Panoramica single-tenancy

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

Single-tenancy ti consente di avere l'accesso esclusivo a un nodo single-tenant, ovvero un server Compute Engine fisico dedicato esclusivamente all'hosting alle VM del progetto. Utilizza i nodi single-tenant per mantenere le tue VM fisicamente separate VM in altri progetti o per raggruppare le 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.

Confronto tra 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 lo stesso Compute Engine le stesse caratteristiche delle altre VM, tra cui la pianificazione trasparente e l'archiviazione a blocchi, con un ulteriore livello di isolamento hardware. per darti il controllo completo sulle VM sul server fisico, ciascun nodo single-tenant mantiene una mappatura one-to-one il server fisico su cui si basa il nodo.

All'interno di un nodo single-tenant, puoi eseguire il provisioning di più VM su tipi di macchina di varie dimensioni, consentendoti di utilizzare in modo efficiente le risorse sottostanti dell'hardware host dedicato. Inoltre, se scegli di non condividere l'host l'hardware con altri progetti, puoi soddisfare i requisiti di sicurezza o conformità con 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 VM della tenancy secondo le necessità.

I nodi single-tenant possono aiutarti a soddisfare i requisiti hardware dedicati per portare la tua licenza (BYOL) che richiedono licenze per core o per processore. Quando utilizzi nodi single-tenant, hai una certa visibilità sull'hardware sottostante, consente di tenere traccia dell'uso di core e processori. Per monitorare questo utilizzo, Compute Engine segnala l'ID del server fisico su cui viene generata una VM in fase di pianificazione. Quindi, utilizzando Cloud Logging, puoi visualizzare il l'utilizzo storico di una VM da parte del server.

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

Tramite un criterio di manutenzione dell'host configurabile, puoi controllare il comportamento le VM single-tenant mentre il relativo host è in manutenzione. Puoi specificare quando la manutenzione e se le VM mantengono l'affinità con un server fisico o vengono spostati 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 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 di machine learning, elaborazione dei dati o rendering di immagini. Per questi carichi di lavoro standard, valuta la possibilità di prenotare GPU.

  • Carichi di lavoro che richiedono un aumento delle operazioni di I/O al secondo (IOPS) e di riduzione della 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, considera prenotando 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, delle proprietà del modello di nodo vengono copiate in modo immutabile su ciascun nodo del nodo gruppo.

Quando crei un modello di nodo, devi specificare un tipo di nodo. In via facoltativa, specificare le etichette di affinità dei nodi quando crei un modello di nodo. Puoi solo specificare le etichette di affinità dei nodi su un modello di nodo. Non puoi specificare l'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 di nodo. Il nodo single-tenant di nodo, a cui fa riferimento il modello di nodo, specifica la quantità totale di core vCPU e memoria per i nodi creati nei gruppi di nodi che utilizzano quel 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 delle il tipo di nodo specificato nel modello di nodo. Ad esempio, n2 I tipi di nodi single-tenant sono compatibili solo con le VM create con n2 tipo di macchina. Puoi aggiungere VM a un nodo single-tenant fino alla quantità totale di vCPU o memoria superano la capacità del nodo.

Quando crei un gruppo di nodi utilizzando un modello di nodo, ogni nodo nel gruppo di nodi eredita le specifiche del tipo di nodo del modello di nodo. Un tipo di nodo si applica 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 n2-node-80-640 di tipo di nodo, a ogni nodo sono allocate 80 vCPU e 640 GB di la memoria.

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

La seguente tabella mostra i tipi di nodi disponibili. Per visualizzare un elenco tipi di nodi disponibili per il tuo progetto, esegui gcloud compute sole-tenancy node-types list o il comando 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,93 2 28 56
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88
m2-node-416-8832 Lago Cascade 416 8832 01:21,23 8 28 224
m2-node-416-11776 Lago Cascade 416 11776 01:28,31 8 28 224
m3-node-128-1952 Lago di ghiaccio 128 1952 1:15,25 2 36 72
m3-node-128-3904 Lago di ghiaccio 128 3904 1: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 di ghiaccio 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 Nodo single-tenant pricing.

Tutti i nodi ti consentono di pianificare VM di forme diverse. Il tipo di nodo n è nodi per uso generico su cui puoi pianificare modelli di macchine di tipo VM. Per sui tipi di nodi da scegliere, consulta Consigli per tipi di macchine. Per informazioni sulle prestazioni, vedi Piattaforme CPU.

Gruppi di nodi e provisioning delle VM

