A.4.1 Das System einrichten

Konfigurieren Sie die Computerhardware, die Netzwerkhardware, die Speicherhardware, die Betriebssysteme, die Benutzerkonten und andere grundlegende Systemressourcen entsprechend der dokumentierten Anforderungen für Sentinel sowie der lokalen Anforderungen des Kunden. Testen Sie die Systeme, um die ordnungsgemäße Funktion und Stabilität sicherzustellen.

A.4.2 Einrichtung des freigegebenen Speichers

Richten Sie Ihren freigegebenen Speicher ein und vergewissern Sie sich, dass Sie ihn auf jedem Clusterknoten einhängen können. Wenn Sie FibreChannel und ein SAN verwenden, könnten physische Verbindungen und weitere Konfigurationsschritte erforderlich sein. Der freigebene Speicher wird für die Datenbanken und Ereignisdaten von Sentinel verwendet. Er muss daher für die Kundenumgebung entsprechend groß sein, basierend auf der erwarteten Ereignisrate und den Datenbeibehaltungsrichtlinien.

Eine typische Implementierung könnte ein schnelles SAN verwenden, das über FibreChannel an alle Clusterknoten angehängt wird und über ein großes RAID-Array zum Speichern der lokalen Ereignisdaten verfügt. Ein separater NAS- oder iCSI-Knoten könnte für den langsameren Netzwerkspeicher verwendet werden. Wenn der Clusterknoten den lokalen Speicher als normales Blockgerät einhängen kann, kann er auch für die Lösung verwendet werden. Der Netzwerkspeicher kann auch als Blockgerät eingehängt werden oder könnte ein NFS- oder CIFS-Volume sein.

Die Beispiellösung verwendet iSCSI-Ziele, die auf einem virtuellen SUSE-Linux-Computer gehostet werden: Der virtuelle Computer ist storage03 wie in Das System einrichten aufgeführt. iSCSI-Geräte können über jede Datei oder jedes Blockgerät erstellt werden, doch einfachheitshalber verwenden wir hier eine Datei, die speziell zu diesem Zweck erstellt wird.

Stellen Sie eine Verbindung zu storage03 her und starten Sie eine Konsolensitzung. Erstellen Sie mit dem Befehl dd eine leere Datei jeder beliebigen Größe für den lokalen Sentinel-Speicher:

dd if=/dev/zero of=/localdata count=10240000 bs=1024

In diesem Fall erstellen wir eine 10 GB große Datei mit Nullen (kopiert von /dev/zero pseudo-device). Weitere Details zu den Befehlszeilenoptionen finden Sie in der Info oder auf der man-Seite für dd. Zum Beispiel zur Erstellung von „Datenträgern“ unterschiedlicher Größe. Das iSCSI-Ziel behandelt diese Datei, als ob sie ein Datenträger wäre. Sie könnten natürlich auch einen Datenträger verwenden, falls Sie dies vorziehen.

Wiederholen Sie diesen Vorgang, um eine Datei für den Netzwerkspeicher zu erstellen:

dd if=/dev/zero of=/networkdata count=10240000 bs=1024

Für dieses Beispiel verwenden wir zwei gleich große Dateien („Datenträger“) mit denselben Leistungseigenschaften. Für eine Produktionsbereitstellung könnten Sie den lokalen Speicher in ein schnelles SAN stellen und den Netzwerkspeicher in ein langsameres iSCSI-, NFS- oder CIFS-Volume.

Konfigurieren Sie diese Dateien als iSCSI-Ziele:

Mit der oben genannten Prozedur werden zwei iSCSI-Ziele am Server mit der Adresse 10.0.0.3 ausgewiesen. Stellen Sie sicher, dass die freigegebenen Speichergeräte mit den lokalen Daten in jedem Clusterknoten eingehängt werden können. Sie müssen die Geräte auch (einmal) formatieren:

Wiederholen Sie die Schritte 1-15 in der oben genannten Prozedur, um sicherzustellen, dass jeder Clusterknoten den lokalen freigegebenen Speicher einhängen kann. Ersetzen Sie die Knoten-IP in Schritt 5 jedoch durch eine andere IP (z. B.node02 > 10.0.0.2).

A.4.3 Sentinel-Installation

Zur Installation von Sentinel haben Sie zwei Möglichkeiten: Sie installieren jeden Teil von Sentinel im freigegebenen Speicher (und verwenden die Option „--location“, um die Sentinel-Installation dorthin umzuadressieren, wo der freigegebene Speicher eingehängt ist). Oder Sie stellen einfach die variablen Anwendungsdaten in den freigegebenen Speicher.

