Vysoce dostupné Abíčko

5.12.2007 21:34 | Přečteno: 2250× | Abíčko |

Zatím jen sen, těch výpadků jsme ale už zažili tolik, že Stickfish plánuje nasadit Abíčko do clusteru. No a já trochu chladím jejich nadšení soupisem možných problémů. Rád bych slyšel vaše názory a postřehy, jak byste je řešili vy.

Poslední výpadek byl způsoben hard diskem, který se poroučel do věčných lovišť. RAID nám sice zachránil kůži (už poněkolikráté), ale nemůžeme se spoléhat na jeden server. V nárazech nemusí stíhat požadavkům, ale hlavně jeho výpadek znamená desítky minut či hodiny nefunkčnosti Abíčka. A to si prostě nemůžeme dovolit. Takže se koupila další našlapaná mašina, na kterou se přesunou všechny servery (webové) a z původního stroje vznikne druhý uzel pidi clusteru. Na obou strojích by měly být nainstalovány stejné webové aplikace i databáze, která se bude mezi nimi replikovat. Požadavky bude na uzly rozhazovat buď specializovaná mašina nebo nějaká síťová komponenta (nejspíše round robin algoritmus, nic sofistikovaného).

Život mě naučil jisté skepse a tak dopředu hledám rizika, ať se na ně mohu připravit. Za prvé databáze. Abíčko teď jede na MySQL 4.1, která clusterování neumí. Přechod na pětku snad nebude tak bolet, jako na 4.1 (důsledkem jsou duplicitní loginy, které tento víkend budeme fixovat). Jaké máte zkušenosti? Je možné rozjet MySQL na dvou počítačích tak, aby databáze byly v obou okamžicích rovnocenné a vzájemně zastupitelné? Aby měly stejné data a když jeden uzel spadne, druhý jede v pohodě dál a po obnovení spojení ten první uzel jen načetl změny? (Nechci mít dedikovaný databázový server, stejně bychom jej museli dát do clusteru.)

Dalším rizikem je souborový systém. Abíčko má spoustu souborů na disku, uživatelé nahrávají screenshoty či obrázky. Jak efektivně ale zajistit, ať oba uzly mají stejná data při požadavku na co nejmenší riziko zatuhnutí? Připojit disk ze třetího stroje (třeba NFS) nepovažuji za dobrý nápad, jeho výpadek by zasáhl oba uzly. Takže spíše nějakým skriptem neustále synchronizovat adresáře na obou strojích. Ale to bude asi dost náročné na výkon počítače.

Další problém vidím v Abíčku jako aplikaci. Abíčko je nesmírně optimalizovaná aplikace (kvůli jedné hloupé chybě - vypnutí JIT - jsem dělal divy), jenže všechny ty cache jsou stavěny na tom, že Abíčko běží na jediném stroji. Kdyby běželo na dvou strojích, rychle by byly cache nesynchronizovány a data by se mohly poškodit či přepsat, různě ztrácet atd. Například uzly A a B načtou softwarový záznam. Uzel A jej pak upraví, změní třeba licenci a uloží jej. Nicméně uzel B o tom nic neví a má v cache původní hodnotu, takže když má změnit třeba popisek, uloží do databáze řádek se starou licencí a novým popiskem. Což se ale nedozví uzel A a tak bude všem čtenářům ukazovat starý popisek a novou licenci, zatímco uzel B bude ukazovat starou licenci a nový popisek. Schíza, že?

Co teď? Jak toto vyřešit? Udělat komunikaci mezi cachemi, aby se vzájemně informovaly, když je třeba něco načíst z databáze? Nebo zahodit současnou cache a najít nějakou distribuovanou cache? Máte v této oblasti zkušenosti? Co byste doporučili?

       

Komentáře

[Jan Drábek]

"Život mě naučil jisté skepse a tak dopředu hledám rizika"
Ano, život a především rodičovství tě tohle naučí :D - měli jsme informatika - první rok fajn chlap - druhej rok si "pořídil" dítě a hned nás viděl při sebemenší akci rozpláclé na podlaze s vyhřezlým mozkem... Nic ve zlým - fajn chlap pořád :D Nic proti tobě ;)

[Leoš Literák]

