Planen der fortlaufenden Clusterreplikation

 

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

Letztes Änderungsdatum des Themas: 2008-07-23

Zwar ähnelt die Bereitstellung der fortlaufenden Clusterreplikation (Cluster Continuous Replication, CCR) der Bereitstellung der fortlaufenden lokalen Replikation (Local Continuous Replication, LCR) und der Bereitstellung eines Einzelkopieclusters (Single Copy Cluster), doch müssen einige wichtige Unterschiede berücksichtigt werden. Für CCR müssen allgemeine Anforderungen sowie Hardware-, Software-, Netzwerk- und Clusteranforderungen erfüllt werden.

Allgemeine Anforderungen an die fortlaufende Clusterreplikation

Stellen Sie sicher, dass die folgenden systemweiten Anforderungen erfüllt sind, bevor Sie die CCR bereitstellen:

• Es muss eine einzelne Datenbank pro Speichergruppe verwendet werden. Bei Erstellung einer Speichergruppe in einer CCR-Umgebung darf diese nur eine Datenbank enthalten. Auf diese Weise kann die Microsoft Exchange-Speichertopologie leichter verwaltet und die Wiederherstellbarkeit verbessert werden.

• DNS (Domain Name System) muss ausgeführt werden. Der DNS-Server sollte im Idealfall dynamische Updates akzeptieren. Wenn der DNS-Server keine dynamischen Updates akzeptiert, müssen Sie einen DNS-Hosteintrag (A-Eintrag) für jeden Postfachclusterserver und einen für den Cluster selbst erstellen. Andernfalls funktioniert Exchange nicht ordnungsgemäß. Weitere Informationen zum Konfigurieren von DNS für Exchange finden Sie im Microsoft Knowledge Base-Artikel 322856 Konfigurieren von DNS für eine Verwendung mit Exchange Server.

• Wenn die Clusterknoten zu einer Verzeichnisnamensdienst-Zone gehören, die einen anderen Namen als den Domänennamen des Active Directory-Verzeichnisdiensts hat, zu dem der Computer gehört, enthält die Eigenschaft DNSHostName nicht standardmäßig den Namen der Unterdomäne. In diesem Fall müssen Sie die DNSHostName-Eigenschaft ändern, um sicherzustellen, dass bestimmte Dienste, wie zum Beispiel der Dateireplikationsdienst (File Replication Service, FRS), ordnungsgemäß funktionieren. Weitere Informationen finden Sie im Knowledge Base-Artikel 240942 Active Directory-Eigenschaft DNSHostName enthält Subdomäne nicht.

• Alle Clusterknoten müssen Mitgliedsserver in derselben Domäne sein. Microsoft Exchange Server 2007 wird nicht auf Knoten unterstützt, die ebenfalls Active Directory-Server sind, oder auf Knoten, die Mitglieder verschiedener Active Directory-Domänen sind.

• Der Cluster muss zusammengestellt sein, bevor Exchange 2007 installiert wird. Weitere Informationen zum Bilden eines Windows Server 2008-Failoverclusters finden Sie unter Installieren der fortlaufenden Clusterreplikation unter Windows Server 2008. Weitere Informationen zum Bilden eines Windows Server 2003-Failoverclusters finden Sie unter Installieren eines Einzelkopieclusters.

• Die Namen von Postfachclusterservern (CMS) dürfen maximal 15 Zeichen lang sein.

• In dem Cluster, in dem Exchange 2007 installiert ist, kann weder Exchange Server 2003 noch Exchange 2000 Server oder eine clusteraktivierte Version von Microsoft SQL Server vorhanden sein. Das Ausführen von Exchange 2007 in einem Cluster zusammen mit einer dieser Anwendungen wird nicht unterstützt. Das Ausführen von Exchange 2007 in einem Cluster mit SQL Server 2005 Express Edition oder einer anderen Datenbankanwendung (z. B. Microsoft Office Access) zu dann zulässig, wenn die Datenbankanwendung nicht geclustert ist.

• Stellen Sie vor der Installation von Exchange 2007 sicher, dass der Ordner, in dem Sie Exchange installieren, leer ist.

• Auf allen Knoten im Cluster, die als Hosts eines Postfachclusterservers konfiguriert sind, muss dieselbe Version von Exchange 2007 installiert werden. Zusätzlich müssen die Betriebssystemdateien und die Exchange-Dateien auf allen Knoten im Cluster in identischen Pfaden installiert sein. Hierzu ist erforderlich, dass alle Computer über eine ähnliche, wenn auch nicht identische Datenträgerkonfiguration verfügen.

• Das Clusterdienstkonto muss auf jedem Knoten Mitglied der Gruppe der lokalen Administratoren sein, der in der Lage ist, als Host für einen Postfachclusterserver zu dienen.

• Installieren, erstellen oder verschieben Sie keine Ressourcen von der Standardclustergruppe in die Ressourcengruppe, die den Postfachclusterserver enthält. Installieren, erstellen oder verschieben Sie außerdem keine Ressourcen von der Gruppe, die den Postfachclusterserver enthält, in die Standardclustergruppe. Die Standardclustergruppe darf nur die Cluster-IP-Adresse, den Netzwerknamen und die Quorumressourcen enthalten. Das Verschieben oder Zusammenfassen von Ressourcen in die oder mit der Standardclustergruppe wird nicht unterstützt.

  Wichtig

  Cluster, auf denen frühere Versionen von Exchange ausgeführt werden, erfordern eine Instanz von Microsoft Distributed Transaction Coordinator (MSDTC). In Exchange 2007 entfällt diese Anforderung für die geclusterte MSDTC-Ressource. Postfachclusterserver in einer Umgebung mit fortlaufender Clusterreplikation verwenden und benötigen keine installierte MSDTC-Ressource auf dem Failovercluster. Für Anwendungen von Drittanbietern ist möglicherweise eine MSDTC-Ressource aufgrund von COM+-Abhängigkeiten erforderlich. In Windows Server 2003 erfordert der MSDTC-Cluster die Verwendung von freigegebenem Speicher im Cluster. Das Hinzufügen von freigegebenem Speicher zu einer Umgebung mit fortlaufender Clusterreplikation wird nicht empfohlen. Windows Server 2008 stellt eine lokale, nicht geclusterte MSDTC-Instanz bereit, die das Erfordernis von freigegebenem Speicher in einem Windows Server 2008-Failovercluster aufhebt. Weitere Informationen zu den MSDTC betreffenden Änderungen in Windows Server 2008 finden Sie in der Windows Server 2008-Hilfe.

Anforderungen an die Hardware für die fortlaufende Clusterreplikation

Um allgemeine Informationen zur Hardwareplanung erhalten, lesen Sie Planen von Prozessorkonfigurationen und Planen von Datenträgerspeicher. Folgende spezifisch für CCR-Umgebungen geltende Hardwareanforderungen müssen erfüllt werden:

• Wenn Sie ein Hauptknotensatzquorum mit einem Freigabezeugen unter Windows Server 2003 verwenden, dürfen nur exakt zwei Knoten im Cluster vorhanden sein. Wenn ein oder mehr als zwei Knoten im Cluster vorhanden sind, kann die Dateizeugenfunktion des Hauptknotensatzquorums nicht verwendet werden. Stattdessen muss ein herkömmliches Hauptknotensatzquorum verwendet werden, das drei oder mehr Knoten im Cluster erfordert.

• Wenn Sie das Knoten- und Dateifreigabe-Mehrheitsquorum unter Windows Server 2008 verwenden, dürfen nur exakt zwei Knoten im Cluster vorhanden sein. Wenn ein oder mehr als zwei Knoten im Cluster vorhanden sind, kann das Knoten- und Dateifreigabe-Mehrheitsquorum nicht verwendet werden. Stattdessen muss ein Knotenhauptquorum verwendet werden, das drei oder mehr Knoten im Cluster erfordert.

  Hinweis

  Es wird empfohlen, einen Failovercluster mit zwei Knoten zu verwenden, der entweder das Hauptknotensatzquorum mit Dateifreigabezeugen oder das Knoten- und Dateifreigabe-Mehrheitsquorum verwendet. Dadurch ist kein dritter Wählerknoten mehr im Cluster erforderlich.

• Die verwendeten Server müssen im Microsoft Windows Server-Katalog getesteter Produkte für das Betriebssystem aufgeführt werden, unter dem diese installiert werden. Wenn im Cluster jedoch kein freigegebener Speicher verwendet wird, müssen die Server nicht in der Clusterkategorie aufgeführt werden.

• Die beiden Server mit der Serverfunktion Mailbox müssen in folgenden Punkten vergleichbar, aber nicht identisch sein:

  • CPU

  • Arbeitsspeicher

  • Eingabe/Ausgabe (E/A)-Leistungsfähigkeit

  • Netzwerk

  • Lieferant

  • Verfügbarer Festplattenspeicher. Dies beinhaltet sowohl den Speicherplatz als auch die Leistungsfähigkeit hinsichtlich E/A-Operationen.

Quorumanforderungen an die fortlaufende Clusterreplikation

Im Allgemeinen kennen Clusteranwendungen den vom Cluster verwendeten Quorumtyp nicht, auf dem diese installiert sind. Beachten Sie beim Entwurf der Quorumkomponente für die CCR-Umgebung die Folgenden Empfehlungen und Anforderungen:

• Unter Windows Server 2008 ist ein Knoten- und Dateifreigabe-Mehrheitsquorum der ausdrücklich empfohlene Quorumtyp für CCR.

• Unter Windows Server 2003 ist ein Hauptknotensatzquorum mit Freigabezeugen der ausdrücklich empfohlene Quorumtyp für CCR.

Wenn einer der Quorumtypen für CCR verwendet wird, müssen die Knoten nicht im Microsoft Windows Server-Katalog für getestete Produkte aufgeführt werden.

Wenn ein freigegebenes Speicherquorum für CCR verwendet wird, muss das gesamte System im Microsoft Windows Server-Katalog für getestete Produkte aufgeführt werden.

In Exchange Server 2007 Service Pack 1 (SP1) blockiert das Setup Clusterkonfigurationen mit zwei Knoten, wenn kein Dateifreigabezeuge oder keine Dateifreigabemehrheit konfiguriert ist. Der Grund hierfür ist, dass die Konfiguration nicht in der Lage sein würde, einen Knoten im Cluster zu verlieren (da die Mehrheit nicht erhalten bleibt), wodurch der Cluster offline geschaltet wird.

Anforderungen an die Software für die fortlaufende Clusterreplikation

Folgende Softwareanforderungen müssen für CCR-Umgebungen erfüllt werden:

• Auf beiden Knoten im Cluster muss das Betriebssystem Windows Server 2008 Enterprise oder Windows Server 2003 Enterprise Edition installiert sein, und alle Knoten im Cluster müssen dieselben Start- und Systemlaufwerkbuchstaben verwenden. Es ist nicht möglich, dass in einem Cluster der eine Knoten Windows Server 2008 und der andere Knoten Windows Server 2003 ausführt. Gemischte Betriebssystemversionen in einem Failovercluster werden nicht unterstützt.

• Wenn Sie eine CCR-Umgebung mithilfe der RTM-Version (Release to Manufacturing) von Exchange 2007 in Windows Server 2003 installieren, muss auf beiden Knoten im Failovercluster entweder Windows Server 2003 Service Pack 2 (SP2) oder Windows Server 2003 SP1 und das Hotfix aus Knowledge Base-Artikel 921181 Eine Aktualisierung ist verfügbar, die ein Dateifreigabezeugen-Feature und ein konfigurierbares Clustertaktfeature zu Windows Server 2003 Service Pack 1-basierten Serverclustern hinzufügt, installiert sein. Dieses Hotfix ist in Windows Server 2003 SP2 enthalten. Wenn Sie eine CCR-Umgebung mithilfe von Exchange 2007 SP1 in Windows Server 2003 aufbauen, muss auf beiden Knoten im Failovercluster Windows Server 2003 SP2 installiert sein.

• Bei dem Cluster muss es sich entweder um einen drei Knoten umfassen Cluster mit herkömmlichen Hauptknotensatzquorum oder um einen zwei Knoten umfassenden Cluster mit einem Hauptknotensatzquorum mit Dateifreigabezeugen handeln. Im Allgemeinen wird angenommen, dass unter Windows Server 2003 ein Cluster mit zwei Knoten mit Hauptknotensatzquorum mit Dateifreigabezeuge und unter Windows Server 2008 ein Cluster mit zwei Knoten mit einem Knoten- und Dateifreigabe-Mehrheitsquorum verwendet wird.

• Der Dateifreigabezeuge für das Hauptknotensatzquorum oder das Dateifreigabe-Mehrheitsquorum muss sich nicht auf einem dedizierten Computer befinden. Er kann sich auf einem beliebigen Computer befinden, der Windows Server ausführt. Es wird jedoch empfohlen, dass Sie den Dateifreigabezeugen auf einem Hub-Transport-Server speichern (oder einem anderen Exchange-Server), damit dieser der Kontrolle des Exchange-Administrators untersteht.

• In einem Cluster kann nur die Serverfunktion Mailbox installiert werden. Auf einem Computer, der Teil eines Failoverclusters ist, können keine anderen Serverfunktionen installiert werden.

Anforderungen an das Netzwerk für die fortlaufende Clusterreplikation

Es ist wichtig, dass die Netzwerke für die Client- und Clusterkommunikation ordnungsgemäß konfiguriert sind. In diesem Abschnitt werden Links zu den Verfahrensweisen bereitgestellt, die notwendig sind, um sicherzustellen, dass die privaten und öffentlichen Netzwerkeinstellungen ordnungsgemäß konfiguriert sind. Zusätzlich müssen Sie sicherstellen, dass die Netzwerkverbindungen für den Cluster in der richtigen Reihenfolge konfiguriert sind. Ziehen Sie folgende Punkte in Betracht, wenn Sie die Netzwerkinfrastruktur für Ihre CCR-Umgebung entwerfen:

• Jeder Knoten muss mindestens zwei Netzwerkkarten für die Bildung eines Windows-Clusters zur Verfügung haben. Clients und andere Server müssen nur über eine der beiden Netzwerkkarten auf die Knoten zugreifen können. Die anderen Netzwerkkarten werden für die Kommunikation zwischen den Clustern verwendet. Die empfohlene Konfiguration besteht aus dem privaten Netzwerk, das für die interne Clusterkommunikation reserviert ist, und dem öffentlichen Netzwerk, das als "gemischt" gekennzeichnet ist.

• Das öffentliche Clusternetzwerk sollte die Verbindungen mit anderen Servern mit Exchange sowie mit anderen Diensten wie Active Directory und DNS bereitstellen. Durch die Zusammenführung von Netzwerkkarten oder ähnlichen Technologien können Sie verhindern, dass es an dieser Stelle zu einer einzelnen Fehlerquelle kommt.

• Ein gesondertes privates Clusternetzwerk muss bereitgestellt werden. Das private Netzwerk wird für den Clustertakt verwendet. Bei einem privaten Netzwerk ist kein DNS erforderlich.

• Taktanforderungen sind vielleicht nicht die strikteste Anforderung an öffentliche Netzwerkbandbreiten und Wartezeiten für eine Konfiguration mit zwei Datencentern. Sie müssen die gesamte Netzwerklast berechnen, zu welcher Clientzugriff, Active Directory, Transport, fortlaufende Replikation und anderer Anwendungsdatenverkehr gehört, um die erforderlichen Netzwerkvoraussetzungen für die Umgebung zu bestimmen.

• Wir empfehlen die Verwendung von Gigabit-Ethernet für CCR-Umgebungen, um die Zeit für das erneute Seeding zu maximieren. Weitere Informationen zur Frage, warum Gigabit-Ethernet empfohlen wird, finden Sie weiter unten in diesem Thema unter "Datenbankgröße und fortlaufende Clusterreplikation".

• In Exchange 2007 RTM kann eine Ressourcengruppe, die nur einen Postfachclusterserver enthält, nur eine Netzwerknamenressource aufweisen. Die Verwendung mehrerer Netzwerknamenressourcen in Ressourcengruppen, die einen Postfachclusterserver enthalten, wird in Exchange 2007 RTM nicht unterstützt. Diese Einschränkung ist in Exchange 2007 SP1 jedoch nicht vorhanden. Wenn der Postfachclusterserver auf Exchange 2007 SP1 aktualisiert wurde, können mehrere Netzwerknamenressourcen in der Ressourcengruppe vorhanden sein, die den Postfachclusterserver enthält.

Netzwerkanforderungen für die Installation von fortlaufender Clusterreplikation in Windows Server 2008

Die Netzwerkanforderungen für das Installieren der fortlaufenden Clusterreplikation in Windows Server 2008 unterscheiden sich etwas von den Anforderungen für das Installieren der fortlaufenden Clusterreplikation in Windows Server 2003. Wie in Windows Server 2003, müssen Sie beim Installieren der fortlaufenden Clusterreplikation in Windows Server 2008 über ausreichend freie IP-Adressen für beide Knoten und für den Postfachclusterserver (CMS) verfügen. Jedoch stehen in Windows Server 2008 einige weitere Optionen zur Verfügung, die in Windows Server 2003 nicht verfügbar sind:

• Clusterknoten können sich in verschiedenen Subnetzen befinden. In Windows Server 2003 muss sich die Netzwerkschnittstelle für jedes Netzwerk auf jedem Knoten im gleichen Subnetz wie das entsprechende Netzwerk auf dem anderen Knoten befinden. Diese Anforderung besteht in Windows Server 2008 nicht. Daher können Knoten innerhalb eines Failoverclusters über Netzwerkrouter hinweg kommunizieren, und es muss keine VLAN-Technologie (virtual LAN, virtuelles LAN) verwendet werden, um die Knoten zu verbinden.

• Bei der Verwendung mehrerer Subnetze in einer Umgebung mit fortlaufender Clusterreplikation kann sich DNS-Replikation auf die Fähigkeit eines Clients auswirken, nach dem Auftreten eines Failovers oder einer Übergabe des Postfachclusterservers unter den Knoten erneut eine Verbindung mit einem Postfachclusterserver herzustellen. Clients und andere Server, die mit einem Postfachclusterserver mit geänderter IP-Adresse kommunizieren, können erst wieder mit dem Postfachclusterserver kommunizieren, wenn das DNS mit der neuen IP-Adresse aktualisiert wurde und eine Aktualisierung aller lokalen DNS-Caches stattgefunden hat. Um die Zeitspanne zu reduzieren, die benötigt wird bis die DNS-Änderungen auf Clients und anderen Servern bekannt sind, sollten Sie einen DNS-TTL-Wert (Time to Live) von fünf Minuten für die Netzwerknamenressource des Postfachclusterservers festlegen. In den meisten Umgebungen empfiehlt sich die Einrichtung des DNS TTL-Werts nur für die Netzwerknamenressource des Postfachclusterservers. In Umgebungen mit Nicht-Exchange-Verwaltungstools, die zu Verwaltungszwecken mit dem entsprechenden Namen eine Verbindung zum Cluster herstellen, wird die Einrichtung eines niedrigeren TTL-Werts für die Netzwerknamenressource des Clusters angeraten. Ausführliche Anweisungen zum Konfigurieren der DNS-TTL-Werte für Netzwerknamenressourcen zur Verwendung auf einem Postfachclusterserver mit mehreren Subnetzen oder in einem Ersatzcluster finden Sie unter Konfigurieren von DNS TTL-Werten für Netzwerknamenressourcen.

• Beim Windows Server 2008-Failoverclustering besteht die Möglichkeit, dass Cluster-IP-Adressressourcen ihre Adresse von DHCP-Servern (Dynamic Host Configuration Protocol) 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. Die Verwendung von DHCP für Postfachclusterserver wird nicht empfohlen. Vor der Verwendung von DHCP für einen Postfachclusterserver sollten die folgenden Punkte erwogen werden:

  • Der Clusterdienst kann eine DHCP-aktivierte IP-Adressressource nicht online zur Verfügung stellen, wenn sich die IP-Adresse ändert.

  • DHCP-Server sollten für die Erteilung einer uneingeschränkten Lease für alle von DHCP zugewiesenen Adressen konfiguriert werden, die von Postfachclusterservern verwendet werden.

• Windows Server 2008 und dessen Clusterdienst unterstützen ebenfalls IPv6 (Internet Protocol Version 6). 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). Die Verwendung von IPv6-Adressen und IP-Adressbereichen wird nur unterstützt, wenn auf einem Computer unter Windows Server 2008 Exchange 2007 SP1 installiert ist, wenn auf diesem Computer sowohl IPv6 als auch IPv4 aktiviert sind und wenn das Netzwerk beide IP-Adressversionen unterstützt. Wenn Exchange 2007 SP1 in dieser Konfiguration implementiert ist, können alle Serverfunktionen Daten an Geräte, Server und Clients senden bzw. von diesen empfangen, die IPv6-Adressen verwenden. In einer Standardinstallation von Windows Server 2008 ist die Unterstützung für IPv4 und IPv6 aktiviert. Wenn Exchange 2007 SP1 unter Windows Server 2003 installiert ist, werden IPv6-Adressen nicht unterstützt. Weitere Informationen zur Unterstützung von IPv6-Adressen in Exchange 2007 SP1 finden Sie unter IPv6-Unterstützung in Exchange 2007 SP1 und SP2.

Netzwerkanforderungen für die Installation von fortlaufender Clusterreplikation in Windows Server 2003

Wenn Sie eine fortlaufende Clusterreplikation in Windows Server 2003 installieren, müssen Sie beim Erstellen von Postfachclusterservern in einer CCR-Konfiguration mit zwei Knoten über eine ausreichende Anzahl statischer IP-Adressen verfügen. Es wird eine IP-Adresse für den Cluster und eine für den Postfachclusterserver benötigt. Ferner werden IP-Adressen sowohl für die öffentlichen als auch für die privaten Netzwerke auf jedem Knoten benötigt:

• Private Adressen   Für jeden Knoten wird eine statische IP-Adresse pro Netzwerkkarte benötigt, die für das private Clusternetzwerk verwendet wird. Es müssen statische IP-Adressen verwendet werden, die nicht in einem derselben Subnetze oder Netzwerke liegen wie die öffentlichen Netzwerke. Es wird empfohlen, für die zwei Knoten als private IP-Adressen 10.10.10.10 und 10.10.10.11 mit einer Subnetzmaske von 255.255.255.0 zu verwenden. Wenn Ihr öffentliches Netzwerk ein 10.x.x.x-Netzwerk und die Subnetzmaske 255.255.255.0 verwendet, wird empfohlen, alternative IP-Adressen und eine andere Subnetzmaske für das private Netzwerk zu verwenden. Wenn Sie mehrere private Netzwerke konfigurieren, sind für jede private Netzwerkkarte und jedes Netzwerk eindeutige Adressen und Subnetze erforderlich.

• Öffentliche Adressen   Für jeden Knoten wird eine statische IP-Adresse pro Netzwerkkarte benötigt, die für das öffentliche Clusternetzwerk verwendet wird. Darüber hinaus werden für den Servercluster und den Postfachclusterserver statische IP-Adressen benötigt, damit Clients und Administratoren darauf zugreifen können. Es müssen statische IP-Adressen verwendet werden, die nicht in einem derselben Subnetze oder Netzwerke liegen wie die privaten Netzwerke.

Das private Netzwerk für alle Knoten in einem Cluster muss im selben Subnetz liegen. Sie können aber VLAN-Switches (virtuelles LAN) an den Anschlussstellen zwischen zwei Knoten verwenden. Wenn Sie ein VLAN verwenden, muss die Point-to-Point-Roundtrip-Wartezeit unter einer halben Sekunde liegen. Darüber hinaus muss der Link zwischen zwei Knoten für das Windows Server 2003-Betriebssystem, das auf den Knoten ausgeführt wird, als einzelne Point-to-Point-Verbindung angezeigt werden. Damit einzelne Fehlerquellen (Single Point of Failure, SPoF) vermieden werden, sollte unabhängige VLAN-Hardware für die verschiedenen Pfade zwischen den Knoten verwendet werden. Für Failovercluster, die unter Windows Server 2008 ausgeführt werden, gilt nicht dieselbe Subnetzeinschränkung.

Die öffentlichen Netzwerke für alle Knoten in einem Cluster müssen sich im selben Subnetz befinden. Alle Netzwerke müssen ein Subnetz verwenden, das sich von dem unterscheidet, das für die privaten Netzwerke verwendet wird. Für Failovercluster, die unter Windows Server 2008 ausgeführt werden, gilt nicht dieselbe Subnetzeinschränkung.

Die Verbindungsreihenfolge im Clusternetzwerk muss in Windows so konfiguriert werden, dass sich die öffentlichen Netzwerke an oberster Stelle der Liste der Verbindungsreihenfolge befinden, und die Netzwerkpriorität im Cluster muss mit den privaten Netzwerken an oberster Stelle in der Prioritätsreihenfolge konfiguriert werden.

Beim Installieren von CCR in Windows Server 2003 in einer Konfiguration mit mehreren Datenzentren:

• Alle für den Clientzugriff verwendeten Netzwerke müssen ausreichend Bandbreite sowie hinreichend niedrige Wartezeiten bereitstellen, um Clients in allen Datacentern den Zugriff auf den Postfachclusterserver zu ermöglichen.

• Alle zum Replizieren von Transaktionsprotokollen verwendeten Netzwerke müssen ausreichend Bandbreite sowie hinreichend niedrige Wartezeiten bereitstellen, damit die Protokolldateien zügig kopiert werden können, sodass es so selten wie möglich zu Rückständen bei den Protokolldateien kommt.

• Die für den Clustertakt verwendeten Netzwerke müssen in der Lage sein, ein Taktpaket innerhalb der erforderlichen Anzahl konfigurierter Wiederholungen zu senden und zu empfangen. Wenn Sie CCR unter SP2 für Windows Server 2003 oder unter SP1 für Windows Server 2003 und bei installiertem Hotfix aus Knowledge Base-Artikel 921181 Eine Aktualisierung ist verfügbar, die ein Dateifreigabezeugen-Feature und ein konfigurierbares Clustertaktfeature zu Windows Server 2003 SP1-basierten Serverclustern hinzufügt, installieren, werden die verlorenen Taktwiederholungen der Schnittstelle und des Knotens als Clusterkonfigurationseigenschaften offen gelegt. Wenn Sie CCR unter Windows Server 2008 installieren, ist diese Aktualisierung nicht erforderlich. In beiden Fällen werden die Takte weiterhin alle 1,2 Sekunden gesendet, aber der Cluster kann so konfiguriert werden, dass mehre Verluste auftreten müssen (entweder aufgrund verworfener Pakete, übermäßiger Wartezeit, Schnittstellenfehlern oder Knotenfehlern), bevor Wiederherstellungsmaßnahmen eingeleitet werden. Die Eigenschaftswerte werden in Einheiten von verpassten Takten und nicht von vergangener Zeit angegeben. Deshalb kann der Cluster nicht so konfiguriert werden, dass er nach fünf Sekunden einen Schnittstellenfehler annimmt. Er kann so konfiguriert werden, dass er nach fünf Verlusten von einem Schnittstellenfehler ausgeht, und in Abhängigkeit davon, wann tatsächlich der Fehler in der Taktdauer auftritt, dauern fünf Verluste ungefähr fünf bis sechs Sekunden. Beide Einstellungen weisen ein zulässigen Mindestwert von 2 Sekunden und einen maximalen Wert von 20 Sekunden auf.

Optimieren von Windows 2003-Netzwerken für CCR

Bei der Verwendung von CCR unter Windows Server 2003 wird empfohlen, die TCP/IP-Einstellungen von Windows Server hinsichtlich der spezifischen Geschwindigkeits- und Latenzwerte Ihrer Netzwerkverbindung zu optimieren. Insbesondere kann es erforderlich sein, die TCP-Empfangsfenstergröße (Transmission Control Protocol) sowie die RFC 1323-Fensterskalierungsoptionen (Request for Comments) auf dem aktiven und passiven Knoten anzupassen. Zusätzlich kann es vorteilhaft sein, Ablaufeinstellungen für den ARP-Cache (Address Resolution Protocol, Adressauflösungsprotokoll) zu konfigurieren und die erweiterten TCP/IP-Optionen für das Windows Server 2003 Scalable Networking Pack (SNP) in der Windows-Registrierung zu deaktivieren.

Über diese Empfehlungen hinaus ist es ratsam, wenn Ihre Umgebung das IPsec-Protokoll (IP Security) verwendet, IPsec konsistent in der gesamten CCR-Umgebung zu konfigurieren. Entweder sollten beide Knoten IPsec verwenden oder keiner. Wenn nur ein Knoten für die Verwendung von IPsec konfiguriert ist, kann der IPsec-Sicherheitszuordnungsprozess zu Paketverzögerungen oder sogar zu Paketverlusten führen.

TCP-Empfangsfenster und RFC 1323-Skalierungsoptionen

Das TCP-Empfangsfenster ist die maximale Datenmenge (in Bytes), die gleichzeitig über eine Verbindung empfangen werden kann. Der sendende Computer kann nur diese Höchstmenge von Daten senden und muss danach auf eine Bestätigung und eine TCP-Fensteraktualisierung vom empfangenden Computer warten. Es kann von Vorteil sein, diese Einstellung anzupassen, damit der Durchsatz während des Protokollversands erhöht wird.

Zur Optimierung des TCP-Durchsatzes sollte der sendende Computer genügend Pakete übermitteln, um die Leitung zwischen dem Sender und Empfänger zu füllen. Die Kapazität der Netzwerkleitung basiert auf ihrer Bandbreite und Latenz (Roundtrip-Wartezeit). Je größer die Latenz, desto höher ist die Kapazität der Netzwerkleitung, weil zwischen den einzelnen Bestätigungen mehr Zeit verbleibt, um Daten zu senden. Durch ein Vergrößern des TCP-Fensters kann das System die Zeiträume zwischen den Bestätigungen ausnutzen, indem mehr Daten gesendet werden.

Der TCP/IP-Standard erlaubt ein Empfangsfenster mit einer Größe von bis zu 65.535 Oktetten, wobei es sich um den Höchstwert handelt, der im 16-Bit-Feld für die TCP-Fenstergröße angegeben werden kann. Zur Verbesserung der Leistung bei Netzwerken mit hoher Bandbreite und großer Verzögerung unterstützt Windows Server-TCP/IP die Möglichkeit, Empfangsfenstergrößen von mehr als 65.535 Oktetten anzukündigen, indem skalierbare Fenster gemäß der Beschreibung in RFC 1323, TCP-Erweiterungen für hohe Leistung (nur in Englisch), verwendet werden. Bei Verwendung von Fensterskalierung können Hosts während einer Kommunikation eine Fenstergröße aushandeln, die es zulässt, dass mehrere große Pakete, wie sie zum Beispiel häufig von Dateiübertragungsprotokollen (File Transfer Protocol, FTP) verwendet werden, in den Puffern des Empfängers ausstehend sind. In RFC 1323 wird eine Methode zur Unterstützung größerer Empfangsfenster dargelegt, bei der TCP berechtigt ist, zum Zeitpunkt der Herstellung der Verbindung einen Skalierungsfaktor für die Fenstergröße auszuhandeln.

Sie können die TCP-Empfangsfenstergröße und die RFC 1323-Fensterskalierungsoptionen auf einem Computer, der Windows Server 2003 ausführt, optimieren, indem Sie zwei Registrierungseinträge ändern: TCPWindowSize und TCP1323Opts. Weitere Informationen zu diesen Features finden Sie im Microsoft Knowledge Base-Artikel 224829 Beschreibung von TCP-Eigenschaften in Windows 2000 und Windows Server 2003.

Empfohlen wird die Verwendung von Version 13 oder höher des Speicheranforderungsrechners für die Exchange 2007-Serverfunktion Mailbox, um die optimalen Einstellungen für diese Registrierungseinträge auf Grundlage Ihrer Netzwerkverbindung und -latenz zu ermitteln. Der Rechner steht im Exchange-Teamblog zum Download bereit. Der Speicherrechner enthält außerdem schrittweise Anleitungen zum Eingeben der Registrierungswerte auf Ihren Servern.

ARP-Cacheablauf

Der ARP-Cache ist eine arbeitsspeicherinterne Tabelle, in der IP-Adressen zu MAC-Adressen (Media Access Control) zugeordnet werden. Auf Einträge im ARP-Cache wird immer referenziert, wenn ein ausgehendes Paket an die IP-Adresse in dem jeweiligen Eintrag gesendet wird. Windows Server 2003 passt die Größe des ARP-Caches standardmäßig automatisch an die Anforderungen des Systems an. Wenn ein Eintrag zwei Minuten lang von keinem ausgehenden Datagramm verwendet wird, wird dieser Eintrag aus dem ARP-Cache entfernt. Einträge, auf die referenziert wird, werden nach zehn Minuten aus dem ARP-Cache entfernt. Manuell hinzugefügte Einträge werden nicht automatisch aus dem Cache entfernt.

Interne Tests der internen IT-Abteilung von Microsoft haben gezeigt, dass es mit Standardablaufeinstellungen für den ARP-Cache in CCR- und SCR-Umgebungen zu Paketverlusten kam. Bei auftretenden Paketverlusten muss der sendende Server die verlorenen Daten erneut übermitteln. In einer Umgebung mit fortlaufender Replikation ist es wichtig, dass die Protokolldateien so schnell wie möglich auf den passiven Knoten kopiert werden. Daher kann es sich negativ auf den Durchsatz des Protokollversands auswirken, wenn Daten wegen verlorener Pakete wiederholt übermittelt werden müssen.

Um den ARP-Cacheablauf zu steuern, können Sie den TCP/IP-Parameter ArpCacheMinReferencedLife in der Windows-Registrierung ändern. Dieser Parameter bestimmt, wie lange referenzierte Einträge in der ARP-Cachetabelle verbleiben müssen, bevor sie gelöscht werden können. Intern hat Microsoft herausgefunden, dass sich als optimale Einstellung für den Registrierungswert ArpCacheMinReferencedLife derselbe Wert eignet, wie er von den im Netzwerk befindlichen Routern für den ARP-Cacheablauf verwendet wird; dieser betrug im Test 4 Stunden.

Bevor Sie aber den Wert von ArpCacheMinReferencedLife in Ihrer eigenen Umgebung ändern, empfiehlt es sich, mithilfe von Microsoft Netzwerkmonitor oder einem ähnlichen Erfassungstool den Netzwerkverkehr an der Netzwerkschnittstelle, über die Protokolle vom aktiven auf den passiven Knoten kopiert werden, zu erfassen und zu analysieren. Ausführliche Anleitungen zum Ändern des Registrierungswerts ArpCacheMinReferencedLife finden Sie unter Appendix A: TCP/IP Configuration Parameters (englischsprachig).

Erweiterte TCP/IP-Features für SNP (Scalable Networking Pack)

Das Windows Server 2003 Scalable Networking Pack (SNP) ist ein gesondertes Update für Windows Server 2003, das zustandsbehaftete und zustandslose Abladungen enthält, um den Windows-Netzwerkstack zu beschleunigen. Das Update umfasst TCP Chimney-Abladung, RSS (Receive Side Scaling) und NetDMA (Network Direct Memory Access).

"TCP Chimney" ist eine zustandsbehaftete Abladung. TCP Chimney-Abladung ermöglicht das Abladen der TCP/IP-Verarbeitung auf Netzwerkadapter, die die TCP/IP-Verarbeitung hardwareseitig durchführen können.

RSS und NetDMA sind zustandslose Abladungen. Bei einem einzelnen Computer mit mehreren Prozessoren (CPUs) begrenzt der Windows-Netzwerkstack die eingehende Protokollverarbeitung auf einen einzigen Prozessor. RSS löst dieses Problem dadurch, dass die von einem Netzwerkadapter empfangenen Pakete ausgleichend über mehrere Prozessoren verteilt werden können. NetDMA ermöglicht ein DMA-Modul (Direct Memory Access) auf dem PCI-Bus (Peripheral Component Interconnect). Der TCP/IP-Stack kann dann mithilfe des DMA-Moduls Daten kopieren, statt den Prozessor unterbrechen zu müssen, um den Kopiervorgang verarbeiten zu können. Eine verwandte Komponente, TCPA, ist eine weitere Abladungsfunktion, bei der ein DMA-Hardwaremodul auf dem PCI-Bus eingesetzt werden kann, um die Verarbeitung eingehender Pakete zu unterstützen.

In einigen Umgebungen können diese Features zwar Vorteile bei der Netzwerkleistung bewirken, doch gibt es Szenarien, in denen sie nicht einsetzbar sind, weil andere Technologien zur Anwendung kommen. Beispielsweise können TCP Chimney-Abladung und NetDMA nicht verwendet werden, wenn eine der folgenden Technologien eingesetzt wird:

• Windows-Firewall

• IPsec (Internet Protocol Security)

• Internet Protocol Network Address Translation (IPNAT)

• Firewalls von Drittanbietern

• NDIS 5.1-Zwischentreiber

Darüber hinaus gibt es in einigen Umgebungen bekannte Probleme, einschließlich Umgebungen mit Microsoft Exchange, aufgrund derer die Netzwerkleistung abnehmen kann, wenn diese Features eingesetzt werden. Ausführliche Informationen zu einigen dieser Probleme finden Sie im Exchange-Teamblogbeitrag Windows 2003 Scalable Networking Pack (SNP) und mögliche Auswirkungen auf Exchange (in englischer Sprache).

Es wird empfohlen, in CCR-Umgebungen, die unter dem Betriebssystem Windows Server 2003 ausgeführt werden, sämtliche dieser Features sowohl für das Betriebssystem als auch für alle Netzwerkschnittstellenkarten im System zu deaktivieren. Die Features lassen sich wie folgt deaktivieren:

• Öffnen Sie zum Deaktivieren des Features "TCP Chimney-Abladung" eine Eingabeaufforderung, und führen Sie folgenden Befehl aus: Netsh int ip set chimney DISABLED

• Zum Deaktivieren der anderen SNP-Features können Sie die Werte für die TCP/IP-Registrierungsparameter EnableRSS und EnableTCPA in der Windows-Registrierung auf "0" festlegen. Ausführliche Anleitungen zur Vorgehensweise hierzu finden Sie im Microsoft Knowledge Base-Artikel 936594 Nachdem Sie Windows Server 2003 SP2 oder das Scalable Networking Pack auf einem Computer mit Windows Server 2003 installiert haben, können netzwerkbezogene Probleme auftreten.

• Informationen zum Deaktivieren dieser Features für die Netzwerkschnittstellenkarten im System finden Sie in den Anleitungen, die der jeweiligen Netzwerkschnittstellenkarte beiliegen, oder Sie erhalten Sie beim Hersteller der Hardware.

Weitere Informationen zum SNP finden Sie im Knowledge Base-Artikel 912222 Die Microsoft Windows Server 2003 Scalable Networking Pack Version, sowie auf der Website Skalierbare Netzwerke (in englischer Sprache).

Verhalten von Outlook nach einem Failover des Postfachclusterservers in einem Failovercluster mit mehreren Subnetzen

Wenn ein Verschiebevorgang oder Failover für einen Postfachclusterserver auftritt, der in einem geografisch verteilten Failovercluster mit mehreren Subnetzen bereitgestellt wird, wird der Name des Postfachclusterservers beibehalten. Die diesem Namen zugewiesene IP-Adresse wird jedoch nicht beibehalten. Die Verfügbarkeit dieses Servers für Clients und andere Server ist abhängig von der Übermittlung der neuen IP-Adresse über DNS. Es kann einige Zeit in Anspruch nehmen, bist die DNS-Propagierung durchgeführt wird. Aus diesem Grund sollten Sie den TTL-Wert (Time to Live) des DNS-Hosteintrags für den Postfachclusterserver auf 5 Minuten (300 Sekunden) festlegen. Ausführliche Anleitungen zum Konfigurieren des DNS-TTL-Werts für den Postfachclusterserver finden Sie unter Konfigurieren von DNS TTL-Werten für Netzwerknamenressourcen. Nachdem Sie den DNS-TTL-Wert für den Postfachclusterserver festgelegt haben, müssen Sie den Postfachclusterserver beenden und dann erneut starten, damit die Änderungen wirksam werden.

Obwohl interne Microsoft Office Outlook-Clients keine neuen oder neu konfigurierten Profile für die Verbindung mit der neuen IP-Adresse benötigen, muss zuvor ihr lokaler DNS-Cache gelöscht werden, damit die Namensauflösung des Postfachclusterserver-Namens von der alten IP-Adresse zur neuen IP-Adresse verschoben wird. Nachdem die IP-Adresse an die entsprechenden DNS-Server weitergegeben wurde, kann der DNS-Cache auf den Outlook-Clients mithilfe des folgenden Befehls über eine Eingabeaufforderung auf dem Client gelöscht werden:

ipconfig /flushdns

In den folgenden Abschnitten wird das Verhalten von Outlook in verschiedenen Konfigurationen illustriert.

Verteilte fortlaufende Clusterreplikation (CCR) unter Windows Server 2003 (ein Subnetz)

In dieser Konfiguration gibt es eine Netzwerknamenressource und eine IP-Adressenressource, von der die Netzwerknamenressource abhängig ist. Im DNS ist der Netzwerkname der IP-Adresse zugeordnet. Alle Ressourcen, einschließlich der IP-Adressenressource, können zwischen den beiden Knoten im Cluster verschoben werden. Aus Sicht von Outlook kommt es zu keiner Änderung der IP-Adresse, weil bei einem Failover als einzige Netzwerkänderung die Zuordnung der IP-Adresse zur MAC-Adresse des Computers erfolgt, die für Clients transparent ist.

Verteilte fortlaufende Clusterreplikation (CCR) unter Windows Server 2008 (zwei Subnetze, IPv4 vorausgesetzt)

In dieser Konfiguration gibt es eine Netzwerknamenressource und zwei IP-Adressenressourcen, von denen die Netzwerknamenressource in Form einer logischen "ODER"-Beziehung abhängig ist. Im DNS ist der Netzwerkname der aktuellen Online-IP-Adresse zugeordnet. Während eines Failovers aktualisiert der Clusterdienst beim Onlineschalten der Netzwerknamenressource den DNS-Eintrag für den Netzwerknamen mit der zweiten IP-Adresse, die zu dem anderen Subnetz gehört. Die Aktualisierung des Eintrags muss im DNS propagiert werden. Aus Sicht von Outlook ist kein neues oder neu konfiguriertes Profil für Outlook erforderlich, aber es muss darauf warten, dass der lokale DNS-Cache geleert wird, damit der Netzwerkname in die andere IP-Adresse aufgelöst werden kann. Dies kann manuell auf dem Client ausgeführt werden, indem folgender Befehl ausgeführt wird:

IPConfig /flushdns

Lokale fortlaufende Clusterreplikation (CCR) mit Standbyreplikation (SCR) in einem Remotestandort (eins oder zwei Subnetze)

In dieser Konfiguration gibt es eine Netzwerknamenressource und eine IP-Adressenressource, von der der Netzwerkname abhängig ist. Alle Ressourcen, einschließlich der IP-Adresse, können zwischen den beiden Knoten des Clusters verschoben werden. Bei einem Standortfailover, in dessen Verlauf das SCR-Ziel durch Ausführen von "Setup.com /recoverCMS" aktiviert wird, wird der Postfachclusterserver in einen anderen Standort/Cluster verschoben. Bei Ausführung dieses Befehls geben Sie die IP-Adresse an, die dem Netzwerknamen im Remotestandort zugeordnet werden soll. Die Netzwerknamen- und IP-Adressenressource werden von Setup erstellt, und der Clusterdienst aktualisiert das DNS mit der neuen IP-Adresse. Die DNS-Aktualisierung muss im DNS propagiert werden. Aus Sicht von Outlook ist kein neues oder neu konfiguriertes Profil für Outlook erforderlich, aber es muss darauf warten, dass der lokale DNS-Cache geleert wird, damit der Netzwerkname in die andere IP-Adresse aufgelöst werden kann. Dies kann manuell auf dem Client ausgeführt werden, indem folgender Befehl ausgeführt wird:

IPConfig /flushdns

Anforderungen an den Speicher für die fortlaufende Clusterreplikation

CCR ist so ausgelegt, dass in einem Cluster unter Windows kein freigegebener Speicher mehr benötigt wird. Die Verwendung von freigegebenem Speicher war bei früheren Versionen von Exchange eine Voraussetzung. Die einzige Speicheranforderung für CCR sind ausreichende Leistungsfähigkeit und Kapazität des von Windows unterstützten Speichers.

Die fortlaufende Clusterreplikation stellt keine zusätzlichen E/A-Anforderungen an den von Speichergruppen und Datenbanken belegten Speicher. Beim Entwurf Ihrer CCR-Speicherlösung wird empfohlen, folgende bewährte Methoden anzuwenden:

• Der Speicherort der Speichergruppen und Datenbanken muss auf allen Clusterknoten identisch sein.

• Speichern Sie die Datenbankdateien und Transaktionsprotokolldateien auf unterschiedlichen logischen Gerätenummern (Logical Unit Number, LUN).

• Verwenden Sie Bereitstellungspunkte für NTFS-Dateisystemvolumes, um die Volumes dem Betriebssystem verfügbar zu machen.

• Verwenden Sie sprechende Namen, die sich direkt und offensichtlich der enthaltenen Speichergruppe oder Datenbank zuordnen lassen. Bei Verwendung verschiedener Volumes für Protokolle und Datenbanken sollten die Pfade den Typ von Daten angeben. Auf diese Weise können bei wachsender Anzahl von Datenbanken und Speichergruppen Fehler durch menschliches Versagen vermieden werden. Bei der Standardinstallation werden die Speichergruppe und die Datenbanken am Installationsspeicherort von Exchange 2007 erstellt.

  Hinweis

  Exchange 2007 unterstützt nicht das Speichern von Transaktionsprotokollen oder Datenbankdateien im Stamm eines Volumes.

Eine CCR-Umgebung erfordert Speicher, der angemessene Leistungen und Kapazitäten bereitstellt. Auf beiden Knoten sollte ein entsprechender Speicher für die Leistung und Kapazität des Systems unter Verwendung desselben Speicherorts (Laufwerkbuchstabe und Pfade) für jede Speichergruppe und Datenbank konfiguriert werden.

Datenbankgröße und fortlaufende Clusterreplikation

Die erste Verteidigungsmaßnahme bei schwerwiegenden Speicherfehlern oder einer physikalischen Beschädigung der Datenbank mit CCR ist es, die Wiederherstellung mit der passiven Kopie der Daten und nicht mit der Datensicherung durchzuführen. Dadurch ist es weitaus weniger entscheidend, kurze Wiederherstellungszeitziele zu erreichen, die auf der Wiederherstellung aus dem Archiv oder von Band basieren. Anstatt von Band wiederherzustellen, aktivieren Sie die passive Kopie einer Datenbank, woraufhin die Daten den Clients nach Minuten und nicht erst Stunden wieder zur Verfügung stehen. In diesem Sinne kann CCR als schneller Wiederherstellungsmechanismus betrachtet und in dieselbe Kategorie eingeordnet werden, wie hardwarebasierte Snapshots und Klone, die mithilfe des Volumeschattenkopie-Diensts in Exchange Server 2003 erstellt wurden.

Es ist nicht ungewöhnlich, dass ein Administrator Offlinedatenbankoperationen durchführt, z. B. als Reparaturmaßnahme aufgrund von fehlerhaften Sicherungen (beispielsweise durch beschädigte Bänder oder Wiederherstellungsfehler). Mit CCR wird dieses Szenario vermieden und das Risiko ist wesentlich geringer, dass eine Datenbank repariert werden muss. Obwohl sich der Prozentsatz der Situationen, in denen eine Reparatur erforderlich ist, drastisch verringern sollte, wird es sicherlich weiterhin Situationen geben, in denen diese erforderlich ist. Vergewissern Sie sich, dass Sie Ihre Toleranz für die im schlimmsten Fall mögliche Ausfallzeit berücksichtigen, wenn Sie die Datenbankgröße festlegen.

CCR ermöglicht es Ihnen, längere Onlinewartungsfenster zu verwenden. Da CCR es Ihnen ermöglicht, eine Sicherung aus der passiven Kopie einer Speichergruppe zu erstellen, können Sie Ihr Onlinewartungsfenster auf dem aktiven Clusterknoten ausdehnen. In vielen Fällen können Sie das Onlinewartungsfenster verdoppeln, wodurch es Ihnen wiederum ermöglicht wird, größere Postfächer und Datenbanken vorzuhalten.

Ein weiteres Feature von Exchange 2007, die Ausfallsicherung bei verlorenen Protokollen (Lost Log Resiliency, LLR), verringert das Vorkommen von Datenbankinkonsistenzen aufgrund verlorener Protokolle erheblich. Der häufigste Grund für ein Datenbankreparatur durch den Administrator besteht im Allgemeinen in der Notwendigkeit, diese in einen konsistenten Zustand zu versetzen, wenn erforderliche Protokolle verschwunden oder beschädigt sind und dadurch das Bereitstellen der Datenbank verhindert wird. LLR bietet eine Ausfallsicherung für viele dieser Szenarien mit verschwundenen und beschädigten Protokollen, wodurch eine Datenbank ohne Reparatur bereitgestellt werden kann. Weitere Informationen zu LLR finden Sie unter Flexibilität der verlorenen Protokolle und Aktivität des Transaktionsprotokolls in Exchange 2007.

An diesem Punkt mag es erscheinen, als ob es Ihnen die fortlaufende Replikation ermöglicht, Ihre Datenbanken ohne Risiko zu einer beliebigen Größe anwachsen zu lassen. Dies ist jedoch nicht der Fall. Eine Onlinewartung, die in einem vertretbaren Zeitraum pro Datenbank abgeschlossen werden kann, ist weiterhin eine Einschränkung für die Datenbankgröße. Bei CCR ist die Möglichkeit, ein erneutes Seeding für Datenbanken durchführen zu müssen, ebenfalls eine Einschränkung. CCR bietet eine Datenbankredundanz, daher kann die Wiederherstellung schnell durch Aktivieren der passiven Kopie einer Datenbank erreicht werden, wenn die aktive Kopie einer Datenbank verschwunden oder beschädigt ist. CCR ermöglicht die automatische Aktivierung über den als Failover bekannten Prozess.

Nach dem Auftreten eines Failovers ist nur noch eine Kopie der Datenbank vorhanden, die neue aktive Kopie. Da die passive Kopie nicht länger vorhanden ist, kann die Ausfallsicherung der Datenbank beeinträchtigt werden. Sie sollten jedoch weiterhin über Ihre Datensicherung verfügen. Damit die Ausfallsicherung wieder aktiviert wird, muss die verlorene oder beschädigte Datenbank entfernt und eine neue passive Kopie der Datenbank erstellt werden, für die das erneute Seeding von der aktiven Kopie erfolgen muss. In Abhängigkeit von der Größe der Datenbank kann dies lange dauern. Der schlimmste Fall ist der Verlust oder die Beschädigung aller aktiven Kopien, in dem für alle passiven Kopien das erneute Seeding erfolgen muss. Dieses Szenario ist einer der Gründe, warum Gigabit-Ethernet für CCR-Umgebungen empfohlen wird.

In einer CCR-Umgebung sollten Sie folgende Werte über Gigabit-Ethernet erwarten können, wenn keine Engpässe durch Datenträger oder Prozessoren auftreten:

• Erneutes Seeding für einzelne Datenbank: Ungefähr 25 MB/s

• Erneutes (paralleles) Seeding für mehrere Datenbanken: Ungefähr 100 MB/s (eingeschränkt durch Netzwerkbandbreite)

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.

Anforderungen an Active Directory für die fortlaufende Clusterreplikation

Die Anforderungen der CCR an die Active Directory-Infrastruktur sind mit denen eines eigenständigen Servers identisch, bis auf ein paar zusätzliche Anforderungen. Bei einer Lösung mit mehreren Rechenzentren müssen beide Rechenzentren über ausreichende Active Directory-Infrastrukturunterstützung verfügen, weil jedes der beiden Rechenzentren jederzeit den Postfachclusterserver enthalten kann. Diese Kapazität muss selbst dann vorhanden sein, wenn die anderen Rechenzentren nicht verfügbar sind. Zusätzlich müssen alle Knoten im Cluster Mitglied derselben Domäne sein, und das Clusterdienstkonto muss über ausreichende Berechtigungen verfügen.

Dienstkontoanforderungen an die fortlaufende Clusterreplikation

Wenn Sie CCR unter Windows Server 2008 installieren, wird das Clusterdienstkonto unter dem Konto LocalSystem (SYSTEM) ausgeführt.

Wenn Sie CCR unter Windows Server 2003 installieren, müssen Sie für das Clusterdienstkonto ein Domänenkonto verwenden. Alle Knoten im Cluster müssen Mitglied derselben Domäne sein und dasselbe Clusterdienstkonto verwenden. Das Clusterdienstkonto muss zudem auf jedem Knoten Mitglied der Gruppe der lokalen Administratoren sein, der in der Lage ist, als Host für einen Postfachclusterserver zu dienen.

Das Clusterdienstkonto ist für das Erstellen und Warten des Computerkontos zuständig, das durch die Netzwerknamenressource des Failoverclusters identifiziert und dieser zugeordnet wird, wenn die Ressource online zur Verfügung gestellt wird. Informationen zum Sicherstellen, dass das Clusterdienstkonto über die erforderlichen Berechtigungen verfügt, finden Sie im Knowledge Base-Artikel 307532 Problembehandlung für das Clusterdienstkonto von Computerobjekten. Weitere Informationen hierzu enthält der Knowledge Base-Artikel 251335 Domänenbenutzer können Workstation oder Server nicht zu einer Domäne hinzufügen.

Fortlaufende Clusterreplikation und Öffentliche Ordner-Datenbanken

Fortlaufende Clusterreplikation und Replikation Öffentlicher Ordner sind zwei sehr verschiedene Formen von Replikation, die in Exchange eingebaut sind. Aufgrund der Interoperabilitätsbeschränkungen zwischen der fortlaufenden Replikation und der Replikation Öffentlicher Ordner ist die Replikation Öffentlicher Ordner aktiviert, wenn mehrere Postfachserver in der Exchange-Organisation über eine Öffentliche Ordner-Datenbank verfügen, und Öffentliche Ordner-Datenbanken sollten nicht in Umgebungen mit fortlaufender Replikation gehostet werden.

Die folgenden Konfigurationen werden für die Verwendung von Öffentlichen Ordner-Datenbanken und fortlaufender Clusterreplikation in Ihrer Exchange-Organisation empfohlen:

• Wenn Sie in Ihrer Exchange-Organisation einen einzelnen Postfachserver verwenden, der als Postfachclusterserver in einer CCR-Umgebung genutzt wird, kann der Postfachserver als Host für eine Öffentliche Ordner-Datenbank dienen. Bei dieser Konfiguration gibt es nur eine Öffentliche Ordner-Datenbank in der Exchange-Organisation. Deshalb ist die Replikation Öffentlicher Ordner deaktiviert. In diesem Szenario wird die Redundanz der Öffentlichen Ordner-Datenbank durch Einsatz der CCR erzielt. Bei CCR werden zwei Kopien Ihrer Öffentlichen Ordner-Datenbank gepflegt.

• Wenn Sie mehrere Postfachserver haben, können Sie eine Öffentliche Ordner-Datenbank in einer CCR-Umgebung unter der Voraussetzung hosten, dass in der gesamten Exchange-Organisation nur eine einzige Öffentliche Ordner-Datenbank vorhanden ist. In diesem Szenario wird die Redundanz der Öffentlichen Ordner-Datenbank ebenfalls durch CCR erzielt. Bei dieser Konfiguration gibt es nur eine Öffentliche Ordner-Datenbank in der Exchange-Organisation. Deshalb ist die Replikation Öffentlicher Ordner deaktiviert.

• Wenn Sie Daten aus Öffentlichen Ordnern in eine Umgebung mit fortlaufender Clusterreplikation migrieren, können Sie die Replikation Öffentlicher Ordner verwenden, um die Inhalte einer Öffentliche Ordner-Datenbank von einem eigenständigen Postfachserver oder einem Postfachclusterserver in einer Einzelkopieumgebung auf einen Postfachclusterserver in einer Umgebung mit fortlaufender Clusterreplikation zu verschieben. Wenn Sie die Öffentliche Ordner-Datenbank in einer Umgebung mit fortlaufender Clusterreplikation erstellen, sollten die zusätzlichen Öffentlicher Ordner-Datenbanken nur vorhanden sein, bis Ihre Öffentlichen Ordner-Daten vollständig in die Umgebung mit fortlaufender Clusterreplikation repliziert wurden. Wenn die Replikation erfolgreich abgeschlossen wurde, sollten alle Öffentliche Ordner-Datenbanken außerhalb der Umgebung mit fortlaufender Clusterreplikation entfernt werden, und Sie sollten keine weiteren Öffentliche Ordner-Datenbanken in der Exchange-Organisation bereitstellen.

• Wenn Sie Daten aus Öffentlichen Ordnern aus einer Umgebung mit fortlaufender Clusterreplikation migrieren, können Sie die Replikation Öffentlicher Ordner verwenden, um die Inhalte einer Öffentliche Ordner-Datenbank von einem Postfachserver in einer Umgebung mit fortlaufender Clusterreplikation auf einen eigenständigen Postfachserver oder einen Postfachclusterserver in einer Einzelkopieumgebung zu verschieben. Nach dem Erstellen der zusätzlichen Öffentliche Ordner-Datenbank außerhalb der Umgebung mit fortlaufender Clusterreplikation sollte die Öffentliche Ordner-Datenbank in der CCR-Umgebung nur vorhanden sein, bis die Daten aus Öffentlichen Ordnern vollständig in die zusätzlichen Öffentlicher Ordner-Datenbanken repliziert wurden. Wenn die Replikation erfolgreich abgeschlossen wurde, sollten alle Öffentlicher Ordner-Datenbanken innerhalb aller Umgebungen mit fortlaufender Clusterreplikation entfernt werden, und nachfolgende Öffentlicher Ordner-Datenbanken sollten nicht in Speichergruppen bereitgestellt werden, die für fortlaufende Replikation aktiviert sind.

Während aller Zeiträume, in denen mehr als eine Öffentliche Ordner-Datenbank in der Exchange-Organisation vorhanden ist und mindestens eine Öffentliche Ordner-Datenbank in einer Umgebung mit fortlaufender Clusterreplikation bereitgestellt ist (wie in den zuvor beschriebenen Migrationsszenarien), sollten die Unterschiede im Verhalten zwischen geplanten (verlustfreien) und ungeplanten (verlustbehafteten) Ausfällen berücksichtigt werden:

• Bei einem erfolgreichen geplanten verlustfreien Ausfall ist die Öffentliche Ordner-Datenbank online, und die Replikation Öffentlicher Ordner sollte erwartungsgemäß fortgeführt werden.

• Bei einem nicht geplanten Ausfall wird die Öffentliche Ordner-Datenbank erst bereitgestellt, wenn der Originalserver verfügbar ist und alle Protokolle für die Speichergruppe, in der sich die Öffentliche Ordner-Datenbank befindet, zur Verfügung stehen. Bei ausfallbedingtem Datenverlust darf die fortlaufende Clusterreplikation keine Öffentliche Ordner-Datenbank bereitstellen, wenn die Replikation Öffentlicher Ordner aktiviert ist. In diesem Fall muss der Originalknoten online bereitgestellt werden, um Datenverlust zu vermeiden, oder die Öffentliche Ordner-Datenbank muss erneut auf dem Postfachclusterserver in der CCR-Umgebung erstellt und ihre Inhalte mithilfe der Replikation Öffentlicher Ordner aus Öffentlichen Ordner-Datenbanken wiederhergestellt werden, die sich außerhalb der CCR-Umgebung befinden.

Sicherung und Wiederherstellung und fortlaufende Clusterreplikation

Exchange-abhängige Sicherungen werden für Produktions- und Kopiespeichergruppen und -datenbanken mithilfe der VSS-Technologie unterstützt. Streamingsicherungen werden nur vom aktiven Knoten unterstützt.

Exchange-abhängige Wiederherstellungen der aktiven Kopie können mithilfe von Streamingsicherungslösungen oder Sicherungslösungen des Volumeschattenkopie-Diensts ausgeführt werden. Exchange-abhängige Wiederherstellungen werden für die passive Kopie nicht unterstützt.

Nach der Wiederherstellung einer Datenbank aus einer Sicherung in einer Speichergruppe in einer CCR-Umgebung müssen Sie die fortlaufende Replikation für die Speichergruppe mithilfe der Cmdlets Suspend-StorageGroupCopy bzw. Resume-StorageGroupCopy anhalten und wieder fortsetzen. Dieser Prozess ist erforderlich, um den Microsoft Exchange-Replikationsdienst mit den richtigen Protokollgenerierungsinformationen zu aktualisieren. Wenn die fortlaufende Replikation nicht angehalten und wieder fortgesetzt wird, verfügt der Microsoft Exchange-Replikationsdienst über veraltete Protokollgenerierungsinformationen und beendet die Replikation von Protokolldateien.

Onlinewartung in Exchange 2007 SP1 – Erstellung von Datenbankprüfsummen und unwiderrufliches Löschen von Datenbankseiten

Durch das Erstellen von Prüfsummen wird die Integrität der Datenbank überprüft. Beim Löschen von Seiten werden Datenbanken am Ende einer Streamingsicherung unwiderruflich gelöscht. Exchange 2007 RTM versieht eine gesamte Datenbank mit Prüfsummen, wenn eine vollständige Onlinestreamingsicherung einer Datenbank durchgeführt wird. Wie zuvor erwähnt, können Streamingsicherungen in einer Umgebung mit fortlaufender Replikation nur anhand der aktiven Kopie einer Datenbank durchgeführt werden. Sie können für eine passive Kopie einer Datenbank keine Streamingsicherung durchführen. VSS kann auch dazu verwendet werden, vollständige Snapshots oder vollständige Klone einer passiven Kopie zu erstellen, wobei vollständige Snapshots und Klone ebenfalls mit Prüfsummen versehen werden können. Aber normalerweise kann in einer Umgebung mit fortlaufender Replikation nur eine der Datenbankkopien (entweder die aktive oder die passive) ohne Administratoreingriff und Ausfallzeit mit Prüfsummen versehen werden. Grund:

• Es ist beschwerlich, Streamingsicherungen einer aktiven Kopie der Datenbank und auch VSS-Sicherungen der passiven Kopie derselben Datenbank zu erstellen.

• Obwohl VSS sowohl für aktive und passive Datenbankkopien verwendet werden kann, entspricht diese Vorgehensweise nicht der Empfehlung, Sicherungsvorgänge von der aktiven Kopie auf die passive Kopie zu verlagern.

• Die Ausfallsicherheit kann temporär gefährdet sein, da die manuelle Durchführung von Integritätsprüfungen mithilfe der Exchange Server-Datenbankdienstprogramme (Eseutil) die Aufhebung der fortlaufenden Replikation erfordert.

Damit das Löschen von Seiten und die Erstellung von Datenbankprüfsummen für alle Datenbankkopien ohne die zuvor beschriebenen Probleme ermöglicht wird, führt Exchange 2007 SP1 zwei neue Features ein: Onlinewartung – Erstellung von Datenbankprüfsummen und Onlinewartung – Unwiderrufliches Löschen von Datenbankseiten. Mithilfe dieser Features kann ein Administrator sowohl das im Hintergrund durchgeführte Löschen von Seiten als auch die im Hintergrund durchgeführte Erstellung von Datenbankprüfsummen aktivieren. Sie können diese Features einzeln oder zusammen aktivieren, indem Sie die Registrierungswerte auf dem Postfachserver manuell konfigurieren, der die zu durchsuchende Datenbanken enthält und dann den Microsoft Exchange-Informationsspeicherdienst neu starten. Die Registrierungswerte werden auf Microsoft Exchange-Informationsspeicherebene konfiguriert. Daher führen alle Datenbanken auf dem Postfachserver nach der Aktivierung die konfigurierte Hintergrundaktivität durch. Die verfügbaren Registrierungseinstellungen werden später in diesem Thema erläutert.

Achtung:
UNRESOLVED_TOKEN_VAL(exRegistry)

Aktivieren der Onlinewartung – Erstellung von Datenbankprüfsummen

Speicherort: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Name: Onlinewartung – Prüfsumme Geben Sie Folgendes ein: REG_DWORD Wert: 0x00000001

Aktivieren der Onlinewartung – Unwiderrufliches Löschen von Datenbankseiten

Speicherort: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Name: Löschen von Datenbankseiten während der Erstellung von Prüfsummen Typ: REG_DWORD Wert: 0x00000001

Einschränken der Onlinewartung – Erstellung von Datenbankprüfsummen

Speicherort: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Name: Drosseln von Prüfsummen Typ: REG_DWORD Wert: 0x00000000 (Millisekunden)