Partitions sur un serveur

Bon, je me dis bien que le sujet risque d'être à polémique, mais je pense aussi que certains conseils simples peuvent aider sur comment partitionner un disque dur pour un serveur.

• Une bonne documentation à lire : http://www.pathname.com/fhs/

• La page sur [:LVM:]

Comment partitionner correctement son disque sans perdre trop de place et sans trop risquer de blocage au cas ou une partition se retrouve pleine. Cela va dépendre du type de service offert par le serveur en question.

Notez qu'en utilisant [:LVM:] vous pourrez facilement agrandir une partition. Ne soyez pas trop "large" dans vos prévisions, n'utilisez pas forcément tout le disque disponible sur votre système afin d'en réserver une partie pour agrandit une partition trop pleine ou créer une nouvelle partition.

• Base :

  • Racine (/) : 1 Go est largement suffisant

  • /boot : 128 Mo

  • /usr : 2 Go suffisent

  • /var : 2 Go suffisent

  • /tmp : 512 Mo suffisent

  • swap : entre 512 Mo et 1 Go, selon l'humeur du jour

• Particularités

  • Serveur de fichiers pour les utilisateurs : /home séparé, en général assez important, 10 à 500 Go, tout dépend de la dimension de votre installation.

  • Serveur web; /var/www séparé. 2 à 5 Go suffisent dans un premier temps.

  • Bases de données et assimilés : /var/lib/ séparé, 2 Go.

  • Serveur avec beaucoup d'activité : /var/log séparé, 2 Go.

  • Serveur gérant des fils d'attentes, notamment pour la messagerie : /var/spool séparé, 2 Go.

  • Serveur cache (Squid) : /var/spool/squid séparé, 2 à 30 Go.

  • Serveur de mail : /var/mail pour stocker les message. Taille en général importante voire très importante car aujourd'hui on préconise l'utilisation de IMAP, les messages restent stockés sur le serveur.

  • Serveur de backup [:BackupPC:] : avoir une partition à part /var/lib/backuppc. Taille... heu... très très grande

Sur un poste client (type Ubuntu)

On installe une racine / de 10Go, un swap égal à une à deux fois la RAM. Le /home est soit monté depuis un serveur de fichier (par [:NFS:], soit mis sur une partition à part (cas pour une machine personelle de type portable).

Discussions

• JeanChristopheAndré :

  • 1 Go pour / carrément excessif dans le cas où on sépare /usr, personnellement je dépasse rarement les 600 Mo pour / et /usr combinés, même dans le cas d'un serveur multi-services, et je taille donc la somme des deux entre 700 Mo et 1 Go.

  • De même pour les 2 Go pour /var à partir du moment où on sépare /var/log, /var/lib, /var/spool, /var/mail, /var/www, etc, le reste tourne autour de 100 Mo.

  • À noter qu'avec VServer le /tmp est un montage tmpfs ce qui veut dire qu'il est directement en mémoire et que son accès est donc des plus rapides. Cela montre aussi qu'on peut la plupart du temps de limiter à un /tmp de quelques dizaines de Mo. Par ailleurs, quid de /var/tmp qui n'est pas séparé et pourrait être faire un DoS en cas de remplissage volontaire ?

  • Pour le /home, je n'y touche plus directement car je le découpe maintenant systématiquement en /home/local pour les comptes locaux et /home/... (par exemple /home/share ou encore /home/enseignants et /home/etudiants) pour les comptes partagés. Je ne fais donc plus de partition pour /home mais éventuellement pour /home/local (et encore, les admins sont sensés être sérieux) et pour les autres /home/....

  • Pour /var/lib il faut souvent découper encore, sachant que certains services peuvent remplir le disque et corrompre les autres, par exemple un départ en vrille de amavis empêchant les écritures pour mysql.

  • Pour backuppc, ne pas oublier qu'il mutualise les fichiers identiques et qu'il compresse tout, donc la taille n'a pas besoin d'être si grande que ça, par exemple largement moins grande (jusqu'à 5 voir 10 fois moins) que pour l'espace pour /var/mail.

  • Pour Ubuntu je mets également le swap dans les 10 Go, 1 Go dans /var/swapfile, pour des questions de facilités ensuite avec udpcast : une seule partition à transmettre et pas de problème d'identification de la partition de swap (ni UUID qui change ni référence directe au disque). À noter qu'avec les noyaux 2.6 ça ne change rien aux performances (cf [http://lkml.org/lkml/2005/6/29/11 ici] et [http://lkml.org/lkml/2005/7/7/326 là] ; Andrew Morton étant pour moi une référence suffisamment solide).