SQL Server AlwaysOn – kein automatischer Failover bei Verlust von Datenbank-Files

SQL Server AlwaysOn – kein automatischer Failover bei Verlust von Datenbank-Files

Seit SQL Server Release 2012 stellt Microsoft eine neue Hochverfügbarkeitstechnologie namens „AlwaysOn“ zur Verfügung, die in die Datenbanksoftware integriert ist und das bestehende Angebot an Hochverfügbarkeitslösungen ergänzt. In Zukunft soll AlwaysOn den Datenbankspiegel sogar komplett ablösen (siehe Hochverfügbarkeitslösungen – MS Technet)

In diesem Beitrag möchten wir die AlwaysOn-Technologie näher erläutern, uns aber auch einer Problemkonstellation widmen, die mit deren Einsatz auftreten kann.

Was ist AlwaysOn?

Die SQL Server AlwaysOn (AO) Technologie ist bereits umfassend online beschrieben und dokumentiert. Besonders hervorzuheben sind die FaQ auf den Technet-Seiten von Microsoft Microsoft Technet – AlwaysOn FAQ sowie dieser sehr anschauliche Blogbeitrag von Jürgen Thomas: SQL Server 2012 AlwaysOn – What is it?

Kurz gesagt:

AlwaysOn ist neben Database Mirroring (DBM) und Clustering des SQL Servers eine alternative Hochverfügbarkeitslösung für SQL Server Datenbanken, deren Ziel es ist, alle Vorteile aus der Kombination der beiden genannten HA-Lösungen zu vereinbaren und gleichzeitig deren Nachteile auszumerzen.

Die Komplexität einer geclusterten SQL Server Instanz wird bei AO durch lokal installierte SQL Server Instanzen mit lokal angebundenem Storage vermieden. Die Datenbank ist wie bei DBM auf jedem Server lokal vorhanden.

Im Gegensatz zu DBM lässt sich eine über AO abgesicherte Datenbank über einen einheitlichen DNS-Namen / IP-Adresse ansprechen. Die Applikation, die die Datenbank nutzt, hat somit Transparenz über einen eventuell erfolgenden Failover und muss nicht zur Laufzeit einen anderen Datenbankserver ansprechen.

Zahlreiche Geschäftsprozesse werden in der heutigen Zeit in IT-Systemen abgebildet und deren Ausführung erfordert die Verfügbarkeit und korrekte Funktionsweise der zugrundeliegenden Systeme. Besonders bei Systemen, die von geschäftskritischen Prozessen genutzt werden, kann Nichtverfügbarkeit zu hohen finanziellen Verlusten führen. Nutzer bzw. Administratoren müssen sich daher darauf verlassen können, dass die durch die Hochverfügbarkeitstechnologie abgesicherten Datenbanken auch im Fehlerfall (Hardwareausfälle und dergleichen) jederzeit erreichbar sind. Doch funktioniert AlwaysOn in jeder denkbaren Fehlersituation zuverlässig und wie zu erwarten?

Wie reagiert SQL-Server bzw. die durch AlwaysOn gesicherte Datenbank auf den Verlust der primären Anbindung (Ausfall der Festplatten oder SSDs)?

Um diese Frage zu klären haben wir folgende Testumgebung aufgebaut:

  • Betriebssystem-Plattform Windows Server 2012 R2
  • SQL Server 2012 SP1 CU2 (dabei ist der genaue Patchlevel unerheblich, das Folgende gilt für alle SQL Server 2012 ab RTM)
  • Anbindung der LUNs für die durch AO abgesicherte Test-DB mit iSCSI (internet Small Computer System Interface)
  • Einrichtung von Windows Server Failover Clustering
  • Bereitstellung einer Test-DB auf den iSCSI-LUNs
  • Einrichtung einer SQL Server AO Verfügbarkeitsgruppe

     

Abbildung 1: AlwaysOn Testaufbau

Wie in Abbildung 2 ersichtlich ist, befinden sich die Datenbanken momentan auf den beiden AlwaysOn Testservern in einem synchronisierten Zustand.

Abbildung 2: Synchrone Datenbanken im AO

 

Nun versuchen wir, den Ausfall der primären Disk-Anbindung zu simulieren, indem wir die Festplatte, auf der die Datenfiles der primären Datenbank liegen, im Disk Manager offline setzen.

Zu erwarten wäre, dass SQL Server 2012 den Ausfall bemerkt und entsprechend mit einem Failover darauf reagiert.

Abbildung 3: Simulierter Festplattenausfall

Wechselt man nun zum AO-Dashboard und refresht den AlwaysOn-Status, sieht man jedoch, dass dieses trotz „Ausfall“ der Festplatte weiterhin davon ausgeht, dass die Datenbanken synchron sind. Auch das SQL-Server Errorlog der primären Datenbankinstanz verzeichnet selbst Sekunden nach dem „Ausfall“ der Festplatte, auf der eigentlich die Datenfiles der Datenbank liegen, keine Probleme.

Kritischer Status:

Beim Zugriff auf ein beliebiges Datenbankobjekt in dieser Datenbank (hier mittels SQL Server Management Studio) erscheint dann allerdings folgende Fehlermeldung:

Abbildung 4: Hinweis: Zugriff auf DB nicht mehr möglich, DB-Check wird empfohlen

 

Als Administrator würde man basierend auf dieser Fehlermeldung vermuten, dass die Festplatte, auf der die Datenfiles der primären Datenbank liegen, defekt ist und als Korrekturmaßnahme einen Failover über AlwaysOn auslösen, um die Datenbank auf der vermeintlich synchronen sekundären Seite zu öffnen. Doch SQL Server kann in diesem Zustand mit gewisser Wahrscheinlichkeit nicht mehr auf die bis dahin synchrone zweite Datenbank failovern! Im SQL Server Errorlog der sekundären Datenbankinstanz taucht folgende Fehlermeldung auf:

 

