Nikdy bych si nemyslel, že budu psát tyto řádky – ale poté, co jsem nedávno na vlastní kůži zažil sílu matky přírody, dospěl jsem k závěru, že tohle stojí za zveřejnění. Než se dostanu k věci, musím na rovinu říci, že jsem právě zažil stresující, vyčerpávající a neuvěřitelně dlouhé čtyři dny. Většina firem v této době už má nějaké plány pro zotavení po katastrofě, ale dokud tu katastrofu opravdu nezažijete, nikdy nebudete vědět, jak to proběhne ve skutečnosti. Já už to vím.
Nejprve bych tu pro nezasvěcené rád krátce shrnul extrémy počasí, které nás na severovýchodě USA nedávno potkaly. Zažili jsme nejvlhčí léto, jaké tu kdo pamatuje. Nevyhnuly se nám ani extrémní deště, ani hurikány, ani tropické bouře, ani přívalové deště, které zemi zahltily i deseticentimetrovým sloupcem vody během dvaceti minut. Nedávno jsme tu dokonce měli i slabé zemětřesení. Takové podmínky v naší oblasti rozhodně nejsou běžné.
Každá firma, ať už se nachází kdekoli, je vystavena určitému riziku. Můžete
Oko hurikánu, foto: NASA mít datové centrum v nejlepší možné lokalitě, ale stejně se nevyhnete všem hrozbám. Stačí třeba nehoda cisterny s benzínem nebo převrácený náklaďák s chlorem poblíž vašeho areálu... Všichni také považujeme za jistou existenci elektrické sítě nebo vysokorychlostního připojení k internetu – páteřních sítí, které dosud nezažily velký výpadek – ale jak vám řekne nejeden síťový specialista, jednou k tomu velkému výpadku jistě dojde.
V neděli 27. srpna jsme s mou ženou seděli na mezinárodním letišti Newark a čekali na let do Las Vegas, kde za pár dní začínala konference VMworld 2011. V posledních dnech se všude mluvilo jen o hurikánu Irena – a my jsme měli letět posledním spojem na západ před tím, než bude letiště kvůli počasí uzavřeno.
Osobně vždy sleduji počasí na východním pobřeží USA velmi pozorně. Jednak mě baví sledovat radarové snímky a počítačem generované grafy vývoje, jednak potřebuji vědět, co se děje v místech, kde máme pobočky. Je jich celkem 6 a ve většině z nich nemáme příliš serverů – je tam především síťová infrastruktura, která požadavky uživatelů směruje do centrály. Tentokrát jsou na trase hurikánu – jednoho z nejsilnějších, který v posledních letech v této oblasti udeřil – čtyři ze šesti poboček – New York City, Virginia, New Jersey a New Hampshire.
Když jsem přiletěl do Las Vegas, měl jsem sevřený žaludek a celý víkend jsem nebyl schopen myslet na nic jiného, než na silný vítr a déšť, kterým jsou naše pobočky vystaveny. Do neděle večer naše centrála ve Scrantonu (Pensylvánie) schytala devět centimetrů vody a stále lilo – a mělo pršet až do pondělního rána. Takový déšť by nevadil, pokud by neexistovalo cosi, co se jmenuje Susquehanna - řeka, před kterou nás má chránit 12metrová hráz, která se nachází jen nějakých 30 metrů od naší centrály s hlavním datovým centrem. Tato zábrana byla vybudována armádou USA jako reakce na záplavy z roku 1972 způsobené hurikánem Agnes; tehdy šlo o nejhorší přírodní katastrofu v historii Pensylvánie.
V minulosti hráz vydržela už lecjakou zkoušku... A ani tentokrát nás nic zlého nepotkalo. Alespoň po dobu, kdy jsem byl v Las Vegas.
V týdnu, kdy jsem se vrátil z VMworldu, jsem byl unavený, ale chtěl jsem otestovat ESXi 5 a připravit nějaké plány na třetí čtvrtletí. Netušil jsem, že právě toto bude nejdrsnější týden mého života – i kariéry. Až do středy 7. září, to tak vlastně ani nevypadalo.
Předpověď počasí se opět zhoršovala s každým novým snímkem z radaru. Blížilo se k nám několik bouří, z nichž některé byly poměrně silné. Dalo se čekat, že na severu Pensylvánie i státu New York spadne velké množství srážek – přes 20 centimetrů, což může znamenat problém. V této oblasti je řada přehrad, říčních systémů, protipovodňových ventilů a další infrastruktury, bez níž by každé město od Syrakus po Filadelfii čekaly povodně. Část z těchto systémů ústí do řeky Susquehanna, jejíž hladinu zvedly už předchozí deště.
V naší organizaci máme definovány tři úrovně katastrofy:
Stupeň 1: Evakuace oblasti v okolí datového centra a dalších budov (při stoupající řece, chemickém zamoření apod.). Šance? 8 z 10. Toto je naše "typická katastrofa". Práce pokračují v náhradní lokalitě (disaster recovery site), provoz je směrován přes VPN a 100MB linku do centrály.
Stupeň 2: Dočasné přerušení spojení s centrálou (výpadek napájení, stoupající řeka, která si vynutí odpojení, nebezpečné chemikálie apod.). Šance? 3 z 10.
Stupeň 3: Kompletní ztráta konektivity do centrály, kompletní ztráta systémů na neurčitou dobu (katastrofa v regionu nebo v celém státě, katastrofická ztráta budovy). Šance? 1 z 10.
Tentokrát jsem se dostal do stupně 2,5. Nutno dodat, že naši náhradní lokalitu jsem navrhl a zařídil tak, abychom byli schopni řešit stupně 1 a 2. Proč ne 3? Prostě kvůli nedostatku času. Zajistil jsem konektivitu, což samo o sobě trvalo déle, než jsem čekal, navrhl záložní řešení pro virtuální stroje a přitom řešil upgrade i v našem hlavním datovém centru. To, že jsme byli schopni zvládnout i stupeň 2,5, považuji za slušný úspěch – obzvlášť když ještě před devíti měsíci žádný disaster recovery plán neexistoval.
Byl čtvrtek 8. září, 8:30 ráno. Toto datum si budu pamatovat navždy. Sledoval jsem počasí a vše nasvědčovalo tomu, že už tak vysoká hladina řeky bude i nadále stoupat. Vzhledem k její výšce jsem dospěl k závěru, že je na čase začít se připravovat na katastrofu – a řešit disaster recovery. Tušil jsem, že odteď se nejméně 48 hodin nevyspím – a nebyl jsem daleko od pravdy.
Sáhnul jsem po našem plánu pro zotavení po katastrofě. Byl jsem si jistý, že bude fungovat pro stupně jedna a dva. Dojde-li k nejhoršímu, budu to muset nějak vyřešit.
Nejprve jsem naložil několik nejdůležitějších serverů do svého Jeepu. Byly to ty, které jsem neměl v záložní lokalitě – potřeboval jsem některé záložní obrazy systémů, záložní hardware a pár páskových jednotek. To, že jsem si tento hardware vzal s sebou, jsem později vyhodnotil jako jeden z nejšťastnějších kroků, které jsem učinil. Kluci, kteří mají na starosti desktopové počítače, naložili do dodávky pracovní stanice a připravili se na přejezd do záložní lokality, která je naštěstí jen 25 minut jízdy odsud – na kopci.
Jakmile jsme tam přijeli, nastal čas řídit se pokyny plánu pro stupeň jedna, což bylo jednoduché. Nebudu vás nudit detaily – v záložní lokalitě je připravena síť, kterou stačí připojit k lince do hlavního datového centra. Pak tu může pracovat nějakých 30 až 40 lidí na běžném hardwaru a softwaru. A tak to také fungovalo až do páté odpoledne, kdy jsme se dozvěděli, že řeka kulminuje na 12 metrech a energetická společnost vypne dodávku elektřiny v okolí řeky. Nastává řízená panika – a my přecházíme na stupeň dva.
Byl jsem na takovou možnost připraven, ale rozhodně jsem neměl touhu své plány realizovat v praxi. Stupeň dva znamená ztrátu konektivity do centrály, což je velmi blízko nejhoršímu scénáři. Plánoval jsem to, testoval jsem to, ale když se to skutečně stalo, bylo to něco úplně jiného.
Pro ochranu virtuálních strojů a virtuální infrastruktury používám Veeam Backup and Replication 5.0. V záložní lokalitě jsme měli tři servery Dell R710 s 48 GB RAM připojené ke třem úložným zařízením s 5 TB prostoru (založeným na open source Openfiler 2.99). A měli jsme 15 replikovaných virtuálních strojů připravených pro okamžité spuštění – včetně domain controllerů, některých serverů pro sdílení souborů, serverů Exchange, SQL a dalších. Slabým článkem byl chybějící systém pro replikaci od EqualLogic, kterému do implementace scházelo už jen několik měsíců, když jsem přišel o potřebné finance. Bez jeho nasazení bylo naše řešení nekompletní a provizorní. Nicméně i náš stávající systém byl schopen zajistit běh základních služeb.
Velmi brzy jsem zjistil, že hlavní slabinou našeho plánu pro zotavení po katastrofě je jeho často přehlížená složka – totiž komunikace. Nemám na mysli e-mail, SMS nebo telefony, ale komunikaci mezi státními i lokálními úřady a vedením firem v dotčených oblastech. Skutečnost, že ve skutečnosti nikdy nedošlo k přerušení dodávek elektřiny v naší centrále, nebo že jsme se nikdy spolehlivě nedozvěděli, jaká je aktuální výška řeky, nás vedla ke špatným rozhodnutím.
Ve čtvrtek v noci jsem s pomocí Veeam Replication v kombinaci s VMware Migrations kompletně převedl aktivity datového centra na záložní servery. K tomu zřejmě vůbec nemuselo dojít. Tehdy jsem to ale samozřejmě nevěděl. Naše e-maily, webové aplikace, IIS, intranet a aplikace pro core business (ty, které dosud nejsou v cloudu) normálně běžely v záložní lokalitě. Což považuji docela za úspěch, vzhledem k tomu, že nám spánkový deficit situaci rozhodně neusnadňoval.
Dobrou zprávou je, že nebyla ztracena jediná transakce a firma normálně fungovala. To dokazuje, že disaster recovery byla úspěšná. V sobotu dopoledne jsem se pak dozvěděl, že voda v řece kulminovala na třinácti metrech, takže snad jen zázrak zachránil město před nejhorší záplavou v historii severovýchodní Pensylvánie.
Na závěr bych tu měl několik doporučení pro IT oddělení i pro všechny, kdo jsou zodpovědní za plány pro disaster recovery:
Autorem tohoto textu je Jonathan Franconi, odborník na virtualizaci a správce sítě jedné firmy v severovýchodní Pensylvánii (USA). Ve svém volném čase poskytuje konzultace ohledně virtualizace i dalším společnostem. Franconi publikuje na svém blogu VirtualizationImpact. Původní text byl pro publikování na BusinessIT.cz se souhlasem autora přeložen, redakčně upraven a zkrácen.
Možná je to laciné, možná podbízivé, možná až nevkusné, ale nemohli jsme odolat: Některé příběhy lidí z IT, které jsme...
