Jak se migrovalo AbcLinuxu a spol.

10.5.2011 12:14 | Přečteno: 3034× | AbcLinuxu | | poslední úprava: 10.5.2011 13:21

Zhruba před měsícem naběhlo AbcLinuxu poprvé z nového serveru. Popíšu vám, jak celý proces probíhal.

Do konce března běžely všechny naše weby (tj. AbcLinuxu, ITBiz, HDmag a AbcPráce) ještě ze serverů firmy Stickfish. Na nás bylo najít jiný hosting, kam vše přesunout.

Hledání hostingu

Uvažovali jsme o třech variantách: pořídit vlastní server, server si pronajímat, jít do cloudu. Poslední variantu jsme rychle vyloučili, protože někde by to vyžadovalo kompletní přepis (Google App Engine) a i když jinde ne, tak bych měl stejně pocit, že nemám nic pod kontrolou.

Pak nás oslovil Hosting90, který se specializuje na virtuální servery, což jsem - abych pravdu řekl - moc nezvažoval, protože mé předchozí zkušenosti s hostingem na virtuálních serverech vždy končily zlosti, neboť výkon nebyl nikdy ideální. Mám také zkušenosti z jiné společnosti, kde jsem pracoval a kde se například ukazovalo jako velký problém I/O: extrémně swapující VS dokázal brzdit ostatní VS na stejném fyzickém stroji... Jednoduše to nebylo jako skutečné železo.

Dostali jsme možnost si tedy "virtuální infrastrukturu" osahat a co se mi líbilo jako první věc: distribuci (Debian Stable) jsem si instaloval sám. Ačkoliv bylo možné zvolit si nějaký přednastavený obraz, připojit se přes VNC k serveru a nainstalovat si vše po svém, to má své kouzlo a výhody. Jako třešnička na dortu je pak VNC klient ve Flashi, takže člověk má server rovnou v prohlížeči... Na jednu stranu to může znít jako "machrovina", ale takhle se zase například nemusím nikdy bát vyměnit jádro. Ty nervy, když člověk rebootuje do nového jádra, ty zná asi dobře každý, kdo někdy spravoval nějaký server.

Otestoval jsem výkon a ukázalo se, že virtualizace v podání této firmy není vůbec špatná, přesněji když jsou hardwarové prostředky vyhrazené a samotná virtualizace slouží v podstatě hlavně jako vrstva abstrakce. Když pak selže nějaký HW, migrace je hračka. Možnost naklikat si VLAN mezi stroji nemá chybu. Automatické zálohování "v ceně" taktéž není k zahození. Jinak uvažuji o použití Amazon S3 pro zálohy "mimo budovu". IPv6 je samozřejmost.

Samotný přístup technické podpory také nemá chybu; je ukázkou toho, jak by věci měly fungovat. Na e-maily neodpovídá žádná sekretářka, ehm helpdesk, ale přímo lidé, kteří věci mají na starosti. Člověk při vyskytnutí problému hned dostane informace, co se vlastně děje, kdy to bude opravené, jaký je případný dočasný workaround a jaké kroky budou učiněny, aby se problém neopakoval.

Několik screenshotů z administrace:

Zkoumání clusterového řešení

U Hosting90 máme celkem tři stroje: slabší frontend a dva backendy. Moje původní představa bylo postavit škálující infrastrukturu, kdy nedostatek výkonu vyřeším přidáním dalšího backendu. Namísto klasického MySQL by na jelo MySQL NDB a pro javovské aplikace by byl použit Glassfish. S weby v PHP jsem se dostal hodně daleko. U NDB jsem ale musel přepsat různé neefektivně navržené tabulky (příliš dlouhé fieldy), protože NDB má v tomto znatelné omezení. Samotný výkon mi také nepřišel úplně ideální. Co ale bylo poslední ránou: poškození dat databáze. Při jednom z importů došla MySQL paměť na primární klíče nebo tak něco. Osobně se mi nelíbilo už jen to, že jsem u NDB narazil na další pitomé omezení.

