Erkunden von Hochverfügbarkeits- und Notfallwiederherstellungsoptionen

15 Minuten

Um sich eine Lösung für virtuelle Computer (VMs) vorstellen zu können, müssen Sie zunächst die Verfügbarkeitsoptionen für IaaS-basierte Bereitstellungen verstehen.

Infrastructure-as-a-Service im Vergleich zu Platform-as-a-Service

Wenn es um die Verfügbarkeit geht, macht die Wahl von IaaS oder PaaS einen Unterschied. Bei IaaS haben Sie einen virtuellen Computer, was bedeutet, dass es ein Betriebssystem mit einer Installation von SQL Server gibt. Dem Administrator oder der Gruppe, der/die für SQL Server verantwortlich ist, stünde eine Auswahl an Hochverfügbarkeits- und Nofallwiederherstellungslösungen (HADR) sowie ein hohes Maß an Kontrolle darüber zur Verfügung, wie diese Lösung konfiguriert wird.

Bei PaaS-basierten Bereitstellungen wie Azure SQL-Datenbank sind die HADR-Lösungen in die Funktion integriert und müssen häufig nur aktiviert werden. Es gibt minimale Optionen, die konfiguriert werden können.

Aufgrund dieser Unterschiede kann die Auswahl von IaaS oder PaaS das endgültige Design Ihrer HADR-Lösung beeinflussen.

HADR-Funktionen von SQL Server für Azure Virtual Machines

Bei Verwendung von IaaS können Sie die von SQL Server bereitgestellten Funktionen nutzen, um die Verfügbarkeit zu erhöhen. In einigen Fällen können sie mit Funktionen auf Azure-Ebene kombiniert werden, um die Verfügbarkeit noch weiter zu erhöhen.

Die in SQL Server verfügbaren Funktionen sind in der folgenden Tabelle aufgeführt

Funktionsname	Schutz von
Always On-Failoverclusterinstanz (FCI)	Instanz
Always On-Verfügbarkeitsgruppe (VG)	Datenbank
Protokollversand	Datenbank

Eine Instanz von SQL Server ist die gesamte Installation von SQL Server (Binärdateien, alle Objekte innerhalb der Instanz, einschließlich Dingen wie Anmeldungen, SQL Server-Agent-Aufträgen und Datenbanken). Schutz auf Instanzebene bedeutet, dass die gesamte Instanz in der Verfügbarkeitsfunktion berücksichtigt wird.

Eine Datenbank in SQL Server enthält die Daten, die Endbenutzer und Anwendungen verwenden. Es gibt Systemdatenbanken, auf denen SQL Server basiert, sowie Datenbanken, die für die Verwendung durch Endbenutzer und Anwendungen erstellt werden. Eine Instanz von SQL Server besitzt immer ihre eigenen Systemdatenbanken. Schutz auf Datenbankebene bedeutet, dass alles, was sich in der Datenbank befindet oder im Transaktionsprotokoll für eine Benutzer- oder Anwendungsdatenbank aufgezeichnet wird, als Teil der Verfügbarkeitsfunktion berücksichtigt wird. Alles, was sich außerhalb der Datenbank befindet oder nicht als Teil des Transaktionsprotokolls erfasst wird, wie SQL Server-Agent-Aufträge und Verbindungsserver, muss manuell behandelt werden, um sicherzustellen, dass der Zielserver im Falle eines geplanten oder ungeplanten Failover-Ereignisses wie das primäre Replikat funktionieren kann.

Sowohl FCIs als auch Verfügbarkeitsgruppen benötigen einen zugrunde liegenden Clustermechanismus. Für SQL Server-Bereitstellungen, die auf Windows Server ausgeführt werden, ist es ein Windows Server-Failovercluster (WSFC) und für Linux ist es Pacemaker.

AlwaysOn-Failoverclusterinstanzen

Eine FCI wird bei der Installation von SQL Server konfiguriert. Eine eigenständige Instanz von SQL Server kann nicht in eine FCI konvertiert werden. Der FCI wird ein eindeutiger Name sowie eine IP-Adresse zugewiesen, die sich von den zugrunde liegenden Servern oder Knoten, die am Cluster teilnehmen, unterscheidet. Der Name und die IP-Adresse müssen sich auch von dem zugrunde liegenden Clustermechanismus unterscheiden. Anwendungen und Endbenutzer würden den eindeutigen Namen der FCI für den Zugriff verwenden. Diese Abstraktion ermöglicht es Anwendungen, nicht wissen zu müssen, wo die Instanz ausgeführt wird. Ein Hauptunterschied zwischen Azure-basierten FCIs gegenüber lokalen FCIs ist, dass für Azure ein interner Lastenausgleich (Internal Load Balancer, ILB) erforderlich ist. Der ILB wird verwendet, um sicherzustellen, dass Anwendungen und Endbenutzer eine Verbindung mit dem eindeutigen Namen des FCI herstellen können.

