Erste Erfahrungen mit Open-vSwitch

Vor kurzem habe ich Debian 8 (Jessie) auf meiner Entwicklermaschine, einem HP ProLiant DL380G5, installiert. Als Basissystem habe ich mich dieses Mal für Debian (stable) entschieden, obwohl ich ja sonst fast ausschließlich unter Gentoo arbeite. Das System macht einen sehr guten Eindruck. Interessiert hat mich hierbei am meisten, wie die Integration von systemd unter Debian gelungen ist, nachdem ich mich damit auf einer Gentoo-Maschine schon seit etlichen Monaten beschäftigt habe.

Was mir dabei gut gefällt ist, dass die gewohnte Netzwerkkonfiguration unter /etc/network/interfaces noch immer so genutzt wird. Auf diese Weise konnte ich recht schnell eine Bridge konfigurieren, in der eine meiner externen Schnittstellen mit integriert ist (ich liebe diese Art, weil dann jede VM direkten Zugang zum Netzwerk hat).

Das funktionierte sehr gut. Nach einiger Zeit war klar, dass ich gerne eine Gentoo-Clusterlösung als Testsystem auf dem Server betreiben wollte (wir haben ein Produktivsystem und dieses neue Testsystem soll einfach unser Staging für Updates sicherer machen).

Jetzt ist es so, dass dieser Cluster Bonding und etliche VLANs konfiguriert hat und nun war klar, dass der Weg mit einer Bridge nicht unbedingt optimal dafür ist. Also habe ich mich entschieden, Open-vSwitch auf der Entwicklermaschine aufzubauen. Mit Erfolg.

Im Wesentlichen zeige ich einmal die Konfiguration der Debian-interfaces-Datei und ein Beispiel einer XML-Konfiguration zu einem der beiden Clusterknoten. Zum Schluss, wie das Ganze dann unter Gentoo auf dem ersten Knoten genutzt wird.

Mein Fokus liegt klar auf den VLANs. Zu Bonding bin ich noch nicht weiter tiefer eingestiegen. Wer dazu Ideen und Anregungen hat, gerne in den Kommentaren erwähnen 🙂

Debian interfaces

Das Beispiel definiert einen Switch namens ovsbr0. In diesem Switch hängen beide externen Schnittstellen des Servers so wie einVLAN-Device. Der Switch hat selbst eine IP und zusätzlich habe ich noch ein weiteres Netz hinzugefügt, was für den Testcluster selbst eine Relevanz hat.

Die beiden physischen Schnittstellen sind nicht im selben VLAN! eth1 habe ich bewusst in VLAN 109 untagged gepackt. Ich nutze das, um mein Laptop daran anzuschließen und bestimmte Kommunikation mit dem Cluster zu testen.

Weiterhin gibt es ein virtuelles VLAN mit der ID 108. Das nutze ich, um aus Sicht des Test-Clusters eine ansprechbare IP “extern” zu haben. Heißt so viel wie: Ich kann vom Cluster aus eine IP auf dem VLAN 108 pingen und somit ebenfalls eine bestimmte Kommunikation simulieren.

libvirt XML Konfiguration einer der Knoten

Das sieht auf den ersten Moment schlimm aus. Zerlegen wir das mal:

Der Server hat vier Netzwerkkarten. Jeweils zwei davon bilden ein Bond-Gerät. Das eine Device wird für die interne Clusterkommunikation (corosync, pacemaker, DRBD, …) benutzt, das andere für eine Anbindung an den Switch mit all seinen VLANs. Jetzt kommt vielleicht schnell die Frage auf, wo denn “all die VLANs” oben definiert wurden? Nirgends. Das geschieht zur Laufzeit des Gastes. Freundlicherweise fügt libvirt alles Notwendige direkt in open-vSwitch hinzu und wir brauchen uns um nichts weiter zu kümmern.

Alle hier gezeigten VLANs sind tagged Ports. D.h. dass der Cluster selbst 802.1Q sprechen muss, was gleich gezeigt wird.

Zuerst zeige ich mal kurz die Switchkonfiguration vor dem Start der MS und dann danach

Vor dem Start

Nach dem Start

Wie gewünscht 🙂

Gentoo Netzwerk-Konfiguration unter openrc

Viel lässt sich dazu jetzt nicht sagen, denn das ist Cluster-spezifisch. Ich zeige nur kurz, was die Ausgabe von IP so zeigt (der Cluster ist im Beispiel auf beiden Knoten im Standby)

Die Linkliste

Fazit

Mit Hilfe von Open-vSwitch kann ich sehr realistische Setups virtuell nachbauen, was Kosten und Ressourcen an Hardware spart.

Eine kleine Anmerkung habe ich noch:

Sowohl unter Debian (zum Zeitpunkt dieses Artikels) als auch unter Gentoo (mit systemd!) kann es vorkommen, dass der Switch während des Bodens noch nicht hundert prozentig verfügbar ist. Das ist noch ein bisschen nervig, aber unproblematisch. Ich habe einfach alle VMs auf der Testmaschine aus dem Autostart genommen. Bei Gentoo klappt das, aber gelegentlich kommt das ovsbr0 selbst nicht hoch. Dann sind zwar alle Gäste voll funktional vorhanden und erreichbar, aber die Kommunikation zwischen der physischen Maschine und den Gästen klappt nicht. Ich nutze hier netctl, um mein Netzwerk zu konfigurieren und ein


netctl start ovsbr0

nach einem Neustart behebt dann umgehend das Problem. Wer eine Firewall wie Shorewall auf einer physischen Maschine nutzt, kann hier auch einen Trick anwenden, damit der Server dann nicht unerreichbar ist, wenn das ovsbr0 nicht gleich hoch kam:

Das Schlüsselwort “optional” erlaubt das Nichtvorhandensein einer Netzwerkschnittstelle zur Startzeit von Shorewall.

Have fun…