Paměťový limit jsem proto zvýšil a změnu aplikoval na všech nodech. Jenže přerušený import někde něco zvoral, takže ani po intenzivním googlení jsem se nedokázal vymotat ze situace, kdy nedoimportovanou databázi nejde kvůli poškození ani smazat a ani tam dělat něco jiného. Považoval jsem to hlavně jako znamení, protože jsem od NDB čekal něco jiného. Čekal jsem hyper-super neomezenou spolehlivou věc a namísto toho jsem dostal věc s lehce nižším výkonem, tunou omezení a poškozením dat po pár minutách experimentů. Určitě se k tomu někdy vrátím, ale tehdy už jednoduše nebyl čas s tím dlouho experimentovat a určitě jsem nechtěl nasazovat něco neozkoušeného.

Celému plánu škodilo i odrazování od clusterování Drupalu, na které narazíte po chvilce googlení. Problém by byl i se samotným AbcLinuxu, které pro to není navrženo - musela by se předělat cache, aby byla sdílená. WhirlyCache to podle všeho neumí.

Průběh migrace

Začal jsem migrací e-mailových schránek. Doposud byly na Google Apps a my GA neradi. Máme radši e-maily u sebe a máme plnou kontrolu nad nabízenými funkcemi atd. Možná trochu "out" přístup, ale tady se to asi nesetká s takovým nepochopením. Nasadil jsem Postfix a Dovecot, uživatelé jsou v databázi. Jako webmail RoundCube s rozšířeními pro managesieve a změnu hesla.

Speciální věcí pak byla migrace mailing listů. GA nic, co by přesně odpovídalo mailing listům nemá. Nasadil jsem mailmana a od té doby výborně slouží (na rozdíl od GA).

Weby

Pokračoval jsem migrací ITBizu a následně i ostatních webů v PHP. To je asi ten největší průser a po pravdě je to věc, při které jsem nejvíce vykřikoval "to by se v Javě nestalo". Pro autory PHP je nějaká kompatibilita naprostý výsměch. Co vám budu povídat. Trochu novější verze PHP a rázem tisíc a jedna drobnost nefunguje. Díky bohu se snad všeho v PHP brzo zbavíme. Podělal se jeden Drupal, podělal se i druhý Drupal a nefungovalo pořádně ani phpBB. Fakt super.

Migrace Abc byla pohoda. Tady asi není nic dodat. Na původním Abc jsem dal read-only režim, překopíroval jsem data, spustil jsem Abc na novém, změnil záznamy v DNS a bylo hotovo. To samé se týkalo Linkboxu, který je rovněž v Javě. Bugzilla, která je v Perlu, se přesouvala také dobře. Okopíroval jsem config, překopíroval databázi a bylo - dokonce i přílohy jsou v databázi, to jsem ani netušil.

Poslední věcí byl přesun LDAPu. Ten spočíval jen ve vypnutí slave režimu, protože jsem už nějakou dobu nechal kopírovat data z master serveru Stickfishe.

Občas něco dolaďuji, ale Ábíčko je rozhodně rychlejší. Ani jsem to nečekal, ale je to znát jak při prohlížení, tak hlavně při zápisových operacích. Ty dříve blokovaly klidně na několik sekund.

Ostatní

Když se repozitáře se zdrojáky Abc přesouvaly z CVS na Subversion, tak jsem nadával něco ve smyslu "z bláta do louže". Neváhal jsem a všechno jsem šoupnul do Gitu.

Migrace se dotkla pochopitelně i Jabberu. Openfire saje. Nebýt jeho webového rozhraní, tak na něm není snad nic zajímavého. Je to pomalé, rozežrané a chudé na funkce a rozšíření. Teď to jede na ejabberd k naprosté spokojenosti.

Moje aktuální práce

