Linux LACP bonding: konfigurálás, ellenőrzés és hibaelhárítás

A Linux LACP bonding több Ethernet-interfészt egyesít egyetlen logikai kapcsolattá, így nagyobb összesített sávszélességet és automatikus átállást biztosít a fizikai hálózati kártyák között. Az IEEE 802.3ad szabványt használja, amelynek keretében mindkét fél (szerver és kapcsoló) egyezteti, mely kapcsolatok aktívak és hogyan oszlik el a forgalom. Ez a bejegyzés bemutatja, hogy mit is csinál valójában az LACP, mikor érdemes ezt választani a többi Linux bonding mód helyett, hogyan kell konfigurálni egy modern Linux szerveren, és hogyan lehet ellenőrizni, hogy működik-e.

Mi az a linkaggregáció és az LACP?

A linkaggregáció több fizikai hálózati kapcsolatot egyesít egy logikai csatornába. Két célt szolgál: növeli a linkcsoport teljes rendelkezésre álló sávszélességét, és automatikus átállást biztosít, ha bármelyik taglink leáll.

Az LACP (Link Aggregation Control Protocol) az IEEE 802.3ad szabványban meghatározott link-aggregáció dinamikus változata. Ahelyett, hogy mindkét végén statikus konfigurációra támaszkodna, az LACP LACPDU nevű vezérlőcsomagokat cserél a szerver és a kapcsoló között. A két fél egyezteti, mely kapcsolatok csatlakoznak az összevonáshoz, figyelemmel kíséri az egyes kapcsolatok állapotát, és a körülmények változásával tagokat vesz fel a csoportba vagy távolít el onnan.

Linux környezetben az LACP a kernel bonding illesztőprogram 4. módjaként (802.3ad) fut. Az illesztőprogram létrehoz egy logikai interfészt (jellemzően bond0), amely az IP-címet birtokolja, míg a fizikai interfészek, mint például eth0 és eth1 a kötés alárendeltjeivé válnak. Az operációs rendszer szempontjából egyetlen hálózati interfész létezik. A vezeték szempontjából több párhuzamos Ethernet-kapcsolat létezik.

Néhány dolog, amit az LACP kifejezetten nem csinál, de amit az emberek gyakran elvárnak:

• Egyetlen TCP-kapcsolat továbbra is egyetlen fizikai kapcsolaton halad át. Az LACP a forgalmat egyenlíti ki, nem pedig a forgalmon belüli csomagokat. Két összekapcsolt 1 GbE-kapcsolat nem teszi gyorsabbá az egyes letöltéseket 1 Gbps-nál.
• A LACP-hez 802.3ad-t támogató kapcsolóra van szükség. Nem képez kötést nem kezelt vagy nem LACP-kompatibilis kapcsolóval.
• Minden tagkapcsolatnak azonos sebességgel és duplex módban kell működnie. Nem lehet összekapcsolni egy 1 GbE portot egy 10 GbE porttal.

Linux bonding módok: mikor érdemes használni az LACP-t

A Linux bonding illesztőprogram hét módot támogat. A legtöbb termelési környezetben a három közül az egyiket használják.

1. mód: aktív-tartalék

Egy tag interfész aktív, a többi tétlen. Ha az aktív meghibásodik, egy másik néhány száz milliszekundumon belül átveszi a feladatot. Nincs szükség kapcsolókonfigurációra, ami miatt ez a megfelelő választás, ha a kapcsolók az Ön ellenőrzésén kívül vannak, vagy nem támogatják az 802.3ad szabványt. Redundanciát kap, de nincs extra sávszélesség.

4. mód: 802.3ad (LACP)

Minden tag továbbítja a forgalmat. A bonding illesztőprogram és a kapcsoló az LACP-t használja az aktív készlet kialkudására és a meghibásodások észlelésére. A kimenő forgalom az Ön által konfigurált hash-szabály alapján oszlik meg a tagok között. Ez a szokásos választás a menedzselt kapcsolókhoz csatlakozó dedikált szerverek esetében, ha redundanciát és további sávszélességet is szeretne többáramlású munkaterhelésekhez.

