Použití skupin s automatickým převzetím služeb při selhání k umožnění transparentního a koordinovaného geografického převzetí služeb

PLATÍ PRO: Azure SQL Database Azure SQL Managed Instance

Funkce skupin automatického převzetí služeb při selhání umožňuje spravovat replikaci a převzetí služeb při selhání skupiny databází na serveru nebo všech databází ve spravované instanci do jiné oblasti. Jedná se o deklarativní abstrakci nad stávající aktivní geografickou replikací , která je navržená tak, aby zjednodušila nasazení a správu geograficky replikovaných databází se škálováním. Geografické převzetí služeb při selhání můžete iniciovat ručně nebo je můžete delegovat na službu Azure na základě uživatelsky definované zásady. druhá možnost umožňuje automaticky obnovit více souvisejících databází v sekundární oblasti po závažných chybách nebo jiné neplánované události, které mají za následek úplnou nebo částečnou ztrátu SQL Database nebo SQL dostupnosti spravované Instance v primární oblasti. Skupina převzetí služeb při selhání může zahrnovat jednu nebo více databází, které obvykle používá stejná aplikace. Kromě toho můžete použít čitelné sekundární databáze pro přesměrování zatížení dotazů jen pro čtení.

Pokud používáte skupiny s automatickým převzetím služeb při selhání se zásadami automatického převzetí služeb při selhání, výpadek, který ovlivňuje jednu nebo více databází ve skupině, bude mít za následek automatické geografické převzetí služeb při selhání. Obvykle se jedná o výpadky, které nemůžou automaticky zmírnit integrovaná infrastruktura vysoké dostupnosti. příklady aktivačních událostí geografického převzetí služeb při selhání zahrnují incident způsobený SQL Databasem okruhem tenanta nebo řídicím cyklem v důsledku nevracení paměti jádra operačního systému na výpočetních uzlech nebo incidentu, který vychází z jednoho nebo více okruhů tenantů, protože při běžném vyřazení hardwaru došlo k náhodnému vyjmutí nesprávného síťového kabelu. další informace najdete v tématu SQL Database vysoké dostupnosti.

Skupiny s automatickým převzetím služeb při selhání poskytují koncové body naslouchacího procesu pro čtení i zápis a jen pro čtení, které během geografického převzetí služeb při selhání zůstaly beze změny. Bez ohledu na to, jestli používáte ruční nebo automatickou aktivaci převzetí služeb při selhání, se geografické převzetí služeb při selhání přepne mezi sekundární databáze ve skupině do primární role. Po dokončení geografického převzetí služeb při selhání se záznam DNS automaticky aktualizuje a přesměruje koncové body do nové oblasti. Informace o geografickém převzetí služeb při selhání RPO a RTO najdete v tématu Přehled provozní kontinuity.

Pokud používáte skupiny s automatickým převzetím služeb při selhání se zásadami automatického převzetí služeb při selhání, výpadek, který ovlivňuje databáze na serveru nebo spravované instance, způsobí automatické geografické převzetí služeb při selhání.

Skupinu automatického převzetí služeb při selhání můžete spravovat pomocí:

• Azure Portal
• Azure CLI: Skupina převzetí služeb při selhání
• PowerShell: Skupina převzetí služeb při selhání
• REST API: Skupina převzetí služeb při selhání

Při konfiguraci skupiny převzetí služeb při selhání zajistěte, aby byl ověřování a přístup k síti u sekundární sítě nastavený na správné fungování po geografickém převzetí služeb při selhání, když se geografická sekundární stala novou primární. podrobnosti najdete v tématu SQL Database security po zotavení po havárii.

Aby se dosáhlo plné provozní kontinuity, Přidání redundance místní databáze je jenom součástí řešení. Kompletní obnovení aplikace (služby) po závažných chybách vyžaduje obnovení všech součástí, které tvoří službu a všechny závislé služby. Mezi tyto komponenty patří klientský software (například prohlížeč s vlastním JavaScriptem), webové front-endy, úložiště a DNS. Je velmi důležité, aby všechny součásti byly odolné vůči stejnou selhání a byly k dispozici v rámci plánované doby obnovení (RTO) vaší aplikace. Proto je potřeba identifikovat všechny závislé služby a porozumět zárukám a funkcím, které poskytují. Pak musíte provést vhodné kroky, abyste zajistili, že vaše služba funguje při převzetí služeb při selhání služeb, na kterých závisí. Další informace o návrhu řešení pro zotavení po havárii najdete v tématu navrhování cloudových řešení pro zotavení po havárii pomocí aktivní geografické replikace.

Terminologie a funkce skupiny převzetí služeb při selhání

• Skupina převzetí služeb při selhání (MLHOVé)

  Skupina převzetí služeb při selhání je pojmenovaná skupina databází spravovaná jedním serverem nebo ve spravované instanci, která může převzít služby při selhání jako jednotka v jiné oblasti v případě, že všechny nebo některé primární databáze nebudou k dispozici z důvodu výpadku v primární oblasti. když je vytvořená pro SQL Managed Instance, skupina převzetí služeb při selhání obsahuje všechny uživatelské databáze v instanci, a proto se v instanci dá nakonfigurovat jenom jedna skupina převzetí služeb při selhání.

  Důležité

  Název skupiny převzetí služeb při selhání musí být globálně jedinečný v rámci .database.windows.net domény.

• Servery

  Některé nebo všechny uživatelské databáze na logickém serveru lze umístit do skupiny převzetí služeb při selhání. Server také podporuje více skupin převzetí služeb při selhání na jednom serveru.

• Primární

  Server nebo spravovaná instance, která je hostitelem primárních databází ve skupině převzetí služeb při selhání.

• Sekundární

  Server nebo spravovaná instance hostující sekundární databáze ve skupině převzetí služeb při selhání. Sekundární nemůže být ve stejné oblasti jako primární.