No já Lucinku nechávám, ať se otluče. Sice si vždycky zapláče, ale aspoň se naučí větší opatrnosti. Hlídám spíše ty rizika s většími následky (elektrika, těžké předměty, výšky, ostré rohy).

[Jan Drábek]

Mě rodiče taky nechávali takhle - jednou jsem se zaklínil pod topení

[Käyttäjä 11133]

Já pod televizí

[Rezza]

Ja si zase hral s kabelem v zasuvce, ktery misto spotrebice koncil mnou :D

[ʚĭɞ 🍉]

Při tvém tvaru těla... ^_^

[ajikdpoe]

Jo, to je tak ked sa nepocita s clusterom od zaciatku vyvoja aplikacie, obcas to byva neprijemne, nastastie sa zrejme nejedna o pripad "Sef si precital clanok vo vikendovej prilohe dennej tlace, v piatok nasadzujeme u zakaznika" ale aj tak, radsej dvakrat merat a raz strihat.

[Leoš Literák]

Ten cluster není potřeba kvůli výkonu jako spíše pro zvýšeni dostupnosti. Load se stále ještě pohybuje kolem 0,5.

[petr_p]

Tak používejte v jeden okamžik jen jeden server.

Obecně v clusteru, kde jenom jeden uzel může zapisovat, je mnohem jednodušší udržet konzistenci.

U clustrů s rovnocennými uzly je synchronizace značně obtížná a představuje nezanedbatelnou režii. Pak je třeba volit kompromis mezi režií a oknem nutným pro synchronizaci (tj. množstvím transakcí, které při selhání přijdou zahodit).

Lze říci, že čím více ůzlů je, tím lze obsluhovat více použadavků v jednu dobu, ale naopak délka obsloužení jednoho požadavku se prodlužuje.

[stativ]

Já bych na to asi šel podobně. Na jednom serveru by primárně běželo ábíčko, druhý by se podle něj miroroval a prováděl zkoušku dostupnosti prvního serveru. Když by primární server byl nedostupný, zapojil by se do hry.

[Luboš Doležel (Doli)]

Mně by přišlo, že je to škoda. Hlavním účelem je sice zvýšení dostupnosti, ale výkon navíc k zahození také není - hodí se v budoucnu.

[pele]

A co clusterovat jen datovou vrstvu, tedy jen databazi. Aplikacni vrstvu nechat na dedikovanem stroji, kdyz je pro nej optimalizovan?

[Leoš Literák]

Hlavním cílem této akce je zvýšit dostupnost, tedy minimalizovat stav, že je abíčko nedostupné. Takže je potřeba clusterovat nejen db, ale i aplikaci, protože jinak by výpadek stroje s aplikací znamenal přerušení provozu abíčka. HA cluster nesmí mít žádný slabý bod, jinak nic neřeší.

[Rob]

Tak proc teda chcete rozdelovat pozadavky mezi obema stroji? Prvni co cloveka napadne, kdyz se nema zvysovat vykon, tak posilat kazdy pozadavek na _oba_ stroje. Podle naivni predstavy by pak mel byt na obou strojich stejny stav. Neumim posoudit, zda je to ta spravna cesta a zda se muze stat, ze odpovedi by mohly byt ruzne (tedy dojde k rozsynchronizovani). Asi jo. Takze asi jinak. Kazdopadne je ale jednodussi synchonizovat jednim smerem nez obema, teda na jeden stroj zpracovava vsechny pozadavky a na druhy posila aktualizace. Zadne rozhazovani pozadavku.

[Roman]

Co to zjednodusit a mit druhy server jen stand-by a replikovat jen mysql a obcas (tak casto se nemeni) soubory? Replikaci jednim smerem uz umela relativne spolehlive i mysql 3.23.xx... Pri padu prvniho serveru si jen druhy vezme jeho IP a jede se dal.

[jm]

Vo jave a cachi vim kulovy. Ano, MySQL funguje v clusteru tak, jak chces, ale je to celkem vopruz zprovoznit. Takhle funguje treba Gentoo bugzilla. Mezi mensi chybky patri treba to, ze zaznamy v DB nejsou cislovani postupne, ale tak nejak se obcas nejake cislo vynecha.

[Marek 'marx' Grác]

Takže pekne po poriadku :)

HA (High Availability) cluster na linuxe sú a fungujú. Tieto riešenia ponúka RedHat, Suse, TurboLinux a snáď aj iní. Budem RH-centrický, ale takto abstraktne sa budú meniť len mená programov.

