Einsatzmuster für zwei Multizonenbereiche

IBM Cloud Windows Server 2019 Standard virtuelle Server, die als Windows Server Failover Cluster (WSFC)-Knoten konfiguriert sind, und SQL Server Enterprise Edition mit SQL Server Always On-Verfügbarkeitsgruppen, die auf jedem Knoten konfiguriert sind, bilden die Grundlage des dualen Bereitstellungsmusters Multi-Zone Region (MZR). Diese Architektur bietet zusammen mit MS ADDNS eine SQL Server für die Notfallwiederherstellung.

Das gezeigte duale MZR-Bereitstellungsmuster nutzt das duale Availability Zone (AZ)-Muster und erweitert es so, dass eine Kopie der Datenbanken in einer entfernten Region vorhanden ist. Daher eignet sich dieses Muster für Produktionsdatenbanken, die eine Notfallwiederherstellung erfordern, und nutzt die folgenden Kerntechnologien:

Eine IBM Cloud VPC mit Subnetzen in zwei MZRs.
Sicherheitsgruppen werden verwendet, um den Datenverkehr zwischen den Komponenten zu kontrollieren.
Ein oder mehrere Bastion-Hosts, die für den administrativen Zugang zu den Servern verwendet werden.
Floating IP (FIP), das an die Bastion-Hosts angeschlossen ist, um den Internetzugang zu ermöglichen.
Drei virtuelle Server mit Windows Server 2019 Standard, einer in jedem AZ im primären MZR und ein dritter im Wiederherstellungs-MZR, die Active Directory in derselben Forest-Domäne sind.
Drei virtuelle Windows Server 2019 Standard-Server, einer in jedem AZ im primären MZR und ein dritter im Recovery-MZR, die zu Windows Server Failover Cluster (WSFC)-Knoten werden.
Always On-Verfügbarkeitsgruppen bieten die Möglichkeit, eine diskrete Gruppe von Datenbanken über einen oder mehrere Clusterknoten hochverfügbar zu halten und arbeiten auf Datenbankebene. Verfügbarkeitsgruppen bestehen aus einem primären Replikat und bis zu maximal acht sekundären Replikaten und verwenden synchrone oder asynchrone Datenreplikation. Bei diesem Einsatz:
- synchrone Replikation zwischen den beiden AZs im primären MZR verwendet.
- die asynchrone Replikation zwischen den MZRs verwendet wird.
Distributed Network Names ist eine Namensressource in WSFC- und Always On-Verfügbarkeitsgruppen, die für die Namensauflösung der Clusterressourcen verwendet wird.

Ein Dateifreigabe-Zeuge ist bei dieser Bereitstellung nicht erforderlich, da eine ungerade Anzahl von Knoten vorhanden ist und der Quorum-Modus Node " verwendet wird

Windows Server Failover Cluster

Die Bereitstellung von Always On-Verfügbarkeitsgruppen für HA unter Windows erfordert einen Windows Server Failover Cluster (WSFC). Jede Verfügbarkeitsreplik einer Verfügbarkeitsgruppe muss sich auf einem anderen Knoten der WSFC befinden. Um die Sicherheitskonfiguration für die Verfügbarkeitsdatenbanken zu vereinfachen, wird empfohlen, dass die SQL-Server-Instanzen (die Dienstkonten) unter einem Domänendienstkonto laufen.

Windows Server Failover Cluster (WSFC) ist eine Windows Server-Funktion und jeder Server, der als Clusterknoten fungiert, muss diese Funktion aktiviert haben. Die WSFC ist auf Quorum-Abstimmungen angewiesen, um das "Split-Brain"-Syndrom zu verhindern, und es gibt eine Reihe von Quorum-Modi:

Node- Die aktiven Clusterknoten bestimmen das Quorum. Mindestens die Hälfte der möglichen Stimmen muss auf "Ja" lauten, damit der Cluster einen gesunden Zustand erhält.
Node und Dateifreigabe-Mehrheit - Eine entfernte Dateifreigabe fungiert als Abstimmungszeuge für die aktiven Knoten, die an einer Quorum-Abstimmung beteiligt sind. Wie bei der Node muss mindestens die Hälfte der möglichen Stimmen positiv sein, damit der Cluster einen gesunden Zustand beibehält.
Node und Festplattenmehrheit - Eine gemeinsam genutzte Festplatte fungiert zusammen mit den aktiven Knoten, die an einer Quorum-Abstimmung beteiligt sind, als Abstimmungszeuge.
Nur Festplatte - Eine gemeinsam genutzte Festplatte fungiert als Zeuge und das Quorum wird dadurch bestimmt, welche Knoten auf die Festplatte zugreifen können. Es ist keine Mindestanzahl an möglichen Stimmen erforderlich.

Die Microsoft-Empfehlungen für SQL Server lauten wie folgt:

Verwenden Sie den Quorum-Modus Node ", wenn es eine ungerade Anzahl von stimmberechtigten Knoten gibt.
Verwenden Sie den Modus Node und Dateifreigabe-Mehrheit für das Quorum, wenn Sie eine gerade Anzahl von stimmberechtigten Knoten haben.

Immer verfügbare Verfügbarkeitsgruppen

Eine Verfügbarkeitsgruppe unterstützt einen Satz von primären Datenbanken und bis zu acht Sätze von sekundären Datenbanken. Sekundäre Datenbanken sind keine Backups, daher ist es wichtig, dass Sie die Datenbanken und ihre Transaktionsprotokolle in regelmäßigen Abständen sichern. Always On-Verfügbarkeitsgruppen erfordern eine der folgenden drei Clustertyp-Optionen: WSFC, EXTERNAL, NONE.

WSFC - Verwendet Windows Server Failover Cluster (WSFC) zur Verwaltung des Cluster-Failover. Dies ist eine Voraussetzung für Hochverfügbarkeitsgruppen auf Windows-Servern.
Extern - Verwendet einen externen Clustermanager. So unterstützt SQL Server unter Linux beispielsweise Pacemaker. Verfügbarkeitsgruppen auf Linux erfordern mindestens zwei synchrone Replikate, um HA zu gewährleisten, jedoch mindestens drei Replikate für die automatische Wiederherstellung. Es wird daher empfohlen, eine Verfügbarkeitsgruppe auf mindestens drei Knoten einzurichten.
Keine - Bekannt als clusterlose Verfügbarkeitsgruppen oder wurde ursprünglich als Read-Scale-Verfügbarkeitsgruppe bezeichnet. Diese Option bietet jedoch nur eine Teilmenge der Funktionen von Verfügbarkeitsgruppen und umfasst keine automatische Ausfallsicherung. Die Funktionen umfassen manuelles geplantes und erzwungenes Failover sowie synchrone und asynchrone Replikationsmodi, lesbare sekundäre Knoten und sekundäre Replikationssicherungen. Verfügbarkeitsgruppen ohne WSFC-Cluster können dennoch lesbare sekundäre Knoten, Read-Only-Routing und Lastausgleich bieten. Die Ausfallsicherung kann mit externen Tools automatisiert werden. Eine neue Funktion von SQL Server 2019 entschärft dieses Problem mit der automatischen Datenverkehrsumleitung, die für die Rückleitung des Lese-/Schreibverkehrs zum primären Knoten sorgt und keinen Listener erfordert.

Die folgende Terminologie wird zur Beschreibung von Verfügbarkeitsgruppenkonzepten verwendet:

Verfügbarkeitsgruppe - unterstützt eine replizierte Umgebung für eine diskrete Gruppe von Benutzerdatenbanken.
HA-Verfügbarkeitsgruppe - eine Gruppe von Datenbanken, die gemeinsam Failover betreiben.
Read-Scale-Verfügbarkeitsgruppe - eine Gruppe von Datenbanken, die auf andere Instanzen von SQL Server kopiert werden, um eine reine Lese-Arbeitslast zu ermöglichen.
Primäres Replikat - stellt die primären Datenbanken für Lese- und Schreibverbindungen von Clients zur Verfügung und sendet Transaktionsprotokollsätze jeder primären Datenbank an jede sekundäre Datenbank.
Sekundäres Replikat - bis zu acht sekundäre Replikate, von denen jedes eine Reihe von sekundären Datenbanken hostet und als potenzielle Failover-Ziele für die HA-Verfügbarkeitsgruppe dient.

