Provozní kontinuita a zotavení po havárii pro SQL Managed Instance s podporou Azure Arc
SQL Managed Instance s podporou Azure Arc poskytuje funkce pro provozní kontinuitu a zotavení po havárii (BCDR), které firmám pomáhají zotavit se z přerušení a pokračovat v provozu s minimálními výpadky.
Tento článek obsahuje klíčové aspekty návrhu a doporučení pro konfiguraci a správu funkcí provozní kontinuity, jako je obnovení k určitému bodu v čase, vysoká dostupnost a zotavení po havárii.
Architektura
Následující diagramy architektury znázorňují možnosti vysoké dostupnosti SQL Managed Instance s podporou arc na úrovni služby Pro důležité obchodní informace, která podporuje převzetí služeb při selhání s téměř nulovými výpadky. Pokud primární instance selže, nástroj pro vyrovnávání zatížení do této instance přestane posílat provoz. Pak se jedna ze sekundárních instancí zvýší na primární a nově zvýšená instance začne přijímat provoz pro čtení a zápis z nástroje pro vyrovnávání zatížení. Jakmile se neúspěšná instance vrátí do režimu online, přidá se jako sekundární instance.
Následující diagram architektury ukazuje, jak je možné SQL Managed Instance s podporou arc nasadit do dvou samostatných clusterů Kubernetes ve dvou různých lokalitách pro zotavení po havárii.
Následující diagram architektury znázorňuje, jak SQL Managed Instance s podporou Arc reaguje na zahájení převzetí služeb při selhání zotavení po havárii.
Na co dát pozor při navrhování
Pokud chcete posoudit dopad SQL Managed Instance s podporou Azure Arc na celkový model BCDR, projděte si doporučení BCDR pro cílové zóny provozní kontinuity a zotavení po havárii. Mějte na paměti, že se provozní kontinuita a zotavení po havárii zaměřují na doporučení návrhu pouze pro provozní kontinuitu, ale vysoká dostupnost a odolnost vaší instance závisí také na dostupnosti základní infrastruktury Kubernetes.
Obnovení k určitému bodu v čase
Definujte cíle pro cíl bodu obnovení (RPO) a časový cíl obnovení (RTO).
Určete, jak dlouho chcete uchovávat a obnovovat zálohy v rámci podporovaných limitů uchovávání.
Zvažte důsledky pro úložiště a náklady na prodloužení doby uchovávání záloh. Výchozí doba uchovávání je sedm dní. S touto dobou můžete obnovit až sedm dní a získáte jednu úplnou zálohu, denní rozdíl a zálohy transakčních protokolů přibližně každých pět minut.
Zvažte, kterou třídu úložiště použít pro trvalý svazek pro zálohování. Pokyny najdete v tématu Disciplíny úložiště pro SQL Managed Instance s podporou Azure Arc.
Zvažte velikost trvalého svazku pro zálohy v kontextu očekávané velikosti dat a nakonfigurované doby uchovávání.
Osvědčené postupy pro úložiště najdete v tématu Disciplíny úložiště pro SQL Managed Instance s podporou Azure Arc.
Zálohování se vždy provádí na primární replice. Při identifikaci prostředků přidělených vaší instanci zvažte vliv procesů zálohování a obnovení na výkon.
Vezměte v úvahu, že obnovení databáze k určitému bodu v čase nemůže přepsat existující databázi. Můžou ale obnovit data do nové databáze ve stejné instanci.
Zvažte další kroky potřebné k úplnému obnovení databáze, pokud je vaše aplikace během procesu obnovení online.
Vezměte v úvahu další kroky potřebné k obnovení databáze na instanci s více replikou, jak je popsáno v tématu Obnovení databáze do instance s více replikou.
Určete nástroje, které správci databáze používají ke konfiguraci a obnovení záloh. Další informace najdete v tématu Připojení k SQL Managed Instance s podporou Azure Arc.
Vysoká dostupnost
Zkontrolujte požadavky na dostupnost úloh a rozhodněte se, jaká úroveň služby je nejvhodnější pro vaše nasazení SQL Managed Instance s podporou Arc:
- Na úrovni služby Pro obecné účely je k dispozici jedna replika a vysoké dostupnosti se dosahuje prostřednictvím orchestrace Kubernetes.
- Na úrovni služby Pro důležité obchodní informace poskytuje SQL Managed Instance s podporou Azure Arc kromě toho, co nativně poskytuje orchestrace Kubernetes, skupinu dostupnosti s omezením.
Zvažte potenciální obchodní důsledky výpadku na úrovni služby Pro obecné účely, který by mohl mít za následek existenci pouze jedné repliky.
Zvažte, kolik replik (jedna až tři) se má nasadit ve Pro důležité obchodní informace úrovni služby.
Při nasazování instance v Pro důležité obchodní informace úrovni služby se dvěma nebo více replikami můžete sekundární repliky nakonfigurovat jako čitelné. Rozhodněte o počtu sekundárních replik, které se mají nasadit na úrovni služby Pro důležité obchodní informace. Informace o změně čísla najdete v tématu Konfigurace čitelných sekundárních souborů.
Určete prioritu konzistence před dostupností prostřednictvím počtu sekundárních replik potřebných k potvrzení transakce v Pro důležité obchodní informace úrovni služby pomocí volitelného parametru--sync-secondary-to-commit. Pokud dojde k problémům s připojením mezi replikami, primární server nemusí potvrdit žádné transakce:
- V konfiguraci se dvěma replikami musí být transakce potvrzena na obou replikách, aby primární server obdržel zprávu o úspěchu.
- V konfiguraci se třemi replikami musí alespoň dvě ze tří replik potvrdit transakci, aby se vrátila zpráva o úspěchu.
Rozhodněte se, jestli potřebujete jako primární určit konkrétní repliku. Informace o zadání primární repliky najdete v tématu Upřednostňovaná primární replika.
Rozhodněte, jaký typ služby Kubernetes budete používat, LoadBalancer nebo NodePort. Pokud použijete nástroj pro vyrovnávání zatížení, aplikace se můžou znovu připojit ke stejnému primárnímu koncovému bodu a Kubernetes přesměruje připojení na nový primární bod. Pokud použijete port uzlu, aplikace se musí znovu připojit k nové IP adrese.
Zotavení po havárii
Instance SQL Managed Instance s podporou služby Azure Arc v primárních i geografických sekundárních lokalitách musí být identické z hlediska výpočetních prostředků a kapacity a musí být nasazené do stejných úrovní služby.
Při vytváření konfigurace zotavení po havárii, která je přístupná pro oba clustery hostující instanci, rozhodněte o umístění, do kterého se mají ukládat certifikáty zrcadlení.
Zvažte, jak monitorovat výpadky primární instance a rozhodnout se, kdy provést převzetí služeb při selhání sekundární instance.
Každá instance má své vlastní koncové body. Zvažte, jak budou vaše aplikace přistupovat k primárnímu koncovému bodu s minimálním přerušením v případě převzetí služeb při selhání.
Doporučení k návrhu
Následující části obsahují návrh doporučení pro obnovení k určitému bodu v čase, vysokou dostupnost a zotavení po havárii.
Obnovení k určitému bodu v čase
Při nasazování nové instance SQL Managed Instance s podporou arc vždy definujte třídu úložiště pro zálohy, abyste se vyhnuli výchozí třídě úložiště dat.
Použijte třídu úložiště, která podporuje ReadWriteMany (RWX) pro záložní svazek. Pokyny najdete v tématu Disciplíny úložiště pro SQL Managed Instance s podporou Azure Arc.
Před zahájením operace obnovení nejprve pomocí volitelného parametru--dry-run ověřte, jestli bude operace úspěšná. Další informace najdete v tématu Vytvoření databáze z bodu v čase pomocí az CLI.
Vytvořte proces pro odesílání záloh, které vyžadují delší dobu uchovávání, do Azure nebo jiného místního studeného úložiště.
Monitorujte úložiště spotřebované zálohami a zjistěte, jestli můžete v případě potřeby využít delší uchovávání.
Vysoká dostupnost
Provádějte pravidelné postupy k ověření vysoké dostupnosti vaší instance SQL Managed Instance s podporou arc. Mezi příklady podrobností patří odstranění podu v instanci Pro obecné účely a selhání repliky v instanci Pro důležité obchodní informace.
V Pro důležité obchodní informace vrstvě nasaďte instanci v konfiguraci se třemi repliky místo konfigurace se dvěma repliky, abyste dosáhli téměř nulové ztráty dat.
Pro zajištění lepší dostupnosti použijte při nasazování instance jako typ služby LoadBalancer.
Projděte si omezení vysoké dostupnosti SQL Managed Instance s podporou Azure Arc.
Projděte si podporované režimy dostupnosti a rozhodněte se, který režim použít na základě vašich potřeb vysoké dostupnosti.
Při nasazování instance Pro důležité obchodní informace s více replikami použijte pro úlohy čtení jednu ze sekundárních replik. Připojovací řetězec aplikace musí zadat sekundární koncový bod jako naslouchací proces služby pro přesměrování na sekundární repliky. Informace o koncových bodech najdete v tématu Získání primárního a sekundárního koncového bodu a stavu skupiny dostupnosti.
Informace o osvědčených postupech pro monitorování dostupnosti instancí najdete v tématu Správa a monitorování SQL Managed Instance s podporou Azure Arc.
Zotavení po havárii
Ujistěte se, že vaše instance SQL Managed Instance s podporou arc mají různé názvy primární a sekundární lokality a že hodnota sdíleného názvu pro weby je stejná.
Proveďte pravidelné postupy zotavení po havárii a ověřte proces převzetí služeb při selhání.
Vytvořte proces pro zahájení ručního i vynuceného převzetí služeb při selhání.
Informace o osvědčených postupech pro monitorování stavu clusterů a informace o tom, kdy se vyžaduje převzetí služeb při selhání, najdete v tématu Správa a monitorování SQL Managed Instance s podporou služby Azure Arc.
Definujte záznam DNS pro sdílený název distribuované skupiny dostupnosti na vašich serverech DNS, abyste nemuseli během převzetí služeb při selhání vytvářet záznamy DNS ručně.
Další kroky
Další informace o hybridní a vícecloudové cestě ke cloudu najdete v následujících článcích:
- Co jsou datové služby s podporou Azure Arc?
- Přehled: SQL Managed Instance provozní kontinuita s podporou Azure Arc
- Ověřování Kubernetes datových služeb s podporou Azure Arc
- Správa portfolia napříč hybridními a multicloudovými operacemi
- Datové služby s podporou Azure Arc pro automatizované scénáře s využitím azure Arc Jumpstart
- Přineste inovace Azure do hybridních prostředí pomocí Azure Arc, studijního programu z Microsoft Learn