NUOVA SERVER FARM ROGETTO - siaf.unifi.it · Dimensionamento dei sistemi 28 9.1. Parte stabile 29...

NUOVA SERVER FARM – PROGETTO

Tipo di documento: Relazione Tecnica Pag. 2 di 35

Tilolo del documento: Nuova Server Farm – ProgettoData: File: sf.tex Preparato da: Riccardo DettiProt: Allegati: Approvato da: Cristina MugnaiRevisione: 1.0

Indice1. Introduzione �� 52. Obiettivi del progetto �� 5

2.1. Razionalizzazione �� 52.2. Disegno di una nuova architettura del sistema informativo �� 62.3. Sicurezza �� 62.4. Ottimizzazione e potenziamento dei servizi interni �� 62.5. Obiettivi a lungo termine �� 7

3. Ricognizione dello stato attuale �� 73.1. Infrastruttura e topologia di rete �� 73.2. Server �� 83.3. Servizi �� 9

3.3.1. Servizi esterni �� 93.3.1.1. DNS �� 93.3.1.2. WWW �� 93.3.1.3. Posta elettronica �� 103.3.1.4. FTP �� 103.3.1.5. Video Streaming �� 10

3.3.2. Servizi interni �� 103.3.2.1. Contabilita di ateneo �� 113.3.2.2. Segreterie Studenti �� 113.3.2.3. Sistema di Gestione delle Biblioteche – SBN �� 11

3.4. Criticita emerse dalla ricognizione �� 124. Progetto �� 13

4.1. Filosofia del progetto �� 134.2. Open Source, GNU, Linux �� 144.3. Architettura �� 16

5. Rete �� 195.1. Topologia �� 195.2. Tecnologia �� 195.3. Sicurezza e firewall �� 19

6. Sezione di front-end �� 207. Sezione applicativa �� 20

7.1. Tecnologia �� 207.2. Servizi �� 21

7.2.1. DNS �� 217.2.2. WWW �� 217.2.3. Proxy �� 227.2.4. Email �� 227.2.5. FTP �� 237.2.6. LDAP �� 247.2.7. Streaming �� 247.2.8. Segreterie Studenti �� 24

7.3. Servizi interni �� 247.3.1. File service �� 247.3.2. Print service �� 25

Il materiale tecnico e le informazioni contenute nel presente documento sono di natura strettamente confidenziale edi esclusiva proprieta del CSIAF. Non e consentita la divulgazione e la riproduzione totale o parziale senza esplicitaautorizzazione.



8. Sezione di back-end – Database e servizi ausiliari �� 258.1. Database �� 258.2. Storage Area Network �� 268.3. Sistema di Backup �� 278.4. Monitoraggio �� 28

9. Dimensionamento dei sistemi �� 289.1. Parte stabile �� 299.2. Server ad alto carico – Prima ipotesi �� 309.3. Server ad alto carico – Seconda ipotesi �� 30

Appendice A – Descrizione dei sistemi attuali �� 31




Indice delle figureFig. 1 – Stato attuale: topologia di rete e sistemi �� 8Fig. 2 – Architettura generale della Server Farm �� 17Fig. 3 – Architettura generale della Server Farm — Deployment iniziale �� 18




1. IntroduzioneQuesto documento presenta in modo sintetico i vari aspetti che concernono la ristrutturazione

della server farm del CSIAF.

I primi capitoli oltre ad illustrare gli obiettivi del progetto, offrono una descrizione dettagliatadegli attuali servizi in carico alla farm e indicano in modo critico le carenze derivanti dalla attualearchitettura.

I capitoli successivi descrivono l’approccio al problema e la filosofia del progetto; il progetto,in seguito, viene illustrato piu in dettaglio focalizzando le varie componenti della nuova serverfarm.

L’ultimo capitolo, “Dimensionamento dei sistemi”, fornisce indicazioni di massima, utili aduna discussione sulle strategie da seguire al fine di rendere esecutivo il progetto, descrivendo ipossibili fabbisogni delle varie componenti.

L’intero progetto si basa sui servizi. I servizi che la farm e, piu in generale il Centro stesso,erogano al momento, insieme a quelli che e’ possibile prevedere nei prossimi tre anni, costituis-cono “l’input” del progetto. I servizi progettati e realizzati all’interno del Centro (o comunquedell’Universita) sono analizzati in modo critico e per alcuni di essi si prospetta una evoluzione voltasia al miglioramento del servizio stesso, sia ad una migliore integrazione con il nuovo contestooperativo. Cio dovrebbe portare, nell’arco di vita previsto per il progetto (circa tre anni), versola realizzazione di un sistema informativo “integrato” di ateneo, ove tutte le componenti siano ingrado di interagire reciprocamente.

Alcuni servizi (di grande importanza) sono invece forniti da terzi e sono solo ospitati dalCentro. Non potendo l’Univerita incidere ne sulla loro architettura ne sulle loro possibili evoluzioni,il progetto li colloca nel nuovo contesto nel modo migliore possibile. Essi in qualche modo vizianosia l’architettura generale, sia, soprattutto, la possibilita di evoluzione appena accennata e quindi laqualita complessiva dell’intero processo. D’altronde in questa sede non si ritiene appropriata, nedi competenza, la discussione a posteriori della validita, sia architetturale sia operativa, delle sceltefatte; di conseguenza, come appena detto, il progetto include questi servizi valutandoli allo statoattuale dell’arte e accettandone le imposizioni.

Si ritiene comunque indispensabile, per il futuro, che la scelta di nuovi servizi venga preventi-vamente discussa sul piano architetturale e tecnologico, in modo che questi si integrino nel contestosenza degradare la qualita dell’intero sistema. A tal fine sarebbe necessaria la preparazione di una“carta tecnica dei servizi”, che indichi, sia agli interni sia agli esterni, gli standard architetturali edi qualita’ che devono essere soddisfatti da qualunque nuovo servizio prima di essere attivato.

2. Obiettivi del progettoIl progetto di ristrutturazione della Server Farm del CSIAF, centrale per quasi tutte le attivita

informatiche dell’ateneo, e sicuramente un progetto di elevata complessita tecnica. Predisporre,infatti, il cambiamento in una unica soluzione dell’intero basamento su cui poggia l’attuale sis-tema informativo dell’Universita, pone tutto l’insieme delle problematiche classiche, aprendo alcontempo un insieme di possibilita tecnologiche e architetturali, che di norma si affrontano gradual-mente durante l’evoluzione di un sistema esistente. Comunque, come descritto nel paragrafo 3.4,le carenze dell’attuale struttura impongono un’azione radicale, tale da poter rispondere in tempibrevi alle necessita gia emerse da tempo e a quelle previste nei piani di sviluppo del CSIAF.




2.1. RazionalizzazioneDalla ricognizione dell’insieme dei server installati presso il CSIAF (vedi capitolo 3), risulta

una miscellanea di macchine, spesso dedicate ad un singolo servizio. Uno degli obiettivi principalidel progetto sara l’omogeneizzazione dei server al fine di ottenere:

Economia di gestione. Utilizzando server per quanto possibile omogenei si ha un migliora-mento dei tempi e dei costi di intervento per la gestione e l’aggiornamento dei sistemi. Si rendeagevole il monitoraggio attraverso l’utilizzo uniforme di software di system management.Economia nell’acquisto e nei canoni di manutenzione. Rivolgendosi ad uno o ad un poolristretto di fornitori si ottengono sicuramente vantaggi economici di scala.Svecchiamento dei server in produzione. Si possono dismettere i server piu vecchi che hannoun basso rapporto tra potenza e costi di gestione e manutenzione a favore di server di nuovatecnologia piu potenti ed economici.

2.2. Disegno di una nuova architettura del sistema informativoL’attuale disegno architetturale del sistema informativo presenta gravi carenze. Le criticita

che ne derivano sono descritte nel paragrafo 3.4; in particolare il nuovo disegno architetturale dovragarantire:

Scalabilita. A fronte dell’aumento della richiesta di risorse, fisiologica o eccezionale, da partedi uno o piu servizi l’architettura dovra permettere l’aumento delle capacita di elaborazionesenza dover modificare l’architettura stessa.Fault-tolerance. L’architettura dovra permettere ad ogni servizio di continuare a funzionareanche in caso di guasto di un qualsiasi componente.Tecnologia. Il progetto dovra impiegare lo stato dell’arte in campo tecnologico e valutarepossibilmente il trend dei prossimi anni.Evoluzione. L’architettura dovra permettere la naturale evoluzione dei sistemi e dei servizicoinvolti. Sara, per quanto possibile, neutra rispetto alla tecnologia dei sistemi che la com-pongono.

2.3. SicurezzaLa sicurezza dei sistemi informatici riveste sicuramente un aspetto che, ormai da qualche

anno, non e piu trascurabile, anzi lo si deve considerare un fattore di base nella progettazione ditutti i livelli di un sistema informativo, dall’infrastruttura di rete fino ai servizi resi all’utenza. Ilprogetto dovra quindi valutare l’intero disegno anche da questo punto di vista, cercando, per quantopossibile, di utilizzare gli standard piu diffusi per ottenere un sufficiente livello di sicurezza senzacomplicare l’utilizzo delle risorse e la fruizione dei servizi.

2.4. Ottimizzazione e potenziamento dei servizi interniLa priorita dei servizi resi all’esterno del CSIAF ha reso di importanza secondaria le necessita

interne alla Server Farm e piu in generale quelle del personale interno al Centro. Obiettivo delprogetto sara un aggiornamento e un ampliamento dei servizi interni tra cui:

Sistema centralizzato di backup per il salvataggio dei dati dei server e delle stazioni di lavorodel personale.Sistema per il monitoraggio dei server, dei servizi e dell’infrastruttura di rete interna alla ServerFarm.




File server centralizzato per i sistemi interni alla Farm e per il lavoro di gruppo del personaledel Centro.Servizi di stampa e stampanti di formato e qualita adeguati alle necessita del Centro.

2.5. Obiettivi a lungo termineIl presente progetto e testimonianza dell’attenzione e della priorita dedicata alla qualita dei

servizi forniti dal CSIAF. Con gli stessi criteri del presente progetto (stato dell’arte della tecnologia,adesione agli standard ecc.) vengono progettati i servizi sviluppati all’interno del Centro. Edoveroso pero notare che, per motivi che non possono essere discussi qui, i servizi informaticichiave dell’Universita (contabilita, segreterie, protocollo, gestione del personale, ecc.) sono statiprogettati e sviluppati da terzi. Prescindendo dalla qualita di ogni singolo servizio e inconfutabileil fatto che ognuno di essi rappresenta una realta (un mondo) a se stante, fatto di architetture,tecnologie e dati diversi tra loro. In altre parole questi mondi non sono in grado di comunicarene tantomeno di cooperare gli uni con gli altri. Se questa situazione poteva essere accettabile inpassato, gia oggi induce grosse difficolta allo sviluppo di servizi trasversali, cioe che interessanocontemporaneamente piu mondi, imponendo attivita notturne di trasferimento, trasformazione e,soprattutto, duplicazione dei dati. In futuro questa incapacita di ogni servizio di comunicare congli altri rappresentera il problema maggiore nel costituire un Sistema Informativo dell’Universitadi Firenze.

Pertanto sara indispensabile, a fronte della acquisizione di nuovi servizi/prodotti dall’esterno,la possibilita di valutare:

L’architettura, in modo che il nuovo sistema possa essere agevolmente integrato e gestitonell’infrastruttura della Server Farm.La tecnologia, affinche il servizio possa eventualmente essere ospitato da server gia presentinella Server Farm.La capacita di offrire servizi verso altre applicazioni in modo che il nuovo sistema possainteragire con gli altri gia presenti.

3. Ricognizione dello stato attuale

