Quando prevedi di eseguire carichi di lavoro 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 criterio 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.
Criteri 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 del criterio 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 criterio 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 cambiare l'hardware sottostante delle tue macchine virtuali. La scalabilità automatica dei nodi e i criteri di manutenzione predefiniti possono portare alla sostituzione dell'hardware più spesso di quanto consentito dai termini della licenza, il che può comportare l'addebito di commissioni aggiuntive 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 carichi di lavoro 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 carichi di lavoro, 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 mescolare 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 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 la sperimentazione 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 per eseguire solo il scale out.
Non utilizzare il criterio di manutenzione predefinito: il criterio di manutenzione predefinito consente di ottimizzare per la disponibilità delle VM, ma può causare frequenti modifiche hardware. Per ridurre al minimo le modifiche hardware e ottimizzare in base al costo delle licenze, utilizza il criterio di migrazione all'interno del gruppo di nodi o di riavvio in loco.
Per i carichi di lavoro che non richiedono licenze per core, prendi in considerazione le seguenti best practice:
- Utilizza il criterio di manutenzione predefinito: se utilizzi la migrazione live, il criterio di manutenzione predefinito offre una disponibilità migliore rispetto al criterio di riavvio in situ e consente di evitare il costo aggiuntivo dell'infrastruttura del criterio di migrazione all'interno della manutenzione del gruppo di nodi.
Gestione
Quando hai più di un carico di lavoro o quando hai carichi di lavoro 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 e 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 ("vicino rumoroso").
- Un carico di lavoro 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 carichi di lavoro di ogni ambiente e pianificali su un numero ridotto 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 carichi di lavoro.
Questo approccio ti consente di semplificare controllo dell'accesso#39;accesso utilizzando un progetto distinto per ogni carico di lavoro, nonché di ottimizzare l'utilizzo delle risorse condividendo i gruppi di nodi tra i carichi di lavoro.
Condividi i 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 carichi di lavoro, ti consigliamo di monitorare l'utilizzo delle VM sole-tenant e di utilizzare questi dati per eseguire l'attribuzione dei costi interni.
Disponibilità
I carichi di lavoro potrebbero differire nei requisiti di disponibilità e se è possibile ottenere un'alta disponibilità a livello di livello di applicazione o se deve essere implementata a livello di infrastruttura:
Applicazioni in cluster: alcuni dei tuoi carichi di lavoro potrebbero implementare l'alta disponibilità nell'applicazione utilizzando tecniche di clustering come la replica e il bilanciamento del carico.
Alcuni esempi di questi carichi di lavoro sono i controller di dominio 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 carichi di lavoro 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 dal criterio di manutenzione predefinito e dal criterio di manutenzione Esegui la migrazione all'interno del gruppo di nodi, ma non è supportata se utilizzi il criterio di manutenzione Riavvia in loco.
Applicazioni non critiche: i carichi di lavoro batch, i carichi di lavoro di sviluppo/test e altri carichi di lavoro con priorità inferiore potrebbero non avere requisiti di disponibilità particolari. Per questi carichi di lavoro, potrebbe essere accettabile che singole VM non siano disponibili durante la manutenzione del nodo.
Per soddisfare i requisiti di disponibilità dei tuoi carichi di lavoro, prendi in considerazione le seguenti best practice:
Utilizza i gruppi di nodi in zone o regioni diverse per eseguire il deployment di carichi di lavoro clusterizzati: 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 il criterio di manutenzione predefinito o Riavvia in situ, 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 il criterio di manutenzione di riavvio in situ per i carichi di lavoro non clusterizzati che richiedono un'alta disponibilità: poiché il criterio di manutenzione di riavvio in situ arresta le VM quando il nodo sottostante richiede manutenzione, preferisci utilizzare un criterio di manutenzione diverso per i gruppi di nodi che eseguono carichi di lavoro 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 carichi di lavoro stateless sia per quelli stateful.
Prestazioni
La sensibilità ai cambiamenti delle prestazioni potrebbe variare in base ai carichi di lavoro. Per alcune applicazioni interne o carichi di lavoro di test, l'ottimizzazione dei costi potrebbe essere più importante dell'assicurarsi prestazioni costanti per tutto il giorno. Per altri carichi di lavoro, come le applicazioni rivolte all'esterno, il rendimento potrebbe essere critico e più importante dell'utilizzo delle risorse.
Per utilizzare al meglio i tuoi nodi monoproprietario, tieni a mente le seguenti best practice:
Utilizza gruppi di nodi dedicati e overcommit della CPU per i carichi di lavoro insensibili alle 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 carichi di lavoro 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 carichi di lavoro 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 più memoria per core della CPU consente di assicurarti che la memoria non diventi un fattore limitante.
- Utilizza la scalabilità automatica dei nodi per i carichi di lavoro sensibili al rendimento: per soddisfare le diverse esigenze di risorse per i carichi di lavoro sensibili al rendimento, 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 carichi di lavoro sensibili al rendimento (ad esempio applicazioni rivolte ai clienti) e non sensibili al rendimento (ad esempio applicazioni interne), puoi utilizzare più gruppi di nodi che utilizzano tipi di nodi diversi:
- Un gruppo di nodi utilizza overcommit della CPU e un tipo di nodo con un rapporto vCPU:memoria di 1:8. Questo gruppo di nodi viene utilizzato per i carichi di lavoro insensibili 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 carichi di lavoro critici per il rendimento e viene configurato per eseguire lo scale up e lo scale down in base alla domanda.
Disponibilità elevata multizona per i workload clusterizzati con licenza per core
Se esegui workload clusterizzati che utilizzano licenze per core e devi minimizzare le modifiche hardware, puoi trovare un equilibrio tra disponibilità e ovverhead delle licenze utilizzando più gruppi di nodi con finestre di manutenzione non sovrapposte:
- Più gruppi di nodi vengono di cui viene eseguito il deployment in zone o regioni diverse.
- Tutti i gruppi di nodi utilizzano il criterio di manutenzione restart. I gruppi di nodi utilizzano finestre di manutenzione non sovrapposte in modo che non più di un gruppo di nodi debba subire interruzioni correlate alla manutenzione contemporaneamente.
- Le istanze VM che eseguono workload clusterizzati utilizzano le etichette di affinità in modo che ogni nodo del cluster venga pianificato in un gruppo di nodi in una zona diversa.
Disponibilità elevata multizona per workload misti con licenza per core
Se utilizzi licenze per core, ma non tutti i tuoi carichi di lavoro sono raggruppati, puoi estendere il modello precedente utilizzando criteri di manutenzione eterogenei:
- Il gruppo di nodi principale viene implementato nella zona
aed esegue workload sia clusterizzati che non clusterizzati. Per ridurre al minimo le interruzioni causate dalla manutenzione dell'hardware, il gruppo di nodi utilizza il criterio di manutenzione Esegui la migrazione all'interno del gruppo di nodi. - Uno o più gruppi di nodi secondari vengono dipartiti in zone o regioni aggiuntive. Questi gruppi di nodi utilizzano il criterio di manutenzione restart, ma utilizzano periodi di manutenzione non sovrapposti.
- Le istanze VM che eseguono workload clusterizzati 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 carichi di lavoro non clusterizzati utilizzano le etichette di affinità in modo da essere dipiattate nel gruppo di nodi principale.
Se pianifichi i carichi di lavoro raggruppati solo nei gruppi di nodi secondari, puoi assicurarti che le interruzioni temporanee causate dal criterio di manutenzione del riavvio abbiano un impatto minimo sulla disponibilità complessiva. Allo stesso tempo, limiti il sovraccarico delle licenze e dell'infrastruttura utilizzando il criterio 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 eseguire l'overcommit delle CPU su VM single-tenant.
- Scopri come utilizzare le licenze che hai già.