E/A-Leistung für Hyper-V-Speicher

Artikel
12/20/2023

In diesem Artikel werden die verschiedenen Optionen und Überlegungen zur Optimierung der Speicher-E/A-Leistung für einen virtuellen Computer (VM) beschrieben. Der Speicher-E/A-Pfad umfasst vier aufeinanderfolgende Abschnitte:

Gastspeicherstapel
Hostvirtualisierungsebene
Hostspeicherstapel
Physikalischer Datenträger

In den folgenden Abschnitten werden die für die einzelnen Phasen möglichen Optimierungen beschrieben.

Virtuelle Controller

Hyper-V bietet drei Arten virtueller Controller:

IDE-Schnittstelle (IDE)
SCSI-Schnittstelle (SCSI)
Virtueller Fibre Channel Hostbusadapter (HBAs)

IDE

Es wird empfohlen, nur IDE-Datenträger für Betriebssystem-Datenträger zu verwenden. Betriebssystem-Datenträ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. Diese Art Controller ist die einzige Option, die für Gast-VMs verfügbar ist, auf denen frühere Versionen von Windows ohne Hyper-V-VM-Integrationsdienste ausgeführt werden. Der IDE-Filtertreiber, den Integrationsdienste bereitstellen, 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 VM verfügbar. Jeder SCSI-Controller kann bis zu 64 Geräte unterstützen. Der SCSI-Pfad wird nicht emuliert, sodass er der bevorzugte Controller für alle anderen Datenträger als der Betriebssystem-Datenträger ist. Windows Server 2012 R2 und höher unterstützen SCSI-Controller, aber nur in Szenarien, in denen Sie den Controller als Serial Attached SCSI (SAS) zur Unterstützung einer freigegebenen virtuellen Festplatte (VHDX) melden.

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

Virtuelle Fibre Channel-Hostbusadapter

Konfigurieren Sie virtuelle Fibre Channel-HBAs, um direkten Zugriff auf Fibre Channel- und Fibre Channel over Ethernet (FCoE)-LUNs (logische Gerätenummern) für virtuelle Computer zu ermöglichen. Virtuelle Fibre Channel-Datenträger umgehen das NTFS-Dateisystem in der Root-Partition, wodurch die Auslastung des Zentralprozessors (CPU) durch Speicher-E/A reduziert wird. Große Datenlaufwerke und Laufwerke, die von mehreren VMs in Gast-Clustering-Szenarien gemeinsam genutzt werden, sind am besten für virtuelle Fibre Channel-Datenträger geeignet.

Um virtuelle Fibre Channel-Datenträger zu verwenden, muss mindestens ein Fibre Channel-HBA auf dem Hostcomputer installiert sein. Jeder Host-HBA muss HBA-Treiber verwenden, die die Funktionen von Windows Server 2016 Virtual Fibre Channel oder N_Port ID Virtualization (NPIV) unterstützen. Das Storage Area Network (SAN)-Fabric sollte auch NPIV unterstützen, und die HBA-Ports, die für den Fibre Channel verwendet werden, sollten in einer Fibre Channel-Topologie eingerichtet werden, die NPIV unterstützt.

Um den Durchsatz auf Hosts mit mehr als einem HBA zu maximieren, empfehlen wir Ihnen, mehrere virtuelle HBAs auf dem virtuellen Hyper-V-Computer zu konfigurieren. Für jeden VM können bis zu vier HBAs konfiguriert werden. Hyper-V belastet virtuelle HBAs automatisch gleichmäßig, wenn HBAs gehostet werden, die auf dasselbe virtuelle SAN zugreifen.

Virtuelle Datenträger

Virtuelle Datenträger werden von virtuellen Controllern für VMs 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 verschieden Arten von virtuellen Festplattendateien.

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

VHD-Format

Spätere Versionen von Hyper-V enthalten Verbesserungen für das VHD-Format, um eine bessere Ausrichtung zu 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 sind spätere Versionen von Hyper-V auf Datenträgern mit großem Sektor besser geeignet.

