Grupos de instâncias geridas com estado

Pode criar implementações de alta disponibilidade de cargas de trabalho com estado em instâncias de VMs usando grupos de instâncias geridas com estado (GIGs com estado). As cargas de trabalho com estado incluem aplicações com dados ou configurações com estado, como bases de dados, aplicações monolíticas antigas e cálculos em lote de longa duração com pontos de verificação.

Com os GIGs com estado, pode melhorar o tempo de atividade e a capacidade de recuperação de aplicações com estado com autorreparação (recuperação automática de cargas de trabalho com falhas), implementações em várias zonas e atualizações contínuas automáticas.

Um grupo de instâncias geridas com estado preserva o estado único de cada instância (incluindo o nome da instância, os discos persistentes anexados, os endereços IP e os metadados) no reinício, na recriação, na autorrecuperação ou na atualização da VM.

Esta página descreve quando usar MIGs com estado e oferece uma vista geral de alto nível de como funcionam. Para mais informações, consulte o artigo Como funcionam os MIGs com estado.

Para saber como configurar um MIG com estado, consulte o artigo Configurar MIGs com estado.

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

Pode usar grupos de instâncias geridos para suportar cargas de trabalho com e sem estado. A principal diferença entre as cargas de trabalho com estado e sem estado é que as cargas de trabalho com estado preservam o estado individual da VM (por exemplo, um fragmento da base de dados ou a configuração da app) nos discos da VM, enquanto as cargas de trabalho sem estado, como um front-end Web, não retêm nenhum estado nas VMs individuais.

Trata as VMs com cargas de trabalho com estado como máquinas criadas à medida: preocupa-se com a identidade (nome), o endereço IP, os metadados e os dados da VM em cada máquina individual. Não pode dimensionar facilmente cargas de trabalho com estado horizontalmente porque o dimensionamento pode exigir a replicação de dados, a criação ou a eliminação de fragmentos de dados, ou a alteração da configuração geral da aplicação. Quando recria ou atualiza uma máquina com uma carga de trabalho com estado, tem de preservar o estado exclusivo da VM. Alguns exemplos de aplicações com estado incluem Cassandra, ElasticSearch, mongoDB, MySQL, PostgreSQL e Kafka.

Trata as VMs com cargas de trabalho sem estado como intermutáveis e só se preocupa com o número de VMs de publicação que tem. Nenhuma MV é tratada de forma diferente de outra. Pode dimensionar rapidamente cargas de trabalho sem estado na horizontal adicionando ou removendo VMs. Quando atualiza a sua aplicação, pode eliminar máquinas e substituí-las por novas com nomes, endereços IP, metadados e discos diferentes. Quando uma VM sem estado é eliminada ou recriada, todos os dados na máquina são perdidos: os discos são eliminados ou recriados de raiz. Um frontend Web é um exemplo de uma aplicação sem estado.

MIG com estadoGMIG sem estado
Carga de trabalho Cargas de trabalho com estado em que os discos, os endereços IP e/ou os metadados são preservados nas operações de recriação de VMs. Cargas de trabalho sem estado altamente disponíveis e escaláveis, em que os discos e os endereços IP são recriados de raiz na escalabilidade horizontal, na autorreparação, na atualização automática e na recriação de VMs.
Funcionalidades do MIG
  • Autorreparação
  • Atualizações contínuas automatizadas
  • Implementações em várias zonas
  • Autorreparação
  • Atualizações contínuas automatizadas
  • Implementações em várias zonas
  • Escala automática
Itens preserváveis
  • Nomes de instâncias
  • Discos persistentes, incluindo suporte para discos que não estão definidos no modelo de instância
  • Metadados específicos da instância
  • Endereços IP
 Nomes de instâncias

Todos os MIGs suportam nomes de instâncias personalizadas e preserváveis.

Quando usar MIGs com estado

Considere usar grupos de instâncias geridas com estado (GIGs com estado) sempre que implementar uma aplicação ou um cluster com estado no Compute Engine e quiser melhorar a respetiva disponibilidade com autorreparação e implementações em várias zonas, ou quiser simplificar as atualizações de instâncias com estado orquestrando implementações de atualizações e controlando o nível de interrupção permitido para as instâncias.

Os MIGs com estado destinam-se a aplicações com dados ou configuração com estado, como:

  • Bases de dados. Por exemplo: Cassandra, ElasticSearch, mongoDB e ZooKeeper. Antes de decidir usar MIGs com estado, considere usar serviços totalmente geridos. Por exemplo, o MySQL e o PostgreSQL estão disponíveis no Cloud SQL para se concentrar nas suas aplicações e não ter de lidar com VMs.
  • Aplicações de tratamento de dados. Por exemplo: Kafka e Flink. Antes de decidir usar os MIGs com estado, considere usar serviços totalmente geridos, por exemplo, o Dataflow ou o Dataproc, para se concentrar nas suas tarefas de processamento de dados e não ter de lidar com VMs.
  • Outras aplicações com estado. Por exemplo: TeamCity, Jenkins, Bamboo, servidores DNS com endereço IP com estado e cargas de trabalho com estado personalizadas.
  • Aplicações monolíticas antigas. Estas aplicações armazenam o estado da aplicação num disco de arranque ou em discos persistentes adicionais, ou dependem da configuração com estado, como nomes de instâncias de VMs, endereços IP ou valores de chaves de metadados específicos.
  • Processamento em lote com pontos de verificação. Com esta configuração, pode preservar os resultados de pontos de verificação de cálculos de longa duração antecipando uma falha na carga de trabalho ou na VM, ou a remoção preventiva da instância. Os MIGs com estado podem recriar uma máquina com falhas, preservando o respetivo disco de dados, para que a computação possa continuar a partir do último ponto de verificação.

Para alcançar a resiliência contra falhas zonais, a sua aplicação tem de replicar os dados em várias instâncias ao nível da aplicação. Por exemplo, o ElasticSearch e o Cassandra suportam esta funcionalidade. Pode usar um MIG regional para tornar uma aplicação deste tipo resiliente a falhas zonais implementando réplicas redundantes em várias zonas e contando com a funcionalidade de replicação de dados da sua aplicação. Em caso de falha zonal, os dados são publicados a partir de réplicas disponíveis nas zonas restantes.

Reveja as limitações para verificar se um MIG com estado cumpre totalmente os seus requisitos.

O que torna um MIG com estado

Um MIG é considerado com estado se tiver criado uma configuração com estado.

Pode criar uma configuração com estado quando cria o MIG ou pode converter um grupo de sem estado para com estado após a sua criação adicionando uma configuração.

Cria uma configuração com estado definindo uma política com estado não vazia ou uma ou mais configurações por instância não vazias:

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

A configuração entra em vigor depois de a aplicar ou de o MIG a aplicar:

  • Um MIG aplica automaticamente a configuração da política com estado a instâncias novas e existentes.
  • Quando cria ou atualiza configurações por instância, pode escolher se quer aplicar a nova configuração manualmente ou automaticamente.

Depois de aplicar a configuração com estado (política com estado ou configurações por instância), pode validá-la inspecionando o estado preservado de cada instância gerida.

As alterações subsequentes à configuração com estado ou ao tamanho do MIG (por exemplo, diminuir o tamanho do MIG ou eliminar ou abandonar instâncias do MIG) podem afetar os estados preservados das instâncias.

Configuração com estado

Um grupo de instâncias geridas (GIG) com estado usa a respetiva configuração de instância a partir de uma combinação do modelo de instância, da configuração de todas as instâncias opcional, da política com estado opcional e das configurações por instância opcionais que definir. Depois de definir a configuração do grupo, o MIG usa essa configuração quando cria VMs. Para aplicar uma configuração atualizada a VMs existentes, consulte o artigo Aplique novas configurações de VMs num MIG.

