Novell OES: Clusterressourcen

01.01.2007 von Martin Kuppinger

Der Aufbau von gemischten Clustern beim OES wurde bereits detailliert besprochen. In dieser Ausgabe folgen nun mehrere Artikel, in denen auf spezifische Teilaspekte des Umgangs mit Clustern eingegangen wird. Ein zentraler Punkt sind dabei die Clusterressourcen.

Eine Clusterressource definiert eine Ressource wie eine Website, eine Datenbank, einen DHCP-Server, den IP-Dienst für die gemeinsame Adresse oder einen anderen Dienst, der im Cluster bereitgestellt wird. Diese Ressource ist auf den verschiedenen Knoten im Cluster bekannt. Um clusterspezifische Funktionen wie das Failover nutzen zu können, muss man sie als Ressource definieren.

Die Verwaltung von Clusterressourcen kann mit dem iManager durchgeführt werden. Alternativ kann man auch die ConsoleOne verwenden, auf die in diesem Artikel allerdings nicht näher eingegangen wird.

Die Erstellung mit dem iManager

Im iManager finden sich die Clusterressourcen bei Cluster/Clusteroptionen. Nach Auswahl eines Clusters wird dort eine Liste der vorhandenen Clusterobjekte angezeigt (Bild 1). In der Liste finden sich die definierten Ressourcen, die Knoten im Cluster und die Schablonen, die bereits definiert wurden.

Bild 1: Die Liste von konfigurierten Ressourcen bei einem Cluster.

Auch Pools und andere gemeinsame Objekte werden angezeigt. Nach Auswahl eines Objekts kann man dieses mit Löschen wieder entfernen oder mit Eigenschaften die Konfiguration anpassen. Mit Neu lassen sich dagegen neue Objekte anlegen. Nach der Auswahl werden drei Optionen angezeigt:

Pool definiert einen neuen Pool, der gemeinsam im Cluster verwendet werden soll.
Ressource wird für die Erstellung einer Clusterressource auf Basis einer vorhandenen Schablone verwendet.
Schablone wird für die Erstellung einer neuen Schablone ausgewählt. Darauf wird weiter unten noch im Detail eingegangen.

Auswahl von Ressourcen und Schablonen

Bei Auswahl von Ressource wird ein weiteres Dialogfeld angezeigt, in dem man einen Namen eingeben muss. Außerdem kann die Schablone ausgewählt werden (Bild 2). Es empfiehlt sich, nur über Schablonen zu arbeiten. Falls man neue Arten von Ressourcen anlegen möchte, muss man also gegebenenfalls vorab eine geeignete Ressource definieren.

Bild 2: Die Erstellung einer neuen Cluster-Ressource und Schablone.

Die Schablonen finden sich unterhalb des Clusterobjekts im eDirectory. Als weitere Option kann hier angegeben werden, dass die Ressource nach der Erstellung gleich online gebracht werden soll. Diese Option sollte man mit Vorsicht nutzen. Es empfiehlt sich, die Konfiguration zunächst abzuschließen und eine Ressource anschließend explizit zum gewünschten Zeitpunkt online zu nehmen.

Die Option Zusätzliche Eigenschaften definieren sollte man dagegen gewählt lassen, um die weiteren erforderlichen Einstellungen vornehmen zu können. Die weiteren Schritte werden am Beispiel einer DHCP-Ressource erläutert, wobei die grundlegende Reihenfolge immer gleich ist.

Ladescript: Server anpassen

Im nächsten Schritt wird zunächst das Ladeskript angezeigt. Ein Ladeskript wird beim Laden einer Ressource ausgeführt. Bei einem DHCPServer muss dort der Server angegeben werden, auf dem der DHCP-Dienst zuerst installiert wurde. Dazu müssen die beiden Zeilen:

CLUSTER DHCP CN=SERVER.O=ORG.T=TREE

dhcpsrvr --servaddr=A.B.C.D

angepasst werden. In der ersten Zeile wird der korrekte Kontext, in der zweiten die IP-Adresse des Servers angegeben.

Der Parameter Zeitüberschreitung gibt an, in welchem Zeitraum das Skript ausgeführt werden muss, damit eine Ressource als verfügbar betrachtet wird. Der Standardwert von 10 Minuten ist natürlich zu lang gewählt, da Ressourcen in der Regel deutlich schneller online gebracht werden müssen. Zu kurze Werte bergen allerdings das Risiko, dass Ressourcen nicht schnell genug verfügbar werden.

Entladescript

Genauso wie ein Ladeskript gibt es auch ein Entladeskript. In diesem finden sich die Anweisungen, um einen Dienst auf einem Server zu beenden, wenn dieser auf diesem Knoten im Cluster nicht mehr ausgeführt werden soll, weil beispielsweise ein anderer Knoten die Kontrolle übernommen hat.

Bei DHCP wird dazu der entsprechende Dienst beendet, weil der DHCP-Server in einer solchen Situation keine Anforderungen mehr bearbeiten darf. Auch hier kann wieder eine maximale Ausführungszeit beim Parameter Zeitüberschreitung angegeben werden.

Bild 3: Die Einstellungen zu den Ressourcenrichtlinien.

Im folgenden Schritt müssen die Ressourcenrichtlinien mithilfe mehrerer Optionen definiert werden (Bild 3):

