Rekencapaciteit van Azure Stack Hub

De grootten van virtuele machines (VM's) die worden ondersteund in Azure Stack Hub, zijn een subset van de grootten die worden ondersteund in Azure. Azure legt resourcelimieten op langs verschillende vectoren om overconsumptie van resources te voorkomen (lokale server en serviceniveau). Zonder beperkingen op te leggen aan het verbruik van tenants, zullen de tenantervaringen eronder lijden wanneer andere tenants resources te veel verbruiken. Voor netwerkuitgang van de VM zijn er bandbreedtelimieten ingesteld op Azure Stack Hub die overeenkomen met azure-beperkingen. Voor opslagresources in Azure Stack Hub voorkomt U met IOPS-limieten voor opslag dat de resources door tenants te veel worden verbruikt voor opslagtoegang.

Belangrijk

De Azure Stack Hub Capacity Planner houdt geen rekening met IOPS-prestaties of garandeert deze niet. In de beheerdersportal wordt een waarschuwing weergegeven wanneer het totale geheugenverbruik van het systeem 85% heeft bereikt. Deze waarschuwing kan worden hersteld door extra capaciteit toe te voegen of door virtuele machines te verwijderen die niet meer nodig zijn.

VM-plaatsing

De plaatsingsengine van Azure Stack Hub plaatst tenant-VM's op de beschikbare hosts.

Azure Stack Hub maakt gebruik van twee overwegingen bij het plaatsen van VM's. Ten eerste, is er voldoende geheugen op de host voor dat VM-type? En twee: maken de VM's deel uit van een beschikbaarheidsset of zijn het virtuele-machineschaalsets?

Om een hoge beschikbaarheid van een productieworkload voor meerdere VM's in Azure Stack Hub te bereiken, worden virtuele machines (VM's) in een beschikbaarheidsset geplaatst die ze over meerdere foutdomeinen verspreidt. Een foutdomein in een beschikbaarheidsset wordt gedefinieerd als één knooppunt in de schaaleenheid. Azure Stack Hub ondersteunt het hebben van een beschikbaarheidsset met maximaal drie foutdomeinen om consistent te zijn met Azure. VM's die in een beschikbaarheidsset worden geplaatst, worden fysiek van elkaar geïsoleerd door ze zo gelijkmatig mogelijk te verdelen over meerdere foutdomeinen (Azure Stack Hub-knooppunten). Als er een hardwarefout optreedt, worden VM's van het foutdomein opnieuw opgestart in andere foutdomeinen. Indien mogelijk worden ze in afzonderlijke foutdomeinen bewaard van de andere VM's in dezelfde beschikbaarheidsset. Wanneer de host weer online komt, worden VM's opnieuw in balans gebracht om hoge beschikbaarheid te behouden.

Virtuele-machineschaalsets maken gebruik van beschikbaarheidssets op de back-end en zorgen ervoor dat elk exemplaar van de virtuele-machineschaalset in een ander foutdomein wordt geplaatst. Dit betekent dat ze gebruikmaken van afzonderlijke Azure Stack Hub-infrastructuurknooppunten. In een Azure Stack Hub-systeem met vier knooppunten kan er bijvoorbeeld een situatie zijn waarin een virtuele-machineschaalset van drie exemplaren mislukt bij het maken van de capaciteit met vier knooppunten om drie virtuele-machineschaalsetexemplaren op drie afzonderlijke Azure Stack Hub-knooppunten te plaatsen. Bovendien kunnen Azure Stack Hub-knooppunten op verschillende niveaus worden gevuld voordat u de plaatsing probeert uit te proberen.

Azure Stack Hub overcommitt geheugen niet. Een overtoewijzing van het aantal fysieke kernen is echter toegestaan.

Omdat plaatsingsalgoritmen niet kijken naar de bestaande verhouding tussen overprovisioning van virtuele en fysieke kernen als factor, kan elke host een andere verhouding hebben. Als Microsoft bieden we geen richtlijnen voor de verhouding tussen fysieke en virtuele kernen vanwege de variatie in workloads en serviceniveauvereisten.

