l2007 02 login63

EDITORIALE

Login Internet Expert n.63 Marzo/Aprile 20073

www.infomedia.it

BIMESTRALE - ANNO 12 - N.63 “Con licenzaparlando”

Agli inizi di Aprile, l’Apache Software Foundation ha inviato una lettera a Sun Microsystems lamentando che è dall’Agosto 2006 che non riesce ad acquisire da Sun una licenza “accettabile” per il JCK (Java Compatibility Kit) di Java SE 5, necessario per dimostrare la compatibilità di Apache Harmony (un progetto, in origine donato da IBM, della Apache Foundation di implementazione indipendente di JDK per JSE 5 e di relativa architettura runtime costituita da una libreria di classi e da una Virtual Machine) con le specifiche Java SE 5. Non avendo ricevuto una risposta diretta entro trenta giorni, l’Apache Software Foundation ha deciso di pubblicare questa lettera sul proprio sito (http://www.apache.org/jcp/sunopenletter.html), informando la comunità Internet.In pratica, la licenza del JCK offerta da Sun impone delle restrizioni sulle condizioni di utilizzo di questo software da parte degli utenti, condizioni che Apache Foundation riconosce come ostative. Ciò che la ASF sottolinea è l’incompatibilità di un passo della licenza JCK con i termini del Java Specification Participation Agreement (JSPA), sottoscritto anche dalla ASF a suo tempo.Il passo “inaccettabile” è quello dell’art. II “Read Only Rigths” comma A., relativo ai diritti trasferiti della licenza JCK, che, tradotto, recita “… Sun concede una licenza non esclusiva, non trasferibile, mondiale e royalty-free di visionare e leggere la tecnologia licenziata unicamente per scopi di valutazione interna. Come condizione conseguente dei diritti di licenza, non si potrà copiare, modificare, creare lavori derivati, esporre in pubblico, eseguire in pubblico, compilare, avviare o eseguire, dimostrare, rivelare, distribuire o utilizzare altrimenti la tecnologia licenziata, compreso senza limitazioni, l’utilizzo della tecnologia licenziata per sviluppare altre suite di test o altri tool concepiti per validare la compatibilità con una specifica, o parte di essa, per o inerente alle tecnologie Java”.Pertanto non poter modificare, creare lavori derivati, esporre in pubblico, compilare, avviare o eseguire, sono difatti un ostacolo per poter “dimostrare” la compatibilità di Harmony con le specifiche JSE 5 (come appunto richiesto dalla specifica della licenza Sun per Java SE 5). Al momento non risulta ci sia stata una risposta ufficiale diretta, salvo dei commenti su un weblog Sun (blog.sun.com) e un annuncio alla conferenza JavaOne che il JCK diventerà open source (in futuro). Una cosa un alquanto buffa da leggere è nel blog “On The Record” (blogs.sun.com/ontherecord/entry/apache_open_letter_to_sun) in cui, tra l’altro, si legge “la tecnologia Java coinvolge molti interessati, e riconosciamo di non poter essere sempre in grado di soddisfare tutti mentre percorriamo questo processo. In alcuni casi,” (e qui viene il bello) “dovremo convenire di essere in disaccordo su alcuni punti”. Dopo aver sottoscritto un Java Specification Participation Agreement che impone determinati vincoli impolementativi, come si può poi riconoscere di dover convenire di poter essere in disaccordo su alcuni punti, se difatti creano un vantaggio competitivo per chi detiene (in esclusiva) i più ampi diritti? Si tratta solo di un difetto nella transizione dal mondo commerciale al mondo open source? Con licenza parlando o con beneficio del dubbio?

Natale Fino

D I R E T T O R E R E S P O N S A B I L E MA R I A L E T I Z I A MA R I(M M A R I@ I N F O M E D I A . I T )

D I R E Z I O N E E D I T O R I A L ENA T A L E F I N O

(N F I N O@I N F O M E D I A . I T )

C O L L A B O R A T O R IA L E S S I O A L E S S I

M A U R I Z I O D E L M O N T E

A N D R E A L E O N C I N I

F I L I P P O M A R T I N E L L I

LU I G I M O R E L L I

A L B E R T O R O S O T T I

N I C O L Ò TA M B O N E

GR U P P O ED I T O R I A L E I N F O M E D I A S R LV I A VA L D E R A P.116

56038 PO N S A C C O (P I ) I T A L I ATE L 0587736460 FA X

0587732232E-M A I L R E D_L O G I N@ I N F O M E D I A . I T

S I T O WE B W W W. I N F O M E D I A . I T

D I R E Z I O N E NA T A L E F I N O (N F I N O@I N F O M E D I A . I T )

TE C H N I C A L B O O KL I S A VA N N I

( B O O K@I N F O M E D I A . I T )

M A R K E T I N G & A D V E R T I S I N GSE G R E T E R I A : 0587736441

M A R KE T I N G@I N F O M E D I A . I T

A M M I N I S T R A Z I O N ESA R A MA T T E I

( A M M I N I S T R A Z I O N E@I N F O M E D I A . I T )

S E G R E T E R I A EN R I C A NA S S I

( I N F O@I N F O M E D I A . I T )

G R A F I C APA O L O FR A N C O

(G R A F I C A@G R U P P O I N F O M E D I A . I T )

S T A M P AT I P O L I T O G R A F I A PE T R U Z Z I C I T T À D I CA S T E L L O (PG )

U F F I C I O A B B O N A M E N T ITE L 0587736460 FA X 0587732232

A B B O N A M E N T I@ I N F O M E D I A . I TW W W. I N F O M E D I A . I T

Per contattare la Redazione di Login

scrivete a:Gruppo Editoriale Infomedia S.r.l.

Via Valdera P. 116 - 56038 Ponsacco (PI)Tel. 0587/736460 (r.a.) - Fax 0587/732232

e-mail: [email protected] - http://www.infomedia.it/Login

I listati che corredano gli articoli sonoliberamente scaricabili dagli indirizzi:

http://www.infomedia.it/Riviste/LoginFtp://ftp.infomedia.it/pub/Login/listati

Login Building The Information Highwayè una rivista del Gruppo Editoriale Infomedia S.r.l.

Direzione e amministrazioneVia Valdera P. 116 - Ponsacco (PI)

Registrazione n.18 del 25/11/99 - Contenuto pubblicitario inferiore al 45%

u Plone Sorrento Sprint 2007 60

SpecialeCluster di calcolo Beowulf con LinuxBeowulf, il Signore dei Cluster

di Nicolò Tambone 16

Realizzazione di un cluster di calcolo Beowulf

di Alessio Alessi 19

Architetture cluster con Linux

di Luigi Morelli 24

Appunti sulle topologie dei cluster

di Natale Fino 29

Cutting edgeJava e RFID

di Andrea Leoncini 35

Elementi di sicurezza elettrica nelle reti dati

sanitarie: il trasformatore d’isolamento

di Alberto Rosotti 42

Solutions Un download “unificato” con i metalink

di Natale Fino 8

Accesso esterno sicuro: sottoreti e VPN

di Filippo Martinelli 52

REPORTAGE

LOGIN n.63 - Marzo/Aprile 2007SOMMARIO

Login Internet Expert n.45 Mrzio/Aprile 20046

SOMMARIOLOGIN n.45 - Marzo/Aprile 2004

��

��

��

��

��

solutions

8Login Internet Expert n.63 Marzo/Aprile 2007

solutions


Accade ogni giorno di dover scaricare dei file dalla rete, nel nostro caso si tratta spesso di software da installare, e capita spesso di effet-tuare il download da un sito che scegliamo a caso, attraverso un motore di ricerca, o da un mirror, anch’esso scelto a caso o individuato automaticamente dal sito principale del pro-dotto o del progetto (come accade, ad esem-pio per i download da Sourceforge). Tutto ciò che esiste su Internet deve sottostare al motto mediceo “del diman non v’è certezza” e spes-so l’operazione di download, nonostante la determinazione del mirror ottimale da con-tattare, può non andare a buon fine al primo tentativo: il sito prescelto (o il mirror propo-sto dal sito principale) può essere interessato da un malfunzionamento temporaneo (della connessione o dell’hardware), o può non ga-rantire una velocità di connessione ottimale rispetto alla dimensione del file da scaricare o, banalmente, può non memorizzare più il file richiesto (immagino vi sarà successo, ad esempio, con i mirror di Sourceforge). Que-sto tipo di problematiche, interessano non solo gli utenti, ma anche i produttori di sof-tware (o comunque di contenuti digitali) che distribuiscono gli aggiornamenti delle pro-prie applicazioni via Internet (magari usan-do proprio Sourceforge).

Download avventurosi

Un ulteriore “acciacco” durante i download è che la connessione può interrompersi, un classico esempio da “road warrior” soggetto a cadute della linea in una classica connes-

sione UMTS/HSDPA (con velocità tipiche tra i 200 e i 380 Kbit). Un esempio pratico di “accidenti da download” mi è accaduto poco fa, mentre stavo effettuando “via etere” due download contemporanei da Sourceforge: il primo download era di un file di una ventina di Megabyte; per il secondo download, di un file di un paio di MB, avevo scelto un mirror diverso da quello propostomi da Sourcefor-ge, ossia il mirror che stavo utilizzando per il download del primo file. Così, mi sono detto, non rischio di rallentare il primo download. Ovviamente il download del secondo file è terminato prima e senza problemi. A questo punto, si interrompe il collegamento e vengo disconnesso, quando ormai avevo superato il 90% del primo download! Alla successi-va riconnessione ho riavviato il download del primo file, confidando nella funzionali-tà di ripresa del download del browser Web! Ma resto pietrificato nell’accorgermi che il download è ripartito da zero! A quel pun-to, mi sono accorto che stavolta Sourcefor-ge aveva proposto come mirror quello scelto per ultimo nella sessione precedente, ossia quello utilizzato per il secondo download! Per cui, la funzionalità del browser Web di ripresa del download ha fatto cilecca! Non rassegnato, ho abortito il download in corso, ho riselezionato a mano il primo mirror e ho avviato ancora il download. A questo punto, coincidendo nome file e indirizzo del mirror, il browser Web ha ripreso il download dal 90% e dopo un paio di minuti l’operazione si è conclusa proficuamente. Su connessioni lente o comunque con soglie di traffico da non superare, pena una tariffa salata, scherzi del genere possono costar cari.

Metalink è un formato aperto di rappresentazione “aggregata” dei link per il download di file via Internet, utilizzando sia i protocolli standard HTTP e FTP sia protocolli P2P come BitTorrent. Scopriamone l’essenza e le modalità di impiego.

Un download unificato con i metalink

Ü di Natale Fino

solutions


solutions


La soluzione metalink

Quale idea potrebbe rivelarsi più efficace del trasfor-mare le indicazioni per il download in una sorta di meta-indicazioni per un download guidato e consape-vole della mutevolezza della rete? In sintesi, è questa l’utilità dei metalink, un formato aperto e estensibi-le, basato su una rappresentazione conforme a XML 1.0, per facilitare e garantire un proficuo download dei file dalla rete. Il formato dei metalink supporta sia i protocolli standard HTTP e FTP sia i protocolli P2P, tra cui BitTorrent, ed2k e magnet link. Il noccio-lo della soluzione è presto detto: un unico metalink che descriva le informazioni di download da più siti alternativi e con protocolli disparati. E qui ha inizio

il “metalink blues”: chi impone che i link contenuti debbano essere utilizzati in modo mutuamente esclu-sivo? chi impedisce di poter effettuare un download segmentato da più siti e con protocolli diversi? La risposta è quasi immediata: essendo il metalink un formato aperto, basato su XML, la “differenza” fun-zionale la fa il software client, che interpreta e utiliz-za i diversi link contenuti in un metalink. Infatti, un metalink altro non è che un mero contenitore (o me-glio, una sorta di batch di puntatori) che racchiude le URL a più host di destinazione, peraltro accessibili con differenti protocolli. Ma procediamo per ordine, scandagliando gli aspetti sintattici e semantici inerenti ai metalink.

Com’è fatto un metalink

Un metalink è un documento scritto nel dialetto XML denominato MMM (Multi Method Meta-linker) e i file hanno come estensione.metalink. La “magia” di un metalink si apprezza meglio investi-gando la struttura XML delle informazioni che lo compongono. Prima di descrivere gli elementi (tassa-tivi e opzionali) definiti, partiamo da una analisi “by example” della struttura sintattica che è, ovviamente, abbastanza elementare:

I metalink fungono da meta-indicatori per download guidati e efficienti

FIGURA 1 WxDownloadFast un download manager in grado di gestire il formato metalink

solutions


solutions


<file name=”setup-2.4.5.exe”> <language>en-US</language> <os>Windows-x86</os> <verification> <hash type=”md5”>2a619782501e51791f61e120622531f</hash> </verification> <resources> <url type=”http” preference=”100”>http://www.infomedia.it/ downloads/reader/2.4.5/Windows/setup-2.4.5.exe</url> <url type=”http” preference=”100”>http://www.infomedia.it/downloads/reader/2.4.5/Windows/setup-2.4.5.exe</url> </resources> </file> … </files></metalink>

Analizzando questo frammento, scopriamo che il for-mato metalink è in grado di esprimere le differenze dei file da scaricare in termini di lingue di localizza-zione del software, sistemi operativi supportati, hash di verifica del file ed elenco dei siti da cui effettuare il prelievo (delimitati dal tag <resources>).Iniziamo a fare un po’ di chiarezza: piuttosto che ipotizzare che a un unico tag <file name> possano corrispondere più occorrenze dei tag <os>, <verifi-cation> e <resources>, va osservato che la relazione fra il tag <file name> e i tag <language>, <os> e <verification> non è uno a molti, ma uno a uno: il tag <file name> è un mero contenitore per questi tag successivi, che sono nidificati all’interno del tag stesso, che indica un singolo file. Invece, la relazione è uno a molti tra il file e i descrittori <resources>: infatti, un singolo file possiamo prelevarlo da più siti (che siano mirror o meno). E i criteri per prelevare uno stesso file da uno o più siti sono anche moltepli-ci: pertanto, nel tag <resources>, la presenza dell’at-tributo type permette di descrivere il protocollo da utilizzare, mentre l’attributo preference permette di attribuire una preferenza o priorità ai siti da contat-tare

Vediamo, servendoci di un esempio reale, qual è il metalink che descrive le possibilità di download per la versione 2.4.5 del software Abiword:

<?xml version=”1.0” encoding=”utf-8”?><metalink version=”3.0” generator=”Metalink Generator v1.00.0034”

xmlns=”http://www.metalinker.org/”> <files> <file name=”abiword-setup-2.4.5.exe”> <language>en-US</language> <os>Windows-x86</os> <verification> <hash type=”md5”>120622531f51091f5b1e2a619782501e</hash> </verification> <resources> <url type=”http” preference=”100”>http://www.abisource.com/downloads/abiword/2.4.5/Windows/abiword-setup-2.4.5.exe</url> <url type=”http” preference=”100”>http://www.abiword.com/downloads/abiword/2.4.5/Windows/abiword-setup-2.4.5.exe</url>

<?xml version=”1.0” encoding=”utf-8”?><metalink version=”3.0” generator=”Metalink Generator

v1.00.0034” xmlns=”http://www.metalinker.org/”> <files> … </files></metalink>

In pratica, un metalink contiene le informazioni su come scaricare dalla rete una collezioni di file (uno o più file), descrivendo per ciascun file ulteriori detta-gli per il download. In quella che potremmo definire la “collection” files si possono elencare più file (o nel caso degenere un solo file). Pertanto, servendoci di un frammento tratto da un ipotetico esempio, avremo una struttura del tipo:


xmlns=”http://www.metalinker.org/”> <files> <file name=”setup-2.4.5.exe”> … </file> <file name=”setup-2.5.0.exe”> … </file> … </files></metalink>

Ogni file descritto nel metalink è caratterizzato da ulteriori informazioni pertinenti “quel file”: ad oggi (essendo il metalink un formato aperto è suscettibile di qualsiasi estensione) i dati associati al file riguar-dano:

· la URL di destinazione

· il protocollo da utilizzare per il download

· la lingua di localizzazione del file

· il sistema operativo supportato

· l’hash di verifica dell’integrità del file (tipo di codi-fica dell’hash e valore)

· una eventuale priorità di preferenza degli host di de-stinazione da contattare

Un esempio di metalink

In sintesi, un esempio fittizio più completo (e concre-to) di scrittura di un metalink è del tipo:


xmlns=”http://www.metalinker.org/”> <files>

solutions


solutions


</resources> </file> </files></metalink>

Elementi e attributi del formato metalink

Alcuni elementi e alcuni attributi sono obbligatori nella parte header e nella parte body del documen-to MMM, altri elementi e attribuiti sono invece opzionali. Esaminiamo gli elementi e gli attributi principali sia della parte header sia della parte body, rimandando al documento di specifica i dettagli gli ulteriori elementi opzionali.

Elementi dell’header

L’header deve iniziare con un elemento <metalink> che identifica il namespace XML

<metalink version=”3.0” xmlns=”http://www.metalinker.org/”>

Sempre nell’header, sono invece raccomandati i se-guenti attributi: type, origin, generator, pubdate e refreshdate. L’attributo type può assumere solo due valori:

type = “dynamic” | “static”

Con static si indica che il file metalink non viene ag-giornato, mentre dynamic indica che lo è. L’attributo origin indica l’ubicazione originale del file.metalink.

origin = “ubicazione originale del metalink”

Se type è “dynamic” allora questa ubicazione è quel-la in cui si troverà sempre la versione aggiornata del file.

L’attributo generator indica l’applicazione utilizzata

per generare il file.metalink:

generator = “application”

L’attributo pubdate esprime la data e l’ora di pubbli-cazione del file.metalink.

pubdate = “Sun, 15 Apr 2007 09:30:00 GMT”

I valori date-time sono conformi a quanto specifica-to nel documento RFC 822 (ad eccezione che l’anno può essere espresso sia con due sia con quattro ca-ratteri (quattro è preferito). Mentre pubdate è l’indi-catore di quando è avvenuta la prima pubblicazione del.metalink, l’attributo refreshdate indica la data e l’ora in cui è stato aggiornato un file “dinamico”:

refreshdate = “Mon, 16 Apr 2007 10:30:00 GMT”

Riassumendo, l’header assumerà tipicamente questa struttura

<metalink version=”3.0” xmlns=”http://www.metalinker.org/” origin=”http://www.infomedia.it/downloads/abc.exe.metalink”

type=”dynamic” pubdate=”Sun, 15 Apr 2007 09:30:00 GMT” refreshdate=” Mon, 16 Apr 2007 10:30:00 GMT” generator=”manual”>

Elementi del body

Gli elementi obbligatori nel body sono <files> (una sola occorrenza), <file> (una o più occorrenze), <re-sources> (una sola occorrenza) e <url> (una o più occorrenze). In sintesi il body, come abbiamo già vi-sto in precedenza, assumerà una struttura simile a:

<files> <file> <resources> <url> </url> … <url> </url> <resources> </file> … <file> </file></files>

<file> deve avere un attributo name che indica il nome del file:

Un file .metalink de-scrive le informazioni di downalod per più siti e con protocolli disparati

solutions


solutions


<file name=”abc.exe”>.

Per <resources> è disponibile un attributo opzio-nale maxconnections che indica il numero massimo di connessioni contemporanee (“1”, “2”, “3”, ecc.) utilizzabili per il download da quel server. Se ma-xconnections è “1”, difatti non è prevista dal server la possibilità di download segmentato.

L’attributo type di <url> può assumere i seguenti valori

<url> = “ftp” | “ftps” | “http” | “https” | “rsync” | “bittorrent” | “magnet” | “ed2k”

Un secondo attributo opzionale è location che indica, con un classico codice di 2 lettere, l’ubicazione del mirror, ad esempio:

location=”it”

Ulteriore attributo opzionale è preference che espri-me un valore di priorità di scelta per il download, che va 100 (massima preferenza) a 1 (minima preferenza)

Tra gli elementi raccomandati per il body ci limitia-mo a citare quattro sottoelementi di <file>: <iden-

tity> che indica l’identità del “produttore” di un file, <version> che indica la versione e <size>, che esprime la dimensione del file in byte. Ad esempio:

<file name=“abc.exe”> <resources> … </resources> <identity>infomedia.it</identity> <version>2.0</version> <size>4096</size></file>

Verificare l’integrità e l’autenticità

Il quarto sottoelemento di <file> da segnalare è <verification>, e contiene a sua volta gli elementi <hash> e <signature> utilizzati per poter verificare l’integrità del file (hash) e l’autenticità del file (signa-ture). L’hash esprime il valore di checksum per il file (va detto che metalink supporta anche i checksum parziali, per un controllo sugli errori mentre è in cor-so il download del file) ed è in formato esadecimale. I valori possibili di codifica dell’hash si esprimono tra-

FIGURA 2Metalink Editor: produrre file metalink con una comoda GUI

solutions


solutions


mite l’attributo type di <hash>:

type = “md4” | “md5” | “sha1” | “sha256” | “sha384” | “sha512” | “rmd160” | “tiger” | “crc32”

Siccome è ammesso più di un hash per file, un tipico esempio sarà:

<verification> <hash type=”md5”>hash_md5_hex</hash> <hash type=”sha1”>hash_sha1_hex</hash></verification>

Per quanto concerne signature mi limito a evidenziare che è possibile specificare una “firma” PGP in questo modo

<verification> <signature type=”pgp” file=”linux.sign”> -----BEGIN PGP SIGNATURE----- … -----END PGP SIGNATURE----- </signature></verification>

Il ruolo dei client

I client che non interpretano i metalink dovranno po-ter continuare a funzionare anche in presenza di un indirizzo a un documento metalink. Perché ciò av-venga il formato di URL estesa che comprende l’in-formazione sul metalink ha la seguente sintassi:

http://www.infomedia.it/downloads/abc.exe#!metalink3!http://www.infomedia.it/downloads/abc.exe.metalink

Un client ignaro della presenza del metalink trascu-rerà ciò che segue il carattere “#”, interpretandolo come ; ad esempio, basta aprire un browser web e di-gitare (in questo caso su una macchina su cui è in ese-cuzione un web server)

http://localhost/#!metalink3!http://xyz123.com

per rendervi conto che non viene emesso alcun errore e che viene aperta correttamente la pagina di default di localhost. Viceversa, un client che supporta il for-mato metalink analizzerà ciò che segue la stringa

#!metalink3!

interpretando la URL che punta al documento MMM. Quando l’utente clicca su un metalink, il client prele-va il file.metalink e procede ad analizzarne il contenu-to. Se il file metalink è dinamico (type=”dynamic”) il client contatterà la URL di origine per verificare se esiste un file metalink con un refreshdate più recente. Diversamente, il client analizza <resources> e le re-lative <url> per scaricare più segmenti (se è presente maxconnections ed è maggiore di “1”) dai server con maggiore preference. Terminato il download del file, il client utilizza le informazioni <hash> e/o <signa-ture> di <verification> per controllare l’autenticità o l’integrità del file.

Configurazione del Web server

I siti che servono file metalink devono prevedere un tipo MIME per i file.metalink. Pertanto alla configu-razione dei tipi MIME del Web server si dovrà ag-giungere una apposita direttiva. Ad esempio nel caso di Apache 2 si dovrà aggiungere nel file mime.types la seguente direttiva

application/metalink+xml metalink

o inserire nel file httpd.conf una equivalente direttiva AddType. In una versione di Apache meno recente si aggiungerà

filename.tar.gz.metalink

ma ciò, può produrre un errore nei browser. In tal caso, come è riportato nel documento di specifi-ca, è necessario decommentare queste righe nel file httpd.conf:

# AddEncoding x-compress.Z# AddEncoding x-gzip.gz.tgz

Client e editor di metalink

Sono già diversi i siti che mettono a disposizione dei metalink per il downlaod dei propri file (tra cui OpenOffice.org e alcune distribuzioni Linux come OpenSUSE e Ubuntu), e per poterli utilizzare è ne-

Un metalink è un file scritto in un dialet-to XML denominato MMM

solutions


cessario dotarsi di un download manager che sia “sen-sibile” ai metalink. Sono già disponibili una dozzina di client GUI o a riga di comando. Ad esempio, aria2 (http://aria2.sourceforge.net/) è un tool open source a riga di comando disponibile per Windows/Unix/Linux; GetRight (www.getright.com) e SmartFtp (www.smartftp.com) sono applicazioni Windows; wxDownaloadFast (http://dfast.sourceforge.net/) è open source ed è disponibile per Mac, Unix e Win-

dows (Figura 1). Ovviamente sono solo alcuni esem-pi. Per quanto riguarda la “produzione” dei file me-talink, fortunatamente, non è necessario scrivere i documenti MMM a mano con un editor di testo (l’impresa non sarebbe ardua, se non fosse per il cal-colo dei checksum): sono disponibili diversi editor con tanto di GUI che permettono di creare agevol-mente un.metalink completo di ogni informazione. Un esempio di editor è Metalink Editor (Figura 2) scritto in Python dallo svedese Hampus Wessman (http://hampus.vox.nu/metalink). Un elenco esau-stivo e costantemente aggiornato di implementazio-ni client e di editor metalink è disponibile sul sito metalinker.org. Da notare, che chiunque può creare e mantenere dei metalink, non essendo una prero-gativa esclusiva del produttore del file da scaricare; ovviamente le informazioni nel metalink sono più attendibili se sono i produttori dei file stessi o del-le fonti autorevoli a rendere disponibili dei.metalink “accurati”.

In conclusione: estendere un metalink

Analizzando il documento di specifica, mi sono ac-corto che non fa parte del formato attuale dei me-talink un’ulteriore indicazione oraria opzionale che indichi anche quali sono le fasce orarie preferenziali per un determinato mirror o server, ore in cui la velo-cità di media di download potrebbe essere maggiore, rispetto ai momenti di massimo traffico della giorna-ta. Ammesso che ciò sia utile, siccome metalink è un formato aperto, è facile definire un ulteriore attributo per il tag <url> per indicare anche questa informa-

zione. Ad esempio, si può ricorrere ad un attributo besttime per il tag <url> sotto <resources> che indichi, ad esempio in coordinate temporali UTC, proprio questa informazione. Un ipotetico esempio potrebbe essere:

<resources> <url type=”ftp” preference=”100”>ftp:// ftp1.infomedia.it/pub/TestAjax.exe</url>

<url type=”ftp” preference=”100” besttime=”01am- 07am”>ftp://ftp2.infomedia.it/pub/TestAjax.exe</url>

<url type=”ftp” preference=”100” besttime=”06pm- 00am”>ftp://ftp3.infomedia.it/pub/TestAjax.exe</url>

<url type=”http” preference=”100” besttime=”09am-06pm”>http://www.infomedia.it/samples/TestAjax.exe</url>

</resources>

Come potrebbe essere interpretata da un client questa informazione? Andrebbe interpretata come segue:

· a parità di priorità (preference) e di indicazione be-sttime scegliere un server qualsiasi (o più server qual-siasi per un download segmentato);

· se invece l’indicazione besttime varia, preferire il server (o i server) in base all’ora in cui si sta effet-tuando il download.

Nel precedente frammento, ad esempio, tra le ore 1 e le ore 7 del mattino si possono scegliere arbitraria-mente (o effettuare in parallelo download segmenta-ti) i server ftp1 e ftp2, mentre dalle 6 della sera fino alla mezzanotte i server da preferire sono ftp1 e ftp3. Analogamente, dal frammento si evince che nelle ore di ufficio, dalle 8 del mattino alle 6 della sera, è prefe-ribile il download via HTTP e non via FTP. Ovviamente, anche questa ulteriore funzionalità deve essere supportata e gestita dai client e dovrà essere ignorata dai client che non la supportano. Tuttavia, estendere il formato metalink per adattarlo alle pro-prie necessità non è sicuramente un aspetto difficol-toso, ed è possibile implementare una propria esten-sione dello standard (a patto di fornire un client di supporto) senza dover necessariamente attendere o prevedere che l’estensione proposta sia effettivamen-te ratificata nel documento ufficiale (il che, ovvia-mente, sarebbe comunque auspicabile). Se i metalink si diffonderanno sempre più, è molto probabile che diventeranno uno standard, perlomeno de facto.

Riferimenti

Sito ufficiale Metalinker.org – www.metalinker.orgaria2 – http://aria2.sourceforge.net GetRight – http://www.getright.comSmartFtp – http://www.smartftp.comwxDownaloadFast – http://dfast.sourceforge.net/Metalink Editor – http://hampus.vox.nu/metalink

Sono già diversi i siti che mettono a di-sposizione dei meta-link per il downlaod


SOMMARIOLOGIN n.45 - Marzo/Aprile 2004


speciale CLUSTER BEOWULF



Nell’estate del 1994, Thomas Sterling e Don Becker, due ricercatori del CESDIS (Center of Excellence in Space Data and Information Sciences), presso il Goddard Space Flight Center, realizzarono un cluster di personal computer con sistema operati-vo Linux. Alla nuova macchina diedero il nome di Beowulf.Beowulf è l’eroe protagonista di un poema epico del VI secolo, la più antica opera ad oggi pervenuta in lingua inglese, della quale un unico manoscritto è in-credibilmente e ostinatamente sopravvissuto ad in-cendi e svariate altre forme di distruzione. E consa-pevoli che i nomi hanno la loro importanza, Sterling e Becker seppero adeguatamente battezzare un’opera così ben riuscita da trovare ben presto diffusione nei centri di ricerca e nelle imprese private.A stabilire definitivamente il successo del lavoro dei due ricercatori statunitensi, il riconoscimento della comunità di High Performance Computing, la qua-le ha classificato questo tipo di cluster come “classe Beowulf ”, collocando la tecnologia in questione tra le NOW (Network Of Workstation) ed i Supercom-puter.

Linux1 + Linux2 + … + Linuxn = Beowulf

Con il rapido diffondersi dell’informatica per così dire “di massa”, iniziato con gli anni ’80 e prosegui-to nella incessante rincorsa di maggiori prestazioni e affidabilità dell’hardware, la progressiva diminu-zione dei prezzi dovuta alla concorrenza, il nascere ed il proliferare delle iniziative Open Source, anche i più elitari utilizzatori accademici hanno iniziato a considerare seriamente l’impiego di sistemi “off the

shelf ”, ovvero presi dallo scaffale del rivenditore di PC nel negozio all’angolo della strada. Erano i primi anni ’90 e già non si sentiva più parlare di “calcola-tori” o “cervelli” elettronici come, con sprezzo del ridicolo, si era fatto fino a poco tempo prima. Inol-tre i ricercatori si trovavano spesso a sviluppare so-luzioni in proprio, o ad essere eccessivamente legati ad un sistema proprietario. Per questo motivo si era formata e consolidata una certa mentalità: “perché comprare all’esterno ciò che si può costruire all’in-terno?” Se si considera che nel 1994 gli addetti ai lavori già ben conoscessero ed apprezzassero Linux, è naturale concludere che qualcosa di nuovo doveva a quel punto accadere.Il prototipo di Beowulf nasceva su macchine dotate di processori 486DX4 e scheda Ethernet da 10Mbit. Il processore era tuttavia più veloce di quanto una singola Ethernet consentisse, mentre gli switch era-no ancora troppo costosi. Don Becker riscrisse i dri-ver, costruendo una rete “a canali” che permetteva di smistare il traffico in parallelo su più Ethernet.

La Genetic Programming Inc.

La Genetic Programming Inc. è un centro per la ricerca sulla programmazione genetica, finanziato con capitali privati e, manco a dirlo, situato in Ca-lifornia.Gli algoritmi genetici costituiscono una materia piuttosto vasta, sulla quale è stata scritta una quan-tità di letteratura alla quale è consigliabile rivolgersi per approfondimenti. Per una definizione sommaria ed iper-semplificata si può affermare che lo scopo degli algoritmi genetici è quello di pervenire ad una soluzione ottimale a partire da evoluzioni successive

Quando i fondi per la ricerca scarseggiano l’ingegno si affila: un po’ di storia su come la Genetic Programming Inc. realizzò un cluster Beowulf da mille nodi che raggiun-geva prestazioni paragonabili a quelle di un supercomputer, ma a costi molto infe-riori.

Beowulfil Signore dei Cluster

Ü di Nicolò Tambone

SPEC

IALE





di codice iniziale “grezzo” via via selezionato attraverso nu-merose generazioni del codice stesso. In sostanza, la prima ge-nerazione di programmi è pressoché pseudo-casuale, criteri di selezione mutuati direttamente dalla teoria darwiniana prov-vedono a mantenere le caratteristiche che meglio rispondono ai requisiti e attraverso ricombinazioni, mutazione e cancel-lazione di geni, produrre generazioni successive, tendenzial-mente “più adatte”. Alla base della programmazione genetica c’è l’imitazione del-la natura nell’ambito delle teorie darwiniane, per produrre software attraverso il software stesso, ovvero a partire da una descrizione ad alto livello del problema e codice iniziale im-perfetto, si ottiene alla fine delle iterazioni, codice ottimo alla soluzione del problema dato.Tra i vari obiettivi che la società si prefigge, in base a quanto af-fermato dalle pagine del sito www.genetic-programming.com

c’è quello di produrre una “macchina per invenzioni”, magari brevettabili, che a dire il vero, lascia un po’ perplessi e fa pen-sare alle avventure di Archimede Pitagorico nei numeri di To-polino della nostra infanzia.Eppure la serietà delle intenzioni è ampiamente dimostrata dai fatti: nell’estate del 1999 la Genetic Programming ha mes-so in funzione un cluster di Beowulf costituito da mille nodi. Vediamo come è stato realizzato.

Un cluster Beowulf da 1000 nodi realizzato dalla Genetic Programming Inc. La pionieristica società statunitense non era nuova ai cluster: già nel 1995 aveva conseguito importanti risultati utilizzando 64 Power PC a 80Mhz e, in seguito, il parallelismo di 70 mac-chine Alpha.Il cluster Beowulf costituito da mille personal computer dotati di processore Pentium II a 350Mhz, entrò in funzione nel Lu-glio 1999. Ciascuna macchina era dotata di 64Mbyte di RAM, per un totale di 64Gbyte. Ciascuna motherboard Tyan Tiger 100 era in grado di ospitare due CPU e 128 Mbyte di memoria, per cui fisicamente il cluster era costituito da 500 case mini-tower, ognuno carburato dal classico alimentatore switching da 300W. A concludere l’assemblaggio, la scheda di rete Intel PRO/100+ da 100 Mbit. Nessun hard-disk, né monitor, tastie-ra, mouse, tranne che per il server di rete, controllore dei nodi. Il sistema operativo scelto era ovviamente Linux, nella distri-buzione Red Hat che all’epoca si trovava allo stato dell’arte: la versione 6.0.Il server era invece dotato di due CPU Pentium II 350Mhz, 256Mbyte di memoria RAM, hard-disk da 14Gbyte, CD-

FIGURA 1 Notizie sui sistemi cluster: www.linuxhpc.org

Il prototipo di Beowulf nasceva su macchine dotate di processori 486DX4 e scheda Ethernet da 10Mbit





ROM, tastiera, mouse e, ovviamente, monitor.Ogni gruppo di 40 processori, ovvero 20 box fisici, era connes-so ad un HUB da 24 port e 100Mbit, per un totale nel sistema di 25 HUB, ciascuno di essi a sua volta collegato con uno dei due switch Ethernet collegati tra loro e con il server.L’applicazione “vede” i mille processori come se fossero col-legati in una rete toroidale, ciascun processore comunica solo con il server e con i quattro processori adiacenti nel toroide. Con l’eccezione dei soli messaggi di traccia, l’unico tipo di co-municazione tra il processore ed il server è rappresentato dal messaggio di “fine generazione”. Questo contiene il miglio-re “individuo” della corrente generazione, più informazioni statistiche riguardanti l’elaborazione. Il solo tipo di comuni-cazione tra processi riguarda il trasferimento di un piccolo numero di “individui” da un processore ad un altro dei suoi quattro adiacenti. I 1000 processori sono logicamente dislo-cati all’interno di una griglia composta di 25 per 40 gruppi. Ciascun gruppo di 40 processori che condivide un HUB viene dislocato in un rettangolo di 8 per 5 all’interno della griglia più grande. In base al sistema di comunicazione “tra vicini” quasi tutto il traffico di rete in ciascuno dei 40 gruppi è locale all’interno del gruppo.Per quanto riguarda la memoria, circa la metà dei 64Mbyte di RAM di ciascun processore è riservato ad immagazzinare la “popolazione”, il resto è utilizzato dal sistema operativo, dal-l’applicazione e da alcuni buffer utilizzati per il trasferimento di “individui”.Utilizzando il metodo di memorizzazione costituito “one byte per point”, il sistema da 1000 nodi è in grado di memorizzare 10.000 individui di 3000 byte ciascuno, oppure 30.000 indivi-dui da 1000 byte. Se per esempio, un ciclo di valutazione ri-chiede 0,1 secondi, per effettuare la valutazione di 10.000 indi-vidui occorreranno 1000 secondi, quindi ciascuna generazione richiederà un tempo macchina di un quarto d’ora e fino a 96 generazioni potranno essere elaborate in una giornata.La scelta di singoli case standard, ciascuno dotato di un ali-mentatore, pur essendo penalizzante dal punto di vista del-l’occupazione di spazio, si è rivelata efficace sotto il profilo economico. In particolare sarebbe stato poco economico un si-stema di alimentazione centralizzato. Un gruppo di continuità provvede a garantire 15 minuti di autonomia in caso di inter-

ruzione dell’alimentazione di rete.La robustezza del sistema operativo Linux era già stata veri-ficata in passato dalla Genetic Programming, tramite il prece-dente cluster di 70 macchine Alpha. Questo dispositivo aveva funzionato per 14 mesi, 24 ore al giorno, sette giorni a settima-na, registrando in totale solamente tre interruzioni di servizio dovute a motivi diversi.La scelta di non installare hard-disk a bordo dei singoli nodi è stata dettata da ragioni di affidabilità ed agevolata dalla snel-lezza sia di Linux sia del codice applicativo. Il bootstrap del-le singole macchine veniva garantito attraverso un messaggio DHCP inviato dal server a ciascun nodo, che era in grado di accedere direttamente al file system del server attraverso NFS. Il meccanismo di bootstrap del cluster veniva gestito attraver-so il software Beoboot, realizzato dalla società svizzera Rembo Technology. A questo riguardo aggiungeremo una breve nota più avanti.I report di fine generazione prodotti da ciascun nodo venivano memorizzati sull’hard-disk del server, senza tuttavia dare ec-cessive preoccupazioni riguardo l’utilizzo di spazio. Un’ultima caratteristica hardware riguarda il sistema di climatizzazione che, per un numero così elevato di macchine doveva per forza essere notevole: due condizionatori da 25 tonnellate per man-tenere il sistema nei limiti di temperatura.

Conclusioni

A distanza di oltre dieci anni da quando il primo cluster di classe Beowulf vide la luce per la prima volta nei laboratori del Goddard Space Flight Center, decine di migliaia di instal-lazioni “girano” oggi nel mondo al servizio di istituzioni pub-bliche e private. Donald Becker lasciò il prestigioso incarico di ricercatore per fondare la Scyld Computing Corporation (an-che in questo c’è un riferimento letterario perché Scyld, nel poema, è la madre di Beowulf). Dai progetti dedicati al clustering ospitati su Sourceforge, si può avere la conferma dell’interesse tributato a Beowulf dal mondo Open Source. Osservazione quasi ovvia, dal momen-to che Beowulf è imprescindibile da Linux e lo stesso Donald Becker è conosciuto per i suoi contributi nello sviluppo del kernel.

Riferimenti

[1] Genetic-Programming www.genetic-programming.com[2] The Beowulf Project www.beowulf.org[3] Scyld Computing Corporation www.scyld.com[4] Sourceforge www.sourceforge.org

Il cluster Beowulf realizzato dalla Ge-netic Programming Inc costituito da mille nodi entrò in funzione nel Luglio 1999.

Note Biografiche

Nicolò Tambone, Consulente informatico, ha collaborato a di-versi progetti nell’ambito della tecnologia Oracle e dei lin-guaggi Object Oriented.



Il cluster Beowulf

La risoluzione di problemi sempre più complessi nei diversi campi della scienza moderna, dalla Fisica, alla Chimica, alla Matematica, ha richiesto l’utilizzo da parte dei ricercatori di tutto il mondo di calcola-tori sempre più potenti. Ciò ha portato negli ultimi anni a un interesse sempre crescente nello studio dei sistemi di calcolatori in cluster. I sistemi Beowulf rappresentano una tipologia di cluster costituiti da nodi di elaborazione distinti a basso costo, basati ti-picamente su personal computer e connessi da una rete di interconnessione per lo scambio di messaggi tra i nodi. Talvolta è possibile scomporre il problema scientifico di cui si cerca la soluzione in sottopro-blemi distinti ed indipendenti; talvolta è possibile eseguire in parallelo il calcolo suddividendo il lavo-ro tra più unità di elaborazione. In entrambi i casi l’uso di un calcolatore con più processori consente di ridurre i tempi di calcolo, poiché il lavoro può es-sere suddiviso tra differenti CPU. I cluster Beowulf si prestano bene per la risoluzione di entrambe le ti-pologie di problemi e pertanto costituiscono una via alternativa per chi non dispone di finanziamenti tali da potersi permettere l’acquisto di supercomputer dedicati. Nessun progetto può però essere portato a termine senza la copertura finanziaria adeguata. Sul-la base dei fondi disponibili, è possibile comunque effettuare delle scelte con risvolti importanti sull’ar-chitettura hardware della macchina e quindi sulla classe dei problemi trattabili e sulle performance operative del cluster. Passare dall’utilizzo di sempli-ci personal computer connessi da una rete a bassa velocità, a dei server multiprocessore comunicanti con reti ad alta banda e bassa latenza porta ad un incremento dei costi ma anche ad un aumento delle prestazioni su certe applicazioni, ed in generale ad a un allargamento della classe dei problemi risolubili in tempi accettabili [AVRE].

La sala cluster

Il primo problema da affrontare per chi vuole dotarsi di un cluster di calcolo è trovare dei locali adatti ad ospitare il sistema. Il Dipartimento di Matematica dell’Università degli Studi di Milano non dispone-va di locali ampi e disponibili da poter adibire a sala CED. Pertanto, dopo un attento esame delle effettive possibilità, la scelta è ricaduta su un piccolo locale di 28 metri quadrati, situato nel seminterrato del Di-partimento e che fino a quel momento aveva ospitato una camera oscura per lo sviluppo fotografico. La scelta obbligata poneva dei problemi tecnici rile-vanti, sia per le dimensioni della sala sia per il sof-fitto piuttosto basso, e non uniforme per la presenza di volte che rendevano problematico qualunque ap-proccio tradizionale basato sulla realizzazione di un pavimento “galleggiante”. Un altro aspetto da non sottovalutare era il peso che il pavimento avrebbe dovuto sostenere in seguito all’installazione delle macchine del cluster. Il peso medio di un rack si aggira infatti sui 260 Kg. Que-st’ultimo requisito era comunque soddisfatto per la posizione del locale nell’edificio.

Il sistema

Il sistema di calcolo, che costituisce la soluzione clu-ster adottata, risulta costituito da:

· 36 nodi di calcolo a doppio processore (di cui 26 nodi con processori Xeon a 2.4 GHz e 10 con proces-sori a 2,8 GHz);· una SAN (Storage Area Network) con 600 GB di spazio disco in Raid 5 accessibile mediante 2 nodi storage;· una libreria di backup SDLT contenente 16 slot.

Il Dipartimento di Matematica dell’Università degli Studi di Milano per far fron-te alle esigenze dei propri ricercatori e scienziati si è dotato di un cluster Beowulf basato su Linux per il calcolo scientifico ad alte prestazioni. L’articolo presenta una panoramica del sistema con particolare riguardo alle problematiche tecni-che di progettazione e realizzazione.

Realizzazione di un cluster di calcolo Beowulf

Ü di Alessio Alessi

SPEC

IALE





Ogni nodo di calcolo è dotato sia di un un’interfaccia Ethernet sia Myrinet. Inoltre, ogni nodo dispone di un disco SCSI per l’istallazione del sistema operativo Linux, mentre un’area con-divisa è disponibile via NFS sul nodo “master” per il softwa-re condiviso. Per quanto concerne il software utilizzato, pos-siamo citare: Linux RedHat, PGI-Compiler, Librerie BLAS, LAPACK, ATLAS, PETSc 7, MPICH, Magma, Gromacs, Singular-A, Time Navigator Atempo.

Nella Figura 1 è riportato il file FSTAB relativo ai 36 nodi di calcolo.

/usr/local

è l’area condivisa sul nodo master, mentre il file system GPFS è indicato da

/dev/gpfs0

e

/dev/gpfs1

Le home degli utenti sono accessibili utilizzando il file system IBM GPFS su rete Myrinet [1] così come uno spazio scratch di 30 GB. Gli utenti accedono al sistema mediante il protocol-lo ssh e sottopongono i loro job utilizzando PBS [2] e MAUI [3]. Ogni nodo di calcolo, alto 1U, viene impilato uno sull’al-tro come è mostrato nella Figura 2. Il peso complessivo di un rack a pieno carico si aggira intorno ai 300 Kg ed occupa uno spazio di 0.7 metri quadri per un’altezza di 2.02 metri. Circa 70 cm vengono lasciati liberi nella parte posteriore del rack per le operazioni di manutenzione e per la circolazione dell’aria for-zata, grazie ad un sistema di ventole.

Energia elettrica e gruppo di continuità

Per fornire alla sala l’alimentazione elettrica corretta è neces-sario progettare un impianto di distribuzione che soddisfi i requisiti di sicurezza e di espandibilità nel tempo. L’impian-to viene scelto per assicurare la continuità dell’alimentazione e l’eliminazione dei disturbi elettrici che potrebbero influire sul corretto funzionamento delle macchine. La linea elettrica, proveniente dalla cabina di distribuzione, deve assicurare una

FIGURA 1 Fstab dei nodi di calcolo

FIGURA 2 Il cluster IBM 1350FIGURA 3 Rack della sala cluster con il gruppo di continuità in primo piano





potenza adeguata in termini di tensione e di intensità di cor-rente, per evitare sovraccarichi.

La soluzione adottata rende minimo l’impianto elettrico perché connette direttamente al gruppo di continuità tut-te le PDU (Power Distribution Unit) dei rack, riducendo drasticamente le prese di alimentazione. I primi due rack del-la Figura 3 mostrano le componenti del gruppo di continuità. In particolare, nel primo sono inseriti i moduli di potenza (3 moduli da 10 KW ciascuno, sostituibili a caldo) ed il gruppo batterie, in grado di fornire energia per oltre 20 minuti in as-senza di corrente. Il secondo rack presenta gli interruttori di alimentazione delle PDU ed il sistema di bypass. I cavi di ali-mentazione dei rack del cluster scorrono su una canalizzazio-ne posta al di sopra dei rack stessi, minimizzando l’impianto elettrico della sala.

Il sistema di condizionamento

Il sistema di condizionamento deve essere in grado di mante-nere una temperatura compresa tra 10 e 32 °C. Anche l’umi-dità dell’aria non deve superare l’80% e deve essere superiore all’8%. I condizionatori utilizzati sono del tipo ad espansione diretta e sono posizionati sulla parete della sala opposta al clu-ster (Figura 4). Sono in bilanciamento di carico ed alternano il loro funzionamento in condizioni di basso carico. La sala è predisposta per ospitare un terzo condizionatore, qualora se ne dovesse presentare la necessità. Per monitorare la temperatura e l’umidità della sala all’interno dei rack è posto un sensore ter-mico. Il sensore viene monitorato dall’UPS. Se viene superata la soglia programmata di temperatura o di umidità, il gruppo di continuità provvede ad inviare un allarme via SMS sul te-lefonino dell’amministratore e via posta elettronica al servizio di assistenza tecnica. La sonda controlla la temperatura critica (32 °C) al di sopra della quale il sistema viene arrestato. L’aria calda generata dai rack viene rimossa da un sistema di aspirazione costituito da due coppie di ventole, dimensionate in modo che la temperatura esterna rilevata dalla sonda non superi una soglia prefissata in condizioni di alto carico delle CPU (Figura 5). Una stima effettuata porta a 41000 BTU il carico da smaltire per un cluster composto da 32 nodi. Ogni coppia opera in modalità attiva/passiva. Una griglia nel con-trosoffitto consente all’aria calda rimossa di immettersi nel canale di ritorno verso i condizionatori d’aria.

Il cablaggio

Per poter connettere la sala al resto della rete LAN diparti-mentale è stato realizzato un collegamento in fibre ottiche con il centro distribuzione dati dell’edificio. In questo modo, il cluster è accessibile agli utenti dall’esterno mediante acces-so sicuro SSH. I nodi del cluster sono connessi tra loro me-diante una rete Ethernet suddivisa in due VLAN distinte per l’istallazione e la gestione dei nodi e dalla rete Myrinet per lo scambio di messaggi tra i nodi (Figura 6). Quest’ultima viene utilizzata anche per l’accesso I/O ai nodi storage della SAN (Figura 7) sfruttando il file system GPFS [4].

Il sistema di monitoraggio

Il cluster IBM 1350 viene fornito con il software per la gestio-ne CSM [5]. Tuttavia, per monitorare da remoto lo stato della macchina in modo elegante e comprensibile anche da parte degli utenti è stato configurato il Ganglia toolkit [6]. In tal modo, è possibile verificare l’uso delle risorse via Web. Nella Figura 8 è visibile una delle pagine di monitoraggio. Viene presentata una visione d’insieme del cluster con il numero dei processori, il carico, la RAM e l’area di Swap utilizzata.

I progetti in corso

Sfruttando le potenzialità del cluster, sono stati avviati diversi progetti di ricerca. Sono in corso simulazioni di Fisica basate sul metodo Montecarlo, di Astrofisica riguardanti le stelle a neutroni e di Chimica Computazionale e di Elettrocardiolo-gia Computazionale. Ad esempio, è stato simulato un modello elettrico del cuore umano ed un modello che descrive le inte-razioni biochimiche durante la formazione dei vasi sanguigni. Maggiori dettagli sui progetti in corso sono disponibili all’in-dirizzo [8].

Le prestazioni ottenute utilizzando il benchmark HPL hanno mostrato un valore di 123 GFLOP/sec utilizzando 26 nodi di calcolo a 2,4Ghz e di 163,5 GFLOP/sec utilizzando 70 proces-sori. Questi valori sono stati confrontati con quelli ottenuti in passato con tipologie di macchine simili, ma con una minore

FIGURA 4 Un gruppo di condizionatori FIGURA 5 Coppia di ventole posizionatesopra i rack per asportare il calore (in fault tolerance)





FIGURA 6 Switch ad alta banda e bassa latenza Myrinet per la comunicazione tra processi

FIGURA 7 Particolare della SAN con i nodi storage e la libreria di backup

FIGURA 8 Ganglia Toolkit : Cluster Load

frequenza di clock, e si è notato un notevole miglioramento di prestazioni (74.4 GFlop/sec su un cluster 64-Way 128 pro-cessori) [JMDR]. Nel tempo verrà effettuato un upgrade della macchina per adeguarla via via alle crescenti richieste di cal-colo.

Monitoraggio delle temperature

Per salvaguardare il corretto funzionamento delle macchine è stato predisposto un sistema di controllo delle temperature dei nodi. Configurando i condizionatori installati nella sala alla

temperatura di 18-20 °C è possibile mantenere la temperatu-ra delle CPU entro l’intervallo corretto di funzionamento in condizioni di alto carico. Il confronto nelle due condizioni di attività e di riposo è mostrato in Figura 9. Per migliorare l’effi-cienza del sistema di raffreddamento ed evitare l’accumulo di calore prodotto, è stato realizzato un sistema di aspirazione e di canalizzazione dell’aria calda che fuoriesce posteriormente dai rack. Mantenere il sistema nelle condizioni ideali di fun-zionamento risulta fondamentale per prolungare il tempo di vita dell’hardware.

Ogni nodo di calco-lo è dotato sia di un un’interfaccia Ether-net sia Myrinet





Publishing, June 2002.

[STER] T.Sterling, “ Beowulf Cluster Computing with Li-nux”, Cambridge, MIT Press,2002.

[BUUY] R. Buyya, “High Performance Cluster Computing”: Architectures and Systems, Volume 1, New Jersey, Prentice Hall PTR,1999.

[RBUUY] R. Buyya, “Programming and Applications”: Ar-chitectures and Systems, Volume 2, New Jersey, Prentice Hall PTR,1999.

[RBRO] R. Brown, “Features Beowulf Infrastructure”, Linux Magazine June 2003 (http://www.linux-mag.com)

[TSRE03] T. Sterling, “Features Beowulf Breakthroughs”,Linux Magazine, June 2003 (http://www.linux-mag.com)

[IBM0] IBM, “Linux Clustering con CSM e GPFS” Redbooks SG24-6601- 02,December 2003

[IBM1] IBM, “Linux HPC Cluster Installation” Redbooks SG24-6041- 00, June 2001

[JMDR] J. M. Dressler, N. Kandadai, “Performance of Scienti-fic Applications on Linux Clusters”, IBM Performance Tech-nical Report, November, 2001

[Dell] Dell Power Solutions, “Building a High Performance Computing Environment” Issue 4 2001 Enterprise System Group, Dell Computer Corporation, One Dell Way, Round Rock, Texas.

FIGURA 9 Confronto delle temperature delle CPU nelle differenti condizioni di carico e riposo

Riferimenti

[1] Interconnessione scalabile per cluster prodotta da Myri-com (www.myricom.com)[2] Portable Batch System (www.openpbs.org) [3] Maui Scheduler (www.supercluster.org) [4] GPFS (General Parallel File System), www.ibm.com/systems/clusters/software/gpfs.html[5] CSM (Cluster System Management), www.ibm.com/systems/clusters/software/csm.html [6] Ganglia, sistema di monitoraggio distribuito per sistemi HPC (http://ganglia.sourceforge.net/) [7] PETSc (http://www.mcs.anl.gov/petsc)[8] Progetti in corso sul cluster (http://cluster.mat.unimi.it)

Bibliografia

[AVRE] A. Vrenios, “Linux Cluster Computing”, USA, Sams

Il monitoraggio da remoto dello stato della macchina avvie-ne tramite il toolkit Ganglia





Quando la Scienza dell’Informazione iniziò a muo-vere i propri primi timidi passi nell’arena dei pro-dotti commerciali, lasciando i laboratori asettici del-le Università, il prodotto finito che venne alla luce era pesante, monolitico e difficile da gestire. Tutta-via, l’idea di consentire ad una macchina dotata di controlli di ridondanza e poco incline alla stanchez-za fisica ebbe immediatamente effetto nell’immagi-nario collettivo; quando vennero distribuiti i primi mainframe si assistette ad un radicale ed irreversi-bile cambio di prospettiva nella gestione del lavoro aziendale. Tutti oramai siamo abituati all’idea di un notebook sulla scrivania; il collegamento in rete, Internet e lo sviluppo di architetture distribuite ne hanno reso flessibile ed intuitivo l’utilizzo. Il passo successivo è stato una ulteriore sfida progettuale, una “idea nuova” dai cui sviluppi ha preso piede un sistema completamente diverso di intendere l’Infor-matica.

Cos’è un cluster?

L’idea di base nasce come spesso accade, in modo tranquillo, con l’apparizione dei primi mainframe biprocessori. Sull’adagio secondo il quale “due è me-glio di uno”, vennero realizzate architetture hard-ware che prevedevano un canale ad alta velocità per il passaggio di messaggi tra sistemi diversi; ad esso venne ovviamente associata un’apposita funzione di bilanciamento che consentisse una corretta distri-buzione dei carichi tra le due CPU (allora enormi e dotate di complessi sistemi di raffreddamento ad ac-qua). In seguito la Digital Equipment produsse siste-mi altamente scalabili ed interconnessi, dimostran-do che una serie di minicomputer opportunamente

gestiti potevano raggiungere e superare la potenza di calcolo e l’efficienza transazionale di mainframe ben più costosi.Un cluster è quindi paragonabile ad un agglome-rato di unità di elaborazione che, pur mantenendo la propria identità hardware e software, interagisce tra i propri componenti utilizzando particolari di-spositivi di comunicazione che sovrintendono al completamento dei task nell’ambito di una sorta di metasistema; se la descrizione appare un po’ farragi-nosa, una serie di esempi potrà sicuramente aiutare a chiarire il concetto.Ciò che differenzia una batteria di telefoni colle-gati fisicamente tra loro ad una centrale telefonica elettronica con selezione automatica dei numeri disponibili è ovviamente lo strato software per la gestione; tuttavia non si tratta di gestire l’unità “te-lefono”, perfettamente in grado di lavorare da sola, né di programmare il lavoro della centrale in sé, che possiede di fabbrica le istruzioni necessarie per met-tere in contatto ciascun apparecchio con gli altri: la differenza è fatta invece dal sistema di scambio mes-saggi tra le unità di comunicazione e la centrale, tra-sparente al lavoro hardware dell’apparecchio telefo-nico ed a quello della centrale, ma tale da coordinare ciascun elemento del sistema con gli altri. Allo stes-so modo un cluster di PC che disponga del proprio hardware e del proprio sistema operativo e di rete, può “rispondere” ad una serie di messaggi particola-ri che, coordinando le CPU e le risorse meno appe-santite, consentono alle macchine in rete di collabo-rare per il raggiungimento di un fine unico.Esistono fondamentalmente due tipologie di cluster: sistemi per il bilanciamento delle prestazioni di rete (risorse esterne al PC) e sistemi per il bilanciamento delle prestazioni della CPU (risorse interne al PC);

Un’introduzione storica alla caratteristiche distintive di gruppi di computer che coope-rano tra loro nell’ambito di un sistema Li-nux, analizzando pregi e difetti.

Architetture cluster con Linux

Ü di Luigi Morelli

SPEC

IALE





vediamo rapidamente in cosa consistono e per quali caratteri-stiche si differenziano.

Cluster per il bilanciamento delle prestazioni di reteL’analisi della risposta di un sistema basato sulle transazioni

risulta il punto cruciale per l’ottimizzazione delle sue presta-zioni: troppo spesso infatti ci si imbatte in un Web server o un database che sulla carta promette straordinaria efficienza ma in pratica risulta appesantito da un carico eccessivo o gestito in modo maldestro. Il primo rimedio al quale si pensa per al-leggerire il carico consiste nell’affiancare un nuovo server al vecchio per ridistribuire il carico di lavoro, ma a questo pun-to sorgono numerosi problemi: sovente occorre mantenere un unico sistema di indirizzamento, ed è impossibile suddividere i dati logici su due macchine. Occorre pertanto trovare un si-stema che, lavorando su entrambe, ne gestisca il carico senza però creare un overhead che rallenterebbe ulteriormente la risposta del sistema alle richieste esterne; in altre parole, il metasistema al quale accennavamo prima, svincolato dalla ge-stione squisitamente fisica dei dati ma in grado di indirizzare ciascun utente sul server di volta in volta più scarico, bilan-ciandone le risorse. Un sistema del genere consentirà oltre al load-balancing anche un’affidabilità avanzata, la ridondanza dei dati, il supporto contro il fail-over di un server e dei suoi servizi di rete e permetterà l’aggiunta di nuove macchine (clu-ster, appunto) ed in definitiva la crescita di un sistema di ri-sposta altamente modulare, scalable come si dice in inglese. Linux dispone di diversi sistemi per la gestione di network clusters [1]; un kernel efficiente in grado di sfruttare comple-tamente le risorse hardware del server, unitamente ad un siste-ma di controllo efficace, garantisce l’assenza di fastidiosi colli di bottiglia nella progettazione di un cluster che gestisca al meglio gli accessi concorrenti di migliaia di client remoti.

FIGURA 1 Rappresentazione schematica di un sistema gestito sotto PVM.

Esistono fonda-mentalmente due tipologie di cluster: sistemi per il bilan-ciamento delle pre-stazioni di rete e sistemi per il bilan-ciamento delle pre-stazioni della CPU





Cluster per il calcolo distribuito

Beowulf è il nome di un poema epico composto di circa 3200 versi, risultante dalla confluenza di numerose saghe germani-che che i Sassoni tramandarono inizialmente in modo orale, e che vennero raccolte intorno al 750 d.C. In esso si narrano le avventure dell’eroe Beowulf contro il terribile mostro Grendel e contro draghi di fuoco, e mostrano come lo spirito combat-tivo dei Sassoni riesca a cementare razze spesso diverse, ma legate tutte da un comune senso tribale, dall’amore per il mare e dal disprezzo per il pericolo.Ciò spiega come mai si sia scelto proprio questo nome per in-dicare un’architettura di computer in cui le risorse di diversi sistemi, ciascuna con il proprio sistema operativo e la propria identità, vengano riunite nel momento del bisogno a formare un sistema di potenza decisamente elevata, in grado di esegui-re assieme missioni “epiche”. Un Beowulf Cluster di una doz-zina di macchine Linux faceva bella mostra di sé diversi anni or sono ad una fiera dell’Informatica: lo scopo era quello di utilizzare la propria potenza per forzare il sistema di accesso di un server NT. Ovviamente lo scopo venne raggiunto in meno di venti minuti di lavoro…Ma come è possibile coordinare architetture diverse e convin-cerle a lavorare per un fine unico? Occorrono programmi o compilatori particolari, o è sufficiente un middleware in grado di gestire con efficienza il passaggio di messaggi tra le diverse CPU? Sarà esattamente questo l’argomento del prossimo pa-ragrafo.

Ambiente di programmazione in cluster

Una delle maggiori difficoltà nello sviluppo di sistemi infor-mativi basati su computer multiprocessore, è rappresentata dalla complessità nella stesura di programmi in grado di av-vantaggiarsi in modo efficace dell’architettura cluster. Infat-ti, occorre sottolineare l’ambiente di sviluppo completamente nuovo, nel quale si deve specificare non solo la temporizzazio-ne delle istruzioni, ma anche la località. È per questa ragione che sono nate librerie come PVM ed MPI: tali pacchetti di comunicazione dichiarano esplicitamente la struttura di con-

versazione tra i nodi del cluster, mentre gli schemi orientati agli oggetti si concentrano sulla trasparenza, liberando il pro-grammatore dalla descrizione esplicita dell’algoritmo di paral-lelismo.È stato osservato che per realizzare un’architettura basata su cluster era necessario sviluppare un framework per la pro-grammazione parallela che operasse su calcolo distribuito ete-rogeneo; benché esistano centinaia di linguaggi che suppor-tano istruzioni orientate al parallelismo hardware, ciascuno è stato progettato per una architettura specifica, rifiutandosi il più delle volte di compilare su di un architettura cluster. I tempi di latenza di un cluster sono infatti decisamente su-periori rispetto a quelli di un computer parallelo, mentre il throughput di comunicazione risulta inferiore; ecco perché è necessario utilizzare linguaggi di programmazione il cui ob-biettivo principale è di limitare al massimo l’I/O, aspetto inve-ce trascurabile nell’ambito dei computer paralleli che possono usufruire di memoria condivisa. Sono proprio queste conside-razioni di distribuzione dei dati e di località delle informazio-ni che risultano un punto cardine per il successo di un qual-siasi ambiente di programmazione cluster, e che al contempo eliminano dalla scena la maggior parte dei linguaggi orientati alla programmazione parallela. Passiamo ad analizzare in det-taglio i sistemi di architettura cluster più efficaci e diffusi oggi a disposizione del programmatore

PVM

Lo sviluppo di PVM, acronimo di Parallel Virtual Machine, è iniziato nel 1989 presso l’Oak Ridge National Laboratory, quando Vaidy Sunderam e Al Geist presentarono i propri stu-di sul calcolo distribuito eterogeneo. PVM nacque dalla neces-sità di un framework per tale progetto: si tratta di un pacchet-to che consente di accomunare macchine diverse che vanno dal laptop con Windows 95 ai server paralleli che girano sotto Unix e si affacciano sulla medesima rete, facendoli apparire come un sistema di calcolo unico. In altre parole, viene reso disponibile l’accesso ad un unico massiccio supercomputer attraverso la connessione di molteplici unità distinte, limi-tate esclusivamente dalla banda consentita da linee di comu-nicazione ad alta capacità. Centinaia di siti utilizzano oggi le capacità di PVM per risolvere importanti problemi legati alla scienza, all’industria ed alla medicina: con decine di migliaia di utenti sparsi sul Web, PVM è divenuto lo standard de facto del calcolo distribuito nel mondo.Ed ecco i principi sui quali si basa PVM:

- Host pool configurabile dall’utente. I compiti di calcolo del-l’applicazione vengono eseguiti su di un insieme di macchine selezionate dall’utente per una data esecuzione del progetto PVM; è possibile aggiungere e togliere macchine al progetto durante l’esecuzione.

- Accesso trasparente all’hardware. È possibile avvantaggiarsi di determinate caratteristiche hardware nel pool indirizzando verso queste unità dei task specifici, oppure utilizzando un de-terminato ambiente hardware come una serie di elementi di elaborazione virtuale.

- Calcolo basato sul processo. Il task è l’unità base di paralle-lismo per PVM, e rappresenta un thread di controllo sequen-

Centinaia di siti uti-lizzano oggi le ca-pacità di PVM per risolvere importanti problemi legati alla scienza, all’industria ed alla medicina





ziale indipendente che interviene sia nel calcolo sia durante la comunicazione.

- Modello di passaggio dei messaggi esplicito. Questo insieme di task cooperano scambiandosi esplicitamente dei messaggi. Non c’è alcuna restrizione imposta dal linguaggio sulla misura dei messaggi.

-Supporto alla eterogeneità. Il sistema PVM supporta l’etero-geneità in termini di macchina, rete ed applicazioni. Relativa-mente al passaggio di messaggi, PVM consente la trasmissione di messaggi contenenti più di un datatype tra macchine con differenti standard di rappresentazione dei dati.- Supporto multiprocessore. PVM utilizza le caratteristiche native di message-passing sui sistemi multiprocessore per av-vantaggiarsi dell’hardware sottostante.

Il sistema PVM si compone di due parti: la prima è un daemon che risiede su ciascun computer della macchina virtuale, viene definito spesso pvmd e ed è progettato in modo che qualsiasi utente possa installarlo sulla propria macchina. Una macchi-na virtuale viene quindi creata lanciando PVM, dopodiché è possibile eseguire programmi sotto PVM. Ciascun utente ha la possibilità di eseguire contemporaneamente differenti ap-plicazioni PVM (Figura 1).La seconda parte del sistema è costituita da una libreria di routine di interfaccia costituta da un repertorio di primitive necessarie per la cooperazione tra i task di una stessa applica-zione. La libreria, infatti, offre le funzioni per il passaggio di messaggi, l’esecuzione dei processi, la coordinazione tra i task e la modifica della macchina virtuale.PVM rappresenta oramai uno standard, e su tale sistema si basano una serie di estensioni che vanno da un front end gra-fico (XPVM) ad una libreria che consente lo scambio – oltre

ai messaggi – di oggetti C++ (CPPVM e PVM++) ed un in-sieme di estensioni per allargare PVM al mondo Java (jPVM), oltre a versioni ottimizzate per sistemi specifici (PerlPVM, PyPVM, HP-PVM).

MPI

Al contrario di PVM, sviluppato nell’ambito di un progetto di ricerca, MPI è venuto alla luce grazie allo sforzo di un comi-tato di una quarantina di esperti di calcolo ad alte prestazioni provenienti da Industria e Ricerca durante una serie di mee-ting tenutisi tra il 1993 ed il 1994. Lo scopo principe di MPI è stato quello di ridurre il numero sempre crescente di API ma-chine-dependent progettate dai venditori di macchine MPP (Massive Parallel Processor). MPI, infatti, rappresentava una specifica di message-passing indipendente dalla macchina, alla quale i produttori di MPP avrebbero dovuto attenersi per consentire la stesura di applicazioni parallele portabili. Ovvia-mente, la necessità di alte prestazioni da parte dei distributo-ri MPP rese l’efficienza una delle basi sulla quale la specifica avrebbe dovuto poggiare. Il progetto riuscì alla perfezione, e le API MPI divennero uno standard tra i produttori di siste-mi MPP.A causa degli scopi del progetto, una implementazione MPI su di una macchina MPP risulterà sempre più efficiente di una basata su PVM. MPI-1 esponeva le seguenti caratteristiche:

- Un nutrito insieme di routine di comunicazione punto-pun-to

- Una serie di routine dedicate alla collective communication, orientate alla comunicazione tra gruppi di processi.

RIQUADRO 1

Differenze tra MPI e PVM

PVM implementa completamente il controllo di processo, ossia la capacità di lanciare e fermare task, di capire quale task sia attivo e se possibile dove è attivo. MPI-1, invece, non ha modo di lan-ciare un programma parallelo. Per contro, MPI-2 dovrebbe poterlo fare.

La natura dinamica di PVM gli permette di occuparsi della gestione delle risorse; le risorse di cal-colo, o “host”, possono essere aggiunte o tolte a volontà sia da una sorta di console di sistema sia dall’applicazione utente. MPI, invece, non è altrettanto dinamico, per favorire l’efficienza.

In MPI un gruppo di task può essere sistemato in una particolare struttura topologica di intercon-nessione. La topologia di comunicazione dei task, infatti, può essere mappata sullo strato di rete fisica prescelto, aumentando così la velocità di trasmissione dei messaggi. PVM non supporta que-sta astrazione.

PVM gestisce uno schema di notifica dell’errore sotto il controllo dell’utente. Alcuni task possono essere registrati tramite PVM per ricevere un alert qualora lo stato della macchina virtuale venisse modificato; tale notifica giunge sotto forma di messaggi che contengono informazioni sull’evento. L’attuale standard MPI non include meccanismi di fault-tolerance, benché la specifica MPI-2 pre-veda una implementazione simile a quella definita in PVM.

Una delle maggiori differenze tra i due ambienti è nel comunicatore MPI. Il comunicatore può esse-re rappresentato come un link tra un contesto di comunicazione e un gruppo di processi; la presen-za di un contesto di comunicazione consente l’uso di librerie e pacchetti scritte in message-passing system per mezzo delle quali ogni messaggio di comunicazione è protetto e filtrato all’utente.





Note Biografiche

Luigi Morelli, è un consulente informatico. Si occupa di system & network management, ma da sempre cerca di coniugare il lato ludico di Matematica e Scienza dell’Informazione.

- Un contesto di comunicazione che offre un supporto per la produzione di librerie sicure per il software parallelo.

- La possibilità di specificare topologie di comunicazione.

- La possibilità di creare tipi di dato derivati che descrivano messaggi di dati non contigui.

A causa delle istanze di portabilità sulla rete, nel 1995 il co-mitato MPI iniziò una nuova serie di incontri per progettare MPI-2, estendendo il supporto a:

- Funzioni MPI SPAWN per lanciare sia processi MPI sia pro-cessi non-MPI.

- Funzioni di comunicazione one-sided come get e put.

- Funzioni non bloccanti di comunicazione collettiva.

- Primi legami con C++ per la struttura del linguaggio.

Conclusioni

È meglio dunque PVM o MPI? Forse nessuna delle due… È infatti la possibilità di combinare le potenzialità di entrambi i sistemi ad offrire le caratteristiche di macchina virtuale di PVM e le caratteristiche di message-passing avanzato di MPI;

PVM può accedere al controllo di risorse della macchina vir-tuale creando nel contempo un sistema fault-tolerant, mentre il sistema di comunicazione in rete di PVM è stato utilizzato per trasferire dati tra le implementazioni MPI di produttori differenti, consentendo così l’interoperabilità in una macchi-na virtuale più ampia. Per installare le librerie parallele PVM e MPI è sufficiente installare Linux. Ad esempio, PVM e LAM/MPI sono preinstallate con Fedora Core Linux (se si esegue l’installazione personalizzata basta selezionare i pacchetti di calcolo scientifico).

Bibliografia

[1] S.Needham & T.Hansen, “Cluster Programming Environ-ments”, Monash University, Melbourne[2] http://www.netlib.org/pvm[3] http://www-unix.mcs.anl.gov/mpi/index.html[4] http://www.epm.ornl.gov/pvm/PVMvsMPI.ps

JAVA Journal

n.3 - marzo/aprile 200712

speciale Java Micro Edition JAVA Journal

n.3 - marzo/aprile 2007 13

Java Micro Edition speciale

ECHO2

È probabilmente quanto di più completo si possa tro-vare oggigiorno in Java su AJAX. ECHO2 è un web framework che dispone di una libreria molto completa di componenti per realizzare applicazioni con frontend molto ricchi e complessi. ECHO2 dispone anche di un ambiente di sviluppo visuale avanzato, in grado di aiutare notevolmente in fase di sviluppo. Le librerie di ECHO2 sono disponibili con licenze lgpl o mpl, mentre l’ambiente di sviluppo è proprietario. Per utilizzare ECHO2 non è indispensabile utilizzare l’ambiente vi-suale anche se si perdono molti dei benefici della piat-taforma, come i wizard e i suggerimenti.Gli esempi presenti sul sito del produttore (http://demo.nextapp.com) descrivono le potenzialità del fra-mework meglio di qualunque descrizione testuale.

Firebug

Uno dei problemi di chi sviluppa con AJAX è monitorare il dialogo client/server per individuare facilmente dove possono annidarsi eventuali problemi. L’ultimo stru-mento che consiglio è Firebug. Si tratta di un plugin per Firefox in grado di intercettare, tra le altre cose, l’uso del oggetto XHR, mostrando sia la chiamata che la risposta.

Conclusioni

Sviluppare con la tecnica AJAX consente di realizzare vere e proprie applicazioni client. Il browser non mostra più semplici pagine ma potenzialmente una singola pagina che continua ad aggiornarsi dinamicamente in funzione delle interazioni con l’utente. Per capire a fondo le poten-zialità basta vedere Gmail di Google, con il suo sistema di chat o il nuovo frontend per la posta di Yahoo!. AJAX comporta una serie di conseguenze, che impongono un attento studio prima di essere utilizzato indistintamente. Le prime considerazioni sono sull’accessibilità. Una applica-zione AJAX sarà difficilmente accessibile da altri sistemi, in particolare dai motori di indicizzazione. Siti per i quali è fon-damentale l’indicizzazione o per i quali è previsto l’accesso da altre piattaforme non dovrebbero fare uso di Javascript e quindi di AJAX. Un’altra considerazione è sulla sicurezza: esporre servizi web è come mostrare il fianco al nemico. Oc-corre utilizzare tutti gli accorgimenti per evitare che altri ne abusino (ad esempio con un blocco su referrer) e per i dati sensibili occorre sempre proteggere l’accesso e fornire i dati solo in HTTPS. Sono accorgimenti comuni ma spesso trascu-rati, per la percezione errata che nessuno conosce il servizio e quindi nessuno lo chiamerà direttamente.

Note Biografiche

Luigi Zanderighi è Ingegnere del software ed è esperto nella pro-gettazione di architetture distribuite e di software Java.

Dada S.p.A. è una Internet Company quotata alla Borsa di Milano e presente sui principali mercati internazionali, leader nel settore dei servizi Community ed Entertainment (Internet & Mobile).

Il nostro è un mondo con una forte componente internazionale, in cui ogni dipendente e collaboratore si identifica con l’Azienda, un mondo dove la passione per le nuove tecnologie contribuisce al successo dell’Azienda, oltre che alla crescita personale e professionale.Siamo convinti che dal confronto delle idee nascano le soluzioni più brillanti, che il team-working sia un valore condiviso ed una realtà quotidiana radicata nel piacere di rapportarsi con gli altri.

A seguito della forte crescita del nostro business ricerchiamo

Sviluppatori per il prodotto Dada.net (www.dada.net)Il candidato ideale ha maturato una significativa esperienza di sviluppo software per il WEB.

Requisiti:o Formazione in ambito informatico o elettronicoo Buona conoscenza della lingua ingleseo Comprovata conoscenza di uno o più linguaggi di programmazione:

• PHP• Perl• J2ME• HTML, CSS e Javascript • Javascript e Actionscript

Titoli preferenziali:Passione per il mondo Internet, le nuove tecnologie, l’integrazione tra sistemi, lo studio e la realizzazione di community dedicate al mondo consumer dell’entertainment (web e mobile).Completano il profilo autonomia e spirito d’iniziativa, orientamento ai risultati e motivazione ad inserirsi in un contesto giovane e molto dinamico.

Sede di lavoro: Firenze.Se siete interessati ad incontrarci, aspettiamo le vostre candidature (Rif.: DEV07) all’indirizzo [email protected] (autorizzando il tratta-mento dei dati personali ai sensi del D.Lgs. 196/03). Per approfondimenti, visitate il nostro sito istituzionale: http://dada.dada.net/it/.



Obiettivo della progettazione di un cluster è la rea-lizzazione di un’infrastruttura di calcolo affidabile costituita da gruppi di PC “standard” (anche in ter-mini di “media” affidabilità). In letteratura, chiun-que si è cimentato nel confronto economico tra so-luzioni con macchine parallele dedicate e cluster di unità di calcolo (ossia semplici PC) ha constatato che il prezzo per unità di prestazione di una soluzione cluster è di gran lunga inferiore al costo di una so-luzione parallela dedicata: e ad incidere sono anche i costi relativi all’alimentazione e alla dissipazione del calore. Ulteriori vantaggi delle soluzioni cluster rispetto a sistemi paralleli dedicati sono la facilità di scalabilità (possibilità di aggiungere ulteriori PC con costi operativi contenuti) e la maggiore affidabilità non essendoci un “unico punto critico” in caso di malfunzionamento di un nodo (con possibilità di so-stituzione a caldo dell’hardware o di ridistribuire il carico di lavoro su altri nodi).

Indirizzi IP del cluster

Ovviamente le macchine del cluster avranno in-dirizzi IP non pubblici, e al più esisteranno una o più macchine con indirizzi IP pubblici a garantire l’accesso via Internet al cluster (sistemi che hanno la funzione di dispathcer). In tal modo i problemi di si-curezza si concentrano su queste macchine “proxy”, mentre, per via dell’indirizzamento IP con indirizzi privati, l’accesso diretto ai nodi del cluster non può avvenire, né i pacchetti della rete IP privata potran-no essere inoltrati all’esterno della rete dei nodi del cluster. Come è noto sono tre gli intervalli IP riser-vati per reti private:

· 10.0.0.0 – 10.255.255.255 · 172.16.0.0 – 172.31.255.255 · 192.168.0.0 – 192.168.255.255

Nella configurazione IP dei nodi del cluster poter disporre di indirizzi IP privati è utile sia per motivi di sicurezza sia perché non tutti dispongono di deci-ne di preziosi indirizzi IP pubblici da poter sottrar-re per i nodi di un cluster (numero che può variare da pochi PC a centinaia di nodi). Inoltre col passar del tempo, ad esempio utilizzando gli indirizzi IP di classe C 192.168.x, si possono utilizzare fino a 256 indirizzi di rete per configurare ulteriori cluster che si andranno a sviluppare in futuro.

Interconnessione dei nodi

Esistono più metodi per l’interconnessione dei nodi del cluster: ciascuna tecnica comporta un determi-nato bilancio tra vantaggi e svantaggi a livello di costo e di efficienza della soluzione ottenuta. Due macrocategorie topologiche per realizzare un cluster fisico (tralasceremo quindi le soluzioni “sparse”) si ottengono in base al tipo di interconnessione tra i nodi:

· interconnessioni dirette: ogni nodo ha la duplice funzione di “nodo” di calcolo e di switch

· interconnessioni indirette: ogni nodo o è un nodo di calcolo o è uno switch

Nel caso di nodi a interconnessione diretta, si ricorre a una o più schede di rete per macchina e alla attenta configurazione delle tabelle di routing del nodo per poter realizzare le connessioni desiderate con gli al-tri nodi; nel caso delle interconnessioni indirette i nodi sono tipicamente connessi tramite switch. Gli aspetti di progettazione topologica di un cluster sono concetti derivati e in comune con la progetta-zione delle reti (specie reti geografiche complesse) e dei sistemi paralleli: per cui si parla di configurazio-

Modalità e tecniche di interconnessione dei nodi di un cluster

Appunti sulle topologie dei cluster

Ü di Natale Fino

SPEC

IALE





ni bidimensionali a maglia (mesh), toroidali (una maglia in cui ogni nodo estremo è connesso sia all’altro nodo estremo della stessa riga sia al nodo estremo della riga ortogonale), ad anello (nodi connessi in sequenza e i nodi estremi a loro volta interconnessi), a ipercubo (i nodi sono i vertici di cubi “con-centrici” o “adiacenti” fra loro connessi), ad albero e via dicen-do. Ad esempio, così come accade per la progettazione delle reti e dei sistemi paralleli due proprietà a cui si è interessati anche nella progettazione topologica di un cluster (ne diamo solo un breve cenno) sono:

· latenza di commutazione (tempo che un “messaggio” impie-ga ad attraversare la rete)

· banda di bisezione (somma della banda di comunicazione del minor numero di canali che se rimossi separano la rete in due sottografi equivalenti disgiunti)

Ad esempio per diverse topologie viene evidenziata una laten-za “single-switch” ad indicare che ogni coppia di nodi è con-nessa attraverso un singolo hop.

Interconnessioni con switch

A differenza di un hub (che è un mero “ripetitore broadcast” di pacchetti di rete) uno switch interpreta gli indirizzi di de-stinazione dei pacchetti in ingresso su ogni porta e li inoltra attraverso la porta a cui è connesso il nodo (o il segmento di cui il nodo fa parte) di destinazione. Gli switch possono esse-re amministrati o non amministrati. Gli switch amministrati hanno un costo maggiore ma permettono configurazioni più avanzate. Molti switch di fascia alta, ad esempio, hanno pos-sibilità di connessioni dedicate inter-switch a larga banda, tra cui alcuni esempi sono:

· Port trunking ossia “segmentazione della porta” (noto anche come Cisco EtherChannel). Permette fino a 8 porte di essere trattate come una porta logica. Ad esempio, si possono connet-tere due switch Gb/s con una connessione a 4 Gb/sec “sacrifi-cando” quattro porte su ogni switch. La possibilità del port trunking sullo switch consente anche di utilizzare su macchi-ne Linux il cosiddetto channel bonding. Channel bonding si-gnifica collegare assieme più NIC in una connessione logica di rete, ed è supportato su Linux a livello di kernel (a partire dalla versione 2.4.x in poi).

· Switch meshing. Permette fino a 24 porte tra switch di essere trattate come una unica porta logica, creando una connessione con banda molto alta.

· Switch impilabili. Gli switch impilabili dispongono della possibilità di interconnessione ad alta banda tra gli switch che costituiscono un rack (ad es. fino a 8 switch). Queste connes-

FIGURA 1 Collegamento con port trunking di due switch Gb/s. Le quattro porte da 1 Gb/s in trunking realizzano una porta logica a 4 Gb/s.

FIGURA 2 Utilizzo di switch a n porte e m porte con port trunking

Il prezzo per unità di prestazione di una soluzione cluster è di gran lunga infe-riore al costo di una soluzione parallela dedicata





TABELLA 1 Stima utilizzata del prezzo di

acquisto degli switch Gb/s

sioni dedicate inter-switch raggiungono i 16, 32 e anche 40 Gb/s. Ovviamente si tratta di switch con costi non proprio ac-cessibili per progetti di cluster “amatoriali” o con pochi nodi.

Switch e port trunking

Nel caso di utilizzo di switch che supportano il port trunking è necessario riservare un certo numero di porte al trunking in modo da realizzare una porta logica con maggiore velocità di cifra: nel caso tipico (è il caso ad esempio di alcuni modelli di switch Gb/s), vengono messe in trunking fino a 8 porte fi-siche, per cui con gli switch Gb/s si possono realizzano porte logiche fino a 8 Gb/s. Un esempio di port trunking a 4 Gb/s è mostrato in Figura 1. Per non commettere errori di connessio-ne vanno considerati alcuni vincoli basilari del port trunking, ad esempio:

· Le porte in trunking su uno switch vanno connesse solo a porte in trunking di un altro switch.

· Le porte in trunking devono essere della stessa velocità: non si possono connettere porte in trunking a 100 Mbps con porte da 1 Gbps aggregate in trunking.

Detto ciò, supponendo che il numero di nodi da collegare sia tale da dover utilizzare due o più switch, quali relazioni

intercorrono tra numero di switch, porte da dedicare al port trunking e numero di nodi del cluster (Figura 2)? Ho provato a fare qualche semplice conto algebrico e a ricavare una for-mula di calcolo per ottenere un costo indicizzato per soluzioni (miste o omogenee), che utilizzano switch, ad esempio a 8, 16 e 48 porte. Va detto che non ho tenuto conto di eventuali limita-zioni “costruttive”, che possono quindi impedire determinate soluzioni, basate su un numero di switch omogenei o eteroge-nei. Le formule ricavate vanno prese come mero esercizio, per cui sono suscettibili a critiche e a correzioni, e sono comunque da raffinare con i vincoli imposti dalla realtà.

Supponiamo che il fattore di port trunking sia espresso dalla costante KT = numero di porte per switch in trunking

Nel seguito questa costante assumerà sempre il valore 4. Se per connettere Z nodi, disponiamo di un assortimento di più tipi di switch (ad esempio a 8, 16 e 48 porte), tutti che supportano il port trunking, quanti nodi (porte libere) otteniamo ricor-rendo a 2 switch “estremi” più k switch interni? Nei calcoli bisognerà tener conto che per gli switch estremi sono Kt le porte dedicate al trunking, e che il consumo di porte diventa 2*Kt per gli switch interni. Se chiamiamo con

Z = numero totale nodi (porte non occupate dal trunking)Ne = numero porte per switch estremi Ni = numero porte per switch interni

otteniamo:

Z = 2*(Ne - KT)+ K*(Ni - 2*KT)

Nel caso Kt = 4 abbiamo:

Z = 2*(Ne-4)+ K*(Ni-8)

con i vincoli

Ne>4, Ni>=8, K = 0,1,2,...

Vale a dire gli switch interni (valore K) possono essere 0 o più, e che per via del fattore di trunking (nei nostri esempi pari a 4) è tassativo utilizzare switch estremi con più di 4 porte e switch interni con almeno 8 porte. Possiamo anzi considerare il caso con switch estremi e interni a 8 porte un caso degene-re, in quanto

Z = 2*(8-4)+ K*(8-8) = 8

ha come risultato sempre 8 nodi, indipendentemente dal nu-mero di (inutili) switch interni utilizzati.Invece, nel caso di utilizzo di switch estremi a 8 porte e switch interni a 16 porte si ha:

Z = 2*(8-4)+ K*(16-8) = 8 + K*8

per cui ogni ulteriore switch interno a 16 porte comporta ulte-riori 8 porte disponibili (e quindi 8 ulteriori nodi collegabili).Per stabilire un costo delle soluzioni ho ipotizzato alcuni prez-zi per gli switch Gb/s a 8, 16 e 48 porte (Tabella 1).A questo punto, con un semplice foglio elettronico, è sta-

FIGURA 3 FNN con 3 switch e 8 nodi. La disposizione delle connessioni è ricavabile a mano solo per pochi nodi,poi è necessario ricorrere a un algoritmodi ausilio

Numero porte Costo (euro)

SW8 60

SW16 100

SW48 3800





to semplice ottenere i prospetti delle soluzioni e dei costi al variare del tipo e numero di switch utilizzati e del valore K (numero di switch interni utilizzati). Dopodiché è possibile confrontare le diverse soluzioni ottenute per ricavare quali, a parità di costo, permettono di connettere il maggior numero di nodi o, viceversa, quali a parità di nodi permettono un costo inferiore. Ad esempio per una soluzione a 48 nodi si ottengono tre possibilità, utilizzando tre combinazioni diverse di switch a 8, 16 e 48 porte (Tabella 2). La soluzione con costo inferiore è quella con 5 switch a 16 porte. Viceversa, disponendo, ad esempio, di circa 1000 euro di bu-dget, qual è la soluzione che permette il maggior numero di nodi? Le soluzioni con un costo di circa 1000 euro sono ripor-tate in Tabella 3: la soluzione da 1000 euro più conveniente è quella con 10 switch a 16 porte che consente di connettere 88 nodi; con 1100 euro si possono connettere 96 nodi utilizzando 11 switch da 16 porte. Tutte considerazioni che sfogliando un depliant, o davanti allo scaffale di un negozio, o consultando i listini Web di un rivenditore, non sono affatto immediate.

Reti FNN

Una rete FNN (Flat Neighborhood Network) si basa sull’uti-lizzo di più schede di rete su ogni macchina (tipicamente due), per realizzare connessioni tramite switch con un solo hop per il collegamento a qualsiasi altra macchina della FNN (un al-tro modo per indicare una latenza “single-switch”). Per gestire l’instradamento è necessario configurare opportunamente il routing su ciascun nodo. La configurazione delle connessioni disponendo di n porte switch, consente di collegare, con PC muniti di due schede di rete, n/2 macchine. La tecnica si basa sulla constatazione che è possibile far sì che ogni macchina sia connessa a due switch distinti: in tal modo ogni PC appartiene a due “regioni” diverse della rete. Un caso con quattro switch

a 4 porte (che permette di connettere 8 PC) è mostrato nella Figura 3. Le FNN rappresentano una soluzione economica, poiché non richiedono switch amministrati e permettono di ottenere pre-stazioni di tutto rispetto. Con l’aumentare del numero di mac-chine da connettere (considerando che un’ulteriore variabile è il numero di schede di rete per macchina), non è né intuiti-vo né facile ricavare manualmente la configurazione. All’in-dirizzo http://aggregate.org/FNN è disponibile un form per utilizzare un algoritmo genetico, sviluppato dall’Università del Kentucky, che consente di ottenere una configurazione ot-timale specificando il numero di nodi, il numero di porte per ciascuno switch (senza contare le porte di uplink) e il numero massimo di schede di rete per macchina.

Cluster senza switch: anelli e ipercubi

Nel caso del collegamento diretto, viene meno il costo di ap-provvigionamento degli switch, ma si amplificano i costi del-le schede di rete e dei cavi Ethernet di categoria 5e (costi che tuttavia sono minori rispetto a quelli degli switch). Con più schede di rete per macchina si possono creare più o meno age-volmente diverse topologie; il punto critico però è una attenta configurazione delle tabelle di routing di ogni nodo, per per-mettere ai pacchetti di attraversare la rete. I nodi, quindi, as-sumono una ulteriore funzionalità di router.

Anelli

Un anello è una disposizione in cui ogni macchina, dotata di due schede di rete, viene connessa alla macchina succes-

Ciascuna tecnica di interconnessione dei nodi comporta un determinato bilancio tra costi e efficienza della soluzione otte-nuta.

TABELLA 2 Confronto dei costi di switching con port

trunking per una soluzione a 48 nodi

Soluzione (sw estremi /sw interni)

Numero nodi Costo(euro)

2 8 porte + 5 16 porte 48 620

2 8 porte + 1 48 porte 48 3920

2 16 porte + 3 16 porte 48 500

TABELLA 3 Confronto delle soluzioni implementabili con un budget di circa

mille euro per l’acquisto degli switch

Soluzione (sw estremi /sw interni)

Numero nodi Costo(euro)

2 8 porte + 8 16 porte 72 920

2 8 porte + 9 16 porte 80 1020

2 16 porte + 7 16 porte 80 900

2 16 porte + 8 16 porte 88 1000

2 16 porte + 9 16 porte 96 1100

siva tramite un’interfaccia (ad esempio eth0) e alla macchi-na precedente tramite l’altra interfaccia (ad esempio eth1). Per l’assegnazione degli indi-rizzi IP conviene adottare una strategia che impiega due di-stinte classi di indirizzi di rete, uno per ciascuna “dimensio-ne”: ad esempio, gli indirizzi della rete 192.168.0 verranno assegnati alle schede connesse ai sistemi “successivi”, mentre gli indirizzi di rete 192.168.0 verranno assegnati alle schede connesse ai sistemi “preceden-





· dimensione 1: 192.168.1.x (con x che va da 1 a 8)


Il nodo k, ad esempio, avrà come indirizzi corrispondenti alle tre interfacce 192.168.0.k, 192.168.1.k e 192.168.2.k, e k varie-rà da 1 a 8 al variare del nodo in questione. A questo punto non resta che inserire la tabella di routing per ogni nodo. Un nodo avrà tre collegamenti diretti con i nodi limitrofi, per cui inseriremo tre corrispondenti comandi route add; per la con-nessione con gli altri nodi si può utilizzare come criterio il principio di instradare i pacchetti verso la i-ma dimensione di un nodo attraverso l’interfaccia di quella dimensione, ossia l’interfaccia i-ma (quindi l’indirizzo 192.168.0.x, 192.168.1.x o 192.168.2.x di ogni nodo). Un esempio di cubo a 16 nodi è mo-strato nella Figura 6. Da notare che in letteratura, il termine cubo o ipercubo, non sempre implica l’utilizzo di più interfac-ce di rete per sistema: spesso si preferisce ricorrere agli switch visto che il costo di questi apparati è diminuito notevolmente, evitando così il ricorso alle interconnessioni dirette.

Il channel bonding … in pillole

Il channel bonding è una tecnica che si basa su un particola-re driver, supportato dal kernel Linux, che permette di con-figurare in modalità slave più interfacce di rete che saranno associate a una interfaccia “virtuale” master. Si può utilizza-

FIGURA 4 Un anello con 4 nodi: ogni sistema è dotato di due interfacce di rete.

ti”. Un esempio di anello a 4 nodi in cui si adotta questa con-venzione è mostrato nella Figura 4. In questo modo, è anche più facile scrivere e verificare la correttezza delle regole di rou-ting di ciascun nodo. Da notare che in un anello con un mag-gior numero di nodi, per i nodi “estremali” può essere conve-niente un percorso di routing che tenga conto che alcuni nodi di destinazione dell’altro “lato” si raggiungono con un minor numero di hop seguendo il percorso inverso. Ad esempio, è banale constatare che in un cubo a n nodi il percorso più breve di instradamento dal nodo n al nodo 2 è attraverso il nodo 1 e non attraverso il nodo n-1.

Cubi e ipercubi

Nel caso più semplice di cubo, costituito da 8 sistemi inter-connessi senza switch, possiamo ricavare il numero di schede di rete necessarie per ciascun sistema da una semplice consi-derazione: da ogni vertice di un cubo (a sei facce) si diparto-no tre spigoli (che conducono ad ulteriori tre vertici distinti). Immaginando ogni sistema posizionato su un vertice del cubo è quindi evidente che ciascun “nodo” dovrà comunicare con altri tre nodi del cubo. Pertanto, ogni sistema sarà dotato di tre interfacce di rete, banalmente eth0, eth1 e eth2, realizzando così tre canali di comunicazione paralleli che coincidono con le tre “dimensioni” del cubo (Figura 5). Una strategia utile per “orientarsi” in cluster con topologie a più dimensioni è utiliz-zare un indirizzo di rete per ogni dimensione, e all’interno di ogni dimensione utilizzare la parte host dell’indirizzo IP della rete per enumerare gli indirizzi dei nodi. Per cui, nel caso a tre dimensioni (ossia per un cubo a 8 vertici) avremo le dimensio-ni 0, 1 e 2 che corrispondono alle interfacce eth0, eth1 e eth2 di ogni nodo. Ad esempio:


Gli switch ammi-nistrati hanno un costo maggiore ma permettono configu-razioni più avanzate.

FIGURA 5 Nodi di un cubo: ogni vertice è un sistema dotato di 3 interfacce di rete.





re qualsiasi interfaccia Ethernet, e il numero di interfacce di bonding definibile è virtualmente illimitato, mentre il nume-ro di interfacce slave è limitato dal numero di schede di rete supportato dalla distro Linux utilizzata e anche dal numero di slot liberi disponibili nel proprio PC. La configurazione di un alias di device virtuale viene inserita in

/etc/modules.conf

in modo che il driver di bonding venga caricato quando viene configurata l’interfaccia definita dall’alias. Ad esempio:

alias bond0 bonding

Per definire l’interfaccia di bonding bond0 si utilizza la proce-dura che si utilizzerebbe per una normale interfaccia di rete, creando il file di configurazione ifcfg-bond0 nel percorso

/etc/sysconfig/network-scripts

Il contenuto di questo file potrebbe essere

DEVICE=bond0IPADDR=192.168.1.1NETMASK=255.255.255.0NETWORK=192.168.1.0BROADCAST=192.168.1.255ONBOOT=yesBOOTPROTO=noneUSERCTL=no

Le interfacce che fanno parte del bonding avranno nel rispet-tivo file di configurazione (ad esempio, ifcfg-eth0 e ifcfg-eth1) due parametri specifici: SLAVE e MASTER. Ad esempio il file di configurazione per eth0 che fa parte del bond0 potreb-be essere:

DEVICE=eth0USERCTL=noONBOOT=yesMASTER=bond0SLAVE=yesBOOTPROTO=none

La direttiva MASTER indica il nome dell’interfaccia di bon-ding che funge da MASTER (ad esempio, bond0, bond1, ecc. se nel sistema sono definite più interfacce di bonding) men-tre la direttiva SLAVE definisce l’interfaccia di rete corrente come interfaccia slave associata all’interfaccia MASTER.

Se la distro Linux utilizzata non interpreta i parametri MA-STER e SLAVE nei file di configurazione delle interfacce di rete, non resta che procedere con i comandi ifconfig e ifen-slave:

/sbin/ifconfig bond0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up

e l’associazione tra la master e le due (o più) slave avviene per mezzo del comando

/sbin/ifenslave bond0 eth0/sbin/ifenslave bond0 eth1

Modificati gli script di configurazione, basta riavviare lo stra-to di rete, riavviando il sistema o meglio, con comandi spe-cifici, ad esempio su sistemi Fedora si potrebbe ricorrere al comando

ifup bond0

o eseguire lo script di inizializzazione della rete:

/etc/rc.d/init.d/network restart

A questo punto le due interfacce saranno gestite e supervi-sionate come “unicum” dal driver di bonding, aumentando la banda di connessione disponibile in ingresso/uscita sulla rete.

Conclusioni

La topologia di un cluster dipende anche dal tipo di problema parallelo da trattare, pertanto le valutazioni su quale tipologia adottare è anche funzione della classe specifica di problemi computazionali da trattare. Per quanto concerne l’aspetto eco-nomico, invece, è opportuno richiedere delle offerte commer-ciali a più fornitori, poiché l’acquisto in quantità di un con-gruo numero di PC, di schede di rete e di switch può far de-terminare sconti variabili che possono ridurre, anche sensibil-mente, il costo teorico previsto dell’architettura da realizzare.

Riferimenti

[1] Brown R. G., “Engineering a Beowulf-style Compute Clu-ster” http://www.phy.duke.edu/~rgb/Beowulf/beowulf_book/beowulf_book/index.html[2] Adams J., Vos D., “Small-College supercomputing: buil-ding a Beowulf cluster at a comprehensive college”http://www.calvin.edu/~adams/professional/publications/SmallCollegeSupercomputing.pdf[3] Linux Channel Bonding - http://sourceforge.net/projects/bonding[4] FNN – http://aggregate.org/FNN

FIGURA 6 Un ipercubo a 16 nodi

cutting edge


L’ambiente di sviluppo Java permette di integrare la tecnologia RFID con i sistemi informativi per la gestione dei processi aziendali orientati alla logistica (Supply Chain). In questo articolo, oltre a trattare le nozioni introduttive esamineremo anche le componenti di un sistema informativo RFID basato su Java.

Cos’è RFID

Radio Frequency Identification o RFID è una tecnologia che permette di riconosce-re oggetti o “articoli” utilizzando i segnali radio. RFID nasce come evoluzione dei sistemi basati su codice a barre, e si basa sulla presenza di un tag o transponder e di un lettore. La tecnologia RFID accede da remoto alle informazioni disponibili tramite il tag, utilizzando un sistema di comunica-zioni a radio frequenza. Queste informazioni variano da un semplice numero progressivo, a quantità di dati dell’ordine dei kilobyte, fino alla possibilità di gestire dati dinamici memorizzati cronologicamente.RFID è parte di una più ampia gamma di tecnologie per la collezione e la gestione automatizzata di dati in formato digitale, che va sotto il nome di Auto-ID; tra queste, oltre all’RFID, abbiamo il codice a barre, la biometrica ed il riconoscimento vocale.Queste tecnologie hanno lo scopo di effet-tuare il tracciamento di oggetti, di qualun-que natura siano, mediante un protocollo o schema di riconoscimento. In pratica si tratta di associare (applicare o innestare) univocamente dei tag a basso costo (lo sti-cker del codice a barre, o il transponder RFID, i quali hanno ormai costi pressoché paragonabili) a degli oggetti (ma anche ad animali o persone).

Cosa sono i tag RFID

Sono disponibili tre tipi di tag o transpon-der: attivi, semi-passivi e passivi:

· I tag attivi sono quelli dotati di alimenta-zione e sono essi stessi generatori di segnali radio;

· I tag passivi non sono sorgenti dirette di segnale, ma utilizzano le frequenze radio in ingresso per generare il segnale di risposta.

· I tag semi-passivi sono simili a quelli passi-vi, ma sono dotati di una batteria di alimen-tazione; e ciò permette di avere maggiore raggio di azione rispetto ai tag passivi.

L’impulso allo sviluppo di questa tecnologia si è avuto con l’abbattimento dei costi per singolo tag, abbattimento che si è avuto con i tag di tipo passivo, anche se questo tipo di

Le architetture Java a supporto dei processi di approvvigionamento

Java e RFID

Ü di Andrea Leoncini

Radio Frequency Identification o RFID è una tecnologia che permette di ricono-scere oggetti o “ar-ticoli” utilizzando i segnali radio

cutting edge


cutting edge

tag presuppone un tipo di antenna per i lettori leg-germente più complessa, in quanto, oltre a leggere i dati di ritorno dal tag, deve anche essere in grado di attivare il tag stesso per induzione.Non avendo bisogno di un sistema di alimentazione interno è stato possibile lavorare sulle dimensioni di questi tag fino ad ottenerne di molto sottili, dello spessore di un foglio di carta [1].I tag passivi hanno invece un limite nel raggio di azione, e si va da pochi centimetri fino a qualche me-tro; per raggio di azione si intende la distanza entro cui l’antenna del lettore è in grado di generare, per induzione sul tag, il segnale di ritorno.Tag di questo tipo possono essere facilmente applica-ti ad oggetti mediante pellicole adesive, oppure, date le loro ridotte dimensioni, possono essere innestati direttamente negli oggetti (Figura 1).Anche se fa un certo effetto, è corretto far notare che questi tag possono essere facilmente impiantati “sotto pelle”, in genere per scopi agro-alimentari, ma la tecnica di impianto è applicabile anche sulle persone.Naturalmente, si potrebbe discutere molto sulle im-plicazioni relative al “taggare” una persona, con im-plicazioni di carattere filosofico e anche religioso; ma è ovviamente un argomento che, seppur interessante, evito di trattare, esulando dall’ambito tecnico.

Gli standard di riferimento

Affinché i sistemi RFID possano essere implemen-tati nell’intero ciclo di vita di un prodotto (richiesta di approvvigionamento, produzione, spedizione, immagazzinamento, vendita, riparazione, ecc.), ciclo

che coinvolge aziende e strutture diverse, è ovvio che la standardizzazione delle componenti coinvolte as-sume un ruolo fondamentale.L’intero processo, infatti, coinvolge non solo più si-stemi informativi, diversi tra loro per le caratteristi-che funzionali, ma, soprattutto, sistemi informativi di aziende diverse.

L’organismo che inizialmente si occupava di gestire ed unificare le varie specifiche funzionali e la reda-zione degli standard in questo settore era l’Auto-ID Center [2]. Questo centro verso la fine del 2003 ha cessato le sue attività ed ha trasferito tecnologie e compiti all’EPCglobal [3], un organismo finanziato dalle industrie del settore con lo scopo di emana-re gli standard a supporto della tecnologia EPC (Electronic Product Code) e la sua adozione in quella che è chiamata la EPCglobal Network. Per EPCglobal Network si intende un pacchetto di tec-nologie abilitanti i sistemi informativi digitali per il riconoscimento automatico, e la condivisione dei dati ad essi associati, degli oggetti di quella che viene comunemente chiamata la Supply Chain. La EPC-global Network utilizza la tecnologia RFID, ovvero le radio frequenze, per il riconoscimento automatico degli oggetti. La EPCglobal Network è costituita da cinque elementi fondamentali:

· EPC – Electronic Product CodeÈ il numero seriale che identifica univoca-mente un articolo della Supply Chain.

· I sistemi RFID, ossia lettori e tag RFIDIl tag è un microchip, dotato di antenna, che contiene i dati EPC. Il lettore è un apparato anch’esso dotato di antenna; in questo caso l’antenna è del tipo in grado di emettere onde radio che sollecitano l’antenna “pas-siva” del tag, che a sua volta emette segnali di risposta contenenti i dati EPC. A questo punto, il lettore comunica i dati ricevuti al sistema informativo mediante il cosiddetto EPC middleware. Da questo punto di vista, una delle attività al momento in corso pres-

L’impulso allo svilup-po di questa tecno-logia si è avuto con l’abbattimento dei costi per singolo tag che si è avuto con i tag di tipo passivo

FIGURA 1 Tag RFID applicabile a qualsiasi tipo di oggetto

cutting edge cutting edge


so l’EPCglobal è definire l’Auto-ID Reader Protocol Specification, ossia il protocollo con cui il lettore comunica i dati al middleware.

· EPC Middleware. L’EPC Middleware è il primo strato software di questi sistemi. Si interfaccia da una parte con l’apparato ad onde radio e si occupa di gestire gli eventi che l’appa-rato genera e di filtrare e collezionare i dati che dovrà poi immettere nel sistema informativo. Un esempio di filtro è quello legato alla ripetizione dell’evento di lettura di un tag: in questo caso, il middleware deve essere in grado di decidere se le due letture sono una ripetizione dello stesso evento e quindi una delle due va scartata.

·Object Name ServiceÈ il servizio che permette di individuare il server sul World Wide Web che dispone dei dati associati all’articolo EPC.

· Physical Markup LanguageÈ il linguaggio con cui vengono descritti i dati asso-ciati ad un articolo; si tratta di una sorta di vocabo-lario comune per i sistemi che gestiscono gli oggetti della EPCglobal Network.

Uno scenario di utilizzo

Quando si parla di applicazioni web, soprattutto in ambito didattico, si fa spesso riferimento al “carrello della spesa”, ossia il carrello virtuale (del negozio vir-tuale) che troviamo in alcuni siti web. Bene, anche nel nostro caso farò ricorso a questa metafora: solo che, stavolta, si tratta proprio del carrello fisico della spesa che usiamo nei grandi magazzini.Immaginiamo che la catena dei magazzini ACME, di cui siamo abituali frequentatori, abbia scelto di applicare la tecnologia RFID ai propri prodotti (at-tenzione: ciò significa che la stessa tecnologia è stata adottata anche dai fornitori, dai produttori degli ar-ticoli, dai magazzinieri e così via).Cosa noteremo di diverso rispetto agli altri supermer-cati? Per noi utenti, ossia clienti del supermercato, la differenza che salterà all’occhio saranno le casse.Rispetto al codice a barre, che necessita di un ope-ratore che esegua la lettura manovrando il lettore oppure l’articolo, i tag RFID vengono invece letti automaticamente dal sistema. La cassa, quindi, non avrà il banco per il passaggio degli articoli ma ci sarà semplicemente un “elemento” attraverso cui faremo transitare il carrello con gli articoli da acquistare; e sul display comparirà direttamente l’importo com-plessivo della spesa. Questo “elemento”, la cui forma lascio a voi stabilire o immaginare (ma di fatto è mol-to semplice), altro non è che una antenna RFID; ed è parte integrante del lettore. Ad esempio, è qualcosa di molto simile alle colonnine antifurto installate al-l’uscita di molti negozi. Probabilmente, qualche altro “passaggio” simile a quello delle casse lo troveremo

anche nei reparti, in modo che ogni tanto si possa fare un controllo sulla spesa fin lì effettuata e cono-scere l’importo totale.

Altre differenze, meno visibili esteriormente, saran-no presenti anche in altre zone nevralgiche dei ma-gazzini ACME, a cominciare dal reparto spedizioni. Le merci in arrivo (o in partenza) saranno convoglia-te attraverso un ulteriore “elemento”, differente pro-babilmente nelle dimensioni, ma sostanzialmente identico per funzionalità a quello delle casse.

Mentre nel caso delle casse il vantaggio sarà quello di non dover effettuare manualmente la scansione dei singoli tag degli articoli (basterà ciò per eliminare le code?), in questo caso ne trarranno vantaggio i sistemi di imballaggio. Con il metodo tradizionale, infatti, per inventariare la merce in ingresso ci si basa sul fatto che su ogni imballo è riportata la quan-tità di prodotti contenuti (per esempio, 24 pacchi di pasta), e si conteggia quindi il numero dei colli per sapere quanta merce è arrivata. Con il sistema RFID, invece, gli imballi possono contenere anche prodotto differenti, tanto la lettura del tag avviene per ogni singolo articolo contenuto nell’imballaggio.Analogamente, ancor oggi viene utilizzato il codice a barre per i pacchi in spedizione. Il problema è che l’ID con cui si marca il pacco fa riferimento al collo come entità unica; l’associazione con i contenuti è solo presunta, o comunque è stabilita in base ad al-tri strumenti (tra cui i documenti di trasposto della spedizione). Nel caso dell’RFID, invece, i contenuti dell’imballo sono stabiliti in base alla lettura “simul-tanea” dei tag, lettura che in tempo reale mostra la lista esatta degli oggetti contenuti nel pacco. Questa precisione nel controllo degli articoli può inoltre es-sere applicata in tutta la fase di spedizione (Figura 2).

Se vi è mai capitato di dover controllare i movimenti di una spedizione internazionale avrete notato che avviene per tratte. Pensate ad una spedizione dal-l’Inghilterra all’Italia. Un corriere ritira un plico dal mittente e la consegna ad un hub regionale in

Questi tag posso-no essere facilmen-te impiantati sotto pelle, in genere ad animali

cutting edge


cutting edge

Inghilterra; e questo hub inoltra il pacco ad un hub europeo (in Germania). Dall’hub europeo, il plico viene inviato all’hub regionale in Italia, ed infine un corriere effettua la consegna a domicilio. Si tratta di una modalità più o meno standard per questo tipo di spedizioni.Se tutti i nodi di questo percorso hanno adottato la tecnologia RFID, in ogni nodo si può controllare l’integrità del contenuto, ossia che tutti gli articoli della spedizione siano presenti e che non ci siano state manomissioni. Inoltre, il tag RFID può tenere traccia di tutti i passaggi avvenuti (data, ora di arrivo e di partenza) per ogni nodo del percorso (Figura 3).

Architettura di riferimento

Se tag RFID e antenne rappresentano l’hardware adottato dalla ACME, passiamo ora ad analizzare anche il lato software dell’architettura (Figura 4). Aspetto che ci riguarda più direttamente.Analizziamo perciò l’architettura logica che serve a implementare un sistema informativo basato sulla tecnologia RFID; e partiamo dalla periferia del siste-ma, ossia dai lettori (EPC Tag Reader).Prima di tutto, serve una componente software che si occupi di processare i dati grezzi trasmessi dalle antenne o, come si è detto prima, dai reader. Questa componente la chiameremo Event Manager.

Tipicamente, i reader espongono un’interfaccia a cui è attribuito un indirizzo IP, per cui l’Event Manager può processare i dati tramite delle connessioni TCP/IP. Questa componente deve occuparsi fondamental-mente di due aspetti:

· raccogliere ed interpretare i dati che i reader pro-ducono;

· filtrare i dati stessi.

Sebbene i dati EPC siano definiti secondo degli stan-dard, il protocollo di trasmissione di questi dati, os-sia le modalità con cui l’Event Manager ed il reader si scambiano i dati, è invece legato all’hardware. In altre parole, i vari produttori di antenne hanno adot-tato ciascuno un proprio protocollo di trasmissione: il nostro Event Manager, quindi, deve essere in grado di gestire apparati differenti. L’idea è che l’Event Manager sia predisposto per poter essere configurato con dei driver specifici, in base al modello di reader. Deve quindi essere predisposto con un “Adapter” sul quale installare i vari driver (o plug-in) forniti a cor-redo dell’apparato hardware.Riguardo al filtro sui dati, questo deve essere in gra-do di processare gli eventi per poter estrapolare solo quelli significativi.Nel caso del carrello della spesa, ad esempio, se un pacco di pasta (lo stesso pacco di pasta) viene letto dall’antenna due volte, è chiaro che l’informazione

FIGURA 2 Applicazione della tecnologia RFID in fase di spedizione



“pacco di pasta nel carrello” deve essere processata una sola volta. Praticamente, quando le letture di un medesimo oggetto vengono processate entro un certo intervallo di tempo, il filtro deve emettere un solo evento. Tipicamente, il valore dell’intervallo di con-trollo è uno dei parametri configurabili del sistema.

Da un punto di vista logico abbiamo quindi una o più antenne o reader che fanno riferimento ad un Event Manager (EM).

La realizzazione fisica, invece, consiste nell’avere una o più antenne collegate via TCP/IP ad una sta-zione su cui è installato l’EM. Trattando l’implemen-tazione fisica dell’architettura, andrebbe valutato an-che l’impatto che la gestione della cosiddetta “High Availability” (HA) ha su di essa.Questa analisi, però, implica una serie di considera-zioni tipiche dell’ambito progettuale ed è difficile in-dicare un’architettura in HA senza analizzare anche le condizioni al contorno.Diciamo comunque che in generale il reader è una componente atomica e deve essere quindi trattato come un apparato di rete; quindi, se vogliamo esse-re sicuri che in un certo sito (per esempio la cassa

o l’ufficio spedizioni) si abbia la certezza di poter effettuare delle letture dobbiamo eventualmente ridondare il reader, piazzando due antenne o più antenne (in questo caso la funzione di filtro dell’EM sarà maggiormente necessaria). La pratica di ridon-dare le antenne viene adottata anche per evitare che interferenze o impedimenti facciano perdere delle letture.Per quanto riguarda l’EM, invece, possiamo gestire l’HA moltiplicando le istanze applicative, quindi dati N reader, avremo due o più istanze di EM di riferimento.

Bene, a questo punto abbiamo a disposizione le com-ponenti che eseguono le letture RFID ed abbiamo un hub per la gestione delle letture. Adesso dobbiamo convertire gli eventi di lettura dei dati EPC in eventi di business. Mi spiego meglio: ab-biamo un sistema che ci informa in modo automatico quando un articolo viene riconosciuto da una delle antenne; ma il sistema informativo come deve inter-pretare questa informazione?Se, per esempio, la lettura viene effettuata da uno dei reader delle casse, il sistema informativo deve presentare il conto e probabilmente deve anche se-gnalare che gli articoli presenti nel carrello sono stati venduti, quindi non più disponibili sugli scaffali e va decrementata la giacenza di magazzino.Se invece la lettura viene effettuata dal reader in-stallato all’ingresso del magazzino, ciò significa che degli articoli letti va incrementata la giacenza di magazzino. Nella realtà certamente il processo è più complesso (dovendo prevedere anche la gestione del-le scorte minime, gli ordini a fornitore, il passaggio dal magazzino ai banchi vendita, ecc.).

Tuttavia, ci basta capire che tra gli EM e il sistema informativo aziendale abbiamo bisogno di un’altra componente software, che traduca gli eventi di lettu-ra dei tag RFID in dati propri del processo aziendale. Questa componente deve essere in grado di adattarsi

alle specifiche ca-ratteristiche del si-stema informativo: la traduzione degli eventi semplici in dati di business dipende fortemente dai processi azien-dali. Infatti, la tec-nologia RFID può essere applicata ai settori più disparati, per cui la lettura di un certo tag assume di volta in volta in volta significati di-versi.Chiamiamo questa nuova componente Information Server, non per particolare

Tag di questo tipo possono essere fa-cilmente applicati ad oggetti mediante pel-licole adesive

FIGURA 3 Applicazione della tecnologia RFID in un hub

cutting edge


cutting edge

simpatia per l’uso di termini in inglese, ma per adat-tarci alla terminologia già in uso in questo settore. Possiamo pensare all’IS come ad una applicazione JEE (Java Enterprise Edition): in questo caso abbia-mo bisogno di un Application Server.Quindi l’IS quando riceve una notifica del tipo: “letto EPC abc dall’antenna xyz” sa che equivale a dire “entrato in magazzino l’articolo xxx”, che, tra-dotto in termini informatici, equivale più o meno ad aggiungere dei dati in un certo formato all’interno di un archivio. L’IS è una componente tipicamente asincrona del nostro sistema distribuito.Se ci pensate bene, i due momenti, ricezione della notifica e transazione sul sistema informativo, sono di fatto disaccoppiati. Da un lato, infatti, abbiamo bisogno di poter ricevere e trattare anche grosse quantità di eventi di lettura e di prepararli per essere processati; successivamente, si potrà gestire l’intera-zione con i sistemi informativi (tenendo conto che questo secondo passaggio potrebbe anche richiedere l’intervento di un operatore). Si tratterà quindi di implementare una coda di eventi e una serie di sotto-scrittori alla coda che processino gli eventi stessi.

Un esempio: la spesa ai grandi magazzini ACMEIl carrello della spesa passa tra i “varchi” delle casse e i reader leggono i tag degli articoli contenuti nel carrello; l’EM riceve i dati grezzi delle letture, esegue

gli eventuali filtri sui dati, confeziona gli eventi e li invia all’IS (ossia invia dei messaggi JMS all’Appli-cation Server dell’IS).A questo punto, l’IS, leggendo i messaggi in arrivo, potrà applicare la logica di business opportuna, che nel caso delle casse equivale a creare una lista degli articoli, riportando il relativo prezzo e il totale della spesa effettuata. Questo processo potrebbe facil-mente essere implementato con dei Message Driven Bean.Passati i varchi, il cliente troverà lo scontrino pronto e dovrà solo effettuare il pagamento (magari anch’es-so automatizzato). Preparare lo scontrino, natural-mente, non sarà l’unica operazione da associare agli eventi: il sistema dovrà infatti interagire con una qualche componente del sistema legacy dei magazzi-ni, per “avvisare” che si devono rimuovere certi arti-coli dalla lista degli articoli presenti sugli scaffali dei reparti; operazione che potrebbe consistere nell’in-vocare un apposito Web service o più semplicemente in una invocazione di una stored procedure SQL su un database.Oltre ai sistemi legacy già presenti in azienda, da un punto di vista logico non c’è altro: gli Event Manager e l’Information Server sono le componenti di base (il numero degli EM e degli IS è naturalmente variabi-le e dipende dalle caratteristiche dell’impianto). È quindi l’architettura del sistema a differenziarsi in funzione degli impianti e, naturalmente, le logiche di business da applicare agli eventi.

FIGURA 4 Flusso di funzionamento dell’RFID



Ulteriori considerazioni su RFID

A conclusione dell’articolo vorrei tornare su alcuni aspetti meno tecnici della tecnologia RFID ma co-munque decisamente significativi ed interessanti.Partiamo dal presupposto che si tratta di una tecno-logia che avrà sicuramente un impatto sempre mag-giore sulla vita di tutti i giorni. Con l’abbattimento dei costi dei tag e di conseguenza con l’utilizzo mas-siccio della tecnologia sui prodotti di uso comune, i sistemi RFID apporteranno non poche novità nella vita quotidiana. Voglio accennare ad un paio di esse come spunto per delle riflessioni che lascio al lettore. Io vivo a Roma, ma l’argomento che tratterò è comu-ne a molte altre città, in Italia e non: i furti di auto e di moto.In particolare prendo spunto da una testimonianza. Il proprietario di uno scooter molto venduto, mi ha raccontato di avere subito il furto della moto e di-verse volte anche il furto di alcuni pezzi della moto. Mi ricordo che mi disse, ovviamente avvilito, che nonostante le mille precauzioni e i soldi spesi per l’antifurto, probabilmente avrebbe dovuto desistere, e scegliere un altro modello di moto … meno sogget-to a furti.Proviamo ad immaginare le implicazioni dell’appli-cazione della tecnologia RFID nel settore automobi-listico (nonostante il ricorso ai sistemi GPS). Ciò che otterremmo è che quasi ogni singolo pezzo con cui è costruito il mezzo (macchina o moto che sia) sarà catalogato e registrato in base all’EPC. La carrozze-ria, i fari, i sedili, gli sportelli, le parti del motore, le ruote, i dischi e le pinze dei freni: insomma tutte le parti, che assemblate costituiscono il veicolo, sono singolarmente registrate e questi codici costituireb-bero una sorta di DNA del veicolo. Nel caso di una riparazione in officina, la sostituzione di un pezzo comporterà anche l’aggiornamento di un archivio centrale (una sorta di Pubblico Registro Automobili-

stico) con il codice del nuovo pezzo sostituito.In questo scenario, una pattuglia di Polizia che deve effettuare un controllo sarà dotata semplicemente di un’antenna RFID e grazie a un collegamento telema-tico con la centrale potrà verificare i dati al passaggio di un veicolo. Con buona pace per il traffico di pezzi di ricambio e di veicoli rubati.

Conclusioni

L’idea è invitante e rassicurante. Ma esiste un rove-scio della medaglia? I tag RFID non hanno nessun livello di sicurezza nel proteggere i dati contro la lettura non autorizzata: chiunque può effettuare delle letture. Motivo per cui alcune letture sarebbero lesive della privacy. Nel caso citato dell’applicazione della tecnologia RFID al settore dell’abbigliamento, ad esempio, se gli esercizi commerciali facessero pa-trimonio comune dei dati letti dalle antenne, ognuno di noi potrebbe essere “etichettato” in base agli ac-quisti effettuati, tracciando anche movimenti, gusti e abitudini dei consumatori. E in teoria si potrebbe risalire anche alle relazioni sociali tra persone (per via di regali e prestiti). Ed è ben noto, che il proble-ma cruciale è sempre “chi controlla il controllore?”. Probabilmente chi si occupa della parte tecnologica della questione non è direttamente coinvolto nelle decisioni sugli “impatti sociali” che guideranno questi sviluppi, ma tuttavia alcune implicazioni pra-tiche, positive e non, dell’adozione della tecnologia RFID è bene conoscerle.Allora, siete pronti? O state pensando sia meglio ca-tena, lucchetto e attendere in fila alle casse?

Riferimenti

[1] http://www.eetimes.com/news/design/showArticle.jhtml?articleID=179100286[2] Auto-ID Center www.autoidcenter.org[3] EPCglobal http://www.epcglobalinc.org/home

Note Biografiche

Andrea Leoncini è Senior Java Architect di Sun Microsystems Italia, lavora nei servizi professionali e si occupa di progetti di sviluppo nell’area enterprise. Ha più di 15 anni di esperienza nel settore dell’Information Tecnology e, precedentemente, oltre ad alcune aziende private minori, ha lavorato nel settore pubblico (Gruppo ENI) maturando esperienze di Cartografia e Computer Aid Design.

Con l’abbattimento dei costi dei tag i sistemi RFID appor-teranno non poche novità nella vita quo-tidiana

cutting edge


cutting edge

Introduzione

Le reti Ethernet in rame trasportano i dati utilizzando basse tensioni elettriche, come stabilito dall’IEEE 802.3. In condizioni or-dinarie tali tensioni non sono pericolose, ma negli ambienti sanitari, ove possono essere applicati degli elettrodi sul paziente, la rete dati va progettata con particolari accorgi-menti. Questo articolo richiama nozioni di cablaggio strutturato, leggi in vigore in Italia e tecniche di progettazione, oltre ad introdurre un elemento poco conosciuto dai network designer: il trasformatore elettrico d’isolamento.

Verso un sistema di cablaggio universaleSe analizzassimo la storia dei progressi avve-nuti negli ultimi 15 anni relativamente al ca-blaggio strutturato ci accorgeremmo di come tra le linee guida ne siano emerse tre:

· Convergenza;· Integrazione;· Sicurezza.

Relativamente alla convergenza, abbiamo assistito all’utilizzo sempre più diffuso di un unico tipo di cavo, l’UTP (Unshielded Twisted Pair) per trasportare sia i dati digitali sia il segnale analogico. Tra questi, l’UTP in classe 5e si è dimostrato in grado di adattarsi

all’evoluzione degli standard, confermando nel tempo di essere un ottimo supporto. Il basso costo lo rende conveniente, non solo per realizzare reti dati bensì anche come semplice doppino telefonico (collegando una sola coppia di fili ritorti invece delle quattro coppie), realizzando in tal modo un’infrastruttura che al bisogno è già pronta per il Voice Over IP, ed è anche in grado di trasportare il segnale video in alta definizio-ne (HDTV). In merito all’integrazione, stiamo assistendo all’esplosione della domotica, cioè alla possi-bilità di gestire strumenti elettrici come gli impianti d’illuminazione, i sistemi antincen-dio, di allarme, di irrigazione o di riscalda-mento, solo per citare qualche esempio, di industrie, alberghi, ospedali o abitazioni, tra-mite un bus dati in bassa tensione che pilota, sotto il controllo di un computer, i relè di po-tenza finali. L’integrazione della rete dati con la rete elettrica ha posto non pochi problemi di sicurezza, intesa non solo come sicurezza logica legata agli attacchi di virus o hacker, ma anche in termini di sicurezza elettrica e di conformità alle leggi. Capita, così, che i progettisti di reti ben conoscano i vantaggi derivanti da una comune piattaforma di co-municazione, in termini di crescita, efficacia ed efficienza dei processi, ma spesso ignorino i potenziali rischi dovuti all’integrazione con la rete elettrica. Una piattaforma dati comu-

In alcune realtà, nel progettare una rete dati si devono affrontare problematiche non proprio comuni

Elementi di sicurezza elettrica nelle reti dati sanitarie: il trasformatore d’isolamento

Ü di Alberto Rosotti

cutting edge

42Login Internet Expert n.62 Gennaio/Febbraio 2007

cutting edge


ne ed aperta si adatta più efficacemente alle esigenze del mercato, mostrando maggiore flessibilità agli sviluppi imprevedibili della ricerca, riducendo i costi di esercizio, con il vantaggio di un controllo centra-lizzato, vantaggio che da solo spesso ripaga i sacrifici compiuti nel progettarla in modo convergente ed elettricamente a norma.I prossimi due paragrafi richiamano i concetti di cablaggio strutturato ed introducono il problema dell’integrazione con gli impianti elettrici.

Il cablaggio strutturato

Il cablaggio strutturato è un’infrastruttura composta da elementi attivi e passivi, con lo scopo di far circo-lare dati, analogici e digitali, tra gli attori delle rete. La condivisione dei dati si può ottenere in vari modi, con o senza cavi, mediante schede di rete ed apparati intermedi di smistamento e controllo (hub, switch, router, ecc.). Si parla comunque di interconnessione fisica e di interconnessione logica: quella fisica riguarda cavi ed apparati che realizzano le rete, quella logica si rife-risce al metodo seguito per implementare il flusso dei dati. Le tre topologie fisiche canoniche sono:

· a stella (Figura 1a); · ad anello (Figura 1b); · a bus (Figura 1c);

ognuna caratterizzata da peculiari vantaggi e svan-taggi. La topologia più comune è sicuramente la stella a più livelli, detta anche stella gerarchica o stella di stelle, che garantisce flessibilità sia in fase d’installazione sia di ampliamento della rete. L’inter-connessione logica ha le medesime forme canoniche di quella fisica, cioè stella, anello e bus; la possibilità d’implementare una forma logica piuttosto che un’al-tra dipende sia dai protocolli usati sia dalla topologia fisica. La topologia fisica a stella, ad esempio, permet-te di realizzare la maggior parte degli schemi logici d’interconnessione (utilizzando opportuni switch programmabili) ed in particolare le tre forme canoni-che. D’altro canto, con una rete fisica ad anello non si riescono a fare circolare i dati “peer-to-peer”, come in una stella. In sintesi, ciò che mi preme sottolineare, è che la struttura fisica può non coincidere con quella

logica: dei nodi collegati fisicamente tra loro a stella possono comunicare sfruttando diversi schemi logici mentre l’unione dello schema fisico e logico è il punto di partenza nella progettazione delle reti integrate.

Livelli di cablaggio

Generalmente, la progettazione di LAN complesse

richiede tre livelli di cablaggio:

· cablaggio di piano; · cablaggio di edificio; · cablaggio di comprensorio.

La progettazione di LAN complesse richie-de generalmente tre livelli di cablaggio.

FIGURA 1a Topologia d’interconnessione a stella

FIGURA 1b Topologia d’interconnessione ad anello

FIGURA 1c Topologia d’interconnessione a bus

cutting edge


cutting edge


Il cablaggio di piano è sinonimo di cablaggio orizzon-tale, in quanto di norma lo sviluppo dei cavi giace su uno stesso piano. Interessa quella parte di rete che va dall’utente (presa a muro) fino al primo centro stella, cioè l’armadio di piano più vicino. Normalmente, questo cablaggio è realizzato con cavi in rame. Il cablaggio di edificio è sinonimo di cablaggio ver-ticale, perché collega gli switch posti negli armadi di piano al concentratore principale; è consigliabile realizzarlo con cavi in fibra ottica o di tipo Gigabit rame. È bene precisare che quanto detto non è un dogma, e che le regole e le normative ammettono eccezioni: per esempio, a patto che vengano rispettate le distan-ze nei collegamenti, può capitare di realizzare un cablaggio in rame orizzontale che serva utenti su più piani, con un unico concentratore per tutto l’edificio. In questo caso si parla ancora di cablaggio orizzontale anche se i cavi percorrono tratte verticali ed i piani sono più d’uno. In modo analogo un piano può essere cablato con due o più cablaggi orizzontali fisicamente separati: ciò può accadere quando il piano è molto va-sto oppure per ottemperare a precise norme di legge legate alla sicurezza elettrica. Ciò accade, ad esempio, nelle reti dati delle sale operatorie, che devono essere elettricamente isolate: questo è il tema principale del-l’articolo e verrà sviluppato nei prossimi paragrafi. Il cablaggio di comprensorio è quello che permette di collegare edifici distanti, facenti capo ad un’unica infrastruttura logica; per esempio, ad un unico domi-

nio o ad un’unica azienda con più domini. Sovente, per risolvere problemi di distanza, è necessario uti-lizzare la fibra ottica multimodale (tratte fino a 500 metri) o monomodale (tratte fino a 50 km) con router e firewall appositamente programmati. La progetta-zione del cablaggio di comprensorio prende spesso spunto da quella delle reti metropolitane (MAN), perché ne condivide le esigenze e gli apparati.

Velocità di cifra e larghezza di banda

Dal punto di vista tecnologico, la progettazione del cablaggio strutturato è definita a livello internaziona-le da severe norme di legge. Tutti i componenti, dai cavi agli switch, sono descritti funzionalmente nelle normative di riferimento EIA/TIA o ISO/IEC, che riguardo le caratteristiche elettriche e le prestazioni in esercizio. Altrettanto formalmente, sono descritti i protocolli che si utilizzano per lo scambio dei dati a livello di rete e a livello applicativo: tra questi ricor-diamo i protocolli 802.3 (Ethernet) e 802.11 (Wi-Fi). Al di là delle sigle e delle normative, nell’interazione con il committente il progettista concentra spesso l’attenzione su due punti chiave: la larghezza di ban-da e la velocità, concetti che vale la pena rinfrescare, perché legati alle prestazioni.La velocità di cifra è il numero di bit trasmessi in un secondo tra due punti di una rete dati. Si misura in bit al secondo (bps) o con i suoi multipli (Kbps, Mbps, ecc.) e dipende da vari fattori:

· lunghezza del cavo;· rapporto segnale/rumore (S/R);· topologia della rete;· schede di rete lato computer;· porte lato switch.

Oltre ovviamente ai protocolli utilizzati. Nella pra-tica, il tanto amato protocollo Ethernet 10Base-TX trasmette 10 Mbps mentre l’ultimo nato, denominato IEEE 802.3an, che risale a Giugno 2006, raggiunge i 10 Gbps: in altre parole è 1000 volte più veloce.La larghezza di banda è l’intervallo di frequenze che una rete dati può trasportare mantenendo integro, entro certi limiti, il rapporto segnale/rumore. La lar-

Velocità di cifra e larghezza di banda sono due concetti che spesso vengono confusi

TABELLA 1

Standard EIA/TIA Standard ISO/IEC Larghezza di banda Velocità di cifra (applicazioni supportate)

Categoria 3 Classe C 16 Mhz Ethernet a 10 Mbps

Categoria 5 Classe D 100 Mhz Fast Ethernet a 100Mbps

Categoria 5e Classe D-2000 100 Mhz Gigabit Ethernet a 1 Gbps

Categoria 6 Classe E 250 Mhz Gigabit Ethernet a 10 Gbps

Categoria 6a Classe EA 500 Mhz Gigabit Ethernet a 10 Gbps

Categoria 7 Classe F 600 Mhz Gigabit Ethernet a 10 Gbps

cutting edge


cutting edge


ghezza di banda, in realtà, si esprime in Hertz (cicli al secondo), un’unità di misura ben diversa da quella usata per la velocità di cifra! È però vero che all’au-mentare della larghezza di banda aumenta anche la velocità di cifra, per cui spesso i due termini si usano come sinonimi senza commettere errori “evidenti”: comunque chi è alle prese con capitolati o appalti è bene che conosca la differenza.

La Tabella 1 elenca la larghezza di banda delle catego-rie dei cavi più comuni. Esaminando la tabella sono possibili alcune considerazioni. · Prima considerazione: il cavo in rame di classe 5e ha larghezza di banda pari a 100 MHz e normalmente viene utilizzato con velocità di cifra pari a 100 Mbps. Nulla vieta, però, di trasmettere dati a 300 Mbps su una banda di 100 Mhz! La riuscita, in genere, dipen-de dalle schede di rete, dal rapporto segnale/rumore che si vuole mantenere, dai requisiti del capitolato, dalla lunghezza dei cavi, ecc.· Seconda considerazione: un cavo in rame in classe 6A ha larghezza di banda pari a 500 MHz e spesso viene usato per trasmettere dati ad 1 Gbps; anche in questo caso nulla vieta, anzi è la norma, di trasmettere dati ad una velocità di cifra inferiore, per esempio 100 Mbps. Molto più spesso di quanto si creda le reti dati vengono sovradimensionate in fase di progettazione e realizzate in classi che permetterebbero una velocità di cifra superiore alla velocità degli switch! In nome di un’espandibilità che non verrà mai sfruttata. Ho incontrato spesso queste realtà, sopratutto … quando il denaro è pubblico. · Terza considerazione: sia la categoria 5 sia la cate-goria 5e hanno la stessa larghezza di banda; ma la 5e, molto più utilizzata, può raggiungere velocità 10 vol-te maggiori. La differenza tra le due categorie risiede nelle caratteristiche dei parametri elettrici, che per la 5e sono molto più restrittivi: in altre parole, il cavo 5e deve superare prove più selettive e deve fornire, rispetto al fratello minore, prestazioni maggiori su

tutta la larghezza di banda.

Per tirare le somme, se dovessimo progettare oggi un’infrastruttura di rete integrata ed universale, sia in ambiente pubblico sia in una civile abitazione, i cavi in rame in categoria 6 rappresentano un’ottima ed economica opportunità, dato che il segnale televi-sivo HDTV richiede una velocità di cifra attualmente pari a 2,5 Gbps mentre la telefonia al massimo richie-de 1 Mbps, e per i dati digitali il Gbps è più che suf-ficiente. L’unico svantaggio che si ha, rispetto all’uso dei cavi 5e, è di tipo pratico e lo incontriamo all’atto della stesa dei cavi dentro le guide corrugate (soprat-tutto se “sovraffollate”), essendo il cavo in classe 6 più rigido del cavo precedente. Dal versante econo-mico le ultime quotazioni in mio possesso indicano il cavo UTP classe 5e a 0,90 Đ/metro e l’UTP in classe 6 a 1,20 Đ/metro (sono prezzi puramente indicativi e al netto dell’IVA).

Elementi di sicurezza elettrica nelle reti dati sanitarie

Veniamo ora al cuore dell’articolo, la parte che affron-ta la sicurezza elettrica delle reti dati. Come sappia-mo, Ethernet utilizza tensioni relativamente basse per trasportare i segnali, dell’ordine di 5 V e correnti di pochi milliampere (per approfondimenti si veda il protocollo ISO-OSI layer fisico e IEEE 802.3). Fanno eccezione le tecnologie Power Over Ethernet (PoE), ove per alimentare dispositivi come telecamere, siste-mi d’allarme ed Access Point sono in gioco tensioni di circa 15 V, fornite dagli switch PoE. Certamente anche 15 Volt non costituiscono un pericolo per un individuo adulto che tocca un cavo Ethernet con un dito (quindi il bus dati della casa “demotica” non de-sta problemi). Ma pensiamo cosa potrebbe accadere se 5 Volt raggiungessero direttamente il cuore di un uomo. L’articolo illustrerà come evitare che ciò acca-da, descrivendo un dispositivo detto trasformatore d’isolamento. Prima però, dobbiamo soffermarci su alcune considerazioni propedeutiche legate al mondo della Sanità, che possono rivelarsi utili a tutti i pro-gettisti in qualunque situazione.

Le reti dati nei locali medici seguono criteri di progettazione particolari, perché tali sono i pazienti rispetto alle persone in buona salute. I locali medici sono sovraffollati di apparecchi elettrici, più propria-mente detti apparecchi elettromedicali, destinati alla diagnosi ed alla terapia. Questi hanno trovato lar-ghissima diffusione, perché il corpo umano ha natura elettrochimica e dunque l’elettricità è il veicolo ideale d’interazione. La maggior parte degli elettromedicali sono collegati sia al paziente (per esempio elettrodi per l’elettrocardiogramma (ECG), l’elettroencefalo-gramma (EEG) o la saturazione d’ossigeno nel san-gue), sia alla rete dati. Nell’uso degli elettromedicali il pericolo può venire sia per mancanza di corrente (la legge prevede l’uso di gruppi UPS e di gruppi elet-

FIGURA 2 Collegamento di un paziente ad un elettromedicale

cutting edge


cutting edge


FIGURA 3a Percorso della corrente di dispersione in condizioni ordinarie

trogeni), sia per una scarica elettrica indesiderata sul paziente. Nel merito della rete dati, la scarica elettri-ca potrebbe nascere dalla dispersione di uno switch, dispersione che potrebbe riversarsi sullo strumento elettromedicale e da questo al paziente, se collegato

tramite elettrodi o altre terminazioni conduttive (Figura 2).

Come aggravante, la dispersione potrebbe capitare quando il paziente è anestetizzato, condizione an-cora più pericolosa sopratutto se gli elettromedicali sovrintendono a funzioni vitali, come la respirazio-ne assistita.Tra tutti i pericoli quello maggiore è costituito dal cosiddetto microshock, una scarica elettrica che raggiunge il cuore o il cervello, per esempio attra-verso l’elettrodo di un pace-maker o un catetere per angioplastica. In questi casi, anche una piccola corrente di dispersione di uno switch può essere fa-tale, e proprio perché piccola e difficile da rilevare. Infatti, mentre in una persona sana in condizioni ordinarie il limite di pericolosità della corrente elettrica stabilito per legge è dell’ordine di 10 mA (milliampere), se tale corrente dovesse raggiunge il miocardio di un paziente in sala operatoria potreb-be indurre la fibrillazione ventricolare e determi-nare la morte: da qui il nome di microshock (Fi-gura 3a). Per gli apparecchi elettrici d’uso comune (lavapiatti, asciugacapelli, switch, computer, ecc.) è ammessa una corrente di dispersione di 0.5 mA perché non è neppure avvertibile in condizioni ordinarie; per tale ragione gli interruttori differen-ziali (i cosiddetti salvavita) installati nelle case sono tarati su questo valore. Ma la corrente che colpisce direttamente al cuore è mille volte più pericolosa di quella che arriva all’estremità di un arto, perché i tessuti tra l’estremità dell’arto ed il cuore fungono da isolante (Figura 3b).

Per quanto detto, una rete dati realizzata a regola d’arte in un’abitazione o in una fabbrica potrebbe essere molto pericolosa e non a norma in un locale sanitario; per questo motivo gli impianti elettrici,

ed in particolare le reti dati nei locali medici, possono essere progettate solo da professionisti iscritti all’albo (DPR 447/91 art.4 comma 1) secondo le norme CEI 0-2, utilizzando negli elaborati esecutivi appositi sim-boli grafici (DPR 447/91 art4 comma 2).

Obiettivo del “network designer” sanitario è realizzare una rete affidabile e che non causi danni da microshock

FIGURA 3b Percorso della corrente didispersione in un paziente collegato ad unelettromedicale

cutting edge


cutting edge


Prima di affrontare la progettazione, che vedremo nel prossimo paragrafo, è bene sapere che i locali medici si classificano in tre gruppi, in base al tipo di apparec-chi elettromedicali impiegati (norma CEI 64-8/7 art. 710.2 5,6,7). Questi tre gruppi sono:

1. Locali di gruppo zero: nei quali non si utilizzano apparecchi elettromedicali con parti applicate al pa-ziente (per esempio un termometro a raggi infrarossi che sfiora solo la fronte del paziente);

2. Locali di gruppo uno: nei quali si utilizzano ap-parecchi elettromedicali con parti applicate esterna-mente al paziente, oppure invasivamente all’interno del paziente con esclusione della zona cardiaca (per esempio un ECG su rete IP);

3. Locali di gruppo due: nei quali si fa uso di elettro-medicali con parti applicate in interventi intracardia-ci o in operazioni chirurgiche (per esempio il catetere di un pace-maker).

Il trasformatore d’isolamento

L’obiettivo del “network designer” sanitario non è solo realizzare una rete affidabile con alta velocità di cifra, bensì anche di non causare danni da micro-shock. I danni, intesi come lesioni al paziente, posso-no nascere quando la rete dati viene collegata diret-tamente al corpo (o tramite l’elettromedicale), come accade con gli ECG che hanno piastrine conduttrici

applicate sulla pelle (skin detector). Per questo moti-vo, è indispensabile che il network designer conosca alcuni principi della fisica e lavori a stretto contatto con l’ingegnere elettrico.Partendo dal presupposto che è impossibile realizza-re una rete dati in grado di garantire l’assenza di dispersioni di corrente, la mossa vincente è fare sì che quando queste avven-gono, non si scarichino sul paziente. Dobbiamo cioè ricreare quella situazione che salva la vita ai piccioni quando si posano su un cavo dell’alta tensione! E dobbiamo utilizzare tale espediente per mettere in sicurezza il paziente. Una volta imparato il trucco possiamo usarlo sempre: nella pratica lo si usa solo quando la legge lo impone, perché la sua attuazione comporta costi aggiuntivi ed il fattore economico è

troppo spesso l’ago della bilancia nella scelta tra un progettista ed un altro. Il trucco sta nell’alimentare tutti gli apparati elettrici del locale sanitario con il trasformatore d’isolamento, uno strumento che disaccoppia (isola) gli elettroni della rete elettrica principale (quella dell’Enel o di al-tro fornitore di energia elettrica, tanto per intenderci) da quella usata nel locale sanitario (Figura 4).

L’avvolgimento primario è collegato alla rete elet-trica cittadina, mentre l’avvolgimento secondario è collegato all’impianto elettrico del locale sanitario. In realtà, il primario viene collegato ad un UPS che a sua volta è a valle del gruppo elettrogeno che è col-legato alla rete elettrica cittadina (Figura 5). I due avvolgimenti sono isolati: tra essi non c’è scambio di elettroni. La corrente alternata che scorre nel-l’avvolgimento primario (220 V / 50 MHz) produce un campo elettromagnetico variabile che genera per induzione la corrente nell’avvolgimento secondario (per approfondimenti è opportuno un ripasso della Legge di Faraday). Otteniamo così un circuito d’ali-mentazione secondario con una differenza di poten-ziale “sospesa”: in tal modo le eventuali dispersioni non si scaricano più verso terra attraverso il paziente. Inoltre, la massa del circuito secondario è collegata all’isolamento del trasformatore.

Reti dati tradizionali vs. reti con trasformatore d’isolamentoÈ istruttivo capire cosa accade nelle reti dati tradizio-

FIGURA 4 Fotografia del trasformatore d’isolamento in uso nel Pronto Soccorso dell’Ospedale di Pesaro

cutting edge


cutting edge


nali e cosa in quelle dotate di trasformatore d’isola-mento. Nelle reti dati tradizionali gli switch sono ali-mentati dalla rete elettrica mediante due conduttori: una fase (solitamente di colore nero, bianco o grigio) ed un neutro (colore blu); inoltre sono collegati a terra da un cavo di colore giallo-verde. Se lo switch si guasta, i 220 V potrebbero disperdersi sulla sua scocca (o peggio sul cavo UTP): chi tocca lo switch chiude con il proprio corpo il circuito verso terra! Il neutro dell’alimentazione elettrica tradizionale è infatti a terra (chi dispone di un tester può verifica-re che benché la tensione sia alternata, uno dei due conduttori del circuito elettrico di casa è a potenziale zero) e così facendo viene attraversato da una corren-te elettrica. Se mettessimo ai nostri piedi un bel paio di zoccoli in legno perfettamente isolanti, il circuito rimarrebbe aperto e saremmo salvi. Per questo moti-vo gli elettricisti usano scale di legno, e per lo stesso motivo i piccioni non vengono arrostiti sui cavi: i 10.000 volt dell’alta tensione non si scaricano sul corpo dei piccioni perché la corrente non ha motivo di scorrere in essi (come è noto, la corrente elettrica è costituita da elettroni che fluiscono dal potenziale più alto a quello più basso, esattamente come l’acqua scorre dalle quote alte verso quelle basse). Ora, non potendo isolare una sala operatoria (che è fatta di mattoni e cemento) o sospenderla nel vuoto, la soluzione più semplice è realizzare una rete elet-trica dedicata al locale medico, isolandola da quella

tradizionale con il trasformatore d’isolamento. In tal modo, una dispersione di corrente che arrivi al cuore di un paziente non lo attraverserà, perché non cercherà di scaricarsi a terra. Infatti, la corrente di dispersione si scaricherà verso il suo neutro, che è collegato al trasformatore d’isolamento e che non passa certamente per il corpo del paziente.Inoltre, tutti i trasformatori d’isolamento sono dotati per legge di un sistema d’allarme acustico e luminoso (una vera sirena posta dentro al locale alimentato dal trasformatore) che avvisa immediatamente dell’esi-stenza di una dispersione, senza peraltro bloccare il flusso di corrente, come fa il salvavita nelle abitazioni (detto tecnicamente “interruttore differenziale”, che analizza costantemente la corrente che esce dalla fase ed entra nel neutro: se c’è una differenza maggiore di una tolleranza prefissata interrompe il flusso di cor-rente. Queste differenze sono dovute alle dispersioni di elettroni che in casi normali non si devono verifi-care, perché tanti elettroni devono uscire da un polo della presa quanti ne devono entrare nell’altro). Questo accorgimento è indispensabile per non far mancare l’alimentazione ad apparecchi elettromedi-cali di supporto alle funzioni vitali. La sirena è tacita-bile, la luce no: in tal modo i chirurghi hanno tempo per continuare ad operare e chiamare immediata-mente l’elettricista di turno per riparare il guasto.Nei locali sanitari di gruppo due (sale operatorie, terapie intensive, UTIC, ecc.), le norme CEI EN

FIGURA 5 Schema di collegamento tra impianto elettrico e rete cittadina

cutting edge


cutting edge


61558-1 prescrivono che i trasformatori d’isolamento siano raffreddati ad aria, abbiano una tensione non superiore a 250 V, abbiano un doppio isolamento rinforzato tra gli avvolgimenti e fra questi e le masse dall’apparecchiatura, abbiano una potenza compresa tra 0,5 KvA e 10 KvA. Inoltre, consigliano d’installa-re un sensore della temperatura all’interno del cabi-net del trasformatore, in grado di attivare un allarme acustico.

FIGURA 6 Schema di collegamento tra impianto elettrico e rete cittadina

FIGURA 7 Fotografia di due trasformatori d’isolamento con i relativi quadri elettrici.

Isolare la rete dati dalla LAN

Abbiamo detto che nei locali medici di gruppo 2 dob-biamo collegare gli apparecchi elettrici al trasforma-tore d’isolamento per evitare lesioni al paziente, ma i lettori più attenti avranno notato che c’è ancora un problema: la rete dati del locale sanitario deve essere collegata anche al resto dell’ospedale tramite la LAN

cutting edge


cutting edge


e questo collegamento fa venir meno l’isolamento.Per risolvere il problema ci sono due soluzioni: o ri-nunciamo a collegare la rete dati del locale sanitario alla LAN, oppure la colleghiamo tramite la fibra otti-ca. Visto che la prima soluzione è spesso impraticabile (perchè nelle sale operatorie si ha la necessità di avere dati in tempo reale provenienti dal laboratorio d’ana-lisi, dalla sala TAC oppure di richiedere la “second opinion” con il teleconsulto via Internet), si attua la seconda soluzione utilizzando switch con una (o due per ridondanza) porte in fibra ottica (le GBIC) che disaccoppiano il segnale elettrico da quello ottico. La fibra di vetro trasporta solo fotoni che non possono in nessun caso scaricare a terra l’eventuale corrente derivante da una dispersione e d’altro canto non pos-sono trasferire sul paziente un’eventuale corrente di dispersione proveniente dalla LAN.

Come disaccoppiare le reti multiutente

In una sala operatoria con un solo letto è relativa-mente semplice disaccoppiare la rete elettrica e la rete dati interna da quella esterna, usando il trasformatore d’isolamento ed uno switch con unlink in fibra. Il problema si complica quando si devono realizza-re impianti elettrici e reti dati in sale con più letti, come le terapie intensive o il pronto soccorso. In questo caso ci sono due soluzioni: o si usa un unico trasformatore d’isolamento per tutta l’area, oppure si realizzano delle aree elettricamente isolate con un trasformatore per ogni area, facendo in modo che la parte elettrica afferente ad un trasformatore sia isola-ta da quelle afferenti agli altri (Figura 6).

Avendo i trasformatori un amperaggio massimo fis-sato per legge, ed essendo tanti gli elettromedicali in uso, quando gli ospedali non hanno problemi di budget usano un trasformatore per ogni letto (crean-do tante aree quanti sono i letti), ma quando i soldi mancano al progettista è richiesto di accorpare elet-tricamente due o tre letti. La legge stabilisce che at-torno al paziente si deve creare un’area elettricamente isolata con un margine di 1,5 metri in orizzontale e 2,5 metri in verticale. La distanza orizzontate può essere usata come riferimento per posizionare le pre-se a muro, mentre la distanza verticale è importante perché spesso i pazienti sono monitorati da telecame-re a circuito chiuso poste sopra i letti e collegate ad uno switch dedicato al segnale video: se le webcam sono poste a più di 2,5 metri dal paziente possiamo usare un unico switch in rame, mentre se il soffitto è più basso, dobbiamo applicare le medesime consi-derazioni fatte per gli elettromedicali (sopratutto se il circuito TVCC è PoE). Riassumendo, in ogni area elettricamente isolata dobbiamo installare come mi-nimo uno switch con uplink in fibra, un trasformato-re d’isolamento ed un quadro elettrico dedicato con sezionatori di fase e differenziali (Figura 7).Quest’ultima considerazione è fondamentale, perché se collegassimo due aree afferenti a trasformatori d’isolamento diversi con cavi in rame su un unico

Note Biografiche

Alberto Rosotti è consigliere dell’Ordine degli Ingegneri di Pe-saro. Attualmente fa parte dello staff Sistemi Informativi del-l’Ospedale della sua città.

switch avremmo perso l’isolamento elettrico: la corrente di dispersione di un trasformatore potrebbe riversarsi sull’altro tramite lo switch, passando per il paziente che farebbe da ponte, ed avremmo perso l’effetto “piccione”.Un metodo alternativo, per evitare che la rete dati infici l’isolamento elettrico senza usare uno switch con porte in fibra GBIC per ogni trasformatore, è concentrate tutta la rete dati su un unico switch, con sole porte in fibra ottica. Questo comportamento potrebbe essere giustificato anche dalle maggiori pre-stazioni della rete in fibra rispetto a quella in rame. Ci sono però quattro svantaggi che lo rendono scon-veniente da adottare:

1. La fragilità dei cavi in fibra, che mal si prestano a situazioni d’emergenza in cui è preferibile disporre di cavi in rame flessibili, in grado di seguire gli stru-menti, di essere calpestati o ritorti attorno o dentro gli stativi (bracci o snodo che scendono dal soffitto);

2. l’obsolescenza di alcuni apparecchi elettromedica-li, che necessariamente richiedono il cavo in rame;

3. la praticità e la sicurezza dall’innesto RJ45 a baio-netta, rispetto alla boccola della fibra ottica;

4. L’elevato costo dello switch in fibra, che oltretutto è necessario acquistare in due esemplari per ottenere la ridondanza. È pur vero che i punti uno e due si potrebbero ri-solvere dotando ogni letto di un trasduttore optoe-lettronico (convertitore di segnali da ottico a rame e viceversa), ma questi dovrebbero essere alimentati dal trasformatore d’isolamento e costituirebbero un altro “point of failure”, che si tende ad evitare negli ambienti sanitari.

Conclusioni

Può capitare che giungano in pronto soccorso pazien-ti, pensando che ad accogliergli ci sia lo staff di ER, con George Clooney in camice bianco. Ed essendo caricate di un notevole stato d’ansia, non tollerano ri-tardi e pretendono d’essere visitate subito, senza con-siderare che la fila viene servita per urgenza, non per ordine d’arrivo. Inevitabilmente, infermieri e medici vengono criticati, e qualcuno da troppo in attesa im-preca contro la malasanità. Permettetemi di spezzare una lancia a favore degli infermieri; quegli “angeli” che quando si guasta una presa elettrica si rifiutano di usare quella attigua, facendo perdere le staffe a chi pensa si tratti della solita incomprensibile inefficien-za pubblica: stanno solo tentando di salvarci la vita, e i network designer ne comprendono i motivi!

solutions


solutions


Ogni azienda o organizzazione ha ormai al proprio interno numerosi applicativi softwa-re, utilizzati sia per le attività inerenti al core business, sia nei servizi, come ad esempio la gestione della contabilità o del personale. Se nel passato, specie per le aziende di dimen-sioni minori, la manutenzione e l’aggior-namento di questi applicativi era affidata a fornitori vicini nel territorio che prestavano la loro attività recandosi fisicamente dal cliente, oggi la tecnologia permette di lavora-re da remoto con altrettanta efficacia. Conce-dere un accesso esterno ai server è comunque un’operazione che pone seri interrogativi in termini di sicurezza informatica. L’approccio di riporre cieca fiducia nel fornitore incarica-to della manutenzione espone a rischi troppo alti: vanno quindi individuate soluzioni architetturali in grado di limitare al minimo indispensabile le attività disponibili e i ser-ver visibili attraverso l’accesso remoto.

Creazione di una sottorete

Un paio di mesi or sono, ci è stato consegnato un nuovo server, denominato Efforts, su cui era installata un’applicazione molto impor-tante per il core business. Improvvisamente, è arrivata dai fornitori addetti alla manuten-zione la richiesta di poter accedere al server attraverso Internet, per le necessarie attività

di manutenzione e di taratura. Si è poi appu-rato che in effetti richiedevano il controllo completo della macchina attraverso una ses-sione di desktop remoto con un utente del gruppo Administrators! La dirigenza, informata dei potenziali ri-schi, ha approvato la richiesta per tutelare l’investimento effettuato, e mi ha affidato l’incarico esecutivo, chiedendomi di pren-dere tutte le misure necessarie per tutelare la sicurezza.Ho colto l’occasione per cercare di sistemare anche un altro server, denominato Luxp8, fino a quel momento posizionato all’interno della LAN ed accessibile da remoto da un’al-tra azienda fornitrice attraverso una linea telefonica dedicata ed un modem. Il primo passo è stato isolare le macchine in telemanutenzione dal resto della LAN creando una sottorete dedicata, secondo lo schema logico riportato in Figura 1. Esisteva già una DMZ, riservata ai web server, ma ho voluto creare una nuova area, la DMZ_2, sia per avere un controllo più rigido sulla comu-nicazione tra le varie interfacce del firewall (abilitando solo le porte indispensabili per i servizi di interesse) sia per evitare che troppi server potessero essere compromessi in un colpo solo in caso di attacco. Ho iniziato a cercare su Internet della docu-mentazione relativa ad un dominio Windows diviso in sottoreti diverse ed ho trovato due

Realizzare un accesso remoto trami-te VPN è un compito concettualmente semplice ma che può riservare amare sorprese e noiosi inconvenienti nella fase di messa a punto. Questo articolo è un resoconto dettagliato di un caso reale di media complessità per la cui risoluzione sono stati necessari studio, ricerca, perseveranza ed intuito.

Accesso esterno sicuro: sottoreti Windows e VPN

Ü di Filippo Martinelli

solutions


solutions


documenti:

· Active Directory in Networks Segmented by Firewalls [1] · How to configure a firewall for domains and trusts [2]

Il primo, che dal titolo sembrava molto prometten-te, dopo una breve ed incompleta trattazione delle porte e dei protocolli da abilitare sul firewall per permettere il colloquio dei vari client con il Domain Controller, si è rivelato un documento sull’utilizzo e la configurazione di IPSEC per stabilire canali di comunicazione sicuri. Non l’ho giudicato utile per le seguenti considerazioni:

1. L’utilizzo di un semplice switch eviterà di poter catturare ed analizzare il traffico di rete delle macchi-ne presenti; inoltre, essendo fisicamente inaccessibile ad estranei, non sarà possibile effettuare attacchi del tipo “Man in the middle”, in cui un computer intruso cerca di assumere l’identità di un membro della rete.

2. Un utente non autorizzato che riuscisse a prendere il controllo di una macchina non sarebbe in alcun modo ostacolato dal fatto di aver protetto parte del traffico con IPSEC.

Dopo aver predisposto la sottorete DMZ_2 ho abili-

tato sul firewall le porte ed i protocolli secondo quan-to riportato in Tabella 1, cominciando a fare degli esperimenti. I risultati, come mi aspettavo, non sono stati subito positivi.Come spiegato in [2] è necessario permettere le richie-ste ICMP verso i Domain Controller, in quanto que-sto protocollo è utilizzato dal Sistema Operativo per determinare se il link è “lento” o “veloce”. Inoltre, le group policy non venivano processate: il meccanismo implementativo prevede infatti richieste sulla porta 135 (RPC) con allocazione dinamica di un’altra porta per creare il canale di trasmissione.In base alle indicazioni contenute in How to con-figure RPC dynamic port allocation to work with firewalls [3] ho allora modificato il registry dei Domain Controller, in modo da restringere il range di allocazione dinamica delle porte ed abilitare solo tale range sul firewall. Raggiunto il corretto funzionamento e consideran-do sia la complessità introdotta, sia il numero e la tipologia di porte che avevo dovuto aprire tra le due sottoreti, ho cominciato a soppesare i vantaggi e gli svantaggi di questa soluzione rispetto a togliere dal dominio le macchine in DMZ_2. Le mie considera-zioni sono riportate nella Tabella 2 ed alla fine, visto che le macchine nella sottorete erano soltanto due e le configurazioni non troppo complesse, ho giudicato più conveniente separarle dal dominio per poter ope-rare un controllo più rigido e selettivo nelle comuni-

FIGURA 1 Architettura logica del sistema diviso in sottoreti

solutions


solutions


TABELLA 1 Regole di transito tra DMZ_2 e le altre sottoreti

Regole di transito tra Lan e Dmz_2

Funzione Direzione Protocollo e porte Note

Gestione antivirus Dmz_2 -> Lan Tcp 80 e 4343 Accesso limitato al solo DC

Utilizzo di WSUS Dmz_2 -> Lan Tcp 8080 Accesso limitato al solo DC

Accesso a SqlServer Dmz_2 -> Lan Tcp 1433 Limitato alla coppia luxp8, lu2003se1

Accesso a SqlServer Lan->Dmz_2 Tcp 1433 Qualsiasi client in Lan

Cartelle condivise Lan->Dmz_2 Tcp 445, Tcp 139, Udp 137, Udp 138

Accesso alle cartelle condivise anche dal client legacy Win98

Richiesto da antivirus Dmz_2 -> Lan ICMP Limitato al solo DC

Richiesto da antivirus Lan->Dmz_2 Tcp 58662

Regole di transito tra Dmz_2 e Dmz


Trasferimento file sui web servers

Dmz_2 -> Dmz Ssh, ftp e http Limitata ai soli web servers

Accesso internet Dmz_2 -> Dmz Tcp 8080 Accesso al proxy server

Regole di transito tra Dmz_2 ed interfaccia di uscita


Upload e download files Dmz_2 -> out ftp

Risoluzione nomi Dmz_2 -> out dns

Servizio ora Dmz_2 -> out ntp

cazioni con la LAN.

Rimuovere una workstation o un server dal dominio

La rimozione di una workstation dal dominio è una operazione un po’ più complessa di quanto possa sembrare (se si vogliono fare le cose a modo). L’utente di dominio, che fino a quel momento ha operato sulla macchina, possiede sia dati propri sia configurazioni personalizzate delle varie applicazioni: per una tran-sizione indolore è bene operare una copia del profilo su un nuovo utente locale, appositamente creato se-condo la procedura descritta e spiegata nel Riquadro 1. Inoltre, l’utente può aver creato, e quindi essere il proprietario (owner) di altri file presenti sul disco ri-gido; o può aver cambiato qua e là le ACL (i permessi di accesso) per evitare che altri potessero vedere o modificare documenti riservati: nel momento in cui la macchina viene rimossa dal dominio, l’utente non sarà più riconosciuto come utente valido! Ma il suo SID (security identifier) continuerà ad esistere nelle ACL, senza la possibilità di risolverlo in un nome intelligibile. Sebbene l’amministratore locale abbia

la possibilità di prendere il possesso dei file e di mo-dificare le ACL, qualsiasi sia la loro configurazione di partenza (scongiurando quindi il pericolo di non poter più accedere a dati di interesse), è possibile pre-venire l’insorgere di simili problematiche, evitando così la comparsa di misteriosi numeri del tipo

s-1-12345-6789 …

(ossia i SID di utenti non più riconosciuti dal sistema) nella finestra delle proprietà (scheda dei permessi). Utilizzando subinacl, un tool distribuito e supportato da Microsoft, è possibile fare una scansione di tutto il contenuto di un disco e sostituire, nelle ACL, il SID di un utente con quello di un altro. Nel caso in esame, da shell DOS si può lanciare un comando del tipo:

C:> subinacl /outputlog=out.doc /errorlog=err.doc /subdirec \\nomeHost\c$\*.* /replace=nomeDominio\utenteDominio=nomeHost\ utenteLocale /pathexclude=”Documents and Settings”

Dalla LAN è necessario accedere al contenuto di

solutions


solutions


FIGURA 2 Finestra Gestione nomi utente e

password archiviati in sottoreti

Luxp8 ed Efforts (Figura 2), in modo del tutto traspa-rente a chi è seduto davanti alla workstation.

Risoluzione dei nomi

Ognuno di noi sa bene quanto sia più facile collegarsi alle risorse di rete utilizzando il nome mnemonico del server remoto piuttosto del corrispondete indiriz-zo IP: ciò, in una rete Windows, è reso possibile sia dal protocollo NETBIOS (che, quando abilitato, ese-gue un broadcast del nome della macchina in modo che sia conosciuto e registrato dagli altri computer), sia dal DNS, componente fondamentale all’interno di un dominio basato su Active Directory. Visto che i server in DMZ_2 non fanno parte del dominio, il DNS integrato in Active Directory non registra au-tomaticamente i loro nomi; né è possibile risolverli tramite NETBIOS, visto che i pacchetti broadcast non transitano tra sottoreti diverse. È perciò utile un elenco di tutte le necessità relative alla risoluzione di nomi per trovare una soluzione idonea:

1. Dalla LAN è necessario accedere ai server in DMZ_2: per farlo, è sufficiente aggiungere a mano dei record host nel DNS.

2. Il server Efforts, per le sue elaborazioni, deve po-tersi collegare ad una serie di server FTP in Internet,

cartelle condivise in DMZ_2: allo scopo si creano due nuovi utenti locali, chiamiamoli lettore e scrit-tore, con permessi, rispettivamente, di sola lettura e lettura/scrittura sulle aree in condivisione. Tramite la gestione delle password di rete, disponibile in Win-dows XP, si configurano su alcune macchine della LAN le credenziali per poter autenticarsi sui server

RIQUADRO 1 Passi consigliati per la copia di un profilo

La copia del profilo consiste nel duplicare il contenuto del-la cartella dell’utente X presente nella directory Documents and Settings in quella dell’utente Y. In questo modo Y si tro-verà ad avere le stesse chiavi di registro HKey_Current_User di X, corrispondenti ad impostazioni personalizzate del Si-stema Operativo e degli applicativi, lo stesso desktop, gli stessi documenti, la stessa configurazione di Internet Explo-rer e dei Preferiti, lo stesso menu di avvio. I passi da seguire sono i seguenti:

1. È conveniente, come primo passo, eliminare il contenuto della cache di Internet Explorer dell’utente X in modo da aver meno file da copiare.

2. Occorre accedere alla macchina utilizzando l’utente Y: ciò creerà la cartella personale dell’utente Y.

3. Riavvio della macchina: questo passo evita di trovare profili “bloccati” perché il loro rilascio non è stato gestito correttamente dal Sistema Operativo alla disconnessione dell’utente. La pratica insegna che è un passo quasi sempre indispensabile.

4. Si accede alla macchina con un terzo utente che abbia di-ritti di amministratore e si copia il profilo di X nella cartella personale di Y, ricordandosi di assegnare ad Y il possesso di tali file.

5. La necessità di agire con il terzo utente è legata al fatto che altrimenti alcuni file personali sarebbero bloccati perché in uso da parte del Sistema Operativo.

Ssubinacl è un tool supportato da Mi-crosoft per sosti-tuire, nelle ACL, il SID di un utente con quello di un altro.

solutions


solutions


TABELLA 2 Vantaggi e svantaggi di un dominio esteso in DMZ_2

tramite il rispettivo nome pubblico. Nelle proprietà TCP/IP della connessione di rete basta allora impo-stare i DNS forniti dal provider internet.

3. Sia Efforts, sia Luxp8, si collegano ad una serie li-mitata di macchine della DMZ e della LAN. Tramite il file hosts (memorizzato nella directory %windir%\system32\drivers\etc) è possibile inserire un elenco di associazioni indirizzo IP/nome mnemonico. Ov-viamente, tutte le macchine dell’elenco devono avere un IP statico; la flessibilità garantita dal DNS o da NETBIOS in combinazione con il DHCP che si ha per i client della LAN non può essere raggiunta.

Da quanto esposto sinora, si evince che con configu-razioni non troppo impegnative è possibile evitare che le macchine in DMZ_2 debbano accedere al DNS nella LAN. In tal modo, le policy di transito sul firewall possono essere ristrette in modo da garantire un maggior isolamento tra le due aree.

Condivisione file

Come si è accennato prima, entrambe le macchine in DMZ_2 hanno delle cartelle condivise che devono essere visibili dalla LAN. Questo servizio è disponi-bile sulla porta 455 che quindi dovrà essere aperta sul firewall in modo unidirezionale, da LAN a DMZ_2. Dopo aver effettuato le necessarie configurazioni, il primo tentativo di instaurare una connessione dalla LAN a Luxp8 è miseramente fallito, mentre funzio-nava correttamente da Efforts, posizionato nella sua stessa sottorete. Era forse sbagliata la regola imposta-ta sul firewall? In simili circostanze, per isolare il problema, è utile eseguire una cattura dei pacchetti che transitano in rete, per poi procedere ad una loro analisi: pertanto, ho configurato lo switch in modo che replicasse il traffico di interesse su una porta, porta a cui ho con-

nesso uno sniffer (ethereal). Così facendo, è risultato che le richieste di connessione arrivavano corretta-mente a Luxp8 dalla LAN, ma non veniva data alcu-na risposta. Che fare? La prova effettuata da Efforts non lasciava dubbi sul corretto funzionamento del servizio di condivisione; così come quella con lo sniffer evidenziava che il pro-blema era su Luxp8.Su quest’ultimo, era attivo il firewall integrato di Windows e per scrupolo ne ho abilitato il log: è ri-sultato che era proprio questo componente a scartare i pacchetti provenienti dalla LAN, a causa di un pa-rametro di configurazione che fino a quel momento non avevo mai notato. Il servizio era sì aperto alle ri-chieste esterne, ma solo a quelle provenienti dall’am-bito locale (Figura 3); quando si lavora con un’unica sottorete, come nel caso di piccole e medie reti da ufficio, queste problematiche non emergono, e posso-no disorientare il sistemista quando si manifestano. Un’altra sorpresa è venuta da un client legacy con sistema operativo Windows 98, dotato di una vecchia applicazione di visualizzazione che utilizza come sorgente dati un file su Luxp8. Il servizio di con-divisione file utilizza le porte NETBIOS 137, 138 e 139, e quindi non è rimasta altra scelta che aprirle sul firewall. Per inciso, aggiungo che i sistemi operativi Windows 2000 e Windows XP (proprio per compati-bilità con le precedenti versioni) hanno abilitato di default anche le porte NETBIOS e quindi gestiscono in modo trasparente all’utente le richieste provenien-ti da computer con Win98: questo comportamento può essere modificato tramite le proprietà avanzate del protocollo TCP/IP nella scheda WINS.

Gestione degli aggiornamenti di sistema

Gli aggiornamenti critici e di sicurezza del sistema operativo vengono approvati ed installati tramite

Unico dominio Dmz_2 fuori dal dominio

Tramite GPO comuni a tutto il dominio vengono impostati alcuni parametri fondamentali come il proxy per l’accesso internet, la modalità di lavoro del servizio di aggiornamento automatico (che nel caso in esame utilizza WSUS) ecc.

Le configurazione devono essere replicate a mano, eventualmente importando opportune chiavi di registro.

Alcune GPO mappano come unità di rete delle cartelle condivise presenti su alcuni server e contenenti dati riservati agli utenti della lan. La loro applicazione in dmz_2 è quindi solo dannosa.

Accesso a cartelle condivise con le credenziali utilizzate in fase di login.

Per accedere a cartelle condivise su macchine in dmz_2 è necessario fornire le credenziali di un utente locale.

L’ora corrente è la stessa su tutte le macchine

La risoluzione dei nomi è affidata a DNS integrati in active directory che registrano automaticamente i nomi delle macchine in dmz_2.

Occorre predisporre un idoneo sistema di risoluzione dei nomi in dmz_2 e registrare manualmente i nomi delle macchine sul dns del dominio.

solutions


solutions


FIGURA 3 Finestre per l’amministrazione del firewall di Windows

WSUS, uno dei prodotti gratuiti sviluppati da Mi-crosoft per soddisfare le esigenze di amministrazione centralizzata degli aggiornamenti per piccole e medie reti. I client sono istruiti ad avvalersi di WSUS trami-te un opportuna GPO, che stabilisce sia le modalità di aggiornamento sia l’indirizzo del server e la porta su cui lavora. Sebbene WSUS sia installato su un Domain Controller, può comunque lavorare senza appoggiarsi ad Active Directory, e quindi è in grado di gestire anche computer che non fanno parte del dominio, come quelli in DMZ_2.Oltre ad aprire le porte necessarie sul firewall, oc-corre anche configurare in modo opportuno Luxp8 e Efforts poiché nel loro caso non sono utilizzabili le GPO del dominio. I parametri con cui lavora Windows Update sono però facilmente rintracciabili all’interno del registro, sotto la chiave

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ WindowsUpdate

si possono quindi esportare su un file .reg ed impor-tarli da quest’ultimo sulle macchine in DMZ_2.

Installazione dell’antivirus

L’antivirus utilizzato in azienda è OfficeScan di TrendMicro, soluzione in architettura client-ser-ver che permette il controllo centralizzato delle impostazioni, dell’aggiornamento e del monitoraggio delle infezioni. Non sono riuscito a trovare documen-ti che descrivessero il caso in cui il server si trova in

una sottorete diversa rispetto ai client e quindi ho proceduto con le conoscenze pregresse, e con un ap-proccio “per induzione ragionata”. OfficeScan ha la veste di una Web application che si appoggia ad IIS e rende disponibile, tramite collegamento HTTPS sulla porta 4343, sia un’interfaccia amministrativa sia l’installazione, tramite il browser, della parte client. Quest’ultima recupera gli aggiornamenti dei pattern dei virus collegandosi alla porta 80 del server e vie-ne interrogata sullo stato corrente tramite la porta 58662. Da esperienze precedenti già sapevo che il firewall integrato di Windows non veniva corret-tamente configurato nei computer dotati di doppia scheda di rete (situazione tipica di workstation non recentissime), in cui la LAN integrata nella scheda madre non garantisce le stesse prestazioni degli appa-rati di rete con cui colloquia. Infatti, durante l’instal-lazione OfficeScan si preoccupa sì di aprire la porta del servizio alle connessioni esterne, ma lo fa sulla scheda di rete sbagliata! Ed occorre intervenire per replicare la configurazione sulla interfaccia Ethernet effettivamente utilizzata. Purtroppo, anche dopo aver compiuto questa operazione, controllando dalla con-sole di amministrazione, le macchine in DMZ_2 ve-nivano segnalate come spente, situazione legata alla mancata connessione sulla porta 58662.Ho quindi controllato il log del firewall di rete, per vedere se venivano bloccati dei pacchetti: ma l’unica cosa che ho notato erano delle echo-request dirette al server antivirus; ho però avuto la sensazione che il server, per alcune operazioni, usasse l’IP della mac-china client. Il servizio di risoluzione dei nomi, già

solutions


solutions


FIGURA 4 Abilitazione protocollo NETBIOS

descritto in precedenza ed impostato manualmente, mancava di una zona di ricerca inversa per la DMZ_2, ovvero poteva solo associare un IP ad un nome, ma non viceversa. Ho allora fatto una prova creando tale zona all’interno del DNS sul Domain Controller e reinstallando OfficeScan su Luxp8: questa volta, fi-nalmente, le cose hanno funzionato a dovere!

Creazione della VPN tra firewall e road warrior

A questo punto, avevo finalmente una sottorete suf-ficientemente isolata, in grado di comunicare con la LAN solo per un ristretto numero di servizi essenzia-li. Il passo successivo è stato realizzare una VPN che permettesse di accedere dall’esterno alla DMZ_2. Il materiale che avevo a disposizione era il Cisco PIX 515 E in release 6.3(4); ho allora scaricato l’ultima versione del client VPN per il sistema road-warrior, nome evocativo con cui è denominato il laptop che accede “dalla strada” alla rete aziendale ed ho iniziato a fare delle prove. Tramite il wizard, disponibile nella interfaccia Web di amministrazione del firewall, ho potuto creare una semplice VPN di cui ho subito ve-

rificato con soddisfazione il corretto funzionamento. Se però si hanno delle esigenze particolari (o si vuole un controllo molto preciso di cosa avviene) non si può prescindere dalla programmazione tramite riga di co-mando e dallo studio attento del ma-nuale. I requisiti minimi che dovevo soddisfare erano i seguenti:

1. Dopo aver visto molti “post-it” attaccati ai monitor con username e password ho tremato all’idea che una simile situazione, al di fuori di ogni controllo, potesse verificarsi anche presso il fornitore a cui concedevamo un accesso esterno. È stato questo uno dei motivi per cui ho scelto di utilizzare l’autenticazione tramite i certificati digitali.

2. L’accesso esterno doveva essere appositamente loggato e limitato esclusivamente al server Efforts in DMZ_2.

3. L’algoritmo di crittografia doveva dare garanzie maggiori rispetto al DES, utilizzato di default sul PIX 515: tramite un apposito codice di attivazione, richiedibile sotto certe restrizioni tramite un form sul sito web del produttore, ho abilitato il 3DES.

Senza scendere troppo nei dettagli dei comandi e della loro sintassi, descritti

in modo sintetico e chiaro in [6], descriverò qui di seguito gli aspetti non adeguatamente trattati nella documentazione disponibile, che mi hanno riservato diversi grattacapi.

In primo luogo, tutti gli esempi che si trovano in rete fanno uso del comando:

sysopt connection permit ipsec

che quindi sembra indispensabile. Questo comando, permette al traffico proveniente dal peer con cui è sta-to creato il tunnel VPN di attraversare il firewall con accesso incondizionato a tutte le sottoreti; e quindi non soddisfa i requisiti minimi di sicurezza prefis-sati. L’unica alternativa che ho trovato è utilizzare una apposita access-list di ingresso che permetta il transito di pacchetti originati e diretti ad un ristretto gruppo di indirizzi IP. Questa soluzione permette an-che di registrare l’evento nel file di log, ma ho dovuto testarla a fondo, prima di ritenerla valida e sicura, in quanto, a prima vista, potrebbe permettere l’ingresso di traffico non appartenente alla VPN. In realtà, una volta creato il tunnel, al road warrior viene assegnato un indirizzo IP privato appartenente ad un pool che è

solutions


solutions


possibile specificare: anche sfruttando tale indirizzo per un possibile attacco è estremamente improbabile che i pacchetti di risposta trovino la strada del ritor-no, visto che nel loro tragitto incontreranno router che non sanno dove effettuare l’instradamento. Inol-tre, là dove viene definita la “mappa dinamica”, si indica, tramite un’altra access-list, a quali pacchetti verrà applicata; e ciò determina lo sbarramento di eventuale traffico che soddisfa la regola e che sia ricevuto fuori dal tunnel IPSEC. Un’altra opzione, descritta in modo non proprio chiaro, è quella rela-tiva allo split-tunnel: è utilizzato per permettere al road-warrior di accedere ad un insieme di indirizzi Internet, per i quali il traffico verrà instradato in modo da bypassare il tunnel VPN. Si tratta comunque di una complicazione non richiesta nel caso specifico e che può rappresentare una potenziale minaccia per la sicurezza, in quanto un malintenzionato che da Internet prendesse il controllo remoto del road-war-rior si ritroverebbe a poter operare, tramite la VPN, sui server aziendali.

Autorità di certificazione

Sui server di casa Microsoft può essere facilmente installato ed attivato il servizio per la emissione e ge-stione di certificati digitali; ma affinché possa intero-perare con gli apparati Cisco è necessario il supporto per SCEP, come descritto in [5]. Per verificare che sia operativo, da Internet Explorer si accede alla URL

http://nome_del_server/certsrv/mscep/mscep.dll

e se tutto funziona correttamente verrà riportato un codice che sarà poi utilizzato durante la programma-zione del PIX. Andando ad indicare la CA Microsoft nella configurazione del firewall, non basta indicare l’indirizzo IP del server, ma occorre indicare l’indi-rizzo completo del servizio nel seguente modo

ip_server:/certsrv/mscep/mscep.dll

Nei passi successivi verrà inserito il codice trovato in precedenza con il browser e utilizzando la console di

autorità di certificazione sarà possibile trovare la ri-chiesta in attesa di approvazione ed emettere il corri-spondente certificato. Anche il road warrior necessita di un certificato, ed il client VPN, se in grado di rag-giungere il server CA, può richiederlo direttamente, oppure se ne può importarne uno creato “a mano”.

Conclusioni

In questo articolo, al di là degli aspetti prettamente tecnici, ho voluto mettere in evidenza come spesso il sistemista debba risolvere problemi legati alla scarsa documentazione disponibile su apparati e applicativi. Lo studio del materiale disponibile, pur necessario, si rivela spesso molto dispendioso per trovare informa-zioni che siano effettivamente utili e quasi mai indica una soluzione direttamente applicabile. In molti casi l’esperienza può dare una mano, e anche gli strumen-ti di analisi e debugging possono venire in soccorso, ma occorre anche un forte intuito, tenacia, e la deter-minazione a capire come funzionano le cose, talvolta dovendo ricorrere a prove e a esperimenti mirati.

Bibliografia

[1] “Active Directory in Networks Segmented by Firewalls”, Microsoft Knowledge Base, http://www.microsoft.com/downloads/details.aspx?FamilyID=c2ef3846-43f0-4caf-9767a9166368434e&DisplayLang=en [2] “How to configure a firewall for domains and tru-sts”, Microsoft knowledge base, http://support.microsoft.com/kb/179442/en-us[3] “How to configure RPC dynamic port allocation to work with firewalls”, Microsoft knowledge base, http://support.microsoft.com/kb/154596/en-us[4] “Panoramica dei servizi e requisiti per le porte di rete per il sistema server Windows”, Microsoft Knowledge Base, http://support.microsoft.com/kb/832017/it[5] “Setting Up a VPN that Uses Certificates”, artico-lo su WindowsItPro, http://www.windowsitpro.com/Articles/ArticleID/49738/49738.html?Ad=1[6] “Configurare Vpn ipsec sul PIX”, articolo su Openskills, http://openskills.info/infobox.php?ID=806[7] “Configuration guide for pix 515 6.3”, documen-tazione tecnica Cisco, http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_configuration_guide_book09186a0080172852.html

Note Biografiche

Filippo Martinelli, si è laureato a Pisa in Ingegneria Informatica nel 1999. Ha lavorato in Marconi dove si è occupato di protocolli ed integrazione software ed in Autostrade per l’Italia dove ha sviluppato applicazioni Web. Al momento svolge attività sistemistica e di sviluppo software presso un ente pubblico.

Sui server Windows per rendere intero-perabile il servizio dei certificati digitali con gli apparati Ci-sco è necessario sia abilitato il supporto per SCEP.

Reportage


Reportage


Plone è un Content Management System, scritto in Python, basato sulla piattaforma Zope. È riconosciuto da molti come leader nell’ambito degli strumenti Open Source orientati alla gestione dei contenuti, ed è molto apprezzato, anche se confrontato con alternative a licenza chiusa. Plone e la sua comunità hanno oltre cinque anni di vita, e questo la dice lunga in termini di robustez-za e qualità: cinque anni fa difficilmente ci si riferiva ai CMS come a strumenti di lavo-ro diffusi e riconosciuti. Plone è tutelato da una fondazione, la Plone Foundation, che garantisce la qualità del codice, longevità al progetto, e il disaccoppiamento rispetto agli interessi dei singoli partecipanti al progetto. Uno degli strumenti fondamentali di cui la comunità si è dotata da lungo tempo, per cre-scere e per far crescere la tecnologia Plone, è proprio il meccanismo degli sprint.

Cos’è uno sprint?

Gli sprint, ispirati da tecniche di sviluppo teorizzate in ambito agile programming, ven-nero introdotti nel mondo Zope come sessio-ni di sviluppo di due o tre giorni, durante i quali gli sviluppatori lavorano in uno stesso ambiente fisico, in coppia o a piccoli gruppi, concentrandosi su uno specifico obiettivo. In particolare, gli sprint furono sperimentati durante le fasi iniziali dello sviluppo di Zope 3, che rispetto a Zope 2 è stato fin dall’inizio

un prodotto comunitario e molto meno lega-to ai condizionamenti di Zope Corporation; pertanto molto più bisognoso del supporto di un gruppo di lavoro coeso. Dopo i primi mesi in cui Plone veniva seguito solo da po-chi “fedelissimi”, attenti alla materia, si deci-se di seguire la via degli sprint, non solo con il fine di produrre codice. Uno Sprint Plone è spesso organizzato desi-gnando un responsabile (coach), che ne assu-me la guida. Il coach fissa l’agenda, usa una lavagna per tracciare le attività e fa in modo che lo sviluppo proceda. Solitamente, le pri-me ore di uno sprint sono dedicate all’orien-tamento dei partecipanti: fissare gli obiettivi, decidere chi fa cosa, fare in modo che tutti possano accedere al server SVN delle versio-ni del software, ecc. Chiaramente, Plone non è solo tecnologia, ma è anche un prodotto utilizzabile di per sé. Ciò significa che agli Sprint Plone non accedono solo gli sviluppatori, ma anche per-sone con una minore preparazione tecnica che possono dedicarsi ad attività comunque essenziali: testare l’applicazione, scrivere la documentazione, e anche solo testimoniare ai non presenti cosa è stato fatto. In questo modo, figure meno “tecniche”, e anche alle prime armi, possono affiancare dei veri guru e apprendere in modo rapido ed efficacissi-mo, nel breve periodo di tempo a disposizio-ne, una quantità enorme di informazioni.

Perché Sorrento

Un ulteriore molto utile per offrire il proprio apporto alla comunità consiste nel contri-buire finanziariamente agli sprint: spon-

Sorrento capitale “plonista” per una settimana. A cavallo tra Marzo e Aprile, per una settimana, la penisola sorrentina ha ospitato uno degli eventi centrali per il 2007 della comunità Plone internazionale: il Sorrento Sprint.

Plone Sorrento Sprint 2007

Ü di Maurizio Delmonte

Reportage


Reportage


sorizzandoli, o addirittura organizzandoli. Come è stato nel caso di Sorrento, in cui, Abstract, giovane società napoletana attiva nel panorama italiano come una delle aziende leader nella fornitura di soluzioni basate su Plone, ha fortemente voluto lo sprint par-tenopeo. Il ruolo di Abstract è stato, appunto, fornire un apporto fattivo per ospitare lo sprint a Sorrento. Abstract, con questo sprint, ha anche voluto offrire uno stimolo alla comunità Plone italiana: infatti, uno sprint costituisce un ottimo contesto per la discussio-ne di idee, non solo tecniche, e per la condivisione delle esperienze dei singoli sviluppatori e utenti di software open source. Nonostante la scarsa presenza di italiani nel gruppo centrale di sviluppo di Plone non giocasse a favore di una richiesta di organizzare l’evento in Italia (attività che deve essere approvata e sostenuta dalla fondazio-ne), l’ottimo lavoro di Vincenzo Barone e di tutto lo staff di Abstract ha fatto sì che questa possibilità si concretizzasse: con buoni auspici per tutti nel poter aumentare la propria esposizione e il proprio apporto alla comunità Plone internazionale. Il gruppo di lavoro è stato ospitato nella splendida cornice della costa sorrentina, che ha positivamente colpito i suoi ospiti fin dal primo arrivo. Lo sprint si è tenuto nella sala riunioni di un magnifico hotel, fornita delle attrezzature necessarie e dotata per l’oc-casione di abbondante connettività rispetto alle nor-mali esigenze della struttura. Una vista mozzafiato sul golfo di Napoli ci ha ac-

compagnato durante tutto il soggiorno: certo, il pa-norama non è indispensabile per produrre del buon codice, ma di sicuro aiuta lo spirito, al punto che al-cune sessioni di lavoro si sono tenute direttamente nel giardino dell’hotel o nel foyer, seduti sui comodi divani. Non va dimenticato, infatti, che i partecipanti ad uno sprint sono dei volontari: ed è fondamentale, anche per gli orari massacranti, che possano operare nel contesto migliore possibile.

Gli argomenti dello sprint

Il Sorrento Sprint ha avuto come finalità principale l’evoluzione della prossima versione di sviluppo di Plone, la 3.5; tuttavia, l’evento si è svolto a ridosso dell’uscita della versione 3.0, prevista per Maggio. Per cui, è stato naturale collocare un “Bug Day” nel bel mezzo dello sprint e buona parte dei partecipan-ti, per un intero giorno, si è dedicata a risolvere i bug segnalati sul collector ufficiale, contribuendo così anche a migliorare la qualità della nuova versione di Plone (decisamente più ricca di novità e di migliora-menti rispetto alla precedente). Plone 3.0 dispone di meccanismi nativi di versioning e di staging dei contenuti, strumenti molto potenti e piuttosto invidiati anche da soluzioni a licenza chiu-sa. Chiaramente, sono migliorabili ed estensibili a casi d’uso diversi da quelli di partenza; perciò uno degli obiettivi dello sprint è mostrarne le potenzialità

FIGURA 1 Foto di gruppo dei partecipanti al Plone Sorrento Sprint 2007

Reportage


Reportage


ai partecipanti, e chiedere il loro supporto per la pro-secuzione dello sviluppo di questi meccanismi. Altra questione molto sentita, e centrale durante lo sprint, è il processo di supporto a AJAX dell’interfac-cia di Plone, un’evoluzione in corso da tempo (è sta-ta già scelta la metodologia da seguire e siamo nella fase di viva realizzazione di quanto è necessario). Gli sviluppatori Plone dispongono già oggi di una infra-struttura, KSS, che li mette in condizione di rendere dinamiche intere parti dell’interfaccia di Plone, sen-za inficiare la bontà dei meccanismi di base (che re-stano funzionanti anche se il javascript non è attivo o non è disponibile nel browser web). L’impiego di Plone negli ambiti più disparati ha reso necessaria nel tempo l’implementazione di un’infra-struttura di gestione utenti molto ricca e flessibile: oggi Plone può facilmente autenticare utenti a fronte di servizi esterni (tra cui LDAP o Active Directory), può autorizzarli sulla base di regole contestuali molto specializzate, può gestirne gli attributi ottenendoli e memorizzandoli, se necessario, in sorgenti distribui-te. Tutto ciò utilizzando dei plugin che si agganciano al servizio di base, PAS, e lo specializzano in modo semplice ed efficace. Allo sprint si è lavorato su Re-member, un prodotto capace di sfruttare le tecnologie PAS per dotare Plone di un oggetto “utente” più ver-satile, i cui attributi possano essere facilmente estesi, e che sia agganciabile ad un workflow (utile ad esem-pio per gestire fasi di approvazione di richieste di re-gistrazione al portale). Ulteriore argomento notevole, tra quelli trattati allo sprint, è stata l’importazione e l’esportazione di contenuti in Plone. Anche in que-sto caso, da tempo esistono tecnologie molto valide, capaci di assistere gli sviluppatori nel risolvere tali esigenze, ma non esistono analoghe funzioni efficaci per permettere all’utente finale di Plone di effettua-re queste operazioni in modo semplice e completo. Durante lo sprint sono stati valutati diversi approcci, e probabilmente uno tra questi sarà presto parte del Plone base.

I partecipanti

A detta dei veterani presenti, lo sprint di Sorrento è stato uno dei più affollati (vedi foto di gruppo) e ric-chi di tematiche organizzati negli ultimi anni. Tra gli oltre 60 partecipanti, molti rappresentavano aziende europee e americane (perciò, come di consueto, la lingua più parlata allo sprint era l’inglese), ma erano presenti anche dei freelance e alcuni “decisori” e IT manager, interessati a capire cosa Plone può offrire loro: non potevano scegliere occasione migliore! Fol-ta anche la presenza italiana, con una importante rap-presentanza dell’Associazione Zope Italia. Gli sprint rappresentano uno dei principali momenti di miglioramento di Plone: pertanto, in base alle te-matiche trattate e alla propria disponibilità, gli svi-luppatori più importanti alternano la propria presen-za fisica a questi eventi. Nel caso di Sorrento, il Coach designato è stato Alec Mitchell, freelance proveniente da Los Angeles, re-

lease manager di Plone 2.5 e autore di molti prodot-ti basati su tecnologia Zope, tra cui Relationship, il nuovo modulo di gestione delle relazioni tra oggetti di Zope 3. Alec ha svolto un ottimo lavoro: non era infatti facile, soprattutto i primi giorni, coordinare un così folto gruppo di sviluppatori, ma ci è riuscito al meglio, grazie all’immensa disponibilità, alla capa-cità di ascolto, e al grande rispetto e fiducia che ha sa-puto infondere anche a chi non lo conosceva già. Tra le altre presenze “eminenti” citiamo anche Rob Miller, responsabile tecnico di Open Plans, una no-profit newyorkese piuttosto sensibile alle nuove tec-nologie, noto per molti importanti prodotti per Zope e Plone, e per essere l’autore del portale del Burning Man, un evento unico nel suo genere ed estremamen-te noto soprattutto negli Stati Uniti. A questo sprint, Rob si è dedicato alle problematiche inerenti alla ge-stione utenti, essendo il leader del progetto Remem-ber, a cui abbiamo accennato prima. Per quanto riguarda la gestione di AJAX in Plone, lo sprint ha ospitato due degli sviluppatori fondamen-tali di KSS, Godefroid Chapelle e Balasz Ree, prove-nienti rispettivamente da Belgio e Ungheria. Anche per loro si sono registrate lunghe sessioni di forma-zione e sviluppo, dato che moltissimi dei presenti erano interessati a questi nuovi e promettenti mecca-nismi che rendono l’interfaccia di Plone ancora più moderna e potente, grazie all’adozione di AJAX. I neofiti di KSS si sono detti sbalorditi e molto sod-disfatti per le scelte operate dagli strateghi di Plone: KSS permette di sviluppare la parte AJAX dell’inter-faccia senza andare a manipolare le skin di base (che devono essere mantenute tali per consentire di usare l’applicazione anche in caso AJAX non sia funzio-nante). In sintesi, Plone non riscrive le proprie libre-rie AJAX, ma fa utilizzare ai suoi sviluppatori quelle già esistenti, senza impedire ai singoli di implemen-tare e adottare le proprie! A questo sprint ha anche partecipato Jens Klein, svi-luppatore austriaco molto in vista nella comunità (è coinvolto in progetti fondamentali quali Archetypes e ArchGenXML, strumenti che rendono la produt-tività nei progetti basati su Plone estremamente ele-vata). Jens è arrivato a Sorrento per interessarsi alle problematiche di migrazione di contenuti Plone ba-sata su XML, ma ha anche cercato supporto per Ge-nesis, il progetto di riscrittura di ArchGenXML, per il quale ha in programma di organizzare uno sprint nei prossimi mesi. Tra i partecipanti che hanno fatto più strada per rag-giungere Sorrento ci sono Rocky Burt (dall’isola di Terranova!) e Nate Aune, entrambi insigni rappre-sentanti della Plone Foundation ed esperti delle tec-nologie Zope 3. Durante lo sprint hanno lavorato a Plone4Artist, una verticalizzazione open source di Plone orientata alla gestione di file multimediali utile alle comunità di artisti che vogliono rendere disponi-bili online i propri lavori audio-video. Plone4Artist è in grado di gestire agevolmente file di grandi dimen-sioni e le problematiche legate al multimedia (come lo streaming). Plone4Artist è anche un ottimo esem-pio di come le tecnologie Zope 3 possono potenzia-

Reportage


Reportage


re Plone: chi ha supportato Plone4Artist durante lo sprint è rimasto sbalordito di quel che si riesce a fare con tali tecniche rispetto a quello a cui si è abituati con lo sviluppo Zope classico. Per quanto riguarda l’Italia, segnaliamo la partecipa-zione di Vincenzo di Somma, uno dei più importanti sviluppatori italiani della comunità Plone internazio-nale, che da sempre fa parte del gruppo responsabile dell’infrastruttura di Plone. Vincenzo si è dedicato al miglioramento del supporto ai workflow di Plone, e ha dispensato infiniti consigli a chi stava cercando di perfezionare Plone 3.0 in vista del rilascio ufficiale.Restando in ambito italiano, l’Associazione Zope Italia ha approfittato dell’evento anche per coordi-nare con Redomino, sponsor dello sprint, un’azione comunitaria sull’Italian Skin, un prodotto realizzato e mantenuto finora da Redomino, capace di dotare Plone di un’interfaccia mirata a risolvere le richieste di accessibilità definite per i portali delle pubbliche istituzioni dalla Legge Stanca. Infatti, Plone rispet-ta da sempre i canoni internazionali di accessibilità, quasi da farsene un fiore all’occhiello. Ma per l’Italia si è ben visto di darsi obiettivi ancor più stringenti, e per questo si rende necessario estendere ulteriormen-te, secondo le regole XHTML Strict, la già accessibi-le interfaccia di Plone.

Sviluppo, ma non solo!

Lo sprint non è stato (e non vuole essere) solo una lunga sessione di sviluppo software. I nuovi arrivati vengono accolti con molta disponibilità, e i vetera-ni possono farsi conoscere, per le doti tecniche e per quelle umane. Insomma, è un bellissimo modo per dare un volto e stringere amicizia con quei nomi che appaiono nella documentazione del software, nelle mailing list e nelle chat tecniche. Dopo esserci incon-trati, sarà molto più facile e proficuo, tornati a casa, scambiare le proprie idee e collaborare insieme, an-che a migliaia di chilometri di distanza. Non sono mancate sessioni di presentazione e di for-mazione su tecnologie e prodotti innovativi (alcune addirittura improvvisate, grazie alla disponibilità de-gli specialisti presenti). Tutti hanno imparato qualco-sa di nuovo, hanno potuto vivere il flusso creativo che caratterizza lo sviluppo software, e hanno sperimen-tato le tecniche e le metodologie utilizzate nello svi-luppo del core di Plone (predisposizione delle istanze di lavoro, versioning, testing automatico, tecniche mutuate da Zope 3, strumenti di lavoro alternativi a quelli di solito utilizzati). In particolare, molti dei “nuovi” sono rimasti sbigot-titi e affascinati dall’approccio test-driven che carat-terizza Plone e tutti i prodotti di qualità che ne esten-dono le funzionalità di base. Da anni Plone viene ri-lasciato con un corredo di test in grado di verificarne automaticamente le funzionalità di base, a garanzia della sua qualità. In sostanza, per ogni nuova funzio-nalità (e per ogni bug individuato) come primo passo viene implementata una o più funzioni che ne veri-ficano il funzionamento (o la presenza del bug). Ciò

permette sia di poter lavorare in moltissimi in modo coerente sulla stessa base di codice, sia di rifattorizza-re il codice nel caso in cui vengano proposte imple-mentazioni migliori di specifiche funzionalità. Lo sprint è anche stato occasione per potersi cimen-tare nell’apprendimento delle tecniche mutuate da Zope 3 introdotte in Plone già dalla versione 2.1. Rispetto a Zope 2, Zope 3 si pone al contempo in un’ottica di continuità e di rottura: buona parte del materiale implementato per Zope 3 può essere facil-mente adattato e utilizzato anche in ambiente Zope 2 (e questo ne testimonia la continuità), tuttavia i prin-cipi alla base di Zope 3 sono in alcuni casi nuovi in al-tri addirittura alternativi a quelli adottati da Zope 2. Ad esempio, mentre in Zope 2 è il concetto di oggetto che pervade tutto il framework, in Zope 3 tutto è in-centrato sul concetto di componente. E da ciò deriva una serie di possibilità che si manifestano concreta-mente in Plone in vari modi, portando gli sviluppa-tori Plone ad apprezzare i vantaggi dell’adozione di Zope 3 come ambiente di sviluppo. Solo per citare alcune delle caratteristiche più evidenti e più attese, nella versione Plone 3.0 sono stati integrati i mecca-nismi di versioning e di staging dei contenuti, sono stati introdotti elementi AJAX lato client (che faci-litano molto la vita agli utilizzatori finali), ed è stato introdotto un servizio di gestione degli eventi sugli oggetti. Non resta che sperimentarlo un po’!

Conclusioni

Al termine di questa magnifica settimana, il bilancio è positivo: oltre sessanta partecipanti, quasi tutti pre-senti per l’intera durata di questo sprint (caratterizza-to da orari che potremmo dire “disumani”, soprattut-to se correlati alla sua abnorme durata: di solito due-tre giorni, invece dei sei del Sorrento Sprint!). Il coach, e quindi la Foundation, si è detto soddisfat-to della buona riuscita dell’incontro, considerandolo molto produttivo, ed è stato anche molto contento delle “new entry” nel gruppo di lavoro di Plone: la mancanza di sprint in Italia non ha certo favorito fi-nora una partecipazione fattiva. Anche i leader dei vari gruppi di lavoro, che si sono formati più o meno spontaneamente, hanno riportato buoni risultati con-seguiti durante la permanenza a Sorrento, sia per i progressi fatti sia per le nuove prospettive raggiunte sui problemi aperti. Molti dei presenti hanno utiliz-zato tutte le pause disponibili per scambiarsi idee, comprendere nuove possibilità di collaborazione, e anche per fare amicizia: questo è il modo con cui la comunità Plone si è sviluppata fin dagli inizi, ed è quello in cui ci aspettiamo che continui a prospe-rare. Arrivederci alla Plone Conference di Ottobre a Napoli!

Note Biografiche

Maurizio Delmonte, Ingegnere Elettronico, si occupa di tema-tiche Zope/Plone da oltre cinque anni. Lavora in Redomino come responsabile tecnico per l’implementazione ed il delive-ry di soluzioni document oriented.

IN VETRINA LOGIN 63


IN VETRINA LOGIN 63

Scrivi a [email protected] specificando nell’oggetto della e-mail:

IN VETRINA LOGIN N. 63OPPURE

inviaci il coupon al numero di fax 0587/732232

Potrai acquistare i libri qui riportaticon uno SCONTO ECCEZIONALE

del 10% anche se acquisti solo un libroOPPURE

del 20% se acquisti 3 libri

LOGIN 63

Windows VistaThe Definitive Guide

di W. R. Stanek

Una guida completa per miglio-rare le prestazioni del sistema operativo e per la manutenzione del computer indipendentemente dalla versione di Windows Vista posseduta.

O’ Reilly942 pp - 47,20 EuroISBN 9780596528003

Programming WCF Servicesdi J. Löwy

Scritto da un esperto di Microsoft, questo libro rappresenta la miglio-re introduzione sul mercato alla piattaforma SOA su Windows.Il libro non ha valore di documen-tazione, ma offre un approccio pratico per la costruzione delle applicazioni di prossima genera-zione.

O’ Reilly654 pp - 42,40 EuroISBN 9780596526993

Access Data Analysis Cookbook

di K. Bluttman, W. S. Freeze

Per coloro che gestiscono grandi quantità di dati e necessitano di studiare quei dati in profondità. La prima parte del libro mostra come estrarre i dati, la seconda come approntare calcoli con essi. Presenta inoltre numerosi proble-mi ricorrenti associando le relative soluzioni.

O’Reilly400 pp - 47,20 EuroISBN 9780596101220

AutoCAD 2007di R. Grabowski

Il testo tratta tutti gli aspetti fonda-mentali di AutoCAD. Non sono tralasciati aspetti peculiari come il plottaggio e la modellazione 3D.La presenza dei tutorial passo passo permette un apprendimento immediato e velocizza l’acquisizio-ne delle competenze operative.I file utilizzati negli esempi del testo sono contenuti nel Cd-Rom allegato.

Masterizzare con Nero 7di W. Wang

Una documentazione appropriata e approfondita per comprendere tutte le problematiche e conoscere le potenzialità del pacchetto.La suite non prevede solo i classici strumenti per riversare i dati su CD o DVD, ma combina anche tutte le attività legate ai media digitali: de-sign grafico, elaborazione sonora, programma per il video editing e molto altro ancora.

Dizionario di Informatica6.a ed.

Inglese-Italianodi A. Gallippi

Presenta oltre 5500 termini legati al mondo delle nuove tecnologie. I lemmi, tradotti, spiegati e classifi-cati, spaziano tra vari argomenti.Un’opera che costituisce uno stru-mento professionale insostituibile per gli operatori del settore, ma anche chi intende rendere fruibili tutti i neologismi.

Endpoint Securitydi M. Kadrich

Questo libro chiarisce che cosa ogni endpoint riesce a fare per pro-teggersi e spiega come nuove tec-nologie, quali il network admission control, aumentino la sicurezza.

Addison Wesley384 pp - 50,95 EuroISBN 9780321436955

VBA for the 2007 Microsoft® Office System

di P. McFedries

Questo libro rende il lettore esperto sia in merito al linguaggio VBA che all’Office 2007 Object Model. Non dà per scontate conoscenze approfondite e ha una struttura user friendly, con schemi, doman-de con risposte ed esercizi pratici.

Tecniche Nuove1016 pp - 42,00 EuroISBN 9788848120494



Que432 pp - 38,40 EuroISBN 9780789736673

IN VETRINA LOGIN 63


IN VETRINA LOGIN 63

Scrivi a [email protected] specificando nell’oggetto della e-mail:

IN VETRINA LOGIN N. 63OPPURE

inviaci il coupon al numero di fax 0587/732232

Potrai acquistare i libri qui riportaticon uno SCONTO ECCEZIONALE

del 10% anche se acquisti solo un libroOPPURE

del 20% se acquisti 3 libri

LOGIN 63

Founders at Work: Stories of Startups’ Early Days

di J. Livingston

Il testo presenta una collezione di interviste ai grandi dell’informatica, persone che oggi sono celebrità: fondatori come Steve Wozniak (Apple), Caterina Fake (Flickr), Mitch Kapor (Lotus), Max Levchin (PayPal) e Sabeer Bhatia (Hotmail) raccontano idee e scommesse del tempo in cui hanno iniziato a metter su le proprie aziende.

Apress456 pp - 35,00 EuroISBN 1590597141

Multimedia Data Mining and Knowledge Discovery

di V. Petrushin e Khan, L.

Multimedia Data Mining and Knowledge Discovery unisce l’espe-rienza di academici e prifessionisti dell’industria. Il libro procede con un approcio molto strutturato al multimedia data mining.

Springer526 pp - 77,95 EuroISBN 9781846284366

Microsoft SharePoint 2007 Unleashed

di Colin Spence, C. e Noel, M.

La prima parte del libro offre un’introduzione a SharePoint 2007 in merito anche alla sua imple-mentazione. La seconda parte si concentra sulla sua programmazione e struttura-zione. Utilissima la parte in cui si illu-strano le procedure per passare da SharePoint 2003 a SharePoint 2007.

Sams840 pp - 52,95 EuroISBN 9780672329470


SOMMARIOLOGIN n.45 - Marzo/Aprile 2004 OFFERTEABBONAMENTI

l2007 02 login63

Documents

Transcript of l2007 02 login63