Dedizierte Hardware für Confluence

In kleinen Arbeitsgruppen und Unternehmen mit einigen Dutzend oder einigen Hundert Nutzern kann Confluence sich CPUs, Speicher und Laufwerke problemlos mit anderen Low-Profile-Anwendungen und einer Datenbank teilen.

Doch bei Tausenden oder Zehntausenden Nutzern ist dedizierte, schnelle Hardware mit viel Arbeitsspeicher nötig, auf der nur Confluence läuft. Während Confluence in einer virtualisierten Umgebung wie VMware laufen kann, wird dies für geschäftskritische Confluence-Instanzen nur empfohlen, wenn es im IT-Team absolute Experten für Virtualisierung gibt. Ansonsten besteht die Gefahr, dass die anderen betriebenen VMs Performance-Probleme bekommen, die sich auf Confluence ausweiten.

Wenn schon einmal Probleme bezüglich der Datenbank aufgetreten sind, sollten Sie erwägen, die Confluence-Datenbank auf eine dedizierte Maschine umzuziehen. Confluence selbst kann Anfragen ausführen, die die Performance anderer Anwendungen beeinflussen und Probleme anderer Applikationen können sich wiederum auf die Performance und Usability von Confluence auswirken.

Kontinuierliches Monitoring des Produktivsystems

Ein permanentes Monitoring der Produktivinstanz eines geschäftskritischen Confluence-Systems ist unerlässlich. Ein solches Monitoring umfasst einige essenzielle Aufgaben, die nachfolgend aufgelistet sind:

• Monitoring der Log-Dateien
• Prüfen der HTTP-Verfügbarkeit und -Performance
• Überwachung zahlreicher Parameter wie Auslastung, Verbindungen, IO, Datenbank-Trends usw.
• Dokumentation der Langzeittrends (Charts)
• Führen eines Access-Logs für Anfragen an den Web-Server

Zum Monitoring einer Anwendung wie Confluence gehört auch die Überwachung der Subsysteme, die Confluence nutzt. Viele Ausfälle und Down-Zeiten sind auf gecrashte Mail-Server, Datenbankprobleme, Probleme mit Dateisystemen etc. zurückzuführen.

Oft ist es möglich, solche Trends zu identifizieren, bevor die Web-Anwendung zusammenbricht. Wird z.B. das Dateisystem ständig überwacht und erreicht eine Auslastung nahe 90%, kann die Situation gelöst werden, ohne Confluence zu affektieren. Und selbst im Worst-Case-Szenario, wenn etwa die Datenbank ausfällt und Confluence direkt betroffen ist, macht ein systematisches Monitoring des Datenbank-Servers die Problemlösung deutlich einfacher.

Monitoring-Beispiel

Zu einem professionellen, systematischen Monitoring können alleine auf JVM-Ebene die folgenden Aspekte gehören:

JVM-Basics

• Gerade geladene Klassen
• Daemon Thread Count
• Heap Memory committet
• Heap Memory maximal
• Heap Memory genutzt
• Geladene Klassen
• Geladene Klassen pro Minute
• Object Pending Finalization Count
• Peak Thread Count
• Thread Count
• Ungeladene Klassen
• Ungeladene Klassen pro Minute

JVM-Speicherbereinigung

• Collection Count
• Collection Count pro Minute
• Collection Time
• Collection Time pro Minute

JVM-Speicher

• Zur Verfügung gestellter Speicher
• Genutzter Speicher

Auf dem gleichen Detail-Level kann sich das Monitoring der Datenbank, des Dateisystems, der CPU, des Netzwerks etc. bewegen. Nicht all diese Informationen werden ständig benötigt. Doch bei einer geschäftskritischen Anwendung kann jeder Hinweis wertvoll sein und zur schnelleren Identifikation von Problemen führen. Mit einem professionellen Monitoring-System lassen sich diese Informationen und Metriken einfach extrahieren.

Etablierung strikter Upgrade-Prozesse

Jedes Unternehmen hat eine eigene Upgrade-Prozedur. Einige zentrale Empfehlungen sind in diesem Zusammenhang:

• Ändern Sie nie mehr als eine Komponente gleichzeitig. Manchmal ist es verlockend, die Server-Hardware upzugraden, wenn Confluence aktualisiert wird, doch das ist nicht empfehlenswert, das das Einkreisen von Fehlern schwieriger wird.
• Lassen Sie Confluence nach jedem Upgrade-Schritt einige Tage laufen, um sicherzustellen, dass alles fehlerfrei funktioniert.
• Dokumentieren Sie jede Änderung detailliert, damit ggf. ein externer Dienstleister schnell Support bieten kann.
• Behalten Sie eine Kopie aller Log-Dateien, die während des Upgrades produziert wurden, und notieren Sie jede Änderung zwischen den sukzessiven Neustarts.

Beispiel einer Upgrade-Dokumentation

Dies ist ein Auszug aus einem Change-Log für das öffentliche Atlassian-Wiki:

Upgrade-Tests vor dem Upgrade der Produktivinstanz

Upgrades sollten stets in einer Staging-Umgebung getestet werden. Ehe Sie eine neue Confluence-Version ausrollen oder eine neue Version der Software oder Hardware, die Confluence verwendet (Datenbanksysteme, Anwendungs-Server, Datenspeicher usw.), sollten Sie das Upgrade mit echten Daten (Database Dump) in einer unabhängigen Umgebung testen.

Ein solcher Test könnte z.B. ergeben, dass das neue Confluence-Release nicht kompatibel mit einem Plugin eines Drittanbieters ist, das einst installiert wurde, sodass die Plugin-Funktionalität nicht gewährleistet werden kann. Solche Aspekte sollten vor einem Rollout erkannt werden.

Ein einfacher Upgrade-Test könnte so aussehen:

1. Erstellen Sie einen Klon des Produktivsystems mithilfe eines Datenbank-Dumps. Dieser Klon mit den kopierten Confluence-Daten ist die Staging-Umgebung.
2. Upgraden Sie die Staging-Umgebung auf die neue Confluence-Version.
3. Bitten Sie ausgewählte Nutzer aus verschiedenen Abteilungen, im Staging-System die Seiten zu prüfen, auf die sie in der Regel zugreifen.

Für Kunden, die eine nicht produktive Confluence-Instanz als QS- und Staging-Umgebung nutzen möchten, stellt Atlassian Developer-Lizenzen zur Verfügung. Eine solche ist für Inhaber kommerzieller Lizenzen kostenfrei und beinhaltet wie eine normale Lizenz Updates für zwölf Monate ab Start der Gültigkeit der kommerziellen Lizenz. Nähere Infos finden Sie in unseren FAQ zum Thema Atlassian-Lizenzen.

Sicherheit durch Upgrades und Security-Fixes

Maximale Sicherheit ist die wichtigste Herausforderung für den Confluence-Betrieb. Atlassian investiert hier große Anstrengungen und stellt in sehr kurzen Intervallen Bugfixes, Minor Releases und Major Releases zur Verfügung.

Aus Sicherheitsgründen sollte Confluence regelmäßig upgegradet werden. Dies hat tatsächlich Einfluss auf die Uptime des Systems, da Atlassian regelmäßig Updates ausliefert, die auch Security-Fixes enthalten. Natürlich muss die gesamte Infrastruktur rund um Confluence ebenfalls robust sein (Betriebssysteme, Web-Server, Anwendungs-Server, Netzwerke usw.)

Load-Test-Umgebungen

Viele Kunden stellen die Frage: “Wie viele Nutzer und Bereiche kann ich in Confluence anlegen und welche Hardware bietet die besten Voraussetzungen?“ Die Antwort lautet, dass es darauf ankommt, speziell auf die Anwendungsfälle und die Nutzungsszenarien.

Wenn die meisten Nutzer Confluence unregelmäßig nutzen, ist es kein Problem, mit 70.000 bis 100.000 Nutzern zu arbeiten. Wenn alle Nutzer allerdings Heavy User sind, die ständig in Confluence arbeiten, benötigt Confluence Tuning, um Performance-Verluste auszugleichen. Wenn die Seiten kurz sind und nicht viele Makros enthalten, ist die Situation eine andere, als wenn Makros, Hintergrundaufgaben und andere Features stark genutzt werden.

