Para executar cargas de trabalho de VM em nós de locatário individual, primeiro você precisa decidir como implantá-los. Especificamente, você precisa decidir quantos grupos de nós são necessários e qual política de manutenção esses grupos precisam usar:
Grupos de nós: para escolher o número certo de grupos de nós, você precisa considerar a disponibilidade e a utilização dos recursos. Embora um pequeno número de grupos de nós permita otimizar a utilização de recursos e o custo, isso limita você a uma única zona. A implantação de grupos de nós em várias zonas melhora 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 softwares que você planeja executar, o escalonamento automático de nós e a política de manutenção escolhida podem afetar o custo de licenciamento e a disponibilidade.
Para tomar a decisão certa sobre como usar nós de locatário individual, considere cuidadosamente seus requisitos.
Como avaliar os requisitos
Na seção a seguir, listamos vários requisitos que você precisa considerar antes de decidir quantos grupos de nós são necessários e qual política de manutenção eles devem usar.
BYOL e licenciamento por núcleo
Se você planeja usar licenças adquiridas pelo usuário (BYOL, na sigla em inglês) para o Compute Engine, os nós de locatário individual podem ajudar você a atender aos requisitos ou restrições de hardware impostos por essas licenças.
Alguns softwares e sistemas operacionais, como o Windows Server, podem ser licenciados por núcleo da CPU física e podem definir limites para a frequência com que você tem permissão para alterar o hardware das 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 o permitido pela licença, o que pode resultar em taxas extras de licenciamento.
Para otimizar o BYOL por núcleo, considere as seguintes práticas recomendadas:
Equilibrar o custo da infraestrutura e do licenciamento: para calcular o custo geral da execução de cargas de trabalho de BYOL no Compute Engine, considere o custo da infraestrutura e do licenciamento. Em alguns casos, minimizar o custo da infraestrutura pode aumentar o overhead 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 gerar custos extras de licenciamento caso as licenças sejam fixadas por núcleo.
Usar grupos de nós separados para cargas de trabalho de BYOL e que não são de BYOL: para limitar o número de núcleos que você precisa licenciar, evite combinar cargas de trabalho de BYOL e que não são de BYOL em um único grupo de nós. Em vez disso, use grupos de nós separados.
Se você usa vários modelos de licenciamento de BYOL, como Windows Server Datacenter e Standard, dividir os grupos de nós por modelo de licenciamento pode ajudar a simplificar o monitoramento de licenças e reduzir os custos de licenciamento.
Usar alocação extra de CPU e tipos de nós com uma alta proporção de núcleo/memória: os tipos de nó são diferentes na proporção entre soquetes, núcleos e memória. Usar um tipo de nó com uma proporção maior de núcleo/memória e ativar a alocação extra de CPU pode ajudar a reduzir o número de núcleos que você precisa licenciar.
Evitar a redução de escala horizontal no escalonamento automático: o escalonamento automático de grupos de nós pode aumentar ou reduzir automaticamente um grupo de nós com base na demanda atual. O aumento e a redução frequentes de um grupo de nós implica que você muda com frequência o hardware em que as VMs são executadas.
Se você alterar o hardware com mais frequência do que o permitido para transferir licenças entre máquinas físicas, essas mudanças poderão resultar em uma situação em que seja necessário licenciar mais núcleos do que você está de fato usando.
Quando há limites na frequência com que você pode alternar entre máquinas físicas, é possível evitar o custo excessivo do licenciamento desativando o escalonamento automático ou configurando-o apenas para escalonamento horizontal.
Não usar 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 mudanças frequentes de hardware. Para minimizar essas alterações e otimizar o custo do licenciamento, use a política de manutenção de migração no grupo de nós ou de reinicialização local.
Para cargas de trabalho que não exigem licenciamento por núcleo, considere as seguintes práticas recomendadas:
- Usar a política de manutenção padrão: com o uso da migração em tempo real, a política de manutenção padrão oferece disponibilidade melhor do que a de reinicialização local e evita o custo extra de infraestrutura da política de manutenção de migração no grupo de nós.
Gerenciamento
Quando você tiver mais de uma carga de trabalho ou cargas de trabalho de desenvolvimento e de produção que precisem ser executadas em nós de locatário individual, considere as seguintes práticas recomendadas:
Usar grupos de nós separados para ambientes de desenvolvimento e de produção: use grupos de nós separados para isolar ambientes e evitar situações como as mostradas abaixo.
- Uma VM de desenvolvimento pode afetar o desempenho das VMs de produção consumindo recursos de CPU, disco ou rede em excesso (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.
Limitar 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 cada um deles completamente. Para otimizar a utilização, combine as cargas de trabalho de cada ambiente e programe-as em um pequeno número de grupos de nós.
Usar projetos dedicados para gerenciar grupos de nós: para cada ambiente, crie um projeto dedicado para gerenciar os grupos de nós. Em seguida, compartilhe os grupos de nós com projetos que contêm cargas de trabalho.
Essa abordagem permite que você simplifique o controle de acesso usando um projeto separado para cada carga de trabalho e otimize a utilização de recursos compartilhando grupos de nós entre cargas de trabalho.
Compartilhar 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 os ambientes e evita a divulgação de informações sobre grupos de nós a outros projetos.
Estabelecer um processo para a atribuição de custo interno: o custo para executar um grupo de nós é gerado no projeto que contém esse grupo. Se você precisar atribuir esse custo a projetos ou cargas de trabalho individuais, considere monitorar o uso das VMs de locatário individual e usar esses dados para realizar a atribuição de custo interno.
Disponibilidade
Suas cargas de trabalho podem ter requisitos de disponibilidade diferentes, e a alta disponibilidade pode ser alcançada na camada do aplicativo ou implementada na camada da infraestrutura:
Aplicativos clusterizados: algumas das cargas de trabalho podem implementar a alta disponibilidade no aplicativo usando técnicas de clustering, como replicação e balanceamento de carga.
Exemplos dessas cargas de trabalho incluem controladores de domínio do Active Directory, grupos de disponibilidade e instâncias de cluster de failover do SQL Server ou aplicativos clusterizados com balanceamento de carga em execução no IIS.
Em geral, os aplicativos clusterizados podem lidar com interrupções de VMs individuais, desde que a maioria delas permaneça disponível.
Aplicativos sem clustering: algumas cargas de trabalho podem não implementar recursos de clustering e 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, você precisa garantir que elas possam ser migradas em tempo real no caso de um evento de manutenção de nós programado.
A migração em tempo real é aceita pela política de manutenção padrão e pela política de manutenção de migração no grupo de nós, mas não é aceita pela política de manutenção de reinicialização local.
Aplicativos não essenciais: cargas de trabalho em lote, de desenvolvimento, de teste e outras de menor prioridade podem não ter requisitos de disponibilidade específicos. Para essas cargas de trabalho, pode ser aceitável que VMs individuais não estejam disponíveis durante a manutenção de nós.
Para acomodar os requisitos de disponibilidade das suas cargas de trabalho, considere as seguintes práticas recomendadas:
Usar grupos de nós em diferentes zonas ou regiões para implantar cargas de trabalho clusterizadas: os grupos de nós e nós de locatário individual são um recurso zonal. Para evitar interrupções zonais, implante vários grupos de nós em diferentes zonas ou regiões. Use a afinidade de nó para programar VMs. Assim, cada instância do aplicativo clusterizado é 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 a política de reinicialização local, configure as janelas de manutenção para evitar sobreposições.
Se várias instâncias dos aplicativos clusterizados precisarem ser executadas em uma única zona, use a antiafinidade para garantir que as instâncias de VM sejam programadas em nós ou grupos de nós diferentes.
Evitar a política de manutenção de reinicialização local para cargas de trabalho não clusterizadas que exigem alta disponibilidade: como a política de manutenção de reinicialização local encerra as VMs quando o nó subjacente requer manutenção, prefira usar outra política de manutenção para grupos de nós que executam cargas de trabalho não clusterizadas que exigem alta disponibilidade.
Usar grupos gerenciados de instâncias para aumentar a resiliência e a disponibilidade das cargas de trabalho: aumente ainda mais a resiliência e a disponibilidade da implantação usando grupos gerenciados de instâncias para monitorar a integridade das cargas de trabalho e recriar automaticamente as instâncias de VM, se necessário. É possível usar grupos gerenciados de instâncias para cargas de trabalho sem estado e com estado.
Desempenho
A sensibilidade das cargas de trabalho a flutuações de desempenho pode ser diferente. Para determinados aplicativos internos ou cargas de trabalho de teste, otimizar o custo pode ser mais importante do que garantir um desempenho consistente ao longo do dia. Para outras cargas de trabalho, como aplicativos externos, o desempenho pode ser fundamental e mais importante do que a utilização de recursos.
Para aproveitar ao máximo os nós de locatário individual, considere as seguintes práticas recomendadas:
Usar grupos de nós dedicados e a alocação extra de CPU para cargas de trabalho que não são sensíveis ao desempenho: a alocação extra de CPU permite aumentar a densidade da VM em nós de locatário individual. Isso pode ajudar a reduzir o número necessário desses nós.
Para usar a alocação extra de CPU, use um tipo de nó que aceite esse recurso. A ativação da alocação extra de CPU para um grupo de nós gera cobranças adicionais por nó de locatário individual.
A alocação extra de CPU pode ser mais econômica quando você usa um grupo de nós dedicado com cargas de trabalho adequadas para esse recurso e a ativa somente para esse grupo. Deixe a alocação extra de CPU desativada para todos os grupos de nós que precisam executar cargas de trabalho sensíveis ao desempenho.
Usar um tipo de nó com uma proporção alta de núcleo/memória para alocação extra de CPU: embora a alocação extra de CPU permita o compartilhamento de núcleos entre VMs, ela não permite o compartilhamento de 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.
- Usar o escalonamento automático de nós para cargas de trabalho sensíveis ao desempenho: para atender às necessidades variáveis de recursos das 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. Na seção a seguir, descrevemos uma seleção de padrões que podem ser usados como ponto de partida para derivar uma arquitetura que atenda aos seus requisitos individuais.
Vários grupos de nós para requisitos de desempenho variados
Se você tiver cargas de trabalho sensíveis ao desempenho, como aplicativos voltados ao cliente, e cargas de trabalho que não são sensíveis ao desempenho, como aplicativos internos, use vários grupos de nós com diferentes tipos de nós.
- Um grupo de nós usa a alocação extra de CPU e um tipo de nó com uma proporção de 1:8 para vCPU/memória. Esse grupo de nós é usado para cargas de trabalho que não são sensíveis ao desempenho.
- Um segundo grupo de nós usa um tipo de nó otimizado para computação com uma proporção de 1:4 para vCPU/memória, sem alocação extra de CPU. Esse grupo de nós é usado para cargas de trabalho em que o desempenho é importante. Ele está configurado para aumentar ou reduzir o escalonamento vertical conforme a demanda.
Alta disponibilidade em várias zonas para cargas de trabalho licenciadas e clusterizadas por núcleo
Se você executar cargas de trabalho clusterizadas que usam o licenciamento por núcleo e precisar minimizar as alterações de hardware, tente encontrar um equilíbrio entre disponibilidade e overhead 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 manutenção de reinicialização. Os grupos de nós usam janelas de manutenção não sobrepostas para que apenas um grupo de nós por vez passe por interrupções relacionadas à manutenção.
- As instâncias de VM que executam cargas de trabalho clusterizadas usam rótulos de afinidade para que cada nó de cluster seja programado em um grupo de nós em uma zona diferente.
Alta disponibilidade em várias zonas para cargas de trabalho licenciadas e mistas por núcleo
Se você usar o licenciamento por núcleo, mas nem todas as cargas de trabalho forem clusterizadas, estenda o padrão anterior usando políticas de manutenção diferentes:
- O grupo de nós principal é implantado na zona
ae executa cargas de trabalho clusterizadas e não clusterizadas. Para minimizar as interrupções causadas pela manutenção do hardware, o grupo de nós usa a política de manutenção de migração no grupo de nós. - Um ou mais grupos de nós secundários são implantados em outras zonas ou regiões. Esses grupos de nós usam a política de manutenção de reinicialização, mas usam janelas de manutenção não sobrepostas.
- As instâncias de VM que executam cargas de trabalho clusterizadas usam rótulos de afinidade para que cada nó de 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 clusterizadas usam rótulos de afinidade para que sejam implantadas no grupo de nós principal.
Ao programar apenas cargas de trabalho clusterizadas nos grupos de nós secundários, você garante que as interrupções temporárias causadas pela política de manutenção de reinicialização tenham um impacto mínimo na disponibilidade geral. Além disso, você limita o overhead de licenciamento e infraestrutura usando a política de manutenção de migração no grupo de nós apenas para o grupo de nós principal.
A seguir
- Saiba mais sobre nós de locatário individual.
- Saiba como fazer a alocação extra de CPU em VMs de locatário individual.
- Saiba mais sobre o modelo de licenças adquiridas pelo usuário (BYOL).