Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Entendendo o banco de dados de configuração Efêmero

O banco de dados efêmero é um banco de dados de configuração alternativo que fornece uma interface programática rápida para realizar atualizações de configuração em dispositivos que executam o Junos OS e o Junos OS Evolved. O banco de dados efêmero permite que os aplicativos Juniper Extension Toolkit (JET) e NETCONF e Junos XML protocolem aplicativos de cliente de protocolo de gerenciamento para carregar e confirmar alterações de configuração em um dispositivo e com taxa de transferência significativamente maior do que ao comprometer dados no banco de dados de configuração do candidato.

As seções a seguir discutem os diferentes aspectos do banco de dados de configuração efêmero.

Benefícios do banco de dados de configuração efêmero

  • Permite que vários aplicativos de clientes configurem simultaneamente um dispositivo carregando e comprometendo dados para instâncias separadas do banco de dados efêmero
  • Permite o provisionamento rápido e mudanças rápidas de configuração em ambientes dinâmicos que exigem tempos de confirmação rápidos

Visão geral do banco de dados de configuração efêmera

Ao gerenciar dispositivos Junos, o método recomendado e mais comum para configurar o dispositivo é modificar e comprometer a configuração do candidato, o que corresponde a um banco de dados de configuração (estático) persistente. A operação de confirmação padrão lida com grupos de configuração, macros e scripts de confirmação; realiza verificações de confirmação para validar a sintaxe e a semântica da configuração; e armazena cópias das configurações comprometidas. O modelo de confirmação padrão é robusto porque evita erros de configuração e permite que você reverta para uma configuração previamente comprometida. No entanto, em alguns casos, a operação de confirmação pode consumir uma quantidade significativa de tempo e recursos do dispositivo.

Aplicativos JET e aplicativos de cliente de protocolo NETCONF e Junos XML também podem configurar o banco de dados efêmero. O banco de dados efêmero é um banco de dados de configuração alternativo que fornece uma camada de configuração separada do banco de dados de configuração do candidato e das camadas de configuração de outros aplicativos do cliente. O modelo de confirmação efêmero permite que os dispositivos Junos comprometam e mesclam mudanças de vários clientes e executem os compromissos com uma taxa de transferência significativamente maior do que quando comprometem dados com o banco de dados de configuração do candidato. Assim, o banco de dados efêmero é vantajoso em ambientes dinâmicos onde o provisionamento rápido e mudanças rápidas de configuração são necessárias, como em grandes data centers.

Uma operação de confirmação no banco de dados efêmero requer menos tempo do que a mesma operação no banco de dados estático porque o banco de dados efêmero não está sujeito à mesma validação necessária no banco de dados estático. Como resultado, o modelo de comprometimento efêmero oferece melhor desempenho do que o modelo de compromisso padrão, mas às custas de alguns dos recursos mais robustos presentes no modelo padrão. O modelo de compromisso efêmero tem as seguintes restrições:

  • A sintaxe dos dados de configuração é validada, mas a semântica de dados de configuração não é validada.

  • Determinadas declarações de configuração não são suportadas como descrito em declarações de configuração não suportadas no banco de dados de configuração Efêmero.

  • Grupos de configuração e intervalos de interface não são processados.

  • Macros, scripts de confirmação e scripts de tradução não são processados.

  • As versões anteriores da configuração efêmera não são arquivadas.

  • Os dados de configuração efêmeros não são exibidos na configuração normal usando comandos de exibição padrão.

  • Os dados de configuração efêmeros não persistem quando você:

    • Instale um pacote que exija a reconstrução do esquema Junos, por exemplo, um pacote OpenConfig ou YANG.

    • Realize uma atualização de software ou uma atualização unificada de software em serviço (ISSU).

    • Reinicialize ou impulsione o dispositivo.

CUIDADO:

Recomendamos fortemente que você tenha cuidado ao usar o banco de dados de configuração efêmero, pois o comprometimento de dados de configuração inválidos pode corrupter o banco de dados efêmero, o que pode fazer com que os processos do Junos reiniciem ou até mesmo afetem e resultem em interrupções no sistema ou na rede.

