Panoramica del 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.

L'architettura single-tenancy ti consente di avere accesso esclusivo a un nodo single-tenant, ovvero un server Compute Engine fisico dedicato all'hosting delle VM solo per il tuo progetto. Utilizza i nodi single-tenant per mantenere le tue VM fisicamente separate dalle VM in altri progetti o per raggruppare le tue VM sullo stesso hardware host, come mostrato nel diagramma seguente. 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.
Figura 1: un host multi-tenant e un nodo single-tenant.

Le VM in esecuzione su nodi single-tenant possono utilizzare le stesse funzionalità di Compute Engine di altre VM, ad esempio pianificazione trasparente e archiviazione a blocchi, ma con un ulteriore livello di isolamento hardware. Per darti il controllo completo sulle VM sul server fisico, ogni nodo single-tenant mantiene una mappatura one-to-one sul server fisico che supporta il nodo.

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

I nodi single-tenant possono aiutarti a soddisfare requisiti hardware dedicati per gli scenari BYOL (Bring Your Own License) che richiedono licenze per core o per processore. Quando utilizzi nodi single-tenant, hai una certa visibilità sull'hardware sottostante, che ti consente di tenere traccia dell'utilizzo di core e processori. Per monitorare questo utilizzo, Compute Engine segnala l'ID del server fisico su cui è pianificata una VM. Quindi, utilizzando Cloud Logging, puoi visualizzare l'utilizzo storico del server di una VM.

Per ottimizzare l'utilizzo dell'hardware host, puoi:

Tramite un criterio di manutenzione dell'host configurabile, puoi controllare il comportamento delle VM single-tenant mentre il loro host è in fase di manutenzione. Puoi specificare quando viene eseguita 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 carico di lavoro

I seguenti tipi di carichi di lavoro potrebbero trarre vantaggio dall'utilizzo di nodi single-tenant:

  • Carichi di lavoro per i giochi con requisiti di prestazioni.

  • Carichi di lavoro del settore finanziario o sanitario con requisiti di sicurezza e conformità.

  • Carichi di lavoro Windows con requisiti di licenze.

  • Carichi di lavoro di machine learning, elaborazione dati o rendering delle immagini. Per questi carichi di lavoro, valuta la possibilità di prenotare le GPU.

  • Carichi di lavoro che richiedono un maggior numero di operazioni di I/O al secondo (IOPS) e minore latenza o carichi di lavoro che utilizzano l'archiviazione temporanea sotto forma di cache, spazio di elaborazione o dati di scarso valore. Per questi carichi di lavoro, valuta la possibilità di prenotare SSD locali.

Modelli di nodo

Un modello 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 modello di nodo, le proprietà di quest'ultimo vengono copiate immutabilmente in ciascun nodo del gruppo.

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

Tipi di nodo

Quando configuri un modello di nodo, specifica un tipo di nodo da applicare a tutti i nodi all'interno di un gruppo di nodi creato in base al modello. Il tipo di nodo single-tenant, a cui fa riferimento il modello di nodo, specifica la quantità totale di core vCPU e la memoria per i nodi creati nei gruppi di nodi che utilizzano il modello. 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 modello di nodo. 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 modello di nodo, ogni nodo nel gruppo eredita le specifiche del tipo di nodo del modello di nodo. Un tipo di nodo si applica a ogni singolo nodo all'interno di un gruppo di nodi, non a tutti i nodi in modo uniforme. Quindi, se crei un gruppo di nodi con due nodi entrambi del tipo n2-node-80-640, a ogni nodo sono allocati 80 vCPU e 640 GB di memoria.

A seconda dei requisiti dei carichi di lavoro, potresti riempire il nodo con più VM più piccole in esecuzione su tipi di macchine di varie dimensioni, tra cui tipi di macchine predefinite, tipi di macchine personalizzate e tipi di macchine con memoria estesa. Quando un nodo è pieno, non puoi pianificare VM aggiuntive su quel nodo.

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 la richiesta REST nodeTypes.list.

