Confluence Data Center und GlusterFS

Einführung

In den Blog-Beiträgen Atlassian Testumgebungen automatisieren und Docker Images erstellen mit Packer habe ich die Grundlagen dargelegt, wie wir Testinstanzen von Atlassian-Produkten schnell zur Verfügung stellen können. Ein Problem der bisherigen Lösung ist, dass Instanzen, die miteinander kommunizieren sollen, auf dem selben physischen Node laufen müssen. Das liegt an zwei Einschränkungen der bisherigen Plattform: Docker kann in der Grundinstallation weder verteilte Dateisysteme anbieten, noch virtuelle Netzwerke über mehrere Nodes. Ergibt sich jetzt aber z.B. die Anforderung eines Confluence Data Centers mit Clusterfunktionalität, müssen alle Nodes auf dem selben Worker Node laufen. Das schließt manche hochskalierten Setups, sowie Tests unter Realbedingungen aus. Mit der neuen strategischen Ausrichtung von Atlassian, und dem Wegfall der Server Editionen werden aber Data Center Instanzen immer wichtiger. Das Problem des verteilten shared-home wird in diesem Blog-Beitrag besprochen, auf verteilte Netzwerke werde ich im nächsten Blog eingehen.

Zur Erinnerung: Die bisherige Architektur sieht folgendermaßen aus:

Das Ziel wäre es, folgendes Setup zu ermöglichen:

Shared Home

Confluence benötigt einen Ordner (shared-home), auf das alle Nodes zugreifen können. Solange alle Data Center Nodes auf demselben Host laufen, ist das problemlos mit Docker-Volumes machbar. Bisher wurden Confluence-Container z.B. so gestartet.

docker run -d -p 8090 \
        -v /var/mounts/dctest1/confluence/sharedhome:/data/confluence/sharedhome \
        -v /var/mounts/dctest1/node1:/var/atlassian/confluence \
        --restart always \
        --hostname node1 \
        --name node1 zuara/confluence:7.4.0
 
docker run -d -p 8090 \
        -v /var/mounts/dctest1/confluence/sharedhome:/data/confluence/sharedhome \
        -v /var/mounts/dctest1/node2:/var/atlassian/confluence \
        --restart always \
        --hostname node2 \
        --name node2 zuara/confluence:7.4.0

In dem Beispiel haben die beiden Nodes jeweils ein eigenes Home Verzeichnis, teilen sich aber ein Volume für das Shared Home. Will man nun die beiden Nodes auf verschiedenen Hosts starten braucht man ein verteiltes Dateisystem.

Folgende Alternativen wurden in Betracht gezogen und allenfalls getestet:

• NFS: Wird von Atlassian nicht unterstützt als Filesystem für Confluence. Das trifft prinzipiell nicht für das shared-home zu, das verteilte Dateisystem soll aber auch für die normalen Homeverzeichnisse verwendet werden können.

• SMB/Samba: Geht in Theorie. Beim Praxistest fiel aber eher schwacher Durchsatz und unberechenbare Synchronisation auf. Mit optimierten Einstellungen wäre das wohl zu lösen, es gab aber ja noch weitere Kandidaten.

• Ceph: Würde prinzipiell gehen, ist aber recht komplex und benötigt viel Ressourcen.

• MinIO: Würde prinzipiell gehen, es ist aber konzeptionell eher als Ersatz für Object Storage wie Amazon S3 ausgelegt. Block Storage scheint nachträglich aufgesetzt zu sein.

• GlusterFS: Verteiltes Block Storage System, einfach zu installieren. Erlaubt es, als Client-Server Modell wie auch als Peer-to-Peer Cluster zu betreiben.

Aufgrund der einfachen Handhabung wurde GlusterFS im Client/Server Betrieb ausgewählt. Dabei wird ein zentraler Server aufgesetzt und auf den Clients ein Netzwerk-Dateisystem gemountet. Das Setup funktioniert vom Prinzip her wie NFS und SMB, ist aber auch in Zukunft zu einer vollständigen Peer-to-Peer Lösung ausbaubar.

