Vista geral da posse exclusiva

Este documento descreve os nós de inquilino único. Para obter informações sobre como aprovisionar VMs em nós de inquilino único, consulte o artigo Aprovisionar VMs em nós de inquilino único.

A exclusividade de inquilino permite-lhe ter acesso exclusivo a um nó de inquilino único, que é um servidor físico do Compute Engine dedicado ao alojamento exclusivo das VMs do seu projeto. Use nós de inquilino único para manter as suas VMs fisicamente separadas das VMs noutros projetos ou para agrupar as suas VMs no mesmo hardware de anfitrião, conforme mostrado no diagrama seguinte. Também pode criar um grupo de nós de inquilino único e especificar se quer partilhá-lo com outros projetos ou com toda a organização.

Um anfitrião com vários inquilinos em comparação com um nó de inquilino único.
Figura 1: um anfitrião multi-inquilino versus um nó de inquilino único.

As VMs executadas em nós de inquilino único podem usar as mesmas funcionalidades do Compute Engine que outras VMs, incluindo o agendamento transparente e o armazenamento em blocos, mas com uma camada adicional de isolamento de hardware. Para lhe dar controlo total sobre as VMs no servidor físico, cada nó de inquilino único mantém um mapeamento individual para o servidor físico que suporta o nó.

Num nó de inquilino único, pode aprovisionar várias VMs em tipos de máquinas de vários tamanhos, o que lhe permite usar de forma eficiente os recursos subjacentes do hardware do anfitrião dedicado. Além disso, se optar por não partilhar o hardware do anfitrião com outros projetos, pode cumprir os requisitos de segurança ou conformidade com cargas de trabalho que exijam isolamento físico de outras cargas de trabalho ou VMs. Se a sua carga de trabalho exigir a posse exclusiva apenas temporariamente, pode modificar a posse de VMs conforme necessário.

Os nós de inquilino único podem ajudar a cumprir os requisitos de hardware dedicado para cenários de traga a sua própria licença (BYOL) que exigem licenças por núcleo ou por processador. Quando usa nós de inquilino único, tem alguma visibilidade do hardware subjacente, o que lhe permite monitorizar a utilização de núcleos e processadores. Para acompanhar esta utilização, o Compute Engine comunica o ID do servidor físico no qual uma VM está agendada. Em seguida, ao usar o Cloud Logging, pode ver o histórico de utilização do servidor de uma VM.

Para otimizar a utilização do hardware do anfitrião, pode fazer o seguinte:

Através de uma política de manutenção do anfitrião configurável, pode controlar o comportamento das VMs de inquilino único enquanto o respetivo anfitrião está em manutenção. Pode especificar quando a manutenção ocorre e se as VMs mantêm a afinidade com um servidor físico específico ou são movidas para outros nós de inquilino único num grupo de nós.

Considerações sobre a carga de trabalho

Os seguintes tipos de cargas de trabalho podem beneficiar da utilização de nós de inquilino único:

  • Cargas de trabalho de jogos com requisitos de desempenho

  • Cargas de trabalho de finanças ou cuidados de saúde com requisitos de segurança e conformidade

  • Cargas de trabalho do Windows com requisitos de licenciamento

  • Cargas de trabalho de aprendizagem automática, processamento de dados ou renderização de imagens. Para estas cargas de trabalho, considere reservar GPUs.

  • Cargas de trabalho que requerem um aumento das operações de E/S por segundo (IOPS) e uma diminuição da latência, ou cargas de trabalho que usam armazenamento temporário sob a forma de caches, espaço de processamento ou dados de baixo valor. Para estas cargas de trabalho, considere reservar discos SSD locais.

Modelos de nós

Um modelo de nó é um recurso regional que define as propriedades de cada nó num grupo de nós. Quando cria 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.

Quando cria um modelo de nó, tem de especificar um tipo de nó. Opcionalmente, pode especificar etiquetas de afinidade de nós quando cria um modelo de nó. Só pode especificar etiquetas de afinidade de nós num modelo de nó. Não pode especificar etiquetas de afinidade de nós num grupo de nós.

