Como distribuir instâncias usando MIGs regionais

Nesta página, descrevemos como criar grupos de instâncias gerenciadas (MIGs, na sigla em inglês) com instâncias distribuídas em uma única região.

Ao contrário dos grupos de instâncias gerenciadas por zonas, que pertencem a uma única zona, os grupos de instâncias gerenciadas por região melhoram a disponibilidade do aplicativo porque distribuem as instâncias por várias zonas dentro de uma única região. Por exemplo, por padrão, um grupo de instâncias gerenciadas por região em us-east1 mantém uma distribuição uniforme das instâncias em três zonas dentro da região: us-east1-b, us-east1-c e us-east1-d.

No caso das regiões que contêm mais de três zonas, o grupo de instâncias gerenciadas por região seleciona três zonas onde criar as instâncias. Também é possível escolher seletivamente as zonas onde criar instâncias ou usar regiões com menos de três zonas. Por exemplo, para acelerar as cargas de trabalho com GPUs, selecione as zonas compatíveis com GPUs.

Assim como os grupos de instâncias gerenciadas por zona, os grupos por região são compatíveis com escalonamento automático e balanceamento de carga interno e externo.

Antes de começar

Limitações

  • Cada grupo de instâncias gerenciadas por região pode conter até 2.000 instâncias.
  • Na atualização de um grupo de instâncias gerenciadas, é possível especificar no máximo 1.000 instâncias em uma única solicitação.
  • Não é possível usar grupos de instâncias gerenciadas por região com um balanceador de carga que usa a opção maxRate de balanceamento.

Como selecionar grupos de instâncias gerenciadas por região

O Google recomenda usar grupos de instâncias gerenciadas por região porque eles permitem distribuir a carga do aplicativo por várias zonas, ao contrário dos grupos de instâncias gerenciadas por zona que limitam o aplicativo a uma única zona. Além disso, com os grupos de instâncias gerenciadas por região, não é necessário gerenciar vários grupos de instâncias em diferentes zonas. Essa replicação proporciona proteção contra falhas nas zonas e cenários imprevistos, como problemas no funcionamento de um grupo inteiro de instâncias em uma única zona. Se esse tipo de problema ocorrer, o aplicativo poderá continuar a disponibilizar o tráfego a partir de instâncias em execução em outra zona na mesma região.

No caso de uma falha da zona ou se um grupo de instâncias em uma zona parar de responder, um grupo de instâncias gerenciadas por região continuará auxiliando as instâncias de VM da maneira a seguir:

  • As instâncias que fazem parte do grupo de instâncias gerenciadas por região nas zonas restantes continuarão a exibir tráfego. Novas instâncias não serão adicionadas e nenhuma será redistribuída, a menos que você tenha configurado o escalonamento automático.

  • Após a recuperação da zona com falha, o grupo de instâncias voltará a exibir o tráfego dela.

Para desenvolver aplicativos robustos e escalonáveis, use grupos de instâncias gerenciadas por região.

Redistribuição proativa de instâncias

Por padrão, um grupo de instâncias gerenciadas por região tenta manter uma distribuição uniforme das instâncias de VM entre as zonas da região para maximizar a disponibilidade do seu aplicativo no caso de uma falha no nível da zona.

Se você excluir ou abandonar instâncias de VM de seu grupo, causando uma distribuição desigual entre as zonas, o grupo redistribuirá de maneira proativa as instâncias para restabelecer uma distribuição uniforme.

Para restabelecer uma distribuição uniforme entre zonas, o grupo exclui instâncias das zonas com mais instâncias de VM e adiciona novas instâncias às zonas com menos instâncias de VM. O grupo escolhe automaticamente quais instâncias excluir.

A redistribuição proativa restabelece distribuições uniformes em zonas
Exemplo de redistribuição proativa

Por exemplo, suponha que você tenha um grupo de instâncias gerenciadas por região com quatro instâncias distribuídas por três zonas: a, b e c. Se você excluir três instâncias de VM de c, o grupo tentará se reequilibrar para que as instâncias sejam novamente distribuídas de maneira uniforme entre as 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 de instâncias, é possível desativar a redistribuição proativa de instâncias ao criar ou atualizar um grupo de instâncias gerenciadas por região.

