Article Number: 000129905
E/A-Verbesserung am SR-IOV-Netzwerk in einer virtualisierten Umgebung unter Windows Server 2012
Summary: Lösungen zu Dell Betriebssystemen und Anwendungen auf Dell TechCenter – Projekt Sputnik, Microsoft Windows, Red Hat Linux, SUSE, Ubuntu und weitere
Article Content
Symptoms
Dieser Beitrag wurde ursprünglich von Abhijit Khande und Vineeth V Acharya vom DELL Windows Engineering Team verfasst.
Kommentare sind willkommen! Wenn Sie ein Thema vorschlagen oder andere Anmerkungen machen möchten, wenden Sie sich an WinServerBlogs@dell.com.
Mit dem Betriebssystem Microsoft® Windows Server® 2012 Beta hat Microsoft die Unterstützung für eine Reihe von Funktionen im Netzwerkbereich eingeführt. Ein solches wichtiges und interessantes Merkmal ist Single-Root-I/O-Virtualisierung (SR-IOV), wodurch virtuelle Maschinen ein einziges PCI-e-Gerät gemeinsam nutzen können. Dieser Beitrag bietet eine grundlegende Übersicht über SR-IOV in Windows Server 2012 Beta und darüber, wie es die CPU-Auslastung in einer virtualisierten Umgebung während Netzwerk-I/O-Vorgängen drastisch reduziert.
Die SR-IOV-Schnittstelle ist eine Erweiterung der PCI Express (PCIe)-Spezifikation. SR-IOV ermöglicht es einem einzelnen PCIe-Gerät, z. B. einem Netzwerkadapter, mehrere einfache Hardwareoberflächen auf dem PCI-Bus bereitzustellen und den Zugriff auf seine Ressourcen zwischen den verschiedenen Instanzen zu trennen. Dies wird durch die Verwendung mehrerer virtueller Funktionen (VF) zusätzlich zur (üblichen) physikalischen Funktion (PF) erreicht. Da dies hardwareabhängig ist, müssen sowohl das PCIe-Gerät als auch die Plattform diese Funktion unterstützen.
Üblicherweise wird ein für die virtuelle Maschine bestimmtes Paket vom physischen Netzwerkadapter (mithilfe der physischen Funktion) im Hostbetriebssystem empfangen. Dieses Paket wird vom NDIS-Treibermodul (Network Driver Interface Specification for NICs) verarbeitet. Das Paket wird dann dem Hyper-V-Switch bereitgestellt, der das Paket verarbeitet (z. B. Routing, VLAN-Filterung) und das Paket über VMBus an die vorgesehene VM weiterleitet, wie in Abbildung 1 dargestellt. Der umgekehrte Pfad wird befolgt, wenn die VM ein Paket senden muss.
Mit SR-IOV kann die VM eine virtuelle Funktion (VF) verwenden, um Pakete direkt an den physischen Netzwerkadapter zu senden und zu empfangen, wobei der herkömmliche Pfad vollständig umgangen wird, wie in Abbildung 1 gezeigt. Dies erhöht nicht nur die Netzwerk-I/O, sondern reduziert auch den Overhead auf der CPU des Hostcomputers.
Abbildung 1: Datenpfad mit und ohne SR-IOV
Jeder SR-IOV-fähige Netzwerkadapter macht eine feste Anzahl virtueller Funktionen verfügbar, die durch Ausführen des PowerShell-Befehls "Get-NetAdapterSriov" abgerufen werden können.
Wir haben einige Tests in unserem Labor durchgeführt, um die Leistung mit und ohne SR-IOV zu vergleichen. Die Testumgebung besteht aus einem Testserver (auf dem die Tests ausgeführt werden) und einem Dateiserver. Der Testserver ist ein Dell PowerEdge™ R710 II mit einem Intel® X520 10 GB Ethernet-Adapter und Windows Server 2012 Beta OS. Der Dateiserver hostet mehrere SMB-Freigaben und ist über ein 10-GB-Netzwerk über einen Dell PowerConnect™ 8024-Switch mit dem Testserver verbunden.
Wir erfassten die Leistungsdaten in Bezug auf die CPU, die von den DPCs (Deferred Procedure Call) verwendet wird, die von den verschiedenen Treibermodulen eingeplant werden, die an der Netzwerkdatenübertragung beteiligt sind. Diese Daten wurden sowohl im Gast- als auch im Hostbetriebssystem erfasst, wie in den folgenden Szenarien beschrieben. Der Testserver verfügt über 4 identische virtuelle Computer mit Windows Server 2012 Beta als Gastbetriebssystem. Die 4 VMs sind über einen virtuellen Switch mit dem 10-GB-Netzwerk verbunden. Diese Testkonfiguration ist in Abbildung 2 dargestellt.
Abbildung 2: Testkonfiguration
Bevor wir die Performancedaten präsentieren, ist es wichtig, einen sehr wichtigen Parameter einzuführen, der für diese Tests verwendet wird. Wählen Sie in der Microsoft Windows Unter OS gibt es einen Systemmechanismus namens Deferred Procedure Call (DPC), der Aufgaben mit hoher Priorität (z. B. ein Interrupt-Handler), um erforderliche, aber niedrigere Priorität zugewiesene Aufgaben auf eine spätere Ausführung zu verschieben. Auf diese Weise können Gerätetreiber und andere Verbraucher von Ereignissen auf niedriger Ebene den Teil der Verarbeitung mit hoher Priorität schnell durchführen und unkritische zusätzliche Verarbeitungen für die Ausführung mit einer niedrigeren Priorität einplanen.
Für dieses Szenario haben wir vier virtuelle Maschinen (VM) verwendet (VM 1 bis VM 4). Wir haben SR-IOV auf VM 1 und VM 2 aktiviert (durch Aktivieren der Option "Enable SR-IOV" in den VM-Einstellungen) und SR-IOV auf VM 3 und VM 4 deaktiviert (durch Deaktivierung derselben Option). Daher verwenden VM 1 und VM 2 die virtuelle Funktion (die vom Intel-Adapter verfügbar gemacht wird), während VM 3 und VM 4 den synthetischen Pfad (VMBus) für die gesamte Netzwerkkommunikation verwenden, wie in Abbildung 2 dargestellt.
Wir haben damit begonnen, Daten (mit einer Größe von 20 GB) von einer einzigen SMB-Freigabe auf die VMs zu kopieren und die Protokolle zur CPU-Auslastung des Systems im Gastbetriebssystem zu erfassen.
Abbildung 3: DPC-CPU-Auslastung in virtueller Maschine
In Abbildung 3 bezieht sich SR-IOV auf die durchschnittliche DPC-CPU-Auslastung in VM-1 und VM-2 und Nicht-SR-IOV auf die durchschnittliche DPC-CPU-Auslastung in VM-3 und VM-4. Wenn wir uns das Diagramm ansehen, sehen wir, dass es keinen großen Unterschied in der CPU-Auslastung zwischen den beiden Fällen gibt, aber wir haben die CPU-Auslastung auf dem Hostcomputer noch nicht berücksichtigt.
Für dieses Szenario haben wir eine virtuelle Maschine verwendet. Wir haben mit dem Kopieren von Daten (mit einer Größe von 20 GB) von der SMB-Freigabe auf die VM begonnen und die DPC-CPU-Nutzung von 2 Modulen, NDIS und VMBUS, erfasst, die für Netzwerk-I/O verwendet werden.
Abbildung 4: DPC-CPU-Auslastung auf Hostcomputer
Die Ergebnisse sind in Abbildung 4 dargestellt. Erwartungsgemäß gibt es einen großen Unterschied bei der CPU-Nutzung zwischen den beiden Fällen (SR-IOV und Nicht-SR-IOV). Die CPU-Auslastung liegt bei SR-IOV in der Größenordnung 102 und bei Nicht-SR-IOV in der Größenordnung 103–104. Das liegt vor allem daran, dass bei SR-IOV die virtuelle Maschine direkt über die virtuelle Funktion mit der physischen NIC kommuniziert. Daher werden die CPU-Zyklen des Hosts nicht für die Verarbeitung von Netzwerkpaketen genutzt. Bei Nicht-SR-IOV (siehe Abbildung 1) kommuniziert das Gastbetriebssystem mit dem Hostbetriebssystem über den VM-Bus, der wiederum die Pakete verarbeitet und über die physische NIC sendet. Daher werden Module wie VM-Bus und NDIS in großem Umfang verwendet.
Bei der Berechnung der gesamten CPU-Auslastung stellen wir fest, dass die CPU-Auslastung während Netzwerk-I/O bei Verwendung von SR-IOV weitaus geringer ist. Daher hilft Windows Server 2012 Beta mit aktiviertem SR-IOV den Kunden, den CPU-Overhead während Netzwerk-I/O-Vorgängen zu reduzieren und dadurch die Gesamtsystemleistung zu verbessern.
Kommentare sind willkommen! Wenn Sie ein Thema vorschlagen oder andere Anmerkungen machen möchten, wenden Sie sich an WinServerBlogs@dell.com.
Mit dem Betriebssystem Microsoft® Windows Server® 2012 Beta hat Microsoft die Unterstützung für eine Reihe von Funktionen im Netzwerkbereich eingeführt. Ein solches wichtiges und interessantes Merkmal ist Single-Root-I/O-Virtualisierung (SR-IOV), wodurch virtuelle Maschinen ein einziges PCI-e-Gerät gemeinsam nutzen können. Dieser Beitrag bietet eine grundlegende Übersicht über SR-IOV in Windows Server 2012 Beta und darüber, wie es die CPU-Auslastung in einer virtualisierten Umgebung während Netzwerk-I/O-Vorgängen drastisch reduziert.
Die SR-IOV-Schnittstelle ist eine Erweiterung der PCI Express (PCIe)-Spezifikation. SR-IOV ermöglicht es einem einzelnen PCIe-Gerät, z. B. einem Netzwerkadapter, mehrere einfache Hardwareoberflächen auf dem PCI-Bus bereitzustellen und den Zugriff auf seine Ressourcen zwischen den verschiedenen Instanzen zu trennen. Dies wird durch die Verwendung mehrerer virtueller Funktionen (VF) zusätzlich zur (üblichen) physikalischen Funktion (PF) erreicht. Da dies hardwareabhängig ist, müssen sowohl das PCIe-Gerät als auch die Plattform diese Funktion unterstützen.
Üblicherweise wird ein für die virtuelle Maschine bestimmtes Paket vom physischen Netzwerkadapter (mithilfe der physischen Funktion) im Hostbetriebssystem empfangen. Dieses Paket wird vom NDIS-Treibermodul (Network Driver Interface Specification for NICs) verarbeitet. Das Paket wird dann dem Hyper-V-Switch bereitgestellt, der das Paket verarbeitet (z. B. Routing, VLAN-Filterung) und das Paket über VMBus an die vorgesehene VM weiterleitet, wie in Abbildung 1 dargestellt. Der umgekehrte Pfad wird befolgt, wenn die VM ein Paket senden muss.
Mit SR-IOV kann die VM eine virtuelle Funktion (VF) verwenden, um Pakete direkt an den physischen Netzwerkadapter zu senden und zu empfangen, wobei der herkömmliche Pfad vollständig umgangen wird, wie in Abbildung 1 gezeigt. Dies erhöht nicht nur die Netzwerk-I/O, sondern reduziert auch den Overhead auf der CPU des Hostcomputers.
Abbildung 1: Datenpfad mit und ohne SR-IOV
Live Migration und SR-IOV
In Windows Server 2012 Beta kann die Live Migration mit SR-IOV durchgeführt werden, das von einer VM verwendet wird. Wenn die Quell- und Zielsysteme SR-IOV unterstützen und das Ziel über eine verfügbare VF verfügt, verwendet die VM die virtuelle Funktion. Andernfalls kehrt die VM zum herkömmlichen Pfad (VM-Bus) zurück.Jeder SR-IOV-fähige Netzwerkadapter macht eine feste Anzahl virtueller Funktionen verfügbar, die durch Ausführen des PowerShell-Befehls "Get-NetAdapterSriov" abgerufen werden können.
Performanceanalyse
Wir haben einige Tests in unserem Labor durchgeführt, um die Leistung mit und ohne SR-IOV zu vergleichen. Die Testumgebung besteht aus einem Testserver (auf dem die Tests ausgeführt werden) und einem Dateiserver. Der Testserver ist ein Dell PowerEdge™ R710 II mit einem Intel® X520 10 GB Ethernet-Adapter und Windows Server 2012 Beta OS. Der Dateiserver hostet mehrere SMB-Freigaben und ist über ein 10-GB-Netzwerk über einen Dell PowerConnect™ 8024-Switch mit dem Testserver verbunden.
Wir erfassten die Leistungsdaten in Bezug auf die CPU, die von den DPCs (Deferred Procedure Call) verwendet wird, die von den verschiedenen Treibermodulen eingeplant werden, die an der Netzwerkdatenübertragung beteiligt sind. Diese Daten wurden sowohl im Gast- als auch im Hostbetriebssystem erfasst, wie in den folgenden Szenarien beschrieben. Der Testserver verfügt über 4 identische virtuelle Computer mit Windows Server 2012 Beta als Gastbetriebssystem. Die 4 VMs sind über einen virtuellen Switch mit dem 10-GB-Netzwerk verbunden. Diese Testkonfiguration ist in Abbildung 2 dargestellt.
Abbildung 2: Testkonfiguration
Bevor wir die Performancedaten präsentieren, ist es wichtig, einen sehr wichtigen Parameter einzuführen, der für diese Tests verwendet wird. Wählen Sie in der Microsoft Windows Unter OS gibt es einen Systemmechanismus namens Deferred Procedure Call (DPC), der Aufgaben mit hoher Priorität (z. B. ein Interrupt-Handler), um erforderliche, aber niedrigere Priorität zugewiesene Aufgaben auf eine spätere Ausführung zu verschieben. Auf diese Weise können Gerätetreiber und andere Verbraucher von Ereignissen auf niedriger Ebene den Teil der Verarbeitung mit hoher Priorität schnell durchführen und unkritische zusätzliche Verarbeitungen für die Ausführung mit einer niedrigeren Priorität einplanen.
Szenario 1 – Performanceergebnisse der virtuellen Maschine (Gastbetriebssystem):
Für dieses Szenario haben wir vier virtuelle Maschinen (VM) verwendet (VM 1 bis VM 4). Wir haben SR-IOV auf VM 1 und VM 2 aktiviert (durch Aktivieren der Option "Enable SR-IOV" in den VM-Einstellungen) und SR-IOV auf VM 3 und VM 4 deaktiviert (durch Deaktivierung derselben Option). Daher verwenden VM 1 und VM 2 die virtuelle Funktion (die vom Intel-Adapter verfügbar gemacht wird), während VM 3 und VM 4 den synthetischen Pfad (VMBus) für die gesamte Netzwerkkommunikation verwenden, wie in Abbildung 2 dargestellt.
Wir haben damit begonnen, Daten (mit einer Größe von 20 GB) von einer einzigen SMB-Freigabe auf die VMs zu kopieren und die Protokolle zur CPU-Auslastung des Systems im Gastbetriebssystem zu erfassen.
Abbildung 3: DPC-CPU-Auslastung in virtueller Maschine
In Abbildung 3 bezieht sich SR-IOV auf die durchschnittliche DPC-CPU-Auslastung in VM-1 und VM-2 und Nicht-SR-IOV auf die durchschnittliche DPC-CPU-Auslastung in VM-3 und VM-4. Wenn wir uns das Diagramm ansehen, sehen wir, dass es keinen großen Unterschied in der CPU-Auslastung zwischen den beiden Fällen gibt, aber wir haben die CPU-Auslastung auf dem Hostcomputer noch nicht berücksichtigt.
Szenario 2 – Leistungsergebnis auf dem Hostcomputer (Hostbetriebssystem):
Für dieses Szenario haben wir eine virtuelle Maschine verwendet. Wir haben mit dem Kopieren von Daten (mit einer Größe von 20 GB) von der SMB-Freigabe auf die VM begonnen und die DPC-CPU-Nutzung von 2 Modulen, NDIS und VMBUS, erfasst, die für Netzwerk-I/O verwendet werden.
Abbildung 4: DPC-CPU-Auslastung auf Hostcomputer
Die Ergebnisse sind in Abbildung 4 dargestellt. Erwartungsgemäß gibt es einen großen Unterschied bei der CPU-Nutzung zwischen den beiden Fällen (SR-IOV und Nicht-SR-IOV). Die CPU-Auslastung liegt bei SR-IOV in der Größenordnung 102 und bei Nicht-SR-IOV in der Größenordnung 103–104. Das liegt vor allem daran, dass bei SR-IOV die virtuelle Maschine direkt über die virtuelle Funktion mit der physischen NIC kommuniziert. Daher werden die CPU-Zyklen des Hosts nicht für die Verarbeitung von Netzwerkpaketen genutzt. Bei Nicht-SR-IOV (siehe Abbildung 1) kommuniziert das Gastbetriebssystem mit dem Hostbetriebssystem über den VM-Bus, der wiederum die Pakete verarbeitet und über die physische NIC sendet. Daher werden Module wie VM-Bus und NDIS in großem Umfang verwendet.
Bei der Berechnung der gesamten CPU-Auslastung stellen wir fest, dass die CPU-Auslastung während Netzwerk-I/O bei Verwendung von SR-IOV weitaus geringer ist. Daher hilft Windows Server 2012 Beta mit aktiviertem SR-IOV den Kunden, den CPU-Overhead während Netzwerk-I/O-Vorgängen zu reduzieren und dadurch die Gesamtsystemleistung zu verbessern.
Cause
Konfigurieren von SR-IOV mithilfe von PowerShell
Sie können die folgenden PowerShell-Befehle verwenden, um einen neuen virtuellen Switch mit aktiviertem SR-IOV zu erstellen und den virtuellen Switch mit dem virtuellen Netzwerkadapter einer vorhandenen virtuellen Maschine zu verbinden.HINWEIS: Bevor Sie die folgenden Befehle ausführen, sollten die folgenden Optionen im BIOS aktiviert sein
- Virtualisierungstechnologie
- SR-IOV global aktivieren
$NetAdap = Get-NetAdapter | Where-Objekt { $_. Status -eq "Aktiv"}
(Der Switch -EnableIov wird verwendet, um SR-IOV im virtuellen Switch zu aktivieren)
New-VMSwitch -Name "SRIOV-Switch" -NetAdapterName $NetAdap.Name -AllowManagementOS $True -Notes "SRIOV-Schalter auf X520" -EnableIov $True$VMSw
= Get-VMSwitch
Hinzufügen eines neuen Netzwerkadapters zu VM-1 und Verbinden des Netzwerkadapters mit dem virtuellen Switch
Add-VMNetworkAdapter -SwitchName $VMSw.Name -VMName VM-1 -Name "SRIOV Adapter"
HINWEIS:Damit dieser Befehl funktioniert, muss die VM ausgeschaltet
sein)Sie können auch einen bereits vorhandenen VM-Netzwerkadapter verwenden, indem Sie die folgenden Befehle verwenden)
$VMNet = Get-VMNetworkAdapter -VMName VM-1
Connect-VMNetworkAdapter -VMName VM-1 -SwitchName $VMSw.Name -Name $VMNet.Name
Jeder VM-Netzwerkadapter verfügt über zwei Eigenschaften, IovWeight und VmqWeight, die SR-IOV bzw. VMQ entsprechen. Durch Anpassen dieser Gewichtungen werden die Funktionen aktiviert oder deaktiviert.
Resolution
Um SR-IOV zu aktivieren, legen Sie IovWeight auf 100 fest. Um SR-IOV zu deaktivieren, legen Sie IovWeight auf 0 (Standardeinstellung)
festSet-VMNetworkAdapter -VMName VM-1 -VMNetworkAdapterName $VMNetName -IovWeight 100
, wobei $VMNetName der Name des VM-Netzwerkadapters ist, der mit dem SRIOV-Switch verbunden ist.
Weitere Informationen finden Sie unter den folgenden Links:
festSet-VMNetworkAdapter -VMName VM-1 -VMNetworkAdapterName $VMNetName -IovWeight 100
, wobei $VMNetName der Name des VM-Netzwerkadapters ist, der mit dem SRIOV-Switch verbunden ist.
Weitere Informationen finden Sie unter den folgenden Links:
Article Properties
Affected Product
Servers
Last Published Date
20 Sept 2021
Version
4
Article Type
Solution