Hyper-V Speicher-E/A-Leistung

2025-04-30
Gilt für:: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Windows 11, ✅ Windows 10

In diesem Artikel werden verschiedene Optionen und Überlegungen zur Optimierung der Leistung von Speichereingabe/Ausgabe (E/A) auf einem virtuellen Computer (VM) erläutert. Der Speicher-E/A-Pfad erstreckt sich über vier aufeinander folgende Phasen:

Gastspeicherstapel
Hostvirtualisierungsebene
Hostspeicherstapel
Physikalischer Datenträger

In den folgenden Abschnitten werden die optimierungen beschrieben, die für jede Phase möglich sind.

Virtuelle Controller

Hyper-V bietet drei Arten virtueller Controller:

Integrierte Antriebselektronik (Integrated Drive Electronics, IDE)
Kleine Computersystemschnittstelle (SCSI)
Hostbusadapter (HBAs) für den virtuellen Fibre Channel

ALAND

Es wird empfohlen, nur IDE-Datenträger für Betriebssystemdatenträger zu verwenden. Betriebssystemdatenträger haben Leistungsbeschränkungen basierend auf der maximalen E/A-Größe für ihre Geräte.

IDE-Controller sind emulierte Controller, die IDE-Datenträger für die VM verfügbar machen. Dieser Controllertyp ist die einzige Option für Gast-VMs mit früheren Windows-Versionen ohne Hyper-V VM-Integrationsdienste. Der IDE-Filtertreiber, den Integrationsdienste bereitstellt, kann Datenträger-E/A besser als der emulierte IDE-Controller ausführen.

SCSI (SAS-Controller)

Virtuelle SCSI-Controller machen SCSI-Datenträger für den virtuellen Computer verfügbar. Jeder SCSI-Controller unterstützt bis zu 64 Geräte. Der SCSI-Pfad wird nicht emuliert, wodurch er zum bevorzugten Controller für einen anderen Datenträger als den Betriebssystemdatenträger wird. Windows Server 2012 R2 und höher unterstützen SCSI-Controller, aber nur in Szenarien, in denen Sie den Controller als SAS (Serial Attached SCSI) zur Unterstützung einer freigegebenen virtuellen Festplatte (VHDX) melden.

Um eine optimale Leistung zu erzielen, empfehlen wir, mehrere Datenträger an einen einzelnen virtuellen SCSI-Controller anzufügen. Sie sollten nur weitere Controller erstellen, wenn Sie keine anderen Optionen zum Skalieren der Anzahl von Datenträgern haben, die mit dem virtuellen Computer verbunden sind.

Hostbusadapter für den virtuellen Fibre Channel

Konfigurieren Sie HBAs für den virtuellen Fibre Channel, um direkten Zugriff auf Fibre Channel- und FCoE-LUNs (Fibre Channel over Ethernet) für VMs zu ermöglichen. Virtual Fibre Channel-Datenträger umgehen das NTFS-Dateisystem in der Stammpartition, wodurch die Nutzung der CPU für Speicher-E/A reduziert wird. Virtuelle Fibre Channel-Datenträger eignen sich hervorragend für große Datenlaufwerke und Laufwerke, die zwischen mehreren virtuellen Computern in Gastclusteringszenarien gemeinsam genutzt werden.

Um Virtual Fibre Channel-Datenträger zu verwenden, müssen Sie einen oder mehrere Fibre Channel HBAs auf dem Hostcomputer installieren. Jeder Host-HBA muss HBA-Treiber verwenden, die Windows Server 2016 Virtual Fibre Channel oder N_Port ID Virtualization (NPIV)-Funktionen unterstützen. Das Storage Area Network (SAN)-Fabric sollte auch NPIV unterstützen, und Sie sollten die HBA-Ports für den Fibre Channel in einer Fiber Channel-Topologie konfigurieren, die NPIV unterstützt.

Um den Durchsatz auf Hosts mit mehr als einem HBA zu maximieren, empfehlen wir, viele virtuelle HBAs innerhalb der Hyper-V VM zu konfigurieren. Sie können bis zu vier HBAs für jeden virtuellen Computer konfigurieren. Hyper-V gleicht virtuelle HBAs automatisch aus, um HBAs zu hosten, die auf dasselbe virtuelle SAN zugreifen.

Virtuelle Datenträger