Ressource folgt Master: Diese Option muss ausgewählt werden, wenn eine Ressource nur auf dem Master-Knoten im Cluster ausgeführt wer den soll. Wenn dieser ausfällt, wird die Ressource automatisch auf dem Knoten gestartet, der die Rolle des Masters übernimmt.
Quorum ignorieren: Wenn diese Option gewählt wird, tritt das Quorum, das ja eine Mindestzahl von Systemen in einem Cluster ermittelt, nicht in Kraft. Die Ressource wird in diesem Fall auf jedem Knoten gestartet, sobald dieser online gebracht wird. Das kann für Ressourcen sinnvoll sein, die auch erforderlich sind, wenn sich der Knoten im nicht aktiven Teil eines nur teilweise verfügbaren Clusters befindet.
Startmodus: Hier kann angegeben werden, ob die Ressourcen automatisch oder manuell geladen werden sollen.
Failover-Modus: Dieser Parameter steuert das Failover, also die Übergabe im Fehlerfall. Diese kann automatisch oder manuell erfolgen. Ein automatisches Failover ist die Standardoption und in der Regel auch sinnvoll, um eine hohe Verfügbarkeit eines Clusters zu sichern.
Failback-Modus: Beim Failback-Modus kann neben diesen beiden Parametern auch Deaktivieren gewählt werden, um ein Failback vollständig zu verhindern.

Weitere Ressourcen-Einstellungen

Anschließend können noch der oder die bevorzugten Knoten in einem Cluster ausgewählt werden. Ebenso lässt sich die Failover-Reihenfolge für Systeme in einem Cluster modifizieren. Mit Fertigstellen wird die Ressource abschließend definiert. Sie steht damit im Cluster zur Verfügung.

Die Einstellungen können jederzeit geändert werden, wenn man eine Ressource auswählt und Eigenschaften anklickt, um die gesetzten Parameter betrachten und anpassen zu können. Dazu werden die Register Allgemein und Skripten verwendet. Das Register Geschäftskontinuität ist nur von Bedeutung, wenn die Business Continuity Cluster-Software installiert ist, mit der man einen Cluster aus Clustern erstellen kann, um ein Failover eines gesamten Clusters durchführen zu können, beispielsweise in einem Notfall-Rechenzentrum.

Ressourcen-Schablonen

Die Ressourcen basieren jeweils auf Schablonen. Schablonen lassen sich ebenso einfach erstellen wie Ressourcen. Schablonen können sogar auf anderen Schablonen basieren. Bei einer Schablone werden primär die Skripts angegeben. Diese Skripts bestehen wiederum aus den Start- und Ende-Befehlen für die Ressourcen.

Da es für wichtige Ressourcen bereits solche Schablonen gibt, hat man aber auch eine gute Basis, um sich daran zu orientieren. Das zeigt sich beispielsweise bei der Schablone für den MySQL-Datenbank-Server, der etwas mehr Startbefehle aufweist. Wichtig ist aber, dass die Befehle in einem Skript jeweils die sind, die auch an der Konsole angegeben würden.

Spezifische Ressourcen-Konfiguration

Bei einigen Ressourcentypen ist aber noch eine spezifische Konfiguration der Anwendungen erforderlich, damit diese korrekt mit den Novell Cluster Services zusammenarbeiten. Das Handbuch OES Cluster Services Resource liefert einen umfassenden Überblick über die spezifischen Anforderungen. Folgende Ressourcentypen werden standardmäßig unterstützt:

NSS Mirroring: Dabei handelt es sich um eine spezielle Variante der Spiegelung von NSS-Umgebungen. Die NSS-Volumes werden vollständig gespiegelt, wobei in der Regel ein über Fibre Channel verbundenes SAN verwendet wird.
Web Search: Bei Web Search geht es wie beim NSS Mirroring nur um die Realisierung einer fehlertoleranten Umgebung, da die Lastverteilung in diesem Fall über die Synchronisationsfunktionen erfolgt.
Tomcat: Tomcat-Umgebungen können ebenfalls fehlertolerant in einem Cluster aufgesetzt werden. Damit wird auch die Fehlertoleranz für die auf Tomcat basierenden Umgebungen geliefert.
Apache: Gleiches gilt für Apache. Wie bei Tomcat sind auch für die Einrichtung von Apache in einem Cluster einige zusätzliche Konfigurationsschritte auf der Ebene der Anwendung erforderlich.
DHCP: Auf die Definition von Ressourcen für diesen Dienst wurde bereits ausführlich in diesem Artikel eingegangen. Spezielle Anpassungen sind nur erforderlich, wenn durch den Cluster unterschiedliche IP-Subnetze in getrennten physischen Subnetzen unterstützt werden sollen.
iPrint: Auch die Print-Server-Funktionalität, die über iPrint angeboten wird, wird von den NCS (Novell Cluster Services) unterstützt. Der Konfigurationsaufwand ist in diesem Fall relativ hoch, weil auch eine gemeinsame Festplatten- Partition benötigt wird.
MySQL: MySQL kann in Kombination mit dem Extend Application Server konfiguriert werden. Auch hier sind einige Anpassungen auf Systemebene erforderlich, damit das Failover korrekt arbeitet.
DNS: Gleiches gilt für DNS. Auch hier wird gemeinsam genutzter Plattenplatz benötigt, um die Informationen austauschen zu können.
NetStorage: Ein weiterer standardmäßig unterstützter Dienst ist Novell’s NetStorage.

Über diese Dienste hinaus können auch weitere Anwendungen unterstützt werden. Das ist gegebenenfalls mit den Anwendungsherstellern zu klären. (hal))