SUR CETTE PAGE
Comprendre les clusters logiques au sein d’un cluster Junos Space
Vous pouvez connecter plusieurs appliances Junos Space (matérielles ou virtuelles) pour former un cluster Junos Space. La figure 1 montre les clusters logiques (cluster Apache Load Balancer, cluster JBoss et cluster MySQL) formés au sein de chaque cluster Junos Space.
logiques Junos Space
Apache Load-Balancer Cluster
Le serveur HTTP Apache, avec le module d’équilibrage de charge mod_proxy activé, s’exécute à tout moment sur deux nœuds du cluster. Ces serveurs forment un cluster logique de secours actif. Ils écoutent tous les deux sur le port TCP 443 les requêtes HTTP des clients GUI et NBI. Tous les clients utilisent l’adresse IP virtuelle (VIP) du cluster pour accéder à ses services. À tout moment, l’adresse VIP appartient à un seul nœud du cluster. Par conséquent, le serveur HTTP Apache sur le nœud propriétaire de l’adresse VIP reçoit toutes les requêtes HTTP des clients GUI et NBI et agit comme le serveur d’équilibrage de charge actif, tandis que l’autre serveur agit comme serveur de secours. Un algorithme d’équilibrage de charge tourniquet est utilisé pour distribuer les demandes aux serveurs JBoss exécutés sur tous les nœuds du cluster. L’équilibreur de charge utilise également l’adhérence des sessions pour s’assurer que toutes les requêtes HTTP d’une session utilisateur sont envoyées au même nœud du cluster. Pour ce faire, le serveur définit un cookie nommé JSESSIONID. La valeur de ce cookie identifie le nœud spécifique du cluster qui traite les demandes appartenant à cette session utilisateur. Toutes les demandes supplémentaires contiennent ce cookie et l’équilibreur de charge transmet la demande au serveur JBoss qui s’exécute sur le nœud identifié par ce cookie.
Si le serveur HTTP Apache d’un nœud tombe en panne, le serveur est automatiquement redémarré par le service de surveillance sur ce nœud. Si ce nœud possède l’adresse VIP, les clients GUI et NBI peuvent subir une brève interruption de service jusqu’à ce que le serveur HTTP Apache soit redémarré. Cependant, cette panne ne dure que quelques secondes (généralement deux secondes) et est à peine remarquée par les clients. D’autre part, si le serveur HTTP Apache tombe en panne sur le nœud qui ne possède pas actuellement l’adresse VIP, aucun effet secondaire n’est remarqué par les clients ou tout autre composant. Le service de surveillance redémarre le serveur et le serveur revient en deux secondes environ.
JBoss Cluster
Le serveur d’applications JBoss s’exécute sur tous les nœuds, à l’exception des nœuds de base de données dédiés du cluster Junos Space. Les nœuds forment un seul cluster logique entièrement actif et le serveur d’équilibrage de charge (décrit précédemment) répartit la charge sur tous les nœuds. Même si un ou plusieurs serveurs JBoss du cluster tombent en panne, la logique de l’application reste accessible à partir des nœuds survivants. Les serveurs JBoss de tous les nœuds sont démarrés avec la même configuration et utilisent la multidiffusion UDP pour se détecter mutuellement et former un cluster unique. JBoss utilise également le multicast UDP pour la réplication de session et les services de mise en cache sur tous les nœuds.
Le serveur JBoss ne s’exécute pas sur les nœuds FMPM (Fault Monitoring and Performance Monitoring) ni sur les machines virtuelles hébergées.
Lorsque le serveur JBoss d’un nœud tombe en panne, les autres nœuds du cluster JBoss détectent cette modification et se reconfigurent automatiquement pour supprimer le nœud défaillant du cluster. Le temps nécessaire aux autres membres du cluster pour détecter un serveur JBoss défaillant varie selon que le processus du serveur JBoss s’est bloqué anormalement ou ne répond pas. Dans le premier cas, les membres du cluster détectent la défaillance immédiatement (environ deux secondes) car leurs connexions TCP au serveur JBoss en panne sont fermées par le système d’exploitation. Dans ce dernier cas, les membres du cluster détectent la défaillance en 52 secondes environ. Si un serveur JBoss tombe en panne, le serveur JBoss est automatiquement redémarré par le service de surveillance (jmp-watchdog) exécuté sur le nœud. Lorsque le serveur JBoss revient, il est automatiquement découvert par les autres membres du cluster et ajouté au cluster. Le serveur JBoss synchronise ensuite son cache à partir des autres nœuds du cluster. Le temps de redémarrage typique du serveur JBoss est de deux à cinq minutes, mais il peut prendre plus de temps en fonction du nombre d’applications installées, du nombre d’équipements gérés, du nombre de versions de schéma DMI installées, etc.
Un serveur JBoss du cluster agit toujours comme serveur principal du cluster. L’objectif principal de la désignation principale est d’héberger des services déployés en tant que singletons HA (cluster-wide singletons), par exemple, des services qui doivent être déployés sur un seul serveur du cluster à la fois. Junos Space utilise plusieurs services de ce type, notamment le service Job Poller, qui fournit un minuteur unique pour planifier les tâches dans le cluster, et le service Distributed Resource Manager (DRM), qui surveille et gère les nœuds du cluster. Ces services sont déployés uniquement sur le serveur JBoss désigné comme serveur principal.
Cela ne signifie pas que le principal n’héberge pas d’autres services. Les services singleton hors cluster sont également hébergés sur le serveur principal. Junos Space est configuré de telle sorte que le premier serveur JBoss apparu dans le cluster devienne le serveur principal. Si le serveur principal tombe en panne, les autres membres du cluster JBoss le détectent et élisent un nouveau serveur principal.
MySQL Cluster
Le serveur MySQL s’exécute simultanément sur deux nœuds du cluster Junos Space. Ces nœuds forment un cluster actif-de secours logique et les deux nœuds écoutent sur le port TCP 3306 les demandes de base de données des serveurs JBoss. Par défaut, les serveurs JBoss sont configurés pour utiliser l’adresse IP virtuelle (VIP) du cluster afin d’accéder aux services de base de données. À tout moment, l’adresse VIP appartient à un seul nœud du cluster. Ainsi, le serveur MySQL sur le nœud propriétaire de l’adresse VIP reçoit toutes les demandes de base de données du serveur JBoss, qui agit en tant que serveur de base de données actif tandis que l’autre serveur agit en tant que serveur de secours.
Si vous souhaitez améliorer les performances de la plate-forme de gestion du réseau Junos Space et des applications Junos Space, vous pouvez ajouter deux nœuds Junos Space à exécuter en tant que nœuds de base de données dédiés. Lorsque vous ajoutez deux nœuds Junos Space en tant que nœuds de base de données principal et secondaire, le serveur MySQL est déplacé vers les deux nœuds de base de données dédiés et désactivé sur les deux premiers nœuds du cluster Junos Space. Cela libère des ressources système sur le nœud VIP actif Junos Space, améliorant ainsi les performances du nœud.
Les serveurs JBoss utilisent une adresse IP virtuelle (VIP) de base de données distincte pour accéder aux services de base de données sur des nœuds de base de données dédiés. Vous spécifiez l’adresse VIP de la base de données lorsque vous ajoutez des nœuds en tant que nœuds de base de données dédiés au cluster Junos Space. Cette adresse VIP appartient au nœud désigné comme nœud de base de données principal. Le serveur MySQL sur le nœud de base de données primaire agit en tant que serveur de base de données actif et le serveur sur le nœud de base de données secondaire agit en tant que serveur de secours. La figure 2 montre les clusters logiques (cluster Apache Load Balancer, cluster JBoss et cluster MySQL) formés au sein d’un cluster Junos Space lorsque des nœuds de base de données dédiés font partie du cluster Junos Space.
de base de données dédiés
Les serveurs MySQL sur chacun des nœuds sont configurés avec des ID de serveur uniques. La relation primaire/sauvegarde est également configurée symétriquement sur les nœuds de sorte que le serveur sur le premier nœud soit configuré avec le deuxième nœud comme nœud principal ; et le serveur sur le deuxième nœud est configuré avec le premier nœud comme nœud principal. Ainsi, les deux nœuds sont capables d’agir comme une sauvegarde pour l’autre, et le serveur exécuté sur le nœud propriétaire de l’adresse VIP agit comme principal à tout moment, ce qui garantit que la relation de sauvegarde principale bascule dynamiquement lorsque la propriété VIP bascule d’un nœud à l’autre. Toutes les transactions validées sur le serveur actif (primaire) sont répliquées sur le serveur de secours (sauvegarde) en temps quasi réel, au moyen de la solution de réplication asynchrone [2] fournie par MySQL, basée sur le mécanisme de journalisation binaire. Le serveur MySQL fonctionnant comme principal (la source des modifications de la base de données) écrit les mises à jour et les modifications en tant qu'"événements » dans le journal binaire. Les informations contenues dans le journal binaire sont stockées dans différents formats de journalisation en fonction des modifications de base de données enregistrées. Le serveur de sauvegarde est configuré pour lire le journal binaire à partir du journal principal et pour exécuter tous les événements du journal binaire sur la base de données locale de la sauvegarde.
Si le serveur MySQL sur un nœud tombe en panne, le serveur est redémarré automatiquement par le service de surveillance sur ce nœud. Au redémarrage, le serveur MySQL devrait apparaître dans les 20 à 60 secondes. Si ce nœud possède l’adresse VIP, JBoss peut subir une brève panne de base de données pendant cette durée de 20 à 60 secondes. Toutes les demandes nécessitant un accès à la base de données échouent pendant cette période. D’autre part, si le serveur MySQL tombe en panne sur le nœud qui ne possède pas actuellement l’adresse VIP, il n’y a pas d’effets secondaires remarqués par JBoss. Le service de surveillance redémarre le serveur et le serveur revient en moins d’une minute. Une fois le serveur restauré, il se resynchronise avec le serveur principal en arrière-plan et le temps de resynchronisation dépend du nombre de modifications survenues pendant la panne.
Cassandra Cluster
À partir de la version 15.2R2, le cluster Cassandra est un cluster logique facultatif que vous pouvez inclure dans le cluster Junos Space. Le cluster Cassandra se forme lorsqu’il existe au moins deux nœuds Cassandra dédiés ou deux nœuds JBoss ou plus sur lesquels le service Cassandra est en cours d’exécution, ou une combinaison des deux, dans la fabric Junos Space. Vous pouvez choisir d’exécuter le service Cassandra sur aucun nœud ou sur tous les nœuds de la structure, à l’exception des nœuds de base de données dédiés et des nœuds FMPM. Le service Cassandra exécuté sur les nœuds Junos Space fournit un système de fichiers distribué pour stocker les images des périphériques et les fichiers des applications Junos Space (tels que le Juniper Message Bundle [JMB] généré par Service Now et les fichiers RRD générés par Network Director). S’il n’y a pas de nœuds Cassandra dans la structure, les fichiers image du périphérique et les fichiers d’application Junos Space sont stockés dans la base de données MySQL. La figure 3 montre les clusters logiques (cluster Apache Load Balancer, cluster JBoss, cluster MySQL et cluster Cassandra) formés au sein d’un cluster Junos Space lorsque des nœuds Cassandra font partie du cluster Junos Space.
de Cassandra
Le service Cassandra s’exécute sur tous les nœuds Cassandra dans une configuration active-active avec réplication en temps réel de la base de données Cassandra. Tous les fichiers téléchargés dans la base de données Cassandra sont copiés sur tous les nœuds du cluster Cassandra. Les serveurs JBoss envoient des requêtes aux nœuds Cassandra du cluster Cassandra de manière round robin et accèdent aux nœuds en utilisant l’adresse IP (de l’interface eth0) du nœud Cassandra respectif.
Si un nœud Cassandra tombe en panne, Junos Space Platform ne peut pas télécharger ou supprimer des fichiers de la base de données Cassandra tant que le nœud arrêté n’a pas été supprimé de la fabric. Si tous les nœuds Cassandra existants sont supprimés, les fichiers stockés dans la base de données Cassandra sont perdus.