3.1. Infrastruttura e topologia di reteLa Figura 1 schematizza le parti della rete di ateneo interessate dal progetto. Le sottoreti .1 e

.3 costituiscono, rispettivamente, la rete dei servizi di front-end e quella dei servizi applicativi. Essesono all’interno della sede di Via delle Gore , mentre le sottoreti .22 e .85 (in basso nella figura)sono all’interno della sede del rettorato. I rettangoli presenti in figura rappresentano i sistemi; inappendice Asono descritti in dettaglio i server e le loro configurazioni hardware e software. Gliapparati di rete sono viceversa elencati qui di seguito:

C7200 – Router CISCO 7200, e’ il router di frontiera, collegato al POP GARR con un canaleATM a 34Mb/s, esposto verso l’esterno via protocollo BGP. Storicamente e stato il centro dellecomunicazioni dell’ex CeSIT, sia verso l’esterno sia verso l’interno; sta avendo un ruolo semprepiu marginale dopo l’implementazione della rete interna a 1Gb/s. Implementa verso l’interno ilprotocollo di routing OSPF.

ENALP – Extreme Networks Alpine XXX, e lo switch layer 3 che WIND ha installato pressotutte le sedi che si collegano all’anello in fibra ottica a 1Gb/s. Sono fisicamente i “centro stella”




sia della sede di Via delle Gore sia di quella del Rettorato. In Via delle Gore questo switch collegadirettamente i server piu importanti (MAIL, WWW, WWW2, OLS), mentre gli altri vi arrivanoattraverso switch secondari (non presenti in figura).

Si nota l’assenza di firewall; tutti i server presso la sede di Via delle Gore sono infatti espostidirettamente in rete pubblica, ponendo gravi, e noti, problemi di sicurezza e di interoperabilita.L’unico firewall presente (un CISCO PIX XXX) e installato presso il Rettorato a protezionedei sistemi di contabilita e delle segreterie studenti. L’argomento sara discusso in dettaglio nelparagrafo 5.3.

Gli apparati e l’infrastruttura non sono ridondati.

F W

Internet

150.217.

1 Gb Eth

MAIL DNS WWW WWW2 STRM EPRES MSTUD PROXY WWWS

DEVELOLSC7200

ENALP

ENALP

.1

.3

.22

.85

GISSdbGISSdbGISSas

CONT

DNS2

Collegamento alle sedi principali dell’Ateneo

Sede CSIAF

Rettorato

Fig. 1– Stato attuale: topologia di rete e sistemi

3.2. ServerIn appendice A sono elencati i server principali attualmente installati presso le sedi del CSIAF,

ne viene descritta sinteticamente la configurazione hardware, la dotazione di software di base, iprincipali servizi offerti. L’elenco non e completo, non sono descritti i server ritenuti marginali aifini del progetto:

per la scarsa importanza del servizio offerto, ad esempio file sever per un singolo ufficio;per la duplicazione del servizio, ad esempio un sito FTP simile a quello principale;per la non integrabilita dovuta alla specificita del servizio o dell’hardware; ad esempio ilmainframe BULL che ospita il sistema gestionale delle biblioteche.




3.3. ServiziSono di seguito elencati i servizi attualmente offerti dal CSIAF, divisi tra esterni, quelli cioe

esposti in Internet, e interni, dedicati all’utenza di ateneo. Si noti che il termine esterno va intesocome “accedibile dall’esterno” e cioe’ da qualsiasi postazione Internet nel mondo e non come rivoltoad una utenza rigorosamente esterna all’Universita. Viceversa per servizi interni si assumono quellistrettamente dedicati alle strutture, al personale tecnico-amministrativo, agli studenti e ai docentidell’Universita di Firenze. Ad esempio sono esterni il servizio web di ateneo ed il “cerca-chi”,utilizzati massivamente anche all’interno dell’ateneo, mentre contabilita e segreterie studenti sonoservizi interni.

3.3.1. Servizi esterni

3.3.1.1. DNSIl Domain Name System e un servizio di base, obbligatorio per ogni ente che esponga il

proprio dominio in Internet. Il sistema, organizzato come un database gerarchico distribuito alivello mondiale, garantisce la corrispondenza biunivoca tra la nomenclatura gerarchica a domini diInternet dei sistemi di una organizzazione con l’indirizzo IP di ogni sistema. Il DNS dell’Universitadi Firenze “mappa” il dominio unifi.it e i suoi sottomini con gli indirizzi IP della rete di classe B(150.217.) dedicata all’ateneo.

Il servizio DNS e’ ospitato su piu server, per garantire ridondanza in caso di guasto e permigliorare l’efficienza. Poiche ogni singola stazione interroga ripetutamente il DNS, da sempresi e provveduto ad installare il DNS primario presso la sede di Via delle Gore, vicino alla fron-tiera, in modo che le richieste provenienti dall’esterno trovino subito il servizio, senza percorrerel’infrastruttura di rete interna all’ateneo. Per lo stesso criterio, tutti i sistemi interni, topologicamentevicini alla sede di Via delle Gore, riferiscono direttamente al DNS primario. Il DNS secondario,installato presso la sede del Rettorato, fa da riferimento per i sistemi del Rettorato stesso e perquelli che insistono sulle reti del centro storico. Il sistema DNS presso la sede del Rettorato non eridondato, mentre presso la sede di Via delle Gore e attivo un altro server, normalmente visto comesecondario, che puo sostituire temporaneamente il primario in caso di guasto.

3.3.1.2. WWWE il piu importante, insieme alservizio di posta elettronica, dei servizi esterni. Da sempre

sviluppato e gestito all’interno dell’ateneo viene considerato a livello nazionale tra i migliori sitiuniversitari. Attualmente sono molteplici i server che ospitano parti del sito web di ateneo; i piuimportanti (vedi appendice A per le caratteristiche) sono:

WWW E il server che storicamente ha esposto la parte informativa del web di ateneo. Re-centemente e stato scaricato della sezione “studenti”. Ospita sezioni “periferiche”, alimentatedirettamente da unita amministrative dell’ateneo. Implementa alcuni servizi dinamici, tra i qualispicca il “cerca-chi”. Le parti dinamiche utilizzano i linguaggi PHP e PERL che sono installaticome moduli del server Apache. Le procedure in PHP utilizzano il database mySQL.

WWW2 E’ il server, recentemente introdotto, che ospita la sezione “studenti”, sviluppatautilizzando il prodotto di content management WebMate di Navita. Ospita le sezioni perifericheche utilizzano la tecnologia Active Server Pages (.asp) di Microsoft.

OLS E un server orientato completamente all’erogazione dei servizi via WWW. Ospita ilcatalogo online delle biblioteche, tutti i servizi destinati agli studenti e recentemente alcuni servizi




dedicati ai docenti. Il sistema ospita due web server: Apache e iPlanet. Il server Apache e dedicatoall’OPAC/WWW, il quale consiste in un pacchetto di procedure in linguaggio Sibylla. Sibyllae un estensione del linguaggio di script TCL al quale sono state aggiunte primitive e funzioniper l’accesso al motore di information retrieval Basis+ e per l’interfaccia HTTP/HTML. Il serveriPlanet invece viene utilizzato principalmente per le sue funzionalita di “servlet container” e dipubblicazione con la tecnologia “java server pages”. Tutti i servizi online per gli studenti e per idocenti sono sviluppati come servlet java e stanno convergendo verso lo standard 2.2

WWWS Ospita i siti web gestiti dalle organizzazioni studentesche. Non ospita contenutidinamici.

DEVEL E un server dedicato soprattutto allo sviluppo di nuovi servizi WWW , il piu importantedei quali e’ il progetto dell’anagrafe della ricerca. I prototipi sono scritti in linguaggio PHP.L’interprete PHP e installato come modulo del server Apache e incorpora i driver per l’accesso aldatabase Oracle.

3.3.1.3. Posta elettronicaIl servizio di posta elettronica e ormai considerato indispensabile al funzionamento di qualsiasi

ente; nel caso dell’Universita di Firenze e divenuto strumento infrastrutturale, e abituale, soprattuttonella comunicazione interna oltreche verso l’esterno. L’importanza con cui e stato visto questoservizio ha inciso notevolmente sul numero di risorse umane dedicate alla gestione e sulla tecnologia,hardware e software, sui cui e basato. Al momento tre persone si occupano praticamente a tempopieno del sistema, che ospita circa 5.000 caselle di posta e circa 280 mailing lists.

Il sistema e costituito da un cluster a 2 nodi basato sul sistema operativo Open/VMS (vediMAIL in appendice A); i sistemi di comunicazione, di email e di gestione delle mailing list sonodella InnoSoft. La scelta di questi sistemi, avvenuta alcuni anni fa, ha prediletto la leggendariasicurezza e stabilita dei sistemi basati sul VMS ritenendo secondarie le problematiche e i costi digestione.

3.3.1.4. FTPIl File Transfer Protocol, una volta l’unico sistema di trasferimento dei file tra sistemi remoti,

ha perso nel tempo la sua cardinalita, essendo affiancato da numerosi altri modi per lo scambio diinformazioni. Appare, da una breve indagine,che l’“utente medio” non utilizzi questo sistema (moltinon lo conoscono nemmeno), preferendo sistemi piu immediati come il download via protocolloHTTP, lo share di directory e, purtroppo, gli attach della posta elettronica. Viene, viceversa,utilizzato molto nelle comunita open source, e in generale nei siti da cui si scaricano grosse moli didati, dove e ritenuta importante l’efficienza del trasferimento.

L’offerta FTP presso il CSIAF e limitata allo scaricamento di alcuni pacchetti software,ad esempio Panda Antivirus, e al caricamento delle pagine web da parte degli amministratoridei contenuti delle sezioni periferiche del web di ateneo. E da notare che il software di clientper la contabilita di ateneo utilizza internamente il protocollo FTP per l’installazione dei propriaggiornamenti.

3.3.1.5. Video Streaming




3.3.2. Servizi interniNei paragrafi successivi vengono descritti i servizi dedicati ad una utenza rigorosamente

interna, a supporto delle attivita critiche di funzionamento dell’ateneo. La ricognizione non hapreso in considerazione quei servizi come ad esempio il l’E-learning o la gestione delle carrieredel personale che, pur essendo importanti, non impattano direttamente sul progetto, essendo gestiticompletamente da aziende esterne. Il sistema di gestione delle biblioteche viene citato in questiparagrafi per la sua storia particolare e per la centralita che occupa nel CSIAF; non sara valutato aifini del progetto in quanto, pur essendo in corso uno studio di migrazione e downsizing, le soluzioniarchitetturali e le esigenze dell’hardware, subordinate alle caratteristiche funzionali del nuovosistema di gestione non sono note al momento. Saranno comunque fornite (nel paragrafo 3.3.2.3)alcune indicazioni di massima che, se rispettate, porteranno ad una buona integrazione del nuovosistema nel contesto della Server Farm.

3.3.2.1. Contabilita di ateneoLa Contabilita Integrata di Ateneo (CIA) e il pacchetto applicativo che l’Universita ha acquisito

nel 2000 dal CINECA per la propria gestione contabile a amministrativa. Gli utenti registrati sonopoco meno di 500. Dal punto di vista architetturale e tecnologico il programma implementa la logicaclient-server a due livelli. I client, cioe la parte di programma installata presso la postazione dilavoro di ogni utente, contengono l’interfaccia grafica, la logica di funzionamento dell’applicazionee le funzionalita di colloquio, via rete, con il server. Il programma client e stato sviluppato conVisual Age di IBM. Il server, unico per tutti i client, riceve ed esegue i comandi spediti dai client;con CIA il database Oracle viene esposto direttamente ai client, che ne sfruttano le capacita dimultiutenza e di motore transazionale.

