Présentation de l’architecture logicielle haute disponibilité de Junos Space

Architecture logicielle Junos Space

La figure 1 offre une vue d’ensemble de l’architecture logicielle de Junos Space. Les services Junos Space sont accessibles aux clients GUI et NBI au moyen d’une adresse IP virtuelle unique pour le cluster.

Figure 1 : architecture logicielle de Junos Space

Les demandes des clients sont équilibrées en charge entre plusieurs nœuds du cluster via Apache HTTP Load Balancer, qui est déployé dans une configuration de secours actif-chaud sur deux nœuds du cluster. L’équilibreur de charge sur le nœud propriétaire de l’adresse IP virtuelle (VIP) agit comme l’instance active. Si le nœud qui possède actuellement l’adresse VIP tombe en panne, l’autre nœud du cluster Linux Virtual Server (LVS) détectera cette défaillance et prendra automatiquement en charge l’adresse VIP. La charge des requêtes HTTP est équilibrée entre tous les serveurs JBoss actifs du cluster à l’aide d’un algorithme tourniquet.

Les serveurs JBoss actifs du cluster fournissent le cadre applicatif des applications Junos Space, notamment les services suivants :

• Hébergement des applications et de la logique métier associée

• Équilibrage de charge au niveau de l’application au sein du cluster

• Surveillance des applications et récupération automatique

• Surveillance des nœuds du cluster et restauration automatique

• Services de base de données avec accès direct à la base de données MySQL via JDBC

• Logique de médiation des appareils d’hébergement

Architecture d’équilibrage de charge

Un cluster Junos Space présente deux types de charges :

• Demandes entrantes de clients GUI et NBI

• Communication avec les appareils gérés

Junos Space est conçu pour équilibrer la charge des demandes entrantes sur tous les nœuds actifs du cluster. Les requêtes des clients GUI et NBI arrivent sous forme de requêtes HTTP traitées par l’instance active de l’équilibreur de charge HTTP Apache. L’équilibreur de charge distribue les demandes à tous les serveurs JBoss actifs du cluster à l’aide d’un algorithme tourniquet. Les sessions persistantes permettent de s’assurer que toutes les requêtes HTTP associées à une session GUI spécifique sont traitées par le même serveur JBoss pendant toute la durée de vie de cette session. Aux fins de l’équilibrage de charge au niveau des applications, la logique métier JBoss traite les demandes complexes comme un ensemble de sous-tâches, qui sont réparties sur plusieurs nœuds du cluster. Par exemple, une demande unique adressée à un cluster Space à quatre nœuds pour resynchroniser 100 périphériques est divisée en quatre sous-tâches exécutées sur quatre nœuds différents, chaque nœud resynchronisant 25 périphériques. Pour obtenir une présentation détaillée de l’équilibrage de charge, reportez-vous à la rubrique Présentation des clusters logiques au sein d’un cluster Junos Space.

Pour effectuer l’équilibrage de charge au niveau de l’équipement, Junos Space utilise la logique de la couche de médiation des périphériques (DML) afin que les connexions des équipements soient réparties de manière égale sur tous les nœuds actifs du cluster. L’équilibrage de charge au niveau du périphérique est effectué lors de la découverte des périphériques en comparant le nombre de connexions de périphériques desservies par des nœuds individuels et en sélectionnant le nœud le moins chargé. En cas de panne d’un nœud, toutes les connexions de périphérique associées sont distribuées aux nœuds actifs restants du cluster, empêchant ainsi une panne de nœud d’affecter la connectivité de l’appareil. Pour obtenir une présentation détaillée de la gestion de la connectivité des périphériques, consultez la rubrique Présentation de la gestion de la haute disponibilité des connexions DMI.

Architecture de la base de données

MySQL Enterprise Edition est utilisé pour fournir des services de base de données pour la gestion des données persistantes pour la plate-forme et les applications. Les serveurs de base de données MySQL s’exécutent sur deux nœuds du cluster en configuration de veille active. Les transactions de base de données sont répliquées entre les deux serveurs MySQL en temps quasi réel. Pour plus d’informations sur le cluster MySQL formé au sein de chaque cluster Junos Space, consultez Présentation des clusters logiques au sein d’un cluster Junos Space.

La plate-forme Junos Space intègre également la surveillance réseau pour la gestion des pannes et des performances, qui utilise le service de base de données relationnelle PostgreSQL pour stocker les données liées aux pannes et aux performances. Le serveur PostgreSQL s’exécute sur deux nœuds du cluster Space en configuration active-active avec réplication en temps réel pour garantir que les données de panne et de performance restent disponibles même si l’un de ces nœuds tombe en panne. Pour plus d’informations, consultez Haute disponibilité pour la surveillance réseau.

Communication entre nœuds d’un cluster Junos Space

Afin de faciliter une communication transparente entre les nœuds d’un cluster Space et d’obtenir des performances optimales du cluster, vous devez vous assurer des éléments suivants :

• Tous les nœuds d’un cluster Junos Space sont configurés avec des adresses IP dans le même sous-réseau. Ceci est important pour que le mécanisme de basculement VIP fonctionne correctement.

• Tous les nœuds d’un cluster Space sont connectés au moyen d’un réseau local de 1 Gbit/s ou 100 Mbit/s avec une latence négligeable.

• Les serveurs JBoss d’un cluster Junos Space communiquent via un multicast UDP pour former des clusters logiques.

  Note:

  Le trafic de multidiffusion UDP doit être autorisé dans les nœuds du cluster, ce qui signifie également que vous devez désactiver la surveillance IGMP sur les commutateurs qui interconnectent le cluster ou les configurer explicitement pour autoriser la multidiffusion UDP entre les nœuds.