Panoramica della single-tenancy

Questo documento descrive i nodi single-tenant. Per informazioni su come eseguire il provisioning delle VM sui nodi single-tenant, consulta Provisioning delle VM sui nodi single-tenant.

La modalità single-tenancy ti consente di avere accesso esclusivo a un nodo single-tenant, ovvero un server Compute Engine fisico dedicato esclusivamente all'hosting delle VM del tuo progetto. Utilizza i nodi single-tenant per mantenere le VM fisicamente separate da quelle di altri progetti o per raggrupparle sullo stesso hardware host, come mostrato nel seguente diagramma. Puoi anche creare un gruppo di nodi single-tenant e specificare se vuoi condividerlo con altri progetti o con l'intera organizzazione.

Un host multi-tenant e un nodo single-tenant a confronto.
Figura 1: un host multi-tenant e un nodo single-tenant a confronto.

Le VM in esecuzione su nodi single-tenant possono utilizzare le stesse funzionalità di Compute Engine delle altre VM, tra cui la programmazione trasparente e l'archiviazione a blocchi, ma con un ulteriore livello di isolamento dell'hardware. Per consentirti di avere il pieno controllo sulle VM sul server fisico, ogni nodo single-tenant gestisce una mappatura one-to-one al server fisico di supporto del nodo.

All'interno di un nodo single-tenant, puoi eseguire il provisioning di più VM su tipi di macchine di varie dimensioni, il che ti consente di utilizzare in modo efficiente le risorse sottostanti dell'hardware host dedicato. Inoltre, se scegli di non condividere l'hardware dell'host con altri progetti, puoi soddisfare i requisiti di sicurezza o conformità con i workload che richiedono l'isolamento fisico da altri workload o VM. Se il tuo workload richiede la single-tenancy solo temporaneamente, puoi modificare la tenancy della VM in base alle necessità.

I nodi single-tenant possono aiutarti a soddisfare i requisiti hardware dedicati per scenari BYOL (Bring Your Own License) che richiedono licenze per ciascun core o processore. Quando utilizzi i nodi single-tenant, hai una certa visibilità sull'hardware sottostante, il che ti consente di monitorare l'utilizzo del core e del processore. Per monitorarne l'utilizzo, Compute Engine segnala l'ID del server fisico su cui è programmata una VM. Poi, utilizzando Cloud Logging, puoi visualizzare la cronologia di utilizzo del server di una VM.

Per ottimizzare l'utilizzo dell'hardware host, puoi intraprendere le seguenti azioni:

Tramite una policy di manutenzione dell'host configurabile puoi controllare il comportamento delle VM single-tenant mentre l'host è in manutenzione. Puoi specificare quando avviene la manutenzione e se le VM mantengono l'affinità con un server fisico specifico o vengono spostate in altri nodi single-tenant all'interno di un gruppo di nodi.

Considerazioni sul workload

L'utilizzo di nodi single-tenant potrebbe essere utile per i seguenti tipi di workload:

  • Workload di giochi con requisiti di prestazioni.

  • Workload finanziari o sanitari con requisiti di sicurezza e conformità.

  • Workload Windows con requisiti di licenza.

  • Workload di machine learning, elaborazione dati o rendering di immagini. Per questi tipi di workload, valuta la possibilità di prenotare delle GPU.

  • Workload che richiedono un aumento delle operazioni di I/O al secondo (IOPS) e una minore latenza, oppure workload che utilizzano uno spazio di archiviazione temporaneo sotto forma di cache, spazio di elaborazione o dati di basso valore. Per questi workload, valuta la possibilità di prenotare dischi SSD locali.

Template di nodo

Un template di nodo è una risorsa di regione che definisce le proprietà di ciascun nodo in un gruppo di nodi. Quando crei un gruppo di nodi da un template di nodo, le proprietà del template vengono copiate in modo immutabile in ogni nodo del gruppo.

Quando crei un template di nodo, devi specificare un tipo di nodo. Facoltativamente, puoi specificare le etichette di affinità dei nodi quando crei un template di nodo. Puoi specificare le etichette di affinità dei nodi solo su un template di nodo. Non le puoi specificare su un gruppo di nodi.

Tipi di nodo

