Failovergruppen: Übersicht und bewährte Methoden – Azure SQL Managed Instance

Gilt für: Azure SQL Managed Instance

Mit der Funktion Failovergruppen können Sie die Replikation und das Failover aller Benutzerdatenbanken in einer verwalteten Instanz in eine andere Azure-Region verwalten. Dieser Artikel enthält eine Übersicht über das Failovergruppenfeature mit bewährten Methoden und Empfehlungen für die Verwendung mit Azure SQL Managed Instance.

Informationen zum Einstieg in das Feature finden Sie unter Konfigurieren einer Failovergruppe für Azure SQL Managed Instance.

Übersicht

Mit der Funktion Failovergruppen können Sie die Replikation und das Failover von Benutzerdatenbanken in einer verwalteten Instanz zu einer verwalteten Instanz in einer anderen Azure-Region verwalten. Failovergruppen wurden entwickelt, um die Bereitstellung und Verwaltung georeplizierter Datenbanken im großen Stil zu vereinfachen.

Weitere Informationen finden Sie unter Hochverfügbarkeit für Azure SQL Managed Instance. Informationen zu Geofailover-RPO und -RTO finden Sie unter Übersicht über die Geschäftskontinuität.

Endpunktumleitung

Failovergruppen bieten Listenerendpunkte mit Lese-/Schreibzugriff und schreibgeschützte Listenerendpunkte, die während Geofailovers unverändert bleiben. Sie müssen die Verbindungszeichenfolge für Ihre Anwendung nach einem Geofailover nicht ändern, da die Verbindungen automatisch an das aktuelle primäre Replikat weitergeleitet werden. Sowohl bei manueller als auch automatischer Failover-Aktivierung schaltet das Geofailover alle sekundären Datenbanken in der Gruppe zur primären Rolle um. Nach Abschluss des Geofailovers wird der DNS-Eintrag automatisch aktualisiert, um die Endpunkte in die neue Region umzuleiten.

Auslagern schreibgeschützter Workloads

Um den Datenverkehr an Ihre primären Datenbanken zu verringern, können Sie zudem mithilfe der sekundären Datenbanken in einer Failovergruppe schreibgeschützte Workloads auslagern. Verwenden Sie den schreibgeschützten Listener, um schreibgeschützten Datenverkehr an eine lesbare sekundäre Datenbank weiterzuleiten.

Wiederherstellen einer Anwendung

Wenn Sie echte Geschäftskontinuität erreichen möchten, ist das Hinzufügen einer regionalen Datenbankredundanz nur ein Teil der Lösung. Für die komplette Wiederherstellung einer Anwendung bzw. eines Diensts nach einem schwerwiegenden Fehler ist das Wiederherstellen aller Komponenten erforderlich, aus denen sich der Dienst und alle abhängigen Dienste zusammensetzen. Beispiele dieser Komponenten sind die Clientsoftware (z. B. ein Browser mit benutzerdefiniertem JavaScript), Web-Front-Ends, Speicher und DNS. Es ist wichtig, dass alle Komponenten hinsichtlich derselben Fehler gegen Ausfälle geschützt und innerhalb des RTO (Recovery Time Objective) der Anwendung wieder verfügbar sind. Daher müssen Sie alle abhängigen Dienste bestimmen und mit dem Leistungsumfang und den Funktionen vertraut sein, die sie bieten. Dann müssen Sie entsprechende Maßnahmen ergreifen, um sicherzustellen, dass Ihr Dienst während des Failovers der Dienste funktioniert, von denen er abhängig ist.

Failover-Richtlinie

Failovergruppen unterstützen zwei Failover-Richtlinien:

• Vom Kunden verwaltet (empfohlen) – Kunden können ein Failover einer Gruppe ausführen, wenn sie einen unerwarteten Ausfall bemerken, der sich auf eine oder mehrere Datenbanken in der Failover-Gruppe auswirkt. Bei Verwendung von Befehlszeilentools wie PowerShell, Azure CLI oder der Rest-API lautet der Wert der Failover-Richtlinie für den verwalteten Kunden manual.
• Microsoft verwaltet – Im Falle eines weit verbreiteten Ausfalls, der sich auf eine primäre Region auswirkt, initiiert Microsoft ein Failover aller betroffenen Failover-Gruppen, für die ihre Failover-Richtlinie so konfiguriert ist, dass sie von Microsoft verwaltet wird. Von Microsoft verwaltetes Failover wird für einzelne Failovergruppen oder eine Teilmenge von Failovergruppen in einer Region nicht initiiert. Bei Verwendung von Befehlszeilentools wie PowerShell, Azure CLI oder der Rest-API lautet der Wert der Failoverrichtlinie für Microsoft-verwaltet automatic.

Jede Failoverrichtlinie verfügt über einen eindeutigen Satz von Anwendungsfällen und entsprechenden Erwartungen an den Failoverumfang und Datenverlust, wie in der folgenden Tabelle zusammengefasst:

Vom Kunden verwaltet

