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