(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Best Practices für die Verwendung des Volumeschattenkopie-Diensts (VSS) mit Exchange Server 2003

 

Letztes Änderungsdatum des Themas: 2005-10-18

In Microsoft® Exchange Server 2003 wird der im Betriebssystem Microsoft Windows Server™ 2003 enthaltene Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS) verwendet, um Volumeschattenkopien von Exchange Server 2003-Datenbanken und -Transaktionsprotokolldateien zu erstellen. Mithilfe von VSS können Datenbanken unabhängig von ihrer Größe u. U. innerhalb von Minuten wiederhergestellt werden. Wie schnell die Wiederherstellung erfolgt, hängt in erster Linie von den Eigenschaften der Anbieterkomponente der VSS-Lösung ab.

Da es viele VSS-Strategien gibt, müssen Sie die Auswirkungen der einzelnen Lösungen auf Kapazität, Leistung und Wiederherstellung kennen und testen, um sicherzustellen, dass Sie über die für eine erfolgreiche Bereitstellung benötigten Daten verfügen. Außerdem müssen Sie dafür sorgen, dass potenzielle Lösungen innerhalb des VSS-Frameworks funktionieren. Dieser Artikel enthält Informationen zum Auswählen, Testen, Bereitstellen und Überwachen einer VSS-Lösung für Exchange Server 2003.

VSS umfasst eine Reihe von COM-APIs zur Implementierung eines Frameworks, mit dessen Hilfe Volumesicherungen ausgeführt werden können, während Anwendungen in einem System weiterhin Daten auf die Volumes schreiben. Anforderer, Verfasser und Anbieter kommunizieren innerhalb des VSS-Frameworks miteinander, um Schattenkopien von Volumes zu erstellen und wiederherzustellen. In einer Schattenkopie eines Volumes werden alle zu einem genau definierten Zeitpunkt auf dem Volume enthaltenen Daten dupliziert.

Der Sicherungsvorgang umfasst die folgenden Schritte:

  1. Der Anforderer leitet den Sicherungsvorgang ein. Der Anforderer weist den Verfasser an, ein Dataset für die Sicherung vorzubereiten.
  2. Der Verfasser bereitet die Daten für die Sicherung vor. Von Exchange Server 2003 und anderen Anwendungen werden Verfasser implementiert, die Daten entsprechend den besonderen Anforderungen der Anwendung vorbereiten. Wenn das Dataset bereit ist, benachrichtigt der Verfasser den Anforderer, dass das Dataset gesichert werden kann.
  3. Der Anbieter interagiert mit dem Datenträgersystem und verwaltet die Schattenkopien. Auf Anweisung des Anforderers erstellt der Anbieter eine Schattenkopie.
  4. Der Anforderer meldet dem Verfasser, ob die Sicherung erfolgreich ausgeführt wurde oder fehlgeschlagen ist, und schließt den Sicherungsvorgang ab.

Durch die Trennung der einzelnen Funktionen von Anforderer, Verfasser und Anbieter ist im VSS-Framework jede Komponente von den anderen unabhängig. Ein einzelner Anforderer kann mit unterschiedlichen Anbietern oder mit mehreren Verfassern interagieren. Weitere Informationen zu Anforderern, Verfassern und Anbietern finden Sie unter Basic VSS Concepts (in englischer Sprache).

Der Exchange-Verfasser wird automatisch mit Exchange Server 2003 installiert. Anforderer können nur auf den Exchange-Verfasser zugreifen, wenn Exchange Server 2003 unter Windows Server 2003 installiert ist. Wenn Exchange Server 2003 unter Microsoft Windows® 2000 Server installiert ist, sind keine VSS-Sicherungen für Exchange Server 2003 verfügbar.

Auf Anweisung eines Anforderers bereitet der Exchange-Verfasser Exchange-Datenbanken für die Sicherung vor. Zu diesem Zweck hält der Verfasser alle E/A-Schreibzugriffe auf die Datenbanken bis zu 20 Sekunden lang an. Dieser Vorgang wird als Fixierung der Datenbanken bezeichnet. Der Anbieter muss die Schattenkopie innerhalb dieses Zeitfensters fertig stellen können. Andernfalls wird die Sicherung abgebrochen. Nach Abschluss der Sicherung reaktiviert der Verfasser die Datenbanken, und die regulären E/A-Vorgänge werden wieder aufgenommen.

noteAnmerkung:
Von Windows-Sicherung für Windows Server 2003 kann der standardmäßige softwarebasierte Windows-VSS-Anbieter verwendet werden, um generische VSS-Sicherungen von Datenträgervolumes und Dateien zu erstellen. Allerdings kann Windows-Sicherung nicht mit dem Exchange-Verfasser kommunizieren und sollte daher nicht verwendet werden, um VSS-Sicherungen von Exchange-Datenbankdateien zu erstellen. In diversen nicht von Microsoft stammenden Sicherungsanwendungen sind Anforderer implementiert, die mit dem Exchange-Verfasser zusammenarbeiten.

Ein Anbieter kann Schattenkopieanforderungen auf zahlreiche verschiedene Arten ausführen. Obwohl der Exchange-Verfasser nicht erkennt, auf welche Weise der Anbieter eine Schattenkopie erstellt, müssen Sie wissen, wie der Anbieter für Ihre Lösung funktioniert, damit Sie Leistung und Kapazität planen können. Es gibt zwar keine standardisierte Definition oder Namenskonvention für diese Sicherungsmethoden, jedoch kann die Mehrheit der Sicherungsmethoden in zwei Kategorien unterteilt werden, nämlich Klonschattenkopien und Snapshotschattenkopien.

Bei einem Klon handelt es sich um eine vollständige Kopie der Volumes in einem Schattenkopiesatz. Ein Schattenkopiesatz ist eine Gruppe von Volumeschattenkopien, die gleichzeitig synchronisiert werden.

Ebenso wie eine normale Kopie ist ein Klon von den ursprünglichen Daten unabhängig. Auch wenn alle ursprünglichen Daten verloren gehen, bleibt der Klon intakt. Ein Snapshot hingegen ist von den ursprünglichen Daten nicht vollständig unabhängig. Weitere Informationen zu Snapshots finden Sie weiter unten in diesem Artikel unter "Snapshotschattenkopien".

Bei der Verwendung von Klonen ist eine Kapazitätsplanung unverzichtbar. Damit eine wiederherstellbare Kopie für den Fall verfügbar ist, dass während einer Sicherung ein Fehler auftritt, müssen Sie ein N+1-Schema verwenden. Dabei steht N für die Anzahl von Sicherungsklonen, die jederzeit zur Wiederherstellung verfügbar sein sollen. Wenn Sie z. B. nur eine Sicherung anlegen, benötigen Sie zwei (1+1) Zielklone, zwischen denen gewechselt werden kann, um Datenverluste zu verhindern, falls während einer Sicherung ein Fehler auftritt.

  • Der Hersteller des Anbieters bestimmt, wie die Erstellung von Klonen in einer bestimmten Lösung implementiert wird.

Spiegeln   Von einigen Lösungen werden vorab Spiegelkopien erstellt. Diese Spiegelkopien werden anschließend zur Erstellung einer Sicherung abgetrennt, sodass Sie über eine schreibgeschützte Kopie und ein aktives Produktionsvolume verfügen. Bei dieser Strategie gibt es während der Sicherung und der Prüfsummenintegritätsprüfung nahezu keine Auswirkungen auf die Produktions-LUNs (Logical Unit Number, logische Gerätenummer). Allerdings entsteht bei dieser Strategie vor der Sicherung eine erhebliche I/O-Belastung der Produktions-LUNs.

Wenn Sie mehrere Klone im Wechsel verwenden, müssen Sie Zeit für die Neusynchronisierung eines nicht mehr benötigten Klons mit der Produktions-LUN einplanen. Zur Wiederherstellung wird die schreibgeschützte Kopie unter Umständen erneut mit der Produktions-LUN synchronisiert. Davon sind andere Onlinespeichergruppen, die dieselbe Produktions-LUN verwenden, solange betroffen, bis sämtliche Daten kopiert sind. Von einigen Speicherarrays werden während der Wiederherstellung einfach die Zeiger für die schreibgeschützte Kopie geändert, wodurch der Schreibschutz aufgehoben wird.

Klonen   Bei einigen Lösungen wird während der Sicherung ein Klon erstellt. Dabei müssen alle Daten in der LUN auf eine andere LUN kopiert werden. Anschließend werden diese Daten als schreibgeschützt gekennzeichnet. Bei dieser Strategie wird zunächst zwar weniger Kapazität beansprucht, jedoch müssen alle Daten während der Sicherung kopiert werden. Sie müssen bei dieser Strategie wissen, wie viele Gigabytes pro Stunde ein bestimmter Speichercontroller bewältigen kann und mit welchen Auswirkungen auf die LUNs der Produktionsdatenbank während des Kopiervorgangs zu rechnen ist. Dadurch sind Sie in der Lage, die LUNs im Hinblick auf maximalen Durchsatz zu entwerfen und den Vorgang zeitlich so zu planen, dass es nur zu minimalen Auswirkungen auf die Produktions-LUNs kommt.

Der wichtigste Unterschied zwischen einem Klon und einem Snapshot besteht darin, dass ein Snapshot von den ursprünglichen Daten nicht vollständig unabhängig ist. Grundsätzlich wird zum Erstellen von Snapshots zu einem bestimmten Zeitpunkt eine Markierung definiert und sichergestellt, dass für die Daten ein Rollback bis zu diesem Zeitpunkt ausgeführt werden kann. Sie können mehrere Snapshots verwalten, die i. d. R. sehr viel weniger zusätzlichen Speicherplatz belegen als Klone.

