Entendendo a atualização ininterrupta de software em um Virtual Chassis e um Mixed Virtual Chassis

Benefícios do NSSU

• Nenhuma interrupção no plano de controle — a NSSU usa comutação graciosa do Mecanismo de Roteamento (GRES) (e roteamento ativo sem interrupções (NSR) nas 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 interface, kernel e protocolo de roteamento.

• Interrupção mínima do tráfego de rede — a NSSU minimiza a interrupção do tráfego de rede atualizando os 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 pelos membros na função de placa de linha que não estão sendo atualizados.

Requisitos para realizar um NSSU

Os requisitos para executar 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 do Mecanismo de Roteamento Gracioso (GRES).

• Você deve habilitar o roteamento ativo sem interrupções (NSR) para plataformas aplicáveis.

  Embora a ponte sem interrupções (NSB) não seja necessária para executar um NSSU, também recomendamos habilitar o NSB antes de executar um NSSU nas plataformas aplicáveis. O NSB garante que todos os protocolos de Camada 2 suportados pelo NSB operem perfeitamente quando o Mecanismo de Roteamento muda durante o NSSU. Veja a Configuração de Pontes Sem Parar 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 enlaces membros de cada LAG residam em diferentes membros do Virtual Chassis e configurar o Link Aggregation Control Protocol (LACP) para monitorar os estados dos enlaces membros do LAG. Quando um enlace membro de um LAG está inativo, os enlaces 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 Configuração da agregação de enlaces e Configuração de LACP Ethernet agregada (procedimento de CLI).

  Observação:

  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, poderá ver contagens de tráfego incorretas ou nulas. Para contornar esse problema, execute o comando no membro do Mecanismo de Roteamento de backup se esse membro já estiver carregado e em execução.

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

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

• Os switches de membros primários e de backup devem ser adjacentes uns aos outros na topologia em anel. O posicionamento adjacente garante que o primário e o backup estejam sempre sincronizados enquanto os switches membros nas funções de placa de linha estão sendo reinicializados.

• 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 primário e de backup do Virtual Chassis mudam de função primária enquanto um ou outro está sendo atualizado durante o NSSU, mas eles devem manter suas funções de mecanismo de roteamento primário e 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 seja dividido quando um NSSU atualizar um membro. Consulte Entendendo a divisão e a mesclagem em um Virtual Chassis.

Como um NSSU funciona em um Virtual Chassis e um Virtual Chassis Misto

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

1. O principal do Virtual Chassis verifica se:

   • O backup está online e executando a mesma versão do software.

   • Você habilitou o switchover do Mecanismo de Roteamento Gracioso (GRES) e, se aplicável, o roteamento ativo sem interrupções (NSR).

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

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

   Para otimizar o tempo necessário para concluir uma operação NSSU para um Virtual Chassis, o primário usa sessões paralelas rcp para copiar o novo software para vários membros ao mesmo tempo (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 primário 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 rcp-count declaração de configuração. Veja rcp-count para detalhes.

   Observação:

   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 reinicializar nenhum membro e registra a condição de erro.

3. O primário reinicia o switch de membro de backup com o novo software e o backup é sincronizado novamente com o primário.

4. O primário carrega e reinicializa switches de membros que estão na função de placa de linha, um de cada vez. O primário espera que cada membro fique online 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 carregam a nova imagem e reiniciam. Quando os membros desse grupo de atualização estiverem online novamente, os membros do próximo grupo de atualização carregarão a nova imagem e serão reiniciados. (O NSSU atualiza os grupos na ordem em que 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 sido reiniciados com o novo software.

   Observação:

   Se algum membro da função de placa de linha não for reinicializado com êxito, o NSSU encerrará o processo de atualização e registrará a condição de erro. Nesse caso, para evitar a instabilidade do Virtual Chassis, você deve reverter a atualização parcial restaurando o software antigo e reinicializando os membros que já foram reinicializados com o novo software, ou tentar reinicializar manualmente todos os membros com o novo software que foi copiado para eles, para que todos os membros fiquem online novamente executando a mesma versão do software.

6. Depois que o primário atualizou todos os membros na função de placa de linha, ele executa um switchover gracioso do Mecanismo de Roteamento e o switch de membro de backup atualizado se torna o novo primário.

7. O novo primário atualiza o software no primário original e o reinicializa automaticamente. Depois que o primário original tiver se juntado novamente ao Virtual Chassis, você pode, opcionalmente, reverter 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 fazer downgrade do software, ou seja, para instalar uma versão anterior do software do que está sendo executada no switch no momento. Para instalar uma versão anterior do software, use o request system software add comando.

Você não pode reverter para a versão anterior do software depois de executar uma atualização usando o NSSU. Se você precisar reverter para a versão anterior do software, poderá reinicializar a partir da partição raiz alternativa se ainda não tiver copiado a nova versão do software para a partição raiz alternativa.

Suporte para lançamento do NSSU e do Junos OS

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

Se o seu Virtual Chassis estiver executando uma versão de software que não suporta NSSU ou não suporta a combinação de versões from e to com NSSU, use o request system software add comando para atualizar os switches de membros no Virtual Chassis individualmente.

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

• Procedimento de atualização do Virtual Chassis da Série QFX de dois membros

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

Para que o NSSU seja bem-sucedido, o Virtual Chassis e os switches de membros devem atender aos requisitos em Requisitos para executar um NSSU. A 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. Consulte Atualizando o Software em um Virtual Chassis e Mixed Virtual Chassis Usando o Nonstop Software Upgrade para obter detalhes.