SQL Server

Die besten Tipps für die SQL Server-Clusterbildung

Tom Moreau, PhD

Kurz zusammengefasst:

• Ausführen von SQL Server auf einem Cluster
• Hardware- und Softwareanforderungen
• Clusterbildung für einen Knotens
• Kostengünstige Optionen

Ein Servercluster ermöglicht Ihnen das Verbinden einer Reihe physischer Servern (oder Knoten), die einander als Failoverpartner dienen. Die von einem Cluster bereitgestellte Redundanz bedeutet mehr Betriebszeit für Ihre unverzichtbaren

Vorgänge. Ich habe bei meiner Arbeit mit SQL Server™ in den letzten 13 Jahren viele Cluster implementiert, bei denen es jeweils ganz spezielle Probleme gab. Diese Erfahrung hat zur Sammlung einer Reihe von Tipps geführt, mit deren Hilfe Sie die Clusterbildung erleichtern und erfolgreich gestalten können.

Servercluster nutzen die integrierten Clusterbildungsfunktionen der Enterprise-Editionen der Windows Server®-Produktfamilie. Tatsächlich ist Windows Server 2003 für die Clusterbildung wesentlich besser geeignet als Windows 2000 Advanced Server. Um die Vorteile der Clusterbildung zu maximieren, brauchen Sie die entsprechende Hardware, und das ist mit einigen Ausgaben verbunden. Es reicht nicht aus, ein paar Server mit einem freigegebenen Datenträger zusammenzufügen, und Sie können sich nicht auf die Tatsache verlassen, dass einzelne Hardwarekomponenten im Windows®-Katalog (früher als Hardwarekompatibilitätsliste bezeichnet) enthalten sind. Das System muss als Ganzes im Windows-Katalog enthalten sein. Doch keine Sorge – es gibt einige erprobte, kostengünstigere Clusterlösungen. Abbildung 1 zeigt eine typische Clusterkonfiguration.

Abbildung 1** Ein typischer Cluster **(Klicken Sie zum Vergrößern auf das Bild)

Natürlich ist bei der Clusterbildung mehr als die Hardware zu beachten. So müssen Sie beispielsweise auch die richtige Edition von SQL Server 2005 auswählen. Die Enterprise Edition ermöglicht die Clusterbildung, verfügt aber auch über andere nützliche Features, wie z. B. die Möglichkeit, mehr CPUs wirksam einzusetzen, verteilte und aktualisierbare partitionierte Ansichten, den integrierten Protokollversand und die automatische Verwendung indizierter Ansichten. Wenn Sie bereits über eine Enterprise Edition-Lizenz verfügen, sollten Sie die Clusterbildung in Betracht ziehen, unabhängig davon, ob Sie die zwei bis acht Server haben, die für einen traditionellen Cluster erforderlich sind (auf Einzelknotencluster komme ich gleich zu sprechen). Wenn Sie die SQL Server 2005 Standard Edition haben, können Sie einen Cluster mit zwei Knoten installieren.

Bei der Windows Server 2003 Enterprise bzw. Datacenter Edition ist die Clusterbildung integriert. Sie müssen nur die Clusterverwaltung ausführen, um Ihren Cluster einzurichten. Sie können alle Knoten auf einmal oder nacheinander hinzufügen. Bei der Installation von SQL Server können Sie ebenfalls entscheiden, einen einzelnen, nicht gruppierten Server zu installieren, oder Sie können eine virtuelle Instanz in einem Cluster installieren. Wenn Sie sich für die Installation einer virtuellen Instanz entscheiden, können Sie diese auf allen Knoten des Clusters, nur einigen Knoten oder sogar nur auf einem Knoten installieren.

Um das wahre Ziel einer hochverfügbaren Clusterlösung zu erreichen, brauchen Sie auch qualifizierte Mitarbeiter und eingespielte Verfahren, die bei Problemen befolgt werden. Obwohl die Clusterbildung eine gute Absicherung gegen Hardwarefehler ist, verhindert es keine Benutzerfehler, wie z. B. das Löschen einer wichtigen Tabelle durch einen übermüdeten DBA mitten in der Nacht.

