Kommunikation

Datenschutz und Notfallwiederherstellung für Exchange Server 2007

Lee Benjamin

Kurz zusammengefasst:

• Einfache Sicherung und Wiederherstellung
• Datenkontinuität
• Replikationstechnologien
• Alternative Lösungen

Bei der Entwicklung von Microsoft Exchange Server stand die Sicherheit im Vordergrund. Organisationen müssen ihre Messagingdaten sichern und auch die Möglichkeit haben, diese Daten wiederherzustellen. Um diese Anforderungen zu erfüllen, hat Microsoft ein vollständiges Spektrum an Datenschutzoptionen, von der traditionellen

Sicherung und Wiederherstellung über betriebliche Kontinuität bis hin zu echten Geschäftskontinuitätslösungen konzipiert, durch die ein hohes Maß an Verfügbarkeit und Notfallwiederherstellung bereitgestellt wird. In diesem Artikel werden die verschiedenen Optionen erläutert, um Sie bei der Entscheidung zu unterstützen, wie Sie die beste Exchange-Wiederherstellungslösung für Ihre Organisation implementieren können.

STUFE 1: EINFACHE SICHERUNG UND WIEDERHERSTELLUNG

Sie können Exchange-Dateien sichern, indem Sie die Datenbanken offline setzen, aber Sie können sie auch online sichern. Letztere Alternative ist für Exchange-Dateien in den meisten Fällen zu empfehlen. Aber Exchange ist mehr als ein Satz von Dateien. Es handelt sich vielmehr um einen Informationsspeicher mit großen Datenbankdateien und Transaktionsprotokollen. Nachrichten, die an Exchange gesendet werden, werden sofort in die Transaktionsprotokolle eingetragen, und wenn das System ein paar freie Zyklen hat (meist ein paar Millisekunden später), werden die Nachrichten in die Datenbank kopiert. Durch die schnellstmögliche Speicherung der Daten auf dem Datenträger stellt Exchange ein sehr hohes Maß an Wiederherstellbarkeit bereit. Grundlage für die Wiederherstellung von Exchange ist die Verfügbarkeit beider Informationssätze. Sollte Ihr System ausfallen, ist es die Kombination aus einer früheren Sicherung zusammen mit allen Transaktionen seit diesem Punkt, die es Ihnen ermöglicht, Exchange wieder mit den neuesten Informationen herzustellen. Beachten Sie, dass Exchange Transaktionen bei Bedarf automatisch in eine wiederhergestellte Datenbank einspielt.

Sicherungsprogramme greifen auf Daten in der Exchange-Datenbank über die Extensible Storage Engine (ESE)-Sicherungs-API oder neuere VSS-Lösungen zu, die weiter unten in diesem Artikel erörtert werden. Wenn eine ESE-Sicherung initiiert wird, hält Exchange vorübergehend alle Schreibvorgänge in die Datenbanken an. Gleichzeitig setzt ESE die Datenbank vorübergehend in einen schreibgeschützten Modus, wodurch die Datenbank komplett gesichert werden kann. Zudem werden neue, während der Sicherung erfolgte Transaktionen in einer temporären Datenbank gespeichert. Wenn die Sicherung abgeschlossen ist, setzt ESE die Datenbank wieder in den normalen Lese-/Schreibmodus zurück und fügt dann die Transaktionen ein, die in der temporären Datenbank gesammelt wurden. Am Ende eines erfolgreichen Sicherungsprozesses werden außerdem alte Transaktionsprotokolle gelöscht.

Dieser Sicherungsprozess ist zwar einfach und transparent, sogar für Benutzer, die sich mitten in der Nacht während der Sicherung anmelden, aber ESE braucht u. U. sehr lange für die Sicherung, insbesondere da Exchange-Datenbanken eine Größe von ein paar Gigabyte bis zu noch überschaubaren 30 bis 50 oder sogar bis zu 100 GB haben können. Bei letzterer Größe ist es beinahe unmöglich, unter Einsatz von Standardtechnologien Daten über Nacht zu sichern. Abbildung 1 zeigt Einsatzbeispiele für NTBackup.exe.

Abbildung 1** Verwenden des NTBackup-Dienstprogramms **

Best Practices für Exchange

Wenn Sie in der Lage sein wollen, Daten nach Hardware- und Systemfehlern schnell wiederherzustellen, sollten Sie jede Nacht komplette Exchange-Sicherungen ausführen. Um Leistung und Wiederherstellbarkeit zu verbessern, wenn ein Exchange-Server lokale Festplatten verwendet, sollten Sie zum Speichern der Exchange-Datenbanken und Exchange-Transaktionsprotokolle unbedingt separate RAID-Arrays verwenden. Beim Ausfall eines RAID-Arraycontrollers oder beim Ausfall von mehr als einem Datenträger im Array, sodass die übrigen Datenträger die Daten nicht mehr rekonstruieren können, ist eine Wiederherstellung der Daten trotzdem möglich. Wenn Sie die Transaktionsprotokolle verlieren, stehen immer noch aktuelle Exchange-Datenbanken auf den anderen Laufwerken zur Verfügung, die es Ihnen ermöglichen, normale Vorgänge mit neuen Transaktionsprotokollen fortzusetzen. Wenn Sie die Datenbanklaufwerke verlieren, sieht Ihre Wiederherstellungsstrategie so aus, dass die komplette Sicherung der Exchange-Datenbanken von der vorherigen Nacht mit den Transaktionsprotokollen des laufenden Tags aktualisiert wird.

