Netzwerk-Bonding mit Linux

© © Andrey Khrobostov, 123RF

Gebündelt

Für hochverfügbare Installationen ist eine redundante Netzwerkanbindung unverzichtbar. Dieser Artikel führt die entsprechende Konfiguration eines Linux-Stacks vor.
Egal, um welchen Dienst es sich dreht, den Benutzern geht es immer zu langsam. Der Schwerpunkt des ADMIN-Magazins 05/2011 verrät, mit welchen Tools man ... (mehr)

Viele Anwender und Administratoren wünschen sich eine möglichst hohe Verfügbarkeit wichtiger Anwendungen und Dienste. Neben der Ausfallsicherheit von Serverhardware und dem möglichen Clustering von Serverdiensten spielt das Netzwerk eine elementare Rolle, damit Anwender die gewünschten Dienste nutzen können.

Dieser Artikel zeigt Linux-Administratoren einige Möglichkeiten auf, wie sie mit möglichst wenig Komplexität ein möglichst hochverfügbares Netzwerk im Unternehmen aufbauen können. Dabei geht es von den Netzwerkkarten der Server, über die Switches und Router bis hin zur Firewall ohne die Verwendung von (Rapid) Spanning-Tree oder ähnlichen Protokollen.

Fällt ein Stockwerk-Switch aus, sind im besten Fall nur wenige Anwender betroffen, trifft der Ausfall jedoch einen zentralen Switch im Serverraum, steht vielleicht gleich bei vielen Nutzern, die Dienste auf Servern nutzen, die Arbeit still. Bei Servern mit nur einer aktiven Netzwerkkarte führt ein Ausfall dieser zum Totalausfall des Servers aus Sicht der Anwender. Der Ausfall eines zentralen Routers würde weite Teile der Firma lahmlegen, während ein Ausfall der Firewall zumindest noch die Arbeit mit der internen IT-Infrastruktur ermöglicht.

Die Anforderungen in Unternehmen sind immer individuell zu bewerten, sodass dieser Artikel keine allgemeingültige Lösung für alle Netzwerke geben kann. Abbildung 1 zeigt daher schematisch, wie der Netzwerkadministrator sein Netzwerk vom Server bis zur Firewall redundant aufbauen kann. Soll auch der Ausfall des Internetproviders berücksichtigt werden, hilft ein zweiter Internetanschluss zumindest für ausgehende Verbindungen auf einfache Weise weiter. Für eingehende Verbindungen ist mehr Planung nötig, da sich IP-Adressen bei einem Provider-Failover ändern.

Abbildung 1: Aufbau des redundant ausgelegten Linux-Netzwerks durch alle Schichten hindurch.

In welcher Reihenfolge das Netzwerk redundant aufgebaut wird, ist Geschmackssache. Dieser Artikel beschreibt den Weg von unten nach oben durch den Netzwerk-Stack (Abbildung 1).

Administratoren aktueller Linux-Distributionen haben es leicht, den Server über mehrere Netzwerkverbindungen redundant an einen oder sinnvollerweise zwei Switches anzubinden. Das Zauberwort heißt Bonding, und die Technik funktioniert seit vielen Jahren problemlos und zuverlässig. Der Autor verwendet Ubuntu 10.04 in der 64-Bit-Version, für andere Distributionen muss man die Befehle anpassen.

Falls nicht bereits installiert, befördert »aptitude install ifenslave ethtool« die benötigten Pakete auf die Festplatte. Nun gilt es, die »/etc/modprobe.d/aliases.conf« anzupassen oder falls noch nicht vorhanden zu erstellen. Listing 1 zeigt eine Active-Standby-Konfiguration, die alle 100 Millisekunden prüft, ob die Verbindung zum Switch funktioniert. Der Mode-Parameter gibt an, auf welche Art Netzwerkkarten miteinander zusammenarbeiten sollen (lastverteilt und redundant oder nur redundant). Unter [1] auf der Webseite der Linuxfoundation befindet sich eine detaillierte Beschreibung der verschiedenen Modi. Die Einstellung »mode=1« hat sich bei Tests des Autors als die am einfachsten zu konfigurierende und unempfindlichste Einstellung erwiesen. Die Switches müssen dafür keinerlei besondere Voraussetzungen erfüllen, im Gegensatz zu »mode=4« , bei dem der Switch 802.3ad (LACP) unterstützen muss.

Listing 1

Bonding-Device

01 alias bond0 bonding
02 options bonding mode=1 miimon=100

Im letzten Konfigurationsschritt ist die Konfigurationsdatei »/etc/network/interfaces« nach dem Vorbild von Listing 2 anzupassen. Dort werden eine OnboardNetzwerkkarte (»eth0« ) und eine Zusatznetzwerkkarte (»eth2« ) zum logischen Interface »bond0« zusammengefasst. Ein Neustart des Netzwerks mittels »/etc/init.d/networking restart« aktiviert die Einstellungen. Wer keine Remotekonsole zu seinem Server hat, sollte vorher die Konfiguration sorgfältig prüfen, da bei Fehlkonfigurationen die Netzwerkverbindung abreißt.

Listing 2

Netzwerkkonfiguration

01 auto lo
02 iface lo inet loopback
03
04 auto bond0
05 iface bond0 inet static
06         address 192.168.60.10
07         netmask 255.255.255.0
08         post-up ifenslave bond0 eth0 eth2
09         gateway 192.168.60.254

