Se 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 devono essere necessari e quali criteri di manutenzione devono essere utilizzati dai gruppi di nodi:
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 e i costi delle risorse, ti limita a una singola zona. Il deployment di gruppi di nodi in più zone consente di migliorare la disponibilità, ma può ridurre l'utilizzo delle risorse.
Criteri di scalabilità automatica e manutenzione: a seconda dei requisiti di licenza dei sistemi operativi e del software che intendi eseguire, la scalabilità automatica dei nodi e la scelta dei criteri di manutenzione possono influire sui costi e sulla disponibilità delle licenze.
Per prendere la decisione giusta su come utilizzare i nodi single-tenant, devi considerare 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 quali criteri di manutenzione devono utilizzare i gruppi di nodi.
BYOL e licenza per core
Se stai pianificando di portare la tua licenza (BYOL) 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 concessi in licenza dal core della CPU fisica e potrebbero definire dei limiti per la frequenza con cui è consentito cambiare l'hardware sottostante alle macchine virtuali. La scalabilità automatica dei nodi e i criteri di manutenzione predefiniti possono comportare la modifica dell'hardware più spesso di quanto consentito dai termini di licenza, il che può comportare costi aggiuntivi per la licenza.
Per eseguire l'ottimizzazione in base al BYOL per core, prendi in considerazione 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, ridurre al minimo i costi dell'infrastruttura potrebbe aumentare l'overhead delle licenze o viceversa. Ad esempio, l'utilizzo di un tipo di nodo con un numero elevato di core potrebbe essere la migliore dal punto di vista di costo/prestazioni per determinati carichi di lavoro, ma potrebbe portare a costi aggiuntivi per le licenze se il prezzo delle licenze è determinato per core.
Utilizza gruppi di nodi separati per i carichi di lavoro BYOL e non BYOL: per limitare il numero di core da concedere in licenza, evita di combinare carichi di lavoro BYOL e non BYOL in un singolo 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), la suddivisione dei gruppi di nodi in base al modello di licenza può aiutare a semplificare il monitoraggio delle licenze e ridurre i costi delle licenze.
Utilizza l'overcommit della CPU e i tipi di nodi con un rapporto core/memoria elevato: i tipi di nodi differiscono nel rapporto tra socket, core e memoria. L'utilizzo di un tipo di nodo con un rapporto core:memoria più elevato e l'abilitazione dell'overcommit della CPU può contribuire a ridurre il numero di core da acquisire in licenza.
Evita la scalabilità automatica dello scale in: la scalabilità automatica dei gruppi di nodi consente di aumentare o ridurre automaticamente un gruppo di nodi in base alla domanda attuale. La crescente e contrazione frequente di un gruppo di nodi implica la modifica frequente dell'hardware su cui vengono eseguite le VM.
Se cambi spesso l'hardware in modo che ti sia permesso di spostare licenze tra macchine fisiche, queste modifiche all'hardware possono portare a una situazione in cui devi concedere in licenza più core che stai effettivamente utilizzando.
Se sono presenti limiti per la frequenza di spostamento tra macchine fisiche, puoi evitare costi eccessivi per le licenze disabilitando la scalabilità automatica o configurando la scalabilità automatica per solo lo scale out.
Non utilizzare il criterio di manutenzione predefinito: il criterio di manutenzione predefinito ti consente di ottimizzare la disponibilità delle VM, ma può causare frequenti modifiche dell'hardware. Per ridurre al minimo le modifiche all'hardware e ottimizzare i costi delle licenze, utilizza il criterio di migrazione all'interno della manutenzione del gruppo di nodi o di riavvio attivo.
Per i carichi di lavoro che non richiedono licenze per core, prendi in considerazione le seguenti best practice:
- Utilizza il criterio di manutenzione predefinito: con il criterio live-migration, il criterio di manutenzione predefinito offre una disponibilità migliore rispetto al criterio di riavvio in loco, evitando i costi aggiuntivi dell'infrastruttura necessari per la migrazione all'interno del criterio di manutenzione del gruppo di nodi.
Gestione
Se hai più di un carico di lavoro o se hai carichi di lavoro sia di sviluppo che di produzione che devono essere eseguiti su nodi single-tenant, considera le seguenti best practice:
Utilizza gruppi di nodi separati per gli ambienti di sviluppo e produzione: l'utilizzo di gruppi di nodi separati consente di isolare gli ambienti da altri ed evitare situazioni quali:
- Una VM di sviluppo potrebbe influire sulle prestazioni delle VM di produzione consumando in modo eccessivo CPU, disco o risorse di rete ("vicino rumore").
- 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 appieno ciascun 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. Quindi condividi i gruppi di nodi con i progetti che contengono carichi di lavoro.
Questo approccio consente di semplificare controllo dell'accesso#39;accesso utilizzando un progetto separato per ogni carico di lavoro e, al contempo, di ottimizzare l'utilizzo delle risorse condividendo i gruppi di nodi tra i carichi di lavoro.
Condividi gruppi di nodi con singoli progetti: anziché condividere un gruppo di nodi con un'intera organizzazione, condividilo solo con i singoli progetti. Selezionare i progetti singolarmente ti consente di mantenere una separazione tra gli ambienti ed evita di divulgare informazioni sui gruppi di nodi ad altri progetti.
Stabilisci un processo per l'attribuzione dei costi interni: il costo per l'esecuzione di un gruppo di nodi viene sostenuto per il progetto che contiene il gruppo di nodi. Se devi attribuire questo costo a singoli progetti o carichi di lavoro, ti consigliamo di monitorare l'utilizzo delle VM single-tenant e di utilizzare questi dati per eseguire l'attribuzione dei costi interni.
Disponibilità
I requisiti di disponibilità dei tuoi carichi di lavoro potrebbero essere diversi e l'alta disponibilità potrebbe essere raggiunta a livello di applicazione o la necessità di implementazione a livello di infrastruttura:
Applicazioni in cluster: alcuni dei carichi di lavoro potrebbero implementare l'alta disponibilità nell'applicazione utilizzando tecniche di clustering come la replica e il bilanciamento del carico.
Esempi di questi carichi di lavoro includono i controller di dominio Active Directory, le istanze del cluster di failover SQL Server e i gruppi di disponibilità o le applicazioni in cluster con bilanciamento del carico in esecuzione su IIS.
Le applicazioni in cluster possono in genere sostenere interruzioni di singole VM, purché la maggior parte delle VM rimanga disponibile.
Applicazioni non in cluster: alcuni carichi di lavoro potrebbero non implementare alcuna funzionalità di clustering e richiedere invece che la VM stessa rimanga disponibile.
Alcuni esempi di carichi di lavoro di questo tipo 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 imminente evento di manutenzione dei nodi.
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 riavvio in loco di manutenzione.
Applicazioni non critiche: i carichi di lavoro batch, i carichi di lavoro di sviluppo/test e altri carichi di lavoro a priorità inferiore potrebbero non avere requisiti di disponibilità specifici. Per questi carichi di lavoro, potrebbe essere accettabile se le singole VM non sono disponibili durante la manutenzione dei nodi.
Per soddisfare i requisiti di disponibilità dei carichi di lavoro, prendi in considerazione le seguenti best practice:
Utilizza gruppi di nodi in zone o regioni diverse per eseguire il deployment di carichi di lavoro in cluster: I nodi e i gruppi di nodi single-tenant sono una risorsa di zona. Per proteggerti da interruzioni 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 della tua applicazione in cluster venga eseguita su un nodo diverso in una zona o regione diversa.
Se due o più gruppi di nodi utilizzano il criterio di manutenzione predefinito o di riavvio in loco, configura i periodi di manutenzione in modo che sia improbabile che si sovrappongano.
Se più istanze delle applicazioni in cluster devono essere eseguite in una singola zona, utilizza l'anti-affinità per garantire che le istanze VM siano pianificate su nodi o gruppi di nodi diversi.
Evita il criterio di manutenzione di riavvio in loco per i carichi di lavoro non cluster che richiedono un'alta disponibilità: Poiché il criterio di manutenzione Riavvio in loco arresta le VM quando il nodo sottostante richiede manutenzione, è preferibile utilizzare criteri di manutenzione diversi per i gruppi di nodi che eseguono carichi di lavoro non in cluster che richiedono un'alta disponibilità.
Utilizza i gruppi di istanze gestite per aumentare la resilienza e la disponibilità dei carichi di lavoro: puoi aumentare ulteriormente la resilienza e la disponibilità del tuo deployment utilizzando i gruppi di istanze gestite per monitorare l'integrità dei carichi di lavoro e ricreare automaticamente le istanze VM, se necessario. Puoi utilizzare i gruppi di istanze gestite sia per i carichi di lavoro stateless che per i carichi di lavoro stateful.
Prestazioni
La sensibilità dei carichi di lavoro alle fluttuazioni del rendimento potrebbe essere diversa. Per alcune applicazioni interne o carichi di lavoro di test, l'ottimizzazione dei costi potrebbe essere più importante che garantire prestazioni coerenti durante il giorno. Per altri carichi di lavoro, come le applicazioni rivolte all'esterno, le prestazioni potrebbero essere critiche e più importanti dell'utilizzo delle risorse.
Per utilizzare al meglio i nodi single-tenant, prendi in considerazione le seguenti best practice:
Utilizza gruppi di nodi dedicati e overcommit della CPU per carichi di lavoro non sensibili 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 supporti l'overcommit della CPU. L'abilitazione 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 carichi di lavoro idonei per l'overcommit della CPU e che abiliti l'overcommit della CPU solo per questo gruppo di nodi. Lascia disabilitato l'overcommit della CPU per tutti 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: l'overcommit della CPU ti consente di condividere i core tra le VM, ma 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 aiuta a garantire che la memoria non diventi un fattore limitante.
- Utilizza la scalabilità automatica dei nodi per carichi di lavoro sensibili alle prestazioni: per soddisfare esigenze di risorse diverse per carichi di lavoro sensibili alle prestazioni, configura il tuo gruppo di nodi in modo che utilizzi la scalabilità automatica.
Pattern di deployment
Il modo migliore per utilizzare i nodi single-tenant dipende dalle esigenze individuali. La seguente sezione descrive una selezione di pattern che puoi utilizzare come punto di partenza per ricavare un'architettura adatta ai tuoi requisiti individuali.
Gruppi di più nodi per requisiti di prestazioni misti
Se hai una combinazione di carichi di lavoro 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 1:8. Questo gruppo di nodi viene utilizzato per carichi di lavoro 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 carichi di lavoro critici per le prestazioni ed è configurato per fare lo scale up e lo scale down on demand.
Alta disponibilità multi-zona per carichi di lavoro con licenza per core in cluster
Se esegui carichi di lavoro in cluster che utilizzano licenze per core e hai bisogno di ridurre al minimo le modifiche all'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 zone o regioni diverse.
- Tutti i gruppi di nodi utilizzano il criterio di manutenzione di riavvio. I gruppi di nodi utilizzano periodi di manutenzione non sovrapposti in modo che non si verifichino interruzioni correlate alla manutenzione di più di un gruppo di nodi alla volta.
- Le istanze VM che eseguono carichi di lavoro in cluster utilizzano etichette di affinità in modo che ciascun nodo del cluster venga pianificato su un gruppo di nodi in una zona diversa.
Alta disponibilità multizona per carichi di lavoro misti per core di licenze
Se utilizzi le licenze per core, ma non tutti i carichi di lavoro sono in cluster, puoi estendere il pattern precedente utilizzando criteri di manutenzione eterogenei:
- Viene eseguito il deployment del gruppo di nodi principali nella zona
aed esegue carichi di lavoro in cluster e non. 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. - Il deployment di uno o più gruppi di nodi secondari viene eseguito in zone o regioni aggiuntive. Questi gruppi di nodi utilizzano il criterio di manutenzione di riavvio, ma utilizzano periodi di manutenzione non sovrapposti.
- Le istanze VM che eseguono carichi di lavoro in cluster utilizzano etichette di affinità in modo che ciascun nodo del cluster venga pianificato su un gruppo di nodi in una zona diversa.
- Le istanze VM che eseguono carichi di lavoro non in cluster utilizzano le etichette di affinità in modo che il deployment venga eseguito nel gruppo di nodi principali.
Pianificando i carichi di lavoro in cluster solo sui 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 l'overhead 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 principali.
Passaggi successivi
- Scopri di più sui nodi single-tenant.
- Scopri come overcommit delle CPU su VM single-tenant.
- Scopri come portare le tue licenze.