Abgabetermin:

I.
7 März 2011
Stoyan Varlyakov | Motivation
1
t
Inhalt
I.
Motivation ............................................................................................................................................. 4
II.
Problemübersicht .................................................................................................................................. 6
A.
Anpassungen in der Hardwareebene ................................................................................................ 8
B.
Anpassungen der Protokollebene (OSI3+) ........................................................................................ 9
C.
Prefetching ...................................................................................................................................... 12
D.
Per-Packet Overhead (als der schwierigsten Operation) ................................................................ 14
E.
SMP Overheads ............................................................................................................................... 16
F.
Virtualization Overheads ................................................................................................................. 17
G.
Zusammenfassung TCP Overhead ................................................................................................... 20
H.
Netzwerkbonding als Lösung des Flashenhalsproblems: ................................................................ 21
III.
Theoretische Lösung........................................................................................................................ 27
A.
Syntetische Tests: ............................................................................................................................ 27
B.
Echte Dateitransferaufgaben: ......................................................................................................... 29
C.
Receive Aggregation ........................................................................................................................ 30
D.
Acknowledgment Offload................................................................................................................ 37
IV.
Praktische Lösung (Beweis) ............................................................................................................. 40
A.
Testverfahrenerklärung ................................................................................................................... 40
B.
Teste ................................................................................................................................................ 40
V.
Resultaten in Ausgangssituation ......................................................................................................... 43
A.
Schritt1 ............................................................................................................................................ 44
B.
Schritt 2 ........................................................................................................................................... 46
C.
Schritt 3 ........................................................................................................................................... 48
D.
Validierung der Resultate in Linux................................................................................................... 49
VI.
2
Analyse der Pakete per Wireshark .................................................................................................. 51
Motivation | Stoyan Varlyakov
7 März 2011
A.
Ausgangssituation ........................................................................................................................... 51
A.
Schritt1 – nur Offloading ................................................................................................................. 52
B.
Schritt 2 und 3 – MTU = 16386 mit und ohne Offloading ............................................................... 52
C.
Sicherheit der implementierte Lösungen – Der UDP Test .............................................................. 53
VII.
Zusammenfassung ........................................................................................................................... 55
A.
Windows Resultate der Verbesserung: ........................................................................................... 55
B.
CPU Auslastung in der gegebenen Tests: ........................................................................................ 56
C.
Resultate in der Linux Implementierung ......................................................................................... 56
7 März 2011
Stoyan Varlyakov | Motivation
3
I.
Motivation
Es sind schon mehr als 20 Jahren seit den ersten größeren Netzwerken entstanden. Für dieses
Periode hat sich der Netzwerkwelt mehrmals verändert. Da sich der Kundenzentrirung der
Lösungen einen größeren Schwiergrad bekommt mit jeden nächsten Tag, werden immer
größere Anforderungen an der Netzwerkumgebung präsentiert. Somit wachst der Komplexität
der Umgebungen und die Anforderungen an sichere, schnelle und fehlertolerantes
Netwerkumgebung sind immer höher.
Heutzutage HD Video direkt vom Netz zu sehen, oder immer mehr virtualiserte Anwendungen
zu verwenden, die physikalisch und geographisch weit entfernt sind ist ganz normal. Auch die
Interaktive Inhalt, 3D und weitere datendurchsatzfristige Anwendungen sind immer häufiger
gewünscht von Endkunden und das im Endeffekt bringt weitere Anforderungen an der
Netzwerkebene, die dahinter das ganze ermöglicht.
Auf der Serverniveau, mit den immer mehr verwendeten Virtualisiernungslösungen von
verschiedenen Anbieter (Microsoft, VMWare, Citrix, Novell...) der endbenutzerorientierte
Netzwerke wachsen weiterhin an Anforderungen.
Das bringt der Typischen Problem „Ich will alles haben und doch sofort“. Die
Netzwerklösungsanbieter reagieren sehr schnell auf diesen Marktanforderungen, um
Einkommen Erniedrigungen zu vermeiden. Aber die Recherche in der Richtung von radikalen
Veränderungen ist leider nicht so schnell und alle Lösungen verbleiben einen Firmengeheimnis.
Letzter Zeit ist einen Tendenz sehr stark entwickelt – kostenoptimierte Lösungen, die aber sehr
gute Sicherheit und Fehlertoleranz anbieten und aufgrund der niedrigen Kosten lassen sich sehr
leicht in Faktoren multiplizieren.
Ein sehr guter Beispiel für diese aus der Festplattenlösung ist der RAID Arrays (Redundant Array
of Inexpensive Disks). Auf ähnlichen Arbeitsart- und weise hat sich die Netzwerkumgebung stark
modifiziert und der IEEE Standard 802.3 für Ethernetverbindungen gewinnt immer mehr und
mehr Marktanteil und alle Forschungen in der Richtung werden eigentlich immer von der
Marktanfrage betrieben.
4
Motivation | Stoyan Varlyakov
7 März 2011
Was passiert aber mit der gesamten Protokollumgebung die schon 20 Jahre alt ist? Eigentlich
nicht viel. Alle dazugehörigen Lösungen für die immer steigenden Anforderungen sind fast
immer Betriebssystemabhängig oder Hardwarelösungsanbieter abhängig.
Der IETF hat mehrere RFCs in der Richtung aufgemacht aber keinen bringen klare Lösungen und
das ursprüngliche Design verbleibt unverändert. Aber alle Nachteile, die früher aufgrund der
niedrigen Durchsatzanforderung nicht sichtbar/wichtig waren, sind momentan einen
Flaschenhalslimitierung der gesamten Struktur.
Auch schnellere Leitungen wie Infiniband und 10Ge bringen keine wirkliche Verbesserung der
Situation aufgrund der veralteten Protokolle, die verwendet werden und die
Flaschenhalsproblem an der CPU Leistung.
Um die Lösungseinsatz für den Netzwerkumgebung immer schwieriger zu machen, gibt es
immer der Anforderung für Kompatibilität. Oft Protokolle, die aus Serversicht angepasst werden
können, bringen Probleme für Klienten, die verschiedenen Anforderungen an dasselbe Protokoll
verwenden.
Deshalb soll man immer einen Teaming (Netzwerkbonding) Lösung mit Anwendungsansicht im
Vordergrund implementieren. Und genau diesen Ausgangspunkt werde ich in der folgenden
Diplomarbeit forschen und die meist verwendete Szenarien als Case Study in Detail erforschen.
Viel Spaß beim Lesen!
7 März 2011
Stoyan Varlyakov | Motivation
5
II.
Problemübersicht
Hochleistungnetzwerke sind heutzutage immer häufiger eine Voraussetzung für den normalen
Betrieb. Die Streben nach hochverfügbaren Hochleistungssystemen bringt sehr hohe
Anforderung an der Transportsschicht. Das Problem ist, dass die grundlegende Protokolle für
den Datenaustausch sind schon veraltet und einen neueren Methode für Anpassung gibt es
leider nicht.
Auch die Gesellschaft ist in verschiedene Richtungen verteilt – Protokollanpassung auf eine
höhere Niveau der OSI Tabelle oder eine Hardwaregebundene Anpassung mit der riesigen Last.
Schlussendlich die Aspekte des Problems sind mehrere und man muss immer den Flaschenhals
suchen, um das gesamte Durchsatz zu verbessern. Einen kurzen Anblick in einen
Systemarchitektur zeigt gleich, warum Overhead und Performance eine größere Thema sind:
Typisches RDMA Access auf Netzwerkebene verglichen mit DMA auf dem lokalen Knoten
6
Problemübersicht | Stoyan Varlyakov
7 März 2011
Mit der hellgrünen Linie wird ein direkter Datenaufruf aus der Festplatte dargestellt.
In dem zweiten Szenario (mit der roten Linie) wird einen Aufruf von einen iSCSI Target
dargestellt. Dann sieht man, dass die Daten mehrmals umgewandelt werden und im Endeffekt
ist der Prozessor wesentlich mehr belastet.
Der zweite Aspekt des gegebenen Szenarios ist die Situation, wenn eine Anwendung nicht
netzwerkfähig ist. Dann emuliert das Betriebssystem lokale Festplatenverhalten. Das aber
verursacht im Endeffekt wesentlich höhere Netzwerkauslastung aufgrund des
Flaschenhalsproblems auf Netzwerkebene. Schematisch dargestellt, sieht die Verbindung auf
Netzwerkebene so aus:
Physikalischer Schicht Darstellung, verglichen zu der (OSI) Referenzmodell[4]
7 März 2011
Stoyan Varlyakov | Problemübersicht
7
Um das Flaschenhalsproblem zu kämpfen haben wir mehrere Optionen.
A.
Anpassungen in der Hardwareebene
1.
Hardwarespezifische Losungen
Diese Lösungen sind keinen echten Fortschritt, da eine Lösung in dieser Form hat
nur wirtschaftlichen Sinn. Die erste Schritte in Verbessern der Netzwerkdurchsatz
sind immer von Großhersteller und sind eigene Standarte und Lösungen. Die
Erfahrungen in der Richtung, aber verbleiben Eigentum der Hersteller und sind
keine Thema in dieser Diplomarbeit
2.
Durchsatzoptimierung
Manchmal wir die Optimierung einer Lösung verpasst. Aber es ist äußerst
wichtig, weil wir bis zum 50 % der Leistung nicht verwenden konnten, aufgrund
weniger Zeit für Optimierung der Lösung. Bei der Durchsatzoptimierung wird das
ganze Netzwerk betrachtet und durch Netzwerkdumps analysiert, damit die
reelle Auswirkung der Lösung analysiert wird. Oft werden Design- oder
Implementierungsprobleme nur mit dieses Verfahren entdeckt, die am Anfang
wegen der niedrigen Last versteckt verbleiben.
3.
“Brute force” Verfahren
Durch Bruteforce Verfahren ermöglicht immer schnellere, breitere usw.
Verbindungen. Das ist aber technisch schwer möglich, da die Anforderungen an
der Umgebung werden immer Höher mit dem Erhöhung der Taktfrequenz auf
Hardwareebene und reines Bruteforce passt leider in den reellen Welt nicht, da
die unkontrollierte Erhöhung der Frequenz setzt immer hohe Anforderungen an
der Netwerkumgebung und die Realisierung wird schon zu schwierig sein. Ein
perfektes Beispiel in dieser Richtung ist die CX4 Kabelanforderung für 10 Gb
Netzwerke – anstatt 100m auf Cat5e Kabel, kann man 10 GbEthernet nur bis zum
10 Meters betreiben mit derselben Kabelgröße 24AWG.
4.
Anpassungen in der Transportsicht

8
OSI Layer 1+2 Anpassungen – Ethernetstandarterweiterungen
Problemübersicht | Stoyan Varlyakov
7 März 2011
Es wäre möglich Optimierung auf OSI Layer 1+2 zu realisieren. Aber in
meinem Diplomarbeit wurde ich eher in Richtung Transportoptimierung
in Netzwerkprotokoll eingrenzen und diese Aufgabe verbleibt für den
nächsten Jahrgang.
B.
Anpassungen der Protokollebene (OSI3+)

Anpassungen der Inhalt der Pakete, anstatt der Transportmedium
Es wäre optimal wenn man die Anwendungen für ein bestimmtes Protokoll
anpasst – bspw. Wenn man in lokales Netz einen riesigen Fail transportiert, kann
er der unsicheren aber sehr schnelle UDP verwenden mit einen sehr hohen MTU
(bspw. 65000) anstatt der sichere aber nicht-so-schnelle TCP. Dann braucht man
aber einen Algorithmus für Bestätigung der Transferierte Dateien im Anwendung
selber, der schneller als der TCP Protokoll funktioniert…

Die Protokolle an den Situation anpassen anstatt die Situation an der Protokolle
Man kann das Verhalten der Protokolle anpassen für die Situation, deshalb ist
einen sicheren, schnellen, skalierbarer Protokoll erforderlich für eine optimale
Lösungseinsatz
Ich werde in diese Diplomarbeit die Implementierung „Netzwerkbonding“
weitererforschen als Hardwarelösung für Verbesserung der Durchsatz und verschiedene
Optionen bei der TCP-Protokolleinpassung für Arbeit unter stärkerer Auslastung.
Auf die physikalische Ebene sollen wir einen Netzwerkbonding-verfahren
implementieren. Dieses Methode war ursprünglich im Jahre 2000 beim 802.3ad definiert
auf eine Protokollebene, nämlich LACP, aber im Jahre 2008, als die Interesse an der
Technologie schon sichtbar war und mehrere Hardwareanbieter haben eigene Lösungen
zum Thema vorgestellt, hat sich die IEEE entschieden die Technologie auf die
Transportebene zu verschieben, deshalb wird 802.1x Standard klassifiziert.
Sollte man die Netzwerkebene als Flaschenhals betrachten, dann wäre es möglich, die
theoretische Lösung des Problems folgendermaßen grafisch darzustellen:
7 März 2011
Stoyan Varlyakov | Problemübersicht
9
Die Szenario vom Bild 1 im Bondingkonfiguration
In diese Implementierung durch „Bonding“ von 4 verschiedenen Netzwerkkarten in
einen Bond, haben wir das Flaschenhalsproblem aus Bandbreiteaspekt gelöst.
Die Realisierung von Bondingmodell auf Netzwerkebene sieht folgendermaßen so aus:
Physikalischer Schicht Darstellung mit Netzwerkbonding eingeschaltet, verglichen zu der (OSI)
Referenzmodell [3]
10
Problemübersicht | Stoyan Varlyakov
7 März 2011
Das Bonding von Netzwerkkarten war ursprünglich im 802.3ad definiert. Andere
wirtschaftliche
Bezeichnungen
sind
„Netzwerkteaming“
„Hochverfügbare
Netzwerklösung“, „Scalable Networking Pack“. Im 2006 nach der Veröffentlichen der
Dokument „IEEE 802.3 Maintenance“ hat die Entscheidung getroffen, dass LACP
(Netzwerkbonding) ist einen Sublayer von 802.3, deshalb muss man diese in 802.1ax
verschieben. Die Argumente für dieses sind mehrere, aber im großen und ganzen kann
man die Lösung LACP so betrachten, dass keine Protokollkontrolle existieren kann (oben
gezeigtes Bild) , sondern einfaches mehrkanaliges Bond auf Data Link Niveau (OSI Layer
2). Aber um mit dem Problem von „established Sessions are lost when the link which
handled the connection is dropped“ zu Lösen, implementiert man einen Protokolllösung
in der Form von LACP, die immer noch auf Niveau 3 funktioniert, deshalb betrachtet man
die Teaming als 802.1ax + 802.3ad. LACP hat aber einen Nachteil – es ist nicht gedacht,
dass LACP über mehrere Switche funktioniert. Zum Beispiel wenn man 2 Bonds von
jeweils 2 Netzwerkkarten, und dann wird das Trafik durch einer der Beiden geleitet.
Nehmen wir an, dass der Switch, denen der Trafik handelt ausfällt. Dann mussten alle
Klienten nochmals ARP lookup machen, um den anderen Team zu sehen auf den zweiten
Switch.
Dieses Problem beseitigt man, mit einem Verfahren „alle Switche als virtueller Cluster
betreiben“. Diese Lösung betrachtet jeder Switch als kleiner Baustein einen größeren
Switch. Dann wenn einen Switch ausfällt, die andere leiten alle Pakete der Topologie
entsprechend und dieser Ausfall verbleibt für den Klient nicht sichtbar.
Es verbleibt aber ein anderer Aspekt und zwar – CPU Leistung Problem. Angesehen
davon, wie viel Overhead gibt es bei jedem einzelnem Netzwerkadapter und die
Summierung der Overhead an die alle 4 Adapter plus den Overhead bezüglich der
Teaminglösung beobachten wir Ressourcenmangel. Der Grund dafür ist der etwas
kompliziertere Arbeits- Art und Weise der TCP Protokoll, die aufgrund der Grundlage für
sicheres Transport auftritt.
Um die Situation zu behandeln, können wir sämtliche Optionen der TCP Standard
modifizieren, die aber einen stärkeren Einfluss über die Sicherheit des geleiteten Pakets
hat*. Die RFC Gemeinschaft hat mehrmals erfolglos versucht einen generellen TCP
7 März 2011
Stoyan Varlyakov | Problemübersicht
11
Abladungmechanismus (TCP/IP Offloading Engine - TOE) darzustellen, der für jede
beliebige Situation fähig wäre.
*Diese Aussage wird in den praktischen Teil der Diplomarbeit bewiesen.
Leider die Resultate für solche Implementierungen sind der Ziel nicht entsprechend und
seit Jahr 2003 gibt es keinem vernünftig arbeitenden Algorithmus. Die ursprüngliche Idee
für konzentrieren der Netzwerkstack in einen klügeren Netzwerkkarte hat leider nicht
funktioniert, da es von Realisierungssicht sehr schwierig ist, das Ziel zu erreichen. Die
intelligenten NICs, die Offloading machen könnten, sind am Anfang der Implementierung
schneller als eine CPU, aber mit der Zeit (und Kosten) macht es wirklich weniger Sinn, die
Netzwerkstack offzuloaden.
Deshalb gibt es auch andere Verfahren die Netzwerkstack zu optimieren und trotzdem
Hardwareunabhängig zu verbleiben. Aravind Menon und Willy Zwaenepoel beschreiben
solchen Verfahren bei Linux-Systemen. [7]
C.
Prefetching
Einerseits muss man den Prefetching bei modernen CPUs betrachten. Prefetching
kommt als Lösung für zu schnelle CPUs, die die Unbenutzte Bandbreite zu RAM
verwenden die nächsten vermuteten Speicherblöcke in den Puffer anzulegen. Moderne
CPUs wie der Intel Nehalem (Core i7) und AMD Phenom 2 haben 3 Niveaus von Cache,
und der gesamte Größe ist bis zum 12 Mb. Diesen erweiterten Caching-Speicherplatz
ermöglicht verbessertes Data Prefetching, die zu einen höheren Leistungsverbesserung
führen.
Alle Tests sind durch den Tool OProfile gemacht und die Grafen zeigen nur die
Resultaten.
Die durchgeführte Analyse zeigt dem Overhead beim Transportieren von 1500 Byte
große Einheiten (maximaler Auslastung) auf einen Single CPU System.
12
Problemübersicht | Stoyan Varlyakov
7 März 2011
Overhead im Abhängigkeit von der Prefetching [7]
Die Konfiguration “None” verwendet kein Prefetching der TCP Stack, “Partial” verwendet
cache-line prefetching, und „Full“ verwendet cache-line prefetching und schritt-based
prefetching.
Wie zu sehen ist, der Overhead per-packet ist inversproportional zu der per-Byte
Overhead und per-Byte overhead ist inversproportional zu Prefetching.
Da Prefetching einer der meist verwendete Performance Optimierung ist, in den
weiteren Bearbeitung dieses Dokument werde ich immer die aggressivsten Einstellung
implementieren.
Weiterhin, die nächste problematische Zone bei der TCP-Optimierung ist die Architektur
des Rechners. Aravind Menon und Willy Zwaenepoel3 haben auch diese Auswirkung
getestet in 3 verschiedene Umgebungen: Uniprozessor (UP), Symmetricmultiprozessor
(SMP) und einen virtualiserte Umgebung durch Xen Kernel. Die Resultate sind in der
nächsten Grafik gezeigt:
7 März 2011
Stoyan Varlyakov | Problemübersicht
13
Auswirkung der Systemarchitektur auf der CPU basertes Overhead [7]
D.
Per-Packet Overhead (als der schwierigsten Operation)
Aus der schon dargestellte Grafik2 ist klar zu sehen, dass die Per Packet Overhead die
größte Anteil bei der schwierigen mathematische Kalkulationen hat, deshalb werde ich
mich in diese Richtung vertiefen. Am wichtigsten ist, dass wir einen klaren Unterschied
zwischen den echten Berechnungen der TCP Stack Anarbeiten machen und die
Operationen, die aus historische oder architektonische Gründen immer noch von der
CPU durchgeführt pro Packet werden, aber haben nichts mit den Empfanganarbeiten zu
tun.
Grafik 3 zeigt die Analyse der TCP Empfangabarbeiten Overhead in 5 verschiedene
Kategorien der Linux Kernel 2.6.26.34 auf 3 Ghz Xeon (Hyperpath), in Uniprocessor
Konfiguration mit voll Prefetching eingestellt. Die vertikale Achse stellt die gebrauchte
CPU Takten für jede der folgenden 5 Kategorien von Anarbeiten dar:
1. rx: TCP/IP Protokollanarbeitenroutinen in dem Empfangspfad der TCP Stack.
2. tx: TCP/IP Protokollanarbeitenroutinen in dem Sendepfad der TCP Stack für
Übermittlung von Bestätigungsquittungen (ACKs).
3. Buffer: Pufferverwaltungroutinen für Netzwerkpakete, ACKs, sk_buffs (Linux
Eigenschaft) , die Puffermetadateistruktur im Linux.
14
Problemübersicht | Stoyan Varlyakov
7 März 2011
4. non-proto: Andere Routinen, die operieren pro Packet, aber sind keiner Teil der Kern
TCP/IP Protokollanaberiten. Einige von diese sind Linux spezifisch, z.B wie Routinen
für softIRQ zum Interruptkontext Bewegung, aber andere sind eher generisch z.B.
Paketfiltrierung oder Netzwerkbrückenbehandlung im Kernel.
5. driver: Treiberspezifische Routinen, die arbeiten in Interruptmodus.
Erweiterte Overheadanalyse für Uniprozessorsysteme [7]
Die Spalte „per byte“ zeigt die Operationen pro Byte in den Empfangspfad.
Die „misc“ Routinen sind nicht relevant zum Empfangsprozessing und sind nicht strikt
definiert „pro Byte“ oder „Pro Packet“, deshalb gibt es eine separate Spalte für diesen
Overhead.
Der Overhead für „driver“ ist um 21%. Diesen Overhead ist per Paket, aber man kann
dieses Overhead ohne Hardwaredesignveränderungen nicht beeinflussen, deshalb wir
nehmen dieses Overhead als Fixwert und fokussieren uns auf die verbleibende 79% im
rx, tx, buffer und non-proto. Auch wenn wir den Treibereinfluss ausschließen, the
Overhead von den verbleibende Routinen ist 46% und diesen Wert ist in Faktor 3 großer
als der „per-byte“ Overhead mit 17%. Den Overhead der TCP/IP Protokoll Routinen
selber enthält Tx und Rx Routinen, die haben einen Anteil von ungefähr 21%. Den
größeren Anteil der Overhead ist der Pufferverwaltung und „non-proto“ mit ungefähr
25% zusammen. Erweitertes Profilierung der Pufferverwaltungsoverhead zeigt, dass die
meisten Overhead ist von sk_buffs Zyklen verursacht und nicht Speicherverwaltung
7 März 2011
Stoyan Varlyakov | Problemübersicht
15
selber. In Schlussfolgerung können wir zusammenfassen, dass die meßten
Overheadzyklen sind aufgrund Routinen, die irrelevant für die Protokollbearbeitung im
Kernel sind.
E.
SMP Overheads
Da alle moderne CPUs haben mehr als ein Kernel, werde ich auch die Overhead
vergleichen zwischen 2.6.16.34 UP Kernel und SMP Kernel auf einen 3.0 GHz Netburst
Xeon CPU. Da das Profil der Overhead sehr ähnlich ist, werde ich dieselben
Bezeichnungen verwenden, wie bei der UP System. Für ein besseres Verstehen der
Overhead von Multiprozessormaschinen und der Auswirkung der SMP auf die
verschiedene Komponente der TCP Stack, werde ich die UP Resultaten auch in den Grafik
darstellen:
Aufriss der Empfanganarbeiten in eine SMP gegen UP Umgebung [7]
Einige Schlussfolgerungen lassen sich von der Graphen ziehen:
1.
Bei der UP System ist der Overhead „pro Paket“ wesentlich höher (bei 48%)
verglichen zum „pro Bit“.
2.
Die Migration von UP zum SMP verbleibt der Overhead „pro Byte“ fast dasselbe,
aber wir beobachten wesentlich Erhöhung in einige der „Pro Paket“ Operationen.
Genauer angesehen, die Rx Routinen brauchen 62% mehr CPU Zeit und die Tx Routinen
16
Problemübersicht | Stoyan Varlyakov
7 März 2011
entsprechend 40% im Vergliech zu der UP System. Der Pufferverwaltungsoverhead
verbleibt ungefähr dasselbe.
Offen verbleibt die Frage, ob hinzufügen einen weiteren Kern wurde die Overhead
immer noch erhöhen. Leider kann ich selber kein Recherchieren in der Richtung finden.
F.
Virtualization Overheads
Ein wichtiger Schwerpunkt bei der heutige Systemen- und IT-Lösungen ist die
Virtualisierungsoverhead. Selbst der größte Hersteller von CPUs Intel hat deshalb eine
ganze Reihe von Produkte, die sind speziell an Virtualisierungslösungen optimiert.
Was heißt das auf Netzwerkebene? Schauen wir uns die Struktur von der sogenannten
Virtualisierungsmodell v. 1.0
Nichtoptimiertes Virtualisierungsmodell [14]
Dann hat Intel auf Systemebene den VT-x Instruktionen implementiert, so dass den
Hypervisor kann eine Netzwerkschnittstelle pro virtuelle Maschine zuweisen. Dann kann
die Virtuelle Maschine einen größeren Teil der Overhead aufgrund der Vitalisierung
ersparen und im Endeffekt den Bus für wichtigere Operationen befreien. So wird sogar
7 März 2011
Stoyan Varlyakov | Problemübersicht
17
die IRQs direkt an die Netzwerkkarte geleitet und die verdoppelte Handlung dasselbe
verursacht ziemlich stärkere Last auf Systeme.
Schematisch dargestellt die V2P (Virtuell to Physikalisch) Konfigurierung sieht so aus:
Physikalischer Passtrough von Netzwerkadapter in die virtuellen Maschinen [14]
Eine Lösung in dieser Form würde den Overhead bei normaler Virtualisierung ersparen.
Aravind Menon und Willy Zwaenepoel3 haben dem Overhead bei einer Xen virtualiserte
Maschine durch OProfile angemessen. Zusätzlich der schon bekannte Spalten Tx, Rx, Per
Byte, non-proto, driver und misc, gibt es bei der virtualiserte Systeme die
Overheadkategorien [7]
Netback: Die Netback Treiber initialisiert Transfers von der TCP Stack (Hostmaschine) zu
der Gasmaschine. Diese Overheadeinheiten sind meistens pro Paket und sind
proportional zu der Fragmente (Frames) die transferiert werden.
18
Problemübersicht | Stoyan Varlyakov
7 März 2011
Netfront: Die Netfront Treiber transferiert Pakete von der virtualiserte mMaschine und
transferiert diese zu der zu der Hostmaschine. Der Overhead ist zu der Netback ähnlich
und wieder proportional zu den Fragmenten, die transferiert werden.
Overheadprofill laut Oprofil [1] [7]
Die allgemeine Resultaten für “pro Paket” Overhead, generiert als Summe der
Kategorien non-proto, netback, netfront, tcp rx, tcp tx und buffer sind insgesamnt 56%
der gesamnten Overhead und sind wesentlich mehr als der „Pro Byte“ wert von 14%. Die
Ursache für diese erhöhte Overhead-Resultaten ist die verdoppelte Kopieren der Dateien
zwischen die VM und HM aufgrund der verwendete VMM 1.0 Struktur. VMM 2.0 sollte
die Situation deutlich verbessern, aber die Leistung eine physikalische Maschine ist als
Orientierungswert leider nie immer zu erreichen.
Interesanterweise non-proto, netback, netfront und buffer sind 46% des gesamten
Overheads. Für die TCP/IP Protokoll selber ist die Overheadprozenteinsatz genau 10%.
Diese Resultate weisen auf eine mögliche Verbesserung der Leistung in Faktoren nach
TCP/IP Optimierung hinauf.
7 März 2011
Stoyan Varlyakov | Problemübersicht
19
G.
Zusammenfassung TCP Overhead
Die modernen Rechnerarchitekturen sind aufgrund der Prefetchingverfahren,
implementiert in moderne CPUs, wesentlich optimiert in Richtung sequenzieller
Speicherzugriff. Bei nichtsequenziellem Zugriff, gibt es keine Möglichkeit auf CPU-Ebene
das Lese- oder Schreibvorgänge zu beschleunigen. Allerdings in den meisten
Programmen wird schon eine verbesserte Speicherstruktur verwendet, damit
Prefetchingalgorithmen die gesamte Leistung des Programms verbessern können.
Dieses Tendenz hat einen bestimmten Auswirkung auf der Netzwerkstruktur und protokolle gebracht. Früher war Dateikopierung der Flaschenhals. Jetzt aber mit den
neueren Architekturen hat sich die Flaschenhals auf die „per Packet“ Operationen
verschoben, sprich die Netzwerkstack ist momentan die langsamste Teil in der
Datenaustauschprozess. Ich habe dieses in 3 verschiedenen Netzwerkarchitekturen
bewiesen.
Als zweite Schlussfolgerung, können wir eindeutig bestimmen folgendes:
Wenn wir die gesamte Anzahl der Pakete in der TCP Empfangprozessing verkleinern,
dann würden wir die gesamte Overhead direktproportional verkleinern.
TCP/IP Anarbeiten ist die einzige nötige Overhead, die wir nicht vermeiden können, aber
in Wirklichkeit ist diese obligatorische Berechnung eine sehr sehr kleine (10-15%) Anteil
des gesamten Overheads. Die meisten Komponente der Overhead (system,
virtualisierung und SMP Skalierung) kommen auch in der „Pro Packet“ Berechnung, aber
die sollten wir irgendwie ausschließen.
Ich werde in der theoretische Lösungsteil 2 mögliche Lösungen der oben beschriebenen
Problem vorschlagen und nämlich Receive Aggregation (auch MTU Erweiterung „Jumbo
Frames“ als ähnliche Arbeitsart und -weise)und Acknowledgment Offload.
20
Problemübersicht | Stoyan Varlyakov
7 März 2011
H.
Netzwerkbonding als Lösung des Flashenhalsproblems:
Wie schon früher diskutiert, wird die Netzwerkbandbreite- und Verbindungssicherheit
ein Problem.
Da die Lösung des Problems sehr tief in der OSI Layer liegt (OSI Layer 1), war oftmals die
Lösung oftmals hardwarespezifisch und daher Herstellerspezifisch. Um dieses
Kompatibilitätsproblem zu kämpfen, haben sich die meisten Hardwareanbieter im Jahre
1997 auf einer Symposium getroffen und folgende Ideen dargestellt, bezüglich den
Bedarf von Standardisierung.
Die genauste Definition finden wir in der Präsentation von Sun Microsystems:



Kapazität der Leitung - Erhöhung der Kapazität ist durch Parallelschaltung
mehrerer Verbindungen zwischen zwei Endpunkten realisiert. [11]
Transparenz - Keine Auswirkungen auf die Protokolle und Schnittstellen
über den Stamm Endpunkte
(oder eine einfachere Formulierung: Nichts kaputt machen beim
Verbesserung)
Um dieses Problem zu lösen hat die IEEE der Standard 802.3ad formuliert. Die
ursprüngliche Idee war, einen Protokoll zu formulieren, der würde die
Hardwareabhängige Lösungen abstrahieren, ähnlich der Java virtuelle Maschine beim
Java Programmiersprache. Später aber in Jahre 2008 hat die Gesellschaft, die
Protokolldefinition auf Hardwareniveau verschoben, da es sehr „teuer“ ist die
Hardwarespezifischelösungen ins Betribessystemunabhängigelösgunen umzuwandeln.
So ist 802.1ax zum ersten Mal formuliert. Dank des Protokolls ist es möglich
verschiedene Hardwarekarten in einen Netzwerkbond zu verpacken. Auszug aus der
Anleitung der meistverwendete Servernetzwerkadapter:
Multi-Vendor-Teaming (MVT) gilt für alle Modi in Microsoft Windows.
Linux-Ethernet-Bonding (auch als Channel Bonding bekannt oder Teaming) unter Linux
Channel Bonding-Dokumentation finden Sie im Linux Kernel-Quellen finden Sie hier:
http://www.kernel.org/doc/Documentation/networking/bonding.txt [12] [13]
7 März 2011
Stoyan Varlyakov | Problemübersicht
21
Der Linux-Treiber Bindung stellt ein Verfahren zur Aggregation mehrere
Netzwerkschnittstellen in einem einzigen logischen "gebunden"-Schnittstelle. Das
Verhalten des gebundenen Schnittstellen hängt vom Modus, meist Sprechen, bieten
entweder Hot-Standby-Modi oder Load Balancing Services. Darüber hinaus kann Link
Integrität Überwachung durchgeführt werden. [13]
Da der Realisierungen der Netzwerkloadbalancing bei Windows und Linux/Unix dieselbe
Modi haben, werden wir uns nur auf der LInuxlösungen konzentriere, wo unter der
Name des Modus werde ich auch die entsprechenden Bezeichnung aus der Windows
Welt einschreiben, wieso (Win:):
1.
balance-rr or 0 (Win:keine)
Round-Robin-Politik: Versendet Pakete in der angegebenen Reihenfolge aus dem
ersten freien Sklaven (Slave) durch die letzte. Dieser Modus bietet Lastverteilung
und Fehlertoleranz.
2.
active-backup or 1(Win:)
Active-Backup-Politik: Nur ein Slave im Bond ist aktiv. Ein anderer Slave wird
aktiv, dann und nur dann, wenn der aktive Slave fehlschlägt. Die Wandelanleihe
hat eine MAC-Adresse, die von außen auf nur einem Port (Netzwerkadapter)
sichtbar ist. In Kernel Version 2.6.2 oder höher, wenn ein Failover in aktivBackup-Modus auftritt, wird Bindung eines oder mehrerer grundlose ARPs auf
dem neu aktiven Slave schon ein Problem. Eine kostenlose ARP ist für das
Verkleben Master-Schnittstelle ausgegeben und jedes VLAN-Schnittstellen
konfiguriert darüber, vorausgesetzt, dass die Schnittstelle mindestens eine IPAdresse konfiguriert wurde. Grundlose ARPs ausgestellt für VLAN-Schnittstellen
mit dem entsprechenden VLAN-ID gekennzeichnet sind. Dieser Modus bietet
Fehlertoleranz. Die erste Möglichkeit, dokumentiert unten, wirkt sich das
Verhalten dieses Modus.
3.
balance-xor or 2 (Win: SFT)
XOR-Politik: Transmit von der gewählten übertragen Hash Politik. Die StandardPolitik ist ein einfaches [(Quell-MAC-Adresse XOR mit Ziel-MAC-Adresse) Modulo
22
Problemübersicht | Stoyan Varlyakov
7 März 2011
Slave count]. Alternate, kann man über die xmit_hash_policy die unten
beschriebene Option gesteuert werden. Dieser Modus bietet Lastverteilung und
Fehlertoleranz.
4.
broadcast or 3 (Win: AFT)
Broadcast-Politik: überträgt alles auf allen Slave-Schnittstellen. Dieser Modus
bietet Fehlertoleranz.
5.
802.3ad or 4 (Win: IEEE 802.3ad + SLA/DYNAMIC)
IEEE 802.3ad Dynamische Link-Aggregation. Erstellt Aggregation Gruppen, die die
gleiche Geschwindigkeit und Duplex-Einstellungen. Nutzt alle Slaves im aktiven
Aggregator nach 802.3ad-Spezifikation.Slave Auswahl für ausgehenden
Datenverkehr wird nach der Übertragung Hash Politik, die von der
Standardeinstellung einfaches XOR Politik über die xmit_hash_policy Option,
dokumentiert unten verändert werden kann getan. Beachten Sie, dass nicht alle
Maßnahmen übertragen werden können 802.3ad, insbesondere in Bezug auf das
Paket mis-Bestellung Anforderungen von Abschnitt 43.2.4 der 802.3ad Standard.
Unterschiedliche Peer Implementierungen haben unterschiedliche Toleranzen für
die Nichteinhaltung.
Voraussetzungen:



