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: 

• Confluence wird in einem privaten Intranet / einer nicht öffentlichen Instanz betrieben
• Linux kann als Betriebssystem eingesetzt werden
• MySQL Datenbanken sind verfügbar 
• Apache Webserver kann verwendet werden
• Microsoft Active Directory ist die zentralisierte Anwendung zur Benutzerverwaltung
• Clustering wird nur zur Skalierung und nicht für eine hohe Verfügbarkeit eingesetzt (obwohl es teilweise zu Redundanz kommt)

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:

• 2 dedizierte, physische Rechner für die Confluence-Knoten
• 1 dedizierter, physischer Rechner für die MySQL Master-Datenbank
• 1 dedizierter, physischer Rechner für die MySQL Slave-Datenbank
• 1 dedizierter, physischer Rechner zum Lastenausgleich
• exakt gleiche Hard- und Software für beide Confluence-Knoten
• Empfohlene Hardware für beide Confluence-Knoten:
  • 2x QuadCore CPU >= 2,5 Ghz oder 1x 8-Core CPU >= 2,5 Ghz
  • 20 GB RAM
  • schnelle Festplatte (z.B. SSD) für den Suchindex (32-64 GB)
• Empfohlene Hardware für Staging-Server:
  • 2x QuadCore CPU >= 2,5 Ghz oder 1x 8-Core CPU >= 2,5 Ghz
  • 32 GB RAM
  • große Festplatte (500-1000 GB) RAID10
• Empfohlene Hardware für die Master-Datenbank:
  • 2x 8-Core CPU >= 2,5 Ghz
  • 32 GB RAM
  • schnelle, große Festplatte (500-1000 GB) RAID10
• Empfohlene Hardware für die Slave-Datenbank:
  • 1x 8-Core CPU >= 2,5 Ghz
  • 16 GB RAM
  • schnelle, große Festplatte (500-1000 GB) RAID10
• Empfohlene Hardware für den Lastenausgleich-Rechner:
  • 1x QuadCore CPU >= 2,5 Ghz
  • 8 GB RAM

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:

• Root Partition - /
• Confluence install - /opt
• Confluence home - /var/opt/confluence
• MySQL - /var/lib/mysql

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:

• Herunterfahren des MySQL Slave
• Backup der RAW Dateien mit einer beliebigen Backup-Strategie
• Starten des MySQL Slave zur Synchronisierung mit dem MySQL Master

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:

• SSL Verschlüsselung für HTTP- sowie LDAP-Traffic.
• Confluence wird als unpriviligierter User ausgeführt. 
• Secure Tomcat wird zusammen mit dem Apache2 Webserver betrieben. In diesem Fall abgesichert durch den Lastenausgleich-Rechner. Der gesamte Traffic zwischen den beiden Knoten wird vom Lastenausgleichs-Rechner verarbeitet.
• vollständige Deaktivierung der Remote-API (falls nicht benötigt) oder Zugangsbeschränkung zur API auf bestimmte IPs oder via BasicAuth im Apache2 Lastenausgleich-Rechner (falls vom Kunden so gewünscht).
• beschränkter oder gesicherter Zugriff auf die Admin-Konsole im Lastausgleich-Rechner wie oben erwähnt (falls vom Kunden so gewünscht).
• Konfigurieren des LDAP-Filters zum Ausschluss von Usern mit gesetzter ‘disabled’-Markierung.
• Deaktivierung der öffentlichen Anmeldung.
• Aktivierung des XSS / CSRF Schutzes.

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):

• Einsatz von Fail2ban zum Schutz for Brute-Force-Attacken.
• auf länderspezifischen Instanzen kann mit Hilfe des iptables Modul ‘geoip’ der Zugriff auf Confluence (und den Server) aus bestimmten Ländern komplett geblockt werden.
• Deaktivierung des People-Verzeichnisses.
• Aktivierung von Captcha für fehlgeschlagene Loginversuche und Spam-Schutz.
• Konfiguration der E-Mail-Sichtbarkeit.

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

