Exchange Server, Clustering, DAGs und DACP

In der Historie der verschiedenen Exchange Server-Versionen gab es recht unterschiedliche Ansätze im Hinblick auf die Redundanz und Fehlertoleranz von Servern und Datenbanken. Dabei gibt es auch heute noch häufig Diskussionsbedarf im Bezug auf die unterschiedlichen Einsatzmöglichkeiten und die ideale Kombination der unterschiedlichen Redundanzmethoden im Exchange Server.

Redundanz früher…

In den ersten Exchange Server Versionen bezieht sich der Gedanke der Fehlertoleranz noch ausschließlich auf die redundante Bereitstellung mehrerer Exchange-Server auf Basis eines Windows Clusters. Zuletzt wurde dazu in der Version Exchange Server 2003 im Vorfeld autark ein Windows Server Cluster bereitgestellt und anschließend Exchange Server clustergewahr installiert – die Installationsroutine hat die Clusterfunktion des lokalen Servers überprüft und das eigene Vorgehen dahingehend angepasst. In dieser Konstruktion stellt ein Server den aktiven Part (Active Node) und die weiteren Server den passiven Part (Passive Nodes) für die Exchange Dienste dar. Quittiert der Active Node den Dienst, kann der Passive Node dies anhand der untereinander im Netzwerk versandten Replikationsinformationen (Heartbeat) erkennen und die aktive Funktion übernehmen.

Diese damaligen Clusterkonstrukte benötigen dabei jedoch eine dedizierte Ablage für die Exchange-Datenbanken in Form eines zentralen Festplattenarrays. Jedem Mitglied des Exchange-Clusters muss der Zugriff auf die zentral gelagerten Datenbanken ermöglicht werden, damit dieser im Bedarfsfall die aktive Exchange-Funktion ausüben kann. Diese, aufgrund der aus Serverperspektive einzeln zentral existierenden Datenbanken als Single Copy Cluster bezeichneten Konstrukte, schützen in erster Instanz ausschließlich die Server und Exchange-Dienste vor einem Ausfall. Probleme mit den Exchange-Datenbanken oder den zentralen Festplatten müssen auf andere Weise und meist sehr aufwendig durch dedizierte Hard- und / oder Software kompensiert werden. Administratoren müssen sich in diesem Szenario also nicht nur Gedanken um die Konstellation und Position der eigentlichen Server machen, sondern auch an die Redundanz des Festplattenarrays und der Exchange Datenbanken denken. Sind darüber hinaus Cluster in diesem Bereich zunächst physisch rein lokale Konstrukte, kommt zunehmend auch der geographische Sicherheitsaspekt zum tragen. Die jeweiligen Server sollen räumlich in unterschiedlichen Rechenzentren bereitgestellt werden, was den Aufwand im Bezug auf die redundante Bereitstellung der Datenbanken ebenfalls deutlich erhöht.

Jedoch besitzt die Single Copy Cluster Bereitstellung einen ganz entscheidenden Vorteil: erkennt ein Passive Node den Ausfall eines Active Node, so registriert er dies zunächst durch die ausbleibenden Replikationsinformationen auf der Heartbeat-Netzwerkverbindung. Allerdings muss der Passive Node dabei in Betracht ziehen, dass es sich wirklich um den Ausfall des Active Node handeln kann oder lediglich die Netzwerkverbindung zum Active Node ausgefallen ist. Im letzteren Fall erfreut sich der Active Node noch bester Gesundheit und der Passive Node würde dennoch versuchen, die aktive Rolle zu übernehmen – ein sogenanntes Split Brain Szenario.

Als Schutzmechanismus verwendet der Cluster daher ein bestimmtes Abstimmung- oder Quorum-Modell, hier die Quorum-Disk: Auf dem gemeinsam im Zugriff verfügbaren Festplattenarray liegt eine durch den Cluster kontrollierte Quorum-Ressource. Diese wird durch den Active Node beansprucht und auch stets aktualisiert. Fällt einem Passive Node durch den Ausfall von Replikationsinformationen auf, dass der Active Node nicht verfügbar sein könnte, verifiziert er dieses Indiz durch die Kontrolle der Quorum-Disk. Hat der Active Node die Kontrolle über diese verloren, ist zusätzlich zum Indiz der ausgefallenen Replikationsverbindung nun auch der Beweis für den Active Node erbracht und der Passive Node übernimmt die aktive Rolle – ein Failover-Prozess findet statt.

Failover, Switchover und Failback
Ein Failover findet in der Regel automatisch statt, wenn der aktive Knoten im Cluster ausfällt. Ein passiver Knoten wird diesen Ausfall bemerken, ein Quorum bilden und die entsprechenden Aufnahmen übernehmen. Durch die zur Überprüfung  des Fehlerzustands notwendige Zeitspanne ergibt sich eine gewisse Failover-Latenz. Diese Latenz möchte man im administrativen Alltag vermeiden, indem man vor einem kontrollierten Beenden des aktiven Knotens die dort ausgeführten Aufgaben manuell an einen vorhanden passiven Knoten überträgt – ein sogenannter Switchover. Steht in Folge eines Fail- oder Switchovers der ehemalige aktive Knoten anschließend wieder zur Verfügung, bleiben zwei Möglichkeiten: die derzeit auf einem anderen Knoten ausgeführte Aufgabe verbleibt auf diesem oder sie wird auf den nun wieder verfügbaren Knoten zurück übertragen. Im letzten Fall spricht man von einem Failback.
…etwas moderner…