Snapshots können auf unterschiedliche Weise erstellt werden. Die gängigste Methode wird als Kopie bei Schreibvorgang bezeichnet.

Bei dieser Methode wird zu einem bestimmten Zeitpunkt ein Snapshot definiert, und anschließend wird das ursprüngliche Dataset auf Änderungen überwacht. Jede Änderung wird an einem separaten Ort aufgezeichnet bzw. nachverfolgt. Auf diese Weise kann ein Snapshot im Laufe der Zeit größer werden, insbesondere dann, wenn ein häufig geändertes Dataset zugrunde liegt.

Im Snapshot-Manager stehen unterschiedliche Ansichten des Datasets zur Verfügung, die i. d. R. so dargestellt werden, als ob es sich um verschiedene vollständige Sicherungen der Daten handeln würde. Außerdem kann im Snapshot-Manager bei Bedarf zu einer beliebigen verfügbaren Ansicht der Daten gewechselt werden, wodurch in gewissem Sinne die Daten wiederhergestellt werden.

Bedenken Sie, dass ein Snapshot keine unabhängige Kopie der Daten ist. Falls die ursprünglichen Daten zerstört werden, sind die Snapshotdaten nutzlos, denn sie enthalten nur die zuletzt vorgenommenen Änderungen.

Bei dieser Sicherungsmethode verfügen Sie über einen Rollbackmechanismus, nicht jedoch über eine wirkliche Sicherung der Daten. Der Vorteil dieser Sicherungsmethode besteht darin, dass nur die Änderungen und nicht alle Daten auf den Datenträger geschrieben werden, sodass der Snapshot sehr schnell erstellt werden kann. Ein Nachteil ist, dass Sie über keine wiederherstellbare Sicherung verfügen, wenn die Originaldaten beschädigt werden.

Da eine Snapshotsicherung keine echte Sicherung darstellt, wird bei den meisten Lösungen ein zusätzlicher Schritt implementiert, bei dem die Snapshotsicherung auf Band gestreamt wird. Das Streaming auf Band bedeutet eine starke sequenzielle E/A-Belastung für die Produktionsdatenbank-LUNs.

Im normalen Betrieb erfolgen E/A-Zugriffe auf einen Datenträger, der Exchange-Datenbanken hostet, wahlfrei, also direkt, bei einer Streamingsicherung hingegen sequenziell. Wenn Arbeitsauslastungen mit sequenziellem Zugriff und solche mit wahlfreiem Zugriff gemischt werden, wird eine effiziente Zwischenspeicherung erschwert, und es kann zu übermäßig langen Wartezeiten und einer erheblichen Reduzierung des maximalen E/A-Durchsatzes kommen. Dies ist ein wichtiger Aspekt, wenn Sie beabsichtigen, als Sicherungsquelle für Exchange Server 2003 ausschließlich Snapshots zu verwenden.

In vielen Fällen beabsichtigten Exchange Server-Administratoren, diesem Problem durch die Ausführung von Streamingsicherungen in Zeiten mit geringer Auslastung zu begegnen. Zwar kann dies eine wirkungsvolle Strategie sein, jedoch ist nicht immer klar erkennbar, wann es tatsächlich Zeiten mit geringer Auslastung gibt.

Außer für die Bearbeitung von Clientanforderungen benötigt eine Exchange-Datenbank auch Zeit für die Ausführung der Onlinewartung. Die Wartung kann vom Administrator geplant werden, jedoch nimmt sie nicht selten mehrere Stunden pro Tag in Anspruch. Selbst bei einer geringen Endbenutzerauslastung kann die Datenbank durch Wartungstasks ausgelastet sein. Des Weiteren müssen Sie die zusätzliche Serverauslastung durch die Vorbereitung oder Ausführung von Sicherungen berücksichtigen. Es hat sich bewährt, jegliche Überschneidung der Sicherungszeitfenster mit der Onlinewartung oder mit Zeiten mit maximalem Aufkommen an Benutzeranforderungen zu vermeiden.

Zu welchen Zeiten tatsächlich die Datenbankaktivität am höchsten ist, können Sie nur feststellen, indem Sie über einen Grundzeitraum von mindestens einigen Tagen das Auslastungsprofil der Datenbanken erfassen.

Eine Exchange-Datenbankdatei ist in eine Reihe von Seiten gleicher Größe unterteilt. Jede dieser Seiten enthält eine Prüfsumme, anhand derer die Integrität der Exchange-Daten auf der Seite überprüft wird. Wenn Daten auf der Seite außerhalb der Kontrolle des Exchange-Servers geändert werden, z. B. durch einen Datenträger- oder Controllerfehler, wird dieses Problem bei der Überprüfung der Prüfsumme erkannt. Auch in Exchange-Transaktionsprotokolldateien ist die Überprüfung anhand von Prüfsummen implementiert, allerdings nicht auf Seitenbasis. Daher können auch Beschädigungen von Transaktionsprotokolldateien erkannt werden.

Microsoft unterstützt eine Streamingsicherungs-API zum Sichern von aktiven Exchange-Datenbanken. Diese API ist in Windows-Sicherung in allen Versionen von Windows und Exchange Server sowie in zahlreichen nicht von Microsoft stammenden Sicherungsanwendungen implementiert.

noteAnmerkung:
Damit von Windows-Sicherung Exchange-Onlinesicherungen über die Streaming-API ausgeführt werden können, müssen Sie das Exchange-Administrationsprogramm auf einem Computer mit Windows Server installieren.

Im Wesentlichen wird bei einer Streamingsicherung eine Datenbank Seite für Seite auf das Sicherungsmedium kopiert. Während der Sicherung wird die Prüfsumme jeder Seite überprüft, und die Sicherung wird nur dann erfolgreich abgeschlossen, wenn alle Seiten in der Datenbank die Überprüfung bestehen. Zu sichernde Transaktionsprotokolldateien werden ebenfalls überprüft. Dadurch wird garantiert, dass die letzte Sicherung einer bestimmten Datenbank fehlerfrei ist.

Beim Erstellen einer Schattenkopie gibt es keine Möglichkeit, die Seitenintegrität einer Datenbank oder von Transaktionsprotokollen zu überprüfen. Aus diesem Grund muss die Prüfsummenintegritätsprüfung nach der Erstellung der Schattenkopie ausgeführt werden. Gemäß den Microsoft-Richtlinien liegt die Verantwortung für diese Überprüfung beim Anforderer.

Der Anforderer, also die Sicherungsanwendung, führt die Prüfsummenintegritätsprüfung für die Datenbank und die Protokolldateien nach Abschluss der Sicherung aus. Die Belastung der Datenbank- und Transaktionsprotokoll-LUNs (Logical Unit Number, logische Gerätenummer) durch die Streaming-E/A-Vorgänge ist sehr hoch. Der Anforderer führt zur Prüfsummenintegritätsprüfung die Datenbankdienstprogramme für Exchange Server (Eseutil.exe) aus. Dabei werden alle Sicherungsdateien gelesen, um die Integrität jeder einzelnen Datenbankseite und Transaktionsprotokolldatei zu überprüfen.

Standardmäßig wird Eseutil.exe so schnell ausgeführt, wie die Daten vom Speicher gelesen werden können, Für den typischen Klon, der von den Produktions-LUNs unabhängig ist, ist dies optimal. Allerdings sind nicht alle VSS-Sicherungssätze von den ursprünglichen Daten unabhängig. Weitere Informationen zu den verschiedenen Typen von VSS-Sicherungen finden Sie unter "VSS-Sicherungsmethoden" weiter oben in diesem Artikel.

In bestimmten Fällen kann es hilfreich sein, die E/A-Rate der Prüfsummenintegritätsprüfung durch Hinzufügen einer künstlichen Pause nach einer bestimmten Anzahl von E/A-Vorgängen einzuschränken. Wenn Sie Exchange Server 2003 mit Service Pack 2 (SP2) verwenden, können Sie mit der folgenden Option nach einer bestimmten Anzahl von E/A-Vorgängen eine Pause von 1 Sekunde hinzufügen:

/p<x>

Dabei steht x für die Anzahl der E/A-Vorgänge, nach denen die Pause eintritt. Mit dem folgenden Befehl wird z. B. nach jeweils 100 E/A-Vorgängen eine künstliche Pause von 1 Sekunde hinzugefügt:

eseutil /K /p100    

Diese E/A-Einschränkung wird nur für die Überprüfung von Datenbankdateien implementiert, nicht für die Überprüfung von Transaktionsprotokolldateien.

Beim Erarbeiten der Sicherungsverfahren müssen Sie die durch die Prüfsummenintegritätsprüfung entstehende E/A-Last sorgfältig abwägen und einplanen. Diese Überprüfung ist ein wichtiger Bestandteil des Sicherungsvorgangs und darf keinesfalls außer Acht gelassen werden. Allerdings können Sie die Überprüfung vorübergehend zurückstellen, wobei die im Microsoft Knowledge Base-Artikel 822896, Exchange Server 2003-Dienste für Datensicherung und Volumeschattenkopie, beschriebenen strengen Richtlinien eingehalten werden müssen. In diesem Artikel ist genau beschrieben, welche Anforderungen im Hinblick auf die Prüfsummenintegritätsprüfung ein Anforderer erfüllen muss, um den Microsoft-Unterstützungsempfehlungen zu entsprechen.

Ein Snapshot kann nicht völlig unabhängig von den Produktions-LUNs sein. Daher hat die Ausführung der Prüfsummenüberprüfung für einen Snapshot in jedem Fall Auswirkungen auf die Produktions-LUNs. Die Prüfsummenüberprüfung bei einem Klon hat nicht unbedingt Auswirkungen auf das Produktionssystem. Dies hängt davon ab, wo der Klon gespeichert und wie auf diesen zugegriffen wird.

