Speicherentwurf für Postfachserver

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2009-04-03

Das Vorhandensein ausreichender Datenträgerkapazität ist überaus wichtig. Wenn der Speicherplatz einer Datenbank vollständig belegt ist, wird die Datenbank offline geschaltet. Wenn der Speicherplatz auf einem Datenträger für Transaktionsprotokolle erschöpft ist, werden alle Datenbanken in dieser Speichergruppe offline geschaltet. Das Bereitstellen zusätzlichen Speicherplatzes kann oft nicht rasch erfolgen und eine Offlinekomprimierung zur Freigabe von Speicherplatz sehr lange dauern. In den meisten Fällen führt die Erschöpfung von Datenträgerspeicherplatz zu einer Unterbrechung der Verfügbarkeit einer oder mehrerer Datenbanken für einen Zeitraum, der meist die geforderten Wiederherstellungszeiten übersteigt.

Dieses Thema stellt die folgenden Informationen zur Verfügung:

• Postfachspeicherrechner für Exchange 2007

• Datenbank-LUN-Kapazität

• LUN-Kapazität für Protokolle

• Transaktionelle E/A

• Vorhersagen der Basis-E/A pro Sekunde von Exchange 2007

• Nicht transaktionelle E/A

• LUNs und physikalische Datenträger

• Auswirkung der fortlaufenden Replikation auf den Speicher

Postfachspeicherrechner für Exchange 2007

Mit dem Exchange Server 2007 Mailbox Server Role Storage Requirements Calculator (Speicherrechner) können Sie Ihre Speicheranforderungen (E/A-Leistung und -Kapazität) sowie eine optimale logische Gerätenummer (Logical Unit Number, LUN) basierend auf einer Reihe von Eingabefaktoren festlegen. Der Entwurf einer optimalen Speicherlösung für einen Exchange 2007-Postfachserver setzt die Einbeziehung vieler Eingabefaktoren voraus. Diese Eingabefaktoren werden in diesem Thema näher erläutert.

Mit dem Speicherrechner können Sie auf Ihre Organisation abgestimmte Werte eingeben. Weiterhin erhalten Sie Empfehlungen für die E/A-Anforderungen, Kapazitätsanforderungen und den optimalen LUN-Entwurf.

Weitere Informationen zum Speicherrechner und dessen Verwendung finden Sie im Exchange-Teamblogartikel unter Exchange 2007 Mailbox Server Role Storage Requirements Calculator (hier können Sie den Rechner ebenfalls herunterladen).

Datenbank-LUN-Kapazität

Zum Festlegen der Größe einer Datenbank-LUN verwenden Sie mehrere Datenpunkte. Darüber hinaus sind andere Faktoren zu berücksichtigen. Nachdem alle Faktoren geprüft und berechnet wurden, wird empfohlen, einen zusätzlichen Overheadfaktor für die Datenbank-LUN von 20 Prozent einzuplanen. Dieser Wert berücksichtigt andere Daten in der Datenbank, die beim Berechnen von Postfachgrößen und freien Speicherbereichen ggf. nicht angezeigt werden. Beispielsweise trägt die Datenstruktur (Tabellen, Sichten, interne Indizes usw.) der Datenbank zur Gesamtgröße der Datenbank bei. Beispiel: Wenn Sie nach dem Lesen der folgenden Unterabschnitte feststellen, dass Sie 120 GB benötigen, wird empfohlen, 144 GB bereitzustellen, um einen Sicherheitspuffer von 20 Prozent für die Datenbank-LUN dieser Speichergruppe einzurichten.

Postfachkontingent

Die erste wichtige Kennzahl ist die Postfachgröße. Wenn Sie die Datenmenge kennen, die ein Endbenutzer in seinem Postfach speichern darf, können Sie bestimmen, wie viele Benutzer der Server unterstützen kann. Wenngleich sich die Postfachgrößen und -kontingente zumeist ändern, ist ein geeigneter Zielwert der erste Schritt beim Bestimmen der benötigten Kapazität. Beispiel: Wenn es auf einem Server 5.000 Benutzer mit einem Postfachkontingent von 250 MB gibt, benötigten Sie mindestens 1,25 TB (Terabyte) Speicherplatz. Wenn keine festen Postfachkontingente festgelegt wurden, ist eine Ermittlung der benötigten Kapazität schwierig.

Freier Speicherplatz in der Datenbank

Die Datenbankgröße auf dem physikalischen Datenträger entspricht nicht nur der Anzahl der Benutzer multipliziert mit dem Benutzerkontingent. Wenn die Mehrzahl der Benutzer ihr Postfachkontingent nicht voll ausschöpft, belegen die Datenbanken weniger Speicherplatz und freier Speicherplatz ist kein Kapazitätsproblem. Die Datenbank selbst weist stets freie Seiten oder freien Speicherplatz auf, die überall verteilt sind. Während einer Onlinewartung werden zum Entfernen aus der Datenbank markierte Objekte entfernt, wodurch diese Seiten freigegeben werden. Der Prozentsatz an leeren Seiten ändert sich ständig, wobei der Prozentsatz nach einer Onlinewartung am höchsten und unmittelbar vor einer Onlinewartung am niedrigsten ist.

Die Größe der leeren Seiten in der Datenbank kann über die Menge der von den Benutzern mit Postfächern in der Datenbank gesendeten und empfangen E-Mails geschätzt werden. Wenn es z. B. 100 Postfächer mit 2 GB (insgesamt 200 GB) in einer Datenbank gibt, in der die Benutzer durchschnittlich 10 MB an E-Mails pro Tag empfangen, dann beträgt der Umfang der leeren Seiten ungefähr 1 GB (100 Postfächer × 10 MB pro Postfach).

Die Anzahl leerer Seiten kann über einen Annäherungswert hinaus ansteigen, wenn bei der Onlinewartung kein vollständiger Durchlauf erfolgen kann. Es ist wichtig, dass für die Betriebsaktivitäten genügend Zeit für eine allnächtliche Onlinewartung eingeplant wird, damit ein vollständiger Durchlauf innerhalb einer Woche oder schneller erfolgen kann.

Datenbankpapierkorb

Jede Datenbank hat einen "Papierkorb", in dem mittels Soft-Deletion gelöschte Objekte gespeichert werden. In Microsoft Exchange Server 2007 werden Elemente standardmäßig 14 Tage gespeichert. Dazu zählen Elemente, die aus dem Ordner Gelöschte Elemente entfernt wurden. Im Vergleich zu Exchange Server 2003 weist Exchange 2007 einen größeren vom Datenbankpapierkorb belegten Speicherplatz auf, da gelöschte Elemente nun doppelt so lange gespeichert werden.

Nach Ablauf des Aufbewahrungszeitraums werden diese Elemente während einer Onlinewartung aus der Datenbank entfernt. Letztlich wird ein stetiger Status erreicht, bei dem die Papierkorbgröße gemäß einem Prozentsatz der Größe Ihrer Datenbank dem Volumen sämtlicher eingehender/ausgehender E-Mails von zwei Wochen entspricht. Der genaue Prozentsatz hängt vom Volumen gelöschter E-Mails und den einzelnen Postfachgrößen ab.

Der Papierkorb fügt der Datenbank abhängig von der Größe des Postfachs und der Nachrichtenübermittlungsrate dieses Postfachs einen Prozentsatz an Overhead hinzu. Beispiel: Bei einer konstanten Nachrichtenübermittlungsrate von 52 MB pro Woche speichert ein Postfach mit einem "Sehr hoch"-Profil von 250 MB ca. 104 MB im Papierkorb, was einem Overhead von 41 Prozent entspricht. Ein 1 GB-Postfach, das ebenfalls 104 MB im Papierkorb speichert, fügt einen Overhead von 10 Prozent hinzu.

Tatsächliche Postfachgröße

Mit der Zeit erreichen Benutzerpostfächer das Postfachkontingent, weshalb ein E-Mail-Volumen, das der eingehenden E-Mail entspricht, gelöscht werden muss, um unter dem Postfachkontingent zu bleiben. Dies bedeutet, dass der Papierkorb eine Maximalgröße erreicht, die sämtlichen eingehenden/ausgehenden E-Mails von zwei Wochen entspricht. Wenn die Mehrzahl der Benutzer das Postfachkontingent noch nicht ausgeschöpft hat, werden nur einige eingegangene/ausgegangene E-Mails gelöscht, sodass sich die Zunahme auf den Papierkorb und die Erhöhung der Postfachgröße verteilt. Beispiel: Ein Postfach mit einem hohen Nachrichtenfluss von 250 MB, in das pro Woche 52 MB an E-Mails eingeht (bei einer durchschnittlichen Nachrichtengröße von 50 KB), belegt auch 104 MB im Papierkorb (41 Prozent) und 7.3 MB an leeren Seiten bei einer gesamten Postfachgröße von 360 MB. Weiteres Beispiel: Ein Postfach von 2 GB, in das pro Woche 52 MB an E-Mails eingeht, belegt auch 104 MB im Papierkorb (5 Prozent) sowie 7.3 MB an leeren Seiten bei einer gesamten Postfachgröße von 2,11 GB. Fünfzig Postfächer mit 2 GB in einer Speichergruppe entsprechen 105,6 GB.

Es folgt eine Formel, die das Bestimmen der Datenbankgröße anhand des Postfachs mit 2 GB veranschaulicht:

Postfachgröße = Postfachkontingent + Leere Seiten + (Wöchentlich eingehende E-Mails × 2)