In seltenen Fällen reicht die integrierte Verfügbarkeit oder hohe Verfügbarkeit nicht aus, um einen Ausfall zu minimieren, und Ihre Datenbanken in einer Failovergruppe sind möglicherweise für eine Dauer nicht verfügbar, die für die Vereinbarung auf Servicelevel (Service Level Agreement, SLA) der Anwendungen, die die Datenbanken verwenden, nicht akzeptabel ist. Datenbanken können aufgrund eines lokalisierten Problems, das sich auf nur wenige Datenbanken auswirkt, nicht verfügbar sein, oder sie kann sich auf der Ebene des Rechenzentrums, der Verfügbarkeitszone oder der Region befinden. In jedem dieser Fälle können Sie zum Wiederherstellen der Geschäftskontinuität ein erzwungenes Failover initiieren.

Das Festlegen Ihrer Failoverrichtlinie auf vom Kunden verwaltete Kunden wird dringend empfohlen, da Sie die Kontrolle darüber behalten, wann sie ein Failover initiieren und die Geschäftskontinuität wiederherstellen möchten. Sie können ein Failover initiieren, wenn sie einen unerwarteten Ausfall bemerken, der sich auf eine oder mehrere Datenbanken in der Failovergruppe auswirkt.

Von Microsoft verwaltet

Mit einer von Microsoft verwalteten Failoverrichtlinie wird die Verantwortung für die Notfallwiederherstellung an den Azure SQL-Dienst delegiert. Damit der Azure SQL-Dienst ein erzwungenes Failover initiieren kann, müssen die folgenden Bedingungen erfüllt sein:

• Das Rechenzentrum, die Verfügbarkeitszone oder der Ausfall der Region aufgrund eines Naturkatastrophenereignisses, Konfigurationsänderungen, Softwarefehler oder Hardwarekomponentenfehler und viele Datenbanken in der Region sind betroffen.
• Die Karenzzeit ist abgelaufen. Da Maßnahmen ergriffen werden müssen, um das Ausmaß des Ausfalls zu überprüfen und festzustellen, wie schnell dieser minimiert werden kann, kann die Toleranzperiode nicht auf einen Wert unter einer Stunde festgelegt werden.

Wenn diese Bedingungen erfüllt sind, initiiert der Azure SQL-Dienst erzwungene Failovers für alle Failovergruppen in der Region, für die die Failoverrichtlinie auf Microsoft verwaltet wurde.

Legen Sie die Failoverrichtlinie nur auf Microsoft fest, die verwaltet wird, wenn:

• Sie möchten die Verantwortung für die Notfallwiederherstellung an den Azure SQL-Dienst delegieren.
• Die Anwendung ist tolerant für Ihre Datenbank, die mindestens eine Stunde lang nicht verfügbar ist.
• Es ist akzeptabel, erzwungene Failover einige Zeit nach Ablauf der Nachfrist auszulösen, da die tatsächliche Zeit für das erzwungene Failover erheblich variieren kann.
• Es ist akzeptabel, dass alle Datenbanken innerhalb der Failovergruppe unabhängig vom Zonenredundanzkonfigurations- oder Verfügbarkeitsstatus fehlschlagen. Datenbanken, die für Zonenredundanz konfiguriert sind, sind zwar widerstandsfähig für Zonalfehler und sind möglicherweise nicht durch einen Ausfall betroffen, aber sie werden immer noch fehlgeschlagen, wenn sie Teil einer Failovergruppe mit einer von Microsoft verwalteten Failoverrichtlinie sind.
• Es ist akzeptabel, dass in der Failovergruppe Failovers von Datenbanken erzwungen werden, ohne die Abhängigkeit der Anwendung von anderen Azure-Diensten oder -Komponenten zu berücksichtigen, die von der Anwendung verwendet werden, was zu Leistungsbeeinträchtigungen oder Nichtverfügbarkeit der Anwendung führen kann.
• Es ist akzeptabel, eine unbekannte Menge an Datenverlust zu verursachen, da die genaue Zeit des erzwungenen Failovers nicht gesteuert werden kann, und ignoriert den Synchronisierungsstatus der sekundären Datenbanken.
• Alle primären und sekundären Datenbanken in der Failover-Gruppe und alle Geo-Replikationsbeziehungen haben dieselbe Dienstebene, Compute-Ebene (bereitgestellt oder serverlos) und Compute-Größe (DTUs oder virtuelle Kerne). Wenn das Ziel der Dienstebene (Service Level Objective, SLO) aller Datenbanken nicht übereinstimmt, wird die Failover-Richtlinie schließlich von Microsoft Managed vom Azure SQL-Dienst auf „Vom Kunden verwaltet“ aktualisiert.

Wenn ein Failover von Microsoft ausgelöst wird, wird dem Azure Monitor-Aktivitätsprotokoll ein Eintrag für den Vorgangsnamen Failover Azure SQL-Failovergruppe hinzugefügt. Der Eintrag enthält den Namen der Failovergruppe unter "Ressource", und "Ereignis", das von einem einzelnen Bindestrich (-) initiiert wird, um anzugeben, dass das Failover von Microsoft initiiert wurde. Diese Informationen finden Sie auch auf der Seite "Aktivitätsprotokoll" des neuen primären Servers oder der neuen Instanz im Azure-Portal.

Terminologie und Funktionen

• Failovergruppe

  Eine Failovergruppe ermöglicht allen Benutzerdatenbanken innerhalb einer verwalteten Instanz das Failover als Einheit in eine andere Azure-Region, falls die primäre verwaltete Instanz aufgrund eines Ausfalls der primären Region nicht mehr verfügbar ist. Da Failovergruppen für SQL Managed Instance alle Benutzerdatenbanken in der Instanz enthalten, kann nur eine Failovergruppe für eine Instanz konfiguriert werden.

  Wichtig

  Der Name der Failovergruppe muss innerhalb der .database.windows.net-Domäne global eindeutig sein.