Synchronisierungsmodi

Sekundäre Replikate von Verfügbarkeitsgruppen können mit einem der folgenden Synchronisierungsmodi konfiguriert werden:

Synchron - Das Protokoll wird auf jedem sekundären Replikat gehärtet (die Transaktionen werden in das Transaktionsprotokoll übertragen), bevor die Transaktion auf dem primären Replikat übertragen wird. Dies garantiert, dass es zu keinem Datenverlust kommt, was sich jedoch bei einer hohen Transaktionslast und hohen Netzwerklatenz auf die Leistung auswirken kann. Sie können zwei Synchron-Commit-Replikate pro AG haben. Dieser Modus ist am besten für Instanzen im gleichen AZ oder MZR geeignet.
Asynchron - Die Transaktion gilt als bestätigt, sobald sie im Transaktionsprotokoll auf dem primären Replikat gehärtet ist. Wenn ein Problem auftritt, bevor die Protokolle auf allen sekundären Replikaten gehärtet sind, ist ein Datenverlust möglich, und der Wiederherstellungspunkt wäre die letzte Transaktion, die auf allen sekundären Replikaten erfolgreich war. Dieser Modus eignet sich besser für Instanzen in verschiedenen MZRs oder zwischen einem AZ und On-Premise.

Failover-Modi

Wenn eine Verfügbarkeitsgruppe ausfällt, wird ein sekundäres Replikat zum neuen primären Replikat, und das primäre Replikat wird, falls verfügbar, zu einem sekundären Replikat.

Automatisches Failover - Automatisches Failover bietet HA und hängt von ordnungsgemäß konfigurierten Listener- und WSFC-Objekten ab, um erfolgreich zu sein. Nur ein Replikat im Verfügbarkeitsmodus Synchronous-Commit kann das Ziel eines automatischen Failover sein. Sie können die Bedingungen, die ein automatisches Failover auslösen, auf einer Skala von 1 bis 5 konfigurieren, wobei 1 angibt, dass nur ein vollständiger Ausfall des SQL Server auf der primären Replikation ein Failover auslösen würde, und 5 eine Reihe von kritischen bis weniger schwerwiegenden SQL Server anzeigt. Der Standardwert ist 3, was im Falle eines Ausfalls oder einer nicht reagierenden primären Replikation, aber auch bei einigen kritischen Serverzuständen zu einem automatischen Ausfall führt. Diese Bedingungen der "flexiblen Failover-Richtlinie" werden unter Konfigurieren einer flexiblen automatischen Failover-Richtlinie für eine Always On-Verfügbarkeitsgruppe beschrieben.
Geplantes Failover - Ein geplantes Failover kann nur erfolgen, wenn kein Datenverlust droht. Konkret bedeutet dies, dass der Failover ohne Verwendung des FORCE-Parameters zur Bestätigung von Warnungen im Code oder in den SSMS-Dialogfeldern erfolgt. Ein geplanter Failover auf ein sekundäres Replikat ist nur im Verfügbarkeitsmodus synchronouscommit möglich. Sie können ein Replikat im Verfügbarkeitsmodus "Asynchronous-Commit" in den Modus "Synchronous" verschieben, den Status "SYNCHRONIZED" abwarten und dann einen geplanten Failover ohne Datenverlust durchführen. Geplante Failover sollten immer über SSMS, T-SQL oder PowerShell initiiert werden.
Erzwungener Failover - Ein manuell initiierter, erzwungener Failover sollte nur als Reaktion auf ungünstige Cluster-Bedingungen wie den Ausfall des primären Knotens initiiert werden. Starten Sie von SSMS-Assistenten, T-SQL-Befehlen oder PowerShell aus und nur als letzten Ausweg vom Windows Server Failover Cluster Manager.
Failover erzwingen, wenn WSFC-Quorum ausgefallen ist - Sie können kein Failover für Verfügbarkeitsgruppen erzwingen, die auf einer WSFC basieren, wenn die WSFC kein Quorum hat. Sie müssen zunächst die Beschlussfähigkeit im Konfigurationsmanager erzwingen, indem Sie die Abstimmung "manipulieren" und die Knotengewichte ändern. Sie sollten diesen Schritt nur in Notfällen in Erwägung ziehen, z. B. wenn eine Katastrophe die Mehrheit der Clusterknoten gestört hat. Dies kann mit einem PowerShell erreicht werden, um einen Online-Knoten zu zwingen, die primäre Rolle zu übernehmen, ohne dass eine Mehrheit der Stimmen vorliegt.

