Přehled kontinuity podnikových prostředí s Azure SQL Database & Azure SQL Managed Instance

PLATÍ PRO: Azure SQL Database Azure SQL Managed Instance

Kontinuita podnikových procesů ve službě Azure SQL Database SQL Managed Instance odkazuje na mechanismy, zásady a postupy, které vaší společnosti umožňují pokračovat v provozu v případě narušení provozu, zejména v případě její výpočetní infrastruktury. Ve většině případů bude spravovaná instance SQL Database a SQL zpracovávat rušivé události, ke které může dojít v cloudovém prostředí, a udržovat vaše aplikace a obchodní procesy v provozu. Existují však některé rušivé události, které nelze automaticky SQL Database například:

• Uživatel omylem odstranil nebo aktualizoval řádek v tabulce.
• Útočníkovi se zlými úmysly se podařilo odstranit data nebo odstranit databázi.
• Zemětřesení způsobilo výpadky napájení a dočasné zakázané datové centrum.

Tento přehled popisuje možnosti, které SQL Database a SQL spravované instance poskytují pro zajištění kontinuity podnikových služeb a zotavení po havárii. Seznamte se s možnostmi, doporučeními a kurzy pro zotavení z ničivá událostí, které by mohly způsobit ztrátu dat nebo nedostupnost databáze a aplikace. Zjistěte, co dělat, když chyba uživatele nebo aplikace ovlivní integritu dat, dojde v oblasti Azure k výpadku nebo vaše aplikace vyžaduje údržbu.

Funkce služby SQL Database, pomocí kterých můžete zajistit provozní kontinuitu

Z hlediska databáze existují čtyři hlavní potenciální scénáře narušení:

• Selhání místního hardwaru nebo softwaru ovlivňující databázový uzel, například selhání diskové jednotky.
• Poškození nebo odstranění dat obvykle způsobené chybou aplikace nebo lidskou chybou. Taková selhání jsou specifická pro aplikaci a databázová služba obvykle nemůže detekovat.
• Výpadky datacentra, pravděpodobně způsobené přírodní katastrofou. Tento scénář vyžaduje nějakou úroveň geografické redundance s převzetím služeb při selhání aplikace do alternativního datacentra.
• Chyby upgradu nebo údržby, neočekávané problémy, ke kterým dochází během plánované údržby infrastruktury nebo upgradů, mohou vyžadovat rychlé vrácení zpět do předchozího stavu databáze.

Za účelem zmírnění selhání místního hardwaru asoftwaru obsahuje SQL Database architekturu s vysokou dostupností, která zaručuje automatické obnovení z těchto selhání s až 99,995% dostupností SLA.

Spravovaná instance SQL Database a SQL chrání vaši firmu před ztrátou dat a automaticky vytváří týdenní úplné zálohy databáze, rozdílové zálohy databáze každých 12 hodin a zálohování transakčních protokolů každých 5 až 10 minut. Zálohy se uchovávají v úložišti RA-GRS nejméně sedm dnů pro všechny úrovně služby. Všechny úrovně služby kromě podpora Basic dobu uchovávání záloh pro obnovení k bodu v čase až 35 dnů.

SQL Database a SQL Managed Instance také poskytují několik funkcí kontinuity podnikových dat, které můžete použít ke zmírnění různých neplánovaných scénářů.

• Dočasné tabulky umožňují obnovit verze řádků z jakéhokoli bodu v čase.
• Integrované automatizované zálohy a obnovení k bodu v čase umožňují obnovit úplnou databázi k nějakému bodu v čase v rámci nakonfigurované doby uchovávání až do 35 dnů.
• Odstraněnou databázi můžete obnovit do bodu, kdy byla odstraněna, pokud server nebyl odstraněn.
• Dlouhodobé uchovávání záloh umožňuje zachovat zálohy až 10 let. Tato možnost je ve verzi Limited Public Preview SQL Managed Instance.
• Aktivní geografická replikace umožňuje vytvořit repliky pro čtení a ručně provést převzetí služeb při selhání na jakoukoli repliku v případě výpadku datacentra nebo upgradu aplikace.
• Skupina automatického převzetí služeb při selhání umožňuje aplikaci automatické obnovení v případě výpadku datacentra.