• Primärer Server/verwaltete Instanz

  Die verwaltete Instanz, in der die primären Datenbanken in der Failovergruppe gehostet werden.

• Sekundärer Server/verwaltete Instanz

  Die verwaltete Instanz, in der die sekundären Datenbanken in der Failovergruppe gehostet werden. Das sekundäre Replikat kann sich nicht in derselben Azure-Region befinden wie das primäre Replikat.

  Wichtig

  Wenn eine Datenbank In-Memory-OLTP-Objekte enthält, müssen die primäre Datenbank und die sekundäre Georeplikat-Datenbank übereinstimmende Dienstebenen aufweisen, da sich In-Memory-OLTP-Objekte im Speicher befinden. Eine niedrigere Dienstebene auf der Geo-Replica-Instanz kann zu Problemen durch nicht genügend Arbeitsspeicher führen. Wenn dies der Fall ist, kann das Georeplikat die Datenbank nicht wiederherstellen, was dazu führt, dass die sekundäre Datenbank zusammen mit den In-Memory-OLTP-Objekten auf der sekundären Geodatenbank nicht verfügbar ist. Dies wiederum kann dazu führen, dass auch Failover nicht erfolgreich sind. Um dies zu vermeiden, stellen Sie sicher, dass die Dienstebene der sekundären Geodatenbank mit der der primären Datenbank übereinstimmt. Dienstebenenupgrades können Vorgänge zur Datengröße sein und können eine Weile dauern.

• Failover (kein Datenverlust)

  Beim geplanten Failover wird eine vollständige Datensynchronisierung zwischen primärer und sekundärer Datenbank ausgeführt, bevor die sekundäre Datenbank die Rolle der primären Datenbank übernimmt. Dadurch ist sichergestellt, dass keine Daten verloren gehen. Failover ist nur möglich, wenn auf die primäre Datei zugegriffen werden kann. Ein geplantes Failover wird in den folgenden Szenarien verwendet:

  • Ausführen von DR-Drills (Notfallwiederherstellung) in der Produktion, wenn ein Datenverlust nicht akzeptabel ist
  • Verschieben der Datenbanken in eine andere Region
  • Rückkehr der Datenbanken in die primäre Region, nachdem der Ausfall behoben wurde (Failback)

• Erzwungenes Failover (potenzieller Datenverlust)

  Beim ungeplanten oder erzwungenen Failover übernimmt die sekundäre Datenbank sofort die Rolle der primären Datenbank, ohne dass auf die Weitergabe kürzlicher Änderungen von der primären Datenbank gewartet wird. Dieser Vorgang kann zu Datenverlust führen. Ein ungeplantes Failover wird als Wiederherstellungsmethode bei Ausfällen verwendet, wenn auf die primäre Datenbank nicht zugegriffen werden kann. Wenn der Ausfall behoben wird, stellt die alte primäre Datenbank automatisch wieder eine Verbindung her und wird zu einer neuen sekundären Datenbank. Ein geplantes Failover kann ausgeführt werden, um ein Failback durchzuführen und die Replikate an ihre ursprünglichen primären und sekundären Rollen zurückzugeben.

• Toleranzperiode mit Datenverlust

  Da Daten mithilfe der asynchronen Replikation auf die sekundäre Replikation repliziert werden, kann das erzwungene Failover von Gruppen mit von Microsoft verwalteten Failoverrichtlinien zu Datenverlust führen. Sie können die Richtlinie für automatisches Failover entsprechend der Toleranz Ihrer Anwendung gegenüber Datenverlust anpassen. Durch Konfiguration von GracePeriodWithDataLossHours können Sie steuern, wie lange das System wartet, bevor ein erzwungenes Failover initiiert wird, das zu Datenverlust führen kann.

• DNS-Zone

  Eine eindeutige ID, die automatisch generiert wird, wenn eine neue SQL Managed Instance erstellt wird. Ein Zertifikat mit mehreren Domänen (SAN) für diese Instanz wird bereitgestellt, um die Clientverbindungen mit einer beliebigen Instanz in der gleichen DNS-Zone zu authentifizieren. Die beiden verwalteten Instanzen in der gleichen Failovergruppe müssen die DNS-Zone gemeinsam verwenden.

• Lese-/Schreib-Failovergruppenlistener

  Ein DNS CNAME-Eintrag, der auf die aktuelle primäre Datenbank verweist. Er wird automatisch mit der Failovergruppe erstellt und ermöglicht der Lese-/Schreibworkload die transparente Verbindungswiederherstellung mit der primären verwalteten Instanz, wenn sich diese nach dem Failover ändert. Wenn die Failovergruppe in einer SQL Managed Instance erstellt wird, hat der DNS CNAME-Eintrag für die Listener-URL die Form <fog-name>.<zone_id>.database.windows.net.

