Bereitstellungsrichtlinien für die Datenreplikation für Exchange Server mit mehreren Standorten

Artikel
10/25/2013

Letztes Änderungsdatum des Themas: 2006-09-01

Durch die Replikationstechnologie kann eine hohe Verfügbarkeit der Microsoft® Exchange Server-Daten erreicht werden. Dieses Thema bietet Informationen zum besseren Verständnis der Replikationsspeichertechnologie und deren Verwendung in einer Exchange Server-Umgebung.

Replikation unterstützt eine hohe Verfügbarkeit, indem redundante Daten an mehreren Standorten gespeichert werden, aber sie kann nicht verhindern, dass Datenbeschädigungen auftreten. Wenn beschädigte Daten auf das primäre Speichergerät geschrieben werden, das die Datenbeschädigung verursacht hat, werden diese beschädigten Daten auch auf die Remotestandorte repliziert, und die Datenbanken des Remotestandorts werden ebenfalls beschädigt. Daher stellt die Datenreplikation keinen Ersatz für Datenbankwartungsprozesse wie die Datenbanksicherung dar, bei denen die Datenbankintegrität regelmäßig überprüft wird.

Dieses Thema befasst sich mit der Art von Daten, auf die durch die Ausführung von Exchange-Diensten zugegriffen wird, z. B. beliebige E/A-Schreibanforderungen eines Exchange-Prozesses. Die Replikation von System-/Betriebssystemdaten wird hier nicht behandelt.

Microsoft verfügt über Supportrichtlinien für verschiedene Arten von Replikationslösungen. Details zu diesen Supportrichtlinien finden Sie im Microsoft Knowledge Base-Artikel 895847 über die Unterstützung der Datenreplikation für Exchange 2003 und Exchange 2000 mit mehreren Standorten."

Anmerkung:
Laden Sie Bereitstellungsrichtlinien für die Datenreplikation für Exchange Server mit mehreren Standorten herunter, um das Dokument zu drucken oder offline zu lesen.

Replikationsmechanismen

Der Zweck der Datenreplikation besteht darin, aktuelle Replikate der Daten auf Remotestandorten zu speichern. Exchange-Server können mithilfe der Replikate auf den Remotestandorten die Kontinuität des E-Mail-Dienstes bei einem Speicher- oder Standortausfall des primären Standorts sicherstellen. Die Datenreplikation kann synchron oder asynchron erfolgen. Bei der synchronen Replikation von Daten erhalten die Hosts vom Speicher erst dann eine Rückmeldung über den Abschluss des Schreibvorgangs, wenn die E/A-Schreibvorgänge auf den lokalen und den Remotestandorten erfolgreichen abgeschlossen wurden. Mit anderen Worten, sowohl der lokale als auch der Remotespeicher müssen die Änderung implementieren, bevor dem Host gemeldet wird, dass der Schreibvorgang erfolgreich war. Im asynchronen Modus erhält der Host die Rückmeldung über den Abschluss des Schreibvorgangs vom Speicher, sobald der Schreibvorgang in den lokalen Speicher übertragen wurde; die Bestätigung des Remotespeichers über die Aktualisierung des Replikats wird nicht abgewartet.

Asynchrone Replikation

Im Gegensatz zum synchronen Replikationsmodus haben größere Replikationsentfernungen und die damit verbundene höhere Schreiblatenz bei der asynchronen Replikation im Allgemeinen keine wesentlichen Auswirkungen auf die Hostanwendung. Bei der Bereitstellung der asynchronen Replikation sollten Sie jedoch die folgenden Punkte beachten:

Datenverlust Je nach der Häufigkeit der Datenreplikation sind einzelne, am primären Standort erfolgte Datenänderungen am Remotestandort unter Umständen noch nicht verfügbar. Bei einem Ausfall des primären Standorts ist das Replikat des Remotestandorts daher nicht unbedingt auf dem neuesten Stand. Diese Verzögerung ist zwar bei den meisten Speicherlösungen konfigurierbar, Sie sollten sich aber bewusst sein, dass dieses Verhalten das Risiko eines Datenverlusts mit sich bringt.
Datenintegrität (Bewahren der Schreibreihenfolge) Bei Exchange besteht eine Abhängigkeit in der Schreibreihenfolge zwischen der Datenbank und den zugehörigen Transaktionsprotokollen. Exchange schreibt Änderungen immer zuerst in das Protokoll, bevor sie in die Datenbankdateien übertragen werden. Im synchronen Replikationsmodus steuert die Anwendung die Schreibreihenfolge. Im asynchronen Modus steuert die Replikationslösung hingegen, wann die Daten repliziert werden. Wenn die Lösung die Schreibreihenfolge während der Replikation nicht einhält, führt dies möglicherweise zu einer Beschädigung der Datenbankdateien und dazu, dass die Datenbank bei einem Notfall am primären Standort nicht aktiviert werden kann.
Leistungsauswirkungen Viele Lieferanten behaupten, dass ihre asynchronen Lösungen keine Auswirkungen auf die Speicherleistung haben, aber in Wahrheit kommt es beim Einsatz asynchroner Replikation stets zu einer Leistungsminderung. Je nach der Implementierung der Lösung lassen sich die Leistungserwartungen nicht in Zahlen beschreiben. Daher sollten Kunden die Lösung vor der Bereitstellung ausreichend testen, um zu ermitteln, ob die Lösung eine angemessene Speicherleistung für Exchange-Benutzer bieten kann.