Sie müssen die E/A-Last und die Auswirkungen der Überprüfung sowohl auf die Endbenutzer als auch auf die reguläre Datenbankwartung sorgfältig überwachen. Durch einen wohlüberlegten Einsatz des Einschränkungsmechanismus von Eseutil.exe können Sie u. U. auch ein ausgewogeneres Verhältnis zwischen der Überprüfungsleistung und anderen E/A-Anforderungen erzielen.

Für die meisten Administratoren liegt der wichtigste Vorteil einer VSS-Sicherungslösung darin, dass große Datenmengen schnell wiederhergestellt werden können. Am nützlichsten sind VSS-Lösungen in Bereitstellungen mit umfangreichen Datenbanken, die in weniger als 60 Minuten wiederherzustellen sein müssen. Diese Anforderung übersteigt die Möglichkeiten der gegenwärtig erhältlichen Streaming- oder Bandsicherungslösungen. Eine VSS-Lösung bietet die folgenden Vorteile:

  • Kürzere Wiederherstellungszeit
  • Die Fähigkeit, innerhalb eines typischen Sicherungszeitfensters wesentlich mehr Daten zu sichern und wiederherzustellen als bei einer herkömmlichen Streaming-Onlinesicherung

Häufig wird irrtümlich angenommen, mit VSS-Lösungen könnten Sicherungen praktisch sofort und ohne Auswirkungen auf den Produktionsserver ausgeführt werden. Aus Sicht einer Anwendung mag das stimmen, jedoch kann eine VSS-Sicherung genauso viel Vorbereitung erfordern und eine ebenso hohe Auslastung verursachen wie eine Streamingsicherung, insbesondere bei Verwendung von Klonen. Beim Sichern und Wiederherstellen auf Datenträger erzielen Sie u. U. einen höheren Durchsatz und eine höhere Leistung als mit einer Bandlösung. Dies ändert jedoch nichts an der Tatsache, dass die Daten von einem Ort an einen anderen kopiert werden müssen, und zwar unabhängig von der gewählten Sicherungsmethode. Mit einer VSS-Lösung kann dieser Kopiervorgang optimiert und geplant werden, aber er bleibt unumgänglich, und beim Kopieren von großen Datenmengen werden immer Systemressourcen in Anspruch genommen.

Die E/A-Vorgänge von Exchange Server im Produktionssystem umfassen meist viele kleine wahlfreie E/A-Transaktionen in den Datenbanken. Während der Sicherung und Wiederherstellung kann der E/A-Durchsatz des Speichersubsystems zu einem Engpass werden, durch den die Sicherungs- und Wiederherstellungsgeschwindigkeit künstlich eingeschränkt wird. Stellen Sie sicher, dass Durchsatz und Lastenausgleich für die gewünschten Sicherungen und Wiederherstellungen ausreichen.

Jede Speichergruppe von Exchange Server 2003 besteht aus bis zu fünf Datenbanken, Transaktionsprotokolldateien und einer Prüfpunktdatei. In VSS werden die Datenbank (EDB) und die Streamingdateien (STM) als die Datenbankkomponente betrachtet, die Transaktionsprotokolle (LOG) und Prüfpunktdateien (CHK) hingegen als Bestandteil der Protokollkomponente.

Wenn Sie VSS als Sicherungslösung verwenden, sollten Sie das Betriebssystem Windows Server 2003 mit Service Pack 1 (SP1) verwenden. Erkundigen Sie sich beim Hersteller Ihrer Speicherlösung, ob Windows Server 2003 mit SP1 unterstützt wird. Für den Fall, dass Sie nicht auf Windows Server 2003 mit SP1 aktualisieren können, finden Sie im Microsoft Knowledge Base-Artikel 833167, Update-Paket für Volumeschattenkopie-Dienst von Windows Server 2003 verfügbar, Informationen zu einem VSS-Updatepaket. Eine Liste zusätzlicher Hotfixes, die Sie anwenden müssen, wenn Sie nicht Windows Server 2003 mit SP1 verwenden, finden Sie weiter unten unter "Anhang".

Sie müssen sicherstellen, dass eine potenzielle VSS-Lösung für Exchange Server 2003 dem VSS-Framework entspricht und die Lösung unterstützt wird. Informationen zu unterstützten VSS-Lösungen finden Sie im Microsoft Knowledge Base-Artikel 822896, Exchange Server 2003-Dienste für Datensicherung und Volumeschattenkopie.

Die Ausführung der Prüfsummenintegritätsprüfung ist ein E/A- und speicherintensiver Vorgang. Es wird empfohlen, diesen Vorgang bei eigenständigen Exchange-Servern und Exchange-Clusterservern auf einen Sicherungsserver zu verlagern, der die schreibgeschützte Schattenkopie bereitstellt und die Prüfsummenintegritätsprüfung an dieser ausführt. Nach Möglichkeit sollten Sie die Prüfsummenintegritätsprüfung stets an Schattenkopien ausführen, die nicht auf den gleichen physikalischen Datenträgern gehostet werden wie die Produktions-LUNs.

Sie können für den gesamten Server oder eine einzelne Speichergruppe eine vollständige Sicherung, eine Kopiesicherung, eine differenzielle oder eine inkrementelle Sicherung verwenden. Weitere Informationen zu VSS-Sicherungsarten finden Sie unter Backup Operations (in englischer Sprache).

Vollständige Sicherung   Verwenden Sie die vollständige Sicherung für Exchange Server-Bereitstellungen. Bei dieser Sicherungsart werden alle Datenbanken, Transaktionsprotokolle und Prüfpunktdateien in einer Speichergruppe gesichert. Nach der Sicherung werden die Protokolldateien abgeschnitten.

Beim Protokolldatei-Abschneideverfahren werden überschüssige Transaktionsprotokolldateien gelöscht, die nicht zur Wiederherstellung oder für den Rollforward der letzten Sicherung benötigt werden. Vor dem Abschneiden der Protokolldateien müssen Sie die Prüfsummenintegrität der letzten Sicherung überprüfen. Beim Abschneidevorgang werden Protokolldateien entfernt, die für einen Rollforward des Systems mit einer Sicherung benötigt werden, die vor der letzten Sicherung angelegt wurde. Obwohl frühere Sicherungen durch den Abschneidevorgang nicht ungültig werden, können Sie die Datenbank nach dem Abschneidevorgang nur bis zu dem Zeitpunkt wiederherstellen, zu dem die frühere Sicherung erstellt wurde.

Kopiesicherung   Bei einer Kopiesicherung werden die gleichen Schritte ausgeführt wie bei einer vollständigen Sicherung, allerdings werden die Transaktionsprotokolldateien nicht abgeschnitten. Mithilfe einer Kopiesicherung können Sie eine Kopie der Datenbank für Test- oder Analysezwecke erstellen.

Inkrementelle Sicherung   Für eine inkrementelle Sicherung ist Exchange Server 2003 mit Service Pack 1 (SP1) oder höher erforderlich. Bei der inkrementellen Sicherung werden die Transaktionsprotokolle gesichert, um Änderungen aufzuzeichnen, die seit der letzten inkrementellen oder vollständigen Sicherung vorgenommen wurden. Anschließend werden die Transaktionsprotokolle abgeschnitten. Zum Wiederherstellen der Daten aus einer inkrementellen Sicherung müssen Sie zuerst die letzte vollständige Sicherung und anschließend alle inkrementellen Sicherungen wiederherstellen. Eine inkrementelle Sicherung nimmt weniger Zeit in Anspruch, allerdings kann es dabei zu einer längeren Wiederherstellungs- und Protokollwiedergabezeit kommen.

Differenzielle Sicherung   Für eine differenzielle Sicherung ist Exchange Server 2003 mit SP1 oder höher erforderlich. Bei einer differenziellen Sicherung werden die Transaktionsprotokolle gesichert, um Änderungen aufzuzeichnen, die seit der letzten vollständigen Sicherung vorgenommen wurden. Die Transaktionsprotokolle werden nicht abgeschnitten. Zum Wiederherstellen der Daten aus einer differenziellen Sicherung müssen Sie zuerst die letzte vollständige Sicherung und anschließend die aktuelle differenzielle Sicherung wiederherstellen. Eine differenzielle Sicherung nimmt weniger Zeit in Anspruch, allerdings geschieht dies auf Kosten von Kapazität und Wiederherstellungszeit.

Bei einer Schattenkopiesicherung werden i. d. R. die folgenden Phasen durchlaufen, die vom Anforderer und Verfasser verwaltet werden:

  • Synchronisieren   Der vorherige Schattenkopiesatz wird vom Sicherungsserver entfernt, und die Synchronisierung mit der Produktions-LUN wird ausgeführt.
  • Aufteilen   Schreibvorgänge auf den Quell-LUNs werden fixiert, wenn die Schattenkopien synchronisiert werden, die Synchronisierung der Schattenkopien wird aufgeteilt, und die Schreibvorgänge für die Quell-LUN werden wieder aufgenommen.
  • Transportieren und Prüfsumme   Die Schattenkopiedaten und Transaktionsprotokoll-LUNs werden auf den Bereitstellungshost transportiert und dort bereitgestellt. Die Prüfsummenintegritätsprüfung wird am Schattenkopiesatz ausgeführt. Weitere Informationen zur Prüfsummenintegritätsprüfung finden Sie weiter oben in diesem Artikel unter "Exchange-Anforderer und Prüfsummenintegritätsprüfung".
  • Abschneiden der Protokolldateien   Die Sicherung wird abgeschlossen, indem Transaktionsprotokolle für die Speichergruppe bei Erfolg abgeschnitten werden, und die vollständige Sicherung wird als abgeschlossen gekennzeichnet.

