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 müssenspeicher, 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 für 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.

  • Virtual Server hat EINE IP
    Das Bild zeigt zwei Netzwerke, die mit Routern verbunden sind. Das bedeutet natürlich auch, dass beide Netzwerke ein eigenes IP-Subnetz sind. Damit bekommt aber der Clusterdienst ein Problem, da dem Exchange Virtuellen Server (EVS) ja eine IP-Adresse als  Ressource zugewiesen ist. Diese kann natürlich auch nur in dem dazugehörigen Subnetz aktiviert werden
  • Hub/Transport Failover über mehrere AD-Sites
    Diese Konfiguration funktioniert nicht. Siehe auch Exchange Server 2007 routing load balancing and fault tolerance
    http://blogs.technet.com/b/exchange/archive/2007/01/04/432069.aspx
  • High availability für Microsoft Exchange Server 2007 using CCR with HP StorageWorks EVA8000
    http://h20195.www2.hp.com/PDF/4AA1-4230ENW.pdf

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 Witness" 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:

  • CCR und Single Public Folder Store
    Wenn es in der gesamten Organisation nur genau einen Speicher über öffentliche Ordner gibt, dann kann der natürlich auf einem CCR liegen. In diesem Fall ist die Replikation von öffentlichen Ordner deaktiviert
  • Migration von Exchange 2003 auf CCR
    Installiert man einen Exchange 2007 CCR in eine Exchange 2003 Umgebung dann hat man natürlich mehrere Datenbanken und entsprechend ist die Replikation aktiviert. Dies ist erlaubt und auch ein gültiger Weg, um die Inhalte auf den CCR zu migrieren. Nachdem aber alle Inhalte auf den CCR repliziert wurden, "sollten" alle anderen Instanzen entfernt werden, so dass der CCR der einzige Server mit einem öffentlichen Informationsspeicher ist.
  • Migration von Exchange 2003 weg vom CCR
    Will man aber nun doch mehrere Server mit einer Datenbank für öffentliche Ordner betreiben, dann kann man weitere Datenbanken auf anderen Servern anlegen und die Inhalte vom CCR auf diese Server replizieren. Auch hier "sollten" dann am Ende die Datenbank auf dem CCR entfernt werden.

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

  • Geplanter Failover (Lossless)
    Hierbei kann der vormals passive Knoten alle Transaktionsprotokoll kopieren und die Datenbank ohne Verlust "online" schalten. Alles arbeitet wir gewohnt
  • Ungeplanter Failover
    Wenn beim Failover einige Transaktionsprotokolle nicht mehr kopiert werden können, müsste der Server ja eine "etwas ältere" Datenbank online schalten. Das stört die Replikation. Aus diesem Grund wird die Datenbank nicht online geschaltet und kann auch nicht online geschaltet werden !!. Der Administrator kann die Datenbank nur dann online schalten, wenn er die fehlenden Transaktionsprotokolle vom ausgefallenen Server dazu kopiert oder den ersten Knoten repariert und wieder hochfährt. Ist dies nicht möglich, dann kann man nur den Public Folder Speicher löschen und neu anlegen. Die Inhalte werden dann wieder von den anderen öffentlichen Ordnern zurück repliziert, sofern mindestens eine Instanz der Inhalte noch vorhanden ist.

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