Progettazione e sviluppo di una piattaforma di power ... · della sesta versione del protocollo (IPv6) per far fronte a questa crescita che sembra inarrestabile. Anche in un contesto

POLITECNICO DI MILANOFacolta di Ingegneria dell’Informazione

Corso di Laurea Specialistica in Ingegneria Informatica

Progettazione e sviluppo di una piattaforma

di power management basata su architettura

multi-core per apparati di reti in fibra ottica

Relatore: prof. Carlo BrandoleseCorrelatore: Giorgio Parladori

Tesi di laurea diMichele MELCHIORImatricola 735358

Anno Accademico 2011/2012

Experience is what you getwhen you don’t get what you want

Randolph Frederick (Randy) Pausch(1960-10-23 — 2008-07-25)

Alla mia famigliaai miei amici

e a tutte le persone che, in un modo o nell’altro,mi hanno supportato, sopportato e accompagnato

durante questo percorso.

Un grazie particolare a Nicola e Marco,per il supporto morale che hanno saputo darmi.

Indice

1 Introduzione ed obiettivi 11.1 Evoluzione delle reti di telecomunicazioni . . . . . . . . . . . . 11.2 Obiettivi di lungo periodo . . . . . . . . . . . . . . . . . . . . 31.3 Motivazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Obiettivo del lavoro di tesi . . . . . . . . . . . . . . . . . . . . 6

2 Architettura 92.1 Architettura d’insieme . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Scelte implementative . . . . . . . . . . . . . . . . . . 102.2 Tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Interne al nodo . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Esterne al nodo . . . . . . . . . . . . . . . . . . . . . . 15

3 Nodo di rete 193.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Architetture multi core . . . . . . . . . . . . . . . . . . . . . . 203.3 Comunicazione tra i due software . . . . . . . . . . . . . . . . 223.4 Avvio asimmetrico del nodo . . . . . . . . . . . . . . . . . . . 23

3.4.1 Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.2 Device Tree . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5 Software di dump . . . . . . . . . . . . . . . . . . . . . . . . . 253.6 Modello del consumo di potenza . . . . . . . . . . . . . . . . . 27

4 Comunicazione 294.1 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Struttura di un Web Service . . . . . . . . . . . . . . . . . . . 304.3 File WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 Implementazione in PHP . . . . . . . . . . . . . . . . . . . . . 344.5 Implementazione in JavaScript . . . . . . . . . . . . . . . . . . 354.6 Interfaccia con l’amministratore . . . . . . . . . . . . . . . . . 36

4.6.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . 36

V

VI INDICE

4.6.2 Client JavaScript . . . . . . . . . . . . . . . . . . . . . 38

5 Risultati ottenuti 39

6 Conclusioni 436.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

A Modello XML del nodo 47A.1 Modello XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.2 File DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

B Avvio asimmetrico 51B.1 Device Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51B.2 Configurazione dell’avvio asimmetrico . . . . . . . . . . . . . . 53

B.2.1 Configurazione e compilazione dei device tree . . . . . 53B.2.2 Configurazione e compilazione dei kernel . . . . . . . . 54

C Metodi implementati 55

Elenco delle figure

1.1 Esempio di rete con carico asimmetrico . . . . . . . . . . . . . 31.2 Struttura di esempio di un nodo di rete . . . . . . . . . . . . . 5

2.1 Confronto tra soluzione centralizzata e distribuita . . . . . . . 102.2 Schema della soluzione per un generico nodo di rete . . . . . . 122.3 Passaggio da architettura single core a dual core . . . . . . . . 132.4 Confronto tra DBMS con software server e DBMS embedded . 152.5 Architettura basata su Web Service con PHP e JavaScript . . 18

3.1 Diversi approcci alla programmazione multicore . . . . . . . . 203.2 Aggiunta dei power manager alla rete . . . . . . . . . . . . . . 23

4.1 Architettura generale di un Web Service . . . . . . . . . . . . 314.2 Esempio di doppia RPC . . . . . . . . . . . . . . . . . . . . . 324.3 Confronto di specifiche tra WSDL 1.1 e 2.0 . . . . . . . . . . . 334.4 Struttura interna del provider . . . . . . . . . . . . . . . . . . 344.5 Struttura interna del requester . . . . . . . . . . . . . . . . . . 35

5.1 Direzioni nelle quali e stato trasferito il file di test . . . . . . . 405.2 Architettura logica della rete di test . . . . . . . . . . . . . . . 405.3 Schema di esecuzione di una query distribuita . . . . . . . . . 41

C.1 Alberi delle strutture dati da fornire ai metodi implementati . 57C.2 Albero della struttura dati restituita dai metodi implementati 57

VII

VIII ELENCO DELLE FIGURE

Sommario

La crescita di importanza delle reti di telecomunicazione nella societaodierna e un fatto ormai risaputo. Tali reti permettono di collegare qualsiasidispositivo elettronico che ruota attorno alla persona, a partire da quelli piuovvi, come computer e telefoni cellulari, fino a raggiungere gli strumenti piuremoti, come quelli dedicati alla gestione automatica dell’illuminazione e delriscaldamento all’interno delle case. Questo ha permesso di modificare lemodalita con le quali si utilizza la rete: la navigazione web sta perdendo diimportanza, a favore di servizi evoluti e di maggiore interattivita come latelefonia o l’online gaming.

Anche all’interno di realta piu piccole della rete Internet, come ad esempionelle aziende o nelle universita, si sta riscontrando la stessa tendenza adampliare la rete di comunicazione interna, in modo che possa offrire agli utentiuna piattaforma con la quale sia possibile accedere a risorse distribuite, comead esempio uno spazio di archiviazione remoto tramite il quale sia possibilecondividere progetti e documenti o fare in modo che file e archivi importantisiano registrati in sicurezza su supporti di backup.

Una proprieta dei dispositivi che sono alla base del funzionamento dellereti e il fatto che il loro consumo di potenza, anche se non costante, non variadi molto in funzione del carico di lavoro; questa osservazione, accoppiata aquella che permette di affermare che il traffico dati gestito dalla rete non ecostante nel tempo ne uniforme, porta a notare che la rete e un’area nellaquale si trovano sprechi energetici proporzionali alla sua estensione. Questisprechi, se non correttamente gestiti, in caso di reti discretamente estesepossono essere considerati come non trascurabili.

Scopo del lavoro di tesi e progettare e costruire una base per una piatta-forma che fornisca dei servizi di power saving proprio dei dispositivi di rete,con l’obiettivo di ridurre al minimo gli sprechi energetici del networking senzaintaccare le prestazioni alle quali gli utenti della rete sono abituati.

Capitolo 1

Introduzione ed obiettivi

In questo capitolo si presenta l’obiettivo del lavoro di tesi. Inizialmente sidescrive il contesto all’interno del quale si andra ad operare, evidenziando leproblematiche e le limitazioni della soluzione attuale e suggerendo un obiet-tivo di lungo periodo nei termini di quelle che dovrebbero essere le nuove fun-zionalita fornite per risolvere completamente tali problematiche. Si esponeinfine una breve analisi dei passi che devono essere compiuti per raggiungeretale obiettivo, e una descrizione delle principali attivita sviluppate nel corsodella tesi in questa direzione.

1.1 Evoluzione delle reti di telecomunicazioni

Le reti di telecomunicazione rivestono un’importanza sempre maggiore all’in-terno della societa odierna. Le infrastrutture di rete, inizialmente concepiteper supportare i servizi di telefonia, stanno sempre piu evolvendo verso un’in-frastruttura a supporto della connettivita dati globale, in cui si assiste allaconvergenza e all’integrazione di tecnologie e soluzioni di complessita semprecrescente, con scopi che vanno oltre la semplice comunicazione tra perso-ne ma includono anche e soprattutto servizi piu evoluti. Gli utenti si sonospostati dall’utilizzo del telefono fisso o del cellulare sempre piu verso lo sfrut-tamento della gratuita del del VOIP (Voice Over Internet Protocol) e, datala maggiore larghezza di banda a disposizione, hanno avuto la possibilita dicomunicare tramite video chiamate e video conferenze.

Anche la distribuzione di contenuti multimediali, come televisione e radio,sta evolvendo verso Internet: e diventata cosa normale trovare pubblicati trale pagine del sito web di un’emittente alcuni contenuti gia mostrati in pas-sato tramite i canali standard (podcast), e spesso e anche a disposizione unostreaming in tempo reale di quanto si sta trasmettendo sulla rete dedicata.

1

2 CAPITOLO 1. INTRODUZIONE ED OBIETTIVI

Questo ha gettato la base per i concetti di IPTV e di video on demand,nei quali i contenuti sono fruibili dall’utente direttamente tramite il propriotelevisore, il quale pero li ottiene tramite la rete Internet.

Nel campo della domotica esistono soluzioni che permettono ad una per-sona di controllare la sorveglianza, l’illuminazione, il riscaldamento ed altriservizi della propria abitazione da qualsiasi punto della Rete.

I punti di accesso sono in continua crescita, tanto che gli indirizzi delprotocollo IPv4 non sono piu sufficienti ad identificare ogni singolo dispositivoconnesso, nonostante ve ne siano a disposizione piu di quattro miliardi. Daqui la tecnica del subnetting e, successivamente, la proposta dell’introduzionedella sesta versione del protocollo (IPv6) per far fronte a questa crescita chesembra inarrestabile.

Anche in un contesto aziendale la rete sta assumendo un’importanza sem-pre piu vitale: da tempo i dipendenti devono collaborare e mantenere i con-tatti anche se appartengono ad aree diverse o se si trovano in regioni distantitra loro. Le conferenze audio e video sono diffuse molto piu che nel mer-cato customer, inoltre l’evoluzione dei vari servizi a livello di cloud rendonosemplice la condivisione di file e la collaborazione, al prezzo pero di una mag-giore pressione sulla rete. Questa in tutti i settori diventa sempre piu ampiae pervasiva, di conseguenza le sue capacita, in termini di larghezza di banda,devono almeno inseguire la sua estensione.

I componenti base di ogni rete sono gli apparati di networking, ovveroquell’insieme piu o meno ampio di hub, bridge, switch e router che, connessitra loro e ai client della rete, forniscono agli utilizzatori le funzionalita del-la rete stessa. La continua crescita ed evoluzione di quest’ultima richiedeun incremento del numero e delle capacita di questi apparati, in modo daconsentire ad ogni nuovo client di avere la possibilita di poter sfruttare iservizi messi a disposizione dalla rete o fornire i propri senza dover soffrirelimitazioni di banda.

Ognuno di questi dispositivi deve essere collegato alla rete elettrica perpoter funzionare, ed il suo consumo di potenza e proporzionale alle presta-zioni che fornisce. Da questo deriva che l’incremento del numero di apparati,delle connessioni e dei punti di accesso alla rete porta un incremento pro-porzionale del consumo di potenza che diventa sempre meno trascurabile nelbilancio energetico di un’azienda.

Inoltre, come e facile immaginare, il carico di lavoro demandato alla retenon gode della proprieta di essere costante nel tempo: ad esempio di notte iltraffico da gestire e quasi nullo, mentre durante il giorno si avranno dei picchidi massimo. Un’altra proprieta che non si puo assegnare al carico sulla retee l’uniformita nello spazio: ad esempio se si analizza la rete di Figura 1.1 sipuo notare che molti nodi stanno comunicando con il server evidenziato, di

1.2. OBIETTIVI DI LUNGO PERIODO 3

n0 n1 n2 n3

n4

n5n6

server

Figura 1.1: Esempio di rete nella quale alcune connessioni (in neretto) sonosoggette ad un maggior traffico rispetto alle altre

conseguenza la maggior parte del traffico passa attraverso i link vicini a taleserver.

Va da se che la rete, soprattutto se situata in ambienti critici come ospe-dali o industrie che trattano materiali pericolosi, deve comunque essere ingrado di fornire la larghezza di banda minima garantita ad ogni dispositivo,pena il sovraccarico che porta ad un denial of service di un terminale chepotrebbe svolgere funzioni anche critiche.

L’obiettivo di lungo periodo che si vuole perseguire e che inizia con questolavoro e quindi quello di sviluppare ed implementare politiche di power savingdella rete con lo scopo di ridurre il consumo di potenza degli apparati dinetworking, sfruttando il fatto che, come appena descritto, l’utilizzo dei linknon e costante ne uniforme.

1.2 Obiettivi di lungo periodo

Da quanto e stato descritto nella sezione precedente e evidente la necessitadi porre la riduzione del consumo di potenza degli apparati di networkingtra gli obiettivi primari dello sviluppo di nuove reti di telecomunicazioni. Unmodo per ottenere cio e quello di modellare la rete come un insieme di ap-parati interconnessi, controllati da un elemento che gli permette di adattarsidinamicamente alle variazioni del carico di lavoro, disattivando le componen-ti meno utilizzate per aggregare il traffico sul minor numero di link possibile,ma anche riattivando quanto e stato posto in precedenza in stand-by nel casoil traffico torni ad aumentare.

Queste operazioni sono gia eseguibili manualmente da un operatore direte: esso infatti e in grado di connettersi ad ogni nodo e, tramite una shellremota, di impartire comandi di suspend e di wake-up. Queste operazioni,essendo lente e da eseguire nodo per nodo, sono fattibili solo se si ritiene che


una porzione della rete restera poco utilizzata per un periodo rilevante ditempo.

L’obiettivo che si vuole porre e la creazione di uno sviluppo sostenibiledelle reti di telecomunicazione, tramite la creazione di una soluzione softwareche sia in grado di gestirle in maniera dinamica e quasi in tempo reale, inmodo che sia possibile applicare una politica di risparmio energetico senzala necessita dell’intervento di un operatore umano. Per poter fare cio ilsoftware deve essere in grado di analizzare il livello di utilizzo dei singoli nodi edelle interfacce che li compongono: con queste informazioni deve determinareuna distribuzione del carico istantaneo sulla rete; se ha a disposizione anchedei dati storici puo tentare una sorta di previsione del traffico futuro. Adogni modo deve prendere delle decisioni riguardanti quali interfacce attivareo disattivare, in modo che nessun link sia sovraccaricato e, d’altro canto,nessuno sia attivo ma con un utilizzo minimo.

1.3 Motivazione

L’obiettivo che si vuole raggiungere e facilmente motivabile dopo un’analisidettagliata del consumo di potenza di un singolo apparato.

Struttura del nodo Un nodo di rete puo essere modellizzato come mo-strato in Figura 1.2. Esso e sostanzialmente una struttura gerarchica, chedi conseguenza si presta molto bene ad essere descritta con linguaggi comeXML o JSON; un esempio di file che descrive il nodo mostrato e presente inAppendice A.

Partendo dal livello piu basso si trovano le interfacce di rete, i dispositiviche gestiscono fisicamente il traffico dei dati sui link. La line card e la schedasulla quale sono montate le interfacce, il suo compito e quello di controllarlee smistare il traffico tra di esse. In un nodo di rete e possibile che sianomontate piu line card, quindi tra loro e sempre presente una matrice di switch(matrix ) con il solo scopo di instradare il traffico tra una line card e un’altra.Essendo un componente abbastanza vitale del nodo, essa e sempre affiancatada almeno una matrix di backup che in caso di problemi puo prendere ilsuo posto. A fianco di line card e matrix vi sono le altre parti comuni checompongono il nodo di rete, come l’alimentatore, la CPU ed il sistema diraffreddamento.

