Quando planeia executar cargas de trabalho de VMs em nós de inquilino único, primeiro tem de decidir como implementar nós de inquilino único. Em particular, tem de decidir quantos grupos de nós precisa e que 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, tem de ponderar a disponibilidade e a utilização de recursos. Embora um pequeno número de grupos de nós lhe permita otimizar a utilização de recursos e os custos, limita-o a uma única zona. A implementação de grupos de nós em várias zonas permite melhorar a disponibilidade, mas pode resultar numa menor utilização de recursos.
Políticas de manutenção e escalamento automático: consoante os requisitos de licenciamento dos sistemas operativos e do software que planeia executar, o escalamento automático de nós e a 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 inquilino único, tem de considerar cuidadosamente os seus requisitos.
A avaliar os requisitos
A secção seguinte apresenta vários requisitos que deve considerar antes de decidir de quantos grupos de nós precisa e que política de manutenção os grupos de nós devem usar.
BYOL e licenciamento por núcleo
Se planeia trazer a sua própria licença (BYOL) para o Compute Engine, os nós de inquilino único podem ajudar a resolver os requisitos de hardware ou as restrições impostas por estas licenças.
Alguns softwares e sistemas operativos, como o Windows Server, podem ser licenciados por núcleo de CPU físico e podem definir limites na frequência com que tem autorização para alterar o hardware subjacente às suas máquinas virtuais. O dimensionamento automático de nós e a política de manutenção predefinida podem levar a que o hardware seja alterado com mais frequência do que o permitido pelos termos da sua licença, o que pode resultar em taxas de licenciamento adicionais.
Para otimizar a opçã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 das licenças: Para calcular o custo geral da execução de cargas de trabalho BYOL no Compute Engine, tem de considerar o custo da infraestrutura e o custo das licenças. Em alguns casos, a minimização do custo da infraestrutura pode aumentar os custos gerais de licenciamento ou vice-versa. Por exemplo, usar um tipo de nó com um número elevado de núcleos pode ser a melhor opção do ponto de vista do custo/desempenho para determinadas cargas de trabalho, mas pode gerar um custo de licenciamento adicional 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 tem de licenciar, evite misturar cargas de trabalho BYOL e não BYOL num único grupo de nós e use grupos de nós separados.
Se usar vários modelos de licenciamento BYOL diferentes (por exemplo, Windows Server Datacenter e Standard), dividir os grupos de nós por modelo de licenciamento pode ajudar a simplificar o acompanhamento de licenças e reduzir o custo de licenciamento.
Use o overcommit da CPU e tipos de nós com uma elevada relação núcleo/memória: os tipos de nós diferem na respetiva relação entre encaixes, núcleos e memória. A utilização de um tipo de nó com uma relação núcleo:memória mais elevada e a ativação da sobreposição de compromissos da CPU podem ajudar a reduzir o número de núcleos que tem de licenciar.
Evite a escala automática de redução: a escala automática do grupo de nós permite aumentar ou diminuir automaticamente um grupo de nós com base na procura atual. O aumento e a diminuição frequentes de um grupo de nós implica que está a alterar frequentemente o hardware no qual as suas VMs são executadas.
Se alterar o hardware com mais frequência do que o permitido para mover licenças entre máquinas físicas, estas alterações de hardware podem levar a uma situação em que tem de licenciar mais núcleos do que os que está a usar.
Se existirem limites na frequência com que pode mover-se entre máquinas físicas, pode evitar custos de licenciamento excessivos desativando o dimensionamento automático ou configurando o dimensionamento automático para apenas aumentar a escala.
Não usar a política de manutenção predefinida: a política de manutenção predefinida permite otimizar a disponibilidade das VMs, mas pode causar alterações frequentes ao hardware. Para minimizar as alterações de hardware e otimizar em função do custo de licenciamento, use a política de migração na manutenção do grupo de nós ou de reinício no local.
Para cargas de trabalho que não requerem licenciamento por núcleo, considere as seguintes práticas recomendadas:
- Use a política de manutenção predefinida: ao usar a migração em direto, a política de manutenção predefinida oferece uma melhor disponibilidade do que a política de reinício no local e evita o custo de infraestrutura adicional da política de migração na manutenção do grupo de nós.
Gestão
Quando tem mais do que uma carga de trabalho ou quando tem cargas de trabalho de desenvolvimento e de produção que precisam de ser executadas em nós de inquilino único, considere as seguintes práticas recomendadas:
Use grupos de nós separados para ambientes de desenvolvimento e produção: a utilização de grupos de nós separados ajuda a isolar os ambientes uns dos outros e evitar situações como as seguintes:
- Uma VM de desenvolvimento pode afetar o desempenho das VMs de produção consumindo excessivamente recursos de CPU, disco ou rede ("vizinho ruidoso").
- Uma carga de trabalho de desenvolvimento pode esgotar a capacidade de um grupo de nós, o que impede a criação de novas VMs de produção.
Limite o número de grupos de nós em cada ambiente: se executar vários grupos de nós, pode ser difícil usar totalmente cada grupo de nós. Para otimizar a utilização, combine as cargas de trabalho de cada ambiente e agende-as num pequeno número de grupos de nós.
Use projetos dedicados para gerir grupos de nós: para cada ambiente, crie um projeto dedicado para gerir grupos de nós. Em seguida, partilhe os grupos de nós com projetos que contenham cargas de trabalho.
Esta abordagem permite-lhe simplificar o controlo de acesso através da utilização de um projeto separado para cada carga de trabalho, ao mesmo tempo que lhe permite otimizar a utilização de recursos através da partilha de grupos de nós entre cargas de trabalho.
Partilhe grupos de nós com projetos individuais: em vez de partilhar um grupo de nós com uma organização inteira, partilhe-o apenas com projetos individuais. A seleção de projetos individualmente ajuda a manter uma separação entre ambientes e evita a divulgação de informações sobre grupos de nós a outros projetos.
Estabeleça um processo de atribuição de custos internos: o custo de execução de um grupo de nós é incorrido no projeto que contém o grupo de nós. Se precisar de atribuir este custo a projetos ou cargas de trabalho individuais, considere monitorizar a utilização das suas VMs de inquilino único e usar estes dados para realizar a atribuição de custos interna.
Disponibilidade
As suas cargas de trabalho podem diferir nos requisitos de disponibilidade e se a alta disponibilidade pode ser alcançada na camada de aplicação ou se precisa de ser implementada na camada de infraestrutura:
Aplicações agrupadas: algumas das suas cargas de trabalho podem implementar a alta disponibilidade na aplicação através de técnicas de agrupamento, como a replicação e o equilíbrio de carga.
Exemplos de tais cargas de trabalho incluem controladores de domínio do Active Directory, instâncias de cluster de comutação por falha e grupos de disponibilidade do SQL Server, ou aplicações com balanceamento de carga em cluster em execução no IIS.
Normalmente, as aplicações agrupadas podem suportar falhas de VMs individuais, desde que a maioria das VMs permaneça disponível.
Aplicações não agrupadas: algumas das suas cargas de trabalho podem não implementar capacidades de agrupamento e, em alternativa, exigem que a própria VM esteja disponível.
Alguns exemplos destas cargas de trabalho incluem servidores de base de dados não replicados ou servidores de aplicações com estado.
Para otimizar a disponibilidade de VMs individuais, tem de garantir que a VM pode ser migrada em direto em caso de um evento de manutenção de nós futuro.
A migração em direto é suportada pela política de manutenção predefinida e pela política de manutenção migrar no grupo de nós, mas não é suportada se usar a política de manutenção de reinício no local.
Aplicações não críticas: as cargas de trabalho em lote, as cargas de trabalho de desenvolvimento/teste e outras cargas de trabalho de prioridade inferior podem não ter requisitos de disponibilidade específicos. Para estas cargas de trabalho, pode ser aceitável se as VMs individuais não estiverem disponíveis durante a manutenção dos nós.
Para ter em conta 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 implementar cargas de trabalho agrupadas: os nós de inquilino único e os grupos de nós são um recurso zonal. Para se proteger contra interrupções zonais, implemente vários grupos de nós em diferentes zonas ou regiões. Use a afinidade de nós para agendar VMs de modo que cada instância da sua aplicação agrupada seja executada num nó diferente numa zona ou região diferente.
Se dois ou mais dos seus grupos de nós usarem a política de manutenção predefinida ou de reinício no local, configure janelas de manutenção para que seja improvável que se sobreponham.
Se várias instâncias das suas aplicações agrupadas tiverem de ser executadas numa única zona, use a antiafinidade para garantir que as instâncias de VM são agendadas em nós diferentes ou grupos de nós.
Evite a política de manutenção de reinício no local para cargas de trabalho não agrupadas que requerem elevada disponibilidade: Uma vez que a política de manutenção de reinício no local desliga as VMs quando o nó subjacente requer manutenção, é preferível usar uma política de manutenção diferente para grupos de nós que executam cargas de trabalho não agrupadas que requerem elevada disponibilidade.
Use grupos de instâncias geridas para aumentar a resiliência e a disponibilidade das cargas de trabalho: pode aumentar ainda mais a resiliência e a disponibilidade da sua implementação usando grupos de instâncias geridas para monitorizar o estado das suas cargas de trabalho e recriar automaticamente instâncias de VMs, se necessário. Pode usar grupos de instâncias geridos para cargas de trabalho sem estado e com estado.
Desempenho
As suas cargas de trabalho podem diferir na respetiva sensibilidade às flutuações de desempenho. Para determinadas aplicações internas ou cargas de trabalho de teste, a otimização dos custos pode ser mais importante do que garantir um desempenho consistente ao longo do dia. Para outras cargas de trabalho, como aplicações viradas para o exterior, o desempenho pode ser crítico e mais importante do que a utilização de recursos.
Para tirar o máximo partido dos nós de inquilino único, considere as seguintes práticas recomendadas:
Use grupos de nós dedicados e sobrecompromisso da CPU para cargas de trabalho insensíveis ao desempenho: O sobrecompromisso da CPU permite-lhe aumentar a densidade de VMs em nós de inquilino único e pode ajudar a reduzir o número de nós de inquilino único necessários.
Para usar o overcommit de CPU, tem de usar um tipo de nó que suporte o overcommit de CPU. A ativação da sobreposição de CPU para um grupo de nós causa cobranças adicionais por nó de inquilino único.
O compromisso excessivo de CPUs pode ser mais rentável se usar um grupo de nós dedicado para cargas de trabalho adequadas para o compromisso excessivo de CPUs e ativar o compromisso excessivo de CPUs apenas para este grupo de nós. Deixe a sobreposição de CPU desativada para todos os grupos de nós que precisam de executar cargas de trabalho sensíveis ao desempenho.
Use um tipo de nó com uma relação núcleo:memória elevada para o compromisso excessivo de CPU: embora o compromisso excessivo de CPU lhe permita partilhar núcleos entre VMs, não lhe permite partilhar memória entre VMs. A utilização de um tipo de nó com relativamente mais memória por núcleo da CPU ajuda a garantir que a memória não se torna um fator limitativo.
- Use a escala automática de nós para cargas de trabalho sensíveis ao desempenho: para acomodar as necessidades de recursos variáveis para cargas de trabalho sensíveis ao desempenho, configure o seu grupo de nós para usar a escala automática.
Padrões de implementação
A melhor forma de usar nós de inquilino único depende dos seus requisitos individuais. A secção seguinte descreve uma seleção de padrões que pode usar como ponto de partida para derivar uma arquitetura adequada aos seus requisitos individuais.
Vários grupos de nós para requisitos de desempenho mistos
Se tiver uma combinação de cargas de trabalho sensíveis ao desempenho (por exemplo, aplicações orientadas para o cliente) e insensíveis ao desempenho (por exemplo, aplicações internas), pode usar vários grupos de nós que usam diferentes tipos de nós:
- Um grupo de nós usa o excesso de compromisso da CPU e um tipo de nó com uma relação de 1:8 entre vCPU e memória. 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 relação de 1:4 entre vCPU e memória sem compromisso excessivo de CPU. Este grupo de nós é usado para cargas de trabalho críticas para o desempenho e está configurado para aumentar e diminuir a escala a pedido.
Disponibilidade elevada em várias zonas para cargas de trabalho licenciadas por núcleo agrupadas
Se estiver a executar cargas de trabalho agrupadas que usam licenciamento por núcleo e precisar de minimizar as alterações de hardware, pode encontrar um equilíbrio entre a disponibilidade e a 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 implementados em diferentes zonas ou regiões.
- Todos os grupos de nós usam a política de manutenção restart. Os grupos de nós usam janelas de manutenção não sobrepostas, pelo que não deve haver mais do que um grupo de nós a sofrer interrupções relacionadas com a manutenção em simultâneo.
- As instâncias de VM que executam cargas de trabalho agrupadas usam etiquetas de afinidade para que cada nó do cluster seja agendado num grupo de nós numa zona diferente.
Disponibilidade elevada em várias zonas para cargas de trabalho licenciadas por núcleo mistas
Se estiver a usar licenciamento por núcleo, mas nem todas as suas cargas de trabalho estão agrupadas, pode estender o padrão anterior usando políticas de manutenção heterogéneas:
- O grupo de nós principal é implementado na zona
ae executa cargas de trabalho agrupadas e não agrupadas. Para minimizar as indisponibilidades causadas pela manutenção de hardware, o grupo de nós usa a política de manutenção migrate within node group. - Um ou mais grupos de nós secundários são implementados em zonas ou regiões adicionais. Estes grupos de nós usam a política de manutenção restart, mas usam janelas de manutenção não sobrepostas.
- As instâncias de VM que executam cargas de trabalho agrupadas usam etiquetas de afinidade para que cada nó do cluster seja agendado num grupo de nós numa zona diferente.
- As instâncias de VM que executam cargas de trabalho não agrupadas usam etiquetas de afinidade para que sejam implementadas no grupo de nós principal.
Ao agendar apenas cargas de trabalho agrupadas nos grupos de nós secundários, pode garantir que as interrupções temporárias causadas pela política de manutenção de reinício têm um impacto mínimo na disponibilidade geral. Ao mesmo tempo, limita os custos gerais de licenciamento e infraestrutura usando a política de manutenção migrar no grupo de nós apenas para o grupo de nós principal.
O que se segue?
- Saiba mais sobre os nós de inquilino único.
- Saiba como trazer as suas próprias licenças.