Einzelknotencluster

Selbst wenn Sie derzeit nur einen einzelnen Server brauchen, sollten Sie das Erstellen eines Einzelknotenclusters in Betracht ziehen. Dies bietet Ihnen die Möglichkeit, später auf einen Cluster zu aktualisieren, sodass eine Neuerstellung vermieden wird. Sie müssen nur darauf achten, dass die von Ihnen ausgewählte Hardware im Clusterteil des Windows-Katalogs enthalten ist.

Doch hohe Verfügbarkeit ist nicht der einzige Grund für die Option, zu einem späteren Zeitpunkt einen Knoten hinzuzufügen. Bedenken Sie, was geschieht, wenn Sie feststellen, dass Ihr Server nicht über die notwendige Kapazität verfügt. In diesem Fall wäre eine aufwändige Migration erforderlich. Wenn Sie einen Einzelknotencluster haben, lässt sich eine Migration leichter mit weitaus weniger Ausfallzeit bewältigen. Sie fügen dem Cluster den neuen Knoten und dem neuen Knoten die SQL Server-Binärdateien und Service Packs hinzu und führen dann das Failover zum neuen Knoten durch. Dann fügen Sie etwaige Updates der Service Packs hinzu und entfernen schließlich den alten Knoten. Die Ausfallzeit beträgt nur die Zeit, die für das Failover und das Hinzufügen etwaiger Updates erforderlich ist.

Hinzufügen von Knoten

Da alle Knoten in einem Cluster gleich sein müssen, werden Sie lieber früher als später aktiv werden wollen, um diesen zusätzlichen Knoten einzurichten. Wenn Sie zu lange warten, könnte der Knoten nicht mehr in Produktion sein. Bei einem Projekt musste ich einen Knoten in einem SQL Server 2000-Cluster neu erstellen. Ich überließ dem Betriebssystem-/Netzwerkadministrator die grundlegende Einrichtung und übernahm dann das Hinzufügen zum Cluster und die Vorbereitung auf den Dienst als SQL Server-Knoten. Alles ging gut, bis ich das Failover auf den neuen Knoten durchführte. Zu meiner Bestürzung musste ich feststellen, dass sofort ein Failback erfolgte. Um es kurz zu fassen: Obwohl ich ein ausführliches Dokument für das Einrichten eines neuen Clusters einschließlich Hinzufügen des Clusterdiensts und der SQL Server-Dienstkonten zu beiden Knoten erstellt hatte, wurde das Dokument nicht genau befolgt. Der Administrator hatte dem neu erstellten Knoten nicht die Dienstkonten hinzugefügt, sodass die Berechtigungen, die vor der Neuerstellung bestanden, nicht mehr vorhanden waren.

Es dauerte ziemlich lange, diesen Fehler zu finden. Mir kam die Idee, mir eine lokale Gruppenmitgliedschaft anzuschauen. Nachdem ich die beiden Konten hinzugefügt hatte, verlief das Failover reibungslos. Ich dachte weiter darüber nach. Ein Knoten wird nicht häufig neu erstellt, und wenn man es tut, ist es ein Notfall. Obwohl ich ein Dokument geschrieben hatte, wurde es nicht verwendet. Wir hätten den Sicherheitsteil durch Schreiben eines kurzen Skripts zum Hinzufügen der beiden Konten und für andere notwendige Anpassungen automatisieren können. Bei SQL Server 2005 wurde dies jedoch verbessert. Das Installationsprogramm fordert Sie auf, Gruppen auf Domänenebene für die SQL Server-Dienstkonten festzulegen.

Dies regte mich noch weiter zum Nachdenken an. Es ist möglich, Skripts zu erstellen, die CLUSTER.EXE aufrufen, um dem MSCS-Cluster (Microsoft® Cluster Server) den Knoten hinzuzufügen. Dazu muss der Benutzer dem Skript nur den Namen des Knotens hinzufügen, und der Rest geht wie von selbst. In einem Notfall ist die Automatisierung wirklich von Vorteil.

