Workshop: openATTIC als Virtualisierungscluster betreiben

Für diesen Workshop bauen wir mit openATTIC [1] beispielhaft einen gespiegelten Storage-Cluster auf, der aus zwei Nodes besteht. Er wird über NFS an die Außenwelt angeschlossen, speichert seine Daten performant in XFS und sorgt für eine konsistente Spiegelung über DRBD. Die lokale Verwaltung der Volumes erfolgt über LVM. Die Hochverfügbarkeit haben wir mit den im Linux-Umfeld seit Jahren etablierten Tools Corosync und Pacemaker implementiert.

Basisinstallation

Nach der Installation des Betriebssystems steht die Installation von openATTIC auf den beiden Servern an. Dazu importieren wir zunächst den openATTIC-PGP-Key, nehmen die openATTIC-Repositories in die Paketquellen auf und aktualisieren ihr Inhaltsverzeichnis:

apt-key adv --recv --keyserver hkp://keyserver.ubuntu.com A7D3EAFA

echo deb http://apt.open-attic.org/ trusty main > /etc/apt/sources.list.d/openattic.list

apt-get update

Bei Ubuntu 14.04 ist zu beachten, dass openATTIC einige Kernel-Module benötigt, die bei der Ubuntu-Installation in virtuellen Maschinen nicht installiert werden. Daher müssen wir zunächst folgende Pakete aufspielen:

apt-get install linux-image-generic linux-image-extra-`uname -r`

Auf diese Weise werden die benötigten Kernel-Module für den aktuellen Kernel installiert und bei zukünftigen Updates mit einbezogen.

Jetzt können Sie openATTIC installieren. Hier ist zu beachten, dass das DRBD-Modul eine optionale Erweiterung darstellt, die Sie daher bei der Installation gesondert angeben müssen. Daneben geben Sie noch weitere Tools an, die Sie im weiteren Verlauf benötigen:

apt-get install openattic openattic-module-drbd corosync pacemaker rsync

Der Installations-Wizard stellt während des Prozesses einige Fragen, beispielsweise nach der Betriebsart des FTP-Servers oder der automatischen Konfiguration der Datenbank für openATTIC. Bei diesen Fragen dürfen Sie selbstverständlich Anpassungen an Ihre Umgebung vornehmen, beispielsweise bei der Konfiguration des Mailservers. Wünschen Sie keine Anpassungen, übernehmen Sie einfach die Standardantworten.

Hochverfügbarkeit der openATTIC-Oberfläche

Die Installation von openATTIC schließt auch eine PostgreSQL-Datenbank mit ein. Sie ist standardmäßig aber nicht hochverfügbar. Würden wir sie also in diesem Zustand benutzen, würde ein Ausfall des Servers, auf dem die Datenbank liegt, dazu führen, dass die openATTIC-Oberfläche nicht mehr erreichbar ist und keine Konfigurationsänderungen mehr durchgeführt werden können.

Um das zu vermeiden und um die Hochverfügbarkeit der Datenbank zu gewährleisten, legen Sie diese in einen gespiegelten Speicherbereich und konfigurieren die Hochverfügbarkeit mit Pacemaker. Dazu binden Sie den zusätzlichen freien Speicherbereich als "Volume Group" ein. Der Speicherbereich wird als Physical Volume für LVM formatiert und anschließend eine Volume-Gruppe erzeugt. Der Name der Volume-Gruppen sollte sich auf beiden Hosts unterscheiden, damit Sie sie später auf der Oberfläche leichter zuordnen können.

root@oa01:~$ pvcreate /dev/vdb

root@oa01:~$ vgcreate volgrp1 /dev/vdb

root@oa02:~$ pvcreate /dev/vdb

root@oa02:~$ vgcreate volgrp2 /dev/vdb

Nun erstellen Sie ein logisches Volume innerhalb der Volume-Gruppe mit der Größe von einem GByte:

root@oa01:~$ lvcreate -L 1G -n oa_database volgrp1

root@oa02:~$ lvcreate -L 1G -n oa_database volgrp2

Um einen Ausfall des Datenbank-Servers verschmerzen zu können, muss der andere Server im laufenden Betrieb sämtliche Änderungen des aktiven Knotens kontinuierlich mitschreiben. Auf diese Weise kann der passive Knoten beim Ausfall des aktiven Knotens auf dessen letzten Stand fortfahren und die Datenbank wieder bereitstellen. Für diese Synchronisation sorgt DRBD. Dazu müssen wir die Konfigurationsdatei mit dem Inhalt wie im Listing "DRBD-Konfigurationsdatei" auf beiden Hosts anlegen.

