A beszállító visszaüt: hogyan térdelt le tavaly a Delta?
Érdekes részletek rejlenek a Delta légitársaság tavaly augusztusi masszív, több napos járatkimaradásai mögött. A kritikus adatközpont leállásához ugyanis olyan vitatható döntések vezettek, amelyből mindenki sokat tanulhat.
Nálunk is hír volt tavaly augusztusban a Delta Airlines adatközpontjának leállása, amely hosszabb időre ki is vonta a légitársaság gépeit a forgalomból. A pénzügyi kár jelentős, a hiba oka azonban egészen meglepő helyről érkezett. Lássuk a szaftos részleteket egyenesen az adatközpont-legenda James Hamilton tollából.
Atlanta, we have a problem
A leállás maga prózai epizóddal kezdődött: leállt az áramellátás. A kérdéses adatközpont (ahogy az adatközpontok túlnyomó többsége) erre felkészült, a kieső villamoshálózati tápellátás pótlása ma már alapvetően megoldott problémának számít. Az adatközpont a közmű-áramot ugyanis saját generátoraival tudja pótolni, azok beindításáig és bemelegedéséig pedig a helyi UPS-ek adnak áramot a szerverek alá. A folyamatot általában gyakorolni is szokták az üzemeltetők, ma pedig már magasan automatizált megoldások hajtják végre, mindenféle felügyelet nélkül is.
Esetünkben is így történt, azonban az áramforrások közötti zökkenőmentes váltást végző automatizált villamos kapcsoló a generátort kizárta a rendszerből. Ennek eredményeképp az UPS-ek sorban lemerültek, a szerverek leálltak, és hiába pörgött stabilan az adatközpont generátora, azt a belső villamos hálózatra nem tudták az üzemeltetők felkapcsolni, ami a kritikus számítási feladatok leállásához vezetett - esetünkben a Delta elvesztette a képességét arra, hogy elindítsa a járatokat (szerencsére senki nem volt veszélyben, a már levegőben lévő gépek zavartalanul érték el célpontjaikat).
A posztmortem alapján fény derült a probléma okára: az automatizált kapcsoló a közmű-áram elvesztését követően feszültséganomáliát észlelt, ami utalhatott arra, hogy a belső, adatközponti rendszerben van rövidzárlat valahol. Az esetre megadott, beprogramozott szabály alapján pedig a generátort védendő nem engedte annak felkapcsolását. A megközelítésben van logika, mivel ezek a generátorok egyenként mintegy 750 ezer dollárba kerülnek, ezért érdemes szigorú védelmi mechanizmusokat beiktatni.
Csakhogy a leállás nyomán az érintett légitársaság mintegy 100 millió dolláros közvetlen kárt szenvedett, első napon mintegy 1000 járatot kellett törölnie, a menetrend szerinti szolgáltatás pedig csak az ötödik napon állt helyre teljesen, ennyi időbe került visszaállítani a rendszerek normális működését. És akkor nem beszéltünk a légitársaság renoméján esett csorbáról, amely még évekkel később is kieső bevétel formájában jelentkezhet. A fentiek fényében egyértelmű, hogy a generátor védelmének másodlagosnak kellett volna lennie, a kritikus számítási feladat elvesztése ennél több nagyságrenddel nagyobb veszteséget jelentett.
Transfer switch - fekete doboz?
Hamilton spekulációja szerint az anomáliát egyébként sok tényező okozhatta, ezek túlnyomó többsége azonban az adatközponton kívüli, így a generátor kizárása nem volt indokolt. Vannak persze belső tényezők is, elképzelhető, hogy a rövidzárlat az üzem területén található, ebben az esetben viszont a generátor bekapcsolásával kinyitnak a megfelelő biztosítékok, az adatközpont nagy része viszont biztonságosan működhet tovább. És annak is nemnulla az esélye, hogy a hiba a villamos elosztó rendszer felsőbb szintjein van, biztosíték védelme nélkül, és a generátort tényleg károsítani tudja - de a fentiek alapján ennek vállalható kockázatnak kell lennie.
Az adatokból egyébként könnyen kikövetkeztethető, hogy a Delta Airlines tavaly augusztus eleji incidenséről van szó. A cég akkori tájékoztatása szerint az atlantai globális irányítóközpontot kiszolgáló adatközpont esett ki, ezt használja a társaság a flotta kezelése mellett a személyzet és az utasok számontartására is - a javításoktól a gépen található ebédek számáig, a beszállókártyákig minden ide fut össze. A történethez tartozik az is, hogy a Delta (természetesen) készenlétben tart egy tartalék adatközpontot is ilyen esetekre, a failoverre azonban egy másik probléma miatt nem került sor. Így az irányítóközpont elsötétedett, a gépek pedig a földön maradtak.
Érdemes rá hallgatni
Hamilton egyébként nem egyszerű adatközponti szakember - ő felel az Amazon Web Services alatt dolgozó adatközpontok felépítéséért és működéséért. Az Amazon előtt a Microsoft foglalkoztatta, hasonló, Data Center Futures Architect funkcióban a Windows Live Core rendszerekért felelt. Kompetenciája tehát az ilyen adatközponti infrastruktúrához kapcsolódó obskúrus hibaforrások ismerete és megelőzése.
A szerző elmondása szerint az Amazon is belefutott korábban ugyanebbe a hibába: akkor egy autós döntött ki egy alumínium villanyoszlopot, rá az adatközpontot kiszolgáló huzalokra. Az eredmény pedig azonos volt: az áramellátás leállt, az automatikus kapcsoló pedig a (külső) rövidzárlatot észlelve kizárta a generátort. Akkor a kapcsolót szállító gyártóval is felvették az Amazon mérnökei a kapcsolatot, a cég azonban vonakodott az algoritmus módosításától - még úgy is, hogy az Amazon vállalta a generátort érő kárért a felelősséget.
A beszállítói algoritmus problémájára van megoldás egyébként: saját vezérlést implementálni. Ma már az Amazon is ezt alkalmazza, az adatközponti áramellátást vezérlő, a fenti helyzetekben döntést hozó PLC-k (programmable logic controller) firmware-ét az üzemeltető csapat írja, így egészen részletesen meg tudja határozni a különböző eseményekre adandó válaszokat. Ezt persze nem minden vállalat tudja megengedni magának, a nagyobb skálán dolgozó, sok adatközpontot üzemeltető cégeknek azonban ez járható út.
A szakemberről a Wired írt 2013-ban portrécikket, érdemes azt is fellapozni, meglehetősen részletes leírását adja a blogposztban is említett amazonos problémának.