Considerazioni generali sull'aggiornamento

Prima di eseguire un aggiornamento di vSRX, è necessario tenere presente quanto segue:

Potresti riscontrare delle interruzioni di rete quando esegui l'upgrade della tua versione di vSRX. Per evitare interruzioni, eseguire l'aggiornamento durante una finestra di manutenzione che supporta potenziali tempi di inattività della rete. Il failover non sarà disponibile fino al completamento dell'aggiornamento, che potrebbe richiedere diverse ore. Per ambienti HA (High Availability), le tue impostazioni di configurazione vSRX vengono migrate; tuttavia, ti consigliamo di esportare le tue impostazioni prima dell'upgrade.
Per un ambiente autonomo, la configurazione precedente non viene ripristinata, quindi è necessario esportare e importare la configurazione. Per ulteriori informazioni, vedi Importazione ed esportazione di una configurazione vSRX.
Per ricaricare con successo un HA 'vSRX,, la password di root del gateway 'vSRX deve corrispondere alla password di root definita nel portale 'vSRX. Inoltre, devi abilitare l'accesso SSH root all'IP privato vSRX.

Hai definito la password nel portale quando hai eseguito il provisioning del tuo gateway. Potrebbe non corrispondere alla password del gateway corrente. Se la password è stata modificata dopo la configurazione, connettiti tramite SSH al gateway vSRX e modifica la password di root in modo che corrisponda. Il controllo dello stato di disponibilità ha esito negativo se si verifica una mancata corrispondenza della password.
Non modificare la configurazione di vSRX durante un ricaricamento del SO. Il processo di aggiornamento cattura un'istantanea della configurazione del cluster vSRX corrente all'inizio del processo. Pertanto, la modifica della configurazione di vSRX durante il processo di aggiornamento può causare un errore o risultati imprevedibili. Ad esempio, agent software automatizzati che tentano di modificare uno o entrambi i nodi vSRX. Le modifiche alle configurazioni possono danneggiare il processo di ricaricamento del sistema operativo. Inoltre, queste modifiche di configurazione non vengono conservate se viene avviato un rollback.

Prima di effettuare un aggiornamento del ricaricamento del SO su un cluster HA, eseguire il comando show chassis cluster status. I nodi devono essere raggruppati in cluster con un nodo elencato come primario e l'altro come secondario. Assicurarsi che non vi siano monitor failures. Se il cluster non è in buono stato prima dell'aggiornamento, l'aggiornamento potrebbe non riuscire, causando un'interruzione estesa del traffico.

Esempio di un cluster integro:

 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}

Esempio di un cluster non integro con errori di monitoraggio:

  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 il tuo account IBM Cloud ha più istanze del gateway vSRX nello stesso pod, assicurati che venga eseguito l'upgrade di un solo gateway alla volta. L'aggiornamento di più di un vSRX alla volta può causare conflitti IP, interrompere il processo di aggiornamento e potenzialmente causare errori.
Se si configura il cluster HA per utilizzare IDP (Intrusion Detection Policies) e un database delle firme, si consiglia di aggiornare il database delle firme dopo aver completato l'aggiornamento. Ciò è dovuto al fatto che il database potrebbe non essere aggiornato. Per informazioni sugli aggiornamenti del database online e offline, vedi Intrusion Detection and Prevention on IBM Cloud
Il processo di aggiornamento non esegue il backup né il ripristino dei certificati di vSRX presenti localmente sulla macchina virtuale ( VM ) oggetto dell'aggiornamento. Il processo di aggiornamento elimina il file system esistente VM e ne crea uno nuovo, che sostituisce il file system JunOS. Ad esempio, un certificato locale come IKE_POLICY_CERT deve essere sottoposto a backup prima dell'aggiornamento e ripristinato manualmente una volta completato.

set security ike policy MY_VPN_IKE_POLICY certificate local-certificate IKE_POLICY_CERT

Ubuntu Aspetti da considerare nell'aggiornamento dell'hypervisor

vSRX, viene eseguito come macchina virtuale ( VM ) su un hypervisor ( Ubuntu ). In genere, questo sistema operativo dell'hypervisor viene reinstallato nell'ambito di un aggiornamento dell' vSRX. Tuttavia, in alcuni casi è necessario eseguire operazioni di manutenzione solo sull'hypervisor Ubuntu, ad esempio per applicare aggiornamenti del kernel, patch di sicurezza o correzioni di vulnerabilità, senza aggiornare la macchina virtuale vSRX stessa.

In questi casi, il comando standard apt update è in genere sufficiente, ma occorre tenere presente alcune avvertenze importanti. L'aggiornamento del solo hypervisor di Ubuntu è generalmente considerato un'operazione di manutenzione sicura e, di norma, può essere eseguito con un'interruzione minima delle macchine virtuali vSRX in esecuzione. La maggior parte degli aggiornamenti dei pacchetti, comprese le librerie e le utilità standard dello spazio utente, non richiede l'interruzione delle operazioni dell' VM e guest.

Tuttavia, gli amministratori devono esaminare attentamente i pacchetti inclusi in un aggiornamento prima di procedere. Alcuni aggiornamenti possono compromettere la stabilità o la connettività delle macchine virtuali in esecuzione fino al riavvio dell'hypervisor.

I seguenti tipi di aggiornamenti richiedono particolare attenzione:

Pacchetti del kernel
systemd e gli aggiornamenti su " udev "
libvirt pacchetti
Pacchetti relativi alla rete, quali nftables, bridge o altri componenti di virtualizzazione di rete
qemu e gli aggiornamenti del pacchetto kvm

In alcuni casi, l'aggiornamento dei pacchetti relativi alla virtualizzazione o alla rete mentre le macchine virtuali sono attive può causare un deterioramento delle prestazioni di rete ( VM ), il blocco delle interfacce o uno stato incoerente dell' libvirt, fino al riavvio del nodo dell'hypervisor. In genere, il riavvio dell'hypervisor di Ubuntu ripristina il normale funzionamento.

Quando si esegue un'operazione di " apt upgrade " sull'hypervisor, tenere presenti le seguenti raccomandazioni:

Controlla i pacchetti in sospeso prima di applicare gli aggiornamenti.
Pianificare una finestra di manutenzione se si sta effettuando l'aggiornamento del kernel, di libvirt o dei componenti di rete.
Prevedere il riavvio dell'hypervisor quando necessario.
Se possibile, evitare di eseguire operazioni di manutenzione simultanee su più nodi HA.

Esempio:

apt update
apt list --upgradable
apt upgrade