6. mód: balance-alb

Adaptív terheléselosztás mindkét irányban, kapcsoló támogatás nélkül. Az illesztőprogram elfogja az ARP-válaszokat, hogy átírja a MAC-címeket és elossza a bejövő forgalmat. Működik, de az LACP-hez képest bizonytalan. Csak akkor használja, ha a kapcsoló oldalának konfigurálása valóban lehetetlen.

Döntési szabály:

• Nincs menedzselt kapcsoló, vagy csak failoverre van szükség: 1. mód (active-backup).
• Kezelhető kapcsoló, több áramlás, sávszélességre és redundanciára is szükség van: 4. mód (LACP).
• Kezelhető kapcsoló használata lehetetlen, de mindkét irányban kiegyensúlyozásra van szükség: 6. mód (balance-alb).

A 0 (balance-rr), 2 (balance-xor), 3 (broadcast) és 5 (balance-tlb) módok léteznek, de modern hardverek esetén ritkán jelentik a megfelelő választást. Válassza az 1. vagy a 4. módot, hacsak nincs konkrét oka arra, hogy ne tegye.

LACP-összekapcsolás konfigurálása Linuxon

A modern Ubuntu és Debian rendszereken az LACP a netplan segítségével konfigurálható. RHEL, CentOS Stream, AlmaLinux és Rocky Linux rendszereken használja a NetworkManager-t nmcli vagy az alapul szolgáló kapcsolati fájlok szerkesztésével.

Netplan (Ubuntu, Debian)

Helyezze be a következőket a /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

Ezután alkalmazza a netplan apply. A legfontosabb paraméterek:

• mode: 802.3ad engedélyezi az LACP-t.
• lacp-rate: fast másodpercenként küld LACPDU-kat az alapértelmezett 30 másodperc helyett. Meg kell egyeznie a kapcsoló beállításával.
• mii-monitor-interval: 100 100 ms-enként lekérdezi a kapcsolat állapotát.
• transmit-hash-policy: layer3+4 az adatforgalmat forrás/cél IP-cím és TCP/UDP-port szerint osztja el. Ez jobb kiegyensúlyozást eredményez, mint az alapértelmezett layer2 szabályzatnál a tipikus webes és adatbázis-forgalom esetében.

