Atualização de dispositivos em um cluster de chassi usando UTI
O método de UTI de cluster de chassi permite que ambos os dispositivos em um cluster sejam atualizados a partir de versões com suporte do Junos OS usando um único comando. Para obter mais informações, veja os seguintes tópicos:
Para firewalls SRX300, SRX320, SRX340, SRX345 e SRX380, se você estiver atualizando para o Junos OS Release 24.4R1, você não poderá usar o método de UTI. Você deve usar os procedimentos descritos KB 85650 ou o procedimento mínimo de inatividade documentado em KB17947 (Minimal_Downtime_Upgrade_Branch_Mid arquivo PDF). Uma vez atualizado para o Junos OS Release 24.4R1, você pode usar o método de UTI para atualizar para quaisquer versões posteriores ou rebaixar de uma dessas versões posteriores para o Junos OS Release 23.4R2-S3 ou para lançar 24.2R2.
Atualização de ambos os dispositivos em um cluster de chassi usando UTI
Antes de começar, observe o seguinte:
A UTI está disponível com a opção de não sincronização apenas para dispositivos SRX300, SRX320, SRX340, SRX345 e SRX380.
Antes de iniciar a UTI, você deve garantir que o espaço suficiente do disco esteja disponível. Veja atualização da UTI usando uma construção disponível localmente em um nó primário em um cluster de chassi e atualização da UTI usando uma construção disponível em um servidor FTP.
Para os dispositivos SRX300, SRX320, SRX340, SRX345 e SRX380, esse recurso não pode ser usado para rebaixar para uma construção antes do Junos OS 11.2 R2.
Para dispositivos SRX1500, esse recurso não pode ser usado para rebaixar para uma construção antes do Junos OS 15.1X49-D50.
Os firewalls da Série SRX em um cluster de chassi podem ser atualizados com uma interrupção mínima de serviço usando a atualização de cluster (UTI) em banda. O recurso de UTI de cluster de chassi permite que ambos os dispositivos em um cluster sejam atualizados a partir de versões com suporte do Junos OS usando um único comando. Você pode habilitar esse recurso executando o request system software in-service-upgrade image_name comando no nó principal. Este comando atualiza o Junos OS e reinicializa tanto o nó secundário quanto o nó primário por sua vez. Durante o processo de UTI, a interrupção de tráfego é mínima; no entanto, a sincronização a frio não é fornecida entre os dois nós.
Para os dispositivos SRX300, SRX320, SRX340, SRX345 e SRX380, os dispositivos em um cluster de chassi podem ser atualizados com uma interrupção mínima de serviço de aproximadamente 30 segundos usando a UTI com a opção de não sincronização. O recurso de UTI de cluster de chassi permite que ambos os dispositivos em um cluster sejam atualizados a partir de versões com suporte do Junos OS.
Você deve usar os comandos de atualização de cluster (UTI) em SRX1500 dispositivo para atualizar após as versões do Junos OS:
-
Versão Junos OS 15.1X49-D50 para Junos OS Versão 15.1X49-D100
-
Versão Junos OS 15.1X49-D60 para Junos OS Versão 15.1X49-D110
-
Versão Junos OS 15.1X49-D50 para Junos OS Versão 15.1X49-D120
Você deve usar os comandos de atualização de cluster (UTI) em SRX1600 dispositivo para atualizar do Junos OS Release 23.3R1 para versão posterior.
Você pode usar os comandos de atualização de cluster (UTI) em SRX2300,SRX4100 e dispositivos SRX4200 para atualizar após as versões do Junos OS:
-
Versão Junos OS 15.1X49-D65 para Junos OS Versão 15.1X49-D70
-
Junos OS Versão 15.1X49-D70 para Junos OS Versão 15.1X49-D80.
Para os dispositivos SRX300, SRX320, SRX340, SRX345 e SRX380, o impacto no tráfego é o seguinte:
-
Queda no tráfego (aproximadamente 30 segundos)
-
Perda de sessões de fluxo de segurança
A atualização é iniciada com a construção do Junos OS localmente disponível no nó principal do dispositivo ou em um servidor FTP.
-
O nó primário, RG0, muda para o nó secundário após uma atualização da UTI.
-
Durante a UTI, os grupos de redundância de cluster do chassi são reprovados no nó principal para mudar o cluster para o modo ativo/passivo.
-
Os estados de UTI podem ser verificados no syslog ou com os logs de console/terminal.
-
A UTI exige que ambos os nós estejam executando um esquema de partição de raiz dupla, com uma exceção sendo a SRX1500 e a SRX1600. A UTI não continuará se não detectar partições de raiz dupla em nenhum dos nós. O requisito da partição dual-root é aplicável apenas para dispositivos SRX300, SRX320, SRX340, SRX345 e SRX380.
A partição de raiz dupla não é suportada em dispositivos de SRX1500 e SRX1600. SRX1500 e SRX1600 usam a unidade de estado sólido (SSD) como armazenamento secundário.
Atualização da UTI usando uma construção disponível localmente em um nó primário em um cluster de chassi
Certifique-se de que o espaço suficiente do disco esteja disponível para o pacote Junos OS na localização /var/tmp no nó secundário do cluster.
Para atualizar a UTI usando uma construção disponível localmente no nó principal de um cluster:
Atualização da UTI usando uma compilação disponível em um servidor FTP
Certifique-se de que o espaço suficiente do disco esteja disponível para o pacote Junos OS na localização /var/tmp tanto nos nós primários quanto secundários do cluster.
Para atualizar a UTI usando uma compilação disponível em um servidor FTP:
O processo de atualização exibe a seguinte mensagem de aviso para reiniciar o sistema:
AVISO: é necessário um reboot para carregar este software corretamente. Use o comando quando a request system reboot instalação do software estiver concluída.
Essa mensagem de aviso pode ser ignorada porque o processo de UTI reinicia automaticamente ambos os nós.
Terminando uma atualização em um cluster de chassi durante uma UTI
Você pode encerrar uma UTI a qualquer momento emitindo o seguinte comando no nó primário:
request system software abort in-service-upgrade
A emissão de um abort comando durante ou após as reinicializações de nó secundário coloca o cluster em um estado inconsistente. O nó secundário começa a executar a nova construção do Junos OS, enquanto o principal continua a executar a construção mais antiga do Junos OS.
Para recuperar o estado inconsistente do cluster do chassi, execute as seguintes ações sequencialmente no nó secundário:
Você deve executar as etapas acima sequencialmente para concluir o processo de recuperação e evitar a instabilidade do cluster.
A Tabela 1 lista as opções e suas descrições para o request system software in-service-upgrade comando.
Opções |
Descrição |
|---|---|
sem sincronização |
Desativa o estado de fluxo da sincronização quando o nó secundário antigo é inicializado com uma nova imagem do Junos OS. Essa opção não está disponível em dispositivos de SRX1500 e SRX1600. |
no-tcp-syn-check |
Cria uma janela na qual a verificação do TCP SYN para os pacotes de entrada será desativada. O valor padrão da janela é de 7200 segundos (2 horas). Essa opção não está disponível em dispositivos de SRX1500 e SRX1600. |
sem validação |
Desativa a validação da configuração no momento da instalação. O comportamento do sistema é semelhante a |
desvincular |
Remove o pacote da mídia local após a instalação. |
Durante a UTI, se um comando de rescisão for executado, a UTI só será terminada após o término da operação atual. Isso é necessário para evitar qualquer inconsistência com os dispositivos.
Por exemplo, se a formatação e a atualização de um nó estiverem em andamento, a UTI terminará após o término desta operação.
Após a rescisão, a UTI tentará reverter a construção dos nós se a etapa de atualização dos nós for concluída.