Bonding

Siehe auch

Bonding Modes im Vergleich

Mode 0 (round-robin): Netzwerkpakete werden nacheinander über alle im Bond verfügbaren NICs gesendet - Paket 1 über die erste NIC, Paket 2 über die zweite NIC usw. Mode 0 bietet Fehlertoleranz und Load Balancing, kann aber nicht für Bridges verwendet werden, weswegen es nicht mit logischen Netzwerken für virtuelle Maschinen (also mit KVM oder oVirt) eingesetzt werden kann.
Mode 1 (active-backup): Eine Netzwerkkarte im Bonding-Set ist aktiv, die anderen warten im Stand-By auf ihren Einsatz. Verliert die aktive Netzwerkkarte die Verbindung, übernimmt eine der Backup-NICs. Die Bond-MAC-Adresse ist nur auf einem Port sichtbar. Mode 1 bietet Fehlertoleranz, wird seitens oVirt unterstützt und sollte dann gewählt werden, wenn der Switch kein IEEE 802.3ad kann.
Mode 2 (Load Balance, balance-xor): Für die Paketvermittlung wird diejenige Netzwerkkarte ausgewählt, die zu einem XOR auf Quell- und Ziel-MAC modulo der Anzahl der Slave-Netzwerkkarten passt. So wird immer die gleiche Netzwerkkarte für das gleiche Ziel verwendet. Mode 2 bietet Fehlertoleranz sowie Load Balancing und wird seitens oVirt unterstützt.
Mode 3 (Broadcast, broadcast): Alle Pakete über alle NICs versenden. Mode 3 bietet Fehlertoleranz und wird seitens oVirt unterstützt.
Mode 4 (IEEE 802.3ad, Dynamic Link Aggregation, LACP, 802.3ad): Setzt auf Aggregation Groups, in denen die NICs die gleichen Speed- und Duplex-Einstellungen besitzen. Mode 4 nutzt alle NICs in der aktiven Aggregation Group und wird seitens oVirt unterstützt. Setzt zwingend einen dafür passend konfigurierten Switch voraus. Kommen zwei Switche zum Einsatz, müssen diese MLAG-fähig konfiguriert werden.
Mode 5 (adaptive transmit load balancing, balance-tlb): Eine NIC empfängt den gesamten Traffic, auf allen anderen wird lastverteilt gesendet. Mode 5 kann nicht für Bridges verwendet werden, weswegen es nicht mit logischen Netzwerken für virtuelle Maschinen (also mit KVM oder oVirt) eingesetzt werden kann.
Mode 6 (adaptive load balancing, balance-alb): Kombiniert Mode 5 (adaptive transmit load balancing policy) mit einem Load-Balancing von IPv4-Traffic auf der Empfangsseite, ohne dass eine Switch-Konfiguration wie bei Mode 4 nötig ist. Das Load-Balancing auf der Empfangsseite wird mit ARP negotiation umgesetzt. Mode 6 kann nicht für Bridges verwendet werden, weswegen es nicht mit logischen Netzwerken für virtuelle Maschinen (also mit KVM oder oVirt) eingesetzt werden kann.

oVirt / RHEV verwendet standardmässig Mode 4 (IEEE 802.3ad).

GlusterFS wünscht sich standalone eingesetzt Mode 6 und nutzt dann jede NIC für parallele Schreibanforderungen, während in einem Hyperconverged-Setup mit oVirt immer Mode 4 eingesetzt werden muss.

Ein Bond kann nur 1 logisches non-VLAN-Netzwerk unterstützen. Alle weiteren Netze müssen eindeutige VLAN-IDs aufweisen.

Bonding mit nmcli konfigurieren (Mode 4)

BOND=bond0
IPADDR=192.168.122.102/24
GATEWAY=192.168.122.1
DNS=1.1.1.1
SLAVE1=ens1
SLAVE2=ens2

nmcli con add type bond ifname $BOND
nmcli con add type bond ifname $BOND bond.options "mode=802.3ad,miimon=100"

nmcli con mod bond-$BOND ipv4.addresses $IPADDR
nmcli con mod bond-$BOND ipv4.gateway $GATEWAY
nmcli con mod bond-$BOND ipv4.dns $DNS
nmcli con mod bond-$BOND ipv4.method manual

nmcli con add type ethernet ifname $SLAVE1 master bond-$BOND
nmcli con add type ethernet ifname $SLAVE2 master bond-$BOND

# activate the slaves
nmcli con up bond-slave-$SLAVE1
nmcli con up bond-slave-$SLAVE2

# activate the bond
nmcli con up id $BOND

Bonding klassisch konfigurieren (Mode 4, MTU=9000)

/etc/sysconfig/network-scripts/ifcfg-eno1

BOOTPROTO="none"
DEVICE="eno1"
MASTER="bond0"
MTU="9000"
NAME="eno1"
NM_CONTROLLED="no"
ONBOOT="yes"
SLAVE="yes"
UUID="abc...def"

/etc/sysconfig/network-scripts/ifcfg-eno2

BOOTPROTO="none"
DEVICE="eno2"
MASTER="bond0"
MTU="9000"
NAME="eno2"
NM_CONTROLLED="no"
ONBOOT="yes"
SLAVE="yes"
UUID="123...789"

/etc/sysconfig/network-scripts/ifcfg-bond0

AUTOCONNECT_SLAVES="yes"
BONDING_MASTER="yes"
BONDING_OPTS="mode=4 miimon=100"
BOOTPROTO="none"
DEVICE="bond0"
DNS1="..."
DNS2="..."
GATEWAY="10.80.32.1"
IPADDR="10.80.32.xx"
MTU="9000"
NAME="bond0"
NM_CONTROLLED="no"
ONBOOT="yes"
PREFIX="24"
TYPE="Bond"

systemctl restart network

Bonding klassisch konfigurieren (Mode 6, MTU=9000)

/etc/sysconfig/network-scripts/ifcfg-ens6f0

BOOTPROTO="none"
DEVICE="ens6f0"
MASTER="bond0"
MTU=9000
NAME="ens6f0"
NM_CONTROLLED="no"
ONBOOT="yes"
SLAVE="yes"
UUID="abc...def"

/etc/sysconfig/network-scripts/ifcfg-ens6f1

BOOTPROTO="none"
DEVICE="ens6f1"
MASTER="bond0"
MTU=9000
NAME="ens6f1"
NM_CONTROLLED="no"
ONBOOT="yes"
SLAVE="yes"
UUID="123...789"

/etc/sysconfig/network-scripts/ifcfg-bond0

BONDING_MASTER="yes"
BONDING_OPTS="mode=6 miimon=100"
BOOTPROTO="none"
DEVICE="bond0"
DNS1="..."
DNS2="..."
GATEWAY="10.80.32.1"
IPADDR="10.80.32.xx"
MTU=9000
NAME="bond0"
NM_CONTROLLED="no"
ONBOOT="yes"
PREFIX="24"
TYPE="Bond"

systemctl restart network

Bonding und MTU - Performance

Unsere Tests in einem 10 Gbit-Netz mit Hilfe von iperf3 ergeben einen klaren Vorteil beim Einsatz von Jumbo-Frames:

Sender MTU=1500, Empfänger MTU=1500: 9.38 Gbits/sec
Sender MTU=1500, Empfänger MTU=9000: 9.41 Gbits/sec
Sender MTU=9000, Empfänger MTU=1500: 9.39 Gbits/sec
Sender MTU=9000, Empfänger MTU=9000: 9.90 Gbits/sec

Built on 2024-04-18