Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Atlassian Confluence Cluster: Skalierbar und hochverfügbar?

Mit einem "wach­sen­den" Confluence kommt häu­fig die Frage nach einer Cluster-Lösung auf. Mit einem Verbund von meh­re­ren Servern (auch Instanzen oder Nodes) kön­nen unter­schied­lich Ziele ver­folgt wer­den – Cluster ist nicht gleich Cluster – dem­entspre­chend kate­go­ri­siert man zahl­rei­che Typen. Im Atlassian Portfolio fin­det sich die Wiki-Software auch als Clustered Confluence. Charakterisieren wir einige Eigenschaften und Besonderheiten die­ses Clusters, da immer wie­der Fragen in des­sen Zusammenhang auftreten.

Die in die­sem Kontext wich­tigs­ten Cluster-Typen sind das Hochverfügbarkeits-Cluster (HA-Cluster) und das so genannte Load-Balancing-Cluster. Bei ers­te­rem besteht das ver­folgte Ziel darin, durch meh­rere par­al­lel betrie­bene Systeme ein feh­ler­to­le­ran­tes und robus­tes Verhalten des Gesamtsystems zu errei­chen. Tritt auf einem der Instanzen ein Fehler auf, so wer­den bspw. alle gerade akti­ven Dienste die­ser Instanz auf eine andere über­tra­gen. Für den Nutzer ist die­ser Vorgang voll­kom­men trans­pa­rent (Failover).

Die Absicht eines Load-Balancing-Cluster wird hin­ge­gen häu­fig mit der Verbesserung der Performance beschrie­ben. Die Anfragen der Nutzer an den Dienst wer­den auf meh­rere Instanzen ver­teilt, sodass die ein­zelne Instanz weni­ger par­al­lele "Prozesse" bear­bei­ten muss. Aus Sicht des Nutzers kann so die Antwortzeit her­ab­ge­setzt wer­den oder ver­ein­facht gesagt: "der Dienst ist schnel­ler". Dies ist ins­be­son­dere bei gro­ßen Nutzerzahlen von Bedeutung, da die Auslastung mit jedem wei­te­ren akti­ven Nutzer immer wei­ter zunimmt und die Antwortzeiten z.T. spür­bar anstei­gen. Wichtig hier­bei ist, dass die Funktion des Failovers hier nicht vor­aus­ge­setzt wird.

Das Confluence-Cluster von Atlassian reiht sich in die Kategorie der Load-Balancing-Cluster ein, des­sen pri­mä­res Ziel es ist selbst bei zahl­rei­chen Zugriffen eine Skalierbarkeit des Dienstes zu bie­ten. Auch wenn es die Verfügbarkeit in Spitzenlastzeiten ver­bes­sern kann, ist ein Confluence-Cluster kein Hochverfügbarkeits-Cluster ("five nines availability"). 

 

Im Folgenden wird es etwas tech­ni­scher. Steigen wir ein Stück weit in die interne Funktionsweise ein, um die Anforderungen eines Confluence-Clusters bes­ser zu verstehen.

Zunächst ist wich­tig, dass alle Instanzen auf die­selbe Datenbank zugrei­fen und somit die Inhalte, mit denen die Instanzen arbei­ten, immer über­ein­stim­men. Neben die­sen wer­den zahl­rei­che wei­tere Daten in Zwischenspeichern (Caches) gehal­ten, die aber jeweils nur auf einer Instanz exis­tie­ren kön­nen. Zum Abgleich die­ser wird ein syn­chro­ni­sier­ter Cache ver­wen­det. Hierdurch wer­den auch alle Daten die Confluence im Cache hält, stän­dig zwi­schen den Instanzen abge­gli­chen und sind damit prak­tisch sofort auf allen ande­ren Instanzen ver­füg­bar. Das Cluster kann aus einer Vielzahl von Instanzen bestehen. Confluence erkennt diese dabei selbst­stän­dig im Netzwerk und bil­det dar­aus ein Cluster. Die Kopplung der Komponenten des Clusters wird im unten ste­hen­den Schema noch ein­mal verdeutlicht.

Confluence Cluster Schema

Abb. Altassian

 

Im Vergleich zu einem Confluence ohne Cluster erge­ben sich hier­aus einige zusätz­li­che Anforderungen. Die Confluence-Instanzen mit­samt der Datenbank soll­ten nicht geo­gra­phisch ver­teilt wer­den, da in die­sem Fall die Latenz für die Synchronisation zu groß ist. Die Instanzen arbei­ten auf unter­schied­li­chen Servern und nut­zen Datenbank und Cache "gemein­sam", die Dateien in den Daten-/Home-Verzeichnissen wer­den hin­ge­gen nicht syn­chro­ni­siert, daher müs­sen bspw. alle Seitenanhänge in der Datenbank abge­legt wer­den. Der Suchindex wird eben­falls auf jeder Instanz par­al­lel erzeugt und verwaltet.

Aufgrund der beschrie­be­nen Architektur ist es nicht mög­lich, ein Update einer ein­zel­nen Instanz unab­hän­gig von den ande­ren durch­zu­füh­ren. Die ist im Übrigen auch eine typi­sche Anforderung an ein HA-Cluster, das auch bei der­ar­ti­gen Wartungsarbeiten ver­füg­bar sein muss.

Besonders kri­tisch zu betrach­ten sind die im Confluence ein­ge­setz­ten Plugins. Sie müs­sen eben­falls spe­zi­elle Anforderungen erfül­len, bspw. den Confluence-Cache nut­zen anstatt eigene zu imple­men­tie­ren, damit diese zwi­schen den Instanzen syn­chro­ni­siert wer­den kön­nen. Speichern Plugins einen Teil ihrer Daten im Home-Verzeichnis ab, wel­cher nicht syn­chro­ni­siert wird, kön­nen diese im Cluster feh­ler­haft arbei­ten. Zudem sollte viel Wert auf die Performance der Plugins gelegt wer­den. So nütz­lich wie Plugins sind, so speicher- und rechen­in­ten­siv kön­nen sie auch sein. Im ungüns­tigs­ten Fall kann es sogar dazu füh­ren, dass der Vorteil einer zusätz­li­chen Cluster-Instanz durch die Auswahl der Plugins prak­tisch auf­ge­ho­ben wird. Soll die Antwortzeit des Confluence hal­biert wer­den, kann ins­be­son­dere bei kom­ple­xen Konfigurationen nicht davon aus­ge­gan­gen wer­den, dass die dop­pelte Anzahl an Instanzen aus­reicht. Die Verbesserung der Antwortzeit ver­hält sich nicht linear zur Anzahl der ein­ge­setz­ten Instanzen.

Weitere Anforderungen, wie bspw. die erfor­der­li­che Netzwerk-Infrastruktur und deren Konfiguration, fin­den sich auf den Seiten von Atlassian in einer Cluster Checklist.

Confluence Cluster Administration

 

In die­sem kur­zen Artikel konnte nur eine kurze Übersicht gege­ben wer­den. Wie jedoch ersicht­lich wird, gibt es zusätz­li­che Anforderungen, um ein Confluence-Wiki im Cluster zu betrei­ben. Auch exis­tie­ren zunächst alter­na­tive Wege der Performance-Optimierung. Ein Cluster zu betrei­ben kann, sobald diese aus­ge­schöpft sind und es rich­tig ein­ge­setzt wird, eine wei­tere Lösung bei hohen Nutzerzahlen und einer damit ver­bun­de­nen hohen Anfragedichte sein.

Related Posts

Pin It on Pinterest