Cuándo evacuar instancias OpenStack tras un fallo de Compute

La evacuación es una recuperación posterior a una falla

En Nova, evacuar recrea una instancia en otro nodo cuando el host de cómputo donde estaba alojada falló. Es una acción administrativa de recuperación. No es una migración planificada ni sirve para retirar ordenadamente un nodo que sigue ejecutando instancias.

Nova no puede probar por sí solo que el host original dejó de ejecutar la VM. Antes de evacuar, el operador debe aislar ese servidor y los caminos que podrían permitirle volver a acceder a redes o almacenamiento compartido. Este aislamiento, llamado fencing, evita que la instancia original reaparezca mientras la nueva escribe en los mismos recursos.

Antes de tocar Nova

1. Delimita la falla. Anota el host afectado, las instancias implicadas, cuándo se perdió el servicio y qué señales independientes confirman el incidente. Distingue un fallo del proceso nova-computede una caída del servidor físico, la red de gestión o el backend de almacenamiento.
2. Aísla el host original. Usa el mecanismo aprobado para impedir que el hipervisor ejecute de nuevo las instancias o acceda a las redes y discos compartidos. Comprueba el resultado desde los planos de energía, hipervisor, red y almacenamiento que existan en tu arquitectura. Un estado downen Nova, un ping fallido o una alarma no sustituyen este paso.
3. Confirma el estado del servicio. Revisa los servicios de Nova y el host de las instancias. Si el servicio todavía figura activo después del fencing, aplica el procedimiento de tu operación para marcarlo abajo; esa acción cambia el estado que ve Nova, no apaga ni aísla el servidor físico.
4. Revisa qué se conserva. Identifica discos efímeros locales, raíz en volumen, volúmenes de datos y sistemas de archivos compartidos. Aclara con el propietario de la carga qué datos pueden perderse antes de iniciar.
5. Valida el destino. Confirma capacidad para RAM, CPU, disco, cuotas y Placement; acceso al backend requerido; conectividad de Neutron; e imagen original disponible en Glance cuando la raíz sea efímera. Una zona de disponibilidad puede restringir los destinos elegibles.

Consulta el estado con comandos de solo lectura

Sustituye los marcadores por los nombres e identificadores de tu nube. Si la versión instalada admite estas opciones, revisa el servicio y la ubicación reportada antes de decidir:

openstack compute service list --service nova-compute --host <HOST_FALLIDO> --long
openstack server show <ID_DE_INSTANCIA>
openstack server volume list <ID_DE_INSTANCIA>
openstack volume show <ID_DEL_VOLUMEN>

Estos comandos consultan el registro de control y las asociaciones conocidas por los servicios; no demuestran que el hipervisor haya dejado de ejecutar la VM. Para listar instancias de otros proyectos hacen falta permisos administrativos y las opciones compatibles con la versión de OpenStackClient de tu entorno.

Si el procedimiento operativo determina que el servicio debe marcarse como abajo después de confirmar el fencing, la forma documentada de OpenStackClient es:

openstack compute service set --down <HOST_FALLIDO> nova-compute

Es un cambio administrativo. No lo uses para simular un fallo o como reemplazo del fencing. Confirma antes la sintaxis, los permisos y la microversión de la nube concreta.

Qué ocurre con los discos

“El volumen aparece adjunto” no prueba que la base de datos o el sistema de archivos se recuperó correctamente. Verifica primero los datos y la aplicación con sus responsables antes de reanudar escrituras o evacuar más instancias.

Evacúa una instancia a la vez

En versiones actuales de OpenStackClient, el comando recrea una instancia después de la falla y requiere permisos de administrador. Confirma que el servicio está abajo y que la VM original no sigue ejecutándose. Usa la microversión negociada por tu nube; --host indica un destino preferido que el scheduler valida desde la microversión 2.29. Antes de 2.29, especificar un host podía eludir esa validación; deja que el scheduler elija si no puedes confirmar el comportamiento de tu versión.

openstack server evacuate --wait <ID_DE_INSTANCIA>
# Opcional, si la microversión lo admite:
openstack server evacuate --wait --host <HOST_DESTINO> <ID_DE_INSTANCIA>

Prueba primero una instancia con prioridad y dependencias conocidas, y coordina el momento con su responsable. No ejecutes un lote hasta verificar el resultado, el destino, los volúmenes y la aplicación. La disponibilidad de una opción en OpenStackClient no garantiza que la política, los servicios o la versión de tu nube la permitan.

Comprueba la recuperación antes de cerrar el incidente

1. Confirma que Nova ubica la instancia en el host destino y que el host original sigue aislado. Desde la microversión 2.95, espera que la VM quede detenida.
2. Antes de iniciar, revisa los volúmenes, las interfaces, los puertos, los grupos de seguridad y las direcciones según el diseño del proyecto.
3. Si quedó detenida, inicia solo después de confirmar el fencing, el almacenamiento y la autorización operativa: openstack server start <ID_DE_INSTANCIA>.
4. Cuando arranque, revisa consola, sistema operativo, sistemas de archivos, servicios y logs de inicio.
5. Valida integridad de datos y una operación representativa de la aplicación con su responsable.
6. Registra pérdida de datos local, tiempo de recuperación, tareas pendientes y decisiones para las instancias restantes.

Si una operación queda en estado de tarea, falla el scheduler o aparecen errores de red o volumen, no repitas la evacuación a ciegas ni edites directamente las bases de Nova o Cinder. Revisa el estado de Neutron, Cinder, Glance, Placement y del backend implicado; coordina la limpieza con el operador de la nube.

Zonas no equivalen a dominios de alta disponibilidad

Una zona de disponibilidad es una agrupación lógica definida por cada operador. Sus nombres no prueban que los hosts estén separados por rack, energía, red o centro de datos. Nova advierte que una zona no ofrece por sí misma un beneficio intrínseco de alta disponibilidad. Revisa sus miembros, agregados, políticas de Placement y restricciones de la instancia; en determinadas configuraciones, la zona fijada puede limitar la evacuación.

Si el nodo está vivo: planifica la migración

Para mantenimiento previsto, primero impide nuevas ubicaciones según la política del cloud y migra ordenadamente las cargas con la opción adecuada: migración en vivo o en frío, según almacenamiento, hipervisor, versión y ventana acordada. Evacuación corresponde al escenario de un host que falló y quedó aislado. No uses ese flujo para mantenimiento mientras las instancias siguen activas.

Registra alcance y versión

La documentación publicada en latest cambia con el desarrollo de OpenStack. Antes de seguir comandos, anota la release del cloud, versión de OpenStackClient, microversión de Compute, permisos requeridos, backend de almacenamiento y procedimiento operativo local. Si una nube está varios ciclos detrás, usa la guía que corresponde a esa instalación; no copies una opción de una versión distinta sin validarla en un entorno seguro.

Este artículo explica conceptos y controles previos. No describe una intervención realizada por Elaine System ni acredita experiencia de recuperación en una nube productiva. El procedimiento debe adaptarse con el operador y el responsable de los datos de cada entorno.