Postfachgröße = 2,048 MB + (7.3 MB) + (52 MB x 2)

2,159 MB = 2,048 MB + 7.3 MB + 104 MB (5 % größer als das Kontingent)

Nachdem Sie die geplante tatsächliche Postfachgröße bestimmt haben, können Sie diesen Wert verwenden, um die maximale Anzahl von Benutzern pro Datenbank zu ermitteln. Nehmen Sie die geplante Postfachgröße und teilen Sie diese durch die maximal empfohlene Datenbankgröße. Dies hilft Ihnen auch beim Ermitteln, wie viele Datenbanken erforderlich sind, um die geplante Benutzeranzahl zu bedienen, wobei angenommen wird, dass die Datenbanken vollständig aufgefüllt sind. Beachten Sie, dass Sie aufgrund der nicht transaktionellen E/A oder wegen der Hardwarebeschränkungen möglicherweise die Anzahl der Benutzer ändern müssen, die einem einzelnen Server zugeordnet wird. Einige Administratoren bevorzugen die Verwendung mehrerer Datenbanken, um die Datenbankgröße noch weiter zu reduzieren. Dieser Ansatz kann mithilfe von Fenstern für die Sicherung und Wiederherstellung auf Kosten der Komplexität beim Verwalten einer größeren Anzahl von Datenbanken pro Server unterstützt werden.

Inhaltsindizierung

Bei der Inhaltsindizierung wird ein Index oder Katalog erstellt, mit dessen Hilfe die Benutzer ihre E-Mail-Objekte schnell und einfach durchsuchen können, anstatt das Postfach manuell zu durchlaufen. Exchange 2007 erstellt einen Index, der ungefähr 5 Prozent der gesamten Datenbankgröße entspricht und auf der gleichen LUN gespeichert wird, wie die Datenbank. Eine zusätzliche Kapazität von 5 Prozent muss bei der Größe der Datenbank-LUN für die Inhaltsindizierung berücksichtigt werden.

Wartung

Eine Datenbank, die offline repariert oder komprimiert werden muss, benötigt Kapazität, die der Größe der Zieldatenbank plus 10 Prozent entspricht. Unabhängig davon, ob Sie ausreichend Speicherplatz für eine einzelne Datenbank, eine Speichergruppe oder einen Sicherungssatz zuordnen, muss für die Durchführung dieser Operationen zusätzlicher Speicherplatz verfügbar sein.

Speichergruppe für die Wiederherstellung

Wenn Sie eine Speichergruppe für die Wiederherstellung im Rahmen Ihrer Pläne für die Notfallwiederherstellung verwenden möchten, muss ausreichend Kapazität verfügbar sein, um alle Datenbanken verarbeiten zu können, die gleichzeitig auf dem gewünschten Server wiederhergestellt werden können sollen.

Sicherung auf Datenträger

Viele Administratoren führen Onlinestreamingsicherungen auf einen Datenträger aus. Wenn Ihr Sicherungs- und Wiederherstellungsentwurf die Sicherung auf Datenträgern vorsieht, muss auf dem Server genügend Kapazität vorhanden sein, um die Sicherung zu unterstützen. Je nach verwendetem Typ der Sicherung kann diese Kapazität der Größe der Datenbank und Protokolle oder aber der Größe der Datenbank und aller Protokolle seit der letzten vollständigen Sicherung entsprechen.

LUN-Kapazität für Protokolle

Die Transaktionsprotokolldateien enthalten eine Aufzeichnung aller vom Datenbankmodul durchgeführten Transaktionen. Alle Transaktionen werden zuerst in das Protokoll und anschließend ganz allmählich in die Datenbank geschrieben. Im Gegensatz zu früheren Versionen von Exchange wurde die Größe der Transaktionsprotokolldateien in Exchange 2007 von 5 MB auf 1 MB reduziert. Diese Änderung ist erfolgt, um die fortlaufende Replikation zu unterstützen und den Umfang des Datenverlusts zu minimieren, sollte das primäre Speichermedium ausfallen.

Die folgende Tabelle kann verwendet werden, um die Anzahl der auf einem Exchange 2007-Postfachserver generierten Transaktionsprotokolle bei einer durchschnittlichen Nachrichtengröße von 50 KB einzuschätzen.

Anzahl der für jedes Postfachprofil generierten Transaktionsprotokolle

Postfachprofil	Nachrichtenprofil	Generierte Protokolle / Postfach
Niedrig	5 gesendet/20 empfangen	6
Mittel	10 gesendet/40 empfangen	12
Hoch	20 gesendet/80 empfangen	24
Sehr hoch	30 gesendet/120 empfangen	36
Außerordentlich hoch	40 gesendet/160 empfangen	48

Die folgenden Richtlinien wurden erstellt, um den Einfluss der Nachrichtengröße auf die Protokollgenerierungsrate festzulegen:

• Wenn sich die durchschnittliche Nachrichtengröße von 100 KB verdoppelt, nehmen die pro Postfach generierten Protokolle um den Faktor 1,9 zu. Diese Zahl stellt den Prozentsatz der Datenbank dar, die die Anlagen und Nachrichtentabellen (Nachrichtentexte und Anlagen) enthält.

• Bei einer Verdopplung der Nachrichtengröße von 100 KB verdoppelt sich die Protokollgenerierungsrate pro Postfache ebenfalls.

Beispiel:

• Bei einem Postfachprofil mit einem hohen Nachrichtenfluss und einer durchschnittlichen Nachrichtengröße von 100 KB beträgt die Anzahl der pro Postfach erstellen Protokolle 24 × 1,9 = 46.

• Bei einem Postfachprofil mit einem hohen Nachrichtenfluss und einer durchschnittlichen Nachrichtengröße von 200 KB beträgt die Anzahl der pro Postfach erstellen Protokolle 24 × 3,8 = 91.

Faktoren bei der Sicherung und Wiederherstellung

Die meisten Unternehmen, die nachts eine vollständige Sicherung durchführen, ordnen die Kapazität von Protokolldateien, die in ca. drei Tagen erstellt wurden, in einer Speichergruppe auf der Transaktionsprotokoll-LUN zu. Dies erfolgt, um zu verhindern, dass ein Sicherungsfehler dafür sorgt, dass das Protokolllaufwerk vollständig belegt wird, wodurch die Bereitstellung der Speichergruppe aufgehoben würde.

Die Bestimmung der Größe von Protokoll-LUNs hängt von Ihrem Sicherungs- und Wiederherstellungsentwurf ab. Wenn beispielsweise Ihr Entwurf zulässt, dass Sie zwei Wochen zurückgehen und alle seitdem erstellten Protokolle zurückspielen, benötigen Sie Protokolldateispeicher für zwei Wochen. Wenn Ihr Sicherungsentwurf wöchentliche vollständige und tägliche differenzielle Sicherungen vorsieht, muss die Protokoll-LUN größer als der Speicherplatz für Protokolle für eine gesamte Woche sein, um während des Zurückspeichern sowohl eine Sicherung als auch eine Wiederherstellung zu ermöglichen.

Verschieben von Postfächern

Das Verschieben von Postfächern ist ein wichtiger Kapazitätsfaktor bei großen Postfachbereitstellungen. In vielen Großunternehmen wird ein Prozentsatz der Benutzer nachts oder wöchentlich in andere Datenbanken, auf andere Server oder an andere Standorte verschoben. Wenn dies in Ihrer Organisation der Fall ist, müssen Sie ggf. die Protokoll-LUN mit mehr Kapazität ausstatten, um Benutzermigrationen zu unterstützen. Während der Quellserver die Datensatzlöschvorgänge protokolliert (die klein sind), muss der Zielserver zuerst alle übertragenen Daten in die Transaktionsprotokolle schreiben. Wenn Sie an einem Tag 10 GB an Protokolldateien erzeugen und einen dreitägigen Puffer von 30 GB eingerichtet haben, führt das Verschieben von 50 Postfächern mit 2 GB (100 GB) zur vollständigen Belegung der Zielprotokoll-LUN und dadurch zu Ausfallzeiten. In solchen Fällen müssen Sie ggf. den Protokoll-LUNs zusätzliche Kapazität zuordnen, um diese Postfachverschiebungen zu unterstützen.

Protokollwachstumsfaktor

Für die meisten Bereitstellungen wird empfohlen, beim Erstellen der Protokoll-LUN die Protokollgröße mit einem Overheadfaktor von 20 Prozent auszustatten (nach Berücksichtigung aller anderen Faktoren), um die erforderliche Kapazität bei einer unerwarteten Protokollgenerierung sicherzustellen.

Postfachkapazitätsplanung - Beispiel

Das folgende Beispiel veranschaulicht die entsprechende Bemessung der LUN-Größe für eine Umgebung, in der 4.000 Postfächer mit einem hohen Nachrichtenfluss von 1 GB auf einem einzelnen Postfachclusterserver in einer CCR-Umgebung (Cluster Continuous Replication) enthalten sind. Diese Postfächer empfangen durchschnittlich 52 MB an E-Mails mit einer durchschnittlichen Nachrichtengröße von 50 KB pro Woche. Die folgende Tabelle bietet Beispielwerte, die die tatsächliche Postfachgröße bestimmen.

Beispielwerte zum Bestimmen der tatsächlichen Postfachgröße auf dem Datenträger

Postfachgröße	Papierkorbgröße (2 Wochen)	Freier Speicherplatz	Gesamtgröße auf dem Datenträger
1 GB	104 MB ( 2 × 52 MB)	7,3 MB	1,11 GB (+ 11 %)

