Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Présentation du cluster de châssis

Un cluster de châssis offre une haute disponibilité sur les pare-feu SRX Series où deux équipements fonctionnent comme un seul équipement. Le cluster de châssis inclut la synchronisation des fichiers de configuration et les états de session d’exécution dynamique entre les pare-feu SRX Series, qui font partie de la configuration du cluster de châssis.

Présentation du cluster de châssis

Junos OS offre une haute disponibilité sur le pare-feu SRX Series grâce au clustering de châssis. Les pare-feu SRX Series peuvent être configurés pour fonctionner en mode cluster, où deux équipements peuvent être connectés ensemble et configurés pour fonctionner comme un seul nœud, offrant ainsi une redondance des équipements, des interfaces et des niveaux de service.

Pour les pare-feu SRX Series, qui agissent comme des pare-feu dynamiques, il est important de préserver l’état du trafic entre deux équipements. Dans une configuration de cluster de châssis, en cas de défaillance, la persistance des sessions est requise pour que les sessions établies ne soient pas abandonnées même si l’équipement défaillant transférait le trafic.

Lorsqu’ils sont configurés en tant que cluster de châssis, les deux nœuds se sauvegardent, l’un faisant office de périphérique principal et l’autre de périphérique secondaire, garantissant ainsi un basculement dynamique des processus et services en cas de défaillance du système ou du matériel. Si l’équipement principal tombe en panne, l’équipement secondaire prend en charge le traitement du trafic. Les nœuds du cluster sont connectés ensemble par deux liens appelés lien de contrôle et lien de structure, et les périphériques d’un cluster de châssis synchronisent les états de session de configuration, de noyau et PFE dans l’ensemble du cluster pour faciliter la haute disponibilité, le basculement des services dynamiques et l’équilibrage de charge.

Aucune licence distincte n’est requise pour activer le cluster de châssis. Toutefois, certaines fonctionnalités du logiciel Junos OS nécessitent une licence pour l’activer. Pour plus d’informations, reportez-vous aux sections Présentation des exigences relatives aux licences des clusters de châssis, Installation de licences sur les équipements SRX Series d’un cluster de châssis et Vérification des licences sur un équipement SRX Series dans un cluster de châssis. Reportez-vous au Guide des licences Juniper pour obtenir des informations générales sur la gestion des licences. Pour plus de détails, reportez-vous aux fiches techniques des produits sur les passerelles de services SRX Series, ou contactez votre équipe de compte Juniper ou votre partenaire Juniper.

Avantages de Chassis Cluster

  • Prévient les défaillances d’un seul appareil qui entraînent une perte de connectivité.

  • Assure une haute disponibilité entre les appareils lors de la connexion de liens de succursales et de sites distants à des bureaux d’entreprise plus importants. En tirant parti de la fonctionnalité de cluster de châssis, les entreprises peuvent garantir la connectivité en cas de défaillance d’un équipement ou d’une liaison.

Fonctionnalité de cluster de châssis

La fonctionnalité du cluster de châssis comprend :

  • Architecture système résiliente, avec un seul plan de contrôle actif pour l’ensemble du cluster et plusieurs moteurs de transfert de paquets. Cette architecture présente une vue unique du cluster.

  • Synchronisation des états de configuration et d’exécution dynamique entre les nœuds d’un cluster.

  • Surveillance des interfaces physiques et basculement si les paramètres de défaillance dépassent un seuil configuré.

Modes de cluster de châssis

Un cluster de châssis peut être configuré en mode actif/actif ou actif/passif.

  • Active/passive mode: en mode actif/passif, le trafic de transit passe par le nœud principal alors que le nœud de secours n’est utilisé qu’en cas de panne. En cas de défaillance, l’équipement de sauvegarde devient principal et prend en charge toutes les tâches de transfert.

  • Active/active mode: en mode actif/actif, le trafic de transit passe constamment par les deux nœuds du cluster.

Comment fonctionne le clustering de châssis ?

Les ports de contrôle sur les nœuds respectifs sont connectés pour former un plan de contrôle qui synchronise la configuration et l’état du noyau pour faciliter la haute disponibilité des interfaces et des services.

Le plan de données sur les nœuds respectifs est connecté sur les ports de fabric pour former un plan de données unifié.

Lors de la création d’un cluster de châssis, les ports de contrôle sur les nœuds respectifs sont connectés pour former un plan de contrôle qui synchronise la configuration et l’état du noyau pour faciliter la haute disponibilité des interfaces et des services.

De même, le plan de données sur les nœuds respectifs est connecté sur les ports de fabric pour former un plan de données unifié.

Le lien fabric permet de gérer le traitement des flux entre nœuds et la redondance des sessions.

Le logiciel du plan de contrôle fonctionne en mode actif ou de secours. Lorsqu’ils sont configurés en tant que cluster de châssis, les deux nœuds se sauvegardent, l’un faisant office de périphérique principal et l’autre de périphérique secondaire, garantissant ainsi un basculement dynamique des processus et services en cas de défaillance du système ou du matériel. Si l’équipement principal tombe en panne, l’équipement secondaire prend en charge le traitement du trafic.

