Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Démon de redondance de service

Présentation du démon de redondance de service

Présentation du démon de redondance de service

  • Le service redundancy daemon (srd) fournit des événements configurables qui peuvent décider quand la redondance se produit sur plusieurs passerelles sur les routeurs MX Series équipés de MS-MPC et MS-MIC. Cela vous permet de gérer les basculements de rôles principaux en fonction d’un événement surveillé. Vous pouvez configurer la redondance en fonction des événements surveillés, notamment :

    • Événements de liaison.

    • FPC et PIC redémarrent.

    • Le démon de protocole de routage (rpd) s’arrête et redémarre.

    • Événements de passerelle homologue, y compris les demandes d’acquisition ou de libération du rôle principal, ou la diffusion d’avertissements.

Composants du démon de redondance de service

Les composants configurables suivants contrôlent le traitement SRD :

  • Redundancy Event—Événement critique surveillé qui incite le srd à acquérir ou à libérer le rôle principal pour les homologues redondants, ou à déclencher des événements d’avertissement uniquement, et à ajouter ou supprimer des routes de signaux. Les événements surveillés comprennent les événements d’interface ou de liaison inactive, les événements rpd et les événements d’acquisition ou de publication de rôles principaux de pairs.

  • Redundancy Policy: stratégie qui définit l’ensemble des actions entreprises lorsqu’un événement de redondance se produit. Les actions disponibles incluent l’acquisition ou la libération du rôle principal, ainsi que l’ajout ou la suppression de routes de signalisation.

  • Redundancy Set: ensemble d’un ou de plusieurs ensembles de services avec une ou plusieurs stratégies de redondance communes. Un jeu de redondance s’applique à deux passerelles système ou plus. Une seule des passerelles est principale et le ou les homologues sont en veille à tout moment. Les stratégies de redondance définissent les actions à entreprendre pour un ensemble de redondances lorsque le SRD détecte un événement déclencheur.

  • Redundancy Group: il existe une relation un-à-un entre un jeu de redondance et un groupe de redondance. Un jeu de redondance ne peut faire partie que d’un seul groupe de redondance.

  • Signal routes: routes statiques ajoutées ou supprimées par le srd en fonction des changements d’état du rôle principal.

  • Routing Policies: stratégies configurées pour annoncer des routes en fonction de l’existence ou de l’inexistence de routes de signal à l’aide de la if-route-exists condition.

  • VRRP (Virtual Router Redundancy Protocol) route tracking—Fonctionnalité VRRP standard de Junos OS TA, mais composant srd en option, qui suit l’existence d’une route accessible dans la table de routage de l’instance de routage incluse dans la configuration et modifie dynamiquement la priorité du groupe VRRP en fonction de l’accessibilité de la route suivie, déclenchant ainsi une nouvelle élection de routeur principal. L’itinéraire à suivre est un itinéraire de signalisation.

Contraintes des démons de redondance de service

Les contraintes suivantes s’appliquent aux configurations de traitement srd :

  • Il existe une relation un-à-un entre un jeu de redondance et un groupe de redondance. Un jeu de redondance ne peut faire partie que d’un seul groupe de redondance.

  • Une stratégie de redondance ne peut faire partie que d’un seul jeu de redondance, mais un jeu de redondance peut avoir plusieurs stratégies de redondance. Par exemple, le jeu de redondances RS1 peut inclure les stratégies de redondance RP1 et RP2. Les stratégies de redondance RP1 et RP2 ne peuvent pas être incluses dans des jeux de redondance autres que RS1.

  • Un événement de redondance ne peut faire partie que d’une seule stratégie de redondance, mais une stratégie de redondance peut avoir plusieurs événements de redondance. Par exemple, la stratégie de redondance RP1 peut inclure les événements de redondance RE1 et RE2. Les événements de redondance RE1 et RE2 ne peuvent pas être inclus dans les stratégies de redondance autres que RP1.

  • Une interface ou une liaison surveillée ne peut faire partie que d’un seul événement de redondance, mais un événement de redondance peut avoir plusieurs interfaces surveillées.

  • Un ensemble de services ne peut faire partie que d’un seul jeu de redondance, mais un jeu de redondances peut avoir plusieurs ensembles de services.

  • Si la passerelle 1, c’est-à-dire le châssis configuré avec l’adresse IP la plus basse, est le châssis principal et que vous désactivez SRD sur celui-ci, un basculement vers la passerelle 2 se produit. Si la passerelle 2, le châssis configuré avec l’adresse IP la plus élevée, est le châssis principal et que vous désactivez SRD sur celui-ci, il n’y a pas de basculement.

  • Un jeu de redondance particulier ne peut être actif que sur une seule passerelle, mais il n’est pas nécessaire que tous les jeux de redondance soient actifs sur la même passerelle. Par exemple, le jeu de redondances A peut être actif sur la passerelle 1, tandis que le jeu de redondances B est actif sur la passerelle 2.

