Wie man Failover und Hochverfügbarkeitsnetzwerk-Bonding unter Linux konfiguriert
Dieses Tutorial erklärt, wie Sie die Netzwerkbindung auf einem Linux-Server konfigurieren. Bevor ich beginne, möchte ich erklären, was Netzwerkbindung ist und was sie bewirkt. 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.
Normalerweise ist es eine Best Practice und ein Muss, 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. Es gibt mehrere Bindungsmodi, die Sie in Ihrer Serverumgebung implementieren können. Nachfolgend finden Sie eine Liste der verfügbaren Modi und deren Funktionsweise:
- 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.
1. Vorbemerkung
Für dieses Tutorial verwende ich Oracle Linux 6.4 in der 32-Bit-Version. Bitte beachten Sie, dass die Konfiguration zwar unter Oracle Linux erfolgt, die Schritte aber auch für CentOS- und Red Hat OS-Distributionen sowie für 64Bit-Systeme gelten. Das Endergebnis unseres Beispielaufbaus wird zeigen, dass die Verbindung zu unserem Bonding-Server verbunden bleibt, obwohl ich 1 der Ethernet-Netzwerke deaktiviert habe. In diesem Beispiel werde ich zeigen, wie man Netzwerk-Bonding mit Modus 1 anwendet, der die Active-Backup-Richtlinie ist.
2. Installationsphase
Für diesen Prozess ist keine Installation erforderlich. Eine Standard-Linux-Installation eines Servers enthält alle erforderlichen Pakete für eine Netzwerk-Bonding-Konfiguration.
3. Konfigurationsphase
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. Nachfolgend finden Sie die Schritte:
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. Nachfolgend finden Sie die Schritte:
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
Dann lauf weg:
ls *ifcfg*bon*
Das Ergebnis ist:
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. Nachfolgend finden Sie die Schritte:
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 . Nachfolgend finden Sie die Schritte:
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. Nachfolgend finden Sie die Schritte:
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.
4. 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. Nachfolgend finden Sie die Schritte:
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. Nachfolgend finden Sie die Schritte:
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.