Sie können eine ganze Speichergruppe wiederherstellen. Sie können aber auch eine oder mehrere in der Speichergruppe enthaltene Datenbanken wiederherstellen, wenn die Datenbanken auf separaten LUNs gehostet werden. Dies ist jedoch nicht empfehlenswert.

Bevor Sie auch nur eine Datenbank wiederherstellen können, müssen Sie alle Datenbanken in der Speichergruppe offline schalten. Nach Abschluss der der Wiederherstellung wird dann die automatische Datenbankwiederherstellung (Wiedergabe der Transaktionsprotokolldatei) für die gesamte Speichergruppe aufgerufen, indem eine beliebige Datenbank in der Speichergruppe bereitgestellt wird.

Damit diese automatische Wiederherstellung erfolgreich ausgeführt wird, müssen mindestens die folgenden Bedingungen erfüllt sein:

  • Die Namen der Datenbankdateien und die logischen Dateipfade müssen mit denen übereinstimmen, die zum Zeitpunkt der Sicherung verwendet wurden. Wenn z. B. die Dateinamen Priv1.edb und Priv1.stm lauteten und die Dateien im Pfad D:\Databases gespeichert waren, muss auch der Wiederherstellungspfad D:\Databases lauten, und die Dateinamen dürfen nicht geändert werden.
  • Das Präfix der Speichergruppe muss mit den Dateinamen wiederzugebender Transaktionsprotokolldateien übereinstimmen.
  • Wenn Sie Daten auf dem ursprünglichen Server wiederherstellen, sind diese Bedingungen automatisch erfüllt, es sei denn, Sie haben die Datenbankpfade seit der Erstellung der Sicherung geändert.
  • Bei einigen VSS-Anforderern ist eine Wiederherstellung auf alternativen Servern zulässig. Dies kann zum Bereitstellen von Datenbanken auf Laborservern sowie in erweiterten Wiederherstellungsszenarien nützlich sein, in denen der ursprüngliche Server nicht verfügbar ist. Weitere Informationen zum Sichern und Wiederherstellen von Exchange Server 2003 finden Sie im Exchange 2003-Handbuch zur Wiederherstellung nach Datenverlust.

Die Wiederherstellung kann auf zwei Arten erfolgen:

  • Rollforward-Wiederherstellung   Eine Rollforward-Wiederherstellung ist eine Wiederherstellung bis zum Ausfallzeitpunkt. Diese kann ausgeführt werden, wenn die aktuelle Protokoll-LUN verfügbar ist. In diesem Fall können Sie die Datenbankdateien, nicht jedoch die Transaktionsprotokolldateien aus der Sicherung wiederherstellen und die aktuellen Protokolle auf dem Server verwenden, um ein Rollforward der Datenbank auszuführen. Wenn alle seit dem Zeitpunkt der Sicherung generierten Protokolldateien verfügbar sind, gehen bei der Wiederherstellung aus der Sicherung keine Daten verloren.
  • Zeitpunktwiederherstellung   Bei einer solchen Wiederherstellung werden nur die Daten der letzten Sicherung wiederhergestellt. Alle neueren Daten gehen verloren. Bei der Zeitpunktwiederherstellung werden nur die Transaktionsprotokolldateien verwendet, die Teil des Sicherungssatzes sind. Seit dem Zeitpunkt der Sicherung generierte zusätzliche Protokolldateien werden nicht verwendet, und die betreffenden Datenbanken werden nur bis zum Zeitpunkt der Sicherung wiederhergestellt.

In vielen Unternehmenslösungen wird der Windows-Clusterdienst zur Erhöhung der Serververfügbarkeit verwendet. Wenn Sie Windows Server 2003 mit SP1 und Exchange Server 2003 in einem Cluster ausführen, steht ein neues Feature, der so genannte Wartungsmodus, zur Verfügung, der bei einigen Wiederherstellungsverfahren hilfreich ist. Beim Clustering kommen einige spezielle Herausforderungen an VSS hinzu, die Sie kennen und einplanen müssen, wenn der Vorgang erfolgreich sein soll. Es ist wichtig, die Auswirkungen der Clusterlösung auf Sicherung und Wiederherstellung zu kennen.

Während einer Sicherung wird die Integrität der Prüfsummen der Schattenkopie überprüft. Eine Prüfsummenintegritätsprüfung ist ein speicher- und datenträgerintensiver Vorgang, den die meisten Administratoren nicht auf einem Clusterknoten ausführen möchten, auf dem ein virtueller Exchange-Produktionsserver gehostet wird. Während der Prüfsummenintegritätsprüfung wird die LUN als schreibgeschützt dargestellt. Dies kann zu Problemen mit der Datenträgersignatur der ursprünglichen LUN führen und bewirken, dass sie offline geschaltet wird. Aus diesem Grund wird bei den meisten Clusterlösungen ein Sicherungsserver implementiert, der die gesicherten LUNs für die Prüfsummenintegritätsprüfung bereitstellt.

Während einer Wiederherstellung werden die physikalischen Clusterdatenträgerressourcen mit IsAlive- und LooksAlive-Taktanforderungen überwacht. Bei Wiederherstellungslösungen, bei denen die Bereitstellung der Produktions-LUN aufgehoben und die Sicherungs-LUN bereitgestellt wird, kann es zu einem Zeitproblem kommen: Wenn der Clusterdienst die Taktanforderungen in dem Moment an den physikalischen Datenträger sendet, in dem von der Produktions-LUN auf die Sicherungs-LUN umgeschaltet wird, tritt u. U. ein Fehler auf der physikalischen Clusterdatenträgerressource auf, wodurch es zu einem Clusterfailover kommt. Bei Lösungen, in denen die Sicherungs-LUN wieder mit der Produktions-LUN synchronisiert wird, besteht kein Risiko eines Clusterfailovers.

Wenn Sie Exchange in einer Clusterumgebung ausführen und einen Anbieter für die Schattenkopiesicherung oder -wiederherstellung verwenden, der dazu führt, dass LUNs im Cluster vorübergehend nicht verfügbar sind, wird dringend empfohlen, das Betriebssystem Microsoft Windows Server 2003 mit Service Pack 1 (SP1) zu verwenden und den Anbieter so zu konfigurieren, dass der Wartungsmodus für Datenträgerressourcen genutzt wird. Weitere Informationen zum Wartungsmodus für Datenträgerressourcen finden Sie im Microsoft Knowledge Base-Artikel 903650, Erweiterte Wartung-Modus-Funktionalität für physische Cluster-Datenträger-Ressourcen in Windows Server 2003.

Falls Sie Windows Server 2003 SP1 nicht ausführen können oder der VSS-Anbieter den Wartungsmodus für Datenträgerressourcen noch nicht unterstützt, können Sie das Risiko eines Clusterfailovers während kritischer Vorgänge mindern, wenn auch nicht ganz ausräumen, indem Sie die IsAlive- und LooksAlive-Werte für die Ressource auf jeweils 5 Minuten erhöhen. Der Wert von 5 Minuten sollte nicht beibehalten werden. Legen Sie für den normalen Betrieb wieder die typischen Werte fest. Informationen zum Erhöhen der IsAlive- und LooksAlive-Werte finden Sie unter Frequently Asked Questions (in englischer Sprache).

Bei der Planung der Sicherungsstrategie müssen Sie eine Vereinbarung zum Servicelevel (Service Level Agreement, SLA) erstellen, in der das benötigte Sicherungs- und Wiederherstellungszeitfenster definiert wird. Damit ist eine genaue Festlegung der für das benötigte Sicherungszeitfenster erforderlichen Anzahl von Datenbanken, Speichergruppen und Exchange-Servern möglich. Die meisten Administratoren definieren auch ein zusätzliches Zeitfenster für die Onlinewartung und -defragmentierung der Datenbanken sowie für die Wartung des Betriebssystems.

Bei der Erstellung einer VSS-Lösung können Sie eine der beiden folgenden Strategien verfolgen:

  • Aktualisieren der vorhandenen Infrastruktur, sodass diese VSS unterstützt
  • Entwerfen einer neuen, hoch verfügbaren VSS-Lösung für Exchange Server 2003

Informationen zu Hochverfügbarkeitsstrategien für Exchange Server 2003 finden Sie im Exchange 2003-Handbuch für hohe Verfügbarkeit. Informationen zur Planung der Notfallwiederherstellung finden Sie unter Arbeitsblatt: Vorbereitung der Wiederherstellung nach Datenverlust für Microsoft Exchange Server 2003.

Unabhängig davon, ob Sie eine neue Lösung entwerfen oder eine vorhandene Lösung aktualisieren, müssen Sie zuerst die aktuelle Methode und das Zeitfenster für Sicherung und Wiederherstellung, die Datenbank- und Speichergruppengröße, den aktuell belegten Speicherplatz und den verfügbaren Speicherplatz analysieren. Sie sollten die Leistung der Speicherlösung sowohl während des Produktions- als auch während des Sicherungszeitfensters messen.

Es ist auch wichtig, das Postfachprofil zu kennen, zu dem Angaben wie die Größe eines einzelnen Postfachs und die Anzahl von Datenbank-E/A-Vorgängen pro Benutzer gehören. Dieser Faktor ist bei VSS zu berücksichtigen, da Sicherung und Wiederherstellung eine zusätzliche Belastung für das Speichersubsystem darstellen, bei dessen Entwurf Sie sorgfältig vorgehen müssen, um geringe Wartezeiten sicherzustellen. Informationen zur Vorgehensweise zum Definieren des Postfachprofils finden Sie unter Optimieren von Speichersystemen für Exchange Server 2003.

