linux ethernet bonding

Linux-haladó

Üdv mindenkinek,

Kísérleti jelleggel szeretném kipróbálni az ethernet bonding-ot.Jelenleg a következő a helyzet:

- test1 szerver 2x Intel Corporation 82576 Gigabit
- test2 szerver 2x Broadcom Corporation NetXtreme BCM5721 Gigabit
- Linksys SRW2048 switch 24 port Gigabit

- Mindkét szerveren létrehoztam a (eth1,eth2)-> bond0 hálózati eszközöket mode=4 (802.3ad) szerint.
- A switch-en szintén össze vannak kötve a port párok IEEE 802.3ad Dynamic link aggregation szerint.

Az adatátvitel megy a gépek között (bond0<->bond0) de csak egyszeres Gigabit sebességgel. (~110MByte/sec) 


# Transmitter 10.0.1.1
dd if=/dev/zero bs=10k count=102400 | nc -l p

# Receiver 10.0.2.1
nc 10.0.2.1 10000 | pv -b >/dev/null

ifconfig szerint is csak az egyik slave hálózati eszközön ment keresztül az adat 


bond0     Link encap:Ethernet  HWaddr 00:1e:0b:5a:a2:e9  
          inet addr:10.0.2.1  Bcast:10.255.255.255  Mask:255.0.0.0
          inet6 addr: fe80::21e:bff:fe5a:a2e9/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:53318 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3985612 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4935280 (4.7 MiB)  TX bytes:263100254 (250.9 MiB)

eth0      Link encap:Ethernet  HWaddr 00:1e:0b:5a:a2:e8  
          inet addr:172.16.2.202  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::21e:bff:fe5a:a2e8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8002809 errors:0 dropped:0 overruns:0 frame:0
          TX packets:751 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12095476780 (11.2 GiB)  TX bytes:102508 (100.1 KiB)
          Interrupt:16 

eth1      Link encap:Ethernet  HWaddr 00:1e:0b:5a:a2:e9  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:27591 errors:0 dropped:0 overruns:0 frame:0
          TX packets:819 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2577904 (2.4 MiB)  TX bytes:87648 (85.5 KiB)
          Interrupt:17 

eth2      Link encap:Ethernet  HWaddr 00:1e:0b:5a:a2:e9  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:25727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3984793 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2357376 (2.2 MiB)  TX bytes:263012606 (250.8 MiB)
          Memory:dc220000-dc240000

- A kérdésem az lenne, hogy csinált már valaki ilyet?
- Mit rontok el, hogy nem növekszik az átviteli sebesség? Egyáltalán kellene, hogy bond0<->bond0 esetén a duplája legyen?

A válaszokat előre is köszönöm.

  • 2211 megtekintés

( athila v | 2010. 05. 25., k – 14:11 )

Szerintem semmit, ha ez a linuxos "bonding" is olyan, mint a ciscós port-channel és társai,
akkor ez csak per mac-address szerinti load sharinget fog tudni produkálni.
Vagyis működik ez, de csak 50+ kliensnél fogod látni... :)

( vl v | 2010. 05. 25., k – 15:02 )

RTFM

/usr/src/linux/Documentation/networking/bonding.txt:


mode
802.3ad or 4
Slave selection for outgoing traffic is done according
to the transmit hash policy, which may be changed from
the default simple XOR policy via the xmit_hash_policy
option, documented below. Note that not all transmit
policies may be 802.3ad compliant, particularly in
regards to the packet mis-ordering requirements of
section 43.2.4 of the 802.3ad standard. Differing
peer implementations will have varying tolerances for
noncompliance.

xmit_hash_policy

Selects the transmit hash policy to use for slave selection in
balance-xor and 802.3ad modes. Possible values are:

layer2

Uses XOR of hardware MAC addresses to generate the
hash. The formula is

(source MAC XOR destination MAC) modulo slave count


This algorithm will place all traffic to a particular
network peer on the same slave.

This algorithm is 802.3ad compliant.

The default value is layer2. This option was added in bonding
version 2.6.3. In earlier versions of bonding, this parameter
does not exist, and the layer2 policy is the only policy. The
layer2+3 value was added for bonding version 3.2.2.

a lényeg hogy 1-1 mac address közt nem lesz 2Gbit mivel mac-addressenként választja szét szóval pont-pont nem lesz jó.
Ha van 4Gbited bondingolod egy switchen és arra a switchre rátolsz 4 db gépet 1-1 Gbittel akkor talán kihajtható a 4gbit, de 2 géppel mivel 2 macről jön csak 2 gbit lesz :>
Kb ez lenne.

Ubuntu 10.04, Thinkpad x60s

egy ip címhez egy arp bejegyzés tartozhat, ezért amikor felépül a forgalom, lefixálódik egy mac cím. Azt pedig utána mindig egy interfészen küldi ki.

A problémád magja az, hogy az ethernet elvileg sorrendtartó közeg, tehát ha egy gép sorban adja a csomagokat, azok érkezési sorrendje nem térhet el a feladási sorrendtől. Viszont ha több interfészen öntöd a switchbe a csomagokat, elvileg előfordulhatna, hogy valamelyiket hamarabb tolja át a backplane-n, mint a másik interfészen, korábban feladott csomagot, ezért borul a sorrend.
Ennek megakadályozására csinálják, hogy mac címek szerint terhelik az interfészeket.

...
És ennek alapvetően architekturális oka van: ha egyazon TCP forgalom csomagjait elkezded felváltva átlökdösni a két dróton, biztos lehetsz benne, hogy rendszeresen egy-egy csomag később fog megérkezni, mint az utána indított (de a másik drótra kerülő) csomag. Ezt pedig a TCP azzal fogja "díjazni", hogy mondjuk 0.5-1 másodpercre megakad, visszaszabályozza a sebességet, néha egyes csomagokat újraküld, majd csak szépen lassan kezdi visszaemelni a sebességet (miközben a drótok üresen várnak). Így a két drót szumma sebessége kevesebb lesz, mint ha csak egyet használnál, ráadásul ez tök egyenetlen lesz.

Na ezért csinálták ilyenre a bondingot.

( maszili | 2010. 05. 26., sze – 15:50 )

Köszönöm mindenkinek a segítséget.

--
maszili

( maszili | 2010. 05. 27., cs – 10:11 )

Még annyit hozzátennék a dologhoz, hogy mégis lehet növelni az átviteli sebességet, ha a hálózati eszközöket páronként külön switch-be (vagy különálló vlan) dugjuk és mode=balance-rr módon fogjuk ösze a hálózati eszközöhet. Ezzel a módszerrel ~160MByte/sec átviteli sebességet sikerült elérni.

Ebben az esetben mi a helyzet a "csomagok sorrendje" miatti korláttal? Miszerint a csomagok sorrenjének megváltozása miatt nem működhet a dolog. Mert ebben az esetben mindkét eszközön mennek az adatok (Gbit fizikai korlátja 125MB/s) és azok rendben (helyes sorrendben) megérkeznek a fogadó oldalra.

--
maszili