In diesem Tutorial wird erläutert, wie Sie die Netzwerkbindung auf einem Linux-Server konfigurieren. Bevor ich anfange, lassen Sie mich erklären, was Network Bonding ist und was es tut. In einer Windows-Umgebung wird Netzwerkbindung als Netzwerk-Teaming bezeichnet. Dies ist eine Funktion, die jeder Serverarchitektur hilft, Hochverfügbarkeit und Failover in Szenarien bereitzustellen, in denen eines der Haupt-Ethernetkabel eine Fehlfunktion hat oder falsch konfiguriert ist.
Normalerweise ist dies eine bewährte Methode und eine unverzichtbare Funktion, die implementiert werden muss, wenn Sie einen Server für Produktionszwecke einrichten. Obwohl diese Funktion in einer Linux-Umgebungskonfiguration ausgeführt werden kann, müssen Sie sich zunächst von Ihrem Netzwerkadministrator bestätigen lassen, um sicherzustellen, dass die mit Ihrem Server verbundenen Switches Netzwerkbindung unterstützen. Es gibt mehrere Bonding-Modi, die Sie in Ihrer Serverumgebung implementieren können. Unten finden Sie eine Liste der verfügbaren Modi und ihrer Aufgaben:
- Balance-rr
Dieser Modus bietet Funktionen für Lastenausgleich und Fehlertoleranz (Failover) über eine Round-Robin-Richtlinie. Bedeutet, dass es Pakete in sequentieller Reihenfolge vom ersten verfügbaren Slave bis zum letzten überträgt. - Aktives Backup
Dieser Modus bietet Fehlertoleranzfunktionen über eine aktive Sicherungsrichtlinie. Dies bedeutet, dass, sobald das Bonding-Ethernet aktiv ist, nur einer der Ethernet-Slaves aktiv ist. Der andere Ethernet-Slave wird nur dann aktiv, wenn der aktuell aktive Slave ausfällt. Wenn Sie diesen Modus wählen, werden Sie feststellen, dass die Bonding-MAC-Adresse nur auf einem Netzwerkadapter extern sichtbar ist. Dies dient dazu, den Schalter nicht zu verwechseln. - Balance-xor
Dieser Modus bietet Lastausgleich und Fehlertoleranz. Es überträgt basierend auf der ausgewählten Übertragungs-Hash-Richtlinie. Alternative Übertragungsrichtlinien können über die Option xmit_hash_policy ausgewählt werden. - Sendung
Dieser Modus bietet nur Fehlertoleranz. Es überträgt alles auf allen Slave-Ethernet-Schnittstellen. - 802.3ad
Dieser Modus bietet Lastausgleich und Fehlertoleranz. Es erstellt eine Aggregationsgruppe mit denselben Geschwindigkeits- und Duplexeinstellungen. Es nutzt alle Slave-Ethernet-Schnittstellen im aktiven Aggregator, es basiert auf der 802.3ad-Spezifikation. Um diesen Modus zu implementieren, muss das ethtool die Basistreiber zum Abrufen der Geschwindigkeit und des Duplexmodus jedes Slaves unterstützen. Der Switch muss außerdem dynamische Link-Aggregation unterstützen. Normalerweise erfordert dies das Eingreifen des Netzwerktechnikers für eine detaillierte Konfiguration. - Balance-TLB
Dieser Modus bietet Lastausgleichsfunktionen, da der Name TLB für Übertragungslastausgleich steht . Wenn für diesen Modus die Konfiguration tlb_dynamic_lb =1 ist, wird der ausgehende Datenverkehr gemäß der aktuellen Last auf jeden Slave verteilt. Wenn die Konfiguration tlb_dynamic_lb =0 ist, ist der Lastausgleich deaktiviert, die Last wird jedoch nur mithilfe der hasd-Verteilung verteilt. Für diesen Modus muss das ethtool die Basistreiber unterstützen, um die Geschwindigkeit jedes Slaves abzurufen. - Guthaben-ALB
Dieser Modus bietet Load-Balancing-Funktionen, da der Name TLB für adaptives Load-Balancing steht . Ähnlich wie balance-tlb, außer dass sowohl der Sende- als auch der Empfangsverkehr verbunden sind. Es erhält einen Lastausgleich, indem es eine ARP-Aushandlung erreicht. Der Bonding-Treiber fängt die vom lokalen System gesendeten ARP-Antworten auf ihrem Weg nach draußen ab und überschreibt die Quellhardwareadresse mit der eindeutigen Hardwareadresse eines der Slaves im Bond. Für diesen Modus muss das ethtool die Basistreiber unterstützen, um die Geschwindigkeit jedes Slaves abzurufen.
1. 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 durchgeführt wird, die Schritte auch für CentOS- und Red Hat OS-Distributionen sowie für 64-Bit-Systeme gelten. Das Endergebnis unseres Beispiel-Setups zeigt, dass die Verbindung zu unserem Bonding-Server bestehen bleibt, obwohl ich eines der Ethernet-Netzwerke deaktiviert habe. In diesem Beispiel zeige ich, wie Sie die Netzwerkbindung mit Modus 1 anwenden, der die Richtlinie für aktive Sicherungen ist.
2. Installationsphase
Für diesen Vorgang 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 zum Netzwerkkonfigurationsordner und listen Sie die verfügbaren Ethernet-Schnittstellen auf. Unten sind 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 per Setup in unserem Server haben, 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 physische Ethernet-Schnittstelle von ETH0 und ETH1 enthält. Unten sind 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
Führen Sie dann Folgendes aus:
ls *ifcfg*bon*
Das Ergebnis ist:
ifcfg-bond0
Das ist alles. Bitte beachten Sie, dass ich in der BOND0-Schnittstelle eine IP-Adresse eingefügt habe. Diese IP-Adresse ist die einzige IP-Adresse, die mit unserem Server verbunden ist. Um mit dem Prozess fortzufahren, müssen wir die physische Ethernet-Schnittstelle in Bezug auf die BOND0-Schnittstelle ändern. Unten sind 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 Schnittstellen ETH0 und ETH1 vorgenommen. Beachten Sie, dass wir die IP-Adresse in beiden Schnittstellen entfernt und MASTER =bond0 angehängt haben. Dies ist erforderlich, um zu bestätigen, dass beide Schnittstellen virtuelle Schnittstellen sind, die der Ethernet-BOND0-Schnittstelle zugeordnet sind.
Um mit der Konfiguration fortzufahren. Lassen Sie uns eine Bonding-Konfigurationsdatei namens bonding.conf unter /etc/modprobe.d erstellen. Unten sind 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 mit der Schnittstelle BOND0 konfiguriert. Wir haben der Bindungskonfiguration auch den Verwendungsmodus =1 zugewiesen, was eine aktive Sicherungsrichtlinie 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 Fehlertoleranzfunktionen in der Servernetzwerkkonfiguration.
Nachdem alles eingerichtet ist, starten wir den Netzwerkdienst neu, um die neue Konfiguration zu laden. Unten sind 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 hatten. Sie werden feststellen, dass die neue Schnittstelle mit dem Namen BOND0 in der Netzwerkliste angezeigt wird. Sie werden auch feststellen, dass den Schnittstellen ETH0 und ETH1 keine IP-Adresse zugewiesen ist, nur die Schnittstelle BOND0 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 den Bindungsstatus auch mit diesem 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 oben, dass wir die Schnittstellen ETH0 und ETH1 erfolgreich in eine Bonding-Konfiguration mit aktivem Backup-Modus konvertiert haben. Angegeben, dass der Server jetzt die Schnittstelle ETH0 verwendet, ETH1 wird als Backup-Schnittstelle dienen.
4. Testphase
Jetzt ist alles wie erwartet konfiguriert. Machen wir einen einfachen Test, 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, unseren Bonding-Server zu pingen, um zu sehen, ob während des Tests eine intermittierende Verbindung auftritt. Unten sind 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
Lassen Sie uns während dieser Zeit zu unserem Bonding-Server zurückkehren und die Ethernet-Schnittstelle ETH0 ausschalten. Unten sind 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
Nun haben wir die Dienste für die Netzwerkschnittstelle ETH0 abgeschaltet. Lassen Sie uns den Bindungsstatus überprüfen. Unten sind 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 jetzt nicht mehr im Verbindungsstatus vorhanden ist. Lassen Sie uns während dieser Zeit 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 werden Sie 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 1 Test. Schalten Sie die ETH0-Schnittstelle wieder ein und schalten Sie 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 aktiv war, fahren wir die ETH1-Schnittstelle herunter.
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
Lassen Sie uns jetzt zum Testserver zurückkehren und prüfen, was mit dem kontinuierlichen Ping an unseren 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 das Disaster-Recovery-Szenario bei einer Netzwerk-Failover-Bedingung bewältigen kann.