In dieser Umgebung verbraucht jeder Benutzer 1,11 GB Speicherplatz. Da die maximal empfohlene Datenbankgröße in einer CCR-Umgebung 200 GB entspricht, sollte der Server nicht mehr als 180 Postfächer pro Datenbank aufnehmen. Für die Unterstützung von 4.000 Postfächern sind 23 Datenbanken erforderlich und in dieser Umgebung wären außerdem 23 Speichergruppen vorhanden. Da die CCR-Umgebung eine Datenbank pro Speichergruppe voraussetzt, befindet sich jede Datenbank in einer eigenen Speichergruppe. Dies führt zu einem Endzähler für Postfächer pro Speichergruppe von 174. Basierend auf der Anzahl der Postfächer und der endgültigen Datenbankgröße sollte die Datenbank-LUN, wie in der folgenden Tabelle dargestellt, mindestens 193 GB umfassen

Anforderungen an die Datenbankkapazität

Postfächer pro Datenbank	Gesamtanzahl der Datenbanken	Anforderungen an die Datenbankgröße
174	23	193 GB

Um zu vermeiden, dass der Postfachserver aufgrund von Speicherzuordnungsproblemen ausfällt, muss die Größe der Transaktionsprotokolle ebenfalls festgelegt werden, um alle während des Sicherungssatzes generierten Protokolle problemlos zu speichern. Viele Organisationen, die die Sicherungsstrategie "täglich vollständig" verwenden, planen das Dreifache der täglichen Protokollgenerierungsrate für den Fall ein, dass die Sicherung nicht erfolgreich durchgeführt werden kann. Bei Verwendung einer wöchentlichen vollständigen und dabei differenziellen oder inkrementellen Sicherung ist mindestens die Protokollkapazität einer ganzen Woche erforderlich, um den Wiederherstellungsfall abzudecken. Wenn ein Postfach mit einem hohen Nachrichtenfluss durchschnittlich 42 Transaktionsprotokolle pro Tag generiert, generiert ein Postfachserver mit 4.000 Postfächern 168.000 Transaktionsprotokolle pro Tag. Bei dieser Rate erzeugt jede Speichergruppe 7,304 Protokolle. Zehn Prozent der Postfächer werden pro Woche an einem Tag (Samstag) verschoben und das Sicherungssystem bezieht wöchentliche vollständige und tägliche inkrementelle Sicherungen mit ein. Weiterhin kann der Server drei Tage ohne das Abschneiden von Protokollen tolerieren. Wie in der folgenden Tabelle dargestellt, benötigt dieser Server 38,8 GB Speicherplatz für jede einzelne Speichergruppe.

Anforderungen an die Protokollkapazität

Protokolle pro Speichergruppe	Größe der Protokolldatei	Tägliche Protokollgröße	Verschieben der Postfachgröße	Inkrementelle Wiederherstellungsgröße	Anforderungen an die Protokollgröße
7,304	1 MB	7,13 GB	17 GB (17 × 1 GB)	21,4 GB (3 × 7.13 GB)	38,8 GB (17.4 + 21.4)

Die Transaktionsprotokoll-LUN muss ausreichend groß sein, um sowohl die durch das Verschieben der Postfächer generierten Protokolle als auch den zum Wiederherstellen der Protokolle einer ganzen Woche erforderlichen Speicherplatz aufnehmen zu können.

Transaktionelle E/A

Als transaktionelle E/A wird die Datenträger-E/A bezeichnet, die von Benutzern des Servers verursacht wird. Datenträger-E/A wird beispielsweise durch das Empfangen, Senden und Löschen von Elementen verursacht. Microsoft Outlook-Benutzer, die nicht den Exchange-Cachemodus verwenden, werden direkt von der hohen Datenträgerlatenz beeinträchtigt. Dies ist einer der wichtigsten Aspekte beim Speicherlösungsentwurf. Die Anforderungen an die transaktionelle E/A für die Speicherung wurden reduziert. Bei einer fortlaufenden Replikation bedeutet hohe Verfügbarkeit nicht mehr, dass eine teure Fibre Channel-Speicherlösung verwendet werden muss (wenngleich diese immer noch eine sehr gute Lösung darstellt).

Grundlegendes zu E/As pro Sekunde

In früheren Exchange Server-Versionen war eine der benötigten Kennzahlen für die Bestimmung der Speichergröße die Menge der Datenbank-E/As pro Sekunde der einzelnen Benutzer. Um diesen Wert zu messen, muss die Menge der E/As (sowohl Lese- als auch Schreibvorgänge) der Datenbank-LUN für eine Speichergruppe durch die Anzahl der Benutzer in dieser Speichergruppe dividiert werden. Beispiel: 1.000 Benutzer, die 1.000 E/As in der Datenbank-LUN verursachen, bedeuten pro Benutzer 1 E/A pro Sekunde.

Messen der Basis-E/As pro Sekunde

Wenn Sie eine frühere Exchange Server-Version verwenden und einen Basiswert für die E/As pro Sekunde berechnet haben, beachten Sie, dass sich Exchange 2007 wie folgt auf Ihren Basiswert auswirkt.

• Die Anzahl der Benutzer auf dem Server wirkt sich auf den gesamten Datenbankcache pro Benutzer aus.

• Die Größe des Arbeitsspeichers (RAM) wirkt sich darauf aus, auf welche Größe der Datenbankcache anwachsen kann. Ein größerer Datenbankcache führt zu mehr Lesetreffern im Cache und verringert dadurch die Lese-E/A der Datenbank.

Ein Kernpunkt ist, dass das Wissen um die E/As pro Sekunde auf einem bestimmten Server nicht für die Planung eines gesamten Unternehmens ausreicht, da die Arbeitsspeichermenge sowie die Anzahl der Benutzer und Speichergruppen meist auf jedem Server unterschiedlich ist. Nachdem Sie die tatsächlichen Werte für die E/As pro Sekunde ermittelt haben, wenden Sie stets einen E/A-Overheadfaktor von 20 Prozent auf Ihre Berechnungen an, um für mehr Spielraum zu sorgen. Wenn die Aktivität höher als normal ist, kann somit ein schwaches Anwendungsverhalten vermieden werden.

Datenbankcache

Eine 64-Bit-Version von Windows Server, unter der die 64-Bit-Version von Exchange 2007 ausgeführt wird, bietet einen wesentlich größeren virtuellen Adressraum und ermöglicht Exchange die Vergrößerung seines Datenbankcache, eine Verringerung der Lese-E/A-Vorgänge in der Datenbank und bis zu 50 Datenbanken pro Server.

Die Verringerung der Datenbanklesevorgänge hängt von dem auf dem Server verfügbaren Datenbankcache und dem Benutzernachrichtenprofil ab. Anleitungen zu Arbeitsspeicher und Speichergruppen finden Sie unter Planen von Prozessorkonfigurationen. Das Befolgen der Anleitungen in diesem Thema kann zu einer Verringerung der transaktionellen E/A von bis zu 70 Prozent im Vergleich zu Exchange 2003 führen. Die Größe des Datenbankcache pro Benutzer ist ein Hauptfaktor bei der tatsächlichen E/A-Verringerung.

Die folgende Tabelle veranschaulicht die Zunahme des tatsächlichen Datenbankcaches pro Benutzer durch den Vergleich der standardmäßigen 900 MB in Exchange 2003 mit dem 5 MB großen Datenbankcache pro Benutzer in Exchange 2007. Es ist dieser zusätzliche Datenbankcache, der mehr Lesetreffer im Cache ermöglicht, wodurch die Datenbanklesevorgänge auf Datenträgerebene reduziert werden.

Datenbankcachegrößen basierend auf der Postfachanzahl

Postfachanzahl	Exchange 2003-Datenbankcache/Postfach (MB)	Exchange 2007-Datenbankcache/Postfach (MB)	Zunahme des Datenbankcaches im Vergleich zu Exchange 2003
4,000	0.225	5	23 Mal
2,000	0.45	5	11 Mal
1,000	0.9	5	6 Mal
500	1.8	5	3 Mal

Vorhersagen der Basis-E/A pro Sekunde von Exchange 2007

Die beiden größten Faktoren, die zum Vorhersagen der IOPS von Exchange 2007-Datenbanken verwendet werden können, sind die Größe des Datenbankcaches pro Benutzer und die Anzahl der Nachrichten, die jeder Benutzer pro Tag sendet und empfängt. Die folgende Formel basiert auf einem Standardbenutzer, der Office Outlook 2007 im Exchange-Cachemodus verwendet und Genauigkeitsschwankungen von +/- 20 Prozent unterliegt. Andere Clienttypen und Verwendungsszenarien führen möglicherweise zu ungenauen Ergebnissen. Die Vorhersagen sind nur für Cachegrößen von Benutzerdatenbanken zwischen 2 MB und 5 MB gültig. Die Formel wurde nicht mit Benutzern bestätigt, die über 150 Nachrichten pro Tag senden und empfangen. Die durchschnittliche Nachrichtengröße für die Formelvalidierung betrug 50 KB, wobei die Nachrichtengröße nicht den Hauptfaktor für IOPS darstellt.

Die folgende Tabelle bietet geschätzte Werte für IOPS pro Benutzer, mit denen Sie Ihre Exchange 2007-Basisanforderungen an die E/As pro Sekunde vorhersagen können.

