Zeige mehr…

Kapazitätsplanung und Skalierung von großen Confluence Instanzen

View this page in English.

Clusterbildung zur Skalierung von Confluence

Zur Verwaltung von einer User-Anzahl ab 50.000 ist ein Zwei-Knoten-Confluence-Cluster notwendig.

Annahmen

Folgende Annahmen werden getroffen: 

Bereiche

Die Erstellung eines Confluence-Clusters beinhaltet folgende Bereiche:

Cluster Topologie

Wir gehen von der folgenden Zwei-Knoten-Cluster Topologie aus:

Quelle: http://confluence.atlassian.com/display/DOC/Recommended+network+topology

Allgemeine Hardware Vorraussetzungen:

Cluster Konzept

Das Cluster besteht aus zwei dedizierten, physischen Confluence-Knoten (Knoten 1+2) und einem separaten Staging-Server, einer dedizierten, physischen MySQL Datenbank zusammen mit einer Slave-Datenbank und einem Apache2 Webserver mit mod_jk zum Lastenausgleich. Zwischen den zwei Confluence-Knoten besteht eine Gigabit Netzwerkverbindung (direkt bzw. VLAN) zur Cluster-Synchronisation. Zwischen den beiden Datenbanken besteht eine Master/Slave-Replikation. Alle relevanten Daten sind, inklusive der Anhänge, in der Datenbank abgelegt und auf einem zweiten MySQL Server dupliziert. Das Active Directory wird zur zentralen Benutzerverwaltung, einschließlich Gruppen, genutzt.

Der zweite Confluence-Knoten und der Staging-Server ist eine Kopie des ersten Knoten. Das ermöglicht eine schnellere und einfachere Einrichtung des Systems und stellt sicher, dass Konfiguration, Software und Version auf allen Systemen einheitlich ist. Dies sollte sowohl mit dem MySQL Master als auch dem MySQL Slave durchgeführt werden (Beachten Sie, dass die spezifischen Einstellungen wie Networking, Hostname, Confluence-Cluster Konfiguration, Master/Slave Konfiguration für MySQL weiterhin erforderlich sind).

LVM (Logical Volume Manager) wird in allen Systemen als Schicht zwischen der Festplatte und dem Dateisystem eingesetzt und erlaubt Speicherauszüge (Vorteile werden unten erläutert). Die Partition sollte wie folgt aussehen:

Backup

Da alle relevanten Daten, einschließlich der Anhänge, in der Datenbank gesichert sind, ist es ausreichend ein Backup der Datenbank zu erstellen. Änderungen an den Installationsdateien können nachverfolgt und im Repository gesichert werden. Der interne Backup von Confluence wird nicht genutzt. Wegen der zu erwartenden großen Datenmenge (beispielsweise Anhänge), ist es hinsichtlich Leistung und Wiederherstellung am Besten die RAW MySQL Dateien zu sichern. Die gesamten Daten sind in der Slave-Datenbank dupliziert, das vereinfacht eine regelmäßige Sicherung der RAW Dateien, da der MySQL Slave beliebig gestoppt und gestartet werden kann und dann automatisch synchronisiert. Beachten Sie dabei, dass dies nur über einen bestimmten Zeitraum hinweg möglich ist, abhängig davon wieviel in der Zwischenzeit passiert ist.

Aus diesem Grund empfehlen wir folgende Backup-Strategie:

Diese Strategie unterstützt allerdings keine Point-In-Time-Recovery. Sollte dies erforderlich sein, empfehlen wir den Einsatz von Software wie beispielsweise Zmanda Recovery Manager, dadurch wird eine  zeitpunktspezifische Wiederherstellung möglich. Die Software wird auf dem MySQL Master, mit aktivierten Binary Logs, installiert (die Binary Logs sind aber sowieso aktiviert, da sie für die Replikation benötigt werden). Über eine Web-Oberfläche wird die Einrichtung des Backups und eine einfache Wiederherstellung zu einem gewünschten Zeitpunkt ermöglicht.

Darüber hinaus besteht auf Grund der Master/Slave-Architektur bereits ein Live-Backup, auf das bei einem Master/Slave-Hardwarefehler direkt zugegriffen werden kann. Dadurch erhält die Cluster-Topologie etwas Redundanz.

Solange keine Hardwarefehler vorliegen, muss man so gut wie nie auf ein Backup zurückgreifen. Der Papierkorb sowie die Revision von Seiten sind meist ausreichend wenn es um die Wiederherstellung versehentlich gelöschter Seiten geht.

Sicherheit

Die folgenden Sicherheitsmaßnahmen werden getroffen:

Für den Fall, dass die Instanz mit dem Internet verbunden ist (obwohl dies in den Annahmen ausgeschlossen wurde, ist es unserer Meinung nach dennoch interessant):

Des Weiteren empfehlen wir unseren Kunden sich an folgenden Richtlinien zu halten:

Überwachung

Die Überwachung der Cluster-Topologie ist unverzichtbar und besteht aus verschiedenen Punkten die in Verfügbarkeits-, Leistungs- und Fehlerüberwachung aufgeteilt werden können.

Überwachung  der Verfügbarkeit 

Die Verfügbarkeitsüberwachung beinhaltet regelmäßige Checks (etwa alle 1-2 Minuten) der

Das Überwachen der Verfügbarkeit ist unverzichtbar in (zukünftigen) größeren Instanzen, da eine längere Nichterreichbarkeit fatal für die Akzeptanz des Systems und die Produktivität der Angestellten ist.

