Popis cíle doby obnovení a cíle bodu obnovení
Pochopení cílů doby obnovení a bodů obnovení je pro váš plán vysoké dostupnosti a zotavení po havárii (HADR), protože jsou základem pro jakékoli řešení dostupnosti.
Cíl doby obnovení
Cíl doby obnovení (RTO) je maximální doba, která je k dispozici pro přenesení prostředků do režimu online po výpadku nebo problému. Pokud tento proces trvá déle než RTO, může to mít důsledky, jako jsou finanční sankce, práce se nedá provést atd. RtO lze zadat pro celé řešení, které zahrnuje všechny prostředky, a také pro jednotlivé komponenty, jako jsou instance SQL Serveru a databáze.
Cíl bodu obnovení
Cíl bodu obnovení (RPO) je bod v čase, ke kterému by měla být databáze obnovena, a odpovídá maximálnímu množství ztráty dat, kterou má firma přijmout. Předpokládejme například, že virtuální počítač IaaS, který obsahuje SQL Server, dojde k výpadku v 10:00 a databáze v instanci SQL Serveru mají cíl bodu obnovení 15 minut. Bez ohledu na to, jakou funkci nebo technologii se tato instance a její databáze používají, očekává se, že dojde ke ztrátě dat maximálně 15 minut. To znamená, že databázi je možné obnovit na 9:45 nebo novější, aby se zajistilo, že nedojde k žádné ztrátě dat, která splňuje uvedené cíle bodu obnovení. Mohou existovat faktory, které určují, jestli je možné dosáhnout cíle bodu obnovení.
Definování doby obnovení a cílů bodu obnovení
RtOs a rpOs jsou řízeny obchodními požadavky, ale jsou také založeny na různých technologických a dalších faktorech, jako jsou dovednosti a schopnosti správců (nejen DBA). I když firma nemusí chtít žádný výpadek nebo nulovou ztrátu dat, nemusí to být reálné nebo možné z různých důvodů. Určení rto a RPO vašeho řešení by mělo být otevřenou a upřímnou diskuzí mezi všemi zúčastněnými stranami.
Jedním z aspektů zásadních pro RTO i RPO je znalost nákladů na výpadky. Pokud definujete toto číslo a celkový efekt je pro firmu mimo provoz nebo je nedostupný, je jednodušší definovat řešení. Pokud například firma může přijít o 10 000 za hodinu nebo může být vyměněná vládní agenturou, pokud by něco nebylo možné zpracovat, je to měřitelný způsob, jak definovat RTO a RPO. Výdaje na řešení by měly být úměrné výši výpadku nebo nákladům. Pokud vaše řešení HADR stojí $X, ale místo hodin nebo dnů, kdy dojde k problému, se vám to projeví jenom po dobu několika sekund.
Z jiného než obchodního hlediska by mělo být RTO definováno na úrovni komponenty (například SQL Server) i pro celou architekturu aplikace. Schopnost zotavit se z výpadku je pouze stejně dobrá jako její nejslabší propojení. Pokud se například SQL Server a jeho databáze dají převést do online režimu během pěti minut, ale trvá to, aby aplikační servery 20 minut udělaly totéž, celková doba RTO by byla 20 minut, ne pět minut. Prostředí SQL Serveru může mít rto 5 minut; stále nezmění celkovou dobu obnovení.
RPO se zabývá konkrétně daty a přímo ovlivňuje návrh jakéhokoli řešení HADR a také zásad a postupů správy. Použité funkce musí podporovat jak rto, tak rpos, které jsou definované. Pokud jsou například zálohy transakčních protokolů naplánované každých 30 minut, ale existuje 15minutový cíl bodu obnovení, databáze by mohla být obnovena pouze do poslední dostupné zálohy transakčního protokolu, která by v nejhorším případě byla před 30 minutami. Toto načasování předpokládá, že nedošlo k žádným jiným problémům a zálohování bylo otestováno a je známo, že jsou dobré. I když je obtížné otestovat každou zálohu vygenerovanou pro každou databázi ve vašem prostředí, zálohy jsou jen soubory v systému souborů. Bez provádění aspoň pravidelných obnovení není zaručeno, že jsou dobré. Spuštění kontrol během procesu zálohování vám může poskytnout určitou míru spolehlivosti.
Konkrétní použité funkce, jako je skupina dostupnosti AlwaysOn (AG) nebo instance clusteru s podporou převzetí služeb při selhání alwaysOn (FCI), ovlivní také vaše rto a rpos. V závislosti na konfiguraci funkcí může řešení IaaS nebo PaaS automaticky převzít služby při selhání do jiného umístění, což může vést k delšímu výpadku. Když definujete plánovanou dobu obnovení a cíl bodu obnovení( RPO), technické řešení, které tento požadavek podporuje, je možné navrhnout s vědomím povolenek pro čas a ztrátu dat. Pokud jsou tyto vyřazování nerealistické, musí být odpovídajícím způsobem upraveny rto a rpOs. Pokud je například požadovaná rto dvě hodiny, ale zálohování bude trvat tři hodiny, než se zkopíruje na cílový server pro obnovení, rto se už zmešká. Tyto typy faktorů musí být při určování objektů RTO a RPO potřeba zohlednit.
Pro vysokou dostupnost a zotavení po havárii by měly být definované rto a rpos. Vysoká dostupnost se považuje za lokalizovanější událost, kterou lze snadněji obnovit. Jedním z příkladů vysoké dostupnosti je automatické převzetí služeb při selhání skupiny dostupnosti z jedné repliky do druhé v rámci oblasti Azure. To může trvat několik sekund a v tomto okamžiku byste měli zajistit, aby se aplikace mohla po převzetí služeb při selhání připojit. Výpadek SQL Serveru by byl minimální. Místní rto nebo cíl bodu obnovení (RPO) se může v závislosti na kritické povaze řešení nebo systému měřit v minutách.
Zotavení po havárii by bylo podobné, jako by přineslo zcela nové datové centrum. Existuje spousta kusů puzzle; SQL Server je jen jedna komponenta. Získání všeho online může trvat hodiny nebo déle. Proto jsou rto a rpos oddělené. I když je mnoho technologií a funkcí používaných pro vysokou dostupnost a zotavení po havárii stejné, nemusí být úroveň úsilí a času.
Všechny rto a RPO by měly být formálně zdokumentované a revidované pravidelně nebo podle potřeby. Po zdokumentování můžete zvážit, jaké technologie a funkce můžete pro architekturu použít.