Geschäftskontinuität und Datenbankwiederherstellung – SQL Server

Gilt für: SQL Server 2016 (13.x) und spätere Versionen

Dieser Artikel bietet eine Übersicht über Lösungen für Geschäftskontinuität für Hochverfügbarkeit und Notfallwiederherstellung in SQL Server unter Windows und Linux.

Eine allgemeine Aufgabe, die jeder berücksichtigen sollte, der SQL Server bereitstellt, ist das Sicherstellen der Verfügbarkeit aller unternehmenskritischen SQL Server-Instanzen und der darin enthaltenen Datenbanken, wenn das Unternehmen oder die Benutzer diese benötigen, ob von 9 bis 17 Uhr oder rund um die Uhr. Das Ziel ist, das Unternehmen mit minimaler oder ohne Unterbrechung aufrechtzuerhalten. Dieses Konzept wird auch als Geschäftskontinuität bezeichnet.

In SQL Server 2017 (14.x) wurden viele neue Funktionen oder Erweiterungen für vorhandene eingeführt, einige davon dienen der Verfügbarkeit. Die wichtigste Erweiterung für SQL Server 2017 (14.x) war die Unterstützung für SQL Server für Linux-Distributionen. Eine vollständige Liste der neuen Features in SQL Server finden Sie in den folgenden Artikeln:

• Neue Funktionen in SQL Server 2017
• Neuigkeiten zu SQL Server 2017 für Linux
• Neue Funktionen in SQL Server 2019
• Neuigkeiten zu SQL Server 2019 für Linux
• Neue Funktionen in SQL Server 2022

In diesem Artikel werden die Verfügbarkeitsszenarien ab SQL Server 2017 (14.x) sowie neue und erweiterte Verfügbarkeitsfeatures behandelt. Dabei sind auch hybride Szenarien enthalten, durch die SQL Server-Bereitstellungen unter Windows Server und Linux umfassen können sowie Szenarien, mit denen die Anzahl von lesbaren Kopien einer Datenbank erhöht werden kann.

Dieser Artikel behandelt keine Verfügbarkeitsoptionen außerhalb von SQL Server, z. B. solche, die durch die Virtualisierung bereitgestellt werden. Sämtliche Erläuterungen beziehen sich auf Installationen von SQL Server einer Gast-VM, die sich entweder in der öffentlichen Cloud befindet oder von einem lokalen Hypervisorserver gehostet wird.

SQL Server-Szenarios, die Verfügbarkeitsfeatures verwenden

Always On-Verfügbarkeitsgruppen, Always On-Failoverclusterinstanzen und der Protokollversand können auf unterschiedliche Weise und nicht unbedingt nur zu Verfügbarkeitszwecken verwendet werden. Verfügbarkeitsfunktionen können auf vier verschiedene Arten verwendet werden:

• Hochverfügbarkeit
• Notfallwiederherstellung
• Migrationen und Upgrades
• Horizontales Hochskalieren von lesbaren Kopien von einer oder mehreren Datenbanken

In den folgenden Abschnitten werden die relevanten Funktionen erläutert, die für ein bestimmtes Szenario verwendet werden können. Die einzige Funktion, die nicht behandelt wird, ist die SQL Server-Replikation. Die SQL Server-Replikation ist nicht offiziell als Verfügbarkeitsfeature für „Always On“ definiert, wird jedoch häufig zum Herstellen redundanter Daten in bestimmten Szenarios verwendet. Die Mergereplikation wird für SQL Server unter Linux nicht unterstützt. Weitere Informationen finden Sie unter SQL Server-Replikation unter Linux.

Hochverfügbarkeit

Es ist wichtig, sicherzustellen, dass SQL Server-Instanzen oder -Datenbanken im Fall eines lokalen Problems in einem Rechenzentrum oder einer einzelnen Region in der Cloudregion verfügbar sind. In diesem Abschnitt wird erläutert, wie die SQL Server-Verfügbarkeitsfeatures Ihnen bei dieser Aufgabe helfen können. Alle beschriebenen Features sind für Windows Server und Linux verfügbar.

Verfügbarkeitsgruppen

Die in SQL Server 2012 (11.x) eingeführten Always On-Verfügbarkeitsgruppen stellen Schutz auf Datenbankebene bereit, indem sie jede Transaktion einer Datenbank zu einer anderen Instanz (auch als Replikat bezeichnet) senden, die eine Kopie dieser Datenbank in einem speziellen Zustand enthält. Eine Verfügbarkeitsgruppe kann in der Standard Edition oder Enterprise Edition bereitgestellt werden. Die Instanzen, die in einer Verfügbarkeitsgruppe enthalten sind, können eigenständig oder Always On-Failoverclusterinstanzen (FCIs, im nächsten Abschnitt beschrieben) sein. Da die Transaktionen direkt an ein Replikat gesendet werden, werden Verfügbarkeitsgruppen empfohlen, wenn Anforderungen für niedrigere Ziele bei Wiederherstellungspunkten und der Wiederherstellungszeit gelten. Das Verschieben von Daten zwischen Replikaten kann synchron oder asynchron erfolgen. Die Enterprise Edition unterstützt bis zu drei synchrone Replikate, einschließlich des primären Replikats. Eine Verfügbarkeitsgruppe enthält eine vollständige Lese-/Schreibkopie der Datenbank, die sich auf dem primären Replikat befindet. Sekundäre Replikate können keine Transaktionen direkt von Benutzer*innen oder Anwendungen empfangen.

Vor SQL Server 2022 (16.x) boten Verfügbarkeitsgruppen nur Schutz auf Datenbankebene und nicht auf Instanzebene. Alles, was nicht im Transaktionsprotokoll erfasst oder in der Datenbank konfiguriert ist, muss für jedes sekundäre Replikat manuell synchronisiert werden. Einige Beispiele für Objekte, die manuell synchronisiert werden müssen, sind Anmeldungen auf Instanzebene, Verbindungsserver und SQL Server-Agent-Aufträge.

