Entender o banco de dados de configuração efêmero

Entender o banco de dados efêmero comprometer modelos de sincronização

Ao contrário do modelo de compromisso padrão, o modelo de compromisso efêmero padrão executa operações de sincronização de compromisso de forma assíncrona. O mecanismo de roteamento de solicitação compromete a configuração efêmera e emite uma notificação completa de compromisso sem esperar que o outro mecanismo de roteamento sincronizar e comprometer a configuração primeiro. Dispositivos que usam recursos de alta disponibilidade exigem que os mecanismos de roteamento principal e de backup sejam sincronizados em caso de failover. No entanto, pode haver situações em que uma operação de sincronização assíncrona pode ser interrompida e não sincronizar a configuração efêmera com o outro mecanismo de roteamento.

Em dispositivos que executam o Junos OS Release 21.1R1 ou posteriores e dispositivos que executam o Junos OS Evolved, você pode configurar o banco de dados efêmero para executar operações de sincronização de compromisso usando um modelo de compromisso síncrono, semelhante ao usado pelo banco de dados de configuração estático. No modelo de compromisso síncrono:

1. O mecanismo de roteamento primário inicia sua operação de compromisso inicial para a instância efêmera.
2. Em um determinado ponto durante sua operação de compromisso, o mecanismo de roteamento primário inicia um compromisso no mecanismo de roteamento de backup.
3. Se o mecanismo de roteamento de backup confirmar com sucesso a configuração, o mecanismo de roteamento primário continua sua operação de compromisso. Se o commit falhar no mecanismo de roteamento de backup, o mecanismo de roteamento primário também falhará no compromisso.

As operações de compromisso síncrono são mais lentas do que as operações de compromisso assíncrono, mas fornecem melhor garantia de que a configuração efêmera é sincronizada entre mecanismos de roteamento. O modelo de compromisso síncrono permite que você use o banco de dados efêmero com maior confiabilidade em dispositivos que também usam recursos de alta disponibilidade.

Para habilitar o modelo de sincronização de compromisso síncrono para o banco de dados de configuração efêmero, configure a commit-synchronize-model synchronous declaração no nível de [edit system configuration-database ephemeral] hierarquia no banco de dados de configuração estático.

Dispositivos que executam o Junos OS Release 20.2R1 ou posteriores e dispositivos que executam o Junos OS Evolved também oferecem suporte à sincronização de configuração de failover para o banco de dados efêmero. Quando você configura a sincronização de failover e o mecanismo de roteamento de backup sincroniza-se com o mecanismo de roteamento principal, por exemplo, quando ele é inserido recentemente, trazido de volta on-line ou durante uma mudança de função, ele sincroniza seus bancos de dados de configuração estáticos e efêmeros. Nas versões anteriores do Junos OS, o mecanismo de roteamento de backup sincroniza apenas seu banco de dados de configuração estática. Para habilitar a sincronização de failover, configure a commit synchronize declaração no nível de [edit system] hierarquia no banco de dados de configuração estático.

Em dispositivos que executam o Junos OS Release 21.1R1 ou posteriores e dispositivos que executam o Junos OS Evolved, ambos cometem operações de sincronização e failover sincronizam as operações sincronizam os dados de configuração efêmeros com o outro Mecanismo de Roteamento usando uma operação de atualização de carga em vez de uma operação de override de carga. Ao usar uma operação de atualização de carga, o dispositivo só precisa notificar os processos do Junos que correspondem a declarações alteradas durante a atualização, o que minimiza possíveis interrupções na rede.

Mecanismos de roteamento redundantes

Sistemas de mecanismos de roteamento duplo suportam a configuração do banco de dados efêmero. No entanto, o modelo de compromisso efêmero não sincroniza automaticamente os dados de configuração efêmeros com o mecanismo de roteamento de backup durante uma operação de compromisso. Os aplicativos do cliente podem sincronizar os dados em uma instância efêmera em uma base por compromisso ou por sessão, ou podem configurar uma instância efêmera para sincronizar automaticamente seus dados toda vez que a instância for comprometida. Para obter mais informações, consulte os dados de configuração Efêmero Commit e Synchronize usando o protocolo NETCONF ou Junos XML.

