teched 2009: SQL Server 2008 Failover Clustering

  • Article

Entgegen der landläufigen Meinung einen Cluster zu Installieren sei sehr aufwendig und kompliziert, haben wir in dieser Session gelernt, dass die Installation eines SQL 2008 Failover Cluster mit etwas Basiswissen und Dokumentation durchaus auch für “normalsterbliche” DBA’s möglich ist ;-).

Doch warum warum überhaupt clustern?

Die Failover-Clusterunterstützung in SQL Server bietet eine hohe Verfügbarkeit für eine gesamte SQL Server-Instanz für zwei Problemstellungen:

1. geplante downtime reduzieren (Upgrade patches)

2. ungeplante downtime reduzieren (Fehlerfall).

In beiden Fällen reduziert Failoverclustering maßgeblich die Downtime des SQL Servers, teilweise bis auf 0.

Was ist wichtig zu wissen?

image1. SQL Server-Failovercluster werden auf der Basis von Windows Server-Failoverclustern erstellt. Um einen SQL Server-Failovercluster zu erstellen, muss zuerst der zugrunde liegenden Windows Server-Failovercluster erstellt werden.

2. Bestehende SQL “stand-alone” Instanzen können NICHT in einen Cluster umgewandelt werden.

3. Die Installation eines Clusters ist ein eigener Punkt im Setup, auf jeder Node wird mit diesem Punkt ein SQL installiert und dann über einen zweiten Setup Punkt in den Cluster gehängt. (Install Node, Join Node)

3. Das Setup ist ziehmlich selbserklärend, es gibt ausreichende Dokumentation dazu (Whitepaper: https://download.microsoft.com/download/6/9/D/69D1FEA7-5B42-437A-B3BA-A4AD13E34EF6/SQLServer2008FailoverCluster.docx, MSDN (deutsch): https://msdn.microsoft.com/de-de/library/ms189134.aspx)

4. Für den darunterliegenden Windows Clsuter empfehlen wir Windows Server 2008 (R2). Neben einigen Verbesserungen im Clustermechanismus ist vorallem auch das Setup extrem vereinfacht und verkürzt worden (12 vs. 3 Schritte im Assistenten)

Wie verhält sich der Cluster im Fehler oder Upgrade Fall?

1. Der Failover (egal ob manuell oder automatisch) ist gleichbedeutend mit einem Restart einer Instanz, wobei die Zeitverzögerung minimal ist. Trotzdem verliert eine Client Applikation kurzzeitig die Verbindung zur Datenbank und sollte daher einen Retry-Mechanismus für die DB Connection eingebaut haben. Die “Ansprechdaten” (Servername, Instanznamen, usw.) bleiben natürlich gleich, es ist so als würde man kurz das Netzwerkkabel kappen.

2. Im Upgrade Fall (2005 –> 2008) kann mit 2 Nodes kein Failover während des Installationsprozesses stattfinden, da einer der 2 Knoten upgegraded wird und daher offline ist. Wenn die Installtion fertig ist und vom 2005er Node auf den “neuen” 2008er Node umgeschalten wird, müssen noch DB Aktualisierungsscripts laufen. Daher ist die Downtime bei diesem speziellen Failover länger als normal (wenige Minuten), diese Downtime muss aber unbedingt eingeplant werden! Ab 4 Nodes im Cluster ist auch ein Failover während des Upgrades möglich, da die Nodes immer paarweise upgegraded werden. Die Downtime vom Switch 2005 auf 2008 muss aber trotzdem einkalkuliert werden.

3. Ein Upgrade ist auch mit einem zusätzlichen Mirror Server möglich. In diesem Cluster + Mirror Szenario wird zuerst der Mirror und dann der Cluster aktualisiert.

Weiterführende Infos zu Installation, Betrieb und Hintergrundwissen:

Martin Pöckl von der teched 2009, Berlin
martin.poeckl@microsoft.com