Provozní kontinuita a zotavení po havárii pro spravovanou instanci SQL s podporou služby Azure Arc
Spravovaná instance SQL s podporou služby Azure Arc poskytuje možnosti 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 spravované instance SQL s podporou arc ve vrstvě 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í přestane do této instance odesílat provoz. Pak se jedna ze sekundárních instancí zvýší na primární a nově upřednostněná instance začne přijímat provoz pro čtení a zápis z nástroje pro vyrovnávání zatížení. Po návratu instance, která selhala, se přidá jako sekundární instance.
Následující diagram architektury ukazuje, jak je možné službu SQL Managed Instance s podporou arc nasadit na dva samostatné clustery Kubernetes ve dvou různých lokalitách pro zotavení po havárii.
Následující diagram architektury znázorňuje, jak služba SQL Managed Instance s podporou arc reaguje při spuštění převzetí služeb při selhání zotavení po havárii.
Aspekty návrhu
Pokud chcete posoudit účinek služby SQL Managed Instance s podporou služby Azure Arc na celkový model BCDR, projděte si doporučení BCDR pro cílové zóny v provozní kontinuitě a zotavení po havárii. Všimněte si, že zaměření provozní kontinuity a zotavení po havárii je na návrhových doporučeních 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 plánovanou dobu obnovení (RTO).
Určete, jak dlouho chcete uchovávat a obnovovat zálohy v rámci podporovaných limitů uchovávání informací.
Vezměte v úvahu důsledky pro úložiště a náklady na zvýšení doby uchovávání záloh. Výchozí uchovávání je sedm dní. Během této doby můžete obnovit až sedm dní a získáte jednu úplnou zálohu, denní rozdílové zálohování 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álohy. Pokyny najdete v tématu Disciplíny úložiště pro službu SQL Managed Instance s podporou služby Azure Arc.
Vezměte v úvahu 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 disciplínách úložiště pro spravovanou instanci SQL s podporou Služby Azure Arc.
Zálohy se vždy provádějí na primární replice. Při identifikaci prostředků přidělených vaší instanci zvažte výkon procesů zálohování a obnovení.
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.
Zvažte další kroky potřebné k obnovení databáze do instance s více replikou, jak je popsáno v části 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í ke službě SQL Managed Instance s podporou služby Azure Arc.
Vysoká dostupnost
Zkontrolujte požadavky na dostupnost vaší úlohy a rozhodněte se o úrovni služby, která je pro vaše nasazení služby SQL Managed Instance s podporou arc nejvhodnější:
- Na úrovni služby Pro obecné účely je k dispozici jedna replika a vysoká dostupnost se dosahuje prostřednictvím orchestrace Kubernetes.
- Na úrovni služby Pro důležité obchodní informace poskytuje spravovaná instance SQL s podporou služby Azure Arc kromě toho, co orchestrace Kubernetes nativně poskytuje, obsaženou skupinu dostupnosti.
Vezměte v úvahu potenciální obchodní účinky výpadků na úrovni služby Pro obecné účely, které by mohly mít za následek existenci pouze jedné repliky.
Zvažte, kolik replik ( jedna až tři) se má nasadit v Pro důležité obchodní informace úrovni služby.
Při nasazování instance ve vrstvě služby Pro důležité obchodní informace se dvěma nebo více replikami můžete sekundární repliky nakonfigurovat jako čitelné. Rozhodněte se o počtu sekundárních replik, které se mají nasadit v Pro důležité obchodní informace úrovni služby. Informace o změně čísla najdete v tématu Konfigurace čitelných sekundárních souborů.
Pomocí volitelného parametru --sync-secondary-to-commit se rozhodněte, jestli chcete určit prioritu konzistence před dostupností prostřednictvím počtu sekundárních replik, které jsou potřeba k potvrzení transakce ve vrstvě služby Pro důležité obchodní informace. Pokud mezi replikami dochází k problémům s připojením, primární nemusí potvrdit žádné transakce:
- V konfiguraci se dvěma replikami musí být transakce potvrzena na obou replikách, aby primární získal 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 určit konkrétní repliku jako primární. Informace o zadání primární repliky najdete v tématu Upřednostňovaná primární replika.
Rozhodněte se, jaký typ služby Kubernetes budete používat, LoadBalancer nebo NodePort. Pokud používáte nástroj pro vyrovnávání zatížení, můžou se aplikace znovu připojit ke stejnému primárnímu koncovému bodu a Kubernetes přesměruje připojení na novou primární. Pokud použijete port uzlu, musí se aplikace znovu připojit k nové IP adrese.
Zotavení po havárii
Instance služby SQL Managed Instance s podporou služby Azure Arc v geograficky primárních i geografických sekundárních lokalitách musí být stejné ve výpočetních prostředcích a kapacitě a také nasazené na stejné úrovni služby.
Při vytváření konfigurace zotavení po havárii, která je přístupná oběma clustery, které hostují instanci, rozhodněte o umístění, ve kterém se mají ukládat zrcadlené certifikáty.
Zvažte, jak monitorovat výpadky primární instance, abyste se rozhodli, kdy provést převzetí služeb při selhání sekundární instance.
Každá instance má 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í doporučení k návrhu 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 služby SQL Managed Instance s podporou arc vždy definujte třídu úložiště pro zálohy, abyste se vyhnuli výchozímu nastavení třídy úložiště dat.
Pro svazek záloh použijte třídu úložiště, která podporuje ReadWriteMany (RWX). Pokyny najdete v disciplínách úložiště pro službu SQL Managed Instance s podporou služby Azure Arc.
Před zahájením operace obnovení nejprve pomocí volitelného parametru --dry-run ověřte, jestli by operace proběhla ú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é potřebují delší dobu uchovávání do Azure nebo jiného místního studeného úložiště.
Monitorujte úložiště, které vaše zálohy spotřebovávají, a zjistěte, jestli můžete v případě potřeby pojmout delší uchovávání.
Vysoká dostupnost
Proveďte pravidelné procházení, abyste ověřili vysokou dostupnost vaší instance SQL Managed Instance s podporou Arc. Příklady přechodu k podrobnostem zahrnují 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 dvou replik, abyste dosáhli téměř nulové ztráty dat.
Pro lepší dostupnost použijte LoadBalancer jako typ služby při nasazování instance.
Projděte si omezení vysoké dostupnosti služby SQL Managed Instance s podporou služby Azure Arc.
Projděte si podporované režimy dostupnosti a rozhodněte se, který režim se má 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 jednu ze sekundárních replik pro úlohy čtení. Aplikace připojovací řetězec musí jako naslouchací proces služby zadat sekundární koncový bod pro přesměrování na sekundární repliky. Informace o koncových bodech najdete v tématu Získání primárních a sekundárních koncových bodů a stavu skupiny dostupnosti.
Vysvětlení osvědčených postupů pro monitorování dostupnosti vašich instancí najdete v tématu Správa a monitorování pro spravovanou instanci SQL s podporou služby Azure Arc.
Zotavení po havárii
Ujistěte se, že vaše instance služby SQL Managed Instance s podporou arc mají různé názvy primárních a sekundárních lokalit a že hodnota sdíleného názvu pro lokality 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í.
Pokud chcete porozumět osvědčeným postupům pro monitorování stavu clusterů a zjistit, kdy se vyžaduje převzetí služeb při selhání, přečtěte si téma Správa a monitorování pro spravovanou instanci SQL s podporou služby Azure Arc.
Definujte záznam DNS pro sdílený název distribuované skupiny dostupnosti na serverech DNS, abyste nemuseli během převzetí služeb při selhání ručně vytvářet záznamy DNS.
Další kroky
Další informace o cestě k hybridnímu a multicloudovém cloudu najdete v následujících článcích:
- Co jsou datové služby s podporou Azure Arc?
- Přehled: Provozní kontinuita služby SQL Managed Instance s podporou služby Azure Arc
- Ověřování datových služeb s podporou Azure Arc Kubernetes
- Správa portfolia napříč hybridními a multicloudovými operacemi
- Datové služby s podporou Služby Azure Arc pro automatizované scénáře s využitím rychlého startu Azure Arc
- Používání inovací Azure do hybridních prostředí pomocí Azure Arc, studijního programu z Microsoft Learn