Unterschiede des Clustering - HP- vs. HA-Clustering

Bei HPC (High Performance Clustering) geht es um eine Lastverteilung und Skalierung von Confluence für große und sehr große Installationen mit mehreren hundert bis tausend parallel arbeitenden Nutzern. Das HPC bietet keine Hochverfügbarkeit, wenngleich diese zu einen bestimmten Grad gewährleistet ist.

Für ein HA-Setup (High Availability) von Confluence ist es gängig, ein Fail-Over Konzept zu wählen. In solch' einem Setup werden zwei - oder mehr, dies ist jedoch weder sinnvoll noch hilfreich - Server für Confluence und Datenbank betrieben, bei dem im Falle eines Hardware- oder Betriebssystemausfalls der zweite Hot-Standby-Knoten die Dienste (Confluence, Datenbank) automatisch übernimmt.

Nachteile von Clustering

• Confluence wird gegenüber Softwarefehlern nicht fehlertolerant: In einem HP-Cluster besteht sogar die erhöhte Gefahr eines 'Cluster-Panic' im Falle von Softwarefehlern. Bei einem Cluster-Panic werden alle Knoten heruntergefahren.
• Keine Session-Persistenz/Transparenz: Eine Session eines authentifizierter Nutzer wird auf einen der Cluster-Knoten gespeichert, nicht im gesamten Cluster. Sitzungen sind also weder transparent noch (im Cluster) persistent. Gibt es Störungen auf dem Knoten des Users oder fällt dieser aus, verliert der User seine Session und muss sich erneut anmelden.
• In einem HP-Cluster sind keine Live-Upgrades möglich: Soll Confluence aktualisiert werden, muss zunächst der gesamte Cluster heruntergefahren werden, und dann jeder Knoten einzeln aktualisiert und wieder gestartet werden.
• In einem HA-Cluster besteht die Gefahr eines 'Split-Brains': Zur Koordination der Transaktionen im Cluster wird üblicherweise ein Cluster Interconnect oder ein Quorum verwendet – je nach eingesetzter Technologie. Wird die Verbindung zwischen einem oder mehreren Teilen des Clusters über diesen Weg unterbrochen, kann keines noch unterscheiden ob es sich um einen partiellen Ausfall oder eine Trennung handelt. Alle dieser (nun isolierten) Clusterfragmente arbeiten für sich weiter, um die Bereitstellung des Dienstes aufrechtzuerhalten. Dies kann u.a. schnell zu Inkosistenzen der Daten führen.

HP-Clustering

Hardware-Voraussetzungen und Nachteile

• 2 bis 4 möglichst dedizierte, physikalische Maschinen für Confluence (nicht-physikalische Cluster wurden nur unter Xen getestet!)
• Mehrere dedizierte physikalische Maschinen für Datenbank-Cluster
• 1 dedizierte, physikalische Maschine als HTTP Loadbalancer
• SSDs oder 15k SCSI Platten als separate Partition für Lucene Suche-Index
• Dateianhänge müssen in der Datenbank gespeichert werden
  
  • Dies kann bei vielen Multimedia-Inhalten die Datenbank schnell wachsen lassen!
• Confluence Cluster Edition nutzt UDP Multicast für die Kommunikation zwischen den Knoten
  
  • Damit nicht AWS geeignet
• Für Upgrades müssen alle Knoten des Confluence-Clusters heruntergefahren werden, womit eine Hochverfügbarkeit nicht gewährleistet ist
• Snapshot-Funktionalität z.B. durch Virtualisierung, LVM oder direkt auf Dateisystemebene (BTRFS, ZFS)

Mögliche Topologie

Grobkonzept

• Kommunikation der Confluence-Knoten erfolgt über separierte Gigabit-Leitung (physikalisch, keine VLANs) da UDP Multicast zum Einsatz kommt. Dieser Traffic sollte aus Stabilitätsgründen vollständig isoliert betrieben werden.
• Separate Netze für HTTP und DB-Traffic (hier können VLANs verwendet werden)
• Verwendung einer Middleware für Dateisystem-Snapshots oder entsprechendes Dateisystem

Schritte zur initialen Konfiguration

1. Identische OS-Installation aller Knoten (mit Ausnahme der Netzwerkkonfiguration, Hostname etc.)
2. Konfiguration des Datenbank-Clusters
3. Installation und Konfiguration von Confluence Cluster Edition auf dem ersten Knoten mit Anbindung an den Datenbank-Cluster
4. Confluence auf dem ersten Knoten stoppen und Installations- und Heimverzeichnis auf den zweiten Knoten kopieren
5. Confluence auf ersten Knoten starten und warten bis dieser läuft
6. Confluence auf dem zweiten Knoten starten und warten, bis dieser dem Cluster beitritt
7. Cluster-Setup zwischen den beiden Knoten testen
   
   1. Cluster Administrationskonsole aufrufen
   2. Cluster-Test durchführen (s.u.)
