© Friday, Fotolia.com

Der Ausfall einzelner Netzwerkkomponenten darf Infrastrukturen nicht gefährden. Ethernet-Interfaces redundant über Bonding zu koppeln, fängt viele Probleme schon vorher ab.

Die angestrebten 99,999 Prozent Erreichbarkeit entsprechen 5 Minuten Ausfallzeit pro Jahr. Dass HA in dieser Größe äußerst schwer zu erreichen ist, weiß jeder Admin, der schon mit einem Schraubenzieher in einem mysteriös ausgefallenen Server schwitzend hantieren musste. Ist dann noch ein Virtualisierungsserver im Spiel, fallen gleich mehrere Maschinen aus und es brennt unterm Dach.

Moderne IT-Abteilungen kontern mit Redundanz auf Software- (Cluster) und Hardware-Ebene (Raid, Netzteile, USV). Aber auch auf Ebene der Netzwerkinfrastruktur haben sich redundante Strategien durchgesetzt, weil sich immer weniger Admins mit dem Single Point of Failure eines Switch, einer Netzwerkkarte oder eines Kabels abfinden wollen.

Kanalbündelung

Fasst ein System mehrere physische Netzwerkschnittstellen zu einem neuen, gebündelten Kanal zusammen, spricht der Techniker von Bonding. Ziel ist es, die Ausfallsicherheit zu erhöhen und eine sinnvolle Lastverteilung zu erreichen, vielleicht sogar beides auf einmal.

Mit einem Aufbau mit mehreren Switches (Active Backup) lässt sich so jeglicher Single Point of Failure auf der Netzwerkebene vermeiden. Der unter Linux sehr ausgereifte Bonding-Treiber [1] beherrscht in unterschiedlichen Modi Ausfallsicherheit und Lastverteilung, teilweise auch in Kombination (Tabelle 1).

Problemfall Switch

Allerdings muss sich der Admin vorher einige Gedanken über die gewünschte Infrastruktur machen, denn die Sicherheit beim Failover steht und fällt mit den Fähigkeiten der Hardware und der richtigen Verkabelung zwischen Serversystemen und Geräten. Ein etwas besserer Switch darf es auch sein, und zwar einer, der das Rapid Spanning Tree Protocol (RSTP, 802.1w, [2]) beherrscht und so dabei hilft, Schleifen in der Netzwerkkonfiguration aufzuspüren und zu vermeiden. Die richtige Verkabelung ergibt sich dann zwangsläufig durch die Auswahl der Bonding-Modi sowie der zur Verfügung stehenden Switch-Hardware und der dort eingebauten Firmware.

Das bedeutet jedoch leider nicht, dass alle Switches in der Lage wären, jeden Bonding-Modus zu unterstützen. Die Hersteller kochen vielmehr ihre eigenen Süppchen. Bonding findet sich bei den verschiedenen Herstellern unter diversen Synonymen wie Link Aggregation (IEEE, [3]), Etherchannel (Cisco, [4]) oder Trunking (Sun, [5]).

Ciscos Geräte zum Beispiel müssen zum Bonding mittels 802.3ad (Modus 4) die jeweiligen Ports in einer Gruppe in einem Etherchannel mit dem Modus »lacp« (Link Aggregation Control Protocol, [6]) kombinieren. Weil dieser Standard zurzeit aber eigentlich keine Szenarios mit mehreren Switches unterstützt, geht das bei 802.3ad nur über kompliziertere Umwege. Bei anderen Bonding-Modi ist der Einsatz mehrfacher Switches viel einfacher möglich.

Abbildung 1: Durch Zusammenschluss von Switches zu einem logischen 802.3ad-basierten Verbund lässt sich echtes Trunking mit voller Ausfallsicherheit realisieren.

Diverse Geräte im oberen Preissegment wie der Cisco 6500 oder Junipers EX4200 bieten jedoch durch logischen Zusammenschluss mehrerer Switches dennoch die Möglichkeit, einen Single Point of Failure zu vermeiden (Abbildung 1).

Bonding-Modi

Der Bonding-Treiber des Linux-Kernels bietet mit aktuell sechs Modi eine Auswahl für fast jedes Szenario an, sei es Lastverteilung oder Ausfallsicherheit (Tabelle 1). Vorsicht bei der Auswahl ist geboten: Wer die Modi »balance-rr«, »balance-xor« und »broadcast« einsetzt, braucht auf dem Switch die passende Konfiguration. »active-backup«, »balance-tlb« sowie »balance-alb« kommen jedoch gänzlich ohne Einstellungen am Switch zurecht.

Während der Klassiker »active-backup« nach wie vor sehr häufig Verwendung findet, kommen in Unternehmen zunehmend Konfigurationen mit »802.3ad« vor. Diese bringen den zusätzlichen Vorteil der Lastverteilung mit erhöhter Bandbreite (Trunking) mit.

Die Modi »balance-xor«, »balance-tlb« sowie »balance-alb« bieten Lastverteilung pro MAC-Adresse. Bei solchen Szenarien ist bei einer großen Anzahl an potenziellen Gegenstellen bei starkem Netzwerkverkehr eine Steigerung des Durchsatzes zu erwarten.

Der Treiber liegt als Kernelmodul »bonding« vor und lässt sich mit den Standardtools laden. Modulparameter korrigieren die Defaultwerte für die Attribute der Bonding-Interfaces.

Laufzeitkonfiguration

Da sich Bonding-Interfaces auch nach dem Laden des Moduls noch mittels Sysfs konfigurieren lassen – die Attribute finden sich in »/sys/class/net/bondN/bonding/« – besteht aber generell keine Notwendigkeit, von Modulparametern Gebrauch zu machen.

