OpenStack-Konfiguration für Service Provider

Echtzeit-Paketverarbeitung ohne Performanceverlust

| Autor / Redakteur: Dan Teichman / Andreas Donner

Besonders in OpenStack-Umgebungen kommt es auf eine performante, deterministische Paketverarbeitung an.
Besonders in OpenStack-Umgebungen kommt es auf eine performante, deterministische Paketverarbeitung an. (Bild: © Cybrain - stock.adobe.com)

Die Open-Source-Communities wie OpenStack und OPNFV haben zweifellos gute Arbeit geleistet, um Vorgaben in Bezug auf Performance-Anforderungen, Skalierbarkeit und Zuverlässigkeit für Carrier-Anwendungen festzulegen. Realistisch betrachtet ist und bleibt diese Thematik jedoch nach wie vor als „Work in Progress“ zu sehen.

Viele Service Provider befürchten, dass die Migration der Echtzeit-Kommunikation von spezialisierter Hardware hin zu einer virtuellen, Cloud-basierten Umgebung mit Einbußen bei der Performance einhergeht. Insbesondere bestehen Bedenken bezüglich der Performance von Virtual Network Functions (VNFs), die einen hohen Durchsatz, eine hohe Verfügbarkeit und geringe Latenzzeiten für die Paketverarbeitung in Echtzeit erfordern.

Als Spezialist für hochsichere und intelligente Kommunikationslösungen in der Cloud hat Sonus Networks dieses Thema ausführlich erforscht. Und unserer Meinung nach gibt es Lösungen, die eine beschleunigte Handhabung ermöglichen und das für die Echtzeit-Paketverarbeitung erforderliche deterministische Verhalten sicherstellen. Denn mit einer Lösung, die für geringe Latenzzeiten bei der Echtzeit-Medien-Paketverarbeitung in einer virtuellen Cloud-Umgebung sorgt, ist es nicht nur möglich, den gefühlten Performance-Nachteil zu beseitigen, sondern auch nachzuweisen, wie VNFs die hohen Erwartungen der größten Communication Service Providers (CSPs) in Bezug auf die Echtzeit-Kommunikation erfüllen können.

Handhabung mit hoher Performance

Die Bearbeitung von Echtzeit-Paketen zu beschleunigen, ist im Prinzip eine einfache Angelegenheit – ein Paket wird aus dem Netzwerk in eine virtuelle Maschine (VM) geladen, so schnell wie möglich verarbeitet und wieder in das Netzwerk zurückgeladen. Aber natürlich ist dies in der Realität nicht ganz so einfach. Die Verwendung der Standardtechnik Open vSwitch (OVS), Pakete aus den NIC-Karten auszulesen und sie dann in den VMs durch die für jeden Port erzeugten Linux Tap-Devices zu schicken, funktioniert nur für Anwendungen mit niedrigen Datenverkehr-Durchsatzraten zufriedenstellend. Für Anwendungen mit hohem Paketdurchsatz sind Lösungen wie SR-IOV oder DPDK Accelerated Open vSwitch mit Multi-Queue vhost-Benutzer-Support erforderlich, um eine schnelle Paketverarbeitung zu erreichen.

Trotz alledem gelten für jede dieser Lösungen gewisse Einschränkungen:

  • 1. Mit SR-IOV erhält man eine Lösung, welche die physische Netzwerkfunktion zu mehreren virtuellen Funktionen virtualisiert und den ankommenden Datenverkehr mit MAC oder MAC+VLAN jeder virtuellen Funktion zuteilt. Ein Problem bei SR-IOV ist, dass die ankommenden Pakete nicht reguliert werden, sodass sie nicht in der Datenrate begrenzt werden. Dies muss von der Gast-VM realisiert werden. Mit SR-IOV gibt es leider keine Sicherheit für die ankommenden Pakete; dies ist der VNF selbst überlassen, was zusätzliche Verarbeitungszeit erfordert.
  • 2. Dagegen bietet DPDK Accelerated Open eine Implementierung, welche die Behandlung der von der Schnittstelle gelesenen Pakete und die Bereitstellung der Pakete zu einer bestimmten VM verbessert. Das OVS DPDK Modell ermöglicht zudem die Anwendung von Sicherheitsmaßnahmen auf jedes Paket, was aber den CPU- und Speicheraufwand erhöht.