• Přidávání samostatných databází do skupiny převzetí služeb při selhání

  Do stejné skupiny převzetí služeb při selhání můžete umístit několik samostatných databází na stejný server. Pokud přidáte do skupiny převzetí služeb při selhání jednu databázi, automaticky vytvoří sekundární databázi pomocí stejné edice a výpočetní velikosti na sekundárním serveru. Tento server jste zadali při vytvoření skupiny převzetí služeb při selhání. Pokud přidáváte databázi, která už má sekundární databázi na sekundárním serveru, toto propojení geografické replikace je zděděné skupinou. Když přidáváte databázi, která už má sekundární databázi na serveru, který není součástí skupiny převzetí služeb při selhání, vytvoří se na sekundárním serveru nový sekundární objekt.

  Důležité

  Ujistěte se, že sekundární server nemá databázi se stejným názvem, pokud se nejedná o existující sekundární databázi. v případě skupin převzetí služeb při selhání pro SQL spravovaná Instance se replikují všechny uživatelské databáze. V této skupině převzetí služeb při selhání nelze vybrat podmnožinu uživatelských databází pro replikaci.

• Přidání databází do elastického fondu do skupiny převzetí služeb při selhání

  Do jedné skupiny převzetí služeb při selhání můžete umístit všechny nebo několik databází v rámci elastického fondu. Pokud je primární databáze v elastickém fondu, sekundární se automaticky vytvoří v elastickém fondu se stejným názvem (sekundární fond). Je nutné zajistit, aby sekundární server obsahoval elastický fond se stejným přesným názvem a dostatek volné kapacity pro hostování sekundárních databází, které budou vytvořeny skupinou převzetí služeb při selhání. Pokud přidáte databázi do fondu, který již má sekundární databázi v sekundárním fondu, bude tento odkaz geografická replikace zděděn skupinou. Když přidáváte databázi, která už má sekundární databázi na serveru, který není součástí skupiny převzetí služeb při selhání, vytvoří se v sekundárním fondu nový sekundární objekt.

• Počáteční osazení

  Když přidáváte databáze, elastické fondy nebo spravované instance do skupiny převzetí služeb při selhání, před spuštěním replikace dat se vytvoří prvotní fáze osazení. Počáteční fáze osazení je nejdelší a nejnáročná operace. Po dokončení počátečního osazení se data synchronizují a pak se replikují jenom následné změny dat. Čas potřebný k dokončení počátečního osazení závisí na velikosti vašich dat, počtu replikovaných databází, zatížení primárních databází a rychlosti propojení mezi primárním a sekundárním serverem. za běžných okolností je možná rychlost osazení až 500 gb hodiny pro SQL Database a až 360 gb za hodinu pro SQL Managed Instance. Osazení se provádí pro všechny databáze paralelně.

  v případě SQL spravované Instance zvažte rychlost propojení Express Route mezi dvěma instancemi při odhadování doby prvotní fáze osazení. V případě, že rychlost propojení mezi dvěma instancemi je pomalejší, než je potřeba, je pravděpodobné, že čas na počáteční hodnotu bude znamenat dopad. Můžete použít uvedenou rychlost osazení, počet databází, celkovou velikost dat a rychlost připojení k odhadu, jak dlouho bude prvotní fáze osazení trvat před spuštěním replikace dat. Například pro jednu 100 GB databáze by počáteční fáze osazení trvat přibližně 1,2 hodin, pokud je odkaz 84 schopný přenášet GB za hodinu, a pokud nejsou osazené žádné jiné databáze. Pokud odkaz může přenášet jenom 10 GB za hodinu, pak bude dosazení 100 GB databáze trvat přibližně 10 hodin. Pokud existuje více databází k replikaci, je osazení provedeno paralelně a při kombinaci s pomalým připojením může prvotní fáze osazení trvat mnohem déle, zejména v případě, že paralelní osazení dat ze všech databází přesahuje dostupnou šířku pásma propojení. Pokud je šířka pásma sítě mezi dvěma instancemi omezená a do skupiny převzetí služeb při selhání přidáváte víc spravovaných instancí, zvažte postupně přidání více spravovaných instancí do skupiny převzetí služeb při selhání, jednu po druhé. Vzhledem k odpovídající velikosti skladové položky brány mezi dvěma spravovanými instancemi a v případě, že šířka pásma podnikové sítě umožňuje, je možné dosáhnout rychlostí až 360 GB hodiny.

• Zóna DNS

  jedinečné ID, které se automaticky vygeneruje při vytvoření nové spravované Instance SQL. Pro tuto instanci se zřídí certifikát s více doménami (SAN) pro ověřování připojení klientů k jakékoli instanci ve stejné zóně DNS. Tyto dvě spravované instance ve stejné skupině převzetí služeb při selhání musí sdílet zónu DNS.

  Poznámka

  Pro skupiny s podporou převzetí služeb při selhání vytvořené pro SQL Database se nevyžaduje ID zóny DNS.

• Naslouchací proces pro čtení a zápis skupiny převzetí služeb při selhání

  Záznam DNS CNAME, který odkazuje na aktuální primární. Automaticky se vytvoří při vytvoření skupiny převzetí služeb při selhání a umožňuje úlohám čtení i zápisu transparentně se znovu připojit k primárnímu objektu, když se po převzetí služeb při selhání primární změny změní. Když je na serveru vytvořená skupina převzetí služeb při selhání, bude záznam CNAME DNS pro adresu URL naslouchacího procesu vytvořený jako <fog-name>.database.windows.net . pokud je skupina převzetí služeb při selhání vytvořena na spravované instanci SQL, bude záznam CNAME DNS pro adresu URL naslouchacího procesu vytvořený jako <fog-name>.<zone_id>.database.windows.net .

• Skupina převzetí služeb při selhání – naslouchací proces jen pro čtení

  Záznam DNS CNAME, který odkazuje na aktuální sekundární položku. automaticky se vytvoří při vytvoření skupiny převzetí služeb při selhání a umožňuje, aby se při převzetí služeb při selhání sekundárním způsobem připojovaly k sekundárnímu připojení k sekundárnímu objektu SQL jen pro čtení. Když je na serveru vytvořená skupina převzetí služeb při selhání, bude záznam CNAME DNS pro adresu URL naslouchacího procesu vytvořený jako <fog-name>.secondary.database.windows.net . pokud je skupina převzetí služeb při selhání vytvořena na spravované instanci SQL, bude záznam CNAME DNS pro adresu URL naslouchacího procesu vytvořený jako <fog-name>.secondary.<zone_id>.database.windows.net .

