Cluster für Atlassian-Anwendungen für große Umgebungen

Es liegt auf der Hand, dass zentrale IT-Anwendungen wie ein Confluence-Wiki oder JIRA, die von einer großen Anzahl an Mitarbeitern produktiv genutzt werden, stets verfügbar und ausreichend performant sein sollten. Eine gute Verfügbarkeit von Server-Diensten lässt sich dank heute verfügbarer Virtualisierungslösungen (z.B. VMWare ESX) mit entsprechendem IT-Equipment (Shared Storage) leicht sicherstellen. Die Dienste werden in virtuellen Maschinen betrieben, die beim Ausfall eines Servers auf einem anderen System direkt wieder gestartet werden können.

In größeren Umgebungen mit erhöhter Server-Last weisen die Virtualisierungslösungen bei Atlassian-Anwendungen im Bereich der Anwendungs-Performance jedoch Schwächen auf. Es kann notwendig werden, die Anwendungen nativ ohne Virtualisierung in einem Cluster zu betreiben. Spätestens wenn die Rechenleistung einer virtuellen Maschine für den performanten Betrieb nicht mehr ausreicht, führt kein Weg mehr am Aufbau eines eigenen Clusters für die Anwendung vorbei.

In diesem Artikel erläutern wir, wann der Aufbau eines Clusters für Atlassian-Anwendungen sinnvoll bzw. erforderlich ist.

Was ist ein Cluster?

Ein Cluster ist ein Verbund aus miteinander vernetzten Computern, die von außen als eine Einheit wahrgenommen werden. Cluster dienen zur Verbesserung der Verfügbarkeit und/oder Rechenleistung im Vergleich zu einem einzelnen Computer. Die Rechner in einem Cluster werden als Knoten bezeichnet. Man unterscheidet zwischen drei Kategorien von Clustern.

High-Availability Cluster (HA-Cluster)
Zur Steigerung der Verfügbarkeit von Server-Diensten und Anwendungen werden Hochverfügbarkeits-Cluster eingesetzt. Der klassischste Vertreter dieser Kategorie ist ein Aktiv/Passiv-Cluster mit zwei Rechnern/Knoten. Nur auf einem Knoten werden alle Dienste betrieben (aktiv), der andere steht als "Reserve" zur Verfügung (passiv). Tritt ein Fehler auf dem aktiven Knoten auf (z.B. Ausfall einer Hardwarekomponente), werden alle Dienste automatisch vom aktiven auf den passiven Knoten umgezogen.

Load-Balancing-Cluster (SLB-Cluster)
Reicht die Rechenleistung eines einzelnen Computers für den performanten Betrieb eines Server-Dienstes oder einer Anwendung nicht mehr aus, ist es möglich, mit einem Load-Balancing-Cluster die Rechenlast auf mehrere Rechner zu verteilen. Der Zugriff auf die im Cluster betriebenen Dienste und die Verteilung der Last erfolgen über eine zentrale Instanz, den Load-Balancer. Da die Server-Dienste und Anwendungen auf mehreren Knoten betrieben werden, kann ein SLB-Cluster zusätzlich zur Lastverteilung auch eine verbesserte Verfügbarkeit der Dienste gewährleisten.

High-Performance-Computing-Cluster (HPC-Cluster)
Ein HPC-Cluster ist ein spezieller Verbund von Computern zur Abarbeitung von Rechenaufgaben, wie z.B. im wissenschaftlichen Bereich oder zur Berechnung von 3D-Computergrafiken (Renderfarmen). Im Vergleich zu den HA- und SLB-Clustern lassen sich im HPC-Cluster ausschließlich speziell für die Cluster-Software entwickelte Rechenanwendungen betreiben.

Performance von Atlassian-Anwendungen in einer virtualisierten Umgebung

Atlassian hat Performance-Tests ihrer Anwendungen Confluence und JIRA durchgeführt, in denen sich gezeigt hat, wie sich die Performance bei Nutzung von Virtualisierung (VMWare ESX 3.5 und 4) bei unterschiedlicher Last im Vergleich zum nativen Betrieb auf physikalischen Server-Systemen verhält. Die wichtigsten Erkenntnisse im Überblick:

  • Bei Confluence- und JIRA-Installationen mit hoher Last sollte aus Gründen der Performance auf Virtualisierung verzichtet werden.
  • Außerdem empfiehlt es sich bei hoher Last, die Datenbank auf einem zusätzlichen Server-System zu betreiben.
  • Auch bei geringer bis mittelhoher Last ist der Performance-Verlust virtueller Instanzen im Vergleich zu nativen Installationen nicht zu vernachlässigen. Dies sind einige Vergleichswerte für Confluence:
    • Bei geringer Last (16 Anfragen pro Sekunde) ist die Anzeige einer Confluence-Seite auf einer nativen Installation im Durchschnitt 30% schneller als in einer ESX4-Umgebung und 53% schneller als in einer ESX3.5-Umgebung.
    • Bei mittelhoher Last (32 Anfragen pro Sekunde) wird der Unterschied noch deutlicher: Der Geschwindigkeitsvorteil einer nativen Installation steigt auf 65% im Vergleich zu ESX4 und auf 98% im Vergleich zur älteren ESX-Version 3.5.

