Exchange 2007 - CCR Failover

Diese Seite beschreibt meine eigenen Erfahrungen und Eindrücke einer Exchange 2007 Funktion, die ich aber mangels Source-Code nicht 100% sicherstellen kann. Es kann also sein, dass hier einige Fehler enthalten sind. Feedback ist gerne willkommen. Kontakt

White Paper: Continuous Replication Deep Dive (released erst Jun 2008)
http://technet.microsoft.com/en-us/library/cc535020(EXCHG.80).aspx

Erschreckenderweise scheinen immer mehr Firmen einen Exchange 2007 CCR zu installieren, ohne sich genauer mit der Thematik beschäftigt zu haben. Ich mache das an Supportcalls und Fragen in Newsgroups fest, die erst dann kommen, wenn das Kind sprichwörtlich schon in den Brunnen gefallen ist.

Unterstützung durch Net at Work:
Diese Seite versucht die Hintergründe eines CCR zu beschreiben. Sie ist keine How-To Anleitung, sondern soll ihnen die Komplexität verdeutlichen. Wir helfen ihnen gerne bei der Planung, Umsetzung und Pflege ihres CCR Clusters.

CCR Ziele und Warnungen

In aller Kürze möchte ich der noch einmal ein paar Fakten dazu aufführen:

ACHTUNG: Nutzen Sie immer die Exchange Commandlets um einen Cluster zu schwenken
Damit sind sie sicher, dass der passive Knoten auch die Funktion übernommen hat, ehe Sie den vormals aktiven Knoten herunter fahren

Fahren Sie nie den aktiven Knoten mit einem "Shutdown" herunter
Ansonsten beenden sich zwar noch die Exchange Dienste "sauber" aber der Serverdienst wird dann auch sehr schnell beendet. Der passive Knoten hat nicht mehr die Zeit alle beim Beenden der Speichergruppen geschriebenen Transaktionsprotokolle zu kopieren und fährt nicht mehr hoch.

Wenn Sie nun immer noch glauben, dass CCR für Sie die richtige Lösung ist, dann schauen Sie sich die folgenden Ausführungen an. Sie sollten das alles schon vorher gewusst haben und dies nur als "Auffrischung" verstehen. Zudem ist dies natürlich nur eine Teilmenge dessen, was ein Administrator mit Cluster wissen sollte.

CCR Planung

Wenn Sie CCR nur als Paarung von zwei Servern zur besseren Verfügbarkeit von Exchange 2007 ansehen, dann haben Sie ihre Hausaufgaben noch nicht gemacht. Die Exchange Verfügbarkeit misst sich beim Client. Ich habe ihnen hier mal eine mögliche Konfiguration aufgezeichnet.

CCR Netzwerkplanung

Wichtig ist, dass für ein echtes automatisches Failover wirklich alle Komponenten doppelt und unabhängig voneinander vorhanden sind. Dazu zählen nicht nur die beiden Clusterknoten, sondern auch die Domain Controller, DNS, WINS, NTP und andere Infrastrukturdienste. Auch die Hub/Transport und Client Access-Rollen müssen zum einen auf nicht geclusterten Servern und dann auch doppelt vorgehalten werden. Wird ein echter "Shared Nothing"-Cluster installiert, muss der File Share Whitness so platziert werden, dass er keine gemeinsamen Komponenten mit den Clusterknoten nutzt. Er muss auch den Ausfall eines kompletten Datacenters so überleben, dass der verbliebene Knoten eine Verbindung herstellen kann. Häufig vergessen werden die Clients. Auch diese müssen mit beiden Knoten derart angebunden werden,  dass der Ausfall eines Datacenters keine Folgen für die Kommunikation mit dem anderen Datacenter hat.

Damit sie überprüfen können, ob Sie alle Ausführungen "verstanden" haben, sehen Sie hier eine CCR Planung , die mindestens 4 Fehler enthält:

CCR Fehler

Die Fehler sind im einzelnen:

Spitzfindige Leser können mir nun gerne schreiben, dass ich hier noch die redundante Datensicherung, die Internetanbindung etc. vergessen habe. Hochverfügbarkeit mit Exchange ist ein weites Feld und auch wenn die Exchange 2007 Online Hilfe die Installation sehr einfach beschreibt und die Installation sogar per grafischem Assistenten wirklich Jedem gelingen sollte, ist CRR mehr als nur das Ausführen verschiedener Setups.