In dieser Beispiellösung folgen wir letzterem Ansatz und installieren Sentinel in jeden Clusterknoten, der es hosten kann. Wenn Sentinel zum ersten Mal installiert wird, nehmen wir eine vollständige Installation einschließlich der Anwendungsbinärdateien, der Konfiguration und aller Datenspeicher vor. Bei nachfolgenden Installationen in den anderen Clusterknoten wird nur die Anwendung installiert und es wird angenommen, dass die eigentlichen Sentinel-Daten später verfügbar werden (z. B. wenn der freigegebene Speicher eingehängt ist).

In dieser Beispiellösung installieren wir Sentinel in jedem Clusterknoten und speichern nur die variablen Anwendungsdaten im freigegebenen Speicher. Dadurch bleiben die Anwendungsbinärdateien und die Konfiguration an den Standardspeicherorten und wir können die RPMs überprüfen und auch in bestimmten Szenarien Patches im laufenden Betrieb anwenden.

Wiederholen Sie die Installation in anderen Knoten:

Das ursprüngliche Sentinel-Installationsprogramm erstellt ein Benutzerkonto, das von dem Produkt verwendet werden kann, welches zum Zeitpunkt der Installation die nächste verfügbare Benutzer-ID verwendet. Bei nachfolgenden Installationen im unbeaufsichtigten Modus wird versucht, dieselbe Benutzer-ID für die Erstellung von Konten zu verwenden, doch es besteht die Möglichkeit, dass Konflikte auftreten (wenn die Clusterknoten zum Zeitpunkt der Installation nicht identisch sind). Es wird dringend empfohlen, eine der folgenden Maßnahmen zu ergreifen:

Am Ende dieses Vorgangs sollte Sentinel in allen Knoten installiert sein, doch es funktioniert wahrscheinlich zunächst nur im ersten Knoten und in den anderen erst nach der Synchronisierung der verschiedenen Schlüssel, was nach der Konfiguration der Clusterressourcen der Fall ist.

A.4.4 Clusterinstallation

Installieren Sie die Clustersoftware in jedem Knoten und registrieren Sie jeden Clusterknoten mit dem Clustermanager. Die entsprechenden Prozeduren variieren abhängig von der Clusterimplementierung, doch am Ende des Vorgangs sollte jeder Clusterknoten in der Clusterverwaltungskonsole angezeigt werden.

In unserer Beispiellösung richten wir die SUSE Linux High Availability Extension ein und überlagern sie mit den Sentinel-spezifischen Resource Agents:

Wenn Sie zur Überwachung von Sentinel nicht den OCF Resource Agent verwenden, müssen Sie wahrscheinlich eine ähnliche Überwachungslösung für die lokale Clusterumgebung entwickeln. Der OCF Resource Agent für Sentinel ist ein einfaches Shell-Skript, das eine Reihe von Überprüfungen durchführt, um festzustellen, ob Sentinel funktionsfähig ist. Falls Sie selbst einen Resource Agent entwickeln möchten, sollten Sie den vorhandenen als Anleitung verwenden (der Resource Agent ist in der sentinel-ha.rpm im Sentinel-Download-Paket gespeichert).

Ein SLE HAE-Cluster kann auf viele verschiedene Arten konfiguriert werden, doch wir wählen Optionen aus, die die Konfiguration relativ einfach gestalten. Im ersten Schritt wird die SLE HAE-Software installiert. Alle Details zur Installation finden Sie in der Dokumentation für SLE HAE. Informationen zur Installation der SLES-Add-ons finden Sie im Bereitstellungshandbuch.

Sie müssen SLE HAE in allen Clusterknoten installieren, in unserem Beispiel node01 und node02. Mit dem Add-on werden neben der zentralen Software für die Clusterverwaltung und Kommunikation auch viele Resource Agents installiert, die zur Überwachung von Clusterressourcen verwendet werden.

Nach der Installation der Clustersoftware sollte ein zusätzlicher RPM installiert werden, um weitere Sentinel-spezifische Cluster-Resource Agents bereitzustellen. Der RPM ist in der Datei novell-Sentinel-ha-7.1*.rpm verfügbar, die im normalen Sentinel-Download gespeichert ist, den Sie zur Installation des Produkts entpackt haben.

Kopieren Sie in jedem Clusterknoten die Datei novell-Sentinel-ha-7.1*.rpm in das Verzeichnis /tmp und fahren Sie fort mit:

cd /tmp

rpm -i novell-Sentinel-ha-7.1*.rpm

A.4.5 Clusterkonfiguration

Sie müssen die Clustersoftware konfigurieren, um jeden Clusterknoten als Mitglied des Clusters zu registrieren. Als Teil dieser Konfiguration können Sie auch Fencing- und STONITH-Ressourcen einrichten, um die Clusterkonsistenz sicherzustellen.

