configuration des paramètres de basculement du cluster

Présentation des pulsations de la liaison de contrôle du cluster de châssis

Vous spécifiez le seuil de pulsation et l’intervalle de pulsation lorsque vous configurez le cluster de châssis.

Par défaut, le système surveille l'état de la liaison de contrôle.

Pour les liaisons à double contrôle, qui sont prises en charge sur les lignes SRX5600 et SRX5800, le processus jsrpd (Juniper Services Redundancy Protocol) envoie et reçoit les messages de pulsation de contrôle sur les deux liaisons de contrôle. Tant que des pulsations sont reçues sur l’une des liaisons de contrôle, Junos OS considère que l’autre nœud est actif.

Le produit de l’option heartbeat-threshold et l’option heartbeat-interval définit le temps d’attente avant le déclenchement du basculement. Les valeurs par défaut de ces options produisent un temps d’attente de 3 secondes. Un seuil de pulsation de 5 et un intervalle de pulsation de 1000 millisecondes donneraient un temps d’attente de 5 secondes. Si vous définissez le seuil de pulsation sur 4 et l’intervalle de pulsation sur 1250 millisecondes, le temps d’attente est également de 5 secondes.

Dans un environnement de cluster de châssis, si plus de 1000 interfaces logiques sont utilisées, il est recommandé d’augmenter les temporisateurs de pulsation du cluster par rapport à la valeur par défaut de 3 secondes. Lorsque vous atteignez la capacité maximale d’un pare-feu SRX4600, SRX5400, SRX5600 ou SRX5800, nous vous recommandons d’augmenter le temps configuré avant basculement à au moins 5 secondes.

Présentation de la défaillance et de la récupération des liens de contrôle du cluster de châssis

En cas de défaillance de la liaison de contrôle, Junos OS définit l’état de fonctionnement du nœud secondaire comme inéligible pour un compte à rebours de 180 secondes. Si la liaison de structure échoue également pendant les 180 secondes, Junos OS transforme le nœud secondaire en nœud principal ; sinon, après 180 secondes, l’état du noeud secondaire passe à Désactivé.

Lorsque la liaison de contrôle est désactivée, un message de journal système est généré.

La défaillance d’une liaison de contrôle est définie comme l’absence de pulsations sur la liaison de contrôle alors que les pulsations sont toujours reçues sur la liaison de structure.

En cas de défaillance d’une liaison de contrôle légitime, le groupe de redondance 0 reste principal sur le nœud sur lequel il est actuellement principal, les groupes de redondance inactifs x sur le nœud principal deviennent actifs et le nœud secondaire passe à l’état désactivé.

Lorsque le nœud secondaire est désactivé, vous pouvez toujours vous connecter au port de gestion et exécuter les diagnostics.

Pour déterminer si une défaillance légitime de la liaison de contrôle s’est produite, le système s’appuie sur des signaux de vivacité redondants envoyés à la fois sur la liaison de contrôle et sur la liaison de structure.

Le système transmet périodiquement des sondes sur la liaison fabric et des signaux de pulsation sur la liaison de contrôle. Les sondes et les signaux de pulsation partagent un numéro de séquence commun qui les mappe à un événement temporel unique. Junos OS identifie une défaillance de liaison de contrôle légitime si les deux conditions suivantes sont réunies :

• Le nombre seuil de battements de cœur a été perdu.

• Au moins une sonde dont le numéro de séquence correspond à celui d’un signal de pulsation manquant a été reçue sur la liaison de fabric.

En cas de défaillance de la liaison de contrôle, le compte à rebours de 180 secondes commence et l’état du nœud secondaire n’est plus éligible. Si la liaison de structure échoue avant que le compte à rebours de 180 secondes n’atteigne zéro, le nœud secondaire devient principal, car la perte des deux liens est interprétée par le système pour indiquer que l’autre nœud est mort. Étant donné que la perte simultanée de liaisons de contrôle et de structure signifie que les nœuds ne synchronisent plus les états et ne comparent plus les priorités, les deux nœuds peuvent donc temporairement devenir principaux, ce qui n’est pas un état de fonctionnement stable. Toutefois, une fois la liaison de contrôle rétablie, le nœud avec la valeur de priorité la plus élevée devient automatiquement principal, l’autre nœud devient secondaire et le cluster revient à un fonctionnement normal.

Lorsqu’une défaillance de liaison de contrôle légitime se produit, les conditions suivantes s’appliquent :

• Le groupe de redondance 0 reste principal sur le nœud sur lequel il est actuellement principal (et donc son moteur de routage reste actif), et tous les groupes de redondance x sur le nœud deviennent principaux.

  Si le système ne parvient pas à déterminer quel moteur de routage est principal, le nœud avec la valeur de priorité la plus élevée pour le groupe de redondance 0 est principal et son moteur de routage est actif. (Vous configurez la priorité de chaque noeud lorsque vous configurez l’instruction pour le redundancy-group groupe de redondance 0.)

• Le système désactive le noeud secondaire.

  Pour récupérer un périphérique du mode désactivé, vous devez redémarrer l’appareil. Lorsque vous redémarrez le noeud désactivé, le noeud synchronise son état dynamique avec le noeud principal.

Si vous apportez des modifications à la configuration alors que le noeud secondaire est désactivé, exécutez la commande commit pour synchroniser la configuration après avoir redémarré le noeud. Si vous n’avez pas apporté de modifications à la configuration, le fichier de configuration reste synchronisé avec celui du nœud principal.

Vous ne pouvez pas activer la préemption pour le groupe de redondance 0. Si vous souhaitez remplacer le nœud principal par le groupe de redondance 0, vous devez effectuer un basculement manuel.

Lorsque vous utilisez des liaisons à double contrôle (prises en charge sur les périphériques SRX5600 et SRX5800), notez les conditions suivantes :

• Le trafic entrant ou sortant de l’hôte peut être affecté pendant 3 secondes maximum en cas de défaillance d’une liaison de contrôle. Prenons l’exemple d’un cas où le groupe de redondance 0 est principal sur le nœud 0 et où il existe une session Telnet vers le moteur de routage via un port d’interface réseau sur le nœud 1. En cas de défaillance de la liaison de contrôle active, la session Telnet perd des paquets pendant 3 secondes, jusqu’à ce que cette défaillance soit détectée.

• Une défaillance de liaison de contrôle qui se produit alors que le processus de validation est en cours d’exécution sur deux nœuds peut entraîner un échec de validation. Dans ce cas, exécutez à nouveau la commande commit après 3 secondes.

Pour les équipements SRX5600 et SRX5800, les liaisons à double contrôle nécessitent une deuxième moteur de routage sur chaque nœud du cluster de châssis.

Vous pouvez spécifier que la récupération de la liaison de contrôle soit effectuée automatiquement par le système en définissant l’instruction control-link-recovery . Dans ce cas, une fois que le système a déterminé que la liaison de contrôle est saine, il émet un redémarrage automatique sur le nœud désactivé. Lorsque le noeud désactivé redémarre, il rejoint à nouveau le cluster.