Es ist wichtig, dass Sie die Größe der Exchange-Datenbanken beschränken, damit jede in kürzester Zeit gesichert und, was noch wichtiger ist, wiederhergestellt werden kann. Für die meisten Organisationen bedeutet dies eine Datenbankgröße von 30 bis 50 GB. Wenn eine Datenbank größer wird, ist es ratsam, sie in mehrere Datenbanken zu unterteilen, damit eine schnelle Wiederherstellung möglich ist.

Sicherungs- und Wiederherstellungsfolge

Der Speicherort der Datenbanken und Transaktionsprotokolle ist äußerst wichtig, nicht nur für die Sicherungsleistung, sondern auch für die Wiederherstellungsgeschwindigkeit. Heute unterstützen alle Server verschiedene Ebenen der Laufwerkredundanz, die als RAID bezeichnet werden. Grundsätzlich ermöglicht es RAID, dass ein Laufwerk ausfällt, ohne dass hierbei das System abstürzt. Die Systemleistung wird dabei allerdings langsamer, bis das Laufwerk ersetzt und wieder aufgebaut ist. Bis dahin muss der Arraycontroller die Daten von den übrigen Datenträgern ad hoc rekonstruieren, sobald sie von einem Laufwerk angefordert werden. Weitere Informationen zum Postfachserver-Speicherdesign finden Sie im Microsoft IT Showcase-Artikel Die 64-Bit-Version von Exchange Server 2007.

Ein Hauptfeature von Exchange ist das Einzelinstanz-Datenbankdesign. Das bedeutet, dass innerhalb einer Exchange-Datenbank nur eine einzige Kopie einer bestimmten Nachricht zusammen mit einer einzigen Anlage (sofern vorhanden) gespeichert wird. Wenn die Nachricht an mehrere Empfänger auf dem gleichen Informationsspeicher gesendet wurde, werden zusätzliche Zeiger zu den Objekten (Nachricht, Anlage) erstellt, die Objekte werden aber nicht dupliziert. Das ist nicht nur sehr effizient, sondern kann auch Speicherplatz für Exchange einsparen, sowohl auf dem Datenträger als auch auf dem Band.

Exchange eignet sich zwar gut zum Wiederherstellen der gesamten Datenbank, zur Wiederherstellung einzelner Postfächer, Ordner oder Nachrichten muss jedoch zuerst das ganze Band wiederhergestellt werden. Es ist nicht überraschend, dass Benutzer besser abgestimmte Wiederherstellungsfunktionen fordern. Durch die Einzelinstanz auf dem Band gestaltet sich dies sehr schwierig. Anbieter von Sicherungslösungen haben auf diese Anforderung mit dem „Brick-Level Backup“ reagiert (das ich nicht empfehle). Nach Abschluss einer kompletten Sicherung der Exchange-Datenbank mit der genehmigten ESE-Sicherungs-API fügen die Sicherungsprodukte dem Sicherungsband alle Postfächer hinzu. Da die Sicherungs-API keine Möglichkeit bereitstellt, die Daten aus einzelnen Postfächern herauszuziehen, wird MAPI verwendet. Folglich ist das Sicherungsband erheblich länger, weil alle Nachrichten und Anlagen dupliziert werden.

Microsoft hat einige Verbesserungen vorgenommen, die das Problem teilweise ansprechen. Zum Beispiel werden Elemente nach dem Löschen durch einen Benutzer über einen bestimmten Zeitraum hinweg im Administratorpapierkorb aufbewahrt, falls sie erneut gebraucht werden. Außerdem ist es nicht mehr notwendig, einen zweiten Server als Gesamtstruktur für die Exchange-Notfallwiederherstellung zur Verfügung zu haben. Speichergruppen für die Wiederherstellung (Recovery Storage Groups, RSG) ermöglichen es einem Administrator nämlich, von Band wiederhergestellte Datenbanken teilweise bereitzustellen und Daten zu kopieren oder bis zur Postfachebene hinunter zusammenzuführen.

Übung macht den Meister

Sicherungsmedien und Wiederherstellungsverfahren müssen unabhängig vom Sicherungs- und Wiederherstellungsumfang regelmäßig getestet werden. Viele Organisationen lernen dies spätestens dann, wenn Daten einmal unwiderruflich verloren gegangen sind. Zu viele Administratoren finden erst heraus, ob ihre Sicherungstechnologien und Wiederherstellungsverfahren tatsächlich funktionieren, nachdem ein Notfall eingetreten ist. Der beste Testzeitpunkt ist der Tag, wenn der neue Server aufgebaut, konfiguriert und als Teil der Exchange-Organisation in Betrieb ist, aber erst ein paar Benutzer hat. Zu diesem Zeitpunkt sollte eine komplette Exchange-Sicherung sowie regelmäßige Sicherungen der Laufwerke durchgeführt und auch der Systemstatus erfasst werden, der äußerst wichtige Dateien auf dem Systemdatenträger sowie die IIS-Metabasis enthält (in der die Exchange-Routerkonfiguration gespeichert ist). Formatieren Sie dann den neuen Server in aller Ruhe neu. Aktualisieren Sie dabei die Notizen, die Sie beim ersten Aufbau des Servers dokumentiert haben. Sie müssen in der Lage sein, Einstellungen vom Systemstatus wiederherzustellen, sollten die Systemkonfigurationseinstellungen aber auch ausreichend dokumentiert haben, um sie manuell wiederherstellen zu können.