Die etablierteste Lösung zur Verfügbarkeitsüberwachung ist Nagios. Wir empfehlen die Nutzung von Nagios oder Icinga.

Überwachung der Leistung

Die wichtigsten Checks sind einfach: CPU Nutzung, Speicherverbrauch, Nutzung des Java Heap Bereichs, Anzahl an Datenbank-Verbindungen/-Anfragen und Netzwerk-Latenz, denn diese Werte helfen oft als erstes bei der Problemlokalisierung.

Wir empfehlen die Nutzung von Munin für automatisierte Leistungsüberwachung und Javamelody oder Hyperic für die Confluence/Tomcat-Überwachung. Einfache, manuelle Checks können zudem über die Confluence Admin-Konsole durchgeführt werden, die Statistiken über Min/Max der Heap-Größe, der genutzten Heap-Größe, Datenbank-Latenz-Cache Statistiken und weitere.

Überwachung von Fehlern

Fehlerüberwachung beinhaltet hauptsächlich das Beobachten der Confluence Logs für Java Applikationsfehler. Aktuelle Versionen von Confluence stellen ‘Herkules’ zur manuellen Fehlerkontrolle zur Verfügung. Eine einfache, automatisierte Lösung zum Beobachten von Fatal-Errors in den Logs von Confluence könnte eine Kombination von Unix-Tools wie ‘tail’, ‘awk’ und ‘mail’ sein, um bei Fehlern eine Email zuerhalten.

Tuning

In Verbindung mit den allgemeinen Anforderungen und dem oben erwähntem Cluster-Konzept, sollten die folgenden ‘Best-Practices’ angewandt werden um eine optimale Leistung zu erzielen:

Das Tuning von Confluence und allen anderen Services und Systemen ist ein beständiger Prozess während des gesamten Lebenszyklus von Confluence. Denn Größen, Anwendungsfälle, Software/Architektur verändern sich von Zeit zu Zeit und erfordern Anpassungen. Gleichwohl sind die folgenden allgemeinen Tuning-Maßnahmen nützlich und werde deshalb auch in unserem Cluster angewandt:

# Optimizations from the Java Team -XX:+AggressiveOpts # old parallel GC -XX:+UseParallelOldGC -XX:+DisableExplicitGC # This feature is enabled by default since JDK 6 Update 21 -XX:+UseCompressedOops # Compiler escape analysis, this feature is enabled by default since JDK 6 Update 21 -XX:+DoEscapeAnalysis # String Operation optimizations (if JDK 6 Update 20 or later is installed) -XX:+OptimizeStringConcat # If on Intel CPU with 'Quick Path Interconnect' or AMD Opteron, then this should be enabled -XX:+UseNUMA

Staging/Testen

Vor dem Upgraden, beispielsweise von System-Packages oder einer neuen Version von Confluence, ist es notwendig in einer Staging-Umgebung zu testen.

Wie in den Vorraussetzungen oben bereits erwähnt, ist ein separater Staging-Rechner notwendig. Eine Developer Lizenz ist ebenfalls obligatorisch.

Der Staging-Server kombiniert eine Ein-Knoten-Confluence-Cluster Installation mit einer MySQL Datenbank, so dass es sowohl einem produktiven Confluence-Knoten als auch einer Datenbank gleicht. Der Staging-Server ist jedoch in erster Linie für Systemupgrade-Tests und Confluence Upgrade-Tests geeignet (siehe unten, Schritte eines solchen Upgrade-Tests). Für Leistungs- und Tuningtests empfehlen wir, diese in einer produktiven Umgebung innerhalb eines festgelegten Zeitrahmens durchzuführen.

Schritte für einen System (Package) Upgrade-Test:

Schritte für einen Confluence Upgrade-Test:

Upgrades

Wenn in der Staging-Umgebung alles funktioniert, kann das Upgrade durchgeführt werden. Während des gesamten Prozesses sollten die Log-Files überwacht werden, während eines möglichen Datenbank-Upgrades besonders die Confluence-Logs.

Schritte für ein Confluence-Upgrade:

Jetzt sollte der erste Knoten mit der neuen Version laufen. Wenn alles funktioniert, können die folgenden Schritte angewandt werden:

Das Arbeiten mit Snapshots erlaubt eine schnelle Wiederherstellung falls während des Upgrades irgendetwas schief geht. Schritte zur Wiederherstellung:

Wir empfehlen unseren Kunden immer nur eine Änderung gleichzeitig vorzunehmen und zu beobachten (für einen längeren Zeitraum, etwa 2-3 Tage) was passiert. Wir empfehlen keine mehrfachen Änderungen gleichzeitig (wie beispielsweise ein System- UND Confluence-Upgrade). Wir empfehlen weiterhin jede einzelne Änderung nachzuverfolgen und darüber hinaus das Anlegen einer Upgrade-Checkliste.

Auf die Frage, wann und auf welche Version man upgraden sollte (eine häufige Frage unserer Kunden): Generell empfehlen wir NICHT sofort auf die erste verfügbare Version einer größeren Versionsänderung zu upgraden (z.B. von 3.4.x auf 3.5.0). Stattdessen empfehlen wir auf das erste oder zweite Bug-Fix Release zu warten (z.B. 3.5.2 anstatt von 3.5.0) und die Knowledge-Base und den Bug-Tracker zu beobachten.

Zeige mehr…
Zeige mehr…