Mittels »ifconfig« lässt sich anschließend prüfen, ob das Interface »bond0« aktiv ist. Unter »/sys/class/net/bond0/bonding/« finden sich die entsprechenden Informationen des Kernels, wie zum Beispiel die gerade aktive Netzwerkkarte, die in »active_slave« steht. Man sollte die erwartete Fehlertoleranz auch einmal physisch testen, etwa indem man den Port des Switches deaktiviert oder das entsprechende Netzwerkkabel zieht. Funktioniert alles ordnungsgemäß, geht maximal ein Ping-Paket beim Failover verloren (siehe Abbildung 2).

Abbildung 2: Weitgehend ausfallsicher: Nur ein Paket ging verloren.

Wer bereits Nagios im Einsatz hat, dem sei das Plugin "check_linux_bonding" von Trond Hasle Amundsen von der Universität Oslo empfohlen [2], da ein einfacher Ping-Check den Ausfall eines Netzwerklinks nicht mehr feststellen kann. Das Plugin zeigt im OK-Zustand den aktiven Link mit einem Ausrufezeichen an (siehe Abbildung 3) und geht beim Ausfall eines Links in den Zustand "Warning" (siehe Abbildung 4).

Abbildung 4: Nagios meldet: Ein Fehler ist aufgetreten.
Abbildung 3: Zurzeit ist beim Bonding-Device alles in Ordnung.

Den Wunsch, auch Failovers zu überwachen, um eventuelle Probleme im Netzwerk frühzeitig zu erkennen, konnte der Autor leider nicht erfüllen. Dies ist nicht möglich, da es im Kernel selbst keine Informationen über einen vergangenen Failover gibt und eine Speicherung des Status seitens des Plugins zu einem unlösbaren Problem führen würde: Ein Hin- und Rück-Failover zwischen zwei Prüfungen des Plugins ist nicht unterscheidbar.

Switches

Nun ist einem Serveradministrator schnell klar, dass es nicht unbedingt sinnvoll ist, beide Netzwerkkabel an einen Switch zu stecken, da bei einem Ausfall des Switch der Server trotzdem offline wäre. Der Netzwerkadministrator muss nun einen zweiten Switch bereitstellen und dafür sorgen, dass dabei keine Ethernet-Loops entstehen und so das Netzwerk lahmlegen.

Eine sehr einfache und effektive Lösung für dieses Problem ist das sogenannte Stacking von Switches. Dabei verhalten sich zwei oder mehr Switches wie ein einziger. Der (zweifache) Uplink von diesem Stack zu weiteren Switch-Stacks oder Router-Stacks wird wiederum mittels Bonding auf Switch-Ebene realisiert (je nach Hersteller kann dies zum Beispiel Link Aggregation, Etherchannel oder Trunk heißen). Ziel ist es, (Rapid) Spanning Tree und andere Implementierungen zur Vermeidung redundanter Netzwerkpfade nicht zu verwenden, da dies in vielen Fällen eher Probleme bereitet als löst. Manche Administratoren ziehen sogar ein manuelles Failover (von Hand umstecken) vor. Das ist an sich nichts Schlechtes und in vielen Fällen vollkommen ausreichend, es gibt aber viele Situationen, in denen dies nicht möglich ist beziehungssweise zu langen Ausfallszeiten führen würde, weil zum Beispiel das Rechenzentrum weit entfernt ist.

Stacking-Funktionen bieten die für den Unternehmenseinsatz gebauten Switches aller großen Hersteller, sodass sich die in diesem Artikel verwendeten Cisco-Techniken auch auf andere Hersteller übertragen lassen. Auf OSI Layer 2 kommen Cisco 2960-S Switches mit Flexstack-Technologie zum Einsatz. Der Flexstack wird über ein zusätzliches Modul (siehe Abbildung 5) auf der Rückseite der Switches mit zwei Cisco-proprietären Kabeln realisiert. Die Konfiguration ist dabei denkbar einfach und erfreut den Netzwerkadministrator: anstecken, ein paar Minuten warten, fertig.

Abbildung 5: Die Cisco-Lösung für die Verbindung zweier Switches ist eine proprietäre Verbindung.

Die automatische Konfiguration lässt sich mit »show switch« auf der Konsole des Switch mitverfolgen. Der Status ändert sich von »waiting« auf »initializing« zu »ready« und damit zum einsatzbereiten Status. Einer der beiden Switches ist Master des Stacks und sowohl durch ein LED am Switch selbst als auch auf der Konsole zu erkennen. Natürlich ist es auch beim Switch-Stack empfehlenswert, den Status des Stacks zu überwachen [3].Dies ist beispielsweise mit dem Skript »check_snmp_cisco_stack.pl« möglich, das zwar für den 3750 gedacht ist, aber auch zum 2960 kompatibel ist.

Routing

Im nächsten Schritt wird der Stack von zwei Switches mit einem beziehungsweise zwei Routern / Layer-3-Switches verbunden. Der Router ist wiederum als Stack ausgeführt (zum Beispiel zwei Cisco 3750). Nähme der Netzwerkadministrator einfach zwei Kabel und verbände den Switch-Stack mit dem Router-Stack, würde das zu einem Ethernet-Loop führen und das Netzwerk massiv beeinträchtigen. Daher wird auch zwischen Switch- und Router-Stack mit Bonding gearbeitet, bei Cisco also Etherchannel. Um den Ausfall eines Routers und eines Switches gleichzeitig verarbeiten zu können, müssen vier Kabel kreuzweise zwischen Switch- und Routerstack verwendet werden.

comments powered by Disqus