Capacità di calcolo dell'hub di Azure Stack

Le dimensioni della macchina virtuale supportate nell'hub di Azure Stack sono un subset di quelle supportate in Azure. Azure impone limiti di risorse per diversi vettori per evitare un consumo eccessivo di risorse (locali del server e a livello di servizio). Senza imporre alcun limite all'utilizzo dei tenant, le esperienze dei tenant ne risentono quando altri tenant consumano una quantità eccessiva di risorse. Per l'uscita di rete dalla macchina virtuale, sono previsti limiti di larghezza di banda nell'hub di Azure Stack che corrispondono alle limitazioni di Azure. Per le risorse di archiviazione nell'hub di Azure Stack, i limiti per le operazioni di I/O al secondo di archiviazione evitano il consumo eccessivo delle risorse da parte dei tenant per l'accesso alle risorse di archiviazione.

Importante

Capacity Planner dell'hub di Azure Stack non considera o garantisce prestazioni di I/O al secondo. Il portale di amministrazione visualizza un avviso quando il consumo totale di memoria di sistema ha raggiunto l'85%. Questo avviso può essere corretto aggiungendo capacità aggiuntiva o rimuovendo macchine virtuali non più necessarie.

Selezione host per le macchine virtuali

Il motore di posizionamento dell'hub di Azure Stack inserisce le macchine virtuali tenant negli host disponibili.

L'hub di Azure Stack usa due considerazioni per l'inserimento di macchine virtuali. Uno è disponibile memoria sufficiente nell'host per quel tipo di macchina virtuale? E due, le macchine virtuali fanno parte di un set di disponibilità o sono set di scalabilità di macchine virtuali?