Failover werden nicht durch Datenbankprobleme verursacht, z. B. wenn eine Datenbank durch den Verlust einer Datendatei oder die Beschädigung eines Transaktionsprotokolls verdächtig wird.

Andere Arten von Verfügbarkeitsgruppen

Die folgenden Verfügbarkeitsgruppen werden in diesem Bereitstellungsmuster nicht verwendet, können aber für Lösungsanbieter, die dieses Bereitstellungsmuster anpassen oder erweitern wollen, von Interesse sein:

Einfache Verfügbarkeitsgruppen - Eine eingeschränkte Version von Verfügbarkeitsgruppen, die nur von der SQL Server Standard Edition unterstützt wird. Das einzelne sekundäre Replikat kann nicht gelesen oder gesichert werden, und jede Basisverfügbarkeitsgruppe kann nur zwei Replikate unterstützen, es können jedoch mehrere Basisverfügbarkeitsgruppen pro Server konfiguriert werden. Einfache Verfügbarkeitsgruppen bieten viele der gleichen Funktionen wie Verfügbarkeitsgruppen, einschließlich synchroner oder asynchroner Replikation, manueller oder automatischer Failover.
Verteilte Verfügbarkeitsgruppen - Dies ermöglicht einer Verfügbarkeitsgruppe, eine andere Verfügbarkeitsgruppe als sekundäres Replikat zu behandeln. Die sekundären Replikate mit Lesezugriff können global verteilt werden, um Arbeitslasten auf regionale sekundäre Replikate mit Lesezugriff zu verlagern. Die beiden Verfügbarkeitsgruppen, jede mit ihrem eigenen Listener, müssen sich nicht im selben Netz oder in derselben WSFC befinden. Dies ermöglicht eine geografisch entfernte HA und DR über mehrere Standorte hinweg. Bei verteilten Verfügbarkeitsgruppen muss sich eine WSFC nicht über Regionen erstrecken. Es gibt keine automatische Ausfallsicherung zwischen der primären und der sekundären Verfügbarkeitsgruppe. Die Verfügbarkeitsgruppe, die nicht primär ist, kann nur schreibgeschützte Abfragen bedienen, hat aber selbst ein primäres Replikat. Das primäre Replikat in der sekundären Verfügbarkeitsgruppe ist mit der Replikation von Transaktionen an die anderen sekundären Replikate in der sekundären Verfügbarkeitsgruppe beauftragt. Diese Architektur ist nützlich für Betriebssystem- und SQL Server, da Sie in jeder Verfügbarkeitsgruppe verschiedene Versionen von Windows Server haben können. Obwohl jede Verfügbarkeitsgruppe in einem verteilten Szenario über einen eigenen Listener verfügt, gilt dies nicht für die verteilte Verfügbarkeitsgruppe als Ganzes. Die Anwendungen werden sich nach einem Failover direkt mit jeder Verfügbarkeitsgruppe verbinden, vielleicht mit Hilfe von DNS-Aliasnamen, um die Vorteile der lesbaren sekundären Replikate zu nutzen.

Verteilte Netzwerknamen

Diese Bereitstellung verwendet Distributed Network Names (DNN), eine Namensressource in WSFC- und Always On-Verfügbarkeitsgruppen, die für die Namensauflösung der Clusterressourcen verwendet wird. Sie unterscheidet sich von einer Standard-Netznamensressource, weil sie keine von den IP-Adressen der Knoten getrennte IP-Adresse benötigt und bei einem Failover nicht das Gratuitous Address Resolution Protocol (GARP) im Netz verwendet werden muss. In Windows Server 2019 können sowohl der Name der WSFC, der auch das Cluster Name Object (CNO) in Active Directory Domain Services ist, als auch der Datenbank-Listener mit DNNs erstellt werden.