FACOLTÀ DI SCIENZE MM. FF. NN

Transcript

1 UNIVERSITÀ DEGLI STUDI DI SALERNO FACOLTÀ DI SCIENZE MM. FF. NN CORSO DI LAUREA IN INFORMATICA TESI DI LAUREA IN CALCOLO DELLE PROBABILITA' E STATISTICA MATEMATICA Progettazione di sistemi ad alta affidabilità per le rilevazioni statistiche. Caso di applicazione : Ufficio di statistica della Provincia di Salerno Relatore: Candidato: Ch.mo Prof. Antonio Di Crescenzo Christian Rago Relatore esterno: Matr.: Dott.ssa Roberta Morena ANNO ACCADEMICO

2 Un grazie al Professore Di Crescenzo per l'opportunità, alla Dottoressa Morena e all'ingegnere Vuolo, più che semplici colleghi. Un grazie alla mia famiglia, che mi ha sostenuto sempre, anche nei periodi più brutti. Ai miei amici,che continuano a chiedermi quando mi laureo.

3 Indice generale Introduzione...2 CAPITOLO 1: Alta Affidabilità (HA) Livelli di affidabilità Sistemi ad alta affidabilità Cluster HA Introduzione al Cluster Progetti Open Source per Cluster HA Come creare un cluster HA opensource Configurazione delle macchine Heartbeat Pacemaker Apache Cos'è Apache? Configurare Apache per cluster HA Configurazione MySQL Introduzione all'sql, MySQL e phpmyadmin Replica Circolare DRBD Configurazione dei nodi...27 CAPITOLO Software Statistico Software selection MAUSS e MAUSS-R ACTR BANFF/GEIS CANCEIS CONCORD IDEA QUIS EVER GENESEES ARGUS Limesurvey...36 CAPITOLO Esperienza diretta Introduzione Personalizzazione della piattaforma Fase finale Conclusioni Potenzialità della piattaforma Sviluppi futuri

4 Introduzione La seguente tesi di laurea nasce da una collaborazione tra l'università degli Studi di Salerno e la Provincia di Salerno. Il tutto è nato da un'attività svolta presso l'ufficio statistico della Provincia, diretto dalla dottoressa Roberta Morena, che punta a informatizzare gli uffici dell'ente Provincia, a digitalizzare tutti gli archivi ancora cartacei, e ad effettuare rilevazioni statistiche all'interno delle strutture di tale Ente. In particolare, nella fattispecie l'attenzione è stata focalizzata sulle rilevazioni effettuate all'interno dell'ente che sono ancora presentate in moduli cartacei e difficilmente consultabili una volta terminate. Proprio per questo è stata progettata una piattaforma di rilevazioni statistiche partendo da un software già largamente utilizzato chiamato Lime Survey che verrà descritto dettagliatamente nel Capitolo 3. Tutta l'attività è suddivisa in tre parti: una parte rivolta alla software selection basata sulle risorse della Provincia; una seconda, lunga e cruciale, che tratta la configurazione del sistema; ed infine una terza sezione circa la modifica del software scelto, test della piattaforma e partenza della prima rilevazione di prova. Il tutto si è svolto sotto la supervisione della dottoressa Morena e dell'ingegnere Gianluca Vuolo, che hanno rivestito il ruolo di coordinatore rispettivamente per la parte statistica e per la parte sistemistica. Sebbene i dati già elaborati e quelli futuri abbiano un livello di criticità relativo, si è scelto di sviluppare un'architettura ad alta affidabilità (HA- High Availability) distribuito su due nodi e basato su sistemi operativi Linux Server. Il prodotto finale della collaborazione su menzionata è stato utilizzato dall'ufficio statistico ed è stato preso in considerazione come nuovo strumento di rilevazione non solo nella Provincia di Salerno ma in molti uffici delle istituzioni pubbliche Campane. 2

