Skalierbarkeitskönig

von Martin Loschwitz

Tungsten Fabric ist die Open-Source-Variante von Junipers Software-defined-Networking-Produkt Contrail. Die freie Plattform glänzt mit technischer Innovation, kämpfte in der Vergangenheit aber mit lästigen Bugs und mangelnder Stabilität. Wir haben uns angesehen, ob sich hier etwas getan hat und ob Tungsten aktuell zum SDN-Allrounder taugt. Gut gefallen hat uns die Skalierbarkeit, weniger die Verwaltbarkeit.

Software-defined Networking, kurz SDN, ist im Rechenzentrum der Gegenwart längst von der Idee zur Realität geworden. Wer heute riesige Plattformen baut, die im Idealfall auch noch in die Breite skalieren sollen, beschäftigt sich immer seltener mit klassischen Netzwerklayouts wie dem Baum-Ansatz oder dem Stern-Modell. Wo VLANs und Spanning Tree auf den Switches früher zwingend notwendig waren, gibt heute Software den Ton an und die physische Hardware ist kurzerhand zum tumben Paketweiterleiter degradiert.

Open vSwitch & Co trennen heute Datenströme in virtuellen Umgebungen mit Multi-Tenant-Betrieb und nicht mehr die tatsächliche Hardware im Netzwerkpfad. Die großen Anbieter haben diesen Trend längst erkannt und sind mit eigenen SDN-Produkten am Start: Cisco buhlt mit ACI um Kunden und Konkurrent Juniper schickt Contrail ins Rennen. Anders als Contrail lässt Tungsten sich völlig ohne Vertrag mit Juniper nutzen. Grund genug, der Lösung umfassend auf den Zahn zu fühlen.

Fünf Testkriterien

Diesen Test haben wir anhand von fünf Kriterien vorgenommen. Im Mittelpunkt steht die technische Funktionalität. Wie sieht die Tungsten-Architektur aus, wie gut funktioniert Tungsten unter der Haube und bietet die Software SDN auf der Höhe der Zeit?

Das zweite Kriterium beschäftigt sich mit der Integration von Tungsten in andere Lösungen. SDN-Umgebungen müssen heute viele Ansprüche bedienen und aus OpenStack, OpenNebula oder Kubernetes heraus nutzbar sein. Wir haben uns angeschaut, ob dies bei Tungsten der Fall ist und mit welchen Werkzeugen es integriert ist. Von hier kommend stellt sich freilich die Frage, wie es um die praktische Handhabung von Tungsten steht – ist das Tool leicht aufzusetzen, zu betreiben und zu pflegen? Mit welchem Aufwand müssen Admins rechnen und ist Automatisierung eine Option? Diese Fragen bilden zusammen den dritten Punkt im Test.

Das vierte Kriterium beschäftigt sich mit dem Thema Sicherheit: Gewährleistet Tungsten zuverlässig, dass Datenströme unterschiedlicher Kunden voneinander getrennt sind und bleiben? Wo bietet das Produkt selbst Angriffspunkte und wie halten die Entwickler es generell mit dem Thema Sicherheit? Im fünften und letzten Teil geht es schließlich um die Frage, wie gut Tungsten skaliert und für Plattformen bis zu welcher Größe es grundsätzlich geeignet ist. Der Admin verhindert auf diese Weise, zu einem späteren Zeitpunkt womöglich in die Bredouille zu kommen – in einer laufenden Virtualisierungsumgebung lässt sich ein einmal ausgerolltes SDN nämlich nicht mehr so einfach austauschen.

Bewegte Historie

Tungsten hat eine wechselvolle Geschichte hinter sich. Ursprünglich entstand das Tool mit dem Namen Contrail als Produkt eines kleinen Unternehmens, das der Spanier Pedro Marques vor fast zehn Jahren aus der Taufe hob. Das zentrale Ziel war bereits damals die Schaffung einer umfassenden SDN-Plattform, die vorhandenen Ansätzen am Markt überlegen sein sollte. Auf dem seinerzeitigen Höhepunkt von OpenStack war es Unternehmen wie Cisco und Juniper wichtig, sich im SDN-Markt frühzeitig zu positionieren.

