Exchange Server 2010

Artikel
08/31/2016

Sicherstellen hoher Verfügbarkeit in Microsoft Exchange Server 2010

William R. Stanek

Exchange Server 2010-Features für hohe Verfügbarkeit
Detaillierte Untersuchung der Datenbankverfügbarkeitsgruppen

Postfachdatenbanken und die darin enthaltenen Daten sind für jede Exchange-Organisation äußerst wichtig. Um die hohe Verfügbarkeit von Postfachdatenbanken zu gewährleisten, bot Exchange 2007 verschiedene Replikations- und Clusterbildungsoptionen, darunter fortlaufende lokale Replikation, Einzelkopiecluster und Postfachclusterserver. Obwohl diese Features Verbesserungen gegenüber früheren Angeboten darstellten, warfen sie noch viele Implementierungsprobleme auf. Einfach gesagt: Jeder Ansatz zur Erreichung hoher Verfügbarkeit wurde auf andere Weise gehandhabt. Bei Einzelkopieclustern nutzten alle Postfachserver eines Clusters gemeinsam freigegebenen Speicher. Zur Implementierung der Clusterbildung mussten Exchange-Administratoren Windows-Failovercluster konfigurieren, was ziemlich kompliziert ist und den Administrator eine Menge Zeit kosten kann, bis er geringe Ausfallzeiten erreicht. Bei der fortlaufenden Replikation erstellte Exchange 2007 unter Verwendung der integrierten asynchronen Replikation Kopien der Daten und verwaltete die Kopien dann durch den Versand und die Wiedergabe von Transaktionsprotokollen. Die lokale fortlaufende Replikation wurde verwendet, um in einer Umgebung ohne Cluster lokale Kopien zu erstellen, in einer Clusterumgebung wurde dagegen die fortlaufende Clusterreplikation oder die fortlaufende Standbyreplikation verwendet, und jeder Typ von fortlaufender Replikation wurde anders verwaltet.

Exchange Server 2010 zeichnet sich durch einen völlig anderen Ansatz zur Erreichung hoher Verfügbarkeit aus, weil hohe Verfügbarkeit bereits in die Kernarchitektur integriert wurde. Daraus ergibt sich eine Komplettlösung, die Dienstverfügbarkeit, Datenverfügbarkeit und automatische Wiederherstellung bietet. Ergebnis ist, dass eine zentrale Hochverfügbarkeitslösung die vielen verschiedenen Lösungen ersetzt, die zuvor verwendet wurden. Diese Lösung heißt Database Availability Group (DAG).

DAG bieten automatische Failover- und Wiederherstellungsfunktionen auf der Datenbankebene (statt auf der Serverebene), ohne Cluster zu erfordern, wenn mehrere Postfachserver mit mehreren Kopien von Postfachdatenbanken bereitgestellt werden. Aufgrund dieser Änderungen sind zum Aufbau einer Postfachserverlösung mit hoher Verfügbarkeit weder Clusterhardware noch anspruchsvolle Clusterkonfigurationen erforderlich. Stattdessen bilden DAGs die Grundkomponente für hohe Verfügbarkeit, und für Postfachdatenbanken, die Teil derselben DAG sind, wird automatisch eine Failover durchgeführt. DAGs können auf mehrere Active Directory-Standorte ausgeweitet werden, und entsprechende architektonische Änderungen an den Postfachservern ermöglichen das Verschieben einer Postfachdatenbank zwischen Active Directory-Standorten. Deswegen kann eine Postfachdatenbank an einem Active Directory-Standort im Fehlerfall zu einem anderen Active Directory-Standort umgeschaltet werden.

Vergessen Sie aber nicht, dass die Datenbankkopien nur für Postfachdatenbanken erstellt werden. Zur Sicherung von Redundanz und hoher Verfügbarkeit der Datenbanken für öffentliche Ordner verwenden Sie die Replikation öffentlicher Ordner. Im Gegensatz zur fortlaufenden Clusterreplikation, bei der ein Cluster nicht mehrere Kopien einer Datenbank für öffentliche Ordner enthalten kann, können Datenbanken mit öffentlichen Ordnern zwischen Servern einer DAG repliziert werden.

Bevor ich mich eingehend mit den DAGs befasse, sehen wir uns an, in welcher Weise andere Optionen für die hohe Verfügbarkeit in Exchange 2010 verändert wurden.

Exchange Server 2010-Features für hohe Verfügbarkeit im Schnelldurchlauf