Aktuálně dělám hlavně na bakalářské práci ("FatRat Download Manager Extensions"), ale po jejím dokončení budu zase pokračovat ve vývoji nového enginu pro ITBiz. Je to v podstatě otázka jen několika dnů/týdnů, ale ty si teď nemohu dovolit obětovat. Engine používá Spring Security a Hibernate, jinak se ale jedná o do značné míry vlastní Spring-like framework, který mám to stavěné na míru svým potřebám: abych dokázal implementovat funkce co nejrychleji, s co nejmenší duplikací kódu a rizikem chyb.

Dále jsem v posledních dnech opravil různé chyby na AbcLinuxu: nahlašování závadných komentářů opět funguje, funguje i přidávání/odebírání se ze skupin plus několik dalších oprav, které si už ani nepamatuji. Po dokončení ITBizu se budu věnovat Ábíčku aktivně.

Sobotní výpadek

Brzy možná přinesu podrobnější analýzu sobotního výpadku. Na vině byl kruhový buffer ve virtio, který se zaplňoval daty ve špatném pořadí, a to hlavně kvůli zvýšené latenci (zátěži) v dané době. Buffer se tak ucpal novými daty a stará pak nebylo kam uložit, což efektivně vedlo k deadlocku přístupu k úložišti.

       

Komentáře

[Zdenek]

Jako webmail Dovecot s rozšířeními pro managesieve a změnu hesla.

Ten Dovecot tam asi nepatri. RoundCube?

[Luboš Doležel (Doli)]

Jasně.

[Heron]

Skvělé popsáno, ať se v novém prostředí daří. Virtualizace se netřeba bát.

Pro autory PHP je nějaká kompatibilita naprostý výsměch.

+ INT_MAX

Čekal jsem hyper-super neomezenou spolehlivou věc a namísto toho jsem dostal věc s lehce nižším výkonem, tunou omezení a poškozením dat po pár minutách experimentů.

Já už od MySQL nečekám naprosto nic. Replikace nefunguje (a tím myslím master-slave, ne jakože fake master master režim, kterým se to chlubí), nastavit se to pořádně nedá, neumí to obecně transkace (protože někdo musel nutně použít MyISAM na nějakou pičovinu). V MySQL nevidím žádnou výhodu, jen samé nevýhody. Vlastně ano, člověk se dobře procvičí v data recovery. To, že nefunguje NDB (u nás to taky chtěli nasazovat) mě nepřekvapuje. To už bych raději poradil nad SQL udělat nějakou memcached/redis vrstvu.

[msk]

Super. Otazne je, co clovek moze realne pouzit. MySQL to nevie, Postgres to nevie, ... Co z opensource sveta clovek moze pouzit ako databazu, ktora sa da prevadzkovat v master-master mode?

[Stanislav Petr]

MySQL je mozne v kruhove replikaci pouziat, ale s urcitymi omezenimi - zejmena je potreba na to brat ohledy pri psani aplikace, v dotazech a strukture databaze se vynout nekterym konstrukcim a tak podobne.

Takove nejdulezitejsi body:

1) na kazdem serveru mit nastavene posuniti generatoru autoincrementu

2) vyhnout se nedeterministickym funkcim

3) vsechny update/insert/delete dotazy provadet v transakci

4) dusledne dodrzovat unikatni identifikaci pomoci primarniho klice ve vsech update/delete dotazech

5) mit garantovanou linku mezi obema servery - replikace po internetu (a to vcetne propojeni po paternich linkach) rozhodne nedoporucuju - z vlastni zkusenosti

6) omezit pouzivani kaskady triggeru, pokud mozno vubec nepouzivat

7) nemixovat tabulky ruznych typu - pro replikaci pokud mozno pouzivat InnoDB

8) pro master-master nepouzivat statement based, ale pouze row based.

9) a to nejdulezitejsi - s verzi starsi nez 5.1.55 se o to ani nepokousejte...

