\documentclass[a4paper,12pt]{report}
\linespread{1.5}
\usepackage{fancyhdr}
\usepackage[italian]{babel}
\usepackage{latexsym}
\usepackage{wrapfig}
\usepackage[all]{xy}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[pdftex]{color, graphicx}
\usepackage[hmargin=1.5cm,vmargin=2cm,twoside,bindingoffset=1cm]{geometry}
\pagestyle{empty}
\fancyhf{}
\renewcommand{\headrulewidth}{0.4pt}
\newcommand{\clearemptydoublepage}{\newpage{\pagestyle{empty}\cleardoublepage}}

\pagenumbering{roman}


\begin{document}
\title{Architetture di \emph{Grid Computing}}
\author{Nicola Baron}
\begin{center}
\LARGE{UNIVERSIT\`{A} DEGLI STUDI DI PISA}\\[0.65cm]
\large{Facolt\`{a} di Ingegneria}\\[0.65cm]
Corso di Laurea in Ingegneria delle Telecomunicazioni\\
\begin{figure}[h]
\vspace{0.25cm}
    \begin{center}
        \includegraphics{/tesi/CHERUBIN.pdf}
    \end{center}
\end{figure}
\large{TESI DI LAUREA}\\[0.75cm]
Progetto ed implementazione di un Grid Network Resource Broker per il supporto di applicazioni di
griglia \emph{network--aware}\\[2cm]
\end{center}
\begin{center}
\begin{tabular}[t]{l@{\hspace{4.8cm}}l}
\small{Relatori} & \small{Candidato}\\[0.5cm]
\small{Prof. Stefano Giordano} & \small{Nicola Baron}\\[0.85cm]
\small{Ing. Michele Pagano} & \\[0.85cm]
\small{Ing. Davide Adami} & \\[1.2cm]
\end{tabular}
\newline
Anno Accademico 2004 - 2005
\end{center}
\cleardoublepage \pagestyle{fancy} \pagenumbering{roman} \fancyfoot[RO,LE]{\thepage}
\fancyhead[LO,RE]{Indice} \addtocontents{toc}{\protect\thispagestyle{empty}} \tableofcontents
\pagenumbering{arabic} \fancyhead[LO,RE]{Prefazione} \fancyhead[RO,LE]{}
\fancyfoot[RO,LE]{\thepage}


\chapter{Il \emph{Grid Computing} }
\pagestyle{fancy} \thispagestyle{empty} \fancyhead[RO,LE]{Capitolo 1} \fancyhead[LO,RE]{\emph{Il
Grid Computing}} \fancyfoot[RO,LE]{\thepage}

\pagenumbering{arabic}

\section{Introduzione}
La sempre maggiore necessità di risorse di calcolo richiesta dai
moderni progetti di ricerca scientifica, negli ultimi anni sta
spingendo ad un notevole sviluppo delle tecnologie di \emph{Grid
Computing}. \\
Un esempio attuale di progetto di ricerca che richiederà capacità di calcolo ben superiori a quelle
attualmente disponibili è quello relativo alla costruzione del Large Hadron Collider al CERN di
Ginevra. Tale struttura viene spesso citata nei documenti relativi al \emph{Grid Computing}, in
quanto da quando entrerà in attività, nel 2007, produrrà una grandissima mole di dati, sia dal
punto di vista della quantità che della velocità con cui dovranno essere elaborati.
\begin{figure}[th]
\begin{center}
\includegraphics[width=0.9\textwidth]{/tesi/Capitolo1/LHCsurface.pdf}
\caption{\tiny Il progetto del sito superficiale per il \emph{Large
Hadron Collider}.}
\end{center}
\end{figure}
Fino dagli anni '80 l'idea di utilizzare i tempi di inattività delle centinaia di elaboratori
presenti in grandi università e istituti di ricerca per fornire risultati utili a progetti
scientifici con alti carichi computazionali, è stata perseguita attraverso alcuni fruttuosi tentativi \emph{ad~hoc}. \\
In particolare, un'ottima realizzazione di tale idea è quella legata al progetto \emph{SETI@home},
che, sfruttando l'efficace connettività fra Personal Computer realizzatasi nel nuovo millennio, ha
accumulato \emph{donazioni} in cicli di clock per migliaia di anni di tempo di calcolo. SETI@home è
un esperimento scientifico che utilizza computer connessi ad Internet nella ricerca di forme di
vita extraterrestri. Chiunque sia connesso alla rete e possieda un PC, in sostanza, può partecipare al progetto eseguendo un'applicazione gratuita che scarica e analizza dati provenienti dai radio telescopi \cite{seti}. \\
\begin{figure}[th]
\begin{center}
\includegraphics[width=0.7\textwidth]{/tesi/Capitolo1/seti.png}
\caption{\tiny Il sito che riporta le statistiche di risultati forniti al progetto SETI@home}
\end{center}
\end{figure}
Il funzionamento di SETI@home, tuttavia, dipende dalla presenza sugli elaboratori dell'applicazione
client, la quale è stata realizzata specificamente per questo scopo. Ciò impedisce di utilizzare le
risorse di calcolo dinamicamente secondo le necessità che si presentano oppure per finalità
differenti. Infatti, il loro sfruttamento è limitato all'attività per cui l'applicazione installata
sui client è stata sviluppata. Oggi si presenta la necessità di superare tale vincolo, consentendo
uno sfruttamento più flessibile delle risorse. L'idea alla base del \emph{grid computing} è quella
di costituire delle \emph{organizzazioni virtuali}, le quali collaborino condividendo in maniera
coordinata risorse di
calcolo e di storage, sfruttando reti di comunicazione ad alta capacità \cite{anatomy}. Tali organizzazioni vengono, in terminologia \emph{Grid} definite \emph{Virtual Organizations (VO)}. \\
Sono molteplici i campi in cui il \emph{grid computing} può portare grande sviluppo. In particolare
vengono citati, oltre alla ricerca scientifica, aree legate al \emph{drug discovery}, all'analisi
del rischio finanziario e alla progettazione di nuovi prodotti \cite{ogsa}. La realizzazione di
sistemi per il \emph{grid computing} introduce nuove difficoltà e la necessità di nuova ricerca
teorica e sviluppo software per fronteggiare le numerose problematiche introdotte dalla gestione di
un ambiente così eterogeneo e contemporaneamente così integrato.

\section{\emph{Grid Computing} e l'\emph{Open Grid Services Architecture}}
Sicuramente l'organizzazione di risorse - o \emph{servizi grid} - così eterogenee, richiede un
notevole sforzo di standardizzazione. \\
Tra il 1999 e il 2000, i principali gruppi di ricerca che cominciavano ad occuparsi di \emph{Grid
Computing}, hanno dato vita al \emph{Global Grid Forum (GGF)}; un'organizzazione costituita da
centinaia di ricercatori e gruppi di lavoro con lo scopo di sviluppare nuovi standard e coordinare
gli sforzi di ricerca. Il \emph{Global Grid Forum}, attraverso i suoi \emph{Working Group},
mantiene i contatti con il mondo della ricerca e dell'industria. La discussione portata avanti con
la collaborazione degli istituti di ricerca, è arrivata alla definizione della \emph{Open Grid
Services Architecture (OGSA)}. OGSA è la principale linea guida per il raggiungimento della
standardizzazione richiesta ai vari componenti grid che costituiscono le \emph{Virtual
Organization}. \\
OGSA analizza ed identifica otto categorie di servizi ad alto livello, all'interno delle quali sono
state individuate e definite interfacce di programmazione e di comunicazione che, se implementate
da tutti i sistemi, consentono l'integrazione delle \emph{Virtual Organization}. \\
Le categorie identificate nell'architettura OGSA, così come vengono pubblicate nel documento
ufficiale del GGF \cite{ogsa} sono:
\begin{itemize}
  \item \textbf{Infrastructure Services} \\ Servizi di intercomunicazione tra le risorse condivise.
  \item \textbf{Resource Management Services} \\ Controllo, allocazione e distribuzione delle risorse.
  \item \textbf{Data Services} \\ Trasferimento dati, inclusa la conversione.
  \item \textbf{Context Services} \\ Descrizione e politiche di utilizzo delle risorse in funzione del
  contesto e dell'utilizzatore.
  \item \textbf{Information Services} \\ Servizi di informazione sullo stato ed il funzionamento della
  griglia.
  \item \textbf{Self-Management Services} \\ Gestione della efficienza e della complessità del sistema.
  \item \textbf{Security Services} \\ Servizi di sicurezza ed autenticazione all'interno della Virtual
  Organization.
  \item \textbf{Execution Management Services} \\ Gestione dell'esecuzione delle applicazioni.
\end{itemize}
Alla base delle proposte del GGF, si trova sempre il tentativo di favorire standard consolidati,
semplici e già largamente implementati, specialmente per quanto riguarda i servizi di comunicazione
\emph{intra--grid}. Ciò contrasta con l'approccio, preso seriamente in considerazione negli anni
'90 e poi abbandonato, della necessità della creazione di un vero e proprio sistema operativo
finalizzato alla realizzazione di griglie di calcolo. In realtà tale necessità svanisce nel momento
in cui vengono definiti ed implementati protocolli standard ed interfacce di comunicazione che
consentano il coordinamento e la condivisione sicura dei servizi.\\
L'intera struttura di OGSA, vede alla base questo principio, ed è stata interamente progettata per
favorire lo sviluppo di applicazioni realizzate tramite l'integrazione di componenti che
interagiscono in maniera dinamica e variabile. \\
Nell'approccio grid indicato dal GGF, ogni problema viene scomposto in \emph{servizi} atomici, che
vengono attivati sotto il coordinamento di un \emph{Grid Manager}. Il \emph{Grid Manager}
interpreta le richieste dell'applicazione, distribuendone le necessità sui \emph{provider} di servizio disponibili. \\
I \emph{servizi} possono essere rappresentati sia da risorse software - generalmente sotto forma di
procedure di calcolo - sia da risorse hardware, nella forma di storage o cicli di clock utilizzabili. \\
L'accesso  ai servizi avviene, secondo l'indicazione di OGSA, tramite interfacce di programmazione
che ogni servizio deve esporre per poter entrare a far parte attivamente del sistema di griglia. \\
La comunicazione fra un servizio e l'altro invece, avviene attraverso i protocolli di trasporto
consolidatisi nel mondo Internet, in particolare il TCP. \\
Questa impostazione consente di introdurrre un elevato livello di astrazione nella progettazione
delle applicazioni, le quali risulteranno definite da un flusso di interazioni successive fra i
servizi di griglia. Ognuno dei servizi può rappresentare sia un'operazione concettualmente atomica,
sia una tradizionale procedura software che elabora dati producendo un risultato. \\
Questa impostazione a diagramma di flusso, deve naturalmente tenere conto di molti vincoli dovuti
alla sincronizzazione e al parallelismo di calcolo. Un'applicazione grid, infatti, cerca di
massimizzare il suo \emph{throughput} di elaborazione dati distribuendo il carico di lavoro nella
maniera migliore possibile in funzione della disponibilità di servizi, risorse, e del \emph{Service
Level Agreement} dell'utente. \\ Il \emph{Grid Manager} deve tenere conto del fatto che alcuni
passi dell'applicazione potranno essere eseguiti solo quando i precedenti servizi saranno
terminati, avendo reso disponibili i loro risultati. \\
Il \emph{Grid Manager}, per coordinare il funzionamento dei singoli servizi, ha a disposizione un
sistema di messaggistica asincrona, che interconnette, le varie componenti dell'applicazione. Tali
messaggi, sono tipici delle applicazioni, e sono indirizzati ai singoli servizi. OGSA, con il
\emph{Notification Framework}, definisce interfacce di messaggistica monodirezionale che consentono
sia di spedire messaggi, sia di ricerverne in maniera asincrona. L'approccio seguito è di tipo
multicast, in quanto il \emph{source} dei messaggi possiede di fatto un elenco a cui i servizi
interressati alla ricezione (denominati \emph{sink}) devono iscriversi. Periodicamente i
\emph{sink} devono notificare al \emph{source} che sono ancora interessati alla ricezione dei
messaggi, altrimenti vengono cancellati dall'elenco. Questo meccanismo può essere utilizzato, in un
contesto di comunicazione service-to-service, anche per sollecitare da parte del \emph{sink}
l'invio di un messaggio, tramite la sua iscrizione nell'elenco del \emph{source}.

\section{Gestione dei servizi in ambiente \emph{OGSA}}

\subsection{Identificazione e creazione dei servizi}

Il modello \emph{OGSA}, come si è visto precedentemente,  descrive le applicazioni in termini di
\emph{servizi} atomici, ognuno dei quali opera in un proprio ambiente, mantiene un proprio stato
che lo distingue da un'altra istanza dello stesso servizio, e comunica con l'esterno tramite
interfacce e protocolli prestabiliti. Tali interfacce definiscono formalmente ed identificano
univocamente un servizio grid. \\
Ogni servizio deve esporre un'interfaccia che ne consenta l'individuazione sul grid, la sua
attivazione e la gestione del suo ciclo di vita. I protocolli di interscambio dati, invece,
definiscono una semantica che, auspicabilmente, è implementata tramite
librerie standard, le cui funzioni sono richiamate, secondo le sintassi e convenzioni del linguaggio di programmazione utilizzato, dai vari servizi. \\
Tale approccio orientato ai servizi richiede un'orchestrazione globale del sistema, che, pur
lasciando ogni \emph{grid service} operare come un'unità a sè stante che riceve dati di input e
produce elaborazioni in output, identifichi e coordini le singole istanze dei processi in
esecuzione
istante per istante, e ne controlli lo stato di operatività. \\
Se, ad esempio, un servizio viene richiamato e durante l'esecuzione questo si interrompe senza
arrivare a comunicare un risultato al chiamante, quest'ultimo potrebbe - se non adeguatamente
notificato dell'evento - rimanere indefinitamente in attesa. \\
Il sistema di monitoraggio si deve dunque occupare del controllo di ogni singola istanza di un
servizio, il che richiede un metodo di identificazione delle istanze stesse, univoco relativamente
all'intero ambiente \emph{Grid}. A tal fine viene assegnato ad ogni istanza di servizio un
\emph{Grid Service Handle (GSH)}. I GSH sono unici sia nel tempo che nello spazio, sono tuttavia
gestiti in modo tale che se un meccanismo di \emph{recovery} a livello di coordinamento o
applicazione è in grado di ripristinare un servizio interrotto, mantenendone lo stato, al nuovo servizio non viene assegnato un nuovo GSH. \\
Per preservare l'espandibilità dei servizi e l'adeguamento a sempre nuovi protocolli, il GSH non è
determinato a partire da informazioni legate a protocolli di rete o trasporto, nè è progettato per
essere utilizzato con protocolli specifici. \\
La directory dei servizi istanziati e del
loro stato è perciò di tipo \emph{soft--state}, il che la rende attendibile in ogni momento. \\
Il GSH viene assegnato, al momento della creazione dell'istanza di un servizio, da un interfaccia
OGSA denominata \emph{factory}. L'interfaccia \emph{factory} non specifica \emph{come} un servizio
deve essere istanziato, e teoricamente possono esistere più \emph{factory} nello stesso ambiente. \\
I sistemi di griglia attuali prevedono un'interfaccia \emph{factory} utilizzata all'interno
dell'ambiente grid e comune per tutti i tipi di servizio.

\subsection{Durata e ciclo di vita dei servizi}

L'approccio \emph{soft--state} è utile anche dal punto di vista inverso rispetto al controllo dello
stato dei servizi. Infatti, essendo un servizio uno strumento che impiega risorse, è importante che
sia in qualche modo consapevole che c'è sempre un interesse da parte del chiamante verso l'attività
che sta compiendo. OGSA utilizza a questo scopo un valore di \emph{lifetime}, associato
inizialmente ad ogni istanza di servizio, e che ne rappresenta la durata massima di esecuzione. Se,
prima dello scadere del tempo di \emph{lifetime}\footnote{La necessità di una tale sincronizzazione
tra i servizi comporta l'esistenza di un \emph{tempo globale} del sistema grid. A tal fine viene
utilizzato generalmente il protocollo Network Time Protocol (NTP).}, il \emph{service container}
non riceve una affermazione di continuo interesse da parte del \emph{consumer}, distrugge il
servizio e dealloca le risorse. Il chiamante viene, naturalmente, anche informato di ogni
cambiamento di stato - terminazione inclusa - dal servizio stesso, in modo tale da poter sapere se
e quando l'elaborazione si è conclusa correttamente.\\
Questo meccanismo comporta che l'utilizzatore abbia sempre una visione chiara dello stato dei
servizi istanziati, e continui a interessarsi di quelli funzionanti, mentre prenda le opportune
contromisure nei confronti di quelli caduti o terminati in maniera inaspettata. \\
Tutto ciò, visto dall'ottica dell'ambiente complessivo di esecuzione, comporta invece che il
consumo di risorse possa essere sempre tenuto sotto controllo e adeguatamente bilanciato in maniera
dinamica.

\subsection{Discovery dei servizi}
Ad ogni servizio grid\footnote{I servizi grid vengono anche impropriamente indicati con il termine
\emph{Web services} in testi più orientati ad un linguaggio commerciale. Il termine \emph{web} è
dovuto al fatto che quasi universalmente i protocolli utilizzati per accedere a tali servizi sono
trasportati su HTTP. Un \emph{grid service} in realtà è più specifico di un \emph{web service}, in quanto per definizione deve esporre le interfacce di discovery, attivazione dinamica, gestione del \emph{lifetime}, notifica e manutenzione \cite{physiology}.} sono associate una serie di informazioni che ne agevolano l'identificazione. \\
Tali informazioni sono solitamente rappresentate attraverso documenti XML e registrate in un \emph{registry} globale. \\
I sistemi di griglia, mettono a disposizione servizi di ricerca e di richiesta di tali informazioni
attraverso interfacce basate principalmente su \emph{WSDL (Web Service Definition
Language)}\footnote{Si tratta di uno standard XML per la descrizione dei servizi Web che consente
la loro pubblicazione in un \emph{registry}.}. \\
Queste informazioni possono essere utilizzate per individuare la disponibilità di un particolare
servizio, attraverso richieste di attributi o interfacce, oppure attraverso dati più specifici
quali la disponibilità, l'utilizzo, l'accessibilità (figura \ref{wsdl}). \\
I messaggi che servono a mantenere aggiornato il \emph{registry} sono detti messaggi di
\emph{heartbeat}. Tali messaggi, rinnovando periodicamente il contenuto del \emph{registry}, lo
mantengono consistente. Se infatti non arriva al \emph{registry} il rinnovo della disponibilità di
un servizio, questo non viene più considerato utilizzabile. Tale approccio \emph{soft--state}
è molto solido in ambienti di rete a commutazione di pacchetto. \\
Una variante all'architettura OGSA, non completamente portatile, ma estremamente efficace in
ambienti con un numero particolarmente elevato di servizi disponibili, consiste nell'utilizzo di
messaggi multicast UDP, esplicitamente inviati dal client al momento della ricerca. \\
I servizi devono essere in grado di ricevere i pacchetti multicast e rispondere segnalando la loro presenza all'utilizzatore. \\
Seguendo questa tecnica, non è più necessaria la presenza di un \emph{registry} dei servizi.

\section{Evoluzione dei sistemi di griglia}

Come è stato descritto nei paragrafi precedenti, alla base dell'idea che ha condotto allo sviluppo
dei sistemi di griglia, c'è il concetto di \emph{Virtual Organization}. Questo concetto è legato
alla condivisione ed all'ottimizzazione nell'utilizzo di risorse disponibili in un certo numero di
elaboratori, senza imporre limiti fisici o geografici alla loro distribuzione. L'aggettivo
\emph{virtual} infatti è stato scelto in quanto le sue diverse sfumature di significato bene si
adattano a caratterizzare i sistemi di griglia. Le organizzazioni che si vengono a costituire nei
sistemi \emph{grid} infatti, possono essere definite virtuali in quanto si costituiscono al di
fuori dei limiti delle tradizionali associazioni pubbliche o private. \\
Sia sul piano dell'estensione che dell'accessibilità le Grid possono essere fondamentalmente
diverse. Si distinguono, inatti, griglie private oppure pubbliche; esistono griglie estese
geograficamente ed altre racchiuse in un stanza. Non esiste alcuna limitazione per la creazione e
l'identificazione di una Grid.
\begin{figure}[th]
\begin{center}
\includegraphics[width=0.9\textwidth]{/tesi/Capitolo1/evoluzione.png}
\caption{\tiny  Evoluzione delle "Grid"} \label{evoluzione}
\end{center}
\end{figure}
In Figura \ref{evoluzione} viene rappresentata un'ideale evoluzione delle "Grid". Una prima
organizzazione dei sistemi di Grid Computing può essere fatta coincidere con i cluster. I cluster
sono spesso definiti come file system distribuiti o come un gruppo di server omogenei aggregati al
fine di incrementare le prestazioni. Il ruolo fondamentale che i cluster hanno svolto
nell'evoluzione delle Grid, nonostante ne rappresentino solo uno stadio simbolico, rimane
innegabile. La seconda fase dell'evoluzione dei sistemi di Grid Computing può essere identificata
con la nascita delle intra--grid. Queste, in generale, rispondono alla necessità di interconnettere
più cluster. Con la creazione delle intra--grid si è reso necessario per la prima volta il
controllo del livello network. Tramite l'introduzione di un \emph{middleware} di griglia, si
riescono ad affrontare e risolvere indipendentemente dall'applicazione problematiche di allocazione
delle risorse, autenticazione degli utenti e dei servizi, sicurezza. \\
Le intra--grid rappresentano lo stato dell'arte nell'evoluzione dei sistemi di Grid Computing. Un
esempio di intra--grid può essere rappresentato da due o più cluster appartenenti a differenti
dipartimenti all'interno di una stessa organizzazione, al fine di condividere una serie di dati e
di incrementare la capacità di processing. Attualmente, in questo scenario, le problematiche di
sicurezza e di autenticazione, ugualmente importanti, non sono critiche. Le relazioni fra i
cluster, infatti, rimangono confinate all'interno di uno stesso dominio. \\
\begin{figure}[th]
\begin{center}
\includegraphics[width=0.9\textwidth]{/tesi/Capitolo1/gridcafe.png}
\caption{\tiny La home page del sito divulgativo del CERN per l'informazione di base sul Grid
Computing. Si cerca di portare il Grid Computing al di fuori del mondo accademico.}
\label{gridcafe}
\end{center}
\end{figure}
L'evoluzione successiva conduce alla definizione delle extra--grid. Le extra--grid sono
essenzialmente cluster grid e/o intra--grid connesse fra loro e appartenenti a siti geograficamente
distribuiti all'interno di una stessa organizzazione, o fra organizzazioni distinte. In tale
contesto, dal momento che sia il processing che i dati possono essere condivisi tra differenti
organizzazioni, l'autenticazione, il policing management, e la sicurezza diventano requisiti
critici che il \emph{middleware} deve supportare. Per assicurare le prestazioni sono importanti
anche l'introduzione di algoritmi per il \emph{load balancing} multi--site, la conoscenza della
topologia della rete, e dei servizi esistenti. Lo stadio finale dell'evoluzione del Grid Computing
è l'inter--grid. Questo stadio è il più importante perché rappresenta due delle principali visioni
del grid computing: l'infrastruttura delle utility e i grid service/service provider. Attualmente
non è presente una prospettiva commerciale di questo stadio finale. Le inter--grid sono oggi al
centro della ricerca e dello sviluppo. Le inter-grid superano in complessità di gran lunga le altre
fasi dell'evoluzione. Gli utenti di una inter--grid possono essere fino a centinaia o migliaia,
quindi in numero notevolmente superiore ai due o tre partecipanti di una intra--grid. Ne consegue
un notevole incremento della complessità sia del middleware che nel controllo del livello network.
I cluster grid attualmente esistenti, si evolveranno, prossimamente, come intra--grid nel mondo
commerciale. Le complesse inter--grid sono al centro della ricerca e quindi in fase di sviluppo e
di testing. Questi sono segni che il mercato si sta muovendo in questa direzione, e la chiave del
successo sarà lo sviluppo di tecnologie che evolvano di pari passo con le richieste del mercato.

\section{Globus nell'architettura OGSA}

Fino ad ora, si è discusso genericamente di \emph{sistemi di griglia}, e si è introdotto il
concetto di \emph{middleware}, descrivendone per sommi capi il modello architetturale OGSA ormai standardizzato. \\
La definizione di OGSA ha prodotto lo sviluppo di \emph{middleware} che implementa le funzionalità
del sistema di griglia aderendo alla specifica OGSA. \\
\emph{Globus} costituisce quello che viene denominato un \emph{hosting environment}, cioè un
ambiente software di esecuzione all'interno del quale i servizi vengono istanziati. L'\emph{hosting
environment} definisce il modello ed il linguaggio di programmazione, gli strumenti di sviluppo e
mette a disposizione le librerie necessarie all'implementazione delle interfacce adeguate alla
semantica del
\emph{Grid}. \\
Tale semantica, come si è detto, è definita da OGSA: interfacce di creazione, controllo e
comunicazione dei servizi. OGSA non definisce requisiti su come un servizio viene eseguito o sugli algoritmi. \\
\emph{Globus} è basato sul sistema operativo ospite quale ambiente di esecuzione. Di conseguenza
istanzia processi in risposta alle richieste di servizio. \'E dunque il sistema operativo a gestire
l'esecuzione dei servizi, mentre il \emph{Globus Toolkit} mette a disposizione i comandi
necessari all'attivazione e al controllo del loro ciclo di vita. \\
In tale contesto, la disponibilità di innumerevoli linguaggi di programmazione, offre una
molteplicità di possibilità per l'implementazione dei servizi. Ogni linguaggio che disponga di un
compilatore o di un interprete compatibile con il sistema operativo scelto come \emph{hosting
environment} può essere utilizzato. \'E necessario in ogni caso scegliere un linguaggio per cui sia
disponibile una libreria che implementi la semantica dell'ambiente
\emph{Grid}. Ciò è a maggior ragione vero in un contesto di manutenibilità a lungo termine dell'applicazione. \\
La scelta implementativa di \emph{Globus} è legata ad una filosofia \emph{open--source} ed
altamente orientata ad applicazioni scientifiche, che perciò richiedono grande efficienza
nell'esecuzione. Non inserire un \emph{container} ulteriore, riducendo il \emph{middleware} fra il
processore ed il servizio, aumenta l'efficienza dei processi e diminuisce l'impiego di risorse.


\begin{figure}[hbt]
\begin{center}
\includegraphics[width=1\textwidth]{/tesina/discovery.png}
\caption{\tiny Funzionamento del registro WSDL in architettura OGSA.} \label{wsdl}
\end{center}
\end{figure}

\section{I componenti di Globus}

L'architettura di \emph{Globus} è organizzata secondo componenti sovrapposti secondo la struttura a
strati rappresentata in figura \ref{j2ee2}. I componenti di ogni strato condividono
caratteristiche comuni e completano le funzionalità dei livelli inferiori esattamente come accade nel modello a strati del TCP/IP. \\
Complessivamente si può individuare, nella sovrapposizione degli strati, una struttura a
\emph{clessidra}, il cui restringimento centrale rappresenta quelle astrazioni e quei protocolli
(in particolare TCP e HTTP) che consentono un elevato livello di connettività fra diversi elaboratri collegati tramite reti geografiche. \\
Il punto di forza di questo modello architetturale, infatti, consiste proprio nella possibilità che
molteplici applicazioni - allo strato più alto - e molteplici software per il controllo diretto
delle risorse - allo strato più basso - siano connettibili tramite pochi protocolli di trasporto.
\begin{figure}[hbt]
\begin{center}
\includegraphics[width=0.7\textwidth]{/tesina/gridarch.png}
\caption{\tiny L'architettura a strati dell'ambiente \emph{Grid} e la sua %%@
correlazione con il modello ISO/OSI.} \label{j2ee2}
\end{center}
\end{figure}

In generale, il posizionamento degli strati dell'architettura di Globus, segue l'andamento degli
strati del protocollo TCP/IP. Le \emph{applicazioni}, che si trovano nella zona più alta della
clessidra, sfruttano i servizi di \emph{gestione delle risorse} e di \emph{connettività}. Questi a
loro volta sfruttano implementazioni specifiche dei servizi di gestione dell'hardware. Tale ultimo
livello, di controllo diretto della macchina, viene detto strato \emph{Fabric}. \\
Chiave di un buon funzionamento di tutto il sistema in ambito molto eterogeneo, è il numero ridotto
di protocolli definiti nello strato di \emph{connettività} e la loro collaudata solidità e
diffusione.

\section{I protocolli \emph{Inter--Grid}}

Secondo il modello a clessidra è auspicabile che un minimo numero di interfacce consolidate vengano
utilizzate per specifiche funzionalità. Queste vengono definite nell'architettura generale solo in
astratto. Così, ad esempio, è possibile utilizzare nel contesto Globus differenti meccanismi di
sicurezza per il controllo degli accessi o la crittografia, nel momento in cui esistono API
standardizzate che nascondano tale varietà di implementazioni al livello superiore. Ciò tuttavia,
seppure risolva il problema della portatitilità e gestibilità delle applicazioni, ancora non
consente l'interoperabilità. \\
Infatti, relativamente all'esempio precedente, lo stesso codice implementato al livello applicativo
non può funzionare se i pacchetti
sono criptati con algoritmi differenti. \\
Come evidenziato dallo studio dell'architettura protocollare di \emph{Globus}, l'interoperabilità
richiede una definizione rigida di
pochi ed efficaci protocolli per il trasporto di rete. \\
Chiave del funzionamento del sistema \emph{Grid} è insomma la selezione e l'accettazione di un
insieme consolidato di protocolli negli strati di \emph{Connettività} e \emph{Gestione risorse}. \\
I protocolli definiti \emph{Inter--grid} nella terminologia OGSA, sono quelli che consentono lo
scambio di informazioni e gestione risorse fra il più vasto numero
possibile di elaboratori eterogenei. \\
Naturalmente la soluzione più semplice è stata quella di selezionare protocolli già largamente e
comunemente utilizzati ai diversi strati del modello ISO/OSI: IP, TCP, HTTP. \\
Per portare un esempio di utilizzo ormai comune su protocolli Internet di un semplice sistema che
rientra pienamente nella definizione di \emph{Grid}, si pensi ai software di condivisione file
peer--to--peer correntemente assai diffusi. Essi, di fatto, costituiscono un sistema di storage
virtuale accessibile contemporaneamente da molteplici utenti, i quali costituiscono una Virtual
Organization. Tuttavia tali sistemi risultano sempre molto specifici e verticalizzati ad un
contesto specifico, il che ne ha di fatto bloccato lo sviluppo.

\section{Protocolli standard di gestione servizi}

Di fatto, si è detto che i servizi Grid e le \emph{Application Programming Interface} per la loro
gestione possono operare attraverso differenti protocolli di comunicazione e interscambio dati.
Tuttavia è opportuno evidenziare un insieme di tecnologie che si stanno affermando come standard di
fatto per la gestione e comunicazione fra servizi grid.
\begin{itemize}
\item{\emph{XML (Extensible Markup Language)}: è alla base
dell'interscambio dati fra servizi. XML è un meta-linguaggio per la definizione formale di
grammatiche rappresentanti dati strutturati. Il successo di XML consiste nel fatto che può sia
definire la semantica del protocollo, sia contenere l'informazione vera e propria. Un unico SDK,
fornendo lo strumento per implementare sia i documenti XML, sia la loro descrizione, consente
dunque un maneggevole approccio al problema della continua definizione di nuovi tipi di dati.}
\item{\emph{WSDL (Web Service Description Language)}: è lo standard per
l'\emph{esposizione} di un servizio web nel registry dell'hosting environment. \'E basato su una
semantica di tipo XML. }
\item{\emph{UDDI (Universal Description Discovery and Integration)}: è il
protocollo vero e proprio per la comunicazione con un registry di servizi. \'E lo strumento che
consente di trovare servizi e risorse in un \emph{Grid}. }
\item{\emph{SOAP (Simple Object Access Protocol)}: è un protocollo
semplice e leggero, basato su XML, che consente lo scambio di messaggi fra servizi grid. Il
messaggio SOAP contiene al suo interno tutto ciò che è necessario sapere riguardo la codifica dei
dati trasmessi e le convenzioni utilizzate nella chiamata a metodi remoti. I messaggi SOAP possono
essere utilizzati per creare istanze di servizi e riceverne il risultato dell'elaborazione. }
\item{\emph{HTTP (HyperText Transfer Protocol)}: è un protocollo di tipo
query--response, utilizzato attualmente per il trasferimento di pagine web. \'E particolarmente
efficace se usato in combinazione con SOAP in quanto non introduce rischi particolari di sicurezza
e non viene filtrato dai firewall aziendali. }
\end{itemize}

\chapter{Sistemi grid e problematiche di rete}
\pagestyle{fancy} \thispagestyle{empty} \fancyhead[RO,LE]{Capitolo 2} \fancyhead[LO,RE]{Sistemi
grid e problematiche di rete} \fancyfoot[RO,LE]{\thepage}


A causa dello sviluppo dei sistemi di Grid Computing e del sempre più impellente bisogno di
efficienti ed economiche tecniche per il calcolo distribuito, lo studio e lo sviluppo di tecnologie
e metodologie adatte per gestire sia le applicazioni grid-aware sia l'interfacciamento tra tali
applicazioni (e, più in generale, il middleware di Grid) e le reti di trasporto sta subendo un
notevole impulso. L'obiettivo sperimentale, che molti gruppi di ricerca, più o meno
coordinatamente, intendono perseguire, è di progettare e sviluppare sistemi efficienti ed il più
standardizzati possibile, per garantire un utilizzo delle risorse remote di calcolo e di storage
con requisiti di high performance all'interno di strutture di tipo Grid. \\
Per creare un'interfaccia univoca tra le applicazioni grid-aware e le risorse di griglia occorre
definire e implementare nuovi moduli funzionali che consentono di astrarre il più possibile i
servizi offerti dall'infrastruttura di griglia sottostante. È quindi necessario progettare
meccanismi di ricerca, monitoraggio e gestione delle risorse presenti nella griglia e richieste
dall'applicazione. A tal fine è stato proposto l'utilizzo, nelle griglie di calcolo di un
\emph{Grid Abstract Manager (GAM)}. Il Grid Abstract Manager rappresenta il modulo funzionale in
grado di offrire un'interfaccia uniforme dei vari strumenti messi a disposizione dal middleware di
griglia agli sviluppatori di applicazioni grid-aware per raggiungere il più alto livello di
astrazione possibile dell'infrastruttura sottostante. Infatti il Grid Abstract Manager si prefigge
lo scopo di automatizzare i passi comuni necessari per avviare il maggior numero di applicazioni
grid--aware. \\
\section{Introduzione al Grid Network Resource Broker}
Recentemente è emersa la necessità di inserire tra i servizi offerti dalla griglia alcuni servizi
di rete (come precisato nei documenti del Grid High Performance Networking Group (GHPNG-RG)). I
servizi di rete, chiamati nell'ambito del GHPNG grid network services, permettono agli utenti di
griglia di interagire con l'infrastruttura di rete. I seguenti grid network services sono
considerati fondamentali dal GHPNG per l'integrazione con i servizi forniti dall'infrastruttura di
griglia:
\begin{itemize}
\item{\textbf{Network Information e Monitoring Service}: fornisce informazioni riguardo alla topologia di rete
che collega i nodi della griglia coinvolti nella Virtual Organization con riferimento anche a
caratteristiche di tali collegamenti (banda, latenza etc.).}
\item{\textbf{Network Cost Estimation Service}: fornisce algoritmi di calcolo per determinare la topologia fisica di collegamento tra i nodi di
griglia in base ad una specifica funzione costo.}
\item{\textbf{Connectivity Service}: fornisce la capacità di allocare sulla rete le risorse necessarie per garantire la connettività tra i nodi di
griglia.}
\end{itemize}
Lo scopo di questo documento è quello di proporre un progetto ed un prototipo di implementazione di
sistema che comprende i servizi di rete sopra descritti. Non potendo demandare tali compiti ad
un'estensione del Grid Abstract Manager, dobbiamo, in qualche modo, garantire delle procedure per
l'invocazione dei servizi di rete da parte dello stesso GAM. Introdurre delle metriche di rete
(e.g. banda disponibile e/o garantita, latenza minima garantita, etc.) durante la fase di mapping
del GAM (decisione di associazione tra risorse e processi), può rilevarsi un requisito fondamentale
per consentire l'associazione degli archi appartenenti al grafo generale che rappresenta
l'applicazione con le risorse di rete della griglia computazionale. In prima istanza, questo
significa progettare un modulo funzionale che preveda un meccanismo di segnalazione che il Grid
Abstract Manager, tramite un'invocazione diretta, utilizzi per negoziare e richiedere l'attivazione
di uno specifico grid network service. In questo lavoro si propone un Grid Network Resource Broker
(GNRB) come collettore e interfaccia dei grid network services. La proposta si basa su un modello
overlay delle reti nel quale il \emph{middleware} di griglia vede la rete come una black box che
provvede alla definizione e alla gestione di servizi, anche dinamici, utilizzabili dai potenziali
utenti.
\begin{figure}[hbt]
\begin{center}
\includegraphics[width=0.7\textwidth]{/tesi/Capitolo1/qr.png}
\caption{\tiny Meccanismo di query - response} \label{qr}
\end{center}
\end{figure}
Infatti, il GNRB, tramite un paradigma di comunicazione client/server (come da Figura \ref{qr}),
consente all'utente di griglia di richiedere differenti servizi di rete, che, partendo dalla
definizione generale data dal GHPNG, sono:
\begin{itemize}
\item{Topology Discovery Service}
\item{Network Resource Allocation Service}
\item{Network Information Service}
\end{itemize}
Oltre alla definizione di un meccanismo di invocazione dei servizi, basato su semantica XML, il
Grid Network Resource Broker deve prevedere funzionalità di monitoring, collecting, elaboration e
storage delle informazioni di rete ricavate da opportuni sensori di misura. Ovviamente la gestione
delle richieste da parte del GNRB deve comprendere sia un protocollo di accesso che meccanismi di
sicurezza che garantiscano la consistenza delle informazioni sullo stato e l'utilizzo della rete.
Inoltre, dal momento che la natura distribuita dei sistemi di Grid Computing rende inevitabile un
aumento della complessità passando da una intra--grid ad una inter--grid topology, requisiti
basilari per qualsiasi piattaforma di griglia come la sicurezza, l'affidabilità, le prestazioni
fornite e i servizi di directory diventano più complicati da gestire. La memorizzazione delle
informazioni sullo stato della rete e la conoscenza della topologia della rete comportano
ovviamente problemi di scalabilità e disponibilità di informazioni (legate soprattutto alla
presenza di differenti gestori di rete). Nella letteratura classica, la soluzione a questo problema
viene affrontata utilizzando due scenari possibili: utilizzo di sistemi centralizzati con una
organizzazione gerarchica oppure utilizzo di sistemi distribuiti. Nel nostro progetto abbiamo
scelto di organizzare gerarchicamente i Grid Network Resource Broker (vedi Figura \ref{gera}) in
modo da evitare tutte le problematiche legate all'eterogeneità e all'interoperabilità degli
apparati di rete sia sulle reti di accesso che sulla backbone.
\begin{figure}[hbt]
\begin{center}
\includegraphics[width=0.9\textwidth]{/tesi/Capitolo1/gera.png}
\caption{\tiny Organizzazione gerarchica dei GNRB} \label{gera}
\end{center}
\end{figure}
Un Network Discovery Service deve essere in grado di soddisfare richieste relative alla
caratterizzazione, in termini di metriche prestazionali, dei collegamenti, a livello rete, che
esistono o possono essere garantiti tra due risorse di calcolo utilizzate da applicazioni
grid--aware. In questo modo, per esempio, il Grid Abstract Manager può invocare tale servizio per
ottimizzare, rispetto ai parametri di rete, il mapping dei moduli delle applicazioni sulle risorse
di calcolo. Infatti, la topologia virtuale che il Network Discovery Service restituisce al Grid
Abstract Manager contiene una descrizione dei collegamenti pesati rispetto ad una o più metriche
(e.g. banda, latenza) di rete. \\
In definitiva, introdurre il Topology Discovery Service tra i servizi messi a disposizione di una
griglia computazionale permette di effettuare un mapping completo del grafo logico
dell'applicazione, anche relativamente ai suoi archi di collegamento, sulle risorse fisiche della
griglia. Il Topology Discovery Service può fornire una topologia virtuale determinata in base alle
richieste di allocazione del servizio seguendo le richiesre dell'applicazione e verificando il
rispetto del Service Level Agreement fra l'utente e il provider dei servizi di griglia. Sulle
modalità previste per l'allocazione delle risorse, si rimanda al capitolo successivo, nel quale si
scenderà nel dettaglio dell'architettura GNRB e della descrizione dei suoi modi di funzionamento.
\\
Il GNRB deve implementare anche algoritmi di decisione che, sfruttando le informazioni sulla rete e
la conoscenza della topologia fisica costruiscono grafi pesati e calcolano i percorsi migliori in
rispetto alla caratteristica pervenuta tramite la query dell'utente. Inoltre tali algoritmi devono
garantire che il GNRB sia in grado di decidere se una nuova richiesta può essere mappata
all'interno dell'attuale configurazione di rete o se è necessario cambiare la configurazione
oppure, infine, se rifiutare la richiesta per l'impossibilità di garantire il servizio.
\\
Il Grid Abstract Manager, come specificato precedentemente, deve implementare funzionalità per il
monitoraggio e la gestione dell'esecuzione dell'applicazione grid--aware nel suo complesso. Per
tale scopo, i servizi di monitoraggio delle risorse di rete e la configurabilità dinamica della
connettività tra le risorse fisiche della griglia forniti dal Grid Network Resource Broker
diventano, tramite un Network Information Service, uno strumento adeguato a disposizione del stesso
GAM. Ad esempio, sarà possibile durante l'esecuzione di un'applicazione grid--aware soddisfare
richieste di variazione in termini di prestazioni di rete ( e.g. banda, latenza ) tra due risorse
di calcolo impegnate.

\section{Monitoraggio delle risorse di rete}
Lo sviluppo di un meccanismo di gestione delle risorse di rete, prevede un'uniformità nella
definizione delle misure che vengono effettuate e valutate dal \emph{middleware}. \\
I meccanismi per la misurazione delle grandezze caratterizzanti le prestazioni di una rete di
calcolatori in un determinato intervallo temporale, si sono sviluppati nel corso degli anni
attraverso le ricerche e le implementazioni software di diversi gruppi di studio nel mondo. \\
Infatti l'affinamento degli algoritmi utilizzati per la rilevazione di quei parametri che sono
diventati di uso quotidiano per i progettisti e i tecnici che operano su reti a commutazione di
pacchetto, spesso ha seguito lo sviluppo di strumenti software concepiti proprio al fine di
ricavare tali grandezze. \\
La rapidità di sviluppo e la diffusione negli ultimi anni delle reti (che hanno raggiunto persino
l'utenza domestica al punto di diventare parte della quotidianità) sono, d'altra parte, sia causa,
sia conseguenza di questa metodologia di innovazione così capillare, eterogenea e
geograficamente estesa. \\
Quando si giunge, tuttavia, al punto in cui le nuove necessità del progresso tecnologico richiedano
una sintesi organica delle esperienze e delle competenze maturate da diversi gruppi di ricerca, è
necessario cercare di trovare una solida base concettuale e teorica su cui si possano appoggiare i
diversi studi effettuati sino al momento e al contempo una struttura formale atta all'utilizzo
sistematico dei risultati ottenuti e al loro studio ed approfondimento in termini
omogenei e scientificamente corretti. \\
In relazione al problema della valutazione dello stato della rete finalizzata all'ottimizzazione
dei processi di grid computing, la necessità di una standardizzazione si sente fin dalla
variabilità di interpretazione e di scelta legata a quali siano i parametri da monitorare nel
tempo. \'E risultato presto chiaro, insomma, che fosse necessario accordarsi  su terminologie e
convenzioni che consentissero a chiunque utilizzasse un sistema così disomogeneo come è per sua
natura il \emph{Grid}, sia di interpretare correttamente i dati messi a disposizione dal sistema
stesso, sia di sapere dove e come ricercarli. \\
Un esempio calzante riguarda i termini \emph{bandwidth} e \emph{bitrate}\footnote{Questo esempio è
ricavato dalla trattazione del problema della misurazione della banda in \cite{events}}: ci sono
almeno quattro aspetti che caratterizzano l'interpretazione del termine. Si può infatti
interpretare la banda nei suoi significati di \emph{capacità}, cioè la massima quantità di dati per
unità di tempo che un percorso può trasportare oppure di \emph{capacità istantanea} intesa come
massima quantità di dati che può transitare dato il corrente
utilizzo. \\
Si può tuttavia anche intendere per banda l'\emph{utilizzo}, nel senso di traffico che
correntemente impegna il percorso, misura che si può ottenere piuttosto facilmente da quasi tutti i
modelli di router, interrogandoli tramite il protocollo SNMP. Nel contesto più specifico della
ricerca della qualità di servizio, spesso si utilizza il significato di \emph{banda disponibile}
interpretata come la capacità trasmissiva che il percorso può sopportare, stabiliti i protocolli,
le applicazioni e l'andamento dei flussi nel
tempo. \\
Bisogna in ogni caso tenere presente che quando si vogliono trasmettere dati, i protocolli
utilizzati introducono un \emph{overhead} che diminuisce il valore netto di bit trasferiti per
unità di tempo. Limitandoci al caso di utilizzo di reti IP, si può sicuramente affermare che è
necessario specificare quale protocollo di trasporto si sta prendendo in
considerazione nell'eseguire la misura. \\
Questo esempio mostra quale sia il valore di incertezza riguardo alla terminologia comunemente
utilizzata in quei contesti eterogenei che tuttavia trovano un denominatore comune nel costituire
un sistema di \emph{grid computing}.  \\
Il \emph{Network Measurements Working Group (NMWG)} si è occupato e si occupa attualmente di
trovare schemi standardizzati che consentano l'osservazione e la pubblicazione di grandezze di rete
utili
all'interno dell'ambiente Grid. \\
Il gruppo Internet Protocol Performance Metrics (IPPM) di IETF si occupa, più specificamente, degli
algoritmi di misura più appropriati in relazione ai vari parametri in osservazione, e definisce i
metodi migliori per ottenere tali misurazioni. \\
I due gruppi lavorano, nell'ottica Grid, in collaborazione, ma su ambiti comunque diversi.

\section{Approccio metodologico alle misure di rete}

Nel disegnare un'applicazione distribuita, il progettista prende decisioni riguardo le opzioni che
l'applicazione ha per meglio adattarsi alla rete, come valutarle e quali siano più significative.
Generalmente chi opera al livello \emph{Application} del Grid, deve disporre di tali
informazioni. \\
L'approccio seguito dal NMWG nel mettere a disposizione del programmatore
gli strumenti necessari a sviluppare servizi \emph{grid} è quello di %%@
basarsi sulla grande quantità di librerie già esistenti e coordinarne %%@
l'utilizzo. \'E infatti un dato di fatto che le numerose API sviluppate %%@
per la misurazione ed il controllo di rete siano molto eterogenee fra di %%@
loro, in quanto sviluppate concentrando l'attenzione dei vari gruppi di %%@
lavoro su specifici problemi, senza la presenza di uno schema di sviluppo %%@
generale omogeneo. \\
Il draft \cite{events} cerca di individuare una classificazione comune di %%@
osservazioni di rete realizzate da differenti sistemi e metterla a %%@
disposizione degli sviluppatori. Il NMWG ha presentato un sistema di %%@
nomenclatura necessario per la presentazione e la ricerca %%@
(\emph{discovery}) di molteplici dati di misurazione in un sistema di %%@
informazione generalizzato per l'ambiente \emph{Grid}. \\
Nell'ambito dell NMWG è tuttavia uno scopo chiaramente prefissato quello %%@
di non impedire o rallentare lo sviluppo di nuovi e sempre più efficienti %%@
algoritmi o software per il monitoraggio o il probing delle reti. Viene %%@
anzi incoraggiata la massima creatività, seppure - come è nello spirito %%@
del \emph{Grid} - all'interno di standard e protocolli ben definiti.

\section{Principio base della nomenclatura}

La considerazione più intuitiva, su cui si basa l'intero sistema di nomenclatura, è l'esistenza in ogni rete di \emph{entità}, che vengono descritte tramite \emph{caratteristiche} della rete (figura \ref{ce}). \\
\newline
Più esplicitamente, un \emph{entità} è un componente della rete visto ad %%@
un determinato livello della pila ISO-OSI come mostrato nella figura %%@
\ref{l23}. Un \emph{percorso} o un \emph{router} sono entità di una rete %%@
considerata a livello \emph{network}, uno \emph{switch} è un'entità di %%@
una rete considerata al livello \emph{data-link}. \\
\begin{figure}[hbt]
\begin{center}
\includegraphics[width=0.6\textwidth]{/tesina/layer2.png}
\caption{\tiny Rete considerata allo strato \emph{data-link}.}
\includegraphics[width=0.6\textwidth]{/tesina/layer3.png}
\caption{\tiny La stessa rete fisica è rappresentata da differenti %%@
\emph{entità} se considerata allo strato \emph{network}.}
\end{center}
\label{l23}
\end{figure}
La rappresentazione di una rete, cioè di un insieme di \emph{entità} %%@
interconnesse fra di loro, di conseguenza, può essere realizzata con un %%@
grafo, i cui nodi e rami rappresentano le \emph{entità} stesse. \\
Un nodo, come si è detto in precedenza, non rappresenta necessariamente %%@
un'\emph{entità} fisica, ma può ad esempio essere un'interfaccia virtuale %%@
su una scheda LAN Ethernet. \\
Le proprietà intrinsiche di una rete, o di una porzione di essa, sono %%@
determinabili dalle \emph{caratteristiche}, e misurano le prestazioni e %%@
l'affidabilità della rete stessa. \\
\'E importante distinguere fra la \emph{caratteristica}, che è una %%@
proprietà misurabile di un'\emph{entità} o del traffico legato ad essa, e %%@
l'\emph{osservazione}, cioè l'istanza specifica della misura di una %%@
caratteristica effettuata in un certo momento \ref{procmes}. L'RFC 2330 %%@
suddivide le osservazioni in tre categorie:
\begin{itemize}
\item{\emph{singleton}: la più piccola osservazione effettuabile;}
\item{\emph{sample}: un insieme di \emph{singleton};}
\item{\emph{statistical}: un'elaborazione statistica degli elementi di un %%@
\emph{sample}.}
\end{itemize}
La tecnica con cui si ottiene un'osservazione è definita %%@
\emph{metodologia}.
\begin{figure}[htb]
\begin{displaymath}
\xymatrix{  \fbox{Caratteristica} \ar[d]^{misurata} & & & & \fbox{Entità} %%@
\ar[llll]^{descritta} \\
            \fbox{Metodologia} \ar[rrrr]^{produce} & & & & %%@
\fbox{Osservazione} \ar[d] \\
                                                   & & & & %%@
\fbox{Singleton} \ar[d] \\
                                                   & & & & \fbox{Sample} %%@
\ar[d] \\
                                                   & & & & %%@
\fbox{Statistical}
             }
\end{displaymath}
\caption{\tiny Struttura concettuale definita dal NMWG del processo di %%@
misurazione.} \label{procmes}
\end{figure}
Le \emph{metodologie} di misura possono essere basate su tecniche che %%@
producono direttamente una \emph{osservazione}, oppure su algoritmi che %%@
la derivano a partire da \emph{osservazioni} di altre %%@
\emph{caratteristiche} oppure da elaborazioni statistiche di vario %%@
genere. \\
A tal proposito è importante evidenziare che spesso, specialmente in %%@
condizioni di reti particolarmente efficienti e ad alta capacità, %%@
l'osservazione, realizzata spesso tramite \emph{probing}, può essere %%@
erroneamente determinata dai limiti massimi di misura dello strumento %%@
utilizzato. In questi casi si rende indispensabile l'utilizzo di %%@
metodologie non basate sulla misura diretta di una caratteristica, ma che %%@
ne consentano la stima a partire da altre osservazioni. \\
Ad esempio, un'osservazione della banda disponibile su un link può essere %%@
ottenuta in maniera diretta, provocando traffico sul link e misurandolo. %%@
La stessa osservazione può essere ottenuta dalla capacità del link meno %%@
l'utilizzo. Senza dubbio la seconda tecnica è meno invasiva, ma anche più %%@
precisa, in quanto per poter misurare accuratamente la banda disponibile %%@
con la prima tecnica dobbiamo essere in grado di produrre traffico %%@
sufficiente, il che non sempre corrisponde ad una situazione reale. \\
In ogni caso il concetto di \emph{caratteristica} risulta slegato da %%@
quello di \emph{metodologia} di misura, e, relativamente ad una stessa %%@
\emph{caratteristica}, tutte le \emph{metodologie} appropriate devono %%@
produrre la stessa osservazione. \\

\section{Influenza del \emph{network layer}}

Il network layer relativo ad una \emph{osservazione} dovrebbe essere %%@
specificato ogni volta che la stessa \emph{caratteristica} ha senso %%@
relativamente a più strati di rete. \\
La scelta di specifici protocolli e livelli di qualità di servizio può %%@
infatti condizionare grandemente l'\emph{osservazione}, introducendo o %%@
meno ritardi, oppure variando la selezione del percorso di rete. \\
Quando ci si riferisce ad una \emph{osservazione}, di conseguenza, è %%@
necessario specificare tutti i parametri che possono influenzare la %%@
misura relativamente al network layer a cui stiamo facendo riferimento. %%@
\\
I nodi e i path di un grafo che rappresenta una rete dovrebbero sempre %%@
essere disegnati con annotate tutte le condizioni di misura significative %%@
(ad esempio UDP su IPv4 con una certa QoS). In questo modo lo stesso %%@
grafo, rappresentato con differenti \emph{attributi}, può rappresentare %%@
anche diversi tipi di traffico su una stessa rete. Tali \emph{attributi} %%@
non sono semplicemente descrittivi, ma se presi nel loro complesso %%@
caratterizzano un nodo o un percorso. \\
Per identificare quali attributi è necessario specificare per ogni %%@
\emph{caratteristica}, ad ognuna di esse è associato un \emph{profilo}. %%@
Un \emph{profilo}, oltre ad essere costituito da una serie di %%@
''condizioni´´ in cui si è ottenuta la misura, può anche richiedere che %%@
vengano specificate altre \emph{caratteristche} utili all'inquadramento %%@
preciso dell'\emph{osservazione}. Ad esempio è utile specificare il %%@
numero dei nodi che vengono attraversati insieme ad ogni misura di tipo %%@
end--to--end.

\section{Rappresentazione}

Quanto specificato in precedenza, conduce ad una organizzazione %%@
gerarchica delle caratteristiche, in cui alcune sono subordinate ad %%@
altre, nel senso che ne specificano completamente l'\emph{osservazione}.
\begin{figure}[th]
\begin{center}
\includegraphics[width=0.7\textwidth]{/tesina/char.png}
\caption{\tiny Schema delle caratteristiche e subcaratteristiche %%@
individuate dal NMWG.}
\end{center}
\label{car}
\end{figure}
La figura \ref{car} mostra un elenco delle caratteristiche necessarie per %%@
descrivere il comportamento delle entità di rete, e la relativa %%@
gerarchia. In notazione testuale, ogni caratteristica è rappresentata da %%@
una notazione a punti introdotta dal Discovery and Monitoring Event %%@
Descriptions (DAMED) working group, nella forma: \\
\newline
\verb|<entità>.<caratteristica>.<sub-caratteristica>| \\
\newline
L'\emph{entità} deve essere naturalmente relativa al network layer a cui %%@
si sta facendo riferimento. \\
La \emph{caratteristica} è sempre selezionata fra quelle di primo livello %%@
nella gerarchia in figura. \\
La \emph{sub-caratteristica} non è obbligatoria, e viene specificata solo %%@
quando ha una senso o è necessaria a chiarire completamente il %%@
significato dell'\emph{osservazione}. \\
Non devono essere presenti spazi, e tutte le lettere devono essere in %%@
caratteri minuscoli, tranne le iniziali delle parole successive alla %%@
prima per quelle caratteristiche per cui è necessario. Inoltre, tranne %%@
nel caso dell'entità \emph{NetworkPath}, abbreviata in \emph{path}, il %%@
nome deve essere sempre scritto per esteso.

\section{Ricerca e interrogazione delle osservazioni}

Lo scopo della misura delle caratteristiche, e della successiva %%@
memorizzazione delle osservazioni, è naturalmente quello di consentire ai %%@
\emph{consumer} dei sistemi \emph{Grid} di poter eseguire delle %%@
interrogazioni specifiche sul database che si è costituito. \\
Non è ancora chiaro quale sia la strategia di implementazione più %%@
efficace di un tale sistema di memorizzazione e interrogazione dei dati %%@
ottenuti tramite misurazione, in quanto la flessibilità e la complessità %%@
della struttura delle caratteristiche e subcaratteristiche rende le %%@
possibili query non facilmente identificabili. \\
Esistono infatti almeno due problematiche distinte collegate a due %%@
diversi tipi di interrogazione:
\begin{itemize}
\item{interrogazione di tipo \emph{White pages}: fornisce un'osservazione %%@
relativa ad una entità ben definita e nota a priori. Ricade in questo %%@
caso, ad esempio, la richiesta della capacità disponibile su una %%@
specifica interfaccia di un router.}
\item{interrogazione di tipo \emph{Yellow pages}: fornisce un elenco di %%@
entità che corrispondono a determinati requisiti, specificati attraverso %%@
valori minimi e massimi di caratteristiche. Ad esempio si può pensare ad %%@
una ricerca di tutti i path verso un elaboratore che dispone di un certo %%@
servizio con banda disponibile superiore a 1000Kbit/sec.}
\end{itemize}
Spesso i valori presenti nei database vengono solo considerati %%@
indicativi, in quanto è impossibile avere sempre disponibili misurazioni %%@
puntuali ed accurate. Ciò infatti richiederebbe un impiego di risorse per %%@
la misurazione e la distribuzione dell'informazione sempre aggiornata che %%@
potrebbe impegnare una sostanziosa percentuale delle capacità complessive %%@
del sistema. \\
Perciò l'implementazione del database delle osservazioni dovrà avere %%@
capacità di ricerca anche piuttosto complesse, pur dovendo mantenere %%@
efficacia nelle prestazioni. \\
Al momento esiste una sintassi, denominata \emph{RSL}, che è utilizzata %%@
in ambiente \emph{Globus} per l'identificazione dei \emph{service %%@
provider} dotati di specifiche caratteristiche minime di potenza di %%@
calcolo, disponibilità di memoria, utilizzabilità, ecc\ldots \\
Ad esempio il seguente codice RSL:
\begin{center}
\begin{verbatim}
                & (count>=5) (count<=10)
                   (max_time=240) (memory>=64)
                   (executable=myprog)
\end{verbatim}
\end{center}
istanzia 5-10 processi \verb|myprog|, ognuno su un elaboratore con almeno %%@
64 MB di memoria e che sia disponibile per almeno 4 ore\footnote{Esempio %%@
tratto da \cite{course}}.
\newline
L'estensione di RSL con le caratteristiche classificate secondo lo schema %%@
del NMWG è teoricamente possibile, ma in pratica comporta notevoli %%@
difficoltà implementative legate soprattutto alla molteplicità dei %%@
\emph{profili} determinabili per singola caratteristica.

\chapter{Proposta di architettura di rete per un \emph{Grid Network Resource Broker}}
\pagestyle{fancy} \thispagestyle{empty} \fancyhead[RO,LE]{Capitolo 3} \fancyhead[LO,RE]{\emph{Grid
Network Resource Broker}} \fancyfoot[RO,LE]{\thepage}

\section{Introduzione}
In questo capitolo viene descritta una proposta architetturale per garantire "network-awarness"
alle applicazioni di griglia. Tale architettura si basa sul coordinamento di moduli software che
forniscono strumenti per il monitoraggio, il controllo e la configurabilità della rete necessarie
per garantire dei servizi di rete (definiti \emph{grid network service} dal Grid High Performance
Network Research Gruop, come descritto successivamente) che l'infrastruttura di griglia possa
sfruttare a proprio vantaggio per ottenere informazioni o richiedere specifici livelli di qualità
di servizio. In particolare descriveremo la struttura del Grid Network Resource Broker (GNRB) che
assolve a tutte le funzionalità di controllo e gestione della rete e fornisce i servizi di rete a
disposizione di un qualsiasi \emph{Grid Application Manager} durante il processo di coordinamento e
allocazione delle risorse.
\section{Progettazione del GNRB}
\subsection{Coordinamento delle risorse di griglia}
Una delle caratteristiche base di ogni sistema di Grid Computing, è l'esistenza di un coordinamento
delle risorse, centralizzato o meno, che sia al corrente della disponibilità di mezzi
computazionali della griglia. Il coordinamento e la distribuzione delle risorse si basano sulla
"conoscenza" o la possibilità di ottenere rapidamente informazioni sullo stato di operatività dei
dispositivi che la griglia ha a disposizione per istanziare processi e richiedere servizi. Il
sistema di coordinamento della griglia, elabora ogni richiesta di attivazione di un processo,
identificandone la struttura e costruendo un piano di esecuzione. Tale piano, assegna già
implicitamente risorse ai moduli che costituiscono il processo, determinando quali di essi possono
essere distribuiti ed eseguiti in parallelo e quali, invece, richiedono la sequenzialità di
elaborazione. Nell'elaborare questa struttura, il Grid Application Manager prende anche in
considerazione i vincoli legati a richieste minime o ottimali di risorse di calcolo per
l'esecuzione dei moduli. In particolare, quando i moduli rappresentano sottoprocessi che possono
essere eseguiti in parallelo, ad essi è associata una lista di "aggregati" di risorse che può
include anche vincoli di rete. Tali vincoli possono essere specificati attraverso condizioni sulla
qualità di servizio, oppure sulla topologia delle sottoreti interessate alla distribuzione. Per
sfruttare correttamente la possibilità di rendere parallela l'esecuzione di un processo, infatti, è
necessario che il tempo richiesto per il trasferimento delle informazioni fra un elaboratore e
l'altro sia minimo rispetto al tempo dell'elaborazione. Naturalmente, durante l'esecuzione del
processo, il Grid Application Manager è sempre in grado di controllarne lo stato di avanzamento
tramite un sistema ad eventi che vengono generati dai vari moduli. La struttura che rappresenta
l'esecuzione complessiva di un'applicazione sulla griglia, può essere rappresentata come un grafo,
i cui nodi rappresentano i moduli che la compongono, e i cui archi costituiscono le relazioni
logiche che intercorrono fra i moduli stessi. La distribuzione dell'applicazione, viene eseguita
tramite algoritmi di mapping di ogni nodo del grafo su un aggregato di risorse, che sono quelle
scelte per l'esecuzione del modulo parallelo o sequenziale dell'applicazione. Inoltre, quando archi
del grafo non rappresentano solamente un vincolo di continuità logica nel flusso dell'applicazione,
ma sottintendono anche un vero e proprio spostamento "fisico" dell'esecuzione, con conseguente
deallocazione e riallocazione di risorse e, soprattutto, "trasporto" di informazione, è necessario
prevedere per tali archi un'opportuna assegnazione con le risorse di rete. Un'infrastruttura di
griglia, in generale, prevede esplicitamente che trasferimenti di dati possono avvenire
genericamente fra due provider di servizi, e di conseguenza, che vengano attraversati tratti di
rete soggetti ai più disparati utilizzi e costituiti da apparati eterogenei durante l'esecuzione di
un'applicazione. In definitiva, un ambiente grid per garantire un comportamento "network-aware",
deve prevedere funzionalità di monitoraggio dello stato della rete, allocazione dinamica e
efficiente delle risorse di connettività e servizi che garantiscono performance di rete. A tal fine
è stato progettato il Grid Network Resource Broker come interfaccia univoca tra le applicazioni
grid-aware e le reti di trasporto.
\subsection{Interazione con il \emph{middleware} grid}
Uno dei criteri progettuali che hanno dovuto essere definiti nello sviluppo di GNRB, è legato al
suo posizionamento rispetto al middleware grid ed ai protocolli che consentono il funzionamento
della rete. I vari progetti di ricerca attualmente attivi nell'ambito del software per piattaforme
di grid computing, non concordano nella definizione di uno standard per il monitoraggio delle
risorse di rete, né sono in grado di definire attualmente un protocollo di interscambio dati
universalmente accettato. E' presumibile che, per quanto il problema di monitorare e controllare
risorse di rete sia differente da quello legato al controllo di risorse di calcolo, ogni
sviluppatore di sistemi grid vorrà integrare nel proprio "resource manager" i dati che più ritiene
opportuni riguardo le possibilità di impiego della rete.  La difficoltà principale di tale
approccio consiste nel fatto che i dati di stato della rete non sono riportabili semplicemente
all'entità host, ma si riferiscono ad entità differenti quali nodi, link, path, e che assumono
significati differenti secondo il livello dello stack TCP/IP a cui li si considera. In
considerazione di ciò, si è ritenuto opportuno pensare ad un sistema che fosse di supporto ai grid
environment, senza tuttavia vincolarli in modo rigido riguardo i metodi di accesso e di utilizzo.
L'idea di base è, infatti, che, considerato che, in qualche modo, ogni grid resource manager avrà
la necessità di ottenere informazioni dalla rete e possibilmente interagire con essa per
ottimizzare i carichi di lavoro, fosse opportuno pensare ad una sorta di "servizio" indipendente e
autonomo, in grado di ricevere richieste dai grid environment tramite protocolli flessibili e
facilmente integrabili e di occuparsi internamente dei compiti di controllo e gestione della rete.
L'obiettivo è quello di creare un'interfaccia fra il middleware grid e la rete, che nascondesse al
grid environment la complessità del monitoraggio e della gestione dei collegamenti, ma fornisse al
sistema risposte il più possibile ottimizzate in base alle richieste di capacità trasmissiva
inviate dal middleware grid.
\begin{figure}[th]
\begin{center}
\includegraphics[width=0.9\textwidth]{/tesi/Capitolo3/overlay.png}
\caption{\tiny Relazione fra Grid e GNRB} \label{overlay}
\end{center}
\end{figure}
In sostanza si vuole ridurre al massimo l'interazione diretta tra il resource manager e la rete,
semplificando il processo di ottenimento delle misure ad una semplice mappatura fra il protocollo
di comunicazione di GNRB e il formato di memorizzazione nativo di ogni specifico resource manager..
Risultando, in tali condizioni, il servizio del tutto indipendente dalla stessa presenza di uno o
più ambienti grid che lo utilizzano, i dati su cui compie stime ed elaborazioni, non devono essere
teorici e calcolati in funzione delle richieste ottenute dal grid, ma devono rispecchiare reali
condizioni di carico della rete. Questa affermazione è basata su diverse considerazioni. Innanzi
tutto, se ci si pone nell'ottica di supportare e integrare i sistemi grid, ma non di farne
necessariamente parte, bisogna considerare che tali sistemi potrebbero istanziare job di minore
importanza, oppure con basse richieste di qualità di servizio senza passare da GNRB (si veda in
seguito il paragrafo sull'attivazione dei job). Non esiste infatti una dipendenza vincolante dei
due sistemi, ma solo un rapporto di supporto dell'uno all'altro quando questo lo ritiene
necessario. Ciò tuttavia non vieta che il grid manager sia implementato per basarsi interamente su
GNRB. Si cerca semplicemente di perseguire un approccio meno integrato, che sia più vicino ad un
concetto di stratificazione funzionale e che ponga GNRB nell'area delle funzioni che la rete mette
a disposizione delle applicazioni, così come la risoluzione dei nomi di dominio o l'instradamento
corretto dei pacchetti. Il grid environment, infatti, nell'ipotesi che questo si appoggi su GNRB,
deve solamente sapere che esiste la possibilità di richiedere alla rete qualità di servizio,
percorsi ottimali, riconfigurazione dei percorsi per ottenere prestazioni particolari senza entrare
nel merito né del tipo di link fisici che si sfruttano, né del modello dei router e dei protocolli
che utilizzano. La rete stessa, tuttavia, non potrà essere considerata - nel caso generale - come
uno strumento ad integrale disposizione della griglia. Bisogna tenere presente che è molto
probabile che affianco dei job istanziati dal grid environment, esistano normali comunicazioni di
tipo tradizionale, e che i link siano quindi soggetti all'utilizzo di utenti esterni alle
organizzazioni partecipanti al grid. Tali applicazioni spesso possono richiedere notevoli livelli
di qualità di servizio ed impegno di rete. Non è difficile immaginare che fra due sedi remote di
un'azienda che abbia implementato una sistema di calcolo grid e che perciò utilizzi un link fra le
due sedi per far transitare dati utilizzati dalle applicazioni, esista anche un sistema di
telefonia su IP che condivida lo stesso canale di comunicazione. Questa considerazione
naturalmente, rafforza ulteriormente la scelta di mantenere indipendenti grid environment e GNRB.
In base a tali ragionamenti, si è preferito dunque posizionare il GNRB a metà strada tra i
protocolli di rete veri e propri e il middleware grid.
\section{Distribuzione del servizio}
\subsection{Accesso ai dati}
Innanzi tutto bisogna considerare il processo di misura. I valori dei parametri da monitorare
possono essere ottenuti e calcolati in numerosi modi differenti. Spesso, per limitare l'overhead
introdotto nel corso della misurazione, si cercherà di sfruttare i contatori dei router e dei nodi
di rete in generale, quando questi siano disponibili e accessibili. Altre volte, sarà invece
necessario ottenere i valori dei parametri direttamente tramite metodi basati su probing. In un
numero inferiore di situazioni infine, sarà possibile conseguire le misurazioni tramite un
algoritmo di calcolo o di stima che fornisca risultati sufficientemente accurati. Entrambe le prime
situazioni descritte, di fatto, impongono una soluzione architetturale che prevede la disposizione
di "monitor" dello stato della rete in aree piuttosto periferiche. Se, infatti, non ci si vuole
limitare a sfruttare le misurazioni ottenibili sui backbone principali, sarà necessario che il
sistema di monitoraggio abbia accesso ai tratti di rete che arrivano ai router periferici, con la
possibilità di accedere ai registri degli stessi per ricavarne misure, oppure per poter inviare
pacchetti di probing autorizzati. Considerando che, nella maggior parte dei casi, i colli di
bottiglia nel traffico di rete non sono rappresentati dai link di backbone ad altissima capacità,
ma dalle linee di collegamento che raggiungono le LAN periferiche, non è possibile in pratica
ipotizzare una soluzione che ignori le misurazioni delle prestazioni vicino al bordo della rete. A
questo riguardo appare immediatamente evidente il problema di sicurezza che si presenta, in quanto
il monitor, sia che acceda a dati sui router, sia che misuri effettivamente parametri di rete, sarà
pur sempre un elemento estraneo, che va ad inserirsi in un'area amministrativa che è di competenza
dei sistemisti locali. Già in questa fase di controllo dello stato di rete, dunque, si deve
affrontare il problema di come il sistema centrale di raccolta dei dati interagisca con le sue
parti più decentralizzate e meno accessibili. Inoltre, i sistemi grid sono, per loro natura,
eterogenei, non solo dal punto di vista tecnico, ma anche da quello dei fornitori e utilizzatori di
servizi. Spesso anzi, è ipotizzabile un rapporto di collaborazione fra organizzazioni che
partecipano ad una stessa virtual organization in cui alcuni membri mettono a disposizione loro
capacità specifiche sotto forma di servizi grid. Da un punto di vista tecnico, sia che esista un
accordo economico per l'utilizzo dei servizi, sia che ciò avvenga in modalità gratuita, è comunque
necessario prevedere che le organizzazioni non vogliano interagire fra di loro se non tramite la
virtualizzazione dei loro prodotti. Ciò significa che non saranno intenzionati ad esporre, per
l'accesso esterno, niente più che interfacce - si pensi al meccanismo RPC implementato dal
protocollo SOAP - che nascondono totalmente agli utilizzatori del servizio sia la logica interna
del software, che la struttura hardware del provider. In queste condizioni la soluzione che
l'architettura GNRB propone è quella di un sistema di misura definito sostanzialmente dal suo
protocollo di interscambio dati. Per non vincolarsi a metodi di misura obbligati, infatti, è
previsto in GNRB un modulo funzionale denominato Measurement Data Collector, il quale ricavi misure
nel modo più opportuno dalla rete e tramite uno stream XML definito dal suo DTD, le comunichi al
software di Measurement Elaboration che si trova gerarchicamente più in alto nella struttura GNRB.
\subsection{Scalabilità e organizzazione gerarchica}
Su una rete di grandi dimensioni, quali possono essere quelle delle Virtual Organization, la
quantità di informazioni che è necessario memorizzare nel database di stato della rete, può
facilmente diventare molto rilevante. Tradizionalmente il problema della scalabilità viene
affrontato tramite strutture gerarchiche oppure strutture distribuite. Le considerazioni svolte
riguardo alle problematiche di accesso ai dati e alle informazioni sullo stato delle reti indicano
che la soluzione basata su una architettura gerarchica è in questo caso preferibile. Una struttura
distribuita del servizio, infatti, oltre a richiedere una maggiore complessità nell'organizzazione
dei misuratori e soprattutto dei database, può comportare problemi sia dal punto di vista della
sicurezza che da quello della riservatezza. Non si può escludere che alcune organizzazioni
preferiscano nascondere la loro struttura fisica interna, esponendo solo metriche sufficienti alla
valutazione delle prestazioni nell'accesso ai servizi forniti. In questo scenario un servizio
distribuito può essere troppo invasivo in quanto, prevedrebbe numerosi accessi esterni agli
apparati di rete della struttura, anche da macchine molto lontane e non sicure. Per inquadrare il
problema, si pensi alle reti peer-to-peer per la condivisione files che sono al giorno d'oggi
diffusissime su Internet. Tali applicativi, oltre ad essere fra i più pericolosi tipi di software
per la sicurezza delle macchine che li contengono, consentono decine di accessi da ogni parte del
mondo, con evidenti rischi. E' sicuramente molto rischioso pensare di replicare tale struttura su
un'applicazione che consente addirittura il controllo della rete e l'allocazione dinamica delle
risorse per la qualità di servizio. Organizzando la struttura di GNRB in modo gerarchico invece, si
garantisce un maggiore controllo sulla periferia della rete, in quanto le richieste che transitano
da un estremo periferico ad un altro, devono in ogni caso attraversare i server GNRB posizionati
sulla backbone di rete, i quali possono essere considerati più affidabili. In pratica il problema
dell'autenticazione si riduce a garantire l'affidabilità dei server GNRB posizionati immediatamente
più in alto nella struttura gerarchica. Il problema dell'accesso agli apparati per la loro
configurazione in funzione delle richieste, invece, rimane confinato nell'area di amministrazione
locale, in quanto è il server GNRB posizionato nella rete di accesso che si occupa di interagire
con i router. Non è perciò necessario distribuire accessi al di fuori dell'area di amministrazione
di rete locale. Un altro aspetto che avvalora un approccio gerarchico dell'implementazione del GNRB
è relativo al problema della scalabilità e alla possibilità di ridurre il numero di misure da
effettuare e far transitare sulla rete. Infatti, le reti di accesso, dotate del proprio server
GNRB, possono assolvere a due compiti fondamentali: risolvere autonomamente le richieste che
riguardano l'ambito locale e selezionare, filtrandoli opportunamente i dati da trasmettere al
livello superiore della gerarchia.
\subsubsection{Risoluzione di richieste di servizio locali}
Per quanto riguarda la risoluzione di richieste di servizio locali, il sistema fornisce ovviamente
una risposta corretta senza accedere a tutti i server della struttura gerarchica. Tutte le
informazioni sull'area, infatti, sono normalmente conservate dal server GNRB che si trova
posizionato all'interno dell'area stessa. Di conseguenza, il server locale possiede già tutte le
informazioni di stato necessarie alla risoluzione della richiesta. Tuttavia è necessario che al
sistema centralizzato, cioè ai server della gerarchia che controllano quest'area specifica, venga
comunicata l'allocazione di risorse, le quali non possono più essere considerate come disponibili.
Questo processo si traduce in una fase di risposta alla richiesta di servizio, di attivazione del
servizio stesso, e di comunicazione dell'avvenuta occupazione di risorse. Tali operazioni
dovrebbero essere eseguite dal primo server GNRB della gerarchia che possiede una quantità di
informazioni sufficiente a rispondere alla richiesta di servizio. Il problema del filtraggio, dei
dati da trasmettere allo strato gerarchico superiore, è correlato al livello di mascheramento che
si vuole dare all'area locale verso il resto della rete grid. Gli amministratori di rete
potrebbero, per esempio ritenere un'approssimazione ragionevole quella di considerare nulli i
ritardi introdotti dalle LAN locali, considerare la rete Ethernet sempre scarica e così
approssimare le misurazioni che dovrebbero essere fatte verso ogni nodo della rete con quelle fatte
sul gateway verso la LAN. Con questo approccio il carico di lavoro dovuto al monitoraggio interno,
e il corrispondente impegno di rete, verrebbero notevolmente ridotti. Un'appropriata configurazione
dei misuratori nelle reti di accesso periferiche conseguirebbe questo scopo in maniera molto
semplice.  Anche al livello gerarchico superiore i misuratori locali potrebbero non trasmettere
tutte le informazioni che hanno a disposizione, ma selezionarne una parte significativa in modo da
non produrre un'inutile ed eccessiva mole di dati che si propagano verso i livelli più alti della
gerarchia. Utilizzando un approccio di questo tipo si potrebbe arrivare a delineare, in una
successiva evoluzione del meccanismo GNRB, una metodologia di ricerca dei percorsi di rete più
efficaci basata sull'analisi di dati a diversi livelli gerarchici: si cerca dapprima il percorso
più vantaggioso sulla backbone, dopodichè si scende verso la periferia, analizzando la rete sempre
localmente e individuando le tratte ottimali da attraversare. Questa ipotesi tuttavia, richiede
ulteriore investigazione, e può essere argomento di ricerca per uno sviluppo futuro.

\subsection{Accesso al servizio}
L'architettura proposta prevede un accesso e una segnalazione basata su stream XML trasportati via
TCP su porte note. Tali stream, definiti dai loro schemi o dai DTD, rappresentano l'interfaccia
verso il sistema di grid network service offerti dal GNRB. Un'implementazione reale deve prevedere
meccanismi di autenticazione e codifica che proteggano le informazioni sullo stato e l'utilizzo
della rete. Tali informazioni, in specifici ambienti, potrebbero divenire, infatti, sensibili.
L'utilizzo di XML consente una notevole semplicità d'implementazione dei client e il raggiungimento
di un notevole livello di solidità del server. Infatti, applicando il parsing basato su DTD al
flusso in ingresso, viene verificata immediatamente la correttezza formale della trasmissione da
una solida libreria, preferibilmente open-source, molto ben collaudata. In questo modo vengono
ridotti al minimo i possibili crash prodotti da messaggi non completamente conformi alla specifica.
L'uso di TCP come protocollo di trasporto è invece stato preferito rispetto al più snello UDP, per
le sue garanzie di affidabilità e, anche in questo caso, seguendo considerazioni che riguardano lo
sviluppo dell'applicazione client. Infatti, la presenza di solide librerie di alto livello per la
gestione delle connessioni TCP (ad esempio quelle del linguaggio Java), consente sia di poter
reindirizzare facilmente i flussi XML verso il server, sia di non doversi preoccupare del controllo
di trasmissione dei pacchetti. Tutto ciò, insieme alla precedente considerazione riguardante la
verifica formale dei messaggi XML, riduce al minimo i rischi dovuti ad errori nei flussi
trasmessi/ricevuti. In una futura evoluzione potrebbe essere opportuno introdurre un protocollo di
accesso al sistema basato su UDP, specialmente nel caso in cui si operi su reti particolarmente
efficienti e a bassa probabilità di errore e perdita.

\subsection{Stream di segnalazione}

Come si può notare dall'architettura gerarchica del sistema di monitoring, i vari nodi che
distribuiscono il database sulla rete, si scambiano informazioni continuamente al fine di
aggiornare le misure che contengono, oppure di integrarle con quelle nuove che eventualmente
ricevono. Tali nodi inoltre ricevono i risultati delle misure e delle stime effettuate direttamente
dai monitor di rete che devono essere posizionati strategicamente al fine di ottenere misure
significative. Questa problematica verrà approfondita in seguito nel paragrafo dedicato al Data
Management.

\subsection{Request}

Le request possono essere di vari tipi. Alcuni tipi di request sono semplicemente interrogazioni al
GNRB per la semplice fornitura di dati memorizzati nel database. In questo caso non viene compiuta
nessuna elaborazione sui dati, ma semplicemente inoltrata la richiesta al meccanismo di storage. I
dati ricavati vengono tradotti nel formato di response appropriato e inviati in risposta al
richiedente. Questo tipo di request viene normalmente utilizzato da strumenti di controllo
dell'attività di GNRB, da altre istanze di GNRB nel caso si voglia operare un interscambio di dati
secondo i protocolli standard, oppure nel caso si voglia richiedere la descrizione della topologia
di rete completa conosciuta dal GNRB. Altri tipi di request, invece, sono quelli che riguardano la
vera e propria attività del servizio GNRB verso il grid. Tali richieste servono ad ottenere
informazioni riguardo la migliore scelta da fare per l'attivazione di un servizio grid. A seconda
della qualità della risposta desiderata e del service level agreement impostato con l'ambiente
grid, sono disponibili tre diverse modalità di richiesta servizio: Best Service, Intermediate
Service e QoS.

\subsubsection{Modalità di funzionamento Best Service.}

L'utilizzatore comunica al sistema una lista di host destinazione (nel caso di un sistema grid
possono essere i provider che mettono a disposizione un certo servizio) e la caratteristica
principale richiesta (ad esempio l'ampiezza di banda disponibile al momento). Il sistema risponde
ordinando gli host dal migliore al peggiore secondo la disponibilità della caratteristica
specificata, specificando il valore attuale della misura della caratteristica disponibile nel
database. La risposta del sistema GNRB, in questo caso, non fornisce tuttavia alcuna garanzia di
qualità di servizio in quanto il collegamento con gli host destinazione è di tipo best-effort.

\subsubsection{Modalità di funzionamento Intermediate Service.}

Modalità Intermediate Service. Questa modalità di funzionamento è simile alla Best Service, ma
aggiunge la garanzia sulla qualità di servizio ottenibile. Di fatto il sistema seleziona un livello
di qualità di servizio che può essere raggiunto verso certi host, e, se l'utente l'accetta,
istanzia le risorse necessarie per garantirlo. Per funzionare in modalità Intermediate Service, il
GNRB deve essere dotato della possibilità di acedere ai router sul percorso selezionato ed allocare
le risorse necessarie.

\subsubsection{Modalità di funzionamento Quality of Service.}

Il sistema cerca di soddisfare le specifiche minime che vengono richieste attraverso l'analisi dei
dati disponibili misurati sulla topologia di rete attualmente configurata. Se ciò non risulta
possibile, ricerca percorsi alternativi sfruttando la conoscenza della topologia fisica di rete e
la disponibilità di misure di parametri dei singoli link. Se è possibile individuare un percorso
alternativo, configura i router in modo da instaurare un path specifico (possibilmente sfruttando
le caratteristiche di QoS della rete) che verrà mantenuto per tutto il tempo necessario. Affinché
questa modalità funzioni correttamente, il sistema dovrà possedere tutte le caratteristiche
necessarie per l'Intermediate Service, più almeno un algoritmo di decisione che, costruendo un
grafo pesato della rete, calcoli il miglior percorso rispetto alla metrica desiderata
dall'utilizzatore. Questo argomento sarà approfondito nel paragrafo riguardante il Network
Management.

\begin{figure}[th]
\begin{center}
\includegraphics[width=0.9\textwidth]{/tesi/Capitolo3/bas.png}
\caption{\tiny  Request e response in modalità QoS} \label{qossample}
\end{center}
\end{figure}

\subsection{Response}

I flussi XML di risposta che il GNRB invia alle applicazioni in conseguenza delle varie richieste,
sono  sempre strutturati in maniera molto simile e contengono una lista di risposte a tutte le
richieste che sono state inviate nello stream di tipo request. Ogni risposta identifica la
richiesta a cui si riferisce con l'identificativo progressivo corrispondente. La risposta relativa
ad una specifica richiesta, comprende informazioni necessarie al client per l'attivazione effettiva
del servizio grid e, dove necessario, i parametri necessari o i minimi di servizio garantiti.

\section{La struttura di GNRB}
Come si può vedere dalla figura, la struttura di GNRB è organizzata in blocchi che rappresentano i
blocchi funzionali, ognuno dei quali è composto da vari moduli ed è interconnesso con gli altri
tramite l'utilizzo di interfacce che sfruttano protocolli per l'interscambio dei dati. Nella
versione architetturale del GNRB che presentiamo sono evidenziati tre blocchi funzionali:
\begin{itemize}
\item{Network monitoring}
\item{Network Management}
\item{Protocol Data Exchange}
\end{itemize}
L'approccio che abbiamo utilizzato durante la progettazione ed l'implementazione di tali blocchi
funzionali è quello dell'indipendenza rispetto alla localizzazione. Infatti è possibile dislocare
le funzionalità su macchine diverse ed utilizzarle anche separatamente a seconda dei servizi che si
vogliono assegnare ad una determinata istanza dell'applicazione. Ad esempio si può configurare un
nodo della gerarchia GNRB per non avere né funzioni di risposta a richieste di servizio, né
funzioni di monitoraggio diretto della rete, ma per funzionare solamente come punto di
"aggregazione" ed elaborazione dei dati da passare al livello gerarchicamente superiore. Una
configurazione di questo tipo è significativa nei casi in cui si vuole ridurre l'overhead della
rete dovuto al monitoraggio di dati che possono essere considerati ridondanti.

\begin{figure}[th]
\begin{center}
\includegraphics[width=0.9\textwidth]{/tesi/Capitolo3/architettura.png}
\caption{\tiny Architettura del GNRB} \label{archgnrb}
\end{center}
\end{figure}


\subsection{Data acquisition process}
Il processo che si occupa del monitoraggio di rete, nel suo complesso è denominato Data Acquisition
Process. La sua funzionalità è chiusa e indipendente da quella degli altri moduli del GNRB.  In
particolare, la sua funzione è quella di interagire con i misuratori disposti sulla rete in
posizioni opportune per ottenerne i valori di stato, elaborare i dati acquisiti, ed infine
memorizzare tali dati in un database secondo un'organizzazione che ne consenta l'accesso in maniera
efficiente.

\subsection{Measurement data collector}
Il Data Collector è il modulo funzionale che si occupa di ricavare dalla rete i valori relativi
alle misurazioni delle caratteristiche che intendiamo analizzare ed utilizzare nel processo di
elaborazione. Questo modulo è composto di due gruppi sub-funzionali: i Measuerement Objects e il
Data Exchange Object. Il cuore attivo del modulo sono i Measurement Objects. Si tratta
sostanzialmente di software che implementano tool di probing consolidati, oppure legge tabelle di
stato quali quelle che spesso sono mantenute nella memoria dai router della rete. Laddove sia
possibile, infatti, è chiaramente più efficiente ottenere le misure relative allo stato della rete
senza dover eseguire alcun probing o test, ma ricavandole per altre vie. Ciò tuttavia comporta
comunemente che debbano essere presenti sul sistema di misura credenziali di autenticazione valide
per l'accesso ai router.  Da questo punto di vista, come si è spiegato in precedenza,
l'architettura gerarchica è piuttosto sicura, in quanto è sempre possibile installare un apposito
Measurement Object adiacente ad un router le cui statistiche si vogliono fornire ai sistemi
gerarchicamente superiori, senza tuttavia distribuire al di fuori della rete locale le credenziali
per l'accesso ad esso. Un semplice, ma utile, esempio di Measurement Object è quello che richiama
un tool di misura preesistente (ad esempio traceroute) ed esegue il parsing dell'output. In questo
modo ottiene i dati grezzi relativi a caratteristiche quali il round trip time (RTT) e il numero di
hops fra due nodi. Questi dati possono essere passati al modulo di Measurement Elaboration tramite
le funzionalità di interscambio dati del Data Collector. Il Measurement Data Collector è in grado
di ricavare dati e misurazioni anche in "collaborazione"  con altri servizi di monitoraggio di
rete, e, a tal fine può essere previsto di una funzionalità di interscabio dati diretto. Di fatto
si tratta sempre di un Measurement Object particolare, con in più funzionalità di output dati e non
solo di input.

\subsection{Measurement elaboration}
Lo scopo del modulo di Measurement Elaboration è quello di "raffinare" i dati grezzi che provengono
dalla misura diretta prodotta dai Measurement Objects. Questo processo è finalizzato a garantire la
consistenza del database delle informazioni di rete durante l'attività del meccanismo di monitoring
di rete. Il Measurement Elaboration deve verificare prima di tutto la validità dei dati ricevuti.
Può infatti accadere che un tentativo di probing non vada a buon fine  e si ottenga un risultato
completamente scorretto o un messaggio di errore.  In tali situazioni occorre prevedere delle
adeguate contromisure per impedire che il database venga corrotto. Un altro problema, che si
riscontra nel momento di "riempimento" del database, è quello della differenza di unità di misura o
di accuratezza nell'elaborazione di dati provenienti da diversi Measurement Objects. E' necessario,
infatti, che i dati presenti nello storage siano omogenei e che le loro unità di misura siano
stabilite a priori, insieme alla definizione delle entità, caratteristiche e subcaratteristiche da
monitorare. Anche eventuali algoritmi di predizione e stima sulle statistiche di rete devono essere
sviluppati all'interno di questo livello architetturale del GNRB. Infatti, qualora sia necessario
agli algoritmi di management della rete ( vedi Network Management) utilizzare informazioni ricavate
da predittori e stimatori delle statistiche di rete, vogliamo garantire la disponibilità di tali
dai in maniera persistente all'interno del database. In questo modo garantiamo che il processo di
richiesta dati al Data Management, sia particolarmente snello e veloce. Infine, un'altra
funzionalità importante del Measurement Elaboration è quella di ricavare dalle statistiche attuali
e da quelle presenti nel DataBase la topologia della rete.Un metodo per la memorizzazione della
topologia è quello di utilizzare la caratteristica che rappresenta il numero di hops fra nodi. Si
memorizza in pratica la catena dei nodi indicando che esiste un solo hop fra ogni coppia di essi.

\subsection{Data management}
Punto finale del processo di acquisizione dati è il Data Management. Con questa definizione si
intende il meccanismo che organizza i dati rilevati ed elaborati nella maniera più opportuna ai
livelli di Measurement Data Collector e di Measurement Elaboration in una struttura permanente che
ne consenta un semplice accesso.  Tutte le strategie di Network Management si basano sulla ricerca
di soluzioni ottime relativamente allo stato della rete che ottengono tramite le funzionalità del
Data Management. Compito del Data Management è perciò memorizzare tale stato di rete, e rendere
disponibile, in maniera rapida ed efficace, i dati per l'elaborazione. Un requisito fondamentale è
che la fornitura dei dati alla funzione di Network Management avvenga già in maniera ordinata, in
modo che gli algoritmi di decisione dei percorsi o delle destinazioni ottimali, possano
avvantaggiarsi di questa caratteristica. Da un punto di vista della specifica architetturale, non è
previsto un'unica tecnica per l'immagazzinamento dei dati di stato della rete, in quanto si ritiene
conveniente lasciare che vengano utilizzati gli strumenti più opportuni all'integrazione efficiente
con il Network Management. I due moduli infatti, pur essendo funzionalmente distinti, potrebbero
condividere gran parte del codice sorgente, specialmente in implementazioni leggere del sistema,
orientate all'ottimizzazione ed al monitoraggio di piccole porzioni di rete. Il software di
storage, deve tuttavia tenere conto che le richieste che riceverà saranno strutturate secondo il
modello multilivello entità.caratteristica.subcaratteristica descritto in precedenza (dove????).
Tale struttura, pur non essendo forse completa nella caratterizzazione di tutti gli aspetti della
rete, è di fatto riconosciuta come standard, e perciò è stata scelta per l'utilizzo in questo
contesto. Per avere una descrizione più approfondita delle caratteristiche architetturali fin qui
descritte, si faccia riferimento alle situazioni descritte in seguito.

\subsubsection{Esempio di implementazione leggera}
Potrebbe essere realisticamente pensata una soluzione implementativi della funzionalità di Data
Management che non faccia uso di supporti elettromeccanici scrivibili. Tale approccio è spesso
usato, in condizioni di ridotto carico di lavoro, per avere implementazioni efficienti e in cui le
configurazioni non siano attaccabili dall'esterno.  Se si ritiene che la quantità di dati
collezionabili, infatti, non cresca oltre una dimensione tollerabile, semplici strutture che
risiedono in memoria potrebbero essere sufficienti per l'implementazione della funzionalità di
storage e risultare particolarmente leggere ed efficaci, non richiedendo accessi ai dischi per il
recupero e l'elaborazione delle informazioni. Naturalmente questo tipo di implementazione, oltre al
limite della quantità di dati trattabili, dipendente dalla disponibilità di memoria allocabile per
lo storage e richiede che ad ogni riavvio, o interruzione del sistema, il database venga
completamente ricostruito. In realtà in molte situazioni, questo è tollerabile grazie alla natura
stessa del meccanismo di Network Monitoring, il quale propaga ripetutamente le informazioni
attraverso la gerarchia dei sistemi collegati. In un contesto operativo a regime, è immaginabile
che pochi minuti siano sufficienti perché il database torni ad essere popolato con i dati
aggiornati relativi allo stato della porzione di rete da monitorare. Questo esempio introduce anche
ad un'altra delle funzionalità del blocco di Data Management, cioè la possibilità di eseguire dei
"bulk transfer" di sottoinsiemi dei suoi dati verso il blocco Data Management di un altro server.
In contesti adeguatamente protetti e correttamente configurati, dovrebbe essere possibile stabilire
una relazione di trust fra server che servono differenti gruppi di utenti, in maniera tale che lo
scambio reciproco di informazioni avvenga tramite forme di interscambio dati che minimizzano il
carico di rete. In tal caso, si decide deliberatamente di rinunciare alla compatibilità globale in
cambio di una tecnica di trasferimento dati più efficiente. Ciò, tuttavia, non introduce
limitazioni alla distribuibilità e trasparenza del sistema, in quanto i normali meccanismi di
scambio informazioni che attraversano tutta la catena dell'architettura rimangono comunque
disponibili. Questa tecnica può risultare estremamente potente ed efficace in ambienti in cui si
abbia la piena controllabilità. \\
Se si pensa ad un'implementazione del sistema limitata
all'utilizzo in un ambiente di griglia universitaria, la quale costituisce una propria Virtual
Organization, che mette a disposizione servizi grid di varia natura, distribuiti fra i vari
dipartimenti, è ragionevole pensare che la soluzione con storage in memoria e relazione trus fra i
livelli Data Management dei vari dipartimenti possa essere efficace. Il presupposto della relazione
di trust fra il server che mette a disposizione i dati e quello che li integra ai propri, in questo
caso non può venire meno, in quanto non viene compiuta alcuna ulteriore verifica sulle informazioni
caricate.

\subsubsection{Esempio di implementazione per grandi reti}
Si consideri adesso un'implementazione destinata al trattamento di una mole di informazioni molto
più consistente, ad esempio un server che si trova ad un livello della gerarchia piuttosto alto e
che riceva informazioni che gli vengono passate dallo strato di Measurement Elaboration senza
nessuna strategia di aggregazione. Tale situazione comporta il trasferimento verso il server di una
grande quantità di dati, tra i quali possono presentarsi anche i dati relativi al singolo host di
una sottorete. In questo caso la funzionalità di storage, verrà notevolmente caricata, sia dal
punto di vista della quantità di dati che dovrà gestire, sia dal punto di vista della concorrenza
per quanto riguarda l'accesso ai dati stessi in lettura e scrittura. Una solida implementazione
della funzionalità di Data Management, si baserà probabilmente in questo caso, su un motore di
database SQL. Ciò consente, in funzione del numero, del tipo e della frequenza degli accessi ai
dati, di sfruttare i numerosi parametri disponibili per il tuning del motore di gestione dati e di
ottenere un buon livello di ottimizzazione. In questa implementazione, il motore SQL verrebbe
interfacciato tramite un wrapper che svolge funzionalità di mapping per le richieste di accesso ai
dati dai livelli adiacenti, in chiamate SQL opportune. Il motore SQL stesso, fornirebbe le
funzionalità di ordinamento ottimizzate necessarie per gli algoritmi di ricerca dei percorsi
ottimali. Questo scenario spiega, tra l'altro, perché sia conveniente che le capacità di
ordinamento risiedano nel Data Management: esse sono inscindibilmente legate alla modalità in cui i
dati vengono memorizzati, nel senso che l'utilizzo di indici sul database o proprietà della
struttura dati che le contiene, possono essere vantaggiosamente sfruttate per ottenere prestazioni
migliori.
\subsection{Flusso dei dati}
Nel procedimento di Data Acquisition Process il trasferimento delle informazioni provenienti dai
Measurement Objects verso i blocchi funzionali di livello superiore segue un paradigma di
trasferimento asincrono. Infatti, come abbiamo descritto precedentemente, il Measurement
Elaboration può richiedere più misurazioni per compiere una elaborazione prima di memorizzare il
risultato nel database di storage delle informazioni di rete. Essendo il meccanismo di rilevazione
e trasmissione dati asincrono, consente una maggiore possibilità di taratura riguardo la frequenza
con cui vengono ripetute le misure relative a dati con maggiore o minore variabilità temporale. La
verifica della topologia di rete, ad esempio, può essere eseguita molto raramente, mentre la
rilevazione del carico sulla banda di un link dovrà essere eseguita con maggiore frequenza. Non
richiedere una sincronizzazione nella rilevazione dei dati, aiuta anche a non mettere il sistema in
crisi di fronte a tentativi di probing che non vanno a buon fine o mancate risposte dai server a
cui ci si collega per richiedere i dati (ad esempio mancata risposta di un server SNMP in tempo
utile). Uno sviluppo futuro dell'architettura, dovrebbe prevedere una tecnica per la comunicazione
verso lo strato di Measurement Data Collection di richieste di rinnovo dati o di acquisizione di
dati mancanti.  Tale richiesta tuttavia, non è di semplice ed immediata implementazione, in quanto
richiede che il Data Management, accortosi di dover richiedere più dati, sappia a chi richiederli e
soprattutto comunichi allo strato di Measurement Elaboration che tali dati devono essergli
trasmessi senza subire raggruppamenti o elaborazioni che potrebbero alterarne il significato.

\subsection{Network Management}
La funzionalità di Network Management rappresenta il cuore intelligente del sistema GNRB. Gli
algoritmi di decisione dei percorsi ottimi, o degli host di destinazione sono tutti implementati in
moduli che appartengono a questa funzionalità. Tali moduli si interfacciano con gli utenti
attraverso autenticazioni opportune e stream XML.
\subsection{Modulo di decisione}
Il modulo di decisione riceve le richieste dall'utente e si interfaccia con lo storage dei
parametri di rete per interpretarli nel modo più opportuno. Attualmente il modulo di decisione
implementa i tre tipi di algoritmi di risposta all'utente: best available service, intermediate
service e QoS service. Queste tre modalità di funzionamento sono state descritte in precedenza e
rispondono a precise necessità degli utenti grid. In realtà il modulo di decisione può anche
accorgersi che la richiesta è semplicemente relativa ad una trasmissione dati che non richiede
ulteriori elaborazioni e, dopo aver ottenuto i dati dal modulo di Data Management, li esporta
all'utente.
\subsection{Modulo Network Configuration}
Il modulo Network Configuration è controllato direttamente ed esclusivamente dal modulo di
decisione. Si occupa dell'interfacciamento con i router e gli apparati di rete, istanziando e
deallocando dinamicamente le risorse . Il fatto che non debba esistere nessun modo per scavalcare
il modulo di decisione e controllare direttamente il Network Configuration è legato ai problemi di
sicurezza di cui si è discusso nei paragrafi precedenti.

\chapter{Aspetti implementativi del prototipo GNRB}
\pagestyle{fancy} \thispagestyle{empty} \fancyhead[RO,LE]{Capitolo 4}
\fancyhead[LO,RE]{\emph{Aspetti implementativi del prototipo GNRB}} \fancyfoot[RO,LE]{\thepage}

\section{Finalità del prototipo}

Il prototipo realizzato rappresenta un primo tentativo di implementazione dell'architettura GNRB.
Tale prototipo si propone di verificare l'efficienza del servizio di monitoraggio e controllo di
rete all'attivazione di applicazioni che ne provocano una progressiva saturazione. \\
L'implementazione realizzata non comprende tutte le funzionalità ed i moduli precedentemente
descritti, ma solamente quelli necessari per le verifiche che ci si  propone di realizzare sul
testbed a disposizione (Figura \ref{metrocore}). \\
\begin{figure}[th]
\begin{center}
\includegraphics[width=0.9\textwidth]{/tesi/Capitolo4/ring.png}
\caption{\tiny Nodi della \emph{Virtual Organization} dell'area pisana} \label{metrocore}
\end{center}
\end{figure}
I test che sono stati eseguiti riguardano le due modalità di funzionamento di GNRB: Best Service e
Quality Of Service. \\
Nell'eseguire i test, ci si è prefissi lo scopo di simulare l'operatività di un certo numero di
applicazioni di griglia network--aware. Il primo tipo di test è finalizzato a verificare il
funzionamento di tipo \emph{Best Service}. Il test consiste nel comunicare al GNRB un elenco di
provider di servizi grid e verificare che il sistema le "classifica" effettivamente da quella più
favorevole a quella meno favorevole in funzione dello stato attuale della rete. In questa
situazione al client viene solamente fornita un'indicazione riguardo a quale provider, fra quelli
da esso stesso proposti, convenga richiedere un servizio. GNRB non comprende alcun meccanismo di
"discovery" dei servizi grid e, di conseguenza, si appoggia sulle funzionalità implementate in tal
senso nel \emph{middleware} grid. Questa modalità di funzionamento può essere associata a contratti
di accesso alla griglia con bassi livelli di Service Level Agreement. Questi, spesso, non
consentono di garantire o instaurare livelli minimi di qualità di servizio. \\
Il secondo tipo di test, è finalizzato a simulare la modalità di accesso con garanzia di qualità di
servizio che può essere attuata nel caso di utenti con un Service Level Agreement di livello
superiore e con accesso privilegiato. \\
Nel caso del test di funzionamento QoS lo scopo è quello di dimostrare che il sistema, accorgendosi
di non poter garantire, attraverso lo schema di routing preimpostato, la qualità di servizio
richiesta, cercherà di riconfigurare la rete per soddisfare la specifica richiesta. \\
La variazione del routing avviene attraverso la creazione di uno Label Switched Path temporaneo.
Tale LSP viene ricavato in funzione dei nodi e dei link che al momento risultano in grado di
soddisfare la richiesta effettuata. Dato che l'intera area di funzionamento del grid dovrebbe
essere monitorata, si suppone di avere a disposizione le misurazioni relative a tutti i
collegamenti ed i router interessati. Quei link sui quali non si hanno a disposizione informazioni,
infatti, non possono
essere presi in considerazione per la ricerca. \\

\section{Algoritmo di ricerca per modalità QoS}
Per soddisfare la richiesta di tipo QoS, GNRB dapprima verifica se la rete è in grado di fornire la
qualità di servizio necessaria. A tal fine ricerca nel database delle misurazioni i valori
end--to--end riguardanti la metrica da garantire. Nel caso in cui non sia trovato un percorso con
qualità sufficiente, l'algoritmo di ricerca ricostruisce il grafo della topologia di rete a partire
dai dati conosciuti e significativi rispetto al tipo di QoS da fornire. \\
Le metriche di rete per cui si richiede qualità di servizio, in generale, possono essere
classificate come additive e non additive. Tale distinzione è legata al modo differente con cui i
valori si combinano link dopo link. Misure additive sono, ad esempio, quelle relative al ritardo.
Chiaramente, per questo tipo di metriche, si può approssimare il costo accumulato attraverso il
percorso complessivo come la somma dei costi dei singoli link. Il prototipo è stato sviluppato,
tuttavia, per affrontare il problema della banda disponibile che ricade fra le misure non additive.
In particolare si tratta di una misura di minimo, in cui ogni singolo link deve garantire il valore
minimo di prestazione richiesta. Per schematizzare questo tipo di condizione, si può immaginare di
dover applicare un algoritmo \emph{shortest path} ad un grafo i cui rami abbiano peso finito o
infinito a seconda che garantiscano o meno la condizione di minimo desiderata. \\
Di fatto si vuole che i rami che non garantiscono il minimo non vengano mai selezionati. Si può
dunque semplificare questa situazione applicando l'algoritmo di ricerca direttamente al grafo
privato dei rami non desiderati. Sul grafo risultante è eseguito l'algoritmo di Dijkstra per la
ricerca dello shortest path fra chi richiede il servizio e uno dei provider in grado di fornirlo.
Altri tipi di misure non additive, prevedono in ogni caso l'applicazione di differenti varianti
degli algoritmi di ricerca. Le misure moltiplicative, quali ad esempio quella della probabilità di
perdita sul percorso, si combinano infatti in maniera ancora più complessa. La probabilità di
perdita si può ricavare moltiplicando fra di loro le probabilità di corretta trasmissione sui
singoli link e sottraendo a 1 il valore ottenuto. \\
Il Document Type Definitions (DTD) degli stream XML delle request prevede la caratterizzazione del
tipo di metrica che si considera. In una versione definitiva dell'implementazione di GNRB si dovrà
prevedere di tenere in considerazione una tale caratterizzazione. In futuro sarà anche necessario
affrontare il problema di richieste combinate di qualità di servizio. Al momento esistono proposte
di algoritmi differenti che affrontano questo problema cercando di ottenere tempi di esecuzione comunque ragionevoli. \\

\section{Client per l'interfacciamento con GNRB}
Oltre al software GNRB vero e proprio, è stato sviluppato un semplice client per effettuare
richieste al sistema e per visualizzare i risultati forniti. Il client ha solo lo scopo di leggere
un file XML - la request - ed inviarlo al server GNRB, dopo avere aperto un socket TCP verso la
porta di ascolto. Il server, compiute le operazioni necessarie, invia una risposta che il client
consente di visualizzare. L'operatore, interpretando tale risposta, è in grado di valutare il
corretto funzionamento del sistema. \\

\section{Scelta del linguaggio di programmazione}
Il linguaggio Java è stato scelto per la realizzazione del prototipo per le sue caratteristiche di
solidità, semplicità di sviluppo e per la vasta disponibilità di librerie open-source disponibili.\\
Java è un linguaggio per scopi generalizzati sviluppato da Sun Microsystems all'inizio degli anni
'90 ed oggi molto stabile e consolidato per la scrittura di software di rete. \\
Nello sviluppo del prototipo, si è data priorità a caratteristiche di semplicità di sviluppo,
manutenibilità nel tempo, possibilità di suddivisione del lavoro in gruppi. Non si è voluto inoltre
utilizzare un linguaggio, quale il C, che richieda un notevole sforzo di implementazione, per non
distogliere energie dallo sviluppo concettuale. \\
Sicuramente Java è inferiore, in termini di prestazioni, rispetto ad altri linguaggi a più basso
livello, in quanto è basato sulla presenza di una \emph{virtual machine} che riproduce un ambiente
logico di esecuzione per ogni processo. Tuttavia, si è tenuto in considerazione che lo sviluppo
delle \emph{virtual machine} le sta portando ad essere molto performanti e che, nel caso fossero
necessarie implementazioni in linguaggio C, il prototipo può essere sempre considerato una solida
linea guida. \\
Java è un linguaggio totalmente ad oggetti. Questa sua caratteristica lo rende particolarmente
adatto alla scrittura di codice nel quale si possano identificare facilmente parti da assegnare a
diversi membri di un gruppo di lavoro per lo sviluppo. Gli oggetti infatti rappresentano entità,
ognuna delle quali deve essere dotata delle proprie funzionalità e caratteristiche specifiche. E'
poi la loro interconnessione a determinare l'ossatura dell'applicazione.\\
Gli ambienti di run-time, o virtual machine, disponibili per il linguaggio Java sono molteplici e
funzionanti sulle piattaforme hardware e software più comuni. In particolare la possibilità di
utilizzare sistemi operativi Unix/Linux per l'installazione dei server GNRB garantisce
caratteristiche di affidabilità e livelli di performance più che sufficienti per i test di
valutazione programmati. L'installazione dei moduli di sola misurazione di rete su computer
portatili economici e poco potenti dotati di sistema operativo Windows è risultata altrettanto
comoda per i test, in quanto tali macchine possono essere facilmente spostate e configurate. Il
linguaggio Java, con il suo ambiente di esecuzione basato su virtual machine, risulta
particolarmente indicato per la programmazione di servizi di rete solidi ed affidabili. E' infatti
il linguaggio stesso ad indurre ad una corretta gestione degli errori di run--rime, e ad impedire
la caduta non gestita dei servizi di rete. \\
Java è così universalmente diffuso che molte librerie di software riutlizzabile sono disponibili
gratuitamente in Internet. Queste librerie spesso provengono progetti di sviluppo universitari e
consentono di avere a disposizione algoritmi utili e solidi per la loro integrazione nel software
prototipo. Di seguito vengono elencate le principali librerie esterne che sono state utilizzate
nello sviluppo.

\subsection{Xerces}
Xerces è una libreria che fornisce funzionalità di parsing e di generazione di documenti XML.
Xerces fa parte del progetto Apache XML. La libreria è disponibile sia per il linguaggio Java che
per C++ e implementa sia gli standard XML e DOM livello 1 e 2 standardizzati dal W3C che lo
standard SAX di fatto. Xerces supporta anche la gestione degli schemi XML secondo le specifiche del
corrente draft W3C. La libreria può essere utilizzata anche da altri linguaggi di programmazione
attraverso dei wrapper disponibili in rete. Come specificato dalle definizioni XML le stringhe
Unicode sono supportate interamente, non si hanno perciò problemi con l'internazionalizzazione dei
tag. \\
Xerces è stata utilizzata nel prototipo per il parsing e la verifica degli stream XML che
trasportano i vari messaggi di segnalazione. \\
Il codice per l'utilizzo di Xerces è semplice e in perfetto stile Java. Di seguito si riportano, a
titolo di esempio, alcune righe di codice (non consecutive) di una funzione che esegue il parsing
di un flusso XML.

\begin{verbatim}
public void readXml(BufferedInputStream is) throws IOException {
  DOMParser parser = new DOMParser();
  ...
  StringReader s = new StringReader(xml);
  ...
  org.xml.sax.InputSource i1 = new org.xml.sax.InputSource();
  i1.setCharacterStream(s);
  parser.parse(i1);
  ...
  Document doc = parser.getDocument();
  ...
  NodeList nodi = doc.getElementsByTagName("request");
  for (int i = 0; i < nodi.getLength(); i++) {
    Node node = nodi.item(i);
    ...
}
\end{verbatim}

\subsection{Jung - the Java Universal Network/Graph Framework}
Jung è una libreria software che fornisce un linguaggio per la modellazione, l'analisi e la
visualizzazione di dati che possono essere rappresentati come grafi o reti. E' scritta in Java, il
che consente alle applicazioni basate su Jung di non perdere le caratteristiche di sicurezza e
portabilità del linguaggio. \\
L'architettura di Jung è progettata per supportare una varietà di rappresentazioni di entità e
delle loro relazioni, come grafi direzionati o non direzionati, grafi multi-modali, grafi con rami
paralleli e \emph{ipergrafi}. Fornisce inoltre strumenti per l'associazione alle entità del grafo
di meta-dati, i quali possono essere utilizzati nelle fasi di elaborazione, per prendere decisioni
o eseguire algoritmi sul grafo stesso. \\
La distribuzione corrente di Jung, inoltre, include implementazioni di molti algoritmilegati alla
teoria dei grafi. \\
Jung inoltre dispone di numerose funzionalità per la visualizzazione dei grafi secondo i più
importanti tipi di \emph{layout}. \\
Nel prototipo Jung è stato utilizzato pesantemente in tutte le funzioni legate alla gestione della
topologia. In particolare si utilizza, per la ricerca dei percorsi ottimali, l'implementazione
dell'algoritmo di Djikstra che contiene. Si seguito è riportata proprio questa parte di codice.

\begin{verbatim}
public class ShortestPathFinder {
    private Topology g;
    private HopsList hl;
    ...
    public HopsList find(String from, String to) {
        DijkstraShortestPath dsp = new DijkstraShortestPath(g);
        dsp.enableCaching(true);
        StringLabeller sl = StringLabeller.getLabeller(g);
        Vertex v1 = sl.getVertex(from);
        Vertex v2 = sl.getVertex(to);
        List s = dsp.getPath(v1,v2);
        ...
\end{verbatim}

\subsection{Westhawk's Java SNMP stack}
La distribuzione dello stack SNMP Java prodotto da Westhawk, è costituita da classi Java che
implementano tutte le funzionalità necessarie al prototipo per interagire con i router tramite
questo protocollo. La libreria è leggera e distribuita gratuitamente, insieme al suo codice
sorgente. Le versioni SNMP supportate sono la SNMPv1, SNMPv2c e SNMPv3, comprensiva delle
funzionalità di autenticazione. \\
Di seguito si riporta un frammento di codice per l'invio ad un router della richiesta di lettura di
un OID.
\begin{verbatim}
   ...
   context2c = new SnmpContextv2c(sq.SNMPServer.getHostAddress(),
                   port, socketType);
   context2c.setCommunity(sq.community);
   pdu = new OneGetPdu(context2c);
   pdu.addObserver(this);
   pdu.addOid(sq.oid);
   pdu.send();
   ...
\end{verbatim}

\subsection{MySQL Connector/J} Il prototipo utilizza MySQL come software di database per archiviare
i dati provenienti dai misuratori. La libreria per interfacciare il database con il software è
chiamata MySQL
Connectior/J.\\
Si tratta di un driver Java nativo che converte chiamate JDBC (Java Database Connectivity) nel
protocollo di rete utilizzato dal database. Ciò consente di non vincolarsi all'utilizzo di questo
specifico database utilizzando una sintassi specifica, ma di effettuare semplicemente chiamate con
una sintassi standard adattaile ad ogni database. \\
MySQL Connectior/J è un driver JDBC di tipo IV, cioè scritto totalmente in Java ed autosufficiente.
E' perciò portatile fra diverse architetture del sistema operativo. Di seguito si riporta il codice
utilizzato per la connessione al database.
\begin{verbatim}
public static Connection getConnection() {
    ...
    Connection conn = null;
    try {
      Class.forName("com.mysql.jdbc.Driver").newInstance();
      conn = DriverManager.getConnection(DBUrl, user, password);
      return conn;
    }
    catch (Exception e) {
        System.err.println(e);
        return null;
    }
}
\end{verbatim}


\section{Files di configurazione}
Il file di configurazione del sistema è basato su una sintassi XML che separa le impostazioni
relative alle diverse funzionalità. \\
I tag di primo livello individuano parametri globali del sistema, oppure sezioni differenti del
software. Il server principale è identificato dalla sezione \texttt{netwatch}. Per ogni server
possono essere attivate le tre funzioni di \texttt{listener}, \texttt{sender} e
\texttt{query--responder}.
\subsection{Configurazione del \texttt{listener}}
La funzionalità di \texttt{listener} attiva la ricezione dei dati dai monitor di rete oppure da
altri GNRB posti gerarchicamente più in basso. Al momento gli unici parametri configurabili per
questa funzionalità sono:
\begin{itemize}
\item{\textbf{start}: indica se il listener deve essere
attivato oppure no;}
\item{\textbf{port}: quale porta utilizzare per ascoltare gli stream dati;}
\item{\textbf{displaywindow}: true/false indica se deve essere attivata una finestra di monitoraggio del
database locale.}
\end{itemize}
\subsection{Configurazione del \texttt{sender}}
La funzionalità di \texttt{sender} è quella che attiva i monitor interni al sistema, interpreta i
risultati e li spedisce, via stream XML, al \texttt{listener}. I tag di configurazione sono:
\begin{itemize}
\item{\textbf{start}: attivazione o meno del servizio;}
\item{\textbf{server}: l'indirizzo ip del server verso cui inviare i risultati ottenuti;}
\item{\textbf{port}: la porta su cui il server ascolta.}
\end{itemize}
\subsection{Configurazione del \texttt{query--responder}}
La funzionalità di \texttt{query--responder} è quella che consente al nodo GNRB di interagire con i
client o con l'infrastruttura Grid. E' possibile non attivare questa funzionalità se si è
interessati alla configurazione di un nodo di solo passaggio e collezione dati. Ci sono al momento
solo due parametri configurabili:
\begin{itemize}
\item{\textbf{start}: attivazione o meno del servizio;}
\item{\textbf{port}: la porta su cui il \texttt{query--responder} riceve le request.}
\end{itemize}

\subsection{Esempio di file di configurazione}
\begin{verbatim}
<configuration>
 <DBUrl>jdbc:mysql://127.0.0.1/netwatch</DBUrl>
 <osversion>LINUX</osversion>
 <netwatch>
  <listener>
   <start>true</start>
   <port>32000</port>
   <displaywindow>false</displaywindow>
  </listener>
  <sender>
   <start>false</start>
   <port>32000</port>
   <server>127.0.0.1</server>
  </sender>
  <router>
    <address>172.16.1.1</address>
    <username>user</username>
    <password>*****</password>
  </router>
  <queryresponder>
   <start>true</start>
   <port>32001</port>
   <configurablerouter>
    <type>juniper</type>
    <ipexposed>131.114.53.153</ipexposed>
    <user>nicola</user>
    <password>pippo</password>
    <externalcommand>junconfig.bat</externalcommand>
   </configurablerouter>
  </queryresponder>
 </netwatch>
 <watcher>
    <start>true</start>
    <pathdiscoverer>
        <start>true</start>
        <command>traceroute -n</command>
        <target>172.16.10.1</target>
    </pathdiscoverer>
    <snmpbandwidthcalculator>
        <target>172.16.0.17</target>
        <source>172.16.0.18</source>
        <SNMPServer>217.9.66.53</SNMPServer>
        <SNMPVersion>2c</SNMPVersion>
        <community>public</community>
        <oidcapacity>.1.3.6.1.2.1.2.2.1.5.73</oidcapacity>
        <oidinput>.1.3.6.1.2.1.2.2.1.10.73</oidinput>
        <oidoutput>.1.3.6.1.2.1.2.2.1.16.73</oidoutput>
        <entity>link</entity>
        <characteristic>bandWidth</characteristic>
        <subcharacteristic>available</subcharacteristic>
    </snmpbandwidthcalculator>
    <snmpquery>
        <target>121.0.0.251</target>
        <source>121.0.0.5</source>
        <SNMPServer>121.0.0.251</SNMPServer>
        <SNMPVersion>1</SNMPVersion>
        <community>public</community>
        <oid>.1.3.6.1.2.1.2.2.1.5.1</oid>
        <entity>link</entity>
        <characteristic>bandWidth</characteristic>
        <subcharacteristic>maximum</subcharacteristic>
    </snmpquery
 </watcher>
</configuration>
\end{verbatim}

\section{Monitor di rete implementati}
Sono stati integrati nel prototipo alcuni monitor di rete, necessari per l'esecuzione dei test
sull'anello ottico. \\
I monitor \textbf{snmpquery} e \textbf{snmpbandwidthcalculator} (si vedano gli omonimi tag XML
nell'esempio di file di configurazione proposto), consentono di interrogare router o apparati che
implementano il protocollo SNMP versione 1, 2c o 3. In particolare \texttt{snmpquery} rappresenta
una semplice richiesta per ottenere un singolo valore dall'apparato. Questo valore è identificato
dall'\texttt{oid} specificato nel file di configurazione. I parametri \texttt{target} e
\texttt{source} identificano il ramo di rete alla quale la grandezza ottenuta fa riferimento. I
parametri \texttt{SNMPVersion}, \texttt{SNMPServer}, \texttt{community}, contengono i valori
necessari ad identificare la versione di SNMP supportata, l'apparato che si intende interrogare, e
la community da utilizzare per la richiesta. Infine i parametri \texttt{entity},
\texttt{characteristic}, \texttt{subcharacteristic} classificano il valore ottenuto. \\
Il monitor \texttt{snmpbandwidthcalculator} si basa su \texttt{snmpquery} per calcolare la banda
disponibile istantaneamente su un link.


\section{Descrizione dei package}
La struttura delle classi Java del progetto, è stata pensata in modo da isolare il più possibile le
funzionalità in differenti \texttt{package}, e di consentire l'implementazione di classi differenti
ed interscambiabili per adattarsi alle condizioni di esecuzione. \\
E' infatti sufficiente aggiungere classi dotate delle stesse interfacce e opportune voci di
configurazione per espandere a piacere le tecniche di misurazione, gli strumenti per lo storage dei
dati, gli algoritmi di ricerca dei percorsi, ecc... \\
Il codice è organizzato in maniera tale da includere nello stesso package le classi che fanno
riferimento ad una specifica funzionalità dell'applicazione. Le classi sono ovviamente
interconnesse, ma il loro raggruppamento nei package consente di identificare e manutenere più
facilmente specifiche porzioni di codice. Alcuni package sono presenti nell'applicazione solo con
scopo di debug, oppure sono ancora in fase di completamento. \\
Fra questi package troviamo quelli relativi all'interfaccia grafica \textbf{netwatch.ui} e
\textbf{netwatch.ui.jung}, i quali non sono determinanti per il funzionamento del sistema. Il
package \textbf{network.configuration} include, la classe con la funzione di leggere ed
interpretare il file di configurazione principale del sistema. Di tale file è stata data in
precedenza una descrizione completa. I valori dei vari settaggi, dopo essere stati validati
attraverso il parser XML, vengono assegnati a variabili pubbliche dell'oggetto, le quali sono
accessibili ove necessario nel software. \\
Il package, \textbf{network.client}, è esterno alle funzionalità del GNRB vero e proprio, ma
rappresenta un'applicazione a parte che viene utilizzata per testare gli altri moduli del sistema.
Si può infatti utilizzare tale applicazione per inviare specifiche \texttt{request} al server e
catturare il risultato in un file. Tale risultato può essere successivamente valutato insieme agli
effetti che la \texttt{request} ha prodotto sulla configurazione della rete. La struttura dati
principale utilizzata dal server, è basata sul modello
\texttt{entità.caratteristica.subcaratteristica}. Questo modello, opportunamente espanso, viene
mappato su una gerarchia di classi all'interno del package \textbf{netwatch.data}. La figura
descrive la fondamentale struttura di relazioni fra
classi. \\
struttura.vsd \\
E' importante notare che l'unica funzionalità associata alle classi del package
\texttt{netwatch.data} è quella di sapersi serializzare in XML. Ogni oggetto istanziato a partire
da queste classi possiede, infatti, due metodi: \texttt{fromXML()} e \texttt{writeXML()} che gli
consentono rispettivamente di istanziare tutto il resto della gerarchia figlia, oppure di esportare
tutta la struttura e i dati.
\begin{verbatim}
public void fromXML(Node node) {
 int type = node.getNodeType();
 if (type == Node.ELEMENT_NODE) {
    NodeList children = node.getChildNodes();
      if (children != null) {
       for (int i = 0; i < children.getLength(); i++) {
          Node n1 = children.item(i);
          String name1 = n1.getNodeName();
          ...
            }
          }
        }
      return;
}
\end{verbatim}
Si è ritenuto opportuno inserire tali capacità in queste classi per una questione di pulizia del
codice che rappresenta la vera e propria logica di funzionamento del GNRB. In generale, nella
programmazione, si è cercato di rispettare la regola di delegare ai singoli oggetti tutte le
funzionalità specifiche dell'entità che rappresentano. \\
La classe di partenza del server GNRB è \texttt{mainapp} ed è posizionata nel package
\textbf{netwatch.collector}. L'oggetto \texttt{mainapp}, a seconda dei settaggi presenti nel file
di configurazione, istanzia gli oggetti che attivano o meno la varie funzionalità del software. \\
StrutturaPackage.bmp \\
Il package \texttt{netwatch.collector}, contiene le classi che consentono il funzionamento del
\texttt{listener} e del \texttt{sender}. Le classi \texttt{Listener} e \texttt{Sender} di questo
package, sono estensioni della classe Thread della libreria di base del linguaggio Java. Queste
vengono attivate in maniera asincrona quando si verifica un evento che ne richiede
l'utilizzo, e portano a termine il loro compito terminando autonomamente. \\
Il \texttt{Sender} può infatti essere utilizzato sia per rinfrescare periodicamente i dati del
server GNRB che si trova gerarchicamente più in alto, sia per trasmettere il risultato di una
misura specifica allo storage. Nel primo caso l'oggetto \texttt{Sender} periodicamente si attiva,
compiendo il proprio lavoro in background. Nel secondo caso è una specifica chiamata nel codice a
provocare la spedizione del flusso di dati verso il server. \\
Il \texttt{Listener} funziona sempre rimanendo in attesa di dati sulla porta specificata nel file
di configurazione. All'arrivo di una connessione sulla porta TCP, istanzia un oggetto di tipo
\texttt{DataCollector} e gli passa la connessione TCP, rimettendosi in ascolto sulla porta nota in
attesa di ulteriori collegamenti. Il \texttt{DataCollector} è l'oggetto che si occupa di
interpretare e validare lo stream XML che riceve e aggiungerlo al database delle misurazioni
locali. Per una descrizione più approfondita del funzionamento dei moduli \texttt{sender},
\texttt{listener} e \texttt{datacollector}, si faccia riferimento alla figura \ref{gera} ed al
capitolo precedente.

\chapter{Test di funzionamento di GNRB su anello ottico}
\pagestyle{fancy} \thispagestyle{empty} \fancyhead[RO,LE]{Capitolo 5} \fancyhead[LO,RE]{\emph{Test
di funzionamento di GNRB su anello ottico}} \fancyfoot[RO,LE]{\thepage}

\section{Introduzione}
L'esperimento effettuato sul testbed dell'area pisana si ripropone di verificare il funzionamento
del prototipo GNRB in un semplice caso di interrogazione di tipo Quality Of Service. \\
L'esperimento ha utilizzato le macchine della Grid pisana posizionate presso l'Università di Pisa,
il CNIT e il CNR. Sugli elaboratori utilizzati per il test, è stato installato il run--time
dell'ambiente Java e il software descritto nel capitolo precedente. Ogni elaboratore è equipaggiato
con sistema operativo Linux. Come sarà mostrato in seguito alcuni dei computer avevano
semplicemente la funzionalità di monitor, un altro è stato utilizzato solo come client, infine uno
è stato usato da server. \\
Con riferimento alla figura che descrive l'anello ottico pisano, sono
state configurate le seuenti sottoreti: 172.16.1.0 e 172.16.2.0 presso l'Università. All'interno di
queste sottoreti troviamo il server GNRB con indirizzo 172.16.1.10 e un client con indirizzo
172.16.2.5.

\section{Test di monitoraggio della rete}
Sul server (hostname \texttt{triallap}) sono state attivate anche funzionalità di monitoring, come
descritto in seguito. \\ Il primo test realizzato, doveva verificare la capacità dei monitor di
dialogare con il server e di comunicare misure corrette. Bisognava anche verificare che il numero
di connessioni aperte dai monitor verso il server e dal server verso il database MySQL, non
saturassero il sistema, venissero correttamente deallocate e il loro numero si stabilizzasse e non
crescesse con il funzionamento prolungato. In questa fase, attivando il sistema, sono stati
individuati e corretti due errori di deallocazione delle risorse. Si è ottenuto che il server si
dimostrasse solido sia rispetto alle misurazioni che lui stesso effettua, sia rispetto alle
connessioni che riceve dagli altri monitor disposti sulla rete.

\subsection{Discovery della topologia}
La topologia viene individuata attraverso lo strumento \texttt{PathFinder} incluso nel prototipo.
Configurando opportunamente le destinazioni dei test in funzione degli indirizzi conosciuti dei
router dell'anello si riesce a ricavare l'insieme di tutti i link e delle interfacce alle quali
sono collegati. Le interfacce rappresentano un altro problema, in quanto il sistema deve essere in
grado di capire che lo stesso nodo di rete si presenta con indirizzi IP differenti.\\
Nella ricerca dei percorsi tuttavia è necessario tenere conto che può esistere routing fra le
interfacce individuate e che in realtà appartengono alla stessa macchina. Di conseguenza bisogna
costruire un'opportuna magliatura fra di esse. Se questa operazione non venisse compiuta la rete
apparirebbe come un insieme di link con agli estremi i nodi corrispondenti alle interfacce e
totalmente disconnessi l'uno dall'altro. La soluzione che è stata implementata nel prototipo,
tuttavia, dovrà in futuro essere raffinata, in quanto al momento non consente di individuare in
maniera ben definita i singoli apparati, ma solo le loro interfacce ed i collegamenti fra essi. \\
Per ricavare l'elenco completo delle interfacce del router, sono state utilizzate chiamate a
routine \texttt{junoscript} compatibili con i router Juniper. Tali chiamate restituiscono un file
XML il quale viene opportunamente parsato dalla classe \texttt{RouterInspector}. Al termine di
questo processo i dati ricavati vengono opportunamente aggiunti al database della topologia. La
configurazione dei monitor è fatta in modo tale da riuscire sempre ad individuare tutti i link.

\subsection{Banda disponibile}
La banda disponibile sui tre link fondamentali dell'anello ottico si ottiene attraverso il tool
\texttt{SNMPBandWidthQuery} che interroga via SNMP un dispositivo e ne ricava la banda disponibile
sulle varie interfacce. Purtroppo l'albero degli OID standard di SNMP prevede che, interfaccia per
interfaccia, siano disponibili i contatori progressivi del numero di otteti in uscita ed in
entrata, ma non della banda disponibile istantaneamente sull'interfaccia stessa. La misura di banda
disponibile perciò viene calcolata come la differenza fra due valori successivi dei contatori di
traffico divisa per il tempo trascorso fra le due misure.
\begin{displaymath}
Bandwidth=8*\frac{C_{t_2} - C_{t_1}}{t_2-t_1} bit/sec
\end{displaymath}
Ciò che si ottiene è una misura mediata ma piuttosto accurata. Le misure di banda vengono ripetute,
a seconda dei tempi di risposta dei router alle interrogazioni, ogni circa 20 secondi. Questo
risulta essere, di conseguenza, l'intervallo minimo di risoluzione temporale del nostro prototipo
GNRB. Non sembra tuttavia che questo rappresenti un limite stringente. In situazioni di carico e di
utilizzo di reti ad alta capacità, le variazioni complessive di utilizzo dei link probabilmente non
saranno così istantanee. \\
In ogni caso, i router Juniper possono essere interrogati in maniera probabilmente più efficace
tramite le proprie routine proprietarie. Non è comunque realistico pensare di riuscire ad ottenere
misure più frequenti rispetto a qualche secondo. \\
\newline
Di seguito vengono riportati il grafico della topologia di rete ricavata dall'attività del sistema
(ignorando le interfacce dei router non interessate al test) e il grafico del log della banda
disponibile misurata sul link specificato durante i test. L'introduzione di traffico sul link
infatti, è stato alla base del secondo test, quello di risposta alla request di tipo QoS.
\section{Test di richiesta QoS}
Lo scopo di questo test è verificare che il sistema GNRB sfrutta le conoscenze acquisite sullo
stato della rete per tentare di fornire agli utenti abilitati un servizio migliore. La bassa
complessità della topologia di rete a disposizione, rende questa prova di comprensione intuitiva ed
evidenzia il significato del Grid Network Resource Broker in un ambiente per Grid Computing. \\
Il test è stato eseguito secondo la seguente modalità:
\begin{itemize}
\item{Fase 1 - Anello scarico: il client invia al server la richiesta per un servizio con Quality
Of Service garantita verso 192.164....}
\item{Fase 2 - Il server risponde individuando il percorso più breve per raggiungere la
destinazione}
\item{Fase 3 - Generazione di traffico di disturbo sul link per simulare l'attivazone del servizio
Grid.}
\item{Fase 4 - Ripetizione della stessa richiesta, con un valore di banda minima garantita non più
sostenibile dal link su cui ora c'è traffico.}
\item{Fase 5 - Il server risponde questa volta indicando gli altri link dell'anello, i quali
risultano scarichi.}
\end{itemize}

\section{Esecuzione del test QoS}
Di seguito vengono descritte più in dettaglio le fasi di esecuzione precedentemente elencate. Si
tenga in considerazione che si sta simulando il funzionamento in ambiente Grid. Il traffico che
viene generato artificialmente sul link che vogliamo impegnare, simula quello prodotto da un
servizio Grid ad alta necessità di trasferimento dati. Si osservi che in questo caso, senza
l'impiego del sistema GNRB, non sarebbe possibile garantire ad entrambe le richieste di servizio
sufficienti risorse, in quanto entrambi i servizi Grid tasferirebbero dati sullo stesso link. \\
\subsection{Fase 1 - Richiesta di servizio con anello scarico}
Si simula la situazione in cui il \emph{middleware} di griglia, interagendo con GNRB, vuole
istanziare un servizio che richieda 100MBit di banda garantita. Il \emph{middleware} prepara una
\texttt{request} di tipo QoS nella quale specifica il provider di servizio grid ed il requisito
minimo richiesto.
\begin{verbatim}
<requests>
 <request>
  <type>QualityOfService</type>
  <requestId>1</requestId>
  <jobId>JobTest</jobId>
  <parameter>
    <entity>link</entity>
    <characteristic>bandWidth</characteristic>
    <subcharacteristic>available</subcharacteristic>
    <value>100000000</value>
  </parameter>
  <path>
      <source>151.6.0.145</source>
      <target>195.210.91.100</target>
  </path>
 </request>
</requests>
\end{verbatim}
\subsection{Fase 2 - Risposta del server ad anello scarico}
In condizioni di anello scarico, il server GNRB prende in considerazione il seguente valore nel
database delle misurazioni:
\begin{verbatim}
172.16.0.9 -> 172.16.0.10: link.bandWidth.available = 9.99e+9
\end{verbatim}
Insieme alla conoscenza della topologia dell'anello e delle interfacce sui due router agli estremi
(Università di Pisa e CNR), questa informazione è sufficiente al server per identificare questo
path come il più efficace capace di garantire la qualità di servizio richiesta. \\
Questo percorso è anche quello che il routing prevede per default, di conseguenza il server non
intraprende nessuna azione sui router.
\subsection{Fase 3 - Generazione del traffico di simulazione e di disturbo}
Procedendo nella simulazione, a questo punto il \emph{middleware} grid, identificato che il
percorso che impegna il link tra le interfacce 172.16.0.9 e 172.16.10 è quello preferibile,
attiverebbe il servizio. \\
L'attivazione del servizio produrrebbe traffico sul link. Simuliamo il caso in cui anche altro
traffico cominci ad essere presente sul link 172.16.0.9-172.16.0.10, in quantità tale da lasciare
libera una banda inferiore ai 100Mb. Utilizziamo per questo scopo un generatore di traffico
direttamente collegato al router di Ingegneria con interfaccia Gigabit. Bisogna ricordare che i
link che costituiscono l'anello ottico sono capaci di trasportare 1Gb, il che può non essere facile
da saturare con un numero limitato di elaboratori dotati di scheda Fast Ethernet a 100Mb. \\
Dopo l'attivazione del generatore di traffico, rimane meno del 5\% del link libero.
\subsection{Fase 4 - Richiesta di servizio con link di anello saturo}
A questo punto, ripetiamo la stessa richiesta di servizio effettuata nella Fase 1 del test. E'
chiaro che ora le condizioni di rete sono variate e che la risposta che il server ha fornito
precedentemente non sarà più corretta.
\subsection{Fase 5 - Risposta del server ad anello carico}
Il server, ricevuta la richiesta di servizio, opera nel modo seguente:
\begin{enumerate}
\item{ricostruisce la topologia di rete conosciuta,}
\item{elimina tutti i rami che non soddisfano la caratteristica richiesta,}
\item{applica l'algoritmo Dijkstra Shortest Path al grafo rimanente.}
\end{enumerate}
Lo stato del monitoraggio adesso indica la situazione seguente per l'anello:
\begin{verbatim}

172.16.0.9  -> 172.16.0.10: link.bandWidth.available = 50e+6

172.16.0.17 -> 172.16.0.18: link.bandWidth.available = 9.99e+9

172.16.0.21 -> 172.16.0.22: link.bandWidth.available = 9.99e+9

\end{verbatim}
In questa condizione, l'algoritmo esclude il primo link e la ricerca dello shortest path passa per
forza di cose attraverso gli altri due. La risposta inviata dal server al client, di conseguenza
indicherà un percorso alternativo rispetto a quello precedente. Per fare in modo che i pacchetti
inviati dal client all'attivazione del servizio Grid, passino effettivamente attraverso il nuovo
percorso, il server GNRB interagisce con il router che ha la funzione di gateway fra il client e
l'anello. Il server attiva una connessione di tipo \texttt{telnet} o \texttt{ssh} con il router, si
autentica e attiva un \emph{Label Switched Path} per i pacchetti della nuova connessione.

\section{Conclusioni e sviluppi futuri}
In conclusione si è tentato di mostrare, con questo lavoro, che la costruzione di un sistema di
\emph{Grid Computing} efficiente, richiede il supporto di una gestione di rete superiore a quella
attualmente disponibile. Nel sostenere tale affermazione, si è individuato il più opportuno
posizionamento dell'\emph{intelligenza} necessaria al supporto Grid nella rete stessa. \\
Nell'architettura proposta, viene utilizzato il criterio secondo cui la rete dovrebbe essere
un'entità in grado di funzionare al meglio delle proprie possibilità indipendentemente dal supporto
che può ottenere dalle applicazioni che la sfruttano. Il \emph{Grid Network Resource Broker} deve
essere interpretato come un primo passo verso una struttura di rete il più autonoma e performante
possibile. In questo senso lo sviluppo futuro deve orientarsi verso la caratterizzazione dei
requisiti delle applicazioni di griglia. Si parla già di approccio \emph{Path--Oriented} oppure
\emph{Knowledge--Oriented}, a seconda che l'applicazione possa essere classificata in un gruppo
predefinito, da cui la rete ricava le caratteristiche di funzionamento, oppure no. \\




\begin{thebibliography}{99}
\bibitem{seti} \emph{The SETI@home web site.} \\Pagina web: http://setiathome.ssl.berkeley.edu/index.html
\bibitem{anatomy} I.~Foster, C.~Kesselman, S.~Tuecke. \emph{The Anatomy of the Grid.} Enabling Scalable Virtual Organizations.
\bibitem{physiology} I.~Foster, C.~Kesselman, J.~Nick, s.~Tuecke. \emph{The Physiology of the Grid.} An Open Grid Services Architecture for Distributed Systems Integration.
\bibitem{ogsa} Global Grid Forum. \emph{Overview of OGSA.} http://www.gridforum.org
\bibitem{events} B.~Lowekamp, B.~Tierney, C.~Cottrell, R.~Hughes-Jones, T.~Kielmann, M.~Swany: \emph{A Hierarchy of Network Performance Characteristics for Grid
Applications and Services}
\bibitem{course} \emph{Course Introduction (cont.) and Introduction to Globus.} Joint work of USC Information Sciences Institute and Argonne National Laboratory.
\end{thebibliography}
\addtocontents{toc}{\protect\clearemptydoublepage}
\end{document}