Quando um aplicativo do cliente compromete dados em uma instância efêmera e os sincroniza com o mecanismo de roteamento de backup, por padrão, o banco de dados efêmero executa a operação de sincronização de commit de maneira assíncrona. Você pode configurar o banco de dados efêmero para usar um modelo de compromisso síncrono para comprometer operações de sincronização. Além disso, os dispositivos dual Routing Engine também oferecem suporte à sincronização de configuração de failover para o banco de dados efêmero a partir do Junos OS Release 20.2R1. Para obter mais informações, consulte o Understanding Ephemeral Database Commit Synchronize Models.

Switchover gracioso do mecanismo de roteamento (GRES)

A comutação graciosa do mecanismo de roteamento permite que um dispositivo com mecanismos de roteamento redundantes continue a encaminhar pacotes, mesmo que um mecanismo de roteamento falhe. O GRES exige que os mecanismos de roteamento principal e de backup sincronizam a configuração e determinadas informações de estado antes que ocorra uma mudança de switch.

Por padrão, o banco de dados efêmero executa operações de sincronização assíncronas. Em dispositivos suportados que executam o Junos OS Release 21.1R1 ou posteriores e dispositivos que executam o Junos OS Evolved, você pode configurar o banco de dados efêmero para realizar operações de sincronização de compromisso usando um modelo de compromisso síncrono conforme descrito no Understanding Ephemeral Database Commit Synchronize Models. Recomendamos que você use o modelo de compromisso síncrono em dispositivos que tenham o GRES habilitado, quando o dispositivo não tiver requisitos rigorosos em tempos de compromisso. As operações de compromisso síncrono são mais lentas do que as operações de compromisso assíncrono, mas fornecem melhor garantia de que a configuração efêmera é sincronizada entre mecanismos de roteamento. Assim, com este modelo de compromisso, você pode usar o banco de dados efêmero com maior confiabilidade em dispositivos habilitados para GRES.

Não recomendamos o uso do banco de dados efêmero com o modelo de sincronização de compromisso assíncrono em dispositivos habilitados pelo GRES, porque, em certas circunstâncias, o banco de dados efêmero pode não ser sincronizado entre os mecanismos de roteamento principal e de backup quando ocorre uma troca. Por exemplo, os mecanismos de roteamento primários e de backup podem não sincronizar o banco de dados efêmero se a operação de sincronização de compromisso for interrompida por uma interrupção repentina de energia. Além disso, em dispositivos que executam o Junos OS Release 20.1 e anteriores, quando o mecanismo de roteamento de backup sincroniza sua configuração com o mecanismo de roteamento primário, ele não sincroniza o banco de dados de configuração efêmero. Assim, se o mecanismo de roteamento de backup reiniciar, por exemplo, ele elimina os dados de configuração efêmeros, que não persistem em reinicializações, e não sincroniza automaticamente o banco de dados novamente quando ele está on-line. Como resultado, o banco de dados efêmero pode não ser sincronizado entre os mecanismos de roteamento primário e de backup quando ocorre uma troca.

Quando o GRES é habilitado e o banco de dados efêmero usa o modelo de compromisso assíncrono, que é o padrão, você deve configurar explicitamente a allow-commit-synchronize-with-gres declaração no nível de hierarquia no [edit system configuration-database ephemeral] banco de dados de configuração estática para permitir que o dispositivo sincronizar dados de configuração efêmera ao mecanismo de roteamento de backup quando você solicita uma operação de sincronização de compromisso em uma instância efêmera. Se o GRES estiver habilitado e você não configurar a declaração, os allow-commit-synchronize-with-gres dispositivos que usam o modelo de compromisso assíncrono não sincronizam a instância efêmera com o mecanismo de roteamento de backup quando você solicita uma operação de sincronização de compromisso nessa instância.

Roteamento ativo sem parar (NSR)

Por padrão, o banco de dados efêmero executa operações de sincronização assíncronas. Em dispositivos suportados que executam o Junos OS Release 21.1R1 ou posteriores e dispositivos que executam o Junos OS Evolved, você pode configurar o banco de dados efêmero para realizar operações de sincronização de compromisso usando um modelo de compromisso síncrono conforme descrito no Understanding Ephemeral Database Commit Synchronize Models. Recomendamos que você use o modelo de compromisso síncrono em dispositivos que tenham o roteamento ativo (NSR) ativado sem parar. As operações de compromisso síncrono são mais lentas do que as operações de compromisso assíncrono, mas fornecem melhor garantia de que a configuração efêmera é sincronizada entre mecanismos de roteamento. Assim, com este modelo de compromisso, você pode usar o banco de dados efêmero com maior confiabilidade em dispositivos habilitados para NSR.

