Descripción de la base de datos de configuración efímera
La base de datos efímera es una base de datos de configuración alternativa que proporciona una interfaz programática rápida para realizar actualizaciones de configuración en dispositivos que ejecutan Junos OS y Junos OS Evolved. La base de datos efímera permite que las aplicaciones del kit de herramientas de extensión (JET) de Juniper y las aplicaciones cliente del protocolo de administración NETCONF y Junos XML carguen y confirmen simultáneamente cambios de configuración en un dispositivo y con un rendimiento significativamente mayor que cuando se confirman datos en la base de datos de configuración candidata.
En las secciones siguientes se describen los distintos aspectos de la base de datos de configuración efímera.
Beneficios de la base de datos de configuración efímera
- Permite que varias aplicaciones cliente configuren simultáneamente un dispositivo cargando y confirmando datos en instancias separadas de la base de datos efímera
- Permite un aprovisionamiento rápido y cambios rápidos de configuración en entornos dinámicos que requieren tiempos de confirmación rápidos
Información general sobre la base de datos de configuración efímera
Al administrar dispositivos Junos, el método recomendado y más común para configurar el dispositivo es modificar y confirmar la configuración candidata, que corresponde a una base de datos de configuración persistente (estática). La operación de confirmación estándar controla grupos de configuración, macros y secuencias de comandos de confirmación; realiza comprobaciones de confirmación para validar la sintaxis y la semántica de la configuración; y almacena copias de las configuraciones confirmadas. El modelo de confirmación estándar es sólido porque evita errores de configuración y permite revertir a una configuración confirmada anteriormente. Sin embargo, en algunos casos, la operación de confirmación puede consumir una cantidad significativa de tiempo y recursos del dispositivo.
Las aplicaciones JET y las aplicaciones cliente de protocolo XML NETCONF y Junos también pueden configurar la base de datos efímera. La base de datos efímera es una base de datos de configuración alternativa que proporciona una capa de configuración independiente de la base de datos de configuración candidata y de las capas de configuración de otras aplicaciones cliente. El modelo de confirmación efímera permite a los dispositivos Junos confirmar y combinar cambios de varios clientes y ejecutar las confirmaciones con un rendimiento significativamente mayor que cuando se confirman datos en la base de datos de configuración candidata. Por lo tanto, la base de datos efímera es ventajosa en entornos dinámicos donde se requiere un aprovisionamiento rápido y cambios rápidos de configuración, como en grandes centros de datos.
Una operación de confirmación en la base de datos efímera requiere menos tiempo que la misma operación en la base de datos estática porque la base de datos efímera no está sujeta a la misma validación requerida en la base de datos estática. Como resultado, el modelo de confirmación efímera proporciona un mejor rendimiento que el modelo de confirmación estándar, pero a expensas de algunas de las características más robustas presentes en el modelo estándar. El modelo de confirmación efímera tiene las siguientes restricciones:
-
La sintaxis de los datos de configuración se valida, pero la semántica de los datos de configuración no se valida.
-
Algunas instrucciones de configuración no se admiten como se describe en Instrucciones de configuración no compatibles en la base de datos de configuración efímera.
-
No se procesan los grupos de configuración ni los rangos de interfaz.
-
Las macros, los scripts de confirmación y los scripts de traducción no se procesan.
-
Las versiones anteriores de la configuración efímera no se archivan.
-
Los datos de configuración efímera no se muestran en la configuración normal mediante los comandos show estándar.
-
Los datos de configuración efímera no persisten cuando:
-
Instale un paquete que requiera reconstruir el esquema de Junos, por ejemplo, un paquete OpenConfig o YANG.
-
Realice una actualización de software o una actualización de software en servicio unificada (ISSU).
-
Reinicie o apague y encienda el dispositivo.
-
Le recomendamos encarecidamente que tenga cuidado al usar la base de datos de configuración efímera, ya que confirmar datos de configuración no válidos puede dañar la base de datos efímera, lo que puede provocar que los procesos de Junos se reinicien o incluso se bloqueen y provocar interrupciones en el sistema o la red.
Los dispositivos Junos validan la sintaxis, pero no la semántica o las restricciones, de los datos de configuración comprometidos con la base de datos efímera. Por ejemplo, si la configuración hace referencia a una directiva de enrutamiento no definida, la configuración puede ser sintácticamente correcta, pero semánticamente incorrecta. El modelo de confirmación estándar genera un error de confirmación en este caso, pero el modelo de confirmación efímera no. Por lo tanto, es imperativo validar todos los datos de configuración antes de confirmarlos en la base de datos efímera. Si confirma datos de configuración no válidos o que provocan interrupciones no deseadas de la red, debe eliminar los datos problemáticos de la base de datos o, si es necesario, reiniciar el dispositivo, que elimina todos los datos de configuración efímeros.
La base de datos de configuración efímera almacena información interna de la versión, además de los datos de configuración. Como resultado, el tamaño de la base de datos de configuración efímera siempre es mayor que la base de datos de configuración estática para los mismos datos de configuración, y la mayoría de las operaciones en la base de datos efímera, ya sean adiciones, modificaciones o eliminaciones, aumentan el tamaño de la base de datos.
Cuando se usa la base de datos de configuración efímera, las operaciones de confirmación en la base de datos de configuración estática pueden tardar más tiempo, ya que se deben realizar operaciones adicionales para combinar los datos de configuración estáticos y efímeros.
Instancias de bases de datos efímeras
Los dispositivos Junos proporcionan una instancia de base de datos efímera predeterminada, que se habilita automáticamente, así como la capacidad de habilitar instancias definidas por el usuario de la base de datos de configuración efímera. Las aplicaciones JET y las aplicaciones cliente de protocolo XML NETCONF y Junos pueden cargar y confirmar datos simultáneamente en instancias independientes de la base de datos efímera. La configuración activa del dispositivo es una vista combinada de las bases de datos de configuración estática y efímera.
A partir de Junos OS versión 18.2R1, Junos OS admite la configuración de hasta siete instancias definidas por el usuario de la base de datos de configuración efímera. En versiones anteriores, puede configurar hasta ocho instancias definidas por el usuario. Junos OS Evolved admite la configuración de ocho instancias definidas por el usuario.
Las instancias de base de datos efímeras son útiles en escenarios en los que varias aplicaciones cliente pueden necesitar actualizar simultáneamente la configuración de un dispositivo, como cuando dos o más controladores SDN envían simultáneamente datos de configuración al mismo dispositivo. En el modelo de confirmación estándar, un controlador puede tener un bloqueo exclusivo en la configuración candidata, lo que impide que el otro controlador la modifique. Mediante el uso de instancias efímeras independientes, los controladores pueden implementar los cambios al mismo tiempo.
Las aplicaciones pueden cargar y confirmar datos simultáneamente en diferentes instancias de bases de datos efímeras, además de la base de datos de configuración estática. Sin embargo, el dispositivo procesa las confirmaciones secuencialmente. Como resultado, la confirmación con una base de datos específica puede retrasarse, dependiendo del orden de procesamiento.
Los procesos de Junos leen los datos de configuración tanto de la base de datos de configuración estática como de la base de datos de configuración efímera. Cuando una o más instancias de base de datos efímeras están en uso y hay datos en conflicto, las instrucciones de una base de datos con una prioridad más alta invalidan las instrucciones de una base de datos con una prioridad menor. La prioridad de la base de datos, de mayor a menor, es la siguiente:
-
Instrucciones en una instancia definida por el usuario de la base de datos de configuración efímera.
Si hay varias instancias efímeras definidas por el usuario, la prioridad viene determinada por el orden en que se configuran las instancias en el nivel jerárquico
[edit system configuration-database ephemeral], ejecutándose de mayor a menor prioridad. -
Instrucciones de la instancia predeterminada de base de datos efímera.
-
Instrucciones en la base de datos de configuración estática.
Considere la siguiente configuración:
system {
configuration-database {
ephemeral {
instance 1;
instance 2;
}
}
}
La figura 1 ilustra el orden de prioridad de las instancias de base de datos efímeras y la base de datos de configuración estática (confirmada). En este ejemplo, la instancia 1 de la base de datos efímera tiene la prioridad más alta, seguida de la instancia 2 de la base de datos efímera, luego la instancia de base de datos efímera predeterminada y, por último, la base de datos de configuración estática.
de bases de datos efímeras
Modelo de confirmación general de base de datos efímero
Las aplicaciones JET y las aplicaciones cliente de protocolo XML NETCONF y Junos pueden modificar la base de datos de configuración efímera. Las aplicaciones JET deben enviar solicitudes de configuración como pares de operaciones de carga y confirmación. Las aplicaciones cliente de protocolo XML NETCONF y Junos pueden realizar varias operaciones de carga antes de ejecutar una operación de confirmación.
Debe validar todos los datos de configuración antes de cargarlos en la base de datos efímera y confirmarlos en el dispositivo, ya que la confirmación de datos de configuración no válidos puede provocar que los procesos de Junos se reinicien o incluso se bloqueen, y provocar interrupciones en el sistema o la red.
Las aplicaciones cliente pueden cargar y confirmar datos simultáneamente en diferentes instancias de la base de datos efímera. Las confirmaciones emitidas al mismo tiempo para diferentes instancias efímeras son puestas en cola y procesadas en serie por el dispositivo. Si un cliente se desconecta de una sesión, el dispositivo descarta cualquier cambio de configuración no confirmado en la instancia efímera, pero los datos de configuración que ese cliente ya haya confirmado en la instancia efímera no se verán afectados.
Cuando se confirma una instancia efímera, el sistema valida la sintaxis, pero no la semántica, de los datos de configuración efímera. Cuando se completa la confirmación, el dispositivo notifica a los procesos del sistema afectados. Los procesos leen la configuración actualizada y combinan los datos efímeros en la configuración activa de acuerdo con las reglas de priorización descritas en Instancias de base de datos efímeras. La configuración activa del dispositivo es una vista combinada de las bases de datos de configuración estática y efímera.
El tiempo de confirmación de la base de datos efímera será ligeramente mayor en dispositivos que ejecuten Junos OS evolucionado que en dispositivos que ejecuten Junos OS debido a las diferencias arquitectónicas entre los dos sistemas operativos.
Para obtener información detallada acerca de cómo confirmar y sincronizar instancias de la base de datos de configuración efímera, consulte Confirmar y sincronizar datos de configuración efímera mediante el protocolo XML NETCONF o Junos.
Uso de la base de datos efímera en dispositivos que usan características de alta disponibilidad
La alta disponibilidad se refiere a los componentes de hardware y software que proporcionan redundancia y confiabilidad para las comunicaciones de red. Hay ciertos comportamientos y advertencias que deben tenerse en cuenta antes de usar la base de datos efímera en sistemas que usan características de alta disponibilidad, incluidos motores de enrutamiento redundantes, cambio de motor de enrutamiento (GRES), enrutamiento activo sin interrupciones (NSR) y redundancia entre chasis para enrutadores serie MX o conmutadores serie EX que usan chasis virtual. En las secciones siguientes se describen estos comportamientos y se describe cómo los diferentes modelos de sincronización de confirmación de bases de datos efímeras pueden afectar a estos comportamientos.
- Descripción de los modelos de sincronización de confirmación de bases de datos efímeras
- Motores de enrutamiento redundantes
- Cambio de motor de enrutamiento agraciado (GRES)
- Enrutamiento activo sin interrupciones (NSR)
- Chasis virtual serie MX
- Chasis virtual de la serie EX
Descripción de los modelos de sincronización de confirmación de bases de datos efímeras
La base de datos de configuración efímera tiene dos modelos para sincronizar datos de configuración efímeros entre motores de enrutamiento o miembros de chasis virtual durante una operación de sincronización de confirmación:
-
Asincrónico (predeterminado)
-
Síncrono
A diferencia del modelo de confirmación estándar, el modelo de confirmación efímero predeterminado ejecuta operaciones de sincronización de confirmación de forma asincrónica. El motor de enrutamiento solicitante confirma la configuración efímera y emite una notificación de confirmación completa sin esperar a que el otro motor de enrutamiento sincronice y confirme primero la configuración. Los dispositivos que usan funciones de alta disponibilidad requieren que los motores de enrutamiento principal y de respaldo estén sincronizados en caso de conmutación por error. Sin embargo, puede haber situaciones en las que una operación de sincronización de confirmación asincrónica pueda interrumpirse y no se pueda sincronizar la configuración efímera con el otro motor de enrutamiento.
En dispositivos que ejecutan Junos OS versión 21.1R1 o posterior y dispositivos que ejecutan Junos OS evolucionado, puede configurar la base de datos efímera para que utilice un modelo de confirmación sincrónico para las operaciones de sincronización de confirmación, similar al modelo utilizado por la base de datos de configuración estática.
En un entorno de motor de enrutamiento dual o de chasis virtual de la serie MX, el modelo de confirmación sincrónico funciona de la siguiente manera:
- El motor de enrutamiento principal inicia su operación de confirmación inicial para la instancia efímera.
- En un momento dado de su operación de confirmación, el motor de enrutamiento principal inicia una confirmación en el motor de enrutamiento de reserva.
- Si el motor de enrutamiento de reserva confirma correctamente la configuración, el motor de enrutamiento principal continúa su operación de confirmación. Si se produce un error en la confirmación en el motor de enrutamiento de reserva, el motor de enrutamiento principal también produce un error en la confirmación.
Cuando un chasis virtual de la serie EX utiliza el modelo de confirmación sincrónica, el conmutador miembro de la función principal Motor de enrutamiento inicia primero la operación de confirmación en los demás miembros simultáneamente. Dado que un chasis virtual de la serie EX puede tener muchos miembros, el conmutador principal continúa con su operación de confirmación, incluso si la confirmación falla en otro miembro.
Las operaciones de confirmación sincrónicas son más lentas que las operaciones de confirmación asincrónicas, pero ofrecen una mayor garantía de que la configuración efímera está sincronizada entre los motores de enrutamiento y entre los miembros del chasis virtual. Por lo tanto, el modelo de confirmación sincrónica le permite utilizar la base de datos efímera con mayor confiabilidad en dispositivos que también usan características de alta disponibilidad.
Como en el caso de la base de datos de configuración estática, incluso con el modelo de sincronización de confirmación sincrónica, puede haber circunstancias excepcionales en las que el dispositivo confirme una configuración efímera actualizada en el motor de enrutamiento de reserva pero no complete la confirmación en el motor de enrutamiento principal, lo que hace que las configuraciones no estén sincronizadas.
Para habilitar el modelo de sincronización de confirmación sincrónica para la base de datos de configuración efímera, configure la commit-synchronize-model synchronous instrucción en el nivel de [edit system configuration-database ephemeral] jerarquía de la base de datos de configuración estática.
Los dispositivos que ejecutan Junos OS versión 20.2R1 o posterior y los dispositivos que ejecutan Junos OS Evolved también admiten la sincronización de configuración de conmutación por error para la base de datos efímera. Cuando configura la sincronización de conmutación por error y el motor de enrutamiento de reserva se sincroniza con el motor de enrutamiento principal, por ejemplo, cuando se inserta recientemente, se vuelve a conectar o durante un cambio de función, sincroniza sus bases de datos de configuración estáticas y efímeras. En versiones anteriores de Junos OS, el motor de enrutamiento de copia de seguridad sincroniza solo su base de datos de configuración estática. Para habilitar la sincronización de conmutación por error, configure la commit synchronize instrucción en el nivel de [edit system] jerarquía de la base de datos de configuración estática.
Para la sincronización de conmutación por error, el motor de enrutamiento de copia de seguridad o el dispositivo de copia de seguridad MX Virtual Chassis solo sincronizan la base de datos de configuración efímera con el dispositivo principal si tanto el dispositivo de copia de seguridad como el dispositivo principal ejecutan la misma versión de software.
En los dispositivos que ejecutan Junos OS versión 21.1R1 o posterior y en los dispositivos que ejecutan Junos OS Evolved, tanto las operaciones de sincronización de confirmación como las operaciones de sincronización de conmutación por error sincronizan los datos de configuración efímeros con el otro motor de enrutamiento mediante una operación de actualización de carga en lugar de una operación de reemplazo de carga. Mediante una operación de actualización de carga, el dispositivo solo necesita notificar a los procesos de Junos que corresponden a instrucciones modificadas durante la actualización, lo que minimiza las posibles interrupciones en la red.
Motores de enrutamiento redundantes
Los sistemas de motor de enrutamiento dual admiten la configuración de la base de datos efímera. Sin embargo, el modelo de confirmación efímera no sincroniza automáticamente los datos de configuración efímeros con el motor de enrutamiento de reserva durante una operación de confirmación. Las aplicaciones cliente pueden sincronizar los datos de una instancia efímera por confirmación o por sesión, o pueden configurar una instancia efímera para sincronizar automáticamente sus datos cada vez que se confirma la instancia. Para obtener más información, consulte Confirmar y sincronizar datos de configuración efímera mediante el protocolo XML NETCONF o Junos.
Los entornos multichasis no admiten la sincronización de la base de datos de configuración efímera con los otros motores de enrutamiento.
Cuando una aplicación cliente confirma datos en una instancia efímera y los sincroniza con el motor de enrutamiento de copia de seguridad, de forma predeterminada, la base de datos efímera realiza la operación de sincronización de confirmación de forma asincrónica. Puede configurar la base de datos efímera para que utilice un modelo de confirmación sincrónico para las operaciones de sincronización de confirmación. Además, los dispositivos de motor de enrutamiento dual también admiten la sincronización de configuración de conmutación por error para la base de datos efímera a partir de Junos OS versión 20.2R1. Para obtener más información, vea Descripción de los modelos de sincronización de confirmación de bases de datos efímeras.
Cambio de motor de enrutamiento agraciado (GRES)
El cambio correcto del motor de enrutamiento permite que un dispositivo con motores de enrutamiento redundantes continúe reenviando paquetes, incluso si falla un motor de enrutamiento. GRES requiere que los motores de enrutamiento principal y de reserva sincronicen la configuración y cierta información de estado antes de que se produzca un cambio.
De forma predeterminada, la base de datos efímera realiza operaciones de sincronización de confirmación de forma asincrónica. En dispositivos compatibles que ejecutan Junos OS versión 21.1R1 o posterior y dispositivos que ejecutan Junos OS evolucionado, puede configurar la base de datos efímera para realizar operaciones de sincronización de confirmación mediante un modelo de confirmación sincrónico, tal como se describe en Descripción de los modelos de sincronización de confirmación de bases de datos efímeras. Se recomienda utilizar el modelo de confirmación sincrónica en dispositivos que tengan habilitado GRES cuando el dispositivo no tenga requisitos estrictos sobre los tiempos de confirmación. Las operaciones de confirmación sincrónicas son más lentas que las operaciones de confirmación asincrónicas, pero ofrecen una mayor seguridad de que la configuración efímera está sincronizada entre los motores de enrutamiento. Así, con este modelo commit se puede utilizar la base de datos efímera con mayor confiabilidad en dispositivos que tengan habilitado GRES.
Los dispositivos de motor de enrutamiento dual que ejecutan Junos OS Evolved habilitan GRES de forma predeterminada.
No se recomienda usar la base de datos efímera con el modelo de sincronización de confirmación asincrónica en dispositivos que tengan habilitado GRES, ya que, en determinadas circunstancias, es posible que la base de datos efímera no se sincronice entre los motores de enrutamiento principal y de reserva cuando se produce un cambio. Por ejemplo, es posible que los motores de enrutamiento principal y de copia de seguridad no sincronicen la base de datos efímera si la operación de sincronización de confirmación se interrumpe por un corte de energía repentino. Además, en dispositivos que ejecutan Junos OS versión 20.1 y versiones anteriores, cuando el motor de enrutamiento de reserva sincroniza su configuración con el motor de enrutamiento principal, no sincroniza la base de datos de configuración efímera. Por lo tanto, si el motor de enrutamiento de copia de seguridad se reinicia, por ejemplo, elimina los datos de configuración efímeros, que no persisten durante los reinicios, y no vuelve a sincronizar automáticamente la base de datos cuando se conecta. Como resultado, es posible que la base de datos efímera no se sincronice entre los motores de enrutamiento principal y de copia de seguridad cuando se produce un cambio.
Cuando GRES está habilitado y la base de datos efímera utiliza el modelo de confirmación asincrónico (valor predeterminado), debe configurar explícitamente el dispositivo para sincronizar los datos de configuración efímera con el motor de enrutamiento de reserva. Para habilitar la sincronización, configure la allow-commit-synchronize-with-gres instrucción en el nivel de [edit system configuration-database ephemeral] jerarquía de la base de datos de configuración estática. Si GRES está habilitado y no configura la allow-commit-synchronize-with-gres instrucción, los dispositivos que utilizan el modelo de confirmación asincrónica no sincronizarán la instancia efímera con el motor de enrutamiento de reserva cuando solicite una operación de sincronización de confirmación en esa instancia.
Enrutamiento activo sin interrupciones (NSR)
De forma predeterminada, la base de datos efímera realiza operaciones de sincronización de confirmación de forma asincrónica. En dispositivos compatibles que ejecutan Junos OS versión 21.1R1 o posterior y dispositivos que ejecutan Junos OS evolucionado, puede configurar la base de datos efímera para realizar operaciones de sincronización de confirmación mediante un modelo de confirmación sincrónico, tal como se describe en Descripción de los modelos de sincronización de confirmación de bases de datos efímeras. Se recomienda usar el modelo de confirmación sincrónica en dispositivos que tengan habilitado el enrutamiento activo sin interrupciones (NSR). Las operaciones de confirmación sincrónicas son más lentas que las operaciones de confirmación asincrónicas, pero ofrecen una mayor seguridad de que la configuración efímera está sincronizada entre los motores de enrutamiento. Así, con este modelo commit se puede utilizar la base de datos efímera con mayor confiabilidad en dispositivos que tengan habilitada NSR.
No recomendamos usar la base de datos efímera con el modelo de sincronización de confirmación asincrónica en dispositivos que tengan NSR habilitado, ya que viene con ciertas advertencias. En una implementación con motores de enrutamiento duales, una operación de sincronización de confirmación en una instancia efímera del motor de enrutamiento principal da como resultado una confirmación asincrónica en el motor de enrutamiento de reserva. Si el dispositivo notifica al proceso de protocolo de enrutamiento (rpd) en el proceso de actualización de la configuración, podría producirse un comportamiento no deseado del sistema debido a la naturaleza asincrónica de la confirmación en el motor de enrutamiento de reserva.
Los procesos que se notifican cuando se sincroniza una instancia efímera con el motor de enrutamiento de reserva dependen de la versión de Junos OS. En Junos OS versión 20.4 y anteriores, cuando se actualiza una instancia efímera en el motor de enrutamiento principal, el cambio en el motor de enrutamiento de reserva anula la configuración completa de la instancia efímera y se sustituye por la más reciente. En Junos OS versión 20.1 y anteriores, cuando se aplica la nueva configuración en el motor de enrutamiento de reserva, Junos OS notifica a todos los procesos del sistema que tienen instrucciones en esa instancia efímera. A partir de Junos OS versión 20.2R1, se mejora el comportamiento de la base de datos efímera. Si la instancia efímera ya está sincronizada entre los motores de enrutamiento principal y de respaldo, y actualiza la instancia efímera en el motor de enrutamiento principal, Junos OS solo notifica a los procesos correspondientes a las partes modificadas de la configuración de la instancia efímera cuando confirma los cambios en el motor de enrutamiento de reserva. A partir de Junos OS versión 21.1R1, el dispositivo sincroniza la instancia efímera con el motor de enrutamiento de copia de seguridad mediante una operación de actualización de carga en lugar de una operación de anulación de carga, por lo que solo notifica a los procesos correspondientes a las instrucciones que se han cambiado.
Las aplicaciones que utilizan la base de datos efímera solo se ven afectadas en esta situación NSR si interactúan con el proceso del protocolo de enrutamiento. Por ejemplo, SmartWall Threat Defense Director (SmartWall TDD) no se vería afectado en este caso, porque solo interactúa con el proceso de firewall (dfwd) a través de la base de datos efímera.
Chasis virtual serie MX
A partir de Junos OS versión 20.2R1, el chasis virtual de la serie MX admite la configuración de la base de datos efímera. Solo puede configurar y confirmar una instancia efímera en el motor de enrutamiento principal del dispositivo principal del chasis virtual.
Un chasis virtual serie MX no sincroniza automáticamente ningún dato de configuración efímero durante una operación de confirmación. Al igual que con los sistemas de motor de enrutamiento dual, puede sincronizar los datos de una instancia efímera por confirmación o por sesión, o puede configurar una instancia efímera para que sincronice automáticamente sus datos cada vez que se confirme la instancia. Los datos efímeros solo se sincronizan desde el motor de enrutamiento principal del dispositivo principal al motor de enrutamiento principal del dispositivo de copia de seguridad.
Los chasis virtuales de la serie MX no sincronizan, bajo ninguna circunstancia, los datos de configuración efímera del motor de enrutamiento principal con el motor de enrutamiento de respaldo en el miembro del chasis virtual respectivo.
El chasis virtual de la serie MX debe tener GRES configurado. Si configura la base de datos efímera para que utilice el modelo de sincronización de confirmación sincrónica, el dispositivo sincronizará la instancia efímera con el otro motor de enrutamiento cuando solicite una operación de sincronización de confirmación. Sin embargo, si la base de datos efímera utiliza el modelo de sincronización de confirmación asincrónica (valor predeterminado), debe configurar explícitamente la instrucción en la base de datos de configuración estática para habilitar la allow-commit-synchronize-with-gres sincronización. Consulte Descripción de los modelos de confirmación de confirmación de base de datos efímeros para obtener más información acerca de los modelos de confirmación de base de datos efímeros.
Cuando confirme y sincronice una instancia efímera en un Virtual Chassis de la serie MX que utilice el modelo de sincronización de confirmación asincrónica:
-
El dispositivo principal de Virtual Chassis valida la sintaxis de configuración y confirma la instancia efímera en su motor de enrutamiento principal.
-
Si la confirmación se realiza correctamente, el dispositivo principal notifica al dispositivo de copia de seguridad que sincronice la instancia efímera.
-
El dispositivo de copia de seguridad confirma la instancia efímera solo en su motor de enrutamiento principal. Si se produce un error en la operación de confirmación, el dispositivo de copia de seguridad registra un mensaje en el archivo de registro del sistema, pero no notifica al dispositivo principal.
Cuando confirme y sincronice una instancia efímera en un Virtual Chassis de la serie MX que esté configurado para usar el modelo de sincronización de confirmación sincrónica:
-
El dispositivo principal de Virtual Chassis inicia la confirmación de la instancia efímera en su motor de enrutamiento principal.
-
En un momento dado de su operación de confirmación, el dispositivo principal inicia una confirmación en el motor de enrutamiento principal del dispositivo de copia de seguridad.
-
Si el dispositivo de copia de seguridad confirma correctamente la configuración, el dispositivo principal continúa con su operación de confirmación. Si el dispositivo de copia de seguridad no confirma la configuración, el dispositivo principal tampoco puede confirmar la confirmación.
Como se ha descrito, cuando se utiliza el modelo de sincronización asincrónica de confirmación para la base de datos efímera, la confirmación puede realizarse correctamente en el dispositivo principal, pero fallar en el dispositivo de copia de seguridad. Cuando se utiliza el modelo de sincronización de confirmación sincrónica, la confirmación se realiza correctamente o se produce un error para ambos motores de enrutamiento principales, excepto en raras circunstancias.
El chasis virtual de la serie MX admite la sincronización de configuración de conmutación por error para la base de datos efímera. Cuando se configura la commit synchronize instrucción en el nivel de [edit system] jerarquía de la base de datos de configuración estática y el motor de enrutamiento principal del dispositivo de copia de seguridad Virtual Chassis se sincroniza con el motor de enrutamiento principal del dispositivo principal del chasis virtual, por ejemplo, después de reiniciarlo, sincroniza sus bases de datos de configuración estáticas y efímeras.
Para la sincronización de conmutación por error, el dispositivo de copia de seguridad MX Virtual Chassis solo sincroniza la base de datos de configuración efímera con el dispositivo principal si ambos dispositivos ejecutan la misma versión de software.
Chasis virtual de la serie EX
Los chasis virtuales de la serie EX admiten la base de datos de configuración efímera. Solo puede configurar y confirmar una instancia efímera en el conmutador miembro en el rol principal de motor de enrutamiento. A partir de Junos OS versión 23.4R1, puede sincronizar la base de datos efímera entre los miembros del chasis virtual de la serie EX.
Un chasis virtual de la serie EX no sincroniza automáticamente ningún dato de configuración efímero durante una operación de confirmación. Puede sincronizar los datos de una instancia efímera por confirmación o por sesión, o puede configurar una instancia efímera para que sincronice automáticamente sus datos cada vez que se confirme la instancia.
Puede configurar GRES en un chasis virtual de la serie EX para permitir que el chasis virtual continúe reenviando paquetes si falla el motor de enrutamiento principal. Si configura la base de datos efímera para que utilice el modelo de sincronización de confirmación sincrónica, el dispositivo sincronizará la instancia efímera con los demás miembros cuando solicite una operación de sincronización de confirmación. Sin embargo, si la base de datos efímera utiliza el modelo de sincronización de confirmación asincrónica (valor predeterminado) y GRES está configurado, debe configurar explícitamente la instrucción en la base de datos de configuración estática para habilitar la allow-commit-synchronize-with-gres sincronización.
Cuando confirma y sincroniza una instancia efímera en un chasis virtual de la serie EX que utiliza el modelo de sincronización de confirmación asíncrona:
-
El modificador miembro de la función principal de motor de enrutamiento valida la sintaxis de configuración y confirma la instancia efímera.
-
Si la confirmación se realiza correctamente, el dispositivo principal notifica al
commit-syncdproceso, que inicia sucesivamente la confirmación en cada conmutador miembro. -
Cada conmutador miembro confirma la instancia efímera. Si se produce un error en la operación de confirmación en algún miembro, no afectará a la operación de confirmación en los demás miembros.
Al confirmar y sincronizar una instancia efímera en un chasis virtual de la serie EX configurado para utilizar el modelo de sincronización de confirmación sincrónica:
-
El modificador miembro de la función principal Motor de enrutamiento inicia la confirmación en todos los conmutadores miembro simultáneamente.
-
Cada conmutador miembro confirma la instancia efímera y notifica al conmutador principal. Si se produce un error en la operación de confirmación en algún miembro, no afectará a la operación de confirmación en los demás miembros.
-
Después de recibir respuestas de todos los conmutadores miembro, el conmutador principal confirma la instancia efímera.
Como se ha descrito, en el modelo asincrónico, el conmutador principal se basa en el commit-syncd proceso para iniciar las confirmaciones en cada conmutador miembro secuencialmente. Si el commit-syncd proceso falla por cualquier motivo, es posible que no se inicien algunas confirmaciones. En el modelo de confirmación sincrónica, el conmutador principal inicia la confirmación en todos los conmutadores miembro directamente y en paralelo. Por lo tanto, el modelo de confirmación sincrónica es generalmente más confiable que el modelo de confirmación asincrónica. En cualquier caso, si la confirmación falla en un miembro, no afecta ni impide la confirmación en los otros miembros.
Además, en el modelo de confirmación sincrónica, el modificador principal muestra el progreso de confirmación de cada miembro a medida que se produce la confirmación. En el modelo asincrónico, las confirmaciones se producen en segundo plano, por lo que, en este caso, el dispositivo principal solo registra los resultados de la confirmación.
Mejores prácticas de bases de datos efímeras
La base de datos de configuración efímera permite que varias aplicaciones realicen cambios rápidos de configuración simultáneamente. Dado que la base de datos de configuración efímera no utiliza las mismas medidas de seguridad que la base de datos de configuración estática, debe considerar detenidamente cómo se utiliza la base de datos efímera. Se recomienda seguir estas prácticas recomendadas para optimizar el rendimiento y evitar posibles problemas al usar la base de datos de configuración efímera.
- Regular la frecuencia de confirmación
- Garantizar la integridad de los datos
- Consolide configuraciones escaladas
Regular la frecuencia de confirmación
La base de datos efímera está diseñada para confirmaciones más rápidas. Sin embargo, confirmar con demasiada frecuencia puede causar problemas si las aplicaciones que consumen la configuración no pueden seguir el ritmo de las operaciones de confirmación. Por lo tanto, le recomendamos que confirme el siguiente conjunto de cambios solo después de que el estado operativo del dispositivo refleje los cambios con respecto a la confirmación anterior.
Por ejemplo, si ejecuta confirmaciones frecuentes y rápidas, el dispositivo podría sobrescribir determinados datos de configuración que almacena en archivos externos antes de que un proceso de Junos lea la actualización anterior. Si un proceso de Junos pierde una actualización importante, el dispositivo o la red podrían mostrar un comportamiento impredecible.
Garantizar la integridad de los datos
Los dispositivos Junos no validan la semántica de los datos de configuración cuando se confirman datos en una base de datos efímera. Por lo tanto, debe realizar pasos adicionales antes de cargar y confirmar la configuración para garantizar la integridad de los datos. Le recomendamos que siempre:
-
Validar los datos de configuración antes de cargarlos en la base de datos
-
Consolide instrucciones de configuración relacionadas en una única base de datos
Debe validar todos los datos de configuración antes de cargarlos en una base de datos efímera. Se recomienda validar previamente los datos de configuración mediante una base de datos estática, que valide tanto la sintaxis como la semántica.
Además, siempre debe cargar los datos de configuración relacionados en una única base de datos. Agregar datos de configuración relacionados o dependientes en la misma base de datos ayuda a garantizar que el dispositivo pueda detectar y procesar instrucciones relacionadas durante una operación de confirmación. Por ejemplo, si define un filtro de firewall en la base de datos de configuración estática o en una base de datos de configuración efímera, debe configurar la aplicación del filtro a una interfaz de la misma base de datos de configuración.
Por el contrario, supongamos que configura algunas instrucciones en la base de datos estática pero configura instrucciones relacionadas o dependientes en una base de datos efímera. Cuando se confirma la base de datos estática, el sistema valida los datos sólo dentro de esa base de datos. Es posible que el sistema no identifique la configuración dependiente en la base de datos efímera, lo que puede provocar un error en la validación y, por lo tanto, en la confirmación.
Consolide configuraciones escaladas
Se recomienda cargar las configuraciones escaladas en una única instancia de base de datos efímera, en lugar de distribuirlas en varias bases de datos. Una configuración escalada puede incluir, por ejemplo, grandes listas de:
-
Opciones de directiva
-
Listas de prefijos
-
VLAN
-
Filtros de firewall
Cuando se restringe una jerarquía de configuración de nivel superior a una sola base de datos, las optimizaciones internas permiten que los procesos de Junos consuman la configuración de manera más eficiente. Como alternativa, si distribuye la configuración en varias bases de datos, los procesos de Junos deben analizar una vista combinada de la configuración, lo que generalmente requiere más recursos y tiempo de procesamiento.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.
commit synchronize instrucción en el nivel de
[edit system] jerarquía de la base de datos de configuración estática y el motor de enrutamiento de reserva se sincroniza con el motor de enrutamiento principal, por ejemplo, cuando se inserta recientemente, se vuelve a conectar o durante un cambio de rol, se sincronizan sus bases de datos de configuración estáticas y efímeras.