Ao planejar executar cargas de trabalho de VM em nós de locatário individual, você deve primeiro decidir como implantar nós de locatário individual. Em particular, você precisa decidir quantos grupos de nós precisa e qual política de manutenção os grupos de nós devem usar:
Grupos de nós: para escolher o número certo de grupos de nós, você deve avaliar a disponibilidade e a utilização de recursos. Embora um pequeno número de grupos de nós permita otimizar a utilização e o custo de recursos, ele limita você a uma única zona. A implantação de grupos de nós em diversas zonas permite melhorar a disponibilidade, mas pode resultar em menor utilização de recursos.
Políticas de escalonamento automático e manutenção: dependendo dos requisitos de licenciamento dos sistemas operacionais e software que você planeja executar, o escalonamento automático de nós e sua escolha de política de manutenção podem afetar o custo e a disponibilidade do licenciamento.
Para tomar a decisão certa sobre como usar nós de locatário individual, você deve considerar cuidadosamente seus requisitos.
Avaliando requisitos
A seção a seguir lista vários requisitos que você deve considerar antes de decidir quantos grupos de nós você precisa e qual política de manutenção os grupos de nós devem usar.
Licenciamento BYOL e por núcleo
Se você planeja trazer sua própria licença (BYOL) para o Compute Engine, os nós de locatário individual podem ajudar você a atender aos requisitos de hardware ou às restrições impostas por essas licenças.
Alguns softwares e sistemas operacionais, como o Windows Server, podem ser licenciados por núcleo físico da CPU e podem definir limites sobre a frequência com que você pode alterar o hardware subjacente às suas máquinas virtuais. O escalonamento automático de nós e a política de manutenção padrão podem fazer com que o hardware seja alterado com mais frequência do que os termos de licença permitem, o que pode resultar em taxas de licenciamento adicionais.
Para otimizar o BYOL por núcleo, considere as seguintes práticas recomendadas:
Encontre um equilíbrio entre a otimização do custo da infraestrutura e o custo do licenciamento : para calcular o custo geral da execução de cargas de trabalho BYOL no Compute Engine, você deve considerar o custo da infraestrutura e o custo do licenciamento. Em alguns casos, minimizar os custos de infra-estrutura pode aumentar as despesas gerais de licenciamento, ou vice-versa. Por exemplo, usar um tipo de nó com um grande número de núcleos pode ser melhor do ponto de vista de custo/desempenho para determinadas cargas de trabalho, mas pode levar a custos adicionais de licenciamento se as licenças forem cobradas por núcleo.
Use grupos de nós separados para cargas de trabalho BYOL e não BYOL: para limitar o número de núcleos que você precisa licenciar, evite misturar cargas de trabalho BYOL e não BYOL em um único grupo de nós e, em vez disso, use grupos de nós separados.
Se você usar vários modelos de licenciamento BYOL diferentes (por exemplo, Windows Server Datacenter e Standard), a divisão de grupos de nós por modelo de licenciamento pode ajudar a simplificar o rastreamento de licenças e reduzir o custo de licenciamento.
Use overcommit de CPU e tipos de nós com alta proporção de núcleo/memória: os tipos de nós diferem em sua proporção entre soquetes, núcleos e memória . Usar um tipo de nó com uma proporção núcleo/memória mais alta e ativar a superalocação de CPU pode ajudar a reduzir o número de núcleos que você precisa licenciar.
Evite o escalonamento automático escalonado: o escalonamento automático do grupo de nós permite aumentar ou diminuir automaticamente um grupo de nós com base na demanda atual. O crescimento e a redução frequentes de um grupo de nós implicam que você altera frequentemente o hardware em que suas VMs são executadas.
Se você estiver alterando o hardware com mais frequência e tiver permissão para mover licenças entre máquinas físicas, essas alterações de hardware poderão levar a uma situação em que você precisará licenciar mais núcleos do que realmente está usando.
Se houver limites para a frequência com que você pode mover-se entre máquinas físicas, você poderá evitar custos excessivos de licenciamento desabilitando o escalonamento automático ou configurando o escalonamento automático para apenas escalar horizontalmente .
Não use a política de manutenção padrão: a política de manutenção padrão permite otimizar a disponibilidade da VM, mas pode causar alterações frequentes de hardware. Para minimizar as alterações de hardware e otimizar o custo de licenciamento, use a política de migração dentro do grupo de nós ou reinicialização no local .
Para cargas de trabalho que não exigem licenciamento por núcleo, considere as seguintes práticas recomendadas:
- Use a política de manutenção padrão: ao usar a migração ao vivo , a política de manutenção padrão oferece melhor disponibilidade do que a política de reinicialização no local e evita o custo extra de infraestrutura da política de manutenção de migração dentro do grupo de nós .
Gerenciamento
Quando você tiver mais de uma carga de trabalho ou cargas de trabalho de desenvolvimento e produção que precisam ser executadas em nós de locatário individual, considere as seguintes práticas recomendadas:
Use grupos de nós separados para ambientes de desenvolvimento e produção: usar grupos de nós separados ajuda a isolar ambientes uns dos outros e a evitar situações como as seguintes:
- Uma VM de desenvolvimento pode afetar o desempenho das VMs de produção ao consumir excessivamente recursos de CPU, disco ou rede ("vizinho barulhento").
- Uma carga de trabalho de desenvolvimento pode esgotar a capacidade de um grupo de nós, impedindo a criação de novas VMs de produção.
Limite o número de grupos de nós em cada ambiente: Se você executar vários grupos de nós, poderá ser difícil utilizar totalmente cada grupo de nós. Para otimizar a utilização, combine cargas de trabalho de cada ambiente e agende-as em um pequeno número de grupos de nós.
Use projetos dedicados para gerenciar grupos de nós: Para cada ambiente, crie um projeto dedicado para gerenciar grupos de nós. Em seguida, compartilhe os grupos de nós com projetos que contenham cargas de trabalho.
Essa abordagem permite simplificar o controle de acesso usando um projeto separado para cada carga de trabalho, ao mesmo tempo que permite otimizar a utilização de recursos compartilhando grupos de nós entre cargas de trabalho.
Compartilhe grupos de nós com projetos individuais: em vez de compartilhar um grupo de nós com uma organização inteira, compartilhe-o apenas com projetos individuais. Selecionar projetos individualmente ajuda a manter uma separação entre ambientes e evita a divulgação de informações sobre grupos de nós para outros projetos.
Estabeleça um processo para atribuição interna de custos: O custo de execução de um grupo de nós é incorrido no projeto que contém o grupo de nós. Se precisar atribuir este custo a projetos ou cargas de trabalho individuais, considere acompanhar a utilização dos seus VMs de inquilino individual e utilizar estes dados para realizar a atribuição interna de custos.
Disponibilidade
Suas cargas de trabalho podem diferir em seus requisitos de disponibilidade e se a alta disponibilidade pode ser alcançada na camada de aplicação ou se precisa ser implementada na camada de infraestrutura:
Aplicativos em cluster: algumas de suas cargas de trabalho podem implementar alta disponibilidade no aplicativo usando técnicas de cluster, como replicação e balanceamento de carga.
Exemplos dessas cargas de trabalho incluem controladores de domínio do Active Directory, instâncias de cluster de failover e grupos de disponibilidade do SQL Server ou aplicativos clusterizados com balanceamento de carga em execução no IIS.
Os aplicativos clusterizados normalmente podem sustentar interrupções individuais de VMs, desde que a maioria das VMs permaneça disponível.
Aplicativos sem cluster: algumas de suas cargas de trabalho podem não implementar nenhum recurso de cluster e, em vez disso, exigir que a própria VM seja mantida disponível.
Exemplos dessas cargas de trabalho incluem servidores de banco de dados não replicados ou servidores de aplicativos com estado.
Para otimizar a disponibilidade de VMs individuais, é necessário garantir que a VM possa ser migrada em tempo real no caso de um próximo evento de manutenção de nó.
A migração ao vivo é suportada pela política de manutenção padrão e pela política de manutenção de migração dentro do grupo de nós , mas não é suportada se você usar a política de manutenção de reinicialização no local .
Aplicativos não críticos: cargas de trabalho em lote, cargas de trabalho de desenvolvimento/teste e outras cargas de trabalho de prioridade mais baixa podem não ter requisitos específicos de disponibilidade. Para estas cargas de trabalho, poderá ser aceitável que os VM individuais estejam indisponíveis durante a manutenção do nó.
Para acomodar os requisitos de disponibilidade das suas cargas de trabalho, considere as seguintes práticas recomendadas:
Use grupos de nós em diferentes zonas ou regiões para implantar cargas de trabalho clusterizadas: nós de locatário individual e grupos de nós são um recurso zonal. Para se proteger contra interrupções zonais, implante vários grupos de nós em diferentes zonas ou regiões. Use a afinidade de nó para agendar VMs para que cada instância do seu aplicativo em cluster seja executada em um nó diferente em uma zona ou região diferente.
Se dois ou mais grupos de nós usarem a política de manutenção padrão ou de reinicialização no local, configure as janelas de manutenção para que seja improvável que elas se sobreponham.
Se diversas instâncias de seus aplicativos em cluster precisarem ser executadas em uma única zona, use a antiafinidade para garantir que as instâncias de VM sejam planejadas em diferentes nós ou grupos de nós.
Evite a política de manutenção de reinicialização no local para cargas de trabalho não agrupadas em cluster que exigem alta disponibilidade: como a política de manutenção de reinicialização no local desliga as VMs quando o nó subjacente requer manutenção, prefira usar uma política de manutenção diferente para grupos de nós que executam cargas de trabalho não agrupadas em cluster que exigem alta disponibilidade.
Use grupos de instâncias gerenciadas para aumentar a resiliência e a disponibilidade de cargas de trabalho: você pode aumentar ainda mais a resiliência e a disponibilidade de sua implantação usando grupos de instâncias gerenciadas para monitorar a integridade de suas cargas de trabalho e recriar automaticamente instâncias de VM, se necessário . Você pode usar grupos de instâncias gerenciadas para cargas de trabalho sem estado e com estado .
Desempenho
Suas cargas de trabalho podem diferir na sensibilidade às flutuações de desempenho. Para determinadas aplicações internas ou cargas de trabalho de teste, otimizar custos pode ser mais importante do que garantir um desempenho consistente ao longo do dia. Para outras cargas de trabalho, como aplicações externas, o desempenho pode ser crítico e mais importante do que a utilização de recursos.
Para fazer o melhor uso dos seus nós de locatário individual, considere as seguintes práticas recomendadas:
Use grupos de nós dedicados e alocação excessiva de CPU para cargas de trabalho insensíveis ao desempenho: a alocação excessiva de CPU permite aumentar a densidade da VM em nós de locatário individual e pode ajudar a reduzir o número de nós de locatário individual necessários.
Para usar o overcommit de CPU, você deve usar um tipo de nó que suporte CPU overcommit . A ativação da superalocação de CPU para um grupo de nós causa cobranças adicionais por nó de locatário individual.
A alocação excessiva de CPU pode ser mais econômica se você usar um grupo de nós dedicado para cargas de trabalho adequadas para alocação excessiva de CPU e ativar a alocação excessiva de CPU somente para esse grupo de nós. Deixe a superalocação de CPU desabilitada para qualquer grupo de nós que precise executar cargas de trabalho sensíveis ao desempenho.
Use um tipo de nó com uma proporção alta de núcleo:memória para alocação excessiva de CPU: embora a alocação excessiva de CPU permita compartilhar núcleos entre VMs, ela não permite compartilhar memória entre VMs. Usar um tipo de nó que tenha relativamente mais memória por núcleo de CPU ajuda a garantir que a memória não se torne um fator limitante.
- Use o escalonamento automático de nós para cargas de trabalho sensíveis ao desempenho: para acomodar diversas necessidades de recursos para cargas de trabalho sensíveis ao desempenho, configure seu grupo de nós para usar o escalonamento automático .
Padrões de implantação
A melhor maneira de usar nós de locatário individual depende dos seus requisitos individuais. A seção a seguir descreve uma seleção de padrões que você pode usar como ponto de partida para derivar uma arquitetura que atenda às suas necessidades individuais.
Vários grupos de nós para requisitos de desempenho mistos
Se você tiver uma combinação de cargas de trabalho sensíveis ao desempenho (por exemplo, aplicativos voltados para o cliente) e insensíveis ao desempenho (por exemplo, aplicativos internos), você poderá usar vários grupos de nós que usam diferentes tipos de nós:
- Um grupo de nós usa superalocação de CPU e um tipo de nó com proporção de vCPU:memória de 1:8. Este grupo de nós é usado para cargas de trabalho insensíveis ao desempenho.
- Um segundo grupo de nós usa um tipo de nó otimizado para computação com uma proporção de vCPU:memória de 1:4 sem superalocação de CPU. Esse grupo de nós é usado para cargas de trabalho de desempenho crítico e é configurado para aumentar e diminuir sob demanda.
Alta disponibilidade em várias zonas para cargas de trabalho licenciadas em cluster por núcleo
Se você estiver executando cargas de trabalho clusterizadas que usam licenciamento por núcleo e precisar minimizar alterações de hardware, poderá encontrar um equilíbrio entre disponibilidade e sobrecarga de licenciamento usando vários grupos de nós com janelas de manutenção não sobrepostas:
- Vários grupos de nós são implantados em diferentes zonas ou regiões .
- Todos os grupos de nós usam a política de reinicialização de manutenção. Os grupos de nós usam janelas de manutenção não sobrepostas para que apenas um grupo de nós sofra interrupções relacionadas à manutenção por vez.
- As instâncias de VM que executam cargas de trabalho em cluster usam rótulos de afinidade para que cada nó do cluster seja programado em um grupo de nós em uma zona diferente.
Alta disponibilidade em várias zonas para cargas de trabalho licenciadas mistas por núcleo
Se estiver usando o licenciamento por núcleo, mas nem todas as suas cargas de trabalho estiverem agrupadas, você poderá estender o padrão anterior usando políticas de manutenção heterogêneas:
- O grupo de nós primários é implementado na zona
ae executa cargas de trabalho clusterizadas e não clusterizadas. Para minimizar interrupções causadas pela manutenção de hardware, o grupo de nós usa a política de migração dentro do grupo de nós . - Um ou mais grupos de nós secundários são implementados em zonas ou regiões adicionais. Esses grupos de nós usam a política de reinicialização de manutenção, mas usam janelas de manutenção não sobrepostas.
- As instâncias de VM que executam cargas de trabalho em cluster usam rótulos de afinidade para que cada nó do cluster seja programado em um grupo de nós em uma zona diferente.
- As instâncias de VM que executam cargas de trabalho não agrupadas em cluster usam rótulos de afinidade para que sejam implementadas no grupo de nós primários.
Ao agendar apenas cargas de trabalho clusterizadas nos grupos de nós secundários, você pode garantir que as interrupções temporárias causadas pela política de manutenção de reinicialização tenham impacto mínimo na disponibilidade geral. Ao mesmo tempo, você limita o licenciamento e a sobrecarga de infraestrutura usando a política de manutenção de migração dentro do grupo de nós apenas para o grupo de nós primário.
O que vem a seguir
- Saiba mais sobre nós de locatário individual .
- Saiba como sobrecarregar CPUs em VMs de locatário individual .
- Aprenda como trazer suas próprias licenças .