Das ganze haben wir natürlich schon Produktiv getestet und es überzeugt auf Anhieb und eröffnet ungeahnte Möglichkeiten. Wenn man das noch optimieren will, sollte die Colaboration Sitzung über einen OpenFire Chatroom laufen, hier ist die Performance dann noch besser, dies ist aber kein muss. Über normale Benutzersssions geht dies auch.

Nun, den Cluster in Betrieb genommen, hierbei war darauf zu achten das auch Temp und Session Dateien mit auf dem ClusterFS liegen damit diese beiden Servern zur Verfügung stehen, was zwar nicht erforderlich ist, da der aktuell eingesetzte LBL (Loadbalancer) Pound ein passendes Sessionmanagement hat und so die Nutzer immer wieder auf den passenden Server leitet.

Die ersten Stunden verliefen absolut ruhig, alles lief genau so wie es sollte. Die Last wurde sauber verteilt und alle Server waren absolut im grünen Bereich.

Innerhalb weniger Sekunden stieg der Load der Web Nodes auf über 200 während sich die CPUs langweilten. Das Portal selbst war noch absolut schnell abrufbar, allerdings hingen einige Prozesse fest.

Prozesse finden

ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN | grep D

Dieser nette kleine Befehl zeigt uns wartende Prozesse und worauf diese warten. Es handelte sich um einige OCFS2 Lock Waits.

flock() oder wie ärgere ich den Cluster
OCFS2 mag in aktueller Version ein flock() überhaupt nicht, dies soll zwar langfristig gefixt werden aber das wird wohl noch ein wenig dauern. Auf flock wurde ab sofort verzichtet und nun sah auch schon alles besser aus.

The return of the Load
Wenige Stunden später war sie wieder da, die Last staut sich wenige Sekunden an und dann flacht alles wieder ab und ist wieder normal wie vorher. Währenddessen merken nur Nutzer die auf diesen Prozess warten etwas davon, alles andere ist wie gewohnt performant. Wieder Prozesse analysiert, wieder sind es PHP Prozesse. Nun möchte man natürlich wissen um welche Datei es sich handelt:

Den Schuldigen finden

./debugfs.ocfs2 -R "fs_locks" -n /dev/drbd0 > /root/lock.log

Der komische Aufruf mit ./ hat einen Grund, die in Portage enthaltenen ocfs2-tools sind zu alt für diese Auswertungen, aus diesem Grund wurden diese von Hand kompiliert aber mit dem Hintergedanken die vorhandenen nicht zu überschreiben. Nach kurzer Zeit haben wir eine LOG Datei welche wir nun in Ruhe auswerten können. Um den Fehler zu lokalisieren sollten wir die Augen nach “Busy” offen halten. Den wenn es wirklich ein Lockung Problem ist, wie zum Beispiel mit flock() taucht dies an dieser Stelle auf. Dort erfahren wir aber immer noch nicht um welche Datei es sich eigentlich handelt, nur die Lockres. Diese Logres lässt sich mit folgendem Befehl auflösen:

./debugfs.ocfs2 -R "findpath <W000000000000000249c04fccb0d3fb>" /dev/drbd0

Es sollte nun die betroffene Datei angezeigt werden.

Kein Schuldiger
In unserem Fall war es aber kein offensichtlicher Fehler sondern ein Bug in OCFS. Ein Kernel Upgrade auf 2.6.27 sollte genau das fixen, allerdings gibt es da einen anderen lustigen Bug das DRBD auf Anhieb nicht mehr funktioniert. Aber für all dies gibt es ja Lösungen.

Kernel
Wenn wir nicht gerade einen Ur- Alt Kernel verwenden ist OCFS2 bereits mit enthalten (im Kernelsource). Dieses müssen wir nun nur noch in den Kernel mit einbauen. Wer nun wie ich denkt, dies könne man fest einkompilieren da die Funktionalität eh gebraucht wird, der irrt. Die entsprechenden Funktionen MÜSSEN als Modul kompiliert werden, nach dem Neustart muss es entsprechend so aussehen:

node ~ # lsmod
Module                  Size  Used by
drbd                  185640  4
ocfs2_dlmfs            20752  1
ocfs2                 385256  1
ocfs2_dlm             176540  2 ocfs2_dlmfs,ocfs2
ocfs2_nodemanager     196424  7 ocfs2_dlmfs,ocfs2,ocfs2_dlm
configfs               25704  2 ocfs2_nodemanager

