The name is bond... bond0

(találós kérdés: kit parodizálok? :) )

Ja és természetesen az úgy kéne, hogy a nagyobb sávszél bármely 1-1 blade között is rendelkezésre álljon. Hogy ez miért fontos, az majd kiderül lejjebb.

Mit lehet tenni ilyenkor?
Venni 10Gbit-es cuccokat... NEM! :)
Például bondolni a két interfészt, hogy együttesen 2Gbit legyen.

Persze ez nem ilyen egyszerű. Egy kis gyors áttekintés a bondolás buktatóiról:

• Kapásból többféle üzemmód van, a Linux támogat vagy hatfélét. Itt lehet bővebben olvasni róluk
• Ezekből összesen 1 olyan üzemmód van, ami szabványos, és switchekben is szokás támogatni: a 802.3ad, másnéven LACP.
• A legtöbb bonding üzemmód, az LACP-t (minden lehetséges beállításával, lásd lejjebb) is beleértve arra játszik, hogy minél inkább elkerülje egy-egy kapcsolat csomagjainak a különböző útvonalak közötti szétdobálását, mert ebből csomag átsorrendeződés sülhet ki. Az átsorrendeződés pedig nem jó, mert a felsőbb rétegek (pl TCP) nem feltétlen szeretik. Pl belassulnak tőle, jól, illetve elkezdenek feleslegesen újraküldeni szegmenseket.
• Vannak mindenféle hashing policy-k, amik a csomagok fejléceiből - általában konfigurálható módon - bizonyos mezőkből egy hash-t számolnak és ez alapján az egész adatfolyamot egy megadott kimenő interfészhez kötik. A butábbak csak forrás-cél MAC címek alapján, az okosabbak akár TCP, UDP portok alapján is. Ezzel jó esetben akár két host között is ki lehet használni a nagyobb sávszélességet, de csak több különálló TCP kapcsolat esetén.
• Ha viszont egy kapcsolaton belül kéne kihasználni a sávszélességet, akkor csak egy üzemmód jöhet szóba: a round-robin
• A round-robin viszont egy elég rosszul támogatott üzemmód. A legtöbb switchben nem lehet bekapcsolni. Mitikus, múltba vesző legendák szólnak olyan switchekről, amik még támogatták. Én egyel sem találkoztam, pedig láttam már párfajta Cisco-t, Nortel-t (Dlinket, Linksys-t, Planet-et, SMC-t). A baj az, hogy hiába adja a host a csomagokat felváltva két linken, a switchből kifelé már csak egy linken fognak menni akkor is, ha a fogadó félnek is volna több linkje (és a switch tud is róla). Egy sessionhöz tartozó össz-sávszélesség sosem lesz több egy link sebességénél.

Mit lehet ilyenkor tenni? A round-robin mode viszonylag sikeresen szokott működni akkor, ha a gépek crossover kábellel direkben vannak kötve. Blade keretben ilyenre nincs lehetőség, ott sajnos a hálókártya mindenképpen a belső switch-ekben végződik. Ráadásul a két hálókártya két külön switchbe megy... ami jelen esetben nem is annyira hátrány. De azért vannak buktatói.

A round-robin bondolásnál mindekét slave interfész felvesz egy közös MAC címet, ettől a (bondingot nem támogató, vagy nem jól bekonfigurált) switchek idegbajt kaphatnak. Most ugyan két külön switch van, de azért kívül az uplink egy Cisco3750-ben találkozik, itt baj lehet. Nekem ugyan a blade-ek között kell a nagy sávszél, de azért eközben ki is kell látni valahol a keretből. Az ARP normál működésével sem teljesen konform ez a megoldás, ha a switchben esetleg ARP caching is van, akkor ki tudja végül mi történik.

LABEL: A_LENYEG

Így tehát csavartam egyet a terven és úgy döntöttem, hogy a round-robin bondolt forgalmat ketrecbe, illetve a keretbe zárom, az ne jusson ki a blade kaszni két belső switchéből, így kívül nem fog találkozni egymással a két különböző irányból érkező azonos MAC című csomag. Viszont a blade-ek legalább 1 hálókártyán - nem bondolt módon - ki kell lássanak a keretből. Ezt meg lehet oldani például VLAN-okkal. A bondolt forgalom taggelt lesz és a switcheken ezt a VLAN-t csak a belső portokra veszem fel. A kimenő forgalom viszont marad a default VLAN-on, az engedve van a külső portokra is.

Ez egy elég beteg konfiguráció (nem nagyon dokumentálják sehol, néhány fórumban kérdezgettek ilyet, de sehol sincs rá válasz) tehát késztetést éreztem rá, hogy mindenképpen kipróbáljam. :)
Bonding és VLAN tagging együttes használata úgy támogatott, hogy a fizikai eth0-ethX iterfészeket először bond0 interfész alá kell rakni slave-nek, majd a taggelt forgalmat már a bond0-ról kell kifejteni önálló bond0.X intefészekre. Én ezt szándékosan fordítva akarom.

A sikertelen próbálkozásokat most kihagyom, a működő megoldás a következő:

# Legyen egy bond0 interfészünk, mode0 a round-robin loadbalance
modprobe bonding mode=0

# Fejtsük ki a VLAN-okat, jelen példában a 100-ast.
ip link add link eth0 name eth0.100 type vlan id 100
ip link add link eth1 name eth1.100 type vlan id 100

# Kössük be a vlan taggelt interfészt slave-nek a bond0 alá