N+1-Cluster

Manchmal ist der Grund für das Hinzufügen eines Knotens zu einem Cluster nicht das Ersetzen eines Knotens. Sie könnten Ihrem Cluster beispielsweise mehr SQL Server-Instanzen hinzufügen, und jede Instanz braucht separate Datenträgerressourcen. Obwohl mehrere Instanzen auf einem Einzelknoten ausgeführt werden können, würden sie die CPU und den Arbeitsspeicher gemeinsam nutzen, was zu schlechter Leistung führen kann. Im Idealfall sollte nur eine einzige Instanz auf einem Einzelknoten ausgeführt werden. Wie stellen Sie dies beim Failover sicher? Die Lösung besteht darin, dass auf einem Knoten keine Dienste ausgeführt werden, während auf den anderen Knoten jeweils eine SQL Server-Instanz ausgeführt wird. Das ist die Definition eines N+1-Clusters: N Instanzen werden auf N+1-Knoten ausgeführt. Der zusätzliche Knoten dient zur Sicherung.

Aktualisieren von SQL Server

Das Aktualisieren einer gruppierten Instanz von SQL Server ist nichts für schwache Nerven: Die Clusterbildung hat ihren Grund – Sie brauchen Betriebszeit. Doch SQL Server 2005 bietet eine Reihe von Verbesserungen, die Sie nutzen sollten, damit Sie im Falle einer notwendigen Clusterbildung ohne viel Ausfallzeit fortfahren können.

Welche Möglichkeiten haben Sie? Beginnen wir mit der teuersten Lösung: das Erstellen eines ganz neuen Clusters, was neue Server und möglicherweise ein neues SAN (Storage Area Network) erfordert. Sie können wahrscheinlich die vorhandenen Netzwerkschalter beibehalten, aber das ist auch schon alles. Offensichtlich ist dieser Ansatz nicht billig, aber er hat gewisse Vorteile. Neue Hardware zeigt im Allgemeinen viel bessere Leistung als alte, da Datenträgerkapazität und Geschwindigkeit ständig zunehmen. Daher wird die Leistung allein schon durch neue Hardware verbessert. Vielleicht sollten Sie sogar Ihre Ausrüstung leasen, um technisch immer auf dem neuesten Stand zu sein.

Wenn die Hardware vorhanden ist, können Sie Ihren neuen virtuellen SQL Server auf diesem Setup erstellen, Ihre Produktionsdatenbanken kopieren und dann das neue System auf gründlich prüfen, sodass vor dem Cutover-Tag viel Zeit für die Fehlerbehebung vorhanden ist. Sie sollten jedoch unbedingt dafür sorgen, dass ein Skript für die Übertragung der Anmeldeinformationen von Ihrem vorhandenen Server erstellt wird. (Informationen dazu finden Sie unter support.microsoft.com/kb/246133. Es ist auch gut, Ihr Anmeldebuildskript für einen eventuellen Totalausfall zu aktualisieren.)

Um die Ausfallzeit zu minimieren, müssen Sie wahrscheinlich den Protokollversand verwenden, es sei denn, Ihre Datenbanken sind recht klein und Ihnen steht ein Zeitraum zur Verfügung, in dem keine Benutzer verbunden sind. Sie können den Protokollversand praktisch bis kurz vor dem Cutover durchführen. Dann sperren Sie die Benutzer, beenden und senden das letzte Protokoll und weisen die Anwendung dann der neuen Instanz zu. (Der Abschnitt zur Datenbankspiegelung weiter unten enthält eine interessante Alternative für den Protokollversand.) Wenn Sie DNS-Aliase verwenden, müssen Sie die Anwendungen wahrscheinlich nicht einmal der neuen Instanz zuweisen. Aktualisieren Sie stattdessen den DNS-Alias. Dieser Ansatz hat den Vorteil, dass immer noch das Original vorhanden ist, wenn Sie nach teilweiser Migration das Original wiederherstellen müssen.