Virtuelle Datenträger werden von virtuellen Controllern für virtuelle Computer verfügbar gemacht und können virtuelle Festplatten oder Pass-Through-Datenträger auf dem Host sein.

Virtuelle Datenträger werden in VHD- oder VHDX-Formaten bereitgestellt. Jedes Format unterstützt drei Typen virtueller Festplattendateien.

Wenn Sie die Bereitstellung auf Windows Server 2016 oder höher aktualisieren, empfehlen wir, alle VHD-Dateien in das VHDX-Format zu konvertieren. Weitere Informationen finden Sie im VHDX-Format.

VHD-Format

Spätere Versionen von Hyper-V umfassen Verbesserungen des VHD-Formats, die eine bessere Ausrichtung ermöglichen. Hyper-V in Windows Server 2012 und höher unterstützt sowohl VHDX- als auch VHD-Formate im Gegensatz zu früheren Versionen, die nur das VHD-Format unterstützen. Daher können spätere Versionen von Hyper-V auf großen Datenträgern besser funktionieren.

Jede VHD, die Sie unter Windows Server 2012 oder höher erstellen, hat die optimale Ausrichtung von 4 KB. Dieses angepasste Format ist vollständig kompatibel mit früheren Versionen von Windows Server. Die Ausrichtungseigenschaft unterstützt jedoch keine neuen Zuordnungen von Parsern, die keine 4 KB-Ausrichtung aufweisen, z. B. ein Parser aus einer früheren Version von Windows Server oder ein Nicht-Microsoft-Parser.

Konvertieren des Datenträgers in das VHD-Format

Wenn Sie eine VHD von einer früheren Version von Hyper-V oder Windows Server zu einer späteren Version migrieren, konvertiert das System den Datenträger nicht automatisch in das VHD-Format.

Sie können einen vorhandenen virtuellen Datenträger in VHD konvertieren, indem Sie ein PowerShell-Fenster öffnen und den folgenden Befehl ausführen:

Convert-VHD –Path <SourceDiskFilePath> –DestinationPath <ConvertedDiskFilePath>

Wenn Sie z. B. geplant haben, einen Quelldatenträger test.vhd in Laufwerk E in einen umbenannten konvertierten Datenträger zu konvertieren, der im selben Ordner benannt ist test-converted.vhd , führen Sie diesen Befehl aus:

Convert-VHD –Path E:\vms\testvhd\test.vhd –DestinationPath E:\vms\testvhd\test-converted.vhd

Hinweis

Wenn Sie eine VHD konvertieren, verwendet PowerShell die Daten aus der Quell-VHD basierend auf der Option "Aus Quelldatenträger kopieren ". Weitere Informationen finden Sie unter Convert-VHD.

Überprüfen der Datenträgerausrichtung

Nachdem Sie einen Datenträger konvertiert haben, können Sie die Ausrichtungsvariable überprüfen, um sicherzustellen, dass sie die optimale 4-KB-Ausrichtung verwendet, indem Sie den Get-VHD Befehl in PowerShell ausführen. Führen Sie den Befehl für den Quelldatenträger und den konvertierten Datenträger aus, und vergleichen Sie dann die Werte, um sicherzustellen, dass der konvertierte Datenträger eine Ausrichtung von 4 KB unterstützt.

So zeigen Sie die Ausrichtung Ihrer Datenträger an:

Öffnen Sie ein PowerShell-Fenster.
Führen Sie den Get-VHD Befehl aus, um die Ausrichtungseinstellung für den Quelldatenträger anzuzeigen.
```
Get-VHD –Path <SourceVHDFilePath>
```

Beachten Sie in der Ausgabe den Wert für die Alignment Eigenschaft. In diesem Beispiel ist der Wert 0, was bedeutet, dass der Datenträger keine Ausrichtung von 4 KB unterstützt.

Path                    : <SourceVHDFilePath>
VhdFormat               : VHD
VhdType                 : Dynamic
FileSize                : 69245440
Size                    : 10737418240
MinimumSize             : 10735321088
LogicalSectorSize       : 512
PhysicalSectorSize      : 512
BlockSize               : 2097152
ParentPath              :
FragmentationPercentage : 10
Alignment               : 0
Attached                : False
DiskNumber              :
IsDeleted               : False
Number                  :

Führen Sie den Get-VHD Befehl erneut aus, verwenden Sie jedoch diesmal den Dateipfad für den konvertierten Datenträger.
```
Get-VHD –Path <ConvertedDiskFilePath>
```

Überprüfen Sie in der Ausgabe den Wert für die Alignment Eigenschaft. Der Wert sollte 1 lauten. Das bedeutet, dass der Datenträger erfolgreich in das neuere VHD-Format konvertiert wurde und die 4-KB-Ausrichtung unterstützt.

Path                    : <ConvertedDiskFilePath>
VhdFormat               : VHD
VhdType                 : Dynamic
FileSize                : 69369856
Size                    : 10737418240
MinimumSize             : 10735321088
LogicalSectorSize       : 512
PhysicalSectorSize      : 512
BlockSize               : 2097152
ParentPath              :
FragmentationPercentage : 0
Alignment               : 1
Attached                : False
DiskNumber              :
IsDeleted               : False
Number                  :

VHDX-Format

VHDX ist ein aktualisiertes Festplattenformat, das in Windows Server 2012 eingeführt wurde. Dieses Format kann widerstandsfähige, leistungsfähige virtuelle Datenträger mit bis zu 64 Terabyte Kapazität erstellen.

Wenn Sie ein Upgrade auf Windows Server 2016 oder höher durchführen, empfehlen wir, alle VHD-Dateien in das VHDX-Format zu konvertieren. Bewahren Sie Dateien nur im VHD-Format auf, wenn Sie den virtuellen Computer in eine frühere Hyper-V Version verschieben müssen, die das VHDX-Format nicht unterstützt.

Hier sind einige Vorteile des VHDX-Formats:

Unterstützung für virtuelle Festplattenspeicherkapazität von bis zu 64 Terabyte
Schutz vor Datenbeschädigung bei Stromausfällen durch Protokollieren von Aktualisierungen der VHDX-Metadatenstrukturen
Speichert benutzerdefinierte Metadaten für eine Datei basierend auf dem, was der Benutzer konfiguriert, der es aufzeichnen möchte, z. B. die Betriebssystemversion oder angewendete Patches

Das VHDX-Format bietet außerdem mehrere Leistungsfeatures:

Verbesserte Ausrichtung des VHD-Formats, höhere Leistung auf großen Datenträgern
Größere Blockgrößen für dynamische und differenzielle Datenträger, mit denen Datenträger für Workloadanforderungen angepasst werden können
Eine virtuelle Festplatte mit logischem 4-KB-Sektor, die eine höhere Leistung unterstützt, wenn sie von Anwendungen und Workloads verwendet wird, die für 4-KB-Sektoren konzipiert sind
Effizienz bei der Darstellung von Daten, um kleinere Dateigrößen zu erzeugen und dem zugrunde liegenden physischen Speichergerät zu ermöglichen, nicht genutzten Speicherplatz freizugeben

Hinweis

Zum Kürzen sind Passthrough- oder SCSI-Datenträger und kürzungskompatible Hardware erforderlich.

Virtuelle Dateien

Es gibt drei Typen von VHD-Dateien:

Feste Dateien dienen zur Verbesserung der Resilienz und Leistung, und Sie sollten sie verwenden, wenn der Speicher auf dem Hostingwert nicht aktiv überwacht wird. Stellen Sie sicher, dass genügend Speicherplatz vorhanden ist, wenn Sie die VHD-Datei zur Laufzeit erweitern. Sie können sie auf einem beliebigen Datenträgerformat verwenden.
Dynamische Dateien dienen der Gewährleistung von Resilienz und der Zuweisung von Speicherplatz entsprechend den Anforderungen der Softwarebereitstellung. Sie können sie nur auf VHDX verwenden.
Verwenden Sie bei differenzierenden Dateitypen kurze VM-Momentaufnahmeketten, um eine gute E/A-Leistung des Datenträgers zu gewährleisten. Sie können sie auf einem beliebigen Datenträgerformat verwenden.

Fester Dateityp

Wenn Sie eine feste VHD-Datei erstellen, weist das System Speicherplatz dafür zu. Feste Dateitypen sind wahrscheinlich weniger fragmentiert, wodurch der E/A-Durchsatz reduziert wird, wenn ein einzelner E/A-Vorgang in mehrere aufgeteilt wird. Außerdem verfügt sie über den niedrigsten CPU-Aufwand der drei Dateioptionen, da Lese- und Schreibvorgänge die Zuordnung des Blocks nicht nachschlagen müssen.

Es wird empfohlen, den festen Dateityp zu verwenden, wenn Sie eine optimale Resilienz und Leistung benötigen.

Dynamischer Dateityp

Wenn Sie eine dynamische VHD-Datei erstellen, weist das System Speicherplatz für sie bei Bedarf zu. Blöcke in der Datei beginnen als zugewiesene Blöcke, und es gibt keinen Speicherplatz in der Datei, der die nicht zugewiesenen Blöcke unterstützt. Wenn ein Block seinen ersten Schreibzugriff erhält, muss der Virtualisierungsstapel Speicherplatz für den Block in der VHD-Datei zuweisen und dann die Metadaten aktualisieren. Diese Zuordnung erhöht die Anzahl der Datenträger-E/A, die für den Schreibvorgang erforderlich ist, und erhöht die CPU-Auslastung. Lese- und Schreibvorgänge in vorhandene Blöcke führen zu Datenträgerzugriff und CPU-Aufwand, wenn die Zuordnung der Blöcke in den Metadaten nachgefragt wird.

Wenn Sie eine VHDX-Datei verwenden, empfiehlt es sich, den dynamischen Dateityp zu verwenden, wenn Sie den Speicher auf dem Hostvolume nicht aktiv überwachen. Stellen Sie sicher, dass genügend Speicherplatz vorhanden ist, wenn Sie die VHD-Datei zur Laufzeit erweitern.

Unterschiedlicher Dateityp

Bei differenzierenden Dateitypen handelt es sich um VM-Momentaufnahmen, die zum Speichern auf die Datenträger geschrieben werden. Wenn Sie ohne vorhandene Schreibvorgänge in einen Block schreiben, weist das System ähnlich wie bei dynamisch erweiterten VHDs Speicherplatz in der VHD-Datei zu. Die Systemdienste führen Lesevorgänge aus der VHD-Datei durch, wenn der Block bereits Schreibvorgänge enthält. Andernfalls werden Blöcke aus der übergeordneten VHD-Datei verarbeitet. In beiden Fällen liest das System Metadaten, um die Blockzuordnung zu bestimmen. Lese- und Schreibvorgänge in diese VHD können mehr CPU verbrauchen und zu mehr E/A führen als eine feste VHD-Datei.

Wenn nur wenige Momentaufnahmen vorhanden sind, kann Speicher-E/A potenziell mehr CPU als normal verwenden, wirkt sich jedoch nicht auf die Leistung aus, außer in stark E/A-intensiven Serverworkloads. Das Erstellen und Verwenden einer großen Kette von VM-Momentaufnahmen verursacht Leistungsprobleme. Bei differenzierenden Dateitypen muss das System die angeforderten Blöcke auf vielen verschiedenen VHDs überprüfen, um nur von der VHD zu lesen. Wenn Sie differenzierende Dateitypen verwenden, sollten Sie Momentaufnahmeketten kurz halten, um eine gute E/A-Leistung des Datenträgers aufrechtzuerhalten.

Überlegungen zu Größen

Wenn Sie die Datenträgeroptimierung planen, sollten Sie sowohl die Blockgröße als auch die Sektorgröße berücksichtigen. In diesem Abschnitt werden Empfehlungen für die Größenanpassung von Blöcken und Sektoren beschrieben.

Blockgröße

Da sich die Blockgröße erheblich auf die Leistung auswirken kann, empfiehlt es sich, die Blockgröße mit den Zuordnungsmustern der Workloads auf dem Datenträger abzugleichen. Wenn eine Anwendung Blöcke in Blöcken von 16 MB zuordnet, sollten Sie idealerweise eine VHD-Blockgröße von 16 MB verwenden. Blockgrößen größer als 2 MB sind nur auf VHDs mit dem VHDX-Dateiformat möglich. Wenn die Blöcke größer als das Zuordnungsmuster für eine zufällige E/A-Workload sind, erhöht sich der Speicherplatz, der von der VHD auf dem Host verwendet wird.

Sektorgröße

Softwareorganisationen hängen häufig von Datenträgersektoren von 512 Byte ab, der Branchenstandard wechselt jedoch auf 4-KB-Datenträgersektoren. Um Kompatibilitätsprobleme zu verringern, die sich aus Änderungen der Branchengröße ergeben können, führen Festplattenanbieter eine Übergangsgröße ein, die als 512 Emulationslaufwerke (512e) bezeichnet wird.

Emulationslaufwerke bieten einige der Vorteile, die von systemeigenen 4-KB-Festplattenlaufwerken bereitgestellt werden, z. B. verbesserte Formateffizienz und ein verbessertes Schema für Fehlerkorrekturcodes (ECC). Emulationslaufwerke verursachen weniger Kompatibilitätsprobleme, wenn eine Sektorgröße von 4 KB auf der Datenträgerschnittstelle angezeigt wird.

Um 4-KB-Sektoren vollständig zu nutzen, empfehlen wir, das VHDX-Format anstelle von Datenträgersektoren von 512 Byte zu verwenden. Um Kompatibilitätsprobleme zwischen Datenträgergrößen zu verringern, implementieren Sie 512e Laufwerke für die Übergangsgröße.

Unterstützung der Übergangsgröße mit 512e-Datenträgern

Ein 512e-Datenträger kann einen Schreibvorgang nur in Bezug auf einen physischen Sektor ausführen. Dieser Datenträgertyp kann einen 512-Byte-Sektor nicht direkt schreiben, in den das System es ausgibt. Der Datenträger verfügt über einen internen Prozess, der Schreibvorgänge ermöglicht, die Lese-Modify-Write (RMW)-Vorgänge in der folgenden Reihenfolge beinhalten:

Zunächst liest der Datenträger den physischen 4-KB-Sektor in den internen Cache. Der Cache enthält den logischen 512-Byte-Sektor, auf den im Schreibvorgang verwiesen wird.
Als Nächstes ändert der Datenträger die Daten im 4-KB-Puffer so, dass er den aktualisierten 512-Byte-Sektor enthält.
Schließlich schreibt der Datenträger den aktualisierten 4-KB-Puffer wieder in seinen physischen Sektor auf dem Datenträger.

Der Gesamteffekt, den der RMW-Prozess auf die Leistung hat, hängt von der Arbeitsauslastung ab. Der RMW-Prozess kann aus folgenden Gründen zu Leistungsbeeinträchtigungen auf virtuellen Festplatten führen:

Dynamische und differenzierende virtuelle Festplatten haben vor den Datennutzdaten eine 512-Byte-Sektorbitmap. Footer, Header und übergeordnete Locators sind auf einen 512-Byte-Sektor ausgerichtet. Es ist üblich, dass der virtuelle Festplattentreiber 512-Byte-Schreibvorgänge ausführt, um diese Strukturen zu aktualisieren, wodurch der Datenträger den RMW-Prozess ausführt.
Anwendungen führen häufig Lese- und Schreibvorgänge in Vielfachen von 4 KB-Größen aus, da 4 KB die Standardclustergröße von NTFS ist. Dynamische und unterschiedliche virtuelle Festplatten weisen eine 512-Byte-Sektorbitmap vor dem Datennutzlastblock auf. Diese Bitmap bewirkt, dass die 4-KB-Blöcke nicht an der physischen Grenze von 4 KB ausgerichtet werden. Das folgende Diagramm zeigt einen hervorgehobenen 4-KB-Block auf einer VHD, die nicht an der physischen Grenze von 4 KB ausgerichtet ist.

Jeder 4-KB-Schreibvorgang durch den aktuellen Parser zum Aktualisieren der Nutzlastdaten führt zu zwei Lesevorgängen für zwei Blöcke auf dem Datenträger. Das System aktualisiert dann die Blöcke und schreibt sie zurück in die beiden Datenträgerblöcke. Hyper-V in Windows Server 2016 verringert einige Leistungseffekte auf 512e-Datenträgern im VHD-Stapel. Hyper-V bereitet die Strukturen für die Ausrichtung auf 4-KB-Begrenzungen im VHD-Format vor. Durch die Entschärfung wird der RMW-Effekt auf den Zugriff auf Daten in der virtuellen Festplattendatei und Aktualisierungen der Metadatenstrukturen der virtuellen Festplatte vermieden.

Wie bereits erwähnt, werden VHDs, die aus früheren Versionen von Windows Server kopiert wurden, nicht automatisch auf 4 KB ausgerichtet. Sie können den Datenträger manuell so konvertieren, dass er optimal ausgerichtet wird, indem Sie die Option "Aus Quelldatenträger kopieren " mit dem Convert-VHD Befehl verwenden.