NetworkManager (RHEL, AlmaLinux, Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

Kapcsoló oldal

A kapcsolónak szüksége van egy LAG-csoportra (gyakran port-csatornának nevezik), amely LACP aktív módra van konfigurálva, és ugyanannyi tagporttal rendelkezik, mint a kötés. A pontos szintaxis gyártónként eltérő, de a követelmények nem: a portoknak ugyanabban a VLAN-ban kell lenniük, ugyanarra a sebességre és duplexre kell beállítani őket, és legalább az egyik oldalon LACP aktív módot kell használniuk. A legbiztonságosabb beállítás, ha mindkét oldal aktív.

Cisco IOS esetén:

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

Aruba/ProCurve rendszeren:

trunk 1-2 trk1 lacp

A lacp_rate kapcsolón lévő beállításnak meg kell egyeznie a gazdagéppel. Az eltérés itt az egyik leggyakoribb LACP-konfigurációs hiba, és 30 másodpercenkénti időszakos flappinget okoz.

A LACP ellenőrzése és hibaelhárítása

Ellenőrizze a kötés aktuális állapotát a Linux oldalon:

cat /proc/net/bonding/bond0

Négy dologra kell figyelni a kimenetben:

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation megerősíti, hogy a 4. mód betöltődött.
2. Minden alárendelt interfész, amely MII Status: up és link failure count: 0.
3. A nullától eltérő Partner Mac Address érték minden alárendelt esetében. Ha itt minden érték nulla, az azt jelenti, hogy a kapcsoló egyáltalán nem küld LACP-csomagokat, vagy azért, mert a port nem egy LACP-aktív LAG-ban van, vagy azért, mert a kábel a rossz portba van dugva.
4. Aggregator ID minden tagon azonos. Az eltérő azonosítók azt jelentik, hogy a tagok valójában nincsenek összekapcsolva, hanem függetlenül működnek.

A sávszélesség használatának leggyorsabb ellenőrzése az, ha az iperf3 programot több párhuzamos adatfolyammal (iperf3 -P 8) egy másik gazdagépről. Ha a teljes átviteli sebesség meghaladja egy adott kapcsolat kapacitását, akkor a LACP megfelelően egyensúlyoz. Az egycsatornás teszt, amely egy kapcsolat sebességét mutatja, várható viselkedés, nem hiba.

A leggyakoribb LACP-problémák és azok okai:

• A partner MAC-címe teljesen nulla: a kapcsolóport nem tartozik egy LACP-aktív LAG-hez, vagy a kábelek rosszul vannak összekötve.
• A kötés létrejön, de az átviteli sebesség egy kapcsolaton ragad: a hash-szabály valószínűleg alapértelmezés szerint layer2, amely csak a cél MAC-cím alapján végez hash-t. Váltson layer3+4.
• 30 másodpercenkénti szakaszos flapping: lacp_rate eltérés a gazdagép és a kapcsoló között.
• Az egyik alárendelt működik, de a másik soha nem továbbít forgalmat: sebesség/duplex eltérés, vagy a kapcsolóportok nem ugyanabban a LAG-csoportban vannak a kapcsoló oldalán.

Amikor a LACP nem a megfelelő megoldás

Az LACP egy konkrét problémát old meg: több kapcsolat összevonását egy gazdagép és egy kapcsoló (vagy egy kapcsolócsomag) között a redundancia és az áramlásonkénti sávszélesség elérése érdekében. Vannak olyan esetek, amikor ez nem a megfelelő eszköz.

Ha csak redundanciára van szükség, és a kapcsolók nem támogatják az 802.3ad szabványt, akkor inkább az 1. módot (aktív-tartalék) használja. Ez minden esetben működik.

Ha két különálló kapcsoló között kell összekapcsolást létrehozni a házszintű redundancia érdekében, a szabványos LACP nem fogja összekötni a két egymástól független kapcsolót. Ilyenkor a Multi-Chassis Link Aggregation (MLAG) szükséges, amelynek keretében két kapcsoló egyetlen logikai LACP-partnerként jelenik meg. A legtöbb vállalati kapcsológyártó saját néven valósítja meg ezt: Cisco vPC, Arista MLAG, Juniper MC-LAG.

Ha egyetlen adatfolyamnak meg kell haladnia egy kapcsolat sávszélességét, a LACP erre nem képes. A lehetőségek a következők: gyorsabb fizikai kapcsolat használata (2x 10 GbE helyett 1x 25 GbE vagy 1x 40 GbE), vagy egy teljesen más technológia használata. Az SR-IOV közel vonali sebességű, egyetlen adatfolyamú teljesítményt biztosít a virtuális gépek számára azáltal, hogy minden virtuális gépnek hardveresen gyorsított virtuális hálózati kártyát biztosít, de ez egy másik problémát old meg, és saját korlátai vannak. Ez egy külön bejegyzés témája.

A legtöbb dedikált és kolokációs szerver esetében, amelyek sok egyidejű kapcsolatot kezelnek, a LACP marad a standard megoldás. Két összekapcsolt 10 GbE kapcsolat layer3+4 hashing segítségével kényelmesen kezelik a több mint 18 Gbps összesített forgalmat számos adatfolyamon keresztül, miközben egy hálózati kártya vagy kábel meghibásodását is kibírják anélkül, hogy egyetlen csomagot is elveszítenének.