JDM-Architekturübersicht
Grundlegendes zu disaggregiertem Junos OS
Viele Anbieter von Netzwerkgeräten haben ihre Software traditionell an speziell entwickelte Hardware gebunden und ihren Kunden die gebündelte und paketierte Software-Hardware-Kombination verkauft. Mit der disaggregierten Junos OS-Architektur sind die Netzwerkgeräte von Juniper nun auf Netzwerke abgestimmt, die cloudorientiert und offen sind und auf flexibleren Implementierungsszenarien basieren.
Das Grundprinzip der disaggregierten Junos OS-Architektur ist die Zerlegung (Disaggregation) der eng gebundenen Junos OS-Software und proprietärer Hardware in virtualisierte Komponenten, die möglicherweise nicht nur auf Hardware von Juniper Networks, sondern auch auf Whiteboxen oder Bare-Metal-Servern ausgeführt werden können. In dieser neuen Architektur ist der Juniper Gerätemanager (JDM) ein virtualisierter Root-Container, der Softwarekomponenten verwaltet.
JDM ist der einzige Root-Container in der disaggregierten Junos OS-Architektur (es gibt andere Branchenmodelle, die mehr als einen Root-Container zulassen, aber die disaggregierte Junos OS-Architektur gehört nicht dazu). Das disaggregierte Junos OS ist ein Single-Root-Modell . Eine der wichtigsten Funktionen von JDM besteht darin, zu verhindern, dass Änderungen und Aktivitäten auf der Plattform das zugrunde liegende Host-Betriebssystem (normalerweise Linux) beeinträchtigen. Als Wurzelentität ist das JDM gut für diese Aufgabe geeignet. Die andere wichtige Funktion von JDM besteht darin, die Hardware des Geräts so ähnlich wie ein traditionelles Junos OS-basiertes physisches System wie möglich aussehen zu lassen. Dies erfordert auch eine Form von Root-Funktionen.
Abbildung 1 zeigt die wichtige Position, die JDM in der Gesamtarchitektur einnimmt.
von Juniper
Eine VNF ist ein konsolidiertes Angebot, das alle Komponenten enthält, die für die Unterstützung einer vollständig virtualisierten Netzwerkumgebung erforderlich sind. Bei einer VNF steht die Netzwerkoptimierung im Mittelpunkt.
JDM ermöglicht:
Management von gast virtualisierten Netzwerkfunktionen (VNFs) während ihres Lebenszyklus.
Installation von Modulen von Drittanbietern.
Bildung von VNF-Serviceketten.
Verwaltung von Gast-VNF-Bildern (deren Binärdateien).
Steuerung des Systembestands und der Ressourcennutzung.
Beachten Sie, dass einige Implementierungen der grundlegenden Architektur eine Packet Forwarding Engine sowie die üblichen Hardware-Ports der Linux-Plattform umfassen. Dies ermöglicht eine bessere Integration der Datenebene von Juniper Networks mit der Bare-Metal-Hardware einer generischen Plattform.
Die disaggregierte Junos OS-Architektur ermöglicht es JDM, virtualisierte Netzwerkfunktionen wie eine Firewall oder Network Address Translation (NAT)-Funktionen zu verarbeiten. Die anderen in JDM integrierten VNFs und Container können Produkte von Juniper Networks oder Produkte von Drittanbietern als native Linux-Anwendungen sein. Die grundlegende Architektur des disaggregierten Junos OS ist schematisch in Abbildung 2 dargestellt.
Es gibt mehrere Möglichkeiten, die grundlegende disaggregierte Junos OS-Architektur auf verschiedenen Plattformen zu implementieren. Die Details können stark variieren. In diesem Thema wird die allgemeine Architektur beschrieben.
Die Virtualisierung des einfachen Softwareprozesses, der auf fester Hardware läuft, stellt im Bereich der Interprozesskommunikation mehrere Herausforderungen dar. Wie funktioniert beispielsweise eine VNF mit NAT-Funktion mit einer Firewall, die als Container auf demselben Gerät ausgeführt wird? Schließlich kann es nur einen oder zwei externe Ethernet-Ports auf dem gesamten Gerät geben, und die Prozesse sind immer noch geräteintern. Ein Vorteil ist die Tatsache, dass die Schnittstellen zwischen diesen virtualisierten Prozessen oft selbst virtualisiert werden, vielleicht als SXE-Ports; das bedeutet, dass Sie eine Art VON MAC-Layer-Bridge zwischen Prozessen direkt oder zwischen einem Prozess und dem Hostbetriebssystem und dann zwischen dem Hostbetriebssystem und einem anderen Prozess konfigurieren können. Dies unterstützt die Verkettung von Services, wenn Datenverkehr das Gerät ein- und verlässt.
JDM bietet Benutzern eine vertraute Junos OS CLI und verarbeitet alle Interaktionen mit dem zugrunde liegenden Linux-Kernel, um das "Aussehen und Gefühl" eines Geräts von Juniper Networks zu erhalten.
Einige der Vorteile des disaggregierten Junos OS sind:
Das gesamte System kann wie die Verwaltung einer Serverplattform verwaltet werden.
Kunden können Anwendungen, Tools und Services von Drittanbietern wie Chef, Wiireshark oder Quagga in einer virtuellen Maschine (VM) oder einem Container installieren.
Diese Anwendungen und Tools können mithilfe typischer Linux-Repositories aktualisiert werden und sind unabhängig von Junos OS-Versionen.
Modularität erhöht die Zuverlässigkeit, da Fehler im Modul enthalten sind.
Die Steuerungs- und Datenebene kann direkt über APIs programmiert werden.
Grundlegendes zu physischen und virtuellen Komponenten
In der disaggregierten Junos OS Network Functions Virtualization (NFV)-Umgebung können die Gerätekomponenten physisch oder virtuell sein. Die gleiche physisch-virtuelle Unterscheidung kann auf Schnittstellen (Ports), die Pfade, die Pakete oder Frames das Gerät nehmen, und andere Aspekte wie CPU-Cores oder Festplattenspeicher angewendet werden.
Die disaggregierte Junos OS-Spezifikation enthält ein Architekturmodell. Das architektonische Modell eines Hauses kann Anweisungen für eine Küche, ein Dach und ein Esszimmer haben und kann verschiedene Arten von Wohnungen darstellen; von einem Ferienhaus am Meer bis zu einem palastartigen Herrenhaus. Alle diese Häuser sehen sehr anders aus, folgen aber dennoch einem grundlegenden Architekturmodell und teilen viele Merkmale.
Ebenso decken die Modelle im Fall der disaggregierten Junos OS-Architekturmodelle sehr unterschiedliche Arten von Plattformen ab, von einfachen CpE-Geräten (Customer Premises Equipment) bis hin zu komplexen Switching-Geräten, die in einem großen Datencenter installiert werden, haben aber einige grundlegende Merkmale, die die Plattformen gemeinsam haben.
Welche Merkmale haben diese Plattformen? Alle disaggregierten Junos OS-Plattformen basieren auf drei Ebenen. Diese Ebenen und einige mögliche Inhalte sind in Abbildung 3 dargestellt.
Die unterste Ebene ist die Hardwareschicht. Neben Arbeitsspeicher (RAM) und Festplattenspeicher (SSD) verfügt die Plattformhardware über eine Multi-Core-CPU mit einem externen NIC-Port, der für die Verwaltung verwendet wird. In einigen Fällen wird ein einzelner NIC-Port für die Steuerungs- und Datenebene verwendet, aber dieser Port kann auch für die Kommunikation mit einer Packet Forwarding Engine für Benutzerdatenströme verwendet werden.
Die Plattformsoftwareschicht sitzt auf der Hardwareschicht. Hier finden alle plattformabhängigen Funktionen statt. Diese Funktionen können eine Software-Switching-Funktion für verschiedene virtuelle Komponenten umfassen, um den Datenverkehr zwischen ihnen zu überbrücken. Eine Linux- oder Kernel-basierte virtuelle Maschine (KVM) führt die Plattform aus, und in einigen Modellen kontaktiert ein Telefon-Home-Agent einen Anbieter oder ein Service Provider-Gerät, um Autokonfigurationsaufgaben durchzuführen. Der Phone Home Agent wird besonders für kleinere CPE-Plattformen bevorzugt.
Über der Plattformsoftwareschicht befindet sich die Kundensoftwareschicht, die verschiedene plattformunabhängige Funktionen bietet. Einige der Komponenten können virtuelle Maschinen von Juniper Networks sein, z. B. ein virtuelles SRX-Gerät (vSRX) oder die Junos Control Plane (JCP). Der JCP arbeitet mit dem JDM zusammen, um das Gerät wie eine dedizierte Plattform von Juniper Networks zu machen, die jedoch viel mehr Flexibilität bietet. Ein Großteil dieser Flexibilität ergibt sich aus der Fähigkeit, ein oder mehrere VNFs zu unterstützen, die eine virtualisierte Netzwerkfunktion (VNF) implementieren. Diese VNFs bestehen aus vielen Arten von Aufgaben, wie Network Address Translation (NAT), spezialisierten DNS-Server-Suchen und so weiter.
Im Allgemeinen gibt es eine feste Anzahl von CPU-Cores und einen begrenzten Speicherplatz. In einer virtuellen Umgebung ist die Ressourcenzuweisung und -nutzung jedoch komplexer. Virtuelle Ressourcen wie Schnittstellen, Festplattenspeicher, Speicher oder Cores werden gemäß dem VNF-Image auf die zu diesem Zeitpunkt ausgeführten VNFs aufgeteilt.
Die VNFs, egal ob virtuelle Maschinen (VMs) oder Container, die sich das physische Gerät teilen, sind oft erforderlich, um miteinander zu kommunizieren. Pakete oder Frames gelangen über eine physische Schnittstelle (einen Port) in ein Gerät und werden an einige anfängliche VNF verteilt. Nach einer Verarbeitung des Datenverkehrsstroms leitet die VNF den Datenverkehr an eine andere VNF weiter, wenn dies so konfiguriert ist, und dann an eine andere, bevor der Datenverkehr das physische Gerät verlässt. Diese VNFs bilden eine Servicekette auf der Data Plane, die innerhalb des Geräts durchquert wird.
Wie leiten die VNFs, bei denen es sich um isolierte VMs oder Container handelt, den Datenverkehr von einem zum anderen? Die Servicekette ist so konfiguriert, dass der Datenverkehr von einer physischen Schnittstelle an eine oder mehrere interne virtuelle Schnittstellen weitergeleitet wird. Daher gibt es virtuelle NICs, die mit jeder VM oder jedem Container verbunden sind, die alle über einen virtuellen Switch oder eine Bridge-Funktion innerhalb des Geräts verbunden sind. Diese generische Beziehung, die die Kommunikation zwischen physischen und virtuellen Schnittstellen ermöglicht, ist in Abbildung 4 dargestellt.
zwischen physischen und virtuellen Komponenten
In diesem allgemeinen Modell, das Abweichungen von verschiedenen Plattformen aufweisen kann, werden Daten über einen Port der physischen Netzwerkkarte eingegeben und über die virtuelle Switch-Funktion auf Grundlage der ZIEL-MAC-Adresse zur virtuellen Maschine1 bis virtual NIC 1 überbrückt. Der Datenverkehr kann auch über eine andere konfigurierte virtuelle Schnittstelle zu Virtual Machine2 oder mehr VNFs überbrückt werden, bis er wieder an einen physischen Port übergeben wird und das Gerät verlässt.
Zu Konfigurationszwecken können diese Schnittstellen bekannte Bezeichnungen wie ge-0/0/0 oder fxp0 oder neue Bezeichnungen wie sxe0 oder hsxe0 haben. Manche sind zwar real, aber interne Ports (z. B. sxe0) und andere können vollständig virtuelle Konstrukte (wie hsxe0) sein, die für den Betrieb des Geräts erforderlich sind.
Disaggregierte Junos OS-VMs
Cloud-Computing ermöglicht die Ausführung von Anwendungen in einer virtualisierten Umgebung, sowohl für Serverfunktionen des Endbenutzers als auch für Netzwerkfunktionen, die für die Verbindung von verstreuten Endgeräten in einem großen Datencenter oder sogar zwischen mehreren Datencentern erforderlich sind. Anwendungen und Netzwerkfunktionen können durch virtualisierte Netzwerkfunktionen (VNFs) implementiert werden. Was sind die Unterschiede zwischen diesen beiden Arten von Paketen und warum sollte jemand den einen oder den anderen Typ verwenden?
Sowohl VNFs als auch Container ermöglichen das Multiplexing von Hardware mit Zehntausenden oder Hunderten von VNFs, die sich einen physischen Server teilen. Dies ermöglicht nicht nur eine schnelle Bereitstellung neuer Services, sondern auch die Erweiterung und Migration von Workloads in Zeiten starker Nutzung (wenn Erweiterung verwendet werden kann) oder physische Wartung (wenn eine Migration verwendet werden kann).
In einer Cloud-Computing-Umgebung ist es üblich, VNFs zu verwenden, um die schwere Arbeit auf den riesigen Serverfarmen zu erledigen, die Big Data in modernen Netzwerken charakterisieren. Mit der Servervirtualisierung können Anwendungen, die für verschiedene Entwicklungsumgebungen, Hardwareplattformen oder Betriebssysteme geschrieben wurden, auf generischer Hardware ausgeführt werden, auf der eine entsprechende Softwaresuite ausgeführt wird.
VNFs sind auf einen Hypervisor angewiesen, um die physische Umgebung zu verwalten und Ressourcen den VNFs zuzuweisen, die zu einer bestimmten Zeit ausgeführt werden. Zu den beliebten Hypervisoren gehören Xen, KVM und VMWare ESXi, aber es gibt noch viele andere. Die VNFs werden im Benutzerbereich auf dem Hypervisor ausgeführt und umfassen eine vollständige Implementierung des Betriebssystems der VM-Anwendung. Beispielsweise kann eine Anwendung, die in der Sprache C++ geschrieben wurde und auf dem Betriebssystem Microsoft Windows ausgeführt wird, auf einem Linux-Betriebssystem mit dem Hypervisor ausgeführt werden. In diesem Fall ist Windows ein Gastbetriebssystem.
Der Hypervisor bietet dem Gastbetriebssystem eine emulierte Ansicht der Hardware der VNFs. Neben anderen Ressourcen wie Festplattenspeicher bietet der Hypervisor eine virtualisierte Ansicht der Netzwerkschnittstellenkarte (NIC), wenn sich Endgeräte für verschiedene VMs auf verschiedenen Servern oder Hosts befinden (eine häufige Situation). Der Hypervisor verwaltet die physischen NICs und stellt den VNFs nur virtualisierte Schnittstellen zur Verfügung.
Der Hypervisor führt auch eine virtuelle Switch-Umgebung aus, die es den VNFs auf der VLAN-Frameschicht ermöglicht, Pakete innerhalb desselben Pakets oder über ein (virtuelles) Netzwerk auszutauschen.
Der größte Vorteil von VNFs besteht darin, dass die meisten Anwendungen einfach auf die Hypervisor-Umgebung portiert werden können und ohne Änderungen gut ausgeführt werden können.
Der größte Nachteil ist, dass der ressourcenintensive Overhead des Gastbetriebssystems oft eine vollständige Version des Betriebssystems enthalten muss, auch wenn die Funktion der gesamten VNF darin besteht, einen einfachen Service wie ein Domain Name System (DNS) bereitzustellen.
Container sind im Gegensatz zu VNFs speziell darauf ausgelegt, als unabhängige Aufgaben in einer virtuellen Umgebung ausgeführt zu werden. Container bündeln nicht wie VNFs ein gesamtes Betriebssystem darin. Container können auf viele Arten codiert und gebündelt werden, aber es gibt auch Möglichkeiten, Standard-Container zu erstellen, die einfach zu warten und zu erweitern sind. Standard-Container sind viel offener als container, die zufällig erstellt werden.
Standard-Linux-Container definieren eine Einheit der Softwarebereitstellung, die als Standard-Container bezeichnet wird. Anstatt das gesamte Gastbetriebssystem zu verkapseln, verkapselt der Standard-Container nur die Anwendung und alle Abhängigkeiten, die zum Ausführen der Aufgabe erforderlich sind, für die die Anwendung programmiert ist. Dieses einzelne Laufzeitelement kann geändert werden, aber dann muss der Container neu erstellt werden, um zusätzliche Abhängigkeiten zu enthalten, die die erweiterte Funktion möglicherweise benötigt. Die allgemeine Architektur von Containern in Abbildung 5.
Die Container laufen auf dem Host-Betriebssystem-Kernel und nicht auf dem Hypervisor. Die Container-Architektur verwendet eine Container-Engine zur Verwaltung der zugrunde liegenden Plattform. Wenn Sie weiterhin VNFs ausführen möchten, kann der Container auch eine komplette Hypervisor- und Gastbetriebssystemumgebung paketieren.
Standard-Container umfassen:
Eine Konfigurationsdatei.
Eine Reihe von Standardoperationen.
Eine Ausführungsumgebung.
Der Name Container ist den Versandbehältern entlehnt, die für den Transport von Waren auf der ganzen Welt verwendet werden. Versandcontainer sind Standardzustelleinheiten, die durch Ausrüstung, die speziell für die Container entwickelt wurden, beladen, gekennzeichnet, gestapelt, angehoben und entladen werden können. Unabhängig davon, was sich im Inneren befindet, kann der Container standardmäßig gehandhabt werden, und jeder Container hat einen eigenen Benutzerbereich, der von anderen Containern nicht verwendet werden kann. Obwohl Docker ein beliebtes Containermanagementsystem ist, um Container auf einem physischen Server auszuführen, gibt es Alternativen wie Drawbridge oder Rocket in Betracht zu ziehen.
Jedem Container wird eine virtuelle Schnittstelle zugewiesen. Container-Managementsysteme wie Docker umfassen eine virtuelle Ethernet-Brücke, die mehrere virtuelle Schnittstellen und die physische Netzwerkkarte verbindet. Konfigurations- und Umgebungsvariablen im Container bestimmen, welche Container miteinander kommunizieren können, welche das externe Netzwerk verwenden können usw. Externe Netzwerke werden normalerweise mit NAT durchgeführt, obwohl es andere Methoden gibt, da Container oft den gleichen Netzwerkadressraum verwenden.
Der größte Vorteil von Containern besteht darin, dass sie auf einem Gerät geladen und viel schneller ausgeführt werden können als VNFs. Container nutzen Ressourcen auch viel sparsamer– Sie können viel mehr Container als VNFs auf derselben Hardware ausführen. Dies liegt daran, dass Container weder ein vollständiges Gastbetriebssystem noch eine Startzeit erfordern. Container können in Millisekunden und nicht in wenigen Sekunden geladen und ausgeführt werden. Der größte Nachteil bei Containern besteht jedoch darin, dass sie speziell so geschrieben werden müssen, dass sie mit einigen Standards oder gängigen Implementierungen übereinstimmen, während VNFs in ihrem nativen Zustand ausgeführt werden können.
Virtio- und SR-IOV-Nutzung
Sie können die Kommunikation zwischen einem Linux-basierten virtualisierten Gerät und einem Network Functions Virtualization (NFV)-Modul entweder mithilfe von virtio oder durch verwendung geeigneter Hardware und Single-Root-E/A-Virtualisierung (SR-IOV) ermöglichen. Jede Methode hat unterschiedliche Merkmale.
Verständnis der Virtio-Nutzung
Wenn ein physisches Gerät virtualisiert wird, existieren sowohl physische NIC-Schnittstellen und externe physische Switches als auch virtuelle NIC-Schnittstellen und interne virtuelle Switches. Wenn also die isolierten VNFs im Gerät mit jeweils eigenen Speicher-, Festplattenspeicher- und CPU-Zyklen versuchen, miteinander zu kommunizieren, stellen die verwendeten mehrere Ports, MAC-Adressen und IP-Adressen eine Herausforderung dar. Mit der virtio Library wird der Datenverkehr zwischen den isolierten virtuellen Funktionen einfacher und einfacher.
Virtio ist Teil der standardmäßigen Linux libvirt-Bibliothek mit nützlichen Virtualisierungsfunktionen und wird normalerweise in den meisten Linux-Versionen enthalten. Virtio ist ein rein softwarebasierter Ansatz für die VNF-Kommunikation zwischen VNF. Virtio bietet eine Möglichkeit, einzelne virtuelle Prozesse zu verbinden. Die gebündelte Natur von virtio ermöglicht es jedem Linux-Gerät, virtio zu verwenden.
Virtio ermöglicht VNFs und Containern die Verwendung einfacher interner Bridges zum Senden und Empfangen von Datenverkehr. Der Verkehr kann immer noch über eine externe Brücke ankommen und verlassen. Eine externe Bridge verwendet eine virtualisierte interne NIC-Schnittstelle an einem Ende der Brücke und eine physische externe NIC-Schnittstelle am anderen Ende der Bridge, um Pakete und Frames zu senden und zu empfangen. Eine interne Brücke, von der es mehrere Arten gibt, verbindet zwei virtualisierte interne NIC-Schnittstellen, indem sie sie über eine virtualisierte interne Switch-Funktion im Hostbetriebssystem überbrückt. Die gesamte Architektur von virtio ist in Abbildung 6 dargestellt.
Abbildung 6 zeigt die innere Struktur eines Servergeräts mit einer einzigen physischen NIC-Karte, auf der ein Host-Betriebssystem ausgeführt wird (die äußere Abdeckung des Geräts ist nicht dargestellt). Das Host-Betriebssystem enthält den virtuellen Switch oder die Bridge, die mit virtio implementiert wurde. Über dem Betriebssystem verwenden mehrere virtuelle Maschinen virtuelle NICs, die über virtio kommunizieren. Es werden mehrere virtuelle Maschinen ausgeführt, in der Abbildung mit der Nummer 1 bis N. Die Standard-Notation "Punktpunkt" zeigt mögliche virtuelle Maschinen und NICs an, die in der Abbildung nicht dargestellt sind. Die gestrichelten Linien zeigen mögliche Datenpfade mithilfe von virtio an. Beachten Sie, dass Datenverkehr, der das Gerät ein- oder verlässt, dies über die physische Netzwerkkarte und den Port tut.
Abbildung 6 zeigt auch den Datenverkehr, der das Gerät über die interne Brücke ein- und verlässt. Virtuelle Maschine 1 verknüpft ihre virtualisierte interne NIC-Schnittstelle mit der physischen externen NIC-Schnittstelle. Virtual Machine 2 und Virtual Machine N verbinden interne virtuelle NICs über die interne Brücke im Hostbetriebssystem. Beachten Sie, dass ihnen VLAN-Label oder interne Schnittstellennamen zugeordnet sind. Frames, die über diese interne Brücke zwischen VNFs gesendet werden, verlassen das Gerät nie. Beachten Sie die Position der Bridge (und der virtualisierten Switch-Funktion) im Host-Betriebssystem. Beachten Sie die Verwendung eines einfachen Bridgings im Gerät. Diese Bridges können entweder mit regulären Linux-Befehlen oder der Verwendung von CLI-Konfigurationsanweisungen konfiguriert werden. Zur Automatisierung des Prozesses können Skripte verwendet werden.
Virtio ist ein Virtualisierungsstandard für Festplatten- und Netzwerkgerätetreiber. Nur der Gastgerätetreiber (der Gerätetreiber für die virtualisierten Funktionen) muss wissen , dass er in einer virtuellen Umgebung ausgeführt wird. Diese Treiber arbeiten mit dem Hypervisor zusammen und die virtuellen Funktionen erhalten Leistungsvorteile als Gegenleistung für zusätzliche Komplikationen. Virtio ist architektonisch ähnlich wie Xen paravirtualisierte Gerätetreiber (Treiber, die einem Gast hinzugefügt werden, um sie bei der Ausführung auf Xen schneller zu machen). Auch die Gast-Tools von VMWare sind virtio ähnlich.
Beachten Sie, dass ein Großteil des Datenverkehrs auf die CPU des Hostbetriebssystems konzentriert wird – genauer gesagt auf die virtualisierten internen Bridges. Daher muss die Host-CPU in der Lage sein, bei der Skalierung des Geräts angemessen zu arbeiten.
Grundlegendes zur SR-IOV-Nutzung
Wenn ein physisches Gerät virtualisiert wird, existieren sowohl NIC-Schnittstellen (Physical Network Interface Card)-Schnittstellen und externe physische Switches als auch virtuelle NIC-Schnittstellen und interne virtuelle Switches. Wenn also die isolierten virtuellen Maschinen (VMs) oder Container im Gerät mit jeweils eigenen Speicher-, Festplattenspeicher- und CPU-Zyklen versuchen, miteinander zu kommunizieren, stellen die verwendeten mehrere Ports, MAC-Adressen und IP-Adressen eine Herausforderung dar.
SR-IOV erweitert das Konzept der virtualisierten Funktionen auf die physische Netzwerkkarte . Die einzelne physische Karte ist in bis zu 16 Partitionen pro physischem NIC-Port unterteilt, die den virtuellen Funktionen auf den höheren Ebenen entsprechen. Die Kommunikation zwischen diesen virtuellen Funktionen wird genauso gehandhabt, wie die Kommunikation zwischen Geräten mit individuellen Netzwerkkarten üblicherweise über eine Brücke gehandhabt wird. SR-IOV umfasst eine Reihe von Standardmethoden für das Erstellen, Löschen, Aufzählen und Abfragen des SR-IOV NIC-Switches sowie die Standardparameter, die festgelegt werden können.
Der Single-Root-Teil von SR-IOV bezieht sich auf die Tatsache, dass es wirklich nur einen primären Teil der Netzwerkkarte gibt, der alle Vorgänge steuert. Eine SR-IOV-fähige Netzwerkkarte ist nur ein Standard-Ethernet-Port, der die gleiche physische Bit-für-Bit-Funktion wie jede Netzwerkkarte bietet.
Das SR-IOV bietet jedoch auch mehrere virtuelle Funktionen, die durch einfache Warteschlangen zur Bearbeitung von Ein- und Ausgabeaufgaben erledigt werden. Jede auf dem Gerät ausgeführte VNF wird einer dieser NIC-Partitionen zugeordnet, sodass VNFs selbst direkten Zugriff auf NIC-Hardwareressourcen haben. Die Netzwerkkarte verfügt außerdem über eine einfache Layer-2-Sortierfunktion, die Frames in Datenverkehrswarteschlangen klassifiziert. Pakete werden mithilfe von Direct Memory Access (DMA) direkt zu und von der virtuellen Netzwerkfunktion in den Vm-Speicher verschoben, wobei der Hypervisor vollständig umgangen wird. Die Rolle der Netzwerkkarte im SR-IOV-Vorgang ist in Abbildung 7 dargestellt.
Der Hypervisor ist weiterhin an der Zuweisung der VNFs zu den virtuellen Netzwerkfunktionen und an der Verwaltung der physischen Karte beteiligt, nicht aber an der Übertragung der Daten innerhalb der Pakete. Beachten Sie, dass die Kommunikation zwischen VNF und VNF von Virtual NIC 1, Virtual NIC 2 und Virtual NIC N durchgeführt wird. Es gibt auch einen Teil der Netzwerkkarte (nicht angezeigt), der alle virtuellen Funktionen und den Sortierer verfolgt, um den Datenverkehr zwischen den VNFs und externen Geräteports zu übertragen.
Beachten Sie, dass die Fähigkeit zur Unterstützung von SR-IOV von der Plattformhardware, insbesondere der NIC-Hardware, und der Software der VNFs oder Container abhängt, um DMA für die Datenübertragung zu verwenden. Partitionierbare NICs und das erforderliche interne Bridging sind tendenziell teurer, wodurch ihre Verwendung die Kosten für kleinere Geräte spürbar erhöhen kann. Das Umschreiben von VNFs und Containern ist auch keine triviale Aufgabe.
Vergleich von Virtio und SR-IOV
Virtio ist Teil der standardmäßigen libvirt-Bibliothek hilfreicher Virtualisierungsfunktionen und wird normalerweise in den meisten Linux-Versionen enthalten. Virtio verfolgt einen rein softwarebasierten Ansatz. SR-IOV erfordert Software, die auf eine bestimmte Weise geschrieben ist, und spezielle Hardware, was auch bei einem einfachen Gerät eine Kostensteigerung bedeutet.
Im Allgemeinen ist die Verwendung von virtio schnell und einfach. Libvirt ist Teil jeder Linux-Distribution und die Befehle zum Aufbau der Brücken sind gut verstanden. Virtio belastet jedoch die gesamte Leistung auf das Hostbetriebssystem, das normalerweise den gesamten Datenverkehr zwischen VNFs in und aus dem Gerät überbrückt.
Im Allgemeinen kann SR-IOV eine geringere Latenz und eine niedrigere CPU-Auslastung bieten – kurz gesagt, fast native, nicht virtuelle Geräteleistung. Die VNF-Migration von einem Gerät zum anderen ist jedoch komplex, da die VNF von den NIC-Ressourcen auf einem Computer abhängig ist. Außerdem befindet sich der Weiterleitungsstatus für die VNF im Layer 2-Switch, der in die SR-IOV-NIC integriert ist. Aus diesem Grund ist die Weiterleitung nicht mehr ganz so flexibel, da die Regeln für die Weiterleitung in die Hardware codiert sind und nicht oft geändert werden können.
Während die Unterstützung für virtio nahezu universell ist, variiert die Unterstützung für SR-IOV je nach NIC-Hardware und -Plattform. Die NFX250 Network Services Platform von Juniper Networks unterstützt SR-IOV-Funktionen und erlaubt 16 Partitionen an jedem physischen NIC-Port.
Beachten Sie, dass eine bestimmte VNF bei Unterstützung entweder virtio oder SR-IOV oder sogar beide Methoden gleichzeitig verwenden kann.
Virtio ist die empfohlene Methode für den Aufbau einer Verbindung zwischen einem virtualisierten Gerät und einem NFV-Modul.