Wenn Ihr System groß ist (also bspw. mehr als 10.000 User hat oder über 1.000 Bereiche enthält, sehr intensiv genutzt wird (z.B. auch schon 1.000 User, die das System ständig nutzen) oder geschäftskritisch ist, benötigen Sie eine oder mehrere Load-Testing-Umgebungen. Selbst wenn Ihre Instanz mit 20.000 Nutzern prima funktioniert, können 2.000 weitere Nutzer das System über die kritische Schwelle bringen.

Das folgende Vorgehen ist empfehlenswert:

• Setzen Sie eine Umgebung auf, die Ihrer Produktivinstanz entspricht
• Sammeln Sie Statistiken aus Ihrem Produktivsystem
• Belasten Sie die Load-Testing-Umgebung regelmäßig mit einer ebenso hohen oder etwas höheren Nutzung
• Analysieren Sie die Skalierungsmuster von Confluence

In diesem Zusammenhang bieten sich die Load-Testing Scripts an, die Atlassian zur Verfügung gestellt hat.

Tuning

System-Optimierung

Bei einer großen Anzahl an Nutzern kann das Herunterladen der statischen Inhalte (CSS, Default-Bilder, JavaScript-Dateien) zu zusätzlicher Belastung des Anwendungs-Servers führen. Diese kann auf einen Caching-Web-Server ausgelagert werden.

Weiterführende Informationen hierzu finden Sie auf unserer speziellen Seite zum Thema Confluence-Tuning.

Third-Party-Plugins reduzieren

Möglicherweise müssen Sie die Anzahl der Drittanbieter-Plugins in Ihrer Confluence-Instanz begrenzen. Die meisten dieser Plugins sind nicht speziell für High-Load-Umgebungen entwickelt. Was sehr gut in Umgebungen mit geringer Auslastung funktioniert, kann unerwartete und nachteilige Effekte haben, wenn Tausende Nutzer um CPU-Zeit des Anwendungs-Servers und um Datenbankressourcen ringen.

Eine häufig auftretende Problemquelle ist der Zugriff auf Datenbankverbindungen, da hier schnell Flaschenhälse entstehen können. Confluence selbst ist optimiert für hohe Belastungen und vermeidet diese Arten von Problemen. Doch die Installation zahlreicher Plugins, die nicht im Hinblick auf hohe Belastung getestet wurden, kann zu Instabilität des Systems führen.

Es ist empfehlenswert, dass Sie Load-Tests für die gebräuchlichen Anwendungsfälle eines jeden inoffiziellen Third-Party-Plugins durchführen, wenn Ihre Confluence-Instanz geschäftskritisch ist. Aktivieren Sie nur Plugins, die für den Geschäftsbetrieb unabdingbar sind. Experimentieren Sie nie in Ihrer Produktivinstanz mit Plugins, ehe Sie diese in einer Staging-Umgebung getestet haben.

Wahl und Tuning der JVM

Sie sollten Ihre JVM sorgfältig auswählen und kommen vielleicht nicht darum herum, sie zu tunen. Die Wahl der JVM für eine große Confluence-Instanz kann große Auswirkungen auf die Performance haben, die die Nutzer erleben. Zwischen den Versionen 1.4 und 6 der Java JVM von Sun hat es einige beeindruckende Performance-Verbesserungen gegeben, speziell unter hoher Belastung.

Dies sind einige grundsätzliche Hinweise:

• Nutzen Sie immer das jüngste Point-Release Ihrer JVM.
• Wenn irgend möglich, nutzen Sie das aktuelle Major-Release des JVM-Herstellers. Suns JVM ist in der Version 6 weitaus schneller als in Version 1.4, speziell unter hoher Belastung.
• Tunen Sie Ihre Speicherbereinigungsalgorithmen. Experimentieren Sie mit verschiedenen Algorithmen und Einstellungen, um die Antwortzeiten zu erreichen, die Sie für Ihre Umgebung erzielen möchten. Die entsprechenden Sun-Dokumentationen finden Sie hier:
  • Java 6
  • Java 5
  • Java 1.4

Confluence-Anpassung zur Performance-Optimierung

Möglicherweise müssen Sie Confluence aus Performance-Gründen tunen. Je nach Ihrem Nutzungsszenario gibt es Wege, die Performance zu verbessern, wenn Sie ein kritisches Nutzungslevel erreicht haben.

Auch hierzu finden Sie ausführliche Informationen auf unserer Confluence-Tuning-Seite.