Im Gespräch: VMware zur NFV-Strategie

Chef-Ingenieur Bruce Davie von VMware erklärt die interne Strategie zu Network Functions Virtualization, kurz NFV.

Im Gespräch mit Bruce Davie, Chef-Ingenieur bei VMware, erörtern wir, ob das Unternehmen mit Network Functions Virtualization arbeiten wird. Wir diskutieren, ob der Virtualisierungs-Pionier seinen Hypervisor dafür auslegt, NFV-Workloads zu unterstützen und die Services seiner NSX-Netzwerk-Virtualisierungs-Software zu verbessern. VMware erklärt hier zudem, wie sie Telko-Firmen dabei unterstützt, NFV-Services zu orchestrieren.

Telekom-Provider wollen geringere Latenzen im Hypervisor für NFV. Wie gehen Sie dieses Problem an?

BD: Am Anfang der Virtualisierungs-Ära stand die Frage, wie viel Overhead man in Kauf nehmen muss, um überhaupt Hypervisors nutzen zu können, anstatt die Workloads auf dem reinen Blech abzuarbeiten. Wir haben quasi schon seit es die Firma gibt daraufhin gearbeitet, die Performance zu verbessern.

Allerdings muss man Kompromisse eingehen, wenn man die Performance-Schraube im Hypervisor anzieht. Zunächst beginnt man, Dinge abzuschalten, um effizienter zu werden, weniger Strom zu verbrauchen und höheren Durchsatz zu erhalten. Aber Sie können nicht einfach verlangen, dass der Hypervisor geringere Latenzen aufweist, ohne gewisse Einbußen. Bei manchen Workloads läuft es eher nach dem Schema, dass man zwar die Latenzen verringert, dafür aber auf andere Dinge verzichten muss.

Will man die Latenzzeiten oder generell die Performance verbessern, so muss man nach den zehn kleinen Dingen suchen, die alle etwas Budget in Anspruch nehmen, und diese dann verbessern. Es gibt keine magische Formel, um geringe Latenzen zu erhalten.

Einer unserer Prototypen erlaubt das Einstellen der Latenzen bis zu 100 Prozent mit hohen Latenzzeiten bis zu 20 Mikrosekunden. Das würde ich einen extremen Latenzfall nennen, beispielsweise in der Reaktorsteuerung, wo man lieber diese Einstellungsauswahl hat, anstatt Kompromisse beim Durchsatz oder der Effizienz zu machen. Vom ESX 5.1 bis ESX 5.5 haben wir signifikante Verbesserungen hinzugefügt. Auch haben wir bereits Code zur Verfügung, der zwar noch nicht im Umlauf ist, aber noch weitere Optimierung bringen wird.

Was sind die Kompromisse, die man bei geringeren Latenzen in Kauf nehmen muss?

BD: Nehmen wir zum Beispiel Interrupt Coalescing. Ein Hypervisor führt die Interrupts zusammen. Anstatt, dass der erste Interrupt an der CPU ankommt und diese aktiviert, lassen sich mehrere zusammenfassen, die dann im Verbund die CPU aktivieren. Das ist gut für die Effizienz, aber schlecht für die Latenz, denn der erste Interrupt muss auf die anderen „warten“. 

Dieses Zusammenführen der Interrupts führt zwar zu weniger „Arbeit“ pro Interrupt, aber zu schlechterer Latenz. Aktiviert man Interrupt Coalescing, erhält man höhere Effizienz, schaltet man es ab, verbessern sich die Latenzen. Also geben wir den Anwendern genau diesen Knopf zum An- und Ausschalten, damit sie ihre eigene Wahl treffen können. Selbst Effizienz und Durchsatz könnten betroffen sein, da man mehr CPU-Zyklen in Anspruch nimmt, wenn man ineffizient arbeitet. Die ließen sich aber besser nutzen, beispielsweise für den Durchsatz.

Telekom-Provider verlangen zudem höheren Durchsatz für kleine Datenpakete. Könnten Sie dieses Problem beschreiben?

