Grupos de instâncias gerenciadas com estado

É possível criar implantações altamente disponíveis de cargas de trabalho com estado em instâncias de VM usando grupos de instâncias gerenciadas (MIGs) com estado. As cargas de trabalho com estado incluem aplicativos com dados ou configurações com estado, como bancos de dados, aplicativos monolíticos legados e cálculos em lote de longa duração com checkpoint.

Com os MIGs com estado, é possível melhorar o tempo de atividade e a resiliência desses aplicativos com estado e com recuperação automática (recuperação automática de cargas de trabalho com falha) e implantações em várias zonas, além de simplificar as atualizações de instâncias com estado ⁠ controlando os lançamentos de atualização.

Um grupo de instâncias gerenciadas com estado preserva o estado exclusivo de cada instância (nome da instância, discos permanentes anexados e metadados) na reinicialização, recriação, recuperação automática ou atualização da VM.

Nesta página, descrevemos quando usar MIGs com estado e fornece uma visão geral de alto nível de como eles funcionam. Para mais informações, consulte Como funcionam os MIGs com estado.

Para saber como configurar um MIG com estado, consulte Como configurar MIGs com estado.

Como as cargas de trabalho com estado são diferentes das cargas de trabalho sem estado

É possível usar grupos de instâncias gerenciadas para aceitar cargas de trabalho com estado e sem estado. A principal diferença entre cargas de trabalho com estado e sem estado é que cargas de trabalho com estado preservam o estado individual da VM (por exemplo, um fragmento de banco de dados ou uma configuração de aplicativo) nos discos da VM, enquanto cargas de trabalho sem estado, como um front-end da Web, não mantêm nenhum estado nas VMs individuais.

As VMs com cargas de trabalho com estado são tratadas como máquinas personalizadas: você se preocupa com a identidade (nome), os metadados e os dados da VM em cada máquina individual. Não é possível escalonar horizontalmente as cargas de trabalho com estado horizontalmente porque o escalonamento pode exigir replicação de dados, criação ou exclusão de fragmentos de dados ou alteração da configuração geral do aplicativo. Ao recriar ou atualizar uma máquina com uma carga de trabalho com estado, é necessário preservar o estado exclusivo da VM. Exemplos de aplicativos com estado incluem Cassandra, ElasticSearch, mongoDB, MySQL, PostgreSQL e Kafka.

Você trata as VMs com cargas de trabalho sem estado como intercambiáveis e só se preocupa com o número de VMs de exibição que você tem. Nenhuma VM é tratada de maneira diferente da outra. É possível escalonar cargas de trabalho sem estado horizontalmente adicionando ou removendo VMs. Ao atualizar seu aplicativo, é possível excluir máquinas e substituí-las por novas com nomes, metadados e discos diferentes. Quando uma VM sem estado é excluída ou recriada, todos os dados na máquina são perdidos: os discos são excluídos ou recriados do zero. Um front-end da Web é um exemplo de aplicativo sem estado.

MIG com estadoMIG sem estado
Carga de trabalho Cargas de trabalho com estado em que discos e/ou metadados são preservados em operações de recriação de VM. Cargas de trabalho sem estado altamente escalonáveis e disponíveis, em que os discos são recriados do zero no escalonamento horizontal, na recuperação automática, na atualização automática e na recriação da VM.
Recursos do MIG
  • Recuperação automática
  • Atualizações controladas de instâncias específicas
  • Implantações em várias zonas
  • Recuperação automática
  • Atualizações automáticas contínuas
  • Implantações em várias zonas
  • Escalonamento automático
Itens preserváveis
  • Nomes de instância
  • Discos permanentes, incluindo suporte para discos não definidos no modelo de instância
  • Metadados específicos da instância
Nomes de instância

Todos os MIGs são compatíveis com nomes de instâncias personalizadas e preserváveis.

Quando usar MIGs com estado