In SQL Server 2022 (16.x) und höheren Versionen können Sie Metadatenobjekte wie Benutzer, Anmeldungen, Berechtigungen und SQL Server-Agent-Aufträge zusätzlich zur Instanzebene auf AG-Ebene verwalten. Weitere Informationen finden Sie unter Was ist eine eigenständige Verfügbarkeitsgruppe?

Eine Verfügbarkeitsgruppe besitzt eine weitere Komponente, die als Listener bezeichnet wird. Durch diesen können Anwendungen und Benutzer*innen eine Verbindung herstellen, ohne zu wissen, welche Instanz von SQL Server das primäre Replikat hostet. Jede Verfügbarkeitsgruppe hat einen eigenen Listener. Während die Implementierungen des Listeners sich geringfügig zwischen Windows Server und Linux unterscheiden, sind die bereitgestellte Funktionalität und die Verwendung identisch. Das folgende Diagramm zeigt eine Windows Server-basierte AG, die einen Windows Server-Failovercluster (WSFC) verwendet. Ein zugrunde liegender Cluster auf der Betriebssystemebene ist für die Verfügbarkeit erforderlich, unabhängig davon, ob es sich auf Linux oder Windows Server befindet. Dieses Beispiel zeigt eine einfache Konfiguration für zwei Server oder Knoten, bei der ein WSFC den zugrunde liegenden Cluster darstellt.

Bei Replikaten gelten für die Standard Edition und die Enterprise Edition unterschiedliche Höchstwerte. Eine Verfügbarkeitsgruppe in der Standard Edition, die als Basis-Verfügbarkeitsgruppe bezeichnet wird, unterstützt zwei Replikate (ein primäres und ein sekundäres) mit nur einer einzigen Datenbank in der Verfügbarkeitsgruppe. In der Enterprise Edition können nicht nur mehrere Datenbanken für eine einzige Verfügbarkeitsgruppe konfiguriert werden, sondern es können auch bis zu neun Replikate (ein primäres, acht sekundäre) verwendet werden. Die Enterprise Edition bietet weitere optionale Vorteile, z.B. lesbare sekundäre Replikate, das Erstellen von Sicherungen aus einem sekundären Replikat usw.

Verfügbarkeitsgruppen können für die Verfügbarkeit entweder automatische oder manuelle Failover bereitstellen. Automatische Failover können auftreten, wenn die synchrone Datenverschiebung konfiguriert ist und die Datenbank auf dem primären und sekundären Replikat sich in einem synchronisierten Zustand befindet. Solange der Listener verwendet wird und die Datenbank eine höhere Version des .NET Framework (3.5 mit einem Update oder 4.0 und höher) verwendet, sollte das Failover mit minimaler oder ohne Auswirkungen für die Benutzer*innen ausgeführt werden. Ein Failover zu einem sekundären Replikat, das dieses zum neuen primären Replikat macht, kann als automatisch oder manuell konfiguriert werden und wird im Allgemeinen in Sekunden gemessen.

In der folgenden Liste werden einige Unterschiede mit AGs unter Windows Server und Linux hervorgehoben:

• Da die zugrunde liegenden Cluster unter Linux und Windows Server unterschiedlich funktionieren, werden unter Linux alle Failover (manuell oder automatisch) von Verfügbarkeitsgruppen über den Cluster ausgeführt. Bei Bereitstellungen von Windows Server-basierten Verfügbarkeitsgruppen müssen manuelle Failover über SQL Server ausgeführt werden. Automatische Failover werden unter Windows Server und Linux von den zugrunde liegenden Clustern behandelt.
• Für SQL Server für Linux umfasst die empfohlene Konfiguration für Verfügbarkeitsgruppen mindestens drei Replikate. Der Grund dafür liegt in der Funktionsweise des zugrunde liegenden Clusterings.
• Unter Linux wird der gemeinsame Name, der von jedem Listener verwendet wird, in DNS und nicht im Cluster definiert, wie er sich auf Windows Server befindet.

SQL Server 2017 (14.x) führt die folgenden Features und Verbesserungen für AGs ein:

• Clustertypen
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• Erweiterte MS DTC-Unterstützung (Microsoft Distributed Transaction Coordinator) für Windows Server-basierte Konfigurationen
• Zusätzliche Szenarios für das horizontale Hochskalieren von schreibgeschützten Datenbanken (später in diesem Artikel beschrieben)

Clustertypen für Verfügbarkeitsgruppen

Das integrierte Verfügbarkeitsformular des Clusterings in Windows Server wird über eine Funktion namens Failoverclustering aktiviert. Dadurch kann ein WSFC erstellt werden, der mit einer Verfügbarkeitsgruppe oder einer Failoverclusterinstanz (FCI) verwendet werden kann. Die Integration von Verfügbarkeitsgruppen und FCIs wird über clusterfähige Ressourcen-DLLs bereitgestellt, die in SQL Server enthalten sind.

SQL Server für Linux unterstützt mehrere Clustertechnologien. Microsoft unterstützt die SQL Server Komponenten, während unsere Partner die entsprechende Clustertechnologie bereitstellen. So unterstützt SQL Server für Linux zusammen mit Pacemaker als Clusterlösung auch HPE Serviceguard und DH2i DxEnterprise.

Ein Windows-basierter Failovercluster und eine Linux-Clusterlösung haben mehr Gemeinsamkeiten als Unterschiede. Beide ermöglichen das Kombinieren von einzelnen Servern in einer Konfiguration, um die Verfügbarkeit zu gewährleisten und enthalten Konzepte für Ressourcen, Einschränken (die jedoch unterschiedlich implementiert sind), Failover usw.

