Considerações gerais de upgrade

Antes de executar um upgrade do vSRX, esteja ciente das considerações a seguir:

Você pode enfrentar interrupções na rede ao atualizar a versão do vSRX. Para evitar interrupções, execute o upgrade durante uma janela de manutenção que suporte o tempo de inatividade da rede potencial. O failover não estará disponível até a conclusão do upgrade e isso poderá levar várias horas. Para ambientes de alta disponibilidade (HA), as suas definições de configuração do vSRX são migradas, no entanto, recomenda-se exportá-las antes do upgrade.
Para um ambiente independente, a configuração anterior não é restaurada, portanto, é necessário exportar e importar a sua configuração. Para obter mais informações, consulte Importando e exportando uma configuração do vSRX.
Para um recarregamento bem-sucedido em um vSRX de alta disponibilidade, a senha raiz para o gateway vSRX provisionado deve corresponder à senha raiz definida no portal do vSRX. Além disso, deve-se ativar o login SSH raiz para o IP privado do vSRX.

Você definiu a senha no portal quando provisionou o seu gateway. Isso pode não corresponder à senha de gateway atual. Se ela tiver sido mudada após o fornecimento, use o SSH para se conectar ao gateway vSRX e mudar a senha raiz para gerar correspondência. A verificação de prontidão falhará se houver uma incompatibilidade de senha.
Não modifique a configuração do vSRX durante um recarregamento do S.O. O processo de upgrade captura uma captura instantânea da configuração de cluster do vSRX atual no início do processo. Portanto, modificar a configuração do vSRX durante o processo de upgrade pode resultar em uma falha ou em resultados imprevisíveis. Por exemplo, agentes de software automatizados que tentam modificar um ou ambos os nós do vSRX. As mudanças de configurações podem corromper o processo de recarregamento do S.O. Além disso, essas mudanças de configuração não serão preservadas se um retrocesso for iniciado.

Antes de executar um upgrade de recarregamento do S.O., em um cluster de alta disponibilidade, execute o comando show chassis cluster status. Os nós devem ser agrupados em um cluster, com um nó definido como primário e o outro como secundário. Assegure-se de que não existam monitor failures. Se o cluster não estiver em bom estado antes da atualização, a atualização poderá falhar, causando uma interrupção prolongada do tráfego.

Exemplo de um cluster em funcionamento:

 root@asloma-19-10g-ha1-vsrx-vSRX-Node0> show chassis cluster status
 Monitor Failure codes:
   CS  Cold Sync monitoring        FL  Fabric Connection monitoring
   GR  GRES monitoring             HW  Hardware monitoring
   IF  Interface monitoring        IP  IP monitoring
   LB  Loopback monitoring         MB  Mbuf monitoring
   NH  Nexthop monitoring          NP  NPC monitoring
   SP  SPU monitoring              SM  Schedule monitoring
   CF  Config Sync monitoring      RE  Relinquish monitoring
   IS  IRQ storm

 Cluster ID: 2
 Node   Priority Status               Preempt Manual   Monitor-failures

 Redundancy group: 0 , Failover count: 1
 node0  100      primary              no      no       None
 node1  1        secondary            no      no       None

 Redundancy group: 1 , Failover count: 1
 node0  100      primary              no      no       None
 node1  1        secondary            no      no       None

 {primary:node0}

Exemplo de um cluster não em funcionamento com falhas de monitor:

  root@asloma-tc11-15-10g-pubpriv-ha1-vsrx-vSRX-Node1> show chassis cluster status
  Monitor Failure codes:
    CS  Cold Sync monitoring        FL  Fabric Connection monitoring
    GR  GRES monitoring             HW  Hardware monitoring
    IF  Interface monitoring        IP  IP monitoring
    LB  Loopback monitoring         MB  Mbuf monitoring
    NH  Nexthop monitoring          NP  NPC monitoring
    SP  SPU monitoring              SM  Schedule monitoring
    CF  Config Sync monitoring
  Cluster ID: 3
  Node   Priority Status         Preempt Manual   Monitor-failures

  Redundancy group: 0 , Failover count: 1
  node0  0        lost           n/a     n/a      n/a
  node1  1        primary        no      no       None

  Redundancy group: 1 , Failover count: 1
  node0  0        lost           n/a     n/a      n/a
  node1  0        primary        no      no       CS

  {primary:node1}