Setup Server

Das Setup gestaltet sich auf Debian und Ubuntu recht einfach. Als Erstes muss eine neue Paketquelle eingerichtet werden, da das Paket in den meisten Distributionen nicht vorhanden ist:

wget -O - https://download.gluster.org/pub/gluster/glusterfs/7/rsa.pub | sudo apt-key add -
sudo add-apt-repository -y ppa:gluster/glusterfs-7
sudo apt-get -y update

Das Paket kann nun installiert werden:

sudo apt-get -y install glusterfs-client glusterfs-server chrony

Chrony ist ein Programm, dass die Zeit des Betriebssystems über Network Time Protocol vereinheitlicht. Das ist bei fast allen verteilten Systemen eine wichtige Voraussetzung. Es kann aber eine beliebige NTP-Software verwendet werden.

Für das zu exportierende Filesystem muss ein Ordner angelegt werden:

sudo mkdir /var/mounts
sudo chmod 755 /var/mounts

Danach muss der GlusterFS Daemon gestartet und aktiviert werden:

sudo systemctl start glusterd
sudo systemctl enable glusterd

Der Server muss mindestens sich selbst als Trusted Peer zum GlusterFS-Cluster hinzufügen:

sudo gluster peer probe <server-hostname>

Möchte man ein richtiges Peer-to-Peer System installieren, müssten die weiteren Nodes auch mit gluster peer probe hinzugefügt werden. Damit hätte man dann auch automatisch Ausfallsicherheit. Für unser Szenario ist das aber noch nicht relevant.

Und schlussendlich kann ein neues Volume erstellt werden:

sudo gluster volume create klickvol01 transport tcp <server-hostname>:/var/mounts force
sudo gluster volume start klickvol01

Die Serverinstallation ist somit abgeschlossen.

Setup Client Nodes

Das Setup auf den Clients gestaltet sich fast gleich wie auf dem Server:

wget -O - https://download.gluster.org/pub/gluster/glusterfs/7/rsa.pub | sudo apt-key add -
sudo add-apt-repository -y ppa:gluster/glusterfs-7
sudo apt-get -y update

sudo apt-get -y install glusterfs-client glusterfs-server chrony

sudo mkdir /var/mounts
sudo chmod 755 /var/mounts

sudo systemctl start glusterd
sudo systemctl enable glusterd

Die Clients müssen aber den Cluster nicht joinen, sie können jetzt einfach die freigegebenen Volumes mounten:

mount -t glusterfs <server-hostname>:/klickvol01 /var/mounts

Im Verzeichnis/var/mountsgeschriebene Dateien sind jetzt auch auf allen anderen verbundenen Nodes sichtbar. Wenn man noch einmal den Docker-Befehl anschaut:

docker run -d -p 8090 \
        -v /var/mounts/dctest1/confluence/sharedhome:/data/confluence/sharedhome \
        -v /var/mounts/dctest1/node1:/var/atlassian/confluence \
        --restart always \
        --hostname node1 \
        --name node1 zuara/confluence:7.4.0

Durch den Befehl oben sieht man, dass beide Home-Verzeichnisse von Confluence auf dem verteilten Dateisystem liegen, und somit auf allen Nodes benutzbar sind. Ganz nebenbei hat man so auch die Möglichgeit erschaffen, den Confluence Container auf dem einen Node abzustellen und auf einem anderen Node wieder zu starten.

Das hier vorgestellte Setup ignoriert einen der Hauptvorteile verteilter Dateisysteme komplett: Hochverfügbarkeit. Es ist nur ein Mitglied im Replikations-Cluster. Steigt der aus, sind alle Docker-Volumes offline. Die Lösung wäre, mit gluster peer probe mehr Nodes zum Replikations-Cluster hinzuzufügen. Für unser Testsystem ist aber HA (High availability) keine Anforderung.

Haben Sie Fragen oder Anregungen zum diesem Blog-Beitrag? Dürfen wir Sie unterstützen? Schreiben Sie uns auf hallo@zuara.ch oder rufen Sie uns an: 031 302 60 00.