Quando configuri un template di nodo, specifica un tipo di nodo da applicare a tutti i nodi all'interno di un gruppo di nodi creato in base al template. Il tipo di nodo single-tenant, a cui fa riferimento il template di nodo, specifica la quantità totale di core vCPU e memoria per i nodi creati nei gruppi di nodi che utilizzano il template. Ad esempio, il tipo di nodo n2-node-80-640 ha 80 vCPU e 640 GB di memoria.

Le VM aggiunte a un nodo single-tenant devono avere lo stesso tipo di macchina del tipo di nodo specificato nel template. Ad esempio, i tipi di nodi single-tenant n2 sono compatibili solo con le VM create con il tipo di macchina n2. Puoi aggiungere VM a un nodo single-tenant finché la quantità totale di vCPU o memoria non supera la capacità del nodo.

Quando crei un gruppo di nodi utilizzando un template di nodo, ogni nodo del gruppo eredita le specifiche del tipo di nodo del template. Un tipo di nodo si applica a ogni nodo all'interno di un gruppo di nodi individualmente, non a tutti i nodi del gruppo in modo uniforme. Pertanto, se crei un gruppo di nodi con due nodi di tipo n2-node-80-640, a ogni nodo vengono allocate 80 vCPU e 640 GB di memoria.

A seconda dei requisiti del tuo workload, puoi riempire il nodo con più VM più piccole in esecuzione su tipi di macchine di varie dimensioni, inclusi tipi di macchine predefinite, tipi di macchine personalizzate e tipi di macchine con memoria estesa. Quando un nodo è pieno, non vi puoi programmare altre VM.

La tabella seguente mostra i tipi di nodi disponibili. Per visualizzare un elenco dei tipi di nodi disponibili per il tuo progetto, esegui il comando gcloud compute sole-tenancy node-types list o crea una richiesta REST nodeTypes.list.

Tipo di nodo Processore vCPU GB vCPU:GB Socket Core:Socket Core totali Numero massimo di VM consentite
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36 15
c3-node-176-352 Sapphire Rapids 176 352 1:2 2 48 96 44
c3-node-176-704 Sapphire Rapids 176 704 1:4 2 48 96 44
c3-node-176-1408 Sapphire Rapids 176 1408 1:8 2 48 96 44
c3d-node-360-708 AMD EPYC Genoa 360 708 1:2 2 96 192 34
c3d-node-360-1440 AMD EPYC Genoa 360 1440 1:4 2 96 192 40
c3d-node-360-2880 AMD EPYC Genoa 360 2880 1:8 2 96 192 40
c4-node-192-384 Emerald Rapids 192 384 1:2 2 60 120 40
c4-node-192-720 Emerald Rapids 192 720 1:3,75 2 60 120 30
c4-node-192-1488 Emerald Rapids 192 1488 1:7,75 2 60 120 30
c4a-node-72-144 Google Axion 72 144 1:2 1 80 80 22
c4a-node-72-288 Google Axion 72 288 1:4 1 80 80 22
c4a-node-72-576 Google Axion 72 576 1:8 1 80 80 36
g2-node-96-384 Cascade Lake 96 384 1:4 2 28 56 8
g2-node-96-432 Cascade Lake 96 432 1:4,5 2 28 56 8
h3-node-88-352 Sapphire Rapids 88 352 1:4 2 48 96 1
m1-node-96-1433 Skylake 96 1433 1:14,93 2 28 56 1
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88 4
m2-node-416-8832 Cascade Lake 416 8832 1:21,23 8 28 224 1
m2-node-416-11776 Cascade Lake 416 11.776 1:28,31 8 28 224 2
m3-node-128-1952 Ice Lake 128 1952 1:15,25 2 36 72 2
m3-node-128-3904 Ice Lake 128 3904 1:30,5 2 36 72 2
m4-node-224-2976 Emerald Rapids 224 2976 1:13,3 2 112 224 1
m4-node-224-5952 Emerald Rapids 224 5952 1:26,7 2 112 224 1
n1-node-96-624 Skylake 96 624 1:6,5 2 28 56 96
n2-node-80-640 Cascade Lake 80 640 1:8 2 24 48 80
n2-node-128-864 Ice Lake 128 864 1:6,75 2 36 72 128
n2d-node-224-896 AMD EPYC Rome 224 896 1:4 2 64 128 112
n2d-node-224-1792 AMD EPYC Milan 224 1792 1:8 2 64 128 112
n4-node-224-1372 Emerald Rapids 224 1372 1:6 2 60 120 90

