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:

  • Manuelles Failover mit Zeitbedarf
    Der SCR-Knoten muss erst durch die Installation/Konfiguration  von Exchange "aktiviert" werden. Damit bleibt es dem Administrator überlassen, den "Schwenk" selbst durchzuführen. Das ist besonders wichtig, da ohne Automatismus natürlich auch kein "Falscher" Failover passieren kann. Allerdings muss der Administrator auch die Zeit einberechnen, um Exchange zu installieren.
  • Zielserver hat Exchange Dienste
    Der Zielserver muss kein aktiver Exchange Server sein. Allerdings muss der Exchange Replikation Dienst vorhanden sind, was doch nur über die Installation der Mailbox Rolle erfolgen kann. Insofern ist ein SCR-Server auch immer ein Exchange Server.
  • Kein MSCS erforderlich
    Für den Betrieb eines SCR ist kein Microsoft Cluster erforderlich. Es können damit zwei normale Windows 2003 Standard Server verwendet werden, um einen aktiven Server zu haben.

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:

  • Many to Many
    SCR ist nicht auf eine 1:1 Kopie beschränkt, sondern ein Server kann mehrere SCR-Knoten bedienen und ein SCR-Knoten kann von mehreren Servern
  • Ziel muss "passiv" sein
    Ist der SCR-Server selbst als Microsoft Cluster (MSCS) ausgeführt, dann muss das Ziel ein "passiver" Knoten sein, d.h. auf ihm selbst darf Exchange nicht aktiv sein.
  • 1:1 Datenbankzuordnung und max. 50 Speichergruppen
    Auch für SCR gilt, dass immer nur genau eine Datenbank in einer Speichergruppe enthalten sein darf. Zudem kann auch hier ein Server maximal 50 Speichergruppen bedienen. Bedenken Sie das besonders, wenn mehrere Server den gleichen SCR-Server als Ziel haben.

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

  • Restore-StorageGroupCopy
    Damit wird die Kopie quasi "aktiviert"
  • Setup /m:RevoverCMS oder Setup /m:RecoverServer
    Über diese Kommandozeile wird Exchange 2007 im "Recover Mode" installiert. Das Setup geht davon aus, dass die Datenbanken vorhanden sind und auch die Konfiguration im Active Directory gültig ist. Es werden im wesentlichen nur die Exchange Binaries und lokalen Konfigurationseinstellungen durchgeführt.

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.

  • Move-Mailbox mailbox -targetDataBase dbname -configurationonly
    Über das Move-Mailbox Commandlet werden nun die Einträge bei den Benutzern auf den neuen Server umgestellt (Im wesentlichen sind dies HomeMTA, HomeMDB, msExchHomeServerName). Die Inhalte werden jedoch nicht verschoben, da diese ja schon da sind.

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:

  • Sizing
    Beide Server müssen so ausgelegt sein, dass Sie beide die volle Last tragen können und zusätzlich die Replikationslast und Belastung beim umschalten
  • Failover-Zeit
    Im Gegensatz zu CCR ist der Failover manuell und dauert einige Zeit.
  • Know-How
    Das System macht nichts alleine. Sie als Administrator müssen daher die richtigen Befehle in der richtigen Reihenfolge durchführen. Dazu benötigen Sie Know-how und regelmäßige Übung.

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.

  • Der SCR kopiert Transaktionsprotokolle von dem Aktiven Koten über das LAN
    Entsprechend benötigt er Ressourcen für die Netzwerkzugriffe, Bandbreite, wenig CPU und natürlich etwas Disk-IO. Wobei dieser IO nicht "zeitkritisch" ist und das Volumen bei den meisten Firmen überschaubar ist. Prüfen Sie doch mal, wie viele Transaktionsprotokolle ihr Exchange Server pro Tag macht. Sind es wirklich 20 Gigabyte am Tag? Selbst dann sind das auf 8 Arbeitsstunden grade mal 41 Megabyte/Minute oder 680 Kilobyte/Sek., was heute keinen Server ernsthaft aus der Ruhe bringen sollte.
  • Ein SCR prüft die kopierten Logs (Disk-Lesen)
    Dann prüft der SCR-Prozess natürlich die Konsistent der Protokolldateien (vergleichbar zum ESEUTL) mit der gleichen Performance. Das passiert direkt nach dem Kopieren, so dass die Blöcke meist eh noch im Cache sind und daher nur etwas CPU-Last und PCI-Bus erforderlich ist.
  • Ein SCR bucht die Logs in die Datenbank ein
    Das ist nun etwas mehr Arbeit, da der SCR die Logdateien in die Datenbank einbucht und dazu "Random" auf die verschiedenen Blöcke zugreift. Die Festplatten haben also schon etwas zu tun, aber auch hier die die Belastung nicht zeitkritisch, da ja kein Anwender auf Ergebnisse wartet. Die Anforderungen sind also geringer als beim aktiven Betrieb.

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

  • Virenscan
    Die hierfür sonst aufgewendete CPU-Last kann also entfallen
  • Keine Clients (Disk, RAM, Connections)
    Da der SCR keine Anwender bedient, entfällt die Last für das zufällige Lesen von Blöcken aus den Datenbanken. Während der aktive Exchange 2007 Server allen Hauptspeicher auch für das "Cachen" von Zugriffen nutzt, um eben die Clients schneller zu bedienen, entfällt auch diese Last für den SCR-Knoten. Er kann also mit weniger Speicher arbeiten.
    Zuletzt entfallen die Arbeiten zur Pflege von Verbindungen von Outlook zum Postfachserver (Netzwerk, TCP-Stack, Puffer etc.)
  • keine Verbindungen zum Hub/Transport oder CAS
    Abe auch die Transportdienste und IMAP4, POP3, OWA und ActiveSync-Zugriffe belasten nicht den SCR-Knoten, da diese alle den primären Server ansprechen.

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