EMC RepliStor

Exemplarisch für alternative Produkte zur Hochverfügbarkeit konnte ich EMC RepliStor in der Version 6.1 einmal genauer unter die Lupe nehmen.

Verstehen Sie diese Seite nicht als Empfehlung, sondern eher als Know-how Artikel, welche Kniffe und Tricks mit Exchange so alles möglich sind.

Unterstützung durch Net at Work:
Wir unterstützen Sie gerne bei der Analyse ihrer Anforderungen an die Verfügbarkeit eines Systems und wählen mit ihnen das für Sie passende Produkt aus, implementieren es und weisen Sie ein.

Beachten Sie die neuen Funktionen Cluster Continuous Replication und Local Continuous Replication, die mit Exchange 2007 interessante Alternativen bieten.

Das Prinzip

Die prinzipielle Funktionsweise von Replistor ist die Übertragung von Änderungen auf einer Festplatte von einem Server auf einen anderen Server.  Das gleiche Prinzip nutzen auch Produkte. Dazu wird auf dem Quellesystem ein Filtertreiber installiert, der jede Änderung auf der Festplatte (Blockweise) erkennt und zum Backupsystem überträgt. Einige Systeme arbeiten dabei Synchron, d.h. ehe die Daten nicht im Backup geschrieben sind, bekommt auch die Quelle kein OK. Replistsor arbeitet Asynchron, d.h. wenn der Zielserver nicht aktiv oder zu langsam ist, dann baut sich eine Warteschlange auf. Fällt dann die Quelle aus, dann ist ein mehr oder minder großer Datenverlust zu erwarten. Durch die Replikation wird erreicht, dass beide Systeme fast unabhängig voneinander sind auch auch etwas weiter entfernt stehen können.

Replistor sollte prinzipbedingt mit jeder NTFS-Festplatte funktionieren, auch wenn kein Exchange Server drauf installiert ist. Der Zielserver ist aber ebenfalls ein Windows Server und im gleichen Netzwerk muss dieser ja einen anderen Namen und eine eigene IP-Adresse haben. Der zweite Server ist quasi ein "Standby-Server".

Fällt nun der produktive Server aus, muss der Standby-Server dies erkennen und seine Dienste starten. Bei einem Dateiserver kann man ja noch recht einfach den Namen ändern und den Server durchstarten oder den alten Servernamen einfach als zusätzlichen Namen hinzubinden.

HKEY_Local_Machine\System\CurrentControlSet\Servic es\LanmanServer\Parameters
OptionalNames:REG_SZ = "Alias" oder  REG_MULTI_SZ

  • 829885 Distributed File System Update to support consolidation roots in Windows Server 2003

Allerdings ist das bei Exchange nicht so einfach, da auf dem Backupserver ja auch Exchange installiert sein muss. Die Installation mit dem gleichen Namen geht aber nicht, so dass der Backupserver als eigener Exchange Server in der Organisation auftaucht.

Daher wird Exchange 2000/2003 auf dem Standbyserver mit dem Namen des Standby-Servers installiert und danach die Dienste beendet. Fällt der Quellserver nun aus, dann startet Replistor auf dem Standbyserver die Exchange Dienste. Wie Sie ja bereits aus Exchange NOTFALL Hilfe wissen, kann man eine Exchange Datenbank problemlos an einem anderen Server mounten.

Damit ist die Backupdatenbank zwar nun online, aber davon haben die Anwender erst mal nichts, da der Server ja einen neuen Namen hat und die ganzen Einträge im Active Directory (HomeMDB, HomeMTA etc.) noch auf den alten Server verweisen.

Trick mit "Network Address"

