Como distribuir instâncias usando MIGs regionais

Nesta página, descrevemos como criar grupos de instâncias gerenciadas (MIGs, em inglês) regionais. Você também pode criar MIGs por zona (zona única). Os MIGs zonais e regionais são compatíveis com recuperação automática, balanceamento de carga, escalonamento automático, atualização automática e cargas de trabalho com estado.

Os MIGs regionais oferecem maior disponibilidade em comparação com os MIGs zonais porque as instâncias gerenciadas de um MIG regional estão distribuídas uniformemente por várias zonas em uma única região. No entanto, os MIGs regionais têm limitações diferentes em comparação com os MIGs zonais.

Seja por zona ou regional, o MIG baseia cada uma das instâncias gerenciadas em um modelo de instância comum e uma configuração com estado opcional. Cada instância gerenciada é uma entidade de dados no MIG que contém o status atual e o estado pretendido de uma instância de VM real. Os MIGs mantêm a alta disponibilidade dos aplicativos mantendo as VMs reais disponíveis, ou seja, no estado RUNNING.

Para mais informações sobre grupos de instâncias e os respectivos recursos, consulte a Visão geral de grupos de instâncias.

Antes de começar

Para usar os exemplos da API deste guia, configure o acesso a ela.
Para usar os exemplos de linha de comando deste guia, instale a ferramenta de linha de comando gcloud.
Leia sobre os modelos de instância.
Leia sobre grupos de instâncias gerenciadas (MIGs, na sigla em inglês).
Leia sobre as regiões e zonas.

Limitações

Cada MIG regional pode conter até 2.000 VMs.
Ao atualizar um MIG, não é possível especificar mais de 1.000 VMs em uma única solicitação.
Não é possível usar MIGs regionais com um balanceador de carga que usa a opção de balanceamento maxRate.
Quando usado com escalonamento automático com base em métricas do Cloud Monitoring:
- Ao contrário dos MIGs de zona única, os MIGs regionais não são compatíveis com a filtragem de métricas por instância.
- Ao contrário dos MIGs de zona única, os MIGs regionais não são compatíveis com o escalonamento automático usando métricas por grupo.

Selecionar grupos de instâncias regionais gerenciados

O Google recomenda MIGs regionais em vez de MIGs zonais, pois eles permitem distribuir a carga do aplicativo em várias zonas, em vez de confinar o aplicativo a uma única zona ou gerenciar vários grupos de instâncias em diferentes zonas. O uso de várias zonas protege contra falhas por zona e situações imprevistas em que um grupo inteiro de instâncias em uma única zona não funciona. Se este tipo de problema ocorrer, o aplicativo continua a servir o tráfego a partir das instâncias em execução na zona da mesma região.

No caso de uma falha de zona ou se um grupo de VMs em uma zona parar de responder, um MIG regional continuará a oferecer suporte a suas VMs da seguinte maneira:

O número de VMs que fazem parte do MIG regional nas zonas restantes continua a veicular tráfego. Nenhuma VM nova é adicionada e nenhuma é redistribuída, a menos que você configure o escalonamento automático.
Depois que a zona com falha for recuperada, o MIG voltará a veicular o tráfego dessa zona.

Ao criar aplicativos robustos e escalonáveis, use MIGs regionais.

Redistribuição proativa de instâncias

Por padrão, um MIG regional tenta manter uma distribuição uniforme de VMs entre zonas para maximizar a disponibilidade do aplicativo no caso de uma falha no nível da zona.

Se você excluir ou abandonar instâncias do grupo, causando uma distribuição uniforme entre as zonas, o grupo redistribuirá as instâncias para restabelecer uma distribuição uniforme.

Para restabelecer uma distribuição uniforme entre zonas, o grupo exclui VMs em zonas com mais VMs e adiciona VMs a zonas com menos VMs. O grupo escolhe automaticamente as VMs a serem excluídas.

A redistribuição proativa restabelece a distribuição uniforme entre as zonas. — **Exemplo de redistribuição proativa**

Por exemplo, suponha que você tenha um MIG regional com quatro instâncias espalhadas por três zonas: a, b e c. Se você excluir três instâncias gerenciadas em c, o grupo tentará reequilibrar para que as instâncias sejam distribuídas uniformemente pelas zonas. Nesse caso, o grupo exclui duas instâncias (uma de a e outra de b) e cria duas na zona c, para que cada uma tenha três instâncias e a distribuição seja uniforme. Não há como determinar seletivamente quais instâncias são excluídas. O grupo perde a capacidade temporariamente enquanto as novas instâncias são iniciadas.

Para evitar a redistribuição automática das suas VMs, desative a redistribuição proativa de instâncias ao criar ou atualizar um MIG regional.

Isso é útil quando você precisa:

Excluir ou abandonar as VMs do grupo sem afetar outras instâncias de VM em execução. Por exemplo, é possível excluir uma VM de worker em lote após a conclusão do job sem afetar outros workers.
proteger VMs que têm apps com estado contra exclusão automática indesejável por redistribuição proativa.

Desativar a redistribuição proativa pode afetar a capacidade durante uma falha de zona. — *Distribuição não uniforme após desativar a redistribuição proativa*

