Link Aggregation/Bonding: Unterschied zwischen den Versionen
Zeile 76: | Zeile 76: | ||
= TMP = | = TMP = | ||
== Testphase == | == 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. | 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. |
Version vom 29. Januar 2023, 12:38 Uhr
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
Dateien
Sicherheit
Dokumentation
RFC
Man-Pages
Info-Pages
Siehe auch
Links
Projekt-Homepage
Weblinks
Einzelnachweise
Testfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5
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.