Sicherstellen des deterministischen Verhaltens

Einer der Vorteile einer virtualisierten Umgebung ist die gemeinsame Nutzung physischer Ressourcen durch alle VMs. Bei rechenintensiven VNFs – z.B. bei solchen im Zusammenhang mit leistungsfähiger Echtzeit-Pakethandhabung –, wird jedoch genau diese Eigenschaft zu einem Nachteil. Der Nachteil resultiert daraus, dass ein nicht-deterministisches Verhalten zu langen Latenzzeiten oder Paketverlust führen kann, mit negativen Folgen für Performance und Qualität. Für rechenintensive VNFs ist eine Plattformbezogenheit wünschenswert, um die Beschleunigung der zu Grunde liegenden Hardware nutzen zu können.

Auf Grundlage unserer durchgeführten Analysen und Tests hat Sonus Networks eine Reihe von empfohlenen OpenStack-Konfigurationen identifiziert, die positiv dazu beitragen, dass Echtzeit-Pakete deterministisch und mit kurzen Latenzzeiten behandelt werden:

Overcommit-Einstellungen: Überschreiben der standardmäßigen Overcommit-Einstellungen von OpenStack und Einstellen eines Verhältnisses von 1:1 für CPU und RAM.

Non-Uniform Memory Access (NUMA)-Platzierung: Obwohl jeder NUMA-Knoten einen dedizierten lokalen Bus zum Speicher besitzt, kann der Zugriff auf den dezentralen Systemspeicher auch über einen Bus erfolgen, der von allen Knoten genutzt wird. Beim Zugriff auf den dezentralen Systemspeicher über den gemeinsamen Bus oder mit einem NIC, der nicht lokal zum Host gehört, können verschiedene Probleme auftreten. Dazu zählen etwa unerwünschte Cache-Synchronisierung zwischen den NUMA-Knoten, verringerte E/A-Performance oder Verschwendung von Ressourcen im gemeinsamen Bus zwischen den Knoten. Zur Vermeidung dieser Nachteile wird empfohlen, die VM, z.B. Medien-SBC, auf eine NUMA-Grenze zu beschränkten.

vCPU-Topologie: In OpenStack sind die virtuellen CPUs in einer Gast-VM standardmäßig als eigenständige Prozessoren zugeordnet. Dies ist jedoch nicht unbedingt für alle Anwendungen sinnvoll. Für die genannten Virtual Network Functions lässt sich der Hypervisor-Overhead reduzieren, wenn die Host-Topologie ebenfalls in der Gast-VM konfiguriert wird.

CPU-Pinning: Für den Hypervisor stellt sich die virtuelle Maschine als ein einziger Prozess dar, der auf den verfügbaren CPUs zur Ausführung eingeplant werden muss. Während die oben genannte NUMA-Konfiguration bedeutet, dass der Speicherzugriff vom Prozessor eher lokal erfolgt, hat der Hypervisor die Möglichkeit, anschließend beim nächsten Taktzyklus einen anderen Prozessor zu wählen. Leider kann dies zu einer geringeren lokalen Speichernutzung führen und die Möglichkeit erfolgloser Cache-Zugriffe erhöhen, sodass zwar eventuell eine Gast-VM für das Scheduling zur Verfügung steht, aber nicht genutzt wird. Daher wird empfohlen, die Gast-vCPUs den Host-CPUs fest zuzuordnen („pinning“), sodass sie von anderen VMs am selben Host nicht genutzt werden können. Die Rechnerressourcen sollten entweder nur für fest zugeordnete VMs oder nicht fest zugeordnete VMS sein, aber nicht für eine Kombination aus beiden. Wenn auf dem Host Hyper-Threading aktiviert ist, soll das Standard-Thread-Verfahren beibehalten werden.

Vorgabe für das „Paging“: Das Linux Kernel-Feature „transparent huge pages“ (THP) und die explizite Zuordnung großer Pages sollte für die Zuordnung von RAM für die Applikation verwendet werden, wenn dies sinnvoll ist. Die Zuordnung großer Pages reduziert die Notwendigkeit der Paging-Verteilung zur Laufzeit (Runtime) in Abhängigkeit von der Speichernutzung, reduziert den Hypervisor-Overhead und ermöglicht den VMs die RAM-Zuordnung, um ihre Performance zu erhöhen.

