Visão geral do locatário individual

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Este documento descreve nós de locatário individual. Para obter informações sobre como provisionar VMs em nós de locatário individual, consulte Provisionando VMs em nós de locatário individual .

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 seu projeto. Use nós de locatário individual para manter suas VMs fisicamente separadas das VMs de outros projetos ou para agrupar suas VMs no mesmo hardware host, conforme mostrado no diagrama a seguir. Você também pode criar um grupo de nós de locatário individual e especificar se deseja compartilhá-lo com outros projetos ou com toda a organização .

As VMs executadas em nós de locatário individual podem usar os mesmos recursos do Compute Engine que outras VMs, incluindo agendamento transparente e armazenamento em blocos, mas com uma camada adicional de isolamento de hardware. Para fornecer controle total sobre as VMs no servidor físico, cada nó de locatário individual mantém um mapeamento individual para o servidor físico que está apoiando o nó.

Dentro de um nó de locatário individual, você pode provisionar várias VMs em tipos de máquinas de vários tamanhos, o que permite usar com eficiência os recursos subjacentes do hardware host dedicado. Além disso, se você optar por não compartilhar o hardware host com outros projetos, poderá atender aos requisitos de segurança ou conformidade com cargas de trabalho que exigem isolamento físico de outras cargas de trabalho ou VMs. Se a sua carga de trabalho exigir locação individual apenas temporariamente, você poderá modificar a locação da VM conforme necessário.

Os nós de locatário individual podem ajudá-lo a 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 alguma visibilidade do hardware subjacente, o que permite rastrear o uso do núcleo e do processador. Para rastrear esse uso, o Compute Engine informa o ID do servidor físico no qual uma VM está programada. Depois, usando o Cloud Logging , você poderá visualizar o histórico de uso do servidor de uma VM .

Para otimizar o uso do hardware host, você pode fazer o seguinte:

• Alocação excessiva de CPUs em VMs de locatário individual

• Compartilhar grupos de nós de locatário individual

• Migrar manualmente VMs de locatário individual em tempo real

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

Considerações sobre carga de trabalho

Os seguintes tipos de cargas de trabalho podem se beneficiar do 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 aprendizado de máquina, processamento de dados ou renderização de imagens. Para essas cargas de trabalho, considere reservar GPUs .

• Cargas de trabalho que exigem operações de E/S por segundo (IOPS) aumentadas e latência reduzida 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ós

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 de nó, as propriedades do modelo de nó são copiadas de forma imutável para cada nó no grupo de nós.

Ao criar um modelo de nó, você deve especificar um tipo de nó. Opcionalmente, você pode especificar rótulos de afinidade de nó ao criar um modelo de nó. Você só pode especificar rótulos de afinidade de nó em um modelo de nó. Não é possível especificar rótulos de afinidade de nó 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 dentro de um grupo de nós 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 para nós criados em grupos de nós que usam esse modelo. Por exemplo, o tipo de nó n2-node-80-640 possui 80 vCPUs e 640 GB de memória.

As VMs que você adiciona a um nó de locatário individual devem ter o mesmo tipo de máquina que o tipo de nó especificado no modelo de nó. Por exemplo, os tipos de nós de locatário individual n2 são compatíveis apenas com VMs criadas com o tipo de máquina n2 . Você pode adicionar VMs a um nó de locatário individual até que a quantidade total de vCPUs ou memória exceda a capacidade do nó.

Ao criar um grupo de nós usando um modelo de nó, cada nó no grupo de nós herda as especificações de tipo de nó do modelo de nó. Um tipo de nó se aplica a cada nó individual dentro de um grupo de nós, e 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 que sejam do tipo n2-node-80-640 , cada nó receberá 80 vCPUs e 640 GB de memória.

Dependendo dos requisitos da sua carga de trabalho, você pode preencher o nó com diversas VMs menores executadas em tipos de máquinas de vários tamanhos, incluindo tipos de máquinas predefinidos , tipos de máquinas personalizados e tipos de máquinas com memória estendida . Quando um nó está cheio, não é possível agendar VMs adicionais nesse nó.

A tabela a seguir exibe os tipos de nós disponíveis. Para ver uma lista dos tipos de nós disponíveis para seu projeto, execute o comando gcloud compute sole-tenancy node-types list ou crie uma solicitação REST nodeTypes.list .

