Azure Availability Zones: ako navrhnúť odolnosť bez falošných istôt

Firma presunie aplikáciu do Azure, vyberie región a očakáva, že cloud automaticky vyrieši každý výpadok. Práve tu vzniká nebezpečná skratka. Azure poskytuje odolnú platformu a v mnohých regiónoch aj Availability Zones, no odolnosť konkrétnej aplikácie závisí od zvolených služieb, ich režimu, počtu inštancií, dátovej replikácie, smerovania, testov a obnovy.

Availability zone je logická skupina jedného alebo viacerých fyzicky oddelených dátových centier v rámci jedného Azure regiónu. Každá zóna má nezávislé napájanie, chladenie a sieťovú infraštruktúru. Cieľom je obmedziť spoločný dopad lokálneho zlyhania, nie chrániť automaticky pred výpadkom celého regiónu.

Región, zóna a dátové centrum nie sú to isté

Azure región je geografická oblasť, v ktorej Microsoft prevádzkuje infraštruktúru. Región môže podporovať Availability Zones, ale nemusí. Jedna zóna môže obsahovať jedno alebo viac fyzických dátových centier. Zóny sú od seba fyzicky oddelené a prepojené výkonnou sieťou, aby mohli podporovať nízku latenciu a odolnosť voči zlyhaniu jednej zóny.

Z toho nevyplýva, že ľubovoľný resource v regióne automaticky beží vo viacerých zónach. Podpora sa líši podľa služby, regiónu, vrstvy alebo SKU a spôsobu konfigurácie. Pred návrhom treba otvoriť reliability guide konkrétnej služby, nie sa spoliehať na všeobecnú vlastnosť regiónu.

Zonal a zone-redundant: rozdiel v zodpovednosti

Zonal resource

Zonal resource je nasadený do jednej zóny, ktorú zákazník vyberie. Získava izoláciu od chýb v iných zónach, ale sám osebe nie je odolný voči výpadku svojej zóny. Ak firma používa napríklad virtuálne stroje v zonal režime, musí navrhnúť viac inštancií vo viacerých zónach, distribúciu prevádzky a postup failoveru.

Zone-redundant resource

Pri zone-redundant službe zabezpečuje rozloženie a replikáciu naprieč zónami samotná služba. Pri výpadku zóny Microsoft riadi failover pre daný resource. Ani tu však nemožno preskočiť kontrolu požadovanej vrstvy, kapacity, dátovej konzistencie a závislostí. Aplikácia je odolná iba tak, ako jej najslabšia súčasť.

Jeden zone-redundant komponent neurobí odolnou aplikáciu, ktorej databáza, DNS, tajomstvá alebo jediná virtuálna mašina zostali bez zónovej stratégie.

Praktický príklad firemnej aplikácie

Predstavme si interný objednávkový portál s webovou vrstvou, API a databázou. Web a API bežia na viacerých inštanciách rozdelených medzi podporované zóny a prevádzku smeruje load balancer s podporou zónovej odolnosti. Databáza používa podporovanú zone-redundant konfiguráciu. Logy a metriky sledujú dostupnosť každej vrstvy.

Takýto návrh má zmysel iba vtedy, keď tím overí aj správanie počas zlyhania: či health probe odstráni nefunkčnú inštanciu, či databáza prejde na zdravú repliku, či aplikácia zvládne krátke prerušenie spojenia a či zostáva dostatočná kapacita. Test má používať bezpečný neprodukčný scenár alebo riadené cvičenie s jasným návratom.

Availability Zones nechránia pred výpadkom celého regiónu. Pri mission-critical aplikácii Microsoft odporúča zvážiť architektúru s viacerými zónami aj regiónmi. Ak firma z dôvodu rezidencie dát alebo suverenity nemôže používať druhý región, musí túto hranicu pomenovať a skombinovať zónovú odolnosť so zálohou a obnovou podľa realistických RTO a RPO.

Ako overiť podporu zón v predplatnom

Microsoft upozorňuje, že čísla logických zón sa medzi Azure subscriptions môžu mapovať na odlišné fyzické zóny. Ak architektúra spája viac predplatných, nemožno automaticky predpokladať, že „zóna 1“ znamená rovnakú fyzickú zónu v oboch.

Aktuálne mapovania dostupných lokalít pre konkrétne predplatné možno načítať zdokumentovaným príkazom Azure CLI:

az account list-locations --query "[?availabilityZoneMappings].{availabilityZoneMappings: availabilityZoneMappings, displayName: displayName, name: name}"

Príkaz iba číta metadáta lokalít. Neoveruje, či konkrétna služba a SKU podporujú požadovaný režim, ani či aplikácia správne failoveruje. Ďalším krokom je preto kontrola reliability guide každej použitej služby a reálneho nasadenia.

Zóny nie sú záloha ani plán obnovy

Replikácia medzi zónami zvyšuje dostupnosť, ale môže rýchlo preniesť aj logickú chybu, nechcené vymazanie alebo poškodenie dát. Záloha má odlišný účel: uchovať obnoviteľný bod podľa politiky retencie a umožniť návrat po incidente. Firma potrebuje oboje, ak to vyžaduje význam služby.

Rovnako dôležité je poznať prevádzkové ciele. RTO určuje, za aký čas má byť služba obnovená; RPO určuje, aká strata dát v čase je ešte prijateľná. Tieto hodnoty nie sú vlastnosťou marketingového názvu služby. Musia vychádzať z dopadu na podnikanie a byť overené testom.

Kontrolný zoznam pred rozhodnutím

• Je vybraný región so zónami a podporuje ich každá kritická služba a SKU?
• Ktoré resources sú zonal, zone-redundant alebo iba regional?
• Sú výpočtové inštancie, dáta, load balancing, tajomstvá a monitoring navrhnuté ako jeden reťazec?
• Čo sa stane s kapacitou a výkonom po strate jednej zóny?
• Je failover automatický alebo ho musí riadiť aplikácia či administrátor?
• Ako sa rieši výpadok celého regiónu a aká hranica vyplýva z rezidencie dát?
• Existuje samostatná záloha, retencia, RTO, RPO a otestovaný restore?
• Bol test zlyhania zdokumentovaný bez zásahu do produkčných dát?

Pri návrhu Azure infraštruktúry pre firmu vie Yenwa zmapovať závislosti aplikácie, preveriť podporu zón, navrhnúť kapacitu po výpadku a pripraviť test failoveru aj obnovy. Výsledkom nemá byť všeobecný sľub „beží to v cloude“, ale architektúra s jasne pomenovanými hranicami a dôkazom, že splní dohodnutý cieľ.