Die detaillierten Testergebnisse für Confluence und JIRA finden sich im Atlassian-Wiki.

Wann ist welcher Cluster sinnvoll?

Prinzipiell kommen die Clustertypen HA- und SLB-Cluster für den Einsatz von Atlassian-Anwendungen in Frage.

HA-Cluster und Atlassian-Anwendungen
Die Tests von Atlassian zeigen, dass bei höherer Last eine native Installation ohne Virtualisierung eine deutlich bessere Performance erzielt. Durch den Wegfall der Virtualisierung ist jedoch die Verfügbarkeit nicht mehr sichergestellt, da die Software-Dienste nur auf einem Server nativ betrieben werden. Die Lösung ist der Aufbau eines HA-Clusters für den Betrieb der Anwendung: Man erhält die maximale Performance durch die native Installation auf den Server-Systemen ohne Virtualisierung und sichert gleichzeitig die Verfügbarkeit durch den Einsatz von mehreren Server-Systemen im Cluster-Verbund.

Zusammenfassend sind HA-Cluster unter diesen Voraussetzungen bzw. bei diesen Anforderungen sinnvoll:

  • Falls eine sehr gute Verfügbarkeit der Anwendung sichergestellt werden soll, jedoch keine Virtualisierungslösung mit HA-Funktion zur Verfügung steht.
  • Beim Einsatz von älteren Virtualisierungslösungen wie ESX 3.5, die keine ausreichende Performance gewährleisten.
  • Je nach Anforderung an die Anwendungs-Performance beim Betrieb von Atlassian-Anwendungen mit mittlerer bis hoher Last.

Generell lassen sich alle Atlassian-Anwendungen ohne Modifikationen in einem HA-Cluster betreiben. Voraussetzung ist entweder ein Shared Storage oder eine Datenreplikation zwischen den Cluster-Knoten.

Die wirtschaftlichste Konfiguration eines HA-Cluster, die wir für Atlassian-Anwendungen anbieten, ist ein Active/Passive-Passive/Active-Cluster mit zwei Servern: Auf einem Knoten werden die Anwendungen betrieben, auf dem anderen die Datenbank. Beim Ausfall eines Server-Systems übernimmt jeweils das andere die Dienste des ausgefallenen. Die Daten werden mittels Spiegelung über ein internes Netzwerk auf beiden Knoten abgeglichen, ein Shared Storage wird nicht benötigt.

Das Ergebnis ist eine maximale Performance bei minimalem Hardware-Bedarf. Lediglich beim Ausfall eines Servers ist die Performance eingeschränkt, da alle Dienste auf nur einem Server betrieben werden müssen.

Abb. 1: Aufbau eines HA-Clusters

SLB-Cluster und Atlassian-Anwendungen
Ist die Last der Anwendung so hoch, dass auch der native Betrieb der Anwendung und der Datenbank auf getrennten und leistungsstarken Server-Systemen nicht ausreicht, ist der Aufbau eines Load-Balancing-Clusters erforderlich. Die Anwendung wird bei dieser Cluster-Kategorie auf mehreren Servern aktiv betrieben, sodass die Last der Anwender über den Load-Balancer gleichmäßig auf diese verteilt werden kann.

Im Gegensatz zum HA-Cluster müssen Anwendungen für den Betrieb in einem SLB-Cluster spezielle Anforderungen erfüllen. Unter den Atlassian-Anwendungen ist bisher nur Confluence für den Betrieb in einem SLB-Cluster ausgelegt. Confluence unterstützt dabei bis zu vier Knoten mit aktiven Anwendungsinstanzen, womit auch die anspruchsvollsten Anforderungen abgedeckt sein sollten.

Abb. 2: Empfohlene Netzwerk-Topologie für Atlassian-Anwendungen mit sehr hoher Last (Quelle: Atlassian)

Die Systemadministratoren von //SEIBERT/MEDIA/SYSTEMS unterstützen Sie gerne bei der Schätzung Ihrer voraussichtlichen Anwendungslast und beraten Sie bei der Wahl einer geeigneten IT-Infrastruktur für Ihre Atlassian-Anwendung. Bitte sprechen Sie uns unverbindlich an.

Weiterführende Informationen:
Die Website von //SEIBERT/MEDIA/SYSTEMS
Hosting-Notfalldienstleistungen von //SEIBERT/MEDIA/SYSTEMS


Mehr über die Creative-Commons-Lizenz erfahren