Az internet örök, nem az, ami fut rajta

Az internetet, vagyis a később internetté váló ARPANET-et a legenda szerint arra tervezték, hogy az USA rakétavédelmi számítógépeit összekötő hálózat akkor se váljon működésképtelenné, ha atomtámadást intéznek az ország ellen. Anélkül, hogy túl mélyen belemennénk abba, hogyan is működik pontosan az internet, fogadjuk el, hogy az eredeti célt végül sikerült is elérni. Az internetre kötött gépeket képzeljük el házakként, ahova utak vezetnek. Egy-egy házhoz több út is vezet, a legjobb útvonalat az útkereszteződésben álló forgalmi rendőrök (útvonalválasztó berendezések) döntik el. Az internet előnye, hogy központ helyett rengeteg út és útválasztó van, így ha valami miatt a legjobb út ki is esne, a kapcsolat nem veszik el a céllal, csak másfelé kanyarogva valósul meg.

Atombiztos kártyavár

Ez jól működik a gyakorlatban, hiszen ha nem így lenne, most nem az interneten folyna a gazdasági folyamatoktól a macskás képekig és a pornóig minden, ami egy picit is fontos az emberiség számára. A rendszert arra tervezték, hogy nem számít, mi csap bele, megrázza magát, és működik tovább. Ehhez képest a Sandy hurrikán alaposan megtépázott több szolgáltatást. Weboldalak álltak le, cégek adatai váltak elérhetetlenné annak ellenére, hogy nemcsak az internet van atombiztosra méretezve, de elméletileg az üzleti alkalmazások többsége is. De nem kell hurrikán ahhoz, hogy a világ kisebb-nagyobb felén egyszer csak ne lehessen normálisan netezni.

2011-ben Pakisztán úgy döntött, hogy az iszlámellenes filmek elleni tiltakozásul letiltja a Youtube-ot az országhatárokon belül. A megoldás egyszerű volt: a Youtube felé irányuló adatkéréseket egy hálózati fekete lyukba vezérelték. Elfelejtettek azonban kivételt tenni azokkal az adatokkal, amelyek csak átmennek a pakisztáni hálózaton, de nem pakisztáni célponttal rendelkeznek.

A hatás nagyjából úgy képzelhető, mint a katasztrófafilmek kötelező New York-i áramkimaradásos jelenete, amikor a nagytotálban mutatott, fényben fürdő belvárosi felhőkarcolók egymás után válnak fekete monolitokká. A pakisztáni akció is a dominó-elvet követte: eleinte még mindenhol volt Youtube, aztán szép lassan leszakadt Ázsia, Európa, végül pár óra alatt a világon mindenhol minimum akadozni kezdett a videómegosztó. A megoldás ugyanolyan egyszerű volt, mint a pakisztániak akciója: az ázsiai ország interneteléréséért is felelős, hongkongi PCCW adatközpontban egész Pakisztánt lekapcsolták az internetről, így az útvonalválasztó berendezések elkezdték egy új útvonalon küldeni a csomagokat.

Az eset még csak nem is egyedi. 2010 áprilisában az Európát és a Közel-Keletet összekötő, a Földközi-tengerben futó gerincvezetéket, a SeaMeWe-4-et nyírták el, két évvel korábban pedig nagyjából egyszerre szakadt el két (egymást helyettesítő, de egymástól alig két kilométernyire lévő) indiai, és a Falcon nevű, európai gerincvezeték. Mindegyik eset komoly kieséseket okozott, ráadásul nemcsak az interneten, de a telekommunikációban is.

Ráadásul az, hogy az internet, mint a gépek hálózata, elméletileg halhatatlan, már nem elég. Manapság már nemcsak az az elvárás, hogy emaileket küldhessünk vagy hogy tudományos anyagokat érjünk el a hálózaton. A mérnökök a hálózatok folytonosságának biztosítása után arra is rájöttek, hogy az sem lenne baj, ha az interneten futó szolgáltatások is védve lennének. Ha nem is egy atombomba hatásai ellen, de jó lenne, ha egy földrengés, árvíz, vagy a huszonegyedik században is fájóan gyakori áramszünet nem okozna gondot, hiszen a szolgáltatás típusától függően egy-egy kiesés percek alatt is képes milliókban mérhető károkat okozni.

