Atualização de um cluster de chassi usando upgrade de software em serviço

A atualização de software em serviço (ISSU) permite um upgrade de software de uma versão do Junos OS para uma versão posterior do Junos OS com pouco ou nenhum tempo de inatividade. O ISSU é realizado quando os dispositivos estão operando apenas no modo cluster do chassi.

O recurso ISSU de cluster de chassi permite que ambos os dispositivos em um cluster sejam atualizados a partir de versões com suporte do Junos OS com uma interrupção mínima no tráfego e sem interrupções no serviço.

O ISSU oferece os seguintes benefícios:

• Elimina o tempo de inatividade da rede durante atualizações de imagens de software

• Reduz os custos operacionais, ao mesmo tempo em que entrega níveis de serviço mais altos

• Permite a implementação rápida de novos recursos

O ISSU tem as seguintes limitações:

• O ISSU está disponível apenas para o Junos OS Release 10.4R4 ou posterior.

• O ISSU não oferece suporte a rebaixamentos de software.

• Se você atualizar de uma versão do Junos OS que oferece suporte apenas ao IPv4 para uma versão que oferece suporte tanto ao IPv4 quanto ao IPv6, o tráfego IPv4 continuará funcionando durante o processo de atualização. Se você atualizar de uma versão do Junos OS que oferece suporte ao IPv4 e IPv6 para uma versão que ofereça suporte tanto ao IPv4 quanto ao IPv6, tanto o tráfego IPv4 quanto O IPv6 continuam funcionando durante o processo de atualização. O Junos OS Release 10.2 e posteriores liberam o processamento baseado em fluxo para tráfego IPv6.

• Durante um ISSU, você não pode colocar nenhum PICs on-line. Você não pode realizar operações como confirmar, reiniciar ou parar.

• Durante um ISSU, operações como monitoramento de malha, recuperação de enlaces de controle e preempício do RGX são suspensas.

• Durante um ISSU, você não pode confirmar nenhuma configuração.

Para obter mais informações sobre o status de suporte ISSU, veja o artigo base de conhecimento KB17946.

O processo a seguir ocorre durante um ISSU para dispositivos em um cluster de chassi. As sequências fornecidas abaixo são aplicáveis quando RG-0 é nó 0 (nó primário). Observe que você deve iniciar um ISSU a partir das primárias de RG-0. Se você iniciar a atualização no nó 1 (RG-0 secundário), uma mensagem de erro será exibida.

1. No início de um ISSU de cluster de chassi, o sistema falha automaticamente em todos os grupos de redundância RG-1+ que não são primários no nó do qual o ISSU é iniciado. Essa ação garante que todos os grupos de redundância estejam ativos apenas no nó primário RG-0.

   O failover automático de todos os grupos de redundância RG-1+ está disponível na versão 12.1 ou posterior do Junos OS. Se você estiver usando o Junos OS versão 11.4 ou anterior, antes de iniciar o ISSU, certifique-se de que todos os grupos de redundância estão todos ativos apenas no nó primário RG-0.

   Depois que o sistema falha em todos os grupos de redundância RG-1+, ele define o bit de failover manual e altera todas as prioridades de nó primário RG-1+ para 255, independentemente de o grupo de redundância ter falhado no nó primário do RG-0.

2. O nó primário (nó 0) valida a configuração do dispositivo para garantir que ele possa ser comprometido usando a nova versão de software. Verificações são feitas para disponibilidade de espaço em disco para o sistema de arquivos /var em nós, configurações sem suporte e placas de interface física (PICs) sem suporte.

   Se o espaço de disco disponível em qualquer um dos mecanismos de roteamento for insuficiente, o processo ISSU falha e retorna uma mensagem de erro. No entanto, PICs sem suporte não impedem o ISSU. O software emite um aviso para indicar que esses PICs serão reiniciados durante a atualização. Da mesma forma, uma configuração de protocolo sem suporte não impede o ISSU. No entanto, o software emite um aviso de que a perda de pacotes pode ocorrer para o protocolo durante a atualização.

3. Quando a validação é bem sucedida, o daemon de sincronização de estado do kernel (ksyncd) sincroniza o kernel no nó secundário (nó 1) com o nó 0.

4. O nó 1 é atualizado com a nova imagem de software. Antes de ser atualizado, o nó 1 recebe o arquivo de configuração do nó 0 e valida a configuração para garantir que ele possa ser comprometido usando a nova versão de software. Após ser atualizado, ele é ressincronizado com nó 0.

