Grupos de instancias administrados con estado

Puedes compilar implementaciones con alta disponibilidad de cargas de trabajo con estado en VM mediante grupos de instancias administrados con estado (MIG con estado). Las cargas de trabajo con estado incluyen aplicaciones que tienen configuración o datos con estado, como bases de datos, aplicaciones monolíticas heredadas y procesamientos por lotes de larga duración con puntos de control.

Con los MIG con estado, puedes mejorar el tiempo de actividad y la resiliencia de esas aplicaciones con estado mediante la reparación automática (recuperación automática de cargas de trabajo con fallas) y las implementaciones en varias zonas. Además, puedes simplificar las actualizaciones de las instancias con estado mediante el control de las actualizaciones de lanzamiento.

Los grupo de instancias administrados con estado conservan el estado único de cada instancia (incluidos el nombre de la instancia, los discos persistentes conectados y los metadatos) cuando las VM se reinician, se vuelven a crear, se reparan automáticamente o se actualizan.

En esta página, se describe cuándo usar MIG con estado y se proporciona una descripción general de alto nivel de su funcionamiento. Para obtener más información, consulta Cómo funcionan los MIG con estado.

Para obtener información sobre cómo configurar un MIG con estado, consulta Configura los MIG con estado.

Diferencias entre las cargas de trabajo con estado y las cargas de trabajo sin estado

Puedes usar grupos de instancias administrados para admitir cargas de trabajo con estado y sin estado. La diferencia clave entre las cargas de trabajo con estado y las sin estado es que las cargas con estado conservan el estado de las VM individuales (por ejemplo, un fragmento de base de datos o la configuración de la app) en los discos de las VM, mientras que las cargas de trabajo sin estado, como un frontend web, no conservan ningún estado de las VM individuales.

Debes tratar las VM con cargas de trabajo con estado como máquinas personalizadas: debes ocuparte de la identidad de las VM (nombres), los metadatos y los datos en cada máquina individual. No es fácil escalar horizontalmente las cargas de trabajo con estado porque es posible que el escalamiento requiera la replicación de datos, la creación o la eliminación de fragmentos de datos o cambios en la configuración general de la aplicación. Cuando vuelves a crear o actualizas una máquina con una carga de trabajo con estado, debes conservar el estado único de la VM. Algunos ejemplos de aplicaciones con estado son Cassandra, ElasticSearch, mongoDB, MySQL, PostgreSQL y Kafka.

Debes tratar a las VM con cargas de trabajo sin estado como intercambiables y solo ocuparte de la cantidad de VM de entrega que tienes. Ninguna VM se trata de manera diferente a otra. Puedes escalar horizontalmente las cargas de trabajo sin estado si agregas o quitas VM. Cuando actualizas la aplicación, puedes borrar las máquinas y reemplazarlas por otras nuevas con nombres, metadatos y discos diferentes. Cuando se borra o se vuelve a crear una VM sin estado, se pierden todos los datos en la máquina: los discos se borran o se vuelven a crear desde cero. Un frontend web es un ejemplo de una aplicación sin estado.

MIG con estadoMIG sin estado
Carga de trabajo Cargas de trabajo con estado en las que los discos o los metadatos se conservan en las operaciones de recreación de VM. Cargas de trabajo sin estado con alta disponibilidad y escalabilidad, en las que los discos se vuelven a crear desde cero durante el escalamiento horizontal, la reparación automática, la actualización automática y la recreación de VM.
Funciones de los MIG
  • Reparación automática
  • Actualizaciones controladas de instancias específicas
  • Implementaciones de varias zonas
  • Reparación automática
  • Actualizaciones progresivas automatizadas
  • Implementaciones de varias zonas
  • Ajuste de escala automático
Elementos que se pueden conservar
  • Nombres de instancias
  • Discos persistentes, incluida la compatibilidad con los discos que no están definidos en la plantilla de instancias
  • Metadatos específicos de la instancia
Nombres de instancias

Todos los MIG admiten nombres de instancias personalizados y conservables.

Cuándo usar MIG con estado

Considera usar grupos de instancias administrados con estado (MIG con estado) cada vez que implementes una aplicación o un clúster con estado en Compute Engine y desees mejorar su disponibilidad con las implementaciones en varias zonas y la reparación automática, o desees simplificar las actualizaciones de instancias con estado mediante la organización de los lanzamientos de actualizaciones y el control del nivel permitido de interrupción de las instancias.

Los MIG con estado están diseñados para aplicaciones con datos o configuración con estado, como los siguientes:

  • Bases de datos. Por ejemplo: Cassandra, ElasticSearch, mongoDB y ZooKeeper. Antes de decidirte por los MIG con estado, considera usar servicios completamente administrados, como MySQL y PostgreSQL, que están disponibles en Cloud SQL para que te enfoques en tus aplicaciones sin necesidad de preocuparte por las VM.
  • Aplicaciones de procesamiento de datos. Por ejemplo: Kafka y Flink. Antes de decidirte por los MIG con estado, considera usar servicios completamente administrados, como Dataflow o Dataproc, para enfocarte en las tareas de procesamiento de datos y no tener que ocuparte de las VM.
  • Otras aplicaciones con estado. Por ejemplo: TeamCity, Jenkins, Bamboo y cargas de trabajo con estado personalizadas.
  • Aplicaciones monolíticas heredadas. Estas aplicaciones almacenan el estado de la aplicación en un disco de arranque o discos persistentes adicionales, o dependen de una configuración con estado, como nombres de instancias de VM o valores de claves de metadatos específicos.
  • Cargas de trabajo por lotes con puntos de control. Con esta configuración, puedes conservar los resultados controlados de los procesamientos de larga duración en previsión de fallas de la VM o la carga o de la interrupción de la instancia. Los MIG con estado pueden volver a crear una máquina con fallas y conservar su disco de datos para que el procesamiento pueda continuar desde el último punto de control.

Para lograr una resiliencia contra fallas zonales, la aplicación debe replicar los datos en varias instancias a nivel de aplicación. Por ejemplo, ElasticSearch y Cassandra admiten esta funcionalidad. Puedes usar un MIG regional para hacer que dicha aplicación sea resiliente a la falla zonal si implementas réplicas redundantes en varias zonas y usas la funcionalidad de replicación de datos en la aplicación. En el caso de una falla zonal, tus datos se entregan desde réplicas disponibles en las zonas restantes.

Revisa las limitaciones para verificar si un MIG con estado cumple por completo con tus requisitos.

Características de un MIG con estado

Un MIG se considera con estado si creaste una configuración con estado.

Puedes crear este tipo de configuración con estado cuando creas el MIG o puedes convertir un grupo sin estado a uno con estado después de su creación mediante el agregado de una configuración con estado.

Para crear una configuración con estado, establece una política con estado no vacío o uno o más parámetros de configuración no vacíos por instancia:

  • Una política con estado define los elementos que deseas conservar para todas las instancias del MIG.
  • Una configuración por instancia define los elementos que se conservarán para una instancia de VM específica.

La configuración se activará después de que tú o el MIG la apliquen:

  • El MIG aplica de forma automática la configuración de política con estado a las instancias nuevas y existentes.
  • Cuando creas o actualizas la configuración por instancia, puedes elegir aplicar la nueva configuración como configuración por instancia de forma manual o que se aplique automáticamente.

Después de aplicar la configuración con estado (política con estado o configuración por instancia), puedes verificarla si inspeccionas el estado conservado de cada instancia administrada.

Los cambios posteriores en la configuración con estado o en el tamaño del MIG (por ejemplo, reducir el tamaño del MIG, o borrar o descartar instancias del MIG) pueden afectar los estados conservados de las instancias.

Configuración con estado

Un grupo de instancias administrado (MIG) con estado toma su configuración de instancias a partir de una combinación de la plantilla de instancias, la política con estado y la configuración por instancia que estableces. Después de que aplicas la plantilla de instancias, la política con estado o la configuración por instancia a tu grupo, el MIG usa esa configuración cuando crea, recrea, repara o actualiza de forma automática sus instancias de VM.

Política con estado

