Comprendre les nœuds haute disponibilité dans un cluster
Un cluster Junos Space doit inclure au moins deux nœuds pour atteindre une haute disponibilité. Si le cluster comprend plus de deux nœuds, la disponibilité du cluster n’augmente pas, mais la charge que le cluster peut gérer augmente avec chaque nœud ajouté au cluster. Ainsi, à un moment donné, seuls deux nœuds du cluster fournissent une haute disponibilité à l’ensemble du cluster. Par défaut, ces deux nœuds seuls (appelés nœuds HA du cluster) forment le cluster HA Linux, le cluster Apache Load Balancer et le cluster MySQL. Si vous avez ajouté des nœuds de base de données dédiés au cluster, le cluster MySQL est formé par les nœuds de base de données primaire et secondaire.
Par défaut, les deux premiers nœuds ajoutés à la fonction de cluster en tant que nœuds HA. Dans la rubrique Comprendre les clusters logiques dans un cluster Junos Space, l’exemple montre que les deux premiers nœuds (nœuds 1 et nœud 2) sont des nœuds HA. Si vous devions supprimer les nœuds 1 ou 2 de la plate-forme de gestion du réseau > Administration > l’espace de travail de la structure, le système vérifie si d’autres nœuds du cluster sont disponibles pour remplacer le nœud HA supprimé. Le système affiche ensuite la liste des nœuds capables (seulement le nœud 3 dans l’exemple), que vous pouvez sélectionner. Une fois que vous avez confirmé le nœud sélectionné, le service Distributed Resource Manager (DRM) ajoute le nœud au cluster HA en envoyant des requêtes à l’agent de gestion de nœud (NMA) qui s’exécute sur le nœud nouvellement sélectionné. Les actions suivantes sont lancées sur le nœud ajouté au cluster HA :
Le serveur HTTP Apache avec le mod_proxy équilibreur de charge est lancé sur le nœud et le nœud est configuré avec tous les nœuds JBoss comme membres.
S’il n’y a pas de nœuds de base de données dédiés dans le cluster, la base de données du serveur MySQL sur l’autre nœud HA du cluster est copiée et le serveur MySQL est démarré sur le nœud. Ce serveur est configuré en tant que sauvegarde de l’autre serveur MySQL du cluster et il se synchronise de nouveau avec le serveur principal en arrière-plan. Le serveur MySQL existant est également reconfiguré pour faire office de sauvegarde de ce nouveau serveur afin de garantir une configuration primaire/de secours symétrique sur les deux.
Lorsque vous ajoutez des nœuds de base de données dédiés au cluster Junos Space, vous ajoutez deux nœuds en tant que nœuds de base de données primaires et secondaires pour former le cluster MySQL. La base de données est copiée depuis le nœud HA actif vers les deux nœuds de la base de données et est désactivée sur les nœuds HA. Si vous devions supprimer l’un des nœuds de la base de données du cluster, l’autre nœud de base de données est désigné nœud de base de données principal. Le système vérifie si les nœuds non haute disponibilité du cluster sont disponibles pour remplacer le nœud de base de données supprimé et affiche la liste de nœuds que vous pouvez sélectionner pour remplacer le nœud supprimé.
Une fois que vous avez sélectionné un nœud, le service Distributed Resource Manager (DRM) ajoute le nœud au cluster MySQL en envoyant des requêtes à l’agent de gestion de nœud (NMA) qui s’exécute sur le nœud nouvellement sélectionné.
Les actions suivantes sont lancées sur le nœud ajouté au cluster MySQL :
La base de données du serveur MySQL sur le nœud de base de données principal du cluster est copiée et le serveur MySQL démarre sur le nœud de base de données secondaire nouvellement ajouté. Ce serveur est configuré en tant que sauvegarde du serveur MySQL sur le nœud de base de données principal et il se synchronise à nouveau avec le principal en arrière-plan. Le serveur MySQL existant sur le nœud de base de données principale est également reconfiguré pour faire office de sauvegarde de ce nouveau serveur sur le nœud de base de données secondaire afin de garantir une configuration primaire/de secours symétrique sur les deux.
Le serveur JBoss est arrêté sur le nœud de base de données nouvellement ajouté.
En plus des trois clusters logiques par défaut, si vous disposez d’un cluster Cassandra dans la structure Junos Space, les fichiers téléchargés sur Cassandra sont copiés vers tous les nœuds Cassandra qui font partie du cluster Cassandra. Par conséquent, si un nœud Cassandra échoue, les fichiers du nœud défaillant ne sont pas perdus. Toutefois, la plate-forme Junos Space ne peut pas télécharger ou supprimer des fichiers dans la base de données Cassandra tant que le nœud qui a échoué n’a pas été supprimé.
Si le service Cassandra est activé sur un nœud HA et que ce nœud tombe en panne, et si vous souhaitez exécuter le service Cassandra sur le nœud HA nouvellement ajouté, vous devez activer et démarrer manuellement le service Cassandra sur le nœud. Lorsque le dernier nœud avec le service Cassandra s’exécute, les fichiers stockés dans la base de données Cassandra sont perdus.