Durch einen solchen Test lässt sich die Zeit, die Sie in Zukunft für eine Wiederherstellung benötigen, erheblich verringern. Wiederholen Sie den Prozess in regelmäßigen Abständen. Messen Sie während der Testläufe auch gleich die Zeit, die benötigt wird, um Bänder von einem anderen Ort wieder zu Ihrem Server zu bringen. Sie werden sich auf diese Weise ein realistischeres Bild darüber machen können, wie wichtig eine Sicherungs- und Wiederherstellungsstrategie sein kann, selbst wenn Sie sich letztendlich für den Notfall auf Sicherungsbänder verlassen, die an einem anderen Ort aufbewahrt werden.

Herausforderungen bei der Bandsicherung

Eine Wiederherstellung von Band nimmt zu viel Zeit in Anspruch. Exchange ist für Organisationen inzwischen so wichtig, dass Benutzer und das Management ständige Verfügbarkeit erwarten. Wenn ein ernsthaftes Problem auftritt, werden die meisten Organisationen hiervon überrascht. Niemand plant bei seiner Arbeit ein, dass es acht Stunden dauern kann, eine 75 GB große Datenbank von Band wiederherzustellen, und das umfasst noch nicht einmal die Zeit für die Beschaffung der Bänder von einem anderen Ort oder für die Installation des Betriebssystems.

Außerdem besteht noch die Herausforderung, die richtige Datenbank vom Band abzurufen. In den 10 Jahren, seit Exchange erstmals auf den Markt kam, sind Festplattenspeicher und WANs sehr viel preiswerter geworden. Demzufolge können sich viele Organisationen schnellere Methoden zur Sicherung und Wiederherstellung leisten. Organisationen können heute Technologien nutzen, die es ihnen ermöglichen, betriebliche Kontinuität und Notfallwiederherstellung für ihre Exchange-Infrastruktur zu erhalten.

STUFE 2: BETRIEBLICHE KONTINUITÄT

Betriebliche Kontinuität ist ein Satz von Prozessen und Technologien, der eine Wiederherstellung beschleunigen und unerwartete Ausfallzeiten minimieren soll. Bei einer lokalen Wiederherstellung von Band bietet betriebliche Kontinuität eine verkürzte Zeitspanne von einem Ausfall bis zur Wiederaufnahme des Diensts (Recovery Time Objective, RTO) und eine geringere Datenmenge, deren Verlust toleriert werden kann (Recovery Point Objective, RPO). Die Zeit, die benötigt wird, um Bänder von einem anderen Ort zu holen, soll möglichst eliminiert werden. In Abbildung 2 ist ein Vergleich der betrieblichen Kontinuität für Sicherung und Wiederherstellung und DR abgebildet.

Abbildung 2** Wiederherstellungsfolge **(Klicken Sie zum Vergrößern auf das Bild)

Das Schaubild illustriert die Wiederherstellungs- und Verfügbarkeitsfolge von langsam und billig am linken unteren Rand zu schnell und teuer am rechten oberen Rand, mit einem absichtlich verwischten Übergang zwischen betrieblichen Kontinuitäts- und Notfallwiederherstellungslösungen.

Das Schaubild vermittelt Ihnen einen Eindruck über die Kompromisse zwischen Kosten, Wiederherstellungszeiten und Verfügbarkeit bei den verschiedenen Ansätzen. In diesem Artikel unterscheide ich absichtlich ganz deutlich zwischen lokalen Kontinuitätsprozessen und Notfallwiederherstellung. DR wird immer als remote angesehen, mit dem Hauptziel, die Daten an einen anderen Ort zu bringen. Entfernung führt zu zusätzlichen Herausforderungen und ist in der Regel viel teurer, aber bei DR geht es darum. dass der Geschäftsbetrieb nach Notfällen fortgesetzt werden kann. Darauf wird weiter unten in diesem Artikel näher eingegangen.

Ein bisschen Geschichte

In dem Maße, in dem Exchange ein wichtigerer Bestandteil der Infrastruktur wurde und mehr Informationen in Exchange-Datenbanken gespeichert wurden, mussten die Sicherungs- und Wiederherstellungszeiten verkürzt werden. In Zusammenarbeit mit Microsoft entwickelten einige große Organisationen einen Ansatz, der eine bessere Rückkehr zum teilweisen Betrieb bot. Wenn eine Organisation E-Mails empfangen und senden kann, scheint nach außen alles in Ordnung zu sein. Der äußere Eindruck zählt nun mal.