Isso é útil quando você precisa fazer o seguinte:

  • Excluir ou abandonar as VMs do grupo sem afetar outras instâncias de VM em execução. Por exemplo, é possível excluir uma instância de VM de worker em lote após a conclusão do job sem afetar outros workers.
  • Proteger VMs que têm aplicativos 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 grupo de instâncias gerenciadas não adicionará ou removerá instâncias de maneira proativa para conseguir o balanceamento. No entanto, ele ainda convergirá de modo oportuno para o balanceamento durante as operações de redimensionamento, tratando cada uma delas como uma oportunidade de balancear o grupo. Por exemplo, ao reduzir, o grupo usa automaticamente o redimensionamento como uma oportunidade para remover instâncias de zonas maiores. Ao expandir, o grupo usa a oportunidade para adicionar instâncias a zonas menores.

Como provisionar o tamanho correto do grupo de instâncias gerenciadas para garantir a disponibilidade

Diversos eventos podem fazer com que uma ou mais instâncias fiquem indisponíveis. É possível atenuar esse problema usando vários serviços do Google Cloud:

No entanto, mesmo se você usar esses serviços, os usuários ainda poderão ter problemas se houver muitas instâncias indisponíveis ao mesmo tempo.

A fim de se preparar para o caso extremo em que uma zona falha ou um grupo inteiro de instâncias para de responder, o Google recomenda enfaticamente provisionar mais grupos de instâncias gerenciadas. Dependendo das necessidades do aplicativo, aumentar o provisionamento do grupo impede que o sistema falhe completamente caso uma zona ou um grupo de instâncias pare 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 o provisionamento e o pagamento de mais instâncias de VM do que as normalmente necessárias para o aplicativo. Baseie suas decisões de provisionamento nas necessidades do aplicativo e nas limitações de custo.

Como estimar o tamanho recomendado do grupo de instâncias

No Compute Engine, é recomendável provisionar instâncias suficientes para que, caso todas as instâncias de qualquer zona fiquem indisponíveis, as restantes consigam atender ao número mínimo necessário.

Use a tabela a seguir para determinar o tamanho mínimo recomendado para seu grupo de instâncias:

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 extras é inversamente proporcional ao número de zonas em que seu grupo de instâncias gerenciadas está localizado. Portanto, é possível reduzir o número de VMs extras distribuindo de forma uniforme seu aplicativo por um número maior de zonas.

Como provisionar um grupo de instâncias gerenciadas por região em três ou mais zonas

Ao criar um grupo regional de instâncias gerenciadas em uma região com pelo menos três zonas, o Google recomenda aumentar o provisionamento do seu grupo de instâncias em pelo menos 50%. Por padrão, um grupo de instâncias gerenciadas por região cria instâncias em três zonas. Distribuir instâncias de VM por três zonas ajuda a preservar pelo menos 2/3 da capacidade de serviço, uma vez que as outras duas zonas da região continuam a fornecer o tráfego ininterruptamente, caso uma delas falhe. 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ê precisa de 20 instâncias de VM em seu grupo de instâncias gerenciadas em três zonas, recomendamos pelo menos um adicional de 50% de instâncias. Nesse caso, 50% de 20 corresponde a 10 instâncias extras, totalizando 30 instâncias no grupo. Se você criar um grupo de instâncias gerenciadas por região de tamanho 30, ele distribuirá suas instâncias da maneira mais uniforme possível entre as três zonas, da seguinte maneira:

Zona Número de instâncias
zona-de-exemplo-1 10
zona-de-exemplo-2 10
zona-de-exemplo-3 10

Se uma única zona falhar, você ainda terá 20 instâncias para disponibilizar o tráfego.

Como provisionar um grupo de instâncias gerenciadas por região em duas zonas

Para provisionar suas instâncias em duas zonas em vez de três, o Google recomenda dobrar o número de instâncias. Por exemplo, se você precisar de 20 instâncias de VM para seu serviço distribuídas em duas zonas, recomendamos configurar um grupo de instâncias gerenciadas por região com 40 instâncias para que cada zona fique com 20. Se uma única zona falhar, você ainda terá 20 instâncias para fornecer o tráfego.

Zona Número de instâncias
zona-de-exemplo-1 20
zona-de-exemplo-2 20

Se o número de instâncias em seu grupo não puder ser divisível facilmente em duas zonas, o Compute Engine dividirá as instâncias da maneira mais uniforme possível e colocará aleatoriamente as instâncias restantes em uma das zonas.

Como provisionar um grupo de instâncias gerenciadas por região em uma zona

É possível criar um grupo de instâncias gerenciadas por região com apenas uma zona. Isso é semelhante à criação de um grupo de instâncias gerenciadas por zona.

No entanto, isso não é recomendável porque oferece a garantia mínima para aplicativos altamente disponíveis. Se a zona falhar, todo o grupo de instâncias gerenciadas ficará indisponível, com a possibilidade de prejudicar os usuários.

Como selecionar zonas para um grupo

A configuração padrão de um grupo de instâncias gerenciadas por região é distribuir as instâncias da maneira mais uniforme possível por 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 instâncias, selecione apenas as zonas compatíveis com GPUs. É possível ter discos permanentes disponíveis somente em determinadas zonas ou começar com instâncias de VM em apenas algumas zonas, em vez de em três zonas aleatórias dentro de uma região.

Se quiser escolher o número de zonas ou as zonas específicas em que o grupo de instâncias precisa executar, é preciso fazer isso na primeira vez que você criar o grupo. Após a escolha de 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 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, ainda é necessário especificá-las explicitamente na solicitação.

Não importa se você escolher zonas específicas ou apenas selecionar a região e deixar o Compute Engine criar instâncias em todas as zonas da região, por padrão, as novas instâncias de VM são distribuídas igualmente entre todas as zonas. Como prática recomendada, verifique se você provisionou instâncias de VM o suficiente para auxiliar seus aplicativos no número especificado de zonas.

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

Crie um grupo de instâncias gerenciadas por região na ferramenta de linha de comando gcloud, no console ou na API.

Quando não há capacidade suficiente em cada zona para aceitar as instâncias do grupo, o Compute Engine cria o máximo possível de instâncias e, conforme as cotas extras ficam disponíveis, ele continua a criar as restantes.

Como você está criando um grupo de instâncias gerenciadas por região, lembre-se de que determinados recursos, como os discos permanentes, são definidos por zona. Quando você especifica recursos de zona no modelo de instância, como discos permanentes extras, o disco precisa estar presente em todas as zonas para ser anexado às instâncias criadas no grupo de instâncias gerenciadas por região.

Por padrão, se você não especificar explicitamente as zonas individuais em sua solicitação, o Compute Engine escolherá automaticamente três zonas para criar instâncias. Se precisar criar instâncias em mais de ou menos de três zonas, ou se quiser escolher quais zonas serão usadas, forneça uma lista de zonas em sua 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ê precisa gerenciar manualmente o número de instâncias em cada zona, é possível desativar a redistribuição proativa de instâncias e não é possível configurar o escalonamento automático. Para mais informações, consulte redistribuição proativa de instâncias.

Console

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acessar a página "Grupos de instâncias"

  2. Clique em Criar grupo de instâncias para criar um novo grupo.
  3. Em Localização, selecione Várias zonas.
  4. Escolha a região pretendida.
  5. Se quiser escolher zonas específicas, clique em Configurar zonas para selecionar quais usar.
  6. 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.
  7. Selecione um modelo de instância para o grupo ou crie um modelo novo.
  8. Especifique o número de instâncias do grupo. Lembre-se de provisionar instâncias suficientes para fazer com que o aplicativo continue a funcionar se uma zona falhar.
  9. Continue com o restante do processo de criação do grupo de instâncias gerenciadas.

gcloud

É obrigatório usar um modelo de instância para todos os grupos de instâncias gerenciadas. 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 será 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

É obrigatório usar um modelo de instância para todos os grupos de instâncias gerenciadas. 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 do grupo pretendido, 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]"}
          ]
       }
    }

em que:

  • [PROJECT_ID] é o ID do projeto da solicitação;
  • [REGION] é a região do grupo de instâncias;
  • [BASE_INSTANCE_NAME] é o nome de cada instância 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;
  • [TARGET_SIZE] é o número limite de instâncias do grupo.

Se você quiser selecionar zonas específicas ou se estiver criando instâncias em uma região com menos ou mais do que 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 criar as instâncias.

    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]"}
          ]
       }
    }

Por exemplo, o código a seguir cria um grupo de instâncias denominado "example-rmig" com 10 instâncias 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"
       },
    }

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

Para uma lista do seu grupo de instâncias gerenciadas por região, 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 ao método regionInstanceGroupManagers.listManagedInstances.

Console

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acessar a página "Grupos de instâncias"

  2. Clique no nome do grupo de instâncias gerenciadas por região com as instâncias que você quer ver.

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]

em que:

  • [INSTANCE_GROUP_NAME] é o nome do grupo de instâncias;
  • [REGION] é a região do grupo de instâncias.

Por exemplo, o comando a seguir lista instâncias que fazem parte de um grupo de instâncias denominado 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

É possível atualizar um grupo de instâncias gerenciadas por região usando o recurso Atualizador de grupo de instâncias. O Atualizador permite atualizar um subconjunto de suas instâncias ou todas elas dentro de 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.

De maneira semelhante, também é possível alterar o modelo de instância de um grupo sem atualizar as instâncias atuais usando o comando set-instance-template no gcloud ou o método setInstanceTemplate na API. A alteração do modelo de instância não atualiza automaticamente as instâncias atuais com o novo modelo de instância. É preciso recriar as instâncias individuais ou executar o Atualizador de grupo de instâncias para aplicar as alterações. No entanto, as instâncias de VM recém-adicionadas ao 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 instâncias 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 grupos de instâncias gerenciadas por região, mas é possível desativá-la para grupos de instâncias gerenciadas sem escalonamento automático. Quando a redistribuição proativa de instâncias está desativada, o grupo não tenta redistribuir proativamente as instâncias entre as regiões. Isso é útil quando você precisa fazer o seguinte:

  • Excluir ou abandonar manualmente as instâncias de VM do grupo sem afetar outras instâncias em execução.
  • Excluir automaticamente uma instância de worker em lote após a conclusão do job sem afetar outros workers.
  • Proteger instâncias 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 de VM do grupo e causar um desequilíbrio de instâncias entre as zonas, será preciso reequilibrar manualmente o grupo antes de reativar a redistribuição proativa. Para reequilibrar manualmente o grupo, redimensione-o ou exclua instâncias de zonas com mais instâncias.

Quando você redimensiona um grupo de instâncias gerenciadas que está com a redistribuição proativa de instâncias desativada, o grupo ainda converge para o balanceamento de maneira oportuna, tratando cada operação de redimensionamento como uma oportunidade de balancear o grupo. Quando o grupo cresce, ele sempre tenta adicionar instâncias às zonas com o menor número de VMs. Quando o grupo diminui, ele sempre remove instâncias das zonas com o maior número de instâncias.

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

Use o console, a ferramenta gcloud ou a API para criar um grupo de instâncias com a redistribuição proativa de instâncias desativada ou para ativar ou desativar a redistribuição de instâncias de um grupo atual.

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

Console

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acessar a página "Grupos de instâncias"

  2. Clique em Criar grupo de instâncias para criar um novo grupo.
  3. Em Localização, selecione Várias zonas.
  4. Escolha a região pretendida.
  5. Se quiser escolher zonas específicas, clique em Configurar zonas para selecionar quais usar.
  6. 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.
  7. Selecione um modelo de instância para o grupo ou crie um modelo novo.
  8. Especifique o número de instâncias do grupo. Lembre-se de provisionar instâncias suficientes para fazer com que o aplicativo continue a funcionar se uma zona falhar.
  9. Continue com o restante do processo de criação do grupo de instâncias gerenciadas.

gcloud

Para criar um novo grupo de instâncias gerenciadas por região 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 [SIZE] \
        --zones [ZONES] \
        --instance-redistribution-type NONE

Em que:

  • [INSTANCE_GROUP_NAME] é o nome do grupo de instâncias;
  • [TEMPLATE] é o nome do modelo de instância a ser usado para o grupo;
  • [SIZE] é o tamanho de destino do grupo de instâncias;
  • [ZONES] é a lista de zonas em uma única região em que você precisa implantar instâncias de VM.

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 grupo de instâncias gerenciadas por região sem escalonamento automático e 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"
        }
    }

Em que:

  • [PROJECT_ID] é o ID do projeto da solicitação;
  • [REGION] é a região do grupo de instâncias;
  • [INSTANCE_GROUP_NAME] é o nome do grupo de instâncias;
  • [BASE_INSTANCE_NAME] é o prefixo do nome de cada instância. O sufixo do nome da instância é gerado automaticamente;
  • [TEMPLATE] é o nome do modelo de instância a ser usado para o grupo;
  • [TARGET_SIZE] é o tamanho de destino do grupo de instâncias;
  • [ZONE] é o nome de uma zona na região única em que você precisa implantar instâncias de VM.

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

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acessar a página "Grupos de instâncias"

  2. Selecione o grupo de instâncias a ser atualizado e clique em Editar grupo.
  3. Verifique se o Modo de escalonamento automático está definido como Desativado.
  4. Defina Redistribuição de instâncias como Desativado para desativar a redistribuição automática.
  5. Clique em Salvar.

gcloud

Para desativar a redistribuição proativa de instâncias para um grupo de instâncias gerenciadas por região sem escalonamento automático, 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]

em que:

  • [INSTANCE_GROUP_NAME] é o nome do grupo de instâncias;
  • [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]

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

em que:

  • [PROJECT_ID] é o ID do projeto da solicitação;
  • [REGION] é a região do grupo de instâncias;
  • [INSTANCE_GROUP] é o nome de um grupo de instâncias gerenciadas sem escalonamento automático.

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ê excluiu ou abandonou manualmente algumas instâncias e causou uma distribuição desigual de instâncias na região, antes de reativar a redistribuição proativa de instâncias, reequilibre manualmente o grupo. A diferença no número de instâncias de VM entre duas zonas não pode ultrapassar uma VM.

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

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

Como realizar o escalonamento automático de um grupo de instâncias gerenciadas por região

O Compute Engine oferece escalonamento automático de grupos de instâncias gerenciadas, permitindo que seus grupos adicionem ou removam instâncias automaticamente com base em aumentos ou reduções de carga.

Quando você ativa o escalonamento automático de um grupo de instâncias gerenciadas por região, o recurso funciona 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 66% de utilização de CPU, ele rastreará todas as instâncias no grupo para manter uma utilização média de 66% em todas as instâncias de todas as zonas.

  • O escalonamento automático tenta distribuir as instâncias de maneira uniforme pelas 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 seu fluxo de trabalho usa instâncias de maneira uniforme em três zonas e uma zona ou um grupo de instâncias falha, 1/3 de capacidade pode ser perdido, mas 2/3 permanecem nas outras zonas. Recomendamos que você aumente o provisionamento do seu grupo de instâncias gerenciadas por região escalonado automaticamente para evitar sobrecarregar os servidores sobreviventes durante o período em que uma zona estiver perdida.

  • Se certos recursos, como instâncias preemptivas, estiverem temporariamente indisponíveis em uma zona, o grupo continuará tentando criar essas instâncias gerenciadas nessa zona. Após os recursos ficarem disponíveis novamente, o grupo receberá o número pretendido de instâncias em execução.

  • Se o balanceamento de carga estiver ativado e se os recursos estiverem indisponíveis em uma zona, causando uma maior utilização de recursos atuais nela, novas instâncias poderão ser criadas em zonas com menores taxas de utilização, o que pode acarretar uma distribuição temporária desigual.

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

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

Assim como na recomendação de superestimar o provisionamento de um grupo de instâncias gerenciadas, sugerimos que faça o mesmo na configuração do escalonador automático:

  • A meta de utilização do escalonador automático é 2/3 da meta pretendida.
  • Para se ajustar à meta de utilização reduzida, o escalonador automático adicionará mais instâncias. Isso significa que é preciso aumentar o valor de maxNumReplicas em 50% acima do número que seria definido sem considerar o provisionamento extra.

Por exemplo, caso queira que 20 instâncias sejam capazes de manipular seus picos de carga e que a meta de utilização seja 80%, configure o escalonador automático da maneira a seguir:

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

Essa configuração garante que, em caso de falha em uma única zona, a capacidade do grupo de instâncias não seja esgotada. Isso porque os outros 2/3 de instâncias precisam ser suficientes para manipular o aumento de carga proveniente da zona off-line, já que você reduziu a meta de utilização para um valor bem abaixo da capacidade. No escalonador automático, as novas instâncias também são adicionadas até alcançar o número máximo especificado de modo que a meta de utilização de 2/3 seja mantida.