E previsto a breve termine l’istallazione e la sperimentazione del nuovo servizio di contabilitaper i Poli (CIA-Poli). Dal punto di vista architturale il sistema dovrebbe consistere in un serverapplicativo (IBM Web Sphere) che colloquia con i client via protocollo HTTP e, in back end, conuno schema dati all’interno dell’istanza Oracle della contabilita (CIA). L’hardware, per il test delprototipo, sara fornito dal CINECA.

3.3.2.2. Segreterie StudentiIl sistema Gestione Integrata delle Segreterie Studenti (GISS) e stato acquisito dall’Universita

nel 2001 dalla Societa Sistemi Informativi. Dopo una “laboriosa” attivit‘a di migrazione dei datidal precedente sistema di gestione, GISS e entrato in produzione nel periodo di immatricolazionee iscrizione dello stesso anno. L’architettura del sistema, che serve circa XXX postazioni utente,segue la logica client-server a tre livelli, anche se in pratica si discosta dal modello classico a trelivelli. Infatti i client ospitano solo la presentazione della interfaccia utente (via browser WWW)e colloquiano con il server di livello intermedio, seguendo l’impostazione canonica 3-tier. Illivello intermedio, solitamente descritto come application server, cioe il server ove risiede la logicaapplicativa, in questo caso cura soltanto la logica di presentazione e la comunicazione con i client.Il database sever, il terzo livello, ospita, oltre ai dati anche le procedure applicative scritte inlinguaggio PL/SQL, il linguaggio “interno” di Oracle.

3.3.2.3. Sistema di Gestione delle Biblioteche – SBNIl sistema gestionale delle biblioteche supporta il lavoro di acquisizione, catalogazione, col-

locazione e circolazione del materiale librario delle 5 biblioteche di area (oltre 70 fondi librari).Il sistema operante presso l’ateneo fiorentino e considerato una delle pietre miliari del Sistema




Bibliotecario Nazionale (SBN) ed e stato progettato e sviluppato dal personale dell’Universita diFirenze in collaborazione con altri enti coinvolti nel progetto finanziato direttamente dal Ministerodei Beni Culturali. Evoluto, e ri-ingegnerizzato piu volte nel corso degli anni, questo sistema e’in uso presso le piu importanti biblioteche (le biblioteche nazionali centrali di Firenze e Roma) eistituti (Treccani), nonche la Regione Veneto e l’Universita dell’Aquila.

Il sistema consiste in un insieme di transazioni scritte in linguaggio COBOL, gestite da unmotore transazionale classico (TDS), in ambiente mainframe BULL GCOS7. Il database su cuiinsiste il sistema e IDS II a struttura reticolare. Come gia accennato e in corso una valutazione(congiunta CSIAF e Sistema Bibliotecario di Ateneo) per evolvere l’intero sistema di gestione versouna piattaforma piu moderna.

Non essendo note al momento le caratteristiche del sistema che sara scelto si possono peroelencare alcuni fattori che possono facilitarne l’inserimento e la gestione nella Server Farm:

Architettura a tre livelli, in modo da separare il carico conversazionale e la logica applicativadalle attivita sulle basi dati. Eventualmente avere server separati per sfruttare le caratteristichedi sicurezza dell’infrastruttura di rete.Data base Oracle, in modo da sfruttare le conoscenze e unificare le attivita di gestione emanutenzione. Eventualmente ospitare le basi dati su un server esistente.Sistema operativo Unix, per gli stessi motivi del punto precedente.

3.4. Criticita emerse dalla ricognizioneI paragrafi precedenti elencano lo stato attuale dei server e dei servizi offerti in modo il piu

possibile neutro e oggettivo. In questo paragrafo sono invece elencate una serie di valutazionicritiche in relazione ad alcuni aspetti emersi durante la ricognizione.

Dalla ricognizione effettuata appare evidente la differenza di approccio, e di esigenze, chele strutture confluite nel CSIAF hanno utilizzato nell’acquisizione e nella configurazione dei varisistemi. Senza entrare nel merito della validita delle strategie adottate si possono estrapolare iseguenti punti che possono aiutare nella valutazione complessiva del “parco macchine” esistente eindicare direzioni possibili di evoluzione e di cambiamento per il progetto:

Vetusta. La maggior parte dei server e in funzione da piu di tre anni, con punte di cinque esei anni. Questo fattore e indice delle difficolta di reperimento dei fondi per l’aggiornamentodei sistemi, della mancanza di strategie e di protocolli a lungo termine con le ditte fornitrici,e della complessita degli iter burocratici sia di acquisto sia, soprattutto, di dismissione delmateriale obsoleto.Proliferazione. L’Universita di Firenze e “in rete” dal 1991; all’inizio, come e ovvio, conpochi sistemi sperimentali. In questi dieci anni di attivita si e avuta una evoluzione e unaespansione dei servizi, sia verso l’esterno, sia interni, che ha portato ad una moltitudine diserver di varie dimensioni e potenza, nella logica che ogni nuovo servizio abbisognasse di unserver. La situazione di “un servizio un server” e stata generata per vari motivi: la mancanza diun piano strategico unitario a lungo termine; l’evoluzione, a volte tumultuosa, dell’informaticache propone soluzioni e architetture non prevedibili con anni, se non mesi, di anticipo; i serviziesistenti, spesso di terze parti, ancorati ad architetture specifiche e/o antiquate che migranocon difficolta, o addirittura non possono migrare, alle nuove architetture hardware e software;sistemi acquisiti che non possono scalare per ospitare nuovi servizi.




Omogeneita. La crescita dei servizi offerti e, come abbiamo visto, dei server coinvolti, hagravato, per contro, su un pool ristretto di persone che ha gestito i servizi in pratica fino dal loroesordio. Cio ha portato, per una evidente ed implicita economicita di gestione, ad acquisireserver aventi lo stesso sistema operativo e software di base. In pratica la maggioranza deiserver rilevati sono prodotti da SUN Microsystems e “girano” lo stesso (nelle varie evoluzioni)sistema operativo: SUN Solaris. L’uniformare a livello di sistema operativo i vari server haportato i seguenti vantaggi: la conoscenza approfondita del sistema ha permesso al personaledi essere autonomo e risolvere situazioni critiche rapidamente; economia nella gestione delsoftware di base che viene installato e manutenuto con le stesse modalita su i vari server;possibilta di interscambio tra le persone che si occupano dei sistemi. Sono da notare alcuneeccezioni: il sistema di posta elettronica insiste su sistema operativo Digital Open/VMS, ilsistema di gestione delle segreterie studenti su IBM AIX, la sezione “Studenti” del sito webdi ateneo in ambiente Windows 2000.

Logica client-server a due livelli: e stata utilizzata moltissimo nel periodo di migrazione degliapplicativi gestionali dai mainframe, ad architettura centrica, ai sistemi (tipicamente UNIX) in rete.Essa e utilizzata da alcuni sistemi in ateneo tra i quali il piu importante e CIA. Il client-server adue livelli e considerato oramai obsoleto avendo dimostrato qualche limite; e essenziale la correttavalutazione delle problematiche indotte da questa architettura ai fini della collocazione di CIAnel modello proposto dal progetto. Sono qui elencati alcuni aspetti che verranno poi ripresi nelparagrafo 5.3:

I client, possedendo in pratica tutta la logica applicativa, tendono ad essere molto complessi,abbisognano di hardware potente ed essendo numerosi impongono un costo di gestione emanutenzione oneroso.I client, colloquiando direttamente con il database centrale, generano un notevole trafficodi rete, che spesso ha portato insoddisfazione all’utenza per i lunghi tempi di rispostadell’applicativo e costi per il potenziamento dell’infrastruttura di rete. I due aspetti appenacitati si possono sintetizzare nella scarsa propensione della logica a due livelli a scalare versoun elevato numero di postazioni di lavoro.Il database, essendo acceduto direttamente dai client (che all’Universita sono addiritura in retepubblica), e esposto in rete e quindi pone gravi problemi di sicurezza.

4. ProgettoDopo aver elencato nei capitoli precedenti gli obiettivi del progetto, lo stato attuale dell’infra-

struttura, dei server e dei servizi, questo capitolo introdurra il contensto in cui opera il progetto, isuoi limiti e i punti di vista strategico, architetturale e di sicurezza del problema.

4.1. Filosofia del progettoLa Server Farm, per definizione, costituisce le fondamenta su cui si basano i servizi informatici

offerti dal CSIAF all’ateneo e le attivita del personale del Centro. Cio implica il contatto con prati-camente tutte le unita organizzative del CSIAF, sia quelle direttamente coinvolte con l’erogazionedei servizi, sia quelle in back-end. Ai fini di una corretta iterpretazione del progetto e necessario“ritagliare” il dominio di responsabilit‘a della Server Farm. In particolare:

E responsabilita del progetto della Server Farm del CSIAF lo studio, la scelta delle




offerte sul mercato, l’implementazione e la messa in servizio:

Dell’architettura informatica di insieme della Server Farm.Dell’infrastruttura di rete dedicata alla Server Farm, in collaborazione con l’area opera-tiva “Servizi di Rete” per gli aspetti legati agli apparati di rete necessari e all’interazionedella rete della Server Farm con la rete di ateneo.Dell’architettura e la tecnologia dei server della Server Farm, analizzate le propostetecnologiche dei maggiori fornitori sul mercato.Dei sistemi operativi da installare sui vari server.Dei database, in collaborazione con l’area operativa “Sistemi Informativi”.Degli ambienti di sviluppo, intesi sia come server dedicati allo sviluppo di nuovi sistemi,sia come strumenti software (compilatori, interpreti, tools, ecc.), in collaborazioneprincipalmente con l’area operativa “Sistemi Informativi” e con altre che possonoabbisognare di tali strumenti.Del software per l’erogazione dei servizi di base.Dei sistemi di file server e di print server per la Farm e per il personale del Centro.Del sistema centralizzato di backup della Server Farm.Del sistema di monitoraggio.

Vista la complessita del progetto si e deciso di sentire il “Settore Gestione Sistemi” delCINECA, che ha terminato da poco la ristrutturazione della proria Farm. CINECA e in grado diapportare un notevole contributo al progetto avendo in carico, anche se in scala piu grande, gli stessiservizi della Server Farm, essendo fornitore dell’Universita di Firenze di alcuni servizi (CIA, Emailper gli studenti) e, soprattutto, avendo conoscenza ed esperienza sulle tecnologie che si intendeadottare nel progetto.

Un aspetto interessante della collaborazione, emerso fino dai primi incontri, e l’esperienza delSettore Gestione Sistemi nel campo dei sistemi in cluster e, soprattutto, nell’aver sperimentato consuccesso e adottato tecniche di alta affidabilita e divisione di carico con server Linux. L’adozionedi tali sistemi, prevista per alcune componenti nelle fasi preliminari del progetto, ma che inducevaalcuni dubbi soprattutto sulla complessita architetturale e sull’affidabilita, trova adesso un confortoprezioso che si basa su una solida esperienza.

4.2. Open Source, GNU, LinuxFino a poco tempo fa la valutazione di un qualsiasi sistema software da classificare come

“in produzione”, non avrebbe mai preso in considerazione software open source, ma sarebbe statosicuramente orientato alla valutazione di prodotti industriali. Oggi, sarebbe insensato non consid-erare attentamente i prodotti disponibili dalle comunita open source, in quanto hanno dimostratonel tempo caratteristiche di stabilita, performance, e adesione agli standard in assoluto non in-feriori ai prodotti industriali. Anzi ultimamente assistiamo alla tendenza, sempre piu diffusa,dell’integrazione dei prodotti open source all’interno delle suite software vendute dalle softwarehouse industriali: un esempio per tutti e il web server Apache, considerato unanimemente unprodotto di altissima qualita e integrato in molti prodotti (ad esempio Oracle).

