Plánovaná odstávka datového centra vedla k neplánovanému výpadku služeb Seznamu

Testování datových center za plného provozu v dopolední špičce má svoje důvody a genezi. Samotné testování je snad jediný účinný způsob, jak si ověřovat, že v praxi funguje z hlediska zabezpečení provozu vše, na co firma spoléhá a do čeho investuje čas a peníze s cílem dosahovat vysoké provozní dostupnosti svých služeb.

Poslední dva roky Seznam zasvětil pravidelnému testování pod skutečnou zátěží. To postupně vedlo k tomu, že dnes za běžných okolností uživatelé odstávku datového centra významně nepocítí, protože všechny služby běží více méně v pořádku.

„I tentokrát vše vypadalo bezproblémově. Z prvních hlášení vyplynulo, že trochu zazlobilo Počasí.cz, kde zřejmě šlo jen o konfigurační chybu, kterou tento test odhalil. Za běhu to bylo napraveno. Krátce před 11. hodinou byl ohlášen návrat do normálu. Obvykle by tím vše skončilo a pár lidí by suše konstatovalo, že to bylo opět bez potíží. Jenže nebylo,“ popisuje situaci Vlastimil Pečínka, technický ředitel Seznam.cz. Prvním reportem byla hlášena nedostupnost firemního intranetu, e-mailu a kalendáře, následovalo hledání. To bylo přisuzováno možnému flapování po připojení odstavených služeb. Nicméně zhruba od 11:11 hodin už bylo víc a víc jasné, že se děje něco s DNS – začal hromadný report nefungujících služeb.

Co se tedy stalo?

Je ještě brzy na definitivní závěry, je však možné popsat první kámen, který vypadl z přehrady a způsobil protržení hráze s následnou záplavou. Po připojení odstavené Kokury v relativně krátké době přestal fungovat interní resolving doménových jmen. Tedy přestaly fungovat takové technické věci jako „jaká je IP adresa databázového serveru XYZ“ nebo „kde leží aplikace ABC, kterou potřebuji spustit, protože aplikaci začalo používat více uživatelů“? Důvody, proč to přestalo fungovat, musí zástupci firmy důkladně zanalyzovat. Infrastruktura se ocitla pod palbou vlastních komponent a aplikací v nich běžící, které se opakovaně a neúnavně doptávaly, „jaká je IP adresa …?“, začaly se plnit fronty a celý cloud de facto zamrzl. Komponent, které se dokola najednou ptaly, byly vysoké statisíce. Smrtící jistě bylo, že se začaly víceméně ptát všechny najednou, protože jim vypršely časy, po které si pamatují předchozí odpovědi. Nekrátký čas stálo toto identifikovat a pak se snažit proud dotazů od statisíců komponent a agentů „usměrnit“ (aby se neptaly nebo aby se jejich dotazy zahodily a odhlásilo se tak DNS resolvingu).

Situaci kolem DNS resolvingu se podařilo stabilizovat kolem 13:08 hodin, tedy zhruba po dvou hodinách boje s valící se vodou z přetržené hráze. Ale vyhráno nebylo. V důsledku problémů s resolvingem stačily „popadat“ různé aplikace, včetně těch důležitých infrastrukturních. A bohužel nemohly naběhnout, protože nebylo k dispozici úložiště s aplikacemi (kontejnery). Identifikace příčiny a rozjetí trvalo přes další hodinu (týmy bojovaly zejména s kruhovou závislostí jednotlivých komponent a muselo se to rozjíždět manuálně). Rozjetím úložiště se pak již začalo vše vracet do normálu, ve 14:44 hodin vypadala situace zvenku na návrat k normálu a v 15:14 hodin byla odvolána pohotovost.