Ognuno di questi componenti ha un identificativo che ne evidenzia laposizione all’interno della rete. I nodi, essendo il componente piu in altonella gerarchia, hanno solamente un indice numerico progressivo; i dispositiviall’interno del nodo seguono una nuova numerazione con l’indice del nodo

1.3. MOTIVAZIONE 5

nodo

LC1 LC2

M2

M1

I1

I2

I1

I2

I3

I4

Fan

PSU CPU

Figura 1.2: Struttura di esempio di un nodo di rete

come prefisso: ad esempio nel nodo n si potrebbe avere n.1 per la CPU, n.2per l’alimentatore e n.5 per una line card. Ogni interfaccia di rete su questaline card sara identificata da un altro numero progressivo i, nella forma n.5.i.

Consumo di potenza Il modello di consumo di potenza creato per questidispositivi segue l’equazione:

P (t) = Ps + Pd ·BW (t)

MBW

dove P (t) e il consumo di potenza e BW (t) la larghezza di banda utilizza-ta, entrambi al tempo t. Gli altri elementi dell’equazione rappresentano iparametri statici del dispositivo:

Ps e il consumo di potenza statico, ovvero quanti Watt consuma il dispo-sitivo mentre e acceso e completamente in idle;

Pd e il massimo consumo di potenza dinamico, ovvero quella potenza inpiu rispetto a Ps che serve al dispositivo per gestire il traffico quandoBW (t) = MBW ;

MBW e la capacita massima, in termini di larghezza di banda, del dispositivo:il flusso massimo di dati che e in grado di controllare.

Su questo modello e interessante fare almeno due osservazioni. La primariguarda il consumo dinamico di potenza: nel funzionamento reale del di-spositivo tale consumo e influenzato non solamente dalla larghezza di bandautilizzata, ma anche da altri fattori, non ultimo la temperatura di esercizio;


e stato deciso di adottare questa funzione lineare in quanto e gia una buo-na approssimazione del comportamento reale del dispositivo, e permette dimantenere il modello in funzione delle sole variabili che e possibile controllaretramite il power manager, senza dover considerare componenti aleatorie.

La seconda considerazione riguarda invece la suddivisione presente nelmodello tra consumo di potenza statico e dinamico, che mette in evidenzacome il dispositivo assorbe energia anche se non sta eseguendo nessuna ope-razione, ma solamente per il fatto che esso e attivo. Per valutare il peso dellacomponente statica del consumo di potenza si consideri un’interfaccia otticain grado di gestire fino a 10Gb/s; i suoi parametri di funzionamento sonoPs = 20W e Pd = 10W . Significa che il suo consumo di potenza, quando eattiva, varia tra 20 e 30 Watt. Si prenda ora una parte di rete nella qualee presente un nodo sul quale arriva un traffico di 8Gb/s, questo puo essereindirizzato su due diverse interfacce che hanno gli stessi parametri appenaindicati. Si possono isolare due diverse situazioni:

1. le due interfacce sono entrambe attive: in questo caso, data la simme-tricita dei loro parametri, la somma dei loro consumi di potenza saradata da 2 · Ps + 8/MBW = 48W ;

2. il traffico e gestito completamente da una sola delle due interfacce,mentre l’altra e spenta: in questo caso la somma dei consumi di potenzasi riduce a Ps + 8/MBW = 28W .

Da questo esempio emerge che lo stesso servizio fornito dal nodo alla re-te, l’instradamento cioe di un traffico di 8Gb/s, puo essere completato inentrambe le situazioni elencate, ma nella seconda il consumo di potenza ecirca il 58% della prima: spegnere l’interfaccia che al momento puo restareinutilizzata porta ad una riduzione di circa il 40% dei consumi. Questo dimo-stra l’utilita di una piattaforma software in grado di disattivare le interfacceo i dispositivi poco utilizzati per poterli riattivare all’occorrenza quando ilvolume di traffico sulla rete torna a crescere.

1.4 Obiettivo del lavoro di tesi

Una soluzione software in grado di compiere le operazioni descritte si sviluppasu diversi livelli, ognuno dei quali richiede un ampio sviluppo.

Al livello piu basso vi e tutto quanto e richiesto per raccogliere le infor-mazioni di consumo di potenza all’interno di ogni nodo della rete e fare inmodo che queste informazioni siano accessibili al software di gestione. Que-sto prevede la progettazione di come raccogliere le informazioni, di come dar

1.4. OBIETTIVO DEL LAVORO DI TESI 7

loro persistenza fintanto che hanno un’utilita per le politiche di power ma-nagement ed infine del protocollo di comunicazione che permette al managerdi ottenere queste informazioni e di inviare comandi sulla rete.

Al secondo livello va creata un’interfaccia utente, con la duplice funzio-nalita di agire da piattaforma di debugging del livello base e di poter iniziarea far funzionare il sistema. Questa interfaccia infatti deve permettere ad unutente di ottenere determinare informazioni dalla rete, perche possa analiz-zarle e valutare l’invio di comandi di attivazione e disattivazione di apparati.Questo livello rappresenta una soluzione sub-ottima, in quanto la gestionedella rete e demandata ad un operatore umano, ma almeno rappresenta unapossibilita di analisi ed una velocizzazione nella gestione dei vari apparati,in quanto non necessita dell’accesso alla shell remota di ogni singolo nodo sucui si intende agire.

Piu in alto si trova la necessita di creare il programma che automatica-mente e in grado di gestire la rete. Questo deve essere in grado di eseguirein maniera autonoma quello che era compito dell’operatore al livello pre-cedente, fermo restando la possibilita del controllo manuale imposto da unamministratore umano.

Lavoro di tesi Data la vastita della soluzione completa questo lavoro ditesi si concentra sullo sviluppo del suo livello piu basso. Questa attivita sisuddivide in piu passi, dei quali il primo deve riguardare una progettazio-ne preventiva della struttura completa della soluzione: questa e esposta nelCapitolo 2. Durante questo passo devono essere anche compiute delle sceltedi natura tecnologica, per determinare quali, tra le alternative hardware esoftware individuate, si adattano meglio ai requisiti posti. La prima analisiva compiuta sulla piattaforma hardware a supporto del software embeddedche rappresenta il cuore del controllo e della gestione di ogni singolo nododi telecomunicazione, per valutarne in particolare l’evoluzione verso il multicore con l’obiettivo di rispettare i requisiti di scalabilita, affidabilita e flessi-bilita futura posti. Analisi successive vanno compiute tra i DBMS MySQL eSQLite confrontati con dei file di log, per determinare la soluzione migliorein grado di dare persistenza ai dati storici di consumo di potenza di ognidispositivo all’interno della rete. Sul piano delle comunicazioni le alternativeda valutare sono lo standard SNMP contro un’implementazione RESTful; daquest’ultima scaturisce inoltre anche la soluzione dei Web Services. Altretecnologie da valutare comprendono il boot asimmetrico del nodo di teleco-municazione tramite apposite configurazioni di U-Boot e dei relativi DeviceTree (Sezione 3.4), e di un Hypervisor di comunicazione tra due kernel dif-ferenti (Sezione 3.3). Per quanto riguarda gli endpoint della comunicazione


sono da valutare dei software dedicati in alternativa a script PHP e/o clientHTML con JavaScript.

Compiute le scelte implementative e necessario procedere con lo sviluppodi ogni componente del livello, sia per quanto riguarda il software in esecu-zione su ogni nodo di rete (Capitolo 3) che le configurazioni necessarie per lacorretta comunicazione tra i vari componenti (Capitolo 4). Il lavoro di tesisi concentra sulla creazione della piattaforma di base, relegando l’interfacciautente ad un’implementazione minimale, descritta nella Sezione 4.6, che hail semplice scopo di debug e analisi delle comunicazioni. Per l’analisi ed iltesting di funzionamento dell’avvio asimmetrico di due Sistemi Operativi e laloro successiva capacita di comunicazione e stata sfruttata una piattaformaQorIQTM P2020 fornita da Freescale. Questa e una piattaforma dual corebasata sull’architettura PowerPCTM, ed e stata scelta per la sua somiglianzacon l’hardware che va a comporre il cuore di un nodo di telecomunicazione.

Lo sviluppo di un’interfaccia amministrativa piu completa e dei livelli piuelevati della soluzione e rimandato a futuri lavori di estensione.

Capitolo 2

Architettura

In questo capitolo e analizzata la soluzione proposta. Nella prima parte cisi e soffermati sulla visione generale della soluzione e sul suo funzionamento,mentre solo successivamente si sono evidenziati i confronti tra le tecnologiedisponibili e le scelte progettuali che sono state fatte sulla base dei requisitispecifici della soluzione.

2.1 Architettura d’insieme

Dati gli obiettivi posti al capitolo precedente, la prima scelta da affrontare etra una soluzione centralizzata o distribuita. Nel primo caso (Figura 2.1a) siavrebbe la necessita di dedicare un dispositivo in rete ad eseguire due com-piti: fungere da server sul quale ogni altro nodo deve inviare periodicamentele letture dei valori misurati dai propri sensori e, in secondo luogo, analizzarei dati ricevuti per poter inviare comandi di accensione o spegnimento dei di-spositivi meno utilizzati. In questa situazione si ha che tutta l’informazionegenerata dai nodi e concentrata in un unico punto: questo porta alla pos-sibilita di implementare una politica molto piu accurata e complessa, datoche il power manager sarebbe a conoscenza della struttura dell’intera rete,ma a discapito di uno sbilanciamento del traffico nei pressi del manager, inquanto questo periodicamente deve poter ricevere le letture dai nodi. Talesbilanciamento cresce con le dimensioni della rete, in quanto l’aumentare delnumero dei nodi e seguito dall’incremento del volume di traffico necessario atrasmettere al manager ogni lettura.

In secondo luogo la soluzione centralizzata richiede che il manager siasempre online e che abbia spazio di archiviazione sufficiente a manteneretutto lo storico dell’intera rete. Tale storico deve poi essere analizzato, e

9

10 CAPITOLO 2. ARCHITETTURA

manager

database

n0

n1

n2

n3

(a) Centralizzata

thinmanager

n0

DB0

n1

DB1

n2

DB2

n3

DB3

(b) Distribuita

Figura 2.1: Confronto tra soluzione centralizzata e distribuita

questo puo richiedere capacita computazionali non indifferenti per reti didimensioni importanti.

In una soluzione distribuita (Figura 2.1b) si e invece in grado di suddivi-dere uniformemente su tutta la rete il traffico necessario al corretto funziona-mento delle politiche di power saving inoltre, data la possibilita di sfruttarelo storage locale, si rilassa il vincolo per il quale ogni nodo deve trasmetterein rete ogni lettura.

Un’ultima considerazione e di natura concettuale: in un’architettura cen-tralizzata si crea una separazione fisica tra la rete e le informazioni che lariguardano, separazione che puo diventare problematica nel caso in cui l’am-ministratore non abbia accesso al dispositivo che agisce da manager o peg-gio ancora nel caso di failure del manager stesso. La soluzione alternativapermette invece di implementare una sorta di base di dati distribuita: le in-formazioni restano strettamente legate alla rete descritta e sono disponibilifintanto che la rete e raggiungibile.

Tutte queste considerazioni hanno permesso di optare per la soluzionedistribuita, la quale pero ha per contro il costo di dover dedicare una partedello storage di ogni nodo all’archiviazione delle letture dei propri sensori euna parte della capacita di elaborazione alle politiche di power saving.

2.1.1 Scelte implementative

Per la costruzione della soluzione si e posto un occhio di riguardo all’aderenzaagli standard esistenti, in modo da permettere e facilitare future modifiche oestensioni della soluzione stessa. Si e reso necessario eseguire uno studio sudue diversi fronti:

1. da un lato vi e la necessita di mantenere un registro storico dei valori diconsumo di potenza e quantita di banda utilizzata da ogni interfacciadi rete del nodo;

2.1. ARCHITETTURA D’INSIEME 11

2. dall’altro tali informazioni devono essere rese disponibili all’esterno tra-mite un software server in grado di analizzare le richieste ricevute eritornare i dati interessati.

Sensing e persistenza dei dati Il punto 1 dell’elenco precedente richiedel’analisi di tre problematiche distinte:

1.a. come eseguire una lettura non invasiva delle informazioni di utilizzo dibanda e consumo di potenza;

1.b. come salvare in maniera persistente queste informazioni in modo chepossano essere recuperate e fornite in risposta ad un’interrogazione delmanager;

1.c. come evitare di far crescere in maniera incontrollata la dimensione del-l’archivio di letture passate, considerando anche il fatto che mano a ma-no che il dato appartiene ad un passato remoto il suo valore informativosi riduce.

La necessita di trasparenza rispetto al funzionamento standard del nodorichiesta al punto 1.a e risolta da sensori hardware che sono gia presenti sui va-ri dispositivi, e che compiono le misurazioni senza interferire con l’operativitanormale del nodo. Quando i sensori non sono disponibili le misurazioni sonosostituite da un modello di consumo di potenza sulla base della larghezza dibanda utilizzata ottenuto da misurazioni eseguite direttamente sull’hardwarein laboratorio.

Per quanto riguarda il problema di persistenza e reperibilita dei dati (1.b),la scelta era tra un file di log testuale e una base di dati relazionale. Si edeciso per quest’ultima alternativa, per ottenere in blocco sia una gestioneottimizzata dei dati sia un’interfaccia di inserimento e ricerca attraverso unlinguaggio standard (SQL) che di conseguenza e facilmente riutilizzabile infuturo.

Questa scelta ha un altro risvolto positivo, cioe il fatto che tramite un da-tabase si e in grado di risolvere facilmente il problema 1.c: e infatti sufficientela creazione di un trigger che in maniera automatica dopo ogni inserimentoanalizza lo stato del database e raggruppa tra loro le tuple appartenenti adun passato troppo remoto, eliminando i dati grezzi. Quando anche gli aggre-gati storici perdono troppo valore informativo si ha la possibilita di creareun secondo livello di aggregazione oppure di eliminarli perche ormai inutili.


hardwaresensori

softwaredump

softwaregestionestorico

RPCserver

storage deidati letti

attuatori

amministratorenododi rete

Figura 2.2: Schema della soluzione per un generico nodo di rete

Condivisione dei dati Il secondo fronte sul quale e stato progettato losviluppo riguarda la condivisione sulla rete dei dati ottenuti dai sensori, inmodo che questi possano essere analizzati per potervi applicare la politica diottimizzazione energetica.

Date le scelte fatte in materia di dislocamento dei dati, per ogni nododella rete si e deciso di creare un server che esponga un insieme di funzioniRPC (Remote Procedure Call) tramite le quali un client puo eseguire duecompiti: da un lato richiedere la disattivazione o l’attivazione di particolaricomponenti del nodo e dall’altra ottenere le informazioni di cui necessita perpoter determinare quali comandi inviare.