• Zásady automatického převzetí služeb při selhání

  Ve výchozím nastavení je skupina převzetí služeb při selhání nakonfigurovaná se zásadami automatického převzetí služeb při selhání. Po zjištění selhání systém aktivuje geografické převzetí služeb při selhání a vypršela lhůta odkladu. Systém musí ověřit, jestli se výpadek nedá zmírnit vestavěnou infrastrukturou vysoké dostupnosti, například kvůli škále dopadu. Pokud chcete řídit pracovní postup geografického převzetí služeb při selhání z aplikace nebo ručně, můžete vypnout zásady automatického převzetí služeb při selhání.

  Poznámka

  Vzhledem k tomu, že ověřování škály výpadku a jak rychle se dá zmírnit, zahrnuje lidské akce, období odkladu nelze nastavit pod jednu hodinu. Toto omezení se vztahuje na všechny databáze ve skupině převzetí služeb při selhání bez ohledu na stav synchronizace dat.

• Zásada převzetí služeb při selhání jen pro čtení

  Ve výchozím nastavení je převzetí služeb při selhání naslouchacího procesu jen pro čtení zakázané. Zajišťuje, že výkon primárního z těchto primárních není ovlivněný, když je sekundární objekt v režimu offline. Ale také to znamená, že relace jen pro čtení se nebudou moci připojit až po obnovení sekundárního zařízení. Pokud nemůžete tolerovat výpadky u relací jen pro čtení a můžete použít primární pro provoz jen pro čtení i pro čtení i zápis na úkor možného snížení výkonu primární služby, můžete povolit převzetí služeb při selhání pro naslouchací proces jen pro čtení konfigurací AllowReadOnlyFailoverToPrimary Vlastnosti. V takovém případě bude přenos, který je jen pro čtení, automaticky přesměrován na primární, pokud není k dispozici sekundární.

  Poznámka

  AllowReadOnlyFailoverToPrimaryVlastnost má vliv jenom v případě, že jsou povolené zásady automatického převzetí služeb při selhání a aktivovaly se automatické geografické převzetí služeb při selhání. V takovém případě, pokud je vlastnost nastavena na hodnotu true, bude nová primární aplikace sloužit pouze pro čtení i zápis i relace jen pro čtení.

• Plánované převzetí služeb při selhání

  Plánované převzetí služeb při selhání provádí úplnou synchronizaci dat mezi primárními a sekundárními databázemi před sekundárními přepínači primární role. To zaručuje, že nedojde ke ztrátě dat. Plánované převzetí služeb při selhání se používá v následujících scénářích:

  • Podrobná cvičení při zotavení po havárii (DR) v produkčním prostředí, když je ztráta dat nepřijatelná
  • Přemístit databáze do jiné oblasti
  • Obnovení databází do primární oblasti po omezení výpadku (navrácení služeb po obnovení)

• Neplánované převzetí služeb při selhání

  Neplánované nebo vynucené převzetí služeb při selhání se okamžitě přepne sekundární na primární roli bez čekání na rozšíření nedávných změn z primární služby. Tato operace může způsobit ztrátu dat. Neplánované převzetí služeb při selhání se používá jako metoda obnovení během výpadků, pokud není primární přístup k primárnímu přístupu. V případě zmírnění výpadku se stará primární primární databáze automaticky znovu připojí a stane se novou sekundární. Plánované převzetí služeb při selhání může být spuštěno, aby se vracely tyto repliky na původní primární a sekundární role.

• Ruční převzetí služeb při selhání

  Geografické převzetí služeb při selhání můžete kdykoli iniciovat ručně bez ohledu na konfiguraci automatického převzetí služeb při selhání. Při výpadku, který ovlivňuje primární, pokud není nakonfigurovaná Automatická zásada převzetí služeb při selhání, je potřeba ruční převzetí služeb při selhání pro zvýšení sekundární role na primární roli. Můžete iniciovat vynucené (neplánované) nebo přívětivé (plánované) převzetí služeb při selhání. Přívětivé převzetí služeb při selhání je možné jenom v případě, že je původní primární přístup dostupný a dá se použít k přemístění primární do sekundární oblasti, aniž by došlo ke ztrátě dat. Po dokončení převzetí služeb při selhání se záznamy DNS automaticky aktualizují, aby se zajistilo připojení k nové primární službě.

• Období odkladu s ztrátou dat

  Vzhledem k tomu, že jsou sekundární databáze synchronizovány pomocí asynchronní replikace, může dojít ke ztrátě dat z automatického geografického převzetí služeb při selhání. Zásady automatického převzetí služeb při selhání můžete přizpůsobit tak, aby odrážely odolnost vaší aplikace proti ztrátě dat. Konfigurací nástroje GracePeriodWithDataLossHours můžete určit, jak dlouho systém počká, než se iniciuje vynucené převzetí služeb při selhání, což může způsobit ztrátu dat.

• Několik skupin převzetí služeb při selhání

  Můžete nakonfigurovat více skupin převzetí služeb při selhání pro stejnou dvojici serverů pro řízení rozsahu geografického převzetí služeb při selhání. U každé skupiny dojde k selhání nezávisle. Pokud je vaše aplikace tenanta nasazená v několika oblastech a využívá elastické fondy, můžete tuto možnost využít ke smíchání primárních a sekundárních databází v jednotlivých fondech. Tímto způsobem může být možné snížit dopad výpadku jenom na některé databáze tenantů.

  Poznámka

  SQL Spravovaná instance nepodporuje více skupin převzetí služeb při selhání.

Oprávnění

Oprávnění pro skupinu převzetí služeb při selhání se spravují prostřednictvím řízení přístupu na základě role Azure (RBAC). role přispěvatel SQL Server má všechna potřebná oprávnění ke správě skupin převzetí služeb při selhání.

Vytvoření skupiny převzetí služeb při selhání

