Algunos casos de soporte son rutinarios. Otros lo desvían por completo del camino de la documentación y lo llevan a áreas donde el único camino a seguir es profundo, es decir, dominar la experiencia en código abierto. Esta serie analiza cómo el soporte de Canonical responde a situaciones inesperadas: cuando los manuales estándar no son suficientes, los ingenieros de soporte ayudan a los clientes a encontrar soluciones sobre la marcha.
Este es uno de ellos. El entorno OpenStack de producción de un cliente pasó de estar completamente operativo de la noche a la mañana a no poder aprovisionar, escalar o administrar un solo recurso.
qué sucedió
OpenStack no es una sola pieza de software. Es una arquitectura de servicio coordinada que gestiona componentes centrales de la infraestructura, como informática, redes, identidad, almacenamiento, etc., todos los cuales dependen de una base de datos compartida que registra el estado actual de la nube: qué se está ejecutando, dónde se está ejecutando y cómo está configurado.
Durante las operaciones de rutina, se realiza una operación en el clúster de base de datos que admite este plano de control. En cuestión de segundos, las capas que permiten a los operadores administrar la nube, configurarla, migrarla y escalarla desaparecen.
Los casos de soporte se abren el mismo día.
La primera pregunta: copia de seguridad
La primera pregunta del equipo fue simple: ¿Cuándo se realizó la última copia de seguridad y alguna vez se probó como restauración? Las copias de seguridad disponibles son lo suficientemente antiguas como para que ya no reflejen el estado actual de la nube. Se movieron máquinas virtuales, se reasignaron recursos y se rotaron las credenciales desde la captura.
Restaurarlo directamente puede dar como resultado un plano de control que describe la nube que ya no existe. Esto elimina el camino más fácil y deja el camino más difícil: reconstruir el plano de control alrededor de las cargas de trabajo que se ejecutan de inmediato sin interrumpirlas.
Esto merece una pausa, ya que es una brecha común incluso en operaciones maduras. El plan de respaldo le indica que se está capturando material. No le dice que la restauración funcionará o que el estado restaurado seguirá siendo realista cuando lo necesite. Los dos deben verificarse juntos, y el ritmo de la verificación está relacionado con la velocidad de los cambios reales en el medio ambiente.
nada que romper
Antes de tocar nada, el ingeniero de soporte designado comprobó lo que aún estaba funcionando y descubrió que en realidad no había nada malo. No se perdieron cargas de trabajo. El negocio sigue funcionando. Lo que se pierde es la capacidad de gestionar la nube: sin nuevas configuraciones, sin migraciones, sin escalado.
Esta es una propiedad de la arquitectura OpenStack y vale la pena entenderla desde su propia perspectiva. El plano de control gestiona el estado de la nube; el plano de datos es responsable del trabajo real, la informática, las redes y el almacenamiento. Estas capas están desacopladas por diseño, específicamente para que la falla de la infraestructura de administración no reduzca las cargas de trabajo que dependen de ella. Es una de las ventajas arquitectónicas que hace que OpenStack sea viable en entornos de producción a gran escala, y en eso insistimos aquí.
Esta seguridad sólo le ayudará si sabe que existe y sabe cómo utilizarla para desarrollar una estrategia de recuperación. Reconocer esto a tiempo puede convertir esta crisis abierta en un problema de ingeniería con alcance y solución en la primera hora.
recuperación
Después de confirmar que las cargas de trabajo existentes estaban seguras, el equipo comenzó a reconstruir el plano de control. Debido a que la necesidad de reconstruir una base de datos desde cero es extremadamente rara, los archivos de recuperación estándar solo cubren estados corruptos o degradados. Por lo tanto, los ingenieros desarrollaron y validaron un nuevo procedimiento para este escenario específico: reconstruir el clúster del repositorio, restaurar los datos disponibles en un orden controlado y luego volver a conectar cada servicio OpenStack al nuevo repositorio, una dependencia a la vez.
Esa última parte es la mayor parte del trabajo. La relación que conecta cada servicio con la base de datos debe restablecerse individualmente, y las brechas entre el estado de la copia de seguridad y el estado real en la nube deben conciliarse manualmente, incluidas situaciones en las que una máquina virtual funciona bien pero la base de datos está trabajando con información obsoleta, informándola como detenida o con error.
Los ingenieros de Canonical y los equipos de clientes trabajaron estrecha y continuamente durante varios días. Al final, la nube está en pleno funcionamiento sin pérdida de carga de trabajo.
¿Qué ilustra realmente este caso?
Hay dos puntos de los que vale la pena aprender.
La validación de las copias de seguridad debe ser tan rigurosa como el plan de copias de seguridad. Esta no es una brecha hipotética. laboratorio de cucarachas Estado de resiliencia 2025 encuesta El estudio encontró que el 62% de las organizaciones no realiza ejercicios regulares de recuperación de copias de seguridad y el 71% no realiza ninguna prueba de conmutación por error, aunque casi todas realizan algún tipo de prueba de resiliencia en papel. respectivamente, Acronis Telemetría Q1 2026 En su plataforma de recuperación de desastres, se descubrió que el 85% de los servidores de recuperación tenían el monitoreo de RPO completamente desactivado, lo que significa que no había una verificación automática para ver si las copias de seguridad eran lo suficientemente recientes y útiles, y solo el 18% de las reglas de copia de seguridad estaban configuradas para pruebas mensuales.
El patrón es consistente: tener una estrategia de respaldo es común, pero demostrar que la estrategia realmente funciona en condiciones del mundo real no lo es. Esta brecha a menudo es invisible hasta el gran día, por lo que un proceso de recuperación de extremo a extremo probado, programado y pertenece a la lista de verificación de resiliencia junto a los objetivos de RTO y RPO y no se considera un hecho una vez que un trabajo de respaldo se muestra en verde.
En tales sistemas interconectados, el conocimiento arquitectónico hace posible la recuperación. Saber que el plano de control y el plano de datos de OpenStack están desacoplados no es un asunto trivial aquí. Es este hecho el que determina toda la estrategia de recuperación, ya que les dice a los ingenieros en la primera hora que el negocio no se ha perdido. Este conocimiento entra en juego sólo una vez, cuando hay mucho en juego, con un soporte profesional profundo proporcionado según demanda.
Las infraestructuras grandes y distribuidas acumulan inherentemente complejidad operativa e interdependencias en todos los proveedores y en cada capa de la pila. Cuando surge un problema, no es la complejidad del entorno lo que determina el resultado. La pregunta es si el equipo de respuesta tiene suficiente profundidad para actuar con rapidez, diagnosticar correctamente y establecer soluciones bajo presión cuando se agote el camino documentado.
Los procedimientos desarrollados durante este incidente han sido documentados para su uso en casos futuros. Pero el caso en sí es un buen recordatorio de lo que realmente se compra con una suscripción de soporte: no sólo respuestas a problemas conocidos, sino acceso a experiencia para resolver problemas sobre los que nadie ha escrito todavía.
Si su organización implementa OpenStack en producción, hable con nosotros sobre el soporte de Ubuntu Pro.