Per ottenere la disponibilità elevata di un carico di lavoro di produzione con più macchine virtuali nell'hub di Azure Stack, le macchine virtuali vengono inserite in un set di disponibilità che li distribuisce tra più domini di errore. Un dominio di errore in un set di disponibilità è definito come un singolo nodo nell'unità di scala. L'hub di Azure Stack supporta l'uso di un set di disponibilità con un massimo di tre domini di errore, per assicurare la coerenza con Azure. Le macchine virtuali inserite in un set di disponibilità saranno fisicamente isolate l'una dall'altra distribuendole il più uniformemente possibile su più domini di errore (nodi dell'hub di Azure Stack). Se si verifica un errore hardware, le macchine virtuali dal dominio di errore non riuscito verranno riavviate in altri domini di errore. Se possibile, verranno mantenuti in domini di errore separati dalle altre macchine virtuali nello stesso set di disponibilità. Quando l'host torna online, le macchine virtuali verranno ribilanciate per mantenere la disponibilità elevata.

I set di scalabilità di macchine virtuali usano set di disponibilità nel back-end e assicurano che ogni istanza del set di scalabilità di macchine virtuali venga posizionata in un dominio di errore diverso. Questo significa che vengono usati nodi dell'infrastruttura dell'hub di Azure Stack distinti. In un sistema hub di Azure Stack a quattro nodi, ad esempio, può verificarsi una situazione in cui la creazione di un set di scalabilità di macchine virtuali di tre istanze ha esito negativo a causa della mancanza di capacità dei quattro nodi per posizionare le tre istanze del set di scalabilità di macchine virtuali in tre nodi dell'hub di Azure Stack separati. I nodi dell'hub di Azure Stack possono inoltre essere riempiti a diversi livelli prima di provare a eseguire la selezione host.

L'hub di Azure Stack non esegue l'overcommit della memoria. Tuttavia, è consentito un overcommit del numero di core fisici.

Poiché gli algoritmi di posizionamento non esaminano il rapporto di overprovisioning tra core fisici e virtuali esistente come fattore, ogni host potrebbe avere un rapporto diverso. Microsoft non fornisce indicazioni sul rapporto tra core fisici e virtuali a causa della variazione dei carichi di lavoro e dei requisiti del livello di servizio.

Considerazione per il numero totale di macchine virtuali

Esiste un limite per il numero totale di macchine virtuali che è possibile creare. Il numero massimo di macchine virtuali nell'hub di Azure Stack è 700 e 60 per ogni nodo di unità di scala. Ad esempio, un limite di 8 server della macchina virtuale dell'hub di Azure Stack sarà 480 (8 * 60). Per una soluzione hub di Azure Stack da 12 a 16 server, il limite sarà 700. Questo limite è stato creato tenendo presenti tutte le considerazioni relative alla capacità di calcolo, ad esempio la riserva per la resilienza e il rapporto tra CPU virtuali e fisiche che un operatore vuole mantenere nello stamp.

Se viene raggiunto il limite di scalabilità di macchine virtuali, vengono restituiti i codici di errore seguenti: VMsPerScaleUnitLimitExceeded, VMsPerScaleUnitNodeLimitExceeded.

Nota

Una parte del massimo di 700 vm è riservata per le macchine virtuali dell'infrastruttura dell'hub di Azure Stack. Per altre informazioni, vedere Capacity Planner dell'hub di Azure Stack.

Considerazione per la distribuzione batch di macchine virtuali

Nelle versioni precedenti e incluse la versione 2002, 2-5 macchine virtuali per batch con 5 minuti di gap tra batch e distribuzioni di macchine virtuali affidabili per raggiungere una scala di 700 macchine virtuali. Con la versione 2005 dell'hub di Azure Stack in poi, è possibile effettuare il provisioning affidabile delle macchine virtuali con dimensioni batch di 40 con 5 minuti di distanza tra le distribuzioni batch. Le operazioni di avvio, deallocazione e aggiornamento devono essere eseguite con dimensioni batch di 30, lasciando 5 minuti tra ogni batch.

Considerazione per le macchine virtuali GPU

L'hub di Azure Stack riserva memoria per l'infrastruttura e le macchine virtuali tenant per il failover. A differenza di altre macchine virtuali, le macchine virtuali GPU vengono eseguite in modalità non a disponibilità elevata (disponibilità elevata) e pertanto non eseguono il failover. Di conseguenza, la memoria riservata per un timbro di sola macchina virtuale GPU è ciò che è richiesto dall'infrastruttura per il failover, invece di tenere conto anche della memoria della macchina virtuale tenant a disponibilità elevata.

Memoria dell'hub di Azure Stack

L'hub di Azure Stack è progettato per mantenere in esecuzione le macchine virtuali di cui è stato eseguito correttamente il provisioning. Ad esempio, se un host è offline a causa di un errore hardware, l'hub di Azure Stack tenterà di riavviare la macchina virtuale in un altro host. Un secondo esempio riguarda l'applicazione di patch e l'aggiornamento del software dell'hub di Azure Stack. Se è necessario riavviare un host fisico, viene effettuato un tentativo di spostare le macchine virtuali in esecuzione in tale host in un altro host disponibile nella soluzione.

Questa gestione o spostamento delle macchine virtuali può essere eseguita solo se è presente capacità di memoria riservata per consentire il riavvio o la migrazione. Una parte della memoria totale dell'host è riservata e non disponibile per il posizionamento della macchina virtuale tenant.

È possibile esaminare un grafico a torta nel portale di amministrazione che mostra la memoria libera e quella in uso nell'hub di Azure Stack. Il diagramma seguente mostra la capacità di memoria fisica in un'unità di scala dell'hub di Azure Stack nell'hub di Azure Stack:

La memoria usata è costituita da diversi componenti. I componenti seguenti utilizzano la memoria nella sezione del grafico a torta che indica la quantità un uso:

• Utilizzo o riserva del sistema operativo host: Memoria usata dal sistema operativo nell'host, nelle tabelle delle pagine di memoria virtuale, nei processi in esecuzione nel sistema operativo host e nella cache di memoria diretta di Spaces. Poiché questo valore dipende dalla memoria usata dai diversi processi Hyper-V in esecuzione nell'host, può variare.
• Servizi di infrastruttura: Macchine virtuali dell'infrastruttura che costituiscono l'hub di Azure Stack. Come illustrato in precedenza, queste macchine virtuali fanno parte del massimo di 700 macchine virtuali. L'utilizzo della memoria del componente dei servizi di infrastruttura può cambiare man mano che si rendono i servizi di infrastruttura più scalabili e resilienti. Per altre informazioni, vedere Capacity Planner dell'hub di Azure Stack
• Riserva di resilienza: L'hub di Azure Stack riserva una parte della memoria per consentire la disponibilità del tenant durante un singolo errore dell'host, nonché durante la patch e l'aggiornamento per consentire la corretta migrazione in tempo reale delle macchine virtuali.
• Macchine virtuali tenant: Macchine virtuali tenant create dagli utenti dell'hub di Azure Stack. Oltre all'esecuzione di macchine virtuali, la memoria viene utilizzata da tutte le macchine virtuali che hanno eseguito l'infrastruttura. Ciò significa che le macchine virtuali nello stato "Creazione" o "Non riuscito" o le macchine virtuali arrestate dall'interno del guest utilizzeranno memoria. Tuttavia, le macchine virtuali deallocate che usano l'opzione arresta deallocata dal portale/powershell/interfaccia della riga di comando non utilizzerà la memoria dall'hub di Azure Stack.
• Provider di risorse con aggiunta di valore (RP): Macchine virtuali distribuite per i provider di servizi di aggiunta di valore, ad esempio SQL, MySQL, servizio app e così via.

Il modo migliore per comprendere l'utilizzo della memoria nel portale consiste nell'usare Azure Stack Hub Capacity Planner per visualizzare l'impatto di diversi carichi di lavoro. Il calcolo illustrato di seguito è lo stesso usato dallo strumento di pianificazione.

Questo calcolo restituisce la memoria totale disponibile che può essere usata per il posizionamento della macchina virtuale tenant. La capacità di memoria si riferisce all'intera unità di scala dell'hub di Azure Stack.

Memoria disponibile per il posizionamento della macchina virtuale = memoria host totale - riserva di resilienza - Memoria usata dalle macchine virtuali tenant in esecuzione - Sovraccarico dell'infrastruttura dell'hub di Azure Stack ¹

• Memoria host totale = Somma della memoria da tutti i nodi
• Riserva per la resilienza = H + R * ((N-1) * H) + V * (N-2)
• La memoria usata dalle macchine virtuali tenant = Memoria effettiva utilizzata dal carico di lavoro del tenant, non dipende dalla configurazione a disponibilità elevata
• Sovraccarico dell'infrastruttura dell'hub di Azure Stack = 268 GB + (4 GB x N)

Dove:

• H = Dimensioni della memoria a server singolo
• N = Dimensione dell'unità di scala (numero di server)
• R = Riserva del sistema operativo per il sovraccarico del sistema operativo (in questa formula, 0,15)²
• V = Macchina virtuale a disponibilità elevata più grande nell'unità di scala

¹ Overhead dell'infrastruttura dell'hub di Azure Stack = 268 GB + (4 GB x numero di nodi). Circa 31 macchine virtuali vengono usate per ospitare l'infrastruttura dell'hub di Azure Stack e, in totale, utilizzano circa 268 GB + (4 GB x numero di nodi) di memoria e 146 core virtuali. Il motivo per questo numero di macchine virtuali è soddisfare la separazione dei servizi necessaria per soddisfare i requisiti di sicurezza, scalabilità, manutenzione e applicazione di patch. Questa struttura dei servizi interna consente l'introduzione futura di nuovi servizi di infrastruttura, man mano che vengono sviluppati.

² Riserva del sistema operativo per il sovraccarico = 15% (0,15) della memoria dei nodi. Il valore di riserva del sistema operativo è una stima e varia in base alla capacità di memoria fisica del server e al sovraccarico generale del sistema operativo.

Il valore V, la macchina virtuale a disponibilità elevata più grande nell'unità di scala, è dinamicamente basata sulle dimensioni di memoria della macchina virtuale tenant più grandi. Ad esempio, il valore massimo della macchina virtuale a disponibilità elevata è un minimo di 12 GB (tenendo conto della macchina virtuale dell'infrastruttura) o 112 GB o qualsiasi altra dimensione di memoria di macchina virtuale supportata nella soluzione hub di Azure Stack. La modifica della macchina virtuale a disponibilità elevata più grande nell'infrastruttura dell'hub di Azure Stack comporterà un aumento della resilienza e anche l'aumento della memoria della macchina virtuale stessa. Tenere presente che le macchine virtuali GPU vengono eseguite in modalità non a disponibilità elevata.

