Durante un evento de mantenimiento planificado para el hardware subyacente de una instancia de máquina virtual (VM) o de metal desnudo, el servidor host no está disponible. Para mantener una instancia en ejecución durante un evento del 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 host, consulta Acerca de los eventos del host.
La migración en vivo permite que Google Cloud realice mantenimiento sin interrumpir una carga de trabajo, reiniciar una instancia ni modificar ninguna de sus propiedades, 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 la infraestructura. El mantenimiento de la infraestructura incluye hardware del host, red y cuadrícula de energía en los centros de datos, y sistema operativo (SO) y 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 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 se detecta la falla antes de que se produzca una falla completa 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 vivo, la instancia finaliza y se reinicia automáticamente.
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 discos SSD locales
Compute Engine puede migrar en vivo instancias con discos SSD locales conectados (excepto las instancias Z3). Compute Engine traslada las instancias de VM junto con sus datos de 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:
- Instancias de Bare Metal. Las instancias de Bare Metal C3 y X4 no admiten la migración en vivo. El comportamiento de mantenimiento de estas instancias se establece en
TERMINATEyRESTART, respectivamente. - La mayoría de las instancias de Confidential VMs La migración en vivo para instancias de Confidential VM solo es compatible con los tipos de máquinas N2D con plataformas de CPU AMD EPYC Milan que ejecutan SEV de AMD. Todas las demás instancias de Confidential VMs no admiten la migración en vivo y deben configurarse para que se detengan y, de forma opcional, se reinicien durante un evento de mantenimiento del host. 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 Engine ofrece un aviso de 60 minutos 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 GPUs, consulta Cómo manejar el mantenimiento del host en la documentación de las GPUs.
- Cloud TPU. Las Cloud TPU no admiten la migración en vivo.
- 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 se programa una migración en vivo de una VM, 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 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 VMs 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 se debe mover una VM 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 solo 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 los cambios de estado enviados durante la etapa de disponibilidad limitada de la fuente alcanzan 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 compatibilidad con 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 los registros de Cloud Logging de tu VM.
Migración en vivo de VMs de usuario único
A medida que se ejecuta la carga de trabajo, es posible que quieras mover las VMs a un nodo o grupo de nodos de usuario único diferente. 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 un host multiusuario a un nodo de usuario único. Para obtener más información, consulta Migra VM en vivo de forma manual.
¿Qué sigue?
Establece opciones de la política de mantenimiento del host de VM para 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.