Overweging voor het totale aantal VM's

Er is een limiet voor het totale aantal VM's dat kan worden gemaakt. Het maximum aantal VM's in Azure Stack Hub is 700 en 60 per schaaleenheidknooppunt. Een AZURE Stack Hub VM-limiet met acht servers is bijvoorbeeld 480 (8 * 60). Voor een Azure Stack Hub-oplossing van 12 tot 16 servers is de limiet 700. Deze limiet is gemaakt met alle overwegingen voor de rekencapaciteit, zoals de tolerantiereserve en de virtueel-fysieke CPU-verhouding die een operator op de zegel wil behouden.

Als de vm-schaallimiet is bereikt, worden de volgende foutcodes geretourneerd: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.

Notitie

Een deel van het maximum van 700 VM's is gereserveerd voor azure Stack Hub-infrastructuur-VM's. Raadpleeg de Azure Stack Hub-capaciteitsplanner voor meer informatie.

Overweging voor batchimplementatie van VM's

In releases vóór en met 2002 zorgden 2-5 VM's per batch met 5 minuten tussen batches voor betrouwbare VM-implementaties om een schaal van 700 VM's te bereiken. Met de 2005-versie van Azure Stack Hub kunnen we op betrouwbare wijze VM's inrichten met een batchgrootte van 40 met een afstand van 5 minuten tussen batchimplementaties. Bewerkingen voor starten, stoppen/ongedaan maken van toewijzing en bijwerken moeten worden uitgevoerd met een batchgrootte van 30, waarbij 5 minuten tussen elke batch overblijven.

Overweging voor GPU-VM's

Azure Stack Hub reserveert geheugen voor de infrastructuur en tenant-VM's voor failover. In tegenstelling tot andere VM's worden GPU-VM's uitgevoerd in een modus zonder hoge beschikbaarheid (hoge beschikbaarheid) en wordt daarom geen failover uitgevoerd. Als gevolg hiervan is gereserveerd geheugen voor een GPU-VM-stempel vereist voor de infrastructuur om failover uit te voeren, in tegenstelling tot de verwerking van tenant-VM-geheugen met hoge beschikbaarheid.

Azure Stack Hub-geheugen

Azure Stack Hub is ontworpen om VIRTUELE machines actief te houden die zijn ingericht. Als een host bijvoorbeeld offline is vanwege een hardwarefout, probeert Azure Stack Hub die VM opnieuw op te starten op een andere host. Een tweede voorbeeld tijdens het patchen en bijwerken van de Azure Stack Hub-software. Als een fysieke host opnieuw moet worden opgestart, wordt geprobeerd de VM's die op die host worden uitgevoerd, te verplaatsen naar een andere beschikbare host in de oplossing.

Deze VM-beheer of -verplaatsing kan alleen worden bereikt als er gereserveerde geheugencapaciteit is om het opnieuw opstarten of migreren mogelijk te maken. Een deel van het totale hostgeheugen is gereserveerd en niet beschikbaar voor plaatsing van tenant-VM's.

U kunt een cirkeldiagram bekijken in de beheerdersportal waarin het vrije en gebruikte geheugen in Azure Stack Hub wordt weergegeven. In het volgende diagram ziet u de capaciteit van het fysieke geheugen op een Azure Stack Hub-schaaleenheid in Azure Stack Hub:

Het gebruikte geheugen bestaat uit verschillende onderdelen. De volgende onderdelen verbruiken het geheugen in de sectie Gebruik van het cirkeldiagram:

• Gebruik of reservering van hostbesturingssystemen: 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 Spaces Direct-geheugencache. 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: De infrastructuur-VM's waaruit Azure Stack Hub bestaat. Zoals eerder besproken, maken deze VM's deel uit van het maximum van 700 VM's. Het geheugengebruik van het onderdeel infrastructuurservices kan veranderen als we onze infrastructuurservices schaalbaarder en toleranter maken. Zie de Azure Stack Hub-capaciteitsplanner voor meer informatie
• 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: De tenant-VM's die zijn gemaakt door Azure Stack Hub-gebruikers. 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 vanuit de gast worden afgesloten, geheugen verbruiken. VM's die zijn ongedaan gemaakt met de optie stoppen met ongedaan maken van toewijzing van de portal/powershell/cli, verbruiken echter geen geheugen van Azure Stack Hub.
• Resourceproviders (RPs) toevoegen met waarde: VM's die zijn geïmplementeerd voor de RPs met toegevoegde waarde, zoals SQL, MySQL, App Service, enzovoort.