Pokud chcete vytvořit skupinu převzetí služeb při selhání, potřebujete přístup k zápisu do Azure RBAC na primární i sekundární servery i do všech databází ve skupině převzetí služeb při selhání. u SQL spravované instance potřebujete přístup k zápisu v rámci Azure RBAC do spravované instance primárního i sekundárního SQL, ale oprávnění k jednotlivým databázím nejsou relevantní, protože SQL samostatné databáze spravované Instance se nedají do skupiny převzetí služeb při selhání přidávat ani je z ní odebírat.

Aktualizace skupiny převzetí služeb při selhání

Pokud chcete aktualizovat skupinu převzetí služeb při selhání, potřebujete přístup k zápisu do skupiny převzetí služeb při selhání pomocí Azure RBAC a všech databází na aktuálním primárním serveru nebo spravované instanci.

Převzít služby při selhání skupiny převzetí služeb při selhání

Pokud chcete převzít služby při selhání skupiny převzetí služeb při selhání, potřebujete přístup k zápisu do skupiny převzetí služeb při selhání na novém primárním serveru nebo spravované instanci.

Osvědčené postupy pro skupinu převzetí služeb při selhání pro SQL Database

Skupina automatického převzetí služeb při selhání musí být nakonfigurovaná na primárním serveru a bude připojena k sekundárnímu serveru v jiné oblasti Azure. Skupiny mohou obsahovat všechny nebo některé databáze na těchto serverech. Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace s využitím více databází a skupiny s automatickým převzetím služeb při selhání.

Při navrhování služby s ohledem na provozní kontinuitu se řiďte těmito obecnými pokyny:

Použití jedné nebo několika skupin převzetí služeb při selhání pro správu převzetí služeb při selhání více databází

Jednu nebo více skupin s podporou převzetí služeb při selhání je možné vytvořit mezi dvěma servery v různých oblastech (primární a sekundární servery). Každá skupina může zahrnovat jednu nebo několik databází, které jsou obnoveny jako jednotka v případě výpadku v primární oblasti, nebo některé primární databáze nebudou k dispozici. Při vytvoření skupiny převzetí služeb při selhání se vytvoří geograficky sekundární databáze se stejným cílem služby jako primární. Pokud přidáte existující vztah geografické replikace do skupiny převzetí služeb při selhání, ujistěte se, že je geograficky sekundární nakonfigurovaná se stejnou úrovní služeb a výpočetní velikostí jako primární.

Použití naslouchacího procesu pro čtení i zápis pro připojení k primárnímu

Pro úlohy pro čtení i zápis použijte <fog-name>.database.windows.net jako název serveru v připojovacím řetězci. Připojení se automaticky přesměrují na primární. Po převzetí služeb při selhání se tento název nezmění. Všimněte si, že při převzetí služeb při selhání je potřeba aktualizovat záznam DNS, aby se připojení klientů přesměrovala na nové primární až po aktualizaci mezipaměti DNS klienta. Hodnota TTL (Time to Live) primárního a sekundárního záznamu DNS naslouchacího procesu je 30 sekund.

Použití naslouchacího procesu jen pro čtení k připojení k geografickému sekundárnímu

Pokud máte logicky izolované úlohy jen pro čtení, které jsou odolné vůči latenci dat, můžete je spustit na geograficky sekundární. V případě relací jen pro čtení použijte <fog-name>.secondary.database.windows.net jako název serveru v připojovacím řetězci. Připojení budou automaticky směrována k geografickému sekundárnímu. Je také vhodné určit záměr čtení v připojovacím řetězci pomocí ApplicationIntent=ReadOnly .

Potenciální snížení výkonu po geografickém převzetí služeb při selhání

Typická aplikace Azure používá několik služeb Azure a skládá se z několika součástí. automatické geografické převzetí služeb při selhání ve skupině převzetí služeb při selhání se aktivuje v závislosti na stavu samotných komponent Azure SQL. Jiné služby Azure v primární oblasti nemusí být ovlivněny výpadkem a jejich komponenty mohou být v této oblasti stále dostupné. Po přepnutí primárních databází do sekundární oblasti (DR) se může zvýšit latence mezi závislými komponentami. Aby se zabránilo dopadu vyšší latence na výkon aplikace, zajistěte redundanci všech komponent aplikace v oblasti zotavení po havárii podle těchto pokynů pro zabezpečení sítěa orchestrujte geografické převzetí služeb při selhání relevantních komponent aplikace spolu s databází.

Potenciální ztráta dat po geografickém převzetí služeb při selhání

Pokud dojde k výpadku v primární oblasti, nedávné transakce nemusí být schopné replikovat na geograficky sekundární. Pokud je nakonfigurovaná zásada automatického převzetí služeb při selhání, systém počká, GracePeriodWithDataLossHours než se před zahájením automatického geografického převzetí služeb při selhání zadalo zadané období. Výchozí hodnota je 1 hodina. Tím se upřednostní dostupnost databáze při žádné ztrátě dat. Nastavení GracePeriodWithDataLossHours na větší číslo, například 24 hodin nebo vypnutí automatického geografického převzetí služeb při selhání, umožňuje snížit pravděpodobnost ztráty dat na úkor dostupnosti databáze.

Změna sekundární oblasti skupiny převzetí služeb při selhání

K ilustraci sekvence změn se předpokládá, že server A je primárním serverem, server B je stávající sekundární server a Server C je nový sekundární ve třetí oblasti. Pro přechod proveďte následující kroky:

1. Pomocí aktivní geografické replikacevytvořte další sekundární databáze pro každou databázi na serveru A na server C. Každá databáze na serveru A bude mít dvě sekundární, jednu na serveru B a jednu na server C. Tím se zajistí, že primární databáze zůstanou chráněné během přechodu.
2. Odstraňte skupinu převzetí služeb při selhání. V tomto okamžiku se pokusy o přihlášení pomocí koncových bodů skupiny převzetí služeb při selhání budou zdařit.
3. Znovu vytvořte skupinu převzetí služeb při selhání se stejným názvem mezi servery A a C.
4. Přidejte všechny primární databáze na serveru A do nové skupiny převzetí služeb při selhání. V tomto okamžiku pokusy o přihlášení přestanou selhávající.
5. Odstraňte server B. Všechny databáze na B se odstraní automaticky.

Změna primární oblasti skupiny převzetí služeb při selhání