Hier kommt nun eine Besonderheit von Exchange zum Tragen, die ich so auch noch nirgends produktiv gesehen habe und daher auch erst mal skeptisch bin, ob dieser Weg wirklich legitim ist: Damit die Clients per MAPI nicht den "echten" Namen verwenden wird ein Alias im eingetragen. In der Exchange Konfiguration im Active Directory wird beim originalen Server im Feld "networkAddress: ncacn_ip_tcp:ALIAS.msxfaq.de". eingetragen. Verbindet man Outlook mit dem Server, dann übernimmt MAPI diesen Alias in das MAPI-Profil. Dieser Name ist natürlich nicht mit dem physikalischen Servernamen identisch. Per DNS und WINS wird dieser Alias auf eine eigene IP-Adresse aufgelöst. Der aktive Server hat dann diese IP-Adresse gebunden. (Dies ist seltsamerweise nur mit IPCONFIG zu sehen und nicht in den Eigenschaften der Netzwerkkarte)

Failover

Wenn wir in dieser Situation nun einen Fehler des Servers SOURCE annehmen und einen geplanten Failover vornehmen, dann werden folgende Aktionen gestartet:

  1. TARGET: Exchange Dienste werden beendet
  2. TARGET: IP-Adresse wird freigegeben
  3. TARGET: Daten werden zum Ziel repliziert und dann beendet
  4. TARGET: Skript ändert alle Empfänger Objekte (HomeMDB/HomeMTA)
  5. TARGET: IP-Adressse binden und aktivieren
  6. TARGET: Dienste starten

Exchange ist nun auf dem Targetserver. Die Funktion des "Patchen" entspricht "etwa" dem eines Move-Mailbox, nur dass die Daten über RepliStor rüberkommen und nur die usereigenschaften angepasst werden. Dieses Verfahren einer Migration soll wohl auch ab Exchange 2007 offiziell per PowerShell nutzbar werden.

Bei einem "ungeplanten" Ausfall von SOURCE erkennt der Server TARGET den Ausfall und übernimmt die Funktion. Da hierbei die Replikation von der Quelle natürlich einfach unterbrochen wurde, muss TARGET nun anhand der Daten auf seinen Festplatten die Datenbanken wieder starten. Dank der transaktionsorientierten Datenbank (Siehe Exchange Datenbank - ein Blick dahinter) ist dies normalerweise auch kein Problem. Voraussetzung ist natürlich, dass die blockbasierte Replikation auch immer schön in der Reihenfolge der Änderungen die Daten repliziert hat.

Reparatur und Fallback

Wenn der Server SOURCE nun wieder repariert ist, dann erfolgt erst mal kein automatisches FallBack. Im Gegensatz zum Microsoft Cluster, bei dem die Daten auf einem gemeinsamen Laufwerk liegen, müssen hier ja die Änderungen seit dem Ausfall natürlich erst wieder auf den Server SOURCE durch folgende Aktionen zurückrepliziert werden.

  1. SOURCE: Server reparieren
    Zuerst muss der Server SOURCE natürlich wieder repariert werden bzw. in einen funktionsfähigen Zustand versetzt werden.
  2. TARGET: Server als Quelle definieren
    Auf dem Server TARGET muss nun der lokale Datenspeicher als Quelle aktiviert werden. Erst dann startet die Replikation der Änderungen zurück auf den Server SOURCE
  3. Manuelles Failover nach Replikation
    Nachdem alle Daten wieder "In Sync" sind, kann auch die Aufgabe wieder auf den Server SOURCE übertragen werden.
    Vergessen Sie danach aber nicht die Aktivierung von "SOURCE" als Quelle, damit der Server TARGET auch wieder als Ziel der Replikation arbeiten kann

Sonstige Vorteile

RepliStor ist nicht nur ein Produkt für Exchange, sondern kann auch normale Dateiserver replizieren und damit höher verfügbar machen. RepliStor nutzt dazu auch die Windows 2003 Schattenkopien um die Daten abzugleichen und wieder bereit zu stellen.

Durch die Installation von RepliStor kommen Sie als Administrator damit zu einer sehr einfach zu bedienenden Funktion, Schattenkopien von Servern zu erstellen und diese einfach per Mausklick auch wieder zu "mounten".

