Ao planejar executar cargas de trabalho de VM em nós de locatário individual, primeiro é preciso decidir como implantar nós de locatário individual. Especificamente, é preciso decidir quantos grupos de nós você precisa e qual política de manutenção os grupos de nós 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 de 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 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 estão listados 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 os grupos devem usar.
BYOL e licenciamento por núcleo
Se você planeja trazer sua própria licença (BYOL, na sigla em inglês) para o Compute Engine, os nós de locatário individual podem ajudar a atender os requisitos ou restrições de hardware impostos por essas licenças.
Alguns softwares e sistemas operacionais, como o Windows Server, podem ser licenciados pelo núcleo da CPU física. Também é possível definir limites na frequência com que você tem permissão para alterar o hardware subjacente às máquinas virtuais. de dados. 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 de infraestrutura e de licenciamento: para calcular o custo geral de execução de cargas de trabalho de BYOL no Compute Engine, considere o custo de infraestrutura e de licenciamento. Em alguns casos, minimizar o custo da infraestrutura pode aumentar a sobrecarga de licenciamento ou vice-versa. Por exemplo, usar um tipo de nó com um alto número de núcleos pode ser melhor do ponto de vista de custo/desempenho para determinadas cargas de trabalho, mas poderá gerar custo de licenciamento adicional se as licenças forem fixadas por núcleo.
Use grupos de nós separados para cargas de trabalho BYOL e que não estão em 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. use grupos de nós separados.
Se você usar vários modelos de licenciamento BYOL (por exemplo, Windows Server Datacenter e Standard), dividir os grupos de nós por modelo de licenciamento poderá ajudar a simplificar o rastreamento de licenças e reduzir os custos de licenciamento.
Use sobrecarga da CPU e tipos de nó 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 excessiva de CPU pode ajudar a reduzir o número de núcleos que você precisa licenciar.
Evite o escalonamento automático de escalonamento vertical: o escalonamento automático do grupo de nós pode aumentar ou reduzir automaticamente um grupo de nós com base na demanda atual. O crescimento e a redução frequentes de um grupo de nós implica que você muda com frequência o hardware em que suas VMs são executadas.
Caso você altere o hardware com mais frequência para mover licenças entre máquinas físicas, essas alterações podem levar a uma situação em que seja necessário licenciar mais núcleos que você esteja usando.
Se houver 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 escalonamento automático para apenas escalonamento horizontal.
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 mudanças frequentes de hardware. Para minimizar as alterações de hardware e otimizar o custo do licenciamento, use a política migrar para manutenção do grupo de nós ou reiniciar 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: com o uso da migração em tempo real, a política de manutenção padrão oferece disponibilidade melhor do que Começar a reinicialização e evita o custo extra de infraestrutura migrar dentro da manutenção do grupo de nós.
Gerenciamento
Quando você tiver mais de uma carga de trabalho ou tiver cargas de trabalho de desenvolvimento e produção que precisem 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: use grupos de nós separados para isolar ambientes e evitar situações como estas:
- Uma VM de desenvolvimento pode afetar o desempenho das VMs de produção consumindo demais 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.
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 cargas de trabalho de cada ambiente e programe-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 contêm cargas de trabalho.
Essa abordagem permite simplificar o controle de acesso usando um projeto separado para cada carga de trabalho e, ao mesmo tempo, permite que você 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 ambientes e evita a divulgação de informações sobre grupos de nós a outros projetos.
Estabeleça um processo para atribuição de custo interno: o custo para executar um grupo de nós é gerado no projeto que contém o grupo de nós. Se você precisar atribuir esse custo a projetos ou cargas de trabalho individuais, considere rastrear o uso de suas VMs de locatário individual e usar esses dados para executar a atribuição de custo interno.
Disponibilidade
A carga de trabalho pode ser diferente nos requisitos de disponibilidade e se a alta disponibilidade pode ser alcançada na camada do aplicativo ou se ela precisa ser implementada na camada da infraestrutura:
Aplicativos em cluster: algumas das cargas de trabalho podem implementar 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, instâncias de cluster de failover e SQL de disponibilidade do SQL Server ou aplicativos em balanceamento de carga em cluster em execução no IIS.
Os aplicativos em cluster geralmente podem manter interrupções individuais da VM, desde que a maioria das VMs permaneça disponível.
Aplicativos sem clustering: algumas das cargas de trabalho podem não implementar recursos de clustering e, em vez disso, exigem que a própria VM esteja 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 a VM possa ser migrada em tempo real no caso de um evento de manutenção de nós futuro.
A migração em tempo real é compatível com a política de manutenção padrão e a política de manutenção de migração no grupo de nós, mas não será compatível se você usar o reinicie a política de manutenção no local.
Aplicativos não essenciais: cargas de trabalho em lote, de desenvolvimento/teste e outras cargas de trabalho de menor prioridade podem não ter requisitos de disponibilidade específicos. Para essas cargas de trabalho, pode ser aceitável se VMs individuais não estejam disponí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 em cluster: os nós e grupos de nós de locatário individual 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 programar VMs. Assim, cada instância do aplicativo em cluster será executada em um nó diferente em uma zona ou região diferente.
Se dois ou mais grupos de nós usarem o padrão ou reiniciar na política de manutenção, configure as janelas de manutenção para que não se sobreponham.
Se várias instâncias dos seus aplicativos em cluster 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.
Evite a política de manutenção de reinicialização no local para cargas de trabalho não em cluster que exigem alta disponibilidade:. Isso ocorre porque a política de manutenção reiniciar no local encerra as VMs quando o nó subjacente requer manutenção, prefira usar a política de manutenção diferente para grupos de nós que executam cargas de trabalho não em cluster que exigem alta disponibilidade.
Use grupos de instâncias gerenciadas para aumentar a resiliência e a disponibilidade das cargas de trabalho: Aumente ainda a resiliência e a disponibilidade da implantação usando grupos de instâncias gerenciadas para monitorar a integridade das cargas de trabalho e recriar automaticamente as instâncias de VM, se necessário de dados. É possível usar grupos de instâncias gerenciadas 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, tenha em mente as seguintes práticas recomendadas:
Use grupos de nós dedicados e alocação extra de CPU para cargas de trabalho insensíveis ao desempenho: a sobrecarga da CPU permite aumentar a densidade da VM em nós de locatário individual. Isso pode ajudar a reduzir o número de nós de locatário individual necessários.
Para usar a alocação extra de CPU, use um tipo de nó compatível com alocação excessiva de CPU. A ativação da alocação excessiva de CPU para um grupo de nós gera 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 a alocação de CPU e ativar a alocação extra de CPU somente para esse grupo de nós. Deixe a alocação excessiva de CPU desativada para todos os grupos de nós que precisam executar cargas de trabalho sensíveis ao desempenho.
Use um tipo de nó com uma proporção alta de núcleo de memória para alocação excessiva de CPU: embora a alocação excessiva 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.
- Use 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 de 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 misto
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), será possível usar vários grupos de nós que utilizam diferentes tipos de nó .
- Um grupo de nós usa alocação excessiva de CPU e um tipo de nó com uma proporção de 1:8 vCPU:memória. Esse grupo de nós é usado para cargas de trabalho 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 vCPU:memória, sem alocação excessiva de CPU. Esse grupo de nós é usado para cargas de trabalho em que o desempenho é importante. Ele está configurado para aumentar e diminuir a demanda.
Alta disponibilidade em várias zonas para cargas de trabalho em cluster por licença
Se estiver executando cargas de trabalho em cluster que usam licenciamento por núcleo e precisar minimizar alterações de hardware, é possível encontrar um equilíbrio entre disponibilidade de sobrecarga e 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 restart. Os grupos de nós usam janelas de manutenção não sobrepostas, de modo que não mais de um grupo de nós possa passar por interrupções relacionadas à manutenção de cada vez.
- As instâncias de VM que executam cargas de trabalho em cluster 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 mistas licenciadas por núcleo
Se estiver usando o licenciamento por núcleo, mas nem todas as cargas de trabalho estiverem em cluster, será possível estender o padrão anterior usando políticas de manutenção heterogêneas:
- O grupo de nós principal é implantado na zona
ae executa cargas de trabalho em cluster e não em cluster. Para minimizar interrupções causadas pela manutenção do hardware, o grupo de nós usa a política de manutenção migrar para o grupo de nós. - Um ou mais grupos de nós secundários são implantados em zonas ou regiões adicionais. Esses grupos de nós usam a política de manutenção de restart, 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ó de cluster seja programado em um grupo de nós em uma zona diferente.
- As instâncias de VM que executam cargas de trabalho sem cluster usam rótulos de afinidade para que sejam implantadas no grupo de nós principal.
Ao programar apenas cargas de trabalho em cluster 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. Ao mesmo tempo, você limita a sobrecarga 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.
A seguir
- Saiba mais sobre nós de locatário individual.
- Saiba mais sobre o modelo de licenças adquiridas pelo usuário (BYOL).