Datenbankcache und geschätzter IOPS pro Benutzer auf Basis von Benutzerprofil und Nachrichtenaktivität

Benutzertyp (Verwendungsprofil)	Anzahl der täglich gesendeten/empfangenen Nachrichten mit einer Größe von ca. 50 KB	Datenbankcache pro Benutzer	Geschätzte E/As pro Sekunde pro Benutzer
Niedrig	5 gesendet/20 empfangen	2 MB	0.11
Mittel	10 gesendet/40 empfangen	3,5 MB	0.18
Hoch	20 gesendet/80 empfangen	5 MB	0.32
Sehr hoch	30 gesendet/120 empfangen	5 MB	0.48
Außerordentlich hoch	40 gesendet/160 empfangen	5 MB	0.64

Zum Schätzen der Größe des Datenbankcaches ziehen Sie 2.048 MB (3.072 MB bei Verwendung von LCR) von der auf dem Exchange-Server installierten Gesamtmenge des Speichers ab, und teilen Sie den Betrag durch die Anzahl der Benutzer. Für einen Server mit beispielsweise 3.000 Benutzern und 16 GB RAM werden 2 GB für das System abgezogen, bleiben 14 GB RAM oder 4,66 MB pro Benutzer (14 GB/3,000 = 4,66 MB).

Mit dem Wissen, dass die Cachegröße für eine durchschnittliche Datenbank 4,66 MB und die durchschnittliche Anzahl von gesendeten und empfangenen Nachrichten 60 entsprach, können Sie sowohl Lese- als auch Schreibvorgänge in Datenbanken schätzen.

• Datenbanklesevorgang   Zuerst nehmen Sie die 60 Nachrichten pro Tag und multiplizieren diese mit 0,0048, wodurch sich der Wert 0,288 ergibt. Als nächstes nehmen Sie die Menge des Datenbankcaches pro Postfach (4,77 MB) zur 0,65 Potenz (5 ^ -0,65) und erhalten 0,3622. Abschließend multiplizieren Sie die beiden Werte, wodurch sich 0,104 Datenbanklesevorgänge pro Benutzer ergeben (0,288 × 0,3622 = 0,104).

• Datenbankschreibvorgang   Multiplizieren Sie die Anzahl der Nachrichten pro Benutzer (60) mit 0,00152, wodurch sich 0,0912 Datenbankschreibvorgänge pro Benutzer ergeben.

Dabei wird folgende Formel verwendet:

((0.0048 × M) × (D ^ -0,65)) + (0,00152 × M) = gesamte Datenbank-IOPS

wobei M die Anzahl der Nachrichten und D den Datenbankcache pro Benutzer angibt. Die gesamten Datenbank-IOPS pro Benutzer ergeben sich durch Addieren der Lese- und Schreibvorgänge, was in diesem Beispiel zu 0,189 IOPS führt.

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

Das folgende Diagramm veranschaulicht die Reduzierung der Datenbanklese- und -schreibvorgänge bei der Ausführung von Exchange 2007 mit 4.000 Postfächern mit einer Nachrichtengröße von 250 MB, die Outlook 2007 im Exchange-Cachemodus simuliert, sowie den empfohlenen Serverspeicher.

Reduzieren der IOPS in Exchange Server 2007 im Vergleich zu Exchange Server 2003

Auswirkungen der Clients im Onlinemodus

Im Gegensatz zu Exchange-Clients im Cachemodus werden alle Clientoperationen im Onlinemodus für die Datenbank ausgeführt. Die Lesevorgänge für die Datenbank werden daher erhöht. Wenn die Mehrheit der Clients im Onlinemodus arbeitet, stehen die folgenden Richtlinien zur Verfügung:

• Im Vergleich zu Exchange-Clients im Cachemodus erhöhen 250 MB-Clients im Onlinemodus die Lesevorgänge um den Faktor 1,5. Bei einer Größe von unter 250 MB sind die Auswirkungen sehr gering.

• Bei einer Verdopplung der Postfachgröße wird die Datenbanklese-IOPS ebenfalls verdoppelt (bei einer gleichmäßigen Verteilung der Objekte auf die jeweiligen Hauptordner).

Das folgende Diagramm veranschaulicht IOPS basierend auf der Postfachgröße.

Datenbanklese-IOPS nimmt im Verhältnis zur Postfachgröße zu

Tests haben ebenfalls gezeigt, dass die Erhöhung des Datenbankcache auf über 5 MB pro Postfach die Anforderungen an die Lese-E/A der Datenbank nicht sonderlich reduziert. Das folgende Diagramm stellt Clients im Onlinemodus mit 2 GB-Postfächern dar. Zudem werden die Auswirkungen dargelegt, die die Erhöhung des Cache über 5 MB auf die Reduzierung der Datenbanklese-E/A hat.

Datenbanklese-IOPS vermindert die Cachegröße pro Postfachzunahme

Aufgrund der Analyse dieser Daten empfehlen wir die folgende Vorgehensweise:

• Stellen Sie Clients im Cachemodus bereit, sofern dies angemessen ist. Weitere Informationen finden Sie im Abschnitt "Elementanzahl pro Ordner" weiter unten.

• Stellen Sie sicher, dass die E/A-Anforderungen beim Entwerfen des Datenbankspeichers berücksichtigt werden.

Informationen zu weiteren IOPS-Faktoren, wie zum Beispiel Drittanbieterclients, finden Sie unter Optimizing Storage for Exchange Server 2003.

Verhältnis von Datenbanklese- und -schreibvorgängen

In Exchange 2003 betrug das Verhältnis von Datenbanklese- und -schreibvorgängen in der Regel 2:1 oder 66 Prozent Lesevorgänge. In Exchange 2007 verringert der größere Datenbankcache die Anzahl der Lesevorgänge in der Datenbank auf dem Datenträger, wodurch die Lesevorgänge prozentual zur gesamten E/A reduziert werden. Wenn Sie die Empfehlungen zum Arbeitsspeicher befolgt haben und den Exchange-Cachemodus verwenden, sollte das Verhältnis von Lese- und Schreibvorgängen näher bei 1:1 oder 50 Prozent Lesevorgängen liegen.

Bei Verwenden von Outlook im Onlinemodus oder von Desktopsuchmaschinen nimmt das Lese-/Schreib-Verhältnis auf der Leseseite geringfügig zu (abhängig von der Postfachgröße). Wenn prozentual zur gesamten E/A-Aktivität mehr Schreibvorgänge anfallen, hat dies besondere Auswirkungen bei der Auswahl eines RAID-Typs, der einen hohen Verarbeitungsaufwand bei Schreibvorgängen hat, wie z. B. RAID5 oder RAID6. Weitere Informationen zur Auswahl einer geeigneten RAID-Lösung für Ihre Server finden Sie unter Speichertechnologie.

Protokoll-/Datenbank-Verhältnis

In Exchange 2003 erfordert ein Transaktionsprotokoll für eine Speichergruppe ca. 10 Prozent der E/As der Datenbanken in der Speichergruppe. Beispiel: Verwendet die Datenbank-LUN 1.000 E/As, verwendet die Protokoll-LUN ca. 100 E/As. Durch die Verringerung der Datenbanklesevorgänge in Exchange 2007 in Kombination mit kleineren Protokolldateigrößen und der Möglichkeit zusätzlicher Speichergruppen beträgt das Protokoll-/Datenbank-Schreibverhältnis ca. 3:4. Wenn die Datenbank-LUN beispielsweise 500 Schreib-E/As benötigt, sind für die Protokoll-LUN ca. 375 Schreib-E/As erforderlich.

Nach dem Messen oder Schätzen der Transaktionsprotokoll-E/A sollten Sie einen E/A-Overheadfaktor von 20 Prozent anwenden, um für Phasen mit höherer Aktivität für Spielraum zu sorgen. Bei Verwenden der fortlaufenden Replikation müssen abgeschlossene Transaktionsprotokolle ferner gelesen und an einen zweiten Speicherort übertragen werden. Dieser zusätzliche Verarbeitungsaufwand führt zu 10 Prozent mehr Protokolllesevorgängen. Wenn das Transaktionsprotokoll einer Speichergruppe 375 Schreib-E/As erfordert, sind bei Verwenden der fortlaufenden Replikation 37,5 zusätzliche Lese-E/As zu erwarten.

Elementanzahl pro Ordner

Grundlagen der Auswirkungen einer großen Anzahl von Elementen und mit Einschränkungen versehener Ansichten auf die Leistung erläutert, wie die Anzahl der Elemente in Ihren kritischen Ordnern sowie der Typ und der Modus des verwendeten Clients sich auf die Festplattenleistung für einige Benutzer auswirken.

Eine Möglichkeit, die Server-E/A zu verringern besteht in der Verwendung von Outlook 2007 im zwischengespeicherten Exchange-Modus. Die anfängliche Postfachsynchronisierung ist ein verarbeitungsaufwändiger Vorgang, doch mit der Zeit (d. h. der Zunahme der Postfachgröße) wird die Verarbeitungslast des Datenträgersubsystems vom Server mit Exchange auf den Outlook-Client verlagert. Dies bedeutet, dass eine große Anzahl von Elementen im Posteingang eines Benutzers oder ein Benutzer, der ein Postfach durchsucht, nur wenig Auswirkung auf den Server hat. Dies bedeutet auch, dass Benutzer des Exchange-Cachemodus mit größeren Postfächern ggf. schnellere Computer als Benutzer mit kleinen Postfächern benötigen (abhängig vom Schwellenwert des einzelnen Benutzers für eine akzeptable Leistung). Wenn Sie Clientcomputer bereitstellen, die Outlook 2007 im Exchange-Cachemodus ausführen, berücksichtigen Sie die folgenden Aspekte hinsichtlich der Postfachgröße und der Größe der OST-Dateien:

• Bis zu 5 GB: Diese Größe sollte auf den meisten Hardwareplattformen eine gute Benutzererfahrung bereitstellen.

• Zwischen 5 GB und 10 GB: Diese Größe ist normalerweise hardwareabhängig. Daher ist die Benutzererfahrung besser, wenn eine schnelle Festplatte und eine große RAM-Menge verwendet werden. Mit langsameren Festplattenlaufwerken, z. B. Laufwerken, die normalerweise in portablen Computern verwendet werden, oder älteren Festkörperlaufwerken, kann es zu Anwendungsverzögerungen kommen, wenn die Laufwerke antworten.

• 10 GB oder mehr: Bei dieser Größe kommt es auf den meisten Hardwareplattformen zu kurzen Verzögerungen.

• Sehr groß, z. B. mindestens 25 GB: Bei dieser Größe steigt die Häufigkeit kurzer Verzögerungen, insbesondere beim Herunterladen neuer E-Mail-Nachrichten. Alternativ können Sende-/Empfangsgruppen zum manuellen Synchronisieren der Nachrichten verwendet werden.

Sollten leistungsbezogene Probleme mit Outlook 2007 bei der Bereitstellung im Exchange-Cachemodus auftreten, lesen Sie Knowledge Base-Artikel 940226 Beheben von Leistungsproblemen in Outlook 2007.

Sowohl Outlook Web Access als auch Outlook im Onlinemodus speichern Indizes und durchsuchen die Serverkopie der Daten. Bei Postfächern mit moderater Größe führt dies zu ca. einer Verdopplung der E/As pro Sekunde pro Postfach eines Exchange-Clients im Cachemodus vergleichbarer Größe. Die E/A pro Sekunde pro Postfach bei sehr großen Postfächern ist sogar noch höher. Wenn Sie eine Sicht auf eine neue Weise sortieren, wird ein Index erstellt, der viele E/A-Lesevorgänge der Datenbank-LUN verursacht. Nachfolgende Sortiervorgänge für einen aktiven Index haben einen sehr geringen Verarbeitungsaufwand.

Ein komplexes Szenario ist gegeben, wenn ein Benutzer die Anzahl der Indizes überschreitet, die Exchange speichern kann. Bei Exchange 2007 beträgt diese Anzahl 11 Indizes. Wenn der Benutzer auf eine neue Weise eine Sortierung durchführt und dadurch den zwölften Index erstellt, wird zusätzliche Datenträger-E/A verursacht. Da der Index nicht gespeichert wird, tritt diese Datenträger-E/A-Verarbeitung bei jedem Sortiervorgang ein. Aufgrund der hohen E/A, die in diesem Szenario generiert werden kann, wird ausdrücklich empfohlen, nicht mehr als 20.000 Elemente in Hauptordnern wie Posteingang und Gesendete Elemente zu speichern. Durch Erstellen weiterer Ordner auf erster Ebene oder von Unterordnern unter den Ordnern Posteingang und Gesendete Elemente wird der Verarbeitungsaufwand bei dieser Indexerstellung stark verringert, solange die Anzahl der Elemente in einem dieser Ordner nicht 20.000 überschreitet. Weitere Informationen dazu, wie sich die Elementanzahl auf die Leistung des Postfachservers auswirkt, finden Sie unter Recommended Mailbox Size Limits (englischsprachig) und Grundlagen der Auswirkungen einer großen Anzahl von Elementen und mit Einschränkungen versehener Ansichten auf die Leistung.

Weitere Informationen zu den verfügbaren Optimierungen finden Sie in Knowledge Base-Artikel 968009 Optimierungen von Outlook 2007 im kumulativen Update aus Februar 2009.

Nicht transaktionelle E/A

Die transaktionelle E/A erfolgt als Reaktion auf direkte Benutzeraktionen und hat meist die höchste Priorität, weshalb sie den Schwerpunkt beim Speicherentwurf bildet. Durch die Verringerung der transaktionellen E/A wird die nicht transaktionelle E/A noch wichtiger. Bei großen Postfächern, insbesondere im Fall des 2 GB-Postfachs, wird in vielen Unternehmen die Benutzerkapazität nicht verdoppelt, sondern mitunter verzehnfacht. Ein solches Beispiel ist der Wechsel von 200 MB zu 2 GB. Wenn sich die Menge der Daten auf einem Datenträger so stark erhöht, müssen Sie nun beim Planen des Speicherentwurfs die nicht transaktionelle E/A berücksichtigen.

Inhaltsindizierung

In Exchange 2007 werden eingehende Nachrichten indiziert, was nur sehr wenig E/A-Verarbeitungsaufwand erfordert. Das Durchsuchen des Indexes in Exchange 2007 erfolgt ca. 30 Mal schneller als in Exchange 2003.

Verwaltung von Nachrichtendatensätzen

Verwaltung von Messagingdatensätzen ist eine neue Funktion in Exchange 2007, die Administratoren und Benutzer bei der Verwaltung ihrer Postfächer unterstützt. Es können Richtlinien festgelegt werden, um E-Mails zu verschieben oder zu löschen, die bestimmte Kriterien erfüllen, z. B. Alter. Verwaltung von Messagingdatensätzen ist eine geplante Auffüllung, die im Abgleich mit der Datenbank in einem synchronen Lesevorgang ausgeführt wird, der einer Sicherung und Onlinewartung ähnelt. Der Verarbeitungsaufwand auf dem Datenträger von Verwaltung von Messagingdatensätzen hängt von der Anzahl der Elemente ab, die eine Aktion erfordern (z. B. Löschen oder Verschieben).

Es wird empfohlen, diese Funktion nicht gleichzeitig mit entweder einer Sicherung oder einer Onlinewartung auszuführen. Wenn Sie mit der fortlaufenden Replikation arbeiten, können Sie VSS-Sicherungen (Volume Shadow Copy Service) auf die passive Kopie verlagern, um mehr Zeit für die Onlinewartung und Verwaltung von Messagingdatensätzen einzuräumen, damit diese Funktionen sich nicht gegenseitig oder die Benutzer beeinträchtigen.

Onlinewartung

Wenn die Onlinewartung der Datenbank ausgeführt wird, erfolgen viele Aktionen, z. B. die dauerhafte Entfernung gelöschter Elemente oder die Onlinedefragmentierung der Datenbank. Die Wartung verursacht Lesevorgänge, die Onlinedefragmentierung Lese- und Schreibvorgänge. Die bis zum Abschluss der Wartung benötigte Zeit ist proportional zur Größe der Datenbank und kann sich einschränkend darauf auswirken, in welchem Maß Datenbanken anwachsen dürfen. Weitere Informationen zur Onlinewartung finden Sie unter Store Background Processes Part I.

Sichern und Wiederherstellen

Dem Administrator stehen viele verschiedene Methoden zum Sichern und Wiederherstellen zur Verfügung. Die Hauptkennzahl bei der Sicherung und Wiederherstellung ist der Durchsatz bzw. die Anzahl der Megabytes pro Sekunden, die in bzw. aus Ihren Produktions-LUNs kopiert werden können. Nach der Bestimmung des Durchsatzes müssen Sie entscheiden, ob dieser zur Erfüllung Ihrer Servicevereinbarung (SLA) für Sicherung und Wiederherstellung ausreicht. Beispiel: Wenn Sie in der Lage sein müssen, die Sicherung binnen 4 Stunden abzuschließen, müssen Sie für dieses Ziel ggf. weitere Hardware hinzufügen. Abhängig von Ihrer Hardwarekonfiguration können Sie durch Ändern der Zuordnungseinheitsgröße Vorteile erzielen. Dies kann beim Onlinestreamingsicherungen und der Exchange Server Database Utilities (Eseutil.exe)-Integritätsprüfung während einer VSS-Sicherung hilfreich sein.

Bei 2000 Benutzern auf einem Server führt ein Wechsel der Postfachgröße von 200 MB zu 2 GB zu einer zehnfachen Vergrößerung der Datenbank. Viele Administratoren sind das Arbeiten mit sehr großen Datenmengen auf einem einzelnen Server nicht gewohnt. Nehmen Sie z. B. einen Server mit 1000 Postfächer mit einer Größe von je 2 GB. Bei Berücksichtigung des zuvor beschriebenen Overheads handelt es sich um mehr als 4 TB Daten. Bei einem Sicherungsdurchsatz von 175 GB pro Stunde (48 MB pro Minute) dauert eine Sicherung des Servers mindestens 23 Stunden. Eine Alternative für Server, die nicht mit der lokalen fortlaufenden oder fortlaufenden Clusterreplikation arbeiten, ist die tägliche vollständige Sicherung von 1/7 der Datenbanken und eine inkrementelle Sicherung des Rests (siehe Tabelle 3).

Beispiel einer wöchentlichen Sicherungsroutine

Sicherungstyp	Tag 1	Tag 2	Tag 3	Tag 4	Tag 5	Tag 6	Tag 7
Vollständig	DB 1-2	DB 3-4	DB 5-6	DB 7-8	DB 9-10	DB 11-12	DB 13-14
Inkrementell	DB 3-14	DB 1-2 DB 5-14	DB 1-4 DB 7-14	DB 1-6 DB 9-14	DB 1-8 DB 11-14	DB 1-10 DB 13-14	DB 1-12