Um diese „Dial-Tone“-Wiederherstellung für Exchange zu implementieren, kam anstelle der beschädigten Datenbank eine neue Datenbank zum Einsatz. Exchange und Active Directory® erstellten dann neue Postfächer mit den entsprechenden Zugriffsrechten, und Benutzer konnten E-Mails senden und empfangen. Wenn dann das Sicherungsband an Ort und Stelle war und die Daten wiederhergestellt waren, konnte es vom Administrator bereitgestellt werden. Der Exchange-Administrator führte dann die wiederhergestellten Postfächer mit den „Dial-Tone“-Postfächern zusammen. Postfächer konnten nach Bedarf priorisiert werden. Obwohl dies eine Verbesserung war, war es ein zeitaufwändiger und komplizierter Prozess, der ursprünglich EXMERGE verwendete und dann auf RSGs zugeschnitten wurde. Es sollte jedoch darauf hingewiesen werden, dass eine komplette Datenwiederherstellung nach einem „Dial-Tone“-Wiederherstellungsszenario mühsam und kompliziert sein kann, insbesondere, da in Exchange 2007 bis zu 50 Speichergruppen möglich sind. Wenn Sie erwägen, ein „Dial-Tone“-Wiederherstellungsszenario zu implementieren, sollten Sie die Vor- und Nachteile gründlich abwägen.

Volumeschattenkopie-Dienste

Um günstigere Datenträger zu nutzen und die Prozessorbelastung für Exchange-Server in der Produktion zu senken, wurde für Microsoft® Windows Server® 2003 und Exchange eine neue Sicherungs-API entwickelt. Der Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS) wurde entwickelt, um konsistente Kopien von Daten für einen bestimmten Zeitpunkt zu erstellen. Bei diesen Snapshots handelt es sich um verkürzte, schreibgeschützte Kopien der Exchange-Daten, die fortlaufend nur die Daten enthalten, die sich geändert haben. Die Kopien zeigen gewöhnlich auf einen anderen Server mit verfügbarem Speicherplatz oder auf ein Storage Area Network (SAN). Es können mehrere Snapshots erstellt und auf Band gesichert werden. Der Exchange-Server in der Produktion wird damit also nicht mehr von der Leistung der Sicherungssoftware und der Belastung durch Bandkopien beeinträchtigt.

Es gibt mehrere Vorteile, die für eine Verwendung von VSS für den Exchange-Datenschutz sprechen. Erstens kann der Leistungsaufwand von Bandsicherungsvorgängen aus dem Exchange-Server entfernt werden. Eine Sicherung auf Band ist zwar immer noch erforderlich, aber es kann die Kopie der Exchange-Daten verwendet werden, sodass sich die Sicherung nicht auf die Benutzerleistung auswirkt. Zweitens wird es möglich, Snapshots häufiger als einmal pro Nacht zu erstellen. Als Bonus können Sie mehrere Snapshots auf dem sekundären Server oder einem anderen lokalen Speicher speichern.

Es gibt eine Reihe von Produkten von Drittanbietern auf dem Markt, die die VSS-Snapshotfunktionen nutzen. Einige verkürzen einfach die Zeit, die für eine Sicherung und Wiederherstellung von Exchange-Datenbanken erforderlich ist, während andere Funktionen wie eine besser abgestimmte Wiederherstellung als der systemeigene Exchange Server hinzufügen, wodurch Sie bis zur Postfachebene hinunter wiederherstellen können. Während niemand solche „Brick-Backups“ mag, möchten die Benutzer doch manchmal in der Lage sein, nur bestimmte Ordner oder sogar Nachrichten wiederherzustellen.

Replikationstechnologien

Softwaregestütztes Exchange-Failover wird von einigen Anbietern von Replikationslösungen als Option bereitgestellt. Dabei geht ein Exchange-Standbyserver live und teilt dann Active Directory mit, dass die Postfächer aller Benutzer verschoben wurden. Hierfür gibt es zwei Möglichkeiten, und beide erfordern einige Anpassungen der Exchange- und Windows-Umgebung. Bei der einen Möglichkeit sind ein paar Tricks mit DNS erforderlich, damit der Standbyserver den Namen und die IP-Adresse des ausgefallenen Servers annimmt. Dieser Ansatz hat den Vorteil, die Clientarbeitsstationen nicht zusätzlich zu belasten, da Outlook® denkt, dass immer noch der gleiche Server verwendet wird.

Beim zweiten Ansatz wird ein Standbyserver verwendet, auf dem Exchange ausgeführt wird und auf dem sich Kopien der Datenbank befinden, aber nichts bereitgestellt ist. Bei einem Ausfall informiert der Standbyserver Active Directory, dass alle Benutzerpostfächer zu diesem Server verschoben wurden. Dann wird ein Skript ausgeführt oder eine Gruppenrichtlinie verteilt, die die Clients informiert, dass sie sich auf einem anderen Mailserver befinden. Outlook 2007 erkennt Active Directory, was den Prozess erleichtert, weil diese Zuordnungen automatisch gefunden werden.

Lokale Clusterbildung mit MSCS

Höher in der Verfügbarkeitsfolge ist Microsoft Cluster Services (MSCS). Exchange ist eine clusterorientierte Anwendung. Clusterbildung gibt Informationen zwischen zwei oder mehr Computern frei, damit bei einem Ausfall ein anderer Computer einspringen kann. Heute liegen in den meisten Exchange-Clustern zwei oder vier Knoten vor, obwohl bis zu acht Knoten verwendet werden können. Ein Knoten ist immer passiv und funktioniert, wenn Windows Server ausgeführt wird und Exchange Server installiert ist, aber keine aktiven Postfächer vorhanden sind. Ein 2-Knoten-Cluster (aktiv/aktiv) war in Exchange 2003 möglich, ist aber aufgrund des Leistungsaufwands heute nicht mehr die bevorzugte Option und wird in Exchange 2007 nicht unterstützt.

