Principais diferenças entre o Junos OS Evolved e o Junos OS

Diferenças no sistema

O conceito de sistema no Junos OS Evolved é diferente do Junos OS. O Junos OS usa um modelo centrado no mecanismo de roteamento, onde o sistema geralmente se refere a um mecanismo de roteamento. No entanto, o Junos OS Evolved usa um modelo baseado em nós, onde o sistema se refere a todos os nós, incluindo mecanismos de roteamento, concentradores PIC flexíveis (FPCs) e muito mais. No Junos OS Evolved, um nó é qualquer componente que pode executar o kernel linux e os aplicativos Junos OS Evolved, e todos os nós são considerados nós de computação.

Impacto operacional

No Junos OS Evolved, você pode realizar muitas ações por nó. Você pode usar comandos CLI para visualizar informações e solicitar operações em nós individuais.

Comandos CLI relevantes

• show system nodes — Veja uma lista de todos os nós no sistema.

• show node ( reboot | statistics ) node-name — Veja informações sobre um nó específico.

• show system applications <node node-name> — Exibir informações resumidas do aplicativo para todos os nós ou um nó específico.

• show system core-dumps <node node-name> — Mostrar arquivos de núcleo do sistema para todos os nós ou um nó específico.

• show system errors active— Use este comando em vez do comando para visualizar informações de erro do show chassis errors active sistema.

• show system processes <node node-name> <detail> — Exibir informações do processo para todos os nós ou um nó específico.

• show system storage node ( re0 | re1 | fpc0 | fpc1 | ...) — Visualize o espaço gratuito do disco para um nó específico.

• show version node ( all | node-name ) — Exibir informações de versão de software para todos os nós ou um nó específico.

• request node ( halt | offline | online | power-off/on | reboot ) node-name — Solicite uma operação em um nó específico.

• request system reboot — No Junos OS Evolved este comando reiniciará todos os nós.

Estrutura de software e aplicativos

O Junos OS Evolved funciona como um sistema operacional Linux distribuído com processos em execução como aplicativos autônomos. Todo processo Junos OS Evolved é executado como um aplicativo. Todos os aplicativos Junos OS Evolved são gerenciados pelo systemd processo usando unidades de serviço. Os aplicativos são executados como serviços separados, o que oferece isolamento de falhas porque você pode reiniciar um aplicativo separadamente sem afetar outros aplicativos. A maioria dos aplicativos publica e consome estado, que é armazenado em um banco de dados central.

Impacto operacional

No Junos OS Evolved, muitos recursos de alta disponibilidade são por aplicativo e não por nó. Alguns aplicativos executam um backup em tempo integral para falha rápida, enquanto outros aplicativos são reiniciados em um novo nó no caso de uma falha.

Comandos CLI relevantes

• show system applications <node node-name> — Exibir informações resumidas do aplicativo para todos os nós ou um nó específico.

• restart process — No Junos OS este comando reinicia um processo específico. No Junos OS Evolved, o mesmo comando reinicia um aplicativo (processo) específico no mesmo nó do qual o comando é emitido.

• request system application restart app application node node — Esse comando é específico do Junos OS Evolved e reinicia um aplicativo específico em um nó específico.

Modelo de estado

O Junos OS Evolved usa uma infraestrutura de estado distribuída. Os aplicativos publicam ou se inscrevem em objetos de estado, que são armazenados em um banco de dados estatal chamado DDS (Distributed Data Store, Loja de dados distribuídos) que é distribuído em nós. Em comparação, os processos do Junos OS armazenam o estado internamente, trocando informações de estado e mudanças de estado com outros processos por meio do kernel. O modelo de estado Junos OS Evolved é assíncrono e eventualmente consistente na camada de transporte com consistência causal na camada de aplicativo ao acessar o estado. Isso significa que, se um processo for reiniciado no Junos OS Evolved, as informações não se perderão porque elas podem recuperar informações de estado do DDS.

Impacto operacional

O modelo de estado Junos OS Evolved leva a um desempenho mais rápido porque você não precisa esperar que o componente mais lento seja atualizado. Os aplicativos leem e escrevem para o estado do sistema sem esperar que todos os outros processos preencham as primeiras atualizações. Se um aplicativo for reiniciado, o estado será preservado e recuperado do DDS pela nova instância, mesmo que o aplicativo seja gerado em um nó diferente.

