Présentation de la base de données de configuration éphémère
La base de données éphémère est une base de données de configuration alternative qui fournit une interface de programmation rapide pour effectuer des mises à jour de configuration sur les périphériques exécutant Junos OS et Junos OS Evolved. La base de données éphémère permet aux applications Juniper Extension Toolkit (JET) et aux applications clientes NETCONF et Junos XML Management Protocol de charger et valider simultanément les modifications de configuration sur un équipement, et ce, avec un débit nettement supérieur à celui de la validation des données dans la base de données de configuration candidate.
Les sections suivantes abordent les différents aspects de la base de données de configuration éphémère.
Avantages de la base de données de configuration éphémère
- Permet à plusieurs applications clientes de configurer simultanément un périphérique en chargeant et validant les données dans des instances distinctes de la base de données éphémère
- Permet un provisionnement et des changements de configuration rapides dans des environnements dynamiques qui nécessitent des temps de validation rapides
Vue d’ensemble de la base de données à configuration éphémère
Lors de la gestion des équipements Junos, la méthode recommandée et la plus courante consiste à modifier et valider la configuration candidate, qui correspond à une base de données de configuration persistante (statique). L’opération de validation standard gère les groupes de configuration, les macros et les scripts de validation ; effectue des vérifications de validation pour valider la syntaxe et la sémantique de la configuration ; et stocke des copies des configurations validées. Le modèle de validation standard est robuste, car il évite les erreurs de configuration et vous permet de revenir à une configuration précédemment validée. Toutefois, dans certains cas, l’opération de validation peut consommer beaucoup de temps et de ressources sur l’appareil.
Les applications JET et les applications clientes de protocole XML NETCONF et Junos peuvent également configurer la base de données éphémère. La base de données éphémère est une base de données de configuration alternative qui fournit une couche de configuration distincte de la base de données de configuration candidate et des couches de configuration des autres applications clientes. Le modèle de validation éphémère permet aux équipements Junos de valider et de fusionner les modifications de plusieurs clients et d’exécuter les validations avec un débit nettement plus élevé que lors de la validation des données dans la base de données de configuration candidate. Ainsi, la base de données éphémère est avantageuse dans les environnements dynamiques où un provisionnement rapide et des changements de configuration rapides sont nécessaires, comme dans les grands centres de données.
Une opération de validation sur la base de données éphémère nécessite moins de temps que la même opération sur la base de données statique, car la base de données éphémère n’est pas soumise à la même validation que celle requise dans la base de données statique. Par conséquent, le modèle de commit éphémère offre de meilleures performances que le modèle de commit standard, mais au détriment de certaines des fonctionnalités les plus robustes présentes dans le modèle standard. Le modèle de commit éphémère présente les restrictions suivantes :
-
La syntaxe des données de configuration est validée, mais la sémantique des données de configuration ne l’est pas.
-
Certaines instructions de configuration ne sont pas prises en charge, comme décrit dans la section Instructions de configuration non prises en charge dans la base de données de configuration éphémère.
-
Les groupes de configuration et les plages d’interfaces ne sont pas traités.
-
Les macros, les scripts de commit et les scripts de traduction ne sont pas traités.
-
Les versions précédentes de la configuration éphémère ne sont pas archivées.
-
Les données de configuration éphémères ne sont pas affichées dans la configuration normale à l’aide des commandes show standard.
-
Les données de configuration éphémères ne sont pas conservées lorsque vous :
-
Installez un package qui nécessite de reconstruire le schéma Junos, par exemple, un package OpenConfig ou YANG.
-
Effectuez une mise à niveau logicielle ou une mise à niveau logicielle unifiée en service (ISSU).
-
Redémarrez ou redémarrez l’appareil.
-
Nous vous recommandons vivement de faire preuve de prudence lors de l’utilisation de la base de données de configuration éphémère, car la validation de données de configuration non valides peut corrompre la base de données éphémère, ce qui peut entraîner le redémarrage, voire le blocage des processus Junos, et entraîner une perturbation du système ou du réseau.
Les équipements Junos valident la syntaxe, mais pas la sémantique, ou les contraintes, des données de configuration validées dans la base de données éphémère. Par exemple, si la configuration fait référence à une stratégie de routage non définie, la configuration peut être syntaxiquement correcte, mais elle est sémantiquement incorrecte. Dans ce cas, le modèle de validation standard génère une erreur de validation, mais pas le modèle de validation éphémère. Par conséquent, il est impératif de valider toutes les données de configuration avant de les valider dans la base de données éphémère. Si vous validez des données de configuration non valides ou qui entraînent une perturbation indésirable du réseau, vous devez supprimer les données problématiques de la base de données ou, si nécessaire, redémarrer l’équipement, ce qui supprime toutes les données de configuration éphémères.
La base de données de configuration éphémère stocke les informations de version internes en plus des données de configuration. Par conséquent, la taille de la base de données de configuration éphémère est toujours supérieure à celle de la base de données de configuration statique pour les mêmes données de configuration, et la plupart des opérations sur la base de données éphémère, qu’il s’agisse d’ajouts, de modifications ou de suppressions, augmentent la taille de la base de données.
Lorsque vous utilisez la base de données de configuration éphémère, les opérations de validation sur la base de données de configuration statique peuvent prendre plus de temps, car des opérations supplémentaires doivent être effectuées pour fusionner les données de configuration statiques et éphémères.
Instances de base de données éphémères
Les équipements Junos fournissent une instance de base de données éphémère par défaut, qui est automatiquement activée, ainsi que la possibilité d’activer des instances définies par l’utilisateur de la base de données de configuration éphémère. Les applications JET et les applications clientes du protocole XML NETCONF et Junos peuvent charger et valider simultanément des données dans des instances distinctes de la base de données éphémère. La configuration active de l’appareil est une vue fusionnée des bases de données de configuration statique et éphémère.
À partir de Junos OS version 18.2R1, Junos OS prend en charge la configuration de jusqu’à sept instances définies par l’utilisateur de la base de données de configuration éphémère. Dans les versions antérieures, vous pouviez configurer jusqu’à huit instances définies par l’utilisateur. Junos OS Evolved prend en charge la configuration de huit instances définies par l’utilisateur.
Les instances de base de données éphémères sont utiles dans les scénarios où plusieurs applications clientes peuvent avoir besoin de mettre à jour simultanément la configuration d’un équipement, par exemple lorsque deux contrôleurs SDN ou plus transmettent simultanément des données de configuration au même équipement. Dans le modèle de commit standard, un contrôleur peut avoir un verrou exclusif sur la configuration candidate, empêchant ainsi l’autre contrôleur de la modifier. En utilisant des instances éphémères distinctes, les contrôleurs peuvent déployer les modifications en même temps.
En plus de la base de données de configuration statique, les applications peuvent charger et valider simultanément des données dans différentes instances de base de données éphémères. Cependant, l’équipement traite les validations de manière séquentielle. Par conséquent, la validation dans une base de données spécifique peut être retardée, en fonction de l’ordre de traitement.
Les processus Junos lisent les données de configuration à partir de la base de données de configuration statique et de la base de données de configuration éphémère. Lorsqu’une ou plusieurs instances de base de données éphémères sont utilisées et qu’il existe des données en conflit, les instructions d’une base de données avec une priorité plus élevée remplacent les instructions d’une base de données avec une priorité inférieure. La priorité de la base de données, de la plus élevée à la plus basse, est la suivante :
-
Instructions dans une instance définie par l’utilisateur de la base de données de configuration éphémère.
S’il existe plusieurs instances éphémères définies par l’utilisateur, la priorité est déterminée par l’ordre dans lequel les instances sont configurées au niveau de la hiérarchie, de la priorité la plus élevée à la
[edit system configuration-database ephemeral]plus faible. -
Instructions dans l’instance de base de données éphémère par défaut.
-
Instructions dans la base de données de configuration statique.
Prenons l’exemple de la configuration suivante :
system {
configuration-database {
ephemeral {
instance 1;
instance 2;
}
}
}
La figure 1 illustre l’ordre de priorité des instances de base de données éphémères et de la base de données de configuration statique (validée). Dans cet exemple, l’instance de base de données éphémère 1 a la priorité la plus élevée, suivie de l’instance de base de données éphémère 2, puis de l’instance de base de données éphémère par défaut et enfin de la base de données de configuration statique.
de base de données éphémères
Modèle de validation général de base de données éphémère
Les applications JET et les applications clientes du protocole XML NETCONF et Junos peuvent modifier la base de données de configuration éphémère. Les applications JET doivent envoyer des demandes de configuration sous forme de paires d’opérations de chargement et de validation. Les applications clientes de protocole XML NETCONF et Junos peuvent effectuer plusieurs opérations de chargement avant d’exécuter une opération de validation.
Vous devez valider toutes les données de configuration avant de les charger dans la base de données éphémère et de les valider sur l’équipement, car la validation de données de configuration non valides peut entraîner le redémarrage, voire le blocage des processus Junos, et entraîner une perturbation du système ou du réseau.
Les applications clientes peuvent charger et valider simultanément des données dans différentes instances de la base de données éphémère. Les validations émises en même temps pour différentes instances éphémères sont mises en file d’attente et traitées en série par l’appareil. Si un client se déconnecte d’une session, l’appareil ignore toutes les modifications de configuration non validées dans l’instance éphémère, mais les données de configuration qui ont déjà été validées dans l’instance éphémère par ce client ne sont pas affectées.
Lorsque vous validez une instance éphémère, le système valide la syntaxe, mais pas la sémantique, des données de configuration éphémères. Une fois la validation terminée, l’appareil informe les processus système concernés. Les processus lisent la configuration mise à jour et fusionnent les données éphémères dans la configuration active selon les règles de hiérarchisation décrites dans Instances de base de données éphémères. La configuration active de l’appareil est une vue fusionnée des bases de données de configuration statique et éphémère.
Le temps de validation de la base de données éphémère sera légèrement plus long sur les périphériques exécutant Junos OS Evolved que sur les périphériques exécutant Junos OS en raison des différences architecturales entre les deux systèmes d'exploitation.
Pour plus d’informations sur la validation et la synchronisation des instances de la base de données de configuration éphémère, reportez-vous à la section Valider et synchroniser les données de configuration éphémères à l’aide du protocole XML NETCONF ou Junos.
Utilisation de la base de données éphémère sur des appareils qui utilisent des fonctionnalités de haute disponibilité
La haute disponibilité désigne les composants matériels et logiciels qui assurent la redondance et la fiabilité des communications réseau. Certains comportements et mises en garde doivent être pris en compte avant d’utiliser la base de données éphémère sur des systèmes qui utilisent des fonctionnalités de haute disponibilité, notamment les moteurs de routage redondants, le basculement GRES (Graceful Moteur de routage), le routage actif ininterrompu (NSR) et la redondance interchâssis pour les routeurs MX Series ou les commutateurs EX Series utilisant Virtual Chassis. Les sections suivantes décrivent ces comportements et expliquent comment les différents modèles de synchronisation de validation de base de données éphémères peuvent affecter ces comportements.
- Comprendre les modèles de synchronisation de validation de base de données éphémères
- Moteurs de routage redondants
- GRES (Graceful moteur de routage Switchover)
- NSR (NonStop Active Routing)
- MX Series Virtual Chassis
- EX Series Virtual Chassis
Comprendre les modèles de synchronisation de validation de base de données éphémères
La base de données de configuration éphémère comporte deux modèles pour synchroniser les données de configuration éphémère entre les moteurs de routage ou les membres de Virtual Chassis lors d’une opération de synchronisation de validation :
-
Asynchrone (par défaut)
-
Synchrone
Contrairement au modèle de validation standard, le modèle de validation éphémère par défaut exécute les opérations de synchronisation de validation de manière asynchrone. Le moteur de routage requérant valide la configuration éphémère et émet une notification de validation complète sans attendre que l’autre moteur de routage synchronise et valide d’abord la configuration. Les appareils qui utilisent des fonctionnalités de haute disponibilité nécessitent que les moteurs de routage principal et secondaire soient synchronisés en cas de basculement. Toutefois, il peut arriver qu’une opération de synchronisation de validation asynchrone soit interrompue et ne puisse pas synchroniser la configuration éphémère avec l’autre moteur de routage.
Sur les équipements exécutant Junos OS version 21.1R1 ou ultérieure et les équipements exécutant Junos OS Evolved, vous pouvez configurer la base de données éphémère pour utiliser un modèle de validation synchrone pour les opérations de synchronisation de validation, semblable au modèle utilisé par la base de données de configuration statique.
Dans un environnement à double moteur de routage ou MX Series Virtual Chassis, le modèle de validation synchrone fonctionne comme suit :
- Le moteur de routage principal démarre son opération de validation initiale pour l’instance éphémère.
- À un moment donné au cours de son opération de validation, le moteur de routage principal lance une validation sur le moteur de routage de secours.
- Si le moteur de routage de sauvegarde valide la configuration, le moteur de routage principal poursuit son opération de validation. Si la validation échoue sur le moteur de routage de sauvegarde, le moteur de routage principal échoue également à la validation.
Lorsqu’un EX Series Virtual Chassis utilise le modèle de validation synchrone, le commutateur de membre dans le rôle de moteur de routage principal lance d’abord l’opération de validation sur les autres membres simultanément. Étant donné qu’un EX Series Virtual Chassis peut avoir de nombreux membres, le commutateur principal poursuit son opération de validation, même si la validation échoue sur un autre membre.
Les opérations de validation synchrones sont plus lentes que les opérations de validation asynchrones, mais elles fournissent une meilleure assurance que la configuration éphémère est synchronisée entre les moteurs de routage et entre les membres de Virtual Chassis. Ainsi, le modèle de validation synchrone vous permet d’utiliser la base de données éphémère avec une plus grande fiabilité sur des appareils qui utilisent également des fonctionnalités de haute disponibilité.
Comme c’est le cas pour la base de données de configuration statique, même avec le modèle de synchronisation de validation synchrone, il peut arriver de rares circonstances dans lesquelles l’équipement valide une configuration éphémère mise à jour sur le moteur de routage de secours, mais ne parvient pas à terminer la validation sur le moteur de routage principal, ce qui entraîne une désynchronisation des configurations.
Pour activer le modèle de synchronisation de validation synchrone pour la base de données de configuration éphémère, configurez l’instruction commit-synchronize-model synchronous au niveau de la [edit system configuration-database ephemeral] hiérarchie dans la base de données de configuration statique.
Les équipements exécutant Junos OS version 20.2R1 ou ultérieure et les équipements exécutant Junos OS Evolved prennent également en charge la synchronisation de la configuration de basculement pour la base de données éphémère. Lorsque vous configurez la synchronisation de basculement et que le moteur de routage de sauvegarde se synchronise avec le moteur de routage principal, par exemple, lorsqu’il est nouvellement inséré, remis en ligne ou lors d’un changement de rôle, il synchronise ses bases de données de configuration statiques et éphémères. Dans les versions antérieures de Junos OS, le moteur de routage de sauvegarde synchronise uniquement sa base de données de configuration statique. Pour activer la synchronisation de basculement, configurez l’instruction commit synchronize au niveau de la [edit system] hiérarchie dans la base de données de configuration statique.
Pour la synchronisation de basculement, le moteur de routage de sauvegarde ou le périphérique de sauvegarde MX Virtual Chassis synchronise la base de données de configuration éphémère avec le périphérique principal uniquement si le périphérique de sauvegarde et le périphérique principal exécutent la même version du logiciel.
Sur les équipements exécutant Junos OS version 21.1R1 ou ultérieure et les équipements exécutant Junos OS Evolved, les opérations de synchronisation de validation et de synchronisation de basculement synchronisent les données de configuration éphémères avec l’autre moteur de routage à l’aide d’une opération de mise à jour de charge au lieu d’une opération de remplacement de charge. Avec une opération de mise à jour de chargement, l’équipement n’a qu’à notifier les processus Junos qui correspondent aux instructions modifiées lors de la mise à jour, ce qui minimise les perturbations possibles du réseau.
Moteurs de routage redondants
Les systèmes à double moteur de routage prennent en charge la configuration de la base de données éphémère. Toutefois, le modèle de validation éphémère ne synchronise pas automatiquement les données de configuration éphémères avec le moteur de routage de sauvegarde lors d’une opération de validation. Les applications clientes peuvent synchroniser les données d’une instance éphémère par commit ou par session, ou configurer une instance éphémère pour qu’elle synchronise automatiquement ses données chaque fois que l’instance est validée. Pour plus d’informations, reportez-vous à la section Valider et synchroniser des données de configuration éphémères à l’aide du protocole XML NETCONF ou Junos.
Les environnements multichâssis ne prennent pas en charge la synchronisation de la base de données de configuration éphémère avec les autres moteurs de routage.
Lorsqu’une application cliente valide des données dans une instance éphémère et les synchronise avec le moteur de routage de sauvegarde, par défaut, la base de données éphémère exécute l’opération de synchronisation de validation de manière asynchrone. Vous pouvez configurer la base de données éphémère pour qu’elle utilise un modèle de validation synchrone pour les opérations de synchronisation de validation. En outre, les équipements de moteur de routage doubles prennent également en charge la synchronisation de la configuration de basculement pour la base de données éphémère à partir de Junos OS version 20.2R1. Pour plus d’informations, reportez-vous à la section Présentation des modèles de synchronisation de validation de base de données éphémères.
GRES (Graceful moteur de routage Switchover)
Le basculement du moteur de routage normal permet à un périphérique doté de moteurs de routage redondants de continuer à transférer des paquets, même si un moteur de routage tombe en panne. GRES exige que les moteurs de routage principal et secondaire synchronisent la configuration et certaines informations d’état avant qu’un basculement ne se produise.
Par défaut, la base de données éphémère effectue des opérations de synchronisation de validation de manière asynchrone. Sur les équipements pris en charge exécutant Junos OS version 21.1R1 ou ultérieure et les équipements exécutant Junos OS Evolved, vous pouvez configurer la base de données éphémère pour qu’elle effectue des opérations de synchronisation de validation à l’aide d’un modèle de validation synchrone, comme décrit dans Présentation des modèles de synchronisation de validation de base de données éphémères. Nous vous recommandons d’utiliser le modèle de validation synchrone sur les périphériques sur lesquels GRES est activé, lorsque l’appareil n’a pas d’exigences strictes en matière de temps de validation. Les opérations de validation synchrones sont plus lentes que les opérations de validation asynchrones, mais elles fournissent une meilleure garantie que la configuration éphémère est synchronisée entre les moteurs de routage. Ainsi, avec ce modèle de commit, vous pouvez utiliser la base de données éphémère avec une plus grande fiabilité sur les appareils sur lesquels GRES est activé.
Les équipements à double moteur de routage exécutant Junos OS Evolved activent GRES par défaut.
Nous vous déconseillons d’utiliser la base de données éphémère avec le modèle de synchronisation de validation asynchrone sur les périphériques sur lesquels GRES est activé, car dans certaines circonstances, la base de données éphémère peut ne pas être synchronisée entre les moteurs de routage principal et secondaire lorsqu’un basculement se produit. Par exemple, les moteurs de routage de secours et principaux peuvent ne pas synchroniser la base de données éphémère si l’opération de synchronisation de validation est interrompue par une panne de courant soudaine. En outre, sur les périphériques exécutant Junos OS version 20.1 et antérieure, lorsque le moteur de routage de sauvegarde synchronise sa configuration avec le moteur de routage principal, il ne synchronise pas la base de données de configuration éphémère. Ainsi, si le moteur de routage de sauvegarde redémarre, par exemple, il supprime les données de configuration éphémères, qui ne persistent pas après les redémarrages, et il ne synchronise pas automatiquement la base de données lorsqu’elle est mise en ligne. Par conséquent, la base de données éphémère peut ne pas être synchronisée entre les moteurs de routage de secours et principaux lorsqu’un basculement se produit.
Lorsque GRES est activé et que la base de données éphémère utilise le modèle de validation asynchrone (valeur par défaut), vous devez configurer explicitement l’équipement pour synchroniser les données de configuration éphémères avec le moteur de routage de sauvegarde. Pour activer la synchronisation, configurez l’instruction allow-commit-synchronize-with-gres au niveau de la [edit system configuration-database ephemeral] hiérarchie dans la base de données de configuration statique. Si GRES est activé et que vous ne configurez pas l’instruction allow-commit-synchronize-with-gres , les périphériques utilisant le modèle de validation asynchrone ne synchronisent pas l’instance éphémère avec le moteur de routage de sauvegarde lorsque vous demandez une opération de synchronisation de validation sur cette instance.
NSR (NonStop Active Routing)
Par défaut, la base de données éphémère effectue des opérations de synchronisation de validation de manière asynchrone. Sur les équipements pris en charge exécutant Junos OS version 21.1R1 ou ultérieure et les équipements exécutant Junos OS Evolved, vous pouvez configurer la base de données éphémère pour qu’elle effectue des opérations de synchronisation de validation à l’aide d’un modèle de validation synchrone, comme décrit dans Présentation des modèles de synchronisation de validation de base de données éphémères. Nous vous recommandons d’utiliser le modèle de validation synchrone sur les périphériques sur lesquels le routage actif continu (NSR) est activé. Les opérations de validation synchrones sont plus lentes que les opérations de validation asynchrones, mais elles fournissent une meilleure garantie que la configuration éphémère est synchronisée entre les moteurs de routage. Ainsi, avec ce modèle de validation, vous pouvez utiliser la base de données éphémère avec une plus grande fiabilité sur les appareils sur lesquels NSR est activé.
Nous vous déconseillons d’utiliser la base de données éphémère avec le modèle de synchronisation de validation asynchrone sur les périphériques sur lesquels NSR est activé, car il s’accompagne de certaines mises en garde. Dans un déploiement avec deux moteurs de routage, une opération de synchronisation de validation sur une instance éphémère sur le moteur de routage principal entraîne une validation asynchrone sur le moteur de routage de secours. Si l’équipement notifie le processus de protocole de routage (rpd) lors de la mise à jour de la configuration, cela peut entraîner un comportement indésirable du système en raison de la nature asynchrone de la validation sur le moteur de routage de sauvegarde.
Les processus qui sont notifiés lorsqu’une instance éphémère est synchronisée avec le moteur de routage de sauvegarde dépendent de la version de Junos OS. Dans Junos OS version 20.4 et antérieure, lorsque vous mettez à jour une instance éphémère sur le moteur de routage principal, la modification apportée au moteur de routage de sauvegarde remplace la configuration complète de l’instance éphémère et la remplace par la plus récente. Dans Junos OS version 20.1 et antérieure, lorsque la nouvelle configuration est appliquée sur le moteur de routage de sauvegarde, Junos OS notifie tous les processus système qui ont des instructions dans cette instance éphémère. À partir de Junos OS version 20.2R1, le comportement de la base de données éphémère est amélioré. Si l’instance éphémère est déjà synchronisée entre le moteur de routage principal et le moteur de routage de sauvegarde et que vous mettez à jour l’instance éphémère sur le moteur de routage principal, Junos OS notifie uniquement les processus correspondant aux parties modifiées de la configuration de l’instance éphémère lorsqu’il valide les modifications sur le moteur de routage de sauvegarde. À compter de Junos OS version 21.1R1, l’équipement synchronise l’instance éphémère avec le moteur de routage de sauvegarde à l’aide d’une opération de mise à jour de charge au lieu d’une opération de remplacement de charge, de sorte qu’il notifie uniquement les processus correspondant aux instructions modifiées.
Les applications utilisant la base de données éphémère ne sont affectées dans cette situation NSR que si elles interagissent avec le processus du protocole de routage. Par exemple, le SmartWall Threat Defense Director (SmartWall TDD) ne serait pas affecté dans ce cas, car il n’interagit avec le processus de pare-feu (dfwd) que par le biais de la base de données éphémère.
MX Series Virtual Chassis
À partir de Junos OS version 20.2R1, MX Series Virtual Chassis prenons en charge la configuration de la base de données éphémère. Vous pouvez configurer et valider une instance éphémère uniquement sur le moteur de routage principal du périphérique principal Virtual Chassis.
Un MX Series Virtual Chassis ne synchronise pas automatiquement les données de configuration éphémères lors d’une opération de validation. Comme avec les systèmes à double moteur de routage, vous pouvez synchroniser les données dans une instance éphémère par commit ou par session, ou vous pouvez configurer une instance éphémère pour synchroniser automatiquement ses données chaque fois que l’instance est validée. Les données éphémères sont uniquement synchronisées entre le moteur de routage principal de l’équipement principal et le moteur de routage principal de l’équipement de sauvegarde.
MX Series Virtual Chassis ne synchronisons en aucun cas les données de configuration éphémères du moteur de routage principal vers le moteur de routage de sauvegarde du membre Virtual Chassis respectif.
MX Series Virtual Chassis doit avoir configuré GRES. Si vous configurez la base de données éphémère pour utiliser le modèle de synchronisation de validation synchrone, l’équipement synchronise l’instance éphémère avec l’autre moteur de routage lorsque vous demandez une opération de synchronisation de validation. Toutefois, si la base de données éphémère utilise le modèle de synchronisation de validation asynchrone (valeur par défaut), vous devez configurer explicitement l’instruction allow-commit-synchronize-with-gres dans la base de données de configuration statique pour activer la synchronisation. Pour plus d’informations sur les modèles de validation de base de données éphémères , reportez-vous à la section Présentation des modèles de synchronisation de validation de base de données éphémères.
Lorsque vous validez et synchronisez une instance éphémère sur un MX Series Virtual Chassis qui utilise le modèle de synchronisation de validation asynchrone :
-
Le périphérique principal Virtual Chassis valide la syntaxe de configuration et valide l’instance éphémère sur son moteur de routage principal.
-
Si la validation réussit, l’appareil principal informe l’appareil de sauvegarde de synchroniser l’instance éphémère.
-
L’unité de sauvegarde valide l’instance éphémère sur son moteur de routage principal uniquement. En cas d’échec de l’opération de validation, l’unité de sauvegarde consigne un message dans le fichier journal système, mais n’en informe pas l’unité principale.
Lorsque vous validez et synchronisez une instance éphémère sur un MX Series Virtual Chassis configuré pour utiliser le modèle de synchronisation de validation synchrone :
-
L’équipement principal Virtual Chassis démarre sa validation de l’instance éphémère sur son moteur de routage principal.
-
À un moment donné de son opération de validation, l'équipement principal lance une validation sur le moteur de routage principal de l'équipement de sauvegarde.
-
Si l’unité de sauvegarde valide la configuration, l’unité principale poursuit son opération de validation. Si l’unité de sauvegarde ne parvient pas à valider la configuration, l’unité principale échoue également à la validation.
Comme indiqué, lorsque vous utilisez le modèle de synchronisation de validation asynchrone pour la base de données éphémère, la validation peut réussir sur l’unité principale, mais échouer sur l’unité de sauvegarde. Lorsque vous utilisez le modèle de synchronisation de validation synchrone, la validation réussit ou échoue pour les deux moteurs de routage principaux, sauf dans de rares circonstances.
MX Series Virtual Chassis prennent en charge la synchronisation de la configuration de basculement pour la base de données éphémère. Lorsque vous configurez l’instruction commit synchronize au niveau de la [edit system] hiérarchie dans la base de données de configuration statique et que le moteur de routage principal sur l’unité de sauvegarde Virtual Chassis se synchronise avec le moteur de routage principal sur l’équipement principal Virtual Chassis, par exemple après son redémarrage, il synchronise ses bases de données de configuration statiques et éphémères.
Pour la synchronisation de basculement, le périphérique de sauvegarde MX Virtual Chassis synchronise la base de données de configuration éphémère avec le périphérique principal uniquement si les deux périphériques exécutent la même version du logiciel.
EX Series Virtual Chassis
EX Series Virtual Chassis prennent en charge la base de données de configuration éphémère. Vous pouvez uniquement configurer et valider une instance éphémère sur le commutateur membre dans le rôle principal du moteur de routage. À partir de Junos OS version 23.4R1, vous pouvez synchroniser la base de données éphémère entre EX Series Virtual Chassis membres.
Un EX Series Virtual Chassis ne synchronise pas automatiquement les données de configuration éphémères lors d’une opération de validation. Vous pouvez synchroniser les données d’une instance éphémère par commit ou par session, ou vous pouvez configurer une instance éphémère pour qu’elle synchronise automatiquement ses données chaque fois que l’instance est validée.
Vous pouvez configurer GRES sur un EX Series Virtual Chassis pour permettre au Virtual Chassis de continuer à transférer des paquets en cas de défaillance de l’moteur de routage primaire. Si vous configurez la base de données éphémère pour qu’elle utilise le modèle de synchronisation de validation synchrone, l’appareil synchronise l’instance éphémère avec les autres membres lorsque vous demandez une opération de synchronisation de validation. Toutefois, si la base de données éphémère utilise le modèle de synchronisation de validation asynchrone (valeur par défaut) et que GRES est configuré, vous devez configurer explicitement l’instruction dans la base de données de configuration statique pour activer la allow-commit-synchronize-with-gres synchronisation.
Lorsque vous validez et synchronisez une instance éphémère sur un EX Series Virtual Chassis qui utilise le modèle de synchronisation de validation asynchrone :
-
Le commutateur membre dans le rôle principal du moteur de routage valide la syntaxe de configuration et valide l’instance éphémère.
-
Si la validation réussit, l’appareil principal en informe le
commit-syncdprocessus, qui lance la validation sur chaque commutateur membre à tour de rôle. -
Chaque commutateur membre valide l’instance éphémère. Si l’opération de validation échoue sur l’un des membres, elle n’affecte pas l’opération de validation sur les autres membres.
Lorsque vous validez et synchronisez une instance éphémère sur un EX Series Virtual Chassis configuré pour utiliser le modèle de synchronisation de validation synchrone :
-
Le commutateur membre dans le rôle principal du moteur de routage lance la validation sur tous les commutateurs membres simultanément.
-
Chaque commutateur membre valide l’instance éphémère et en informe le commutateur principal. Si l’opération de validation échoue sur l’un des membres, elle n’affecte pas l’opération de validation sur les autres membres.
-
Après avoir reçu les réponses de tous les commutateurs membres, le commutateur principal valide l’instance éphémère.
Comme indiqué, dans le modèle asynchrone, le commutateur principal s’appuie sur le commit-syncd processus pour lancer les validations sur chaque commutateur membre de manière séquentielle. Si le commit-syncd processus échoue pour une raison quelconque, certaines validations peuvent ne pas être lancées. Dans le modèle de validation synchrone, le commutateur principal lance la validation sur tous les commutateurs membres directement et en parallèle. Ainsi, le modèle de commit synchrone est généralement plus fiable que le modèle de commit asynchrone. Dans les deux cas, si la validation échoue sur un membre, elle n’a pas d’impact ou n’empêche pas la validation sur les autres membres.
De plus, dans le modèle de validation synchrone, le commutateur principal affiche la progression de la validation pour chaque membre au fur et à mesure que la validation se produit. Dans le modèle asynchrone, les validations se produisent en arrière-plan, de sorte que dans ce cas, l’appareil principal enregistre uniquement les résultats de la validation.
Bonnes pratiques pour les bases de données éphémères
La base de données de configuration éphémère permet à plusieurs applications d’effectuer simultanément des modifications rapides de configuration. Étant donné que la base de données de configuration éphémère n’utilise pas les mêmes garanties que la base de données de configuration statique, vous devez examiner attentivement la façon dont vous utilisez la base de données éphémère. Nous vous recommandons de suivre ces meilleures pratiques pour optimiser les performances et éviter les problèmes potentiels lorsque vous utilisez la base de données de configuration éphémère.
- Réguler la fréquence de validation
- Garantir l’intégrité des données
- Consolider les configurations mises à l’échelle
Réguler la fréquence de validation
La base de données éphémère est conçue pour des validations plus rapides. Toutefois, une validation trop fréquente peut entraîner des problèmes si les applications qui consomment la configuration ne peuvent pas suivre le rythme des opérations de validation. Par conséquent, nous vous recommandons de valider l'ensemble de modifications suivant uniquement une fois que l'état opérationnel de l'appareil reflète les modifications apportées à la validation précédente.
Par exemple, si vous exécutez des validations fréquentes et rapides, l’équipement peut écraser certaines données de configuration qu’il stocke dans des fichiers externes avant qu’un processus Junos ne lise la mise à jour précédente. Si un processus Junos manque une mise à jour importante, l’équipement ou le réseau peut présenter un comportement imprévisible.
Garantir l’intégrité des données
Les équipements Junos ne valident pas la sémantique des données de configuration lorsque vous validez des données dans une base de données éphémère. Par conséquent, vous devez prendre des mesures supplémentaires avant de charger et de valider la configuration pour garantir l’intégrité des données. Nous vous recommandons de toujours :
-
Valider les données de configuration avant de les charger dans la base de données
-
Consolidez les instructions de configuration associées dans une base de données unique
Vous devez valider toutes les données de configuration avant de les charger dans une base de données éphémère. Nous vous recommandons de prévalider vos données de configuration à l’aide d’une base de données statique, qui valide à la fois la syntaxe et la sémantique.
En outre, vous devez toujours charger les données de configuration associées dans une seule base de données. L’ajout de données de configuration associées ou dépendantes dans la même base de données permet de s’assurer que l’appareil peut détecter et traiter les instructions associées lors d’une opération de validation. Par exemple, si vous définissez un filtre de pare-feu dans la base de données de configuration statique ou dans une base de données de configuration éphémère, vous devez configurer l’application du filtre à une interface de la même base de données de configuration.
En revanche, supposons que vous configuriez certaines instructions dans la base de données statique, mais que vous configuriez des instructions liées ou dépendantes dans une base de données éphémère. Lorsque vous validez la base de données statique, le système valide uniquement les données au sein de cette base de données. Il se peut que le système n’identifie pas la configuration dépendante dans la base de données éphémère, ce qui peut entraîner l’échec de la validation, et donc de la validation.
Consolider les configurations mises à l’échelle
Nous vous recommandons de charger les configurations mises à l’échelle dans une seule instance de base de données éphémère, plutôt que de les distribuer sur plusieurs bases de données. Une configuration mise à l’échelle peut inclure, par exemple, de longues listes de :
-
Options de stratégie
-
Listes de préfixes
-
VLAN (VLAN)
-
Filtres de pare-feu
Lorsque vous limitez une hiérarchie de configuration de niveau supérieur à une seule base de données, les optimisations internes permettent aux processus Junos d’utiliser la configuration plus efficacement. Par ailleurs, si vous répartissez la configuration sur plusieurs bases de données, les processus Junos doivent analyser une vue fusionnée de la configuration, ce qui nécessite généralement plus de ressources et de temps de traitement.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plate-forme 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.
commit synchronize au niveau de la
[edit system] hiérarchie dans la base de données de configuration statique et que le moteur de routage de sauvegarde se synchronise avec le moteur de routage principal, par exemple, lorsqu’il est nouvellement inséré, remis en ligne ou lors d’un changement de rôle, il synchronise ses bases de données de configuration statiques et éphémères.