Uno schema generale della struttura della soluzione e mostrato in Figu-ra 2.2, nella quale si puo notare una rappresentazione astratta degli elementie delle interazioni che avvengono tra loro per il corretto funzionamento dellapiattaforma.

2.2 Tecnologie

Dopo aver compiuto delle scelte generali e di alto livello si e reso necessarioentrare nel particolare di ogni tecnologia da sfruttare per poter completareil progetto della soluzione. Per ogni ambito che si e identificato si e cercatodi valutare almeno un’alternativa, mantenendo l’attenzione su vantaggi esvantaggi di ognuna di esse.

Come situazione iniziale dal punto di vista tecnologico si ha il nodo che,tramite un’architettura single core, esegue il suo software di gestione ed espo-ne verso la rete una shell remota che puo essere utilizzata dall’amministratoreper modificare i parametri di funzionamento.

2.2. TECNOLOGIE 13

hardware

CPU

softwarecore

shell

admin

(a) single core

hardware

CPU-0 CPU-1

softwarecore

shell

powermgmt

admin

(b) dual core

Figura 2.3: Passaggio da architettura single core a dual core

2.2.1 Interne al nodo

Avvio asimmetrico Un primo requisito che e stato imposto all’applica-zione e quello di mantenere un isolamento che sia maggiore possibile tra ilsoftware che esegue la gestione dei pacchetti di rete (il software core) e quel-lo della soluzione, che esegue la parte del management plane della rete conl’obiettivo del power saving. Questo requisito e stato posto per fare in mo-do che le modifiche da apportare al software core del nodo siano ridotte alminimo, nella politica di “non introdurre potenziali problemi in cio che e giafunzionante”.

Per poter soddisfare questo requisito si e deciso di sfruttare una parti-colare capacita del bootloader utilizzato: la possibilita di eseguire un avvioasimmetrico del nodo. Questo significa che, dato un adeguato partiziona-mento delle risorse hardware, e possibile istruire tale bootloader per caricarein memoria ed avviare l’esecuzione di due kernel differenti, totalmente isolatil’uno dall’altro. Come mostrato in Figura 2.3, questa idea prevede un cambioarchitetturale a livello hardware, il passaggio da single core a dual core, cosıda avere un processore dedicato ad eseguire il software originale del nodo el’altro a gestire il power management plane. Dal punto di vista del softwaregia scritto non cambia nulla, infatti esso continua a funzionare su un solocore con le risorse che aveva a disposizione in precedenza, e il suo controllocontinua ad essere tramite shell remota. Questo software non e a conoscen-za dell’esistenza del secondo core sul quale e in esecuzione il software dellasoluzione, per questo non si ha la possibilita di mettere in comunicazionedirettamente i due software.

Si e deciso di sfruttare la possibilita di aggiungere ai kernel un’interfacciadi rete virtuale con il suo driver, per permettere al power manager di inviarecomandi verso la shell del software core senza essere costretto ad impiegareun’interfaccia fisica per stabilire la connessione.


Base di dati La scelta di quale base di dati utilizzare per dare persistenzaalle letture dai sensori e stata guidata innanzi tutto dalla tipologia di in-formazioni che devono esservi rappresentate. Esse contengono dati storiciche devono essere recuperati solo periodicamente tramite particolari filtri,come i limiti di timestamp e di interfacce interessate; inoltre le informazioniregistrate non subiscono alterazioni, essendo relative ad eventi passati.

Si e eseguito un confronto tra due soluzioni software: una classica, basatasu un processo che agisce da database server ed espone un’interfaccia, solita-mente TCP/IP, alla quale il software deve connettersi per poter interrogarela base di dati, ed un’altra che prevede di integrare l’accesso al databasedirettamente nelle applicazioni che devono accedere ai dati, come se questofosse un semplice file al quale i due software devono accedere.

Come rappresentanti delle due categorie di soluzioni sono stati scelti ri-spettivamente MySQL e SQLite. Il primo e il nome di riferimento per iDBMS open source, con diverse applicazioni in ambito web e presente inmolti stack preconfigurati per il desktop1, mentre il secondo e spesso utiliz-zato in soluzioni embedded, come telefoni cellulari, o in software che richiedeuno storage organizzato dei dati su disco, come molti browser Internet2.

I vantaggi della prima soluzione derivano dalla presenza del software diaccesso ai dati, al quale chi utilizza il database deve connettersi per richie-dere l’esecuzione delle interrogazioni. Questo software intermedio tra datie consumatori e in grado di garantire un alto livello di fault tolerance e diconcorrenza degli accessi.

La seconda soluzione, invece, integra il software di accesso ai dati in unalibreria compilata con l’applicazione. Questa chiaramente non garantiscegli stessi livelli di protezione dagli errori di programmazione forniti dallasoluzione precedente, pero ha tra i suoi vantaggi il fatto di non richiedere laconfigurazione e la taratura del server per poter funzionare sul nodo di rete: einfatti sufficiente la possibilita di accedere in scrittura ad un’unita di storagelocale. Questa soluzione inoltre permette di mantenere ridotto il consumo dimemoria in quanto non rimane nessuna applicazione in esecuzione oltre aiclient. Consente infine di ottimizzare lo storage in quanto si ha la possibilitadi mantenere l’intero database in un unico file su disco, e la libreria non hadipendenze esterne da soddisfare o file di configurazione da rispettare.

Le differenze tra le due soluzioni sono mostrate anche in Figura 2.4. Sie valutato che l’accesso fisico al database del nodo e compiuto solo da duesoftware: quello di dump che periodicamente aggiunge nuove tuple e quelloche implementa i metodi RPC. Quest’ultimo fornisce l’accesso al database al

1fonte: http://en.wikipedia.org/wiki/MySQL2fonte: http://en.wikipedia.org/wiki/SQLite#Adoption

http://en.wikipedia.org/wiki/MySQL

http://en.wikipedia.org/wiki/SQLite#Adoption

2.2. TECNOLOGIE 15

DB

databaseserver

dumpersensori

RPC

controllohardware

amministratore

(a) MySQL

DB

dumpersensori

RPC

controllohardware

amministratore

(b) SQLite

Figura 2.4: Confronto tra DBMS con software server e DBMS embedded

client della rete (il sistema di power management) ed espone all’esterno altrefunzionalita, si e quindi valutato che si ha poco vantaggio a configurare unserver MySQL o un’alternativa equivalente per due soli client, uno dei qualifunge gia da aggregatore di accessi al database.

La scelta e quindi ricaduta su SQLite, grazie anche alla sua capacitadi una minimale gestione della concorrenza, che permette ad entrambe leapplicazioni di accedere al database in maniera contemporanea senza doverchiudere e riaprire il file per ogni scrittura di nuovi dati.

2.2.2 Esterne al nodo

Una volta che sono state decise le tecnologie da utilizzare all’interno delnodo si e passato a definire quella che deve essere l’interfaccia con la reteesterna e con l’amministratore. Per la forte dipendenza di queste due partidella soluzione si e reso necessario valutarle contemporaneamente; dall’analisisono emerse tre differenti alternative:

• l’impiego dello standard SNMP (Simple Network Management Proto-col) e la diffusione delle informazioni presenti all’interno del databasetramite questo protocollo;

• lo sfruttamento di un web server accoppiato ad un processore PHPche sia in grado di costruire delle pagine web dinamiche contenenti leinformazioni sullo stato della macchina;

• la costruzione di un Web Service che permetta di gestire le richieste divisualizzazione ricevute dal client e di inviare in rete degli oggetti cherappresentano lo stato della macchina.

Segue una breve analisi delle diverse soluzioni identificate.


SNMP E un protocollo che si posiziona al livello applicativo dello stackOSI e permette ai dispositivi connessi in rete di esporre informazioni, nellaforma di variabili, che descrivono la loro configurazione ed il loro stato, e aigestori di leggere ed eventualmente modificare da remoto tali variabili.

Il suo utilizzo si basa sulla definizione e creazione di tre componentisoftware:

• agent: e eseguito sul nodo di rete, il suo compito e quello di metterea disposizione i dati letti dai sensori: agisce quindi come server RPCinstallato sul nodo;

• manager: il processo che si occupa di inviare richieste agli agent, ela-bora le informazioni ed invia comandi; in questo software deve ancheessere inserita un’interfaccia grafica che permetta all’amministratore didialogare con il sistema;

• Management Information Base (MIB): il documento che descrive glioggetti che sono alla base della comunicazione tra manager ed agents.

Questa soluzione si adatta molto bene ad un approccio centralizzato, nelquale il database storico di tutta la rete si trova sul terminale dell’ammi-nistratore: in questa situazione infatti basta inviare sulla rete delle querySNMP periodiche e dare persistenza alle risposte ricevute, poi un’analisi deldatabase locale permette di prendere le dovute decisioni di power mana-gement; in un approccio distribuito, invece, si rende necessario un utilizzomolto particolare delle variabili definite nella MIB in modo da poter trattareanche dati storici e non solo valori attuali.

RESTful Web Server Questa soluzione prevede l’installazione su ogninodo della rete di un piccolo software con le capacita di operare come un ser-ver web, accompagnato da un processore capace di una generazione dinamicadelle pagine HTML. Un amministratore di rete puo collegarsi all’indirizzo cheidentifica un nodo ed ottenere in risposta, con una adeguata formattazione,le statistiche presenti all’interno del database.

Tramite lo sfruttamento di tecnologie come JavaScript e AJAX e possibilefare in modo che l’interfaccia dell’amministratore possa mostrare dati relativiad intere sezioni di rete e non ai singoli nodi, mantenendo comunque limitatoil carico sulla rete stessa.

La scelta di questa soluzione prevede la scrittura di alcune pagine HTMLe relativi JavaScript per definire l’interfaccia utente, e di script PHP pergenerare queste pagine in base ai dati presenti nel database locale. In questocontesto il server RPC e rappresentato dal web server che interpreta i file

2.2. TECNOLOGIE 17

PHP e le richieste del client per poter generare correttamente le rispostenecessarie.

Web Service I Web Service forniscono un approccio ad alto livello allacomunicazione di rete. Permettono infatti di astrarre da come vengono tra-sferiti i dati tra client e server, focalizzando l’attenzione sul significato di ognisingola comunicazione. Questa astrazione riduce al minimo la parte di soft-ware da produrre dedicata al parsing dei pacchetti ricevuti: le API utilizzatepermettono di leggere e scrivere sulla rete degli oggetti complessi come arrayo strutture, e non solo tipi di dati atomici.

La soluzione presenta almeno un vantaggio rispetto alle precedenti: i datiche viaggiano sulla rete sono di tipo testuale ed i protocolli utilizzati (HTTPe XML) sono aperti e disponibili praticamente ovunque, il che permette unarapida implementazione di eventuali nuovi consumatori dei dati.

Per poter sfruttare questo approccio e necessario creare un file che forniscauna descrizione rigorosa dei metodi offerti dal Web Service: questo file escritto in un apposito linguaggio, chiamato WSDL (Web Service DescriptionLanguage), in modo che sia interpretabile dal client in maniera automatica.

Dopo aver completato questo passo si ha a disposizione un documentoche specifica rigorosamente come deve avvenire la comunicazione tra il server(nodo di rete) ed il client (amministratore), dato questo documento i due soft-ware possono avvalersi di opportune librerie che gestiscono la comunicazionedi rete tramite RPC in maniera autonoma.

Confronto tra gli approcci proposti Da quanto detto fino ad ora epossibile notare che, dal punto di vista implementativo, la soluzione basatasu SNMP e molto simile a quella dei Web Services, in quanto entrambesono differenti approcci ad una soluzione client-server, per la quale devonoessere sviluppate due differenti applicazioni. Il server deve interfacciarsi conil database mentre il client deve fornire l’interfaccia utente.

Differente e la soluzione del web server RESTful: in questo caso infattie piu complicato differenziare lato server e lato client dell’applicazione inquanto quasi tutta l’elaborazione (dall’interrogazione della base di dati allacostruzione della pagina HTML) e eseguita dal server, mentre il browser silimita ad interpretare e mostrare all’amministratore la pagina che riceve ead eseguire l’eventuale codice dinamico collegato ad essa.

Se si confrontano le tre soluzioni utilizzando la metrica dei costi di im-plementazione si ottiene che la soluzione RESTful e la scelta piu veloce: essainfatti prevede la scrittura di alcune pagine web, mentre il server (il webserver) e il client (il browser) sono gia disponibili. Le altre due soluzioni


n0RPC

file.WSDL

PHP

n1

RPC

n2RPC

RPCclient

amministratore

HTML +JavaScript

Figura 2.5: Architettura basata su Web Service con PHP e JavaScript

prevedono invece una maggiore formalizzazione del servizio e lo sviluppo didue software differenti da mettere in comunicazione.

Se pero si intende utilizzare una metrica che valorizza la capacita del co-dice di adattarsi a future estensioni o manutenzioni si nota che la soluzioneRESTful perde di interesse a favore delle altre due: se ad esempio si ipotiz-za di voler creare in futuro un software di analisi statistica del traffico cheattraversa la rete su un periodo giornaliero o settimanale, ci si troverebbe adover trattare quasi gli stessi dati della soluzione attuale, se questi dati perosono ricevuti dal software in formato HTML prima di poterli analizzare enecessario eseguire un parsing della pagina per separarli dalle informazionidi formattazione. Negli altri due casi invece si avrebbe a disposizione unadescrizione formale dei dati e di come sono rappresentati nelle comunica-zioni di rete e ci si potrebbe affidare ad una libreria in grado di convertirlidirettamente in oggetti analizzabili dal software.

In Pautasso e altri (2008) e stato eseguito un confronto tra RESTful eBig Web Service che puo essere riassunto in questo modo: la scelta RESTfulsi adatta molto bene a situazioni nelle quali il software e scritto ad hoc eper scenari semplici, mentre i Web Service sono da preferire in situazioninelle quali e importante mantenere un’astrazione rispetto al protocollo dicomunicazione sottostante e rispetto ai due capi della comunicazione.

Per questo progetto si e optato per una soluzione “ibrida” che consente diunire la formalizzazione del protocollo, permessa dal file WSDL, alla possibi-lita fornita dall’opzione RESTful di poter sfruttare il browser come softwareclient: esistono delle classi PHP e JavaScript che permettono di leggere i fileWSDL e fornire al resto dello script i metodi RPC in esso descritti. Queste,come mostrato in Figura 2.5 hanno permesso di implementare un’architetturabasata su Web Service sfruttando HTML5, JavaScript e PHP.

Capitolo 3

Nodo di rete