Gerenciamento de software

Cada vez que você instala uma imagem de software no Junos OS Evolved, a imagem e a configuração do software anterior são preservadas automaticamente. O Junos OS Evolved armazena imagens de software no /soft directory. Cada versão do software é armazenada em uma área distinta, garantindo assim que uma instalação de pacotes de software não afete as outras versões de software instaladas no sistema. Enquanto o Junos OS oferece suporte à instalação de duas versões de software no dispositivo, o Junos OS Evolved oferece suporte ao armazenamento de tantas imagens de software quanto o espaço permite. No entanto, recomendamos que você mantenha não mais do que cinco versões de software no sistema.

Durante uma instalação bem-sucedida, o pacote de instalação reinstala completamente o software existente. Ele retém arquivos de configuração e informações semelhantes, como o secure shell e as chaves do host, da versão anterior. Quando você reinicia o sistema após a instalação de um pacote de software, todos os mecanismos de roteamento e FPCs no sistema executam a nova versão do software.

Impacto operacional

O Junos OS Evolved garante que todos os mecanismos de roteamento e FPCs do sistema estejam executando a mesma versão de software. Quando você instala uma imagem de software no mecanismo de roteamento primário, o sistema instala a nova versão do software em ambos os mecanismos de roteamento, se os mecanismos de roteamento estiverem on-line e parte do sistema. Se você inserir um mecanismo de roteamento que tenha uma versão de software diferente no sistema e não tiver configurado a system auto-sw-sync enable declaração, o mecanismo de roteamento é mantido fora do sistema e o sistema gera um alarme de incompatibilidade de software.

Quando você instala uma nova imagem de software, o pacote de software anterior é preservado em uma área separada, e você pode reverter manualmente para ele, se necessário. O Junos OS Evolved permite que você reverta para uma imagem alternativa com o arquivo de configuração atual ou com o instantâneo de configuração de quando a imagem alternativa estava sendo executada pela última vez.

Comandos CLI relevantes

• show system software list — No Junos OS Evolved, veja as imagens instaladas atualmente em cada nó.

• show system storage — Visualize o espaço de armazenamento disponível. No Junos OS Evolved, os /soft, /var e /data directories devem ter menos de 90% de capacidade para instalar imagens adicionais.

• request system software delete — Limpe imagens antigas. A partir do Junos OS Evolved Release 20.1R1, use este comando em vez do request system storage cleanup comando para remover imagens ISO do sistema.

• request system snapshot — Tire um instantâneo dos arquivos usados atualmente para executar o dispositivo e copie os arquivos na unidade de estado sólido alternativo (SSD). O instantâneo inclui o conteúdo completo do /soft, /config, e /root directories, cópias de dados do usuário e conteúdo do diretório /var (exceto o /var/core, /var/externo, /var/log e /var/tmp directories).

• request system software rollback reboot <package-name> <with-old-snapshot-config> — Reverta todos os mecanismos de roteamento e FPCs para outra versão de software e reinicialização. Inclua a opção with-old-snapshot-config de usar a configuração salva que corresponde à imagem do software de reversão.

• request system software sync ( all-versions | current | rollback ) — Sincronizar o software e as configurações desde o mecanismo de roteamento primário até os outros nós e reiniciar os outros nós.

• set system auto-sw-sync enable — Sincronizar automaticamente o software e a configuração do mecanismo de roteamento primário para um mecanismo de roteamento e reinicialização recém-adicionados, quando o mecanismo de roteamento recém-adicionado tem uma versão de software diferente do resto do sistema.

Interfaces de gerenciamento

No Junos OS Evolved, as interfaces de gerenciamento são renomeadas para acomodar mais de uma porta de gerenciamento por nó routing Engine.

Impacto operacional

As interfaces de gerenciamento no Junos OS Evolved não usam os mesmos nomes que o Junos OS (fxp0, em0, ). me0 Em vez disso, o formato de nome da interface de gerenciamento Junos OS Evolved é device-name:type-port. Por exemplo: re0:mgmt-0, re0:mgmt-1, , re1:mgmt-0. re1:mgmt-1

