Kapitel 3. Service Administration

Die folgenden Abschnitte beschreiben das Anzeigen, Aktivieren, Deaktivieren, Ändern, Umlagern und Löschen eines Service sowie die Behandlung von Services, die nicht starten. Es werden Beispiele für das Einrichten bestimmter Servicetypen gegeben.

3.1. Konfigurieren eines Service

Nachdem Sie den Festplattenspeicher eingerichtet und Applikationen zur Verwaltung durch den Cluster installiert haben, können Sie Services mit dem Cluster Configuration Tool konfigurieren, die diese Applikationen und Ressourcen verwalten.

Um einen Service zu Konfigurieren, folgen Sie diesen Schritten:

  1. Falls zutreffend, erstellen Sie ein Skript, das die im Service verwendeten Applikationen startet und beendet. Informationen hierzu finden Sie unter Abschnitt 3.1.2.

  2. Sammeln Sie Informationen über Ressourcen und Eigenschaften des Service. Informationen hierzu finden Sie unter Abschnitt 3.1.1.

  3. Richten Sie die vom Service benutzten Dateisysteme oder Raw-Geräte ein. Informationen hierzu finden Sie unterAbschnitt 3.1.3.

  4. Stellen Sie sicher, dass die Applikations-Software auf jedem der Cluster Systeme laufen kann und dass das Service-Skript, falls vorhanden, die Service-Applikation starten und beenden kann. Informationen hierzu finden Sie unter Abschnitt 3.1.4.

  5. Wenn Sie einen bestehenden Cluster aktualisieren, führen Sie ein Backup der Datei /etc/cluster.conf durch. Informationen hierzu finden Sie unter Abschnitt 2.2.

  6. Starten Sie das Cluster Configuration Tool und fügen Sie Services hinzu, geben Sie hierbei die Informationen über die Serviceressourcen und Eigenschaften, die Sie in Schritt 2 erhalten haben, an.

  7. Sichern Sie Ihre Konfiguration. Das Sichern der Einstellungen auf einem Cluster-Member überträgt diese automatisch auf die anderen.

Weitere Informationen zum Hinzufügen eines Cluster Service, finden Sie imfolgenden:

3.1.1. Sammeln der Service Information

Bevor Sie einen Service konfigurieren, sammeln Sie alle Informationen über die Serviceressourcen und Eigenschaften. In einigen Fällen ist es möglich, mehrere Ressourcen für einen Service anzugeben (zum Beispiel mehrere IP Adressen und Plattengeräte).

Die Eigenschaften und Ressourcen, die ein Benutzer im Cluster Configuration Tool angeben kann, sind in Tabelle 3-1 beschrieben.

EigenschaftBeschreibung
Name des ServiceJeder Service muss einen eindeutigen Namen haben. Ein Servicename kann von einem bis 63 Zeichen lang sein und muss aus Buchstaben (entweder Groß- oder Kleinbuchstaben), Ganzzahlen, Unterstrichen und Bindestrichen bestehen. Ein Servicename muss allerdings entweder mit einem Buchstaben, oder einem Unterstrich beginnen.
Failover Domain

Identifizieren Sie die Member, auf denen der Service laufen soll, indem Sie diesen mit einer bestehenden Failover Domain in Verbindung bringen.
Ist geordnetes Failover aktiviert, wird, wenn der Member auf dem der service gerade läuft, automatisch auf den nächsten Member in der Liste übertragen. (Präferenzen in der Reihenfolge wird durch die Abfolge der Member-Namen in der Failover Domain Liste bestimmt). Weitere Informationen findne Sie unter Abschnitt 2.9.

Check IntervallGibt die Frequenz (in Sekunden) an, in der das System die Funktionstüchtigkeit der mit dem Service assoziierten Applikation überprüft. Wenn Sie zum Beispiel einen Check Intervall, der nicht Null ist, für NFS oder Samba Services angeben, überprüft der Red Hat Cluster Manager, dass die notwendigen NFS oder Samba Daemons laufen. Für zusätzliche Servicetypen prüft der Red Hat Cluster Manager den Rückgabewert bei Ausführung der status Klausel des Applikations-Service-Skripts. Standardmäßig ist die Angabe des Wertes 0 für den Intervall Check, was bedeutet, dass die Überprüfung deaktiviert ist.
Benutzer-SkripteFalls zutreffend, geben Sie den vollständigen Pfadnamen für das Skript, das zum Starten und Beenden des Service verwendet wird, an. Weitere Informationen finden Sie unter Abschnitt 3.1.2.
IP Adresse

