Démon de redondance de service
Présentation du démon de redondance de service
- Présentation du démon de redondance de service
- Composants du démon de redondance de service
- Contraintes des démons de redondance de service
- Fonctionnement du démon de redondance de service
- Comportement du démon de redondance de service spécifique à la plate-forme
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 :
Le srd s’exécute sur le moteur de routage. Il surveille en permanence les événements de redondance configurés.
Lorsqu’un événement de redondance est détecté, le srd :
Ajoute ou supprime les itinéraires de signal spécifiés dans la stratégie de redondance.
Bascule les services vers la passerelle de secours préférée suivante.
Met à jour les rôles de synchronisation avec états si nécessaire.
Les modifications d’itinéraire qui en résultent entraînent :
La stratégie de routage connectée à cet itinéraire pour annoncer les itinéraires différemment.
VRRP pour modifier les priorités annoncées.
Pour résumer le processus de basculement :
Un événement critique se produit.
SRD ajoute ou supprime un itinéraire de signal.
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.
Les services basculent vers la passerelle de secours préférée suivante.
La synchronisation dynamique est mise à jour en conséquence.
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 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-policy
au niveau hiérarchique[edit policy-options]
-
redundancy-event
au niveau hiérarchique[edit event-options]
-
redundancy-set
au 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
- Configuration des stratégies de redondance
- Configuration de l’ensemble et du groupe de redondance
- configuration des stratégies de routage avec prise en charge de la redondance
- Configuration des ensembles de services
Configuration des événements de redondance
Pour configurer les événements de redondance :
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 :
L’exemple suivant illustre la configuration de stratégies de redondance pour deux passerelles homologues :
user@gateway1# edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events ACQU_MSHIP_MANUAL_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-event ACQU_MSHIP_MANUAL_EV then] user@gateway1# set acquire-mastership add-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway1# top user@gateway1# edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then [edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then] user@gateway1# set release-mastership-force delete-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE
user@gateway2# edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events ACQU_MSHIP_MANUAL_EV then] user@gateway2# set release-mastership-force add-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway2# top user@gateway2# edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events PEER_MSHIP_RELS_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events PEER_MSHIP_RELS_EV then] user@gateway2# set acquire-mastership delete-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway2# top user@gateway2# edit policy-options redundancy-policy WARN_POL redundancy-events WARN_EV then [edit policy-options redundancy-policy WARN_POL redundancy-events WARN_EV then] user@gateway2# set broadcast-warning
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.
iccp { local-ip-addr 10.1.1.1; peer 10.2.2.2 { redundancy-group-id-list 1; liveness-detection { minimum-interval 1000; } } }
Pour configurer des jeux de redondance, procédez comme suit :
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 :
Configuration des ensembles de services
Spécifiez la synchronisation avec état des services d’un ensemble de services.
[edit] user@gateway1# set services service-set service-set-name redundancy-set-id redundancy-set
Par exemple:
[edit] user@gateway1# set services service-set CGN4_SP-7-0-0 redundancy-set-id 1
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.
[edit] user@host# set system scripts op file sdg-inservice.slax user@host# set system scripts op file sdg-oos.slax user@host# set system scripts op file services-oids.slax user@host# set system scripts op file srd-status.slax user@host# set system scripts op max-datasize 512m
Utilisez les scripts srd en tant qu’utilisateur root :