Wie die vorangehende Tabelle zeigt, beträgt die nachts zu sichernde Datenmenge ca. 650 GB, die bei einem angenommenen Durchsatz von 175 GB/h in 3,7 Stunden erfolgt. Einige Lösungen erzielen mehr oder weniger Durchsatz. Für große Postfächer müssen jedoch andere Methoden angewendet werden.

Bei der lokalen fortlaufenden Replikation und fortlaufenden Clusterreplikation stellt die passive Kopie die erste Schutzmaßnahme dar. Sie müssen nur eine Wiederherstellung aus einer Sicherung ausführen, wenn sowohl die aktive als auch die passive Kopie ausfallen oder auf sonstige Weise nicht verfügbar sind. Die Wiederherstellung inkrementeller Protokolle mehrerer Tage kann die Wiederherstellungsdauer verlängern. Deshalb wird die inkrementelle Sicherung für eine schnelle Wiederherstellungslösung, z. B. CCR- oder VVS-Klone, nur selten verwendet. Bei einem VSS-Klon erfolgt die Wiederherstellung der Daten sehr schnell. Der erhöhte Zeitaufwand für das Zurückspielen der Protokolle kann ggf. akzeptabel sein, um die Sicherungszeiten im Rahmen der Servicevereinbarung (SLA) für die Sicherung einzuhalten.

Onlinestreamingsicherung

Für Streamingsicherungen wird empfohlen, die Streaming-E/A (Quelle und Ziel) zu trennen, damit mehrere gleichzeitig zu sichernde Speichergruppen nicht um dieselben Datenträgerressourcen konkurrieren. Ist das Ziel ein Datenträger oder Band, gelten je nach Hardwarelösung Durchsatzbeschränkungen für die physikalischen Datenträger und Controller. Es ist u. U. erforderlich, einige Speichergruppen voneinander zu isolieren, um die Anzahl gleichzeitiger Sicherungsvorgänge und den Durchsatz zu maximieren, um das Zeitfenster für die Sicherung zu minimieren. Die folgende Tabelle ist ein Beispiel mit zwei gleichzeitigen Sicherungen von 14 Datenbanken veranschaulicht.

Beispiel einer gleichzeitigen Sicherungsroutine

Sicherungsnummer	LUN 1	LUN 2	LUN 3	LUN 4	LUN 5	LUN 6	LUN 7
Erste Sicherung	Speichergruppe (SG) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
Zweite Sicherung	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

Sie können Streamingsicherungen gleichzeitig ausführen, eine von jeder LUN, wenn Sie Ihre Speichergruppen-LUNs voneinander isolieren, wie in der vorangehenden Tabelle gezeigt. Die Sicherungsaufträge werden auf jeder LUN bei der ersten Speichergruppe abgeschlossen, bevor die zweite Speichergruppe mit der Sicherung beginnt, wodurch die Sicherungsdatenströme voneinander getrennt sind. Zwei Streamingsicherungsaufträge auf den gleichen physikalischen Datenträgern werden möglicherweise nicht doppelt so schnell ausgeführt, aber sie sollten hinsichtlich der Megabyte pro Sekunde schneller ausgeführt werden, als ein einzelner Streamingauftrag.

VSS-Sicherungen

Exchange 2007 verwendet den Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS) von Windows Server 2003, um Volumeschattenkopien von Datenbanken und Transaktionsprotokolldateien zu erstellen. Weitere Informationen über VSS, einschließlich Klon- und Snapshotmethoden, finden Sie auf der Website mit den bewährten Methoden für die Verwendung des Volumeschattenkopie-Diensts (VSS) mit Exchange Server 2003. Neu ist in Exchange 2007 die Möglichkeit, VSS-Sicherungen der passiven Kopie von Speichergruppen zu erstellen, die in einer LCR- oder CCR-Umgebung ausgeführt werden. In diesen Umgebungen wird durch Erstellen eines VSS-Snapshots von der passiven Kopie während der Prüfsummenintegritätsphase der Sicherung und dem nachfolgenden Kopieren auf Band oder Datenträger die Datenträgerlast von den aktiven LUNs entfernt. Außerdem ist mehr Zeit auf den aktiven LUNs verfügbar, um Onlinewartung, Verwaltung von Nachrichtendatensätzen (Messaging Records Management, MRM) und andere Aufgaben auszuführen.

LUNs und physikalische Datenträger

Häufig erkennt das Betriebssystem den physikalischen Datenträger oder dessen logische Gerätenummern (Logical Unit Number, LUN) in anderer Weise, da der Datenträger dem Betriebssystem durch die Hardware anderweitig angezeigt wird. Im Hinblick auf die Leistung und Wiederherstellung war es stets wichtig, Transaktionsprotokolldateien von den Datenbankdateien zu trennen, sowohl auf Ebene der LUN als auch auf Ebene der physikalischen Datenträger. Wenn zufällige und sequenzielle E/A-Vorgänge auf demselben physikalischen Datenträger kombiniert werden, führt dies zu einer Leistungsverringerung. Im Hinblick auf Wiederherstellungen wird durch die Trennung der Protokolldateien und Datenbankdateien einer Speichergruppe sichergestellt, dass ein schwerwiegender Fehler auf einem Satz physikalischer Datenträger nicht zum Verlust sowohl der Datenbankdateien als auch der Protokolldateien führt.

Eine bewährte Methode in Exchange 2007 besteht darin, alle Datenbanken in einer Speichergruppe auf derselben physikalischen LUN zu platzieren. Nicht mehr als eine Datenbank in jeder Speichergruppe zu platzieren, ist eine weitere bewährte Methode. E/A-Vorgänge der Exchange-Datenbank sind zufällig. Die meisten Speichersubsysteme profitieren davon, wenn die physikalischen Datenträger dieselbe Arbeitslast verarbeiten. Viele Speicherarrays sind so konzipiert, dass ein Großteil der physikalischen Datenträger zunächst in einer Datenträgergruppe zusammengefasst werden. Anschließend werden anhand des verfügbaren Speicherplatzes in dieser Gruppe die LUNs erstellt und gleichmäßig auf die einzelnen physikalischen Datenträger verteilt. Die physikalischen Datenträger, mit denen die Datenbank-LUN einer Speichergruppe gesichert wird, können ebenfalls als Sicherung für andere LUNs dienen, in denen Datenbanken für andere Speichergruppen und Server untergebracht sind. Ebenso ist es nicht wichtig, die Transaktionsprotokoll-LUNs der einzelnen Speichergruppen auf gesonderten physikalischen Spindles zu isolieren, obwohl sich der Verlust sequenzieller E/A-Vorgänge minimal auf die Leistung auswirkt.

Ist das Maximum von 50 Speichergruppen auf einem einzelnen Server konfiguriert, ist für die einzelnen Speichergruppen eine eigene Transaktionsprotokoll-LUN und Datenbank-LUN erforderlich. Die Anzahl der verfügbaren Laufwerkbuchstaben wird überschritten, und die Bereitstellungspunkte des NTFS-Volumes müssen verwendet werden. Wenn für die fortlaufende Replikation fünfzig Speichergruppen konfiguriert werden, sind 200 LUNs erforderlich. Hierdurch können die Höchstwerte einiger Speicherarrays überschritten werden, insbesondere bei der fortlaufenden lokalen Replikation (Local Continuous Replication, LCR), bei der alle 200 LUNs einem einzelnen Server angezeigt werden müssen. Mit zunehmender LUN-Anzahl wächst die Bedeutung der Überwachung, da ein Mangel an Speicherplatz dazu führt, dass die Bereitstellung der jeweiligen Speichergruppe aufgehoben wird.

LUN-Entwurf

In vielen Fällen wird die LUN, die das Betriebssystem erkennt, von der physikalischen Hardware, die sich tatsächlich hinter diesem "Datenträger" befindet, abstrahiert. Zur Optimierung von Leistung und Wiederherstellbarkeit war es stets wichtig, Transaktionsprotokolle sowohl auf LUN- als auch physikalischer Datenträgerebene zu trennen. Bei manchen Speicherarrays kann die Kombination von sowohl wahlfreier als auch sequenzieller E/A auf denselben physikalischen Datenträgern zu Leistungseinbußen führen. Aus Sicht der Wiederherstellbarkeit stellt das Trennen der Transaktionsprotokolle und Datenbanken einer Speichergruppe sicher, dass ein katastrophaler Ausfall eines bestimmten Satzes physikalischer Datenträger nicht zum Verlust von sowohl der Datenbank als auch der Transaktionsprotokollen führt.

