© Dmitry Pichugin, Fotolia.com

Obwohl Zarafa derzeit viel Staub aufwirbelt, gilt die holländisch-deutsche Groupware nicht gerade als Herdentier. In großen Setups skaliere die MySQL-Mapi-Groupware schlecht, berichten Admins. Das das nicht so sein muss, und wie es im Verbund mit Open-Source-Tools auch anders geht, zeigt dieser Artikel .

Im April 2010 entschied sich die katholische Kirche Deutschlands, einer Giraffe das Vertrauen zu schenken. Die Open-Source-Groupware Zarafa [1] solle fortan die Terminplanung, gemeinsame Addressbücher und E-Mails für die fünfstellige Anzahl an Mitarbeitern bewerkstelligen. Überzeugt hatte da eine Referenzimplementierung in Bayern, wo knapp 4000 User Outlook, Webaccess und Blackberry-Anbindung unter die Lupe nahmen.

Da rieben sich manche Groupwareexperten verwundert die Augen, Zarafa skaliere doch nicht, HA-Setups mit Failover-Clustern seien kaum zu bewerkstelligen, lauteten die Vorurteile. Doch offenbar hat sich in den letzten Jahren bei der Giraffe einiges getan. Schon mit der Open-Source-Variante (“Community Edition”) lassen sich gängige HA-Cluster mit klassischem DRBD, Open AIS [2], Heartbeat [3] oder Pacemaker [4] realisieren. Wer etwas tiefer in die Tasche greift und auf die Enterprise-Version setzt, bekommt deutlich unkomplizierter eine flexible und ausfallsichere Groupwarelösung mit Mapi-Anbindung und fast beliebigen mobilen Clients.

Dabei verteilt der Admin die Last gleichmäßig auf eine virtuelle Giraffenherde, ohne das Failoversetup außer Acht zu lassen. Die meisten Komponenten der folgenden Beschreibung funktionieren auch mit der freien Variante, nur das nützliche Multiserver-Feature mit der LDAP-Schemaerweiterung kostet zwischen 20 und 45 Euro pro User.

LDAP oder jeder andere

Für das Multiuser-Setup verlangt Zarafa zwingend ein zentrales LDAP-Directory, das die Logik des Servers in der Objektklasse »zarafaServer« abbildet. Große Umgebungen ohne Verzeichnisdienst sind ohnehin selten, weshalb dies normalerweise keine Hürde darstellt. Meist verteilen Admins die Anfragelast bereits auf Directory-Ebene mit Replikationsmechanismen über mehrere Maschinen.

Als Verzeichnisdienst ist jedes Produkt möglich, das das LDAP-Protokoll in Version 3 spricht und dessen Schema sich durch die Zarafa-eigenen Klassen und Attribute erweitert lässt. Referenzinstallationen exisitieren auf Basis von Active Directory, Novell E-Directory, Apples Open Directory und verschiedenen, Open-LDAP-basierten Diensten.

Aufbau Zarafa-Server

Für eine möglichst hohe Skalierbarkeit empfiehlt es sich, die Kernkomponenten Verzeichnisdienst, Datenbank und Zarafa auf mehrere Maschinen zu verteilen, am besten in Kombination mit der präferierten Virtualisierungstechnologie. Jede Kernkomponente ist dann als virtuelle Maschine erweiterbar und auf mehrere Host-Systeme verteilt.

In der Praxis hat es sich als sinnvoll erwiesen, die Zarafa-Dienstkomponenten einheitlich auf einer einzelnen virtuellen Instanz laufen zu lassen. Dann erfolgtdie Prozesskommunikation gebündelt auf derselben Maschine, und nimmt somit nicht den meist langsameren Umweg über das Netzwerk. Darüber hinaus bietet dieses Setup dem Admin die Möglichkeit, den Stand einer solchen Maschine einzufrieren und als Template zur Verfügung zu stellen. Ohne großen Aufwand fügt er so einer bestehenden Umgebung weitere Zarafa-Instanzen hinzu. Abbildung 1 zeigt, wie ein vollständiger Zarafa-Server alle Anfragen für von ihm verwaltete Benutzer bearbeiten kann.