In Vorgängerversionen war Exchange eine Clusteranwendung, die das Clusterressourcenverwaltungsmodell verwendete. Bei diesem Ansatz wurde hohe Verfügbarkeit für Postfachserver implementiert, indem zuerst ein Windows-Failovercluster erstellt und anschließend Exchange im Clustermodus eingerichtet wurde. Im Rahmen des Installationsvorgangs wurde die Clusterressourcen-DLL von Exchange (exres.dll) registriert, wodurch die Erstellung von in Clustern gruppierten Postfachservern ermöglicht wurde. Im Gegensatz dazu wird Exchange 2010 nicht mehr als Clusteranwendung ausgeführt und das Clusterressourcenverwaltungsmodell nicht mehr zur Gewährleistung hoher Verfügbarkeit verwendet. Die Clusterressourcen-DLL von Exchange und die von ihr bereitgestellten Clusterressourcen gibt es nicht mehr. Stattdessen verwendet Exchange 2010 ein eigenes internes Modell zur Gewährleistung hoher Verfügbarkeit. Obwohl einige Komponenten der Windows-Failoverclusterbildung auch in diesem Modell zum Einsatz kommen, werden diese jetzt ausschließlich von Exchange 2010 verwaltet.

Interessanterweise werden viele der zugrunde liegenden Replikationstechnologien beibehalten. Sie sind einfach weiterentwickelt worden und zeigen jetzt ein deutlich anderes Verhalten. Weil Speichergruppen aus Exchange 2010 entfernt wurden, wird die fortlaufende Replikation auf der Datenbankebene ausgeführt. Statt der Verwendung von SMB (Server Message Block) für Protokollversand und Seeding wird in Exchange 2010 ein einzelner vom Administrator definierter TCP-Port für den Datenaustausch verwendet. Hier müssen nicht passive Kopien geschlossene Protokolldatei von der aktiven Kopie abrufen, sondern die aktive Kopie sendet Protokolldateien an die passiven Kopien, und der Datenstrom wird durch Verschlüsselung oder Komprimierung gesichert, um die Größe der replizierten Daten zu verringern. In früheren Exchange-Versionen konnte die aktive Kopie einer Datenbank nur für das Seeding und das Reseeding verwendet werden, in Exchange Server 2010 können dagegen sowohl aktive als auch passive Kopien der Postfachdatenbanken als Quelle für das Seeding und das Reseeding angegeben werden. Dadurch ist es einfacher, eine Kopie der Datenbank einem anderen Postfachdatenbankserver hinzuzufügen.

Eine weitere deutliche Änderung hat mit der Art und Weise zu tun, wie Daten repliziert werden. In Exchange 2007 gab der Microsoft Exchange-Replikationsdienst Protokolle in den passiven Datenbankkopien wieder und erstellte einen Zwischenspeicher von Lese-/Schreibvorgängen, der zur Verringerung der Anzahl von E/A-Lesevorgängen genutzt wurde. Sobald die passive Kopie der Datenbank aktiviert wurde, ging der Datenbankzwischenspeicher allerdings verloren, da er dem Microsoft Exchange-Informationsspeicherdienst, der die Datenbank bereitstellte, nicht zur Verfügung stand. Das bedeutete, dass die passive Kopie in einem Ausgangszustand ohne einsatzbereiten Zwischenspeicher aktiviert und verfügbar gemacht wurde. Ein Ausgangszustand ist derselbe Zustand, in dem sich der Datenbankzwischenspeicher nach einem Neustart des Servers bzw. dem Neustart der Dienste, welche die Zwischenspeicherung durchführen, befindet. Dies bedeutete, dass dem Server keine zwischengespeicherten Lese-/Schreibvorgängen zur Verfügung standen. Dieser Umstand hatte in der Regel eine höhere Anzahl von E/A-Lesevorgängen zur Folge, die erforderlich waren, bis der Zwischenspeicher eine ausreichende Größe erreicht hatte, bei der weniger Datenträger-E/A-Vorgänge auf dem Server ausgeführt werden mussten. In Exchange 2010 ist der Microsoft Exchange-Informationsspeicherdienst für die Wiedergabe der Protokolle und die Bereitstellungsvorgänge zuständig, womit sichergestellt wird, dass der Zwischenspeicher verfügbar ist, wenn eine passive Kopie aktiviert und verfügbar gemacht wird. Deswegen kann der Server wahrscheinlich eher den Zwischenspeicher nutzen, um nach einem Wechsel oder Failover die Anzahl von E/A-Lesevorgängen zu reduzieren.