Não recomendamos o uso do banco de dados efêmero com o modelo de sincronização de compromisso assíncrono em dispositivos habilitados pelo NSR, porque ele vem com certas ressalvas. Em uma implantação com mecanismos de roteamento duplos, uma operação de sincronização de compromisso em uma instância efêmera no mecanismo de roteamento primário resulta em um compromisso assíncrono no mecanismo de roteamento de backup. Se o dispositivo notificar o processo de protocolo de roteamento (rpd) no processo de atualização da configuração, ele pode resultar em um comportamento indesejável do sistema devido à natureza assíncrona do commit no mecanismo de roteamento de backup.

Os processos que são notificados quando uma instância efêmera é sincronizada com o mecanismo de roteamento de backup dependem da versão do Junos OS. No Junos OS Release 20.4 e anteriormente, quando você atualiza uma instância efêmera no mecanismo de roteamento primário, a mudança no mecanismo de roteamento de backup substitui a configuração completa para a instância efêmera, substituindo-a pelo mais recente. No Junos OS Release 20.1 e anterior, quando a nova configuração é aplicada no mecanismo de roteamento de backup, o Junos OS notifica todos os processos de sistema que têm declarações nessa instância efêmera. A partir do Junos OS Release 20.2R1, o comportamento do banco de dados efêmero é aprimorado. Se a instância efêmera já estiver sincronizada entre os mecanismos de roteamento primários e de backup, e você atualizar a instância efêmera no mecanismo de roteamento primário, o Junos OS só notifica esses processos correspondentes às porções modificadas da configuração de instâncias efêmeras quando comete as alterações no mecanismo de roteamento de backup. A partir do Junos OS Release 21.1R1, o dispositivo sincroniza a instância efêmera com o mecanismo de roteamento de backup usando uma operação de atualização de carga em vez de uma operação de override de carga, para que ele apenas notifique processos correspondentes a declarações que são alteradas.

Chassi virtual da Série MX

A partir do Junos OS Release 20.2R1, o chassi virtual da Série MX oferece suporte para configurar o banco de dados efêmero. Você só pode configurar e cometer uma instância efêmera no mecanismo de roteamento primário do dispositivo principal virtual Chassis.

Um Chassi Virtual da Série MX não sincroniza automaticamente nenhum dados de configuração efêmeros durante uma operação de compromisso. Como acontece com sistemas dual Routing Engine, você pode sincronizar os dados em uma instância efêmera em uma base por commit ou por sessão, ou configurar uma instância efêmera para sincronizar automaticamente seus dados toda vez que a instância for comprometida. Os dados efêmeros só são sincronizados desde o mecanismo de roteamento primário no dispositivo principal até o mecanismo de roteamento principal no dispositivo de backup.

O chassi virtual da Série MX deve ter o GRES configurado. Se você configurar o banco de dados efêmero para usar o modelo de sincronização de compromisso síncrono, o dispositivo sincroniza a instância efêmera com o outro Mecanismo de Roteamento quando solicita uma operação de sincronização de compromisso. No entanto, se o banco de dados efêmero usar o modelo de sincronização de compromisso assíncrono padrão, você deve configurar explicitamente a allow-commit-synchronize-with-gres declaração no banco de dados de configuração estática para permitir que o dispositivo sincronizar dados de configuração efêmeros durante uma operação de sincronização de compromisso. Consulte o Understanding Ephemeral Database Commit Synchronize Models para obter mais informações sobre os modelos de compromisso de banco de dados efêmeros.

Quando você comete e sincroniza uma instância efêmera em um Chassi Virtual da Série MX que usa o modelo de sincronização de compromisso assíncrono:

1. O dispositivo primário Virtual Chassis valida a sintaxe e comete a instância efêmera em seu mecanismo de roteamento primário.

2. Se o commit for bem-sucedido, o dispositivo principal notifica o dispositivo de backup para sincronizar a instância efêmera.

3. O dispositivo de backup comete a instância efêmera apenas em seu mecanismo de roteamento principal. Se a operação de confirmação falhar, o dispositivo de backup registrará uma mensagem no arquivo de log do sistema, mas não notificará o dispositivo principal.