Wie bei der Exchange 2003-Clusteranordnung können die Exchange 2007-Cluster, die einen passiven Knoten enthalten, immer noch ein einzelnes freigegebenes Speicherarray verwenden. Obwohl Speicherarrays mit Clusterqualität in der Regel über eine Anzahl von Redundanzfeatures verfügen, die vielen Arten von Fehlern widerstehen, stellen sie nach wie vor nur eine Kopie der Daten bereit, wodurch eine Sicherheitslücke verbleibt. Diese Cluster werden als Einzelkopiecluster (Single Copy Cluster, SCC) bezeichnet, um sie von der nächsten Stufe des Datenschutzes zu unterscheiden, die sich in Exchange 2007 in Form von Mehrfachkopieclustern (Multiple Copy Cluster, MCC) präsentiert. Unter dem Thema Notfallwiederherstellung werden MCCs detaillierter beleuchtet.

Lokale ununterbrochene Replikation

Lokale ununterbrochene Replikation (Local Continuous Replication, LCR) ist ein neues Feature in Exchange 2007, das eine verbesserte Möglichkeit bietet, eine zweite Kopie der Exchange-Datenbanken und Transaktionsprotokolle auf demselben Server zu speichern. Hierdurch wird der Best Practice, die Exchange-Datenbank auf einem RAID-Array und die Transaktionsprotokolle auf einem anderem zu speichern, eine Redundanzebene hinzugefügt: LCR ermöglicht es, eine sekundäre Kopie der Protokolle auf dem Array zu speichern, das die primäre Kopie der Datenbank enthält und dann eine sekundäre Kopie der Datenbank auf dem Array zu speichern, das die primäre Kopie der Protokolle enthält (siehe Abbildung 3). Wenn der RAID-Controller oder das Array ausfällt, stehen immer noch die Datenbank und die Transaktionsprotokolle auf dem anderen Array zur Verfügung. Auf diese Weise können Sie weiterarbeiten, wenn auch nicht mit einer gleich hohen Leistung, bis Sie das ausgefallene Array wieder aufbauen können.

Abbildung 3** Konfigurieren von LCR **

LCR ist eine lokale betriebliche Kontinuitätslösung und keine Sicherungslösung, deshalb benötigen Sie nach wie vor eine komplette Sicherungsstrategie. Mit LCR wird auch die Leistung beeinträchtigt, weil der Server jetzt zwei Kopien der Datenbank und der Transaktionsprotokolle erstellt. Außerdem gibt es in der Exchange 2007-Implementierung einige Beschränkungen, durch die sich LCR lediglich für kleinere Organisationen eignet, weil LCR nur eine Datenbank in einer Speichergruppe und nur eine öffentliche Ordnerdatenbank in einer Organisation unterstützt.

Ein Failover mithilfe einer LCR-Wiederherstellung erfolgt nicht automatisch. Ein erfahrener IT-Mitarbeiter muss Skripts ausführen, um Exchange wiederherzustellen. Der Prozess erfordert die Ausführung von Exchange-Verwaltungsshellbefehlen, die außerhalb der Exchange-Verwaltungskonsole ausgeführt werden.

Exchange Server 2003 Enterprise Edition ermöglichte einer Organisation das Ausführen von bis zu 20 Exchange-Datenbanken (vier Speichergruppen mit bis zu je fünf Datenbanken). Exchange 2007 Enterprise Edition dagegen lässt bis zu 50 Speichergruppen zu, wobei jede ihre eigene Datenbank hat. Die Transaktionsprotokolle wurden außerdem von 5 MB-Dateien in Exchange 2003 auf 1 MB-Dateien in Exchange 2007 verringert. Beide Änderungen sollen LCR und die fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR) unterstützen, deren Relevanz weiter unten deutlich wird.

Für kleine und mittelständische Organisationen bietet LCR einen verbesserten Datenschutz der Exchange-Vorgänge. LCR ist leicht zu implementieren, erfordert aber immer noch manuelle Eingriffe. Als eine „gleicher Server/lokaler Datenträger“-Lösung ist LCR nur ein erster Schritt in Richtung verbesserter betrieblicher Kontinuität. LCR schützt zwar vor Ausfällen eines RAID-Arrays und von RAID-Controllern, aber mehrere simultane Abstürze von Festplatten oder Ausfälle von RAID-Controllern sind relativ selten. Meistens handelt es sich bei einem Ausfallszenario um den Zusammenbruch des gesamten Servers, was eine gute Überleitung zum nächsten Schritt für den Schutz von Exchange bietet.

Lokale Off-Host-Replikation von Drittanbietern

Um die Wiederherstellungsfunktionen von Exchange zu erweitern, haben Drittanbieter Produkte entwickelt, die die Off-Host-Replikation über die Exchange Protokolldateien nutzen, um eine Standbykopie der Exchange-Datenbank auf einem anderen Computer zu speichern. In diesem Fall führt die Datenschutz- oder Archivlösung eine vollständige ESE-Sicherung von Exchange auf einen anderen Computer durch und ruft dann Transaktionsprotokolle ab, sobald Exchange sie schließt. Sie fügt diese Transaktionen in die Exchange-Datenbankkopie ein, damit diese immer auf dem neuesten Stand ist. Wie bereits erwähnt, sind diese Protokolle relativ klein (5 MB in Exchange 2003 und 1 MB in Exchange 2007), damit die Protokolldateien nach der Sicherung auf den Off-Host-Server kopiert werden können, ohne die Leistung des Exchange-Servers zu verringern.

