Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Entenda a atualização ininterrupta de software em um chassi virtual e chassi virtual misto

A atualização ininterrupta de software (NSSU) permite que você atualize o software em execução em todos os switches de membros em um Virtual Chassis com um mínimo de interrupção no tráfego de rede durante a atualização. Este tópico descreve o NSSU sobre a Série EX e o Chassi Virtual da Série QFX que oferecem suporte a esse recurso.

Veja essas outras referências para obter informações sobre o uso do NSSU nas seguintes plataformas específicas:

Nota:

Como o NSSU atualiza o software em cada membro do Virtual Chassis um de cada vez, a atualização usando o NSSU pode levar mais tempo do que um upgrade usando o request system software add comando.

Você pode reduzir o tempo que um upgrade leva configurando grupos de upgrade de placa de linha em um Virtual Chassis maior que oferece suporte a esse recurso. O Virtual Chassis atualiza os switches de membros em um grupo de upgrade simultaneamente, reduzindo o tempo necessário para realizar um upgrade. Veja a configuração de grupos de atualização de placas de linha para atualização ininterrupta de software.

Benefícios do NSSU

  • Sem interrupções no plano de controle — o NSSU usa switchover gracioso do mecanismo de roteamento (GRES) (e roteamento ativo ininterrupto (NSR) em plataformas aplicáveis) para garantir que nenhuma interrupção ocorra no plano de controle. Durante o processo de atualização, o Virtual Chassis preserva as informações de protocolo de interface, kernel e roteamento.

  • Interrupção mínima no tráfego de rede — o NSSU minimiza a interrupção do tráfego da rede atualizando switches de membros um de cada vez, permitindo que os membros primários e de backup mantenham suas funções primárias e de backup (embora a função primária mude) sem interromper o tráfego e permitindo que o tráfego continue a fluir através de membros na função de placa de linha que não estão sendo atualizados.

Requisitos para realizar um NSSU

Os requisitos para realizar o NSSU para um Virtual Chassis incluem:

  • Todos os membros do Virtual Chassis e todos os Mecanismos de roteamento devem estar executando a mesma versão do Junos OS.

  • Você deve habilitar o switchover gracioso do mecanismo de roteamento (GRES).

  • Você deve habilitar o roteamento ativo (NSR) sem parar para as plataformas aplicáveis.

    Embora a ponte sem interrupções (NSB) não seja necessária para realizar um NSSU, também recomendamos habilitar o NSB antes de realizar um NSSU em plataformas aplicáveis. O NSB garante que todos os protocolos de Camada 2 suportados por NSB operem perfeitamente quando o mecanismo de roteamento é substituído durante o NSSU. Veja configuração de pontes ininterrupta em switches (procedimento CLI).

  • Para minimizar a interrupção do tráfego, você deve configurar grupos de agregação de enlaces (LAGs) de modo que os links de membros de cada LAG residam em diferentes membros do Virtual Chassis e configurem o Protocolo de controle de agregação de enlaces (LACP) para monitorar os estados de link membros do LAG. Quando um link de membro de um LAG está desativado, os links restantes estão em alta e o tráfego continua a fluir pelo LAG. Para obter mais informações sobre a configuração de LAGs e LACP, consulte Configurando a agregação de enlaces e configurando o PROCEDIMENTO Ethernet LACP agregado (CLI).

    Nota:

    Quando você atualiza um switch da Série EX em um Virtual Chassis misto para o Junos OS Release 15.1 ou posterior de um lançamento antes do lançamento 15.1, pode haver uma queda no tráfego por até 60 segundos.

    Nota:

    Durante uma operação NSSU, se você tentar visualizar o status da interface LAG no membro principal do mecanismo de roteamento usando o show interfaces ae-ae-interface-number comando CLI, você pode ver contagens de tráfego incorretas ou zero. Para resolver esse problema, execute o comando no membro do mecanismo de roteamento de backup, em vez disso, se esse membro já estiver carregado e em execução.