Le logiciel du plan de données fonctionne en mode actif/actif. Dans un cluster de châssis, les informations de session sont mises à jour lorsque le trafic traverse l’un ou l’autre équipement, et ces informations sont transmises entre les nœuds via le lien de structure pour garantir que les sessions établies ne sont pas abandonnées lors d’un basculement. En mode actif/actif, il est possible que le trafic pénètre dans le cluster sur un nœud et sorte de l’autre nœud. Lorsqu’un appareil rejoint un cluster, il devient un nœud de ce cluster. À l’exception des paramètres de nœud uniques et des adresses IP de gestion, les nœuds d’un cluster partagent la même configuration.

À tout moment, un cluster peut se trouver dans l’un des états suivants : attente, principale, secondaire, secondaire, inéligible et désactivée. Une transition d’état peut être déclenchée en raison de n’importe quel événement, tel que la surveillance d’interface, la surveillance de l’USU, les défaillances et les basculements manuels.

Prise en charge du clustering IPv6

Les pare-feu SRX Series exécutant IP version 6 (IPv6) peuvent être déployés dans des configurations de clusters de châssis actif/actif (basculement), en plus de la prise en charge existante des configurations de clusters de châssis actif/passif (basculement). Une interface peut être configurée avec une adresse IPv4, une adresse IPv6 ou les deux. Les entrées du carnet d’adresses peuvent inclure n’importe quelle combinaison d’adresses IPv4, d’adresses IPv6 et de noms DNS (Domain Name System).

Le cluster de châssis prend en charge les tunnels GRE (Generic Routing Encapsulation) utilisés pour acheminer le trafic IPv4/IPv6 encapsulé au moyen d’une interface interne, gr-0/0/0. Cette interface est créée par Junos OS au démarrage du système et est utilisée uniquement pour le traitement des tunnels GRE. Consultez le Guide de l’utilisateur des interfaces pour les périphériques de sécurité.

Limitations des clusters de châssis

Les pare-feu SRX Series présentent les limitations suivantes pour les clusters de châssis :

Chassis Cluster

  • Le VPN de groupe n’est pas pris en charge.

  • Tous les pare-feu SRX Series d’un cluster de châssis prennent en charge la surveillance des flux pour les versions 5 et 8. Toutefois, la surveillance de flux pour la version 9 n’est pas prise en charge.

  • Lorsqu’un pare-feu SRX Series fonctionne en mode cluster de châssis et rencontre un problème d’accès à la puce IA dans un SPC ou une carte d’E/S (IOC), une alarme FPC mineure est activée pour déclencher le basculement du groupe de redondance.

  • Sur les appareils SRX5400, SRX5600 et SRX5800, les données statistiques d’écran ne peuvent être collectées que sur l’appareil principal.

  • Sur les équipements SRX4600, SRX5400, SRX5600 et SRX5800, dans les configurations de clusters de châssis de grande taille, si plus de 1000 interfaces logiques sont utilisées, il est recommandé d’augmenter le temps d’attente par défaut par rapport au temps d’attente par défaut avant de déclencher le basculement. Dans une implémentation à pleine capacité, nous recommandons d’augmenter l’attente à 8 secondes en modifiant heartbeat-threshold les valeurs de heartbeat-interval la [edit chassis cluster] hiérarchie.

    Le produit des heartbeat-threshold valeurs et heartbeat-interval définit le temps avant le basculement. Les valeurs par défaut (heartbeat-threshold de 3 battements et heartbeat-interval de 1000 millisecondes) produisent un temps d’attente de 3 secondes.

    Pour modifier le temps d’attente, modifiez les valeurs des options afin que le produit soit égal au paramètre souhaité. Par exemple, définir la valeur sur 8 et conserver la heartbeat-threshold valeur par défaut pour ( heartbeat-interval 1000 millisecondes) donne un temps d’attente de 8 secondes. De même, définir le sur 4 et le heartbeat-threshold heartbeat-interval à 2000 millisecondes donne également un temps d’attente de 8 secondes.

  • Sur les équipements SRX5400, SRX5600 et SRX5800, les configurations à huit files d’attente ne sont pas reflétées sur l’interface du cluster de châssis.

