Virtueller Switch mit Openvswitch

© Lisa Young, 123RF

Schaltstelle

Die Virtualisierung mit VMware, KVM und Xen ist nicht mehr aufzuhalten. Leider fehlte bisher ein virtueller Switch, der komplexe Szenarien unterstützt. Openvswitch unterstützt Flows, VLANs und Trunking, Policies und das Bündeln von Netzwerkkarten wie die großen Hardware-Switches.

Immer mehr Unternehmen stellen ihre gesamte Infrastruktur auf virtuelle Systeme um. Sie virtualisieren zentrale Komponenten wie SAP-Systeme, Oracle-Datenbanken, E-Mail-Systeme und Fileserver und verringern so den Verwaltungsaufwand. Gleichzeitig muss der Administrator für die Wartung der Hardware nicht mehr zwingend die Systeme ausschalten, da er diese zuvor im laufenden Betrieb auf andere virtuelle Hosts verschieben kann.

Ein großer Nachteil der virtuellen Umgebungen war lange Zeit deren einfache Netzwerkstruktur. Während reale Netzwerk-Switches neben VLANs, Trunking, QoS, Port-Aggregation und Firewalling auch Layer-3-Funktionalität bieten, sind die virtuellen Switches sehr simpel. VMware hat dieses Problem gemeinsam mit Cisco gelöst, das für VMware-Umgebungen den virtuellen Switch Nexus 1000V anbietet. Dieser integriert sich in die VMware-Umgebung und bietet entsprechend fortgeschrittene Funktionen.

Für freie Virtualisierungslösungen fehlte bisher ein entsprechendes Produkt. Mit Openvswitch [2] entsteht nun eine OpenSource-Lösung für dieses Problem. Dabei unterstützt Openvswitch neben Xen, KVM und Virtual Box auch den XenServer. Auch Citrix wechselt in der kommenden Version auf Openvswitch, das auf dem Openflow-Projekt [1] der Universität Stanford basiert. Openflow ist ein neuer offener Standard, der die Verwaltung von Switchen und Routern mit beliebiger Software erlauben soll (siehe Kasten "Openflow")

Openflow

Das Openflow-Projekt der Stanford Universität will die Router/Switch-Welt revolutionieren. Ein klassischer Router oder Switch vereinigt zwei Funktionen in einem Gerät:

  • Schnelle Weiterleitung der Pakete (Data Path)
  • Entscheidung wie und wohin die Pakete weiterzuleiten sind (Control Path)

Üblicherweise arbeiten diese beiden Systeme unabhängig voneinander auf demselben Gerät. Nur wenn der Data-Path-Anteil nicht weiß, wie und wohin ein Paket zu senden ist, fragt er den Control Path. Dieser ermittelt den Pfad/Route und speichert diese in der Flow-Tabelle. Alle weiteren Pakete desselben Flows kann die Data Path Engine schnell weiterleiten.

Der Openflow-Ansatz verschiebt nun den Control Path auf einen separaten Controller. Hierbei kann es sich um einen einfachen Server handeln. Der Openflow-Switch (Data Path) und der Controller kommunizieren dann über einen sicheren Kanal.

Der Openflow-Switch speichert die Flow-Tabelle. In dieser speichert der Controller die einzelnen Flows. Jeder Flow beschreibt die Eigenschaften der Pakete, die Bestandteil des Flows sind, und wie der Switch diese Pakete behandeln soll (Drop, Send-out-Port und so weiter). Sobald der Switch ein Paket erhält, für das kein passender Eintrag in der Tabelle existiert, sendet er das Paket an den Controller, der das Paket analysiert, eine Entscheidung trifft und diese in der Flow-Tabelle speichert.

Durch die Zusammenarbeit mit mehreren Herstellern konnten die Entwickler die Unterstützung für Openflow bereits in einigen kommerziellen Netzwerkgeräten erreichen. So exisiteren angepasste Firmwares für einige Switches von Hewlett-Packard, NEC, Toroki und Pronto [3]. Openvswitch ist eine Software-Implementierung, die beide Funktionalitäten (Data Path und Controller) zur Verfügung stellt.

Reichhaltig

Mit Openvswitch kann der Administrator auf einem Linux-System die folgenden Funktionen nutzen:

  • Voll-funktionaler Layer-2-Switch
  • Unterstützung für Netflow, sFlow(R), SPAN, and RSPAN
  • 802.1Q VLANs mit Trunking
  • Quality of Service (QoS)
  • Port Aggregation
  • GRE Tunneling
  • Kompatibilität zum Linux-Bridge-Code (»brctl« )
  • Switch-Implementierungen im Kernel und im Userspace

Bevor der Administrator jedoch loslegen kann, muss er Openvswitch installieren. Für Debian Sid (Unstable) gibt es fertige Pakete. Für Fedora/RedHat hat der Autor auf seiner Seite [4] Pakete zur Verfügung gestellt. Die Installation kann aber auch einfach aus den Quellen erfolgen (siehe Kasten "Installation").

Installation

Nach dem Auspacken der Quellen übersetzt und installiert der Administrator die Openvswitch-Software mit den üblichen Befehlen:

./configure --with-l26=/lib/modules/$(uname -r)/build
make
sudo make install

Um das Kernel-Modul zu übersetzen, müssen die Kernel-Header installiert sein. Diese sind bei den meisten Distributionen in einem Paket wie »kernel-devel« oder »kernel-headers« untergebracht.

