Durante un evento de mantenimiento planificado en el hardware subyacente de una instancia de máquina virtual (VM), Compute Engine podría mover la VM a otro host. Para mantener una VM en ejecución durante un evento del host, Compute Engine realiza una migración en vivo de la VM a otro host en la misma zona. Para obtener más información sobre los eventos del host, consulta Información sobre los eventos del host.
La migración en vivo permite que Google Cloud realice mantenimiento sin interrumpir una carga de trabajo, reiniciar una VM ni modificar ninguna de sus propiedades, como direcciones IP, metadatos, datos de almacenamiento en bloque, estado de la aplicación y configuración de red.
Además de mantener las VM en ejecución durante los eventos de host planificados, la migración en vivo mantiene las VM en ejecución durante las siguientes situaciones:
Mantenimiento de la infraestructura. El mantenimiento de la infraestructura incluye hardware del host, red y cuadrícula de energía en los centros de datos, y SO y BIOS de host.
Actualizaciones relacionadas con la seguridad y cambios en la configuración del sistema. Estos 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 el almacenamiento de los paquetes y la imagen del SO del host.
Fallas de hardware Esto incluye fallas en la memoria, las CPU, las tarjetas de interfaz de red y los discos. Si el hardware falla por completo o impide la migración en vivo, la VM finaliza, se reinicia de forma automática y Compute Engine registra un
hostError.
Compute Engine solo realiza una migración en vivo de las VM que tienen la política de mantenimiento del host configurada para migrar. Para obtener información sobre cómo cambiar la política de mantenimiento del host, consulta Configura la política de mantenimiento del host de VM.
Proceso de migración en vivo y SSD locales
Compute Engine puede migrar en vivo las VMs con SSD locales conectados, trasladando las VMs y sus SSD locales a una máquina nueva antes de cualquier mantenimiento programado.
Limitaciones
La migración en vivo no es compatible con los siguientes tipos de VM:
Algunas instancias de Confidential VM. La migración en vivo solo es compatible con los tipos de máquinas N2D con plataformas de CPU AMD EPYC Milan que ejecutan SEV de AMD. Todos los demás tipos de Confidential VM deben configurarse para que se detengan y, de forma opcional, se reinicien. Consulta Migración en vivo para obtener más detalles.
VMs con GPU conectadas. Las instancias de VM con GPU conectadas deben configurarse para que se detengan y, de forma opcional, se reinicien. Compute E ngine ofrece un aviso de 60minutos antes de que finalice una instancia de VM con una GPU conectada. Para obtener más información sobre estos avisos de eventos de mantenimiento, consulta Obtén avisos de migración en vivo.
Para obtener más información sobre el manejo del mantenimiento del host con GPU, consulta Cómo manejar el mantenimiento del host en la documentación de las GPU.
Cloud TPU. Cloud TPU no admite la migración en vivo.
VM interrumpibles. No puedes configurar una VM interrumpible para la migración en vivo. El comportamiento de mantenimiento de las instancias interrumpibles siempre se configura como
TERMINATEde forma predeterminada y no es posible cambiar esta opción. No puedes configurar la opción de reinicio automático para las instancias interrumpibles, pero puedes iniciar de forma manual las VMs interrumpibles desde la página Detalles de las instancias de VM después de que se interrumpan.Si necesitas cambiar la instancia a fin de que deje de ser interrumpible, desconecta el disco de arranque de la instancia interrumpible y conéctalo a una instancia nueva que no esté configurada para ser interrumpible. También puedes crear una instantánea del disco de arranque y usarla para crear una instancia nueva sin interrumpibilidad.
VMs Spot. Las VMs Spot no pueden migrar en vivo para convertirse en VM estándar mientras se ejecutan o están configuradas para reiniciarse de forma automática cuando hay un evento de alojamiento.
VMs con optimización de almacenamiento. Las VMs de Z3 no admiten la migración en vivo. El comportamiento de mantenimiento de las VMs Z3 se establece en
TERMINATE.
¿Cómo funciona el proceso de migración en vivo?
Cuando una VM está programada para migrar en vivo, Google Cloud proporciona una notificación. Durante la migración en vivo, Google Cloud garantiza un tiempo de interrupción mínimo, que suele ser mucho menos de 1 segundo. Si una VM no está configurada para migrar en vivo, Compute Engine la finaliza durante el mantenimiento del host. Las VM configuradas para finalizar durante un evento del host se detienen y (opcionalmente) se reinician.
Cuando Google Cloud migra una VM en ejecución de un host a otro, traslada el estado completo de la VM del origen al destino de forma transparente para el SO invitado y cualquier comunicación que tenga. Hay muchos componentes involucrados en hacer que esto funcione a la perfección, pero los pasos de alto nivel se muestran en la siguiente ilustración:
El proceso comienza con una notificación que dice que las VM se deben mover de su máquina anfitrión actual. La notificación puede comenzar con un cambio de archivo que indique que hay una versión nueva del BIOS disponible, una operación de hardware que programe el mantenimiento o una señal automática de una falla inminente del hardware.
El software de administración de clústeres de Google Cloud detecta de forma constante estos eventos y los programa en función de políticas que controlan los centros de datos, como las tasas de uso de capacidad y la cantidad de VMs que un cliente puede migrar a la vez.
Después de que se selecciona una VM para la migración, Google Cloud notifica al invitado que pronto se realizará una migración. Luego de un período de espera, se selecciona un host de destino y se le solicita que configure una nueva VM “de destino” vacía para recibir la VM “de origen” que se migra. La autenticación se usa para establecer una conexión entre el origen y el destino.
La migración de la VM consta de las siguientes tres etapas:
Disponibilidad limitada del origen. La VM aún se ejecuta en el origen, mientras que la mayor parte del estado se envía del origen al destino. Por ejemplo, Google Cloud copia toda la memoria del invitado en el destino, mientras rastrea las páginas que se cambiaron en el origen. El tiempo dedicado al período de disponibilidad limitada del origen depende del tamaño de la memoria del invitado y la velocidad a la que se cambian las páginas.
Sin disponibilidad. Un momento muy breve en el que la VM no se ejecuta en ningún lugar, se detiene y se envía todo el estado restante necesario para comenzar a ejecutarla en el destino. La VM entra en la etapa de sin disponibilidad cuando el estado enviado durante el período de disponibilidad limitada del origen alcanza un punto de rendimientos decrecientes. Se usa un algoritmo que equilibra la cantidad de bytes de memoria que se envían con la velocidad a la que la VM invitada realiza los cambios.
Durante los eventos sin disponibilidad, el reloj del sistema parece avanzar en incrementos de hasta 5 segundos. Si el evento sin disponibilidad excede los 5 segundos, Google Cloud detiene el reloj y lo vuelve a sincronizar mediante el uso de un daemon incluido como parte de los paquetes de invitado de la VM.
Disponibilidad limitada del destino. La VM se ejecuta en la VM de destino. La VM de origen está presente y podría proporcionar funcionalidad complementaria para la VM de destino. Por ejemplo, hasta que la estructura de red alcance la ubicación nueva de la VM de destino, la VM de origen proporciona servicios de desvío de paquetes desde y hacia la VM de destino.
Por último, la migración se completa y el sistema borra la VM de origen. Puedes ver que la migración tuvo lugar en tus registros de VM.
Proceso manual de migración en vivo
A medida que se ejecuta la carga de trabajo, es posible que quieras mover las VM a un nodo o grupo de nodos diferente. El usuario único te permite mover las VM a un nodo de usuario único específico o a un grupo de nodos. Si mueves una VM a un grupo de nodos, Compute Engine determina en qué nodo colocarla. Para obtener información sobre el usuario único, consulta Descripción general del usuario único.
Para mover VM de usuario único a un nodo o grupo de nodos diferente, puedes iniciar manualmente una migración en vivo. También puedes iniciar de forma manual una migración en vivo para mover una VM de multiusuario a un usuario único. Para obtener más información, consulta Migra VM en vivo de forma manual.
¿Qué sigue?
Establece una política de mantenimiento del host de VM a fin de configurar las instancias para la migración en vivo.
Consulta las sugerencias para diseñar un sistema sólido que pueda controlar las interrupciones del servicio.