Fonctionnement du démon de redondance de service

Le srd fonctionne comme suit :

  1. Le srd s’exécute sur le moteur de routage. Il surveille en permanence les événements de redondance configurés.

  2. Lorsqu’un événement de redondance est détecté, le srd :

    1. Ajoute ou supprime les itinéraires de signal spécifiés dans la stratégie de redondance.

    2. Bascule les services vers la passerelle de secours préférée suivante.

    3. Met à jour les rôles de synchronisation avec états si nécessaire.

  3. Les modifications d’itinéraire qui en résultent entraînent :

    1. La stratégie de routage connectée à cet itinéraire pour annoncer les itinéraires différemment.

    2. VRRP pour modifier les priorités annoncées.

Pour résumer le processus de basculement :

  1. Un événement critique se produit.

  2. SRD ajoute ou supprime un itinéraire de signal.

  3. Une stratégie de routage annonce les itinéraires différemment. Les changements annoncés dans le cadre du PRVR ont fait l’objet d’une annonce.

  4. Les services basculent vers la passerelle de secours préférée suivante.

  5. La synchronisation dynamique est mise à jour en conséquence.

Note:

L’ordre des priorités de routage doit correspondre au rôle principal de l’ordre des services.

Comportement du démon de redondance de service spécifique à la plate-forme

Plateforme

Différence

MX Series

Le démon de redondance de service n’est pas activé par défaut. Vous pouvez activer Service Redundancy Daemon à l’aide de l’instruction system processes srd enable dans la [edit] hiérarchie.

Dans Junos OS version 21.2R1, vous pouvez activer Service Redundancy Daemon à l’aide de l’instruction services redundancy bring-up-on-any dans la [edit] hiérarchie.

configuration du démon de redondance de service

Avant de configurer le traitement srd, nous vous recommandons de vous familiariser avec Configuration d’ICCP pour MC-LAG, qui explique les relations d’homologue entre les passerelles qui sont activées pour échanger des rôles principaux et de secours.

Vous utilisez les instructions de configuration suivantes :

  • redundancy-policyau niveau hiérarchique [edit policy-options]

  • redundancy-eventau niveau hiérarchique [edit event-options]

  • redundancy-setau niveau hiérarchique [edit services]

Les actions à effectuer lorsque des événements de redondance configurés se produisent sont définies dans les stratégies de redondance. Les stratégies de redondance sont associées à des ensembles de redondance. Elles sont analogues aux règles associées aux ensembles de services. Les jeux de redondance sont associés à des groupes de redondance par des ID de groupe de redondance. Les détails des groupes de redondance sont définis par la configuration iccpd (Inter-Chassis Communication Protocol Daemon) sous-jacente. Les ensembles de services et les jeux de redondance sont associés par le biais de l’instruction dans la redundancy-sets configuration des ensembles de services.

Dans les procédures qui suivent, les événements de redondance configurés et associés à une stratégie de redondance. La stratégie de redondance est associée à un ensemble de redondance pour effectuer une action appropriée de libération ou d’acquisition du rôle principal. Si un événement est associé à une stratégie qui prend l’action de mise en production du rôle principal, srd vérifie si l’état de l’homologue redondant est prêt ou averti. Si l’état d’alerte est en état d’avertissement, l’action de mise en production du rôle principal échoue. Vous pouvez restaurer la vérification de l’état et exécuter manuellement l’action de rôle principal de mise en production.

Pour libérer le rôle principal dans tous les cas, vous pouvez soit configurer l’action de stratégie en tant que release-mastership-force , soit utiliser la request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force commande dans l’interface de ligne de commande opérationnelle. Même si votre configuration spécifie l’option release-mastership-force , l’utilisation de la request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force commande CLI est prioritaire et le rôle principal est libéré. De même, si un événement de redondance est configuré avec une stratégie avec une action acquire primary-role, srd vérifie l’état de l’ensemble de redondance local. Dans le cas d’un état d’attente, l’action échoue à moins que vous n’utilisiez la request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force commande CLI. Nous vous recommandons de déterminer la raison de l’échec des vérifications de l’état et de prendre les mesures nécessaires pour corriger cet échec. Après cela, lorsque l’état du jeu de redondance revient à STANDBY, cette action de modification du rôle principal réussit.