Microsoft stellt z. B. für die Unterstützung von Pacemaker für die Konfiguration von Verfügbarkeitsgruppen und FCIs, einschließlich des automatischen Failovers, das Paket mssql-server-ha bereit. Dieses ähnelt den Ressourcen-DLLs in einem WSFC, ist aber nicht mit diesen identisch. Einer der Unterschiede zwischen einem WSFC und Pacemaker besteht darin, dass Pacemaker keine Netzwerknamenressource enthält. Diese Komponente ermöglicht das Abstrahieren des Namens des Listeners (oder der FCI) auf einem WSFC. DNS stellt diese Namensauflösung unter Linux bereit.

Aufgrund der Unterschiede im Clusterstapel müssen für Verfügbarkeitsgruppen einige Änderungen vorgenommen werden, da SQL Server einige der Metadaten behandeln muss, die nativ von einem WSFC behandelt werden. Eine wichtige Änderung ist die Einführung eines Clustertyps für eine Verfügbarkeitsgruppe. Dieser wird in sys.availability_groups in den Spalten cluster_type und cluster_type_desc gespeichert. Es gibt drei Clustertypen:

• WSFC
• Extern
• Keine

Alle Verfügbarkeitsgruppen, die Verfügbarkeit erfordern, müssen einen zugrunde liegenden Cluster verwenden. Dies ist im Fall von SQL Server 2017 (14.x) und höher ein WSFC oder ein Linux-Cluster-Agent. Für Windows Server-basierte Verfügbarkeitsgruppen, die einen zugrunde liegenden WSFC verwenden, ist der Standardclustertyp WSFC, der nicht explizit festgelegt werden muss. Beim Erstellen von Linux-basierten Verfügbarkeitsgruppen muss der Clustertyp auf „Extern“ festgelegt werden. Die Integration mit einer externen Clusterlösung unter Linux wird nach der Erstellung der Verfügbarkeitsgruppe konfiguriert, während dies bei einem WSFC zur Erstellungszeit erfolgt.

Der Clustertyp „Keiner“ kann für Windows Server- und Linux-Verfügbarkeitsgruppen verwendet werden. Das Festlegen des Clustertyps auf „Keiner“ bedeutet, dass die Verfügbarkeitsgruppe keinen zugrunde liegenden Cluster erfordert. Das bedeutet, dass es sich bei SQL Server 2017 (14.x) um die erste Version von SQL Server handelt, die Verfügbarkeitsgruppen ohne einen Cluster unterstützt. Der Nachteil hierbei ist jedoch, dass diese Konfiguration nicht als Hochverfügbarkeitslösung unterstützt wird.

Für Benutzer*innen, die nur zusätzliche schreibgeschützte Kopien einer Datenbank hinzufügen möchten oder die festlegen möchten, welche Optionen eine Verfügbarkeitsgruppe für die Migration/Upgrades bereitstellt, ohne an die zusätzliche Komplexität eines zugrunde liegenden Clusters oder der Replikation gebunden zu sein, ist eine Verfügbarkeitsgruppe mit dem Clustertyp „Keiner“ die ideale Lösung. Weitere Informationen finden Sie in den Abschnitten "Migrationen und Upgrades" und " Read-Scale".

Der folgende Screenshot zeigt die Unterstützung für die verschiedenen Arten von Clustertypen in SQL Server Management Studio (SSMS). Sie müssen Version 17.1 oder höher ausführen. Der folgende Screenshot stammt aus Version 17.2:

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

In SQL Server 2016 (13.x) wurde die Unterstützung für die Anzahl von synchronen Replikaten in der Enterprise Edition von zwei auf drei erhöht. Wenn jedoch ein sekundäres Replikat synchronisiert wurde und bei einem anderen ein Problem auftrat, konnte das Verhalten nicht gesteuert werden, um dem primären Replikat mitzuteilen, entweder auf das sich falsch verhaltende Replikat zu warten oder fortzufahren. Dadurch erhält das primäre Replikat ab einem bestimmten Punkt weiterhin Schreibdatenverkehr, obwohl das sekundäre Replikat sich nicht in einem synchronisierten Zustand befindet. Dies bedeutet, dass es zu Datenverlusten im sekundären Replikat kommt.

In SQL Server 2017 (14.x) und höheren Versionen können Sie das Verhalten der Vorgänge steuern, wenn synchrone Replikate vorhanden REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITsind. Diese Option funktioniert folgendermaßen:

• Es gibt drei mögliche Werte: 0, 1 und 2.
• Der Wert entspricht der Anzahl von sekundären Replikaten, die synchronisiert werden müssen, und hat Auswirkungen auf Datenverluste, auf die Verfügbarkeit von Verfügbarkeitsgruppen und auf Failover.
• Für WSFCs und den Clustertyp „Keiner“ ist der Standardwert 0 und kann manuell auf 1 oder 2 festgelegt werden.
• Für den Clustertyp „Extern“ wird dies standardmäßig durch den Clustermechanismus festgelegt, kann aber manuell überschrieben werden. Bei drei synchronen Replikaten ist der Standardwert 1.

Unter Linux wird der Wert für REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT in der Ressource der Verfügbarkeitsgruppe im Cluster konfiguriert. Unter Windows wird er per Transact-SQL festgelegt.

Ein Wert größer 0 gewährleistet einen höheren Datenschutz, denn wenn die erforderliche Anzahl von sekundären Replikaten nicht verfügbar ist, ist auch das primäre Replikat nicht verfügbar, bis dieses Problem behoben ist. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT wirkt sich auch auf das Failover-Verhalten aus, da das automatische Failover nicht stattfinden kann, wenn sich nicht die richtige Anzahl sekundärer Replikate im richtigen Zustand befindet. Unter Linux lässt ein Wert von 0 keine automatischen Failover zu. Wenn Sie unter Linux also synchrone Replikate mit automatischem Failover verwenden, muss ein Wert größer 0 festgelegt werden, um ein automatisches Failover zu erzielen. 0 unter Windows Server entspricht dem Verhalten in SQL Server 2016 (13.x) und früheren Versionen.

