Přehled provozní kontinuity se službou Azure SQL Database
Platí pro:
Azure SQL Database SQL Database v prostředcích infrastruktury
Tento článek obsahuje přehled možností provozní kontinuity a zotavení po havárii služby Azure SQL Database, které popisují možnosti a doporučení pro zotavení z rušivých událostí, které můžou vést ke ztrátě dat nebo způsobit nedostupnost databáze a aplikace. Zjistěte, co dělat, když chyba uživatele nebo aplikace ovlivňuje integritu dat, zónu dostupnosti Azure nebo oblast dojde k výpadku nebo že vaše aplikace vyžaduje údržbu.
Přehled
Kontinuita podnikových procesů ve službě Azure SQL Database se týká mechanismů, zásad a postupů, které vaší firmě umožňují pokračovat v provozu v případě přerušení poskytováním dostupnosti, vysoké dostupnosti a zotavení po havárii.
Ve většině případů sql Database zpracovává rušivé události, ke kterým může dojít v cloudovém prostředí, a udržuje vaše aplikace a obchodní procesy spuštěné. Existuje však několik rušivých událostí, kdy zmírnění může nějakou dobu trvat, například:
- Uživatel omylem odstraní nebo aktualizuje řádek v tabulce.
- Útočník se zlými úmysly úspěšně odstraní data nebo zahodí databázi.
- Katastrofická přírodní katastrofa přebírá datacentrum nebo zónu dostupnosti nebo oblast.
- Vzácné výpadky datacentra, zóny dostupnosti nebo oblasti způsobené změnou konfigurace, chybou softwaru nebo selháním hardwarových komponent.
Dostupnost
Azure SQL Database nabízí základní příslib odolnosti a spolehlivosti, který ho chrání před selháním softwaru nebo hardwaru. Zálohy databáze jsou automatizované, aby chránily vaše data před poškozením nebo náhodným odstraněním. Jako platforma jako služba (PaaS) poskytuje služba Azure SQL Database dostupnost jako funkci mimo provoz se smlouvou SLA s nejlepší dostupností 99,99 %.
Vysoká dostupnost
Pokud chcete dosáhnout vysoké dostupnosti v cloudovém prostředí Azure, povolte redundanci zón, aby databáze nebo elastický fond používaly zóny dostupnosti k zajištění odolnosti databáze nebo elastického fondu vůči zónovým selháním. Řada oblastí Azure poskytuje zóny dostupnosti, které jsou oddělené skupiny datových center v rámci oblasti, které mají nezávislou infrastrukturu napájení, chlazení a sítě. Zóny dostupnosti jsou navržené tak, aby poskytovaly regionální služby, kapacitu a vysokou dostupnost ve zbývajících zónách, pokud dojde k výpadku jedné zóny. Povolením redundance zón je databáze nebo elastický fond odolné vůči zónovým selháním hardwaru a softwaru a obnovení je pro aplikace transparentní. Když je povolená vysoká dostupnost, služba Azure SQL Database dokáže poskytovat smlouvu SLA s vyšší dostupností 99,995 %.
Zotavení po havárii
Pokud chcete dosáhnout vyšší dostupnosti a redundance napříč oblastmi, můžete povolit možnosti zotavení po havárii a rychle obnovit databázi z závažného regionálního selhání. Možnosti zotavení po havárii pomocí Služby Azure SQL Database jsou:
- Aktivní geografická replikace umožňuje vytvořit nepřetržitě synchronizovanou sekundární databázi v libovolné oblasti pro primární databázi.
- Skupiny převzetí služeb při selhání kromě poskytování průběžné synchronizace mezi primární a sekundární databází také umožňují spravovat replikaci a převzetí služeb při selhání některých nebo všech databází na logickém serveru do sekundárního logického serveru v jiné oblasti. Skupiny převzetí služeb při selhání poskytují koncové body naslouchacího procesu jen pro čtení a jen pro čtení, které zůstávají beze změny, takže aktualizace aplikací připojovací řetězec po převzetí služeb při selhání není nutná.
- Geografické obnovení umožňuje zotavení z regionálního výpadku obnovením z geograficky replikovaných záloh, když nemůžete získat přístup k databázi v primární oblasti vytvořením nové databáze na jakémkoli existujícím serveru v libovolné oblasti Azure.
Následující tabulka porovnává aktivní geografickou replikaci a skupiny převzetí služeb při selhání, dvě možnosti zotavení po havárii pro Azure SQL Database:
| Aktivní geografická replikace | Skupiny převzetí služeb při selhání | |
|---|---|---|
| Průběžná synchronizace dat mezi primárním a sekundárním serverem | Ano | Yes |
| Převzetí služeb při selhání více databází současně | No | Ano |
| Připojovací řetězec zůstane po převzetí služeb při selhání beze změny. | No | Ano |
| Podporuje škálování čtení. | Ano | Yes |
| Více replik | Yes | No |
| Může být ve stejné oblasti jako primární | Yes | No |
Funkce, které poskytují kontinuitu podnikových procesů
Z hlediska databáze existují čtyři hlavní potenciální scénáře přerušení. Následující tabulka uvádí funkce provozní kontinuity služby SQL Database, které můžete použít ke zmírnění potenciálního scénáře přerušení podnikání:
| Scénář přerušení podnikání | Funkce provozní kontinuity |
|---|---|
| Selhání místního hardwaru nebo softwaru, které ovlivňují databázový uzel. | Kvůli zmírnění selhání místního hardwaru a softwaru zahrnuje SQL Database architekturu dostupnosti, která zaručuje automatické obnovení z těchto selhání s až 99,99% smlouvou SLA o dostupnosti. |
| Poškození nebo odstranění dat obvykle způsobuje chyba aplikace nebo lidská chyba. Taková selhání jsou specifická pro jednotlivé aplikace a většinou se nedají zjistit databázovou službou. | Kvůli ochraně vaší firmy před ztrátou dat sql Database automaticky vytváří týdenní úplné zálohy databází, rozdílové zálohy databází každých 12 nebo 24 hodin a zálohy transakčních protokolů každých 5 až 10 minut. Ve výchozím nastavení se zálohy ukládají v geograficky redundantním úložišti po dobu sedmi dnů pro všechny úrovně služby. Všechny úrovně služby kromě úrovně Basic podporují konfigurovatelnou dobu uchovávání záloh pro obnovení k určitému bodu v čase (PITR) až 35 dnů. Odstraněnou databázi můžete obnovit do bodu, ve kterém byla odstraněna, pokud server nebyl odstraněn, nebo pokud jste nakonfigurovali dlouhodobé uchovávání (LTR). |
| Vzácné výpadky datového centra nebo zóny dostupnosti, které můžou být způsobeny událostí přírodní katastrofy, změnou konfigurace, chybou softwaru nebo selháním hardwarové komponenty. | Pokud chcete zmírnit výpadky na úrovni datového centra nebo zóny dostupnosti, povolte redundanci zón pro databázi nebo elastický fond, aby používala Azure Zóny dostupnosti a poskytovala redundanci napříč několika fyzickými zónami v rámci oblasti Azure. Povolení redundance zón zajišťuje odolnost databáze nebo elastického fondu vůči zónovým selháním s až 99,995% smlouvou SLA s vysokou dostupností. |
| Vzácné regionální výpadky , které mají vliv na všechny zóny dostupnosti a datacentra, která ho tvoří, pravděpodobně způsobila katastrofická přírodní katastrofa. | Pokud chcete zmírnit výpadky v celé oblasti, povolte zotavení po havárii pomocí jedné z těchto možností: – Možnosti průběžné synchronizace dat, jako jsou skupiny převzetí služeb při selhání (doporučeno) nebo aktivní geografická replikace, které umožňují vytvářet repliky v sekundární oblasti pro převzetí služeb při selhání. – Nastavení redundance úložiště zálohování na geograficky redundantní úložiště záloh pro použití geografického obnovení. |
RTO a RPO
Při vývoji plánu provozní kontinuity porozumíte maximální přijatelné době před tím, než se aplikace plně obnoví po rušivé události. Čas potřebný k úplnému obnovení aplikace se označuje jako plánovaná doba obnovení (RTO). Také porozumíte maximálnímu období nedávných aktualizací dat (časový interval), které může aplikace tolerovat ztrátu při obnovení z neplánované rušivé události. Potenciální ztráta dat se označuje jako cíl bodu obnovení (RPO).
Následující tabulka porovnává cíle bodu obnovení (RPO) a RTO jednotlivých možností provozní kontinuity:
| Možnost provozní kontinuity | RTO (výpadek) | RPO (ztráta dat) |
|---|---|---|
| Vysoká dostupnost (použití redundance zón) |
Obvykle méně než 30 sekund | 0 |
| Zotavení po havárii (použití skupin převzetí služeb při selhání se zásadami převzetí služeb při selhání spravované zákazníkem nebo aktivní geografickou replikací) |
Obvykle méně než 60 sekund | Je rovno nebo větší než 0 (závisí na změnách dat před rušivým událostí, která nebyla replikována) |
| Zotavení po havárii (použití geografického obnovení) |
Obvykle minuty nebo hodiny | Obvykle minuty nebo hodiny |
Kontrolní seznamy provozní kontinuity
Referenční doporučení k maximalizaci dostupnosti a dosažení vyšší kontinuity podnikových procesů najdete v tématu:
- Kontrolní seznam k dostupnosti
- Kontrolní seznam k vysoké dostupnosti
- Kontrolní seznam pro zotavení po havárii
Příprava na výpadek oblasti
Bez ohledu na to, které funkce provozní kontinuity používáte, musíte sekundární databázi připravit v jiné oblasti. Pokud se správně nepřipravíte, přenesení aplikací po převzetí služeb při selhání nebo obnovení trvá delší dobu a pravděpodobně také vyžaduje řešení potíží, což může zpozdit RTO. Postupujte podle kontrolního seznamu pro přípravu sekundárního výpadku oblasti.
Obnovení databáze ve stejné oblasti Azure
Automatické zálohy databáze můžete použít k obnovení databáze k určitému 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 určitému bodu v čase (PITR) 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 najdete v tématu Doba obnovení databáze.
Pokud maximální podporovaná doba uchovávání záloh pro obnovení k určitému bodu v čase 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.
Upgrade aplikace s minimálními výpadky
Někdy se aplikace musí přecházet do offline režimu kvůli údržbě, jako je upgrade aplikace. Správa upgradů aplikací popisuje, jak pomocí aktivní geografické replikace povolit postupné upgrady cloudové aplikace, aby se minimalizovaly výpadky během upgradů a poskytovaly cestu obnovení, pokud se něco nepovede.
Úspora nákladů s pohotovostní replikou
Pokud se sekundární replika používá jenom pro zotavení po havárii (DR) a nemá žádné úlohy čtení nebo zápisu, můžete ušetřit náklady na licencování tím, že databázi navrhnete pro pohotovostní režim při konfiguraci nového aktivního vztahu geografické replikace.
Další informace najdete v pohotovostní replice bez licence.
Další kroky
Aspekty návrhu aplikací najdete v tématu Návrh aplikace pro cloudové zotavení po havárii a strategie zotavení po havárii elastického fondu.
Projděte si pokyny k zotavení po havárii služby Azure SQL Database a kontrolní seznam pro vysokou dostupnost a zotavení po havárii služby Azure SQL Database.