Tipos de nós

Quando configurar um modelo de nó, especifique um tipo de nó a aplicar a todos os nós num grupo de nós criado com base no modelo de nó. O tipo de nó de inquilino único, 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 adicionar a um nó de inquilino único têm de 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 inquilino único só são compatíveis com VMs criadas com o n2 tipo de máquina.n2 Pode adicionar VMs a um nó de inquilino único até que a quantidade total de vCPUs ou memória exceda a capacidade do nó.

Quando cria um grupo de nós através de um modelo de nó, cada nó no grupo de nós herda as especificações do tipo de nó do modelo de nó. Um tipo de nó aplica-se a cada nó individual num grupo de nós e não a todos os nós do grupo de forma uniforme. Assim, se criar um grupo de nós com dois nós que sejam ambos do tipo de nó n2-node-80-640, cada nó recebe 80 vCPUs e 640 GB de memória.

Consoante os requisitos da sua carga de trabalho, pode preencher o nó com várias VMs mais pequenas 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 expandida. Quando um nó está cheio, não pode agendar VMs adicionais nesse nó.

A tabela seguinte apresenta os tipos de nós disponíveis. Para ver uma lista dos tipos de nós disponíveis para o seu projeto, execute o comando gcloud compute sole-tenancy node-types list ou crie um pedido REST nodeTypes.list.

Tipo de nó Processador vCPU GB vCPU:GB Tomadas Cores:Socket Total de núcleos Máximo de VMs permitidas
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36 15
c3-node-176-352 Sapphire Rapids 176 352 1:2 2 48 96 44
c3-node-176-704 Sapphire Rapids 176 704 1:4 2 48 96 44
c3-node-176-1408 Sapphire Rapids 176 1408 1:8 2 48 96 44
c3d-node-360-708 AMD EPYC Genoa 360 708 1:2 2 96 192 34
c3d-node-360-1440 AMD EPYC Genoa 360 1440 1:4 2 96 192 40
c3d-node-360-2880 AMD EPYC Genoa 360 2880 1:8 2 96 192 40
c4-node-192-384 Emerald Rapids 192 384 1:2 2 60 120 40
c4-node-192-720 Emerald Rapids 192 720 1:3,75 2 60 120 30
c4-node-192-1488 Emerald Rapids 192 1488 1:7,75 2 60 120 30
c4a-node-72-144 Google Axion 72 144 1:2 1 80 80 22
c4a-node-72-288 Google Axion 72 288 1:4 1 80 80 22
c4a-node-72-576 Google Axion 72 576 1:8 1 80 80 36
c4d-node-384-720 AMD EPYC Turin 384 744 1:2 2 96 192 24
c4d-node-384-1488 AMD EPYC Turin 384 1488 1:4 2 96 192 25
c4d-node-384-3024 AMD EPYC Turin 384 3024 1:8 2 96 192 25
g2-node-96-384 Cascade Lake 96 384 1:4 2 28 56 8
g2-node-96-432 Cascade Lake 96 432 1:4,5 2 28 56 8
h3-node-88-352 Sapphire Rapids 88 352 1:4 2 48 96 1
m1-node-96-1433 Skylake 96 1433 1:14.93 2 28 56 1
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88 4
m2-node-416-8832 Cascade Lake 416 8832 1:21,23 8 28 224 1
m2-node-416-11776 Cascade Lake 416 11776 1:28.31 8 28 224 2
m3-node-128-1952 Ice Lake 128 1952 1:15,25 2 36 72 2
m3-node-128-3904 Ice Lake 128 3904 1:30,5 2 36 72 2
m4-node-224-2976 Emerald Rapids 224 2976 1:13,3 2 112 224 1
m4-node-224-5952 Emerald Rapids 224 5952 1:26,7 2 112 224 1
n1-node-96-624 Skylake 96 624 1:6,5 2 28 56 96
n2-node-80-640 Cascade Lake 80 640 1:8 2 24 48 80
n2-node-128-864 Ice Lake 128 864 1:6,75 2 36 72 128
n2d-node-224-896 AMD EPYC Rome 224 896 1:4 2 64 128 112
n2d-node-224-1792 AMD EPYC Milan 224 1792 1:8 2 64 128 112
n4-node-224-1372 Emerald Rapids 224 1372 1:6 2 60 120 90

Para ver informações sobre os preços destes tipos de nós, consulte os preços dos nós de inquilino único.

Todos os nós permitem-lhe agendar VMs de diferentes formas. O tipo de nó n são nós de uso geral, nos quais pode agendar instâncias de tipo de máquina personalizado. Para recomendações sobre o tipo de nó a escolher, consulte as recomendações para tipos de máquinas. Para informações sobre o desempenho, consulte as plataformas de CPU.

Grupos de nós e aprovisionamento de VMs

Os modelos de nós de inquilino único definem as propriedades de um grupo de nós e tem de criar um modelo de nó antes de criar um grupo de nós numa zona. Google CloudQuando cria um grupo, especifica a política de manutenção do anfitrião para VMs no grupo de nós, o número de nós para o grupo de nós e se o quer partilhar com outros projetos ou com toda a organização.

Um grupo de nós pode ter zero ou mais nós. Por exemplo, pode reduzir o número de nós num grupo de nós para zero quando não precisar de executar nenhuma VM em nós no grupo ou pode ativar o autoscaler do grupo de nós para gerir automaticamente o tamanho do grupo de nós.

Antes de aprovisionar VMs em nós de inquilino único, tem de criar um grupo de nós de inquilino único. Um grupo de nós é um conjunto homogéneo de nós de inquilino único numa 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.

Quando cria um grupo de nós, ative o dimensionamento automático para que o tamanho do grupo se ajuste automaticamente de acordo com os requisitos da sua carga de trabalho. Se os requisitos da carga de trabalho forem estáticos, pode especificar manualmente o tamanho do grupo de nós.

Depois de criar um grupo de nós, pode aprovisionar VMs no grupo ou num nó específico no grupo. Para um controlo mais preciso, use etiquetas de afinidade de nós para agendar VMs em qualquer nó com etiquetas de afinidade correspondentes.

Depois de aprovisionar VMs em grupos de nós e, opcionalmente, atribuir etiquetas de afinidade para aprovisionar VMs em grupos de nós ou nós específicos, considere etiquetar os seus recursos para ajudar a gerir as suas VMs. As etiquetas são pares de chave-valor que podem ajudar a categorizar as suas VMs para que as possa ver de forma agregada por motivos como a faturação. Por exemplo, pode usar etiquetas para marcar a função de uma VM, a respetiva posse, o tipo de licença ou a respetiva localização.

Política de manutenção do anfitrião

Consoante os seus cenários de licenciamento e cargas de trabalho, é recomendável limitar o número de núcleos físicos usados pelas suas VMs. A política de manutenção de anfitriões que escolher pode depender, por exemplo, dos seus requisitos de licenciamento ou conformidade, ou pode querer escolher uma política que lhe permita limitar a utilização de servidores físicos. Com todas estas políticas, as suas VMs permanecem em hardware dedicado.

Quando agenda VMs em nós de inquilino único, pode escolher entre as seguintes três opções de políticas de manutenção do anfitrião diferentes, que lhe permitem determinar como e se o Compute Engine migra em direto as VMs durante os eventos do anfitrião, que ocorrem aproximadamente a cada 4 a 6 semanas. Durante a manutenção, o Compute Engine migra em direto, como um grupo, todas as VMs no anfitrião para um nó de inquilino único diferente. No entanto, em alguns casos, o Compute Engine pode dividir as VMs em grupos mais pequenos e migrar em direto cada grupo mais pequeno de VMs para nós de inquilino único separados.

Política de manutenção de anfitriões predefinida

