Hírek‎ > ‎

Miért olyan nehéz hibatűrő webszolgáltatást biztosítani?

Tibor Kruska, 2012. máj. 4. 1:50   [ frissítve: 2012. máj. 4. 3:44, felhasználó: Tamas Grosz ]
A múlt hétvégi hálózati kimaradás kapcsán sokan megszólaltak, felelőtlenül vagdalkozva olyan szakszavakkal mint backup szerver, VPS, dedikált szerver, cluster, redundáns webszerver, felhőszolgáltatás, szimmetrikus hálózati kapcsolat satöbbi; fennen hangoztatva, hogy e varázsszavak halmaza a webhosting szolgáltatók Szent Grálja.

Ezek mind létező dolgok, de szinte mindegyik más feladatra megoldás. Azoknak készítettem ezt az összefoglalót, akik be szeretnének picit pillantani a kulisszák mögé.

Minden valamirevaló szolgáltató védekezik hardverhiba ellen a webszerverein. Az első szinten a hibatűrő lemezköteteket használjuk (RAID), hogy egy szinte mindennapos diszkhiba miatt ne legyen egyetlen másodperc kiesés sem. A következő szint a fürtözött technológia (cluster), amikor a komplett szerver tükrözzük, hogy bármelyik szerver(alkatrész) meghibásodása ne eredményezzen leállást (maximum néhány percet, az átkapcsolás idejére). Itt viszont van egy nagyon komoly korlát: a clusterek szinte kivétel nélkül helyi megoldások, tehát a két gép közel van egymáshoz, egy közös (és hibatűrő) adattárolóra kapcsolódnak, és hálózatilag kívülről ugyanazon az IP címen érhetőek el.

A hétvégi esetben ez a megoldás sajnos nem működhetett, mert a komplett szervertermet kapcsolták le, clusterestül, adattárolóstul, hálózatostul.

Miért nem jó, hogy a mentést visszaállítja a szolgáltató egy másik helyen, egy másik szerveren? Nos, amíg csak információs weboldalakat szolgál ki a szerver, amelyek hetente/havonta változnak, nincs is semmi gond. Azonban ha valódi online rendszerek üzemelnek rajta, úgy mint webáruházak, CRM vagy éppen ERP rendszerek, számlázóprogramok, akkor már akár néhány órányi adatvesztés is óriási probléma. 

Ha a szolgáltató egyszerűen csak fogja az utolsó mentést, és visszaállítva beindítja egy tartalék szerveren, a következőket eredményezi: elveszett ügyfélmegrendelések, hiányos ügyféltörténet, szigorú számadású bizonylatok hiánya (pl. számlasorszámozás). Ez adott esetben elképzelhető hogy nagyobb problémát eredményezne, mint maga a leállás ténye, és az ügyfeleknek mindenképpen óriási pluszmunkát eredményez (adatok rekonstruálása, hiányzó bizonylatok manuális rögzítése). Vegyünk egy példát:

Adott egy tipikus online rendszer, egy webáruház. Vegyünk egy mindennapi tranzakciót, egy ügyfél megrendelést. A következő folyamat játszódik le a "fizetek" gomb lenyomására:
  • megrendelés rögzítése
  • banki kapcsolat, kártyás fizetés
  • készlet csökkentés webáruházban
  • CRM rögzítés és folyamatok beindítása (ügyfél értesítése, visszaigazolás)
  • ERP feladás (gyártási + szállítási rendelési feladás)

Ne is a legrosszabbat vegyük, amikor egy ilyen tranzakció félbemarad, hanem egyszerűen amikor szerverhiba vagy elérés hiánya miatt korábbi mentést kell visszaállítani. Ez azt eredményezi, hogy a webáruházban visszaáll a korábbi állapot (azaz eltűnnek komplett megrendelések), de például a külső CRM/ERP rendszerekbe a hívás már megtörtént, tehát ott léteznek a tranzakció nyomai: az ügyfél megkapta az értesítést, a gyártási/szállítási folyamat megkezdődött, de a hivatkozások nem passzolnak a hiányzó adatok miatt. Ezt hívjuk egyébként inkonzisztenciának. 

Triviális a megoldás: építsünk olyan clustert, aminek a két lába két különböző helyen üzemel. A technikai kihívás nyilvánvalóan az, hogy valós időben biztosítanunk kell a két szerver közötti tökéletes (bitről bitre) azonosságot. 

Erre az egyik kézenfekvő megoldás, hogy az adatbázist kihelyezzük egy harmadik, önmagában is hibatűrő helyszínre, ahová a webszerverek kapcsolódnak, és minden műveletet ezen a távoli adatbázisban végeznek el. Ez jó megoldásnak tűnik, azonban a kiszolgálási sebesség egyértelmű csökkenése mellett emelik az SPOF szintjét a rendszernek, hiszen keletkezik egy újabb olyan pont, amely kiesése az egész rendszert veszélyezteti. Annyit csináltunk, hogy a webszerverünk sebezhetőségét lecsökkentettük egy kisebb alrendszer, az adatbázisrendszer sebezhetőségére, és amelyre pontosan ugyanúgy érvényesek lesznek a már felsoroltak: ha csak egy helyszínen belül hibatűrő csak az adatbázis, nem vagyunk előrébb.

A másik megoldás, hogy ügyes mérnökeinket megkérjük, hogy biztosítsák adatszinten a két szerver egyezését. Két komponenssel kell igazából foglalkozni: a filerendszerrel és az adatbázissal. A filerendszer szinkronizálására rengeteg megoldás létezik, a teljesség igénye nélkül: hálózati filerendszer, rsync, mirror stb. Az adatbázis folyamatos szinkronizálására pedig a master/slave, standby, replica, logshipping kulszavakat minden gyakorlott IT mérnök kapásból vágja.

Ezek így elméleti síkon akár egyszerűnek is tűnhetnek, azonban a gyakorlatban sajnos már bonyolultabb. A két szerver között ugyanis olyan sávszélesség szükséges, ami távoli helyszínek esetében (ahogy az egésznek értelme van) nem egyszerűen biztosítható. Hiába van a szerverünkön például gigabites hálózati kapcsolat, ha a távoli (esetleg külföldi) szervert csak ennek töredékével tudjuk elérni. Ha nincs megfelelő sávszélesség, a felhasználó jelentős lassulást fog érzékelni (hiszen meg kell várnia, amíg a távoli szerver szinkronba kerül), vagy pedig a konzisztencia fog sérülni hiba esetén, ha engedjük szétcsúszni a szerverszinkront.

Mindezeket csak azért írtam le, hogy a "clustert neki!" vagy éppen a "mire való a backup szerver?" felkiáltások még nem biztos, hogy megoldanak mindent.


Egy lehetséges megoldás...