Como distribuir instâncias usando grupos de instâncias gerenciadas regionais

Veja nesta página o processo de criação de grupos de instâncias gerenciadas 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 regionais 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 regional de instâncias gerenciadas na região us-east1 manterá uma distribuição igual de instâncias em três zonas dentro dessa 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 regionais escolhe três zonas onde criar as instâncias. Você também pode escolher seletivamente em quais zonas as instâncias serão criadas ou, então, criar instâncias em regiões com menos de três zonas. Por exemplo, se você quer acelerar cargas de trabalho com GPUs, selecione zonas compatíveis com GPUs.

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

Antes de começar

Limitações

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

Como escolher grupos de instâncias gerenciadas regionais

O Google recomenda usar grupos de instâncias gerenciadas regionais porque eles permitem distribuir a carga do aplicativo por várias zonas, ao contrário dos grupos de instâncias gerenciadas por zonas que limitam o aplicativo a uma única zona. Além disso, com os grupos de instâncias gerenciadas regionais, 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 continua a servir o tráfego a partir das instâncias em execução na zona da mesma região.

Se houver alguma falha na zona ou se um grupo de instâncias de uma zona deixar de responder, os grupos de instâncias gerenciadas regionais continuarão a dar suporte para suas VMs da maneira a seguir:

  • As instâncias que fazem parte do grupo de instâncias gerenciadas regional nas zonas restantes continuarão a processar o tráfego. Nenhuma instância nova é adicionada ou 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 processar o tráfego dela.

Para desenvolver aplicativos robustos e escalonáveis, use grupos de instâncias gerenciadas regionais.

Rebalanceamento automático

Os grupos de instâncias gerenciadas regionais tentam equilibrar a quantidade de instâncias de VM entre o número especificado de zonas para aceitar cargas de trabalho de alta disponibilidade. Se outra ação, como uma chamada de método para deleteInstances ou abandonInstances, for executada e causar um desequilíbrio das instâncias de VM nas zonas, o grupo trabalhará ativamente para restabelecer o equilíbrio. Como consequência, o grupo poderá excluir ou adicionar instâncias.

Por exemplo, suponha que você tem um grupo de instâncias gerenciadas regional com duas instâncias na zona us-central1-a, uma instância na zona us-central1-b e uma instância na zona us-central1-c. Se você excluir a instância de VM em us-central1-c, o grupo tentará reequilibrar a distribuição de instâncias para que sejam divididas uniformemente entre as zonas.

Nesse caso, o grupo removeria uma instância de us-central1-a e adicionaria uma nova instância a us-central1-c para que cada zona tenha uma instância. Não é possível selecionar qual instância deverá ser excluída.

Esse comportamento está ativado por padrão para que os grupos de instâncias gerenciadas regionais consigam suportar cargas de trabalho de alta disponibilidade. No entanto, você precisa estar ciente do que acontecerá se excluir ou remover instâncias de um grupo de instâncias gerenciadas regional.

Como provisionar o tamanho correto do grupo de instâncias gerenciadas

Para estar preparado para uma situação extrema em que há falha na zona ou interrupção no funcionamento de um grupo inteiro de instâncias, é recomendável aumentar o provisionamento de seu grupo de instâncias gerenciadas no Compute Engine. Dependendo das necessidades de seu aplicativo, aumentar o provisionamento pode impedir 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. Decida o quanto de provisionamento a mais é ideal para você, com base nas necessidades do aplicativo e limites de custos.

Como provisionar um grupo de instâncias gerenciadas regional em três ou mais zonas

Se você estiver criando um grupo de instâncias gerenciadas regional em uma região com, pelo menos, três zonas, o Google recomenda aumentar o provisionamento desse grupo em 50%, no mínimo. Por padrão, um grupo de instâncias gerenciadas regional 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 servir 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á suportado pelas outras zonas.

Por exemplo, se você precisar de 20 instâncias de máquina virtual em seu grupo de instâncias gerenciadas distribuídas por três zonas, recomendamos, no mínimo, adicionar 50% ao número 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 regional com um tamanho de 30, o grupo distribuirá as instâncias da maneira mais uniforme possível entre as três zonas como a seguir:

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

Se ocorrer alguma falha em uma única zona, você ainda terá 20 instâncias que servirão o tráfego.

Como provisionar um grupo de instâncias gerenciadas regional em duas zonas

Se você quiser provisionar suas instâncias em duas zonas, em vez de em três, o Google recomenda duplicar 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, configure um grupo de instâncias gerenciadas regional com 40 instâncias para que cada zona fique com 20. Se uma única zona falhar, você ainda terá 20 instâncias para servir o tráfego.

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

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

Como provisionar um grupo de instâncias gerenciadas regional em uma zona

É possível criar um grupo de instâncias gerenciadas regional com apenas uma zona. Isso é semelhante à criação de um grupo de instâncias gerenciadas por zona, mas com algumas diferenças:

  • Ao criar um grupo de instâncias gerenciadas regional com uma zona, adicione mais zonas ao grupo posteriormente. Não é possível adicionar zonas a um grupo de instâncias gerenciadas por zona.

  • Muitos recursos novos geralmente são disponibilizados primeiro para os grupos de instâncias gerenciadas por zona.

No entanto, não é recomendável criar um grupo de instâncias gerenciadas regional de zona única porque essa é a configuração que oferece menor capacidade de disponibilidade. Se a zona ou região falhar, todo seu grupo de instâncias gerenciadas ficará indisponível, o que poderá prejudicar seus usuários.

Como selecionar zonas para um grupo

A configuração padrão para um grupo de instâncias gerenciadas regional é 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. Você pode ter discos permanentes disponíveis somente em determinadas zonas ou, então, 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.

Escolha o número de zonas e/ou zonas específicas para a execução do grupo durante a criação dele. 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 todas as quatro zonas dentro de uma região, informe-as claramente na solicitação. Se você não fizer isso, o Compute Engine, por padrão, selecionará três zonas.

  • Para selecionar até duas zonas em uma região, especifique 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 instâncias em todas as zonas, as instâncias de VM serão distribuídas igualmente entre todas elas. Como prática recomendada, verifique se você provisionou instâncias de VM o suficiente para dar suporte a seus aplicativos no número especificado de zonas.

Como criar um grupo de instâncias gerenciadas regional

Crie um grupo de instâncias gerenciadas regional na ferramenta de linha de comando gcloud, no console ou na API.

Quando as zonas não têm capacidade suficiente para aceitar instâncias do grupo, o Compute Engine cria o máximo possível de instâncias e continua tentando criar as instâncias restantes à medida que mais cotas são disponibilizadas.

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

Por padrão, se você não especificar explicitamente as zonas individuais em sua solicitação, o Compute Engine escolherá três zonas onde as instâncias serão criadas. Se você precisar criar instâncias em menos ou mais do que três zonas ou quiser escolher quais zonas usar, forneça uma lista de zonas em sua solicitação. Leia sobre como selecionar zonas para um grupo.

Console

  1. Acesse a página "Grupos de instâncias" no Console do GCP.

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

  2. Clique em Criar grupo de instâncias para criar um novo grupo de instâncias.
  3. Em Local, selecione Várias zonas.
  4. Escolha a região que você quer.
  5. Se você quiser escolher zonas específicas, clique em Configurar zonas para selecionar quais usar.
  6. Selecione um modelo de instância para o grupo ou crie um modelo novo.
  7. 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.
  8. 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 o sinalizador --region. Por exemplo, o comando abaixo cria um grupo de instâncias gerenciadas regional 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 deverá 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

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 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://www.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 dessa 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, ao usar o nome de instância básico example-instance, serão criadas instâncias com nomes como example-instance-[RANDOM_STRING] em que [RANDOM_STRING] é gerada 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 onde as instâncias deverão ser criadas.

POST https://www.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, a amostra abaixo cria um grupo de instâncias chamado exemple-rmig com 10 instâncias distribuídas entre as zonas us-east1-b e us-east1-c:

POST https://www.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"}
      ]
   }
}

Como listar instâncias em um grupo de instâncias gerenciadas regionais

Para ver a lista de instâncias do grupo de instâncias gerenciadas regional, use o Console do GCP, 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

  1. Acesse a página "Grupos de instâncias" no Console do GCP.

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

  2. Clique no nome do grupo regional que inclui as instâncias gerenciadas 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 seguinte comando lista as instâncias que fazem parte de um grupo chamado example-rmig na região us-east1:

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

API

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

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Por exemplo:

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

Como atualizar um grupo de instâncias gerenciadas regional

Você pode atualizar um grupo de instâncias gerenciadas regionais usando o recurso Atualizador de grupo de instâncias. O Atualizador permite atualizar um subconjunto ou todas as instâncias 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 da 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. Observe que a alteração do modelo da instância não atualiza automaticamente as instâncias atuais para o novo modelo. Você precisa 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 fazer o escalonamento automático de um grupo de instâncias gerenciadas regionais

O Compute Engine oferece escalonamento automático para grupos de instâncias gerenciadas, o que permite a esses grupos adicionar ou remover instâncias automaticamente com base no aumento ou na redução da carga. Você pode ativar o escalonamento automático para grupos de instâncias gerenciadas regionais.

Quando você ativa o escalonamento automático para um grupo de instâncias gerenciadas regional, o recurso funciona da maneira a seguir:

  • Uma política de escalonamento automático é aplicada ao grupo como um todo, e não a zonas individuais. Por exemplo, se você ativa o autoescalador com a meta de uso de CPU de 66%, todas as instâncias do grupo são monitoradas para manter uma média de utilização de 66% em todas as instâncias de todas as zonas.

  • Sempre que possível, as instâncias são distribuídas igualmente entre zonas pelo escalonamento automático. Em geral, o balanceamento de tamanho das zonas é mantido pelo autoescalador por meio do aumento de zonas menores e da expectativa de que a carga será redirecionada de zonas maiores. Não recomendamos configurar um balanceador de carga padrão que dê preferência a uma zona, porque isso pode resultar em um comportamento inesperado.

  • Caso haja falha em uma zona ou em um grupo de instâncias dentro de uma determinada zona, é possível que 1/3 da capacidade seja perdida, porém 2/3 permanecerão em outras zonas. Recomendamos a configuração da política de escalonamento automático para aumentar o provisionamento do grupo de instâncias gerenciadas que foi automaticamente escalonado, evitando a sobrecarga dos outros servidores em funcionamento durante o tempo em que uma zona está inoperante.

