Per il server abbiamo deciso di installare una distribuzione GNU/Linux, EdUbuntu che fornisce gia' integrati molti software a scopo didattico, e un ambiente di base gia' predisposto per una struttura del tipo ServerTerminali.
Finita l'installazione abbiamo proceduto a configurare le varie componenti del sistema necessarie per il corretto funzionamento del progetto LTSP quali server DHCP, server NFS e server OpenSSH.
Soluzioni Client - Server: il progetto LTSP
Il progetto LTSP (Linux Terminal Server Project) fornisce un modo semplice per (ri)utilizzare
dei computer a basso costo come terminali, sia in modo grafico che in modo testo,
collegandoli ad un server GNU/Linux.
In una tipica situazione d'ufficio o in un laboratorio scolastico su ogni postazione vengono
normalmente utilizzati computer abbastanza potenti, basati su processori Intel o compatibili,
ognuno con molti gigabytes di spazio su disco fisso. Ciascun utente memorizza i propri dati
sul disco rigido presente nel computer e molto raramente vengono effettuati dei backup.
Ha veramente un senso avere un computer completo su ciascuna postazione ?
Ragionevolmente no. Possiamo migliorare questa situazione. Fortunatamente c'è
un'alternativa. Utilizzando LTSP, si possono usare anche PC piuttosto datati o comunque di
scarse prestazioni. Basta, eventualmente aggiungere una scheda di rete con supporto per il
boot da rete. La maggior parte delle schede di rete ha un alloggio ove inserire una ROM che
permette il boot da rete, o semplicemente installando il programma di Etherboot su un
supporto (floppy disk).
Durante la fase di accensione (la fase di boot), il computer,seguendo le istruzioni del
programma contenuto nel floppy disk, ottiene le informazioni necessarie per far funzionare la
rete (come il proprio numero IP) ed il kernel Linux (la parte fondamentale di questo sistema
operativo) dal server, quindi accede ai dischi (monta il filesystem) tramite il servizio NFS.
Il computer della postazione di lavoro (workstation) può: essere configurato nei 3 modi sotto
descritti:
- Interfaccia Grafica con Sistema X Window: la workstation può: essere usata per accedere a qualsiasi applicazione presente sul server o su altri server eventualmente presenti all'interno della stessa rete.
- Sessioni tramite telnet ad interfaccia in modalità testo: la workstation può: instaurare una o più sessioni telnet con il server. Ogni sessione telnet viene collocata in uno schermo virtuale separato.
Sono possibili più sessioni in contemporanea fino ad un massimo di 9 sessioni. Premendo i tasti da Alt-F1 a Alt-F9 sarà possibile passare da una sessione ad un'altra.
- Shell prompt (linea di comando): la workstation può: essere configurata in modo da fornire direttamente e semplicemente una linea di comando (la bash shell) sulla console. Questo può: essere molto utile in alcuni casi, ad esempio quando è necessario, in fase di configurazione correggere
eventuali problemi che possono insorgere con il sistema X Window o con il collegamento
NFS.
Più nello specifico il metodo che abbiamo scelto consiste nel copiare l'Etherboot nel boot
sector del floppy. Quindi tutto funziona come nel caso del boot rom(boot effettuato tramite
una rom inserita nella scheda di rete). Il codice letto dal boot record del floppy viene
eseguito, la scheda di rete viene inizializzata e il kernel viene caricato in memoria dal server
via rete.
Etherboot nel dettaglio
Consideriamo in prima istanza una singola workstation sul nostro segmento di rete,
equipaggiata quindi con una scheda Ethernet e, di conseguenza, univocamente
riconoscibile dal suo MAC address.
All'accensione tale macchina carica l'immagine
contenuta nel floppy, così accede ai servizi di rete per ottenere quanto necessario per il
boot. La prima informazione che deve ricavare è un indirizzo di rete IP che la identifichi, in
modo da poter successivamente richiedere l'immagine del kernel e l'accesso al suo
file system; per far ciò:, in fase di accensione, istruita dall'immagine sul floppy, la workstation
effettua un broadcast notificando a un qualsiasi server BOOTP (BOOTstrap Protocol) o
DHCP presente nel segmento di rete il suo MAC address.
A questo broadcast il server
BOOTP, dopo aver consultato una tabella interna, risponde fornendo alla workstation un
nome simbolico, un indirizzo IP, l'indirizzo IP del server da cui effettuare il boot e il nome di
un'immagine del kernel che dovrà caricare. Una volta ottenute queste informazioni il client
deve scaricare il kernel indicatogli ed eseguirlo: in questa fase entra in gioco il TFTP (Trivial
File Transfer Protocol), una versione ridotta del più conosciuto FTP, priva di autenticazione,
controlli e funzionalità complesse. Proprio utilizzando il protocollo TFTP il client scarica dal
server fornitogli dal BOOTP il suo kernel. Eseguito il kernel cosi ottenuto ora non resta che
montare un filesystem via rete e terminare la sequenza di boot del sistema.
Possibili problemi con il dischetto
Quando parte il boot dal floppy dovrebbe apparire qualcosa del tipo:
loaded ROM segment 0x0800 length 0x4000 reloc 0x9400
Etherboot 5.0.1 (GPL) Tagged ELF for [LANCE/PCI]
Found AMD Lance/PCI at 0x1000, ROM address 0x0000
Probing...[LANCE/PCI] PCnet/PCI-II 79C970A base 0x1000, addr 00:50:56:81:00:01
Searching for server (DHCP)...
L'esempio riportato qui sopra mostra cosa dovreste aspettarvi di vedere quando avviene il
boot da floppy. Se non vengono visualizzati questi messaggi, che indicano che è partito
l'Etherboot, allora probabilmente il dischetto floppy è sbagliato: o il dischetto floppy è
danneggiato o l'immagine non è stata scritta sul floppy in modo corretto.
Se viene visualizzato un messaggio del tipo riportato qui sotto, allora probabilmente vuol
dire che l'immagine che è stata generata non è quella adatta per la vostra scheda di rete.
ROM segment 0x0800 length 0x8000 reloc 0x9400
Etherboot 5.0.2 (GPL) Tagged ELF for [Tulip]
Probing...[Tulip]No adapter found
Se arriva al punto in cui rivela la scheda di rete e mostra il corretto MAC address, allora il
dischetto floppy è probabilmente corretto e funzionante.
Per ottenere un nuovo dischetto sarà neccessario andare sul sito web www.Rom-O-Matic.net di Marty Connor, che ha fatto un eccellente lavoro mettendo in piedi un'interfaccia per il web per la configurazione e la compilazione necessaria per creare un
immagine bootrom con Etherboot. Sul suo sito, selezionate la versione più aggiornata
disponibile (latest production release) di etherboot, selezionate il tipo di scheda di rete che
avete ( NOME DELLA SCHEDA) e che tipo di immagine volete. Per avere il formato per il
floppy scegliete 'Floppy Bootable ROM Image'. Questa scelta aggiunge un header di 512
byte che fa sì che il boot loader venga caricato in memoria da dove poi viene eseguito.
Inoltre avete anche la possibilità di modificare alcune opzioni di configurazione del
Etherboot. A questo punto premete il pulsante 'Get ROM' (ottieni ROM) e una immagine
personalizzata del bootrom verrà generata in breve tempo.
Dopo alcuni secondi che avete premuto il bottone, il vostro browser farà comparire una
finestra pop-up "Save As" (o "Salva con nome") in cui sceglierete il nome con cui salvare il
file sul vostro computer. Una volta che avete salvata l'immagine sul vostro disco fisso dovete
scriverla sul vostro floppy. Inserite il disco floppy nel vostro lettore di floppy e date il seguente
comando per scrivere sul floppy:
dd if=Etherboot_Image of=/dev/fd0
dove al posto di Etherboot_Image dovete mettere il nome del vostro file immagine, ed
eventualmente il percorso se non è nella directory corrente( /../.. ../Etherboot_Image).
Chiaramente questo comando deve essere eseguito su un computer Linux. A questo punto
potrete riconnettervi normalmente al server.
La soluzione FreeNX
FreeNX è un proxy server open source per i protocolli di controllo remoto del display X11,
RDP e VNC; è in grado di operare una compressione del traffico di rete incrementando
notevolmente le prestazioni con linee lente.
E' basato sulle librerie NX sviluppate dall'azienda NoMachine e rilasciate dalla stessa
secondo licenza GPL.
Con questa tecnologia è possibile collegarsi ad un server da remoto (anche su linee
telefoniche lente) utilizzandolo anche da PC obsoleti, ed usare programmi altrimenti
ingestibili da questi stessi PC. Può: quindi essere considerato come alternativa a LTSP, ed è
anche più semplice da installare e configurare. Il client è disponibile per Linux, Mac e
Finestre.
Il client FreeNX si può: liberamente scaricare da www.nomachine.com. L'installazione non
richiede nulla di particolare. Al primo avvio è sufficiente configurare l' indirizzo ip del server e
porta ssh (in genere 22, se non l'abbiamo modificata); a questo punto possiamo entrare con
l'utente di sistema Linux.
Testing delle due soluzioni: LTSP e FreeNX
Abbiamo testato i due tipi di soluzioni praticabili FreeNX e LTSP mettendole a
confronto,tramite l'utilizzo contemporaneo del software disponibile su tutti i client e
verificandone le prestazioni.
E' risultata una superiorità di prestazioni da parte di LTSP sotto diversi punti di vista:
- maggiore fluidità e velocità nell'interazione con l'interfaccia grafica;
- maggiore longevità e stabilità, FreeNX era più facilmente soggetto a crash
(errori,instabilità...);
Questi motivi ci hanno portato a scegliere la soluzione LTSP e tenere l'altra, FreeNX , solo
come ripiego nel caso di problemi con la prima.
Distribuzione utilizzata: Edubuntu
"Ubuntu" è un'antica parola africana, dal significato "umanità agli altri". Un ulteriore
significato è: "io sono ciò: che sono per merito di ciò: ce siamo tutti". La distribuzione
Edubuntu Linux migra lo spirito di Ubuntu nelle scuole, poichè è stato studiato per un
ambiente scolastico.
Per ora Edubuntu è rivolto solamente a questo ambiente ma nel prossimo futuro sarà
adattato anche ad altri ambiti come quello Universitario. Deriva da Ubuntu, basata a sua
volta su Debian.
Fra gli altri programmi, Edubuntu include Linux Terminal Server Project (LTSP), un gran
numero di applicazioni educative tra le quali GCompris e la raccolta di programmi di
edutainment di KDE, nonchè Schooltool Calendar.
Edubuntu utilizza il desktop environment GNOME e la versione attuale supporta le
piattaforme i386, AMD64 e PowerPC. Edubuntu include più di 16000 pacchetti ma il sistema
di base si installa con unsingolo CD.
Installazione e configurazione Server
La distribuzione usata, Edubuntu, dispone dalla versione 6.10 un ambiente integrato per
LTSP che ha permesso di evitare la parte di creazione di un ambiente in un chroot minimale
per i client in quanto già predisposto.
Abbiamo assegnato al server un indirizzo di classe C e poi configurato tutti i client di
conseguenza.
I file principali sono :
/etc/ssh/sshd_config
Il file per la configurazione del demone ssh essenziale per l'avvio di applicazioni sul server
dai client.
In questo file e' necessaria che sia abilitata l'opzione
X11Forwarding yes
per rendere possibile il forward di applicazioni grafiche sui client
/opt/ltsp/i386/etc/ltsp.conf
Il contiene la configurazione dei singoli client LTSP.
In questo file si possono fare configurazione globali (valide per tutti i client LTSP) o
configurazioni specifiche a seconda dei client (come far caricare un modulo audio o un
modulo video al particolare client, o abilitargli una stampante)
/etc/ltsp/dhcpd.conf
Il file per la configurazione del demone dhcp.
Nel nostro caso abbiamo impostato in modo che venissero assegnati degli indirizzi ip
specifici a seconda del MAC Address di ogni scheda, in modo da avere un corrispondenza
fissa tra un indirizzo ip e una macchina, in caso siano necessarie configurazioni speciali.
/etc/exports
Contiene i parametri per la configurazione di nfs, e sono indicati le cartelle da esportare via
rete
Nel nostro caso conteneva
/opt/ltsp *(ro,no_root_squash,async)
che significa esportare la cartella /opt/ltsp verso tutta la rete in sola lettura.
/var/lib/tftpboot/ltsp/i386/
Cartella che contiene le immagini del kernel che utilizzeranno i client per bootare.
/opt/ltsp/i386
Cartella che contiene l'ambiente per il chroot del sistema minimale LSTP.
Amministrazione del server
I vantaggi di una soluzione LTSP sono, oltre al risparmio di soldi e tempo di comprare e
configurare diverse macchine, la facilita' di manutenzione e di amministrazione del tutto.
Poiche' LTSP e' una soluzione centralizzata tutto il lavoro di manutenzione deve essere
svolto solo in un punto ( il server ), e operazione amministrative ( come l'installazione di un
nuovo software ) devono essere svolte su una sola macchina.
Edubuntu mette a disposizione strumenti molto potenti per l'amministrazione quale Synaptic
( frontend grafico per apt ), che permette grazie a una connessione internet di installere e
configurare molti software in pochi click, aptitude e ntop.
Aggiungere utenti e' altrettanto facile grazie agli strumenti integrati in gnome ( come usersadmin
) che permette in pochi secondi di aggiungere nuovi utenti e modificare i privilegi di
utenti gia' esistenti.
Test di prestazioni
Per misurare le potenzialità del sistema sono stati condotti alcuni test in particolare
riguardo all'utilizzo della rete, della memoria e dell'utilizzo della CPU del server,
considerando che il lavoro svolto dalle macchine client si limita alla semplice
visualizzazione dei programmi e quindi non è minimamente oneroso in termini di utilizzo di
risorse.
Il primo test condotto è stato quello dell'utilizzo della banda sulla rete fra le postazioni,
avendo a disposizione uno switch 100 Mb/s. Per far questo è stato usato il software Open
Source ntop, che tra le molte possibilità è anche in grado di creare dei grafici del carico di
rete. Il primo grafico mostra il momento dell'accensione delle macchine, che sono state
accese contemporaneamente.
Chiaramente questo è un momento di grande traffico in
quanto ogni client richiede al server l'immagine di boot, che viene scaricata alla massima
velocità possibile: il picco verso la fine rappresenta questo momento (gli altri erano
esperimenti di accensione di macchine isolate) e come si può: notare va poco oltre i 60
Mb/s, traffico del tutto accettabile.
Un'altra prova è stata fatta durante l'utilizzo normale delle macchine dopo che erano state
avviate dando come risultato il seguente grafico.
In questo caso si ha un picco intorno alle 14.34 che corrisponde al momento di lancio e di
esecuzione delle applicazioni pesanti su alcuni computer, non tutti. Qui in effetti si ha un
collo di bottiglia che potrebbe essere risolto grazie alla sistituzione con uno switch Gigabit
Ethernet, ma come vedremo in seguito in realtà queste applicazioni pongono dei seri
problemi anche alla potenza del processore.
Passando adesso ai test sul carico del processore, che ricordiamo essere un Intel Core2
Duo E6750 a 2.66GHz, quindi in realtà composto da due processori, possiamo vedere
attraverso la prossima immagine che durante l'utilizzo normale con i 10 client accesi e
ognuno usato per eseguire applicazioni della suite OpenOffice il carico medio delle due
CPU si aggira intorno al 20%.
Questo dato fa anche riflettere su come un'architettura del genere sfrutti meglio la potenza
elaborativa del server, considerando che solitamente nei laboratori delle scuole sono
contenute tante macchine ognuna con una potenza simile a quella del nostro server e che
quindi sfruttano il proprio processore all'12% della sua potenza reale.
Il discorso cambia quando si utilizzano programmi applicativi che usano pesantemente la
grafica, come i videogiochi: in quel caso ci siamo accorti che il processore diventa il collo
di bottiglia, lavorando al 99% e comunque non riuscendo a soddisfare le richieste dei
singoli client e quindi di fatto quelle applicazioni risultano inutilizzabili.
Ribadiamo comunque che questo si verifica solo per alcune applicazioni particolari come i videogiochi
e che quindi non inficia la validità generale della soluzione.
L'ultima serie di test è stata condotta per verificare la quantità di memoria utilizzata sul
server, considerando che la quantità totale di memoria è di 4 GB, di cui solo 3.6 utilizzabili
effettivamente perchè gli altri sono occupati dalla scheda grafica che non dispone di una
propria memoria.
Durante l'utilizzo normale con tutti i client accessi e ognuno che esegue
programmi diversi si è verificata la quantità di memoria libera e quella occupata tramite il
programma vmstat e graficando i risultati con Calc, ottenendo il seguente diagramma.
La linea blu rappresenta la quantità di memoria usata mentre quella rossa quella libera: si
può: notare che il quantitativo di memoria usata in condizioni normali non supera mai i
2GB. Nella successiva prova si è proceduto ad aprire su tutte le macchine client un solo
programma, The Gimp, una applicazione di fotoritocco piuttosto avida di memoria,
ottenendo i seguenti risultati, che confermano che il server riesce a ottimizzare l'uso della
memoria quando più client usano la stessa applicazione, poichè molta parte viene
condivisa tra le diverse istanze.
In questo caso la memoria usata è contenuta sotto gli 1.5 GB, e dal momento in cui non
solo aperte più applicazioni si stabilizza. Infine si è provato ad far aprire in sequenza una
serie di programmi su tutti i client e si è notato che l'utilizzo di memoria, pur aumentando a
mano a mano che nuove applicazioni venivano aperte, non portava comunque a superare
mai i 2.5 GB di memoria.
Alla fine della prova su ogni client erano caricati tutti i programmi
della suite OpenOffice più altri e questo dimostrava che la memoria non diventa mai un
collo di bottiglia in nessuna condizione operativa.
Vai alla pagina precedente
|