Neue Funktionalität für hohe Verfügbarkeit und Ausfallsicherheit von Standorten in Exchange 2010 SP1

Exchange 2010
 

Gilt für: Exchange Server 2010 SP1

Letztes Änderungsdatum des Themas: 2015-03-09

Microsoft Exchange Server 2010 Service Pack 1 (SP1) umfasst neue Funktionen sowie Verbesserungen der Funktionen, die mit der RTM-Version (Release to Manufacturing) von Exchange 2010 eingeführt wurden. Mit den neuen und verbesserten Features werden die Szenarien erweitert, in denen Daten- und Dienstverfügbarkeit für Ihre Exchange 2010-Umgebung erreicht werden kann.

Mit Exchange 2010 SP1 stehen die folgenden neuen Hochverfügbarkeitsfunktionen sowie Verbesserungen an vorhandenen Hochverfügbarkeitsfunktionen bereit:

  • Fortlaufende Replikation - Blockmodus

  • Neuverteilung der aktiven Postfachdatenbank

  • Verbesserte Unterstützung der Koordinierung der Datencenteraktivierung

  • Neue und verbesserte Skripts für Verwaltung und Überwachung

  • Verbesserte Benutzeroberfläche der Exchange-Verwaltungskonsole

  • Verbesserte Failoverleistung

  • Wiederherstellung der Extensible Storage Engine bei Stillstand der E/A

Diese Funktionen werden in den folgenden Abschnitten detaillierter behandelt.

In der RTM-Version von Exchange 2010 und allen Versionen von Exchange Server 2007 werden bei der fortlaufenden Replikation Kopien der von der aktiven Datenbankkopie erstellten Protokolldateien in die passiven Kopien übertragen. Ab Exchange 2010 SP1 wird diese Form der fortlaufenden Replikation als Fortlaufende Replikation - Dateimodus bezeichnet. In Exchange 2010 SP1 wird außerdem eine neue Form der fortlaufenden Replikation eingeführt, die als Fortlaufende Replikation - Blockmodus bezeichnet wird. Im Blockmodus wird beim Schreiben jeder Aktualisierung in den aktiven Protokollpuffer der aktiven Datenbankkopie diese auch in einen Protokollpuffer aller passiven Postfachkopien übertragen. Sobald der Protokollpuffer voll ist, führt jede Datenbankkopie eine Überprüfung durch und erstellt dann die nächste Protokolldatei in der Generierungssequenz. Sollte sich ein Systemausfall auf die aktive Kopie auswirken, werden die passiven Kopien mit den meisten oder allen der letzten Aktualisierungen aktualisiert. Die aktive Kopie wartet nicht den Abschluss der Replikation ab, um zu verhindern, dass sich Replikationsprobleme auf die Clientumgebung auszuwirken.

Die fortlaufende Replikation im Blockmodus ist nur aktiv, wenn die fortlaufende Replikation im Dateimodus auf dem neuesten Stand ist. Der Übergang in und aus dem Blockmodus erfolgt mithilfe der Protokollkopierfunktion automatisch. Der Blockmodus verkürzt drastisch die Wartezeit zwischen dem Zeitpunkt einer Änderung an der aktiven Kopie und deren Replikation in passive Kopien. Zusätzlich zum Replizieren einzelner Protokolldateischreibvorgänge ändert der Blockmodus auch den Aktivierungsprozess einer passiven Kopie. Wenn sich eine Kopie bei Auftreten eines Fehlers im Blockmodus befindet, verwendet das System während des Aktivierungsprozesses die vorhandenen teilweisen Protokollinhalte. Dies verhindert, dass die aktuelle Protokolldatei eine einzelne Fehlerquelle für die aktive Kopie darstellt.

Exchange 2010 SP1 bietet das Skript RedistributeActiveDatabases.ps1, das von Administratoren regelmäßig ausgeführt werden kann, um die Verteilung aktiver Datenbanken in einer Database Availability Group (DAG) basierend auf eine vom Administrator konfigurierten Aktivierungseinstellung gleichmäßig zu gestalten. Darüber hinaus wurde dem Active Manager-Prozess zur Auswahl der bestmöglichen Kopie die Kopieverteilungserkennung hinzugefügt. Insbesondere werden im ersten Durchgang der Auswahl der bestmöglichen Kopie für verlustfreie Switchover nun die möglichen Ziele anhand der Einstellung und nicht anhand des geringstmöglichen Verlusts sortiert.

Exchange 2010 RTM bietet nun einen Konfigurationsmodus zur Unterstützung der Ausfallsicherheit von DAGs, der Koordinierung der Datencenteraktivierung (Datacenter Activation Coordination, DAC) genannt wird. Im DAC-Modus können Exchange-Cmdlets zum Durchführen eines Datencenterswitchovers verwendet werden. In der RTM-Version ist der DAC-Modus auf Database Availability Groups mit mindestens drei Mitgliedern begrenzt, die über mindestens zwei oder mehr Mitglieder im primären Datencenter verfügen.

In Exchange 2010 SP1 wurde der DAC-Modus weiter optimiert, um DAGs mit zwei Mitgliedern zu unterstützen, die sich in getrennten Datencentern befinden. Im DAC-Modus zur Unterstützung von DAGs mit zwei Mitgliedern wird ein Zeugenserver zur zusätzlichen Vermittlung verwendet. Darüber hinaus wurde der DAC-Modus so optimiert, dass DAGs unterstützt werden, deren Mitglieder an einem einzelnen Active Directory-Standort bereitgestellt sind, einschließlich einzelner Active Directory-Standorte, die auf mehrere Standorte ausgedehnt wurden.

Exchange 2010 SP1 enthält mehrere neue und optimierte Skripts zum Verbessern von Verwaltung und Überwachung:

  • CheckDatabaseRedundancy.ps1 (neu)   Mit diesem Skript können Sie die Redundanz replizierter Datenbanken überprüfen. Es generiert außerdem Ereignisse, wenn die Ausfallsicherheit der Datenbank gefährdet ist (wenn z. B. nur eine fehlerfreie Kopie einer replizierten Datenbank vorhanden ist.) Dieses Skript wird von einer Microsoft System Center Operations Manager 2007 Management Pack-Änderung begleitet, die zum Überwachen von Datenbanken ohne Redundanz dienen kann, was in Umgebungen ohne RAID besonders sinnvoll ist.

  • "StartDagServerMaintenance.ps1" und "StopDagServerMaintenance.ps1" (neu)   Mit StartDagServerMaintenance.ps1 können Sie ein Mitglied einer DAG zu Wartungszwecken außer Betrieb nehmen. Es verschiebt aktive Datenbanken vom Server und verhindert das Verschieben von Datenbanken auf diesen Server. Ferner stellt es sicher, dass sämtliche wichtige Funktionalität zur DAG-Unterstützung (z. B. die Rolle "Primary Active Manager"), die sich ggf. auf dem Server befindet, auf einen anderen Server verschoben wird, und verhindert, dass sie auf den Server zurückverschoben wird. Das andere Skript, StopDagServerMaintenance.ps1, dient zum Abschließen des Vorgangs und Aufheben der Sperren.

  • CollectOverMetrics.ps1 (optimiert)   Mit diesem Skript können Sie Switchover- und Failoverdaten sammeln. Das Skript wurde in Exchange 2010 SP1 so optimiert, dass es Metriken für die fortlaufende Replikation im Blockmodus und weitere Details aus der Replikations- und Wiedergabepipeline enthält. Außerdem ermöglicht es eine verbesserte Berichterstellung.

  • CollectReplicationMetrics.ps1 (optimiert)   Bei diesem Skript handelt es sich um eine aktive Form der Überwachung, da es Metriken für die fortlaufende Replikation in Echtzeit erfasst, während das Skript ausgeführt wird. Es unterstützt Parameter, mit denen Sie das Verhalten und die Ausgabe des Skripts anpassen können.

Exchange 2010 SP1 bietet nur bessere Möglichkeiten der Verwaltung von DAGs über die Exchange-Verwaltungskonsole. Die Exchange-Verwaltungskonsole unterstützt nun das Verwalten von IP-Adressen und alternativen Zeugenservereinstellungen für DAGs. Zur Konfiguration dieser Einstellungen muss nicht mehr die Exchange-Verwaltungsshell verwendet werden.

Exchange 2010 SP1 bietet eine optimierte Failover- und Switchoverleistung. In der RTM-Version von Exchange 2010 beendet die passive Kopie bei Auftreten eines Failovers oder Switchovers unmittelbar das Wiedergeben von Protokolldateien, die in diese passive Kopie kopiert wurden. Die Einbindung der aktiven Kopie wird anschließend aufgehoben (falls noch nicht geschehen), und verbleibende Protokolldateien werden in die aktivierte passive Kopie kopiert. Vorausgesetzt, dass sich fehlende Daten innerhalb der Einstellung AutoDatabaseMountDial befinden, wird die passive Kopie zur neuen aktiven Kopie, und die Datenbank wird mit dem Status "Dirty Shutdown" bereitgestellt. An dieser Stelle werden alle Protokolldateien, die in die zuvor passive (nun aktive) Kopie kopiert wurden, wiedergegeben, damit die Datenbank konsistent wird.

Wenn in Exchange 2010 SP1 ein Failover oder Switchover auftritt, fährt der Exchange -Replikationsdienst für die aktivierte Kopie mit der Wiedergabe von Protokolldateien fort, die in die passive Kopie kopiert wurden, bis die letzte von der aktiven Kopie generierte Kopie hineinkopiert wurde. Dadurch kann ein Einbindungsvorgang für eine Datenbank erfolgen, die einen nahezu konsistenten Status hat.

Zu den weiteren Leistungsverbesserungen zählen Timeouts und andere algorithmische Details zum Verbessern der Failoverleistung sowie der E/A-Leistung im Anschluss an ein Failover.

Exchange 2010 SP1 umfasst eine neue Wiederherstellungslogik, die bei bestimmten Bedingungen das integrierte Windows-Verhalten zur Fehlerprüfung (BugCheck) nutzt. Insbesondere wurde das ESE-Modul (Extensible Storage Engine) aktualisiert und bietet nun die Möglichkeit, einen Stillstand von E/A-Vorgängen zu erkennen und entsprechende Schritte zur Wiederherstellung des Servers einzuleiten. ESE nutzt einen E/A-Überwachungsthread, der erkennt, wenn ein E/A-Vorgang für eine bestimmte Zeitdauer ausstehend ist. Per Voreinstellung protokolliert ESE ein Ereignis, wenn ein E/A-Vorgang für eine Datenbank länger als eine Minute aussteht. Wenn ein E/A-Vorgang für eine Datenbank länger als vier Minuten ausstehend ist, protokolliert ESE ein spezifisches Fehlerereignis (sofern möglich). Die ESE-Ereignisse 507, 508, 509 und 510 werden abhängig vom Grund für den Stillstand der E/A protokolliert oder nicht protokolliert. Wenn das Problem das Betriebssystemvolume oder die Möglichkeit zum Schreiben in das Ereignisprotokoll betrifft, werden die Ereignisse nicht protokolliert. Wenn die Ereignisse protokolliert werden, wird der wininit.exe-Prozess explizit vom Microsoft Exchange-Replikationsdienst (MSExchangeRepl.exe) beendet, um eine Windows-Fehlerprüfung auszulösen.

In einigen Fällen wirkt sich der Stillstand auf den gesamten Speicherstapel aus, sodass keine Fehlerereignisse in den Crimson-Kanal oder in einen anderen Bereich des Windows-Ereignisprotokolls geschrieben werden können. ESE überwacht zusätzlich den Crimson-Kanal, indem überprüft wird, ob in das Ereignisprotokoll geschrieben werden kann. Wenn für einen längeren Zeitraum nicht in das Ereignisprotokoll geschrieben werden kann, löst MSExchangeRepl eine Windows-Fehlerprüfung aus, indem der wininit.exe-Prozess beendet wird. Wenn die Betriebssystem-E/A stillsteht, kann das System keine ESE-Ereignisse in das Ereignisprotokoll schreiben.

HinweisHinweis:
Bei Anwendungs- und Dienstprotokollen handelt es sich um eine neue Kategorie von Ereignisprotokollen in Windows Server 2008. Anstelle von Ereignissen, die systemweite Auswirkungen haben können, werden in diesen Protokollen Ereignisse aus einer einzigen Anwendung oder Komponente gespeichert. Diese neue Kategorie von Ereignisprotokollen wird als Crimson-Kanal einer Anwendung bezeichnet. Weitere Informationen finden Sie unter Überwachen von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.

Diese auf der Fehlerprüfung basierende neue Wiederherstellungsfunktion in Exchange 2010 SP1 ermöglicht eine schnelle Wiederherstellung, wenn ein E/A-Vorgang stillsteht oder ein Controller nicht mehr reagiert. So muss das System nicht länger erneut versuchen, einen Vorgang auszuführen, oder darauf warten, dass der Speicherstapel einen Fehler auslöst, der zu einem Failover führt. Wenn die Fehlerüberprüfung ausgeführt wird, lautet der Fehlercode wie folgt:

 

CRITICAL_OBJECT_TERMINATION (f4)

Ein für das Betriebssystem wesentlicher Prozess oder Thread wurde unerwarteterweise abgebrochen oder beendet.

WarnungWarnung:
Wenn dieser Fehlercode angezeigt wird, bedeutet dies nicht unbedingt, dass der Fehler durch Exchange verursacht wurde. Unabhängig davon, wodurch der wininit.exe-Prozess beendet wird – auch wenn der Administrator den Prozess über den Task-Manager oder ein anderes Taskverwaltungstool beendet –, wird derselbe Fehlercode angezeigt.
 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.
Anzeigen: