[trashware] dimensionare LTSP

Ruggero Russo ruggero.russo@gmail.com
Mar 4 Ott 2005 10:43:10 CEST


Per la configurazione il problema vero è il server.
Sulla documentazione ufficiale del 2003 si diceva che un pIII con 512Mb di
ram poteva far funzionare ottimamente 10 macchine. Ora sul wiki (nuovo
mooolto interessante) del sito ltsp riportano una formuletta che ti
consiglio di vedere. La ram dei client non è un problema a meno che tu non
decida di far girare delle applicazioni in locale.
Spero di esserti stato utile,
ciao
R.

On 10/3/05, Andrea Della Regina <zmajl@maidirezmaj.it> wrote:
>
> Cherubini Enrico ha scritto:
>
> >Ciao,
> >non so se qualcuno ha visto il progetto nell'ambito di installare
> macchine
> >un po' vecchiotte...io mi trovo nella situazione di vedere di
> riutilizzare
> >dei P233 come terminali di una rete LTSP, il problema e' di dimensionare
> il
> >server. Qualcuno ha qualche idea di massima ? Da quello che ho capito i
> >dischi devono essere della massima velocita' possibile (SCSI
> quindi...magari
> >in striping), RAM in abbondanza (ma quella si puo' aumentare senza grossi
> >problemi), mentre il problema e' il processore (o i processori)...qualche
> >suggerimento ?
> >
> >
> Qui tra Padova e Venezia Faber e Velug hanno realizzato alcuni progetti
> LTSP. Io c'ero in alcuni di questi, se vuoi assistenza su questi
> argomenti sono a tua disposizione, comunque sono in molti in lista
> quelli ad avere gia' usato questa tecnologia.
>
> Partiamo dal processore: in condizioni standard il server deve essere in
> grado di fare velocemente tutto cio' che ci si aspetta che i client nel
> suo complesso facciano... perche' e' su di lui che vengono in effetti
> eseguite le applicazioni.
> Quindi quella che conta e' ad esempio la velocita' con cui il server
> riesce ad eseguire OpenOffice, la quale e' la stessa avvertibile (a meno
> di sostanziosi ritardi nella rete) su di un thin-client in una topologia
> 1-a-1 (un server ed un client su postazione disk-less). Questo velocita'
> e' data in gran parte dal processore ma anche dalla velocita' di accesso
> ai dischi e naturalmente dal fatto di non swappare mai durante
> l'esecuzione. Assicurarsi poi che queste applicazioni non siano soggette
> a fenomeni di progressiva occupazione/bufferizzazione della memoria.
>
> Il discorso dei dischi scsi andrebbe trattato a parte: quanti accessi al
> disco si prevede? va detto che la parte di file system exportata per il
> caricamento del sistema sui client di rete e' irrisoria (il sistema
> exportato e' minimale appunto perche' si lavora con macchine piccole),
> quindi anche se partissero 10 pc contemporaneamente il ritardo della
> rete sarebbe sempre maggiore di quello anche di un normale disco IDE.
> Resta quindi la parte relativa alle diverse directory home degli utenti
> connessi: se 10 utenti fanno frequenti compilazioni di codice, ad
> esempio, la velocita' del disco e' fondamentale, in altri casi l'uso di
> quotare lo spazio sul disco puo' ridurre i danni di un uso eccessivo
> della risorsa disco da parte di utenti (che magari si mettono a
> scaricare file enormi da internet). Direi che invece per quanto concerne
> la cache dei diversi programmi non vi siano problemi, dato che /tmp e'
> montato in ramfs (almeno mi sembra...), ed eventualmente anche la cache
> del browser si puo' mettere li' se proprio si vuole.
>
> La RAM e' invece il discorso piu' delicato: il server deve fare il suo
> lavoro bene con la giusta dose di ram (diciamo 128 MByte per un sistema
> con kernel 2.4 e magari un window manager frugale ), il resto dei client
> hanno bisogno di una dose di ram a testa che si puo' quantificare in
> 50-70 Mbyte per thin-client come base, ma che cresce se le applicazioni
> che si usano sono via via piu' esose in fatto di memoria.
> Comunque, per esperienza personale, 5 client (4 thin ed il server)
> avviati con Kernel 2.6 sul server, Gnome, OpenOffice e Firefox aperti su
> ogni client, quindi totale spreco di risorse, richiede per lavorare bene
> che il server abbia 1GByte di RAM (il che e' un po' sovradimensionato,
> ma il quel caso non si e' stato a guardare per il sottile). In questo
> caso il server era un buon Pentium 4 con dischi IDE.
> Sui client invece 64 MByte sono piu' che sufficienti, ma se dotati di
> coraggio tutti mi rassicurano che si puo' scendere fino a 16.
>
> I client se sono dei PII 233 sono decisamente sovradimensionati per
> quello che devono fare, pero' almeno sei sicuro che arrivno a corredo di
> una scheda grafica decente, dato che e' questa assieme al monitor a dare
> la risoluzione del desktop dell'utente.
>
> Infine la rete: l'ideale entro i dieci terminali e' una rete basata su
> switch da 100MBit/s, soprattutto nel caso di un nuovo acquisto, comunque
> anche un hub da 10MBit/s da le sue soddisfazioni, vorrei provare una
> rete in coassiale, prima o poi.
>
> Ti ricordo che esiste anche il progetto thin-station
> http://thinstation.sourceforge.net/ che dovrebbe piu' parco in risorse
> lato server e client di ltsp ma che io stesso ho solo intravisto e mai
> usato proficuamente.
>
> Ciao e buon lavoro/esperimento/hacking
> ManicheN
>
> --
> Andrea Della Regina - zmajl[at]maidirezmaj[dot]it
> MaiDireZmaj - http://www.maidirezmaj.it/
> Telefono / Phone Number - (+39) 393 516 7974
>
>
>
>
> --
> Mailing list info: http://lists.linux.it/listinfo/trashware
>
>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://lists.linux.it/pipermail/trashware/attachments/20051004/cf0e2d72/attachment.htm


Maggiori informazioni sulla lista trashware