Nous en savons maintenant assez pour parler de placement. J'ai mis ma m�thode au point apr�s avoir essay� toutes les combinaisons possibles sur mes 3 vieux disques SCSI.
Les tables donn�es en appendice servent � simplifier le processus. Elles vous aideront � optimiser votre syst�me mais aussi � le d�panner �ventuellement. Quelques exemples sont donn�s.
R�fl�chissez � vos besoins et posez sur le papier une liste de toutes les parties de votre syst�me de fichiers que vous voulez mettre sur une partition s�par�e. Notez la taille de chacune et triez-les par vitesse d�croissante.
La table du chapitre Appendice A est utile pour choisir quels r�pertoires mettre dans quelles partitions. Elle est tri�e par ordre logique, avec des blancs pour vos notes personnelles et des remarques sur les points de montage. Elle n'est PAS tri�e par vitesse d�croissante, mais les besoins en vitesse sont indiqu�s par des petits ronds ('o').
Si vous voulez utiliser du RAID notez avec quels disques vous voulez le faire et quelles partitions seront en RAID. Notez que les diff�rents modes RAID offrent une vitesse et une fiabilit� variable. Pour simplifier, on suppose dans la suite qu'on a un ensemble de disques SCSI identiques et pas de RAID.
Il faut maintenant d�terminer sur quelles disques physiques seront plac�es les partitions choisies ci-dessus. Voici un algorithme pour optimiser le parall�lisme et l'utilisation du bus. Dans notre exemple les partitions � placer sont 123456789, 9 est celle qui a besoin de la plus grande vitesse et 1 est la plus lente. On les r�partit comme suit:
A : 9 4 3
B : 8 5 2
C : 7 6 1
Cela fait une "moyenne des vitesses" � peu pr�s �gale sur chaque disque.
Utiliser la table de l'appendice B pour d�terminer quels disques utiliser pour quelles partitions afin de profiter au maximum du parall�lisme.
Notez la vitesse de chacun de vos disques dans la bonne colonne. �ventuellement, permutez les r�pertoires, les partitions et les disques jusqu'� �tre content du r�sultat.
L'�tape suivante est de s�lectionner les num�ros de partition pour chaque disque.
Utilisez la table du chapitre
appendice C
pour s�lectionner les num�ros de partitions � l'int�rieur de chaque
disque. Remplissez avec ces valeurs les tables des Appendices A et B.
Ces tables vous serviront lorsque vous installerez votre syst�me
(�tape de partitionnement avec fdisk ou cfdisk)
Des consid�rations sp�cifiques � un mat�riel ou � un type d'utilisation peuvent intervenir. Par exemple si le disque C est beaucoup plus lent que les deux autres il vaudra mieux adopter la r�partition suivante:
A : 9 6 5
B : 8 7 4
C : 3 2 1
Des disques de vitesse globale comparable peuvent s'av�rer plus ou adapt�s � un usage ou � un autre. Comme on l'a d�j� dit, les binaires, qui sont nombreux et petits, sont bien � leur place dans un disque de temps d'acc�s moyen faible et qui g�re une queue des requ�tes. Les librairies et autres gros fichiers profiteront davantage d'un disque ayant un bon taux de transfert, ce que les disques IDE offrent pour pas cher.
On peut �viter la surcharge du disque en pensant aux t�ches. Par
exemple si vous ex�cutez un programme de /usr/local/bin il y
a des chances que vous acc�derez aussi � /usr/local/lib;
placer ces deux r�pertoires sur des disques physiquement diff�rents
permet de diminuer le temps de recherche et autorise les op�rations en
parall�le ou l'utilisation du cache. Des gains de performance
surprenants peuvent �tre obtenus ainsi. Identifiez les t�ches
communes, les partitions qu'elles utilisent et gardez ces partitions
sur des disques physiquement diff�rents.
Voici quelques exemples:
comme les traitements de texte ou les tableurs sont des exemples typiques de logiciels peu gourmands en temps CPU comme en acc�s disque (une fois lanc�s). Cepandant, ces logiciels ont souvent des fonctions de sauvegarde automatique qui cr�ent du traffic dans les r�pertoires personnels des utilisateurs. Avoir les r�pertoires personnels sur plusieurs disques r�partira la charge.
ont aussi des fonctions de sauvegarde automatique, et les fournisseurs d'acc�s � Internet ont int�r�t � s�parer les r�pertoires utilisateurs entre plusieurs disques.
Les queues des serveurs de News (/var/spool/news) sont connues pour
leurs grand nombre de r�pertoires et de fichiers. La perte d'une telle
partition n'est pas grave dans la plupart des cas, donc le RAID 0 lui
convient parfaitement. Avec beaucoup de petits disques le syst�me
pourra supporter un grand nombre de requ�tes par seconde. On peut m�me
mettre les news et les fichiers .overview sur des disques
s�par�s: voir les FAQs sur les serveurs INN � ce sujet.
Voir aussi la page Web d�di�e � l'optimisation des serveurs INN
sont gourmandes en terme d'acc�s disques comme de temps de calcul. Cela d�pend beaucoup de l'application envisag�e. On peut envisager le RAID pour avoir � la fois performance et fiabilit�.
met en jeu les r�pertoires des utilisateurs comme les queues de courrier arriv�/� envoyer. Si possible garder les r�pertoires des utilisateurs et les queues sur des disques diff�rents. Pour un serveur de courrier on peut envisager de mettre les queues de courrier re�u et � envoyer sur des disques diff�rents.
Perdre du courrier est extr�mement g�nant, si vous �tes un fournisseur d'acc�s ou un routeur. Envisager le RAID et faire des sauvegardes fr�quentes.
peut demander un grand nombre de
r�pertoires pour les binaires, les librairies, les fichiers
d'en-t�te, les sources et l'archive. S�parer autant que possible tous ces
r�pertoires. Sur des petits syst�mes vous pouvez placer
/usr/src et l'archive sur le m�me disque que les r�pertoires
personnels.
est � la mode. Les butineurs ont souvent un cache local qui peut grossir pas mal. Comme le cache est utilis� pour recharger des pages ou retourner � la page pr�c�dents, la vitesse compte. Cepandant, si vous �tes connect�s � un bon serveur de proxy les utilisateurs n'ont plus besoin de cache individuel. Voir aussi Les r�pertoires personnels des utilisateurs et Le Web.
Lorque vous achetez une bo�te de 10 c�d�roms avec une distribution Linux et le contenu de gros sites FTP, il peut �tre tentant de vouloir installer autant de choses que vos disques le peuvent. Cependant, vous ne tarderez pas � trouver que �a vous laisse bien peu de place pour �voluer. Voil� pourquoi je soulignerai quelques points importants.
Linux est simple et vous n'avez m�me pas besoin d'un disque dur pour cela. Il sufit d'une disquette de d�marrage comme celles fournies avec les distributions. Si vos p�riph�rique ne sont pas support�s, n'oubliez pas qu'il y a souvent plusieurs versions de disquette de d�marrage pour les p�riph�riques exotiques qui peuvent vous d�panner jusqu'� la compilation d'un noyau personnalis�.
comment marche un syst�me d'exploitation est tr�s facile avec Linux: c'est un syst�me qui vient avec les sources et une abondante documentation. Un disque de 50 Mo suffit pour avoir un shell et les utilitaires les plus courants.
des programmes plus nombreux sont n�cessaires, mais 500 Mo sur un seul disque devraient suffire pour les binaires, les sources et la documentation.
ou amateur s�rieux, il faut encore plus de place, des queues pour le courrier �lectronique et les nouvelles, etc. S�parer les fichiers entre plusieurs disques peut �tre b�n�fique. La place requise est plus difficile � estimer, mais 2 � 4 Go devraient �tre plus que suffisants, m�me pour un petit serveur.
vont du simple serveur de courrier �lectronique au gros serveur pour un fournisseur d'acc�s � Internet. Compter 2 Go pour le syst�me de base, ajouter ensuite de la place (et probablement des disques) pour chaque service propos�. Le co�t est ici le facteur limitant mais si on veut justifier le S de Service il faut bien d�penser un peu. J'admets que tous les fournisseurs d'acc�s ne le font pas.
Dans les appendices on trouvera les valeurs � employer pour un serveur d�partemental (de 10 � 100 utilisateurs). Dans cette section on parlera des grands serveurs. De mani�re g�n�rale n'ayez pas peur d'employer le RAID, pas seulement parce qu'il est rapide et fiable mais aussi parce qu'il est un peu plus facile de faire grandir un syst�me RAID. Ce qui est mentionn� ici s'ajoute aux remarques pr�c�dentes.
Le plus souvent les gros serveurs ne sont pas apparus comme �a, mais ils ont grandi progressivement. Dans la plupart des cas c'est une bonne id�e de r�server un ou plusieurs disque SCSI pour chaque t�che. Cela permet de r�cup�rer efficacement les donn�es si le serveur est hors d'usage. Notez que transporter un disque d'une machine � une autre n'est pas si simple, en particulier pour les disques IDE. Et les tours de disques SCSI ont besoin d'une initialisation correcte pour reconstruire les donn�es, donc vous devez garder une copie papier de votre fichier /etc/fstab comme des num�ros de s�rie des disques SCSI.
Faites une estimation du nombre de disques requis, si c'est plus que 2
je recommande fortement le RAID. Si vous ne l'utilisez pas, vous
pouvez utiliser un algorithme de hachage simple pour r�partir la
charge entre les disques. Par exemple vous pouvez utiliser les deux
premi�res lettres du nom de login, ainsi jbloggs est mis sur
/u/j/b/jbloggs o� /u/j est un lien symbolique vers
un disque physique.
C'est un �quipement essentiel si vous attachez de l'importance � la notion de service. Les bons serveurs sont bien maintenus, document�s, � jour, et tr�s populaires o� qu'ils soient dans le monde. Le serveur ftp.funet.fi (ndT: et en France ftp.lip6.fr) est un exemple de "gros serveur FTP".
En g�n�ral c'est plut�t la bande passante du r�seau que la vitesse du processeur qui compte. La taille varie beaucoup. Je crois que l'archive de ftp.cdrom.com est une machine *BSD avec 50 Go de disque. La m�moire vive est importante aussi: 256 Mo pour un gros serveur mais de plus petits peuvent se contenter de 64 Mo.
Pour beaucoup c'est la principale raison d'aller sur l'Internet. En plus de consommer de la bande passante, cette activit� g�n�re des besoins en cache disque. Garder le cache sur un disque rapide, � part peut �tre int�ressant. Avoir un serveur de proxy est encore mieux. Cela peut r�duire la taille du cache pour chaque utilisateur et acc�l�rer le service en diminuant la bande passante utilis�e.
Un serveur de cache a besoin d'un ensemble de disques rapides, le
RAID0 est id�al dans ce cas car la fiabilit� n'est pas primordiale.
2 Go devraient suffire. Ne pas oublier d'adapter la dur�e de vie des
pages dans le cache � la capacit� disque et aux besoins. On peut
adapter la dur�e de vie selon les serveurs, voir:
Harvest,
Squid
ou le serveur de
Netscape
pour plus de d�tails.
La plupart des machines manipulent, peu ou prou, du courrier �lectronique. Cependant, les grands serveurs de courrier forment une cat�gorie � part. C'est une t�che tr�s exigeante et m�me un gros serveur dot� de disques rapides et d'une bonne connexion au r�seau peut se r�v�ler lent � l'usage. A la diff�rence des news qui sont r�parties sur plusieurs serveurs, le courrier �lectronique est centralis�. La s�curit� est donc bien plus importante. Pour un gros serveur envisagez une solution RAID redondante (RAID4 ou RAID5).
C'est une t�che qui demande de grands volumes, mais cela d�pend
beaucoup du nombre de forums o� vous souscrivez. Sur Nyx il y a en a
17 Go. Les plus grands groupes sont sans doute dans la hi�rarchie
alt.binary.*, vous pouvez sans doute assurer un bon service
avec 12 Go si vous ns vous abonnez pas � ces groupes. Certains que je
ne nommerai pas pensent que 2 Go suffisent pour pr�tendre assurer un
"Service d'Acc�s � Internet". Dans ce cas les news expirent si vite
que le mot de "service" se justifie peu. Un vrai serveur de news
signifie un trafic de plusieurs Go par jour, et ce nombre ne cesse de
cro�tre.
Il y a plein de services disponibles sur Internet, m�me si la plupart ont �t� jet� aux oubliettes par la Toile. Cependant, des services comme archie, gopher et wais existent encore et restent des outils appr�ciables.
Les dangers de tout scinder entre des partitions distinctes sont mentionn�s dans la section sur la gestion de volume. Mais on m'a demand� d'insister sur ce point: quand une partition est pleine, elle ne peut plus grandir, m�me s'il y a de la place sur les autres partitions.
En particulier, il faut veiller � la croissance explosive de la queue
des News (/var/spool/news). Pour les machines
multi-utilisateurs avec des quotas gardez un oeil sur /tmp et
/var/tmp car certains utilisateurs stockent leurs fichiers
l�, recherchez seulement les noms de fichiers termin�s par gif ou
jpeg ...
Il n'y a aucun avantage � tirer d'un seul disque scind�
en plusieurs partitions, si ce n'est que �a rend la surveillance des
fichiers (avec la commande 'df') plus facile et que �a permet
de mettre les partitions rapides sur le milieu (physique) du disque.
Mais �a n'apporte rien en terme d'acc�s en parall�le � plusieurs
partitions
Une mani�re d'�viter le pi�ge mentionn� ci-dessus est de ne mettre que
les partitions dont la taille est peu susceptible de varier comme le swap,
/tmp et /var/tmp et de regrouper les autres dans les
partitions restantes au moyen de liens symboliques.
Exemple: Soit un disque lent (slowdisk), et un disque rapide
(fastdisk), et une collection de fichiers. Nous mettons
swap et tmp sur fastdisk; /home et la racine
sur slowdisk. Et nous avons encore les r�pertoires (fictifs)
/a/slow, /a/fast, /b/slow and
/b/fast � placer sur les deux partitions /mnt.slowdisk et
/mnt.fastdisk faites avec l'espace restant sur chaque disque.
Mettre /a ou /b directement sur l'une des deux
partitions donnera les m�mes propri�t�s � tous les sous-r�pertoires de
chacun de ces r�pertoires, et nous voulons l'�viter. Tailler 4
partitions pour ces 4 r�pertoires ferait perdre de la flexibilit�,
nous l'�viterons aussi. La bonne solution est de faire de ces 4
r�pertoires des liens symboliques vers les bons r�pertoires de chacun
des disques. Ainsi:
/a/fast lien symbolique vers /mnt.fastdisk/a.fast
/a/slow lien symbolique vers /mnt.slowdisk/a.slow
/b/fast lien symbolique vers /mnt.fastdisk/b.fast
/b/slow lien symbolique vers /mnt.slowdisk/b.slow
Et nous avons tous les r�pertoires rapides sur le disque rapide sans avoir � faire une partition pour chacun d'entre eux.
Le d�savantage est que c'est relativement compliqu� et qu'il faut pr�voir tous les points de montage, liens symboliques et partitions avant d'installer le syst�me.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:42