<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9"> <TITLE>HOWTO: Multi Disk System Tuning: Considerazioni e Dimensionamento</TITLE> <LINK HREF="Multi-Disk-HOWTO-11.html" REL=next> <LINK HREF="Multi-Disk-HOWTO-9.html" REL=previous> <LINK HREF="Multi-Disk-HOWTO.html#toc10" REL=contents> </HEAD> <BODY> <A HREF="Multi-Disk-HOWTO-11.html">Avanti</A> <A HREF="Multi-Disk-HOWTO-9.html">Indietro</A> <A HREF="Multi-Disk-HOWTO.html#toc10">Indice</A> <HR> <H2><A NAME="s10">10. Considerazioni e Dimensionamento</A></H2> <P> <!-- disco!considerazioni e dimensionamento --> Il punto di inizio in questo, sarà considerare dove siete e cosa volete fare. Un tipico sistema casalingo inizia con hardware esistente e l'utente Linux convertito da poco vorrà ottenere il massimo dall'hardware esistente. Qualcuno che mette su un nuovo sistema per uno scopo specifico (come un ISP) dovrà considerare invece quale è lo scopo e comprare in relazione ad esso. Essendo ambizioso, cercherò di ricoprire l'intero ambito. <P>Vari scopi avranno anche necessità differenti riguardanti il posizionamento del file system sui dischi, una grande macchina multiutente sarà migliore con la directory <CODE>/home</CODE> su un disco separato, solo per dare un esempio. <P>In generale, per prestazione è vantaggioso dividere la maggior parte delle cose su più dischi possibili ma c'è un numero limitato di dispositivi che possono vivere su un bus SCSI ed il costo è naturalmente un altro fattore. Ugualmente importante, la manutenzione del file system diventa più complicata con l'aumentare del numero delle partizioni e dei dischi fisici. <P> <H2><A NAME="ss10.1">10.1 Sistemi casalinghi</A> </H2> <P> <!-- disco!considerazioni e dimensionamento!sistemi casalinghi --> Con l'hardware economico che si può comprare oggi, è possibile avere un sistema grande a casa che è ancora economico, sistemi che battono i maggiori server del passato. Mentre molti hanno iniziato a mettere su un server Linux con vecchi dischi scartati (che è il motivo per il quale è nato questo HOWTO), molti possono permettersi oggi di comprare dischi da 20 GB. <P>La dimensione rimane importante per alcuni, e qui ci sono un po' di linee guida: <P> <DL> <DT><B>Testare</B><DD><P>Linux è semplice e non avete nemmeno bisogno di un disco rigido per provarlo, se potete fare il boot dai floppy, probabilmente riuscirete a farlo funzionare sul vostro hardware. Se il kernel standard non vi funziona, non dimenticate che spesso ci possono essere versioni speciali dei dischi di boot per combinazioni inusuali di hardware che possono risolvere i vostri problemi iniziali fino a che non compilate il vostro kernel personale. <P> <DT><B>Conoscere</B><DD><P>il sistema operativo è qualcosa in cui Linux eccelle, c'è una marea di documentazione ed i sorgenti sono disponibili. Un disco singolo con 50 MB è sufficiente per farvi iniziare con una shell e una cerchia ristretta dei comandi e delle utilità più frequentemente utilizzate. <P> <DT><B>Un utilizzo per hobby</B><DD><P>o per un apprendimento più serio richiede più comandi ed utilità ma un disco singolo è ancora ciò che è necessario, 500 MB saranno spazio sufficiente, sia per i sorgenti che per la documentazione. <P> <DT><B>Serio</B><DD><P>sviluppo software o semplicemente serio lavoro richiede anche molto altro spazio. A questo stadio, probabilmente avrete entrate di posta e news che richiedono file di coda e molto spazio. Dischi separati per compiti di vario genere cominceranno a mostrare un beneficio. A questo stadio probabilmente avrete anche un po' di dischi. Le necessità di dischi diventano più dure da stimare ma mi aspetterei che 2-4 GB siano sufficienti, anche per un piccolo server. <P> <DT><B>I server</B><DD><P>sono di molti tipi, variando da server di posta fino a server ISP di piena grandezza. Una base di 2 GB per il sistema principale dovrebbe essere sufficiente, poi aggiungete spazio e forse anche dischi per caratteristiche separate che offrirete. Il costo è il maggior fattore limitante qui ma siate preparati a spendere un po' se volete giustificare la "S" dell'ISP. In verità non tutti lo fanno. <P>Praticamente un server è dimensionato come ogni macchina per utilizzo serio con spazio aggiunto per i servizi offerti, e tende ad essere limitato dall'IO piuttosto che dalla CPU. <P>Con tecnologia economica sia per linee di terra come anche per reti radio, è molto probabile che molto presto, gli utenti casalinghi avranno i propri server più o meno permenentemente agganciati alla rete. </DL> <P> <H2><A NAME="ss10.2">10.2 Server</A> </H2> <P> <!-- disco!server --> Grossi compiti richiedono grossi dischi ed una sezione separata qui. Se possibile mantenete quanto più possibile su dischi separati. Qualcuna delle appendici descrivono il setup di un piccolo server dipartimentale per 10-100 utenti. Qui presenterò un po' di considerazioni per i server limite. In generale non dovreste avere paura di utilizzare RAID, non solo perché è veloce e sicuro ma anche perché rende la crescita un po' meno dolorosa. Tutte le note qui sotto sono aggiunte ai punti menzionati in precedenza. <P>I server popolari raramente sono lì per caso, piuttosto, crescono nel tempo e questo richiede quantitativi generosi di spazio disco come anche una buona connessione di rete. In molti di questi casi potrebbe essere una buona idea riservare ad ogni compito interi dischi SCSI, da soli o in fila. In questo modo potrete spostare i dati nel caso il computer fallisse. Notate che trasferire i dischi attraverso i computer non è semplicissimo e potrebbe anche non funzionare sempre, specialmente nel caso di dischi IDE. Gli insiemi di dischi, richiedono setup attenti al fine di ricostruire i dati correttamente, quindi potreste voler mantenere una copia cartacea del vostro file <CODE>fstab</CODE> come anche una nota degli ID degli SCSI. <P> <H3><A NAME="server-home-dirs"></A> Directory Home </H3> <P> <!-- disco!server!directory home --> Stimate di quanti dischi avete bisogno, se sono più di 2, raccomanderei RAID, fortemente. Altrimenti dovreste separare gli utenti attraverso i vostri dischi dedicati agli utenti basati su una qualche specie di semplice algoritmo di hash. Ad esempio potreste utilizzare le prime due lettere del nome utente, quindi <CODE>jbloggs</CODE> viene situato in <CODE>/u/j/b/jbloggs</CODE> dove <CODE>/u/j</CODE> è un link simbolico ad un disco fisico quindi potete ottenere un carico bilanciato sui vostri dischi. <P> <H3>FTP Anonimo </H3> <P> <!-- disco!server!FTP, anonimo --> <!-- disco!server!FTP anonimo --> Questo è un servizio essenziale se siete seri riguardo al servizio. I server buoni sono ben mantenuti, documentati, aggiornati e immensamente popolari, non importa dove sono localizzati nel mondo. Il grosso server <A HREF="ftp://ftp.funet.fi">ftp.funet.fi</A> è un eccellente esempio di ciò. <P>In generale questo non è una questione di CPU ma di ampiezza di banda di rete. La dimensione è difficile da calcolare, principalmente è una questione di ambizione e attitudini del server. Credo che il grosso archivo presente presso <A HREF="ftp://ftp.cdrom.com">ftp.cdrom.com</A> sia una macchina *BSD con un disco da 50 GB. Inoltre anche la memoria è importante per un server FTP dedicato, circa 256 MB di RAM sarebbero sufficienti per un server molto grande, anche se server più piccoli possono farcela bene anche con 64 MB di RAM. Le connessioni di rete sarebbero comunque sempre il fattore più importante. <P> <P> <H3><A NAME="www"></A> WWW </H3> <P> <!-- disco!server!WWW --> <!-- disco!server!World Wide Web --> Per molti questa è la ragione principale per andare in Internet, infatti ora sembra che molti li considerino la stessa cosa. Inoltre ad essere intensi in rete consegue il fatto di avere un bel po' di attività nei dischi per questo motivo, principalmente riguardante le cache. Mantenere le cache su un disco separato e veloce, porterebbe beneficio. Anche meglio sarebbe installare un server proxy di cache. In questo modo potreste ridurre la dimensione della cache per ogni utente ed aumentare la velocità del servizio riducendo nello stesso tempo le necessità di ampiezza di banda. <P> <P>Con un server proxy di cache, avrete bisogno di un insieme di dischi veloci; RAID0 sarebbe l'ideale visto che l'affidabilità qui non è importante. Una capacità più alta è importante ma circa 2 GB sarebbero sufficienti per la maggior parte. Ricordatevi di far coincidere il periodo della cache con la capacità e la domanda. Periodi troppo lunghi sarebbero d'altro canto uno svantaggio, se possibile provate a regolare a seconda dell'URL. Per maggiori informazioni, controllate i server più utilizzati come <CODE>Harvest</CODE>, <A HREF="http://www.nlanr.net/Squid">Squid</A> e quello della <A HREF="http://www.netscape.com">Netscape</A>. <P> <H3>Posta</H3> <P> <!-- disco!server!posta --> Gestire la posta è qualcosa che molte macchine fanno fino ad un certo punto. I grandi server di posta, comunque, fanno gruppo a parte. Questo è un compito su richiesta e un grande server può essere lento anche se connesso a dischi veloci e ad una rete molto efficiente. Nel mondo Linux, il grande server come <CODE>vger.rutgers.edu</CODE> è un esempio ben noto. Diversamente da un servizio di news che è distribuito e che può parzialmente ricostruire lo spool utilizzando altre macchine come meccanismo di alimentazione, i server di posta, sono centralizzati. Questo rende la sicurezza molto più importante, quindi per un server principale, potreste considerare una soluzione RAID con enfasi sull'affidabilità. La dimensione è difficile da stabilire, dipende tutto da quante liste fate girare e da quanti iscritti avete. <P>Notate che in questi giorni si sta passando dall'utilizzare <CODE>POP</CODE> per prelevare la posta sulla macchiana locale dal server di posta all'utilizzo di <CODE>IMAP</CODE> per servire la posta mantenendo gli archivi di posta centralizzati. Questo vuol dire che la posta non è più accodata nel senso originale ma spesso cresce, richiedendo un'enormità di spazio disco. Inoltre sempre più si (ab)usano i messaggi con allegati per spedire ogni sorta di roba, anche un piccolo documento di un elaboratore testi può facilmente finire sopra il MB. Dimensionate i vostri dischi generosamente e controllate quanto spazio resta. <P> <P> <H3>News</H3> <P> <!-- disco!server!news --> Questo è sicuramente un compito di grande volume e molto dipendente dal gruppo a cui vi iscrivete. Sul Nyx c'è un meccanismo di alimentazione molto completo ed i file di coda occupano circa 17 GB. I gruppi più grandi sono senza dubbio nella gerarchia <CODE>alt.binary.*</CODE>, quindi se per qualche ragione decidete di non averli, potete avere un buon servizio forse con 12 GB. In ogni caso altri, che rimarranno senza nome, pensano che 2 GB siano sufficienti per conferirsi il titolo di ISP. In questo caso le news scadono molto velocemente che penso che chiamarli IsP è abbastanza giustificato. Un completo meccanismo di alimentazione per le news significa un traffico di qualche GB ogni giorno e questo è un numero sempre crescente. <P> <P> <H3>Altri</H3> <P> <!-- disco!server!altri --> Ci sono molti servizi disponibili sulla rete e nonostante ciò molti sono stati messi nell'ombra dalla rete. Nonostante ciò servizi quali <EM>archie</EM>, <EM>gopher</EM> e <EM>wais</EM> esistono ancora e rimangono strumenti di valore sulla rete. Se state pensando in maniera coscienziosa di iniziare a creare un server principale, dovreste anche considerare questo servizio. Determinare lo spazio necessario è difficile, dipende tutto dalla popolarità e dalla domanda. Fornire un buon servizio ha inevitabilmente i suoi costi, lo spazio disco è solamente uno di essi. <P> <P> <H3>Raccomandazioni sul Server</H3> <P> <!-- disco!server!raccomandazioni --> I server oggi richiedono molti dischi per funzionare in maniera soddisfacente per le impostazioni commerciali. Visto che il tempo medio tra i fallimenti (MTBF) diminuisce rapidamente con l'aumentare dei componenti, è consigliabile utilizzare RAID per protezione ed utilizzare un numero di dischi di media grandezza piuttosto che uno singolo ed enorme. Inoltre guardate anche nell progetto High Availability (HA) per maggiori informazioni. <P> <P> <P> <H2><A NAME="ss10.3">10.3 Trappole</A> </H2> <P> <!-- disco!trappole --> I pericoli di dividere ogni cosa su partizioni separate sono brevemente menzionati nella sezione riguardante la gestione del volume. Comunque, molte persone mi hanno chiesto di enfatizzare questo punto più fermamente: quando una partizione si riempie, non può crescere di più, non importa se c'è un mare di spazio su altre partizioni. <P>In particolare tenete d'occhio la crescita esplosiva nella coda delle news (<CODE>/var/spool/news</CODE>). Per macchine multi utente con le quote tenete sotto controllo <CODE>/tmp</CODE> e <CODE>/var/tmp</CODE> visto che c'è qualcuno che cerca di nascondere i propri file lì, basta cercare i file che finiscono per gif o jpeg... <P>Praticamente, per singoli dischi fisici questo schema offre guadagni molto piccoli, piuttosto che rendere più facile il controllo della crescita dei file (utilizzando '<CODE>df</CODE>') e del posizionamento fisico delle tracce. Più importante, non c'è possibilità per accesso di disco parallelo. La disponibilità di avere un sistema per la gestione di un volume potrebbe risolvere ciò, ma ciò accadrà in futuro. Comunque, quando file system più specializzati saranno disponibili, anche un disco singolo potrà beneficiare dall'essere diviso in diverse partizioni. <P> <P> <P> <HR> <A HREF="Multi-Disk-HOWTO-11.html">Avanti</A> <A HREF="Multi-Disk-HOWTO-9.html">Indietro</A> <A HREF="Multi-Disk-HOWTO.html#toc10">Indice</A> </BODY> </HTML>
