Daniel Snellen

Mit dem SQL Server 2012 hat Microsoft ein neues Feature Namens „AlwaysOn“ eingeführt.
AlwaysOn erweitert die Möglichkeiten der Hochverfügbarkeit des SQL 2012.
Diese neue Funktion unterstützt jedoch nur den relationalen Teil, und z.B. nicht den Analysis Service
Auch von der SQL Azure Plattform wird diese Funktion eingesetzt, um hohe Verfügbarkeit zu realisieren.

Als Grundgerüst nutzt das AlwaysOn Feature den Windows Server Failover Cluster Service, welcher Bestandteil des Windows Server 2008 und 2008R2 Betriebssystems ist.

Im Gegensatz zum klassischen Failover Cluster benötigen die Nodes keinen gemeinsamen Speicherplatz mehr.

Hierdurch lässt sich einiges an Hardware Kosten einsparen, da kein teures SAN angeschafft werden muss.
Ein weiterer Vorteil ist, dass die Nodes auch über größere Distanzen betrieben werden können und somit der Cluster auch Multi-Subnetz tauglich ist.

Eine weitere Möglichkeit besteht in der Kombination der unterschiedlichen Techniken.
So kann u. a. auch eine SQL Server Failover Instance mit AlwaysOn kombiniert werden.

Leider ist AlwaysOn ein Enterprise Feature und somit nur mit der SQL2012 Enterprise Lizenz verfügbar.

Im SQL Server 2010 AlwayOn werden sogenannte Availability Gruppen (AG) angelegt. Innerhalb einer solchen Gruppe wird dann festgelegt, welche Datenbanken auf welchen Node synchronisiert werden soll, sowie welche Synchronisationsmethode verwendet werden soll.

Eine Availability Gruppe erhält einen virtuellen Namen sowie mindestens eine IP Adresse. Die IP Adressen lassen sich auch vom DHCP Server zuweisen, was aus meiner Sicht nicht sinnvoll ist, da statische IP Adressen sich besser verwalten lassen.

Es können ausschließlich nur Benutzerdatenbanken in Availability Gruppen eingebunden werden. Da jeder Node eine eigenständige Instanz vom SQL Server vorhält, macht es auch keinen Sinn die Systemdatenbanken zu replizieren

SQL Server AlwaysOn unterstützt bis zu 5 Nodes, wobei ein Node immer das primäre Replikat bereitstellt und die restlichen jeweils ein sekundäres Replikat.

Es werden 2 Synchronisierungsmethoden angeboten:

  • Synchroner Modus
    Die primäre Datenbank übernimmt erst eine Transaktion wenn alle sekundären Replikate diese auch bestätigt habe.
    Hierdurch kann es auch zu Performance Verlusten kommen.
    Eine Availability Gruppe kann nur 2 synchrone sekundäre Replikate haben.
  • Asynchroner Modus
    Die primäre Datenbank übernimmt in diesem Modus die Transaktion sofort und wartet nicht auf die sekundären Replikate.
    Somit sind die sekundären Replikate nicht immer aktuell.
    Eine Availability Gruppe kann max. nur 4 asynchrone sekundäre Replikate haben.

Die beiden Modi können auch kombiniert werden.

image

Des Weiteren kann das Verhalten im Störungsfall festgelegt werden.
Hier kann zwischen dem automatischen und dem manuellen Failover gewählt werden.
Der automatische Failover ist jedoch nur beim synchronen Modus möglich, da es wenig Sinn macht, automatisch auf ein nicht aktuelles System umzuschalten.

Man hat auch die Möglichkeit die Replikate so zu konfigurieren, dass die Datenbanken einer AG auch über die lokalen Instanzen der einzelnen Nodes erreichbar sind.

image

Hierfür gibt es zwei Möglichkeiten bei „Yes“ ist das Lesen auf den Datenbanken erlaubt, bei „Read-intent only“ muss der Client die Info mitsenden, dass es sich um eine Read Only Verbindung handelt.

Wie schon erwähnt, könnte man auch eine Failover Cluster mit AlwaysOn kombinieren.
In einem solchen Fall würde zuerst der SQL Failover Cluster eingerichtet und dann im gleichen Windows Cluster die Availability Gruppe eingerichtet.
Bei der Kombination dieser beiden Funktionen ist jedoch zu beachten, dass innerhalb der Availability Gruppe kein automatischer Failover mehr möglich ist, weil der Failover Cluster hier die Hoheit hat.

Dieses neue Feature des SQL Server 2012 eröffnet z.B. einem Datenbank-Administrator einige neue Möglichkeiten, u. a. beim Backup.
Da die lokalen SQL Instanzen auf den jeweiligen Nodes auch direkt angesprochen werden können und nicht nur über den virtuellen Namen verfügbar sind, könnte ein Backup auch von einem sekundären Replikat erstellt werden und würde das primäre Replikat nicht belasten. Hierdurch könnte auch eine räumliche Trennung zwischen dem produktiven System und dem Backup erreicht werden.

In einem weiteren Blog werde ich die Einrichtung des AlwaysOn Features erklären. (coming soon)