Os dispositivos Junos validam a sintaxe, mas não a semântica, ou restrições, dos dados de configuração comprometidos com o banco de dados efêmero. Por exemplo, se a configuração fizer referência a uma política de roteamento não definida, a configuração pode estar sintáticamente correta, mas seria semanticamente incorreta. O modelo de confirmação padrão gera um erro de confirmação neste caso, mas o modelo de compromisso efêmero não. Portanto, é imperativo validar todos os dados de configuração antes de compensá-los ao banco de dados efêmero. Se você confirmar dados de configuração inválidos ou resultarem em interrupções indesejáveis da rede, você deve excluir os dados problemáticos do banco de dados ou, se necessário, reiniciar o dispositivo, que exclui todos os dados de configuração efêmeros.

Nota:

O banco de dados de configuração efêmero armazena informações de versão interna, além de dados de configuração. Como resultado, o tamanho do banco de dados de configuração efêmero é sempre maior do que o banco de dados de configuração estática para os mesmos dados de configuração, e a maioria das operações no banco de dados efêmero, sejam adições, modificações ou exclusões, aumentam o tamanho do banco de dados.

Nota:

Quando você usa o banco de dados de configuração efêmero, as operações de confirmação no banco de dados de configuração estática podem levar mais tempo, pois operações adicionais devem ser realizadas para mesclar os dados de configuração estáticos e efêmeros.

Instâncias de banco de dados efêmeras

Os dispositivos Junos oferecem uma instância padrão de banco de dados efêmero, que é habilitada automaticamente, bem como a capacidade de permitir instâncias definidas pelo usuário do banco de dados de configuração efêmero. Aplicativos JET e aplicativos de cliente de protocolo NETCONF e Junos XML podem carregar e comprometer dados simultaneamente em instâncias separadas do banco de dados efêmero. A configuração ativa do dispositivo é uma visão mesclada dos bancos de dados de configuração estáticos e efêmeros.

Nota:

A partir do Junos OS Release 18.2R1, o Junos OS oferece suporte à configuração de até sete instâncias definidas pelo usuário do banco de dados de configuração efêmero. Em versões anteriores, você pode configurar até oito instâncias definidas pelo usuário. O Junos OS Evolved oferece suporte à configuração de oito instâncias definidas pelo usuário.

Instâncias de banco de dados efêmeras são úteis em cenários onde vários aplicativos de cliente podem precisar atualizar simultaneamente uma configuração de dispositivo, como quando dois ou mais controladores SDN simultaneamente empurram dados de configuração para o mesmo dispositivo. No modelo de confirmação padrão, um controlador pode ter um bloqueio exclusivo na configuração do candidato, impedindo assim que o outro controlador o modifique. Ao usar instâncias efêmeras separadas, os controladores podem implantar as mudanças ao mesmo tempo.

Nota:

Os aplicativos podem carregar e comprometer dados simultaneamente em diferentes instâncias de banco de dados efêmeras, além do banco de dados de configuração estático. No entanto, o dispositivo processa o confirma sequencialmente. Como resultado, o compromisso com um banco de dados específico pode ser adiado, dependendo da ordem de processamento.

Os processos do Junos lêem os dados de configuração tanto do banco de dados de configuração estática quanto do banco de dados de configuração efêmero. Quando uma ou mais instâncias de banco de dados efêmeras estão em uso e há dados conflituosos, as declarações em um banco de dados com maior prioridade sobrepõem as declarações em um banco de dados com menor prioridade. A prioridade do banco de dados, do mais alto ao mais baixo, é a seguinte:

  1. Declarações em uma instância definida pelo usuário do banco de dados de configuração efêmero.

    Se houver várias instâncias efêmeras definidas pelo usuário, a prioridade é determinada pela ordem em que as instâncias estão configuradas no [edit system configuration-database ephemeral] nível hierárquica, indo da mais alta à menor prioridade.

  2. Declarações na instância padrão do banco de dados efêmero.

  3. Declarações no banco de dados de configuração estático.

Considere a configuração a seguir:

A Figura 1 ilustra a ordem de prioridade das instâncias de banco de dados efêmeras e do banco de dados de configuração estático (comprometido). Neste exemplo, a instância 1 do banco de dados efêmero tem a maior prioridade, seguida pela instância de banco de dados efêmera 2, depois a instância padrão do banco de dados efêmero e, finalmente, o banco de dados de configuração estático.

Figura 1: Instâncias de banco de dados efêmeras Ephemeral Database Instances

