Università degli Studi di Napoli Federico II. Facoltà di Scienze MM.FF.NN.

Transcript

1 Università degli Studi di Napoli Federico II Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica Tesi sperimentale di Laurea Triennale Sistema di monitoraggio dell'infrastruttura impiantistica di un Data Center basato su portlet container Relatori Candidato Prof. G. Russo Armando Cosimo Dr. G. Vitagliano mat. 566/2063 Ing. A. Violetta Anno accademico 2008/2009

2 INDICE GENERALE INTRODUZIONE Il GRID COMPUITING Il progetto S.Co.P.E Il concetto di GRID IMPIANTI SERVER FARM SCOPE Layer della Server Farm Scope Il sistema di raffreddamento Il sistema di alimentazione L'impianto di sicurezza L'impianto antincendio VESDA Cablaggio Strutturato Pavimentazione Canalizzazione Impianto elettrico Illuminazione e messa a terra APPLICAZIONI PER IL MONITORAGGIO DEGLI IMPIANI RITTAL RigetIT RITTAL RiwatchIT PROGETTAZIONE DEL SISTEMA DI MONITORAGGIO INTEGRATO Definizione del problema La scelta del portale: Liferay Il Mock-Up del portale L'Architettura Analisi e progettazione del sistema di monitoraggio degli impianti... 37

3 4.6 La scelta delle metodologie Tecnologie utilizzate IMPLEMENTAZIONE MODULO I Funzionamento generale Struttura dell'applicativo La classe SQLTableCreate La classe SelectRackSensor La classe SelectVariable Esempi di output Primo caso d'uso: prima esecuzione Secondo caso d'uso: riconfigurazione del data center IMPLEMENTAZIONE MODULO II Funzionamento generale Scelta del parser Struttura dell'applicativo SAX La classe DefaultHandler I metodi characters e startelement La gestione delle eccezioni IMPLEMENTAZIONE MODULO III Funzionalità della Web Application Struttura dell'albero di navigazione Tecnologie e metodologie VALIDAZIONE E TESTING CONCLUSIONI INDICE FOTOGRAFICO BIBLIOGRAFIA

4

5 INTRODUZIONE Negli ambienti lavorativi moderni è diventato sempre più importante disporre di mezzi tecnologici tramite i quali velocizzare e gestire la ricerca d'informazione. Se un'azienda può disporre più velocemente di dati, documenti e altri fonti informative può migliorare il suo guadagno e le prestazioni. La gestione dell informazione e la creazione della conoscenza, a partire dalle numerose sorgenti di dati raggiungibile tramite la rete, oggi più che mai può rappresentare un fattore determinante nella competitività aziendale. In questo contesto i portali hanno assunto un ruolo fondamentale e si sono evoluti fino ad arrivare agli attuali Enterprise Information Portal (EIP), applicativi che integrano un architettura e un insieme di tecnologie che rappresentano lo stato dell arte nell ambito dei sistemi distribuiti. La manutenzione e l evoluzione di un sistema informativo non è un problema semplice. Coinvolge aspetti economici, tecnologici, culturali ed organizzativi. L aspetto economico è caratterizzato dal fatto che una serverfarm ha la necessità di evolversi sia in termini di apparecchiature hardware ma soprattutto in termini di servizi offerti. Un organizzazione responsabile con un sistema informativo complesso sa che il cambiamento è indispensabile, per cui il suo obiettivo sarà quello di gestirlo in modo da minimizzare l impatto economico. Il progetto da me realizzato, durante il periodo di tirocinio presso la control room di S.Co.P.E., è stato quello di implementare un applicazione web capace di integrarsi a quella già esistente per fornire una visualizzazione più snella e dettagliata degli impianti da monitorare. S.Co.P.E. è un'iniziativa dell Università degli Studi di Napoli Federico II. Nasce con l obiettivo di creare un'infrastruttura di supercomputing general purpose, basata sul paradigma del GRID e sulle più moderne tecnologie di calcolo distribuito, a supporto della ricerca di base e delle Piccole e Medie Imprese. L applicazione creata è stata poi incapsulata all interno di un portlet ed infine pubblicata utilizzando Liferay, un Enterprise Open Source Portal. La scelta del livello su cui effettuare l integrazione è dettata da molti fattori: "raramente" però la valutazione è consapevole, essendo normalmente guidata più da considerazioni di tipo tecnologico che architetturale. Le Cosimo Armando 566/2063 Pagina 1 di 116

6 strategie di integrazione sono classificabili, in prima istanza, con il layer su cui vanno ad agire. Possiamo quindi pensare di integrare a livello di presentazione, a livello di logica applicativa oppure a livello di dati. Nel nostro caso, ho implementato un integrazione a livello di logica applicativa del programma utilizzato dal centro, il RiwatchIT della RITTAL. Questo sistema utilizza il file XML come supporto di memorizzazione di tutti gli eventi che si verificano all'interno del data center; ogni qual volta un dispositivo della sala di calcolo dovesse avere un qualsiasi tipo di problema, questo viene segnalato e memorizzato all'interno di questo file. Non disponendo di nessuna documentazione a riguardo, trattandosi di un prodotto commerciale, ho dovuto eseguire un analisi sintattico - semantica del file XML riuscendo, quindi, ad identificare il set minimo di informazioni atte ad identificare univocamente un messaggio. L applicazione è stata creata utilizzando Java e Sax e suddivisa in tre moduli affinché possa evolvere nel tempo: Il primo modulo è quello che si occupa della creazione del database e della sua popolazione e viene lanciato soltanto in fase di start up, il secondo è quello che si occupa di eseguire la lettura semantica del file XML ed infine, l ultimo, si occupa della visualizzazione delle informazioni prodotte dagli altri due ed è parte integrante del portale per il monitoraggio del data center. Cosimo Armando 566/2063 Pagina 2 di 116

7 1 IL GRID COMPUTING 1.1 IL PROGETTO S.CO.P.E Il progetto S.Co.P.E, ovvero Sistema Cooperativo Distribuito ad alte Prestazioni per Elaborazioni Scientifiche Multidisciplinari, è un progetto che ha come obiettivo quello di realizzare un data center composto da sistemi di calcolo ad alte prestazioni, basato sul paradigma della GRID e sulle più moderni tecnologie di calcolo distribuito, tutto ciò a favore della ricerca e dello sviluppo. La fig.1.1 di seguito riportata, illustra la Server Farm di SCOPE situata a M.S. Angelo (fig.1.1) Data Center SCOPE Il progetto va a modificare ed ampliare una già esistente infrastruttura di rete metropolitana, che connette tra loro tutte le maggiori strutture di ricerca dell Ateneo; Infatti l architettura del data center S.Co.P.E ha integrato risorse già disponibili con nuove componenti hardware e software ad alte prestazioni. Queste risorse sono inglobate poi in un unica piattaforma, che a sua volta permette l'integrazione con altre infrastrutture di GRID presenti a livello nazionale ed internazionale. Cosimo Armando 566/2063 Pagina 3 di 116

8 (fig. 1.2) Rete metropolitana Il data center opera in vari ambiti quali possono riguardare la modellistica, il calcolo numerico ad elevate prestazioni, la gestione di grandi banche dati, la simulazione e l'analisi di informazioni in ambito scientifico; Inoltre sono coinvolte nel progetto diverse aree scientifiche quali: Astrofisica: studio del modello di analisi dati nell'ambito della struttura cosmica su larga scala ; Elettromagnetismo e Telecomunicazioni: progetto di una rete di sensori in connessione wireless operante in architettura GRID e realizzazione di un test - bed per una città sicura; Fisica subnucleare: l'attività consiste nello studio delle interazioni protone - protone ad altissima energia presso l'acceleratore LHC (Large Hadron Collider) del CERN (Esperimento ATLAS); Informatica: metodologie e tecnologie per l'accesso in sicurezza e lavalutazione delle prestazioni di sistemi GRID; Matematica numerica: sviluppo, validazione e testing di codici per la risoluzione numerica di problemi di base della matematica numerica; Scienze dei materiali e dell'ambiente: sviluppo di metodi teorici e protocolli computazionali per la modellizzazione delle proprietà strutturali e spettroscopiche di polimeri e di sistemi nano-strutturati; Cosimo Armando 566/2063 Pagina 4 di 116

9 Scienze della vita: studio modellistico-computazionale dei meccanismi fondamentali alla base di processi di interesse biologico, e interfacciamento di database bioinformatici con metodi di simulazione molecolare; Scienza statistiche e sociali: algoritmi di ottimizzazione per la statistica computazionale basati su GRID computing. Metodologie dell'e-learning basate sull'integrazione di sistemi complessi per la gestione dei contenuti nelle scienze sociali. La parte hardware presente nel data center, comprende le seguenti componenti: 33 rack per il contenimento delle apparecchiature e 33 colonne LCP (Liquid Cooling Package) per il loro raffreddamento; 304 server blade (doppia CPU quad-core per un totale di 2432 core), raggruppati in 16 blade per chassis; 26 server 1U; 10 server 2U; Otto server 8U quadriprocessore dual-core; Soluzione di storage misto: 200Terabyte di Storage Fiber Channel + 32 Terabyte di Storage iscsi; Rete Gigabit ethernet; Infiniband su ogni macchina; Rete Fibre Channel. 1.2 IL CONCETTO DI GRID La parola Griglia è stata utilizzata per la prima volta verso la metà degli anni Novanta e denota un'infrastruttura reticolare su scala geografica, nella quale tutte le strutture appartenenti ad essa, condividono risorse ed organizzazione. La condivisione non è limitata al singolo scambio di file o al semplice accesso dei dati e delle risorse, ma anche all'utilizzo diretto dei computer. Cosa necessaria affinché si possa usufruire di questi privilegi, è che si faccia parte della stessa Organizzazione Virtuale. Cosimo Armando 566/2063 Pagina 5 di 116

10 Queste organizzazioni sono degli insiemi di persone che al fine di raggiungere uno scopo comune, hanno bisogno di condividere risorse e dati attraverso regole ben determinate. Questo modello di condivisione, quindi, non si definisce a priori, ma può essere modificato nel corso del tempo a seconda delle necessità richieste dal gruppo, come ad esempio il bisogno di nuovi o particolari servizi, abilitare o disabilitare l'uso di questi a nuovi utenti e tante altre funzioni che possono rendere il gruppo ben organizzato. Da quanto detto si può facilmente notare che una organizzazione virtuale non è caratterizzata tanto da chi ne fa parte ma da un insieme di regole che ne formano una giusta politica di condivisione delle risorse. In questo modo è possibile unire e collegare insieme varie risorse, anche tra loro eterogenee, realizzando di fatto un'unica e grande entità informatica. Caratteristica comune per tutti i progetti GRID è la necessità di avere un data center ben strutturato. Le applicazioni devono poter accedere a grandi quantità di dati geograficamente distribuiti in maniera veloce e affidabile. Il principale compito della GRID, è proprio quello di far eseguire tali applicazioni nel miglior modo possibile. La Server Farm sarà, quindi, costituita da sistemi ad alte prestazioni che daranno all'utente l'impressione di accedere ad un enorme supercomputer virtuale con una incredibile potenza computazionale e una grossa capacità di memorizzazione, in grado di supportare grandi carichi di lavoro. La visione logica data all'architettura GRID, come un unico supercomputer virtuale, necessita di uno schedulatore di risorse (Resource Broker), ovvero di un gestore capace di allocare le risorse necessarie per il completamento dei lavori (job) sottomessi dagli utenti. La scalabilità e l'interoperabilità rappresentano due caratteristiche fondamentali affinché una GRID possa essere efficace. La prima garantisce il graduale incremento della potenza di calcolo disponibile man mano che le risorse entrano a far parte della rete, mentre la seconda consente la compatibilità tra i diversi tipi di risorse ed un'evoluzione dinamica delle VO. Cosimo Armando 566/2063 Pagina 6 di 116

11 2 IMPIANTI SERVER FARM SCOPE Il valore strategico, negli ultimi anni, è diventato un aspetto fondamentale riguardante la progettazione dei moderni sistemi informativi; per questo si cerca in tutti i modi di garantire un elevato standard di sicurezza, non solo dal punto di vista delle apparecchiature, ma soprattutto dal punto di vista della continuità del servizio. (fig. 2.1) Logo RITTAL Con Rimatrix5, l'azienda RITTAL (multinazionale con sede in Germania) offre una griglia di protezione a 360 per i centri di elaborazione dati, con un servizio esteso ai seguenti aspetti strategici: soluzione per i rack, alimentazione e distribuzione di corrente, raffreddamento e climatizzazione, monitoraggio e remote management. Infatti è possibile avere per il singolo rack o per l intera sala un concetto unico e integrato di sicurezza. Con la soluzione integrata RITTAL RimatriX5, è possibile sfruttare al massimo le prestazioni dei server e allo stesso tempo ridurre al minimo i costi. 2.1 LAYER DELLA SERVER FARM SCOPE L'infrastruttura del data center è composta da 33 armadi di tipo server rack atti a contenere gli apparati per il supercalcolo distribuito. I primi 12 sono relativi al progetto SCOPE, gli ultimi 10 invece appartengono ad ATLAS, mentre i restanti 11 armadi sono ancora vuoti ma pronti a contenere altre apparecchiature per successivi ampliamenti infrastrutturali. Cosimo Armando 566/2063 Pagina 7 di 116