• Die ‘confluence-administrators’ Gruppe sollte nur Nutzer enthalten, die einen vollen Administrationszugang benötigen. Im Idealfall haben alle Administratoren einen eigenen Administratorzugang (z.B. sollte für den User-Account ‘avrienen’ der Admin-Account ‘avrienen-admin’ lauten). Selbiges gilt auf für die ’System Administrator’ Zugriffsrechte.
• Regelmäßige Durchführung von Audits: Überprüfen und aufräumen von globalen, Bereichs- und Seiten-Zugriffsrechten. Entfernen von nicht benötigten Zugriffsrechten. Selbiges gilt auch für Gruppenzugehörigkeit.
• Abonnieren Sie die ‘Technical Alerts’ Mailingliste (auch //SEIBERT/MEDIA ist Abonnent dieser Mailingliste und informiert Kunden gegebenenfalls wenn diese von entsprechenden Sicherheitsrisiken betroffen sind). 
• Etablieren Sie eine Art ‘Richtlinie’ für Plugins in Confluence. Da sich Confluence stark/schnell entwickelt, können nicht alle Plugins mit den neuen Releases Schritt halten. Das kann zum Problem werden, wenn Administratoren auf eine neue Version updaten wollen, dies aber auf Grund der fehlenden Kompatibilität bestimmter Plugins nicht können. Wenn wir von Kunden gefragt werden, welche Plugins installiert werden können, geben wir ihnen die Daumenregel nur Plugins zu installieren die offiziell von Atlassian unterstützt werden ODER kommerziell erhältlich sind (oder Support bieten) ODER bereits seit einiger Zeit verfügbar sind und bei denen mit einer zukünftige Weiterentwicklung zu rechnen ist (wir haben gute Erfahrung mit Plugins von Adaptavist und CustomWare). Dies ist nicht zwangsläufig ein Sicherheitsrisiko, aber dennoch wichtig.

Ü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

• Prozesse: Sind bestimmte Prozesse wie Tomcat, Apache, MySQL aktiv (also nicht im Zombie- oder Stale-Modus)?
• Netzwerk: Sind alle Cluster-Komponenten online (Ping-Check), Latenz-Checks, sind alle Netzwerkinterfaces aktiv?
• HTTP: Überprüfen von Patterns und HTTP Antwortcodes.

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

• Lastausgleich-Rechner Ebene: Zugriffe und die Anzahl der Anfragen/sec., Anzahl der Apache Prozesse und Threads, Apache Traffic Volumen.
• System Ebene Überwachung: Dies gilt für alle Rechner in der Cluster-Topologie. Diese Überwachung ist notwendig um Defizite und Probleme auf System Ebene zu erkennen. Die Checks beinhalten: CPU-Auslastung, Speicherverbrauch, Swap-Nutzung, Ein-/Ausgabedurchsatz, Netzwerk-Traffic, Festplattenauslastung, Inode-Nutzung, Anzahl der aktiven Netzwerkverbindungen, Anzahl und Arten von Interrupts, Durchschnittsauslastung.
• Datenbank Überwachung: Anzahl der Anfragen pro Sekunde, Anzahl der langsamen Anfragen pro Sekunde, Datendurchsatz, Insert/Select Ratio, Anzahl der Threads.
• Confluence/Tomcat Überwachung: Diese spezielle Überwachung ist entscheidend um Probleme zu erkennen und die Auswirkungen der Aktivierung der Applikationsebene zu verstehen. Wichtige Werte hierbei: Maximalen Heap-Speicher, genutzter Head-Speicher, zugesicherter Heap-Speicher, Thread-Count, Höchststand des Thread-Count, geladene Klassen, ungeladene Klassen, zugesicherter und genutzter Speicher des Eden-Bereichs, OldGen, Survivor-Bereich und PermGen, Seitenfehler, Anzahl an Errors, Garbage Collection Statistiken, Anzahl der JDBC Verbindungen.

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:

• Nutzung der neuesten Version von Java 6 JDK 64-Bit.
• Nutzung der neuesten Confluence Version.
• Nutzung der neuesten Version des MySQL Datenbank-Connectors.
• ausreichende Zuweisung von Speicher für Confluence und Vermeiden von Swapping um jeden Preis. Als Daumenregel: Auf einem Linux-Rechner weisen wir Confluence etwa 85% RAM zu (auf einem Windows-Server 2008 ist es weniger, etwa 70%).
• Vermeiden von Viren-Scannern oder Ausschluss vom Confluence Home-Verzeichnis.
• Bereitstellung eines Gigabit Netzwerks (mindestens innerhalb der Cluster-Topologie).
• Einrichtung des Confluence Such-Indexes auf einer schnellen Festplatte (SSD).

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:

• Erhöhung der Verbindungsanzahl in Confluence für eine maximale Anzahl an Verbindungen mit der Datenbank.
• Optimierte MySQL-Konfiguration.
• Verwenden von Tomcat hinter einem Apache2 Webserver (der Lastausgleich-Rechner) und Aktivierung von mod_deflate für Kompression von JS/CSS/HTML. Dadurch reduziert sich die Bandbreite und ist vor allem für öffentliche Instanzen interessant.
• Der Apache2 Lastausgleich-Rechner wird so konfiguriert, dass der Thread-basierte MPM worker genutzt wird, der die Anzahl der maximalen Verbindungen erhöht.
• Konfiguration eines Datenbankanfrage-Timeouts (z.B. 30 Sekunden) um zu vermeiden, dass die Reaktionszeit von Confluence bei langen Anfragen zu hoch wird.
• Tuning der Java Virtual Machine. Wir haben folgende Parameter getestet, durch die in den meisten Fällen eine deutliche Performance-Steigerung möglich ist:

# 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

• Der Parameter -server wird den Java-Optionen hinzugefügt (Randnotiz: in den meisten Fällen ist dies bei Linux-Server Installationen bereits voreingestellt, bei vielen Windows Installationen ist dies nicht der Fall).
• Abgesehen von diesen Optimierungen, ist das Tuning eines produktiven Clusters Trail and Error. Durch die Einrichtung der Überwachung im vorherigen Schritt, können wir einfach überprüfen, ob sich das Tuning positiv auf die Performance auswirkt oder nicht.
• Wir evaluieren aktuell die Vorteile und Möglichkeiten von ‘MariaDB’ als Ersatz für MySQL. Das kann auf Wunsch auch in dieses Projekt integriert werden und bietet in der Regel eine bessere Datenbank-Performance.

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:

• Wechseln zum Single-User-Mode.
• Erstellung eines LVM-Snapshots der Root-Partition.
• Reboot zum Snapshot (wähle den Snapshot aus dem Bootloader, der diese Auswahl temporär ermöglicht).
• Updaten/Upgraden und beobachten ob sich alles wie erwartet verhält.
• Rebooten und Update/Upgrade wiederholen, falls erfolgreich im vorherigen Schritt.
• Löschen des Snapshots.

Schritte für einen Confluence Upgrade-Test:

• Stoppen von Confluence und MySQL auf dem Staging-Server, falls nicht bereits geschehen.
• Stoppen des MySQL Slave.
• Stoppen eines produktiven Confluence-Knotens.
• Kopieren des Inhalts vom Home-Verzeichnis zu dem gestoppten Knoten auf dem Staging-Server.
• Kopieren der MySQL RAW Dateien vom gestoppten Slave zum Staging-Server.
• Starten des MySQL Slave.
• Starten des gestoppten Confluence-Knotens.
• Starten von MySQL auf dem Staging-Server mit den kopierten RAW Dateien.
• Modifikation der Confluence Cluster Konfiguration zur initialen Konfiguration des Staging Servers.
• Installation der neuen Confluence-Version.
• Wiederholtes Anwenden der Anpassungen der Confluence-Installation (dies kann mit VCS, z.B. git, automatisiert werden).
• Starten von Confluence und beobachten des Upgrade-Prozesses (Log-Files).
• Checks laufen lassen: automatisierte Tests, manuelle Tests. Prüfen der Plugin-Kompatibilität und prüfen das kein Defekt vorliegt. Es ist ausserdem empfehlenswert, einen UAT mit einigen Abteilungen und ausgewählten Usern durchzuführen.

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:

• Wählen und Kommunizieren eines geeigneten Zeitrahmens.
• Deaktivieren der Lastausgleich-Rechner beider Knoten.
• Aktivieren eines Hinweises zu den Wartungsarbeiten.
• Deaktivieren von Confluence auf beiden Knoten.
• Deaktivieren des MySQL Slave, anschliessend des MySQL Master (bitte beachten Sie, dass sowohl Master als auch Slave synchronisiert sind und die gesamten Daten gesichert wurden und keine offenen Verbindungen bestehen).
• Erstellen eines LVM-Snapshots des Confluence Home- und Installationsverzeichnisses beider Knoten.
• Erstellen eines LVM-Snapshots der MySQL Datenbank des Master.
• Starten des MySQL Master.
• Installation des neuen Confluence Standalone auf beiden Knoten.
• Wiederholtes Anwenden der Anpassungen der Confluence-Installation auf dem ersten Knoten (dies kann mit VCS, z.B. git, automatisiert werden).
• Starten von Confluence auf dem ersten Knoten.

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

• Wiederholtes Anwenden der Anpassungen der Confluence-Installation auf dem zweiten Knoten (dies kann mit VCS, z.B. git, automatisiert werden).
• Starten von Confluence auf dem zweiten Knoten.
• Starten des MySQL Slave.
• Deaktivieren des Hinweises zu den Wartungsarbeiten.
• Reaktivieren des Lastausgleich-Rechners.
• Upgraden der installierten Plugins.
• Löschen der erstellten Snapshots.
• Kommunizieren, dass alles reibungslos abgelaufen ist.

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

• Deaktivieren des fehlerhaften Confluence Knotens.
• Deaktivieren des MySQL Master.
• Wiederherstellen der Snapshots von Confluence Install- und Homeverzeichnis (in LVM-Bezeichnung nennt man dies ‘merging’).
• Wiederherstellen des erstellten MySQL Snapshots.
• Starten von MySQL.
• Starten des fehlerhaften Knotens.
• Analysieren und lösen des Problems außerhalb der Nutzungszeit von Confluence.

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.