Per informazioni sui prezzi di questi tipi di nodi, consulta Prezzi dei nodi single-tenant.

Tutti i nodi ti consentono di programmare VM di forme diverse. I nodi di tipo n sono nodi di uso generale su cui puoi programmare le istanze di tipo di macchina personalizzata. Per consigli su quale tipo di nodo scegliere, consulta Consigli per i tipi di macchine. Per informazioni sul rendimento, consulta Piattaforme CPU.

Gruppi di nodi e provisioning delle VM

I template di nodi single-tenant definiscono le proprietà di un gruppo di nodi. Quindi devi creare un template di nodo prima di creare un gruppo di nodi in una zona Google Cloud. Quando crei un gruppo, specifica la policy di manutenzione dell'host per le VM nel gruppo di nodi, il numero di nodi per il gruppo e se condividerlo con altri progetti o con l'intera organizzazione.

Un gruppo di nodi può avere zero o più nodi. Ad esempio, puoi azzerare il numero di nodi in un gruppo di nodi quando non devi eseguire VM sui nodi del gruppo oppure puoi attivare il gestore della scalabilità automatica del gruppo di nodi per gestire automaticamente le dimensioni del gruppo di nodi.

Prima di eseguire il provisioning delle VM sui nodi single-tenant, devi creare un gruppo di nodi single-tenant. Un gruppo di nodi è un insieme omogeneo di nodi single-tenant in una zona specifica. I gruppi di nodi possono contenere più VM della stessa serie di macchine in esecuzione su tipi di macchine di varie dimensioni, purché il tipo di macchina abbia almeno 2 vCPU.

Quando crei un gruppo di nodi, abilita la scalabilità automatica in modo da regolare in automatico le dimensioni del gruppo in base ai requisiti del tuo workload. Se il workload ha requisiti statici, puoi specificare manualmente la dimensione del gruppo di nodi.

Dopo aver creato un gruppo di nodi, puoi eseguire il provisioning delle VM nel gruppo o su un nodo specifico al suo interno. Per un maggiore controllo, utilizza le etichette di affinità dei nodi per programmare le VM su qualsiasi nodo con etichette di affinità corrispondenti.

Dopo aver eseguito il provisioning delle VM sui gruppi di nodi e, facoltativamente, aver assegnato le etichette di affinità per eseguire il provisioning delle VM su gruppi di nodi o nodi specifici, ti consigliamo di etichettare le risorse per gestire più facilmente le VM. Le etichette sono coppie chiave/valore che possono aiutarti a classificare le VM così da visualizzarle in modo aggregato ai fini della fatturazione, ma non solo. Ad esempio, puoi utilizzare le etichette per contrassegnare il ruolo di una VM, il relativo tenant, il tipo di licenza o la sua posizione.

Policy di manutenzione dell'host

A seconda delle licenze e dei workload, considera l'idea di limitare il numero di core fisici utilizzati dalle VM. La scelta della policy di manutenzione dell'host potrebbe dipendere, ad esempio, dai requisiti di licenza o conformità, oppure puoi considerare l'opzione di scegliere una policy che ti consenta di limitare l'utilizzo dei server fisici. Con tutte queste policy le VM rimangono su hardware dedicato.

Quando programmi le VM su nodi single-tenant, puoi scegliere tra le seguenti tre diverse opzioni di policy di manutenzione dell'host, che ti consentono di determinare in che modo e se Compute Engine deve eseguire la migrazione live delle VM durante eventi dell'host, che si verificano approssimativamente ogni 4-6 settimane. Durante la manutenzione, Compute Engine esegue la migrazione live, come gruppo, di tutte le VM sull'host a un altro nodo single-tenant. In alcuni casi però, Compute Engine potrebbe suddividere le VM in gruppi più piccoli ed eseguire la migrazione live di ciascun gruppo di VM a nodi single-tenant separati.

Policy di manutenzione dell'host predefinita

