Grundsätzlich gilt, dass viele der Schnittstellen, die auch sonst für die Überwachung des OES genutzt werden, auch für die Analyse von Clustern verwendet werden können. Dazu zählen beispielsweise die verschiedenen Funktionen für das Health Monitoring.
Zusätzlich gibt es aber auch spezielle Schnittstellen und Funktionen für die Überwachung von Clustern sowie Möglichkeiten, um clusterspezifische Aktivitäten wie die Migration von Ressourcen durchzuführen. Das Clusterereignisprotokoll wird Thema eines gesonderten Artikels in einen der nächsten Beiträge von Experts Inside Novell sein.
Der Cluster-Zustandsbericht
Im Bereich Cluster/Cluster-Manager des Novell iManager wird der Clusterzustandsbericht angezeigt (Bild 1). Es besteht aus einer Liste aller Ressourcen mit ihrem aktuellen Status. Im oberen Bereich finden sich auch die Knoten im Cluster mit ihrem aktuellen Zustand. Es gibt mehrere Zustandsinformationen, die über Farben und Symbole dargestellt werden.
Bei den Knoten selbst sind vor allem diejenigen zu beachten, die entweder explizit als fehlerhaft gekennzeichnet sind oder bei denen es kein Zustandssymbol gibt. Falls kein Symbol angezeigt wird, wie in Bild 1 bei der Ressource cluster3, so ist der Zustand des Knotens unbekannt. Das bedeutet, dass in jedem Fall der Administrator eingreifen muss, weil sonst der Cluster keine Kommunikation mit diesem Knoten durchführen kann. Das kann daran liegen, dass das System nicht arbeitet oder dass es ein grundlegendes Problem mit der Clustersoftware auf diesem Knoten gibt.
Zustände von Ressourcen
Bei den einzelnen Ressourcen wird zwischen verschiedenen möglichen Zuständen unterschieden. Der Idealzustand ist Läuft. Sehr klar ist auch offline als Zustand einer nicht aktiven Ressource. Die anderen Zustände sind aber wesentlich interessanter, auch wenn sei nicht allzu häufig auftreten. Hier gibt es folgende Situationen:
-
Alert: Dieser Zustand wird angezeigt, wenn bei der Konfiguration einer Ressource eine manuelle Startart definiert wurde und die Ressource nicht gestartet ist. Damit wird darauf hingewiesen, dass hier eine Aktivität erforderlich ist.
-
Comatose: Das ist einer der kritischen Zustände, weil sich die Ressource in diesem Fall in einem vom System identifizierten kritischen Zustand befindet, der sich nur durch den Eingriff eines Administrators beheben lässt.
-
Loading: Die Ressource wird aktuell geladen. Dieser Zustand sollte in den meisten Fällen nur kurz andauern, sodass auch kein Eingriff eines Administrators erforderlich ist.
-
NDS_Sync: Wenn dieser Zustand ausgegeben wird, müssen geänderte Eigenschaften einer Ressource noch im eDirectory synchronisiert werden. Solange dieser Vorgang nicht abgeschlossen ist, wird der entsprechende Hinweis angezeigt. In der Regel sind auch hier keine Eingriffe erforderlich. Falls es zu Replikationsproblemen im eDirectory kommt, sind die dafür „üblichen“ Maßnahmen zu ergreifen, also beispielsweise die differenzierte Analyse des Replikationsstatus und aktueller Replikationsprobleme mit DStrace.
-
Quorum wait: Bei diesem Zustand wartet die Ressource darauf, dass ein Quorum etabliert werden kann. Der Zustand kann darauf hindeuten, dass es zwischen den Knoten in einem Cluster Kommunikationsprobleme gibt.
-
Unassigned: Dieser Zustand tritt nur auf, wenn eine Ressource noch keinem Knoten zugewiesen wurde.
-
Unloading: Die Ressource wird aktuell beendet.
-
Upgrade: Die Ressource wird aktualisiert. Dieser Zustand tritt nur bei einer Aktualisierung der NCS auf.
Interessant im Zusammenhang mit den Zuständen von Clustern und ihren Ressourcen ist auch die Information darüber, wie oft sich der Zustand geändert. Diese Information findet sich bei jeder Ressource. Neben Failover- und Failback- Systemen wird der Wert auch durch den Start und das Herunterfahren von Clustern und manuelle Änderungen des Zustands wie das Offline- und Online-Nehmen von Ressourcen beeinflusst.
Cluster-Ressourcen migrieren
Zu den Aktivitäten, die für Ressourcen in einem Cluster durchgeführt werden können, zählt die Migration. Damit kann eine Ressource manuell auf einen anderen Knoten verschoben werden. Das ist sinnvoll, wenn man beispielsweise einen Knoten im Cluster für Wartungsarbeiten offline nehmen möchte.
Für die Migration muss die Ressource ausgewählt und anschließend Migrieren angeklickt werden. Im angezeigten Dialogfeld (Bild 2) kann der Knoten im Cluster ausgewählt werden, auf den die Migration erfolgen soll. Nach dessen Auswahl wird der Migrationsprozess vom Cluster Service gestartet und abgewickelt. Es empfiehlt sich, dabei die Stati der Ressource auf beiden Knoten zu überwachen, um bei etwaigen Problemen, beispielsweise weil ein Dienst nicht korrekt gestartet wird, eingreifen zu können.
Die Migration kann übrigens auch über den Novell Remote Manager (NRM) erfolgen. Dort finden sich ebenfalls Funktionen für das Cluster Management.
Konsolen-Anweisungen im Cluster
Für die Überwachung von Clustern sind auch einige der Befehle, die es an der Konsole gibt, von Bedeutung. Zu nennen sind hier insbesondere folgende Anweisungen:
-
Cluster stats display: Dieser Befehl zeigt Statistiken zu einem Knoten im Cluster an. Die Informationen werden nicht an der normalen Konsole angezeigt, sondern in der Cluster Log- Ansicht, also einer speziellen Konsole.
-
Cluster status: Mit diesem Befehl lassen sich allgemeine Informationen zum Status eines Clusters ausgeben. Dazu zählen auch die im Cluster definierten Ressourcen.
-
Cluster status dhcp: Durch zusätzliche Angabe des Ressourcennamens als Parameter können auch detaillierte Statistiken zu einer Ressource ermittelt werden. In diesem Fall würde also der Status der Ressource DHCP erfragt.
-
Cluster view: In ähnlicher Weise wie mit Cluster stats display können auch hier Informationen zu einem Cluster ermittelt werden. Dazu zählt unter anderem eine Liste der Knoten mit ihrem aktuellen Zustand.
-
Cluster resources: Um einen Überblick über die Ressourcen in einem Cluster zu erhalten, wird dieser Befehl verwendet. Die Ressourcen müssen nicht online sein, um in der Liste angezeigt zu werden.
Mithilfe der verschiedenen Befehle kann man sich relativ einfach einen Überblick über den Status eines Clusters verschaffen. Allerdings wird man sich auch überlegen müssen, ob das ausreicht. Denn gerade bei Clustern ist eine permanente Überwachung erforderlich, um auf Fehler schnell reagieren zu können. Hier sind Werkzeuge wie Novell Audit mit einer entsprechenden Konfiguration für automatische Warnungen und Maßnahmen ein Ansatz.
Eine weitere Möglichkeit sind Benachrichtigungen in einem Cluster. Auf sie wird in einem nachfolgenden Artikel noch näher eingegangen.