Die Exchange-Datenbank-E/A ist überaus wahlfrei, und die meisten Speichersubsysteme profitieren, wenn die physikalischen Datenträger dieselbe Verarbeitungslast übernehmen. Viele Speicherarrays virtualisieren den Speicher so, dass ein Großteil der physikalischen Datenträger zunächst in einer Datenträgergruppe zusammengefasst wird. Anschließend werden anhand des verfügbaren Speicherplatzes in dieser Gruppe die LUNs erstellt und gleichmäßig auf die einzelnen physikalischen Datenträger verteilt. Wenn nicht mit der fortlaufenden Replikation gearbeitet wird, ist nichts dagegen einzuwenden, dass die physikalischen Datenträger, auf denen die Datenbank-LUN einer Speichergruppe gesichert wird, ebenfalls zum Sichern anderer LUNs dienen, in denen Datenbanken für andere Speichergruppen und Server untergebracht sind. Ebenso ist es nicht wichtig, die Transaktionsprotokoll-LUNs der einzelnen Speichergruppen auf gesonderten physikalischen Spindles zu isolieren, obwohl sich der Verlust sequenzieller E/A-Vorgänge minimal auf die Leistung auswirkt. Die Protokoll- und Datenbank-LUNs derselben Speichergruppe müssen auf jeden Fall auf getrennten physikalischen Datenträgern abgelegt werden. Es ist nicht realistisch, zwei oder vier physikalische Datenträger mit 500 GB für die Transaktionsprotokoll-LUN einer einzelnen Speichergruppe zu reservieren, wenn Sie 30 E/As pro Sekunde und 5 Prozent der Kapazität benötigen.

Wenngleich es für den Entwurf von LUNs in Exchange 2007 viele Möglichkeiten gibt, werden zum Eingrenzen der Komplexität die beiden folgenden Entwürfe empfohlen:

• 2 LUNs pro Speichergruppe

• 2 LUNs pro Sicherungssatz

2 LUNs pro Speichergruppe

Das Erstellen von 2 LUNs (eine für Protokolle und eine für Datenbanken) für eine Speichergruppe war die Standardvorgehensweise für Exchange 2003. Unter Exchange 2007 und bei maximal 50 Speichergruppen hängt die Anzahl der bereitgestellten LUNs von Ihrer Sicherungsstrategie ab. Wenn die angestrebte Wiederherstellungsdauer sehr kurz ist oder Sie VSS-Klone (Volume Shadow Copy Service, Volumeschattenkopie-Dienst) für eine schnelle Wiederherstellung verwenden, ist es ggf. am besten, jede Speichergruppe ihrer eigenen Transaktionsprotkoll-LUN und Datenbank-LUN zuzuordnen. Da dabei die Anzahl verfügbarer Laufwerkbuchstaben überschritten wird, müssen Datenträger-Bereitstellungspunkte verwendet werden.

Diese Strategie besitzt z. B. die folgenden Vorteile:

• Ermöglichung von hardwarebasiertem VSS auf Speichergruppenebene sowie der Sicherung und Wiederherstellung einzelner Speichergruppen.

• Flexibilität zum Isolieren der Leistung zwischen Speichergruppen.

• Höhere Zuverlässigkeit. Ein Kapazitäts-, Datenbeschädigungs- oder Virusproblem einer einzelnen LUN wirkt sich nur auf eine Speichergruppe aus.

Diese Strategie besitzt z. B. die folgenden Nachteile:

• Wenn für die fortlaufende Replikation 50 Speichergruppen konfiguriert werden, sind 200 LUNs erforderlich. Hierdurch können die Höchstwerte einiger Speicherarrays überschritten werden, insbesondere bei der fortlaufenden lokalen Replikation (Local Continuous Replication, LCR), bei der alle 200 LUNs einem einzelnen Server angezeigt werden müssen.

• Eine separate LUN für jede Speichergruppe sorgt für mehr LUNs pro Server, wodurch sich der Verwaltungsaufwand erhöht.

2 LUNs pro Sicherungssatz

Ein Sicherungssatz entspricht der Anzahl der Datenbanken, die in einer Nacht vollständig gesichert werden. Eine Lösung, die pro Nacht eine vollständige Sicherung von 1/7 der Datenbanken erstellt, kann die Komplexität reduzieren, indem alle zu sichernden Speichergruppen derselben Protokoll- und Datenbank-LUN zugeordnet werden. Dadurch kann die Anzahl der LUNs auf dem Server verringert werden.

Diese Strategie besitzt z. B. die folgenden Vorteile:

• Vereinfachung der Speicherverwaltung, da weniger LUNs zu verwalten sind.

• Potenzielle Reduzierung der Anzahl der Sicherungsaufträge.

Diese Strategie besitzt z. B. die folgenden Nachteile:

• Einschränkung der Fähigkeit, hardwarebasierte VSS-Sicherungen und -Wiederherstellungen durchzuführen.

• Einschränkung der Skalierungsmöglichkeiten der Kapazität ein durch den 2 TB-Grenzwert für eine MBR-Partition.

Datenträger-Bereitstellungspunkte

Es kommt häufig vor, z. B. bei Einzelkopieclustern mit mehreren Knoten, dass die Anzahl der erforderlichen LUNs die der verfügbaren Laufwerkbuchstaben überschreitet. In diesen Fällen müssen Sie mit Datenträger-Bereitstellungspunkten arbeiten. Laufwerkbuchstaben sind ein Relikt aus alten MS-DOS-Tagen zum Kennzeichnen von Partitionen und Datenträgern, und es empfiehlt sich, nicht zu viele Laufwerkbuchstaben zu verwenden. Zur Vereinfachung der Verwaltung sollten alle Transaktionsprotokoll- und Datenbank-LUNs einem Datenträger-Bereitstellungspunkt zugeordnet werden. Wenn Sie 20 Speichergruppen besitzen, von denen jede eine Datenbank aufweist, ist es schwierig sich zu merken, welcher Laufwerksbuchstabe zur Datenbank 17 zählt. In der folgenden Tabelle ist ein Beispiel zur Verwendung von Datenträger-Bereitstellungspunkten veranschaulicht.

Beispielordnerlayout unter Verwendung von Datenträger-Bereitstellungspunkten

