Acerca de los eventos del host

Para elegir cómo responden las instancias de máquinas virtuales (VM) durante un evento de host o después de él, puedes configurar la política de mantenimiento del host durante la creación de una VM. Un evento de host puede incluir el mantenimiento regular de la infraestructura de Compute Engine o un error de host en una VM. De forma predeterminada, las VMs están configuradas en migración en vivo durante los eventos del sistema host, pero puedes configurarlas para que finalicen y se reinicien de forma opcional. Las VMs Z3 son la excepción a la migración en vivo, ya que se reinician en el lugar de forma predeterminada.

Los siguientes eventos del host conducen a la migración en vivo o a la finalización de tu VM según la política de mantenimiento del host que establezcas:

Eventos de mantenimiento

Un evento de mantenimiento es cuando Compute Engine detiene una VM para realizar una actualización de hardware o software. Si habilitas la política de mantenimiento del host de migración en vivo, Compute Engine mueve la VM a un host nuevo y no se interrumpe la aplicación.

El comportamiento de la VM durante un evento de mantenimiento puede variar según los usuarios de la VM. En la siguiente tabla, se muestran algunas diferencias entre el comportamiento de las VM de usuarios múltiples y los de usuario único durante los eventos de mantenimiento.

Usuarios del host Frecuencia aproximada* Migración en vivo a un host nuevo Selección de host
Multiusuario Cada 2 semanas Sí Compute Engine
Usuario único Cada 4 a 6 semanas Depende de la política de mantenimiento del host. Depende de la política de mantenimiento del host.
* Estas frecuencias son aproximaciones; en ocasiones, Compute Engine podría realizar tareas de mantenimiento con mayor frecuencia.

Compute Engine también aplica algunas actualizaciones de hipervisor y redes básicas en segundo plano sin interrupciones.

Política de mantenimiento del host

La política de mantenimiento del host de una VM determina su comportamiento durante los siguientes eventos:

  • Cuando hay un evento de mantenimiento en el que Google debe trasladar una VM a otra máquina anfitrión
  • Cuando ocurre un error de host en el que Google debe finalizar o reiniciar una VM

Puedes configurar las VM para que se sigan ejecutando durante el mantenimiento del host, mientras que Compute Engine las migra en vivo a otro host, o puedes optar por detener las VM. Es posible actualizar la política de mantenimiento del host de una VM en cualquier momento con el objetivo de controlar cómo quieres que se comporten tus VM.

Puedes cambiar la política de mantenimiento del host de una VM si configuras los siguientes parámetros:

  • Comportamiento de mantenimiento: indica si la VM se migra en vivo o se detiene cuando ocurre un evento de mantenimiento.
  • Comportamiento de reinicio: indica si Compute Engine reinicia o finaliza la VM si esta falla o experimenta un error de host.
  • Tiempo de detección de error del host: la cantidad máxima de tiempo que Compute Engine espera para reiniciar o finalizar una VM después de detectar que la VM no responde.
  • Tiempo de recuperación de SSD local: la cantidad máxima de tiempo que Compute Engine dedica a la recuperación de los datos en discos SSD locales después de detectar un error del host. Los datos del SSD local se pierden si transcurre el tiempo especificado sin una recuperación correcta.

Programación del mantenimiento

Google Cloud proporciona funciones que permiten un control más estricto sobre el mantenimiento. Si usas ciertas familias de VMs, puedes especificar las preferencias de mantenimiento para obtener notificaciones de varios días a través de Cloud Logging. Cuando recibes una notificación, puedes activar el mantenimiento en cualquier momento que elijas hasta el evento programado.

Puedes usar estas funciones junto con la política de mantenimiento del host para personalizar un programa que se adapte a tu carga de trabajo.

Migración en vivo

De forma predeterminada, todas las VMs, excepto las VMs de Z3, están configuradas con la migración en vivo, con la que Compute Engine migra automáticamente tu VM lejos de un evento de mantenimiento de infraestructura, y tu VM permanecerá en ejecución durante la migración. Es posible que la VM experimente un período breve de disminución del rendimiento, pero, en general, la mayoría de las VMs no deberían tener un rendimiento notablemente diferente. Esto resulta ideal para las VM que requieren un tiempo de actividad constante y pueden tolerar un corto período de disminución del rendimiento.

Cuando Compute Engine migra tu VM, informa un evento del sistema que se publica en la lista de operaciones de zona. Puedes revisar este evento si visualizas las operaciones de Compute Engine para una zona específica. Los eventos de migración en vivo tienen el siguiente tipo de operación:

    compute.instances.migrateOnHostMaintenance

Detén y reinicia la instancia (opcional)

Si no deseas que tu VM realice una migración en vivo, puedes optar por detenerla y, de manera opcional, reiniciarla. En el caso de las VM configuradas para detenerse y reiniciarse de forma opcional, Compute Engine envía una señal de apagado suave para apagar la VM. Luego, espera 60 segundos para que la VM se apague de forma correcta, finaliza la VM y la reinicia lejos del evento de mantenimiento. Si la VM no se cierra de forma correcta en 60 segundos, se finaliza.

Esta opción es ideal si tus VM exigen un rendimiento máximo y constante y, si tu aplicación general está compilada para controlar fallas o reinicios de VM.

