Exchange 2007 - Cluster Continuous Replication

Diese Funktion ist mit Exchange 2010 nicht mehr verfügbar ! Siehe Database Availability Groups

Wichtige Quellen zu SP1
How to Upgrade a Clustered Mailbox Server in a CCR Environment to Exchange 2007 SP1
http://technet.microsoft.com/en-us/library/bb676320.aspx
Video: Upgrading Exchange 2007 CCR to Exchange 2007 SP1
http://msexchangeteam.com/videos/9/drandha/entry447645.aspx

Wichtiges Update für Cluster Failoverzeiten Exchange 2007SP1 Rollup 2
948332 Failover takes a long time to finish in an Exchange Server 2007 cluster continuous replication environment

Wichtiges Rollup5 für CCR auf Windows 2008 mit OAB Generierung
954197 Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters

Empfehlung.
Lesen Sie auch die Seite CCR Failover mit Details zum Failover, Failback und Überwachung.

Wer bisher schon mit einem Exchangecluster geliebäugelt hat, wird dabei sicher auch die offensichtlichen Probleme erkannt haben: Der normale Exchange Cluster ist ein "Shared Disk"-Cluster, d.h. die Datenbank liegt auf einem gemeinsamen Massenspeicher, auf den der aktive Knoten zugreift. Fällt dieser Knoten aus, dann übernimmt ein anderer Knoten die Arbeit auf den gleichen Datenbanken. Fällt jedoch die Datenbank aus, dann kann kein Knoten die Arbeit übernehmen. (Siehe auch Ausfallszenarien auf Hochverfügbarkeit).

Mit CCR kann nun in Verbindung mit dem Microsoft Cluster Dienst ein "Shared Nothing" Cluster aufgebaut werden. Sie benötigen zwar weiterhin einen Microsoft Cluster, damit die Umschaltung gesteuert wird, aber der aktive Knoten hat die Daten auf einer lokalen Festplatte und legt die Kopie einfach auf der lokalen Festplatte des anderen Clusterknotens ab. Fällt nun der Knoten aus, dann startet der virtuelle Server auf dem anderen Knoten.

Dieses Konstruktion ist natürlich auf einen 2-Knoten-Cluster beschränkt. Cluster wird also auch damit keine Lösung für jedermann, sondern ist nur für die Firmen interessant, die wirklich eine höhere Verfügbarkeit erreichen wollen. Wenn ihre Ansprüche für den "Worst Case" immer noch nicht im Minutenbereich (Siehe Hochverfügbarkeit) liegen, dann sind andere Alternativen zu evaluieren.

Mit Exchange 2007 wird es keine Unterstützung mehr für A/A-Cluster geben, d.h. es muss immer einen Knoten mehr als virtuelle Server geben.

CCR und Public Folder
CCR unterstützt Öffentliche Ordner nur, wenn es der einzige Store in der gesamten Organisation ist. !!
Exchange 2007 - Planning for Cluster Continuous Replication
http://technet.microsoft.com/en-us/library/bb123996.aspx

CCR und WAN

Wenn Sie nun diese Ideen weiter spinnen, dann könnten Sie ja auf Gedanken kommen, die beiden Server an verschiedene Standorte der Welt zu verteilen.


Achtung: Dieses Bild zeigt absichtlich eine Falschkonfiguration

Das ist sogar möglich, wenn Sie ein paar Randbedingungen aber beachten. Der Fehler in dem obigen Bild ist die ansonsten sinnvolle Trennung der Standorte in eigene Active Directory Standorte.

Wenn Sie also einen CCR-Cluster über zwei Standorte verteilen wollen, dann müssen sie neben einem Konzept und einem Plan im Idealfall eine etwas umfangreichere Konfiguration einstellen. Bitte verstehen Sie das folgende Bild nicht als "Lösung" sondern als Denkanreiz.

Jedes Rechenzentrum hat natürlich seine eigene AD-Site mit eigenen DCs und IP-Subnetzen.. Aber zusätzlich gibt es eine weitere AD-Site nur für die Exchange Server. Diese erstreckt sich über beide Rechenzentren und enthält nur das IP-Subnetz, welches die Betriebsnetzwerkkarten (Nicht Heartbeat) den virtuellen Exchange Server und der beiden Knoten enthält. Diese Netz darf natürlich nicht zwischen den beiden Standorten geroutet werden, sondern muss getunnelt/bridged sein. Damit auch ein automatisches Failover stattfinden kann, muss ein dritter Server, der das File Witness (Majority Set of Quorum Cluster) natürlich an einem anderen Ort stehen.

Sollten Sie keinen dritten unabhängigen Ort nutzen können, dann stellen Sie den Server in das RZ, auf dem der aktive Server arbeitet (z.B.RZ1). Im Falle des höher wahrscheinlichen Leitungsausfalls finden dann kein Failover statt. Allerdings verlieren Sie damit natürlich das automatische Failover beim Ausfall von RZ1. In dieser Situation müssen Sie schon manuell dann den Failover initiieren. Natürlich sollten die Exchange Cluster dann ihre eigenen DC und Hub/Transport-Server in der gleichen Site haben.

Einfacher wird der Failover auch, wenn das "File Share Whitness" nicht auf einen physikalischen Servernamen gebunden wird, sondern auf einen Alias. Dazu kann der Server mit dem FSW einfach ein weiterer Servername verpasst werden. (Siehe auch 281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name), so dass beim Ausfall des FSW ein anderer Server schnell die Funktion übernehmen kann.

Mit Windows 2008 wird es auch möglich sein, einen Cluster über mehrere Subnetze zu erstrecken.