In questo capitolo e presentato il lato server della piattaforma, ovvero la par-te di software che e eseguita da ogni nodo di rete ed a cui l’amministratorepuo collegarsi per controllare la piattaforma di power management. La trat-tazione attraversa innanzi tutto una parte di introduzione al multi core e dimotivazioni che hanno portato alla sua scelta, successivamente sono analiz-zati i vari aspetti dell’implementazione del lato server: dalla comunicazionedel power manager col nodo alla configurazione dell’avvio asimmetrico di duekernel, toccando infine il software che esegue il dump delle letture dei sensoriall’interno del database locale ed il modello del consumo di potenza dei varicomponenti del nodo, modello che deve essere utilizzato nel caso in cui alcunisensori non siano disponibili.

3.1 Introduzione

In questo documento si definisce nodo della rete di telecomunicazione ognidispositivo che e in grado di collegare tra loro diversi segmenti della rete,ovvero l’unita che, assieme ai collegamenti fisici, puo essere definita comesua componente base.

Le sue funzioni sono quelle di ricevere il pacchetto dall’interfaccia col-legata al segmento sorgente, compiere delle elaborazioni per verificarne lacorrettezza e l’integrita, ed infine inoltrarlo verso il destinatario. Nel casoil pacchetto debba attraversare piu nodi per essere trasferito tra sorgentee destinazione il singolo nodo e in grado, tramite opportuni protocolli edeuristiche, di inoltrarlo solamente sul segmento di rete che lo avvicina alladestinazione.

Per compiere queste operazioni il nodo puo sfruttare dell’elettronica de-dicata ed un core che esegue le operazioni piu ad alto livello. Proprio a causa

19

20 CAPITOLO 3. NODO DI RETE

core

fn A

core

fn B

core

fn C

(a) Modello pipeline

core

fn A,B,C

core

fn A,B,C

core

fn A,B,C

scheduler

(b) Modello run to completion

Figura 3.1: Diversi approcci alla programmazione multicore

del fatto che per le elaborazioni di base non e necessario impiegare la CPU, edifficile trovare dei nodi che non siano basati su un’architettura single core, senon in casi in cui la rete ha un’importanza critica e deve sostenere continua-mente volumi importanti di traffico. In Dronamraju Subramanyam (2012)sono mostrati due differenti tipi di metodi per sfruttare il multi core sugliapparati di networking: il pipelining dei core ed il modello run to completion.Nel primo (Figura 3.1a) si suddividono le operazioni in moduli indipendentiche devono essere eseguiti in maniera sequenziale (pipeline) per completarel’elaborazione sul pacchetto, in modo che l’output di un modulo rappresentil’input del successivo. Nel secondo caso (Figura 3.1b) e invece presente unoscheduler che ha il compito di assegnare i pacchetti in ingresso ad uno qual-siasi dei core liberi: questi eseguono tutte le elaborazioni che sono richiestein maniera indipendente uno dall’altro.

In entrambi i casi riportati l’approccio del multi core ha l’obiettivo di mi-gliorare le prestazioni generali del nodo di rete, possibilmente aumentando ilsuo throughput. La soluzione proposta non ha invece scopi prestazionali, maintende usare il secondo core di un’architettura dual per eseguire il softwaredi power management, che ha scopi completamente differenti rispetto a quellidel nodo.

3.2 Architetture multi core

Introduzione Le architetture multi core sono la naturale evoluzione dellacontinua ricerca di un incremento di prestazioni dei sistemi di elaborazione.Per anni i produttori di hardware, sulla scia delle legge di Moore1, hanno

1Il numero di componenti elettronici nei circuiti integrati raddoppiera ogni due anniper almeno altri dieci anni dal 1965 — Gordon E. Moore, co-fondatore Intel, 1965

3.2. ARCHITETTURE MULTI CORE 21

spinto sulla miniaturizzazione dei transistor e sul parallelismo a livello diistruzione, per fornire agli utenti dispositivi in grado di trattare le moli di datisempre maggiori che sono stati in grado di creare. Questo trend esponenzialee durato ben oltre il 1975: solo nel 2010 si e riconosciuto che il tasso dicrescita e rallentato.

Una causa per questo rallentamento e sicuramente da attribuire a quellache viene definita come la seconda legge di Moore, o legge di Rock2 ed ilconseguente cambio di obiettivi da parte dei produttori: Intel e AMD nel2005 lanciarono sul mercato i primi processori dual core, anticipati di unpaio d’anni solo da IBM con i suoi PowerPC. In quegli anni si e raggiuntala barriera dei 3GHz di frequenza di lavoro, le ottimizzazioni che sono sta-te applicate in precedenza erano difficilmente migliorabili, ed i consumi dipotenza con i conseguenti costi di cooling stavano diventando decisamenteimportanti. Il Pentium 4 di Intel e considerato da alcuni la migliore CPUsingle core mai prodotta sotto il profilo architetturale, con pipeline e tecnichedi prediction molto spinte ed accurate.

L’unica opportunita di migliorare ulteriormente era offerta da una mag-giore parallelizzazione del carico di lavoro, suddividendolo prima su due, poisu piu core.

Le soluzione multi core maggiormente diffuse sul mercato vedono la pre-senza di due o piu unita di elaborazione perfettamente identiche: su questearchitetture e possibile implementare il modello run to completion citatonell’introduzione. I core sono infatti in grado di eseguire le stesse operazionied un task puo essere allocato indifferentemente su uno qualsiasi dei coredisponibili.

In Merritt (2008) si propone un approccio differente, ovvero la specializ-zazione dei core: questo approccio segue quanto e gia implementato in moltitelefoni cellulari: tante unita altamente ottimizzate per l’esecuzione di unparticolare compito e controllate da un gestore centrale. Questo approcciopermette di ottimizzare le prestazioni, in quanto ogni modulo attivo sfruttatutte le sue componenti per eseguire il proprio compito, altrimenti se non haoperazioni da eseguire e possibile spegnerlo completamente.

La proposta di questo lavoro di tesi non ricerca nel multi core un in-cremento di prestazioni, ma un isolamento tra compiti differenti. Prevededi caricare in memoria due kernel indipendenti ed assegnare un core a cia-scuno: questo e chiamato avvio asimmetrico o Asymmetric MultiProcessing(AMP) e si contrappone all’utilizzo simmetrico delle risorse, nel quale tutto

2Anche i costi di ricerca e sviluppo e di produzione di circuiti integrati hanno unacrescita esponenziale con ogni nuova generazione di chip — Arthur Rock, venture capitaliste finanziatore di molte aziende della Silicon Valley


l’hardware e controllato dallo stesso Sistema Operativo, il quale assegna lerisorse ai processi che ne fanno richiesta. In una soluzione asimmetrica adognuno dei due kernel sono assegnate in fase di caricamento una partizionedelle risorse fisiche del sistema e durante la sua esecuzione esso puo accederesolamente a quell’insieme di risorse.

Motivazioni dell’approccio scelto Le motivazioni che hanno portatoalla scelta di questo tipo di approccio sono in prima battuta di carattereindustriale: la rete e gia operativa e tutti i suoi nodi sono di tipo single core.Questo significa che il software che e eseguito da ognuno di essi e ottimizzatoper funzionare e sfruttare al massimo questo tipo di architettura. Aggiunge-re nuovo software all’immagine gia funzionante richiede un’accurata analisidelle performance e approfonditi casi di test per garantire la convivenza delnuovo software con i requisiti di quello attuale, mentre un avvio asimmetricofornisce la completa trasparenza rispetto al software del nodo, garantendouna migliore stabilita di tutto il sistema proprio per il fatto che le modificheda apportare all’immagine presente sono minime.

Una seconda motivazione prende in considerazione quelli che possono es-sere gli sviluppi futuri che puo avere la piattaforma di power management. Inun possibile futuro il software della soluzione potrebbe diventare arbitraria-mente complesso e compiere delle predizioni di carico sulla rete analizzandolo storico a sua disposizione; queste predizioni potrebbero richiedere capa-cita computazionali importanti, ed in momenti particolari potrebbero farvenir meno le funzionalita di base del nodo, portando ad un denial of ser-vice di una parte della rete. In uno scenario alternativo invece il nodo direte si potrebbe arricchire di una CPU dedicata e dimensionata in manieratale da soddisfare esattamente i requisiti della politica di power managementimplementata, sulla scia dell’approccio citato in Merritt (2008) dei core spe-cializzati. In questo caso l’avvio asimmetrico diventerebbe necessario perpoter sfruttare appieno questa particolare CPU.

3.3 Comunicazione tra i due software

Per consentire al power manager di svolgere il suo compito e necessario per-mettergli di comunicare con il software del nodo. I due sistemi operativi chesi intende avviare non sono configurabili per assistere questo tipo di comu-nicazione attraverso un’area di memoria condivisa, in quanto la InterProcessCommunication (IPC) che sono in grado di gestire riguarda processi che sonoin esecuzione all’interno dello stesso sistema operativo.

E gia stato detto che il software del nodo espone verso la rete una shell

3.4. AVVIO ASIMMETRICO DEL NODO 23

hardware

CPU-1 CPU-2

HSO-1 SO-2

pwrmgr

(a) Ruolo dell’hypervisornella comunicazione

n1

n2

n3

n4

(b) Schema logico della rete dopol’aggiunta dei power manager

Figura 3.2: Aggiunta dei power manager alla rete

alla quale un amministratore puo accedere da remoto per modificare la con-figurazione del nodo. Questa e la via che e stata scelta per consentire alpower manager di inviare i suoi comandi: stabilire una connessione versoquella shell e sfruttarla per indicare al nodo di attivare o spegnere alcunedelle proprie interfacce.

Tramite un hypervisor dedicato e possibile evitare il passaggio attraversoun’interfaccia di rete esterna per stabilire la comunicazione, in quanto questopermette di creare un’interfaccia virtuale per ogni kernel e fare in modo chequeste possano comunicare tra loro. La Figura 3.2 mostra come cambia larete con l’aggiunta dei power manager: nella 3.2a si evidenzia come l’hyper-visor (H) si pone tra i due Sistemi Operativi per garantire la comunicazionesenza l’impiego di interfacce esterne, mentre la 3.2b mostra come cambia alivello logico la rete dopo l’aggiunta dei power manager.

Dal punto di vista della rete infatti la situazione che si crea e similea quella che si avrebbe aggiungendo un nodo terminale per ogni nodo dicomunicazione. Nell’esempio mostrato in Figura 3.2b i nodi etichettati conni sono quelli di comunicazione, mentre con un tratto piu marcato sonomostrati i nodi terminali. Quelli tratteggiati sono infine i power manager,uno per ogni nodo di comunicazione, che si pongono come ulteriori terminalied utilizzatori della rete, in quanto generano dell’ulteriore traffico che deveessere gestito.

3.4 Avvio asimmetrico del nodo

La strada scelta per l’implementazione della soluzione e quella di mantene-re attivi due kernel differenti per disaccoppiare il software di gestione delnodo con l’ottimizzazione energetica. Per consentire questo tipo di approc-


cio, ammessa la presenza di un hardware con almeno due core, vi sono dueprerequisiti che devono essere soddisfatti:

• un bootloader che supporti questa funzionalita, che permetta cioe dicaricare in memoria i due kernel e di impartire comandi di avvio aduna CPU per volta;

• una coppia di kernel correttamente configurati prima della compilazio-ne in modo che non tentino entrambi di inizializzare tutto l’hardwarepresente sulla macchina.

3.4.1 Bootloader

Il primo requisito e soddisfatto da U-Boot3, il bootloader gia utilizzato peri nodi di rete e largamente sfruttato in ambito embedded per la sua ampiaconfigurabilita. In questo bootloader sono gia presenti tutte le funzionalitanecessarie ad adattarsi agli impieghi piu disparati: al suo interno e possibiletrovare client DHCP e TFTP e supporto ai protocolli BOOTP e TFTPBOOTper caricare un kernel presente su un dispositivo remoto in rete, gestione dellamemoria flash e delle partizioni linux per poter caricare un kernel locale esupporto al trasferimento di file attraverso la linea seriale per situazioni didebug o di testing prima della messa in opera dell’hardware. Ha anche ilsupporto per compiere una verifica CRC dei dati caricati in memoria.

Il suo comportamento di default e quello di presentare una console sul-la porta seriale attraverso la quale l’utente puo interagire con il bootloader.Tramite appositi comandi e variabili d’ambiente e possibile caricare in me-moria ad indirizzi specifici le immagini del kernel e del filesystem iniziale eavviare il Sistema Operativo. U-Boot ha un supporto anche per script mini-mali e la possibilita di eseguire delle istruzioni di default, senza l’interventodell’utente sulla porta seriale: questi permettono di caricare un kernel in ma-niera autonoma, e possono essere utilizzati quando il sistema esce dal testinged entra in fase produttiva.

3.4.2 Device Tree

Per fornire al kernel l’elenco dei dispositivi hardware presenti sul nodo so-no stati creati i Flattened Device Tree o FDT, dei file binari che descrivonol’hardware sul quale il kernel deve operare. Quest’ultimo puo utilizzare talifile per trovare e registrare le varie periferiche del sistema, dato che al lorointerno sono presenti anche gli indirizzi ai quali le periferiche sono collegate.

3http://www.denx.de/wiki/U-Boot/WebHome

http://www.denx.de/wiki/U-Boot/WebHome

3.5. SOFTWARE DI DUMP 25

Tramite i device tree e possibile descrivere molti aspetti di design architet-turale, come ad esempio numero e tipo di CPU, gli indirizzi dedicati allamemoria RAM, gli interrupt hardware e le connessioni con le periferiche.

L’approccio classico alla problematica della ricerca dell’hardware a dispo-sizione prevede che all’interno del kernel sia compilato del codice di inizializ-zazione che esegue del probing su indirizzi noti per verificare se un determi-nato hardware e presente e risponde correttamente all’indirizzo testato.

I device tree, come alternativa, hanno il vantaggio di essere una strutturadati standard e formale, ed in grado di descrivere praticamente tutto l’hard-ware che dovrebbe essere rilevato tramite probing. Essi possono sostituirequesta procedura, ed hanno almeno due risvolti positivi: da un lato i produt-tori di hardware possono focalizzare le proprie risorse sulla stesura di driverdi Sistema Operativo per i loro prodotti, evitando di dover includere al lorointerno anche la procedura di ricerca ed identificazione della periferica; dal-l’altro i kernel compilati possono essere utilizzati anche su hardware creatoed aggiunto a posteriori in quanto tramite i device tree e possibile sostituireil codice di probing. Questo permette quindi di ridurre il quantitativo dicodice hardware dependand ed aumentare la genericita del kernel.

Se necessario e possibile fornire al kernel in fase di avvio un device tree chedescrive solamente un sottoinsieme delle periferiche effettivamente presenti,in questo casi esso si limitera ad inizializzare e sfruttare solamente quelleche vi sono elencate, ignorando l’esistenza delle altre. Questa flessibilitae sfruttabile per completare l’avvio asimmetrico dei due kernel: e infattisufficiente partizionare l’hardware e creare un device tree per ognuno dei duesottoinsiemi della partizione, infine tramite appositi comandi impartiti albootloader e possibile caricare in sequenza i kernel sui due core passandogliil corretto device tree.

In Appendice B sono presenti degli ulteriori dettagli riguardanti l’avvioasimmetrico di due kernel sullo stesso hardware e le operazioni preventiveche e importante eseguire.

