Schon einmal im Internet nach Trunking, Bonding und/oder Multipath gesucht und sich gefragt, was brauche ich eigentlich? Aus aktuellem Anlass haben wir heute einige Experimente mit diesen Verfahren gemacht.

Warum?

Die Evolution der Virtualisierung unserer Maschinen in der Firma hat mittlerweile einen langen Weg hinter sich. Zu Anfang setzten wir auf Virtual Server 2005 von Microsoft, danach folgte dann ein VMWare Server. Auf den Clients wird zu Testzwecken weiterhin VirtualBox benutzt. Warum wir von den Microsoft und VMWare-Lösungen weg wollten, war die mieserable Performance. Die Windows-Systemen liefen unter VS2005 relativ schnell. Linux hingegen ließ sich faktisch gar nicht benutzen (Kernel 2.6.20 aufwärts, Ubuntu, Debian, SuSE). Somit hatten wir im ersten Schritt VMWare neben VS2005 laufen. Allerdings verbrauchten beide Virtualisierungslösungen im Parallel-Betrieb doch einiges an Ressourcen, so dass wir von VS2005 nach VMWare migrierten. Bereits nach einigen Tagen stellten wir enorme Probleme unter Windows-Gästen beim Festplattenzugriff fest.

Wegen fehlender Debug-Möglichkeiten lag unser Schluss darin, dass vermutlich das darunterliegende RAID5 (3Ware-Controller) mit dem VMWare Write-Operations nicht klar kam. Außerdem liefen die Windows-GUIs nicht perforrmant genug.

Nach zwei Jahren des Herumärgerns starteten wir vor zwei Wochen, den XENServer zu evaluieren. Dabei ist es so, dass alle unsere virtuellen Fesplatten in unserem SAN (open-E DSS) liegen sollten. SAN, physikalische XEN-Maschine und zwei weitere Server sind an einem Netgear-Gigabit-Switch angeschlossen.

Trunking / Bonding

Trunking bedeutet, dass mehrere physikalische Leitungen zu einer “dicken” logischen Leitung zusammengelegt werden. Dies hat den Vorteil, dass der Gesamtz-Datendurchsatz (theoretisch!) um die Anzahl und den Durchsatz der zusätzlichen Leitungen erhöht werden würde. Damit ein Trunk erstellt werden kann, kommt das Link Aggregation Control Protocol zum Einsatz. Dieses Protokoll bildet den IEEE-Standard 802.3ad ab. Auf den Netgear-Switches nennt sich diese Funktion Link Aggregation Group (LAG).

Der Begriff Trunking wird häufig auf Seiten des Switches verwendet. Bei den Netzwerkkarten an sich wird weitaus häufiger der Begriff des “Bondings”, d.h. das Zusammenfassen von mehrerer Netzwerkkarten zu einer, benutzt. Grundsätzlich sind die Begriffe Bonding und Trunking aber gleichbedeutend zu benutzen.

Beim Bonding gibt es verschiedene Modi. Unter Windows mit einer Intel PRO/1000 PT Quad Port LP kann man aber beispielsweise keinen direkten Modus auswählen, es wird immer der Modus 802.3ad benutzt.

Linux bzw. Linux Channel Bonding Project hingegen kennt weitere Modi:

• mode=0 (balance-rr): Dabei werden alle gebondeten Netzwerkkarten nacheinander benutzt. Paket a wird über phys. eth0 gesendet, Paket b über eth1 u.s.w. (Load Balancing und Fehlertolerant)
• mode=1 (active-backup): Es ist immer eine Netzwerkkarte aus dem Bond aktiv. Sobald diese deaktiviert wird (Netzwerkkarte kaputt, Link zwischen NIC und Switch weg etc.) wird die nächste Karte aus dem Bond aktiviert (Fehlertolerant)
• mode=2 (balance-xor): Für jede Anfrage wird eine Netzwerkkarte ausgewählt und diese wird im Laufe der Verbindung weiter benutzt (Fehlertolerant und Load Balancing)
• mode=3 (broadcast): Der Name ist Programm: Auf allen NICs wird übertragen (Fehlertolerant)
• mode=4 (802.3ad): Hiermit wird 802.3ad für das Bond benutzt. Der Switch muss das Protokoll unterstützen.
• mode=5 (balance-tlb): Steht für Transmit Load Balancing, wenn ein Slave aufällt, wird die MAC-Adresse von einem anderen Bond-Mitglied übernommen (Fehlertolerant)
• mode=6 (balance-alb): Steht für Adaptive Load Balancing, hier werden die ARP-Requests des lokalen Systems vom Bonding-Treiber überschrieben (Fehlertolerant)

Mehr Infos auf englisch gibt es bei Linux Horizon, von wo ich auch die Informationen her habe.

Bonding im XENServer

