Spolehlivost

Dokončeno

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

1.

Předpokládejme, že chcete zvýšit dostupnost systému a vašim zákazníkům poskytovat lepší smlouvu o úrovni služeb (SLA). Které z následujících možností jsou hlavním principem, který můžete použít?

2.

Na které z následujících možností by měl vliv vámi definovaný cíl bodu obnovení (RPO)?