So konfigurieren Sie Failover und Hochverfügbarkeits-Netzwerk-Bonding unter Linux

Dieses Tutorial erklärt, wie man Netzwerk-Bonding auf einem Linux-Server konfiguriert. Bevor ich beginne, lassen Sie mich erklären, was Netzwerk-Bonding ist und was es bewirkt. In einer Windows-Umgebung wird Netzwerk-Bonding als Netzwerk-Teaming bezeichnet, dies ist eine Funktion, die jeder Serverarchitektur hilft, hohe Verfügbarkeit und Failover in Szenarien zu bieten, in denen eines der Haupt-Ethernet-Kabel eine Fehlfunktion hat oder falsch konfiguriert ist.

Normalerweise ist es eine bewährte Methode und eine unverzichtbare Funktion, die implementiert werden muss, wenn Sie einen Server für Produktionszwecke einrichten. Obwohl diese Funktion auch in einer Linux-Umgebung konfiguriert werden kann, müssen Sie zunächst mit Ihrem Netzwerkadministrator bestätigen, dass die Switches, die mit Ihrem Server verbunden sind, Unterstützung für Netzwerk-Bonding haben. Es gibt mehrere Bonding-Modi, die Sie in Ihrer Serverumgebung implementieren können. Nachfolgend finden Sie eine Liste der verfügbaren Modi und was sie bewirken:

Balance-rr
Dieser Modus bietet Lastenausgleich und Fehlertoleranz (Failover) über eine Round-Robin-Politik. Das bedeutet, dass er Pakete in der Reihenfolge von dem ersten verfügbaren Slave bis zum letzten überträgt.
Active-Backup
Dieser Modus bietet Fehlertoleranzfunktionen über eine Active-Backup-Politik. Das bedeutet, dass, sobald das Bonding-Ethernet aktiv ist, nur einer der Ethernet-Slaves aktiv ist. Der andere Ethernet-Slave wird nur aktiv, wenn der derzeit aktive Slave nicht mehr aktiv ist. Wenn Sie diesen Modus wählen, werden Sie feststellen, dass die Bonding-MAC-Adresse extern nur auf einem Netzwerkadapter sichtbar ist. Dies soll Verwirrung beim Switch vermeiden.
Balance-xor
Dieser Modus bietet Lastenausgleich und Fehlertoleranz. Er überträgt basierend auf der ausgewählten Übertragungs-Hash-Politik. Alternativen Übertragungsrichtlinien können über die Option xmit_hash_policy ausgewählt werden.
Broadcast
Dieser Modus bietet nur Fehlertoleranz. Er überträgt alles über alle Slave-Ethernet-Schnittstellen.
802.3ad
Dieser Modus bietet Lastenausgleich und Fehlertoleranz. Er erstellt eine Aggregationsgruppe, die die gleichen Geschwindigkeits- und Duplexeinstellungen teilt. Er nutzt alle Slave-Ethernet-Schnittstellen im aktiven Aggregator und basiert auf der 802.3ad-Spezifikation. Um diesen Modus zu implementieren, muss das ethtool die Basis-Treiber unterstützen, um die Geschwindigkeit und den Duplexmodus jedes Slaves abzurufen. Der Switch muss auch dynamisches Link-Aggregation unterstützen. Normalerweise erfordert dies das Eingreifen eines Netzwerkingenieurs für eine detaillierte Konfiguration.
Balance-TLB
Dieser Modus bietet Lastenausgleichsfunktionen, wie der Name TLB Transmit Load Balancing darstellt. Für diesen Modus, wenn die Konfiguration tlb_dynamic_lb = 1 ist, wird der ausgehende Datenverkehr entsprechend der aktuellen Last auf jedem Slave verteilt. Wenn die Konfiguration tlb_dynamic_lb = 0 ist, wird der Lastenausgleich deaktiviert, jedoch wird die Last nur unter Verwendung der hasd-Verteilung verteilt. Für diesen Modus muss das ethtool die Basis-Treiber unterstützen, um die Geschwindigkeit jedes Slaves abzurufen.
Balance-ALB
Dieser Modus bietet Lastenausgleichsfunktionen, wie der Name TLB Adaptive Load Balancing darstellt. Ähnlich wie Balance-TLB, mit dem Unterschied, dass sowohl der Sendungs- als auch der Empfangsverkehr gebondet sind. Er erhält Lastenausgleich durch ARP-Verhandlung. Der Bonding-Treiber fängt die ARP-Antworten ab, die vom lokalen System auf ihrem Weg nach außen gesendet werden, und überschreibt die Quellhardwareadresse mit der einzigartigen Hardwareadresse eines der Slaves im Bond. Für diesen Modus muss das ethtool die Basis-Treiber unterstützen, um die Geschwindigkeit jedes Slaves abzurufen.

Vorbemerkung

Für dieses Tutorial verwende ich Oracle Linux 6.4 in der 32-Bit-Version. Bitte beachten Sie, dass, obwohl die Konfiguration unter Oracle Linux erfolgt, die Schritte auch auf CentOS und Red Hat OS-Distributionen sowie auf 64-Bit-Systemen anwendbar sind. Das Endergebnis unserer Beispielkonfiguration wird zeigen, dass die Verbindung zu unserem Bonding-Server auch dann bestehen bleibt, wenn ich eines der Ethernet-Netzwerke deaktiviert habe. In diesem Beispiel zeige ich, wie man Netzwerk-Bonding im Modus 1 anwendet, der die Active-Backup-Politik ist.