Modelo de confirmação geral de banco de dados efêmero

Aplicativos JET e aplicativos de cliente de protocolo NETCONF e Junos XML podem modificar o banco de dados de configuração efêmero. Os aplicativos JET devem enviar solicitações de configuração como pares de carga e confirmar operações. Os aplicativos de cliente de protocolo NETCONF e Junos XML podem realizar várias operações de carga antes de executar uma operação de confirmação.

CUIDADO:

Você deve validar todos os dados de configuração antes de carregá-los no banco de dados efêmero e empenhá-los no dispositivo, porque o comprometimento de dados de configuração inválidos pode fazer com que os processos do Junos reiniciem ou até mesmo a travam e resultem em interrupção no sistema ou na rede.

Os aplicativos do cliente podem carregar e comprometer dados simultaneamente em diferentes instâncias do banco de dados efêmero. Os commits emitidos ao mesmo tempo para diferentes instâncias efêmeras são enfileirados e processados em série pelo dispositivo. Se um cliente se desconectar de uma sessão, o dispositivo descarta qualquer alteração de configuração não comprometida na instância efêmera, mas os dados de configuração que já foram comprometidos com a instância efêmera por esse cliente não serão afetados.

Quando você confirma uma instância efêmera, o sistema valida a sintaxe, mas não a semântica, dos dados de configuração efêmeros. Quando o compromisso é concluído, o dispositivo notifica os processos de sistema afetados. Os processos lêem a configuração atualizada e mesclam os dados efêmeros na configuração ativa de acordo com as regras de priorização descritas em instâncias de banco de dados efêmeras. A configuração ativa do dispositivo é uma visão mesclada dos bancos de dados de configuração estáticos e efêmeros.

Nota:

O tempo de confirmação do banco de dados efêmero será um pouco mais longo em dispositivos que executam o Junos OS Evolved do que em dispositivos que executam o Junos OS devido às diferenças arquitetônicas entre os dois sistemas operacionais.

Para obter informações detalhadas sobre o compromisso e a sincronização de instâncias do banco de dados de configuração efêmera, consulte Confirmar e sincronizar dados de configuração efêmeros usando o PROTOCOLO NETCONF ou Junos XML.

Usando o banco de dados efêmero em dispositivos que usam recursos de alta disponibilidade

Alta disponibilidade refere-se aos componentes de hardware e software que fornecem redundância e confiabilidade para as comunicações de rede. Existem certos comportamentos e advertências que devem ser considerados antes de usar o banco de dados efêmero em sistemas que usam recursos de alta disponibilidade, incluindo mecanismos de roteamento redundantes, switchover gracioso do mecanismo de roteamento (GRES), roteamento ativo sem parar (NSR) e redundância de interchasse para roteadores da Série MX ou switches da Série EX usando Virtual Chassis. As seções a seguir descrevem esses comportamentos e descrevem como o banco de dados efêmero diferente confirma que modelos de sincronização podem afetar esses comportamentos.

Entendendo modelos de sincronização de banco de dados efêmeros

O banco de dados de configuração efêmero tem dois modelos para sincronizar dados de configuração efêmeros em mecanismos de roteamento ou membros do Virtual Chassis durante uma operação de sincronização de compromissos:

  • Assíncronos (padrão)

  • Síncrono

Ao contrário do modelo de confirmação padrão, o modelo de confirmação efêmero padrão executa operações de sincronização de commit assíncronas. O mecanismo de roteamento de solicitação compromete a configuração efêmera e emite uma notificação completa de confirmação sem esperar que o outro mecanismo de roteamento sincronizar e comprometer a configuração primeiro. Os dispositivos que usam recursos de alta disponibilidade exigem que os mecanismos de roteamento primários e de backup sejam sincronizados em caso de falha. No entanto, pode haver situações em que uma operação de sincronização de comprometimento assíncronos 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 os dispositivos que executam o Junos OS Evolved, você pode configurar o banco de dados efêmero para usar um modelo de confirmação síncrono para confirmar operações, semelhante ao modelo usado pelo banco de dados de configuração estático.

Em um ambiente virtual chassis de mecanismo de roteamento duplo ou série MX, o modelo de confirmação síncrono funciona da seguinte forma:

  1. O mecanismo de roteamento primário inicia sua operação de confirmação inicial para a instância efêmera.
  2. Em um determinado ponto durante sua operação de confirmação, 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 confirmação. Se o comprometimento falhar no mecanismo de roteamento de backup, o mecanismo de roteamento primário também falhará no comprometimento.
