Configurazione Cluster Applicativo

Concetti

Partiamo dal concetto di availability, cioè di disponibilità: com’è facile capire intendiamo semplicemente il fatto che un servizio sia attivo e raggiungibile e quanto esso impieghi a rispondere alla nostra richiesta. La High Availability è proprio questa: la capacità di un sistema o di un componente di assicurare una performance alta senza interruzioni di sorta in un dato periodo di tempo. In due parole, un servizio sempre attivo, senza interruzioni,

Come viene misurata l’affidabilità?

Per spiegare la disponibilità, un buon modo è usare le percentuali: spesso infatti ci troviamo davanti alle percentuali di uptime di un sistema rispetto ad un periodo di tempo, dove un valore del 100% significa che il sistema non fallisce mai. Generalmente questa percentuale viene calcolata su base annua, e ciò significa che se qualcuno vi garantisce il 99% di uptime, vi sta dicendo anche che potrebbero esserci 3,65 giorni di downtime in un anno (ovvero l’1%). Dato che quasi quattro giorni di servizio interrotto sono un’enormità, è per questo che spesso sentirete parlare di “nines”, cioè di quanti “nove” dopo la virgola del 99% ci sono. Questi numeri tengono conto di tutti i fattori, inclusa, ad esempio, la manutenzione programmata e quella non programmata.

Cosa rende un sistema altamente affidabile?

Uno degli obiettivi dell’alta affidabilità è di eliminare i cosiddetti “single points of failure”: con questa espressione si intendono quei componenti che causerebbero un’interruzione del servizio qualora dovesse rendersi indisponibili. Ne consegue che qualsiasi componente necessario al funzionamento dell’intera infrastruttura che non abbia un metodo di backup, è per forza di cose da ritenersi un “single point of failure”. Per contrastare questa situazione, ogni componente fondamentale dell’infrastruttura deve essere pensato in un’ottica ridondante: se quel componente smette di funzionare per qualsiasi motivo, ci deve essere un “sostituto” che intervenga immediatamente con le stesse funzioni. Questo concetto può portare a pensare che basti “sdoppiare” ogni componente per avere automaticamente un sistema ad alta affidabilità: non è così, ed oltre ad un sistema ridondante è necessario approntare anche delle tecniche a monte di recovery e di failure prediction.

Sicr@Web e l'alta affidabilità

Nel nostro ambiente di sviluppo, siamo abituati ad avviare un'unica istanza di Wildfly, tramite script o via SWCC. All'avvio, l'application server effettua la lettura del file standalone-full.xml, che riporta la configurazione dei cosiddetti subsytem, sottosistemi che definiscono i servizi gestiti (es datasource, logging, etc)

Nel nostro contesto, in un cluster ci sono più istanze attive di Wildfly su una macchina: la macchina prende il nome di "host" ed ogni istanza prende il nome di "nodo". Per ogni nodo, il file di configurazione utilizzato diventa lo standalone-full-ha.xml, che attiva dei sottosistemi che permettono di attivare servizi per garantire l'alta affidabilità. Con questa topologia (1 host con più nodi), si parla di "cluster verticale".

Le chiamate eseguite dall'applicativo non saranno più dirette al singolo nodo, ma passeranno per un elemento "smistatore", il cui lavoro è "reinderizzare" le chiamate verso un nodo: tale elemento è detto "Load Balancer". Alla prima chiamata, il Load Balancer sceglie un nodo e vi "rigira" la chiamata, creando su quel nodo una sessione: finchè la sessione di quel client è attiva, il load balancer restituirà per quel client lo stesso nodo (questa modalità è detta "Sticky Session"). Se per qualche motivo tale nodo non fosse più raggiungibile, allora sarà compito del Load Balancer eleggere un nuovo nodo su cui "rigirare" la sessione

Creazione del cluster

Da eseguire solamente dopo aver verificato le operazioni preliminari, questa procedura permette di creare rapidamente un cluster verticale