Esta é a política de manutenção do anfitrião predefinida, e as VMs em grupos de nós configurados com esta política seguem o comportamento de manutenção tradicional para VMs não de inquilino único. Ou seja, consoante a definição de manutenção no anfitrião do anfitrião da VM, as VMs são migradas em direto para um novo nó de inquilino único no grupo de nós antes de um evento de manutenção do anfitrião, e este novo nó de inquilino único só executa as VMs do cliente.

Esta política é mais adequada para licenças por utilizador ou por dispositivo que requerem migração em direto durante eventos do anfitrião. Esta definição não restringe a migração de VMs a 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.

Uma vez que as VMs migram em direto para qualquer servidor sem considerar a afinidade do servidor existente com esta política, esta política não é adequada para cenários que exijam a minimização da utilização de núcleos físicos durante eventos do anfitrião.

A figura seguinte mostra uma animação da política de manutenção do anfitrião Predefinição.

Animação da política de manutenção do anfitrião predefinida.
Figura 2: animação da política de manutenção do anfitrião predefinido.

Reinicie a política de manutenção do anfitrião no local

Quando usa esta política de manutenção do anfitrião, o Compute Engine para as VMs durante os eventos do anfitrião e, em seguida, reinicia as VMs no mesmo servidor físico após o evento do anfitrião. Tem de definir a definição de manutenção no anfitrião da VM como TERMINATE quando usar esta política.

Esta política é mais adequada para cargas de trabalho tolerantes a falhas e que podem sofrer aproximadamente uma hora de inatividade durante eventos do anfitrião, cargas de trabalho que têm de permanecer no mesmo servidor físico, cargas de trabalho que não requerem migração em direto ou se tiver licenças baseadas no número de processadores ou núcleos físicos.

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

A figura seguinte mostra uma animação da política de manutenção de reinício no local.

Animação da política de manutenção do anfitrião de reinício no local
Figura 3: animação da política de manutenção do anfitrião Reiniciar no local.

Migre na política de manutenção do anfitrião do grupo de nós

Quando usa esta política de manutenção do anfitrião, o Compute Engine migra as VMs em direto num grupo de tamanho fixo de servidores físicos durante eventos do anfitrião, o que ajuda a limitar o número de servidores físicos únicos 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 do anfitrião, cada nó de inquilino único no grupo está associado a um conjunto fixo de servidores físicos, o que é diferente da política predefinida que permite que as VMs migrem para qualquer servidor.

Para confirmar a capacidade de migração em direto, o Compute Engine reserva 1 nó de retenção para cada 20 nós que reservar. A figura seguinte mostra uma animação da política de manutenção do anfitrião Migrar no grupo de nós.

Animação da migração numa política de manutenção do anfitrião do grupo de nós.
Figura 4: animação da política de manutenção do anfitrião Migrar no grupo de nós.

A tabela seguinte mostra quantos nós de retenção o Compute Engine reserva, consoante o número de nós que reserva para o seu grupo de nós.

Total de nós no grupo Nós de retenção reservados para a migração em direto
1 Não aplicável. Tem de reservar, pelo menos, 2 nós.
2 a 20 1
21 a 40 2
41 a 60 3
61 a 80 4
81 a 100 5

Fixe uma instância a vários grupos de nós

Pode fixar uma instância a vários grupos de nós através da node-group-name etiqueta de afinidade nas seguintes condições:

  • A instância que quer fixar está a usar uma política de manutenção do anfitrião predefinida (migrar instância de VM).
  • A política de manutenção do anfitrião de todos os grupos de nós aos quais quer fixar a instância é migrar no grupo de nós. Se tentar fixar uma instância a grupos de nós com políticas de manutenção de anfitriões diferentes, a operação falha com um erro.

Por exemplo, se quiser fixar uma instância test-node a dois grupos de nós node-group1 e node-group2, verifique o seguinte:

  • A política de manutenção do anfitrião de test-node é Migrar instância de VM.
  • A política de manutenção do anfitrião do node-group1 e do node-group2 é migrar no grupo de nós.

Não pode atribuir uma instância a nenhum nó específico com a etiqueta de afinidade node-name. Pode usar quaisquer etiquetas de afinidade de nós personalizadas para as suas instâncias, desde que lhes seja atribuído o valor node-group-name e não o valor node-name.

Períodos de manutenção

Se estiver a gerir cargas de trabalho, por exemplo, bases de dados ajustadas com precisão, que podem ser sensíveis ao impacto no desempenho da migração em direto, pode determinar quando a manutenção começa num grupo de nós de inquilino único especificando um período de manutenção quando cria o grupo de nós. Não pode modificar a janela de manutenção depois de criar o grupo de nós.

As janelas de manutenção são blocos de tempo de 4 horas que pode usar para especificar quando a Google realiza a manutenção nas suas VMs de inquilino único. Os eventos de manutenção ocorrem aproximadamente uma vez a cada 4 a 6 semanas.

A janela de manutenção aplica-se a todas as VMs no grupo de nós de inquilino único e especifica apenas quando a manutenção começa. Não é garantido que a manutenção termine durante o período de manutenção, e não existe 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 do anfitrião Migrar no grupo de nós.

Simule um evento de manutenção do anfitrião

Pode simular um evento de manutenção do anfitrião para testar o comportamento das suas cargas de trabalho em execução em nós de inquilino único durante um evento de manutenção do anfitrião. Isto permite-lhe ver os efeitos da política de manutenção do anfitrião da VM de inquilino único nas aplicações em execução nas VMs.

Erros do anfitrião

Quando ocorre uma falha de hardware crítica rara no anfitrião, de inquilino único ou multi-inquilino, o Compute Engine faz o seguinte:

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

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

  3. Substitui o hardware com falhas por um novo servidor físico com um novo identificador exclusivo.

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

  5. Reinicia as VMs afetadas se as tiver configurado para reiniciar automaticamente.

Afinidade e antiafinidade de nós

Os nós de inquilino único garantem que as suas VMs não partilham o anfitrião com VMs de outros projetos, a menos que use grupos de nós de inquilino único partilhados. Com os grupos de nós de inquilino único partilhados, outros projetos na organização podem aprovisionar VMs no mesmo anfitrião. No entanto, ainda pode querer agrupar várias cargas de trabalho no mesmo nó de inquilino único ou isolar as cargas de trabalho umas das outras em nós diferentes. Por exemplo, para ajudar a cumprir alguns requisitos de conformidade, pode ter de usar etiquetas de afinidade para separar cargas de trabalho confidenciais de cargas de trabalho não confidenciais.

Quando cria uma VM, pede a posse exclusiva especificando a afinidade de nós ou a antiafinidade, referindo-se a uma ou mais etiquetas de afinidade de nós. Especifica etiquetas de afinidade de nós personalizadas quando cria um modelo de nó, e o Compute Engine inclui automaticamente algumas etiquetas de afinidade predefinidas em cada nó. Ao especificar a afinidade quando cria uma VM, pode agendar VMs em conjunto num nó específico ou em nós num grupo de nós. Ao especificar a antiafinidade quando cria uma VM, pode certificar-se de que determinadas VMs não são agendadas em conjunto no mesmo nó ou nós num grupo de nós.

As etiquetas de afinidade de nós são pares de chave-valor atribuídos a nós e são herdados de um modelo de nó. As etiquetas de afinidade permitem-lhe:

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

Etiquetas de afinidade predefinidas

O Compute Engine atribui as seguintes etiquetas de afinidade predefinidas a cada nó:

  • Uma etiqueta para o nome do grupo de nós:
    • Tecla: compute.googleapis.com/node-group-name
    • Valor: nome do grupo de nós.
  • Uma etiqueta para o nome do nó:
    • Tecla: compute.googleapis.com/node-name
    • Valor: nome do nó individual.
  • Uma etiqueta para os projetos com os quais o grupo de nós é partilhado:
    • Tecla: compute.googleapis.com/projects
    • Valor: ID do projeto que contém o grupo de nós.

Etiquetas de afinidade personalizada