Pro ilustraci pořadí změn budeme předpokládat, že server A je primární server, server B je existující sekundární server a server C je nový primární server ve třetí oblasti. Pokud chcete provést přechod, postupujte takto:

1. Proveďte plánované geografické převzetí služeb při selhání a přepněte primární server na B. Server A se stane novým sekundárním serverem. Převzetí služeb při selhání může vést k několikaminutové prostojům. Skutečný čas bude záviset na velikosti skupiny převzetí služeb při selhání.
2. Vytvořte další sekundy každé databáze na serveru B na serveru C pomocí aktivní geografické replikace. Každá databáze na serveru B bude mít dvě sekundy, jednu na serveru A a jednu na serveru C. Tím se zajistí, že primární databáze zůstanou během přechodu chráněné.
3. Odstraňte skupinu převzetí služeb při selhání. V tomto okamžiku budou neúspěšné pokusy o přihlášení pomocí koncových bodů skupiny převzetí služeb při selhání.
4. Znovu vytvořte skupinu převzetí služeb při selhání se stejným názvem mezi servery B a C.
5. Přidejte všechny primární databáze na B do nové skupiny převzetí služeb při selhání. V tomto okamžiku pokusy o přihlášení přestanou selhávající.
6. Proveďte plánované geografické převzetí služeb při selhání skupiny převzetí služeb při selhání a přepněte B a C. Server C se teď stane primárním serverem a B sekundárním serverem. Všechny sekundární databáze na serveru A budou automaticky propojeny se sekundárními databázemi v jazyce C. Stejně jako v kroku 1 může převzetí služeb při selhání způsobit několik minut výpadků.
7. Odstraňte server A. Všechny databáze v A se odstraní automaticky.

Osvědčené postupy pro skupiny převzetí služeb při selhání SQL spravované instanci

Skupina automatického převzetí služeb při selhání musí být nakonfigurovaná na primární instanci, kterou připojí k sekundární instanci v jiné oblasti Azure. Všechny uživatelské databáze v instanci se replikují do sekundární instance. Systémové databáze, jako jsou hlavní databáze a msdb, se nereplikují.

Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace s využitím spravované instance a skupiny automatického převzetí služeb při selhání.

Pokud vaše aplikace používá SQL spravovanou instanci jako datovou vrstvu, při návrhu pro zajištění kontinuity podnikových dat postupujte podle těchto obecných pokynů:

Vytvoření spravované instance v sekundární geografické lokalitě

Aby se zajistilo nepřerušované připojení k primární SQL spravované instanci po převzetí služeb při selhání, musí být primární i sekundární instance ve stejné zóně DNS. Zaručí se, že se k ověření připojení klientů k jedné ze dvou instancí ve skupině převzetí služeb při selhání bude možné použít stejný certifikát SAN (multi-domain certificate). Až bude vaše aplikace připravená k produkčnímu nasazení, vytvořte sekundární spravovanou instanci SQL v jiné oblasti a ujistěte se, že sdílí zónu DNS s primární SQL Managed Instance. Můžete to provést zadáním volitelného parametru během vytváření. Pokud používáte PowerShell nebo REST API, je název volitelného parametru DNSZonePartner . Název odpovídajícího volitelného pole v poli Azure Portal je Primární spravovaná instance.

Další informace o vytvoření sekundární instance SQL ve stejné zóně DNS jako primární instance najdete v tématu Vytvoření sekundární spravované instance.

Použití spárovaných oblastí

Z důvodu výkonu nasaďte obě spravované instance do spárovaných oblastí. SQL Skupiny převzetí služeb při selhání spravované instance ve spárovaných oblastech mají v porovnání s ne spárovanými oblastmi lepší výkon.

Povolení provozu geografické replikace mezi dvěma spravovanými instancemi

Vzhledem k tomu, že je každá spravovaná instance izolovaná ve své vlastní virtuální síti, musí být mezi těmito virtuálními sítěmi povolen obousměrný provoz. Viz Azure VPN Gateway.

Vytvoření skupiny převzetí služeb při selhání mezi spravovanými instancemi v různých předplatných

Skupinu převzetí služeb při selhání můžete vytvořit mezi SQL instancemi ve dvou různých předplatných, pokud jsou předplatná přidružená ke stejnému Azure Active Directory tenantovi. Pokud používáte rozhraní API PowerShellu, můžete to udělat zadáním parametru pro sekundární instanci PartnerSubscriptionId SQL spravované instance. Při použití REST API, každé ID instance zahrnuté v properties.managedInstancePairs parametru může mít své vlastní ID předplatného.

Správa geografické služby při selhání do instance v sekundární geografické lokalitě

Skupina převzetí služeb při selhání bude spravovat geografické převzetí služeb při selhání všech databází v primární spravované instanci. Při vytvoření skupiny se každá databáze v instanci automaticky geograficky replikuje do instance v sekundární geografické oblasti. Skupiny převzetí služeb při selhání nelze použít k zahájení částečného převzetí služeb při selhání podmnožiny databází.

Připojení k primární spravované instanci pomocí naslouchacího procesu pro čtení i zápis

Pro úlohy čtení i zápisu použijte <fog-name>.zone_id.database.windows.net jako název serveru. Připojení budou automaticky směrována na primární. Tento název se po převzetí služeb při selhání nezmění. Geografické převzetí služeb při selhání zahrnuje aktualizaci záznamu DNS, takže připojení klientů se přesměrují na novou primární instanci až po aktualizaci mezipaměti DNS klienta. Vzhledem k tomu, že sekundární instance sdílí zónu DNS s primární instancí, klientská aplikace se k ní bude moct znovu připojit pomocí stejného certifikátu SAN na straně serveru.

Připojení k geograficky sekundární spravované instanci pomocí naslouchacího procesu jen pro čtení

Pokud máte logicky izolované úlohy jen pro čtení, které jsou tolerantní k latenci dat, můžete je spustit v sekundární geografické lokalitě. Pokud se chcete připojit přímo k sekundární geografické lokalitě, <fog-name>.secondary.<zone_id>.database.windows.net použijte jako název serveru .

Potenciální snížení výkonu po převzetí služeb při selhání do geograficky sekundární spravované instance

