SQL Server 2012 AlwaysOn-Verfügbarkeitsgruppen
Werbung
AlwaysOn-Architektur: Erstellen einer Hochverfügbarkeits- und Notfallwiederherstellungslösung unter Verwendung von Failoverclusterinstanzen und Verfügbarkeitsgruppen Technischer Artikel zu SQL Server Autoren: Joseph Sack (SQLskills.com), Sanjay Mishra (Microsoft) Technische Bearbeiter: Min He (Microsoft), Chuck Heinzelman (Microsoft), Alexi Khalyako (Microsoft), Charles Mathews (Microsoft), Prem Mehra (Microsoft), Juergen Thomas (Microsoft), Mike Weiner (Microsoft), Amitabh Tamhane (Microsoft), Brent Ozar (Brent Ozar PLF), Gianluca Hotz (SolidQ), David P. Smith (ServiceU), Michael Steineke (Edgenet), Glenn Berry (SQLskills.com) Content Program Manager: Glenn Minch (Microsoft) Veröffentlicht: Juni 2012 Betrifft: SQL Server 2012 Zusammenfassung: SQL Server 2012 AlwaysOn-Failoverclusterinstanzen (FCI) und AlwaysOn-Verfügbarkeitsgruppen bieten eine umfassende Lösung für Hochverfügbarkeit und Notfallwiederherstellung. Vor SQL Server 2012 setzten viele Kunden FCIs ein, um Hochverfügbarkeit (High Availability, HA) für ihr lokales Rechenzentrum zu implementieren, und die Datenbankspiegelung, um die Notfallwiederherstellung in einem Remoterechenzentrum zu ermöglichen. Ab SQL Server 2012 kann dieses Entwurfsmodell von einer Architektur abgelöst werden, die FCIs für Hochverfügbarkeit und Verfügbarkeitsgruppen als Notfallwiederherstellungsstrategie einsetzt. Verfügbarkeitsgruppen nutzen die Windows Server Failover Clustering (WSFC)-Funktionalität und unterstützen eine Reihe von Merkmalen, die in der Datenbankspiegelung nicht verfügbar sind. In diesem Whitepaper werden die wesentlichen Topologieanforderungen dieses Entwurfsmusters erörtert, einschließlich Überlegungen zu asymmetrischem Speicher, Auswahl des Quorummodells, Quorumsstimmen, erforderlichen Schritten zum Einrichten der Umgebung und eines exemplarischen Notfallwiederherstellungsereignisses für unterschiedliche Administratorrollen auf der Basis 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 FCIs für lokale HA und Datenbankspiegelung für DR .................................................................................... 4 FCIs für lokale HA und Verfügbarkeitsgruppen für DR ................................................................................. 5 Planung und Vorüberlegungen ..................................................................................................................... 7 Anforderungen an Windows Server-Failovercluster ................................................................................ 7 Asymmetrischer Speicher ......................................................................................................................... 7 Instanznamen und Dateipfad.................................................................................................................... 7 Verfügbarkeits- und Failovermodus ......................................................................................................... 8 Quorummodell und Knotenstimmen........................................................................................................ 8 Tools zur Anzeige und zum Ändern von Quorummodell und Knotenstimmen .................................. 11 Konfigurieren des WSFC-Quorummodells .......................................................................................... 11 Verwenden von DMVs und AlwaysOn-Dashboard zum Anzeigen von Quoruminformationen ......... 12 Konfigurieren von Knotenstimmen..................................................................................................... 13 Clientkonnektivität.................................................................................................................................. 14 Lese-/Schreibarbeitslasten.................................................................................................................. 14 Leseoperationen ................................................................................................................................. 14 Unterstützung für Multisubnetz-Verbindungen ................................................................................. 15 Konfigurieren der FCI+AG-Lösung............................................................................................................... 15 Installationsvoraussetzungen ................................................................................................................. 15 Einrichten der Lösung im primären Rechenzentrum .............................................................................. 16 Einrichten der Lösung im DR-Rechenzentrum ........................................................................................ 21 Überlegungen zur Überwachung ................................................................................................................ 25 Wiederherstellung nach einem Notfall....................................................................................................... 26 Wiederinbetriebnahme des primären Rechenzentrums ............................................................................ 32 Schlussfolgerung ......................................................................................................................................... 36 Referenzmaterial ........................................................................................................................................ 37 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). Weitere Informationen zu den SQL Server 2012 AlwaysOn-Entwurfsmustern für HA und DR finden Sie unter SQL Server 2012 AlwaysOn-Entwurfsmuster für Hochverfügbarkeit und Notfallwiederherstellung. Dieses Whitepaper beschreibt eine Lösung, die Failoverclusterinstanzen (FCI) zur Erreichung der HA-Ziele und Verfügbarkeitsgruppen (Availability Groups, AG) als DR-Strategie einsetzt. Die zugrunde liegende Architektur vereint eine Lösung mit freigegebenem Speicher (FCI) und eine Lösung mit nicht freigegebenem Speicher (AG). Vor SQL Server 2012 basierte eine gängige HA- und DR-Architektur auf folgendem Konzept: FCIs für lokale Hochverfügbarkeit und Datenbankspiegelung (Database Mirroring, DBM) für die RemoteNotfallwiederherstellung. Ab SQL Server 2012 können Verfügbarkeitsgruppen die Datenbankspiegelung in einem solchen Modell ablösen. Neben Überlegungen zur Planung dokumentiert dieses Whitepaper die einzelnen Schritte zum Erstellen der Lösung. Darüber hinaus enthält es die Schritte zur Notfallwiederherstellung und erläutert, wie der Betrieb des primären Rechenzentrums nach der Wiederherstellung wiederaufgenommen wird. Zum besseren Verständnis werden grundlegende Kenntnisse über Failoverclusterinstanzen (FCIs), Verfügbarkeitsgruppen, Hochverfügbarkeit und Notfallwiederherstellung vorausgesetzt. 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. Weitere Informationen zu den Migrationsschritten finden Sie im Whitepaper Migration: Migrieren zu SQL Server 2012-Failoverclustering und -Verfügbarkeitsgruppen von vorherigen Clustering- und Spiegelungsbereitstellungen. Dieses Whitepaper richtet sich an Administratoren und Technologiearchitekten operationaler SQL Server-Datenbanken. Auch Systemadministratoren, die gemeinsam mit Datenbankadministratoren Windows Server, Windows Active Directory-Domänendienste, WSFC und Netzwerkdienste verwalten, profitieren von diesem Whitepaper. FCIs für lokale HA und Datenbankspiegelung für DR Wie bereits in der Einführung erwähnt, basierte eine gängige SQL Server-Bereitstellungsarchitektur vor SQL Server 2012 auf folgendem Konzept: FCIs für lokale Hochverfügbarkeit und Datenbankspiegelung für die Notfallwiederherstellung zwischen Rechenzentren. Diese Lösung wurde als FCI+DBM bezeichnet. Dabei wird eine FCI innerhalb des primären Rechenzentrums konfiguriert, die freigegebenen Festplattenspeicher (z. B. SAN) verwendet, um Schutz auf SQL Server-Instanzebene zu gewährleisten. Bei einem Hardwareausfall auf einem der Knoten kann innerhalb desselben Rechenzentrums ein anderer Knoten als Host der FCI einspringen. Die Datenbankspiegelung wird zwischen dem primären Standort und dem Notfallwiederherstellungsstandort verwendet, um Schutz auf Datenbankebene zu gewährleisten. Sollte ein primäres Rechenzentrum ausfallen oder der freigegebene Speicher im primären Rechenzentrum beschädigt sein, kann der Betrieb der Anwendungen aufrechterhalten werden, indem die Spiegelung aus dem DR (Data Recovery)-Rechenzentrum verwendet wird. Das DR-Rechenzentrum hostet eine weitere FCI auf einem separaten WSFC, der über eigenen freigegebenen Speicher verfügt. Die Architektur dieser Lösung wird in Abbildung 1 veranschaulicht. 4 Primäres Rechenzentrum Rechenzentrum für Notfallwiederherstellung Windows Windows Server-Failovercluster Server-Failovercluster "B" "A" Windows Server-Failovercluster "A" SQLFCIPrimary\INST_A SQLFCIDR\INST_A Datenbankspiegelung Prinzipaldatenbank Spiegeldatenbank Abbildung 1: FCI für HA und Datenbankspiegelung für DR Normalerweise liegt das DR-Rechenzentrum geografisch entfernt vom primären Rechenzentrum. Für die Spiegelungssitzung wird der hochperformante, asynchrone Modus verwendet, um den Transaktionsoverhead auf ein Minimum zu reduzieren. Zeitweise ist auch eine synchrone Datenbankspiegelung zwischen Rechenzentren zu beobachten. Weitere Informationen und ein Praxisbeispiel dieser spezifischen Lösung finden Sie unter Hochverfügbarkeit und Notfallwiederherstellung bei ServiceU: eine technische SQL Server 2008-Fallstudie. FCIs für lokale HA und Verfügbarkeitsgruppen für DR SQL Server 2012 unterstützt eine ähnliche Lösung, bei der FCIs für lokale Hochverfügbarkeit eingesetzt werden (wie bei der FCI+DBM-Lösung). Die Notfallwiederherstellung übernehmen jedoch Verfügbarkeitsgruppen (Availability Groups, AG). Diese Lösung wird als FCI+AG bezeichnet. Abbildung 2 zeigt die Lösung, in der FCIs für lokale Hochverfügbarkeit und Verfügbarkeitsgruppen für die Notfallwiederherstellung zwischen Rechenzentren verwendet werden. Abbildung 2: FCIs für HA und Verfügbarkeitsgruppen für DR 5 Abbildung 2 zeigt die beiden FCIs – eine im primären Rechenzentrum und die andere im DRRechenzentrum. Jede FCI verfügt über zwei Knoten und eigenen freigegebenen Speicher. Alle vier Knoten sind jedoch Teil desselben WSFC-Clusters. Bei Verfügbarkeitsgruppen wird vorausgesetzt, dass alle Knoten demselben WSFC-Cluster angehören. Abbildung 2 zeigt eine einfache Szenariotopologie mit zwei Rechenzentren, von denen jedes ein AGReplikat auf einer aus zwei Knoten bestehenden FCI hostet. Die Architektur lässt auch Abwandlungen dieser Topologie zu: Mehrere Rechenzentren Mehrere Replikate (bis zu fünf), bestehend aus einem primären Replikat und ein bis vier sekundären Replikaten Mehr als zwei Knoten in jeder FCI, falls aus HA-Gründen zusätzliche passive Knoten erforderlich sind Nicht alle Replikate in einer Verfügbarkeitsgruppe müssen sich auf FCI-Instanzen befinden; einige Replikate können auf eigenständigen SQL Server-Instanzen außerhalb einer FCI gespeichert sein Mehrere Verfügbarkeitsgruppen, die auf einer logischen Gruppierung von Datenbanken für die Anwendungsumgebung basieren 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. Da die vier, auf zwei Standorte verteilten Knoten demselben WSFC-Cluster angehören, sind bei der Nutzung freigegebenen Speichers, der nur für die lokalen Rechenzentrumsknoten sichtbar ist, zusätzliche Gesichtspunkte zu berücksichtigen. Besonderes Augenmerk erfordern auch die Quorumabstimmung und das Quorummodell. Diese und weitere Überlegungen werden in diesem Whitepaper erörtert. Die Verfügbarkeitsgruppe kann mit einer oder mehreren Benutzerdatenbanken konfiguriert werden und die synchrone oder asynchrone Datenverschiebung nutzen. Synchrone Replikate verursachen eine höhere Latenz bei Datenbanktransaktionen, da das primäre Replikat eine Bestätigung anfordert, dass Protokolldatensätze in den Protokollen des sekundären Replikats festgeschrieben wurden, bevor ein Commit für die Transaktion ausgeführt wird. Es ist auch darauf hinzuweisen, dass die zur Notfallwiederherstellung verwendete SQL Server-Instanz keine FCI sein muss. Eine Verfügbarkeitsgruppe kann auch über eine eigenständige SQL Server-Instanz als sekundäres Replikat verfügen. Bei Verfügbarkeitsgruppen können eigenständige Instanzen und FCIs innerhalb einer Topologie auf demselben WSFC-Cluster kombiniert werden. Abbildung 3 zeigt eine Mischtopologie. Primäres Rechenzentrum Rechenzentrum für Notfallwiederherstellung Windows Server-Failovercluster SQLFCIPrimary\INST_A SQLDR\INST_B Verfügbarkeits gruppe Primäre Datenbank(en) Sekundäre Datenbank(en) Abbildung 3: FCI für lokale HA und Verfügbarkeitsgruppen für DR (die DR-Instanz ist eine eigenständige Instanz) 6 Im weiteren Verlauf des Whitepapers wird davon ausgegangen, dass sowohl das primäre als auch das sekundäre Replikat gehostete FCIs und keine eigenständigen Instanzen sind. Planung und Vorüberlegungen Dieser Abschnitt enthält die detaillierten Planungsüberlegungen, Anforderungen und Voraussetzungen, die vor der Implementierung einer FCI+AG-Lösung für Hochverfügbarkeit und Notfallwiederherstellung zu berücksichtigen sind. Anforderungen an Windows Server-Failovercluster Ein grundlegender Unterschied zwischen einer FCI+DBM-Lösung und einer FCI+AG-Lösung besteht darin, dass anstelle von zwei FCIs auf zwei separaten WSFC-Clustern zwei FCIs in einem einzigen WSFC-Cluster verwendet werden. Alle Replikate für eine Verfügbarkeitsgruppe müssen sich auf einem einzigen WSFCCluster innerhalb einer einzigen Active Directory-Domäne befinden. Dies gilt auch für den Einsatz mehrerer Rechenzentren. Asymmetrischer Speicher Zwei FCIs, von denen sich jede an einem Standort eines standortübergreifenden WSFC-Clusters befindet, stellen besondere Anforderungen an die Nutzung freigegebenen Speichers. Jede FCI verfügt über eigenen freigegebenen Speicher. Die Knoten des primären Standorts nutzen den Speicher gemeinsam und bilden so eine FCI mit freigegebenem Speicher; das gleiche gilt für die Knoten am DR-Standort, die somit eine weitere FCI mit freigegebenem Speicher etablieren. Der Speicher am primären Standort ist für die Knoten am DR-Standort nicht sichtbar und umgekehrt. Diese Speicherkonfiguration, bei der ein Clusterdatenträger von einem Teil der Knoten in einem WSFC-Cluster gemeinsam verwendet wird, bezeichnet man als asymmetrischen Speicher. Vor der Einführung der asymmetrischen Speicherfunktion musste freigegebener Speicher für alle Knoten im WSFC-Cluster sichtbar sein (symmetrischer Speicher). Asymmetrischer Speicher wurde erstmals als Hotfix für Windows Server 2008 eingeführt. Asymmetrischer Speicher wird auch in Windows Server 2008 R2 über Service Pack 1 unterstützt. Weitere Informationen zu diesem Hotfix finden Sie im Knowledge Base-Artikel Hotfix zum Hinzufügen der Unterstützung für asymmetrische Speicher zum MMC-Failovercluster-Verwaltungs-Snap-in für einen Failovercluster, der unter Windows Server 2008 oder Windows Server 2008 R2 ausgeführt wird. Diese Windows Server-Erweiterung ist die Hauptfunktionalität, die die Architektur der hier beschriebenen FCI+AG-Lösung möglich macht. Dank dieser Funktionalität können Sie die Lösung für freigegebenen Speicher (FCI) mit der Lösung für nicht freigegebenen Speicher (Verfügbarkeitsgruppen) in einer HA+DR-Lösung kombinieren. Darüber hinaus sind Sie in der Lage, identische Laufwerkbuchstaben für freigegebene Datenträgerressourcen in mehreren Rechenzentren zuzuordnen. Wenn Sie den asymmetrischen Speicher konfigurieren, wird während der WSFC-Validierungstests möglicherweise die folgende Meldung angezeigt: "Der Datenträger mit der ID XYZ ist nur für eine Teilmenge von Knoten sichtbar oder clusterfähig". Dies entspricht dem erwarteten Verhalten für asymmetrischen Speicher und ist kein Grund zur Besorgnis. Instanznamen und Dateipfad Die beiden FCIs müssen innerhalb desselben WSFC-Clusters unterschiedliche Instanznamen verwenden, beispielsweise "INST_A" als Instanzname für die primäre FCI und "INST_B" als Instanzname für die DR-FCI. (Im Gegensatz zu Verfügbarkeitsgruppen erlaubt die Datenbankspiegelung die Verwendung gleicher Instanznamen, sofern sich die einzelnen FCIs auf separaten WSFC-Clustern befinden. In Abbildung 1 verwenden beide FCIs den Instanznamen "INST_A" bei der FCI+DBM-Lösung.) 7 Jede FCI verfügt über eigenen freigegebenen Speicher, auf den die Knoten des anderen Rechenzentrums keinen Zugriff haben. Die FCIs sollten beide identische Laufwerkbuchstaben für die Datenträger sowie identische Dateipfade für Datenbankdateien und Transaktionsprotokolldateien verwenden. Grundsätzlich sind identische Dateipfade und identische Laufwerkbuchstaben kein absolutes Erfordernis. Sollten die Dateipfade jedoch voneinander abweichen, müssen Sie manuell einen RESTORE WITH MOVE-Befehl ausführen, wenn Sie die Replikatdatenbanken auf dem sekundären Replikat wiederherstellen. Darüber hinaus können heterogene Pfade dazu führen, dass Dateien, die später beim Erstellen von Dateigruppen, sekundären Protokollen oder Datendateien hinzugefügt werden, als ungültig angesehen werden. Weitere Informationen, darunter ein Problemszenario mit Lösungsvorschlag, finden Sie unter Problembehandlung bei einem fehlgeschlagenen Vorgang zum Hinzufügen einer Datei (AlwaysOn-Verfügbarkeitsgruppen). Verfügbarkeits- und Failovermodus Für die Verfügbarkeitsgruppe, die zwischen den beiden FCIs erstellt wird, können Sie zwei Modi festlegen: synchrone oder asynchrone Commits. Wenn der Verfügbarkeitsmodus synchron ist, wartet das primäre Replikat mit dem Commit der Benutzertransaktionen, bis diese an die sekundären Replikate gesendet und dort festgeschrieben wurden. Das kann die Latenz bei Benutzertransaktionen zwar erhöhen, beseitigt jedoch auch das Risiko von Datenverlusten auf dem sekundären Replikat, indem sichergestellt wird, dass Transaktionen an die DR-FCI gesendet werden, bevor für die Transaktion auf dem primären Replikat ein Commit signalisiert wird. Wenn der Verfügbarkeitsmodus asynchron ist, warten die Benutzertransaktionen auf dem primären Replikat nicht, bis Transaktionen in den Protokollen des sekundären Replikats festgeschrieben wurden. Das verringert zwar die Latenz von Transaktionen, erhöht gleichzeitig jedoch das Risiko eines Datenverlusts bei einem Ausfall. Wenn in der Verfügbarkeitsgruppentopologie FCIs verwendet werden, muss der Failovermodus der Verfügbarkeitsgruppen auf "Manuell" (nicht "Automatisch") eingestellt sein. Innerhalb der einzelnen FCIs erfolgt das FCI-Failover der SQL Server-Instanz auf andere Knoten jedoch automatisch. Quorummodell und Knotenstimmen Hinweis: Die Erläuterungen für Quorummodelle sowie verwandte Informationen beziehen sich in diesem Whitepaper auf Lösungen, die unter den Betriebssystemen Windows Server 2008 und Windows Server 2008 R2 mit entsprechenden Service Packs und weiteren Softwareupdates ausgeführt werden. Da die zugrunde liegende Infrastruktur der FCI+AG-Lösung ein WSFC-Cluster ist, 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 FCIs, Replikate und Verfügbarkeitsgruppen, die im WSFC-Cluster gehostet werden. In WSFC gibt es vier Quorummodelle: Knotenmehrheit, Knoten- und Dateifreigabemehrheit, Knoten- und Datenträgermehrheit, Keine Mehrheit: Nur Datenträger. Weitere Informationen zu Quorummodellen finden Sie unter Schrittweise Anleitung für Failovercluster: Konfigurieren des Quorums in einem Failovercluster. 8 Bevor Sie ein Quorummodell auswählen, müssen Sie die Anzahl der stimmberechtigten Knoten berücksichtigen. Das Zuweisen der Knotenstimmen nimmt einen wichtigen Teil im HA+DR-Entwurfsmodell ein. Standardmäßig verfügt jeder Knoten in einem Failovercluster ü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 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 NodeWeightEigenschaft 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 zur Quorumabstimmung für eine AlwaysOn-HA+DR-Lösung finden Sie unter Empfohlene Anpassungen an der Quorumabstimmung in der SQL Server-Onlinedokumentation. Diese sollten bei der Auswahl des Abstimmungsschemas für die AlwaysOn-Lösung als Richtschnur gelten. Wenn Sie anhand dieser Richtlinien sicherstellen möchten, dass das Quorum der Knoten im primären Rechenzentrum nicht durch Ausfälle im DR-Rechenzentrum oder Verbindungsunterbrechungen zwischen den beiden Rechenzentren beeinträchtigt wird, verwenden Sie für die in Abbildung 2 dargestellte FCI+AG-Lösung das folgende Abstimmungsschema: 1 Stimme für jeden Knoten im primären Rechenzentrum 0 Stimmen für jeden Knoten im DR-Rechenzentrum Diese Stimmenzuweisung ergibt insgesamt zwei Stimmen für den WSFC-Cluster. Es hat sich bewährt, für die Gesamtanzahl der Stimmen im WSFC-Cluster eine ungerade Zahl zu wählen. Fügen Sie bei einer geraden Anzahl stimmberechtigter Knoten (wie in der Beispieltopologie) ggf. einen Dateifreigabezeugen hinzu, und wählen Sie dann das Quorummodell "Knoten- und Dateifreigabemehrheit" aus. Hinweis: In vielen Unternehmensumgebungen ist es üblich, dass Besitz und Verwaltung einer Dateifreigabe in den Händen eines anderen Teams liegen. Die Kontrolle der Knotenstimme unterliegt dann diesem Team, das den Status des Failoverclusters somit beeinflussen kann. Eine Dateifreigabe zählt als eine Stimme und muss daher immer verfügbar sein. Um die Verfügbarkeit der Dateifreigabestimme sicherzustellen, werden Cluster- oder andere HA-Technologien empfohlen. Alternativ können Sie einen zusätzlichen Knoten hinzufügen und das Quorummodell "Knotenmehrheit" verwenden. Der zusätzliche Knoten muss sich zwar innerhalb des WSFC-Clusters befinden, aber nicht unbedingt der FCI-Konfiguration angehören. Er sollte demselben primären Rechenzentrum hinzugefügt werden, dem die beiden vorhandenen WSFC-Knoten bereits zugeordnet sind. Abbildung 4 zeigt die Stimmenzuweisung mithilfe des Quorummodells "Knoten- und Dateifreigabemehrheit". 9 Abbildung 4: FCI+AG HA/DR-Lösung mit zugewiesenen Knotenstimmen In Abbildung 4 verfügt jeder der beiden Knoten im primären Rechenzentrum über eine Stimme. Ein Dateifreigabezeuge wird ebenfalls im primären Rechenzentrum definiert und zählt als eine Stimme. Die beiden Knoten im DR-Rechenzentrum erhalten keine Stimme und haben keinen Einfluss auf das Quorum. Weitere Optionen für Quorummodelle in dieser Bereitstellungsarchitektur sind "Knoten- und Datenträgermehrheit" (asymmetrischer Datenträger) oder "Keine Mehrheit: Nur Datenträger" (asymmetrischer Datenträger). Vor der Einführung des asymmetrischen Speichers in einem WSFCCluster konnte ein freigegebener Datenträger als Quorumressource fungieren, sofern er für alle WSFCKnoten sichtbar war. Beim asymmetrischen Speicher kann der Clusterspeicher nur für einen Teil der Knoten sichtbar sein, aber trotzdem als Quorumressource verwendet werden. Beim asymmetrischen Quorummodell "Keine Mehrheit: Nur Datenträger" können Sie ein "Last Man Standing"-Szenario (der letzte bleibt stehen) implementieren. Dabei behält der WSFC-Cluster das Quorum so lange bei, wie ein einzelner Knoten Kontakt mit dem asymmetrischen Datenträger hat, der als Quorumressource auftritt. Diese Konfiguration können Sie über die Befehlszeile von "cluster.exe" vornehmen, über den Failovercluster-Manager oder Windows PowerShell ist dies jedoch nicht möglich. Ein Beispiel für diese Konfiguration finden Sie im Abschnitt Ändern der Quorumkonfiguration in einem Failovercluster mit asymmetrischem Speicher des Artikels Schrittweise Anleitung für Failovercluster: Konfigurieren des Quorums in einem Failovercluster. Wichtig: Die Verwendung eines asymmetrischen Datenträgers als Quorumressource bietet zahlreiche Vorteile, erfordert jedoch deutlich mehr Erfahrung mit Clustern und dem Planungsprozess. Bevor Sie diese Konfiguration in einer Produktionsumgebung bereitstellen, sollten Sie sich eingehend mit den Gesetzmäßigkeiten vertraut machen. 10 Bei einem Ausfall des primären Rechenzentrums, der die Fortführung des Betriebs im DR-Rechenzentrum erfordert, müssen Sie die Quorumkonfiguration neu bewerten. Jedem Knoten im DR-Rechenzentrum muss eine Stimme zugewiesen werden, und jedem Knoten im primären Rechenzentrum muss die Stimme bis zur Wiederherstellung des Betriebs entzogen (auf "0" gesetzt) werden. Wenn die FCI über zwei Knoten verfügt und ein längerer Ausfall des primären Rechenzentrums erwartet wird, sollten Sie außerdem einen Dateifreigabezeugen (bzw. eine zusätzliche Stimme) im DR-Rechenzentrum konfigurieren und das Quorummodell entsprechend festlegen. Nachdem das primäre Rechenzentrum wieder betriebsbereit ist, muss die Abstimmung erneut angepasst und das Quorummodell neu bewertet werden. An späterer Stelle in diesem Whitepaper begleiten wir Sie durch ein Notfallwiederherstellungsszenario und die zugehörigen Schritte. Beim Quorummodell und den Stimmenzuweisungen in Abbildung 4 wird von einer Lösung mit zwei Replikaten ausgegangen – jeweils einem in jedem der beiden Rechenzentren. 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 andere Stimmenzuweisungen in Betracht kommen. Tools zur Anzeige und zum Ändern von Quorummodell und Knotenstimmen Es gibt mehrere Methoden, das Clusterquorummodell und/oder die Quorumsstimmen anzuzeigen und zu ändern. In der folgenden Tabelle sind die verschiedenen Tools für diese Aufgaben aufgeführt. Anzeigen des Quorummodells Windows-Failovercluster-Manager Windows PowerShell Cluster.exe SQL Server-DMVs AlwaysOn-Dashboard in SQL Server Management Studio Ändern des Quorummodells Windows-Failovercluster-Manager Windows PowerShell Cluster.exe Hinweis: Um das Quorummodell auf "Knoten- und Datenträgermehrheit" (asymmetrisch) oder auf "Keine Mehrheit: nur Datenträger" (asymmetrisch) festzulegen, kann nur "Cluster.exe" verwendet werden. Anzeigen von Knotenstimmen Ändern von Knotenstimmen Windows PowerShell Cluster.exe SQL Server-DMVs AlwaysOn-Dashboard 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 \\FileShare\Witness 11 Die ausgewählte Zeugendateifreigabe darf sich nicht auf einem Knoten befinden, der bereits Teil der AlwaysOn-WSFC-Konfiguration ist. Sie 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 Konto, ü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 (http://technet.microsoft.com/dede/library/hh212952(v=sql.110).aspx) aus. SELECT FROM cluster_name, quorum_type_desc, quorum_state_desc sys.dm_hadr_cluster; Wenn Sie diese Abfrage für das hier beschriebene Beispiel ausführen, wird das folgende Resultset zurückgegeben: cluster_name -----------contosocluster 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 Sie diese Abfrage für das hier beschriebene Beispiel ausführen, wird das folgende Resultset zurückgegeben: Die Zuweisung von Stimmen wird in einem späteren Abschnitt erläutert. member_name -----------------PrimaryNode1 PrimaryNode2 DRNode1 DRNode2 Dateifreigabezeuge number_of_quorum_votes ---------------------1 1 0 0 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). 12 Abbildung 5: Anzeigen von Quorumsstimmen und Clusterstatus im AlwaysOn-Dashboard 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 stellt DRNode1 einen bestimmten WSFC-Knoten im DR-Rechenzentrum dar. 13 Anzeigen aktueller Einstellungen für alle Knotenstimmen Get-ClusterNode | fl NodeName, NodeWeight Festlegen der Stimme eines Knotens auf "0" (Get-ClusterNode "DRNode1").NodeWeight=0 Hinweis: Der Wert "0 " bedeutet, dass der Knoten keine Stimme hat. Der Wert "1" bedeutet, dass der Knoten eine Quorumsstimme hat. Clientkonnektivität FCI-Verbindungsmethoden in SQL Server 2012 sind identisch mit denen in den Vorgängerversionen; allerdings sind bei der Migration von der Datenbankspiegelung zu Verfügbarkeitsgruppen einige Änderungen zu berücksichtigen, bevor Sie die neuen lesbaren sekundären Replikate verwenden können. Weitere Informationen zur Migration, einschließlich fundierter Überlegungen und Arbeitsschritte, finden Sie unter Migration: Migrieren zu SQL Server 2012-Failoverclustering und -Verfügbarkeitsgruppen von vorherigen Clustering- und Spiegelungsbereitstellungen. Lese-/Schreibarbeitslasten Für Lese-/Schreibarbeitslasten, die für Verfügbarkeitsdatenbanken in einer Verfügbarkeitsgruppe ausgeführt werden, stehen Ihnen zwei Optionen zur Verfügung, um eine Verbindung mit dem primären Replikat herzustellen. Bei der ersten Option stellen Sie eine direkte Verbindung mit dem FCI-VNN (Virtual Network Name) her; jedes Replikat verfügt über einen eigenen FCI-VNN. Bei der zweiten Option verwenden Sie den Namen des Verfügbarkeitsgruppenlisteners. Der Verfügbarkeitsgruppenlistener ist die bevorzugte Methode, weil er für Transparenz und die automatische Umleitung an das aktuelle primäre Replikat sorgt. Darüber hinaus bleibt der Name in der Verbindungszeichenfolge für alle Instanzen gleich. Der Verfügbarkeitsgruppenlistener ist ein VNN, der an mindestens eine TCP/IP-Adresse und mindestens einen Listenerport gebunden ist und eine automatische Verbindung mit einem beliebigen Replikat herstellt, ohne dass jedes mögliche Verfügbarkeitsgruppenreplikat in der Verbindungszeichenfolge explizit angegeben werden muss. Wenn Sie Verbindungen für Lese-/Schreibarbeitslasten von einer Datenbankspiegelungs-Lösung, die das "Failoverpartner"-Attribut verwendet, migrieren, können Sie die Verbindungszeichenfolge der Datenbankspiegelung weiterhin verwenden. Dies gilt jedoch nur, wenn die Verfügbarkeitsgruppe mit einem einzigen sekundären Replikat konfiguriert ist, das für Lese-Schreibaktivitäten eingerichtet ist. Anschließend können Sie den Namen des ursprünglichen primären Replikatservers als Datenquelle und den Namen des sekundären Replikats (optional) als Failoverpartner verwenden. Dies ist jedoch nur als vorübergehende Lösung gedacht. Leseoperationen Bei Verbindungen für Leseoperationen stehen Ihnen ebenfalls zwei Optionen zur Verfügung. Sie können den FCI-VNN oder den Verfügbarkeitsgruppenlistener verwenden und das neue ApplicationIntentAttribut in der Verbindungszeichenfolge auf "ReadOnly" festlegen. 14 Wenn Sie die Verbindungszeichenfolge einer früheren Datenbankspiegelung verwenden, können Sie eine Verbindung mit der Verfügbarkeitsgruppe nur so lange herstellen, wie die Verfügbarkeitsgruppe als einziges sekundäres Replikat für Lese-/Schreibaktivitäten konfiguriert ist. Wenn Sie das Routing von Lesezugriffen nutzen möchten, müssen Sie den Namen des Verfügbarkeitsgruppenlisteners zusammen mit dem ApplicationIntent-Attribut und dem Wert "ReadOnly" verwenden. Darüber hinaus müssen Sie innerhalb der Verfügbarkeitsgruppe auf eine Verfügbarkeitsdatenbank verweisen. Die Verfügbarkeitsgruppe muss auch für das Routing von Lesezugriffen an lesbare sekundäre Replikate konfiguriert sein. Dazu werden URLs und Listen für das Routing von Lesezugriffen verwendet. Weitere Informationen zu diesem Verfahren finden Sie unter Konfigurieren des schreibgeschützten Routings für eine Verfügbarkeitsgruppe (SQL Server). Unterstützung für Multisubnetz-Verbindungen Der Verfügbarkeitsgruppenlistener kann auch das MultiSubnetFailover-Verbindungsattribut in Clientbibliotheken nutzen. Es wird empfohlen, in Verbindungszeichenfolgen für Verfügbarkeitsgruppen das MultiSubnetFailover-Attribut für Multisubnetz-Topologien festzulegen, wenn sie auf den Namen eines Verfügbarkeitsgruppenlisteners verweisen. Die MultiSubnetFailover-Verbindungsoption bietet Unterstützung für Multisubnetz-Verbindungen und öffnet TCP-Sockets für IP-Adressen des Verfügbarkeitsgruppenlisteners parallel. Bei älteren Clientbibliotheken, die das MultiSubnetFailoverAttribut nicht unterstützen, sollten Sie ein entsprechendes Timeout für die Clientanmeldung berücksichtigen. Weitere Informationen zu Clientverbindungen und zum Anwendungsfailover finden Sie unter Clientkonnektivität und Anwendungsfailover (AlwaysOn-Verfügbarkeitsgruppen) in der SQL ServerOnlinedokumentation. Konfigurieren der FCI+AG-Lösung In diesem Workflow werden die Schritte zur Erstellung der FCI+AG-Lösung beschrieben. 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 Schritte sind nach Aufgabengebiet gegliedert, da die Aufgaben in den meisten großen Unternehmensumgebungen nach Zuständigkeit unterteilt sind, z. B. Datenbankadministrator, Windows-(oder Cluster-)Administrator und Netzwerkadministrator. Aus diesem Grund müssen die Aktivitäten der verschiedenen Aufgabengebiete richtig kommuniziert und koordiniert werden. Installationsvoraussetzungen Bevor Sie die Lösung für AlwaysOn-Verfügbarkeitsgruppen bereitstellen, müssen Sie überprüfen, ob Ihr System die Anforderungen (einschließlich aller Updates) erfüllt. Weitere Informationen zu den Voraussetzungen für die Bereitstellung einer AlwaysOn-Verfügbarkeitsgruppenlösung finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server). Es wird dringend empfohlen, dieses Thema zu lesen, bevor Sie fortfahren. Auf allen Knoten muss die gleiche Version des Windows Server-Betriebssystems und der Softwareupdates installiert sein. Als Serverbetriebssystem sollte mindestens Windows Server 2008 SP2 oder Windows Server 2008 R2 SP1 mit den folgenden Updates installiert sein: 15 Asymmetrischer Speicher (bei Verwendung von Windows Server 2008): http://support.microsoft.com/kb/976097 Knotenstimmen: http://support.microsoft.com/kb/2494036 Datenträgerüberprüfung während der Clustervalidierung: http://support.microsoft.com/kb/2531907 Möglicherweise benötigen Sie zusätzliche Updates. Einrichten der Lösung im primären Rechenzentrum Tabelle 1 zeigt den Workflow zum Einrichten der Knoten im primären Rechenzentrum. In diesem Beispiel wird von zwei Knoten ausgegangen. 16 Schritt 1. Fügen Sie den beiden Knoten im primären Rechenzentrum die Failoverclusterfunktion hinzu. Weitere Informationen zur Vorgehensweise finden Sie unter Installieren des Failoverclusterfeatures. Weitere Informationen zum Überprüfen der Netzwerkinfrastruktur sowie weitere Anforderungen finden Sie unter Grundlegendes zu den Anforderungen für Failovercluster. 2. Überprüfen Sie die erforderlichen Komponenten, und installieren Sie die erforderlichen Windows ServerSoftwareupdates auf jedem Knoten im primären Rechenzentrum. 3. Stellen Sie sicher, dass die freigegebenen Speichervolumes, die für die FCI des primären Rechenzentrums festgelegt wurden, formatiert sind und über einen Laufwerkbuchstaben verfügen. Es wird empfohlen, die Laufwerkbuchstaben und den Verzeichnispfad der DR-FCI gemäß der primären FCI festzulegen. Beachten Sie diesen Punkt bereits bei der Zuordnung von Laufwerkbuchstaben in der primären FCI. 4. Stellen Sie sicher, dass das Konto, das Sie zur Installation und Konfiguration des WSFC-Clusters 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 Namensobjektkonten vorzeitig bereitstellen oder ein Domänenadministratorkonto zur Installation verwenden. Weitere Informationen zu den erforderlichen Berechtigungen und Bereitstellungsoptionen finden Sie unter Schrittweise Anleitung für Failovercluster: Konfigurieren von Konten in Active Directory. 17 DatenbankWindows administrator Server-/Clusteradministrator Ja Ja (Koordination der Aktivitäten über Aufgabengebiete hinweg) Ja Ja Ja Netzwerkadministrator Schritt 5. Führen Sie mithilfe des FailoverclusterManagers eine Clustervalidierung für die beiden Serverknoten im primären Rechenzentrum und den freigegebenen Speicher aus, der dem WSFC-Cluster hinzugefügt wird. Führen Sie die Überprüfung iterativ aus, bis keine Blockierungsfehler mehr auftreten. 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 zum Ausführen eines Validierungstests finden Sie unter Überprüfen einer Failoverclusterkonfiguration. 6. Nach der Clustervalidierung verwenden Sie den Failovercluster-Manager, um einen aus zwei Knoten bestehenden WSFC-Cluster zu erstellen. Weitere Informationen und eine ausführliche Darstellung dieses Prozesses finden Sie unter Erstellen eines neuen Failoverclusters. 7. Stellen Sie sicher, dass eine ungerade Zahl von Stimmen zugewiesen wird. Zu diesem Zweck können Sie eine Dateifreigabe oder einen zusätzlichen Knoten hinzufügen, wie oben bereits erläutert. Wenn Sie "Knoten- und Dateifreigabemehrheit" auswählen, bevor Sie die Konfiguration ändern, müssen dem WSFC-Clusterkonto Leseund Schreibberechtigungen für die Zeugendateifreigabe gewährt werden. 8. Für die Installation muss freigegebener, formatierter Speicher bereitstehen, auf den nur die beiden Knoten im primären Rechenzentrum Zugriff haben. Die Datenträger werden im nächsten Schritt für SQL Server verwendet. 18 DatenbankWindows administrator Server-/Clusteradministrator Ja Ja Ja Ja Netzwerkadministrator Ja – bei Problemen, die bei der Vernetzung der Knoten auftreten können Ja – bei Problemen, die bei der Vernetzung der Knoten auftreten können Schritt 9. Installieren Sie eine FCI-Instanz von SQL Server 2012 Enterprise im primären Rechenzentrum. Weitere Informationen finden Sie unter Erstellen eines neuen SQL Server-Failoverclusters. Sie müssen zwei Installationen ausführen: Neue SQL ServerFailoverclusterinstallation zur Erstellung der FCI und Knoten einem SQL ServerFailovercluster hinzufügen für den zweiten Knoten im primären Rechenzentrum. 10. Nachdem Sie die erste FCI installiert haben, aktivieren Sie die AlwaysOnVerfügbarkeitsgruppenfunktionen für beide SQL Server-Instanzen. Weitere Informationen darüber, wie Sie den SQL Server-Konfigurations-Manager – oder alternativ – SQL Server PowerShell verwenden, finden Sie unter Aktivieren und Deaktivieren von AlwaysOnVerfügbarkeitsgruppen. Wenn Sie AlwaysOn-Verfügbarkeitsgruppen für die Instanz aktivieren, muss die Instanz neu gestartet werden, damit die Änderung wirksam wird. 19 DatenbankWindows administrator Server-/Clusteradministrator Ja Netzwerkadministrator Schritt DatenbankWindows administrator Server-/Clusteradministrator 11. Nachdem Sie die DR-FCI für die Unterstützung von AlwaysOnVerfügbarkeitsgruppen eingerichtet haben, sichern Sie die produktiven Benutzerdatenbanken der älteren Topologie, und stellen Sie sie auf der FCI des primären Rechenzentrums wieder her. Hinweis: Sie können diesen Schritt so lange aufschieben, bis die DR-FCI ebenfalls verfügbar ist und die Verfügbarkeitsgruppe mit zwei Replikaten eingerichtet werden kann. 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 ServerAnmeldungen, 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 DatenbankSpiegelungspartnerschaft außerhalb der gespiegelten Datenbank befinden. Es gibt mehrere Methoden zum Übertragen von Datenbankobjekten und Prinzipien zwischen SQL Server-Instanzen. Der Integration Services-Task "SQL ServerObjekte übertragen" ist ein solcher Ansatz. Eine andere Methode, bei der Anmeldenamen und Kennwörter zwischen Instanzen übertragen werden, wird im Folgenden beschrieben: http://support.microsoft.com/kb/918992/ Tabelle 1: Erstellen der FCI+AG-Lösung im primären Rechenzentrum 20 Netzwerkadministrator Einrichten der Lösung im DR-Rechenzentrum Diese Tabelle veranschaulicht die Schritte zum Einrichten der Knoten im sekundären DR-Rechenzentrum sowie zum Erstellen der Verfügbarkeitsgruppe. Schritt Datenbankadministrator Windows Server-/Clusteradministrator 1. Statten Sie alle Knoten, die sich im DR-Rechenzentrum befinden und Teil der Lösung sind, mit der Failoverclusterfunktion aus. Ja (Koordination der Aktivitäten über Aufgabengebiete hinweg) Ja 2. Überprüfen Sie die erforderlichen Komponenten, und installieren Sie die erforderlichen Windows ServerSoftwareupdates auf jedem Knoten im DR-Rechenzentrum. 3. Stellen Sie sicher, dass das Konto, das Sie zur Installation und Konfiguration des WSFC-Clusters 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. Wenn Sie die gleichen Konten wie im primären Rechenzentrum verwenden, sind die Berechtigungen bereits ordnungsgemäß festgelegt. 4. Führen Sie mithilfe des FailoverclusterManagers eine Clustervalidierung für die beiden Serverknoten und den freigegebenen Speicher aus, der dem vorhandenen WSFC-Cluster zugewiesen ist. Wenn die Warnmeldung "Der Datenträger mit der ID XYZ ist nur für eine Teilmenge von Knoten sichtbar oder clusterfähig" für asymmetrischen Speicher angezeigt wird, ist keine Maßnahme erforderlich. Diese Meldung wird erwartungsgemäß angezeigt und ist für asymmetrischen Speicher unkritisch. Führen Sie die Überprüfung iterativ aus, bis keine Blockierungsfehler mehr auftreten. 5. Nach Ende der Validierung fügen Sie dem vorhandenen WSFC-Cluster mithilfe des Failovercluster-Managers die beiden DR-Knoten hinzu. Ja 6. Legen Sie die NodeWeight-Einstellung der WSFC-Knoten im DR-Rechenzentrum auf 0 (Null) fest (vgl. Abbildung 4: FCI+AG HA/DR-Lösung mit zugewiesenen ). Ja 21 Netzwerkadministrator Ja Ja Ja – bei Problemen, die bei der Vernetzung der Knoten auftreten können Ja Ja – bei Problemen, die bei der Vernetzung der Knoten auftreten können Schritt Datenbankadministrator 7. Für diese Installation sollte freigegebener, formatierter Speicher verwendet werden, auf den nur die beiden Knoten im DR-Rechenzentrum Zugriff haben. Die Datenträger werden im nächsten Schritt für SQL Server verwendet. Verwenden Sie identische Laufwerkbuchstaben und Zuordnungen, um die Bereitstellung der Verfügbarkeitsgruppe in späteren Schritten zu vereinfachen und Datenbankdateivorgänge zuzulassen, die keinen manuellen Eingriff bzw. keine Unterbrechung der Verfügbarkeitsgruppensitzung erfordern. 8. Verschieben Sie den verfügbaren Speicher auf einen der Knoten im DR-Rechenzentrum, um ihn im nächsten Schritt zu verwenden. 9. Installieren Sie eine FCI-Instanz von Ja SQL Server 2012 Enterprise im DR-Rechenzentrum. Sie müssen den Schritt Neue SQL ServerFailoverclusterinstallation für einen der Knoten ausführen, um die FCI zu erstellen. Führen Sie dann den Schritt Knoten einem SQL Server-Failovercluster hinzufügen für den zweiten Knoten im DR-Rechenzentrum aus. 10. Nach der Installation der beiden FCIs Ja besteht der nächste Schritt darin, AlwaysOnVerfügbarkeitsgruppenfunktionen für die SQL Server-Instanz im DR-Rechenzentrum zu aktivieren. Die ausführlichen Schritte zur Verwendung des SQL Server-Konfigurations-Managers oder von PowerShell finden Sie unter Aktivieren und Deaktivieren von AlwaysOn-Verfügbarkeitsgruppen. Die Instanz muss neu gestartet werden, damit die AlwaysOn-Verfügbarkeitsgruppe für die Instanz aktiviert wird. 22 Windows Server-/Clusteradministrator Netzwerkadministrator Ja Ja Ja – zur Koordinierung von IPAdressen (bei Verwendung statischer IP-Adressen) und Ports Schritt Datenbankadministrator 11. 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 ServerAnmeldungen, zugeordnete Berechtigungen auf Serverebene, SQL Server-Agent-Aufträge). Ja Dies sind die gleichen Objekte, für die Sie möglicherweise bereits ein Skript erstellt haben und die auf die FCI des primären Rechenzentrums kopiert wurden. 12. Legen Sie die Besitzer der beiden FCIs ordnungsgemäß fest: Mögliche Besitzer für INST_A sind PRIMARYNODE1, PRIMARYNODE2, und mögliche Besitzer für INST_B sind DRNODE1, DRNODE2. 13. Erstellen Sie eine Verfügbarkeitsgruppe (dieser Schritt gilt sowohl für die primäre als auch für die DR-FCI). Abhängig von der Arbeitslast und der Netzwerkkonfiguration Ihrer Umgebung können Sie zwischen dem asynchronen und synchronen Verfügbarkeitsmodus wählen. Wählen Sie manuelles Failover für die Verfügbarkeitsgruppen. In einer FCI+AG-Lösung erfolgt das FCI-Failover automatisch und das Verfügbarkeitsgruppenfailover manuell. Weitere Informationen zur Failoverkonfiguration für diese Lösung finden Sie unter Erstellung und Konfiguration von Verfügbarkeitsgruppen. 23 Ja Windows Server-/Clusteradministrator Netzwerkadministrator Ja – um sicherzustellen, dass die Endpunktports geöffnet sind und ggf. zur Problembehandlung Schritt Datenbankadministrator Windows Server-/Clusteradministrator Netzwerkadministrator 14. Erstellen Sie den Verfügbarkeitsgruppenlistener. Dieser Schritt ist nicht erforderlich, wenn Sie den Listener bereits bei der Erstellung der Verfügbarkeitsgruppe konfiguriert haben. Sie können den Verfügbarkeitsgruppenlistener mit Transact-SQL, SQL Server PowerShell oder einem Assistenten in SQL Server Management Studio erstellen. Weitere Informationen zu den verschiedenen Methoden finden Sie unter Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners. Ja Ja Ja – zur Koordinierung von IP-Adressen und Ports Tabelle 2: Erstellen der FCI+AG-Lösung im DR-Rechenzentrum Nachdem Sie diese Schritte ausgeführt haben, sehen Sie im Windows-Failovercluster-Manager unter "Dienste und Anwendungen" eine neue Gruppe mit dem Namen der Verfügbarkeitsgruppe. Innerhalb dieser neuen Gruppe sehen Sie auch die Verfügbarkeitsgruppenlistener-Ressource und zugeordnete Listener-IP-Adressen (vgl. Abbildung 5). Abbildung 7: Nach der Konfiguration der FCI für eine HA- und AG-DR-Entwurfslösung Abbildung 7 zeigt die WSFC-Ansicht der Bereitstellung. Zur Verdeutlichung wird der AG-Listener in der Abbildung mit einer zugeordneten IP-Adresse angezeigt. Für Topologien mit mehreren Rechenzentren sind jedoch zwei IP-Adressen üblich. Hinweis: Obwohl die Verfügbarkeitsgruppe als Ressource im WSFC-Cluster angezeigt wird, sollten Sie nicht versuchen, sie mithilfe des Failovercluster-Managers oder über WSFCSchnittstellen zu verwalten. Verwalten Sie die Verfügbarkeitsgruppe stattdessen im Kontext der SQL Server-Instanz über SQL Server Management Studio, Transact-SQL oder Windows PowerShell. Weitere Informationen zu den Gründen, warum der Failovercluster-Manager oder andere WSFC-Schnittstellen nicht verwendet werden sollen, finden Sie im Blogbeitrag FailoverclusterManager NICHT zum Failover von Verfügbarkeitsgruppen verwenden. 24 Abbildung 8 zeigt die Bereitstellung in SQL Server Management Studio. Die Abbildung enthält eine der FCIs, deren Ordner "AlwaysOn High Availability" in der Objekt-Explorer-Ordnerhierarchie geöffnet ist. In diesem Beispiel ist die DR-FCI das sekundäre Replikat und die andere FCI das primäre Replikat. Die drei Verfügbarkeitsdatenbanken, die der Gruppe angehören, sind mit dem Namen des Verfügbarkeitsgruppenlisteners aufgeführt. Abbildung 8: Postkonfiguration der FCI für die HA- und AG-DR-Entwurfslösung in SQL Server Management Studio Überlegungen zur Überwachung Die Migration von einer FCI- und Datenbankspiegelungs-Topologie zu einer Lösung mit FCIs und Verfügbarkeitsgruppen erfordert einen neuen Ansatz zur Überwachung der Topologie. Die folgenden Methoden und Tools stehen Ihnen zur Überwachung der Verfügbarkeitsgruppeninfrastruktur zur Verfügung: AlwaysOn-Dashboard in SQL Server Management Studio, Statusinformationen im ObjektExplorer, richtlinienbasierte Verwaltung, neue Leistungsindikatoren für Verfügbarkeitsgruppen, Katalogsichten, dynamische Verwaltungssichten und eine Extended Events-Sitzung, die die Ausführung der letzten AlwaysOn DDL-Anweisungen, WSFC-Konnektivitätsprobleme, Failoverereignisse, Statusänderungen und REDO-Threadblockierungen nachverfolgt. Das AlwaysOn-Dashboard wird empfohlen, um schnell den Status einer bestimmten Verfügbarkeitsgruppe anzuzeigen. Die Informationen umfassen den Speicherort der primären Instanz, den Failovermodus und Synchronisierungsstatus der Replikate sowie die Failoverbereitschaft der verschiedenen Replikate. 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. 25 Abbildung 9: AlwaysOn-Dashboard 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 und Anweisungen zur Überwachung einer Verfügbarkeitsgruppenumgebung finden Sie unter Überwachen von Verfügbarkeitsgruppen. Wiederherstellung nach einem Notfall Dieser Abschnitt beschreibt die Arbeitsschritte, die Sie bei einem Ausfall des primären Replikats im primären Rechenzentrum ausführen. Darüber hinaus werden die Schritte behandelt, die Sie ausführen, um das primäre Replikat über das DR-Rechenzentrum verfügbar zu machen. Ein Ausfall des primären Replikats kann eine oder mehrere der folgenden Ursachen haben: Ausfall aller FCI-Knoten des primären Rechenzentrums Ausfall des FCI-Speichers des primären Rechenzentrums Fehler oder Netzwerkausfall, der sich auf das gesamte primäre Rechenzentrum auswirkt Bei jedem dieser Szenarien sind bestimmte Aktionen im DR-Rechenzentrum auszuführen, um den SQL Server-Betrieb für die Anwendungen wiederaufzunehmen. Abbildung 10 zeigt das Fenster mit Informationen zum Clusterquorum für dieses Szenario (auf diese Informationen wird über das AlwaysOn-Dashboard und den Link Informationen zum Clusterquorum anzeigen zugegriffen). Die Abbildung zeigt das Quorum vor einem Notfall (beide DR-Knoten mit 0 Stimmen). 26 Abbildung 10: Vorheriger Status der Clusterquorumsstimmen Der folgende Workflow enthält die Schritte, die erforderlich sind, um eine Verfügbarkeitsgruppe bei Ausfall des primären Rechenzentrums im DR-Rechenzentrum wiederherzustellen: 1. Erzwingen Sie das Quorum auf einem der DR-Knoten, und stellen Sie sicher, dass die Knoten im primären Rechenzentrum kein eigenes Quorum bilden. Wenn der Failovercluster-Manager auf einem 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. Abbildung 11: Failovercluster-Manager nach einem Notfall und vor der Wiederherstellung Die FCIs sind auf einen funktionsfähigen WSFC-Cluster angewiesen. Der Zugriff ist möglich, solange ein Clusterquorum besteht und der Clusterdienst ausgeführt wird. Bei einem Szenario, in dem der Status des primären Rechenzentrums unklar ist und der Betrieb vom sekundären DR-Rechenzentrum wiederhergestellt werden muss, um die RTO-Vorgaben (Wiederanlaufdauer) nicht zu überschreiten, müssen Sie für einen der DR-Knoten ein Quorum erzwingen. 27 Der folgende Windows PowerShell-Befehl veranschaulicht, wie das Quorum für einen DR-Knoten erzwungen wird. Start-ClusterNode –Name "DRNODE1" –FixQuorum Nach Ausführung des Befehls sollte etwa folgendes Resultset ausgegeben werden. Name ------drnode1 State -------Joining Hinweis: Wenn der Clusterdienst weiterhin auf "DRNODE1" ausgeführt wird, können Sie den Dienst mit dem folgenden Windows PowerShell-Befehl beenden, bevor Sie den Clusterdienst mit erzwungenem Quorum erneut starten: Stop-ClusterNode –Name "DRNODE1" Zum Erzwingen des Quorums können Sie zusätzliche Tools wie "cluster.exe" oder den Failovercluster-Manager verwenden. Weitere Informationen finden Sie unter Erzwingen des Starts eines Clusters ohne Quorum. 2. Öffnen Sie den Failovercluster-Manager, um den Status des Windows-Clusters anzuzeigen. An diesem Punkt sollte sich der Windows-Cluster im erzwungenen Quorumstatus befinden und die sekundäre FCI gestartet sein. Die FCI des primären Rechenzentrums ist genauso wie die Verfügbarkeitsgruppenressourcen immer noch offline. Abbildung 12: Failovercluster-Manager nach dem Erzwingen eines Quorums 3. Schalten Sie die Verfügbarkeitsgruppe auf der DR-FCI online. Achtung: Wenn das Replikat mit dem asynchronen Modus konfiguriert wurde, kann die Wiederaufnahme des Betriebs bei noch nicht gesendeten Protokolldatensätzen zu Datenverlusten führen. Sie müssen sich über die Auswirkungen dieser Aktion vollständig im Klaren sein. Weitere Informationen zu den Maßnahmen vor, während und nach dieser Art des manuellen Failovers finden Sie unter Ausführen eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe. 28 Stellen Sie in SQL Server Management Studio eine Verbindung mit der FCI im DR-Rechenzentrum her. In SQL Server Management Studio sollte für Verfügbarkeitsdatenbanken der Status "Synchronisierung wird nicht ausgeführt" angezeigt werden. Darüber hinaus wird die DR-FCI mit dem Status "Wird aufgelöst" angezeigt (vgl. Abbildung 13). Abbildung 13: Objekt-Explorer von SQL Server Management Studio nach dem Erzwingen eines Quorums In Abbildung 13 sehen Sie, dass für das andere Replikat (in diesem Beispiel "SQLFCIPrimary\INST_A") im Objekt-Explorer unter dem Ordner AG1 "Verfügbarkeitsreplikate" keine Statusangaben angezeigt werden. Das ist die FCI des primären Rechenzentrums, auf die aufgrund des Ausfalls nicht zugegriffen werden kann. Wenn Datenverluste bis zu einem gewissen Grad akzeptabel sind und der Betrieb im Rechenzentrum wiederhergestellt werden muss, führen Sie die folgende Transact-SQL-Syntax auf der DR-FCI aus, um ein Failover zu erzwingen. ALTER AVAILABILITY GROUP [AG1] FORCE_FAILOVER_ALLOW_DATA_LOSS; Jetzt sollten die Datenbanken innerhalb der Verfügbarkeitsgruppe verfügbar sein. Abbildung 14 zeigt den Status nach einem erzwungenen Failover. 29 Abbildung 14: Objekt-Explorer nach erzwungenem Failover Nachdem der Onlinestatus wiederhergestellt wurde, werden neue Verbindungen mit dem Verfügbarkeitsgruppenlistener automatisch an das aktuelle primäre Replikat umgeleitet, das von der DR-FCI gehostet wird. Beachten Sie auch die verschiedenen Warnmeldungen zu nicht verfügbaren Knoten im primären Rechenzentrum, die in SQL Server Management Studio angezeigt werden. Abbildung 15 zeigt ein entsprechendes Beispiel. 30 Abbildung 15: AlwaysOn-Dashboard nach einem erzwungenen Failover 4. Entziehen die den Knoten des primären Rechenzentrums vom DR-WSFC-Knoten aus Stimmen, und weisen Sie den Knoten im DR-Rechenzentrum Stimmen zu. Stimmen können entzogen werden, auch wenn die Knoten des primären Rechenzentrums nicht verfügbar sind. Die beiden Knoten mit der "NodeWeight"-Einstellung "1" sind die DR-WSFC-Knoten. (Get-ClusterNode "DRNode1").NodeWeight=1 (Get-ClusterNode "DRNode2").NodeWeight=1 (Get-ClusterNode "PrimaryNode1").NodeWeight=0 (Get-ClusterNode "PrimaryNode2").NodeWeight=0 Hinweis: Wenn für längere Zeit auf den DR-Standort ausgewichen werden muss, wird empfohlen, zusätzliche stimmberechtigte Mitglieder (WSFC-Knoten oder Dateifreigabe) hinzuzufügen. 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 Wie oben bereits ausgeführt, sind die Aufgaben in den meisten großen Unternehmensumgebungen nach Zuständigkeit unterteilt, z. B. Datenbankadministrator, Windows Server-(oder Cluster-)Administrator und Netzwerkadministrator. 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. 31 Schritt Datenbankadministrator 1. Bestätigen Sie den aktuellen Status Ja des primären Rechenzentrums und der übrigen DR-Knoten des WSFC-Clusters; Koordinieren aller Maßnahmen. 2. Erzwingen Sie das Quorum für einen der Knoten am DR-Standort, um auf die DR-FCI zuzugreifen. 3. Erzwingen Sie das Failover der Ja Verfügbarkeitsgruppe auf die DR-FCI. 4. Fügen Sie den DR-Knoten Stimmen hinzu, und entziehen Sie den primären Knoten Stimmen. Windows Server-/Clusteradministrator Ja Netzwerkadministrator Ja Ja Ja Tabelle 3: Notfallwiederherstellung nach Aufgabengebiet unterteilt Wiederinbetriebnahme des primären Rechenzentrums Die Fortführung des Betriebs im DR-Rechenzentrum wird in diesem Whitepaper als Übergangslösung betrachtet, bis die Probleme mit dem primären Rechenzentrum behoben wurden. 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. Das Replikat auf der FCI des zuvor ausgefallenen primären Rechenzentrums weist den Status "Synchronisierung wird nicht ausgeführt" auf (vgl. Abbildung 16). 32 Abbildung 16: SQL Server Management Studio nach der Wiederherstellung der primären FCI, aber vor Wiederherstellung der Verfügbarkeitsgruppe Die SQL Server-Instanz am DR-Standort (in unserem Beispiel "SQLFCIDR\DC2") ist weiterhin das primäre Replikat. Beachten Sie auch das Symbol "Anhalten" für jede Verfügbarkeitsdatenbank unter dem Ordner "Verfügbarkeitsdatenbanken". 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 stattdessen mit der Wiederherstellung der Replikatsitzungen fortfahren. Achtung: Bei der Wiederinbetriebnahme der Verfügbarkeitsgruppenreplikate können jetzt Datenverluste auftreten. Wenn Datenverluste nicht toleriert werden können, müssen die Daten gerettet werden, bevor die Datenverschiebung wiederaufgenommen wird. Wird der Betrieb der Verfügbarkeitsgruppe dagegen nicht wiederaufgenommen, kann dies dazu führen, dass die Größe der Transaktionsprotokolldateien in den DR-Replikatdatenbanken zunimmt. Eine Methode besteht darin, eine Datenbankmomentaufnahme auf den angehaltenen sekundären Datenbanken (ursprünglich primäre Datenbanken) zu erstellen, um die erforderlichen Daten zu extrahieren und anhand der DR-Replikatversion der Verfügbarkeitsdatenbanken wieder 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 = 'R:\MSSQL11.MSSQLSERVER\MSSQL\Data\AppDB_A1.ss' ) AS SNAPSHOT OF AppDB; GO 33 Die erforderlichen Daten können aus der Datenbankmomentaufnahme extrahiert und entsprechend in das aktuelle primäre Replikat eingefügt werden, bevor die Datenverschiebung wiederaufgenommen wird. Hinweis: Weitere Informationen zu den Risiken eines erzwungenen Failovers und zur Einschränkung des Datenverlustrisikos finden Sie unter Failover und Failovermodi. Nachdem das Datenverlustproblem adäquat behandelt wurde und die Wiederinbetriebnahme des primären Rechenzentrums bevorsteht, besteht der nächste Schritt darin, das primäre Replikat kontrolliert in das primäre Rechenzentrum zurückzuverlegen: 1. Beginnen Sie mit der kontrollierten Rückmigration in das primäre Rechenzentrum, indem Sie den beiden Knoten im primären Rechenzentrum ihre Quorumsstimmen zurückgeben. Überprüfen Sie nach dem Konfigurieren dieser Einstellung erneut, ob alle Knoten im WSFCCluster über eine Stimme verfügen. 2. Um den Betrieb jeder Datenbank in der Verfügbarkeitsgruppe wiederaufzunehmen, führen Sie die Transact-SQL ALTER DATABASE-Befehle für die FCI des primären Rechenzentrums aus. Beispiel: ALTER DATABASE AppDB SET HADR RESUME; GO ALTER DATABASE ConfigDB SET HADR RESUME; GO ALTER DATABASE ReportDB SET HADR RESUME; GO 3. Um vor dem Failover eine Synchronisierung durchzuführen, ändern Sie die Verfügbarkeitsgruppe für die DR-FCI, um vorübergehend den Verfügbarkeitsmodus mit synchronem Commit zu verwenden. Vorzugsweise sollte die Einstellung für synchrone Commits zu weniger aktiven Zeiten vorgenommen werden, um die Transaktionslatenz gering zu halten. Hier sehen Sie ein Beispiel für den Transact-SQL-Befehl (der auf der aktuellen primären FCI im DR-Rechenzentrum ausgeführt wird). In diesem Beispiel ist AG1 die Verfügbarkeitsgruppe und SQLFCIPrimary\INST_A das Replikat des primären Rechenzentrums. USE [master] GO ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT); GO Führen Sie in derselben SQL Server Management Studio-Sitzung den folgenden Befehl aus, um auch für das DR-Replikat synchrone Commits festzulegen. 34 USE [master] GO ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT); GO 4. Bestätigen Sie den Synchronisierungsstatus zwischen den beiden Standorten (in beiden Fällen sollte der Replikatstatus "Fehlerfrei" lauten, bevor Sie zum nächsten Schritt übergehen. Beide Replikate mit synchronem Commit gelten dann als synchronisiert). SELECT role_desc, synchronization_health_desc FROM sys.dm_hadr_availability_replica_states; 5. Um ein Failover von der FCI des DR-Rechenzentrums auf die FCI des früheren primären Rechenzentrums auszuführen, stellen Sie eine Verbindung her und führen das folgende Skript für die FCI des primären Rechenzentrums aus, die zum neuen primären Replikat wird. ALTER AVAILABILITY GROUP [AG1] FAILOVER; 6. Wenn die Topologie den Hochleistungsmodus verwendet, bringen Sie den Replikatknoten der DR-FCI wie oben bereits erwähnt wieder in den Modus für asynchrone Commits. Führen Sie den folgenden Transact-SQL-Befehl für das primäre Replikat aus. USE [master] GO ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT); GO USE [master] GO ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT); GO 7. Entziehen Sie den DR-Knoten die Quorumsstimmen. 35 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. Schritt 1. Nachdem der Betrieb, die Knoten und die FCI des primären Rechenzentrums wiederhergestellt wurden, weisen Sie den ursprünglichen primären Knoten wieder Quorumsstimmen zu. 2. Stellen Sie die Verfügbarkeitsdatenbanksitzungen auf den einzelnen sekundären Replikaten wieder her. 3. Aktivieren Sie für das DR-FCI-Replikat und das FCI-Replikat des primären Rechenzentrums den Modus für synchrone Commits. 4. Bestätigen Sie den Synchronisierungsstatus zwischen den beiden Standorten (der Status beider Replikate sollte "Fehlerfrei" lauten, bevor der nächste Schritt ausgeführt wird). 5. Führen Sie ein Failover auf das FCI-Replikat des primären Rechenzentrums aus. 6. Stellen Sie den asynchronen Commitmodus für das DR-Replikat (gemäß Originalkonfiguration) wieder her. 7. Entziehen Sie den DR-WSFC-Knoten Stimmen. Datenbankadministrator Windows Server-/Clusteradministrator Ja Netzwerkadministrator Ja Ja Ja Ja Ja Ja Tabelle 4: Wiederinbetriebnahme des primären Rechenzentrums Schlussfolgerung SQL Server 2012 AlwaysOn-Verfügbarkeitsgruppen können verwendet werden, um die Datenbankspiegelung in Topologien, die FCIs zur Erreichung von HA-Zielen und die Datenbankspiegelung als DR-Strategie verwenden, abzulösen. Dieses Entwurfsmuster erweitert die Möglichkeiten früherer Versionen durch Failoverunterstützung für mehrere Datenbanken, lesbare Replikate und vieles andere mehr. Das Ziel dieses Whitepapers war es, eine neue HA+DR-Lösung vorzustellen, die die vormalige Architektur durch AlwaysOn-FCIs und AlwaysOn-Verfügbarkeitsgruppen ersetzt. 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. 36 Referenzmaterial 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) AlwaysOn-Failoverclusterinstanzen (http://technet.microsoft.com/library/ms189134.aspx) Übersicht über AlwaysOn-Verfügbarkeitsgruppen (http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx) Failoverclustering und AlwaysOn-Verfügbarkeitsgruppen (http://technet.microsoft.com/library/ff929171.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) Weitere Informationen: SQL Server-Website (http://www.microsoft.com/sqlserver/) SQL Server TechCenter (http://technet.microsoft.com/sqlserver/) SQL Server DevCenter (http://msdn.microsoft.com/sqlserver/) 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 37
