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), las implementaciones multizona y las actualizaciones progresivas automatizadas.

Los grupo de instancias administrados con estado conservan el estado único de cada instancia (incluidos el nombre de la instancia, los discos persistentes conectados, las direcciones IP y los metadatos) cuando las VMs 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 la VM individual (por ejemplo, un fragmento de base de datos o la configuración de la app), 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 (nombre), la dirección IP, los metadatos y los datos de las VM en cada máquina individual. No es fácil escalar horizontalmente las cargas de trabajo con estado porque es posible que el escalamiento necesite 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, direcciones IP, 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 estado	MIG sin estado
Carga de trabajo	Cargas de trabajo con estado en las que los discos, las direcciones IP 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 y las direcciones IP se recrean 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 progresivas automatizadas 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 Direcciones IP	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 VMs.
• Otras aplicaciones con estado. Por ejemplo: TeamCity, Jenkins, Bamboo, servidores DNS con dirección IP con estado 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, direcciones IP o valores clave 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.

Nota: Las regiones de México, Montreal y Osaka tienen tres zonas dentro de uno o dos centros de datos físicos. Estas regiones están en proceso de expansión a, al menos, tres centros de datos físicos. Para obtener más información, consulta Ubicaciones de Cloud y ANS de Google Cloud Platform. Para mejorar la confiabilidad de tus cargas de trabajo, considera una implementación multirregional.

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

Nota: La carga de trabajo debe iniciarse de forma automática en el inicio de la VM para que pueda continuar con la entrega o el procesamiento después de la reparación automática, la actualización automática y los eventos de recreación de instancias.

Características de un MIG con estado

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

Puedes crear una 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 si agregas una configuración.

Creas una configuración con estado definiendo una política con estado que no esté vacía o una o más configuraciones no vacías 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 configuraciones por instancia, puedes elegir si deseas aplicar la configuración nueva de forma manual o automática.

Después de aplicar la configuración con estado (política con estado o configuración por instancia), puedes verificarla si inspeccionas el estado preservado 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 con estado (MIG) toma su configuración de instancia de una combinación de la plantilla de instancias, la configuración de todas las instancias opcional, opcional. política con estado y configuraciones por instancia opcionales que establezcas. Después de establecer la configuración para tu grupo, el MIG usa esa configuración cuando crea VM. Para aplicar una configuración actualizada a las VM existentes, consulta Aplica una configuración de VM nueva en un MIG.

Nota: Si solo necesitas conservar los nombres de las instancias de VM, no necesitas configurar una política con estado ni configuraciones por instancia:

• Los MIG conservan los nombres de las instancias durante la recreación y la reparación automática de forma predeterminada.
• Para que las actualizaciones progresivas proactivas conserven los nombres de las instancias, debes configurar el método de reemplazo del Actualizador como RECREATE.

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:

• Agregar los discos a la política con estado para convertirlos en discos con estado
• Quitar los discos de la política con estado para que se conviertan en discos sin estado
• Para especificar que las direcciones IP deben tener estado, agrega la configuración de la interfaz de red a la política con estado.
• Especifica que las direcciones IP deben tratarse como sin estado mediante la eliminación de la configuración de la 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 discos específicos de instancias, los pares clave-valor de metadatos y las direcciones IP. Los metadatos y discos específicos de la instancia no necesitan definirse en la plantilla de instancias del MIG. Sin embargo, las interfaces de red para las IP con estado deben definirse 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.
• Configura direcciones IP de forma individual para que las instancias de un MIG tengan estado o no.

Ejemplo de configuración con estado

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

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 ni 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 el par clave-valor node-id:xyz273 como con estado porque se especifica en la configuración por instancia.

Cuando se recrea la VM node-1, si la misma configuración aún está en vigencia, el MIG recrea 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).

Comentarios

Queremos conocer tus casos de uso, desafíos y comentarios sobre los MIG con estado. Comparte tus comentarios con nuestro equipo en [e-mail].

¿Qué sigue?

• Consulta Configura MIG con estado para obtener información sobre cómo admitir cargas de trabajo con estado mediante la preservación de nombres de instancias, discos persistentes y metadatos en instancias administradas.
• Obtén más información sobre cómo migrar una carga de trabajo existente a un MIG con estado.
• Obtén más información sobre Cómo funcionan los MIG con estado.
• Obtén más información sobre los Grupos de instancias administrados.
• Lee sobre cómo trabajar con instancias administradas.