Die hardwareseitige Komplexität in der Bereitstellung solcher redundanten Konstrukte erschwerte jedoch den Aufbau geographisch verteilter Rechenzentren. Hier war nun nicht nur mehr die Redundanz einzelner lokaler Server gefragt, sondern die Möglichkeit den Ausfall einer ganzen Infrastruktur – beispielsweise durch einen lokalen Stromausfall – zu kompensieren. Mit dem Erscheinen von Exchange Server 2007 passt Microsoft das Redundanzverhalten daher in Form der Cluster Continuous Replication (CCR) an die neuen Anforderungen in diesem Bereich an.

Bei CCR handelt es sich im Kern um die Spiegelung der Informationen des Active Node auf den Passive Node, wobei diese Daten jeweils individuell und autark durch die jeweiligen Server verarbeitet werden. Durch die Einführung des seinerzeit neuen Rollenkonzepts konnte während der Installation eines Exchange Server 2007 dieser eine oder mehrere Funktionen in der Exchange Organisation übernehmen: die Postfach-, Hub Transport- und Clientzugriffsrolle in beliebiger Kombination oder – stets separat – die Edge Transportrolle. Im Hinblick auf eine redundante Bereitstellung der Exchange Postfachserverrolle durfte allerdings auch isoliert von den übrigen Funktionen entweder die aktive oder passive Postfachrolle bereitgestellt werden.  Dabei erhalten beide Rollen, sowohl der Active Node als auch der Passive Node jeweils eigene lokale Datenbanken und dazugehörige Transaktionsprotokolle. Eine zentrale Bereitstellung der Datenbanken und somit die Notwendigkeit eines gemeinsamen Festplattenarrays entfällt.

Die Funktionsweise der CCR wird maßgeblich durch das sogenannte Log Shipping realisiert. Dabei werden in den Datenbanken abzulegende Informationen nicht nur durch den Active Node verarbeitet, sondern auch an den Passive Node weitergeleitet. Somit findet gleichsam – nicht unbedingt gleichzeitig – die Verarbeitung dieser Information auf beiden Systemen statt. Einen guten Überblick zum diesem Thema gibt es im Microsoft Technet hier (Stand: September 2016)

Da CCR in diesem Zusammmenhang allerdings die Speicherkonstrukte Direct Attached Storage (DAS) oder Storage Area Networks (SAN) – also Festplatten die jeweils nur lokal durch den jeweiligen Server / Knoten verwaltet werden – benutzt und nicht wie in vorherigen Clusterkonstrukten Shared Storage verwendet, ergibt sich jedoch ein anderes Problem. Zur Vermeidung des Split Brain Szenarios steht in diesem Kontext keine gemeinsam genutzte Quorum-Disk zur Verfügung. Um ein Quorum bilden zu können, setzt Microsoft hier alternativ auf das Clusterkonzept des Majority Node Clusters. Dieser Hauptknotensatz-, oder besser Mehrheitsknotensatz-Cluster bildet das Quorum, indem ausschließlich die Mehrheit aller Knoten eine verbindliche Entscheidung treffen können. Existiert beispielsweise ein Majority Node Cluster mit vier Knoten, ist jeder dieser einzelnen Knoten mit einer Stimme stimmberechtigt. Fällt in einem solchen Cluster der Active Node aus, müssen nun mehrheitlich drei von vier Knoten dies attestieren. Erst dann darf einer der Passive Nodes die aktive Rolle übernehmen. Im Falle von Exchange Server 2007 stand ursprünglich jedoch ausschließlich ein Clusterkonstrukt mit maximal zwei Knoten zur Verfügung. Fällt der Active Node aus, kann der verbleibende Knoten keine Mehrheit bilden und dürfte demnach nicht aktiv werden. Mit dem Erscheinen von Service Pack 1 für Exchange Server 2007 hat Microsoft die Möglichkeiten hier noch ein wenig erweitert – dazu aber später mehr…

…und Redundanz aktuell

Mit der Veröffentlichung von Exchange Server 2010 hat Microsoft die Fehlertoleranz durch die Datenbankverfügbarkeitsgruppe oder im Original Database Availability Group (DAG) funktional deutlich erweitert – in den Grundzügen ähnelt dies allerdings der Funktion CCR in Exchange Server 2007.

In der Betrachtung von DAGs ist zunächst eine weitere Neuigkeit in Exchange Server 2010 sehr bedeutsam. Waren bisher Exchange Datenbanken dem jeweiligen Exchange Server direkt zu- und auch untergeordnet, finden sich diese nun auf Exchange Organisationsebene wieder und werden den nun untergeordneten Exchange Servern nur zugewiesen. Dazu hat sich Microsoft in der Version 2010 vom Konstrukt der Speichergruppen getrennt. In der Praxis konnte ein Exchange Administrator eine solche Speichergruppe erstellen und in dieser eine oder mehrere Datenbanken bereitstellen. Darüber hinaus – in Abhängigkeit der verwendeten Exchange Version – ließen sich pro Server auch mehrere Speichergruppen erstellen. Leistungstechnisch nachteilig zeigte sich dabei der Faktor, das alle Datenbanken innerhalb einer Speichergruppen nur durch ein einzelnes Transaktionsprotoll versorgt werden konnten. Unter Optimierungsaspekten schlägt Microsoft daher schon zu Zeiten von Exchange Server 2007 die Verwendung einer Speichergruppe für jeweils nur eine Datenbank vor. Seit Exchange Server 2010 bleibt nun keine Variationsmöglichkeit mehr: eine Exchange Datenbank wird auf Organisationsebene erstellt und dabei einem spezifischen Server zugewiesen. Dabei wird ihr individuell ein eigenes Transaktionsprotokoll zugeordnet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.