Zudem unterstützt RepliStor auch Exchange über Schattenkopien. So können Sie ganz einfach eine Datenbank einer Schattenkopie wieder bereitstellen und z.B.: mit PowerControls 4 einzelne Inhalte davon extrahieren oder über die Recovery Storage Group komplette Postfächer zurücksichern.

Eine Replikation und Schattenkopien sind aber kein Ersatz für ein ordentliches Backup

Fragen und Verbesserungen

  • Speichergruppe statt Dienste ?
    Vermutlich gibt es das Produkt auch schon für Exchange 5.5. Ansonsten wäre es durchaus denkbar, nicht den kompletten Store zu beenden, sondern einfach nur die Speichergruppen beim Failover anzustarten.
    Ein Betrieb als "Aktiv/Aktiv" Konfiguration ist aber so nicht denkbar, da der Exchange Servername "ALIAS" nur genau einem System gehören darf
  • Offline Adressbuch
    Bei einem Failover werden natürlich alle Benutzer geändert. Ich konnte es noch nicht prüfen, aber ich denke, dass dies auch zu Änderungen beim Offline Adressbuch führen kann. Wenn dem so ist, dann kann ein einziger Failover natürlich auch bedeuten, dass die Client beim nächsten Download einiges mehr herunter laden müssen. (die 10% Regel sagt, dass bei mehr als 10% Änderungen sogar das komplette Adressbuch herunter geladen wird.)
  • AD Replikation
    Auf jeden Fall bedeutet so ein Schwenk viel Replikation für die Domaincontroller. Erst Windows 2003  DCs replizieren "feldweise" und nicht mehr das gesamte Objekt. Aber selbst dann ist die Belastung bei JEDEM Schenk vorhanden. Dies muss besonders berücksichtigt werden, wenn eine Niederlassung vielleicht nur sehr schwach angebunden ist. Ein anderes Problem kann natürlich die Latenzzeit und Caches anderer Server sein. Selbst wenn die Eigenschaften geändert sind, dann wissen das noch nicht alle DCs und noch nicht alle Bridgehead und Frontend Server. Hier kann es also schon etwas dauern, bis alles wieder "rund" läuft. Dies dürfte auch Mails auf anderen Servern betreffen, die schon in der "Warteschlange" zum SOURCE sind, aber durch den Ausfall die Empfänger schon alle auf TARGET sind.
  • Downzeit/Failoverzeit
    Demosystem sind natürlich keine Live-Systeme aber eine umschaltung  kann schon einige Minuten dauern. Damit ist man immer noch schneller als mit einem Ersatzserver, aber ein Microsoft Cluster ist natürlich schneller. Zudem stellt sich die Frage, wie lange der Neustart nach dem Failover dauert, wenn das aktive System "unsanft" beendet wurde.
  • Monitoring
    Die Lösung stellt besondere Ansprüche an das Monitoring, da natürlich ein Server beendet ist und der Zustand "normal" ist. Problematisch ist es, wenn beide Server beendet oder beide Server gestartet sind. Diese Situation ist dann ein "Fehler": Aber da beide Exchangeserver in der Konfiguration vorhanden sind, werden andere Server der Organisation natürlich beide erreichen wollen und entsprechende Events produzieren
  • Public Folder
    Soweit ich das Prinzip verstanden habe, dürfen auf den Servern demnach keine öffentlichen Ordner abgelegt werden. Das Problem wären die Replikationsnachrichten an die jeweiligen Systeme, die nur ankommen, wenn ein SMTP-Dienst und Postfachspeicher für die Systemmailbox aktiv ist. Der Server, der aktuell passiv ist, nimmt aber keine Nachrichten an, so dass sich in den Warteschlangen zu diesem Server sehr bald umfangreiche Replikationsnachrichten stauen werden. Zum Glück können öffentliche Ordner auch ohne Cluster allein durch zwei Server und Replikation höher verfügbar gemacht werden. Dies bedeutet aber auf jeden Fall zusätzliche Server
  • Dienstabhängigkeiten
    Wird der RepliStor-Service beendet, dann werden auch die Exchange Dienst mit beendet. Da dies aber nicht durch "Abhängigkeiten" im Dienstmanager definiert ist, erhält der Administrator keine Warnung. Umgekehrt können die Exchange Dienste problemlos von Hand gestartet werden,  auch wenn der RepliStor-Dienst nicht läuft. Die Folgen sind natürlich unangenehm da damit die Replikation der Datenbank in Konflikt mit den laufenden Diensten steht. Hier könnte die Definition von Abhängigkeiten eine Fehlerquelle verhindern.

