La promessa di ElasticXL è aggiungere potenza senza rifare il progetto: si collega un’appliance, entra nel cluster e da quel momento lavora. La guida la riassume come «ability to add and remove ElasticXL Cluster Members on-the-fly (the configuration and software packages are cloned automatically from the SMO)». Qui guardiamo come avviene davvero l’ingresso di un membro e che cosa decide quanto traffico finisce su ciascuno.

Far entrare un membro nuovo

L’apparato nuovo non si configura a mano: si presenta al cluster. Va collegato alla stessa rete di Sync degli altri e portato a uno stato pulito, cioè installazione da zero o factory reset. Poi, dal SMO, si autorizza l’ingresso dal Global Gaia Portal oppure da gClish:

add cluster member method hostname identifier NOME-APPLIANCE site-id 1

Il candidato si può identificare per hostname, per numero di serie oppure per request-id; il parametro site-id vale 1 o 2 e assegna il membro a un sito. Da lì l’apparato attraversa una sequenza di stati che conviene riconoscere a colpo d’occhio: REQUEST_TO_JOIN, poi APPROVED_TO_JOIN, poi JOINING_CLUSTER, infine CLUSTER_MEMBER. Il processo richiede «several minutes» perché il membro sta clonando pacchetti software, impostazioni e policy dal SMO: niente First Time Configuration Wizard da rifare, niente policy da installare su di lui, nessun oggetto nuovo in SmartConsole.

La crescita ha un limite preciso: tre membri per sito, sei in totale fra i due siti. Oltre quella soglia la risposta corretta non è aggiungere un altro membro ma cambiare piattaforma e passare a Quantum Maestro. L’operazione inversa è simmetrica e si esegue da gClish:

delete cluster member method hostname identifier NOME-APPLIANCE

Non mandarlo in produzione al buio

Un membro che entra e comincia subito a lavorare è comodo finché la sua configurazione è corretta. Per questo esiste una guardia: set cluster configuration high-availability down_on_first_join 1 fa arrivare ogni nuovo membro nello stato administratively DOWN. Il valore predefinito è 0, cioè la guardia è disattivata e il membro entra attivo. Con la guardia attiva, «the administrator can confirm that the Security Group Member is configured correctly before changing its state to UP»: si verifica con insights o con i test HealthCheck Point, e solo dopo lo si alza, da gClish con set cluster members-admin-state ids ID up oppure da Expert mode con cluster-cli set members-admin-state ids ID up. È la differenza fra scalare e scommettere.

Come si distribuisce davvero il carico

Qui sta l’idea che fa sbagliare più domande di qualunque altra. In un ElasticXL Cluster i membri non pescano il traffico ciascuno per conto proprio: un solo membro per sito riceve il traffico e lo distribuisce agli altri, con un ruolo paragonabile a quello del Pivot in un ClusterXL in High Availability. Gli altri membri ispezionano i pacchetti che ricevono da lui. Aggiungere membri significa quindi più capacità di ispezione, non più punti d’ingresso in rete.

La regola con cui i pacchetti vengono assegnati si chiama Distribution Mode. Sulle Scalable Platforms ne esistono tre: General, che considera indirizzo sorgente e indirizzo destinazione; User, detta anche Internal, che guarda solo l’indirizzo di destinazione; Network, detta anche External, che guarda solo l’indirizzo sorgente. Un’opzione Layer 4 aggiunge le porte al calcolo. Su ElasticXL è supportata una sola modalità: General. Lo strumento che la espone è asg dxl, con sottocomandi come stat, calc, query e verify, e la guida è esplicita sul suo uso: «do not use this command to change the configuration, unless Check Point Support explicitly asked you to do so».

Da qui discende il comportamento che va saputo raccontare: poiché l’assegnazione dipende dagli indirizzi, i pacchetti di uno stesso flusso finiscono sullo stesso membro, mentre sessioni diverse possono cadere su membri diversi. Un membro più carico degli altri non è di per sé un guasto: è una distribuzione per indirizzi che incontra un traffico non uniforme. Per leggere la situazione reale servono asg stat -v, che mostra lo stato membro per membro, e asg stat -i list_all, che elenca ID, stato, indirizzo e task assegnati.

Trappole tipiche d’esame

  • Il membro nuovo non completa il join e si accusa il software. Se resta in REQUEST_TO_JOIN o non arriva mai a CLUSTER_MEMBER, la pista giusta sono le interfacce: porte Sync fuori dallo stesso dominio di broadcast di livello 2, Sync impostata come VLAN Trunk, apparato non riportato a installazione pulita. Non è la policy, non è la licenza.
  • Credere che aggiungere un membro tocchi SmartConsole. L’oggetto è uno solo, il SMO. Ogni risposta che aggiunge il nuovo gateway a un oggetto cluster, lo elenca fra i membri o installa la policy su di lui è sbagliata: configurazione e policy si clonano dal SMO.
  • Immaginare un bilanciamento che non esiste. Non è round robin pacchetto per pacchetto, non è un ingresso simultaneo su tutti i membri, e la modalità di distribuzione non si cambia: su ElasticXL c’è solo General, e asg dxl non è la leva con cui risolvere uno squilibrio.
  • Dimenticare la guardia sul primo join. Se lo scenario dice che il membro risulta nel cluster ma non lavora traffico, il sospetto numero uno è lo stato administratively DOWN dovuto a down_on_first_join, da sanare con il comando di members-admin-state, non con un riavvio.