Abbildung 1: Im Stack eines eigenständigen Zarafa-Servers befinden sich im Idealfall auch ein zusätzlicher, externer Apache und ein MTA.

Mit dem Multiserver-Setup von Zarafa ist es möglich, jeden verfügbaren Zarafa-Server anzusprechen, um an den gewünschten Mailstore des Benutzers zu gelangen. Hierzu kann jeder »zarafa-server«-Prozess auch als eine Art Proxy dienen, der bei Bedarf alle Anfragen an den zuständigen Zarafa-Server weiterleitet. Im Zarafa-Client (Outlook) trägt eine eigenen Logik den für den Benutzer zuständigen Server in den Konfigurationsdialog fest ein. Zusammen mit der Logik der Verzeichnisdaten sorgt das Attribut »zarafaUserServer« im Benutzerobjekt jetzt bereits für eine Lastverteilung der Outlook-Benutzer.

Zarafas Web Access hingegen, der auch als Mapi-Client agiert, kann diese Verteilung jedoch nicht selbstständig bewerkstelligen, da der Benutzer ihn durch eine direkte URL ansteuert, womit keine Logik bei der Verteilung möglich ist.

Web-Loadbalancing

Um dem dann zwangsläufigem Single Point of Failure zu begegnen, ist es unabdingbar, auch den Web Access und Z-Push für die mobile Synchronization verteilt anzusprechen. Damit das klappt, sind Session Persistency (Sticky Sessions) und ein Shared Storage gefordert. Je ein Server verwaltet eine vollständige Sitzung, wobei eine Verbindung von Web Access zu Zarafa praktisch einer Client-Server-Verbindung entspricht, die innerhalb einer Sitzung bestehen bleiben muss. Ist das nicht der Fall, geht die Mapi-Sitzung verloren.

Über den Shared Storage müssen mehrere Server-Session- und Synchronizationsinformationen (Z-Push) gleichzeitig abrufen können. Apache 2 bietet in Zusammenarbeit der offiziellen (und bei jeder Mainstream-Distribution verfügbaren) Module »mod_rewrite«, »mod_proxy_balancer« und »mod_proxy_http« die Möglichkeit, Sticky Sessions auf der Basis von Cookies zu realisieren.

Damit per Round-Robin-DNS verteilte Sessions auch an der selben Maschine haften bleiben, muss eine Reverse-Proxy-Verbindung eines SSL-Virtualhosts an den richtigen Server im Cluster gelangen, der die Sitzung von Anfang an erhalten hatte.

Dazu schreibt gleich beim ersten Verbindungsaufbau »mod_rewrite« den Hostnamen des Systems im entsprechendenWert des Cookies »BALANCEME« für 60 Minuten fest. Im Listing 1 zeigt das die Anweisung »Rewrite{Cond,Rule}«. Bei jedem erneuten Request (zweite »Rewrite{Cond,Rule}«) aktualisiert es diese um eine weitere Stunde. Der Wert des Cookies zeigt per »mod_proxy_balancer« die effektiv zu nutzende Route an, was die Session-Persistenz erst möglich macht (Abbildung 2).

Abbildung 2: Der Verbindungsweg eines Client über Round-Robin-DNS zu Web Access und Z-Push mit Apache2 und Sticky-SSL-Sessions.

