Présentation de la haute disponibilité
La haute disponibilité (HA) sur le contrôleur NorthStar est une solution active/en veille. Cela signifie qu’il n’y a qu’un seul nœud actif à la fois, tous les autres nœuds du cluster servant de nœuds de secours. Tous les nœuds d’un cluster doivent se trouver sur le même sous-réseau pour que la HA prenne en charge l’IP virtuelle (VIP). Sur le nœud actif, tous les processus sont en cours d’exécution. Sur les nœuds de secours, les processus nécessaires au maintien de la connectivité sont en cours d’exécution, mais les processus NorthStar sont à l’arrêt. Si le nœud actif subit une défaillance de connectivité liée au matériel ou au logiciel, le processus NorthStar HA_agent choisit un nouveau nœud actif parmi les nœuds de secours. Le basculement complet est réalisé en cinq minutes. L’un des facteurs de sélection du nouveau nœud actif est les priorités configurées par l’utilisateur des nœuds candidats.
Tous les processus sont lancés sur le nouveau nœud actif, et le nœud configure l’adresse IP virtuelle en fonction de la configuration utilisateur (via net_setup.py). L’IP virtuelle peut être utilisée pour les interfaces côté client ainsi que pour les sessions PCEP.
Tout au long de votre utilisation du contrôleur NorthStar HA, n’oubliez pas que vous devez répliquer toutes les modifications apportées à northstar.cfg sur tous les nœuds du cluster afin que la configuration soit uniforme dans tout le cluster. En revanche, les modifications de configuration du cMGD sont automatiquement répliquées sur les nœuds du cluster.
Scénarios de défaillance
Le contrôleur NorthStar HA protège le réseau contre les scénarios de défaillance suivants :
-
Pannes matérielles (panne de courant du serveur, interfaces réseau du serveur ou défaillance du câble Ethernet côté réseau)
-
Défaillances du système d’exploitation (redémarrage du système d’exploitation du serveur, échec du système d’exploitation du serveur)
-
Défaillances logicielles (défaillance d’un processus en cours d’exécution sur le serveur actif lorsqu’il est incapable de récupérer localement)
Basculement et interfaces utilisateur du contrôleur NorthStar
Si un basculement se produit pendant que vous travaillez dans le client Java Planner du contrôleur NorthStar, le client est déconnecté et vous devez relancer le contrôleur NorthStar à l’aide de l’adresse IP virtuelle de l’interface côté client.
Si le serveur n’a qu’une seule interface ou si vous ne souhaitez utiliser qu’une seule interface, l’interface côté réseau est alors également l’interface côté client.
L’interface utilisateur Web perd également sa connectivité en cas de basculement, ce qui vous oblige à vous reconnecter.
Prise en charge de plusieurs interfaces réseau
Jusqu’à cinq interfaces réseau sont prises en charge pour les déploiements haute disponibilité (HA), dont l’une que vous désignez comme interface de communication de cluster (Zookeeper). L’utilitaire net_setup.py permet de configurer les interfaces surveillées à la fois dans la configuration hôte (interfaces hôtes 1 à 5) et dans la configuration JunosVM (interfaces JunosVM 1 à 5). Dans HA Setup, net_setup.py permet de configurer toutes les interfaces sur chacun des nœuds du cluster HA.
Le ha_agent envoie des sondes à l’aide de paquets ICMP (ping) à des points de terminaison de cluster distants (y compris l’interface Zookeeper) pour surveiller la connectivité des interfaces. Si le paquet n’est pas reçu dans le délai imparti, le voisin est déclaré inaccessible. Le ha_agent informe Zookeeper de tout changement d’état d’interface et propage cette information dans tout le cluster. Vous pouvez configurer les valeurs d’intervalle et de délai d’expiration pour le cluster dans le script de configuration de la HA. Les valeurs par défaut sont respectivement de 10 secondes et 30 secondes.
L’utilitaire de configuration de la HA contient également une option permettant de configurer si le basculement doit être autorisé pour chaque interface.
Pour les configurations de machines virtuelles imbriquées, vous devrez peut-être modifier supervisord-junos.sh pour prendre en charge les interfaces supplémentaires pour junosVM.
Rapport d’anomalie LSP
Lors d’un basculement HA, le serveur PCS effectue le rapprochement LSP. Le rapprochement produit le rapport d’écart LSP qui identifie les LSP dont le serveur PCS a découvert qu’ils pourraient nécessiter un nouveau provisionnement.
Seuls les LSP initiés et délégués par PCC sont inclus dans le rapport.
Accédez au rapport en accédant à Applications > Reports. La figure 1 présente une liste des rapports disponibles, y compris le rapport sur les écarts LSP.
Cluster Configuration
La mise en œuvre de HA par NorthStar exige que le cluster ait un quorum, ou une majorité, d’électeurs. Ceci afin d’éviter le « split brain » lorsque les nœuds sont partitionnés en raison d’une défaillance. Dans un cluster à cinq nœuds, la HA peut tolérer deux défaillances de nœuds, car les trois nœuds restants peuvent encore former une majorité simple. Le nombre minimum de nœuds dans un cluster est de trois.
L’utilitaire de configuration du contrôleur NorthStar permet de configurer un cluster HA. Tout d’abord, configurez les serveurs autonomes ; puis configurez le cluster.
Voir Configuration d’un cluster NorthStar pour une haute disponibilité dans le Guide de démarrage du contrôleur NorthStar pour obtenir des instructions étape par étape sur l’installation/configuration du cluster.
Ports qui doivent être autorisés par des pare-feu externes
Parmi les ports utilisés par NorthStar, il y en a un certain nombre qui doivent être autorisés par les pare-feu externes pour que les serveurs du contrôleur NorthStar puissent communiquer. Voir Configuration système requise pour le contrôleur NorthStar dans le Guide de démarrage du contrôleur NorthStar pour obtenir la liste des ports utilisés par le contrôleur NorthStar qui doivent être autorisés par les pare-feu externes. Les ports dont la description des objectifs figure dans ce mot cluster se rapportent spécifiquement à la configuration HA.