bonding agybaj

Hálózatok általános

Sziasztok,

adott 3 gépen 3-3 interface; mindegyik gigabites uplinken van; ugyanazon switchen eléggé egyező konfiggal.
Az egyik kiszolgáló minden probléma nélkül használja a bonding drivert balance-tlb (5) módban; a többi nem.
Probléma:
Az első gépen 3 G/sec a bonding sebessége, míg a másik kettőn csak 1.

Mi okozhat szerintetek ilyen működést? A másik kettőn sem jelentkezik ugyanis hiba, a szó szoros értelmében, de képtelen kihajtani az interface-ket (iperf,jnettop szerint is). dmesg -ben semmi.

A 0,5,6 módban ugyanaz az eredmény.

Előre is köszi a válaszokat :)

  • 7426 megtekintés

( uid_7086 | 2013. 12. 25., sze – 14:09 )

Hülye ötlet, de míg nincs valakinek jobb: azt ugye ellenőrizted, hogy a két hibásan működő gépen az interface-ek önmagukban működőképesek és 1000mbit full-duplex módban mennek?

Igen, az uplinkek rendben mennek, csak épp nem nagyon szeretek routinggal, meg dns round-robinnal szívózni. Ez már nagyon régóta fennálló dolog, s szeretnék pontot tenni a végére.

A konfigok rendre így néznek ki:

ifconfig:

auto bond0
iface bond0 inet static
slaves eth0 eth2 eth3
address x.x.x.x
netmask 255.255.255.0
gateway x.x.x.x
bond-mode balance-tlb
bond-miimon 100

auto eth0
iface eth0 inet manual

auto eth2
iface eth2 inet manual

auto eth3
iface eth3 inet manual

/etc/modprobe.d/bonding.conf:
alias bond0 bonding
options bonding mode=5

###
uname -a:
Linux machine-a 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux

( XMI | 2013. 12. 25., sze – 23:51 )

Kb 100 kérdés van, amire tudni kéne a választ:

- Ki(k) között van meg a 3gbit/s az első gépen?
- Hány kapcsolat megy egyszerre?
- Mi volt a mérési módszer? Gondolom tisztában vagy vele, hogy az egyes üzemmódok nagyon eltérő körülmények között tudnak csak hatásosak lenni.
- A mérés végeztével az egyes fizikai interfészek forgalomszámlálója mit mutatott?

- A switchen milyen konfig van?
- Van LACP, statikus trunking vagy valami hasonló beállítva?
- Xmit hash mode beállítás milyen?
- Azt sem ártana tudni egyáltalán miféle switchről van szó.

- MTU milyen?
- Jumbo frame van?
---
Régóta vágyok én, az androidok mezonkincsére már!

Nahh, van feladat :)

"- Ki(k) között van meg a 3gbit/s az első gépen?
- Hány kapcsolat megy egyszerre? "
--Publikus hálózatról van szó, így a végpontok száma 4k körül van egyszerre; alapból min 3*500 mbit/sec forgalommal, amire még egy másik eszközön hozzácsaptam egy iperfet.

"- Mi volt a mérési módszer? Gondolom tisztában vagy vele, hogy az egyes üzemmódok nagyon eltérő körülmények között tudnak csak hatásosak lenni."
--a mérést iperf-el végeztem, 5 alkalommal, 60sec intervallumban; a végpontokon publikus kiszolgálás miatt nem tudtam mérni; az eredmény mégis szignifikáns volt, mivel:
0.0-60.0 sec 5.90 GBytes 844 Mbits/sec < ez a "jól működő" kapcsolat sebessége
0.0-60.0 sec 1.13 GBytes 162 Mbits/sec < ez a "nem jól működő" kapcsolat sebessége
Utóbbinál hozzátenném, hogy ennyi hiányzott ez idő alatt a2 1 gbit/sec -hez, mivel a váltást követően lassan kapcsolódnak vissza a kliensek.

-MTU 1500 minden esetben
-Jumbo frame alapbol nincs használatban

-A switcheink (Cisco Catalyst 3560G-48TS) üzemeltetését a szolgáltató végzi, publikus irányban (magenta); szerintük nincs probléma, ugyanakkor a konfighoz abszolute nem férünk hozzá, bérelt eszközökről van szó; a belső hálózatunkat magunk manageljük, saját eszközökön (és az itt nem is érintett) :)