Load-balancing, ktorý nepotrebuješ rieši piranha ( v kerneli to je VIP - virtual IP; súčasná implementácia len ipv4). Tá ti rozloží záťaž s tým, že veci od jedného užívateľa pôjdu vždy (rozumne dlhý interval) na jednu mašinu, aby šlo pracovať so session.

High availability - základný problém, ktorý potrebuješ vyriešiť je SPOF (single point of failure). Ako si na to správne prišiel, tak to bude databáza. Active/active riešenia využívajú kúsok odlišný prístup a preto je Oracle RAC, Mysql a PgSql cluster (presný názov si nespomeniem; pre Pg je toho viac, viď prednáška na LinuxTag '07). Bežne, ale ľuďom stačí, keď to dokáže nabehnúť za pár jednotiek až desiatok sekúnd na druhom stroji. Toto rieši RH Cluster Suite (tým pádom samozrejme aj CentOs). Problémom je, aby tam boli dostupné tie súbory s databázou. Buď to dáme na NFS a máme znovu SPOF, alebo kúpime naozajstné diskové pole (tj. nie JBOD - just bunch of disks - to sú tie lacné). Takéto polia sú bohužial drahé ako divá sviňa, na druhej strane ich môžeme pripojiť do viacerých počítačov súčasne (iScsi alebo FibreChannel). Jedno menšie pole má Dell, je ho možné pripojiť do dvoch mašín, a nič lacnejšie a použitelné IMHO nie je (budem rád ak ma niekto vyvedie z omylu). Ak chceme mať pripojený disk viackrát, tak potrebujeme vhodný filesystém, ponúka sa global filesystem - gfs a gfs2 (oba vo vanilla kerneli). Tie sa postarajú o to, aby tam mohli mať všetky stroje práva na zápis aj čítanie.

active/passive riešenie - vyrieši cman/rgmanager (resource manager - máme záľubu v divných skratkách, preto pri testovaní mám často spustené rgmgrd -fd :) Nepoužívajú sa klasické init skripty, ale resource agents - čo je vlastne skoro to isté s pár odchýlkami. Medzi hlavné patrí podpora pre to, aby vám bežal na jednej mašine x-krát Apache,MySql (na sebe nezávislé, s rôznymi pid file, lock file, konfiguráky, ip adresy, ...). Presun po páde služby je transparentný (stop/start).

Súčasný trend spájania projektov sa týka aj pôvodne dosť odlišných clustrov RH/Suse, viac nájdete pod heslom openAIS.

[Oldak]

A co takhle pouzit DRBD a Heartbeat? ... Byla o tom docela pekna prednaska na lonskem LinuxAltu v Brne a je o tom myslim i serie clanku na Rootu. Toto by melo byt reseni rychle a vcelku efektivni. Data jsou neustale synchronizovana po blocich a dojde-li k vypadku jednoho ze serveru, tak jeho roli behem nekolika sekund prebira stroj druhy. Nebyly by potreba zadne zasahy do aplikace abicka.

Olda

[marekb]

Na synchonizaci filesystemu v podobnych scenarich pouzivam drbd - prozatim k plne spokojenosti - pouzivam prave na konzistentni kopii prevazne statickych dat.. Load balancing a fail-ver aplikacniho serveru webovych aplikaci resim pomoci nginx, take k plne spokojenosti..

[Dan Ohnesorg]

Multiple master MySQL je sice mozne, ale moc bych se do toho nehnal. Pokud vim, je to mozne pouze pokud databaze neni vetsi nez fyzicky dostupna RAM a neni zaruceno to, ze primarni klic bude sekvencni, na coz mnoho vyvojaru ponekud nestastne spoleha.

Ja bych to zase tak HA neresil, dal bych jedno mysql s replikou na druhy stroj, rozdelil objekty na staticke a dynamicke a kazde hnal z jednoho stroje. Mozna nejake sdilene NFS pole, kdyz klekne tak klekne, tak se data obnovi na zalozni stroj a nebo lokalne. Zalezi samozrejme na tom kolik jich je.

A kdyz se stane, ze jeden ze stroju padne, tak bych rucne nebo pres heartbeat nakopl sluzby na druhem stroji. Upgrade repliky mysql na master je trochu pracnejsi, ale mozny.

Takle postavene reseni dokaze obsluha nahodit zpet online ve vetsine pripadu do tech cca 60 minut. Coz podle me pro abicko bohate staci. Navic v bezne pracovni dobe to bude stejne jeste rychleji, rekneme do tech 15 minut by se to mohlo stihat. Abicko vzhledem k unikatnimu obsahu fakticky netrpi tim, ze by zakaznici nakoupili jinde, kdyz nepobezi. Proste prijdou pozdeji,takze pocet zobrazeni reklam se sice v hodine vypadku snizi, ale v dalsi hodine zase naskace a globalne za den to vyjde +- stejne.

[Leoš Literák]

My bychom rádi snížili výpadky na délku maximálně desítek sekund, hodina je moc. Nejde ani o chybějící imprese, jako spíše o důvěru čtenářů a dopad na image.

[Filip Jirsák]

Cache bych řešil přechodem na nějakou knihovnu, která už má sdílení vyřešeno. Databáze asi bude oříšek, tedy pokud nechcet koupit nějakou komerční nadstavbu. Osobně bych asi zatím nešel do on-line replikace, ale použil bych pouze fail-over zálohu – tj. na druhém stroji mít data v readonly režimu a v případě výpadku primární databáze během pár sekund přepnout na zálohu. Nějaké články o clusterehc v MySQL a PostgreSQL jsou na blogu WhoAmI?.

Odkazy o clusterování s Jetty v dokumentaci asi znáš.

[dustin]

Přesně pro toto používáme drbd a heartbeat mezi dvěma servery. Funguje to velice spolehlivě, ostré webové aplikace nám takto běží několik let (v průběhu času se měnily stroje, což je s touto technologií poměrně jednoduché). Přes drbd mirrorujeme i mysql (v. 5, převážně innoDB), po přemigrování (řízeném či automatickém po poruše zdroje) na druhém stroji vždy vše naběhlo v pořádku. Máme to postavené tak, že přes drbd mirrorujeme celou chrootovanou instalaci debianu, tudíž po migraci máme úplně stejné SW prostředí, jako na primárním stroji. Pro dlouholetý provoz se to ukazuje jako docela zásadní.

[Věroš]

Já teď přemýšlím o podobném nasazení, jenom místo chrootu hodlám mirrorovat XENové image.

[rADOn]

Master - master replikaci mysql se vyhni, sic vymenis dostupnost za konzistenci dat. Stacila by master - slave replikace, jednoduchy wrapper nad db knihovnou ktery by vybiral spojeni (selecty do slave, zapisy do master) a pohlidal si failover a kdyz se neco pos... A prepnout slave na master je trivka.

Distribuovana cache se jmenuje memcached. Urcite existujou i nejaky javacky reseni ale afaik zadny z nich neni tak vykonny.

Pristup k souborum bych opatril handlerem ktery kdyz nenajde lokalne zepta se po siti (stacil by http redirect) cimz by aktualnost synchronizace prestala byt tak kriticka a snad by se dalo vyjit s rsyncem.

[Josef Kufner]

Na synchronizaci souborů by nemuselo být špatné použít incron a kopírovat třeba po NFS. Vytvoří/změní se soubor -> incron ho pošle k sousedům.

[Tomas Krause]

Ad data - co máš, Leoši, proti datům na externím diskovém poli? Pokud je to skutečné pole a ne parodie, je to prakticky nezničitelné (RAID, záložní zdroje, ...) a vůbec bych se toho nebál. Nepamatuji se na jediný výpadek našeho diskového pole za tři roky... Jen bych asi nebral IBM s ohledem na zkušenost Seznamu :)

