nuova server farm – progetto

Transcript

NUOVA SERVER FARM – PROGETTO
Tipo di documento:
Relazione Tecnica
Tilolo del documento: Nuova Server Farm – Progetto
Data:
File:
sf.tex Preparato da:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 2 di 35
Riccardo Detti
Cristina Mugnai
Indice
1. Introduzione 5
2. Obiettivi del progetto 5
2.1. Razionalizzazione 5
2.2. Disegno di una nuova architettura del sistema informativo 6
2.3. Sicurezza 6
2.4. Ottimizzazione e potenziamento dei servizi interni 6
2.5. Obiettivi a lungo termine 7
3. Ricognizione dello stato attuale 7
3.1. Infrastruttura e topologia di rete 7
3.2. Server 8
3.3. Servizi 9
3.3.1. Servizi esterni 9
3.3.1.1. DNS 9
3.3.1.2. WWW 9
3.3.1.3. Posta elettronica 10
3.3.1.4. FTP 10
3.3.1.5. Video Streaming 10
3.3.2. Servizi interni 10
3.3.2.1. Contabilità di ateneo 11
3.3.2.2. Segreterie Studenti 11
3.3.2.3. Sistema di Gestione delle Biblioteche – SBN 11
3.4. Criticità emerse dalla ricognizione 12
4. Progetto 13
4.1. Filosofia del progetto 13
4.2. Open Source, GNU, Linux 14
4.3. Architettura 16
5. Rete 19
5.1. Topologia 19
5.2. Tecnologia 19
5.3. Sicurezza e firewall 19
6. Sezione di front-end 20
7. Sezione applicativa 20
7.1. Tecnologia 20
7.2. Servizi 21
7.2.1. DNS 21
7.2.2. WWW 21
7.2.3. Proxy 22
7.2.4. Email 22
7.2.5. FTP 23
7.2.6. LDAP 24
7.2.7. Streaming 24
7.2.8. Segreterie Studenti 24
7.3. Servizi interni 24
7.3.1. File service 24
7.3.2. Print service 25
Il materiale tecnico e le informazioni contenute nel presente documento sono di natura strettamente confidenziale e
di esclusiva proprietà del CSIAF. Non è consentita la divulgazione e la riproduzione totale o parziale senza esplicita
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 3 di 35
Riccardo Detti
Cristina Mugnai
8. Sezione di back-end – Database e servizi ausiliari 25
8.1. Database 25
8.2. Storage Area Network 26
8.3. Sistema di Backup 27
8.4. Monitoraggio 28
9. Dimensionamento dei sistemi 28
9.1. Parte stabile 29
9.2. Server ad alto carico – Prima ipotesi 30
9.3. Server ad alto carico – Seconda ipotesi 30
Appendice A – Descrizione dei sistemi attuali 31
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 4 di 35
Riccardo Detti
Cristina Mugnai
Indice delle figure
Fig. 1 – Stato attuale: topologia di rete e sistemi 8
Fig. 2 – Architettura generale della Server Farm 17
Fig. 3 – Architettura generale della Server Farm — Deployment iniziale 18
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 5 di 35
Riccardo Detti
Cristina Mugnai
1. Introduzione
Questo 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 dettagliata
degli attuali servizi in carico alla farm e indicano in modo critico le carenze derivanti dalla attuale
architettura.
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 server
farm.
L’ultimo capitolo, “Dimensionamento dei sistemi”, fornisce indicazioni di massima, utili ad
una discussione sulle strategie da seguire al fine di rendere esecutivo il progetto, descrivendo i
possibili 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, costituiscono “l’input” del progetto. I servizi progettati e realizzati all’interno del Centro (o comunque
dell’Università) sono analizzati in modo critico e per alcuni di essi si prospetta una evoluzione volta
sia al miglioramento del servizio stesso, sia ad una migliore integrazione con il nuovo contesto
operativo. Ciò dovrebbe portare, nell’arco di vita previsto per il progetto (circa tre anni), verso
la realizzazione di un sistema informativo “integrato” di ateneo, ove tutte le componenti siano in
grado di interagire reciprocamente.
Alcuni servizi (di grande importanza) sono invece forniti da terzi e sono solo ospitati dal
Centro. 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 viziano
sia l’architettura generale, sia, soprattutto, la possibilità di evoluzione appena accennata e quindi la
qualità complessiva dell’intero processo. D’altronde in questa sede non si ritiene appropriata, n é
di competenza, la discussione a posteriori della validità, sia architetturale sia operativa, delle scelte
fatte; di conseguenza, come appena detto, il progetto include questi servizi valutandoli allo stato
attuale dell’arte e accettandone le imposizioni.
Si ritiene comunque indispensabile, per il futuro, che la scelta di nuovi servizi venga preventivamente discussa sul piano architetturale e tecnologico, in modo che questi si integrino nel contesto
senza 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 e
di qualita’ che devono essere soddisfatti da qualunque nuovo servizio prima di essere attivato.
2. Obiettivi del progetto
Il 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 sistema informativo dell’Università, pone tutto l’insieme delle problematiche classiche, aprendo al
contempo un insieme di possibilità tecnologiche e architetturali, che di norma si affrontano gradualmente 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 tempi
brevi alle necessità già emerse da tempo e a quelle previste nei piani di sviluppo del CSIAF.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 6 di 35
Riccardo Detti
Cristina Mugnai
2.1. Razionalizzazione
Dalla 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 principali
del progetto sarà l’omogeneizzazione dei server al fine di ottenere:
Economia di gestione. Utilizzando server per quanto possibile omogenei si ha un miglioramento dei tempi e dei costi di intervento per la gestione e l’aggiornamento dei sistemi. Si rende
agevole 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 pool
ristretto di fornitori si ottengono sicuramente vantaggi economici di scala.
Svecchiamento dei server in produzione. Si possono dismettere i server pi ù vecchi che hanno
un basso rapporto tra potenza e costi di gestione e manutenzione a favore di server di nuova
tecnologia più potenti ed economici.
2.2. Disegno di una nuova architettura del sistema informativo
L’attuale disegno architetturale del sistema informativo presenta gravi carenze. Le criticit à
che ne derivano sono descritte nel paragrafo 3.4; in particolare il nuovo disegno architetturale dovr à
garantire:
Scalabilità. A fronte dell’aumento della richiesta di risorse, fisiologica o eccezionale, da parte
di uno o più servizi l’architettura dovrà permettere l’aumento delle capacità di elaborazione
senza dover modificare l’architettura stessa.
Fault-tolerance. L’architettura dovrà permettere ad ogni servizio di continuare a funzionare
anche in caso di guasto di un qualsiasi componente.
Tecnologia. Il progetto dovrà impiegare lo stato dell’arte in campo tecnologico e valutare
possibilmente il trend dei prossimi anni.
Evoluzione. L’architettura dovrà permettere la naturale evoluzione dei sistemi e dei servizi
coinvolti. Sarà, per quanto possibile, neutra rispetto alla tecnologia dei sistemi che la compongono.
2.3. Sicurezza
La 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 di
tutti i livelli di un sistema informativo, dall’infrastruttura di rete fino ai servizi resi all’utenza. Il
progetto dovrà quindi valutare l’intero disegno anche da questo punto di vista, cercando, per quanto
possibile, di utilizzare gli standard più diffusi per ottenere un sufficiente livello di sicurezza senza
complicare l’utilizzo delle risorse e la fruizione dei servizi.
2.4. Ottimizzazione e potenziamento dei servizi interni
La 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 del
progetto 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 lavoro
del personale.
Sistema per il monitoraggio dei server, dei servizi e dell’infrastruttura di rete interna alla Server
Farm.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 7 di 35
Riccardo Detti
Cristina Mugnai
File server centralizzato per i sistemi interni alla Farm e per il lavoro di gruppo del personale
del Centro.
Servizi di stampa e stampanti di formato e qualità adeguati alle necessità del Centro.
2.5. Obiettivi a lungo termine
Il 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. È
doveroso però notare che, per motivi che non possono essere discussi qui, i servizi informatici
chiave dell’Università (contabilità, segreterie, protocollo, gestione del personale, ecc.) sono stati
progettati e sviluppati da terzi. Prescindendo dalla qualità di ogni singolo servizio è inconfutabile
il 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 comunicare
nè tantomeno di cooperare gli uni con gli altri. Se questa situazione poteva essere accettabile in
passato, già oggi induce grosse difficoltà allo sviluppo di servizi trasversali, cioè che interessano
contemporaneamente più mondi, imponendo attività notturne di trasferimento, trasformazione e,
soprattutto, duplicazione dei dati. In futuro questa incapacità di ogni servizio di comunicare con
gli altri rappresenterà il problema maggiore nel costituire un Sistema Informativo dell’Università
di 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 gestito
nell’infrastruttura della Server Farm.
La tecnologia, affinché il servizio possa eventualmente essere ospitato da server già presenti
nella Server Farm.
La capacità di offrire servizi verso altre applicazioni in modo che il nuovo sistema possa
interagire con gli altri già presenti.
3. Ricognizione dello stato attuale
3.1. Infrastruttura e topologia di rete
La 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. Esse
sono 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; in
appendice Asono descritti in dettaglio i server e le loro configurazioni hardware e software. Gli
apparati di rete sono viceversa elencati qui di seguito:
C7200 – Router CISCO 7200, e’ il router di frontiera, collegato al POP GARR con un canale
ATM a 34Mb/s, esposto verso l’esterno via protocollo BGP. Storicamente è stato il centro delle
comunicazioni dell’ex CeSIT, sia verso l’esterno sia verso l’interno; sta avendo un ruolo sempre
più marginale dopo l’implementazione della rete interna a 1Gb/s. Implementa verso l’interno il
protocollo di routing OSPF.
ENALP – Extreme Networks Alpine XXX, è lo switch layer 3 che WIND ha installato presso
tutte le sedi che si collegano all’anello in fibra ottica a 1Gb/s. Sono fisicamente i “centro stella”
autorizzazione.
Tipo di documento:
Relazione Tecnica
Pag. 8 di 35
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Riccardo Detti
Cristina Mugnai
sia della sede di Via delle Gore sia di quella del Rettorato. In Via delle Gore questo switch collega
direttamente i server più importanti (MAIL, WWW, WWW2, OLS), mentre gli altri vi arrivano
attraverso switch secondari (non presenti in figura).
Si nota l’assenza di firewall; tutti i server presso la sede di Via delle Gore sono infatti esposti
direttamente in rete pubblica, ponendo gravi, e noti, problemi di sicurezza e di interoperabilit à.
L’unico firewall presente (un CISCO PIX XXX) è installato presso il Rettorato a protezione
dei sistemi di contabilità e delle segreterie studenti. L’argomento sarà discusso in dettaglio nel
paragrafo 5.3.
Gli apparati e l’infrastruttura non sono ridondati.
Internet
DNS
MAIL
WWW
WWW2
STRM
EPRES MSTUD PROXY WWWS
150.217.
C7200
Sede CSIAF
.1
ENALP
OLS
DEVEL
.3
Collegamento alle sedi principali dell’Ateneo
1 Gb Eth
Rettorato
ENALP .22
DNS2
.85
F W
GISSas GISSdb GISSdb
CONT
Fig. 1– Stato attuale: topologia di rete e sistemi
3.2. Server
In 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, i
principali servizi offerti. L’elenco non è completo, non sono descritti i server ritenuti marginali ai
fini 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 il
mainframe BULL che ospita il sistema gestionale delle biblioteche.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 9 di 35
Riccardo Detti
Cristina Mugnai
3.3. Servizi
Sono 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 inteso
come “accedibile dall’esterno” e cioe’ da qualsiasi postazione Internet nel mondo e non come rivolto
ad una utenza rigorosamente esterna all’Università. Viceversa per servizi interni si assumono quelli
strettamente dedicati alle strutture, al personale tecnico-amministrativo, agli studenti e ai docenti
dell’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 sono
servizi interni.
3.3.1. Servizi esterni
3.3.1.1. DNS
Il 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 a
livello mondiale, garantisce la corrispondenza biunivoca tra la nomenclatura gerarchica a domini di
Internet dei sistemi di una organizzazione con l’indirizzo IP di ogni sistema. Il DNS dell’Universit à
di 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 per
migliorare l’efficienza. Poiché ogni singola stazione interroga ripetutamente il DNS, da sempre
si è provveduto ad installare il DNS primario presso la sede di Via delle Gore, vicino alla frontiera, in modo che le richieste provenienti dall’esterno trovino subito il servizio, senza percorrere
l’infrastruttura di rete interna all’ateneo. Per lo stesso criterio, tutti i sistemi interni, topologicamente
vicini 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 per
quelli che insistono sulle reti del centro storico. Il sistema DNS presso la sede del Rettorato non è
ridondato, mentre presso la sede di Via delle Gore è attivo un altro server, normalmente visto come
secondario, che può sostituire temporaneamente il primario in caso di guasto.
3.3.1.2. WWW
É 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 siti
universitari. Attualmente sono molteplici i server che ospitano parti del sito web di ateneo; i pi ù
importanti (vedi appendice A per le caratteristiche) sono:
WWW É il server che storicamente ha esposto la parte informativa del web di ateneo. Recentemente è stato scaricato della sezione “studenti”. Ospita sezioni “periferiche”, alimentate
direttamente da unità amministrative dell’ateneo. Implementa alcuni servizi dinamici, tra i quali
spicca il “cerca-chi”. Le parti dinamiche utilizzano i linguaggi PHP e PERL che sono installati
come moduli del server Apache. Le procedure in PHP utilizzano il database mySQL.
WWW2 E’ il server, recentemente introdotto, che ospita la sezione “studenti”, sviluppata
utilizzando il prodotto di content management WebMate di Navita. Ospita le sezioni periferiche
che utilizzano la tecnologia Active Server Pages (.asp) di Microsoft.
OLS É un server orientato completamente all’erogazione dei servizi via WWW. Ospita il
catalogo online delle biblioteche, tutti i servizi destinati agli studenti e recentemente alcuni servizi
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 10 di 35
Riccardo Detti
Cristina Mugnai
dedicati ai docenti. Il sistema ospita due web server: Apache e iPlanet. Il server Apache è dedicato
all’OPAC/WWW, il quale consiste in un pacchetto di procedure in linguaggio Sibylla. Sibylla
è un estensione del linguaggio di script TCL al quale sono state aggiunte primitive e funzioni
per l’accesso al motore di information retrieval Basis+ e per l’interfaccia HTTP/HTML. Il server
iPlanet invece viene utilizzato principalmente per le sue funzionalità di “servlet container” e di
pubblicazione con la tecnologia “java server pages”. Tutti i servizi online per gli studenti e per i
docenti sono sviluppati come servlet java e stanno convergendo verso lo standard 2.2
WWWS Ospita i siti web gestiti dalle organizzazioni studentesche. Non ospita contenuti
dinamici.
DEVEL É un server dedicato soprattutto allo sviluppo di nuovi servizi WWW , il pi ù importante
dei 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 al
database Oracle.
3.3.1.3. Posta elettronica
Il 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, soprattutto
nella comunicazione interna oltreché verso l’esterno. L’importanza con cui è stato visto questo
servizio 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 tempo
pieno 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 (vedi
MAIL in appendice A); i sistemi di comunicazione, di email e di gestione delle mailing list sono
della InnoSoft. La scelta di questi sistemi, avvenuta alcuni anni fa, ha prediletto la leggendaria
sicurezza e stabilità dei sistemi basati sul VMS ritenendo secondarie le problematiche e i costi di
gestione.
3.3.1.4. FTP
Il 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 di
informazioni. Appare, da una breve indagine,che l’“utente medio” non utilizzi questo sistema (molti
non lo conoscono nemmeno), preferendo sistemi più immediati come il download via protocollo
HTTP, 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 di
dati, 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 amministratori
dei contenuti delle sezioni periferiche del web di ateneo. È da notare che il software di client
per la contabilità di ateneo utilizza internamente il protocollo FTP per l’installazione dei propri
aggiornamenti.
3.3.1.5. Video Streaming
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 11 di 35
Riccardo Detti
Cristina Mugnai
3.3.2. Servizi interni
Nei paragrafi successivi vengono descritti i servizi dedicati ad una utenza rigorosamente
interna, a supporto delle attività critiche di funzionamento dell’ateneo. La ricognizione non ha
preso in considerazione quei servizi come ad esempio il l’E-learning o la gestione delle carriere
del personale che, pur essendo importanti, non impattano direttamente sul progetto, essendo gestiti
completamente da aziende esterne. Il sistema di gestione delle biblioteche viene citato in questi
paragrafi per la sua storia particolare e per la centralità che occupa nel CSIAF; non sarà valutato ai
fini del progetto in quanto, pur essendo in corso uno studio di migrazione e downsizing, le soluzioni
architetturali e le esigenze dell’hardware, subordinate alle caratteristiche funzionali del nuovo
sistema 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 nuovo
sistema nel contesto della Server Farm.
3.3.2.1. Contabilita`di ateneo
La 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 sono
poco meno di 500. Dal punto di vista architetturale e tecnologico il programma implementa la logica
client-server a due livelli. I client, cioè la parte di programma installata presso la postazione di
lavoro di ogni utente, contengono l’interfaccia grafica, la logica di funzionamento dell’applicazione
e le funzionalità di colloquio, via rete, con il server. Il programma client è stato sviluppato con
Visual 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 capacit à di
multiutenza e di motore transazionale.
È previsto a breve termine l’istallazione e la sperimentazione del nuovo servizio di contabilit à
per i Poli (CIA-Poli). Dal punto di vista architturale il sistema dovrebbe consistere in un server
applicativo (IBM Web Sphere) che colloquia con i client via protocollo HTTP e, in back end, con
uno schema dati all’interno dell’istanza Oracle della contabilità (CIA). L’hardware, per il test del
prototipo, sarà fornito dal CINECA.
3.3.2.2. Segreterie Studenti
Il 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 dati
dal precedente sistema di gestione, GISS è entrato in produzione nel periodo di immatricolazione
e 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 tre
livelli. 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. Il
livello intermedio, solitamente descritto come application server, cioè il server ove risiede la logica
applicativa, 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 in
linguaggio PL/SQL, il linguaggio “interno” di Oracle.
3.3.2.3. Sistema di Gestione delle Biblioteche – SBN
Il sistema gestionale delle biblioteche supporta il lavoro di acquisizione, catalogazione, collocazione 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
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 12 di 35
Riccardo Detti
Cristina Mugnai
Bibliotecario Nazionale (SBN) ed è stato progettato e sviluppato dal personale dell’Università di
Firenze in collaborazione con altri enti coinvolti nel progetto finanziato direttamente dal Ministero
dei 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) e
istituti (Treccani), nonché la Regione Veneto e l’Università dell’Aquila.
Il sistema consiste in un insieme di transazioni scritte in linguaggio COBOL, gestite da un
motore transazionale classico (TDS), in ambiente mainframe BULL GCOS7. Il database su cui
insiste 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 verso
una piattaforma più moderna.
Non essendo note al momento le caratteristiche del sistema che sarà scelto si possono però
elencare 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 applicativa
dalle attività sulle basi dati. Eventualmente avere server separati per sfruttare le caratteristiche
di sicurezza dell’infrastruttura di rete.
Data base Oracle, in modo da sfruttare le conoscenze e unificare le attività di gestione e
manutenzione. Eventualmente ospitare le basi dati su un server esistente.
Sistema operativo Unix, per gli stessi motivi del punto precedente.
3.4. Criticita`emerse dalla ricognizione
I paragrafi precedenti elencano lo stato attuale dei server e dei servizi offerti in modo il pi ù
possibile neutro e oggettivo. In questo paragrafo sono invece elencate una serie di valutazioni
critiche in relazione ad alcuni aspetti emersi durante la ricognizione.
Dalla ricognizione effettuata appare evidente la differenza di approccio, e di esigenze, che
le strutture confluite nel CSIAF hanno utilizzato nell’acquisizione e nella configurazione dei vari
sistemi. Senza entrare nel merito della validità delle strategie adottate si possono estrapolare i
seguenti punti che possono aiutare nella valutazione complessiva del “parco macchine” esistente e
indicare 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 e
sei anni. Questo fattore è indice delle difficoltà di reperimento dei fondi per l’aggiornamento
dei 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 del
materiale obsoleto.
Proliferazione. L’Università di Firenze è “in rete” dal 1991; all’inizio, come è ovvio, con
pochi sistemi sperimentali. In questi dieci anni di attività si è avuta una evoluzione e una
espansione dei servizi, sia verso l’esterno, sia interni, che ha portato ad una moltitudine di
server di varie dimensioni e potenza, nella logica che ogni nuovo servizio abbisognasse di un
server. La situazione di “un servizio un server” è stata generata per vari motivi: la mancanza di
un piano strategico unitario a lungo termine; l’evoluzione, a volte tumultuosa, dell’informatica
che propone soluzioni e architetture non prevedibili con anni, se non mesi, di anticipo; i servizi
esistenti, spesso di terze parti, ancorati ad architetture specifiche e/o antiquate che migrano
con difficoltà, o addirittura non possono migrare, alle nuove architetture hardware e software;
sistemi acquisiti che non possono scalare per ospitare nuovi servizi.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 13 di 35
Riccardo Detti
Cristina Mugnai
Omogeneità. La crescita dei servizi offerti e, come abbiamo visto, dei server coinvolti, ha
gravato, per contro, su un pool ristretto di persone che ha gestito i servizi in pratica fino dal loro
esordio. Ciò ha portato, per una evidente ed implicita economicità di gestione, ad acquisire
server aventi lo stesso sistema operativo e software di base. In pratica la maggioranza dei
server 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 ha
portato i seguenti vantaggi: la conoscenza approfondita del sistema ha permesso al personale
di essere autonomo e risolvere situazioni critiche rapidamente; economia nella gestione del
software 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 alcune
eccezioni: il sistema di posta elettronica insiste su sistema operativo Digital Open/VMS, il
sistema di gestione delle segreterie studenti su IBM AIX, la sezione “Studenti” del sito web
di ateneo in ambiente Windows 2000.
Logica client-server a due livelli: è stata utilizzata moltissimo nel periodo di migrazione degli
applicativi 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 a
due livelli è considerato oramai obsoleto avendo dimostrato qualche limite; è essenziale la corretta
valutazione delle problematiche indotte da questa architettura ai fini della collocazione di CIA
nel modello proposto dal progetto. Sono qui elencati alcuni aspetti che verranno poi ripresi nel
paragrafo 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 e
manutenzione oneroso.
I client, colloquiando direttamente con il database centrale, generano un notevole traffico
di rete, che spesso ha portato insoddisfazione all’utenza per i lunghi tempi di risposta
dell’applicativo e costi per il potenziamento dell’infrastruttura di rete. I due aspetti appena
citati si possono sintetizzare nella scarsa propensione della logica a due livelli a scalare verso
un elevato numero di postazioni di lavoro.
Il database, essendo acceduto direttamente dai client (che all’Università sono addiritura in rete
pubblica), è esposto in rete e quindi pone gravi problemi di sicurezza.
4. Progetto
Dopo aver elencato nei capitoli precedenti gli obiettivi del progetto, lo stato attuale dell’infrastruttura, dei server e dei servizi, questo capitolo introdurrà il contensto in cui opera il progetto, i
suoi limiti e i punti di vista strategico, architetturale e di sicurezza del problema.
4.1. Filosofia del progetto
La 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 praticamente tutte le unità organizzative del CSIAF, sia quelle direttamente coinvolte con l’erogazione
dei 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
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 14 di 35
Riccardo Detti
Cristina Mugnai
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 operativa “Servizi di Rete” per gli aspetti legati agli apparati di rete necessari e all’interazione
della rete della Server Farm con la rete di ateneo.
Dell’architettura e la tecnologia dei server della Server Farm, analizzate le proposte
tecnologiche 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 collaborazione
principalmente con l’area operativa “Sistemi Informativi” e con altre che possono
abbisognare 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” del
CINECA, che ha terminato da poco la ristrutturazione della proria Farm. CINECA è in grado di
apportare un notevole contributo al progetto avendo in carico, anche se in scala pi ù grande, gli stessi
servizi della Server Farm, essendo fornitore dell’Università di Firenze di alcuni servizi (CIA, Email
per gli studenti) e, soprattutto, avendo conoscenza ed esperienza sulle tecnologie che si intende
adottare nel progetto.
Un aspetto interessante della collaborazione, emerso fino dai primi incontri, è l’esperienza del
Settore Gestione Sistemi nel campo dei sistemi in cluster e, soprattutto, nell’aver sperimentato con
successo e adottato tecniche di alta affidabilità e divisione di carico con server Linux. L’adozione
di tali sistemi, prevista per alcune componenti nelle fasi preliminari del progetto, ma che induceva
alcuni dubbi soprattutto sulla complessità architetturale e sull’affidabilità, trova adesso un conforto
prezioso che si basa su una solida esperienza.
4.2. Open Source, GNU, Linux
Fino 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 stato
sicuramente orientato alla valutazione di prodotti industriali. Oggi, sarebbe insensato non considerare attentamente i prodotti disponibili dalle comunità open source, in quanto hanno dimostrato
nel tempo caratteristiche di stabilità, performance, e adesione agli standard in assoluto non inferiori ai prodotti industriali. Anzi ultimamente assistiamo alla tendenza, sempre pi ù diffusa,
dell’integrazione dei prodotti open source all’interno delle suite software vendute dalle software
house industriali: un esempio per tutti è il web server Apache, considerato unanimemente un
prodotto 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 che
può essere resa praticabile con un approccio pragmatico di valutazione, prodotto per prodotto, dei
benefici 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
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 15 di 35
Riccardo Detti
Cristina Mugnai
di punti che aiutano ad inquadrare il problema: sono di eseguito elencati i vantaggi, i problemi e
alcuni 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 di
errori e per deficienze sulla sicurezza, sia per l’implementazione di nuove funzionalit à. È
un fattore estremamente positivo, ma può diventare un problema di gestione (vedi sotto).
Adesione agli standard. L’etereogenità dei partecipanti allo sviluppo del software open
source 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 source
divengono 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 (alla
genialità) delle persone che vi partecipano.
2) Problemi
Evoluzione. La continua evoluzione dei prodotti open source pu ò imporre una elevata
attività 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. Deve
essere cura di chi li utilizza il verificarne periodicamente lo stato di evoluzione. Anche
se questa è diventata una tendenza generale, adoottata anche dai sistemi industriali, deve
essere prevista una periodica attività di monitoraggio dello stato dell’arte di ogni prodotto
adottato.
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 siano
molto innovativi come architettura, o che abbiano team di sviluppo di poche unit à, possono indurre cambiamenti radicali del prodotto o nella configurazione adottata; possono
addirittura cessare l’attività di sviluppo e fondersi con altri gruppi che sviluppano prodotti
simili. La maturità dei prodotti è un fattore essenziale nella scelta e nell’adozione di qualsiasi componente.
Interesse. Prodotti che hanno una utenza vasta sono sviluppati da team di grosse dimensioni e possono contare su un feedback ampio e proveniente dalle pi ù diverse realtà di
installazione. I prodotti di vasto interesse sono normalmente affidabili ed efficienti; in
questa 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̀ che
hanno già operato una scelta e messo in servizio prodotti di interesse e che abbiano
requisiti confrontabili con i propri, può essere fonte di informazioni e indicazioni utili sia
a 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,
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 16 di 35
Riccardo Detti
Cristina Mugnai
porta necessariamente a valutare il sistema operativo che e’ stato sviluppato dalla comunit à open
source: 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 di
Linux 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 open
source. 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 open
source. 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 chip
di “glue”e degli standard di interconnessione delle periferiche, i sistemi che utilizzano queste
tecnologie si collocano nella fascia più bassa, come caratteristiche di potenza, dei server. Come
conseguenza, ove servisse una potenza di calcolo o di I/O superiore a quella fornibile da un server di
questa classe è indispensabile ricorrere a sistemi proprietari di potenza medio/alta che implementano
sistemi operativi UNIX (di solito sviluppati dalle stesse case che forniscono l’hardware). Uno o
più sistemi di fascia media (spesso con hardware ridondante) con sistemi operativi proprietari e
software applicativo industriale è stato fino ad oggi l’approccio standard per qualsiasi servizio di
una certa importanza.
La rapidissima evoluzione del software di base per le comunicazioni in Linux, ha introdotto di
recente varie tecniche che permettono, in una certa misura, di aggirare le limitazioni di potenza dei
server Intel. Il bilanciamento del carico applicativo su più server e il bilanciamento del traffico di rete
su più interfacce, si candidano come tecnologie di base per raggiungere gli obiettivi architetturali
previsti: ridondanza e scalabilità.
In conclusione, nei casi in cui il software applicativo open source offra le caratteristiche
necessarie al progetto, si ritiene percorribile la via di insiemi di server Linux, equipaggiati delle
tecnologie appena accennate, per l’offerta di alcuni servizi. Al costo, forse, di una attivit à più
onerosa di installazione, avremo sicuramente un notevolissimo risparmio economico, considerando
la 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 di
installazioni “standard”, magari prese in considerazione in una prima istanza, portassero i progetto
fuori dal budget disponibile, è possibile riesaminarlo in un contesto open source più economico.
4.3. Architettura
Questo 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 evidenziandone
soprattutto 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 in
cluster. Per cluster si intende in qusto caso la capacità di più di un server di offrire lo stesso
servizio in modo di aumentare le capacità di carico durante il normale funzionamento e garantire la
continuità dei servizi in caso di guasto di un server. La “collaborazione” dei server che offrono lo
autorizzazione.
Tipo di documento:
Relazione Tecnica
Pag. 17 di 35
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Riccardo Detti
Cristina Mugnai
Internet
150.217.
F W
Cluster di Front−End
DR
Sezione di Front−End
C7200
.1
ENALP
RS
RS
RS
...
RS
.3
Sezione applicativa
F W
FS
DR
Cluster Server Applicativi
SAN
AS
F W
AS
DB
...
DB
Database Cluster
LAN di Management
MGT
...
BCK
Sezione di Back−End
1 Gb Eth
ENALP
.22
F W
DNS2
Fig. 2– Architettura generale della Server Farm
stesso servizio non avviene (come nei veri cluster) mediante meccanismi interni ai server stessi, ma
mediante l’azione di elemento esterno (DR in figura) che provvede a dirigere le richieste provenienti
dall’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 firewall
e una LAN dedicata al management. L’organizzazione a bastioni multipli dovrebbe garantire alla
sezione di back-end, la più interna (che custodisce i database), un livello adeguato di sicurezza
disaccoppiando i client che richiedono i servizi dai server applicativi mediante i proxy della sezione
di front-end e controllando i flussi di informazione tra le varie LAN mediante i firewall. La rete di
management permette l’accesso per la configurazione e il controllo dei vari sistemi solo dal sistema
di management (MGT in figura); offre inoltre la possibilità di usufruire del sistema centralizzato di
backup (BCK in figura) senza appesantire il traffico sulle altre LAN. Non sono rappresentati, per
autorizzazione.
Tipo di documento:
Relazione Tecnica
Pag. 18 di 35
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Riccardo Detti
Cristina Mugnai
mantenere leggibile lo schema, gli apparati di rete e le modalità di collegamento dei vari server, che
saranno descritti nel capitolo 5.
Sulla destra della Figura 2 è rappresentata la Storage Area Network (SAN), sebbene sia un
elemento 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) performance
e flessibilità di gestione.
Il disegno architetturale proposto in Figura 2 risponde pienamente ai requisiti e agli obiettivi di
progetto, 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 quindi
opportuno implementare in un primo momento solo una parte del disegno appena illustrato, in
modo da verificare “sul campo” le scelte operate (ed eventualmente aggiustarle), per poi completare
il disegno in una fase successiva. Le parti da implementare secondariamente sono sostanzialmente
due: la sezione di front-end e la LAN di management.
Sezione applicativa
Internet
F W
FS
DR
Cluster Server Applicativi
150.217.
SAN
C7200
AS
.1
ENALP
...
AS
.3
F W
DB
...
DB
Database Cluster
MGT
1 Gb Eth
BCK
Sezione di Back−End
Sede del Rettorato
F W
DNS2
Fig. 3– Architettura generale della Server Farm — Deployment iniziale
ENALP
.22
La parte di front-end, prevista dal progetto come interfaccia verso l’esterno attraverso l’uso di
sistemi di proxy, imporrebbe un firewall e un bilanciatore di carico in alta affidabilità e un insieme
di server per ospitare i sistemi proxy. La posticipazione di questa sezione riduce senz’altro il livello
di sicurezza dell’intero sistema, ma permette di concentrare, senza rinunciare a nessun servizio
previsto, 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 ne
risenta notevolmente. Concentrando le attività di backup dei sistemi durante le ore notturne, quando
cioè il traffico è più basso, non dovrebbero presentarsi problemi di saturazione degli apparati di rete.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 19 di 35
Riccardo Detti
Cristina Mugnai
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. Tale
soluzione 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 management
permette 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 parzialmente
rispetto al disegno completo, soddisfa i prerequisiti imposti dagli obiettivi del progetto e le necessit à
discusse nei capitoli precedenti; viene proposta di seguito una lista che riassume gli aspetti salienti
dell’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 della
rottura di un server (fault-tolerance).
L’architettura è indipendente dalla tecnologia dei server utilizzati: si possono usare pochi
server di fascia media o più server di fascia bassa in tecnologia Intel (Linux) a seconda delle
esigenze delle piattaforme applicative.
I server sono assistiti da tre componenti di servizio: il sistema centralizzato di backup; il file
server; il sistema di management.
5. Rete
L’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 sicurezza
della rete interna alla Server Farm.
5.1. Topologia
La 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 di
ateneo attraverso un firewall e, mediante un secondo firewall, verso la LAN pi ù interna che ospita
i database e i sistemi di controllo e di gestione. La scelta di due firewall in cascata, rispetto ad un
firewall a tre vie, è giustificata essenzialmente da due fattori: il troughput e la semplificazione della
configurazione, come descritto più in dettaglio nel paragrafo 5.3.
5.2. Tecnologia
Le 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 sistemi
saranno 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 sar à
valutata la possibilità di installarne in ridondanza in modo da pemettere il funzionamento della rete
anche in caso del guasto di un componente.
Poiché è prevedibile che i server saranno installati in rack, i collegamenti tra i server e gli
switch saranno in rame, mentre i link tra i rack e verso la rete di ateneo saranno in fibra ottica.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 20 di 35
Riccardo Detti
Cristina Mugnai
5.3. Sicurezza e firewall
La sicurezza dell’intero sistema è affidata principalmente ai firewall i quali saranno preposti principalmente al filtraggio delle connessioni provenienti dall’esterno, permettendo l’accesso
soltanto ai servizi previsti. I firewall, inoltre, si occuperanno di trasformare gli indirizzi privati dei
server 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 sicurezza
dei sistemi verso l’esterno, mantenendo alto il livello di interoperatività e di servizio tra i server
all’interno delle LAN.
I firewall saranno costituiti da coppie di sistemi Linux in alta affidabilità sfruttando le caratteristiche di filtraggio del kernel e del software iptables. La soluzione pi ù economica sarebbe di
installare un solo firewall con tre interfacce: la prima vesro la rete esterna, la seconda verso la LAN
applicativa 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 creando
un collo di bottiglia. Viceversa, installando due firewall in cascata, a fronte di un maggior costo
economico, si ha la sicurezza che i firewall possano mantenere i traffico teorico della rete Ethernet
a 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 pi ù critici nella LAN più
interna, 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 in
modo tale da isolare ulteriormente la sezione di back-end dall’esterno. Purtroppo l’architettura a
due livelli utilizzata da CIA impone che ogni postazione di lavoro dell’utenza si debba collegare
direttamente con il databse server; i firewall, pertanto, dovranno essere configurati in modo tale che
le postazioni su cui è installato CIA possano aprire connessioni verso il database server. Tutto ci ò
riduce notevolmente l’efficacia dell’intero disegno.
Si possono, per ora, ipotizzare due soluzioni, ma è necessario discutere con CINECA il
problema 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 questo
modo si snellirebbe la configurazione del primo firewall, ma si otterrebbe un livello di sicurezza
paragonabile 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-end
La sezione di front-end, composta essenzialmente da sistemi di proxy, garantisce il disaccoppiamento delle connessioni dei client dai server applicativi. Come accennato nel paragrafo 4.3
questa sezione verrà implementata in un secondo momento.
7. Sezione applicativa
7.1. Tecnologia
La sezione applicativa della Server Farm sartà popolata di server predisposti all’offerta, principalmente, dei servizi “standard” di Internet. In questo campo il software open source è considerato
eccellente; si prevede, pertanto, l’utilizzo di server Linux che ospitano i principali servizi.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 21 di 35
Riccardo Detti
Cristina Mugnai
I server applicativi saranno coadiuvati da un sistema (Linux) in alta affidabilità che opererà
come bilanciatore di carico mediante il software LVS (Linux Virtual Server). Per massimizzare
la capacità di carico dell’intero sistema si è optato (tra le varie configurazioni possibili) per la
configurazione DR (Direct Routing) dell’LVS.
7.2. Servizi
7.2.1. DNS
Il 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̀ basso
e la duplicazione su più server del servizio aumenterebbe soltanto il traffico di rete verso i server
esterni 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 (specialmente in modalità DR), il sistema in alta affidabilità del bilanciatore di carico è ottimale per
ospitare il servizio DNS.
7.2.2. WWW
Ritenendo 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 piattaforma
software per i servizi WWW dovrà soddisfare entrambe le necessità. Inoltre l’evoluzione della
parte informativa statica verso un sistema dinamico di content management è altrettanto importante
e porta a valutare soluzioni software verticali.
L’offerta Oracle della propria piattaforma Application Server e Portal, illustrata recentemente
dai tecnici Oracle in una serie di seminari tenuti presso il CSIAF, potrebbe soddisfare le necessit à
appena esposte oltre ad un insieme di possibiltà, come valore aggiunto, che innalzerebbero sicuramente il livello qualitativo e di servizio del sito web di ateneo. Sono elencate di seguito, in estrema
sintesi, alcune delle caratteristiche salienti del prodotto Oracle:
Il motore HTTP è Apache standard con alcuni moduli (in aggiunta a quelli standard tipo PHP
o 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 come
container per gli Enterprise Java Beans. Questi sono rispettivamente lo standard attuale presso
il CSIAF per la produzione dei servizi via WWW e la piattaforma, più complessa, verso la
quale potrebbero convergere i servizi in futuro.
Il software di portale, che permette funzionalità di alto livello,sia per il processo di management
dei contenuti sia per la naturale integrazione della parte informativa e di servizio. L’ambiente
di portale è integrato in AS.
Il sistema di management permette, mediante l’uso di un database di repository, la configurazione 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 software
di management è in grado di replicare la configurazione su più server mediante l’uso del
repository.
L’AS, o meglio tutti gli applicativi e i servizi via WWW, possono usufruire dell’infrastruttura
di Single Sign On che permette all’utente di autenticarsi una sola volta per qualsiasi servizio
voglia utilizzare.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 22 di 35
Riccardo Detti
Cristina Mugnai
L’AS incorpora anche un server LDAP v3 che oltre alle funzionalità previste dallo standard
offre una capacità di interfaccia diretta verso i database Oracle. Questa caratteristica permetterebbe il caricamento e la gestione dei contenuti del directory server con modalità molto più
lineari e rapide rispetto a quelle degli altri prodotti.
L’AS permette la produzione di report, sia a stampa che pubblicabili via WWW, con strumenti
interattivi che si interfacciano direttamente con il portale, i database ed eventualmente con i
cubi di data warehouse.
Il pacchetto di gestione delle segreterie studenti (GISS) adotta questa piattaforma per la
presentazione via WWW verso i client; GISS sarebbe perfettamente integrabile con indubbi
vantaggi di gestione e di economia.
Nell’eventualità che i prodotti Oracle non siano economicamente sostenibili la scelta alternativa, 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’hardware
può essere vincolata dal tipo di accordo tecnico/economico che si stipulerà con il fornitore. Poiché
normalmente Oracle quota i propri prodotti in base al numero di processori che saranno utilizzati dal
cliente, nel caso venga applicata questa politica, può essere economicamente vantaggioso scegliere
hardware che offra la maggiore potenza possibile per CPU, tipicamente sistemi di fascia media
con processori RISC a 64 bit. Nel caso invece venga stipulato un agreement complessivo, che
ci svincolasse dal numero di CPU che utilizzeremo, potrebbero essere impiegati anche per questa
parte 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 information
retrieval 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 di
carico, mentre la base di dati sarà ospitata da un server dedicato.
7.2.3. Proxy
Per 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 DNS
nel paragrafo 7.2.1. Sembra comunque sia possibile, con una particolare configurazione di LVS e
di Squid, fare cooperare più cache di pari livello; tale possibilità sarà valutata in dettaglio durante
la fase di deployment del servizio. Successivamente, stabilizzato il servizio, pu ò essere affrontata
la valutazione di evolvere il sistema verso il “transparent proxy”, ovvero di rendere automatico il
funzionamento del sistema senza dover configurare ogni client per l’utilizzo del proxy.
7.2.4. Email
Il 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, sia
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 23 di 35
Riccardo Detti
Cristina Mugnai
open source che industriali, soprattutto al fine di integrare questo servizio con gli altri e di unificare
la piattaforma operativa. I pacchetti dovranno essere valutati, come gli altri, in funzione delle loro
potenzialità e della loro rispondenza ai requisiti che si ritengono necessari, ma soprattutto dovranno
essere esaminate le problematiche di passaggio dal sistema attualmente in uso verso quello giudicato
idoneo, 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 la
qualità e la potenzialità del servizio; in particolare:
I server che ospiteranno il servizio saranno Linux o Unix, la loro gestione e manutenzione
sarà omogenea con gli altri server; ad esempio l’aggiornamento del sistema operativo, l’uso
del 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 dei
virus, 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 oggi
un po’ rudimentale, potrà essere integrata con gli altri servizi e utilizzare software allo stato
dell’arte. Ciò potrebbe portare ad utilizzare normalmente questo sistema al posto dei client
(OutLook, Eudora, ecc.) attualmente in uso ed minimizzare le problematiche di installazione
e di funzionamento presso l’utenza.
L’interfacciamento verso il directory server (LDAP) e verso il sistema di Single Sign On
porterà questo servizio a integrarsi completamente con gli altri, facilitandone l’uso all’utente e
al 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 funzionali à,
gestione, migrazione e costi saranno:
PMDF su sistema operativo UNIX, di InnoSoft. Questo è il pacchetto che attualmente è in
funzione sul sistema OpenVMS. Sarà il punto di riferimento per la valutazione degli altri
sistemi.
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 pone
oggi come una delle MTA di riferimento nell’ambiente open source. È il software scelto da
CINECA per il servizio di posta elettronica per gli studenti.
Qmail. È il più sicuro dei software di Email in circolazione. La sua sicurezza risiede anche
sulla semplicità con cui sono implementati i vari servizi. Conta un numero elevatissimo di
utenti soprattutto in realtà molto grandi e sono disponibili molti pacchetti per aumentarne le
capacità: imap, autenticazione sicura, LDAP, ecc.
Courier. Software completamente sviluppato dalla comunità open source (il sito web è ospitato
su Source Forge) ricalca la filosofia di Qmail, ma è molto più aderente agli standard. La
caratteristica saliente è il motore di filtraggio dei messaggi, che risiede all’interno del nucleo
del programma, e che permette l’eliminazione e la corretta gestione del traffico di spam. È
dotato di tutti i servizi, compreso web mail.
7.2.5. FTP
Il 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
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 24 di 35
Riccardo Detti
Cristina Mugnai
(es. ProFTPD) per chi utilizza direttamente il protocollo FTP e potenziando il servizio mediante
l’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 pacchetti
software. Tutto ciò permetterebbe all’utenza di avere un luogo “vicino” di facile e di rapido accesso
e al contempo un sicuro risparmio di traffico verso, e soprattutto da, l’esterno per il download del
software.
La Server Farm si doterà comunque di server per l’accesso FTP, essendo necessario, ad
esempio, per l’upload dei documenti web e per altri servizi (vedi paragrafo 3.3.1.4), così come sarà
disponibile il file sharing via WWW per facilitarne l’uso. La quantità, il tipo di informazioni e la
politica con cui saranno disponibili all’utenza esula però dallo scopo del progetto.
7.2.6. LDAP
Il 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 più
diffusi (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 degli
studenti è da considerarsi obbligatoria.
È attualmente allo studio, con un gruppo di lavoro presso il CSIAF, sia il contesto pi ù prettamente tecnologico rivolto principalmente alle tecniche di autenticazione e al mantenimento dei
dati, sia la valutazione, logica e strutturale, delle informazioni che saranno disponibile nel directory
tree. Il gruppo sta inoltre valutando le caratteristiche tecniche dei vari server disponibili sul mercato
e le loro capacità di interfacciamento verso i database di produzione; in altre parole il gruppo di
lavoro sta cercando il prodotto che permetta il modo più agevole di alimentazione dell’LDAP con i
contenuti dei database del personale e degli studenti.
7.2.7. Streaming
7.2.8. Segreterie Studenti
L’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 il
database 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 di
ateneo e per i servizi online, la parte di presentazione di GISS sarebbe integrata agli altri servizi
condividendone i server e le caratteristiche, come descritto nel paragrafo 7.2.2.
7.3. Servizi interni
7.3.1. File service
Il 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 di
ogni 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̀ del
personale della Server Farm e altri spazi a comune per favorire e semplificare il lavoro di gruppo e
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 25 di 35
Riccardo Detti
Cristina Mugnai
lo scambio di informazioni tra il personale del Centro. Gli spazi disco messi a disposizione saranno
accedibili 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 sistema
esporterà i filesystem sia attraverso la modalità nativa Networked File System, sia attraverso il
server 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 service
I 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 alle
stazioni Windows, mediante Samba, sia alle stazioni Linux/Unix mediante i servizi nativi di remote
print.
La Server Farm si doterà di stampanti adeguate alle necessità del centro; si prevede di utilizzare
una stampante HP in bianco/nero formato A3 con fronte/retro da 32 ppm già presente al CSIAF e
di acquisirne una nuova a colori con caratteristiche simili.
8. Sezione di back-end – Database e servizi ausiliari
8.1. Database
Le 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 un
RDBMS alternativo.
Viceversa l’organizzazione e la gestione dei database a tutt’oggi è assai poco efficace; in pratica
ogni applicativo ha uno (o più) database server dedicato, imponendo una duplicazione delle attività
di aggiornamento del software di sistema e del RDBMS. Anche l’hardware necessario risulta in
eccesso 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 si
avrebbero una serie di vantaggi:
Fault-tolerance e scalabilità. Valgono gli stessi criteri espressi nel paragrafo 4.3. Come per i
server applicativi il cluster di database avrebbe gli stessi vantaggi.
Snellimento delle procedure di gestione. Avendo server uguali ed una sola versione del
RDBMS la manutenzione e l’aggiornamento dei sistemi è meno onerosa. In aggiunta è
possibile mettere in manutenzione un nodo (server) del cluster alla volta mantenendo attivi i
servizi.
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 per ò alcune limitazioni che
devono 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
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 26 di 35
Riccardo Detti
Cristina Mugnai
server risiede il software e tutto l’ambiente operativo di una istanza. Nel caso si abbiano N istanze
su M server si dovranno gestire N * M configurazioni; risulta dunque essenziale cercare di ridurre
al minimo il numero di istanze necessarie.
Ad una prima analisi sembrerebbe possibile unificare l’istanza del database di GISS con
i servizi online, i quali utilizzano in gran parte gli stessi dati, ottenendo anche una maggiore
efficienza ed eliminando quasi totalmente le attività notturne di trasferimento di dati tra server
diversi. Appare invece più problematica la situazione che riguarda CIA, che impone attualmente
quattro istanze (tre di produzione e una di test). Sarà necessario un studio più approfondito del
problema coivolgendo i tecnici che si occupano di CIA al CINECA.
La seconda limitazione imposta dal RAC è di tipo tecnologico/economico; i server devono
montare un sistema di clustering e, soprattutto, devono accedere contemporaneamente allo stesso
spazio disco imponendo, di fatto, l’utilizzo di una SAN. Dovranno quindi essere valutati in dettaglio
i rapporti costo/beneficio dei vari componenti del sistema (Numero e potenza dei server, software
di 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 attuali
all’interno della nuova struttura della Server Farm. I server potrebbero essere gli stessi (o di
nuova 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 miglioramento
delle prestazioni si ottiene acquistando server più potenti.
2) Cluster di server di fascia media (RAC). Un cluster a due o massimo tre nodi costituito da
server di media potenza da 4 o 8 processori; sistema operativo Unix; necessità del software
di clustering; Connessione ridondata alla SAN. È, rispetto alla precedente, una soluzione con
migliori caratteristiche di servizio, che unisce la potenza dei server di fascia media con le
caratteristiche 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 2
o 4 processori; sistema operativo Linux; il software di cluster è incluso nel RAC; connessione
alla SAN. È lo scenario più aggressivo dal punto di vista tecnologico; i punti critici possono
essere: la gestione, a causa dell’elevato numero di nodi del cluster; l’innovazione, in un’area
in cui la stabilità è essenziale.
4) Coppie di server in Cluster HA (Unix o Linux). Due coppie di server a 4 processori; sistema
Linux o Unix (nel caso di Unix il software di clustering va acquistato); connessione ridondata
alla SAN. Ogni server ospita una o più istanze di database (distribuite in base alla stima del
carico). 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 flessibilità
sul numero delle istanze di database, che è destinato a crescere in futuro; garantirebbe inoltre
l’isolamento tra le applicazioni, che può essere un vincolo imposto dalle aziende fornitrici dei
pacchetti applicativi. Il numero di configurazioni è N * 2.
8.2. Storage Area Network
La 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 configurazione ridondata che gestiscono uno o più array di dischi. I controller espongono verso i sistemi
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 27 di 35
Riccardo Detti
Cristina Mugnai
interfacce in fibra ottica a 2Gb/s di tipo Fibre Channel Arbitrated Loop (FC-AL). I dischi contenuti
negli array sono acceduti mediante un doppio canale FC-AL in rame. La connessione dei server
viene effettuata mediante switch ottici (solitamente a 16 o 32 porte) che collegano gli adattatori in
fibra ottica installati sui server ai sistemi a dischi.
Dal punto di vista logico e funzionale si nota innanzitutto che lo storage, normalmente interno
ai server e gestito in modo autonomo, è invece un sistema centralizzato a se stante, con proprie
funzionalità di gestione e di amministrazione, che offre come “servizio” lo spazio disco di cui i vari
server abbisognano. La centralizzazione dello storage offre, come conseguenza diretta, una unica
interfaccia per il management di questa risorsa per tutti i sistemi e una estrema flessibilità nella
pianificazione e nella assegnazione di spazio disco ai vari server.
Altra importante caratteristica introdotta dalla SAN è la possibilità di implementare i server
come cluster in alta affidabilità (HA). Infatti in caso di guasto di un server o di un suo componente
o 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 esempio
controller 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 caratteristiche migliori come sicurezza, gestione e flessibilità di utilizzo. Quest’ultima caratteristica è
estremamente importante in una realtà come quella del CSIAF in cui si ha una continua e rapida
espansione e diversificazione dei servizi offerti.
L’implementazione di una SAN nella Server Farm alza però il costo dell’operazione. Infatti
l’alta tecnologia dei componenti l’infrastruttura (controller, adattatori, switch e dischi), ma soprattutto la classe di mercato in cui questi componenti si collocano, pongono la SAN come elemento
che economicamente non è trascurabile anche se riferito all’intero progetto.
8.3. Sistema di Backup
Il sistema centralizzato di backup è uno degli obiettivi del progetto; attualmente i server
provvedono al salvataggio dei dati e degli ambienti software mediante dispositivi (normalmente
streamer DDS a 4mm) interni ai server stessi o sfruttando via rete i drive di altri server nei momenti
in 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, presenti
sui sistemi devono essere sincronizzate e devono tenere in conto i volumi di dati da salvare e la
durata di ogni operazione. I sistemi periferici (le stazioni di lavoro e i server di workgroup) non
hanno possibilità di backup o, al massimo, utilizzano spazi disco temporaneamente disponibili dei
server.
Il progetto prevede un sistema (Linux) per gestire in modo centralizzato i backup; il server
si interfaccerà ad un dispositivo a natri con tecnologia LTO da 100 GB a due drive e libreria
automatica (autochanger) da almeno 15 nastri, mediante bus SCSI. Al fine di disaccoppiare le
attività di salvataggio dei server (e delle stazioni di lavoro) dalla scrittura fisica sui nastri, il server
di backup sarà dotato di dischi, da utilizzare come buffer, con capacità almeno doppia dei nastri
utilizzati (circa 400 GB).
Sono inoltre disponibili software open source per la gestione centralizzata dei backup (ad
esempio AMANDA) che permettono la schedulazione dei backup, completi e incrementali, dei
server e l’utilizzo efficiente delle librerie di nastri. Questi software sono in grado di interfacciare
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 28 di 35
Riccardo Detti
Cristina Mugnai
i sistemi Windows, in modo da poter ricevere i backup anche dalle stazioni di lavoro di tutto il
personale ed eventualmente da server con questo sistema operativo.
Dovranno invece essere valutate in dettaglio tecniche che permetteranno il salvataggio in modo
fisico delle partizioni di sistema, sia dei server sia delle stazioni di lavoro, al fine di permettere un
ripristino rapido delle funzionalità in caso di guasto ai dischi di sistema, evitando la reinstallazione
dei sistemi operativi e dei software di base.
8.4. Monitoraggio
Lo sforzo progettuale teso alla massima unificazione dei server e dei sistemi operativi all’interno della Server Farm, trova nel sistema di monitoraggio la sua migliore giustificazione. Si ritiene
infatti indispensabile, dato il numero di server, del numero e della complessità dei servizi, un
sistema che permetta in tempo reale l’individuazione e la localizzazione dei guasti degli apparati
di rete e dei server, controlli il corretto funzionamento dei servizi e misuri costantemente il traffico
di rete e il carico di lavoro dei server. L’omogeneità dei sistemi coinvolti semplifica di molto il
delicato processo di messa a punto del sistema di monitoraggio, massimizzando l’efficacia di tale
sistema.
È doveroso citare che mediante l’uso dell’attuale stazione di network management (che utilizza
SUN Network/Domain Manager), orientata più al monitoraggio della rete che dei sistemi, si sono
avuti riscontri molto positivi riguardo alla tempestività delle diagnosi (spesso si sono attivati
interventi prima della segnalazione del guasto da parte dell’utenza) e della gestione della rete di
ateneo.
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 di
monitoraggio, si stanno ultimamente affermando prodotti open source che offrono capacit à comparabili e che dovrebbero integrarsi perfettamente con le strutture previste. In particolare saranno
valutati in dettaglio e verificati mediante test sul campo due prodotti open source: OpenNMS e
Nagios.
OpenNMS, accreditato come uno dei migliori in circolazione, è basato sull’architettura
Java/Servlet, utilizza un database relazionale (PostGres) e files di configurazione XML. Ha capacità di controllo dei sistemi e della rete a basso livello, ma, soprattutto, offre moduli per il
monitoraggio dei servizi (database, email, web, ecc). L’architettura Java semplificherebbe, se fosse
necessario, attivitità di messa a punto e estensione degli agent in base alle conoscenze acquisite in
passato in questo ambiente.
Nagios offre un’ampia gamma di possibilità di controllo sia della rete sia dei sistemi, richiedendo al contempo una infrastruttura di sistema per il funzionamento molto pi ù semplice rispettoa
OpenNMS. È il sistema di monitoraggio più diffuso ed è utilizzato da CINECA per il monitoraggio
del proprio data center.
Dal punto di vista fisico il server che ospita il sistema di monitoraggio sarà connesso alla rete
di back-end, per motivi di sicurezza, e alla SAN in modo da concentrare su una stazione il controllo
di tutta la Server Farm.
9. Dimensionamento dei sistemi
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 29 di 35
Riccardo Detti
Cristina Mugnai
Con scopo puramente introduttivo, al fine di fornire indicazioni per guidare il progetto verso la
fase 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 successivi
descriveranno invece soluzioni tra loro alternative che si differenziano soprattutto sulla tecnologia
di alcuni server e, di conseguenza, sull’architettura complessiva.
9.1. Parte stabile
Si assume innanzitutto di utilizzare software open source per i seguenti “componenti”:
Firewall
DNS
Load balancer
LDAP server
Proxy
Mail server
File e print server
FTP server
Backup server
Management
Come conseguenza (vedi il paragrafo 4.2) questi componenti saranno ospitati da sistemi con
Linux su server in tecnologia X86.
I due firewall previsti dal progetto saranno realizzati come coppie di server Linux in cluster
HA con la seconda unità in stand-by. Ogni sistema sarà dotato di due processori X86 con 1GB di
memoria e 2 NIC ethernet a 1Gb/s.
Un cluster HA ospiterà il DNS e il software di distribuzione del carico (LVS) sul primo server
e il server LDAP di front-end sul secondo. I sistemi saranno dotati di due processori X86, 2GB di
memoria, 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, mentre
il secondo esporterà in NFS il filesystem contenente le mailbox ai server smtp ed offrirà i servizi
POP3/IMAP. I sistemi saranno dotati di due processori X86, 2GB di memoria, Ethernet a 1Gb/s e
interfaccia FC-AL verso la SAN.
Due server per il servizio di email, coordinati dal bilanciatore di carico. I server riceveranno
via SMTP i messaggi di posta, filtrandoli attraverso il software di antivirus, e alimenteranno, via
NFS, le mailbox utente. I sistemi saranno dotati di due processori X86, 2GB di memoria, Ethernet
a 1Gb/s.
Due server per il servizio di proxy, coordinati dal bilanciatore di carico. I sistemi utilizzeranno
il software Squid e saranno configurati in modo da cooperare; offriranno il proxy per i protocolli
HTTP e FTP. La dimensione delle cache è da definire (da 100 a 200 GB ognuna); sarà inoltre da
valutare se implementare le cache su dischi locali o invece farle insistere sulla SAN. I sistemi saranno
dotati di due processori X86, 2GB di memoria, Ethernet a 1Gb/s e, eventualmente, interfaccia FCAL verso la SAN.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 30 di 35
Riccardo Detti
Cristina Mugnai
Un server per il sistema di backup. Il sistema sarà dotato di due processori X86, 1GB di
memoria, Ethernet a 1Gb/s; il sottosistema a nastri, i dischi e il software di gestione sono descritti
nel 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 soprattutto
delle procedure dei servizi online e dei contenuti (statici e dinamici) dei siti web si ritiene utile un
server, posto sulla lan di front-end, dedicato appunto allo sviluppo. Tale sistema sar à dotato di due
processori 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 valutare
in dettaglio), il nuovo programma per il protocollo (Titulus), l’application server per CIA-WEB
e l’application server per GISS. A parte quest’ultimo, di caratteristiche note, questi servizi sono
ancora in fase sperimentale o addirittura ancora da implementare; il numero e il dimensionamento
dei server che li ospiteranno sarà possibile quando saranno note le caratteristiche di funzionamento
e di carico previsto per questi servizi.
9.2. Server ad alto carico – Prima ipotesi
Dalla 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 di
database previste e di un server applicativo in front-end.
Il database server potrebbe consistere in un server di fascia media, configurato con 8 processori
RISC 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 essere
partizionato (cioè di funzionare come due o più server) in modo da permettere l’ottimizzazione delle
risorse, la manutenzione del software di sistema e applicativo e l’esecuzione di interventi harware
senza interrompere i servizi. Caratteristiche simili (o leggermente inferiori) sono necessarie per
il server applicativo che ospiterà i server HTTP, gli application server, le procedure per i servizi
online e i software di portale (e/o di content management).
I fattori positivi di questa ipotesi sarebbero: utilizzo ottimale delle risorse hardware, affidabilit à
di questa classe di server, economia e snellimento delle fasi di implementazione e di manutenzione
del 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 ipotesi
Questa 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 carichi
di 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 necessari
due server, con configurazioni simili a quelle definite per i db server, coordinati dal bilanciatore di
carico. Gli elementi positivi di questa ipotesi sono: economia di acquisto e di gestione, completa
ridondanza dei sistemi, uniformità delle problematiche di gestione e manutenzione con gli altri
server della Farm.
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 31 di 35
Riccardo Detti
Cristina Mugnai
Incide negativamente, per i db server, una maggiore complessità iniziale di implementazione
e messa a punto delle tecniche di alta affidabilità che devono garantire la continuità dei servizi a
fronte di qualsiasi problema.
Appendice A – Descrizione dei sistemi attuali
MAIL
mail1.unifi.it, mail2.unifi.it, smtp.unifi.it, Compaq DS20E 6/500 + DS20E 6/833 in cluster
1 Alpha EV68 500MHz + 1 Alpha EV68 833MHz
1GB + 1GB
9GB internal + 18GB internal, mirrored
External SCSI array: 90GB mirrored, 18Gb spare
2 10/100 Mbps Ethernet adapters
Digital OpenVMS 7.3
Multinet 4.3
Innosoft PMDF 6.0
WASD 7.1.1
yahMAIL
Servizi: Mail Server di Ateneo
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Disks:
Network:
Sistema operativo:
Software di base:
DNS
dns.unifi.it
SUN Ultra 10
1 UltraSparc II 440 MHz
512 MB
9.1GB internal
Solaris 8
Bind 9.2
Tacacs
Servizi: DNS Primario di Ateneo
Servizi: Autenticazione connessioni remote
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
Database:
Database:
Servizi:
WWW
www.unifi.it
SUN Blade 1000
1 UltraSparc III 750 MHz
512 MB
36GB internal
Solaris 8
Apache 1.3.9
mySQL 2.0.11
miniSQL 2.3.22
Web Server di Ateneo
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
Software di base:
Database:
Servizi:
Note:
Pag. 32 di 35
Riccardo Detti
Cristina Mugnai
WWW2
www2.unifi.it
Compaq ProLiant 370
1 Intel P4 1.0GHz
1 GB
20GB internal
MS Windows 2000 Server
MS IIS 5
Navita WebMate
MS SQL Server 2000
Web Server di Ateneo
Ospita la sezione “Studenti” del Web di Ateneo
STRM
sb1.unifi.it
SUN Blade 1000
1 GB
18.2 internal
Solaris 8
Apache 1.3.9
RealServer 8.01
Servizi: Video streaming (Real Video)
Note: Proprietà di CINECA
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
Software di base:
Database:
Servizi:
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
EPRES
epress.unifi.it
SUN SS 20
1 Sparc II 50 MHz
32 MB
6 GB
1 10 Mbps Ethernet adapter
Solaris 8
Apache 1.3.9
Perl 5.005 36
mySQL 3.23.36
Server Web University Press
MSTUD
mail.student.unifi.it
SUN Enterprise 250
512 MB
20GB internal, mirrored
1 10/100 Mbps Ethernet adapter
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 33 di 35
Riccardo Detti
Cristina Mugnai
Sistema operativo: Solaris 7
Software di base: Apache 1.3.4
Innosoft PMDF 5.2
Endymion MailMan Standard edition
Servizi: Mail server per gli studenti
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
Servizi:
PROXY
proxy.unifi.it
PC assemblato
Intel P4 2.0GHz
512MB
108GB EIDE, internal
Linux RedHat 7.2 (Kernel 2.4.9-31)
Squid 2.4 Stable 4
Proxy server di ateneo
WWWS
?.unifi.it
PC assemblato
Intel P3 600GHz
128
8.5 EIDE, internal
Linux RedHat 6.2 (Kernel 2.2.19-6.2.16)
Proxy server di ateneo
Apache 1.3.9
BIND 8.2.3
Servizi: Web server per gli studenti
DNS secondario di ateneo
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Servizi:
Software di base:
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Disks:
I/O:
Network:
Sistema operativo:
Software di base:
OLS
alicudi.unifi.it
SUN Enterprise 3500
2.5 GB
External FibreChannel array: 200 GB RAID5, 36 GB spare
2 I/O subsystems
Solaris 2.6
Apache 1.3.9
iPlanet Web Server 6.0 + java 1.3.1
java SDK 1.3.1
SUN C compiler
Perl 5
TCL 7.3
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 34 di 35
Riccardo Detti
Cristina Mugnai
Database: Oracle 8.1.6
Basis+ 8.3
Servizi: Servizi online per gli studenti
Catalogo online delle biblioteche (OPAC)
DEVEL
salina.unifi.it
SUN Blade 1000
1 GB
Solaris 8
Apache 1.3.9
php
Database: Oracle 9i 9.0.1
Servizi: Prototipo anagrafe della ricerca
Base dati PEOPLE
Progetto Data Warehouse
Note: Il database PEOPLE è acceduto direttamente dai client
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
DNS2
dns.unifi.it
SUN Ultra 10
256 MB
18.2GB internal
Solaris 8
BIND 9.2
ProFTPD
Qmail
Servizi: DNS Secondario di Ateneo
Server di posta per il rettorato – dismesso
FTP server per l’aggiornamento dei client CIA
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Disks:
I/O:
Network:
Sistema operativo:
Database:
CONT
contab.adm.unifi.it
SUN Enterprise 3500
1.75 GB
9.1GB internal, mirrored
External SCSI array: 50 GB mirrored, 18 GB spare
2 I/O subsystems
Solaris 2.6
Oracle 8.1.7
autorizzazione.
Tipo di documento:
Relazione Tecnica
Data:
File:
Prot:
Allegati:
Approvato da:
Revisione:
1.0
Pag. 35 di 35
Riccardo Detti
Cristina Mugnai
Servizi: Contabilità Integrata di Ateneo (CIA)
Protocollo
Note: Istanze Oracle (5) accedute direttamente dai client
Sigla in Figura 1:
Hostname:
Hardware:
CPU:
RAM:
Disks:
Network:
Sistema operativo:
Software di base:
Servizi:
STUDas
studenti.adm.unifi.it
IBM e-server PSeries 640(B80)
2 Power II 375 MHz
4 GB
AIX 4.3
Oracle Application Server
Gestione Integrata Segreterie Studenti (GISS)
Sigla in Figura 1:
Hardware:
CPU:
RAM:
Disks:
Disks:
Network:
Sistema operativo:
Database:
Servizi:
Note:
STUDdb
IBM e-server PSeries 640(B80)
2 Power II 375 MHz
2 GB
External SCSI array 6X18.2GB, RAID 5
AIX 4.3
Oracle 8.1.6
Gestione Integrata Segreterie Studenti (GISS)
2 server identici in cluster HA/CMP
3 istanze Oracle (produzione, test, migrazione)
autorizzazione.

nuova server farm – progetto

Transcript

Documenti analoghi

direttamente dai palchi di vasco rossi, san remo e music farm.

Tutto sulla Service Farm Sistemi

Aperte le scommesse a quota fissa sul reality tv "Music farm"

Trodat 5460

POLITECNICO DI TORINO 10.00 Prof. Rodolfo ZICH Introduzione ai

move! do something

SOSTIENI FARM CULTURAL PARK

VEDI - Carducci

DELIBERAZIONE n°1232 del 02.10.2012