Überblick über die JDM-Architektur
Verständnis von disaggregiertem Junos OS
Viele Anbieter von Netzwerkgeräten haben ihre Software traditionell an speziell entwickelte Hardware gebunden und ihren Kunden die gebündelte und verpackte Software-Hardware-Kombination verkauft. Mit der disaggregierten Junos OS-Architektur sind die Geräte von Juniper Network nun jedoch auf Netzwerke ausgerichtet, die Cloud-orientiert und offen sind und auf flexiblere Implementierungsszenarien angewiesen sind.
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 potenziell nicht nur auf der Hardware von Juniper Networks, sondern auch auf White Boxen oder Bare-Metal-Servern ausgeführt werden können. In dieser neuen Architektur ist der Juniper Device Manager (JDM) ein virtualisierter Root-Container, der Softwarekomponenten verwaltet.
Das 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 Hauptfunktionen von JDM besteht darin, zu verhindern, dass Änderungen und Aktivitäten auf der Plattform das zugrunde liegende Host-Betriebssystem (normalerweise Linux) beeinträchtigen. Als Root-Entity ist das JDM für diese Aufgabe gut geeignet. Die andere wichtige Funktion von JDM besteht darin, die Hardware des Geräts so weit wie möglich wie ein herkömmliches, auf Junos OS basierendes physisches System aussehen zu lassen. Dies erfordert auch eine Form von Root-Funktionen.
Abbildung 1 veranschaulicht die wichtige Stellung, die JDM in der Gesamtarchitektur einnimmt.
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 liegt der Schwerpunkt auf der Netzwerkoptimierung.
JDM ermöglicht:
-
Verwaltung von virtualisierten Gastfunktionen (VNFs) während ihres Lebenszyklus.
-
Installation von Modulen von Drittanbietern.
-
Bildung von VNF-Serviceketten.
-
Verwaltung von Gast-VNF-Images (deren Binärdateien).
-
Kontrolle des Systembestands und der Ressourcennutzung.
Beachten Sie, dass einige Implementierungen der Basisarchitektur eine Packet Forwarding Engine sowie die üblichen Hardwareports der Linux-Plattform enthalten. Dies ermöglicht eine bessere Integration der Data Plane 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 in Abbildung 2 schematisch dargestellt.
Es gibt mehrere Möglichkeiten, die grundlegende disaggregierte Junos OS-Architektur auf verschiedenen Plattformen zu implementieren. Details können sehr unterschiedlich sein. In diesem Thema wird die Gesamtarchitektur beschrieben.
Die Virtualisierung des einfachen Softwareprozesses, der auf fester Hardware läuft, stellt mehrere Herausforderungen im Bereich der Interprozesskommunikation dar. Wie funktioniert beispielsweise eine VNF mit einer NAT-Funktion mit einer Firewall, die als Container auf demselben Gerät ausgeführt wird? Schließlich gibt es möglicherweise nur einen oder zwei externe Ethernet-Ports auf dem gesamten Gerät, und die Prozesse sind immer noch geräteintern. Ein Vorteil ist die Tatsache, dass die Schnittstellen zwischen diesen virtualisierten Prozessen oft selbst virtualisiert sind, vielleicht als SXE-Ports; Dies bedeutet, dass Sie eine Art MAC-Layer-Bridge zwischen Prozessen direkt oder zwischen einem Prozess und dem Host-Betriebssystem und dann zwischen dem Host-Betriebssystem und einem anderen Prozess konfigurieren können. Dies unterstützt die Verkettung von Diensten, wenn Datenverkehr in das Gerät ein- und ausgeht.
JDM bietet Benutzern eine vertraute Junos OS CLI und verarbeitet alle Interaktionen mit dem zugrunde liegenden Linux-Kernel, um das "Look and Feel" eines Geräts von Juniper Networks beizubehalten.
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-Repositorys aktualisiert werden und sind unabhängig von Junos OS-Versionen.
-
Die Modularität erhöht die Zuverlässigkeit, da Fehler im Modul enthalten sind.
-
Die Steuerungs- und Datenebenen können direkt über APIs programmiert werden.
Physische und virtuelle Komponenten verstehen
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 durch das Gerät nehmen, und andere Aspekte wie CPU-Kerne oder Festplattenspeicher angewendet werden.
Die disaggregierte Junos OS-Spezifikation enthält ein Architekturmodell. Das Architekturmodell eines Hauses kann Anweisungen für die Einbeziehung einer Küche, eines Daches und eines Esszimmers enthalten und verschiedene Arten von Wohnungen darstellen; von einem Ferienhaus am Meer bis zu einem palastartigen Herrenhaus. Alle diese Häuser sehen sehr unterschiedlich aus, folgen aber dennoch einem architektonischen Grundmodell und teilen viele Merkmale.
Auch die disaggregierten Architekturmodelle von Junos OS decken sehr unterschiedliche Arten von Plattformen ab, von einfachen Customer Premises Equipment (CPE) bis hin zu komplexen Switching-Geräten, die in einem großen Datencenter installiert sind.
Welche Merkmale haben diese Plattformen gemeinsam? Alle disaggregierten Junos OS-Plattformen basieren auf drei Ebenen. Diese Ebenen und einige mögliche Inhalte sind in Abbildung 3 dargestellt.
Die unterste Schicht 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 einem Packet Forwarding Engine für Benutzerdatenströme verwendet werden.
Die Plattformsoftwareschicht sitzt auf der Hardwareschicht. Hier finden alle plattformabhängigen Funktionen statt. Zu diesen Funktionen kann eine Software-Switching-Funktion für verschiedene virtuelle Komponenten gehören, um den Datenverkehr zwischen ihnen zu überbrücken. Die Plattform wird von einer Linux- oder kernelbasierten virtuellen Maschine (KVM) ausgeführt, und bei einigen Modellen kontaktiert ein Phone Home-Agent ein Gerät eines Anbieters oder Service Providers, um Autokonfigurationsaufgaben auszuführen. Der Phone Home Agent wird besonders für kleinere CPE-Plattformen bevorzugt.
Oberhalb der Plattformsoftwareschicht befindet sich die Kundensoftwareschicht, die verschiedene plattformunabhängige Funktionen ausführt. Bei einigen Komponenten kann es sich um virtuelle Maschinen von Juniper Networks handeln, z. B. ein virtuelles SRX-Gerät (Virtuelle Firewall vSRX) oder die Junos Control Plane (JCP). Das JCP arbeitet mit dem JDM zusammen, um das Gerät einer dedizierten Plattform von Juniper Networks zu ähneln, jedoch mit viel mehr Flexibilität. Ein Großteil dieser Flexibilität ergibt sich aus der Möglichkeit, eine oder mehrere VNFs zu unterstützen, die eine virtualisierte Netzwerkfunktion (VNF) implementieren. Diese VNFs bestehen aus vielen Arten von Aufgaben, wie z. B. Network Address Translation (NAT), spezielle DNS-Serversuchen (Domain Name System) und so weiter.
Im Allgemeinen gibt es eine feste Anzahl von CPU-Kernen und eine begrenzte Menge an Speicherplatz. In einer virtuellen Umgebung ist die Ressourcenzuweisung und -nutzung jedoch komplexer. Virtuelle Ressourcen wie Schnittstellen, Festplattenspeicher, Arbeitsspeicher oder Kerne werden auf die zu diesem Zeitpunkt ausgeführten VNF aufgeteilt, wie durch das VNF-Image bestimmt.
Die VNFs, ob virtuelle Maschinen (VMs) oder Container, die sich das physische Gerät teilen, müssen häufig miteinander kommunizieren. Pakete oder Frames gelangen über eine physische Schnittstelle (einen Port) in ein Gerät und werden an eine anfängliche VNF verteilt. Nach einer gewissen Verarbeitung des Datenverkehrs leitet die VNF den Datenverkehr an eine andere VNF weiter, sofern dies konfiguriert ist, und dann an eine andere, bevor der Datenverkehr das physische Gerät verlässt. Diese VNF bilden eine Data-Plane-Servicekette, die innerhalb des Geräts durchlaufen wird.
Wie leiten die VNFs, bei denen es sich um isolierte VMs oder Container handelt, den Datenverkehr von einem zum anderen weiter? Die Servicekette ist so konfiguriert, dass Datenverkehr von einer physischen Schnittstelle an eine oder mehrere interne virtuelle Schnittstellen weitergeleitet wird. Daher gibt es virtuelle Netzwerkkarten, die jeder VM oder jedem Container zugeordnet 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
Bei diesem allgemeinen Modell, das je nach Plattform variieren kann, gelangen Daten über einen Port auf der physischen NIC und werden über die Funktion des virtuellen Switch über die virtuelle MAC-Adresse an die virtuelle Maschine1 über die virtuelle MAC-Adresse überbrückt. Der Datenverkehr kann auch über eine andere konfigurierte virtuelle Schnittstelle zu Virtual Machine2 oder mehr VNFs überbrückt werden, bis er an einen physischen Port zurückgeleitet wird und das Gerät verlässt.
Zu Konfigurationszwecken können diese Schnittstellen vertraute Bezeichnungen wie ge-0/0/0 oder fxp0 oder neue Bezeichnungen wie sxe0 oder hsxe0 aufweisen. Einige können real sein, aber interne Ports (z. B. sxe0) und einige können vollständig virtuelle Konstrukte (z. B. hsxe0) sein, die erforderlich sind, um das Gerät betriebsbereit zu machen.
Disaggregierte Junos OS VMs
Cloud Computing ermöglicht die Ausführung von Anwendungen in einer virtualisierten Umgebung, sowohl für Endbenutzer-Serverfunktionen als auch für Netzwerkfunktionen, die für die Verbindung verstreuter Endpunkte 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 anderen Typ verwenden?
Sowohl VNFs als auch Container ermöglichen das Multiplexing von Hardware mit Dutzenden oder Hunderten von VNFs, die sich einen physischen Server teilen. Dies ermöglicht nicht nur die schnelle Bereitstellung neuer Services, sondern auch die Erweiterung und Migration von Workloads in Zeiten hoher Nutzung (wenn die Erweiterung genutzt werden kann) oder der physischen Wartung (wenn die Migration verwendet werden kann).
In einer Cloud-Computing-Umgebung ist es üblich, VNFs für die umfangreiche Serverfarm einzusetzen, die für Big Data in modernen Netzwerken charakteristisch ist. Die Server-Virtualisierung ermöglicht die Ausführung von Anwendungen, die für unterschiedliche Entwicklungsumgebungen, Hardwareplattformen oder Betriebssysteme geschrieben wurden, auf generischer Hardware, auf der eine entsprechende Software-Suite läuft.
VNFs verlassen sich auf einen Hypervisor, um die physische Umgebung zu verwalten und Ressourcen zwischen den zu einem bestimmten Zeitpunkt ausgeführten VNF zuzuweisen. Beliebte Hypervisoren sind Xen, KVM und VMWare ESXi, aber es gibt noch viele andere. Die VNFs werden im Benutzerbereich auf dem Hypervisor ausgeführt und enthalten eine vollständige Implementierung des Betriebssystems der VM-Anwendung. Beispielsweise kann eine Anwendung, die in der Sprache C++ geschrieben und unter dem Betriebssystem Microsoft Windows kompatisiert und ausgeführt wird, mit dem Hypervisor auf einem Linux-Betriebssystem ausgeführt werden. In diesem Fall ist Windows ein Gastbetriebssystem.
Der Hypervisor stellt dem Gastbetriebssystem eine emulierte Ansicht der Hardware der VNF zur Verfügung. Neben anderen Ressourcen wie Speicherplatz oder Arbeitsspeicher 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 Netzwerkkarten und stellt nur virtualisierte Schnittstellen für die VNF bereit.
Auf dem Hypervisor läuft auch eine virtuelle Switch-Umgebung, in der die VNFs auf der VLAN-Frame-Ebene Pakete innerhalb derselben Box oder über ein (virtuelles) Netzwerk austauschen können.
Der größte Vorteil von VNFs besteht darin, dass die meisten Anwendungen einfach in die Hypervisor-Umgebung portiert werden können und ohne Änderungen gut laufen.
Der größte Nachteil besteht darin, dass der ressourcenintensive Overhead des Gastbetriebssystems oft eine vollständige Version des Betriebssystems umfassen muss, selbst wenn die Funktion des gesamten VNF darin besteht, einen einfachen Dienst wie ein Domain Name System (DNS) bereitzustellen.
Container sind im Gegensatz zu VNFs speziell dafür konzipiert, als unabhängige Aufgaben in einer virtuellen Umgebung ausgeführt zu werden. Container bündeln nicht ein ganzes Betriebssystem wie VNFs. Container können auf viele Arten codiert und gebündelt werden, aber es gibt auch Möglichkeiten, Standardcontainer zu bauen, die einfach zu warten und zu erweitern sind. Standardcontainer sind viel offener als willkürlich erstellte Container.
Standard-Linux-Container definieren eine Einheit der Softwarebereitstellung, die als Standardcontainer bezeichnet wird. Anstatt das gesamte Gastbetriebssystem zu kapseln, kapselt der Standardcontainer 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 alle zusätzlichen Abhängigkeiten einzuschließen, die die erweiterte Funktion möglicherweise benötigt. Die Gesamtarchitektur von Containern ist in Abbildung 5 dargestellt.
Die Container werden auf dem Hostbetriebssystemkernel und nicht auf dem Hypervisor ausgeführt. Die Container-Architektur verwendet eine Container-Engine zur Verwaltung der zugrunde liegenden Plattform. Wenn Sie dennoch VNFs ausführen möchten, kann der Container auch einen kompletten Hypervisor und eine Gastbetriebssystemumgebung verpacken.
Zu den Standardcontainern gehören:
-
Eine Konfigurationsdatei.
-
Eine Reihe von Standardoperationen.
-
Eine Ausführungsumgebung.
Der Name Container ist den Schiffscontainern entlehnt, mit denen Waren rund um die Welt transportiert werden. Versandcontainer sind Standard-Liefereinheiten, die von speziell für die Handhabung der Container gebauten Geräten beladen, etikettiert, gestapelt, angehoben und entladen werden können. Unabhängig davon, was sich darin befindet, kann der Container auf standardmäßige Weise behandelt werden, und jeder Container hat seinen eigenen Benutzerbereich, der nicht von anderen Containern verwendet werden kann. Obwohl Docker ein beliebtes Container-Management-System ist, um Container auf einem physischen Server auszuführen, gibt es Alternativen wie Drawbridge oder Rocket, die Sie in Betracht ziehen sollten.
Jedem Container ist eine virtuelle Schnittstelle zugeordnet. Container-Management-Systeme wie Docker umfassen eine virtuelle Ethernet-Bridge, die mehrere virtuelle Schnittstellen und die physische NIC verbindet. Konfigurations- und Umgebungsvariablen im Container bestimmen, welche Container miteinander kommunizieren können, welche das externe Netzwerk nutzen können usw. Externe Netzwerke werden in der Regel mit NAT durchgeführt, obwohl es andere Methoden gibt, da Container oft denselben Netzwerkadressraum verwenden.
Der größte Vorteil von Containern besteht darin, dass sie auf ein Gerät geladen und viel schneller ausgeführt werden können als VNFs. Container gehen auch viel sparsamer mit Ressourcen um – Sie können viel mehr Container als VNFs auf derselben Hardware ausführen. Dies liegt daran, dass Container kein vollständiges Gastbetriebssystem oder keine Startzeit benötigen. Container können in Millisekunden geladen und ausgeführt werden, nicht in Dutzenden von Sekunden. Der größte Nachteil von Containern besteht jedoch darin, dass sie speziell geschrieben werden müssen, um einem Standard oder einer allgemeinen Implementierung zu entsprechen, 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 NFV-Modul (Network Functions Virtualization) aktivieren, indem Sie entweder virtio oder geeignete Hardware und Single-Root-E/A-Virtualisierung (SR-IOV) verwenden. Jede Methode hat unterschiedliche Eigenschaften.
Virtio-Nutzung verstehen
Wenn ein physisches Gerät virtualisiert wird, koexistieren sowohl physische NIC-Schnittstellen und externe physische Switches als auch die virtuellen NIC-Schnittstellen und internen virtuellen Switches nebeneinander. Wenn also die isolierten VNFs im Gerät mit jeweils eigenem Speicher, Speicherplatz und CPU-Zyklen versuchen, miteinander zu kommunizieren, stellen die verschiedenen Ports, MAC-Adressen und IP-Adressen eine Herausforderung dar. Mit der virtio-Bibliothek wird der Verkehrsfluss zwischen den isolierten virtuellen Funktionen immer einfacher.
Virtio ist Teil der Standard-Linux-Bibliothek libvirt mit nützlichen Virtualisierungsfunktionen und ist normalerweise in den meisten Linux-Versionen enthalten. Virtio ist ein reiner Software-Ansatz für die 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 es VNFs und Containern, einfache interne Bridges zum Senden und Empfangen von Datenverkehr zu verwenden. Der Verkehr kann weiterhin über eine externe Brücke ein- und ausgehen. Eine externe Bridge verwendet eine virtualisierte interne NIC-Schnittstelle an einem Ende der Bridge und eine physische externe NIC-Schnittstelle am anderen Ende der Bridge, um Pakete und Frames zu senden und zu empfangen. Eine interne Bridge, von der es mehrere Typen gibt, verbindet zwei virtualisierte interne NIC-Schnittstellen, indem sie sie über eine virtualisierte interne Switch-Funktion im Host-Betriebssystem überbrückt. Die Gesamtarchitektur 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 mit virtio implementierten virtuellen Switch oder die Bridge. Oberhalb des Betriebssystems verwenden mehrere virtuelle Maschinen virtuelle NICs, die über virtio kommunizieren. Es werden mehrere virtuelle Computer ausgeführt, die in der Abbildung von 1 bis N nummeriert sind. Die standardmäßige "Punkt Punkt Punkt"-Notation gibt mögliche virtuelle Maschinen und NICs an, die in der Abbildung nicht dargestellt sind. Die gestrichelten Linien zeigen mögliche Datenpfade mit virtio. Beachten Sie, dass der Datenverkehr, der in das Gerät ein- oder ausgeht, über die physische NIC und den Port erfolgt.
Abbildung 6 zeigt auch den Datenverkehr, der über die interne Bridge in das Gerät ein- und ausgeht. Die virtuelle Maschine 1 verbindet ihre virtualisierte interne NIC-Schnittstelle mit der physischen externen NIC-Schnittstelle. VM 2 und VM N verknüpfen interne virtuelle NICs über die interne Bridge im Host-Betriebssystem. Beachten Sie, dass diesen Schnittstellen möglicherweise VLAN-Labels oder interne Schnittstellennamen zugeordnet sind. Frames, die über diese interne Brücke zwischen VNF gesendet werden, verlassen niemals das Gerät. Notieren Sie sich die Position der Bridge (und der virtualisierten Switch-Funktion) im Host-Betriebssystem. Beachten Sie die Verwendung von einfachem Bridging im Gerät. Diese Bridges können entweder mit regulären Linux-Befehlen oder mithilfe 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 kooperieren mit dem Hypervisor und die virtuellen Funktionen erhalten im Gegenzug für die zusätzliche Komplikation Leistungsvorteile. Virtio ähnelt architektonisch den paravirtualisierten Xen-Gerätetreibern, ist aber nicht dasselbe (Treiber, die einem Gast hinzugefügt werden, um ihn schneller zu machen, wenn er auf Xen ausgeführt wird). Die Guest Tools von VMWare ähneln ebenfalls virtio.
Beachten Sie, dass sich ein Großteil des Datenverkehrs auf die CPU des Host-Betriebssystems konzentriert – genauer gesagt auf die virtualisierten internen Bridges. Daher muss die Host-CPU in der Lage sein, bei Skalierung des Geräts eine angemessene Leistung zu erbringen.
SR-IOV-Nutzung verstehen
Wenn ein physisches Gerät virtualisiert wird, existieren sowohl physische NIC-Schnittstellen (Network Interface Card) und externe physische Switches als auch die virtuellen NIC-Schnittstellen und internen virtuellen Switches nebeneinander. Wenn also die isolierten virtuellen Maschinen (VMs) oder Container im Gerät mit jeweils eigenem Arbeitsspeicher, Speicherplatz und CPU-Zyklen versuchen, miteinander zu kommunizieren, stellen die verschiedenen Ports, MAC-Adressen und IP-Adressen eine Herausforderung dar.
SR-IOV erweitert das Konzept virtualisierter Funktionen bis auf die physische NIC . Die einzelne physische Karte ist in bis zu 16 Partitionen pro physischem NIC-Port unterteilt, die den virtuellen Funktionen entsprechen, die auf den höheren Ebenen ausgeführt werden. Die Kommunikation zwischen diesen virtuellen Funktionen wird genauso gehandhabt, wie die Kommunikation zwischen Geräten mit einzelnen NIC normalerweise gehandhabt wird: mit einer Bridge. SR-IOV umfasst eine Reihe von Standardmethoden zum Erstellen, Löschen, Aufzählen und Abfragen des SR-IOV NIC-Switches sowie die einstellbaren Standardparameter.
Der Single-Root-Teil von SR-IOV bezieht sich auf die Tatsache, dass es wirklich nur einen primären Teil der NIC gibt, der alle Vorgänge steuert. Ein SR-IOV-fähiger NIC ist nur ein Standard-Ethernet-Port, der die gleiche physische Bit-für-Bit-Funktion wie jede andere Netzwerkkarte bietet.
Das SR-IOV stellt jedoch auch einige virtuelle Funktionen bereit, die durch einfache Warteschlangen zur Bearbeitung von Ein- und Ausgabeaufgaben ausgeführt werden. Jede VNF, die auf dem Gerät ausgeführt wird, wird einer dieser NIC-Partitionen zugeordnet, sodass VNFs selbst direkten Zugriff auf die Hardwareressourcen der NIC haben. Die NIC verfügt auch über eine einfache Layer-2-Sortierfunktion, die Frames in Datenverkehrswarteschlangen einteilt. Pakete werden mithilfe von DMA (Direct Memory Access, Direct Memory Access, DMA) direkt in und von der virtuellen Netzwerkfunktion in den Speicher der VM verschoben, wobei der Hypervisor vollständig umgangen wird. Die Rolle der NIC im SR-IOV-Betrieb ist in Abbildung 7 dargestellt.
Der Hypervisor ist weiterhin an der Zuweisung der VNF zu den virtuellen Netzwerkfunktionen und an der Verwaltung der physischen Karte beteiligt, nicht jedoch an der Übertragung der Daten innerhalb der Pakete. Beachten Sie, dass die VNF-zu-VNF-Kommunikation von virtueller NIC 1, virtueller NIC 2 und virtueller NIC N durchgeführt wird. Es gibt auch einen Teil der NIC (nicht dargestellt), der alle virtuellen Funktionen und den Sortierer verfolgt, um den Datenverkehr zwischen den VNF und externen Geräteports zu verteilen.
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 die erforderliche interne Überbrückung sind in der Regel teurer, weshalb ihre Verwendung die Kosten auf kleineren Geräten erheblich erhöhen kann. Auch das Umschreiben von VNFs und Containern ist keine triviale Aufgabe.
Vergleich von Virtio und SR-IOV
Virtio ist Teil der Standardbibliothek libvirt mit hilfreichen Virtualisierungsfunktionen und ist normalerweise in den meisten Linux-Versionen enthalten. Virtio verfolgt einen reinen Software-Ansatz. SR-IOV erfordert auf eine bestimmte Weise geschriebene Software und spezielle Hardware, was selbst 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 Einrichten der Brücken sind gut verstanden. Virtio legt jedoch die gesamte Leistungslast auf das Host-Betriebssystem, 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 geringere CPU-Auslastung bieten – kurz gesagt, eine 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 der 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 Juniper Networks NFX250 Netzwerkserviceplattform unterstützt SR-IOV-Funktionen und erlaubt 16 Partitionen auf jedem physischen NIC Port.
Beachten Sie, dass eine bestimmte VNF entweder virtio oder SR-IOV oder sogar beide Methoden gleichzeitig verwenden kann, sofern unterstützt.
Virtio ist die empfohlene Methode zum Herstellen einer Verbindung zwischen einem virtualisierten Gerät und einem NFV-Modul.