[Dan Ohnesorg]

No ono je to take o te povestne kapicce stesti. Samozrejme pole se vetsinou nedostava do problemu, protoze na nem v podstate nic nebezi (jen kernel + nfs nebo iscsi), ale na druhou stranu to pole za ty tri roky nepotkal ani jeden vypadek proudu, ani jeden vypadek klimatizace.

U toho seznamu to taky nebylo nutne o IBM, znam i pripady havarii poli jinych firem se stejnym ci podobnym prubehem. Protoze cert nikdy nespi, tak se ukazuje, ze redundantni zdroj umira zpravidla tak, ze oba bloky jsou ve stejne kondici a tak selhani jednoho a nasledne zatizeni druheho vede k selhani druheho. Roky nepouzivana zalozni cesta na FC se ukaze nefunkcni kdyz se na ni preleje provoz. Obnova dat ze zalohy na pole, ktere se rebuilduje take nepatri k zalezitostem resitelnym v radu minut.

Myslim ze cil v podobe obnovy z HW nebo SW poruchy v radu 30s dava tolika devitkovou dostupnost, ze je pro portal financne nedosazitelna. Ale lze se ji asi za cenu velkeho plytvani HW priblizit s nadeji, ze k vetsinu vypadku dojde treba jednou za rok. Pro priklady nemusime chodit daleko, staci se podivat na sporku tento tyden, reseni za deviticiselnou sumu, udajne neodstrelitelne nicim a hnedle nekolikahodinovy vypadek.

