Link Aggregation/Bonding

Aus Foxwiki

topic kurze Beschreibung

Beschreibung

Failover und Hochverfügbarkeit

Netzwerkbindung auf einem Linux-Server konfigurieren
  • In einer Windows-Umgebung wird Network Bonding als Network Teaming bezeichnet
    • dies ist eine Funktion, die jeder Serverarchitektur hilft, Hochverfügbarkeit und Failover in Szenarien zu gewährleisten, in denen eines der wichtigsten Ethernet-Kabel eine Fehlfunktion hat oder falsch konfiguriert ist.
Best Practice
  • wenn Sie einen Server für Produktionszwecke einrichten.
  • Obwohl diese Funktion in einer Linux-Umgebungskonfiguration durchgeführt werden kann, müssen Sie dies jedoch zuerst mit Ihrem Netzwerkadministrator klären, um sicherzustellen, dass die mit Ihrem Server verbundenen Switches Unterstützung für die Netzwerkbindung bieten.

Verfügbaren Modi

Es gibt mehrere Bindungsmodi, die Sie in Ihrer Serverumgebung implementieren können.

Option Beschreibung
Balance-rr Dieser Modus bietet Lastausgleich und Fehlertoleranz (Failover) über die Round-Robin-Richtlinie. Bedeutet, dass es Pakete in sequentieller Reihenfolge vom ersten verfügbaren Slave bis zum letzten sendet.
Active-Backup Dieser Modus bietet Fehlertoleranzfunktionen über die Active-Backup-Richtlinie. Das bedeutet, dass nach dem Auflegen des Bonding-Ethernet nur noch 1 der Ethernet-Slaves aktiv ist. Der andere Ethernet-Slave wird nur dann aktiv, wenn und nur wenn der aktuell aktive Slave nicht aktiv ist. Wenn Sie diesen Modus wählen, werden Sie feststellen, dass die Bonding-MAC-Adresse von außen auf nur einem Netzwerkadapter sichtbar ist. Dies dient dazu, eine Verwechslung des Schalters zu vermeiden.
Balance-xor Dieser Modus bietet Lastausgleich und Fehlertoleranz. Es überträgt basierend auf der ausgewählten Sende-Hash-Richtlinie. Alternative Übertragungsrichtlinien können über die Option xmit_hash_policy ausgewählt werden.
Broadcast Dieser Modus bietet nur Fehlertoleranz. Es überträgt alles auf allen Slave-Ethernet-Schnittstellen.
802.3ad Dieser Modus bietet Lastausgleich und Fehlertoleranz. Es wird eine Aggregationsgruppe erstellt, die die gleichen Geschwindigkeits- und Duplexeinstellungen hat. Es nutzt alle Slave-Ethernet-Schnittstellen im aktiven Aggregator und basiert auf der 802.3ad-Spezifikation. Um diesen Modus zu implementieren, muss das Ethtool die Basistreiber unterstützen, um die Geschwindigkeit und den Duplexmodus jedes Slaves abzurufen. Der Switch muss auch die dynamische Link-Aggregation unterstützen. Normalerweise erfordert dies einen Eingriff des Network Engineers für eine detaillierte Konfiguration.
Balance-TLB Dieser Modus bietet Lastausgleichsmöglichkeiten, da der Name TLB für den Sende-Lastausgleich steht. Für diesen Modus, wenn die Konfiguration tlb_dynamic_lb = 1 ist, wird der ausgehende Verkehr entsprechend der aktuellen Last auf jeden Slave verteilt. Wenn die Konfiguration tlb_dynamic_lb = 0 ist, dann ist der Lastausgleich deaktiviert, jedoch wird die Last nur über die Hastverteilung verteilt. Für diesen Modus muss das Ethtool die Basistreiber unterstützen, um die Geschwindigkeit jedes Slaves zu ermitteln.
Balance-ALB Dieser Modus bietet Lastausgleichsmöglichkeiten, da der Name TLB für adaptiven Lastausgleich steht. Ähnlich wie balance-tlb, nur dass sowohl Sende- als auch Empfangsverkehr verbunden sind. Es erhält einen Lastenausgleich, indem es die ARP-Verhandlung erreicht. Der Bonding-Treiber fängt die vom lokalen System gesendeten ARP-Antworten auf ihrem Weg nach draußen ab und überschreibt die Quell-Hardwareadresse mit der eindeutigen Hardwareadresse eines der Slaves in der Bindung. Für diesen Modus muss das Ethtool die Basistreiber unterstützen, um die Geschwindigkeit jedes Slaves wiederherzustellen.