Eine oder mehrere Internet Protokoll (IP)-Adresse(n) können einem Service zugewiesen werden. Diese IP-Adresse (auch "schwebende" IP Adresse genannt) unterscheidet sich von der IP-Adresse, die mit dem Hostnamen (Ethernet-Schnittstelle) des Cluster-Systems assoziiert ist. Diese "schwebende" IP wird zusammen mit den Ressourcen des Service umgelagert, sollte ein Failover auftreten. Sollte ein Client diese IP-Adresse zum Zugriff auf den Service benutzen, wird dieser nicht wissen, auf welchem der Cluster-Systeme der Service läuft und ein Failover ist transparent zum Client.
Beachten Sie, dass die Netzwerkkarten der Cluster-Member im IP-Subnetz jeder der im Service benutzten IP-Adressen konfiguriert sein müssen.
Netmask- und Broadcast-Adressen für jede der IP-Adressen können auch angegeben werden. Sind diese nicht angegeben, benutzt der Cluster Netmask- und Broadcast-Adressen von der Netzwerkverknüpfung im Subnet.

GerätedateiGeben Sie jede im Service benutzte gemeinsame Diskpartition an.
Dateisystem und Sharing-Optionen

Sollte ein Dateisystem benutzt werden, geben Sie den Typ des Dateisystems, den Mount-Punkt, und jede Mount-Option an. Zur Auswahl stehende Mount-Optionen sind die des Standard Dateisystems, die auf der man-Seite mount(8) beschrieben sind. Es ist nicht nötig, Mount-Informationen für Raw-Geräte anzugeben (wenn im Service benutzt). Die ext2 und ext3-Dateisysteme werden unterstützt.
Geben Sie an, ob ein zwangsweises Unmount eines Dateisystems eingeschaltet werden soll. Ein zwangsweises Unmount erlaubt der Infrastruktur des Cluster Service Management ein Unmount eines Dateisystems auch dann durchzuführen, wenn auf dieses von einer Applikation oder durch einen Benutzer zugegriffen wird (auch wenn das Dateisystem beschäftigt ist). Dies geschieht durch das Beenden jeder Applikation, die auf dieses Dateisystem zugreift.
Sie können auch angeben, ob ein NFS Export des Dateisystems durchgeführt werden soll, und wenn ja, welche Zugriffsrechte angewendet werden sollen. Detaillierte Informationen finden Sie unterAbschnitt 5.1.
Geben Sie an, ob auf das Dateisystem über Samba von SMB-Clients aus zugegriffen werden soll.

Tabelle 3-1. Service Informationen zu Eigenschaft und Ressource

3.1.2. Erzeugen von Service-Skripten

Die Cluster-Infrastruktur startet und beendet den Service zu bestimmten Applikationen durch Ausführen von Service-spezifischen Skripten. Für NFS und Samba Services sind die assoziierten Skripte in die Cluster Service Infrastruktur eingebaut. Wenn Sie daher Cluster Configuration Tool zum Konfigurieren des NFS oder Samba Service verwenden, lassen Sie das User Script-Feld leer. Für andere Applikationen ist es notwendig, ein Service-Skript zu bestimmen. Zum Konfigurieren einer Datenbank-Applikation z.B.geben Sie den vollständigen Pfadnamen des entsprechenden Datenbank-Start-Skripts an.

Das Format des Service-Skripts muss den Konventionen des System V init Skripts folgen. Diese Konvention gibt vor, dass Skripte eine start, stop und status Klausel haben müssen. Diese sollten einen Rückgabewert von 0 für den Erfolgsfall haben.

Wenn ein Service nicht auf einem Cluster-Member starten kann, versucht der Red Hat Cluster Manager den Service auf einem anderen Member zu starten. Startet der Service auch nicht auf dem anderen Member, versucht der Red Hat Cluster Manager den Service auf allen Membern zu stoppen. Kann der Service nicht gestoppt werden, legt die Cluster-Infrastruktur den Service in den Fehlgeschlagen-Status. Administratoren müssen dann das Cluster Status Tool starten, den fehlgeschlagenen Service markieren und auf Deaktivieren klicken, bevor der Service wieder aktiviert werden kann.