BD: Egal wie groß das Paket ist, es bedarf in jedem Fall einiger Zeit, es abzuarbeiten. Wenn der Anwender große Pakete abarbeitet, kann er hohen Durchsatz erhalten, da er nur wenige Pakete pro Sekunde transferiert. Verarbeitet man kleine Datenpakete, so werden pro Sekunde genau so viele kleine wie große Pakete abgearbeitet. Der Durchsatz verringert sich aber in diesem Falle, da pro Paket weniger Bytes transportiert werden.

Hier muss der Anwender sich seine Transaktionen auf pro-Paket-Basis und nicht auf pro-Byte-Basis betrachten. Wir müssen nur genügend Durchsatz liefern, um alle Ressourcen des Servers zu nutzen. Ein x86-Server kann nur schlecht mit einem Router konkurrieren, der voll mit ASICs ausgestattet ist. Deswegen wird es auch weiterhin Switch-Hersteller und- Anbieter geben.

Im NFV-Umfeld hat man Server, die Compute (CPU), Netzwerk und I/O mitbringen. Der Anwender möchte diese Ressourcen natürlich so effizient wie möglich nutzen. Ideal wäre es, die CPU zu 100 Prozent auszunutzen und den NIC mit 100 Prozent zu laden. Das zu erreichen, hängt von der Workload ab, die von der CPU abzuarbeiten ist. 

In unseren Tests war das eher trivial. Die CPU erhält und transferiert das Paket. Hier passiert also nicht viel Computing. Besser wäre es, innerhalb des Gast-Betriebssystems eine Firewall oder eine Paket Core-Funktion laufen zu lassen, die viel Computing pro Paket übernehmen. Als Anwender möchte man, dass die CPU ständig läuft und man auch kontinuierlich Pakete an die CPU sendet, damit diese auch beschäftigt bleibt. Im nächsten Release können wir bis zu vier Millionen kleine Pakete pro Sekunde abarbeiten. Das würde viele CPUs für NFV-Applikationen auf Trab halten.

Was trägt NSX zur NFV-Strategie von VMware bei?

BD: Die interessanteste Arbeit fällt bei der Service-Verkettung an. Hier haben wir bereits gute Funktionalität, aber tüfteln weiterhin daran, zusätzliche Verbesserungen hinzuzufügen. Es gibt nur wenige konzeptionelle Dinge, die man bei der Service-Verkettung tun kann. Das Wichtigste ist, ein System zu haben, dass abstrakte Topologien erstellt, um sich mit den virtuellen Netzwerk-Funktionen zu verbinden. Genau dies kann NSX.

Im Wesentlichen ist eine Service-Kette eine Topologie von Services. NSX erstellt virtuelle Topologien, um VMs zu verbinden, auf denen dann die virtuellen Netzwerk-Funktionen laufen. Traditionell wurde dies früher mit VLANs umgesetzt, wie beispielsweise auch Segmentierung. Mit NSX lassen sich aber diese Topologien besser und programmatischer aufbauen.

Des Weiteren benötigt man einen Metadaten-Kanal, um Informationen von einem Punkt der Service-Kette an einen anderen weiterzuleiten. Ein Beispiel wäre, dass der erste Block in einer Service-Kette zahlreiche Informationen darüber erhält, von welcher Station ein Anruf gestartet wurde und welches Nutzer-Profil dazu gehört. Zu Beginn der Service-Kette erfolgt eine Klassifizierung. Letztlich erhält man die Information, dass der Nutzer zur Klasse 732 gehört und irgendwo im Laufe der Kette muss nun etwas bestimmtes mit diesem User passieren, weil er dieser Klassifizierung angehört. Zum Beispiel bekommt er einen Premium Video Optimizer, wenn er bei der Video-Optimierungsfunktion der Kette ankommt.

Also müssen die Metadaten entlang der Kette weitergegeben werden, damit die Klassifizierung auch von einer anderen Funktion der Kette genutzt werden kann. Es gibt eigentlich nur einen Ort, die Metadaten vorzuhalten: im Paket-Header, der mit dem Paket transportiert wird. Sie müssen allerdings nicht im Paket selbst enthalten sein, weil man das User-Paket nicht modifizieren will. Da NSX die Pakete mit einem Virtualization Header versieht, ist dies der beste Platz, seine Metadaten abzulegen.

