Esta página foi traduzida pela API Cloud Translation.

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), implantações de várias zonas e atualizações automáticas em andamento.

Um grupo gerenciado de instâncias 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), endereço IP, metadados e os dados da VM em cada máquina individual. Não é possível escalonar 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 o aplicativo, é possível excluir máquinas e substituí-las por novas com nomes, endereços IP, 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 estado	MIG sem estado
Carga de trabalho	Cargas de trabalho com estado em que discos, endereços IP 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 discos e endereços IP 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 automáticas contínuas 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 Endereços IP	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, servidores DNS com endereço IP com estado e cargas de trabalho com estado personalizadas.
Aplicativos monolíticos legados. Esses aplicativos armazenam o estado do aplicativo em um disco de inicialização ou em outros 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 uma configuração.

Para criar uma configuração com estado, defina uma política com estado não vazio e/ou 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 maneira manual ou automática.

Depois que a configuração com estado (seja a política com estado e/ou as 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 gerenciado de instâncias com estado (MIG, na sigla em inglês) usa a configuração da instância de uma combinação do modelo de instância, configuração de todas as instâncias opcional, política com estado opcional e configurações opcionais por instância que você definir. Depois que você definir a configuração do grupo, o MIG usará essa configuração ao criar VMs. Para aplicar uma configuração atualizada às VMs, consulte Aplicar novas configurações de VM em um MIG.

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.
Especificar que os endereços IP precisam ser com estado adicionando a configuração de interface da rede à política com estado.
Especificar que os endereços IP precisam 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 exclusivos para uma instância gerenciada específica, como discos, pares de chave-valor de metadados e endereços IP específicos da instância. Os metadados e discos específicos da instância não precisam ser definidos no modelo de instância do MIG. No entanto, as interfaces de rede para IPs com estado precisam ser definidas 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).
Configurar discos atuais, 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 serem desconectados 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.
Configurar endereços IP individualmente para instâncias em um MIG para que se tornem com estado ou sem estado.

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:

Usa o tipo de máquina n2-standard-2, de acordo com o modelo de instância.
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. O 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.
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.
Anexa um disco atual 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 novo disco my-legacy-1 como com estado, porque o nome de dispositivo dele é especificado na configuração por instância.
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:

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

Feedback

Queremos saber sobre seus casos de uso, desafios e feedback que envolvem os MIGs com estado. Compartilhe essas informações com nossa equipe em mig-discuss@google.com.

A seguir

Leia Como configurar MIGs com estado para saber como oferecer suporte a cargas de trabalho com preservação de estado, nomes de instâncias, discos permanentes e metadados em instâncias gerenciadas.
Saiba como migrar uma carga de trabalho para um MIG com estado.
Saiba mais sobre Como os MIGs com estado funcionam.
Saiba mais sobre os grupos de instâncias gerenciadas.
Leia sobre como trabalhar com instâncias gerenciadas.