Nós de locatário individual


Neste documento, descrevemos 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.

Figura 1: um host de vários locatários e um nó de locatário individual.

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

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 certa visibilidade sobre o hardware de base, o que permite monitorar 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 do host, faça a alocação extra de CPUs da VM de locatário individual.

Com uma política de manutenção configurável, é possível controlar o comportamento de VMs de locatário individual enquanto o host está em manutenção. Você pode especificar quando a manutenção ocorre e se as VMs mantêm a afinidade com um servidor físico específico ou se são movidas para outros nós de locatário individual em um grupo de nós.

Considerações sobre carga de trabalho

Os tipos de cargas de trabalho a seguir podem se beneficiar com o uso de nós de locatário individual:

  • Cargas de trabalho de jogos com requisitos de desempenho.

  • Cargas de trabalho financeiras ou de saúde com requisitos de segurança e conformidade.

  • Cargas de trabalho do Windows com requisitos de licenciamento.

  • Cargas de trabalho de machine learning, processamento de dados ou renderização de imagens. Para essas cargas de trabalho, considere reservar GPUs.

  • Cargas de trabalho que exigem aumento de operações de entrada/saída por segundo (IOPS, na sigla em inglês) e redução de latência, ou cargas de trabalho que usam armazenamento temporário na forma de caches, espaço de processamento ou dados de baixo valor. Para essas cargas de trabalho, considere reservar SSDs locais.

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.

As VMs que você adicionar a um nó de locatário individual precisarão ter o mesmo tipo de máquina que você especificar no modelo de nó. Por exemplo, os tipos de nó de locatário individual n2 são compatíveis somente com VMs criadas com o tipo de máquina n2. É possível adicionar VMs a um nó de locatário individual até que a quantidade total de vCPUs ou de memória 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
m1-node-160-3844 Broadwell E7 160 3.844 1:24 4 22 88
m2-node-416-11776 Skylake 416 11.776 1:28.3 8 28 224
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 de diferentes formas. 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.

Política de manutenção padrão

As VMs em grupos de nós configurados com a política de manutenção padrão seguem o comportamento de manutenção tradicional das VMs que não são de locatário individual. Isso significa que, 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.

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

A figura a seguir mostra uma animação da política de manutenção Padrão.

Figura 2: animação da política de manutenção Padrão.

Política de manutenção Reinicialização no local

Ao usar esta política de manutenção, o Compute Engine interrompe as VMs durante os eventos de manutenção e as reinicia no mesmo servidor físico após o evento. Com esta política, você precisa definir as configurações de manutenção do host da VM para serem TERMINATE.

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 ou processadores físicos.

Com essa política, a instância pode ser atribuída ao grupo de nós usando node-name, node-group-name ou um rótulo de afinidade de nó.

A figura a seguir mostra uma animação da política de manutenção Reinicialização no local.

Figura 3: animação da política de manutenção Reinicialização no local.

Política de manutenção Migração dentro do grupo de nós

Ao usar essa política de manutenção, o Compute Engine migra em tempo real as VMs em um grupo de servidores físicos de tamanho fixo durante os eventos de manutenção, o que ajuda a limitar o número de servidores físicos exclusivos usados pela VM.

Esta 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 um nó de restrição para cada 20 nós reservados. A tabela a seguir mostra quantos nós de restrição são reservados pelo Compute Engine, dependendo de quantos nós você reserva para o grupo de nós.

Total de nós no grupo Nós de restrição reservados para migração em tempo real
1 Não relevante. É necessário reservar pelo menos dois nós.
2 a 20 1
21 a 40 2
41 a 60 3
61 a 80 4
81 a 100 5

Com essa política, cada instância precisa segmentar um único grupo de nós usando o rótulo de afinidade node-group-name e não pode ser atribuída a qualquer nó específico node-name. Isso é necessário para permitir que o Compute Engine migre em tempo real as VMs para o nó de restrição quando houver um evento de manutenção. Observe que as VMs podem usar qualquer rótulo de afinidade de nó personalizado, desde que recebam node-group-name e não o node-name.

A figura a seguir mostra uma animação da política de manutenção Migração dentro do grupo de nós.

Figura 4: animação da política de manutenção Migração dentro do grupo de nós.

Janelas de manutenção

Se você estiver gerenciando cargas de trabalho, por exemplo, bancos de dados ajustados, que podem ser sensíveis ao impacto no desempenho da migração em tempo real, é possível determinar quando a manutenção começa em um grupo de nós de locatário individual especificando uma janela de manutenção ao criar o grupo.

As janelas de manutenção são blocos de quatro horas que podem ser usados para especificar quando o Google realiza manutenção nas VMs de locatário individual. Os eventos de manutenção ocorrem aproximadamente uma vez a cada duas semanas. Depois de especificar uma janela de manutenção em um grupo de nós, não será possível modificá-la.

Essa janela de manutenção se aplica a todas as VMs no grupo de nós de locatário individual e só especifica quando a manutenção é iniciada. Não há garantia de que ela será concluída durante a janela de manutenção. Também não há garantias sobre a frequência de manutenção. As janelas de manutenção não são compatíveis em grupos de nós com a política de manutenção migrar dentro do grupo de nós.

Erros de host

Quando há uma falha crítica de hardware grave no host, locatário individual ou multilocatário, o Compute Engine faz o seguinte:

  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.

  • Se você provisionar nós de locatário individual com GPUs ou SSDs locais, será cobrado por todas as GPUs ou SSDs locais em cada nó provisionado. O acréscimo de locatário individual não se aplica a GPUs ou SSDs locais.

  • Se você reservar GPUs ou SSDs locais em um nó de locatário individual, você será cobrado por todas as GPUs ou SSDs locais em cada nó em que reservar o recurso.

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.

  • Antes de usar GPUs ou SSDs locais em nós de locatário individual, verifique se você tem cota de GPU ou SSD local suficiente na zona em que está reservando o recurso.

  • O Compute Engine é compatível com GPUs em tipos de nós de locatário individual do n1 que estejam em zonas compatíveis com GPU. A tabela a seguir mostra os tipos de GPUs que podem ser anexadas a nós n1 e quantas GPUs você precisa anexar ao criar o modelo de nó.

    Tipo de GPU Quantidade da GPU
    NVIDIA® P100 4
    NVIDIA® P4 4
    NVIDIA® T4 4
    NVIDIA® V100 8
  • O Compute Engine é compatível com SSDs locais nos tipos de nós de locatário individual n1, n2 e n2d que estejam em zonas compatíveis com SSD local.

Restrições

A seguir