Außerdem müssen Sie feststellen, ob Sie eine Lösung mit Streamingsicherung oder eine VSS-Sicherungslösung verwenden können. Bei der Streaming-Onlinesicherung wird eine Exchange-Sicherungs-API zum Sichern von bereitgestellten Datenbanken und Speichergruppen verwendet. Während der Streamingsicherung wird für jede Seite die Prüfsummenintegritätsprüfung ausgeführt. Wenn die Sicherung erfolgreich war, können Sie also davon ausgehen, dass Sie über eine zuverlässige Sicherung verfügen. Die Belastung der Produktions-LUNs durch die Streaming-E/A-Vorgänge während der Sicherung ist ebenso hoch wie bei der Prüfsummenintegritätsprüfung einer Schattenkopie, und die Speichersysteminfrastruktur muss eine geeignete Größe haben, damit die Sicherungs- und Wiederherstellungs-SLA eingehalten werden kann.

Eine Mischung von Exchange-abhängiger Streamingsicherung und Exchange-abhängiger VSS-Sicherung in derselben Speichergruppe ist nicht möglich, da es in diesem Fall zu Konflikten bei der Verwaltung der Transaktionsprotokolldateien käme. Bei der einen Sicherungsart werden möglicherweise Protokolldateien abgeschnitten, die für die andere Sicherung erforderlich sind. Sie können jedoch eine allgemeine Streamingdateisicherung eines VSS-Schattenkopie-Sicherungssatzes ausführen, um den Sicherungssatz dauerhaft zu erhalten, bevor er durch eine nachfolgende Sicherung überschrieben wird.

In einer Umgebung mit Streamingsicherung sind die Bandbreite der physikalischen Datenträger oder des Netzwerks, die Isolierung der physikalischen Datenträger und die Bandgeschwindigkeit zu berücksichtigen. Diese Aspekte stellen jeweils Engpässe dar, die es im Allgemeinen verhindern, dass die Sicherung eines Exchange-Servers die Sicherung eines anderen Exchange-Servers beeinträchtigt.

Aufgrund der VSS-Anforderungen für Exchange Server 2003 verarbeiten das Speichersystem und der Speichercontroller grundsätzlich alle sequenziellen E/A-Vorgänge der Sicherung neben den normalen wahlfreien E/A-Anforderungen. Daher müssen Sie den Durchsatz während der Sicherung und Wiederherstellung testen. Es ist wichtig, dass Sie wissen, wie viele GB pro Stunde ein Controller während der Synchronisierung bewältigen kann, während er die Produktionslast verarbeiten muss, die Sie während des Sicherungsvorgangs erwarten, damit die SLA eingehalten werden kann.

Wenn Sie mit VSS arbeiten, müssen Sie eine SLA erstellen, in der das Sicherungszeitfenster und die akzeptable Downtime bei einem Ausfall definiert werden. Danach richtet sich der Entwurf des Speichersystems. Sie müssen auch in Betracht ziehen, eine SLA für unterschiedliche Szenarien zu erstellen, die Anlass zur Wiederherstellung geben. Bei der Definition Ihrer Sicherungsstrategie müssen Sie die Notwendigkeit kurzer Sicherungs- und Wiederherstellungszeitfenster gegen die damit verknüpften Kosten abwägen. Eine SLA für eine Wiederherstellung in 10 Minuten erfordert z. B. mehr Hardwareleistung und technische Kenntnisse als eine SLA für eine Wiederherstellung in 72 Stunden.

Weitere Informationen zu SLAs und zur Verfügbarkeitsverwaltung finden Sie unter Microsoft Solutions for Management: Availability Management (in englischer Sprache). Weitere Informationen zu SLAs für Exchange Server 2003 finden Sie im Exchange 2003-Handbuch für hohe Verfügbarkeit.

Legen Sie im Rahmen der SLA Folgendes fest:

  • Recovery Point Objective (RPO)   RPO ist die Datenmenge, deren Verlust Sie tolerieren können. Wenn Sie z. B. keine Datenverluste hinnehmen können, hat RPO den Wert Null (0).
  • Recovery Time Objective (RTO)   RTO ist die Zeitspanne von einem Ausfall bis zur Wiederaufnahme des Diensts. Um das RTO zu erfüllen, sind bei manchen Lösungen kürzere Intervalle zwischen den Sicherungszeitfenstern erforderlich, damit die Protokollwiedergabezeit während der Wiederherstellung der Wiederherstellungs-SLA entspricht. Grundsätzlich empfiehlt es sich, das RTO für folgende Elemente festzulegen:
    • Postfach   Es wird empfohlen, integrierte Funktionen wie Gelöschte Objekte wiederherstellen in Microsoft Office Outlook® 2003 oder Richtlinien für die Aufbewahrungszeit von Objekten in Exchange Server 2003 für die Wiederherstellung eines einzelnen Postfachs oder von Daten innerhalb eines Postfachs zu verwenden. Weitere Informationen zur Funktion Gelöschte Objekte wiederherstellen finden Sie unter Microsoft Office-Unterstützung: Wiederherstellen gelöschter Elemente aus einem beliebigen Ordner. Weitere Informationen zu Richtlinien für die Aufbewahrungszeit von Objekten finden Sie unter Welcher VERFAHRENSWEISE: TO: um Postfach-Speichergrenzwerte in Exchange Server 2003 zu konfigurieren, verwenden Sie Systemrichtlinie.
    • Speichergruppe   Zum Wiederherstellen beschädigter Daten oder Datenbanken bzw. Protokolldateidaten in der Speichergruppe müssen Sie die Sicherung verwenden. Darüber hinaus muss die Lösung der festgelegten SLA und dem Wiederherstellungszeitfenster entsprechen. Sie können zwar VSS verwenden, um einzelne Datenbanken in einer Speichergruppe zu sichern und wiederherzustellen, jedoch wird als bewährte Methode empfohlen, Speichergruppen als Ganzes zu sichern und wiederherzustellen. Die Sicherung und Wiederherstellung pro Datenbank ist ein komplexerer Vorgang, bei dem Sie pro LUN jeweils nur eine Datenbank speichern können. Die Sicherung einzelner Datenbanken wird unterstützt, und u. U. ist dies aufgrund der besonderen Anforderungen Ihrer Umgebung das geeignete Verfahren, allerdings sollten Sie sich auch die Nachteile vergegenwärtigen.
    • Server   Bei einem Serverfehler ist die Wiederherstellung der VSS-Sicherung auf einem anderen Server eine gute Lösung. Bei den Systemen einiger Speicherhersteller können VSS-Sicherungen wiederhergestellt werden, die asynchron an einem anderen Standort repliziert wurden Dazu muss der Anforderer VSS verwenden können, um die Daten auf einem anderen Server wiederherzustellen, der den gleichen Pfad und Hostnamen aufweist.
    • Standort   Bei einem Standortfehler müssen die Exchange Server-Daten an einem anderen Standort verfügbar sein. Sie können die Replikation verwenden und/oder die VSS-Sicherungen auf Band kopieren und die Bänder an einem anderen Standort lagern, damit sie zur Wiederherstellung an dem alternativen Standort zur Verfügung stehen.

Die Definition einer Replikationsstrategie ist ein wichtiger Bestandteil der Implementierung einer VSS-Lösung, da einige Replikationsmethoden die Wartezeiten der Produktions-LUNs beeinflussen und im Hinblick auf die Erfüllung der SLA sorgfältig konzipiert werden müssen. Exchange Server 2003 bietet keinen Replikationsmechanismus auf Anwendungsebene für Postfachdatenbanken. Wir empfehlen den Windows-Clusterdienst für die Serverflexibilität, verweisen jedoch auf die Speicher- und Standortflexibilitätslösungen unserer Speichersystempartner.

Die Replikation wird immer wichtiger, da Unternehmen Messaging immer häufiger nicht mehr nur als "willkommenen Zusatz", sondern als unverzichtbare Anwendung ansehen. Sie können die Replikation auf verschiedene Weise implementieren. Die meisten Lösungen sind allerdings entweder synchron oder asynchron. Weitere Informationen zur Replikationsunterstützung in Exchange Server 2003 finden Sie unter Bereitstellungsrichtlinien für die Datenreplikation für Exchange Server mit mehreren Standorten und im Microsoft Knowledge Base-Artikel 895847, Datenreplikationsunterstützung von Exchange Server mit mehrerem Standort.

Im Anschluss an die Analyse der aktuellen Infrastruktur und die Definition neuer SLAs müssen Sie eng mit Ihrem Speicherhersteller zusammenarbeiten, um eine Speicherlösung zu entwerfen, die Ihrer SLA entspricht. Geben Sie dem Speicherhersteller genaue Informationen zur Größe und E/A-Leistung der Speichergruppen, zu Sicherungs- und Wiederherstellungszeitfenstern, akzeptablen Leistungsniveaus während Produktion und Sicherung sowie zur erwarteten Häufigkeit der Datensicherung an die Hand. Der Speicherhersteller kann Ihnen dann eine Lösung vorschlagen, die Sie überprüfen können.

Beim Entwerfen der Speicherinfrastruktur müssen Sie überprüfen, ob die gesamte End-to-End-Lösung von Microsoft qualifiziert wurde und im Windows-Katalog aufgeführt ist. Die Strategie, die in Ihrer Lösung für die Datensicherung verfolgt wird, spielt eine große Rolle beim Entwurf des Speichersystems.

