Betrieb von Containern in Netzwerkkomponenten
Zusätzliche Ladung
Veröffentlicht in Ausgabe 04/2024 - PRAXIS
Container kamen zunächst im Bereich der vereinfachten virtuellen Applikationsbereitstellung zum Einsatz. Sie beinhalten alle benötigten Pakete, um flexibel auf unterschiedlichen Hosts zu laufen. Neben klassischen Servern kommen Sie inzwischen auch in Kombination mit Hardwareplattformen [1] zur Netzwerkbereitstellung zum Einsatz. So bietet beispielsweise Cisco Systems mit dem sogenannten Application Hosting eine Umgebung zum Einsatz von Containern auf aktiven Netzwerkkomponenten wie Switches oder Routern. Dabei laufen die Container zusätzlich zur eigentlichen Netzwerkfunktion wie Switching oder Routing auf dediziert zugewiesenen Ressourcen für Compute, Speicher und Netzwerk.
Einen noch weitreichenderen Ansatz bietet das sogenannte Universal Customer Premises Equipment (uCPE) [2]. Hierbei handelt es sich um eine Allzweckplattform, die Compute, Speicher und Netzwerk auf einem Standardserver integriert und es ermöglicht, mehrere virtuelle Netzwerkfunktionen bereitzustellen. Sie haben keine fest definierte Funktion, sondern lassen sich flexibel an die Nutzung anpassen. Dazu zählen virtuelle Router und Switches, aber auch virtuelle Firewalls, SD-WAN-Appliances, IDS/IPS-Systeme sowie Proxys. Diese Bereitstellung ist mit den App-Stores auf Smartphones vergleichbar. Jedoch bergen diese Ansätze auch Herausforderungen wie die sicherheits- und ressourcentechnische Trennung, damit keine Gefährdung zwischen den Funktionen entsteht.
Voraussetzungen fürCiscos Application Hosting
Ciscos Application Hosting [3] ermöglicht es, Container an den Edge des Netzwerks zu bringen. Dies kann sowohl auf Switches, als auch auf Routern oder inzwischen sogar WLAN-Access-Points [4] der Fall sein. Diese Art der Bereitstellung bietet sich sowohl für die Applikationen und Dienste als auch für Monitoring und Analysen an, falls nicht bereits separate Serverressourcen am Standort bereitstehen. So kann der IT-Verantwortliche beispielsweise Infrastrukturdienste wie DHCP- oder DNS-Dienste über den beliebten DNS-Server Bind9 oder auch den DHCP-Server ISC Kea deployen, um unnötige Latenzen an zentralen Serverdiensten zu vermeiden. Für das Performance- und Erreichbarkeitsmonitoring könnte der Administrator einen ThousandEyes-Container deployen. Um aktive Performancemessungen vorzunehmen, ist ein Container mit iPerf3 denkbar. So kann der Admin remote einen Container auf bestehenden Switches und Routern installieren. Als Containerplattform dient in diesem Fall Docker.
Container kamen zunächst im Bereich der vereinfachten virtuellen Applikationsbereitstellung zum Einsatz. Sie beinhalten alle benötigten Pakete, um flexibel auf unterschiedlichen Hosts zu laufen. Neben klassischen Servern kommen Sie inzwischen auch in Kombination mit Hardwareplattformen [1] zur Netzwerkbereitstellung zum Einsatz. So bietet beispielsweise Cisco Systems mit dem sogenannten Application Hosting eine Umgebung zum Einsatz von Containern auf aktiven Netzwerkkomponenten wie Switches oder Routern. Dabei laufen die Container zusätzlich zur eigentlichen Netzwerkfunktion wie Switching oder Routing auf dediziert zugewiesenen Ressourcen für Compute, Speicher und Netzwerk.
Einen noch weitreichenderen Ansatz bietet das sogenannte Universal Customer Premises Equipment (uCPE) [2]. Hierbei handelt es sich um eine Allzweckplattform, die Compute, Speicher und Netzwerk auf einem Standardserver integriert und es ermöglicht, mehrere virtuelle Netzwerkfunktionen bereitzustellen. Sie haben keine fest definierte Funktion, sondern lassen sich flexibel an die Nutzung anpassen. Dazu zählen virtuelle Router und Switches, aber auch virtuelle Firewalls, SD-WAN-Appliances, IDS/IPS-Systeme sowie Proxys. Diese Bereitstellung ist mit den App-Stores auf Smartphones vergleichbar. Jedoch bergen diese Ansätze auch Herausforderungen wie die sicherheits- und ressourcentechnische Trennung, damit keine Gefährdung zwischen den Funktionen entsteht.
Voraussetzungen fürCiscos Application Hosting
Ciscos Application Hosting [3] ermöglicht es, Container an den Edge des Netzwerks zu bringen. Dies kann sowohl auf Switches, als auch auf Routern oder inzwischen sogar WLAN-Access-Points [4] der Fall sein. Diese Art der Bereitstellung bietet sich sowohl für die Applikationen und Dienste als auch für Monitoring und Analysen an, falls nicht bereits separate Serverressourcen am Standort bereitstehen. So kann der IT-Verantwortliche beispielsweise Infrastrukturdienste wie DHCP- oder DNS-Dienste über den beliebten DNS-Server Bind9 oder auch den DHCP-Server ISC Kea deployen, um unnötige Latenzen an zentralen Serverdiensten zu vermeiden. Für das Performance- und Erreichbarkeitsmonitoring könnte der Administrator einen ThousandEyes-Container deployen. Um aktive Performancemessungen vorzunehmen, ist ein Container mit iPerf3 denkbar. So kann der Admin remote einen Container auf bestehenden Switches und Routern installieren. Als Containerplattform dient in diesem Fall Docker.
Zunächst bedarf es jedoch einer kompatiblen Komponente: Als Switch-Plattformen dienen beispielsweise Catalyst 9300 oder 9400 mit mindestens IOS-XE 16.12.1 und von Cisco zertifiziertem USB-3.0-Flashspeicher im USB-Port. Dabei stellt IOS-XE 16.12 eher weniger ein Problem dar, da dieses bereits den Status "End of Vulnerability/Security Support" erreicht hat und die Nutzer aus Sicherheitsgründen bereits auf 17er-Versionen sein sollten. Die USB-3.0-Flashspeicher stellen jedoch eine nicht ganz unerhebliche finanzielle Belastung dar. Damit jedoch noch nicht genug, denn es braucht zusätzlich noch eine sogenannte DNA-Advantage-Lizenz oder alternativ eine DNA-Premier-Lizenz für den Switch. Zusätzlich kann der IT-Verantwortliche auch auf den größeren Catalyst-9500- und 9600-Plattformen Container bereitstellen, insofern er auf die passende SSD und Lizenz sowie ein IOS-XE mit mindestens Version 17.5.1 zurückgreift. Bei den WLAN-Access-Points sind die Catalyst-9100-APs und bei Routern die Modelle ISR4351/4331/4451 und ASR1001-X/1002-X für das Application Hosting ausgestattet. Einen aktuellen Überblick liefert die Plattformmatrix [5] im Cisco Developer Network.
Praxisbeispiel Application Hosting
Bevor wir jedoch einen Docker-Container deployen können, müssen wir diesen als TAR-Archiv vorbereiten. Als Beispiel nutzen wir einen vorbereiteten Container von Daniel Guerra [6] mit Alpine Linux, Wireshark und XFCE mit RDP-Server für den Managementzugriff. Dieses Beispiel dient dazu, eine Paketanalyse an einem entfernten Standort per RDP auf dem Docker-Container vorzunehmen. Der Switch kann Pakete zur Aufzeichnung und späteren Analyse an den Container spiegeln.
Zunächst beziehen wir auf unserem Management-PC über Docker Pull den entsprechenden Container und starten diesen mit einem Mapping des Ports 3389 für RDP. Im Nachgang erzeugen wir über den docker-save-Befehl ein entsprechendes TAR-Archiv, das wir dann auf einem SCP-Server bereitstellen:
docker pull danielguerra/alpine-xfce4-xrdp
docker run -d --name rdp --shm-size 1g -p 3389:3389 danielguerra/alpine-xfce4-xrdp
docker save -o itawireshark.tar danielguerra/alpine-xfce4-xrdp
Grundsätzlich kann die Installation des Containers manuell per Kommandozeile oder über eine zentrale Plattform, wie das Cisco Catalyst Center (ehemals "DNA Center"), erfolgen. Die Variante über das Catalyst Center bietet sich insbesondere für größere Deployments an. Nachfolgend beschreiben wir eine manuelle Installation über die Kommandozeile.
Application Hosting ist nicht per Default aktiviert. Daher müssen Sie das Framework über den Konfigurationsbefehl "iox" aktivieren. Über
show iox-service prüfen Sie, ob die benötigten Dienste laufen. Dies kann jedoch einige Minuten in Anspruch nehmen:configure terminal
iox
end
show iox-service
Die Docker-App muss anschließend als TAR-Archiv auf dem Switch vorliegen. Hierzu kopieren Sie dieses über Protokolle wie beispielsweise SCP auf das Device. Die korrekte Übertragung prüfen Sie über die MD5-Checksumme. Darauffolgend installieren Sie Container und checken, ob der Vorgang erfolgreich war:
copy scp://fileadmin@srvfile1.intern.pfisterit.de/itawireshark.tar usbflash1:
verify /md5 usbflash1:itawireshark.tar
app-hosting install appid itawire-shark package usbflash1:itawire-shark.tar
show app-hosting list
Jedoch muss der Container auch im Netzwerk erreichbar sein. Seine interne Anbindung im Switch über die sogenannte AppGigabitEthernet1/0/1-Schnittstelle ähnlich einem Layer-2-Port erfordert eine entsprechende Konfiguration. Die über diesen Port betriebenen Container lassen sich, wie der Name bereits vermuten lässt, mit einer maximalen kombinierten Datenrate von 1 GBit/s anbinden. Dies kann gegebenenfalls einen Engpass darstellen, falls Sie beispielsweise Performancemessungen mit iPerf3 ausführen möchten.
Auf OSI-Layer-2 bietet es sich an, den AppGigabitEthernet-Port über einen sogenannten 802.1Q-Trunk zu integrieren, um Container auch in unterschiedlichen VLANs beziehungsweise Subnetzen betreiben zu können. Als Beispiel nutzen wir unseren Testcontainer "VLAN 101". Damit er mit der Außenwelt kommunizieren kann, richten wir einen Uplink-Port zum VLAN-Gateway, also beispielsweise einem Router auf den Switchport "Gi1/0/ 48", ein, wobei im Beispiel die VLANs 101, 200 und 300 getaggt erlaubt sind. Da wir zunächst nur VLAN 101 benötigen, reichen wir nur dieses getagged an den Port "AppGigabitEthernet1/0/1" durch. Zusätzlich richten wir noch ein Switched Virtual Interface (SVI; auch als VLAN-Interface bezeichnet) im Container-VLAN ein. Wir können darüber auch unabhängig von der Konfiguration innerhalb des Containers die Konnektivität des VLANs prüfen.
Im Nachgang wechseln wir über das CLI-Kommando
app-hosting appid itawireshark
in die zugehörige Parametrisierung. Mit
app-vnic AppGigabitEthernet trunk
übergeben wir ein VLAN-Bündel an den Container. Die Zuweisung einer Containerschnittstelle zum VLAN 101 erfolgt nun über
vlan 101 guest-interface 0
Damit der Container in diesem VLAN auch kommunizieren kann, verpassen wir ihm anschließend noch eine statische Gast-IP-Adresse:
guest-ipaddress 10.1.1.9 netmask 255.255.255.0
und definieren für diese Schnittstelle noch ein Default-Gateway über
app-default-gateway 10.1.1.1 guest-interface 0
Alternativ können Sie auch DHCP anwenden. Zusätzlich übergeben wir noch zwei DNS-Server sowie eine zweite Schnittstelle "guest interface 12" mit der Option zum Spiegeln an den Container. Somit steht der Container über die IP-Adresse 10.1.1.9 und die Schnittstelle "guest interface 0" für das Management zur Verfügung. Um die Ressourcen des Switches für Application Hosting besser im Griff zu behalten oder spezifischen Anforderungen des Containers gerecht zu werden, lassen sich CPU- und RAM-Ressourcen auch dediziert zuweisen.
Damit haben wir nun den Container vorbereitet, sodass wir diesen aktivieren können. Dabei validiert der Switch die angeforderten Ressourcen und stellt diese, falls möglich, bereit. Der eigentliche Start findet über das CLI-Kommando
app-hosting start itawireshark statt. Das Listing 1 zeigt exemplarisch eine Konfiguration für Application Hosting. Diese dient der Bereitstellung eines Docker-Containers mit Wireshark auf Alpine Linux. Im Nachgang kann der Container zur Anwendung kommen.Anschließend greifen Sie per RDP auf den Container zu und können über Wireshark Pakete aufzeichnen sowie analysieren. Dazu müssen Sie die Mitschnitte nicht mehr an einen Monitoring-PC zur Analyse weiterleiten, da der Vorgang direkt per RDP auf dem Container erfolgen kann.
Listing 1: Docker-Container auf
einem Catalyst-9300-Switch
app-hosting install appid itawireshark package usbflash1:itawireshark.tar
!
configure terminal
!
interface GigabitEthernet1/0/48
description Uplink Gateway
switchport mode trunk
switchport trunk allowed vlan 101, 200, 300
!
interface Vlan101
description Container_SVI
ip address 10.1.1.254 255.255.255.0
no shut
exit
!
interface AppGigabitEthernet1/0/1
switchport trunk allowed vlan 101
switchport mode trunk
!
app-hosting appid itawireshark
app-vnic AppGigabitEthernet trunk
guest-interface 1 mirroring
vlan 101 guest-interface 0
guest-ipaddress 10.1.1.9 netmask 255.255.255.0
exit
exit
app-default-gateway 10.1.1.1 guest-interface 0
name-server0 10.10.10.10
name-server1 10.10.10.11
app-hosting appid itawireshark
app-resource profile custom
cpu 7400
memory 2048
persist-disk 2048
vcpu 2
end
write memory
app-hosting activate appid itawireshark
app-hosting start appid itawireshark
Die Architektur von uCPE
Bislang haben wir jedoch nur den proprietären Ansatz von Cisco Systems abgedeckt, bei dem der Container neben einer Kernfunktion zur Anwendung kommt. Einen ganzheitlichen Ansatz zur Netzwerk-Funktionsvirtualisierung liefert das sogenannte Universal Customer Premises Equipment. Hierbei handelt es sich um eine Basisplattform, die Computer, Speicher und Netzwerk auf Standardhardware bereitstellt, um darauf virtuelle Netzwerkfunktionen (VNF) zu betreiben.
Dieser Ansatz beruht auf der sogenannten Network Function Virtualization (NFV) [7] der ETSI (Europäisches Institut für Telekommunikationsnormen). Die Abstraktion bietet eine flexible Möglichkeit des Deployments benötigter Funktionen und trägt aktuellen Bedürfnissen Rechnung, wie beispielsweise im Sicherheitskontext. Soll der Admin beispielsweise im Fall von SD-WAN einen lokalen Breakout in einer Außenstelle mit zusätzlichen Sicherheitsfunktionen bereitstellen, so kann er dies auf uCPE tun. Dazu ist es beispielsweise möglich, neben dem SD-WAN-Routing auch Firewalls, IDS/IPS- oder Proxy-Systeme dezentral auf uCPE auszurollen. Früher brauchte es dazu drei Appliances, doch der uCPE-Ansatz ermöglicht es, dieses in einer Appliance zu kombinieren. Selbst wenn nachträglich zusätzliche Funktionen zur Anwendung kommen sollen, ist dies ohne zusätzlichen Hardwarerollout möglich, insofern die uCPE-Dimensionierung dies hergibt.
Die uCPEs definieren sich aus Hardware, Virtualisierungsschicht, den auf dieser Basis betriebenen VNFs und dem Management sowie der Orchestrierung. Die Hardwareplattform bildet die Grundlage von uCPE. Dabei besteht diese aus einer Mehrkern-CPU, Arbeitsspeicher, SSD/ HDD-Speicher und einer definierten Anzahl an Konnektivitätsoptionen. Dies können zunächst klassische Ethernet-Schnittstellen wie beispielsweise 1/10-GBASE-T oder SFP+-Slots für Module zur Anbindung von Lichtwellenleitern mit unterschiedlichen Wellenlängen sein. Ebenfalls möglich sind 4G/5G- oder xDSL-Schnittstellen, um flexible Anbindungen für SD-WAN-Umgebungen bereitzustellen. Die Virtualisierungsschicht besteht aus einem Hypervisor oder einer Container-Orchestrierungsplattform, die direkt auf der Hardware installiert ist. Sie bildet die Basis zum Anlegen, Löschen, Verwalten und Isolieren von virtuellen Netzwerkfunktionen und steuert auch die Ressourcenallokation.
Um eine größere Anzahl an uCPEs sinnvoll und effizient zu verwalten, ist eine zentralisierte Verwaltung und Orchestrierung notwendig. Dies bietet eine vereinheitlichte Übersicht über alle bereitstehenden uCPEs, um VNFs ausrollen, skalieren und monitoren zu können, ohne jeweils direkt auf eine einzelne uCPE zugreifen zu müssen. So ist eine sinnvolle Ressourcenverteilung und ein Überblick über redundante Verteilungen von Diensten vereinfacht möglich. Durch die Bündelung von Funktionen auf einer Hardware können Systemverantwortliche auch die Ressourcennutzung optimieren und folglich Kosten einsparen, insbesondere beim Stromverbrauch.
Zudem reduziert dies auch Wartungsaufwände und Reisezeiten von Onsite-Technikern, da diese nicht mehr für jede neue oder zu entfernende Netzwerkfunktion vor Ort fahren müssen. Dies bietet sich insbesondere für entfernte Lokationen ohne das passende IT-Personal an. Auch Managed-Service-Provider profitieren von dieser Art der Funktionsbereitstellung, da sie nicht mehr so oft zum Kunden unterwegs sind und gleichzeitig die Flexibilität für den Nutzer verbessern.
Neben den Vorteilen in klassischen Netzwerkfunktionen bieten sich uCPEs auch an, um weitere Dienste abzubilden, wie beispielsweise dezentral betriebene Infrastrukturdienste wie DHCP und DNS. Auch WLAN-Controller oder IP-Telefonanlagen sind denkbar, um diese Dienste jeweils in Außenstellen oder bei kleineren Organisationen einzurichten. Aber auch der Einsatz für Monitoringdienste wie ThousandEyes oder zum Betrieb von dezentralen Paket-Analysetools wie Wireshark an den Punkten, an denen der Traffic anfällt, erscheint interessant.
Wo Licht ist, gibt es jedoch auch Schatten. So kann die Virtualisierungsschicht die Performance etwas verringern. Gleichzeitig gibt es weder einen einheitlichen Hypervisor noch eine einheitliche Container-Orchestrierung. Zudem müssen Sie beachten, dass es beim Ausfall einer Hardware im Fall von uCPE zur Störung mehrerer Netzwerkfunktionen kommt. Die Redundanz der uCPEs sollte also eine entscheidende Rolle im Designprozess darstellen.
Optimierung über DPDK
Eine weitere Option zur Optimierung von Datenflüssen stellt das Dataplane Development Kit [10] dar. Dabei handelt es sich um ein Zusammenspiel zwischen Softwarebibliothek und Netzwerkkartentreiber zur Performanceverbesserung auf x86-Architekturen. Intel entwickelte DPDK initial, wobei es inzwischen ein Open Source-Projekt ist. Es dient dazu,
den Kernel des Betriebssystems bei der Paketweiterleitung über einen sogenannten Fast-Path zu umgehen. Die Applikation im Userspace erhält dabei direkten Zugang zur Netzwerkkarte. Das DPDK schränkt jedoch die Verwendung auf bestimmte, unterstützte Netzwerkadapter ein.Die virtuelle Netzwerkfunktion (VNF) im Userspace muss einen DPDK-Poll-Mode-Treiber (PMD) aktiviert haben und über die entsprechenden Bibliotheken verfügen. Der PMD befragt dabei wiederkehrend die Netzwerkkarte, ob Pakete zur Verarbeitung vorliegen. Dabei kommt es zum sogenannten Offloading der Paketverarbeitung vom Kernel in
den Userspace. Das erhöht die Effizienz und ermöglicht in Folge höhere Datenraten als bei klassischen Interrupt-Verarbeitungen. DPDK nutzt Direct Memory Access, wodurch die NIC den Speicher direkt ohne CPU-Interaktion ansprechen kann. Bei DPDK sind somit keine Kopieroperationen nötig. Zudem bietet DPDK eine Unterstützung für Non-Uniform
Memory Access (NUMA), um die Speicherzugriffszeiten zu minimieren.
Performancesteigerungmit SR-IOV
Wie erwähnt können Virtualisierung und Containerisierung durch das Einbringen der Abstraktionsebene Performanceeinbußen mit sich bringen. Es gibt jedoch auch Maßnahmen, um diesen zu begegnen. Im Normalfall verwaltet der Kernel des Betriebssystems die NIC. Zu Beginn der Paketverarbeitung erzeugt eine NIC bei einem eingehenden Netzwerkpaket einen CPU-Interrupt. Im Nachgang werden die Pakete von der NIC in die Kernel-Pufferwarteschlange kopiert. Von dort aus gibt es einen weiteren Kopiervorgang in den Userspace, in dem die jeweilige Anwendung oder auch der jeweilige Container angesiedelt ist. Dies stellt also einen sehr ressourcenintensiven Ansatz dar, der gleichzeitig auch noch einiges an Latenz erzeugt. Wir stellen im Folgenden Single Root I/O Virtualization (SR-IOV) [8] und anschließend das Dataplane Development Kit (DPDK) vor, die diesem Verhalten entgegenwirken.
Single Root I/O Virtualization (SR-IOV) kommt im Bereich von Virtualisierungsumgebungen zum Einsatz, um deren Leistung zu verbessern. SR-IOV wurde durch die "Peripheral Component Interconnect Special Interest Group" (PCI-SIG) ins Leben gerufen, also der Industrieorganisation zur Entwicklung und Verwaltung der PCI-Standards. Dem Ansatz liegt die Grundidee von PCI Pass-through zugrunde, das eine Netzwerkkarte direkt an einen Gast im sogenannten Userspace durchreicht, ohne den Kernel zu passieren. Jedoch gibt es bei PCI Passthrough nur eine 1-zu-1-Beziehung von Netzwerkkarten zu virtuellen Maschinen, was die Flexibilität stark einschränkt. SR-IOV löst diese Beschränkung auf, indem es virtualisierten Gästen im Userspace einen nativen Zugriff auf ein gemeinsam genutztes PCIe-Gerät ermöglicht. Somit können bei SR-IOV mehrere VNFs Zugriff auf eine physische Netzwerkkarte erhalten, also eine N-zu-1-Beziehung. Dazu müssen jedoch die Netzwerkkarten SR-IOV unterstützen.
Der Hypervisor oder das Host-Betriebssystem für die Container nehmen die Daten von der physischen Netzwerkkarte (pNIC) und senden sie über einen virtuellen Switch (vSwitch) an die virtuelle Netzwerkkarte (vNIC) der VM oder der virtuellen Netzwerkfunktion (VNF) und anschließend an die darin enthaltene Anwendung. Die virtuelle Schicht verursacht Virtualisierungs-Overhead und zusätzliche Paketverarbeitung, die den Durchsatz von E/A-Paketen verringert und zu Engpässen führt. In nicht virtualisierten Umgebungen empfängt die pNIC die Netzwerkdaten. Das Betriebssystem leitet diese Daten über den Kernelspace und den Userspace zur Applikation.
Bei traditioneller Paketverarbeitung für virtualisierte oder containerisierte Ressourcen erzeugt ein eingehendes Datenpaket auf einer Netzwerkkarte einen Interrupt. Im Nachgang erfolgt eine Prüfung, welcher Kern und welche VM beziehungsweise Container das Paket verarbeiten muss. Die meisten Pakete benötigen dabei zwei Interrupts: Ein Kern der CPU kümmert sich um den Ethernet-Interrupt der NIC und ein weiterer Interrupt auf einem anderen Kern übernimmt die Arbeit auf der Ziel-VM. Somit muss der Hypervisor oder Container-Host jedes Paket selbst anfassen.
Bei SR-IOV ist dieser Prozess optimiert und die VM oder der Container können dabei Daten direkt mit dem Netzwerkadapter austauschen [9]. Dabei umgeht SR-IOV den Kernel des Host-Betriebssystems. Dies führt in Folge zu höherem Netzwerkdurchsatz, kleinerer Latenz und geringerer CPU-Last. Aktuelle x86-Prozessoren nutzen Technologie wie Intel VT-X für den direkten Speichertransfer, die die Basis für SR-IOV darstellen.
Die SR-IOV Spezifikation definiert zwei logische Arten von Gerätetypen: Physical Function (PF) und Virtual Function (VF). Eine Physical Function gleicht einer statischen virtuellen Netzwerkkarte mit vollwertigen PCIe-Funktionen. Pro physischem NIC gibt es eine PF. PFs werden erkannt, verwaltet und konfiguriert wie ein normales PCIe-Gerät. Eine PF übernimmt die Verwaltung und Konfiguration mehrerer VFs.
Darüber hinaus enthalten PFs die sogenannte SR-IOV-Fähigkeitsstruktur, verwalten also die SR-IOV-Funktionalität, wie zum Beispiel die Einrichtung und Konfiguration von virtuellen Funktionen. VFs können Sie sich wie eine dynamische virtuelle Netzwerkkarte vorstellen. Sie haben mindestens die notwendigen Ressourcen zur Weiterleitung von Datenpaketen. Der Admin verwaltet diese jedoch nicht direkt, sondern über die PFs. Er kann zudem VMs oder Containern eine oder mehrere VFs zuweisen. Dabei benötigen Sie diese separate SR-IOV Treiber.
Der Systemverantwortliche erstellt virtuelle Funktionen (VF), die sich wie eine separate physische NIC für jede VM verhalten. Die VF in der NIC erhält dann eine Beschreibung, die ihr mitteilt, wo sich der Speicher im Userspace befindet, der der jeweiligen VM gehört, die sie bedient. Die Datenübertragung von NIC zur VM oder dem Container erfolgt direkt über DMA (Direct Memory Access), was die Performance verbessert.
Zusätzlich zu den virtuellen Funktionen bietet SR-IOV auch die Physical Function (PF). Diese sind voll ausgestattete PCIe-Funktionen, die sich wie jedes andere PCIe-Gerät erkennen, verwalten und manipulieren lassen. Darüber hinaus enthalten PFs die SR-IOV-Fähigkeitsstruktur und verwalten die SR-IOV-Funktionalität, wie zum Beispiel die Einrichtung und Konfiguration von virtuellen Funktionen.
Fazit
Die Virtualisierung greift auch im Netzwerk zunehmend um sich. IT-Verantwortliche fordern immer flexiblere und schneller bereitgestellte Netzwerke bei gleichzeitig immer höheren Verfügbarkeits-, Sicherheits- und Performanceanforderungen. Der Einsatz von Containern auf Netzwerkkomponenten bietet hierzu einen validen Ansatz. Die Systemverantwortlichen können diese nah am Endanwender betreiben, was einige Vorteile wie geringe Latenz mit sich bringt. Dies kann entweder additiv in Form von Application Hosting oder in einer Vollcontainerisierung in Form von uCPEs geschehen.
(jp)
Link-Codes
[1] Drittanbieter-Applikationen in Containern: https://www.juniper.net/documentation/us/en/software/junos/overview-evo/topics/task/third-party-applications-deploying.html
[2] Universal CPE: https://www.colt.net/de/resources/what-is-ucpe/#:~:text=uCPE%20(oder%20Universal%20Customer%20Premise,Standort%20in%20einem%20Netzwerk%20bereitzustellen
[3] Cisco Application Hosting: https://developer.cisco.com/docs/app-hosting/#!application-hosting-in-the-enterprise
[4] Application Hosting auf Cisco Access Points: https://developer.cisco.com/docs/app-hosting-ap/#!device-prerequisites/device-prerequisites
[5] Cisco-Plattformmatrix: https://developer.cisco.com/docs/iox/#!platform-support-matrix/enterprise-platforms
[6] Container mit Alpine Linux, Wireshark und XFCE: https://hub.docker.com/r/danielguerra/alpine-xfce4-xrdp/
[7] Network Function Virtualization: https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/R6BGArNQ/TECSPG-2300.pdf
[8] Single Root I/O Virtualization: https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-manager/GUI-User-Guides/Configuration/3-2/b_GUI_KVM_VM-FEX_UCSM_Configuration_Guide_3_2/b_GUI_KVM_VM-FEX_UCSM_Configuration_Guide_3_2_chapter_00.pdf
[9] Optimierungen durch SRV-IO: https://events.static.linuxfound.org/sites/events/files/slides/Jun_Nakajima_NFV_Container_final.pdf
[10] Einführung in DPDK: https://www.youtube.com/watch?v=1DWxo2gF-RQ