Isolation von CPUs für Host-Prozesse: Es wird empfohlen, alle „pinned“ CPUs für die Gast-vCPU vorzusehen, ohne dass Beeinträchtigungen mit den Prozessen auf der Host-Ebene auftreten.

Deaktivierung/Nichtnutzung von Einstellungen: Es gibt mehrere OpenStack-Einstellungen, die deaktiviert oder auf andere Weise nicht genutzt werden sollten:

  • Verbessern des Speicherzugriffs und Sicherstellen kurzer Latenzzeiten beim Speicherzugriff, indem KEIN Auslagerungsspeicher am Rechner-Host genutzt wird.
  • Bei Verwendung der Large-Page-Option wird ein RAM Overcommit-Verhältnis nicht mehr verwendet, da eine 1:1-Zuordnung zwischen Gast-RAM und Host-RAM bestehen muss, und das Host-OS berücksichtigt keine Large Pages, die dem Gast zugeordnet sind, zum Auslagern. In diesem Zusammenhang ist es auch sinnvoll, das Overcommit auch für vCPUs auszuschalten.
  • Kernel Shared Memory (KSM) kann erhebliche Verbesserungen in der Nutzung des RAM bringen, wenn viele identische Gast-Betriebssysteme auf dem gleichen Host laufen oder die Gäste auf andere Weise identische Speicherseiten-Inhalte haben. Jedoch geht KSM mit einer erhöhten CPU-Nutzung einher und dieser Overhead kann die Applikationen verlangsamen. Deshalb sollte KSM ausgeschaltet werden.
  • CPU-Modell-Einstellung für die VM: Nova ist eine Komponente in OpenStack, die dafür entwickelt wurde, den Zugriff auf Rechenressourcen und das Management großer VM-Netzwerke nach Bedarf zu ermöglichen. Eine Option in der Nova-Konfiguration ermöglicht die Konfiguration der virtuellen Gast-VM zwischen verschiedenen Alternativen. Für die beschriebene rechenintensive Anwendung wird empfohlen, dass die BIOS-Power-Einstellung des Hosts für maximale Performance konfiguriert und der CPU-Modus auf „host-pass through“ eingestellt wird, so dass alle CPU-Flags vom Host zum Gast sichtbar gemacht werden.

Quantitative Beurteilung der OpenStack-Konfiguration

Wie zuvor beschrieben, wurden mehrere Empfehlungen zum Konfigurieren von OpenStack gegeben, aber nicht alle Änderungen sind gleich wirksam, um die Latenzzeiten zu verkürzen. Abbildung 1 zeigt die relativen Verbesserungen bei der Latenz für diese verschiedenen Einstellungen, wobei die NUMA-Bezogenheit und das CPU-Pinning den größten Effekt haben.

Auch wenn zwei Änderungen am wichtigsten sind, sollten alle Empfehlungen als wichtig angesehen werden, da sie sich gegenseitig ergänzen, um kurze Latenzzeiten zu erzielen. Zum Nachweis der kumulativen Wirkung wurden eine OpenStack-Standardkonfiguration und eine modifizierte OpenStack-Konfiguration mit einer definierten Zahl von virtuellen Maschinen und CPU-Kernen durchgeführt. Die Abbildung 2 zeigt den kumulativen Effekt der Empfehlungen. Hieraus ist ersichtlich, dass die Kapazität (Gesamtzahl der Aufrufe) um den Faktor 5 und der Durchsatz (Aufrufe pro Sekunde) um den Faktor 6 erhöht werden.

Dan Teichman.
Dan Teichman. (Bild: Sonus Network)

Als Experte in den Bereichen Sicherheit, Interworking und Optimierung für die Echtzeitkommunikation werden wir die Tests im Labor fortsetzen und die Resultate aus realistischen Proof-of-Concepts und Produktionsanwendungen auch weiterhin analysieren. Als Unternehmen wird Sonus diese innovativen Lösungen außerdem auch weiterhin für die Open-Source-Community verfügbar machen, um Cloud-native Lösungen voranzubringen und die Performance bei hoher Skalierung für Echtzeit-Kommunikations-VNFs in den virtuellen Cloud-Netzwerken unserer Kunden sicherzustellen.

Über den Autor

Dan Teichman ist Senior Product Marketing Manager bei Sonus.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44904657 / Client-/Server-Administration)