STUFE 3: NOTFALLWIEDERHERSTELLUNG UND HOHE VERFÜGBARKEIT

Notfallwiederherstellung ist die Möglichkeit, schnell wieder den Betrieb aufnehmen zu können, wenn das Hauptdatenzentrum plötzlich nicht mehr verfügbar ist. Exchange benötigt eine effektive Notfallwiederherstellung, weil heute viele Organisationen ohne E-Mail- und Kalenderfunktionen nicht mehr richtig arbeiten können.

Einige Unternehmen sagen sich, dass traditionelle Bandsicherungen, die an einem anderen Ort aufbewahrt werden, eine Form der Notfallwiederherstellung sind, aber wenn Ihr einziges Datenzentrum durch Feuer oder Überschwemmung zerstört wird, ist ein mit Bandspulen beladener Lkw von geringem Wert. Notfallwiederherstellung beinhaltet nicht nur, dass die Daten an einem anderen Ort aufbewahrt werden, sondern auch, dass die Technologien und Prozesse vorliegen, um die Anwendung wiederherzustellen und zum Laufen zu bringen. Um effektiv zu sein, müssen für eine Notfallwiederherstellung primäre und sekundäre Systeme physisch voneinander getrennt werden. Wie weit auseinander die Standorte liegen sollten, hängt von der Größe der Katastrophe ab, die Sie überwinden wollen. Wenn Sie sich am meisten Sorgen darum machen, dass Ihre Daten in Flammen aufgehen, reicht es, die Bänder in einem anderen Gebäude am selben Standort aufzubewahren. Infrastrukturkatastrophen, bei denen Züge oder Flugzeuge beteiligt sind, könnten jedoch einen Radius von einem Kilometer oder mehr betreffen. Viele Katastrophen sind regional: Überschwemmungen, Schneestürme, Erdbeben und sogar Stromausfälle. Aber auch die Kommunikation kann in Mitleidenschaft gezogen werden, angefangen von Problemen, durch die die Verbindung zu Ihrem ISP unterbrochen wird, bis zu Denial-of-Service-Angriffen und Internet-DoS-Angriffen, die allgemein darauf ausgerichtet sind, Unternehmen Schaden zuzufügen.

Ein praktischer Tipp: Wenn Ihre Organisation bereits über mehr als einen Standort mit IT-Personal verfügt, erfüllt einer dieser Standorte vielleicht Ihre Unternehmenskriterien für die Remotekontinuität, um Sie vor genau den gefürchteten Katastrophen zu schützen. Wenn Sie eigene Gebäude und eigenes Personal verwenden, ist dies weit weniger kostspielig als einen Notfallwiederherstellungsanbieter zu beauftragen oder Räume an einem neuen Standort anzumieten.

Ultimativ geht es bei der Notfallwiederherstellung auch um Wahrnehmung: Geben Sie Ihren Kunden die Gewissheit, das Sie immer noch im Geschäft sind. Ihre Kunden werden Verständnis dafür haben, wenn eine Katastrophe eine Stadt oder Region trifft, aber wenn Ihr Unternehmen nicht innerhalb von ein paar Tagen bis zu einer Woche wieder online ist, nehmen Kunden und Lieferanten u. U. das Schlimmste an. Viele Unternehmen scheitern aus diesem Grund. Der Kunde muss den Eindruck erhalten, dass der Geschäftsbetrieb nur kurzzeitig unterbrochen ist und Sie dabei sind, den Betrieb wiederherzustellen. Wie schnell Sie nach Meinung Ihrer Kunden wieder voll einsatzbereit sein sollten, hängt vom einzelnen Kunden ab: Verständlicherweise wird ein Kunde bei einem Finanzdienstleistungsinstitut weniger Geduld an den Tag legen als zum Beispiel bei einem Lieferanten von Büromöbeln.

Anforderungen an die Notfallwiederherstellung

Um in der Lage zu sein, Exchange nach einer Katastrophe wieder online zu bringen, müssen die Daten auf den sekundären Standort repliziert werden. Es müssen Replikationstechnologien eingesetzt werden, die die Daten auf einen laufenden Exchange-Server aufspielen und dann die Outlook-Clients benachrichtigen, dass ihre Postfächer verschoben wurden.

Die Replikation von Exchange ist, besonders über weite Entfernungen, nicht einfach. Es handelt sich um eine echte Transaktionsdatenbank, bei der die Reihenfolge der Schreibvorgänge extrem wichtig ist. Die Herausforderung wird dadurch noch verkompliziert, dass das Transportprotokoll, das Exchange zur Weiterleitung aller Transaktionen und Systeminformationen zwischen den Servern verwendet, SMTP ist. SMTP ist ein bandbreitenintensives Protokoll. Außerdem muss bei Exchange-Clustern alle 500 Millisekunden ein Signal zwischen Systemen gesendet werden. Wenn ein sekundärer Knoten dieses Signal nicht erhält, wird hierdurch u. U. der Start eines Failovers ausgelöst.

