I/O-prestaties van Hyper-V opslag

In dit artikel worden de verschillende opties en overwegingen onderzocht voor het afstemmen van de prestaties van opslaginvoer/-uitvoer (I/O) in een virtuele machine (VM). Het I/O-pad voor opslag strekt zich uit over vier opeenvolgende fasen:

1. Opslagstapel voor gasten
2. Host virtualisatielaag
3. Opslagstack voor host
4. Fysieke schijf

In de volgende secties worden de optimalisaties beschreven die mogelijk zijn voor elke fase.

Virtuele controllers

Hyper-V biedt drie soorten virtuele controllers:

• Geïntegreerde aandrijfelektronica (IDE)

• Kleine computersysteeminterface (SCSI)

• Virtuele Fibre Channel hostbusadapters (HBA's)

IDE

We raden u aan IDE-schijven alleen te gebruiken voor besturingssysteemschijven. OS-schijven hebben prestatiebeperkingen op basis van de maximale I/O-grootte voor hun apparaten.

IDE-controllers zijn geëmuleerde controllers die IDE-schijven blootstellen aan de VM. Dit type controller is de enige optie voor gast-VM's waarop eerdere versies van Windows worden uitgevoerd zonder Hyper-V VM-integratieservices. Het IDE-filterstuurprogramma dat door de integratieservices wordt geleverd, kan schijf-I/O beter uitvoeren dan de geëmuleerde IDE-controller.

SCSI (SAS-controller)

Virtuele SCSI-controllers stellen SCSI-schijven bloot aan de VM. Elke SCSI-controller ondersteunt maximaal 64 apparaten. Het SCSI-pad wordt niet geëmuleerd, waardoor het de voorkeurscontroller is voor elke andere schijf dan de besturingssysteemschijf. Windows Server 2012 R2 en hoger bieden ondersteuning voor SCSI-controllers, maar alleen in scenario's waarin u de controller rapporteert als een Serial Attached SCSI (SAS) voor ondersteuning van een gedeelde virtuele harde schijf (VHDX).

Voor de beste prestaties raden we u aan meerdere schijven aan te sluiten op één virtuele SCSI-controller. U moet alleen meer controllers maken als u geen andere opties hebt voor het schalen van het aantal schijven dat op de VM is aangesloten.

Virtuele Fibre Channel HBA's

Configureer Virtual Fibre Channel HBA's om VM's rechtstreeks toegang te geven tot Fibre Channel en Fibre Channel over Ethernet (FCoE) logische eenheidsnummers (LUN's). Virtuele Fibre Channel-schijven omzeilen het NTFS-bestandssysteem in de hoofdpartitie, waardoor het gebruik van de I/O-CPU (Central Processing Unit) voor opslag wordt verminderd. Virtual Fibre Channel-schijven zijn ideaal voor grote gegevensstations en stations die worden gedeeld tussen meerdere VM's in gastclusterscenario's.

Als u Virtual Fibre Channel-schijven wilt gebruiken, moet u een of meer Fibre Channel HBA's op de hostcomputer installeren. Elke host-HBA moet HBA-stuurprogramma's gebruiken die ondersteuning bieden voor Windows Server 2016 Virtual Fibre Channel of N_Port ID Virtualization (NPIV)-mogelijkheden. De SAN-fabric (Storage Area Network) moet ook ondersteuning bieden voor NPIV en u moet de HBA-poorten voor de Fibre Channel configureren in een Fibre Channel-topologie die NPIV ondersteunt.

Als u de doorvoer op hosts met meer dan één HBA wilt maximaliseren, raden we u aan veel virtuele HBA's in de Hyper-V VM te configureren. U kunt maximaal vier HBA's configureren voor elke VM. Hyper-V brengt virtuele HBA's automatisch in evenwicht om HBA's te hosten die toegang hebben tot hetzelfde virtuele SAN.

Virtuele schijven

Virtuele schijven worden blootgesteld aan de VM's door virtuele controllers en kunnen virtuele harde schijven of passthrough-schijven op de host zijn.

Virtuele schijven zijn verkrijgbaar in VHD- of VHDX-indeling. Elk formaat ondersteunt drie typen virtuele bestanden op de harde schijf.

Als u een upgrade uitvoert naar Windows Server 2016 of hoger, raden we u aan alle VHD-bestanden te converteren naar de VHDX-indeling. Zie VHDX-indeling voor meer informatie.

VHD-indeling

Latere versies van Hyper-V bevatten verbeteringen aan hun VHD-formaat die een betere uitlijning mogelijk maken. Hyper-V in Windows Server 2012 en hoger ondersteunt zowel VHDX- als VHD-indelingen, in tegenstelling tot eerdere versies die alleen de VHD-indeling ondersteunen. Als gevolg hiervan presteren latere versies van Hyper-V beter op grote sectorschijven.

Alle VHD's die u in Windows Server 2012 of hoger maakt, hebben de optimale uitlijning van 4 kB. Deze uitgelijnde indeling is volledig compatibel met eerdere versies van Windows Server. De uitlijningseigenschap biedt echter geen ondersteuning voor nieuwe toewijzingen van parsers die niet 4 kB uitlijningsbewust zijn, zoals een parser van een eerdere versie van Windows Server of een niet-Microsoft-parser.

Schijf converteren naar VHD-formaat

Wanneer u een VHD migreert van een eerdere versie van Hyper-V of Windows Server naar een nieuwere versie, wordt de schijf niet automatisch geconverteerd naar de VHD-indeling.

U kunt een bestaande virtuele schijf converteren naar VHD door een PowerShell-venster te openen en de volgende opdracht uit te voeren:

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

Als u bijvoorbeeld van plan was een bronschijf met de naam test.vhd in station E te converteren naar een geconverteerde schijf test-converted.vhd met een andere naam in dezelfde map, voert u de volgende opdracht uit:

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

Schijfuitlijning controleren

Nadat u een schijf hebt geconverteerd, kunt u de bijbehorende uitlijningsvariabele controleren om ervoor te zorgen dat deze de optimale uitlijning van 4 kB gebruikt door de Get-VHD opdracht uit te voeren in PowerShell. Zorg ervoor dat u de opdracht voor de bronschijf en de geconverteerde schijf uitvoert en vergelijk vervolgens de waarden om er zeker van te zijn dat de geconverteerde schijf 4 kB uitlijningsgevoelig is.

De uitlijning van uw schijven weergeven

1. Open een PowerShell-venster.

2. Voer de Get-VHD opdracht uit om de uitlijningsinstelling voor de bronschijf weer te geven.

   Get-VHD –Path <SourceVHDFilePath>
   

3. Let in de uitvoer op de waarde voor de Alignment eigenschap. In dit voorbeeld is 0de waarde , wat betekent dat de schijf niet 4 kB uitlijningsgevoelig is.

   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                  :
   

4. Voer de Get-VHD opdracht opnieuw uit, maar gebruik deze keer het bestandspad voor de geconverteerde schijf.

   Get-VHD –Path <ConvertedDiskFilePath>
   

5. Controleer in de uitvoer de waarde voor de Alignment eigenschap. De waarde moet zijn 1, wat betekent dat de schijf is geconverteerd naar het nieuwere VHD-formaat en 4 kB uitlijningsbewust is.

   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-indeling

VHDX is een bijgewerkt formaat voor de harde schijf dat is geïntroduceerd in Windows Server 2012. Met deze indeling kunnen veerkrachtige, krachtige virtuele schijven worden gemaakt met een capaciteit tot 64 terabyte.

Als u een upgrade uitvoert naar Windows Server 2016 of hoger, raden we u aan alle VHD-bestanden te converteren naar de VHDX-indeling. Bewaar bestanden alleen in VHD-indeling als u de VM moet verplaatsen naar een eerdere Hyper-V release die geen ondersteuning biedt voor de VHDX-indeling.

Hier zijn enkele voordelen van het VHDX-formaat:

• Ondersteuning voor virtuele harde schijf opslagcapaciteit tot 64 terabyte

• Bescherming tegen gegevensbeschadiging tijdens stroomuitval door updates van de VHDX-metagegevensstructuren te registreren

• Slaat aangepaste metagegevens voor een bestand op op basis van wat de gebruiker die het bestand configureert, wil opnemen, zoals de versie van het besturingssysteem of toegepaste patches

Het VHDX-formaat biedt ook verschillende prestatiekenmerken:

• Verbeterde uitlijning van het formaat van de virtuele harde schijf, waardoor de prestaties op grote sectorschijven worden verbeterd

• Grotere blokgroottes voor dynamische en differentiële schijven, waardoor schijven kunnen worden aangepast aan de workloadvereisten

• Een virtuele schijf van 4 kB voor logische sector ter ondersteuning van verbeterde prestaties bij gebruik door toepassingen en workloads die zijn ontworpen voor sectoren van 4 kB

• Efficiëntie bij het weergeven van gegevens om kleinere bestandsgroottes te produceren en het onderliggende fysieke opslagapparaat in staat te stellen ongebruikte ruimte terug te winnen

  Note

  Voor het bijsnijden zijn pass-through- of SCSI-schijven en trimcompatibele hardware vereist.

Virtuele bestanden

Er zijn drie soorten VHD-bestanden:

• Vaste bestanden zijn bedoeld om de tolerantie en prestaties te verbeteren, en u moet ze gebruiken wanneer de opslag op de hostingwaarde niet actief wordt gecontroleerd. Zorg ervoor dat er voldoende schijfruimte is wanneer u het VHD-bestand tijdens runtime uitbreidt. U kunt ze op elk schijfformaat gebruiken.

• Dynamische bestanden zijn bedoeld voor het waarborgen van de veerkracht en het toewijzen van schijfruimte wanneer de implementatie dit nodig heeft. U kunt ze alleen gebruiken op VHDX.

• Differentiërende bestanden houden VM-snapshotketens kort om goede schijf-I/O-prestaties te behouden. U kunt ze op elk schijfformaat gebruiken.

Vast bestandstype

Wanneer u een vast VHD-bestand maakt, wijst het systeem er ruimte voor toe. Vaste bestanden zullen minder snel fragmenteren, waardoor de I/O-doorvoer wordt verminderd wanneer een enkele I/O wordt opgesplitst in meerdere. Het heeft ook de laagste CPU-overhead van de drie bestandsopties, omdat lees- en schrijfbewerkingen de toewijzing van het blok niet hoeven op te zoeken.

We raden u aan het vaste bestandstype te gebruiken wanneer u optimale tolerantie en prestaties nodig hebt.

Dynamisch bestandstype

Wanneer u een dynamisch VHD-bestand maakt, wijst het systeem er op aanvraag ruimte voor toe. Blokken in het bestand beginnen als toegewezen blokken en er is geen ruimte in het bestand die de niet-toegewezen blokken ondersteunt. Wanneer een blok voor het eerst wordt geschreven, moet de virtualisatiestack ruimte toewijzen aan het blok in het VHD-bestand en vervolgens de metadata bijwerken. Deze toewijzing verhoogt het aantal schijf-I/O's dat nodig is voor het schrijven, waardoor het CPU-gebruik toeneemt. Lees- en schrijfbewerkingen naar bestaande blokken brengen schijftoegang en CPU-overhead met zich mee bij het opzoeken van de toewijzing van de blokken in de metadata.

Als u een VHDX-bestand gebruikt, raden we u aan het dynamische bestandstype te gebruiken wanneer u de opslag op het hostingvolume niet actief bewaakt. Zorg ervoor dat u voldoende schijfruimte hebt wanneer u het VHD-bestand tijdens runtime uitbreidt.

Differentiërend bestandstype

Differentiërende bestanden zijn momentopnamen van een VM die schrijfbewerkingen naar de schijven opslaan. Als u naar een blok schrijft zonder bestaande schrijfbewerkingen, wijst het systeem ruimte toe in het VHD-bestand, net als een dynamisch uitbreidende VHD. De systeemservices lezen bewerkingen van het VHD-bestand als het blok al schrijfbewerkingen bevat. Anders worden blokkades van het bovenliggende VHD-bestand bediend. In beide gevallen leest het systeem metadata om de bloktoewijzing te bepalen. Lezen en schrijven naar deze VHD kan meer CPU verbruiken en resulteren in meer I/O's dan een vast VHD-bestand.

Wanneer er slechts een paar snapshots zijn, kunnen opslag-I/O's mogelijk meer CPU gebruiken dan normaal, maar dit heeft geen merkbare invloed op de prestaties, behalve in zeer I/O-intensieve serverworkloads. Het maken en gebruiken van een grote keten van VM-snapshots veroorzaakt prestatieproblemen. Bij differentiërende bestanden moet het systeem controleren op de gevraagde blokken in veel verschillende differentiërende VHD's om van de VHD te kunnen lezen. Als u differentiërende bestanden gebruikt, raden we u aan snapshotketens kort te houden om goede schijf-I/O-prestaties te behouden.

Grootteoverwegingen

Wanneer u schijfoptimalisatie plant, moet u rekening houden met zowel de blokgrootte als de sectorgrootte. In deze sectie worden aanbevelingen beschreven voor het bepalen van de grootte van blokken en sectoren.

Blokgrootte

Omdat de blokgrootte de prestaties aanzienlijk kan beïnvloeden, raden we u aan de blokgrootte af te stemmen op de toewijzingspatronen van de workloads die de schijf gebruiken. Als een applicatie blokken toewijst in brokken van 16 MB, dan gebruik je idealiter een VHD-blokgrootte van 16 MB. Blokgroottes groter dan 2 MB zijn alleen mogelijk op VHD's met het VHDX-bestandsformaat. Wanneer de blokgrootte groter is dan het toewijzingspatroon voor een willekeurige I/O-workload, neemt de hoeveelheid ruimte toe die de VHD op de host gebruikt.

Sectorgrootte

Softwareorganisaties zijn vaak afhankelijk van schijfsectoren van 512 bytes, maar de industriestandaard verschuift naar schijfsectoren van 4 kB. Om compatibiliteitsproblemen te verminderen die kunnen voortvloeien uit veranderingen in de sectorgrootte, introduceren leveranciers van harde schijven een overgangsgrootte die wordt aangeduid als 512-emulatieschijven (512e).

Emulatiestations bieden enkele van de voordelen van native schijven met een schijfsector van 4 kB, zoals een efficiëntere indeling en een verbeterd schema voor foutcorrectiecodes (ECC). Emulatiestations leveren minder compatibiliteitsproblemen op bij het beschikbaar maken van een sectorgrootte van 4 kB op de schijfinterface.

Als u volledig gebruik wilt maken van sectoren van 4 kB, raden we u aan de VHDX-indeling te gebruiken in plaats van schijfsectoren van 512 bytes. Om compatibiliteitsproblemen tussen schijfgroottes te verminderen, implementeert u 512e-schijven voor overgangsformaat.

Ondersteuning voor overgangsgrootte met 512e-schijven

Een 512e-schijf kan een schrijfbewerking alleen uitvoeren in termen van een fysieke sector. Dit type schijf kan niet rechtstreeks een 512-byte sector schrijven waaraan het systeem deze uitgeeft. De schijf heeft een intern proces dat schrijfbewerkingen mogelijk maakt, waarbij RMW-bewerkingen (Read-Modify-Write) in de volgende volgorde worden uitgevoerd:

• Eerst leest de schijf de fysieke sector van 4 kB in de interne cache. De cache bevat de logische sector van 512 bytes waarnaar wordt verwezen in de schrijfbewerking.

• Vervolgens wijzigt de schijf de gegevens in de buffer van 4 kB om de bijgewerkte sector van 512 bytes op te nemen.

• Ten slotte schrijft de schijf de bijgewerkte buffer van 4 kB terug naar de fysieke sector op de schijf.

Het totale effect van het RMW-proces op de prestaties is afhankelijk van de werklast. Het RMW-proces kan om de volgende redenen leiden tot prestatievermindering in virtuele harde schijven:

• Dynamische en verschillende VHD's hebben een bitmap van 512 bytes voor hun gegevenslading. Voettekst-, koptekst- en bovenliggende locators zijn uitgelijnd met een sector van 512 bytes. Het is gebruikelijk dat het stuurprogramma van de virtuele harde schijf schrijfbewerkingen van 512 bytes uitvoert om deze structuren bij te werken, waardoor de schijf het RMW-proces uitvoert.

• Toepassingen voeren gewoonlijk lees- en schrijfbewerkingen uit in veelvouden van 4 kB, aangezien 4 kB de standaardclustergrootte van NTFS is. Dynamische en differentiërende virtuele harde schijven hebben een sectorbitmap van 512 bytes voor het payloadblok voor gegevens. Deze bitmap zorgt ervoor dat de blokken van 4 kB niet worden uitgelijnd met de fysieke grens van 4 kB. In het volgende diagram ziet u een gemarkeerd VHD 4-KB-blok dat niet is uitgelijnd met de fysieke 4-KB-grens.

  

Elke schrijfbewerking van 4 kB door de huidige parser om de payloadgegevens bij te werken, resulteert in twee leesbewerkingen voor twee blokken op de schijf. Het systeem werkt vervolgens de blokken bij en schrijft ze terug naar de twee schijfblokken. Hyper-V in Windows Server 2016 beperkt enkele prestatie-effecten op 512e-schijven op de VHD-stack. Hyper-V bereidt de structuren voor op uitlijning met 4-KB-grenzen in het VHD-formaat. De beperking vermijdt het RMW-effect op de toegang tot gegevens in het bestand van de virtuele harde schijf en updates van de metagegevensstructuren van de virtuele harde schijf.

Zoals eerder vermeld, worden VHD's die zijn gekopieerd uit eerdere versies van Windows Server niet automatisch uitgelijnd met 4 kB. U kunt de schijf handmatig converteren om optimaal uit te lijnen met behulp van de optie Kopiëren van bronschijf met de Convert-VHD opdracht.

VHD's worden standaard blootgesteld met een fysieke sectorgrootte van 512 bytes. Deze methode zorgt ervoor dat de toepassingen die afhankelijk zijn van de fysieke sectorgrootte niet worden beïnvloed wanneer u de toepassing en VHD's migreert vanuit een eerdere versie van Windows Server.

Standaard maakt het systeem VHDX-schijven met een fysieke sectorgrootte van 4 kB om hun prestatieprofiel op gewone schijven en grotere sectorschijven te optimaliseren.

Om compatibiliteitsproblemen tussen schijfgroottes te verminderen, raden we u aan 512e-schijven te implementeren voor overgangsgrootte. Gebruik de VHDX-indeling om volledig gebruik te maken van sectoren van 4 kB.

Native schijven van 4 kB

Hyper-V in Windows Server 2012 R2 en hoger ondersteunt native schijven van 4 kB. U kunt VHD-schijfgegevens ook opslaan op een native schijf van 4 kB door een softwarematig RMW-algoritme te implementeren in de virtuele opslagstacklaag. Het algoritme converteert toegangs- en updateverzoeken van 512 bytes naar overeenkomstige toegangen en updates van 4 kB.

Omdat VHD-bestanden alleen kunnen worden weergegeven als schijven van 512 bytes met een logische sectorgrootte, is het waarschijnlijk dat er toepassingen zijn die I/O-aanvragen van 512 bytes uitgeven. In dergelijke gevallen voldoet het RMW-algoritme in de opslagstacklaag aan de verzoeken en veroorzaakt het prestatievermindering. Hetzelfde resultaat doet zich voor voor VHDX-schijven met een logische sectorgrootte van 512 bytes.

U kunt VHDX-bestanden zo configureren dat ze worden weergegeven als een schijf van 4 kB met een logische sectorgrootte. Deze implementatie is een optimale configuratie voor prestaties voor schijven die worden gehost op een native fysiek apparaat van 4 kB. Zorg er echter voor dat de logische sectorgrootte van 4 kB zowel de gast als de toepassing ondersteunt die de virtuele schijf gebruikt. De VHDX-indeling werkt correct op een apparaat met een logische sectorgrootte van 4 kB.

We raden u aan geen native schijven van 4 kB te gebruiken met VHD- en VHDX-bestanden, omdat dit prestatieverlies kan veroorzaken. Wanneer in uw scenario systeemeigen schijven van 4 kB zijn vereist, moet u de VHDX-indeling gebruiken op een apparaat met een logische sectorgrootte van 4 kB.

Passthrough-schijven

We raden u aan het gebruik van passthrough-schijven te vermijden vanwege de beperkingen die deze introduceren in VM-migratiescenario's.

Als u een VHD in een virtuele machine rechtstreeks toewijst aan een fysieke schijf of LUN (Logical Unit Number) in plaats van een VHD-bestand, wordt dit een passthrough-schijf genoemd. Passthrough-schijven stellen u in staat het NTFS-bestandssysteem in de hoofdpartitie te omzeilen, waardoor het CPU-gebruik van opslag-I/O wordt verminderd. Het gebruik van pass-through-schijven brengt echter ook het risico met zich mee dat fysieke schijven of LUN's moeilijker tussen machines kunnen migreren dan VHD-bestanden.

Geavanceerde opslagfuncties

In dit gedeelte worden nog enkele prestatie-optimalisaties besproken die u zou moeten overwegen voor geavanceerde opslagfuncties.

Opslagkwaliteit van de service (QoS)

In Windows Server 2012 R2 en hoger omvat Hyper-V de mogelijkheid om bepaalde QoS-parameters (Quality of Service) in te stellen voor opslag op VM's. We raden u aan Storage QoS te implementeren om toegang te krijgen tot extra opslagparameters, maximale en minimale IOPS-drempels voor virtuele harde schijven in te stellen en de schijfprestaties te controleren. U kunt deze parameters implementeren om de volgende voordelen te behalen:

• Isolatie van opslagprestaties configureren in een multitenant-omgeving

• Specificeer de maximale en minimale invoer-/uitvoerbewerkingen per seconde (IOPS) voor virtuele harde schijven

  • Beheerders kunnen de opslag-I/O beperken om te voorkomen dat een tenant buitensporige opslagbronnen verbruikt die van invloed kunnen zijn op andere tenants. Stel de minimale IOPS-waarde in en ontvang meldingen wanneer het systeem niet voldoet aan de drempel voor optimale prestaties. We specificeren de maximale of minimale IOPS-waarden in termen van genormaliseerde IOPS, waarbij we elke 8 KB aan gegevens als een I/O gebruiken.

• Ontvang meldingen wanneer de I/O-prestaties van storage onder gedefinieerde drempels vallen om VM-workloads efficiënt uit te voeren

• Krijg toegang tot opslagparameters voor de infrastructuur voor VM-metrische gegevens en stel beheerders in staat om prestaties en terugboekingsgerelateerde parameters te bewaken

Houd er echter ook rekening mee dat Storage QoS de volgende beperkingen heeft:

• Alleen beschikbaar voor virtuele schijven

• Differentiërende schijf kan geen bovenliggende virtuele schijf op een ander volume hebben

• QoS voor een replicasite wordt afzonderlijk van de primaire site geconfigureerd

• Opslag QoS biedt geen ondersteuning voor gedeelde VHDX

Zie Opslagkwaliteit van de service voor Hyper-V voor meer informatie.

NUMA I/O-registerinstellingen voor grote VM's

Windows Server 2012 en hoger biedt ondersteuning voor het projecteren van een virtuele, niet-uniforme NUMA-topologie (Memory Access) in Hyper-V VM's. NUMA-ondersteuning verbetert de prestaties van workloads die worden uitgevoerd op VM's die zijn geconfigureerd met grote hoeveelheden geheugen of grote VM's. Om deze ondersteuning mogelijk te maken, vereisen grote VM-configuraties schaalbaarheid in termen van I/O-doorvoer. Een voorbeeld van een grote VM is Microsoft SQL Server met 64 virtuele processors.

De volgende verbeteringen van Windows Server voldoen aan de I/O-schaalbaarheidsvereisten van grote VM's:

• Het creëren van meer communicatiekanalen tussen gastapparaten en de hostopslagstack.

• Een efficiënter I/O-voltooiingsmechanisme met interrupt-distributie tussen de virtuele processors om dure onderbrekingen tussen processors te voorkomen.

Registersleutels

We raden u aan de registersleutelinstellingen van Windows Server NUMA te gebruiken om de prestaties van workloads die op grote VM's worden uitgevoerd, te verbeteren.

We hebben enkele registervermeldingen toegevoegd en bijgewerkt om de verbeteringen in de vorige sectie te ondersteunen en u in staat te stellen het aantal kanalen aan te passen. U kunt de vermeldingen vinden op HKLM\System\CurrentControlSet\Enum\VMBUS\<device id>\<instance id>\StorChannel.

Het <device id>\<instance id>\ gedeelte van het pad komt overeen met de relevante waarden in uw configuratie. Deze registervermeldingen stemmen de virtuele processors die de I/O-voltooiingen afhandelen uit op de virtuele CPU's die de toepassing is toegewezen als de I/O-processors. Het systeem configureert registerinstellingen per adapter op de hardwaresleutel van het apparaat.

Hier zijn twee belangrijke instellingen om te overwegen:

• ChannelCount (DWORD) is het totale aantal communicatiekanalen dat uw implementatie kan gebruiken. De maximale waarde is 16. Het aantal kanalen is standaard gelijk aan het aantal virtuele processors gedeeld door 16.

• ChannelMask (QWORD) is de processoraffiniteit voor de kanalen. Als u deze sleutelinstelling niet opgeeft of de waarde niet instelt op 0, wordt het kanaalmasker standaard ingesteld op het bestaande algoritme voor kanaaldistributie voor normale opslag- of netwerkkanalen. De standaardactie zorgt ervoor dat uw opslagkanalen niet conflicteren met uw netwerkkanalen.

Integratie van geoffloade gegevensoverdracht

We raden u aan ODX-bewerkingen (Offloaded Data Transfer) te gebruiken om ervoor te zorgen dat de VM-workload ODX-opslag kan gebruiken op dezelfde manier als in een fysieke omgeving.

Cruciale onderhoudstaken voor VHD's, zoals samenvoegen, verplaatsen en comprimeren, omvatten het kopiëren van grote hoeveelheden gegevens. De huidige methode voor het kopiëren van gegevens vereist dat het systeem gegevens naar verschillende locaties leest en schrijft, wat tijdrovend is en CPU- en geheugenbronnen gebruikt die naar het onderhoud van VM's hadden kunnen gaan.

Leveranciers van Storage Area Network (SAN) kunnen een hardwarefunctie bieden met de naam ODX. Met deze functie kunnen vrijwel onmiddellijke kopieerbewerkingen worden uitgevoerd voor grote hoeveelheden gegevens. ODX staat het systeem toe, niet de schijven, om op te geven hoe specifieke gegevenssets van de ene locatie naar de andere moeten worden verplaatst.

Hyper-V in Windows Server 2012 en hoger ondersteunt ODX-bewerkingen om gekopieerde gegevens van het gastbesturingssysteem door te geven aan de hosthardware. De workload kan ODX-opslag gebruiken, net als in een niet-gevirtualiseerde omgeving. De Hyper-V-opslagstack kan ook ODX-bewerkingen uitvoeren tijdens onderhoudsbewerkingen voor VHD's, zoals het samenvoegen van schijven en het opslaan van metabewerkingen tijdens grote gegevensmigraties.

Integratie van meldingen ongedaan maken

We raden u aan unmap-meldingen te gebruiken om uw VHDX-bestanden efficiënter te maken en het onderliggende fysieke opslagapparaat ongebruikte ruimte te laten vrijmaken.

VHD-bestanden bevinden zich op een opslagvolume waar ze de beschikbare ruimte delen met andere bestanden. Omdat hun bestandsgrootte meestal groot is, kunnen VHD-bestanden veel ruimte in beslag nemen. Een grotere vraag naar opslagruimte heeft gevolgen voor de budgetten voor IT-hardware, wat betekent dat u het fysieke ruimtegebruik waar mogelijk moet optimaliseren.

In versies van Windows Server ouder dan Windows Server 2012 hadden de Windows-opslagstack in het gastbesturingssysteem en de Hyper-V host beperkingen waardoor ze de opslagruimte niet konden optimaliseren. Wanneer applicaties inhoud in een VHD verwijderden, bleef de opslagruimte verlaten. Het systeem stelt de VHD of het fysieke opslagapparaat niet op de hoogte van de verwijderde informatie, waardoor de Hyper-V opslagstack geen ruimte kon optimaliseren voor de op VHD gebaseerde virtuele schijfbestanden. Als gevolg hiervan kon het onderliggende opslagapparaat de nu ongebruikte ruimte die de verwijderde gegevens in beslag namen, niet terugwinnen.

Vanaf Windows Server 2012 biedt Hyper-V ondersteuning voor het ongedaan maken van meldingen. Met deze functie kunnen VHDX-bestanden verwijderde gegevens rapporteren aan de opslagstack, wat de efficiëntie maximaliseert door de bestandsgrootte klein te houden en de stack ongebruikte opslagruimte te laten terugwinnen voor ander gebruik.

Alleen Hyper-V-specifieke SCSI-, enlightened IDE- en Virtual Fibre Channel-controllers staan toe dat de unmap opdracht van het gastbesturingssysteem de virtuele opslagstack van de host bereikt. Op VHD's ondersteunen unmap alleen virtuele schijven die zijn geformatteerd als VHDX opdrachten van het gastbesturingssysteem.

Verwante inhoud

• terminologieHyper-V

• Hyper-V architectuur

• Hyper-V server configuratie

• Hyper-V prestaties van de processor

• Hyper-V geheugenprestaties

• Hyper-V netwerk-I/O-prestaties

• Knelpunten detecteren in een gevirtualiseerde omgeving

• Virtuele Linux-machines