Rekencapaciteit van Azure Stack Hub

De grootten van de virtuele machine (VM) die worden ondersteund in Azure Stack Hub, vormen een subset van de grootten die worden ondersteund in Azure. Azure legt resourcelimieten op langs veel vectoren om overconsumption van resources (lokaal serverniveau en serviceniveau) te voorkomen. Zonder bepaalde limieten voor tenantverbruik in te stellen, heeft de tenant te lijden wanneer andere tenants te veel resources verbruiken. Voor uitgaand netwerkverkeer van de virtuele machine zijn er limieten voor bandbreedte in Azure Stack Hub die overeenkomen met Azure-beperkingen. Voor opslagbronnen in Azure Stack Hub worden IOPS-limieten voor opslag niet beperkt tot het basisgebruik van resources door tenants voor opslagtoegang.

Belangrijk

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

VM-plaatsing

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

Azure Stack Hub maakt gebruik van twee overwegingen bij het plaatsen van VM's. Eén, 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?

Voor een hoge beschikbaarheid van een productieworkload met meerdere VM's in Azure Stack Hub worden virtuele machines (VM's) in een beschikbaarheidsset geplaatst die deze verspreidt over meerdere foutdomeinen. Een foutdomein in een beschikbaarheidsset wordt gedefinieerd als één knooppunt in de schaaleenheid. Azure Stack Hub biedt ondersteuning voor het hebben van een beschikbaarheidsset met maximaal drie foutdomeinen die consistent zijn met Azure. VM's die in een beschikbaarheidsset worden geplaatst, worden fysiek van elkaar geïsoleerd door ze zo gelijkmatig mogelijk te verspreiden over meerdere foutdomeinen (Azure Stack Hub-knooppunten). Als er een hardwarefout opgetreden is, worden VM's van het mislukte foutdomein opnieuw opgestart in andere foutdomeinen. Indien mogelijk worden ze bewaard in afzonderlijke foutdomeinen 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 zorg ervoor dat elk exemplaar van een virtuele-machineschaalset in een ander foutdomein wordt geplaatst. Dit betekent dat ze afzonderlijke Azure Stack Hub-infrastructuurknooppunten gebruiken. 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, omdat de capaciteit met vier knooppunten niet beschikbaar is om drie instanties van virtuele-machineschaalsets op drie afzonderlijke Azure Stack Hub-knooppunten te plaatsen. Bovendien kunnen Azure Stack Hub-knooppunten op verschillende niveaus worden opgevuld voordat u de plaatsing probeert uit te voeren.

Azure Stack Hub overschrijft het geheugen niet. Het is echter toegestaan om meer logische processors te gebruiken dan er fysieke kernen beschikbaar zijn.

Omdat plaatsingsalgoritmen niet kijken naar de bestaande verhouding tussen virtuele en fysieke kernen als factor, kan elke host een andere verhouding hebben. Als Microsoft geven wij geen richtlijnen voor de verhouding tussen fysieke en virtuele kernen, vanwege de variatie in workloads en vereisten voor het serviceniveau.

Rekening houden met het totale aantal VM's

Er is een limiet voor het totale aantal virtuele machines 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 wordt gemaakt met alle overwegingen met betrekking tot de rekencapaciteit, zoals de tolerantiereserve en de virtuele-naar-fysieke CPU-verhouding die een operator op de stempel wil behouden.

Als de VM-schaallimiet is bereikt, worden de volgende foutcodes geretourneerd als gevolg hiervan: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.

Opmerking

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

Overweging voor batchimplementatie van VM's

In releases tot en met 2002 werd 2-5 VM's per batch met een pauze van 5 minuten tussen batches ingezet voor betrouwbare VM-deployments om een schaal van 700 VM's te bereiken. Met de 2005-versie van Azure Stack Hub kunnen we vm's op betrouwbare wijze inrichten op batchgrootten van 40 met een tussenruimte van 5 minuten tussen batchimplementaties. Start-, stop-deallocate- en updatebewerkingen moeten worden uitgevoerd met een batchgrootte van 30, met een pauze van 5 minuten tussen elke batch.