Wenn ein FCI ein Failover auf einen anderen Knoten eines Clusters ausführt, unabhängig davon, ob dies manuell initiiert wird oder aufgrund eines Problems geschieht, wird die gesamte Instanz auf einem anderen Knoten neu gestartet. Das bedeutet, dass der Failover-Prozess aus einem vollständigen Beenden und Starten von SQL Server besteht. Alle Anwendungen oder Endbenutzer, die mit dem FCI verbunden sind, werden während des Failovers getrennt und nur Anwendungen, die mit dieser Unterbrechung umgehen und sich davon wiederherstellen können, können sich automatisch wieder verbinden.

Beim Starten auf dem anderen Knoten durchläuft die Instanz den Wiederherstellungsprozess. Die FCI ist bis zum Zeitpunkt des Ausfalls konsistent, d. h. technisch gesehen gibt es keinen Datenverlust, aber bei allen Transaktionen, für die eine Zurücksetzung erforderlich ist, erfolgt diese als Teil der Wiederherstellung. Da es sich um einen Schutz auf Instanzebene handelt, ist, wie bereits zuvor erwähnt, alles Notwendige (Anmeldungen, SQL Server-Agent-Aufträge usw.) bereits vorhanden, sodass der Betrieb und das Geschäft wie gewohnt fortgesetzt werden können, sobald die Datenbanken bereit sind.

FCIs benötigen eine Kopie einer Datenbank, was aber auch ihr Single Point of Failure ist. Um sicherzustellen, dass ein anderer Knoten auf die Datenbank zugreifen kann, benötigen FCIs eine Form von freigegebenem Speicher. Bei Windows Server-basierten Architekturen kann dies über eine Azure-Premium-Dateifreigabe, iSCSI, Azure Shared Disk, Direkte Speicherplätze (S2D) oder eine unterstützte Drittanbieterlösung wie SIOS DataKeeper erreicht werden. FCIs, die die Standard Edition von SQL Server verwenden, können bis zu zwei Knoten haben. FCIs erfordern außerdem die Verwendung von Active Directory Domain Services (AD DS) und Domain Name Services (DNS), was bedeutet, dass AD DS und DNS irgendwo in Azure implementiert sein müssen, damit ein FCI funktioniert.

Mit Windows Server 2016 oder höher können FCIs mithilfe eines Speicherreplikats eine native Notfallwiederherstellungslösung für FCIs erstellen, ohne eine andere Funktion wie Protokollversand oder Verfügbarkeitsgruppen verwenden zu müssen.

Always On-Verfügbarkeitsgruppen

Verfügbarkeitsgruppen wurden in SQL Server 2012 Enterprise Edition eingeführt und sind seit SQL Server 2016 auch in der Standard Edition enthalten. In der Standard Edition kann eine Verfügbarkeitsgruppe eine Datenbank enthalten, während in der Enterprise Edition eine Verfügbarkeitsgruppe mehr als eine Datenbank enthalten kann. Während Verfügbarkeitsgruppen einige Ähnlichkeiten mit FCIs haben, unterscheiden sie sich doch in den meisten Punkten.

Der größte Unterschied zwischen einer FCI und einer Verfügbarkeitsgruppe besteht darin, dass Verfügbarkeitsgruppen Schutz auf Datenbankebene bieten. Das primäre Replikat ist die Instanz, die an einer Verfügbarkeitsgruppe teilnimmt, die die Lese-/Schreibdatenbanken enthält. Ein sekundäres Replikat ist der Ort, an den primäre Replikat Transaktionen über den Protokolltransport sendet, um es synchron zu halten. Datenverschiebungen zwischen einem primären Replikat können synchron oder asynchron sein. Die Datenbanken auf einem sekundären Replikat befinden sich in einem Ladezustand, was bedeutet, dass sie Transaktionen empfangen, aber so lange keine vollständig schreibbare Kopie sein können, bis dieses Replikat das primäre Replikat geworden ist. Eine Verfügbarkeitsgruppe in der Standard Edition kann maximal zwei Replikate haben (ein primäres, ein sekundäres), während die Enterprise Edition bis zu neun unterstützt (ein primäres, acht sekundäre). Ein sekundäres Replikat wird entweder aus einer Sicherung der Datenbank initialisiert, oder ab SQL Server 2016 können Sie eine Funktion namens „Automatisches Seeding“ verwenden. Automatisches Seeding verwendet den Protokollstreamtransport, um die Sicherung für jede Datenbank der Verfügbarkeitsgruppe unter Verwendung der konfigurierten Endpunkten an das sekundäre Replikat zu streamen.