AlwaysOn: The local replica of availability group ‚AOGroupSLM‘ is preparing to transition to the primary role in response to a request from the Windows Server Failover Clustering (WSFC) cluster. This is an informational message only. No user action is required.

The availability replica for availability group ‚AOGroupSLM‘ on this instance of SQL Server cannot become the primary replica. One or more databases are not synchronized or have not joined the availability group, or the WSFC cluster was started in Force Quorum mode. If the cluster was started in Force Quorum mode or the availability replica uses the asynchronous-commit mode, consider performing a forced manual failover (with possible data loss). Otherwise, once all local secondary databases are joined and synchronized, you can perform a planned manual failover to this secondary replica (without data loss). For more information, see SQL Server Books Online.

 

 

Fazit:

AlwaysOn verhält sich in einem solchen Fall auf den ersten Blick hin unerwartet:

  • Es wird kein Failover ausgelöst, wenn sich der Status einer der durch AO abgesicherten Datenbank ändert. Warum ist das so?
    Weil AlwaysOn keine Verfügbarkeitsprüfung auf Datenbankebene ausführt. Im Gegensatz zum Datenbankspiegel bietet AO wie SQL-Clustering die Möglichkeit, mehrere Datenbanken logisch zu gruppieren und bei Bedarf gemeinsam zu failovern. Dies ist für die Betrachtung des Verhaltens von entscheidender Bedeutung. Die Prüfung und Bewertung der Verfügbarkeit findet bei AlwaysOn nicht auf Ebene der einzelnen Datenbank statt, sondern auf der Ebene der SQL Server Instanz und der AO Availability Group. Dies ist ein entscheidender Unterschied zum Verhalten von Database Mirroring, denn Mirroring prüft die Verfügbarkeit der einzelnen abgesicherten Datenbanken und löst auch dann einen Failover aus, wenn die Verfügbarkeit der Datenbank auf dem primären Server beeinträchtigt ist.

    Dies ist im SAP Hinweis 1772688 (Login nötig) nachzulesen:
    „Letzteres hat auch eine Änderung in der Granularität von Health-Checks oder Indikationen erzwungen, die einen Failover auslösen könnten. Das Schließen einer Datenbank infolge von z.B. einem Datenträgerausfall löst in DBM einen Failover aus (wenn ein automatischer Failover konfiguriert ist). Wohingegen die Health-Checks in AlwaysOn hauptsächlich in der Verfügbarkeitsgruppe stattfinden und die SQL-Server-Instanz die Verfügbarkeitsgruppe als primär ausführt. Bei der Integritätsermittlung wird aber nicht der Zustand der einzelnen Datenbanken geprüft, die sich in der Verfügbarkeitsgruppe befinden. Folglich kann eine Datenbank innerhalb einer Verfügbarkeitsgruppe geschlossen werden, z.B. ausgelöst durch einen Datenträgerausfall, ohne dass die Verfügbarkeitsgruppe in einen problematischen Zustand gerät oder einen Failover auslöst (sofern der automatische Failover konfiguriert ist). Dies stellt im Vergleich zu DBM eine drastische Änderung im Verhalten und im Abdeckungsbereich dar. Insbesondere im Fall von Datenträgerausfällen, die durch sekundäre Auswirkung das Schließen von betroffenen SQL-Datenbanken verursachen, löst DBM einen Failover aus, wohingegen AlwaysOn in der Standardeinstellung keinen Failover auslöst.“

  • Die Datenbanken befinden sich nach einem Storage-Defekt auf Primärseite in einem vermeintlich asynchronem Zustand, sodass die in Wirklichkeit synchrone sekundäre Datenbank so geöffnet werden muss als wäre sie eine asynchron gehaltene Datenbank (‚with allow_data_loss‘)
    Dabei ist der Zustand der sekundären AO-Datenbank identisch zum Status der sekundären DBM-Datenbank bei einem vergleichbaren Datenbankfehler. Die Datenbanken sind mit beiden Technologien gleichartig synchron bzw. asynchron, AlwaysOn beurteilt hier jedoch konservativer, als DBM und ändert den Status der Sekundär-Datenbanken auf Out-of-Sync (wie es bei einem asynchron betriebenen Datenbankspiegel bzw. asynchronem AO generell und dauerhaft der Fall ist)

 

Das Verhalten beim Verlust von Log- oder Datenfiles ist bei AlwaysOn und Database Mirroring so lange identisch, bis die geschützte Datenbank geschlossen wird. Hier liegt der Unterschied zwischen den beiden HA-Lösungen in der Automatisierung. AlwaysOn bietet nur so lange Hochverfügbarkeit, wie die Integrität der Datenbankdateien der aktuellen Primärdatenbank gegeben ist. Geht die Primäre Datenbank z.B. durch Storage/SSD-Ausfall oder iSCSI-Verbindungsverlust verloren, wird die Datenbank je nach Laufzeitzustand als „out of sync“ markiert und erfordert ein manuelles Eingreifen. Database Mirroring dagegen schwenkt je nach Konfiguration automatisch bei Verlust von Daten- oder Logfiles auf den Spiegel.

Wenn mit einem manuellen Eingreifen und Starten des Spiegels die SLAs weiterhin erfüllt werden, spricht aus Sicht der Datenkonsistenz nichts gegen die Verwendung der Hochverfügbarkeitslösung SQL Server AlwaysOn.