Quando prevedi di eseguire workload VM su nodi single-tenant, devi prima decidere come eseguire il deployment dei nodi single-tenant. In particolare, devi decidere quanti gruppi di nodi ti servono e quale policy di manutenzione devono utilizzare:
Gruppi di nodi: per scegliere il numero corretto di gruppi di nodi, devi valutare la disponibilità e l'utilizzo delle risorse. Sebbene un numero ridotto di gruppi di nodi ti consenta di ottimizzare l'utilizzo delle risorse e i costi, ti limita a una singola zona. Il deployment di gruppi di nodi in più zone consente di migliorare la disponibilità, ma può comportare un utilizzo inferiore delle risorse.
Policy di scalabilità automatica e manutenzione: a seconda dei requisiti di licenza dei sistemi operativi e del software che prevedi di eseguire, la scalabilità automatica dei nodi e la scelta della policy di manutenzione possono influire sul costo e sulla disponibilità delle licenze.
Per prendere la decisione giusta su come utilizzare i nodi single-tenant, devi esaminare attentamente i tuoi requisiti.
Valutazione dei requisiti
La sezione seguente elenca diversi requisiti da considerare prima di decidere quanti gruppi di nodi sono necessari e quale policy di manutenzione devono utilizzare.
BYOL e licenze per core
Se prevedi di utilizzare licenze BYOL (Bring Your Own License) su Compute Engine, i nodi single-tenant possono aiutarti a soddisfare i requisiti o i vincoli hardware imposti da queste licenze.
Alcuni software e sistemi operativi come Windows Server possono essere autorizzati per core della CPU fisica e potrebbero definire limiti alla frequenza con cui puoi modificare l'hardware sottostante delle tue macchine virtuali. La scalabilità automatica dei nodi e le policy di manutenzione predefiniti possono portare alla sostituzione dell'hardware più spesso di quanto consentito dai termini della licenza, il che può comportare costi aggiuntivi per le licenze.
Per ottimizzare per BYOL per core, considera le seguenti best practice:
Trova un equilibrio tra l'ottimizzazione del costo dell'infrastruttura e del costo delle licenze: per calcolare il costo complessivo dell'esecuzione dei workload BYOL su Compute Engine, devi considerare sia il costo dell'infrastruttura sia il costo delle licenze. In alcuni casi, minimizzare il costo dell'infrastruttura potrebbe aumentare il costo delle licenze o viceversa. Ad esempio, l'utilizzo di un tipo di nodo con un numero elevato di core potrebbe essere la soluzione migliore dal punto di vista del rapporto costo/prestazioni per determinati workload, ma potrebbe comportare un costo aggiuntivo per le licenze se le licenze sono calcolate in base al core.
Utilizza gruppi di nodi separati per i workload BYOL e non BYOL: per limitare il numero di core di cui devi acquistare la licenza, evita di combinare i workload BYOL e non BYOL in un unico gruppo di nodi e utilizza invece gruppi di nodi separati.
Se utilizzi più modelli di licenza BYOL diversi (ad esempio Windows Server Datacenter e Standard), suddividere i gruppi di nodi in base al modello di licenza può contribuire a semplificare il monitoraggio delle licenze e a ridurre il costo delle licenze.
Utilizza l'overcommit della CPU e tipi di nodi con un rapporto core/memoria elevato: i tipi di nodi si differenziano per il rapporto tra socket, core e memoria. L'utilizzo di un tipo di nodo con un rapporto core/memoria più elevato e l'attivazione dell'overcommit della CPU possono contribuire a ridurre il numero di core di cui devi acquistare la licenza.
Evita la scalabilità automatica con riduzione: la scalabilità automatica dei gruppi di nodi consente di aumentare o ridurre automaticamente un gruppo di nodi in base alla domanda attuale. L'aumento e la riduzione frequenti di un gruppo di nodi implicano che stai cambiando spesso l'hardware su cui vengono eseguite le VM.
Se cambi l'hardware più spesso di quanto ti sia consentito spostare le licenze tra macchine fisiche, queste modifiche hardware possono portare a una situazione in cui devi acquistare licenze per più core di quelli che utilizzi effettivamente.
Se esistono limiti alla frequenza con cui puoi spostarti tra macchine fisiche, puoi evitare costi eccessivi per le licenze disattivando la scalabilità automatica o configurandola in modo da fare solo lo scale out.
Non utilizzare la policy di manutenzione predefinita: la policy di manutenzione predefinita consente di ottimizzare per la disponibilità delle VM, ma può causare frequenti modifiche hardware. Per ridurre al minimo le modifiche hardware e ottimizzare il costo delle licenze, utilizza la policy di migrazione all'interno del gruppo di nodi o di riavvio in loco.
Per i workload che non richiedono licenze per core, prendi in considerazione le seguenti best practice:
- Utilizza la policy di manutenzione predefinita: se utilizzi la migrazione live, la policy di manutenzione predefinita offre una disponibilità migliore rispetto alla policy di riavvio in loco ed evita il costo aggiuntivo dell'infrastruttura della policy di migrazione all'interno della manutenzione del gruppo di nodi.
Gestione
Quando hai più di un workload o quando hai workload sia di sviluppo che di produzione che devono essere eseguiti su nodi single-tenant, considera le seguenti best practice:
Utilizza pool di nodi separati per gli ambienti di sviluppo e di produzione: l'utilizzo di pool di nodi separati ti consente di isolare gli ambienti ed evitare situazioni come le seguenti:
- Una VM di sviluppo potrebbe influire sulle prestazioni delle VM di produzione consumando eccessivamente risorse di CPU, disco o rete (disturbi dovuti alla vicinanza).
- Un workload di sviluppo potrebbe esaurire la capacità di un gruppo di nodi, impedendo la creazione di nuove VM di produzione.
Limita il numero di gruppi di nodi in ogni ambiente: se esegui più gruppi di nodi, può essere difficile utilizzare completamente ogni gruppo di nodi. Per ottimizzare l'utilizzo, combina i workload di ogni ambiente e pianificali su un piccolo numero di gruppi di nodi.
Utilizza progetti dedicati per la gestione dei gruppi di nodi: per ogni ambiente, crea un progetto dedicato per gestire i gruppi di nodi. Poi condividi i gruppi di nodi con i progetti che contengono i workload.
Questo approccio ti consente di semplificare il controllo dell'accesso utilizzando un progetto distinto per ogni workload, nonché di ottimizzare l'utilizzo delle risorse condividendo i gruppi di nodi tra i workload.
Condividi gruppi di nodi con singoli progetti: anziché condividere un gruppo di nodi con un'intera organizzazione, condividilo solo con singoli progetti. La selezione dei progetti singolarmente ti aiuta a mantenere una separazione tra gli ambienti ed evita di divulgare informazioni sui gruppi di nodi ad altri progetti.
Stabilisci una procedura per l'attribuzione dei costi interni: il costo per l'esecuzione di un gruppo di nodi viene sostenuto nel progetto che lo contiene. Se devi attribuire questo costo a singoli progetti o workload, ti consigliamo di monitorare l'utilizzo delle VM single-tenant e di utilizzare questi dati per eseguire l'attribuzione dei costi interni.
Disponibilità
I workload potrebbero differire nei requisiti di disponibilità e nell'eventuale possibilità di ottenere un'alta affidabilità a livello di applicazione o se deve essere implementata a livello di infrastruttura:
Applicazioni in cluster: alcuni dei tuoi workload potrebbero implementare l'alta affidabilità nell'applicazione utilizzando tecniche di clustering come la replica e il bilanciamento del carico.
Alcuni esempi di questi workload sono i domain controller Active Directory, le istanze e i gruppi di disponibilità del cluster di failover di SQL Server o le applicazioni bilanciate in cluster in esecuzione in IIS.
In genere, le applicazioni in cluster possono sopportare interruzioni di singole VM purché la maggior parte delle VM rimanga disponibile.
Applicazioni non in cluster: alcuni dei tuoi workload potrebbero non implementare alcuna funzionalità di clustering e richiedere invece che la VM stessa debba essere mantenuta disponibile.
Alcuni esempi di questi tipi di workload sono i server di database non replicati o i server di applicazioni stateful.
Per ottimizzare la disponibilità delle singole VM, devi assicurarti che sia possibile eseguire la migrazione live della VM in caso di un prossimo evento di manutenzione del nodo.
La migrazione live è supportata dalla policy di manutenzione predefinita e dalla policy di manutenzione Esegui la migrazione all'interno del gruppo di nodi, ma non è supportata se utilizzi la policy di manutenzione Riavvia in loco.
Applicazioni non critiche: i workload batch, i workload di sviluppo/test e altri workload con priorità inferiore potrebbero non avere requisiti di disponibilità particolari. Per questi workload, potrebbe essere accettabile che singole VM non siano disponibili durante la manutenzione del nodo.
Per soddisfare i requisiti di disponibilità dei tuoi workload, prendi in considerazione le seguenti best practice:
Utilizza i gruppi di nodi in zone o regioni diverse per eseguire il deployment di workload in cluster: i nodi e i gruppi di nodi di proprietà esclusiva sono una risorsa di zona. Per proteggerti dalle interruzioni di servizio a livello di zona, esegui il deployment di più gruppi di nodi in zone o regioni diverse. Utilizza l'affinità dei nodi per pianificare le VM in modo che ogni istanza dell'applicazione cluster venga eseguita su un nodo diverso in una zona o una regione diversa.
Se due o più gruppi di nodi utilizzano la policy di manutenzione predefinita o Riavvia in loco, configura le finestre di manutenzione in modo che non si sovrappongano.
Se più istanze delle tue applicazioni in cluster devono essere eseguite in un'unica zona, utilizza l'anti-affinità per assicurarti che le istanze VM siano pianificate su nodi o gruppi di nodi diversi.
Evita la policy manutenzione di riavvio in loco per i workload non in cluster che richiedono un'alta affidabilità: poiché la policy di manutenzione di Riavvia in loco arresta le VM quando il nodo sottostante richiede manutenzione, preferisci utilizzare una policy di manutenzione diversa per i gruppi di nodi che eseguono workload non clusterizzati che richiedono un'alta disponibilità.
Utilizza i gruppi di istanze gestite per aumentare la resilienza e la disponibilità dei workload: puoi aumentare ulteriormente la resilienza e la disponibilità del tuo deployment utilizzando i gruppi di istanze gestite per monitorare l'integrità dei tuoi workload e ricreare automaticamente le istanze VM, se necessario. Puoi utilizzare i gruppi di istanze gestite sia per i workload stateless sia per quelli stateful.
Prestazioni
La sensibilità ai cambiamenti delle prestazioni potrebbe variare in base ai workload. Per alcune applicazioni interne o workload di test, l'ottimizzazione dei costi potrebbe essere più importante dell'assicurarsi prestazioni costanti per tutto il giorno. Per altri workload, come le applicazioni rivolte all'esterno, le prestazioni potrebbero essere critiche e più importanti dell'utilizzo delle risorse.
Per utilizzare al meglio i tuoi nodi single-tenant, tieni a mente le seguenti best practice:
Utilizza gruppi di nodi dedicati e overcommit della CPU per i workload non sensibili prestazioni: l'overcommit della CPU consente di aumentare la densità delle VM sui nodi single-tenant e può contribuire a ridurre il numero di nodi single-tenant richiesti.
Per utilizzare l'overcommit della CPU, devi utilizzare un tipo di nodo che supporta l'overcommit della CPU. L'attivazione dell'overcommit della CPU per un gruppo di nodi comporta costi aggiuntivi per nodo single-tenant.
L'overcommit della CPU può essere più conveniente se utilizzi un gruppo di nodi dedicato per i workload adatti all'overcommit della CPU e lo attivi solo per questo gruppo di nodi. Lascia disattivato l'overcommit della CPU per i gruppi di nodi che devono eseguire workload sensibili alle prestazioni.
Utilizza un tipo di nodo con un rapporto core:memoria elevato per l'overcommit della CPU: sebbene l'overcommit della CPU ti consenta di condividere i core tra le VM, non ti consente di condividere la memoria tra le VM. L'utilizzo di un tipo di nodo con una memoria relativamente maggiore per core della CPU ti consente di assicurarti che la memoria non diventi un fattore limitante.
- Utilizza la scalabilità automatica dei nodi per i workload sensibili alle prestazioni: per soddisfare le esigenze di risorse variabili per i workload sensibili alle prestazioni, configura il gruppo di nodi in modo da utilizzare la scalabilità automatica.
Pattern di deployment
Il modo migliore per utilizzare i nodi single-tenant dipende dai tuoi requisiti individuali. La sezione seguente descrive una selezione di pattern che puoi utilizzare come punto di partenza per ricavare un'architettura adatta alle tue esigenze specifiche.
Più gruppi di nodi per requisiti di prestazioni misti
Se hai una combinazione di workload sensibili alle prestazioni (ad esempio applicazioni rivolte ai clienti) e non sensibili alle prestazioni (ad esempio applicazioni interne), puoi utilizzare più gruppi di nodi che utilizzano tipi di nodi diversi:
- Un gruppo di nodi utilizza l'overcommit della CPU e un tipo di nodo con un rapporto vCPU:memoria di 1:8. Questo gruppo di nodi viene utilizzato per i workload non sensibili alle prestazioni.
- Un secondo gruppo di nodi utilizza un tipo di nodo ottimizzato per il calcolo con un rapporto vCPU:memoria di 1:4 senza overcommit della CPU. Questo gruppo di nodi viene utilizzato per i workload critici per le prestazioni e viene configurato per fare lo scale up e lo scale down in base alla domanda.
Alta affidabilità multizona per i workload in cluster con licenza per core
Se esegui workload in cluster che utilizzano licenze per core e devi minimizzare le modifiche hardware, puoi trovare un equilibrio tra disponibilità e overhead delle licenze utilizzando più gruppi di nodi con finestre di manutenzione non sovrapposte:
- Il deployment di più gruppi di nodi viene eseguito in diverse zone o regioni.
- Tutti i gruppi di nodi utilizzano la policy di manutenzione Riavvia. I gruppi di nodi utilizzano finestre di manutenzione non sovrapposte in modo che non più di un gruppo di nodi debba subire interruzioni legate alla manutenzione contemporaneamente.
- Le istanze VM che eseguono workload in cluster utilizzano le etichette di affinità in modo che ogni nodo del cluster venga pianificato in un gruppo di nodi in una zona diversa.
Alta affidabilità multizona per i workload misti con licenza per core
Se utilizzi licenze per core, ma non tutti i tuoi workload sono raggruppati in cluster, puoi estendere il pattern precedente utilizzando policy di manutenzione eterogenee:
- Il gruppo di nodi principale viene implementato nella zona
aed esegue workload sia in cluster che non in cluster. Per ridurre al minimo le interruzioni causate dalla manutenzione dell'hardware, il gruppo di nodi utilizza la policy di manutenzione Esegui la migrazione all'interno del gruppo di nodi. - Per uno o più gruppi di nodi secondari viene eseguito il deployment in altre zone o regioni. Questi gruppi di nodi utilizzano la policy di manutenzione Riavvia, ma utilizzano periodi di manutenzione non sovrapposti.
- Le istanze VM che eseguono workload in cluster utilizzano le etichette di affinità in modo che ogni nodo del cluster venga pianificato in un gruppo di nodi in una zona diversa.
- Le istanze VM che eseguono workload non in cluster utilizzano le etichette di affinità in modo che il loro deployment venga eseguito nel gruppo di nodi principale.
Se pianifichi i workload raggruppati solo nei gruppi di nodi secondari, puoi assicurarti che le interruzioni temporanee causate dalla policy di manutenzione Riavvia abbiano un impatto minimo sulla disponibilità complessiva. Allo stesso tempo, limiti il sovraccarico delle licenze e dell'infrastruttura utilizzando la policy di manutenzione Esegui la migrazione all'interno del gruppo di nodi solo per il gruppo di nodi principale.
Passaggi successivi
- Scopri di più sui nodi single-tenant.
- Scopri come utilizzare le licenze Bring Your Own License.