Grupos de instâncias gerenciadas com estado

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Você pode criar implantações altamente disponíveis de cargas de trabalho com estado em instâncias de VM usando grupos de instâncias gerenciadas com estado (MIGs com estado). 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 execução com pontos de verificação.

Com MIGs com estado, você pode melhorar o tempo de atividade e a resiliência desses aplicativos com estado com recuperação automática (recuperação automática de cargas de trabalho com falha), implantações em várias zonas e atualizações contínuas automatizadas .

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

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

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

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

Você pode usar grupos de instâncias gerenciadas para oferecer suporte a cargas de trabalho com e sem estado. A principal diferença entre 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 de banco de dados ou configuração de aplicativo) nos discos da VM, enquanto as cargas de trabalho sem estado, como um front-end da Web, não retêm nenhum estado nas VMs individuais.

Você trata VMs com cargas de trabalho com estado como máquinas personalizadas: você se preocupa com a identidade (nome), endereço IP, metadados e dados da VM em cada máquina individual. Você não pode dimensionar facilmente cargas de trabalho com estado horizontalmente porque o dimensionamento 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, você deve 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 se preocupa apenas com o número de VMs em serviço que você possui. Nenhuma VM é tratada de forma diferente de outra. Você pode dimensionar facilmente cargas de trabalho sem estado horizontalmente adicionando ou removendo VMs. Ao atualizar seu aplicativo, você pode 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 da 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.

Todos os MIGs oferecem suporte a nomes de instâncias personalizados e preserváveis.

Quando usar MIGs com estado

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

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

• Bancos de dados . Por exemplo: Cassandra, ElasticSearch, mongoDB e ZooKeeper. Antes de decidir por MIGs com estado, considere usar serviços totalmente gerenciados, por exemplo, MySQL e PostgreSQL estão disponíveis no Cloud SQL , para focar em seus aplicativos e não ter que 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 discos persistentes adicionais, ou dependem de configuração com estado, como nomes de instâncias de VM específicas, endereços IP ou valores de chave de metadados.
• Cargas de trabalho em lote com pontos de verificação . Com esta configuração, você pode preservar resultados de verificação de computação de longa execução em antecipação à carga de trabalho ou falha de VM ou preempção de instância. Os MIGs com estado podem recriar uma máquina com falha, preservando seu disco de dados, para que sua computação possa continuar a partir do último ponto de verificação.

Para obter resiliência contra falhas zonais, a sua aplicação deve replicar dados em múltiplas instâncias ao nível da aplicação. Por exemplo, ElasticSearch e Cassandra suportam essa funcionalidade. Você pode usar um MIG regional para tornar esse aplicativo resiliente a falhas zonais, implantando réplicas redundantes em diversas zonas e contando com a funcionalidade de replicação de dados do seu aplicativo. No caso de uma falha zonal, seus dados serão servidos a partir de réplicas disponíveis nas zonas restantes.

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

O que torna um MIG com estado

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

Você pode criar uma configuração com estado ao criar seu MIG ou pode converter um grupo de sem estado para com estado após sua criação, adicionando uma configuração.

Você cria uma configuração com estado definindo uma política com estado não vazia e/ou uma ou mais configurações por instância não vazias:

• Uma política com estado define os itens que você deseja preservar para todas as instâncias do 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 existentes.
• Ao criar ou atualizar configurações por instância, você pode escolher se deseja aplicar a nova configuração manualmente ou aplicá-la automaticamente.

Depois que a configuração com estado (política com estado e/ou configurações por instância) for aplicada, você poderá 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 com estado (MIG) obtém sua configuração de instância de uma combinação do modelo de instância , da configuração opcional de todas as instâncias , da política com estado opcional e das configurações opcionais por instância que você define. Depois de definir a configuração do seu grupo, o MIG usa essa configuração ao criar VMs. Para aplicar uma configuração atualizada às VMs existentes, consulte Aplicar novas configurações de VM em um MIG .

Política com estado

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

Você pode 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 os discos para se tornarem sem estado, removendo-os da política com estado.
• Especifique que os endereços IP devem ter estado adicionando a configuração da interface de rede à política com estado.
• Especifique que os endereços IP devem 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 específicos da instância, pares de valores-chave de metadados e endereços IP. Os metadados e discos específicos da instância não precisam ser definidos no modelo de instância do MIG; entretanto, as interfaces de rede para IPs com estado devem ser definidas no modelo de instância do MIG.

Você pode fazer as seguintes alterações em uma configuração por instância para uma instância específica em um MIG:

• Configure os 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 para se tornarem sem estado (removendo esses discos da configuração por instância).
• Configure os discos existentes , não definidos no modelo de instância, para serem anexados e se tornarem 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).
• Adicione ou remova pares de valores-chave de metadados com estado específicos da instância.
• Configurar endereços IP individualmente para que instâncias em um MIG se tornem com ou sem estado.

Exemplo de configuração com estado

Aqui está um exemplo de configuração com estado:

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 . Ele especifica anexar um disco existente, my-legacy-1 , à instância node-1 e tratá-lo como com estado. Ele 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. 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.
3. Cria e anexa um disco adicional 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 disco adicional data-disk-1 como com estado porque seu nome de 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. O MIG trata o disco adicional my-legacy-1 como stateful porque seu nome de dispositivo é especificado na configuração por instância.
5. Define três pares de valores-chave 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 chave-valor node-id:xyz273 como stateful porque é 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 Debian GNU/Linux, conforme especificado no modelo de instância.

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

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

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

   Define os metadados após a recriação da VM. Também define os pares de valores-chave comuns do modelo de instância ( app:example-stateful-app e version:1.0 ).

Opinião

Queremos saber mais sobre seus casos de uso, desafios e feedback sobre MIGs com estado. Compartilhe seus comentários com nossa equipe em [email protected] .

O que vem a seguir

• Leia Configurando MIGs com estado para saber como oferecer suporte a cargas de trabalho com estado preservando nomes de instâncias, discos permanentes e metadados em instâncias gerenciadas.
• Aprenda como migrar uma carga de trabalho existente para um MIG com estado .
• Saiba mais sobre como funcionam os MIGs com estado .
• Saiba mais sobre grupos de instâncias gerenciadas .
• Leia sobre Como trabalhar com instâncias gerenciadas .