Comprendre les nœuds de haute disponibilité dans un cluster
Un cluster Junos Space doit inclure au moins deux nuds pour atteindre la haute disponibilité (HA). Si le cluster comprend plus de deux nœuds, la disponibilité du cluster n’augmente pas, mais la quantité de 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 dans le 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 noeuds ajoutés au cluster fonctionnent comme des noeuds HA. Dans la rubrique Présentation des clusters logiques au sein d’un cluster Junos Space, l’exemple montre que les deux premiers noeuds (noeud-1 et noeud-2) sont des noeuds HA. Si vous supprimez le nœud 1 ou le nœud 2 de l’espace de travail Administration > Fabric du Plate-forme de gestion du réseau > , 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 alors la liste des noeuds compatibles (uniquement le noeud-3 dans l’exemple), que vous pouvez sélectionner. Une fois que vous avez confirmé le noeud sélectionné, le service Distributed Resource Manager (DRM) ajoute le noeud au cluster HA en envoyant des demandes à l’agent de gestion du noeud (NMA) exécuté sur le noeud nouvellement sélectionné. Les actions suivantes sont initiées sur le nœud ajouté au cluster HA :
Le serveur HTTP Apache avec l’équilibreur de charge mod_proxy est démarré sur le nœud et le nœud est configuré avec tous les nœuds JBoss en tant que 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é comme une sauvegarde de l’autre serveur MySQL du cluster et il se resynchronise avec le serveur principal en arrière-plan. Le serveur MySQL existant est également reconfiguré pour agir comme une sauvegarde de ce nouveau serveur afin d’assurer une configuration primaire/de sauvegarde 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 ensemble en tant que nœuds de base de données primaire et secondaire pour former le cluster MySQL. La base de données est copiée du noeud HA actif vers les deux noeuds de base de données et est désactivée sur les noeuds HA. Si vous supprimez l’un des noeuds de base de données du cluster, l’autre noeud de base de données est désigné noeud de base de données primaire. Le système vérifie si des noeuds non-HA du cluster sont disponibles pour remplacer le noeud de base de données supprimé et affiche la liste des noeuds que vous pouvez sélectionner pour remplacer le noeud 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 demandes à l’agent de gestion des nœuds (NMA) s’exécutant 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 est démarré sur le nœud de base de données secondaire nouvellement ajouté. Ce serveur est configuré comme une sauvegarde du serveur MySQL sur le nœud de base de données principal et il se resynchronise avec le serveur principal en arrière-plan. Le serveur MySQL existant sur le nœud de base de données primaire est également reconfiguré pour agir comme une sauvegarde de ce nouveau serveur sur le nœud de base de données secondaire afin d’assurer une configuration primaire/de sauvegarde symétrique sur les deux.
Le serveur JBoss est arrêté sur le noeud de base de données nouvellement ajouté.
Outre les trois clusters logiques par défaut, si vous disposez d’un cluster Cassandra dans la fabric Junos Space, les fichiers téléchargés sur Cassandra sont copiés sur tous les nœuds Cassandra qui font partie du cluster Cassandra. Par conséquent, si un nœud Cassandra tombe en panne, les fichiers du nœud défaillant ne sont pas perdus. Toutefois, la plate-forme Junos Space ne peut pas charger ou supprimer des fichiers dans la base de données Cassandra tant que le nœud défaillant n’est pas 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 en cours d’exécution est supprimé, les fichiers stockés dans la base de données Cassandra sont perdus.