Geschäftskontinuität und Notfallwiederherstellung für azure Arc-fähige SQL Managed Instance

Azure Arc-fähige SQL Managed Instance bietet Funktionen für Geschäftskontinuität und Notfallwiederherstellung (BCDR), die Unternehmen bei der Wiederherstellung von Unterbrechungen und den Betrieb mit minimalen Ausfallzeiten unterstützen.

Dieser Artikel enthält wichtige Entwurfsüberlegungen und Empfehlungen für das Konfigurieren und Verwalten von Geschäftskontinuitätsfunktionen wie Point-in-Time-Wiederherstellung, hohe Verfügbarkeit und Notfallwiederherstellung.

Architektur

Die folgenden Architekturdiagramme zeigen die Hochverfügbarkeitsfunktionen der arc-fähigen SQL Managed Instance auf der Business Critical-Dienstebene, die Failover mit nahezu null Ausfallzeiten unterstützt. Wenn die primäre Instanz fehlschlägt, beendet der Lastenausgleich das Senden von Datenverkehr an diese Instanz. Anschließend wird eine der sekundären Instanzen in die primäre Instanz heraufgestuft, und die neu heraufgestufte Instanz empfängt Lese-/Schreibdatenverkehr vom Lastenausgleichsmodul. Nachdem die fehlgeschlagene Instanz wieder online ist, wird sie als sekundäre Instanz hinzugefügt.

Das folgende Architekturdiagramm zeigt, wie Arc-fähige verwaltete SQL-Instanz auf zwei separaten Kubernetes-Clustern an zwei verschiedenen Standorten für die Notfallwiederherstellung bereitgestellt werden kann.

Das folgende Architekturdiagramm zeigt, wie arc-enabled SQL Managed Instance reagiert, wenn ein Notfallwiederherstellungsfailover initiiert wird.

Entwurfsüberlegungen

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 Geschäftskontinuität und Notfallwiederherstellung nur auf Entwurfsempfehlungen für Geschäftskontinuität liegt, aber die hohe Verfügbarkeit und Resilienz Ihrer Instanz hängt auch von der Verfügbarkeit der zugrunde liegenden Kubernetes-Infrastruktur ab.

Zeitpunktwiederherstellung

• Definieren Sie Ihre Ziele für Wiederherstellungspunktziel (RPO) und Wiederherstellungszeitziel (RTO).

• Bestimmen Sie, wie lange Sie Ihre Sicherungen innerhalb der unterstützten Aufbewahrungsgrenzen aufbewahren und wiederherstellen möchten.

• Berücksichtigen Sie die Auswirkungen auf die Speicherung und die Kosten für die Erhöhung des Aufbewahrungszeitraums Ihrer Sicherungen. Die Standardaufbewahrung beträgt sieben Tage. In diesem Zeitraum können Sie bis zu sieben Tage lang wiederherstellen, und Sie erhalten eine vollständige Sicherung, eine tägliche differenzielle Sicherung und Sicherungen von Transaktionsprotokollen etwa alle fünf Minuten.

• Überlegen Sie, welche Speicherklasse für das persistente Volume für Sicherungen verwendet werden soll. Anleitungen finden Sie unter Speicherdisziplinen für Azure Arc-fähige SQL Managed Instance.

• Berücksichtigen Sie die 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.

• Backups werden immer auf der primären Replika durchgeführt. Berücksichtigen Sie die Leistungseffekte der Sicherungs- und Wiederherstellungsprozesse, wenn Sie die Ressourcen identifizieren, die Ihrer Instanz zugeordnet sind.

• Berücksichtigen Sie, dass Point-in-Time-Wiederherstellungen einer Datenbank keine vorhandene Datenbank überschreiben können. Sie können jedoch Daten in einer neuen Datenbank in derselben Instanz wiederherstellen.

• Berücksichtigen Sie die zusätzlichen Schritte, die erforderlich sind, um Ihre Datenbank vollständig wiederherzustellen, wenn Ihre Anwendung während des Wiederherstellungsvorgangs online ist.

• Berücksichtigen Sie die zusätzlichen Schritte, die zum Wiederherstellen einer Datenbank in einer Multireplikatinstanz erforderlich sind, wie in Wiederherstellen einer Datenbank auf einer Multireplikatinstanzbeschrieben.

• 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.

Hohe Verfügbarkeit

• Überprüfen Sie die Verfügbarkeitsanforderungen Ihrer Workload, und entscheiden Sie sich für die Dienstebene, die für Ihre Bereitstellung von arc-fähigen verwalteten SQL-Instanzen am besten geeignet ist:

  • In der Dienstebene für allgemeine Zwecke ist ein einzelnes Replikat verfügbar, und die hohe Verfügbarkeit wird über die Kubernetes-Orchestrierung erreicht.
  • Auf der Dienstebene "Business Critical" bietet die Azure Arc-aktivierte SQL Managed Instance eine isolierte Verfügbarkeitsgruppe, zusätzlich zu dem, was durch die Kubernetes-Orchestrierung nativ bereitgestellt wird.

• Berücksichtigen Sie die potenziellen geschäftlichen Auswirkungen von Ausfallzeiten auf der Dienstebene für allgemeine Zwecke, die aufgrund des Vorhandenseins nur eines Replikats resultieren könnten.

• Überlegen Sie, wie viele Replikate – eine bis drei – in der Business Critical-Dienstebene bereitgestellt werden sollen.

• Wenn Sie eine Instanz in einer geschäftskritischen Dienstebene mit zwei oder mehr Replikaten bereitstellen, können Sie die sekundären Replikate als lesbar konfigurieren. Entscheiden Sie über die Anzahl der sekundären Replikate, die auf der Business Critical-Dienstebene bereitgestellt werden sollen. Informationen zum Ändern der Anzahl finden Sie unter Konfigurieren lesbarer sekundärer Replikate.

