AlwaysOn-Verfügbarkeitsgruppen für HA und DR
Werbung
AlwaysOn-Architektur: Erstellen einer Hochverfügbarkeits- und Notfallwiederherstellungslösung unter Verwendung von AlwaysOnVerfügbarkeitsgruppen Technischer Artikel zu SQL Server Autoren: Joseph Sack (SQLskills.com), Sanjay Mishra (Microsoft) Technische Bearbeiter: Lindsey Allen (MS), Juergen Thomas (MS), Mike Weiner (MS), Prem Mehra (MS), Yorihito Tada (MS), Curt Matthews (MS), Amitabh Tamhane (MS), Aditya Samant (MS), Daniel Janik (MS), Jimmy May (MS), David P Smith (ServiceU), Richard Waymire (SolidQ), Brent Ozar (Brent Ozar PLF), Wolfgang Kutschera (bwin.party), Paul S. Randal (SQLskills.com), Gianluca Hotz (SolidQ), Ayad Shammout (Caregroup) Content Program Manager: Glenn Minch (Microsoft) Veröffentlicht: Juni 2012 Betrifft: SQL Server 2012 Zusammenfassung: AlwaysOn-Verfügbarkeitsgruppen in SQL Server 2012 bieten eine vereinheitlichte HADR (High Availability and Disaster Recovery)-Lösung mit weiterentwickeltem Funktionsumfang, der in Vorgängerversionen auf mehrere Funktionen verteilt war. Vor SQL Server 2012 basierten viele Kundenbereitstellungen auf folgendem Konzept: Datenbankspiegelung für lokale Hochverfügbarkeit innerhalb eines Rechenzentrums und Protokollversand für die Notfallwiederherstellung in einem Remoterechenzentrum. Ab SQL Server 2012 kann dieses allgemeine Entwurfsmodell von einer Architektur abgelöst werden, die Verfügbarkeitsgruppen sowohl für Hochverfügbarkeit als auch für die Notfallwiederherstellung einsetzt. In diesem Whitepaper werden die wesentlichen Topologieanforderungen dieses Entwurfsmusters erörtert, einschließlich Überlegungen zur Quorumskonfiguration, einer Anleitung zum Einrichten der Umgebung und eines exemplarischen Notfallwiederherstellungsereignisses in der neuen Topologie. Copyright Die Informationen werden in ihrem derzeitigen Zustand zur Verfügung gestellt. Die in diesem Dokument enthaltenen Angaben und Ansichten, einschließlich URLs und anderer Verweise auf Internetwebsites, können ohne vorherige Ankündigung geändert werden. Ihnen obliegt das Risiko der Verwendung. Einige der in diesem Dokument dargestellten Beispiele werden nur zu Illustrationszwecken bereitgestellt und sind fiktiv. Ähnlichkeiten mit realen Gegebenheiten sind weder beabsichtigt noch erwünscht. Mit diesem Dokument erwerben Sie keine Rechte an geistigem Eigentum in Microsoft-Produkten. Sie können dieses Dokument zu internen Zwecken und als Referenz kopieren und verwenden. © 2012 Microsoft. Alle Rechte vorbehalten. 2 Inhalt Einführung..................................................................................................................................................... 4 Älteres Architekturmodell: Datenbankspiegelung für HA und Protokollversand für DR ............................. 4 AlwaysOn-Verfügbarkeitsgruppen für HA und DR........................................................................................ 5 Planung und Überlegungen zur Bereitstellung ............................................................................................. 6 Topologieanforderungen .......................................................................................................................... 6 Failovereinheit .......................................................................................................................................... 7 Alternativen zum Protokollversand .......................................................................................................... 7 Quorummodell und Knotenstimmen........................................................................................................ 7 Tools zur Anzeige oder zum Ändern von Quorummodell und Knotenstimmen................................... 9 Konfigurieren des WSFC-Quorummodells .......................................................................................... 10 Verwenden von DMVs und AlwaysOn-Dashboard zum Anzeigen von Quoruminformationen ......... 10 Konfigurieren von Knotenstimmen..................................................................................................... 12 Clientkonnektivität.................................................................................................................................. 13 Verbindungszeichenfolgen für ältere Datenbankspiegelungslösungen ............................................. 13 Verfügbarkeitsgruppenlistener ........................................................................................................... 13 Unterstützung für Multisubnetz-Verbindungen ................................................................................. 13 Erstellen der Verfügbarkeitsgruppenlösung ............................................................................................... 14 Überlegungen zur Überwachung ................................................................................................................ 20 Wiederherstellung nach einem Notfall....................................................................................................... 21 Wiederinbetriebnahme des primären Rechenzentrums ............................................................................ 25 Schlussfolgerung ......................................................................................................................................... 28 Referenzmaterial ........................................................................................................................................ 28 Anhang A: HA/DR-Beispiel mit Verfügbarkeitsgruppen und 3 Rechenzentren .......................................... 29 3 Einführung Microsoft SQL Server 2012 AlwaysOn bietet Kunden flexible Entwurfsoptionen zur Auswahl der richtigen Strategie für eine Hochverfügbarkeits- und Notfallwiederherstellungslösung (High Availability, HA + Disaster Recovery, DR). SQL Server 2012 unterstützt mehrere Entwurfsmuster zum Umsetzen einer HA+DR-Lösung mit AlwaysOn-Technologie. Dieses Whitepaper beschreibt eine Lösung, die HA und DR über AlwaysOn-Verfügbarkeitsgruppen implementiert. Die Lösung basiert ausschließlich auf nicht freigegebenem Speicher, da jede SQL Server-Instanz in der Topologie über einen eigenen Satz von Daten verfügt und keinen Speicher gemeinsam nutzen muss. Weitere Informationen zu anderen Entwurfsoptionen finden Sie unter SQL Server 2012 AlwaysOn-Entwurfsmuster für Hochverfügbarkeit und Notfallwiederherstellung. Vor SQL Server 2012 zeichnete sich eine gängige HA- und DR-Architektur durch zwei Mechanismen aus: Datenbankspiegelung für lokale Hochverfügbarkeit und Protokollversand für die RemoteNotfallwiederherstellung. Ab SQL Server 2012 können Verfügbarkeitsgruppenlösungen mit mehreren sekundären Replikaten die Vorgängerlösung mit Datenbankspiegelung und Protokollversand ablösen. Dieses Whitepaper enthält Überlegungen zur Planung und führt Sie durch die Schritte zum Erstellen von Verfügbarkeitsgruppen, die Sie bei der Umsetzung Ihrer HA- und DR-Ziele unterstützen. Außerdem erfahren Sie hier, welche Schritte Sie zur Notfallwiederherstellung ausführen und wie Sie den Betrieb des primären Rechenzentrums nach der Wiederherstellung wiederaufnehmen. Dieses Dokument setzt Grundkenntnisse über AlwaysOn-Verfügbarkeitsgruppen, Hochverfügbarkeit und Notfallwiederherstellung voraus. Weitere Informationen zum vollständigen Funktionsumfang von AlwaysOn-Lösungen finden Sie im Whitepaper Microsoft SQL Server AlwaysOn-Lösungen für Hochverfügbarkeit und Notfallwiederherstellung. Dieses Whitepaper richtet sich an Administratoren und Technologiearchitekten operationaler SQL Server-Datenbanken. Auch Systemadministratoren, die gemeinsam mit Datenbankadministratoren Windows Server, Active Directory-Domänendienste (AD DS), Windows Server-Failovercluster (WSFC) und Netzwerkfunktionen verwalten, profitieren von diesem Whitepaper. Älteres Architekturmodell: Datenbankspiegelung für HA und Protokollversand für DR Vor SQL Server 2012 basierte eine typische SQL Server-Kundenlösung auf der folgenden Architektur: Datenbankspiegelung für Hochverfügbarkeit innerhalb des primären Rechenzentrums und Protokollversand für die Notfallwiederherstellung zwischen Rechenzentren. Bei dieser Lösung wird die Datenbankspiegelung innerhalb des primären Rechenzentrums konfiguriert. Für das automatische Failover wird die synchrone Datenbankspiegelung mit einem Zeugen (d. h. einer dritten SQL Server-Instanz) konfiguriert. Wenn Datenverluste nicht tolerierbar sind, gewährleistet die (synchrone) Datenbankspiegelung im Hochsicherheitsmodus, dass zwischen den beiden Servern im primären Rechenzentrum keine Daten verloren gehen. Um die Datenbankverfügbarkeit innerhalb des primären Rechenzentrums zu verbessern, wird eine dritte SQL Server-Instanz als Zeuge konfiguriert, um automatische Failover zwischen den Datenbank-Spiegelungspartnern zu ermöglichen. 4 Wenn beim Ausfall eines primären Rechenzentrums beide Datenbank-Spiegelungspartner unerreichbar sind, wird anhand des Protokollversands eine Notfallwiederherstellung durchgeführt. Beim Protokollversand werden die Transaktionsprotokolle der Prinzipaldatenbank fortlaufend gesichert. Anschließend werden diese Transaktionsprotokollsicherungen auf eine SQL Server-Instanz im DR-Rechenzentrum kopiert. Eingehende Transaktionsprotokollsicherungen werden der Reihe nach fortlaufend wiederhergestellt. Sie können den Protokollversand auch nur für Leseoperationen konfigurieren. Das hat jedoch den Nachteil, dass schreibgeschützte Verbindungen getrennt werden müssen, bevor eingehende Transaktionsprotokollsicherungen repliziert werden. Abbildung 1 zeigt Architektur dieser Lösung. Abbildung 1: Datenbankspiegelung für HA und Protokollversand für DR Weitere Informationen und ein Praxisbeispiel finden Sie in der technischen Fallstudie Hohe Verfügbarkeit und Notfallwiederherstellung für die Microsoft SAP Data-Tier: eine technische SQL Server 2008-Fallstudie. AlwaysOn-Verfügbarkeitsgruppen für HA und DR AlwaysOn-Verfügbarkeitsgruppen können die zuvor beschriebene Lösung, die auf Datenbankspiegelung und Protokollversand basiert, ersetzen. Die Verwendung von Verfügbarkeitsgruppen sowohl für Hochverfügbarkeit als auch für Notfallwiederherstellung bietet die folgenden Vorteile: 5 Mehrere Benutzerdatenbanken können in einer Failovereinheit gruppiert werden. Im Gegensatz dazu unterstützt die Datenbankspiegelung nur eine Benutzerdatenbank als Failovereinheit. Verfügbarkeitsgruppen mit mehreren sekundären Replikaten ermöglichen die Umsetzung einer einheitlichen HA- und DR-Lösung auf der Basis einer einzelnen Technologie, anstatt wie in der früheren Lösung mehrere Technologien einzubinden. Sekundäre Replikate können auch so konfiguriert werden, dass sie Leseoperationen zulassen, um Daten nahezu in Echtzeit auszuschöpfen. Im Unterschied zum Protokollversand müssen bestehende schreibgeschützte Verbindungen mit sekundären Replikaten nicht getrennt werden, um kontinuierliche Datenänderungen gegenüber dem primären Replikat sichtbar zu machen. Sekundäre Replikate können auch verwendet werden, um vollständige Datenbank- und Transaktionsprotokollsicherungen auszulagern. Verfügbarkeitsgruppen und der zugeordnete Verfügbarkeitsgruppenlistener unterstützen die automatische Clientumleitung zum primären Replikat oder die Umleitung zu verfügbaren lesbaren sekundären Replikaten. Verfügbarkeitsgruppenlistener bieten den Vorteil, dass in der Clientverbindungszeichenfolge kein Failoverpartner mehr angegeben werden muss. Abbildung 2 zeigt die HA- und DR-Lösung unter Verwendung von Verfügbarkeitsgruppen. DR-Rechenzentrum Primäres Rechenzentrum Windows Server-Failovercluster (einzelner WSFC über zwei Rechenzentren) SQL Server SQL Server Sekundär SQL Server Primär Sekundär Synchron Asynchron Verfügbarkeitsgruppe Abbildung 2: Verwenden von Verfügbarkeitsgruppen für HA und DR Wie in Abbildung 2 dargestellt, gehören die drei Knoten (auf denen jeweils eine SQL Server-Instanz läuft) einem einzigen Windows Server-Failovercluster (WSFC) an, der sich über zwei Rechenzentren erstreckt. Es ist darauf hinzuweisen, dass es sich um eine Lösung mit nicht freigegebenem Speicher handelt und dass die Knoten untereinander keinen Speicher zusammen mit anderen Knoten nutzen. Auf jedem Knoten wird eine Instanz von SQL Server ausgeführt, die über einen eigenen Satz an Daten verfügt. Hinweis: Abbildung 2 zeigt ein einfaches Szenario mit zwei Rechenzentren: das primäre Rechenzentrum hostet zwei Replikate, während das DR-Rechenzentrum ein Replikat hostet. Die Architektur lässt auch Abwandlungen dieser Topologie zu, indem mehrere Rechenzentren und (bis zu 5) Replikate verwendet werden können. Der Schwerpunkt dieses Whitepapers liegt auf der in Abbildung 2 dargestellten Topologie. Grundsätzlich gelten die allgemeinen Ausführungen jedoch auch für Abwandlungen dieser Topologie. Eine alternative Konfiguration mit drei Rechenzentren wird in Anhang A erörtert. Planung und Überlegungen zur Bereitstellung In den nächsten Abschnitten werden die zentralen Planungsüberlegungen, Anforderungen und Voraussetzungen, die der Bereitstellung von Verfügbarkeitsgruppen für HA und DR vorausgehen, ausführlich erörtert. Topologieanforderungen Bevor Sie eine HA+DR-Lösung unter Verwendung von Verfügbarkeitsgruppen umsetzen, müssen Sie die Voraussetzungen und Einschränkungen genau verstehen. Weitere Informationen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server). 6 Failovereinheit In dieser HA+DR-Lösung fungiert eine Verfügbarkeitsgruppe (eine Gruppe von Benutzerdatenbanken) als Failovereinheit. SQL Server-Agent-Aufträge, Anmeldenamen, Verbindungsserver und andere Objekte, die außerhalb der Verfügbarkeitsdatenbanken gespeichert sind, werden beim Failover der Verfügbarkeitsgruppe nicht berücksichtigt. Eigenständige Datenbanken sind eine Möglichkeit, um Anmeldenamen beim Failover zwischen Verfügbarkeitsreplikaten mitzunehmen. Für andere Objekte, die sich außerhalb der Benutzerdatenbank befinden, z. B. SQL Server-Agent-Aufträge, Verbindungsserver und SQL Server Integration Services-Pakete, sind zur Synchronisierung mehrerer SQL Server-Instanzen zusätzliche Schritte erforderlich. Alternativen zum Protokollversand Wenn Sie eine frühere Lösung mit Protokollversand durch eine Verfügbarkeitsgruppenlösung ersetzen, sind folgende Punkte zu berücksichtigen: Der Verzicht auf den Protokollversand bedeutet auch, dass Sicherungen nicht verzögert auf sekundäre Replikate kopiert werden können. Die Protokolldatensätze des Verfügbarkeitsgruppenreplikats werden sofort repliziert, und das vom Protokollversand bekannte verzögerte Kopieren wird für Verfügbarkeitsgruppen nicht unterstützt. Wenn diese Funktion ein wichtiger Bestandteil Ihrer alten Lösung war, müssen Sie eine Alternative suchen oder den Protokollversand zusammen mit Ihrer Verfügbarkeitsgruppenlösung implementieren. Der Wegfall des Protokollversands bedeutet auch, dass keine regelmäßigen Protokollsicherungen mehr erstellt werden. Verfügbarkeitsgruppen sind kein Ersatz für eine Sicherungs- und Wiederherstellungsstrategie. Sie müssen die regelmäßige Protokollsicherung als separaten Prozess für Verfügbarkeitsgruppen einrichten, um die notwendige fortlaufende Aktualisierung des Transaktionsprotokolls für jede Verfügbarkeitsdatenbank in der Verfügbarkeitsgruppe sicherzustellen. Quorummodell und Knotenstimmen Hinweis: Das Quorum und verwandte Themen in diesem Whitepaper beziehen sich auf eine Lösung, die unter den Betriebssystemen Windows Server 2008 und Windows Server 2008 R2 inklusive relevanter Softwareupdates ausgeführt wird. Ein WSFC-Cluster bildet die Infrastruktur einer Verfügbarkeitsgruppe. Deshalb muss das geeignete Quorummodell für den WSFC-Cluster ausgewählt werden. Die Quorumkonfiguration wird auf der WSFCEbene verwaltet, unabhängig von der Anzahl der Replikate und Verfügbarkeitsgruppen, die im WSFCCluster gehostet werden. WSFC unterstützt vier Quorummodelle. Allerdings sind nicht alle Quorummodelle für die hier besprochene Lösung mit nicht freigegebenem Speicher geeignet. Insofern sind Quorummodelle, die auf freigegebenen Datenträgern basieren (Knoten- und Datenträgermehrheit, Keine Mehrheit: Nur Datenträger) nicht anwendbar. Demnach sind für die hier vorgestellte Lösungsarchitektur zwei Quorummodelle denkbar: "Knoten- und Dateifreigabemehrheit" oder "Knotenmehrheit". Weitere Informationen zu den vier Quorummodellen finden Sie unter Schrittweise Anleitung für Failovercluster: Konfigurieren des Quorums in einem Failovercluster. 7 Bevor Sie ein Quorummodell auswählen, müssen Sie Überlegungen zur Anzahl der stimmberechtigten Knoten anstellen. Das Zuweisen der Knotenstimmen nimmt einen wichtigen Teil im HA+DR-Entwurfsmodell ein. Standardmäßig verfügt jeder Knoten in einem WSFC-Cluster über eine Stimme, was aber nicht für jede HA+DR-Lösung geeignet sein muss, je nachdem, wie die Knoten im primären und DR-Rechenzentrum verteilt sind. Ein Windows Server-Hotfix (http://support.microsoft.com/kb/2494036) kann verwendet werden, um einigen Knoten im WSFC-Cluster 1 Stimme und anderen Knoten 0 Stimmen zuzuweisen. Die NodeWeight-Eigenschaft des WSFC-Knotens repräsentiert die Stimme des betreffenden Knotens. Der Wert "0" bedeutet, dass der Knoten keine Stimme hat. Der Wert "1" bedeutet, dass der Knoten eine Quorumsstimme hat. Das Hotfix muss auf jedem Knoten in der Topologie installiert werden. Allgemeine Empfehlungen für die Quorumabstimmung in einer AlwaysOn HA+DR-Lösung finden Sie im Abschnitt Empfohlene Anpassungen an der Quorumabstimmung unter WSFC-Quorummodi und Abstimmungskonfiguration in der SQL Server-Onlinedokumentation. Diese sollten bei der Auswahl des Abstimmungsschemas für die AlwaysOn-Lösung als Richtschnur gelten. Unter Berücksichtigung dieser Richtlinien ergibt sich für die in Abbildung 2 dargestellte HA+DR-Lösung auf der Basis von Verfügbarkeitsgruppen das folgende Abstimmungsschema: 1 Stimme für jeden Knoten im primären Rechenzentrum 0 Stimmen für den Knoten im DR-Rechenzentrum Durch die Stimmenzuweisung stellen Sie sicher, dass das Quorum der Knoten im primären Rechenzentrum nicht durch Ausfälle des DR-Rechenzentrums oder unterbrochene Verbindungen zwischen den beiden Rechenzentren beeinträchtigt wird. Wenn Sie über eine ungerade Anzahl stimmberechtigter Knoten verfügen, ist das Quorummodell "Knotenmehrheit" die beste Wahl. Da die in diesem Whitepaper erörterte Topologie über eine gerade Zahl stimmberechtigter Knoten verfügt (die beiden Knoten im primären Rechenzentrum), stehen die beiden folgenden Optionen zur Auswahl: Fügen Sie dem WSFC-Cluster im primären Rechenzentrum einen zusätzlichen stimmberechtigten Knoten hinzu, und verwenden Sie dann das Quorummodell "Knotenmehrheit". Es ist nicht erforderlich, SQL Server auf diesem zusätzlichen Knoten zu installieren, und er muss kein Replikat der Verfügbarkeitsgruppe sein. Diese Konfiguration mit den entsprechenden stimmberechtigten Knoten ist in Abbildung 3 dargestellt (die Zuweisung von Knotenstimmen wird an späterer Stelle in diesem Whitepaper erörtert). DR-Rechenzentrum Primäres Rechenzentrum Windows Server-Failovercluster (einzelner WSFC über zwei Rechenzentren) SQL Server SQL Server KEINE STIMME STIMME STIMME Sekundär Primär SQL Server Sekundär Synchron Asynchron Verfügbarkeitsgruppe STIMME Zusätzlicher Server für Quorummodell mit Knotenmehrheit Abbildung 3: Zuweisung von Knotenstimmen für die Bereitstellung einer HA+DR-Verfügbarkeitsgruppenlösung mit dem Quorummodell "Knotenmehrheit" 8 Verwenden Sie das Quorummodell "Knoten- und Dateifreigabemehrheit" mit einem geschützten Dateifreigabezeugen. Die Dateifreigabe liefert eine zusätzliche Stimme zur Schaffung des Quorums und enthält keine SQL Server-Daten. Diese Konfiguration mit den entsprechenden stimmberechtigten Knoten ist in Abbildung 4 dargestellt. DR-Rechenzentrum Primäres Rechenzentrum Windows Server-Failovercluster (einzelner WSFC über zwei Rechenzentren) SQL Server SQL Server STIMME STIMME Primär Sekundär KEINE STIMME SQL Server Sekundär Synchron Asynchron Verfügbarkeitsgruppe STIMME Dateifreigabe Abbildung 4: Zuweisung von Knotenstimmen für die Bereitstellung einer HA+DR-Verfügbarkeitsgruppenlösung mit dem Quorummodell "Knoten- und Dateifreigabemehrheit" Beachten Sie, dass sich der Dateifreigabezeuge außerhalb des WSFC-Clusters befindet, der die Verfügbarkeitsgruppe hostet. Eine bestimmte Dateifreigabe kann als Zeuge für einen oder mehrere WSFC-Cluster auftreten. Der Dateifreigabezeuge (falls verwendet) zählt immer als eine Stimme. Es ist nicht zulässig, einem Dateifreigabezeugen 0 Stimmen zuzuweisen. Bei dem Quorummodell und den Stimmenzuweisungen in Abbildung 3 und 4 wird davon ausgegangen, dass Sie über drei Replikate (ein primäres und zwei sekundäre Replikate) der Verfügbarkeitsgruppe verfügen (zwei Replikate im primären Rechenzentrum und ein Replikat im DR-Rechenzentrum). Wenn Sie über eine abweichende Anzahl von Knoten und Replikaten verfügen, kann die Stimmenzuweisung geringfügig abweichen. Die grundlegenden Prinzipien sind jedoch weiterhin gültig. Wenn Sie beispielsweise über ein zusätzliches Replikat im primären Rechenzentrum verfügen (z. B. um Leseund Sicherungsoperationen auszulagern), ergibt sich eine Gesamtzahl von drei Knoten im primären Rechenzentrum. Folglich kann das Quorummodell "Knotenmehrheit" verwendet werden, ohne dass der zusätzliche Knoten (vgl. Abbildung 3) oder der Dateifreigabezeuge (vgl. Abbildung 4) erforderlich ist. In diesem Szenario weisen Sie außerdem jedem Knoten im primären Rechenzentrum eine (1) Stimme zu und dem Knoten im DR-Rechenzentrum null (0) Stimmen. Bei dem Quorummodell und den Stimmenzuweisungen in Abbildung 3 und 4 wird zusätzlich davon ausgegangen, dass sich die Lösung über zwei Rechenzentren erstreckt. Wenn Sie über weitere Rechenzentren verfügen und einen Teil der Lösung in ein drittes Rechenzentrum verlagern möchten, können ein anderes Quorummodell und eine andere Stimmenzuweisung in Betracht kommen. Tools zur Anzeige oder zum Ändern von Quorummodell und Knotenstimmen Es gibt mehrere Möglichkeiten, das Clusterquorummodell und die Quorumsstimmen anzuzeigen und zu ändern. In den folgenden Tabellen sind die verschiedenen Tools für diese Aufgaben aufgeführt. 9 Anzeigen des Quorummodells Windows-Failovercluster-Manager Windows PowerShell Cluster.exe Dynamische SQL Server-Verwaltungssichten (DMVs) AlwaysOn-Dashboard in SQL Server Management Studio Anzeigen von Knotenstimmen Windows PowerShell Cluster.exe Dynamische SQL Server-Verwaltungssichten (DMVs) AlwaysOn-Dashboard Ändern des Quorummodells Windows-Failovercluster-Manager Windows PowerShell Cluster.exe Ändern von Knotenstimmen Windows PowerShell Cluster.exe Konfigurieren des WSFC-Quorummodells Es folgen Beispiele für die Verwendung von Windows PowerShell über die Befehlszeile, um das aktuelle Quorummodell anzuzeigen und zu ändern. Anzeigen des vorhandenen Quorummodells Get-ClusterQuorum Konfigurieren des Quorummodells "Knotenmehrheit" Set-ClusterQuorum -NodeMajority Ändern des Quorummodells in "Knoten- und Dateifreigabemehrheit" Set-ClusterQuorum -NodeAndFileShareMajority \\EMU-DC\Witness Die ausgewählte Zeugendateifreigabe darf sich nicht auf einem Knoten befinden, der bereits Teil der AlwaysOn-WSFC-Konfiguration ist. Er kann jedoch als Freigabe in einer anderen WSFC-Konfiguration platziert sein und muss sich in derselben Active Directory-Domäne wie der WSFC-Cluster befinden. Außerdem benötigt das WSFC-Clusterdienstkonto Lese- und Schreibberechtigungen für den Dateifreigabezeugen. Der Failovercluster-Manager verfügt über eine integrierte Logik, um dem Dateifreigabezeugen diese Berechtigungen hinzuzufügen. Das funktioniert jedoch nur, solange das Administratorkonto, über das das Quorummodell geändert wird, über Berechtigungen für die Dateifreigabe verfügt. Verwenden von DMVs und AlwaysOn-Dashboard zum Anzeigen von Quoruminformationen Weder Quorummodell noch Knotenstimmen können mithilfe von SQL Server-Tools festgelegt oder geändert werden. Ihnen stehen jedoch Transact-SQL-Abfragen für DMVs und das AlwaysOn-Dashboard in SQL Server Management Studio zur Verfügung, um die Knotenstimmen und das Quorummodell des Windows-Clusters, der die Verfügbarkeitsgruppe hostet, anzuzeigen. Um das Quorummodell des Windows-Clusters anzuzeigen, der die Verfügbarkeitsgruppe hostet, führen Sie die DMV-Abfrage sys.dm_hadr_cluster aus. 10 SELECT FROM cluster_name, quorum_type_desc, quorum_state_desc sys.dm_hadr_cluster; Wenn die Abfrage in der Beispielumgebung dieses Whitepapers ausgeführt wird, gibt sie das folgende Resultset zurück. cluster_name -----------EMU-AGClstr quorum_type_desc ---------------NODE_AND_FILE_SHARE_MAJORITY quorum_state_desc ----------------NORMAL_QUORUM Um die Knotenstimmen anzuzeigen, führen Sie die DMV-Abfrage sys.dm_hadr_cluster_members aus. SELECT FROM member_name, number_of_quorum_votes sys.dm_hadr_cluster_members; Wenn die Abfrage in der Beispielumgebung dieses Whitepapers ausgeführt wird, gibt sie das folgende Resultset zurück. (Die Stimmenzuweisung wird in einem späteren Abschnitt erläutert.) Member_name number_of_quorum_votes ----------- ---------------------EMU-SQL1 1 EMU-SQL2 1 EMU-SQL3 0 FSWitness 1 Das AlwaysOn-Dashboard in SQL Server Management Studio kann auch verwendet werden, um Quorumsstimmen und den Clusterstatus anzuzeigen. Abbildung 5 zeigt diese Informationen für einen Windows-Cluster mit dem Quorummodell "Knotenmehrheit" an (Clusterstatus und Quorumsstimmen sind markiert). Abbildung 5: Anzeigen von Quorumsstimmen und Clusterstatus im AlwaysOn-Dashboard für das Quorummodell "Knotenmehrheit" 11 Obwohl die Spalte Quorumsstimmen standardmäßig nicht angezeigt wird, können Sie sie dem Dashboard hinzufügen, indem Sie mit der rechten Maustaste auf Verfügbarkeitsreplikat klicken und dann eine bestimmte Spalte zur Anzeige auswählen. Beim Quorummodell "Knoten- und Dateifreigabemehrheit" enthält die AlwaysOn-Dashboardansicht nur die Knoten, aber nicht die Dateifreigabe. Um die vollständigen Quoruminformationen zu sehen, klicken Sie auf der rechten Seite auf Informationen zum Clusterquorum anzeigen. Ein mit Abbildung 6 vergleichbares Popupfenster wird angezeigt. Abbildung 6: Clusterquoruminformationen für das Quorummodell "Knoten- und Dateifreigabemehrheit" Konfigurieren von Knotenstimmen Die NodeWeight-Eigenschaft des WSFC-Knotens repräsentiert die Stimme des betreffenden Knotens. Die folgenden Beispiele zeigen, wie die "NodeWeight"-Einstellung eines Knotens in einem WSFC-Cluster mithilfe von Windows PowerShell konfiguriert wird. Zum Ausführen von Windows PowerShell auf dem Serverknoten klicken Sie auf Start, zeigen auf Verwaltung und klicken dann auf Windows PowerShellModule. In diesem Beispiel steht EMU-SQL3 für einen bestimmten WSFC-Knoten im sekundären Rechenzentrum. Anzeigen aktueller Einstellungen für alle Knotenstimmen Get-ClusterNode | fl NodeName, NodeWeight Festlegen der Stimme eines Knotens auf "0" (Get-ClusterNode "EMU-SQL3").NodeWeight=0 Hinweis: Der Wert "0" bedeutet, dass der Knoten keine Stimme hat. Der Wert "1" bedeutet, dass der Knoten eine Quorumsstimme hat. 12 Clientkonnektivität Dieser Abschnitt fasst die Überlegungen zur Clientkonnektivität zusammen, die beim Umstieg auf eine Verfügbarkeitsgruppenlösung wichtig sind. Weitere Informationen zu Clientkonnektivität und Anwendungsfailover finden Sie unter Clientkonnektivität und Anwendungsfailover (AlwaysOnVerfügbarkeitsgruppen). Verbindungszeichenfolgen für ältere Datenbankspiegelungslösungen Wenn Sie Anwendungsverbindungen von einer älteren Datenbankspiegelungslösung migrieren, die das Failoverpartner-Attribut verwendet, können Sie die Verbindungszeichenfolge für die Datenbankspiegelung nur weiter verwenden, wenn die Verfügbarkeitsgruppe mit einem einzelnen sekundären Replikat konfiguriert ist. Das sekundäre Replikat kann nicht für Leseoperationen aktiviert werden. Sie können den anfänglichen Partnerservernamen und optional den Failoverpartnernamen angeben. Dies ist jedoch nicht als langfristige Lösung gedacht und als Umgehungslösung für die in diesem Whitepaper vorgestellte Bereitstellungslösung nicht geeignet, weil für dieses spezielle Entwurfsmodell mindestens drei Replikate (ein primäres Replikat und zwei sekundäre Replikate) erforderlich sind. Verfügbarkeitsgruppenlistener Bei Verfügbarkeitsgruppen können Sie einen Verfügbarkeitsgruppenlistener-Namen für das Serverattribut festlegen. Der Verfügbarkeitsgruppenlistener ist ein VNN (Virtual Network Name), den Sie zur Verwendung mit einer bestimmten Verfügbarkeitsgruppe erstellen. Dieser Name ist an mindestens eine TCP/IP-Adresse und mindestens einen Listenerport gebunden und wird für die automatische Verbindung mit dem primären Replikat verwendet, wo auch immer dieses gerade gehostet wird. Der VNN macht die Verwendung eines Failoverpartner-Attributs überflüssig und unterstützt eine skalierbare Topologie mit bis zu fünf Verfügbarkeitsreplikaten. Wenn für eine Verfügbarkeitsgruppe beispielsweise ein Failover von Knoten1 auf Knoten2 ausgeführt wird, werden neue Verbindungen mit dem Verfügbarkeitsgruppenlistener automatisch mit dem Replikat hergestellt, das gerade das primäre Replikat hostet. Darüber hinaus kann der Verfügbarkeitsgruppenlistener für das automatische Routing von Leseoperationen an lesbare sekundäre Replikate verwendet werden. Weitere Informationen zu dieser Funktion finden Sie unter Konfigurieren des schreibgeschützten Routings für eine Verfügbarkeitsgruppe (SQL Server). Unterstützung für Multisubnetz-Verbindungen Bei anderen Verbindungsattributen für Verfügbarkeitsgruppen wird empfohlen, das MultiSubnetFailoverAttribut – sowohl für Einzel- als auch für Multisubnetz-Topologien – in VerfügbarkeitsgruppenVerbindungszeichenfolgen anzugeben, wenn auf den Namen eines Verfügbarkeitsgruppenlisteners verwiesen wird. Wenn dieses Verbindungszeichenfolgenattribut aktiviert ist, ermöglicht die MultiSubnetFailover-Verbindungsoption die Unterstützung von Multisubnetz-Verbindungen und öffnet parallel TCP-Sockets für IP-Adressen von Verfügbarkeitsgruppenlistenern. Wenn Sie ältere Clientbibliotheken verwenden, die das MultiSubnetFailover-Attribut nicht unterstützen, sollten Sie das Timeout für die Clientanmeldung in der Anwendungsverbindungszeichenfolge heraufsetzen, um eine mögliche Latenz bei Multisubnetz-Verbindungen zu berücksichtigen. Die Timeouteinstellung sollte einem Wert entsprechen, der größer als die durchschnittliche Failoverzeit für Verfügbarkeitsgruppen in der jeweiligen Umgebung ist. Weitere Informationen zur Clientunterstützung finden Sie unter SQL Server Native ClientUnterstützung für hohe Verfügbarkeit, Notfallwiederherstellung. 13 Erstellen der Verfügbarkeitsgruppenlösung In diesem Abschnitt werden die Schritte und der Workflow beschrieben, die erforderlich sind, um in einer Lösung für lokale Hochverfügbarkeit und Remote-Notfallwiederherstellung eine Verfügbarkeitsgruppe zu erstellen. Der Schwerpunkt liegt auf der Erstellung einer neuen Umgebung ähnlich der Topologie in Abbildung 4 oben. Bei diesem Entwurfsmuster wird vorausgesetzt, dass auf den einzelnen SQL ServerInstanzen nicht freigegebener Speicher verwendet wird. Die Mindestanforderungen für SQL Server 2012 sind Windows Server 2008 R2 mit Service Pack 1 (SP1) oder Windows Server 2008 mit SP2. Bei den folgenden Anweisungen wird davon ausgegangen, dass Windows Server 2008 R2 SP1 Enterprise als Betriebssystem auf dem Serverknoten installiert ist. Tabelle 1 beschreibt die Schritte, die erforderlich sind, um eine Verfügbarkeitsgruppenlösung für lokale Hochverfügbarkeit und Remote-Notfallwiederherstellung umzusetzen. Obwohl hier nicht auf jeden einzelnen Schritt eingegangen wird, soll dieser Abschnitt dazu beitragen, die Schritte zur Workflowimplementierung und die Rollen der verschiedenen Aufgabenbereiche zu verdeutlichen. Sofern nötig, wird auf Begleitdokumentationen verwiesen. Die folgenden Schritte sind nach Aufgabengebiet gegliedert, da die Aufgaben in den meisten großen Unternehmensumgebungen nach Zuständigkeit unterteilt sind, z. B. Datenbankadministrator, Windows Server-(oder Cluster-)Administrator und Netzwerkadministrator. Aus diesem Grund müssen die Aktivitäten der verschiedenen Aufgabengebiete richtig kommuniziert und koordiniert werden. Schritt Datenbankadministrator Windows Server-/Clusteradministrator 1. Zunächst fügen Sie den beiden neu konfigurierten Knoten im primären Rechenzentrum und dem dritten neu konfigurierten Knoten im sekundären Rechenzentrum die Failoverclusterfunktion hinzu. Weitere Informationen finden Sie unter Installieren der Failoverclusterfunktion und Anforderungen an Failovercluster. Ja – Koordination der Aktivitäten über Aufgabengebiete hinweg Ja 14 Netzwerkadministrator Schritt 2. Stellen Sie sicher, dass das Konto, das Sie zur Installation und Konfiguration des WSFCClusters verwenden, ein Domänenkonto ist. Dieses Konto sollte auch über Administratorberechtigungen für jeden Clusterknoten sowie über die Berechtigungen Computerobjekte erstellen und Alle Eigenschaften lesen für den Container verfügen, in dem die Domänencomputerkonten enthalten sind. Alternativ können Sie die Active DirectoryNamensobjektkonten vorzeitig bereitstellen oder ein Domänenadministratorkonto zur Installation verwenden. Weitere Informationen und detaillierte Schritte zu den erforderlichen Berechtigungen und Bereitstellungsoptionen finden Sie unter Schrittweise Anleitung für Failovercluster: Konfigurieren von Konten in Active Directory. 3. Führen Sie mit dem Failovercluster-Manager eine Clustervalidierung der drei Serverknoten in den beiden Rechenzentren aus, die dem WSFC-Cluster angehören. Da für das in diesem Whitepapier behandelte Entwurfsmuster kein freigegebener Speicher verwendet wird, werden diesbezügliche Tests während der Validierung nicht ausgeführt. Nachdem Sie die Clustervalidierung ausgeführt haben, stellen Sie vor dem Erstellen des tatsächlichen WSFC-Clusters sicher, dass keine Blockierungsfehler aufgetreten sind. Wenn Sie trotz angezeigter Warnungen zum nächsten Schritt übergehen können, müssen Sie alle Warnungen genau verstehen, um eine stabile Konfiguration zu gewährleisten. Weitere Informationen und Anweisungen zum Ausführen eines Validierungstests finden Sie unter Überprüfen einer Failoverclusterkonfiguration. 15 Datenbankadministrator Windows Server-/Clusteradministrator Netzwerkadministrator Ja Ja Ja – bei Problemen, die bei der Vernetzung der Knoten auftreten können Schritt 4. Nach Ende der Validierung verwenden Sie den Failovercluster-Manager, um einen aus drei Knoten bestehenden WSFC-Cluster zu erstellen. Weitere Informationen finden Sie unter Erstellen eines neuen Failoverclusters. Wenn der WSFC-Cluster drei Knoten umfasst, lautet die Standardkonfiguration für den Quorummodus an dieser Stelle Knotenmehrheit. Sie können das Quorummodell später ggf. in "Knotenund Dateifreigabemehrheit" ändern oder einen weiteren Knoten als reinen Abstimmungsknoten hinzufügen, auf dem SQL Server nicht installiert sein muss. 5. Damit der Knoten im DR-Rechenzentrum die Verfügbarkeit der Knoten im primären Rechenzentrum nicht beeinträchtigt, installieren Sie das in KB 2494036 angegebene Hotfix. Dieses Hotfix unterstützt die Konfiguration eines Clusterknotens, der über keine Quorumsstimmen verfügt, in Windows Server 2008 und Windows Server 2008 R2. Nachdem Sie das Hotfix auf jedem WSFCKnoten installiert haben, führen Sie die im Abschnitt "Konfigurieren von Knotenstimmen" dieses Whitepapers beschriebenen Schritte aus, um den "NodeWeight"-Wert des WSFCKnotens im DR-Rechenzentrum auf "0" festzulegen. Das bedeutet, dass nur die beiden Knoten im primären Rechenzentrum und der Dateifreigabezeuge, den Sie im nächsten Schritt konfigurieren, über Stimmen verfügen. Bei diesem Workflow wird vorausgesetzt, dass Sie anstelle eines zusätzlichen Servers einen Dateifreigabezeugen für die Knotenmehrheit wählen. Wenn Sie stattdessen einen zusätzlichen Server ausgewählt haben, der die Stimme liefert, gelten die Überlegungen zu Quorumsstimmen im Wesentlichen trotzdem. 16 Datenbankadministrator Windows Server-/Clusteradministrator Netzwerkadministrator Ja Ja – bei Problemen, die bei der Vernetzung der Knoten auftreten können Ja Schritt Datenbankadministrator 6. Da sich der dritte Knoten in einem getrennten Rechenzentrum befindet und keine Stimme mehr hat, sollten Sie dieses Quorummodell in "Knoten- und Dateifreigabemehrheit" ändern. Erstellen Sie im primären Rechenzentrum eine Dateifreigabe auf einem Serverknoten, der dem WSFC-Cluster nicht angehört. Diese Dateifreigabe tritt als Dateifreigabezeuge auf. Nachdem Sie die Dateifreigabe erstellt haben, führen Sie die oben in diesem Whitepaper beschriebenen Schritte aus, um die Quorumkonfiguration in "Knoten- und Dateifreigabemehrheit" zu ändern. Bevor Sie die Konfiguration ändern, sollten Sie dem WSFC-Clusterkonto Leseund Schreibberechtigungen für die Zeugendateifreigabe erteilen. 7. Installieren Sie auf jedem der drei WSFCKnoten eine eigenständige Instanz von SQL Server 2012 Enterprise. Jeder Knoten sollte Zugriff auf seinen eigenen lokalen, nicht freigegebenen Speicher haben, der SQL Server zur Verfügung gestellt wird. Installieren Sie für jeden WSFC-Knoten das SQL Server 2012 Enterprise-Datenbankmodul (zusammen mit weiteren optionalen Funktionen für die Umgebung). Führen Sie die gleichen Schritte wie bei der Installation einer eigenständigen SQL Server-Instanz aus. Obwohl dies ein normaler eigenständiger Vorgang ist, sollten Sie sicherstellen, dass alle SQL Server-Instanzen, die Sie installieren, die gleiche SQL Server-Sortierung zum Hosten der Verfügbarkeitsgruppenreplikate verwenden (und dass diese mit der Sortierung der vorhandenen Datenbankspiegelungs- und Protokollversandumgebung übereinstimmt). Es wird außerdem empfohlen, auf jedem Knoten identische Dateipfade zu verwenden. 17 Windows Server-/Clusteradministrator Ja Ja Netzwerkadministrator Schritt Datenbankadministrator 8. Aktivieren Sie AlwaysOnVerfügbarkeitsgruppenfunktionen für jeden SQL Server-Dienst. Weitere Informationen und ausführliche Schritte zum Verwenden des SQL Server-Konfigurations-Managers oder zur Ausführung von Windows PowerShell finden Sie unter Aktivieren und Deaktivieren von AlwaysOnVerfügbarkeitsgruppen. 9. Nachdem Sie auf allen drei SQL ServerInstanzen die Unterstützung von AlwaysOnVerfügbarkeitsgruppen aktiviert und sichergestellt haben, dass die Datenbanken der Verfügbarkeitsgruppe mit dem Wiederherstellungsmodell FULL konfiguriert wurden, sichern Sie Ihre produktiven Benutzerdatenbanken der früheren Topologie und stellen sie auf einem Knoten des primären Rechenzentrums im WSFC-Cluster wieder her. Ja Es wird davon ausgegangen, dass Sie mindestens eine Benutzerdatenbank auf eine SQL Server-Instanz im primären Rechenzentrum migrieren. Der zweite Knoten im primären Rechenzentrum wird dann als sekundäres Replikat mit synchronem Modus verwendet. Darüber hinaus müssen Sie für andere SQL Server-Objekte der früheren Topologie, von denen die Benutzerdatenbanken abhängen, die jedoch nicht in den wiederhergestellten Benutzerdatenbanken enthalten sind, ein Skript erstellen (z. B. SQL Server-Anmeldungen, zugeordnete Berechtigungen auf Serverebene, SQL Server-Agent-Aufträge). Sie gehen ähnlich vor wie beim Erstellen eines Skripts für abhängige Objekte, die sich in einer Datenbank-Spiegelungspartnerschaft außerhalb der gespiegelten Datenbank befinden. Es gibt mehrere Methoden, um Datenbankobjekte zwischen SQL ServerInstanzen zu übertragen. Der Integration Services-Task SQL Server-Objekte übertragen ist ein solcher Ansatz. 18 Ja Windows Server-/Clusteradministrator Netzwerkadministrator Schritt Datenbankadministrator 10. Erstellen Sie eine Verfügbarkeitsgruppe mit dem Assistenten in SQL Server Management Studio (Verwenden des Assistenten für neue Verfügbarkeitsgruppen), mit Transact-SQL oder Windows PowerShell. Ja Windows Server-/Clusteradministrator Weitere Informationen zur Verwendung von Transact-SQL oder SQL Server PowerShell finden Sie unter Erstellen einer Verfügbarkeitsgruppe (Transact-SQL) oder Erstellen einer Verfügbarkeitsgruppe (SQL Server PowerShell). 11. Erstellen Sie den Verfügbarkeitsgruppenlistener (es sei denn, er wurde bereits während des vorangehenden Schritts erstellt). Sie können den Verfügbarkeitsgruppenlistener mit dem Assistenten in SQL Server Management Studio, mit Transact-SQL oder SQL Server PowerShell erstellen. Weitere Informationen zur Verwendung der verschiedenen Methoden finden Sie unter Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server). Ja Ja – zur Koordinierung der Firewalleinstellungen für die ausgewählten IP-Adressen Netzwerkadministrator Ja – um sicherzustellen, dass der für den Endpunkt der Verfügbarkeitsgruppe angegebene Listenerport für jede beteiligte SQL Server-Instanz geöffnet ist Ja – zur Koordinierung von IP-Adressen und Ports Tabelle 1: Erstellen der Verfügbarkeitsgruppenlösung nach Aufgabengebiet Beachten Sie bei der Installation der Verfügbarkeitsgruppe die Informationen zu Replikatkonfigurationen in Tabelle 2. Diese gelten speziell für den in diesem Whitepaper behandelten Lösungsentwurf. Beachten Sie, dass Sie die sekundären Replikate auch als lesbare sekundäre Replikate verwenden können. Dies ist eine hilfreiche Option, die sich nicht auf den Gesamtentwurf der HA+DR-Lösung auswirkt. Aus diesem Grund wurde sie in der Tabelle nicht berücksichtigt. Rechenzentrum Primäres Rechenzentrum Primäres Rechenzentrum DR-Rechenzentrum Replikat Knoten 1 Rolle Primär Verfügbarkeitsmodus Synchroner Commit Failovermodus Automatisch Knoten 2 Sekundär Synchroner Commit Automatisch Knoten 3 Sekundär Asynchroner Commit (ein sekundäres synchrones Replikat ist jedoch zulässig; berücksichtigen Sie die Netzwerklatenz zwischen den Rechenzentren und deren Auswirkungen auf die Anwendungsleistung) Manuell Tabelle 2: Replikateinstellungen Nachdem Sie die in Tabelle 1 aufgeführten Schritte abgeschlossen haben, wird im Failovercluster-Manager eine neue Ressourcengruppe für die Verfügbarkeitsgruppe angezeigt. Innerhalb dieser Ressourcengruppe finden Sie auch den Verfügbarkeitsgruppenlistener, zugehörige Listener-IP-Adressen und die Verfügbarkeitsgruppenressource. Abbildung 7 zeigt, wie eine solche Konfiguration im FailoverclusterManager aussehen kann. 19 Abbildung 7: Windows Server Failovercluster-Manager: Verfügbarkeitsgruppe für HA- und DR-Lösung Überlegungen zur Überwachung Wenn Sie von einer Datenbankspiegelungs- und Protokollversandtopologie zu einer Topologie mit einer Verfügbarkeitsgruppenlösung migrieren, ändert sich auch die Methode zur Überwachung der Topologie. Die folgenden Methoden und Tools stehen zur Verfügung, um die Infrastruktur für Verfügbarkeitsgruppen zu überwachen: AlwaysOn-Gruppendashboard in SQL Server Management Studio Statusinformationen im Objekt-Explorer Neue Leistungsindikatoren für Verfügbarkeitsgruppen Katalogsichten Dynamische Verwaltungssichten (DMVs) Eine Extended Events-Sitzung, die die letzten AlwaysOn DDL-Anweisungen, WSFCKonnektivitätsprobleme, Failoverereignisse, Statusänderungen und Blockierungsereignisse für REDO-Threads nachverfolgt Das AlwaysOn-Gruppendashboard ist eine effiziente Methode, um schnell den Zustand einer Verfügbarkeitsgruppe zu erkennen. Im Dashboard werden der Speicherort der primären Instanz, der Failovermodus und Synchronisierungsstatus der Replikate sowie die Failoverbereitschaft der verschiedenen Replikate (d. h. das Risiko des Verlusts bestimmter Daten) angezeigt. Die Extended Events-Sitzung mit AlwaysOn-Statusereignissen kann auch direkt im Dashboard aufgerufen werden, um die letzten Aktivitäten der Verfügbarkeitsgruppe, Statusänderungen und Ereignisse anzuzeigen. 20 Darüber hinaus können Sie SQL Server-Agent-Warnungen und diesbezügliche Maßnahmen auf der Grundlage von Leistungsindikator-Schwellenwerten und Statusänderungen von Verfügbarkeitsgruppen anzeigen. Weitere Informationen zur Überwachung einer Verfügbarkeitsgruppenumgebung finden Sie unter Überwachen von Verfügbarkeitsgruppen. Wiederherstellung nach einem Notfall In diesem Abschnitt werden die Schritte erläutert, die beim Ausfall der WSFC-Knoten im primären Rechenzentrum ausgeführt werden sollten. Bei diesem Szenario wird davon ausgegangen, dass die Knoten im primären Rechenzentrum nicht erreichbar sind. Der einzige erreichbare Knoten im WSFCCluster befindet sich demnach im sekundären DR-Rechenzentrum. In der realen Welt gibt es natürlich viele verschiedene Ausfallszenarien. Die hier beschriebenen Schritte beziehen sich auf ein Szenario, in dem die Knoten des primären Rechenzentrums nicht erreichbar sind. Wie bereits erwähnt, wird ebenfalls davon ausgegangen, dass der verbleibende Knoten (zunächst) keine Quorumsstimme hat und dass sich die einzigen stimmberechtigten Knoten im primären Rechenzentrum befinden (Abbildung 4). Führen Sie die folgenden Schritte aus, um eine Verfügbarkeitsgruppe beim Ausfall des primären Rechenzentrums wiederherzustellen: 1. Wenn der Failovercluster-Manager auf dem DR-Knoten gestartet wird, werden zunächst wahrscheinlich keine aussagekräftigen Informationen zum Status des WSFC-Clusters angezeigt, weil der Cluster kein Quorum mehr besitzt. Darüber hinaus zeigt das AlwaysOn-Gruppendashboard auf dem DR-Knoten wahrscheinlich den Failovermodus "Unbekannt" und den Verfügbarkeitsreplikatstatus "Wird aufgelöst" an (während eines Ausfalls wird in der Regel nur der Status des lokalen Replikats angezeigt). Im Objekt-Explorer von SQL Server Management Studio sind die Verfügbarkeitsdatenbanken auf dem DR-Knoten möglicherweise nicht sichtbar (vgl. Abbildung 8). Abbildung 8: Zweites Rechenzentrum während eines Ausfalls des primären Rechenzentrums 21 2. Wenn der Status des primären Rechenzentrums unbekannt ist und der Betrieb von einem sekundären DR-Rechenzentrum wiederaufgenommen werden muss, um die RTO-Vorgabe einzuhalten, besteht die einzige Möglichkeit darin, den Windows-Cluster neu zu starten, nachdem auf dem Knoten im DR-Rechenzentrum ein Quorum erzwungen wurde. Das Erzwingen des Quorums sollte als letzte Möglichkeit angesehen werden, wenn von einem längeren Ausfall des primären Rechenzentrums ausgegangen wird. Wenn Sie ein Quorum erzwingen, müssen Sie sicherstellen, dass die Knoten des primären Rechenzentrums kein eigenes Quorum bilden. Im folgenden Windows PowerShell-Beispiel wird das Erzwingen eines Quorums auf einem Knoten des DR-Rechenzentrums veranschaulicht. Überprüfen Sie zunächst, ob der Clusterdienst nicht bereits auf dem DR-Knoten ausgeführt wird. Stop-ClusterNode –Name "EMU-SQL3" Starten Sie dann den Clusterdienst, indem Sie das Quorum erzwingen. Start-ClusterNode –Name "EMU-SQL3" –FixQuorum Weitere Informationen zum Erzwingen eines Quorums finden Sie unter Erzwingen des Starts eines Clusters ohne Quorum. 3. Zu diesem Zeitpunkt wird für den Cluster immer noch das Quorummodell "Knoten- und Dateifreigabemehrheit" verwendet. Get-ClusterQuorum Cluster ------EMU-AGClstr QuorumResource -------------File Share Witness QuorumType ---------NodeAndFileShareMajority Da der Cluster auf dem DR-Knoten mit erzwungenem Quorum ausgeführt wird, müssen Sie das Quorummodell und die Knotenstimmen entsprechend anpassen. Das DR-Rechenzentrum (in diesem Topologiebeispiel) umfasst nur einen Knoten, sodass Sie das Quorummodell in "Knotenmehrheit" (Mehrheit eines Knotens) ändern und dem DR-Knoten eine Stimme und den Knoten des primären Rechenzentrums 0 Stimmen zuweisen. Um das Quorummodell auf "Knotenmehrheit" festzulegen, geben Sie den folgenden Befehl ein. Set-ClusterQuorum -NodeMajority Indem Sie das Quorummodell ändern, versetzen Sie die Knotenstimmen in den Ausgangszustand (eine Stimme für jeden Knoten). Passen Sie die Knotenstimmen jetzt an. (Get-ClusterNode "EMU-SQL3").NodeWeight=1 (Get-ClusterNode "EMU-SQL1").NodeWeight=0 (Get-ClusterNode "EMU-SQL2").NodeWeight=0 Zu diesem Zeitpunkt verfügt die Umgebung über einen Knoten und eine Stimme, sodass ein SPoF (Single Point of Failure = einzelne Fehlerquelle) entsteht. Bevor Sie fortfahren, können Sie überprüfen, ob die Knotenstimmen wie beabsichtigt geändert wurden. Führen Sie dazu den folgenden Windows PowerShell-Befehl aus. Get-ClusterNode | fl NodeName, NodeWeight 22 Wenn Sie die Besitzer der WSFC-"Clustergruppe" auf Knoten des primären Rechenzentrums beschränkt haben, sollten Sie auch den DR-Knoten in die Reihe der Besitzer aufnehmen. 4. Schalten Sie die Verfügbarkeitsgruppe für die SQL Server-Instanz des DR-Knotens online. Achtung: Wenn das Replikat mit dem asynchronen Modus konfiguriert wurde, kann die Wiederaufnahme des Betriebs bei noch nicht gesendeten Protokolldatensätzen zu einem Datenverlust führen. Bevor Sie den Betrieb wiederherstellen, sollten Sie sich über die Auswirkungen dieses Schritts vollständig im Klaren sein. Weitere Informationen zu den Risiken, die die Wiederherstellung auf Replikaten mit asynchronem Modus mit sich bringt, finden Sie unter Ausführen eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe. Wenn die Notwendigkeit, die festgelegte Wiederanlaufdauer (RTO) einzuhalten und das Rechenzentrum wieder in Betrieb zu nehmen, das Risiko eines Datenverlusts überwiegt, führen Sie die folgende Transact-SQL-Syntax für die SQL Server-DR-Instanz aus, um ein Failover zu erzwingen (in diesem Beispiel ist EMU-AG1 der Name der Verfügbarkeitsgruppe). ALTER AVAILABILITY GROUP [EMU-AG1] FORCE_FAILOVER_ALLOW_DATA_LOSS; Jetzt sollten die Datenbanken innerhalb der Verfügbarkeitsgruppe verfügbar sein. Sie sollten noch einmal sicherstellen, dass keine eingehenden Verbindungsanforderungen an das vorherige primäre Replikat gerichtet sind bzw. dass das primäre Replikat vollständig getrennt ist. Neue Verbindungen mit dem Verfügbarkeitsgruppenlistener (der wieder online sein sollte) sollten automatisch an die DR-Instanz weitergeleitet werden. Außerdem müssen Sie sicherstellen, dass die Anwendungen keine Verbindungen mehr mit dem primären Rechenzentrum herstellen, um eine "Split-Brain"-Situation zu vermeiden. Auch nachdem Sie das Quorum im DR-Rechenzentrum neu erstellt haben, werden in SQL Server Management Studio weiterhin Warnmeldungen zu nicht erreichbaren Knoten im primären Rechenzentrum angezeigt. Abbildung 9 zeigt ein Beispiel, in dem der Objekt-Explorer und das AlwaysOn-Gruppendashboard dargestellt sind. 23 Abbildung 9: SQL Server Management Studio nach erzwungenem Failover Wie bereits oben in diesem Whitepaper erwähnt, sind die Aufgaben in den meisten großen Unternehmensumgebungen nach Zuständigkeit unterteilt, z. B. Datenbankadministrator, Windows Server-(oder Cluster-)Administrator und Netzwerkadministrator. Tabelle 3 greift den oben beschriebenen Workflow zur Notfallwiederherstellung erneut auf, um zu erläutern, welche Aufgaben aus Planungssicht in die verschiedenen Zuständigkeiten fallen. Schritt Datenbankadministrator Bestätigen Sie den aktuellen Status des primären Rechenzentrums und des verbleibenden DR-Knotens des WSFCClusters; Koordinieren aller Maßnahmen. Erzwingen Sie den Quorumdienst auf dem DR-Knoten. Ja Entziehen Sie den primären Knoten Stimmen, und weisen Sie dem DR-Knoten eine Stimme zu. Erzwingen Sie ein Failover der Verfügbarkeitsgruppe auf die SQL ServerDR-Instanz. Ja Ja Ja Tabelle 3: Notfallwiederherstellung nach Aufgabengebiet unterteilt 24 Windows Server-/Clusteradministrator Ja Netzwerkadministrator Ja Wiederinbetriebnahme des primären Rechenzentrums In dem hier beschriebenen Szenario wird vorausgesetzt, dass der Betrieb am DR-Standort nur für die Dauer des Ausfalls zum Abarbeiten der Arbeitslast wiederaufgenommen wird. Das Ziel sollte es sein, die Produktionsarbeitslast nach der Wiederherstellung wieder an den primären Standort zurückzuverlegen. Ein Ausfallszenario kann unterschiedliche Formen annehmen. Das gleiche gilt auch für die Wiederherstellung. In dem hier beschriebenen Szenario wird von einem Notfall ausgegangen, bei dem die Server des primären Rechenzentrums über eine längere Zeit außer Betrieb sind. Nachdem die Probleme mit dem primären Rechenzentrum behoben wurden und die Knoten im primären Rechenzentrum wieder hochgefahren sind, versuchen die Knoten, eine Verbindung mit dem WSFC-Cluster herzustellen. Sobald die Verbindung mit dem WSFC-Cluster wiederhergestellt ist und die Clusterdienste ausgeführt werden, sollten die auf dem DR-Knoten zugewiesenen "NodeWeight"-Einstellungen wirksam sein. Bei diesem Szenario wird außerdem vorausgesetzt, dass die ursprünglichen SQL Server-Installationen und die zugehörigen Datenbanken weiterhin intakt sind. An diesem Punkt sollten Sie überlegen, ob Daten gerettet werden müssen (das bezieht sich auf Datenänderungen auf dem ursprünglichen primären Replikat, die nicht rechtzeitig vor dem Notfall an das DR-Replikat gesendet wurden), oder ob Sie mit der Wiederherstellung aller Replikatsitzungen fortfahren. Die Replikate auf den ausgefallenen Knoten weisen nach einem erzwungenen Failover den Status "Synchronisierung wird nicht ausgeführt" und das DR-Replikat den Status "Synchronisiert" auf (vgl. Abbildung 10). 25 Abbildung 10 Datenbankstatus der Replikate, bevor der Systembetrieb im primären Rechenzentrum wiederaufgenommen wird Eine Methode, die Daten vom ursprünglichen primären Replikat zu retten, besteht darin, eine Datenbankmomentaufnahme der angehaltenen sekundären Datenbank (ursprünglich die primäre Datenbank) zu erstellen, um die erforderlichen Daten zu extrahieren und anhand der DR-Replikatversion der Verfügbarkeitsdatenbanken erneut zu synchronisieren. Das folgende Beispiel zeigt, wie eine Datenbankmomentaufnahme auf einer Verfügbarkeitsdatenbank mit dem Status "Synchronisierung wird nicht ausgeführt" erstellt wird. -- Datenbankmomentaufnahme erstellen CREATE DATABASE AppDB_A1 ON (NAME = AppDB, FILENAME = 'S:\Data\AppDB_A1.ss' ) AS SNAPSHOT OF AppDB; GO Da die DR-Datenbank im ursprünglichen Szenario im asynchronen Modus verwendet wurde, wird davon ausgegangen, dass der Wiederanlaufzeitpunkt (Recovery Point Objective, RPO) Datenverluste bis zu einem gewissen Grad toleriert. In den nächsten Schritten wird vorausgesetzt, dass der Betrieb anhand der bestehenden Replikate des primären Rechenzentrums wiederaufgenommen wird: 1. Sie beginnen mit der kontrollierten Rückmigration zum primären Rechenzentrum, indem Sie das Quorummodell entsprechend (d. h. in "Knoten- und Dateifreigabemehrheit") ändern und dann die Stimmen neu zuweisen. 2. Nachdem sichergestellt wurde, dass die SQL Server-Instanzen des primären Rechenzentrums gestartet wurden, führen Sie auf jeder SQL Server-Instanz im primären Rechenzentrum die folgende Transact-SQL-Syntax im Kontext der master-Datenbank aus, um den Betrieb jeder Datenbank in der Verfügbarkeitsgruppe wiederaufzunehmen. USE [master] GO ALTER DATABASE AppDB SET HADR RESUME; GO ALTER DATABASE ConfigDB SET HADR RESUME; GO ALTER DATABASE SecurityDB SET HADR RESUME; GO 26 3. Ändern Sie die Verfügbarkeitsgruppe, sodass sie vorübergehend den Verfügbarkeitsmodus mit synchronem Commit verwendet, um vor dem Failover eine Synchronisierung durchzuführen. Der Transact-SQL-Befehl lautet wie folgt (er wird für das aktuelle primäre Replikat im DRRechenzentrum ausgeführt, wobei EMU-AG1 in diesem Beispiel die Verfügbarkeitsgruppe und EMU-SQL3 das Replikat des DR-Rechenzentrums ist). Vorzugsweise sollte die Einstellung für synchrone Commits zu weniger aktiven Zeiten vorgenommen werden, um die Transaktionslatenz gering zu halten. USE [master] GO ALTER AVAILABILITY GROUP [EMU-AG1] MODIFY REPLICA ON N'EMU-SQL3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT); GO 4. Bestätigen Sie den Synchronisierungsstatus zwischen den beiden Standorten (der Status aller Replikate sollte "Fehlerfrei" lauten, bevor Sie zum nächsten Schritt übergehen, d. h., dass die Replikate synchronisiert sind). SELECT role_desc, synchronization_health_desc FROM sys.dm_hadr_availability_replica_states; 5. Führen Sie ein Failover von der Verfügbarkeitsgruppe (AG) des Knotens im DR-Rechenzentrum auf den Knoten im primären Rechenzentrum aus (d. h., Sie stellen eine Verbindung her und führen das folgende Skript für den Knoten des primären Rechenzentrums aus, der zum neuen primären Replikat wird). ALTER AVAILABILITY GROUP [EMU-AG1] FAILOVER; 6. Um die ursprüngliche Bereitstellung wiederherzustellen, aktivieren Sie für den Knoten des DRReplikats wieder asynchrone Commits. Führen Sie den folgenden Transact-SQL-Befehl für das neue primäre Replikat aus. EMU-SQL3 ist dabei der Name des DR-Replikats und EMU-AG1 der Name der Verfügbarkeitsgruppe. USE [master] GO ALTER AVAILABILITY GROUP [EMU-AG1] MODIFY REPLICA ON N'EMU-SQL3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT); GO 7. Entziehen Sie dem WSFC-Knoten im DR-Rechenzentrum die Quorumsstimme. In der folgenden Tabelle wird der oben beschriebene Workflow zur Notfallwiederherstellung erneut aufgegriffen, um zu erläutern, welche Aufgaben aus Planungssicht in die verschiedenen Zuständigkeiten fallen. 27 Schritt 1. Nach der Wiederinbetriebnahme des primären Rechenzentrums ändern Sie das Quorummodell entsprechend. Geben Sie den Knoten des primären Rechenzentrums ihre Quorumsstimmen wieder zurück. 2. Stellen Sie die Verfügbarkeitsdatenbanksitzungen auf den einzelnen sekundären Replikaten wieder her. 3. Aktivieren Sie für das DR-Replikat den Modus für synchrone Commits. 4. Bestätigen Sie den Synchronisierungsstatus zwischen den beiden Standorten (der Status aller Replikate sollte "Fehlerfrei" lauten, bevor Sie zum nächsten Schritt übergehen). 5. Führen Sie ein Failover auf ein Replikat im primären Rechenzentrum aus. 6. Stellen Sie den asynchronen Commitmodus für das DR-Replikat (gemäß Originalkonfiguration) wieder her. 7. Entziehen Sie dem Knoten im DRRechenzentrum die Quorumsstimme. DatenbankWindows administrator Server-/Clusteradministrator Ja Netzwerkadministrator Ja Ja Ja Ja Ja Ja Tabelle 4: Wiederinbetriebnahme des primären Rechenzentrums Schlussfolgerung SQL Server 2012 AlwaysOn bietet mehrere Optionen zum Umsetzen von HA (High Availability)- und DR (Disaster Recovery)-Lösungen. Dieses Whitepaper beschreibt eine Lösung, die HA und DR auf der Basis von Verfügbarkeitsgruppen erzielt. Die Lösung basiert ausschließlich auf nicht freigegebenem Speicher, da jede SQL Server-Instanz in der Topologie über einen eigenen Satz an Daten verfügt und keinen Speicher gemeinsam nutzen muss. Sie können diese Lösung verwenden, um ältere Topologien zu ersetzen, die auf Datenbankspiegelung und Protokollversand basieren. Der Erfolg einer solchen HA/DR-Lösung hängt vom Einsatz eines DBA-Teams und der engen Kooperation zwischen DBA-Team, Windows Server-Administratorteam und Netzwerkteam ab. Die fachübergreifenden Kompetenzen bringen die Bereitstellung einer HA-/DR-Lösung entscheidend voran. Referenzmaterial 28 SQL Server 2012 AlwaysOn-Entwurfsmuster für Hochverfügbarkeit und Notfallwiederherstellung (http://go.microsoft.com/fwlink/?LinkId=255048) Microsoft SQL Server AlwaysOn-Lösungen für Hochverfügbarkeit und Notfallwiederherstellung (http://msdn.microsoft.com/library/hh781257.aspx) Übersicht über AlwaysOn-Verfügbarkeitsgruppen (http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx) Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (http://technet.microsoft.com/library/ff878487(v=sql.110).aspx) Schrittweise Anleitung für Failovercluster: Konfigurieren des Quorums in einem Failovercluster (http://technet.microsoft.com/library/cc770620(v=WS.10).aspx) Windows Server-Hotfix für Quorumsstimmen (http://support.microsoft.com/kb/2494036) Windows PowerShell (http://technet.microsoft.com/library/bb978526) Zuordnen von Cluster.exe-Befehlen zu Windows PowerShell-Cmdlets für Failovercluster (http://technet.microsoft.com/library/ee619744(v=WS.10).aspx) Windows PowerShell Survival-Guide (http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survivalguide-en-us.aspx) Failovercluster-Cmdlets in Windows PowerShell (http://technet.microsoft.com/library/ee461009.aspx) SQL Server-PowerShell (http://msdn.microsoft.com/de-de/library/hh245198.aspx) Anhang A: HA/DR-Beispiel mit Verfügbarkeitsgruppen und 3 Rechenzentren Die in diesem Whitepaper beschriebene Architektur basiert auf zwei Rechenzentren und ist somit einer gängigen Bereitstellungstopologie nachempfunden. Es gibt jedoch Situationen, in denen Kunden ein drittes Rechenzentrum in die Architektur einbinden. Meistens wird mit einer solchen Lösung bezweckt, ein automatisches Failover der Verfügbarkeitsgruppe zwischen dem primären und dem DR-Rechenzentrum zu ermöglichen. Ein Ansatz besteht darin, die beiden Replikate in den beiden Rechenzentren und einen Dateifreigabezeugen im dritten Rechenzentrum bereitzustellen (vgl. Abbildung 11). 3. Rechenzentrum STIMME Primäres Rechenzentrum Dateifreigabe DR-Rechenzentrum Windows Server-Failovercluster SQL Server STIMME STIMME Sekundär Primär Synchron Verfügbarkeitsgruppe Abbildung 11: HA/DR-Lösung mit Verfügbarkeitsgruppen und drei Rechenzentren 29 SQL Server Weitere Informationen: http://www.microsoft.com/sqlserver/: SQL Server-Website http://technet.microsoft.com/de-de/sqlserver/: SQL Server TechCenter http://msdn.microsoft.com/de-de/sqlserver/: SQL Server DevCenter War dieses Dokument hilfreich? Geben Sie uns Ihr Feedback. Bewerten Sie dieses Dokument auf einer Skala von 1 (schlecht) bis 5 (ausgezeichnet), und begründen Sie Ihre Bewertung. Beispiel: Bewerten Sie es hoch aufgrund guter Beispiele, ausgezeichneter Screenshots, klarer Formulierungen oder aus einem anderen Grund? Bewerten Sie es niedrig aufgrund schlechter Beispiele, ungenauer Screenshots oder unklarer Formulierungen? Dieses Feedback hilft uns, die Qualität von veröffentlichten Whitepapers zu verbessern. Feedback senden 30