Se você desativar a redistribuição proativa de instâncias, um MIG não adicionará ou removerá VMs de maneira proativa, mas ainda converterá de maneira oportuna em operações de redimensionamento, tratando cada operação de redimensionamento como uma oportunidade para equilibrar o grupo. Por exemplo, ao escalonar, o grupo usa automaticamente o escalonamento como uma oportunidade para remover VMs de zonas maiores. Ao escalonar, o grupo usa a oportunidade para adicionar VMs a zonas menores.

Como provisionar o tamanho correto do MIG para garantir a disponibilidade

Uma variedade de eventos pode fazer com que uma ou mais VMs fiquem indisponíveis, e você pode ajudar a atenuar esse problema usando vários serviços do Google Cloud:

Use um MIG regional para distribuir seu aplicativo em várias zonas.
Use a recuperação automática para recriar VMs com falha.
Use o balanceamento de carga para direcionar automaticamente o tráfego do usuário para longe de VMs indisponíveis.

No entanto, mesmo que você use esses serviços, seus usuários ainda poderão ter problemas se muitas VMs estiverem indisponíveis simultaneamente.

Para estar preparado para o caso de uma zona falhar ou um grupo inteiro de VMs parar de responder, o Google recomenda o provisionamento excessivo do seu MIG. Dependendo das necessidades do aplicativo, o provisionamento excessivo do grupo impede que o sistema falhe completamente se uma zona ou um grupo de VMs deixar de responder.

O Google faz recomendações de como aumentar o provisionamento com a prioridade de manter seu aplicativo disponível para os usuários. Essas recomendações incluem provisionamento e pagamento de mais VMs do que o aplicativo pode precisar diariamente. Baseie suas decisões de provisionamento nas necessidades do aplicativo e nas limitações de custo.

Como estimar o tamanho do grupo recomendado

O Compute Engine recomenda que você provisione VMs suficientes para que, se todas as VMs em qualquer zona estiverem indisponíveis, as VMs restantes ainda atenderão ao número mínimo de VMs necessárias.

Use a tabela a seguir para determinar o tamanho mínimo recomendado para seu grupo:

Número de zonas	VMs extras	Total de VMs recomendado
2	+100%	200%
3	+50%	150%
4	+33%	133%

O número recomendado de VMs adicionais é inversamente proporcional ao número de zonas em que seu MIG está localizado. Portanto, é possível reduzir o número de VMs extras distribuindo de forma uniforme seu app por um número maior de zonas.

Como provisionar um MIG regional em três ou mais zonas

Quando você cria um MIG regional em uma região com pelo menos três zonas, o Google recomenda o provisionamento excessivo do seu grupo em pelo menos 50%. Por padrão, um MIG regional cria VMs em três zonas. Ter uma VM em três zonas já ajuda a preservar pelo menos dois terços da sua capacidade de veiculação e, se uma única zona falhar, as outras duas zonas na região poderão continuar a veicular tráfego sem interrupção. Ao aumentar o provisionamento em 150%, você garantirá que, mesmo no caso de perda de 1/3 da capacidade, 100% do tráfego será aceito pelas outras zonas.

Por exemplo, se você precisar de 20 VMs em seu MIG em três zonas, recomendamos pelo menos 50% das VMs. Nesse caso, 50% de 20 é mais 10 VMs, totalizando 30 VMs no grupo. Se você criar um MIG regional com um tamanho de 30, o grupo distribuirá suas VMs da maneira mais uniforme possível entre as três zonas, como:

Zona	Número de VMs
zona-de-exemplo-1	10
zona-de-exemplo-2	10
zona-de-exemplo-3	10

Se alguma zona falhar, você ainda terá 20 VMs veiculando tráfego.

Como provisionar um MIG regional em duas zonas

Para provisionar suas VMs em duas zonas em vez de três, o Google recomenda dobrar o número de VMs. Por exemplo, se você precisar de 20 VMs para seu serviço, distribuídas em duas zonas, recomendamos configurar um MIG regional com 40 VMs, para que cada zona tenha 20 VMs. Se uma única zona falhar, você ainda terá 20 VMs que veiculam tráfego.

Zona	Número de VMs
zona-de-exemplo-1	20
zona-de-exemplo-2	20

Se o número de VMs no seu grupo não for facilmente divisível entre duas zonas, o Compute Engine dividirá as VMs da maneira mais uniforme possível e colocará aleatoriamente as VMs restantes em uma das zonas.

Como provisionar um MIG regional em uma zona

É possível criar um MIG regional com apenas uma zona. Isso é semelhante à criação de um MIG zonal.

A criação de um MIG regional de zona única não é recomendada porque oferece a garantia mínima para aplicativos altamente disponíveis. Se a zona falhar, todo o MIG estará indisponível, possivelmente interrompendo os usuários.

Como selecionar zonas para um grupo

A configuração padrão para um MIG regional é distribuir as VMs da maneira mais uniforme possível em três zonas. No entanto, talvez você queira selecionar as zonas específicas do seu aplicativo por vários motivos. Por exemplo, se você precisar de GPUs para suas VMs, poderá selecionar apenas zonas compatíveis com GPUs. Talvez você tenha discos permanentes disponíveis apenas em determinadas zonas ou comece com VMs em apenas algumas zonas, e não em três zonas aleatórias em uma região.

Se você quiser escolher o número de zonas ou as zonas específicas em que o grupo deve ser executado, faça isso quando criar o grupo pela primeira vez. Após escolher as zonas específicas durante a criação, não será possível alterá-las ou atualizá-las mais tarde.

Para selecionar mais de três zonas dentro de uma região, especifique explicitamente as zonas individuais. Por exemplo, para selecionar as quatro zonas em uma região, você precisa fornecer todas elas explicitamente na sua solicitação. Se você não fizer isso, o Compute Engine selecionará três zonas por padrão.
Para selecionar até duas zonas em uma região, é preciso especificar explicitamente as zonas individuais. Mesmo que a região contenha apenas duas zonas, é necessário especificá-las claramente na solicitação.

Independentemente de você escolher zonas específicas ou apenas selecionar a região e permitir que o Compute Engine crie VMs em todas as zonas dentro da região, por padrão, as novas VMs são distribuídas uniformemente em todas as zonas. Como prática recomendada, forneça VMs de VM suficientes para oferecer suporte aos aplicativos no número especificado de zonas.

Como criar um MIG regional

Crie um MIG regional na ferramenta de linha de comando gcloud, no console ou na API.

Se não houver capacidade suficiente em cada zona para oferecer suporte a VMs para o grupo, o Compute Engine criará o maior número possível de VMs e continuará tentando criar as VMs restantes quando houver cota adicional disponível.

Como você está criando um MIG regional, lembre-se de que determinados recursos são zonais, como discos permanentes. Se você estiver especificando recursos por zona no modelo de instância, como discos permanentes adicionais, o disco precisará estar presente em todas as zonas para que possa ser anexado às VMs criadas por esse MIG regional.

Por padrão, se você não especificar explicitamente zonas individuais na solicitação, o Compute Engine escolherá automaticamente três zonas para criar VMs. Se você precisar criar VMs em mais ou menos de três zonas ou quiser escolher quais zonas serão usadas, forneça uma lista de zonas na solicitação. Para mais informações, consulte Como selecionar zonas para seu grupo.

Por padrão, a redistribuição proativa de instâncias está ativada. Se você precisar gerenciar manualmente o número de VMs em cada zona, desative a redistribuição proativa de instâncias e não poderá configurar o escalonamento automático. Para mais informações, consulte redistribuição proativa de instâncias.

Console

No Console do Cloud, acesse a página Grupos de instâncias.
Acessar a página "Grupos de instâncias"
Clique em Criar grupo de instâncias para criar um novo grupo.
Em Localização, selecione Várias zonas.
Escolha a região desejada.
Se você quiser escolher zonas específicas, clique em Configurar zonas para selecionar quais usar.
Se você quiser desativar a redistribuição proativa de instâncias, siga estas etapas:
1. Verifique se o Modo de escalonamento automático está definido como Desativado.
2. Defina a Redistribuição da instância como Desativado.
Selecione um modelo de instância para o grupo ou crie um modelo novo.
Especifique o número de VMs para este grupo. Lembre-se de provisionar VMs suficientes para dar suporte ao aplicativo se ocorrer uma falha de zona.
Continue com o restante do processo de criação do MIG.

gcloud

Todos os MIGs exigem um modelo de instância. Caso ainda não tenha um, crie um modelo de instância. Por exemplo, o comando a seguir cria um modelo básico de instância com propriedades padrão:

gcloud compute instance-templates create example-template

Em seguida, use o subcomando instance-groups managed create com a sinalização --region. Por exemplo, este comando cria um grupo de instâncias gerenciadas por região em três zonas dentro da região us-east1:

gcloud compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --region us-east1

Para selecionar as zonas específicas que o grupo usará, especifique a sinalização --zones:

gcloud compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --zones us-east1-b,us-east1-c

Para desativar a redistribuição proativa de instâncias, defina a sinalização --instance-redistribution-type como NONE. Não é possível desativar a redistribuição proativa de instâncias se o escalonamento automático estiver ativado.

gcloud compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --instance-redistribution-type NONE

API

Todos os MIGs exigem um modelo de instância. Caso ainda não tenha um, crie um modelo de instância.

Na API, crie uma solicitação POST para o método regionInstanceGroupManagers.insert. No corpo da solicitação, inclua o nome de grupo desejado, o tamanho do grupo, o nome base para as instâncias do grupo e o URL para o modelo de instância.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers

{
  "baseInstanceName": "base-instance-name",
  "instanceTemplate": "global/instanceTemplates/instance-template-name",
  "name": "instance-group-name",
  "targetSize": "target-size",
  "distributionPolicy": {
     "zones": [
       {"zone": "zones/zone"},
       {"zone": "zones/zone"}
      ]
   }
}

Substitua:

project-id: o ID do projeto para essa solicitação.
region: a região do grupo.
base-instance-name: o nome da instância de cada instância de VM criada como parte do grupo. Por exemplo, o nome de instância de base example-instance cria instâncias com nomes como example-instance-[RANDOM_STRING], em que [RANDOM_STRING] é gerado pelo servidor;
instance-template-name: o modelo de instância a ser usado.
instance-group-name: o nome do MIG;
target-size: o número desejado de VMs para o grupo.

Se você quiser selecionar zonas específicas ou criar VMs em uma região com menos ou mais de três zonas, inclua a propriedade distributionPolicy na solicitação e forneça uma lista de zonas. Substitua [ZONE] pelo nome da zona em que as VMs serão criadas.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers

{
  "baseInstanceName": "base-instance-name",
  "instanceTemplate": "global/instanceTemplates/instance-template-name",
  "name": "instance-group-size",
  "targetSize": "target-size",
  "distributionPolicy": {
     "zones": [
       {"zone": "zones/zone"},
       {"zone": "zones/zone"}
      ]
   }
}

Por exemplo, o seguinte cria um MIG regional chamado example-rmig com 10 instâncias gerenciadas distribuídas entre as zonas us-east1-b e us-east1-c:

POST https://compute.googleapis.com/compute/v1/projects/myproject/regions/us-east1/instanceGroupManagers

{

  "baseInstanceName": "example-instance",
  "instanceTemplate": "global/instanceTemplates/example-instance",
  "name": "example-rmig",
  "targetSize": 10,
  "distributionPolicy": {
      "zones": [
        {"zone": "zones/us-east1-b"},
        {"zone": "zones/us-east1-c"}
      ]
   }
}

Se você quiser desativar a redistribuição proativa de instâncias, inclua a propriedade updatePolicy na sua solicitação e defina instanceRedistributionType como NONE.

Não será possível desativar a redistribuição proativa de instâncias se o escalonamento automático estiver ativado.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers

{
  "baseInstanceName": "base-instance-name",
  "instanceTemplate": "global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
  "name": "instance-group-name",
  "targetSize": "target-size",
  "updatePolicy": {
     "instanceRedistributionType": "NONE"
   },
}

Listar instâncias de um grupo de instâncias regionais gerenciado

Para ver uma lista de instâncias gerenciadas para seu MIG regional, use o Console do Cloud, o comando instance-groups managed list-instances na ferramenta de linha de comando gcloud ou faça uma solicitação para o método regionInstanceGroupManagers.listManagedInstances.

Console

No Console do Cloud, acesse a página Grupos de instâncias.
Acessar a página "Grupos de instâncias"
Clique no nome do MIG regional do qual você quer visualizar as instâncias.

A página de detalhes do grupo de instâncias é carregada com uma lista de instâncias desse grupo.

gcloud

Execute o comando instance-groups managed list-instances:

gcloud compute instance-groups managed list-instances instance-group-name --region region

Substitua:

instance-group-name: o nome do MIG;
region: a região do MIG.

Por exemplo, o comando a seguir lista instâncias que fazem parte de um MIG chamado example-rmig na região us-east1:

gcloud compute instance-groups managed list-instances example-rmig --region us-east1

API

Na API, crie uma solicitação GET vazia para o método regionInstanceGroupManagers.listManagedInstances.

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name

Por exemplo:

GET https://compute.googleapis.com/compute/v1/projects/myproject/regions/us-east1/instanceGroupManagers/example-rmig

Como atualizar um grupo de instâncias gerenciadas por região

Você pode atualizar um MIG regional usando o recurso Updater. O Updater permite atualizar um subconjunto de VMs ou todas as VMs em um grupo para um novo modelo de instância. É possível também usar esse recurso para executar atualizações canário e controlar a velocidade da atualização.

Também é possível alterar o modelo de instância de um MIG sem atualizar as VMs existentes usando o comando set-instance-template em gcloud ou o método setInstanceTemplate na API. Observe que a alteração do modelo de instância não atualiza automaticamente as VMs existentes para o novo modelo de instância. Você precisa recriar instâncias individuais ou executar o Updater para aplicar as alterações. No entanto, novas VMs para o grupo usarão o novo modelo de instância.

Como desativar e reativar a redistribuição proativa de instâncias

A redistribuição proativa de instâncias mantém um número igual de VMs nas zonas selecionadas na região. Essa configuração maximiza a disponibilidade do aplicativo no caso de uma falha no nível da zona.

A redistribuição proativa de instâncias é ativada por padrão para MIGs regionais, mas é possível desativá-la para MIGs não escalonadas automaticamente. Quando a redistribuição proativa de instâncias é desativada, o grupo não tenta redistribuir proativamente as VMs entre as zonas. Isso é útil quando você precisa:

Excluir ou abandonar manualmente as instâncias gerenciadas do grupo sem afetar outras VMs em execução.
Excluir automaticamente uma VM de worker em lote após a conclusão do job sem afetar outros workers.
Proteger as VMs com aplicativos com estado contra exclusão automática não intencional por redistribuição proativa de instâncias.

Se você excluir ou abandonar instâncias gerenciadas do grupo e causar um desequilíbrio entre as VMs entre as zonas, será necessário reequilibrar o grupo manualmente antes de reativar a redistribuição proativa. Para redimensionar o grupo manualmente, redimensione-o ou exclua instâncias gerenciadas de zonas com mais VMs.

Quando você redimensiona um MIG com a redistribuição proativa de instâncias desativada, o grupo ainda converte de maneira oportuna para o equilíbrio, tratando cada operação de redimensionamento como uma oportunidade de equilibrar o grupo: quando o grupo cresce, ele sempre tenta adicionar VMs às zonas com o menor número de VMs; quando diminui, ele sempre remove as VMs das zonas com o maior número de VMs.