Typická aplikace Azure používá více služeb Azure a skládá se z několika komponent. Automatické geografické převzetí služeb při selhání skupiny převzetí služeb při selhání se aktivuje na základě stavu, ve SQL azure. Výpadkem nemusí být ovlivněny jiné služby Azure v primární oblasti a jejich komponenty mohou být v této oblasti stále dostupné. Jakmile primární databáze přepněte na sekundární oblast, může se zvýšit latence mezi závislými komponentami. Pokud se chcete vyhnout dopadu vyšší latence na výkon aplikace, zajistěte redundanci všech komponent aplikace v sekundární oblasti a převzetí služeb při selhání komponent aplikace společně s databází. V době konfigurace postupujte podle pokynů pro zabezpečení sítě, abyste zajistili připojení k databázi v sekundární oblasti.

Potenciální ztráta dat po převzetí služeb při selhání do geograficky sekundární spravované instance

Pokud dojde k výpadku v primární oblasti, poslední transakce nemusí být schopné replikovat do sekundární geografické oblasti. Pokud jsou nakonfigurované zásady automatického převzetí služeb při selhání, aktivuje se geografické převzetí služeb při selhání, pokud dojde k nulové ztrátě dat, podle našich znalostí. Jinak se převzetí služeb při selhání odkládá po dobu, kterou zadáte pomocí GracePeriodWithDataLossHours . Pokud jste nakonfigurovali zásady automatického převzetí služeb při selhání, připravte se na ztrátu dat. Obecně platí, že během výpadků Azure upřednostní dostupnost. Pokud nastavíte větší počet, třeba 24 hodin, nebo zakážete automatické geografické převzetí služeb při selhání, snížíte pravděpodobnost ztráty dat na úkor GracePeriodWithDataLossHours dostupnosti databáze.

K aktualizaci DNS naslouchacího procesu pro čtení i zápis dojde okamžitě po zahájení převzetí služeb při selhání. Tato operace nesnídá data. Proces přepínání databázových rolí však může za normálních podmínek trvat až 5 minut. Dokud se nedokončí, některé databáze v nové primární instanci budou i nadále jen pro čtení. Pokud se převzetí služeb při selhání zahájí pomocí PowerShellu, je operace přepnutí role primární repliky synchronní. Pokud se iniciuje pomocí Azure Portal, uživatelské rozhraní bude indikovat stav dokončení. Pokud se iniciuje pomocí REST API, použijte k monitorování dokončení Azure Resource Manager standardního monitorovacího mechanismu dotazování.

Změna sekundární oblasti skupiny převzetí služeb při selhání spravované instance

Předpokládejme, že instance A je primární instancí, instance B je existující sekundární instance a instance C je nová sekundární instance ve třetí oblasti. Pokud chcete provést přechod, postupujte takto:

1. Vytvořte instanci C se stejnou velikostí jako A a ve stejné zóně DNS.
2. Odstraňte skupinu převzetí služeb při selhání mezi instancemi A a B. V tomto okamžiku budou přihlášení selhávající, protože aliasy SQL pro naslouchací objekty skupiny převzetí služeb při selhání byly odstraněny a brána nerozpozná název skupiny převzetí služeb při selhání. Sekundární databáze se odpojí od databází a stanou se databázemi pro čtení i zápis.
3. Vytvořte skupinu převzetí služeb při selhání se stejným názvem mezi instancí A a C. Postupujte podle pokynů v kurzu skupiny převzetí služeb při selhání SQL managed instance. Jedná se o operaci velikosti dat, která se dokončí, když se všechny databáze z instance A osedí a synchronizují.
4. Pokud není potřeba, odstraňte instanci B, abyste se vyhnuli zbytečným poplatkům.

Změna primární oblasti skupiny převzetí služeb při selhání spravované instance

Předpokládejme, že primární instancí je instance A, instance B je existující sekundární instance a instance C je nová primární instance ve třetí oblasti. Pokud chcete provést přechod, postupujte takto:

1. Vytvořte instanci C se stejnou velikostí jako B a ve stejné zóně DNS.
2. Připojení instance B a ručním převzetím služeb při selhání přepnout primární instanci na B. Instance A se automaticky stane novou sekundární instancí.
3. Odstraňte skupinu převzetí služeb při selhání mezi instancemi A a B. V tomto okamžiku budou neúspěšné pokusy o přihlášení pomocí koncových bodů skupiny převzetí služeb při selhání. Sekundární databáze v A se odpojí od databází a stanou se databázemi pro čtení i zápis.
4. Vytvořte skupinu převzetí služeb při selhání se stejným názvem mezi instancí A a C. Postupujte podle pokynů v kurzu skupiny převzetí služeb při selhání se spravovanou instancí. Jedná se o operaci velikosti dat, která se dokončí, když se všechny databáze z instance A osedí a synchronizují. V tomto okamžiku se pokusy o přihlášení přestanou selhávající.
5. Pokud není potřeba, odstraňte instanci A, abyste se vyhnuli zbytečným poplatkům.

Povolení scénářů závislých na objektech ze systémových databází

Systémové databáze se nereplikují do sekundární instance ve skupině převzetí služeb při selhání. Pokud chcete povolit scénáře, které závisí na objektech ze systémových databází, nezapomeňte vytvořit stejné objekty v sekundární instanci a udržovat je synchronizované s primární instancí.

Pokud například plánujete používat stejná přihlášení v sekundární instanci, nezapomeňte je vytvořit pomocí stejného sidu.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Synchronizace vlastností instance a zásad uchovávání mezi primární a sekundární instancí

Instance ve skupině převzetí služeb při selhání zůstávají samostatnými prostředky Azure a žádné změny provedené v konfiguraci primární instance se automaticky replikují do sekundární instance. Nezapomeňte provést všechny relevantní změny v primární i sekundární instanci. Pokud například změníte redundanci úložiště zálohování nebo zásady dlouhodobého uchovávání záloh v primární instanci, nezapomeňte ji také změnit v sekundární instanci.

Skupiny převzetí služeb při selhání a zabezpečení sítě