Gerade die massenhaften Änderungen an den Empfänger im Active Directory über zwei Exchange Server mit "schwingenden" Datenbanken können ein Problem werden. Beim Microsoft Cluster Server werden Knoten gerne mal geschwenkt, um ein Update, ServicePack oder andere Wartungsarbeiten auszuführen. Dies ist bei Ansatz von Replistor kritischer zu sehen und muss im Einzelfall entschieden werden.

Auf der anderen Seite ist mit RepliStor eine höhere Verfügbarkeit sicherlich machbar, ohne gleich den Aufwand eines Microsoft Cluster Servers betreiben zu müssen. Interessant wir der Ansatz durch die sonstigen Produkte von EMC. Als Hersteller leistungsfähiger Speichersubsysteme kann die Replikation der Daten natürlich auch durch Hardware erledigt werden.

Details

Bei der Betrachtung von RepliStor  sind mir natürlich ein paar Dinge aufgefallen, die mein Interesse geweckt haben.

Auch hier gilt: Ich kann nicht dafür garantieren, das die hier gemachten Aussagen vollständig sind und problemlos auf eigene Lösungen übernommen werden können.

Virtuelle Servername

So konnte ich zwar im MAPI-Profil als Servernamen sowohl SOURCE als auch TARGET eingeben, aber Outlook hat als Servernamen in das Profil immer "ALIAS" geschrieben. So kam das her ?

Also habe ich in der Registrierung als auch im AD nach dem ALIAS gesucht und bin auch fündig geworden.

dn: CN=TARGET,CN=Computers,DC=msxfaq,DC=de
dNSHostName: TARGET.msxfaq.de
servicePrincipalName: exchangeMDB/ALIAS.msxfaq.de
servicePrincipalName: exchangeRFR/ALIAS.msxfaq.de
servicePrincipalName: exchangeRFR/TARGET.msxfaq.de
servicePrincipalName: exchangeRFR/TARGET
servicePrincipalName: exchangeMDB/TARGET
servicePrincipalName: exchangeMDB/TARGET.msxfaq.de
servicePrincipalName: SMTPSVC/TARGET.msxfaq.de
servicePrincipalName: SMTPSVC/TARGET
servicePrincipalName: RepliStorServer/TARGET.msxfaq.de
servicePrincipalName: RepliStorServer/TARGET
servicePrincipalName: HOST/TARGET
servicePrincipalName: HOST/TARGET.msxfaq.de

dn: CN=SOURCE,CN=Computers,DC=msxfaq,DC=de
dNSHostName: SOURCE.msxfaq.de
servicePrincipalName: exchangeRFR/ALIAS.msxfaq.de
servicePrincipalName: exchangeMDB/ALIAS.msxfaq.de
servicePrincipalName: RepliStorServer/SOURCE
servicePrincipalName: RepliStorServer/SOURCE.msxfaq.de
servicePrincipalName: exchangeRFR/SOURCE.msxfaq.de
servicePrincipalName: exchangeRFR/SOURCE
servicePrincipalName: exchangeMDB/SOURCE
servicePrincipalName: exchangeMDB/SOURCE.msxfaq.de
servicePrincipalName: SMTPSVC/SOURCE
servicePrincipalName: SMTPSVC/SOURCE.msxfaq.de
servicePrincipalName: HOST/SOURCE
servicePrincipalName: HOST/SOURCE.msxfaq.de