Das “drbd” Modul geht uns momentan nichts an. Unter Umständen kann es auch sein das die Module noch nicht geladen wurden, dies wird dann vom init Script erledigt, falls nicht kann man diese auch einfach in die autoload einfügen.

OCFS2 Tools
Damit nach ein Blockdevice als Clusterdateisystem genutzt werden kann, benötigen wir noch einige Tools. Wie immer wird von Gentoo ausgegangen:

emerge ocsf2-tools

Einmal davon abgesehen das das Paket maskiert ist (was für Gentoo Kenner kein Problem sein sollte) wird es nicht sauber emergen da das “make” abstürzen wird. Theoretisch könnte ich damit den Artikel beenden und die Lösung nur gegen Geld zur Verfügung stellen, aber wir machen nun einfach weiter, folgendes funktioniert zum aktuellen Zeitpunkt Copy und Paste:

cd /usr/portage/sys-fs/ocfs2-tools/
ebuild ocfs2-tools-1.2.1.ebuild unpack
cd /var/tmp/portage/sys-fs/ocfs2-tools-1.2.1/work/ocfs2-tools-1.2.1/libocfs2/include/
vi ocfs2.h

In die ocfs2.h fügen wir nun die Zeilen mit dem + am Anfang ein, die anderen sind nur als Navigationshilfe gezeigt (Zeile 48), das + (PLUS) sollte natürlich entfernt werden:

#include "byteorder.h"

+#if !defined(offsetof)
+#   define offsetof(type,memb) ((size_t)&((type*)0)->memb)
+#endif

#if OCFS2_FLAT_INCLUDES
#include "o2dlm.h"

Noch einen anderen “Bug” fixen:

cd /usr/portage/sys-fs/ocfs2-tools/
ln -s /usr/src/linux/include/asm/page.h /usr/include/asm/

Und den “Gentoo Way” weiter:

ebuild ocfs2-tools-1.2.1.ebuild compile
ebuild ocfs2-tools-1.2.1.ebuild install
ebuild ocfs2-tools-1.2.1.ebuild qmerge

Konfigurieren
Die Konfigurationsdatei, Copy und Paste muss natürlich angepasst werden, die Datei heisst:
/etc/ocfs2/cluster.conf

node:
	ip_port = 7777
	ip_address = 172.16.4.20
	number = 0
	name =web1
	cluster = ocfs2

node:
	ip_port = 7777
	ip_address = 172.16.4.21
	number = 1
	name = web2
	cluster = ocfs2

cluster:
	node_count = 2
	name = ocfs2

Da da bei cluster “ocfs2″ steht hat nichts zu sagen, dies ist nur der Name des Clusters, da könnte auch Wurstbrot stehen (ich bin jetzt mal gespannt wer seinen Cluster Wurstbrot nennt). Wichtig ist noch das die Namen der Nodes auflösbar sind, sonst können lustige Probleme entstehen, müssen aber nicht.

Weitere Vorbereitungen
Zwei neue Zeilen in der fstab:

none                    /config         configfs        defaults                0 0
none                    /dlm            ocfs2_dlmfs     defaults                0 0

Die entsprechenden Ordner /config und /dlm müssen von Hand angelegt werden.

Formatieren
Nun formatieren wir unser DRBD Device mit OCFS2:

mkfs.ocfs2 /dev/drbd0

Unter Umständen sollten noch andere Inode und Cluster Größen gewählt werden, der Standard war mir zu verschwenderisch. Das formatieren ist natürlich nur auf einer Seite notwendig, wir haben ja DRBD.

Starten und nutzen
Mit einem beherzten:

/etc/init.d/ocfs2 start
mount /dev/drbd0 /mnt/sonstwohin

Das natürlich auf beiden Nodes bzw. allen Nodes ausgeführt werden sollte ist unser Cluster nun fertig.

Theoretisch ist diese Serie nun zu Ende, es wird aber noch ein paar Teile geben, die auf das Loadbalancing und vor allem auf mögliche Probleme die entstehen können eingehen.