3.5 Software di dump

Componente di base della soluzione e rappresentata dal dumper, ovvero quelsoftware, in esecuzione su ogni nodo di comunicazione della rete, che perio-dicamente registra nel database locale le informazioni relative al consumo dipotenza di ogni componente del nodo. Senza la presenza di questo softwarele politiche implementabili sarebbero molto limitate in quanto non avrebberoaccesso ai dati storici della rete.

Il software di dump, eseguito sul core del power manager, e perfettamente


trasparente rispetto al funzionamento normale del nodo. Questo e possibilegrazie innanzi tutto alla scelta di dove allocare tale processo, che consentedi lasciare liberi memoria e tempo di processore dedicati al software del no-do, richiedendoli invece al power manager, il quale non ha gli stessi requisitidi prestazioni del primo. In secondo luogo i valori di consumo di potenzae larghezza di banda utilizzati sono letti da appositi sensori hardware, chepermettono di ottenere tali valori senza dover interrompere la periferica oil software che la sta utilizzando. L’elettronica dei sensori si preoccupa dimantenere aggiornate delle aree di memoria con gli stessi valori rilevati dal-la periferica, in modo che siano leggibili dal dumper come fossero semplicivariabili condivise.

Gli unici requisiti per il corretto funzionamento di questo software sonoquindi la possibilita di accedere alla zona di memoria dove sono mappati ivalori dei sensori e di scrivere dei dati in un database situato su un supportodi archiviazione, possibilmente non volatile, locale al nodo. Soddisfatti que-sti requisiti il software ha il solo compito di scandire, ad intervalli di temporegolari e preconfigurati, tutte le aree di memoria che contengono i valo-ri aggiornati dai sensori e, una volta ottenute tali misurazioni, di inserirleall’interno del database.

Al momento dell’avvio il dumper ha la necessita di conoscere le periferichepresenti in hardware ed i sensori dai quali e possibile ricavare le informazioniche deve trattare. Per fare cio il software analizza il contenuto di un file XMLche gli e fornito: tale file e simile a quello mostrato in Appendice A, e deverispettare il DTD allegato. In esso sono presenti tutte le informazioni di cuinecessita il dumper:

• la struttura hardware del nodo per quanto riguarda le componenti in-teressate dalle politiche di power saving, con espressa anche la lorogerarchia;

• per ognuna delle componenti descritte sono inoltre specificati:

– l’identificativo di rete, ovvero quella stringa, di cui si e tratta-to nell’introduzione, che permette di identificare univocamente ilsingolo dispositivo all’interno dell’intera rete;

– i parametri di funzionamento, in particolare la larghezza di bandamassima ed i suoi consumi di potenza statico e dinamico, in modoche in mancanza del supporto dei sensori hardware sia possibilericavare ugualmente dei valori da inserire nel database;

– la lista di tutti i sensori disponibili, con specificato il tipo digrandezza misurata, potenza o larghezza di banda, e l’indirizzodi memoria al quale e possibile ottenere copia del suo valore.

3.6. MODELLO DEL CONSUMO DI POTENZA 27

Date queste informazioni il software e in grado di creare delle query diinserimento nel database contenenti i valori letti dai sensori o generati dalmodello ed il timestamp della lettura4. Dato che la rete puo essere distribui-ta anche attraverso fusi orari differenti si e deciso di fare in modo che tuttii record in tutte le basi di dati all’interno della rete abbiano il timestampespresso rispetto al tempo universale coordinato (UTC). Questa decisione estata presa anche alla luce del fatto che non sono stati posti vincoli all’accessodell’eventuale amministratore, di conseguenza esso puo analizzare e modifi-care lo stato della rete anche da fusi orari molto distanti da quelli nei qualila rete e ubicata.

La natura distribuita della base di dati pone anche una problematica disincronizzazione dei nodi di comunicazione. Innanzi tutto e necessario assu-mere che l’orologio di sistema dei power manager dei vari nodi sia sincronizza-to almeno all’interno della rete, in modo che tutte le registrazioni compiute inun determinato istante siano etichettate con lo stesso timestamp. In secondoluogo si e ritenuto importante che le registrazioni nei vari database fossero ilpiu possibile sincronizzate in modo che, se l’amministratore richiede lo statodi una porzione della rete in un determinato istante, tali informazioni sianotutte reperibili ed etichettate con lo stesso timestamp, senza che questo abbiadelle variazioni di qualche secondo tra un nodo ed un altro. Questo significache il software di dump, una volta terminata l’analisi del file XML, procedecon la lettura dei sensori ed il conseguente primo inserimento nel databaseal secondo zero del minuto successivo a quello attuale.

3.6 Modello del consumo di potenza

Nel caso in cui alcuni sensori non fossero disponibili il software di dumpe predisposto per calcolare il valore mancante sulla base delle informazioniche sono disponibili, sfruttando un modello compilato all’interno del codice;parte di questo modello e gia stato presentato nella Sezione 1.3 a pagina 4.Tale modello e presentato completamente in questa sezione.

Le componenti statiche di un nodo di comunicazione, come PSU e FAN,hanno chiaramente due soli livelli di consumo di potenza e non hanno unalarghezza di banda utilizzata. Per le altre componenti si e adottata l’identifi-cazione tramite pedici, ovvero ad ogni variabile e stato aggiungo a pedice lalettera iniziale del tipo di componente associato: I per le interfacce, L per leline card e M per le matrix. Quindi ad esempio il consumo di potenza di una

4Il timestamp e espresso come stringa testuale aderente allo standard ISO 8601:2004,secondo la raccomandazione W3C, ovvero nel formato YYYY-MM-DDTHH:MM:SSZ


line card sara etichettato come PL, mentre la larghezza di banda utilizzataall’istante t di una matrix sara BWM(t).

Iniziando dal calcolo della larghezza di banda utilizzata si assuma che siadisponibile quella di ogni interfaccia di rete, allora per ogni line card essasara pari alla somma di quella di ogni sua interfaccia.

BWL(t) =∑i∈L

BWi(t)

Dato che le matrix gestiscono il traffico tra una line card e l’altra si hache tutto il traffico che attraversa il nodo deve essere gestito dalla line cardattiva: quindi la sua larghezza di banda utilizzata e pari alla somma di tuttequelle di tutte le line card del nodo.

BWM(t) =∑l∈N

BWl(t)

Date le informazioni sulla larghezza di banda utilizzata e possibile calco-lare il consumo di potenza delle interfacce di rete e delle matrix con lo stessomodello mostrato in precedenza a pagina 4.

PI(t) = PIS + PID ·BWI(t)

MBWI

PM(t) = PMS + PMD ·BWM(t)

MBWM

Per quanto riguarda le line card e invece necessario evidenziare che le in-terfacce sono dei loro componenti, di conseguenza il loro consumo di potenzacontribuisce direttamente al consumo della line card a cui appartengono.

PL(t) =∑i∈L

Pi(t) + PLS + PLD ·BWL(t)

MBWL

Il consumo di potenza dell’intero nodo infine sara dato dalla somma diquello di ogni componente statico presente (C), delle matrix e delle line card.Le singole interfacce non sono considerate in questo computo in quanto il loroconsumo di potenza e gia inserito nel calcolo di PL(t).

PN(t) =∑c∈N

Pc(t) +∑l∈N

Pl(t) +∑

m∈N

Pm(t)

Come e facile immaginare i consumi di potenza dei componenti statici nondipendono dalla larghezza di banda attualmente utilizzata, il loro valore e infunzione della variabile temporale t solamente per il fatto che tali componentipotrebbero essere spenti, ed in questo caso il loro consumo sarebbe nullo.

Capitolo 4

Comunicazione

Requisito di base affinche tutta la piattaforma di power management sia ingrado di funzionare risiede nella possibilita che devono avere i vari mana-ger di comunicare tra loro e con l’eventuale amministratore. Questo perchel’informazione presente nel database di ogni nodo ha un valore molto limi-tato se non puo essere associata a quella dei nodi circostanti, ed e inoltreimportante che l’amministratore possa avere accesso a queste informazionidi performance per poter gestire adeguatamente la rete.

Per garantire questa comunicazione, sia tra nodi che con l’amministra-tore, sono stati scelti i Web Service. In questo capitolo e presentata unadescrizione di tale piattaforma, con i suoi vantaggi e le sue limitazioni, ed unapprofondimento sul suo componente principale, il formato WSDL. Succes-sivamente sono descritti i due endpoint con la loro struttura interna infine,nell’ultima sezione, e presentato il client realizzato.

4.1 Web Service

Secondo la definizione del World Wide Web Consortium (W3C) un Web Ser-vice e un sistema software progettato per fornire un’interoperabilita standardtra differenti applicazioni, in grado di funzionare su una varieta di piattaformee framework1. Questa descrizione si adatta bene ad evidenziare le potenzia-lita della piattaforma: innanzi tutto e uno standard W3C con un gruppo dilavoro dedicato che si preoccupa di aggiornare e migliorare le sue specificheper inseguire e guidare l’evoluzione del web; in secondo luogo e una soluzio-ne che non dipende da una particolare piattaforma software o di sviluppoper poter funzionare, e quindi accessibile ad una grande varieta di ambientiimplementativi. Il suo punto di forza rispetto alle alternative sta nel fatto

1http://www.w3.org/TR/ws-arch/#whatis

29

http://www.w3.org/TR/ws-arch/#whatis

30 CAPITOLO 4. COMUNICAZIONE

che il suo layer di trasporto e composto di messaggi in formato XML che, es-sendo testuale e non binario, e facile da generare ed interpretare in qualsiasiambiente software.

Le sue potenzialita nascono dalla grandissima diffusione della rete Inter-net, tramite la quale il Web Service trova la sua naturale implementazione,ma nel contempo non e vincolato ad utilizzarla: anche una rete dedicatao due software all’interno dello stesso Sistema Operativo sono in grado digestire ed utilizzare un Web Service tramite un socket locale. Esso infatti,come gia accennato, utilizza il formato XML per i messaggi e la porta HTTPper le connessioni: questa porta e lasciata aperta da quasi tutti i firewall,infatti e quella dedicata alla navigazione web. Questo significa che anche inambito enterprise non e necessaria la riconfigurazione di complicate politichedi sicurezza della rete, ma al contrario la comunicazione e gia pronta all’uso.

Un’altra peculiarita dei Web Service risiede nel disaccoppiamento chesono in grado di fornire tra i due software ai capi della comunicazione: comenello stile delle Remote Procedure Call il client invoca un metodo localedella libreria che gestisce la comunicazione fornendogli alcuni parametri, talemetodo si occupa di inviarli al server, sul quale e compiuta l’elaborazione, edi ritornare i risultati ricevuti al chiamante, rendendogli del tutto trasparentile problematiche della comunicazione. All’altro capo del canale, sul server,si trovano le implementazioni dei metodi che sono messi a disposizione delclient, tali metodi sono invocati dalla libreria di comunicazione nel momentoin cui un messaggio e ricevuto dalla rete.

4.2 Struttura di un Web Service

Un’architettura basata su Web Service e solitamente suddivisa in tre macrocomponenti:

• un insieme di client del servizio, detti Service Requester, che necessitanoe richiedono delle prestazioni fornite dai server;

• un insieme non vuoto di server, detti Service Provider, su cui sonoimplementati i metodi che possono essere richiesti dai client;

• almeno un Service Broker, che ha funzione di indirizzamento dei pro-vider: su richiesta puo fornire una descrizione di tutti i servizi messia disposizione dalla rete e delle modalita con le quali possono essereinvocati.

4.2. STRUTTURA DI UN WEB SERVICE 31

Requester

Broker

Provider

WSDLWSDL

SOAPXML-RPC

REST

Figura 4.1: Architettura generale di un Web Service

L’architettura standard di un Web Service e mostrata in Figura 4.1, nellaquale i nodi rappresentati con tratto continuo sono i tre attori della comunica-zione, mentre sugli archi sono indicati i vari protocolli utilizzati. E possibilenotare che, mentre le comunicazioni con il broker utilizzano obbligatoria-mente il formato WSDL, appositamente progettato per questo scopo, quelletra requester e provider non hanno un protocollo specifico da rispettare maesistono piu alternative possibili. All’interno del file WSDL fornito dal bro-ker e specificato, tra le altre informazioni, quale tra i protocolli alternativiva utilizzato da un requester per potersi mettere in comunicazione con unparticolare service provider.

Da evidenziare e il fatto che tutte le comunicazioni di questa architettura,dai WSDL trattati dal broker alla comunicazione tra requester e provider,sono in formato testuale. Questo ha il grosso vantaggio di essere facilmentee quasi sempre interpretabile in maniera univoca, a meno di differenze diencoding dei caratteri, da qualsiasi software, indipendentemente dalla piat-taforma sulla quale stanno funzionando i due endpoint: questo garantisce lamassima interoperabilita tra software di natura anche eterogenea.

Non e inoltre necessario che le tre componenti elencate siano fisicamenteseparate tra loro: ad esempio in situazioni nelle quali l’indirizzo del providere noto a priori non c’e la necessita di creare un broker esterno, semplicementeogni provider agisce da broker di se stesso. Inoltre anche la separazione traprovider e requester spesso non e ben definita: se si considera l’esempio diFigura 4.2 il software sul nodo A, dopo aver ricevuto la descrizione del serviziofornito dal software di B, invia a quest’ultimo una richiesta di esecuzione diun metodo f(). Per poter completare questa esecuzione pero B necessitadi una chiamata al metodo g() che e fornito dal software sul nodo C. Inuna situazione come quella descritto e facile identificare A come requestere C come provider, mentre B si pone sia come provider di f() che comerequester di g().

Questo esempio mostra come sia possibile integrare tra loro servizi web di-stribuiti in tempi e modalita differenti: per estendere una funzionalita fornita


...

call f()

...

A

function f() {

...

call g()

...

}B

function g() {

...

}

C

WSDL WSDL

Figura 4.2: Esempio di doppia RPC

da un software e sufficiente infatti contattare il broker corretto e scegliere,tra le alternative proposte, la descrizione del servizio che meglio si adat-ta alle necessita di estensione richieste e, con questa, configurare la libreriadi interfaccia con la rete per iniziare immediatamente a sfruttare il nuovoservizio.

Per questa soluzione software ci si e appoggiati ai Web Service, sfruttandolo standard HTTP come mezzo di trasporto e SOAP (Simple Object AccessProtocol) come contenitore dei messaggi scambiati. Quest’ultimo definisce ilformato che deve avere il pacchetto all’interno del quale sono posti i messaggi,ovvero specifiche strutture basate su XML.

4.3 File WSDL

Il Web Service Description Language (WSDL) e il linguaggio nel quale e scrit-to il file cuore della struttura dei Web Service. Tale file, infatti, e distribuitodal broker ai requester e contiene una descrizione di tutta la struttura e dellecomponenti del servizio: a partire dai tipi di dati impiegati fino agli indirizziall’interno della rete ai quali e possibile raggiungere determinate procedure.Questo file e suddiviso in cinque sezioni, ognuna dedicata a descrivere unparticolare aspetto del Web Service, che devono essere specificate in questasequenza:

1. I tipi di dati (types) che possono essere trasmessi sulla rete incluse,se necessarie, strutture di arbitraria complessita e dimensione. Per laloro definizione e utilizzato XML-Schema, i DTD non sono applicabiliin questo ambito a causa della loro impossibilita di definire tipi di datie per il fatto che la loro sintassi non e in formato XML.

2. I messaggi (message) che requester e provider possono scambiarsi ed irelativi dati che devono accompagnarli. Tali dati possono essere atomi-

4.3. FILE WSDL 33

definitions

WSDL 1.1

serviceport

binding

portType

operation

output

input

message

types

description

WSDL 2.0

serviceendpoint

binding

interface

operation

output

input

types

WSDL 1.1 WSDL 2.0types types

message n. d.portType interface

operation operation

binding binding

service service

port endpoint

Figura 4.3: Confronto tra le specifiche di formati di WSDL 1.1 e 2.0

ci, come stringhe o valori numerici, oppure istanze di strutture definiteall’interno della sezione types.

3. I gruppi (portType) di metodi implementati sui vari provider, ognu-no dei quali raccoglie sotto lo stesso nome un insieme di operazioni(operation) che sono in qualche modo correlate tra loro. Per ogni me-todo sono inoltre specificati i messaggi in ingresso e in uscita utilizzatiper completare l’elaborazione.

4. Il tipo di collegamento (binding) tra i portType definiti precedente-mente ed il protocollo da utilizzare per la comunicazione. E possibileavere piu binding per un singolo portType, ad esempio nel caso in cui sudue server differenti e implementato lo stesso insieme di metodi ma so-no utilizzati protocolli differenti per la comunicazione. In questa lavorosi e deciso di sfruttare il protocollo SOAP per tutti i metodi, di con-seguenza i binding sono stati utilizzati solamente per rendere esplicitaquesta scelta.

5. I servizi (service) che raccolgono un set di metodi messi a disposizionedalla rete. Al loro interno sono elencati i punti di accesso (port) per ivari binding che sono stati definiti, i quali consistono solamente in unURL al quale e possibile raggiungere il servizio.

Con la versione 2.0 il formato WSDL ha subito alcune revisioni sintat-tiche, alcune delle quali sono mostrate nella Figura 4.3. La piu evidente di


Requester Web Server SOAPServer Provider

interpretePHP

nodo di comunicazione

SOAP SOAP binary

Figura 4.4: Schema di comunicazione tra requester e metodi providerimplementati in una classe PHP

queste modifiche e la scomparsa degli elementi message: con la versione 1.1del protocollo ogni operation ha uno ed un solo elemento di input che fariferimento ad un particolare message, il quale elenca i parametri da fornirealla operation. In molti casi pero questo porta ad avere un mapping 1:1 trale operation ed i message, di conseguenza nella versione 2.0 del protocollosi e deciso di eliminare questa ridondanza e permettere la creazione di piuparametri di input e output direttamente all’interno dei nodi operation,ognuno dei quali fa riferimento ad un particolare dato atomico o definito intypes.

Questa ed altre modifiche, apportate per aumentare la flessibilita e la se-mantica del linguaggio con lo scopo di renderlo piu facilmente utilizzabile aglisviluppatori, hanno permesso al formato WSDL di divenire, nel giugno 2007,uno standard raccomandato dal W3C2. Purtroppo il supporto di WSDL 2.0da parte di PHP e ancora limitato, di conseguenza per questo lavoro e statocreato un file aderente alla versione 1.1 del formato, in modo che potesseessere correttamente interpretato dalle classi impiegate.

4.4 Implementazione in PHP

I metodi del nodo di comunicazione, inteso come provider del Web Service,sono stati implementati in PHP, in modo da poter sfruttare un’architetturacome quella mostrata in Figura 4.4. In essa i messaggi SOAP inviati dalrequester verso il provider sono ricevuti da un piccolo web server, come adesempio lighttpd3, che si occupa di inoltrarle all’interprete PHP ed alla suaclasse SOAPServer, creata appositamente per gestire il lato provider di questotipo di comunicazione. Tale classe si occupa di invocare i metodi del Web

2http://www.w3.org/TR/wsdl20/3http://www.lighttpd.net

http://www.w3.org/TR/wsdl20/

http://www.lighttpd.net

4.5. IMPLEMENTAZIONE IN JAVASCRIPT 35

Service indicati nel messaggio SOAP ricevuto, tali metodi sono implementatiall’interno di un’altra classe PHP creata ad hoc.

In questa figura e evidenziato il tipo di formato che hanno i vari messaggiche si scambiano gli attori: a partire dal requester fino alla classe SoapServertale formato rimane SOAP, poi questa si occupa di interpretare il messaggioe convertire i parametri in valori binari, in modo che possano essere utilizzatidalla classe provider del Web Service. In direzione contraria i valori ritornatida tale classe sono passati a SOAPServer, la quale si occupa di convertirliin formato testuale ed impacchettarli all’interno di un frame SOAP che sarasuccessivamente inviato al requester tramite il web server.

Questo mette in evidenza come la classe che contiene i metodi del WebService e completamente agnostica delle modalita con le quali tali dati viag-giano sulla rete: essa si occupa solamente di gestire delle chiamate ricevutedalla classe SOAPServer che le e stata posta come interfaccia con il restodell’architettura.

4.5 Implementazione in JavaScript

Ad esempio dell’interoperabilita messa a disposizione dai Web Service e pos-sibile prendere la piattaforma di management fornita all’amministratore dellarete: questa si basa su HTML e JavaScript ma, grazie al protocollo SOAP,e in grado di richiedere l’esecuzione di procedure remote scritte in PHP etrattare dati ritornati come se l’esecuzione fosse locale.

La classe soapclient impiegata ha dovuto subire alcuni adattamenti inquanto e stata creata con lo scopo di funzionare su specifici WSDL genera-ti automaticamente da server quali asp.net e altri. E stato fatto un primolavoro di generalizzazione della classe per avvicinarla maggiormente al funzio-namento standard come interfaccia SOAP, ma parte del lavoro non e ancoracompleta.

GUI

Requester soapclient.js Provider

HTML

JavaScript

Client

binary SOAP

Figura 4.5: Schema di comunicazione tra provider del servizio e logica delrequester implementata in JavaScript


La struttura del lato client della comunicazione e mostrata in Figura 4.5.Il requester e simile al provider gia descritto (Figura 4.4), con la classesoapclient che si pone come interfaccia per il protocollo SOAP ed il codicedel requester che controlla l’interfaccia utente utilizzata dall’amministrato-re. In entrambe le immagini e stato volutamente ridotto ad un solo bloccol’endpoint con il quale il software comunica, per sottolineare il fatto che, see rispettato lo standard, non e necessario essere a conoscenza della naturadell’interlocutore per il corretto funzionamento della piattaforma.

4.6 Interfaccia con l’amministratore

Deciso di utilizzare gli strumenti appena descritti per le comunicazioni direte, le scelte riguardanti il client da fornire all’amministratore sono stateorientate verso il software piu aderente agli standard del W3C e presentein tutti i sistemi operativi: il browser Internet. Questa scelta e stata presaanche sulla base delle osservazioni che vedono la sempre maggiore presenzadi applicazioni fruibili tramite questo tipo di software ed anche la nascita diinteri Sistemi Operativi consumer di tipo browser based: queste osservazionipermettono di predire che nel prossimo futuro questo strumento non verra amancare all’interno di un generico Sistema Operativo, ma al contrario sarasempre maggiormente soggetto ad ottimizzazioni e miglioramenti. Questascelta apre inoltre la porta a possibilita future di estensione della piattaformain maniera tale che sia utilizzabile anche in mobilita, su dispositivi con ridottarisoluzione come smartphone, tablet e netbook.

4.6.1 Requisiti funzionali

Per consentire all’amministratore di analizzare le informazioni ottenute daisensori della rete e necessario che questo sia a conoscenza della sua topologia.Per questo lavoro si e assunto che l’amministratore abbia gia a disposizionequesta informazione, e che sia in grado di accedere direttamente al powermanager di un nodo qualsiasi, conoscendone l’indirizzo di rete. Dato questoprerequisito e possibile semplificare il compito dell’interfaccia utente ad unsemplice reporting di quanto richiesto dall’amministratore, senza porre ilrequisito di istruire quest’ultimo a riguardo della topologia reale della rete.

Fatta questa premessa e possibile definire un insieme di requisiti funzio-nali che un’interfaccia completa deve soddisfare. Innanzi tutto deve esserepermesso all’amministratore di ottenere l’andamento del consumo di poten-za e/o della larghezza di banda utilizzata in un periodo fissato, ad esempiodurante l’ultima mezz’ora. Queste informazioni possono essere visualizza-

4.6. INTERFACCIA CON L’AMMINISTRATORE 37

te in formato testuale, oppure mediante un grafico; quest’ultima soluzionepermette di avere un migliore colpo d’occhio su eventuali picchi massimi o mi-nimi di utilizzo che potrebbero suggerire la necessita di una riconfigurazionedell’architettura della rete intorno a quel nodo.

Un altro requisito che e stato posto e quello della cosiddetta sliding win-dow sui dati mostrati nei grafici, ovvero fare in modo che questi ultimi possa-no aggiornarsi periodicamente ed in maniera automatica, mostrando i nuovidati registrati nel database dai vari dumper presenti sulla rete e nasconden-do i dati troppo vecchi. Questo permette di dare all’amministratore l’ideadella dinamicita della rete, e gli consente di seguire la sua evoluzione senzadover inviare manualmente nuove query ad ogni periodo di dump. Questasliding window non deve pero essere mandatoria, ma un’opzione che l’ammi-nistratore puo attivare o rimuovere: se infatti la sua intenzione e quella diconcentrarsi su un particolare intervallo di tempo il grafico non deve spostarsida tale intervallo solamente per il fatto che sono disponibili nuovi dati.

All’interno dello stesso grafico deve essere inoltre possibile richiedere la vi-sualizzazione di piu di una grandezza: ad esempio potrebbe essere necessarioper l’amministratore valutare l’andamento della larghezza di banda utilizza-ta di due interfacce dello stesso nodo, per ricercare una correlazione tra ledue. Questo potrebbe portare ad osservare che il traffico che le attraversa ein qualche modo correlato e che un’interfaccia e sufficiente a sostenere il cari-co di entrambe senza introdurre eccessivi ritardi nelle comunicazioni in atto.Attenzione deve essere posta a non confrontare grandezze di natura diver-sa: non ha infatti senso mettere a confronto una larghezza di banda con unconsumo di potenza in quanto tali dati, anche se direttamente proporzionali,non hanno valori paragonabili.

Se sulla rete sta funzionando un power manager automatico l’amministra-tore deve inoltre essere in grado di prendere visione del suo comportamento,possibilmente ottenendo un logfile delle operazioni eseguite in un determina-to periodo di tempo. Questo log potrebbe dover essere confrontato con quellodi altri nodi nel caso sia avvenuta una comunicazione tra i power manager,oppure con le informazioni ottenute dai sensori durante il medesimo periododi tempo.

Motivo di creazione di questa interfaccia e anche quello di permettere al-l’amministratore di avere una parte attiva sulla piattaforma di power mana-gement. In mancanza del manager automatico l’amministratore deve esserein grado di modificare i parametri di funzionamento di qualsiasi nodo dellarete, mentre in presenza del software di gestione deve avere la facolta di mo-dificare il suo comportamento cambiando alcune variabili come ad esempiola sua aggressivita nel power saving, oppure forzando alcuni elementi dellarete in modo che rimangano costantemente attivi o spenti.


4.6.2 Client JavaScript

I requisiti sopra elencati devono essere rispettati da un’interfaccia di ammi-nistrazione completa e perfettamente funzionante della piattaforma di powermanagement. Quanto implementato fino ad ora, come gia descritto nell’in-troduzione, e un’interfaccia che invece ha il solo scopo di debug e visualiz-zazione dello stato e della storia della rete, senza la possibilita di compiereazioni attive.

Le funzionalita che sono state implementate sono di interrogazione dellabase di dati distribuita: l’amministratore puo inserire l’identificativo di unparticolare dispositivo e scegliere per esso la grandezza da richiedere al da-tabase con il tipo di aggregato da applicare a tale grandezza. Attualmentei valori salvati all’interno del database sono la larghezza di banda utilizzataed il consumo di potenza, rispettivamente espressi in Gb/s ed in Watt. Gliaggregati che sono calcolati automaticamente dal motore di database sonoil valore medio ed i due limiti minimo e massimo. Una volta che l’ammini-stratore ha compilato una richiesta contenente i dispositivi e le informazionida visualizzare per ognuno di essi, tramite un apposito pulsante puo lanciarel’operazione di query. Questa sara inviata per intero al nodo di rete dal qualee stata scaricata l’interfaccia, successivamente questo dovra suddividerla inmodo da poterla inoltrare ai nodi che contengono le informazioni richiestee, una volta ottenute le risposte, dovra essere in grado di aggregare i dati efornire un’unica risposta all’interfaccia di amministrazione. Per la visualiz-zazione delle informazioni ricevute l’interfaccia crea un grafico appoggiandosialla libreria d3js4. Questa permette di creare i cosiddetti Data-Driven Docu-ments, ovvero delle pagine HTML completamente dinamiche e modificabilisulla base dei dati da mostrare all’utente: le sue funzionalita non sono li-mitate alla creazione di grafici, ma ad esempio consentono la costruzione,direttamente nel DOM della pagina HTML, di tabelle contenenti i dati damostrare. Per funzionare sfrutta tecnologie standardizzate dal W3C, comeHTML per la struttura dei documenti, SVG per le componenti grafiche eCSS per definire lo stile di ogni elemento.

4http://d3js.org

http://d3js.org

Capitolo 5

Risultati ottenuti

Durante lo sviluppo della soluzione non e stato possibile eseguire test sul-l’hardware target in quanto non sono stati resi disponibili nodi di rete suiquali eseguire il software. Gli unici test possibili hanno riguardato l’avvioasimmetrico di una macchina dual core basata su architettura PowerPCTM.Si e scelto questo tipo di architettura in quanto e quella che piu si avvicinaal target di funzionamento pianificato. Un primo periodo di testing e statofatto per valutare il corretto funzionamento dell’avvio asimmetrico di dueSistemi Operativi, dopo aver ottenuto la compilazione di due kernel e com-pletato la stesura di due device tree ad hoc per la macchina di test impiegata.Da questa attivita sono state estratte le informazioni riportate in Appendi-ce B riguardanti gli accorgimenti da tenere in considerazione durante la fasedi progettazione dell’avvio e dell’assegnamento statico delle risorse ai duekernel.

