Exchange 2007 - Standby Continuous Replication (SCR)

Mit dem Exchange 2007 Service Pack 1 gibt es eine eine weitere Option für eine höhere Verfügbarkeit als Ergänzung zu den bisherigen Optionen Cluster Continuous Replication, Local Continuous Replication und SingleCopyCluster.

SCR ist keine Lösung für "jedermann". Für die meisten Leser der MSXFAQ, die eine zweite Kopie ihrer Exchange Datenbank wünschen, ist die Lösung mit Local Continuous Replication der bessere Ansatz. SCR bringt nur etwas, wenn ein weiterer Server vorgehalten wird und Sie die Schritte zur Umschaltung beherrschen.

Die Funktion ist erst mit Exchange 2007 SP1 verfügbar

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

Funktionsweise und Ziel

Die "Standby Continuos Replication" hat nicht die Aufgabe beim Ausfall des primären Systems den Betrieb sofort wieder aufzunehmen, sondern dient primär dazu, eine Kopie der Datenbank auf einem anderen Server vorzuhalten, so dass diese relativ schnell wieder aktiviert werden kann. Genau genommen werden dazu die Daten auf einen anderen Server kopiert, der auch weit entfernt stehen kann.

Database Portability
Die Funktion des SCR basiert im wesentlichen auf der neuen Funktion von Exchange 2007, dass eine Datenbank an jedem Server in der gleichen Organisation "online" gebracht werden kann.

Fällt der Quellserver aus, dann muss der Administrator auf dem SCR-Server erst das Exchange Setup starten um dort Exchange zu installieren.

Dieser Schritt bedeutet gleich dreierlei:

Insofern ist der SCR die logische Weiterentwicklung der Hochverfügbarkeitsstrategie von Exchange und vielleicht zukünftig auch anderen Diensten.

Wer mit Wem ?

Während beim LCR ein Server eine 1:1 Kopie seiner Datenbanken auf einem anderen Massenspeicher ablegt und beim CCR zwei identische Server als Paar auftreten ist diese Bindung beim SCR komplett aufgehoben. Sicher werden viele Firmen ihrem aktiven Standalone Server oder CCR-Server einen SCR-Server in einem anderen Brandabschnitt oder sogar einem anderen Ort zur Seite stellen. Aber darauf ist ein SCR nicht beschränkt. Genau genommen ist nämlich alle Kombinationen möglich. Hier eine Auswahl.

SCR Konfiguration Beschreibung
Single to Standby
 Der einfachste Weg, einen normalen Exchange Server auf einen anderen vorbereiteten Server zu replizieren, um im Falle eines Ausfalls eine Kopie schnell online bringen zu können
CCR to Standby
 Aus meiner Sicht der häufigste Konfigurationsfall, wenn eine Firma heute schon eine hohe Verfügbarkeit durch CCR erreichen will und bei einem Ausfalls des Rechenzentrums in kurzer Zeit in einem anderen RZ online gehen will
CCR to Multi Standby
CCR an mehrere SCR		 Diese Abwandlung soll nur als Beispiel dienen, dass ein CCR-Server seine Datenbanken auf mehrere SCR-Server verteilen kann. Ich denke aber dass der Einsatzbereich hierfür eher theoretisch ist.
Many Single to single Standy
Mehrere Single an einen SCR		 Diese Option ist interessant, wenn Sie mehrere Exchange Server an einem Standorte haben und einen SCR-Knoten als Standby vorsehen. Denken Sie aber daran, dass ein Server max. 50 Speichergruppen halten kann und beim Ausfall mehrerer Server der SCR Knoten die Last tragen muss.
Natürlich kann man auch hier eine N:M Beziehung aufbauen.
CCR to SCR/CCR
 Firmen mit zwei Rechenzentren können natürlich in einem RZ einen CCR als normale Hochverfügbarkeit bereitstellen und eine Kopie auf einen passiven Knoten eines CCR-Servers in einem anderen Subnetz ablegen. Fällt das komplette erste RZ aus, kann der Betrieb sehr schnell im zweiten RZ weiter gehen und ist sogar dort als CCR ausgeführt. Sicher ein Einsatzfall für sehr wenige Kunden aber zeigt, was machbar ist.

Generell gelten einfach die Aussagen:

Lizenzierung

Mit der Lizenz ist es nicht ganz so einfach. SCR ist mit Exchange 2007 SP1 verfügbar und wird sowohl mit der Standard Version als auch mit der Enterprise Version zur Verfügung stehen. In der aktuellen Dokumentation finde ich dazu:

SCR is available in the Standard Edition of Exchange 2007 SP1. If a Mailbox server in an SCC or CCR environment is used as the SCR source, the Enterprise Edition of Exchange 2007 SP1 is required because Enterprise Edition is required when clustering Exchange 2007. If a standby cluster is being used as the SCR target, the Enterprise Edition of Exchange 2007 SP1 is also required.
http://technet.microsoft.com/en-us/library/bb676502.aspx

