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.