Installationsphase

Für diesen Prozess ist keine Installation erforderlich. Eine Standard-Linux-Installation eines Servers umfasst alle erforderlichen Pakete für eine Netzwerk-Bonding-Konfiguration.

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 zum 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 in unserem Server haben, die ETH0 und ETH1 sind.

Jetzt konfigurieren wir eine Bonding-Schnittstelle namens BOND0. Diese Schnittstelle wird eine virtuelle Ethernet-Schnittstelle sein, die die physischen Ethernet-Schnittstellen 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 führen Sie aus:

ls *ifcfg*bon*

Das Ergebnis ist:

ifcfg-bond0

Das war’s. Bitte beachten Sie, dass ich in der BOND0-Schnittstelle eine IP-Adresse hinzugefügt habe. Diese IP-Adresse wird die einzige IP-Adresse sein, die mit unserem Server verbunden ist. Um mit dem Prozess fortzufahren, müssen wir die physische Ethernet-Schnittstelle, die mit der BOND0-Schnittstelle verbunden ist, ändern. 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

Fertig. Wir haben die Schnittstellen ETH0 und ETH1 geändert. Beachten Sie, dass wir die IP-Adresse in beiden Schnittstellen entfernt und MASTER = bond0 hinzugefügt haben. Dies ist erforderlich, um zu bestätigen, dass beide Schnittstellen virtuelle Schnittstellen sind, die der Ethernet-BOND0-Schnittstelle gewidmet 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 Bonding-Modul unter Verwendung der Schnittstelle BOND0 konfiguriert. Wir haben auch die Bonding-Konfiguration zugewiesen, um den Modus = 1 zu verwenden, der die Active-Backup-Politik ist. Die Option miimon = 100 repräsentiert die Überwachungsfrequenz für unseren Bonding-Server, um den Status der Schnittstelle in Millisekunden zu überwachen. Wie oben beschrieben, bietet dieser Modus Fehlertoleranzfunktionen in der Server-Netzwerkkonfiguration.

Da alles eingerichtet ist, lassen Sie uns den Netzwerkdienst neu starten, 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 vorgenommen haben. Sie werden feststellen, dass die neue Schnittstelle namens BOND0 in der Netzwerkliste angezeigt wird. Sie werden auch feststellen, dass den Schnittstellen ETH0 und ETH1 keine IP-Adresse zugewiesen ist, nur die BOND0-Schnittstelle zeigt die IP.

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 auch den Bonding-Status über diesen Befehl überprüfen:

cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.6.0 (26. September 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, dass wir die Schnittstellen ETH0 und ETH1 erfolgreich in eine Bonding-Konfiguration im Active-Backup-Modus umgewandelt haben. Es wurde auch festgestellt, dass der Server jetzt die Schnittstelle ETH0 verwendet, während ETH1 als Backup-Schnittstelle dient.

Testphase

Jetzt, da alles wie erwartet konfiguriert ist, lassen Sie uns einen einfachen Test durchführen, um sicherzustellen, dass die Konfiguration, die wir vorgenommen haben, korrekt ist. Für diesen Test werden wir uns bei einem neuen Server (oder Linux-Desktop) anmelden und beginnen, unseren Bonding-Server anzupingen, um zu sehen, ob während des Tests eine intermittierende Verbindung auftritt. Nachfolgend finden Sie die Schritte:

login as: root  
[email protected]'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 der Zwischenzeit lassen Sie uns zu unserem Bonding-Server zurückkehren und die Ethernet-Schnittstelle ETH0 ausschalten. Nachfolgend finden Sie die Schritte:

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

Jetzt haben wir die Dienste für die Netzwerkschnittstelle ETH0 deaktiviert. Lassen Sie uns den Bonding-Status überprüfen. Nachfolgend finden Sie die Schritte:

cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.6.0 (26. September 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 jetzt im Bonding-Status nicht mehr vorhanden ist. In der Zwischenzeit lassen Sie uns zum vorherigen Testserver zurückkehren und den kontinuierlichen Ping zu unserem Bonding-Server überprüfen.

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 sehen Sie, dass wir, obwohl wir die Schnittstelle ETH0 abgeschaltet haben, immer noch in der Lage sind, unseren Bonding-Server anzupingen und darauf zuzugreifen. Lassen Sie uns einen weiteren Test durchführen. 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 (26. September 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 aktiv war, lassen Sie uns die ETH1-Schnittstelle deaktivieren.

ifdown eth1

cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.6.0 (26. September 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

Jetzt lassen Sie uns zum Testserver zurückkehren und überprüfen, was mit dem kontinuierlichen Ping zu unserem Bonding-Server passiert ist.

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

Daumen hoch! Wir haben erfolgreich konfiguriert und bewiesen, dass unser Bonding-Server in der Lage ist, das Szenario der Katastrophenwiederherstellung bei einem Netzwerk-Failover-Zustand zu bewältigen.

Erhalte neue Beiträge in deinem Posteingang.