Panoramica della modalità single-tenant

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento descrive i nodi single-tenant Per informazioni sul provisioning delle VM sui nodi single-tenant, consulta l'articolo Eseguire il provisioning delle VM sui nodi single-tenant.

La modalità single-tenant ti permette di accedere in modo esclusivo a un nodo single-tenant, ovvero un server fisico Compute Engine dedicato all'hosting di istanze VM soltanto per il tuo progetto. Utilizza i nodi single-tenant per mantenere le VM fisicamente separate dalle VM in altri progetti o per raggruppare le VM sullo stesso hardware host, come mostrato nel diagramma seguente.

Figura 1: host multi-tenant rispetto a un nodo single-tenant

Le VM in esecuzione su nodi single-tenant possono utilizzare le stesse funzionalità di Compute Engine delle altre VM, tra cui pianificazione trasparente e archiviazione a blocchi, ma con un ulteriore livello di isolamento hardware. Per darti il pieno controllo sulle VM sul server fisico, ogni nodo single-tenant mantiene una mappatura one-to-one al 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, poiché non stai condividendo 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 tuo carico di lavoro richiede una single-tenancy solo temporaneamente, puoi modificare la tenancy VM come necessario.

I nodi single-tenant possono aiutarti a soddisfare i requisiti hardware specifici per gli scenari BYOL (Bring Your Own License) che richiedono licenze per core o processore. I nodi single-tenant hanno una certa visibilità sull'hardware sottostante, che consente di monitorare l'utilizzo del core e del processore. 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 dell'host, puoi eseguire l'overovermit di CPU VM single-tenant, condividere gruppi di nodi single-tenant e eseguire la migrazione manuale delle VM.

Tramite un criterio di manutenzione host configurabile, puoi controllare il comportamento delle VM solo tenant in fase di manutenzione. Puoi specificare quando si verifica 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'uso dei nodi single-tenant:

  • Carichi di lavoro di gioco con requisiti di prestazioni.

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

  • Carichi di lavoro Windows con requisiti di licenza.

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

  • Carichi di lavoro che richiedono più operazioni di I/O al secondo e una latenza ridotta oppure carichi di lavoro che utilizzano spazio di archiviazione temporaneo in forma di cache, spazio di elaborazione o dati di scarso valore. Per questi carichi di lavoro, valuta la possibilità di prenotare le unità SSD locali.

Modelli di nodo

Un modello di nodo è una risorsa di area geografica 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à del modello di nodo vengono copiate in ogni nodo del gruppo.

Quando crei un modello di nodo, specifica un tipo di nodo e, facoltativamente, le etichette di affinità nodo. Puoi specificare etichette di affinità nodo in un modello di nodo, ma non in un gruppo di nodi.

Tipi di nodi

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 del nodo. Il tipo di nodo single-tenant, indicato dal modello di nodo, specifica la quantità totale di core vCPU e memoria per i nodi creati nei gruppi di nodi che utilizzano tale modello. Ad esempio, il tipo di nodo n2-node-80-640 ha 80 vCPU e 640 GB di memoria.

Le VM che aggiungi 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 del gruppo in modo uniforme. Quindi, se crei un gruppo di nodi con due nodi che sono entrambi del tipo n2-node-80-640, a ogni nodo vengono allocati 80 vCPU e 640 GB di memoria.

A seconda dei requisiti del tuo carico 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 istanze aggiuntive su quel nodo.

La tabella seguente mostra tutti 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. Per informazioni sui prezzi di questi tipi di nodi, consulta la pagina relativa ai prezzi dei nodi single-tenant.

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
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
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 di ghiaccio 128 864 1:6,75 2 36 72
n2d-node-224-896 AMD EPYC Roma 224 896 1:4 2 64 128

Tutti i nodi ti consentono di pianificare VM di forme diverse. I nodi di tipo n sono nodi di uso generico, in base ai quali è possibile pianificare istanze di tipi di macchine personalizzate. Per suggerimenti sul tipo di nodo da scegliere, consulta la sezione Consigli per i tipi di macchine. Per informazioni sulle prestazioni, consulta la sezione Piattaforme CPU.