5 In particolare, in questa Tesi verrà analizzato il caso d'uso relativo alla raccolta delle informazioni sulle rilevazioni effettuate dall'ente nell'ultimo trienno, e inoltre verrà effettuata una valutazione complessiva sul lavoro svolto. Verrano altresì discusse le potenzialità della piattaforma così come è stata sviluppata, lasciando una porta aperta verso ulteriori modifiche e versioni successive della stessa. Segue una panoramica sugli argomenti trattati nella tesi: Capitolo 1: In questo capitolo verrà spiegato il concetto di High Avaibility e di cluster con un occhio di riguardo allo sviluppo di questa tecnica in ambienti Open Source ed in particolare al sistema operativo Linux Server, base di sviluppo di tutto il progetto. Infine verrano citati i software utilizzati per la creazione del cluster HA e le loro configurazioni. Capitolo 2: Il capitolo è una panoramica sul software Limesurvey, cuore pulsante della piattaforma per le rilevazioni ivi sviluppata. Verrà fornita una breve panoramica dei software proposti come possibile scelta nella software selection proposta all'inizio del progetto e del motivo per cui è stato scelto questo programma. Inoltre verrà focalizzata l'attenzione sulle sue potenzialità, il suo funzionamento e la possibilità di modifiche. Capitolo 3:Qui viene analizzato nei dettagli il caso d'uso che rappresenta il primo utilizzo della piattaforma. Verrà descritta l'esperienza alla base di questa tesi e verrano fornite dei mockup dell'applicativo. Capitolo 4: Nel capitolo conclusivo verrano discusse le prospettive di utilizzo future per il software creato e i miglioramenti a cui può essere soggetto. Inoltre saranno spiegate le proposte già in fase di sviluppo che si basano sul progetto svolto. 3

6 CAPITOLO 1: Alta Affidabilità (HA) 1.1 Livelli di affidabilità Un sistema informatico di solito è soggetto a Disastri, ovvero ad eventi che possono minare i dati elaborati rendendoli corrotti o cancellandoli. A seconda della natura di questi disastri vengono utilizzate delle tecniche che cercano di minimizzarne o eliminarne i danni; a seconda del metodo scelto possiamo distinguere 4 livelli di affidabilità. Primo livello Affidabilità normale: Questo è il livello di affidabilità più basso, i dati vengono preservati unicamente con backup che avvengono periodicamente. I sistemi che appartengono a questo livello sono soggetti a diversi fattori che potrebbero minarne la solidità; in particolare qualora l'intervallo di tempo tra un backup e l'altro portasse alla modifica di molti dati, un eventuale malfunzionamento verificatosi anche solo pochi istanti prima del salvataggio pianificato porterebbe alla perdita dei dati stessi. Inoltre i dati tornerebbero disponibili solo dopo un loro totale recupero, permesso solo da salvataggi di buona qualità. Secondo livello Affidabilità maggiore: I sistemi appartenenti a questo livello comprendono le tecniche già descritte, cercando inoltre di mantenere i backup quanto più aggiornati possibile. Per fare ciò si utilizza una tecnica del mirroring fisico tra dischi come nella già sviluppata tecnologia RAID (Redundant Array of Independent Disks), che rispetto all'utilizzo di un solo disco migliora la tolleranza ai guasti e l'integrità. Anche qui però il ripristino del sistema avviene unicamente dopo un intervento esterno, ovvero il recupero totale dei dati. Terzo livello Alta affidabilità: In questo livello non sono solo i dati ad 4