Tipo di nodo Processore vCPU GB vCPU:GB Socket Core:socket Core totali
c2-node-60-240 Lago Cascade 60 240 1:4 2 18 36
c3-node-176-352 Sapphire Rapids 176 352 1:2 2 48 96
c3-node-176-704 Sapphire Rapids 176 704 1:4 2 48 96
c3-node-176-1408 Sapphire Rapids 176 1408 1:8 2 48 96
c3d-node-360-708 AMD EPYC Genoa 360 708 1:2 2 96 192
c3d-node-360-1440 AMD EPYC Genoa 360 1440 1:4 2 96 192
c3d-node-360-2880 AMD EPYC Genoa 360 2880 1:8 2 96 192
g2-node-96-384 Lago Cascade 96 384 1:4 2 28 56
g2-node-96-432 Lago Cascade 96 432 1:4,5 2 28 56
h3-node-88-352 Sapphire Rapids 88 352 1:4 2 48 96
m1-node-96-1433 Skylake 96 1433 1:14,9 2 28 56
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88
m2-node-416-11776 Lago Cascade 416 11776 1:28,3 8 28 224
m3-node-128-1952 Lago ghiacciato 128 1952 1:15,25 2 36 72
m3-node-128-3904 Lago ghiacciato 128 3904 01:30,5 2 36 72
n1-node-96-624 Skylake 96 624 1:6,5 2 28 56
n2-node-80-640 Lago Cascade 80 640 1:8 2 24 48
n2-node-128-864 Lago ghiacciato 128 864 1:6,75 2 36 72
n2d-node-224-896 AMD EPYC Roma 224 896 1:4 2 64 128
n2d-node-224-1792 AMD EPYC Milan 224 1792 1:8 2 64 128

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

Tutti i nodi ti consentono di pianificare VM in forme diverse. Il tipo di nodo n sono nodi per uso generico su cui puoi pianificare VM di tipi di macchine personalizzate. Per suggerimenti sul tipo di nodo da scegliere, consulta Suggerimenti per i tipi di macchina. Per informazioni sulle prestazioni, consulta Piattaforme CPU.

Gruppi di nodi e provisioning delle VM

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

Un gruppo di nodi può avere zero o più nodi. Ad esempio, puoi ridurre a zero il numero di nodi in un gruppo di nodi quando non devi eseguire VM sui nodi nel gruppo oppure puoi abilitare il gestore della scalabilità automatica dei gruppi di nodi in modo da gestire automaticamente le dimensioni del gruppo di nodi.

Prima di eseguire il provisioning delle VM su 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 in esecuzione su tipi di macchina di varie dimensioni, purché il tipo di macchina abbia due o più vCPU.

Quando crei un gruppo di nodi, abilita la scalabilità automatica in modo che le dimensioni del gruppo si adattino automaticamente ai requisiti del carico di lavoro. Se i requisiti del carico di lavoro sono statici, puoi specificare manualmente la dimensione del gruppo di nodi.

Dopo aver creato un gruppo di nodi, puoi eseguire il provisioning delle VM sul gruppo o su un nodo specifico all'interno del gruppo. Per un ulteriore controllo, usa le etichette di affinità nodo per pianificare le VM su qualsiasi nodo con etichette di affinità corrispondenti.

Dopo aver eseguito il provisioning delle VM sui gruppi di nodi e facoltativamente assegnato le etichette di affinità per eseguire il provisioning delle VM su nodi o gruppi di nodi specifici, valuta la possibilità di etichettare le risorse per facilitare la gestione delle VM. Le etichette sono coppie chiave-valore che possono aiutarti a classificare le VM in modo da visualizzarle in forma aggregata per motivi come la fatturazione. Ad esempio, puoi utilizzare le etichette per contrassegnare il ruolo di una VM, la sua tenancy, il tipo di licenza o la sua posizione.

Criterio di manutenzione dell'host

A seconda degli scenari di licenza e dei carichi di lavoro, potrebbe essere opportuno limitare il numero di core fisici utilizzati dalle VM. Il criterio di manutenzione dell'host che scegli potrebbe dipendere, ad esempio, dai requisiti di licenza o conformità oppure da un criterio che ti consenta di limitare l'utilizzo dei server fisici. Con tutti questi criteri, le tue VM rimangono su hardware dedicato.

Quando pianifichi le VM su nodi single-tenant, puoi scegliere tra i tre diversi criteri di manutenzione dell'host riportati di seguito, che ti consentono di determinare se e come Compute Engine esegui la migrazione live delle VM durante gli eventi host, che si verificano ogni 4-6 settimane circa. Durante la manutenzione, Compute Engine esegue la migrazione live, in gruppo, di tutte le VM sull'host in un nodo single-tenant diverso. Tuttavia, in alcuni casi, Compute Engine potrebbe suddividere le VM in gruppi più piccoli ed eseguire la migrazione live di ogni gruppo più piccolo di VM in nodi single-tenant separati.

Criterio di manutenzione dell'host predefinito

Questo è il criterio di manutenzione dell'host predefinito e le VM sui gruppi di nodi configurati con questo criterio seguono il comportamento tradizionale di manutenzione per le VM non single-tenant. Ciò significa che, a seconda dell'impostazione di manutenzione sull'host dell'host della VM, le VM eseguino la migrazione live su 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.

