Schon bei der Konzeption des ersten kleinen Clusters stößt man auf den Begriff der Quorum- Ressource. Dabei handelt es sich um eine spezielle Ressource mit einer Logdatei, die als Quorum-Log bezeichnet wird. Sie wird standardmäßigals \MSCS\quolog.log gespeichert. Diedarin enthaltenen Informationen werden für Entscheidungen in Problemsituationen verwendet. Damit hat eine Quorum-Ressource zwei Funktionen:
-
Sie stellt einen Speicherplatz für Konfigurationsinformationen zum Cluster zur Verfügung.
-
Sie ist die Basis für Entscheidungen, die mehrere Knoten im Cluster betreffen. Dabei geht es insbesondere um Probleme bei der Mitgliedschaft von Knoten im Cluster und bezüglich des Status des Clusters.
Auf diese Weise wird einerseits Konsistenz erreicht. Innerhalb eines Clusters sollen sich mehrere Systeme wie ein einheitliches virtuelles System verhalten. Entsprechend muss es zwischen diesen Systemen auch Abstimmungsprozesse geben. Die im Zweifelsfall gültigen Informationen zum Zustand des Clusters werden in der Quorum- Ressource abgelegt. Falls diese Ressource nicht verfügbar ist, startet ein Cluster nicht, weil er nicht sicherstellen kann, dass ein konsistenter Zustand erreicht wird.
Die Informationen der Quorum-Ressource dienen aber auch der Auflösung von Situationen, in denen die Kommunikation zwischen einem Teil der Knoten im Cluster unterbrochen ist. Wenn ein Cluster beispielsweise aus vier Knoten besteht und jeweils nur zwei miteinander kommunizieren können, dann hat nur eine der beiden Gruppen Zugriff auf die Quorum-Ressource, weil nur ein Knoten Besitzer davon ist. Der Knoten mit Zugriff auf die Quorum-Ressource und der Knoten, mit dem er noch kommunizieren kann, können nun weiterhin Ressourcen starten.
Standard-Quorums
Der Normalfall für die Quorum-Ressourcen ist deren Speicherung auf einem gemeinsam verwendeten Datenträger. Der Zugriff darauf erfolgt beispielsweise über iSCSI. Eines der Systeme hat die Kontrolle über die Quorum-Ressource, fungiert also als Besitzer dieser Ressource. Im Fehlerfall wird die Kontrolle an einen anderen Knoten übergeben. Die Kommunikation mit der Quorum-Ressource und der Zugriff darauf erfolgen über den Knoten, der als Besitzer fungiert.
MNS-Quorums
Mit dem Windows Server 2003 gibt es nun auch die Option, so genannte Majority Node Set-Cluster (MNS) aufzusetzen. In diesen verfügt jeder Knoten über eine eigene Quorum-Ressource. Es muss im Cluster damit keine gemeinsam verwendeten Datenträger mehr geben. Das ist einerseits eine Option für einfache, spezialisierte Lösungen bei Clustern, die beispielsweise nu Dateidienste bereitstellen und bei denen Informationen mit andern Mechanismen wie dem FRS (File Replication Service) zwischen den Knoten verteilt werden. Es ist andererseits auch für die Erstellung von geografisch verteilten Clustern von Bedeutung, in denen verschiedene Knoten räumlich weit getrennt voneinander stehen und ein Zugriff auf gemeinsam genutzte Datenträger technisch nicht oder nur schwer realisierbar ist.
In solchen Clustern wird für das Funktionieren vorausgesetzt, dass die Mehrheit der Systemeverfügbar ist. Bei vier Knoten müssen also drei Knoten erreichbar sein, bei acht Knoten mindestens fünf Knoten. MNS-Cluster lassen sich sinnvoll also auch erst ab drei Knoten realisieren, weil bei zwei Knoten immer beide online sein müssten.
Falls nicht alle Knoten miteinander kommunizieren können, arbeitet nur der Teil miteinander, der die Mehrheit bildet. Konfigurationsänderungen werden immer an alle Knoten übergeben und von diesen in die Quorums geschrieben, so dass ein einheitlicher Status innerhalb der Systeme, die miteinander kommunizieren können, sichergestellt ist.
Die MNS-Variante von Clustern sollte nur in Ausnahmefällen eingesetzt werden, wenn es die Struktur des Clusters zwingend erforderlich macht. Zudem ist bei Clustern ohne gemeinsam genutzte Datenträger zu beachten, dass damit auch Anwendungsdaten nicht einfach an einen anderen Knoten übergeben werden können – hier sind andere Mechanismen wie das schon genannte FRS erforderlich.
Durch die zentrale Rolle der Quorum-Ressource entsteht das Problem, dass deren Verfügbarkeit in Standardkonfigurationen von Clustern unverzichtbar ist. Wenn nur ein Teil der Knoten auf die Quorum-Ressource zugreifen kann, funktioniert der Cluster weiter. Wenn aber überhaupt kein Zugriff möglich ist, steht der Cluster nicht mehr zur Verfügung, weil die Clusterdienste nicht geladen werden können.