image2

You Are here: Start Kategorie als Blog SQL 2012 SP1: Einrichtung AlwaysOn Availability Group

SQL 2012 SP1: Einrichtung AlwaysOn Availability Group PDF Drucken E-Mail
Samstag, den 27. April 2013 um 15:42 Uhr

Dieser Artikel soll kurz die Schritte zur Einrichtung von AlwaysOn Availability Groups unter SQL 2012 SP1 beschreiben. Die AGs verhalten sich ähnlich den Exchange DAGs und sind schnell eingerichtet. Eine Kopie (Replica) einer Datenbank ist dabei auf verschiedenen Servern einer Verfügbarkeitsgruppe vorhanden - im Bedarfsfall erfolgt ein automatischer Failover. Als Zugangspunkt dient ein Listener, der den Zugriff auf die jeweils aktive Datenbank ermöglicht.

Voraussetzung ist die Enterprise-Edition von SQL 2012, was die Lösung im Gegensatz zu Exchange etwas kostspieliger macht. Bei Exchange reicht bereits die Standard-Edition, um eine DAG zu spannen.  Mehr dazu in der Technet Library:
http://msdn.microsoft.com/en-us/library/aa427606-8422-4656-b205-c9e665ddc8c1

Einrichtung:
Die Test-Umgebung enthält zwei Instanzen von SQL2012 SP1 auf Windows 2012 läuft. Weiterhin ist ein DC unter Windows 2012 eingerichtet, der als Witness dient und auch gleich Access zum Testen der Umgebung mitbringt.

Installation des Failoverclusters:

1.    Feature im Server-Dashboard hinzufügen: Dies muss auf beiden SQL-Servern erfolgen, kann aber von einem zentralen Server durchgeführt werde, sofern alle Server im Dashboard eingebunden sind. Leider kann nur ein Server zurzeit installiert werden – schön wäre es, wenn man gleich eine Gruppe auswählen könnte.

Die SQL-Instanz kann dabei bereits installiert sein oder im Anschluss installiert werden.

2.    Erforderliche Features gleich mit hinzufügen lassen:

3.    Übersicht prüfen und installieren lassen.

 

4.    Nach der Installation sollte die Erfolgsmeldung im Dashboard zu sehen sein:


Einrichten des Clusters

1.    Im nächsten Schritt wird der Cluster über den Cluster-Assistent im Cluster-Manager gestartet.

2.    Die beiden Server, die zuvor installiert wurden, werden dem Cluster hinzugefügt.

3.    Über den Clusternamen lässt sich die Umgebung zukünftig zentral konfigurieren:

4.    Im Abschluss die Konfiguration bestätigen und erstellen lassen.

5.    In der Zusammenfassung werden dann noch mal die Warnungen angezeigt und je nach den Verhältnissen im Cluster sollte das Quorum angepasst werden. In unserem Beispiel wird es über einen Share am DC durchgeführt.

6.    Das Quorum konfigurieren Sie ebenfalls über einen Assistenten im Cluster-Manager, in dem nun unser Cluster zu sehen ist:

7.    Da es zwischen den Servern keine gemeinsames Volume für ein Cluster-Shared-Volume gibt, nutzen wir eine Freigabe auf einem Zeugen:

8.    Die Freigabe sollte auf dem Zeugenserver eingerichtet sein und es müssen für das Cluster-Computer-Objekt lesende und schreibende Rechte im Freigabe- und Sicherheitsbereich bestehen.

9.    Jetzt ist auch im Failover-Clustermanager alles im grünen Bereich:

Anpassung im SQL-Server

1.    Damit die Funktion im SQL Management-Studio genutzt werden kann, muss die Funktion im Configuration Manager zunächst aktiviert werden.

2.    Im nächsten Schritt kann der Assistent zu Einrichtung einer Verfügbarkeitsgruppe gestartet werden. An diesem Punkt sollte die Datenbank bereits verfügbar sein und das Wiederherstellungsmodell auf „Vollständig“ stehen.

3.    Nun werden Name und Datenbank der Verfügbarkeitsgruppe ausgewählt.

4.    Im nächsten Punkt werden die Replikate definiert. Hier werden die Failovereigenschaften und die Lesbarkeit der sekundären DB definiert. An dem Punkt Sicherungseinstellungen kann im Übrigen definiert werden, von wo das Backup erstellt wird.

5.    Ein wichtiger Punkt ist noch der Listener, der den Zugangspunkt zur AG definiert. Dieser kann auch später definiert werden.

6.    Nun muss definiert werden, wie die Kopie zur anderen Instanz kommt. In unserem Fall wird das über eine Datenbanksicherung durchgeführt, die in einem Share auf dem anderen Server automatisch restored wird.

7.    Im Abschluss folgt noch eine Prüfung der Einstellungen, bevor die Einrichtung abgeschlossen wird.

8.    Am Ende sollte alles eingerichtet sein.

Ergebnisse:
1.    Im Clustermangager wurde nun eine Ressource mit dem Namen und der IP des Listener eingerichtet. Hier sieht man auch, welche Instanz aktiv ist.

2.    Im AD hat sich auch etwas getan und sowohl der Cluster als auch der Listener haben ein Computerobjekt erhalten. Erstellen Sie zur Sicherheit eine eigene OU „Cluster“ und verschieben Sie die Objekte, damit diese keiner Aufräumaktion zum Opfer fallen.

3.    Im Managementstudio kann man sich das zugehörige Dashboard anschauen, in dem alle Informationen zusammengefasst sind.

Fehlerfall
1.    Deaktiviert man nun zum Test die Netzwerkverbindung am primären Knoten, erfolgt sofort der Failover und die zweite Instanz übernimmt.

2.    Im Clustermanager wird das natürlich auch angezeigt

3.    Die Datenbankzugriffe über den Listener AG1 zeigen sich von dem Schwenk unbeeindruckt und die Abfragen laufen unberührt weiter. Hier mal mit Access und einer ODBC-Verbindung.