Azure Stack Hub-rekencapaciteit
De vm-grootten (virtuele machines) die worden ondersteund in Azure Stack Hub, vormen een subset van de vm's die worden ondersteund in Azure. Azure legt resourcelimieten op langs veel vectoren om te voorkomen dat resources worden overgebruikt (lokaal serverniveau en serviceniveau). Zonder enkele limieten voor het verbruik van tenants op te leggen, zullen de tenantervaringen lijden wanneer andere tenants resources overconsumeeren. Voor uitgaand netwerkverkeer van de VIRTUELE machine zijn er bandbreedtelimieten aanwezig in Azure Stack Hub die overeenkomen met Azure-beperkingen. Voor opslagbronnen in Azure Stack Hub voorkomt opslag-IOPS-limieten basisgebruik van resources door tenants voor opslagtoegang.
Belangrijk
De Azure Stack Hub Capacity Planner beschouwt of garandeert geen IOPS-prestaties. 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. 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) geplaatst in een beschikbaarheidsset 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 optreedt, 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 evenwicht gebracht om hoge beschikbaarheid te behouden.
Virtuele-machineschaalsets maken gebruik van beschikbaarheidssets op de back-end en zorg ervoor dat elk exemplaar van de 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 vanwege het ontbreken van de capaciteit van vier knooppunten om drie instanties van virtuele-machineschaalsets op drie afzonderlijke Azure Stack Hub-knooppunten te plaatsen. Daarnaast kunnen Azure Stack Hub-knooppunten worden opgevuld op verschillende niveaus voordat u de plaatsing probeert uit te proberen.
Azure Stack Hub overschrijft het geheugen niet. Er is echter een overtoewijzing van het aantal fysieke kernen toegestaan.
Omdat plaatsingsalgoritmen niet kijken naar de bestaande verhouding tussen 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 vereisten op serviceniveau.
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 van 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, waarbij rekening wordt gehouden met alle overwegingen voor 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.
Notitie
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 vóór en inclusief 2002 bieden 2-5 VM's per batch met 5 minuten tussen batches betrouwbare VM-implementaties om een schaal van 700 VM's te bereiken. Met de 2005-versie van Azure Stack Hub kunnen we VM's betrouwbaar inrichten op batchgrootten van 40 met 5 minuten tussen batchimplementaties. Start, stop-de toewijzing en updatebewerkingen moeten worden uitgevoerd met een batchgrootte van 30, waardoor er 5 minuten tussen elke batch blijven.
Overweging voor GPU-VM's
Azure Stack Hub behoudt geheugen voor de infrastructuur en tenant-VM's voor failover. In tegenstelling tot andere VM's worden GPU-VM's uitgevoerd in een niet-HA-modus (hoge beschikbaarheid) en daarom geen failover. Als gevolg hiervan is gereserveerd geheugen voor een ALLEEN-GPU-VM-stempel vereist voor de infrastructuur om failover uit te voeren, in plaats van dat er ook rekening wordt gehouden met het geheugen van tenant-VM's met hoge beschikbaarheid.
Azure Stack Hub-geheugen
Azure Stack Hub is ontworpen om vm's 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 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 de plaatsing van tenant-VM's.
U kunt een cirkeldiagram bekijken in de beheerdersportal 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 de 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 wanneer we werken aan het schalen en toleranter maken van onze infrastructuurservices. Zie de Azure Stack Hub-capaciteitsplanner voor meer informatie
- Tolerantiereserve: Azure Stack Hub behoudt zich een deel van het geheugen voor om tenant-beschikbaarheid toe te staan 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' of vm's die vanuit de gast worden afgesloten, geheugen verbruiken. Vm's die de toewijzing ongedaan hebben gemaakt met behulp van de optie voor stoppen met ongedaan maken van toewijzing vanuit portal/powershell/cli verbruiken echter geen geheugen van Azure Stack Hub.
- Resourceproviders (RPS's) voor waarde-toevoegen: VM's die zijn geïmplementeerd voor de RP's voor waardetoevoeging, zoals SQL, MySQL, App Service, enzovoort.
De beste manier om inzicht te krijgen in 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 dezelfde 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 de gehele Schaaleenheid van Azure Stack Hub.
Beschikbaar geheugen voor vm-plaatsing = totale hostgeheugen - tolerantiereserve - geheugen dat wordt gebruikt door tenant-VM's uit te voeren - Overhead van Azure Stack Hub-infrastructuur 1
- Totaal aantal hostgeheugen = Som van 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 tenantworkload, is niet afhankelijk van de ha-configuratie
- Overhead van Azure Stack Hub-infrastructuur = 268 GB + (4 GB x N)
Waar:
- H = Grootte van één servergeheugen
- N = Grootte van schaaleenheid (aantal servers)
- R = De reserve van het besturingssysteem voor overhead van het besturingssysteem, wat .15 is in deze formule2
- V = Grootste HA-VM in de schaaleenheid
1 Azure Stack Hub Infrastructure overhead = 268 GB + (4 GB x # knooppunten). Er worden ongeveer 31 VM's gebruikt om de infrastructuur van Azure Stack Hub te hosten en in totaal ongeveer 268 GB + (4 GB x aantal knooppunten) van geheugen en 146 virtuele kernen te verbruiken. De logica 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 de toekomstige introductie van nieuwe infrastructuurservices mogelijk terwijl ze worden ontwikkeld.
2 Reserve van het besturingssysteem 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, de grootste HA-VM 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 (boekhouding voor 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 tolerantiereserve en ook tot de toename van het 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 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 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 verbruikt door tenantworkload, is niet afhankelijk van ha-configuratie = 0 GB
- Overhead van Azure Stack Hub-infrastructuur = 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 azure Stack Hub-infrastructuur
Beschikbaar geheugen voor VM-plaatsing = 3072 - 1370 - 0 - 284 = 1418 GB
Overwegingen voor deallocatie
Wanneer een VIRTUELE machine de toewijzingsstatus heeft, worden er geen geheugenbronnen gebruikt. Hierdoor kunnen andere VM's in het systeem worden geplaatst.
Als de toewijzing van de toewijzing van de VM vervolgens 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 VM niet gestart.
De huidige geïmplementeerde grote VM's tonen aan dat het toegewezen geheugen 112 GB is, maar dat de geheugenvraag van deze VM's ongeveer 2-3 GB is.
| Name | 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 formuletolerantiereserve = 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 kleinste VM in stempel (24 GB) wordt de tolerantiereserve 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
Als u een Azure Stack Hub-knooppunt toevoegt , wordt de toewijzing van geheugen ongedaan gemaakt door het geheugen tussen de twee knooppunten gelijkmatig te verdelen.
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 blade capaciteit wordt elke 15 minuten vernieuwd, dus neem dat in overweging.
V: Hoe zie ik de beschikbare kernen en toegewezen kernen?
A: In PowerShell-uitvoeringtest-azurestack -include AzsVmPlacement -debug, waarmee een uitvoer zoals deze 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 in mijn Azure Stack Hub is niet gewijzigd, maar mijn capaciteit fluctueert. Hoe komt dat?
A: Het beschikbare geheugen voor vm-plaatsing heeft meerdere afhankelijkheden, waarvan een de host-besturingssysteemreserve is. 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 vanuit de gast worden afgesloten in plaats van de toewijzing van de portal/powershell/cli te stoppen, 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 beschikbare geheugenrapportage op het dashboard heeft geleid tot een piek van 168 GB gebruik op de capaciteitsblade. De volgende grootte van de andere twee D5_v2 VM's naar D14_v2 leidde tot slechts 56 GB RAM-toename. 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. Aanvankelijk was de grootste VM op de stempel 56 GB geheugen. Toen de grootte 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 (56 GB tot 112 GB VM-geheugenverhoging van tenants) + 112 GB tolerantiereserve geheugenverhoging. Toen de grootte van de volgende VM's werd gewijzigd, bleef de grootste VM-grootte ongewijzigd als de VM van 112 GB en was er daarom geen toename van de tolerantiereserve. De toename van het geheugenverbruik was alleen de geheugentoename 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