6.
Ethtool Unterstützung in der Basis-Treiber für das Abrufen der
Geschwindigkeit und Duplex jedes Slaves.
Ein Schalter, IEEE 802.3ad Dynamische Link-Aggregation unterstützt.
Die meisten Schalter erfordert irgendeine Art von Konfiguration 802.3adModus aktivieren.
balance-tlb or 5 (Win: ALB)
Adaptive Load Balancing übertragen: Kanalbündelung, die nicht benötigt keine
speziellen Schalter zu unterstützen. Der ausgehende Verkehr wird entsprechend
der aktuellen Belastung (berechnet in Bezug auf die Geschwindigkeit) auf jeden
Slave verteilt. Eingehender Verkehr wird von der aktuellen Slave empfangen.
7 März 2011
Stoyan Varlyakov | Problemübersicht
23
Wenn der empfangende Slave ausfällt, übernimmt ein anderes Slave über die
MAC-Adresse des ausgefallenen Empfang Slave.
Voraussetzung:
Ethtool Unterstützung in der Basis-Treiber für das Abrufen der Geschwindigkeit
der einzelnen Slave.
7.
balance-alb or 6 (Win: ALB+RLB)
Adaptive Load Balancing: umfasst Balance-TLB-plus erhalten Load Balancing (RLB)
für IPv4-Datenverkehr und erfordert keine speziellen Schalter zu unterstützen.
Der Lastausgleich beim Empfangen von ARP Verhandlungen erreicht. Die Bindung
Treiber fängt die ARP-Antworten gesendet durch das lokale System auf ihrem
Weg aus und überschreibt die gefundenen Hardware-Adresse mit der
einzigartigen Hardware-Adresse von einem der Sklaven in der Bindung, so dass
verschiedene Peers verschiedenen Hardware-Adressen zu verwenden für den
Server.
Erhalte Verkehr von Verbindungen, die vom Server erstellt wird ebenfalls
ausgeglichen. Wenn das lokale System sendet eine ARP-Request die Bindung
Treiber kopiert und speichert die Peer-IP-Informationen aus dem ARP-Paket.
Wenn der ARP-Antwort aus der Peer eintrifft, wird seine Hardware-Adresse
abgerufen und die Bindung Fahrer initiiert eine ARP-Antwort auf dieses Peer
Zuordnung zu einer der Sklaven in die Bindung. Ein problematischer Ergebnis mit
ARP Verhandlung für den Ausgleich ist, dass jedes Mal, wenn eine ARPAnforderung gesendet wird es verwendet die Hardware-Adresse der Anleihe.
Daher lernen Peers die Hardware-Adresse der Anleihe und die Vereinbarkeit von
Verkehrsinformationen empfangen bricht die aktuelle Slave. Dies kann durch
Senden Updates (ARP-Antworten), um alle Peers mit ihren individuell
zugeordneten Hardware-Adresse, so dass der Verkehr verteilt behandelt wird.
Erhalte Verkehr ist auch neu verteilt, wenn ein neuer Slave, um die Bindung zu
und wenn ein inaktiver Slave ist wieder aktiviert. Der Empfangs-Last wird
sequentiell (Round Robin) in der Gruppe der höchsten Geschwindigkeit Sklaven in
der Anleihe verteilt.
24
Problemübersicht | Stoyan Varlyakov
7 März 2011
Wenn ein Link wieder angeschlossen ist oder ein neuer Slave verbindet die
Bindung der Verkehrsinformationen empfangen unter allen aktiven Slaves in der
Bindung durch die Einleitung ARP-Antworten mit dem gewählten MAC-Adresse
für jeden der Clients umverteilt. Die updelay Parameter (siehe unten) muss auf
einen Wert gleich oder größer als der Schalter die Weiterleitung Verzögerung
eingestellt werden, so dass der ARP-Antworten auf die Peers werden nicht durch
den Schalter blockiert werden gesendet.
Voraussetzungen:
1. Ethtool Unterstützung in der Basis-Treiber für das Abrufen der
Geschwindigkeit der einzelnen Slave.
2. Base Treiber-Unterstützung für die Einstellung der Hardware-Adresse eines
Gerätes, während es geöffnet ist. Das ist so, dass es immer ein Slave im Team
mit der Bindung Hardware-Adresse (die curr_active_slave), während mit
einer einzigartigen Hardware-Adresse für jeden Slave in der Bindung werden
benötigt. Wenn das fehlschlägt curr_active_slave seine Hardware-Adresse
wird mit der neuen curr_active_slave dass gewählt wurde getauscht.
Wie zu sehen ist, in einige Modi ist es nötig, dass auf man der Netzwerkswitchebene
einige Anpassungen unbedingt implementieren muss.
Für diesen Abschnitt "Switch" bezieht sich auf jedes System der Netzwerkkarten sind
direkt verbunden (dh, wo das andere Ende des Das Kabel wird). Dies kann eine
tatsächliche gewidmet Schalteinrichtung werden, oder es kann ein anderes regulären
Systems (z. B. einem anderen Computer ausgeführt werden Linux), Die aktive Backup-,
Balance-TLB-und Balance-Alb-Modi benötigen keine spezielle Konfiguration des
Switches.
Die 802.3ad-Modus erfordert, dass der Switch über die entsprechenden Häfen als
802.3ad Aggregation konfiguriert. Die genaue Methode Um dies zu konfigurieren variiert
von Switch zu Switch, sondern zum Beispiel ein Cisco 3550 Serie Switch erfordert, dass
die entsprechenden Ports zuerst zusammen in einer einzigen Instanz etherchannel
gruppiert, dann etherchannel ist auf den Modus "LACP" gesetzt, um die 802.3ad
(anstelle von Standard EtherChannel).
7 März 2011
Stoyan Varlyakov | Problemübersicht
25
Die Balance-rr, Balance-xor-und Broadcast-Modi im Allgemeinen verlangen, dass der
Switch die entsprechenden Ports zusammengefasst haben. Die Nomenklatur für eine
solche Gruppe unterscheidet zwischen Switches, kann es genannt "etherchannel" (wie in
der Cisco Beispiel oben), ein "Stamm Gruppe "oder andere ähnliche Variante. Für diese
Phasen, jeder Switch wird auch eine eigene Konfigurations-Option für die Umstellung
der Übertragung Politik auf die Bindung. Typische Entscheidungen sind XOR entweder
der MAC-oder IP-Adressen. Die Sende-Politik der beiden Peers muss nicht
übereinstimmen. Für diese drei Modi, die Bindung Modus wirklich wählt einen
übertragen Politik für eine EtherChannel Gruppe, alle drei werden interoperabel mit
einem anderen EtherChannel Gruppe.
26
Problemübersicht | Stoyan Varlyakov
7 März 2011
III.
Theoretische Lösung
Um das Problem richtig zu überprüfen, ist es nötig eine gut erarbeitete Benchmarkingverfahren
zu erarbeiten, damit wir die Korrektheit der vorgeschlagene Lösungsweg überprüfen können.
Ich habe mich in die 2 verschiedenen Betriebssystemen für die folgende Tests entschieden:
A.
Syntetische Tests:
1.
Linux – Netperf
Netperf ist um ein grundlegendes Client-Server-Modell konzipiert. Es gibt zwei
ausführbare Dateien - Netperf und NetServer. Generell sollten Sie nur dann
ausführen, die Netperf Programm, mit dem NetServer Programms durch die RemoteSystems inetd oder gleichwertige geltend gemacht wird. Wenn Sie Netperf
ausführen, ist das erste, das das passieren wird die Einrichtung einer Kontrolle
Verbindung zum entfernten System. Diese Verbindung wird verwendet, um TestKonfiguration Informationen und Ergebnisse zu und von dem Remote-System
übergeben werden. Unabhängig von der Art des Tests ausgeführt werden, wird das
Steuerelement Verbindung eine TCP-Verbindung mit BSD-Sockets werden. Die
Steuerung Verbindung können entweder IPv4 oder IPv6.
Sobald die Kontrolle Verbindung besteht und die Konfigurations-Informationen
übergeben wurde, eine separate "Daten"-Anschluss für die Messung selbst mit Hilfe
der API's und Protokolle für die angegebene Test wird geöffnet. Wenn der Test
abgeschlossen ist, wird die Datenverbindung-abgerissen werden und die Ergebnisse
der NetServer-back wird über die Steuerung Verbindung geleitet werden und in
Kombination mit Netperf das Ergebnis für die Anzeige für den Benutzer.
Netperf macht sicher, dass keine Netzwerkpakete über die Kontrollverbindung
transportiert werden, während eines Tests im Gange ist. Bestimmte TCP-Optionen
wie SO_KEEPALIVE, wenn Ihre Systeme wie voreingestellt, kann gestellt Pakete an
den Kontroll-Verbindung während eines Tests im Gange ist. Generell wird dies keine
Auswirkung auf die Ergebnisse haben.
7 März 2011
Stoyan Varlyakov | Theoretische Lösung
27
2.
Windows – Passmark 7.0 NetworkTtest
Fast alle Computer in diesen Tagen über eine Netzwerkverbindung von einigem
Typen. Ob es eine Modemverbindung zu einem ISP oder ein Ethernet-Verbindung zu
einem Intranet, das Senden und Empfangen von Daten zu und von anderen
Computern ist ein wesentlicher Bestandteil des täglichen Betrieb. Eine Vielzahl von
Anwendungen verwenden TCP / IP-Networking-Technologie - E-Mail, Webbrowser
und Spiele, ein paar populäre Anwendungen zu nennen. In den meisten Fällen gibt es
eine Performance-Kennzahl wird der Benutzer mit am stärksten betroffenen - die
Geschwindigkeit oder Übertragungsrate.
Die PassMark Advanced Network Test (das ist Teil des PerformanceTest) soll die
Datenübertragungsrate zwischen zwei Computern beide müssen ausgeführt werden
PerformanceTest testen. Einer der Computer muss als Server fungieren und sitzen
auf eine Verbindung wartet. Der andere Computer dient als Client. Es verbindet sich
mit dem Server-Rechner und sendet Daten an ihn für die Dauer des Tests.
Das Netzwerk Benchmarktest wird mit jeder Art von TCP / IP-Verbindung arbeiten.
Einschließlich Ethernet, DFÜ-Modems, ADSL, Kabelmodem, Local Area Networks
(LAN), Wide Area Networks (WAN) und drahtlose Netzwerke (WLAN). Die Software
wurde optimiert, um ein Minimum an CPU-Zeit, so dass auch High-Speed-GigabitEthernet-Verbindungen Vergleichstests werden.
Die Benutzer haben die Möglichkeit, die folgenden Test Parameter zu ändern:




28
Die IP-Adresse der Maschine als Server und die Port-Nummer für den
Test, um mit Firewall-Problemen zu helfen.
Die Größe der Daten für jede Anfrage senden verwendet blockieren. Es ist
auch möglich, um variable große Blöcke, um die Leistung Deltas als
Blockgröße erhöht oder verringert messen.
Die Dauer der Prüfung.
Das Protokoll TCP oder UDP. Das TCP-Protokoll ist, wenn die Integrität der
Daten wichtig (Fehler werden korrigiert mit Hilfe von DatenÜbertragungen) ist. UDP ist für Anwendungen, tolerant zu Datenverlust
sind wie Video-Streaming verwendet.
Theoretische Lösung | Stoyan Varlyakov
7 März 2011
B.
Echte Dateitransferaufgaben:
1.
Linux – Kopieren einer Datei von Server zu Klient auf NFS
Die Idee hinter dieser Benchmark ist, dass man mit einen Protokoll auf ein
höheres Niveau die Auswirkung der Einstellungen überprüft. Ich habe den
folgenden Testverfahren erarbeitet: Client-Server Modell, 1 Server am Anfang
ohne Verbesserungen der Netzwerkstack, dann mit verbessertes TCP
Einstellungen und dann einen Teaminglösung drauf konfiguriert auf der
Serverseite. Ich teste mit 3 verschiedenen parallelen Ausführungen der Test von
3
verschiedenen
Klienten.
Somit
kann
ich
am
besten
Flaschenhalsüberprüfungmachen. Für alle Test nehmen wir OpenSUSE 11.3 64 bit
Rechnern an.
2.
Windows – Kopieren einer binären Datei (.exe)über SMB 1.0 (Windows
2003 Server, Windows XP Clients SP3 alle 32 Bit.)
Die Idee dieser Test is ähnlich der Test beim Linux. Server ist 2003 R2 SP2 RTM
und die Klienten sind Windows XP Rechner mit SP3 drauf. Alle sind 32 Bit.
Die alle vier verschiedenen Tests sollen die Behauptungen in die theoretische
Lösung überprüfen. Ein sehr wichtiger Teil der Tests in der Windows Welt ist die
sogenannte Sicherheitstest, wo der PassMark Netzwerktest würde so
konfiguriert, dass UDP Pakete auf 1000 Mbit/sec von der Klient gesendet werden
(Simulation von VPN Trafik oder VoIP/Video Streaming).
Erstmals sollen wir die Baustein 99% alle Netzwerkverbindungen optimieren – TCP/IP.
Wie ich schon dargestellt habe, ist der Anarbeiten bei TCP Protokollberechnungen
weniger als 30% der gesamten Anarbeiten und wenn wir die Anzahl der „zu
bearbeitenden Pakete“ minimieren dann bekommen wir wesentlich weniger
Berechnungen im Endeffekt. Das können wir in 2 verschiedenen Wege schaffen – mit die
Technologie Receive Aggregation Offloading oder durch Vergrößerung der Maximal
Transfer Unit(MTU). Der Endeffekt ist immer, dass weniger Pakete werden bearbeitet
und somit gibt es wesentlich mehr freie Zyklen der CPU. Auch zu beweisen ist die
Behauptung, dass mehrere Netzwerkkarten sich ähnlich wie der Baustück verhalten –
7 März 2011
Stoyan Varlyakov | Theoretische Lösung
29
d.h. die Resultaten, die gelten für die Einzige Netzwerkkarte sind für den gesamten Bond
fähig.
Beweis finden wir in der Definition der LACP Protokoll (grundlegend für die
Netzwerkbonding), die auf OSI Layer 2 mehrere MAC Kontrolle implementiert. (siehe
Bild4) Die praktischen Tests sollen einfach einer Tendenz zeigen, wie viel skaliert die
Lösung mit jeder nächsten Schnittstelle.
C.
Receive Aggregation
1. Welche Netzwerkpackete sind aggregiert
Das Ziel der Aggregation ist Erhalte die Anzahl der Pakete, die der Netzwerk-Stack zu
verringern, hat auf dem Weg empfangen Prozess, und gewährleistet zugleich, dass
die TCP / IP-Protokoll-Verarbeitung der Datenpakete korrekt ausgeführt wird. [7]
Die Grundidee ist, dass Erhalte Aggregation, anstatt dass das Netzwerk zu
verarbeiten Pakete von der Netzwerkkarte direkt empfangen Stapel, die Pakete sind
vorverarbeitet und verschmolzen in `aggregierten" TCP-Pakete, die dann auf mit dem
Netzwerk-Stack zur weiteren Verarbeitung übergeben. Mehrere "Netzwerk" TCPPakete sind zusammengefasst in einem einzigen "Host" TCP-Paket, wodurch die
Anzahl der Pakete, die Netzwerk-Stack hat zu verarbeiten.
Im Idealfall würde die Aggregation vollständig in einen Proxy zwischen dem Fahrer
und der TCP-Stack getan werden, und ohne Änderungen an den Rest der KernelCode. Für die Richtigkeit und Leistung, kann diese vollständige Trennung nicht
erreicht werden, und kleine Änderungen an den Treiber und die TCP-Schicht
notwendig. Es wurden keine Änderungen der IP-Schicht oder das Layout der KernelDatenstruktur für die Speicherung von Paketen, sk_buff in Linux gemacht.
Erhalte Aggregation erfolgt am Eintrittspunkt des Netzwerk-Stacks. Packet
Koaleszenz ist für Netzwerk-TCP-Pakete, die ankommen "in-sequence" im gleichen
TCP-Verbindung. So muss die eingehenden Pakete den gleichen Ursprung haben IP,
Destination IP, Source Port und Destination Port Felder aus. Die Pakete müssen auch
in Folge, und zwar sowohl von TCP Sequence Nummer und TCPBestätigungsnummer. Somit muss die Summe der TCP-Sequenznummer von einem
30
Theoretische Lösung | Stoyan Varlyakov
7 März 2011
Paket und seine Länge entspricht der TCP-Sequenznummer des nächsten Pakets.
Auch ein TCP-Paket später in der aggregierten Folge muss eine TCPBestätigungsnummer größer oder gleich dem eines vorherige Paket in der Sequenz.
Packet Aggregation gilt nur für TCP-Pakete, also solche mit einer gültigen TCP-und IPPrüfsumme getan. Wir überprüfen nur die IP-Prüfsumme Bereich der Netzwerk TCPPaket, bevor es zur Aggregation verwendet wird. Für die TCP-Prüfsumme,
übernehmen wir die gemeinsamen Fall, dass die NIC Prüfsummenverschiebung
unterstützt, und hat die TCP-Prüfsumme validiert. Dies liegt daran, Überprüfung der
TCP-Prüfsumme in der Software würde die Aggregation teuer.
Wenn die Netzwerkkarte nicht unterstützt, erhalten Prüfsummenverschiebung wir
nicht ausführen Erhalte Aggregation.
TCP-Pakete der Länge Null, wie reine ACK-Pakete werden nicht zusammengerechnet.
Dies vereinfacht die Handhabung von doppelten ACKs in der TCP-Schicht und ist in
Abschnitt 3.6 diskutiert.
Da die TCP-und IP-Header eine große Anzahl von Option Felder zu unterstützen, ist
es nicht möglich, insgesamt zwei TCP-Pakete, wenn sie andere Option Felder
enthalten. Auch wird die Aggregation-Funktion recht kompliziert, wenn es um alle
möglichen TCP-und IP-Optionen unterstützen hat. So einfach haben wir nur TCPPakete Aggregat, dessen IP-Header verwenden Sie keine IP-Optionen oder die IPFragmentierung und dessen TCP-Header verwenden Sie nur die TCP-ZeitstempelOption.
Pakete, die nicht auf Spiel eine der Voraussetzungen für Erhalte Aggregation an das
Netzwerk weitergegeben unverändert Stapel. Dabei stellen wir sicher, dass es keine
Päckchen Neuordnung zwischen den Paketen der gleichen TCP-Verbindung, dh alle
teilweise aggregiert Paket die Zugehörigkeit zu einer TCP-Verbindung wird vor jeder
späteren unaggregierte Paket geliefert wird geliefert.
7 März 2011
Stoyan Varlyakov | Theoretische Lösung
31
2. Die Struktur einen aggregiertes Packet
Sobald eine gültige Satz von Netzwerk-Pakete für die Aggregation identifiziert wird,
nach den oben beschriebenen Bedingungen, die Aggregation Funktion verschmilzt
sie in aggregierter TCP-Paket für das Netzwerk Stack. [7]
Die aggregierten TCP-Paket wird durch Verkettung `'zusammen einzelne TCP-Pakete
auf die` Fragmente Form "der aggregierten Paket und durch Umschreiben der TCP /
IP-Header der aggregierten Paket erstellt. Die TCP / IP-Header des ersten TCPFragment in der Kette behält seine wird die Kopfzeile der aggregierten Paket,
während die nachfolgenden TCP-Fragmente nur ihre Nutzlast behalten. Die
Verkettung wird in einer OS-spezifische Art und Weise. Unter Linux, zum Beispiel, ist
die Verkettung, indem Sie den Zeiger in der Fragment sk_buff Struktur auf die
Nutzlast des TCP-Fragmente Punkt gemacht. Somit gibt es keine Daten kopieren in
Packet Aggregation beteiligt.
Die TCP / IP-Header der aggregierten Paket umgeschrieben, um das Paket Koaleszenz
zu reflektieren. Die IP-Paketlänge Feld ist die Länge des gesamten TCP-Nutzlast
(einschließlich aller Fragmente) plus die Länge des Header gesetzt. Die TCP Sequence
Number Feld wird in den TCP-Sequenznummer des ersten TCP Fragment gesetzt, und
die TCP-Bestätigungsnummer Feld ist auf die Anerkennung Nummer des letzten TCP
Fragment gesetzt. Die TCP-Fenstergröße beworben wird die Größe des Fensters in
den letzten TCP Fragment beworben gesetzt. Eine neue IP-Prüfsumme für die
aggregierten Paket über seine IP-Header und dem neuen TCP Pseudo-Header
berechnet. Die TCP-Prüfsumme ist nicht neu (denn das würde teuer werden),
sondern wir zeigen, dass das Paket von der NIC-Prüfsumme verifiziert wurde.
Die TCP-Zeitstempel in der aggregierten Paket wird aus dem Zeitstempel in der
letzten TCP-Fragment des aggregierten Paket kopiert. Theoretisch kann diese
Ergebnisse mit dem Verlust von Zeitstempel-Informationen und Einfluss auf die
genaue Abschätzung der RTT-Werte. Doch in der Praxis, da nur Pakete, die sehr
rechtzeitig ankommen nahe beieinander aggregiert sind, sind die timestamp-Werte
auf alle TCP-Fragmente dürfte die gleiche sein, und es gibt keinen Verlust an
Präzision. Wir geben ein strengeres Argument für diese Behauptung in Abschnitt 3.6.
32
Theoretische Lösung | Stoyan Varlyakov
7 März 2011
Schließlich ist die aggregierte TCP-Paket mit Informationen über ihre konstituierende
TCP-Fragmente ergänzt. Insbesondere wird der TCP-Bestätigungsnummer jedes TCPFragment in das Paket-Metadaten-Struktur (sk_buff, im Falle von Linux) gespeichert.
Diese Informationen werden später durch die TCP-Schicht für die korrekte
Verarbeitung Protokoll verwendet.
3. Wann stoppt die Netzwerkaggregieren
Netzwerkpakete werden zusammengerechnet, sofern sie von den NIC-Treibern
empfangen werden. Die maximale Anzahl der Netzwerk-TCP-Pakete, die in einem
aggregierten TCP-Paket verschmolzen erhalten, ist die Aggregation Limit genannt.
Sobald ein Paket das aggregierte Aggregation Limit erreicht, wird sie an das Netzwerk
weitergeleitet Stapel. [7]
Die tatsächliche Anzahl der Pakete, die in einer aggregierten Paket verschmolzen
bekommen kann kleiner sein als die Aggregation Limit, und hängt von der NetzwerkAuslastung und die Ankunftsrate der Pakete. Wenn eine aggregierte Paket enthält
weniger als die Aggregation Limit Anzahl der Pakete, und nicht mehr NetzwerkPakete werden zur Verarbeitung zur Verfügung, dann ist dieses semi-aggregierten
Paket wird an den Netzwerk-Stack ohne weitere Verzögerung weitergegeben. Somit
ist die Netzwerk-Stack nie erlaubt, untätig bleiben, während es Pakete im System zu
verarbeiten. Erhalte Aggregation ist somit Arbeits-Erhaltung und gilt nicht für die
Verzögerung der Paketverarbeitung hinzuzufügen.
Wir erwarten, dass die Leistungsvorteile von Erhalte Aggregation proportional zu der
Anzahl der Pakete in einer aggregierten Paket verschmolzen. Allerdings sind die
inkrementellen Leistungsvorteile der Aggregation zu erwarten, dass ab einer
gewissen Anzahl von Paketen marginal. Somit dient die Aggregation als obere Grenze
für die maximale Anzahl von Paketen zu aggregieren gebunden, und sollte auf einen
angemessenen Wert, bei dem die meisten Vorteile der Aggregation erreicht gesetzt
werden. Wir ermitteln einen guten Cut-off-Wert für die Aggregation Limit
experimentell.
7 März 2011
Stoyan Varlyakov | Theoretische Lösung
33
4. Modifizierungen der TCP Stack
Das aggregierten TCP-Paket wird vom Netzwerk empfangen und Stapel wird durch
die MAC-und IP-Schichten in der gleichen Weise verarbeitet, wie ein regelmäßiges
TCP-Paket verarbeitet wird. Doch auf der TCP-Schicht, sind Änderungen erforderlich,
um aggregierte Pakete korrekt zu behandeln. Dies liegt daran, TCP-Protokoll
Verarbeitung in der TCP-Schicht ist abhängig von der tatsächlichen Anzahl der
"Netzwerk" TCP-Pakete, und auf die genaue Reihenfolge der TCP-Bestätigungen
erhalten. Seit Erhalte Aggregation modifiziert diese beiden Werte, werden
Änderungen an der TCP-Schicht erforderlich, um einwandfreies ProtokollVerarbeitung für aggregierte Pakete.
Es gibt zwei besondere Situationen, für die das TCP Verarbeitungen muss geändert
werden:


34
Erstens (1) Congestion Control: Die Staus Fenster eines TCP-Sender ist auf die
Anzahl der TCP Quittungspaketen aktualisiert Basis erhielt durch den Absender,
und nicht auf die Gesamtzahl der Bytes anerkannt durch den Empfänger. Seit
Erhalte Aggregation setzt die TCP-ACK-Feld in der aggregierten Paket an die ACKFeld der letzten TCP-Fragment, dem herkömmlichen TCP-Schicht Umsetzung
würde das Congestion-Fenster anders gesetzt, was in Ermangelung erhalten
Aggregation gerechnet.
Die modifizierte TCP-Schicht errechnet die Congestion-Fenster mit dem TCP
Acknowledgement Nummern aller TCP-Fragmente der aggregierten TCP-Paket,
anstatt nur mit der endgültigen Bestätigung an. Wie in Abschnitt 3.1 erwähnt,
sind die Anerkennung Nummern der einzelnen TCP-Fragmente in das PaketMetadaten-Struktur (sk_buff) beim Empfangen Aggregation durchgeführt wird
gespeichert.
Zweitens (2) TCP Danksagung: Das TCP-Protokoll legt fest, dass eine
Anerkennung Paket für jede alternative volle TCP-Segment vom Empfänger
empfangen muss erzeugt werden. Seit Erhalte Aggregation verschmilzt mehrere
Netzwerk-TCP-Pakete in einem einzigen Paket zusammengefasst, würde die
herkömmlichen TCP-Schicht concude, dass es nur einen einzigen TCP-Segment
erhalten hat, und erzeugen daher die falsche Anzahl von Quittungspaketen.
Theoretische Lösung | Stoyan Varlyakov
7 März 2011
Die modifizierte TCP-Schicht errechnet die korrekte Anzahl der Bestätigungen
durch die Berücksichtigung der einzelnen TCP-Fragmente, sondern unter
Berücksichtigung des gesamten aggregierten Pakets als ein Segment. Diese
Information ist auch in der Struktur während sk_buff erhalten Aggregation
gespeichert.
5. Implementierung in Linux kernel 2.6.*
Erhalte Aggregation an der Eintrittsstelle des Netzwerks implementiert ist
Stapelverarbeitung Routine. Für die Linux-Netzwerk-Stack, das ist der Einstiegspunkt
des Softirq für Netzwerk erhalten Verarbeitung.
Treiber für die Netzwerkkarte, die Pakete von der Netzwerkkarte empfängt, wird
modifiziert, um die empfangenen Pakete in einem speziellen Erzeuger-Verbraucher
"Aggregation Warteschlange" Enqueue. Die Receive-Aggregation-Routine ausgeführt
in Softirq Zusammenhang "verbraucht" die Pakete verworfen in die Warteschlange
und verarbeitet sie zur Aggregation. Die `Aggregation Warteschlange" ist ein ProCPU-Warteschlange, und befindet sich in einer Lock-freie Weise umgesetzt. Somit
gibt es keine Sperren Overhead für den Zugriff auf diese Warteschlange gleichzeitig
zwischen verschiedenen CPUs oder zwischen den Interrupt-Kontext und die Softirq
Kontext entstanden sind.
Die Pakete verworfen in der Aggregation Warteschlange von der NIC-Treiber sind
`Roh"-Pakete, dh sie sind nicht in den Linux-Socket-Puffer Metadaten-Struktur,
sk_buff gekapselt. Der Grund für diese, wie in Abschnitt 2.2 diskutiert wird, dass
Speicher-Management von sk_buffs ist ein wichtiger Teil des Puffers ManagementOverhead von Netzwerk-Paketen. Wir vermeiden diesen Overhead durch die
Zuweisung der sk_buff nur für den Abschlussbericht zusammengefasst Paket, in dem
Empfang (receive) Aggregation Routine. Für Linux-Treiber, dieser erlaubt uns auch,
die MAC-Header-Verarbeitung von Netzwerk-Paketen in der Fahrer, die bewegt wird
das Erhalten Aggregation Routine zu vermeiden.
Pakete werden aus der Aggregation Warteschlange durch die Aggregation Routine
verbraucht sind und in eine kleine Lookup-Tabelle, die eine Reihe von teilweise
aggregiert TCP-Pakete unterhält Hash. Wenn das neue Netzwerk TCP-Paket
7 März 2011
Stoyan Varlyakov | Theoretische Lösung
35
"Streichhölzer" eine zuvor Hash-Paket, das heißt, es mit diesem Paket (basierend auf
den Bedingungen in 3.1 beschrieben) können miteinander verschmolzen werden,
dann sind die beiden zusammengerechnet. Ansonsten ist die teilweise aggregiert
Paket an den Netzwerk-Stack ausgeliefert, und das neue Paket wird in der LookupTabelle gespeichert.
Pakete geliefert an die Netzwerk-Stack sind synchron, verarbeitet und damit die
Kontrolle wieder an die Aggregation Routine nur, wenn die Netzwerk-Stack im
Leerlauf ist. So, um zu bleiben Arbeits-Erhaltung, wenn die Aggregation Routine läuft
von Netzwerk-Pakete zu verarbeiten (dh, ist die Aggregation Warteschlange leer), sie
sofort löscht alle teilweise aggregiert Pakete in der Lookup-Tabelle, und liefert sie an
das Netzwerk Stapel. Dies gewährleistet, dass Pakete nicht bleiben abzuwarten
Aggregation, während der Netzwerk-Stack im Leerlauf ist.
6.
Korrektheit
Erhalte Aggregation ist nur für eine beschränkte Gruppe von In-Order-TCP-Pakete,
die die TCP-Schicht "erwartet", während es in fehlerfreie Funktionsweise ist getan.
Jede TCP-Paket erfordert besondere Behandlung durch den TCP-Schicht, aus dem
gemeinsamen Weg, auf dem Stack ohne Aggregation vergangen, und so richtig durch
die TCP-Schicht behandelt. So arbeitet alle Fehler-Handling und Sonderfall
Bearbeitung von Paketen in der TCP-Schicht richtig. Wir geben ein paar Beispiele:
a)
Duplizieren oder Out-of-Order-Pakete: Da diese Pakete nicht in der
richtigen Reihenfolge (von TCP Sequence Number), sie sind nicht aggregiert und
werden direkt von der TCP-Schicht behandelt.
b)
Selektive TCP ACKs: Da TCP andere Optionen als die Timestamp-Option
nicht durch Aggregation behandelt werden TCP-Pakete mit selektiven ACKs
bestanden unverändert.
36
Theoretische Lösung | Stoyan Varlyakov
7 März 2011
c)
Duplikat ACKs: Ein doppelter ACK-Paket enthält keine Daten in seine
Nutzlast. Da reine ACKs nie aggregiert sind, werden diese korrekt durch die TCPSchicht behandelt.
Wir jetzt erklären, warum mit Zeitstempeln aus nur die letzten TCP-Fragment in
der aggregierten Paket nicht im Mangel an Genauigkeit führen. Bei Gigabit
Übertragungsrate kann eine einzelne TCP-Sender Maschine Pakete in Höhe von
rund 81.000 Pakete pro Sekunde zu übertragen. Die Genauigkeit der TimestampWert selbst, ist jedoch typischerweise 10 ms (wenn das System einen 100-Hz-Uhr
verwendet) oder 1 ms bestenfalls (mit einem 1000 HZ Uhr). So sind etwa alle 80
aufeinander folgenden Pakete von einem Absender übermittelt dürfte die gleiche
Zeitstempel zu beginnen haben. Seit Erhalte Aggregation verschmilzt zusammen
Pakete, die einander sehr nahe kommen in der Zeit, wir erwarten, dass diese
Pakete schon die gleiche Timestampwert.
D.
Acknowledgment Offload
Unsere zweite Optimierung zur Reduzierung der Overhead pro Paket von
empfangen Verarbeitung Anerkennung Offload. Anerkennung Offload reduziert
die Anzahl der TCP-ACK-Pakete, die auf dem Übertragungsweg von empfangen
Verarbeitung, verarbeitet werden müssen, und reduziert somit die insgesamt pro
Paket-Overhead. [7]
TCP Quittungspaketen machen einen erheblichen Teil des Aufwands von TCP
erhalten Verarbeitungen. Dies liegt daran, in das TCP-Protokoll, ein TCP-ACKPaket für jeweils zwei volle TCP-Pakete aus dem Netzwerk empfangen erzeugt
werden muss. Somit bilden TCP ACK-Pakete mindestens ein Drittel der
Gesamtzahl der Pakete durch das Netzwerk verarbeitet Stapel. Da der Aufwand
für die Netzwerk-Stack ist überwiegend pro Paket, die Verringerung der TCP-ACKÜbertragung Overhead ist essentiell für die Erreichung eines guten Leistung
erhalten.
7 März 2011
Stoyan Varlyakov | Theoretische Lösung
37
1.
Grundlagen
Anerkennung Offload ermöglicht die TCP-Schicht miteinander zu kombinieren die
Übertragung von aufeinander folgenden TCP-ACK-Pakete von der gleichen TCPVerbindung zu einem einzigen "Template" ACK-Paket.
Zur Übertragung der aufeinanderfolgenden TCP ACK-Pakete, erstellt das TCPSchicht eine "Vorlage" TCP-ACK-Paket, die die einzelnen ACK-Pakete. Die Vorlage
ACK-Paket ist bis das Netzwerk gesendet Stack wie ein normales TCP-Paket. Bei
Erreichen der NIC-Treiber (oder einen Proxy für den Fahrer), sind die einzelnen
TCP-ACK-Pakete wieder aus der Vorlage ACK-Paket generiert, und werden auf das
Netzwerk gesendet.
2.
TCP Schablonenpacket
Die Vorlage ACK-Paket für eine Sequenz von aufeinander folgenden ACKs wird
durch das erste ACK-Paket in der Reihenfolge dargestellt, zusammen mit der ACKSequenz-Nummern für die anschließende ACK-Pakete, die in der Vorlage Pakets
Metadaten-Struktur (sk_buff in Linux) gespeichert ist.
Die TCP-und IP-Header der aufeinanderfolgenden ACK-Pakete einer TCPVerbindung teilen die meisten der Felder des Headers. Insbesondere
unterscheiden sich nur das ACK-Sequenz-Nummer und die IP-Prüfsumme Bereich
zwischen den aufeinanderfolgenden Paketen. (Dies ist vorausgesetzt, sie sind
hinreichend nahe in der Zeit, erzeugt, so dass der TCP-Zeitstempel identisch
sind). Somit wird die Information in der Vorlage ACK-Paket ausreichend, um die
einzelnen ACK-Pakete in der Reihenfolge zu erzeugen.
Der NIC-Treiber ist geändert, um die Vorlage ACK-Paket unterschiedlich zu
behandeln. Die Vorlage Paket ist nicht auf das Netzwerk übertragen direkt.
Stattdessen macht der Fahrer die erforderliche Anzahl von Kopien für den
Netzwerk-ACK-Pakete. Dann schreibt die ACK Sequenznummer für die NetzwerkPakete, Neuberechnung der TCP-Prüfsumme und überträgt die Folge von TCP
ACK-Pakete auf der Netzwerkkarte.
38
Theoretische Lösung | Stoyan Varlyakov
7 März 2011
3.
Anwendungsgriff
Anerkennung Offload wird vorzugsweise in Verbindung mit dem Erhalten
Aggregation Optimierung eingesetzt. Dies liegt daran, in einem herkömmlichen
TCP-Stack, TCP ACK-Pakete erzeugt und synchron in Reaktion auf empfangene
TCP-Pakete (außer für die verzögerte TCP ACKs) übertragen. Da die empfangene
TCP-Pakete werden auch von der TCP-Stack synchron verarbeitet, wird die TCPSchicht nicht erzeugen Chancen zu Charge zusammen die Erzeugung von
aufeinanderfolgenden ACK-Pakete.
Doch mit Erhalte Aggregation, eine aggregierte TCP-Paket wirksam liefert
mehrere Netzwerk-TCP-Pakete an den TCP-Schicht gleichzeitig. Dies bietet die
TCP-Schicht die Möglichkeit, eine Sequenz von aufeinander folgenden TCP-ACKPakete gleichzeitig zu erzeugen, und an diesem Punkt, es kann der Anerkennung
Offload machen die ACK-Pakete zu übertragen.
7 März 2011
Stoyan Varlyakov | Theoretische Lösung
39
IV.
Praktische Lösung (Beweis)
A.
-
-
Testverfahrenerklärung
Durch Optimierung an großes Netzwerkauslastung, werden wir „Real life“ Anwendungen
annehmen – SMB Protokoll bei Windows Systeme und NFS bei Linux. RamDrive (mount –
t tmpfs) to /dev/null copy in Linux, RAMDRIVE to RAMDRIVE in Windows [R2]
Synthetische Benchmarks:
Netperf bei Linux, PassMark Network bei Windows (2003)
B.
Teste
1.
Synthetisches Test
PassMark Benchmark, mit die Einstellungen von MTU 1500 Bytes, keine Optimisationen,
TCP Transfereinheit 16384 Bytes.
2.
Echtdateitransferanwendung:
File Copy über CIFS (oder SMB 1.0) einen 492 MB großes Datei, kopiert vom Server zu die drei
Clients, gleichzeitig. Dieses Filecopy wird 10 Mal wiederholt und dann die gesamten Zeiten in
Sekunden dargestellt. Alle Tests sind dreimal wiederhold und das Resultat approximiert für
maximale Genauigkeit. Es wird die CPU Auslastung notiert.
Als Basis unsere Testverfahren nehmen wir 4 virtuelle Maschinen insgesamt. Ich habe
mich für virtuelle Maschinen entschieden, da der Overhead beim
Netzwerkpacketenbearbeitung doppelt ist und jeder Verbesserung der
Netzwerkdurchsatz wird sich stärker äußern, so sollten die Resultaten deutlich klarer
werden.
Von den schon erwähnten Arten von Netzwerkteaming, werde ich der Lösung von
balance-alb (Modus 6) bekannt als „ALB+RLB“ in der Windows Lösung.
Hiermit will ich erwähnen, dass in keiner der Tests habe ich zulassen, dass die CPU
Auslastung insgesamt der Hostmaschine lauft am 100% pro jede Kern.
Eine Bildschirmaufnahme in die schwierigste Situation:
40
Praktische Lösung (Beweis) | Stoyan Varlyakov
7 März 2011
Anbei Information für die Hostmaschine:
Meminfo lautet (durch das Programm CPU-Z) [R1]:
7 März 2011
Stoyan Varlyakov | Praktische Lösung (Beweis)
41
3.
Server
FQDN Name: server1, IP Adresse 192.168.100.1/24
Windows Server 2003 R2 SP2, alle Hotfixes aus Windowsupdate Stand 20. Jan 2011,
mrxsmb.sys ist Version 5.2.3790.4671 von 24 Feb 2010. RAM ist 2048 Mb, wo die
DataRam Festplatte [R2] hat die Größe von 1024 Mb (wird als non-paged Speicher vom
Betriebssystem betrachtet), eine virtuelle CPU
Clients:
FQDN Name: client1 (192.168.100.10),
(192.168.100.12):
client2
(192.168.100.11) und
client3
Gecloned einer von den anderen. Mrxsbm.sys hat die Version 5.1.2600.5512 Datum 14
April 2008.
Jeder Client hat 1024 Mb RAM, wo der RAMDrive [R2] übernimmt 512 Mb RAM und ist
gemountet als Festplatte E:. Jede virtuelle Maschine hat eine physikalische CPU
zugewiesen.
Die Testdateien befinden sich auf eine Fileshare \\192.168.100.1\e und sind die
folgenden Dateien:
Alle diese sind binäre Dateien, damit keine Komprimierung beim Transferieren mit
einem verbesserten Datenaustauschrate helfen kann.
Auf die RAMDrive in jeder Klient wir die folgende Kommandozeile ausgeführt.
@echo off
@echo %time% >>1.txt
FOR /l %%G IN (1,1,10) DO (
copy y:\en_outlook_2010_x86_516729.exe
del *.exe /f
42
Praktische Lösung (Beweis) | Stoyan Varlyakov
7 März 2011
copy y:\R268878.exe
del *.exe /f
copy y:\3.rar
del *.rar /f
echo Run:%%G
set /a count+=1)
@echo %time% >>1.txt
Als Resultat werden die Anfangs- und Endzeiten notiert. Dieser Test wird Dreimal
wiederholt und das Resultat als durchschnittlicher Wert wird dargestellt.
Für den PassMark Test werden die folgenden Einstellungen implementiert:
Auf dem Server:
3 Paralelle Ausführungen der Test auf 3 verschiedenen TCP Ports 1040, 1041, 1042
Protokoll = TCP
Auf den Klienten:
Transfereinheit = 16384 Bytes
Zeit der Test = 60 s.
Protokoll = TCP
Erwartete Resultaten:
Transferwert im MBit/sek (Summe der 3 Daemons) und CPU Auslastung auf der Server
und durschnittlicher Wert {(Client 1+ Client 2 + client 3) / 3} für die Klienten.
V.
Resultaten in Ausgangssituation
MTU auf der beiden Klient und Server ist auf 1514 (Voreinstellung) konfiguriert und es
sind keine Anpassungen der TCP Stack implementiert.
Restulate Passmark Test
Transfereinheit ist beim 16384, aber MTU beim 1500, d.h. dass jede Transfereinheit wird
von der Netzwerkstack fragmentiert.
Alle Klienten sind bei 100% CPU Auslastung, der Server bei den 39 %.
Datenaustausch ist bei 145 Mbit/sek.
Traffikgraph aus einer der Klienten:
7 März 2011
Stoyan Varlyakov | Resultaten in Ausgangssituation
43
FileCopy: 4 Minuten 24 Sec (21.7 Mb/sec pro Klient), CPU Auslastung beim 82 Prozent
auf Client, 38% auf Server
Anmerkung: Der Passmark Test stresst der CPU wesentlich Mehr auf der Klientseite.
Deshalb ist der Wert für Filecopy wesentlich höher.
A.
Schritt1
Hier wurden die vorgeschlagene TOE and TSO Verbesserungen implementiert nur auf die
Klientseite, da man dort ein Flaschenhalsproblem beobachtet:
1.
PassMark
Transfereinheit ist beim 16384, aber MTU beim 1500, d.h. dass jede Transfereinheit wird von der
Netzwerkstack fragmentiert.
Alle Kliente sind bei 100% CPU Auslastung, der Server bei den 19 %.
Der Server macht insgesamt 185 Mbit/sek.
Traffikgraph aus einer der Klienten:
44
Resultaten in Ausgangssituation | Stoyan Varlyakov
7 März 2011
FileCopy: 2 Minuten 35 Sec (36,7 Mb/sec) pro Client, CPU Auslastung beim 82 Prozent
auf Client, 98% auf Server
Notiz: Wenn wir Teaminglösung in diese Situation konfigurieren, dann haben wir gar
keinen Gewinn bei der beiden Tests. Zwar aufgrund der doppeltes Overhead bei den
Treiberaktionen, wird mehreres CPU Zeit der Server VM gebraucht, deshalb kommt
keine Optimierung vor. Sogar bei dem Filecopy Test sieht die Situation ziemlich
schlechter aus.
WICHTIG: Wenn wir keinen Flaschenhalsproblem beim Netzwerkauslastung haben, die
Teaminglösung ist doch einen unnötigen Overheadquelle!
7 März 2011
Stoyan Varlyakov | Resultaten in Ausgangssituation
45
B.
Schritt 2
In Zusatz der schon vorgeschlagene TOE and TSO Optimisationen, werden wir auch die MTU
Einheit von 1512 auf 16384 Bytes vergrößern
1.
Passmark
Alle Kliente sind bei 100% CPU Auslastung, der Server beim 38%.
Der Server macht insgesamt 900 Mbps
FileCopy: 2 Minuten 15 Sec (42 Mb/sec) pro Client, CPU Auslastung beim 82 Prozent auf
Client, 38% auf Server.
CPU Auslastung auf alle Clients ist bei 87%. Auf der Server bei 29 % .
Insgesamt Auslastung auf der Server während der Filecopytest: 1020 Mbps .
46
Resultaten in Ausgangssituation | Stoyan Varlyakov
7 März 2011
CPU Auslastung auf der Server beim Dateikopieren Test mit TSO+TOE und MTU 16k
7 März 2011
Stoyan Varlyakov | Resultaten in Ausgangssituation
47
C.
Schritt 3
Da wir schon den Flaschenhalsproblem bei der reine Netzwerkkapazität beobachten, sollen wir
schon der Bonding-Lösung implementieren. Da ich in der Testumgebung keinen Switch zum
Switch Verbindung habe, werde ich den schon beschriebenen Adaptive Load Balancing (ALB)
Teaminglösung implementieren und zusätzlich Receive Load Balancing (RLB) aktivieren.
1.
Passmark
Der Server macht 930 Mbps. Die CPU Auslastung auf die Klienten ist beim 95% auf dem
Server beim 39%.
Echtes Dateitransfer:
CPU Auslastung auf alle Clients ist bei 87%. Auf der Server bei 40 % .
Insgesamt Auslastung auf der Server während der Filecopytest: 1580 Mbps (!).
Die Verbesserung sehen wir meistens auf die Serverseite mit einem niedrigeren CPU
Auslastung mit 6% Relative Verbesserung
48
Resultaten in Ausgangssituation | Stoyan Varlyakov
7 März 2011
D.
Validierung der Resultate in Linux
Ich habe dasselbe Verfahren in eine Linuxumgebung nachgestellt.
Die Server war einen OpenSuSE 11.3 32 bit mit 2 Netzwerkadaptern, geteamt mit
balance-alb Modus6. Die Klienten waren wieder OpenSUSE 11.3 32 Bit mit eine
Netzwerkkarte jeder. Ich habe mich nur in den „Real Life Tests“ fokussiert, da der größte
Auswirkung in der reellen Dateitransfer zu sehen war.
Als Netzwerkzugriffsprotokoll, habe ich NFS verwendet und auf dem Server habe ich das
Ziel der gemountete Share auf eine tmpfs gemacht (RAMDrive). Dann nur Lesezugriff in
der Form cat * > /Dev/null getestet. Die Resultate lauten.
Anfangssituation: Benchmark hat 295 Sekunden in Durchschnitt gedauert (154 Mbps pro
Klient
7 März 2011
Stoyan Varlyakov | Resultaten in Ausgangssituation
49
Schritt1 (Offloading): Die Filecopy hat 262 Sekunden gedauert (170,5 Mbps pro Klient
oder Verbesserung von 12,5% im Vergleich zum Ausgangssituation)
Schritt2 (Jumboframes) Filecopy hat 249 Sekunden gedauert (179,4 Mbps pro Klient
Verbesserung 18,4 % im Vergleich zum Ausgangssituation)
Schritt3 (Offloading + Jumboframes). Filecopy hat 46 Sekunden gedauert (992 Mbps pro
Klient, Verbesserung 552 % im Vergleich zum Ausgangssituation)
50
Resultaten in Ausgangssituation | Stoyan Varlyakov
7 März 2011
VI.
Analyse der Pakete per Wireshark
Hier werde ich auf sehr niedriges Niveau sehen, was die Auswirkung der vorgeschlagenen
Implementierungen ist. Ich werde mich in der „Real life“ Test fokussieren, da der Synthetisches
Test sehr leicht hervorzusagen ist.
A.
Ausgangssituation
MTU 1514, kein Offloading
Der SMB 1.0 Protokoll bei Windows 2003 aggregiert einige Lese- oder Schreibvorgägne
zusammen und transferiert nur in einer der beiden Richtungen. Aus der Netzwerktrace
kann ich eine Proportion von 1 Quittung zu 9 Pakete auslesen. Daher ist es sehr leicht zu
erklären die große Verbesserung bei der Optimierung.
Größe der Pakete:
7 März 2011
Stoyan Varlyakov | Analyse der Pakete per Wireshark
51
A.
Schritt1 – nur Offloading
Da der Offloadingtreiber macht TCPSegmentation Offload, zeigt das Betriebssystem alle
Pakete „aggregiert“.
Die Auswirkung der Offloading auf Treiberebene können wir durch die falsche Checksum
erkennen. Da die Checksum von der Netzwerktreiber berechnet wird und ans
Quellserver gesendet, verbleibt dieses Prozess für den Betriebssystem transparent. Auch
die Einheiten der Pakette werden als größer als der MTU angezeigt – 28672 Bytes bis
0xffff = 65536. Aber wenn wir die Situation auf einen Netzwerkbridge anschauen (der
keinen Teilnehmer ist in dieses Datenaustausch, dann beobachten wir alle Pakete (MTU
ist gleich 1514).
Bezüglich der Größe der Pakete – 26% alle Pakete sind größer als 2500 Bytes und 75%
alle Pakete sind von 150 bis 300 Bytes.
Wenn wir die Situation auf dem Netzwerkbridge anschauen, dann sehen wir, dass
eigentlich, dass fast 88% der Pakete eine Größe von 1514 Bytes haben und dann die
Restliche 12% eine Größe von 150 bis 300 Bytes hat.
B.
Schritt 2 und 3 – MTU = 16386 mit und ohne Offloading
Die Verteilung der Packeteinheiten sieht so aus:
52
Analyse der Pakete per Wireshark | Stoyan Varlyakov
7 März 2011
Interessant zu sehen ist, dass 60% der Pakete eine sehr hohe Große haben.
Die Pakete haben einen sequentiellen Reihenfolge und interessanterweise man
beobachtet keine Quittungen in der TCP Stack. Es folgen 2 Pakete mit maximale Große
und dann 1 mit einen Schreibresponce. Keine Quittungen in den beiden Richtungen. Der
SMB Protokoll ist einen bekannten Protokoll und die gesamte Berechnungen der
Quittungen werden von der Netzwerktreiber gemacht, deshalb ist dieses Prozess
transparent für die Betriebssystem.
C.
Sicherheit der implementierte Lösungen – Der UDP Test
Die bis jetzt vorgeschlagenen Optimierungen greifen immer in der Richtung Schnelligkeit,
da der TCP Protokoll sichere Transportierung garantiert.
Oftmals, aber wird auch einen nicht sicheren Dienst auf dieselbe Netzwerk transportiert,
wo es sehr starke Auslastung von TCP Pakete gibt. SO einen Protokoll ist UDP und ich
werde anhand der UDP Protokoll austesten, ob es sicher wäre, die vorgeschlagene
Optimierung direkt in alle Netzwerke zu implementieren.
UDP Test von verlorene Pakete bei Maximaler Auslastung auf einen virtuellen Switch –
keinen Physikalische Probleme, nur Stackbasiertes „Race Condition“ Probleme. Da UDP
kein Sicherer Transport garantiert, ist dieser Test sehr nah an der Cacheverwaltung und
CPU Auslastungseinfluss auf den Puffern orientiert.
7 März 2011
Stoyan Varlyakov | Analyse der Pakete per Wireshark
53
In der Anfangssituation, bei einer vollen Netzwerkauslastung von 200 Mbps mit TCP
Pakete und nur einen Stream mit 50 Mbps, haben wir einen Verlustrate von 90%. Dieser
Wert ist sehr sehr hoch und ist für keinen Dienst genügend (VoIP, Video Streaming
etc…). Wenn wir die TCP Auslastung auf 150 Mbps begrenzen, dann nimmt die
Verlustrate auf 0.2% zu, was für fast jeden UDP Dienst gut genug wäre.
Bei Implementierung von Schritt 1 (Offloading) können wir 2 TCP Streams haben mit
jeder Schreibrate von 100 Mbps und 2 UDP Streams mit Schreibrate von 50 Mbps. Dann
ist der Verlustrate beim 0.06%, was ein sehr gutes Resultat ist.
Wenn wir die Geschwindigkeit der TCP Streams verdoppeln (200 Mbps per Stream),
dann steigt der Verlustrate auf 0,47%, was immer noch akzeptabel ist.
Wenn wir aber der TCP Schreibrate auf 300 Mbps per Stream setzen, dann sehen wir
wieder einen Verlustrate von 90+%, was extremunakzeptabel ist.
Bei Implementierung alle vorgeschlagenen Optimierung, haben wir immer noch
dieselben Resultate bei der UDP Test, weil das Problem mit der CPU Auslastung ist. Jedes
Mal, wann auf der Client die CPU Auslastung einen Wert von 80% Prozent hat, dann gab
es riesige Verluste.
Deshalb ist es kritisch, dass man genug CPU Leistung für UDP Basierte Netzwerke
garantiert. Entweder mit eine QoS Lösung(Limitierung der Geschwindigkeit pro Dienst)
oder mit einen starkes Hardwareeinsatz berücksichtigen.
54
Analyse der Pakete per Wireshark | Stoyan Varlyakov
7 März 2011
VII. Zusammenfassung
In meiner Diplomarbeit habe ich der Antwort der Frage gesucht “Wie kann man der TCP
Protokoll richtig für sehr hohes Netzwerkauslastungsumgebung anpassen”.
Die Lösung in der Richtung CPU Auslastung ist TCP Offloading Engine (TOE) und TCP
Segmentation Offload (TSO) und eine Erhöhung der MTU Wert (bekannt als Jumboframes).
Zusammenimplementiert in einen Homogänennetzwerk, die Resultate sind überraschend – eine
Verbesserung im Faktor 5 kann man erwarten, wenn das Protokoll große Transfereinheiten
unterstützt.
A.
Windows Resultate der Verbesserung:
1600
1400
1200
Mbps
1000
Daten
800
Passmark
600
400
200
0
Start
7 März 2011
Schritt1
Schritt2
Schritt3
Stoyan Varlyakov | Zusammenfassung
55
B.
CPU Auslastung der Server in der gegebenen Tests:
100%
90%
80%
70%
60%
50%
CPU-P
40%
CPU-D
30%
20%
10%
0%
Start
C.
Schritt1
Schritt2
Schritt3
Leistung Bits pro Megahertz
1.4
1.2
Bits\Mhz
1
0.8
Data
0.6
Passmark
0.4
0.2
0
Start
56
Schritt1
Zusammenfassung | Stoyan Varlyakov
Schritt2
Schritt3
7 März 2011
D.
Resultate in der Linux Implementierung pro Client
1200
1000
Mbps
800
600
Datendurchsatz
400
200
0
Start
Schritt1
Schritt2
Schritt3
Eine andere Schlussfolgerung müssen wir aber allerdings ziehen – es gibt keinen QoS
Dienst für die TOE und TSO. Deshalb wird der bekannte FIFO Verfahren verwendet und
Protokolle, die kein sicherer Übertragung garantieren, können ein Problem haben mit
extreme Datenverluste. Daher kommt der sehr spezifischen Einsatz der vorgeschlagenen
Lösungen und zwar Umgebungen, wo iSCSI, Hypervisor, High Performance Computern,
High availability Cluster Hochauslastungsbackupnetzwerke usw.
Noch eine weitere Schlussfolgerung habe ich bewiesen:
Wenn wir keinen Flaschenhalsproblem bei der Netzwerkauslastung haben, die Teaminglösung
ist doch einen unnötigen Overheadquelle!
7 März 2011
Stoyan Varlyakov | Zusammenfassung
57
Referenzen:
[1] http://oprofile.sourceforge.net/news/
[2] http://download.intel.com/design/network/applnots/321211.pdf
[3] IEEE 802.1ad
[4] IEEE 802.3x
[5] Mogul, Jeffrey C. (2003) Proceedings of HotOS IX: The 9th Workshop on Hot Topics in
Operating Systems.
[6] TOE by Linux Foundation, online:
http://www.linuxfoundation.org/collaborate/workgroups/networking/toe
[7] Optimizing TCP Receive Performance Aravind Menon and Willy Zwaenepoel, online:
http://www.usenix.org/event/usenix08/tech/full_papers/menon/menon_html/paper.html
[8] TCP Offload engines finally arrive by: Alan Earls , Storage Magazine
[9] http://www.emulex.com/blogs/dell/2010/03/04/nashville-rocks-convergence-toe-iscsifcoe/
[10] The tolly group doc. no. 207171 Feb 2007 - Nortel Ethernet 5500, 1600, 8300 and 8600
switches, evaluation of resilient routing switches for real time multimedia traffic
[11] Link Aggregation Trunking – Sun Microsystems.
[12] How do I use Teaming with Advanced Networking Services (ANS)? (Intel Webseite)
online: http://www.intel.com/support/network/sb/cs-009747.htm
[13] Thomas Davis <tadavis at lbl.gov> Linux Ethernet Bonding Driver, online:
http://www.kernel.org/doc/Documentation/networking/bonding.txt
[14] An Introduction to SR-IOV Technology, Intel
LAN Access Division, online:
http://download.intel.com/design/network/applnots/321211.pdf
58
Zusammenfassung | Stoyan Varlyakov
7 März 2011
Resourcen
[R1] CPU-Z, Online: http://www.cpuid.com/softwares/cpu-z.html
[R2] DataRam RAMDRIVE, basiertauf ramdisk.sys von Microsoft. Online:
http://memory.dataram.com/products-and-services/software/ramdisk
7 März 2011
Stoyan Varlyakov | Zusammenfassung
59