12 (fig. 2.2) Interno del capannone scope Suddetti armadi sono stati forniti dalla RITTAL, e si presentano con una struttura denominata 'TS8', brevettata dalla stessa azienda, che consiste in uno scheletro in lamiera ripiegata su se stessa per 16 volte, atta a garantire una tenuta di carico applicato ed uniformemente distribuito di più di 1000Kg. Il grado di protezione all'intrusione delle polveri ed all'acqua offerto dai rack, segue la normativa europea CEI in base alla quale la protezione che può fornire un rack è rappresentata da una sigla costituita da due lettere quali sono IP (International Protection) seguito, poi, da due cifre che vengono fissate in base al grado di protezione dell'armadio. Le cifre sono determinate dalle tabelle di seguito riportate: 1 cifra - protezione contro il contatto di corpi solidi esterni e contro l'accesso a parti pericolose: Protezione del materiale protezione delle persone 0 non protetto non protetto 1 protetto contro corpi solidi protetto contro l'accesso con il Cosimo Armando 566/2063 Pagina 8 di 116

13 di dimensioni superiori a dorso della mano 50 mm 2 corpi solidi di dimensioni superiori a 12 mm accesso con un dito 3 corpi solidi di dimensioni superiori a 2.5 mm accesso con un attrezzo 4 corpi solidi di dimensioni superiori a 1 mm accesso con un filo 5 protetto contro la polvere accesso con un filo 6 totalmente protetto contro la polvere accesso con un filo 2 cifra - protezione contro la penetrazione dei liquidi protezione del materiale 0 non protetto 1 protetto contro la caduta verticale di gocce d'acqua 2 caduta di gocce d'acqua con inclinazione max di 15 3 pioggia 4 spruzzi d'acqua 5 getti d'acqua 6 ondate 7 effetti dell'immersione 8 effetti della sommersione Oltre alle due cifre, l'acronimo IP può essere seguito (ma non necessariamente) da un massimo di due lettere le quali sono scelte dalle seguenti tabelle: 1 lettera aggiunta - opzionale A B C D protezione delle persone protetto contro l'accesso con il dorso della mano accesso con un dito accesso con un attrezzo accesso con un filo Cosimo Armando 566/2063 Pagina 9 di 116

14 2 lettera aggiunta - opzionale H M S W protezione del materiale apparecchiature ad alta tensione provato contro gli effetti dannosi dovuti all'ingresso dell'acqua con apparecchiatura in moto effetti dannosi dovuti all'ingresso dell'acqua con apparecchiatura non in moto adatto all'uso in condizioni atmosferiche specificate La protezione relativa ai rack del data center e' di tipo IP55, quindi garantisce immunità rispetto alla polvere ed ai forti getti d'acqua. Verosimilmente tramite questo tipo di protezione è stata migliorata anche la qualità e la vivibilità umana nella sala, poiché gli armadi con protezione IP55 abbattono il rumore generato dagli apparati, che risulta, così, essere rispondente alle normative vigenti in materia. Detti armadi sono raffreddati da 33 colonne di climatizzazione ad essi affiancati, garantendo così il giusto equilibrio termico. 2.2 IL SISTEMA DI RAFFREDDAMENTO All'esterno della Server Farm, ci sono due chiller che vengono utilizzati per il raffreddamento ad acqua di tutte le apparecchiature dell'infrastruttura. I chiller o ricircolatori di calore, sono delle apparecchiature in grado di ricevere in ingresso grosse quantità di acqua e di assorbirne il calore in modo da poter utilizzare la stessa per raffreddare le apparecchiature all'interno della sala. Spesso il calore imprigionato dai chiller, che e' stato ricavato dall'acqua in ingresso, viene utilizzato per vari scopi quali possono essere il riscaldamento di apparecchiature o di ambienti. I chiller sono collegati a quattro pompe che lavorano alternativamente, e che immettono l'acqua all'interno delle tubature collegate alla sala. Sempre per ottenere un impianto efficiente e ridondante sono stati installati quattro tubi, due per il flusso di andata e due per il flusso di ritorno in modo che la momentanea interruzione di una delle tubature non sia ostacolo per il corretto Cosimo Armando 566/2063 Pagina 10 di 116

15 funzionamento delle apparecchiature. Il raffreddamento dei rack avviene grazie a delle colonne (enclosure) dette LCP (Liquid Cooling Package) che affiancano gli armadi rack e provvedono al loro raffreddamento. Il procedimento avviene, tramite degli scambiatori acqua-acqua che risultano essere molto più efficaci degli scambiatori aria-acqua e addirittura quattro volte migliore rispetto alla sola aria. (fig. 2.3) Funzionamento LCP Ogni colonna LCP può accettare fino a tre moduli di raffreddamento in modalità plug&play; Il dettaglio tecnico precedentemente descritto permette : Di soddisfare, in caso di emergenza, una richiesta maggiore di acqua; La scalabilità dell'impianto in quanto basterà inserire nuove colonne di raffreddamento LCP; Una facile manutenibilità a caldo a causa della modularità dell'impianto. Il sistema, infine, attraverso le tubazioni di ritorno ed ad un circuito a doppio anello (sempre per ridondanza) convoglia l'acqua riscaldata verso la sorgente e quindi ai chiller, che provvedono al raffreddamento della stessa. Cosimo Armando 566/2063 Pagina 11 di 116

16 2.3 IL SISTEMA DI ALIMENTAZIONE Il sistema utilizzato è il Power Modular Concept (PMC) della RITTAL, attraverso il quale è stato possibile preservare l'efficienza e la sicurezza di tutti i dispositivi fornendo un'alimentazione corretta agli armadi server. Per la realizzazione del sistema sono stati utilizzati armadi PDR (Power Distribution Rack) atti alla sub-distribuzione di corrente agli armadi Server in modalità plug&play. La fig. 2.4 mostra lo schema implementativo utilizzato. (fig. 2.4) Rete PCM ideata da RITTAL L'armadio PDR(1), che riceverà la corrente da un pannello generale, fornisce 4 moduli PDM(2) ( Power Distribution Modul ) con i quali sono alimentate le barre PSM (3) ( Power System Modul )all'interno degli armadi. Di seguito vengono descritti i componenti utilizzati: - PDR (Power Distribution Rack) Il PDR è un armadio atto alla distribuzione elettrica secondaria al quale si attestano i cavi provenienti dal quadro elettrico Generale. Completamente protetto dai contatti Cosimo Armando 566/2063 Pagina 12 di 116

17 accidentali, è predisposto per 8 uscite con connettore per 4 poli, certificato per l accettazione HOT SWAPPABLE (a caldo) di max 8 moduli PDM di subdistribuzione, consentendo l upgrade per la distribuzione secondaria fino a 250 A per fase a caldo, ovvero senza togliere alimentazione agli apparati in esercizio. - PDM (Power Distribution Module) Gli armadi PDR sono equipaggiati di moduli ad innesto rapido PDM che è un quadretto di sub-distribuzione elettrica che consente una installazione rapida di tipo plug & play HOT SWAPPABLE e un'alta scalabilità riducendo i costi di montaggio. Ciò consente una installazione molto semplice: si inserisce il modulo PDM all interno del PDR, si fanno aderire i connettori e, girando l interruttore del quadretto, si ottiene il blocco meccanico del PDM e l alimentazione alle 4 uscite di distribuzione. Dalle 4 uscite poste nella parte posteriore del PDM, attraverso i cavi preconnettorizzati e di adeguata lunghezza si andranno ad alimentare 4 canaline modulari di alimentazione PSM. - PSM (Power System Module) Il nuovo sistema PSM è l ultimo elemento per la distribuzione di corrente all interno degli armadi. E costituito da una barra di alimentazione completamente protetta dai contatti accidentali che viene montata all interno degli armadi rack ed è studiata per semplificare le operazioni di cablaggio e ridurre i costi di installazione fornendo alimentazione di corrente sicura e senza interruzioni. Riduce significativamente le operazioni di cablaggio e di montaggio in quanto anch esso modulare, consente di con figurare il tipo di alimentazione da distribuire facilmente nei rack grazie ad una guida di supporto verticale dotata di alimentazione trifase sulla quale inserire a scatto diversi tipi di moduli ad innesto plug&play (hot swappable) per l'alimentazione dei componenti attivi. Il sistema di alimentazione parte dall'esterno della sala dove e' situato un gruppo Cosimo Armando 566/2063 Pagina 13 di 116

18 elettrogeno (G.E.) dal quale proviene l'alimentazione di tutto l'impianto. Il G.E. fornirà energia a sufficienza per alimentare due UPS ( Gruppi di continuità ) chiamati UPS A e UPS B che si ripartono il carico di corrente che il gruppo elettrogeno stesso riesce ad erogare. I due UPS, a loro volta, ripartono corrente a 6 armadi di alimentazione secondaria PDR, ognuno dei quali alimenterà una sola parte dei rack che si trovano all'interno della sala. L'armadio PDR e' formato da moduli PDM, dei moduli plug&play, che contengono gli interruttori magnetotermici a 16 A che provvedono all'alimentazione dei rack. Gli armadi PDR lavorano a coppie; infatti i rack che alimenterà un PDR con i relativi moduli PDM saranno alimentati anche da un altro PDR (con i relativi PDM). La differenza tra i due, sta nel fatto che mentre un modulo PDR alimenterà la parte sinistra della dorsale del rack, l'altra alimenterà la parte destra. La dorsale è costituita da n 6 moduli PSM i quali sono suddivisi tre per parte (3 sul lato sinistro e 3 sul lato destro). Questi moduli, detti intelligenti data la loro capacità di autogestione, forniranno dunque le prese sulle quali i componenti attivi e passivi presenti all'interno del rack, potranno attestarsi. La ripartizione di corrente descritta, che avviene già a monte sugli UPS, viene effettuata per ottenere la ridondanza dell'impianto elettrico ed evitare, di conseguenza, interruzioni di lavoro da parte del sistema di calcolo. 2.4 L IMPIANTO DI SICUREZZA Il capannone è equipaggiato con un sistema CMC-TC di sensori efficiente per tutti i fattori ambientali critici quali possono essere la temperatura, l'umidità, lo scarso raffreddamento, la scarsa alimentazione, ed altri. Il modulo detto Security permette di ottenere elevati standard di sicurezza sia per i rack che per l intera sala. Il CMC-TC è un dispositivo che permette la realizzazione di un sistema completo di controllo e gestione della sicurezza e della prevenzione. Il dispositivo permette di controllare gli accessi, monitorare e regolare la temperatura e di rilevare la presenza di fumo. A tal Cosimo Armando 566/2063 Pagina 14 di 116

19 fine sono state installate e configurate centraline di gestione chiamate PU II (Processing Unit) gestibili via IP. Ogni centralina di gestione ambientale ha il compito di controllare e monitorare i seguenti sensori per armadi rack: Temperatura; Umidità; Controllo presenza fumo; Anti allagamento; Sensore apertura porte. Il dettaglio dei collegamenti è riportato in fig. 2.5: (fig. 2.5) Schema logico dei collegamenti tra PU II e Unit di I/O Lo schema precedente evidenzia un altro componente disposto a valle delle PU, chiamato unità di I/O e collegato alle stesse tramite cavo RJ45. Una PU(II) può essere collegata ad un massimo di 4 I/O che a sua volta può essere congiunta (sempre tramite cavo RJ45) ad un massimo di 4 sensori: Cosimo Armando 566/2063 Pagina 15 di 116

20 - Sensore di accesso : consentirà il monitoraggio di porte, pareti laterali o finestre degli armadi di rete. Il magnete viene applicato alla parte mobile (ad es. la parete), il contatto reed (interruttore in lamina che si chiude in presenza di un campo magnetico) alla parte fissa (telaio dell armadio). Il magnete permanente mantiene chiuso il contatto reed. In pratica se la porta viene aperta o la parete smontata, il circuito si apre e scatta l allarme nel CMC. - Sensore antifumo : converte le particelle di fumo in segnali ottici ed elettronici all interno di una camera di misurazione. Il sensore è dotato di un dispositivo di identificazione che ne consente il riconoscimento e la taratura automatica da parte del sistema CMC-TC. - Sensore LCP : Il modulo LCP (Liquid Cooling Package) è collegato alla PU attraverso idoneo cavo di collegamento e, si potrà così gestire e inoltrare messaggi di allarme, di stato e parametri di misura o attuare a distanza azioni preventive/correttive a salvaguardia delle macchine. - Sensore termico : ha la funzione di monitorare la temperatura all interno degli armadi rack ed è dotato di un dispositivo di identificazione che ne consente il riconoscimento e la regolazione automatica da parte del sistema CMC-TC. - Sensore umidità : misura l umidità relativa dell aria e la trasforma in un segnale di frequenza. Il sensore è dotato di un dispositivo di identificazione che ne consente il riconoscimento e la taratura automatica da parte del sistema CMC-TC. - Sensore allagamento : posto sotto il pavimento tecnico, attraverso la sua testina ottica invierà il segnale di allarme allagamento non appena rilevata l umidità. Il sensore è dotato di un dispositivo di identificazione che ne consente il riconoscimento e la taratura automatica da parte del sistema CMC-TC. Cosimo Armando 566/2063 Pagina 16 di 116