Eine unter Windows Server 2012 oder höher erstellte VHD verfügt über die optimale Ausrichtung von 4 KB. Dieses ausgerichtete Format ist vollständig mit früheren Windows Server-Versionen kompatibel. Die Ausrichtungseigenschaft unterstützt jedoch keine neuen Zuteilungen von Parsern, die keine 4-KB-Ausrichtung unterstützen, so z. B. ein VHD-Parser einer früheren Version von Windows Server oder ein Parser, der nicht von Microsoft stammt.

Konvertieren eines 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. einen Quelldatenträger mit dem Namen test.vhd in Laufwerk E in einen umbenannten konvertierten Datenträger mit dem Namen test-converted.vhd, der sich im selben Ordner befindet, konvertieren möchten, 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 In VHD umwandeln.

Ü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 4-KB-Ausrichtung unterstützt.

Anzeige der Datenträger-Ausrichtung:

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

Beachten Sie in der Ausgabe den Wert für die Eigenschaft Alignment. 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 Eigenschaft Alignment. 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. Mit diesem Format können Sie resiliente virtuelle Hochleistungsdatenträger mit einer Kapazität von bis zu 64 Terabyte erstellen.

Wenn Sie auf Windows Server 2016 oder höher upgraden, empfehlen wir, alle VHD-Dateien in das VHDX-Format zu konvertieren. Behalten Sie Dateien im VHD-Format nur bei, wenn Sie den VM zu einer früheren Version von Hyper-V verschieben müssen, die das VHDX-Format nicht unterstützt.

Hier sind einige Vorteile des VHDX-Formats:

Unterstützung für virtuelle Festplatten mit einer Speicherkapazität von bis zu 64 Terabyte
Schutz gegen Datenbeschädigung durch Stromausfälle durch Protokollieren der Aktualisierungen an den 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 darüber hinaus einige Leistungsfeatures:

Verbesserte Ausrichtung des virtuellen Festplattenformats, wodurch die Leistung bei Festplatten mit großen Sektoren verbessert wird
Größere Blöcke für dynamische und differenzierende Datenträger, die eine Anpassung der Datenträger an Workloadanforderungen ermöglichen
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 Datendarstellung, um kleinere Dateigrößen zu erzielen und zu ermöglichen, dass zugrunde liegende physische Speichergerät nicht genutzten Speicher freigeben können

Hinweis

Zum Trimmen sind Pass-Through- oder SCSI-Datenträger und trimmkompatible Hardware erforderlich.

Virtuelle Dateien

Es gibt drei Arten von VHD-Dateien:

Feste Dateien dienen zur Verbesserung der Resilienz und Leistung. Sie sollten sie verwenden, wenn der Speicher auf dem Hosting-Wert nicht aktiv überwacht wird. Vergewissern Sie sich, dass genügend Speicherplatz vorhanden ist, wenn Sie die VHD-Datei zur Runtime erweitern. Sie können sie auf einem beliebigen Datenträgerformat verwenden.
Dynamische Dateien sind für Resilienzgarantien und die Zuweisung von Speicherplatz auf dem Datenträger je nach Bedarf der Bereitstellung gedacht. Sie können nur auf VHDX verwendet werden.
Differenzierungsdateien halten die VM-Momentaufnahmeketten kurz, 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. Bei festen Dateien ist die Wahrscheinlichkeit geringer, dass sie fragmentiert werden, wodurch sich der E/A-Durchsatz verringert, wenn eine einzelne E/A in mehrere E/As getrennt wird. Sie weist den geringsten CPU-Mehraufwand der drei Dateioptionen auf, da Lese- und Schreibvorgänge die Blockzuordnung 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 hinter den nicht zugewiesenen Blöcken ist kein Speicherplatz in der Datei. Wenn ein Block den ersten Schreibvorgang empfängt, muss der Virtualisierungsstapel Speicherplatz in der VHD-Datei für den Block zuteilen und dann die Metadaten updaten. Diese Zuteilung erhöht die Anzahl der für den Schreibvorgang erforderlichen Datenträger-E/A-Vorgänge und damit die CPU-Auslastung. Lese- und Schreibvorgänge in vorhandenen Blöcken verursachen beim Ermitteln der Blockzuordnung in den Metadaten Datenträgerzugriffe und CPU-Mehraufwand.

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

Differenzierender Dateityp

Differenzierende Dateien sind Momentaufnahmen eines VM, die Schreibvorgänge auf die Datenträger speichern. Wenn Sie in einen Block schreiben, für den es noch keine Schreibvorgänge gibt, weist das System der VHD-Datei genau wie bei einer dynamisch expandierenden VHD Speicherplatz zu. Die Systemdienste führen Leseoperationen aus der VHD-Datei durch, wenn der Block bereits Schreibvorgänge enthält. Andernfalls werden Blöcke aus der übergeordneten VHD-Datei bedient. In beiden Fällen liest das System die Metadaten, um die Blockzuordnung zu ermitteln. Lese- und Schreibvorgänge in diese VHD können mehr CPU verbrauchen und zu mehr E/A-Vorgängen führen als bei einer festen VHD-Datei.

Wenn nur wenige Momentaufnahmen vorhanden sind, kann es zu einer erhöhten CPU-Auslastung bei Speicher-E/A-Vorgängen kommen. Die Auswirkungen auf die Leistung sind aber nur bei äußerst E/A-intensiven Serverworkloads spürbar. Das Erstellen und Verwenden einer großen Kette von VM-Momentaufnahmen verursacht Leistungsprobleme. Bei differenzierenden Dateien muss das System in vielen verschiedenen differenzierenden VHDs nach den angeforderten Blöcken suchen, nur um aus der VHD zu lesen. Wenn Sie differenzierende Dateien verwenden, sollten Sie die Momentaufnahmeketten kurz halten, um eine gute Datenträger-E/A-Leistung zu erhalten.

Ü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 Zuteilungsmustern der Workloads abzugleichen, die den Datenträger verwenden. Wenn eine Anwendung Blöcke in Blöcken von 16 MB zuweist, sollten Sie idealerweise eine VHD-Blockgröße von 16 MB verwenden. Blockgrößen von mehr als 2 MB sind nur bei VHDs möglich, die das VHDX-Dateiformat verwenden. Wenn die Blockgröße größer ist als das Zuweisungsmuster für eine zufällige E/A-Workload, erhöht sich der von der VHD belegte Speicherplatz auf dem Host.

Sektorgröße

Softwareorganisationen sind häufig von Datenträgersektoren von 512 Bytes abhängig, die branchenübliche Standardsektorgröße verschiebt sich aber immer mehr hin zu 4-KB-Datenträgersektoren. Um Kompatibilitätsprobleme zu verringern, die sich aus einer Änderung der Sektorgröße ergeben können, haben Festplattenhersteller eine Übergangsgröße eingeführt, die als 512-Emulationslaufwerke (512e) bezeichnet wird.

Emulationslaufwerke bieten einige der Vorteile, die auch native Laufwerke mit 4-KB-Datenträgersektoren bieten (z. B. eine verbesserte Formateffizienz und ein verbessertes Schema für Fehlerkorrekturcodes). Emulationslaufwerke verursachen weniger Kompatibilitätsprobleme, wenn sie eine Sektorgröße von 4 KB an der Datenträgerschnittstelle verfügbar machen.

Um 4-KB-Sektoren vollständig zu nutzen, empfiehlt es sich, das VHDX-Format anstelle von Datenträgersektoren mit 512 Bytes zu nutzen. Um Kompatibilitätsprobleme zwischen Datenträgergrößen zu verringern, implementieren Sie 512e-Laufwerke als Ü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 für ihn ausgegebenen 512-Byte-Sektor nicht direkt schreiben. Der Datenträger verfügt über einen internen Prozess, der Schreibvorgänge ermöglicht. Dabei handelt es sich um Read-Modify-Write (RMW)-Operationen in der folgenden Reihenfolge:

Zuerst liest der Datenträger den physischen 4-KB-Sektor in den internen Cache ein. Der Cache enthält den logischen 512-Byte-Sektor, auf den im Schreibvorgang verwiesen wird.
Danach ändert der Datenträger die Daten im 4-KB-Puffer, sodass sie den aktualisierten 512-Byte-Sektor einschließen.
Abschließend schreibt der Datenträger den Inhalt des aktualisierten 4-KB-Puffers zurück auf den physischen Sektor auf dem Laufwerk.

Der Gesamteffekt des RMW-Prozesses auf die Gesamtleistung hängt vom Workload ab. Der RMW-Prozess kann aus folgenden Gründen eine Leistungsbeeinträchtigung von virtuellen Festplatten verursachen:

Dynamische und differenzierende virtuelle Festplatten umfassen vor der Datennutzlast eine 512-Byte-Sektorbitmap. Footer, Header und übergeordnete Locators sind auf einen 512-Byte-Sektor ausgerichtet. Üblicherweise führt der Treiber der virtuellen Festplatte 512-Byte-Schreibvorgänge aus, um diese Strukturen zu aktualisieren, was dazu führt, dass der Datenträger den RMW-Prozess ausführt.
Anwendungen führen Lese- und Schreibvorgänge in der Regel in Vielfachen von 4 KB aus, da 4 KB die Standard-Clustergröße von NTFS ist. Dynamische und differenzierende virtuelle Festplatten verfügen über eine 512-Byte-Sektorbitmap vor dem Datennutzlastblock. Diese Bitmap bewirkt, dass die 4-KB-Blöcke nicht an der physischen 4-KB-Grenze ausgerichtet sind. Das folgende Diagramm hebt einen 4-KB-VHD-Block hervor, der nicht an der physischen 4-KB-Grenze ausgerichtet ist.

Jeder Schreibvorgang mit 4 KB vom aktuellen Parser zum Aktualisieren der Payload-Daten ergibt zwei Lesevorgänge für zwei Blöcke auf dem Datenträger. Die Blöcke werden dann vom System aktualisiert und zurück in die beiden Datenträgerblöcke geschrieben. In Hyper-V unter Windows Server 2016 werden einige Leistungsbeeinträchtigungen auf 512e-Datenträgern im VHD-Stapel entschärft. Hyper-V bereitet die Strukturen für die Ausrichtung an 4-KB-Grenzen im VHD-Format vor. Durch diese Entschärfung wird der RMW-Effekt beim Zugriff auf Daten in der virtuellen Festplattendatei und beim Aktualisieren der Metadatenstrukturen der virtuellen Festplatte vermieden.

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

Standardmäßig werden VHDs mit einer physischen Sektorgröße von 512 Bytes verfügbar gemacht. Mit dieser Methode wird sichergestellt, dass von der physischen Sektorgröße abhängige Anwendungen nicht beeinträchtigt werden, wenn Sie die Anwendung und VHDs von einer früheren Version von Windows Server übertragen.

Standardmäßig erstellt das System VHDX-Datenträger mit einer physischen Sektorgröße von 4 KB, um das Leistungsprofil für reguläre Datenträger und Datenträger mit großen Sektoren zu optimieren.

Um Kompatibilitätsprobleme zwischen Datenträgergrößen zu verringern, wird empfohlen, 512e-Laufwerke als Übergangsgröße zu implementieren. Verwenden Sie das VHDX-Format, um 4-KB-Sektoren vollständig zu nutzen.

Native 4-KB-Datenträger

Hyper-V in Windows Server 2012 R2 und höher unterstützt native 4-KB-Datenträger. Sie können VHD-Datenträgerdaten auch auf einem nativen 4-KB-Datenträger speichern, indem Sie einen RMW-Softwarealgorithmus auf der Schicht des virtuellen Speicherstapels implementieren. Der Algorithmus konvertiert Zugriffs- und Updateanforderungen mit 512 Byte in entsprechende Zugriffs- und Updateanforderungen mit 4 KB.

Da sich VHD-Dateien nur als Datenträger mit logischer 512-Byte-Sektorgröße verfügbar machen können, ist es wahrscheinlich, dass es Anwendungen gibt, die E/A-Anforderungen mit 512 Byte ausgeben. In solchen Fällen erfüllt der RMW-Algorithmus in der Speicherstapelschicht die Anforderungen und verursacht eine Leistungsminderung. Das gleiche Ergebnis tritt für VHDX-Datenträger mit einer logischen Sektorgröße von 512 Bytes auf.

Sie können VHDX-Dateien so konfigurieren, dass sie als Datenträger mit logischer 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 nativen physischen 4-KB-Gerät gehostet werden. Achten Sie jedoch darauf, dass die Größe des logischen Sektors von 4 KB sowohl den Gast als auch die Anwendung unterstützt, die den virtuellen Datenträger verwenden. Das VHDX-Format funktioniert auf einem Gerät mit einer logischen Sektorgröße von 4 KB einwandfrei.

Empfehlung: Vermeiden Sie die Verwendung nativer 4-KB-Datenträger mit VHD- und VHDX-Dateien, da dies zu Leistungsbeeinträchtigungen führen kann. Wenn Ihr Szenario 4-KB native Datenträger erfordert, sollten Sie das VHDX-Format auf einem Gerät mit einer Größe von 4 KB für logische Sektoren verwenden.

Pass-Through-Datenträger

Wir empfehlen Ihnen, die Verwendung von Pass-Through-Datenträgern zu vermeiden, da sie in VM-Migrationsszenarien Einschränkungen mit sich bringen.

Die Zuordnung einer VHD in einem VM direkt auf eine physische Festplatte oder einer logischen Gerätenummer (LUN) anstelle einer VHD-Datei wird als Pass-Through-Datenträger bezeichnet. Mit Pass-Through-Datenträgern können Sie das NTFS-Dateisystem in der Root-Partition umgehen, was die CPU-Auslastung der Speicher-E/A reduziert. 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.

Quality of Service (QoS) für Speicher

Ab Windows Server 2012 R2 kann Hyper-V bestimmte QoS-Parameter (Quality of Service) für Speicher auf virtuellen Computern festlegen. Wir empfehlen Ihnen, Storage QoS zu implementieren, um auf zusätzliche Speicherparameter zuzugreifen, 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 haben:

Konfigurieren der Speicherleistungsisolation in einer mehrinstanzenfähigen Umgebung
Angeben der maximalen und minimalen Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) für virtuelle Festplatten
- Administrator*innen können die Speicher-E/A-Vorgänge drosseln, um zu verhindern, dass ein Mandant übermäßige Speicherressourcen beansprucht, wenn dadurch andere Mandanten beeinflusst werden. Legen Sie den minimalen IOPS-Wert fest, und erhalten Sie Benachrichtigungen, wenn der Schwellenwert für optimale Leistung nicht erreicht wird. Wir geben die maximalen bzw. minimalen IOPS-Werte in Bezug auf normalisierte IOPS-Werte an, wobei jeweils 8 KB Daten als eine E/A gezählt werden.
Empfangen von Benachrichtigungen, wenn die Speicher-E/A-Leistung unter die definierten 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 Administrator*innen

Beachten Sie jedoch auch, dass Storage 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 einen Replikatstandort wird getrennt vom primären Standort konfiguriert.
Storage QoS unterstützt keine freigegebenen VHDX

Weitere Informationen finden Sie unter Quality of Service für Speicher für Hyper-V.

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

Windows Server 2012 und höher unterstützt das Projizieren einer virtuellen NUMA-Topologie (Non-Uniform Memory Access, nicht einheitlicher Speicherzugriff) auf Hyper-V-VMs. Die NUMA-Unterstützung trägt zur Verbesserung der Leistung von Workloads bei, die auf VMs mit großem Speicher oder auf großen VMs ausgeführt werden. Um diese Unterstützung zu ermöglichen, erfordern Konfigurationen von großen VMs Skalierbarkeit in Bezug auf den E/A-Durchsatz. Ein Beispiel für eine große VM ist Microsoft SQL Server, die mit 64 virtuellen Prozessoren ausgeführt wird.

Die folgenden Windows Server-Erweiterungen erfüllen die E/A-Skalierbarkeitsanforderungen großer VMs:

Eine Erhöhung der Anzahl von Kommunikationskanälen zwischen Gastgeräten und dem Hostspeicherstapel.
Ein effizienterer E/A-Abschlussmechanismus mit Interruptverteilung zwischen den virtuellen Prozessoren, um teure Interprozessorunterbrechungen zu vermeiden.

