Il changeover fra due Management Server è una delle poche operazioni CCSE che si comandano dalla macchina «sbagliata»: non dall’Active che sta per cedere il posto, ma dallo Standby che lo prende. Intorno a questo gesto ruotano due meccanismi che vanno tenuti distinti: chi comanda in un dato istante, e che cosa i due server si sono realmente passati fino a quel momento.

Il Primary opera, il Secondary subentra

Il Primary Security Management Server è quello installato per primo e, in esercizio normale, è il server Active: accetta le modifiche, ospita le sessioni degli amministratori, installa le policy. Il Secondary resta Standby, apribile solo in Read Only mode, e subentra quando il primo si ferma per guasto o per manutenzione.

Check Point è esplicito su un punto che molti danno per scontato al contrario: il passaggio lo avvia l’amministratore. Se il Security Management Server primario si guasta o viene messo offline per manutenzione, è l’amministratore a iniziare il changeover perché il server secondario prenda il controllo. Non c’è elezione automatica fra Management Server, quindi un fermo non pianificato lascia l’ambiente senza server Active finché qualcuno non interviene — e nel frattempo i Security Gateway restano con la policy già installata.

La procedura è breve. Ci si collega con SmartConsole allo Standby Security Management Server, si apre il menu e si sceglie High Availability, si apre la finestra High Availability Status e si usano i pulsanti di azione per portare lo Standby ad Active. Il server che era Active diventa automaticamente Standby: passa in Read Only e da quel momento riceve le modifiche dal nuovo Active. I ruoli Primary e Secondary, invece, restano quelli decisi in fase di installazione.

La sincronizzazione: quando parte e che cosa porta

L’Active si sincronizza con lo Standby — o con gli Standby, se sono più di uno — a intervalli, e inoltre quando si pubblica la sessione di SmartConsole. Il contenuto dell’allineamento è il database di gestione: policies, rules, user definitions, network objects, system configuration settings. Il trasferimento è incrementale, basato sulla tecnologia delle revisions, e riguarda soltanto ciò che è cambiato dall’ultimo allineamento riuscito: è questo che permette un aggiornamento pressoché in tempo reale senza pesare sulle risorse dei due server.

Qui sta la frase che decide molte risposte: le sessioni non pubblicate non vengono sincronizzate. Il lavoro che vive ancora dentro una sessione aperta in SmartConsole appartiene a quella sessione e non esiste per l’altro server. La regola operativa prima di ogni changeover è quindi una sola: pubblicare, poi cambiare ruolo.

Leggere lo stato invece di indovinarlo

La finestra High Availability Status è l’unico posto in cui la situazione è dichiarata, e i messaggi hanno un significato preciso: Synchronized successfully con l’ora dell’ultimo allineamento riuscito; Sync problem, last time sync quando l’allineamento è fallito; No communication e Not communicating, last sync time quando i due server non si parlano più. C’è poi la condizione di collisione, descritta come più di un Management Server configurato come Active: nasce quando la comunicazione con l’Active si interrompe, e il risultato sono due database che divergono in parallelo.

Guarda lo stato due volte: prima del changeover, per sapere che cosa lo Standby ha davvero ricevuto, e subito dopo, per confermare che il ruolo sia passato e che il nuovo Standby stia ricevendo gli aggiornamenti.

Trappole tipiche d’esame

Sincronizzazione mal configurata e dati incoerenti. Se una domanda racconta di modifiche «fatte e poi sparite» dopo un cambio di ruolo, cerca la sessione non pubblicata: è la spiegazione che la documentazione autorizza. E non confondere l’installazione della policy con la pubblicazione: ciò che innesca l’allineamento è il publish della sessione, oltre agli intervalli automatici.

Regole firewall o problemi di rete fra i membri. Sono la causa tipica degli stati No communication e Not communicating, last sync time, ed è anche il modo in cui si arriva a due server entrambi Active. Davanti a uno scenario con due Active la risposta giusta non è «è previsto, così si bilancia il carico», ma «la comunicazione è caduta e i due database stanno divergendo»: si ripristina la comunicazione e si decide quale database tenere.

Il failover mai collaudato. L’errore si paga in tre punti: nessuno ha verificato che i Security Gateway abbiano il server secondario nell’elenco Fetch Policy; nessuno sa quanto tempo richiede davvero il cambio di ruolo; nessuno ha mai aperto SmartConsole verso il Secondary. Ricorda infine che lo Standby è Read Only: un quesito che chiede di modificare una regola «sul server di riserva» sta chiedendo, in realtà, se sai che prima quel server va promosso ad Active.