Una política con estado define elementos con estado comunes para todas las instancias de un grupo de instancias administrado. Cada elemento que incluyas en la política con estado debe definirse en la plantilla de instancias del MIG.

Puedes realizar los siguientes cambios en una política con estado:

Configuración por instancia

Una configuración por instancia define los elementos con estado que son únicos para una instancia administrada específica, como los pares clave-valor de metadatos específicos de la instancia. No es necesario definir estos elementos en la plantilla de instancias del MIG.

Puedes realizar los siguientes cambios en una configuración por instancia para una instancia específica de un MIG:

  • Configurar los discos que se definen en la plantilla de instancias a fin de que tengan estado en la instancia (agrégalos a la configuración por instancia) o convertirlos en discos sin estado (quítalos desde la configuración por instancia).
  • Configurar los discos existentes, que no están definidos en la plantilla de instancias, a fin de conectarlos y convertirlos en discos con estado para la instancia (agrégalos a la configuración por instancia) o desconectarlos de la instancia (quítalos de la configuración por instancia).
  • Agrega o quita pares clave-valor de metadatos con estado que sean específicos de la instancia.

Ejemplo de configuración con estado

Este es un ejemplo de una configuración con estado:

Plantilla de instancias + política con estado + configuración por instancia = configuración de instancia administrada

En este gráfico, se ilustra lo siguiente:

  • La plantilla de instancias define una configuración común para todas las instancias de VM de un MIG.
  • La política con estado define una configuración con estado común para los discos con nombre de dispositivo, data-disk, definidos por la plantilla de instancias, que se crean y conectan de forma individual a cada instancia de VM en el MIG.
  • La configuración por instancia define una configuración con estado para una instancia de VM específica llamada node-1. Establece que un disco existente, my-legacy-1, debe conectarse a la instancia node-1 y tratarse como un disco con estado. También especifica un valor de clave de metadatos para conservar la individualidad de la instancia node-1: node-id:xyz273.

Cuando se crea la VM node-1, el MIG hace lo siguiente:

  1. Usa el tipo de máquina n2-standard-2, según la plantilla de instancias.
  2. Crea y conecta un disco de arranque con un nombre de generado de forma automática, boot-node-1, y el nombre de dispositivo, boot-disk, mediante una imagen de Debian GNU/Linux, de acuerdo con la plantilla de instancias. El MIG trata el disco de arranque boot-node-1 como sin estado porque no está configurado en la política con estado o en la configuración por instancia.
  3. Crea y conecta un disco adicional con un nombre generado de forma automática, data-disk-1, y el nombre de dispositivo, data-disk, mediante una imagen personalizada, de acuerdo con la plantilla de instancias. El MIG trata al disco adicional data-disk-1 como un disco con estado porque su nombre de dispositivo se especifica en la política con estado.
  4. Conecta un disco existente con el nombremy-legacy-1 y usa el nombre de dispositivo legacy-disk, según la configuración por instancia. El MIG trata al disco adicional my-legacy-1 como un disco con estado porque su nombre de dispositivo se especifica en la configuración por instancia.
  5. Establece tres pares clave-valor de metadatos: dos de la plantilla de instancias (app:example-stateful-app y version:1.0) y uno de la configuración por instancia (node-id:xyz273). El MIG trata al par clave-valor node-id:xyz273 como con estado porque se especifica en la configuración por instancia.

Cuando se vuelve a crear la VM node-1, si la misma configuración aún está en vigencia, el MIG vuelve a crear los elementos sin estado y conserva los elementos con estado:

  1. Vuelve a crear el disco de arranque a partir de la imagen original:

    Primero, borra el disco de arranque boot-node-1 y, luego, lo vuelve a crear a partir de la imagen de Debian GNU/Linux, como se especifica en la plantilla de instancias.

  2. Conserva discos adicionales, data-disk-1 y my-legacy-1:

    Los desconecta antes de borrar la VM y los conecta luego de volver a crearla.

  3. Conserva el par clave-valor de metadatos individual, node-id:xyz273:

    Establece los metadatos después de volver a crear la VM. También establece los pares clave-valor comunes de la plantilla de instancias (app:example-stateful-app y version:1.0).

Próximos pasos