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
- 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)
- Configura il subsytem modcluster
- Configura il subsytem jgroups, gestendo il valore degli initial host
- Modifica i file .jnlp, impostando come host da contattare l'URL del load balancer (e non più quindi la singola istanza di Wildfly)
- 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)
Interagire con i singoli nodi
File:Cluster tab menu contestuale.png
Modificare l'indirizzo di Apache
File:Cluster tab proxy list.png
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
- 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