Da SWCC scegliere la voce di menu File → Cluster → Crea Cluster Verticale

Verrà aperta una dialog dove inserire l'URL del Load Balancer. Questa è l'unica informazione da dover inserire

Inserita questa informazione, SWCC inizierà la procedura di creazione del cluster, nel dettaglio

1. Esegue l'allineamento dei file di configurazione, "travasando" le configurazioni dallo standalone-full.xml allo standalone-full-ha.xml, quali
   • Proprietà di sistema (Versione >= 421)
   • logger
   • datasource
   • queue
   • topic
   • deployment-scanner
   • socket-port (offset, http, https, remoting, management-http, management-https)
2. Configura il subsytem modcluster
3. Configura il subsytem jgroups, gestendo il valore degli initial host
4. Modifica i file .jnlp, impostando come host da contattare l'URL del load balancer (e non più quindi la singola istanza di Wildfly)
5. Copia la cartella standalone, creando la cartella standalone-node2

Al termine della procedura è necessario riavviare SWCC per poter iniziare a lavorare in modalità cluster

Esecuzione

[DA COMPLETARE]

La configurazione presente nello standalone-full-ha.xml presenta valori identici tra tutti i nodi: quando verrà avviato l'i-esimo nodo, saranno i parametri forniti al processo standalone.bat/sh a sovrascrivere quelli presenti nel file di configurazione.

Nello standalone-full-ha.xml del primo nodo (nella cartella "standalone") è definito

Strumenti operativi

[DA COMPLETARE]

Sia SWCC che SWCA rilevano automaticamente un ambiente con cluster verticale, presentando un nuovo pannello che permette di avere informazioni di configurazione ed interagire con i singoli nodi

La parte destra del pannello contiene un pulsante per ogni nodo rilevato dall'host: è possibile cliccare sul pulsante per avere un menu contestuale, con il quale poter interagire con il nodo

L'icona del pulsante ha un'icona con un indicatore

• rosso se il nodo è spento
• verde se il nodo è rilevato attivo
• avente l'immagine di un lucchetto se il nodo è attivo in modalità amministrazione (Admin mode)

Come aggiungere un nodo

Al termine dell'operazione, SWCC/A verrà chiuso e sarà necessario ravviarlo

Configurazione Cliente

[DA COMPLETARE]

Questa configurazione permette di creare un cluster verticale sul server di produzione del cliente.

Prerequisiti [DA COMPLETARE]

• Il Sistema Operativo DEVE essere Linux Centos 8 o superiore
• Mod_cluster deve avere al più versione 1.3.3, le versioni successive non funzionano ( rimossa compatibilità con Wildfly 8 )
• I nodi DB ed application, eventualmente anche repository, devono potersi vedere tra loro
• Deve essere presente un'installazione completa di Sicr@web in modalità standard

Operazioni Preliminari

[DA COMPLETARE]

• Modifiche S.O.

• Aggiunta del modulo mod_cluster

yum install https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/os/Packages/m/mod_cluster-1.3.3-11.fc27.x86_64.rpm

• Modificare il file /etc/httpd/conf.modules.d/00-proxy.conf commentando il modulo mod_proxy_balancer

#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

• Editare il file /etc/httpd/conf.d/mod_cluster.conf

Decommentare:

  LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
  LoadModule cluster_slotmem_module modules/mod_cluster_slotmem.so
  LoadModule manager_module modules/mod_manager.so 
  LoadModule advertise_module modules/mod_advertise.so

