Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

A atualização ininterrupta de software (NSSU) permite atualizar o software em execução em todos os switches membros em um Virtual Chassis com interrupção mínima 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 este recurso.

Veja essas outras referências para 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, atualizar usando o NSSU pode levar mais tempo do que uma atualização usando o request system software add comando.

Você pode reduzir o tempo que uma atualização leva configurando grupos de atualização de placas de linha em chassis virtuais maiores que oferecem suporte a esse recurso. O Virtual Chassis atualiza os switches de membros em um grupo de atualização simultaneamente, reduzindo o tempo necessário para completar uma atualização. Veja a configuração de grupos de atualização de placas de linha para atualização sem parar de software.

Benefícios do NSSU

  • Sem interrupções no plano de controle — o NSSU usa switchover gracioso de 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 os switches 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 principal mude) sem interromper o tráfego, e permitindo que o tráfego continue a fluir através dos membros na função de placa de linha que não estão sendo atualizadas.

Requisitos para realizar um NSSU

Os requisitos para realizar o NSSU para um chassi virtual 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 plataformas aplicáveis.

    Embora a ponte sem parar (NSB) não seja necessária para realizar uma NSSU, também recomendamos a habilitação de 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 for implementado durante o NSSU. Veja a configuração de ponte sem parar em switches (procedimento de CLI).

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

    Nota:

    Quando você atualiza um switch da Série EX em um Virtual Chassi 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 de 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 do Virtual Chassis que estão sendo atualizados usando NSSU:

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

  • Os switches de membro principal e de backup devem estar adjacentes uns aos outros 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 placa de linha estão sendo reiniciados.

  • O Virtual Chassis é pré-provisionado e você atribuiu explicitamente a função de placa de linha aos switches membros que atuam em uma função de placa de linha. Os switches de membro principal e de backup do Virtual Chassis mudam a função principal enquanto um ou outro está sendo atualizado durante o 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 configurado para que o Virtual Chassis não se divida quando um NSSU atualiza um membro. Veja a compreensão da divisão e da fusão em um chassi virtual.

Nota:

Em um Chassi Virtual EX4300 executando uma versão Junos OS 13.2X50, você deve habilitar a declaração de tempo de vcp-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 Chassi Virtual 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 divisão e fusão for desativado. Para obter mais informações sobre um Virtual Chassis dividido, consulte Entender a divisão e a fusão em um chassi virtual. Esta declaração afeta apenas o Chassi Virtual EX4300 ou o Virtual Chassis misto que contêm switches EX4300.

Como uma NSSU funciona em um chassi virtual 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 é on-line e executa a mesma versão de software.

    • Você permitiu o switchover Gracioso do Mecanismo de Roteamento (GRES) e, se aplicável, roteamento ativo sem parar (NSR).

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

  2. A primária copia a nova imagem de software para os membros de função de placa de linha de backup e restantes em sequência usando rcp.

    (Apenas para o QFX5100 Virtual Chassis) Começando com o Junos OS Release 14.1X53-D40 para otimizar o tempo necessário para concluir uma operação de 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 a operação de cópia ser 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. Consulte a contagem de rcp para obter detalhes.

    Nota:

    Se a cópia do novo software para qualquer membro falhar, a NSSU encerrará o processo de atualização de todo o Virtual Chassis sem reiniciar nenhum membro e registrará a condição de erro. Começando com o 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 erro para remover o novo software dos membros para o qual ele já foi transferido.

  3. A primária 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 placa de linha, um de cada vez. A principal espera que cada membro se torne on-line e ativo executando o novo software antes de reiniciar o próximo membro.

    • Se você configurar grupos de atualização, os membros do Virtual Chassis no primeiro grupo de atualização carregam a nova imagem e reiniciam. Quando os membros desse grupo de atualização estiverem on-line novamente, os membros do próximo grupo de atualização 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 encerrará o processo de atualização e registrará a condição de erro. Neste caso, para evitar a instabilidade do Virtual Chassis, você deve fazer a atualização parcial restaurando o software antigo e reinicializando 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 com o Junos OS Release 14.1X53-D40, o NSSU invoca automaticamente medidas de recuperação se o reboot falhar em qualquer membro de função de placa de linha, interrompendo o processo de reinicialização sequencial e derrubando e reinicializando todo o Virtual Chassis. O Virtual Chassis 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. Depois que a primária atualizou todos os membros na função de placa de linha, ele realiza uma transição graciosa do Mecanismo de Roteamento e o switch de membro de backup atualizado torna-se o novo principal.

  7. A nova rede primária atualiza o software na primária original e o reinicializa automaticamente. Depois que a primária original voltar 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, 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 reverter para a versão de software anterior depois de realizar uma atualização usando o NSSU. Se você precisar reverter para a versão de software anterior, você pode reiniciar a partir da partição raiz alternativa se você ainda não tiver copiado a nova versão de software na partição raiz alternativa.

Suporte para lançamento do NSSU e Junos OS

O NSSU funciona apenas em algum Virtual Chassis com lançamentos específicos do Junos OS e do Junos. Entre em contato com a Juniper Networks Technical Assistance Center (JTAC) para confirmar o suporte de e para lançamentos se você estiver considerando atualizar seu Virtual Chassis usando NSSU.

Se o virtual Chassis estiver executando uma versão de software que não aceita NSSU ou não aceita a combinação de e para lançamentos com NSSU, use o request system software add comando para atualizar os switches de membros no Virtual Chassis individualmente.

Você também pode se referir a 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 a NSSU não tiver suporte:

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 desempenho de uma NSSU. O NSSU requer apenas essas etapas de configuração.

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

Tabela de histórico de lançamento
Lançamento
Descrição
14,1X53-D40
(Apenas para o QFX5100 Virtual Chassis) Começando com o Junos OS Release 14.1X53-D40 para otimizar o tempo necessário para concluir uma operação de 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 a operação de cópia ser 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 com o 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 erro para remover o novo software dos membros para o qual ele já foi transferido.
14,1X53-D40
Começando com o Junos OS Release 14.1X53-D40, o NSSU invoca automaticamente medidas de recuperação se o reboot falhar em qualquer membro de função de placa de linha, interrompendo o processo de reinicialização sequencial e derrubando e reinicializando todo o Virtual Chassis.