Si tratta della policy di manutenzione dell'host predefinita e le VM nei gruppi di nodi configurati con questa policy seguono il comportamento di manutenzione tradizionale per le VM non single-tenant. In altre parole, a seconda delle impostazioni di manutenzione on-host dell'host della VM, le VM eseguono la migrazione live a un nuovo nodo single-tenant nel gruppo di nodi prima di un evento di manutenzione dell'host e questo nuovo nodo single-tenant esegue solo le VM del cliente.

Questa policy è più adatta per le licenze per utente o per dispositivo che richiedono la migrazione live durante gli eventi dell'host. Questa impostazione non limita la migrazione delle VM all'interno di un pool fisso di server fisici ed è consigliata per i workload generici senza requisiti di server fisici e che non richiedono licenze esistenti.

Poiché la migrazione delle VM avviene in tempo reale su qualsiasi server senza considerare l'affinità esistente del server con la policy, quest'ultima non è adatta per gli scenari che richiedono la minimizzazione dell'uso dei core fisici durante gli eventi dell'host.

La figura seguente mostra un'animazione della policy Predefinita di manutenzione dell'host.

Animazione della policy predefinita di manutenzione dell'host.
Figura 2: animazione della policy Predefinita di manutenzione dell'host.

Policy di manutenzione dell'host di riavvio in loco

Quando utilizzi questa policy di manutenzione dell'host, Compute Engine arresta le VM durante gli eventi dell'host e poi le riavvia sullo stesso server fisico dopo l'evento dell'host. Quando utilizzi questa policy, devi impostare la manutenzione sull'host della VM su TERMINATE.

Questa policy è più adatta per i workload a tolleranza di errore che possono avere circa un'ora di tempo di inattività durante gli eventi dell'host, i workload che devono rimanere sullo stesso server fisico, i workload che non richiedono la migrazione live, oppure se hai licenze basate sul numero di core o processori fisici.

Con questa policy l'istanza può essere assegnata al gruppo di nodi utilizzando node-name, node-group-name o l'etichetta di affinità del nodo.

La figura seguente mostra un'animazione della policy di manutenzione Riavvia in loco.

Animazione della policy di manutenzione dell'host di riavvio in loco
Figura 3: animazione della policy di manutenzione dell' host di riavvio in loco.

Policy di manutenzione dell'host per la migrazione all'interno del gruppo di nodi

Quando utilizzi questa policy di manutenzione dell'host, Compute Engine esegue la migrazione live delle VM all'interno di un gruppo di server fisici di dimensioni fisse durante gli eventi dell'host, il che contribuisce a limitare il numero di server fisici univoci utilizzati dalla VM.

Questa policy è più adatta per workload ad alta affidabilità con licenze basate sul numero di core o processori fisici, perché così ogni nodo single-tenant del gruppo è assegnato a un insieme fisso di server fisici, a differenza della policy predefinita che consente alle VM di eseguire la migrazione su qualsiasi server.

Per garantire la capacità per la migrazione live, Compute Engine riserva 1 nodo holdback per ogni 20 nodi prenotati. La figura seguente mostra un'animazione della policy di manutenzione dell'host Esegui la migrazione all'interno del gruppo di nodi.

Animazione della policy di manutenzione dell'host Esegui la migrazione all'interno di un gruppo di nodi.
Figura 4: animazione della policy di manutenzione dell'host Esegui la migrazione all'interno del gruppo di nodi.

La tabella seguente mostra quanti nodi holdback vengono riservati da Compute Engine in base al numero di nodi prenotati per il gruppo di nodi.

Nodi totali nel gruppo Nodi holdback prenotati per la migrazione live
1 Non applicabile Devi prenotare almeno 2 nodi.
da 2 a 20 1
da 21 a 40 2
da 41 a 60 3
da 61 a 80 4
da 81 a 100 5

Assegna un'istanza a più gruppi di nodi