A show interfaces saída exibe o status de todas as interfaces, incluindo interfaces Ethernet de gerenciamento de ambos os mecanismos de roteamento de um sistema de mecanismo de roteamento duplo.

Nomes de host do sistema

No Junos OS Evolved, os nomes de host do sistema são anexadas com um número correspondente do mecanismo de roteamento, como -re0 ou -re1.

Impacto operacional

No Junos OS Evolved, quando você especifica a host-name declaração, o nome atual do Mecanismo de Roteamento é anexada ao hostname que você especifica. Por exemplo, no mecanismo de roteamento 0, set system host-name my-host define o nome de host para my-host-re0. Você também pode usar o %s personagem para designar onde substituir o nome do mecanismo de roteamento. Por exemplo, no mecanismo de roteamento 1, set system host-name %s_my_host define o nome de host para re1_my-host .

Comandos CLI relevantes

• set system host-name hostname

Filtros de firewall de mecanismo de roteamento

No Junos OS, para controlar o fluxo de pacotes locais entre as interfaces físicas e o Mecanismo de Roteamento, você pode aplicar filtros de firewall sem estado na entrada ou saída da interface de loopback. A interface de loopback (lo0) é a interface para o Mecanismo de Roteamento e não transporta pacotes de dados. No Junos OS, os filtros aplicados à interface de loopback aplicam-se tanto ao tráfego de controle de rede quanto ao tráfego de gerenciamento.

O Junos OS Evolved, por outro lado, oferece suporte a dois filtros diferentes para controlar o fluxo de pacotes locais: um para o tráfego de controle de rede (tráfego de loopback) e outro para o tráfego de gerenciamento. Assim, os filtros aplicados à interface de loopback aplicam-se apenas ao tráfego de controle de rede. Você também pode aplicar filtros separadamente na interface de gerenciamento, o que permite configurar um filtro mais rigoroso no tráfego de gerenciamento.

Impacto operacional

No Junos OS Evolved, os filtros de firewall aplicados à interface de loopback aplicam-se apenas ao tráfego de controle de rede. Você deve aplicar explicitamente filtros de firewall na interface de gerenciamento para filtrar o tráfego de gerenciamento. No Junos OS Evolved, a filtragem de gerenciamento usa filtros de mecanismo de roteamento baseados no Netfilter, uma estrutura que o kernel linux fornece. Como resultado, apenas certas partidas e ações são apoiadas. A Tabela 1 descreve o aplicativo de filtro Junos OS Evolved.

Junos OS Evolved Network Stack

O Junos OS Evolved é executado em Linux nativo. Existem algumas diferenças entre a forma como o Linux exibe informações de topologia de rede solicitadas, como interface e dados de rota, e a forma como o Junos OS exibe essas informações. O Junos OS Evolved CLI foi projetado para superar essas diferenças. Assim, recomendamos que você use comandos CLI em vez de comandos shell para quaisquer operações de rede, especialmente para operações que exijam especificar uma instância de roteamento.

Se você deve realizar operações na concha do Linux ao usar o Junos OS Evolved, você precisa saber sobre as seguintes instâncias de roteamento, também conhecidas como instâncias de roteamento e encaminhamento virtual (VRFs):

• default— lida com o tráfego de WAN e gerenciamento por padrão, a menos que você configure a mgmt_junos instância de roteamento.
• mgmt_junos— Quando você configura essa instância de roteamento, ela coloca a porta de gerenciamento em sua própria instância de roteamento, que separa o tráfego de gerenciamento do tráfego WAN para o mecanismo de roteamento.

• iri— Lida com o tráfego de plano de controle (comunicação interno). No Junos OS Evolved CLI, isso equivale à __juniper_private1__ instância de roteamento.

Impacto operacional

Na shell Junos OS Evolved, você pode usar o chvrf utilitário (alterar VRF) para executar um comando no contexto de uma instância de roteamento específica, ou VRF. Por exemplo:

Registro de sistema