Die Schwierigkeit, diese Herausforderungen zu meistern, sind vielleicht ein Grund dafür, warum Microsoft sich erst jetzt mit Exchange 2007 dieses Problems annimmt. In Abwesenheit einer Microsoft-Lösung sind mehrere Drittanbieterlösungen entwickelt worden, um Exchange-Daten über host- oder arraybasierte Replikation zu replizieren.

Anbieter haben erkannt, dass ein Cluster durch die Verteilung der Knoten auf verschiedene Standorte erweitert werden kann. Dies wird als Stretchcluster bezeichnet. Heute werden Stretchcluster meistens über Datenreplikationsprodukte von Drittanbietern oder Produkte, die speziell für die Erweiterung eines Exchange-Knotens ausgelegt sind, implementiert. Dies kann mithilfe von MSCS erfolgen, aber die Subnetzanforderung über ein WAN ist relativ kompliziert. Clusterbildung und die Komplexitäten, zuverlässige Konnektivität hoher Bandbreite zu Remoterechenzentren bereitzustellen, erhöhen verständlicherweise die Kosten und den Personalbedarf, um Notfallwiederherstellungssysteme aufzubauen, zu verwalten und in regelmäßigen Abständen zu testen.

Fortlaufende Clusterreplikation

Mit Exchange 2007 erweitert Microsoft den Clustersupport mit fortlaufender Clusterreplikation. Durch CCR wird in LCR die Möglichkeit erweitert, zwei Kopien einer Exchange-Datenbank und der Transaktionsprotokolle zu speichern, um die gleiche Idee auf zwei Clusterknoten zu implementieren. Notfallwiederherstellung impliziert eine geografische Trennung primärer und sekundärer Systeme, und die Mehrfachkopiecluster von Microsoft werden bis zur Veröffentlichung Windows Server 2008 (früherer Codename „Longhorn“), der Stretchcluster ermöglicht, keine großen Entfernungen überbrücken können.

Die Technologie, die es MCC-Knoten ermöglicht, separate Kopien der Daten zu halten, wird als Majority Node Set (MNS) bezeichnet und bezieht sich auf den Wahlprozess, den die zwei oder mehr Knoten durchführen, um zu bestimmen, wer die Livekopie der Daten hält. Bei einem Ausfall halten die übrigen Knoten eine neue Wahl ab, um zu bestimmen, wer die Rolle des neuen primären Verarbeitungs-/Datenservers übernehmen soll. Unterstützt wird diese technische Demokratie durch CCR, das sicherstellt, dass jeder Knoten über eine aktuelle Datenbank verfügt. Exchange 2007-Cluster, die CCR verwenden, sind auf nur zwei Knoten beschränkt.

In größeren Konfigurationen konfigurieren Exchange-Server in der Regel die lokale Systemfestplatte auf dem Server und stellen dann über ein SAN (über SCSI, Glasfaser oder iSCSI-Festplattenarrays) eine Verbindung zur Exchange-Datenbank her. Bei einem MCC/MNS-Cluster ist eine interessante Frage, ob bei einer High-End-Exchange-Speicherung wieder auf lokale RAID-Arrays für jeden Knoten zurückgegriffen wird. Wenn der Zweck eines MNS-Clusters darin besteht, jedem Knoten die Fähigkeit zu geben, seinen eigenen getrennten Speicher zu halten, ist es dann immer noch sinnvoll, jeden Knoten auf ein SAN zeigen zu lassen, dessen Hauptzweck darin besteht, gemeinsamen Speicher bereitzustellen?

Bei einem normalen MCC-/MNS-Clusterszenario gäbe es wahrscheinlich den primären Knoten mit Speicher auf dem SAN und einen sekundären Clusterknoten mit lokalen Festplatten oder einem preisgünstigeren iSCSI-SAN. Dieser sekundäre Knoten könnte entfernt vom primären Datencenter an einem Ort sein, der nicht über SAN-Infrastruktur verfügt.

Unabhängig vom Resultat ist MCC, das MNS und CCR verwendet, ein weiterer Schritt nach oben in der Hierarchie der Redundanz und verbesserten Verfügbarkeit, weil mehrere Computer ein Failover haben können und die Daten auf getrennten Speicherelementen repliziert sind. Bis Windows Server 2008 auf den Markt kommt, befindet sich dies alles allerdings weiterhin in einem einzigen Datencenter. Windows Server 2008 unterstützt Stretchcluster, wodurch Knoten in einem MNS-Cluster geografisch so weit wie gewünscht getrennt werden können, solange die Netzwerklatenz zwischen Knoten weniger als 500 ms beträgt. Bis dahin (und danach) kann Clustertechnologie von Drittanbietern auf Microsoft MNS und CCR aufgesetzt werden, um die geografische Trennung bereitzustellen, die zum Ausdehnen von Clustern erforderlich ist, und eine effektive Notfallwiederherstellungslösung bereitzustellen.

Clusterbildung befindet sich am oberen Ende der Notfallwiederherstellungsfolge, und CCR ist entsprechend als eine Hochverfügbarkeitsfunktion von Exchange positioniert. Auch wenn diese Kombination erhöhten Kosten- und Personalaufwand erfordert, verspricht sie, eine interessante Lösung für Kunden zu sein, die eine homogene Microsoft-Umgebung betreiben wollen.