Requisitos para o Virtual Chassis ou membros mistos do Virtual Chassis que estão sendo atualizados usando o NSSU:

  • Os switches de membro devem ser conectados em uma topologia em anel para que nenhum membro seja isolado como resultado da reinicialização de outro membro. Essa topologia impede que o Virtual Chassis se separe durante um NSSU.

  • Os switches de membro principal e backup devem estar adjacentes entre si na topologia do anel. A colocação adjacente garante que o principal e o backup estejam sempre em sincronia enquanto os switches de membros em funções de cartão de linha estão sendo reiniciados.

  • O Virtual Chassis é pré-provisionado e você atribui explicitamente a função de placa de linha aos switches membros que atuam em uma função de placa de linha. Os switches primários e de backup do Virtual Chassis mudam a função primária enquanto um ou outro está sendo atualizado durante a NSSU, mas eles devem manter suas funções primárias e de mecanismo de roteamento de backup, e os switches restantes devem manter suas funções de placa de linha.

  • Um Virtual Chassis de dois membros deve ter no-split-detection sido configurado para que o Virtual Chassis não se divida quando um NSSU atualiza um membro. Veja entender a divisão e a fusão em um virtual Chassis.

Nota:

Em um Virtual Chassis EX4300 que executa uma versão Junos OS 13.2X50, você deve habilitar a declaração de tempo sem espera no nível [edit virtual-chassis] de hierarquia antes de realizar uma atualização de software usando o NSSU. Sem essa opção configurada, o Virtual Chassis pode ser dividido durante a atualização. Um Virtual Chassis dividido pode causar interrupções em sua rede, e você pode ter que reconfigurar manualmente seu Virtual Chassis após o NSSU se o recurso de separação e fusão for desativado. Para obter mais informações sobre um Virtual Chassis dividido, veja Entender a divisão e a fusão em um Virtual Chassis. Essa declaração afeta apenas o Virtual Chassis EX4300 ou o Virtual Chassis misto que contêm switches EX4300.

Como um NSSU funciona em um virtual Chassis e chassi virtual misto

Quando você solicita um NSSU em um Virtual Chassis ou Virtual Chassis misto:

  1. A primária do Virtual Chassis verifica que:

    • O backup está on-line e executando a mesma versão de software.

    • Você habilitou o switchover gracioso do mecanismo de roteamento (GRES) e, se aplicável, o roteamento ativo ininterrupto (NSR).

    • Você usou uma configuração pré-provisionada para configurar o Virtual Chassis.

  2. O principal copia a nova imagem de software para o backup e os membros restantes da função de cartão de linha em sequência usando rcp.

    (Apenas para QFX5100 Virtual Chassis) Começando pelo Junos OS Release 14.1X53-D40, para otimizar o tempo necessário para concluir uma operação NSSU para um Virtual Chassis, o principal usa sessões paralelas rcp para copiar o novo software para vários membros de cada vez (em vez de esperar que a operação de cópia seja concluída para cada membro antes de começar a copiar a imagem do software para o próximo membro). O principal usa um algoritmo padrão para determinar o número de operações de cópia paralelas com base no número de membros no Virtual Chassis, ou você pode configurar um número específico usando a declaração de rcp-count configuração. Veja detalhes da contagem de informações .

    Nota:

    Se a cópia do novo software para qualquer membro falhar, o NSSU encerra o processo de atualização de todo o Virtual Chassis sem reiniciar nenhum membro e registrar a condição de erro. Começando pelo Junos OS Release 14.1X53-D40, se uma operação de cópia do NSSU para um membro falhar, a primária executa uma medida adicional de recuperação de erros para remover o novo software dos membros para o qual ele já foi transferido.

  3. O principal reinicia o switch de membro de backup com o novo software, e o backup se ressincroniza com o principal.

  4. As cargas primárias e reinicializa os switches de membros que estão na função de cartão de linha, um de cada vez. A expectativa principal é que cada membro se torne on-line e ativo executando o novo software antes de reiniciar o próximo membro.

    • Se você configurou grupos de atualização, os membros do Virtual Chassis no primeiro grupo de atualização carregarão a nova imagem e reiniciarão. Quando os membros desse grupo de atualização estiverem on-line novamente, os membros do próximo grupo de upgrade carregam a nova imagem e reiniciam. (O NSSU atualiza os grupos na ordem em que eles aparecem na configuração.)

    • O tráfego continua a fluir pelos outros membros durante esse processo.

  5. A reinicialização continua até que todos os membros ativos tenham reiniciado com o novo software.

    Nota:

    Se algum membro da função de placa de linha não conseguir reiniciar com sucesso, o NSSU encerra o processo de atualização e registra a condição de erro. Neste caso, para evitar a instabilidade do Virtual Chassis, você deve fazer o backup da atualização parcial restaurando o software antigo e reiniciando os membros que já foram reiniciados com o novo software, ou tentar reiniciar manualmente todos os membros com o novo software que foi copiado para eles, para que todos os membros voltem a estar on-line executando a mesma versão do software.

    Começando pelo Junos OS Release 14.1X53-D40, a NSSU invoca automaticamente medidas de recuperação se a reinicialização falhar em qualquer membro da função de placa de linha, interrompendo o processo de reinicialização sequencial e derrubando e reiniciando todo o Virtual Chassis. O Virtual Chassis então traz todos os membros ao mesmo tempo em que executa o novo software, o que recupera a estabilidade do Virtual Chassis mais rapidamente do que ter um Virtual Chassis instável executando diferentes versões do software tentando convergir.

  6. Após a atualização primária de todos os membros na função de cartão de linha, ele executa um switchover gracioso do Mecanismo de Roteamento e o switch de membro de backup atualizado torna-se o novo principal.

  7. O novo principal atualiza o software na primária original e o reinicia automaticamente. Depois que a primária original tiver voltado ao Virtual Chassis, você pode reverter opcionalmente a função primária para esse switch solicitando explicitamente outro switchover gracioso do Mecanismo de Roteamento.