Standardmäßig werden VHDs mit einer physischen Sektorgröße von 512 Byte verfügbar gemacht. Diese Methode sorgt dafür, dass Anwendungen, die von der physischen Sektorgröße abhängen, nicht beeinträchtigt werden, wenn Sie die Anwendung und die virtuellen Festplatten (VHDs) von einer früheren Version von Windows Server migrieren.

Standardmäßig erstellt das System VHDX-Datenträger mit einer Größe von 4 KB physischen Sektoren, um das Leistungsprofil auf normalen Datenträgern und größeren Sektordatenträgern zu optimieren.

Um Kompatibilitätsprobleme zwischen Datenträgergrößen zu verringern, empfehlen wir, 512e Laufwerke für die Übergangsgröße zu implementieren. Um 4-KB-Sektoren vollständig zu nutzen, verwenden Sie das VHDX-Format.

Native 4-KB-Festplatten

Hyper-V in Windows Server 2012 R2 und höher unterstützt 4 KB systemeigene Datenträger. Sie können auch VHD-Datenträgerdaten auf einem 4-KB-systemeigenen Datenträger speichern, indem Sie einen Software-RMW-Algorithmus in der virtuellen Speicherstapelebene implementieren. Der Algorithmus konvertiert 512-Byte-Zugriffs- und Aktualisierungsanforderungen in entsprechende 4-KB-Zugriffe und -Updates.

Da VHD-Dateien nur als 512-Byte-Festplatten mit logischer Sektorgröße verfügbar gemacht werden können, gibt es wahrscheinlich Anwendungen, die 512-Byte-E/A-Anforderungen ausgeben. In solchen Fällen erfüllt der RMW-Algorithmus auf der Speicherstapelebene die Anforderungen und führt zu Leistungsbeeinträchtigungen. Dasselbe Ergebnis tritt bei VHDX-Datenträgern mit einer logischen Sektorgröße von 512 Byte auf.

Sie können VHDX-Dateien so konfigurieren, dass sie als Datenträger mit einer logischen Sektorgröße von 4 KB verfügbar gemacht werden. Diese Implementierung ist eine optimale Konfiguration für die Leistung von Datenträgern, die auf einem 4-KB-systemeigenen physischen Gerät gehostet werden. Stellen Sie jedoch sicher, dass die Größe des logischen 4-KB-Sektors sowohl den Gast als auch die Anwendung unterstützt, die den virtuellen Datenträger verwendet. Das VHDX-Format funktioniert auf einem Gerät mit einer logischen Sektorgröße von 4 KB einwandfrei.

Es wird empfohlen, die Verwendung von 4 KB nativen Datenträgern mit VHD- und VHDX-Dateien zu vermeiden, da dies zu Leistungseinbußen führen kann. Wenn für Ihr Szenario 4-KB systemeigene Datenträger erforderlich sind, sollten Sie das VHDX-Format auf einem Gerät mit 4-KB logischer Sektorgröße verwenden.

Passthrough-Datenträger

Es wird empfohlen, die Verwendung von Pass-Through-Datenträgern aufgrund der Einschränkungen, die sie in VM-Migrationsszenarien einführen, zu vermeiden.

Wenn Sie eine VHD in einer VM direkt einem physischen Datenträger oder einer logischen Einheitennummer (LUN) statt einer VHD-Datei zuordnen, wird dies als Pass-Through-Datenträger bezeichnet. Pass-Through-Datenträger ermöglichen es, das NTFS-Dateisystem in der Stammpartition zu umgehen, wodurch die CPU-Auslastung des Speicher-E/A reduziert wird. Die Verwendung von Pass-Through-Datenträgern birgt jedoch auch das Risiko, dass physische Datenträger oder LUNs schwieriger zwischen Computern migriert werden können als VHD-Dateien.

Erweiterte Speicherfeatures

In diesem Abschnitt werden einige weitere Leistungsoptimierungen erläutert, die Sie für erweiterte Speicherfeatures berücksichtigen sollten.

Speicherqualität des Dienstes (QoS)

In Windows Server 2012 R2 und höher umfasst Hyper-V die Möglichkeit, bestimmte QoS-Parameter (Quality-of-Service) für den Speicher auf virtuellen Computern festzulegen. Es wird empfohlen, Speicher-QoS für den Zugriff auf zusätzliche Speicherparameter zu implementieren, maximale und minimale IOPS-Schwellenwerte für virtuelle Festplatten festzulegen und die Datenträgerleistung zu überwachen. Sie können diese Parameter implementieren, um die folgenden Vorteile zu erzielen:

Konfigurieren der Speicherleistungsisolation in einer Mehrinstanzenumgebung
Angeben der maximalen und minimalen Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) für virtuelle Festplatten
- Administratoren können die Speicher-E/A drosseln, um zu verhindern, dass ein Mandant übermäßige Speicherressourcen verbraucht, die sich auf andere Mandanten auswirken können. Legen Sie den minimalen IOPS-Wert fest, und empfangen Sie Benachrichtigungen, wenn das System den Schwellenwert für optimale Leistung nicht erfüllt. Wir spezifizieren die maximalen oder minimalen IOPS-Werte in Bezug auf normalisierte IOPS, wobei wir alle 8 KB Daten als eine E/A betrachten.
Empfangen von Benachrichtigungen, wenn die Speicher-E/A-Leistung unter definierte Schwellenwerte fällt, um VM-Workloads effizient auszuführen
Zugreifen auf Speicherparameter für die Infrastruktur von VM-Metriken und Ermöglichen der Überwachung von Leistungs- und Rückbuchungsparametern für Admins

Beachten Sie jedoch auch, dass Speicher-QoS die folgenden Einschränkungen hat:

Nur für virtuelle Datenträger verfügbar
Differenzierende Datenträger können keinen übergeordneten virtuellen Datenträger auf einem anderen Volume haben.
QoS für eine Replikatwebsite wird separat vom primären Standort konfiguriert.
Storage-QoS unterstützt keine freigegebenen VHDX-Dateien

Weitere Informationen finden Sie unter Speicherqualität der Dienste für Hyper-V.

NUMA-E/A-Registrierungseinstellungen für große VMs

Windows Server 2012 und höher unterstützt das Projizieren einer virtuellen, nichtuniformen Speicherzugriffstopologie (NUMA) in Hyper-V VMs. NUMA-Unterstützung verbessert die Leistung von Workloads, die auf virtuellen Computern ausgeführt werden, die mit großen Arbeitsspeichermengen oder großen VMs konfiguriert sind. Um diese Unterstützung zu ermöglichen, erfordern große VM-Konfigurationen Skalierbarkeit im Hinblick auf den E/A-Durchsatz. Ein Beispiel für einen großen virtuellen Computer ist Microsoft SQL Server, der mit 64 virtuellen Prozessoren ausgeführt wird.

Die folgenden Windows Server-Verbesserungen erfüllen die Anforderungen an die E/A-Skalierbarkeit großer VMs:

Erstellen weiterer Kommunikationskanäle zwischen Gastgeräten und dem Hostspeicherstapel.
Ein effizienterer E/A-Vervollständigungsmechanismus, der die Unterbrechungsverteilung zwischen den virtuellen Prozessoren umfasst, um teure Interprozessorunterbrechungen zu vermeiden.

Registrierungsschlüssel

Es wird empfohlen, die Registrierungsschlüsseleinstellungen von Windows Server NUMA zu verwenden, um die Leistung von Workloads zu verbessern, die auf großen virtuellen Computern ausgeführt werden.

Wir haben einige Registrierungseinträge hinzugefügt und aktualisiert, um die Verbesserungen im vorherigen Abschnitt zu unterstützen, und ermöglichen es Ihnen, die Anzahl der Kanäle anzupassen. Die Einträge finden Sie unter HKLM\System\CurrentControlSet\Enum\VMBUS\<device id>\<instance id>\StorChannel.

Der <device id>\<instance id>\ Teil des Pfads entspricht den relevanten Werten in Ihrer Konfiguration. Diese Registrierungseinträge ordnen die virtuellen Prozessoren zu, die die E/A-Fertigstellungen verarbeiten, den virtuellen CPUs, die von der Anwendung als E/A-Prozessoren zugewiesen wurden. Das System konfiguriert Registrierungseinstellungen pro Adapter basierend auf dem Hardwareschlüssel des Geräts.

Zwei Schlüsseleinstellungen müssen beachtet werden:

ChannelCount (DWORD) ist die Gesamtanzahl der Kommunikationskanäle, die Ihre Implementierung verwenden kann. Der Maximalwert ist 16. Die Kanalanzahl wird standardmäßig auf einen Wert festgelegt, der der Anzahl der virtuellen Prozessoren entspricht, die durch 16 dividiert sind.
ChannelMask (QWORD) ist die Prozessoraffinität für die Kanäle. Wenn Sie diese Schlüsseleinstellung nicht angeben oder den Wert auf 0 festlegen, wird die Kanalmaske standardmäßig auf den vorhandenen Kanalverteilungsalgorithmus für normale Speicher- oder Netzwerkkanäle festgelegt. Die Standardaktion stellt sicher, dass Ihre Speicherkanäle nicht mit Ihren Netzwerkkanälen in Konflikt geraten.

ODX-Integration (Offloaded Data Transfer)

Es wird empfohlen, offloaded Data Transfer (ODX)-Vorgänge zu verwenden, um sicherzustellen, dass die VM-Workload ODX-fähigen Speicher wie in einer physischen Umgebung verwenden kann.

Wichtige Wartungsaufgaben für VHDs, z. B. zusammenführen, verschieben und komprimieren, umfassen das Kopieren großer Datenmengen. Die aktuelle Methode zum Kopieren von Daten erfordert, dass das System Daten an verschiedene Speicherorte liest und schreibt. Dies ist zeitaufwändig und verwendet CPU- und Arbeitsspeicherressourcen, die in Richtung von Wartungs-VMs gehen könnten.

Anbieter von Storage Area Network (SAN) können ein Hardwarefeature namens ODX bereitstellen. Dieses Feature bietet nahezu sofortige Kopiervorgänge für große Datenmengen. ODX ermöglicht es dem System, nicht den Datenträgern, anzugeben, wie bestimmte Datensätze von einem Speicherort an einen anderen verschoben werden.

Hyper-V in Windows Server 2012 und höher unterstützt ODX-Vorgänge, um kopierte Daten vom Gastbetriebssystem an die Hosthardware zu übergeben. Die Workload kann ODX-fähigen Speicher wie in einer nicht virtualisierten Umgebung verwenden. Der Hyper-V Speicherstapel kann ODX-Vorgänge auch während Wartungsvorgängen für VHDs ausstellen, z. B. das Zusammenführen von Datenträgern und das Speichern von Migrationsmetavorgängen während riesiger Datenmigrationen.

Integration von Benachrichtigungen zum Aufheben der Zuordnung

Es wird empfohlen, Unmap-Benachrichtigungen zu verwenden, um Ihre VHDX-Dateien effizienter zu gestalten und dem zugrunde liegenden physischen Speichergerät zu ermöglichen, ungenutzten Speicherplatz zurückzugewinnen.

VHD-Dateien sind auf einem Speichervolume vorhanden, auf dem sie verfügbaren Speicherplatz für andere Dateien freigeben. Da ihre Dateigröße tendenziell groß ist, können VHD-Dateien viel Speicherplatz belegen. Ein größerer Bedarf an Speicherplatz wirkt sich auf IT-Hardwarebudgets aus, was bedeutet, dass Sie die Physische Raumnutzung nach Möglichkeit optimieren sollten.

In Versionen von Windows Server vor Windows Server 2012 hatte der Windows-Speicherstapel im Gastbetriebssystem und der Hyper-V-Host Einschränkungen, die die Optimierung des Speicherplatzes verhinderten. Wenn Anwendungen Inhalte in einer VHD gelöscht haben, blieb der Speicherplatz verlassen. Das System benachrichtigt das VHD- oder physische Speichergerät nicht über die gelöschten Informationen, wodurch verhindert wurde, dass der Hyper-V Speicherstapel speicherplatz für die VHD-basierten virtuellen Datenträgerdateien optimiert. Daher konnte das zugrunde liegende Speichergerät den jetzt ungenutzten Speicherplatz, den die gelöschten Daten zuvor belegt hatten, nicht zurückgewinnen.

Ab Windows Server 2012 unterstützt Hyper-V unmap-Benachrichtigungen. Mit diesem Feature können VHDX-Dateien gelöschte Daten an den Speicherstapel melden, wodurch die Effizienz maximiert wird, indem die Dateigrößen gekürzt werden und der Stapel nicht genutzter Speicherplatz für andere Zwecke freigibt.

Nur hyper-V-spezifische SCSI-, optimierte IDE- und Virtual Fibre Channel-Controller ermöglichen es dem unmap Befehl vom Gastbetriebssystem, den hostbasierten virtuellen Speicherstapel zu erreichen. Auf VHDs unterstützen nur virtuelle Datenträger, die als VHDX formatiert sind, unmap-Befehle aus dem Gastbetriebssystem.