Calcolo di esempio

È disponibile una piccola distribuzione dell'hub di Azure Stack a quattro nodi con 768 GB di RAM in ogni nodo. Si prevede di inserire una macchina virtuale per SQL Server con 128 GB di RAM (Standard_E16_v3). Quale sarà la memoria disponibile per il posizionamento della macchina virtuale?

• Memoria host totale = Somma della memoria da tutti i nodi = 4 * 768 GB = 3072 GB
• Riserva di resilienza = H + R * ((N-1) * V * (N-2) = 768 + 0,15 * ((4 - 1) * 768) + 128 * (4 - 2) = 1370 GB
• Memoria usata dalle macchine virtuali tenant = Memoria effettiva utilizzata dal carico di lavoro del tenant, non dipende dalla configurazione di disponibilità elevata = 0 GB
• Sovraccarico dell'infrastruttura dell'hub di Azure Stack = 268 GB + (4 GB x N) = 268 + (4 * 4) = 284 GB

Memoria disponibile per il posizionamento della macchina virtuale = memoria host totale - riserva di resilienza - Memoria usata dall'esecuzione di macchine virtuali tenant - Sovraccarico dell'infrastruttura dell'hub di Azure Stack

Memoria disponibile per il posizionamento della macchina virtuale = 3072 - 1370 - 0 - 284 = 1418 GB

Considerazioni sulla deallocazione

Quando una macchina virtuale si trova nello stato deallocato , le risorse di memoria non vengono usate. Ciò consente ad altre macchine virtuali di essere inserite nel sistema.

Se la macchina virtuale deallocata viene avviata di nuovo, l'utilizzo della memoria o l'allocazione viene considerato come una nuova macchina virtuale inserita nel sistema e la memoria disponibile viene utilizzata. Se non è disponibile memoria, la macchina virtuale non verrà avviata.

Le macchine virtuali di grandi dimensioni distribuite corrente mostrano che la memoria allocata è di 112 GB, ma la domanda di memoria di queste macchine virtuali è di circa 2-3 GB.

Nome	Memoria assegnata (GB)	Domanda di memoria (GB)	NomeComputer
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

Esistono tre modi per deallocare la memoria per il posizionamento della macchina virtuale usando la riserva di resilienza della formula = H + R * (N-1) * H) + V * (N-2):

