Business Continuity & Disaster Recovery für SQL Managed Instance mit Azure Arc-Unterstützung

SQL Managed Instance mit Azure Arc-Unterstützung bietet Funktionen für Geschäftskontinuität und Notfallwiederherstellung (Business Continuity & Disaster Recovery, BCDR), die Unternehmen dabei helfen, nach einer Störung den Betrieb mit minimaler Downtime wiederaufzunehmen.

Dieser Artikel enthält wichtige Entwurfsüberlegungen und Empfehlungen zum Konfigurieren und Verwalten von Geschäftskontinuitätsfunktionen wie Zeitpunktwiederherstellung, Hochverfügbarkeit und Notfallwiederherstellung.

Aufbau

Die folgenden Architekturdiagramme zeigen die Hochverfügbarkeitsfunktionen von SQL Managed Instance mit Arc-Unterstützung in der Dienstebene „Unternehmenskritisch“, die Failover nahezu ohne Downtime unterstützt. Bei einem Ausfall der primären Instanz wird vom Lastenausgleichsmodul kein Datenverkehr mehr an diese Instanz gesendet. Anschließend wird eine der sekundären Instanzen zur primären Instanz höher gestuft und empfängt daraufhin Lese-/Schreibdatenverkehr vom Lastenausgleichsmodul. Wenn die ausgefallene Instanz wieder online ist, wird sie als sekundäre Instanz hinzugefügt.

Das folgende Architekturdiagramm zeigt, wie SQL Managed Instance mit Arc-Unterstützung für die Notfallwiederherstellung in zwei separaten Kubernetes-Clustern an zwei verschiedenen Standorten bereitgestellt werden kann:

Das folgende Architekturdiagramm zeigt, wie SQL Managed Instance mit Arc-Unterstützung reagiert, wenn ein Failover für die Notfallwiederherstellung initiiert wird:

Überlegungen zum Entwurf

Machen Sie sich unter Business Continuity & Disaster Recovery mit den BCDR-Empfehlungen für Zielzonen vertraut, um die Auswirkungen von SQL Managed Instance mit Azure Arc-Unterstützung auf Ihr gesamtes BCDR-Modell bewerten zu können. Beachten Sie, dass der Schwerpunkt von Business Continuity & Disaster Recovery nur auf Entwurfsempfehlungen für Geschäftskontinuität liegt. Hochverfügbarkeit und Resilienz Ihrer Instanz hängen jedoch auch von der Verfügbarkeit der zugrunde liegenden Kubernetes-Infrastruktur ab.

Wiederherstellung bis zu einem bestimmten Zeitpunkt

• Definieren Sie Ihre Ziele für Recovery Point Objective (RPO) und Recovery Time Objective (RTO).

• Überlegen Sie sich, wie lange Sie Ihre Sicherungen innerhalb der unterstützten Grenzwerte für die Datenaufbewahrung aufbewahren und wiederherstellen möchten.

• Berücksichtigen Sie die Auswirkungen auf den Speicher und die Kosten, die eine Verlängerung des Aufbewahrungszeitraums Ihrer Sicherungen mit sich bringt. Die Standardaufbewahrungsdauer beträgt sieben Tage. Das bedeutet, es können maximal Daten der letzten sieben Tage wiederhergestellt werden, und Sie erhalten eine vollständige Sicherung, eine tägliche differenzielle Sicherung sowie Transaktionsprotokollsicherungen im Abstand von etwa fünf Minuten.

• Überlegen Sie sich, welche Speicherklasse Sie für das persistente Volume für Sicherungen verwenden möchten. Hilfreiche Informationen hierzu finden Sie unter Speicherdisziplinen für SQL Managed Instance mit Azure Arc-Unterstützung.

• Machen Sie sich Gedanken zur Größe des persistenten Volumes für Sicherungen im Kontext der erwarteten Datengröße und des konfigurierten Aufbewahrungszeitraums.

• Bewährte Methoden im Zusammenhang mit Speicher finden Sie unter Speicherdisziplinen für SQL Managed Instance mit Azure Arc-Unterstützung.

• Sicherungen werden immer für das primäre Replikat durchgeführt. Berücksichtigen Sie die Leistungsauswirkungen der Sicherungs- und Wiederherstellungsprozesse, wenn Sie die Ressourcen identifizieren, die Ihrer Instanz zugeordnet sind.

• Berücksichtigen Sie, dass durch Zeitpunktwiederherstellungen einer Datenbank keine vorhandene Datenbank überschrieben werden kann. Es ist jedoch möglich, Daten in einer neuen Datenbank in der gleichen Instanz wiederherzustellen.

• Berücksichtigen Sie die zusätzlichen Schritte, die für die vollständige Wiederherstellung Ihrer Datenbank erforderlich sind, wenn Ihre Anwendung während des Wiederherstellungsvorgangs online ist.