Einige Lösungslieferanten verwenden verschiedene Technologien, um die Schreibreihenfolge zu wahren. Für einen erfolgreichen Einsatz einer asynchronen Replikationslösung muss der Kunde mit dem Lieferanten zusammenarbeiten, um sicherzustellen, dass die asynchrone Technologie die folgenden Anforderungen erfüllt:

Die konsistente Schreibreihenfolge aller Geräte in einer Speichergruppe sowie die ständige Konsistenz untereinander muss sichergestellt werden.
Die Lösung muss wiederherstellbar sein, und zwar nachweislich sowohl im Labor als auch in einer Produktionsumgebung.
Sie Lieferant der Lösung muss über einen Supportplan für die replizierten Daten verfügen.

Synchrone Replikation

Das Hauptproblem bei synchroner Replikation in einer Exchange-Bereitstellung liegt in der Leistung. Tests haben gezeigt, dass die Clientleistung in enger Beziehung zur Schreiblatenz steht. Bei einer synchronen Replikationslösung ist die Anzahl der Postfächer geringer, die pro Exchange-Server gehostet werden können. Die Auswirkungen auf die Leistung hängen in erster Linie von Replikationsentfernung, Bandbreite der Replikationsverbindung und Verwendung ab. Synchrone Replikation kann die Verfügbarkeit der Postfächer/Server um bis zu 75 Prozent reduzieren. Diese Minderung der Skalierbarkeit sollten Sie bei der Erarbeitung Ihrer Exchange-Kapazitätsplanungsmethode berücksichtigen. Weitere Informationen finden Sie unter "Bereitstellungsplanung für synchrone Replikation", weiter unten in diesem Thema.

Synchrone Replikation wird häufig für eine Lösung gehalten, die Datenverluste ausschließen kann, weil die Replikate vollständig mit den Datendateien des primären Speichers synchronisiert werden. Im Gegensatz zu dieser weit verbreiteten Meinung gibt es jedoch Szenarien, in denen auch bei synchroner Replikation Datenverluste auftreten können. Das folgende Beispiel beschreibt ein solches Szenario.

Grundsätzlich behandeln Replikationslösungen für Speicherdaten den Ausfall einer Replikationsverbindung auf eine der beiden folgenden Arten:

Die Übertragung von Schreib-E/A wird nur auf dem primären Speichergerät fortgesetzt; alle Änderungen, die an sämtlichen Geräten erfolgen, die die ausgefallene Replikationsverbindung verwenden, werden in einer Protokolldatei erfasst; das Protokoll wird im primären Speicher gespeichert.
Der Schreibvorgang schlägt fehl, und die Anwendung behandelt den Fehler so, als ob der Datenträger ausgefallen wäre.

Wenn die Replikationslösung die erste Methode verwendet, ist ein Datenverlust möglich. Folgt kurz nach dem Verbindungsausfall ein Ausfall des primären Standorts, werden die nach dem Verbindungsausfall übertragenen Daten nicht repliziert. Die Daten gehen also mit dem Ausfall des primären Speichers verloren. Beim Entwurf der Speicherreplikationslösung sollten Sie diese Arten von Fehlerbedingungen berücksichtigen, um ein System zu entwickeln, bei dem diese Vorfälle reduziert werden. im vorliegenden Beispiel sollte der Kunde unter Umständen überlegen, redundante Replikationsverbindungen einzurichten, um das Risiko eines Datenverlusts zu verringern.

Synchrone Replikationslösungen