-Konfigot próbálom beszerezni, kb veszett fejsze nyele :)

Elvileg nem hagytam ki semmit.

Update:
Annyi mondjuk most eszembe jutott, hogy az érintett switchportokat megvizsgáltatom, egyezik -e a konfigjuk. :)

Huhh, hát ez sajnos kicsit bonyolultabb, mint gondoltam. Ilyen felállásban tényleg nehéz lesz nyomozni.

A sok végpont mindenképpen jó.

Az lenne érdekes még, hogy a nem jól működő esetben van-e kitüntetett ethX interfész, amelyiken a TX vagy RX gyanúsan kiemelkedően sok, miközben a többin alig van. Ezen a nyomon legalábbis el lehet indulni.

Ha az RX koncentrálódik egy interfészre, akkor switch a ludas és nem sokat tudsz tenni ellene.
Ha a TX gyűlik egy interfészre, akkor viszont van esély a bond driverben a tx_hash_policy állítgatással.
Ha viszont a TX eloszlik egyenletesen, de az összeg mégsem tud 1Gbit fölé menni, akkor a switch belül egyesíti a forgalmat egy portra (kérdés: lehet tudni, hogy a switch uplinkje hogy van megoldva?)

Még egy kérdés: lehetséges, hogy a cisco mellesleg routerként is funkcionál? Akkor előfordulhat, hogy az összes bejövő kapcsolat ugyanazzal a forrás MAC-kel érkezik, és a hash policy olyankor ugyanarra az interfészre fogja kötni őket. Ha a forrás IP-t is beveszed a hash policy-be, akkor esélyes, hogy jó lesz.

Esetleg, ha érdekel nézd meg, hogy round robin modeban nekem mit kellett csinálnom, hogy működjön: http://hup.hu/node/128570. A Vlan-os rész nem most érdekes, a jumbo frame beállítás viszont fontos lehet.
---
Régóta vágyok én, az androidok mezonkincsére már!

Routerként elméletileg biztosan nem funkcionál; ami előtte van, az két 4900 -as, illetve 4950 -es, de ebben már nem vagyok fix; blackbox effektus (operátoroknak sincs hozzáférésük, csak a NOC -nak, csakúgy, mint az általunk bérelt eszközökhöz - konkrétan még egy mac lista sem elérhető).

Elméletileg Jumbo Frame engedélyezett (9000 -es mtu-val tesztelve nem volt packet loss), de mi 1500 -as MTU -t használtunk fixen - ha nem muszaj, nem konfigolok szet semmit :).

"Ha viszont a TX eloszlik egyenletesen, de az összeg mégsem tud 1Gbit fölé menni, akkor a switch belül egyesíti a forgalmat egy portra (kérdés: lehet tudni, hogy a switch uplinkje hogy van megoldva?)" <-- ez esélyes, de nem nagyon játszhatok most vele sokat tesztképpen, mert egyrészt állítólag magentáék nézegetik, mi a katyvasz, nem akarok belekavarni; másrészt éles kiszolgálás megy, amit nem nagyon akarnék a kelleténél sokkal tovább ba..kurálni.

( sibike | 2013. 12. 26., cs – 09:26 )

sar -n DEV 1 mit mond a jól működő ill a rosszul működő node-ok esetén?

( wladek1 | 2013. 12. 26., cs – 10:02 )

Kezd körvonalazódni, hogy valami a switchekben van elk.ve, mert pl. két különböző switchen lógó gép között is képtelen vagyok normális tempót kicsikarni, úgy, hogy mindeközben csomagvesztés sincs.

Azért ennél egy kicsit nagyobb a redundancia és a sávszélesség. A topologia valahol megvan, de nagyon nehezen keresném most elő, pedig szép színes-szagos :)
Ahol fixen működött, az a meglévő forgalom (külső ügyfelek, kb. 1.5 gbit) + ugyanarra a switchre kötött másik eszközön elinditott iperf. ezzel 2.2-2.5 gbit -ig ki lehetett hajtani.

Az érdekesebbik része:
Ha a másik switchen lévő eszközre lett iperf -el tolva a cucc, akkor a teljes sávszélesség limitálódott 1gbit/sec -ben (és a limitáció érintette az addig meglévő 1.5gbit/sec külső forgalmat is, tehát az _egész_ forgalom 1gbit/sec -ig(!!!) ment, s ez volt a plafon)