Erweiterte Unterstützung für den Microsoft Distributed Transaction Coordinator

Vor SQL Server 2016 (13.x) bestand die einzige Möglichkeit für Verfügbarkeit in SQL Server für Anwendungen, die verteilte Transaktionen erfordern, die DTC im Hintergrund ausführen, in der Bereitstellung von FCIs. Eine verteilte Transaktion kann auf zwei Arten erfolgen:

• Eine Transaktion, die mehr als eine Datenbank auf derselben Instanz von SQL Server umfasst
• Eine Transaktion, die mehr als eine Instanz von SQL Server oder möglicherweise eine Nicht-SQL Server-Datenquelle umfasst

In SQL Server 2016 (13.x) wurde eine Teilunterstützung für DTC mit Verfügbarkeitsgruppen eingeführt, die das zweite Szenario abdecken. SQL Server 2017 (14.x) unterstützte dann beide Szenarien mit DTC.

Ab SQL Server 2017 (14.x) kann einer Verfügbarkeitsgruppe auch nach deren Erstellung DTC-Unterstützung hinzugefügt werden. In SQL Server 2016 (13.x) konnte die Unterstützung für DTC für eine Verfügbarkeitsgruppe erst aktiviert werden, nachdem die Verfügbarkeitsgruppe erstellt wurde.

Failoverclusterinstanzen

Gruppierte Installationen sind eine Funktion von SQL Server seit Version 6.5. FCIs sind eine bewährte Methode zum Gewährleisten der Verfügbarkeit für die gesamte Installation von SQL Server, die als Instanz bezeichnet wird. Das bedeutet, dass alle Elemente in der Instanz (einschließlich Datenbanken, SQL Server-Agent-Aufträge, Verbindungsserver) auf einen anderen Server verschoben werden, wenn auf dem zugrunde liegenden Server ein Problem auftritt. Alle FCIs erfordern freigegebenen Speicher, auch wenn dieser über ein Netzwerk bereitgestellt wird. Die Ressourcen der FCIs können jeweils nur von einem Knoten gleichzeitig ausgeführt und besessen werden. Im folgenden Diagramm besitzt der erste Knoten des Clusters den FCI, was bedeutet, dass er über die freigegebenen Speicherressourcen verfügt, die damit verbunden sind, die durch die durchgezogene Linie an den Speicher gekennzeichnet sind.

Nach einem Failover ändert sich der Besitz wie im folgenden Diagramm dargestellt:

Mit einer FCI treten keine Datenverluste auf, aber der zugrunde liegende freigegebene Speicher ist ein Single Point of Failure, da eine Kopie der Daten vorhanden ist. FCIs werden häufig mit anderen Verfügbarkeitsmethoden kombiniert, z. B. Verfügbarkeitsgruppen und Protokollversand, damit redundante Kopien der Datenbank verfügbar sind. Die zusätzlich bereitgestellte Methode sollte einen anderen physischen Speicher als die FCI verwenden. Wird für die FCI ein Failover auf einen anderen Knoten ausgeführt, wird sie auf dem einen Knoten beendet und auf dem anderen Knoten gestartet. Dies ähnelt der Vorgehensweise beim Aus- und Einschalten eines Servers. Eine FCI durchläuft den normalen Wiederherstellungsprozess. Das bedeutet, dass alle Transaktionen ein Rollforward ausgeführt wird, die einen benötigen, und für alle unvollständigen Transaktionen wird ein Rollback ausgeführt. Daher ist eine Datenbank von einem Datenpunkt aus bis zum Zeitpunkt des Fehlers oder des manuellen Failovers konsistent und es kommt nicht zu Datenverlust. Datenbanken sind erst verfügbar, wenn die Wiederherstellung abgeschlossen ist. Die Wiederherstellungszeit hängt also von mehreren Faktoren ab und dauert im Allgemeinen länger als das Ausführen eines Failovers für eine Verfügbarkeitsgruppe. Der Kompromiss besteht darin, dass beim Fehlschlagen einer AG möglicherweise zusätzliche Aufgaben erforderlich sind, um eine Datenbank nutzbar zu machen, z. B. das Aktivieren eines SQL Server-Agent-Auftrags.

FCIs abstrahieren genau wie Verfügbarkeitsgruppen, auf welchem Knoten des zugrunde liegenden Clusters diese gehostet werden. Eine FCI behält immer denselben Namen bei. Anwendungen und Benutzer verbinden sich nie mit den Knoten, sondern der eindeutige Name, der der FCI zugewiesen ist, wird verwendet. Eine FCI kann in einer Verfügbarkeitsgruppe als eine der Instanzen enthalten sein, die entweder ein primäres oder ein sekundäres Replikat hosten.

In der folgenden Liste werden einige Unterschiede mit FCIs unter Windows Server und Linux hervorgehoben:

• Unter Windows Server ist FCI ein Teil des Installationsvorgangs. Unter Linux wird eine FCI nach der Installation von SQL Server konfiguriert.
• Linux unterstützt nur eine einzige Installation von SQL Server pro Host, sodass alle FCIs eine Standardinstanz darstellen. Windows Server unterstützt bis zu 25 FCIs pro WSFC.
• Der allgemeine Name, der von FCIs unter Linux verwendet wird, wird in DNS definiert und sollte mit dem der Ressource identisch sein, die für die FCI erstellt wurde.

Protokollversand