Und weil Großkonzerne vorrangig durch Akquisitionen wachsen, verleibte Juniper sich Contrail kurzerhand ein. Schnell war der Hersteller darin, das Produkt in eine Open-Source-Variante namens OpenContrail und eine kommerzielle Variante aufzuteilen, doch so richtig hatte Juniper lange keine Vorstellung davon, was es mit dem frisch zugekauften Produkt eigentlich anfangen wollte. Das äußerte sich nicht zuletzt dadurch, dass Juniper in Deutschland eine ganze Weile keinen Support und kein Consulting für Contrail verkaufen konnte, weil es die passenden Produkte im Juniper-Portfolio dazu schlechterdings nicht gab.

Technische Grundlagen

Das alles soll und darf nicht über den Umstand hinwegtäuschen, dass Tungsten, wie OpenContrail heute heißt, schon seinerzeit eine solide technische Grundlage hatte. Die Architektur der Plattform ist dezentral, skalierbar und fußt auf gängigen Standards, die sich im Internet millionenfach bewährt haben. Zwei konkrete Beispiele aus dem OpenStack-Alltag machen das deutlich:

Open vSwitch, der langjährige Standard für SDN mit OpenStack, führt keine zentrale Datenbank über virtuelle Instanzen und ihre MAC-Adressen. Wollte eine VM auf Hypervisor A mit einer VM auf Hypervisor B sprechen, musste sie zunächst einen ARP-Request aussenden, der per GRE- oder VXLAN-Tunnel an sämtliche Computing-Knoten der Umgebung ging. Dass dies nicht skaliert, ist vollkommen klar.

Tungsten führte daher von Anfang an eine zentrale Datenbank mit allen Hosts und fängt auf den einzelnen Systemen ARP-Requests ab, um sie selbst zu beantworten. Das vrouter-Kernel-Modul ist genau dafür sowie für die Einrichtung passender Paketströme zuständig. Ein einzelner Dienst auf den Compute-Knoten kommuniziert im Hintergrund mit der Konfigurationsdatenbank von Tungsten und findet heraus, auf welchem Ziel-Host die gewünschte VM läuft. Das vrouter-Modul beantwortet die ARP-Anfrage danach lokal selbst, sodass der ARP-Request den ausgehenden Compute-Knoten nie verlässt. Verglichen mit den Lösungen der Zeit war das ein dramatischer Technologie-Vorsprung.

Schlau auch bei externem Traffic

Ähnliches gilt für die Anbindung an externe Netzwerke, die bei OpenStack zum damaligen Zeitpunkt traditionell über "Network Nodes" erfolgte. Die sind freilich immer ein potenzielles Performance-Nadelöhr, weshalb sie in OpenStack heute so nicht mehr vorkommen. Network Nodes waren simpel konstruiert: Sie erzeugten lokal für virtuelle Router, die Cloudnutzer anlegten, Network Namespaces und banden diese an Open vSwitch an. Eingehender Traffic landete in jenem Network Namespace und wurde im Nachgang per DNAT zur Ziel-VM geleitet.

Tungsten geht hier deutlich schlauer ans Werk: Virtuelle Maschinen mit IPs auf einzelnen Systemen kommunizieren mit der Kommunikationsdatenbank, die auch an eine laufende BGP-Verbindung (Border Gateway Protocol) zu einem Upstream-Router angebunden ist. Sobald eine Public IP in der Cloud aktiv wird, verkündet das BGP-Gateway nach entsprechender Instruktion durch Tungsten die IP als /32-CIDR direkt ins Internet. Dadurch ist sie routingfähig und erreichbar.

Logging, Analyse und Redundanz top

