Acerca de los eventos del host

Durante el ciclo de vida de una instancia de máquina virtual (VM) o de bare metal, la máquina anfitrión en la que se ejecuta la instancia puede experimentar varios eventos de host. Un evento de host puede incluir el mantenimiento regular de la infraestructura de Compute Engine o, en casos excepcionales, un error de host. Puedes elegir cómo responden las instancias de VM y bare metal durante un evento de host o después de él. Para ello, configura la política de mantenimiento del host.

De forma predeterminada, la mayoría de las instancias están configuradas para migrar en vivo durante los eventos del host. Puedes anular este comportamiento y configurar de manera explícita las instancias para que se finalicen y, de manera opcional, se reinicien. Algunos tipos de máquinas no admiten la migración en vivo, como las instancias de Bare Metal o las VMs con GPUs adjuntas. Estas instancias finalizan durante los eventos del host. Para obtener más información, consulta Comportamientos de mantenimiento y reinicio.

Tipos de eventos del host

Existen dos tipos de eventos de host, que se describen con más detalle en las siguientes secciones:

Si tu instancia deja de responder, esto también puede activar un reinicio o una terminación de la instancia.

Eventos de mantenimiento

Un evento de mantenimiento es cuando Compute Engine debe realizar una actividad de mantenimiento o reparación que requiere que se quiten las VMs del servidor host. Si habilitas la política de mantenimiento del host de migración en vivo para un tipo de instancia compatible, Compute Engine mueve la instancia a un host nuevo y se produce una interrupción mínima en la aplicación.

El comportamiento de la instancia durante un evento de mantenimiento puede variar según los usuarios de la instancia y el tipo de máquina. En la siguiente tabla, se resume el comportamiento de los eventos de mantenimiento planificados.

Usuarios del host Frecuencia aproximada del
evento de mantenimiento		 Se admite la migración en vivo Selección de host
Multiusuario (compartido) 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.
X4 Un mínimo de 90 días No Compute Engine
C3 Un mínimo de 30 días No Compute Engine

Compute Engine también aplica algunas actualizaciones de hipervisor y redes básicas en segundo plano sin interrupciones, ya que retiene la instancia en el mismo host.

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 o la infraestructura del centro de datos que aloja tu instancia de procesamiento, lo 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 tu instancia. Si la instancia está configurada para reiniciarse automáticamente, que es la configuración predeterminada, Compute Engine reinicia la instancia, 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.

En ocasiones, una instancia de procesamiento puede dejar de responder antes de que se indique un error de host. Puedes reducir el tiempo que Compute Engine espera para reiniciar o finalizar la instancia si configuras el tiempo de espera de recuperación de errores del host (Versión preliminar). 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.

Descripción general de la política de mantenimiento del host

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

  • Evento de mantenimiento
  • La instancia o el evento de error del host no responden

Puedes configurar las instancias 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 instancias.

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

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

Puedes actualizar la política de mantenimiento del host de una instancia en cualquier momento con el objetivo de controlar cómo quieres que se comporten tus instancias.

Comportamientos de mantenimiento y reinicio

Cuando se produce un evento del host, la instancia de procesamiento puede usar la migración en vivo o finalizarse. Si se finaliza una instancia, puedes reiniciarla por tu cuenta o hacer que Compute Engine la reinicie automáticamente.

Las siguientes series de máquinas no admiten la migración en vivo y, en su lugar, se finalizan durante los eventos del host:

Migración en vivo

De forma predeterminada, la mayoría de los tipos de instancias están configurados para la migración en vivo, excepto los siguientes:

  • Instancias con GPUs y TPU adjuntas
  • Instancias de Bare Metal o X4 de C3
  • Instancias de Z3

Durante la migración en vivo, Compute Engine migra automáticamente tu instancia lejos de un evento de mantenimiento de infraestructura, y la instancia permanece en ejecución durante la migración. Es posible que la instancia experimente un período breve de disminución del rendimiento, pero, en general, la mayoría de las instancias no deberían tener un rendimiento notablemente diferente. Esto resulta ideal para las instancias que requieren un tiempo de actividad constante y pueden tolerar un corto período de disminución del rendimiento.

Cuando Compute Engine migra tu instancia, informa un evento del sistema que se publica en la lista de operaciones de zona y en los registros de eventos del sistema. 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

Finalizar y reiniciar

Si no deseas que tu instancia realice una migración en vivo o si el tipo de instancia no admite la migración en vivo, puedes permitir que Google Cloud detenga la instancia cuando se produzca un evento de host. Con esta configuración, si se produce un evento de host, Compute Engine envía una señal de apagado suave para cerrar la instancia. Luego, espera 60 segundos para que la instancia se cierre de forma correcta y establece el estado de la instancia en TERMINATED. Si la instancia no se cierra de forma correcta en 60 segundos, se finaliza de forma forzosa.

Esta opción es ideal si tus instancias exigen un rendimiento máximo y constante. Tu aplicación, en general, está diseñada para manejar fallas o reinicios de instancias.

Cuando Compute Engine detiene una instancia debido a un evento del host, informa un evento del sistema que se publica en la lista de operaciones de zona y en los registros de eventos del sistema. Puedes revisar este evento si visualizas las operaciones de Compute Engine para una zona específica. Los eventos de finalización de instancias tienen el siguiente tipo de operación:

compute.instances.terminateOnHostMaintenance

Reinicio automático

Si la instancia está configurada para detenerse cuando hay un evento de mantenimiento o si falla debido a un problema subyacente en el hardware, Compute Engine puede reiniciarla automáticamente. La instancia se reinicia en el mismo servidor host o se mueve a otro servidor en la misma zona que no participa en el evento de mantenimiento.