Die meisten Speichersysteme werden nach dem Kriterium der Kapazität gekauft. Es ist zwar wichtig, dass für künftiges Wachstum genügend Speicherkapazität zur Verfügung steht, jedoch ist es für den Erfolg Ihrer Speicherlösung auch entscheidend, dass sie genügend E/A-Vorgänge mit geringer Wartezeit bewältigen kann, um von den Endbenutzern als erfolgreich wahrgenommen zu werden. Das Datenträgersubsystem zeigt eine schlechte Leistung, wenn die mittlere Lese- und Schreibwartezeit 20 Millisekunden übersteigt und Wartezeitspitzenwerte von über 50 Millisekunden nicht nur wenige Sekunden lang zu beobachten sind.

Derzeit platzieren die meisten Exchange Server-Architekten Exchange Server-Datenbanken und Transaktionsprotokolldateien aus Gründen der Leistung und des Datenbankschutzes auf RAID10-LUNs. Sie können die Verwendung anderer RAID-Stufen in Betracht ziehen, wenn die Lösung gründlich getestet wurde und die SLA eingehalten wird. Viele Speicherhersteller geben genaue Empfehlungen für die Bereitstellung ihrer Produkte mit Exchange Server 2003. Es wird empfohlen, beim Speicherhersteller bezüglich einer Exchange-spezifischen Datenträgerkonfiguration und Empfehlungen zur Fehlertoleranz nachzufragen.

Nach dem Kauf des Speichersystems versuchen viele Administratoren, jedes verfügbare Byte an Kapazität mithilfe von RAID5 zu nutzen. Sie können RAID5 verwenden, wenn die Anzahl der zugeordneten Spindles eine vertretbare Leistung und Wartezeit gewährleistet. In manchen Fällen ist die Leistung dann besser als bei RAID10. Vielfach führt die richtige Bemessung der Spindleleistung jedoch dazu, dass bei RAID5 mehr physikalische Datenträger verwendet werden als bei RAID10. Zudem sollten Sie die mit der Neuerstellung von Datenträgern einhergehenden Leistungseinbußen für verschiedene RAID-Stufen testen. Mit Jetstress, das unter "Überprüfen der VSS-Lösung" erläutert wird, sollten Sie die tatsächliche LUN-Konfiguration testen, um sicherzustellen, dass sie unabhängig von der gewählten RAID-Stufe den E/A-Anforderungen von Exchange entspricht. Weitere Informationen zu RAID-Stufen finden Sie unter Optimieren von Speichersystemen für Exchange Server 2003.

Zusammengefasst betrachtet, ist die Datenträgerkapazität nur einer der Faktoren, die bei der Speicherplanung für Exchange Server 2003 berücksichtigt werden müssen. Die folgenden kritischen Faktoren müssen ebenfalls bedacht werden:

  • Fehlertoleranz. Bietet die Lösung ein hohes Maß an Redundanz und Flexibilität, damit Laufwerk- und Medienfehler abgefangen werden können?
  • E/A-Profil. Unterstützen die RAID-Stufe und die Anzahl von Spindles sowohl die erforderliche E/A-Last als auch die tatsächliche E/A-Mischung (Lese- und Schreibzugriffe, wahlfreier und sequenzieller Zugriff)?
  • Wiederherstellungsprofil. Kommt es nach einem Fehler zu erheblichen Leistungseinbußen während der Wiederherstellung der Laufwerkgruppe?

Berücksichtigen Sie beim Entwickeln eines grundlegenden Entwurfs für Ihre VSS-Lösung die folgenden Punkte:

  • Ist für die Speichergruppen die Umlaufprotokollierung aktiviert?
    Es wird empfohlen, die Umlaufprotokollierung zu deaktivieren. Bei aktivierter Umlaufprotokollierung ist für Speichergruppen nur eine Zeitpunktwiederherstellung möglich. Dies kann zu Datenverlusten führen. Wenn nämlich die Umlaufprotokollierung aktiviert ist, sind Wiederherstellungen einzelner Datenbanken nicht möglich, und Sie können für die Protokolle kein Rollforward ausführen. Dies kann sich auf das RPO der SLA auswirken.
  • Werden Exchange Server-Daten von der VSS-Lösung ausschließlich mithilfe des Exchange-Verfassers gesichert und wiederhergestellt?
    Bei Exchange Server 2003 dürfen Exchange Server-Daten ausschließlich vom Exchange-Verfasser gesichert und wiederhergestellt werden.

Berücksichtigen Sie beim Entwickeln eines Clusterentwurfs für Ihre VSS-Lösung die folgenden Punkte:

  • Ist die Wiederherstellung vollständig automatisiert, ist also kein manueller Eingriff erforderlich, um die Abhängigkeit der Clusterressourcen anzupassen?
    Es wird empfohlen, alle notwendigen Änderungen an der Abhängigkeit der Clusterressourcen vom Anforderer ausführen zu lassen.
  • Wirkt sich die Wiederherstellung auf die Integrität der physikalischen Datenträgerressourcen aus?
    Für Cluster sollten Sie Exchange Server 2003 mit SP1 sowie einen Anforderer verwenden, der den Clusterwartungsmodus erkennt. In diesem Modus werden Ressourcenfehler während der Wiederherstellung vermieden, indem die IsAlive- und LooksAlive-Überprüfung vorübergehend deaktiviert wird.

Berücksichtigen Sie beim Entwickeln eines Anbieterentwurfs für Ihre VSS-Lösung die folgenden Punkte:

  • Verfügt Ihr Speicherarray über einen VSS-Anbieter mit Snapshot- oder Klonfunktion oder mit beiden Funktionen?
    Exchange Server 2003 erfordert einen VSS-fähigen Anbieter. Der Anbieter kommuniziert mit dem Speichergerät, um Schattenkopien zu erstellen und zu löschen.
  • Unterstützt der Anbieter Exchange-Clusterkonfigurationen?

Berücksichtigen Sie beim Entwickeln eines Anforderentwurfs für Ihre VSS-Lösung die folgenden Punkte:

  • Überprüft der Anforderer die Prüfsummenintegrität des Schattenkopie-Sicherungssatzes?
    Bei Exchange Server 2003 muss die Prüfsummenintegritätsprüfung an der Schattenkopie ausgeführt werden, um festzustellen, ob die Sicherung fehlerfrei ist. Die Wiederherstellung von Daten, für die keine Prüfsummenintegritätsprüfung ausgeführt wurde, wird nicht unterstützt.
  • Führt der Anforderer die Prüfsummenintegritätsprüfung jeweils nur für eine LUN aus?
    Wenn sich mehrere Datenbanken auf derselben LUN befinden, ist es wahrscheinlich effizienter, die Prüfsummenintegritätsprüfung für die einzelnen Datenbanken seriell auszuführen. Auf diese Weise werden zu starke Bewegungen des Schreib-/Lesekopfes vermieden, und der sequenzielle Lesevorgang bleibt erhalten.
  • Importiert der Anforderer automatisch die aktuelle Schattenkopie zur Prüfsummenintegritätsprüfung auf einen Sicherungsserver?
    Es wird empfohlen, die Prüfsummenintegritätsprüfung mit Eseutil.exe auf einen Sicherungsserver zu verlagern.
  • Unterstützt der Anforderer Exchange-Clusterkonfigurationen?
  • Unterstützt der Anforderer Planung und Warteschlangen?
    Bestimmte Lösungen weisen u. U. andere Leistungsmerkmale auf. So wird bei einer Lösung möglicherweise die optimale Leistung erzielt, wenn Schattenkopien aller LUNs zusammen erstellt werden, während bei anderen die Leistung höher ist, wenn die Schattenkopien seriell erstellt werden. Die Lösung sollte Planungsflexibilität und Möglichkeiten zur Optimierung bieten, damit bei der Planung sowohl die Leistung optimiert als auch der Aufwand für den Administrator so gering wie möglich gehalten werden kann.
  • Überprüft der Anforderer die Daten vor der Sicherung auf potenzielle Beschädigung, und beendet er die Sicherung, wenn beschädigte Daten gefunden werden?
    Einige Anforderer suchen nach Datenbankbeschädigungsereignissen (-1018, -1019, -1022), damit die letzte als fehlerfrei bekannte Sicherung nicht durch eine beschädigte Datenbank überschrieben wird. Wenn Ihr Anforderer nicht über diese Funktion verfügt, können Sie Microsoft Operations Manager (MOM) oder andere Ereignisscanner verwenden oder die Ereignisprotokolle manuell überprüfen, um Beschädigungen zu erkennen.
    Die Überwachung der Ereignisprotokolle auf diese Fehler kann die Überprüfung der Prüfsummenintegrität der Sicherungen nicht ersetzen. Dies liegt daran, dass Ereignisse nur für Seiten in der Datenbank protokolliert werden, auf die tatsächlich zugegriffen wird. Fehler auf Seiten, auf die nur selten zugegriffen wird, werden durch die Überwachung der Ereignisprotokolle nicht zuverlässig erkannt. Wenn Sie die Ereignisprotokolle überwachen, erhalten Sie u. U. zusätzliche und frühere Hinweise auf Datenbankbeschädigungen.
  • Signalisiert der Anforderer Fehler und Erfolg mithilfe von Ereignissen?
    Der Anforderer sollte Ereignisse verwenden, die mit Skripts und Tools wie MOM überwacht werden können. Diese Ereignisse helfen Ihnen bei der vorausschauenden Überwachung Ihrer Exchange Server-VSS-Lösung.
  • Hebt der Anforderer mithilfe von CDOEXM die Bereitstellung der Speichergruppe vollständig auf, bevor sie wiederhergestellt wird?
    Der Anforderer sollte die Bereitstellung der Speichergruppe vor deren Wiederherstellung aufheben. Andernfalls müssen Sie die Bereitstellung der Speichergruppe manuell aufheben, bevor die Wiederherstellung gestartet wird.
  • Unterstützt der Anforderer die E/A-Einschränkung bei der Prüfsummenintegritätsprüfung mit Eseutil.exe?
  • Verwaltet der Anforderer die Aufbewahrung und Löschung von Schattenkopien, ohne dass manuelle Eingriffe des Administrators erforderlich sind?