Limitações do NSSU

Você não pode usar o NSSU para rebaixar o software — ou seja, para instalar uma versão anterior do software do que está sendo executado no switch no momento. Para instalar uma versão de software anterior, use o request system software add comando.

Você não pode voltar à versão de software anterior depois de realizar uma atualização usando o NSSU. Se você precisar voltar para a versão de software anterior, você pode reiniciar a partir da partição raiz alternativa se ainda não tiver copiado a nova versão de software na partição raiz alternativa.

Suporte para versão do NSSU e Junos OS

O NSSU funciona apenas em algum Virtual Chassis com versões específicas do Junos OS e do Junos. Entre em contato com o Centro de Assistência Técnica (JTAC) da Juniper Networks para confirmar o suporte e a versões se você estiver considerando atualizar seu Virtual Chassis usando o NSSU.

Se o Virtual Chassis estiver executando uma versão de software que não ofereça suporte ao NSSU ou não ofereça suporte à combinação de e aos lançamentos com NSSU, use o request system software add comando para atualizar os switches de membro no Virtual Chassis individualmente.

Você também pode consultar este exemplo de configuração de rede sobre como atualizar manualmente um Chassi Virtual da Série QFX de dois membros com impacto mínimo no fluxo de tráfego quando o NSSU não é suportado:

Visão geral da configuração e operação do NSSU

Para que o NSSU tenha sucesso, o Virtual Chassis e os switches de membros devem atender aos requisitos de execução de um NSSU. O NSSU requer apenas essas etapas de configuração.

Se o seu Virtual Chassis atender aos requisitos do NSSU, basta digitar o comando para iniciar o request system software nonstop-upgrade NSSU. Veja atualização de software em um virtual Chassis e chassi virtual misto usando upgrade de software sem parar para obter detalhes.

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.

Lançamento
Descrição
14,1X53-D40
(Apenas para QFX5100 Virtual Chassis) Começando pelo Junos OS Release 14.1X53-D40, para otimizar o tempo necessário para concluir uma operação NSSU para um Virtual Chassis, o principal usa sessões paralelas rcp para copiar o novo software para vários membros de cada vez (em vez de esperar que a operação de cópia seja concluída para cada membro antes de começar a copiar a imagem do software para o próximo membro).
14,1X53-D40
Começando pelo Junos OS Release 14.1X53-D40, se uma operação de cópia do NSSU para um membro falhar, a primária executa uma medida adicional de recuperação de erros para remover o novo software dos membros para o qual ele já foi transferido.
14,1X53-D40
Começando pelo Junos OS Release 14.1X53-D40, a NSSU invoca automaticamente medidas de recuperação se a reinicialização falhar em qualquer membro da função de placa de linha, interrompendo o processo de reinicialização sequencial e derrubando e reiniciando todo o Virtual Chassis.