7 essere tutelati ma anche il servizio erogato dal sistema. Il tutto deve avvenire in maniera autonoma, senza l'aiuto di agenti esterni, quale può essere l'uomo. Nel prossimo paragrafo verranno approfonditi gli aspetti di questo livello. Quarto livello Disaster Recovery: È l'evoluzione finale dell'altà disponibilità. Il sistema che eroga i servizi viene replicato su un sito lontano dal primo, così da evitare anche disservizi dovuti ad esempio a disastri naturali. Esistono diversi livelli di recovery catalogati in base al livello di fault tolerance che si vuole garantire. 1.2 Sistemi ad alta affidabilità Come analizzato in precedenza, i sistemi appartenenti al terzo livello di affidabilità non concentrano la loro attenzione unicamente sui dati ma puntano a fornire un servizio sempre attivo. La traduzione italiana, infatti, non è letterale in quanto in inglese la definizione è High Avaibility, ovvero alta disponibilità; in particolare devono avere una disponibilità del 99,999% (Regola dei 5 9) rispetto al tempo di monitoraggio. Per fare un esempio, se si considera il tempo di utilizzo del servizio di un anno, il periodo massimo in cui il servizio non potrà essere disponibile sarà di 5 minuti e 15 secondi. L'obiettivo, come si nota, è difficilmente raggiungibile, se non attraverso l'eliminazione dei componenti il cui funzionamento potrebbe compromettere il sistema (Single point of Failure), ridondando le componenti critiche o, come nel caso analizzato in questa tesi, creando un cluster. Dato che il primo metodo è molto costoso si preferisce sempre l'ultima opzione poiché non richiede un hardware dedicato e il sistema viene semplicemente riproposto su una seconda macchina con le stesse configurazioni della prima. L'unica nota negativa nella creazione dei cluster è rappresentata dalla complessità del software necessario al corretto funzionamento della struttura e l'attenzione particolare richiesta all'amministratore. 5

8 Il requisito dei cinque 9, spiegato precedentemente, viene visto in due diversi modi: da un lato concentrare tutta l'attenzione unicamente sulla stabilità comporterebbe uno spreco di risorse che potrebbero essere utilizzate in altri punti cruciali, come ad esempio per la tutela dell'integrità dei dati. Da questo ne deriva che per sistemi non critici, come ad esempio quelli che gestiscono pagine web basterebbe un tasso di disponibilità inferiore ("solo" 3 nove ovvero 99,9%).[1] D'altra parte c'è chi considera il requisito di cruciale importanza anche per servizi "accessori". Ad esempio nel caso sovracitato della pagina web, se non consideriamo la stessa come una piccolissima parte del World Wide Web, ma come un punto di rifermento per una specifica azienda, allora si evince subito come un tempo prolungato di mancanza del servizio possa provocare ingenti danni agli utenti finali[2]. Questo è il caso dell'argomento di discussione della tesi; la piattaforma sviluppata è addirittura visibile unicamente in una rete interna, quindi non visibile al pubblico, ma conterrà dati cruciali per l'ufficio statistico, soprattutto se consideriamo che un giorno verrà utilizzata per trasferire i dati relativi a diversi decenni di attività e che dovranno essere rapidamente e facilmente reperibili Cluster HA Introduzione al Cluster 6

9 Illustrazione 1: Struttra generica di un cluster HA con Heartbeat I cluster sono aggregati di diversi nodi che gestiscono un servizio, solitamente applicazioni a livello di server. In alcuni casi possono essere creati in modo da poter distribuire il carico di lavoro su più di una macchina o in altri vengono configurati per avere uno o più nodi in attesa della disattivazione del nodo principale. A prescindere dall'utilizzo che se ne vuole fare, tutti i cluster devono apparire all'applicazione che li utilizza come un unico nodo, lasciando al software di gestione del cluster ogni carico relativo alla distribuzione delle risorse, che si tratti di dividerle o di spostarle.[3] Questo può avvenire unicamente se i file necessari per queste operazioni sono visibili contemporaneamente ad entrambe le macchine; proprio per questo si utilizza una rete privata per la comunicazione di tutti i componenti del cluster. In caso di fault in questo collegamento si può verificare il problema dello split brain, nel quale i nodi del cluster sono scollegati ma tutti funzionanti, di conseguenza ogni nodo cercherà di rendersi attivo e di fornire il servizio portando così ad istanze duplicate che molto probabilmente porteranno ad un corruzione dei dati condivisi. 7