Transaktionsprotokolle (L:)	Datenbanken (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

In diesem Beispiel sind L: und P: Anker-LUNs, die entsprechend alle Protokoll- und Datenbank-LUNs aufnehmen. Jeder Ordner auf diesen Laufwerken ist ein Datenträger-Bereitstellungspunkt für eine separate LUN.

Hardwarebasierter VSS (Volume Shadow Copy Service, Volumeschattenkopie-Dienst)

Beim Verwenden eines hardwarebasierten VSS sollten verschiedene Empfehlungen für das Ablegen von Exchange-Daten auf den LUNs befolgt werden. Bei einer hardwarebasierten VSS-Lösung sollte jede Transaktionsprotokoll- und Datenbank-LUN nur die Dateien in dem ausgewählten Sicherungssatz enthalten. Wenn Sie eine Speichergruppe wiederherstellen möchten, ohne andere Speichergruppen zu beeinträchtigen, benötigen Sie für jede Speichergruppe eine separate Transaktionsprotokolls- und Datenbank-LUN. Wenn Sie gewillt sind, andere Datenbanken und Speichergruppen offline zu schalten, um eine einzelne Datenbank wiederherzustellen, können Sie mehrere Speichergruppen in einer einzelnen Transaktionsprotokoll- und Datenbank-LUN ablegen.

Softwarebasierter VSS (Volume Shadow Copy Service, Volumeschattenkopie-Dienst)

Beim Verwenden eines softwarebasierten VSS umfasst die Sicherung, insbesondere bei großen Postfächern und fortlaufender Replikation, zwei Schritte. Erstellen Sie erstens einen VSS-Snapshot, und übertragen Sie zweitens die Flatfiles auf einen Datenträger oder ein Band.

LUN-Zuverlässigkeit

Die Transaktionsprotokolle und Datenbanken einer Speichergruppe sollten stets auf separaten physikalischen Datenträgern abgelegt werden, da dadurch die Zuverlässigkeit gesteigert wird. Bei der fortlaufenden Replikation müssen zudem die aktiven und passiven LUNs in vollständig separaten Speicherbereichen abgelegt werden. Bei der fortlaufenden Cluster- und lokalen Replikation ist Speicherausfallsicherheit besonders wichtig, sollte der primäre Speicher ausfallen.

LUN-Beispiel

Betrachten Sie das folgende Szenario, das auf dem vorherigen Kapazitätsbeispiel aufbaut und diese Informationen auf die Erstellung der LUN anwendet. In diesem Beispiel wird eine tägliche vollständige Sicherung als Sicherungssystem verwendet. Die Inhaltsindizierung soll aktiviert und deshalb auf der Datenbank-LUN angeordnet werden. Fünf Prozent von 193 GB sind ungefähr 10 GB. Dieser Wert muss zur endgültigen LUN-Größe hinzugezählt werden. Der Wachstumsfaktor für 193 GB sollte 20 Prozent der endgültigen Datenbankgröße betragen. 20 Prozent von 193 GB sind 39 GB. Die Ergebnisse werden in den folgenden Tabellen dargestellt.

Beispielwerte zum Bestimmten der Datenbank-LUN-Größe

Datenbankgröße	Wachstumsfaktor	Inhaltsindizierung	Größe der Datenbank-LUN
193 GB	39 GB	10 GB	241 GB

Jede Speichergruppe erstellt täglich 7,13 GB an Protokollen und es sollen mindestens die Protokolle von 3 Tagen gespeichert werden können.

Beispielwerte zum Bestimmten der Protokoll-LUN-Größe

Protokolle (1 Tag)	Protokolle (3 Tage)
7,13 GB	21,4 GB

Postfach verschieben

Unsere Beispielorganisation verschiebt 10 Prozent seiner Postfächer pro Woche und dieser Vorgang wird jeweils am Samstag ausgeführt. Daher muss die Protokoll-LUN die gesamte Last an einem Tag verarbeiten. Eine bei Microsoft verwendete Strategie zum Verschieben von Postfächern ist es, die eingehenden Benutzer gleichmäßig auf die einzelnen Speichergruppen zu verteilen. Das bedeutet, dass auf dem Beispielserver mit 4.000 Benutzern jeden Samstag ungefähr 400 Benutzer verschoben werden. Bei 23 Speichergruppen muss jede Speichergruppe 17 1-GB-Postfächer empfangen, wie in der folgenden Tabelle dargestellt.

Beispielwerte zum Bestimmten der Protokoll-LUN-Größe beim Verschieben von Postfächern

Protokolle (3 Tage)	Postfach verschieben	Größe der Protokoll-LUN
21,4 GB	17,64 GB (17 - 1 GB Benutzer)	46,6 GB (38,8 GB + 20 %)

Bei diesem Layout würden Sie an einem Tag nie mehr als 17 Benutzer in eine Speichergruppe verschieben. Daher ist es sinnvoller, die Größe der Protokoll-LUN für den Fall zu erhöhen, dass an einem bestimmten Tag mehr als 10 Prozent verschoben werden müssen.

Auswirkung der fortlaufenden Replikation auf den Speicher

Die fortlaufende Replikation ist ein neues Feature in Exchange 2007: die Datenbank- und Protokolldateien einer Speichergruppe werden an einen sekundären Speicherort kopiert. Wenn neue Transaktionsprotokolldateien geschlossen werden oder voll sind, werden sie an den sekundären Speicherot kopiert, überprüft und dann in die passive Kopie der Datenbank eingespielt. Um im Hinblick auf Speicher Flexibilität zu erzielen, sollten Sie die passive Kopie in einem Speicherarray platzieren, das vollständig von den Produktions-LUNs getrennt ist. Da die passive Kopie im Notfall die Produktionslast verarbeiten muss, sollte ihr Speicher der Leistung und Kapazität der Speicherlösung entsprechen, die für die aktive Kopie der Speichergruppe verwendet wird.

Bei der Verwendung der fortlaufenden Replikation kann jede Speichergruppe nur eine einzelne Datenbank enthalten, sodass für jede Datenbankkopie vier LUNs benötigt werden. Jede Datenbankkopie befindet sich in einer eigenen Speichergruppe, die gesonderte Protokoll- und Datenbank-LUNs für die aktive und die passive Kopie der Datenbank benötigt.

Im Folgenden werden die bewährten Methoden aufgeführt:

• Teilen Sie den Speicher auf Hardwareebene in einzelne LUNs auf, und erstellen Sie innerhalb des Betriebssystems nicht mehrere logische Partitionen einer LUN.

• Trennen Sie Transaktionsprotokolle und Datenbanken, und platzieren Sie sie auf gesonderten physikalischen Datenträgern, um die Fehlertoleranz zu erhöhen.

• Trennen Sie aktive und passive LUNs in verschiedenen Speicherarrays, sodass der Speicher keine einzelne Fehlerquelle darstellt.

• Beim Hosten von Speichergruppen oder Datenbanken von mehreren Postfachclusterservern auf demselben Speicherarray sollten Sie sicherstellen, dass jede LUN unter Verwendung von separaten physischen Datenträgern erstellt wird.

In Ihrem Speicherentwurf sollte ebenfalls die Fehlertoleranz durch Unterbringen der Speichercontroller auf verschiedenen PCI-Bussen maximiert werden. Darüber hinaus sollte der Speicher für die passive Kopie im Hinblick auf Kapazität und Leistung dem der aktiven Kopie entsprechen. Der Speicher der passiven Kopie stellt bei schwerwiegenden Fehlern im Speicher der aktiven Kopie die erste Schutzmaßnahme dar. Im Fall eines Failovers wird die passive Kopie zur aktiven Kopie. Durch Platzieren der LUNs der passiven Kopie auf anderer Speicherhardware wird gewährleistet, dass keine für die passive Kopie durchgeführte Aktion sich auf die aktive Kopie auswirkt.

Bei der fortlaufenden Replikation nehmen die transaktionellen E/A-Vorgänge zu. Dieser Faktor muss bei der Größenplanung des Servers berücksichtigt werden. Die aktive Transaktionsprotokollierung, die einen sequenziellen Schreibvorgang darstellt, muss ebenfalls das Protokoll lesen, nachdem es geschlossen und in den Quarantäneordner der replizierenden Transaktionsprotokoll-LUNs kopiert wurde. Das Protokoll muss dann am Replikatsspeicherort geprüft und an seinen endgültigen Speicherort auf der replizierenden LUN verschoben werden. Schließlich wird das Protokoll gelesen und in die Datenbank eingespielt. Im Gegensatz zu einem eigenständigen Postfachserver, auf dem beinahe 100 % der sequenziellen Schreibaktivitäten festzustellen sind, müssen sowohl aktiven als auch replizierenden LUNs Transaktionsprotokolldateien lesen und schreiben. Diese Verhaltensänderung erfordert u. U. eine Neubewertung der Cacheeinstellungen auf Ihrem Speichercontroller. Für einen akkuunterstützten Speichercontroller sollten in den Einstellungen 25 % für Lesevorgänge und 75 Prozent für Schreibvorgänge festgelegt werden.

Fortlaufende Replikation und Datenbankgröße

Eine höhere maximale Datenbankgröße ist möglich, wenn die fortlaufende Replikation verwendet wird. Für Exchange 2007 werden die folgenden maximalen Datenbankgrößen empfohlen:

• Auf einem Postfachserver ohne fortlaufende Replikation gehostete Datenbanken: 100 GB

• Auf einem Postfachserver mit fortlaufender Replikation und Gigabit-Ethernet gehostete Datenbanken: 200 GB

  Hinweis

  Umfangreiche Datenbanken erfordern möglicherweise auch aktuellere Speichertechnologien für höhere Bandbreiten, um Reparaturszenarien zu entsprechen.

  Wichtig

  Die wahre maximale Größe für Ihre Datenbank sollte durch die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) festgelegt sein, die in Ihrer Organisation besteht. Durch die Ermittlung der größtmöglichen Datenbank, die innerhalb des in der Vereinbarung zum Servicelevel Ihrer Organisation angegebenen Zeitraums gesichert und wiederhergestellt werden kann, bestimmen Sie die maximale Größe für Ihre Datenbanken.

Speicheroptionen der LCR

Die LCR ermöglicht den Protokollversand auf einem einzelnen Server. Tritt im Speicher, in dem sich die aktive Kopie der Datenbank- und Protokolldateien befindet, ein schwerwiegender Fehler auf, kann der Administrator die passive Kopie der Datenbank manuell aktivieren. Der Speicher für die passive Kopie sollte von dem der aktiven Kopie vollständig getrennt sein. Darüber hinaus gilt Folgendes:

• Controllerkarten sollten sich auf einem anderen PCI-Bus befinden.

• Jede Speicherlösung sollte über eine eigene USV verfügen.

• Jede Speicherlösung sollte sich in einem gesonderten Stromkreis befinden.

Speicheroptionen der CCR

Die CCR ermöglicht den Protokollversand an einen passiven Knoten in einem Aktiv/Passiv-Failovercluster. Indem die Protokolle an einen anderen Server gesendet und die passive Kopie dort gespeichert wird, werden die Auswirkungen auf den aktiven Knoten verringert, und der Server bietet Fehlertoleranz.

In einer geografisch verteilten CCR-Bereitstellung kann sich die passive Kopie auf einem Knoten befinden, der sich an einem anderen physikalischen Standort befindet als der aktive Knoten. Hierdurch wird Standortflexibilität bereitgestellt. Die Angaben aus dem Artikel zu Bereitstellungsrichtlinien für die Replikation von Daten zwischen mehreren Exchange Server-Standorten treffen noch immer zu, dennoch wirkt sich häufige Wartezeit aufgrund der Technologie, die der fortlaufenden Replikation zugrunde liegt, nicht auf die Benutzererfahrung aus. Dies stellt einen scharfen Kontrast zur geografisch verteilten Clusterlösung dar, in der die Wartezeit der synchronen Replikation den aktiven Server beeinträchtigt. Mit der CCR kann der Replikationsprozess im Hintergrund betrieben werden, wobei die Zeitspanne, in der die aktive und passive Kopie nicht synchronisiert werden, ansteigt. Wenn jedoch Daten der aktiven Kopie verloren gehen, können Nachrichten, die nicht auf den passiven Knoten repliziert wurden, mittels des Transportpapierkorb-Features des Hub-Transport-Servers wiederhergestellt werden.

Speicheroptionen des Einzelkopieclusters

Die in einem Einzelkopiecluster (Single Copy Cluster, SCC) verwendete Hardware muss in der Clusterkategorie des Windows Server-Katalogs aufgeführt werden. Die für einen geografisch verteilten Einzelkopiecluster verwendete Hardware muss in der Kategorie der geografisch verteilten Cluster im zu unterstützenden Windows Server-Katalog aufgeführt werden.

Bei einem Postfachclusterserver, der freigegebenen Speicher verwendet, sind dieselben grundlegenden Aspekte zu berücksichtigen, wie bei einem eigenständigen Server. Bei Verwendung der synchronen Replikation kann die Datenträgerwartezeit durch den Replikationsprozess künstlich erhöht werden. Bei der Maximierung der Replikationspunkte innerhalb des Speicherarrays ist Sorgfalt angebracht. Weitere Informationen zur Replikation für Einzelkopiecluster finden Sie in den Bereitstellungsrichtlinien für die Replikation von Daten zwischen mehreren Exchange Server-Standorten.