Nota:

Quando um Virtual Chassis da Série EX usa o modelo de confirmação síncrona, o switch de membro na função principal do Mecanismo de Roteamento inicia a operação de confirmação simultaneamente aos outros membros. Como um Virtual Chassi da Série EX pode ter muitos membros, o switch principal então prossegue com sua operação de confirmação, mesmo que o commit falhe em outro membro.

As operações de confirmação síncronos são mais lentas do que as operações de confirmação assíncronos, mas oferecem uma melhor garantia de que a configuração efêmera é sincronizada entre mecanismos de roteamento e entre membros do Virtual Chassis. Assim, o modelo de confirmação síncronos permite que você use o banco de dados efêmero com maior confiabilidade em dispositivos que também usam recursos de alta disponibilidade.

Nota:

Como é o caso do banco de dados de configuração estática, mesmo com o modelo de sincronização de confirmação síncrona, pode haver circunstâncias raras em que o dispositivo confirma uma configuração efêmera atualizada no mecanismo de roteamento de backup, mas não consegue concluir o compromisso no mecanismo de roteamento primário, resultando em configurações fora de sincronização.

Para habilitar o modelo de sincronização de commit síncronos 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 com o mecanismo de roteamento primário, por exemplo, quando ele é recém-inserido, 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. Em versões anteriores do Junos OS, o mecanismo de roteamento de backup sincroniza apenas seu banco de dados de configuração estático. Para permitir 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.

Nota:

Para sincronização de failover, o mecanismo de roteamento de backup ou o dispositivo de backup MX Virtual Chassis sincroniza apenas o banco de dados de configuração efêmero com o dispositivo principal se o dispositivo de backup e o dispositivo principal estiverem executando a mesma versão de software.

Em dispositivos que executam o Junos OS Release 21.1R1 ou posteriores e os dispositivos que executam o Junos OS Evolved, ambos confirmam operações de sincronização e failover sincronizam as operações sincronizam os dados de configuração efêmeros para 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 duplos suportam a configuração do banco de dados efêmero. No entanto, o modelo de confirmação efêmero não sincroniza automaticamente os dados de configuração efêmeros no mecanismo de roteamento de backup durante uma operação de confirmação. Os aplicativos do cliente podem sincronizar os dados em uma instância efêmera em uma base por commit ou por sessão, ou podem configurar uma instância efêmera para sincronizar automaticamente seus dados cada vez que a instância é comprometida. Para obter mais informações, consulte Confirmar e sincronizar dados de configuração efêmeros usando o protocolo NETCONF ou Junos XML.

Nota:

Os ambientes multichassis não suportam sincronizar o banco de dados de configuração efêmero com os outros mecanismos de roteamento.

Quando um aplicativo cliente compromete dados em uma instância efêmera e os sincroniza ao mecanismo de roteamento de backup, por padrão, o banco de dados efêmero executa a operação de sincronização de commit de forma assíncrona. Você pode configurar o banco de dados efêmero para usar um modelo de confirmação síncronos para confirmar 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 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 encaminhando pacotes, mesmo que um mecanismo de roteamento não opere. O GRES exige que os mecanismos de roteamento primários e de backup sincronizam a configuração e determinadas informações de estado antes que uma switchover ocorra.

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

Nota:

Os dispositivos dual routing Engine que executam o Junos OS Evolved permitem o GRES por padrão.

Não recomendamos usar o banco de dados efêmero com o modelo de sincronização de confirmação assíncronos em dispositivos que tenham o GRES habilitado, pois, em certas circunstâncias, o banco de dados efêmero pode não ser sincronizado entre os mecanismos de roteamento primários e de backup quando ocorre uma switchover. 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 confirmação 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 excluirá 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 o backup e os mecanismos de roteamento primários quando ocorre uma mudança de switch.

Quando o GRES está habilitado e o banco de dados efêmero usa o modelo de confirmação assíncrona (o padrão), você deve configurar explicitamente o dispositivo para sincronizar dados de configuração efêmeros para o mecanismo de roteamento de backup. Para permitir a sincronização, configure a allow-commit-synchronize-with-gres declaração no nível de [edit system configuration-database ephemeral] hierarquia no banco de dados de configuração estática. 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 confirmação assíncronos 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 confirmação nessa instância.