Anwendungen

Fehlerbehebung

Syntax

Optionen

Parameter

Umgebungsvariablen

Exit-Status

Konfiguration

  • Bevor wir mit der Konfiguration beginnen, müssen wir zunächst sicherstellen, dass wir mindestens 2 Ethernet-Schnittstellen in unserem Server konfiguriert haben.
  • Um dies zu überprüfen, gehen Sie in den Netzwerk-Konfigurationsordner und listen Sie die verfügbaren Ethernet-Schnittstellen auf.
cd /etc/sysconfig/network-scripts/
ls *ifcfg*eth*

Das Ergebnis ist: 

ifcfg-eth0 ifcfg-eth1

Beachten Sie, dass wir derzeit 2 Ethernet-Schnittstellen haben, die auf unserem Server eingerichtet sind, nämlich ETH0 und ETH1.

Lassen Sie uns nun eine Bonding-Schnittstelle namens BOND0 konfigurieren.

  • Diese Schnittstelle wird eine virtuelle Ethernet-Schnittstelle sein, die die physikalische Ethernet-Schnittstelle von ETH0 und ETH1 enthält.
vi ifcfg-bond0
DEVICE=bond0
ONBOOT=yes
MASTER=yes
IPADDR=172.20.43.110
NETMASK=255.255.255.0
GATEWAY=172.20.43.1
BONDING_OPTS="mode=1 miimon=100"
TYPE=Ethernet

ls *ifcfg*bon*

Ergebnis 

ifcfg-bond0

Das ist alles. Bitte beachten Sie, dass ich innerhalb der BOND0-Schnittstelle eine IP-Adresse angegeben habe.

  • Diese IP-Adresse ist die einzige IP-Adresse, die mit unserem Server verbunden ist.
  • Um damit fortzufahren, müssen wir die physikalische Ethernet-Schnittstelle in Bezug auf die BOND0-Schnittstelle modifizieren.
vi ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
MASTER=bond0
SLAVE=yes
vi ifcfg-eth1
DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
MASTER=bond0
SLAVE=yes

Erledigt

  • Wir haben die Modifikation der Schnittstelle ETH0 und ETH1 vorgenommen.
  • Beachten Sie, dass wir die IP-Adresse in beiden Interfaces entfernt und MASTER = bond0 angehängt haben.
  • Dies ist notwendig, um zu bestätigen, dass es sich bei beiden Schnittstellen um virtuelle Schnittstellen handelt, die für die Ethernet-BOND0-Schnittstelle bestimmt sind.
Um mit der Konfiguration fortzufahren

Erstellen wir eine bonding-Konfigurationsdatei namens bonding.conf unter /etc/modprobe.d 

vi /etc/modprobe.d/bonding.conf
alias bond0 bonding
options bond0 mode=1 miimon=100
modprobe bonding
Basierend auf der obigen Konfiguration haben wir ein Bindemodul über die Schnittstelle BOND0 konfiguriert
  • Wir haben die Bonding-Konfiguration auch dem Verwendungsmodus = 1 zugewiesen, der eine aktive Backup-Richtlinie ist.
  • Die Option miimon = 100 stellt die Überwachungsfrequenz für unseren Bonding-Server dar, um den Schnittstellenstatus in Millisekunden zu überwachen.
  • Wie oben beschrieben, bietet dieser Modus Funktionen zur Fehlertoleranz in der Konfiguration des Server-Netzwerks.