Es gibt auch eine kostengünstigere Möglichkeit, für die jedoch mehr Vorausplanung erforderlich ist. Ein Cluster kann mehr als eine SQL Server-Instanz unterstützen, doch jede Instanz muss über ihre eigenen Datenträgerressourcen verfügen. Wenn Sie daher Ihr SAN aufteilen, sollten Sie eine LUN für eine zukünftige Aktualisierung vorsehen. Zur Durchführung der Aktualisierung installieren Sie SQL Server-Binärdateien auf dieser Datenträgerressource. Sie können das System in Anspruch nehmen und, wenn Sie bereit sind, den aktuellen SQL Server herunterfahren, die Datenträgerressourcen von der alten SQL Server-Gruppe verschieben, die Abhängigkeiten aktualisieren und die neue SQL Server-Instanz online stellen. Fügen Sie die Datenbanken der alten Instanz hinzu, und alles ist betriebsbereit. (Sie haben vorher hoffentlich alles gesichert.)

Das ist der kostengünstigere Ansatz, doch er ist etwas riskanter. Wenn es Probleme gibt, können Sie die Datenbanken nicht von der neuen Instanz trennen und wiederherstellen. Sie müssen die Wiederherstellung dann mithilfe von Sicherungen durchführen und das kann zu beträchtlichen Ausfallzeiten führen.

Eine Alternative wäre, zwei Instanzen von SQL Server in Ihr SAN zu stellen, vorausgesetzt, es ist genug Platz vorhanden. Sie stellen die Produktionssicherungen (und den Protokollversand) für die neue Instanz wieder her und fahren dann wie zuvor beschrieben fort. Jetzt verfügen Sie jedoch über ein Sicherungssystem. Nach Durchführung der Migration können Sie die SAN-Ressourcen der alten Instanz freigeben. Kosten entstehen nur durch die zusätzlichen Datenträger.

Lastenausgleich

Zuerst soll hier mit einem häufig anzutreffenden Missverständnis aufgeräumt werden. MSCS-Clusterbildung dient zur Schaffung hoher Verfügbarkeit und nicht zum Lastenausgleich. Zudem verfügt SQL Server nicht über eine integrierte, automatische Funktion zum Lastenausgleich. Sie müssen den Lastenausgleich mithilfe des physischen Entwurfs Ihrer Anwendung durchführen. Was bedeutet das?

Wenn eine Tabelle an Größe zunimmt, ist mit einem Leistungsabbau zu rechnen, insbesondere dann, wenn Tabellenscans beteiligt sind. Wenn Millionen oder Milliarden von Zeilen vorhanden sind, bestand die traditionelle Lösung in der Verwendung partitionierter Ansichten, die aus Tabellen mit identischen Schemas bestehen, die mit UNION ALL-Anweisungen verbunden sind. Es werden auch CHECK-Einschränkungen bereitgestellt, um die Mitgliedertabellen zu unterscheiden, und dies verhindert eine Datenduplizierung in der partitionierten Ansicht. Wenn die in der CHECK-Einschränkung verwendete Spalte auch Teil des primären Schlüssels ist, wird die Ansicht aktualisiert.

Falls die Mitgliedertabellen in ihren eigenen Dateigruppen vorhanden sind, könnte die Datenträgerleistung verbessert werden, wenn die Dateien in diesen Dateigruppen auf separaten physischen Laufwerken vorhanden sind. Die Tabellen können sogar in separaten Datenbanken vorhanden sein. Bei SQL Server 2005 können Sie jedoch die Tabellenpartitionierung verwenden, solange sich alle Daten in derselben Datenbank befinden, wodurch die Implementierung sehr viel einfacher wird.