De forma predeterminada, Compute Engine intenta recuperar instancias con discos SSD locales conectados durante una hora. Si se alcanza el límite de tiempo, Compute Engine intentará reiniciar la instancia en un servidor host diferente en la misma zona. Las instancias Z3 y X4 tienen diferentes tiempos de espera predeterminados. Estos tipos de instancias se reinician en el mismo servidor host después de la finalización de la instancia.

Para configurar el reinicio automático, establece el campo de la política de mantenimiento del host automaticRestart en true. Esta configuración no se aplica si la instancia se desconecta debido a una interrupción zonal o a través de una acción del usuario, como llamar a sudo shutdown dentro del SO huésped.

Cuando Compute Engine reinicia tu instancia 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

Persistencia en disco después de la cancelación de una instancia

Debido a que Persistent Disk y Hyperdisk son almacenamiento conectado a la red, cuando se reinicia tu instancia, Compute Engine vuelve a conectar el disco de arranque y cualquier disco secundario a la instancia. Los datos en esos discos se mantienen durante la migración en vivo y los reinicios de la instancia.

Compute Engine conserva los datos en los discos SSD locales después de un evento de host siempre que sea posible. Sin embargo, Compute Engine no garantiza la persistencia de los datos en las SSD locales.

  • Los discos SSD locales se conservan en los siguientes casos:

    • Si configuras la instancia para la migración en vivo y la instancia pasa por un evento de mantenimiento del host.
    • Se produce un error de host y Compute Engine vuelve a conectar la instancia a los discos SSD locales dentro del límite de tiempo de espera.
    • Una instancia de procesamiento con discos SSD locales conectados que solo admite la terminación y el reinicio automático experimenta un evento de mantenimiento. La instancia se reinicia en su lugar, lo que conserva los datos del SSD local, en lugar de migrar a un host nuevo.

  • Los discos SSD locales no se conservan en los siguientes casos:

    • Si cierras el sistema operativo invitado y fuerzas la detención de la instancia.
    • Si configuras la instancia para que se detenga en eventos de mantenimiento del host y la instancia pasa por un evento de mantenimiento del host.
    • Se produce un error de host y Compute Engine no puede volver a conectar los discos a la instancia antes de que venza el tiempo de espera. En este caso, la instancia se reinicia sin recuperar los discos SSD locales. Cuando se reinicia la instancia, Compute Engine conecta discos SSD locales en blanco a la instancia reiniciada. Debes formatear y activar estos discos para que la instancia pueda usarlos. Los datos de los discos SSD locales originales no se pueden recuperar.

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. Para obtener más información sobre cuándo se preservan los discos SSD locales, consulta Persistencia de datos en SSD local.

Tiempo de espera de recuperación de SSD locales

Cuando se produce un error de host, Compute Engine intenta recuperar los discos SSD locales conectados a la instancia. Puedes controlar cuánto tiempo dedica Compute Engine a intentar recuperar los datos con el parámetro de configuración localSsdRecoveryTimeout de la política de host.

De forma predeterminada, Compute Engine dedica 1 hora a recuperar los datos, pero los valores válidos para este parámetro de configuración están entre 0 y 168, en incrementos de 1 hora. Para las instancias de Z3, el valor predeterminado es 6, lo que significa que las instancias de Z3 intentarán recuperar los datos de la SSD local durante 6 horas antes de alcanzar el límite de tiempo de espera.

Si configuras el tiempo de espera de recuperación de SSD local en 0, Compute Engine no intentará recuperar ningún disco SSD local conectado. La instancia se reinicia lo antes posible y los datos de la SSD local son irrecuperables. Usa esta configuración si reanudar la carga de trabajo es más importante que recuperar los datos de la SSD local.

Si el tiempo de espera de recuperación no se establece en 0, pero se alcanza el límite de tiempo antes de que se recuperen los datos del SSD local, Compute Engine reiniciará la instancia sin el disco SSD local. Compute Engine conecta discos SSD locales nuevos y en blanco a la instancia reiniciada. Debes formatear y activar estos discos para que la instancia pueda usarlos.

La instancia está en un estado REPAIRING mientras Compute Engine intenta recuperar los discos SSD locales. La instancia y los discos SSD locales no estarán disponibles durante este tiempo.

Si configuras el tiempo de espera de recuperación de SSD local en el valor máximo de 168, la instancia permanecerá en el estado REPAIRING durante un máximo de 7 días mientras Compute Engine intenta recuperar los discos SSD locales.

Detén la recuperación del disco SSD local

Puedes interrumpir el proceso de recuperación del disco SSD local antes de que Compute Engine alcance el límite de tiempo de espera de recuperación. Para hacerlo, usa el comando gcloud compute instances stop con la marca --discard-local-ssd=True.

Este comando detiene el proceso de recuperación, detiene la instancia de procesamiento y descarta los datos del SSD local. Luego, puedes reiniciar la instancia. Consulta Detén una instancia 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 la instancia.

Programación del mantenimiento

Google Cloud proporciona funciones que permiten un control más estricto sobre el mantenimiento. Si usas ciertas familias de máquinas, puedes especificar las preferencias de mantenimiento y recibir notificaciones de los próximos eventos de mantenimiento a través de Cloud Logging, el servidor de metadatos de la instancia, el comando compute instances describe de gcloud CLI o el método instances.describe de REST. Cuando recibes una notificación, tienes un período en el que puedes iniciar el mantenimiento programado en el momento que elijas. Si no activas el mantenimiento programado, el evento de mantenimiento se produce al final del período de notificación, que es la hora programada que se indica en la notificación.

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

¿Qué sigue?