Roteamento ativo sem parar (NSR)

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

Não recomendamos usar o banco de dados efêmero com o modelo de sincronização de commit assíncronos em dispositivos que tenham o NSR habilitado, porque ele vem com certas advertências. Em uma implantação com dois mecanismos de roteamento, 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íncrona 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 compromisso 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 anteriores, 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 pela 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 partes modificadas da configuração de instâncias efêmeras quando ele confirma 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, de modo que ele só notifica processos correspondentes a declarações que são alteradas.

Nota:

Os aplicativos que utilizam o banco de dados efêmero só são afetados nesta situação do NSR se interagirem com o processo de protocolo de roteamento. Por exemplo, o SmartWall Threat Defense Director (SmartWall TDD) não seria afetado neste caso, porque ele só interage com o processo de firewall (dfwd) através do banco de dados efêmero.

Chassi virtual da Série MX

A partir do Junos OS Release 20.2R1, o Virtual Chassis da Série MX oferece suporte à configuração do banco de dados efêmero. Você pode configurar e confirmar uma instância efêmera apenas 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êmero durante uma operação de confirmação. Como acontece com sistemas de mecanismo de roteamento duplos, você pode sincronizar os dados em uma instância efêmera em uma base por commit ou por sessão, ou você pode configurar uma instância efêmera para sincronizar automaticamente seus dados cada vez que a instância é comprometida. Os dados efêmeros são sincronizados apenas desde o mecanismo de roteamento primário no dispositivo principal até o mecanismo de roteamento primário no dispositivo de backup.

Nota:

O Virtual Chassis da Série MX não sincroniza, em nenhuma circunstância, dados de configuração efêmeros desde o mecanismo de roteamento primário até o mecanismo de roteamento de backup no respectivo membro Virtual Chassis.