• Nur-Lese-Failovergruppenlistener

  Ein DNS CNAME-Eintrag, der auf die aktuelle sekundäre Datenbank verweist. Er wird automatisch mit der Failovergruppe erstellt und ermöglicht der schreibgeschützten SQL-Workload das transparente Verbinden mit der sekundären verwalteten Instanz, wenn sich diese nach dem Failover ändert. Wenn die Failovergruppe in einer SQL Managed Instance erstellt wird, hat der DNS CNAME-Eintrag für die Listener-URL die Form <fog-name>.secondary.<zone_id>.database.windows.net. Standardmäßig ist das Failover des schreibgeschützten Listeners deaktiviert, da sichergestellt wird, dass die Leistung der primären Datei nicht beeinträchtigt wird, wenn die sekundäre Offlineversion offline ist. Es bedeutet jedoch auch, dass die schreibgeschützten Sitzungen erst dann eine Verbindung herstellen können, nachdem die sekundäre Datenbank wiederhergestellt wurde. Wenn Sie keine Ausfallzeiten für die Nur-Lese-Sitzungen tolerieren können und den primären Rechner sowohl für den Nur-Lese- als auch für den Schreib-Lese-Verkehr verwenden können, ohne dass die Leistung des primären Rechners beeinträchtigt wird, können Sie Failover für den Nur-Lese-Listener aktivieren, indem Sie die Eigenschaft AllowReadOnlyFailoverToPrimary konfigurieren. In diesem Fall wird der schreibgeschützte Datenverkehr automatisch zur primären Datenbank umgeleitet, wenn die sekundäre Datenbank nicht verfügbar ist.

  Hinweis

  Die Eigenschaft AllowReadOnlyFailoverToPrimary ist nur wirksam, wenn die Richtlinie für automatisches Failover aktiviert ist und ein automatisches Failover ausgelöst wurde. Ist die Eigenschaft in diesem Fall auf „True“ festgelegt, werden von der primären Datenbank sowohl Sitzung mit Lese-/Schreibzugriff als auch schreibgeschützte Sitzungen bedient.

Architektur einer Failovergruppe

Die Failovergruppe muss auf der primären Instanz konfiguriert werden und stellt eine Verbindung zur sekundären Instanz in einer anderen Azure-Region her. Alle Benutzerdatenbanken in der Instanz werden in der sekundären Instanz repliziert. Systemdatenbanken wie master und msdb werden nicht repliziert.

Das folgende Diagramm zeigt eine typische Konfiguration einer georedundanten Cloudanwendung mit einer verwalteten Instanz und Failovergruppe:

Wenn Ihre Anwendung SQL Managed Instance als Datenschicht verwendet, beachten Sie beim Entwerfen für Geschäftskontinuität die in diesem Artikel beschriebenen allgemeinen Richtlinien und Best Practices.

Erstellen der sekundären Geoinstanz

Damit eine unterbrechungsfreie Verbindung mit der primären SQL Managed Instance nach einem Failover sichergestellt ist, müssen sich primäre und sekundäre Instanz in der gleichen DNS-Zone befinden. Es wird sichergestellt, dass das gleiche Zertifikat mit mehreren Domänen (SAN) zum Authentifizieren von Clientverbindungen mit einer der zwei Instanzen in der Failovergruppe verwendet werden kann. Wenn Ihre Anwendung für die Bereitstellung in der Produktionsumgebung bereit ist, erstellen Sie eine sekundäre SQL Managed Instance in einer anderen Region, und stellen Sie sicher, dass sie die gleiche DNS-Zone wie die primäre SQL Managed Instance verwendet. Dies können Sie erreichen, indem Sie während der Erstellung einen optionalen Parameter angeben. Wenn Sie PowerShell oder die REST-API verwenden, lautet der Name des optionalen Parameters DNSZonePartner. Der Name des entsprechenden optionalen Felds im Azure-Portal ist Primäre verwaltete Instanz.

Weitere Informationen zum Erstellen der sekundären SQL Managed Instance in derselben DNS-Zone wie die primäre Instanz finden Sie unter Konfigurieren einer Failovergruppe für Azure SQL Managed Instance.

Verwenden von Regionspaaren

Stellen Sie beide verwalteten Instanzen aus Leistungsgründen in gekoppelten Regionen bereit. SQL Managed Instance-Failovergruppen in gekoppelten Regionen weisen im Vergleich zu nicht gekoppelten Regionen eine bessere Leistung auf.

Azure SQL Managed Instance folgt einer sicheren Bereitstellungsmethode, bei der gekoppelte Azure-Regionen generell nicht gleichzeitig bereitgestellt werden. Es ist jedoch nicht möglich vorherzusagen, für welche Region zuerst ein Upgrade ausgeführt wird, sodass die Reihenfolge der Bereitstellung nicht garantiert werden kann. Manchmal wird zuerst ein Upgrade der primären Instanz durchgeführt, und manchmal wird zuerst ein Upgrade der sekundären Instanz durchgeführt.

In Situationen, in denen Azure SQL Managed Instance Teil einer Failovergruppe ist und sich die Instanzen in der Gruppe nicht in Azure-Regionspaaren befinden, wählen Sie unterschiedliche Wartungsfensterzeitpläne für Ihre primäre und sekundäre Datenbank aus. Wählen Sie beispielsweise das Wartungsfenster Werktag für Ihre sekundäre Geodatenbank und das Wartungsfenster Wochenende für Ihre primäre Geodatenbank aus.

Aktivieren und Optimieren des Datenverkehrsflows für die Georeplikation zwischen den Instanzen

Die Konnektivität zwischen den Subnetzen des virtuellen Netzwerks, die die primäre und sekundäre Instanz hosten, muss für den unterbrechungsfreien Datenverkehrsflow für die Georeplikation eingerichtet und verwaltet werden. Es gibt mehrere Möglichkeiten, die Konnektivität zwischen den Instanzen bereitzustellen, die Sie basierend auf Ihrer Netzwerktopologie und Ihren Netzwerkrichtlinien auswählen können:

• Globales Peering virtueller Netzwerke
• VPN-Gateways
• Azure ExpressRoute

Das globale Peering virtueller Netzwerke (VNet-Peering) ist die empfohlene Methode zum Einrichten der Konnektivität zwischen zwei Instanzen in einer Failovergruppe. Es bietet eine private Verbindung mit geringer Latenz und hoher Bandbreite zwischen den virtuellen Netzwerken mit Peering mithilfe der Microsoft-Backbone-Infrastruktur. Für die Kommunikation zwischen virtuellen Netzwerken mit Peering wird kein öffentliches Internet, keine Gateways und keine zusätzliche Verschlüsselung benötigt.

Anfängliches Seeding

Beim Einrichten einer Failovergruppe zwischen verwalteten Instanzen gibt es anfangs eine Seedingphase, bevor die Datenreplikation beginnt. Die Seedingphase zu Beginn ist der längste und teuerste Teil des Vorgangs. Sobald das anfängliche Seeding abgeschlossen ist, werden die Daten synchronisiert, und nur nachfolgende Datenänderungen werden repliziert. Die Zeit bis zum Abschluss des ersten Seeding hängt von der Datengröße, der Anzahl der replizierten Datenbanken, der Workloadintensität in den primären Datenbanken und der Geschwindigkeit der Verbindung zwischen den virtuellen Netzwerken ab, die die primäre und die sekundäre Instanz hosten. Letztere basiert auf der Art, wie die Konnektivität hergestellt wird. Unter normalen Umständen und wenn die Konnektivität mithilfe des empfohlenen globalen Peerings virtueller Netzwerke eingerichtet wird, beträgt die Seedinggeschwindigkeit für SQL Managed Instance bis zu 360 GB pro Stunde. Das Seeding wird parallel für eine Reihe von Benutzerdatenbanken ausgeführt, nicht zwangsläufig für alle Datenbanken gleichzeitig. Möglicherweise sind mehrere Batches erforderlich, wenn viele Datenbanken in der Instanz gehostet werden.

Wenn die Geschwindigkeit der Verbindung zwischen den beiden Instanzen langsamer als erforderlich ist, wirkt sich dies wahrscheinlich erheblich auf die Zeit für das Seeding aus. Anhand der angegebenen Seedinggeschwindigkeit, der Anzahl der Datenbanken, der Gesamtgröße der Daten und der Verbindungsgeschwindigkeit können Sie abschätzen, wie lange die anfängliche Seedingphase vor dem Starten der Datenreplikation dauern wird. Beispielsweise würde für eine einzelne Datenbank mit 100 GB die anfängliche Seedingphase etwa 1,2 Stunden dauern, wenn die Verbindung eine Pushübertragung von 84 GB pro Stunde unterstützt und für keine anderen Datenbanken ein Seeding ausgeführt wird. Wenn über die Verbindung nur 10 GB pro Stunde übertragen werden können, dauert das Seeding einer 100-GB-Datenbank ungefähr 10 Stunden. Wenn mehrere Datenbanken zu replizieren sind, wird das Seeding parallel ausgeführt, und in Kombination mit einer niedrigen Verbindungsgeschwindigkeit kann die anfängliche Seedingphase erheblich länger dauern, insbesondere dann, wenn das parallele Seeding von Daten aus allen Datenbanken die verfügbare Verbindungsbandbreite überschreitet.

Verwalten von Geofailovern auf eine sekundäre Geoinstanz

Die Failovergruppe verwaltet das Geofailover aller Datenbanken auf der primären verwalteten Instanz. Beim Erstellen einer Gruppe wird jede Datenbank in der Instanz automatisch in der sekundären Geoinstanz geografisch repliziert. Sie können Failovergruppen nicht dazu verwenden, ein Teilfailover einer Untergruppe von Datenbanken zu initiieren.

Verwenden des Lese-/Schreiblisteners (primäre verwaltete Instanz)

Verwenden Sie für Lese-/Schreibworkloads <fog-name>.zone_id.database.windows.net als Servernamen. Verbindungen werden automatisch an die primäre Datenbank weitergeleitet. Dieser Name wird nach dem Failover nicht geändert. Das Geofailover umfasst die Aktualisierung des DNS-Eintrags, damit die neuen Clientverbindungen erst dann an die neue primäre Datenbank weitergeleitet werden, wenn der Client-DNS-Cache aktualisiert wurde. Da die sekundäre Instanz die gleiche DNS-Zone wie die primäre Instanz verwendet, kann die Clientanwendung mit dem gleichen serverseitigen SAN-Zertifikat erneut eine Verbindung herstellen. Die vorhandenen Clientverbindungen müssen beendet und dann neu erstellt werden, um an die neue primäre Instanz weitergeleitet zu werden. Der Lese-/Schreiblistener und der Listener für schreibgeschützte Vorgänge können nicht über einen öffentlichen Endpunkt für verwaltete Instanzen erreicht werden.

Verwenden des Lese-/Schreiblisteners (sekundäre verwaltete Instanz)

