Wird im MSSQL Umfeld Hochverfügbarkeit benötigt, ist eine der Lösungsmöglichkeiten die Verwendung von AlwaysOn Verfügbarkeitsgruppen. Diese setzen die Verwendung eines Windows Server Failover Clusters (WSFC) voraus. Kommt es hier zu Problemen mit dem Cluster, kann eine hohe Verfügbarkeit nicht mehr gewährleistet werden und somit geht der Sinn hinter der Verfügbarkeitsgruppe verloren. Darum beschäftigen wir uns heute mit häufigen Fehlern und wie man den Status des Clusters überwachen kann.
Windows Failover Cluster
Bevor wir uns jedoch Fehler anschauen, klären wir die Frage, was genau ein Failover Cluster ist. Wir beginnen mit dem Database Mirroring. Dieses Feature wurde von Microsoft eingeführt, um eine Datenbank auf sekundäre Kopien zu übertragen. Sollte das Original ausfallen, gibt es weitere Kopien, die stattdessen genutzt werden können. Doch damit dieser Wechsel, auch als Failover bezeichnet, automatisch stattfinden kann, muss eine weitere Instanz dazwischen geschaltet werden, welche als Witness fungiert. Dieser trifft die Entscheidung, wann eine Instanz nun wirklich nicht mehr verfügbar ist.
Auch wenn es noch technisch möglich ist, Database Mirroring zu verwenden, rät Microsoft davon ab. Eine AlwaysOn Verfügbarkeitsgruppe ist die moderne Version und eine bessere Alternative. Als Grundlage dient ein Windows Server Failover Cluster. Dies ist ein Feature von Windows Server und hat darum zunächst nichts mit MSSQL Server zu tun. Physische und auch virtuelle Maschinen werden miteinander zu einem Cluster verbunden, welches einen Service ausführt. Sollten Maschinen ausfallen, wird über ein Quorum entschieden, welcher Server die Rolle des Service Hosts übernimmt. Somit wird kein Witness mehr benötigt, wie es beim Database Mirroring der Fall war. Es kann jedoch noch ein Witness hinzugefügt werden, um die Anzahl der Stimmen besser zu regulieren. Das Cluster ist zudem mächtiger, da es nicht an SQL Server gebunden ist, sondern auch Datenbank unabhängige Aufgaben hochverfügbar machen kann. Somit bietet es mehr Funktionen und Einsatzmöglichkeiten. Neben dem Ausführen anderer Software, zählt dazu das Teilen von Dateien und Speicher, sowie das Ausführen einer gesamten SQL Server Instanz über das Cluster und nicht nur einzelner Datenbanken. Dies hat seine eigenen Vor- und Nachteile. Jedoch wollen wir uns mit der klassischen Availability Group beschäftigen.
Tipps zum Erstellen
Wir haben bereits einen Artikel darüber geschrieben, wie man eine Verfügbarkeitsgruppe erstellt und damit verbunden ein Windows Failover Cluster. Sollte etwas während des Erstellens schief gehen, gibt der Failover Manager entsprechende Fehlernachrichten aus, anhand derer das Problem gelöst werden kann. Wir haben ein paar Tipps zusammengefasst, damit es zu keinem Problem kommt.
- die Version des Betriebssystems muss auf allen Nodes dieselbe sein
- jede Node sollte eine IP-Adresse im gleichen Subnetz haben
- das Failover Cluster Feature muss auf allen Nodes installiert sein
- der Account zum Erstellen sollte genügend Rechte besitzen, damit ein Eintrag zum Active Directory hinzugefügt werden kann
Nun ist das Cluster erstellt und basierend darauf wurde eine AOAG erzeugt. Mit der Zeit können jedoch Problem aufkommen. Die Verbindung zu einer Node geht verloren, es kann auf Komponenten nicht zugegriffen werden oder andere Fehler treten auf. Doch wie kann man nachschauen, was gerade im Cluster passiert? Dafür stellen wir zwei Möglichkeiten vor.
Event Viewer
Die erste Möglichkeit ist der Event Viewer. Dies ist ein eigenes Tool von Microsoft. Hier werden Events, die im Cluster auftreten, gespeichert. Im Falle eines Fehlers erhält man eine entsprechende Beschreibung dazu.
Diese Einträge findet man im Ordner Application and Services Logs/Microsoft/Windows. Wurde das Failover Cluster Feature hinzugefügt, findet sich dort ein Ordner namens FailoverClustering. In der Operational Datei stehen die erfassten Events. Mit einem Klick auf das Filter Symbol, kann auch nach bestimmten Events geschaut werden. Eine Liste aller Events hat Microsoft im verlinkten Artikel zusammen getragen.
Cluster.log
Will man sich nicht durch alle Events durchkämpfen und hat keine Angst vor der PowerShell, kann man die zweite Möglichkeit nutzen. Denn dort gibt es einen Befehl, mit dem ein Log des Clusters erstellt wird, das sogenannte Cluster.log. Hier kann neben der Node des Clusters auch eine Zeitspanne angegeben werden. Die Daten werden an einem zu bestimmenden Ort gespeichert und können anschließend nach Excel importiert werden. Der Befehl, um diese Datei zu erstellen, lautet:
Sammlung von Fehlern
Nachdem wir nun wissen, wo wir nach Fehlern des Clusters schauen können, schauen wir uns ein paar häufige Fehler an. Neben den Ursachen wollen wir dabei auch auf mögliche Lösungen eingehen. Wir fangen dabei mit dem oben bereits angesprochenen Active Directory an. Sollte ein Fehler Nachrichten enthalten, wie
- “Cluster resource cannot be brought online. Unable to update password”,
- “Cluster resource failed registration” oder
- “Cluster resource could not be updated”,
dann ist eine häufige Ursache fehlende Berechtigung im Active Directory, bzw. im Domain Name Systems (DNS). Um das zu lösen, muss der Manager des entsprechenden Service geöffnet werden. Dort sucht man nach dem Namen, der im Fehler angegeben wurde und erteilt in den Einstellungen des Objekts die passenden Berechtigungen. Wenn Sie keinen Zugriff, oder selbst keine Rechte haben Änderungen zu machen, sollten Sie Ihren System-Administrator aufsuchen.
Das WSFC hat die Möglichkeit, einen File Share anzulegen. Dies ist ein Stück Speicher, auf den alle Nodes zugreifen können. Damit zusammenhängend gibt es einen häufigen Fehler, “failed to arbitrate for the files share”. Der Fehler sagt aus, dass auf den erstellten File Share nicht zugegriffen werden kann. Das lässt sich lösen, indem in den Einstellungen des Shares im Sicherheitsmenü entweder für Everyone oder nur ausgewählte Accounts vollen Zugriff gegeben wird.
Im Zusammenhang dieses Beitrags gehen wir davon aus, dass wir eine AOAG haben. Häufig gibt es dazu Listener. Auch diese können Fehlerquellen darstellen. Während des Erstellens dieses Listeners kann es passieren, dass kein Netzwerk Interface gefunden werden kann oder Teile des Clusters nicht online gebracht werden können. Das kann in zwei Situationen geschehen. Entweder sind alle Maschinen in unterschiedlichen Subnets. In dem Fall muss sicher gestellt sein, dass zu jedem verbundenen Subnet auch eine IP Adresse vorliegt. Auf der anderen Seite können alle Maschinen in demselben Subnet sein. Hier muss in der Network Interface Card (NIC) für jeden Server die gleiche primäre Subnet Mask verwendet werden. Nur wenn das der Fall ist, kann der Listener erstellt werden.
Weitere Fehler können, wie weiter oben schon erwähnt, an fehlenden Berechtigungen liegen. In den Nachrichten steht dann etwas wie
- “Cluster resource failed registration”, oder
- “ could not be updated”.
In beiden Fällen kann es helfen im NIC eine Option herauszunehmen. Dazu öffnet man die IPv4 oder IPv6 Einstellungen und nimmt den Haken beim Kästchen Register this connection’s addresses in DNS raus.
Ein weitere häufige Nachricht ist Quorum was lost. Mit dem Quorum wird entschieden, auf welche Maschine der Service bei einem Ausfall geschoben wird. Doch damit erfolgreich eine Entscheidung getroffen werden kann, benötigt das System eine Mehrheit. Wenn dieser Fehler auftritt, können nicht genügend Knoten miteinander kommunizieren, die eine Mehrheit bilden würden. Bei einem Cluster von bspw. 5 Knoten können nur noch maximal zwei Maschinen kommunizieren. Dies führt dazu, dass das Cluster vorsichtshalber offline genommen wird. Das Ganze kann behoben werden, indem entweder die Fehler auf den nicht verfügbaren Knoten korrigiert werden, oder der Quorum Threshold in den Einstellungen des Clusters angepasst wird.
Fazit
Wir hoffen, wir konnten Ihnen mit diesem Artikel die Funktion und Aufgaben eines Windows Failover Cluster näher bringen. Zudem sollten Sie nun wissen, wo Sie beim Auftreten von Fehlern im Cluster nachschauen können und wie Sie gängige Fehler schnell beheben können. Sollten darüber hinaus weitere Fragen aufkommen, stehen Ihnen unsere Expert:innen gerne zur Verfügung. Kontaktieren Sie uns gerne über unser Kontaktformular für ein unverbindliches Beratungsgespräch.
