Planen der fortlaufenden Standbyreplikation

  • Artikel

 

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

Letztes Änderungsdatum des Themas: 2008-09-11

Zwar ähnelt die Bereitstellung der fortlaufenden Standbyreplikation (Standby Continuous Replication, SCR) der Bereitstellung der fortlaufenden lokalen Replikation (LCR), doch müssen einige wichtige Unterschiede berücksichtigt werden. Es gibt allgemeine Anforderungen, die für SCR erfüllt sein müssen.

Allgemeine Anforderungen für die fortlaufende Standbyreplikation

Bevor Sie Speichergruppen für SCR aktivieren, wird empfohlen, dass Sie sich mit den folgenden Anforderungen für SCR-Quellen und -Ziele vertraut machen:

  • Eine Quelle kann über mehrere Ziele verfügen. Eine Quelle kann z. B. ein Ziel besitzen, das in demselben Datacenter wie die Quelle vorhanden ist sowie ein zweites Ziel, das in einem separaten Datacenter enthalten ist. Es gibt keine Einschränkung hinsichtlich der Anzahl der Ziele, die eine Quelle besitzen kann. Es wird jedoch empfohlen, pro Quelle nicht mehr als vier Ziele zu verwenden. Die zusätzlichen Auswirkungen auf den Quellserver müssen überprüft und entsprechend berücksichtigt werden, wenn mehr als vier Ziele konfiguriert werden.

  • Jedes Ziel kann mehrere Quellserver besitzen. Sowohl Quell- als auch Zielsystem müssen Exchange 2007 SP1 ausführen. Als Betriebssystem kann jedes von Exchange 2007 SP1 unterstützte Betriebssystem verwendet werden (z. B. Windows Server 2008 oder Windows Server 2003); jedoch muss auf allen SCR-Zielcomputern das gleiche Betriebssystem ausgeführt werden wie auf ihrem SCR-Quellcomputer. Die Verwendung verschiedener Betriebssysteme für eine SCR-Quelle und ihre Ziele (z. B. in dem Fall, dass die SCR-Quelle Windows Server 2003 und das SCR-Ziel Windows Server 2008 oder umgekehrt ist) wird nicht unterstützt.

  • Auf dem SCR-Zielcomputer muss die Exchange 2007 SP1-Serverfunktion Mailbox installiert sein. Wenn der SCR-Zielcomputer ein Clusterknoten ist, muss es sich dabei um einen passiven Knoten handeln (auf dem z. B. die Serverfunktion Passive ClusteredMailbox installiert ist), und der Cluster darf keine Postfachclusterserver enthalten.

  • Sie müssen die Exchange-Serverinstallationspfade bei der Verwendung von SCR sorgfältiger planen, wenn Sie vorhaben, einen Standbycluster und die Wiederherstellungsfunktion für Postfachclusterserver (Setup /RecoverCMS) als Teil der Aktivierungsvorgangs für das SCR-Ziel zu verwenden. Damit Sie denselben Vorgang für die Serverwiederherstellung verwenden können, muss der Installationspfad für Exchange Server für den SCR-Quellcomputer und den SCR-Zielcomputer gleich sein. Wenn Exchange Server auf dem SCR-Quellcomputer im Verzeichnis %ProgramFiles%\Microsoft\Exchange Server installiert ist, muss er auf allen Computern, die als SCR-Ziele für den SCR-Quellserver dienen, ebenfalls im Verzeichnis %ProgramFiles%\Microsoft\Exchange Server installiert sein. Wenn diese Installationspfade nicht übereinstimmen, schlägt Setup /RecoverCMS fehl, da der Installationspfad in der Registrierung nicht mit dem Wert für das Attribut msExchInstallPath des Postfachserverobjekts im Active Directory-Verzeichnisdienst übereinstimmt.

  • Wenn Sie im Rahmen des Aktivierungsprozesses einen Postfachclusterserver wiederherstellen, müssen Sie SCR für alle Speichergruppen auf dem Postfachclusterserver deaktivieren, bevor Sie als Bestandteil des Aktivierungsprozesses Setup /RecoverCMS verwenden. Wenn SCR nicht für alle Speichergruppen deaktiviert wird, kommt es zu einem Fehler bei Setup /RecoverCMS.

  • Die Speichergruppen- und Datenbankpfade auf der SCR-Quelle sowie alle Ziele dürfen nicht mit anderen Speichergruppen- oder Datenbankpfaden in Konflikt stehen. Ferner müssen Sie bei der Verwendung von SCR Ihre Speichergruppen- und Datenbankpfade sorgfältiger planen, weil die von einer SCR-Quelle verwendeten Speichergruppen- und Datenbankpfade für die Kopie der Speichergruppe und Datenbank auf allen SCR-Zielen dieser Quelle verwendet werden.

  • Die SCR-Quell- und SCR-Zielcomputer müssen sich in derselben Active Directory-Domäne befinden, wobei sie sich aber sowohl an denselben als auch an unterschiedlichen Active Directory-Standorten befinden können.

  • Jeder Zielcomputer unterstützt maximal 50 SCR-Ziele (50 replizierte Speichergruppen), wenn die Enterprise Edition von Exchange 2007 verwendet wird. Bei Verwendung der Standard Edition von Exchange 2007 werden maximal 5 SCR-Ziele unterstützt.

Einschränkungen für SCR-Zielcomputer

Wenn ein passiver Knoten oder ein eigenständiger Postfachserver als SCR-Ziel konfiguriert ist, sind folgende Funktionen gesperrt:

  • Für einen eigenständigen Postfachserver, der als SCR-Ziel ausgewiesen ist, kann für keine Speichergruppe LCR aktiviert sein. Der Microsoft Exchange-Replikationsdienst wurde nicht für das Verwalten der lokalen Clusterreplikation und der Replikation von einer anderen Quelle entworfen oder dahingehend modifiziert.

  • Ein als SCR-Ziel ausgewiesener passiver Knoten muss ein Mitglied eines Failoverclusters ein, der über keine Postfachclusterserver verfügt. Dies wird als Standbycluster bezeichnet. Weitere Informationen zu Standbyclustern finden Sie unter Hochverfügbarkeit.

SCR und Öffentliche Ordner-Datenbanken

SCR 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 SCR gehostet werden.

Hinweis

Da Datenbankportierbarkeit nur auf Postfachdatenbanken anwendbar ist, kann die Aktivierung für eine SCR-Zielkopie einer Öffentliche Ordner-Datenbank nur im Rahmen eines Wiederherstellungsvorgangs für einen Server oder Postfachclusterserver erfolgen (z. B. Setup /m:recoverServer oder Setup /recoverCMS).

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

  • Wenn Sie über einen einzelnen Postfachserver in Ihrer Exchange-Organisation verfügen und es sich bei diesem Postfachserver um einen eigenständigen Postfachserver oder einen Postfachclusterserver in einer Einzelkopiecluster-Umgebung handelt, kann der Postfachserver eine Öffentliche Ordner-Datenbank ausführen, und die Speichergruppe, die die Öffentliche Ordner-Datenbank enthält, kann für SCR aktiviert sein, vorausgesetzt, die Speichergruppe ist nicht für lokale Clusterreplikation aktiviert. 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 SCR erzielt. Bei SCR werden zwei Kopien Ihrer Öffentlichen Ordner-Datenbank gepflegt.

  • Wenn Sie über mehrere Postfachserver verfügen und nur einer der Postfachserver eine Öffentliche Ordner-Datenbank enthält und es sich bei dem betreffenden Postfachserver um einen eigenständigen Postfachserver oder um einem Postfachclusterserver in einer SCC handelt, kann der Postfachserver eine Öffentliche Ordner-Datenbank ausführen, und die Speichergruppe, die die Öffentliche Ordner-Datenbank enthält, kann für SCR aktiviert sein, vorausgesetzt, die Speichergruppe ist nicht für lokale Clusterreplikation aktiviert. 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 ebenfalls durch SCR erzielt.

  • Wenn Sie Daten aus Öffentlichen Ordnern in eine Speichergruppe migrieren, die für SCR aktiviert ist, 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 SCC in die SCR-aktivierte Speichergruppe zu verschieben. Wenn die Replikation erfolgreich abgeschlossen wurde, sollten alle Öffentliche Ordner-Datenbanken außerhalb der SCR-aktivierten Speichergruppen entfernt werden, und Sie sollten keine weiteren Öffentliche Ordner-Datenbanken in der Exchange-Organisation bereitstellen.

  • Wenn Sie Daten aus Öffentlichen Ordnern aus einer Speichergruppe migrieren, die für SCR aktiviert ist, können Sie die Replikation Öffentlicher Ordner verwenden, um die Inhalte einer Öffentliche Ordner-Datenbank auf einen eigenständigen Postfachserver oder einen Postfachclusterserver in einer SCC zu verschieben. Wenn die Replikation erfolgreich abgeschlossen wurde, sollten alle Öffentliche Ordner-Datenbanken innerhalb aller SCR-aktivierten Speichergruppen entfernt werden, und keine nachfolgenden Öffentlichen Ordner-Datenbanken sollten in SCR-aktivierten Speichergruppen ausgeführt werden.

Während aller Zeiträume, in denen mehr als eine Öffentliche Ordner-Datenbank in der Exchange-Organisation vorhanden ist und eine oder mehrere Öffentliche Ordner-Datenbanken in einer für SCR aktivierten Speichergruppe ausgeführt werden, kann eine Öffentliche Ordner-SCR-Zieldatenbank, die aktiviert werden muss, bei einem Fehler der SCR-Quellspeichergruppe nur für die Bereitstellung aktiviert werden, wenn alle Protokolle der Speichergruppe, in der die Öffentliche Ordner-Datenbank ausgeführt wird, verfügbar sind. Sollten als Folge des Fehlers der SCR-Quelle Protokolle fehlen oder nicht verfügbar sein, kann die SCR-Zielkopie der Öffentliche Ordner-Datenbank nicht aktiviert werden. In diesem Fall muss die SCR-Quelle online bereitgestellt werden, um Datenverlust zu vermeiden, oder die Öffentliche Ordner-Datenbank muss erneut auf der SCR-Quelle erstellt und ihre Inhalte mithilfe der Replikation Öffentlicher Ordner aus einer anderen Öffentlichen Ordner-Datenbank als der SCR-Zielkopie wiederhergestellt werden.

SCR und Sicherungen

Eine SCR-Zielkopie kann nicht gesichert werden. LCR und CCR unterstützen Sicherungen sowohl von der aktiven als auch von der passiven Kopie. SCR unterstützt nur Sicherungen der SCR-Quelle. Die Datenbankkopfzeilen eines SCR-Ziels werden aktualisiert und die Protokolldateien abgeschnitten, wenn für die SCR-Quellspeichergruppe eine unterstützte Sicherung erstellt wird. Wenn die SCR-Quellspeichergruppe für CCR oder LCR aktiviert ist, werden die Datenbankkopfzeilen des SCR-Ziels aktualisiert und die Protokolldateien abgeschnitten, wenn für die aktiven oder passiven Kopien der SCR-Quellspeichergruppe Sicherungen erstellt werden.

SCR und Wiederherstellungen

Wenn eine SCR-Quelldatenbank durch eine frühere Version der Datenbank ersetzt wird, 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 Replikationsdienst über veraltete Protokollgenerierungsinformationen und beendet die Replikation von Protokolldateien.

SCR und Abschneiden von Protokolldateien

In Exchange 2007 RTM werden Regeln durchgesetzt, damit eine Protokolldatei in einer fortlaufenden Replikationsumgebung nicht gelöscht wird, bis diese gesichert und in der Kopie der Datenbank wiedergegeben wurde. Diese Regel wird bei Verwendung von SCR modifiziert. Die fortlaufende Standbyreplikation (die das Konzept mehrerer Datenbankkopien einführt) ermöglicht das Abschneiden von Protokolldateien bei der SCR-Quelle, sobald diese von allen SCR-Zielcomputern überprüft wurden. Beim Abschneiden von Protokollen bei der SCR-Quelle wird nicht gewartet, bis alle Protokolle in alle SCR-Ziele wiedergegeben wurden, da SCR-Zielkopien mit großen Protokollwiedergabeverzögerungen konfiguriert werden können. Das Abschneiden von Protokollen tritt auf einer SCR-Quelle aber nicht ein, wenn mindestens ein SCR-Ziel für eine Speichergruppe nicht erreichbar ist. Damit Protokolle auf einer SCR-Quelle abgeschnitten werden, müssen die SCR-Zielcomputer online sein und die Quelle muss darauf zugreifen können.

Bei einem SCR-Ziel wird alle drei Minuten ein Hintergrundthread ausgeführt, um zu ermitteln, ob Protokolldateien abgeschnitten werden müssen. Wenn die folgenden drei Kriterien erfüllt sind, wird eine Protokolldatei auf einem SCR-Ziel abgeschnitten:

  • Die Protokolldatei wurde auf der SCR-Quelle abgeschnitten.

  • Die Generierungssequenz der Protokolldatei befindet sich unterhalb des Protokolldateiprüfpunkts für die Speichergruppe.

  • Die Protokolldatei ist älter als ReplayLagTime + TruncationLagTime. (Eine Beschreibung dieser Parameter finden Sie im Thema Fortlaufende Standbyreplikation unter "Cmdlet-Aktualisierungen für SCR").

In einer mit SCR erweiterten LCR- oder CCR-Umgebung wird eine Protokolldatei für die aktiven und passiven Kopien in der LCR- oder CCR-Umgebung abgeschnitten, wenn die folgenden drei Kriterien erfüllt sind:

  • Die Protokolldatei wurde gesichert.

  • Die Generierungssequenz der Protokolldatei befindet sich unterhalb des Protokolldateiprüfpunkts für die Speichergruppe.

  • Alle SCR-Ziele haben die Protokolldatei überprüft.

Optimieren von Windows 2003-Netzwerken für SCR

Zwar sind für die Verwendung von SCR in Windows Server 2008 keine Netzwerkoptimierungen erforderlich, bei der Verwendung von SCR in Windows Server 2003 ist es jedoch empfehlenswert, die Windows Server-TCP/IP-Einstellungen für die Geschwindigkeit und Latenz des tatsächlich verwendeten Netzwerklinks zu optimieren. Insbesondere kann es erforderlich sein, die TCP-Empfangsfenstergröße (Transmission Control Protocol) sowie die RFC 1323-Fensterskalierungsoptionen (Request for Comments) auf einem SCR-Quellcomputer und seinen SCR-Zielcomputern 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 SCR-Umgebung zu konfigurieren. Entweder die SCR-Quelle mit allen SCR-Zielen sollte IPsec verwenden oder weder die SCR-Quelle noch die Ziele. 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 zu optimieren, damit der Durchsatz während des Protokollversands erhöht wird.

Zum Optimieren des TCP-Durchsatzes sollte der sendende Computer ausreichend Pakete übertragen, um die Netzwerkleitung zwischen dem Sender und dem Empfänger zu füllen. Die Kapazität der Netzwerkleitung basiert auf ihrer Bandbreite und ihrer Latenz (Roundtrip-Wartezeit). Je höher die Latenz, desto mehr Kapazität haben Sie, da der Zeitraum zum Senden von Daten zwischen Bestätigungen länger ist. Durch Erhöhen der TCP-Fenstergröße kann das System die Zeitspanne zwischen zwei Bestätigungen zum Senden von Daten nutzen.

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 der Verwendung von Fensterskalierung können Hosts in einer Konversation eine Fenstergröße aushandeln, die das Ausstehen mehrerer großer Pakete, z. B. von der Art, wie sie häufig in Dateiübertragungsprotokollen verwendet werden, im Puffer des Empfängers erlaubt. In RFC 1323 ist ausführlich ein Verfahren zum Unterstützen größerer Empfangsfenster durch das Zulassen der TCP-Aushandlung eines Skalierungsfaktors für die Fenstergröße beim Einrichten der Verbindung beschrieben.

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 kann im Exchange-Teamblog unter Speicheranforderungsrechners für die Exchange 2007-Serverfunktion "Mailbox" (nur in Englisch) heruntergeladen werden. Der Speicherrechner enthält außerdem schrittweise Anleitungen zum Eingeben der Registrierungswerte auf Ihren Servern.

Hinweis

UNRESOLVED_TOKEN_VAL(exBlog)

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 schrittweise Anweisungen zum Ändern des Registrierungswerts ArpCacheMinReferencedLife finden Sie in Anhang A: TCP/IP-Konfigurationsparameter.

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 die Verwendung eines DMA-Moduls (Direct Memory Access) auf einem PCI-Bus (Peripheral Component Interconnect). Der TCP/IP-Stapel kann zum Kopieren von Daten das DMA-Modul verwenden, statt einen Interrupt an die CPU zu senden, damit sie den Kopiervorgang ausführt. 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

UNRESOLVED_TOKEN_VAL(exBlog)

Es wird empfohlen, in SCR-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:

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