CCR Failover

Im folgenden beschreibe ich drei von vielen möglichen Ausfällen, um die Funktionsweise des CCR und der Failover-Funktion zu beschreiben.

Auf dem Exchange Team Blog finden Sie Flussdiagramme, wann CCR welche Aktion durchführt.
http://msexchangeteam.com/files/12/attachments/entry447215.aspx

Geplanter Failover

Diese Situation ist hoffentlich die häufigste Umschaltung von einem Knoten auf einen anderen Knoten. Dies trifft z.B. bei der Installation von Hotfixes und Sicherheitsupdates zu. Der passive Knoten wird "gefixt" und danach durch einen geplanten Failover "aktiv" gesetzt. Dann kann der vormals aktive und nun passive Knoten aktualisiert werden. Eventuell schwenken Sie dann wieder die Dienste auf den ersten Knoten zurück. 

CCR Failover geplant

Durch den geplanten Schwenk werden die Transaktionsprotokolle nach dem Shutdown des aktiven Knotens auf den passiven Knoten kopiert und dann erst gestartet. Dies funktioniert, weil zwar Exchange noch down ist, aber die Dateifreigaben weiterhin erhalten bleiben. Der Transport Dumpster kommt nicht zum Einsatz

Replikationsausfall

Ein anderer häufiger Fall ist eine Unterbrechung der Replikation. Wenn Sie z.B.: den passiven Knoten nach einem Update herunterfahren, dann werden die Protokolldateien erst einmal nicht weiter repliziert.

CCR Aussetzer

Startet der Server dann wieder, dann werden auch hier wieder zuerst die Transaktionsprotokolle kopiert. Übrigens berücksichtigt Exchange diesen Fall auch bei der Datensicherung. Wenn Sie in dieser Phase ein Streamingbackup des aktiven Knotens machen, dann werden nur die Transaktionsprotokolle entfernt, die schon auf dem passiven Knoten sind. Lassen Sie den passiven Knoten also nicht allzu lange "offline" und überwachen Sie die Partition mit den Transaktionsprotokollen.

Ungeplanter Failover

Fällt ein aktiver Clusterknoten ungeplant aus, dann bedeutet dies für den passiven Knoten, dass er zumindest nicht mehr das aktuelle Transaktionsprotokoll mehr hat. Ist der passive Knoten nicht schnell, dann können sogar mehrere Transaktionsprotokolle á 1 Megabyte fehlen.

CCR Failover ungeplant

Mails während der Ausfallzeit bleiben auf dem Transport Server in der Warteschlange liegen. Der passive Knoten versucht dann seine Kopie der Datenbank zu starten. Allerdings fehlen natürlich die letzten Nachrichten. Nun kommt der Transport Dumpster zum Einsatz. Exchange fordert die letzten Nachrichten einfach noch einmal an.

Elemente, die aber in letzter Zeit direkt verändert, angelegt oder gelöscht wurden, z.B.: Termine, Kontakte, Aufgaben etc. und nicht über den Hub/Transport übertragen wurden, sind jedoch nicht mehr vorhanden.

Wird nun der ausgefallene Server wieder aktiviert, dann "versucht" Exchange diesen wieder in die Replikation einzubinden. In den meisten Fällen funktioniert dies sogar, so dass kein komplettes "Seeding" der Datenbank erforderlich wird. Dies würde ja eine Kopieraktion von mehreren Gigabyte zum zweiten Knoten (auch über WAN) bedeuten.

CCR Recovery

Daher hat Microsoft bei Exchange 2007 CCR ziemlich viel Grips investiert, um die Erfordernis einer kompletten Datenbankkopie zu reduzieren. Dies ist eigentlich nur erforderlich, wenn die Datenbank auf dem passiven Knoten nicht mehr vorhanden (Neuinstallation, Festplattenverlust) ist.

Exchange arbeitet transaktionsorientiert. Eine ����nderung wird dazu zuerst im Hauptspeicher durchgeführt und dann in das Transaktionsprotokoll gesichert geschrieben. Die entsprechende Änderung in der Datenbank hingegen erfolgt nicht unbedingt zeitnah. Hier kann Exchange Zugriffe optimieren. Entsprechend groß ist die Wahrscheinlichkeit, dass ihre Änderung noch bis zum Exchange Speicher und vielleicht auch noch in das Transaktionsprotokoll gekommen ist, aber nicht mehr in der Datenbank gelandet ist. Beim CCR hilft das aber nicht, da das letzte Transaktionsprotokoll nicht kopiert wurde. Mit etwas Glück ist die Datenbank auf einem Stand, bei dem sie auch später als passiver Knoten weiter geführt werden kann.