• Entscheiden Sie sich, die Konsistenz gegenüber der Verfügbarkeit zu priorisieren, indem Sie die Anzahl der sekundären Replikate festlegen, die erforderlich sind, um eine Transaktion in der Business Critical-Dienstebene abzuschließen, und verwenden Sie dazu den optionalen Parameter --sync-secondary-to-commit. Wenn es Verbindungsprobleme zwischen den Replikaten gibt, könnte der primäre Server möglicherweise keine Transaktionen bestätigen.

  • In einer Konfiguration mit zwei Replikaten muss die Transaktion auf beiden Replikaten abgeschlossen werden, damit die primäre Instanz eine Erfolgsnachricht erhält.
  • In einer Konfiguration mit drei Replikaten müssen mindestens zwei der drei Replikate eine Transaktion ausführen, um eine Erfolgsmeldung zurückzugeben.

• Entscheiden Sie, ob Sie ein bestimmtes Replikat als primäres Replikat festlegen müssen. Informationen zum Angeben eines primären Replikats finden Sie unter bevorzugtes primäres Replikat.

• Entscheiden Sie, welchen Kubernetes-Diensttyp Sie verwenden, LoadBalancer oder NodePort-. Wenn Sie das Lastenausgleichsmodul verwenden, können Anwendungen eine erneute Verbindung mit demselben primären Endpunkt herstellen, und Kubernetes leitet die Verbindung an die neue Primäre um. Wenn Sie den Knotenport verwenden, müssen Anwendungen erneut eine Verbindung mit der neuen IP-Adresse herstellen.

Notfallwiederherstellung

• Die Instanzen von Azure Arc-fähigen SQL Managed Instance an den geo-primären und geo-sekundären Standorten müssen in Rechenleistung und Kapazität identisch sein und in den gleichen Dienstebenen bereitgestellt werden.

• Entscheiden Sie sich für einen Speicherort, an dem die Spiegelzertifikate gespeichert werden sollen, wenn Sie die Notfallwiederherstellungskonfiguration erstellen, auf die beide Cluster zugreifen können, die die Instanz hosten.

• Überlegen Sie, wie Sie die Ausfallzeiten der primären Instanz überwachen, um zu entscheiden, wann ein Failover für die sekundäre Instanz ausgeführt werden soll.

• Jede Instanz verfügt über eigene Endpunkte. Überlegen Sie, wie Ihre Anwendungen bei Failover auf den primären Endpunkt mit minimalen Unterbrechungen zugreifen.

Designempfehlungen

In den folgenden Abschnitten werden Entwurfsempfehlungen zu Point-in-Time-Wiederherstellung, hoher Verfügbarkeit und Notfallwiederherstellung aufgeführt.

Zeitpunktwiederherstellung

• Definieren Sie bei der Bereitstellung einer neuen Arc-fähigen SQL Managed Instance immer die Speicherklasse für Sicherungen, um die Voreinstellung der Datenspeicherklasse zu vermeiden.

• 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 aus einem bestimmten Zeitpunkt mithilfe von az CLI.

• Erstellen Sie einen Prozess zum Senden von Sicherungen, die längere Aufbewahrungszeiträume an Azure oder einen anderen lokalen Kaltspeicher benötigen.

• Überwachen Sie den durch Ihre Sicherungen genutzten Speicher, um festzustellen, ob Sie bei Bedarf eine längere Aufbewahrung ermöglichen können.

Hohe Verfügbarkeit

• Führen Sie regelmäßige Übungen durch, um die hohe Verfügbarkeit Ihrer Arc-fähigen SQL Managed Instance-Instanz 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 Business Critical-Ebene eine Instanz in einer Konfiguration mit drei Replikaten anstelle einer Konfiguration mit zwei Replikaten bereit, um nahezu null Datenverluste zu erzielen.

• Um eine bessere Verfügbarkeit zu erzielen, verwenden Sie LoadBalancer als Diensttyp bei der Bereitstellung einer Instanz.

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

• Überprüfen Sie die unterstützten Verfügbarkeitsmodi, um zu entscheiden, welcher Modus basierend auf Ihren Anforderungen für hohe Verfügbarkeit verwendet werden soll.

• 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 Management and monitoring for Azure Arc-enabled SQL Managed Instance.

Notfallwiederherstellung

• Stellen Sie sicher, dass Ihre Instanzen von Arc-fähigen SQL Managed Instances unterschiedliche Namen für primäre und sekundäre Standorte haben und dass der gemeinsame Name 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 von manuellen und erzwungenen Failovern.

• Informationen zu den bewährten Methoden zum Überwachen der Integrität der Cluster und zum Verständnis, wann ein Failover erforderlich ist, finden Sie unter Verwaltung und Überwachung für azure Arc-fähige SQL Managed Instance.

• 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 Multicloud-Cloud-Reise finden Sie in den folgenden Artikeln:

• Was sind Azure Arc-fähige Datendienste?
• Übersicht: Azure Arc-fähige SQL Managed Instance für kontinuierlichen Geschäftsbetrieb
• Azure Arc-fähige Datendienste Kubernetes-Überprüfung
• Verwalten Ihres Portfolios über Hybrid- und Multicloud-Vorgänge
• Azure Arc-fähige Datendienste für automatisierte Szenarien mit Azure Arc Jumpstart
• Bringen Sie Azure-Innovationen in Ihre Hybridumgebungen mit Azure Arc, einem Lernpfad von Microsoft Learn