Doch angenommen, dass Sie Ihr Bestes mit der Tabellenpartitionierung oder (lokalen) partitionierten Ansichten getan haben, aber die Geschwindigkeit immer noch zu niedrig ist. Wenn Sie über SQL Server 2000 oder SQL Server 2005 verfügen, können Sie verteilte partitionierte Ansichten verwenden. Der Hauptunterschied besteht darin, dass sich die Mitgliedertabellen in verschiedenen Instanzen von SQL Server befinden können. Diese Instanzen können in einem N+1-Cluster installiert werden. Warum ist das eine gute Vorgehensweise? Wenn eine Mitgliedertabelle in einer partitionierten Ansicht in den Offlinestatus wechselt, gilt dies für die ganze Ansicht. Wenn diese Mitglieder dann Teil eines Clusters werden, verfügen Sie über die Zuverlässigkeit, die zur Unterstützung der Leistung und Bereitstellung des Lastenausgleichs erforderlich ist.

Brauchen Sie überhaupt einen Cluster?

Vielleicht gibt es bei Ihnen einige Ersatzserver, die nicht im Windows-Katalog für Cluster enthalten sind. Es wäre schade, neue Server zur Unterstützung eines Clusters zu kaufen, wenn diese Server verfügbar sind.

In diesem Fall könnte die Datenbankspiegelung eine reizvolle Alternative zur Clusterbildung sein. Bei der Spiegelung sind drei Elemente beteiligt: eine Instanz, in der die gespiegelte Datenbank residiert und die als Prinzipal bezeichnet wird, der als Spiegelserver bezeichnete Sicherungsserver und, falls Sie automatisches Failover wünschen, ein dritter Server, der als Zeugenserver bezeichnet wird. Eine Transaktion in einer Datenbank auf dem Prinzipal wird im Spiegel erneut ausgeführt. Wenn der Prinzipal ausfällt, kann ein Failover der Datenbank auf den Spiegelserver durchgeführt werden. Dies geschieht automatisch, wenn Sie einen Zeugenserver haben. Sie müssen die Spiegelung für alle Ihre Anwendungsdatenbanken einrichten, und es können keine Systemdatenbanken gespiegelt werden.

Der Spiegelserver ist im Unterschied zu einem Cluster eine getrennte Instanz von SQL Server und kann sich an einem weit entfernen Standort befinden. Seine Caches werden durch die Aktualisierungsaktivität aufgefüllt, die als Ergebnis der vom Prinzipal duplizierten Transaktionen stattfindet. Dabei wird natürlich angenommen, dass auf Spiegelservern keine anderen Aktivitäten als der Empfang der gespiegelten Transaktionen vom Prinzipal ablaufen. Das Failover läuft gewöhnlich schneller ab als in einem Cluster, da SQL Server bereits auf dem Spiegelserver ausgeführt wird. Da die Caches zumindest teilweise bereitstehen, ist die anfängliche Leistung nicht so gering wie dies im gruppierten Szenario der Fall sein könnte. Beachten Sie, dass die Rollen von Prinzipal- und Spiegelserver beim Failover einer gespiegelten Datenbank umgekehrt werden.

Der Nachteil der Datenbankspiegelung besteht darin, dass Sie im Gegensatz zu einem Cluster die doppelte Datenträgerkapazität benötigen. Sie brauchen auch mehr CPU-Leistung, wenn Sie den synchronen Modus ohne Datenverlust wünschen. Wie bereits erwähnt, ist hohe Verfügbarkeit nicht billig.

Ein kombinierter Ansatz

Da sich ein Spiegelserver weit entfernt vom Prinzipal befinden kann, ist dieses Verfahren eine gute Wahl für Notfallwiederherstellungen. Ihr Cluster kann Ihre erste Verteidigungslinie sein, doch was geschieht, wenn Sie sowohl Clusterbildung als auch Spiegelung einsetzen? Wenn bei einem Clusterfailover ein Zeuge als Teil Ihrer Spiegelungskonfiguration vorhanden ist, wird der Spiegel zum Prinzipal, während der gruppierte SQL Server in den Onlinestatus wechselt. Es ist jedoch zu beachten, dass das Failover vom neuen Prinzipal zurück zum (gruppierten) neuen Spiegel nicht automatisch verläuft. Folglich ist es besser, das automatische Failover für Ihre gespiegelten Datenbanken bei gleichzeitiger Verwendung eines Clusters nicht zu aktivieren.

