Performance-Engpässe in virtualisierten Netzwerken ermitteln

Spectre und Meltdown haben Netzwerkschwachstellen enthüllt, die immer noch untersucht werden. Es ist aber klar ersichtlich, dass die Angriffe Auswirkungen auf die Kapazitätsplanung für das Netzwerk hatten. Während Administratoren nach Wegen suchen, um die Effekte dieser Attacken zu minimieren, lohnt es sich möglicherweise, eine Spezifikation – Single-Root I/O-Virtualisierung oder kurz SR-IOV – näher zu betrachten.

Bei SR-IOV handelt es sich um einen PCI-Standard (Peripheral Component Interconnect), der wichtige Performance-Auswirkungen für das virtualisierte Networking hat. Bevor wir uns aber zu sehr in den Details verlieren, warum das der Fall ist, ist es wichtig, das Problem, das SR-IOV aufgreift, zu verstehen.

Virtualisiertes Networking abstrahiert die Software von der Hardware. Wenn man einige Prämissen über den Host voraussetzt, sollten sich virtualisierte Anwendungen – beziehungsweise Container – auf Desktop-Hardware genauso verhalten wie bei einem PaaS-Provider (Platform as a Service) oder dazwischen angesiedelten Lösungen. Dadurch können Anwendungsanbieter sich auf eine Handvoll OS-Images als Standard beschränken. Der Nachteil liegt darin, dass Hypervisor-Funktionen und andere Anwendungen einen messbaren Overhead erzeugen, verglichen mit den gleichen Workloads, die auf Bare-Metal-Hardware laufen.

Für die meisten Workloads stellt dies in der Regel kein Problem dar. Allerdings weisen Public Clouds und Private Clouds spezifische Flachenhälse auf, die bei Bare Metal Deployments nicht in der Form entstehen. Ein Beispiel dafür ist, wie der Host herausfindet, welchem Gast er ein Paket senden soll.

Immer wenn ein physischer Host einen Ethernet-Frame empfängt, schickt er die Daten über den PCI-Bus an die Host-CPU. In einer virtualisierten Netzwerkumgebung emuliert die CPU einen Ethernet-Switch, um den Frame an den jeweiligen Gast weiterzuleiten. Dieser Soft-Switch unterbricht buchstäblich einen CPU-Kern bei einer nützlichen Aufgabe, etwa Anfragen eines Gasts zu bedienen.

Der relative Effekt, der entsteht, wenn man die CPU für das Forwarding nutzt, variiert je nach Workload. Eine Datenbanktransaktion erfordert im Allgemeinen einige Disk-I/O-Operationen und erzeugt eine Reihe von Worker Threads. Entsprechend besitzen die CPU-Zyklen, die für das Software-Switching verloren gehen, einen relativ geringen Anteil an der gesamten Transaktionszeit.

Netzwerkfunktionen – zum Beispiel Firewall-Filterung, Content Inspection und Load Balancing – sind in hohem Maße Netzwerk-I/O-intensiv. In einer virtualisierten Netzwerkumgebung sind sie möglicherweise besonders im Nachteil. Typische Aufgaben für diese Workloads sind „Führe diesen regulären Ausdruck aus, und sende das Paket dann weiter“ oder „Schreibe diese Felder in jedem Paket neu“.

Die Performance für diese Transaktionen hängt viel stärker von der CPU ab. Vielleicht sind nur einige wenige Zyklen nötig, um jeden Frame anzunehmen, zu verarbeiten und weiterzuleiten. Darüber hinaus ist diese Art von Transaktion weniger abhängig von der Disk I/O. Infolgedessen kommt es zu einer größeren Auswirkung auf die gesamte Transaktionszeit, wenn ein CPU-Kern bei seiner Arbeit unterbrochen wird, um eine einfache Switch-Funktion durchzuführen.

Eine Möglichkeit, das Problem mit der benötigten Netzwerkkapazität in den Griff zu bekommen, besteht in der Verwendung von DirectPath I/O. Hierbei wird eine physische NIC direkt mit einem einzelnen Gast über den PCI-Bus verbunden. Für Laborumgebungen und einige Spezialfälle ist das prima, allerdings nicht sonderlich gut skalierbar oder effizient. Jeden Host mit Dutzenden von physischen Netzwerkkarten auszustatten, macht einen entscheidenden Vorteil der Virtualisierung zunichte – eine Infrastruktur, die mit weniger Verkabelung und weniger Switches auskommt.

Hinweis der Redaktion: Im nächsten Teil dieser Artikelreihe erläutert Glen Kemp die Vorteile und Nachteile von SR-IOV.

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