Acerca de los eventos de anfitrión

Durante la vida útil de una instancia de máquina virtual o de una instancia de hardware desnudo, la máquina host en la que se ejecuta tu instancia puede experimentar varios eventos de host. Un evento de host puede incluir el mantenimiento periódico de la infraestructura de Compute Engine o, en raras ocasiones, un error de host. Puedes elegir cómo responden tus instancias de VM y de hardware desnudo durante o después de un evento del host configurando la política de mantenimiento del host.

De forma predeterminada, la mayoría de las instancias están configuradas para migrarse automáticamente durante los eventos del host. En todas las series de máquinas, excepto Z3, puedes anular este comportamiento y definir explícitamente que las instancias se terminen y, opcionalmente, se reinicien. Algunos tipos de máquinas no admiten la migración en directo, como las instancias de hardware desnudo, las instancias con GPUs conectadas o las instancias Z3 con más de 18 TiB de SSD de Titanium conectado. Estas instancias finalizan durante los eventos del host. Para obtener más información, consulta Comportamiento durante el mantenimiento y el reinicio.

Tipos de eventos de anfitrión

Hay dos tipos de eventos de anfitrión, que se describen con más detalle en las siguientes secciones:

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

Eventos de mantenimiento

Un evento de mantenimiento se produce cuando Compute Engine tiene que llevar a cabo una actividad de mantenimiento o reparación que requiere que las máquinas virtuales se trasladen del servidor host. Si habilitas la migración en tiempo real política de mantenimiento del host en un tipo de instancia compatible, Compute Engine moverá la instancia a un nuevo host y tu aplicación sufrirá las mínimas interrupciones.

Compute Engine también aplica algunas actualizaciones ligeras del hipervisor y de la red en segundo plano sin interrupciones, ya que mantiene la instancia en el mismo host.

El comportamiento de una instancia durante un evento de mantenimiento puede variar en función de la tenencia de la instancia y del tipo de máquina. Puedes consultar información sobre el comportamiento del mantenimiento de cada tipo de máquina en la página de la familia de máquinas correspondiente, como se indica a continuación:

Para obtener información sobre las políticas de mantenimiento de las instancias con GPUs conectadas, consulta Gestionar eventos de mantenimiento de host de GPU.

En el caso de las máquinas virtuales de único cliente, la frecuencia aproximada de los eventos de mantenimiento planificado del host es de entre 4 y 6 semanas. La compatibilidad con la migración activa depende de la política de mantenimiento del host de la máquina virtual de único cliente.

Errores del host

Un error de host (compute.instances.hostError) significa que ha habido un problema de hardware o software en la máquina física o en la infraestructura del centro de datos que aloja tu instancia de cálculo, lo que ha provocado que falle. Un error del host que implique un fallo total del hardware u otros problemas de hardware puede impedir la migración en directo de tu instancia. Si tu instancia está configurada para reiniciarse automáticamente (que es el ajuste predeterminado), Compute Engine la reiniciará, normalmente en un plazo de tres minutos desde que se detectó el error. En función del problema, el reinicio puede tardar hasta 5 minutos y medio.

En ocasiones, una instancia de proceso puede dejar de responder antes de que se señale un error de host. Puedes reducir el tiempo que espera Compute Engine para reiniciar o finalizar la instancia configurando el tiempo de espera de recuperación de errores del host. Para obtener más información, consulta Definir políticas de disponibilidad.

Los fallos de hardware y software físicos pueden ocurrir de vez en cuando, pero son poco frecuentes. Para proteger tus aplicaciones y servicios de estos eventos del sistema potencialmente perjudiciales, consulta los siguientes recursos:

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

Información general sobre 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
  • Evento de error de host o instancia que no responde

Puedes configurar las instancias para que sigan ejecutándose durante el mantenimiento del host mientras Compute Engine las migra en tiempo real a otro host, o bien puedes detener la instancia.

Puedes cambiar la política de mantenimiento del host de una instancia configurando los siguientes ajustes:

  • Comportamiento durante el mantenimiento: si la instancia se migra automáticamente o se detiene cuando se produce un evento de mantenimiento.
  • Comportamiento al reiniciar: 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 errores del host: el tiempo máximo que espera Compute Engine para reiniciar o finalizar una instancia después de detectar que no responde.
  • Tiempo de recuperación de SSD local: el tiempo máximo que Compute Engine dedica a recuperar los datos de los discos SSD locales después de detectar un error de host. Los datos de SSD local se perderán si transcurre el tiempo especificado sin que se haya realizado una recuperación correcta.

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

Comportamientos de mantenimiento y reinicio

Cuando se produce un evento de host, la instancia de computación puede usar la migración en vivo o se puede terminar la instancia. Si se termina una instancia, puedes reiniciarla tú mismo o hacer que Compute Engine la reinicie automáticamente.

Es posible que las siguientes series de máquinas no admitan la migración en tiempo real y, en su lugar, requieran la finalización durante los eventos del host:

Migrar en tiempo real

De forma predeterminada, la mayoría de los tipos de instancia están configurados para migrar en directo, excepto los tipos de instancia mencionados en la sección anterior.

Durante la migración activa, Compute Engine migra automáticamente tu instancia para evitar un evento de mantenimiento de la infraestructura, y tu instancia sigue ejecutándose durante la migración. Es posible que tu instancia experimente un breve periodo de rendimiento reducido, pero, por lo general, la mayoría de las instancias no deberían funcionar de forma notablemente diferente. Es ideal para las instancias que requieren un tiempo de actividad constante y pueden tolerar un breve periodo de rendimiento reducido.

