Administrace komentářů

Tomu rikam pekna sbirka nepresnosti. Bonding pres LACP (mode 4) active-active provozujeme produkcne jiz nekolik oproti ruznym druhum switchu ruznych vyrobcu. Provozujeme take active-passive reseni, kde neni nutna podpora na switchich (zapojeni do dvou ruznych switchu). Z mych zkusenosti je pouziti LACPu nejvykonejsi, pouzivame parametry BONDING_OPTS="mode=802.3ad miimon=100 xmit_hash_policy=layer3+4", tj. jedna connection jde vzdy po jednom dratu, TCP offload engine by tedy mel byt v pohode. Je to ale spravna pripominka, pri jinych typech to muze ve skutecnosti uskodit. Mame takto zteamovano jak 1Gbit rozhrani, tak napriklad i 4x10Gbit mezi switchi. V jednodusich nastavenich se zapojuji 2 a vice kabelu do jednoho switche, pro nej je to virtualni interface, problemy s ucenim MAC (v MAC tabulce nikoliv ARP tabulce) tedy nema. Pri pouziti chytrejsich switchu, typicky Nexus rady 5000 a vys, ale beha to i na IBM G8124 switchich lze delat active-actve LACP pres dva switche, tj. docilit jak zvyseni propustnosti, tak dostupnost. Vyzaduje si to ale specialni spojeni techto switchu. U Nexusu tomu rikaji VPC (virtual PortChannel). Toto zapojeni take bez problemu provozujeme. Existuji i typy bondingu, ktere podporu switchu nepotrebuji, tam se jiz opravdu musi zonglovat s MAC adresy a napr. jinak odpovidat na ARP dotazy. S tim prilis velkou zkusenost nemam, AFAIK se to i defaultne ale pouziva pri NIC teamingu ve vmwaru esxi 5, coz ale pak koliduje s pouzitim bridgu ve virtualnich masinach. Souhlasim ale s tim, ze neco si o tom nacist neni spatne. Kazdopadne bych se toho nebal.

Cele je to pekne popsane v /usr/src/linux/Documentation/networking/bonding.txt (ve zdrojacich kernelu).