Neue Hochverfügbarkeitsfeatures in Exchange 2007 SP1

Gilt für: Exchange Server 2007 SP1

Letztes Änderungsdatum des Themas: 2009-03-18

Mit Microsoft Exchange Server 2007 Service Pack 1 (SP1) werden neben Verbesserungen der vorhandenen Hochverfügbarkeitsfunktionen auch einige neue Features für die Hochverfügbarkeit eingeführt. Mit den neuen und verbesserten Features werden die Szenarios erweitert, in denen Daten- und Dienstverfügbarkeit für Ihre Exchange 2007-Serverfunktionen erreicht werden kann. Mit den neuen Szenarios sind Organisationen in der Lage, Hochverfügbarkeitsszenarios von Standortflexibilitätsszenarios zu trennen. Außerdem können sie Konfigurationen bereitstellen, die für die speziellen Anforderungen der Organisation in jedem einzelnen Bereich angepasst sind.

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

• Fortlaufende Standbyreplikation (SCR, Standby Continuous Replication)

• Unterstützung für die folgenden Features in Windows Server 2008:

  • Failovercluster mit mehreren Subnetzen

  • DHCP-IPv4 (Dynamic Host Configuration Protocol for IP, Version 4)

  • IPv6

  • Exchange- und Failovercluster-Netzwerkkonfiguration

  • Neue Quorummodelle (Festplatten- und Dateifreigabezeugen)

• Fortlaufende Replikation (Protokollversand und Seeding) über ein redundantes Clusternetzwerk in einer CCR-Umgebung (Cluster Continuous Replication, fortlaufende Clusterreplikation)

• Verbesserungen an der Berichterstellung und Überwachung

• Leistungsverbesserungen

• Verbesserungen am Transportpapierkorb

• Verbesserungen an der Exchange-Verwaltungskonsole

Jedes dieser Features wird später in diesem Thema beschrieben und durch Links zu Dokumentationen zum Planen, Bereitstellen und Verwalten dieser Features ergänzt. In der folgenden Tabelle ist die Unterstützung von Exchange 2007 für Failoverclusterfeatures unter Windows Server 2003 und unter Windows Server 2008 zusammengefasst.

Von Exchange 2007 SP1 unterstützte Failoverclusterfeatures

Fortlaufende Standbyreplikation

Die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) ist ein neues Feature in Exchange 2007 SP1. SCR erweitert vorhandene fortlaufende Replikationsfeatures in Exchange 2007 RTM und aktiviert neue Datenverfügbarkeitsszenarien für Exchange 2007-Postfachserver. SCR verwendet dieselbe Protokollversand- und -wiedergabetechnologie, die auch von der fortlaufenden lokalen Replikation (Local Continuous Replication, LCR) und CCR verwendet wird, um zusätzliche Bereitstellungsoptionen und -konfigurationen bereitzustellen. SCR ist ähnlich wie LCR und CCR, weist aber eigene eindeutige Merkmale auf:

• SCR unterstützt mehrere Ziele pro Speichergruppe. LCR und CCR unterstützen nur ein Replikationsziel pro Speichergruppe (die passive Kopie).

• Bei der SCR kann ein Administrator eine Verzögerungszeit für die Replikation angeben. Dies ist in vielen Szenarien hilfreich. Bei einem verlustreichen Failover von KnotenA zu KnotenB müsste für KnotenM beispielsweise ein erneutes Seeding durchgeführt werden, wenn die verlorenen Protokolldateien auf dem Remote-KnotenM wiedergegeben wurden. Wurden die Protokolle kopiert, jedoch nicht wiedergegeben, dann wurden sie möglicherweise gelöscht und es können neue Protokolldateien erstellt und diese später wiedergegeben werden. In diesem Fall ist kein erneutes Seeding für die Kopie auf KnotenM erforderlich.

• Eine SCR-Kopie kann im Gegensatz zu CCR- und LCR-Kopien nicht gesichert werden. Bei der Verwendung von SCR werden die Datenbankkopfzeilen für SCR-Kopien aktualisiert und die Protokolldateien abgeschnitten, wenn für die Quellspeichergruppe Sicherungen erstellt wurden.

Mithilfe von SCR können Sie die fortlaufende Replikation dazu verwenden, Postfachserverdaten eines eigenständigen Postfachservers oder eines Postfachclusterservers in einer SCC- oder CCR-Umgebung zu replizieren.

Die Aktivierung von Postfachserverdaten, die mit SCR erstellt und verwaltet werden, erfolgt manuell. Sie ist für Situationen konzipiert, in denen ein schwerwiegender Fehler auftritt (und nicht für einfache Serverausfälle, die durch einen Neustart oder anderweitig schnell zu beheben sind). Sie können ein SCR-Ziel mit der Datenbankportabilität, der Option für die Serverwiederherstellung (Setup /m:RecoverServer), oder, bei einem Postfachclusterserver, mit der Option für die Wiederherstellung von Postfachclusterservern (Setup /RecoverCMS) aktivieren. Die von Ihnen zu wählende Option hängt von Ihrer Konfiguration und dem Typ des aufgetretenen Fehlers ab.

Weitere Informationen zur SCR finden Sie unter Fortlaufende Standbyreplikation.

Unterstützung für Windows Server 2008

Windows Server 2008 umfasst neue Hochverfügbarkeitsfeatures, die von Exchange 2007 SP1 unterstützt werden. In Windows Server 2008 sind die Verbesserungen bei Failoverclustern (auch als Servercluster in Windows Server 2003 und früheren Versionen bekannt) auf das Vereinfachen von Clustern, das Optimieren der Sicherheit und Erhöhen der Clusterstabilität ausgerichtet. Zusätzlich wurden die Einrichtung und die Verwaltung von Clustern vereinfacht sowie die zugrunde liegende Clustersicherheit, die Netzwerk- und die Speicherkomponenten verbessert. Eine vollständige Liste der Verbesserungen bei Failoverclustern finden Sie unter Failover Clustering with Windows Server 2008.

Zusätzlich zur Unterstützung von Windows Server 2008 als Betriebssystemplattform führt Exchange 2007 SP1 auch die Unterstützung für die folgenden Windows Server 2008-Failoverclusterfeatures ein. Die Unterstützung dieser Features wurde sowohl für die Befehlszeilenversion (Setup.com) als auch für die GUI-Version (Setup.exe, auch als Exchange Server 2007-Installations-Assistent bekannt) von Exchange 2007 Setup integriert.

Unterstützung für Failovercluster mit mehreren Subnetzen

Das Windows Server 2008-Failoverclustering führt neue Netzwerkfunktionen ein, die gegenüber der Vorgehensweise bei Legacyclustern wesentliche Veränderungen aufweisen. Die Windows Server 2008-Failovercluster führen z. B. die Unterstützung mehrerer Subnetze ein. Bei der Ausführung in einem Windows Server 2008-Failovercluster umfasst Exchange 2007 SP1 bei geografisch verteilten Clustern die Unterstützung eines Failovers über zwei Subnetze. Diese Unterstützung bezieht beide Einzelkopiecluster sowie die Postfachserver in einer CCR-Umgebung mit ein.

Beginnend mit dem Windows Server 2008-Failoverclustering können einzelne Clusterknoten nun in getrennten, gerouteten Netzwerken angesiedelt sein. Dies erfordert, dass von IP-Adressressourcen abhängige Ressourcen (z. B. Netzwerknamensressourcen) eine ODER-Logik (OR) implementieren, da es unwahrscheinlich ist, dass jeder Clusterknoten über eine direkte lokale Verbindung zu jedem, dem Cluster bekannten Netzwerk verfügt. Dies erleichtert das Onlineschalten von IP-Adressen- und Netzwerknamensressourcen, wenn Dienste oder Anwendungen ein Failover auf Remoteknoten ausführen.

Bei der Verwendung von Failoverclustern mit mehreren Subnetzen werden die einer Netzwerknamensressource zugeordneten IP-Adressen dynamisch im DNS (Domain Name System) registriert (wenn dieses für dynamische Aktualisierungen konfiguriert ist), wenn diese online gestellt werden. Daher werden nur die online befindlichen IP-Adressressourcen an Clients zurückgegeben. Da Clusterknoten in verschiedene geroutete Netzwerke gestellt werden können und die Kommunikationsmechanismen geändert wurden, um zuverlässige, über UDP (User Datagram Protocol) implementierte Sitzungsprotokolle (unicast) zu verwenden, gelten die Windows Server 2003-Netzwerkanforderungen für geografisch verteilte Cluster nicht länger in Windows Server 2008. Daher können Unternehmen eine SCC- oder CCR-Umgebung über zwei physische Datacenter bereitstellen, ohne VLAN-Technologie (virtual LAN) zum Einbeziehen der Subnetze einsetzen zu müssen.

Wenn eine Verschiebung oder ein Failover für einen Postfachclusterserver auftritt, der in einem geografisch verteilten Failovercluster mit mehreren Subnetzen bereitgestellt ist, bleibt der Name des Postfachclusterservers erhalten, was für die diesem Namen zugeordnete IP-Adresse nicht der Fall ist. Die Verfügbarkeit dieses Servers für Clients und andere Server hängt von der Propagierung der neuen IP-Adresse im DNS ab. Es kann einige Zeit in Anspruch nehmen, bist die DNS-Propagierung durchgeführt wird. Aus diesem Grund wird empfohlen, einen Gültigkeitswert (Time to Live, TTL) für den DNS-Hosteintrag des Postfachclusterservers von 10 Minuten festzulegen.

Obwohl für interne Microsoft Outlook-Clients keine neuen oder neu konfigurierten Profile erforderlich sind, um die Verbindung über neue IP-Adressen herzustellen, müssen sie auf das Löschen des lokalen DNS-Caches warten, damit die Namensauflösung für den Namen des Postfachclusterservers von der alten zur neuen IP-Adresse wechselt. Nachdem die IP-Adresse an die entsprechenden DNS-Server propagiert wurde, kann der DNS-Cache auf den Outlook-Clients mithilfe des folgenden Befehls über die Befehlszeile des Clients gelöscht werden.

ipconfig /flushdns

Unterstützung für DHCP-IPv4

Beim Windows Server 2008-Failoverclustering besteht die Möglichkeit, dass Cluster-IP-Adressressourcen ihre Adresse von DHCP-Servern sowie über statische Einträge erhalten. Wenn die Clusterknoten selbst für den Erhalt der IP-Adressen über einen DHCP-Server konfiguriert sind, entspricht der automatische Empfang der IP-Adresse für alle Cluster-IP-Adressressourcen der Standardvorgehensweise. Wenn dem Clusterknoten die IP-Adressen statisch zugeordnet werden, müssen auch die Cluster-IP-Adressressourcen mit statischen IP-Adressen konfiguriert werden. Somit folgt die IP-Zuordnung für die Cluster-IP-Adressressource der Konfiguration des physischen Knotens und jeder spezifischen Schnittstelle im Knoten.

Unterstützung für IPv6

IPv6 wird von Windows Server 2008 und dem Clusterdienst unterstützt. Dies bezieht die Unterstützung von IPv6- und IPv4-IP-Adressressourcen mit ein, sowohl eigenständig als auch in Kombination in einem Cluster. Zusätzlich unterstützen Failovercluster auch ISATAP (Intra-site Automatic Tunneling Addressing Protocol) und sie unterstützen nur IPv6-Adressen, die eine dynamische Registrierung im DNS ermöglichen (AAAA-Hosteinträge und die IP6.ARPA-Zone für umgekehrte Lookups). Derzeit gibt es drei Arten von IPv6-Adresstypen: Global, Site-Local und Link-Local. Dynamische DNS-Registrierungen werden nicht für Link-Local-Adressen durchgeführt und daher können die Link-Local-Adressen nicht in einem Cluster verwendet werden.

Exchange- und Failovercluster-Netzwerkkonfiguration

Wenn Sie einen Einzelkopiecluster (SCC) oder eine fortlaufende Clusterreplikation (CCR) für Exchange 2007 SP1 konfigurieren, müssen Sie folgende Anforderungen berücksichtigen:

• IPv6 und DHCP IPv4 werden nur unter Windows Server 2008 unterstützt. Wenn Exchange 2007 unter Windows Server 2003 ausgeführt wird, können beide Protokolle nicht verwendet werden.

• DHCP IPv6 wird von Windows Server 2008 oder dem Clusterdienst nicht unterstützt. Daher wird es auch nicht von Exchange 2007 unterstützt. Es werden nur vom System zugeordnete dynamische IPv6-Adressen unterstützt.

• Statische IPv6-Adressen werden von Windows Server 2008 und dem Clusterdienst unterstützt. Die Verwendung statischer IPv6-Adressen widerspricht jedoch den bewährten Methoden. Daher unterstützt Exchange 2007 das Konfigurieren statischer IPv6-Adressen beim Setup nicht.

• IPv6-Tunneling über IPv4 wird vom Windows Server 2008-Clustering unterstützt, aber das Exchange-Setup ermöglicht die Erstellung dieser Art von IP-Adressressource nicht.

Setup wurde in Exchange 2007 SP1 modifiziert, um die zuvor beschriebenen Änderungen zu unterstützen. Beachten Sie bei der Verwendung des Exchange Server 2007-Installations-Assistenten, dass weitere Seiten und Felder für das Konfigurieren von Cluster-IP-Adressressourcen und Netzwerknamensressourcen zur Verfügung stehen. Zusätzlich wurden die Optionen /NewCMS und /RecoverCMS von Setup.com aktualisiert, um verschiedene neue optionale Parameter zu unterstützen, die in der folgenden Tabelle beschrieben sind.

In Exchange 2007 SP1 hinzugefügte optionale Parameter für "/NewCMS" und "/RecoverCMS"

Der Parameter CMSIPAddress, der für /NewCMS und /RecoverCMS in der RTM-Version von Microsoft Exchange Server 2007 ein erforderlicher Parameter war, wird noch immer zum Angeben einer einzelnen statischen IPv4-Adresse für den Postfachclusterserver verwendet. In Exchange 2007 SP1 ist der Parameter CMSIPAddress jetzt jedoch optional, da es für Setup ausreichend ist, wenn einer der vier Parameter angegeben wird.

Die Parameter in der vorangehenden Tabelle können nur unter Windows Server 2008 verwendet werden.

Neue Quorummodelle in Windows Server 2008

Wenn Netzwerkprobleme auftreten, können diese die Kommunikation zwischen Clusterknoten stören. Eine kleine Gruppe von Knoten kann möglicherweise über einen funktionierenden Teil eines Netzwerks kommunizieren, aber es ist nicht möglich, dass diese mit einer anderen Knotengruppe in einem anderen Teil des Netzwerks kommunizieren. Diese Situation kann zu schwerwiegenden Problemen führen. In dieser Split-Brain-Situation muss mindestens eine dieser Knotengruppen die Funktion als Cluster beenden, auch wenn die Knotengruppen keine eindeutigen Informationen über die Zustände anderer Knoten besitzen.

Damit die Probleme durch eine Unterteilung des Clusters vermieden werden, erfordert die Clustersoftware, dass jede als Cluster ausgeführte Knotengruppe einen Abstimmungsalgorithmus verwendet, um zu einem bestimmten Zeitpunkt zu ermitteln, dass diese Gruppe das Quorum besitzt. Da ein bestimmter Cluster eine bestimmte Anzahl von Knoten und eine bestimmte Quorumkonfiguration besitzt, ist dem Cluster bekannt, wie viele Stimmen eine Mehrheit ergeben (ein Quorum). Wenn die Anzahl keine Mehrheit ergibt, wird der Cluster angehalten. Die Knoten überwachen weiterhin die Anwesenheit anderer Knoten für den Fall, dass ein weiterer Knoten wieder im Netzwerk angezeigt wird. Die Knoten arbeiten aber erst wieder als Cluster, wenn das Quorum (die Mehrheit) erneut erreicht wurde.

Die Quorumkonfiguration in einem Failovercluster bestimmt den Zeitpunkt, an dem zu viele Fehler die Ausführung des Clusters beenden. Die in diesem Zusammenhang relevanten Fehler sind Fehler von Knoten oder in einigen Fällen auch von Datenträgerzeugen oder Dateifreigabezeugen (die eine Kopie der Clusterkonfiguration enthalten). Windows Server 2008 ermöglicht Ihnen die Auswahl unter vier denkbaren Quorumkonfigurationen:

• Knotenmehrheit   Dieses Modell wird für Cluster mit einer ungeraden Anzahl von Knoten empfohlen. Die Anzahl der Ausfälle, die dieses Modell aushalten kann, ergibt sich aus der Hälfte der Knotenanzahl minus 1. Ein Cluster mit 7 Knoten kann beispielsweise 3 Knotenausfälle überstehen.

• Knoten- und Datenträgermehrheit   Dieses Modell wird für Cluster mit einer geraden Anzahl von Knoten empfohlen. Die Anzahl der Ausfälle, die dieses Modell aushalten kann, entspricht der Hälfte der Knotenanzahl, wenn der Datenträgerzeuge online bleibt. Ein Cluster mit 6 Knoten und einem Datenträgerzeugen kann 3 Knotenausfälle überstehen. Die Anzahl der Ausfälle, die dieses Modell überstehen kann, kann sogar der Hälfte der Knotenanzahl minus 1 entsprechen, wenn der Datenträgerzeuge offline geht oder ausfällt. Ein Cluster mit 6 Knoten, in dem der Datenträgerzeuge ausgefallen ist, kann z. B. 2 Knotenausfälle überstehen (3-1 = 2).

• Knoten- und Dateifreigabe-Mehrheit   Dieses Modell wurde für Cluster mit speziellen Konfigurationen entwickelt und es wird für Postfachclusterserver in einer CCR-Umgebung empfohlen. Dieses Modell funktioniert auf dieselbe Weise wie das Modell mit Knoten- und Datenträgermehrheit, aber anstelle des Datenträgerzeugen verwendet es einen Dateifreigabezeugen.

• Kein Mehrheitsquorum: Nur Datenträger   Dieses Modell wird nicht empfohlen, obwohl es unterstützt wird. Es kann Ausfälle aller Knoten mit Ausnahme von 1 Knoten überstehen. Diese Konfiguration wird jedoch nicht empfohlen, da der Datenträger einen einzelnen Fehlerpunkt darstellt.

Fortlaufende Replikation über redundante Clusternetzwerke

In Exchange 2007 RTM erfolgen sämtliche Kopier- und Seedingvorgänge für Transaktionsprotokolldateien in einer CCR-Umgebung über das öffentliche Netzwerk. Für diese Konfiguration gelten folgende Einschränkungen:

• Wenn der passive Knoten mehrere Stunden nicht verfügbar ist, kann sich eine erhebliche Anzahl von Protokollen ansammeln, die übertragen werden muss. Die Verschiebung dieser Protokolle muss so schnell wie möglich erfolgen, sobald der passive Knoten verfügbar ist. Beim Kopieren der Protokolle über das öffentliche Netzwerk konkurriert die Verschiebung der Protokolle mit dem Clientdatenverkehr. Dies wirkt sich auf den Clientdatenverkehr aus und verlangsamt die erneute Synchronisation.

• Wenn das öffentliche Netzwerk ausfällt, ergibt sich ein verlustreicher Failover, auch wenn die Protokolldaten verfügbar sind.

• Durch die Verwendung eines isolierten Netzwerks für die Protokollkommunikation haben Sie die Möglichkeit, die Sicherheit für Nachrichtendaten ohne Verschlüsselung bereitzustellen, wodurch auch die zugehörigen Leistungseinbußen ausbleiben.

• Unter gewissen Umständen kann es zu einem Ansturm von Protokollen kommen. Wenn dieser auftritt, erfährt das System eine ungewöhnlich hohe Replikationsbelastung. Diese Situation kann zu einer Unterversorgung von Clients führen, wenn die Protokolldaten über dasselbe Netzwerk übertragen werden müssen, das für die Kommunikation mit den Clients verwendet wird.

Nicht alle genannten Probleme treten mit der gleichen Häufigkeit auf. Das erste Problem kann jedoch sicherlich alle paar Monate auftreten, da die passiven Knoten für regelmäßige Wartungsmaßnahmen offline gestellt werden.

Exchange 2007 SP1 minimiert die Auswirkungen der vorhergehenden Probleme, indem es dem Administrator ermöglicht, ein oder mehrere gemischte Netzwerke im Cluster für die Protokollübermittlung zu erstellen (z. B. ein Clusternetzwerk, das sowohl den internen Taktdatenverkehr des Clusters als auch den Clientdatenverkehr unterstützt). Exchange 2007 SP1 bietet einem Administrator außerdem die Möglichkeit, ein bestimmtes Netzwerk für das Seeding anzugeben.

Die Unterstützung für das Kopieren von Protokolldateien über ein gemischtes Netzwerk wird mithilfe eines neuen Cmdlets der Exchange-Verwaltungsshell namens Enable-ContinuousReplicationHostName konfiguriert. Ähnlich erzielen Sie die Deaktivierung dieses Features durch Verwendung des Cmdlets Disable-ContinuousReplicationHostName. Nachdem ein Postfachclusterserver in einer CCR-Umgebung vorhanden ist, kann ein Administrator das Cmdlet Enable-ContinuousReplicationHostName auf beiden Knoten des Clusters ausführen und weitere IP-Adressen und Hostnamen angeben, die dann in dedizierten Clustergruppen erstellt werden, die den einzelnen Knoten zugeordnet sind. Nachdem diese Aufgabe durchgeführt wurde, beginnt der Microsoft Exchange-Replikationsdienst kurz nach der erfolgreichen Konfiguration und im Anschluss an die Bestätigung, dass das neue Netzwerk einsatzbereit ist, mit dem Kopieren von Protokollen über dieses neu erstellte Netzwerk. Wenn mehrere neue Netzwerke erstellt werden, wählt der Microsoft Exchange-Replikationsdienst wahllos ein Netzwerk aus. Wenn das angegebene Netzwerk nicht mehr verfügbar ist, beginnt der Microsoft Exchange-Replikationsdienst automatisch mit der Verwendung weiterer Replikationsnetzwerke. Wenn kein Replikationsnetzwerk verfügbar ist, beginnt er innerhalb von 5 Minuten damit, das öffentliche Netzwerk für den Protokollversand zu verwenden. (Die Netzwerkerkennung durch den Microsoft Exchange-Replikationsdienst erfolgt alle 5 Minuten.) Wenn das bevorzugte Replikationsnetzwerk erneut verfügbar ist, verwendet der Microsoft Exchange-Replikationsdienst dieses Netzwerk automatisch wieder für den Protokollversand. Weitere Informationen über die Cmdlets finden Sie unter Enable-ContinuousReplicationHostName und Disable-ContinuousReplicationHostName.

Die Unterstützung für das Seeding über ein redundantes Clusternetzwerk wird mithilfe des Cmdlets Update-StorageGroupCopy konfiguriert, das in Exchange 2007 SP1 aktualisiert wurde, um einen neuen Parameter mit der Bezeichnung DataHostNames einzubeziehen. Dieser Parameter gibt an, welches Clusternetzwerk für das Seeding zu verwenden ist. Weitere Informationen zu den Änderungen am Cmdlet Update-StorageGroupCopy in Exchange 2007 SP1 finden Sie unter Update-StorageGroupCopy.

Nachdem ein Clusternetzwerk für die fortlaufende Replikation erstellt wurde, können Sie das Cmdlet Get-ClusteredMailboxServerStatus dazu verwenden, um aktualisierte Informationen über Clusternetzwerke anzuzeigen, die für die fortlaufende Replikationsaktivität aktiviert wurden. Die neuen Ausgabedetails umfassen:

• OperationalReplicationHostNames:{Host1,Host2,Host3}

• FailedReplicationHostNames:{Host4}

• InUseReplicationHostNames:{Host1,Host2}

Weitere Informationen zu den Änderungen am Cmdlet Get-ClusteredMailboxServerStatus in Exchange 2007 SP1 finden Sie unter Get-ClusteredMailboxServerStatus.

Weitere Informationen zum Aktivieren von Clusternetzwerken für die fortlaufende Replikation unter Windows Server 2003 finden Sie unter Aktivieren redundanter Clusternetzwerke für Protokollversand und Seeding mit Windows Server 2003.

Weitere Informationen zum Aktivieren von Clusternetzwerken für die fortlaufende Replikation unter Windows Server 2008 finden Sie unter Aktivieren redundanter Clusternetzwerke für Protokollversand und Seeding mit Windows Server 2008.

Weitere Informationen zum Deaktivieren von Clusternetzwerken für die fortlaufende Replikation finden Sie unter Deaktivieren der fortlaufenden Replikation in einem Clusternetzwerk.

Verbesserungen an der Berichterstellung und Überwachung

In Exchange 2007 SP1 sind auch verschiedene Änderungen enthalten, die die Verwaltungsfreundlichkeit von Exchange 2007 erhöhen. Dazu zählen Verbesserungen der Berichtsfeatures für Cluster in Exchange 2007 RTM sowie zusätzliche Funktionalität für die proaktive Überwachung von Umgebungen mit fortlaufender Replikation. Insbesondere werden durch die Änderungen und Verbesserungen bekannte Mängel des Cmdlets Get-StorageGroupCopyStatus korrigiert, ein neues Cmdlet namens Test-ReplicationHealth eingeführt und eine verbesserte Einsichtnahme in das vom Transportpapierkorb abgedeckte Verlustfenster bereitgestellt. Weitere Informationen über diese Verbesserungen an der Berichterstellung und Überwachung finden Sie unter Überwachen der fortlaufenden Replikation.

Leistungsverbesserungen

In Exchange 2007 SP1 wurden Leistungsverbesserungen vorgenommen, die für Bereitstellungen mit hoher Verfügbarkeit von Vorteil sind. Diese Verbesserungen umfassen unter anderem:

• E/A-Verringerungen für die Datenträger, auf denen sich passive Kopien von Speichergruppen in Umgebungen mit fortlaufender Clusterreplikation befinden   In Exchange 2007 SP1 wurde das Design der Architektur mit fortlaufender Replikation so geändert, dass der Datenbankcache nun zwischen den einzelnen Instanzen der Protokollwiedergabe auf dem passiven Knoten beibehalten wird. Durch die Beibehaltung des Datenbankcaches zwischen den einzelnen Instanzen der Protokollwiedergabe wird der Microsoft Exchange-Replikationsdienst in die Lage versetzt, die Datenbankcachefeatures der Extensible Storage Engine (ESE) zu nutzen, wodurch wiederum die Menge der Datenträger-E/A-Operationen für die logischen Gerätenummern (Logical Unit Number, LUN) der passiven Kopie verringert wird. In Exchange 2007 RTM hingegen wurde für jeden Batch von Protokollwiedergaben ein neuer Datenbankcache erstellt, was dazu führte, dass die Datenträger-E/A-Aktivität für den passiven Knoten bis zu zwei- bis dreimal so hoch war wie die Datenträger-E-/A-Aktivität für den aktiven Knoten.

  Schnellere Verschiebung von Postfachclusterservern zwischen Knoten in einer CCR-Umgebung   Mithilfe dieser Verbesserungen können die Postfachclusterserver in maximal zwei Minuten zwischen Knoten verschoben werden. Dies bezieht Verschiebungen durch einen Administrator (mithilfe des Cmdlets Move-ClusteredMailboxServer) und Failovers mit ein, die vom Clusterdienst verwaltet werden. Die Datenbanken werden offline gestellt, ohne den Datenbankcache zu leeren, damit schnelle Verschiebungen in einer CCR-Umgebung erreicht werden. In einem Einzelkopiecluster (SCC) dauert das Verschieben des Postfachclusterservers ungefähr fünf Minuten. Der Datenbankcache wird weiterhin geleert, bevor der Postfachclusterserver verschoben wird. Hierbei handelt es sich um ein bequemes Leeren des Caches, da es den Clients ermöglicht, die Verbindung zur Datenbank aufrecht zu erhalten. Dieses Verhalten verkürzt die Ausfallzeit, die beim Verschieben des Postfachclusterservers auf einen anderen Knoten auftritt.

  Während des Failoverprozesses wird die Ereignis-ID 9868 zweimal protokolliert, um den Status der Leerung anzuzeigen, und die Ereignis-ID 113, um den Replikationsstatus anzugeben. Diese Ereignisse ähneln den folgenden:

  Ereignis-ID: 9868 Quelle: MSExchangeIS Kategorie: Allgemein Typ: Informationen Beschreibung: Die versuchte Cacheleerung für Server '<Postfachservername>' wurde abgeschlossen, jedoch erreichten 0 Speichergruppen(n) nicht die gewünschte Prüfpunkttiefe.

  Ereignis-ID: 9868 Quelle: MSExchangeIS Kategorie: Allgemein Typ: Informationen Beschreibung: Die versuchte Cacheleerung für Server '<Postfachservername>' wurde abgeschlossen, jedoch erreichten 2 Speichergruppen(n) nicht die gewünschte Prüfpunkttiefe.

  Ereignis-ID: 113 Quelle: MSExchangeRepl Kategorie: Verschieben Typ: Informationen Beschreibung: Die Cacheleerung des Informationsspeichers vor dem Verschieben von Postfachclusterserver '<Postfachservername>' wurde nicht abgeschlossen. Daten: Speichergruppe '<Postfachservername>\<Speichergruppenname>': Der Start der Prüfpunkttiefe war 19 und das Ende war 17. Speichergruppe '<Postfachservername>\<NameDerZweitenSpeichergruppe>': Der Start der Prüfpunkttiefe war 19 und das Ende war 13.

Verbesserungen am Transportpapierkorb

Der Transportpapierkorb ist ein Feature der Serverfunktion Hub-Transport. Der Transportpapierkorb verwaltet eine Warteschlange mit Nachrichten, die kürzlich Empfängern zugestellt wurden, deren Postfach sich auf einem Postfachclusterserver in einer CCR-Umgebung befindet. Diese Warteschlange ist abhängig von der Aufbewahrungsdauer von E-Mails und dem gesamten verwendeten Speicherplatz. Bei einem nicht verlustfreien Failover fordert der Postfachclusterserver automatisch jeden Hub-Transport-Server am Active Directory-Standort auf, alle Nachrichten aus der Transportpapierkorb-Warteschlange erneut zu senden.

In Exchange 2007 SP1 wurde der Transportpapierkorb wie folgt verbessert:

• Unterstützung für LCR   Der Transportpapierkorb umfasst jetzt die Unterstützung für LCR-Bereitstellungen. Anders als bei CCR, wo die Anforderung für die erneute Zustellung aus dem Transportpapierkorb bei der Wiederherstellung automatisch ausgeführt wird, muss dieser Vorgang in einer LCR-Umgebung manuell ausgeführt werden. Das Cmdlet Restore-StorageGroupCopy wurde in Exchange 2007 SP1 aktualisiert und umfasst nun die Anforderung für die erneute Übermittlung aus dem Transportpapierkorb. Wenn ein Administrator mit dem Cmdlet Restore-StorageGroupCopy eine passive Kopie einer Speichergruppe in einer LCR-Umgebung aktiviert, wird daher die Anforderung für die erneute Übermittlung aus dem Transportpapierkorb als Teil der Aktivierung ausgeführt.

• Transportpapierkorbstatistik   Damit ein Administrator vor der Wiederherstellung eines Servers, auf dem Protokolldateien fehlen, besser informiert ist, wurde der Transportpapier erweitert. Er umfasst jetzt statistische Informationen, die den aktuellen Status aller Hub-Transport-Server bereitstellen, die Nachrichten für eine betroffene Speichergruppe enthalten. Diese Statistik umfasst die Anzahl der Nachrichten sowie das Alter der ältesten Nachricht für alle Hub-Transport-Server des Active Directory-Standorts. Diese Statistik kann mithilfe eines neuen Parameters des Cmdlets Get-StorageGroupCopyStatus mit der Bezeichnung DumpsterStatistics angezeigt werden. Mithilfe dieses neuen Werts umfasst die Ausgabe für Get-StorageGroupCopyStatus eine Transportpapierkorbstatistik für alle verfügbaren Hub-Transport-Server sowie eine Liste der Hub-Transport-Server, auf die nicht zugegriffen werden kann. Verfügbare Server werden in einer mehrwertigen Struktur namens DumpsterStatistics aufgeführt, während nicht verfügbare Server als mehrwertige Zeichenfolge namens DumpsterStatisticsNotAvailable aufgeführt werden, wie nachfolgend veranschaulicht:

  DumpsterStatistics: {HUB1 (ältester Zeitstempel; Anzahl der Elemente im Papierkorb; Größe des Papierkorbs), HUB2 (ältester Zeitstempel; Anzahl der Elemente im Papierkorb; Größe des Papierkorbs), HUB3 (ältester Zeitstempel; Anzahl der Elemente im Papierkorb; Größe des Papierkorbs)}

  DumpsterStatisticsNotAvailable: {HUB4,HUB5}

  Im vorangegangenen Beispiel stellt der älteste Zeitstempel den Zeitpunkt dar, an dem die Nachricht vom Hub-Transport-Server empfangen wurde und nicht den Zeitpunkt, an dem die Nachricht ursprünglich an den Postfachserver übermittelt wurde.

  Das Cmdlet Get-StorageGroupCopyStatus umfasst auch eine neue mehrwertige Struktur namens OutstandingDumpsterRequests, die Hub-Transport-Server mit ausstehenden Anforderungen und den Zeitraum (niedrig-hoch) für ausstehende Anforderungen einbezieht, wie nachfolgend veranschaulicht:

  OutstandingDumpsterRequests: {HUB1 (time-low;time_high), HUB5 (time_low;time_high)}

Verbesserungen bei der Exchange-Verwaltungskonsole

Exchange 2007 SP1 enthält neue GUI-Elemente in der Exchange-Verwaltungskonsole, die dazu gedacht sind, die Verwaltung und Konfiguration für Postfachclusterserver zu verbessern. Diese Verbesserungen umfassen unter anderem:

• Assistent zum Verwalten von Postfachclusterservern   Dieser Assistent wird zum Verschieben, Anhalten oder Starten eines Postfachclusterservers in einer CCR- oder SCC-Umgebung verwendet. Die Funktionen zum Verschieben und Anhalten umfassen auch die optionalen Kommentarfelder für Administratoren, über die dieser den Grund eingeben kann, warum der Postfachclusterserver verschoben oder angehalten wird. Dieser Assistent entspricht der Verwendung der folgenden Cmdlets der Exchange-Verwaltungsshell:

  • Move-ClusteredMailboxServer

  • Stop-ClusteredMailboxServer

  • Start-ClusteredMailboxServer

• Verwaltung der fortlaufenden Replikation   Der Benutzeroberfläche der Exchange-Verwaltungskonsole wurden zusätzliche Steuerelemente hinzugefügt, die es dem Administrator ermöglichen, die fortlaufende Replikation anzuhalten, fortzusetzen, zu aktualisieren und wiederherzustellen. Diese Steuerelemente entsprechen der Verwendung der folgenden Cmdlets der Exchange-Verwaltungsshell:

  • Suspend-StorageGroupCopy

  • Resume-StorageGroupCopy

  • Update-StorageGroupCopy

  • Restore-StoreGroupCopy

  Mithilfe dieser Cmdlets und der entsprechenden Exchange-Verwaltungskonsolenaufgaben können Sie die fortlaufende Replikation sowohl in LCR- als auch in CCR-Umgebungen verwalten.

  Hinweis

  In einer CCR-Umgebung ist der Assistent zum Aktualisieren von Speichergruppenkopien nur über den passiven Knoten verfügbar, während der Assistent zum Wiederherstellen von Speichergruppenkopien nur über den aktive Knoten verfügbar ist.

• Postfachclusterserver (Registerkarte)   Es wurde für Postfachserver, die in einem Cluster enthalten sind, zum Dialogfeld Server Eigenschaften eine neue Registerkarte hinzugefügt. Diese Informationen sind sowohl für CCR- als auch für SCC-Umgebungen verfügbar. Die neue Registerkarte bietet ausführliche Informationen über den Postfachclusterserver und ermöglicht es dem Administrator, den Wert für die Eigenschaft AutoDatabaseMountDial für Postfachclusterserver in einer CCR-Umgebung zu konfigurieren. Viele der Informationen, die auf der neuen Registerkarte angezeigt werden, sind auch mithilfe des Cmdlets Get-ClusteredMailboxServerStatus verfügbar. Weitere Informationen über die Registerkarte Postfachclusterserver finden Sie unter Server Eigenschaften > Postfachclusterserver (Registerkarte).

• Fortlaufende Clusterreplikation (Seite)   Es wurde zum Dialogfeld Speichergruppe Eigenschaften eine neue Seite für Postfachserver hinzugefügt, die in einer CCR-Umgebung bereitgestellt werden. Die neue Eigenschaftenseite bietet detaillierte Informationen über den Status der fortlaufenden Replikation im Cluster. Weitere Informationen über die Seite Fortlaufende Clusterreplikation finden Sie unter Speichergruppe Eigenschaften > Fortlaufende Clusterreplikation (Seite).

Weitere Informationen

Windows Server 2008 enthält verschiedene Features, die erweitert oder umbenannt wurden. Weitere Informationen zu geänderten Features zwischen Windows Server 2003 und Windows Server 2008 finden Sie unter Terminologieänderungen.