• Berücksichtigen Sie die zusätzlichen Schritte, die zum Wiederherstellen einer Datenbank in einer Instanz mit mehreren Replikaten erforderlich sind, wie unter Wiederherstellen einer Datenbank auf einer Instanz mit mehreren Replikaten beschrieben.

• Ermitteln Sie die Tools, die Datenbankadministratoren zum Konfigurieren und Wiederherstellen von Sicherungen verwenden. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit Azure Arc-fähigen SQL Managed Instance-Instanzen.

Hochverfügbarkeit

• Überprüfen Sie die Verfügbarkeitsanforderungen Ihrer Workload, und entscheiden Sie sich für die Dienstebene, die für Ihre Bereitstellung von SQL Managed Instance mit Arc-Unterstützung am besten geeignet ist:

  • In der Dienstebene „Universell“ steht ein einzelnes Replikat zur Verfügung, und die Hochverfügbarkeit wird über Kubernetes-Orchestrierung erreicht.
  • In der Dienstebene „Unternehmenskritisch“ wird von SQL Managed Instance mit Azure Arc-Unterstützung neben dem, was durch die Kubernetes-Orchestrierung nativ zur Verfügung steht, auch eine eigenständige Verfügbarkeitsgruppe bereitgestellt.

• Berücksichtigen Sie bei der Dienstebene „Universell“ die potenziellen geschäftlichen Auswirkungen von Downtime, die sich ergeben können, da lediglich ein einzelnes Replikat vorhanden ist.

• Überlegen Sie, wie viele Replikate (eins bis drei) in der Dienstebene „Unternehmenskritisch“ bereitgestellt werden sollen.

• Wenn Sie eine Instanz in einer Dienstebene vom Typ „Unternehmenskritisch“ mit zwei oder mehr Replikaten bereitstellen, können Sie die sekundären Replikate als lesbar konfigurieren. Entscheiden Sie, wie viele sekundäre Replikate in der Dienstebene „Unternehmenskritisch“ bereitgestellt werden sollen. Informationen zum Ändern der Anzahl finden Sie unter Konfigurieren lesbarer sekundärer Replikate.

• Entscheiden Sie, ob Ihnen Konsistenz wichtiger ist als Verfügbarkeit. Dies ist über die Anzahl sekundärer Replikate möglich, die zum Committen einer Transaktion in der Dienstebene „Unternehmenskritisch“ erforderlich sind. Verwenden Sie dazu den optionalen Parameter --sync-secondary-to-commit. Bei Verbindungsproblemen zwischen den Replikaten werden vom primären Replikat möglicherweise keine Transaktionen committet:

  • In einer Konfiguration mit zwei Replikaten muss eine Transaktion in beiden Replikaten committet werden, damit das primäre Replikat eine Erfolgsmeldung erhält.
  • In einer Konfiguration mit drei Replikaten muss eine Transaktion von mindestens zwei der drei Replikate committet werden, damit eine Erfolgsmeldung zurückgegeben wird.

• Entscheiden Sie, ob ein bestimmtes Replikat als primäres Replikat festgelegt werden muss. Informationen zum Angeben eines primären Replikats finden Sie unter Bevorzugtes primäres Replikat.

• Entscheiden Sie, welchen Kubernetes-Diensttyp Sie verwenden möchten: LoadBalancer oder NodePort. Bei Verwendung des Lastenausgleichs (LoadBalancer) können Anwendungen erneut eine Verbindung mit dem gleichen primären Endpunkt herstellen, und die Verbindung wird von Kubernetes an den neuen primären Endpunkt umgeleitet. Bei Verwendung des Knotenports (NodePort) müssen Anwendungen eine Verbindung mit der neuen IP-Adresse herstellen.

Notfallwiederherstellung

• Die Instanzen von SQL Managed Instance mit Azure Arc-Unterstützung an geoprimären und geosekundären Standorten müssen über identische Computeleistung und Kapazität verfügen sowie in der gleichen Dienstebene bereitgestellt werden.

• Entscheiden Sie sich beim Erstellen der Notfallwiederherstellungskonfiguration für einen Speicherort für die Spiegelungszertifikate, auf den beide Cluster, die die Instanz hosten, zugreifen können.

• Überlegen Sie sich, wie die Downtime der primären Instanz überwacht werden soll, um zu entscheiden, wann ein Failover auf die sekundäre Instanz erfolgen soll.

• Jede Instanz verfügt über ihre eigenen Endpunkte. Überlegen Sie sich, wie Ihre Anwendungen im Falle eines Failovers mit möglichst geringer Unterbrechung auf den primären Endpunkt zugreifen.

Entwurfsempfehlungen

Die folgenden Abschnitte enthalten Entwurfsempfehlungen für Zeitpunktwiederherstellung, Hochverfügbarkeit und Notfallwiederherstellung.

Wiederherstellung bis zu einem bestimmten Zeitpunkt