10 A seconda delle configurazioni dei vari nodi abbiamo diversi tipi di cluster[4]: Attivo/Attivo: Come spiega il nome tutti i nodi sono attivi contemporaneamente ed i dati che dovrebbero essere elaborati sul nodo che si disattiva vengono ugualmente distribuiti sui rimanenti. Attivo/ Passivo: Ogni nodo è una copia ridondante del nodo chiamato principale, ovvero quello che fornisce il servizio. Quando questo si disattiva sarà un altro nodo a prendere il suo ruolo lasciando gli altri in stand by. N+1: Questa è una generalizzazione del caso attivo/passivo, N nodi lavoreranno attivamente ed un solo nodo sarà candidato a prendere il ruolo del primo nodo che si disattiverà. Proprio per questo motivo il nodo dovrà essere in grado di lavorare come uno qualsiasi dei precedenti e dovrà essere configurato adeguatamente. N+M: La configurazione precedente può andare bene solo per cluster che gestiscono uno o pochi servizi. Negli altri casi un solo nodo non fornirà un grado di ridondanza affidabile, per questo saranno M i nodi pronti ad attivarsi. Il valore di M è direttamente proporzionale alle risorse dell'azienda e all'importanza dei servizi. N a 1: In questa configurazione alla caduta di un nodo attivo nel cluster composto da N nodi, sarà un singolo nodo a prenderne il posto (come nel caso N+1), ma per un periodo di tempo limitato alla ripresa del nodo originale. N a N: Una combinazione di cluster Attivo/Attivo e N + M. I servizi, le istanze o le connessioni sul nodo down vengono distribuite sui rimanenti nodi attivi in modo da eliminare la necessità di un insieme di nodi in stand by. 8

11 Per quanto riguarda le configurazioni HA si preferisce utilizzare le prime due configurazioni (A/A o A/P).[5] Progetti Open Source per Cluster HA Nel caso in cui si vogliano utilizzare i servizi di un cluster HA è possibile comprare il cluster stesso da un fornitore esterno o utilizzare una suite di programmi Open Source creati unicamente per sviluppare questi sistemi personalmente. Questa soluzione solitamente è quella preferita poiché oltre ad essere notevolmente più economica, permette ad un utente esperto di poter modificare i file di configurazione dei programmi in modo da adattarli ad ogni esigenza. Nell'esperienza qui presentata si è concentrata l'attenzione su programmi come HeartBeat, Pacemaker e DRBD, su tool di MySql e configurazioni particolari di Apache. Il tutto opensource e completamente funzionante per sistema operativo Linux, anch'esso Opensource. Successivamente verrano descritti i programmi e le configurazioni utilizzate per il funzionamento del cluster dell'esperienza Come creare un cluster HA opensource. In questa sede verrà introdotta la suite di programmi più comunemente usata per la creazione di cluster HA opensource in ambiente Linux Server e quindi senza interfaccia grafica;i comandi e i file di configurazione saranno quelli utilizzati per la piattaforma oggetto della tesi, ma cambiando i valori potranno essere rapportati ad ogni altro progetto che vorrebbe sfruttare i seguenti software per un'esperienza simile. 9

12 Configurazione delle macchine Prima ancora di iniziare ad installare il software necessario occorre configurare le macchine e le relative interfaccie di rete. Nell'esempio sottostante considereremo una macchina con due schede di rete poiché, come spiegato nei paragrafi predenti, occorre avere un'interfaccia per la rete pubblica per fornire il servizio ed una per la rete privata necessaria alla comunicazione dei processi interessati all'alta affidabilità. In ambiente Linux è possibile farlo modificando il file /etc/network/intefaces come il seguente: auto lo iface lo inet loopback auto eth0 iface eth0 inet static address netmask gateway auto eth1 iface eth1 inet static address netmask Come si può ben vedere il file è diviso in tre parti, che rappresentano ognuna la configurazione di un'interfaccia di rete, in particolare: auto lo indica l'indirizzo di loopback sull'interfaccia di lo 10

