Opslagcapaciteit beheren voor Azure Stack Hub

U kunt dit artikel gebruiken als een Azure Stack Hub-cloudoperator voor meer informatie over het bewaken en beheren van de opslagcapaciteit van uw Azure Stack Hub-implementatie. U kunt de richtlijnen gebruiken om inzicht te verkrijgen in het geheugen dat beschikbaar is voor de VM's van uw gebruiker. De Azure Stack Hub-opslaginfrastructuur wijst een subset van de totale opslagcapaciteit van de Azure Stack Hub-implementatie toe als opslagservices. Opslagservices slaan de gegevens van een tenant op in shares op volumes die overeenkomen met de knooppunten van de implementatie.

Als cloudoperator hebt u een beperkte hoeveelheid opslagruimte om mee te werken. De hoeveelheid opslag wordt gedefinieerd door de oplossing die u implementeert. De oplossing wordt geleverd door uw OEM-leverancier wanneer u een oplossing met meerdere knooppunten gebruikt, of wordt geleverd door de hardware waarop u de Azure Stack Development Kit (ASDK) installeert.

Azure Stack Hub ondersteunt alleen de uitbreiding van de opslagcapaciteit door extra schaaleenheidknooppunten toe te voegen. Zie Schaaleenheidknooppunten toevoegen in Azure Stack Hub voor meer informatie. Als u fysieke schijven toevoegt aan de knooppunten, wordt de opslagcapaciteit niet uitgebreid.

Het is belangrijk om de beschikbare opslag te bewaken om ervoor te zorgen dat efficiënte bewerkingen worden onderhouden. Wanneer de resterende vrije capaciteit van een volume beperkt wordt, kunt u de beschikbare ruimte beheren om te voorkomen dat de capaciteit van de shares opraakt.

De opties voor het beheren van capaciteit zijn onder andere:

• Capaciteit vrijmaken.
• Opslagobjecten migreren.

Wanneer een objectopslagvolume 100% wordt gebruikt, werkt de opslagservice niet meer voor dat volume. Neem contact op met Microsoft-ondersteuning voor hulp bij het herstellen van bewerkingen voor het volume.

Informatie over schijven, containers en volumes

Tenantgebruiker maakt schijven, blobs, tabellen en wachtrijen in Azure Stack Hub-opslagservices. Deze tenantgegevens worden op volumes geplaatst boven op de beschikbare opslag.

Disks

VM-gegevens opslaan en bewerken op virtuele schijven. Elke VM begint met een besturingssysteemschijf die is gemaakt op basis van een Marketplace-installatiekopieën of een persoonlijke installatiekopieën. De VM kan nul of meer gegevensschijven koppelen. Er zijn twee typen schijven beschikbaar in Azure Stack:

Beheerde schijven vereenvoudigen het schijfbeheer voor Azure IaaS-VM's door de opslagaccounts te beheren die zijn gekoppeld aan de VM-schijven. U hoeft alleen de grootte van de schijf op te geven die u nodig hebt en Azure Stack Hub maakt en beheert de schijf voor u. Zie overzicht van Managed Disks voor meer informatie.

Niet-beheerde schijven zijn VHD-bestanden die worden opgeslagen als pagina-blobs in opslagcontainers in Azure Stack-opslagaccounts. De pagina-blobs die door tenants zijn gemaakt, worden VM-schijven genoemd en worden opgeslagen in containers in de opslagaccounts. U wordt aangeraden onbeheerde schijven alleen te gebruiken voor VM's die compatibel moeten zijn met hulpprogramma's van derden, die alleen ondersteuning bieden voor niet-beheerde Azure-schijven.

De richtlijnen voor tenants zijn om elke schijf in een afzonderlijke container te plaatsen om de prestaties van de VM te verbeteren.

• Elke container met een schijf of pagina-blob van een VM wordt beschouwd als een gekoppelde container aan de VM die eigenaar is van de schijf.
• Een container die geen schijven van een VM bevat, wordt beschouwd als een gratis container.

De opties voor het vrijmaken van ruimte op een gekoppelde container zijn beperkt. Zie Niet-beheerde schijven distribueren voor meer informatie.

Belangrijk

We raden u aan alleen beheerde schijven in VM's te gebruiken voor eenvoudiger beheer. U hoeft geen opslagaccounts en containers voor te bereiden voordat u Beheerde schijven gebruikt. Beheerde schijven bieden gelijkwaardige of betere functionaliteit en prestaties in vergelijking met onbeheerde schijven. Het gebruik van onbeheerde schijven heeft geen voordelen en ze zijn alleen beschikbaar voor compatibiliteit met eerdere versies.

Beheerde schijven zijn geoptimaliseerd voor een betere plaatsing in de opslaginfrastructuur en hebben aanzienlijk minder overhead voor beheer. Maar omdat beheerde schijven dun zijn ingericht en het uiteindelijke gebruik onvoorspelbaar is bij het maken, zijn er kansen dat het volume te veel wordt gebruikt vanwege onevenwichtige schijfplaatsing. Operators zijn verantwoordelijk voor het bewaken van het gebruik van de opslagcapaciteit en voorkomen een dergelijk probleem.

Voor gebruikers die ARM-sjablonen gebruiken voor het inrichten van nieuwe virtuele machines, gebruikt u het volgende document om te begrijpen hoe u uw sjablonen kunt wijzigen voor het gebruik van beheerde schijven: Sjablonen voor beheerde vm-schijven gebruiken.

VM-schijven worden opgeslagen als sparse-bestanden in de opslaginfrastructuur. Schijven hebben een grootte ingericht die de gebruiker aanvraagt op het moment dat de schijf wordt gemaakt. Alleen de niet-nulpagina's die naar de schijf zijn geschreven, nemen echter ruimte in beslag op de onderliggende opslaginfrastructuur.

Schijven worden vaak gemaakt door te kopiëren van platforminstallatiekopieën, beheerde installatiekopieën, momentopnamen of andere schijven. En momentopnamen worden gemaakt van schijven. Om het gebruik van de opslagcapaciteit te verhogen en de kopieerbewerkingstijd te verkorten, gebruikt het systeem blokklonen in ReFS. Klonen van blobs is een goedkope metagegevensbewerking in plaats van een volledige byte-bytekopie tussen bestanden. Het bronbestand en het doelbestand kunnen dezelfde gebieden delen, identieke gegevens worden niet meerdere keren fysiek opgeslagen, waardoor de opslagcapaciteit wordt verbeterd.

Het capaciteitsgebruik neemt alleen toe wanneer de schijven worden geschreven en identieke gegevens verminderen. Wanneer een installatiekopie of schijf wordt verwijderd, wordt de ruimte mogelijk niet onmiddellijk vrijgemaakt, omdat er schijven of momentopnamen van kunnen zijn gemaakt, nog steeds identieke gegevens behouden en ruimte innemen. Alleen als alle gerelateerde entiteiten worden verwijderd, komt de ruimte beschikbaar.

Blobs en containers

Tenantgebruikers slaan enorme hoeveelheden ongestructureerde gegevens op met Azure Blob. Azure Stack Hub ondersteunt drie typen blobs: blok-blobs, toevoeg-blobs en pagina-blobs. Zie Blok-blobs, toevoeg-blobs en pagina-blobs voor meer informatie over de verschillende soorten blobs.

Tenantgebruikers maken containers die vervolgens worden gebruikt voor het opslaan van blobgegevens. Hoewel gebruikers beslissen in welke container blobs moeten worden geplaatst, gebruikt de opslagservice een algoritme om te bepalen op welk volume de container moet worden geplaatst. Het algoritme kiest doorgaans het volume met de meest beschikbare ruimte.

Nadat een blob in een container is geplaatst, kan de blob groter worden en meer ruimte gebruiken. Wanneer u nieuwe blobs toevoegt en bestaande blobs groter worden, wordt de beschikbare ruimte in het volume met de container kleiner.

Containers zijn niet beperkt tot één volume. Wanneer de gecombineerde blobgegevens in een container 80% of meer van de beschikbare ruimte gebruiken, wordt de overloopmodus van de container geactiveerd. In de overloopmodus worden nieuwe blobs die in die container worden gemaakt, toegewezen aan een ander volume met voldoende ruimte. Na verloop van tijd kan een container in de overloopmodus blobs hebben die zijn verdeeld over meerdere volumes.

Wanneer 90% (en vervolgens 95%) van de beschikbare ruimte in een volume wordt gebruikt, genereert het systeem waarschuwingen in de Azure Stack Hub-beheerportal. Cloudoperators moeten de beschikbare opslagcapaciteit beoordelen en plannen om de inhoud opnieuw te verdelen. De opslagservice werkt niet meer wanneer een schijf 100% wordt gebruikt en er geen extra waarschuwingen worden weergegeven.

Volumes

De opslagservice partitioneert de beschikbare opslag in afzonderlijke volumes die zijn toegewezen voor het opslaan van systeem- en tenantgegevens. Volumes combineren de stations in de opslaggroep om de fouttolerantie, schaalbaarheid en prestatievoordelen van Opslagruimten Direct te introduceren. Zie Opslaginfrastructuur beheren voor Azure Stack Hub voor meer informatie over volumes in Azure Stack Hub.

Objectopslagvolumes bevatten tenantgegevens. Tenantgegevens omvatten pagina-blobs, blok-blobs, toevoeg-blobs, tabellen, wachtrijen, databases en gerelateerde metagegevensarchieven. Het aantal objectopslagvolumes is gelijk aan het aantal knooppunten in de Azure Stack Hub-implementatie:

• Bij een implementatie met vier knooppunten zijn er vier objectopslagvolumes. Bij een implementatie met meerdere knooppunten wordt het aantal volumes niet verminderd als een knooppunt wordt verwijderd of niet goed werkt.
• Als u de ASDK gebruikt, is er één volume met één share.

De objectopslagvolumes zijn uitsluitend bedoeld voor het gebruik van opslagservices. U mag bestanden op de volumes niet rechtstreeks wijzigen, toevoegen of verwijderen. Alleen opslagservices mogen werken op de bestanden die zijn opgeslagen in deze volumes.

Omdat de opslagobjecten (blobs, enzovoort) afzonderlijk in één volume zijn opgenomen, mag de maximale grootte van elk object niet groter zijn dan de grootte van een volume. De maximale grootte van nieuwe objecten is afhankelijk van de capaciteit die in een volume overblijft als ongebruikte ruimte wanneer dat nieuwe object wordt gemaakt.

Wanneer er weinig vrije ruimte beschikbaar is voor een objectopslag en acties om ruimte vrij te maken niet lukt of niet beschikbaar zijn, kunnen Azure Stack Hub-cloudoperators opslagobjecten migreren van het ene volume naar het andere.

Zie Azure Stack Hub Storage-services voor informatie over hoe tenantgebruikers werken met blob-opslag in Azure Stack Hub.

Opslag bewaken

Gebruik Azure PowerShell of de beheerdersportal om ingerichte en gebruikte capaciteit te bewaken en migratie te plannen om een continue normale werking van het systeem te garanderen.

Er zijn drie hulpprogramma's voor het bewaken van volumecapaciteit:

• Portal en PowerShell van voor de huidige volumecapaciteit.
• Waarschuwingen voor opslagruimte.
• Metrische gegevens over volumecapaciteit.

In deze sectie wordt uitgelegd hoe u deze hulpprogramma's kunt gebruiken om de capaciteit van het systeem te bewaken.

PowerShell gebruiken

Als cloudoperator kunt u de opslagcapaciteit van een volume bewaken met behulp van de PowerShell-cmdlet Get-AzsVolume . De cmdlet retourneert de totale en vrije ruimte in gigabyte (GB) op elk van de volumes.

• Totale capaciteit: De totale ruimte in GB die beschikbaar is op de share. Deze ruimte wordt gebruikt voor gegevens en metagegevens die worden onderhouden door de opslagservices.
• Resterende capaciteit: De hoeveelheid ruimte in GB die vrij is om de tenantgegevens en de bijbehorende metagegevens op te slaan.

De beheerdersportal gebruiken

Als cloudoperator kunt u de beheerdersportal gebruiken om de opslagcapaciteit van alle volumes weer te geven.

