Microsoft Exchange Server 2010: Hochverfügbarkeitsstrategien
Die Strategien, die Microsoft bietet für die Erstellung von hoch verfügbaren Microsoft Exchange-Postfächer haben sich im Laufe der Jahre entwickelt.
Auszug aus "Exchange 2010 – A Practical Approach," von Red Gate Books (2009) veröffentlicht.
Jaap Wesselius
Seit Exchange Server 5.5 hat Microsoft Windows Clustering als Option zum Erstellen einer Exchange-Postfach-Umgebung mit hoher Verfügbarkeit angeboten. Es gibt zwei Serverknoten in einer typischen freigegebenen Speicher-Cluster-Umgebung. Sowohl Exchange Server ausführen, und beide Server mit einer freigegebenen Speicher-Lösung verbunden sind.
In den frühen Tagen wurde diese freigegebene Speicher auf einem freigegebenen SCSI-Bus gebaut. Später benutzte es in der Regel Storage Area Networks (San) mit einer Fibre-Channel oder iSCSI-Netzwerkverbindung. Der wichtige Teil war den freigegebenen Speicher wo befanden sich die Exchange Server-Datenbanken.
Nur ein Server-Knoten ist der "Besitzer" dieser freigegebenen Daten. Dieser Knoten stellt die Clientdienste. Es ist auch bekannt als der aktive Knoten. Der andere Knoten nicht in der Lage, auf diese Daten zugreifen, und deshalb den passiven Knoten. Ein privates Netzwerk zwischen den zwei Serverknoten wird für interne Clusterkommunikation, z. B. ein Taktsignal verwendet. Auf diese Weise können beide Knoten bestimmen den Clusterstatus und sicherzustellen, dass die anderen Knoten noch am Leben sind.
Neben den beiden Knoten schafft es "Virtueller Exchange-Server" als Clusterressource. Das hat nichts mit virtuellen Maschinen zu tun. Dies ist die Ressource, auf die Outlook-Clients eine Verbindung herstellen, um auf ihre Postfächer zugreifen. Wenn der aktive Knoten ausfällt, übernimmt der passive Knoten die virtuellen Exchange-Server, die dann weiter ausgeführt. Obwohl Benutzer eine kurze Ausfallzeiten während des Failovers bemerken, ist es eine sonst nahtlose Erfahrung. Es ist keine Handlung des Benutzers erforderlich.
Obwohl diese Lösung Redundanz bietet, gibt es noch ein Einzelpunkt-Versagen — der freigegebenen Datenbank des Exchange-Servers. In einer typischen Umgebung wird diese Datenbank auf einem SAN gespeichert. Ein SAN ist naturgemäß eine hochverfügbare Umgebung. Wenn etwas an der Datenbank geschieht, ist jedoch z. B. einen logischen Fehler, die Datenbank für beide Knoten nicht verfügbar. Dies führt insgesamt Nichtverfügbarkeit.
Exchange-Datenbank-Replikation
Mit Exchange Server 2007 bietet Microsoft eine neue Lösung für die Erstellung hoch verfügbarer Exchange-Umgebungen: Datenbank-Replikation. Datenbank-Replikation erstellt eine Kopie einer Datenbank, wodurch Redundanz-Datenbank. Diese Technologie wurde in drei Geschmacksrichtungen:
- **Lokale fortlaufende Replikation (LCR):**Dieser Ansatz erstellt eine Kopie der Datenbank auf demselben Server.
- **Cluster fortlaufende Replikation (CCR):**Dies erstellt eine Kopie der Datenbank auf einem anderen Knoten in einem Windows-Failovercluster (kann nur werden zwei Knoten in einem CCR-Cluster).
- **Fortlaufende Standbyreplikation (SCR):**Dies kam mit Exchange Server 2007 SP1. Es erstellt eine Kopie einer Datenbank auf einem anderen Exchange-Server (nicht unbedingt im Cluster). Dies ist nicht gedacht für Hochverfügbarkeit (HA); Es ist eher für Disaster Recovery.
Dies ist die Funktionsweise der Datenbankreplikation in einem CCR-Cluster-Umgebung. Exchange Server 2007 wird auf einem Windows Server 2003 oder Windows Server 2008-Failovercluster installiert. Es wird keine freigegebener Speicher innerhalb des Clusters. Jeder Knoten hat seinen eigenen Speicher. Dies kann entweder auf einem SAN (Fibre Channel oder iSCSI) oder Direct attached Storage (DAS) — lokalen physischen Datenträgern.
Der aktive Knoten im Cluster Services-Client-Anforderungen und Exchange Server verwendet die standard-Datenbank-Technologie mit einer Datenbank, Protokolldateien und einer Prüfpunktdatei. Wenn Exchange Server eine Log-Datei abgeschlossen ist, wird es sofort auf passiven Knoten des Clusters gesendet. Dies kann entweder über eine normale Netzwerkverbindung oder über ein Replikationsnetzwerk von engagierten sein.
Der passive Knoten erhält die Log-Datei und auf Fehler überprüft. Wenn keiner gefunden wird, werden die Daten in der Protokolldatei auf die passive Kopie der Datenbank weitergeleitet. Dies ist ein asynchroner Prozess, was bedeutet, dass die passive Kopie ist immer ein paar der Protokolldateien hinter der aktiven Kopie, so dass Informationen "" in die passive Kopie fehlt.
In diesem Umfeld, alle Nachrichten — sogar interne Nachrichten — über einen Hub-Transport-Server gesendet werden. Der Hub-Transport-Server von protokolliert diese Meldungen in einer CCR-Umgebung. Es kann daher fehlende senden Informationen (die passive Knoten tatsächlich anfordert) auf die passive Kopie des Clusters bei einem Clusterfailover. Dies nennt man "Transportpapierkorb" in einem Hub-Transport-Server.
Diese Art von Replikation funktioniert sehr gut. CCR Replikation ist recht zuverlässig, aber es gibt ein paar mögliche Nachteile:
- Eine Exchange Server 2007-CCR-Umgebung läuft auf Windows Server 2003 oder Windows Server 2008 clustering. Für viele wird um die Umwelt zu viel Komplexität erhöht.
- Windows Server 2003-Cluster in einer Umgebung mit mehreren Subnetzen ist beinahe unmöglich, obwohl dies verbessert hat (aber noch nicht perfekt) in Windows Server 2008-Failover-Clusterunterstützung.
- Standortsicherheit nicht nahtlos.
- CCR-Cluster ist nur möglich in einer Umgebung mit zwei Knoten.
- Alle drei Arten von Replikation (LCR, CCR und SCR) sind anders verwaltet.
Um diese Probleme zu überwinden, verbessert Microsoft dramatisch die Technologie für die Replikation. Es reduziert auch den Verwaltungsaufwand. Es erreicht dies durch völlig ausblenden die Clusterkomponenten hinter die Implementierung von Exchange Server 2010. Die Clusterkomponenten sind immer noch da, aber die Administration erfolgt vollständig mit der Exchange Management Console (EMC) oder die Exchange Management Shell (EMS).
DAG-Replikation
In Exchange Server 2010 Microsoft das Konzept einer Database Availability Group (DAG) eingeführt. Dies ist eine logische Einheit von Exchange Server 2010-Postfachservern. Alle Postfach-Server in einer DAG können Datenbanken miteinander replizieren. Eine einzelne DAG kann bis 16-Mailbox-Server und bis zu 16 Kopien einer Datenbank aufnehmen.
Die Idee, mehrere Datenbankkopien in einer Exchange-Organisation wird Exchange Mobility genannt. Eine Datenbank ist auf mehreren Servern, jede, die Instanz davon ist zu 100 Prozent identisch und hat somit die gleiche GUID vorhanden.
Verbinden von Clients mit einer DAG vorhanden mit einer aktiven Datenbank. Dies ist die Datenbank, in dem alle Daten ursprünglich gespeichert war. Neue SMTP-Nachrichten, die entweder von außerhalb oder innerhalb der Organisation, werden zuerst in dieser Datenbank gespeichert.
Wenn der Exchange-Server Verarbeitung von Informationen in der Datenbank-Log-Datei abgeschlossen ist, wird die Datei auf anderen Servern repliziert. Sie können die Server zuweisen, die eine Kopie der Datenbank zu erhalten. Die Protokolldatei wird nach Erhalt überprüft und wenn alles in Ordnung ist, wird die Informationen in der Protokolldatei in der lokalen Kopie der Datenbank gelöscht.
Exchange Server 2010, alle Clients zum Herstellen der Clientzugriffsserver, einschließlich alle Messaging Application Programming Interface oder MAPI-Clients wie Microsoft Outlook Unterstützte Outlook-Clients in Exchange Server 2010 Gehören Outlook 2003, Outlook 2007 und Outlook 2010.
Also verbindet den Outlook-Client auf dem Clientzugriffsserver, der dann mit dem Postfach in der aktiven Kopie der Datenbank verbindet. Leider gilt dies nur für Postfachdatenbanken. Wenn ein Outlook-Client eine öffentliche Ordner-Datenbank zugreifen muss, greift der Client noch den Postfachserver direkt.
Wenn die aktive Kopie einer Datenbank oder einem Server fehlschlägt, wird eine der passiven Kopien der Datenbank aktiv. Sie können die Failover-Reihenfolge beim Kopiervorgang Konfiguration Datenbank konfigurieren. Der Clientzugriffsserver bemerkt das Failover automatisch und beginnt mit die neue aktive Datenbank. Da der Outlook-Client auf dem Clientzugriffsserver und nicht direkt mit der Datenbank verbunden ist, ist ein Datenbankfailover vollständig transparent. Nachrichten nicht wie "die Verbindung zum Server verloren" und, "die Verbindung zum Server wiederhergestellt ist," einfach nicht mehr angezeigt.
Beim Erstellen einer hochverfügbaren Postfach-Server-Umgebung in einer DAG gibt es keine Notwendigkeit, einen Failovercluster im Voraus zu bauen. Sie können zusätzliche Postfachservern der DAG dynamisch hinzufügen. Jedoch verwenden Sie für die DAG ordnungsgemäß funktionieren, noch einige Failover-Clusterunterstützung Komponenten. Diese sind während der DAG-Konfiguration installiert. Sie tun alle DAG und Datenbank-Kopie-Management über die Exchange-Verwaltungskonsole oder der EMS. Sie müssen nicht mehr auf den Windows-Cluster-Manager verwenden.
Die DAG mit Datenbankkopien ist die einzige HA-Technologie, die Exchange Server 2010 verwendet. Ältere Technologien wie SCR, CCR und SCR sind nicht mehr verfügbar. Der herkömmliche Single Copy Cluster mit gemeinsam genutztem Speicher ist entweder nicht mehr unterstützt.
Konfigurieren einer DAG beschränkt sich nicht mehr an einen Server halten nur die Serverfunktion Mailbox. Es ist möglich, schafft eine Situation, zwei Server mit der Hub-Transport, ClientAccess und Mailbox-Serverfunktionen auf beiden Servern, DAG erstellen und Konfigurieren von Datenbankkopien.
Jedoch ist es kein HA-Konfiguration für die Client-Zugriff oder Hub-Transport-Server, sofern Sie Load-balancer vor ihnen gestellt haben. In Kombination der Standard Windows-Netzwerklastenausgleich können nicht mit den Failover Cluster Komponenten. Dennoch ist dies eine große Verbesserung für kleinere Bereitstellungen von Exchange Server 2010, HA noch erforderlich ist.
.jpg)
Jaap Wesselius ist der Gründer der DM-Berater, ein Unternehmen mit einem starken Fokus auf Messaging- und Collaboration-Lösungen. Wesselius beschlossen, nach acht Jahren bei Microsoft tätig, mehr von seiner Zeit in die Exchange-Gemeinschaft in den Niederlanden, was zu einem Exchange Server MVP-Auszeichnung in 2007 zu begehen. Außerdem ist er regelmäßig bei der niederländischen Unified Communications-Benutzergruppe und regelmäßiger Autor für Simple-Talk.
Erfahren Sie mehr über "Exchange 2010 – A Practical Approach" bei red-gate.com/our-company/about/book-store.