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 e tipos de nós

Um modelo de nó é um recurso regional que define as propriedades de cada nó em um grupo. Todas as propriedades definidas no modelo de nó são copiadas sem alterações para cada nó em um grupo criado com base no modelo. Ao criar um modelo de nó, especifique um tipo e, se quiser, os rótulos de afinidade do nó. Só é possível especificar rótulos de afinidade em um modelo de nó. Não é possível especificar esses rótulos em um grupo.

O tipo de nó de locatário individual, que você precisa especificar para cada modelo de nó, especifica a quantidade total de núcleos de vCPU e memória para esse nó específico. Por exemplo, o tipo de nó n1-node-96-624 tem 96 vCPUs e 624 GB de memória. Nós desse tipo podem acomodar VMs em execução em tipos de máquina com até 96 vCPUs e 624 GB de memória. Um tipo de nó se aplica a cada nó individual em um grupo, não ao grupo como um todo. Portanto, se você criar um grupo com dois nós do tipo n1-node-96-624, cada nó receberá 96 vCPUs e 624 GB de memória.

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

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