Bécépé, déerpé

Ennek kivédésére születnek az úgynevezett katasztrófa- illetve üzletfolytonossági tervek (disaster recovery plan, avagy DRP, és business continuity plan, azaz BCP). Az alapötlet az, hogy minden olyan tényező tragikusra fordulására fel kell készülni, amire nem feltétlenül van befolyásunk. Tehát természeti katasztrófára, áram-, telefon- vagy internetkimaradásra, hardveres hibára, és így tovább.

Van, amire egyszerűbb felkészülni, például a hardveres hibák kivédésére ott a gépek összeállításnál szem előtt tartott redundancia: ha elromlik egy tápegység, egy hálózati kártya, elszakad egy vezeték, akkor mindig legyen másik, ami automatikusan (de legalábbis előre programozható noszogatással) be tud ugrani a másik helyére. Az áramot, telefonvonalat és internetet adó szolgáltató kiesésére előre készülni már picit macerásabb, de egy telephely kiválasztásánál fontos szempontnak kell lennie annak, hogy több cégtől is rendelhessünk például áramot, és hamar át lehessen állni egy másikra, ha az alapállapotba belerondít valami.

Nagyjából itt kezd igazán költségessé válni a dolog – ha egy cég igazán katasztrófaállóvá akar tenni egy szolgáltatást, az alapnak mondható túlbiztosított hardvert megveszi még egyszer, és elviszi egy másik helyen, szerencsés esetben másik tájegységen létesített szerverterembe, pótszervernek. Így aztán, ha mondjuk egy meteor eltalálja az általában működő gépet, a szolgáltatás úgynevezett failover módba kapcsol, és szépen átvándorol a másik gépre, ami semmi mást nem csinál, csak arra vár, hogy ez megtörténjen. Jó tervezés és helyes működés esetén ez az egész úgy megy végbe, hogy a szolgáltatást használók semmit sem vesznek észre az egészből.

A Sandy hurrikánt nagyrészt ugyan megúszta az internet, de az is látszott, milyen kevés elég ahhoz, hogy boruljon a szépen kigondolt elv. A failoveres megoldás mondott csődöt a net legnépszerűbb aktuális tartalmát összegző Buzzfeednél is. Egy failover esemény idején lefutó parancssorozat általában sikerrel zárja le a folyamatokat az egyik, majd nyitja meg a folytatáshoz kellő dolgokat a másik oldalon, ezzel próbálkoztak a Buzzfeed szakemberei is, ám valami miatt ez nem járt sikerrel. A failovert egy a New York-i adatközpontot sújtó áramkimaradás váltotta ki, a szolgáltatás azonban már nem ért el a newarki pótgépekre. Ennek számtalan oka lehet. Bár az előre kitalált eljárások tesztelhetők a kábelek kihúzásával vagy a gépek váratlan leállításával, valós vízbetörést, földrengést vagy hurrikánt nem lehet pontosan szimulálni.

Semmi sem sikerülhet elsőre

A katasztrófáknak van azonban előnye is. „Minden ilyen balhé segít a megoldások javításában” – mondja Kincses Zoltán információbiztonsági szakértő. „De így van ez a Forma–1-ben is.” A szakértő szerint az ilyen helyzetekre nemcsak nem lehet tökéletesen felkészülni, de nem is biztos, hogy érdemes. Fel kell mérni, hogy milyen gyakran előforduló veszélyekre érdemes tervezni, illetve hogy mi kerül többe, a védelmi rendszerek és megoldások kidolgozása, vagy a kár, ami egy adott valószínűség mellett bekövetkező katasztrófahelyzet nyomán előáll. „A biztonság egy tudatos kockázatvállalás” – foglalja össze röviden Kincses, aki szerint már az is elég lenne, ha a tudatosságot elérnénk.

