Leia as secções seguintes para saber como várias configurações, ações do grupo de instâncias geridas (MIG) ou eventos do ciclo de vida da instância afetam o estado preservado de uma instância gerida num MIG com estado:
- Recuperação automática
- Atualizar instâncias
- Redimensionamento de grupos
- Eliminar uma instância
- Abandonar uma instância
- Grupos regionais
Como a autocorreção processa o estado preservado
Quando uma instância de máquina virtual (VM) deixa de ser executada ou fica em mau estado, a recuperação automática recria a VM e mantém o estado preservado para os itens que configurou:
- O MIG preserva os discos com estado e os endereços IP, e volta a anexá-los na recriação da VM.
- O MIG preserva os metadados com estado, configurados em configurações por instância, e define-os na recriação da VM.
Para evitar falhas na recriação de instâncias de VM devido a um disco de arranque com estado danificado, mantenha o disco de arranque sem estado para que a autocorreção possa recriar esse disco de raiz através da imagem original.
Como a atualização de instâncias processa o estado preservado
Quando atualiza uma instância, o MIG mantém o estado preservado da instância (discos, endereços IP e metadados):
- O MIG preserva os discos com estado e os endereços IP e volta a anexá-los se a instância de VM for recriada ou reiniciada durante a atualização.
- O MIG preserva os metadados com estado, configurados numa configuração por instância, e define-os na instância durante a atualização.
Quando define um novo modelo de instância, tem de definir todos os discos que especificou na sua política com estado. Não é permitido definir um novo modelo de instância que omita um disco definido numa política com estado. Isto ajuda a evitar a eliminação acidental de discos com estado.
Para remover discos com estado de um MIG quando esses discos estão definidos numa política com estado, use o seguinte procedimento:
- Remova a configuração do disco da sua política com estado.
- (Opcional.) Desassocie os discos das instâncias de VM se ainda os quiser manter.
- Implemente um novo modelo de instância que já não defina os discos.
Não pode atualizar discos com estado para uma nova imagem porque estes discos têm de ser preservados durante a atualização, e a atualização para uma nova imagem requer a recriação de um disco.
A Google recomenda que mantenha os discos de arranque e todos os discos com ficheiros binários ou temporários sem estado, enquanto mantém os seus dados em discos com estado. Esta configuração suporta o seguinte comportamento:
- Pode atualizar facilmente e de forma automática o disco de arranque e os discos com ficheiros binários para imagens mais recentes que contenham novas versões e patches de segurança. Pode usar a atualização automática ou atualizar manualmente as instâncias para recriar esses discos sem estado, mantendo os seus dados intactos em discos com estado separados.
- Pode preservar os dados em discos com estado quando implementar outras atualizações nas suas instâncias.
Pode configurar um disco de arranque para ser com estado, por exemplo, para alojar uma aplicação antiga que mantém ficheiros binários e dados no mesmo disco. Isto permite-lhe mover uma aplicação para um MIG para beneficiar da autorreparação. No entanto, neste cenário, tem de fazer as atualizações de software e do sistema operativo manualmente, por exemplo, atualizando pacotes individuais através de um gestor de pacotes, como o apt, em sistemas Debian, ou usando ferramentas de gestão de configuração.
Se configurou apenas nomes de instâncias personalizadas e não configurou discos ou metadados com estado, pode usar atualizações contínuas automatizadas. Para atualizações implementadas automáticas, tem de definir a política de substituição do atualizador como RECREATE
.
Não pode usar o método de substituição SUBSTITUTE
para instâncias de atualização automática em MIGs com estado porque este método substitui cada VM existente por uma nova com um nome diferente e um estado preservado.
Como a alteração do tamanho do grupo afeta o estado preservado
Diminuir o tamanho do grupo
A Google não recomenda diminuir o tamanho de um GIG com estado porque o GIG escolhe as instâncias de VM para eliminação e pode escolher VMs que precisa de preservar. Pode remover instâncias de VM de MIG de forma controlada eliminando instâncias específicas de que já não precisa.
Se diminuir o tamanho do MIG, o MIG elimina todas as instâncias de VM adicionais, juntamente com os respetivos estados preservados associados. Para evitar esta situação, pode configurar o MIG para desanexar e preservar os discos com estado e os endereços IP na eliminação permanente da instância de VM. Os metadados com estado são eliminados juntamente com o estado preservado. Para mais informações, consulte como a eliminação de uma instância afeta o estado preservado.
Aumentar o tamanho do grupo
Quando aumenta o tamanho de um GIG com estado, o grupo cria VMs a partir do modelo de instância atual com nomes gerados automaticamente (nome da instância base + sufixo). Pode ver a configuração com estado aplicada no preservedStateFromPolicy
da instância gerida correspondente. Depois de o MIG criar as instâncias, pode definir metadados com estado e discos com estado adicionais ou endereços IP nas configurações por instância destas instâncias.
Pode escolher nomes de instâncias personalizados e aumentar o tamanho do grupo criando instâncias manualmente, com a opção de inicializar o respetivo estado fornecendo configurações por instância com metadados com estado, endereços IP e discos para cada instância.
Como a eliminação de uma instância afeta o estado preservado
Uma VM num MIG é eliminada permanentemente quando:
- Reduz o tamanho do grupo e o MIG escolhe esta instância de VM para eliminação ou
- Elimina todo o grupo ou
- Eliminar a instância especificamente do MIG.
Quando uma VM é eliminada permanentemente, o MIG também elimina a configuração por instância e a instância gerida correspondente, incluindo a respetiva configuração de estado preservado.
A eliminação permanente da VM resulta na perda de todos os pares de chaves-valores de metadados com estado.
Pode configurar se quer manter ou eliminar os discos com estado e os endereços IP na eliminação permanente de instâncias definindo a flag autoDelete
para cada recurso na política com estado ou numa configuração por instância. A flag suporta duas opções:
NEVER
: (predefinição.) O MIG nunca elimina o disco.ON_PERMANENT_INSTANCE_DELETION
: o MIG elimina o disco quando a instância é eliminada permanentemente.
O MIG não elimina recursos com estado quando repara automaticamente, atualiza ou recria instâncias.
No exemplo seguinte, o GIG tem uma única VM node-1
com um estado preservado definido por uma configuração por instância. O estado preservado inclui
dois discos (azul e verde) e metadados id:xyz273
. Se redimensionar o MIG para zero, o MIG aciona a eliminação permanente da instância node-1
, o que causa os seguintes efeitos:
- O MIG elimina a instância gerida e a respetiva configuração de estado preservado.
- O MIG elimina a configuração por instância da instância.
- O MIG elimina o recurso de instância de VM real.
- Os metadados
id:xyz273
são perdidos porque a instância de VM e a respetiva configuração de estado preservado são eliminadas. - O disco azul com estado é eliminado porque, para este disco, a configuração por instância tem
autoDelete: ON_PERMANENT_INSTANCE_DELETION
. - O disco verde com estado está desanexado porque, para este disco, a configuração por instância tem
autoDelete:NEVER
.
Como o abandono de uma instância afeta o estado preservado
Quando abandona uma instância de VM de um GIG, o estado da VM, incluindo os metadados com estado, os endereços IP e os discos, permanece na instância fora do GIG. Uma vez que a VM já não é gerida pelo GIG, o GIG elimina a configuração por instância correspondente e a instância gerida, incluindo a configuração do estado preservado da instância.
No exemplo seguinte, a VM node-1
preservou o estado, definido por uma política com estado (disco azul) e uma configuração por instância (disco verde e metadados id:xyz273
). Se abandonar a instância node-1
do MIG, acontece o seguinte ao respetivo estado preservado:
- A instância de VM autónoma,
node-1
, preserva o respetivo estado: todos os discos permanecem anexados e os metadados,id:xyz273
, permanecem definidos na VM. - O MIG elimina a instância gerida e a respetiva configuração de estado preservado.
- O MIG elimina a configuração por instância da instância.
- A política com estado permanece inalterada porque é aplicável a todas as instâncias no MIG.
Como os grupos regionais processam o estado preservado
Os GIGs regionais com estado gerem os estados preservados das respetivas instâncias da mesma forma que os GIGs zonais, exceto que os GIGs regionais criam instâncias de VMs em várias zonas:
- Quando cria instâncias, um GIG regional distribui uniformemente as VMs pelas zonas na região para maximizar a disponibilidade da sua app em caso de falha ao nível da zona.
- Para instâncias existentes, um MIG regional com estado não pode redistribuir nem mover VMs existentes entre zonas automaticamente porque o estado preservado é armazenado numa zona específica e não pode ser movido. Por esse motivo, os MIGs regionais com estado só suportam uma definição de tipo de redistribuição de instâncias de
NONE
.
Feedback
Queremos saber mais sobre os seus exemplos de utilização, desafios e feedback acerca dos MIGs com estado. Partilhe o seu feedback com a nossa equipa através do endereço de email mig-discuss@google.com.
O que se segue?
- Leia sobre como funcionam os MIGs com estado.
- Leia o artigo Configurar MIGs com estado para saber como suportar cargas de trabalho com estado preservando os nomes das instâncias, os discos persistentes e os metadados em instâncias geridas.
- Saiba mais acerca dos grupos de instâncias geridos.
- Trabalhe com instâncias geridas.