Mit einem “wachsenden” Confluence kommt häufig die Frage nach einer Cluster-Lösung auf. Mit einem Verbund von mehreren Servern (auch Instanzen oder Nodes) können unterschiedlich Ziele verfolgt werden – Cluster ist nicht gleich Cluster – dementsprechend kategorisiert man zahlreiche Typen. Im Atlassian Portfolio findet sich die Wiki-Software auch als Clustered Confluence. Charakterisieren wir einige Eigenschaften und Besonderheiten dieses Clusters, da immer wieder Fragen in dessen Zusammenhang auftreten.
Die in diesem Kontext wichtigsten Cluster-Typen sind das Hochverfügbarkeits-Cluster (HA-Cluster) und das so genannte Load-Balancing-Cluster. Bei ersterem besteht das verfolgte Ziel darin, durch mehrere parallel betriebene Systeme ein fehlertolerantes und robustes Verhalten des Gesamtsystems zu erreichen. Tritt auf einem der Instanzen ein Fehler auf, so werden bspw. alle gerade aktiven Dienste dieser Instanz auf eine andere übertragen. Für den Nutzer ist dieser Vorgang vollkommen transparent (Failover).
Die Absicht eines Load-Balancing-Cluster wird hingegen häufig mit der Verbesserung der Performance beschrieben. Die Anfragen der Nutzer an den Dienst werden auf mehrere Instanzen verteilt, sodass die einzelne Instanz weniger parallele “Prozesse” bearbeiten muss. Aus Sicht des Nutzers kann so die Antwortzeit herabgesetzt werden oder vereinfacht gesagt: “der Dienst ist schneller”. Dies ist insbesondere bei großen Nutzerzahlen von Bedeutung, da die Auslastung mit jedem weiteren aktiven Nutzer immer weiter zunimmt und die Antwortzeiten z.T. spürbar ansteigen. Wichtig hierbei ist, dass die Funktion des Failovers hier nicht vorausgesetzt wird.
Das Confluence-Cluster von Atlassian reiht sich in die Kategorie der Load-Balancing-Cluster ein, dessen primäres Ziel es ist selbst bei zahlreichen Zugriffen eine Skalierbarkeit des Dienstes zu bieten. Auch wenn es die Verfügbarkeit in Spitzenlastzeiten verbessern kann, ist ein Confluence-Cluster kein Hochverfügbarkeits-Cluster (“five nines availability”).
Im Folgenden wird es etwas technischer. Steigen wir ein Stück weit in die interne Funktionsweise ein, um die Anforderungen eines Confluence-Clusters besser zu verstehen.
Zunächst ist wichtig, dass alle Instanzen auf dieselbe Datenbank zugreifen und somit die Inhalte, mit denen die Instanzen arbeiten, immer übereinstimmen. Neben diesen werden zahlreiche weitere Daten in Zwischenspeichern (Caches) gehalten, die aber jeweils nur auf einer Instanz existieren können. Zum Abgleich dieser wird ein synchronisierter Cache verwendet. Hierdurch werden auch alle Daten die Confluence im Cache hält, ständig zwischen den Instanzen abgeglichen und sind damit praktisch sofort auf allen anderen Instanzen verfügbar. Das Cluster kann aus einer Vielzahl von Instanzen bestehen. Confluence erkennt diese dabei selbstständig im Netzwerk und bildet daraus ein Cluster. Die Kopplung der Komponenten des Clusters wird im unten stehenden Schema noch einmal verdeutlicht.
Abb. Altassian
Im Vergleich zu einem Confluence ohne Cluster ergeben sich hieraus einige zusätzliche Anforderungen. Die Confluence-Instanzen mitsamt der Datenbank sollten nicht geographisch verteilt werden, da in diesem Fall die Latenz für die Synchronisation zu groß ist. Die Instanzen arbeiten auf unterschiedlichen Servern und nutzen Datenbank und Cache “gemeinsam”, die Dateien in den Daten-/Home-Verzeichnissen werden hingegen nicht synchronisiert, daher müssen bspw. alle Seitenanhänge in der Datenbank abgelegt werden. Der Suchindex wird ebenfalls auf jeder Instanz parallel erzeugt und verwaltet.
Aufgrund der beschriebenen Architektur ist es nicht möglich, ein Update einer einzelnen Instanz unabhängig von den anderen durchzuführen. Die ist im Übrigen auch eine typische Anforderung an ein HA-Cluster, das auch bei derartigen Wartungsarbeiten verfügbar sein muss.
Besonders kritisch zu betrachten sind die im Confluence eingesetzten Plugins. Sie müssen ebenfalls spezielle Anforderungen erfüllen, bspw. den Confluence-Cache nutzen anstatt eigene zu implementieren, damit diese zwischen den Instanzen synchronisiert werden können. Speichern Plugins einen Teil ihrer Daten im Home-Verzeichnis ab, welcher nicht synchronisiert wird, können diese im Cluster fehlerhaft arbeiten. Zudem sollte viel Wert auf die Performance der Plugins gelegt werden. So nützlich wie Plugins sind, so speicher- und rechenintensiv können sie auch sein. Im ungünstigsten Fall kann es sogar dazu führen, dass der Vorteil einer zusätzlichen Cluster-Instanz durch die Auswahl der Plugins praktisch aufgehoben wird. Soll die Antwortzeit des Confluence halbiert werden, kann insbesondere bei komplexen Konfigurationen nicht davon ausgegangen werden, dass die doppelte Anzahl an Instanzen ausreicht. Die Verbesserung der Antwortzeit verhält sich nicht linear zur Anzahl der eingesetzten Instanzen.
Weitere Anforderungen, wie bspw. die erforderliche Netzwerk-Infrastruktur und deren Konfiguration, finden sich auf den Seiten von Atlassian in einer Cluster Checklist.
In diesem kurzen Artikel konnte nur eine kurze Übersicht gegeben werden. Wie jedoch ersichtlich wird, gibt es zusätzliche Anforderungen, um ein Confluence-Wiki im Cluster zu betreiben. Auch existieren zunächst alternative Wege der Performance-Optimierung. Ein Cluster zu betreiben kann, sobald diese ausgeschöpft sind und es richtig eingesetzt wird, eine weitere Lösung bei hohen Nutzerzahlen und einer damit verbundenen hohen Anfragedichte sein.