• Ridurre le dimensioni della macchina virtuale più grande
• Aumentare la memoria di un nodo
• Aggiungere un nodo

Ridurre le dimensioni della macchina virtuale più grande

La riduzione delle dimensioni della macchina virtuale più grande alla macchina virtuale più piccola nel timbro (24 GB) ridurrà le dimensioni della riserva di resilienza.

Riserva di resilienza = 384 + 172,8 + 48 = 604,8 GB

Memoria totale	Infra GB	Tenant GB	Riserva di resilienza	Totale memoria riservata	Totale GB disponibile per il posizionamento
1536 GB	258 GB	329,25 GB	604,8 GB	258 + 329.25 + 604.8 = 1168 GB	~344 GB

Aggiungere un nodo

L'aggiunta di un nodo dell'hub di Azure Stack deallocate la memoria distribuendo equamente la memoria tra i due nodi.

Riserva di resilienza = 384 + (0,15) ((5)*384) + 112 * (3) = 1008 GB

Memoria totale	Infra GB	Tenant GB	Riserva di resilienza	Totale memoria riservata	Totale GB disponibile per il posizionamento
1536 GB	258 GB	329,25 GB	604,8 GB	258 + 329.25 + 604.8 = 1168 GB	~ 344 GB

Aumentare la memoria in ogni nodo a 512 GB