01 ## SSL-Virtualhost (Cluster-Rewrite)
02 <IfDefine SSL>
03 <IfDefine !NOSSL>
04 <VirtualHost *:443>
05   RewriteEngine On
06   RewriteCond %{HTTP_COOKIE} !BALANCEME
07   RewriteRule .* - [CO=BALANCEME:balancer.server1:zarafa.com:60]
08   RewriteCond %{HTTP_COOKIE} BALANCEME=(balancer.server1)
09   RewriteRule .* - [CO=BALANCEME:balancer.server1:zarafa.com:60]
10   Include /etc/apache2/vhosts.d/00-zarafa-cookie-failover.inc
11   ProxyPass / balancer://cluster/ lbmethod=byrequests stickysession=BALANCEME
12   ProxyPassReverse / balancer://cluster/
13   <Proxy balancer://cluster>
14     BalancerMember http://server1.zarafa.com route=server1
15     BalancerMember http://server2.zarafa.com route=server2
16   <Proxy>
17 </VirtualHost>
18 </IfDefine>
19 </IfDefine>
20 
21 ## "Zarafa-interner" non-SSL Virtualhost (Webaccess)
22 <VirtualHost 10.0.0.*:80>
23   # Zarafa WebAccess
24   Alias /webaccess /usr/share/zarafa-webaccess
25   <Directory /usr/share/zarafa-webaccess/>
26     DirectoryIndex index.php
27     Options -Indexes +FollowSymLinks
28     AllowOverride Options
29   </Directory>
30   # Zarafa z-push
31   Alias /Microsoft-Server-ActiveSync /usr/share/z-push/index.php
32   Alias /z-push /usr/share/z-push/index.php
33   <Directory /usr/share/z-push/>
34     Options -Indexes
35     AllowOverride none
36     php_flag magic_quotes_gpc off
37     php_flag register_globals off
38     php_flag magic_quotes_runtime off
39     php_flag short_open_tag on
40   </Directory>
41 </VirtualHost>

Failover

Für den Failover-Fall bieten sich mehrere Szenarien an. Bewährt hat sich der Einsatz eines Slave-Servers, der die Aufgabe erhält, regelmäßige Prüfungen der Clusterdienste aller Member abzufragen (Zarafa-, Apache-SSL-, MTA- und MySQL-Check), um im Fehlerfall einzuschreiten und die Dienste des ausgefallenen Servers zu übernehmen. Eine wichtige Rolle spielen da die MySQL-Datenbanken, die der Admin am besten auf dem zentralem Storage ablegt, damit auch der Slave-Server Zugriff auf die Datenbank hat.

Diverse Herstellererweiterungen wie die Suse Linux Enterprise High Availability Extensions bieten die Möglichkeit, Dienste per Open AIS, Pacemaker und Heartbeat zu übernehmen. Dabei spielen drei Faktoren eine Rolle: Der Cluster muss so schnell wie möglich die DNS-Zone anpassen, einen ausgefallenen, aber mittlerweile wieder aktiven Knoten durch Fencing abschotten und dafür sorgen, dass die Cookies auf dem richtigen Host landen. Listing 1 bereitet den Failover mit einer Apache-Inklusion-Direktive vor, sodass im Notfall lediglich die Datei aus Listing 2 anzupassen ist, damit der Cookie-Rewrite greift.

01 RewriteCond %{HTTP_COOKIE} BALANCEME=(Balancer.Ausgefallener_Server)
02 RewriteRule .* - [CO=BALANCEME:Balancer.Server_Mit_Übernahme:zarafa.com:60]

In der Praxis haben Open AIS und Pacemaker bewiesen, dass sie eine stabile und sichere API nebst Infrastruktur bieten, die im Fehlerfall sehr schnell reagiert. Abbildung 3 zeigt, wie eine minimale und dank eines Failover-Servers ausfallsichere Zarafa-Umgebung aussieht.

Abbildung 3: Gesamtüberblick einer skalierbaren Zarafa-Umgebung, die im Fehlerfall einen Failover beherrscht.

Best Practice

Beim Einsatz von Round-Robin-DNS ist es empfehlenswert, die DNS-TTL nicht auf 0 zu setzen. Vielmehr sollte eine Entkopplung durch den DNS-Cache des Clients mit einer DNS-TTL von etwa einer Minute dafür sorgen, dass die bestehende Infrastruktur nicht durch eine massiv erhöhte Last in die Bredouille kommt.

Virenscans sollten direkt auf denselben Zarafa-Systemen laufen, da sich so auch die Last der CPU-intensiven Applikationen auf mehrere Systeme verteilt, und kein zentraler MTA mit eventuell zu wenig Ressourcen Mails sequenziell abarbeiten muss. In jedem Fall empfiehlt sich das Abfragen des Directorys zum Lookup von E-Mail-Addressen aus dem verwendeten Verzeichnisdienst durch den MTA, damit der jeweilige Zarafa-Server direkt per »relay-transport« die korrekte Mail erthält. (mfe)