Che cosa decide il metodo: versione di partenza e ruolo del server

Prima di scegliere fra aggiornamento in-place e installazione pulita si guarda da dove si parte. Verso R82 l’aggiornamento diretto è supportato da R81.20, R81.10, R81 e R80.40. Da R80.30 e R80.20 (kernel 3.10 e 2.6 per entrambe), R80.10 e R77.30 serve un passaggio intermedio verso una di quelle quattro versioni; per R77.30 e R80.10 l’edizione di Gaia deve essere a 64 bit.

Poi conta il ruolo della macchina. Le Release Notes elencano i metodi componente per componente: i Management Server, primario e secondario, accettano CPUSE Clean Install, CPUSE Upgrade, Advanced Upgrade e Upgrade with Migration, mentre Central Deployment in SmartConsole vale solo per il secondario. Log Server e SmartEvent Server accettano tutti e cinque i metodi. I Security Gateway accettano Central Deployment in SmartConsole, CPUSE Clean Install, CPUSE Upgrade e Upgrade with CDT. Per i cluster ClusterXL e VSX si ragiona invece per strategia: Multi-Version Cluster (MVC) Upgrade, Minimum Effort Upgrade e Minimum Downtime Upgrade, realizzate con CPUSE o con Central Deployment.

L’ordine non è negoziabile: prima i Management Server, poi i server dedicati (Log Server, SmartEvent Server), poi i gateway e i membri di cluster.

In-place con CPUSE

CPUSE è il motore di installazione su Gaia, e tutti i suoi processi sono gestiti dal Deployment Agent. I pacchetti si dividono in hotfix, scaricati e installati automaticamente per impostazione predefinita, major e minor release, che richiedono installazione manuale, e full image.

L’upgrade in-place conserva la configurazione sulla stessa macchina ed è la strada più corta quando la versione di partenza è supportata. Resta un’operazione da cui si deve poter tornare indietro: prima lo Snapshot di Gaia, poi l’export del database.

Installazione pulita e migrazione del database

Quando la macchina va rifatta o cambia l’hardware, la coppia di riferimento è Advanced Upgrade e Upgrade with Migration. L’Advanced Upgrade lavora sullo stesso computer: backup, export del database, upgrade o installazione pulita, import del database. La Migration serve quando il target è un’altra macchina: export dal sorgente, installazione pulita di R82 sul nuovo computer, import.

I prerequisiti pesano più della procedura. Servono licenze valide e un Service Contract che includa software upgrade e major release, registrato nell’account User Center. La partizione /var/log/ del target deve essere almeno il 25% di quella sorgente, e per Advanced Upgrade e Migration il disco deve essere almeno cinque volte la dimensione del database esportato. Vanno lette le Release Notes R82 e le Known Limitations; sui Multi-Domain Server va eseguito il Pre-Upgrade Verifier sui server sorgente. Le configurazioni personalizzate non viaggiano da sole: si copiano a mano da $FWDIR/lib/, $FWDIR/conf/, $CVPNDIR/conf/ e dalle altre directory, compresa la configurazione di Log Exporter. La migrazione dei log si ferma per impostazione predefinita a 180 giorni, valore modificabile nel file upgradeLogData.xml fra 30 e 360.

Per il backup gli strumenti hanno scopi diversi: lo Snapshot di Gaia salva l’intera configurazione del sistema, migrate_server export produce il backup del database del Security Management Server, mds_backup quello dei Multi-Domain Server. In Management High Availability i backup e gli snapshot vanno raccolti e ripristinati da tutti i server nello stesso momento, altrimenti l’ambiente torna su incoerente.

Central Deployment e CDT

Il Central Deployment distribuisce i pacchetti dal Management Server ai target senza toccarli uno per uno. Copre Jumbo Hotfix Accumulator e hotfix, pacchetti di upgrade e la disinstallazione di hotfix e Jumbo. Da SmartConsole si va in Gateways & Servers, si selezionano fino a 30 target (dieci installano in parallelo) e si usa il menu Actions con Install Hotfix/Jumbo oppure Version Upgrade. Il repository si gestisce in Manage & Settings, Package Repository, con Download from cloud o Upload from local. Sui Security Gateway lo stesso lavoro si può fare dal server con il Central Deployment Tool (CDT).

I prerequisiti sono quattro: permessi di scrittura SmartUpdate, Deployment Agent CPUSE aggiornato sui target, SIC stabilita e Access Control Policy installata. I target supportati sono Security Gateway, membri ClusterXL (il cluster intero, non il singolo membro), Log Server e Management Server secondari, cluster VSX non VSLS. Restano fuori ClusterXL in Load Sharing, i cluster VRRP ed ElasticXL e i Security Group su Maestro.

Trappole tipiche d’esame

  • Nessun backup prima dell’aggiornamento. È l’errore che il vendore mette per primo, e la domanda non chiede se hai fatto il backup ma quale. Lo Snapshot di Gaia e l’export del database non sono intercambiabili, e in Management High Availability vanno presi da tutti i server nello stesso momento: un solo snapshot recente vale meno di zero, perché fa credere di avere una via di ritorno.
  • Aggiornare senza verificare la compatibilità. Qui cadono tre controlli distinti: il percorso di upgrade supportato, con il salto in due passi per le versioni più vecchie; il Service Contract, che deve includere le major release; e l’ordine, con i Management Server aggiornati prima dei gateway.
  • Hotfix installati a mano invece che con il Central Deployment Tool. Su un parco di gateway l’installazione manuale è lenta e disallinea le versioni: il Central Deployment e il CDT esistono proprio per i Jumbo Hotfix Accumulator.
  • Credere che il Central Deployment copra tutto. Non tocca il Management Server primario, non gestisce ClusterXL in Load Sharing, VRRP, ElasticXL o i Security Group Maestro, e non funziona attraverso un proxy.