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-os para fazer a separação física das VMs em outros projetos ou agrupá-las no mesmo hardware de host. 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 um locatário único apenas temporariamente, modifique a locação de VM conforme necessário.

Os nós de locatário individual podem atender aos requisitos de hardware dedicados para cenários de traga sua própria licença (BYOL) que exigem licenças por núcleo ou por processador. Ao usar nós de locatário individual, você tem um pouco de 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 uso histórico do servidor de uma VM.

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 node

Um modelo de nó é um recurso regional que define as propriedades de cada nó em um grupo de nós. Quando você cria um grupo de nós a partir de um modelo de nó, as propriedades dele são copiadas para cada nó do grupo.

Ao criar um modelo de nó, especifique um tipo e, se quiser, os rótulos de afinidade dos nós. Só é possível especificar rótulos de afinidade em um modelo de nó. Não é possível especificar esses rótulos em um grupo de nós.

Tipos de nós

Ao configurar um modelo de nó, especifique um tipo de nó para aplicar a todos os nós em um grupo criado com base no modelo de nó. 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 dos nós criados em grupos 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 diversas VMs de formas variadas, cada uma sendo executada em tipos de máquina potencialmente diferentes, até que o total de formas de VM ultrapasse a capacidade do nó.

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

Dependendo dos requisitos de carga de trabalho, também é possível preencher o nó com várias VMs menores em execução em tipos de máquina de tamanhos variados, 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 em seu 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ó Processor vCPU GB vCPU:GB Sockets 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
n1-node-96-1433 Skylake 96 1433 1:14.9 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 de diferentes formas. Os nós n são nós de uso geral, nos quais é 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

Para lidar com diferentes requisitos de carga de trabalho, especifique uma política de manutenção de VMs ao criar um grupo de nós. A política de manutenção de nós de locatário individual permite configurar como e se as VMs dos grupos de nós são migradas após um evento de manutenção. A política de manutenção escolhida pode depender, por exemplo, dos seus requisitos de licenciamento ou conformidade, ou ainda de uma configuração que permita limitar o uso de servidores físicos. Com todas essas políticas de manutenção, as VMs permanecem em hardware dedicado. A lista a seguir descreve essas políticas de manutenção:

  • Padrão: VMs em grupos de nós configurados com esta política seguem o comportamento de manutenção tradicional para VMs 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. Essa configuração não restringe a migração de VMs para um conjunto fixo de servidores físicos e é recomendada para cargas de trabalho gerais que não exijam servidor físico nem licenças atuais.

  • Reiniciar no local: após um evento de manutenção, as VMs são encerradas e reiniciadas no mesmo host físico. Considere usar essa política caso suas cargas de trabalho não exijam migração em tempo real, possam tolerar aproximadamente uma hora de inatividade a cada quatro ou seis semanas para um evento de manutenção de host e caso suas VMs precisem manter uma afinidade de servidor físico com um único host.

  • Migrar dentro do grupo de nós: dependendo da configuração de manutenção do host da VM, as VMs são migradas para outro nó no grupo antes de um evento de manutenção do host. Ao contrário da configuração padrão, essas migrações ocorrem em um conjunto fixo de servidores físicos para ajudar a limitar o número de servidores físicos exclusivos usados pela VM. Para garantir que haja capacidade suficiente para migrar VMs, o Compute Engine reserva um nó para cada 20 nós de locatário individual. Considere usar essa política se você precisa migrar cargas de trabalho em tempo real porque elas não toleram inatividade, se tem cargas de trabalho com requisito de licenciamento baseado no processador e se quer provisionar mais nós de locatário individual.

Falha de hardware

É raro um servidor passar por uma falha grave de hardware. Se isso acontecer, o Compute Engine desativará o servidor físico e o identificador exclusivo dele, revogará o acesso ao servidor físico, atribuirá um nó de substituição com um novo identificador exclusivo e transferirá as VMs para o nó de substituição. Dependendo da configuração dos nós de locatário individual, o Compute Engine poderá reiniciar suas VMs.

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