In unserer Beispiellösung verwenden wir grundsätzlich die einfachste Konfiguration ohne zusätzliche Redundanz oder andere erweiterte Funktionen. Wir verwenden auch eine Unicast-Adresse (anstelle der bevorzugten Multicast-Adresse), weil sie weniger Interaktion mit den Netzwerkadministratoren erfordert und für Testzwecke ausreicht. Wir richten auch eine einfache SBD-basierte Fencing-Ressource ein.

Die Beispiellösung verwendet private IP-Adressen für die interne Clusterkommunikation und verwendet Unicast, um zu vermeiden, dass eine Multicast-Adresse von einem Netzwerkadministrator angefragt werden muss. Die Lösung verwendet auch ein iSCSI-Ziel, das auf demselben virtuellen Computer mit SUSE Linux konfiguriert ist, auf dem auch der freigegebene Speicher gehostet wird, um als SBD-Gerät für Fencing-Zwecke zu dienen. Wie zuvor können mit jeder Datei oder jedem Blockgerät iSCSI-Geräte erstellt werden, doch einfachheitshalber verwenden wir hier eine Datei, die wir für diesen Zweck erstellt haben.

Die folgenden Konfigurationsschritte sind denen zur Einrichtung des freigegebenen Speichers sehr ähnlich:

SBD-Einrichtung

Stellen Sie eine Verbindung zu storage03 her und starten Sie eine Konsolensitzung. Erstellen Sie mit dem Befehl dd eine leere Datei von beliebiger Größe:

dd if=/dev/zero of=/sbd count=1024 bs=1024

In diesem Fall erstellen wir eine 1 MB große Datei mit Nullen (kopiert vom Pseudogerät /dev/zero).

Konfigurieren Sie dieses Gerät als iSCSI-Ziel:

Durch diese Prozedur wird am Server unter der IP-Adresse 10.0.0.3 (storage03) ein iSCSI-Ziel für das SBD-Gerät angezeigt.

Knotenkonfiguration

Stellen Sie eine Verbindung zu einem Clusterknoten (node01) her und öffnen Sie eine Konsole:

Stellen Sie eine Verbindung zu jedem weiteren Clusterknoten (node02) her und öffnen Sie die Konsole:

Unter bestimmten Umständen wird die Clusterkommunikation nicht korrekt initialisiert. Wenn der Cluster nicht startet (der Dienst openais startet nicht):