21 - Modulo unità GSM : sono state fornite dieci unità GSM per inoltrare i messaggi di allarme principali. La comunicazione degli allarmi avviene in formato SMS. L'unità GSM è collegata tramite una interfaccia seriale all'unità di processo. Necessario per il funzionamento del modulo è una carta SIM che può essere del tipo «data only» o le carte SIM comuni. Si potranno impostare fino a quattro numeri telefonici assegnando loro diversi eventi. Inoltre queste unità sensori sono predisposte per essere collegate e quindi monitorare anche le scarpette intelligenti (PSM) che si trovano lungo i lati dei rack (dorsali) che permettono l'alimentazione dei componenti che si trovano in esso. 2.5 L IMPIANTO ANTINCENDIO A protezione della sala CED e delle apparecchiature di calcolo è stato utilizzato un impianto antincendio automatico di rilevazione e spegnimento a gas chimico denominato HFC227. I sistemi che utilizzano gas estinguenti HFC sono progettati per raggiungere l'estinzione delle fiamme entro 10 secondi ed ottenere una rapida protezione delle apparecchiature e dell'intera sala. Ciò è fondamentale in presenza di incendi che evolvono molto rapidamente oppure in presenza di oggetti di elevato valore tecnico ed economico. Gli HFC sono stoccati in fase liquida e necessitano di minori quantità di agente estinguente, perciò i sistemi con gas estinguenti HFC utilizzano un minor numero di bombole rispetto ad altri estinguenti gassosi e di conseguenza occupano spazi di stoccaggio inferiori. Infatti, i sistemi con gas HFC sono progettati per miscelare omogeneamente il gas estinguente con l aria del locale da proteggere, al fine di raggiungere la concentrazione necessaria per l estinzione. Tale concentrazione deve essere mantenuta costante fino a che il pericolo delle fiamme è eliminato. Il sistema di controllo e supervisione automatica dell'impianto è assicurato da una centralina di comando che provvede a tutte le funzioni sequenziali come: segnalazione allarmi, stato e funzionalità dei sensori, anomalie, comando scarica e servizi ausiliari, a cui fanno capo tutte le componenti dell'impianto antincendio. Il Cosimo Armando 566/2063 Pagina 17 di 116

22 funzionamento automatico dell'impianto viene garantito dalla centrale, per mezzo del sistema della rivelazione mediante l'impiego di diversi sensori quali temperatura fissa o variabile, di fiamma, di scintilla, di pressione, di gas ed altri. Per la rilevazione negli armadi è previsto un sistema aggiuntivo di tipo ad aspirazione VESDA, con campionamento singolo su ogni armadio VESDA VESDA (Very Early Smoke Detection), è un sistema che si basa sulla tecnica dell aspirazione dell aria (campionamento) della zona protetta e della sua continua analisi. L aria viene continuamente spinta nelle tubazioni da un sistema di aspirazione interno. Un campione di questa aria viene immesso nel filtro della camera di rivelazione; qui il campione si trova esposto ad una fonte di luce laser molto stabile; la luce filtrata o deviata dal fumo è rilevata da recettori molto sensibili. Il segnale risultante viene elaborato e presentato sul display del grafico. Le centraline VESDA, dialogano con una centrale analogica generale adibita al controllo degli allarmi ed ai comandi per l attivazione degli impianti di spegnimento. 2.6 CABLAGGIO STRUTTURATO PAVIMENTAZIONE E' stata prevista l'installazione di un pavimento flottante nella sala e la concretizzazione di tue tipologie di pavimentazione una per il sostenimento delle strutture rack e l'altra per il pavimento flottante. Le due tipologie di strutture sono collegate tra di loro e sono state costruite in modo che possano essere in grado di garantire all intero pavimento stabilità, affidabilità e accessibilità per ogni punto della sala. I vantaggi di tale soluzione sono stati : resistenza a carichi elevati nei punti di appoggio delle batterie di rack; compattezza e perfetto accoppiamento dei pannelli di chiusura del pavimento; modularità dei pannelli di chiusura di dimensioni adeguate in grado di garantire perfetta accessibilità ai servizi posti all interno dello stesso, per la gestione e la manutenzione della sala stessa; accesso per gli operatori invalidi, Cosimo Armando 566/2063 Pagina 18 di 116

23 parabordi in gomma e battiscopa perimetrale CANALIZZAZIONE La struttura delle canalizzazioni è costituita da una griglia di dimensioni variabile e posizionata al di sotto del pavimento flottante, per garantire la posa di tutti i cavi. Il vantaggio è visto in termini di installazione, successiva gestione, accessibilità, espandibilità e ad un corretto sezionamento dei circuiti elettrici IMPIANTO ELETTRICO La realizzazione dell impianto di distribuzione della potenza elettrica prevede una architettura di tipo stellare per tutte le utenze da servire sposando appieno il concetto di scalabilità, flessibilità ed espansibilità, grazie alla razionalizzazione dei carichi in gioco. Il valore aggiunto è la creazione di circuiti completamente disgiunti; in particolare sono state alimentate separatamente due isole, la prima formata da 17 rack e l altra da 16 e di conseguenza tutte le altre utenze. Inoltre si sono realizzate tre pannelli elettrici; il primo per l alimentazione dei quadri di distribuzione elettrica dei rack, centrale antincendio, centrale video sorveglianza, terminali controllo accessi; il secondo per l alimentazione delle utenze al servizio del sistema di raffreddamento; il terzo per i servizi della sala controllo remoto e del centro stella ILLUMINAZIONE E MESSA A TERRA Il valore aggiunto per l impianto di illuminazione, è la scelta delle lampade fluorescenti che sono caratterizzate dall'avere valori di luminanza relativamente bassi ed elevati valori di efficienza luminosa. Cosimo Armando 566/2063 Pagina 19 di 116

24 3 APPLICAZIONI PER IL MONITORAGGIO DEGLI IMPIANTI L'interrogazione del sistema CMC-TC, avviene attraverso l'utilizzo di una piattaforma software denominata RIwatchIT della RITTAL. Utilizzando questo sistema è così possibile monitorare tutti i componenti dell infrastruttura. Le temperature dei rack o di particolari componenti quali il sistema LCP, sono analizzate in tempo reale. In questo modo è possibile, preventivamente, pianificare sostituzioni o riparazioni. 3.1 RITTAL RIGETIT Il RIgetIT è un software che serve alla configurazione progettuale di tutti gli elementi che la RITTAL ha fornito e che sono posti in opera nel capannone SCOPE. Il sistema guida l utente attraverso una procedura di configurazione dei componenti da utilizzare. Il risultato di questa fase è la realizzazione di una infrastruttura progettata professionalmente e visualizzabile graficamente. 3.2 RITTAL RIWATCHIT Il RIwatchIT è il software di controllo dei componenti Rimatrix5 e funziona in combinazione con il RIgetIT. RIwatchIT visualizza lo stato del data center mediante una rappresentazione grafica dello stesso. Lo stato delle apparecchiature viene modificato dai file XML continuamente aggiornati dalla lettura dei messaggi SNMP prodotti dal sistema CMC-TC. Il sistema RIwatchIT e' formato da due moduli separati: il primo e' il RUN VIEW MODULE e viene utilizzato dagli operatori che possono soltanto visualizzare le informazioni; il secondo modulo chiamato ADMIN MODULE, si occupa della gestione del monitoraggio ed è quindi utilizzato dagli amministratori del sistema. La fig. 3.1 mostra l'ambiante grafico del sistema di monitoraggio: Cosimo Armando 566/2063 Pagina 20 di 116

25 (fig. 3.1) Rappresentazione del Data Center in VIEW MODULE Sulla parte destra della finestra appaiono gli stati delle funzioni principali che sono : RACK, POWER, COOLING, SECURITY. Nella parte inferiore, invece, compariranno le trap di notifica degli eventi (allarmi, warning, ecc.) prodotti dal data center. La parte centrale è riservata all'immagine del data center che rappresenta l intera infrastruttura installata. In caso di evento critico, per esempio di allarme, immediatamente nella parte di destra verrà notificato l evento, come l allarme nella casella Security della figura sopra riportata. Cliccando sulla notifica si aprirà una finestra che consente di lavorare sull allarme ed eventualmente terminarlo una volta risolto il problema. In questo modo eliminiamo l'evento dal sistema ma non dallo storico che potremmo utilizzare per considerazioni future. La fig. 3.2 mostra il dettaglio di un componente: Cosimo Armando 566/2063 Pagina 21 di 116

26 (fig. 3.2) Componenti del Rack Il sistema fornisce la possibilità di modificare i parametri del sistema, come ad esempio le soglie di temperatura (fig 3.3), e di accedere, attraverso la funzione History, ai grafici sull'andamento di ciascun sensore o componente installato (fig. 3.4). Inoltre è possibile monitorare l'andamento dell'armadio LCP, e quello di tutte le componenti delle quali è formato, come mostrato in figura 3.5. Cosimo Armando 566/2063 Pagina 22 di 116

27 (fig. 3.3) Schermata di modifica dei parametri (fig. 3.4) Schermata visualizzazione grafici Cosimo Armando 566/2063 Pagina 23 di 116

28 (fig. 3.5) Visualizzazione degli LCP Per una rapida verifica di tutti i componenti installati, inerenti ad ognuno degli elementi principali, il software permette di evidenziare, utilizzando il tasto destro del mouse, una nuova finestra di dettaglio in cui è riportata la situazione attuale dei sensori e dei componenti che ne garantiscono la sicurezza. Un esempio è mostrato nella figura 3.6. Cosimo Armando 566/2063 Pagina 24 di 116

29 (fig. 3.6) Verifica degli stati 4 PROGETTAZIONE DEL SISTEMA DI MONITORAGGIO INTEGRATO Nel ciclo di vita di un sistema di calcolo ad alte prestazioni, il monitoraggio delle apparecchiature riveste un ruolo fondamentale. Infatti fa in modo che lo stesso data center possa svolgere i suoi compiti in maniera ottimale ed efficiente, limitando gli errori e le interruzioni, ma soprattutto allungando il ciclo di vita delle apparecchiature delle quali, lo stesso, è formato. Per ottenere questi obiettivi vengono utilizzati numerosi sistemi di monitoraggio, infatti il RIwatchIT, precedentemente descritto, è uno dei tanti utilizzati dal gruppo di lavoro SCOPE per tenere traccia dello stato delle apparecchiature dell'intero centro di calcolo. Cosimo Armando 566/2063 Pagina 25 di 116

30 Per quanto riguarda il monitoraggio dell'infrastruttura, dei server e dello storage, il centro utilizza NAGIOS. Il sistema interroga periodicamente i dispositivi tramite protocollo SNMP. NAGIOS è un sistema open source, di tipo modulare, capace,quindi, di ampliare le proprie funzionalità con l'aggiunta di plug-in. Un altro sistema di monitoraggio per la manutenzione ed il controllo degli apparati che compongono il data center, è POWERFARM: un sistema di monitoraggio degli impianti, creato da un gruppo di studenti tirocinanti, che si occupa di tenere sotto controllo i dispositivi del Data Center. Il sistema è predisposto per lo spegnimento e l'accensione degli stessi. NAGIOS e POWERFARM sono solo due dei sistemi di monitoraggio utilizzati nell'ambito del progetto SCOPE; Ad accompagnare questi c'è GANGLIA che è un sistema di controllo distribuito per sistemi ad elevate prestazioni, come i cluster o le GRID. GANGLIA è un progetto open source che nasce dalla University of California ed utilizza file con struttura XML per la rappresentazione dei dati, XDR per la loro compattazione e RRD tool per l'archiviazione e la loro visualizzazione. L'implementazione è robusta infatti è stato progettato per un vasto insieme di sistemi operativi e di architetture di processore, ed è attualmente in uso in migliaia di centri in tutto il mondo. Tutti i sistemi di monitoraggio descritti, fanno si che il Data Center SCOPE possa lavorare in modo efficiente e sicuro. Nonostante ciò, il gruppo di lavoro ha pensato di progettare ed implementare un sistema in grado di racchiudere tutte le funzionalità di questi sistemi in un unico ambiente di lavoro centralizzato. Il sistema integrato per tanto dovrà permettere di monitorare l'intera GRID e dovrà essere in grado di fornire un unico punto di accesso alle risorse. Il monitoraggio realizzato permetterà di avere una visione generale dello stato della rete, la conoscenza dello stato degli impianti e dei server e della loro diretta gestione. Cosimo Armando 566/2063 Pagina 26 di 116