Quando você comete e sincroniza uma instância efêmera em um Chassi Virtual da Série MX configurado para usar o modelo de sincronização de compromisso síncrono:

1. O dispositivo principal virtual Chassis inicia o compromisso da instância efêmera em seu mecanismo de roteamento primário.

2. Em um determinado ponto de sua operação de compromisso, o dispositivo principal inicia um compromisso no mecanismo de roteamento principal do dispositivo de backup.

3. Se o dispositivo de backup confirmar com sucesso a configuração, o dispositivo principal continua sua operação de compromisso. Se o dispositivo de backup não confirmar a configuração, o dispositivo principal também falhará no commit.

Conforme descrito, quando você usa o modelo de sincronização assíncrono para o banco de dados efêmero, o commit pode ter sucesso no dispositivo principal, mas falhar no dispositivo de backup. Quando você usa o modelo de sincronização de compromisso síncrono, o commit tem sucesso ou falha em ambos os mecanismos de roteamento primários, exceto em circunstâncias raras.

O Chassi Virtual da Série MX oferece suporte à sincronização de configuração de failover para o banco de dados efêmero. Quando você configura a commit synchronize declaração no nível de [edit system] hierarquia no banco de dados de configuração estática e o mecanismo de roteamento primário no dispositivo de backup Virtual Chassis sincroniza com o mecanismo de roteamento primário no dispositivo principal do Virtual Chassis, por exemplo, após o reinício, ele sincroniza seus bancos de dados de configuração estáticos e efêmeros.

Regular a frequência de compromisso

O banco de dados efêmero foi projetado para compromissos mais rápidos. No entanto, comprometer-se com muita frequência pode causar problemas se os aplicativos que consomem a configuração não conseguirem acompanhar a taxa de operações de compromisso. Portanto, recomendamos que você cometa o próximo conjunto de mudanças somente após o estado operacional do dispositivo refletir as mudanças do compromisso anterior.

Por exemplo, se você executar compromissos frequentes e rápidos, o dispositivo pode substituir determinados dados de configuração que armazena em arquivos externos antes que um processo do Junos leia a atualização anterior. Se um processo Junos perder uma atualização importante, o dispositivo ou a rede podem exibir um comportamento imprevisível.

Garanta a integridade dos dados

Os dispositivos Junos não validam a semântica de dados de configuração quando você compromete dados em um banco de dados efêmero. Portanto, você deve tomar medidas adicionais antes de carregar e comprometer a configuração para garantir a integridade dos dados. Recomendamos que você sempre:

• Valide os dados de configuração antes de carregá-lo no banco de dados

• Consolide as declarações de configuração relacionadas em um único banco de dados

Você deve validar todos os dados de configuração antes de carregá-los em um banco de dados efêmero. Recomendamos que você valide previamente seus dados de configuração usando um banco de dados estático, que valida sintaxe e semântica.

Além disso, você deve sempre carregar dados de configuração relacionados em um único banco de dados. Adicionar dados de configuração relacionados ou dependentes no mesmo banco de dados ajuda a garantir que o dispositivo possa detectar e processar declarações relacionadas durante uma operação de compromisso. Por exemplo, se você definir um filtro de firewall no banco de dados de configuração estática ou em um banco de dados de configuração efêmero, então você deve configurar a aplicação do filtro para uma interface no mesmo banco de dados de configuração.

Por outro lado, suponha que você configure algumas declarações no banco de dados estático, mas configure declarações relacionadas ou dependentes em um banco de dados efêmero. Quando você confirma o banco de dados estático, o sistema valida os dados apenas dentro desse banco de dados. O sistema pode não identificar a configuração dependente no banco de dados efêmero, o que pode fazer com que a validação e, portanto, o compromisso, falhe.

Consolide configurações escalonadas

Recomendamos que você carregue configurações escalonadas em uma única instância de banco de dados efêmera, em vez de distribuí-las em vários bancos de dados. Uma configuração escalonada pode incluir, por exemplo, grandes listas de:

• Opções de políticas

• Listas de prefixo

• Vlans

• Filtros de firewall

Quando você restringe uma hierarquia de configuração de alto nível a um único banco de dados, otimizações internas permitem que os processos do Junos consumam a configuração de maneira mais eficiente. Alternativamente, se você espalhar a configuração em vários bancos de dados, os processos do Junos devem analisar uma visão mesclada da configuração, que geralmente requer mais recursos e tempo de processamento.