Da alles eingerichtet ist, starten wir den Netzwerkdienst neu, um die neue Konfiguration zu laden. 

service network restart
Shutting down interface eth0: [ OK ]
Shutting down interface eth1: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface bond0: [ OK ]
Ausgezeichnet, jetzt haben wir die neue Konfiguration geladen, die wir oben gemacht haben.
  • Sie werden feststellen, dass die neue Schnittstelle namens BOND0 in der Netzwerkliste angezeigt wird.
  • Sie werden auch feststellen, dass der Schnittstelle ETH0 und ETH1 keine IP-Adresse zugeordnet ist, sondern nur die BOND0-Schnittstelle die IP-Adresse anzeigt.
# ifconfig
bond0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
inet addr:172.20.43.110 Bcast:172.20.43.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe61:e488/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:1723 errors:0 dropped:0 overruns:0 frame:0
TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:147913 (144.4 KiB) TX bytes:108429 (105.8 KiB)
eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:103486 (101.0 KiB) TX bytes:105439 (102.9 KiB)
eth1 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:632 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44487 (43.4 KiB) TX bytes:3288 (3.2 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:208 errors:0 dropped:0 overruns:0 frame:0
TX packets:208 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18080 (17.6 KiB) TX bytes:18080 (17.6 KiB)
Sie können den Bindungsstatus auch über diesen Befehl überprüfen
cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:61:e4:88
Slave queue ID: 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:c8:46:40
Slave queue ID: 0

Beachten Sie dazu, dass wir die Schnittstellen ETH0 und ETH1 erfolgreich in eine Bonding-Konfiguration im Active-Backup-Modus umgewandelt haben. Es wurde auch angegeben, dass der Server die Schnittstelle ETH0 verwendet, ETH1 wird als Backup-Schnittstelle dienen.


Dateien

Sicherheit

Dokumentation

RFC

Man-Pages

Info-Pages

Siehe auch

Links

Projekt-Homepage

Weblinks

Einzelnachweise

Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5

TMP

Testphase

Jetzt, da alles wie erwartet konfiguriert ist. Lassen Sie uns einen einfachen Test durchführen, um sicherzustellen, dass die von uns vorgenommene Konfiguration korrekt ist. Für diesen Test melden wir uns bei einem neuen Server (oder Linux-Desktop) an und beginnen mit dem Pingen unseres Bonding-Servers, um zu sehen, ob während des Tests eine intermittierende Verbindung besteht. 

login as: root
root@172.20.43.120's password:
Last login: Wed Sep 14 12:50:15 2016 from 172.20.43.80
ping 172.20.43.110
PING 172.20.43.110 (172.20.43.110) 56(84) bytes of data.
64 bytes from 172.20.43.110: icmp_seq=1 ttl=64 time=0.408 ms
64 bytes from 172.20.43.110: icmp_seq=2 ttl=64 time=0.424 ms
64 bytes from 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms
64 bytes from 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms
64 bytes from 172.20.43.110: icmp_seq=5 ttl=64 time=0.554 ms
64 bytes from 172.20.43.110: icmp_seq=6 ttl=64 time=0.443 ms
64 bytes from 172.20.43.110: icmp_seq=7 ttl=64 time=0.663 ms
64 bytes from 172.20.43.110: icmp_seq=8 ttl=64 time=0.961 ms
64 bytes from 172.20.43.110: icmp_seq=9 ttl=64 time=0.461 ms
64 bytes from 172.20.43.110: icmp_seq=10 ttl=64 time=0.544 ms
64 bytes from 172.20.43.110: icmp_seq=11 ttl=64 time=0.412 ms
64 bytes from 172.20.43.110: icmp_seq=12 ttl=64 time=0.464 ms
64 bytes from 172.20.43.110: icmp_seq=13 ttl=64 time=0.432 ms

In dieser Zeit gehen wir zurück zu unserem Bonding-Server und schalten die Ethernet-Schnittstelle ETH0 aus. Nachfolgend finden Sie die Schritte. zuerst führen Sie ifconfig eth0 aus: 

ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:103486 (201.0 KiB) TX bytes:105439 (122.9 KiB)
ifdown eth0

Nun haben wir die Dienste für die Netzwerkschnittstelle ETH0 abgeschaltet. Lassen Sie uns den Bindungsstatus überprüfen. 

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:c8:46:40
Slave queue ID: 0

Sie werden feststellen, dass die ETH0-Schnittstelle nun nicht mehr im Bindungsstatus existiert. Während dieser Zeit gehen wir zurück zum vorherigen Testserver und überprüfen den kontinuierlichen Ping zu unserem Bonding-Server. 

64 bytes from 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms
64 bytes from 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms
64 bytes from 172.20.43.110: icmp_seq=24 ttl=64 time=0.437 ms
64 bytes from 172.20.43.110: icmp_seq=25 ttl=64 time=0.504 ms
64 bytes from 172.20.43.110: icmp_seq=26 ttl=64 time=0.401 ms
64 bytes from 172.20.43.110: icmp_seq=27 ttl=64 time=0.454 ms
64 bytes from 172.20.43.110: icmp_seq=28 ttl=64 time=0.432 ms
64 bytes from 172.20.43.110: icmp_seq=29 ttl=64 time=0.434 ms
64 bytes from 172.20.43.110: icmp_seq=30 ttl=64 time=0.411 ms
64 bytes from 172.20.43.110: icmp_seq=31 ttl=64 time=0.554 ms
64 bytes from 172.20.43.110: icmp_seq=32 ttl=64 time=0.452 ms
64 bytes from 172.20.43.110: icmp_seq=33 ttl=64 time=0.408 ms
64 bytes from 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms

Großartig, jetzt wirst du sehen, dass wir, obwohl wir die Schnittstelle ETH0 heruntergefahren haben, immer noch in der Lage sind, unseren Bonding-Server zu pingen und darauf zuzugreifen. Jetzt machen wir noch einen weiteren Test. Schalten Sie die ETH0-Schnittstelle wieder ein und die ETH1-Schnittstelle aus. 

ifup eth0
cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:c8:46:40
Slave queue ID: 0
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:61:e4:88
Slave queue ID: 0

Da die ETH0-Schnittstelle bereits hochgefahren war, schalten wir die ETH1-Schnittstelle aus. 

ifdown eth1
cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:61:e4:88
Slave queue ID: 0

Nun gehen wir zurück zum Testserver und überprüfen, was auf dem kontinuierlichen Ping zu unserem Bonding-Server passiert. 

64 bytes from 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms
64 bytes from 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms
64 bytes from 172.20.43.110: icmp_seq=86 ttl=64 time=0.401 ms
64 bytes from 172.20.43.110: icmp_seq=87 ttl=64 time=0.454 ms
64 bytes from 172.20.43.110: icmp_seq=88 ttl=64 time=0.432 ms
64 bytes from 172.20.43.110: icmp_seq=89 ttl=64 time=0.434 ms
64 bytes from 172.20.43.110: icmp_seq=90 ttl=64 time=0.411 ms
64 bytes from 172.20.43.110: icmp_seq=91 ttl=64 time=0.420 ms
64 bytes from 172.20.43.110: icmp_seq=92 ttl=64 time=0.487 ms
64 bytes from 172.20.43.110: icmp_seq=93 ttl=64 time=0.551 ms
64 bytes from 172.20.43.110: icmp_seq=94 ttl=64 time=0.523 ms
64 bytes from 172.20.43.110: icmp_seq=95 ttl=64 time=0.479 ms

Daumen hoch! Wir haben erfolgreich konfiguriert und bewiesen, dass unser Bonding-Server es schafft, das Disaster-Recovery-Szenario bei einem Netzwerkausfall zu erfüllen.

Abgerufen von „https://wiki.foxtom.de/index.php?title=Link_Aggregation/Bonding&oldid=52611“