Eine Verfügbarkeitsgruppe bietet durch den Listener Abstraktion. Der Listener funktioniert wie der eindeutige Name, der einem FCI zugewiesen ist, und besitzt einen eigenen Namen und seine eigene IP-Adresse, die sich von allen anderen (WSFC, Knoten usw.) unterscheiden. Der Listener benötigt ebenfalls einen ILB und durchläuft einen Beenden- und Startvorgang. Anwendungen und Endbenutzer können den Listener für die Verbindung verwenden, aber im Gegensatz zu einem FCI muss der Listener, falls gewünscht, nicht verwendet werden. Es können direkte Verbindungen mit der Instanz auftreten. In der Enterprise Edition können sekundäre Replikate auf Wunsch auch für schreibgeschützten Zugriff konfiguriert und für andere Funktionen wie Datenbank-Konsistenzprüfungen und Sicherungen verwendet werden.

Verfügbarkeitsgruppe können im Vergleich zu einer FCI schnellere Failover-Zeiten haben, was einer der Gründe für ihre Attraktivität ist. Während Verfügbarkeitsgruppen keinen freigegebenen Speicher benötigen, verfügt jedes Replikat über eine Kopie der Daten, was die Gesamtzahl der Kopien der Datenbank und die Gesamtkosten für Speicher erhöht. Der Speicher ist für jedes Replikat lokal. Wenn beispielsweise der Datenspeicherbedarf der Datenbanken auf dem primären Replikat 1 TB beträgt, gilt derselbe Wert auch für jedes Replikat. Wenn es fünf Replikate gibt, bedeutet dies, dass Sie 5 TB Speicherplatz benötigen.

Denken Sie daran, dass jedes Objekt, das sich außerhalb der Datenbank befindet oder nicht im Transaktionsprotokoll der Datenbank erfasst wird, manuell auf jeder anderen SQL Server-Instanz erstellt und dort berücksichtigt werden muss, falls diese Instanz das neue primäre Replikat werden muss. Beispiele für Objekte, für die Sie verantwortlich wären, sind unter anderem SQL Server-Agent-Aufträge, Anmeldungen auf Instanzebene und Verbindungsserver. Wenn Sie Windows-Authentifizierung verwenden können oder eigenständige Datenbanken mit Verfügbarkeitsgruppen verwenden, vereinfacht dies den Zugriff.

Viele Organisationen stehen vor der Herausforderung, hochverfügbare Architekturen zu implementieren, und benötigen vielleicht nur die Hochverfügbarkeit, die von der Azure-Plattform bereitgestellt wird, oder sie verwenden eine PaaS-Lösung wie Azure SQL Managed Instance. Bevor wir uns Azure-Plattformlösungen ansehen, gibt es noch eine weitere SQL Server-Funktion, die Sie kennen sollten: den Protokollversand.

Protokollversand

Den Protokollversand gibt es schon seit den frühen Tagen von SQL Server. Die Funktion basiert auf Sicherung, Kopie und Wiederherstellung und ist eine der einfachsten Methoden, um HADR für SQL Server zu erreichen. Der Protokollversand wird in erster Linie für die Notfallwiederherstellung verwendet, könnte aber auch zur Verbesserung der lokalen Verfügbarkeit eingesetzt werden.

Der Protokollversand bietet, wie Verfügbarkeitsgruppen, einen Schutz auf Datenbankebene, was bedeutet, dass Sie sich immer noch um SQL Server-Agent-Aufträge, Verbindungsserver, Anmeldungen auf Instanzebene usw. kümmern müssen. Es gibt keine Abstraktion, die vom Protokollversand nativ bereitgestellt wird, sodass ein Wechsel zu einem anderen Server, der am Protokollversand teilnimmt, eine Namensänderung tolerieren können muss. Ist dies nicht möglich, gibt es Methoden wie einen DNS-Alias, der auf Netzwerkebene konfiguriert werden kann, um zu versuchen, die Probleme mit der Namensänderung zu abzumildern.

Der Mechanismus für den Protokollversand ist einfach: Zunächst wird eine vollständige Sicherung der Quelldatenbank auf dem primären Server erstellt und dann in einem Ladezustand (STANDBY oder NORECOVERY) auf einer anderen Instanz, dem sogenannten sekundären Server oder betriebsbereiten Standbyserver, wiederhergestellt. Diese neue Kopie der Datenbank wird als sekundäre Datenbank bezeichnet. Ein in SQL Server integrierter, automatisierter Prozess sichert dann automatisch das Transaktionsprotokoll der primären Datenbank, kopiert die Sicherung auf den Standbyserver und stellt die Sicherung schließlich auf dem Standbyserver wieder her.