Cluster – Einrichtung unter Windows Server 2003
Nachdem ich mich den Grundlagen von Clustern und Voraussetzungen für emulierte Storages gewidmet habe, folgt nun der dritte Teil in der Reihe “Wie richte ich einen Cluster ein?”. Microsoft kennt bis zum Windows Server 2008 nur Aktiv/Passiv-Cluster. Zwar kann der iSCSI Initiator Multipathing, da das System keinen parallelen Zugriff auf Network Storages unterstützt, kann auf diese Funktion nicht zugegriffen werden. Zwar spricht man bei speziellen Installationen von Aktiv/Aktiv-Cluster, doch ist dies nur die halbe Wahrheit.
Oftmals zeichnet sich ein solches Szenario ab, wenn auf die Knoten eines Clusters mehrere Dienste (Bsp. MS Exchange) verteilt wurden. Fällt ein Knoten aus greift das Failover, die Dienste der ausgefallenen Node nehmen ihren Dienst auf dem intakten Knoten wieder auf. Im Prinzip das Verhalten eines Aktiv/Passiv-Cluster. Nur das der passive Knoten bereits durch einen anderen Dienst in Benutzung und damit aktiv ist. Erst ab Windows Server 2008 R2 ist ein Zugriff auf Shared Volumes möglich.
Welche Voraussetzungen sind nun notwendig, um auf Windows Server 2003 (W2K3) ein Cluster einzurichten?
-
Windows Server 2003, Enterprise oder Datacenter Edition
-
min. 2 Netzwerkkarten
-
Network Storage
-
iSCSI Initiator oder andere Connektoren
-
Service Account
Die Server benötigen zwei Netzwerke, ein Public und ein Private (Cluster) Netzwerk. Das erhöht die Performance und Verfügbarkeit. Bei Ausfall eines Netzes kommunizieren die Nodes über das zweite, verfügbare Netz. Bereits zu Beginn konfigurieren wir die Netzwerkkarten und prüfen mittels Ping die Konnektivität. Optional kommt noch ein Netzwerk zu den Storages hinzu. Damit läuft auch der Datenverkehr dediziert, was wiederum die Performance verbessert.
Anschliessend nehmen wir die Rechner in die Domäne auf, sie müssen Mitgliedserver sein. In unserem Szenario nummerieren wir die Nodes durch. Dabei steht der Name Cluster für unseren gemeinsamen Verbund, die Nodes erhalten zusätzlich Ziffern.
-
Cluster.Contoso.Com = Compute Cluster
-
Cluster01.Contoso.Com = Node 1
-
Cluster02.Contoso.Com = Node 2
Nun binden wir die Storages via iSCSI Initiator auf allen Knoten ein. Wichtig! Die Datenträger dürfen über die Datenträgerverwaltung nur auf einem Knoten zugewiesen werden. Alle weiteren Clustermitglieder übernehmen diese Einstellungen. In diesem Szenario haben wir das Quorum und die LUN des Nutzdatenträgers eingebunden.
Im Clusterbetrieb werden die Datenträger dynamisch de-/aktiviert, wie das folgende Beispiel einer Node zeigt.
Nun erstellen wir in DNS den öffentlichen Namen des Verbundes und verknüpfen ihn mit der Public IP, über die er erreichbar ist.
Damit haben wir die wichtigsten Vorbereitungen abgeschlossen.
Der Cluster wird über die Clusterverwaltung eingerichtet. Im Dialog wählen wir den ersten Punkt “Neuen Cluster erstellen” aus.
Der Assistent erläutert die notwendigen Voraussetzungen, welche wir im Vorfeld erfüllt haben. Es empfiehlt sich einen Service Account extra für den Cluster anzulegen, keinen bestehenden oder gar ein Benutzerkonto zu nutzen. Über diesen Account läuft der Clusterdienst. Er benötigt keine besonderen Rechte, es reicht die Standardgruppe “Domänen-Benutzer”. Im nächsten Fenster geben wir den Namen und die Domäne des Clusters an. Anschließend wählen wir den ersten Knoten. Unter “Erweitert” prüfen wir dass die typische Konfiguration ausgewählt haben. Die folgende Konfigurationsanalyse kann Warnungen oder Fehler auswerfen. Diese sollten unbedingt geprüft und beseitigt werden. In unserem Fall wird das “Netzwerklastenausgleich”-Protokoll moniert, welches wir umgehend deinstallieren.
Nach der Eingabe der IP-Adresse unter dem der Cluster, nicht die Node (!), erreichbar ist, geben wir den Service Account und die Anmeldedaten an. Er sollte vorzugsweise Administrationsrechte auf den Knoten haben. Der Assistent informiert in der Zusammenstellung über alle getätigten Eingaben.
Das Cluster wird eingerichtet, sobald man den Assistent beendet. Nach geraumer Zeit ist der Vorgang abgeschlossen. Zusätzlich sollte das Ereignisprotokoll überprüft werden.
Alle Ereignisse sämtlicher Clustermitglieder werden auf jeder Node gesammelt im Ereignisprotokoll angezeigt. Bei Fehler oder Warnungen ist also auch auf die Quelle zu achten.
Wir finden nun zwei Clustergruppen. Die erste Gruppe “Clustergruppe” beinhaltet das Quorum und dient der Verwaltung des Verbundes. Befanden sich weitere Ressourcen am Computer, hat der Assistent diese automatisch in eine weitere Gruppe eingebracht.
Die Clustergruppe “File Server” zeigt bereits auf den zuvor eingebundenen Datenträger D:. Erstellt man nun eine neue Ressource, erscheint er unter dem Cluster. Dazu geht man auf die Clustergruppe und fügt bspw. eine Dateifreigabe hinzu. Es sind die zuständigen Knoten und der dafür zu nutzende Datenträger auszuwählen. Dann wird die Freigabe noch um diverse Optionen ergänzt. Der Pfad zeigt auf den Ordner, welcher allerdings noch manuell erstellt werden muss. Sobald fertig gestellt, ist die Ressource offline, muss daher noch online gestellt werden. Voilá! Ein geclustertes File Share hat die Welt erblickt.
Doch Moment! Ein aktiver Knoten? Fehlt da nicht noch die passive Node? Tatsächlich haben wir bisher nichts als einen Server im Cluster. Fällt dieser aus, ist das File Share nicht erreichbar. Doch genau das wollten wir doch erreichen. Also flink wieder zurück in die Clusterverwaltung. Im Kontextmenü des Cluster entdeckt man unter “Neu” die Möglichkeit einen weiteren Knoten hinzuzufügen. Der Assistent zeigt sich ähnlich wie bei der Einrichtung des Clusters. Es wird der entsprechende Server ausgewählt und als Node hinzugefügt. Zugleich folgt die Analyse und Bestätigung des Kennwortes vom Service Account. Abschliessend wird das Cluster um den oder die Server erweitert. Ist der Server eingetragen, übernimmt er den passiven Status. Wir finden seine Konfiguration nun in der Clusterverwaltung.
Die Managentkonsole besteht aus drei grundsätzlichen Abschnitten und den hinzugefügten Knoten. In ersten Bereich “Gruppen” werden Ressourcen in logische Einheiten unterteilt. Sie stehen auf dem jeweils aktiven Server bereit und bieten bestimmte Dienste wie Quorum, File Shares oder SQL-Instanzen an. Unter dem Abschnitt “Ressourcen” befinden sich alle Kapazitäten des Clusters. In der “Clusterkonfiguration” finden wir unsere Schnittstellen, die Netzwerke wieder. Ebenso werden dort unterstützte Typen wie der DHCP-Dienst angezeigt. Aus diesen Diensten können wir geclusterte Ressourcen erstellen.
Kommen wir auf unser Beispiel mit der Dateifreigabe zurück. Wollen wir doch mal sehen ob wirklich alles funktioniert. Geht man über den Windows Explorer auf den Cluster, erscheint die Ordnerfreigabe. Stopp! Das geht nur wenn man Glück hat und auf den aktiven Cluster kommt, auf dem das File Share angelegt wurde! Doch ist das Quorum zur Zeit auf einem anderen Knoten, sieht man nichts. Warum ist das so? Weil wir gar kein zentrales File Share haben! Jetzt kommen wir zu den Gruppen zurück. Jede Gruppe kann man als eine Art Server betrachten. In unserer “Clustergruppe” befinden sich diverse Ressourcen, unter anderem Netzwerkname und IP-Adresse. Das hat aber unsere File Server-Gruppe nicht. Also kann man diesen File Server gar nicht ansprechen.
Flugs erstellen wir eine neue Ressource vom Typ “IP-Adresse” , vergeben eine neue IP unter der der File Server erreichbar sein soll. Doch auch einen aussagekräftigen Servername brauchen wir, daher erstellen wir eine weitere Ressource vom Typ “Netzwerkname”. Diese Ressourcenart, das ist wichtig, steht immer in Abhängigkeit zu einer IP-Adresse. Wir wählen daher die zuvor angelegte IP-Ressource. Wir können abschliessend den Namen in DNS registrieren lassen oder aber wir erstellen diesen A-Record händisch. Nicht vergessen die Ressourcen zu aktivieren.
Doch funktioniert das Konstrukt denn nun? Gehen wir auf “\\fileserver.contoso.com”, erscheint unser File Share. Und das bleibt auch dann, wenn das Quorum auf einer anderen Node liegt. Und im Störfall wandert es auf den funktionsfähigen Server. Um das zu testen beenden wir kurzerhand den Clusterdienst des cluster01.contoso.com. Schauen wir auf den File Server, so steht das Share dem geneigten Benutzer immer noch zur Verfügung. Nur der NetBIOS-Name des cluster02 verrät uns, dass das Share auf einen anderen Clusterknoten gewandert ist.
Das Failover-Prinzip funktioniert. Apropos Failover. Das Verhalten bei Störung wird über die einzelnen Clustergruppen gesteuert. Unter Eigenschaften kann man den bevorzugten Server, die Werte zu Failover und Failback angeben. Failover tritt immer dann auf, wenn ein aktiver Server ausfällt. Wird der Schwellenwert, Default 10 Störungen, in einem definierten Zeitraum, Default 6 Stunden, überschritten, übernimmt der Ersatzserver die Aufgaben des ausgefallenen Knotens. Ist dieser nach einiger Zeit wieder einsatzbereit, werden die Dienste nach den eingestellten Failback-Werten auf den bevorzugten Server umgezogen.
Mit diesen Informationen schliesse ich unsere heutige Exkursion in die Cluster-Welt. Über Anregungen, Fragen, zusätzliche, wertvolle Informationen und auch einfach nur einem Dankeschön freue ich mich jederzeit.