Der Name "ALIAS" wird in dem servicePrincipalName des jeweiligen Computerkontos mit aufgeführt. Da aber dort acuh die anderen "echten" Computernamen mit enthalten sind, kann dies nicht allein ausschlaggebend sein.

Ein zweites Vorkommen ist da schon interessanter:

dn: CN=TARGET,CN=Servers,CN=AG1,CN=Administrative Groups,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de
networkAddress: ncacn_ip_tcp:ALIAS.msxfaq.de
networkAddress: ncacn_vns_spp:TARGET
networkAddress: NetBIOS:TARGET
networkAddress: ncacn_np:TARGET
networkAddress: ncacn_spx:TARGET
networkAddress: ncalrpc:TARGET
name: TARGET

dn: CN=SOURCE,CN=Servers,CN=AG1,CN=Administrative Groups,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de
networkAddress: ncacn_ip_tcp:ALIAS.msxfaq.de
networkAddress: ncacn_vns_spp:SOURCE
networkAddress: NetBIOS:SOURCE
networkAddress: ncacn_np:SOURCE
networkAddress: ncacn_spx:SOURCE
networkAddress: ncalrpc:SOURCE
name: SOURCE

Wenn Sie dann Testweise einfach mal den Namen hier durch einen anderen Namen ersetzen, und im MAPI-Profil als Server "SOURCE" eingeben, dann ist gut zu sehen, dass eben dieser hier eingetragene Aliasname verwendet wird. Da repliStor aber nur die Einstellungen beim Protokoll "ncacn_ip_tcp" ändert, dürfte der Failover entsprechend auch nur über dieses Protokoll funktionieren. IPX; NetBIOS und BanyanVines sind außen vor.

Interessant ist das Verhalten dennoch, da so der Exchange Servername ein Stück weit virtualisiert werden kann. Leider erlaubt Exchange damit aber keine echten "virtuellen Server", wie dies beim Microsoft Cluster möglich ist. Daher ist ein Failover einzelner Postfächer, Datenbanken oder Speichergruppen nicht möglich. Dennoch ist es damit möglich, einen ausgefallenen Server auf einem anderen Server mit anderen physikalischen Namen weiter leben zu lassen.

Patchen der userdaten

Durch die Replikation der Datenbanken werden beim Failover keine Daten mehr verlagert. Dennoch müssen die Konfigurationsdaten bei den Empfängern natürlich "korrigiert" werden. Hier zählen nur echte Servernamen und keine Aliaseinträge.

Daher habe ich einen Benutzer exportiert und nach dem Failover erneut exportiert. Folgende Felder haben Sie dabei geändert:

Vorher:

dn: CN=User1,CN=Users,DC=msxfaq,DC=de

homeMTA: CN=Microsoft MTA,CN=SOURCE,CN=Servers,CN=AG1,CN=Administrative Groups,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de

homeMDB: CN=MB1,CN=SG1,CN=InformationStore,CN=SOURCE,CN=Servers,CN=AG1,CN=Administrative Groups,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de

msExchHomeServerName: O=MSXFAQ/OU=AG1/cn=Configuration/cn=Servers/cn=SOURCE

Nachher

dn: CN=User1,CN=Users,DC=msxfaq,DC=de

homeMTA: CN=Microsoft MTA,CN=TARGET,CN=Servers,CN=AG1,CN=Administrative Groups,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de

homeMDB: CN=MB1,CN=SG1,CN=InformationStore,CN=TARGET,CN=Servers,CN=AG1,CN=Administrative Groups,CN=MSXFAQ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=msxfaq,DC=de

msExchHomeServerName: O=MSXFAQ/OU=AG1/cn=Configuration/cn=Servers/cn=TARGET

Zudem erfolgt beim umschalten der umzug der Daten ja nicht per Exchange Admin, sondern über die Replikation. Wenn das so einfach ist, dann kann das auch jeder selbst machen, z.B.: wenn Datenbanken im SAN angeschlossen sind und einfach der Exchange Server davor gewechselt werden soll

Weitere Links

ähnliche Produkte