Nós de locatário individual


Nesta página, descrevemos os nós de locatário individual. Para informações sobre como provisionar VMs em nós de locatário individual, consulte este documento.

O locatário individual permite que você tenha acesso exclusivo a um nó de locatário individual, que é um servidor físico do Compute Engine dedicado a hospedar apenas as VMs do projeto. Use nós de locatário individual para manter suas VMs fisicamente separadas das VMs de outros projetos ou para agrupá-las no mesmo hardware host, conforme mostrado no diagrama a seguir.

As VMs executadas em nós de locatário individual podem usar os mesmos recursos do Compute Engine que outras VMs, incluindo programação transparente e armazenamento em blocos, mas com uma camada extra de isolamento de hardware. Para que você tenha controle total sobre as VMs no servidor físico, cada nó de locatário individual tem um mapeamento de um para um em relação ao servidor físico que está fazendo backup do nó.

O locatário individual é apropriado para tipos específicos de cargas de trabalho. Por exemplo, cargas de trabalho de jogos com requisitos de desempenho se beneficiam porque estão separadas no próprio hardware. Já as cargas de trabalho de finanças ou saúde podem exigir segurança e conformidade, enquanto as cargas de trabalho do Windows podem exigir licenciamento.

Em um nó de locatário individual, é possível provisionar várias VMs em tipos de máquina de vários tamanhos, o que permite usar os recursos do hardware de base do host dedicado. Além disso, como você não está compartilhando o hardware host com outros projetos, é possível atender aos requisitos de segurança ou conformidade usando cargas de trabalho que exigem isolamento físico de outras cargas de trabalho ou VMs. Caso a carga de trabalho exija uma locação única apenas temporariamente, modifique a locação de VM conforme necessário.

Os nós de locatário individual podem ajudar você a atender aos requisitos de hardware dedicados para cenários de licenças adquiridas pelo usuário (BYOL) que exigem licenças por núcleo ou por processador. Ao usar nós de locatário individual, você tem alguma visibilidade sobre o hardware de base, o que permite acompanhar o uso do núcleo e do processador. Para acompanhar esse uso, o Compute Engine informa o ID do servidor físico em que uma VM está programada. Em seguida, é possível usar o Cloud Logging para ver o histórico de uso do servidor de uma VM. Para otimizar o uso do hardware host, é possível comprometer as CPUs da VM de locatário individual.

Por meio de uma política de manutenção configurável, os nós de locatário individual permitem controlar o comportamento de VMs durante eventos de manutenção do host. A política de manutenção permite especificar se as VMs provisionadas em nós de locatário individual mantêm a afinidade com um servidor físico específico ou se as VMs são movidas dentro de um grupo fixo de servidores físicos.

Modelos de nó

Um modelo de nó é um recurso regional que define as propriedades de cada nó em um grupo de nós. Ao criar um grupo de nós a partir de um modelo, as propriedades desse modelo serão copiadas sem alterações para cada nó do grupo.

Ao criar um modelo de nó, especifique um tipo de nó e, se preferir, os rótulos de afinidade do nó. Só é possível especificar rótulos de afinidade em um modelo de nó, ou seja, não é possível especificar esses rótulos em um grupo.

Tipos de nós

Ao configurar um modelo de nó, especifique um tipo de nó para aplicar a todos os nós presentes em um grupo criado com base nesse modelo. O tipo de nó de locatário individual, referenciado pelo modelo de nó, especifica a quantidade total de núcleos de vCPU e memória para nós criados em grupos de nós que usam esse modelo. Por exemplo, o tipo de nó n2-node-80-640 tem 80 vCPUs e 640 GB de memória. Os nós desse tipo podem acomodar várias VMs de formas variadas, cada uma sendo executada em tipos de máquina potencialmente diferentes, até que o total das formas de VM exceda a capacidade do nó.

Ao criar um grupo de nós usando um modelo, cada nó do grupo herda as especificações de tipo de nó desse modelo. Um tipo de nó se aplica a cada nó individual em um grupo de nós, não a todos os nós do grupo de maneira uniforme. Portanto, se você criar um grupo de nós com dois nós do tipo n2-node-80-640, cada um deles receberá 80 vCPUs e 640 GB de memória.

Dependendo dos requisitos de carga de trabalho, é possível preencher o nó com várias VMs menores executadas em tipos de máquina de vários tamanhos, incluindo tipos de máquina predefinidos, tipos de máquina personalizados e tipos de máquina com memória estendida. Quando um nó está cheio, não é possível programar mais instâncias nele.

A tabela a seguir mostra todos os tipos de nó disponíveis. Para ver uma lista dos tipos de nó disponíveis no projeto, execute o comando gcloud compute sole-tenancy node-types list ou a solicitação REST nodeTypes.list. Para informações sobre os preços desses tipos de nó, consulte Preços de nó de locatário individual.

