Durante un evento de mantenimiento planificado para el hardware subyacente de una instancia de máquina virtual (VM) o instancia de metal desnudo, el servidor host no está disponible. Para mantener una instancia en ejecución durante un evento de host, Compute Engine realiza una migración en vivo de la instancia a otro servidor host en la misma zona. Para obtener más información sobre los eventos del anfitrión, consulte Acerca de los eventos del anfitrión .
La migración en vivo permite Google Cloud realice el mantenimiento sin interrumpir una carga de trabajo, reiniciar una instancia o modificar cualquiera de las propiedades de la instancia, como direcciones IP, metadatos, datos de almacenamiento en bloque, estado de la aplicación o configuración de red.
La migración en vivo mantiene las instancias en ejecución durante las siguientes situaciones:
Mantenimiento de infraestructura. El mantenimiento de la infraestructura incluye el hardware del host, las redes y las redes eléctricas en los centros de datos, y el sistema operativo (SO) y el BIOS del 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 la imagen y los paquetes del sistema operativo del host.
Fallos de hardware. Esto incluye fallas en la memoria, CPU, tarjetas de interfaz de red y discos. Si la falla se detecta antes de que se produzca una falla completa del servidor, Compute Engine realiza una migración preventiva en vivo de la instancia a un nuevo servidor host. Si el hardware falla por completo o impide la migración en vivo, la instancia finaliza y se reinicia automáticamente.
Compute Engine solo realiza una migración en vivo de las máquinas virtuales 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, consulte Establecer la política de mantenimiento del host de VM .
Proceso de migración en vivo y discos SSD locales
Compute Engine puede migrar en vivo instancias con discos SSD locales conectados (excluidas las instancias Z3). Compute Engine mueve las instancias de VM junto con sus datos SSD locales a una nueva máquina antes de cualquier mantenimiento planificado.
Limitaciones
La migración en vivo no es compatible con los siguientes tipos de VM:
- Instancias de metal desnudo . Las instancias bare metal C3 y X4 no admiten la migración en vivo. El comportamiento de mantenimiento para estas instancias se establece en
TERMINATE
yRESTART
, respectivamente. - La mayoría de las instancias de VM confidenciales . La migración en vivo para instancias de VM confidenciales solo se admite en tipos de máquinas N2D con plataformas de CPU AMD EPYC Milan que ejecutan AMD SEV. Todas las demás instancias de VM confidenciales no admiten la migración en vivo y deben configurarse para detenerse y, opcionalmente, reiniciarse durante un evento de mantenimiento del host. Consulte Migración en vivo para obtener más detalles.
Máquinas virtuales con GPU conectadas . Las instancias de VM con GPU conectadas deben configurarse para que se detengan y, opcionalmente, se reinicien. Compute Engine ofrece un aviso de 60 minutos antes de que se detenga una instancia de VM con una GPU conectada. Para obtener más información sobre estos avisos de eventos de mantenimiento, lea Recibir avisos de migración en vivo .
Para obtener más información sobre cómo manejar el mantenimiento del host con GPU, lea Manejo del mantenimiento del host en la documentación de las GPU.
- TPU en la nube . Las TPU en la nube no admiten la migración en vivo.
- Máquinas virtuales optimizadas para almacenamiento . Las máquinas virtuales Z3 no admiten la migración en vivo. El comportamiento de mantenimiento para las máquinas virtuales Z3 está configurado en
TERMINATE
.
¿Cómo funciona el proceso de migración en vivo?
Cuando una VM está programada para migrar en vivo, Compute Engine proporciona una notificación para que puedas preparar tus cargas de trabajo y aplicaciones para esta interrupción de la migración en vivo. Durante la migración viva, Google Cloud garantiza un tiempo mínimo de interrupción, que normalmente es mucho menor que 1 segundo. Si una VM no está configurada para migrar en vivo, Compute Engine finaliza la VM durante el mantenimiento del host. Las máquinas virtuales que están configuradas para finalizar durante un evento de host se detienen y (opcionalmente) se reinician .
Cuando Google Cloud migra una VM en ejecución de un host a otro, mueve el estado completo de la VM desde el origen al destino de una manera que es transparente para el sistema operativo invitado y cualquier cosa que se comunique con él.Hay muchos componentes involucrados para que esto funcione sin problemas, pero los pasos de alto nivel se muestran en la siguiente ilustración:
El proceso comienza con una notificación de que es necesario mover una máquina virtual desde su máquina host actual. La notificación puede comenzar con un cambio de archivo que indica que hay una nueva versión del BIOS disponible, una operación de hardware que programa el mantenimiento o una señal automática de una falla de hardware inminente.
Google CloudEl software de gestión de clústeres de Google vigila 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 la cantidad de máquinas virtuales que un solo cliente puede migrar a la vez.
Después de seleccionar una máquina virtual para la migración, Google Cloud proporciona una notificación al huésped de que se producirá una migración próximamente. Después de un período de espera, se selecciona un host de destino y se le pide al host que configure una nueva máquina virtual "de destino" vacía para recibir la máquina virtual "de origen" migratoria. La autenticación se utiliza para establecer una conexión entre el origen y el destino.
Hay tres etapas involucradas en la migración de la VM:
Apagón de fuente. La VM todavía se está ejecutando en el origen, mientras que la mayor parte del estado se envía desde el origen al destino. Por ejemplo,Google Cloud copia toda la memoria del invitado en el destino, mientras realiza un seguimiento de las páginas que se han modificado en el origen. El tiempo transcurrido en la caída de la fuente es una función del tamaño de la memoria del huésped y de la velocidad a la que se cambian las páginas.
Apagón. En un momento muy breve en el que la VM no se está ejecutando en ningún lugar, la VM de origen se pausa y se envía todo el estado restante necesario para comenzar a ejecutar la VM en el destino. La máquina virtual entra en la etapa de apagón cuando el envío de cambios de estado durante la etapa de apagón de origen alcanza un punto de rendimiento decreciente. Se utiliza un algoritmo que equilibra la cantidad de bytes de memoria que se envían con la velocidad a la que la máquina virtual invitada realiza cambios.
Durante eventos de apagón, el reloj del sistema parece adelantarse hasta 5 segundos. Si un evento de apagón excede los 5 segundos, Google Cloud detiene y sincroniza el reloj mediante un demonio que se incluye como parte de los paquetes de invitados de VM.
Apagón objetivo. La VM se ejecuta en la VM de destino. La máquina virtual de origen está presente y puede proporcionar soporte para la máquina virtual de destino. Por ejemplo, hasta que la estructura de la red se haya puesto al día con la nueva ubicación de la máquina virtual de destino, la máquina virtual de origen proporciona servicios de reenvío de paquetes hacia y desde la máquina virtual de destino.
Finalmente, la migración se completa y el sistema elimina la VM de origen. Puede ver que la migración se realizó en los registros de Cloud Logging de su VM.
Migración en vivo de máquinas virtuales de único inquilino
A medida que se ejecuta su carga de trabajo, es posible que desee mover las máquinas virtuales a un nodo o grupo de nodos de único inquilino diferente. Si mueves una VM a un grupo de nodos, Compute Engine determina en qué nodo colocarla. Para obtener información sobre el arrendamiento único, consulte Descripción general del arrendamiento único .
Para mover máquinas virtuales de único inquilino a un nodo o grupo de nodos diferente, puede iniciar manualmente una migración en vivo. También puede iniciar manualmente una migración en vivo para mover una máquina virtual en un host multiinquilino a un nodo de único inquilino. Para obtener más información, consulte Migración manual de máquinas virtuales en vivo .
¿Qué sigue?
Configure las opciones de política de mantenimiento del host de VM para configurar sus instancias para la migración en vivo.
Lea consejos para diseñar un sistema sólido que pueda manejar interrupciones del servicio.