Beim Laden des Moduls legt der Kernel Bonding-Interfaces nach dem Schema »bondN« an. Bei Bedarf erzeugt der Admin weitere – mit dem »max_bonds«-Modulparameter statisch oder dynamisch per Sysfs. Die Anzahl der gerade aktiven Bonds stellt er von Hand zum Beispiel mit »echo “+bond1” >/sys/class/ net/bonding_masters « ein. Jetzt fügt er die so genannten Slaves, also die eigentlichen Netzwerkinterfaces »eth0« und »eth1«, dem Bonding-Master hinzu und setzt weitere Parameter:

ip link set eth0 down;
ip link set eth1 down;
cd /sys/class/net;
echo "+eth0" >bond1/bonding/slaves;
echo "+eth1" >bond1/bonding/slaves;

Wichtig dabei: Die Slaves müssen vor dem Hinzufügen zum Master heruntergefahren sein, da die Bonding-Prozedur ihre MAC-Adressen neu setzt. Im Zuge der so genannten Versklavung, abgeleitet aus dem nicht mehr verwendeten Befehl »ifenslave«, startet Linux die Slave-Interfaces automatisch neu. Der Admin setzt noch einige Parameter (Tabelle 2), aktiviert den Master und weist ihm eine IP-Adresse zu:

echo 2000 >bond1/bonding/arp_interval;
echo +192.168.0.1 >bond1/bonding/arp_ip_target;
echo +192.168.0.2 >bond1/bonding/arp_ip_target;
ip link set bond1 up;
ip addr add 2001:db8::1/64 dev bond1;

01 40: eth0: <BROADCAST,NOARP,SLAVE,UP,LOWER_UP> mtu 1500 master bond1 state UNKNOWN link/etherc6:8b:ca:c4:06:9c brd ff:ff:ff:ff:ff:ff
03 41: eth1: <BROADCAST,NOARP,SLAVE,UP,LOWER_UP> mtu 1500 master bond1 state UNKNOWN link/ether c6:8b:ca:c4:06:9c brd ff:ff:ff:ff:ff:ff
05 45: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 state UP link/ether c6:8b:ca:c4:06:9c brd ff:ff:ff:ff:ff:ff inet6 2001:db8::1/64 scope global tentative valid_lft forever preferred_lft forever

Jetzt existiert ein aktiver Bond mit zugewiesener IPv6-Adresse sowie den beiden Schnittstellen »eth0« und »eth1« als Slaves im Standardmodus 0 (Balance-rr), »ip addr« zeigt die Details in Listing 1. Auch zur Laufzeit lässt sich der Bonding-Modus mit »echo Modus >/sys/class/net/bondN/mode« anpassen. Natürlich stellen diese Befehle nur den Low-Level-Zugang zu Bonding-Interfaces dar.

Dauerhafter Betrieb

Um die Einstellungen permanent zu speichern, bedient sich der Admin üblicherweise der von der Distribution zur Verfügung gestellten Konfigurationsmechanismen, etwa Suses Yast (Abbildung 2) oder eines Shellskripts, das die nötigen Befehle enthält. Open Suse und SLES setzen auf »ifcfg«, das die Konfiguration unter »/etc/sysconfig/network/ifcfg -bond1« speichert. Die in Tabelle 2 beschriebenen Attribute tauchen hier in der Zeile »BONDING_OPTS« auf:

STARTMODE='onboot'
BOOTPROTO='static'
BONDING_MASTER='yes'
BONDING_SLAVE_0='eth0'
BONDING_SLAVE_1='eth1'
BONDING_OPTS='arp_interval=2000 arp_ip_target=192.168.0.1,192.168.0.2'
IPADDR='2001:db8::1/64'

Abbildung 2: Suses Konfigurationswerkzeug Yast beherrscht auch Bonding. Die Einstellungen landen in Skripten unter »/etc/sysconfig/network/«.

Bonding-Schnittstellen lassen sich per Procfs überwachen und auswerten. Der aktuelle Status eines Bond ist mit »cat /proc/net/bonding/bondN« einzusehen. Für Nagios gibt es unter [7] ein Bonding-Skript, das sich schnell einbinden lässt und darüber hinaus den aktiven Bonding-Mode in dem bekannten Web-GUI anzeigt.

Regelmäßige Anfragen mit dem Address Resolution Protocol (ARP) mindestens an die Management-IP-Adresse des jeweiligen Switch stellen sicher, dass ein Interface zuverlässig als »down« markiert ist, wenn kein ARP-Traffic mehr läuft. Bei der Nutzung von ARP-Monitoring empfiehlt sich die Abfrage mehrerer Ziele. Schließlich kann auch an der Gegenseite eines Switch-Ports ein Netzwerkfehler auftreten. Dann nimmt der Server fälschlicherweise an, die Netzwerkverbindung einer Schnittstelle wäre nach wie vor funktionstüchtig. Aus diesem Grund ist beim Einsatz von Active-Backup-Bondings in einem Mehrfach-Switch-Szenario die zusätzliche Konfiguration eines hinter dem Switch befindlichen Geräts per »arp_ip_target« ratsam.

Komplexe Setups möglich

Mit dem geschilderten Beispiel ist das Konzept noch lange nicht ausgereizt. Virtualbox und VMware zum Beispiel lassen sich per GUI-Konfiguration auch an Bonding-Schnittstellen binden. Bei Xen muss der Admin mit den Bridge Utils eine Brücke zwischen den Interfaces »bondN« und einem von der VM verwendeten VifN.N-Gerät anlegen. Aber auch in derart komplexen Setups lässt sich das Bonding-Interface unkompliziert, weil nahezu identisch zu einer realen Netzwerkkarte, handhaben. (mfe)