I modelli di nodo single-tenant definiscono le proprietà di un gruppo di nodi e devi crea un modello di nodo prima di creare un gruppo di nodi in un ambiente Google Cloud zona di destinazione. Quando crei un gruppo, specifica il criterio di manutenzione dell'host per le VM sul 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 ridurre il numero di nodi in un gruppo di nodi a zero quando non è necessario eseguire alcuna VM nodi nel gruppo oppure puoi abilitare gestore della scalabilità automatica dei gruppi di nodi la dimensione del gruppo di nodi automaticamente.

Prima di eseguire il provisioning delle VM sui nodi single-tenant, devi creare un nodo single-tenant gruppo. Un gruppo di nodi è un insieme omogeneo di nodi single-tenant in uno specifico zona di destinazione. I gruppi di nodi possono contenere più VM in esecuzione tipi di macchine di varie dimensioni, purché ha due o più vCPU.

Quando crei un gruppo di nodi, abilita la scalabilità automatica in modo che le dimensioni del gruppo si adeguano automaticamente per il tuo carico di lavoro. Se i requisiti dei carichi di lavoro sono statici, puoi specificare la dimensione del gruppo di nodi.

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

Dopo aver eseguito il provisioning delle VM nei gruppi di nodi e aver assegnato l'affinità facoltativamente etichette per il provisioning delle VM su nodi o gruppi di nodi specifici, valuta la possibilità di etichettare le tue risorse per gestire più facilmente le VM. Le etichette sono coppie chiave-valore che possono aiutarti a classificare le VM in modo da possono visualizzarli 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 in ogni località.

Criterio di manutenzione dell'host

A seconda degli scenari di licenza e dei carichi di lavoro, potrebbe essere opportuno limitare le di core fisici utilizzati dalle VM. Il criterio di manutenzione dell'host che scegli può dipendere, ad esempio, dai requisiti di licenza o di conformità potresti voler scegliere un criterio che 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 fra tre diverse opzioni dei criteri di manutenzione dell'host, che ti consentono determinare come e se Compute Engine viene pubblicato esegue la migrazione delle VM durante l'host eventi, che si verificano ogni 4-6 settimane circa. Durante la manutenzione, Compute Engine esegue la migrazione live come gruppo di tutte le VM sull'host a un altro nodo single-tenant, ma in alcuni casi Compute Engine possono suddividere le VM in gruppi più piccoli ed eseguire la migrazione live di ogni gruppo più piccolo delle 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 segue il comportamento di manutenzione tradizionale per le VM non single-tenant. Vale a dire, a seconda della manutenzione sull'host Impostazione dell'host della VM, le VM migrano live in un nuovo nodo single-tenant nel gruppo di nodi prima di una 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 migrazione live durante gli eventi host. Questa impostazione non limita migrazione delle VM in un pool fisso di server fisici (opzione consigliata) per carichi di lavoro generici senza requisiti di server fisici e che non richiedono licenze esistenti.

Poiché le VM migrano in tempo reale su qualsiasi server senza considerare il server esistente affinità a questo criterio, questo criterio non è adatto agli scenari che richiedono minimizzazione dell'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 e poi riavvia le VM sullo stesso server fisico dopo l'evento organizzatore. Devi configurare l'impostazione di manutenzione dell'host per le VM su TERMINATE quando utilizzi questo criterio.

Questo criterio è più adatto per carichi di lavoro a tolleranza di errore e può avrà un tempo di inattività di circa un'ora durante gli eventi dell'organizzatore, che devono rimanere sullo stesso server fisico, carichi di lavoro che richiedono la migrazione live o se hai licenze basate sul numero di 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à nodo.

La figura seguente mostra un'animazione della manutenzione con Riavvio in corso .

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

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

Se utilizzi questo criterio 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 host, 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 che si basano sul numero di core o processori fisici, poiché con questo host criterio di manutenzione, ogni nodo single-tenant del gruppo è bloccato a un set fisso di server fisici, diverso dal criterio predefinito che consente alle VM eseguire la migrazione su qualsiasi server.

Per garantire la capacità per la migrazione live, Compute Engine ne riserva 1 di riserva per ogni 20 nodi prenoti. La tabella seguente mostra come nodi di riserva che Compute Engine riserva in base al numero nodi prenoti per il tuo gruppo di nodi.

Totale nodi nel gruppo Nodi di holdback riservati per la migrazione live
1 Non applicabile. È necessario 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 scegliere come target un singolo gruppo di nodi utilizzando il metodo node-group-name etichetta di affinità e non può essere assegnata a un nodo specifico node-name. Questa operazione è necessaria per consentire a Compute Engine di eseguire la migrazione live 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é vengano loro assegnate node-group-name e non node-name.

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