Die Notfallwiederherstellung ist nicht der einzige Grund für die Verwendung der Spiegelung. Sie ist auch nützlich, wenn Sie bei Ihrem Prinzipal ein Service Pack oder Hotfix installieren müssen, wobei Sie das Failover auf den Spiegel manuell durchführen können. Beim Installieren des Service Packs oder Hotfixes ist der alte Prinzipalserver vorübergehend offline, und die Transaktionen auf dem neuen Prinzipal, für die ein Commit ausgeführt wurde, stehen in einer Warteschlange und warten darauf, an den neuen Spiegel (den alten Prinzipal) zurückgeschickt zu werden. Nach Installation des Service Packs oder Hotfixes findet die Synchronisierung statt, bis schließlich die beiden Server völlig synchron sind. Jetzt können Sie die Rollen von Prinzipal und Spiegel tauschen. Die Ausfallzeit betrug nur ein paar Sekunden bis zum Failover und Failback. Mithilfe dieses Ansatzes können Sie die Migration Ihres SQL Servers durchführen. Aber vermeiden Sie ein Failback.

Ein virtueller Server sorgt für mehr Flexibilität

Virtualisierung ermöglicht die gleichzeitige Ausführung von einem oder mehreren Betriebssystemen auf einem einzigen physischen Server. Virtualisierungssoftware erweitert das Clusterkonzept mit einer weiteren Funktionsschicht, da Sie die Software gruppieren können. Wenn der Server, auf dem der Host ausgeführt wird, versagt, wird ein Failover des Betriebssystems (und seiner Gastbetriebssysteme) auf einen Sicherungsknoten durchgeführt. Dies könnte eine sehr einfache Möglichkeit zum Migrieren eines Gastservers sein. Außerdem muss das Gastbetriebssystem nicht clusterfähig sein. Sie könnten also die SQL Server Workgroup Edition in einem als Gast ausgeführten Windows Server 2003 ausführen, das unter Microsoft Virtual Server 2005 in einem Cluster ausgeführt wird. Indirekt haben Sie praktisch eine Clusterbildung der Workgroup Edition durchgeführt (siehe Abbildung 2).

Abbildung 2** Verwenden eines virtuellen Servers **(Klicken Sie zum Vergrößern auf das Bild)

Alles unter Kontrolle

Wenn Sie für eine SQL Server-Implementierung verantwortlich sind, müssen Sie sich darauf verlassen können, dass Ihr Server immer verfügbar ist. Die Serverclusterbildung hilft sicherzustellen, dass dies immer der Fall ist. Dieser Artikel enthält einige grundlegende Tipps für Sie. In der Randliste „Clusterbildung für Ressourcen“ finden Sie weitere nützliche Informationen.

Clusterbildung für Ressourcen

Weitere Informationen zu den hier verwendeten Methoden und den verschiedenen Produkten, die Sie zur Einrichtung Ihres SQL Server-Clusters brauchen, finden Sie hier:

• SQL Server 2005 Failover Clustering (auf Englisch)
• SQL Server 2000 Failover Clustering (auf Englisch)
• Windows Server 2003 R2 Enterprise Edition–Cluster Server (auf Englisch)
• Microsoft Cluster Server Administrator’s Guide (auf Englisch)
• Microsoft Virtual Server 2005 R2 (auf Englisch)

Tom Moreau, PhD, BSc, PhD, MCSE, MCDBA, ist unabhängiger Berater, der sich auf die Verwaltung, den Entwurf und die Implementierung von SQL Server-Datenbanken spezialisiert hat. Er lebt in Toronto. Tom verwendet SQL Server seit 1993 und ist seit 2001 MVP. Er hat über 100 Artikel geschrieben und ist Mitverfasser eines Buchs über SQL Server. Besonderer Dank gilt SQL Server-MVP Geoff Hiten für seine hilfreiche Unterstützung.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.