L'aumento della memoria di ogni nodo aumenterà la memoria totale disponibile.

Riserva di resilienza = 512 + 230,4 + 224 = 966,4 GB

Memoria totale	Infra GB	Tenant GB	Riserva di resilienza	Totale memoria riservata	Totale GB disponibile per il posizionamento
2048 (4*512) GB	258 GB	505,75 GB	966,4 GB	1730,15 GB	~ 318 GB

Domande frequenti

D: Il tenant ha distribuito una nuova macchina virtuale, quanto tempo richiederà il grafico delle funzionalità nel portale di amministrazione per mostrare la capacità rimanente?

R: il pannello della capacità viene aggiornato ogni 15 minuti, quindi prendere in considerazione questo aspetto.

D: Come è possibile visualizzare i core e i core assegnati disponibili?

R: In PowerShell eseguire test-azurestack -include AzsVmPlacement -debug, che genera un output simile al seguente:

    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

D: il numero di macchine virtuali distribuite nell'hub di Azure Stack non è cambiato, ma la capacità è fluttuante. Perché?

R: la memoria disponibile per il posizionamento della macchina virtuale ha più dipendenze, una delle quali è la riserva del sistema operativo host. Questo valore dipende dalla memoria usata dai diversi processi Hyper-V in esecuzione nell'host, che non è un valore costante.

D: Qual è lo stato che devono essere presenti le macchine virtuali tenant per l'utilizzo della memoria?

R: oltre all'esecuzione di macchine virtuali, la memoria viene usata da tutte le macchine virtuali che hanno eseguito l'accesso all'infrastruttura. Ciò significa che le macchine virtuali in uno stato "Creazione" o "Non riuscito" usano la memoria. Le macchine virtuali si arresteranno dall'interno del guest anziché interrompere la deallocazione dal portale/powershell/cli utilizzeranno anche la memoria.

D: È disponibile un hub azure Stack a quattro host. Il tenant ha 3 macchine virtuali che utilizzano 56 GB di RAM (D5_v2). Una delle macchine virtuali viene ridimensionata a 112 GB di RAM (D14_v2) e la creazione di report sulla memoria disponibile nel dashboard ha generato un picco di utilizzo di 168 GB nel pannello della capacità. Il ridimensionamento successivo delle altre due macchine virtuali D5_v2 per D14_v2 ha generato un aumento di 56 GB di RAM. Perché è così?

R: la memoria disponibile è una funzione della riserva di resilienza gestita dall'hub di Azure Stack. La riserva di resilienza è una funzione delle dimensioni più grandi della macchina virtuale nel timbro dell'hub di Azure Stack. In primo luogo, la macchina virtuale più grande nel timbro era 56 GB di memoria. Quando la macchina virtuale è stata ridimensionata, la macchina virtuale più grande nel stamp è diventata 112 GB di memoria che non solo ha aumentato la memoria usata dalla macchina virtuale tenant, ma ha anche aumentato la riserva di resilienza. Questa modifica ha causato un aumento di 56 GB (aumento della memoria della memoria della macchina virtuale tenant da 56 GB a 112 GB) + 112 GB di memoria di riserva di memoria. Quando le macchine virtuali successive sono state ridimensionate, le dimensioni delle macchine virtuali più grandi sono state mantenute come macchina virtuale da 112 GB e pertanto non sono state aumentate le riserve di resilienza risultanti. L'aumento del consumo di memoria era solo l'aumento della memoria della macchina virtuale tenant (56 GB).

Nota

I requisiti di pianificazione della capacità per la rete sono minimi perché solo le dimensioni dell'indirizzo VIP pubblico sono configurabili. Per informazioni su come aggiungere altri indirizzi IP pubblici all'hub di Azure Stack, vedere Aggiungere indirizzi IP pubblici.

Passaggi successivi

Informazioni sull'archiviazione dell'hub di Azure Stack