Animazione della migrazione all'interno di un criterio di manutenzione dell'host 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 sul rendimento dei contenuti dal vivo migrazione, puoi stabilire quando la manutenzione inizia su un gruppo di nodi single-tenant specificando un 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 intervalli di quattro ore che puoi utilizzare per specificare quando Google esegue la manutenzione dei tuoi delle 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. La manutenzione non è garantita durante il periodo di manutenzione e non possiamo garantire ma non è sempre necessario. I periodi di manutenzione non sono supportati su gruppi di nodi con il criterio 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 carichi di lavoro in esecuzione sui nodi single-tenant un evento di manutenzione dell'host. Puoi vedere gli effetti delle VM single-tenant il criterio di manutenzione dell'host sulle applicazioni in esecuzione sulle VM.

Errori relativi all'host

In caso di raro errore hardware critico sull'host ( single-tenant o multi-tenant: Compute Engine fa quanto segue:

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

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

  3. Sostituisce l'hardware in errore con un nuovo server fisico con un nuovo identificativo dell'utente.

  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 VM non condividano host con VM di altri a meno che non utilizzi gruppi di nodi single-tenant condivisi. Con gruppi di nodi single-tenant condivisi, mentre altri progetti all'interno dell'organizzazione possono eseguire il provisioning delle VM sullo stesso host. Tuttavia, potresti voler raggruppare più carichi di lavoro insieme un nodo single-tenant o isolano i carichi di lavoro l'uno dall'altro su nodi diversi. Ad esempio, per soddisfare alcuni requisiti di conformità, potrebbe essere necessario usare per separare i carichi di lavoro sensibili da quelli non sensibili.

Quando crei una VM, richiedi la single-tenancy specificando l'affinità dei nodi anti-affinità, con riferimento a una o più etichette di affinità nodo. Sei tu a specificare le impostazioni le etichette di affinità dei nodi quando crei un modello di nodo, e Compute Engine include automaticamente alcune etichette di affinità predefinite su ciascun nodo. Specificando affinità quando crei una VM, puoi pianificare insieme le VM su un nodo specifico o nodi in un gruppo di nodi. Specificando l'anti-affinità quando crei una VM, può garantire che determinate VM non siano pianificate insieme sullo stesso nodo o 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 il modo in cui le singole istanze VM vengono assegnate ai nodi.
  • Controlla il modo in cui le istanze VM vengono create da un modello, ad esempio quelle create da un di istanze gestite in base a un gruppo di istanze gestite.
  • Raggruppa le istanze VM sensibili su nodi o gruppi di nodi specifici, separati con altre VM.

Etichette di affinità predefinite

Compute Engine assegna le seguenti 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.
  • Un'etichetta per i progetti con cui è condiviso il gruppo di nodi:
    • Chiave: compute.googleapis.com/projects
    • Valore: ID progetto del progetto contenente il gruppo di nodi.

Etichette di affinità personalizzata

Puoi creare etichette di affinità del nodo personalizzate quando crei un nodo modello. Queste etichette di affinità vengono 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 nodo dopo la creazione del gruppo di nodi.

Per informazioni su come utilizzare le etichette di affinità, consulta Configurazione del nodo di affinità.

Prezzi

  • Per aiutarti a ridurre al minimo il costo del tuo single-tenant nodi, Compute Engine fornisce sconti per impegno di utilizzo e sconti per utilizzo sostenuto. Inoltre, perché ti vengono già fatturate le vCPU e la memoria del tuo single-tenant nodi, non paghi un 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 i costi tutte le GPU o gli SSD locali su ciascun nodo di cui esegui il provisioning. La Il premium single-tenancy non si applica a GPU o SSD locali.

Disponibilità

  • I nodi single-tenant sono disponibili solo in zone. Per garantire l'alta disponibilità, e pianificare VM su nodi single-tenant in zone diverse.

  • Prima di utilizzare GPU o SSD locali sui nodi single-tenant, assicurati di avere una quota GPU o SSD locale sufficiente nella zona in cui ti trovi per prenotare la risorsa.

  • Compute Engine supporta GPU su n1 e g2 nodo single-tenant che si trovano in zone con supporto GPU. La la seguente tabella mostra i tipi di GPU che puoi collegare a n1 e g2 nodi e quante GPU devi collegare quando crei il nodo modello.

    Tipo di GPU Quantità 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 gli SSD locali su n1, n2, n2d e g2 di tipi di nodi single-tenant che si trovano in zone con supporto SSD locali.

Limitazioni

  • I nodi single-tenant C3 e C3D non supportano le CPU in overcommitting.

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

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

Configurazioni di VM supportate dai nodi single-tenant M3

Il single-tenancy supporta le seguenti configurazioni di VM per i nodi single-tenant M3:

  • Su un nodo m3-node-128-3904, la modalità single-tenancy supporta quanto segue 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 in le 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 quanto segue 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 in le seguenti configurazioni:

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

Passaggi successivi