Your SlideShare is downloading. ×
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Progettazione e realizzazione di un nodo di elaborazione per il rilevamento distribuito di defacement con tecnologia Java Enterprise

679

Published on

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
679
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica Anno Accademico 2007/2008 PROGETTAZIONE E REALIZZAZIONE DI UN NODO DI ELABORAZIONE PER IL RILEVAMENTO DISTRIBUITO DI DEFACEMENT CON TECNOLOGIA JAVA ENTERPRISE Relatore: prof. Alberto Bartoli Correlatore: prof. Eric Medvet Laureando: Mauri Marco
  • 2. 1 - SOMMARIO 1 - SOMMARIO ........................................................................................................ 2 2 - INTRODUZIONE .................................................................................................. 4 3 - SCENARIO DEL PROGETTO .................................................................................. 5 3.1 SCOPO DEL PROGETTO ...........................................................................................5 3.2 WEB DEFACEMENT .................................................................................................5 3.2.1 TIPOLOGIE DI ATTACCHI ...................................................................................7 3.3 STRUTTURA DEL PROGETTO ...................................................................................9 3.4 COMPITI DEL NODO DI ELABORAZIONE ...............................................................10 4 - IMPLEMENTAZIONE DEL NODO DI ELABORAZIONE ........................................... 12 4.1 TECNOLOGIE UTILIZZATE ......................................................................................12 4.2 ANALISI DETTAGLIATA DEL NODO DI ELABORAZIONE .........................................13 4.2.1 ANALISI DI UNA PAGINA WEB ........................................................................15 4.2.2 SCHEDULING DEI TASK ...................................................................................17 4.2.3 DOWNLOAD DI UNA PAGINA WEB ................................................................18 4.2.4 COMUNICAZIONE TRA NODO E CONTROLLORE ............................................21 4.2.5 PROPAGAZIONE DEGLI ALERT ........................................................................27 4.2.6 INDICI DI CARICO ............................................................................................27 4.2.7 CLUSTERING DEI NODI DI ELABORAZIONE .....................................................28 5 - CONCLUSIONI ................................................................................................... 30 5.1 OBBIETTIVI RAGGIUNTI ........................................................................................30 5.2 PRINCIPALI PROBLEMI REALIZZATIVI ....................................................................30 5.2.1 CLUSTERING DI GLASSFISH .............................................................................30 5.2.2 SEPARAZIONE TRA INTERFACCIA GRAFICA E CONTROLLORE ........................31 2
  • 3. 5.2.3 UTILIZZO DEI TIMER........................................................................................31 5.2.4 FUNZIONALITÀ RIMANDATE ..........................................................................31 5.3 OSSERVAZIONI PERSONALI ...................................................................................31 5.4 RINGRAZIAMENTI .................................................................................................32 A - DOCUMENTO INIZIALE REQUISITI E SPECIFICHE DEL PROGETTO ....................... 33 A.1 REQUISITI GOLDRAKE ...........................................................................................33 A.1.1 DEFINIZIONI ....................................................................................................33 A.1.2 GENERALE.......................................................................................................33 A.1.3 SCALABILITA' ..................................................................................................34 A.1.4 ISTANZE ..........................................................................................................34 A.1.5 CONTROLLORE ...............................................................................................35 A.1.6 UTENTI ............................................................................................................35 A.1.7 TASK................................................................................................................36 A.1.8 AGGREGATOR .................................................................................................38 A.1.9 ALERT ..............................................................................................................39 A.1.10 INTERFACCIA GRAFICA .................................................................................40 A.2 SPECIFICHE (PARZIALI) GOLDRAKE .......................................................................43 A.2.1 DB CONTROLLORE ..........................................................................................43 A.2.2 CONTROLLORE ...............................................................................................46 A.2.3 ISTANZE ..........................................................................................................48 6 - FONTI ............................................................................................................... 50 3
  • 4. 2 - INTRODUZIONE Questo lavoro intende sviluppare una componente di un progetto software per la rilevazione automatica di web defacement, la parte trattata in questa tesi consiste nella scrittura della parte atta ad elaborare le pagine web. Il software elaborato analizza le pagine web e le relative dipendenze trovando eventuali defacement e rendendo disponibili i risultati alle altre componenti del progetto. Lo sviluppo di questo applicativo è stato motivato dalla grande diffusione di defacement, e dal desiderio di creare una soluzione semplice ed economica al problema, senza porre limitazione agli sviluppatori delle pagine web stesse. Il progetto è, in effetti, iniziato già da alcuni anni con un piccolo gruppo di lavoro che ha svolto lo studio iniziale sugli algoritmi da utilizzare e la progettazione del programma finale. Per la realizzazione del tutto si è deciso di utilizzare la piattaforma Java in quanto già precedentemente utilizzata da tutti i membri dello staff ed in particolare quella Enterprise in quanto forniva già molte delle funzionalità richieste. Un ulteriore vantaggio di questa scelta è l’indipendenza dal sistema operativo utilizzato: in effetti durante lo sviluppo del software sono stati utilizzati, senza problemi di sorta, più sistemi operativi in contemporanea. Per quanto riguarda il salvataggio dei dati, l’uso di Java Enterprise rende l’applicativo indipendente dal DBMS utilizzato, durante lo sviluppo sono stati testati MySQL e PostgreSQL, senza trovare alcuna differenza durante l’esecuzione. Di seguito vengono trattati in modo più completo le seguenti parti: Scenario del progetto: in questa sezione viene esposto in maniera più estesa lo scopo del progetto, le sue motivazioni e le scelte architetturali fatte Implementazione del nodo di elaborazione: in questa sezione viene trattata in maniera dettagliata la struttura della parta svolta, con particolare riguardo per il workflow dell’analisi di una pagina web Conclusioni: in questa sezione vengono esposte in maniera particolareggiata gli obiettivi raggiunti, i problemi riscontrati e le soluzioni adottate, ed anche le osservazioni personali Appendice: in questa sezione viene semplicemente riportato il documento dei requisiti e delle specifiche redatto prima dello sviluppo del software 4
  • 5. 3 - SCENARIO DEL PROGETTO 3.1 SCOPO DEL PROGETTO Lo scopo di questo progetto è la realizzazione di una infrastruttura software in grado di rilevare in maniera automatica i defacement tramite il monitoraggio del contenuto di una pagina web in modo tale da ridurre il più possibile il tempo tra il defacement stesso di un sito e la sua correzione. Partendo da questo concetto astratto è stato compilato un documento contenente i requisiti e le specifiche di partenza da cui poi è stato sviluppato il progetto vero e proprio. In appendice viene riportato tale documento. 3.2 WEB DEFACEMENT Un web site defacement è un attacco remoto che consiste nel modificare una pagina web in modo non autorizzato, la rilevanza di questo fenomeno è manifesta: Zone-H (http://www.zone-h.org) un archivio pubblico dedicato alla raccolta di prove di defacement ha raccolto approssimativamente 490.00 defacement durante il 2005, cifra corrispondente a più di 1300 pagine web de facciate al giorno. I defacement web sono inclusi nell’annuale “CSI/FBI Computer Crime and Security Survey” a partire dalla sua 9° edizione (2004). Secondo le ultime edizioni di questo rapporto i defacement sono una delle poche categorie di attacchi in crescita. Un sito defacciato consiste tipicamente solo di un paio di messaggi o immagini che rappresentano una specie di firma dell’hacker che lo ha conseguito, talvolta un sito defacciato può contenere immagini o testo inquietanti, messaggi politici e così via. 5
  • 6. I danni possono anche non essere così evidenti però. Un attaccante capace di sostituire completamente i contenuti di un sito potrebbe anche eseguire modifiche 6
  • 7. più difficile, se non impossibili, da rilevare da parte dei visitatori delle pagine web, come ad esempio modificare uno script che raccoglie nomi utenti e password inviati dagli utenti in modo che queste venga inviate in un posto scelto dall’attaccante. 3.2.1 TIPOLOGIE DI ATTACCHI Un defacement può essere attuato in vari modi; tralasciando le tecniche che si basano su operatori disonesti, si evidenziano di seguito alcune delle strade più sfruttate, per le quali possiamo vedere nella seguente immagine le frequenze di utilizzo stimate: File inclusion 14% 2% FTP Server intrusion 27% 5% Web Application bugs 8% Attack against the administrator 13% 9% Web Server intrusion 11% SQL Injection 11% Figura 1 frequenza utilizzo metodi utilizzati per ottenere defacement. Fonte: VALUTAZIONE DI ALGORITMI DI ANOMALY DETECTION PER LA RILEVAZIONE AUTOMATICA DELLE INTRUSIONI IN SITI WEB (G. Davanzo) File inclusion (24%): si verifica quando uno script richiede come parametro il nome di un file da includere nella sua esecuzione. Se non vengono previsti adeguati controlli, un malintenzionato può indicare uno script appositamente realizzato e residente su un altro server, ottenendo così la possibilità di eseguire del codice direttamente sulla macchina attaccata. FTP Server intrusion (12%): nonostante possa apparire come una tecnica prevedibile, sfrutta il protocollo FTP per caricare materiale illecito all'interno di server non protetti in maniera adeguata per esempio, accedendo a server per i quali sono rimaste attive username e password di default. 7
  • 8. Web Application bugs (10%): una buona fetta di responsabilità spetta alle applicazioni scritte in malo modo, nelle quali si trascurano le più elementari norme di sicurezza. Accade così che programmatori sbadati si dimentichino di verificare le credenziali di accesso all'interno di tutte le pagine che dovrebbero essere protette, oppure semplifichino i controlli di accesso al punto tale da renderli inutili. Attack against the administrator (10%): solitamente sfruttano il social engineering per ottenere illecitamente username e password dell'amministratore; più rari sono i casi in cui l'attaccante riesce a 'sniffare' il traffico di rete del gestore del sistema e ottenere le password necessarie per compiere il defacement. Web Server intrusion (8%): si applica sfruttando gli errori di programmazione esistenti all'interno delle applicazioni server, cercando solitamente di ottenere privilegi superiori a quelli che effettivamente dovrebbero spettare. SQL Injection (7%): molto simile al File inclusion utilizza predicati SQL per compiere operazioni non lecite sul database. Per esempio, si ipotizzi una verifica di credenziali basata sul fatto che la seguente query ritorni almeno una SELECT * FROM tblUsers WHERE tupla password=passedPassword. E' però possibile che un utente malintenzionato digiti come password del codice sql del tipo 'pippo' or 1=1 poiché la seconda condizione si verifica sempre, la query ritornerà tutte le tuple del database e l'attaccante avrà libero accesso al sito attaccato. Man in the Middle (4%): effettivamente è una strategia molto difficile da attuare. Richiede infatti un discreto accesso alle risorse di rete della macchina server o di chi vi si collega come amministratore, ma diventa banalmente applicabile all'interno di grosse reti aziendali. Il Mani in the Middle è un attacco nel quale l'attaccante è in grado di leggere, inserire o modificare a piacere, messaggi tra due parti senza che nessuna delle due sia in grado di sapere se il collegamento sia stato compromesso. L'attaccante deve essere quindi in grado di osservare e intercettare il transito dei messaggi tra il sito e la vittima. DNS poisoning (2%): ancor più difficile del Man in the Middle, è comunque una strada a volte percorribile; lo si effettua convincendo un DNS ad indirizzare i richiedenti la pagina attaccata verso un indirizzo IP diverso da quello lecitamente registrato. Per la definizione data tale operazione non è 8
  • 9. propriamente un defacement, in accordo con quanto stabilito dagli stessi gestori di Zone-H (i quali, comunque, tempo fa sono stati soggetti ad un attacco di questo tipo). 3.3 STRUTTURA DEL PROGETTO Il progetto complessivo è composto da tre parti ben distinte che interagiscono per raggiungere lo scopo del progetto. Le tre parti sono: 1. NODO DI ELABORAZIONE Il nodo di elaborazione, o istanza, come dice il nome è quella parte del programma responsabile del monitoraggio vera e propria delle pagine web. 2. CONTROLLORE Lo scopo del controllore è quello di coordinare il lavoro di uno o più nodi di elaborazione ed avvisare i proprietari dei siti web dei defacement rilevati. 3. INTERFACCIA GRAFICA L’interfaccia grafica permette agli utenti, essenzialmente i proprietari dei siti web e gli amministratori di questo progetto, di controllare lo stato del monitoraggio e di aggiungere nuovi siti da controllare. Figura 2 Schema grafico della struttura del progetto 9
  • 10. 3.4 COMPITI DEL NODO DI ELABORAZIONE Partendo dai requisiti iniziali: 1. Ogni istanza funziona in modo del tutto autonomo, indipendentemente dalla presenza o meno di altre istanze o di controllori. 2. Ogni istanza è controllabile esclusivamente in maniera programmatica. 3. Deve essere possibile creare nuove istanze rapidamente e con minimo intervento di un operatore. 4. Deve essere possibile aggiornare il software di tutte le istanze rapidamente e con minimo intervento di un operatore. 5. Ogni istanza mantiene dinamicamente due indici di carico, il cui significato deve essere uniforme sulle diverse istanze e deve avere un significato relativo alla potenza di calcolo e di memorizzazione dell'istanza stessa cpuLoadIndex (esempio: 0.75 significa che l'istanza funziona al 75% delle proprie capacità di calcolo) storageLoadIndex (esempio: 0.75 significa che l'istanza ha consumato il 75% delle proprie capacità di memorizzazione) 6. Ogni istanza mantiene dinamicamente alcuni indici di prestazione, il cui significato deve essere uniforme sulle diverse istanze e deve avere un significato assoluto fetchShortTermThroughput (esempio: 500 significa che l'istanza ha prelevato nell'ultimo minuto circa 500 reading) fetchLongTermThroughput (esempio: 50000 significa che l'istanza ha prelevato nell'ultimo giorno circa 50000 reading) globalReadings (esempio: 50000 significa che l'istanza ha prelevato 50000 reading da quando è stata inserita nel sistema) databaseSize (esempio: 2.7 significa che l'istanza sta utilizzando 2.7 GB della propria memoria secondaria) si è cercato di ottenere un’architettura il più efficiente possibile senza essere troppo complessa. In definitiva il compito del nodo di elaborazione concretamente realizzato consiste nello scaricare i dati dei siti, analizzarli e catalogarli e, nel caso di un defacement, vero o sospettato, segnalare la condizione anomala alle altre componenti del progetto. L’unità di lavoro del nodo di elaborazione è il task, questo rappresenta il monitoraggio di una singola pagina web. Ogni task può essere configurato in maniera indipendente dagli altri in modo da variare la frequenza con cui il programma 10
  • 11. controlla la pagina web e che tipo di analisi effettuare. La segnalazione di condizioni anomale avviene tramite gli “alert”, questi rappresentano una singola condizione anomala e ne descrivono la causa; gli alert vengono poi utilizzati dal controllore per avvertire, a secondo del problema verificatosi, o il proprietario del sito monitorato o l’amministratore di questo progetto. 11
  • 12. 4 - IMPLEMENTAZIONE DEL NODO DI ELABORAZIONE 4.1 TECNOLOGIE UTILIZZATE Per sviluppare questo progetto sono state impiegate alcune tecnologie software per facilitarne lo sviluppo; qui di seguito vengono elencate spiegandone l’utilità. 1. ENTERPRISE JAVA BEANS Gli Enterprise Java Beans (EJB) sono una tecnologia standard che permette di sviluppare la business logic di un programma delegando la responsabilità di fornire alcune funzionalità comuni all’application server, cioè il programma responsabile dell’esecuzione degli EJB. I servizi da noi utilizzati forniti dall’application server sono la transazionalità, la gestione automatica della concorrenza e l’invocazione di procedure remote. 2. JAVA PERSISTENCE API La Java Persistence API (JPA) è un framework che permette la gestione dati su un database relazionale tramite l’utilizzo di normali oggetti java. All’interno di questo progetto JPA è stato utilizzato per il salvataggio di tutte le informazioni necessarie all’analisi delle pagine Web 3. SHOAL Shoal è un framework Java per la creazione di cluster, questo permette a più istanze di comunicare tra loro in maniera automatizzata dati condivisi, e la notifica dell’aggiunta o della rimozione di un altro nodo di elaborazione, tanto per uno spegnimento voluto quanto per un guasto. 4. HTML PARSER HTML Parser è una libreria Java in grado di eseguire il parsing di pagine html per estrarne il contenuto. Anche se a prima vista l’html sembra uguale al più rigoroso xml in realtà la sintassi dei due linguaggi è notevolmente diversa soprattutto tenendo conto che un parser html deve anche gestire i numerosi errori di sintassi presenti nella maggior parte delle pagine web. Alcune di queste tecnologie sono implementate da più programmi diversi, permettendo quindi una scelta tra alternative più o meno compatibili tra loro, le nostre scelte sono state le seguenti: 12
  • 13. 1. GLASSFISH 2 Questo programma è la reference implementation dello standard EJB e fornisce anche il supporto a JPA tramite l’inclusione al suo interno di Toplink Essentials 2. POSTGRESQL Per il salvataggio vero e proprio dei dati è stato scelto l’utilizzo di questo database relazionale, anche se, grazie all’uso di JPA, il codice dell’applicativo sviluppato è del tutto indipendente dalla scelta del DBMS. 4.2 ANALISI DETTAGLIATA DEL NODO DI ELABORAZIONE Qui di seguito viene riportata un’analisi dettagliata delle componenti principali del nodo di elaborazione. Fondamentalmente tutto il lavoro dell’istanza consiste nell’eseguire periodicamente i singoli task assegnati all’istanza stessa. Ogni singola esecuzione di un task corrisponde all’esecuzione di un algoritmo ben definito: 1. viene scaricata la pagina web corrispondente all’URL assegnato al task corrente 2. vengono analizzate e poi scaricate le dipendenze della pagina iniziale, ripetendo ricorsivamente questo processo per ogni pagina scaricata, fino ad un livello massimo predefinito 3. vengono applicati alla pagina web i sensori, questi ultimi verranno descritti in dettaglio in un paragrafo successivo 4. utilizzando i risultati dei sensori vengono rilevati gli eventuali defacement, qualora se ne rilevino vengono generati degli avvisi per comunicare la situazione 5. tutti i dati elaborati vengono salvati sul database. Nel caso in cui il download di una o più pagine fallisca viene semplicemente generato un avviso con i dettagli e l’elaborazione prosegue utilizzando i dati parziali. Qualsiasi altro errore, in qualsiasi punto dell’algoritmo avvenga, viene gestito tramite il supporto degli EJB alle transazioni, in pratica cioè in presenza di errori non gestiti esplicitamente, teoricamente non dovrebbero mai verificarsi, tutta l’elaborazione fatta viene annullata, riportando tutti i dati allo stesso stato che avevano prima di iniziare l’elaborazione. 13
  • 14. Un ulteriore condizione di errore gestita specificatamente è quella di crash di sistema che può portare alla perdita di alcuni dati, tale situazione viene descritta in dettaglio nella sezione 3.2.2 Nella pagina seguente viene riportato un diagramma UML che schematizza l’algoritmo descritto. Figura 3 Diagramma UML dell'algoritmo di elaborazione di un task 14
  • 15. 4.2.1 ANALISI DI UNA PAGINA WEB L’analisi di una pagina web viene effettuata tramite l’interazione di numerose classi suddivise in tre categorie: 1. Sensori 2. Aggregatori 3. Feeder Un sensore è un componente software atto ad analizzare uno specifico aspetto di una pagina web e restituire un risultato in modo puramente funzionale, cioè privo di stato; questa definizione molto ampia e generale permette ad un sensore di poter svolgere praticamente qualsiasi tipo di analisi senza limitazioni. Un aspetto estremamente importante dei sensori sono le dipendenze, infatti ogni sensore dichiara una lista di sensori da cui dipende, intendendo con questo che i propri ingressi, in aggiunta alla pagina web originale, consistono nelle uscite dei sensori da cui essi stesso dipende. Questo permette di evitare la duplicazione inutile di codice, infatti se due sensori diversi hanno una logica simile si può separare la parte comune in un terzo sensore da cui i primi due dipendano. Per semplificare le analisi statistiche necessarie a controllare gli eventuali defacement è stato definita una famiglia particolare di sensori (sensori numerici) che deve restituire come risultato delle analisi una lista di numeri; in concreto quindi i sensori su cui vengono effettuate le analisi statistiche sono tutti di tipo numerico, e gli altri sensori vengono solo utilizzati per fornire dati ai sensori numerici. 15
  • 16. Figura 4 Schema delle classi relativa all'analisi delle pagine web 16
  • 17. Un aggregatore, invece, è un componente software che, a partire dai risultati di un certo numero di sensori numerici, crea un modello di una pagina web tramite il quale, valutando l’andamento dei contenuti della pagina web monitorata nel tempo, discrimina fra defacement e cambiamenti normali. Le operazioni che un aggregatore può eseguire sono, quindi, due: valutare lo stato di una pagina e aggiornare il proprio modello interno a partire da una nuova versione della pagina web. L’ultimo componente necessario all’analisi di una pagina web è il feeder, questo è responsabile di applicare i sensori alla pagina web e decidere se i risultati delle analisi verranno utilizzati o meno per l’aggiornamento dello stato dell’aggregatore; per la precisione dopo aver analizzato lo stato di una pagina web se questo è un sospetto defacement non verrà mai utilizzato per aggiornare il modello dell’aggregatore, in caso contrario verrà utilizzato solo se è passato più di un certo tempo dall’ultimo aggiornamento. Un’ultima funzione dei feeder è l’applicazione del feedback degli utenti. Poiché nessun algoritmo può garantire in maniera assoluta il rilevamento di un defacement è possibile che l’analisi di una pagina web provochi un falso positivo o, peggio ancora, un falso negativo; in questo caso è possibile per l’utente fornire le correzioni necessarie, il feedback appunto, per correggere gli errori. Nel caso di feedback dell’utente lo scopo del feeder è quindi quello di riportare lo stato dell’aggregatore a quello subito precedente all’errore, e poi aggiornarne nuovamente lo stato con le nuove informazioni. 4.2.2 SCHEDULING DEI TASK Come già detto in precedenza un task rappresenta il monitoraggio di una singola pagina web e ne specifica il periodo di campionamento, pertanto ha bisogno di un’infrastruttura che ne permette l’esecuzione in maniera periodica. Fortunatamente la tecnologia EJB fornisce supporto all’infrastruttura degli EJB timer, questi permettono l’esecuzione temporizzata di codice, garantendone l’esecuzione anche dopo un crash di sistema. Purtroppo però gli EJB timer non permettono da soli di associare uno stato modificabile, nel nostro caso l’insieme del feeder e degli aggregatori, all’esecuzione del codice del timer. Per aggirare tale problema si è salvato lo stato all’interno di uno stateful EJB, questo tipo di componente software serve proprio a salvare uno stato persistente nel tempo, sfortunatamente però uno stateful EJB non garantisce l’accesso ai dati in seguito ad un crash di sistema, per ovviare a quest’ultimo 17
  • 18. problema è stato creato del codice in grado di ricreare lo stato dell’aggregatore a partire dai dati salvati sul database. 4.2.3 DOWNLOAD DI UNA PAGINA WEB Prima di poter analizzare una pagina web bisogna ovviamente scaricarla sulla macchina locale. Questa operazione, all’apparenza semplice, è in realtà abbastanza complicata, in parte anche a causa dalle particolari necessità del programma. La prima particolarità nel download di una pagina è la gestione manuale dei redirect; normalmente quando si scarica una pagina web si delega la gestione dei redirect alla libreria http utilizzata, ma nel nostro caso abbiamo dovuto gestirla a mano per poter memorizzare sul database tutti i passaggi intermedi, in quanto potrebbero venir scritti in futuro dei sensori che operano anche su queste informazioni. Per ogni passo di redirezione, nella maggior parte dei casi ce n’è soltanto uno, bisogna inoltre salvare tutti gli header http sia della richiesta che della risposta. Un’altra particolarità nel codice di download delle pagine web è la gestione del caching per minimizzare lo spreco di risorse, in particolare banda e spazio su disco;il protocollo http fornisce infatti, nella sua versione 1.1, il supporto nativo al caching tramite l’uso di una di due metodologie diverse. La prima metodologia consta nell’uso delle data di ultima modifica di una particolare pagina web, infatti aggiungendo un apposito header nella richiesta di una pagina si può richiedere al server di inviare i dati solo se ci sono state modifiche posteriori a quella data. Il secondo approccio si basa invece sugli “E-tag” questi sono degli identificatori generati dal server web per marcare una particolare versione di una pagina web, ogni volta che il contenuto di una pagina cambia, cambia anche l’E-Tag associato; aggiungendo tra gli header della richiesta l’E-Tag dell’ultima versione scaricata di una pagina si istruisce al server di restituire il contenuto solo se è stato variato. Purtroppo molte pagine web, soprattutto quelle di tipo dinamico, non supportano nessun tipo di caching obbligando quindi di riscaricare sempre e comunque l’intera pagina, ma fortunatamente il supporto al caching per le immagini, di dimensioni normalmente maggiori delle pagine web associate, è molto più diffuso. L’ultima, e più complessa, peculiarità del downloader del progetto è quella di ricostruire, a partire da una singola pagina web, l’albero delle dipendenze completo della pagina stessa; per esempio praticamente ogni pagina web reale ha almeno un’immagine visualizzata al suo interno ed utilizza un foglio CSS per definire la formattazione. Per costruire l’albero delle dipendenze il programma analizza in maniera ricorsiva la pagina iniziale e le dipendenze della stessa utilizzando una sere di 18
  • 19. sensori creati all’uopo; inoltre per evitare ricorsioni infinite dovute a dipendenze circolari l’applicazione utilizza una cache temporanea per vedere se la pagina da aggiungere sia già stata analizzata ed impone una profondità massima dell’albero delle dipendenze stesso. Nella pagina seguente viene riportato lo schema completo di tutte le classi utilizzate per salvare le pagine web. 19
  • 20. 20
  • 21. 4.2.4 COMUNICAZIONE TRA NODO E CONTROLLORE Poiché il nodo di elaborazione è sprovvisto sia di interfaccia grafica che di interfaccia a linea di comando questo può venir comandato solo dal controllore tramite l’invocazione di metodi remoti. L’invocazione di metodi remoti (remote procedure call o RPC) è una tecnica che permette di eseguire del codice a distanza tra due macchine diverse collegate tra loro da una rete, rendendo al contempo la differenza tra chiamate locali e remote il minore possibile. In particolare nel nostro programma questo è stato reso possibile tramite un particolare costrutto della tecnologia EJB noto come remote stateless session bean. Uno stateless session bean consiste in un’interfaccia java che definisce i metodi richiamabili remotamente che deve essere condivisa tra chiamato e chiamante ed una classe java nota solo al chiamato che implementa la suddetta interfaccia. Questo tecnologia rende la differenza tra chiamate locali e remote estremamente ridotta, consistente nel solo fatto che i parametri passati alla funzioni sono passati per valore invece che per riferimento come di solito con gli oggetti Java; se però i dati passati appartengono ad un tipo nativo di Java o ad un oggetto immutabile, come ad esempio le stringhe, la differenza diventa nulla. Qui di seguito viene riportata l’interfaccia utilizzata per la comunicazione tra nodo di elaborazione e controllore. package it.units.goldrake.common.ejb; import it.units.goldrake.common.entities.SnapshotBase; import it.units.goldrake.common.entities.DataChunkBase; import it.units.goldrake.common.entities.InstanceAlertBase; import it.units.goldrake.common.entities.NetworkAlertBase; import it.units.goldrake.common.entities.ContentAlertBase; import it.units.goldrake.common.entities.TaskDescriptorBase; import it.units.goldrake.common.exceptions.*; import java.net.URI; import java.util.*; import javax.ejb.Remote; /** * This interface exports all the operation relative to Task * amministration * of a Goldrake Instance */ @Remote public interface InstanceRemote { 21
  • 22. /** * This method schedule a Task to be executed on this * Instance * @param descriptor A TaskDecriptor object that describes * the task to be schedulated * @throws it.units.goldrake.common.DuplicateTaskException * If the task is already running */ void createTask(TaskDescriptorBase descriptor) throws TaskException; /** * This method returns the TaskDesciptor describing the * task with the specified ID * @param taskId The ID of the TaskDescriptorBase to * retrieve * @return The task descriptor associated with given ID * @throws it.units.goldrake.common.TaskNotFoundException */ TaskDescriptorBase getTaskDescriptor(long taskId) throws TaskException; /** * This method returns the value of the specified property * from the extendedProperties * map of the task identified by the given id * @param taskId the id of the wanted task * @param propertyName the name of the properties to * obtain * @return the value of the property or null if it doesn't * exits * @throws * it.units.goldrake.common.exceptions.TaskException when * the given Id does not exist */ String getPropertyOfTask(long taskId, String propertyName) throws TaskException; /** * This method set the value of the specified property * from the extendedProperties * map of the task identified by the given id * @param taskId the id of the wanted task * @param propertyName the name of the properties to set * @param propertyValue the new value of the property, if * it is null it deletes the property instead * @throws * it.units.goldrake.common.exceptions.TaskException */ void setPropertyOfTask(long taskId, String propertyName, 22
  • 23. String propertyValue) throws TaskException; /** * This method terminates the execution of the selected * Task * @param taskId The ID of the Task to be terminated * @throws it.units.goldrake.common.TaskNotFoundException * If the task doesn't exist or is not active */ void terminateTask(long taskId) throws TaskException; /** * This method terminates the execution of the selected * Task and save the identifier of the Instance that * countinue this task * @param taskId The ID of the Task to be terminated * @param instance An URI that identifies the next * instance * @throws it.units.goldrake.common.TaskNotFoundException * If the task doesn't exist or is not active */ void terminateTaskAndLinkTo(long taskId, URI instance) throws TaskException; /** * This method set the identifier of the Instance that * executed this Task previously * @param taskId The ID of the Task to be linked * @param instance An URI that identifies the previous * instance * @throws it.units.goldrake.common.TaskNotFoundException * If the task doesn't exist or is not active */ void linkFrom(long taskId, URI instance) throws TaskException; /** * This method return a list of DataChunkBase containing * data about a specified Task * @param taskId The ID of the Task of which retrieve the * data * @return A List&lt;DataChunkBase&gt; that contains the * DataChunkBase */ List<DataChunkBase> getTaskDataChunks(long taskId); 23
  • 24. /** * This method returns the last SnapshotBase of a * specified Task * @param taskId The ID of the Task of which retrieve the * data * @param recursive if true the returned object contains * all of its children. * if false it contains only the children rappresenting * its graphical rappresentation * @return The last SnapshotBase taken by the specified * task */ SnapshotBase getTaskLastSnapshot(long taskId, boolean recursive) throws TaskException; /** * This method returns the last n SnapshotBase of a * specified Task * @param taskId The ID of the Task of which retrieve the * data * @param quantity How many SnapshotBase to retrieve * @param recursive if true the returned objects contains * all of their children. * if false it contains only the children rappresenting * their graphical rappresentation * @return a list of SnapshotBase potentially empty */ List<SnapshotBase> getLastsSnapshotsOfTask(long taskId, int quantity, boolean recursive); /** * This method return all the SnapshotBase taken in the * specified day of the specified Task * @param taskId The ID of the Task of which retrieve the * data * @param theDay the day of interest * @param recursive if true the returned objects contains * all of their children. * if false it contains only the children rappresenting * their graphical rappresentation * @return a list of SnapshotBase potentially empty */ List<SnapshotBase> getSnapshotsOfTaskInDay(long taskId, Date theDay, boolean recursive); 24
  • 25. /** * This method retrieve the SnapshotBase with the * specified Id * @param snapshotId The Id pf the SnapshotBase to retrive * @param recursive if true the returned object contains * all of its children.Iif false it contains only the * children rappresenting its graphical rappresentation * @return The wanted SnapshotBase * @throws it.units.goldrake.common.TaskNotFoundException * If the SnapshotBase does not exist */ SnapshotBase getSnapshotById(long snapshotId, boolean recursive) throws TaskNotFoundException; /** * This method return a list containing all the currently * active tasks * @return A list of the TaskDescriptorBase describing * active tasks */ List<TaskDescriptorBase> getActiveTasks(); /** * This method return a list containing all the currently * active on-line tasks * @return A list of the TaskDescriptorBase describing * active on-line tasks */ List<TaskDescriptorBase> getActiveTasksOnLine(); /** * This method return a list containing all the currently * active simulated tasks * @return A list of the TaskDescriptorBase describing * active simulated tasks */ List<TaskDescriptorBase> getActiveTasksSimulated(); /** * This method return a list containing all known tasks * @return A list of the TaskDescriptorBase describing * known tasks */ List<TaskDescriptorBase> getAllTasks(); 25
  • 26. /** * This method returns all the InstanceAlertBase newer * than the specified date * @param startDate the initial date * @return a list of InstanceAlertBase */ List<InstanceAlertBase> getInstanceAlerts(Date startDate); /** * This method returns all the ContentAlertBase newer than * the specified date * @param startDate the initial date * @return a list of ContentAlertBase */ List<ContentAlertBase> getContentAlerts(Date startDate); /** * This method returns all the NetworkAlertBase newer than * the specified date * @param startDate the initial date * @return a list of NetworkAlertBase */ List<NetworkAlertBase> getNetworkAlerts(Date startDate); /** * This method is meant to apply the user feedback to the * aggregators of a task * in case of false positive or false negative * @param taskId the Id of the task that must be corrected * @param corrections a list of SnapshotBase indicating * the wanted outcomes. Only the Id and Outcome properties * of the objects are evaluated, all other properties can * be null * @return a list of SnapshotBase whose Outcomes changed * because of the corrections applied */ List<SnapshotBase> forceTaskOutcomes(long taskId, List<SnapshotBase> corrections); } 26
  • 27. 4.2.5 PROPAGAZIONE DEGLI ALERT Poiché ogni nodo di elaborazione non è in diretto contatto con gli utenti ha bisogno di qualche modo per comunicare al controllore gli eventuali problemi riscontrati in modo che questi possa poi comunicarli agli interessati; per risolvere questo problema si è deciso di creare in ogni nodo di elaborazione una lista di avvisi, detti alert, contenenti al loro interno la descrizione del problema. Gli alert si suddividono in tre categorie: la categoria degli alert di contenuto (ContentAlert) serve a indicare un possibile defacement, le informazioni che contiene sono il task che l’ha generato, la specifica versione della pagina web (snapshot) interessata ed eventuali messaggi degli aggregatori. La seconda categoria è invece quelle degli alert di rete (NetworkAlert) che indica un qualche problema durante il download di una pagina web come ad esempio l’impossibilità di trovare il server remoto od un qualche errore dello stesso come ad esempio il noto errore http “File not found”; le informazioni contenute in questo tipo di alert sono le stesse di un alert con la sola differenza che la pagina web potrebbe essere assente del tutto. L’ultima categoria di alert è invece quella degli alert di istanza (InstanceAlert), questi rappresentano un errore causato dal nodo di elaborazione stesso. L’unico InstanceAlert generato attualmente è quello che corrisponde alla mancata esecuzione di un’analisi di una pagina web causato da un sovraccarico del nodo stesso; al contrario degli altri alert questo contiene al suo interno solo l’identificativo del nodo che lo ha generato ed un messaggio di errore che ne spiega la causa. Gli alert sono accessibili dal controllore tramite tre metodi remoti, uno per categoria di avvisi, i quali, per evitare di sprecare banda inutilmente, accettano come parametro di ingresso una data che rappresenta la data dell’ultimo avviso noto al controllore permettendo quindi, in caso non ci siano nuovi avvisi, di non inviare dati inutilmente. 4.2.6 INDICI DI CARICO Poiché alla creazione di un task il controllore deve decidere su quale nodo di elaborazione deve avviare il lavoro questo ha bisogna di una metodologia per la scelta del nodo. A questo scopo sono stati creati li indici di carico; questi sono degli indicatori numerici delle risorse hardware, come ad esempi la percentuale di processore utilizzato o lo spazio libero su disco, attualmente utilizzate su un determinato nodo di elaborazione. Grazie agli indici di carico è possibile decidere non solo di avviare nuovi task sulla macchina meno occupata ma anche di rilevare eventuali sovraccarichi e spostare l’esecuzione dei task da una macchina sovraccarica 27
  • 28. ad una meno impegnata. Come gli alert anche gli indici di carico sono acceduti dal controllore tramite l’uso di metodi remoti. 4.2.7 CLUSTERING DEI NODI DI ELABORAZIONE Per semplificare l’utilizzo simultaneo di più nodi di elaborazione in una stessa rete locale si è deciso di avvalersi di una libreria di clustering per automatizzare alcune funzioni in modo da diminuire il più possibile la configurazione da eseguire manualmente in questo contesto. Per raggiungere questo scopo si è introdotto il concetto di gruppo di istanze, questo rappresenta un’insieme di due o più nodi di elaborazione fisicamente collocate nella stessa rete, all’interno di un gruppo l’aggiunta o la rimozione di un nodo viene rilevata automaticamente da tutti gli altri nodi tramite delle notifiche da parte della libreria di clustering. Altre due funzionalità ottenute dall’uso del clustering sono la rilevazione automatica di guasti di un nodo e la condivisione tra tutti i nodi di un gruppo degli indici di carico. Grazie a questa infrastruttura il controllore può automaticamente trovare tutti i nodi di un gruppo conoscendo semplicemente l’indirizzo di uno di questi nodi e, tramite l’invocazione di metodi remoti, ottenere automaticamente la lista di tutte le istanza del gruppo, inoltre anche l’accesso agli indici di carico è semplificato in quanto basta richiederli ad uno qualsiasi dei nodi di un gruppo. Qui di seguito è riportata l’interfaccia remota che permette di ottenere la lista dei nodi di un gruppo e gli indici di carico dello stesso. 28
  • 29. package it.units.goldrake.common.ejb; import it.units.goldrake.common.entities.Instance; import it.units.goldrake.common.entities.LoadIndexType; import java.io.Serializable; import java.net.URI; import java.util.List; import java.util.Map; import javax.ejb.Remote; /** * This interface exports all the operation relative to group * administration and load index of a Goldrake Instance */ @Remote public interface InstanceManagementRemote { /** * This method return a list of all instances known to * this instance, if this instance doesn't belong to a * group or if the group doesn't contains other instances * the list returned contains only reference to this * instance. * @return a list of known instances */ List<Instance> getInstancesList(); /** * This method returns all the known load index of the * specified instance, if this instance doesn't know any * data about the specified instance the returned map is * empty * @param instanceURI The URI of the intance to obtain * data about * @return a map containing the load indexes of a instance, * potentially empty */ Map<LoadIndexType,Serializable> getInstanceDetails( URI instanceURI); /** * This method returns all the known load index of all the * known instances, if this instance doesn't belong to a * group or if the group doesn't contains other instances * this method returns only the index of the current * instance * @return a map of load index keyed by the URI of the * instance */ Map<URI, Map<LoadIndexType, Serializable>> getAllDetails();} 29
  • 30. 5 - CONCLUSIONI 5.1 OBBIETTIVI RAGGIUNTI Il lavoro svolto fino a questo momento ha seguito essenzialmente i requisiti e le specifiche formulate all’inizio, quanto elaborato riesce pertanto a monitorare i siti web per rilevare in maniera automatica eventuali defacement. 5.2 PRINCIPALI PROBLEMI REALIZZATIVI Durante la scrittura del programma sono state però effettuate alcune piccole variazione ed aggiunte rispetto a quanto previsto, mentre altre parti inizialmente pianificate saranno effettuate in un secondo momento. 5.2.1 CLUSTERING DI GLASSFISH Vi sono state delle difficoltà tecniche nella parte riguardante il clustering; inizialmente si pensava di sfruttare il supporto nativo di GlassFish al clustering, ma dopo un esame più attento si è scoperto che non operava nel modo da noi voluto: praticamente il clustering nativo creava una singola macchina logica corrispondente ad un intero cluster, senza esternare la reale suddivisione del lavoro, non solo, imponeva anche l’utilizzo di un solo database per l’intero cluster, mentre si preferiva, per motivi di scalabilità, di avere un database indipendente per ogni istanza. Per tali motivi si è deciso, come già accennato in precedenza, di ricorrere all’utilizzo diretto della libreria Shoal utilizzata anche dal clustering di GlassFish. L’utilizzo di questa libreria ha però portato un altro problema, infatti GlassFish, in caso di comunicazione tra due server appartenenti allo stesso cluster, abilita automaticamente l’uso di transazioni distribuite, le quali risultano computazionalmente molto pesanti, e richiedono l’utilizzo di driver particolari per l’accesso ai database. La soluzione effettuata è stata quella, già descritta precedentemente, di escludere il controllore dal cluster, in quanto, come da requisiti, le istanza non comunicano mai tra di loro. Inoltre è stato sviluppato il supporto a più cluster separati ed a istanze singole non appartenenti a nessun cluster, questa modifica permette una maggior scalabilità del programma, in quanto l’elaborazione può essere suddivisa tra più reti distinte tra loro e permette anche l’utilizzo di singole macchine noleggiate. 30
  • 31. 5.2.2 SEPARAZIONE TRA INTERFACCIA GRAFICA E CONTROLLORE Un’altra modifica rispetto ai piani iniziali riguarda una maggior divisione tra interfaccia grafica e controllore; inizialmente il controllore poteva essere comandato solo dall’interfaccia grafica, ma si è deciso, per semplificare l’amministrazione del programma, di permettere ad altri programmi (nello specifico un programma a riga di comando) di accedere alle funzionalità offerte dal controllore. Questa variazione si è ottenuta trasformando l’interfaccia utilizzata dall’amministrazione web in una serie di remote stateless session bean così da permettere l’esecuzione di codice remoto. 5.2.3 UTILIZZO DEI TIMER Un ulteriore differenza è stato l’uso dei timer al posto dei message bean per la schedulazione dei task, questa variazione è dovuta solo ad una maggior semplicità d’uso, in quanto ci sarebbe stata comunque la necessità di impiegare almeno un timer per schedulare l’invio dei messaggi. 5.2.4 FUNZIONALITÀ RIMANDATE Vi sono state infine alcune funzionalità rimandate ad uno sviluppo futuro, nello specifico è stata implementata solo la gestione degli utenti clienti (funzionalità riguardante solo l’interfaccia grafica), mentre la gestione dei task simulati è stata omessa completamente. 5.3 OSSERVAZIONI PERSONALI Personalmente ritengo questo programma molto interessante e soprattutto attuale; dal punto di vista dello sviluppo si potrebbero provare delle alternative a GlassFish, in quanto quest’ultimo non si rivelato sempre affidabile, talvolta bloccandosi o riportando errori casuali non riproducibili che scompaiono dopo il riavvio del server. Sarebbe inoltre interessante cercare se esiste un metodo per mantenere l’attuale separazione di codice tra le varie componenti (istanza e controllore) riducendo al contempo la quantità di codice necessario da scrivere; infatti per ogni entità logica condivisa tra controllore e istanza è stato necessario scrivere un’interfaccia e tre classi i cui codici sono per la maggior parte identici senza poter sfruttare inoltre le funzionalità di casting in quanto questi tipi non ereditano l’uno dall’altro. 31
  • 32. 5.4 RINGRAZIAMENTI Si ringrazia sentitamente per i consigli e la continua assistenza tecnica e umana il relatore professor A. Bartoli e il correlatore prof. E. Medvet; si ringrazia anche il dottor G. Davanzo per la sua collaborazione. Un sentito grazie anche agli altri tesisti (dott. E. Sorio e dott. A. Zorzin) per la pazienza e la collaborazione necessaria per un lavoro di gruppo come questo. 32
  • 33. A - DOCUMENTO INIZIALE REQUISITI E SPECIFICHE DEL PROGETTO A.1 REQUISITI GOLDRAKE Cioè: cosa vogliamo che faccia, non come. A.1.1 DEFINIZIONI Risorsa: pagina web visualizzabile in un browser. Ogni risorsa è associata an URL. Nel caso la risorsa sia un documento HTML, essa include anche tutte le informazioni necessarie al browser per la sua visualizzazione (immagini, javascript, CSS etc). Warden: unità di servizio acquistabile dai clienti del sistema. WardenProfile: elementi che definiscono la QoS del Warden. Ogni Warden ha esattamente un WardenProfile e questo è immutabile. Task: processo di monitoraggio di una risorsa. Ogni Task appartiene esattamente ad un Warden. Reading: immagine di una risorsa ad un dato istante. Aggregator: algoritmo per catalogare i reading in normali o anomali. A.1.2 GENERALE 1. Non deve essere legato ad alcun sistema operativo. 2. Deve essere possibile analizzare i Task anche dopo la loro terminazione ed indipendentemente dalla versione del software utilizzato. In particolare, se la rappresentazione interna di un Task include informazioni il cui formato dipende dalla versione del software (ad esempio, oggetti Java serializzati quali sensor e aggregator) queste informazioni devono essere utilizzabili in ogni versione del sistema. 3. Consiste di: una o più istanze, tipicamente molte più di una. un controllore. Ogni istanza effettua il monitoraggio di un insieme di risorse, il controllore (o controllori) coordinano il sistema. 33
  • 34. A.1.3 SCALABILITA' 1. Istanze: Alcune centinaia. 2. Risorse: Migliaia o poche decine di migliaia per istanza, in dipendenza della potenza dell'istanza. 3. Warden: Migliaia A.1.4 ISTANZE 1. Ogni istanza funziona in modo del tutto autonomo, indipendentemente dalla presenza o meno di altre istanze o di controllori. 2. Ogni istanza è controllabile esclusivamente in maniera programmatica. 3. Deve essere possibile creare nuove istanze rapidamente e con minimo intervento di un operatore. 4. Deve essere possibile aggiornare il software di tutte le istanze rapidamente e con minimo intervento di un operatore. 5. Ogni istanza mantiene dinamicamente due indici di carico, il cui significato deve essere uniforme sulle diverse istanze e deve avere un significato relativo alla potenza di calcolo e di memorizzazione dell'istanza stessa cpuLoadIndex (esempio: 0.75 significa che l'istanza funziona al 75% delle proprie capacità di calcolo) storageLoadIndex (esempio: 0.75 significa che l'istanza ha consumato il 75% delle proprie capacità di memorizzazione) 6. Ogni istanza mantiene dinamicamente alcuni indici di prestazione, il cui significato deve essere uniforme sulle diverse istanze e deve avere un significato assoluto fetchShortTermThroughput (esempio: 500 significa che l'istanza ha prelevato nell'ultimo minuto circa 500 reading) fetchLongTermThroughput (esempio: 50000 significa che l'istanza ha prelevato nell'ultimo giorno circa 50000 reading) globalReadings (esempio: 50000 significa che l'istanza ha prelevato 50000 reading da quando è stata inserita nel sistema) databaseSize (esempio: 2.7 significa che l'istanza sta utilizzando 2.7 GB della propria memoria secondaria) ... 34
  • 35. A.1.5 CONTROLLORE 1. Il controllore costituisce l'unica modalità di interazione con il sistema per gli utenti. 2. Il controllore consiste di due moduli: interfaccia grafica, accessibile agli utenti; core, accessibile esclusivamente in maniera programmatica dall'interfaccia grafica 3. Gli utenti interagiscono con l'interfaccia grafica. Questa interagisce con il core. Questo interagisce con le istanze. L'interfaccia grafica non deve accedere alle istanze bypassando il core. 4. Il controllore implementa la nozione di WardenProfile, che è del tutto sconosciuta alle istanze. 5. Il controllore deve visualizzare l'elenco delle istanze esistenti e di quelle attualmente attive. 6. Per ogni istanza, il controllore deve acquisire automaticamente le seguenti informazioni: variazioni attiva/inattiva, ritardo contenuto entro pochissimi minuti. cpuLoadIndex, ritardo contenuto entro pochissimi minuti. storageLoadIndex, ritardo contenuto entro qualche ora. (nota: sono acquisiti automaticamente solo gli indici di carico, non gli indici di prestazione). instance alert, ritardo contenuto entro qualche ora A.1.6 UTENTI 1. Sono divisi in tre categorie disgiunte: Amministratori (operatori di Goldrake). Amministratori Clienti (AC) Utenti Clienti (UC) 2. Un AC può essere associato a più Warden, ognuno con il proprio WardenProfile. Il controllore deve associare costantemente un AC al Warden che sta impersonando. 3. I diritti delle categorie sono i seguenti: Un Amministratore può operare su ogni risorsa; può aggiungere/rimuovere AC; può aggiungere/rimuovere UC (associati ad un UC). Un AC può operare su tutte le risorse del/dei warden corrispondenti; può aggiungere/rimuovere suoi UC. 35
  • 36. Un UC può operare solo sulle risorse che sono state da lui inserite nel sistema. A.1.7 TASK 1. Un task consiste di un descrittore e dati, come segue: descrittore: o id del Warden a cui appartiene il Task, o URL della risorsa, o samplingPeriod, o startingTime, endingTime (possibly NULL), o status: inProgress/completed, (descrive se il task è ancora in corso oppure no) o type: onLine/simulated, (descrive se il monitoraggio avviene in tempo reale sulla risorsa reale oppure su un archivio raccolto in precedenza; vedi i task simulati più sotto) o setOfAggregators. dati: o sequenza di reading della risorsa. Ogni reading contiene:  informazioni necessarie per visualizzare completamente la risorsa in un browser (immagini, javascript, CSS etc.) ;  istante a cui è stato prelevato il reading;  HTTP response ottenuta per ogni HTTP request utilizzata per prelevare il reading.  per ogni aggregator del setOfAggregators, outcome: normal/anomalous; eventuale feedback (vedi più sotto il feedback di utenti; occorre indicare se l'outcome è stata alterata da un utente oppure no). values of sensorList o sequenza di alert generati, come segue:  per ogni aggregator del setOfAggregators link ad ogni reading per il quale è stato generato un content alert descrizione dell'alert link ad ogni reading per il quale è stato generato un network alert descrizione dell'alert 36
  • 37. 2. Gli attributi di un task sono immutabili. Qualora sorgesse la necessità di variare alcuni attributi di un task (ad esempio il samplingPeriod oppure il setOfAggregators), allora occorre terminare il task e crearne un altro con i valori opportuni per gli attributi. Operazioni del genere possono essere facilitate dall'interfaccia grafica del controllore. 3. Le operazioni su un task sono: a. creazione. Può essere invocata da un A, AC, UC. input: URL da monitorare, samplingPeriod, setOfAggregators samplingPeriod può essere variato tra estremi prefissati in base al WardenProfile setOfAggregators contiene elementi fissati dal WardenProfile. Alcuni WardenProfile possono permettere all'utente che crea il task di includere zero o più aggregator predefiniti della forma quot;sufficient conditionquot;. Alcuni WardenProfile, disponibili solo agli Amministratori, possono permettere all'utente che crea il task di scegliere a proprio piacimento gli aggregator da inserire nel setOfAggregators. Il task appartiene al Warden associato all'utente che ha creato il task. L'istanza su cui eseguire il task è scelta automaticamente dal controllore (in base a politiche al momento non specificate, che si basano sugli indicatori di carico e sul WardenProfile). E' possibile effettuare una creazione in batch di un insieme di task: l'utente specifica il link di partenza ed un insieme di criteri di ammissione da passare ad un crawler; al termine del crawl, sarà fornito l'elenco delle risorse individuate e sarà possibile creare automaticamente un task per ognuna di esse, eventualmente eliminandone alcune manualmente. b. terminazione può essere invocata da un A, AC, UC. c. checkpoint può essere invocata da un A, AC, UC. termina il task e ne crea un altro del tutto identico al precedente. Può servire per contenere le dimensioni dei dati e per facilitare l'esecuzione di task simulati. 37
  • 38. d. modifica può essere invocata da un A, AC, UC. termina il task e ne crea un altro del tutto identico al precedente, permettendo di modificare alcuni attributi selezionati. e. migrazione per prestazioni può essere invocata solo da un A. Un task può essere forzato a migrare su un'altra istanza quando il cpuLoadIndex dell'istanza su cui risiede il task diventa quot;eccessivoquot;. La decisione su quando effettuare una migrazione e verso quale istanza viene presa dal controllore (non dalle istanze). Ciò può avvenire manualmente, su decisione dell'operatore, oppure automaticamente. f. migrazione per fault-tolerance può essere invocata solo da un A. Un task può essere forzato a migrare su un'altra istanza quando l'istanza su cui risiede si guasta. TASK SIMULATI 1. Un task può essere simulato. Un task simulato è associato a un altro task non simulato e terminato. Un task simulato valuta il comportamento di uno o più aggregator sui dati (sequenza di reading) già raccolti dal task associato. 2. Le operazioni possibli su un task simulato sono le stesse di quelle possibili su un task non simulato. L'unica differenza tra i due è che un task simulato non genera alert. 3. La creazione di task simulati è permessa solo ad alcuni WardenProfile. A.1.8 AGGREGATOR 1. Un aggregator consiste delle seguenti informazioni: Nome ClasseCheImplementaAlgoritmo VersioneAlgoritmo EventualiParametri SensorList unique-ID 2. Un Aggregator riceve un array di numeri prodotti dalla rispettiva SensorList e produce un valore di tipo enumerato: Normal, Anomalous, Learning. 38
  • 39. 3. Un Aggregator può essere aggiunto o rimosso solo da un Amministratore. La rimozione di un Aggregator implica che non sarà più possibile creare Task che utilizzano quell'AggregatorModel. Sarà però possibile continuare ad utilizzare le informazioni storiche associate ad eventuali Task che hanno usato l'Aggregator rimosso. A.1.9 ALERT 1. Un'istanza può generare varie tipologie di alert: content alert, corrispondente ad un reading catalogato come anomalo da un aggregator network alert, corrispondente ad un reading il cui prelievo ha generato una condizione di errore (network error, HTTP response con errore, numero elevato di network error consecutivi...) instance alert, corrispondente a situazioni anomale relative al funzionamento dell'istanza nel suo complesso (indici di carico che superano una soglia predefinita, ...) 2. Un'istanza genera alert per un reading r non appena si verifica una delle condizioni seguenti: content alert, quando l'output dell'aggregator applicato ad r è Anomalous e l'output sul reading precedente non era Anomalous network alert, quando il prelievo di r ha generato una condizione di errore ed il prelievo del reading precedente non ha generato una condizione di errore instance alert, quando l'istanza rileva la situazione anomala. 3. Content alert e network alert sono associati al Task che ha causato il prelievo del reading corrispondente. Instance alert non sono associati a nessun Task. ALERT E UTENTI 1. Gli alert sono visibili agli utenti come segue: content alert e network alert: agli A ed agli AC/UC che possono accedere al Task instance alert, solo agli A 2. Un utente può effettuare operazioni di subscribe / unsubscribe per gli alert che può vedere. L'utente sceglie il metodo di trasmissione dell'alert tra quelli disponibili nel proprio WardenProfile. Alcuni WardenProfile devono supportare l'invio di alert agli utenti tramite email, SMS. 39
  • 40. 3. Un alert deve contenere informazioni esplicative sulla natura dell'alert (network alert e instance alert sono indipendenti dagli aggregator e dalla sensorList, mentre i content alert non lo sono). 4. Il controllore deve: acquisire un alert entro pochissimi minuti dalla sua generazione. inviare ad ogni utente gli alert di sua pertinenza entro pochissimi minuti dalla loro generazione 5. Ogni utente deve quot;vederequot; ogni alert di sua pertinenza. L'interfaccia grafica mantiene evidenza, per ogni utente, degli alert inviati all'utente e non ancora visti. Ciò avviene in modo analogo ai messaggi mail letti/non letti dei comuni programmi mail client. FEEDBACK DI UTENTI 1. Un utente può modificare la catalogazione di una sequenza di reading anomali fornita da un aggregator. Ciò può avvenire solo in questo caso: l'utente si collega all'interfaccia grafica all'istante t_0; il reading più recente disponibile sull'interfaccia è relativo a un istante quot;molto vicinoquot; a t_0; questo reading è anomalo. In questo caso l'utente può decidere di catalogare come normale il reading. Se i reading immediatamente precedenti sono anch'essi anomali (sequenza di reading anomali che non contiene reading normali) allora l'utente può catalogare come normali tutti i reading della sequenza. 2. Questo feedback sarà utilizzato dall'aggregator corrispondente per modificare il proprio stato interno di di conseguenza. 3. Il feedback fornito dagli utenti deve essere memorizzato nel Task corrispondente. A.1.10 INTERFACCIA GRAFICA Deve offrire le seguenti view: 1. Amministrativa (accessibile solo agli A) Gestione Utenti Gestione Warden Gestione WardenProfile Gestione Istanze 40
  • 41. o Elenco delle istanze esistenti, con evidenziazione grafica di quelle attualmente attive. o Elenco storico per una o più istanze, con possibilità di variare la window temporale:  attività/inattività  indici di carico, indici di prestazioni o Analisi di dettaglio dei log di un'istanza specificata, con possibilità di variare la window temporale. Gestione Alert o Funzionalità analoghe alla view Alert (più sotto), con in più elenchi:  Globale  Per istanza 2. Alert Numero degli alert quot;recentiquot;, con possibilità di variare la window temporale, con possibilità di separare content/network: o per warden o per task Analisi di dettaglio di singolo alert, con possibilità di o visualizzazione contemporanea della view Reading per il reading associato. o feedback sui reading anomali (vedi alert, feedback) 3. Warden Elenco degli warden, con ricerca per nome (tramite auto-completion) Analisi di dettaglio del singolo warden (profile). 4. Task (di un warden selezionato, di più warden selezionati, di tutti i warden accessibili all'utente) Elenco dei task, con ricerca per URL (tramite auto-completion) Come sopra, ristretto ai soli task con alert quot;non ancora vistiquot; Analisi di dettaglio del task selezionato, con storico dei dati, con possibilità di passaggio alla view Reading. Operazioni sui task, come specificate più sopra. 5. Task simulati come sopra, ristretto ai soli task simulati 6. Reading Sequenza quot;navigabilequot; di reading, a partire da un reading specificato Possibilità di evidenziare l'output degli aggregator associati al Task a cui appartiene il reading (uno o più aggregator selezionati) Possibilità di passare all'analisi di dettaglio del singolo alert 41
  • 42. Per ogni reading deve essere facilmente accessibile: o contenuto visibile su browser o sorgente HTML/Javascript.... di ogni singolo elemento che compone lo reading della risorsa o risposte HTTP corrispondenti o immagine del contenuto visibile su browser risposte HTTP corrispondenti In tutte le view (ad eccezione della view Amministrativa) deve essere chiaramente evidenziato il Warden ed il Task nel contesto dei quali l'utente sta operando. 42
  • 43. A.2 SPECIFICHE (PARZIALI) GOLDRAKE Cioè: come vogliamo che siano implementati i requisiti GENERALI 1. Java EE, GlassFish application server 2. Le istanze fanno parte di un cluster GlassFish. La membership (istanze attive) è gestita dal GlassFish clustering. La propagazione degli indici di carico è gestita dalla distributed cache del GlassFish clustering (da verificare). 3. Il core del controllore è membro del GlassFish cluster (in modo da poter accedere agli indici di carico; per i soli fini della membership potrebbe essere un client del membership service del cluster e non essere membro del cluster). 4. Controllore: a. L'interfaccia grafica è scritta in JSF. b. Il core consiste di un insieme di bean accessibili al codice dell'interfaccia grafica 5. Ogni istanza accetta richieste attraverso stateless bean 6. L'accesso ai DB deve avvenire attraverso la persistence API (JPA), sia sulle istanze sia sul core. 7. Ogni istanza opera esclusivamente da server. In particolare, ciò implica che: una istanza non può invocare operazioni di altre istanze. una istanza non può invocare operazioni sul controllore. 8. Tutti i messaggi di interazione con gli utenti devono essere in inglese. A.2.1 DB CONTROLLORE PREMESSA IMPORTANTE Il DB del controllore deve contenere informazioni sulle entità non note alle istanze: Warden, WardenProfile, Utenti. In linea teorica sarebbe possibile non memorizzare alcuna informazione sui Task nel DB del controllore. Basterebbe memorizzare i Task solo sulle istanze ed associare ad ogni Task un identificativo del Warden a cui appartiene. Questo approccio però non è accettabile: Alcune informazioni devono essere disponibili agli utenti anche in momenti di temporanea inaccessibilità di alcune istanze (non è pensabile che un AC/UC effettui un login e non veda l'elenco di tutti i suoi Task; è tollerabile che parti dell'archivio siano temporaneamente indisponibili, ma almeno l'elenco delle risorse che il Warden sta monitorando deve essere sempre disponibile). 43
  • 44. Alcune informazioni devono essere ottenibili dall'interfaccia grafica rapidamente (non è pensabile fare uno scan di tutte le istanze per scoprire quali siano i Task di un dato Warden). Il controllo degli accessi deve essere centralizzato (pertanto il controllore deve avere l'elenco completo dei task, poiché la granularità del controllo è il task; ciò implica che occorre mantenere sul DB del controllore una Tabella Task con almeno 1 M record, poiché 100 istanze per 10000 task per istanza fa 1 M.) Occorre pertanto memorizzare sul DB del controllore alcune informazioni relative ad ogni singolo Task. Ciò introduce due problemi molto importanti: Scalabilità (occorre mantenere sul DB del controllore una Tabella Task con almeno 1 M record, poiché 100 istanze per 10000 task per istanza fa 1 M) Coerenza tra i DB (ogni operazione di modifica a un Task, invocata dal controllore, deve aggiornare in modo atomico il DB del controllore ed il DB dell'istanza coinvolta. Guasti o malfunzionamenti durante l'esecuzione dell'operazione possono introdurre incoerenze tra il DB del controllore e il DB dell'istanza; inoltre, l'utente che provocato la modifica non conosce l'esito dell'operazione). Il problema di Scalabilità si risolve minimizzando la quantità di informazioni relative ad un Task che sono mantenute nel DB del controllore. Il problema di Coerenza tra i DB si potrebbe risolvere incapsulando ogni operazione di modifica ad un Task in una transazione distribuita. Anche prescindendo dal costo in termini di prestazioni, questo approccio non è accettabile: Complessità: o la gestione dei commit distribuiti è molto complicata ed è impensabile programmarla esplicitamente; o Java EE supporta automaticamente le transazioni centralizzate (un solo DB) ma non quelle distribuite (più DB). o Esistono application server con estensioni in grado di gestire transazioni distribuite, ma sono di solito a pagamento e normalmente molto complessi o Il sistema dovrà essere programmato e gestito anche da persone che possono non avere familiarità con le sottigliezze della fault-tolerance in ambito distribuito, per cui è bene evitare queste problematiche. Inoltre, l'uso delle transazioni atomiche distribuite non previene le incoerenze tra i DB e non risolve l'incertezza dell'utente in caso di guasto. Questo 44
  • 45. approccio garantisce solo che quando il guasto viene risolto, il sistema automaticamente riporta i due DB nello stesso stato (tra l'altro, è anche possibile che sino a quando non si risolve il guasto su uno dei due lati, la riga del Task su cui si stava operando rimanga inutilizzabile sull'altro lato). Il problema di Coerenza tra i DB si risolve come segue: Le operazioni sui Task sono creazione, terminazione, migrazione, feedback di utente Ogni operazione di modifica dei Task deve essere implementata sul lato controllore in questo modo: o Invocazione operazione su Istanza o Se OK, aggiornamento DB del controllore o Se non-OK, notifica all'utente quot;non so se l'operazione è stata eseguita, please try again laterquot; Periodicamente, un repair thread sul controllore analizza in modo asincrono il DB del controllore e il DB di ogni istanza (un'istanza ogni qualche ora, ad esempio) o when esiste task T su istanza A e non esiste su controllore: genera notifica per gli amministratori (errore durante la creazione; in questo caso la cosa più sensata è cancellare il task sull'istanza); o when esiste task T terminato su istanza A e il controllore ritiene che T stia su A ma non sia terminato (errore durante la terminazione; la cosa più sensata è cancellare il task); o when esiste task T su istanza A e il controllore ritiene che T stia su B: esegue repair della migrazione (errore durante la migrazione; vedi note realizzative più sotto); In altre parole, prima si aggiorna l'istanza e poi si aggiorna il controllore. Le incoerenze possibili si risolvono caso per caso, quando ci sono, visto che sono semplici da rilevare, interpretare, gestire. TABELLE Schema da definire in maggiore dettaglio Tabella degli Utenti Tabella degli WardenProfile Tabella degli Warden (l'unica informazione sui Task del Warden è il task_id; nessuna informazione su quali istanze sono coinvolte) Tabella dei Task 45
  • 46. o task id o URL o ID dell'istanza contenente l'ultimo chunk (o uno quot;vicino all'ultimoquot;) o info di ACL o data dell'ultimo network alert ricevuto per questo Task o data dell'ultimo content alert ricevuto per questo Task Tabella degli Instance Alert o instance id o data dell'ultimo instance alert ricevuto da questa istanza Da notare che gli alert risiedono sui DB delle istanze. Sul DB del controllore ci sono solo le informazioni necessarie per sincronizzare controllore e istanze, per permettere cioè al controllore di prelevare dalle istanze solo gli alert ancora non prelevati (ricordare che le istanze non possono contattare il controllore ma sono contattate da quest'ultimo, ad istanti fissati dall'interfaccia grafica). A.2.2 CONTROLLORE BREVE NOTA REALIZZATIVA SULL'INTERFACCIA GRAFICA 1. Il controllore può mostrare l'elenco dei Task, comprendente il solo URL, rapidamente in quanto è disponibile nel DB locale. 2. Ogni altra informazione è prelevata dall'istanza. Per quot;ogni altra informazionequot; si intende il descrittore del task, i reading, gli alert etc. 3. Queste informazioni sono inserite nella sessione HTTP dell'utente non appena sono state prelevate, in modo da essere richiamate in seguito. 4. Pertanto, ogni volta che è necessario quot;prelevarequot; informazioni da una istanza, prima si verifica se sono nella sessione HTTP; se non ci sono, si prelevano e si inseriscono RAPPRESENTAZIONE 1. Un task consiste di un descrittore e dati (vedi requisiti). 2. La migrazione di un task consiste nella migrazione del solo descrittore sulla nuova istanza. I dati rimangono sulla istanza precedente. A regime, quindi, un task può risiedere su più istanze. Intuitivamente, la componente quot;attivaquot; del task risiede su di una sola istanza, mentre l'archivio storico può risiedere su più istanze. 46
  • 47. 3. I dati di un task consistono di una sequenza di data-chunk, ognuno corrispondente ad un intervallo temporale. Data-chunk corrispondenti a intervalli consecutivi risiedono, tipicamente, su istanze diverse. Idealmente, l'unione di tutti i data-chunk (di uno stesso task) dovrebbe formare un intervallo continuo senza sovrapposizioni. In pratica può accadere che: ci siano intervalli (sperabilmente brevi) non associati a nessun chunk, in caso di guasto di un warden non gestito in maniera fault-tolerant; ci siano intervalli (tipicamente brevi) associati a più chunk. Questi intervalli corrispondono al tempo necessario per completare una riconfigurazione per prestazioni: il descrittore quot;vecchioquot; dovrà essere reso inerte solo dopo che è stato attivato il descrittore quot;nuovoquot;. 4. Ogni data-chunk contiene, oltre ai dati, l'indicazione di: task a cui appartiene; status: inProgress/completed (relativo al data-chunk, non al task); numero d'ordine del data-chunk nel task; istanza su cui risiede il prossimo chunk (possibly NULL, se è l'ultimo data- chunk del task) istanza su cui risiede il precedente chunk (possibly NULL, se è il primo data- chunk del task) MIGRAZIONE La migrazione di un Task da un'istanza A ad un'istanza B deve essere implementata sul controllore come segue: 1. su A: preleva descrittore 2. su B: crea descrittore 3. su A: termina e collega a B 4. su B: collega ad A 5. sul controllore: aggiorna la tabella dei Task Se si verifica un errore (guasto) durante l'operazione, all'operatore viene mostrato il messaggio quot;non so se è stata eseguitaquot;. Il tutto funziona perché: guasto tra 1 e 2, l'operazione non è stata eseguita; guasto tra 2 e 3, il repair thread rileverà, quando analizza l'istanza B, che il controllore ritiene che il Task risiede su A mentre in realtà risiede su B; pertanto il repair thread: 47
  • 48. o verifica su A se il task è terminato e collegato a B; se si, esegue 4 e 5; o else, verifica su A se il task è terminato e collegato a un'istanza diversa da B; se si, elimina il Task da B; o else (task su A non terminato), esegue 3, 4 e 5 guasto tra 3 e 4 oppure tra 4 e 5, simile a quanto sopra A.2.3 ISTANZE OPERAZIONI ESPORTATE Ogni operazione viene eseguita in modo sincrono (il chiamante si blocca sino alla ricezione della risposta). Da incapsulare in stateless bean Da raffinare i parametri, in particolare quelli di ritorno e le eventuali eccezioni createTask(IN task_id, IN altreComponentiDescrittore) terminateTask(IN task_id) per migrare un task da A verso B, si esegue getTaskDescr su A, create su B, terminateAndLink su A, linkFrom su B (vedi le note realizzative dei Task) terminateTaskAndLinkTo(IN task_id, IN instance_desc) linkFrom(IN task_id, IN instance_desc) getTaskDescr(IN task_id, OUT task_descr) getTaskDataChunk(IN task_id, OUT data_chunk) getTaskLastReading(IN task_id, OUT reading) getActiveTasks(OUT setOfTaskIds) (insieme di task quot;attiviquot;, per i quali cioè c'è il descrittore) getActiveTasksOnLine(OUT setOfTaskIds) (come il precedente, senza i task simulati) getActiveTasksSimulated(OUT setOfTaskIds) (come il precedente, per i soli task simulati) getAllTasks(OUT setOfTaskIds) (insieme di tutti i task, anche di quelli per i quali c'è solo un chunk e non un descrittore). getActiveWardens(OUT setOfWardenIds) (simile ai Task ma per gli Warden, un Warden attivo è uno per il quale c'è almeno un Task attivo) getAllWardens(OUT setOfWardenIds) getInstanceAlerts(IN date) (data dell'ultimo instance alert ricevuto; torna tutti quelli successivi a questa data) 48
  • 49. getContentAlerts(IN task_id, IN date) (idem, per il task specificato) getNetworkAlerts(IN task_id, IN date) (idem, per il task specificato) NOTE REALIZZATIVE 1. Ogni istanza contiene (almeno) uno scheduling thread ed un insieme di message bean. I message bean sono tutti identici, ognuno preleva un reading e lo valuta secondo quanto indicato nel messaggio di attivazione (ogni bean esegue automaticamente nel contesto di un thread). Lo scheduling thread si sveglia ad istanti regolari ed invia un messaggio opportuno ai vari bean, in base ai task in corso. 2. L'indice di carico cpuLoadIndex potrebbe essere legato alla quantità di tempo tra il completamento dell'ultimo message bean e il prossimo risveglio dello scheduling thread: più è piccolo questo tempo, maggiore è il load index. 3. Quando un message bean trova nella propria input queue più di un messaggio, significa che l'istanza è sovraccarica. (Documento redatto dal relatore prof. A. Bartoli, dal correlatore prof. E. Medvet e dal dott. G. Davanzo) 49
  • 50. 6 - FONTI Documentazione ufficiale di Java Standard edition (http://java.sun.com/javase/6/docs/) Documentazione ufficiale Java Entrerprise Edition 5 (http://java.sun.com/javaee/reference/index.jsp) Documentazione ufficiale GlassFish (https://glassfish.dev.java.net/docs/project.html) Documentazione ufficiale Shoal (https://shoal.dev.java.net/nonav/docs/api/) Documentazione ufficiale PostgreSQL (http://www.postgresql.org/docs/) Zone-H (http://www.zone-h.org) Tesi di laurea del dott. Giorgio Davanzo: Valutazione di algoritmi di anomaly detection per la rilevazione automatica delle intrusioni in siti web. Marco Mauri 50

×