Flow and Processing

  • Si vous utilisez la capture de paquets sur les interfaces reth, deux fichiers sont créés, l’un pour les paquets entrants et l’autre pour les paquets sortants en fonction du nom de l’interface reth. Ces fichiers peuvent être fusionnés en dehors de l’appareil à l’aide d’outils tels que Wireshark ou Mergecap.

  • Si vous utilisez la mise en miroir de ports sur les interfaces reth, l’interface reth ne peut pas être configurée comme interface de sortie. Vous devez utiliser une interface physique comme interface de sortie. Si vous configurez l’interface reth en tant qu’interface de sortie à l’aide de la set forwarding-options port-mirroring family inet output commande, le message d’erreur suivant s’affiche.

    Port-mirroring configuration error. Interface type in reth1.0 is not valid for port-mirroring or next-hop-group config

  • Lorsqu’un pare-feu SRX Series fonctionne en mode cluster de châssis et rencontre une puce IA (la puce IA fait partie des SPC1 et IOC1 de Juniper. Il a un impact direct sur le plan de contrôle SPC1/IOC1) problème d’accès dans un SPC ou une carte d’E/S (IOC), une alarme FPC mineure est activée pour déclencher le basculement du groupe de redondance.

  • Sur les pare-feu SRX Series d’un cluster de châssis, lorsque deux systèmes logiques sont configurés, la limite de mise à l’échelle dépasse 13 000, ce qui est très proche de la limite d’échelle standard de 15 000, et un temps de convergence de 5 minutes en résulte. Ce problème se produit car l’apprentissage d’itinéraire multicast prend plus de temps lorsque le nombre d’itinéraires est augmenté.

  • Sur les équipements SRX4600, SRX5400, SRX5600 et SRX5800 d’un cluster de châssis, si le nœud principal exécutant le processus LACP (lacpd) subit un redémarrage gracieux ou malgracieux, le lacpd sur le nouveau nœud principal peut prendre quelques secondes pour démarrer ou réinitialiser les interfaces et les machines d’état afin de récupérer des résultats synchrones inattendus. En outre, lors du basculement, lorsque le système traite des paquets de trafic ou des paquets internes hautement prioritaires (suppression de sessions ou rétablissement de tâches), les paquets LACP de priorité moyenne de l’homologue (commutateur) sont repoussés dans les files d’attente, ce qui entraîne des retards supplémentaires.

La surveillance des flux est prise en charge sur les appareils SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500, SRX1600 et SRX2300.

Installation and Upgrade

  • Pour les périphériques SRX300, SRX320, SRX340, SRX345 et SRX380, le paramètre n’est reboot pas disponible, car les périphériques d’un cluster sont automatiquement redémarrés après une mise à niveau de cluster intrabande (ICU).

Interfaces

  • Sur l’interface lsq-0/0/0, les services de liaison MLPPP, MLFR et CRTP ne sont pas pris en charge.

  • Sur l’interface lt-0/0/0, CoS for RPM n’est pas pris en charge.

  • L’interface du numéroteur 3G n’est pas prise en charge.

  • La mise en file d’attente sur l’interface ae n’est pas prise en charge.

Layer 2 Switching

  • Lors du basculement du pare-feu SRX Series, les points d’accès du commutateur de couche 2 redémarrent et tous les clients sans fil perdent la connectivité pendant 4 à 6 minutes.

MIBs

  • La MIB Chassis Cluster n’est pas prise en charge.

Monitoring

  • Le nombre maximal d’adresses IP de surveillance pouvant être configurées par cluster est de 64 pour les appareils SRX300, SRX320, SRX340, SRX345, SRX380, SRX1500, SRX1600 et SRX2300.

  • Sur les périphériques SRX300, SRX320, SRX340, SRX345, SRX380 SRX1500,SRX1600 et SRX2300, les journaux ne peuvent pas être envoyés à NSM lorsque la journalisation est configurée en mode flux. Les journaux ne peuvent pas être envoyés car le journal de sécurité ne prend pas en charge la configuration de l’adresse IP source pour l’interface fxp0 et la destination du journal de sécurité en mode flux ne peut pas être acheminée via l’interface fxp0. Cela implique que vous ne pouvez pas configurer le serveur de journaux de sécurité dans le même sous-réseau que l’interface fxp0 et acheminer le serveur de journaux via l’interface fxp0.

IPv6

  • La surveillance des adresses IP des groupes de redondance n’est pas prise en charge pour les destinations IPv6.

GPRS

  • Sur les appareils SRX5400, SRX5600 et SRX5800, un filtre APN ou IMSI doit être limité à 600 pour chaque profil GTP. Le nombre de filtres est directement proportionnel au nombre d’entrées de préfixe IMSI. Par exemple, si un APN est configuré avec deux entrées de préfixe IMSI, le nombre de filtres est de deux.

MIBs

  • La MIB Chassis Cluster n’est pas prise en charge.

Nonstop Active Routing (NSR)

  • NSR peut préserver les informations de l’interface et du noyau et enregistre les informations du protocole de routage en exécutant le processus RPD (Routing Protocol Process) sur le moteur de routage de secours. Cependant, la plupart des plates-formes SRX ne prennent pas encore en charge NSR. Donc, sur le nœud secondaire, il n’y a pas de démon RPD existant. Après le basculement RG0, le nouveau maître RG0 aura un nouveau RPD et devra renégocier avec le périphérique homologue. Seules SRX5000 plates-formes avec la version 17.4R2 ou supérieure peuvent prendre en charge NSR.

À partir de Junos OS version 12.1X45-D10, les fonctions d’échantillonnage telles que la surveillance des flux, la capture de paquets et la mise en miroir des ports sont prises en charge sur les interfaces reth.

Tableau de l’historique des versions
Libération
Description
12,1 X 45
À partir de Junos OS version 12.1X45-D10, les fonctions d’échantillonnage telles que la surveillance des flux, la capture de paquets et la mise en miroir des ports sont prises en charge sur les interfaces reth.