Neue Maßstäbe setzt Tungsten auch im Hinblick auf sein Monitoring. Denn zur Plattform gehören eine GUI (Bild 1) und eine Analytics-Komponente, die existierende Datenströme registriert und verschiedene Metrikdaten zu ihnen aufzeichnet. Alle Details sind in einer eigenen Weboberfläche abrufbar, bis hinunter zum aktuellen Traffic einzelner virtueller Maschinen. Zum Teil sind die Aufzeichnungen sogar so exakt, dass europäische Unternehmen die Detailtiefe verringern müssen – weil ansonsten durch die aufzeichneten Daten Nutzungsverhalten minutiös rekonstruierbar wäre, was sich mit der DSGVO nur schlecht unter einen Hut bringen lässt.

Die Datensammelei hat allerdings recht deftige Anforderungen an die zugrunde liegende Hardware: Fette Mehrkern-Maschinen mit viel RAM und viel schnellem Flash-Speicher sollten es für Cassandra, Zookeper und Kafka schon sein – denn an der Analyse der Nutzungsdaten sind all diese Komponenten beteiligt.

Aus Admin-Sicht relevant ist zudem, dass die Entwickler sich um das Thema Redundanz ausgiebig Gedanken gemacht haben. Als Datenspeicher kommen in Tungsten Fabric lediglich Dienste zum Einsatz, die sich ab Werk redundant betreiben lassen, etwa Cassandra oder Redis. Und jede zu Tungsten gehörende Komponente kann innerhalb einer Installation beliebig oft laufen, ohne mit ihren Klonen ins Gehege zu kommen. Geht einmal etwas schief, kümmert Tungsten sich automatisch um allfällige Failover, und zwar ohne dass der Admin eingreifen muss.

Performance dank vRouter

Neben den bereits beschriebenen Abläufen bei der ARP-Beantwortung kommen dem vRouter-Modul in Tungsten noch etliche andere Aufgaben zu. Sollen etwa schnelle Techniken wie SR-IOV oder DPDK Verwendung finden, klinkt vRouter sich direkt in die entsprechende Hardware auf dem Host ein und implementiert die gewünschten Features. Packet Filtering erledigt vRouter ebenfalls; hierzu erhält es von der Control-Komponente von Tungsten, die im Hintergrund auf die Config-DB zugreift, die passenden Einstellungen.

Wo Alternativen wie Open vSwitch also auf Linux-Bordmittel setzen, verankert Tungsten entsprechende Funktionen direkt in seinem Kern . Zum Einsatz kommen zudem standardisierte Technologien wie MPLS – was im Test zum Teil erhebliche Performancegewinne mit sich brachte. Der Overhead, der Open-vSwitch-basierten Umsetzungen innewohnt, fehlt bei Tungsten freilich komplett – denn Open vSwitch bleibt hier komplett außen vor.

Fabric-Konzept kein Alleinstellungsmerkmal

Die Ambitionen von Tungsten lassen sich anhand der vollständigen Bezeichnung des Produkts erahnen – "Fabric" ist hier entscheidend. Wer mit diesem Begriff nicht vertraut ist: Im Netzwerkkontext beschreibt "Fabric" eine Umgebung auf Basis standardisierter Protokolle, die massive Skalierbarkeit ermöglicht. Typische Switch-Architekturen skalieren nicht nahtlos, weil sich nicht beliebig viele Switches nachstecken lassen.

Das Problem ist hier der OSI-Layer 2: Große Layer-2-Segmente sind Netzwerk-Admins ein Graus, weil sie den Einsatz von Protokollen wie STP erzwingen, um auch nur in mittelgroße Regionen zu wachsen. Softwarebasierte Fabrics wie Tungsten verlagern einen großen Teil der Funktionalität auf die Software-Ebene, indem sie kleine Layer-2-Segmente bauen und zwischen diesen per Layer 3 mit BGP routen. Auch dieser Ansatz ist in Tungsten im Kern des Konzepts verankert.

Hätte Tungsten vor Jahren als OpenContrail nicht mit erheblichen Problemen im Hinblick auf seine Verfügbarkeit für verschiedene Distributionen und seine grundlegende Funktionalität zu kämpfen gehabt, wäre die Plattform heute vermutlich die erste Adresse in Sachen SDN. Die Zeit stand aber nicht still und andere Werkzeuge haben featureseitig aufgeholt.