Compute Engine potrebbe sostituire un tipo di nodo meno recente con un tipo di nodo più recente. Se Compute Engine sostituisce un tipo di nodo, non puoi creare ulteriori gruppi di nodi da modelli che specificano il tipo di nodo sostituito. Quando Compute Engine sostituisce un tipo di nodo, devi esaminare e modificare tutti i modelli di nodi esistenti che specificano il tipo di nodo non più disponibile.

Gruppi di nodi e provisioning delle VM

I modelli di nodi 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 istanze VM sul gruppo, il numero di nodi per il gruppo di nodi e se condividarlo con altri progetti o con l'intera organizzazione.

Un gruppo di nodi può avere zero o più nodi; ad esempio, puoi ridurre il numero di nodi in un gruppo di nodi a zero quando non hai bisogno di eseguire istanze VM sui nodi nel gruppo o puoi abilitare 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 in esecuzione su tipi di macchina di varie dimensioni, a condizione che il tipo di macchina abbia 2 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 tuo carico di lavoro. Se i requisiti del tuo carico di lavoro sono statici, puoi specificare manualmente le dimensioni del gruppo di nodi.

Dopo aver creato un gruppo di nodi, puoi eseguire il provisioning delle VM nel gruppo o in un nodo specifico all'interno del gruppo. Per un maggiore controllo, utilizza 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, se vuoi, di assegnare etichette di affinità per eseguire il provisioning delle VM su gruppi o nodi specifici, valuta l'opportunità di etichettare le risorse per gestire meglio le VM. Le etichette sono coppie chiave/valore utilizzabili per classificare le VM in modo da poterle visualizzare 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, potresti voler 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 potresti scegliere un criterio che ti consenta di limitare l'utilizzo dei server fisici. Con tutti questi criteri, le VM rimangono su hardware dedicato.

Quando pianifichi le VM su nodi single-tenant, puoi scegliere tra le tre opzioni seguenti di criteri di manutenzione dell'host, che ti consentono di determinare come e se Compute Engine esegue la migrazione live delle VM durante gli eventi host, che si verificano ogni 4-6 settimane circa. Durante la manutenzione, Compute Engine Live esegue la migrazione, come gruppo, a tutte le VM nell'host in un nodo single-tenant diverso, ma, in alcuni casi, Compute Engine può suddividere le VM in gruppi più piccoli ed eseguire la migrazione live di ogni gruppo più piccolo di VM a nodi single-tenant separati.

Criterio di manutenzione host predefinito

Questo è il criterio di manutenzione host predefinito e le VM sui gruppi di nodi configurati con questo criterio seguono il comportamento di manutenzione tradizionale per le VM non single-tenant. Ciò significa che a seconda dell'impostazione di manutenzione on-host dell'host della VM, le VM eseguino la migrazione in tempo reale a un nuovo nodo single-tenant nel gruppo di nodi prima di un evento di manutenzione dell'host. 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 a un pool fisso di server fisici ed è consigliata per i carichi di lavoro generali senza requisiti dei server fisici e che non richiedono licenze esistenti.

Poiché la migrazione delle VM a un server viene eseguita senza considerare l'affinità dei server esistente con questo criterio, questo criterio non è idoneo per gli scenari che richiedono la riduzione dell'utilizzo dei core fisici durante gli eventi host.

La figura seguente mostra un'animazione del criterio di impostazione predefinita Host.

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

Riavvia il criterio di manutenzione host in loco

Se utilizzi questo criterio di manutenzione dell'host, Compute Engine interrompe le VM durante gli eventi host e riavvia le VM sullo stesso server fisico dopo l'evento host. Devi impostare l'impostazione di manutenzione dell'host delle VM su TERMINATE quando utilizzi questo criterio.

Questo criterio è più adatto ai carichi di lavoro a tolleranza di errore e a circa un'ora 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 o le licenze basate sul numero di core fisici o processori.

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

La figura seguente mostra un'animazione del criterio di manutenzione Riavvia in loco.