• Definieren Sie beim Bereitstellen einer neuen Instanz von SQL Managed Instance mit Azure Arc-Unterstützung immer die Speicherklasse für Sicherungen, um zu vermeiden, dass standardmäßig die Datenspeicherklasse verwendet wird.

• Verwenden Sie eine Speicherklasse, die ReadWriteMany (RWX) für das Sicherungsvolume unterstützt. Hilfreiche Informationen hierzu finden Sie unter Speicherdisziplinen für SQL Managed Instance mit Azure Arc-Unterstützung.

• Verwenden Sie vor dem Starten eines Wiederherstellungsvorgangs den optionalen Parameter --dry-run, um zu überprüfen, ob der Vorgang erfolgreich wäre. Weitere Informationen finden Sie unter Erstellen einer Datenbank ab einem bestimmten Zeitpunkt mit der Azure CLI.

• Erstellen Sie einen Prozess, um länger aufzubewahrende Sicherungen an Azure oder an einen anderen lokalen Cold Storage zu senden.

• Überwachen Sie den von Ihren Sicherungen beanspruchten Speicher, um zu ermitteln, ob bei Bedarf eine längere Aufbewahrung möglich wäre.

Hochverfügbarkeit

• Führen Sie regelmäßige Übungen durch, um die Hochverfügbarkeit Ihrer Instanz von SQL Managed Instance mit Arc-Unterstützung zu überprüfen. Beispiele für Übungen wären etwa die Löschung eines Pods in einer universellen Instanz und der Ausfall eines Replikats in einer unternehmenskritischen Instanz.

• Stellen Sie in der Ebene „Unternehmenskritisch“ eine Instanz in einer Konfiguration mit drei Replikaten (anstelle von zwei Replikaten) bereit, um Datenverluste nahezu vollständig zu vermeiden.

• Verwenden Sie zur Verbesserung der Verfügbarkeit den Diensttyp „LoadBalancer“, wenn Sie eine Instanz bereitstellen.

• Informationen zu den Einschränkungen im Zusammenhang mit der Hochverfügbarkeit von SQL Managed Instance mit Azure Arc-Unterstützung finden Sie hier.

• Informieren Sie sich über die unterstützten Verfügbarkeitsmodi, um zu entscheiden, welchen Modus Sie angesichts Ihrer Hochverfügbarkeitsanforderungen verwenden sollten.

• Verwenden Sie eines der sekundären Replikate für Leseworkloads, wenn Sie eine unternehmenskritische Instanz mit mehreren Replikaten bereitstellen. Für die Umleitung an die sekundären Replikate muss der sekundäre Endpunkt in Ihrer Anwendungsverbindungszeichenfolge als Dienstlistener angegeben sein. Informationen zu Endpunkten finden Sie unter Abrufen des primären und sekundären Endpunkts und des Verfügbarkeitsgruppenstatus.

• Informationen zu den bewährten Methoden für die Überwachung der Verfügbarkeit Ihrer Instanzen finden Sie unter Verwaltung und Überwachung für SQL Managed Instance mit Azure Arc-Unterstützung.

Notfallwiederherstellung

• Stellen Sie sicher, dass Ihre Instanzen von SQL Managed Instance mit Arc-Unterstützung über unterschiedliche Namen für primäre und sekundäre Standorte verfügen und dass der Wert des freigegebenen Namens für die Standorte identisch ist.

• Führen Sie regelmäßige Übungen zur Notfallwiederherstellung durch, um den Failoverprozess zu überprüfen.

• Erstellen Sie einen Prozess zum Initiieren manueller und erzwungener Failover.

• Informationen zu den bewährten Methoden für die Überwachung der Clusterintegrität sowie dazu, wann ein Failover erforderlich ist, finden Sie unter Verwaltung und Überwachung für SQL Managed Instance mit Azure Arc-Unterstützung.

• Definieren Sie den DNS-Eintrag für den freigegebenen Namen der verteilten Verfügbarkeitsgruppe auf Ihren DNS-Servern, um zu vermeiden, dass DNS-Einträge während des Failovers manuell erstellt werden müssen.

Nächste Schritte

Weitere Informationen zu Ihrer Hybrid- und Multi-Cloud-Umgebung finden Sie in den folgenden Artikeln:

• Was sind Azure Arc-fähige Datendienste (Vorschauversion)?
• Übersicht: Geschäftskontinuität für SQL Managed Instance mit Azure Arc-Unterstützung
• Kubernetes-Validierung von Datendiensten mit Azure Arc-Unterstützung
• Verwalten Ihres Portfolios über Hybrid- und Multicloudvorgänge hinweg
• Datendienste mit Azure Arc-Unterstützung für automatisierte Szenarien mit „Einstieg in Azure Arc“
• Integrieren von Azure-Innovationen in Ihre Hybridumgebungen mit Azure Arc (Lernpfad von Microsoft Learn)