13 auto eth0 indica l'interfaccia con la quale la macchina si collega alla rete pubblica, per cui è stato necessario specificare la maschera della rete e l'indirizzo del gateway relativo. auto eth1 è la configurazione relativa all'indirizzo della rete privata tra le due macchine, contenente unicamente la maschera della rete. Questa configurazione è stata necessaria su entrambe le macchine ovviamente cambiando l'indirizzo IP per la macchina 2 sulla rete pubblica, che sarà e quello sulla rete privata, cioè e dopo aver creato i file è stato fatto ripartire il servizio del networking.[6] Eseguito questo primo passo è stato necessario modificare il file /etc/hosts su entrambe le macchine per rendere le macchine host conosciuti e quindi sicuri, aggiungendo per ogni riga l'indirizzo IP e il nome dell'host. Le macchine sono state chiamate ha1 e ha2 (High Avaibility 1 e 2) sul dominio "piattaforma statistica", di conseguenza il loro nome completo è risultato essere ha1.piattaforma.statistica e ha2.piattaforma.statistica. Conclusa la configurazione, l'attenzione è stata spostata sulla sicurezza relativa a questa prima parte e si è giunti alla conclusione di dover applicare una connessione in SSH sicura tra i due nodi, dato che la nostra piattaforma conterrà molti dati sensibili. Sulla distribuzione Linux occorrono diversi passaggi per effettuare questa operazione, in particolare una creazione della chiave attraverso ssh-keygen e il comando scp capace di effettuare una copia in ssh dei file necessari Heartbeat Heartbeat è un demone utilizzato per la creazione di cluster e permette ai nodi 11

14 collegati di sapere con estrema precisione quando e quali nodi sono attivi o passivi. La sua funzione è solo quella di monitoraggio, quindi per funzionare ha bisogno di un CRM ( Cluster Resource Manager) che dalle nuove versioni è inserito direttamente nel software.[7] Come molti programmi sviluppati su Linux, Heartbeat ha un'architettura modulare. Il primo modulo è quello riguardanti le connesioni ed in particolare quelle gestite dal programma sono 4 tipi differenti: Unicast UDP su IPv4 Broadcast UDP su IPv4 Multicast UDP su Ipv4 Comunicazione su linea seriale In questo modulo viene gestita anche la sicurezza della connessione con l'autenticazione sulla rete privata. Un altro modulo del programma contiene due processi molto importanti che possono per un certo verso essere considerati "processi client" poiché sono esterni al processo principale (chiamato Master Control Process) e dipendono strettamente dalle richieste di servizi fatte a quest'ultimo ovvero: IPFAIL: è il processo che controlla i nodi e ne monitora la connessione, stabilendo quando sarà necessario spostare i servizi che verranno gestiti dal Master Control Process CCM (Consesnsus Cluster Membership): questo è il processo che controlla la connessione tra i nodi funzionanti ed identifica problemi legati a guasti esterni o malfunzionamenti di software. Questi moduli presentati sono la base del software Heartbeat, ma è possibile inserire diversi plugin alla suite standard per renderla ancora più efficace, 12