31 4.1 DEFINIZIONE DEL PROBLEMA L'idea del gruppo di lavoro SCOPE, è stata quella di eliminare i limiti progettuali dei vari sistemi utilizzati andando a realizzare un unico ambiente per il monitoraggio dell'intera GRID e di tutte le apparecchiature che la compongono. A tal fine, non potendo modificare ed utilizzare parti del codice esistente, si è pensato di utilizzare un Enterprise Open Source Portal come ambiente unico per la gestione dei contenuti e degli applicativi. L utilizzo di un EP (Enterprise Portal) permette di incapsulare gli applicativi esistenti senza dover riscrivere gli stessi per far parte di un unico ambiente, mediante l uso di portlet. Questi ultimi sono moduli web riusabili all'interno di un portale. Tipicamente, una pagina di un portale è suddivisa in una collezione di finestre, il cui contenuto viene definito da un diverso portlet. Ciascuno dei quali è destinato ad una semplice applicazione, ad esempio servizi di news, previsioni meteo, o funzionalità legate a forum o . In quanto finestre, i portlet possono essere chiusi o ridotti o spostati. L'utente che accede al portale può così personalizzare la sua pagina, adattando i contenuti della stessa alle proprie esigenze ed ai permessi legati al ruolo assegnatogli. A differenza dei servlet, che possono rappresentare pagine web complete, i portlet rappresentano singoli componenti, aggregati dal portale che svolge la funzione di Web container. Ne consegue che il portlet container del portale ha un ruolo più determinante del servlet container, poiché attraverso di esso i portlet comunicano tra loro, accedono a contenuti remoti e a dati persistenti. Inoltre i portlet non possono essere raggiunti da un URL specifico, in quanto è il portale intero ad avere associato l'indirizzo ed è per questo che i sistemi Nagvis e PowerFarm sono stati inseriti all interno del portale stesso. In questo modo, la funzionalità di Single Sign On (SSO) ovvero di punto unico di accesso è esposta dal Portal Container e non dal singolo applicativo. NagVis è stato configurato per permettere la visualizzazione dello stato della rete: In generale, mostrando tutti i collegamenti in fibra della GRID ed in particolare, illustrando il dettaglio di ogni singolo apparato. Invece PowerFarm è stato dedicato Cosimo Armando 566/2063 Pagina 27 di 116

32 all accensione ed allo spegnimento dei dispositivi dell intero centro di calcolo. 4.2 LA SCELTA DEL PORTALE: LIFERAY Sono stati analizzati molti prodotti open source tra i quali citiamo: JBoss Portal Joomla uportal Exo Portal BnPortal Questi prodotti presentavano pro e contro, ma nessuno riusciva ad offrire tutta una serie di funzionalità evidenziate dal centro in fase di stesura dei requisiti. La scelta è ricaduta su Liferay, un Enterprise Open Source Portal, per le seguenti caratteristiche: SOA Framework, è un tipo di architettura orientata al servizio e si basa sulla creazione di più moduli software interoperabili. Questi sono utilizzati come dei servizi che verranno poi integrati in un unico sistema comune. Secure Single Sign On (SSO), è un sistema specializzato che permette ad un u- tente di autenticarsi una sola volta e di accedere a tutte le risorse informatiche alle quali è abilitato. Granular, Role-Based Authorizations, al fine di garantire che le persone giuste controllo le informazioni giuste, gli amministratori di un portale possono assegnare i singoli utenti o gruppi di utenti diversi "ruoli" che garantiscono diversi livelli di accesso e di modifica. Dynamic Drag & Drop, Liferay è stato il primo portale ad offrire questa funzionalità, consentendo agli utenti di spostare gli elementi diversi in giro per il portale semplicemente trascinandoli nella posizione corretta. Integration with Microsoft Office, si ha la possibilità di integrare il lavoro con Microsoft Office, il che significa che quando si aggiornano i file e documenti dal Cosimo Armando 566/2063 Pagina 28 di 116

33 disco locale, possono essere automaticamente caricati online tramite delle repository dei documenti. JSR-286, è la specifica Java Portlet v2.0 sviluppato nell'ambito del JCP e svilup-pato per migliorare le carenze sulla versione 1.0 delle specifiche JSR Alcune delle sue caratteristiche principali includono: o Comunicazione attraverso eventi e possibilità di rendere i parametri pubblici; o o Servlet generate in modo dinamico direttamente tramite i portlet; Servizio AJAX o dati JSON direttamente attraverso i portlet. Detailed Documentation, Liferay fornisce un unico punto centrale nel quale è possibile integrare e gestire tutta la documentazione, formata da immagini e da informazioni dettagliate. Entrambe sono dotate di cartelle personalizzabili e condividibili da tutti gli utenti membri del team di lavoro. 4.3 IL MOCK-UP DEL PORTALE Il risultato del censimento è stata la creazione di una mappa dei collegamenti riguardanti l intera GRID (fig. 14). Nella mappa sono visualizzati i seguenti apparati: Il centro SCOPE; La rete Unina comprendente: CSI; Giga POP GAAR; Control Room; Chimica; Matenmatica. Il CEINGE ( Centro Eccellenza Biomedicina e Biotecnologia); La rete di Fisica e del centro INFN comprendente. ATLAS; campus GRID; centro stella. Cosimo Armando 566/2063 Pagina 29 di 116

34 Grisù comprendente: ENEA-CRESCO; Cybersar Sardegna; Cometa Sicilia. (fig. 4.1)Stato generale della rete Il capannone SCOPE visualizzato sulla mappa, così come tutti gli altri collegamenti dell'intera infrastruttura GRID, è dotato di un'icona che permette di entrare nello specifico degli apparati per così valutare e osservare tutte le caratteristiche, i guasti e i malfunzionamenti. Nel momento in cui si clicca su una qualsiasi delle icone, si accede alla schermata di secondo livello. Nel caso specifico del capannone SCOPE, ci viene fornito lo stato delle apparecchiature relative a tre tipologie di componenti che popolano il centro, cioè quelle relative agli apparati attivi, allo storage, ai server ed alle apparecchiature di impiantistica (fig.4.2). Cosimo Armando 566/2063 Pagina 30 di 116

35 (fig. 4.2) Interno del capannone SCOPE Le icone, in corrispondenza degli apparati monitorati, rappresentano lo stato del sistema e consentono, una volta cliccate, la visualizzazione in dettaglio dell'apparato di riferimento. La prima icona (da sinistra verso destra) è relativa agli switch e a tutte le apparecchiature attive (fig. 4.3), la seconda indica i Server (fig. 4.4) e la terza (fig. 4.5) punta al monitoraggio degli impianti ovvero all applicato creato, oggetto del mio contributo. Cosimo Armando 566/2063 Pagina 31 di 116

36 (fig. 4.3) Schermata di stato degli switch (fig. 4.4) Schermata relativa allo storage e ai server Cosimo Armando 566/2063 Pagina 32 di 116

37 (fig. 4.5) Schermata relativa agli impianti A titolo di esempio, di seguito, si riportano le immagini che mostrano il flusso logico di dettaglio implementato per monitorare i server presenti nel data center. Una volta raggiunto il componente monitorato con stato non ottimale, il sistema permette di collegarsi ad un sistema di gestione proprietario: Nel caso si tratti di server prospetterà l applicativo di gestione fornito da DELL, mentre per gli apparati di rete si aprirà una web shell per eseguire un collegamento diretto via telnet. Cosimo Armando 566/2063 Pagina 33 di 116

38 (fig. 4.6) Esempio: visualizzazione dei rack (fig. 4.7) Esempio: visualizzazione in dettaglio di un singolo rack Cosimo Armando 566/2063 Pagina 34 di 116

39 (fig. 4.8) Esempio: visualizzazione dello chassi 01 del rack selezionato in precedenza (fig. 4.9) Esempio: visualizzazione della schermata di configurazione della DELL Cosimo Armando 566/2063 Pagina 35 di 116

40 4.4 L ARCHITETTURA L'architettura sulla quale si basa la nostra Web Application è del tipo three-tires (fig 4.10), per cui abbiamo un Database, un Application Server ed un Web Server. L ambiente di collaudo, del sistema, poggia su un unico server fisico con sistema operativo Red Hat AS 5.0 in cui sono stati installati MySQL come RDBMS e Tomcat in qualità di AS. (fig. 4.10) Architettura di tipo three tires Tomcat rappresenta lo standard in un ambiente di sviluppo open source, anche se non è propriamente corretto definirlo Application Server. Parlando a livello insiemistico, potremmo definire un Web Server come un sottoinsieme di funzionalità di un Application Server. Il set di tecnologie fornito da un AS è molto ampio e lo scopo di tante tecnologie è quello di fornire allo sviluppatore una serie di servizi (middleware) che facilitino compiti tipici di una applicazione Enterprise, ossia un'applicazione che ha una serie di sorgenti informative che vanno al di là della semplice base di dati. Tomcat non è un servizio fully compliant con la specifica JEE, cioè con tutte le tecnologie di cui sopra. Quindi Tomcat non può essere considerato un Application Server: ciò non significa che non sia un servizio valido, anzi, la maggior parte dello sviluppo trae beneficio da un sistema "più leggero". È vero anche che Tomcat va al di là della semplice definizione di Web Server, in quanto ha alcune caratteristiche Enterprise che lo rendono un AS mancato. Elenchiamo alcune delle più comuni tecnologie Enterprise e vediamo quali sono presenti nell'implementazione di Tomcat: JNDI*; Cosimo Armando 566/2063 Pagina 36 di 116

41 JAAS; SOA*; JSP/servlet/JSF; JDBC; Cluster; Datasource*. Questo set di tecnologie consente, di fatto, di avere un ambiente di esecuzione abbastanza completo, tipico delle applicazioni Web pure, con una semplice sorgente dati re-lazionale (un DBMS) e la gestione dei pool di connessione attraverso l'uso di data source (anche se la loro funzionalità pecca abbastanza). A parte Tomcat, esistono altri Web server java come ad esempio GlassFish e JBoss che possono essere utilizzati ma, di sicuro, Tomcat è il più usato in assoluto e non è il caso di soffermarsi sui motivi della sua scelta. La soluzione three-tier utilizzata prevede: la realizzazione di un interfaccia utente grafica e gestita da un web server, un Application Server per la business logic ed infine, un database per la memorizzazione delle informazioni. 4.5 ANALISI E PROGETTAZIONE DEL SISTEMA DI MONITORAGGIO DEGLI IMPIANTI Come punto di partenza, per la creazione della parte relativa all'impiantistica del portale, ho studiato il RiwatchIT e ne ho sfruttato potenzialità e punti di forza. Dopo la prima installazione del prodotto, è stato necessario effettuare un opera di configurazione del sistema di monitoraggio, tramite l'altro software fornito da RITTAL, RigetIT. Questa operazione consiste nel configurare tutte le apparecchiature relative al centro di calcolo ed assegnare degli identificativi alle stesse, affinché possano essere riconosciute dal sistema. In particolare, ogni rack, lcp ed altro dispositivo appartenente all'impiantistica del data center, sarà provvisto di un nome e di un id univoco, in modo da poter essere distinto da tutti gli altri dispositivi. La mia attenzione si è rivolta in particolar modo al file XML, che lo stesso programma di monitoraggio produce e nel quale sono inseriti tutti gli eventi negativi che si Cosimo Armando 566/2063 Pagina 37 di 116

42 verificano nel data center. Attraverso l analisi sintattica del file XML, sono riuscito ad accertare il set minimo di informazioni atte ad identificare univocamente un messaggio: id univoco del messaggio; data e ora dell'evento; rack o lcp nel quale si e' verificato l'evento; sensore che ha causato l'invio dell'errore al sistema; tipologia di errore; stato del dispositivo (ok, alarm, warning,etc.). Tali informazioni sono indispensabili per determinare lo stato di un qualsiasi dispositivo. Per dare persistenza alle informazioni, ho scelto di inserire queste all'interno del database relazionale MySql 5.1. Dall'analisi fatta si è giunti alla creazione del seguente schema relazionale: (fig. 4.11) Diagramma ER del database di supporto Cosimo Armando 566/2063 Pagina 38 di 116

43 I dati relativi ai rack e agli lcp, sono contenuti all'interno di due tabelle, RACK ed LCP, collegate, tramite una relazione uno a molti, con altre due tabelle, SENSOR_RACK e SENSOR_LCP, che contengono gli identificativi univoci dei sensori ad essi connessi. Nella tabella EVENT sono memorizzate tutte le tipologie di eventi che si possono verificare all'interno del centro di calcolo. Questa è collegata ad altre due tabelle tramite una relazione uno a molti : STATUS, che contiene gli stati che il dispositivo può assumere ogni qual volta si verifica un determinato evento; SENSOR_CONFIGURATION che contiene gli identificativi dei sensori del data center. Le altre tabelle fungono da storico dei messaggi che si sono verificati durante l'attività del centro di calcolo. Come si può vedere dal diagramma ER del nostro database, non tutte le tabelle che lo popolano hanno delle relazioni con qualsiasi altra tabella. Ad esempio, le tabelle che si occupano dello storico e della memorizzazione dei messaggi (MESSAGE - MESSAGE_STORY - DATACENTER_STATE) non hanno bisogno di avere collegamenti con le altre tabelle, dato che vengono popolate durante il lavoro di parsing del file xml. Le altre tabelle, invece, sono popolate al momento della loro creazione, quindi quando viene creato per la prima volta il DB. Queste ultime memorizzano la configurazione attuale delle apparecchiature dell'impianto. Il dettaglio degli oggetti relativi alla base dati precedentemente descritta sono: MESSAGE Contiene tutte le informazioni necessarie per identificare la locazione, il sensore, e il tipo di variabile che sono chiamate in causa nell'identificazione di un evento. Questa tabella non funge da storico in quanto ad ogni cambio di configurazione vera' svuotata per dare spazio ai messaggi relativi alla nuova configurazione. L'id del messaggio e' quello assegnato in origine dal programma della RITTAL. DATACENTER_STATE Comprende gli eventi con stato negativo che Cosimo Armando 566/2063 Pagina 39 di 116