Figura 3: Animazione del criterio di manutenzione dell'host Riavvia in posizione.

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 attiva la migrazione delle VM all'interno di un gruppo di server fisici con dimensioni fisse durante gli eventi host, il che consente di limitare il numero di server fisici univoci utilizzati dalla VM.

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

Per garantire la capacità per la migrazione live, Compute Engine riserva 1 nodo di holdback ogni 20 nodi prenotati. La tabella seguente mostra quanti nodi di holdback vengono prenotati 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. Deve 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. Questo è necessario per consentire a Compute Engine di eseguire la migrazione live delle VM al nodo holdback in caso di evento host. Tieni presente che le VM possono utilizzare qualsiasi etichetta di affinità nodo personalizzata, purché siano assegnate node-group-name e non node-name.

La figura seguente mostra un'animazione del criterio di manutenzione dell'host Esegui la migrazione all'interno del 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 ottimizzati, che potrebbero essere sensibili all'impatto sulle prestazioni della migrazione live, 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 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 nel gruppo di nodi single-tenant e specifica solo all'inizio della manutenzione. Non è garantito che la manutenzione venga completata durante il periodo di manutenzione e non vi è alcuna garanzia sulla frequenza della manutenzione. I periodi di manutenzione non sono supportati sui gruppi di nodi con il criterio di manutenzione dell'host Esegui migrazione all'interno del gruppo di nodi.

Errori host

In caso di errore critico sull'hardware nell'host, single-tenant o multi-tenant, Compute Engine esegue le seguenti operazioni:

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

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

  3. Sostituisce l'hardware in errore 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 avevi configurate in modo da riavviarle automaticamente.

Affinità nodo e anti-affinità

I nodi single-tenant assicurano che le VM non condividano l'hardware host con VM di altri progetti. 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 dai carichi di lavoro non sensibili.

Quando crei una VM, richiedi la modalità single-tenant specificando l'affinità o il nodo di affinità nodo, facendo riferimento a una o più etichette di affinità nodo. Specifica le etichette di affinità nodo personalizzata quando crei un modello di nodo e Compute Engine include automaticamente alcune etichette di affinità predefinite su ogni 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 siano programmate insieme sullo stesso nodo o sui nodi in un gruppo di nodi.

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

  • Controlla come vengono assegnate singole istanze VM ai nodi.
  • Controlla come vengono assegnate ai nodi le istanze VM create da un modello, ad esempio quelle create da un gruppo di istanze gestite.
  • Raggruppa le istanze VM sensibili su nodi o gruppi di nodi specifici, separati dalle altre VM.

Etichette di affinità predefinite

Compute Engine assegna due etichette di affinità predefinite a ogni 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.

Etichette di affinità personalizzata

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

Per informazioni su come utilizzare le etichette di affinità, consulta la sezione Configurare l'affinità nodo.

Prezzi

  • Per aiutarti a ridurre al minimo il costo dei tuoi nodi tenant, Compute Engine offre sconti per impegno di utilizzo e sconti per utilizzo sostenuto. Inoltre, dato che ti sono già addebitati i costi per la vCPU e la memoria dei tuoi nodi single-tenant, non paghi la tariffa extra per le VM sui tuoi nodi single-tenant.

  • Se esegui il provisioning di nodi single-tenant con GPU o SSD locali, ti verranno addebitati tutti i GPU o gli SSD locali su ciascun nodo di cui esegui il provisioning. Il premium per modalità single-tenant non si applica alle GPU o alle unità SSD locali.

  • Se prenoti GPU o SSD locali su un nodo single-tenant, ti verranno addebitate tutte le GPU o le SSD locali su ciascun nodo in cui prenoti la risorsa.

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 su nodi single-tenant, assicurati di disporre di una quota GPU o SSD locale sufficiente nella zona in cui intendi conservare la risorsa.

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

    Tipo di GPU Quantità GPU
    NVIDIA® P100 4
    NVIDIA® P4 4
    NVIDIA® T4 4
    NVIDIA® V100 8
  • Compute Engine supporta SSD locali su n1, n2 e n2d tipi di nodi single-tenant che si trovano in zone con supporto SSD locali.

Limitazioni

Passaggi successivi