Synchrone Replikationslösungen werden in hostbasierte und speicherbasierte Replikationslösungen unterteilt, je nachdem, wo die Replikation erfolgt. Die hostbasierte Replikation verwendet in der Regel hostbasierte Software (Filtertreiber), um den E/A-Datenstrom zu unterbrechen und die Replikation zu verwalten. Sie speicherbasierte Replikation erfolgt außerhalb des Hosts auf der Ebene der Speichergeräte. Beide Replikationslösungen können als Teil der folgenden Szenarien bereitgestellt werden:

Geografisch verteiltes Clustering (Geocluster) In dieser Kategorie befinden sich die Knoten, die zu demselben Cluster gehören, an unterschiedlichen Standorten. Allgemein werden Exchange-Server aktiv von den Knoten am primären Standort gehostet. Lösungen stellen den Remotestandorten synchrone Replikation der Exchange-Daten bereit. Bei einem Ausfall des primären Standorts führen die virtuellen Exchange-Server ein Failover an die passiven Knoten an den Remotestandorten aus und sind mit den replizierten Exchange-Daten online.
Der Microsoft Windows® Server-Katalog verfügt über eine Kategorie für geografisch verteilte Clusterlösungen. Sie können die WHQL-zertifizierten (Windows Hardware Qualified Labs) geografisch verteilten Clusterlösungen unter https://go.microsoft.com/fwlink/?LinkId=28572 durchsuchen.
Sonstige Diese Kategorie umfasst alle anderen Arten von synchronen Replikationsbereitstellungen, die kein geografisch verteiltes Clustering einsetzen. Diese Lösungen verfügen über andere Methoden zur Verwendung der replizierten Exchange-Daten auf den Remotestandorten bei einem Ausfall des primären Standorts (z. B. Standbylösung; Replikation gekoppelt mit Notfallwiederherstellungsprozessen).

Microsoft empfiehlt dringend, dass Kunden sich von ihren Replikationslösungslieferanten die folgenden Punkte zusichern lassen:

Gehört die Lösung zur Kategorie der geografisch verteilten Clusterlösungen? Wenn ja, ist sie WHQL-zertifiziert? Wenn es sich nicht um eine solche Lösung handelt, ist das Speichergerät in einer Lösung aufgelistet, die im Abschnitt "Cluster Solutions, Geographically Dispersed Clustering Solution" des Windows Server-Katalogs beschrieben wird?
Schaltet die Replikationslösung sämtliche Risiken eines Datenverlusts aus, außer bei gleichzeitigem Ausfall aller Standorte?
Wie sehen die Verfahren für die Durchführung eines Failovers und eines Failbacks aus?
Kommt die Replikationslösung mit der voraussichtlichen Wartezeit und der geplanten Exchange-Benutzerlast zurecht, und kann sie eine hohe Clientleistung garantieren?

Zu replizierende Exchange-Daten

Exchange ist eine datenzentrierte Serveranwendung. Die Replikation von Exchange-Daten auf einen sekundären Standort stellt Redundanz für speicherbezogene Ausfälle bereit. Bei der Entscheidung, welche Arten von Daten repliziert werden, sollten auch wirtschaftlichen Gesichtspunkte berücksichtigt werden, . Ermitteln Sie dazu die wirtschaftliche Toleranz gegenüber einem Verlust der verschiedenen nachfolgend beschriebenen Datentypen.

Unbedingt zu replizierende Daten

Die folgenden Daten müssen repliziert werden:

In den Exchange-Postfachdatenbankdateien werden Nachrichtendaten gespeichert. Jede Datenbank besteht aus zwei Dateien:
- Der Datenbankdatei (EDB) mit den Nachrichten und MAPI-Inhalten.
- Der Streamingdatei (STM) mit systemeigenen nicht-MAPI-Inhalten.
Transaktionsprotokolldateien (LOG) erfassen jede Transaktion, die in die Datenbank übertragen wird.
Prüfpunktdateien (CHK) enthalten Informationen über die Einträge in den Protokolldateien, die auf den Datenträger geschrieben wurden.

All diese Dateien sind von entscheidender Bedeutung für die Bereitstellung des Clientzugriffs auf die Postfachserver und für das Soft Recovery der im Speicher befindlichen Datenbankänderungen, die verloren gehen, wenn die Speicher eines Exchange-Servers nicht sauber heruntergefahren werden, z. B. bei einem Stromausfall. Aufgrund der kritischen Bedeutung dieser Dateien müssen sie unbedingt repliziert werden. Die Pfade der Datenbankdateien sind auf der Eigenschaftenseite der Datenbank angegeben; jede Datenbank verfügt über einen eigenen Pfad. Der Pfad des Transaktionsprotokolls und der Pfad der Prüfpunktdatei sind auf der Eigenschaftenseite der Speichergruppe angegeben. Alle Datenbanken in dieser Speichergruppe hängen davon ab.