Berücksichtigen Sie beim Entwickeln eines Speichersystementwurfs für Ihre VSS-Lösung die folgenden Punkte:

  • Wirkt sich die Wiederherstellung der Speichergruppe der VSS-Lösung auf andere Speichergruppen oder Exchange-Server aus?
    Sie sollten die LUN-Konfiguration für Ihr Speichersystem so entwerfen, dass sich die Wiederherstellung einer Speichergruppe nicht auf andere Produktionsspeichergruppen oder Exchange-Server auswirkt. Am sinnvollsten ist es, die physikalischen Datenträger jeweils auf Speichergruppenbasis zu isolieren und, wo dies nicht möglich ist, die Produktionslast der Lösung zusätzlich zur Wiederherstellungs-E/A-Last zu testen, um so sicherzustellen, dass die Auswirkungen für die Benutzer akzeptabel sind.
  • Synchronisiert die Lösung während der Wiederherstellung die Schattenkopiedaten aus der Sicherung mit der Produktions-LUN?
    Eine Lösung, die die Synchronisierung entweder mit einem Snapshot oder mit einem Klon unterstützt, muss Daten aus der Schattenkopie auf die ursprüngliche LUN kopieren. Die dafür benötigte Zeit richtet sich nach der Menge der zu kopierenden Daten. Die Wiederherstellungszeit hängt auch von der Anzahl der Protokolldateien ab, die bei einem Hard Recovery-Vorgang für die Datenbank wiedergegeben werden müssen, wenn die Speichergruppe bereitgestellt wird.
  • Ist die VSS-Lösung mit dem Flexibilitätsplan Ihres Standorts kompatibel?
    Bei Exchange Server 2003 müssen Lösungen, die VSS-Sicherungen an einem separaten Standort replizieren, die Daten am zweiten Standort mithilfe von VSS wiederherstellen. Weitere Informationen zur Replikation finden Sie im Exchange 2003-Handbuch für hohe Verfügbarkeit.

Bei einer Klonsicherung werden alle Daten kopiert. Dieser Kopiervorgang erfordert Ressourcen und nimmt Zeit in Anspruch, die von der Größe der zu kopierenden LUN abhängt. Daher sollten Sie unbedingt die Auswirkungen dieses Verfahrens auf die Produktions-LUNs kennen und wissen, ob Ihr Speicherhersteller Features bereitstellt, mit deren Hilfe Sie diese Auswirkungen minimieren können. In Bezug auf die Geschwindigkeit des Klonens von Daten gilt für Speichercontroller ein individueller Maximalwert. Wenn Sie diese Grenze kennen, können Sie den Gesamtdurchsatz erhöhen, indem Sie die LUNs und Exchange-Server so platzieren, dass die Speichercontroller optimal genutzt werden.

Berücksichtigen Sie beim Entwurf einer VSS-Lösung mit Klonsicherung die folgenden Punkte:

  • Wird für das Klonziel ein anderer Satz physikalischer Datenträger verwendet als für die Quellproduktions-LUNs?
    Für den Klon sollten physikalische Datenträger verwendet werden, die von den Quellproduktions-LUNs getrennt sind. Wenn für den Klon die gleichen physikalischen Datenträger verwendet werden, wird die Wartezeit der Produktions-LUNs durch die Prüfsummenintegritätsprüfung erheblich beeinträchtigt, und Sie müssen die Sicherung für eine Zeit mit geringer Aktivität einplanen, um die Auswirkungen auf die Benutzer zu minimieren.
  • Wird für das Klonziel, falls es sich hierbei um einen anderen Satz physikalischer Datenträger handelt, der gleiche RAID-Typ verwendet?
    Wenn Sie für die Produktions-LUNs RAID10 und für das Klonziel RAID5 verwenden, kann die Leistung für die Sicherung ausreichend sein. Wenn die RAID5-LUN während der Wiederherstellung als neue Produktions-LUN verfügbar gemacht wird, müssen Sie beim Entwerfen der Speicherlösung die Auswirkungen des u. U. langsameren Speichersystems auf die Leistung berücksichtigen.
  • Unterstützt der Anforderer mehrere Klonziele?
    Die Lösung sollte mindestens zwei Klonziele unterstützen, zwischen denen gewechselt werden kann, um Datenverluste zu verhindern, falls während der Sicherung ein Fehler auftritt. Dies ermöglicht eine schnelle Wiederherstellung der letzten als fehlerfrei bekannten Sicherung.
  • Wartet der Anforderer, bis der Klon aufgeteilt oder vollständig synchronisiert ist, bevor die Prüfsummenintegrität überprüft wird?
    Der Anforderer sollte warten, bis der Klon aufgeteilt oder normalisiert ist, bevor die Prüfsummenintegrität überprüft wird. Dies ist notwendig, um eine Blockabhängigkeit von den Produktions-LUNs zu vermeiden, und verhindert, dass die Wartezeit der Produktions-LUNs zu hoch wird.
  • Enthält die Lösung einen Mechanismus zur Wiederherstellung des Klons, wenn die Produktions-LUN-Hardware ausfällt?
    Wenn Sie die Daten auf separaten physikalischen Datenträgern klonen, ein Datenträger oder System jedoch ausfällt, müssen Sie in der Lage sein, den Klon wiederherzustellen. Wenn die VSS-Lösung keinen Mechanismus zur Wiederherstellung des Klons enthält, müssen in Ihrer SLA alternative Möglichkeiten zur Wiederherstellung im Falle eines Datenträger- oder Systemausfalls dokumentiert werden, und Sie müssen die alternative Methode testen.
  • Verwendet das Klonziel Nearline-Speicherung?
    Datenträgertypen (SATA) mit geringerer Rotationsgeschwindigkeit und längerer Kopfsuchzeit sind für eine Arbeitsauslastung mit wahlfreiem Zugriff nicht optimal. Preisgünstige Speichersysteme bieten bei sequenziellen Arbeitsauslastungen oder in Umgebungen mit geringen Produktions-E/A-Arbeitsauslastungen in der Regel eine angemessene Leistung. Viele Speichersystemhersteller verwenden SATA- und FATA-Geräte. Diese Geräte eignen sich u. U. gut als Sicherungsziele in VSS-Umgebungen mit sequenziellem Datenzugriff bei Sicherung und Wiederherstellung. Sie müssen darauf achten, dass die bei langsameren Speichersystemen für den Prüfsummenvorgang benötigte Zeit Ihrer SLA entspricht. Riskant sind Lösungen, die dem Host diese minderwertigen Speichersysteme während einer Wiederherstellung als Produktions-LUNs darstellen. Lösungen dieser Art müssen entsprechend skaliert werden, damit sie die Produktionslast verarbeiten können.
  • Tauscht die Lösung den Klon und die Produktions-LUN während einer Wiederherstellung aus?
    Bei Lösungen, die den LUN-Austausch unterstützen, wird in der Regel eine Klonsicherung verwendet. Die Wiederherstellung erfolgt sehr schnell, unabhängig von der Datenmenge, indem die Produktions-LUN durch die gesicherte LUN ersetzt wird. Diese Strategie wird auch durch die Anzahl der Protokolldateien beeinflusst, die bei einem Hard Recovery-Vorgang der Datenbank wiedergegeben werden müssen, wenn die Speichergruppe bereitgestellt wird. Überlegungen zu verschiedenen RAID-Arten (RAID10 und RAID5) sind wichtig, wenn eine Wiederherstellung notwendig ist.

Berücksichtigen Sie beim Entwurf einer VSS-Lösung mit Snapshotsicherung die folgenden Punkte:

  • Ist es vorgesehen, zusätzlich zu den Snapshots vollständig unabhängige Sicherungen zu erstellen?
  • Wird bei der Snapshotsicherung Speicherplatz im erforderlichen Umfang zugeordnet?
    Die meisten Lösungen beanspruchen die Kapazität entsprechend dem Bedarf und den vorgenommenen Änderungen. Bei einigen Lösungen wird bei jedem Snapshot die gesamte Produktions-LUN zugeordnet, um für den Fall vorbereitet zu sein, dass jedes Datenbit geändert wurde. Sie müssen dies bei der Kapazitätsplanung berücksichtigen, falls pro Tag mehrere Snapshotsicherungen angelegt werden müssen. Auch wenn kein Speicherplatz reserviert wird, müssen Sie den zusätzlichen Speicherplatz berücksichtigen, der möglicherweise benötigt wird, wenn die Größe von Snapshots des Typs Kopie bei Schreibvorgang proportional zur Anzahl der Änderungen im Livedataset zunimmt.
  • Wie wirken sich mehrere Snapshots auf die Leistung aus?
    Die Notwendigkeit, mehrere Snapshots gleichzeitig zu verfolgen, kann zusätzlichen Leistungsaufwand zur Folge haben. Es ist wichtig, diese Auswirkung auf die Leistung zu messen, damit Sie die Anzahl der Snapshots festlegen können, die realistischerweise gleichzeitig angelegt werden können. Das Löschen eines Snapshots kann sich ebenfalls auf die Leistung auswirken, da Indizes aktualisiert und in einigen Fällen Daten auf den physikalischen Datenträgern neu organisiert werden müssen, bevor der Speicherplatz im Array neu zugeordnet werden kann.