Cuando Compute Engine migra tu instancia, registra un evento del sistema que se publica en la lista de operaciones de la zona y en los registros de eventos del sistema. Puedes revisar este evento consultando las operaciones de Compute Engine de una zona específica. Los eventos de migración en directo tienen el siguiente tipo de operación:

compute.instances.migrateOnHostMaintenance

Finalizar y reiniciar

Si no quieres que tu instancia se migre en directo o si tu tipo de instancia no admite la migración en directo, puedes permitir queGoogle 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 apagar la instancia. A continuación, espera 60 segundos a que la instancia se apague correctamente y cambia su estado a TERMINATED. Si la instancia no se cierra correctamente en 60 segundos, se finalizará de forma forzosa.

Esta opción es ideal si tus instancias requieren un rendimiento máximo constante y si tu aplicación general está diseñada para gestionar los fallos o reinicios de las instancias.

Cuando Compute Engine detiene una instancia debido a un evento del host, registra un evento del sistema que se publica en la lista de operaciones de la zona y en los registros de eventos del sistema. Puedes revisar este evento consultando las operaciones de Compute Engine de 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 tu instancia está configurada para detenerse cuando se produzca un evento de mantenimiento o si falla debido a un problema de hardware subyacente, Compute Engine puede reiniciarla automáticamente. La instancia se reinicia en el mismo servidor host o se mueve a otro servidor de la misma zona que no participe en el evento de mantenimiento.

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

Para configurar el reinicio automático, asigna el valor true al campo de la política de mantenimiento del host automaticRestart. Este ajuste no se aplica si la instancia se pone fuera de servicio debido a una interrupción zonal o mediante una operación manual, como llamar a sudo shutdown en el SO invitado.

Cuando Compute Engine reinicia automáticamente tu instancia, registra un evento del sistema que se publica en la lista de operaciones de la zona. Puedes revisar este evento consultando las operaciones de Compute Engine de una zona específica. Los eventos de reinicio automático tienen el siguiente tipo de operación:

compute.instances.automaticRestart

Persistencia de los discos tras la finalización de la instancia

Como Persistent Disk yHyperdisk son almacenamiento conectado a la red, cuando se reinicia la instancia, Compute Engine vuelve a asociar el disco de arranque y cualquier disco secundario a la instancia. Los datos de esos discos se conservan durante la migración en directo y los reinicios de instancias.

Compute Engine conserva los datos de los discos SSD locales después de un evento del host cuando es posible. Sin embargo, Compute Engine no garantiza la persistencia de los datos de los discos SSD locales.

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

    • Configuras tu instancia para la migración activa 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 proceso con discos SSD locales conectados que solo admite la finalización y el reinicio automático se somete a un evento de mantenimiento. La instancia se reinicia en el mismo lugar, conservando los datos del SSD local, en lugar de migrar a un nuevo host.

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

    • Apagas el sistema operativo invitado y fuerzas la detención de la instancia.
    • Configuras la instancia para que se detenga cuando se produzcan eventos de mantenimiento del host y la instancia se somete a 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 caduque el tiempo de espera. En este caso, la instancia se reinicia sin recuperar los discos SSD locales. Cuando se reinicie la instancia, Compute Engine adjuntará discos SSD locales vacíos a la instancia reiniciada. Debes formatear y montar estos discos para que la instancia pueda usarlos. Los datos de los discos SSD locales originales no se pueden recuperar.

Google Cloud hace todo lo posible para que tus datos de SSD local no se pierdan. Sin embargo, hay casos en los que no se pueden recuperar los datos, como cuando se agota el tiempo de espera. Para obtener más información sobre cuándo se conservan los discos SSD locales, consulta Persistencia de datos de SSD local.

Tiempo de espera de recuperación de SSD local

Cuando se produce un error de host, Compute Engine intenta recuperar los discos SSD locales conectados a la instancia. Puedes controlar el tiempo que Compute Engine dedica a intentar recuperar los datos con el ajuste de la política de host localSsdRecoveryTimeout.

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

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

Si el tiempo de espera de recuperación no es 0, pero se alcanza el límite de tiempo antes de que se recuperen los datos de la unidad SSD local, Compute Engine reinicia la instancia sin el disco SSD local. Compute Engine adjunta discos SSD locales nuevos y vacíos a la instancia reiniciada. Debes formatear y montar estos discos para que la instancia pueda usarlos.

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

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

Detener la recuperación de un 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 ello, 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 computación y descarta los datos del SSD local. Después, puedes reiniciar la instancia. Para obtener más información, consulta Detener una instancia con SSD local.

Esta opción no está disponible en las instancias Z3.

Para definir el tiempo de espera de recuperación de SSD local, consulta Definir la política de mantenimiento del host de la instancia.

Programación del mantenimiento

Google Cloud ofrece funciones que permiten controlar mejor el mantenimiento. Si usas determinadas familias de máquinas, puedes especificar 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 la CLI de gcloud o el método instances.describe de REST. Cuando recibas una notificación, tendrás un periodo de tiempo para iniciar el mantenimiento programado a la hora que elijas. Si no activas el mantenimiento programado, el evento de mantenimiento se producirá al final del periodo de notificación, que es la hora programada que se indica en la notificación.

Puedes usar estas funciones junto con tu política de mantenimiento de hosts para personalizar una programación de mantenimiento que se adapte a tu carga de trabajo.

Siguientes pasos