In einigen Fällen kann im Skript ein Fehler auftreten, weil der Dienst xinetd den neuen Dienst csync2 nicht ordnungsgemäß hinzufügt. Dieser Dienst ist erforderlich, damit der andere Knoten die Clusterkonfigurationsdateien bis zu diesem Knoten synchronisieren kann. Wenn Sie Fehler wie csync2 run failed sehen, könnte dieses Problem bei Ihnen aufgetreten sein. Führen Sie zur Fehlerbehebung kill -HUP `cat /var/run/xinetd.init.pid aus und führen Sie anschließend das Skriptsleha-join erneut aus.

An diesem Punkt sollten Sie „crm_mon“ in jedem Clusterknoten ausführen können und sehen, dass der Cluster ordnungsgemäß ausgeführt wird. Alternativ können Sie „hawk“, die Webkonsole verwenden. Die Standardanmeldeberechtigung lautet „hacluster / linux“.

Für dieses Beispiel müssen wir zwei zusätzliche Parameter optimieren. Ob diese für den Produktionscluster eines Kunden gelten, hängt von dessen Konfiguration ab:

A.4.6 Ressourcenkonfiguration

Wie bereits im Abschnitt „Clusterinstallation“ erwähnt, ist für diese Lösung ein OCF Resource Agent erforderlich, um die zentralen Dienste unter SLE HAE zu überwachen. Sie können nach Wunsch auch Alternativen erstellen. Die Software hängt auch von verschiedenen anderen Ressourcen ab, für die Resource Agents standardmäßig mit SLE HAE bereitgestellt werden. Wenn Sie SLE HAE nicht verwenden möchten, müssen Sie diese zusätzlichen Ressourcen mit einer anderen Technologie überwachen:

Es gibt noch weitere Ressourcen wie MongoDB, die für die Sicherheitsintelligenz und den ActiveMQ-Nachrichtenbus verwendet wird. Zum jetzigen Zeitpunkt werden zumindest diese als Teil der zentralen Dienste überwacht.

Die Beispiellösung verwendet einfache Versionen der erforderlichen Ressourcen, wie den einfachen Resource Agent für das Dateisystem. Sie können komplexere Clusterressourcen wie cLVM (eine Version des logischen Volumes des Dateisystems) verwenden, falls erforderlich.

Die Beispiellösung stellt das Skript crm bereit, um die Clusterkonfiguration zu unterstützen. Das Skript zieht relevante Konfigurationsvariablen aus der Datei der unbeaufsichtigten Einrichtung, die als Teil der Sentinel-Installation erstellt wurde. Wenn Sie keine Einrichtungsdatei erstellt haben oder die Konfiguration der Ressourcen ändern möchten, können Sie das Skript entsprechend bearbeiten.

Stellen Sie eine Verbindung zum ursprünglichen Knoten her, in dem Sie Sentinel installiert haben (dies muss der Knoten sein, in dem Sie Sentinel vollständig installiert haben) und gehen Sie folgendermaßen vor (<SHARED1> bezeichnet das freigegebene Volume, das Sie oben erstellt haben):

mount /dev/<SHARED1> /var/opt/novell

cd /usr/lib/ocf/resource.d/novell

./install-resources.sh

Bei den neuen Ressourcen, die im Cluster auftauchen, könnten Probleme auftreten. Führen Sie /etc/rc.d/openais restart in node02 auf, wenn Sie ein Problem feststellen.

Das Skript install-resources.sh fordert Sie auf, einige Werte einzugeben, nämlich die virtuelle IP, die für den Zugriff auf Sentinel verwendet werden soll, und den Gerätenamen des freigegebenen Speichers. Die erforderlichen Clusterressourcen werden dann automatisch erstellt. Beachten Sie, dass das Skript ein bereits eingehängtes freigegebenes Volume benötigt sowie dass dafür die Datei der unbeaufsichtigten Installation, die bei der Sentinel-Installation erstellt wurde, vorhanden sein muss (/tmp/install.props). Sie brauchen dieses Skript nur im ersten installierten Knoten auszuführen. Alle relevanten Konfigurationsdateien werden automatisch mit den anderen Knoten synchronisiert.

Wenn die Kundenumgebung von dieser Beispiellösung abweicht, können Sie die Datei resources.cli bearbeiten (im selben Verzeichnis) und die Definitionen der Primitivdaten dort ändern. Beispielsweise verwendet die Beispiellösung eine einfache Dateisystemressource. Sie möchten stattdessen vielleicht eine eher Cluster-bewusste cLVM-Ressource verwenden.

Nach der Ausführung des Shell-Skripts können Sie einen crm-Statusbefehl ausstellen und die Ausgabe sollte folgendermaßen aussehen:

crm status

Last updated: Thu Jul 26 16:34:34 2012
Last change: Thu Jul 26 16:28:52 2012 by hacluster via crmd on node01
Stack: openais
Current DC: node01 - partition with quorum
Version: 1.1.6-b988976485d15cb702c9307df55512d323831a5e
2 Nodes configured, 2 expected votes
5 Resources configured.

Online: [ node01, node02 ]
stonith-sbd    (stonith:external/sbd):    Started node01
 Resource Group: sentinelgrp
     sentinelip    (ocf::heartbeat:IPaddr2):    Started node01
     sentinelfs    (ocf::heartbeat:Filesystem):    Started node01
     sentineldb    (ocf::novell:pgsql):    Started node01
     sentinelserver    (ocf::novell:sentinel):    Started node01

Zu diesem Zeitpunkt sollten die relevanten Sentinel-Ressourcen im Cluster bereits konfiguriert sein. Sie können nachprüfen, wie sie konfiguriert und im Clusterverwaltungswerkzeug gruppiert sind, indem Sie zum Beispiel den crm-Status ausführen.

A.4.7 Konfiguration des Netzwerkspeichers

Als letzten Schritt in diesem Prozess konfigurieren Sie den Netzwerkspeicher, sodass Sentinel Ereignispartitionen in günstigere Speicher migrieren kann. Dies ist optional und der Netzwerkspeicher braucht tatsächlich nicht so hochverfügbar zu sein wie das restliche System. Sie können jedes beliebige Verzeichnis (von einem SAN eingehängt oder auch nicht) oder ein NFS- oder CIFS-Volume verwenden.

Klicken Sie oben in der Menüleiste auf Speicher, wählen Sie Konfiguration aus und anschließend eines der Optionsfelder unter Netzwerkspeicher, das nicht für diese Einrichtung konfiguriert wurde.

Die Beispiellösung verwendet ein einfaches iSCSI-Ziel als freigegebenen Netzwerkspeicherort. Die Konfiguration entspricht in etwa dem lokalen Speicher. In Produktionsimplementierungen wären diese wahrscheinlich unterschiedliche Speichertechnologien.

Mit der folgenden Prozedur können Sie den Netzwerkspeicher für Sentinel konfigurieren:

Die Beispiellösung verwendet einfache Versionen der erforderlichen Ressourcen, wie den einfachen Resource Agent für das Dateisystem. Kunden können komplexere Clusterressourcen wie cLVM (eine Version des logischen Volumes des Dateisystems) verwenden, falls sie es wünschen.