Proceso de migración en tiempo real durante los eventos de mantenimiento

Durante un evento de mantenimiento planificado del hardware subyacente de una instancia de máquina virtual (VM) o de una instancia de hardware desnudo, el servidor host no está disponible. Para que una instancia siga funcionando durante un evento del host, Compute Engine realiza una migración en tiempo real de la instancia a otro servidor host de la misma zona. Para obtener más información sobre los eventos de host, consulta el artículo Acerca de los eventos de host.

La migración en vivo te permite Google Cloud realizar tareas de mantenimiento sin interrumpir una carga de trabajo, reiniciar una instancia ni modificar ninguna de las propiedades de la instancia, como direcciones IP, metadatos, datos de almacenamiento en bloque, estado de la aplicación o ajustes de red.

La migración activa mantiene las instancias en funcionamiento en las siguientes situaciones:

  • Mantenimiento de la infraestructura. El mantenimiento de la infraestructura incluye el hardware del host, las redes y las redes eléctricas de los centros de datos, así como el sistema operativo (SO) y la BIOS del host.

  • Actualizaciones relacionadas con la seguridad y cambios en la configuración del sistema. Entre ellos, se incluyen eventos como la instalación de parches de seguridad y el cambio del tamaño de la partición raíz del host para almacenar la imagen y los paquetes del SO del host.

  • Fallos de hardware. Esto incluye fallos en la memoria, las CPUs, las tarjetas de interfaz de red y los discos. Si el fallo se detecta antes de que se produzca un fallo completo del servidor, Compute Engine realiza una migración en vivo preventiva de la instancia a un nuevo servidor host. Si el hardware falla por completo o impide la migración en directo, la instancia se termina y se reinicia automáticamente.

Compute Engine solo realiza migraciones activas de las máquinas virtuales que tienen la política de mantenimiento del host definida como "Migrar". Para obtener información sobre cómo cambiar la política de mantenimiento del host, consulta Definir la política de mantenimiento del host de la VM.

Proceso de migración activa y discos SSD locales

Compute Engine puede migrar en directo instancias con discos SSD locales conectados (excepto las instancias Z3 con más de 18 TiB de SSD Titanium conectados). Compute Engine mueve las instancias de VM junto con sus datos de SSD local a una nueva máquina antes de cualquier mantenimiento programado.

Limitaciones

La migración en directo no se admite en los siguientes tipos de máquinas virtuales:

  • Instancias Bare Metal. Las instancias creadas con un tipo de máquina Bare Metal no admiten la migración en vivo. El comportamiento de mantenimiento de estas instancias es TERMINATE y RESTART, respectivamente.
  • La mayoría de las instancias de Confidential VMs. La migración en tiempo real de instancias de máquinas virtuales confidenciales solo se admite en tipos de máquinas N2D con plataformas de CPU AMD EPYC Milan que ejecutan AMD SEV. El resto de las instancias de VM confidenciales no admiten la migración activa y deben configurarse para que se detengan y, opcionalmente, se reinicien durante un evento de mantenimiento del host. Consulta la sección Migración en directo para obtener más información.

  • Máquinas virtuales con GPUs conectadas. Las instancias de máquina virtual con GPUs conectadas deben configurarse para que se detengan y, opcionalmente, se reinicien. Compute Engine ofrece un aviso antes de que se detenga una instancia de VM con una GPU conectada, en función del tipo de GPU:

    • En la mayoría de las GPUs, Compute Engine avisa con 60 minutos de antelación.
    • En el caso de las familias de GPUs que se ejecutan en Cluster Director de AI Hypercomputer, Compute Engine avisa con 10 minutos de antelación.

    Para obtener más información sobre estas notificaciones de eventos de mantenimiento, consulta Consultar metadatos de servidor para obtener notificaciones de eventos de mantenimiento.

    Para obtener más información sobre cómo gestionar el mantenimiento de hosts con GPUs, consulta el artículo Gestionar el mantenimiento de hosts en la documentación de GPUs.

  • TPUs de Cloud. Las TPUs de Cloud no admiten la migración en tiempo real.
  • Máquinas virtuales optimizadas para el almacenamiento. Las VMs Z3 con más de 18 TiB de SSD de titanio adjunto no admiten la migración en directo. El comportamiento de mantenimiento de estas VMs se define como TERMINATE y RESTART.Compute Engine conserva los datos de Titanium SSD durante el evento de mantenimiento, tal como se describe en Persistencia de disco tras la finalización de la instancia.

¿Cómo funciona el proceso de migración en directo?

Cuando se programa la migración en tiempo real de una VM, Compute Engine envía una notificación para que puedas preparar tus cargas de trabajo y aplicaciones para esta interrupción. Durante la migración activa, Google Cloud observa un tiempo de interrupción mínimo, que suele ser mucho menor de 1 segundo. Si una VM no está configurada para migrarse en tiempo real, Compute Engine la cancela durante el mantenimiento del host. Las VMs que se hayan configurado para finalizar durante un evento del host se detendrán y (opcionalmente) se reiniciarán.

Cuando Google Cloud migra una VM en ejecución de un host a otro, mueve el estado completo de la VM del origen al destino de forma transparente para el sistema operativo invitado y para cualquier elemento que se comunique con él. Hay muchos componentes implicados para que esto funcione sin problemas, pero los pasos generales se muestran en la siguiente ilustración:

Migrar una VM y cada uno de sus recursos a un nuevo sistema host sin necesidad de reiniciar el sistema operativo invitado.
Componentes de la migración activa

El proceso comienza con una notificación que indica que una máquina virtual debe moverse de su máquina host actual. La notificación puede empezar con un cambio de archivo que indique que hay disponible una nueva versión de la BIOS, una operación de hardware que programe el mantenimiento o una señal automática de un fallo de hardware inminente.

El software de gestión de clústeres deGoogle Cloudmonitoriza constantemente estos eventos y los programa en función de las políticas que controlan los centros de datos, como las tasas de utilización de la capacidad y el número de máquinas virtuales que puede migrar un solo cliente a la vez.

Después de seleccionar una VM para la migración, Google Cloud envía una notificación al invitado para informarle de que la migración se producirá pronto. Después de un periodo de espera, se selecciona un host de destino y se le pide que configure una VM de destino nueva y vacía para recibir la VM de origen que se va a migrar. La autenticación se usa para establecer una conexión entre el origen y el destino.

La migración de una VM consta de tres fases:

  1. Fuente de apagón. La VM sigue ejecutándose en la fuente, mientras que la mayoría de los estados se envían de la fuente al destino. Por ejemplo,Google Cloud copia toda la memoria del invitado en el destino y registra las páginas que se han modificado en la fuente. El tiempo que se tarda en producirse un fallo parcial de la fuente depende del tamaño de la memoria del invitado y de la velocidad a la que se cambian las páginas.

  2. Tiempo sin disponibilidad. Un momento muy breve en el que la VM no se ejecuta en ningún sitio. La VM de origen se pausa y se envía todo el estado restante necesario para empezar a ejecutar la VM en el destino. La VM entra en la fase de apagón cuando el envío de cambios de estado durante la fase de apagón parcial de la fuente llega a un punto de rendimientos decrecientes. Se usa un algoritmo que equilibra el número de bytes de memoria que se envían con la velocidad a la que la máquina virtual invitada realiza cambios.

    Durante los apagones, el reloj del sistema parece adelantarse hasta 5 segundos. Si un evento de apagón supera los 5 segundos, Google Cloud se detiene y sincroniza el reloj mediante un daemon que se incluye en los paquetes de invitado de la VM.

  3. Objetivo de apagón parcial. La VM se ejecuta en la VM de destino. La VM de origen está presente y puede proporcionar asistencia para la VM de destino. Por ejemplo, hasta que la estructura de red se haya puesto al día con la nueva ubicación de la VM de destino, la VM de origen proporciona servicios de reenvío de paquetes a la VM de destino y desde ella.

Por último, se completa la migración y el sistema elimina la VM de origen. Puedes ver que la migración se ha llevado a cabo en los registros de Cloud Logging de tu VM.

Migración en tiempo real de máquinas virtuales de único cliente

Mientras se ejecuta tu carga de trabajo, es posible que quieras mover las VMs a otro nodo o grupo de nodos de único cliente. Si mueves una VM a un grupo de nodos, Compute Engine determina en qué nodo se colocará. Para obtener información sobre el único cliente, consulta la descripción general de único cliente.

Para mover máquinas virtuales de único cliente a otro nodo u otro grupo de nodos, puedes iniciar manualmente una migración en tiempo real. También puedes iniciar manualmente una migración en tiempo real para mover una VM de un host multiinquilino a un nodo de único cliente. Para obtener más información, consulta Migrar manualmente máquinas virtuales en tiempo real.

Siguientes pasos