Commentare tutto il resto e aggiungere in coda:

  Listen *:PORT
  ManagerBalancerName mycluster
  <VirtualHost *:PORT>
  ServerName	IP
  ServerAlias	NOME_HOST
  <Location />
  Options FollowSymLinks
  Order allow,deny
  Allow from all
  Require all granted
  </Location>
  KeepAliveTimeout 300
  MaxKeepAliveRequests 0
  ServerAdvertise On
  AdvertiseFrequency 5
  AdvertiseGroup 224.0.1.108:23364
  AdvertiseSecurityKey S1CR4sicraweb
  EnableMCPMReceive On
  <Location /mod_cluster_manager>
  #Questa configurazione espone al mondo la pagina di amministrazione http://IP:PORT/mod_cluster_manager
  #Sara' necessario limitare l'accesso in produzione.
  SetHandler mod_cluster-manager
  Order allow,deny
  Allow from all
  Require all granted
  </Location>
  Header add Set-Cookie "JSESSIONID=.%{BALANCER_WORKER_ROUTE}e; path=/client" env=BALANCER_ROUTE_CHANGED
  <Proxy balancer://mycluster>
   Order deny,allow
   Allow from all
  </Proxy>
  ProxyPass / balancer://mycluster lbmethod=byrequests stickysession=JSESSIONID|jsessionid nofailover=Off
  ProxyPreserveHost On
  </VirtualHost>

Le voci IP, NOME_HOST, PORT vanno valorizzati con quelli scelti. Al termine riavviare HTTPD.

• Aggiungere al file /etc/sysctl.conf le seguenti righe:

 # Allow a 25MB UDP receive buffer for JGroups
 net.core.rmem_max = 26214400
 # Allow a 1MB UDP send buffer for JGroups
 net.core.wmem_max = 1048576

Ricaricare i valori inseriti con sysctp -p

• Modifiche per Wildlfy

• Aggiungere le seguenti variabili al file .bash_profile di jboss

 export JB_CLUSTER_BIND_ADDRESS=”Nome DNS cluster”
 export JB_CLUSTER_MAN_ADDRESS=”Nome DNS cluster”

• Editare il file standalone.sh/bat

• • Linux

editare il file

 $JBOSS_HOME/bin/standalone.sh

commentare la riga

SERVER_OPTS="--server-config=standalone-full.xml $SERVER_OPTS"

ed inserire

if [ "x$SERVER_OPTS" = "x" ]; then
    SERVER_OPTS="--server-config=standalone-full.xml "
fi

• • Windows

editare il file

 %JBOSS_HOME%\bin\standalone.bat

commentare la riga

set SERVER_OPTS="--server-config=standalone-full.xml %SERVER_OPTS%"

ed inserire

if [ "x%SERVER_OPTS%" == "x" ]; then
   set SERVER_OPTS="--server-config=standalone-full.xml "
fi

• Editare il file %WILDLFY_HOME%\standalone\deploy\sicraweb.ear\sicraweb.war\WEB-INF\web.xml

Inserire la riga <distributable/> nel tag <web-app>

Modificare da 2 a -2:

 <servlet>
   <servlet-name>AutSchedulerStartupServlet</servlet-name>
   <display-name>Sicraweb Scheduler Initialization Servlet</display-name>
   <servlet-class>it.saga.library.authentication.scheduler.AutSchedulerStartupServlet</servlet-class>
   <load-on-startup>-2</load-on-startup>
 </servlet>

• Configurazione del Cluster verticale

N.B. Prima di procedere verificare che l'installazione base di wildfly sia completa ( Da SWCA: Installa - Configurazione - Setup )

Seguire la guida: http://buildenv.maggioli.it/wiki/index.php?title=Configurazione_in_Cluster#Creazione_del_cluster

Gestione del Cluster

• Aggiornamenti

Gli aggiornamenti vengono gestiti tramite il tool SWCC/A. Non sono richiesti interventi manuali anzi sono ALTAMENTE sconsigliati

• Start/stop nodi

Per lo start e stop dei nodi, oltre che per la consultazione dei log è stato approntato uno script apposito: clu

Avviare SWCC/A, selezionare il pannello admin cluster, tasto destro sul nodo e premete genera script [ La procedura deve essere fatta per tutti i nodi ].

Verranno generati degli script per ciascun nodo con le variabili necessarie alla loro gestione tramite lo script clu

Esempi:

 clu "nome nodo" "comando"
 clu node1 stop/start/log/logcompleto
 clu node2 stop/start/log/logcompleto