Per l’ispezione di questa modalita di avvio si e seguito un approccio incre-mentale: inizialmente si e studiato l’avvio di un kernel al quale e assegnatasolamente una parte ridotta della memoria effettivamente disponibile; succes-sivamente si e passati all’avvio di un altro al quale e assegnata l’altra partedella memoria, lasciando inutilizzata la prima meta di questa. Si e quindiarrivati ad unire i due risultati ed a creare una lista di comandi da impartiread U-Boot per configurare l’avvio dei due kernel, partizionando la memoriadi sistema in due aree disgiunte.

Non essendo a disposizione l’hypervisor citato nella Sezione 3.3 ci si elimitati a valutare la comunicazione attraverso due interfacce fisiche collegatead uno switch di rete. Su entrambi i Sistemi Operativi e stato installato ilweb server lighttpd, poi per ognuno si e proceduto con il download di unpiccolo file di esempio verso l’host di compilazione, con lo scopo di valutarela comunicazione con l’interfaccia di amministrazione della rete. Un secondodownload e stato fatto da un Sistema Operativo verso l’altro e vice versa,

39

40 CAPITOLO 5. RISULTATI OTTENUTI

HW

SO1WS1

SO2WS2

admin

Figura 5.1: Direzioni nelle quali e stato trasferito il file di test

per valutare la comunicazione in caso di query distribuita. Uno schema deitrasferimenti provati e mostrato anche in Figura 5.1.

Completato questo passo ci si e concentrati sulla creazione di un am-biente di test per valutare la comunicazione tra PHP su nodi diversi e traPHP e JavaScript usando i Web Service e SOAP. Non avendo a disposizionel’hardware target si e inserito tale piattaforma software in una rete simulata,composta di tre macchine virtuali QEMU collegate all’host tramite delle in-terfacce connesse su un bridge software appositamente creato, come mostratoin Figura 5.2.

Queste macchine hanno eseguito tre istanze di kernel, ognuna equipag-giata con un web server, l’interprete PHP, gli script host, il software di dumped il database locale, ovvero la configurazione software che dovrebbe ave-re il power manager installato su un generico nodo di rete. Non avendo adisposizione la doppia cpu PowerPCTM su queste macchine virtuali non estato provato l’avvio asimmetrico, ma solamente l’esecuzione del kernel in-caricato di eseguire il power manager. Questo ha impedito di dimostrarela non intrusivita del power manager rispetto al normale funzionamento delnodo di comunicazione, ma ha comunque fornito la possibilita di valutarela capacita di comunicazione tramite SOAP dei nodi e della piattaforma diamministrazione.

Per eseguire questa categoria di test si e deciso di sfruttare il modello

browser

vm1 vm2 vm3

bridge

Figura 5.2: Architettura logica della rete di test

41

browservm1

vm2

vm3query

1.x, 2.y, 3.z

query 1.x

query 3.z

data 1.x

data 3.z

data1.x, 2.y, 3.z

Figura 5.3: Schema di esecuzione di una query distribuita

di consumo di potenza implementato all’interno del codice del software didump. Come e stato mostrato nell’introduzione e possibile ricavare alcuneinformazioni sullo stato del nodo anche quando non sono disponibili i relativisensori: e sufficiente applicare le equazioni del modello ai dati disponibili. Sie quindi deciso di far funzionare il software di dump facendogli sfruttare ilmodello su dei dati di utilizzo della larghezza di banda disponibile generati inmaniera pseudo-casuale. Tale modello e stato esteso rispetto alla sua versionestandard in quanto aggiunge uno spostamento della media e della varianzadei valori casuali generati sulla base dell’ora di sistema alla quale e eseguita lamisurazione. Questa modifica e stata effettuata per dare piu coerenza ai daticasuali generati e una maggiore prevedibilita alle informazioni di consumo dipotenza registrate all’interno del database.

Data questa piattaforma sono state compiute due categorie di test, unalocale e una distribuita. Nella prima si e utilizzato il browser per scaricarela piattaforma di amministrazione da una particolare macchina virtuale, etramite questa si e eseguita una query sul database locale al nodo. Tramitewireshark1 si sono studiate le comunicazioni con tale macchina virtuale e sie riscontrata l’effettiva aderenza dei pacchetti allo standard SOAP e la lorocorretta formattazione rispetto al WSDL definito.

Per quanto riguarda il test distribuito sono state compiute le stesse ope-razioni, ma questa volta dall’interfaccia dell’amministratore si sono ancherichieste delle informazioni presenti sulle altre macchine virtuali. Questo ti-po di interrogazione ha obbligato gli script PHP presenti sul nodo da cuie stata scaricata l’interfaccia di partizionare la richiesta ricevuta come mo-strato in Figura 5.3. Si e potuto verificare che le query inoltrate verso glialtri nodi contenevano solamente informazioni delle quali il sorgente non eraa conoscenza, il quale successivamente ha aggregato le risposte ricevute inun unico messaggio ritornato all’interfaccia di amministrazione.

1Software di packet sniffing che permette di studiare le comunicazioni di rete mostrandoin una lista ordinata tutte le comunicazioni che attraversano una particolare interfaccia,evidenziando i vari protocolli utilizzati — http://www.wireshark.org

http://www.wireshark.org

42 CAPITOLO 5. RISULTATI OTTENUTI

Capitolo 6

Conclusioni

In questo lavoro di tesi si sono poste le basi per un futuro sviluppo di unaarchitettura di power management distribuito a livello di rete. La situazio-ne di partenza vedeva una generica rete di comunicazione in una situazionecompletamente non gestita e dal comportamento non analizzabile: un even-tuale amministratore avrebbe avuto un complicato compito di valutazionedelle performance nodo per nodo e, conoscendo le abitudini degli utenti del-la rete o stimandole da profili di utilizzo generici, avrebbe dovuto applicaredelle politiche di power saving connettendosi manualmente ad ogni nodo perattivare o disattivare i componenti che richiedevano modifiche.

L’obiettivo che ci si e posti prevede che la rete di comunicazione, in parti-colare i singoli nodi, sia in grado di gestirsi in maniera autonoma, applicandoalcune politiche di power saving specificate mediante un linguaggio forma-le direttamente interpretabile dal software do power management del nodo.Questo software sara in grado di inviare autonomamente opportuni comandidi attivazione e spegnimento di ogni possibile elemento della rete suscettibiledi ottimizzazione sotto il profilo del consumo di potenza. Dopo un’analisidi alcune alternative e stato deciso di implementare un software distribuitoche, appoggiandosi su ogni nodo di comunicazione, fosse in grado di analiz-zare lo stato attuale e storico del nodo ospite e di quelli adiacenti: grazie atali informazioni il power manager deve essere in grado di compiere scelteadeguate relativamente a quali componenti della rete attivare o disattivaresecondo quanto descritto dalla politica che sta attuando. Il power mana-ger distribuito, durante la fase di raccolta dei dati da analizzare, non deveinfluenzare in alcun modo il funzionamento normale della rete, tranne cheper il piccolo quantitativo di traffico necessario alle comunicazioni tra i varinodi; e stato quindi deciso di disaccoppiarne il funzionamento dal softwaredel nodo, dedicandogli di conseguenza un core di elaborazione e una partedella memoria di sistema disponibile.

43

44 CAPITOLO 6. CONCLUSIONI

Per garantire la comunicazione tra i vari moduli del power manager di-stribuito sulla rete si e deciso di sfruttare lo standard dei Web Service, conl’obiettivo di ottenere una comunicazione facilmente implementabile permet-tendo di astrarre da tutte le problematiche legate alla gestione del canale,all’encoding e al parsing dei messaggi scambiati. Questa soluzione rende inol-tre molto semplici eventuali estensioni future della comunicazione tramitenuovi metodi e nuovi messaggi.

Per permettere ad un amministratore di studiare ed eventualmente modi-ficare il comportamento del power manager, si e resa necessaria la realizzazio-ne di un’apposita piattaforma in grado di comunicare con questo utilizzandoil suo stesso linguaggio, quello dei Web Service. E stato deciso di implemen-tare tale piattaforma in HTML e JavaScript, in modo da non vincolarla aduna particolare piattaforma software, ma facendo invece in modo che fosseaderente agli standard W3C, l’ente che si occupa della standardizzazione ditutto quello che ruota attorno alla rete Internet.

Questo lavoro di tesi ha riguardato principalmente il backend della piat-taforma, in particolare lo studio dell’avvio asimmetrico di due Sistemi Ope-rativi, uno dei quali destinato ad eseguire il solo power manager. Per ognipower manager e stato creato un software in grado di leggere periodicamentele informazioni di prestazione dai vari sensori presenti sul nodo, e di calcola-re i valori per i quali i sensori non sono disponibili, sfruttando un appositomodello. A tutte queste informazioni e stata data persistenza all’interno diun database locale al nodo e sono state esposte verso la rete, tramite i WebService, le funzionalita per interrogare tale base di dati.

Per la comunicazione di rete e stato progettato e creato il file WSDL chedescrive i metodi esposti, e si e fatto in modo che le classi di interfaccia trail software e la rete potessero usare tale file per auto-configurarsi. Dal latodella piattaforma di amministrazione ci si e concentrati sulla creazione diuno strumento di debug della rete, non inteso come utilizzabile in ambitoproduttivo a meno di non apportare le dovute estensioni per completare lasua struttura. Questa interfaccia e infatti in grado solo di eseguire alcunequery al database distribuito e di visualizzare i dati ottenuti dalla rete.

Quanto e stato fatto deve essere posto come base per futuri sviluppi edestensioni della piattaforma. Alcuni di questi possibili obiettivi futuri sonoelencati nella sezione seguente.

6.1 Sviluppi futuri

Per il proseguimento dello sviluppo di questa piattaforma sono stati identifi-cati alcuni passi che sono determinanti per il suo corretto funzionamento.

6.1. SVILUPPI FUTURI 45

Il primo passo da completare riguarda la possibilita di comunicazione tranodo di rete e relativo power manager utilizzando un socket virtuale in vecedi un’interfaccia fisica. Cio si rivela essenziale per ridurre al minimo l’impie-go di risorse hardware da parte della piattaforma di power management e,di conseguenza, evitare sprechi di potenza innanzitutto da parte della piat-taforma stessa. Permette inoltre di massimizzare l’utilizzo di hardware dinetworking a supporto della rete, senza dedicare delle componenti al solofunzionamento del power manager.

A pari priorita rispetto al passo sopra citato si trova la necessita di renderela piattaforma in grado di avere un ruolo attivo nella gestione energetica dellarete, potendo inviare al software del nodo specifici comandi di attivazione espegnimento di particolari dispositivi. Questo passo non e dipendente daquello citato in precedenza, in quanto in via temporanea e possibile sfruttareun’interfaccia fisica per la comunicazione tra power manager e nodo; e adogni modo un passo molto importante in quanto elemento determinante perl’attuazione di una qualsiasi politica di power management, sia essa gestitada un amministratore umano o da un software appositamente creato.

Completato questo passo diventa importante un primo lavoro di estensio-ne dell’interfaccia amministratore per garantire a quest’ultimo la possibilitadi inviare comandi ai vari nodi e non solamente di effettuare delle query.Cio consente innanzitutto di valutare la correttezza della comunicazione trapower manager e nodo di rete e, in secondo luogo, l’interfaccia puo essere uti-lizzata da un amministratore per modificare manualmente la struttura dellarete senza dover impiegare la console di amministrazione dei nodi oggettodella riconfigurazione.

Un ulteriore sviluppo necessario al completamento del power managerconsiste nell’implementazione di un policy manager, ovvero di quel software,cuore della piattaforma automatica e in esecuzione su ogni nodo di rete, con ilcompito di analizzare lo stato del nodo e, tramite apposite comunicazioni congli altri policy manager, di valutare l’attivazione o lo spegnimento di alcunisuoi componenti. Per una maggiore versatilita di questo software potrebbeessere necessario mantenere in un file di configurazione esterno alcuni suoiparametri di funzionamento, in modo che un amministratore umano possaagire su tali parametri per modificare il comportamento del software. Lasoluzione ottima sul piano della versatilita potrebbe essere quella in cui vasviluppato preventivamente un linguaggio di descrizione di generiche politi-che e, tramite questo linguaggio, sia possibile comunicare al software sopracitato le azioni da compiere in particolari situazioni che potrebbero verificar-si. Un’ipotesi interessante da questo punto di vista potrebbe essere quella divalutare l’applicabilita di regole scritte in Fuzzy Logic, definendo delle varia-bili letterali per descrivere lo stato del nodo e della rete nel suo intorno e,

46 CAPITOLO 6. CONCLUSIONI

tramite queste regole, prendere le decisioni di power saving.Altri possibili sviluppi della piattaforma riguardano principalmente il

client, e spaziano dalla correzione della libreria soapclient per garantirleuna maggiore aderenza allo standard WSDL, all’aggiornamento delle libreriedi interfaccia utilizzate, in modo che possano accettare ed utilizzare lo stan-dard WSDL 2.0 invece della sua versione 1.1, dato che quest’ultima non emai stata ratificata come standard W3C. Un’altra estensione potrebbe essereinfine quella che rilassa il vincolo indicato all’inizio della Sezione 4.6.1, se-condo il quale l’amministratore deve essere a conoscenza della struttura dellarete: potrebbe essere interessante fare in modo che la piattaforma di ammi-nistrazione possa costruire una mappa incrementale della rete, mostrandoinizialmente solo il nodo dal quale e stata scaricata l’interfaccia e, tramiterichieste successive, possa fornire all’amministratore una mappa piu o menodettagliata della rete a seconda delle necessita.

Appendice A

Modello XML del nodo

In questa appendice, ad esempio della modellazione che e stata eseguita, emostrato un file XML che descrive la struttura di un generico nodo di rete.Per la validazione di questo tipo di file e stata fatta la scelta dei DocumentType Definition (DTD) in quanto non sono necessarie regole stringenti sutipi di dati ma e invece importante la struttura del documento.

A.1 Modello XML

A seguire e riportato il modello XML di un nodo di rete con due matrix (1.5 e1.6), due line card (1.7 e 1.8) con rispettivamente due e quattro interfacce direte (1.7.1, 1.7.2, 1.8.1 - 1.8.4). Ogni dispositivo e identificato da un omonimonodo nell’albero XML, tranne per le parti comuni, per le quali vi e solo unconsumo di potenza statico: queste sono rappresentate dai nodi commonPartin cima all’albero.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!DOCTYPE node SYSTEM "node.dtd">

<node id="1">

<commonPart id="1" description="Fan" sPower="30" />

<commonPart id="2" description="Supply" sPower="50" />

<commonPart id="3" description="EC" sPower="20" />

<commonPart id="4" description="SC" sPower="18" />

<matrix id="5"

description="Matrix 1"

maxRate="320" sPower="100" dPower="50" />

<matrix id="6"

description="Matrix 2"

47

48 APPENDICE A. MODELLO XML DEL NODO


<lineCard id="7"

description="2x10Gb/s"

maxRate="20" sPower="30" dPower="20">

<interface id="1"

description="SFP 1x10Gb"


<interface id="2"



</lineCard>

<lineCard id="8"

description="10x1Gb/s"

maxRate="10" sPower="30" dPower="20">

<interface id="1"



<interface id="2"



<interface id="3"



<interface id="4"



