Die Eigenschaften für einen Cluster werden im Bereich Cluster/Clusteroptionen des Novell iManager festgelegt. Nach der Auswahl eines Knotens in einem Cluster, der administriert werden soll, wird im Bereich Cluster/Clusteroptionen direkt unter dem Eingabefeld Cluster die Schaltfläche Eigenschaften angezeigt.
Ein Klick darauf bringt eine Maske zum Vorschein, über die die spezifischen Festlegungen für den Cluster vorgenommen werden können. Dort gibt es vier Register, wobei das Register Geschäftskontinuität nur verfügbar ist, wenn die entsprechenden Erweiterungen für den Clusterdienst installiert sind.
Allgemeine Festlegungen
Im Register Allgemein (Bild 1) lassen sich allgemeine Einstellungen zu einem Cluster vornehmen. Bei Clusterinformationen werden die gemeinsame IP-Adresse des Clusters und die Portnummer für die clusterspezifische Kommunikation festgelegt. Die Portnummer bezieht sich logischerweise nicht auf andere Zugriffe. Wenn beispielsweise Apache genutzt wird, läuft das in aller Regel über den Port 80.
Der Quorum-Auslöser konfiguriert das Verhalten des Quorums. Hier gibt es zwei Parameter:
-
Die Knotenzahl legt fest, wie viele Knoten in einem Cluster erreichbar sein müssen, damit Ressourcen geladen werden. Dieser Wert sollte in der Regel der erste ganzzahlige Wert sein, der größer ist als die Hälfte der Anzahl von Knoten in einem Cluster. Bei drei Knoten sollten also mindestens zwei verfügbar sein, bei acht Knoten mindestens fünf.
-
Wie bei anderen Cluster-Lösungen wird aber ohnehin nur der „größere“ Teil eines Clusters genutzt. Die Zeitüberschreitung definiert zwar, wie lange gewartet wird, bis die Ressourcen auf Knoten geladen werden, bei denen das Quorum also die Anzahl der bekannten Knoten noch nicht erreicht ist. Das bedeutet aber nicht, dass nach einiger Zeit auch im kleineren Teil eines Clusters, bei dem die Kommunikation unterbrochen ist, die Ressourcen geladen werden. Man könnte diese Situation durch ein hohes Timeout weitgehend verhindern. Wie problematisch eine solche Situation wäre, hängt von der Art der Anwendungen ab.
Probleme im Cluster vorhersehen und beseitigen
Da in einem nicht vollständig verfügbaren Cluster häufig auch gemeinsam verwendete Datenträger zumindest für einen Teil der Knoten nicht verfügbar sind, reduzieren sich die potenziellen Probleme, weil nur Anwendungen kritisch sind, bei denen Daten unsynchronisiert verändert werden könnten – und genau diese benötigen einen gemeinsamen Datenträger.
Effektiv gelöst wird das Problem aber durch die Art und Weise, wie die NCS mit sogenannten Split-Brain- Bedingungen umgehen, also genau den Situationen, in denen unterschiedlich große Teile eines Clusters voneinander getrennt sind. Falls diese immer noch auf einen gemeinsamen Datenträger zugreifen können, wird die Situation erkannt und der kleinere Teil des Clusters offline genommen.
Im selben Register können schließlich noch Festlegungen zur Benachrichtigung in einem Cluster vorgenommen werden. Diese sind für eine schnelle Reaktion auf Fehler, die in einem Cluster auftreten können, von hoher Bedeutung. Wenn die Benachrichtigung aktiviert ist, lässt sich eine Liste von E-Mail-Adressen definieren, die auch mehrere Adressen umfassen kann, um zum Beispiel verschiedene Operatoren erreichen zu können.
Darunter wird festgelegt, welche Informationen verteilt werden sollen. Die Empfänger können entweder nur über kritische Ereignisse oder generell über auftretende Ereignisse informiert werden. Reizvoll ist die Option, die Meldungen als XML-Dokument zu senden. Solche Mails können einfacher automatisiert analysiert werden.
Einstellungen zu den Prioritäten
Deutlich weniger Optionen finden sich im Register Prioritäten (Bild 2). Die Priorität von Ressourcen beeinflusst insbesondere die Startreihenfolge.
Das ist wichtig, weil es häufig Abhängigkeiten zwischen verschiedenen Ressourcen in einem Cluster gibt. Dies gilt insbesondere für Pools und andere Speicherressourcen, die verfügbar sein müssen, damit andere Ressourcen wie beispielsweise DNS überhaupt gestartet werden können.
Festlegungen für Protokolle
Das Register Protokolle (Bild 3) bietet wieder ein etwas größeres Spektrum an Einstellmöglichkeiten. Der erste Parameter ist der Takt, der in Sekunden angegeben wird. Dieser wird auch als Heartbeat bezeichnet. Der Standardwert ist 1. Das bedeutet, dass die Knoten im Cluster einmal pro Sekunde eine Nachricht an den Master-Knoten im Cluster senden, in dem sie diesen über ihren aktuellen Status informieren.
Die Einstellung Toleranz, die ebenfalls in Sekunden angegeben wird, legt fest, nach welchem Zeitraum eines fehlenden Heartbeats ein Knoten vom Master-Server aus dem Cluster entfernt wird. Der Zeitraum von acht Sekunden als Standard ist relativ knapp gewählt. Man muss hier einen sinnvollen Kompromiss zwischen einer kurzen Nichtverfügbarkeit eines Knotens und der Zeit finden, die das Failover in Anspruch nimmt.
Die beiden Watchdog-Werte für Master und Slave steuern, wie ein Fehler des Master-Knotens in einem Cluster erkannt und behandelt wird. Standardmäßig sendet auch der Master einmal pro Sekunde eine Meldung an die anderen Knoten im Cluster. Wenn diese Information nicht übermittelt wird, entfernen die anderen Knoten nach dem beim Slave-Watchdog angegebenen Zeitraum den Master-Knoten aus dem Cluster und definieren einen anderen Knoten als Cluster.
Weitere Konfiguration der Protokolle
Eine weitere Einstellung ist Höchstzahl der Neuübertragungen. Dieser Wert wird von Novell nicht weiter dokumentiert – bis auf den lapidaren Hinweis, dass der Standardwert nicht angepasst werden sollte.
Im unteren Bereich werden diese Informationen noch einmal angezeigt, dieses Mal aber als Parameter der Konfigurationsdatei. Die Anpassungen sollten aber über die Eingabefelder im oberen Bereich oder alternativ durch direkte Anpassung der Konfigurationsdatei durchgeführt werden.
Die Änderungen an den Einstellungen zu einem Cluster müssen noch auf alle Knoten im eDirectory repliziert werden, stehen also nicht sofort zur Verfügung.
Generell ist eine gewisse Vorsicht beim Umgang mit Anpassungen der Einstellungen im laufenden Betrieb geboten, da einige der Parameter den Betrieb und die Erreichbarkeit von Clustern doch sehr deutlich beeinflussen.