Spolehlivost
Představte si, že provozujete klinický systém pro zdravotnickou organizaci. Lékařský a pečovatelský personál příliš netoleruje výpadky. Potřebuje mít neustálý přístup ke klinickým IT systémům, aby měl jistotu, že v kterémkoli okamžiku poskytuje péči nejvyšší kvality.
Aby se vyhovělo požadavku lékařů na trvalou dostupnost, musí být aplikace schopné zvládat selhání s minimálním dopadem na uživatele. Jak zajistit provozuschopnost aplikací, a to jak v případě lokálních incidentů, tak v případě rozsáhlých havárií?
V této lekci se dozvíte, jak do návrhu architektury začlenit prvky z pilíře spolehlivosti.
Co je spolehlivost?
U složitějších aplikací se může zvrtnout úplně cokoli a v libovolném měřítku. Mohou selhat jednotlivé servery nebo pevné disky. Problém s nasazením by mohl nechtěně vést k odstranění všech tabulek v databázi. Celá datacentra mohou přestat být dostupná. Mohlo by dojít k napadení ransomwarem, který by vám zlomyslně zašifroval všechna vaše data. Je důležité, aby vaše aplikace zůstala spolehlivá a dokázala zvládnout jak lokální incidenty, tak incidenty s rozsáhlým dopadem.
Navrhování s ohledem na spolehlivost spočívá v udržování provozuschopnosti během incidentů v malém měřítku a dočasných podmínek, jako jsou částečné výpadky sítě. Zvládnutí lokálních selhání můžete zajistit integrováním vysoké dostupnosti do jednotlivých komponent aplikace a eliminováním kritických prvků způsobujících selhání. Takový návrh také minimalizuje dopad údržby infrastruktury. Záměrem návrhů s vysokou dostupností je zpravidla rychle a automaticky eliminovat dopad incidentů a zajistit, aby systém dál zpracovával žádosti s malým nebo nulovým dopadem.
Návrh zohledňující spolehlivost se zaměřuje také na zotavení ze ztráty dat a rozsáhlejších havárií. Zotavení z těchto typů incidentů obvykle vyžaduje aktivní zásah, přestože postupy pro automatické zotavení mohou dobu potřebnou k zotavení zkrátit. Tyto typy incidentů mohou vést k určitým výpadkům nebo k trvalé ztrátě dat. Zotavení po havárii je nejen otázkou pečlivého plánování, ale také otázkou provedení takového plánu.
Zahrnutí vysoké dostupnosti a obnovitelnosti do návrhu architektury chrání vaši firmu před finančními ztrátami vyplývajícími z výpadků a ztráty dat. Zajišťuje také, že kvůli ztrátě důvěryhodnosti neutrpí vaše dobrá pověst u zákazníků.
Návrh architektury s ohledem na spolehlivost zajišťuje, že vaše aplikace dokáže plnit závazky vůči zákazníkům. To znamená, že vaše systémy jsou dostupné koncovým uživatelům a dokážou se zotavit ze všech selhání.
Vytvoření vysoce dostupné architektury
Pro zajištění dostupnosti identifikujte smlouvu o úrovni služeb (SLA), k jejímuž dodržování se zavazujete. Zkontrolujte potenciální možnosti vysoké dostupnosti aplikace vzhledem ke smlouvě SLA a zjistěte, kde jste schopni je splnit a kde bude potřeba něco vylepšit. Vaším cílem je přidat do komponent architektury redundanci, aby se snížila pravděpodobnost výpadku.
Příkladem komponent s návrhem vysoké dostupnosti je třeba clustering a vyrovnávání zatížení:
Clustering nahrazuje jeden virtuální počítač sadou koordinovaných virtuálních počítačů. Pokud jeden virtuální počítač selže nebo je nedostupný, služby převezme jiný, který žádosti dokáže obsluhovat.
Vyrovnávání zatížení rozděluje žádosti mezi mnoho instancí služby, detekuje instance, které selhaly, a zabraňuje tomu, aby na ně byly směrovány žádosti.
Vytvoření architektury, která se dokáže zotavit ze selhání
Při posuzování zotavitelnosti byste měli provést analýzu možných scénářů ztráty dat a závažných výpadků. Součástí analýzy by u každého z těchto scénářů mělo být prozkoumání strategií zotavení a kompromisů z hlediska nákladů. Toto cvičení vám poskytne důležitý přehled o prioritách vaší organizace a pomůže vám vyjasnit si roli vaší aplikace. Výsledky by měly obsahovat:
Cíl bodu obnovení (RPO): Maximální přijatelná doba trvání ztráty dat. RPO se měří v časových jednotkách, nikoli v objemových jednotkách. Příkladem je „30 minut dat“, „čtyři hodiny dat“ atd. RPO se týká omezení ztráty dat a zotavení z ní, ale netýká se odcizení dat.
Cíl doby obnovení (RTO): Maximální přijatelná doba výpadku, kde „výpadek“ je definován ve specifikaci. Pokud je třeba v případě havárie přijatelná doba výpadku 8 hodin, bude cíl doby obnovení 8 hodin.
Po definování cíle bodu obnovení a cíle doby obnovení můžete pro svou architekturu navrhnout funkce zálohování, obnovení, replikace a zotavení tak, aby tyto cíle byly splněny.
Každý poskytovatel cloudových služeb nabízí sadu služeb a funkcí, které vám pomohou zlepšit dostupnost a obnovitelnost aplikace. Pokud je to možné, použijte existující služby a osvědčené postupy a zkuste odolat pokušení vytvářet si svoje vlastní.
Mohou selhat pevné disky, datová centra nemusí být dostupná a může dojít k útoku hackerů. Je důležité si pomocí dostupnosti a obnovitelnosti zachovat dobrou reputaci u zákazníků. Dostupnost se zaměřuje na zachování provozuschopnosti během situací, jako jsou výpadky sítě, a zotavitelnost se zaměřuje na získání dat po havárii.
Prověřte své znalosti
Potřebujete pomoc? Projděte si našeho průvodce odstraňováním potíží nebo nahlaste potíže a uveďte konkrétní připomínky.