U některých aplikací pravidla zabezpečení vyžadují, aby byl síťový přístup k datové vrstvě omezen na konkrétní komponentu nebo komponenty, jako je virtuální počítač, webová služba atd. Tento požadavek představuje určité výzvy pro návrh kontinuity podnikových služeb a použití skupin převzetí služeb při selhání. Při implementaci takového omezeného přístupu zvažte následující možnosti.

Použití skupin převzetí služeb při selhání a koncových bodů služby pro virtuální síť

Pokud používáte koncové body Virtual Network pravidla služby k omezení přístupu k databázi ve spravované instanci SQL Database nebo SQL, uvědomte si, že každý koncový bod služby pro virtuální síť se vztahuje pouze na jednu oblast Azure. Koncový bod neumožní ostatním oblastem přijímat komunikaci z podsítě. Proto se k primární databázi mohou připojit pouze klientské aplikace nasazené ve stejné oblasti. Vzhledem k tomu, že geografické převzetí služeb při selhání vede k přesměrování relací klienta SQL Database na server v jiné (sekundární) oblasti, tyto relace selžou, pokud pocházejí z klienta mimo oblast. Z tohoto důvodu není možné povolit zásady automatického převzetí služeb při selhání, pokud jsou zúčastněné servery nebo instance zahrnuté v pravidlech Virtual Network převzetí služeb při selhání. Pokud chcete podporovat ruční převzetí služeb při selhání, postupujte takto:

1. Zřizované kopie front-endových komponent vaší aplikace (webová služba, virtuální počítače atd.) v sekundární oblasti.
2. Nakonfigurujte pravidla virtuální sítě jednotlivě pro primární a sekundární server.
3. Povolte převzetí služeb při selhání front-endu pomocí konfigurace Traffic Manageru.
4. Po zjištění výpadku zahajte ruční geografické převzetí služeb při selhání. Tato možnost je optimalizovaná pro aplikace, které vyžadují konzistentní latenci mezi front-endem a datovou vrstvou, a podporuje obnovení v případě, že výpadkem ovlivní front-end, datovou vrstvu nebo obojí.

Použití skupin převzetí služeb při selhání a pravidel brány firewall

Pokud váš plán kontinuity podnikových služeb vyžaduje převzetí služeb při selhání pomocí skupin s automatickým převzetím služeb při selhání, můžete omezit přístup k databázi v SQL Database pomocí pravidel brány firewall pro veřejné IP adresy. Pokud chcete podporovat automatické převzetí služeb při selhání, postupujte takto:

1. Vytvoření veřejné IP adresy
2. Vytvořte veřejný nástroj pro vyrovnávání zatížení a přiřaďte mu veřejnou IP adresu.
3. Vytvořte virtuální síť a virtuální počítače pro front-endové komponenty.
4. Vytvořte skupinu zabezpečení sítě a nakonfigurujte příchozí připojení.
5. Ujistěte se, že jsou odchozí připojení otevřená Azure SQL Database v oblasti, a to pomocí Sql.<Region> značky služby.
6. Vytvořte pravidlo SQL Database firewallu, které povolí příchozí provoz z veřejné IP adresy, kterou vytvoříte v kroku 1.

Další informace o tom, jak nakonfigurovat odchozí přístup a jakou IP adresu použít v pravidlech brány firewall, najdete v tématu Odchozí připojení nástroje pro vyrovnávání zatížení.

Výše uvedená konfigurace zajistí, že automatické geografické převzetí služeb při selhání nebude blokovat připojení z front-endových komponent a bude předpokládat, že aplikace dokáže tolerovat delší latenci mezi front-endem a datovou vrstvou.

Povolení geografické replikace mezi virtuálními sítěmi spravované instance

Když nastavíte skupinu převzetí služeb při selhání mezi primární a sekundární instancí SQL spravovanými instancemi ve dvou různých oblastech, každá instance je izolovaná pomocí nezávislé virtuální sítě. Pokud chcete povolit provoz replikace mezi těmito virtuálními sítěmi, ujistěte se, že jsou splněné tyto požadavky:

• Dvě instance služby SQL musí být v různých oblastech Azure.

• Dvě instance služby SQL musí mít stejnou úroveň služby a stejnou velikost úložiště.

• Sekundární instance spravované instance SQL být prázdná (bez uživatelských databází).

• Virtuální sítě používané instancemi spravované instance SQL musí být připojené přes VPN Gateway nebo Express Route. Pokud jsou tyto dvě virtuální sítě propojené prostřednictvím místní sítě, ujistěte se, že žádné pravidlo firewallu neblokuje porty 5022 a 11000–11999. Globální VNet Peering sice podporovaný je, ale s určitým omezením (viz poznámka níže).

  Důležité

  22. 9. 2020byla oznámena podpora globálního partnerského vztahu virtuálních sítí pro nově vytvořené virtuální clustery. To znamená, že globální peering virtuálních sítí se podporuje pro spravované instance vytvořené v prázdných podsítích po datu oznámení SQL také pro všechny následné spravované instance vytvořené v těchto podsítích. U všech ostatních SQL partnerských vztahů spravovaných instancí je omezená na sítě ve stejné oblasti z důvodu omezení globálního partnerského vztahu virtuálních sítí. Další podrobnosti najdete také v příslušné části článku Nejčastější dotazy k virtuálním sítím Azure. Pokud chcete mít možnost používat globální peer SQL ing virtuálních sítí pro spravované instance z virtuálních clusterů vytvořených před datem oznámení, zvažte konfiguraci jiných než výchozích intervalů údržby pro instance, protože tyto instance se přesunou do nových virtuálních clusterů, které podporují globální partnerský vztah virtuálních sítí.

• Dvě virtuální SQL spravované instance se nesmí překrývat s IP adresami.

• Je potřeba nastavit skupiny zabezpečení sítě (NSG) tak, aby porty 5022 a 11000–12000 byly otevřené pro příchozí i odchozí připojení z podsítě druhé spravované instance. Důvodem je umožnit provoz replikace mezi instancemi.

  Důležité

  Nesprávně nakonfigurovaná pravidla zabezpečení NSG vedou k zablokovaných operacím předsestavování databáze.