CCR Datenverlust und Recovery 

Viel kniffliger ist das Problem, wenn eine Änderung auch noch den Weg bis in die Datenbank geschafft hat, aber das Transaktionsprotokoll noch nicht auf den passiven Knoten übertragen wurde. Findet nun ein ungeplanter Failover statt, dann fehlen diese Informationen auf dem neuen aktiven Knoten aber die Datenbank auf dem vormals aktiven Knoten ist schon verändert. Kommt nun der alte Knoten wieder online, so versucht dieser eine Rückreplikation. Dazu prüft Exchange die Datenbank und schaut, ob eine Replikation von dem aktiven Server zurück überhaupt möglich ist. Das ist in dem Fall nicht mehr möglich. Aber schauen wir uns die Replikation im zeitlichen Verlauf an.

CCR Failover Recovery

Schritt Beschreibung

 

 Die Installation des aktiven Knotens auf NODE1 erzeugt eine Datenbank. Die Installation des passiven Knotens NODE2 führt dazu, dass die Datenbank beim ersten mal natürlich auf den passiven Knoten kopiert (Seeding) wird.

 

 In der Folge beginnt dann die normale Arbeit und Replikation. Der Node1 ist der aktive Server und generiert für die Änderungen entsprechende Transaktionsprotokolle (1,2,3,4,5,..). Diese werden auf den NODE2 repliziert und dort auch in die Datenbank geschrieben.

 

 Die Datenbank des aktiven Knotens folgt den Transaktionsprotokollen mit etwas Verzögerung. In diesem Beispiel wird die Datenbank erst weitergeschrieben, als schon das vierte Transaktionsprotokoll bearbeitet wird. Die "Versionsnummer" der Datenbank soll anzeigen, bis zu welchem Transaktionsprotokoll die Daten bereits gepflegt sind. Es kann also durchaus sein, dass der passive Knoten schon weiter ist als der aktive Knoten.

 

 Wird der passive Knoten nun herunter gefahren, dann stoppt natürlich die Replikation. den aktiven Knoten stört dies aber nicht. Ist der passive Knoten wieder online, dann beeilt er sich natürlich, die Transaktionsprotokolldateien der Vergangenheit nachzuziehen. Wir gehen nun davon aus, dass das Transaktionsprotokoll "7" noch den Weg auf den passiven Knoten geschafft hat

 

 Hier passiert ein ungeplanter Ausfall. Die Transaktionsprotokolle 8 und 9 sind nicht mehr repliziert worden. Die Datenbank des ausgefallenen Servers ist bis zum Transaktionsprotokoll 4 gekommen. Dennoch muss der passive Knoten nun aktiv werden und startet seine Datenbankkopie. Die Änderungen aus Transaktionsprotokoll 8 und 9 sind verloren bzw. werden teilweise durch den Transport Dumpster nachgeliefert.

 

 Der neue aktive Knoten "NODE2" protokolliert nun seinerseits alle Aktivitäten der Benutzer in den Protokolldateien 8b, 9b und folgende.

 

 Der ausgefallene Server wurde repariert. Dabei blieben die Festplatteninhalte (vor allem die Datenbank)erhalten. Die Datenbank ist bei einer Version 4 stehen geblieben. Nun beginnt der Server seine Prüfung und stellt fest, dass er seine Datenbank durch die eigenen Transaktionsprotokolle und die Kopien von 8b,9b ff wieder synchron bringen kann. Es findet also kein "Seeding" statt.

Dass der ausgefallene Cluster kein Seeding benötigt hat im wesentlichen den Grund, dass die Datenbankversion einen Stand vor dem Failover hat. Hätte die Datenbank schon das Transaktionsprotokoll 8 eingespielt, welches nie auf dem passiven Knoten gelandet ist, dann wären beide Datenbanken auseinander gelaufen. Der NODE hätte dann nicht mehr anhand der Transaktionsprotokolle von NODE2 einen konsistenten Stand erreichen können. Stellen Sie sich zwei Autos vor, von denen eines falsch abbiegt und nicht mehr zurück fahren kann.

