R82 aggiunge una terza forma di clustering accanto a ClusterXL e alle Scalable Platforms con orchestratore: l’ElasticXL Cluster. La documentazione lo presenta come «a new clustering technology delivering simplified operations with a Single Management Object (SMO) and automatic sync of configuration and software between all cluster members». In esame non basta sapere che esiste: serve sapere che cosa cambia davvero rispetto a un cluster classico, perché quasi tutte le domande nascono da lì.

Un solo oggetto di gestione per tutto il cluster

L’intera soluzione vive dietro un unico oggetto: «The entire ElasticXL Cluster is represented by one Security Gateway object (SMO)». Il Management Server parla con un solo indirizzo IP, installa la policy una volta sola e non conosce i singoli apparati come entità separate. Si configura una sola appliance — quella è il SMO — e le altre, dice la guida, «automatically clone all software packages, settings, and security policies from the SMO».

La scelta si compie nel Gaia First Time Configuration Wizard, nella sezione Clustering: si seleziona Unit is a part of a cluster e poi ElasticXL. Nella stessa schermata si decide se attivare VSNext, e quella decisione non si cambia a installazione avvenuta. ElasticXL non supporta il VSX tradizionale: c’è solo VSNext. Ogni apparato che entra nel cluster deve partire da un’installazione pulita o da un factory reset, e la modalità di SecureXL va lasciata dov’è: «Do not change the SecureXL mode. It must run in the Kernel Mode (KPPAK)».

Le interfacce e la rete di Sync sono un vincolo, non un dettaglio

Servono almeno quattro interfacce per membro: management, Sync, external e internal. La rete di Sync è la spina dorsale dell’architettura e ha regole rigide. Le porte Sync di tutti i membri dello stesso cluster devono appartenere allo stesso dominio di broadcast di livello 2, collegate «through a dedicated Layer 2 switch, or a dedicated VLAN». L’indirizzamento della rete interna di sincronizzazione è automatico e usa l’intervallo 192.0.2.0/24: non si assegna a mano. La porta Sync non si può configurare come VLAN Trunk. E in uno stesso dominio di broadcast di livello 2 può esistere un solo ElasticXL Cluster: due cluster affiancati sullo stesso segmento non sono una topologia ammessa. Il traffico di sincronizzazione viaggia in chiaro, quindi quel segmento va trattato come dedicato e fidato, non come una VLAN qualunque riciclata dal resto della rete.

C’è anche un tetto dimensionale da ricordare: fino a tre membri per sito e sei in totale contando i due siti. Quando servono più membri di così, la piattaforma corretta non è ElasticXL ma Quantum Maestro.

Amministrare e osservare il cluster come un apparato solo

La gestione passa da Global Gaia Portal e Global Gaia Clish (gClish), con la Gaia RESTful API a disposizione per l’automazione: un comando dato lì vale per il cluster, non per una scatola. Quando serve scendere sulla shell di un singolo membro c’è il comando member, con la notazione sito-membro: member 2_2 porta sul membro 2 del sito 2, e exit riporta al livello precedente.

Lo stato complessivo si legge con asg stat, che mostra la modalità del gateway, quanti membri sono operativi, la versione e l’uptime. Una coppia come 6 / 6 nell’output si legge così: a sinistra il numero di componenti nello stato UP, a destra quanti devono esserlo. Con asg stat -v si scende al dettaglio per membro — ACTIVE se lavora traffico, DOWN se non lo lavora, DETACHED o LOST se non comunica o si sta riavviando — mentre asg stat -i tasks dice quale membro ospita i vari task, SMO compreso. Per una vista d’insieme con allarmi e test HealthCheck Point c’è la dashboard insights.

Trappole tipiche d’esame

  • Il membro non comunica e si cerca la causa nella policy. Quando lo scenario descrive un apparato che non entra nel cluster o non dialoga con gli altri, la causa quasi sempre è nelle interfacce: Sync configurata come VLAN Trunk, porte Sync su domini di livello 2 diversi, due cluster nello stesso dominio di broadcast, meno di quattro interfacce definite. La reinstallazione della policy non c’entra.
  • Definire l’oggetto come se fosse ClusterXL. Ogni risposta che crea un oggetto per ciascun apparato, o che ricostruisce in SmartConsole un cluster object con i membri elencati uno per uno, è sbagliata: l’oggetto è uno solo, il SMO, e rappresenta tutto il cluster.
  • Scambiare la rete di Sync per la rete di management. Sono due cose diverse: il management ha la sua interfaccia e il suo indirizzo, la Sync è un segmento interno auto-indirizzato in 192.0.2.0/24, in chiaro, che non si progetta né si ri-numera a piacere.
  • Decisioni che sembrano reversibili e non lo sono. VSNext si sceglie nel First Time Configuration Wizard e resta; il VSX tradizionale non è un’opzione; la modalità di SecureXL non è una leva di troubleshooting.