Use grupos gerenciados de instâncias com estado (MIGs com estado) sempre que implantar um aplicativo ou cluster com estado no Compute Engine e quiser melhorar a disponibilidade com recuperação automática e implantações de várias zonas, ou simplificar as atualizações de instâncias com estado, orquestrando os lançamentos de atualização e controlando o nível permitido de interrupção para as instâncias.

MIGs com informações de estado destinam-se a aplicativos com dados com estado ou configuração, como:

  • Bancos de dados. Por exemplo: Cassandra, ElasticSearch, mongoDB e ZooKeeper. Antes de decidir sobre MIGs com estado, considere usar serviços totalmente gerenciados, como o MySQL e o PostgreSQL disponíveis no Cloud SQL, para se concentrar nos seus aplicativos e não precisar lidar com VMs.
  • Aplicativos de processamento de dados. Por exemplo: Kafka e Flink. Antes de decidir sobre MIGs com estado, considere usar serviços totalmente gerenciados, por exemplo, Dataflow ou Dataproc, para se concentrar nas tarefas de processamento de dados e não precisar lidar com VMs.
  • Outros aplicativos com estado. Por exemplo: TeamCity, Jenkins, Bamboo e cargas de trabalho com estado de estado.
  • Aplicativos monolíticos legados. Esses aplicativos armazenam o estado do aplicativo em um disco de inicialização ou em novos discos permanentes ou dependem de configuração com estado, como nomes de instâncias de VM específicos ou valores de chave de metadados.
  • Cargas de trabalho em lote com checkpoint. Com essa configuração, é possível preservar resultados com checkpoint de computação de longa duração em antecipação à falha de carga de trabalho ou VM ou à preempção da instância. MIGs com estado podem recriar uma máquina com falha, enquanto preserva seu disco de dados, para que seu cálculo possa continuar a partir do último checkpoint.

Para conseguir resiliência contra falhas zonais, seu aplicativo precisa replicar dados em várias instâncias no nível do aplicativo. Por exemplo, o ElasticSearch e o Cassandra são compatíveis com essa funcionalidade. É possível usar um MIG regional para tornar esse aplicativo resiliente a falhas zonais, implantando réplicas redundantes em várias zonas e confiando na funcionalidade de replicação de dados do aplicativo. No caso de uma falha zonal, os dados são disponibilizados a partir de réplicas disponíveis nas zonas restantes.

Analise as limitações para verificar se um MIG com estado atende aos seus requisitos.

O que torna um MIG com estado

Um MIG será considerado com estado se você tiver criado uma configuração com estado.

É possível criar uma configuração com estado ao criar seu MIG. Outra opção é converter um grupo sem estado em um com estado após a criação do grupo, adicionando a configuração com estado.

Para criar uma configuração com estado, defina uma política com estado não vazio e uma ou mais configurações não vazias por instância:

  • Uma política com estado define os itens que você quer preservar para todas as instâncias no seu MIG.
  • Uma configuração por instância define itens a serem preservados para uma instância de VM específica.

A configuração entra em vigor depois que você ou o MIG a aplica:

  • Um MIG aplica automaticamente sua configuração de política com estado a instâncias novas e atuais.
  • Ao criar ou atualizar configurações por instância, é possível aplicar a nova configuração de forma manual ou automática.

Depois que a configuração com estado (política com estado e/ou configurações por instância) for aplicada, será possível verificá-la inspecionando o estado preservado de cada instância gerenciada.

Alterações subsequentes na configuração ou no tamanho com estado do MIG (por exemplo, diminuir o tamanho do MIG ou excluir ou abandonar instâncias do MIG) podem afetar os estados preservados das instâncias.

Configuração com estado

Um grupo de instâncias gerenciadas (MIG) com estado usa a configuração da instância a partir de uma combinação do modelo de instância, política com estado e das configurações por instância que você definiu. Depois de aplicar no grupo o modelo da instância, a política com estado e/ou as configurações por instância, o MIG usa essa configuração ao criar, recriar, recuperar automaticamente ou atualizar automaticamente suas instâncias de VM.

Política com estado

Uma política com estado define itens comuns com estado para todas as instâncias em um grupo de instâncias gerenciadas. Cada item incluído na política com estado precisa ser definido no modelo de instância do MIG.

É possível fazer as seguintes alterações em uma política com estado:

  • Configure os discos para se tornarem com estado adicionando-os à política com estado.
  • Configure discos para ficar sem estado removendo-os da política com estado.

Configurações por instância

Uma configuração por instância define itens com estado que são exclusivos para uma instância gerenciada específica, como pares de chave-valor de metadados específicos à instância. Esses itens não precisam ser definidos no modelo de instância do MIG.

É possível fazer as seguintes alterações em uma configuração por instância para uma instância específica em um MIG:

  • Configurar discos definidos no modelo de instância para se tornarem com estado na instância (adicionando esses discos à configuração por instância) ou para se tornarem sem estado (removendo esses discos da configuração por instância).
  • Configure discos existentes, não definidos no modelo de instância, para serem anexados e tornar-se com estado para a instância (adicionando esses discos à configuração por instância) ou para ser desconectado da instância (removendo discos da configuração por instância).
  • Adicione ou remova pares de valores-chave de metadados com estado que sejam específicos à instância.

Exemplo de configuração com estado

Veja um exemplo de configuração com estado:

Modelo de instância + política com estado + configuração por instância = configuração da instância gerenciada.

Neste gráfico:

  • O modelo de instância define uma configuração comum para todas as instâncias de VM em um MIG
  • A política com estado define uma configuração com estado comum para discos com nome de dispositivo, data-disk, que são definidos pelo modelo de instância e que são criados e anexados individualmente a cada instância de VM no MIG.
  • A configuração por instância define uma configuração com estado para uma instância de VM específica chamada node-1. Ela especifica o ato de anexar um disco já existente, my-legacy-1, à instância node-1 e tratá-lo como com estado. Ela também especifica um valor de chave de metadados para preservar a individualidade da instância node-1: node-id:xyz273.

Ao criar a VM node-1, o MIG faz o seguinte:

  1. Usa o tipo de máquina n2-standard-2, de acordo com o modelo de instância.
  2. Cria e anexa um disco de inicialização com um nome de disco gerado automaticamente, boot-node-1, e um nome de dispositivo boot-disk, usando uma imagem Debian GNU/Linux, de acordo com o modelo de instância. A MIG trata o disco de inicialização boot-node-1 como sem estado porque não está configurado na política com estado ou na configuração por instância.
  3. Cria e anexa outro disco com um nome de disco gerado automaticamente, data-disk-1, e um nome de dispositivo, data-disk, usando uma imagem personalizada, de acordo com o modelo de instância. O MIG trata o novo disco data-disk-1 como com estado porque o nome do dispositivo é especificado na política com estado.
  4. Anexa um disco existente com o nome do disco, my-legacy-1, e usa o nome do dispositivo, legacy-disk, de acordo com a configuração por instância. A MIG trata o novo disco my-legacy-1 como com estado, porque seu nome de dispositivo é especificado na configuração por instância.
  5. Define três pares de chave-valor de metadados: dois do modelo de instância (app:example-stateful-app, version:1.0) e um da configuração por instância (node-id:xyz273). O MIG trata o par de chave-valor node-id:xyz273 como com estado porque ele é especificado na configuração por instância.

Ao recriar a VM node-1, supondo que a mesma configuração ainda esteja em vigor, o MIG recria os itens sem estado e preserva os itens com estado:

  1. Recria o disco de inicialização a partir da imagem original:

    Primeiro, ele exclui o disco de inicialização boot-node-1 e depois o recria a partir da imagem do Debian GNU/Linux, conforme especificado no modelo de instância.

  2. Preserva outros discos, data-disk-1 e my-legacy-1:

    Separa os discos extras antes de excluir a VM e, em seguida, anexa-os à VM após ela ter sido recriada.

  3. Preserva o par de chave-valor de metadados individuais, node-id:xyz273:

    Define os metadados depois que a VM foi recriada. Também define os pares de chave-valor comuns a partir do modelo de instância (app:example-stateful-app e version:1.0).

A seguir