Wenn Sie über logisch isolierte schreibgeschützte Workloads verfügen, die datenlatenztolerant sind, können Sie sie auf der sekundären Geodatenbank ausführen. Verwenden Sie <fog-name>.secondary.<zone_id>.database.windows.net als Servernamen, um eine direkte Verbindung mit der sekundären Geodatenbank herzustellen.

Auf der Dienstebene „Unternehmenskritisch“ unterstützt SQL Managed Instance die Verwendung schreibgeschützter Replikate zur Auslagerung schreibgeschützter Abfrageworkloads unter Verwendung des Parameters ApplicationIntent=ReadOnly in der Verbindungszeichenfolge. Wenn Sie eine georeplizierte sekundäre Datenbank konfiguriert haben, können Sie mit dieser Funktion eine Verbindung entweder mit einem schreibgeschützten Replikat am primären Standort oder am geografisch replizierten Standort herstellen:

• Verwenden Sie ApplicationIntent=ReadOnly und <fog-name>.<zone_id>.database.windows.net, um eine Verbindung mit einem schreibgeschützten Replikat am primären Standort herzustellen.
• Wenn Sie eine Verbindung mit einem schreibgeschützten Replikat am sekundären Standort herstellen möchten, verwenden Sie ApplicationIntent=ReadOnly und <fog-name>.secondary.<zone_id>.database.windows.net.

Der Lese-/Schreiblistener und der Listener für schreibgeschützte Vorgänge können nicht über einen öffentlichen Endpunkt für verwaltete Instanzen erreicht werden.

Potenzielle Leistungsbeeinträchtigung nach einem Failover

Eine typische Azure-Anwendung nutzt mehrere Azure-Dienste und besteht aus mehreren Komponenten. Das automatisierte Geofailover der Failovergruppe wird ausschließlich anhand des Status der Azure SQL-Komponenten ausgelöst. Andere Azure-Dienste in der primären Region sind vom Ausfall ggf. nicht betroffen, und es kann sein, dass die entsprechenden Komponenten in dieser Region weiterhin verfügbar sind. Nachdem die primären Datenbanken auf die sekundäre Region umgestellt wurden, erhöht sich unter Umständen die Wartezeit zwischen den abhängigen Komponenten. Gewährleisten Sie die Redundanz aller Anwendungskomponenten in der sekundären Region, und führen Sie ein Failover für Anwendungskomponenten zusammen mit der Datenbank durch, sodass die Leistung der Anwendung nicht durch höhere regionenübergreifende Latenz beeinträchtigt wird.

Potenzieller Datenverlust nach einem Geofailover

Wenn ein Ausfall in der primären Region auftritt, wurden die letzten Transaktionen möglicherweise nicht in die geo-sekundäre Region repliziert, und es kann Datenverlust geben, wenn ein erzwungenes Failover ausgeführt wird.

DNS-Update

Die DNS-Aktualisierung des Lese-/Schreib-Listeners erfolgt sofort nach dem Initiieren des Failovers. Bei diesem Vorgang gehen keine Daten verloren. Allerdings kann der Prozess zum Wechseln der Datenbankrollen unter normalen Bedingungen bis zu 5 Minuten dauern. Bis er abgeschlossen ist, sind einige Datenbanken in der neuen primären Instanz noch schreibgeschützt. Wenn ein Failover mithilfe von PowerShell initiiert wird, ist der Vorgang für den Wechsel der primären Replikatrolle synchron. Wird es über das Azure-Portal initiiert, wird auf der Benutzeroberfläche der Abschlussstatus angegeben. Verwenden Sie beim Initiieren über die REST-API den Standardabfragemechanismus von Azure Resource Manager, um den Abrufvorgang auf seinen Abschluss zu überwachen.

Sparen von Kosten mit einem lizenzfreien DR-Replikat

Sie können SQL Server-Lizenzkosten sparen, indem Sie Ihre sekundäre verwaltete Instanz so konfigurieren, dass sie nur für die Notfallwiederherstellung (disaster recovery, DR) verwendet wird. Informationen zur Einrichtung finden Sie unter Konfigurieren eines lizenzfreien Standbyreplikats für Azure SQL Managed Instance.

Solange die sekundäre Instanz nicht für Leseworkloads verwendet wird, stellt Microsoft ihnen kostenlos eine Anzahl von virtuellen Kernen zur Verfügung, die mit der der primären Instance übereinstimmt. Ihnen werden trotzdem die Compute- und Speicherkosten in Rechnung gestellt, die von der sekundären Instanz verwendet werden. Failovergruppen unterstützen nur ein Replikat. Bei dem Replikat muss es sich entweder um ein lesbares Replikat handeln, oder es muss als reines DR-Replikat festgelegt werden.

Aktivieren von Szenarien in Abhängigkeit von Objekten in den Systemdatenbanken

Systemdatenbanken werden nicht in die sekundäre Instanz in einer Failovergruppe repliziert. Um Szenarien zu ermöglichen, in denen Objekte aus den Systemdatenbanken erforderlich sind, stellen Sie sicher, dass diese Objekte in der sekundären Instanz erstellt werden, und synchronisieren Sie sie mit der primären Instanz.

Wenn Sie beispielsweise in der sekundären Instanz die gleichen Anmeldungen nutzen möchten, stellen Sie sicher, dass sie mit identischer SID erstellt werden.

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

Weitere Informationen finden Sie unter Azure SQL Managed Instance – Sync Agent Jobs and Logins in Failover Groups (Azure SQL Managed Instance: Synchronisieren von Agent-Aufträgen und Anmeldungen bei Failovergruppen).