Wenn die Ziele für den Wiederherstellungspunkt und die Wiederherstellungszeit flexibler sind, oder Datenbanken nicht als unternehmenskritisch betrachtet werden, ist der Protokollversand ein weiteres bewährtes Verfügbarkeitsfeature in SQL Server. Basierend auf den nativen Sicherungen von SQL Server generiert der Prozess für den Protokollversand automatisch Transaktionsprotokollsicherungen, kopiert diese auf eine oder mehrere Instanzen, die als betriebsbereit bekannt sind, und wendet sie auf diese Standbyinstanzen an. Der Protokollversand verwendet SQL Server-Agent-Aufträge, um den Sicherungs- und Kopiervorgang sowie den Anwendungsvorgang der Transaktionsprotokollsicherungen zu automatisieren.

Der größte Vorteil der Verwendung des Protokollversands in gewissem Umfang ist der, dass menschliche Fehler erfasst werden. Die Anwendung der Transaktionsprotokolle kann verzögert werden. Wenn also jemand etwas wie eine UPDATE ohne Klausel WHERE ausgibt, hat der Standbymodus möglicherweise nicht die Änderung, sodass Sie während der Reparatur des primären Systems zu diesem Wechseln wechseln können. Während der Protokollversand einfach zu konfigurieren ist, ist das Wechseln von der primären zur betriebsbereiten Standbyinstanz, auch als Rollenänderung bezeichnet, immer ein manueller Vorgang. Eine Rollenänderung wird über Transact-SQL initiiert, und alle Objekte, die nicht im Transaktionsprotokoll erfasst sind, müssen wie bei Verfügbarkeitsgruppen manuell synchronisiert werden. Der Protokollversand muss pro Datenbank konfiguriert werden, während einzelne Verfügbarkeitsgruppen mehrere Datenbanken enthalten können.

Im Gegensatz zu einer Verfügbarkeitsgruppe oder FCI bietet der Protokollversand keine Abstraktion für eine Rollenänderung, die Anwendungen verarbeiten können müssen. Techniken wie ein DNS-Alias (CNAME) können eingesetzt werden, es gibt jedoch Vor- und Nachteile, z.B. die Zeit, die ein DNS nach dem Wechsel zum Aktualisieren benötigt.

Notfallwiederherstellung

Wenn Ihr primärer Verfügbarkeitsstandort einer Katastrophe wie einem Erdbeben oder einer Überschwemmung ausgesetzt ist, muss das Unternehmen darauf vorbereitet sein, die Systeme an anderer Stelle online schalten zu können. Dieser Abschnitt erläutert, wie die SQL Server-Verfügbarkeitsfunktionen Sie bei der Geschäftskontinuität unterstützen können.

Verfügbarkeitsgruppen

Einer der Vorteile von Verfügbarkeitsgruppen ist, dass Hochverfügbarkeit und Notfallwiederherstellung mithilfe eines einzigen Features konfiguriert werden können. Ohne die Anforderung, dass die Hochverfügbarkeit des freigegebenen Speichers sichergestellt werden muss, ist es deutlich einfacher, lokale Replikate für die Hochverfügbarkeit in einem Rechenzentrum und Remotereplikate mit jeweils separatem Speicher für die Notfallwiederherstellung in anderen Rechenzentren zu verwalten. Das Vorhandensein von zusätzlichen Kopien der Datenbank ist der Nachteil zur Gewährleistung von Redundanz. Ein Beispiel für eine AG, die mehrere Rechenzentren umfasst, wird im folgenden Diagramm gezeigt. Ein primäres Replikat ist dafür verantwortlich, alle sekundären Replikate zu synchronisieren.

Außerhalb einer Verfügbarkeitsgruppe mit dem Clustertyp „Keiner“ erfordert eine Verfügbarkeitsgruppe, dass alle Replikate Teil desselben zugrunde liegenden Clusters (WSFC oder externe Clusterlösung) sind. Das bedeutet, dass der WSFC in der obigen Abbildung für die Verwendung auf zwei verschiedenen Rechenzentren aufgeteilt wird. Dadurch erhöht sich die Komplexität. unabhängig von der Plattform (Windows Server oder Linux) erhöht wird. Das Strecken von Clustern über Entfernungen erhöht die Komplexität.

In SQL Server 2016 (13.x) wurde eingeführt, dass eine verteilte Verfügbarkeitsgruppe einer Verfügbarkeitsgruppe ermöglichen kann, Verfügbarkeitsgruppen auf mehrere Cluster zu erweitern. Verteilte Verfügbarkeitsgruppen entkoppeln die Anforderung, dass alle Knoten im selben Cluster enthalten sein müssen. Dadurch wird das Konfigurieren der Notfallwiederherstellung wesentlich einfacher. Weitere Informationen finden Sie unter Verteilte Verfügbarkeitsgruppen.

Failoverclusterinstanzen

FCIs können für die Notfallwiederherstellung verwendet werden. Wie bei einer normalen Verfügbarkeitsgruppe muss der zugrunde liegende Clustermechanismus auch auf alle Standorte erweitert werden. Dadurch erhöht sich die Komplexität. Zusätzlich muss für FCIs der freigegebene Speicher berücksichtigt werden. Dieselben Datenträger müssen am primären und an den sekundären Standorten verfügbar sein. Eine externe Methode ist erforderlich, z. B. die Funktionalität, die vom Speicheranbieter auf Hardwareebene oder durch das Verwenden von Speicherreplikaten unter Windows Server bereitgestellt wird, um sicherzustellen, dass die von der FCI verwendeten Datenträger an anderer Stelle vorhanden sind.

Protokollversand

Der Protokollversand ist eine der ältesten Methoden für die Bereitstellung der Notfallwiederherstellung für SQL Server-Datenbanken. Der Protokollversand wird häufig mit AGs und FCIs verwendet, um eine kostengünstige und einfachere Notfallwiederherstellung bereitzustellen, bei der andere Optionen aufgrund von Umgebung, Verwaltungskenntnissen oder Budget eine Herausforderung darstellen können. Ähnlich wie bei der Hochverfügbarkeit für den Protokollverstand wird bei vielen Umgebungen das Laden eines Transaktionsprotokolls verzögert, um menschliche Fehler zu erfassen.

