CIA: Dostupnost

Dostupnost je nejčastěji definována jako zajištění, že informace je pro oprávněné uživatele přístupná v okamžiku její potřeby.

O zničení (destruction) určitých informací se v informační bezpečnosti hovoří jako o narušení jejich dostupnosti (availability). Co to ale znamená, když výrobce u svého systému uvádí dostupnost 99,999%? Pokud jako základ vezmeme 365 dní v roce, tak jednoduchým výpočtem zjistíme, že systém může být až 5 minut za rok nedostupný.

Na první pohled se zdá, že dostupnost symbolizovaná pěti devítkami je dostatečná, musíme si ale uvědomit, že systémem se zde dost často myslí jen samotný HW, nikoliv operační systém a aplikace. U operačních systémů a aplikací se tyto parametry záměrně neuvádí a jejich výrobce radši žádné záruky ani neposkytuje nebo se omezuje na lakonické prohlášení, že systém je navrhnut pro běh 99,999%. Nicméně jsou to především OS a aplikace a v některých případech i síť, které dost často bývají hlavní příčinou nedostupnosti většiny IS. Nedostupnosti, která zdaleka překračuje výše proklamovanou hodnotu. A uživateli IS je víceméně jedno, co je onou příčinou, pro něj je nedostupný systém resp. jeho služby, kterých využívá.

Ač je populární uvádět dostupnost systému v % za rok, je mnohem přesnější a praktičtější uvádět RTO (Recovery Time Objective) a RPO (Recovery Point Objective), kde:

  • RTO vyjadřuje, za jak dlouho po výpadku musí být systém funkční, resp. jak dlouhý výpadek může být tolerován. Pro RTO rovno nule by to znamenalo vybudovat zcela redundantní infrastrukturu.
  • RPO vyjadřuje, kolik práce resp. jaké množství dat může být ztraceno. Jde o to, že záloha je dejme tomu naplánována na 03:00 a v 09:00 dojde k havárii diskového pole. Změněny, které byly provedeny mezi 03:00 a 09:00 jsou tedy nenávratně ztraceny.

Dobu nedostupnosti (RTO) a ztrátu dat (RPO) je třeba od sebe odlišovat, když se provádí business impact analýza, od které se odvíjí návrh celé architektury řešení. Častou chybou je, že se uvažuje jen o RTO a na RPO se zcela zapomíná.

Jako logické řešení se nabízí v případě, kdy je požadována vysoká dostupnost, vše duplikovat. A duplikovat lze opravdu vše, od napájení přes HDD, které se zapojí jako RAID1, řadiče, až po celý počítač nebo síť. Ovšem v době, kdy je většina systémů postavena na vícevrstvé architektuře, to znamená duplikovat minimálně webový server, aplikační server a databázový server. Takový systém se stává potom nejen složitějším a tedy i náročnějším na správu, ale především se vzrůstající složitostí roste i počet míst, na kterých může dojít k selhání a celé řešení pak musí být schopno se samo vypořádat se závadou, která může vzniknout prakticky na kterémkoliv prvku nebo síťovém spojení mezi kterýmikoliv prvky.

Jestliže dostupnost každé komponenty je 99,999% potom dostupnost celého řešení lze matematicky vyjádřit jako třetí mocninu 99,999% (Počítáme s 99,999% dostupností pro každou komponentu, 99,999% dostupností pro jednoduchou konfiguraci a s 99,999% pro zdvojenou konfiguraci) což je 99,997% tedy výpadek o délce necelých 16 minut za rok.

Tohle však není až tak podstatné, protože se objevuje mnohem závažnější problém a to, že v okamžiku, kdy provedeme duplikaci celého řešení (jednu konfiguraci si označíme jako primární a druhou jako sekundární, někdy se používá termín aktivní a pasivní), musíme zajistit, že v případě výpadku kterékoliv primární komponenty dojde k přepnutí na sekundární komponentu a ta přejde z pasivního módu do aktivního. Jestliže má toto řešení fungovat, musí být navíc zajištěna synchronizace mezi komponentami, aby bylo možno obsloužit stávající uživatele systému, dokončit zpracování jejich transakcí a nové uživatele směrovat na právě aktivní komponentu. Ten, kdo bude takové řešení navrhovat, bude muset tyto stavy ošetřit a to jak v samotné aplikaci, tak i na síťové vrstvě, a toto není v žádném případě triviální úkol. Protože pokud tyto stavy neošetří, hrozí například tzv. Split Brain Syndrom, kdy by v důsledku ztráty komunikace mezi primární a sekundární konfigurací mohly začít obě části pracovat na sobě zcela nezávisle a po obnově spojení by pak každá část obsahovala jiná data a transakce a systém by nevěděl jak je sloučit. Byla by tak sice zajištěna vysoká dostupnost, ale narušena integrita.

Pozn.: Co se týká používání pojmů primární-sekundární vs. aktivní-pasivní, jde o to, zda duplikované komponenty jsou naprosto stejné nebo ne. V případě, že je použito v záložním řešení méně výkonných komponent je vhodnější hovořit o primární a sekundární části. Pojmy aktivní a pasivní zase naopak lépe vystihují stav, ve kterém se tyto dvě části nacházejí a je vhodnější je používat v případě naprosto identických komponent.


Pokud vás tento příspěvek zaujal, sdílejte ho!
Share on FacebookShare on LinkedInTweet about this on TwitterShare on Google+Email this to someonePrint this page

Štítky: , , , ,


K článku “CIA: Dostupnost” se zde nenachází žádný komentář - buďte první.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.

Přihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce: