Descripción general de la arquitectura del software de alta disponibilidad de Junos Space

Arquitectura del software Junos Space

La figura 1 proporciona una vista de alto nivel de la arquitectura del software Junos Space. Los clientes de GUI y NBI pueden acceder a los servicios de Junos Space mediante una única dirección IP virtual para el clúster.

Figura 1: Arquitectura del software Junos Space

Las solicitudes de los clientes tienen un equilibrio de carga entre varios nodos del clúster a través del balanceador de carga HTTP de Apache, que se implementa en una configuración de espera activa-activa en dos nodos del clúster. El equilibrador de carga en el nodo que posee la dirección IP virtual (VIP) actúa como la instancia activa. Si el nodo que actualmente posee la dirección VIP deja de funcionar, el otro nodo del clúster de Linux Virtual Server (LVS) detectará este error y se hará cargo automáticamente de la dirección VIP. Las solicitudes HTTP tienen un equilibrio de carga en todos los servidores JBoss activos del clúster mediante un algoritmo round-robin.

Los servidores JBoss activos dentro del clúster proporcionan el marco de aplicaciones para las aplicaciones de Junos Space, incluidos los siguientes servicios:

• Hospedar las aplicaciones y la lógica empresarial asociada

• Equilibrio de carga a nivel de aplicación dentro del clúster

• Monitoreo de aplicaciones y recuperación automática

• Supervisión y recuperación automática de nodos de clúster

• Servicios de base de datos con acceso directo a MySQL DB a través de JDBC

• Lógica de mediación de dispositivos de hospedaje

Arquitectura de equilibrio de carga

Un clúster de Junos Space se presenta con dos tipos de cargas:

• Solicitudes entrantes de clientes GUI y NBI

• Comunicación con dispositivos administrados

Junos Space está diseñado para equilibrar la carga de las solicitudes entrantes en todos los nodos activos del clúster. Las solicitudes de los clientes GUI y NBI llegan como solicitudes HTTP atendidas por la instancia activa del equilibrador de carga HTTP Apache. El equilibrador de carga distribuye las solicitudes a todos los servidores JBoss activos del clúster mediante un algoritmo round-robin. Las sesiones adhesivas se utilizan para garantizar que todas las solicitudes HTTP asociadas con una sesión GUI específica sean servidas por el mismo servidor JBoss durante la duración de esa sesión. Con el fin de equilibrar la carga a nivel de aplicación, la lógica empresarial de JBoss procesa solicitudes complejas como un conjunto de subtrabajos, que se distribuyen en varios nodos del clúster. Por ejemplo, una sola solicitud a un clúster de espacio de cuatro nodos para resincronizar 100 dispositivos se divide en cuatro subtrabajos que se ejecutan en cuatro nodos diferentes, y cada nodo resincroniza 25 dispositivos. Para obtener una descripción detallada del equilibrio de carga, consulte el tema Descripción de los clústeres lógicos dentro de un clúster de Junos Space.

Para realizar el equilibrio de carga a nivel de dispositivo, Junos Space emplea lógica en la capa de mediación de dispositivos (DML) para que las conexiones de dispositivos se distribuyan por igual entre todos los nodos activos del clúster. El equilibrio de carga a nivel de dispositivo se realiza durante la detección de dispositivos comparando el número de conexiones de dispositivos servidas por nodos individuales y seleccionando el nodo menos cargado. Si algún nodo deja de funcionar, todas las conexiones de dispositivos asociadas se distribuyen a los nodos activos restantes del clúster, evitando así que una interrupción del nodo afecte a la conectividad del dispositivo. Para obtener una descripción detallada de la administración de conectividad de dispositivos, consulte el tema Descripción de la administración de alta disponibilidad de conexiones DMI.

Arquitectura de base de datos

MySQL Enterprise Edition se utiliza para proporcionar servicios de base de datos para administrar datos persistentes tanto para la plataforma como para las aplicaciones. Los servidores de base de datos MySQL se ejecutan en dos nodos del clúster en configuración de espera activa. Las transacciones de la base de datos se replican entre los dos servidores MySQL casi en tiempo real. Para obtener información sobre el clúster de MySQL que se forma dentro de cada clúster de Junos Space, consulte Descripción de los clústeres lógicos dentro de un clúster de Junos Space.

La plataforma Junos Space también incorpora monitoreo de red para administración de fallas y rendimiento, que utiliza el servicio de base de datos relacional PostgreSQL para almacenar datos relacionados con fallas y rendimiento. El servidor PostgreSQL se ejecuta en dos nodos del clúster Space en configuración activa-activa con replicación en tiempo real para garantizar que los datos de error y rendimiento sigan estando disponibles incluso si uno de estos nodos falla. Para obtener más información, consulte Alta disponibilidad para la supervisión de red.

Comunicación entre nodos en un clúster de Junos Space

Para facilitar una comunicación fluida entre los nodos de un clúster de espacio y lograr un rendimiento óptimo del clúster, debe asegurarse de lo siguiente:

• Todos los nodos de un clúster de Junos Space se configuran con direcciones IP dentro de la misma subred. Esto es importante para que el mecanismo de conmutación VIP funcione correctamente.

• Todos los nodos de un clúster de Space se conectan mediante una red local de 1 Gbps o 100 Mbps con una latencia insignificante.

• Los servidores JBoss de un clúster de Junos Space se comunican mediante una multidifusión UDP para formar clústeres lógicos.

  Nota:

  El tráfico de multidifusión UDP debe permitirse dentro de los nodos del clúster, lo que también significa que debe deshabilitar la supervisión IGMP en los conmutadores que interconectan el clúster o configurarlos explícitamente para permitir la multidifusión UDP entre los nodos.