Betriebssystem-Cluster

Der anwendungsspezifische Cluster verfügt naturgemäß über viele spezielle Funktionen auf der Ebene von Lotus Domino. Auf der anderen Seite gibt es Cluster-Dienste auch bei allen gängigen Serverbetriebssystemen, dort oftmals wiederum in sehr unter-schiedlichen technischen Realisierungen. Beispiele sind der Sun Cluster oder Microsofts MSCS (Microsoft Cluster Services). Letztere werden nachfolgend auch im Schwerpunkt betrachtet.

Anwendungscluster wie die von Domino lassen sich sowohl alternativ als auch in Verbindung mit Betriebssystem-Clustern einsetzen. Letzteres wirkt im ersten Moment redundant, bietet aber den Vorteil, dass damit weitere potenzielle Fehlersituationen adressiert werden.

Die Arbeitsweise von Betriebssystem-Clustern

Wie schon kurz angesprochen gibt es eine ganze Reihe von Konzepten für die Umsetzung von Betriebssystem-Clustern. Dienste wie die MSCS fokussieren auf den Failover, also die Übernahme von Anwendungen, wenn ein Knoten im Netzwerk ausfällt oder außer Betrieb genommen wird.

Ein aktiver Knoten, der eine Anwendung ausführt, nutzt bestimmte Ressourcen wie gemeinsam genutzte Festplatten. Wenn ein Knoten ausfällt, wird das vom Cluster erkannt. Die Ausführung wird in diesem Fall an einen anderen Knoten übergeben. Dieser beantwortet weitere Anforderungen von Clients. Da der Zugriff auf einen virtuellen Server erfolgt, nutzen die Clients die gleichen Netzwerknamen und IP-Adressen, obwohl in diesem Fall mit einem anderen System gearbeitet wird.

Wie weit es dabei möglich ist, die Arbeit genau an dem Punkt fortzusetzen, an dem sie unterbrochen wurde, hängt von der Implementierung ab. Bei den MSCS können über so genannte Ressourcen-DLLs Anwendungen enger mit dem Cluster zusammenarbeiten. Darüber lassen sich zusätzliche Informationen wie Checkpoints im Failover an einen anderen Knoten übergeben.

Grundsätzlich ist der Failover transparent für die Benutzer, wobei je nach Implementierung die Benutzer eine Session neu aufsetzen müssen.

Beim Betrieb unterscheidet man zwischen Active-Passive- und Active-Active-Konfigurationen. Bei einer Active-Passive-Konfiguration wird die Arbeit im Fehlerfall von einem anderen Knoten übernommen, der bis zu diesem Zeitpunkt passiv ist. In einer Active-Active-Konfiguration laufen dagegen auf jedem Knoten aktive Prozesse beispielsweise von Domino. Im konkreten Fall von Domino erfordert das den Einsatz eines partitionierten Servers, weil ein Domino-Server aktiv arbeitet, während einer Stand-By läuft und auf die Übergabe der Ressourcen im Falle eines Failovers wartet. Entsprechend muss es auch zwei getrennte Ressourcen für die Anwendungsdaten geben.

Spezielle Aspekte für die Nutzung von Domino

Die Domino-Cluster haben einige spezielle Fähigkeiten, die sich in dieser Form nicht unbedingt bei Betriebssystem-Clustern finden:

Durch die enge Integration mit Domino weiß der Cluster, wie stark die einzelnen Knoten belastet sind, und kann bei einem Failover einen Knoten mit geringer Auslastung wählen. So differenziert – insbesondere auf Anwendungsebene – können Betriebssystem-Cluster nicht arbeiten.

• Das Ergebnis ist auch ein aktives Load Balancing, das sich in dieser Form sonst nicht findet.

• Domino unterstützt Cluster mit verschiedenen Betriebssystemen. Im Bereich der Betriebssystem-Cluster ist eine solche Lösung unüblich. Eine Ausnahme bilden die Novell Cluster Services mit der Unterstützung für Linux und NetWare als Betriebssysteme – aber eben nur Linux für den Betrieb von Domino.

• Ein weiterer großer Vorteil für den Cluster-Ansatz von Domino ist, dass keine spezielle Storage-Infrastruktur erforderlich ist. Bei Betriebssystem-Clustern wird ein SAN oder zumindest Shared SCSI genutzt. SANs sind durch die zunehmende Verbreitung von iSCSI zwar heute kostengünstiger realisierbar, aber der Aufwand für den Aufbau eines Clusters ist relativ hoch.

Diese Vorteile sprechen grundsätzlich dafür, Lotus Domino eher im spezifischen Domino-Cluster als in Betriebssystem-Clustern zu betreiben.

Vorteile kombinierter Cluster

Die gemeinsame Verwendung beider Varianten von Clustern kann aber auch sinnvoll sein. Einer der Vorteile liegt in der Ausführung von Agenten. Wenn ein Agent für den Betrieb auf einem bestimmten Server ausgelegt ist, wird er beim Failover in einem Domino-Cluster auf einem anderen Server nicht ausgeführt.

In einem Betriebssystem-Cluster läuft Domino dagegen auf einem quasi identischen Server mit dem gleichen Namen, sodass der Agent dort wieder ausgeführt werden kann. Das lässt sich allerdings auch durch entsprechende Gestaltung von Agenten lösen.

Ein vergleichbares Problem entsteht auch mit Anwendungen, die fest codierte Servernamen verwenden. Auch in diesem Fall lässt sich das Problem aber genauso durch eine Anpassung der Anwendung oder die Vermeidung solcher Situationen aus der Welt schaffen.

Benutzer können Dokumente, die sie bearbeiten, außerdem in Betriebssystem-Clustern speichern, sobald der Failover-Server verfügbar ist. Bei einem Domino-Cluster wird auf einem anderen Server gearbeitet, sodass hier Probleme entstehen. Dieser Punkt ist das beste Argument für Betriebssystem-Cluster.

Außerdem ist zu beachten, dass der AdminP-Prozess nur in einem Betriebssytem-Cluster vom Failover erfasst wird, nicht aber in einem Domino-Cluster.

Insofern kann der gemeinsame Betrieb beider Cluster-Technologien durchaus Sinn machen – oder sogar die Konzentration auf einen Betriebssystem-Cluster anstelle des Domino-Clusters. Andererseits darf man nicht unterschätzen, dass die Domino-Cluster in der Handhabung doch insgesamt um einiges einfacher sind und eine weniger komplexe Infrastruktur erfordern. Falls Ihnen also die Funktionalität eines Domino-Clusters ausreicht, können Sie sich den zusätzlichen Aufwand auch sparen.