Die Entscheidung, ob Datenbanken für Öffentliche Ordner repliziert werden sollen, ist eine etwas komplexere Entscheidung. Ob die Replikation erfolgen soll, hängt zum Teil vom Design der Exchange-Topologie Ihrer Bereitstellung ab. Im Gegensatz zu Postfachdaten, können die Daten der Öffentlichen Ordner direkt von Exchange Server repliziert werden. Sie können über mehrere Replikate der Informationsspeicher für Öffentliche Ordner verfügen, in denen Änderungen (Inhalte) repliziert werden. Diese Datenreplikation erfolgt nicht synchron.

Geoclusterlösungen erfordern eine synchrone Replikation der Öffentlichen Ordner im Cluster. Dies ist erforderlich, damit der Cluster auf dem sekundären Standort voll funktionsfähig ist. Postfachdatenbanken innerhalb des Clusters müssen auf den Informationsspeicher für den Öffentlichen Ordner ("Standardinformationsspeicher") verweisen, der ebenfalls innerhalb des Clusters gespeichert ist, damit die Clients sich unmittelbar nach Verfügbarkeit des Clusters am sekundären Standort anmelden können. Die Öffentlichen Ordner innerhalb des Geoclusters brauchen lediglich die Hierarchie und nicht notwendigerweise den kompletten Inhalt zu hosten, um eine Postfachanmeldung während einer Fehlerbedingung zu ermöglichen. Die Option, den vollständigen Inhalt der Öffentlichen Ordner zu hosten und synchron innerhalb der im Geocluster gehosteten Öffentlichen Ordner zu replizieren, ist eine Entscheidung, bei der wirtschaftliche Aspekte zu berücksichtigen sind. Wenn die Daten der Öffentlichen Ordner für das Kerngeschäft entscheidend sind, wenn also nur der Verlust einer minimalen Menge an Daten geduldet werden kann, sollten Sie überlegen, eine Geoclusterlösung anstelle der Exchange Server-Replikation der Öffentlichen Ordner zu verwenden. Wenn Sie diesen Grad an Verfügbarkeit der Daten aus Öffentlichen Ordner nicht benötigen, können Sie auf eine Geoclusterlösung verzichten und eine synchrone Replikationslösung für Postfachdaten kombiniert mit dem Replikationsmechanismus von Öffentlichen Exchange-Ordnern verwenden.

Empfohlene zu replizierende Daten

Lokale SMTP-Warteschlangendaten (Simple Mail Transfer Protocol) (Mailrootverzeichnis) werden temporär auf dem Speichergerät gespeichert, während sie von Exchange Server verarbeitet werden. Dieses Design verhindert, dass die Daten bei einem Serverausfall verloren gehen. Wenn z. B. ein Zielserver nicht erreichbar ist, werden die Nachrichten, die an diesen Server geroutet werden sollen, im lokalen Serverwarteschlangenverzeichnis gespeichert, bis sie übermittelt werden können. Wenn der Datenträger, auf dem die Warteschlangendaten gespeichert sind, ausfällt, gehen alle Nachrichten in der Warteschlange verloren. Weil es sich bei den Warteschlangendaten um temporäre Daten handelt, existiert kein festgelegter Prozess für die Sicherung der Nachrichtenwarteschlangen wie beispielsweise für die Sicherung der Exchange Server-Datenbanken. Die Bereitstellung von Fehlertoleranz und/oder von Lösungen mit hoher Verfügbarkeit für den Speicher, der diese Warteschlangeninformationen enthält, kann Sie vor möglichem Datenverlust schützen. Außerdem empfiehlt es sich, die MTA-Warteschlangendaten (MTADATA-Verzeichnis) in Umgebungen zu replizieren, in denen temporäre Nachrichten aufgrund von Standortausfällen nicht verloren gehen sollen.