Para obter informações sobre os preços desses tipos de nós, consulte preços de nós de locatário individual .

Todos os nós permitem agendar VMs de diferentes formatos. Os nós do tipo n são nós de uso geral, nos quais você pode agendar instâncias personalizadas do tipo de máquina . Para obter recomendações sobre qual tipo de nó escolher, consulte Recomendações para tipos de máquinas . Para obter informações sobre desempenho, consulte Plataformas de CPU .

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, e você deve criar um modelo de nó antes de criar um grupo de nós em um Google Cloudzona. Ao criar um grupo, especifique a política de manutenção de host para VMs no grupo de nós, o número de nós do grupo de nós e se deseja compartilhá-lo com outros projetos ou com toda a organização .

Um grupo de nós pode ter zero ou mais nós; por exemplo, você pode reduzir o número de nós em um grupo de nós para zero quando não precisar executar nenhuma VM nos nós do grupo ou pode ativar o escalonador automático do grupo de nós para gerenciar o tamanho do grupo de nós automaticamente.

Antes de provisionar VMs em nós de locatário individual, você deve criar um grupo de nós de locatário individual. Um grupo de nós é um conjunto homogêneo de nós de locatário individual em uma zona específica. Os grupos de nós podem conter várias VMs da mesma série de máquinas em execução em tipos de máquinas de vários tamanhos, desde que o tipo de máquina tenha 2 ou mais vCPUs.

Ao criar um grupo de nós, habilite o escalonamento automático para que o tamanho do grupo se ajuste automaticamente para atender aos requisitos da sua carga de trabalho. Se os seus requisitos de carga de trabalho forem estáticos, você poderá especificar manualmente o tamanho do grupo de nós.

Depois de criar um grupo de nós, você poderá provisionar VMs no grupo ou em um nó específico dentro do grupo. Para maior controle, use rótulos de afinidade de nó para agendar VMs em qualquer nó com rótulos de afinidade correspondentes.

Depois de provisionar VMs em grupos de nós e, opcionalmente, atribuir rótulos de afinidade para provisionar VMs em grupos de nós ou nós específicos, considere rotular seus recursos para ajudar a gerenciar suas VMs. Os rótulos são pares de valores-chave que podem ajudá-lo a categorizar suas VMs para que você possa visualizá-las agregadas por motivos como cobrança. Por exemplo, você pode usar rótulos para marcar a função de uma VM, sua locação, o tipo de licença ou sua localização.

Política de manutenção de host

Dependendo dos seus cenários de licenciamento e cargas de trabalho, talvez você queira limitar o número de núcleos físicos usados ​​pelas suas VMs. A política de manutenção de host escolhida pode depender, por exemplo, de seus requisitos de licenciamento ou conformidade, ou você pode escolher uma política que permita limitar o uso de servidores físicos. Com todas estas políticas, as suas VMs permanecem em hardware dedicado.

Ao programar VMs em nós de locatário individual , você pode escolher entre as três opções diferentes de política de manutenção do host a seguir, que permitem determinar como e se o Compute Engine migra VMs em tempo real durante eventos de host , que ocorrem aproximadamente a cada quatro ou 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, mas, em alguns casos, o Compute Engine pode dividir as VMs em grupos menores e migrar em tempo real cada grupo menor de VMs para nós de locatário individual separados.

Política de manutenção de host padrão

Esta é a política de manutenção de host padrão, e as VMs em grupos de nós configurados com essa política seguem o comportamento de manutenção tradicional para VMs que não são de locatário individual . Ou seja, dependendo da configuração de manutenção no host do host da VM, as VMs migram ao vivo para um novo nó de locatário individual no grupo de nós antes de um evento de manutenção do host, e esse novo nó de locatário individual executa 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 host. Esta definição não restringe a migração de VMs para um conjunto fixo de servidores físicos e é recomendada para cargas de trabalho gerais sem requisitos de servidor físico e que não requerem licenças existentes.

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

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

Reinicie a política de manutenção do host

Quando você usa essa política de manutenção de host, o Compute Engine interrompe VMs durante eventos de host e reinicia as VMs no mesmo servidor físico após o evento de host. Você deve definir a configuração de manutenção da VM no host como TERMINATE ao usar esta política.

Esta política é mais adequada para cargas de trabalho tolerantes a falhas e que podem passar por aproximadamente uma hora de inatividade durante eventos de host, cargas de trabalho que devem permanecer no mesmo servidor físico, cargas de trabalho que não exigem migração em tempo real ou se você tiver licenças baseadas no número de núcleos físicos ou processadores.

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

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

Migrar dentro da política de manutenção de host do grupo de nós

Ao usar essa política de manutenção de host, o Compute Engine migra VMs em tempo real dentro de um grupo de servidores físicos de tamanho fixo durante eventos de host, 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 físicos ou processadores, porque com esta política de manutenção de anfitrião, cada nó de inquilino individual no grupo é fixado a um conjunto fixo de servidores físicos, que é diferente da política padrão que permite que as VMs migrem para qualquer servidor.

Para garantir a capacidade de migração em tempo real, o Compute Engine reserva um nó de retenção para cada 20 nós reservados. A figura a seguir mostra uma animação da política de manutenção de host Migrar dentro do grupo de nós .

A tabela a seguir mostra quantos nós de retenção o Compute Engine reserva, dependendo de quantos nós você reserva para seu grupo de nós.

Fixar uma instância em vários grupos de nós

Você pode fixar uma instância em vários grupos de nós usando o rótulo de afinidade node-group-name sob as seguintes condições:

• A instância que você deseja fixar está usando uma política de manutenção de host padrão ( instância do Migrate VM ) .
• A política de manutenção do host de todos os grupos de nós nos quais você deseja fixar a instância é migrar dentro do grupo de nós . Se você tentar fixar uma instância em grupos de nós com políticas de manutenção de host diferentes, a operação falhará com um erro.

Por exemplo, se você quiser fixar uma instância test-node em dois grupos de nós node-group1 e node-group2 , certifique-se do seguinte:

• A política de manutenção do host do test-node é Migrate VM instance .
• A política de manutenção de host de node-group1 e node-group2 é migrada dentro de node group .

Você não pode atribuir uma instância a qualquer nó específico com o rótulo de afinidade node-name . Você pode usar qualquer rótulo de afinidade de nó personalizado para suas instâncias, desde que eles recebam o node-group-name e não o node-name .

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 , será 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 de nós. Não é possível modificar a janela de manutenção depois de criar o grupo de nós.

As janelas de manutenção são blocos de quatro horas que você pode usar para especificar quando o Google realizará a manutenção nas suas VMs de locatário individual. Os eventos de manutenção ocorrem aproximadamente uma vez a cada 4 a 6 semanas .

A janela de manutenção se aplica a todas as VMs no grupo de nós de locatário individual e especifica apenas quando a manutenção começa. Não é garantido que a manutenção termine durante a janela de manutenção e não há garantia sobre a frequência com que a manutenção ocorre. As janelas de manutenção não são suportadas em grupos de nós com a política de manutenção de host Migrar dentro do grupo de nós .

Simular um evento de manutenção de host

Você pode simular um evento de manutenção de host para testar como suas cargas de trabalho em execução em nós de locatário individual se comportam durante um evento de manutenção de host. Isto permite-lhe ver os efeitos da política de manutenção do anfitrião do VM de inquilino individual nas aplicações em execução nos VMs.

Erros de host

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

1. Retira o servidor físico e seu identificador exclusivo.

2. Revoga o acesso do seu projeto ao servidor físico.

3. Substitui o hardware com falha por um novo servidor físico que possui um novo identificador exclusivo.

4. Move as VMs do hardware com falha para o nó de substituição.

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

Afinidade e antiafinidade do nó