[Filip Korbel]

story Seznam a pole IBM nebo podobne jsou, jak se zda, fenomenem. nyni maji par "thumperu" od sunu pod nazvem X4500 na ZFS, tak jsem zvedav jak to kluci pod vlastou vyhakujou a napisou si svoje ovladace na marwel chipsety a pod

pole na FC nebo neco s raidem SAS je hezke reseni a dnes asi jiz cenove dostupne i pro abicko. kdyz to ale "umre", tak bez 4h supportu vyrobce, co stoji 40pct ceny pole, je stejna situace jak s plackou a dvema disky. zvedat data z mrtve placky kde je nejaky cluster FS je asi mene prace, nez presvedcovat konzultanty IBM nebo Coma, ze firmware LSI karty s disky Hitachi pojede tak tyden a je treba downgrade, ale data budou necitelna. pokud nekde pada elektrina, tak je jedno zda tam je EMC nebo Chenbro. pri dobrych zalohach baculou a jedinou sluzbou na tom policku ve forme nejakeho FS je asi obnova veci minut.

jsem moc rad za tuto diskusi, protoze prinasi tolik napadu, ze to asi ani leos necekal.

jake pole/vyrobce pouzivaji v iinfo? :-]

[xkucf03]

Sdílenou cache by šlo řešit pomocí Terracoty, je to JVM běžící na několika počítačích a objekty se sdílí - viděl jsem prezentaci na CZJUGu a vypadalo to velmi efektně

S těmi soubory mě napadá několik možností:

1. Použít nějaký vhodný sdílený FS. Jenže jaký?
2. Nacpat data do databáze. Hodně lidem je to proti srsti, ale když se vybere správný DBMS, tak by to mělo jít. Databáze je koneckonců vrstva mezi aplikací a diskem, stejně jako souborový systém.
3. Pro uživatelské soubory (obrázky) vyhradit jeden server a dát mu vlastní doménu (třeba data.abclinuxu.cz). Aplikační servery (členové clusteru) by na tento souborový server pouze zapisovaly změny (přidávaly soubory) a čtení by probíhalo přes HTTP přímo ke klientům (obrázky by přes aplikační servery vůbec neprocházely).

Výhoda třetího řešení by byla i v tom, že když hodně lidí začne koukat na Desktopy a jiné obrázky, nezatíží tím aplikační servery, a tudíž uživatelé, kteří si čtou texty tím nebudou obtěžováni (aplikační servery generující text se nezatíží - zpomalí se jen načítání obrázků).

[Filip Jirsák]

Přimlouval bych se taky za třetí řešení, přičemž ten server zároveň může dělat nějaké méně kritické věci – rozesílat e-maily (informace o změnách v diskuzi), přepočítávat skóre, aktualizovat index pro vyhledávání atd.

Dalo by se to udělat i tak, že aplikační server (např. při uploadu obrázku) přijme data, uloží je na datový server a zároveň dočasně do svého lokálního souborového systému. V noci se pak provede záloha datového serveru, a teprve když proběhne úspěšně, smažou se soubory z dočasného úložiště na aplikačním serveru. Takže v případě havárie disku na datovém serveru by se soubory obnovily ze zálohy z minulé noci, a co se mezitím nahrálo v průběhu dne by se obnovilo z dočasných úložišť na aplikačních serverech.

[onovy]

mrknete na tohle http://sequoia.continuent.org/HomePage

Mirrorovani dat se da resit pomoci rsyncu, ale je to takove... nehezke :]