Migrationen und Upgrades

Beim Bereitstellen neuer Instanzen oder beim Aktualisieren alter Instanzen sind lange Ausfallzeiten für Unternehmen nicht akzeptabel. In diesem Abschnitt wird erläutert, wie die Verfügbarkeitsfeatures von SQL Server verwendet werden können, um die Ausfallzeiten in einer geplanten Architekturänderung, Serverwechsel, Plattformänderung (z. B. Windows Server zu Linux oder umgekehrt) oder während des Patchings zu minimieren.

Verfügbarkeitsgruppen

Für eine vorhandene Instanz mit einer oder mehreren Verfügbarkeitsgruppen kann ein Upgrade auf höhere Versionen von SQL Server durchgeführt werden. Dies erfordert zwar einige Ausfallzeiten, mit dem richtigen Umfang der Planung, kann jedoch minimiert werden.

Wenn das Ziel darin besteht, zu neuen Servern zu migrieren und die Konfiguration (einschließlich des Betriebssystems oder der SQL Server-Version) nicht zu ändern, können diese Server als Knoten zum vorhandenen zugrunde liegenden Cluster hinzugefügt und der AG hinzugefügt werden. Wenn das Replikat oder die Replikate sich im richtigen Zustand befinden, kann ein manuelles Failover auf einen neuen Server ausgeführt werden. Die alten können dann aus der Verfügbarkeitsgruppe entfernt und anschließend außer Betrieb genommen werden.

Verteilte Verfügbarkeitsgruppen stellen eine weitere Methode zum Migrieren zu einer neuen Konfiguration oder zum Aktualisieren von SQL Server dar. Da eine verteilte Verfügbarkeitsgruppe verschiedene zugrunde liegende Verfügbarkeitsgruppen auf verschiedenen Architekturen unterstützt, können Sie z. B. von SQL Server 2016 (13.x) unter Windows Server 2012 R2 auf SQL Server 2017 (14.x) unter Windows Server 2016 wechseln.

Schließlich können Verfügbarkeitsgruppen mit dem Clustertyp „Keiner“ auch für die Migration oder Upgrades verwendet werden. Sie können Clustertypen in einer typischen Konfiguration von Verfügbarkeitsgruppen nicht mischen und anpassen, darum müssen alle Replikate den Typ „Keiner“ aufweisen. Eine verteilte Verfügbarkeitsgruppe kann verwendet werden, um Verfügbarkeitsgruppen zu erweitern, die mit verschiedenen Clustertypen konfiguriert sind. Diese Methode wird auf den verschiedenen Betriebssystemplattformen unterstützt.

Alle Varianten von Verfügbarkeitsgruppen für die Migration und Upgrades ermöglichen die Datensynchronisierung, die den aufwendigsten Teil der Arbeit darstellt. Wenn es an der Zeit ist, den Wechsel zur neuen Konfiguration zu initiieren, ist der Übernahme ein kurzer Ausfall im Vergleich zu einer langen Ausfallzeit, bei der alle Arbeiten, einschließlich der Datensynchronisierung, abgeschlossen werden müssen.

Verfügbarkeitsgruppen können eine minimale Downtime während des Patchens des zugrunde liegenden Betriebssystems bereitstellen, indem manuell ein Failover vom primären zu einem sekundären Replikat ausgeführt wird, während der Patchvorgang abgeschlossen wird. Aus Sicht des Betriebssystems wäre dies häufiger unter Windows Server, da häufig, aber nicht immer, die Wartung des zugrunde liegenden Betriebssystems einen Neustart erfordert. Das Patchen von Linux erfordert manchmal einen Neustart, dies ist jedoch selten der Fall.

Das Patchen von SQL Server-Instanzen, die in einer Verfügbarkeitsgruppe enthalten sind, kann abhängig von der Architektur der Verfügbarkeitsgruppe ebenfalls die Downtime minimieren. Bevor die Server gepatcht werden, die in einer Verfügbarkeitsgruppe enthalten sind, wird zunächst das sekundäre Replikat gepatcht. Sobald die richtige Anzahl von Replikaten gepatcht wurde, wird ein manuelles Failover des primären Replikats auf einen anderen Knoten ausgeführt, um das Upgrade durchzuführen. Alle zu diesem Zeitpunkt verbleibenden sekundären Replikate können ebenfalls aktualisiert werden.

Failoverclusterinstanzen

FCIs allein können traditionelle Migrationsvorgänge und Upgrades nicht unterstützen. Eine Verfügbarkeitsgruppe oder ein Protokollversand muss für die Datenbanken im FCI und alle anderen zu berücksichtigenden Objekte konfiguriert werden. FCIs unter Windows Server sind jedoch weiterhin eine beliebte Option, wenn die zugrunde liegenden Windows-Server gepatcht werden müssen. Ein manuelles Failover kann initiiert werden, was einen kurzen Ausfall bedeutet, statt dass die Instanz für die gesamte Zeit nicht verfügbar ist, in der Windows Server gepatcht wird. Für eine FCI kann ein Upgrade auf höhere Versionen von SQL Server durchgeführt werden. Weitere Informationen finden Sie unter Upgrade einer Failoverclusterinstanz.

Protokollversand