Entretanto, não é recomendável contar exclusivamente com o provisionamento extra dos grupos de instâncias gerenciadas para processar o aumento de carga. Como prática recomendada, o Google aconselha a realização de testes de carga regulares nos seus aplicativos para garantir que você consiga administrar o aumento da utilização devido a uma falha de zona que remove 1/3 das instâncias.

Como ativar o escalonamento automático

Console

  1. No Console do Cloud, acesse a página Grupos de instâncias.

    Acessar a página "Grupos de instâncias"

  2. Se você não tem um grupo de instâncias, crie um. Caso contrário, clique no nome de um grupo de instâncias gerenciadas por região mostrado na lista.
  3. Na página de detalhes do grupo de instâncias, clique no botão Editar grupo.
  4. Em "Escalonamento automático", marque Ativado.
  5. Preencha as propriedades para a configuração de escalonamento automático.
  6. Salve as alterações.

gcloud

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

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

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 por região na API, envie uma solicitação POST para o seguinte URL, usando o ID do projeto e a região do grupo de instâncias gerenciadas:

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

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

{
     "name": "[AUTOSCALER_NAME]",
     "target": "regions/us-east1/instanceGroupManagers/[INSTANCE_GROUP_NAME]",
     "autoscalingPolicy": {
        "maxNumReplicas": [MAX_NUM_INSTANCES],
        "cpuUtilization": {
           "utilizationTarget": [TARGET_UTILIZATION]
         },
        "coolDownPeriodSec": [SECONDS]
      }
    }

Por exemplo:

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

Como atualizar um escalonador automático

Atualize um escalonador automático por região da mesma maneira que um por zona. Leia a documentação sobre a atualização de um escalonador automático.

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.

Designe um grupo de instâncias gerenciadas por região como o 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.

No balanceamento de carga HTTP(S), apenas maxRatePerInstance e maxUtilization são aceitos para grupos de instâncias gerenciadas por região.

Como adicionar um grupo de instâncias gerenciadas por região a um serviço de back-end

É necessário um serviço de back-end para criar um balanceador de carga de HTTP(S), de proxy SSL, de proxy TCP ou 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 da integridade é monitorada pelo serviço de back-end, que não envia novas conexões para instâncias não íntegras.

Leia Como adicionar grupos de instâncias a um serviço de back-end para ver instruções sobre esse procedimento.

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

  1. Acesse a página "Pools de destino" no Console do Cloud.

    Acessar a página "Pools de destino"

  2. Clique no pool de destino para adicionar o grupo de instâncias.
  3. Clique no botão Editar.
  4. Role para baixo até a seção Instâncias da VM e clique em Selecionar grupos de instâncias.
  5. Selecione um grupo de instâncias no menu suspenso.
  6. 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"
      ]
    }

Como simular uma falha de zona em um grupo de instâncias gerenciadas por região

Para testar se o provisionamento do grupo de instâncias gerenciadas por região que foi aumentado é suficiente e resiste a uma falha de zona, use o exemplo a seguir para simular uma falha em uma única 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.

  1. Implante e execute este script em sequência para cada instância de máquina virtual do grupo de instâncias. 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 
    #!/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

  2. Simule uma falha de zona definindo estes dois campos de metadados do projeto:

    • failed_zone: define a zona em que você quer simular a falha (limite a falha a apenas uma zona).
    • failed_instance_names: escolha as instâncias que ficarão off-line por nome (para limitar a falha a somente os nomes de instâncias 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 falha para a zona europe-west1-b e afeta as instâncias com 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-'

  3. 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

Veja abaixo algumas ideias de cenários de falha que podem ser executados com esse script:

  • Interrompa o aplicativo completamente para ver como o grupo de instâncias gerenciadas responde.
  • Faça suas instâncias retornarem como “não íntegras” nas verificações de integridade do balanceamento de carga.
  • Modifique o iptables para bloquear parte do tráfego de saída e de entrada da instância.
  • Encerre as instâncias de máquina virtual. Por padrão, a instância é recriada pelo grupo de instâncias gerenciadas por região pouco tempo depois, mas a nova versão é encerrada assim que o script é executado e enquanto os valores de metadados são definidos. Isso acarreta um loop de falha.

A seguir