[Aleš Kapica]

Vivat la patches!

[nyan]

9) a to nejdulezitejsi - s verzi starsi nez 5.1.55 se o to ani nepokousejte...

Muzu vedet co je za problem v < 5.1.55 verzich ?

[Stanislav Petr]

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-55.html - Pomerne zasadni opravy v replikacich. Po teto varce oprav nam to zacalo celkem dobre chodit. Samozrejme s kazou dalsi verzi se dostavaji dalsi a dalsi opravy replikaci. Ale tohle byla alespon podle nasich zkusenosti prelomova verze od ktere se to da pouzivat.

[nyan]

MongoDB, mozna CouchDB a par dalsich... samozrejme pokud vam nevadi non-sql a javascript ;)

[trekker.dk]

Na vině byl kruhový buffer ve virtio, který se zaplňoval daty ve špatném pořadí, a to hlavně kvůli zvýšené latenci (zátěži) v dané době.

To jsi našel v nějaké bugzille, nebo tě už userspace přestal bavit a tak hackuješ jádro?

[Luboš Doležel (Doli)]

Ne, že by mě jádro nezajímalo , ale tohle řeší Standa z Hostingu 90 (a že mě vždycky těší, že tihle šikovní lidé mají profil na AbcLinuxu).

Já jsem si zatím ani neopravil ten prokletý dvbloopback, aby se nezasekával na novějších jádrech

[Stanislav Petr]

To jsme nasli u nas - provozovatele VPS kde abclinuxu.cz bezi. Se stejnou chybou, ikdyz s trochu odlisnym projevem jsme se setkali uz v jednom pripade zhruba pred mesicem - v te dobe jsme ale problem prisoudili chybe na strane zakaznika. V zasade jde o zahlceni bufferu fragmentovanymi odpovedmi na diskove pozadavky kdy host nemuze pokracovat protoze jeste neodebral nejstarsi data o ktera zadal. Ta ale neni mozne zapsat protoze pri vyrizovani na realnem HW byly pozadavky z hlediska vykonu prehazeny jinak takze byly vraceny v jinem poradi a do bufferu se nedari zapsat zacatek dat. Tohle se dela kvuli vykonu, protoze virtualizovany system nema ani poneti o fyzicke geometrii disku, pozici a trase hlavicek, atd.. Docasnym resenim bylo upraveni vah deadline planovace (snizeni latence), cimz by nemelo dojit k tak velkemu zprehazeni pozadavku ze by se buffer zaplnil drive nez bude obsahovat vsechna data vcetne jejich zacatku.

Dalsi vec ktera by mela v takovemto pripade zlepsit chovani je patch, ktery se pred tremi dny obevil v gitu a ktery definuje minimalni granularitu dat ve virtio:

diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index b14fb99..91e0394 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -290,6 +290,10 @@ static void virtio_blk_handle_write(VirtIOBlockReq *req, 
MultiReqBuffer *mrb)
         virtio_blk_rw_complete(req, -EIO);
         return;
     }
+    if (req->qiov.size % req->dev->conf->logical_block_size) {
+        virtio_blk_rw_complete(req, -EIO);
+        return;
+    }
 
     if (mrb->num_writes == 32) {
         virtio_submit_multiwrite(req->dev->bs, mrb);
@@ -317,6 +321,10 @@ static void virtio_blk_handle_read(VirtIOBlockReq *req)
         virtio_blk_rw_complete(req, -EIO);
         return;
     }