44 accadono all'interno del data center. Ad ogni evento positivo viene cancellato il corrispettivo presente all'interno di questa tabella RACK Racchiude gli id dei rack con i relativi nomi che gli sono stati assegnati quando il programma RITTAL e' stato configurato. Questa tabella non sarà soggetta a cambiamenti durante l'esecuzione dell'applicazione, ma potrà variare il proprio contenuto soltanto dopo un eventuale cambio di configurazione del programma RITTAL. SENSOR_RACK Include gli id dei sensori che si trovano all'interno dei rack del data center. La tabella ha una colonna id_sensor che e' la chiave primaria della tabella e che contiene gli id dei sensori, e una colonna id_rack che contiene gli id dei rack dei quali i sensori fanno parte. Anche questa tabella non varierà il proprio contenuto durante l'esecuzione dell'applicazione ma soltanto ad un eventuale cambiamento di configurazione. LCP Abbraccia gli id degli lcp con i relativi nomi che gli sono stati assegnati quando il programma RITTAL e' stato configurato. Questa tabella non sarà soggetta a cambiamenti durante l'esecuzione dell'applicazione, ma potrà variare il proprio contenuto soltanto dopo un eventuale cambio di configurazione del programma RITTAL. SENSOR_LCP È la tabella che contiene gli id dei sensori che si trovano all'interno degli lcp del data center. La chiave primaria è id_sensor che contiene gli id dei sensori, e una colonna id_rack che contiene gli id degli lcp dei quali i sensori fanno parte. Anche questa tabella non varierà il proprio contenuto durante l'esecuzione dell'applicazione ma soltanto ad un eventuale cambiamento di configurazione. STATUS Presenta tutti i possibili valori che le variabili possono assumere. La tabella e' formata da una colonna che identifica il tipo di variabile, una che contiene il valore numerico che questa può assumere, e una che contiene lo stesso valore sotto formato stringa. Questa tabella viene generata dopo la prima configurazione del programma dopo di che non verrà più modificata. Cosimo Armando 566/2063 Pagina 40 di 116

45 EVENT è la tabella che contiene tutte le possibili variabili che ci sono nella configurazione nel programma della RITTAL fornito insieme alle apparecchiature. Come la tabella precedente, questa viene creata al momento della prima configurazione dopo di che non viene più modificata. SENSOR_CONFIGURATION Contiene tutti gli id di tutte le variabili che vengono utilizzate per la gestione dei sensori all'interno del programma della RITTAL. Queste variabili possono variare in base alla configurazione del programma stesso, infatti ad ogni cambio di configurazione questa tabella viene rigenerata e vengono memorizzate le variabili della nuova configurazione. LAST_ID Viene utilizzata per memorizzare in maniera persistente l'id dell'ultimo messaggio che il programma ha letto. Questa tabella e' soggetta a continui insert e delete e viene definitivamente svuotata al cambio di configurazione. MESSAGE_STORY Memorizza tutto lo storico degli eventi che vengono generati all'interno del data center. Questa tabella e' molto simile alla tabella MESSAGE, infatti entrambe contengono lo storico degli eventi, con la differenza che MESSAGE_STORY contiene colonne di tipo stringa, quindi si ha una rappresentazione testuale del messaggio, mentre MESSAGE contiene solo valori numerici. Un'altra differenza sta nel fatto che mentre MESSAGE viene svuotata ad ogni cambio di configurazione, MESSAGE_STORY non viene mai svuotata. Questo perché l'id di MESSAGE_STORY non corrisponde all'id dei messaggi veri e propri, ma e' un id incrementale che viene generato automaticamente dal database; di conseguenza anche se i messaggi ripartono da zero ad ogni cambio di configurazione, la tabella non può soffrire di problemi riguardanti la duplicazione di chiavi primarie. LAST_UPDATE Utilizzata per memorizzare in maniera persistente la data di creazione dell'ultimo file di log generato dal programma della RITTAL RIwatchIT. Questa tabella viene controllata all'inizio di ogni ciclo di vita del programma e viene aggiornata soltanto nel caso in cui il file xml è cambiato e Cosimo Armando 566/2063 Pagina 41 di 116

46 quindi si è notato che la data di creazione risulta essere diversa da quella letta. Dal diagramma ER del database abbiamo ottenuto lo schema relazionale che ci permette di definire le relazioni che ci sono tra le tabelle. Il suddetto schema risulta essere il seguente: 1. MESSAGE ( id int, rack int, sensor int, var int, val int ); 2. DATACENTER_STATE ( id int, rack int, sensor int, var int, val int ); 3. RACK ( id int, name varchar(10) ); 4. SENSOR_RACK ( id_rack int, id_sens int, name varchar(20) ); 5. LCP ( id int, name varchar(10) ); 6. SENSOR_LCP ( id_lcp int, id_sens int, name varchar(20) ); 7. STATUS ( id int, int_value int, string_value varchar(15) ); 8. EVENT ( id int, name varchar(20) ); 9. SENSOR_CONFIGURATION ( id_var int, id int ); 10. LAST_ID ( id int ); 11. MESSAGE_STORY ( id int, rack varchar(30), sensor varchar(30), var varchar(30), val varchar(30) ); 12. LAST_UPDATE ( time varchar (30) ); Cosimo Armando 566/2063 Pagina 42 di 116

47 4.6 LA SCELTA DELLE METODOLOGIE Per avere il controllo ottimale delle apparecchiature del centro di calcolo, la nostra Web Application necessita di alcuni strumenti in grado di renderla affidabile e performante. Il caricamento dei dati all interno del DB avviene come conseguente lettura semantica del file XML. Affinché possa evolvere nel tempo, si è pensato di suddividerla in tre moduli: Il primo modulo è quello che si occupa della creazione del database e della sua popolazione e viene lanciato soltanto in fase di start up. Inizialmente vengono generate le tabelle, che vengono popolate soltanto dopo la lettura dei file di configurazione del RIwatchIT. Nel caso in cui la configurazione di base del RIwatchIT dovesse cambiare, è possibile rilanciare questo modulo più volte perché in fase di progettazione si è tenuto conto di questa eventualità. Il secondo modulo è quello che si occupa di eseguire la lettura semantica del file XML. Una volta aperto file XML remoto, il lavoro di questo modulo consiste nell'estrarre le informazioni presenti in esso e di inserirle all'interno delle tabelle della base dati. Il terzo ed ultimo passo consiste nell'inserimento di queste ultime, all'interno delle tabelle che sono state logicamente raggruppate come storico. Il secondo modulo, a differenza del primo, viene eseguito in background ed ivi rimane in esecuzione, andando con cadenza prefissata, a leggere il file e ad inserire le informazioni nella base dati. Il terzo modulo, invece, si occupa della visualizzazione delle informazioni prodotte dagli altri due ed è parte integrante del portale per il monitoraggio del data center. 4.7 TECNOLOGIE UTILIZZATE Ajax Ajax, acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo per la realizzazione di applicazioni web interattive. Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio di dati in background fra web browser e server, che consente l'aggiornamento dinamico di una pagina web senza esplicito ricaricamento da parte dell'utente. AJAX è asincrono nel Cosimo Armando 566/2063 Pagina 43 di 116