Un jeu de redondance particulier ne peut être actif que sur une seule passerelle, mais il n’est pas nécessaire que tous les jeux de redondance soient actifs sur la même passerelle. Par exemple, le jeu de redondances A peut être actif sur la passerelle 1, tandis que le jeu de redondances B est actif sur la passerelle 2.

Pour configurer srd, effectuez les tâches de configuration suivantes dans l’ordre recommandé. Des configurations sont affichées pour deux passerelles pour lesquelles le rôle principal peut changer.

Configuration des événements de redondance

Pour configurer les événements de redondance :

  1. Configurez les événements de redondance de liaison descendante pour la passerelle principale.

    Par exemple:

  2. Configurez les événements de redondance de processus pour la passerelle principale.

    Par exemple:

  3. Configurez tous les événements de redondance de liaison descendante pour la passerelle de secours.

    Par exemple:

  4. Configurez tous les événements de redondance de processus pour la passerelle de secours.

    Par exemple:

  5. Configurez tous les événements de redondance d’homologue pour la passerelle de secours.

    Par exemple:

Configuration des stratégies de redondance

Les stratégies de redondance de service spécifient les actions déclenchées par les événements de redondance surveillés.

Pour configurer des stratégies de redondance :

  1. Spécifiez une stratégie de redondance et un événement de redondance pour la passerelle principale. Suivez les mêmes étapes pour la passerelle de secours.
  2. Spécifiez une action d’acquisition ou de libération du rôle principal.

    ou

  3. (Facultatif) Spécifiez une action d’ajout d’un itinéraire statique.
    Bonne pratique :

    Nous vous recommandons d’utiliser cette receive option.

  4. (Facultatif) Spécifiez une action de suppression d’un itinéraire statique.

L’exemple suivant illustre la configuration de stratégies de redondance pour deux passerelles homologues :

Configuration de l’ensemble et du groupe de redondance

Les ID de groupe de redondance utilisés par srd sont associés à ceux configurés pour le démon ICCP (iccpd) via la hiérarchie de configuration ICCP existante en utilisant le même ID de groupe de redondance dans la configuration du groupe de redondance des services.

Pour configurer des jeux de redondance, procédez comme suit :

  1. Spécifiez le jeu et le groupe de redondance pour la passerelle principale.

    Par exemple:

  2. Spécifiez des stratégies de redondance pour le jeu de redondance.

    Par exemple:

  3. Spécifiez le jeu et le groupe de redondance pour la passerelle homologue.

    Par exemple:

  4. Spécifiez des stratégies de redondance pour le jeu de redondance.

    Par exemple:

configuration des stratégies de routage avec prise en charge de la redondance

Pour configurer des stratégies de routage qui prennent en charge la redondance :

  1. Au niveau de la [edit policy-options condition] hiérarchie, utilisez l’instruction if-route-exists de configuration pour définir une condition basée sur l’existence de routes de signal qui nécessitent des modifications de routage liées à la redondance. Spécifiez la table de routage utilisée.

    Par exemple:

  2. Au niveau de la hiérarchie, spécifiez les [edit policy-options policy-statement statement-name] modifications de routage en fonction de la condition indiquant l’existence de l’itinéraire du signal. Pour BGP, les modifications de routage incluent généralement la modification des valeurs local-preference et as-path-prepend.
    1. Pour modifier la préférence locale, spécifiez-le local-preference dans la then clause de l’énoncé de stratégie.

      Par exemple:

    2. Pour modifier as-path-prepend les valeurs, spécifiez-le as-path-prepend dans la then clause de l’énoncé de stratégie.

      Par exemple:

Configuration des ensembles de services

Spécifiez la synchronisation avec état des services d’un ensemble de services.

Spécifiez l’ensemble de services et le jeu de redondance.

Par exemple:

Utilisation de scripts de démon de redondance de service pour afficher et modifier l’état d’une passerelle

Vous pouvez déterminer l’état d’une passerelle, désactiver ou activer toutes les interfaces de la passerelle, ou extraire des informations MIB relatives aux services de la passerelle en exécutant des scripts srd (Service Redundancy Daemon).

Avant de pouvoir utiliser ces scripts, vous devez les activer :

  • Activez les scripts srd.

Utilisez les scripts srd en tant qu’utilisateur root :

  • Désactivez toutes les interfaces du routeur MX Series et mettez les cartes MS-MPC hors tension.
    1. Assurez-vous que tous les jeux de redondance locaux sont en mode veille.
    2. Exécutez le sdg-oos script.
  • Activez toutes les interfaces sur le routeur MX Series et mettez les cartes MS-MPC sous tension.
  • Vérifiez l’état de service d’une passerelle.
  • Extrayez les informations MIB relatives aux services de la passerelle.