Synchronisieren von Instanzeigenschaften und Aufbewahrungsrichtlinien

Instanzen in einer Failovergruppe bleiben separate Azure-Ressourcen, und Änderungen an der Konfiguration der primären Instanz werden nicht automatisch in die sekundäre Instanz repliziert. Stellen Sie sicher, dass Sie alle relevanten Änderungen in der primären und der sekundären Instanz vornehmen. Wenn Sie beispielsweise die Sicherungsspeicherredundanz oder die Richtlinie für die langfristige Sicherungsaufbewahrung für die primäre Instanz ändern, stellen Sie sicher, dass Sie sie auch in der sekundären Instanz ändern.

Skalieren von Instanzen

Sie können die primäre und sekundäre Instanz auf eine andere Computegröße innerhalb derselben Dienstebene oder auf eine andere Dienstebene hoch- oder herunterskalieren. Bei der Skalierung innerhalb derselben Dienstebene wird empfohlen, zuerst die geo-sekundäre und dann die primäre Ebene zu vergrößern. Beim Herunterskalieren innerhalb derselben Dienstebene gehen Sie in umgekehrter Reihenfolge vor: Skalieren Sie zuerst die primäre Datenbank herunter, dann die sekundäre Datenbank. Wenn Sie eine Instanz auf eine andere Dienstebene skalieren, wird diese Empfehlung erzwungen. Die Reihenfolge der Vorgänge wird beim Skalieren der Dienstebene und der virtuellen Kerne sowie des Speichers durchgesetzt.

Die Reihenfolge wird besonders zur Vermeidung des Überladens der geosekundären Datenbank auf einer niedrigeren SKU empfohlen, damit während des Upgrade- oder Downgradevorgangs kein neuerliches Seeding durchgeführt werden muss.

Verhinderung des Verlusts kritischer Daten

Aufgrund der hohen Latenzzeit von WANs verwendet die Georeplikation einen asynchronen Replikationsmechanismus. Bei der asynchronen Replikation ist die Möglichkeit eines Datenverlusts unvermeidbar, wenn die primäre Datenbank ausfällt. Zum Schutz kritischer Transaktionen vor Datenverlust, kann ein Anwendungsentwickler die gespeicherte Prozedur sp_wait_for_database_copy_sync unmittelbar nach dem Commit der Transaktion aufrufen. Der Aufruf von sp_wait_for_database_copy_sync blockiert den aufrufenden Thread, bis die letzte committete Transaktion übertragen und im Transaktionsprotokoll der sekundären Datenbank gehärtet wurde. Er wartet jedoch nicht darauf, dass die übertragenen Transaktionen in der sekundären Datenbank wiedergegeben (wiederholt) werden. sp_wait_for_database_copy_sync ist auf eine bestimmte Georeplikationslink beschränkt. Jeder Benutzer mit den Rechten zum Herstellen der Verbindung mit der primären Datenbank kann diese Prozedur aufrufen.

Um Datenverluste während eines vom Benutzer initiierten, geplanten Geo-Failovers zu vermeiden, wechselt die Replikation automatisch und vorübergehend zur synchronen Replikation und führt dann ein Failover aus. Nach Abschluss des Geo-Failovers wechselt die Replikation wieder in den asynchronen Modus.

Failovergruppenstatus

Failovergruppe meldet ihren Status, der den aktuellen Status der Datenreplikation beschreibt:

• Seeding: Das erste Seeding erfolgt nach der Erstellung der Failovergruppe, bis alle Benutzerdatenbanken auf der sekundären Instanz initialisiert werden. Der Failoverprozess kann nicht initiiert werden, während sich die Failovergruppe im Seedingstatus befindet, da Benutzerdatenbanken noch nicht in die sekundäre Instanz kopiert wurden.
• Synchronisieren – Der übliche Status der Failovergruppe. Dies bedeutet, dass Datenänderungen in der primären Instanz asynchron auf die sekundäre Instanz repliziert werden. Dieser Status garantiert nicht, dass die Daten zu jedem Zeitpunkt vollständig synchronisiert werden. Aufgrund der asynchronen Natur des Replikationsprozesses zwischen Instanzen in der Failovergruppe können Datenänderungen vom primären Replikat zum sekundären Replikat repliziert werden. Sowohl automatische als auch manuelle Failover können initiiert werden, während sich die Failovergruppe im Synchronisierungsstatus befindet.
• Failover wird ausgeführt: Dieser Status gibt an, dass ein automatischer oder manuell initiierter Failoverprozess ausgeführt wird. Es können keine Änderungen an der Failovergruppe oder zusätzliche Failover initiiert werden, während sich die Failovergruppe in diesem Status befindet.

Failback

Wenn Autofailovergruppen mit einer automatischen Failoverrichtlinie konfiguriert sind, wird ein Failover auf den sekundären Geoserver während eines Notfallszenarios gemäß der definierten Nachfrist initiiert. Das Failback auf den alten primären Server muss manuell initiiert werden.

Featureinteroperabilität

Sicherungen

In den folgenden Szenarien wird eine vollständige Sicherung durchgeführt:

• Bevor die anfängliche Ermittlung der Setzliste anfängt, wenn Sie eine Failovergruppe erstellen.
• Nach einem Failover.

