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.

Um allgemeine Informationen zur Hardwareplanung erhalten, lesen Sie Planen von Prozessor- und Speicherkonfigurationen 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.
    

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.

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.
  

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

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

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.

Hinweis:
Der Inhalt jedes Blogs und die zugehörige URL kann ohne vorherige Ankündigung geändert werden. Der Inhalt jedes Blogs wird "WIE BESEHEN" ohne Gewährleistungen bereitgestellt und überträgt keine Rechte. Die Verwendung der enthaltenen Skriptbeispiele bzw. des enthaltenen Codes unterliegt den in den Microsoft – Nutzungsbedingungen (englischsprachig) angegebenen Bedingungen.

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).

Hinweis:
Der Inhalt jedes Blogs und die zugehörige URL kann ohne vorherige Ankündigung geändert werden. Der Inhalt jedes Blogs wird "WIE BESEHEN" ohne Gewährleistungen bereitgestellt und überträgt keine Rechte. Die Verwendung der enthaltenen Skriptbeispiele bzw. des enthaltenen Codes unterliegt den in den Microsoft – Nutzungsbedingungen (englischsprachig) angegebenen Bedingungen.

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).

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)

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

IPConfig /flushdns

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

IPConfig /flushdns

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 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.

Hinweis:
Bei Postfachservern in einem geografisch verteilten Cluster ist es erforderlich, einen einzelnen Active Directory-Standort zwischen den Datacentern auszudehnen, da alle Knoten im Cluster Mitglieder desselben Standorts sein müssen. Es ist jedoch nicht erforderlich, dass andere Server der beiden Datacentern sich im gleichen Subnetz oder am gleichen Active Directory-Standort befinden.

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 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.
  

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.

Hinweis:

Eine häufig auszuführende Aufgabe bei Exchange-abhängigen Sicherungen ist das Abschneiden der Transaktionsprotokolldateien nach dem erfolgreichen Abschluss der Sicherung. Die Replikationsfunktion in CCR stellt sicher, dass die Protokolle, die nicht repliziert wurden, gelöscht werden. Dieses Verhalten führt dazu, dass das Ausführen von Sicherungen in einem Modus, in dem Protokolle gelöscht werden, nicht tatsächlich Speicherplatz freigibt, wenn die Replikation mit dem Protokollkopiervorgang genügend im Rückstand ist.

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.

Hinweis:
Bevor Sie eine Wiederherstellung durchführen, sollten Sie alle Speichergruppen- und Datenbankdateien aus der passiven Speichergruppenkopie entfernen.

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:
Eine fehlerhafte Bearbeitung der Registrierung kann zu schwerwiegenden Problemen führen, die eine Neuinstallation des Betriebssystems erforderlich machen kann. Durch fehlerhafte Bearbeitung der Registrierung verursachte Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie alle wichtigen Daten, bevor Sie die Registrierung bearbeiten.

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)