De beste manier om het geheugenverbruik in de portal te begrijpen, is door de Azure Stack Hub Capacity Planner te gebruiken om de impact van verschillende workloads te bekijken. De volgende berekening is dezelfde berekening die door de planner wordt gebruikt.

Deze berekening resulteert in het totale beschikbare geheugen dat kan worden gebruikt voor de plaatsing van tenant-VM's. Deze geheugencapaciteit is voor het gehele Azure Stack Hub-schaaleenheid.

Beschikbaar geheugen voor VM-plaatsing = totaal hostgeheugen - tolerantiereserve - geheugen dat wordt gebruikt door het uitvoeren van tenant-VM's - Azure Stack Hub Infrastructure Overhead ¹

• Totaal hostgeheugen = som van het geheugen van alle knooppunten
• Tolerantiereserve = H + R * ((N-1) * H) + V * (N-2)
• Geheugen dat wordt gebruikt door tenant-VM's = Het werkelijke geheugen dat wordt verbruikt door de tenantworkload, is niet afhankelijk van de hoge beschikbaarheidsconfiguratie
• Overhead van Azure Stack Hub-infrastructuur = 268 GB + (4 GB x N)

Waar:

• H = grootte van geheugen van één server
• N = Grootte van schaaleenheid (aantal servers)
• R = De besturingssysteemreserve voor besturingssysteemoverhead, die in deze formule² ,15 is
• V = Grootste HA-VM in de schaaleenheid

¹ Azure Stack Hub Infrastructure-overhead = 268 GB + (4 GB x aantal knooppunten). Er worden ongeveer 31 VM's gebruikt om de infrastructuur van Azure Stack Hub te hosten en verbruiken in totaal ongeveer 268 GB + (4 GB x aantal knooppunten) geheugen en 146 virtuele kernen. De reden voor dit aantal VM's is om te voldoen aan de benodigde servicescheiding om te voldoen aan vereisten voor beveiliging, schaalbaarheid, onderhoud en patching. Deze interne servicestructuur maakt de toekomstige introductie van nieuwe infrastructuurservices mogelijk wanneer deze worden ontwikkeld.

² Reserve van besturingssysteem voor overhead = 15% (.15) knooppuntgeheugen. De reservewaarde van het besturingssysteem is een schatting en varieert op basis van de fysieke geheugencapaciteit van de server en algemene overhead van het besturingssysteem.

De waarde V, grootste HA-VM in de schaaleenheid, is dynamisch gebaseerd op de grootste tenant-VM-geheugengrootte. De grootste VM-waarde met hoge beschikbaarheid is bijvoorbeeld minimaal 12 GB (goed voor de infrastructuur-VM) of 112 GB of een andere ondersteunde VM-geheugengrootte in de Azure Stack Hub-oplossing. Het wijzigen van de grootste VM met hoge beschikbaarheid in de Azure Stack Hub-infrastructuur leidt tot een toename van de tolerantiereserve en ook tot een toename van het geheugen van de VIRTUELE machine zelf. Houd er rekening mee dat GPU-VM's worden uitgevoerd in de modus zonder hoge beschikbaarheid.

Voorbeeldberekening

We hebben een kleine Azure Stack Hub-implementatie met vier knooppunten met 768 GB RAM op elk knooppunt. We zijn van plan om een virtuele machine voor SQL Server te plaatsen met 128 GB RAM (Standard_E16_v3). Wat is het beschikbare geheugen voor vm-plaatsing?