Overweging voor GPU-VM's

Azure Stack Hub reserveert geheugen voor failover van de infrastructuur en tenant-VM's. In tegenstelling tot andere VM's draaien GPU-VM's in een niet-hoog beschikbare modus en vallen daarom niet over. Als gevolg hiervan wordt door de infrastructuur alleen het gereserveerde geheugen voor een GPU-VM-stamp vereist om failover uit te voeren, in plaats van rekening te houden met het geheugen van tenant-VM's voor hoge beschikbaarheid.

Azure Stack Hub-geheugen

Azure Stack Hub is ontworpen om virtual machines die succesvol zijn ingericht, actief te houden. 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 er 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.

Dit VM-beheer of -verplaatsing kan alleen worden bereikt als er gereserveerde geheugencapaciteit is om opnieuw opstarten of migratie 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 beheerportal waarin het beschikbare en gebruikte geheugen in Azure Stack Hub wordt weergegeven. In het volgende diagram ziet u de fysieke geheugencapaciteit op een Azure Stack Hub-schaaleenheid in Azure Stack Hub:

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

• Gebruik of reserve 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 cache voor het geheugen van Spaces Direct. 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 is besproken, maken deze VM's deel uit van het maximum van 700 VM's. Het geheugengebruik van het onderdeel infrastructuurservices kan veranderen naarmate 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 tenant-beschikbaarheid mogelijk te maken tijdens één hostfout, evenals tijdens patches en updates 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 vm's die op de infrastructuur zijn geland. Dit betekent dat VM's met de status 'Maken' of 'Mislukt' en VM's die vanuit het gastbesturingssysteem zijn afgesloten, geheugen verbruiken. Vm's waarvoor de toewijzing ongedaan is gemaakt met behulp van de optie voor stoppen met ongedaan maken van toewijzing vanuit de portal/powershell/cli, verbruiken echter geen geheugen van Azure Stack Hub.
• Waarde-toevoegende resource providers (RP's): VM's die zijn geïmplementeerd voor de waarde-toevoegende RP's zoals SQL, MySQL, App Service, enzovoort.

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

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

Beschikbaar geheugen voor vm-plaatsing = totaal hostgeheugen - tolerantiereserve - geheugen dat wordt gebruikt door tenant-VM's uit te voeren - Overhead van azure Stack Hub-infrastructuur ¹

• Totaal hostgeheugen = Som van geheugen van alle knooppunten
• Tolerantiereserve = H + R * ((N-1) * H) + V * (N-2)
• Geheugen dat wordt gebruikt door tenant-VM's = werkelijk geheugen dat wordt verbruikt door tenantworkload, is niet afhankelijk van de ha-configuratie
• Azure Stack Hub-infrastructuuroverhead = 268 GB + (4 GB x N)

Waar:

• H = Grootte van het geheugen van een enkele server
• N = Grootte van schaaleenheid (aantal servers)
• R = De reserve van het besturingssysteem voor de overhead van het besturingssysteem. Dit is .15 in deze formule²
• V = Grootste HA VM in de schaaleenheid

¹ Azure Stack Hub-infrastructuuroverhead = 268 GB + (4 GB x aantal knooppunten). Ongeveer 31 VM's worden gebruikt voor het hosten van de infrastructuur van Azure Stack Hub 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 de vereisten voor beveiliging, schaalbaarheid, onderhoud en patching. Deze interne servicestructuur maakt het mogelijk om nieuwe infrastructuurservices in de toekomst te introduceren terwijl ze worden ontwikkeld.

² Besturingssysteemreserve voor overhead = 15% (.15) aan 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 VM met hoge beschikbaarheid in de schaaleenheid, is dynamisch gebaseerd op de grootste vm-geheugengrootte van de tenant. De grootste vm-waarde voor hoge beschikbaarheid is bijvoorbeeld minimaal 12 GB (rekening houden met de infrastructuur-VM) of 112 GB of een andere ondersteunde VM-geheugengrootte in de Azure Stack Hub-oplossing. Het wijzigen van de grootste HA VM in de Azure Stack Hub-infrastructuur leidt tot een toename van de reservering voor veerkracht en de hoeveelheid geheugen van de VM zelf. Houd er rekening mee dat GPU-VM's worden uitgevoerd in de niet-HA-modus.

Voorbeeldberekening

We hebben een kleine implementatie van vier knooppunten in Azure Stack Hub 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 aantal hostgeheugen = Som van 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 = werkelijk geheugen dat wordt verbruikt door tenantworkload, is niet afhankelijk van de ha-configuratie = 0 GB
• Azure Stack Hub-infrastructuuroverhead = 268 GB + (4 GB x N) = 268 + (4 * 4) = 284 GB

Beschikbaar geheugen voor vm-plaatsing = totale hostgeheugen - tolerantiereserve - geheugen dat wordt gebruikt door tenant-VM's uit te voeren - Overhead van infrastructuur van Azure Stack Hub

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

Overwegingen voor deallocatie

Wanneer een virtuele machine in de gedealloceerde staat is, worden er geen geheugenbronnen gebruikt. Hierdoor kunnen andere VM's in het systeem worden geplaatst.

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

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

Naam	Toegewezen geheugen (GB)	Geheugenvraag (GB)	Computernaam
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

Door de grootte van de grootste virtuele machine te verkleinen tot de eerstvolgende kleinere virtuele machine binnen de cluster (24 GB), wordt de veerkrachtreserve kleiner.

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

Totaal geheugen	Infra GB	Tenant GB	Tolerantiereserve	Totaal geheugen gereserveerd	Totaal 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

Door een Azure Stack Hub-knooppunt toe te voegen wordt het geheugen ongelijk verdeeld door het 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 geheugen gereserveerd	Totaal 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 naar 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 geheugen gereserveerd	Totaal 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 bladcapaciteit wordt om de 15 minuten vernieuwd, houd daar rekening mee.

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

A: In PowerShell-uitvoeringtest-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. Waarom?

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

V: In welke status moeten tenant-VM's geheugen verbruiken?

A: Naast het uitvoeren van VM's wordt geheugen verbruikt door vm's die op de infrastructuur zijn geland. Dit betekent dat vm's met de status 'Maken' of 'Mislukt' geheugen verbruiken. VM's die van binnenuit worden afgesloten, in plaats van te worden gedealloceerd via 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. Een van de VM's is gewijzigd in 112 GB RAM (D14_v2) en de beschikbare geheugenrapportage op het dashboard heeft geleid tot een piek van 168 GB-gebruik op de capaciteitsblade. Het vergroten van de andere twee D5_v2 VM's naar D14_v2 leidde tot een verhoging van slechts 56 GB RAM. 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-zegel. In het begin had de grootste virtuele machine op de postzegel 56 GB geheugen. Toen de grootte van de virtuele machine werd gewijzigd, werd de grootste VM in de cluster 112 GB geheugen, waardoor niet alleen het geheugen dat door die VM wordt gebruikt toenam, maar ook de reservecapaciteit verhoogd. Deze wijziging heeft geresulteerd in een toename van 56 GB (56 GB tot 112 GB VM-geheugenverhoging van tenant-VM's) + 112 GB tolerantiereserve geheugenverhoging. Wanneer de grootte van volgende VM's werd gewijzigd, bleef de grootste VM-grootte ongewijzigd als de VM van 112 GB en was er dus geen toename van de tolerantiereserve. De toename van het geheugenverbruik was alleen de toename van het geheugen van de tenant-VM (56 GB).

Opmerking

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