La scelta di optare per il software open source, e una scelta di campo, filosofica, ma chepuo essere resa praticabile con un approccio pragmatico di valutazione, prodotto per prodotto, deibenefici e delle criticita rispetto allo stato dell’arte dei prodotti offerti dall’industria. Anche se,come appena detto, e indispensabile una valutazione puntuale, possiamo estrapolare un insieme




di punti che aiutano ad inquadrare il problema: sono di eseguito elencati i vantaggi, i problemi ealcuni criteri generali di valutazione del software open source.

1) Vantaggi

Economia. Il software con licenza GPL (o simili) e gratuito.Evoluzione. I software open source evolvono continuamente, sia per la correzione dierrori e per deficienze sulla sicurezza, sia per l’implementazione di nuove funzionalita. Eun fattore estremamente positivo, ma puo diventare un problema di gestione (vedi sotto).Adesione agli standard. L’etereogenita dei partecipanti allo sviluppo del software opensource garantisce, come effetto intrinseco al processo di sviluppo,l’adesione agli standard.Inversamente, nei casi ove non ci siano specifiche formali, spesso i prodotti open sourcedivengono essi stessi standard di fatto (vedi ad esempio il linguaggio PHP).Efficienza.E dimostrata continuamente l’altissima efficienza del software open source,dovuta probabilmente al processo “non economico” di sviluppo e alle conoscenze (allagenialita) delle persone che vi partecipano.

2) Problemi

Evoluzione. La continua evoluzione dei prodotti open source puo imporre una elevataattivita di gestione dovuta all’installazione di nuove versioni, patch, ecc.Contatto. L’aggiornamento, lo stato dell’arte, le linee di sviluppo, i problemi emersi,sono pubblicati nei siti web che ospitano lo sviluppo dei prodotti open source. Deveessere cura di chi li utilizza il verificarne periodicamente lo stato di evoluzione. Anchese questa e diventata una tendenza generale, adoottata anche dai sistemi industriali, deveessere prevista una periodica attivita di monitoraggio dello stato dell’arte di ogni prodottoadottato.Garanzia. Nessuna garanzia. E completa responsabilita dell’utente la scelta del prodotto,la corretta installazione e configurazione, la manutenzione.

3) Criteri generali di valutazione

Maturita del prodotto. Prodotti che hanno ancora in sviluppo parti essenziali, o sianomolto innovativi come architettura, o che abbiano team di sviluppo di poche unita, pos-sono indurre cambiamenti radicali del prodotto o nella configurazione adottata; possonoaddirittura cessare l’attivita di sviluppo e fondersi con altri gruppi che sviluppano prodottisimili. La maturita dei prodotti e un fattore essenziale nella scelta e nell’adozione di qual-siasi componente.Interesse. Prodotti che hanno una utenza vasta sono sviluppati da team di grosse dimen-sioni e possono contare su un feedback ampio e proveniente dalle piu diverse realta diinstallazione. I prodotti di vasto interesse sono normalmente affidabili ed efficienti; inquesta categoria si contano i prodotti che offrono i servizi “standard”: web server, MTA,ecc.Adozione da parte di utenti con requisiti simili alle proprie. Il confronto con entita chehanno gia operato una scelta e messo in servizio prodotti di interesse e che abbianorequisiti confrontabili con i propri, puo essere fonte di informazioni e indicazioni utili siaa livello di indagine, sia a livello di implementazione e configurazione dei prodotti.

Il prendere in considerazione il software open source, con i criteri e le limitazioni appena viste,




porta necessariamente a valutare il sistema operativo che e’ stato sviluppato dalla comunita opensource: Linux. Considerato all’inizio un esperimento, poi un sistema instabile da laboratorio e,infine, come un sistema operativo stabile ed efficientissimo, tanto da essere preso in cosiderazione,e addirittura offerto, dalle grandi case informatiche: IBM, SUN, HP. Soprattutto IBM ha fatto diLinux un cavallo di battaglia nella propria offerta di sistemi di piccola/media taglia e, ultimamente,lo offre anche come sottosistema operativo dei propri mainframe.

Linux e da considerarsi una scelta obbligata se si intende utilizzare prodotti software opensource. Anche se esistono porting e sviluppi paralleli su altre piattaforme dei principali prodotti,Linux e il sistema su cui vengono sviluppati, e rilasciati gia in forma eseguibile, tutti i prodotti opensource. L’unica seria limitazione di questo ambiente e la piattaforma hardware su cui gira in modo“nativo”: Intel o compatibile (AMD).

Anche se si registra una crescita impressionante delle capacita di questi processori, dei chipdi “glue”e degli standard di interconnessione delle periferiche, i sistemi che utilizzano questetecnologie si collocano nella fascia piu bassa, come caratteristiche di potenza, dei server. Comeconseguenza, ove servisse una potenza di calcolo o di I/O superiore a quella fornibile da un server diquesta classe e indispensabile ricorrere a sistemi proprietari di potenza medio/alta che implementanosistemi operativi UNIX (di solito sviluppati dalle stesse case che forniscono l’hardware). Uno opiu sistemi di fascia media (spesso con hardware ridondante) con sistemi operativi proprietari esoftware applicativo industriale e stato fino ad oggi l’approccio standard per qualsiasi servizio diuna certa importanza.

La rapidissima evoluzione del software di base per le comunicazioni in Linux, ha introdotto direcente varie tecniche che permettono, in una certa misura, di aggirare le limitazioni di potenza deiserver Intel. Il bilanciamento del carico applicativo su piu server e il bilanciamento del traffico di retesu piu interfacce, si candidano come tecnologie di base per raggiungere gli obiettivi architetturaliprevisti: ridondanza e scalabilita.

In conclusione, nei casi in cui il software applicativo open source offra le caratteristichenecessarie al progetto, si ritiene percorribile la via di insiemi di server Linux, equipaggiati delletecnologie appena accennate, per l’offerta di alcuni servizi. Al costo, forse, di una attivita piuonerosa di installazione, avremo sicuramente un notevolissimo risparmio economico, considerandola differenza di costo dell’hardware e delle licenze di acquisto e manutenzione degli applicativi.Affrontando il problema dal punto di vista opposto e possibile enunciare che se il costo economico diinstallazioni “standard”, magari prese in considerazione in una prima istanza, portassero i progettofuori dal budget disponibile, e possibile riesaminarlo in un contesto open source piu economico.

4.3. ArchitetturaQuesto paragrafo illustrera il disegno generale della Server Farm, il contesto (framework) che

racchiude tutti i sistemi coinvolti nel progetto.

La Figura 2 illustra schematicamente l’architettura generale della Server Farm evidenziandonesoprattutto gli aspetti della topologia delle varie reti locali che la compongono, della sicurezza,dell’organizzazione dei server e del posizionamento dei componenti di rilievo.

I sistemi, sia nella sezione di front-end sia nella sezione applicativa, sono organizzati incluster. Per cluster si intende in qusto caso la capacita di piu di un server di offrire lo stessoservizio in modo di aumentare le capacita di carico durante il normale funzionamento e garantire lacontinuita dei servizi in caso di guasto di un server. La “collaborazione” dei server che offrono lo




F W

RS RS RS RS

F W

AS

F W DB DB

AS

SAN

F W

1 Gb Eth

ENALP.22

DNS2

Internet

150.217.C7200

ENALP

.1

.3

DR

. . .

DR FS

. . .

. . .

Cluster di Front−End

Cluster Server Applicativi

Database Cluster

MGT BCK

Sezione di Front−End

Sezione applicativa

Sezione di Back−End

LAN di Management

Fig. 2– Architettura generale della Server Farm

stesso servizio non avviene (come nei veri cluster) mediante meccanismi interni ai server stessi, mamediante l’azione di elemento esterno (DR in figura) che provvede a dirigere le richieste provenientidall’esterno, sulla base del servizio richiesto, ai vari server. Ogni server lavora autonomamente,senza avere cognizione che altri possono offrire lo stesso servizio.

La Figura 2 riporta, per quanto riguarda l’infrastruttura di rete, tre reti locali separate da firewalle una LAN dedicata al management. L’organizzazione a bastioni multipli dovrebbe garantire allasezione di back-end, la piu interna (che custodisce i database), un livello adeguato di sicurezzadisaccoppiando i client che richiedono i servizi dai server applicativi mediante i proxy della sezionedi front-end e controllando i flussi di informazione tra le varie LAN mediante i firewall. La rete dimanagement permette l’accesso per la configurazione e il controllo dei vari sistemi solo dal sistemadi management (MGT in figura); offre inoltre la possibilita di usufruire del sistema centralizzato dibackup (BCK in figura) senza appesantire il traffico sulle altre LAN. Non sono rappresentati, per




mantenere leggibile lo schema, gli apparati di rete e le modalita di collegamento dei vari server, chesaranno descritti nel capitolo 5.

Sulla destra della Figura 2 e rappresentata la Storage Area Network (SAN), sebbene sia unelemento che interessa piu il tema tecnologico che architetturale. Lo schema riporta, comunque,quali sistemi la SAN dovrebbe assistere, garantendo (come illustrato nel paragrafo 8.2) performancee flessibilita di gestione.

Il disegno architetturale proposto in Figura 2 risponde pienamente ai requisiti e agli obiettivi diprogetto, ma introduce una complessita, soprattutto come numero di sistemi necessari ad attuarlo,troppo alta per essere messo in produzione nei termini previsti dal progetto. Si ritiene quindiopportuno implementare in un primo momento solo una parte del disegno appena illustrato, inmodo da verificare “sul campo” le scelte operate (ed eventualmente aggiustarle), per poi completareil disegno in una fase successiva. Le parti da implementare secondariamente sono sostanzialmentedue: la sezione di front-end e la LAN di management.

F W

AS

F W DB DB

AS

SAN

F W

1 Gb Eth

ENALP.22

DNS2

Internet

150.217.C7200

ENALP

.1

.3

DR FS

. . .

. . .

Cluster Server Applicativi

Database Cluster

Sezione applicativa

Sezione di Back−End

BCKMGT

Sede del Rettorato

Fig. 3– Architettura generale della Server Farm — Deployment iniziale

La parte di front-end, prevista dal progetto come interfaccia verso l’esterno attraverso l’uso disistemi di proxy, imporrebbe un firewall e un bilanciatore di carico in alta affidabilita e un insiemedi server per ospitare i sistemi proxy. La posticipazione di questa sezione riduce senz’altro il livellodi sicurezza dell’intero sistema, ma permette di concentrare, senza rinunciare a nessun servizioprevisto, le attivita di implementazione e di tuning sulla parte piu critica: la sezione applicativa.

La LAN di management puo essere rimandata o addirittura tolta dal progetto senza che esso nerisenta notevolmente. Concentrando le attivita di backup dei sistemi durante le ore notturne, quandocioe il traffico e piu basso, non dovrebbero presentarsi problemi di saturazione degli apparati di rete.




Per il monitoraggio e la configurazione dei sistemi e proponibile,se i sistemi sono in numero limitato,il collegamento in seriale facendo funzionare come concentratore il sistema di management. Talesoluzione avrebbe come vantaggi minori problemi di sicurezza e di configurazione.

Anche da un punto di vista economico il posticipare le reti di front-end e di managementpermette un margine di manovra piu ampio nelle parti del progetto piu critiche o piu onerose,ad esempio i server per i database e la SAN. La Figura 3 sintetizza gli aspetti appena discussi,mostrando l’architettura generale al primo stadio di implementazione.

In conclusione l’architettura generale, anche se implementata all’inizio solo parzialmenterispetto al disegno completo, soddisfa i prerequisiti imposti dagli obiettivi del progetto e le necessitadiscusse nei capitoli precedenti; viene proposta di seguito una lista che riassume gli aspetti salientidell’architettura proposta:

Organizzazione modulare dell’infrastruttura di rete e di sicurezza.I server collaboranti mediante un divisore di carico possono scalare in base alle esigenze,aggiungendo semplicemente altri server all’insieme.Avendo ogni servizio ripartito su piu server si ha continuita di servizio anche a fronte dellarottura di un server (fault-tolerance).L’architettura e indipendente dalla tecnologia dei server utilizzati: si possono usare pochiserver di fascia media o piu server di fascia bassa in tecnologia Intel (Linux) a seconda delleesigenze delle piattaforme applicative.I server sono assistiti da tre componenti di servizio: il sistema centralizzato di backup; il fileserver; il sistema di management.

5. ReteL’infrastruttura di rete della Server Farm costituisce, di fatto, il contesto entro il quale operano

tutti gli altri sistemi. I paragrafi seguenti illustrano gli aspetti topologici, tecnologici e di sicurezzadella rete interna alla Server Farm.

5.1. TopologiaLa topologia delle reti locali (LAN) interne alla Server Farm, come si desume dalla Figura 3,

e costituita da due reti: una LAN su cui insistono i server applicativi, e collegata alla rete diateneo attraverso un firewall e, mediante un secondo firewall, verso la LAN piu interna che ospitai database e i sistemi di controllo e di gestione. La scelta di due firewall in cascata, rispetto ad unfirewall a tre vie, e giustificata essenzialmente da due fattori: il troughput e la semplificazione dellaconfigurazione, come descritto piu in dettaglio nel paragrafo 5.3.

5.2. TecnologiaLe due LAN saranno implementate utilizzando lo standard Ethernet. Per garantire il troughput

previsto gli switch saranno collegati tra loro e con i firewall con interfacce a 1Gb/s, mentre i sistemisaranno collegati alla rete con interfacce a 100Mb/s o ad 1Gb/s in funzione del loro carico di lavoro.

Tutti gli apparati di rete (switch) dovranno essere configurabili e monitorabili da remoto e saravalutata la possibilita di installarne in ridondanza in modo da pemettere il funzionamento della reteanche in caso del guasto di un componente.

Poiche e prevedibile che i server saranno installati in rack, i collegamenti tra i server e gliswitch saranno in rame, mentre i link tra i rack e verso la rete di ateneo saranno in fibra ottica.




5.3. Sicurezza e firewallLa sicurezza dell’intero sistema e affidata principalmente ai firewall i quali saranno pre-

posti principalmente al filtraggio delle connessioni provenienti dall’esterno, permettendo l’accessosoltanto ai servizi previsti. I firewall, inoltre, si occuperanno di trasformare gli indirizzi privati deiserver in indirizzi pubblici (NAT). L’utilizzo di spazi di indirizzamento privato nelle LAN interne,insieme alle attivita di filtraggio e di NAT dei firewall garantisce un accettabile livello di sicurezzadei sistemi verso l’esterno, mantenendo alto il livello di interoperativita e di servizio tra i serverall’interno delle LAN.

I firewall saranno costituiti da coppie di sistemi Linux in alta affidabilita sfruttando le carat-teristiche di filtraggio del kernel e del software iptables. La soluzione piu economica sarebbe diinstallare un solo firewall con tre interfacce: la prima vesro la rete esterna, la seconda verso la LANapplicativa e la terza verso la LAN di back-end. Poiche le interfacce del firewall saranno a 1Gb/s,esiste la possibilita che si saturino le capacita interne, ad esempio il bus PCI, del firewall creandoun collo di bottiglia. Viceversa, installando due firewall in cascata, a fronte di un maggior costoeconomico, si ha la sicurezza che i firewall possano mantenere i traffico teorico della rete Etherneta 1Gb/s; come effetto secondario si semplificano notevolmente gli schemi di filtraggio e di routing,facilitando le operazioni di mantenimento.

Lo schema architetturale a doppio bastione, che pone i sistemi piu critici nella LAN piuinterna, e pensato principalmente per la protezione delle basi di dati e dei sistemi che le ospitano.Il firewall centrale dovrebbe permettere l’accesso ai database server solo dai server applicativi inmodo tale da isolare ulteriormente la sezione di back-end dall’esterno. Purtroppo l’architettura adue livelli utilizzata da CIA impone che ogni postazione di lavoro dell’utenza si debba collegaredirettamente con il databse server; i firewall, pertanto, dovranno essere configurati in modo tale chele postazioni su cui e installato CIA possano aprire connessioni verso il database server. Tutto cioriduce notevolmente l’efficacia dell’intero disegno.

Si possono, per ora, ipotizzare due soluzioni, ma e necessario discutere con CINECA ilproblema della sicurezza della Server Farm in relazione all’uso di CIA. Le due ipotesi sono:

1) Collegare con una terza interfaccia il firewall piu interno verso la rete di ateneo. In questomodo si snellirebbe la configurazione del primo firewall, ma si otterrebbe un livello di sicurezzaparagonabile a quello odierno.

2) Porre un server di VPN (Virtual Private Network) nella LAN applicativa (o quella di back-end)e installando i relativi client su ogni postazione utente.

6. Sezione di front-endLa sezione di front-end, composta essenzialmente da sistemi di proxy, garantisce il disaccop-

piamento delle connessioni dei client dai server applicativi. Come accennato nel paragrafo 4.3questa sezione verra implementata in un secondo momento.

7. Sezione applicativa

7.1. TecnologiaLa sezione applicativa della Server Farm sarta popolata di server predisposti all’offerta, princi-

palmente, dei servizi “standard” di Internet. In questo campo il software open source e consideratoeccellente; si prevede, pertanto, l’utilizzo di server Linux che ospitano i principali servizi.




I server applicativi saranno coadiuvati da un sistema (Linux) in alta affidabilita che opereracome bilanciatore di carico mediante il software LVS (Linux Virtual Server). Per massimizzarela capacita di carico dell’intero sistema si e optato (tra le varie configurazioni possibili) per laconfigurazione DR (Direct Routing) dell’LVS.

7.2. Servizi

7.2.1. DNSIl DNS, implementato utilizzando il software standard di Berkeley BIND, non si presta come

servizio a valle del bilanciatore di carico poiche il carico generato dai client verso il DNS e bassoe la duplicazione su piu server del servizio aumenterebbe soltanto il traffico di rete verso i serveresterni di livello gerarchico piu alto, duplicando inutilmente le cache dei server locali.

Tenendo conto dello scarso utilizzo delle risorse dei server da parte del software LVS (spe-cialmente in modalita DR), il sistema in alta affidabilita del bilanciatore di carico e ottimale perospitare il servizio DNS.

7.2.2. WWWRitenendo strategici la progettazione e lo sviluppo in un unico contesto della parte statica,

informativa, del sito web di ateneo e della parte dinamica orientata ai servizi, la piattaformasoftware per i servizi WWW dovra soddisfare entrambe le necessita. Inoltre l’evoluzione dellaparte informativa statica verso un sistema dinamico di content management e altrettanto importantee porta a valutare soluzioni software verticali.

L’offerta Oracle della propria piattaforma Application Server e Portal, illustrata recentementedai tecnici Oracle in una serie di seminari tenuti presso il CSIAF, potrebbe soddisfare le necessitaappena esposte oltre ad un insieme di possibilta, come valore aggiunto, che innalzerebbero sicura-mente il livello qualitativo e di servizio del sito web di ateneo. Sono elencate di seguito, in estremasintesi, alcune delle caratteristiche salienti del prodotto Oracle:

Il motore HTTP e Apache standard con alcuni moduli (in aggiunta a quelli standard tipo PHPo PERL) per l’interfaccia verso i database Oracle (PL/SQL) e verso l’ambiente Java.L’Application Server (AS) e un motore Java in grado di agire come Servlet container e comecontainer per gli Enterprise Java Beans. Questi sono rispettivamente lo standard attuale pressoil CSIAF per la produzione dei servizi via WWW e la piattaforma, piu complessa, verso laquale potrebbero convergere i servizi in futuro.Il software di portale, che permette funzionalita di alto livello,sia per il processo di managementdei contenuti sia per la naturale integrazione della parte informativa e di servizio. L’ambientedi portale e integrato in AS.Il sistema di management permette, mediante l’uso di un database di repository, la configu-razione e la gestione di tutti gli aspetti dell’AS ed eventualmente anche dei database associati.L’AS puo essere configurato su piu server a valle di un bilanciatore di carico. Il softwaredi management e in grado di replicare la configurazione su piu server mediante l’uso delrepository.L’AS, o meglio tutti gli applicativi e i servizi via WWW, possono usufruire dell’infrastrutturadi Single Sign On che permette all’utente di autenticarsi una sola volta per qualsiasi serviziovoglia utilizzare.




L’AS incorpora anche un server LDAP v3 che oltre alle funzionalita previste dallo standardoffre una capacita di interfaccia diretta verso i database Oracle. Questa caratteristica permet-terebbe il caricamento e la gestione dei contenuti del directory server con modalita molto piulineari e rapide rispetto a quelle degli altri prodotti.L’AS permette la produzione di report, sia a stampa che pubblicabili via WWW, con strumentiinterattivi che si interfacciano direttamente con il portale, i database ed eventualmente con icubi di data warehouse.Il pacchetto di gestione delle segreterie studenti (GISS) adotta questa piattaforma per lapresentazione via WWW verso i client; GISS sarebbe perfettamente integrabile con indubbivantaggi di gestione e di economia.

Nell’eventualita che i prodotti Oracle non siano economicamente sostenibili la scelta alterna-tiva, che ricadrebbe su prodotti open source, potrebbe essere la seguente:

Apache come motore HTTP con i moduli per PHP, PERL e Java.Jakarta/Tomcat come servlet container.Envolution per il portale ed il content management.OpenLDAP per il directory service.Sarebbero da valutare sistemi per la produzione di report.Il Single Sign On sarebbe da integrare.

Nel caso si opti per i prodotti Oracle per la piattaforma applicativa la scelta dell’hardwarepuo essere vincolata dal tipo di accordo tecnico/economico che si stipulera con il fornitore. Poichenormalmente Oracle quota i propri prodotti in base al numero di processori che saranno utilizzati dalcliente, nel caso venga applicata questa politica, puo essere economicamente vantaggioso sceglierehardware che offra la maggiore potenza possibile per CPU, tipicamente sistemi di fascia mediacon processori RISC a 64 bit. Nel caso invece venga stipulato un agreement complessivo, checi svincolasse dal numero di CPU che utilizzeremo, potrebbero essere impiegati anche per questaparte server Linux a basso costo.

Mentre si da per scontato che servizi on-line via WWW insistano su database relazionali(Oracle), il catalogo on-line per le biblioteche (OPAC/WWW) utilizza un sistema di informationretrieval dedicato (vedi paragrafo 3.3.1.2). Per l’OPAC si ipotizza di integrare la parte procedurale(procedure CGI in TCL/Sibylla) nei server applicativi, in modo da sfruttare il bilanciamento dicarico, mentre la base di dati sara ospitata da un server dedicato.

7.2.3. ProxyPer il servizio di proxy WWW verra utilizzato il software open source Squid. Per il proxy,

la cui attivita principale e di mantenere una cache locale dei documenti web consultati in Internet,potrebbero valere i concetti che ne limitano l’uso a valle di un bilanciatore di carico visti per il DNSnel paragrafo 7.2.1. Sembra comunque sia possibile, con una particolare configurazione di LVS edi Squid, fare cooperare piu cache di pari livello; tale possibilita sara valutata in dettaglio durantela fase di deployment del servizio. Successivamente, stabilizzato il servizio, puo essere affrontatala valutazione di evolvere il sistema verso il “transparent proxy”, ovvero di rendere automatico ilfunzionamento del sistema senza dover configurare ogni client per l’utilizzo del proxy.