No Junos OS Evolved, cada nó tem a ferramenta padrão journalctl , que é uma interface para recuperar e filtrar a revista do sistema. As mensagens de log do sistema são analisadas na revista do sistema. O relay-eventd processo é executado em todos os nós e recupera eventos (com base na configuração do syslog) da revista do sistema, bem como mensagens de erro dos diferentes aplicativos e os encaminha para o master-eventd processo. O master-eventd processo é executado no mecanismo de roteamento primário e escreve as mensagens de log e erros em disco.

Use o aplicativo System Log Explorer para visualizar ou comparar mensagens de log do sistema em diferentes versões.

Impacto operacional

No Junos OS Evolved, não há nenhum messages arquivo no mecanismo de roteamento de backup. Todos os logs do messages mecanismo de roteamento de backup estão no arquivo do nó principal do mecanismo de roteamento.

Formato de mensagem de log do sistema

Por padrão, o Junos OS Evolved anexa o nome do nó ao nome de host em mensagens de log do sistema; O Junos OS não. Essa ação mantém as mensagens de log do sistema Junos OS Evolved em conformidade com RFC5424. No entanto, alguns sistemas de monitoramento podem não identificar corretamente um nome de host Junos OS Evolved, porque a combinação de nome de host não corresponde a nenhum nome de host no inventário de nomes de host.

Impacto operacional

Se o seu sistema de monitoramento não estiver identificando nomes de host evoluídos do Junos OS corretamente, você deve emitir o comando do set system syslog alternate-format modo de configuração. Esse comando muda o formato das mensagens de log do sistema Junos OS Evolved. O nome do nó está pré-preparado para o nome do processo na mensagem em vez de anexo ao nome do host, permitindo assim que o sistema de monitoramento identifique o nome do host corretamente.

Arquitetura de rastreamento

O Junos OS Evolved usa uma nova arquitetura de rastreamento. Todos os aplicativos em execução criam trace information, com várias instâncias do mesmo aplicativo tendo suas próprias informações de rastreamento. O Junos OS Evolved trace-relay e trace-writer os aplicativos coordenam as informações de rastreamento. O trace-relay aplicativo é executado em nós locais e compartilha um buffer de memória com cada aplicativo. Quando um aplicativo Junos OS Evolved escreve para a memória, o trace-relay aplicativo lê os dados diretamente da memória e os envia para os trace-writer aplicativos. Um trace-writer aplicativo é executado em cada nó do Mecanismo de Roteamento. Ele recebe as informações de rastreamento enviadas dos aplicativos e as trace-relay escreve ao arquivo apropriado em Formato de Rastreamento Comum (CTF).

Impacto operacional

No Junos OS, você permite o rastreamento de operações configurando a traceoptions declaração no nível de hierarquia específico que você deseja rastrear. O Junos OS Evolved, por outro lado, usa um modelo baseado em aplicativos e, portanto, as mensagens de rastreamento são registradas, visualizadas e configuradas por aplicativo. Como resultado, o Junos OS Evolved não suporta a traceoptions declaração em muitos dos níveis hierárquicos que o Junos OS suporta. No entanto, alguns níveis de hierarquia, como os de baixo [edit protocols], ainda exigem a configuração da traceoptions declaração para permitir o rastreamento de mensagens.

Embora o Junos OS desativa as operações de rastreamento global para muitos níveis de hierarquia por padrão, alguns processos registram mensagens de rastreamento por padrão para eventos importantes. Por outro lado, todos os aplicativos em execução no Junos OS Evolved criam informações de rastreamento no info nível por padrão.

No Junos OS Evolved, você não visualiza arquivos de rastreamento diretamente, e nunca deve adicionar, editar ou remover arquivos de rastreamento sob o diretório /var/log/traces , porque isso pode corruptor os vestígios. Em vez disso, você usa o show trace application application-name node node-name comando para ler e decodificar mensagens de rastreamento armazenadas nos arquivos de rastreamento.

Comandos CLI relevantes

• show trace application application-name node node-name — Ler e decodificar arquivos de rastreamento.

• clear trace — Limpe manualmente os arquivos de rastreamento.

• set system trace application — Modifique as configurações de trace message no nível do aplicativo.