Puoi assegnare un'istanza a più gruppi di nodi utilizzando l' etichetta di affinità node-group-name nelle seguenti condizioni:

  • L'istanza che vuoi assegnare utilizza una policy predefinita di manutenzione dell'host (Esegui migrazione istanza VM).
  • La policy di manutenzione dell'host di tutti i gruppi di nodi a cui vuoi assegnare l'istanza è Esegui la migrazione all'interno del gruppo di nodi. Se provi ad assegnare un'istanza in gruppi di nodi con policy di manutenzione dell'host diverse, l'operazione non va a buon fine e viene visualizzato un errore.

Ad esempio, se vuoi assegnare un'istanza test-node a due gruppi di nodi node-group1 e node-group2, verifica quanto segue:

  • La policy di manutenzione dell'host di test-node è Esegui migrazione istanza VM.
  • La policy di manutenzione dell'host di node-group1 e node-group2 è Esegui la migrazione all'interno del gruppo di nodi.

Non puoi assegnare un'istanza a un nodo specifico con l'etichetta di affinità node-name. Puoi utilizzare qualsiasi etichetta di affinità dei nodi personalizzata per le tue istanze, a condizione che venga assegnata node-group-name e non node-name.

Periodi di manutenzione

Se gestisci workload (ad esempio database ottimizzati) che potrebbero essere sensibili agli effetti sulle prestazioni della migrazione live, puoi determinare quando inizia la manutenzione di un gruppo di nodi single-tenant specificando un periodo di manutenzione al momento della creazione del gruppo di nodi. Non puoi modificare il periodo di manutenzione dopo aver creato il gruppo di nodi.

I periodi di manutenzione sono intervalli di tempo di 4 ore che puoi utilizzare per specificare quando Google esegue la manutenzione sulle tue VM single-tenant. Gli eventi di manutenzione si verificano circa una volta ogni 4-6 settimane.

Il periodo di manutenzione si applica a tutte le VM del gruppo di nodi single-tenant e specifica solo l'inizio della manutenzione. Non è garantito che la manutenzione venga completata durante il periodo di manutenzione né è garantita la frequenza con cui avviene. I periodi di manutenzione non sono supportati sui gruppi di nodi con la policy di manutenzione dell'host Esegui la migrazione all'interno del gruppo di nodi.

Simula un evento di manutenzione dell'host

Puoi simulare un evento di manutenzione dell'host per testare il comportamento dei workload in esecuzione su nodi single-tenant durante un evento di manutenzione dell'host. In questo modo puoi vedere gli effetti della policy di manutenzione dell'host della VM single-tenant sulle applicazioni in esecuzione sulle VM.

Errori dell'host

Nella rara eventualità che si verifichi un guasto critico dell'hardware sull'host, single o multi-tenant, Compute Engine esegue le seguenti operazioni:

  1. Ritira il server fisico e il relativo identificatore univoco.

  2. Revoca l'accesso del progetto al server fisico.

  3. Sostituisce l'hardware guasto con un nuovo server fisico con un nuovo identificatore unico.

  4. Sposta le VM dall'hardware non funzionante al nodo sostitutivo.

  5. Riavvia le VM interessate se le hai configurate per il riavvio automatico.

Affinità e anti-affinità dei nodi

I nodi single-tenant assicurano che le VM non condividano l'host con le VM di altri progetti, a meno che non utilizzi gruppi di nodi single-tenant condivisi. Con i gruppi di nodi single-tenant condivisi, altri progetti all'interno dell'organizzazione possono eseguire il provisioning delle VM sullo stesso host. Tuttavia, potresti comunque voler raggruppare più workload sullo stesso nodo single-tenant o isolarli l'uno dall'altro su nodi diversi. Ad esempio, per contribuire a soddisfare alcuni requisiti di conformità, potresti dover utilizzare le etichette di affinità per separare i workload sensibili da quelli non sensibili.

Quando crei una VM, richiedi la single-tenancy specificando l'affinità o l'anti-affinità dei nodi facendo riferimento a una o più etichette di affinità dei nodi. Specifichi le etichette di affinità dei nodi personalizzate quando crei un template di nodo e Compute Engine include automaticamente alcune etichette di affinità predefinite su ogni nodo. Se specifichi l'affinità quando crei una VM, puoi programmare le VM insieme su un nodo o su più nodi specifici in un gruppo di nodi. Se specifichi l'anti-affinità quando crei una VM, puoi assicurarti che determinate VM non vengano programmate insieme sullo stesso nodo o sugli stessi nodi in un gruppo di nodi.