+    if (req->qiov.size % req->dev->conf->logical_block_size) {
+        virtio_blk_rw_complete(req, -EIO);
+        return;
+    }
 
     acb = bdrv_aio_readv(req->dev->bs, sector, &req->qiov,
                          req->qiov.size / BDRV_SECTOR_SIZE,
-- 

[Bluebear]

Doposud byly na Google Apps a my GA neradi. Máme radši e-maily u sebe a máme plnou kontrolu nad nabízenými funkcemi atd.

Výrazy "u sebe" a "plná kontrola" na jedné straně a "virtuální server na cizím stroji" na druhé straně mi nějak nejdou k sobě A to nebudu komentovat to zálohování na Amazon.

[Luboš Doležel (Doli)]

Po zkušenostech s placenou podporou Google (dostal jsem ticket# a nikdy mi neodpověděli)... Teď je to sice na cizím stroji, ale u někoho, s kým se znám.

Extra zálohování kamsi do pryč je nekritická operace. To klidně Amazonu svěřím.

[zulu]

Jako třešnička na dortu je pak VNC klient ve Flashi, takže člověk má server rovnou v prohlížeči... Na jednu stranu to může znít jako "machrovina", ale takhle se zase například nemusím nikdy bát vyměnit jádro.

To jsem nepochopil.

[Heron]

Tím chtěl zřejmě říct, že pokud update jádra z nějakého důvodu selže a nové jádro nenabootuje, tak je opravava velmi snadná. Stačí se připojit na vnc, zjistit co se stalo a v boot manageru vybrat starší jádro, případně problém vyřešit. U fyzického serveru (bez managovací karty či kvm over ip) by v takovém případě bylo nutné k danému serveru fyzicky přijít a vyřešit to na místě připojením monitoru, klávesnice, nebo seriové linky apod. (což je zdlouhavé).

[Filip Jirsák]

S Grubem se to dá udělat i tak, že se nenastaví pořadí položky menu, které se má ve výchozím nastavení bootovat, ale určí se, že se má použít uložená položka. Do té si dám aktuální jádro a v sekvenci příkazů je i takový, který uloženou položku přepne na původní jádro. Mezi startovacími skripty je pak takový, který uloženou položku nastaví zase na aktuální jádro. Takže když se boot podaří a provede se startovací skript, je v Grubu nastaveno, aby se příště nabootovalo zase aktuální jádro. Pokud se boot nepodaří, je v Grubu nastaveno, že se má bootovat z předchozího jádra – takže pak stačí na dálku počítač resetovat. Případně těch záložních jader může být i víc a může to končit nějakým, které nabootuje z nějaké záchranné oblasti minimální systém.

Ale KVM je samozřejmě pohodlnější, ono se to s tím Grubem ne vždy podaří nastavit na první pokus správně.

[msk]

No hej, ale to aby sa clovek potom posral strachom, kde sa uklepol a ci to zafunguje

[pavlix]

Tohle nevidím jako udržitelný stav... pravda, naposled, když jsem vyřadil nějaký server restartem z provozu (tzn včera večer), tak se nakonec ukázalo, že jsem žádnou chybu neudělal a hw prostě jen odmítl znovu startovat... ale v minulosti jsem těch chyb udělal až dost.

A i tentokrát jsem pracoval s minimálně 200km vzdáleným strojem, takže „dojít“ si do serverovny, jako když dělám z domova a server je v Master Internet (tedy cca pět minut pěšky), nepřipadalo v úvahu.

[msk]

On to mozno zulu myslel tak, ze v pripade virtualizacie sa to povazuje tak trochu za samozrejmost ( technologicky aspekt vynecham ).

[Radek Hladik]

Ten Flash VNC klient sice vypadá jako machrovina, ale může být i poměrně užitečný. Ale jak je to s bezpečností? Prohlížel jsem různé Flash VNC klienty a žádný z nich neuměl VNCEncrypt (tedy SSL/TLS, které používá Qemu).

[Leoš Literák]

Migrace Abc byla pohoda. Tady asi není nic dodat. Na původním Abc jsem dal read-only režim, překopíroval jsem data, spustil jsem Abc na novém, změnil záznamy v DNS a bylo hotovo. To samé se týkalo Linkboxu, který je rovněž v Javě.

podobnými migracemi jsem si párkrát prošel, takže teď máš práci ulehčenou