Obnovení databáze ve stejné oblasti Azure

Automatické zálohy databáze můžete použít k obnovení databáze k bodu v čase v minulosti. Tímto způsobem se můžete zotavit z poškození dat způsobených lidskými chybami. Obnovení k bodu v čase umožňuje vytvořit novou databázi na stejném serveru, který představuje stav dat před poškozenou událostí. U většiny databází trvá operace obnovení méně než 12 hodin. Obnovení velmi velké nebo velmi aktivní databáze může trvat déle. Další informace o době obnovení najdete v tématu čas obnovení databáze.

Pokud maximální podporovaná doba uchovávání záloh pro obnovení k bodu v čase (PITR) pro vaši aplikaci nestačí, můžete ji prodloužit konfigurací zásad dlouhodobého uchovávání (LTR) pro databáze. Další informace najdete v tématu Dlouhodobé uchovávání záloh.

Porovnání geografické replikace se skupinami převzetí služeb při selhání

Skupiny automatického převzetí služeb při selhání zjednodušují nasazení a používání geografické replikace a přidávají další možnosti, jak je popsáno v následující tabulce:

Obnovení databáze na existující server

I když je to vzácné, může mít datacentrum Azure výpadky. Při výpadku dojde k narušení provozu, které může trvat jen několik minut nebo až několik hodin.

• Jednou z možností je počkat, až se vaše databáze vrátí do režimu online, až dojde k výpadku datacentra. Tento postup funguje pro aplikace, které si mohou dovolit mít databázi v režimu offline. Například vývojový projekt nebo bezplatná zkušební verze, na které nemusíte neustále pracovat. Pokud dojde k výpadku datacentra, nevíte, jak dlouho může trvat, takže tato možnost funguje jenom v případě, že databázi chvíli nepotřebujete.
• Další možností je obnovit databázi na libovolném serveru v jakékoli oblasti Azure pomocí geograficky redundantních záloh databáze (geografické obnovení). Geografické obnovení využívá jako zdroj geograficky redundantní zálohu a je možné ji použít k obnovení databáze i v případě, že je databáze nebo datacentrum nedostupné z důvodu výpadku.
• Pokud jste pro databázi nebo databáze nakonfigurovali geografickou replikaci s použitím aktivní geografické replikace nebo skupiny automatického převzetí služeb při selhání, můžete se rychle zotavit z výpadku. V závislosti na vaší volbě těchto technologií můžete použít ruční nebo automatické převzetí služeb při selhání. Zatímco samotné převzetí služeb při selhání trvá jen několik sekund, aktivace služby trvá nejméně 1 hodinu. To je nezbytné k zajištění, že převzetí služeb při selhání je podchyceno rozsahem výpadku. Převzetí služeb při selhání může také způsobit malou ztrátu dat kvůli povaze asynchronní replikace.

Při vývoji plánu provozní kontinuity musíte pochopit maximální přijatelnou dobu úplného zotavení aplikace po ničivé události. Doba potřebná k úplnému obnovení aplikace se označuje jako cíl doby obnovení (RTO). Musíte také porozumět maximálnímu období nedávných aktualizací dat (časový interval), které může aplikace tolerovat ztrátu při zotavení z neplánované ničivé události. Potenciální ztráta dat se označuje jako cíl bodu obnovení (RPO).

Různé metody obnovení nabízejí různé úrovně RPO a RTO. Můžete zvolit konkrétní metodu obnovení nebo použít kombinaci metod k dosažení úplného obnovení aplikace. Následující tabulka porovnává RPO a RTO jednotlivých možností obnovení. Skupiny automatického převzetí služeb při selhání zjednodušují nasazení a používání geografické replikace a přidávají další možnosti, jak je popsáno v následující tabulce:

Skupiny automatického převzetí služeb při selhání použijte, pokud vaše aplikace splňuje kterákoli z těchto kritérií:

• Je zvlášť důležitá.
• Má smlouvu o úrovni služeb (SLA), která neumožňuje 12 hodin nebo více výpadků.
• Prostoj může mít za následek finanční závazky.
• Má vysokou míru změn dat a 1 hodinu ztráty dat není přijatelná.
• Další náklady na aktivní geografickou replikaci jsou nižší než potenciální finanční závazky a související ztráta podnikání.