Tipo de nó Processador vCPU GB vCPU:GB Soquetes Núcleos:soquete Total de núcleos
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36
m1-node-96-1433 Skylake 96 1433 1:14.9 2 28 56
n1-node-96-624 Skylake 96 624 1:6.5 2 28 56
n2-node-80-640 Cascade Lake 80 640 1:8 2 24 48
n2d-node-224-896 AMD EPYC Rome 224 896 1:4 2 64 128

Todos os nós permitem programar VMs com formas diferentes. Os nós do tipo n são nós de uso geral, em que é possível programar instâncias de tipo de máquina personalizado. Para ver recomendações sobre qual tipo de nó escolher, consulte Recomendações para tipos de máquina. Para informações sobre desempenho, consulte Plataformas de CPU.

Pode haver momentos em que o Compute Engine substitui um tipo de nó mais antigo por um mais novo. Se o Compute Engine substituir um tipo de nó, não será possível criar outros grupos com base em modelos que especificam o tipo de nó substituído. Quando o Compute Engine substitui um tipo de nó, analise e modifique os modelos de nó atuais que especificam o tipo indisponível.

Grupos de nós e provisionamento de VM

Os modelos de nó de locatário individual definem as propriedades de um grupo de nós, então é necessário criar um modelo de nó antes de criar um grupo em uma zona do Google Cloud. Ao criar um grupo, especifique a política de manutenção para instâncias de VM no grupo de nós e o número de nós desse grupo. Um grupo pode ter zero ou mais nós. Por exemplo, o número de nós em um grupo poderá ser reduzido para zero quando não for necessário executar nenhuma instância de VM nos nós do grupo. Além disso, o escalonador automático do grupo de nós pode ser ativado para gerenciar o tamanho do grupo de nós automaticamente.

Antes de provisionar VMs em nós de locatário individual, crie um grupo desse tipo. Um grupo de nós é um conjunto homogêneo de nós de locatário individual em uma zona específica. Grupos de nós podem conter várias VMs em execução em tipos de máquina de vários tamanhos, contanto que o tipo de máquina tenha duas ou mais vCPUs.

Ao criar um grupo de nós, ative o escalonamento automático para que o tamanho do grupo seja ajustado automaticamente e atenda aos requisitos da carga de trabalho. Se os requisitos de carga de trabalho forem estáticos, especifique o tamanho do grupo de nós manualmente.

Depois de criar um grupo de nós, é possível provisionar VMs no grupo ou em um nó específico dentro do grupo. Para ter mais controle, use rótulos de afinidade de nó para programar VMs em qualquer nó com rótulos de afinidade correspondentes.

Depois de provisionar VMs em grupos de nós e, como opção, atribuir rótulos de afinidade para provisionar VMs em grupos ou nós específicos, considere rotular recursos para ajudar a gerenciar as VMs. Os rótulos são pares de chave-valor que podem ajudar a categorizar VMs. Assim, você consegue visualizá-las de forma agregada para fins de faturamento, por exemplo. Os rótulos podem ser usados para marcar o papel de uma VM, o locatário, o tipo de licença ou o local.

Políticas de manutenção

Dependendo dos cenários de licenciamento e das cargas de trabalho, convém limitar o número de núcleos físicos usados pelas VMs. A política de manutenção escolhida pode depender, por exemplo, dos requisitos de licenciamento ou conformidade. Ou talvez você prefira uma política que permita limitar o uso de servidores físicos. Com todas essas políticas, as VMs permanecem em hardware dedicado.

Ao programar VMs em nós de locatário individual, é possível escolher uma das três políticas de manutenção a seguir. Elas permitem determinar como e se o Compute Engine faz migrações de VMs em tempo real durante eventos de manutenção do host, que ocorrem aproximadamente a cada quatro a seis semanas. Durante a manutenção, o Compute Engine migra em tempo real, como um grupo, todas as VMs no host para um nó de locatário individual diferente. Em alguns casos, porém, o Compute Engine pode dividir as VMs em grupos menores e migrar cada um deles para separar nós de locatário individual.

  • Padrão: essa é a política de manutenção padrão, e as VMs em grupos de nós configurados com essa política seguem o comportamento de manutenção tradicional das VMs que não são de locatário individual. Ou seja, dependendo da configuração de manutenção do host da VM, as VMs migram em tempo real para um novo nó de locatário individual antes de um evento de manutenção de host. Esse novo nó de locatário individual executará apenas as VMs do cliente. Além disso:

    • Essa política é mais adequada para licenças por usuário ou por dispositivo que exigem migração em tempo real durante eventos de manutenção. Essa configuração não restringe a migração de VMs para um pool fixo de servidores físicos, e é recomendada para cargas de trabalho gerais que não exigem servidores físicos e licenças atuais.

    • Como as VMs migram em tempo real para qualquer servidor sem considerar a afinidade do servidor atual com essa política, ela não é adequada para cenários que exigem minimização do uso de núcleos físicos durante eventos de manutenção.

  • Reinicialização no local: ao usar essa política de manutenção, o Compute Engine encerra as VMs durante os eventos de manutenção e, reinicia no mesmo servidor físico após o evento. Ao usar essa política, você precisa definir as configurações de manutenção do host da VM para serem TERMINATE. Além disso:

    • Essa política é mais adequada para cargas de trabalho tolerantes a falhas e que podem apresentar aproximadamente uma hora de inatividade durante eventos de manutenção do host, cargas de trabalho que precisam permanecer no mesmo servidor físico e cargas de trabalho que não exigem migração em tempo real. Ela também é adequada para quem tem licenças com base no número de núcleos físicos ou processadores.

    • Com essa política, a instância precisa receber apenas o rótulo de afinidade node-group-name, que pode ser especificado diretamente ou programando a VM no grupo de nós usando o nome desse grupo.

  • Migração dentro do grupo de nós: ao usar essa política de manutenção, o Compute Engine faz a migração em tempo real de VMs em um grupo de servidores físicos de tamanho fixo durante eventos de manutenção, o que ajuda a limitar o número de servidores físicos exclusivos usados pelas VMs. Além disso:

    • Essa política é mais adequada para cargas de trabalho de alta disponibilidade com licenças baseadas no número de núcleos ou processadores físicos, já que com essa política de manutenção cada nó de locatário individual no grupo é fixado em um conjunto fixo de servidores físicos. Isso é diferente da política padrão, que permite às VMs migrarem para qualquer servidor.

    • Para garantir a capacidade de migração em tempo real, o Compute Engine reserva 1 nó a cada 20 nós provisionados.

    • Com essa política, a instância precisa receber apenas o rótulo de afinidade node-group-name, que pode ser especificado diretamente ou programando a VM no grupo de nós usando o nome desse grupo.