CCR Details (LLR, AutoDatabaseMountDial und ForceDatabaseMountAfter

Wie sie jetzt wissen ist der Umgang mit den Transaktionsprotokollen ein wichtiger Punkt beim Betrieb eines CCR-Clusters. Bei einem ungeplanten Failover gehen auf jeden Fall Transaktionsprotokolle verloren. Dies kann durch mehrere Einstellungen gesteuert werden.

Exchange 2007 reduziert selbst das Verlustrisiko, indem Transaktionsprotokolle immer mal wieder abgeschlossen werden, auch wenn in der Zeit nichts passiert ist. Das Transaktionsprotokoll enthält dann leere Bereiche aber dies erlaubt dem passiven Knoten auch die Teilmenge schon zu replizieren und zu übertragen. Drei Stufen sind hierbei konfigurierbar

Konfiguration Logintervall AutoMount
Standard Server
LCR Server
Single Copy Cluster
CCR mit "LossLess"		 96 (900Sek) <=0
CCR mit Good Availability 384 (225 Sek) <=2
CCR mit Best Availability (Default) 675 (128Sek) <=5

Das bedeutet aber auch, dass bei "Best Availability" pro Tag mindestens 675 Megabyte Transaktionsprotokolle entstehen die auch auf den passiven Knoten repliziert werden, auch wenn keine Daten umgeschlagen werden.

Die gleiche Einstellung steuert auch beim Failover, bis wann Exchange die Datenbank automatisch mounted. In der Einstellung "Lossless" wartet der passive Knoten immer bis alle Transaktionsprotokolle kopiert wurden. Damit ist sichergestellt, dass keinerlei Daten verloren gehen. Dies hilft beim CCR aber nur dann wenn der Exchange Dienst auf dem aktiven Knoten ausgefallen ist, aber die Transaktionsprotokolle weiterhin per SMB kopiert werden können.

Standardeinstellung ist aber "Best Availability", d.h. bis zu 5 Transaktionsprotokolle (also 5 MB Daten) können vergessen werden. Damit bei dieser Einstellung aber der Verlust nicht ganz so groß ist, wird hier dann alle 2 Minuten ein neues Transaktionsprotokoll gestartet, so dass auf einem Server mit wenig Last eine Änderung nach wenigen Minuten vom passiven Knoten bezogen werden kann.

Diese Einstellung erfolgt über den Parameter "AutoDatabaseMountDial"

Set-MailboxServer <CMSName> -AutoDatabaseMountDial:<Value>

Gültiger Wert ist: Lossless, GoodAvailability, BestAvailability

Ein zweiter Parameter steuert, wie lange der Cluster wartet bis die Datenbank automatisch gemountet wird. Der passive Knoten versucht immer och vom früheren aktiven Knoten die Transaktionsprotokolle zu beziehen aber dieser Parameter begrenzt dies in der Zeit.

Set-MailboxServer <CMSName> -ForceDatabaseMountAfter:<Value>

Gültige Werte: Datum/Zeit (2h ist dann "2:00:00") oder "unlimited"

Nach dieser Zeit wird also die Datenbank "immer" gemountet, auch wenn mehr Protokolldateien fehlen sollten.

Best Practice
Die Standardeinstellungen von Exchange 2007 sind "BestAvailability" und "unlimited", d.h. der Ausfall bis zu fünf kompletten (und einem angefangenen) Transaktionsprotokoll wird toleriert aber wenn mehr Daten fehlen, dann müssen Sie als Administrator Hand anlegen und den passiven Knoten selbst aktiv schalten oder die fehlenden Transaktionsprotokolle von den Festplatten des ausgefallenen Knotens extrahieren.
Diese Einstellungen sind aus meiner Sicht sinnvoll. Überwachen Sie am besten wie weit der passive Knoten hinter ihrem aktiven Knoten hinterherläuft

Übrigens installiert CCR die Clustergruppe derart, dass nur ein Failover pro Stunde erlaubt ist. Bei Exchange 2003 waren die Werte noch 10 Failovers in 6 Stunden. Dies kommt auch meiner Empfehlung nahe, da ich auch schon immer predige, dass ein Cluster vielleicht ein oder zweimal umfallen darf, aber spätestens dann das System verharren soll, so dass ein Administrator auch eine Fehlersuche durchführen kann. Es ist nicht nur störend, wenn ein Exchange Cluster dauernd schwenkt und einem dadurch die Hände gebunden sind. Für eine Testumgebung ist diese Einstellung  natürlich erst einmal störend, denn hier werden Sie sicher häufiger einen "Failover" benötigen.

CCR Reseeding, wann passiert es ?

Die Funktion des ReSeedings ist in folgenden Fällen erforderlich

Da ein Seeding einer vollen Datenbank faktisch eine Kopie der kompletten Datenbank bedeutet, ist dieser Fall besonders "teuer", wenn eine WAN-Verbindung dazwischen liegt. Ein ReSeeding können Sie z.B. nachstellen, indem Sie den Microsoft Exchange Replication Service auf dem passiven Knoten stoppen, dann die EDB und LOG-Dateien löschen und dann den Service wieder starten.

Technisch ist das ReSeeding einfach ein "StreamingBackup" des aktiven Knoten. Der passive Knoten kopiert die Datenbank, indem er sie über die StreamingAPI vom aktiven Knoten kopiert, wie dies auch beim Streamingbackup erfolgt, nur dass es ein "COPY" ist, d.h. die Transaktionsprotokolle natürlich danach nicht gelöscht werden.

Achtung Remote Streaming Copy und SP1
Aus "Sicherheitsgründen" erlaubt die API seit SP1 kein Kopieren mehr über das LAN und stört damit auch das Reseeding. Also müssen Sie auf den CCR diesen Default wieder ändern
Exchange 2007 - Using Backup to Back Up and Restore Exchange Data
http://technet.microsoft.com/en-us/library/aa998870.aspx

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Name: Enable Remote Streaming Backup
Type: DWORD
Value: 0 = default behavior (remote backup disabled); 1 = remote backup enabled

CCR Dienste

Wenn Sie sich im Cluster Administrator die Exchange Gruppe anschauen, dann erkennen Sie, dass ein CCR in der Clusterverwaltung nur folgende Dienste anzeigt:

Die vom Exchange 2000/2003 bekannten Dienste wie SMTP, MTA, HTTP etc. sind alle nicht mehr als Clusterressource vorhanden. Wenn Sie aber die Exchange Dienste selbst anschauen, dann finden Sie sehr viele weitere Dienste, die nicht als Clusterressource aufgelistet sind:

Sie können auch gerne mal den Test machen und einen dieser anderen Dienste stoppen. Der Cluster wird dies nicht bemerken und auch nicht schwenken. Das ist prinzipiell sogar wünschenswerte, dass sekundäre Dienste nicht gleich einen Failover bewirken. Aber es entbindet Sie natürlich nicht von der Überwachung.

Ich hätte mir z.B. gewünscht, dass diese sekundären Dienste durchaus im Cluster eingerichtet sind. Es reicht ja ein "Do not affect group", damit bei einem Ausfall dieser Dienste der Cluster nicht schwenkt, aber die Gruppe ein gelbes Ausrufezeichen bekommt.

CCR FAQ

CCR Überwachung

Die meisten Administratoren haben vermutlich noch nie wirklich die Performance Counter angeschaut, denn auf dem passiven Knoten gibt es sehr viele Counter, die sehr gut den Status des CCR-Knotens anzeigen. Man erkennt sehr gut die verschiedenen Stationen, die eine Protokolldatei durchläuft, bis Sie im Ziel (dem passiven Knoten) letztlich eingebunden ist.

CCR im Perfmon

Besonders sind hier natürlich die Counter interessant, die eigentlich nur den Status 0 oder 1 haben:

Details, wo es gerade klemmt kann man anhand der anderen Werte erhalten. Der Exchange Replication Service auf dem passiven Knoten ist dafür zuständig, die Protokolldateien auf dem aktiven Knoten zu sehen, zu kopieren, zu prüfen und letztlich in die Datenbank einzubauen. Daher findet man dieses Counter auch nur auf dem passiven Knoten.

Hier ein Bild zu der Position der verschiedenen Counter.

Sie wissen nun, dass es auch eine Liste der Dateien gibt, die vom Replication Service noch zu bearbeiten sind. Als Prüfpunkt kann man also auch einfach kontrollieren, ob diese Listen ausreichend Kurz sind. Meist sind die Werte nahe 0.

Ein Teil der Werte könnte man sich natürlich einfach durch die Substraktion der beiden Counter vor und hinter der Warteschlange ermitteln.

Weitere Links

Keywords: Exchange2K7 Exchange 2007 CCR Cluster Hochverfügbarkeit Failover