ip link set dev bond0 up
ip link set dev eth0 up
ip link set dev eth1 up
ip link set dev eth0.100 down 
ip link set dev eth1.100 down
ip link set dev eth0.100 master bond0
ip link set dev eth1.100 master bond0

Bármennyire is értelmetlennek tűnik, az eth0.100 down kell, miközben az összes többi up, csak így sikerül az enslave művelet. Megpróbálja lehúzni, majd felhúzni a slave interfészt, feltehetően a MAC váltás miatt, ez csak akkor sikerül, ha a kezdeti állapotban fizikai interfész fel van húzva, a vlan taggelt viszont le, bármi más esetben "Network down", "Operation not permitted" és hasonló sokatmondó hibaüzeneteket kapunk.

Ezután már adhatunk két külön IP-t az eth0-nak és a bond0-nak.

Teszt:

dd if=/dev/zero bs=1k count=1M | nc -vv 192.168.40.100 5555 
Connection to 192.168.40.100 5555 port [tcp/*] succeeded!
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 9.12764 s, 118 MB/s

Hááát...
-tal nem kezdünk mondatot, de ezért kár volt ennyit küzdeni... ez bizony nem megy 1 Gbit fölé...

Pedig a két network interfészen láthatóan egyenletesen oszlott szét a forgalom, a switcheken is megnéztem, nem ment semmi rossz helyre.

A TCP tuningokkal kisérletezes következett, de megoldás végül innen jött.

Jumbo frame kell neki, minden más gyakorlatilag hatástalan.

Jumbo frame-et bondinggal összehozni nem is annyira nyilvánvaló. Normális esetben elég lenne ennyi, de persze nem megy:

ip link set dev bond0 mtu 9000
RTNETLNIK answers: Numerical result out of range

Hasonló a probléma, ha az mtu-t előbb állítjuk be, és utána akarjuk berakni a slave-eket. Az történik, hogy a slave interfészre is be akarja állitani az MTU-t (nyilván), viszont jelen esetben a VLAN-os interfész MTU-ja nem lehet nagyobb a fizikai interfész MTU-jánal, a beállitas oda már magától nem terjed tovább. Tehát előbb ezeket kell kézzel felvenni 9000-re, majd jöhet bondolt interfész.

ip link set dev eth0 mtu 9000
ip link set dev eth1 mtu 9000
ip link set dev bond0 mtu 9000

Újabb teszt, immár jumbo frame-ekkel:

root@ubuntu:~# dd if=/dev/zero bs=4k count=1M | nc -vv 192.168.40.100 5555
Connection to 192.168.40.100 5555 port [tcp/*] succeeded!
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 25.0714 s, 171 MB/s 

És már meg is van a hiányzó sebesség. Ugyan nem 2Gbit, de ez korábbi tapasztalatok alapján nagyjából várható is volt. A többi, TCP window, TX/RX buffer tuning inkább kicsit ront a helyzeten, mint javítana.

Egy kis további teszt, csak, hogy biztosak legyünk benne, hogy jól működnek a dolgok:

Először a kereten kívüli külső gép fele:

dd if=/dev/zero bs=4k count=1M | nc -vv 172.16.40.1 5555
Connection to 172.16.40.1 5555 port [tcp/*] succeeded!
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 41.0155 s, 105 MB/s 

Aztán a kereten belül, az eth0-ra felvett nem taggelt és nem bondolt címre:

dd if=/dev/zero bs=4k count=1M | nc -l 5555
1048576+0 records in
1048576+0 records out
4294967296 bytes (4.3 GB) copied, 37.9451 s, 113 MB/s 

Ha komoly packet loss lenne, akkor nem menne ilyen jól. De azért nézzük csak meg:

ping -f 172.16.40.1
PING 172.16.40.1 (172.16.40.1) 56(84) bytes of data.
.^C
--- 172.16.40.1 ping statistics ---
30569 packets transmitted, 30568 received, 0% packet loss, time 5293ms
rtt min/avg/max/mdev = 0.114/0.146/1.896/0.032 ms, ipg/ewma 0.173/0.142 ms

Hasonló a helyzet a blade-ek közt, kívülről, belülről. Vagyis mondhatjuk, hogy egész jól működik.

Ellenpróba: vajon mi történik, ha nem használjuk a VLAN-os leválasztást, minden forgalom round-robinnal szétszórva megy, beleértve a blade keretet elhagyót is?

A bondolt blade-ek egymás között hozzák ugyanezt a sávszélességet és a ping flood sem veszít csomagokat. Ez nem meglepő.

A kifelé menő forgalom is hozza ugyanezt a sávszélességet, ez viszont elég meglepő:

dd if=/dev/zero bs=1k count=1M | nc -vv 172.16.40.1 5555
Connection to 172.16.40.1 5555 port [tcp/*] succeeded!
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 9.36076 s, 115 MB/s

Nem lenne semmi packet loss?

ping -f 172.16.40.1
PING 172.16.40.1 (172.16.40.1) 56(84) bytes of data.
.^C
--- 172.16.40.1 ping statistics ---
27641 packets transmitted, 27640 received, +92 duplicates, 0% packet loss, time 4854ms
rtt min/avg/max/mdev = 0.112/0.148/1.219/0.036 ms, pipe 2, ipg/ewma 0.175/0.144 ms 

Loss nincs, de duplicate-ek vannak, bár elég kevesen. Igazából eléggé meglepő, hogy egy elvileg teljesen rossz konfiguráció mégis ennyire jól tud működni.

Mindenesetre a dupok jelenléte intő jel, úgyhogy láthatóan megéri a VLAN-nal leválasztani a potenciálisan problémás forgalmat a hálózat többi részéről.