Anschließend sollte der Admin die Installation prüfen und die Software das erste Mal starten. Hierzu lädt er manuell das passende Kernel-Modul:

modprobe datapath/linux-2.6/openvswitch_mod.ko

Schlägt dieser Befehl fehl, so muss der Admin meist ein bereits geladenes Bridge-Modul zunächst entfernen: »rmmod bridge« . Möglicherweise passt die Version des Kernel-Moduls auch nicht zum aktuellen Kernel. Dies kann besonders bei dem Einsatz fertiger Pakete ein Problem darstellen. Dann muss der Admin das Modul erneut übersetzen. Anschließend initialisiert er noch die Konfigurationsdatenbank von Openvswitch:

ovsdb-tool create /usr/local/etc/ovs-vswitchd.conf.db vswitchd/vswitch.ovsschema

Bei weiteren Problemen gibt die Datei »INSTALL.Linux« Tipps zur Fehlersuche.

Während die Pakete entsprechende Start-Skripte für die einfache Nutzung liefern, muss der Admin bei manueller Installation die Dienste auch manuell starten oder ein eigenes Startskript erstellen. Die Konfigurationsdatenbank übernimmt die Verwaltung des Switches (Listing 1). Anschließend startet der Admin den Openvswitch-Dienst:

Listing 1

Konfiguration

01  ovsdb-server /usr/local/etc/ovs-vswitchd.conf.db \
02                       --remote=punix:/usr/local/var/run/openvswitch/db.sock \
03                       --remote=db:Open_vSwitch,managers \
04                       --private-key=db:SSL,private_key \
05                       --certificate=db:SSL,certificate \
06                       --bootstrap-ca-cert=db:SSL,ca_cert
ovs-vswitchd unix:/usr/local/var/run/openvswitch/db.sock

Nun lassen sich mit dem Befehl »ovs-vsctl« bereits neue Switches erzeugen, Ports hinzufügen und konfigurieren. Da die meisten Skripte für Xen und KVM aber den Befehl »brctl« für die Administration der Bridge nutzen, sollte der Admin auch den Bridge-Kompatibilitäts-Daemon starten. Hierzu lädt er zunächst das Kernel-Modul und startet dann den Dienst:

modprobe datapath/linux-2.6/brcompat_mod.ko
ovs-brcompatd --pidfile --detach -vANY:console:EMER unix:/usr/local/var/run/openvswitch/db.sock

Nun kann er Openvswitch auch mit den Bridge-Utilities verwalten:

brctl addbr extern0
brctl addif extern0 eth0

Auch alle Skripte der Distributionen für die Erzeugung der Bridges funktionieren nun wie gewohnt. Natürlich kann der Admin auch den Befehl »ovs-vsctl« nutzen, um die Bridge zu verwalten. Beide Befehle lassen sich nun gleichzeitig nutzen (Listing 2).

Listing 2

Kontrolle der Bridge

01 [root@kvm1 ~]# brctl show
02 bridge name     bridge id               STP enabled     interfaces
03 extern0         0000.00304879668c       no              eth0
04                                                         vnet0
05 [root@kvm1 ~]# ovs-vsctl list-ports extern0
06 eth0
07 vnet0

Falls der Befehl »brctl show« meldet, dass bestimmte Dateien in dem Verzeichnis »/sys/« nicht gefunden werden, sind die Bridge-Utilities (zum Beispiel unter RHEL 6) zu aktuell. Hier empfiehlt sich ein Downgrade auf die letzte Version von RHEL 5.

Bis hierher verhält sich Openvswitch ganz genauso wie eine Bridge, die mit den Bridge-Utilities aufgebaut wurde. Um die fortgeschrittenen Funktionen zu nutzen, muss der Admin nun weitere Konfigurationen vornehmen. Sämtliche Einstellungen der Openvswitch-Konfigurationsdatenbank lassen sich mit dem Befehl »ovs-vsctl« verwalten.

Netflow

Openvswitch kann die Netflows innerhalb des Switches exportieren. Hierzu muss der Admin zunächst eine neue Netflow-Probe anlegen.

# ovs-vsctl create netflow target="192.168.0.5\:5000"
75545802-675f-45b2-814e-0875921e7ede

Nun verbindet er die Probe mit der Bridge »extern0« :

# ovs-vsctl add bridge extern0 netflow 75545802-675f-45b2-814e-0875921e7ede

Hat der Admin vorher auf dem System 192.168.0.5 einen Netflow Collector auf Port 5000 gestartet (zum Beispiel Ntop), so kann er nun die Daten anzeigen (siehe Abbildung 1).

Abbildung 1: Ntop zeigt die Flows der Bridge an.

Die Konfigurationseinstellungen in der Datenbank kann der Admin mit »ovs-vsctl list bridge« und »ovs-vsctl list netflow« kontrollieren und mit »ovs-vsctl destroy ...« wieder entfernen.

comments powered by Disqus

Artikel der Woche

Was beim Sniffen erlaubt ist und was nicht

Ein Unternehmer möchte Fehlern in seinem Netz auf den Grund gehen und den Netzwerkverkehr aufzeichnen, um ihn zu analysieren. Was aber sagt das Datenschutzrecht dazu? (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Ausgabe /2014

Was halten Sie von Zertifizierungen, die Fachkenntnisse und Fertigkeiten nachweisen?

  • Sie sind in der Praxis nutzlos
  • Sind für uns ein wichtiges Einstellungskriterium
  • Liefern einen Anhaltspunkt für die Qualifikation

Microsoft Azure