Questo criterio è più adatto alle licenze per utente o per dispositivo che richiedono la migrazione live durante gli eventi host. Questa impostazione non limita la migrazione delle VM all'interno di un pool fisso di server fisici ed è consigliata per carichi di lavoro generali senza requisiti dei server fisici e che non richiedono licenze esistenti.

Poiché le VM eseguono la migrazione live su qualsiasi server senza considerare l'affinità dei server esistenti con questo criterio, questo criterio non è adatto per scenari che richiedono di ridurre al minimo l'uso dei core fisici durante gli eventi host.

La figura seguente mostra un'animazione del criterio di manutenzione dell'host predefinito.

Animazione del criterio di manutenzione dell'host predefinito.
Figura 2: animazione del criterio di manutenzione dell'host predefinito.

Criterio di manutenzione dell'host di riavvio in loco

Quando utilizzi questo criterio di manutenzione dell'host, Compute Engine arresta le VM durante gli eventi host e quindi riavvia le VM sullo stesso server fisico dopo l'evento host. Quando utilizzi questo criterio, devi configurare l'impostazione di manutenzione della VM sull'host su TERMINATE.

Questo criterio è più adatto per i carichi di lavoro a tolleranza di errore e che possono verificarsi circa un'ora di tempo di inattività durante gli eventi host, i carichi di lavoro che devono rimanere sullo stesso server fisico, i carichi di lavoro che non richiedono la migrazione live oppure se disponi di licenze basate sul numero di core o processori fisici.

Con questo criterio, 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 del criterio di manutenzione Riavvio in corso.

Animazione del criterio di manutenzione dell'host di riavvio in loco
Figura 3: animazione del criterio di manutenzione dell'host Riavvio in loco.

Esegui la migrazione all'interno del criterio di manutenzione dell'host del gruppo di nodi

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

Questo criterio è più adatto per carichi di lavoro ad alta disponibilità con licenze basate sul numero di core o processori fisici, perché con questo criterio di manutenzione dell'host, ogni nodo single-tenant del gruppo è bloccato a un insieme fisso di server fisici, diverso dal criterio predefinito che consente alle VM di eseguire la migrazione su qualsiasi server.

Per garantire la capacità per la migrazione live, Compute Engine prenota 1 nodo di isolamento ogni 20 nodi prenotati. La seguente tabella mostra il numero di nodi di holdback prenotabili da Compute Engine in base al numero di nodi prenotati per il gruppo di nodi.

Nodi totali nel gruppo Nodi di holdback riservati 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

Con questo criterio, ogni istanza deve avere come target un singolo gruppo di nodi utilizzando l'etichetta di affinità node-group-name e non può essere assegnata a nessun nodo specifico node-name. Questa operazione è necessaria per consentire a Compute Engine di eseguire in tempo reale la migrazione delle VM al nodo di isolamento in caso di evento host. Tieni presente che le VM possono utilizzare qualsiasi etichetta di affinità dei nodi personalizzata, purché venga assegnata la node-group-name e non la node-name.

La figura seguente mostra un'animazione del criterio di manutenzione dell'host Esegui la migrazione all'interno del gruppo di nodi.

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

Periodi di manutenzione

Se gestisci carichi di lavoro, ad esempio database finemente ottimizzati, che potrebbero essere sensibili all'impatto della migrazione live sulle prestazioni, puoi determinare quando inizia la manutenzione su un gruppo di nodi single-tenant specificando un periodo di manutenzione quando crei il gruppo di nodi. Non puoi modificare il periodo di manutenzione dopo aver creato il gruppo di nodi.

I periodi di manutenzione sono blocchi di 4 ore che puoi utilizzare per specificare quando Google esegue la manutenzione sulle 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 nel gruppo di nodi single-tenant e specifica solo quando inizia la manutenzione. Non è garantito che la manutenzione venga completata durante il periodo di manutenzione e la frequenza con cui viene eseguita questa operazione. I periodi di manutenzione non sono supportati per i gruppi di nodi con il criterio di manutenzione dell'host Esegui la migrazione all'interno del gruppo di nodi.

Simulare un evento di manutenzione dell'host

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

Errori relativi all'host

Quando si verifica un errore hardware critico raro nell'host, single-tenant o multi-tenant, Compute Engine esegue quanto segue:

  1. Ritira il server fisico e il suo 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 univoco.

  4. Sposta le VM dall'hardware in errore 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 tue VM non condividano l'host con le VM di altri progetti, a meno che non utilizzi gruppi di nodi single-tenant condivisi. Nel caso di 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 diversi carichi di lavoro sullo stesso nodo single-tenant o isolare i carichi di lavoro l'uno dall'altro su nodi diversi. Ad esempio, per soddisfare alcuni requisiti di conformità, potresti dover utilizzare le etichette di affinità per separare i carichi di lavoro sensibili da quelli non sensibili.