Manutenção não planejada

No caso raro de uma falha crítica de hardware, o Compute Engine adota estas medidas:

  1. desativa o servidor físico e seu identificador exclusivo;

  2. revoga o acesso do projeto ao servidor físico;

  3. substitui o hardware com falha por um novo servidor físico que tem um novo identificador exclusivo;

  4. migra as VMs do hardware com falha para o nó substituto;

  5. reinicia as VMs afetadas se você as configurou para reiniciar automaticamente.

Afinidade e antiafinidade de nós

Os nós de locatário individual garantem que as VMs não compartilhem hardware de host com VMs de outros projetos. No entanto, é possível agrupar várias cargas de trabalho no mesmo nó de locatário individual ou isolar cargas de trabalho em nós diferentes. Por exemplo, para ajudar a cumprir alguns requisitos de conformidade, talvez seja necessário usar rótulos de afinidade para separar cargas de trabalho confidenciais de cargas de trabalho não confidenciais.

Ao criar uma VM, você solicita o locatário individual especificando a afinidade ou antiafinidade do nó, referenciando um ou mais rótulos de afinidade de nó. Ao criar um modelo de nó, você especifica rótulos de afinidade personalizados. O Compute Engine inclui automaticamente alguns rótulos de afinidade padrão em cada nó. Ao especificar a afinidade durante a criação de uma VM, é possível programar VMs em um nó específico ou em um grupo de nós. Ao especificar a antiafinidade no momento de criação de uma VM, você garante que determinadas VMs não sejam programadas juntas no mesmo nó ou em um grupo de nós.

Os rótulos de afinidade de nó são pares de chave-valor atribuídos a nós e são herdados de um modelo de nó. Os rótulos de afinidade permitem:

  • controlar como as instâncias de VM individuais são atribuídas aos nós;
  • controlar como são atribuídas a nós as instâncias de VM criadas com base em um modelo, como as criadas por um grupo de instâncias gerenciadas;
  • agrupar instâncias de VM confidenciais em nós ou grupos de nós específicos, separadas de outras VMs.

Rótulos de afinidade padrão

O Compute Engine atribui dois rótulos de afinidade padrão a cada nó:

  • Um rótulo para o nome do grupo de nós:
    • Chave: compute.googleapis.com/node-group-name
    • Valor: nome do grupo de nós
  • Um rótulo para o nome do nó:
    • Chave: compute.googleapis.com/node-name
    • Valor: nome do nó individual

Rótulos de afinidade personalizados

É possível criar rótulos de afinidade de nó personalizados no momento da criação de um modelo de nó. Esses rótulos de afinidade são atribuídos a todos os nós dos grupos criados com base nesse modelo. Não é possível adicionar mais rótulos de afinidade personalizados a nós em um grupo após ele ser criado.

Para informações sobre como usar rótulos de afinidade, consulte Como configurar a afinidade de nó.

Preços

Para ajudar a minimizar o custo de nós de locatário individual, o Compute Engine oferece descontos por uso contínuo e por uso prolongado. Além disso, como a vCPU e a memória dos nós de locatário individual já são cobradas, você não paga mais pelas VMs nos nós de locatário individual.

Disponibilidade

Os nós de locatário individual estão disponíveis em zonas selecionadas. Para garantir alta disponibilidade, programe VMs em nós de locatário individual em diferentes zonas.

Restrições

A seguir