Betriebliche Remotekontinuität für Anwendungen von Drittanbietern

Es besteht kein Zweifel daran, dass die Microsoft-Lösung und Erweiterungen von Drittanbietern am oberen Ende der Wiederherstellungsfolge angesiedelt sein werden, wenn die Lösung verfügbar wird. Automatisches Failover innerhalb von Sekunden – besser geht es nicht. Nicht jedes Unternehmen benötigt jedoch dieses Maß an Verfügbarkeit und Geschäftskontinuität, noch kann es sich jedes Unternehmen leisten, die hohen Summen zu investieren, die hierfür erforderlich sind. Für viele Unternehmen liefert eine zuverlässige Lösung, die Exchange vollständig in Minuten wiederherstellt, die gesamte erforderliche betriebliche Kontinuität.

Ein Beispiel: Mimosa Systems, Inc. erweitert die betriebliche Kontinuität innerhalb eines einzigen Datencenters auf Remotekontinuität. An einem Remotestandort bewahrt Mimosa DR eine Kopie von Exchange auf, hält sie mit den Transaktionsprotokollen des primären Exchange-Servers auf dem neuesten Stand, und ist immer in der Lage, diese Livekopie für den Exchange-Standbyserver zur Verfügung zu stellen. Der Exchange Server am Remotestandort verwendet Standardserverhardware und genau wie bei der Implementierung eines einzelnen Datencenters sorgen Sie dafür, dass es im Notfall sofort aktiviert werden kann. Sollte ein Notfall eintreten, initiiert ein Bediener am Remotestandort das Failover und führt es durch, einschließlich der Bereitstellung der Standby-Datenbankdateien, der erneuten Zuordnung von Postfächern und der Outlook-Profile. Beachten Sie, dass Drittanbieterlösungen dieser Art den Supportbegrenzungen unterliegen, die im Knowledge Base-Artikel Microsoft-Supportrichtlinie für Drittanbieterprodukte, die Exchange-Datenbankinhalte verändern oder extrahieren definiert sind.

Schlussbemerkung

Exchange-Datenschutz ist als eine Folge von Technologien und Verfahren verfügbar, die abhängig von Kosten und Funktionen in drei Ebenen gruppiert werden können. Wenn Sie sich über Anforderungen in Bezug auf den Schutz von Exchange-Daten Gedanken machen, sollten Sie sich überlegen, wie viele Ausfallzeiten alle Beteiligten akzeptieren können. Größere Leistung und schnellere Wiederherstellung kosten mehr, und die Preise für High-End-Optionen liegen im sechsstelligen Bereich. Es gibt preisgünstigere Lösungen, die jedoch nicht ganz das höchste Maß an Verfügbarkeit erreichen. Entscheiden Sie sich für die Option, die den Anforderungen Ihrer Organisation entspricht.

Service Pack 1 für Exchange 2007

Service Pack 1 (SP1) für Exchange 2007, das sich momentan in der Betatestphase befindet, enthält eine Reihe von Funktionen, die Administratoren bisher fehlten, darunter Verbesserungen bei OWA, zusätzliche GUI-Funktionen in der Konsole und mehr.

Besonders interessant für Administratoren, die Wiederherstellungslösungen planen, ist eine dritte Verfügbarkeitslösung in Exchange 2007 SP1, um LCR und CCR zu ergänzen: Sekundäre ununterbrochene Replikation (Secondary Continuous Replication, SCR). Dies ist eine mittlere Lösung von Microsoft, die eine höhere Wiederherstellbarkeit ohne die Komplexität einer „hohen Verfügbarkeit“ bietet.

SCR ermöglicht die Replikation der Exchange-Datenbank und der Transaktionsprotokolle auf einem anderen Exchange-Server als dem, auf dem sich Ihre Postfächer normalerweise befinden. Das SCR-Ziel kann lokal oder entfernt und ein Exchange-Standbyserver oder ein Cluster sein. SCR erfordert jedoch keinen Cluster an beiden Orten und unterscheidet sich von CCR dadurch, dass das Ziel eine Standbyumgebung und das Failover ein manueller Prozess ist. Beachten Sie, dass Sie nach wie vor die erste große Kopie (also eine vollständige Sicherung) selbst auf den anderen Computer bringen müssen. Sie müssen eine solche große Replikation u. U. von Zeit zu Zeit durchführen und sich dabei der Folgen für Ihr Netzwerk bewusst sein, genau wie bei CCR und Lösungen von Drittanbietern. Meiner Meinung nach werden SCR und CCR sowie Add-On-Produkte, die ähnliche und sogar mehr Funktionen bieten, in Zukunft eine weite Verbreitung in Unternehmen finden.

Lee Benjamin ist Geschäftsführer von ExchangeGuy Consulting Services, ein Consultingunternehmen, das direkt mit Kunden zusammenarbeitet und Microsoft-Partner berät. Er ist Vorsitzender der größten Exchange-Benutzergruppe der Welt, ExchangeServerBoston, und Direktor der BostonUserGroups. Außerdem ist Lee Benjamin MVP für Exchange, ein Microsoft-zertifizierter Schulungsleiter und regelmäßiger Referent bei Konferenzen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.