Eine vollständige Sicherung ist ein datenintensiver Vorgang, der nicht übersprungen oder verzögert werden kann und einige Zeit in Anspruch nehmen kann. Die Zeit, die zum Abschluss benötigt wird, hängt von der Größe der Daten, der Anzahl der Datenbanken und der Workloadintensität auf den primären Datenbanken ab. Eine vollständige Sicherung kann die anfängliche Ermittlung der Setzliste spürbar verzögern und eine Failoveroperation in einer neuen Instanz kurz nach einem Failover verzögern oder verhindern.

Protokollwiedergabedienst

Datenbanken, die mithilfe des Protokollwiedergabedienstes (LRS) zu Azure SQL Managed Instance migriert wurden, können erst dann zu einer Failovergruppe hinzugefügt werden, wenn der Cutover-Schritt ausgeführt ist. Eine mit LRS migrierte Datenbank befindet sich in einem Wiederherstellungszustand bis das Cutover erfolgt, und Datenbanken in einem Wiederherstellungszustand können einer Failovergruppe nicht hinzugefügt werden. Der Versuch, eine Failovergruppe mit einer Datenbank in einem Wiederherstellungszustand zu erstellen, verzögert die Erstellung der Failovergruppe bis die Datenbankwiederherstellung abgeschlossen ist.

Transaktionsreplikation

Die Verwendung der Transaktionsreplikation mit Instanzen, die sich in einer Failovergruppe befinden, wird unterstützt. Wenn Sie jedoch die Replikation konfigurieren, bevor Sie Ihre Instanz von SQL Managed Instance einer Failovergruppe hinzufügen, wird die Replikation angehalten, wenn Sie mit der Erstellung Ihrer Failovergruppe beginnen, und im Replikationsmonitor wird der Status Replicated transactions are waiting for the next log backup or for mirroring partner to catch up angezeigt. Die Replikation wird fortgesetzt, sobald die Failovergruppe erfolgreich erstellt wurde.

Wenn eine als Herausgeber oder Verteiler fungierende Instanz von SQL Managed Instance Teil einer Failovergruppe ist, müssen die SQL Managed Instance-Administrator*innen alle Veröffentlichungen für die alte primäre Instanz bereinigen und nach einem Failover für die neue primäre Instanz erneut konfigurieren. Den in diesem Szenario erforderlichen Schritt der Aktivitäten können Sie der Anleitung zur Transaktionsreplikation entnehmen.

Erforderliche Berechtigungen und Einschränkungen

Überprüfen Sie eine Liste an Berechtigungen und Einschränkungen bevor Sie eine Failovergruppe konfigurieren.

Programmgesteuertes Verwalten von Failovergruppen

Gruppen für automatisches Failover können auch programmgesteuert mit Azure PowerShell, Azure CLI und der REST-API verwaltet werden. Weitere Informationen finden Sie unter Konfigurieren einer Failovergruppe.

Übungen zur Notfallwiederherstellung

Die empfohlene Methode zum Ausführen eines DR-Drilldowns ist die Verwendung des manuellen geplanten Failovers gemäß dem folgenden Lernprogramm: Testen des Failovers.

Das Ausführen eines Drilldowns mit erzwungenem Failover wird nicht empfohlen, da dieser Vorgang keinen Schutz gegen den Datenverlust bietet. Dennoch ist es möglich, einen datenverlustlosen erzwungenen Failover zu erreichen, indem sichergestellt wird, dass die folgenden Bedingungen erfüllt sind, bevor das erzwungene Failover initiiert wird:

• Die Workload wird in der primären verwalteten Instanz beendet.
• Alle Transaktionen mit langer Ausführung sind abgeschlossen.
• Alle Client-Verbindungen mit der primären verwalteten Instanz wurden getrennt.
• Der Failovergruppenstatus lautet „Synchronisieren“.

Stellen Sie sicher, dass die beiden verwalteten Instanzen über gewechselte Rollen verfügen und der Status der Failover-Gruppe von „Failover in Bearbeitung“ zu „Synchronisieren“ gewechselt hat, bevor Sie optional Verbindungen mit der neuen primären verwalteten Instanz herstellen und Lese-/Schreibzugriffsarbeitslast starten.

Um einen datenverlustlosen Failback zu den ursprünglichen Rollen der verwalteten Instanz durchzuführen, wird dringend empfohlen, das manuelle geplante Failover anstelle des erzwungenen Failovers zu verwenden. So fahren Sie mit erzwungenen Failback fort:

• Führen Sie die gleichen Schritte wie für das Failover ohne Datenverlust aus.
• Längere Failback-Ausführungszeit wird erwartet, wenn der erzwungene Failback kurz nach Abschluss des anfänglich erzwungenen Failovers ausgeführt wird, da er auf den Abschluss ausstehender automatischer Sicherungsoperationen in der ehemaligen primären verwalteten Instanz warten muss.

Zugehöriger Inhalt

• Konfigurieren einer Failovergruppe
• Hinzufügen einer verwalteten Instanz zu einer Failovergruppe mithilfe von PowerShell
• Konfigurieren eines lizenzfreien Standbyreplikats für Azure SQL Managed Instance
• Übersicht über die Geschäftskontinuität mit der Azure SQL Managed Instance
• Automatisierte Sicherungen in Azure SQL Managed Instance
• Wiederherstellen einer Datenbank aus einer Sicherung in Azure SQL Managed Instance