• Totaal hostgeheugen = Som van het geheugen van alle knooppunten = 4 * 768 GB = 3072 GB
• Tolerantiereserve = H + R * ((N-1) * H) + V * (N-2) = 768 + 0,15 * ((4 - 1) * 768) + 128 * (4 - 2) = 1370 GB
• Geheugen dat wordt gebruikt door tenant-VM's = Het werkelijke geheugen dat wordt verbruikt door de tenantworkload, is niet afhankelijk van de configuratie met hoge beschikbaarheid = 0 GB
• Overhead van Azure Stack Hub-infrastructuur = 268 GB + (4 GB x N) = 268 + (4 * 4) = 284 GB

Beschikbaar geheugen voor VM-plaatsing = totaal hostgeheugen - tolerantiereserve - geheugen dat wordt gebruikt door het uitvoeren van tenant-VM's - Overhead van Azure Stack Hub-infrastructuur

Beschikbaar geheugen voor VM-plaatsing = 3072 - 1370 - 0 - 284 = 1418 GB

Overwegingen voor deallocatie

Wanneer de toewijzing van een VM ongedaan is gemaakt, worden er geen geheugenresources gebruikt. Hierdoor kunnen andere VM's in het systeem worden geplaatst.

Als de toegewezen VM vervolgens opnieuw wordt gestart, wordt het geheugengebruik of de toewijzing behandeld als een nieuwe VM die in het systeem is geplaatst en wordt het beschikbare geheugen verbruikt. Als er geen geheugen beschikbaar is, wordt de VM niet gestart.

Huidige geïmplementeerde grote VM's geven aan dat het toegewezen geheugen 112 GB is, maar de geheugenbehoefte van deze VM's is ongeveer 2-3 GB.

Naam	Toegewezen geheugen (GB)	Geheugenvraag (GB)	ComputerName
ca7ec2ea-40fd-4d41-9d9b-b11e7838d508	112	2.2392578125	LISSA01P-NODE01
10cd7b0f-68f4-40ee-9d98-b9637438ebf4	112	2.2392578125	LISSA01P-NODE01
2e403868-ff81-4abb-b087-d9625ca01d84	112	2.2392578125	LISSA01P-NODE04

Er zijn drie manieren om de toewijzing van geheugen voor VM-plaatsing ongedaan te maken met behulp van de formule Tolerantiereserve = H + R * ((N-1) * H) + V * (N-2):

• De grootte van de grootste VM verkleinen
• Het geheugen van een knooppunt vergroten
• Een knooppunt toevoegen

De grootte van de grootste VM verkleinen

Als u de grootte van de grootste VM verlaagt naar de volgende kleinste VM met stempel (24 GB), wordt de tolerantiereserve kleiner.

Tolerantiereserve = 384 + 172,8 + 48 = 604,8 GB

Totaal geheugen	Infra GB	Tenant GB	Tolerantiereserve	Totaal gereserveerd geheugen	Totaal aantal GB beschikbaar voor plaatsing
1536 GB	258 GB	329,25 GB	604,8 GB	258 + 329,25 + 604,8 = 1168 GB	~344 GB

Een knooppunt toevoegen

Als u een Azure Stack Hub-knooppunt toevoegt , wordt de toewijzing van geheugen ongedaan gemaakt door het geheugen gelijkmatig te verdelen tussen de twee knooppunten.

Tolerantiereserve = 384 + (0,15) ((5)*384) + 112 * (3) = 1008 GB

Totaal geheugen	Infra GB	Tenant GB	Tolerantiereserve	Totaal gereserveerd geheugen	Totaal aantal GB beschikbaar voor plaatsing
1536 GB	258 GB	329,25 GB	604,8 GB	258 + 329,25 + 604,8 = 1168 GB	~ 344 GB

Geheugen op elk knooppunt verhogen tot 512 GB

Door het geheugen van elk knooppunt te vergroten , wordt het totale beschikbare geheugen verhoogd.

Tolerantiereserve = 512 + 230,4 + 224 = 966,4 GB

Totaal geheugen	Infra GB	Tenant GB	Tolerantiereserve	Totaal gereserveerd geheugen	Totaal aantal GB beschikbaar voor plaatsing
2048 (4*512) GB	258 GB	505,75 GB	966,4 GB	1730,15 GB	~ 318 GB