Cuando Compute Engine detiene y reinicia tus VM, informa un evento del sistema que se publica en la lista de operaciones de zona. Puedes revisar este evento si visualizas las operaciones de Compute Engine para una zona específica. Los eventos que se detuvieron tienen el siguiente tipo de operación:

compute.instances.terminateOnHostMaintenance

Cuando tu VM se reinicia, usa el mismo disco de arranque persistente y vuelve a conectar cualquier disco persistente secundario que hayas configurado. Los datos en esos discos se mantienen durante la migración y el reinicio de la VM.

Los datos de SSD locales no se conservan cuando se detiene una VM debido a un evento de mantenimiento. Cuando la VM se reinicia, crea una SSD local nueva que debes formatear y activar.

Los datos de SSD locales persisten en las VMs de Z3 con optimización de almacenamiento (vista previa). Cuando hay un evento de mantenimiento, la VM de Z3 se reinicia en lugar de migrar a un host nuevo. Al final del mantenimiento de rutina, la VM se reinicia. Google Cloud hace el mejor esfuerzo para garantizar que los datos de las SSD locales permanezcan intactos. Sin embargo, hay casos en los que los datos no se pueden recuperar, como un caso de tiempo de espera.

Reinicio automático

Si la VM se configuró para detenerse cuando hay un evento de mantenimiento, o si esta falla debido a un problema subyacente en el hardware, puedes configurar Compute Engine para que la reinicie de forma automática mediante la configuración del campo automaticRestart como true. Esta configuración no se aplica si la VM se desconecta debido a la acción de un usuario, como una llamada a sudo shutdown, o durante una interrupción en la zona.

Cuando Compute Engine reinicia tu VM de forma automática, informa un evento del sistema que se publica en la lista de operaciones de zona. Puedes revisar este evento si visualizas las operaciones de Compute Engine para una zona específica. Los eventos de reinicio automático tienen el siguiente tipo de operación:

compute.instances.automaticRestart

Errores del host

Un error de host (compute.instances.hostError) significa que hubo un problema de hardware o software en la máquina física que aloja tu VM que causó la falla. Un error de host que implica una falla total de hardware o, también, otros problemas de hardware podría evitar la migración en vivo de la VM. Si la VM está configurada para reiniciarse de manera automática, que es la configuración predeterminada, Google reinicia la VM, por lo general, dentro de los tres minutos posteriores a la detección del error. Según el problema, el reinicio puede tardar hasta 5.5 minutos.

VMs con discos SSD locales

Si se produce un error de host en una VM que tiene uno o más discos SSD locales conectados, Compute Engine vuelve a conectarse a la VM y preservar los datos del SSD local. Mientras Compute Engine recupera tu VM y el disco SSD local, el sistema host y el disco subyacente no responden.

Puedes especificar cuánto tiempo dedica Compute Engine a recuperar datos de SSD locales configurando el tiempo de espera de recuperación de SSD local.

Para obtener más información sobre cómo se comportan los discos SSD locales cuando se produce un error de host, consulta la persistencia de datos de SSD local.

VMs que no responden

En ocasiones, una VM puede dejar de responder antes de que se detecte un error de host. Puedes reducir el tiempo que Compute Engine espera para reiniciar o finalizar la VM si configuras el tiempo de espera de recuperación de errores del host (Vista previa). Para obtener más información, consulta Configura políticas de disponibilidad.

Las fallas físicas de hardware y software pueden ocurrir de forma ocasional, pero son casos poco frecuentes. Para proteger tus aplicaciones y servicios de estos eventos del sistema que pueden ser disruptivos, revisa los siguientes recursos:

Google también ofrece servicios administrados como App Engine y el entorno flexible de App Engine.

Tiempo de espera de recuperación de SSD locales

Cuando se produce un error de host, Compute Engine intenta recuperar cualquier disco SSD local conectado a la VM. Puedes controlar cuánto tiempo Compute Engine dedica a recuperar los datos con el tiempo de espera de recuperación del SSD local. De forma predeterminada, Compute Engine dedica 1 hora a recuperar los datos, pero los valores válidos están entre 0 y 168, en incrementos de 1 hora. La excepción es Z3, que tiene un tiempo de recuperación predeterminado de hasta 6 horas.

Si se vence el tiempo de espera y los datos aún no se pueden recuperar, Compute Engine reiniciará la VM sin el disco SSD local. Compute Engine conecta un disco SSD local en blanco a la VM reiniciada.

Si el tiempo de espera es de 1 hora o más, la VM está en un estado REPAIRING mientras Compute Engine recupera cualquier disco SSD local conectado. La VM y los discos SSD locales no responden durante la recuperación.

Si el tiempo de espera es 0, Compute Engine no intentará recuperar los discos SSD locales y los datos no se podrán recuperar. Puedes establecer el tiempo de espera de recuperación en 0 si reanudar la carga de trabajo es más importante que recuperar los datos de la SSD local.

Detén la recuperación del disco SSD local

Puedes interrumpir el proceso de recuperación antes de que venza el tiempo de espera de recuperación de la SSD local. Para hacerlo, usa el comando gcloud compute instances stop con la marca --discard-local-ssd=True.

Esto detendrá el proceso de recuperación, detendrá la VM y descartará los datos del SSD local. Luego, puedes reiniciar la VM. Consulta Detén una VM con SSD local para obtener más información.

Para establecer el tiempo de espera de recuperación de SSD local, consulta Configura la política de mantenimiento del host de VM.

¿Qué sigue?