A jól kitalált elmélet gyakorlati működését ugyanis nemcsak a rendszert érő hatás meglepetésszerű mérete akadályozhatja, hanem a szabályok rossz, vagy éppen túl jó alkalmazása. „A németeknél ha a dokumentáció azt mondja, hogy jobbra kell tekerni a balmenetes csavart, akkor ők bizony jobbra tekerik. A japánoknál a nagyon erős beosztott-felettes viszony jelenthet gondot. Itthon az adminisztrációs fegyelem gyengébb a kelleténél, illetve nagyon erős az, hogy mindegy, mit akar a főnök, én így csinálom, mert így akarom, vagy mert így kell, vagy mert így jó, vagy mert csak” – mondja a szakember. De ennél sokkal prózaibb oka is volt már komoly kiesésnek, például hogy az áramkiesés idejére épített dízelgenerátorokat egyszerűen elfelejtették feltölteni, idézi fel egy IT-biztonsági audit meglepő eredményét Kincses.

Nagyon rosszkor, nagyon rossz helyen

Van, ahol egyszerűen csak nagyon rosszkor jött a Sandy hurrikán: a viharban szintén bedőlő Gawker médiabirodalom oldalai is elérhetetlenné váltak, de nem feltétlenül azért, mert csődöt mondott volna a védelmi rendszer. Ahogy Szász Péter, az amerikai cég budapesti munkatársa elmondta, ennél prózaibb volt a helyzet: „Éppen átalakítás alatt van a szerverkörnyezet, amiben futnak az oldalaink, és ebbe csapott bele a Sandy. Kénytelenek voltunk improvizálni.” A Gawker New York-i szervereit gondozó cég csak későn mérte fel, hogy pontosan mekkora veszélyben is vannak a Manhattanben, az evakuációs zóna közepén lévő épületben működő gépek. Az üzemeltető a vihar előtt még nyugodt hangvételű üzenetben csak annyit kért, hogy mindenki mentse el az érzékeny adatokat.

„Számítottunk rá, hogy valamilyen gond lesz, de az üzemeltető optimista volt” – mondja Szász. Aztán amikor mégis beütött a baj, és a kiegészítő generátorok üzemanyag-szivattyúinak helyet adó pincét elárasztotta a betörő víz, a népszerű oldalakat futtató cég technikusainak gyors megoldást kellett találniuk. „Mivel az összes szerverünk elérhetetlen volt, hamar átláttuk, hogy nagy a baj. Ideiglenesen átköltöztettük Tumblrre a blogokat, majd az energiaellátás megoldás után vissza a saját szervereinkre. Volt pár éjszakázás, de mindenki nagyon profin végezte a dolgát” – idézi fel a történteket a Gawker munkatársa. A tanulságokat persze itt is levonják, a már említett átalakítás befejezése után sokkal hibatűrőbb lesz a rendszer, fizikailag több helyre elosztott tartalékokkal.

Működik, csak meghal

A New York-i szerverparkokat, és ezzel együtt a nagyváros egy részét is megtépázó vihar természetesen kevés ahhoz, hogy az internetet magát semmisítse meg, de jól mutatja, hogy van még hova fejlődni biztonság terén. Készült azonban egy olyan grafika is, ami megmutatja a környéken működő szerverek elérhetőségét a vihar alatt. A két napnyi időtávot bemutató mozgóképes ábra is azt bizonyítja, amit a cikk állít: New Yorkot leszámítva a térképen túlnyomórészt zöld, vagyis 99,5 százalékban elérhető szervereket látni, tehát az internet nem hal meg csak azért, mert több forgalmas gép is kiesik. Viszont ha a kiesés hatásait nézzük, már más a helyzet, hiszen a kiesett szolgáltatás felhasználóit világszerte mutatná a térkép.