*Exemplo de redimensionamento manual de um grupo para conseguir redistribuição uniforme*

Use o console, a ferramenta gcloud ou a API para criar uma MIG regional com a redistribuição proativa de instâncias desativada ou para ativá-la ou desativá-la em um grupo existente.

Como criar um grupo com a redistribuição proativa desativada

Console

No Console do Cloud, acesse a página Grupos de instâncias.
Acessar a página "Grupos de instâncias"
Clique em Criar grupo de instâncias para criar um novo grupo.
Em Localização, selecione Várias zonas.
Escolha a região desejada.
Se você quiser escolher zonas específicas, clique em Configurar zonas para selecionar quais usar.
Para desativar a redistribuição proativa de instâncias, siga estas etapas:
1. Verifique se o Modo de escalonamento automático está definido como Desativado.
2. Defina Redistribuição de instâncias como Desativada.
Escolha um modelo de instância para o grupo ou crie um novo.
Especifique o número de VMs para este grupo. Lembre-se de provisionar VMs suficientes para dar suporte ao aplicativo se ocorrer uma falha de zona.
Continue com o restante do processo de criação do MIG.

gcloud

Para criar um novo MIG regional sem redistribuição proativa de instâncias, use o comando gcloud compute instance-groups managed create com a sinalização --instance-redistribution-type definida como NONE.

gcloud compute instance-groups managed create instance-group-name \
    --template template \
    --size target-size \
    --zones zones \
    --instance-redistribution-type NONE

Substitua:

instance-group-name: o nome do MIG.
template: o nome do modelo de instância a ser usado para o grupo.
target-size: o tamanho de destino do grupo.
zones: a lista de zonas em uma única região em que você precisa implantar VMs.

Por exemplo:

gcloud compute instance-groups managed create example-rmig \
    --template example-template \
    --size 30 \
    --zones us-east1-b,us-east1-c \
    --instance-redistribution-type NONE

API

Para criar um MIG regional sem escalonamento automático sem redistribuição proativa de instâncias, crie uma solicitação POST para invocar o método regionInstanceGroupManagers.insert. No corpo da solicitação, inclua a propriedade updatePolicy e defina o respectivo campo instanceRedistributionType como NONE.

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name { "name": "instance-group-name", "baseInstanceName": "base-instance-name", "instanceTemplate": "global/instanceTemplates/template", "targetSize": "target-size", "distributionPolicy": { "zones": [ {"zone": "zones/zone"}, {"zone": "zones/zone"} ] }, "updatePolicy": { "instanceRedistributionType": "NONE" } }

Replace the following:

project-id. The project ID for this request.
region. The region for the instance group.
instance-group-name. The name for the MIG.
base-instance-name. The name prefix for each instance. The instance name suffix is auto generated.
template. The name of the instance template to use for the group.
target-size. The target size of the instance group.
zone. The name of a zone in the single region where you need to deploy VMs.

Como desativar a redistribuição proativa de instâncias

Antes de desativar a redistribuição proativa de instâncias, é preciso desativar o escalonamento automático.

Console

No Console do Cloud, acesse a página Grupos de instâncias.
Acessar a página "Grupos de instâncias"
Selecione o MIG a ser atualizado e clique em Editar grupo.
Verifique se o Modo de escalonamento automático está definido como Desativado.
Defina Redistribuição de instâncias como Desativado para desativar a redistribuição automática.
Clique em Salvar.

gcloud

Para desativar a redistribuição proativa de instâncias para um MIG regional não escalonado automaticamente, use o comando compute instance-groups managed update com a sinalização --instance-redistribution-type definida como NONE.

gcloud compute instance-groups managed update instance-group-name
    --instance-redistribution-type NONE 

    --region region

Substitua:

instance-group-name: o nome do MIG.
region: a região do grupo de instâncias.

API

Na API, crie uma solicitação PATCH para o método regionInstanceGroupManagers.patch. No corpo da solicitação, inclua a propriedade updatePolicy e defina o respectivo campo instanceRedistributionType como NONE

 PATCH https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/[instance-group-name

{
    "updatePolicy": {
         "instanceRedistributionType": "NONE"
    }
}

Substitua:

project-id: o ID do projeto para essa solicitação.
region: a região do grupo de instâncias.
instance-group-name: o nome de um MIG não escalonado automaticamente.

Como ativar a distribuição proativa de instâncias

Para ativar a distribuição proativa de instâncias, use um comando semelhante ao visto em Como desativar a redistribuição proativa de instâncias, mas defina o tipo de redistribuição de instâncias como PROACTIVE.

Se você tiver excluído ou abandonado manualmente algumas instâncias gerenciadas que resultam em uma distribuição desigual de VMs na região, antes de reativar a redistribuição proativa de instâncias, será necessário reequilibrar manualmente o grupo. A diferença no número de VMs entre duas zonas não deve exceder uma VM.

É possível conseguir uma distribuição uniforme de instâncias entre zonas manualmente excluindo VMs de zonas com mais instâncias ou redimensionando o grupo para preencher as zonas com menos VMs até que a distribuição seja uniforme.

Um MIG regional não permite ativar a redistribuição proativa de instâncias quando as VMs são distribuídas de maneira uniforme entre as zonas (a diferença no número de VMs entre duas zonas é de duas ou mais VMs). Isso evita uma exclusão automática não intencional de VMs de zonas com mais VMs, o que seria acionado para atingir a distribuição uniforme.

Escalonar um grupo de instâncias regionais gerenciado automaticamente

O Compute Engine oferece escalonamento automático para MIGs, que permite que seus grupos adicionem automaticamente VMs (escalonamento horizontal) ou removam VMs (escalonamento vertical) com base em aumentos ou reduções de carga.

Se você ativar o escalonamento automático para um MIG regional, o recurso se comportará da seguinte maneira:

Uma política de escalonamento automático é aplicada ao grupo como um todo, não a zonas individuais. Por exemplo, se você ativar o escalonador automático para segmentar 66% de utilização da CPU, ele acompanhará todas as VMs no grupo para manter uma utilização média de 66% em todas as VMs em todas as zonas.
O escalonamento automático tenta distribuir uniformemente as VMs entre as zonas disponíveis quando possível. Em geral, o escalonador automático mantém o tamanho das zonas equilibrado aumentando zonas menores e esperando que a carga seja redirecionada de zonas maiores, por exemplo, por meio de um balanceador de carga. Não recomendamos configurar um balanceador de carga personalizado que dê preferência a uma zona, porque isso pode acarretar comportamento inesperado.
Se o fluxo de trabalho usar VMs uniformemente em três zonas e uma zona sofrer uma falha ou um grupo de VMs dentro de uma zona falhar, 1/3 da capacidade poderá ser perdida, mas ainda teremos 2/3 da capacidade nas outras zonas. Recomendamos que você superprovisione seu MIG regional com escalonamento automático para evitar sobrecarregar os servidores existentes durante o tempo em que um fuso horário é perdido.
Se os recursos (por exemplo, VMs preemptivas) estiverem temporariamente indisponíveis em uma zona, o grupo continuará tentando criar essas VMs nessa zona. Depois que os recursos forem disponibilizados novamente, o grupo adquirirá o número necessário de VMs em execução.
Se o balanceamento de carga estiver ativado e os recursos estiverem indisponíveis em uma zona causando maior utilização dos recursos existentes nessa zona, novas VMs poderão ser criadas em zonas com taxas de utilização menores, o que pode resultar em uma distribuição desigual temporária.

O escalonador automático só adiciona VMs a uma zona até 1/n do máximo especificado para o grupo, em que n é o número de zonas provisionadas. Por exemplo, se você usar o padrão de três zonas e se 15 for o maxNumReplicas configurado para escalonamento automático, o escalonador automático só poderá adicionar até 1/3 * 15 = 5 VMs por zona para o grupo. Se uma zona falhar, o escalonador automático só escalonará verticalmente até 2/3 do maxNumReplicas nas duas zonas combinadas restantes.

Como provisionar a configuração do escalonador automático

Assim como as orientações sobre o provisionamento excessivo de um MIG, você precisa provisionar em excesso a configuração do escalonador automático para que:

A meta de utilização do escalonador automático é 2/3 da meta pretendida.
Para acomodar a meta de utilização reduzida, o escalonador automático adicionará mais VMs. Portanto, você precisa aumentar o maxNumReplicas para ser 50% maior do que o número definido sem considerar o provisionamento excessivo.

Por exemplo, se você espera que 20 VMs possam lidar com as cargas de pico e a utilização de destino seja 80%, defina o escalonador automático como:

2/3 * 0,8 = 0,53 ou 53% como meta de utilização em vez de 80%
3/2 * 20 = 30 para o número máximo de VMs em vez de 20

Essa configuração garante que, no caso de uma falha de zona única, o MIG não fique sem capacidade porque os 2/3 restantes de VMs conseguirão lidar com o aumento da carga da zona off-line (já que você reduziu bem a utilização do valor desejado abaixo de sua capacidade). No escalonador automático também são adicionadas novas VMs até o número máximo de VMs especificado para manter a meta de utilização de 2/3.

No entanto, não é recomendável confiar apenas no provisionamento excessivo do MIG para processar o aumento de carga. Como prática recomendada, o Google aconselha a realização de testes frequentes de carga de seus aplicativos para garantir que eles possam lidar com o aumento da utilização que pode ser causado por uma interrupção zonal removendo 1/3 das VMs.

Como ativar o escalonamento automático

Console

No Console do Cloud, acesse a página Grupos de instâncias.
Acessar a página "Grupos de instâncias"
Se você não tem um grupo de instâncias, crie um. Caso contrário, clique no nome de um MIG regional existente na lista.
Na página de detalhes do grupo de instâncias, clique no botão Editar grupo.
Em "Escalonamento automático", marque Ativado.
Preencha as propriedades para a configuração de escalonamento automático.
Salve as alterações.

gcloud

Na ferramenta de linha de comando gcloud, use o subcomando set-autoscaling para ativar o escalonamento automático regional, seguido pela sinalização --region. Para mais informações sobre como criar um autoescalador, leia a documentação sobre escalonamento automático.

Por exemplo, os snippets a seguir configuram um escalonador automático para um grupo de instâncias de exemplo. Substitua us-east1 pela região do grupo de instâncias gerenciadas e example-rmig pelo nome do grupo de instâncias gerenciadas regional:

gcloud compute instance-groups managed set-autoscaling example-rmig \
    --target-cpu-utilization 0.8 --max-num-replicas 5 --region us-east1

API

Para configurar o escalonamento automático regional na API, chame o [método regionAutoscalers.insert [(/compute/docs/reference/rest/v1/regionAutoscalers/insert)

POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/regionAutoscalers/

O corpo da solicitação precisa incluir os campos name, target e autoscalingPolicy. autoscalingPolicy precisa definir cpuUtilization e maxNumReplicas.

Para facilitar a identificação, recomendamos nomear o recurso escalonador automático de acordo com o recurso MIG que o utiliza.

{
 "name": "<var>autoscaler-name</var>",
 "target": "regions/us-east1/instanceGroupManagers/<var>instance-group-name</var>",
 "autoscalingPolicy": {
    "maxNumReplicas": <var>max-number-of-instances</var>,
    "cpuUtilization": {
       "utilizationTarget": <var>target-utilization</var>
     },
    "coolDownPeriodSec": <var>seconds</var>
  }
}

Por exemplo:

{
 "name": "example-rmig",
 "target": "regions/us-east1/instanceGroupManagers/example-rmig",
 "autoscalingPolicy": {
    "maxNumReplicas": 10,
    "cpuUtilization": {
       "utilizationTarget": 0.8
     },
    "coolDownPeriodSec": 30
  }
}

Como atualizar um escalonador automático

Atualize um autoescalador por região da mesma maneira que um autoescalador por zona. Leia a documentação sobre a atualização de um autoescalador.

Como adicionar um grupo de instâncias gerenciadas por região a um balanceador de carga

No Google Cloud Platform, o balanceamento de carga é feito usando os grupos de instâncias para exibir tráfego. Dependendo do tipo de balanceador de carga que você estiver usando, adicione grupos de instâncias a um pool de destino ou serviço de back-end. Para ler mais sobre grupos de instâncias gerenciadas e balanceamento de carga, consulte a Visão geral de grupos de instâncias.

Você pode atribuir um MIG regional como destino de um serviço de back-end para Balanceamento de carga externo e Balanceamento de carga interno ou como parte de um pool de destino para Balanceamento de carga de rede.

Para balanceamento de carga HTTP(S), apenas maxRatePerInstance e maxUtilization são compatíveis com MIGs regionais.

Adicionar um grupo de instâncias regionais gerenciado a um serviço de back-end

É necessário um serviço de back-end para criar os seguintes tipos de serviços de balanceamento de carga:

Balanceamento de carga HTTP(S) externo
Balanceamento de carga HTTP(S) interno
Balanceamento de carga de proxy SSL
Balanceamento de carga de proxy TCP
Balanceamento de carga TCP/UDP interno

Um serviço de back-end pode conter vários back-ends. Um grupo de instâncias é um tipo de back-end. As instâncias contidas no grupo respondem ao tráfego vindo do balanceador de carga. O serviço de back-end, por sua vez, sabe quais instâncias podem ser usadas, quanto tráfego elas podem processar e a quantidade de tráfego que estão processando no momento. Além disso, a verificação de integridade é monitorada no serviço de back-end, que não envia novas conexões para instâncias não íntegras.

Use as instruções para adicionar um grupo de instâncias gerenciadas a um serviço de back-end.

Console

Acesse a página "Balanceamento de carga" no Console do Cloud.
Acessar a página "Balanceamento de carga"
Selecione o nome do serviço de back-end ao qual você está adicionando o grupo de instâncias gerenciadas.
Clique em Editar.
Selecione +Adicionar back-end.
Selecione o grupo de instâncias que você quer adicionar.
Edite as configurações opcionais como quiser.
Salve as alterações.

gcloud

Com a ferramenta de linha de comando gcloud, use o comando add-backend:

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
        --instance-group=INSTANCE_GROUP \
        [--instance-group-region=INSTANCE_GROUP_REGION | --instance-group-zone=INSTANCE_GROUP_ZONE] \
        --balancing-mode=BALANCING_MODE

Parâmetros adicionais são necessários dependendo do modo de balanceamento do grupo de instâncias gerenciadas. Para mais informações, consulte o comando add-backend no SDK.

API

Para adicionar um serviço de back-end usando a API REST, consulte backendServices.

Como adicionar um grupo de instâncias gerenciadas por região a um pool de destino

Um pool de destino é um objeto que contém uma ou mais instâncias de máquina virtual. Ele é usado no Balanceamento de carga de rede, em que as solicitações do usuário são encaminhadas para o pool de destino associado ao balanceador de carga. As instâncias que fazem parte desse pool atendem essas solicitações e retornam uma resposta. Adicione um grupo de instâncias gerenciadas a um pool de destino para que, quando as instâncias forem adicionadas ou removidas do grupo, o pool também seja atualizado automaticamente com as alterações.

Para adicionar um grupo de instâncias gerenciadas a um pool de destino, é preciso que esse pool já exista. Para mais informações, consulte a documentação Como adicionar um pool de destino.

Para adicionar um grupo de instâncias gerenciadas a um pool de destino, execute as etapas a seguir. Isso faz com que todas as instâncias de VM contidas no grupo sejam adicionadas ao pool de destino.

Console

Acesse a página "Pools de destino" no Console do Cloud.
Acessar a página "Pools de destino"
Clique no pool de destino para adicionar o grupo de instâncias.
Clique no botão Editar.
Role para baixo até a seção Instâncias da VMs e clique em Selecionar grupos de instâncias.
Selecione um grupo de instâncias no menu suspenso.
Salve as alterações.

gcloud

Na ferramenta de linha de comando gcloud, use o comando set-target-pools:

gcloud beta compute instance-groups managed set-target-pools [INSTANCE_GROUP] \
    --target-pools [TARGET_POOL,..] [--region REGION]

em que:

[INSTANCE_GROUP] é o nome do grupo de instâncias;
[TARGET_POOL] é o nome de um ou mais pools de destino aos quais adicionar este grupo de instâncias;
[REGION] é a região do grupo de instâncias.

API

Na API, faça uma solicitação POST para o seguinte URI:

POST https://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/regionInstanceGroupManagers/[INSTANCE_GROUP]/setTargetPools

em que:

[PROJECT_ID] é o ID do projeto da solicitação;
[REGION] é a região do grupo de instâncias;
[INSTANCE_GROUP] é o nome do grupo de instâncias.

O corpo da solicitação conterá uma lista de URIs para os pools de destino a que você quer adicionar esse grupo. Por exemplo:

{
  "targetPools": [
    "regions/us-central1/targetPools/example-targetpool-1",
    "regions/us-central1/targetPools/example-targetpool-2"
  ]
}

Simular uma falha de zona para um grupo de instâncias regionais gerenciado

Para testar se o MIG regional está superprovisionado o suficiente e pode resistir a uma interrupção de zona, use o exemplo a seguir para simular uma única falha de zona.

Neste script, o Apache é interrompido e iniciado como o cenário padrão. Caso isso não se aplique ao aplicativo, substitua os comandos que interrompem e iniciam o Apache pelo seu próprio cenário de falha e recuperação.

Implante e execute esse script continuamente em todas as VMs do grupo. Para fazer isso, adicione o script ao modelo da instância ou inclua esse script a uma imagem personalizada e use essa imagem no modelo.

zone_failure/failure.sh

Ver no GitHub

#!/usr/bin/env bash

# Copyright 2016 Google Inc. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

set -o nounset
set -o errexit
set -o pipefail

function GetMetadata() {
  curl -s "$1" -H "Metadata-Flavor: Google"
}

PROJECT_METADATA_URL="http://metadata.google.internal/computeMetadata/v1/project/attributes"
INSTANCE_METADATA_URL="http://metadata.google.internal/computeMetadata/v1/instance"
ZONE=$(GetMetadata "$INSTANCE_METADATA_URL/zone" | cut -d '/' -f 4)
INSTANCE_NAME=$(hostname)

# We keep track of the state to make sure failure and recovery is triggered only once.
STATE="healthy"
while true; do
  if [[ "$ZONE" = "$(GetMetadata $PROJECT_METADATA_URL/failed_zone)" ]] && \
     [[ "$INSTANCE_NAME" = *"$(GetMetadata $PROJECT_METADATA_URL/failed_instance_names)"* ]]; then
    if [[ "$STATE" = "healthy" ]]; then
      STATE="failure"
      # Do something to simulate failure here.
      echo "STARTING A FAILURE"
      /etc/init.d/apache2 stop
    fi
  else
    if [[ "$STATE" = "failure" ]] ; then
      STATE="healthy"
      # Do something to recover here.
      echo "RECOVERING FROM FAILURE"
      /etc/init.d/apache2 start
    fi
  fi
  sleep 5
done

Simule uma falha de zona definindo estes dois campos de metadados do projeto:
- failed_zone: define a zona em que simular a falha (limite a falha a apenas uma zona);
- failed_instance_names: escolha as VMs que ficarão off-line por nome (para limitar a falha apenas a nomes de VM que contenham essa string).
É possível definir esses metadados usando a ferramenta de linha de comando gcloud. Por exemplo, o comando a seguir define a interrupção da zona como a zona europe-west1-b e afeta as VMs que têm nomes que começam com instance-base-name:
```
gcloud compute project-info add-metadata --metadata failed_zone='europe-west1-b',failed_instance_names='instance-base-name-'
```

Depois de simular a falha, execute a recuperação removendo as chaves de metadados:

gcloud compute project-info remove-metadata --keys failed_zone,failed_instance_names

Aqui estão algumas ideias de cenários de falha que podem ser executados com esse script:

Interrompa seu aplicativo completamente para ver como o MIG responde.
Faça com que suas VMs retornem como "não íntegras" nas verificações de integridade de balanceamento de carga.
Modifique o iptables para bloquear parte do tráfego de e para a VM.
Encerre as VMs. Por padrão, ele será recriado pelo MIG regional logo após, mas a nova encarnação será encerrada imediatamente assim que o script for executado e enquanto os valores de metadados forem definidos. Isso acarreta um loop de falha.

A seguir

Saiba como criar aplicativos altamente disponíveis com MIGs regionais e balanceamento de carga.
Leia sobre balanceamento de carga.
Leia sobre escalonamento automático.
Saiba como criar aplicativos da Web escalonáveis e resilientes.
Saiba mais sobre a recuperação de desastres no Google Cloud Platform.