Política com estado

Uma política com estado define itens com estado comuns para todas as instâncias num grupo de instâncias gerido. Cada item que incluir na política com estado tem de ser definido no modelo de instância do MIG.

Pode fazer as seguintes alterações a uma política com estado:

  • Configure os discos para se tornarem com estado adicionando-os à política com estado.
  • Configure os discos para se tornarem sem estado removendo-os da política com estado.
  • Especifique que os endereços IP têm de ser com estado adicionando a configuração da interface de rede à política com estado.
  • Especifique que os endereços IP têm de ser tratados como sem estado removendo a configuração da política com estado.

Configurações por instância

Uma configuração por instância define itens com estado que são únicos para uma instância gerida específica, como discos específicos da instância, pares de chaves-valores de metadados e endereços IP. Os metadados e os discos específicos da instância não têm de ser definidos no modelo de instância do MIG. No entanto, as interfaces de rede para IPs com estado têm de ser definidas no modelo de instância do MIG.

Pode fazer as seguintes alterações a uma configuração por instância para uma instância específica num MIG:

  • Configurar discos definidos no modelo de instância para se tornarem com estado para a instância (adicionando esses discos à configuração por instância) ou sem estado (removendo esses discos da configuração por instância).
  • Configurar discos existentes, não definidos no modelo de instância, para serem anexados e tornarem-se com estado para a instância (adicionando esses discos à configuração por instância) ou para serem desanexados da instância (removendo discos da configuração por instância).
  • Adicionar ou remover pares de chave-valor de metadados com estado específicos da instância.
  • Configurar endereços IP individualmente para que as instâncias num MIG se tornem com ou sem estado. As configurações por instância para endereços IP não são suportadas para interfaces de rede dinâmicas.

Exemplo de configuração com estado

Segue-se um exemplo de uma configuração com estado:

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

Neste gráfico:

  • O modelo de instância define uma configuração comum para todas as instâncias de VM num MIG
  • A política com estado define uma configuração com estado comum para discos com o nome do 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 denominada node-1. Especifica que deve anexar um disco existente, my-legacy-1, à instância node-1 e tratá-lo como tendo estado. Também especifica um valor de chave de metadados para preservar a individualidade da instância node-1: node-id:xyz273.

Quando cria a node-1 VM, 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 arranque com um nome de disco gerado automaticamente, boot-node-1, e um nome de dispositivo boot-disk, usando uma imagem do Debian GNU/Linux, de acordo com o modelo de instância. O MIG trata o disco de arranque como sem estado porque não está configurado na política com estado nem na configuração por instância.boot-node-1
  3. Cria e anexa um disco adicional com um nome de disco gerado automaticamente, data-disk-1, e um nome do dispositivo, data-disk, usando uma imagem personalizada, de acordo com o modelo de instância. O MIG trata o disco adicional data-disk-1 como com estado porque o respetivo nome do dispositivo está 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. O MIG trata o disco adicional my-legacy-1 como com estado porque o respetivo nome do 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 é especificado na configuração por instância.

Quando recria a VM node-1, partindo do princípio de que a mesma configuração ainda está em vigor, o GIG recria os itens sem estado e preserva os itens com estado:

  1. Recria o disco de arranque a partir da imagem original:

    Primeiro, elimina o disco de arranque e, em seguida, recria-o a partir da imagem do Debian GNU/Linux, conforme especificado no modelo de instância.boot-node-1

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

    Desanexa os discos adicionais antes de eliminar a VM e, em seguida, anexa-os à VM depois de esta ser recriada.

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

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

Feedback

Queremos saber mais sobre os seus exemplos de utilização, desafios e feedback acerca dos MIGs com estado. Convidamos a partilhar o seu feedback com a nossa equipa através do endereço de email mig-discuss@google.com.

O que se segue?