Se sua conta da IBM Cloud tiver várias instâncias de gateway vSRX no mesmo pod, certifique-se de que somente um gateway receba upgrade a cada vez. Fazer upgrade de mais de um vSRX por vez poderá resultar em colisões de IP, interromper o processo de upgrade e potencialmente causar falhas.
Se você configurar seu cluster de alta disponibilidade (HA) para usar Políticas de Detecção de Intrusão (IDP) e um banco de dados de assinaturas, é recomendável atualizar o banco de dados de assinaturas após concluir a atualização. Isso ocorre porque o banco de dados pode estar desatualizado. Para obter informações sobre atualizações de banco de dados online e offline, consulte " Detecção e Prevenção de Intrusões" em IBM Cloud
O processo de atualização não faz backup nem restaura nenhum certificado do servidor de certificação local ( vSRX ) da máquina virtual ( VM ) que está sendo atualizada. O processo de atualização exclui o arquivo VM existente e cria um novo, que substitui o sistema de arquivos JunOS. Por exemplo, um certificado local como IKE_POLICY_CERT deve ser submetido a backup antes do upgrade e restaurado manualmente após sua conclusão.

set security ike policy MY_VPN_IKE_POLICY certificate local-certificate IKE_POLICY_CERT

Ubuntu Considerações sobre a atualização do hipervisor

O servidor de aplicativos ( vSRX ) é executado como uma máquina virtual ( VM ) em um hipervisor ( Ubuntu ). Geralmente, esse sistema operacional do hipervisor é reiniciado como parte de uma atualização do vSRX. No entanto, há casos em que apenas o hipervisor Ubuntu requer manutenção, como a aplicação de atualizações do kernel, patches de segurança ou correções de vulnerabilidades, sem a necessidade de atualizar a própria máquina virtual vSRX.

Nesses casos, o comando padrão apt update costuma ser suficiente, mas há algumas ressalvas importantes que você deve ter em mente. A atualização apenas do hipervisor do Ubuntu é geralmente considerada uma operação de manutenção segura e, normalmente, pode ser realizada com o mínimo de interrupção nas máquinas virtuais do vSRX em execução. A maioria das atualizações de pacotes, incluindo bibliotecas e utilitários padrão do espaço do usuário, não exige a interrupção das operações do sistema operacional convidado ( VM ).

No entanto, os administradores devem analisar cuidadosamente os pacotes incluídos em uma atualização antes de prosseguir. Algumas atualizações podem afetar a estabilidade ou a conectividade das máquinas virtuais em execução até que o hipervisor seja reiniciado.

Os seguintes tipos de atualizações requerem atenção especial:

Pacotes do kernel
systemd e atualizações do udev
libvirt pacotes
Pacotes relacionados à rede, como o nftables``, pontes ou outros componentes de virtualização de rede
qemu e atualizações do pacote kvm

Em alguns casos, atualizar pacotes relacionados à virtualização ou à rede enquanto as máquinas virtuais permanecem ativas pode resultar em desempenho reduzido do VM, interfaces paralisadas ou um estado inconsistente do libvirt até que o nó do hipervisor seja reiniciado. Normalmente, reiniciar o hipervisor do Ubuntu restaura o funcionamento normal.

Ao realizar uma atualização do sistema operacional ( apt upgrade ) no hipervisor, leve em consideração as seguintes recomendações:

Verifique os pacotes pendentes antes de aplicar as atualizações.
Agende uma janela de manutenção caso o kernel, o libvirt ou os componentes de rede estejam sendo atualizados.
Planeje a reinicialização do hipervisor quando necessário.
Sempre que possível, evite realizar manutenção simultânea em vários nós de alta disponibilidade.

Exemplo:

apt update
apt list --upgradable
apt upgrade