48 senso che i dati extra sono richiesti al server e caricati in background senza interferire con il comportamento della pagina esistente. Normalmente le funzioni richiamate sono scritte con il linguaggio JavaScript. Tuttavia, e a dispetto del nome, l'uso di JavaScript e di XML non è obbligatorio, come non è necessario che le richieste di caricamento debbano essere necessariamente asincrone. CSS I fogli di stile a cascata, meglio noti con l'acronimo CSS (dall'inglese Cascading Style Sheet) e detti anche semplicemente fogli di stile, vengono usati per definire la rappresentazione di documenti HTML, XHTML e XML. Le regole per comporre i fogli di stile sono contenute in un insieme di direttive (Recommendations) emanate a partire dal 1996 dal W3C. Attraverso l'uso dei fogli di stile è possibile quindi separare i contenuti dalla formattazione in fase di stesura del codice. MySql I Data Base Management System (DBMS) sono prodotti software in grado di gestire i database; le loro caratteristiche sono: capacità di gestire grandi quantità di dati condivisione dei dati fra più utenti e applicazioni utilizzo di sistemi di protezione e autorizzazione per l'accesso ai dati stessi Il modello relazionale si basa sulle relazioni fra i dati, i quali vengono presentati in forma tabulare, cioè come un insieme di tabelle ciascuna composta da righe e colonne. Insieme al modello relazionale è stato introdotto il linguaggio SQL (Structured Query Language), che consente di operare sui dati tramite frasi che contengono parole chiave prese dal linguaggio corrente. Naturalmente, visto l'ampio successo dei database relazionali, sono molti gli Cosimo Armando 566/2063 Pagina 44 di 116

49 RDBMS presenti sul mercato. MySql è un database relazionale (RDBM) composto da un client con interfaccia a caratteri ed un server, entrambi disponibili sia per sistemi Unix/Linux che per le piattaforme della Microsoft. La versione 5.0 di MySql, finalmente resa disponibile come stabile il 24 ottobre 2005, introduce nuove funzionalità che vanno a colmare le lacune precedentemente mostrate, e soprattutto mette MySql sullo stesso piano dei DBMS concorrenti. In sostanza, quello che già era il più diffuso database open source diventa un vero e proprio DBMS di livello enterprise. HTML L'HyperText Markup Language (HTML) (traduzione letterale: linguaggio di marcatura per ipertesti) è un linguaggio usato per descrivere la struttura dei documenti ipertestuali disponibili nel Word Wide Web ossia su internet. Tutti i siti web sono scritti in HTML, codice che viene letto ed elaborato dal browser, il quale genera la pagina che viene visualizzata sullo schermo del computer. L'HTML non è un linguaggio di programmazione, ma un linguaggio di markup, ossia descrive il contenuto, testuale e non, di una pagina web. JAVA Java è un linguaggio di programmazione orientato agli oggetti, creato da James Goslin e altri ingegneri di Sun Microsystem. La piattaforma di programmazione Java è fondata sul linguaggio stesso, sulla Macchina Virtuale (Java Virtual Machine o JVM) e sulle API Java. L'idea alla base della programmazione ad oggetti è di rappresentare, nella progettazione del software, le entità reali o astratte che compongono il problema sotto forma di oggetti. Questi ultimi sono caratterizzati da proprietà (definite variabili o campi di istanza o di esemplare) e da metodi applicabili sugli oggetti stessi, che possono ad esempio modificarne lo stato o estrarne informazioni. Cosimo Armando 566/2063 Pagina 45 di 116

50 JavaSript JavaScript è un linguaggio di scripting orientato agli oggetti, comunemente usato nei siti web. Fu originariamente sviluppato da della Netscape Comunication con il nome di Mocha e successivamente di LiveScript, ma in seguito è stato rinominato "JavaScript" ed è stato formalizzato con una sintassi più vicina a quella del linguaggio Java. JavaScript è stato standardizzato per la prima volta tra il 1997 e il 1999 dalla ECMA con il nome ECMAScript. Inoltre è anche uno standard ISO. 5 IMPLEMENTAZIONE MODULO I 5.1 FUNZIONAMENTO GENERALE Il primo modulo si occupa della creazione e della popolazione del database e della lettura dei file di configurazione. I file di configurazione sono file di testo che contengono tutte le informazioni utili per definire le relazioni che ci sono tra tutte le apparecchiature che popolano l'impianto del capannone SCOPE. Per prima cosa viene controllato se il database esiste già. Se non esiste, viene creato, insieme a tutti gli oggetti che lo compongono. Dopo questa parte relativa alla creazione ed alla popolazione del DB, viene quella relativa alla configurazione; infatti solo dopo la creazione delle tabelle, sarà possibile leggere i file di configurazione delle apparecchiature, per poi riempirle opportunamente con i suddetti dati. Il modulo è stato progettato per poter essere eseguito più volte proprio per far fronte alle continue evoluzioni del data center. In questo caso il modulo si comporta differentemente da quello precedente: il DB non verrà creato ed alcune tabelle Cosimo Armando 566/2063 Pagina 46 di 116

51 verranno opportunamente svuotate. Una volta effettuate queste operazioni si potrà passare alla lettura dei nuovi file di configurazione, e quindi al nuovo riempimento delle tabelle. 5.2 STRUTTURA DELL'APPLICATIVO I compiti da svolge sono quattro: registrazione dei driver mysql per effettuare le operazioni sul DB; estrazione dei parametri necessari per la connessione al DB da un file di testo; creazione del database; riempimento delle tabelle del DB. Per effettuare delle operazioni sul DB mysql, il modulo necessita di determinate librerie che dovranno essere inserite opportunamente nel progetto. Queste librerie permettono di poter utilizzare le classi contenenti i metodi, in grado di importare i driver necessari alla connessione. Per effettuare la connessione al DB, la sintassi Java prevede l'utilizzo di tre parametri: il database sul quale vogliamo effettuare la connessione, l'utente e la password. Questi valori sono stati opportunamente parametrizzati al fine di consentire future modifiche al database ed alla gestione dei relativi utenti. Questi parametri sono stati memorizzati all'interno di un file di testo in modo da semplificarne l'estrazione, la gestione e la modifica. Il compito di estrarre i dati, è stato affidato al metodo EstractUser: la prima operazione che effettua, e' la connessione al file di testo dal quale bisogna estrarre i parametri. Questa operazione viene effettuata creando un oggetto di tipo BufferedReader il cui compito è quello di leggere i parametri di accesso Cosimo Armando 566/2063 Pagina 47 di 116

52 al DB contenuti nel file. Il metodo EstractUser della classe main viene presentato qui di seguito: Una volta stabilita la connessione con la base dati, si passa alla creazione della nostra istanza come si può notare nel codice seguente: Cosimo Armando 566/2063 Pagina 48 di 116

53 Il comando SQL USE permette di utilizzare il database appena creato come schema di lavoro corrente, e di conseguenza, di non specificare il database nelle successive operazioni SQL. Di seguito si riporta il codice utilizzato per la creazione delle tabelle: LA CLASSE SQLTABLECREATE La classe SQLTableCreate è la classe che si occupa della creazione delle tabelle del DB e della popolazione di alcune di loro. Di seguito sono riportate le parti di codice JAVA per la loro creazione: Cosimo Armando 566/2063 Pagina 49 di 116

54 message_story rack lcp Cosimo Armando 566/2063 Pagina 50 di 116

55 sensor_lcp sensor_rack Cosimo Armando 566/2063 Pagina 51 di 116

56 event La tabella EVENT è la tabella che si occupa di contenere tutti i possibili tipi di eventi che si possono verificare all'interno del data center. Questa tabella, a differenza delle altre viste fino ad ora, non viene riempita dai file di configurazione ma viene riempita manualmente tramite delle INSERT. Questo perché gli eventi che si possono verificare nel capannone non dipendono assolutamente dalla configurazione. Cosimo Armando 566/2063 Pagina 52 di 116

57 status La tabella STATUS racchiude in se tutti i possibili stati che un'apparecchiatura appartenente all'impiantistica del centro di calcolo può avere. Ci sono gli stati relativi ai sensori dei rack, degli lcp, delle scarpette intelligenti psm, e di tutto ciò che viene monitorato. Come la tabella precedente, questa viene popolata manualmente tramite delle INSERT, dato che non ha bisogno di essere ne cancellata ne svuotata ad ogni cambio di configurazione. Cosimo Armando 566/2063 Pagina 53 di 116

58 sensor_configuration message e datacenter_state Cosimo Armando 566/2063 Pagina 54 di 116

59 last_update e last_id Cosimo Armando 566/2063 Pagina 55 di 116

60 5.2.3 LA CLASSE SELECTRACKSENSOR Il file di configurazione dei rack, degli lcp e dei loro sensori, è formato da un insieme di righe, ognuna delle quali rappresenta un diverso dispositivo che popola il data center SCOPE. Ogni riga può essere divisa in colonne, ognuna delle quali rappresenta un'informazione diversa dello stesso dispositivo. Le prime due colonne del file rappresentano i rack e gli lcp, le rimanenti si riferiscono ai loro sensori. (fig. 5.1) File di configurazione dei rack e degli lcp Cosimo Armando 566/2063 Pagina 56 di 116

61 (fig. 5.2) File di configurazione delle variabili di stato Il metodo per prima cosa richiede l'inserimento del path dal quale andare a leggere il file di configurazione ed il risultato viene inserito all'interno di un oggetto di tipo BufferedReader. Siccome il file è formato da tante righe, per lavorarle nel modo corretto senza il rischio di incorrere in errori di scorrimento, si è pensato di inserirlo all'interno di un oggetto di tipo Vector, in modo tale da avere una gestione posizionale delle informazioni Cosimo Armando 566/2063 Pagina 57 di 116

62 acquisite. La prima informazione che ci si ricava, è l'identificativo numerico del dispositivo che viene inserito in una variabile tramite un'opportuna operazione di cast. Il codice per l'identificativo è il seguente: La seconda informazione da ricavare è il nome del dispositivo, operazione eseguita considerando il fatto che una colonna è divisa da un'altra da un TAB ( /t ). Di seguito il codice: Una volta ottenuti l'identificativo e il nome del dispositivo, bisogna ricavare dalla riga soltanto l'ultima informazione, la locazione. Come detto in precedenza, la locazione è un'informazione che riguarda soltanto i sensori, quindi verrà ricavata soltanto in determinanti casi particolari. L'informazione che a noi serve non è sequenziale alle altre due, di conseguenza c'è Cosimo Armando 566/2063 Pagina 58 di 116

63 bisogno di qualcosa che a partire dalla riga, ci porti alla locazione del dispositivo. Questo è il compito del metodo contaparole che ci restituisce la colonna che a noi serve a partire dall'intera riga data in ingresso. Il codice del metodo è il seguente: Restituita l'informazione, possiamo finalmente inserire tutti e tre i dati all'interno delle apposite tabelle. Cosimo Armando 566/2063 Pagina 59 di 116

64 Il metodo in figura, controlla il tipo di dispositivo, rack o lcp, in base alla variabile rack che contiene il nome. In base al risultato del controllo vengono inserite le informazioni in una tabella anziché un'altra. Il controllo viene fatto tramite la chiamata al metodo SearchTable, che controlla la locazione del dispositivo. Una volta inseriti tutti i rack, tutti gli lcp e tutti i dispositivi a loro abbinati, il compito di questa classe termina, e il controllo passa alla classe che gestisce l'altro file di configurazione, quello relativo alle variabili di stato di tutti i dispositivi appartenenti al data center. Cosimo Armando 566/2063 Pagina 60 di 116

65 5.2.4 LA CLASSE SELECTVARIABLE Anche in questo caso le righe del file vengono messe all'interno di un oggetto di tipo Vector, in modo da poterne identificare i giusti valori. Le informazioni da estrarre da questo file sono due: l'identificativo numerico ed il tipo. La prima è semplice da estrapolare visto che è la prima colonna della riga. Il codice per estrarlo è il seguente: Una volta che è stata estratta l'informazione, viene inserita in una variabile dopo aver effettuato anche qui, un opportuna operazione di cast. La seconda informazione invece si trova alla sesta colonna della riga. Per cui utilizzeremo la funzione contaparole, descritta precedentemente. A questo punto, ottenute le due informazioni, siamo in grado di effettuare l'inserimento all'interno della tabella SENSOR_CONFIGURATION tramite la chiamata al metodo InsertVariable. Il codice della chiamata al metodo è il seguente: Cosimo Armando 566/2063 Pagina 61 di 116

66 Come possiamo notare, prima dell'inserimento all'interno della tabella, bisogna fare una ricerca all'interno della tabella STATE, per cercare l'id del tipo di variabile che stiamo inserendo. Questa ricerca viene effettuata all'interno di un altro metodo, getvariableid, che ha il seguente codice: Una volta terminato l'inserimento nella tabella di tutte le variabili estratte da questo file, termina anche il compito di questa applicazione, che ci ha permesso di memorizzare tutta la configurazione del data center. Cosimo Armando 566/2063 Pagina 62 di 116

67 5.3 ESEMPI DI OUTPUT Come abbiamo detto in precedenza, questo modulo può essere eseguito in due momenti differenti: nel caso in cui si voglia creare per la prima volta il database, e nel caso in cui sia stata cambiata la configurazione del data center e si voglia cambiare i valori di configurazione all'interno delle tabelle. Per ognuna delle due tipologie di esecuzione, di seguito mostriamo un esempio di output, e di tutto ciò che l'utente può notare durante il run dell'applicazione PRIMO CASO D USO: PRIMA ESECUZIONE (fig. 5.3) Notifica di corretta creazione del DB Un messaggio ci avvisa della corretta creazione del DB e dei relativi oggtti. Il sistema è in attesa del path da cui leggere i file di configurazione. Una volta inserito il path e permuto invio, l'utente vedrà apparire in output le seguenti schermate: (fig. 5.4) Inserimento degli id dei rack nelle tabelle Cosimo Armando 566/2063 Pagina 63 di 116

68 (fig. 5.5) Inserimento dei sensori all'interno delle tabelle La fig. 5.4 e la fig. 5.5 mostrano due visualizzazioni diverse perché il file di configurazione inserito non contiene soltanto i dati relativi ai rack, ma contiene anche quelli relativi ai loro rispettivi sensori. Di conseguenza la prima schermata riporta che i rack e gli lcp sono stati letti ed inseriti nelle rispettive tabelle, nella seconda dichiara che la stessa operazione è stata effettuata per sensori. Una volta restituiti i comandi all'utente, bisognerà ripetere l'operazione di inserimento del path per il file relativo alla configurazione delle variabili di stato delle apparecchiature del data center. (fig. 5.6) Inserimento delle variabili di stato all'interno del DB Una volta terminata questa operazione, termina anche il nostro applicativo, che con un messaggio di successo ci avvisa che tutto è andato a buon termine. Alla fine di questa fase avremo il database creato e popolato di tutti i dati relativi alla configurazioni delle apparecchiature del data center. Cosimo Armando 566/2063 Pagina 64 di 116

69 5.3.2 SECONDO CASO D USO: RICONFIGURAZIONE DEL DATA CENTER (fig. 5.7) Riconfigurazione delle tabelle del DB Dall'immagine precedente si può notare che, al momento della creazione delle tabelle ci viene segnalato che il DB, così come le tabelle, già esistono, di conseguenza non verranno ricreate ma verranno solamente svuotate per far posto ai nuovi dati che verranno estrapolati dai nuovi file di configurazione. Così come nel caso precedente, alla fine della gestione delle tabelle viene mostrato un messaggio che ci invita ad inserire il path del file da cui prendere la configurazione dei rack e dei loro rispettivi sensori. Cosimo Armando 566/2063 Pagina 65 di 116

70 6 IMPLEMENTAZIONE MODULO II 6.1 FUNZIONAMENTO GENERALE Il secondo modulo, è quello che si occupa di eseguire il parsing del file xml e contestualmente di inserire le informazioni acquisite nel Mysql. Il sistema RiwatchIT della RITTAL utilizza il file xml come supporto di memorizzazione di tutti gli eventi che si verificano all'interno del data center; ogni qual volta un dispositivo della sala di calcolo dovesse avere un qualsiasi tipo di problema, questo viene segnalato e memorizzato all'interno di questo file. Tra le informazioni presenti nel file xml, quelle di interesse sono: data di creazione del file, data di generazione del messaggio di errore, l'id del messaggio, la sua locazione, il tipo di errore ed infine, lo stato in cui si presenta l'apparecchiatura una volta che si è verificato l'errore. (fg. 6.1) Struttura ad albero del file xml Cosimo Armando 566/2063 Pagina 66 di 116

71 Nell immagine precedente possiamo osservare la struttura ad albero del file xml che sono riuscito a disegnare dopo un attenta lettura del file stesso. In figura sono mostrati tutti i tag che lo caratterizzano con i rispettivi attributi. Il nodo radice del file è il tag messagelist, che ha come tag figlio il tag message che contiene in se tutte le informazioni che a noi interessano. Questo tag, a sua volta, ha altri tre sotto tag: variablelist, properties e commentlist, che contengono rispettivamente le variabili di configurazione utilizzate nella valutazione del segnale di errore, le proprietà relative al tipo di errore che si è verificato nell'apparecchiatura ed eventuali commenti inseriti dall'applicazione o dall'utilizzatore del sistema. Di seguito viene riportato una parte del file xml contenente tutti gli eventi che si verificano all interno del data center. (fig. 6.2) Contenuto del file XML Come possiamo notare oltre alle informazioni che abbiamo elencato prima, ci sono tantissime altre informazioni relative al messaggio, come ad esempio tutti i dati relativi Cosimo Armando 566/2063 Pagina 67 di 116

72 agli operatori da contattare. Vediamo ora il suo funzionamento nel dettaglio: per prima cosa controlla la data di creazione del file xml con quella memorizzata nel DB: Nel caso in cui le due date corrispondono, significa che il file non è nuovo, quindi il puntatore di lettura non dovrà partire dall inizio dello stesso. Nel caso in cui, invece, le date non corrispondono, il file xml sarà letto tutto, invocando il metodo che estrapolerà tutto il file xml, per poi renderlo disponibile alla successiva operazione di parsing. Lo stesso procedimento viene effettuato per il controllo dell'ultimo id letto nel file. Infatti se si dovesse verificare il primo caso, cioè il caso in cui le due date coincidono, allora si passerebbe alla verifica dell'ultimo id letto. Anche qui si potranno verificare due casi: Se la tabella che dovrebbe contenere l'id dell'ultimo messaggio letto è piena allora significa che il file non deve essere letto tutto perché lo stesso file è già stato letto in precedenza. Se la tabella che deve contenere l'id invece è vuota allora significa che il file XML è nuovo e quindi dovrà essere letto per intero. Una volta estratto il file, viene chiamato il metodo che ne verifica la validità; se il file risulta essere valido si potrà proseguire con la sua elaborazione, altrimenti sarà chiamato un altro metodo per renderlo valido e leggibile dal parser. L'operazione di parsing consiste nel leggere, messaggio dopo messaggio, le informazioni di interesse. Il secondo modulo, dunque, ci permette di riempire le altre tabelle che ne modulo precedente erano state soltanto create. 6.2 SCELTA DEL PARSER Il parsing di documenti xml in Java, passa principalmente attraverso due famiglie di API: DOM e SAX. L'approccio utilizzato da SAX è quello di generare degli eventi nel momento in cui il reader incontra i tag del documento xml. Per intercettare questi Cosimo Armando 566/2063 Pagina 68 di 116

73 eventi la nostra classe parser deve implementare alcune interfacce come ContentHandler, DTDHandler, ErrorHandler (anche se non tutte necessariamente). Per ognuna di esse bisognerà implementare i metodi all'interno dei quali gestire gli eventi scatenati dal parser. Questi eventi possono essere vari come ad esempio la lettura di un tag o la lettura di un determinato suo attributo. L'approccio di DOM è totalmente diverso. Infatti, in questo caso, tutto l'albero del documento viene caricato in memoria e su di esso potrà essere scelto un algoritmo di esplorazione. In questa struttura ogni elemento del documento xml diventa un nodo dell'albero rappresentato da una classe che implementa l'interfaccia org.w3c.dom.node. Questa interfaccia fornisce metodi per esplorare o modificare l'albero e per conoscere le proprietà di ogni nodo. Ambedue le implementazioni presentano, ovviamente, vantaggi e svantaggi che dipendono dalla situazione che dovrà essere fronteggiata. Nel caso di file di dimensioni importanti (per esempio nel caso di export di database) bisogna considerare che DOM carica TUTTO il documento in memoria e lo trasforma in una struttura ad albero quindi, in questo caso, bisogna necessariamente fare i conti con le risorse del nostro sistema: pensare di caricare un intero database in memoria non è una grande idea. Quindi, in questo caso, forse è meglio rivolgere la nostra attenzione verso SAX. Di contro, questo non permette un controllo agevole sulla struttura del documento e, cosa importante, non consente la modifica diretta del nostro file xml. Viceversa DOM, oltre a permettere la lettura e la navigazione del documento, ne permette anche la modifica. Se volessimo modificare un file xml con SAX dovremmo creare un altro file ed effettuare i cambiamenti che ci interessano man mano che il primo documento viene letto (ossia man mano che vengono intercettati gli eventi). Riassumendo possiamo dire che sarà ragionevole utilizzare DOM in tutti quei casi in cui sarà indispensabile elaborare il file prima di inserirlo nel DB. Nel caso in cui, invece, non si rende necessaria un elaborazione in RAM del file, allora SAX risulterà essere la scelta più performante. Sulla base delle considerazioni fatte si è scelto di utilizzare SAX. Cosimo Armando 566/2063 Pagina 69 di 116

74 6.3 STRUTTURA DELL'APPLICATIVO SAX L'acronimo SAX sta per la Simple API for XML; non ha un modello ad oggetti di default e di conseguenza è tenuto soltanto a leggere e di generare degli eventi in base ai tag presenti nel documento. Gli eventi sono generati quando: si incontrano dei tag di apertura; si incontrano dei tag di chiusura; per la presenza di sessioni PCDATA o CDATA; in corrispondenza di istruzioni di elaborazione, commenti e dichiarazioni di entità. E importante ricordare che la sequenza in cui gli eventi vengono generati determina come si dovrà interpretare ogni evento. Le operazioni eseguite da SAX possono essere racchiuse in tre diversi momenti di seguito identificati: l'applicazione che richiede l'analisi del documento; il parser che analizza il documento e genera gli eventi; il gestore che opera in risposta agli eventi generati dal parser; La prima cosa da fare per utilizzare SAX è istanziare un oggetto della classe SAXParserFactory. Per fare ciò non è necessario indicare il tipo di implementazione da effettuare, pertanto il codice risulta portabile su qualsiasi piattaforma con diverse implementazioni del parser. A questo punto è necessario definire una classe che implementi l interfaccia Cosimo Armando 566/2063 Pagina 70 di 116

75 ContentHandler dal package org.xml.sax. Questa interfaccia espone un metodo per ciascun evento che può essere generato dal parser nel corso dell analisi del documento: void startdocument()/void enddocument(), sono i metodi che catturano gli eventi di inizio e fine del documento. Nella nostra applicazione sono irrilevanti, di conseguenza non sono stati implementati. void characters(char[] ch, int start, int length), sezione #PCDATA, il testo contenuto sotto forma di array di caratteri. Nella nostra applicazione viene utilizzato per catturare alcuni elementi importanti del messaggio. void startelement(string namespaceuri, String localname, String qname, Attributes atts), inizio di un elemento di nome localname appartenente al namespace namespaceuri con attributi atts. Nella nostro caso viene utilizzato per determinare il tipo di tag in cui ci troviamo in un determinato momento del parsing. void endelement(), Fine di un elemento (anche se EMPTY). Non viene implementato, in quanto sapere quando termina un elemento risulta essere irrilevante. La classe che si occupa di implementare l'interfaccia è la classe DefaultHandler, e lo fa tramite metodi vuoti (no-action). Pertanto per implementare un gestore del contenuto del documento si deriva una classe da DefaultHandler e si ridefiniscono i soli metodi richiesti LA CLASSE DEFAULTHANDLER Estendendo la classe DefaultHandler, andremo a sovrascrivere due metodi, characters ed il metodo startelement. I compiti che la classe è tenuta a svolgere sono: la connessione al DB, la lettura, Cosimo Armando 566/2063 Pagina 71 di 116

76 l estrazione e la verifica del file XML più il suo eventuale completamento. Il codice per l'estrazione del path viene mostrato qui di seguito: Il metodo aprire il file specificato dal path in ingresso, ed inizia a leggerlo. A questo punto, viene eseguita l'estrazione dell'ultima data di creazione dello stesso, per poi confrontarla con quella che si trova memorizzata all'interno del DB. Cosimo Armando 566/2063 Pagina 72 di 116

77 Il metodo effettua l apertura del file XML e ne estrae le prime due righe. Tramite due cicli non innestati possiamo estrarre così la stringa che ci serve, in modo da poterla ritornare al programma chiamante. Dopo il controllo della data di creazione i due dati estratti possono essere uguali oppure no: nel primo caso ci troviamo in presenza di un nuovo file per cui dovrà essere completamente caricato nel DB; ne secondo caso, invece, il file xml è uguale a quello che abbiamo letto precedentemente e del quale abbiamo memorizzato la sua data di creazione all'interno del DB. Di conseguenza bisognerà effettuare il controllo sull'ultimo id del messaggio letto in precedenza. Cosimo Armando 566/2063 Pagina 73 di 116

78 Se il risultato della query non produce nessun risultato (ultimo_id uguale a 0) significa che è la prima volta che viene letto, di conseguenza utilizzando il metodo GeneraFile della classe EstractXML, si passerà all'estrazione dell'intero file xml; Nel caso in cui il risultato fosse stato positivo avremo avuto l'id dell'ultimo messaggio letto. A questo punto il metodo Estract della stessa classe estrarrà soltanto la parte del file non letta. Cosimo Armando 566/2063 Pagina 74 di 116

79 Cosimo Armando 566/2063 Pagina 75 di 116

80 Come si può notare dal codice riportato, il primo ciclo do-while serve al metodo per spostarsi all'interno del file nel punto in cui si trova l'id dell'ultimo messaggio letto, che sarà di partenza per la parte del file copiato in locale. A questo punto eseguiamo il controllo di validità del file XML. Questa operazione, in alcuni casi, potrebbe riscontrare delle anomalie nella struttura del XML, che renderebbero il file mal formato. Per prima cosa istanziamo un oggetto di tipo XMLReader per chiamare il metodo parse, quale restituirà true nel caso in cui il file risulti essere corretto. Cosimo Armando 566/2063 Pagina 76 di 116

81 Nel caso di false come si vede dalle due righe di codice precedente, si entrerebbe all'interno del costrutti if, con la chiamata al metodo CompleteXML, creato per rendere valido il file xml. Cosimo Armando 566/2063 Pagina 77 di 116

82 Il metodo che completa il file xml lavora in modo da memorizzare tutto il contenuto dello stesso all'interno di un oggetto di tipo Vector, in cui ogni elemento del vettore corrisponde ad una riga del file. Una volta effettuata questa operazione sovrascriveremo il file con le nuove righe, che a differenza delle vecchie, lo renderanno leggibile da parte del parser SAX. Le prime due righe vengono inserite a mano in quanto sono standard e uguali per tutti i file xml. Per il resto delle righe invece, viene iniziato un ciclo while in cui vengono memorizzare all'interno di una stringa temporanea tutte le righe che appartengono ad un singolo messaggio. Il ciclo termina se sono finiti gli elementi all'interno della struttura Vector oppure quando stiamo inserendo all'interno della stringa di supporto, la riga contenente il tag di chiusura del messaggio (</message>). Soltanto nel secondo caso la stringa viene copiata nel file. Come ultima operazione si inserisce la chiusura del tag radice (</messagelist>) che identifica la chiusura del file. Con questo procedimento siamo sicuri che inseriremo all'interno del file soltanto messaggi completi, evitando così la possibilità di avere un formato non valido. Una volta validato il file, verranno chiamati i metodi characters e startelement, necessari ad identificare gli eventi che si verificano all'interno del data center I METODI CHARACTERS E STARTELEMENT Il metodo characters viene utilizzato ogni qualvolta si incontrano dei dati di tipo CDATA, mentre startelement viene invocato quando si incontra un tag di apertura. Il primo è utilizzato per vedere e controllare in quale parte del file xml ci si trova, l'altro per estrarre dati utili da memorizzare all'interno del DB. Entrambi i metodi sono stati modificati in base alle nostre esigenze. Cosimo Armando 566/2063 Pagina 78 di 116

83 Quando il metodo viene chiamato dal parser SAX, ad esso vengono passati anche tre argomenti che sono: namespaceuri, URI dell'elemento localname, il local name dell'elemento qname, il nome completo dell'elemento atts, gli attributi del tag Cosimo Armando 566/2063 Pagina 79 di 116

84 Il parametro che a noi interessa per conoscere il nome del tag attuale, è il terzo, ovvero qname. Di conseguenza il nostro metodo eseguirà una sequenza di if in cascata, che in base al tipo di tag processato, effettuerà determinate operazioni anziché altre: messagelist: vengono estratti due paramenti: creationtime e updatetime. Una volta estratti dal file i due valori vengono visualizzati a video come informazione di esecuzione all'utente. message: viene estratto il valore dell'attributo id e viene inserito all'interno di una variabile globale pronto per essere inserito all'interno delle tabelle del DB insieme alle altre informazioni che verranno prese di seguito. Inoltre viene mandato a video un messaggio che informa l'utente del messaggio che si sta trattando in quel momento. variable: viene estratto l'attributo id e viene memorizzato anch'esso all'interno di una variabile globale, pronto per una insert nel DB. Oltre all'estrazione di questo attributo, viene impostata una variabile globale booleana a true, utilizzata poi all'interno del metodo characters. property: viene impostata soltanto una variabile globale booleana a true per l'utilizzo all'interno del metodo characters. Il settaggio a true viene effettuato soltanto se il tag ha come attributi name e creationtime. Cosimo Armando 566/2063 Pagina 80 di 116

85 Cosimo Armando 566/2063 Pagina 81 di 116

86 A differenza del metodo precedente, il metodo characters riceve in ingresso soltanto tre parametri, e come abbiamo detto, ha il compito di estrarre dal file xml soltanto i i dati in formato testo. I parametri sono: ch[], array contenente i caratteri del paragrafo start, indice di inizio del paragrafo len, lunghezza del paragrafo In base al tipo di tag processato, il metodo eseguirà alcune operazioni invece che altre: variable: il tag variable è presente, all'interno di un singolo messaggio per ben sei volte. Siccome l'unico tag che a noi interessa è il sesto, è stata dichiarata e inizializzata una variabile contatore che tiene il conto dei tag che abbiamo già letto, in modo da estrarre soltanto il contenuto di interesse. Una volta estratto il dato, questo viene inserito all'interno di una variabile di appoggio, pronto per essere inserito all'interno del DB, tramite un operazione di INSERT. Quando il contatore dei tag supera il valore massimo, viene azzerato e preparato per la Cosimo Armando 566/2063 Pagina 82 di 116

87 lettura di un nuovo messaggio. property: la prima operazione che si effettua è l'inserimento del suo contenuto all'interno di una oggetto stringa opportunamente istanziato. Questa operazione viene effettuata per fare in modo da poter eseguire comandi stringa sul testo. Il formato dell informazione è il seguente: ID DATACENTER, ID RACK, ID SENSORE Di queste soltanto le ultime due saranno trattate. A tal proposito sono stati implementati dei cicli while per l'estrazione degli stessi. Il primo ciclo salta l'informazione relativa al data center, e porta l'indice puntatore della stringa sull'informazione relativa al rack. Questa viene opportunamente salvata in una variabile, pronta ad essere inserita all'interno del DB. Il secondo, invece, porta l'indice sull'informazione relativa al sensore. I successivi tre metodi identificano la logica necessaria per popolare la tabella message e message_story. Cosimo Armando 566/2063 Pagina 83 di 116

88 La prima chiamata, quella effettuata al metodo QueryMessage della classe StartQuery, si occupa di inserire i dati estratti dall'xml all'interno della tabella message del database, tabella che contiene gli eventi che si sono verificati all'interno del data center. La seconda chiamata, quella effettuata al metodo InOutDCS della classe DCSGestion, si occupa di controllare la natura dell'errore che si è verificato all'interno del data center. Per prima cosa viene chiamato il metodo che si occupa di cancellare qualsiasi tipo di messaggio che si trovi all'interno della tabella datacenter_state. Cosimo Armando 566/2063 Pagina 84 di 116

89 In seguito si controlla che il messaggio sia di tipo negativo, ad esempio un alarm oppure un warning. A questo punto viene chiamato il metodo QueryDCSInsert, che inserisce i dati estratti dall'xml all'interno della tabella datacenter_state. L'ultima chiamata è quella che viene effettuata al metodo InsertIntoStory della classe StoryGestion. Questa chiamata serve per inserire all'interno della tabella message_story, il messaggio sotto forma di carattere, e quindi leggibile all'utente in fase di visualizzazione. Per ottenere tutte le informazioni necessarie all'inserimento, il Cosimo Armando 566/2063 Pagina 85 di 116

90 metodo effettua una serie di QUERY in grado di estrarre dalle tabelle del DB, i valori in formato carattere uguali a quelli che sono stati estratti durante il parsing del file xml. Cosimo Armando 566/2063 Pagina 86 di 116

91 6.4 LA GESTIONE DELLE ECCEZIONI Affinché il processo di approvvigionamento degli eventi (modulo II) sia sempre in grado di leggere il file XML è stata progettata una gestione degli errori sulla base di una attenta analisi del flusso dati. Di seguito vengono riportati quelli di maggior interesse: Sia l applicativo che il RiwatchIT tentano di accedere contemporaneamente al file XML; il primo in modalità di lettura ed il secondo in scrittura. In questo caso viene generata un'eccezione anticipando il termine del ciclo di lettura del file, di conseguenza viene ridotto il tempo di accesso al file perché in questa circostanza il nostro sistema non riesce a leggerlo. Cosimo Armando 566/2063 Pagina 87 di 116

92 Il modulo II sta leggendo il file XML mentre il RiwatchIT tenta di accedere in modalità scrittura. Il software della RITTAL ha sempre la precedenza nell acquisizione della risorsa per cui, la nostra applicazione non avrà più il tempo di terminare il suo compito. Il risultato sarà un file xml incompleto, quindi non valido e inadeguato ad una eventuale operazione di parsing. Per tanto sono stati creati dei metodi per la validazione e il completamento del file stesso. In questo caso viene gestita la possibilità di errore scaturita dall analisi sintattica del file stesso. Infatti è possibile che, durante l operazione di parsing, vengano lette male informazioni indispensabili per un corretto riconoscimento del messaggio. Se ciò dovesse accadere, il ciclo di lettura verrebbe immediatamente terminato ed il tempo di attesa ridotto a 5 secondi, riprendendo la stessa dall ultimo messaggio letto con successo. Cosimo Armando 566/2063 Pagina 88 di 116

93 7 IMPLEMENTAZIONE MODULO III Lo scopo da raggiungere, è quello di realizzare un interfaccia grafica semplice ed intuitiva per il sistema di monitoraggio dell impiantistica all interno del capannone SCOPE. L interfaccia creata espone le seguenti funzionalità: Effettuare un log-in sicuro ed affidabile; Controllare lo stato di tutte le apparecchiature del data center; Verificare la temperatura e l umidità di tutti i rack; Esaminare l amperaggio delle componenti appartenenti all impianto di alimentazione; Analizzare il funzionamento dell impianto di raffreddamento e di tutte le ventole ce lo compongono; Monitorare gli ultimi eventi che si sono verificati all interno del data center. 7.1 FUNZIONAMENTO GENERALE Come abbiamo detto precedentemente, la nostra web application, è dotata di una barra di navigazione che ci permette di venire a conoscenza, in maniera più dettagliata, di tutto ciò che sta accadendo all'interno del data center scope. Le funzionalità che vengono offerte sono quattro: Lettura degli ultimi 10 eventi che si sono verificati all'interno della sala; Visione dei grafici relativi alla temperatura degli lcp della sala; Visione dei grafici relativi alla temperatura dei rack della sala; Visione dei grafici relativi all'umidità dei rack della sala. Cosimo Armando 566/2063 Pagina 89 di 116

94 (fig. 7.1) Presentazione della tabella dello storico messaggi Come si può vedere dall'immagine precedente, se si clicca sul pulsante della barra di navigazione dove c'è scritto Storico Messaggi, nella parte bassa della schermata verrà visualizzata una tabella contenente gli ultimi 10 eventi che si sono verificati all'interno del data center. Insieme alla tabella, viene visualizzato un bottone (che nella figura è cerchiato in rosso) tramite il quale è possibile annullare l'operazione, e quindi cancellare la tabella con tutte le informazioni sui messaggi. Nella figura successiva possiamo osservare in dettaglio la tabella: (fig. 7.2) Tabella degli eventi verificatisi nel data center Per quanto riguarda la barra di navigazione appartenente alla schermata iniziale dell'applicazione, come già abbiamo detto in precedenza, ci sono altri quattro pulsanti, Cosimo Armando 566/2063 Pagina 90 di 116

95 uno per l'aggiornamento della pagina, un altro per tornare alla pagina precedentemente visualizzata, e gli altri due per la navigazione all'interno dell'intero portale, e la possibilità di osservare lo stato delle apparecchiature riguardanti i server, lo storage e tutte le apparecchiature attive del data center. Se si scende in profondità, e si naviga nelle pagine che mostrano in dettaglio lo stato delle apparecchiature relative ad un singolo rack o lcp, possiamo notare che la barra di navigazione cambia, e si aggiungono ad essa, alcune funzionalità che nella schermata precedente non avevamo la possibilità di utilizzare. Queste funzionalità sono la visualizzazione di grafici relativi alla temperatura e all'umidità relativa a tutti i rack e gli lcp che popolano la sala. (fig. 7.3) Visualizzazione del grafico della temperatura di lcp Come si può notare dall'immagine, all'interno della pagina relativa ad un lcp, tramite la pressione del pulsante Grafico Temperatura, viene visualizzata una finestra di pop up contenente un grafico che ci permette di studiare l'andamento delle temperature alle quali l'lcp in questione è stato sottoposto nelle ultime rilevazioni. Lo stesso procedimento può essere fatto per quanto riguarda la visualizzazione dei Cosimo Armando 566/2063 Pagina 91 di 116

96 grafici relativi alla temperatura e all'umidità dei rack.nelle figure successive verranno mostrate entrambe le visualizzazioni: (fig. 7.4) Visualizzazione del grafico della temperatura del rack (fig. 7.5) Presentazione del grafico dell'umidità del rack Cosimo Armando 566/2063 Pagina 92 di 116

97 Oltre alla barra di navigazione, l'applicazione offre altre funzionalità che permettono all'utente che si collega al portale, di conoscere a fondo lo stato delle apparecchiature del data center scope. (fig. 7.6) Visualizzazione delle informazione sui sensori del rack Se ad esempio ci troviamo all'interno della pagina relativa ad un rack, cliccando sulle immagini relative agli stati delle apparecchiature, possiamo notare apparire delle informazioni relative al sensore o al dispositivo al quale l'icona faceva riferimento. Cosimo Armando 566/2063 Pagina 93 di 116

98 (fig. 7.7) Visualizzazione delle informazioni sui sensori degli lcp Le informazioni che possiamo ottenere se ci troviamo nella pagina relativa ad un rack (vedi immagine precedente) sono le seguenti: valore dell'amperaggio delle scarpette intelligenti PSM; valori relativi alla temperatura; valori relativi all'umidità; valore relativo alla presenza di fumo nel rack; sensore di accesso al rack. Una volta visualizzata l'informazione, è possibile eliminare quest'ultima tramite un'apposita icona che viene visualizzata insieme ad essa. La stessa funzionalità è sfruttabile all'interno degli lcp. Le informazioni che possiamo ottenere nella pagina relativa ad essi (vedi immagine precedente) sono le seguenti. temperatura dell'acqua in ingresso all'lcp; temperatura dell'acqua in uscita all'lcp; Cosimo Armando 566/2063 Pagina 94 di 116

99 numero di giri delle ventole modulo 1; numero di giri delle ventole modulo 2; numero di giri delle ventole modulo STRUTTURA DELL ALBERO DI NAVIGAZIONE Quando ci si trova davanti alla costruzione dell interfaccia di un sito web talvolta ci si trova dinanzi ad un difficile ostacolo: La progettazione dei sistemi di navigazione, rappresenta una fase contraddistinta da mille dubbi, proposte ed idee ma soprattutto da tante domande. La figura precedente rappresenta l albero di navigazione della Web Application. Con delle ellissi di colore blu sono state identificate le pagine in formato Cosimo Armando 566/2063 Pagina 95 di 116

100 HTML. Con quelle verde, invece, sono state identificate le pagine in formato JSP. Infine con dei rettangoli arancioni sono state identificate le Servlet. I collegamenti rappresentano le chiamate che normalmente vengono effettuate durante l'esecuzione dell'applicazione. La pagina index.html è la radice dell'albero delle chiamate, in quanto è la prima pagina che viene visualizzata nel caso in cui si lancia l'applicazione. In questa schermata è possibile inserire la username e la password da inviare al server, per il riconoscimento dell'utente che sta tentando di accedere alle informazioni sul data center. (fig. 7.8) Schermata di Log-In Cosimo Armando 566/2063 Pagina 96 di 116

101 (fig. 7.9) Schermata di login errato NoLogin.html invece è la pagina che viene visualizzata nel caso in cui l'utente sbaglia ad inserire le proprie credenziali. Nel caso in cui questo dovesse accadere, nella stessa pagina è situato un link che permette di ritornare alla pagina precedente per correggere i dati errati inseriti. Se invece il log-in avrà successo, verrà mostrata la schermata principale, nella quale potremo osservare lo stato di tutti i rack e di tutti gli lcp che si trovano all'interno del data center SCOPE. L interfaccia sarà, cosi, composta da: una barra di navigazione contenente: aggiornamento della pagina corrente; visualizzazione della sessione relativa ai server e ed allo storage; visualizzazione della sessione relativa agli apparati attivi; visualizzazione dei una tabella a scomparsa con gli ultimi messaggi; possibilità di tornare alla pagina precedente. 33 icone rappresentanti i rack che si trovano all'interno della sala con le loro Cosimo Armando 566/2063 Pagina 97 di 116

102 icone per lo stato. 33 oggetti rappresentanti gli lcp che si trovano all'interno della sala anch'essi con le loro icone per lo stato. Un oggetto rappresentante l'unità di controllo dell'allagamento. Un oggetto rappresentante l'unità di controllo di accesso alla sala. (fig. 7.10) Visualizzazione dello stato generale del data center Come si può vedere dall'immagine precedente, ogni rack ed ogni lcp è dotato di una piccola immagine, posta al suo fianco, che ne mostra il suo stato e quello delle apparecchiature al suo interno. Oltre a rappresentare lo stato, queste ultime permettono anche di effettuare due operazioni, in base al tipo di evento che si verifica su di essi. Cosimo Armando 566/2063 Pagina 98 di 116

103 Posizionando il puntatore del mouse su uno di questi oggetti, verrà visualizzato sulla parte destra dello schermo il dettaglio del loro stato attuale. Nella fig. 7.4 è stato cerchiato in rosso quanto descritto in precedenza. Cliccando, invece, sull oggetto il sistema ci mostrerà un ulteriore dettaglio dell impianto preso in considerazione, evidenziando lo stato dei relativi sensori. (fig. 7.11) Presentazione dei sensori del rack 1 Cosimo Armando 566/2063 Pagina 99 di 116

104 (fig. 7.12) Visualizzazione dei sensori relativi all lcp 1 Infine nelle successive figure possiamo osservare ulteriori controlli relativi all allagamento ed alla verifica di accesso nella sala. (fig. 7.13) Sensori per i controlli dell'allagamento Cosimo Armando 566/2063 Pagina 100 di 116

105 (fig. 7.14) Visualizzazione dei controlli della sala 7.3 TECNOLOGIE E METODOLOGIE Per realizzare la web application, sono state utilizzate principalmente servlet e jsp. La scelta del loro utilizzo ricade sul fatto di voler rendere dinamica la nostra applicazione, e per la semplicità di utilizzo delle servlet nelle connessioni al DB mysql. Queste infatti sono state implementate perché si aveva la necessità di interagire maggiormente con il data base remoto e vi era poco codice (in alcuni casi anche nullo) HTML da scrivere. Le jsp sono state utilizzate, invece, senza l'interazione con il data base e con più parte grafica, perché per la generazione di pagine web dinamiche, le jsp, si presentano come tecnologia ideale nella semplificazione della stesura e della modifica dell HTML. In effetti le pagine jsp sono risultate comode per scrivere il codice HTML necessario alla parte grafica del sito che abbiamo realizzato. In alcuni casi, ho comunque utilizzato all'interno delle jsp, del codice java per Cosimo Armando 566/2063 Pagina 101 di 116