Virtualisierung des Gi-LAN – Was man tun und lassen sollte
Nach vielen Jahren der Diskussionen und Proof of Concepts bewegt sich die Virtualisierung von Netzwerkfunktionen (NFV) nun von der Konzeptions- zur Realisierungsphase.
Einige Dienstanbieter haben mit der Einführung von NFV-Infrastrukturplattformen begonnen, und einige von ihnen haben bereits ihre ersten NFV-fähigen Anwendungsfälle und Anwendungen auf diesen Plattformen aktiviert.
Die Virtualisierung des Evolved Packet Core (EPC) und des Gi-LAN ist einer der Anwendungsfälle, der derzeit in der Branche auf große Resonanz stößt.
Beim Bereitstellen eines virtuellen Gi-LAN müssen zwei grundlegende Fragen beantwortet werden. Die erste Frage betrifft die Konsolidierung: Konsolidieren wir mehrere Gi-LAN-Funktionen in einer einzigen virtuellen Netzwerkfunktion (VNF) oder zerlegen wir die Gi-LAN-Architektur vollständig in viele diskrete VNFs?
Die zweite Frage betrifft den Maßstab. Wie können wir diese Architektur effektiv skalieren, da eine einzelne virtuelle Maschine möglicherweise nicht genügend Kapazität bietet, um die Gi-LAN-Arbeitslast zu bewältigen?
Um ihre Netzwerke zu sichern und zu monetarisieren, haben Mobilfunkbetreiber viele verschiedene Technologien im Gi-LAN eingesetzt, darunter unter anderem TCP-Optimierung, Videooptimierung, Header-Anreicherung, Deep Packet Inspection, Gi-Firewalling und Carrier-Grade NAT (CGNAT).
In der Vergangenheit wurden viele dieser Funktionen auf unterschiedlichen Plattformen bereitgestellt, häufig von unterschiedlichen Anbietern. In den letzten Jahren haben Mobilfunkbetreiber ihre Gi-LAN-Architektur konsolidiert und vereinfacht.
Durch die Konsolidierung konnten Mobilfunkbetreiber ihre Gesamtbetriebskosten deutlich senken. Bei der Migration dieser Architektur auf eine NFV-Plattform – die auf handelsüblicher Hardware basiert – besteht möglicherweise die Versuchung, die Architektur in verschiedene diskrete VNFs zu zerlegen, die jeweils einer einzigen Funktion gewidmet sind.
Diese zerlegte Architektur ist sicherlich sinnvoll, wenn die verschiedenen Gi-LAN-Funktionen jeweils auf eine sehr spezifische Teilmenge von Flows anwendbar sind. Basierend auf Geschäftsrichtlinien und durch Interaktion mit einer PCRF (Policy and Charging Rules Function) kann eine intelligente Service-Klassifizierungs-Engine am Eingang des Gi-LAN bestimmen, welche Flows gelenkt und/oder an bestimmte Funktionen verkettet werden müssen, die als separate VNFs bereitgestellt werden. Diese VNFs müssen dann nur den Datenverkehr verarbeiten, auf den sie reagieren müssen, was zu einer sehr effizienten Verteilung des Datenverkehrs auf alle VNFs führt.
Wenn Gi-LAN-Funktionen jedoch auf fast den gesamten Datenverkehr angewendet werden müssen, bringt diese Funktionszerlegung keinen Mehrwert. Nehmen Sie als Beispiele TCP-Optimierung und Gi-Firewalls. Fast der gesamte Gi-LAN-Verkehr muss von diesen beiden Funktionen verarbeitet werden. Die Konsolidierung in einer einzigen VNF führt daher zu Effizienzgewinnen, die mit einer physischen Bereitstellung vergleichbar sind.
Tatsächlich ist hier kein intelligenter Service-Klassifizierer erforderlich, um eine VNF-Auswahl zu treffen, und es ist kein „Hair-Pinning“ in und aus der SDN-Schicht erforderlich, um den Datenverkehr von einer VNF zur nächsten zu leiten. Darüber hinaus verursacht das Hinzufügen einer Firewall-Funktion zusätzlich zu einer TCP-Optimierungsfunktion nur einen sehr geringen CPU-Overhead, sodass der Wert der Konsolidierung auch in einer NFV-Umgebung gilt.
Eine weitere Herausforderung besteht darin, mit Arbeitsabläufen umzugehen, die größer sind als die, die eine einzelne VNF verarbeiten kann. Einige Anbieter verfolgen den Ansatz, eine VNF aus vielen virtuellen Maschinen (VMs) bestehen zu lassen. Bei den meisten Funktionen im Gi-LAN handelt es sich um zustandsbehaftete Vorgänge, was bedeutet, dass der ein- und ausgehende Datenverkehr für dieselben Flows auf derselben VM verarbeitet werden muss. Wenn ausgehender Datenverkehr auf einer anderen VM ankommt, die den eingehenden Datenverkehr verarbeitet hat, ist daher eine Kommunikation zwischen den VMs erforderlich, um den Datenverkehr zurück an die richtige VM zu leiten. Dies führt offensichtlich zu einer Verschlechterung der Leistung.
Bei F5 haben wir den Ansatz gewählt, bei dem eine VNF immer als einzelne VM bereitgestellt wird und die Skalierung der Architektur auf mehrere VMs zu einem externen Designfaktor wird. Es stehen verschiedene Scale-Out-Techniken zur Verfügung, von sehr einfach bis hochentwickelt.
Eine sehr einfache Scale-Out-Architektur basiert auf IP-basiertem Traffic-Hashing über die verschiedenen VMs hinweg, wie etwa Equal Cost Multipath (ECMP). Diese Technik weist jedoch mehrere Nachteile auf und ist für die meisten Anwendungsfälle im Gi-LAN unpraktisch. SDN-basierte Ansätze zur Steuerung der Verkehrsverteilung können einige dieser ECMP-Einschränkungen vermeiden, die Funktionen wären jedoch immer noch etwas eingeschränkt und hängen stark vom gewählten SDN-Player ab.
Der bei weitem flexibelste und fortschrittlichste Ansatz zum Skalieren beliebiger Gi-LAN-Funktionen, die völlig unabhängig vom zugrunde liegenden Netzwerk und/oder SDN sind, wird durch einen zustandslosen, softwarebasierten Load Balancer bereitgestellt (der ebenfalls als VMs bereitgestellt wird). Die Tatsache, dass es zustandslos ist, ermöglicht eine nahezu unbegrenzte Skalierung, da weitere VMs für zustandslosen Lastausgleich hinzugefügt werden können, ohne dass die Konsistenz der Verkehrsverteilung auf die VMs, die die Gi-LAN-Funktionen bereitstellen, verloren geht.
Auf dieser Grundlage halten wir es für sehr wichtig, dass alle Mobilfunkbetreiber bei der Migration ihrer Gi-LAN-Architektur von der physischen auf die virtuelle Ebene sowohl die Konsolidierungs- als auch die Skalierungsaspekte sorgfältig bedenken.