Insofern ist der Einsatz von SCR auch ohne eine Enterprise Lizenz in bestimmten Konstellationen möglich. Bedenken Sie aber, dass eine Standard Version nur maximal 5 Datenbanken betreiben kann.

Failover und Fallback

Da kein automatischer Failover stattfinden kann, muss der Administrator manuell eingreifen. Dazu sind auf dem SCR-Knoten zwei Befehle erforderlich

Danach ist der frühere SCR-Server dann als Exchange Server aktiv. Allerdings ist der Name natürlich ein anderer Name als der frühere produktive Server. Nun müssen Sie noch die Mailboxen verschieben.

Bei Exchange 2010 gibt es den Parameter "-ConfigurationOnly" nicht mehr. Statt dessen wird die richtige Datenbank einfach mit SET-MAILBOX gesetzt. Um alle Benutzer aus DB1 nach DB2 umzustellen ist das dann ein get-mailbox -database DB1 | set-mailbox -database DB2

Wurde der primäre Server wieder repariert, ist die ganze Logik wieder umzudrehen. Der wiederhergestellte Cluster wird zum passiven SCR-Empfänger und nachdem alle Daten wieder repliziert sind, sind die gleichen Schritte erneut durchzuführen.

SCR verkreuzen

Es ist nicht zwingend, dass der SCR-Zielknoten exklusiv bereit steht. Der SCR Server kann auch andere Dienste, z.B. Exchange betreiben. Damit ist z.B. folgende Konfiguration denkbar (Habe ich selbst aber noch nicht produktiv umgesetzt):

Single Server mit bidirektionalem SCR Partner

Zwei Exchange Server an einem Standort betreiben ihren eigenen Mailboxspeicher und nutzen sich gegenseitig als SCR-Ziele. Fällt nun ein Server aus, so kann der Store auf dem anderen Server "relativ" schnell bereit gestellt werden. Beachten Sie dabei aber:

Daher nochmal der Ratschlag, vielleicht besser über ein ordentliches Backup/Restore mit einem Recovery-Plan nachdenken, mit dem in der Verbindung mit LCR auch eine Ausfallzeit von wenigen Stunden erreicht werden kann. Ein SCR ist nicht zwingend "schneller" online, sondern erlaubt einfach die geografische Verteilung von Daten. Jeder der Hochverfügbarkeit im Bereich von wenigen Minuten braucht, ist mit echten Clustern (MSCS) in Verbindung mit CCR oder SCC besser beraten.

Überlegungen zur SCR Belastung

Wer also keinen CCR-Server (z.B. wegen Kosten für Windows Enterprise) betreiben will, kann statt dessen einen Exchange 2007 Standard Server greifen und mit einem SCR-Partner (z.B. kleinere Hardware oder virtuell) eine bessere Verfügbarkeit erreichen. Da stellt sich natürlich die Frage, wie viel "Last" denn so dein SCR-Partner hat, wenn er nur SCR-Ziel für den primären Exchange Server ist (und nicht selbst Datenbanken aktiv betreibt)

Dazu überlegen wir uns erst mal, was genau der SCR tut.

Auf der anderen Seite macht ein reiner SCR-Knoten aber folgende Tätigkeiten nicht:

Insofern hat er als reine SCR-Knoten weniger Bedarf an CPU, Netzwerk und RAM. Die Disk-Belastung ist zwar vom Volumen der Diskdateien her „gleich“ allerdings nicht so anspruchsvoll an „Echtzeit“, da ja keine Clients auf antworte warten. Insofern könnten Sie überlegen, den SCR-Server entweder einfach schwächer zu dimensionieren oder als virtuelles System mit weniger Ressourcen auszustatten.,

Denken Sie aber daran, dass der SCR-Knoten irgendwann doch aktiv werden muss und sie dann die Einstellungen wieder ändern  müssen. Oder sie akzeptieren ein trägeres Antwortverhalten. Interessant könnte daher die Option sein, dass sie nicht mit einem primären und einem SCR-Knoten arbeiten, sondern beide System ihren Teil der Anwender betreiben und nur im Fehlerfall die anderen Datenbanken mit übernehmen. Dann entfallen auch die Überlegungen zur sparsameren Dimensionierung eines SCR-Knotens.

Zusammenfassung

Sie sehen also, dass der Failover zum SCR nicht ein einfacher Mausklick ist, sondern dass SCR nur eine neue Option bietet, um eine höhere Verfügbarkeit beim Ausfall des primären Single Servers oder CCR-Clusters zu erreichen. Es ist aber keine Failover-Lösung für regelmäßige Failovers, wie dies bei CCR oder einem SCC möglich und vorgesehen ist.

Weitere Links

Keywords:Exchange2K7 Exchange 2007