O Virtual Chassis 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 commit síncronos, o dispositivo sincroniza a instância efêmera para o outro Mecanismo de roteamento quando você solicita uma operação de sincronização de confirmação. No entanto, se o banco de dados efêmero usar o modelo de sincronização de commit assíncronos (o 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 a sincronização. Veja a compreensão dos modelos de sincronização do banco de dados Efêmero para obter mais informações sobre os modelos de confirmação de banco de dados efêmeros.

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

  1. O dispositivo principal do Virtual Chassis valida a sintaxe de configuração e confirma 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 confirma a instância efêmera apenas em seu mecanismo de roteamento primário. Se a operação de confirmação falhar, o dispositivo de backup registra uma mensagem no arquivo de log do sistema, mas não notifica o dispositivo principal.

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

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

  2. Em um determinado ponto de sua operação de confirmação, 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 prosseguirá com sua operação de confirmação. Se o dispositivo de backup não confirmar a configuração, o dispositivo principal também falhará no commit.

Como descrito, quando você usa o modelo de sincronização de commit assíncronos 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 commit síncronos, o commit pode ter sucesso ou falhar em ambos os mecanismos de roteamento primários, exceto em circunstâncias raras.

O Virtual Chassis 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 [edit system] nível de 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.

Nota:

Para sincronização de failover, o dispositivo de backup MX Virtual Chassis sincroniza apenas o banco de dados de configuração efêmero com o dispositivo principal se ambos os dispositivos estiverem executando a mesma versão de software.

Chassi virtual da Série EX

O Virtual Chassis da Série EX oferece suporte ao banco de dados de configuração efêmero. Você só pode configurar e confirmar uma instância efêmera no switch de membro na função principal do Mecanismo de Roteamento. A partir do Junos OS Release 23.4R1, você pode sincronizar o banco de dados efêmero entre os membros do Virtual Chassis da Série EX.

Um chassi virtual da Série EX não sincroniza automaticamente nenhum dados de configuração efêmero durante uma operação de confirmação. Você pode sincronizar os dados em uma instância efêmera em uma base por commit ou por sessão, ou pode configurar uma instância efêmera para sincronizar automaticamente seus dados cada vez que a instância é comprometida.

Você pode configurar o GRES em um chassi virtual da Série EX para permitir que o Virtual Chassis continue encaminhando pacotes se o mecanismo de roteamento primário falhar. Se você configurar o banco de dados efêmero para usar o modelo de sincronização de commit síncronos, o dispositivo sincroniza a instância efêmera para os outros membros quando você solicita uma operação de sincronização de confirmação. No entanto, se o banco de dados efêmero usar o modelo de sincronização de commit assíncronos (o padrão) e o GRES estiver configurado, você deve configurar explicitamente a allow-commit-synchronize-with-gres declaração no banco de dados de configuração estática para permitir a sincronização.

Quando você confirma e sincroniza uma instância efêmera em um Chassi Virtual da Série EX que usa o modelo de sincronização de commit assíncronos:

  1. O switch de membro na função principal do mecanismo de roteamento valida a sintaxe de configuração e confirma a instância efêmera.

  2. Se o compromisso for bem-sucedido, o dispositivo principal notifica o commit-syncd processo, que inicia o compromisso em cada switch de membro por sua vez.

  3. Cada switch de membro confirma a instância efêmera. Se a operação de confirmação falhar em qualquer membro, ela não afetará a operação de confirmação dos outros membros.

Quando você confirma e sincroniza uma instância efêmera em um Chassi Virtual da Série EX que é configurado para usar o modelo de sincronização de commit síncronos:

  1. O switch de membro na função principal do Mecanismo de Roteamento inicia o compromisso em todos os switches de membro simultaneamente.

  2. Cada switch de membro confirma a instância efêmera e notifica o switch principal. Se a operação de confirmação falhar em qualquer membro, ela não afetará a operação de confirmação dos outros membros.

  3. Após receber respostas de todos os switches de membros, o switch principal confirma a instância efêmera.

Conforme descrito, no modelo assíncrona, o switch principal conta com o commit-syncd processo para iniciar os compromissos em cada switch membro sequencialmente. Se o commit-syncd processo falhar por qualquer motivo, alguns compromissos podem não ser iniciados. No modelo de confirmação síncronos, o switch principal inicia o commit em todos os switches de membros diretamente e em paralelo. Assim, o modelo de confirmação síncrona é geralmente mais confiável do que o modelo de confirmação assíncrona. Em ambos os casos, se o compromisso falhar em um membro, ele não impacta ou impede o compromisso com os outros membros.

Além disso, no modelo de confirmação síncrona, o switch principal exibe o progresso de comprometimento para cada membro conforme o compromisso ocorre. No modelo assíncronos, os confirmadores ocorrem em segundo plano, portanto, neste caso, o dispositivo primário apenas registra os resultados de confirmação.

Melhores práticas de banco de dados efêmeros

O banco de dados de configuração efêmero permite que vários aplicativos façam mudanças rápidas na configuração simultaneamente. Como o banco de dados de configuração efêmero não usa as mesmas proteções que o banco de dados de configuração estática, você deve considerar cuidadosamente como você usa o banco de dados efêmero. Recomendamos seguir essas melhores práticas para otimizar o desempenho e evitar problemas potenciais quando você usa o banco de dados de configuração efêmero.

Regular a frequência de confirmação

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

Por exemplo, se você executar confirmações frequentes e rápidas, o dispositivo pode substituir determinados dados de configuração que armazena em arquivos externos antes que um processo junos leia a atualização anterior. Se um processo Junos perder uma atualização importante, o dispositivo ou a rede podem apresentar 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 a sintaxe e a semântica.

Além disso, você deve sempre carregar dados de configuração relacionados em um único banco de dados. Incluir 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 confirmação. 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 causar a validação e, portanto, o comprometimento, falhar.

Consolidar configurações em escala

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, as otimizações internas permitem que os processos do Junos consumam a configuração de forma mais eficiente. Como alternativa, se você espalhar a configuração por 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.

Tabela de histórico de mudanças

O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.

Soltar
Descrição
20.2R1
Quando você configura a commit synchronize declaração no nível de hierarquia no [edit system] banco de dados de configuração estática e o mecanismo de roteamento de backup sincroniza com o mecanismo de roteamento primário, por exemplo, quando ele é recém-inserido, 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.
18.2R1
A partir do Junos OS Release 18.2R1, os dispositivos que executam o Junos OS suportam a configuração de até sete instâncias definidas pelo usuário do banco de dados de configuração efêmero. Em versões anteriores, você pode configurar até oito instâncias definidas pelo usuário.