Az internetes szolgáltatások üzemeltetése ugyanis egyre inkább a hatalmas adatközpontokat látja a tökéletes megoldásnak. Ezek a hatalmas épületek nemcsak a Google-höz hasonló óriásoknak nyújtanak otthont, hanem arra is lehetőség van, hogy a kisebb cégek béreljenek maguknak helyet a szervereiknek. Az ilyen központok általában olyan területeken épülnek, ahol a megfelelően nyugodt természeti környezet mellett a működéshez szükséges infrastruktúra, illetve megfelelő szakembergárda is kéznél van. Azonban önmagában az, hogy egy cég egy adatközpontban helyezi el a gépeit, vagyis „beköltözik a felhőbe”, nem jelent védelmet. A felhőalapú szerverüzemeltetés egyik legnagyobb alakja az itthon inkább csak a könyvüzlet megújításáról ismert Amazon. Csak az elmúlt néhány hónapban többször volt komoly kiesés a cég adatközpontjainak valamelyikében, és emiatt a legtöbbször komoly nevek kerültek bajba.

A Reddit, a Foursquare, vagy épp a TMZ ugyan valójában nem kritikus szolgáltatások, de mindegyiknek megvan a maga néhány millió felhasználója, és október 23-án sokan közülük nem érték el a keresett oldalt, mert gondok támadtak az Amazon észak-virginiai szerverparkjában. A sort még folytathatnánk, az Instagram vagy a Flipboard sem kis játékosok a maguk területén, ráadásul a hiba elemzése kimutatta, hogy egy egészen kis, alig néhány felhasználót érintő hiba dagadt 12 óra alatt akkorává, hogy számottevő kiesésről adjanak hírt a szakportálok. Az Amazon szerint sokat segít ilyen helyzetekben, ha az erőforrásokat az ajánlásoknak megfelelően osztják el és rendszerezik, de ez nem változtat a tényen, hogy két éven belül ezen kívül még kétszer volt említésre méltó megállás.

Az egyik idén júniusban történt, az USA közép-atlanti területein (nagyjából az az északkeleti rész, ahol a Sandy hurrikán is pusztított) tomboló viharok miatt beütő áramszünetek mellé addig ismeretlen hibák és a rendszer tervezése miatt kialakult szűk keresztmetszetek miatt az üzleti szempontból jelentős műsorszolgáltatás, a Netflix is ledöglött. Ennek megfelelően ugyan az Amazon szolgáltatásait igénybe vevő cégek közül csak alig néhányan dőltek meg, a hibában érintett felhasználók száma magas volt: a kiesés a nyugati parton élők esti tévézésébe rondított bele, pénteken.

Egy, az esetet értékelő szakértő, Shahin Pirooz szerint megdöbbentő volt látni, hogy a piacvezető felhőszolgáltató Amazon szerverei kártyavárként omlanak össze. Szerinte a piac többi szereplője sincs teljesen védve a hasonló esetektől. Pirooz véleménye alapján a legjobb megoldás az lenne, ha a megbízók több szolgáltatót is megbízhatnának a rendszereik kezelésével, ahogy azt pédául a net- vagy áramszolgáltatók esetében is teszik. Például alapesetben az Amazonnál fussanak a szerverek, de ha ott valami baj van, a szolgáltatás egy másik cégcsoport adatcentereibe vándorolhatna át, ez azonban még legalább tíz évig csak álom marad, egyrészt a cégek közti rivalizálás miatt, másrészt azért, mert drága hasonló méretű adatközpontokat építeni és fenntartani.

Az internet tehát jól tervezett, az évtizedekkel ezelőtt kitalált módszer a gyakorlatban is jól működik. Már csak azt kell elérni, hogy a bivalyerős hálózat végpontjaiba tett gépek, illetve az azon futó alkalmazások is annak megfelelő szintű bizonyossággal működjenek, amekkora szerepet betöltenek a civilizált világ életében. Például gondoljanak csak bele, mi lesz, ha leáll a Facebook?