</lineCard>

</node>

A.2 File DTD

A seguire il file node.dtd che permette di validare l’XML di descrizionedel nodo. Nel file XML mostrato alla sezione precedente non sono elencatisensori, ma dal DTD e possibile notare che e consentito aggiungerli all’internodi un apposito nodo che, se presente, deve comparire come primo figlio diogni nodo dell’albero XML.

<!ELEMENT node (commonPart*, matrix+, lineCard+)>

A.2. FILE DTD 49

<!ATTLIST node id CDATA #REQUIRED>

<!ELEMENT commonPart (sensors?)>

<!ATTLIST commonPart id CDATA #REQUIRED>

<!ATTLIST commonPart description CDATA #IMPLIED>

<!ATTLIST commonPart sPower CDATA #REQUIRED>

<!ELEMENT matrix (sensors?)>

<!ATTLIST matrix id CDATA #REQUIRED>

<!ATTLIST matrix description CDATA #IMPLIED>

<!ATTLIST matrix maxRate CDATA #REQUIRED>

<!ATTLIST matrix sPower CDATA #REQUIRED>

<!ATTLIST matrix dPower CDATA #REQUIRED>

<!ELEMENT lineCard (sensors?, interface+)>

<!ATTLIST lineCard id CDATA #REQUIRED>

<!ATTLIST lineCard description CDATA #IMPLIED>

<!ATTLIST lineCard maxRate CDATA #REQUIRED>

<!ATTLIST lineCard sPower CDATA #REQUIRED>

<!ATTLIST lineCard dPower CDATA #REQUIRED>

<!ELEMENT interface (sensors?)>

<!ATTLIST interface id CDATA #REQUIRED>

<!ATTLIST interface description CDATA #IMPLIED>

<!ATTLIST interface maxRate CDATA #REQUIRED>

<!ATTLIST interface sPower CDATA #REQUIRED>

<!ATTLIST interface dPower CDATA #REQUIRED>

<!ELEMENT sensors (state|rate|power)+>



<!ELEMENT state EMPTY>

<!ATTLIST state address CDATA #REQUIRED>



<!ELEMENT rate EMPTY>

<!ATTLIST rate address CDATA #REQUIRED>



<!ELEMENT power EMPTY>

<!ATTLIST power address CDATA #REQUIRED>

50 APPENDICE A. MODELLO XML DEL NODO

Appendice B

Configurazione di avvioasimmetrico

In questa appendice sono presenti maggiori informazioni riguardanti la con-figurazione di un avvio asimmetrico. Nella prima sezione si tratta unabreve introduzione ai device tree come strumento di descrizione dell’hard-ware, successivamente si porra l’attenzione sulla configurazione richiesta peril caricamento di due kernel sullo stesso nodo di rete.

B.1 Device Tree

Come e stato detto i flattened device tree che devono essere forniti al kernel almomento dell’avvio sono dei file binari che descrivono l’hardware a sua dispo-sizione. Tali file, proprio a motivo della loro natura, sono detti Device TreeBlob (DTB) e sono generati da un apposito compilatore a partire da un filesorgente testuale definito Device Tree Source (DTS). Il motivo di questa com-pilazione preventiva da DTS a DTB risiede nella maggiore compattezza delbinario rispetto al sorgente, e dal fatto che il primo e direttamente utilizzabiledal kernel, eliminando la necessita del parsing di stringhe di testo.

Inoltre per essere piu facilmente trattabili i file DTS possono avere unastruttura gerarchica che rispecchia la stessa struttura che e possibile trovarein hardware. Questo ad esempio porta con se un vantaggio nella descrizionedegli indirizzi delle risorse: le periferiche collegate ad un determinato bushanno una proprieta reg che permette di definire gli indirizzi relativi a talebus e non quelli globali di sistema. Nel nodo che descrive il bus vi sara poiil campo ranges che permette al compilatore di convertire gli indirizzi localiin indirizzi di sistema.

51

52 APPENDICE B. AVVIO ASIMMETRICO

Ad esempio si consideri la seguente parte di file DTS, preso da Grant Li-kely (2008):

opb {

compatible = "simple-bus";

#address-cells = <1>;

#size-cells = <1>;

ranges = <0x0 0xe0000000 0x20000000>;

serial@0 {

compatible = "ns16550";

reg = <0x0 0x10>;

interrupt-parent = <&UIC0>;

interrupts = <1 4>;

};

serial@10000 {

compatible = "ns16550";

reg = <0x10000 0x10>;

interrupt-parent = <&UIC0>;

interrupts = <2 4>;

};

flash@1ff00000 {

compatible = "amd,s29gl256n", "cfi-flash";

reg = <0x1ff00000 0x100000>;

};

};

E possibile notare una sintassi gerarchica simile al formato JSON. Ogninodo ha una proprieta compatible per suggerire al kernel quale driver cari-care per gestire tale periferica, e la proprieta reg per definire gli indirizzi aiquali puo essere acceduta. In particolare il primo valore in quel campo defi-nisce l’indirizzo base, mentre il secondo definisce la dimensione della regionedi indirizzi dedicata a tale periferica.

La porta seriale etichettata come serial@10000, ad esempio, e raggiun-gibile all’indirizzo 0x10000 del bus opb, ed il campo ranges di quest’ultimoindica che l’indirizzo 0xe0000000 del nodo genitore (non mostrato in questoesempio) e riservato a tale bus ed e considerato come indirizzo base (0x0) peri nodi figli. Di conseguenza la porta seriale citata in precedenza ha indirizzo0xe0010000 all’interno del nodo genitore di opb.

Per ulteriori dettagli sui device tree si rimanda a Grant Likely (2008) ealla pagina a loro dedicata su elinux.org1.

1http://elinux.org/Device_Trees

http://elinux.org/Device_Trees

B.2. CONFIGURAZIONE DELL’AVVIO ASIMMETRICO 53

B.2 Configurazione dell’avvio asimmetrico

Per ottenere una corretta configurazione di un avvio asimmetrico sulla stessamacchina vi sono alcune considerazioni di cui tenere conto. Molta attenzionedeve essere posta nella creazione dei device tree, in quanto servono ad indi-care al kernel quali periferiche gli e consentito utilizzare, serve inoltre unaconfigurazione particolare al kernel che non puo sfruttare l’indirizzo 0x0 dellamemoria di sistema.

B.2.1 Configurazione e compilazione dei device tree

Per primo e necessario considerare il fatto che, salvo alcune particolari ecce-zioni come la cache L2, una determinata periferica non puo essere condivisadai due kernel: in questa situazione infatti si avrebbe un conflitto in quantoentrambi cercherebbero in fase di avvio di inviare delle stringhe di inizializza-zione che modificherebbero la configurazione gia compiuta dall’altro. Ricor-dando che ognuno dei due kernel e progettato per essere l’unico utilizzatoredi ognuna delle periferiche e necessario che non vi siano zone grige, in quantoin questo caso il comportamento della singola periferica o dell’intero siste-ma se questa rappresenta una componente importante dello stesso, rimaneindefinito.

Una delle eccezioni a quanto appena scritto riguarda la memoria di si-stema: essa infatti all’interno dei device tree e descritta tramite uno o piuappositi nodi, etichettati con memory, che al loro interno contengono sola-mente la proprieta reg che definisce l’indirizzo base e la dimensione dellamemoria disponibile. Tramite una corretta configurazione e quindi possibi-le dedicare parte della memoria ad un Sistema Operativo e parte all’altro.All’intero del file DTS e possibile lasciare pari a zero i campi relativi al-la memoria di sistema, in quanto il bootloader e in grado di fornire questeinformazioni al kernel tramite delle apposite variabili d’ambiente.

Per consentire la comunicazione tra i due Sistemi Operativi evitando l’im-piego di interfacce di rete esterne e necessario dedicare una parte della memo-ria di sistema in modo che sia utilizzabile esclusivamente per questa comu-nicazione. Quest’area di memoria non deve essere accessibile ai due kernel,in quanto e importante che non vi si eseguano operazioni di paginazione oswap su disco. In questo caso infatti si avrebbe che in quest’area potrebberoessere allocati processi da parte di entrambi i Sistemi Operativi, con ovvieconseguenze di inconsistenza della memoria stessa.

Una volta creati i due file DTS da convertire in binari e importante ri-cordare che il compilatore dei device tree ha un parametro per specificarequal e la CPU sulla quale il kernel deve essere avviato. Questa informazione

54 APPENDICE B. AVVIO ASIMMETRICO

deve essere specificata tramite riga di comando, in quanto all’interno del fileDTS e presente solamente una lista delle CPU disponibili, ma non e possi-bile definire quale tra queste e quella alla quale e demandato di eseguire leprimissime istruzioni di avvio del kernel dopo il suo caricamento in memoria.

B.2.2 Configurazione e compilazione dei kernel

E inoltre importante ricordare che di default il kernel e compilato con l’as-sunzione di essere allocato all’inizio della memoria di sistema, a partire dal-l’indirizzo 0x0. Questo e possibile per il kernel del Sistema Operativo alquale e assegnata la porzione bassa della memoria, quella cioe che inizia ef-fettivamente all’indirizzo 0x0, mentre per l’altro e necessario modificare talecostante in modo che rispecchi l’effettiva ubicazione della memoria che gli ededicata.

Questa operazione e necessaria in quanto il device tree non puo conte-nere un campo di traduzione di indirizzi all’interno del nodo memory ma hasolamente un campo reg che definisce indirizzo base e una dimensione dellamemoria disponibile. Questo tipo di modifica dei parametri di configurazionedel kernel e necessaria per ogni hardware che non ha la memoria di sistemaraggiungibile all’indirizzo 0x0.

La posizione che deve occupare in memoria il kernel pone un vincolo sulpartizionamento della RAM: questo infatti e progettato con l’assunzione diessere allocato nella parte bassa della memoria disponibile. Anche se questapuo essere impostata tramite il bootloader e necessario definire il partiziona-mento il prima possibile, in quanto l’indirizzo di inizio della memoria riservataal secondo Sistema Operativo coincide con quello di avvio del kernel, e questorappresenta uno dei parametri di compilazione dello stesso.

Appendice C

Metodi implementati

Su ogni nodo di comunicazione sono stati implementati alcuni metodi perverificare il corretto funzionamento della piattaforma, l’interfaccia con talimetodi e descritti in dettaglio all’interno del file WSDL.

In questa appendice si intende fornire una loro breve descrizione.

getXMLHistory()

Permette di richiedere la lista delle letture eseguite in un determinato periododai dispositivi indicati. Gli argomenti sono elencati di seguito e mostrati inmaniera grafica in Figura C.1a.

1. devices: Array di stringhe, contenenti l’elenco degli identificativi direte dei dispositivi richiesti

2. fields: Array di stringhe, con l’elenco delle informazioni richieste perogni dispositivo

3. startTS: Stringa rappresentante il timestamp dell’inizio dell’intervallodi tempo oggetto della query

4. endTS: Stringa rappresentante il timestamp del termine dell’intervallodi tempo oggetto della query

getJSONHistory()

Il suo comportamento e identico a quello del metodo precedente, la dif-ferenza riguarda la formattazione del messaggio di risposta: mentre pergetXMLHistory questo e in formato XML, getJSONHistory ritorna unastringa JSON. La struttura logica e le informazioni contenute nei messag-gi e identica, il vantaggio di JSON rispetto ad XML sta nel fatto che ilprimo utilizza una notazione decisamente meno verbosa e di conseguenza piucompatta.

55

56 APPENDICE C. METODI IMPLEMENTATI

getXMLHistoryV2()

Il suo comportamento e simile a quello dell’omonimo getXMLHistory, rap-presenta infatti semplicemente una variante di tale metodo. Mentre conil precedente era necessario richiedere gli stessi campi per ogni dispositivo,con questo metodo e possibile diversificare tale richiesta, in quanto il campofields e affiancato ad ogni istanza di address. L’elenco dei parametri dafornire a questo metodo e mostrato nell’albero di Figura C.1b

getJSONHystoryV2()

E la controparte V2 di getJSONHistory, anche questo con lo stesso compor-tamento ma con la modifica ai parametri gia descritta al punto precedenteper getXMLHistoryV2.

Per tutti i metodi elencati le due stringhe che rappresentano i timestamplimite richiesti startTS e endTS sono opzionali, e se non specificati non eimposto un filtro ai record recuperati dai database. Questo significa che adesempio se nessuno dei due valori e specificato vengono ritornati tutti i recordche rispettano gli altri vincoli.

Il formato delle stringhe che rappresentano dei timestamp, siano esse tra iparametri di ingresso dei metodi o tra i valori restituiti, devono essere aderen-ti allo standard ISO 8601:2004, adottato anche dal W3C. Questo impone ilformato YYYY-MM-DDTHH:MM:SSZ, nel quale i primi dieci caratteri rappresen-tano una data, la lettera T e utilizzato come carattere separatore ed il restodella stringa rappresenta un orario. Tale orario e terminato dalla lettera Z

che specifica tale timestamp come relativo al Tempo Universale Coordinato(UTC).

La struttura dei messaggi ritornati dai metodi e quella mostrata in Fi-gura C.2, in base al metodo invocato essa puo essere espressa in XML o inJSON, ma per entrambe il contenitore rimane lo stesso, ovvero un messaggioSOAP espresso in XML. Nel caso di JSON, quindi, non e possibile eseguireuna validazione usando XML Schema, in quanto tale messaggio e identifi-cato come un contenitore SOAP con al suo interno una generica stringa dicaratteri.

57

request

devices:array-of string

fields:array-of string

startTS:timestamp

endTS:timestamp

(a) Metodi V1

request

startTS:timestamp

endTS:timestamp

args:array-of

address:string

field:string

(b) Metodi V2

Figura C.1: Alberi delle strutture dati da fornire ai metodi implementati

retVal:array-of

address:string

history:array-of

startTS:timestamp

endTS:timestamp

PS

min: float

avg: float

max: float

BW

min: float

avg: float

max: float

PC

min: float

avg: float

max: float

Figura C.2: Albero della struttura dati restituita dai metodi implementati

58 APPENDICE C. METODI IMPLEMENTATI

Bibliografia

Dronamraju Subramanyam, John Rekesh S. A. (2012). Multicore networkingin linux user space with no performance overhead. Embedded Online,http://www.embedded.com.

Grant Likely J. B. (2008). A symphony of flavours: Using the device tree todescribe embedded hardware. Proceeding of Linux Symposium, http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf.

Merritt R. (2008). Cpu designers debate multi-core future. EE Times Online,http://www.eetimes.com.

Pautasso C.; Zimmermann O.; Leymann F. (2008). Restful web services vs.big’ web services: making the right architectural decision. In Proceedingsof the 17th international conference on World Wide Web, WWW ’08, pp.805–814, New York, NY, USA. ACM.

59

http://www.embedded.com

http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf

http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf

http://www.eetimes.com

Documents

Progettazione e sviluppo di una piattaforma di power ... · della sesta versione del protocollo (IPv6) per far fronte a questa crescita che sembra inarrestabile. Anche in un contesto