Exchange Fragen & AntwortenStandortflexibilität mit SCR, empfohlene Stammvolumegröße und mehr
Henrik Walther
F Ich entwerfe derzeit eine Exchange Server 2007-basierte Messaginginfrastruktur für ein großes Unternehmen, das eine Lösung mit Standortflexibilität erfordert. Deshalb erwäge ich, auf fortlaufender Clusterreplikation (cluster continuous replication, CCR) basierende Postfachserver auf Windows Server 2008-Failoverclustern mit dem aktiven Knoten im primären (aktiven) Datencenter und dem passiven Knoten im sekundären (Sicherungs-) Datencenter bereitzustellen.
Die Datencenter befinden sich in verschiedenen Subnetzen, gehören aber zum gleichen Active Directory-Standort, das heißt, dies ist ein unterstütztes Szenario beim Installieren der CCR-basierten Postfachserver unter Windows Server 2008. Würden Sie die Bereitstellung der CCR-basierten Postfachserver in einer Umgebung mit mehreren Subnetzen empfehlen?
A Es stimmt, dass dieses Szenario unterstützt wird, solange Sie den Active Directory-Standort zwischen den Datencentern ausdehnen, da Exchange 2007 die Bereitstellung der aktiven und passiven CCR-Knoten in verschiedenen Active Directory-Standorten nicht unterstützt. Dennoch ist es wichtig, daran zu denken, dass CCR wirklich für hohe Verfügbarkeit innerhalb eines Datencenters und nicht für Standortflexibilität entworfen wurde (die mehr mit der Notfallwiederherstellung zu tun hat als mit einer hohen Verfügbarkeit).
Aus diesem Grund hat die Exchange-Produktgruppe mit Exchange 2007 SP1 die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) eingeführt. SCR verwendet die gleiche Technologie für die Protokollsendung und -wiedergabe, die von CCR verwendet wird, aber SCR basiert im Unterschied zu CCR nicht auf der Failoverclusterfunktionalität von Windows. Dies bedeutet, dass Sie sowohl für gruppierte als auch für nicht gruppierte Postfachserver die Replikation auf ein SCR-Ziel ermöglichen können. Dieses Ziel kann aus einem nicht gruppierten Postfachserver oder einem Standbycluster, auf dem die passive Postfachserverrolle installiert wurde, bestehen.
Dies ist in Abbildung 1 dargestellt, die auch im Abschnitt über die fortlaufende Standbyreplikation in der Exchange 2007-Dokumentation zu finden ist.
Ich empfehle nicht, einen geografisch verteilten Cluster (Geo-Cluster) auf Grundlage von CCR zu implementieren, aber er wird, wie bereits erwähnt, vollständig von Microsoft unterstützt. Sie müssen jedoch die Nachteile bedenken, die dieser Ansatz hat.
Abbildung 1 Modell der fortlaufenden Standbyreplikation (zum Vergrößern auf das Bild klicken)
Als Erstes müssen Sie einen ausgedehnten Active Directory-Standort verwenden. Sie haben dies anscheinend bereits berücksichtigt, aber es soll hier für alle anderen Leser erwähnt werden, denen das nicht klar war. Als Nächstes muss Folgendes beachtet werden: Da sich die CCR-Knoten in verschiedenen Subnetzen befinden, wird der gruppierte Postfachserver (clustered Mailbox server, CMS) seine IP-Adresse während eines Failovers in den anderen Standort ändern. Diese Änderung muss auf alle DNS-Server repliziert werden, die von Microsoft Outlook-Clients verwendet werden, und – das ist genauso wichtig – alle Computer mit Outlook-Clients, die eine Verbindung zum CMS herstellen, müssen ihren DNS-Cache leeren.
Während dies erfolgt, werden die Outlook-Clients von den jeweiligen Postfächern auf dem CMS getrennt. Aus diesem Grund sollten Sie den Wert für die DNS-Gültigkeitsdauer (Time-to-Live, TTL) für die CMS-Netzwerknamenressource in fünf Minuten (300 Sekunden) oder weniger ändern. Weitere Informationen dazu finden Sie unter technet.microsoft.com/library/bb676687.aspx.
Sie müssen außerdem bedenken, wo Sie den Dateifreigabenzeugen (file share witness, FSW) platzieren wollen. Die Empfehlung lautet, den FSW auf einem Hubtransportserver zu erstellen, aber an welchem Standort? Wenn Sie es auf einem Hubtransportserver im primären Datencenter platzieren und das primäre Datencenter verloren geht, erfolgt dann ein automatisches Failover? Nein, das ist nicht möglich, wenn einer der CCR-Knoten und der FSW gleichzeitig ausgefallen sind. Andererseits ist es wahrscheinlich, dass viele es bevorzugen, wenn das Failover in einem Geo-CCR-Szenario nicht automatisch erfolgt. Lesen Sie unbedingt den Leitfaden zur Platzierung des FSW in einem Geo-CCR-Szenario.
Abschließend sollten Sie daran denken, dass bei einem Failover am passiven Knoten im Sicherungsdatencenter kein Abgleich seitens des Transportpapierkorbs auf den Hubtransportservern im primären Datencenter erfolgt, da diese Server höchstwahrscheinlich ausgefallen sind. Das bedeutet letzten Endes, dass E-Mails fehlen.
Wie Sie sehen können, gibt es viele Punkte, die Sie vor dem Bereitstellen einer Geo-CCR in Ihrer Umgebung bedenken müssen, viel mehr Punkte, als wenn Sie stattdessen beschließen, die fortlaufende Standbyreplikation für die Standortflexibilität zu verwenden.
F Unsere Organisation besteht aus mehreren physikalischen Standorten, die sich über die USA sowie Europa, den Nahen Osten und Afrika erstrecken. Heute werden alle Benutzerpostfächer auf Postfachservern gehostet, die an jedem physikalischen Standort lokal bereitgestellt werden, aber wir wollen diese Server zu einem Datencenter in den USA konsolidieren. Können Sie uns für diesen Plan die maximale Latenz für Outlook 2003/2007-Clients nennen, die im Cachemodus ausgeführt werden?
A Es ist gut zu hören, dass alle Ihre Clients aus Outlook 2003 oder 2007 bestehen und im Cachemodus ausgeführt werden, weil der Cachemodus bei Konsolidierungen wie der beschriebenen in der Regel eine große Hilfe ist.
In der Vergangenheit hat Microsoft für Outlook 2003-Clients im Cachemodus eine End-to-End-Latenz von 1.000 ms oder weniger zum Hauptpostfachserver empfohlen. Für nicht im Cachemodus befindliche Outlook 2003-Clients lautete die Empfehlung 200 ms oder weniger.
Aufgrund meiner persönlichen Erfahrung sind 1.000 ms sogar für Outlook 2007-Cachemodus-Clients etwas hoch. Bei mehr als 500 ms fängt Outlook an zu hängen und wird im Allgemeinen langsamer. Meine Empfehlung lautet, eine Latenz von weniger als 500 ms zwischen dem Outlook-Client und dem Hauptpostfachserver anzustreben. In Abbildung 2 können Sie die durchschnittliche Antwortzeit für meinen mit einem Postfach in Redmond verbundenen Outlook 2007-Client sehen.
Hier ein Tipp: Zum Öffnen des Verbindungsstatusfensters in Abbildung 2 können Sie mit der rechten Maustaste auf das Outlook-Symbol in der Taskleiste klicken, während Sie die STRG-Taste gedrückt halten. Alternativ können Sie Outlook starten, indem Sie auf „Start“ | „Ausführen“ klicken und „Outlook.exe /RPCDIAG“ eingeben.
Abbildung 2 Durchschnittliche Antwortzeit in Outlook 2007
Wenn Sie bedenken, dass ich mich in Dänemark befinde, sind die durchschnittlichen Antwortzeiten akzeptabel. Sie sehen, dass die durchschnittlichen Antwortzeiten des globalen Katalogservers deutlich höher sind, aber da diese seltener verwendet werden (für Suchvorgänge im Adressbuch usw.), macht das nicht viel aus.
F Wir haben kürzlich Exchange 2007 SP1 in unserer Organisation bereitgestellt. Die Active Directory-Topologie besteht aus zwei Standorten. Am ersten Standort haben wir einen CCR-basierten Postfachserver und zwei Server bereitgestellt, auf denen jeweils die Hubtransport- und die Clientzugriffs-Serverrolle installiert sind. Am zweiten Standort haben wir einen auf einem Einzelkopiecluster (single copy cluster, SCC) basierenden Postfachserver sowie, genauso wie am ersten Active Directory-Standort, zwei Server mit der Hubtransport- und der Clientzugriffs-Serverrolle bereitgestellt.
Die Mehrzahl der Clients an jedem Active Directory-Standort führt immer noch Outlook 2003 aus, d. h., für die Frei/Gebucht-Informationen und das Offlineadressbuch ist ein öffentlicher Ordnerspeicher erforderlich (öffentliche Ordner werden nur für diesen Zweck verwendet, nicht als Datenrepository). Unser anfänglicher Plan sah vor, einen öffentlichen Ordnerspeicher sowohl auf dem CCR-basierten als auch auf dem SCC-basierten Postfachserver bereitzustellen, damit Änderungen im öffentlichen Ordner zwischen den Active Directory-Standorten repliziert werden können. Aber dann haben wir gehört, dass Microsoft nicht empfiehlt, mehr als einen öffentlichen Ordnerspeicher in einer Exchange-Organisation einzurichten, wenn ein Ordner auf einem CCR-basierten Postfachserver gehostet wird, weil die Replikation öffentlicher Ordner und die CCR-Replikation zusammen nicht gut funktionieren.
Welche Vorgehensweise würden Sie uns in dieser Situation empfehlen? Wir wollen keinen Weg beschreiten, der von Microsoft nicht empfohlen wird. Aber wir wollen auch nicht, dass Outlook 2003-Clients an den einzelnen Active Directory-Standorten den öffentlichen Ordnerspeicher am anderen Active Directory-Standort kontaktieren.
A Das ist eine sehr gute Frage. Es ist richtig, dass die Replikation öffentlicher Ordner nicht mit der CCR-Replikation für einen öffentlichen Ordnerspeicher kombiniert werden sollte. (Einzelheiten dazu, warum Sie dies vermeiden sollten, finden Sie in meinem Artikel der Rubrik „Exchange Fragen & Antworten“ vom Januar 2009.) Da Sie die Funktionalität für öffentliche Ordner verwenden werden, um den Legacy-Outlook-Clients Frei/Gebucht-Suchvorgänge zum Herunterladen des Offlineadressbuchs (offline address book, OAB) zu ermöglichen, lautet meine Empfehlung, dass Sie die Postfachserverrolle auf einem der kombinierten Hubtransport- und Clientzugriffsserver an dem Active Directory-Standort installieren, an dem sich der CCR-basierte Postfachserver befindet. Verschieben Sie dann den Speicher für öffentliche Ordner vom CCR-basierten Postfachserver auf diesen Server.
Denken Sie jedoch daran, dass auf dem Server auch eine Postfachdatenbank ausgeführt werden muss, damit die Replikation öffentlicher Ordner richtig funktioniert. Das Verwenden der kombinierten Hubtransport- und Clientzugriffsserver für Frei/Gebucht-Suchvorgänge und das OAB stellt keine große Belastung des Geräts dar, und so gehen die meisten Exchange-Architekten in einem solchen Szenario vor.
F Wir planen derzeit das Speicherlayout für die Postfachserver, die Teil der Exchange 2007-Messagingumgebung sein werden, zu der wir innerhalb den nächsten sechs Monate wechseln möchten. Da unser Unternehmen aus Tausenden von Benutzern besteht, planen wir 48 Speichergruppen auf jedem Postfachserver, die allesamt auf der CCR-Technologie basieren werden.
Aufgrund der Anzahl der Speichergruppen werden wir selbstverständlich Bereitstellungspunkte verwenden. Da wir einen Bereitstellungspunkt für jede LUN auf jedem der CCR-basierten Postfachserver erstellen werden, interessiert uns, was die empfohlene Mindestgröße für die Ankerlaufwerke ist, auf denen die Bereitstellungspunkte erstellt werden.
A Im Knowledge Base-Artikel Konfigurieren von Datenträgerbereitstellungspunkten auf einem Servercluster unter Windows Server 2008 wird beschrieben, wie Sie Volumebereitstellungspunkte auf einem Servercluster unter Windows Server 2008 konfigurieren. Darin heißt es: Wenn das Stammvolume (Hostvolume), auch als die Anker-LUN bekannt, extensiv für Bereitstellungspunkte verwendet wird, muss es mindestens eine Größe von 5 MB haben. Aber die Empfehlung für Stammvolumes ist anders, wenn es um Exchange geht.
In Exchange 2007 sowie früheren Versionen von Exchange Server ist es eine bewährte Methode, ein Stammvolume zwischen 100 und 500 MB zu verwenden. Beim Ausführen von Exchange 2007 auf Windows Server 2003-basierten Servern können beim Erstellen einer neuen Datenbank Probleme auftreten, wenn das Stammvolume über weniger als 20 MB freien Speicherplatz verfügt. Weitere Informationen zu diesem spezifischen Problem finden Sie unter Nach dem Erstellen einer neuen Datenbank in Exchange Server 2007 wird Ereignis 104 protokolliert.
F Die Messaginginfrastruktur unserer Organisation basiert auf Exchange 2007 SP1. Alle Exchange 2007-Server befinden sich im gleichen Datencenter und basieren auf der CCR-Clustertechnologie, was zu einer lokalen Redundanz führt. Aber wir haben gerade ein zweites Datencenter eingerichtet, das als Sicherung dienen soll, falls unser primäres Datencenter einmal verloren gehen sollte.
Für Exchange möchten wir Standortflexibilität durch Bereitstellen eines Hubtransport-, eines Clientzugriff- und eines Postfachservers im Sicherungsdatencenter erreichen. Wir möchten dann eine fortlaufende Standbyreplikation von den CCR-basierten Postfachservern im primären Datencenter auf den Postfachserver im Sicherungsdatencenter ermöglichen. Bevor wir beginnen, die Exchange 2007-Server im Sicherungsdatencenter zu erstellen, haben wir eine Frage und hoffen, dass Sie sie beantworten können. Wir möchten wissen, ob es unterstützt wird, SCR zwischen SCR-Quellen, die aus CCR-basierten Postfachservern bestehen, und einem SCR-Ziel, das aus einem eigenständigen Postfachserver besteht, zu ermöglichen. Falls dies der Fall ist, würden Sie empfehlen, dass wir diesen Weg einschlagen?
A Die kurze Antwort ist ja, dies wird vollständig unterstützt. Die lange Antwort ist zwar auch ja, aber Sie müssen beachten, dass Sie den CMS, der sich auf den SCR-Quellservern befindet, nicht mit dem /RecoverCMS-Schalter wiederherstellen können. Sie können einen CMS nur dann mit dem /RecoverCMS-Schalter wiederherstellen, wenn das SCR-Ziel ein Windows Server 2003/2008-Failovercluster ist, auf dem nur die passive Postfachserverrolle installiert wurde.
Wenn Sie einen eigenständigen Postfachserver als SCR-Ziel bereitstellen, müssen Sie die Datenbanken mittels Datenbankportabilität wiederherstellen, und das ist ein Verfahren, das mühsamer ist als die RecoverCMS-Methode. Sie können den notwendigen Schritt in der Exchange 2007-Dokumentation im Artikel Fortlaufende Standbyreplikation: Datenbankportabilität finden. Wenn auf dem SCR-Ziel Windows Server 2003/2008 Enterprise Edition installiert ist, könnten Sie auch die Postfachserverrolle entfernen, einen Failovercluster bilden, die passive Postfachserverrolle auf einem der Failoverclusterknoten installieren und dann Ihren CMS wiederherstellen, indem Sie die RecoverCMS-Option verwenden.
Wenn Ihnen derzeit nur ein physikalischer Computer zur Verfügung steht, bald jedoch ein zusätzlicher Computer hinzukommt (sowie eine zusätzliche Lizenz für Windows Server 2003/2008 Enterprise Edition und Exchange Server 2007 Enterprise Edition), könnten Sie auch mit der Bildung eines Windows Server 2003/2008-Failoverclusters beginnen, der aus einem einzigen Knoten besteht, und dann die passive Postfachserverrolle auf diesem Knoten installieren. Wenn der zusätzliche Computer bereit ist, könnten Sie darauf Windows Server 2003/2008 installieren und die Netzwerkeinstellungen usw. konfigurieren und diese Einstellungen abschließend dem Windows-Failovercluster hinzufügen.
Henrik Walther ist Microsoft Certified Master: Exchange 2007 und MVP für Exchange mit mehr als 15 Jahren Erfahrung in der IT-Branche. Er arbeitet als Technologiearchitekt für Trifork Infrastructure Consulting (einen Gold Partner von Microsoft für Infrastruktur mit Sitz in Dänemark) sowie als Autor technischer Artikel für Biblioso Corporation (ein Unternehmen mit Sitz in den USA, das auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert ist).