So hat Open vSwitch mittlerweile in Form von OVN eine Control-Plane erhalten, die wenigstens dem schlimmsten Overhead den Garaus macht. Cloudwerkzeuge wie OpenStack haben ihr Design so überarbeitet, dass Network Nodes als solche nicht mehr existieren, sondern die Internetverbindung verschiedener virtueller Netze direkt über die Compute-Knoten stattfindet. Mit Standardhardware von der Stange lassen sich heute zudem unmittelbar auf Netzwerk-Switches IP-Fabrics bauen, die einen guten Teil der OpenContrail-Funktionalität ersetzen. Technisch ist das alles noch immer nicht so elegant wie das Gesamtpaket bei Tungsten. Allein auf weiter Flur ist Tungsten zumindest im Hinblick auf seinen Funktionsumfang heute aber auch nicht mehr.

Gelungene Integration in Orchestrierungswerkzeuge

Zwar haben wir bereits mehrfach OpenStack erwähnt, faktisch ist die massiv skalierbare Cloudplattform aber nicht mehr der primäre Fokus der meisten Admins. Containerisierte Anwendungen geben stattdessen den Ton an. Ein versatiles SDN-Werkzeug wie Tungsten muss deshalb, will es seine Vielseitigkeit unter Beweis stellen, nicht nur mit klassischen Virtualisierungsumgebungen wie VMware oder OpenStack funktionieren. Die Integration in Orchestrierer für Container ist ebenfalls notwendig.

Dieses Kriterium ließ sich im Test recht fix abhandeln, denn Tungsten Fabric bietet mittlerweile volle Integration für die meisten Umgebungen am Markt. Weil der Fokus 2014 vorrangig auf OpenStack lag, lässt Tungsten Fabric sich bis heute hervorragend damit integrieren. Ähnliches gilt für Kubernetes: Tungsten läuft als CNI-Modul für Kubernetes und erweitert dieses um einen Tungsten-Provider. Aus Kubernetes heraus lassen sich Tungsten-Ressourcen also nativ anlegen und Tungsten selbst kümmert sich im Hintergrund um den Rest. Zwar sind Multi-Tenant-Setups eher die Ausnahme als die Regel im Kubernetes-Umfeld. Von Performancegewinnen und der durchdachten Tungsten-Architektur profitieren aber selbst Single-Tenant-Umgebungen.

Auch für VMware bieten die Entwickler eine Anbindung. Im VMware vCenter lässt Tungsten sich als Netzwerkprovider anlegen, VMware kommuniziert dann direkt mit den relevanten Tungsten-Komponenten. Weil Tungsten an den Kernel von ESXi nicht herankommt, verlagert es das vRouter-Modul in die virtuellen Instanzen und steuert diese so.

In Summe gilt: Wer einen gängigen Flottenorchestrierer nutzt, wird sich um die Anbindung an Tungsten Fabric kaum Sorgen machen müssen.

Bastelei nicht ausgeschlossen

Sorgenfalten könnten dem Admin hingegen die Themen Wartung und Verwaltung auf die Stirn zaubern. Tungsten hat sich hier in den vergangenen Jahren zwar radikal verbessert. Galt es 2014 noch, Pakete für gängige Linux-Distributionen selbst zu bauen oder aus dubiosen Quellen zu beziehen, haben die Entwickler ihren Deployment-Ansatz mittlerweile vollständig umgestellt. Das bedeutet: Sämtliche Tungsten-Komponenten kommen als Container daher. Um deren Rollout muss der Admin sich nicht selbst kümmern – stattdessen legen die Entwickler eine Sammlung von Ansible-Playbooks bei, über die sich das Ausrollen bewerkstelligen lässt.