Erst kürzlich publizierten wir Material zum Header GENEVE. GENEVE ist eigentlich ein VXLAN mit flexiblen Optionsfeldern. Diese flexiblen Optionsfelder sind auch ein guter Platz, Metadaten abzulegen. Die virtuelle Netzwerkfunktion würde die Metadaten zu Beginn der Klassifizierung in das GENEVE Optionsfeld schreiben. Es wird mit dem Paket, in einem Header eingekapselt, transportiert. Es wir dann an eine andere virtuelle Netzwerkfunktion weitergereicht, die diese Metadaten ausliest und basierend darauf eine bestimmte Aktion mit dem Paket durchführt.

Kann man dies auch in VXLAN umsetzen oder eignet sich GENEVE dafür besser?

BD: Es ist nicht so augenscheinlich, wo man so etwas in VXLAN tun könnte. Ich weiß, dass Entwickler das Problem über eine IP-Option lösten, aber man hat schlichtweg keine Stellen mehr, wo man die Informationen platzieren kann, wenn man einen festgesetzten Header verwendet. Es wurde diskutiert, einen VLAN-Header mit dem Paket in VXLAN zu transportieren. Das ist nicht optimal, da es sich hier um ein sehr kurzes Feld handelt.

Gibt es andere VMware NFV-Inititiven?

BD: VMware spielt mit NFV auch auf dem Gebiet der Orchestration eine große Rolle. Hier gibt es derzeit nur wenig ausgereifte Produkte, sondern meist nur Demonstrationen. Bei der Orchestration können wir einige Tools effizient einbringen und mittels OpenStack sinnvolle Funktionalitäten bieten.

Es gibt derzeit NFV-Tests mit Ihrem Hypervisor. Nimmt NSX mehr Fahrt auf?

BD: Das NSX-Team wird häufig hinzugezogen, um diese NFV-Tests zu diskutieren, weil man wissen muss, was NSX gewährleistet und da wir als Netzwerkteam entsprechende Expertise liefern können. Allerdings sind einige Testumgebungen so klein, dass die Agilität von NSX nicht ins Gewicht fällt. In diesen kleinen Umgebungen kann man auch ohne Agilität gut auskommen. In den größeren Tests werden sich die Vorteile der automatisierten Netzwerk-Virtualisierungs-Komponenten zeigen.

Planen Sie Partnerschaften mit anderen NFV-Anbietern?

BD: Wir sind bereits seit längerem dabei, Partnerschaften zu anderen Anbietern von virtuellen Netzwerkfunktionen aufzubauen. Bereits vor Jahren stand für VMware die Strategie fest, hier mit traditionellen Netzwerkkomponenten-Herstellern zusammen zu arbeiten.

Wann wird NFV im Hypervisor verfügbar sein?

BD: Für viele Telko-Applikationen ist der Hypervisor bereits jetzt fertig. Die Herausforderung ist es, die Lösung richtig zu validieren, um die Latenzanforderungen der Anwendungen bedienen zu können. Mit den Latenz-Konfigurationen in ESXi 5.5 bedienen wir bereits die Ansprüche vieler NFV-Applikationen.

Gibt es andere NFV-Bereiche, die nach wie vor eine Herausforderung für den Hypervisor sind?

BD: Das Virtualisieren des Radio Access Network ist noch immer eine große Latenz-Herausforderung. Das ist so ähnlich wie beim Hochfrequenzhandel. Unser CEO Pat Gelsinger sagte, er würde gern 100 Prozent der Applikationen virtualisiert sehen. Damit legt er die Messlatte ziemlich hoch. Wahrscheinlich können wir dies auch erreichen, es bedarf dafür aber noch eine Menge Feinschliff am Hypervisor. Derzeit ist für uns das Virtualisieren des Radio Access Network noch außer Reichweite.

Folgen Sie SearchNetworking.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über LAN-Design und Netzwerkbetrieb

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close