15 garantendo le massime prestazioni per un cluster HA. In particolare nel caso di studio proposto sono stati utilizzati tre processi (inseriti tramite plugin) ritenuti di grande importanza: Plugin di STONITH Plugin di Comunicazione Plugin di Autenticazione Il primo è un acronimo per Shoot The Other Node In The Head, nome che indica l'utilità del plugin. Esso funziona come un interruttore in grado di evitare il problema del brain-splitting, spegnendo i nodi che si presentano come attivi nonostante il nodo che sta erogando il servizio sia completamente funzionante. Questo può essere causato da un problema di connessione. I plugin di comunicazione invece sono di fondamentale importanza per la gestione dei canali di comunicazione, gestendo il traffico in entrata ed in uscita dal Master Control Process. Esso si divide in due sotto categorie di processi, i processi read, impegnati nella lettura dei messaggi in arrivo dal MCP, e i processi write dediti all'invio di messaggi. L'ultimo plugin è forse il più importante per un cluster che gestisce dati sensibili, poiché garantisce la sicurezza dello scambio di informazioni tra i nodi. Nello specifico controlla che tutti i messaggi in arrivo ed in uscita provengano da nodi interni al cluster e che non vi sia possibilità di "contaminazione" esterna. Le modalità di autenticazione sono 3: crc, sha1 e md5, da specificare nel file di configurazionie /etc/heartbeat/authkeys; in particolare sha1 e md5 sono algoritmi di codifica, mentre crc è il parametro che idica una connessione senza chiave di sicurezza. Come avvenuto per la configurazione delle schede di rete e della lista degli 13

16 host conosciuti, anche il settaggio di Heartbeat è stato effettuato con la modifica di alcuni file di testo, in particolare il già citato /etc/heartbeat/authkeys, e il file /etc/heartbeat/ha.cf, il primo è un semplice file che specifica la modalità di connessione dei nodi mentre il secondo, più complesso, necessita di una spiegazionie. Il file è il seguente: logfacility daemon keepalive 2 deadtime 15 warntime 5 initdead 120 udpport 694 mcast eth1 bcast eth0 node ha1 node ha2 crm respawn Di seguito viene fornita la spiegazione dei principali parametri keepalive: questo parametro indica il tempo in cui i pacchetti inviati tra i nodi restano in vita deadtime: questo è il parametro che indica il tempo di attesa di heartbeat prima che dichiari un nodo "morto" warntime: indica il tempo in cui Heartbeat sospetta che un nodo sia morto initdead: parametro opzionale che indica un deadtime iniziale, attivo 14

17 solo quando heartbeat parte per la prima volta mcast: indica l'indirizzo di multicast a cui devono essere inviati i messaggi di heartbeat bcast: indirizzo di braodcast per i messaggi del software node: indica tutti i nodi presenti nel cluster crm respawn: questa è la riga di comando che indica l'attivazione di pacemaker. Udpport: questo è il numero di porta sul quale verranno inviati i messaggi, attraverso il protocollo UDP. Il file è relativo ad una sola macchina e deve essere uguale per entrambi i nodi. 15

18 Pacemaker Come detto in precedenza il solo Heartbeat non è sufficiente a fornire un architettura ad alta affidabilità, poiché esso controlla solo lo stato dei nodi, inviando e leggendo messaggi. Occorre quindi avere un CRM (Cluster Resource Manager), che si occupa appunto delle risorse presenti nel cluster.[8] Illustrazione 2: Struttura di un cluster Attivo/Passivo con pacemaker e DRBD Anche Pacemaker è in realtà una vera e propria suite di plugin che sono completamente integrati in Heartbeat, aventi numerose interfacce di comando. La più diffusa è stata sviluppata da Dejan Muhamedagic, basata su linee di comando che danno pieno controllo sul cluster e sulla sua configurazione[9]. Nella nuova versione di Heartbeat, Pacemaker è attivabile con una semplice linea di comando nel file ha.cf e la sua configurazione avviene con il comando crm configure edit da consolle. Il file all'attivazione di Pacemaker 16