Manche alte Zöpfe haben die Entwickler allerdings noch immer nicht abgeschnitten, und das nervt gehörig. Zu Tungsten gehört etwa eine gepatchte Version von BIND, dem Urahn der heutigen DNS-Server, der speziell an die Bedürfnisse von Tungsten angepasst ist. Das war bereits früher ein riesiger Kritikpunkt, weil der der nur notdürftig gepatchte BIND direkt aus dem Paläolithikum kommt. Hier wäre es längst zwingend nötig, dass die Tungsten-Dienste DNS-Einträge wie die meisten anderen Werkzeuge über die dafür im DNS-Standard vorgesehenen Protokolle an durch den Admin konfigurierbare DNS-Server sendet.

Bauchschmerzen kann dem Admin zudem das vRouter-Modul verursachen. Denn anders als die Tungsten-Dienste lässt dieses sich nicht in Form eines Containers auf die Hosts bringen. Stattdessen gilt: Auf jedem Server, auf dem Tungsten-Dienste laufen, muss das Modul für den aktuell laufenden Kernel vorhanden und geladen sein. Das allerdings heißt auch, dass der Admin vor jedem Kernel-Update auf seinen Compute-Knoten prüfen muss, ob mit dem neuen Kernel das vRouter-Modul weiterhin funktioniert.

Hier hat Tungsten einen nicht gerade makellosen Track-Record. Oft funktioniert vRouter mit einem neuen Kernel gar nicht mehr oder es legt Server wegen eines Bugs lahm. Was im Klartext heißt: Längst nicht mit jeder aktuellen Linux-Distribution lässt Tungsten sich überhaupt nutzen. Ein gewisser Fokus liegt auf Enterprise-Distributionen und dort auf CentOS oder RHEL. Wer Tungsten auf anderen Distributionen betreiben möchte, wird in der Mehrzahl der Fälle Basteleien vor sich haben.

Komplexes Monitoring und Deployment

Zwar kommt Tungsten mit den bereits erwähnten Komponenten zum Monitoring, die einen Teil der Überwachung übernehmen. Wer die Lösung komplementär in bestehende Monitoringsysteme oder Werkzeuge wie Prometheus übernehmen will, muss aber selbst Hand anlegen. Immerhin: Ein Exporter, um Metrikdaten aus Tungsten etwa in Prometheus (und damit indirekt ebenso in InfluxDB) zu exportieren, steht zur Verfügung – wenn auch von einem Drittanbieter und ohne Maintenance-Versprechen durch das Tungsten-Projekt selbst.

Was die Sache zusätzlich erschwert: Tungsten ist unter der Haube eine äußerst komplexe Sammlung von Werkzeugen. Zum Teil nutzen die Komponenten für die Kommunikation miteinander etwa keine standardisierten Protokolle, sondern ein eigenes Protokoll auf XML-Basis namens Sandesh. Zusätzlich hat der Admin es wie bereits erwähnt mit einer riesigen Menge loser Teile zu tun: Cassandra, Redis, Kafka, Dutzende Contrail-Dienste, die Komponenten der Orchestrierungslösung et cetera. "Mal eben" lässt Tungsten sich also weder ausrollen noch betreiben.

Sicherheit nur Mittelmaß

Hiebe setzt es für Tungsten auch beim Testkriterium Sicherheit. Zwar kümmert die Plattform sich um die Sicherheit virtueller Workloads vorbildlich. Die Firewallregeln, die direkt auf der vRouter-Ebene umgesetzt sind, sind dafür ein perfektes Beispiel. Andererseits leistet Tungsten sich Aussetzer wie den bereits erwähnten Pflaster-Bind, der obendrein ins Internet exponiert sein muss. Derartige Schwachstellen erschüttern das Vertrauen in die Sicherheit der Plattform nachhaltig.

Immerhin: Ungewöhnlich viele Sicherheitsprobleme hat die Community zusammen mit den großen Herstellern in Tungsten bisher nicht gefunden – und das aktuelle Deployment-Schema auf Basis von Containern erlaubt zudem, flexibel auf diese zu reagieren. Sicherheitskernschmelzen musste Tungsten zudem bisher noch nicht verzeichnen, und Fälle von fehlgeschlagener Separation von Kundendaten sind zumindest bisher nicht bekannt. Beim Thema Sicherheit schlägt Tungsten sich insofern im Mittelfeld.

