Výpadek clusteru virtuálních serverů – přehled situace a řešení

Dnes došlo k výpadku části cloudové infrastruktury, která zajišťuje provoz virtuálních serverů. V tomto článku popisujeme, co se stalo, jak jsme situaci řešili, proč obnova trvala tak, jak trvala, a jaké kroky děláme, aby se podobná situace neopakovala.

Naším cílem je být v komunikaci otevření – i tam, kde je téma nepříjemné. Zároveň jsme při řešení museli upřednostnit jednu věc před druhou: bezpečnost a konzistenci vašich dat před rychlostí obnovy. Níže vysvětlujeme, proč.

Co se stalo

V naší infrastruktuře běží několik tzv. monitorovacích a řídicích uzlů, jejichž úkolem je průběžně ověřovat stav clusteru a rozhodovat o tom, kde a jak budou data dostupná. Tyto uzly spolu nepřetržitě komunikují a potřebují se shodnout („dosáhnout kvóra“) na tom, že všechno běží tak, jak má.

Jeden z těchto uzlů se dostal do stavu, kdy začal opakovaně vykonávat tutéž operaci v nekonečné smyčce a tím výrazně zatížil i ostatní uzly. Ostatní části systému pak nestíhaly v reálném čase potvrzovat stav clusteru, a systém z bezpečnostních důvodů přešel do ochranného režimu – tedy omezil provoz služeb, aby nemohlo dojít k nekonzistenci dat.

Jde o izolovanou provozní událost v řídicí vrstvě clusteru, nikoliv o poškození samotných dat nebo selhání datové vrstvy. Uživatelská data byla po celou dobu v pořádku.

Průběh incidentu

Proč výpadek trval déle, než by se na první pohled mohlo zdát

Samotné odstranění příčiny zabralo pouze část času. Významnou část výpadku tvořila kontrola integrity dat, která v našem prostředí trvala přibližně hodinu.

Tento krok je nutný a neumíme ho přeskočit, i kdybychom chtěli. Během kontroly integrity jsme museli služby záměrně ponechat offline, a to ze tří důvodů:

• aby nemohlo dojít k poškození dat zápisem do nekonzistentního stavu,
• aby data zůstala identická napříč všemi replikami v celém clusteru,
• aby samotná obnova proběhla kontrolovaně a ověřitelně.

Z pohledu uživatele se výpadek může jevit jako dlouhý. Z pohledu provozovatele ale platí, že čas strávený kontrolou integrity je investice do toho, aby po obnově nebyla žádná data ztracená, rozbitá nebo nekonzistentní. Alternativa – spustit služby rychleji za cenu rizika poškození dat – není alternativou, kterou bychom chtěli svým klientům nabídnout.

Proč jsme vám během výpadku nesdělovali přesný čas obnovy

Během incidentu jsme se snažili informovat průběžně, ale úmyslně jsme nedávali konkrétní odhady času do plné obnovy. Přesná predikce času je v průběhu živého incidentu téměř vždy nepřesná – dokud neznáte kompletní rozsah příčiny, jakýkoliv odhad je buď příliš optimistický (a tím ještě víc frustrující, když se nesplní), nebo defenzivně přehnaný.

Raději jsme sdíleli skutečný stav a podniknuté kroky, než čísla, která bychom si nemohli garantovat.

Proč Ceph a cloudová infrastruktura i navzdory této události

Je na místě otázka: „Když se tohle může stát, není lepší mít data na jednom dedikovaném serveru?“ Odpověď je ne, a rádi vysvětlíme proč.

Tato událost se týkala řídicí vrstvy clusteru, tedy komponent, které koordinují provoz. Samotná datová vrstva Ceph zůstala po celou dobu konzistentní a bez poškození dat – přesně proto byl ochranný mechanismus, který způsobil dočasné omezení provozu, nutný.

Ve srovnání s provozem na jednom fyzickém serveru přináší Ceph cluster zásadní výhody, které se projevují ve dlouhodobém součtu dostupnosti:

• Žádný jediný bod selhání – výpadek disku, RAM, základní desky nebo zdroje v jednom uzlu neznamená výpadek služby. U dedikovaného serveru by stejná hardwarová závada znamenala okamžitou a často několikahodinovou odstávku.
• Data jsou replikována napříč více uzly, takže selhání jednoho kusu hardwaru neohrozí jejich dostupnost.
• Opravy a údržba probíhají online – přidání kapacity, výměna disku nebo migrace dat nevyžadují vypnutí služby. U dedikovaného serveru je každá taková operace spojená s odstávkou.
• Rychlejší obnova po hardwarovém incidentu – v cloudu jde o minuty, u dedikovaného serveru typicky hodiny (diagnostika, objednání náhradního dílu, výměna, znovunasazení systému, obnova ze zálohy).

Jinými slovy: cloudová architektura minimalizuje četnost a délku výpadků, ale za cenu toho, že v ojedinělých případech řeší výpadky i na úrovních, které u jednoho fyzického serveru neexistují. Celkový součet dostupnosti je ale výrazně vyšší.

Aktuální stav

Infrastruktura je stabilizovaná a navrácena do plného provozu. Probíhá zvýšený monitoring všech komponent clusteru. Aktuální dostupnost služeb můžete kdykoliv sledovat na status.wp-hosting.cz.

Omluva a poděkování

Za dnešní výpadek se upřímně omlouváme. Vážíme si toho, že jste nám svěřili provoz svých služeb, a každou takovou situaci bereme velmi vážně – jak po technické stránce, tak ve vztahu k vám jako klientům.

Zvolená architektura nám dlouhodobě umožňuje držet vysokou dostupnost a dnešní incident je prvním takto dlouhým výpadkem za poslední tři roky provozu. Desítky hodin výpadků, které by u klasických dedikovaných serverů proběhly jako „běžný servisní zásah“, cloudová infrastruktura postavená na Ceph odbaví bez přerušení služeb. To dnešní nepříjemnost neomlouvá, ale je to kontext, který je férové zmínit.

Vaši zpětnou vazbu i trpělivost během dnešního řešení si ceníme a bereme vážně – i ona nám pomáhá dělat naše služby spolehlivější.