Zusätzlich zum Ausführen von Start- und Stop-Funktionen werden Service-Skripte auch zur Überwachung von Service-Applikationen verwendet. Dies wird durch den Aufruf der status Klausel des Service-Skripts erzielt. Um die Service-Überwachung einzuschalten, geben Sie einen Wert ungleich 0 für das Check Intervall Feld im Cluster Configuration Tool an. Ist der Rückgabewert einer Statusüberprüfung ungleich 0, wird die Cluster Infrastruktur zuerst versuchen, die Applikation auf dem Cluster Member neu zustarten, auf welchem diese vorhergehend ausgeführt wurde. Status-Funktionen müssen nicht vollständig in Service-Skripten implementiert werden. Sollte keine wirkliche Überwachung durch das Skript ausgeführt werden, sollte eine Stub status Klausel vorhanden sein, die einen erfolgreichen Status zurückgibt.

Die Operationen, welche in der Status Klausel einer Applikation ausgeführt werden, können der Applikation und den Anforderungen von Seiten-spezifischen Parametern angepasst werden. Eine einfache Statusüberprüfung einer Datenbank, zum Beispiel, würde daraus bestehen, zu Verifizieren, dass der Datenbank Prozess noch läuft. Eine umfangreichere Überprüfung könnte aus einer Abfrage einer Datenbanktabelle bestehen.

Das Verzeichnis /usr/share/cluster/doc/services/examples/ enthält ein Template, das zur Erstellung von Service-Skripten benutzt werden kann, zusätzlich zu Beispielen von Skripten. Sehen Sie Abschnitt 4.1, Abschnitt 4.3, Kapitel 6 für Beispiels-Skripte.

3.1.3. Konfigurieren von Plattenspeicher des Service

Vor dem Erstellen eines Service richten Sie die gemeinsamen Dateisysteme und Raw-Geräte ein, die von diesem Service verwendet werden sollen. Weitere Informationen finden Sie unter Abschnitt 1.4.4.

Sollten Raw-Geräte in einem Cluster-Service eingesetzt werden, ist es möglich, die Datei /etc/sysconfig/rawdevices zu benutzen, um diese Geräte während des Hochfahrens zu binden. Bearbeiten Sie die Datei und geben Sie die Raw-Zeichengeräte und Blockgeräte an, die während jedem Hochfahren gebunden werden sollen. Sehen Sie Abschnitt 2.5 für weitere Informationen.

Beachten Sie, dass Software RAID und Host-basierte RAID nicht für gemeinsamen Plattenspeicher verwendet werden können. Lediglich zertifizierte SCSI Adapter-basierte RAID Karten können für gemeinsamen Plattenspeicher verwendet werden.

Sie sollten sich an die folgenden Empfehlungen für Service Plattenspeicher halten:

  • Für optimale Leistung benutzen Sie eine Blockgröße von 4 KB bei der Erzeugung von Dateisystemen. Beachten Sie, dass einige der mkfs-Utilities zur Erzeugung von Dateisystemen eine Standard-Blockgröße von 1 KB haben, welches lange fsck-Zeiten zur Folge haben kann.

  • Zur Unterstützung von kürzeren Failover-Zeiten wird empfohlen, ext3 Dateisysteme zu verwenden. Weitere Informationen finden Sie unter Abschnitt 1.4.4.6.

  • Für große Dateisysteme benutzen Sie die nocheck Option, um Code zu übergehen, der alle Blockgruppen auf der Partition überprüft. Die Angabe der Option nocheck kann die Zeitspanne, die für den Mount eines großen Dateisystems erforderlich ist, erheblich reduzieren.

3.1.4. Verifizieren der Applikations-Software und der Service-Skripte

Vor Einrichtung eines Service installieren Sie auf jedem System alle Applikationen, die vom Service auf jedem Member verwendet werden (oder jedem Member in einer Failover-Domain, falls verwendet). Verifizieren Sie nach der Installation der Applikationen, dass jede dieser ausführbar ist und Zugriff auf den gemeinsamen Plattenspeicher hat. Um die Korruption von Daten zu vermeiden, lassen Sie keine der Applikationen gleichzeitig auf beiden Systemen laufen.

Sollte ein Skript zum Starten und Beenden der Service-Applikation verwendet werden, installieren und testen Sie das Skript auf jedem der Cluster Systeme, und verifizieren Sie, dass dieses zum Starten und Beenden der Applikation verwendet werden kann. Weitere Informationen finden Sie unter Abschnitt 3.1.2.