Pode criar etiquetas de afinidade de nós personalizadas quando cria um modelo de nó. Estas etiquetas de afinidade são atribuídas a todos os nós nos grupos de nós criados a partir do modelo de nó. Não pode adicionar mais etiquetas de afinidade personalizadas a nós num grupo de nós depois de o grupo de nós ter sido criado.

Para ver informações sobre como usar etiquetas de afinidade, consulte o artigo Configurar afinidade de nós.

Preços

  • Para ajudar a minimizar o custo dos seus nós de inquilino único, o Compute Engine oferece descontos de fidelidade (DFs) e descontos de utilização contínua (DUCs). Tenha em atenção que, para os encargos premium de arrendamento exclusivo, só pode receber DFs flexíveis e DFs de suspensão, mas não DFs baseados em recursos.

  • Uma vez que já lhe é faturado o número de vCPUs e a memória dos seus nós de inquilino único, não paga mais pelas VMs que criar nesses nós.

  • Se aprovisionar nós de inquilino único com GPUs ou discos SSD locais, são-lhe faturadas todas as GPUs ou discos SSD locais em cada nó que aprovisionar. O prémio de arrendamento exclusivo baseia-se apenas nas vCPUs e na memória que usa para o nó de arrendamento exclusivo e não inclui GPUs nem discos SSD locais.

Disponibilidade

  • Os nós de inquilino único estão disponíveis em zonas selecionadas. Para validar a elevada disponibilidade, agende VMs em nós de inquilino único em diferentes zonas.

  • Antes de usar GPUs ou discos SSD locais em nós de inquilino único, certifique-se de que tem quota suficiente de GPU ou SSD local na zona onde está a reservar o recurso.

  • O Compute Engine suporta GPUs em tipos de nós de inquilino único n1 e g2 que se encontram em zonas com suporte de GPU. A tabela seguinte mostra os tipos de GPUs que pode associar aos nós n1 e g2, bem como o número de GPUs que tem de associar quando cria o modelo de nó.

    Tipo de GPU Quantidade de GPUs Tipo de nó de inquilino único
    NVIDIA L4 8 g2
    NVIDIA P100 4 n1
    NVIDIA P4 4 n1
    NVIDIA T4 4 n1
    NVIDIA V100 8 n1

  • O Compute Engine suporta discos SSD locais nos tipos de nós de inquilino único n1, n2, n2d e g2 que são usados em zonas que suportam essas séries de máquinas.

Restrições

  • Não pode usar VMs de inquilino único com os seguintes tipos e séries de máquinas: T2D, T2A, E2, C2D, A2, A3, A4, A4X, G4 ou instâncias bare metal.

  • As VMs de inquilino único não podem especificar uma plataforma de CPU mínima.

  • Não pode migrar uma VM para um nó de inquilino único se essa VM especificar uma plataforma de CPU mínima. Para migrar uma VM para um nó de inquilino único, remova a especificação mínima da plataforma de CPU definindo-a como automática antes de atualizar as etiquetas de afinidade de nó da VM.

  • Os nós de inquilino único não suportam instâncias de VM preemptíveis.

  • Para obter informações sobre as limitações da utilização de discos SSD locais em nós de inquilino único, consulte o artigo Persistência de dados do SSD local.

  • Para ver informações sobre como a utilização de GPUs afeta a migração em direto, consulte as limitações da migração em direto.

  • Os nós de inquilino único com GPUs não suportam VMs sem GPUs.

  • Apenas os nós de inquilino único N1, N2, N2D e N4 suportam a sobrealocação de CPUs.

  • As VMs C3, C3D, C4, C4A, C4D e N4 são agendadas com alinhamento à arquitetura NUMA subjacente do nó de inquilino único. Agendar formas de VM NUMA completas e sub-NUMA no mesmo nó pode levar à fragmentação, em que não é possível executar uma forma maior, enquanto é possível executar várias formas mais pequenas que totalizam os mesmos requisitos de recursos.

  • Os nós de inquilino único C3 e C4 requerem que as VMs tenham a mesma relação vCPU/memória que o tipo de nó. Por exemplo, não pode colocar uma VM c3-standard num tipo de nó -highmem.

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

O que se segue?