O autoescalador somente adiciona instâncias a uma zona até alcançar 1/3 do máximo especificado para o grupo. Por exemplo, se 15 é o maxNumReplicas configurado para o escalonamento automático, o autoescalador só pode adicionar até 1/3 * 15 = 5 instâncias por zona ao grupo de instâncias. Quando há falhas em uma zona, ele só escalona até 2/3 do maxNumReplicas nas duas outras zonas combinadas.

Como provisionar a configuração do autoescalador

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 autoescalador:

  • A meta de utilização do autoescalador é de 2/3 da meta que você quer.
  • Para se ajustar à meta de utilização reduzida, o autoescalador adiciona instâncias. Isso significa que é preciso aumentar o valor de maxNumReplicas em 50% em relação ao valor que seria definido se o provisionamento em excesso da conta não fosse considerado.

Por exemplo, caso queira que 20 instâncias gerenciem os picos de carga e que a meta de utilização seja de 80%, configure o autoescalador 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. Os outros 2/3 de instâncias devem ser suficientes para processar o aumento de carga proveniente dessa zona off-line, uma vez que você reduziu a meta de utilização para um valor bem abaixo da capacidade. No autoescalador, 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. Acesse a página "Grupos de instâncias" no Console do GCP.

    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 regional 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

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

Por exemplo, nos snippets a seguir, o autoescalador é configurado para um grupo de instância chamado example-rmig. Substitua us-east1 pela região de seu grupo de instâncias gerenciadas, example-autoscaler pelo nome desejado para o autoescalador 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, envie uma solicitação POST para o seguinte URL, usando o código de seu projeto e a região do grupo de instâncias gerenciadas:

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

O corpo da sua solicitação deve conter os campos name, target e autoscalingPolicy. No autoscalingPolicy, os valores cpuUtilization e maxNumReplicas são definidos.

{
 "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 autoescalador

Atualize um autoescalador regional 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 regional a um balanceador de carga

No Google Cloud Platform, o balanceamento de carga é feito usando os grupos de instâncias para fornecer 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 saber mais sobre grupos de instâncias gerenciadas e balanceamento de carga, consulte a Visão geral de grupos de instâncias.

Atribua um grupo de instâncias gerenciadas regional como o destino de um serviço de back-end para balanceamento de carga externo e interno ou como parte de um pool de destino para balanceamento de carga de rede.

Para o balanceamento de carga HTTP(S), somente maxRatePerInstance e maxUtilization são compatíveis com os grupos de instâncias gerenciadas regionais.

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

Um serviço de back-end é necessário para criar um balanceador de carga HTTP(S), interno ou SSL. Um serviço de back-end contém back-ends individuais, e cada um deles contém um grupo de instâncias gerenciadas ou não gerenciadas. As instâncias contidas no grupo respondem ao tráfego vindo do balanceador de carga. O serviço de back-end, por sua vez, tem as informações de quais instâncias podem ser usadas, a capacidade delas para processar o tráfego e a quantidade de tráfego que elas estão processando no momento. Além disso, a verificação da integridade é monitorada no serviço de back-end, que não envia novas conexões para instâncias não íntegras.

Para saber como adicionar um grupo de instâncias a um serviço de back-end, leia Como adicionar grupos de instâncias a um serviço de back-end.

Como adicionar um grupo de instâncias gerenciadas regional 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 em "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 automaticamente atualizado 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 existente 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 GCP.

    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 de VMs e clique em Selecionar grupos de instâncias.
  5. Selecione um grupo de instâncias no menu suspenso.
  6. Salve as alterações.

gcloud

Com a 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://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/regionInstanceGroupManagers/[INSTANCE_GROUP]/setTargetPools

em que:

  • [PROJECT_ID] é o ID do projeto dessa 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 deve conter uma lista de URIs para os pools de destino aos quais 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 regional

Para testar se o provisionamento do grupo de instâncias gerenciadas regional 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 em 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 configurando estes dois campos de metadados do projeto:

    • failed_zone: configura a zona em que você quer simular a falha, para que ela se limite somente a essa zona.
    • failed_instance_names: escolhe as instâncias que ficam off-line por nome, para que a falha se limite somente às instâncias com nomes que contenham essa string.

    Configure esses metadados usando a ferramenta de linha de comando gcloud. Por exemplo, no seguinte comando, a zona com falha definida é a 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

Aqui estão algumas ideias de cenários de falha possíveis de serem 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 a 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 regional pouco tempo depois, mas a nova encarnação é encerrada assim que o script é executado e enquanto os valores de metadados são definidos. Isso resulta em um loop de falha.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Esta página
Comentários sobre a documentação
Documentação do Compute Engine
Comentários sobre o produto