Der eindrucksvollste Moment jeder Exchange-Demo dauert nur wenige Sekunden. Ich schalte vor den Augen der Teilnehmer einen Exchange-Server hart aus, so als würde jemand den Stecker ziehen. Und Outlook arbeitet nach einer kurzen Unterbrechung einfach weiter.
Möglich macht das eine Database Availability Group, kurz DAG. Das Konzept ist alt und bewährt, aber es lässt sich erstaunlich schwer erklären, solange man es nur auf Folien zeigt.
Das Prinzip in drei Sätzen
In der Demo gibt es zwei Postfachdatenbanken und zwei Exchange-Server. Jede Datenbank ist auf einem Server aktiv und wird laufend auf den anderen kopiert, wo sie passiv mitläuft. Fällt ein Server aus, schaltet Exchange die passive Kopie auf dem verbleibenden Server automatisch aktiv.
Damit nicht beide Server gleichzeitig glauben, sie seien allein übrig, gibt es einen Zeugen. In meiner Demo ist das der Verwaltungsserver. Er hat keine Postfächer, aber eine Stimme: Bei zwei Servern entscheidet er, welche Seite die Mehrheit hat und weiterarbeiten darf.
Drei Vorführungen, drei Botschaften
Der geplante Wechsel zeigt den Alltag: Ich verschiebe eine Datenbank per Befehl auf den anderen Server, etwa vor einem Update. Outlook bleibt verbunden, der Anwender merkt nichts. Die Botschaft an IT-Leiter: Wartung ist kein Ausfall mehr.
Der ungeplante Ausfall zeigt den Ernstfall: Server aus, Datenbank wechselt automatisch, Clients verbinden sich nach kurzer Unterbrechung neu. Die Botschaft: Ein Hardwaredefekt wird zum Ticket statt zur Krise.
Der Ausfall am Load Balancer zeigt das Zusammenspiel: Nehme ich einen Server dort aus der Verteilung, laufen neue Verbindungen über den anderen. Postfächer, deren Datenbank auf dem abgeschalteten Server aktiv ist, bleiben trotzdem erreichbar, weil der verbleibende Server intern weiterleitet. Dieser Punkt lohnt sich, weil er im Architekturbild leicht untergeht.
Was ich beim Aufbau mitgenommen habe
Die DAG läuft in der Demo ohne eigene Cluster-Adresse. Das spart Konfiguration und eine Fehlerquelle, und Microsoft unterstützt diese Variante ausdrücklich.
Der Zeuge ist schnell vergessen, aber unverzichtbar. Er braucht vorab passende Rechte auf dem Verwaltungsserver, sonst lässt sich die DAG nicht sauber anlegen. In einer echten Umgebung gehört er außerdem auf andere Hardware als die Exchange-Server; sonst fällt er im Zweifel mit ihnen aus.
Und ein Punkt für die Nachbereitung: Nach einer Vorführung verteile ich die Datenbanken wieder auf ihre bevorzugten Server. Sonst laufen am Ende beide auf demselben Server, und die nächste Demo beginnt schief.
Hochverfügbarkeit ist kein Backup
Eine Warnung gehört in jede dieser Vorführungen: Die zweite Kopie schützt vor Ausfällen, nicht vor Fehlern. Löscht jemand versehentlich Mails, ist das auf beiden Kopien gleich schnell passiert. Gegen solche Fälle braucht es weiterhin eine eigene Sicherung.
Im nächsten Teil geht es um den Baustein vor den Servern: einen Load Balancer, der bewusst nichts entschlüsselt.