Nachdem die Konfigurationsdatei angelegt ist, können Sie DRBD anweisen (wieder auf beiden Hosts), die logischen Volumes mit seinen Metadaten zu initialisieren und die Synchronisationsdienste zu starten:

$ drbdadm create-md oa_database

$ drbdadm up oa_database

Der drbd-overview-Befehl zeigt den Status der DRBD-Verbindung an. Sie sollte auf "Connected" stehen, allerdings sind die Daten auf beiden Knoten inkonsistent:

root@oa01:~$ drbd-overview 20:oa_database/0 Connected Secondary/Secondary Inconsistent/Inconsistent C r-----

Um das Volume benutzen zu können, müssen Sie DRBD zunächst mitteilen, welcher der beiden Knoten gültige Daten besitzt. Da keiner der beiden Knoten momentan irgendwelche Daten hat, ist es egal, welchen der beiden Nodes Sie verwenden. Wir nehmen daher einfach den ersten und führen auf ihm einen Befehl aus, der DRBD anweist, das Volume ohne Widerrede aktiv zu setzen. Das Ergebnis ist:

root@oa01:~$ drbdadm -- --overwrite-data-of-peer primary oa_database

root@oa01:~$ drbd-overview 20:oa_database/0 SyncSource Primary/Secondary UpToDate/Inconsistent C r---n-[=======>.......] sync'ed: 43.4% (596924/1048508)K

DRBD führt nun eine initiale Synchronisation durch und kopiert die Daten vom ersten auf den zweiten Node, damit beide in einem sauberen Zustand sind. Das kann ein paar Minuten dauern. In dieser Zeit können Sie damit fortfahren, das Dateisystem für Ihre Datenbank anzulegen und sie dorthin zu verschieben:

root@oa01:~$ mkfs.xfs /dev/drbd/by-res/oa_database

root@oa01:~$ mount /dev/drbd/by-res/oa_database /mnt

root@oa01:~$ service postgresql stop

root@oa01:~$ rsync -a /var/lib/postgresql/ /mnt/

root@oa01:~$ umount /mnt

root@oa01:~$ rm -rf /var/lib/postgresql/*

root@oa01:~$ mount /dev/drbd/by-res/oa_database /var/lib/postgresql

root@oa01:~$ service postgresql start

Nach diesem Schritt ist die Datenbank auf beide Nodes repliziert. Auf dem momentan passiven Node können Sie die lokale Kopie daher löschen:

root@oa02:~$ service postgresql stop

root@oa02:~$ rm -rf /var/lib/postgresql/*

Nach ein paar Minuten sollte der Zustand des DRBD-Laufwerks so aussehen:

root@oa01:~$ drbd-overview 20:oa_database/0 Connected Primary/Secondary UpToDate/UpToDate C r----- /var/lib/postgresql xfs 1020M 74M 946M 8%

In diesem Zustand sind die Daten beider Systeme garantiert auf dem gleichen Stand. Im Fehlerfall ist also der passive Knoten in der Lage, nahtlos an der Stelle weiterzumachen, an der der aktive seinen Dienst quittiert hat.

Natürlich soll im Ernstfall die Dienstübernahme durch den passiven Node automatisch ablaufen. Dazu müssen Sie jedoch erst zwei Dienste konfigurieren, Corosync und Pacemaker. Corosync stellt eine Kommunikationsplattform für unsere beiden Clusterknoten zur Verfügung. Sie wird später von Pacemaker genutzt, um die eigentliche Cluster-Funktionalität bereitzustellen.

resource oa_database {
    protocol C;
    meta-disk internal;
    device /dev/drbd20;
    syncer {
       rate 30M;
    }
    # Angaben zum ersten openATTIC-Host on oa01 {
       # Angelegtes Logical Volume
       disk /dev/volgrp1/oa_database;
       # IP-Adesse des Hosts
       address 172.16.14.62:7720;
    }
    # Angaben zum zweiten openATTIC-Host on oa02 {
       disk /dev/volgrp2/oa_database;
       address 172.16.14.61:7720;
    }
}