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)
BOOTPROTO="none"
DEVICE="eno1"
MASTER="bond0"
MTU="9000"
NAME="eno1"
NM_CONTROLLED="no"
ONBOOT="yes"
SLAVE="yes"
UUID="abc...def"
BOOTPROTO="none"
DEVICE="eno2"
MASTER="bond0"
MTU="9000"
NAME="eno2"
NM_CONTROLLED="no"
ONBOOT="yes"
SLAVE="yes"
UUID="123...789"
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)
BOOTPROTO="none"
DEVICE="ens6f0"
MASTER="bond0"
MTU=9000
NAME="ens6f0"
NM_CONTROLLED="no"
ONBOOT="yes"
SLAVE="yes"
UUID="abc...def"
BOOTPROTO="none"
DEVICE="ens6f1"
MASTER="bond0"
MTU=9000
NAME="ens6f1"
NM_CONTROLLED="no"
ONBOOT="yes"
SLAVE="yes"
UUID="123...789"
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-09-30