High Availability: Jak zajistit dostupnost webu i při výpadku serveru

Výpadek jednoho serveru nemusí znamenat, že web přestane fungovat. Pokud aplikace běží na více nezávislých uzlech a provoz se umí přesunout na zdravou část infrastruktury, může služba pokračovat i při poruše. High Availability ale nevzniká pouhým přidáním druhého serveru. Záložní řešení potřebuje také aktuální data, správné směrování provozu a ověřený postup obnovy.

Co znamená High Availability

High Availability (HA), česky vysoká dostupnost, je návrh systému omezující výpadky a zkracuje dobu, po kterou služba není dostupná. Jednotlivé části infrastruktury se navrhují tak, aby porucha jednoho prvku nevyřadila celý web. Může jít o webové servery, databázi, úložiště, síťové spojení nebo samotné směrování požadavků.

Při plánování je užitečné stanovit dvě hodnoty:

•     RTO (Recovery Time Objective) určuje, jak dlouhý výpadek je ještě přijatelný a za jak dlouho má být služba obnovena.
•     RPO (Recovery Point Objective) říká, kolik dat může být při obnově nejvýše ztraceno, vyjádřeno časem od poslední zachované změny.

Požadavky se liší podle webu. Krátká nedostupnost osobní prezentace má jiné důsledky než výpadek e-shopu nebo objednávkového systému. Zvolené řešení by proto mělo odpovídat dopadu výpadku a požadované rychlosti obnovy.

Jak udržet web v provozu při výpadku

Vysoká dostupnost vyžaduje, aby při poruše jedné části systému dokázaly její práci převzít ostatní. Nestačí proto přidat druhý webový server. Je potřeba zajistit také směrování provozu, dostupnost dat, dostatečnou kapacitu a ověřený postup obnovy. 

1) Rozložte provoz mezi více serverů – aplikace může běžet na několika aplikačních serverech, mezi které požadavky rozděluje load balancer. Pokud jeden server přestane odpovídat, load balancer ho vyřadí a nové požadavky pošle na zbývající uzly. Tím se omezí dopad poruchy jednoho stroje a běžná zátěž se může rozdělit mezi více serverů.

2) Kontrolujte, zda servery skutečně obslouží požadavky – load balancer pomocí health checků pravidelně kontroluje, zda jsou servery dostupné a dokážou obsloužit požadavky. Kontrola může ověřovat například odpověď webové aplikace, nejen připojení počítače k síti. Důležité je nastavit ji tak, aby odhalila skutečný problém, ale nevyřadila server kvůli krátkodobému zpomalení.

3) Počítejte s výpadkem jednoho uzlu – zbývající servery musejí zvládnout převzít provoz po nedostupném uzlu. Pokud na to nemají dostatečný výkon, web může zůstat pomalý nebo nezvládat část požadavků. Při návrhu kapacity proto počítejte s tím, že některý server nebude k dispozici.

4) Zajistěte dostupnost databáze a dalších dat – více webových serverů nepomůže, pokud všechny závisí na jediné databázi. Tu lze replikovat na další uzel, který ji při výpadku převezme. Je ale potřeba počítat s tím, že při asynchronní replikaci se nemusí přenést poslední změny, zatímco synchronní může zpomalit zápisy. Stejně tak musí být dostupné soubory a uživatelské relace, například díky sdílenému úložišti a ukládání relací mimo jednotlivé servery.

5) Oddělte záložní části od společných rizik – dva servery ve stejné lokalitě může současně zasáhnout výpadek napájení, sítě nebo datacentra. Pokud má řešení chránit i před podobnou událostí, je vhodné umístit kritické komponenty do oddělených zón či lokalit. Zkontrolujte také méně nápadné závislosti, například jediný load balancer, společné úložiště, DNS, přihlašovací službu nebo externí API. Každá část, jejíž výpadek může zastavit celý web, představuje samostatné riziko.

6) Berte DNS failover jako jednu část řešení – při výpadku celé lokality může DNS služba začít vracet adresu jiného, zdravého endpointu. Přesměrování ale nemusí být okamžité pro všechny návštěvníky. DNS odpovědi se ukládají do mezipamětí a jejich platnost ovlivňuje TTL. Proto je potřeba ověřit, jak se v praxi chová použitá DNS služba i resolvery návštěvníků, a změřit dobu potřebnou k přepnutí.

7) Kombinujte vysokou dostupnost se zálohováním – replika může při poruše převzít aktuální data, ale může převzít také nechtěné smazání nebo poškození. Záloha umožňuje obnovit starší stav, její obnovení však může trvat déle. Ukládejte ji odděleně od produkčního prostředí a pravidelně ověřujte obnovu celého webu včetně databáze, souborů a konfigurace.

8) Pravidelně testujte přepnutí i návrat do běžného provozu – v testovacím prostředí nebo podle připraveného plánu ověřte, co se stane při výpadku aplikačního serveru, databázového spojení nebo celé lokality. Sledujte, zda health check problém rozpozná, jak rychle se provoz přesune jinam a zda aplikace po přepnutí pracuje s aktuálními daty. Ověřte také doručování upozornění a postup návratu do původního provozu. Testy pomohou zjistit skutečné hodnoty RTO a RPO i odhalit chybějící přístupy, zastaralou konfiguraci nebo nedostatečnou kapacitu.

High Availability nevzniká jediným opatřením, ale spoluprací všech částí infrastruktury. Rozsah řešení by měl odpovídat tomu, jak dlouhý výpadek a případnou ztrátu dat si web může dovolit. Pravidelné testování pak ověří, zda záložní servery, replikace i postup obnovy fungují podle očekávání.

Dostupnost se navrhuje podle dopadu výpadku

Vysoká dostupnost neznamená, že každá část infrastruktury musí mít okamžitou kopii v jiné lokalitě. Takové řešení zvyšuje náklady i složitost. Nejprve je proto vhodné určit, jak dlouhý výpadek a jakou případnou ztrátu dat si provoz může dovolit. Poté lze vybrat odpovídající kombinaci více aplikačních uzlů, replikace databáze, geografického oddělení a zálohování.

Pro některé weby postačí kvalitní zálohy a ověřený postup obnovy. U služeb, kde i krátké přerušení znamená významnou ztrátu, dává smysl automatické přepínání mezi redundantními uzly. 

Při návrhu vlastní infrastruktury lze využít například cloudové servery ZonerCloudu. Samotný pronájem serveru však vysokou dostupnost nezaručuje. Rozhodující je architektura celého řešení, nezávislost jeho částí a pravidelné testování.