V závislosti na požadavcích vaší aplikace se můžete rozhodnout použít kombinaci záloh databáze a aktivní geografické replikace. Diskuzi o aspektech návrhu pro samostatné databáze a pro elastické fondy využívající tyto funkce kontinuity podnikových prostředí najdete v tématu Návrh aplikace pro zotavení po havárii cloudu a Strategie zotavení po havárii elastického fondu.

Následující části poskytují přehled kroků pro obnovení pomocí záloh databáze nebo aktivní geografické replikace. Podrobné kroky, včetně požadavků na plánování, kroků po obnovení a informací o simulaci výpadku, který provede postup zotavení po havárii, najdete v tématu Obnovení databáze v SQL Database po výpadku.

Příprava na výpadek

Bez ohledu na funkce provozní kontinuity, které používáte, musíte:

• Identifikujte a připravte cílový server, včetně pravidel brány firewall protokolu IP na úrovni serveru, přihlášení a oprávnění master na úrovni databáze.
• Určit, jak přesměrovat klienty a klientské aplikace na nový server
• Zdokumentovat další závislosti, například nastavení auditování a výstrahy

Pokud se nepřipravíte správně, uvedení aplikací do online režimu po převzetí služeb při selhání nebo obnovení databáze bude chvíli trvat a pravděpodobně také bude vyžadovat řešení potíží v době, kdy dochází ke zátěži – špatné kombinaci.

Převzetí služeb při selhání do geograficky replikované sekundární databáze

Pokud jako mechanismus obnovení používáte aktivní geografickou replikaci nebo skupiny automatického převzetí služeb při selhání, můžete nakonfigurovat zásady automatického převzetí služeb při selhání nebo použít ruční neplánované převzetí služeb při selhání. Po zahájení převzetí služeb při selhání se sekundární databáze stane novým primárním serverem a bude připravená zaznamenávat nové transakce a reagovat na dotazy s minimálními ztrátami dat pro data, která se ještě nereplikovala. Informace o návrhu procesu převzetí služeb při selhání najdete v tématu Návrh aplikace pro zotavení po havárii cloudu.

Provedení geografického obnovení

Pokud používáte automatizované zálohy s geograficky redundantním úložištěm (ve výchozím nastavení povolené), můžete databázi obnovit pomocí geografického obnovení. Obnovení obvykle probíhá během 12 hodin – se ztrátou dat až jednu hodinu podle toho, kdy byla pořízena a replikována poslední záloha protokolů. Dokud se obnovení nedokončí, databáze není schopná zaznamenávat žádné transakce ani reagovat na dotazy. Poznámka: Geografické obnovení obnoví databázi pouze k poslednímu dostupnému bodu v čase.

Provedení úloh po převzetí služeb při selhání nebo obnovení

Po obnovení s použitím libovolného mechanismu musíte provést následující dodatečné úlohy, abyste pro uživatele zprovoznili své aplikace:

• Přesměrovat klienty a klientské aplikace na nový server a obnovenou databázi.
• Ujistěte se, že jsou příslušná pravidla brány firewall protokolu IP na úrovni serveru, aby se uživatelé připojovat nebo aby k povolení příslušných pravidel používejte brány firewall na úrovni databáze.
• Ujistěte se, že jsou na místě příslušná přihlášení a oprávnění na úrovni hlavní databáze (nebo použijte obsažené uživatele).
• Podle potřeby nakonfigurujte auditování.
• Podle potřeby nakonfigurujte výstrahy.

Upgrade aplikace s minimálními výpadky

Někdy je nutné aplikaci přejít do režimu offline kvůli plánované údržbě, jako je upgrade aplikace. Článek Správa upgradů aplikací popisuje, jak pomocí aktivní geografické replikace povolit postupné upgrady cloudové aplikace, aby se minimalizovaly výpadky během upgradů, a poskytne cestu obnovení, pokud se něco pokazí.

Další kroky

Diskuzi o aspektech návrhu aplikací pro jednotlivé databáze a elastické fondy najdete v tématu Návrh aplikace pro zotavení po havárii cloudu a Strategie zotavení po havárii elastického fondu.