Os nós de locatário individual garantem que suas VMs não compartilhem o host com VMs de outros projetos, a menos que você use grupos de nós de locatário individual compartilhados. Com grupos de nós de locatário individual compartilhados , outros projetos dentro da organização podem provisionar VMs no mesmo host. No entanto, talvez você ainda queira agrupar várias cargas de trabalho no mesmo nó de locatário individual ou isolar suas cargas de trabalho umas das outras em nós diferentes. Por exemplo, para ajudar a atender 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 locatário individual especificando a afinidade ou antiafinidade do nó, referenciando um ou mais rótulos de afinidade do nó. Você especifica rótulos de afinidade de nó personalizados ao criar um modelo de nó, e o Compute Engine inclui automaticamente alguns rótulos de afinidade padrão em cada nó. Ao especificar a afinidade ao criar uma VM, você pode agendar VMs juntas em um nó ou nós específicos em um grupo de nós. Ao especificar a antiafinidade ao criar uma VM, você pode garantir que determinadas VMs não sejam planejadas juntas no mesmo nó ou nós em um grupo de nós.

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

• Controle como as instâncias de VM individuais são atribuídas aos nós.
• Controle como as instâncias de VM criadas a partir de um modelo, como aquelas criadas por um grupo de instâncias gerenciadas, são atribuídas aos nós.
• Agrupe instâncias de VM confidenciais em nós ou grupos de nós específicos, separados de outras VMs.

Rótulos de afinidade padrão

O Compute Engine atribui os seguintes 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.
• Um rótulo para os projetos com os quais o grupo de nós é compartilhado:
  • Chave: compute.googleapis.com/projects
  • Valor: ID do projeto que contém o grupo de nós.

Rótulos de afinidade personalizados

Você pode criar rótulos de afinidade de nó personalizados ao criar um modelo de nó . Esses rótulos de afinidade são atribuídos a todos os nós nos grupos de nós criados a partir do modelo de nó. Não é possível adicionar mais rótulos de afinidade personalizados aos nós de um grupo de nós após a criação do grupo de nós.

Para obter informações sobre como usar rótulos de afinidade, consulte Configurando a afinidade do nó .

Preços

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

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

Disponibilidade

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

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

• O Compute Engine oferece suporte a GPUs em tipos de nós de locatário individual n1 e g2 que estão em zonas com suporte a GPU . A tabela a seguir mostra os tipos de GPUs que podem ser conectadas aos nós n1 e g2 e quantas GPUs devem ser conectadas ao criar o modelo de nó.

  Tipo de GPU	Quantidade de GPU	Tipo de nó de locatário individual
  NVIDIA L4	8	g2
  NVIDIA P100	4	n1
  NVIDIA P4	4	n1
  NVIDIA T4	4	n1
  NVIDIA V100	8	n1

• O Compute Engine oferece suporte a SSDs locais nos tipos de nó de locatário individual n1 , n2 , n2d e g2 que estão em zonas com suporte a SSD local .

Restrições

• Não é possível usar VMs de locatário individual com as seguintes séries e tipos de máquinas: T2D , T2A , E2 , C2D , A2 , A3 , A4 ou instâncias bare metal.

• As VMs de locatário individual não podem especificar uma plataforma mínima de CPU .

• Não é possível migrar uma VM para um nó de locatário individual se essa VM especificar uma plataforma mínima de CPU. Para migrar uma VM para um nó de locatário individual, remova a especificação mínima da plataforma de CPU definindo-a como automática antes de atualizar os rótulos de afinidade do nó da VM.

• Os nós de locatário individual não oferecem suporte a instâncias de VM preemptivas .

• Para obter informações sobre as limitações do uso de SSDs locais em nós de locatário individual, consulte Persistência de dados de SSD local .

• Para obter informações sobre como o uso de GPUs afeta a migração em tempo real, consulte as limitações da migração em tempo real .

• Os nós de locatário individual com GPUs não dão suporte a VMs sem GPUs.

• Somente nós de locatário individual N1, N2, N2D e N4 suportam CPUs com superalocação.

• Os nós de locatário individual C3 e C4 não suportam diferentes configurações de VM no mesmo nó de locatário individual. Por exemplo, você não pode colocar uma VM c3-standard no mesmo nó de locatário individual que uma VM c3-highmem .

• Não é possível atualizar a política de manutenção em um grupo de nós ativos.

O que vem a seguir

• Saiba como criar, configurar e consumir nós de locatário individual .

• Saiba como sobrecarregar CPUs em VMs de locatário individual .

• Aprenda como trazer suas próprias licenças .

• Revise nossas práticas recomendadas para usar nós de locatário individual para executar cargas de trabalho de VM .