19 sarà il seguente: node $id="285a de-97ac-04b13e5a1f6c" ha1 node $id="b4fbb893-55d6-4a33-81fb-34f8d010df7f" ha2 colocation ip_with_arp inf: ip1 ip1arp colocation web_with_ip inf: apache2 ip1 Si nota come vengono specificati solo i due nodi con i relativi id e il tipo di servizio da fornire, ovvero un webserver con apache ( che verrà discusso in seguito). La prima fase della configurazione è quella relativa al comportamento dei nodi, effettuata aggiungendo le seguenti linee al file: stonith-enabled="true": questo specifica l'attivazione del plugin STONITH già descritto no-quorum-policy="ignore": qui viene indicata la non considerazione dell'assenza di quorum, ovvero la locazione comune dei dati relativi al cluster. Se questa non sarà accessibile il cluster non dovrà fare nulla. Altre opzioni possibili sono stop (che blocca il cluster), freeze (che lo "congela") e suicide (che effettua un kill su tutti i processi del cluster). Dopo questa fase relativa al comportamento dei nodi è importante inserire la parte relativa al controllo della connettività, possibile attraverso un risorsa chiamata ping e con l'aggiunta del parametro: primitive ping ocf:pacemaker:ping params host_list=" " name="ping" op monitor interval="10s" timeout="60s" op start timeout="60s" op stop timeout="60s" 17