Registrierungsschlüssel

Wir empfehlen Ihnen, die Einstellungen des Windows Server NUMA-Registrierungsschlüssels zu verwenden, um die Leistung von Workloads zu verbessern, die auf großen VMs ausgeführt werden.

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

Der Teil <device id>\<instance id>\ des Pfads entspricht den relevanten Werten in Ihrer Konfiguration. Die Registrierungseinträge richten die virtuellen Prozessoren, die die E/A-Abschlüsse verarbeiten, an den virtuellen CPUs aus, die von der Anwendung als E/A-Prozessoren zugewiesen werden. Die Registrierungseinstellungen werden auf Adapterbasis für den Hardwareschlüssel des Geräts konfiguriert.

Zwei Schlüsseleinstellungen müssen beachtet werden:

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

ODX-Integration (Offloaded Data Transfer)

Wir empfehlen Ihnen die Verwendung von ODX-Vorgängen (Offloaded Data Transfer), um sicherzustellen, dass die VM-Arbeitslast ODX-fähigen Speicher wie in einer physischen Umgebung nutzen 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 verbraucht CPU- und Arbeitsspeicherressourcen, die für die Wartung von VMs hätten verwendet werden können.

Anbieter von Storage Area Network (SAN) können ein Hardwarefeature namens ODX bereitstellen. Dieses Feature ermöglicht nahezu sofortige Kopiervorgänge für große Datenmengen. ODX ermöglicht es dem System, nicht den Datenträgern, festzulegen, 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, sodass die kopierten Daten vom Gast-BS an die Hosthardware übergeben werden können. Die Workload kann ODX-fähigen Speicher wie in einer nicht virtualisierten Umgebung verwenden. Der Hyper-V-Speicherstapel gibt ODX-Vorgänge auch bei Wartungsvorgängen für VHDs aus, beispielsweise beim Zusammenführen von Datensätzen sowie bei Metavorgängen für Speichermigrationen, bei denen große Mengen an Daten migriert werden.

Integration von Benachrichtigungen zum Aufheben der Zuordnung

Wir empfehlen Ihnen die Verwendung von Unmap-Benachrichtigungen, um Ihre VHDX-Dateien effizienter zu gestalten und dem zugrunde liegenden physischen Speichergerät die Möglichkeit zu geben, ungenutzten Speicherplatz zurückzugewinnen.

VHD-Dateien befinden sich auf einem Speichervolume, wo sie sich den verfügbaren Speicherplatz mit anderen Dateien teilen. 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. Das bedeutet, dass Sie die Nutzung des physischen Speicherplatzes nach Möglichkeit optimieren sollten.

In Versionen von Windows Server vor Windows Server 2012 hatte der Windows-Speicherstapel im Gast-BS 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 ungenutzt. Die VHD oder die physische Speichervorrichtung werden nicht über die gelöschten Informationen informiert, wodurch der Hyper-V-Speicherstapel den Speicherplatz für die VHD-basierten virtuellen Festplattendateien nicht optimieren konnte. Infolgedessen konnte die zugrundeliegende Speichervorrichtung den nun ungenutzten Speicherplatz, den die gelöschten Daten belegten, nicht zurückgewinnen.

In Windows Server 2012 und höher unterstützt Hyper-V Benachrichtigungen zum Aufheben der Zuordnung. Mit diesem Feature können VHDX-Dateien gelöschte Daten an den Speicherstapel melden. Dies maximiert die Effizienz, da die Dateigrößen schlank gehalten werden und der Stapel ungenutzten Speicherplatz für andere Zwecke zurückgewinnen kann.

Nur Hyper-V-spezifische SCSI-Controller, optimierte IDE-Controller und virtuelle Fibre Channel-Controller ermöglichen es dem Befehl unmap im Gastbetriebssystem, den virtuellen Speicherstapel des Hosts zu erreichen. Bei VHDs unterstützen nur virtuelle Datenträger, die als VHDX formatiert sind, unmap-Befehle im Gast-BS.