Der Pfad für den SMTP-Mailroot (mit den Verzeichnissen "Queue" und "Badmail" für jede virtuelle Serverinstanz) ist auf der Registerkarte "Nachrichten" der Eigenschaftenseite "SMTP Virtual Server" in Exchange System Manager (ESM) und auf der Eigenschaftenseite "X.400" für den MTA-Warteschlangenpfad angegeben. Sie sollten anhand Ihres Profils entscheiden, ob eine Replikation der Exchange-Warteschlangendaten erforderlich ist. Wenn Sie über eine vorhandene Exchange-Topologie verfügen, können Sie entscheiden, ob Sie den Verlust der Daten in Ihrer lokalen Warteschlange tolerieren können. Die zu erwartende Menge an Daten in der lokalen Warteschlange lässt sich mit dem Leistungsindikator für lokale Warteschlangenlänge in Performance Monitor ("Perfmon.msc") oder über die Warteschlangenanzeige in ESM während der Zeiten mit Spitzenlast ermitteln. Wenn eine Replikation der Warteschlangendaten erforderlich ist, ist es wichtig, die Leistung der Nachrichtenverarbeitung in der Replikationsumgebung zu testen, so dass die entstehende Replikationslatenz nicht zu Engpässen bei der Nachrichtenübertragung führt. Mit dem Exchange Server Stress and Performance 2003-Tool können Sie den Übertragungsdurchsatz in einer synchronen Replikationsumgebung, in der die Warteschlangendaten repliziert werden, testen. Sie können das Tool von der Exchange Server Stress and Performance 2003-Website herunterladen.

Optional zu replizierende Daten

Protokolle der Nachrichtenverfolgung enthalten Informationen über alle Nachrichten, die zu, von und innerhalb eines Exchange-Servers übertragen werden. Diese Daten können zu Diagnosezwecken wichtig sein. Die Nachrichtenverfolgung ist in der Standardeinstellung deaktiviert. Wenn diese Daten für Ihr Unternehmen wichtig sind, können sie jedoch repliziert werden, um einen Datenverlust zu verhindern. Der Pfad des Protokolls der Nachrichtenverfolgung ist auf der Exchange Server-Eigenschaftenseite in ESM angegeben.

Bewährte Methoden zur Konfiguration der Replikationsmechanismen

Jeder Lieferant verfügt über verschiedene eigene proprietäre Implementierungen von Replikationsmechanismen mit unterschiedlichen Replikationsoptionen. Besprechen Sie die Lösungsdetails mit dem jeweiligen Lieferanten, um zu ermitteln, ob die vorgeschlagene Lösung sich für die speziellen Anforderungen und SLAs (Service Level Agreements) Ihres Unternehmens zur Wiederherstellung nach Datenverlusten eignet. Die folgenden Empfehlungen gelten möglicherweise nur für bestimmte Replikationslösungen:

Anmerkung:
Der Begriff "Replikationspunkt" bezieht sich auf den Ort, an dem die Replikation erfolgt. Anhängig von der jeweiligen Lösung kann sich dieser Ort auf Hostfiltertreiber-Ebene oder auf einem Datenträgerabschnitt innerhalb des Speicherarrays befinden.

Konfigurieren Sie die Replikation auf der Ebene des logischen/Bereitstellungspunktvolumes.
Obwohl die Daten, die repliziert werden müssen, sich in den weiter oben im Abschnitt "Zu replizierende Exchange-Daten" beschriebenen Dateien befinden, müssen Sie sicherstellen, dass die Replikation auf Host-Ebene für die Einheit des logischen/Bereitstellungspunktvolumes konfiguriert ist. Wenn der Postfachdatenpfad z. B. "G:\MDB1\MDB1.EDB" lautet, sollte Laufwerk G: die Basiseinheit für die Durchführung der Replikation sein. Als Ergebnis werden alle Daten auf Laufwerk G: repliziert. Die Replikation auf Datei- oder Unterverzeichnisebene ist fehleranfällig und wird von Microsoft nicht unterstützt.
Erstellen Sie viele Replikationspunkte.
Um das Speichern mehrerer E/A-Vorgänge für den gleichen Replikationspunkt in einer Warteschlange zu verringern, konfigurieren Sie möglichst viele Replikationspunkte für den Speicher. Verteilen Sie die E/A-Last auf mehrere Peplikationspunkte. Abhängig von der Speicher-/Replikationslösung kann dieser Ansatz die Gesamtwartezeiten für Lese-/Schreib-E/A-Vorgänge verringern, weil weniger E/A in Warteschlangen gespeichert werden.
Speichern Sie die Transaktionsprotokolle auf verschiedenen logischen Volumes.
Beim Replizieren der Daten wird jede E/A-Anforderung auf Replikationspunktebene in die Warteschlange geschrieben. Exchange schreibt Protokolle in einem sequentiellen Muster. Wenn die E/A für denselben Replikationspunkt bestimmt sind, besteht eine große Wahrscheinlichkeit, dass jede E/A für den Schreibvorgang in der Warteschlange gespeichert wird. Diese Situation würde zu längeren Antwortzeiten beim Schreiben der Protokolle führen, was wiederum einen wesentlichen negativen Einfluss auf die Exchange-Leistung/-Skalierbarkeit darstellt. Aus diesem Grunde empfiehlt Microsoft, Transaktionsprotokolle unterschiedlicher Speichergruppen auf verschiedene logische Volumes mit unterschiedlichen Replikationspunkten aufzuteilen.
Verwenden Sie mehrere Replikationsverbindungen.
Oft lassen sich Leistung/Skalierbarkeit der Replikationslösung durch die Konfiguration mehrerer Replikationsverbindungen zwischen dem primären und den sekundären Standorten verbessern. Die Implementierung dieses Ansatzes ist jedoch unter Umständen teuer und für die Exchange-Datenreplikation nicht erforderlich. Es gibt aber Bereitstellungen, bei denen mehrere Replikationsverbindungen implementiert werden müssen, um die gewünschte Leistung/Skalierbarkeit für eine bestimmte Exchange-Datenreplikationslösung zu erreichen. Es kann auch erforderlich sein, einen Lastenausgleich der Replikationspunkte über die verfügbaren Replikationsverbindungen durchzuführen, um einen optimalen Replikationsdurchsatz zu erreichen.
Da bei Exchange zwischen der Datenbank und den zugehörigen Transaktionsprotokollen eine Abhängigkeit in der Schreibreihenfolge besteht, ist es wichtig, eine Gruppe von Replikationspunkten für die Sicherung der logischen Volumes der Speichergruppe zu konfigurieren (dazu gehören die Datenbank-LUN (Logical Unit Number) und die Protokoll-LUN), die dieselbe Replikationsverbindung verwenden. Diese Konfiguration gewährleistet, dass die Schreibreihenfolge auf Speichergruppenebene beibehalten wird, was entscheidend ist, um die Datenintegrität am Remotestandort im Falle von Fehlerszenarien, beispielsweise einem Verbindungsausfall, zu wahren.
Die Verwendung mehrerer Replikationsverbindungen mit mehreren Replikationspunkten kann ein wirksamer Ansatz zur Skalierung einer Exchange-Datenreplikationslösung sein. Dieser Ansatz könnte außerdem das Risiko eines möglichen Datenverlusts verringern, wie im Beispiel im Abschnitt "Synchrone Replikation" weiter oben beschrieben.

Bewährte Methoden für die Konfiguration von Exchange für die synchrone Replikation

Wenn Exchange in einer synchronen Replikationsumgebung bereitgestellt wird, können ein paar Konfigurationsänderungen die Serverleistung/-skalierbarkeit verbessern. Es ist wichtig, diese Änderungen in der Planungsphase zu verstehen, um sie beim Speicher- und Replikationsentwurf implementieren zu können. Bewährte Methoden und Empfehlungen für die Konfiguration sind beispielsweise:

Erstellen Sie die höchstmögliche Anzahl von Speichergruppen pro Exchange-Server.
Durch die Erhöhung der Anzahl der Speichergruppen in einer synchron replizierten Exchange-Lösung können Sie Leistung/Skalierbarkeit der Bereitstellung verbessern, indem ein Lastenausgleich bei den Protokollschreibtransaktionen über mehrere logische Volumes und demzufolge mehrere Replikationspunkte vorgenommen wird. Im Allgemeinen erfolgen mehr parallele Protokollschreibvorgänge, wodurch sich die Gesamtwartezeit beim Schreiben der Transaktionsprotokolle in einer synchronen Replikationsumgebung verringert (reduzierte E/A-Warteschlangen). Exchange Server 2003 Enterprise Edition unterstützt vier Speichergruppen pro Exchange-Server.
Vergrößern Sie den Transaktionsprotokollpuffer.
Die E/A-Wartezeit beim Schreiben der Exchange-Protokolle ist in synchronen Exchange-Replikationslösungen ein entscheidender Faktor für die Skalierbarkeit. Protokoll-E/A werden sequenziell geschrieben und bestehen aus einem einzelnen Thread, daher führt die Wartezeit bei Protokoll-E/A mit großer Wahrscheinlichkeit zu einem Engpass für das System. Protokoll-E/A werden zuerst in den Protokollpuffer geschrieben, anschließend wird der Puffer entweder durch einem Non-Lazy Commit oder eine Capacity Commit geleert. Bei einem Non-Lazy Commit wird der Protokollpuffer sofort auf den Datenträger geschrieben. Bei einem Capacity Commit wird der Protokollpuffer erst auf den Datenträger geschrieben, wenn der Puffer voll ist.
Wird der Protokollpuffer vergrößert, verringert sich die Häufigkeit der Pufferleerungen, der Umfang der Protokollschreibvorgänge vergrößert sich und damit reduziert sich die Gesamtwartezeit für Protokollschreibvorgänge. Die Reduzierung der Schreiblatenz für Protokoll-E/A ist eine wichtige Möglichkeit zur Verbesserung der Leistung/Skalierbarkeit der Exchange-Bereitstellung.
Allgemein empfiehlt es sich, den Puffer auf einen maximalen Wert von von 9.000 zu vergrößern, wenn die Replikation über Fibre Channels erfolgt. Bei Verbindungen mit niedriger Bandbreite, z. B. TCP/IP-Verbindungen, ist es nicht einfach, einen optimalen Wert für diesen Parameter zu ermitteln. Wenn die Verbindung eine Sättigung für die größeren Protokollschreibvorgänge aufweist, und dies zu einer langsameren Replikation führt, sollten Sie umfangreiche Tests durchführen, um die optimale Protokollpuffergröße zu ermitteln, bei der die Schreiblatenz für Protokoll-E/A minimiert wird. Weitere Informationen zum Ändern dieses Parameters finden Sie in Knowledge Base-Artikel 328466 über ESE-Protokollpuffer, die zu niedrig eingestellt sind und bewirken können, dass der Microsoft Exchange-Informationsspeicher-Dienst nicht mehr reagiert. Außerdem können Sie Ihren Lösungslieferanten zu dieser Einstellung konsultieren.

Bereitstellungsplanung für synchrone Replikation

Selbst wenn bei der synchronen Replikationsspeicherlösung sämtliche zuvor genannten Empfehlungen eingehalten wurden, kann sie dennoch zu Leistungsproblemen für Exchange-Clients führen, wenn die Lösung vor der Bereitstellung nicht ausführlich getestet wurde. Es gibt keine festen Regeln hinsichtlich der negativen Auswirkungen auf Skalierbarkeit/Leistung durch die Implementierung synchroner Replikation mit Exchange. Jede Exchange-Replikationslösung verfügt über unterschiedliche Leistungsfaktoren, zu denen unter anderem die Folgenden gehören: Entfernung zwischen den Standorten, Replikationsübertragungsmechanismus, Anzahl der Replikationsverbindungen, Anzahl der Replikationspunkte, Anzahl der Exchange-Speichergruppen, Konfigurationseinstellungen für Exchange-Datenbanken/-Protokolle, Speicher und Replikationsarchitektur sowie das Exchange-Clientprofil. Jede Lösung ist anders und erfordert umfangreiche Planung und Tests für eine erfolgreiche Bereitstellung.

Die in synchronen Replikationslösungen auftretende E/A-Schreiblatenz trägt entscheidend zur Begrenzung der Exchange-Skalierbarkeit bei. Diese erhöhte E/A-Wartezeit führt zu einer Serverlast, die sich erheblich auf die Exchange-Clientleistung auswirken kann. Insbesondere die hohe Schreiblatenz führt zu einem Anstieg der RPC-Wartezeit, was wiederum in einer langsameren Clientleistung resultiert. Während die synchrone Replikation eine hohe Verfügbarkeit der Exchange-Daten garantiert, hat sie gleichzeitig eine wesentliche Verringerung der E/A-Leistung zur Folge. Diese Verschlechterung der E/A-Schreib- und manchmal auch Leseleistung ist ein wichtiger Faktor dafür, wie viele Benutzer maximal auf einer Plattform unterstützt werden.

In der Planungsphase sollten Sie die folgenden Schritte zur Überprüfung des Designs unternehmen:

Lesen Sie Optimieren von Speichersystemen für Exchange 2003, um zu verstehen, wie Sie den Entwurf und die Implementierung von Speichersystemen für Exchange optimieren.
Überprüfen Sie beim Testen mit Jetstress den Rohdurchsatz des Speichers bei konfigurierter synchroner Replikation. Das Jetstress-Tool können Sie auf der Website Microsoft Exchange Server Jetstress Tool herunterladen.
Ermitteln Sie, welche Auswirkungen die erhöhte Schreiblatenz auf den E-Mail-Client hat, indem Sie einen auf Ihre Umgebung abgestimmten Test mit Exchange Server Load Simulator 2003 (LoadSim) durchführen. LoadSim können Sie auf der Website Microsoft Exchange Server 2003 Load Simulator (LoadSim) herunterladen.
Ermitteln Sie den durchschnittlichen Datenträgerdurchsatz während der Ausführung von LoadSim. Der Datenträgerdurchsatz muss gleich oder höher sein als der in der simulierten Produktionsumgebung (IOPS/Postfach) erwartete durchschnittliche Spitzendurchsatz. Details dazu, wie Sie den durchschnittlichen Spitzendurchsatz des Datenträgers ermitteln, finden Sie unter Optimieren von Speichersystemen für Exchange 2003.
Achten Sie genau auf den Leistungsindikator für die durchschnittliche RPC-Wartezeit auf dem Server und die Clientantwortzeit nach der Durchführung der LoadSim-Tests. Berücksichtigen Sie bei der Analyse der Testergebnisse, dass alle drei Leistungsindikatoren die unten aufgeführten Kriterien erfüllen müssen.
Durchschnittliche RPC-Wartezeit
Dieser Leistungsindikator zeigt an, wie viel Zeit durchschnittlich benötigt wird, um eine einzelne RPC-Anforderung (Remote Procedure Call) abzuarbeiten. Wenn sich entweder die Benutzerlast oder die Replikationsentfernung erhöht, führt dies zu einem Anstieg der durchschnittlichen RPC-Wartezeit. Der obere Grenzwert für den Durchschnittswert liegt bei 50ms und der Höchstwert von 100ms sollte nicht überschritten werden. Wenn die Testergebnisse einen Durchschnittswert über 50ms zeigen, ist zu erwarten, dass die Gesamtleistung der Clients träge ist. Wenn der Durchschnittswert unter 50ms liegt, der Wert jedoch gelegentlich über 100ms steigt, ist die Clientleistung während dieser Spitzen träge.
Leistungsindikatoren für die Datenträgerlatenz
Das Microsoft Exchange-Produktteam hat verschiedene synchrone Hardwarereplikationslösungen getestet. Die Ergebnisse zeigen die Verbindung zwischen durchschnittlicher RPC-Wartezeit und Datenträgerlatenzen auf. Als allgemeine Regel gilt, dass die Lösung eine bestimmte Last problemlos verarbeiten kann, wenn die durchschnittliche Datenbankleselatenz sowie die durchschnittlichen Wartezeiten bei Protokollschreib- und -lesevorgängen unter 20ms liegen. Die Höchstwerte für diese Wartezeiten sollten unter 40ms bleiben. Oberhalb dieses Schwellenwerts kommt es bei den Clients wahrscheinlich zu langsamen Antwortzeiten.
Clientantwortzeit
Sie können die Gesamtclientleistung überprüfen, indem Sie "lslog.exe" auf allen Clientcomputern ausführen. Diese Aktivität gibt den gewichteten Durchschnittswert des 95. Perzentils zurück; der Wert muss geringer als 1.000ms sein. Das Programm "lslog.exe" ist Teil des LoadSim-Tools. In der Dokumentation zu LoadSim wird beschrieben, wie Sie "Islog.exe" verwenden und die ausgegebenen Ergebnisse interpretieren.
Weitere Informationen zur Leistung finden Sie auf der Website über die Behandlung von Exchange Server 2003-Leistungsproblemen.
Testen Sie die Lösung für Ihr Postfachprofil mit der geplanten Replikationsentfernung. Die Replikationsverbindungsentfernung ist physikalisch begrenzt. Mit steigender Entfernung verlangsamt sich die Client-/Serverantwortzeit infolge der steigenden Schreiblatenzen durch die synchrone Replikation über die Entfernung. Allgemein gilt eine Entfernung von 100 km als Schwellenwert für die synchrone Speicherreplikation von Exchange Server-Daten. Dieser Schwellenwert kann abhängig von der Lösungsimplementierung variieren.
Erstellen Sie einen Sicherungsplan, der die Datenbankintegrität regelmäßig überprüft. Replikation ersetzt keine Sicherungsprozesse.
Stellen Sie sicher, dass Sie über einen umfassenden Plan für die Wiederherstellung bei Datenverlust verfügen, der genau so gründlich wie die Replikationsleistung der Lösung getestet wurde. Es gibt verschiedene Methoden für die Wiederherstellung von Exchange-Daten, -Servern und -Standorten. Sie sollten einen Plan für die Wiederherstellung bei Datenverlust implementieren, der Ihre Unternehmensanforderungen und SLAs (Service Level Agreements) erfüllt und Sie im Falle eines Datenverlusts schnell und effizient durch die Wiederherstellungsphase leitet. Testen und überprüfen Sie den Plan, indem Sie mehrere Arten von Fehlerbedingungen und Ausfällen in einer Exchange-Bereitstellung mit synchroner Replikation unter hoher Auslastung simulieren.