7.2.4. EmailIl servizio di Email e ormai consolidato da anni ed e il servizio che coinvolge il piu alto

numero di utenti, circa 5000. Si ritiene comunque necessario valutare i software disponibili, siaIl materiale tecnico e le informazioni contenute nel presente documento sono di natura strettamente confidenziale edi esclusiva proprieta del CSIAF. Non e consentita la divulgazione e la riproduzione totale o parziale senza esplicitaautorizzazione.



open source che industriali, soprattutto al fine di integrare questo servizio con gli altri e di unificarela piattaforma operativa. I pacchetti dovranno essere valutati, come gli altri, in funzione delle loropotenzialita e della loro rispondenza ai requisiti che si ritengono necessari, ma soprattutto dovrannoessere esaminate le problematiche di passaggio dal sistema attualmente in uso verso quello giudicatoidoneo, in modo da rendere il piu indolore possibile all’utenza l’utilizzo del nuovo sistema.

L’adozione di un nuovo sistema di Email dovrebbe migliorare sia gli aspetti di gestione che laqualita e la potenzialita del servizio; in particolare:

I server che ospiteranno il servizio saranno Linux o Unix, la loro gestione e manutenzionesara omogenea con gli altri server; ad esempio l’aggiornamento del sistema operativo, l’usodel sistema centrale di backup e il monitoraggio saranno gli stessi degli altri server.La parte di front-end, cioe la ricezione dei messaggi via SMTP/ESMTP ed il controllo deivirus, puo essere implementata su piu server, mediante il controllo del bilanciatore di carico;si otterranno cosi i vantaggi visti per gli altri servizi.Il sistema di Web Mail, cioe l’interfaccia via WWW per l’uso della posta elettronica, ad oggiun po’ rudimentale, potra essere integrata con gli altri servizi e utilizzare software allo statodell’arte. Cio potrebbe portare ad utilizzare normalmente questo sistema al posto dei client(OutLook, Eudora, ecc.) attualmente in uso ed minimizzare le problematiche di installazionee di funzionamento presso l’utenza.L’interfacciamento verso il directory server (LDAP) e verso il sistema di Single Sign Onportera questo servizio a integrarsi completamente con gli altri, facilitandone l’uso all’utente eal tempo stesso riducendo di molto la complessita di gestione al personale della Server Farm,soprattutto riguardo alla gestione delle mailing-lists.

I pacchetti software che saranno comparati al fine di trovare il migliore rapporto tra funzionalia,gestione, migrazione e costi saranno:

PMDF su sistema operativo UNIX, di InnoSoft. Questo e il pacchetto che attualmente e infunzione sul sistema OpenVMS. Sara il punto di riferimento per la valutazione degli altrisistemi.Postfix. E un prodotto originariamente sviluppato da IBM e da qualche tempo reso pubblico.Progettato per superare le difficolta di configurazione e le scarsa sicurezza di sendmail, si poneoggi come una delle MTA di riferimento nell’ambiente open source. E il software scelto daCINECA per il servizio di posta elettronica per gli studenti.Qmail. E il piu sicuro dei software di Email in circolazione. La sua sicurezza risiede anchesulla semplicita con cui sono implementati i vari servizi. Conta un numero elevatissimo diutenti soprattutto in realta molto grandi e sono disponibili molti pacchetti per aumentarne lecapacita: imap, autenticazione sicura, LDAP, ecc.Courier. Software completamente sviluppato dalla comunita open source (il sito web e ospitatosu Source Forge) ricalca la filosofia di Qmail, ma e molto piu aderente agli standard. Lacaratteristica saliente e il motore di filtraggio dei messaggi, che risiede all’interno del nucleodel programma, e che permette l’eliminazione e la corretta gestione del traffico di spam. Edotato di tutti i servizi, compreso web mail.

7.2.5. FTPIl servizio di FTP e ad oggi scarsamente utilizzato. Potrebbe essere, al contrario, un servizio

molto utile che il CSIAF potrebbe dare all’ateneo. Installando un server affidabile e sicuro




(es. ProFTPD) per chi utilizza direttamente il protocollo FTP e potenziando il servizio mediantel’accesso ai files via WWW per gli utenti che non lo conoscono, potrebbero essere resi disponibili:le principali distribuzioni di Linux, gli aggiornamenti e le patch di Windows e i principali pacchettisoftware. Tutto cio permetterebbe all’utenza di avere un luogo “vicino” di facile e di rapido accessoe al contempo un sicuro risparmio di traffico verso, e soprattutto da, l’esterno per il download delsoftware.

La Server Farm si dotera comunque di server per l’accesso FTP, essendo necessario, adesempio, per l’upload dei documenti web e per altri servizi (vedi paragrafo 3.3.1.4), cosi come saradisponibile il file sharing via WWW per facilitarne l’uso. La quantita, il tipo di informazioni e lapolitica con cui saranno disponibili all’utenza esula pero dallo scopo del progetto.

7.2.6. LDAPIl servizio di directory, presente da anni in rete, solo ultimamente ha conosciuto un vero

e proprio sviluppo, tanto da divenire un servizio essenziale. Poiche adesso anche i servizi piudiffusi (ad esempio Email) basano le fasi di autenticazione e autorizzazione sul protocollo LDAP,la costituzione di un directory server centrale che contenga le informazioni del personale e deglistudenti e da considerarsi obbligatoria.

E attualmente allo studio, con un gruppo di lavoro presso il CSIAF, sia il contesto piu pret-tamente tecnologico rivolto principalmente alle tecniche di autenticazione e al mantenimento deidati, sia la valutazione, logica e strutturale, delle informazioni che saranno disponibile nel directorytree. Il gruppo sta inoltre valutando le caratteristiche tecniche dei vari server disponibili sul mercatoe le loro capacita di interfacciamento verso i database di produzione; in altre parole il gruppo dilavoro sta cercando il prodotto che permetta il modo piu agevole di alimentazione dell’LDAP con icontenuti dei database del personale e degli studenti.

7.2.7. Streaming

7.2.8. Segreterie StudentiL’applicativo GISS, fornito da Sistemi Informativi, si basa completamente sulla piattaforma

Oracle: il modulo FORMS dell’Application Server per la presentazione via WWW ai client e ildatabase per i dati e le procedure in PL/SQL.

Nel caso, auspicato, in cui si decida di adottare la stessa piattaforma per il sito web diateneo e per i servizi online, la parte di presentazione di GISS sarebbe integrata agli altri servizicondividendone i server e le caratteristiche, come descritto nel paragrafo 7.2.2.

7.3. Servizi interni

7.3.1. File serviceIl file server riveste un ruolo centrale nell’architettura della Server Farm; poiche molti servizi

saranno installati su piu di un server, il file server funzionera da repository per le configurazioni diogni servizio. Le informazioni saranno sincronizzate sui server applicativi (ad esempio via rsync)o accedute dai server come filesystem remoti (NFS).

Il file server esportera, mediante i protocolli NFS e SMB, spazi disco propri per le attivita delpersonale della Server Farm e altri spazi a comune per favorire e semplificare il lavoro di gruppo e




lo scambio di informazioni tra il personale del Centro. Gli spazi disco messi a disposizione sarannoaccedibili sia da stazioni Windows (via SMB) che Unix/Linux (via NFS).

Il file server sara costituito da una coppia di sistemi Linux in alta affidabilita; il sistemaesportera i filesystem sia attraverso la modalita nativa Networked File System, sia attraverso ilserver Samba per interfacciare le stazioni Windows. I due server condivideranno i dischi o, meglio,useranno gli stessi volumi messi a disposizione dalla SAN.

7.3.2. Print serviceI servizi di stampa saranno resi disponibili dallo stesso sistema di file server. Con modalita

simili allo share dei filesystem il sistema permettera l’uso delle stampanti della Server Farm sia allestazioni Windows, mediante Samba, sia alle stazioni Linux/Unix mediante i servizi nativi di remoteprint.

La Server Farm si dotera di stampanti adeguate alle necessita del centro; si prevede di utilizzareuna stampante HP in bianco/nero formato A3 con fronte/retro da 32 ppm gia presente al CSIAF edi acquisirne una nuova a colori con caratteristiche simili.

8. Sezione di back-end – Database e servizi ausiliari

8.1. DatabaseLe basi di dati rivestono l’aspetto piu importante della sezione di back-end; il doppio bastione

di firewall e posto proprio per dare una maggiore sicurezza ai database ospitati da questa sezione.

Poiche i principali sistemi gestionali utilizzano i database Oracle e anche i servizi online,fino dal 1998, accedono via JDBC allo stesso motore di database, non c’e ragione di valutare unRDBMS alternativo.

Viceversa l’organizzazionee la gestione dei database a tutt’oggi e assai poco efficace; in praticaogni applicativo ha uno (o piu) database server dedicato, imponendo una duplicazione delle attivitadi aggiornamento del software di sistema e del RDBMS. Anche l’hardware necessario risulta ineccesso rispetto ai risultati ottenuti, e impone l’uso di sistemi costosi.

Recentemente Oracle ha introdotto la tecnologia di cluster per il proprio motore di database,denominata RAC (Real Application Cluster), che permette a piu server (a uno o piu processori)di coordinarsi e di lavorare “in gruppo” sulle stesse basi di dati. Utilizzando tale tecnologia siavrebbero una serie di vantaggi:

Fault-tolerance e scalabilita. Valgono gli stessi criteri espressi nel paragrafo 4.3. Come per iserver applicativi il cluster di database avrebbe gli stessi vantaggi.Snellimento delle procedure di gestione. Avendo server uguali ed una sola versione delRDBMS la manutenzione e l’aggiornamento dei sistemi e meno onerosa. In aggiunta epossibile mettere in manutenzione un nodo (server) del cluster alla volta mantenendo attivi iservizi.Hardware. L’impiego di piu server apre la possibilita di installare server di fascia bassa,ottenendo un risparmio economico.

L’adozione del RAC come motore centrale di database impone pero alcune limitazioni chedevono essere attentamente valutate: la piu importante risiede nel numero di istanze di database.Il RAC e concepito per coordinare il lavoro di piu server sulla stessa istanza di database; su ogni




server risiede il software e tutto l’ambiente operativo di una istanza. Nel caso si abbiano N istanzesu M server si dovranno gestire N * M configurazioni; risulta dunque essenziale cercare di ridurreal minimo il numero di istanze necessarie.

Ad una prima analisi sembrerebbe possibile unificare l’istanza del database di GISS coni servizi online, i quali utilizzano in gran parte gli stessi dati, ottenendo anche una maggioreefficienza ed eliminando quasi totalmente le attivita notturne di trasferimento di dati tra serverdiversi. Appare invece piu problematica la situazione che riguarda CIA, che impone attualmentequattro istanze (tre di produzione e una di test). Sara necessario un studio piu approfondito delproblema coivolgendo i tecnici che si occupano di CIA al CINECA.

La seconda limitazione imposta dal RAC e di tipo tecnologico/economico; i server devonomontare un sistema di clustering e, soprattutto, devono accedere contemporaneamente allo stessospazio disco imponendo, di fatto, l’utilizzo di una SAN. Dovranno quindi essere valutati in dettaglioi rapporti costo/beneficio dei vari componenti del sistema (Numero e potenza dei server, softwaredi clustering, software del RAC, SAN) per operare una scelta ottimale.

Si ipotizzano alcuni scenari possibili:

1) Server separati, nessun cluster. Si tratta della semplice evoluzione che porta i server attualiall’interno della nuova struttura della Server Farm. I server potrebbero essere gli stessi (o dinuova acquisizione), della stessa classe e con caratteristiche simili a quelli esistenti. I costi,la gestione e le caratteristiche di servizio sarebbero simili a quelle odierne. Il miglioramentodelle prestazioni si ottiene acquistando server piu potenti.

2) Cluster di server di fascia media (RAC). Un cluster a due o massimo tre nodi costituito daserver di media potenza da 4 o 8 processori; sistema operativo Unix; necessita del softwaredi clustering; Connessione ridondata alla SAN. E, rispetto alla precedente, una soluzione conmigliori caratteristiche di servizio, che unisce la potenza dei server di fascia media con lecaratteristiche dei cluster; i costi dei componenti sono alti.

3) Cluster di server Linux (RAC). Un cluster da quattro a otto nodi costituito da server Intel da 2o 4 processori; sistema operativo Linux; il software di cluster e incluso nel RAC; connessionealla SAN. E lo scenario piu aggressivo dal punto di vista tecnologico; i punti critici possonoessere: la gestione, a causa dell’elevato numero di nodi del cluster; l’innovazione, in un’areain cui la stabilita e essenziale.

4) Coppie di server in Cluster HA (Unix o Linux). Due coppie di server a 4 processori; sistemaLinux o Unix (nel caso di Unix il software di clustering va acquistato); connessione ridondataalla SAN. Ogni server ospita una o piu istanze di database (distribuite in base alla stima delcarico). In caso di guasto il server in coppia offre, in modo degradato, anche i servizi del primo.Questa scenario, piu conservativo rispetto al RAC, risponde pero alle esigenze di flessibilitasul numero delle istanze di database, che e destinato a crescere in futuro; garantirebbe inoltrel’isolamento tra le applicazioni, che puo essere un vincolo imposto dalle aziende fornitrici deipacchetti applicativi. Il numero di configurazioni e N * 2.

8.2. Storage Area NetworkLa Storage Area Network (SAN) e un elemento infrastrutturale sul quale si basano molte scelte

architetturali del presente progetto.

Dal punto di vista fisico si tratta di uno o piu controller dischi ad alte prestazioni in configu-razione ridondata che gestiscono uno o piu array di dischi. I controller espongono verso i sistemi




interfacce in fibra ottica a 2Gb/s di tipo Fibre Channel Arbitrated Loop (FC-AL). I dischi contenutinegli array sono acceduti mediante un doppio canale FC-AL in rame. La connessione dei serverviene effettuata mediante switch ottici (solitamente a 16 o 32 porte) che collegano gli adattatori infibra ottica installati sui server ai sistemi a dischi.

Dal punto di vista logico e funzionale si nota innanzitutto che lo storage, normalmente internoai server e gestito in modo autonomo, e invece un sistema centralizzato a se stante, con propriefunzionalita di gestione e di amministrazione, che offre come “servizio” lo spazio disco di cui i variserver abbisognano. La centralizzazione dello storage offre, come conseguenza diretta, una unicainterfaccia per il management di questa risorsa per tutti i sistemi e una estrema flessibilita nellapianificazione e nella assegnazione di spazio disco ai vari server.

Altra importante caratteristica introdotta dalla SAN e la possibilita di implementare i servercome cluster in alta affidabilita (HA). Infatti in caso di guasto di un server o di un suo componenteo servizio, l’altro server della coppia, che monitorando i servizi dell’altro si accorge del guasto,“eredita” l’accesso alla SAN del primo server e offre oltre ai propri anche i servizi del server guasto.Anche se esistono in commercio altre soluzioni per lo share di dischi per i cluster HA, ad esempiocontroller SCSI intelligenti che permettono la presenza sul bus SCSI di due server contemporanei,o degli array di dischi esterni con doppio accesso, la soluzione SAN offre sicuramente le carat-teristiche migliori come sicurezza, gestione e flessibilita di utilizzo. Quest’ultima caratteristica eestremamente importante in una realta come quella del CSIAF in cui si ha una continua e rapidaespansione e diversificazione dei servizi offerti.

L’implementazione di una SAN nella Server Farm alza pero il costo dell’operazione. Infattil’alta tecnologia dei componenti l’infrastruttura (controller, adattatori, switch e dischi), ma soprat-tutto la classe di mercato in cui questi componenti si collocano, pongono la SAN come elementoche economicamente non e trascurabile anche se riferito all’intero progetto.

8.3. Sistema di BackupIl sistema centralizzato di backup e uno degli obiettivi del progetto; attualmente i server

provvedono al salvataggio dei dati e degli ambienti software mediante dispositivi (normalmentestreamer DDS a 4mm) interni ai server stessi o sfruttando via rete i drive di altri server nei momentiin cui essi non sono utilizzati. La gestione dei salvataggi risulta piuttosto intricata e prona all’errore;le procedure di salvataggio, che indirizzano direttamente o remotamente i drive a nastro, presentisui sistemi devono essere sincronizzate e devono tenere in conto i volumi di dati da salvare e ladurata di ogni operazione. I sistemi periferici (le stazioni di lavoro e i server di workgroup) nonhanno possibilita di backup o, al massimo, utilizzano spazi disco temporaneamente disponibili deiserver.

Il progetto prevede un sistema (Linux) per gestire in modo centralizzato i backup; il serversi interfaccera ad un dispositivo a natri con tecnologia LTO da 100 GB a due drive e libreriaautomatica (autochanger) da almeno 15 nastri, mediante bus SCSI. Al fine di disaccoppiare leattivita di salvataggio dei server (e delle stazioni di lavoro) dalla scrittura fisica sui nastri, il serverdi backup sara dotato di dischi, da utilizzare come buffer, con capacita almeno doppia dei nastriutilizzati (circa 400 GB).

Sono inoltre disponibili software open source per la gestione centralizzata dei backup (adesempio AMANDA) che permettono la schedulazione dei backup, completi e incrementali, deiserver e l’utilizzo efficiente delle librerie di nastri. Questi software sono in grado di interfacciare




i sistemi Windows, in modo da poter ricevere i backup anche dalle stazioni di lavoro di tutto ilpersonale ed eventualmente da server con questo sistema operativo.

Dovranno invece essere valutate in dettaglio tecniche che permetteranno il salvataggio in modofisico delle partizioni di sistema, sia dei server sia delle stazioni di lavoro, al fine di permettere unripristino rapido delle funzionalita in caso di guasto ai dischi di sistema, evitando la reinstallazionedei sistemi operativi e dei software di base.

8.4. MonitoraggioLo sforzo progettuale teso alla massima unificazione dei server e dei sistemi operativi all’inter-

no della Server Farm, trova nel sistema di monitoraggio la sua migliore giustificazione. Si ritieneinfatti indispensabile, dato il numero di server, del numero e della complessita dei servizi, unsistema che permetta in tempo reale l’individuazione e la localizzazione dei guasti degli apparatidi rete e dei server, controlli il corretto funzionamento dei servizi e misuri costantemente il trafficodi rete e il carico di lavoro dei server. L’omogeneita dei sistemi coinvolti semplifica di molto ildelicato processo di messa a punto del sistema di monitoraggio, massimizzando l’efficacia di talesistema.

E doveroso citare che mediante l’uso dell’attuale stazione di network management (che utilizzaSUN Network/Domain Manager), orientata piu al monitoraggio della rete che dei sistemi, si sonoavuti riscontri molto positivi riguardo alla tempestivita delle diagnosi (spesso si sono attivatiinterventi prima della segnalazione del guasto da parte dell’utenza) e della gestione della rete diateneo.

Mentre fino a poco tempo fa era necessario ricorrere a prodotti software delle grandi case(SUN Network Manager, HP Open View, IBM Tivoli) per ottenere le necessarie caratteristiche dimonitoraggio, si stanno ultimamente affermando prodotti open source che offrono capacita com-parabili e che dovrebbero integrarsi perfettamente con le strutture previste. In particolare sarannovalutati in dettaglio e verificati mediante test sul campo due prodotti open source: OpenNMS eNagios.

OpenNMS, accreditato come uno dei migliori in circolazione, e basato sull’architetturaJava/Servlet, utilizza un database relazionale (PostGres) e files di configurazione XML. Ha ca-pacita di controllo dei sistemi e della rete a basso livello, ma, soprattutto, offre moduli per ilmonitoraggio dei servizi (database, email, web, ecc). L’architettura Java semplificherebbe, se fossenecessario, attivitita di messa a punto e estensione degli agent in base alle conoscenze acquisite inpassato in questo ambiente.

Nagios offre un’ampia gamma di possibilita di controllo sia della rete sia dei sistemi, richieden-do al contempo una infrastruttura di sistema per il funzionamento molto piu semplice rispettoaOpenNMS. E il sistema di monitoraggio piu diffuso ed e utilizzato da CINECA per il monitoraggiodel proprio data center.

Dal punto di vista fisico il server che ospita il sistema di monitoraggio sara connesso alla retedi back-end, per motivi di sicurezza, e alla SAN in modo da concentrare su una stazione il controllodi tutta la Server Farm.

9. Dimensionamento dei sistemi




Con scopo puramente introduttivo, al fine di fornire indicazioni per guidare il progetto verso lafase esecutiva vengono fornite alcuni “scenari” in cui si ipotizzano scelte sugli ambienti applicativi,i sistemi operativi, il numero e le caratteristiche (essenziali) dei server.

Il prossimo paragrafo illustra la parte “stabile”, cioe l’insieme di server e di servizi di cui,sin da ora, si possono descrivere le caratteristiche tecniche e di architettura; i paragrafi successividescriveranno invece soluzioni tra loro alternative che si differenziano soprattutto sulla tecnologiadi alcuni server e, di conseguenza, sull’architettura complessiva.

9.1. Parte stabileSi assume innanzitutto di utilizzare software open source per i seguenti “componenti”:

FirewallDNSLoad balancerLDAP serverProxyMail serverFile e print serverFTP serverBackup serverManagement

Come conseguenza (vedi il paragrafo 4.2) questi componenti saranno ospitati da sistemi conLinux su server in tecnologia X86.

I due firewall previsti dal progetto saranno realizzati come coppie di server Linux in clusterHA con la seconda unita in stand-by. Ogni sistema sara dotato di due processori X86 con 1GB dimemoria e 2 NIC ethernet a 1Gb/s.

Un cluster HA ospitera il DNS e il software di distribuzione del carico (LVS) sul primo servere il server LDAP di front-end sul secondo. I sistemi saranno dotati di due processori X86, 2GB dimemoria, Ethernet a 1Gb/s e interfaccia FC-AL verso la SAN.

Un cluster HA offrira i servizi di file e print sharing (SAMBA) e FTP sul primo server, mentreil secondo esportera in NFS il filesystem contenente le mailbox ai server smtp ed offrira i serviziPOP3/IMAP. I sistemi saranno dotati di due processori X86, 2GB di memoria, Ethernet a 1Gb/s einterfaccia FC-AL verso la SAN.

Due server per il servizio di email, coordinati dal bilanciatore di carico. I server riceverannovia SMTP i messaggi di posta, filtrandoli attraverso il software di antivirus, e alimenteranno, viaNFS, le mailbox utente. I sistemi saranno dotati di due processori X86, 2GB di memoria, Etherneta 1Gb/s.

Due server per il servizio di proxy, coordinati dal bilanciatore di carico. I sistemi utilizzerannoil software Squid e saranno configurati in modo da cooperare; offriranno il proxy per i protocolliHTTP e FTP. La dimensione delle cache e da definire (da 100 a 200 GB ognuna); sara inoltre davalutare se implementare le cache su dischi locali o invece farle insistere sulla SAN. I sistemi sarannodotati di due processori X86, 2GB di memoria, Ethernet a 1Gb/s e, eventualmente, interfaccia FC-AL verso la SAN.