5. O processo de cluster de chassi (chassi) no nó 0 prepara outros processos de software para a lSSU. Quando todos os processos estão prontos, o chassi envia uma mensagem aos PICs instalados no dispositivo.

6. O mecanismo de encaminhamento de pacotes em cada concentrador PIC flexível (FPC) salva seu estado e baixa a nova imagem de software do nó 1. Em seguida, cada Mecanismo de encaminhamento de pacotes envia uma mensagem (pronto para ISSU unificado) para o chassi.

7. Depois de receber a mensagem (pronto para ISSU unificado) de um Mecanismo de encaminhamento de pacotes, o chassisd envia uma mensagem de reinicialização para o FPC no qual o Mecanismo de encaminhamento de pacotes reside. O FPC reinicializa com a nova imagem de software. Após a reinicialização do FPC, o Mecanismo de encaminhamento de pacotes restaura o estado do FPC e um link interno de alta velocidade é estabelecido com o nó 1 executando o novo software. O chassi também é restabelecido com nó 0.

8. Depois de todos os mecanismos de encaminhamento de pacotes terem enviado uma mensagem pronta usando o chassi no nó 0, outros processos de software estão preparados para um switchover de nós. O sistema está pronto para uma mudança de switch neste momento.

9. A switchover de nós ocorre e o nó 1 torna-se o novo nó primário (até então, nó secundário 1).

10. O novo nó secundário (até então nó primário 0) agora é atualizado para a nova imagem de software.

Quando ambos os nós são atualizados com sucesso, o ISSU está completo.

Ao atualizar um cluster de versão que não oferece suporte à criptografia para uma versão que oferece suporte à criptografia, atualize o primeiro nó para a nova versão. Sem a criptografia configurada e habilitada, dois nós com versões diferentes ainda podem se comunicar entre si e o serviço não está quebrado. Depois de atualizar o primeiro nó, atualize o segundo nó para a nova versão. Os usuários podem decidir se ativam o recurso de criptografia após a atualização. A criptografia deve ser desativada antes de rebaixar para uma versão que não oferece suporte à criptografia. Isso garante que a comunicação entre um nó de versão habilitado para criptografia e um nó rebaixado não se quebre, porque ambos não estão mais criptografados.

Você pode usar o ISSU para atualizar de uma versão de software com capacidade ISSU para uma versão posterior.

Para realizar um ISSU, seu dispositivo deve estar executando uma versão do Junos OS que oferece suporte a ISSU para a plataforma específica. Consulte a Tabela 1 para oferecer suporte à plataforma.

Para obter mais detalhes sobre o suporte e limitações de ISSU, veja limitações de atualização de ISSU/ICU em dispositivos da Série SRX.

Observe as seguintes limitações relacionadas a um ISSU:

• O processo ISSU é encerrado se a versão do Junos OS especificada para instalação for uma versão anterior à que está sendo executada no dispositivo atualmente.

• O processo ISSU é encerrado se a atualização especificada entrar em conflito com a configuração atual, os componentes suportados e assim por diante.

• O ISSU não oferece suporte aos pacotes de aplicativos de extensão desenvolvidos usando o Junos OS SDK.

• O ISSU não oferece suporte à redução de versão em todos os firewalls da Série SRX suportados.

• O ISSU falha ocasionalmente sob uma pesada carga de CPU.

Para rebaixar de uma versão com capacidade ISSU para uma versão anterior (com capacidade de ISSU ou não), use o request system software add comando. Ao contrário de uma atualização usando o processo ISSU, um rebaixamento usando o request system software add comando pode causar interrupções na rede e perda de dados.

Recomendamos fortemente que você execute o ISSU nas seguintes condições:

• Quando os nós primários e secundários são saudáveis

• Durante o período de manutenção do sistema

• Durante o menor período de tráfego possível

• Quando o uso da CPU do mecanismo de roteamento é inferior a 40 por cento

Nos casos em que o ISSU não seja suportado ou recomendado, enquanto o tempo de inatividade durante a atualização do sistema deve ser minimizado, o procedimento mínimo de tempo de inatividade pode ser usado, ver o artigo da basede conhecimento KB17947.

Use o Feature Explorer para confirmar o suporte de plataforma e versão para recursos específicos.

Use a tabela a seguir para revisar comportamentos específicos da plataforma para sua plataforma.