20 Questo parametro crea appunto il ping che ha un Resource Agent di tipo OCF. Il RA controlla la lista degli host da controllare, l'intervallo tra un controllo e l'altro ed i valori di timeout per le risorse. Così configurata però questa risorsa non è sufficiente al controllo della connessione su ogni nodo, ma solo sul nodo configurato in host_list, occorre quindi inserire l'ulteriore riga clone ping_clone ping meta globally-unique="false" per indicare al cluster la creazione di una risorsa ping_clone su tutti i nodi indistintamente. Dopo questi passaggi finalmente ci possiamo concentrare sulla fase relativa alla definizione delle risorse; le due linee da aggiungere al file sono: primitive cluster-ip ocf:heartbeat:ipaddr2 params ip=" " nic="eth0" op monitor interval="10s" timeout="20s" op start timeout="20s" op stop timeout="20s" primitive cluster-apache2 ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" httpd="/etc/init.d/apache2" port="80" op monitor interval="10s" timeout="60s" op start timeout="40s" op stop timeout="60s" group cluster cluster-ip cluster-apache2 Il primo comando crea una risorsa di tipo cluser-ip con parametri ben precisi tra cui i già citati interval, timeout e similar. Di particolare importanza è il parametro ip che comprende l'indirizzo del servizio che dovrà essere erogato ed il relativo parametro nic rappresentante l'interfaccia di rete relativa all'indirizzo logico. Il secondo comando è molto simile al primo ed è quello relativo al servizio di Apache, con i parametri httpd (percorso dell'eseguibile), configfile (percorso del file di configurazione) e port (la porta in cui Apache sarà in ascolto). L'ultima riga di configurazione definisce il gruppo cluster da utilizzare come 18

21 un'unica risorsa. Importante notare che per come è stata impostata la riga, in fase di start partirà prima il servizio di cluster-ip e poi quello di cluster-apache2; in fase di stop verrà stoppato prima il secondo e poi il primo. Arrivati a questo punto della configurazione il cluster erogherà il servizio scelto ma non saprà come comportarsi in caso di assenza della connettività. Ciò significa che se il nodo master (ha1) venisse disconnesso dalla rete, il software non migrerebbe le risorse sul nodo slave (ha2) lasciando il servizio inattivo. Per settare le operazioni da eseguire ad un esito negativo della risorsa ping dobbiamo settare un ultima riga nel nostro file: location cluster_on_connected_node cluster rule -inf: not_defined ping or ping lte 0 Così facendo definiamo una regola chiamata cluster_on_connected_node sulla risorsa chiamata cluster. Questa regola non fa altro che associare un peso di - al nodo in cui la risorsa ping non è definita o la sua creazione non ha avuto esito positivo, rendendolo praticamente incapace di erogare risorse.[10] Apache Cos'è Apache? Apache è un progetto opensource, o meglio un software collaborativo, creato per fornire gli strumenti di creazione di un web server. Il progetto è sviluppato e migliorato da un gruppo di persone in contatto tra loro tramite internet, inoltre è parte dell'apache Software Foundation[11]. Il tutto nacque nel 1995 dalla morte del progetto HTTP nato dalla mente di Rob McCool al NCSA (Nationa Center for Supercomputing Application) ed il gruppo di sviluppo inizialmente comprendeva solo 8 persone, che scelsero il nome Apache, in 19

22 onore alle tribù americane e perché suonava come una contrazione di "a patchy server" ovvero un server nato da patch[12]. La prima versione ufficiale venne rilasciata il 1 dicembre 1995 e in poco tempo soppiantò il server NCSA e nel giro di pochi anni la quasi totalità dei siti presenti su internet erano basati sulla sua tecnologia. Apache presenta un'architettura modulare ed ogni modulo è in grado di rispondere ad una richiesta del client in modo indipendente dato che ognuno ha una sua funzionalità. Illustrazione 3: Struttra modulare di Apache I moduli di apache sono: Core: il programma principale composto da un ciclo sequenziale di chiamate a moduli Traslation: modulo che traduce la richiesta del client Access controll: modulo che filtra le richieste dannose MIME Type: modulo che verifica il tipo di contenuto Response: modulo che invia la riposta al client e fa partire eventuali 20

23 procedure Loggin: modulo di log, che registra operazioni e fallimenti Configurare Apache per cluster HA Le configurazioni effettuate in precedenza si occupano solo di gestire le risorse e l'erogazione dei servizi rispetto al comportamento dei nodi, però per il servizio vero e proprio abbiamo bisogno di configurare Apache, permettendogli così di mettere online la nostra piattaforma. La prima cosa da fare è cambiare l'indirizzo di virtual host nel file /etc/apache2/ports.conf sostituendolo con l'ip che verrà assegnato alla nostra pagina web. Effettuata questa operazione dobbiamo settare il web server in modo che sia ad alta affidabilità ed lo faremo creando il file/etc/apache2/sites-avaiable/piattaforma.statistica come qui indicato: <VirtualHost :80> ServerAdmin support@piattaforma.statistica ServerName piattaforma.statistica DocumentRoot /srv/www/piattaforma.statistica/piattaforma/public_h tml/ ErrorLog /srv/www/piattaforma.statistica/piattaforma/logs/err or.log CustomLog /srv/www/piattaforma.statistica/piattaforma/logs/acc ess.log combined </VirtualHost> 21

24 In questo file sono presenti il riferimento alla documentroot, il nome del server e l'amministratore, oltre all'indirizzo ip e le directory di log. Il file dovrà essere copiato su entrambi i nodi. La seconda parte della configurazione comprende la creazione di due pagine di test sul primo e sul secondo server e della successiva abilitazione del sito, con a2ensite Configurazione MySQL Introduzione all'sql, MySQL e phpmyadmin Finora ci siamo interessati alla parte relativa al servizio e alla sua disponibilità. Affinchè il servizio possa funzionare però non occorre solo il webserver, ma è importante avere una solida struttura per i dati. Come per la maggior parte delle applicazioni web, si è scelto di gestire i dati con un database basato su SQL. SQL è acronimo di Structured Query Language ed è un linguaggio di interrogazione per database relazionali, capace di creare e modificare tabelle e strutture di database e di controllare l'accesso alle stesse. Inizialmente nata dall'ibm, venne standardizzato con il nome SQL- 86 e riconosciuto dall'iso. Ormai tutti i sistemi di gestione del database utilizzano questo standard, modificandolo con diverse funzioni proprietarie. Sebbene sia ormai diffusissimo non mancano comunque le critiche a questo linguaggio, come la scarsa portabilità del codice, dovuta appunto alle personalizzazioni delle varie aziende, lo scarso controllo fornito sui dati nulli e la sua complessità, a volte superflua. SQL è un linguaggio dichiarativo, evolutosi con il tempo con costrutti procedurali, istruzioni per il contollo del flusso dei dati, tipi di dati 22