Durante un evento de mantenimiento planificado para el hardware subyacente de una instancia de máquina virtual (VM) o una instancia 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 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 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 en 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 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 la falla se detecta 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 con más de 18 TiB de SSD de Titanium conectados). Compute Engine mueve las instancias de VM junto con sus datos de SSD local 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 equipos físicos Las instancias creadas con un tipo de máquina de hardware bare metal 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 antes de que se detenga una instancia de VM con una GPU conectada, según el tipo de GPU:
- En el caso de la mayoría de las GPUs, Compute Engine proporciona un aviso de 60 minutos.
- En el caso de las familias de GPU que se ejecutan en el director de clúster de AI Hypercomputer, Compute Engine proporciona un aviso de 10 minutos.
Para obtener más información sobre estos avisos de eventos de mantenimiento, consulta Consulta el servidor de metadatos para obtener avisos de eventos de mantenimiento.
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. Las Cloud TPU no admiten la migración en vivo.
- VMs con optimización de almacenamiento. Las VMs de Z3 con más de 18 TiB de SSD de Titanium conectadas no admiten la migración en vivo. El comportamiento de mantenimiento de estas VMs se establece en
TERMINATEyRESTART.Compute Engine conserva los datos en la SSD de Titanium durante el evento de mantenimiento, como se describe en Persistencia del disco después de la finalización de la instancia.
¿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 en vivo, Google Cloud se observa 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 indica 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 deGoogle Clouddetecta 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 la VM de origen y se envía todo el estado restante necesario para comenzar a ejecutar la VM en el destino. La VM entra en la etapa de sin disponibilidad cuando el estado enviado durante la etapa 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 y sincroniza el reloj con un daemon que se incluye 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 asistencia 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 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 en 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 las opciones de la política de mantenimiento del host de VM para configurar tus instancias para la migración en vivo.
Consulta las sugerencias para diseñar un sistema sólido que pueda controlar las interrupciones del servicio.