Veelgestelde vragen

V: Mijn tenant heeft een nieuwe VM geïmplementeerd. Hoe lang duurt het voordat de capaciteitsgrafiek in de beheerdersportal de resterende capaciteit weergeeft?

A: De capaciteitsblade wordt elke 15 minuten vernieuwd, dus hier moet rekening mee worden gehouden.

V: Hoe kan ik de beschikbare kernen en toegewezen kernen zien?

A: Voer in PowerShell uit test-azurestack -include AzsVmPlacement -debug, waarmee een uitvoer als volgt wordt gegenereerd:

    Starting Test-AzureStack
    Launching AzsVmPlacement
     
    Azure Stack Scale Unit VM Placement Summary Results
     
    Cluster Node    VM Count VMs Running Physical Core Total Virtual Co Physical Memory Total Virtual Mem
    ------------    -------- ----------- ------------- ---------------- --------------- -----------------
    LNV2-Node02     20       20          28            66               256             119.5            
    LNV2-Node03     17       16          28            62               256             110              
    LNV2-Node01     11       11          28            47               256             111              
    LNV2-Node04     10       10          28            49               256             101              
    
    PASS : Azure Stack Scale Unit VM Placement Summary

V: Het aantal geïmplementeerde VM's op mijn Azure Stack Hub is niet gewijzigd, maar mijn capaciteit fluctueert. Hoe komt dat?

A: Het beschikbare geheugen voor VM-plaatsing heeft meerdere afhankelijkheden, waaronder de reserve van het host-besturingssysteem. Deze waarde is afhankelijk van het geheugen dat wordt gebruikt door de verschillende Hyper-V-processen die op de host worden uitgevoerd. Dit is geen constante waarde.

V: Welke status moeten tenant-VM's hebben om geheugen te verbruiken?

A: 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' geheugen verbruiken. VM's die worden afgesloten vanuit de gast in plaats van stoppen met ongedaan maken van toewijzing vanuit de portal/powershell/cli, verbruiken ook geheugen.

V: Ik heb een Azure Stack Hub met vier hosts. Mijn tenant heeft 3 VM's die elk 56 GB RAM (D5_v2) verbruiken. Het formaat van een van de VM's is gewijzigd in 112 GB RAM (D14_v2) en de rapportage over het beschikbare geheugen op het dashboard heeft geresulteerd in een piek van het gebruik van 168 GB op de capaciteitsblade. Het wijzigen van de grootte van de andere twee D5_v2 VM's tot D14_v2 resulteerde in een toename van slechts 56 GB RAM-geheugen. Waarom is dit zo?

A: Het beschikbare geheugen is een functie van de tolerantiereserve die wordt onderhouden door Azure Stack Hub. De tolerantiereserve is een functie van de grootste VM-grootte op de Azure Stack Hub-stempel. In eerste instantie was de grootste VM op de zegel 56 GB geheugen. Toen het formaat van de VM werd gewijzigd, werd de grootste VM op de zegel 112 GB geheugen, waardoor niet alleen het geheugen dat door die tenant-VM wordt gebruikt, is toegenomen, maar ook de tolerantiereserve verhoogd. Deze wijziging heeft geresulteerd in een toename van 56 GB (toename van 56 GB naar 112 GB geheugen van tenant-VM's) + 112 GB tolerantiereserve geheugen. Wanneer de grootte van volgende VM's werd gewijzigd, bleef de grootste VM-grootte de VM van 112 GB en was er daarom geen toename van de tolerantiereserve. De toename in geheugenverbruik was alleen de toename van het geheugen van de tenant-VM (56 GB).

Notitie

De vereisten voor capaciteitsplanning voor netwerken zijn minimaal, omdat alleen de grootte van het openbare VIP kan worden geconfigureerd. Zie Openbare IP-adressen toevoegen voor informatie over het toevoegen van meer openbare IP-adressen aan Azure Stack Hub.

Volgende stappen

Meer informatie over Azure Stack Hub-opslag