• Sekundární instance SQL spravovaná instance nakonfigurovaná se správným ID zóny DNS. Zóna DNS je vlastnost spravované instance SQL základního virtuálního clusteru a její ID je součástí adresy názvu hostitele. ID zóny se vygeneruje jako náhodný řetězec při vytvoření první spravované instance SQL v každé virtuální síti a stejné ID se přiřadí všem ostatním instancím ve stejné podsíti. Po přiřazení není možné zónu DNS upravit. SQL Spravované instance zahrnuté ve stejné skupině převzetí služeb při selhání musí sdílet zónu DNS. Toho dosáhnete předáním ID zóny primární instance jako hodnoty parametru DnsZonePartner při vytváření sekundární instance.

  Poznámka

  Podrobný kurz konfigurace skupin převzetí služeb při selhání s SQL managed instance najdete v tématu přidání spravované instance SQL do skupiny převzetí služeb při selhání.

Škálování primární databáze

Primární databázi můžete škálovat nahoru nebo dolů na jinou velikost výpočetních prostředků (v rámci stejné úrovně služby) bez odpojení geografických sekundárních databází. WPři horizontálním navýšení kapacity doporučujeme nejprve škálovat geograficky sekundární geografickou lokalitu a pak na nahoru primární. Při horizontálním navýšení kapacity v opačném pořadí: nejprve zmenšete primární a pak sekundární zmenšete. Při škálování databáze na jinou úroveň služby se toto doporučení vynucuje.

Toto pořadí se doporučuje zejména proto, abyste se vyhnuli problému, kdy se přetíží geografická sekundární geografická část v nižší SKU a během procesu upgradu nebo downgradu se musí znovu nasadit. Tomuto problému můžete zabránit také tak, že primární instanci nastavíte jen pro čtení – bude to však mít vliv na všechny úlohy čtení z primární instance i zápisu na ni.

Prevence ztráty důležitých dat

Z důvodu vysoké latence sítí WIDE AREA používá geografická replikace mechanismus asynchronní replikace. Asynchronní replikace umožňuje nevyhnutelnou ztrátu dat v případě selhání primárního serveru. Za účelem ochrany důležitých transakcí před ztrátou dat může vývojář aplikace volat sp_wait_for_database_copy_sync proceduru ihned po potvrzení transakce. Volání blokuje volající vlákno, dokud poslední potvrzené transakce byla přenesena a potvrzena v transakčním protokolu sp_wait_for_database_copy_sync sekundární databáze. Nečeká ale na přehrání přenášených transakcí (opětovné přehrání) na sekundárním serveru. sp_wait_for_database_copy_sync je vymezený na konkrétní propojení geografické replikace. Tento postup může volat každý uživatel s právy k připojení k primární databázi.

Skupiny převzetí služeb při selhání a obnovení k bodu v čase

Informace o použití obnovení k bodu v čase se skupinami převzetí služeb při selhání najdete v tématu Obnovení k bodu v čase (PITR).

Omezení skupin převzetí služeb při selhání

Uvědomte si následující omezení:

• Skupiny převzetí služeb při selhání není možné vytvořit mezi dvěma servery nebo instancemi ve stejné oblasti Azure.
• Skupiny převzetí služeb při selhání nelze přejmenovat. Budete muset odstranit skupinu a znovu ji vytvořit s jiným názvem.
• Přejmenování databáze není podporováno pro databáze ve skupině převzetí služeb při selhání. Abyste mohli přejmenovat databázi nebo odebrat databázi ze skupiny převzetí služeb při selhání, budete muset dočasně odstranit skupinu převzetí služeb při selhání.
• Systémové databáze se nereplikují do sekundární instance ve skupině převzetí služeb při selhání. Proto scénáře, které závisí na objektech ze systémových databází, vyžadují ruční vytvoření objektů v sekundárních instancích a také ruční synchronizaci po všech změnách provedených v primární instanci. Jedinou výjimkou je hlavní klíč služby pro službu SQL Instance, který se během vytváření skupiny převzetí služeb při selhání automaticky replikuje do sekundární instance. Jakékoli následné změny KLÍČE na primární instanci ale nebudou replikovány do sekundární instance.
• Skupiny převzetí služeb při selhání není možné vytvořit mezi instancemi, pokud se kterákoli z nich nachází ve fondu instancí.

Správa skupin převzetí služeb při selhání prostřednictvím kódu programu

Jak je popsáno výše, skupiny automatického převzetí služeb při selhání je také možné spravovat prostřednictvím kódu programu Azure PowerShell, Azure CLI a REST API. Následující tabulky popisují sadu dostupných příkazů. Aktivní geografická replikace zahrnuje sadu Azure Resource Manager api pro správu, včetně rutin Azure SQL Database REST API a Azure PowerShell. Tato rozhraní API vyžadují použití skupin prostředků a podporu řízení přístupu na základě role v Azure (Azure RBAC). Další informace o tom, jak implementovat role přístupu, najdete v tématu Řízení přístupu na základě role v Azure (Azure RBAC).

Správa SQL Database geografické převzetí služeb při selhání

Správa SQL převzetí služeb při selhání spravované instance

Další kroky

• Podrobné pokyny najdete v tématu.
  • přidání SQL Database do skupiny převzetí služeb při selhání
  • Přidání elastického fondu do skupiny převzetí služeb při selhání
  • přidání spravované Instance SQL do skupiny převzetí služeb při selhání
• Ukázkové skripty najdete v těchto tématech:
  • Konfigurace aktivní geografické replikace pro Azure SQL Database pomocí PowerShellu
  • Použití PowerShellu ke konfiguraci aktivní geografické replikace pro databázi ve fondu v Azure SQL Database
  • přidání Azure SQL Database do skupiny převzetí služeb při selhání pomocí powershellu
• Přehled provozní kontinuity a scénářů najdete v tématu Přehled provozní kontinuity .
• další informace o Azure SQL Database automatizovaných zálohách najdete v tématu SQL Database automatizované zálohy.
• Další informace o použití automatizovaných záloh pro obnovení najdete v tématu obnovení databáze ze zálohy iniciované službou.
• další informace o požadavcích na ověřování nového primárního serveru a databáze najdete v článku SQL Database zabezpečení po zotavení po havárii.