Un server per il sistema di backup. Il sistema sara dotato di due processori X86, 1GB dimemoria, Ethernet a 1Gb/s; il sottosistema a nastri, i dischi e il software di gestione sono descrittinel paragrafo 8.3.

Una stazione di management, con un processore X86, 1GB di memoria, Ethernet a 1Gb/s,interfaccia FC-AL verso la SAN; il software di monitoraggio e descritto nel paragrafo 8.4.

Al fine di rendere piu efficiente le attivita di sviluppo e test degli ambienti operativi e soprattuttodelle procedure dei servizi online e dei contenuti (statici e dinamici) dei siti web si ritiene utile unserver, posto sulla lan di front-end, dedicato appunto allo sviluppo. Tale sistema sara dotato di dueprocessori X86, 2GB di memoria, Ethernet a 1Gb/s e interfaccia FC-AL verso la SAN.

Sono da prevedere altri server per ospitare il video streaming (servizio ancora da valutarein dettaglio), il nuovo programma per il protocollo (Titulus), l’application server per CIA-WEBe l’application server per GISS. A parte quest’ultimo, di caratteristiche note, questi servizi sonoancora in fase sperimentale o addirittura ancora da implementare; il numero e il dimensionamentodei server che li ospiteranno sara possibile quando saranno note le caratteristiche di funzionamentoe di carico previsto per questi servizi.

9.2. Server ad alto carico – Prima ipotesiDalla sezione descritta nel paragrafo precedente mancano i server che subiranno il carico di

lavoro piu gravoso: i database server e i server applicativi. Questa prima ipotesi segue l’approccio,tradizionale, che prevede un unico server (posto nella lan di back-end) che ospita tutte le istanze didatabase previste e di un server applicativo in front-end.

Il database server potrebbe consistere in un server di fascia media, configurato con 8 processoriRISC a 64 bit, 8 GB di memoria, Ethernet a 1Gb/s e interfaccia (a 2Gb/s) FC-AL verso la SAN.Il server, essendo unico, dovra avere hardware ridondato e di tipo hot-swap e la capacita di esserepartizionato (cioe di funzionare come due o piu server) in modo da permettere l’ottimizzazione dellerisorse, la manutenzione del software di sistema e applicativo e l’esecuzione di interventi harwaresenza interrompere i servizi. Caratteristiche simili (o leggermente inferiori) sono necessarie peril server applicativo che ospitera i server HTTP, gli application server, le procedure per i servizionline e i software di portale (e/o di content management).

I fattori positivi di questa ipotesi sarebbero: utilizzo ottimale delle risorse hardware, affidabilitadi questa classe di server, economia e snellimento delle fasi di implementazione e di manutenzionedel sistema.

I fattori che impattano negativamente sarebbero: elevato costo di acquisto e di mantenimento,fermo di tutti i servizi a causa di un guasto grave.

9.3. Server ad alto carico – Seconda ipotesiQuesta ipotesi, alternativa alla precedente, prevede di utilizzare per i database 4 server (a due

a due in HA) che ospitano le varie istanze suddivise in base ad una analisi preventiva dei carichidi lavoro e di fabbisogno di risorse. I server saranno dotati di 4 processori X86, 4GB di memoria,Ethernet a 1Gb/s e interfaccia FC-AL verso la SAN. Per i server applicativi sarebbero necessaridue server, con configurazioni simili a quelle definite per i db server, coordinati dal bilanciatore dicarico. Gli elementi positivi di questa ipotesi sono: economia di acquisto e di gestione, completaridondanza dei sistemi, uniformita delle problematiche di gestione e manutenzione con gli altriserver della Farm.




Incide negativamente, per i db server, una maggiore complessita iniziale di implementazionee messa a punto delle tecniche di alta affidabilita che devono garantire la continuita dei servizi afronte di qualsiasi problema.

Appendice A – Descrizione dei sistemi attuali

Sigla in Figura 1: MAILHostname: mail1.unifi.it, mail2.unifi.it, smtp.unifi.it, ��Hardware: Compaq DS20E 6/500 + DS20E 6/833 in cluster

CPU: 1 Alpha EV68 500MHz + 1 Alpha EV68 833MHzRAM: 1GB + 1GBDisks: 9GB internal + 18GB internal, mirroredDisks: External SCSI array: 90GB mirrored, 18Gb spare

Network: 2 10/100 Mbps Ethernet adaptersSistema operativo: Digital OpenVMS 7.3Software di base: Multinet 4.3

Innosoft PMDF 6.0WASD 7.1.1yahMAIL

Servizi: Mail Server di Ateneo

Sigla in Figura 1: DNSHostname: dns.unifi.itHardware: SUN Ultra 10

CPU: 1 UltraSparc II 440 MHzRAM: 512 MBDisks: 9.1GB internal

Network: 1 10/100 Mbps Ethernet adaptersSistema operativo: Solaris 8Software di base: Bind 9.2

TacacsServizi: DNS Primario di AteneoServizi: Autenticazione connessioni remote

Sigla in Figura 1: WWWHostname: www.unifi.itHardware: SUN Blade 1000

CPU: 1 UltraSparc III 750 MHzRAM: 512 MBDisks: 36GB internal

Network: 1 10/100 Mbps Ethernet adaptersSistema operativo: Solaris 8Software di base: Apache 1.3.9

Database: mySQL 2.0.11Database: miniSQL 2.3.22

Servizi: Web Server di Ateneo




Sigla in Figura 1: WWW2Hostname: www2.unifi.itHardware: Compaq ProLiant 370

CPU: 1 Intel P4 1.0GHzRAM: 1 GBDisks: 20GB internal

Network: 1 10/100 Mbps Ethernet adaptersSistema operativo: MS Windows 2000 ServerSoftware di base: MS IIS 5Software di base: Navita WebMate

Database: MS SQL Server 2000Servizi: Web Server di Ateneo

Note: Ospita la sezione “Studenti” del Web di Ateneo

Sigla in Figura 1: STRMHostname: sb1.unifi.itHardware: SUN Blade 1000

CPU: 2 UltraSparc III 600 MHzRAM: 1 GBDisks: 18.2 internal


RealServer 8.01Servizi: Video streaming (Real Video)

Note: Proprieta di CINECA

Sigla in Figura 1: EPRESHostname: epress.unifi.itHardware: SUN SS 20

CPU: 1 Sparc II 50 MHzRAM: 32 MBDisks: 6 GB

Network: 1 10 Mbps Ethernet adapterSistema operativo: Solaris 8Software di base: Apache 1.3.9Software di base: Perl 5.005 36

Database: mySQL 3.23.36Servizi: Server Web University Press

Sigla in Figura 1: MSTUDHostname: mail.student.unifi.itHardware: SUN Enterprise 250

CPU: 1 UltraSparc II 440 MHzRAM: 512 MBDisks: 20GB internal, mirrored

Network: 1 10/100 Mbps Ethernet adapterIl materiale tecnico e le informazioni contenute nel presente documento sono di natura strettamente confidenziale edi esclusiva proprieta del CSIAF. Non e consentita la divulgazione e la riproduzione totale o parziale senza esplicitaautorizzazione.



Sistema operativo: Solaris 7Software di base: Apache 1.3.4

Innosoft PMDF 5.2Endymion MailMan Standard edition

Servizi: Mail server per gli studenti

Sigla in Figura 1: PROXYHostname: proxy.unifi.itHardware: PC assemblato

CPU: Intel P4 2.0GHzRAM: 512MBDisks: 108GB EIDE, internal

Network: 1 10/100 Mbps Ethernet adapterSistema operativo: Linux RedHat 7.2 (Kernel 2.4.9-31)Software di base: Squid 2.4 Stable 4

Servizi: Proxy server di ateneo

Sigla in Figura 1: WWWSHostname: ?.unifi.itHardware: PC assemblato

CPU: Intel P3 600GHzRAM: 128Disks: 8.5 EIDE, internal

Network: 1 10/100 Mbps Ethernet adapterSistema operativo: Linux RedHat 6.2 (Kernel 2.2.19-6.2.16)

Servizi: Proxy server di ateneoSoftware di base: Apache 1.3.9

BIND 8.2.3Servizi: Web server per gli studenti

DNS secondario di ateneo

Sigla in Figura 1: OLSHostname: alicudi.unifi.itHardware: SUN Enterprise 3500

CPU: 2 UltraSparc II 336 MHzRAM: 2.5 GBDisks: 36GB internal, mirroredDisks: External FibreChannel array: 200 GB RAID5, 36 GB spare

I/O: 2 I/O subsystemsNetwork: 2 10/100 Mbps Ethernet adapters

Sistema operativo: Solaris 2.6Software di base: Apache 1.3.9

iPlanet Web Server 6.0 + java 1.3.1java SDK 1.3.1SUN C compilerPerl 5TCL 7.3




Database: Oracle 8.1.6Basis+ 8.3

Servizi: Servizi online per gli studentiCatalogo online delle biblioteche (OPAC)

Sigla in Figura 1: DEVELHostname: salina.unifi.itHardware: SUN Blade 1000

CPU: 2 UltraSparc III 750 MHzRAM: 1 GBDisks: 36GB internal, mirrored


phpDatabase: Oracle 9i 9.0.1

Servizi: Prototipo anagrafe della ricercaBase dati PEOPLEProgetto Data Warehouse

Note: Il database PEOPLE e acceduto direttamente dai client

Sigla in Figura 1: DNS2Hostname: dns.unifi.itHardware: SUN Ultra 10

CPU: 2 UltraSparc II 440 MHzRAM: 256 MBDisks: 18.2GB internal

Network: 1 10/100 Mbps Ethernet adaptersSistema operativo: Solaris 8Software di base: BIND 9.2

ProFTPDQmail

Servizi: DNS Secondario di AteneoServer di posta per il rettorato – dismessoFTP server per l’aggiornamento dei client CIA

Sigla in Figura 1: CONTHostname: contab.adm.unifi.itHardware: SUN Enterprise 3500

CPU: 2 UltraSparc II 336 MHzRAM: 1.75 GBDisks: 9.1GB internal, mirroredDisks: External SCSI array: 50 GB mirrored, 18 GB spare

I/O: 2 I/O subsystemsNetwork: 2 10/100 Mbps Ethernet adapters

Sistema operativo: Solaris 2.6Database: Oracle 8.1.7




Servizi: Contabilita Integrata di Ateneo (CIA)Protocollo

Note: Istanze Oracle (5) accedute direttamente dai client

Sigla in Figura 1: STUDasHostname: studenti.adm.unifi.itHardware: IBM e-server PSeries 640(B80)

CPU: 2 Power II 375 MHzRAM: 4 GBDisks: 18.2GB internal, mirrored

Network: 1 10/100 Mbps Ethernet adaptersSistema operativo: AIX 4.3Software di base: Oracle Application Server

Servizi: Gestione Integrata Segreterie Studenti (GISS)

Sigla in Figura 1: STUDdbHardware: IBM e-server PSeries 640(B80)

CPU: 2 Power II 375 MHzRAM: 2 GBDisks: 18.2GB internal, mirroredDisks: External SCSI array 6X18.2GB, RAID 5

Network: 1 10/100 Mbps Ethernet adaptersSistema operativo: AIX 4.3

Database: Oracle 8.1.6Servizi: Gestione Integrata Segreterie Studenti (GISS)

Note: 2 server identici in cluster HA/CMP3 istanze Oracle (produzione, test, migrazione)


NUOVA SERVER FARM ROGETTO - siaf.unifi.it · Dimensionamento dei sistemi 28 9.1. Parte stabile 29...

Documents

Transcript of NUOVA SERVER FARM ROGETTO - siaf.unifi.it · Dimensionamento dei sistemi 28 9.1. Parte stabile 29...