Der Protokollversand ist immer noch eine beliebte Option zum Migrieren und Aktualisieren von Datenbanken. Ähnlich wie bei Verfügbarkeitsgruppen kann die Datenweitergabe vor dem Serverwechsel gestartet werden, dieses Mal wird jedoch das Transaktionsprotokoll als Synchronisierungsmethode verwendet. Zum Zweitpunkt des Wechsels, wenn der gesamte Datenverkehr an der Quelle beendet wurde, muss ein letztes Transaktionsprotokoll ausgeführt, kopiert und auf die neue Konfiguration angewendet werden. An diesem Punkt kann die Datenbank online geschaltet werden. Der Protokollversand ist oft toleranter von langsameren Netzwerken, und während der Switch etwas länger sein kann als bei der Verwendung einer AG oder einer verteilten AG, wird er in der Regel in Minuten, nicht in Stunden, Tagen oder Wochen gemessen.

Ähnlich wie bei Verfügbarkeitsgruppen kann der Protokollversand eine Möglichkeit bereitstellen, um während des Patchens auf einen anderen Server zu wechseln.

Andere SQL Server-Bereitstellungsmethoden und Verfügbarkeit

Es gibt zwei Bereitstellungsmethoden für SQL Server unter Linux: Container und das Verwenden von Azure (oder einem anderen öffentlichen Cloudanbieter). Die allgemeine Notwendigkeit der Verfügbarkeit, die in diesem Dokument erläutert wird, besteht unabhängig von der Bereitstellungsmethode von SQL Server. Beide Methoden weisen Besonderheiten auf, wenn SQL Server hoch verfügbar gemacht werden soll.

SQL Server-Container und Optionen für Hochverfügbarkeit/Notfallwiederherstellung

Die SQL Server-Containerbereitstellung ist eine neue Möglichkeit, SQL Server für Linux bereitzustellen. Ein Container ist ein vollständiges Image von SQL Server, das für die Ausführung bereit ist.

Abhängig von der verwendeten Containerplattform, z. B. bei Verwendung eines Containerorchestrators wie Kubernetes, kann der Container bei einem Verlust erneut bereitgestellt und an den freigegebenen Speicher angefügt werden, der verwendet wurde. Dies bietet zwar eine gewisse Resilienz, aber es gibt einige Ausfallzeiten, die mit der Datenbankwiederherstellung verbunden sind, und ist nicht wirklich hoch verfügbar, da dies bei Verwendung einer Verfügbarkeitsgruppe oder einer FCI der Fall wäre.

Wenn Sie Hochverfügbarkeit für SQL Server-Container konfigurieren möchten, die auf Kubernetes- oder anderen Plattformen bereitgestellt werden, können Sie DH2i DxEnterprise als eine der Clusterlösungen verwenden, für die Sie eine Verfügbarkeitsgruppe im Hochverfügbarkeitsmodus konfigurieren können. Diese Option bietet ein Recovery Point Objective (RPO) und ein Recovery Time Objective (RTO), das von einer Hochverfügbarkeitslösung erwartet wird.

Linux-basierte IaaS-Bereitstellung

Virtuelle IaaS-Computer mit Linux können mithilfe von Azure mit einer Installation von SQL Server bereitgestellt werden. Wie bei lokalen Installationen erfordert eine unterstützte Installation die Verwendung des Fencings eines fehlgeschlagenen Knotens, der sich außerhalb des Cluster-Agents selbst befindet. Knoten-Fencing wird über Fencing-Verfügbarkeits-Agents bereitgestellt. In einigen Verteilungen sind diese als Teil der Plattform enthalten, während andere auf externen Hardware- und Softwareanbietern basieren. Wenden Sie sich an Ihre bevorzugte Linux-Verteilung, um zu sehen, welche Formen von Knoten-Fencing bereitgestellt werden, damit eine unterstützte Lösung in der öffentlichen Cloud bereitgestellt werden kann.

Leitfäden zum Installieren von SQL Server für Linux sind für die folgenden Distributionen verfügbar:

• Schnellstart: Installieren von SQL Server und Erstellen einer Datenbank unter Red Hat
• Schnellstart: Installieren von SQL Server und Erstellen einer Datenbank unter Ubuntu
• Schnellstart: Installieren von SQL Server und Erstellen einer Datenbank unter SUSE Linux Enterprise Server

Lesemaßstab

Sekundäre Replikate können für schreibgeschützte Abfragen verwendet werden. Es gibt zwei Möglichkeiten, wie dies mit einer Verfügbarkeitsgruppe erzielt werden kann: indem direkter Zugriff auf das sekundäre Replikat gewährt wird und indem das schreibgeschützte Routing konfiguriert wird, wofür die Verwendung eines Listeners erforderlich ist. In SQL Server 2016 (13.x) wurde die Möglichkeit eingeführt, einen Lastenausgleich für schreibgeschützte Verbindungen über den Listener vorzunehmen, für den ein Roundrobin-Algorithmus verwendet wird. Dadurch können schreibgeschützte Anforderungen auf alle lesbaren Replikate verteilt werden.

Die Skalierung von lesbaren Kopien einer Datenbank über Verfügbarkeitsgruppen wurde erstmals mit den verteilten Verfügbarkeitsgruppen in SQL Server 2016 (13.x) eingeführt. Dadurch können Unternehmen schreibgeschützte Kopien der Datenbank nicht nur lokal besitzen, sondern auch regional und global mit minimalem Konfigurationsaufwand. Außerdem werden durch lokal ausgeführte Abfragen der Netzwerkdatenverkehr und die Latenz reduziert. Jedes primäre Replikat einer Verfügbarkeitsgruppe kann für zwei andere Verfügbarkeitsgruppen ein Seeding ausführen, selbst wenn es sich nicht um eine vollständige Lese-/Schreibkopie handelt. Somit kann jede verteilte Verfügbarkeitsgruppe bis zu 27 lesbare Kopien von Daten unterstützen.

