Geschäftskontinuität und Datenbankwiederherstellung – SQL Server für Linux

Gilt für: SQL Server

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:

• Neues in SQL Server 2017
• Neuigkeiten zu SQL Server 2017 für Linux
• Neuigkeiten zu SQL Server 2019
• Neues in SQL Server 2019 unter Linux
• Neuerungen 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.

Ab SQL Server 2022 (16.x) können Sie Metadatenobjekte wie Benutzer*innen, Anmeldungen, Berechtigungen und SQL Server-Agent Aufträge zusätzlich zur Instanzebene auch auf Gruppenebene verwalten. Weitere Informationen finden Sie unter Enthaltene Verfügbarkeitsgruppen.

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. Die folgende Abbildung zeigt eine Windows Server-basierte Verfügbarkeitsgruppe, die einen Windows Server-Failovercluster (WSFC) verwendet. Ein zugrunde liegender Cluster auf OS-Ebene ist für die Verfügbarkeit auf Linux oder Windows Server erforderlich. 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 bei Verfügbarkeitsgruppen zwischen Windows Server und Linux beschrieben:

• 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 allgemeine Name, der von jedem Listener verwendet wird, im DNS und nicht wie unter Windows Server im Cluster definiert.

Ab SQL Server 2017 (14.x) sind für Verfügbarkeitsgruppen einige neue Features und Erweiterungen verfügbar:

• Clustertypen
• REQUIRED_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 Schreibgeschützte Verfügbarkeitsgruppen.

Der folgende Screenshot zeigt die Unterstützung für die verschiedenen 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. Ab SQL Server 2017 (14.x) können Sie mit REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT steuern, was geschieht, wenn synchrone Replikate vorhanden sind. 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 Failoververhalten aus, da kein automatisches Failover ausgeführt werden kann, wenn sich nicht die erforderliche Anzahl von sekundären Replikaten in einem korrekten 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. In der folgenden Abbildung besitzt der erste Knoten des Clusters die FCI. Das bedeutet, dass dieser auch die freigegebenen Speicherressourcen besitzt, die ihm zugewiesen sind. Dies ist durch die durchgezogene Linie zum Speicher gekennzeichnet.

Wie in der folgenden Abbildung dargestellt ändert sich der Besitz nach einem Failover.

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 Nachteil besteht darin, dass beim Ausführen eines Failovers für eine Verfügbarkeitsgruppe zusätzliche Aufgaben erforderlich sein können, damit die Datenbank verwendet werden kann, 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.

Die folgende Liste hebt einige Unterschiede von FCIs zwischen Windows Server und Linux hervor:

• 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 jemand also z.B. ein Update ohne eine WHERE-Klausel ausführt, verfügt die Standbyinstanz dadurch nicht über die Änderung, sodass Sie zu dieser wechseln können, während Sie das primäre System reparieren. 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. Nachfolgend finden Sie ein Beispiel für eine Verfügbarkeitsgruppe, die auf mehrere Rechenzentren verteilt ist. 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 Verfügbarkeitsgruppen und FCIs verwendet, um eine kosteneffektive und einfachere Notfallwiederherstellung bereitzustellen, wenn die Umsetzung anderer Optionen aufgrund der Umgebung, administrativer Anforderungen oder des Budgets schwierig ist. Ä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ügbarkeitsfunktionen von SQL Server verwendet werden können, um die Ausfallzeit bei einem geplanten Architekturwechsel, einem Serverwechsel, einer Plattformänderung (z.B. Windows Server zu Linux oder umgekehrt) oder während des Patchens 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 gewisse Ausfallzeiten, die jedoch durch die richtige Planung minimiert werden können.

Wenn es das Ziel ist, zu neuen Servern zu migrieren, ohne die Konfiguration zu ändern (einschließlich des Betriebssystems oder der SQL Server-Version), können diese Server als Knoten dem vorhandenen zugrunde liegenden Cluster und der Verfügbarkeitsgruppe 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 der Wechsel zur neuen Konfiguration initiiert werden soll, verursacht die Umstellung einen kurzen Ausfall im Gegensatz zu einer langen Ausfallzeit, in der die gesamte Arbeit, einschließlich der Datensynchronisierung, abgeschlossen werden muss.

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 der Sicht des Betriebssystems wird dieser Vorgang unter Windows Server häufiger ausgeführt, da die Wartung des zugrunde liegenden Betriebssystems oft, aber nicht immer, 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 Aktualisieren einer SQL Server-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 häufig toleranter gegenüber langsameren Netzwerken. Während der Wechsel etwas länger als beim Verwenden einer Verfügbarkeitsgruppe oder einer verteilten Verfügbarkeitsgruppe dauern kann, wird dieser üblicherweise in Minuten gemessen, nicht in Stunden, Tagen oder Wochen.

Ä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. Obwohl dadurch Resilienz bereitgestellt wird, kann es zu Downtime im Zusammenhang mit der Datenbankwiederherstellung kommen, und Hochverfügbarkeit wird nicht genauso wie bei Verwendung einer Verfügbarkeitsgruppe oder FCI gewährleistet.

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. Bei lokalen Installationen erfordert eine unterstützte Installation die Verwendung von STONITH (Shoot the Other Node in the Head), das sich außerhalb des Cluster-Agent befindet. STONITH wird über Agents für das Umgrenzen der Verfügbarkeit bereitgestellt. In einigen Verteilungen sind diese als Teil der Plattform enthalten, während andere auf externen Hardware- und Softwareanbietern basieren. Überprüfen Sie für Ihre bevorzugte Linux-Verteilung, um festzustellen, welche Arten von STONITH 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

: Leseskalierung

Seit sekundäre Replikate in SQL Server 2012 (11.x) eingeführt wurden, können diese 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.

Ab SQL Server 2017 (14.x) ist es möglich, eine schreibgeschützte Lösung mit Verfügbarkeitsgruppen mit dem Clustertyp „Keiner“ in Quasi-Echtzeit zu erstellen. 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 betriebsbereiter Protokollversand kann technisch gesehen für die Lesbarkeit konfiguriert werden, indem die Datenbank mit der WITH STANDBY-Klausel wiederherstellen. 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 also die erforderlichen Indizes für die Berichterstellung oder die Daten bearbeitet werden müssen, bedeutet das, dass dies in den Datenbanken auf dem primären Replikat erfolgen muss. 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. Im Folgenden wird ein Beispiel für eine verteilte Verfügbarkeitsgruppe dargestellt, die einen WSFC und Pacemaker umfasst.

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.

Zugehöriger Inhalt

• Konfigurieren von SQL Server-Always On-Verfügbarkeitsgruppen für Hochverfügbarkeit unter Linux
• Failover der Always On-Verfügbarkeitsgruppe unter Linux