1. Meld u aan bij de Azure Stack Hub-beheerdersportal (https://adminportal.local.azurestack.external).

2. Selecteer Alle services>Opslagvolumes> om de lijst met volumes te openen waar u de gebruiksgegevens kunt bekijken.

   

   • Totaal: de totale beschikbare ruimte op het volume. Deze ruimte wordt gebruikt voor gegevens en metagegevens die worden onderhouden door de opslagservices.
   • Gebruikt: de hoeveelheid gegevens die wordt gebruikt door alle gebieden van de bestanden waarin de tenantgegevens en de bijbehorende metagegevens worden opgeslagen.

Waarschuwingen voor opslagruimte

Wanneer u de beheerdersportal gebruikt, ontvangt u waarschuwingen over volumes met weinig ruimte.

Belangrijk

Als cloudoperator moet u voorkomen dat shares volledig worden gebruikt. Wanneer een share voor 100% wordt gebruikt, werkt de opslagservice niet meer voor die share. Als u vrije ruimte en herstelbewerkingen wilt herstellen op een share die 100% wordt gebruikt, moet u contact opnemen met Microsoft Ondersteuning.

• Waarschuwing: wanneer een bestandsshare voor meer dan 90% wordt gebruikt, ontvangt u een waarschuwing in de beheerdersportal:

  

• Kritiek: wanneer een bestandsshare voor meer dan 95% wordt gebruikt, ontvangt u een waarschuwing Kritiek in de beheerdersportal:

  

• Details weergeven: In de beheerdersportal kunt u de details van een waarschuwing openen om de risicobeperkingsopties weer te geven:

  

Metrische gegevens over volumecapaciteit

Metrische gegevens over volumecapaciteit bieden meer gedetailleerde informatie over ingerichte capaciteit en gebruikte capaciteit voor verschillende typen objecten. De metrische gegevens worden 30 dagen bewaard. De bewakingsservice op de achtergrond vernieuwt de metrische gegevens van de volumecapaciteit per uur.

Het is noodzakelijk om inzicht te hebben in het resourcegebruik van een volume door het rapport met metrische capaciteit proactief te controleren. De cloudoperator kan de distributie van het resourcetype analyseren wanneer een volume vol is om de bijbehorende actie voor vrije ruimte te bepalen. De operator kan ook voorkomen dat het volume te veel wordt gebruikt wanneer de grootte van de ingerichte schijf aangeeft dat het volume te veel is ingericht.

Azure Monitor biedt de volgende metrische gegevens om het volumecapaciteitsgebruik weer te geven:

• Volume Total Capacity toont de totale opslagcapaciteit van het volume.
• Volume resterende capaciteit toont de resterende opslagcapaciteit van het volume.
• Volume VM Disk Used Capacity toont de totale ruimten die worden ingenomen door vm-schijfgerelateerde objecten (inclusief pagina-blobs, beheerde schijven/momentopnamen, beheerde installatiekopieën en platforminstallatiekopieën). Het onderliggende VHD-bestand van VM-schijven kan dezelfde mate delen (zie Schijven) met installatiekopieën, momentopnamen of andere schijven. Dit getal kan kleiner zijn dan de som van de gebruikte capaciteit van alle afzonderlijke VM-schijfgerelateerde objecten.
• Volume Overige gebruikte capaciteit is de totale gebruikte grootte van andere objecten dan schijven, inclusief blok-blobs, toevoeg-blobs, tabellen, wachtrijen en blobmetagegevens.
• Volume-VM-schijf ingerichte capaciteit is de totale ingerichte grootte van pagina-blobs en beheerde schijven/momentopnamen. Deze grootte is de maximale waarde van de totale schijfcapaciteit van alle beheerde schijven en pagina-blobs op het specifieke volume kan toenemen tot.

Metrische gegevens over volumecapaciteit weergeven in Azure Monitor:

1. Controleer of u Azure PowerShell hebt geïnstalleerd en geconfigureerd. Zie PowerShell voor Azure Stack Hub installeren voor instructies over het configureren van de PowerShell-omgeving. Zie De operatoromgeving configureren en aanmelden bij Azure Stack Hub om u aan te melden bij Azure Stack Hub.

2. Download Azure Stack Hub-hulpprogramma's uit de GitHub-opslagplaats. Zie Azure Stack Hub-hulpprogramma's downloaden van GitHub voor gedetailleerde stappen.

3. Genereer de json capaciteitsdashboard door dashboardgenerator uit te voeren onder CapacityManagement.

   .\CapacityManagement\DashboardGenerator\Create-AzSStorageDashboard.ps1 -capacityOnly $true -volumeType object
   

   Er zou een json-bestand met de naam begint met DashboardVolumeObjStore onder de map dashboardgenerator.

4. Meld u aan bij de Azure Stack Hub-beheerdersportal (https://adminportal.local.azurestack.external).

5. Klik op de pagina Dashboard op Uploaden en selecteer het json-bestand dat is gegenereerd in stap 3.

   

6. Zodra de json is geüpload, wordt u omgeleid naar het nieuwe capaciteitsdashboard. Elk volume heeft een bijbehorende grafiek in het dashboard. Het aantal grafieken is gelijk aan het aantal volumes:

   

7. Door op een van de volumes te klikken, kunt u vijf metrische capaciteitsgegevens van het specifieke volume in de gedetailleerde grafiek controleren:

   

Volumegebruikspatronen

Door de metrische gegevens van de volumecapaciteit te controleren, begrijpt de cloudoperator hoeveel de capaciteit van een volume wordt gebruikt en welk resourcetype het grootste deel van het ruimtegebruik in beslag neemt. Het gebruikspatroon van de ruimte kan worden gegroepeerd in de volgende typen, welke operator verschillende acties moet uitvoeren voor elk van de typen:

Onvoldoende ingerichte reservecapaciteit: er is voldoende beschikbare capaciteit op het volume en de totale ingerichte capaciteit van alle schijven op dit volume is kleiner dan de totale beschikbare capaciteit. Het volume is beschikbaar voor meer opslagobjecten, waaronder schijven en andere objecten (blok-/toevoeg-blobs, tabellen en wachtrijen). U hoeft geen actie te ondernemen om het volume te bedienen.

Overingerichte reservecapaciteit: de resterende capaciteit van het volume is hoog, maar de ingerichte capaciteit van de VM-schijf is al hoger dan de totale capaciteit van het volume. Dit volume heeft nu nog ruimte voor meer opslagobjecten. Het kan echter worden gevuld met de gegevens op de VM-schijven op dit volume. U moet de gebruikstrend van dit volume nauwlettend in de gaten houden. Als het verandert in een patroon met te veel ingerichte, lage capaciteit, moet u mogelijk actie ondernemen om de ruimte vrij te maken.

Te weinig ingerichte capaciteit: de resterende capaciteit van het volume is laag en zowel de ingerichte capaciteit van de VM-schijf als de gebruikte capaciteit van de VM-schijf is hoog.

De lage resterende capaciteit geeft aan dat het volume volledig wordt gebruikt. Operators moeten onmiddellijk actie ondernemen om ruimte vrij te maken om te voorkomen dat het volume 100% wordt gebruikt, waardoor de opslagservice wordt geblokkeerd. De gebruikte capaciteit van de hoge VM-schijf geeft aan dat het grootste deel van het volumegebruik VM-schijven is. Raadpleeg de instructie Schijf migreren om schijven van het volledige volume naar andere beschikbare volumes te verplaatsen naar vrije ruimte.

Te weinig ingerichte, lage capaciteit, hoge blok-blobs: de resterende capaciteit van het volume is laag en zowel de capaciteit van de ingerichte VM-schijf als de gebruikte capaciteit van de VM-schijf is laag, maar de andere gebruikte capaciteit is hoog.

Het volume heeft het risico dat deze operator onmiddellijk actie moet ondernemen om ruimte vrij te maken. De hoge andere gebruikte capaciteit geeft aan dat het grootste deel van de volumecapaciteit wordt gebruikt door blok-/toevoeg-blobs of tabel/wachtrij. Wanneer de beschikbare capaciteit van het volume kleiner is dan 20%, wordt de containeroverloop ingeschakeld en wordt het nieuwe blobobject niet op dit bijna volle volume geplaatst. Maar de bestaande blobs kunnen nog steeds groeien. Als u wilt voorkomen dat de continu groeiende blobs de capaciteit overbelasten, kunt u contact opnemen met Microsoft Ondersteuning om een query uit te voeren op de containers die ruimte op het specifieke volume in beslag nemen en bepalen of tenants deze containers moeten opschonen om ruimte vrij te maken.

Te veel ingerichte, lage capaciteit, hoge blok-blobs: de resterende capaciteit van het volume is laag en zowel de gebruikte/ingerichte schijfcapaciteit als andere gebruikte capaciteit is hoog. Dit volume heeft een hoog ruimtegebruik door zowel schijven als andere opslagobjecten. U moet ruimte vrijmaken om te voorkomen dat het volume volledig vol is. Het wordt aanbevolen om eerst de instructies van Schijf migreren te volgen om schijven van het volledige volume naar andere beschikbare volumes te verplaatsen. In andere gevallen kunt u contact opnemen met Microsoft Ondersteuning om een query uit te voeren op de containers die ruimte op het specifieke volume in beslag nemen en bepalen of het opschonen van deze containers moet worden uitgevoerd door tenants om ruimte vrij te maken.

Beschikbare ruimte beheren

Wanneer het nodig is om ruimte vrij te maken op een volume, gebruikt u eerst de minst invasieve methoden. Probeer bijvoorbeeld ruimte vrij te maken voordat u een beheerde schijf migreert.

Capaciteit vrijmaken

U kunt de capaciteit terugvorderen die wordt gebruikt door tenantaccounts die zijn verwijderd. Deze capaciteit wordt automatisch vrijgemaakt wanneer de gegevensretentieperiode is bereikt, of u kunt actie ondernemen om deze onmiddellijk terug te vorderen.

Zie de sectie 'Capaciteit vrijmaken' van Azure Stack Hub-opslagaccounts beheren voor meer informatie.

Een beheerde schijf migreren tussen volumes

Deze optie is alleen van toepassing op geïntegreerde Azure Stack Hub-systemen.

Vanwege tenantgebruikspatronen gebruiken sommige tenantvolumes meer ruimte dan andere. Het resultaat kan een volume zijn dat weinig ruimte heeft voor andere volumes die relatief ongebruikt zijn.

U kunt ruimte vrijmaken op een volume dat te veel wordt gebruikt door een aantal beheerde schijven handmatig naar een ander volume te migreren. U kunt meerdere beheerde schijven migreren naar één volume dat capaciteit heeft om ze allemaal op te slaan. Migratie gebruiken om beheerde offlineschijven te verplaatsen. Offline beheerde schijven zijn schijven die niet zijn gekoppeld aan een virtuele machine.

Belangrijk

Migratie van beheerde schijven is een offlinebewerking waarvoor het gebruik van PowerShell is vereist. U moet de toewijzing van de eigenaar-VM's van de kandidaatschijf ongedaan maken of de kandidaatschijven voor migratie loskoppelen van de eigen VM voordat u de migratietaak start (zodra de migratietaak is voltooid, kunt u de VM's opnieuw toewijzen of de schijven opnieuw koppelen). Totdat de migratie is voltooid, moeten alle beheerde schijven die u migreert de status Gereserveerd of Offline behouden en kunnen ze niet worden gebruikt. Anders wordt de migratietaak afgebroken en bevinden alle niet-gemigreerde schijven zich nog steeds op de oorspronkelijke volumes. U moet ook voorkomen dat u Azure Stack Hub upgradet totdat alle lopende migratie is voltooid.

Beheerde schijven migreren met Behulp van PowerShell

1. Controleer of u Azure PowerShell hebt geïnstalleerd en geconfigureerd. Zie PowerShell voor Azure Stack Hub installeren voor instructies over het configureren van de PowerShell-omgeving. Zie De operatoromgeving configureren en aanmelden bij Azure Stack Hub om u aan te melden bij Azure Stack Hub.

2. Bekijk de beheerde schijven om te begrijpen welke schijven zich bevinden op het volume dat u wilt migreren. Gebruik Get-AzsDisk de cmdlet om de beste kandidaatschijven voor migratie in een volume te identificeren:

   $ScaleUnit = (Get-AzsScaleUnit)[0]
   $StorageSubSystem = (Get-AzsStorageSubSystem -ScaleUnit $ScaleUnit.Name)[0]
   $Volumes = (Get-AzsVolume -ScaleUnit $ScaleUnit.Name -StorageSubSystem $StorageSubSystem.Name | Where-Object {$_.VolumeLabel -Like "ObjStore_*"})
   $SourceVolume  = ($Volumes | Sort-Object RemainingCapacityGB)[0]
   $VolumeName = $SourceVolume.Name.Split("/")[2]
   $VolumeName = $VolumeName.Substring($VolumeName.IndexOf(".")+1)
   $MigrationSource = "\\SU1FileServer."+$VolumeName+"\SU1_"+$SourceVolume.VolumeLabel
   $Disks = Get-AzsDisk -Status OfflineMigration -SharePath $MigrationSource | Select-Object -First 10
   

   Bekijk vervolgens $disks:

   $Disks
   

   

3. Identificeer het beste doelvolume voor de schijven die u migreert:

   $DestinationVolume  = ($Volumes | Sort-Object RemainingCapacityGB -Descending)[0]
   $VolumeName = $DestinationVolume.Name.Split("/")[2]
   $VolumeName = $VolumeName.Substring($VolumeName.IndexOf(".")+1)
   $MigrationTarget = "\\SU1FileServer."+$VolumeName+"\SU1_"+$DestinationVolume.VolumeLabel
   

4. Start de migratie voor beheerde schijven. Migratie is asynchroon. Als u de migratie van andere schijven start voordat de eerste migratie is voltooid, gebruikt u de taaknaam om de status van elke schijf bij te houden.

   $jobName = "MigratingDisk"
   Start-AzsDiskMigrationJob -Disks $Disks -TargetShare $MigrationTarget -Name $jobName
   

5. Gebruik de taaknaam om de status van de migratietaak te controleren. Wanneer de schijfmigratie is voltooid, wordt MigrationStatus ingesteld op Complete.

   $job = Get-AzsDiskMigrationJob -Name $jobName
   

   

   Als u meerdere beheerde schijven migreert in één migratietaak, kunt u ook de subtaken van de taak controleren.

   $job.Subtask
   

   

6. U kunt een actieve migratietaak annuleren. Geannuleerde migratietaken worden asynchroon verwerkt. U kunt annulering bijhouden met behulp van de taaknaam totdat de status bevestigt dat de migratietaak Geannuleerd is:

   Stop-AzsDiskMigrationJob -Name $jobName
   

   

Niet-beheerde schijven distribueren

Deze optie is alleen van toepassing op geïntegreerde Azure Stack Hub-systemen.

De meest extreme methode voor het beheren van ruimte is het verplaatsen van onbeheerde schijven. Als de tenant het aantal niet-beheerde schijven aan één container toevoegt, kan de totale gebruikte capaciteit van de container groter worden dan de beschikbare capaciteit van het volume dat deze bevat voordat de container overflowmodus wordt geactiveerd. Om te voorkomen dat één container de ruimte van een volume uitput, kan de tenant de bestaande niet-beheerde schijven van één container naar andere containers distribueren. Omdat het distribueren van een gekoppelde container (een container met een VM-schijf) complex is, neemt u contact op met Microsoft Ondersteuning om deze actie uit te voeren.

Geheugen beschikbaar voor VM's

Azure Stack Hub is gebouwd als een hypergeconvergeerd cluster van rekenkracht en opslag. De convergentie maakt het delen van de hardware, ook wel een schaaleenheid genoemd, mogelijk. In Azure Stack Hub biedt een schaaleenheid de beschikbaarheid en schaalbaarheid van resources. Een schaaleenheid bestaat uit een set Azure Stack Hub-servers, ook wel hosts of knooppunten genoemd. De infrastructuursoftware wordt gehost in een set virtuele machines en deelt dezelfde fysieke servers als de tenant-VM's. Alle Azure Stack Hub-VM's worden vervolgens beheerd door de Windows Server-clusteringtechnologieën en afzonderlijke Hyper-V-exemplaren van de schaaleenheid. De schaaleenheid vereenvoudigt de aanschaf en het beheer van Azure Stack Hub. De schaaleenheid maakt ook de verplaatsing en schaalbaarheid van alle services in Azure Stack Hub, tenant en infrastructuur mogelijk.

U kunt een cirkeldiagram bekijken in de beheerportal waarin het vrije en gebruikte geheugen in Azure Stack Hub wordt weergegeven, zoals hieronder:

De volgende onderdelen gebruiken het geheugen in de gebruikte sectie van het cirkeldiagram:

• Gebruik of reservering van hostbesturingssystemen Dit is het geheugen dat wordt gebruikt door het besturingssysteem (OS) op de host, tabellen met virtuele geheugenpagina's, processen die worden uitgevoerd op het hostbesturingssysteem en de directe geheugencache van Spaces. Omdat deze waarde afhankelijk is van het geheugen dat wordt gebruikt door de verschillende Hyper-V-processen die op de host worden uitgevoerd, kan deze fluctueren.
• Infrastructuurservices Dit zijn de infrastructuur-VM's waaruit Azure Stack Hub bestaat. Dit omvat ongeveer 31 VM's die 242 GB + (4 GB x aantal knooppunten) geheugen in beslag nemen. Het geheugengebruik van het onderdeel infrastructuurservices kan veranderen als we onze infrastructuurservices schaalbaarder en toleranter maken.
• Tolerantiereserve Azure Stack Hub reserveert een deel van het geheugen om tenants beschikbaar te maken tijdens een fout met één host en tijdens patch en update om een geslaagde livemigratie van VM's mogelijk te maken.
• Tenant-VM's Dit zijn de VM's die door Azure Stack Hub-gebruikers zijn gemaakt. Naast het uitvoeren van VM's wordt geheugen verbruikt door alle VM's die op de infrastructuur zijn beland. Dit betekent dat VM's met de status Maken of Mislukt , of VM's die worden afgesloten vanuit de gast, geheugen verbruiken. VM's die zijn ongedaan gemaakt met behulp van de optie stoppen met ongedaan maken van toewijzing in de Azure Stack Hub-gebruikersportal, PowerShell en Azure CLI gebruiken echter geen geheugen van Azure Stack Hub.
• Resourceproviders voor invoegtoepassingen VM's die zijn geïmplementeerd voor de resourceproviders van de invoegtoepassing, zoals SQL, MySQL en App Service.

Beschikbaar geheugen voor VM-plaatsing

Als cloudoperator voor Azure Stack Hub is er geen geautomatiseerde manier om het toegewezen geheugen voor elke VM te controleren. U kunt toegang hebben tot uw gebruikers-VM's en het toegewezen geheugen handmatig berekenen. Het toegewezen geheugen weerspiegelt echter niet het werkelijke gebruik. Deze waarde kan lager zijn dan de toegewezen waarde.

Om het beschikbare geheugen voor VM's te trainen, wordt de volgende formule gebruikt:

Beschikbaar geheugen voor VM-plaatsing = Total Host Memory--Resiliency Reserve--Memory used by running tenant VMs - Azure Stack Hub Infrastructure Overhead

Tolerantiereserve = H + R * ((N-1) * H) + V * (N-2)

Waar:

H = Grootte van geheugen van één host

N = Grootte van schaaleenheid (aantal hosts)

R = reserve/geheugen van het besturingssysteem dat wordt gebruikt door het hostbesturingssysteem, wat in deze formule ,15 is

V = Grootste VM (qua geheugen) in de schaaleenheid

Overhead van Azure Stack Hub-infrastructuur = 242 GB + (4 GB x aantal knooppunten). Dit is goed voor de ongeveer 31 VM's die worden gebruikt voor het hosten van de infrastructuur van Azure Stack Hub.

Geheugen gebruikt door het host-besturingssysteem = 15 procent (0,15) van het hostgeheugen. De reservewaarde van het besturingssysteem is een schatting en varieert op basis van de fysieke geheugencapaciteit van de host en algemene overhead van het besturingssysteem.

De waarde V, grootste VM in de schaaleenheid, is dynamisch gebaseerd op de grootste tenant-VM die is geïmplementeerd. De grootste VM-waarde kan bijvoorbeeld 7 GB of 112 GB zijn of een andere ondersteunde VM-geheugengrootte in de Azure Stack Hub-oplossing. We kiezen hier de grootte van de grootste VM om voldoende geheugen te hebben gereserveerd, zodat een livemigratie van deze grote VM niet mislukt. Als u de grootste VM wijzigt in de Azure Stack Hub-infrastructuur, resulteert dit in een toename van de tolerantiereserve naast de toename van het geheugen van de virtuele machine zelf.

Bijvoorbeeld met een schaaleenheid van 12 knooppunten:

Zegeldetails	Waarden
sts (N)	12
Geheugen per host (H)	384
Totaal geheugen van schaaleenheid	4608
Besturingssysteemreserve (R)	15%
Grootste VM (V)	112
Tolerantiereserve =	H + R * ((N-1) * H) + V * (N-2)
Tolerantiereserve =	2137.6

Met de bovenstaande informatie kunt u dus berekenen dat een Azure Stack met 12 knooppunten van 384 GB per host (in totaal 4608 GB) 2137 GB gereserveerd heeft voor tolerantie als de grootste VM 112 GB geheugen heeft.

Wanneer u de blade Capaciteit voor het fysieke geheugen raadpleegt zoals hieronder wordt beschreven, bevat de waarde Gebruikt de tolerantiereserve. De grafiek is afkomstig van een Azure Stack Hub-exemplaar met vier knooppunten.

Houd rekening met deze overwegingen bij het plannen van de capaciteit voor Azure Stack Hub. Daarnaast kunt u de Azure Stack Hub Capacity Planner gebruiken.

Volgende stappen

Zie Opslagcapaciteit beheren voor Azure Stack Hub voor meer informatie over het aanbieden van VM's aan gebruikers.