In SQL Server 2017 (14.x) und höheren Versionen können Sie eine nahezu in Echtzeit verfügbare Lösung mit AGs erstellen, die mit einem Clustertyp "None" konfiguriert sind. Wenn es das Ziel ist, Verfügbarkeitsgruppen für lesbare sekundäre Replikate und nicht für die Verfügbarkeit zu verwenden, wird dadurch die Komplexität der Verwendung eines WSFC oder einer externen Clusterlösung und Linux beseitigt, außerdem erhalten die lesbaren Replikate die Vorteile einer Verfügbarkeitsgruppe mit einer einfacheren Bereitstellungsmethode.

Dabei muss allerdings berücksichtigt werden, dass kein Cluster mit dem Clustertyp „Keiner“ vorhanden ist und die Konfiguration des schreibgeschützten Routings sich dadurch geringfügig unterscheidet. Aus der Sicht von SQL Server ist immer noch ein Listener erforderlich, um die Anforderungen weiterzuleiten, obwohl kein Cluster vorhanden ist. Anstatt einen traditionellen Listener zu konfigurieren, wird die IP-Adresse oder der Name des primären Replikats verwendet. Das primäre Replikat wird dann verwendet, um die schreibgeschützten Anforderungen weiterzuleiten.

Ein warmer Standbymodus für den Protokollversand kann technisch für die lesbare Verwendung konfiguriert werden, indem die Datenbank WITH STANDBYwiederhergestellt wird. Da die Transaktionsprotokolle jedoch die exklusive Verwendung der Datenbank für die Wiederherstellung benötigen, können Benutzer*innen währenddessen nicht auf die Datenbank zugreifen. Dadurch ist der Protokollversand keine ideale Lösung, besonders wenn Daten nahezu in Echtzeit erforderlich sind.

Bei allen Szenarien für die Leseskalierung mit Verfügbarkeitsgruppen sollte beachtet werden, dass anders als bei der Transaktionsreplikation, bei der Livedaten verwendet werden, die sekundären Replikate sich nicht in einem Zustand befinden, in dem eindeutige Indizes angewandt werden können und das Replikat eine exakte Kopie des primären Replikats ist. Wenn Indizes für berichte oder Daten bearbeitet werden müssen, müssen sie in den Datenbanken des primären Replikats erstellt werden. Wenn Sie Flexibilität benötigen, ist die Replikation die bessere Lösung für lesbare Daten.

Interoperabilität – plattformübergreifend und für Linux-Verteilungen

Da SQL Server nun für Windows Server und Linux unterstützt wird, werden in diesem Abschnitt Szenarios zu deren Zusammenarbeit u. a. für die Verfügbarkeit beschrieben sowie Lösungen zur Integration mehrerer Linux-Distributionen.

Verteilte Verfügbarkeitsgruppen

Verteilte Verfügbarkeitsgruppen wurden dafür entwickelt, mehrere Konfigurationen für Verfügbarkeitsgruppen zu umfassen, unabhängig davon, ob die zwei zugrunde liegenden Cluster der Verfügbarkeitsgruppen zwei verschiedene WSFCs oder Linux-Distributionen sind oder ob einer sich auf einem WSFC und der andere unter Linux befindet. Eine verteilte Verfügbarkeitsgruppe ist die primäre Methode für plattformübergreifende Lösungen. Eine verteilte Verfügbarkeitsgruppe ist außerdem die primäre Lösung für Migrationsvorgänge, z. B. für das Konvertieren von einer Windows Server-basierten SQL Server-Infrastruktur zu einer Linux-basierten, wenn Ihr Unternehmen dies durchführen möchte. Wie bereits erwähnt minimieren Verfügbarkeitsgruppen, insbesondere verteilte Verfügbarkeitsgruppen, die Zeit, die eine Anwendung nicht für die Verwendung verfügbar ist. Ein Beispiel für eine verteilte AG, die einen WSFC und Pacemaker umfasst, ist im folgenden Diagramm dargestellt:

Wurde eine Verfügbarkeitsgruppe mit dem Clustertyp „Keiner“ konfiguriert, kann sie Windows Server und Linux umfassen und auch mehrere Linux-Distributionen. Da es sich dabei nicht um eine echte Konfiguration für Hochverfügbarkeit handelt, sollte sie nicht für unternehmenskritische Bereitstellungen verwendet werden, sondern nur in Szenarien mit Leseskalierung oder in Migrations- und Upgradeszenarien.

Protokollversand

Da der Protokollversand auf Sicherung und Wiederherstellung basiert, gibt es zwischen SQL Server unter Windows Server und unter Linux keine Unterschiede bezüglich Datenbanken, Dateistrukturen usw. Dies bedeutet, dass der Protokollversand zwischen einer Windows Server-basierten und einer Linux-basierten Installation von SQL Server sowie zwischen Linux-Distributionen konfiguriert werden kann. Alles andere bleibt unverändert. Es muss allerdings berücksichtigt werden, dass der Protokollversand genau wie eine Verfügbarkeitsgruppe nicht funktioniert, wenn die Quelle sich auf einer höheren Hauptversion von SQL Server befindet als das Ziel.

Zusammenfassung

Instanzen und Datenbanken ab SQL Server 2017 (14.x) können hoch verfügbar gemacht werden, indem die gleichen Features unter Windows Server und Linux verwendet werden. Neben den Standardszenarios für die lokale Hochverfügbarkeit und die Verfügbarkeit der Notfallwiederherstellung kann die Ausfallzeit bei Upgrades und Migrationen durch die Verfügbarkeitsfunktionen in SQL Server minimiert werden. Verfügbarkeitsgruppen können ebenfalls zusätzliche Kopien einer Datenbank als Teil derselben Architektur bereitstellen, um schreibgeschützte Kopien aufzuskalieren. Ob Sie eine neue Lösung bereitstellen möchten oder ein Upgrade erwägen: SQL Server bietet Ihnen die Verfügbarkeit und Zuverlässigkeit, die Sie benötigen.

Verwandte Inhalte

• Was ist eine Always On-Verfügbarkeitsgruppe?
• SQL Server-Failoverclusterinstallation