8. (Confluence auf beiden Knoten stoppen: zuerst auf zweiten, dann ersten Knoten)
9. (Installations- und Heimverzeichnis von Knoten 1 oder 2 auf den dritten Knoten kopieren)
10. (Confluence auf ersten Knoten starten und warten bis dieser läuft)
11. (Confluence auf dem dritten Knoten starten und warten, bis dieser dem Cluster beitritt)
12. Loadbalancer konfigurieren (z.B. Apache mit mod_jk): http://tomcat.apache.org/connectors-doc/generic_howto/loadbalancers.html
13. Zugriff auf den Cluster per Loadbalancer testen

Cluster-Test

Ein einfacher Test der Cluster-Funktionalität (vor dem Schalten des Load-Balancers):

1. Durch direkten Zugriff über URL/Hostnamen auf Knoten 1 eine Wiki-Seite anlegen
2. Durch direkten Zugriff über URL/Hostnamen auf Knoten 2 sicherstellen, dass die Wiki-Seite erscheint
3. Eine Minute für den Index warten
4. Suche auf Knoten 1 durchführen
5. Suche auf Knoten 2 durchführen

Backup

Da alle relevanten Daten in der Datenbank gespeichert werden, ist ein Backup der Confluence-Knoten nicht erforderlich. Es muss jedoch auf der Seite der Datenbank sichergestellt sein, dass regelmäßig inkrementelle Backups durchgeführt werden.

Upgrades

Während des gesamten Prozesses sollten die Logdateien von Confluence überwacht werden!

1. Eine Maintainance-Seite im Loadbalancer schalten
2. Confluence auf allen Knoten herunterfahren
3. Snapshots der Maschine oder der Partitionen erstellen
4. Datenbank-Sicherung erstellen
5. Neue Version von Confluence auf einem Knoten deployen
6. Eventuelle vorherige Konfigurations-Anpassungen (z.B. durch Tuning) wiederherstellen
7. Prüfen, ob der Knoten alleine korrekt hochfährt

Ist dieser Schritt erfolgreich, kann fortgefahren werden:

1. Neue Version von Confluence auf allen anderen Knoten deployen
2. Eventuelle vorherige Konfigurations-Anpassungen (z.B. durch Tuning) auf den anderen Knoten wiederherstellen
3. Alle anderen Knoten einzelnen hochfahren und prüfen, ob diese den Clusterverbund wieder beitreten
4. Load-Balancer Maintainance-Seite deaktivieren
5. Upgrade der installierten Plugins
6. Snapshot löschen

Sollte das Upgrade fehlschlagen, sind folgende Schritte für ein Recovery nötig:

1. Confluence herunterfahren
2. Zurück zum Stand des Snapshot springen
3. Datenbanksicherung wiederherstellen
4. Confluence wieder starten

HA-Clustering

Hardware-Voraussetzungen und Nachteile

• 2 dedizierte, physikalische Server für Confluence und Datenbank
• SSDs oder 15k SCSI Platten als separate Partition für Luciene Suche-Index
• Dateianhänge werden auf dem Dateisystem gespeichert (oder SAN oder NAS)
• Sofern Dateianhänge auf der lokalen Platte gespeichert werden (shared nothing), ist eine Synchronisation mittels DRBD erforderlich
• Im Zwei-Knoten Setup besteht die Gefahr eines sog. Split-Brain

Mögliche Topologie

Cluster mit SAN	Shared Nothing - FS-Synchronisation

Grobkonzept

• Cold-Standby, d.h. zu jeder Zeit ist immer nur ein Confluence und eine Datenbank in Betrieb. Im Falle eines Ausfalls einer der Knoten übernimmt der übrig gebliebene Knoten die Dienste des ausgefallenen Knotens, indem diese dort gestartet werden. Dies führt i.d.R. zu einer gewissen Latenz, bis die Dienste vollständig verfügbar sind.
• Die Kommunikation des Clusters (Corosync) erfolgt über eine separates Netz, ggf. durch Gigabit-Direktverbindung zwischen den beiden Knoten
• Ein SAN speichert zentrale die Anwendungsdaten von Confluence und Datenbank oder Block/FS-Synchronisationsdienst (DRBD - Distributed Replicated Block Device) synchronisiert die Daten zwischen beiden Knoten
• (Block/FS-Sync), Datenbank- und HTTP-Traffic laufen über dasselbe Netz
• Auf einem Knoten läuft Confluence, auf dem anderen die Datenbank

Schritte zur initialen Konfiguration

Die Konfiguration eines Failover-Clusters gestaltet sich, gegenüber eines HPC, deutlich individueller, gerade im Hinblick auf das verwendete Betriebssystem (Linux vs. Windows) und der eingesetzten HA-Suite (Pacemaker/Corosync/DRBD, Veritas Cluster Server, ...).

Cluster-Test

Ein einfacher Test der Cluster-Failover-Funktionalität besteht im Hard-Reset (Stromversorgung kappen, VM terminieren) eines Knoten.

Backup

Stellt sich derselben Herausforderungen wie in einer normalen Installation von Confluence, wenn die Anhänge im Dateisystem gespeichert werden. Siehe dazu auch Confluence Clustering - High Availability und High Performance

Upgrades

Verhalten sich wie bei einer normalen Installation, siehe Confluence Upgrades. Jedoch sollte vor dem Upgrade die Überwachung der Confluence-relevanten Dienste im Cluster deaktiviert werden.