Gute Skalierbarkeit

Deutlich anders sieht das beim letzten Kriterium aus, der Skalierbarkeit. Hier hatte Tungsten praktisch von Anfang an die Nase weit vor der Konkurrenz: Das gesamte Angebot ist in allen Komponenten darauf ausgelegt, nahtlos zu skalieren. Wenn einzelne Komponenten nicht mehr ausreichen, konfiguriert der Admin weitere Instanzen derselben Dienste hinzu. Ein erheblicher Teil der von Tungsten verursachten Last liegt auf den Compute-Knoten, die sich allerdings ebenfalls nahtlos skalieren lassen. Potenzielle Flaschenhälse wie Network Nodes sind a priori nicht Teil des Tungsten-Konzepts und können insofern auch keinen Ärger verursachen.

Wie beschrieben verlässt Tungsten sich für seine Funktionalität zudem nicht auf irgendwelche Funktionen des Netzwerk-Layers 2. Diesen können Admins passend mit anderen skalierbaren Ansätzen wie EVPN konstruieren, weil die gesamte Logik für das Routen und Aufteilen der eigenen Pakete letztlich Tungsten auf der Software-Ebene übernimmt. Als Fundament für eine skalierbare Umgebung eignet Tungsten sich deshalb besonders.

Fazit

Unser Test des aktuellen Tungsten fördert Licht und Schatten zutage. Im Hinblick auf seine Architektur ist das Produkt vielen anderen Ansätzen bis heute weit überlegen – dass es sich mittlerweile mit allen relevanten Orchestrierern am Markt nutzen lässt, ist da im Endeffekt nur das Sahnehäubchen. Auch die nahtlose Skalierbarkeit bis hin zu riesigen Umgebungen landet bei Tungsten auf der Habenseite.

Mittelgut schneidet das Programm hingegen im Hinblick auf Sicherheit ab. Und ins Straucheln gerät Tungsten ganz klar im Hinblick auf die alltäglichen Wartungsarbeiten, die ein Admin mit dem Produkt vor der Brust hat. Klar: Eine komplexe SDN-Plattform wie Tungsten hat eine immanente Komplexität. Die Container, in denen die Entwickler Tungsten ausliefern, schaffen hier bereits Abhilfe. Das nützt aber nichts, wenn etwa das vRouter-Modul regelmäßig Updates zur Erhöhung der Wartbarkeit verhindert, weil es mit neueren Kernels nicht zusammenspielt. Oder wenn der Admin es mit so vielen verschiedenen Komponenten und Protokollen zu tun bekommt, dass er erstmal ein Jahr in Klausur muss, um die Grundlagen rund um Tungsten zu lernen.

In Summe hinterlässt Tungsten einen zwiespältigen Eindruck. Admins, die große, skalierbare Umgebungen planen, sollten sich das Angebot dennoch genauer ansehen und gegebenenfalls evaluieren. Genug Zeit zum Lernen sollte dabei aber unbedingt Teil der Planung sein.

Produkt	Open-Source-Plattform für Software-defined Networking.
Hersteller	Tungsten Fabric Project https://tungsten.io/
Preis	Kostenfrei
Systemvoraussetzungen	Mindestvoraussetzung für einen Deployment-Knoten sind eine Zweikern-CPU, 4 GByte RAM und 50 GByte Storage. Empfohlen werden aber mindestens eine Achtkern-CPU, 16 GByte RAM. Der Betrieb als virtuelle Maschine ist möglich. Ein Knoten für die Tungsten-Infrastruktur sollte mindestens eine Vierkern-CPU, 64 GByte RAM und 300 GByte Storage mitbringen. Auf Compute-Knoten läuft das vRouter-Modul mit, stellt selbst jedoch keine erwähnenswerten Anforderungen an die verfügbare Hardware.
Technische Daten	http://www.it-administrator.de/downloads/datenblaetter/