Quando crei una VM, richiedi la single-tenancy specificando l'affinità o l'antiaffinità dei nodi, facendo riferimento a una o più etichette di affinità dei nodi. Puoi specificare le etichette di affinità dei nodi personalizzate quando crei un modello di nodo e Compute Engine include automaticamente alcune etichette di affinità predefinite su ciascun nodo. Specificando l'affinità quando crei una VM, puoi pianificare le VM insieme su uno o più nodi specifici in un gruppo di nodi. Specificando l'anti-affinità quando crei una VM, puoi assicurarti che alcune VM non vengano pianificate insieme sullo stesso nodo o sugli stessi nodi in un gruppo di nodi.

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

  • Controlla il modo in cui le singole istanze VM vengono assegnate ai nodi.
  • Controlla il modo in cui le istanze VM create da un modello, come quelle create da un gruppo di istanze gestite, vengono assegnate ai nodi.
  • Raggruppa le istanze VM sensibili su nodi o gruppi di nodi specifici, separate dalle altre VM.

Etichette di affinità predefinite

Compute Engine assegna le seguenti etichette di affinità predefinite a ciascun nodo:

  • Un'etichetta per il nome del gruppo di nodi:
    • Chiave: compute.googleapis.com/node-group-name
    • Valore: 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: l'ID progetto del progetto contenente il gruppo di nodi.

Etichette di affinità personalizzata

Puoi creare etichette di affinità nodo personalizzate quando crei un modello di nodo. Queste etichette di affinità vengono assegnate a tutti i nodi nei gruppi di nodi creati dal modello di nodi. Non puoi aggiungere altre etichette di affinità personalizzata ai nodi in un gruppo di nodi dopo aver creato il gruppo di nodi.

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 offre sconti per impegno di utilizzo e sconti per utilizzo sostenuto. Inoltre, poiché ti vengono già addebitati i costi per le vCPU e la memoria dei tuoi nodi single-tenant, non paghi i costi aggiuntivi per le VM sui tuoi nodi single-tenant.

  • Se esegui il provisioning di nodi single-tenant con GPU o SSD locali, ti viene addebitato il costo di tutte le GPU o SSD locali su ciascun nodo di cui esegui il provisioning. Il premium per single-tenancy non si applica a GPU o SSD locali.

Disponibilità

  • I nodi single-tenant sono disponibili in zone selezionate. Per garantire l'alta disponibilità, pianifica le VM su nodi single-tenant in zone diverse.

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

  • Compute Engine supporta le GPU su tipi di nodi single-tenant n1 e g2 che si trovano in zone con supporto GPU. La tabella seguente mostra i tipi di GPU che puoi collegare ai nodi n1 e g2 e il numero di GPU che devi collegare quando crei il modello 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 SSD locali sui tipi di nodi single-tenant n1, n2, n2d e g2 che si trovano in zone con supporto SSD locale.

Limitazioni

  • I nodi single-tenant C3 e C3D non supportano l'overcommit delle CPU.

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

  • Non puoi aggiornare il criterio di manutenzione in un gruppo di nodi attivo.

Configurazioni di VM supportate da nodi single-tenant M3

La modalità single-tenancy supporta le seguenti configurazioni VM per i nodi single-tenant M3:

  • Su un nodo m3-node-128-3904, la modalità single-tenancy supporta le seguenti configurazioni VM:

    • 1 x m3-ultramem-128
    • 2 x m3-ultramem-64
    • 1 x m3-megamem-128
    • 2 x m3-megamem-64

    Se vuoi eseguire m3-ultramem-32 istanze VM, puoi farlo nelle seguenti configurazioni:

    • 1 x m3-ultramem-64 (o 1 x m3-megamem-64) + 1 x m3-ultramem-32
    • 2 x m3-ultramem-32

  • Su un nodo m3-node-128-1952, la modalità single-tenancy supporta le seguenti configurazioni VM:

    • 2 x m3-ultramem-32
    • 1 x m3-megamem-128
    • 2 x m3-megamem-64

    Se vuoi eseguire m3-ultramem-32 istanze VM, puoi farlo nelle seguenti configurazioni:

    • 1 x m3-megamem-64 + 1 x m3-ultramem-32
    • 2 x m3-ultramem-32

Passaggi successivi