OpenStack es una plataforma de computación en la nube de código abierto cuya arquitectura incluye servicios de procesamiento, almacenamiento y redes, proporcionando poderosas capacidades de virtualización y funciones de gestión automatizada. Para garantizar la alta disponibilidad de la plataforma OpenStack, es necesario adoptar ciertas soluciones arquitectónicas y medidas técnicas. Este artículo presentará algunas soluciones comunes de arquitectura de alta disponibilidad para OpenStack.
Alta disponibilidad en OpenStack
Para comprender cómo lograr la alta disponibilidad, es fundamental identificar qué servicios son propensos a presentar interrupciones. Primero, obtengamos una comprensión básica de la estructura de OpenStack.
OpenStack consta de cinco componentes principales: Compute (Nova), Gestión de Identidades (Keystone), Gestión de Imágenes (Glance), Gestión del Front-end (Dashboard) y Almacenamiento de Objetos (Swift).
Nova es el componente principal encargado del cálculo y el control. Incluye servicios como nova-compute, nova-scheduler, nova-volume, nova-network y nova-api. Al igual que la mayoría de los demás sistemas distribuidos, OpenStack se divide en dos tipos de nodos: nodos de control y nodos de cálculo. Los nodos de control proporcionan todos los servicios excepto nova-compute. Estos componentes y servicios pueden instalarse de forma independiente, y se pueden elegir combinaciones según sea necesario.
Nova-compute se ejecuta en cada nodo de cómputo. Por ahora, supongamos que es de confianza; de lo contrario, se puede utilizar una máquina de respaldo para conmutar por fallo (aunque configurar una copia de seguridad para cada nodo de cómputo podría ser demasiado costoso en comparación con los beneficios).
Alta disponibilidad del nodo de control
Asegurar la alta disponibilidad del nodo de control es el desafío principal, y diferentes componentes tienen sus propios requisitos y soluciones específicos de disponibilidad.
(1) ¿Qué ocurre si falla el nodo de control, teniendo en cuenta que hay un solo nodo de control que gestiona y controla todo el sistema?
Este es el problema común del único punto de fallo (SPoF). No se puede lograr alta disponibilidad con una sola máquina. Con mayor frecuencia, se diseña una solución para garantizar una rápida asunción de la máquina fallida cuando surge un problema, aunque esto implica un costo más elevado.
Para abordar el problema de punto único, la solución típica es utilizar dispositivos redundantes o en espera activa. Dado que los fallos de hardware o los errores humanos siempre pueden provocar fallos en uno o varios nodos, y el mantenimiento o las actualizaciones a veces requieren detener temporalmente ciertos nodos, un sistema confiable debe ser capaz de soportar la interrupción de uno o varios nodos.
Los modos comunes de implementación incluyen: modo de espera activo-pasivo, modo activo-activo y modo clúster
(2) ¿Cómo construir nodos de control redundantes? ¿O qué otros métodos pueden lograr un control altamente confiable?
Muchos pueden considerar implementar un modo activo-pasivo, utilizando un mecanismo de heartbeat o métodos similares para respaldo, y lograr Alta Disponibilidad mediante failover. OpenStack no admite inherentemente múltiples nodos de control, por lo que Pacemaker requiere que varios servicios implementen por sí mismos sus propios mecanismos de respaldo, monitoreo y conmutación.
Un análisis más detallado de los servicios proporcionados por el nodo de control muestra que principalmente incluyen nova-api, nova-network, nova-scheduler, nova-volume, así como Glance, Keystone y la base de datos MySQL. Estos servicios se proporcionan de forma separada. Nova-api, nova-network y Glance pueden ejecutarse en cada nodo de cómputo, RabbitMQ puede operar en modo primario-de respaldo, y MySQL puede utilizar un clúster redundante de alta disponibilidad.
Las siguientes secciones detallan estos componentes.
Soluciones de alta disponibilidad para componentes clave
1) Alta disponibilidad de nova-api y nova-scheduler
Cada nodo de cómputo puede ejecutar su propia API nova-api y el planificador nova-scheduler, garantizando el equilibrio de carga para un funcionamiento adecuado. De esta manera, cuando el nodo de control falla, la API nova-api y los servicios relacionados en los nodos de cómputo continúan funcionando normalmente.
2) Alta disponibilidad de nova-volume
Actualmente, no existe una solución HA perfecta para nova-volume, por lo que se requiere más trabajo. Sin embargo, dado que nova-volume funciona con iSCSI, es posible lograr alta disponibilidad integrándolo con DRBD o utilizando una solución de hardware de alta disponibilidad basada en iSCSI.
3) Alta disponibilidad de servicios de red (nova-network)
OpenStack ya proporciona múltiples soluciones de red de alta disponibilidad. Un enfoque comúnmente utilizado es activar el modo de alta disponibilidad mediante la opción "Multi-host". Otras soluciones comunes incluyen Failover, Multi-nic, Gateway de Hardware y Quantum.
4) Alta disponibilidad de Glance y Keystone
Las imágenes de OpenStack pueden almacenarse utilizando Swift, y Glance puede ejecutarse en múltiples hosts. Pacemaker es una potente solución de alta disponibilidad para administrar clústeres multinodo, implementando conmutación por error y redundancia de servicios, y puede utilizarse junto con Corosync y Heartbeat. Pacemaker admite flexiblemente múltiples modos como activo-pasivo, N+1 y N-N. Al instalar el agente OCF en cada nodo, puede determinar si otro nodo está ejecutando correctamente los servicios de Glance y Keystone, ayudando a Pacemaker a iniciar, detener y monitorear estos servicios.
5) Alta disponibilidad de Swift Object Storage
Generalmente, el sistema de almacenamiento de objetos distribuido de OpenStack, Swift, no requiere configuraciones adicionales de alta disponibilidad (HA). Esto se debe a que Swift está diseñado con una arquitectura distribuida (sin nodo maestro), mecanismos de tolerancia a fallos, redundancia, recuperación de datos, escalabilidad y alta disponibilidad.
6) Alta disponibilidad del servicio de cola de mensajes (RabbitMQ)
Si RabbitMQ falla, los mensajes pueden perderse. Se pueden utilizar múltiples mecanismos de alta disponibilidad:
El método de confirmación del editor notifica cuando los datos se escriben en el disco en caso de fallo.
Se puede utilizar el mecanismo de clúster de múltiples nodos, pero los fallos en los nodos aún pueden provocar fallos en la cola.
El modo activo-pasivo garantiza la conmutación ante fallos, pero el inicio del nodo de reserva puede implicar retrasos o incluso fallos.
Para recuperación ante desastres y disponibilidad, RabbitMQ proporciona colas persistentes que almacenan mensajes no procesados en disco si el servicio de colas se cae. Para prevenir la pérdida de mensajes debido a retrasos entre el envío y la escritura de mensajes, RabbitMQ introduce el mecanismo de Confirmación de Publicador para asegurar que los mensajes sean realmente escritos en disco.
Para el soporte de clúster, RabbitMQ ofrece modos Activo/Pasivo y Activo/Activo. Por ejemplo, en el modo Activo/Pasivo, cuando un nodo falla, el nodo pasivo se activa inmediatamente y reemplaza rápidamente al nodo activo fallido para continuar gestionando la entrega de mensajes.
Construyendo un OpenStack de alta disponibilidad
En general, la alta disponibilidad se logra estableciendo redundancia y copias de seguridad. Las estrategias comunes incluyen:
Modo clúster. Respaldo mutuo entre múltiples máquinas, en donde cada instancia tiene varias copias de seguridad sin necesidad de un nodo central. Ejemplos incluyen el sistema de almacenamiento distribuido de objetos Swift y el modo multi-host de nova-network.
Modo autónomo. En algunos casos, se puede abordar SPoF permitiendo que cada nodo opere de forma independiente, eliminando las relaciones maestro-esclavo para reducir el impacto de un nodo de control fallido. Por ejemplo, nova-api es responsable únicamente de su propio nodo.
Modo activo-pasivo. Este modelo común implica un nodo pasivo que permanece en estado de espera y respaldo, conmutando cuando ocurre una falla. Ejemplos incluyen clústeres de alta disponibilidad de MySQL, y servicios como Glance y Keystone, que logran redundancia mediante Pacemaker y Heartbeat.
Modo activo-activo. En este modo, los nodos se respaldan y apoyan entre sí. Por ejemplo, RabbitMQ utiliza un clúster de alta disponibilidad en modo activo-activo, donde los nodos del clúster pueden replicar colas. Desde una perspectiva arquitectónica, este enfoque elimina preocupaciones sobre fallos al iniciar los nodos pasivos o la existencia de retrasos excesivos.
En resumen, la optimización y las mejoras de OpenStack están en constante evolución, y su implementación y aplicaciones se están explorando y desarrollando aún más. El ajuste práctico es esencial: buenos diseños e ideas necesitan pruebas reales para ser validados.
Protección mejorada de OpenStack
Aunque OpenStack reduce el riesgo de fallo único en el sistema mediante arquitectura redundante y alta disponibilidad, la protección de datos sigue siendo crítica. Para garantizar la continuidad del negocio, se debe adoptar una solución profesional de copia de seguridad para prevenir la pérdida de datos y el impacto de fallos catastróficos.
Vinchin Backup & Recovery es una solución de copia de seguridad sólida para OpenStack que ofrece copias de seguridad eficientes y sin agentes, con características como deduplicación de datos, compresión, copias de seguridad incrementales, recuperación a nivel de archivos y archivo en la nube, entre otras. Garantiza una recuperación rápida, integración perfecta con OpenStack y una fuerte seguridad de los datos, lo que la convierte en la opción ideal para administrar y proteger entornos en la nube.
Además, el cifrado de datos y la protección contra ransomware le ofrecen una doble protección para salvaguardar las copias de seguridad de sus máquinas virtuales en OpenStack. También puede simplemente migrar datos desde un host OpenStack a otra plataforma virtual (como VMware, Hyper-V, Proxmox, XenServer, oVirt, AWS EC2...) y viceversa.
Para realizar una copia de seguridad de una máquina virtual de OpenStack con Vinchin Backup & Recovery, solo se requieren los siguientes 4 pasos:
1. Seleccione el objeto de copia de seguridad.
2. Seleccione destino de copia de seguridad.
3. Configure estrategias de copia de seguridad.
4. Revisar y enviar el trabajo.
Vinchin Backup & Recovery es confiado por miles de empresas. ¡Comience su prueba gratuita de 60 días con todas las funciones hoy mismo!
Preguntas frecuentes sobre alta disponibilidad en OpenStack
1. ¿Qué es una zona de disponibilidad en OpenStack?
En OpenStack, una Zona de Disponibilidad (AZ) es una partición lógica dentro de un entorno en la nube que ayuda a distribuir las cargas de trabajo para mejorar la tolerancia a fallos y la gestión de recursos. Cada AZ es un dominio de fallo aislado, lo que significa que las instancias ubicadas en diferentes AZ tienen menos probabilidades de verse afectadas por los mismos fallos de hardware o red. Las AZ suelen utilizarse para agrupar nodos de computación, mientras que los servicios de almacenamiento y redes también pueden tener sus propias zonas para ofrecer mayor resistencia y redundancia. Los usuarios pueden especificar una AZ al iniciar instancias para optimizar el rendimiento y la confiabilidad.
2. ¿Es OpenStack un SAAS o un PaaS?
OpenStack es principalmente una plataforma de IaaS. Proporciona recursos virtualizados de computación, almacenamiento y redes, permitiendo a los usuarios implementar y gestionar infraestructura en la nube. Aunque OpenStack puede admitir soluciones PaaS al ejecutar servicios como Kubernetes o Cloud Foundry encima, su función principal es ofrecer IaaS, no SaaS ni PaaS.
Conclusión
Asegurar una alta disponibilidad en OpenStack requiere una combinación de estrategias arquitectónicas y soluciones técnicas para eliminar puntos únicos de fallo y mejorar la resiliencia del sistema. Al implementar modos activo-pasivo y activo-activo, aprovechar técnicas de agrupamiento y optimizar componentes clave como Nova, Glance, Keystone y RabbitMQ, OpenStack puede lograr una infraestructura en la nube tolerante a fallos y altamente confiable. Además, soluciones de almacenamiento distribuido como Swift proporcionan inherentemente redundancia y resiliencia.