Bei Postfachservern mit hoher Verfügbarkeit sind E-Mail-Nachrichten sicher, sobald sie ein Postfach erreichen. Der Schutz der E-Mail-Nachrichten während der Übertragung ist jedoch eine andere Sache. Wenn ein Hub-Transport-Server während der Verarbeitung von Nachrichten ausfällt und nicht wiederhergestellt werden kann, können Nachrichten verloren gehen. Als Schutzmechanismus gegen Datenverluste wurde in Exchange 2007 der Transportpapierkorb eingeführt, der sicherstellte, dass die Hub-Transport-Server eine Warteschlange mit Nachrichten verwalteten, die Empfängern zugestellt wurden, deren Postfächer durch fortlaufende lokale Replikation oder fortlaufende Clusterreplikation geschützt wurden. Die Nachrichten wurden so lange im Transportpapierkorb aufbewahrt, bis eine vom Administrator definierte Zeitspanne verstrichen war oder eine Größenbeschränkung erreicht wurde. Im Failoverfall forderten die in Clustern gruppierten Postfachserver automatisch von jedem Hub-Transport-Server des Active Directory-Standorts die erneute Übermittlung der im Transportpapierkorb enthaltenen Post an. Mit diesem Ansatz wurde verhindert, dass Post während des für das Clusterfailover erforderlichen Zeitraums verloren ging. Dieser Ansatz funktioniert zwar, er ist jedoch nur für die Nachrichtenzustellung in einer Umgebung mit fortlaufender Replikation verfügbar und geht nicht auf mögliche Datenverluste während der Übermittlung von Nachrichten zwischen Hub-Transport- und Edge-Transport-Server ein.

In Exchange 2010 wird auf verschiedene Weise auf diese Mängel eingegangen. Der Transportpapierkorb erhält jetzt Feedback, um ermitteln zu können, welche Nachrichten zugestellt und repliziert wurden. Die Hub-Transport-Server speichern eine Kopie der Nachrichten, die an eine replizierte Postfachdatenbank in einer DAG gesendet werden. Die Kopie wird in der Transportwarteschlange (mail.que) aufbewahrt, bis der Hub-Transport-Server darüber benachrichtigt wurde, dass das Transaktionsprotokoll, welches die Nachricht repräsentiert, erfolgreich repliziert wurde und von allen Kopien der Postfachdatenbank inspiziert wurde. Dann werden die Protokolle aus dem Transportpapierkorb verkürzt, womit sichergestellt wird, dass in der Transportpapierkorb-Warteschlange nur Kopien von Nachrichten aufbewahrt werden, die noch nicht repliziert wurden. Wenn eine Postfachdatenbank eines Active Directory-Standorts bei einem Ausfall zu einem anderen Active Directory-Standort umgeschaltet wird, werden überdies Anforderungen nach einer erneuten Zustellung des Transportpapierkorbs sowohl an den ursprünglichen Standort als auch an den neuen Standort gesendet.

Um während der gesamten Übertragung Nachrichtenredundanz bereitzustellen, wurde Exchange 2010 um Schattenredundanz ergänzt. Mit der Schattenredundanz wird ein ähnlicher Ansatz wie beim Transportpapierkorb verfolgt, nur wird hier mit dem Löschen der Nachrichten aus der Transportdatenbank gewartet, bis der Transport-Server bestätigt, dass die Nachrichtenübermittlung von allen nachfolgenden Stationen abgeschlossen wurde. Wenn der Transport-Server die Übermittlung an die nächste Station nicht verifizieren kann, wird die Nachricht erneut zur nächsten Station geschickt. Dieser Ansatz erfordert weniger Netzwerkbandbreite als das Erstellen doppelter Nachrichtenkopien auf mehreren Servern. Hier bilden die zwischen den Transport-Servern ausgetauschten Statusmeldungen über das Verwerfen von Nachrichten den einzigen Netzwerkdatenverkehr, der zusätzlich generiert wird. Diese Statusmeldungen werden vom Schattenredundanz-Manager erzeugt. Sie geben an, wann eine E-Mail-Nachricht aus der Transportdatenbank gelöscht werden kann.

Die Schattenredundanz ist eine Erweiterung des SMTP-Diensts (Simple Mail Transfer Protocol). Sie wird stets verwendet, wenn beide Server in einer SMTP-Verbindung das Feature unterstützen. Sind in einer Routingtopologie redundante Nachrichtenpfade gegeben, werden Transport-Server durch die Schattenredundanz entbehrlich, weil die Übermittlung nicht mehr auf dem Status eines bestimmten Hub- oder Edge-Transport-Servers beruht. Wenn in diesem Fall ein Transport-Server ausfällt oder wenn Sie einen Transport-Server zur Wartung offline schalten möchten, können Sie dies jederzeit tun, indem Sie den Server entfernen, ersetzen oder aktualisieren, ohne dessen Warteschlange leeren oder sich Gedanken machen zu müssen, ob Nachrichten verloren gehen.

Der Schattenredundanz-Manager ermittelt unter Verwendung eines Taktsignals, ob die Server verfügbar sind, für die Schattennachrichten in Warteschlangen verwaltet werden. Der Ausgangsserver gibt eine XQUERYDISCARD-Nachricht aus, und der Zielserver reagiert darauf, indem er Benachrichtigungen über das Verwerfen zurückgibt. Dieser Austausch von Benachrichtigungen bildet das Taktsignal.

Wenn ein Server innerhalb des Taktintervalls, das in der Standardeinstellung 300 ms beträgt, keine Verbindung mit einem primären Server herstellen kann, setzt der Server den Zeitgeber zurück und versucht es bis zu drei Mal (der Standardwert für die Anzahl von Wiederholversuchen) erneut. Wenn der primäre Server nicht geantwortet hat, nachdem die zulässige Anzahl von Wiederholversuchen erreicht wurde, stellt der Server fest, dass der primäre Server ausgefallen ist, übernimmt die Verantwortung für die Schattennachrichten und sendet sie erneut. Die Nachrichten werden dann die jeweiligen Empfänger übermittelt. In einigen Szenarien, beispielsweise wenn der ursprüngliche Server mit der Originaldatenbank wieder verfügbar wird, können Nachrichten doppelt zugestellt werden. Weil Exchange über eine Funktion zum Erkennen doppelter Nachrichten verfügt, nehmen die Benutzer von Exchange-Postfächern keine doppelten Nachrichten wahr. Allerdings können Empfänger mit Servern, die keine Exchange-Postfachsserver sind, doppelte Nachrichten erhalten.

Einzelheiten zu DAG

Obwohl viele der bislang beschriebenen Verbesserungen zur Gewährleistung hoher Verfügbarkeit wichtig sind, wirkt sich keines dieser Features so stark auf die Art und Weise aus, wie Exchange 2010 verwaltet wird, wie die Data Availability Groups (DAGs). DAGs sind die Grundkomponenten hoher Verfügbarkeit in Exchange 2010. Die für DAGs gültigen Regeln sind einfach. Jede DAG kann bis zu 16 Postfachserver als Mitglieder besitzen. Jeder Postfachserver kann nur Mitglied genau einer DAG sein und nur eine Datenbankkopie hosten. Bei der gehosteten Kopie kann es sich um eine aktive oder eine passive Kopie handeln. Eine aktive Kopie unterscheidet sich von einer passiven Kopie dadurch, dass sie verwendet wird und Benutzer darauf zugreifen. Eine passive Kopie ist offline. Auf einem Server können nicht zwei Kopien derselben Datenbank erstellt werden. Folglich kann jeder Server einer DAG eine Kopie einer beliebigen Postfachdatenbank eines anderen Servers der DAG hosten. Obwohl mehrere Datenbanken gleichzeitig aktiv sein können, kann zu einem gegebenen Zeitpunkt nur eine Kopie einer bestimmten Datenbank aktiv sein, und bis zu 15 passive Kopien dieser Datenbank können sich auf anderen Servern innerhalb der DAG befinden.

Wenn die erste DAG in einer Exchange-Organisation definiert wird, erstellt Exchange ein Windows-Failovercluster, das aber keine Clustergruppen für Exchange und keine Speicherressourcen enthält. Die DAG verwendet lediglich die Clustertaktverbindung, Clusternetzwerke und die Clusterdatenbankfeatures der Windows-Failovercluster. Anhand der Clustertaktverbindung werden Ausfälle erkannt. Jede DAG benötigt mindestens ein Netzwerk für den Austausch von Replikationsdaten und mindestens ein Netzwerk für den MAPI- und anderen Datenverkehr. In der Clusterdatenbank werden Zustandsänderungen und andere wichtige Änderungen gespeichert. Beim Hinzufügen weiterer Server zu einer DAG werden die Server mit dem zugrunde liegenden Cluster verknüpft und das Quorummodell des Clusters wird bei Bedarf automatisch der Anzahl von Mitgliedsservern entsprechend verändert.

Active Manager ist die Exchange 2010-Komponente, die das Ressourcenmodell und die Failoververwaltung bereitstellt. Active Manager wird auf allen Postfachservern ausgeführt, die Mitglieder einer DAG sind, und fungiert entweder als Inhaber der primären Rolle (Primary Active Manager) oder als sekundärer Standby-Rollenhalter (Standby Active Manager) für eine bestimmte Datenbank. Der primäre Active Manager entscheidet, welche Datenbankkopien aktiv sein sollen und welche Kopien aktiviert werden müssen. Der primäre Active Manager empfängt Benachrichtigungen über Topologieänderungen und reagiert auf Serverausfälle. Er ist auch für die Clusterquorumressource zuständig. Wenn der primäre Server ausfällt, wird die primäre Rolle automatisch einem anderen Server der DAG übertragen und dieser Server wird dann Besitzer der Clusterquorumressource.

Der sekundäre Active Manager erkennt Ausfälle replizierter, lokaler Datenbanken und des lokalen Informationsspeichers. Er sendet Failoverbenachrichtigungen an den primären Active Manager, in denen dieser aufgefordert wird, einen Failovervorgang einzuleiten. Der sekundäre Active Manager bestimmt nicht, welcher Server übernimmt, und er aktualisiert auch nicht die Standortangabe der lokalen Datenbank. Der primäre Active Manager erledigt diese Aufgaben. Wenn eine aktive Datenbank ausfällt, wählt der Active Manager mithilfe eines Algorithmus zur Auswahl der besten Kopie die zu aktivierende Datenbankkopie aus. Dieser Algorithmus identifiziert anhand des Datenbankstatus, des Status des Inhaltsindex, der Länge der Kopierwarteschlange und der Länge der Wiedergabewarteschlange der Datenbankkopie diejenige Datenbankkopie, die sich am besten für die Aktivierung eignet. Falls mehrere Datenbankkopien die Auswahlkriterien erfüllen, wird die Aktivierungseinstellung herangezogen und die Datenbank mit dem niedrigsten Einstellungswert wird aktiviert und bereitgestellt.

Nachdem einer DAG Server hinzugefügt wurden, kann die aktive Datenbank eines jeden Mitgliedsservers auf anderen Servern der DAG repliziert werden. Außerdem können andere DAG-Eigenschaften konfiguriert werden, z. B. Netzwerkverschlüsselung oder Netzwerkkomprimierung für die Datenbankreplikation. In einer DAG werden die Transaktionsprotokolle auf jedem Mitgliedsserver repliziert, der über eine Kopie der Postfachdatenbank verfügt, und in der Kopie der Postfachdatenbank wiedergegeben. Sobald Sie mehrere Datenbankkopien erstellt haben, können Sie mit der Exchange-Verwaltungskonsole und Exchange-Verwaltungsshell die Replikation und den Integritätsstatus der DAGs überwachen. Ein Datenbankfailover kann im Fehlerfall automatisch ausgeführt werden. Sie können aber auch manuell eine Umschaltung einleiten. Bei einer Umschaltung wird die Bereitstellung der aktiven Kopie aufgehoben und eine passive Kopie auf einem anderen Server der DAG bereitgestellt und aktiviert.

Echte Vereinfachung

Wie ich in diesem Artikel erläutert habe, verfügt Exchange 2010 über viele wichtige Verbesserungen, welche die Verfügbarkeit erhöhen. Hierzu gehören die Einbindung von Features für hohe Verfügbarkeit in die Kernfunktionalität sowie Architekturänderungen, die die Verfügbarkeit erhöhen usw. DAGs sind mein Liebling unter allen neuen und veränderten Features. DAGs vereinfachen Clusterimplementierungen wirklich, sodass Sie sich auf das konzentrieren können, was am meisten zählt – die Daten. Ich hoffe, Sie finden diesen Artikel hilfreich und sehen sich eines meiner neuen Bücher an: "Exchange Server 2010 Administrator's Pocket Consultant", "Windows 7 Administrator's Pocket Consultant" und "Windows Server 2008 Administrator's Pocket Consultant, 2nd Edition".

William R. Stanek (williamstanek.com) ist ein führender Technologieexperte, ein sehr guter Schulungsleiter und der preisgekrönte Autor von mehr als 100 Büchern. Folgende Bücher von ihm sind aktuell bzw. in Kürze auf dem Markt "Active Directory Administrator's Pocket Consultant", "Group Policy Administrator's Pocket Consultant", "Windows 7 Administrator's Pocket Consultant" (Windows 7 – Taschenratgeber für Administratoren), "Exchange Server 2010 Administrator’s Pocket Consultant" und "Windows Server 2008 Inside Out". Folgen Sie Stanek auf Twitter unter https://twitter.com/WilliamStanek.