Puede crear implementaciones de alta disponibilidad de cargas de trabajo con estado en instancias de VM utilizando grupos de instancias administradas con estado (MIG con estado). Las cargas de trabajo con estado incluyen aplicaciones con datos o configuraciones con estado, como bases de datos, aplicaciones monolíticas heredadas y cálculos por lotes de larga duración con puntos de control.
Con MIG con estado, puede mejorar el tiempo de actividad y la resiliencia de dichas aplicaciones con estado con recuperación automática (recuperación automática de cargas de trabajo fallidas), implementaciones multizona y actualizaciones continuas automatizadas .
Un grupo de instancias administrado con estado conserva el estado único de cada instancia (incluido el nombre de la instancia, los discos persistentes conectados, las direcciones IP y los metadatos) al reiniciar, recrear, reparar automáticamente o actualizar la VM.
Esta página describe cuándo utilizar MIG con estado y proporciona una descripción general de alto nivel de cómo funcionan. Para obtener más información, consulte Cómo funcionan los MIG con estado .
Para aprender cómo configurar un MIG con estado, consulte Configuración de MIG con estado .
En qué se diferencian las cargas de trabajo con estado de las cargas de trabajo sin estado
Puede utilizar grupos de instancias administrados para admitir cargas de trabajo con y sin estado. La diferencia clave entre las cargas de trabajo con estado y sin estado es que las cargas de trabajo con estado preservan el estado de la VM individual (por ejemplo, un fragmento de base de datos o la configuración de una aplicación) en los discos de la VM, mientras que las cargas de trabajo sin estado, como una interfaz web, no retienen ningún estado en las VM individuales.
Trata las máquinas virtuales con cargas de trabajo con estado como maquinaria hecha a medida: se preocupa por la identidad (nombre) de la máquina virtual, la dirección IP, los metadatos y los datos de cada máquina individual. No es fácil escalar horizontalmente cargas de trabajo con estado porque el escalado podría requerir la replicación de datos, la creación o eliminación de fragmentos de datos o el cambio de la configuración general de la aplicación. Al recrear o actualizar una máquina con una carga de trabajo con estado, debe preservar el estado único de la VM. Ejemplos de aplicaciones con estado incluyen Cassandra, ElasticSearch, mongoDB, MySQL, PostgreSQL y Kafka.
Trata las máquinas virtuales con cargas de trabajo sin estado como intercambiables y solo se preocupa por la cantidad de máquinas virtuales en servicio que tiene. Ninguna máquina virtual recibe un trato diferente a otra. Puede escalar fácilmente cargas de trabajo sin estado de forma horizontal agregando o eliminando máquinas virtuales. Al actualizar su aplicación, puede eliminar máquinas y reemplazarlas por otras nuevas con diferentes nombres, direcciones IP, metadatos y discos. Cuando se elimina o se vuelve a crear una máquina virtual sin estado, se pierden todos los datos de la máquina: los discos se eliminan o se vuelven a crear desde cero. Una interfaz web es un ejemplo de aplicación sin estado.
MIG con estado | MIG sin estado | |
---|---|---|
Carga de trabajo | Las cargas de trabajo con estado donde los discos, las direcciones IP y/o los metadatos se conservan en las operaciones de recreación de la VM. | Cargas de trabajo sin estado escalables y de alta disponibilidad, donde los discos y las direcciones IP se recrean desde cero mediante escalamiento horizontal, reparación automática, actualización automática y recreación de máquinas virtuales. |
Funciones MIG |
|
|
Artículos conservables |
| Nombres de instancia |
Todos los MIG admiten nombres de instancia personalizados y conservables.
Cuándo utilizar MIG con estado
Considere la posibilidad de utilizar grupos de instancias administradas con estado (MIG con estado) siempre que implemente una aplicación o un clúster con estado en Compute Engine y desee mejorar su disponibilidad con implementaciones multizona y de reparación automática , o si desea simplificar las actualizaciones de instancias con estado organizando implementaciones de actualizaciones y controlando el nivel permitido de interrupción de las instancias.
Los MIG con estado están destinados a aplicaciones con datos o configuración con estado, como:
- Bases de datos . Por ejemplo: Cassandra, ElasticSearch, mongoDB y ZooKeeper. Antes de decidirse por MIG con estado, considere utilizar servicios totalmente administrados, por ejemplo, MySQL y PostgreSQL están disponibles en Cloud SQL , para centrarse en sus aplicaciones y no tener que lidiar con máquinas virtuales.
- Aplicaciones de procesamiento de datos . Por ejemplo: Kafka y Flink. Antes de decidirse por MIG con estado, considere utilizar servicios totalmente administrados, por ejemplo, Dataflow o Dataproc , para concentrarse en sus tareas de procesamiento de datos y no tener que lidiar con máquinas virtuales.
- 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 en discos persistentes adicionales, o dependen de una configuración con estado, como nombres de instancias de VM específicas, direcciones IP o valores de claves de metadatos.
- Cargas de trabajo por lotes con puntos de control . Con esta configuración, puede conservar los resultados de los puntos de control de los cálculos de larga duración en previsión de una carga de trabajo o una falla de la VM o una preferencia de instancia. Los MIG con estado pueden recrear una máquina fallida y al mismo tiempo preservar su disco de datos, de modo que el cálculo pueda continuar desde el último punto de control.
Para lograr resiliencia contra fallas zonales, su aplicación debe replicar datos en múltiples instancias a nivel de aplicación. Por ejemplo, ElasticSearch y Cassandra admiten dicha funcionalidad. Puede utilizar un MIG regional para hacer que dicha aplicación sea resistente a fallas zonales implementando réplicas redundantes en múltiples zonas y confiando en la funcionalidad de replicación de datos de su aplicación. En caso de una falla zonal, sus datos se entregan desde réplicas disponibles en las zonas restantes.
Revise las limitaciones para verificar si un MIG con estado cumple plenamente con sus requisitos.
¿Qué hace que un MIG tenga estado?
Un MIG se considera con estado si ha creado una configuración con estado.
Puede crear una configuración con estado cuando crea su MIG, o puede convertir un grupo de sin estado a con estado después de su creación agregando una configuración.
Para crear una configuración con estado, establezca una política con estado no vacía y/o una o más configuraciones por instancia no vacías:
- Una política con estado define los elementos que desea conservar para todas las instancias de su MIG.
- Una configuración por instancia define los elementos que se conservarán para una instancia de VM específica.
La configuración es efectiva después de que usted o el MIG la apliquen:
- Un MIG aplica automáticamente su configuración de política con estado a instancias nuevas y existentes.
- Al crear o actualizar configuraciones por instancia, puede elegir si desea aplicar la nueva configuración manualmente o aplicarla automáticamente.
Después de aplicar la configuración con estado (política con estado y/o configuraciones por instancia), puede verificarla inspeccionando el estado conservado de cada instancia administrada.
Los cambios posteriores en la configuración o el tamaño del estado de su MIG (por ejemplo, disminuir el tamaño del MIG o eliminar o abandonar 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 instancia de una combinación de la plantilla de instancia , la configuración opcional de todas las instancias , la política con estado opcional y las configuraciones opcionales por instancia que usted establezca. Después de establecer la configuración para su grupo, MIG usa esa configuración al crear máquinas virtuales. Para aplicar una configuración actualizada a las máquinas virtuales existentes, consulte Aplicar nuevas configuraciones de máquinas virtuales en un MIG .
Política con estado
Una política con estado define elementos con estado comunes para todas las instancias en un grupo de instancias administrado. Cada elemento que incluya en la política con estado debe definirse en la plantilla de instancia del MIG.
Puede realizar los siguientes cambios en una política con estado:
- Configure los discos para que tengan estado agregándolos a la política con estado.
- Configure los discos para que se vuelvan sin estado eliminándolos de la política con estado.
- Especifique que las direcciones IP deben tener estado agregando la configuración de interfaz de red a la política con estado.
- Especifique que las direcciones IP deben tratarse como sin estado eliminando la configuración de la política con estado.
Configuraciones por instancia
Una configuración por instancia define elementos con estado que son únicos para una instancia administrada específica, como discos específicos de la instancia, pares clave-valor de metadatos y direcciones IP. No es necesario definir metadatos y discos específicos de la instancia en la plantilla de instancia del MIG; sin embargo, las interfaces de red para IP con estado deben definirse en la plantilla de instancia del MIG.
Puede realizar los siguientes cambios en una configuración por instancia para una instancia específica en un MIG:
- Configure los discos definidos en la plantilla de instancia para que tengan estado para la instancia (agregando esos discos a la configuración por instancia) o sin estado (eliminando esos discos de la configuración por instancia).
- Configure los discos existentes , no definidos en la plantilla de instancia, para que se adjunten y tengan estado para la instancia (agregando esos discos a la configuración por instancia) o para que se desconecten de la instancia (eliminando discos de la configuración por instancia).
- Agregue o elimine pares clave-valor de metadatos con estado que sean específicos de la instancia.
- Configurar direcciones IP individualmente para instancias en un MIG para que se conviertan en con estado o sin estado.
Ejemplo de configuración con estado
A continuación se muestra un ejemplo de una configuración con estado:
En este cuadro:
- La plantilla de instancia define una configuración común para todas las instancias de VM en un MIG
- La política con estado define una configuración con estado común para discos con nombre de dispositivo,
data-disk
, que están definidos por la plantilla de instancia y que se crean y adjuntan individualmente 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 denominada
node-1
. Especifica adjuntar un disco existente,my-legacy-1
, a la instancianode-1
y tratarlo como con estado. También especifica un valor de clave de metadatos para preservar la individualidad de la instancianode-1
:node-id:xyz273
.
Al crear la VM node-1
, el MIG hace lo siguiente:
- Utiliza el tipo de máquina
n2-standard-2
, según la plantilla de instancia. - Crea y adjunta un disco de arranque con un nombre de disco generado automáticamente,
boot-node-1
y un nombre de dispositivoboot-disk
, utilizando una imagen de Debian GNU/Linux, de acuerdo con la plantilla de instancia. El MIG trata el disco de arranqueboot-node-1
como sin estado porque no está configurado en la política con estado o en la configuración por instancia. - Crea y adjunta un disco adicional con un nombre de disco generado automáticamente,
data-disk-1
y un nombre de dispositivo,data-disk
, mediante una imagen personalizada, según la plantilla de instancia. El MIG trata el disco adicionaldata-disk-1
como con estado porque su nombre de dispositivo se especifica en la política con estado. - Adjunta un disco existente con el nombre del disco,
my-legacy-1
, y utiliza el nombre del dispositivo,legacy-disk
, según la configuración por instancia. El MIG trata el disco adicionalmy-legacy-1
como con estado porque el nombre de su dispositivo se especifica en la configuración por instancia. - Establece tres pares clave-valor de metadatos: dos de la plantilla de instancia (
app:example-stateful-app
,version:1.0
) y uno de la configuración por instancia (node-id:xyz273
). El MIG trata el par clave-valornode-id:xyz273
como con estado porque se especifica en la configuración por instancia.
Al recrear la máquina virtual node-1
, asumiendo que la misma configuración sigue siendo efectiva, el MIG recrea los elementos sin estado y conserva los elementos con estado:
Recrea el disco de arranque a partir de la imagen original:
Primero, elimina el disco de arranque
boot-node-1
y luego lo recrea a partir de la imagen de Debian GNU/Linux, como se especifica en la plantilla de instancia.Conserva discos adicionales,
data-disk-1
ymy-legacy-1
:Desconecta los discos adicionales antes de eliminar la VM y luego los conecta a la VM después de haberla recreado.
Conserva el par clave-valor de metadatos individuales,
node-id:xyz273
:Establece los metadatos después de que se haya recreado la VM. También establece los pares clave-valor comunes de la plantilla de instancia (
app:example-stateful-app
yversion:1.0
).
Comentario
Queremos conocer sus casos de uso, desafíos y comentarios sobre los MIG con estado. Comparta sus comentarios con nuestro equipo en mig-discuss@google.com .
¿Qué sigue?
- Lea Configuración de MIG con estado para aprender cómo admitir cargas de trabajo con estado preservando nombres de instancias, discos persistentes y metadatos en instancias administradas.
- Aprenda cómo migrar una carga de trabajo existente a un MIG con estado .
- Obtenga más información sobre cómo funcionan los MIG con estado .
- Obtenga más información sobre los grupos de instancias administrados .
- Lea acerca de Trabajar con instancias administradas .