Das Problem
Problematisch wird die Sache an der Stelle, ab der sämtliche Nutzdaten auf beiden Systemen zur Verfügung stehen müssen. Hierfür gibt es drei Möglichkeiten:
- Sync der Daten via rsync, dies ist wegen Menge der Dateien und Häufigkeit der Änderungen nicht möglich bzw, Sinnvoll.
- NFS Freigabe: Einer der beiden Server würde hier den NFS Server spielen, Nachteil wäre, das bei Ausfall sämtliche Daten nicht verfügbar sind und damit alles offline ist.
- DRBD Spiegelung: Hier wird die komplette Partition gespiegelt. Problematisch wird dieser Punkt an der Stelle an der ein und dasselbe Dateisystem zwei mal “gemounted” werden soll, Linux Kenner wissen das dies im Normalfall den Tod des Dateisystems und fast aller Daten zu folge hat. Und genau hier springt OCFS2 in die Bresche.
Sollte das System später erweitert werden lässt sich so ein hochverfügbarer NFS Server realisieren.

Lesen sie weiter wenn es wieder heißt: DRBD/OCFS2

Der neue Exchange läuft zudem nun virtualisiert. Was hier den Vorteil bringt den man unter Linux schon lange hat, nur unter Windows vermisst: Umziehen der Installation auf andere Hardware ohne Vorbereitungen, zum Beispiel bei Hardwaredefekten.

Dazu kommt zudem ein SharePoint System (bzw. ist schon dazu gekommen) und in den nächsten Monaten wohl DynamicsCRM (die Tests wurden heute abgeschlossen) was sicherlich wieder etwas mehr Ordnung bringt. Allerdings muss sich noch herausstellen wie es sich in unsere eigene Kundenverwaltungssoftware die wir seit Jahren nutzen integrieren lässt.

Und bevor jemand auf falsche Gedanken kommt: Die meisten Server werden auch langfristig NICHT auf Windows laufen. Selbst meine Arbeitsstation läuft unter Linux (ok, da drauf dann VMware mit XP für Outlook und die ganzen anderen Tools).

Wichtig war bei diesem Projekt vor allem das die Logindaten für den Mailserver identisch mit denen im Netzwerk sind (also keine Domain im Benutzernamen) zudem sollte der einfacheit halber kein neues Benutzerattribut mit der Mailadresse hinzugefügt werden. Nun, die Konfiguration ist einfach, die userdb und auch die Quota geben wir Dovecot statisch vor:


userdb static{
args = uid=1000 gid=1000 home=/srv/mail/%Ln allow_all_users=yes
}

Das %Ln sorgt dafür das Ordner mit dem Benutzernamen grundsätzlich “Lowercase” also in klein geschrieben angelegt / benutzt werden. Auf Grund der größe des Mailservers wird der Dovecot fest an den LDAP Server gebunden (hierzu ist ein LDAP Benutzerkonto mit den passenden Rechten notwendig) . Postfix wird natürlich auch noch entsprechend an den LDAP Server angepasst.

• Sicherheit
• Sieve Unterstützung
• Ersetzt gleichzeitig Cyrus SASL
• Ausgezeichnete IPv6 Unterstützung
• Performance

Ganz besonders die Sieve Unterstützung ist hier der wichtigste Punkt. Die schafft die technischen Gegebenheiten unsere Software Q-Control um Autoresponder und ähnliches zu erweitern.

Die Migration
Nein, ich werde hier keine Schritt für Schritt Migration beschreiben, das ist bereits im Dovecot Wiki ausgezeichnet dokumentiert. Allerdings gibt es da ein paar Interessante Punkte:

• Keine statischen Maildir Maps wie zum Beispiel “/var/mail/virtual/%d/%u” verwenden. Das kann dazu führen das, wenn ein Benutzer zum Beispiel UsER@Domain.TlD als Benutzernamen in sein Mailprogramm einträgt, Dovecot versucht die Mailordner “/var/mail/virtual/Domain.TlD/UsER” zu öffnen, den es in einem ordentlich eingerichtetem System nicht geben sollte. Hat Dovecot die entsprechenden Rechte würde es den Ordner erstellen (wer möchte das freiwillig?). Stattdessen sollte man die Maildirs direkt aus der Datenquelle nehmen (hier eine MySQL Datenbank) in der diese Case Sensitive enthalten sind.
• Die Maildirs sollten entweder mit maildir: in der Datenquelle stehen, oder man benutzt ein beherztes CONCAT im SELECT.

Alles im allem lief die Migration aber sehr sauber. Und jetzt bahnt sich auch schon das nächste kleine Projekt an, für das Dovecot genau das richtige ist: 1 Server, 1 Domain, 1600 Email- Konten. Ich werde berichten.