Redondance du cluster de châssis basculement de groupe
Un groupe de redondance (RG) inclut et gère un ensemble d’objets sur les deux nœuds d’un cluster afin d’assurer la haute disponibilité. Chaque groupe de redondance agit comme une unité de basculement indépendante et n’est principal que sur un seul nœud à la fois. Pour plus d’informations, consultez les rubriques suivantes :
Comprendre la redondance des clusters de châssis Basculement de groupe
Le cluster de châssis utilise un certain nombre de mécanismes de basculement très efficaces qui favorisent la haute disponibilité pour augmenter la fiabilité et la productivité globales de votre système.
Un groupe de redondance est un ensemble d’objets qui basculent en tant que groupe. Chaque groupe de redondance surveille un ensemble d’objets (interfaces physiques) et chaque objet surveillé se voit attribuer une pondération. Chaque groupe de redondance a un seuil initial de 255. Lorsqu’un objet surveillé tombe en panne, le poids de l’objet est soustrait de la valeur seuil du groupe de redondance. Lorsque la valeur seuil atteint zéro, le groupe de redondance bascule sur l’autre nœud. Par conséquent, tous les objets associés au groupe de redondance basculent également. Le redémarrage harmonieux des protocoles de routage permet au pare-feu SRX Series de minimiser les interruptions de trafic lors d’un basculement.
Les basculements consécutifs d’un groupe de redondance dans un court intervalle peuvent entraîner un comportement imprévisible du cluster. Pour éviter ce comportement imprévisible, configurez un temps d’amortissement entre les basculements. Lors du basculement, le nœud principal précédent d’un groupe de redondance passe à l’état de mise en attente secondaire et reste dans l’état de mise en attente secondaire jusqu’à l’expiration de l’intervalle de retenue. Après l’expiration de l’intervalle de retenue, le nœud principal précédent passe à l’état secondaire.
La configuration de l’intervalle d’attente empêche les basculements consécutifs de se produire pendant la durée de l’intervalle d’attente.
L’intervalle d’attente affecte les basculements manuels, ainsi que les basculements automatiques associés aux échecs de surveillance.
Le temps d’amortissement par défaut pour un groupe de redondance 0 est de 300 secondes (5 minutes) et peut être configuré jusqu’à 1800 secondes avec l’instruction hold-down-interval . Pour certaines configurations, telles que celles avec un grand nombre de routes ou d’interfaces logiques, l’intervalle par défaut ou l’intervalle configuré par l’utilisateur peut ne pas suffire. Dans ce cas, le système prolonge automatiquement le temps de mouillage par incréments de 60 secondes jusqu’à ce que le système soit prêt pour le basculement.
Les groupes x de redondance (groupes de redondance numérotés de 1 à 128) ont un temps d’amortissement par défaut de 1 seconde, avec une plage de 0 à 1800 secondes.
Sur les pare-feu SRX Series, les performances de basculement des clusters de châssis sont optimisées pour évoluer avec davantage d’interfaces logiques. Auparavant, lors du basculement de groupe de redondance, un arp gratuit (GARP) était envoyé par le processus jsrpd (Juniper Services Redundancy Protocol) exécuté dans le moteur de routage sur chaque interface logique pour diriger le trafic vers le nœud approprié. Avec la mise à l’échelle de l’interface logique, le moteur de routage devient le point de contrôle et le GARP est directement envoyé par l’unité de traitement des services (SPU).
Délai de basculement préemptif
Un groupe de redondance se trouve à tout moment dans l’état principal (actif) sur un nœud et dans l’état secondaire (sauvegarde) sur l’autre nœud.
Vous pouvez activer le comportement préemptif sur les deux nœuds d’un groupe de redondance et attribuer une valeur de priorité à chaque nœud du groupe de redondance. Le noeud du groupe de redondance avec la priorité configurée la plus élevée est initialement désigné comme principal du groupe, et l’autre noeud est initialement désigné comme secondaire dans le groupe de redondance.
Lorsqu’un groupe de redondance permute l’état de ses nœuds entre le primaire et le secondaire, il est possible qu’un échange d’état ultérieur de ses nœuds se reproduise peu de temps après le premier échange d’état. Ce changement rapide d’états se traduit par un battement des systèmes primaire et secondaire.
À partir de Junos OS version 17.4R1, un temporisateur de basculement est introduit sur les pare-feu SRX Series dans un cluster de châssis afin de limiter le basculement de l’état du groupe de redondance entre les nœuds secondaire et principal lors d’un basculement préventif.
Pour éviter le flottement, vous pouvez configurer les paramètres suivants :
-
Délai préemptif : le délai préemptif correspond à la durée pendant laquelle un groupe de redondance dans un état secondaire attend lorsque l’état principal est indisponible dans un basculement préemptif avant de passer à l’état principal. Ce temporisateur retarde le basculement immédiat pendant une période configurée (comprise entre 1 et 21 600 secondes).
-
Limite préemptive : la limite préemptive limite le nombre de basculements préemptifs (entre 1 et 50) au cours d’une période de préemption configurée, lorsque
preemptioncette option est activée pour un groupe de redondance. -
Période préemptive : période (1 à 1440 secondes) pendant laquelle la limite de préemption est appliquée, c’est-à-dire le nombre de basculements préemptifs configurés sont appliqués lorsque la préemption est activée pour un groupe de redondance.
Considérons le scénario suivant dans lequel vous avez configuré une période de préemption de 300 secondes et une limite de préemption de 50.
Lorsque la limite de préemption est configurée sur 50, le décompte commence à 0 et s’incrémente avec un premier basculement préemptif ; Ce processus se poursuit jusqu’à ce que le nombre atteigne la limite de préemption configurée, c’est-à-dire 50, avant l’expiration de la période de préemption. Lorsque la limite de préemption (50) est dépassée, vous devez réinitialiser manuellement le nombre de préemptations pour permettre aux basculements préemptifs de se produire à nouveau.
Lorsque vous avez configuré la période de préemption sur 300 secondes, et si la différence de temps entre le premier basculement préemptif et le basculement actuel a déjà dépassé 300 secondes et que la limite de préemption (50) n’est pas encore atteinte, la période de préemption est réinitialisée. Après la réinitialisation, le dernier basculement est considéré comme le premier basculement préemptif de la nouvelle période de préemption et le processus recommence.
Le délai préemptif peut être configuré indépendamment de la limite de basculement. La configuration du temporisateur préemptif ne modifie pas le comportement préemptif existant.
Cette amélioration permet à l’administrateur d’introduire un délai de basculement, ce qui peut réduire le nombre de basculements et améliorer l’état du réseau grâce à la réduction des oscillations actives/de veille au sein du groupe de redondance.
- Comprendre le passage de l’état primaire à l’état secondaire avec délai préemptif
- Configuration du temporisateur préemptif
Comprendre le passage de l’état primaire à l’état secondaire avec délai préemptif
Prenons l’exemple suivant, où un groupe de redondance, qui est principal sur le nœud 0, est prêt pour une transition préventive vers l’état secondaire lors d’un basculement. La priorité est attribuée à chaque noeud et l’option preemptive est également activée pour les noeuds.
La Figure 1 illustre la séquence des étapes de transition de l’état primaire à l’état secondaire lorsqu’un temporisateur de retard préemptif est configuré.
préemptif
-
Le noeud à l’état primaire est prêt pour la transition préventive vers l’état secondaire si l’option
preemptiveest configurée et que le noeud à l’état secondaire a la priorité sur le noeud à l’état primaire. Si le délai de préemption est configuré, le noeud de l’état primaire passe à l’état principal-préempt-hold . Si le délai préemptif n’est pas configuré, le passage instantané à l’état secondaire se produit. -
Le noeud est dans l’état de préemption de mise en attente principale en attendant l’expiration du temporisateur de délai préemptif. Le temporisateur préemptif est vérifié et la transition est maintenue jusqu’à l’expiration du minuteur. Le noeud principal reste dans l’état principal-préempt-hold jusqu’à l’expiration du minuteur, avant de passer à l’état secondaire.
-
Le noeud passe de l’état de préemption-attente primaire à l’état de maintien secondaire, puis à l’état secondaire.
-
Le noeud reste dans l’état de maintien secondaire pendant la durée par défaut (1 seconde) ou la durée configurée (un minimum de 300 secondes), puis le noeud passe à l’état secondaire.
Si la configuration de votre cluster de châssis rencontre un nombre anormal de volets, vous devez vérifier vos temporisateurs de liaison et de surveillance pour vous assurer qu’ils sont correctement définis. Soyez prudent lorsque vous définissez des minuteurs sur des réseaux à latence élevée pour éviter d’obtenir des faux positifs.
Configuration du temporisateur préemptif
Cette rubrique explique comment configurer la temporisation sur les pare-feu SRX Series dans un cluster de châssis. Des basculements consécutifs de groupes de redondance qui se produisent trop rapidement peuvent entraîner un comportement imprévisible d’un cluster de châssis. La configuration du temporisateur et de la limite de taux de basculement retarde le basculement immédiat pendant une période configurée.
Pour configurer le délai de préemption et la limite de taux de basculement entre les basculements de groupe de redondance :
-
Activez le basculement préemptif pour un groupe de redondance.
Vous pouvez régler la minuterie de retard entre 1 et 21 600 secondes. La valeur par défaut est 1 seconde.
{primary:node1} [edit chassis cluster redundancy-group number preempt] user@host# set delay interval -
Définissez une limite pour le basculement préventif.
Vous pouvez définir un nombre maximal de basculements préemptifs compris entre 1 et 50 et une période pendant laquelle la limite est appliquée entre 1 et 1440 secondes.
{primary:node1}[edit chassis cluster redundancy-group number preempt] user@host# set limit limit period period
Dans l’exemple suivant, vous définissez le temporisateur de préemption sur 300 secondes et la limite de préemption sur 10 pour une période de préemption de 600 secondes. En d’autres termes, cette configuration retarde le basculement immédiat de 300 secondes et limite un maximum de 10 basculements préventifs sur une durée de 600 secondes.
{primary:node1}[edit chassis cluster redundancy-group 1 preempt]
user@host# set delay 300 limit 10 period 600
Vous pouvez utiliser la clear chassis clusters preempt-count commande pour effacer le compteur de basculement de préemption pour tous les groupes de redondance. Lorsqu’une limite de préemption est configurée, le compteur démarre par un premier basculement préemptif et le nombre est réduit ; Ce processus se poursuit jusqu’à ce que le nombre atteigne zéro avant l’expiration du minuteur. Vous pouvez utiliser cette commande pour effacer le compteur de basculement de préemption et le réinitialiser pour qu’il redémarre.
Voir aussi
Comprendre la redondance des clusters de châssis Basculement manuel des groupes
Vous pouvez lancer manuellement un basculement du groupe de redondance x (groupes de redondance numérotés de 1 à 128). Un basculement manuel s’applique jusqu’à ce qu’un événement de restauration automatique se produise.
Par exemple, supposons que vous effectuiez manuellement un basculement du groupe de redondance 1 du nœud 0 au nœud 1. Dans ce cas, une interface surveillée par le groupe de redondance 1 tombe en panne, ce qui fait tomber la valeur seuil du nouveau groupe de redondance principal à zéro. Cet événement est considéré comme un événement de restauration automatique et le système restitue le contrôle au groupe de redondance d’origine.
Vous pouvez également lancer manuellement un basculement du groupe de redondance 0 si vous souhaitez remplacer le nœud principal par le groupe de redondance 0. Vous ne pouvez pas activer la préemption pour le groupe de redondance 0.
Si la préemption est ajoutée à une configuration de groupe de redondance, l’appareil ayant la priorité la plus élevée dans le groupe peut initier un basculement pour devenir principal. Par défaut, la préemption est désactivée. Pour plus d’informations sur la préemption, reportez-vous à la section préemption (cluster de châssis).
Lorsque vous effectuez un basculement manuel pour le groupe de redondance 0, le nœud de l’état principal passe à l’état de mise en attente secondaire. Le noeud reste à l’état de maintien secondaire pendant la durée par défaut ou configurée (au moins 300 secondes), puis passe à l’état secondaire.
Les transitions d’état dans les cas où un nœud est dans l’état de mise en attente secondaire et que l’autre nœud redémarre, ou que la connexion de lien de contrôle ou de liaison de structure est perdue pour ce nœud, sont décrites comme suit :
Redémarrer le cas : le noeud dans l’état de conservation secondaire passe à l’état principal ; l’autre nœud meurt (inactif).
Cas de défaillance de la liaison de contrôle : le nœud dans l’état de conservation secondaire passe à l’état non éligible, puis à l’état désactivé ; l’autre nœud passe à l’état primaire.
Cas de défaillance de la liaison de structure : le nœud dans l’état de conservation secondaire passe directement à l’état non éligible.
À partir de Junos OS version 12.1X46-D20 et de Junos OS version 17.3R1, la surveillance de la structure est activée par défaut. Avec cette activation, le nœud passe directement à l’état inéligible en cas de défaillance de la liaison de structure.
À partir de Junos OS version 12.1X47-D10 et Junos OS version 17.3R1, la surveillance de la structure est activée par défaut. Avec cette activation, le nœud passe directement à l’état inéligible en cas de défaillance de la liaison de structure.
Gardez à l’esprit que lors d’une mise à niveau logicielle en service (ISSU), les transitions décrites ici ne peuvent pas se produire. Au lieu de cela, l’autre nœud (principal) passe directement à l’état secondaire, car les versions de Juniper Networks antérieures à la version 10.0 n’interprètent pas l’état de mise en attente secondaire. Lorsque vous démarrez un ISSU, si l’un des nœuds a un ou plusieurs groupes de redondance dans l’état de conservation secondaire, vous devez attendre qu’ils passent à l’état secondaire avant de pouvoir effectuer des basculements manuels pour que tous les groupes de redondance soient principaux sur un nœud.
Soyez prudent et judicieux dans votre utilisation des basculements manuels du groupe de redondance 0. Un basculement du groupe de redondance 0 implique un basculement du moteur de routage, auquel cas tous les processus s’exécutant sur le nœud principal sont tués, puis générés sur le nouveau moteur de routage principal. Ce basculement peut entraîner une perte d’état, tel que l’état de routage, et dégrader les performances en introduisant une perte d’attrition du système.
Dans certaines versions de Junos OS, pour les groupes xde redondance, il est possible d’effectuer un basculement manuel sur un nœud dont la priorité est 0. Nous vous recommandons d’utiliser la show chassis cluster status commande pour vérifier les priorités des nœuds du groupe de redondance avant d’effectuer le basculement manuel. Toutefois, à partir de Junos OS versions 12.1X44-D25, 12.1X45-D20, 12.1X46-D10 et 12.1X47-D10 et versions ultérieures, le mécanisme de vérification de l’état de préparation pour le basculement manuel est amélioré pour être plus restrictif, de sorte que vous ne pouvez pas définir le basculement manuel vers un nœud d’un groupe de redondance qui a une priorité 0. Cette amélioration empêche l’abandon inopiné du trafic en raison d’une tentative de basculement vers un nœud de priorité 0, qui n’est pas prêt à accepter le trafic.
Lancement d’un basculement manuel de groupe de redondance de cluster de châssis
Avant de commencer, effectuez les tâches suivantes :
Vous pouvez lancer un basculement manuellement à l’aide de la request commande. Un basculement manuel porte la priorité du groupe de redondance pour ce membre à 255.
Soyez prudent et judicieux dans votre utilisation des basculements manuels du groupe de redondance 0. Un basculement du groupe de redondance 0 implique un basculement du moteur de routage (RE), auquel cas tous les processus s’exécutant sur le nœud principal sont tués, puis générés sur le nouveau moteur de routage principal (RE). Ce basculement peut entraîner une perte d’état, tel que l’état de routage, et dégrader les performances en introduisant une perte d’attrition du système.
Si vous débranchez le cordon d’alimentation et maintenez le bouton d’alimentation enfoncé pour lancer un basculement du groupe de redondance du cluster de châssis, vous risquez d’avoir un comportement imprévisible.
Pour les groupes x de redondance (groupes de redondance numérotés de 1 à 128), il est possible d’effectuer un basculement manuel sur un nœud dont la priorité est 0. Nous vous recommandons de vérifier les priorités des nœuds du groupe de redondance avant d’effectuer le basculement manuel.
Utilisez la show commande pour afficher l’état des noeuds dans le cluster :
{primary:node0}
user@host> show chassis cluster status redundancy-group 0
Cluster ID: 9
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 1
node0 254 primary no no
node1 1 secondary no no
La sortie de cette commande indique que le noeud 0 est principal.
Utilisez la commande pour déclencher un basculement et rendre le request nœud 1 principal :
{primary:node0}
user@host> request chassis cluster failover redundancy-group 0 node 1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Initiated manual failover for redundancy group 0
Utilisez la show commande pour afficher le nouvel état des noeuds dans le cluster :
{secondary-hold:node0}
user@host> show chassis cluster status redundancy-group 0
Cluster ID: 9
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 2
node0 254 secondary-hold no yes
node1 255 primary no yes
La sortie de cette commande indique que le noeud 1 est maintenant principal et que le noeud 0 est à l’état de maintien secondaire. Au bout de 5 minutes, le nœud 0 passe à l’état secondaire.
Vous pouvez réinitialiser le basculement pour les groupes de redondance à l’aide de la request commande. Cette modification est propagée dans l’ensemble du cluster.
{secondary-hold:node0}
user@host> request chassis cluster failover reset redundancy-group 0
node0:
--------------------------------------------------------------------------
No reset required for redundancy group 0.
node1:
--------------------------------------------------------------------------
Successfully reset manual failover for redundancy group 0
Vous ne pouvez pas déclencher un basculement consécutif avant l’expiration de l’intervalle de 5 minutes.
{secondary-hold:node0}
user@host> request chassis cluster failover redundancy-group 0 node 0
node0:
--------------------------------------------------------------------------
Manual failover is not permitted as redundancy-group 0 on node0 is in secondary-hold state.
Utilisez la show commande pour afficher le nouvel état des noeuds dans le cluster :
{secondary-hold:node0}
user@host> show chassis cluster status redundancy-group 0
Cluster ID: 9
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 2
node0 254 secondary-hold no no
node1 1 primary no no
La sortie de cette commande indique qu’aucun basculement consécutif ne s’est produit pour l’un ou l’autre des nœuds.
Après avoir effectué un basculement manuel, vous devez exécuter la reset failover commande avant de demander un autre basculement.
Lorsque le noeud primaire échoue et revient, l’élection du noeud primaire se fait sur la base de critères réguliers (priorité et préemption).
Exemple : configuration d’un cluster de châssis avec un temps d’amortissement entre les basculements de groupes de redondance consécutifs
Cet exemple montre comment configurer le temps d’amortissement entre les basculements consécutifs de groupes de redondance pour un cluster de châssis. Des basculements consécutifs de groupes de redondance qui se produisent trop rapidement peuvent entraîner un comportement imprévisible d’un cluster de châssis.
Exigences
Avant de commencer :
Comprendre le basculement des groupes de redondance. Reportez-vous à la section Présentation de la redondance du cluster de châssis, basculement de groupe .
Comprendre le basculement manuel des groupes de redondance. Reportez-vous à la section Présentation du basculement manuel des groupes de redondance de clusters de châssis.
Aperçu
Le temps d’amortissement est l’intervalle minimal autorisé entre les basculements consécutifs pour un groupe de redondance. Cet intervalle affecte les basculements manuels et les basculements automatiques provoqués par des défaillances de surveillance des interfaces.
Dans cet exemple, vous définissez l’intervalle minimal autorisé entre les basculements consécutifs sur 420 secondes pour le groupe de redondance 0.
Configuration
Procédure
Procédure étape par étape
Pour configurer le temps d’amortissement entre les basculements de groupes de redondance consécutifs :
Définissez le temps d’amortissement pour le groupe de redondance.
{primary:node0}[edit] user@host# set chassis cluster redundancy-group 0 hold-down-interval 420Si vous avez terminé de configurer l’appareil, validez la configuration.
{primary:node0}[edit] user@host# commit
Comprendre les interruptions de basculement SNMP pour la redondance de châssis Basculement de groupe de clusters
La mise en cluster de châssis prend en charge les interruptions SNMP, qui se déclenchent en cas de basculement d’un groupe de redondance.
Le message d’interruption peut vous aider à résoudre les problèmes de basculement. Il contient les informations suivantes :
L’ID de cluster et l’ID de nœud
La raison du basculement
Le groupe de redondance impliqué dans le basculement
État précédent et état actuel du groupe de redondance
Il s’agit des différents états dans lesquels un cluster peut se trouver à un instant donné : en attente, principal, en attente secondaire, secondaire, non éligible et désactivé. Des interruptions sont générées pour les transitions d’état suivantes (seule une transition à partir d’un état de maintien ne déclenche pas d’interruption) :
Primaire < > secondaire
Primaire –> Attente secondaire
maintien-secondaire –> secondaire
Secondaire – > non éligible
Inéligible –> désactivé
Inéligible – > primaire
Secondaire –> désactivé
Une transition peut être déclenchée en raison de n’importe quel événement, tel qu’une surveillance d’interface, une surveillance SPU, des défaillances et des basculements manuels.
L’interruption est transférée sur la liaison de contrôle si l’interface sortante se trouve sur un nœud différent de celui du moteur de routage qui génère l’interruption.
Vous pouvez spécifier la génération d’un journal de suivi en définissant l’instruction traceoptions flag snmp .
Vérification de l’état de basculement du cluster de châssis
But
Affichez l’état de basculement d’un cluster de châssis.
Action
Dans l’interface de ligne de commande, entrez la show chassis cluster status commande :
{primary:node1}
user@host> show chassis cluster status
Cluster ID: 3
Node name Priority Status Preempt Manual failover
Redundancy-group: 0, Failover count: 1
node0 254 primary no no
node1 2 secondary no no
Redundancy-group: 1, Failover count: 1
node0 254 primary no no
node1 1 secondary no no
{primary:node1}
user@host> show chassis cluster status
Cluster ID: 15
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 5
node0 200 primary no no
node1 0 lost n/a n/a
Redundancy group: 1 , Failover count: 41
node0 101 primary no no
node1 0 lost n/a n/a
{primary:node1}
user@host> show chassis cluster status
Cluster ID: 15
Node Priority Status Preempt Manual failover
Redundancy group: 0 , Failover count: 5
node0 200 primary no no
node1 0 unavailable n/a n/a
Redundancy group: 1 , Failover count: 41
node0 101 primary no no
node1 0 unavailable n/a n/a
Effacement de l’état de basculement du cluster de châssis
Pour effacer l’état de basculement d’un cluster de châssis, entrez la clear chassis cluster failover-count commande à partir de l’interface de ligne de commande :
{primary:node1}
user@host> clear chassis cluster failover-count
Cleared failover-count for all redundancy-groups
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.