Im XENServer 5.x kommt das oben genannte Linux Channel Bonding Project zum Einsatz. Unsere bisherige Hardware lief mit einer LACP nach 802.3ad. Nachdem wir in der Oberfläche des XenCenters ein neues Bond erstellt hatten, wurde es auch wunderbar hochgefahren. Allerdings arbeitet das Bond standardmäßig in einem eigenen Modus. Damit war es nicht möglich, unser SAN anzupingen. SAN und XEN lagen im gleichen Subnetz. Grund dafür war eben, dass die Modi sich unterschieden. Damit nun XENServer den Modus 802.3ad benutzt, muss unter /etc/sysconfig/networks der Eintrag BONDING_OPTS=”mode=4″ hinzugefügt werden. Danach müssen die Interfaces neu gestartet werden. Im Anschluss konnte sich der XENServer über den NetGear GS748T mit dem SAN verbinden.

Wenn bis zu dieser Stelle durchgehalten hast, würde dich sicherlich auch folgende PDF interessieren: Virtualiasierung und Netzwerkstruktur

Multipath!

Beim Zugriff auf unser SAN per iSCSI besteht die Möglichkeit, Multipath zu aktivieren.

Beim Bonding besitzt jedes Bond genau eine IP-Adresse. Die einzelnen Bond-Slaves (Netzwerkkarten) besitzen keine fest zugewiesene IP-Adresse mehr. Bei einem Bond aus 4 Netzwerkkarten würde das Bond über eine IP-Adresse angesprochen werden. Im Gegensatz dazu besitzt beim Multipath jeder Netzwerkkarte eine IP-Adresse. Dabei ist es aber wichtig, dass jede Adresse in einem unterschiedlichen Subnetz liegt. Anhand des Subnetzes wird entschieden, an welche Karte das Paket letztendlich gesendet wird. Multipath erhöht durch diese Technik zum einen den Datendurchsatz, zum anderen bietet es höhere Fehlertoleranz.

Beim Multipath gibt es ebenfalls verschiedene Modi, die Auswirkungen auf die Performance und Sicherheit haben:

• Fail Over – entspricht dem mode=2 beim Bonding
• Round Robin – die Pakete werden gleich auf die einzelnen Pfade verteilt (mode=0 beim Bonding)
• Round Robin With Subset – eine Mischung zwischen Fail Over und Round Robin. Sobald eine der aktiven Pfade wegbricht, werden die inaktiven Pfade aus dem Standby aufgeweckt und benutzt.
• Least Queue Depth – hiermit wird ein Lastenausgleich gefahren, der dem Round Robin entspricht. Wenn die einzelnen Pfade vom Durchsatz her nicht gleichmäßig augelastet sind, wird versucht, die Daten über die weniger benutzten Pfade zu transportieren.
• Weighted Paths – Lastenausgleich, der vom Benutzer eingstellt werden kann. Damit lassen sich quasi manuelle Routing-Metriken festlegen
• Least Blocks – Die Anfragen werden an den Pfad weitergeleitet, der die kleinste Nummer an blockierenden I/O-Zugriffen besitzt.

Fragen? Fragen!

• Soll ich Trunking oder Multipath einsetzen?
  Das hängt von der Umgebung ab. Mit Trunking hat man mehr ein paar mehr Möglichkeiten, was die einzelnen Modi angeht. Allerdings funktionieren nicht alle Modi auf allen Betriebssystemen. Für 802.3ad müssen außerdem die Switches das Protokoll unterstützen. Multipath bedeutet höheren Konfigurationsaufwand, da jede Netzwerkkarte eine eigene IP in einem eigenen Subnetz benötigt.
• Kann ich Multipath über einen LACP-Trunk fahren?
  Ja, ich habe zwei Bondings auf jedem Server eingerichtet und diese dann mit Multipath (Round Robin) getestet. Die Verbindung funktioniert einwandfrei, von der Performance her gibt es aber keinen Unterschied zum normalen Bonding. Außerdem ist es doppelter Konfigurationsaufwand, sowohl Bonding als auch Multipath einzurichten.
• Ist Bonding oder Multipath performanter?
  Im Test war das Bonding/Trunking beim Lesen geringfügig langsamer als Multipath. Beim Schreiben hingegen war Multipath fast doppelt so schnell.
• Welches ist der schnellste Multipath-Modus?
  Im Test ergab sich, dass die Policy “Weighted Paths” mit ca. 4 MByte/s die Nase vorne hatte
• Funktioniert Multipath auch unter Windows?
  Ja, der iSCSI Initiator von Microsoft hat dieses Feature implementiert.
• Kann ich die Load Balance Policy “Least Queue Depth” oder “Least Blocks” ind der Kombination Microsoft iSCSI Initiatior und open-E DSS nutzen?
  Nein, in der Kombination Windows (Server 2003, XP, Vista) und open-E DSS ist diese Policy für Multipath nicht möglich.