CCR und Public Folder

Immer wieder gibt es unterschiedliche Aussagen zu öffentlichen Ordnern auf einem CCR. Die Bandbreite reicht dabei von "geht nicht" über "nicht unterstützt" bis "bei mir geht es ohne Probleme". Dabei sind die Aussagen ganz einfach, wenn man sie nur lesen würde:

Da stellt sich natürlich die Frage, was denn bei einem Betrieb von öffentlichen Ordnern auf einem CCR in Verbindung mit anderen Servern so "schlimm" ist. Die Beschreibung ist relativ einfach. Der CCR verhält sich im Bezug auf die Datenbank für öffentliche Ordner anders, wenn es eine Replikation mit anderen Servern gibt. Zu unterscheiden haben wir hier zwei Fälle

Man sieht also, dass öffentliche Ordner auf dem CCR eigentlich funktionieren. Das Problem ist aber der ungeplante Failover. In diesem Fall ist es sehr wahrscheinlich, dass die Clients nicht auf öffentliche Ordner zugreifen können.

CCR und Backup

Die Sicherung eines CCR Server unterscheidet sich etwas von der Sicherung eines einzelnen Servern. Der CCR hat insbesondere den großen Vorteil, dass der passive Knoten eine komplette Kopie der Datenbank vorhält und diese dort auch gesichert werden kann. Dabei sind aber ein paar Randbedingungen zu beachten (Stand Exchange 2007 SP1)

Sicherung Streaming/Legacy Schattenkopie/VSS
Aktiver Knoten Voll/Differenziell/Inkrementell/Copy Voll/Differenziell/Inkrementell/Copy
Passiver Knoten keine Sicherung möglich Voll/Differenziell/Inkrementell/Copy

Bei der Sicherung ist zu beachten, dass eine Kombination von Sicherungen Einschränkungen unterliegt. So ist z.B. nach einer VSS Sicherung des Knoten kein inkrementelles Backup per Streaming möglich. Hier muss auch erst wieder eine Vollsicherung per Streaming erfolgen.

Achtung:
Wer auf dem passiven Knoten per VSS sichern will, muss das Backup natürlich auch auf dem passiven Knoten starten lassen. Ich kenne aber noch keine Sicherung, die dies von Hause aus unterstützt, auch das anlegen einer zweiten Clustergruppe für die Sicherung ist nur die halbe Miete, da man dann sicherstellen muss, dass diese auf dem passiven Knoten läuft.
Eine Lösung könnte ein Skript sein, welches eben auf einem beliebigen Knoten von der Sicherung gestartet wird und selbständig den "richtigen" Knoten ausfindig macht und dort das Backup startet. Mit Tivoli Storage Manager 5.5 (TSM) habe ich das schon bei einem Kunden implementiert.

Eine Wiederherstellung ist auf dem passiven Knoten gänzlich unmöglich. Eine Sicherung muss also immer auf dem aktiven Knoten oder einem anderen Server wiederhergestellt werden.

 Weitere Informationen finden Sie auch in der Exchange Dokumentation

CCR und Status

Wer einen CCR betreibt, tut gut daran, das System zu überwachen. Es ist immer wieder erstaunlich, wenn man zu einem Kunden kommt und ein Blick ausreicht, um einen Fehler im Cluster zu erkennen. Sowohl über das Powershell Commandlet "Get-StorageGroupCopyStatus" als auch über Perfmon Counter kann der Administrator den aktuellen Zustand des Clusters erkennen. Aber er muss es auch tun.

Bei der Überwachung ist mir aber auch aufgefallen, dass nicht alle Werte immer schlüssig sind. Das folgende Bild zeigt die Ausgabe der Powershell, von Perfmon und die Transaktionsverzeichnisse einer Speichergruppe

Dieser Testcluster hatte das Problem, dass die Speichergruppen immer auf "Initialisieren" standen und der Status erst dann auf "Healthy" ging, wenn auf dem aktiven Knoten eine neue Transaktionsprotokolldatei geschrieben wurde. Interessanter ist hier aber das Missverhältnis der Aussagen: Perfmon behauptet, dass die CopyQueueLength der SG7 und SG8 =1 ist und dass SG6-SG8 nicht auf dem Status "Initializing" sind während Get-StoragegroupCopyStatus andere (richtige) Werte anzeigt. Ich kann mir das nur zu erklären, dass Perfmon zwar die Werte anzeigt, die im Speicher stehen, aber der Exchange 2007 Replication Service es noch nicht für nötig gefunden hat, diese auch zu aktualisieren.

Diese Situation konnte ich bislang nur auf einem CCR Cluster erleben, auf dem KEIN Postfach existiert hat und demnach auch keine Transaktionsprotokolle entstehen:

"Lost Log Resilience and Transaction Log Activity in Exchange 2007"  http://technet.microsoft.com/en-us/library/bb288910(EXCHG.80).aspx steht:

"The storage group must have one or more mailboxes that are frequently logged on to by a process or by an application"

Insofern sollten Sie ein paar Testmailboxen auf dem CCR Cluster legen, um die Funktion wirklich zu testen, sonst ist Exchange eher ein Rennpferd, was aber ohne Reiter nicht weiß, wo es hinlaufen soll. Dies Funktion gibt es nicht für öffentliche Ordner.

CCR und VSS-Backup
Wer seine Server per VSS sichert, wird auch sehen, dass der VSS-Writer die Replikation kurz anhält und dann wieder startet, was natürlich ebenfalls zu einem "Initializing" führt und verbleibt, solange keine Aktivität statt findet.

Weitere Links

Keywords:Exchange2K7 Exchange 2007