VSS hat Auswirkungen auf die Infrastruktur des Speichersystems. Nachdem Sie die VSS-Lösung entworfen haben, müssen Sie sie überprüfen, indem Sie diese Auswirkungen messen und sicherstellen, dass die SLA eingehalten wird. Sie müssen in einer Machbarkeitsstudie sämtliche Wiederherstellungsszenarien überprüfen, die von der SLA unterstützt werden sollen.

Nachdem Sie die Lösungsanforderungen zusammengefasst haben, müssen Sie die gesamte End-to-End-Lösung überprüfen. Dabei sind folgende Details zu beachten:

  • Die Anzahl der GB pro Stunde, die der Speichercontroller bei der erwarteten Exchange Server-Auslastung während des Sicherungszeitfensters sichern kann
  • Die Geschwindigkeit, mit der diese Datenbanken wiederhergestellt werden können

Stellen Sie in der Überprüfungsphase fest, ob Ihre Lösung die folgenden Anforderungen erfüllt:

  • Die typische Lese- und Schreibwartezeit der Datenbank-LUNs liegt unter 20 Millisekunden, und Spitzenwerte von über 50 Millisekunden treten höchstens einige Sekunden lang auf.
  • Sie können innerhalb des festgelegten Sicherungszeitfensters eine Sicherung und Prüfsummenintegritätsprüfung ausführen.
  • Die Wiederherstellung entspricht Ihrer SLA für die Wiederherstellung und beeinträchtigt andere Speichergruppen oder Exchange-Server nicht.

Es ist wichtig, die tatsächliche End-to-End-Lösung in einer Weise zu testen, die deren Bereitstellung in der Produktionsumgebung entspricht. Durch die Tests stellen Sie sicher, dass Ihre Lösung das VSS-Framework verwendet und die Exchange Server 2003-Anforderungen erfüllt. Zugleich erhalten Sie die Gelegenheit, einige der Leistungsauswirkungen der Lösung zu verstehen. Sie müssen die End-to-End-Tests entsprechend Ihrer eigenen SLA entwerfen. Wenn Sie eine Exchange Server 2003-VSS-Lösung bereitstellen, ohne deren Auswirkungen auf die Leistung zu berücksichtigen, kann dies die Leistung beeinträchtigen und zu Unzufriedenheit bei den Benutzern führen.

Testen Sie auf jeden Fall die folgenden Aspekte:

  • Die Leistung der Produktions-LUNs während einer Sicherung
  • Die Leistung der Prüfsummenintegritätsprüfung. Hierunter fällt die Leistung der Produktions-LUNs während der Überprüfung. Die Prüfsummenintegritätsprüfung muss so schnell abgeschlossen werden, dass sie nicht den Zeitpunkt der nächsten Sicherung überdauert.
  • Wiederherstellung
  • Protokollwiedergabe
  • Replikation

Die Anzahl der Benutzer pro Speichergruppe sollte der für die Bereitstellung erwarteten Anzahl entsprechen.

Sie können die Bereitstellung mithilfe der folgenden Tools testen:

  • Microsoft Exchange Server 2003 Load Simulator (LoadSim)   LoadSim simuliert die Verwendung von Exchange Server 2003 durch Outlook-MAPI-Benutzer. Mit LoadSim können Sie Benutzer erstellen und Postfächer mit E-Mail initialisieren. Dabei werden Datenbanken erstellt, deren Größe etwa der der Datenbanken in der Produktionsumgebung entspricht. LoadSim erfordert Outlook 2003. Sie können LoadSim unter Microsoft Exchange Server 2003 Load Simulator (LoadSim) (in englischer Sprache) herunterladen.
  • Exchange Server 2003 Jetstress   Jetstress simuliert die Datenträger-E/A-Last, um die Leistung und Stabilität des Speicherarrays zu überprüfen. Das Tool verfügt über eine benutzerfreundliche grafische Benutzeroberfläche. Sie können Jetstress unter Microsoft Exchange Server Jetstress Tool (32 bit) (in englischer Sprache) herunterladen.

Das Ziel der ersten Testphase ist das Burn-In der Lösung, um Probleme mit der Konfiguration und Stabilität von VSS sowie des Speichersystems schnell zu erkennen.

Es folgt ein Beispiel für die Ausführung der ersten Testphase:

  • Führen Sie für jede Datenbank- und Protokoll-LUN einen 24-Stunden-Jetstress-Belastungstest aus.
  • Erstellen Sie mit LoadSim Datenbanken, deren Größe der der Datenbanken des Produktionssystems entspricht, und führen Sie über einen Zeitraum von 48 Stunden alle zwei Stunden eine Sicherung des Servers aus.
    Sie sollten das Sicherungszeitfenster von zwei Stunden dem vorgesehenen Produktionssicherungszeitfenster anpassen. Verwenden Sie je nach der Konfiguration Ihrer Produktionsumgebung einen eigenständigen Server oder einen Clusterserver.

Ziel der zweiten Testphase ist es, sicherzustellen, dass Ihre VSS-Lösung Datenbanken in Produktionsgröße und unter Produktionsbelastung innerhalb der in der SLA definierten Sicherungs- und Wiederherstellungszeitfenster sichern und wiederherstellen kann.

Es folgt ein Beispiel für die Ausführung der zweiten Testphase:

  • Führen Sie nach einer 8-stündigen Anwendung von LoadSim mithilfe des Profils "MAPI Messaging Benchmark 3 (MMB3)" nächtliche Sicherungen aus.
  • Führen Sie die Wiederherstellung morgens aus, bevor der nächste LoadSim-Test gestartet wird. Testen Sie auf jeden Fall die Wiederherstellungsfälle, die Sie entsprechend der Definition in Ihrer SLA in der Produktionsumgebung verwenden möchten. Im Folgenden sind die drei häufigsten Wiederherstellungsfälle genannt:
    • Rollforward-Wiederherstellung, wobei die Datenbanken wiederhergestellt werden und für die Protokolle ein Rollforward ausgeführt wird
    • Zeitpunktwiederherstellung, wobei die Protokolle wiederhergestellt werden
    • Vollständige Wiederherstellung, wobei die gesamte Speichergruppe wiederhergestellt werden muss

Überwachen Sie die Auswirkungen der Prüfsummenintegritätsprüfung auf die Leistung. Wenn die Prüfsummenintegritätsprüfung zu einer nicht akzeptablen Wartezeit führt, stellen Sie zuerst fest, ob ein Engpass vorhanden ist. Speichercontroller, Prozessoren, Cache und Bandbreite zum Speichersystem können jeweils einen Engpass erzeugen. Wenn der Engpass durch die Datenträgerleistung erzeugt wird, ist es u. U. am sinnvollsten, physikalische Spindles hinzuzufügen, um die LUN zu unterstützen. Wenden Sie sich an den Hersteller Ihrer Speicherlösung, um herauszufinden, wie nicht akzeptable Wartezeiten verkürzt werden können.

Es ist von entscheidender Bedeutung, die Integrität Ihrer Lösung zu überwachen, damit Sie im Voraus Schritte zur Bewältigung des Wachstums ergreifen und Probleme verhindern können, wenn sich Ihre Produktionsumgebung weiterentwickelt, wenn sich z. B. die Benutzerprozesse ändern, Benutzer hinzugefügt oder die Postfächer größer werden. Im Hinblick auf die Sicherung und Wiederherstellung müssen Sie folgende Aspekte überwachen:

  • Ob sich Änderungen der Wartezeiten ergeben
  • Ob bei der Sicherung und Prüfsummenintegritätsprüfung die erwarteten Raten erreicht werden
  • Benachrichtigungen, falls während der Sicherung oder Wiederherstellung Probleme auftreten

Der erste Schritt bei der Überwachung besteht darin, Grundwerte für die gewünschte Leistung festzulegen. Überwachen Sie im weiteren Verlauf, ob Abweichungen von den festgelegten Grundwerten auftreten. Weitere Informationen zur Überwachung finden Sie im Exchange 2003-Handbuch für hohe Verfügbarkeit.

Microsoft Operations Manager (MOM) 2005 und das Exchange Management Pack ermöglichen die zentrale Überwachung der Leistung und Verfügbarkeit von Exchange Server 2003. Das Exchange Management Pack enthält eine Wissensdatenbank mit Warnungen sowie Vorschlägen und Links zu entsprechenden Informationen. Mithilfe des Exchange Management Packs können Sie problemlos folgende Aspekte verfolgen:

  • Datenbankgröße
  • Anzahl der Postfächer
  • Konfiguration
  • Verfügbarkeit
  • Clientüberwachung
  • Nachrichtenverkehrsanalyse

Mit dem Exchange Management Pack können Sie auch Warnungen empfangen, die durch bestimmte Schwellenwerte ausgelöst werden. Sie können das Exchange Management Pack unter Exchange Server Management Pack Guide for MOM 2005 (in englischer Sprache) herunterladen. Informationen zu Best Practices für die Überwachung mithilfe von MOM 2005 mit Exchange Server 2003 finden Sie im Exchange 2003 Management Pack Configuration Guide (in englischer Sprache). Weitere Informationen zur Behandlung von Leistungsproblemen bei Exchange Server 2003 finden Sie unter Behandeln von Leistungsproblemen bei Microsoft Exchange Server 2003.

Die Management Packs Ihres Speicherherstellers sind ebenfalls hilfreich. Diese Management Packs können Warnungen ausgeben, wenn die Kapazitäts-, Leistungs- und Fehlertoleranzschwellenwerte des Speichersystems überschritten werden.

Für bestimmte VSS-Lösungen müssen Sie die folgenden Hotfixes anwenden:

  • Für Windows Server 2003 mit SP1: 891957, 898790
  • Für Exchange Server 2003 mit SP1: 892514

Erfragen Sie beim Speicherhersteller, ob Sie diese Hotfixes benötigen.

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft