The Cable Guy - Juni 2006
Microsoft Windows Server 2003 - Überblick über das Scalable Networking Pack
Mit dem Microsoft Windows Server 2003 Scalable Networking Pack (engl.) können Sie die Verarbeitung von Netzwerkverkehr auf externe Hardware auslagern. Es unterstützt Sie darin, Ihre Serverperformance und den Netzwerk-Datendurchsatz für Anwendungsbereiche wie Storage, Sichern, Webhosting und Media-Streaming zu optimieren.
Auf dieser Seite
 | Einleitung |
| TCP Chimney Offload |
| Receive-side Scaling |
| NetDMA |
| Zusätzliche Informationen |
Einleitung
Die Technologien aus dem Scalable Networking Pack - TCP Chimney Offload, Receive-side Scaling und NetDMA - verbessern die Serverperformance bei der Verarbeitung von Netzwerkverkehr. Wenn sie mit kompatibler Netzwerkhardware kombiniert werden, werden die bestehenden Engpässe wie zum Beispiel die Verarbeitung von Netzwerkpaketen durch die CPU beseitigt.
Da auch bereits vorhandene Windows Server 2003-Installationen von den Vorzügen solcher Hardware profitieren können, reduziert das Scalable Networking Pack den Bedarf an neuen Servern. Für die Technologien aus dem Scalable Networking Pack sind keine Konfigurationsänderungen an bestehenden Anwendungen oder Tools zur Netzwerkverwaltung notwendig.
TCP Chimney Offload
Für die Verwaltung von TCP-Verbindungen kann ein erhebliches Maß an Aufwand notwendig werden. Dieser Aufwand entsteht zum Beispiel durch:
| • | Das Parsen von Feldern im TCP-Header (Überprüfen von TCP-Checksumme und Verarbeiten von Sequence- und Acknowledgementnummern, TCP-flags und Quell- und Zielport). |
| • | Erstellen und Senden von Acknowledgements für die empfangenen Daten. |
| • | Segmentierung der zu sendenden Daten. |
| • | Kopieren von Daten zwischen dem Speicherbereich des Empfangsfensters, des Sendefensters und der Anwendungen. |
| • | Verwalten von Timern für TCP-Retransmission. |
Indem dieser Aufwand auf dedizierte Hardware verlagert wird, kann die CPU des Servers für andere Aufgaben eingesetzt werden. TCP/IP unterstützt unter Windows Server 2003 bereits das Auslagern von TCP-Checksummenbereichnungen und TCP-Segmentierung an entsprechende Netzwerkadapter. TCP Chimney Offload bietet eine Möglichkeit, die gesamte TCP-Verarbeitung an entsprechende Hardware mit TOE (TCP Offload Engine) auszulagern.
Statt einzelne Aufgaben auszulagern, kümmern sich TOE-fähige Netzwerkadapter um die meisten Attribute einer Verbindung (zum Beispiel die IP-Adresse, die TCP-Ports und die Sequenznummern). Auf diese Art ist der Netzwerkadapter in der Lage den gesamten TCP-Netzwerkverkehr zu bearbeiten, ohne die CPU belasten zu müssen. Am meisten profitieren Sie von diesem Verfahren bei langfristigen TCP-Verbindungen (zum Beispiel bei der Sicherung von Dateien oder Multimeda-Streams).
TCP Chimney Offload - Design
TCP Chimney Offload ist mit dem Windows Server 2003 TCP/IP-Stack integriert und erfordert keine Änderungen an Anwendungen.
Independent Hardware Vendors (IHVs), die TOE-fähige Netzwerkadapter herstellen möchten, stellt TCP Chimney Offload eine High-Level-Geräteschnittstelle für NDIS (Network Driver Interface Specification) Miniport-Treiber zur Verfügung, die eine Vielzahl von Implementierungsansätzen unterstützt.
TCP Chimney Offload stellt den IHVs außerdem diverse Intermediate-Treiberlösungen zur Verfügung (zum Beispiel das "Verbinden" von mehreren Netzwerkadaptern zu einem virtuellen Adapter für eine bessere Ausfallsicherheit oder zum Load Balancing) und unterstützt mehrere Virtual LANs. IHVs mit TCP Chimney Offload-fähigen Adaptern müssen ihre Intermediate-Treiber auf NDIS 5.2 und TCP Chimney Offload aktualisieren.
Damit TCP Chimney Offload sich nicht negativ auf aktuelle und zukünftige Microsoft Windows-Netzwerkstacks auswirkt, wird TCP Chimney Offload nicht aktiv, wenn der Netzwerkadapter eine bestimmte Funktion nicht unterstützt (zum Beispiel IPsec).
In der folgenden Abbildung sehen Sie die Architektur und die Arbeitsabläufe von TCP Chimney Offload.
| • | Anwendungen: Anwendungen nutzen entweder den TCP/IP-Stack (Tcpip.sys) oder über TCP Chimney den TOE-fähigen Netzwerkadapter. |
| • | Switch: Steuert, ob der Datentransfer über Tcpip.sys oder den TOE-fähigen Netzwerkadapter stattfindet. |
| • | TCP Chimney: Logischer Kanal, über den der Status verändert oder überwacht (durch Tcpip.sys) und Daten ausgetauscht werden. |
| • | State Update-Schnittstellen: Schnittstellen, über die Protokolle aus Tcpip.sys den Status von TCP-Verbindungen abfragen oder konfigurieren können. |
| • | Data Transfer-Schnittstellen: Schnittstellen, mit denen Switch und TCP Chimney Daten austauschen können. |
| • | NDIS-Miniport-Treiber: NDIS-Treiber für TOS-fähige Netzwerkadapter. |
Weitere Informationen finden Sie im Whitepaper Scalable Networking: Network Protocol Offload - Introducing TCP Chimney (engl.).
Receive-side Scaling
Aufgrund der Architektur von NDIS 5.1-Miniport-Treibern ist ein Netzwerkadapter in Multiprozessor-Computern unter Windows Server 2003 immer einem einzelnen Prozessor zugewiesen. NDIS 5.1 erlaubt einen DPC (Deferred Procedure Call) für jeden Netzwerkadapter. Ein oder mehrere Pakete, die über einen Netzwerkadapter empfangen werden, lösen einen Interrupt des Host-Prozessors aus und führen möglicherweise zur Ausführung eines DPC auf einem der Systemprozessoren - typischerweise auf dem Prozessor, für den der Interrupt ausgelöst wurde. Der Netzwerkstack verarbeitet alle empfangenen Pakete im Kontext dieses DPC.
Für viele Szenarien, wie zum Beispiel die Übertragung von großen Dateien, bedeutet dies, dass relativ viel Aufwand im Kontext des DPC erforderlich ist. In diesen Szenarien führt das Fehlen einer Multiprozessorunterstützung in NDIS 5.1 zu einer eingeschränkten Skalierbarkeit. Außerdem routen aktuelle Intel Pentium 4- und IA64-Systeme alle Interrupts von einem einzelnen Gerät an einen bestimmten Prozessor - was ebenfalls zu einer eingeschränkten Skalierbarkeit führt.
Der einzelne Prozessor muss den gesamten vom Adapter empfangenen Netzwerkverkehr verarbeiten - auch dann, wenn andere Prozessoren verfügbar wären. Dies führt dazu, dass bei Servern mit hohem Volumen (zum Beispiel Webserver) die Menge an eingehendem Netzwerkverkehr, der verarbeitet werden kann, auch bei Mehrprozessorsystemen eingeschränkt ist. Wenn der Prozessor, der dem Netzwerkadapter zugewiesen ist, den eingehenden Netzwerkverkehr nicht schnell genug verarbeiten kann, weist der Netzwerkadapter diesen zurück.
Mit dem Scalable Networking Pack wird ein Netzwerkadapter nicht einem einzelnen Netzwerkprozessor zugewiesen. Stattdessen wird die Verarbeitung des eingehenden Netzwerkverkehrs auf alle Prozessoren verteilt. Dieses neue Feature wird Receive-side Scaling genannt. NDIS 5.2 und Receive-side Scaling ermöglichen mehrere DPCs auf verschiedenen Prozessoren für jeden Netzwerkadapter und gleichzeitigem Erhalten der Reihenfolge der Nachrichten pro Stream.
Um die beste Performance durch die parallele Verarbeitung von Paketen zu erreichen, ist es wichtig, deren Reihenfolge zu erhalten. Wenn Pakete für eine Gruppe von Verbindungen auf verschiedenen CPUs verarbeitet werden, kann es sein, dass ältere Pakete zuerst verarbeitet werden. Da TCP jedoch für die Verarbeitung in der Paketreihenfolge optimiert ist, würde dessen Leistung durch eine andere Verarbeitung sinken.
Receive-side Scaling stellt die Verarbeitung in der richtigen Reihenfolge sicher, indem es dafür sorgt, dass Pakete einer TCP-Verbindung nur von einem Prozessor verarbeitet werden. Dieses Feature erfordert jedoch, dass der Netzwerkadapter den TCP-Header überprüft und mit einer Hashfunktion eine Signatur für das Paket erstellt. Der Hash wird dann als Index in einer Tabelle verwendet. Die Tabelle enthält Informationen zur CPU, auf der der entsprechende DPC ausgeführt wird. Der Host-Protokollstack kann die Inhalte der Tabelle zu jeder Zeit ändern, und der TCP/IP-Stack kann ein dynamisches Balancing der Auslastung der einzelnen CPUs durchführen.
Mit Receive-side Scaling kann ein Multiprozessorsystem nun mehr eingehenden Netzwerkverkehr verarbeiten. Um das Features nutzen zu können, müssen Sie jedoch kompatible Netzwerkadapter installieren.
Das Scalable Networking Pack überwacht die Netzwerkadapter und stellt fest, ob diese Receive-side Scaling-fähig sind. Wenn ein Adapter Receive-side Scaling unterstützt, nutzt das Scalable Networking Pack dieses für alle TCP-Verbindungen.
Weitere Informationen finden Sie im Artikel Scalable Networking with RSS (engl.)
NetDMA
Das Windows Server 2003 Scalable Networking Pack stellt außerdem NetDMA zur Verfügung. NetDMA verteilt die Auslastung durch die Verarbeitung von Speicher-zu-Speicher-Datentransfers auf Servern mit NetDMA-Architektur (zum Beispiel die Intel I/O Acceleration Technologie - engl.). NetDMA minimiert den Aufwand für eine CPU beim Verschieben von Daten zwischen Speicherpuffern.
Ohne NetDMA und entsprechende Hardware muss sich die CPU exklusiv mit dem Verschieben beschäftigen. NetDMA befreit die CPU von diesem Aufwand, die so für andere Aufgaben frei wird. Wird Hardware erkannt, die NetDMA und TCP Chimney Offload unterstützt, dann wird NetDMA aktiviert und TCP Chimney Offload deaktiviert.
Zusätzliche Informationen
Weitere Informationen zum Windows Server 2003 Scalable Networking Pack finden Sie unter:
| • | |
| • | Microsoft Windows Server 2003 Scalable Networking Pack (engl.) |
| • | Einführung zum Windows Server 2003 Scalable Networking Pack (engl.) |