Le etichette di affinità dei nodi sono coppie chiave-valore assegnate ai nodi e vengono ereditate da un template di nodo. Le etichette di affinità ti consentono di:

  • controllare in che modo le singole istanze VM vengono assegnate ai nodi;
  • controllare in che modo le istanze VM create da un template, ad esempio quelle create da un gruppo di istanze gestite, vengono assegnate ai nodi;
  • raggruppare le istanze VM sensibili su nodi o gruppi di nodi specifici, separati dalle altre VM.

Etichette di affinità predefinita

Compute Engine assegna le seguenti etichette di affinità predefinita a ogni nodo:

  • Un'etichetta per il nome del gruppo di nodi:
    • Chiave: compute.googleapis.com/node-group-name
    • Valore: il nome del gruppo di nodi.
  • Un'etichetta per il nome del nodo:
    • Chiave: compute.googleapis.com/node-name
    • Valore: nome del singolo nodo.
  • Un'etichetta per i progetti con cui è condiviso il gruppo di nodi:
    • Chiave: compute.googleapis.com/projects
    • Valore: ID del progetto contenente il gruppo di nodi.

Etichette di affinità personalizzata

Puoi creare etichette di affinità dei nodi personalizzata quando crei un template di nodo. Queste etichette di affinità vengono assegnate a tutti i nodi dei gruppi di nodi creati dal template di nodo. Non puoi aggiungere altre etichette di affinità personalizzata ai nodi di un gruppo di nodi dopo averlo creato.

Per informazioni su come utilizzare le etichette di affinità, consulta Configurazione dell'affinità dei nodi.

Prezzi

  • Per aiutarti a ridurre al minimo il costo dei nodi single-tenant, Compute Engine fornisce sconti per impegno di utilizzo (CUD) e sconti per utilizzo sostenuto (SUD). Tieni presente che per gli addebiti premium per la modalità single-tenancy sono previsti solo CUD e SUD flessibili, ma non CUD basati sulle risorse.

  • Poiché ti viene già addebitato il costo delle vCPU e della memoria dei nodi single-tenant, non sono previsti costi extra per le VM che crei su questi nodi.

  • Se esegui il provisioning di nodi single-tenant con GPU o dischi SSD locali, ti viene addebitato il costo di tutte le GPU o di tutti i dischi SSD locali su ogni nodo di cui esegui il provisioning. Gli addebiti premium per l'utilizzo in modalità single-tenancy si basa solo sulle vCPU e sulla memoria utilizzate per il nodo single-tenant e non include GPU o dischi SSD locali.

Disponibilità

  • I nodi single-tenant sono disponibili in alcune zone. Per garantirne l'alta affidabilità, pianifica le VM su nodi single-tenant in zone diverse.

  • Prima di utilizzare GPU o dischi SSD locali su nodi single-tenant, assicurati di disporre di una quota di GPU o SSD locali sufficiente nella zona in cui stai prenotando la risorsa.

  • Compute Engine supporta le GPU sui tipi di nodi single-tenant n1 e g2 che si trovano nelle zone con supporto delle GPU. La tabella seguente mostra i tipi di GPU che puoi collegare ai nodi n1 e g2 e il numero di GPU da collegare quando crei il template di nodo.

    Tipo di GPU Quantità di GPU Tipo di nodo single-tenant
    NVIDIA L4 8 g2
    NVIDIA P100 4 n1
    NVIDIA P4 4 n1
    NVIDIA T4 4 n1
    NVIDIA V100 8 n1

  • Compute Engine supporta i dischi SSD locali sui tipi di nodi single-tenant n1, n2, n2d e g2 utilizzati nelle zone che supportano queste serie di macchine.

Limitazioni

  • Solo i nodi single-tenant N1, N2, N2D e N4 supportano l'overcommit delle CPU.

  • I nodi single-tenant C3 e C4 non supportano configurazioni VM diverse sullo stesso nodo single-tenant. Ad esempio, non puoi posizionare una VM c3-standard o nodo single-tenant di una VM c3-highmem.

  • Non puoi aggiornare la policy di manutenzione in un gruppo di nodi attivo.

Passaggi successivi