CentOS 6 : schéma de partitionnement

Introduction

Suite à l'installation d'un nouveau serveur muni du système d'exploitation CentOS en version 6, je me suis posé la question du partitionnement.

Après la lecture de la documentation officielle de RedHat sur le sujet, j'en suis arrivé à la conclusion que le schéma de partitionnement ci-dessous convenait très bien pour un serveur avec 2 Gio de RAM et quelque soit la taille du disque dur associé.

Schéma

/boot : 256 Mio
/ : 4 Gio
swap : 4 Gio
/home : 256 Mio
/tmp : 256 Mio
/var : 4 Gio

Explication des tailles

Malgré le gros disque dur, il ne me semble pas nécessaire de tailler de grosses partitions dès le départ puisqu'elles peuvent facilement s'agrandir par la suite en fonction des besoins, d'autant que c'est une opération faisable à chaud via LVM (sauf les partitions / et /boot qui ne sont pas en LVM mais qui ne sont pas sensés grossir après l'installation, sauf à empiler les kernel 🙂 ).

Par ailleurs, je considère que les applications principales devraient avoir leur propre volume logique pour le stockage des logs et données, le schéma indiqué ici ne devrait donc s'appliquer qu'à l'espace utilisé par le système et les applications mineures.

/boot : destiné à accueillir le noyau du système d'exploitation, je le laisse à la taille recommandée de 256 Mio
/ : contient la plupart des fichiers et logiciels du système d'exploitation, notamment dans /usr que RedHat ne conseille pas de placer sur une partition séparée pour des questions de compléxité du processus de démarrage
swap : avec 2 Gio de RAM, on peut encore utiliser la formule de calcul "swap = 2 * RAM". Au-delà et jusque 8 Gio, mettre la même taille que la RAM
/home : taille minimum, à ajuster plus tard en fonction du nombre d'utilisateurs et de leurs besoins
/tmp : taille minimum
/var : contient des applications et sert de base au téléchargement des mises à jours de paquets : une taille de 4 Gio est plutôt conseillée

Et après ?

Le reste de la taille sera affecté à un ou plusieurs groupe de volumes LVM afin de pouvoir le distribuer plus tard aux différentes applications hébergées sur le serveur.

Variantes

Quelques variantes discutées dans les commentaires :

/home à 1 Gio
/var à 8 Gio
/tmp à 4 Gio
placer /usr et /lib dans des volumes séparés plutôt que dans /, et avoir un / plus petit

Posted

April 18, 2014

CentOS/RedHat

admin

Tags:

CentOS, LVM, RedHat

Comments

6 responses to “CentOS 6 : schéma de partitionnement”

thasos

April 20, 2014

Coucou ^^

pour /var, je conseille aussi de séparer les logs est les datas à proprement parler, tu peux même sortir de l’arbo /var et faire un /data à côté…

par contre, perso, je préfère avoir un petit / et séparer /usr (voir même /lib) car tu vois direct que si ton / grossit, c’est anormal

enfin, pour la swap, tu peux mettre plus de 2 Go, mais ça dépend de ton applicatif, quand ton apache commence à swapper à plus de 2 Go, vaut mieux le sortir de la VIP car c’est pas normal 🙂 en plus les perfs seront considérablement ralenties

@+ !

Reply
1. Cyril
  
  April 20, 2014
  
  Coucou 🙂
  
  Pour les logs et les data dans le var, j’ai pour habitude de dédier un système de fichiers aux applications, avec leurs logs et leurs données (parfois mêmes plusieurs systèmes de fichiers, dans le cas d’une base de déonnes par exmeple). Pour moi dans le /var il ne devrait y avoir que les logs systèmes.
  
  Je suis plutôt d’accord sur le /usr et le /lib, c’est d’ailleurs ce que j’ai l’habitude de faire sur Debian/Ubuntu. Néanmoins ici je me suis dit que j’allais suivre la recommandation RedHat 😉
  
  Assez d’accord sur le swap aussi (même si là j’ai mis 4 Gio, pas 2), personnellement je considère qu’aucun applicatif ne devrait swapper, donc 4 Gio c’est déjà énorme 😉
  
  Je vais ajouter une section “Variantes” pour la prise en compte des commentaires !
  
  Merci pour le retour 🙂
  
  Reply
Cascador

April 19, 2014

Hello,

On a le même point de vue sur LVM, ça apporte une souplesse exceptionnelle. Cependant vu la taille de ton disque dur, je te trouve dur en affaire avec des répertoires essentiels à ta gestion (logs) et au fonctionnement de ton serveur (répertoires et fichiers temporaires).

Perso, j’aurai fait :
/home : 1 Gio je n’ai pas d’argument, pour le fun lol
/var : 8 Gio, c’est beaucoup voire trop mais j’assume, les logs ça bouffe de la place pour peu que le site soit important
/tmp : 4 Gio, pour être à l’aise
/ : Je pense que tu ne changeras pas la taille et je n’y vois pas grand-chose à redire mais tu as pensé au 5% de l’espace réservé à root ?

Ce que je veux dire, c’est qu’avec ce que je propose ci-dessus, tu consommes même pas 10 Gio de plus. Tu t’évites une probable opération dans le futur même si elle est simple (je ne connais pas une opération réellement simple quand le serveur est en prod). Et tu ne peux pas dire que ces 10 Gio te manqueront car sinon c’est que tu as mal sizé tes besoins et ton serveur.

Une discussion intéressante, rarement croisée sur le net, est de sizer intelligement les besoins sur un serveur. En ce qui me concerne et pour un serveur existant, je prends la taille actuelle occupée par les données et je multiplie par deux pour les 6 années où ce serveur devra fonctionner. Aujourd’hui et heureusement, on se retrouve très régulièrement avec des disques durs minumum 4 fois plus grands que notre besoin.

Tcho !

Reply
1. Cyril
  
  April 20, 2014
  
  Hello,
  
  Ta dernière phrase dépends du contexte 😉
  
  Dans un contexte de virtualisation, on a tendance à toujours tailler les VM assez justes notamment au niveau disque car l’on sait qu’il est rarement utilisé en totalité, causant ainsi le gaspillage de ressources (je ne parlerai pas ici de la sur-allocation de stockage).
  
  Pour le /var et la gestion des logs, une bonne pratique voudrait que l’on mette les logs applicatives dans un système de fichiers distinct, le /var ne contenant ainsi que les logs systèmes qui ne sont pas sensés évoluer en taille au cours du temps (avec une bonne rotation de logs, évidemment).
  
  Je vais enlever la notion de disque de 1 Tio de l’article, puisque pour moi ce schéma de partitionnement s’applique quelque soit la taille du disque.
  
  Je vais aussi ajouter une section “Variantes” pour prendre en compte les différentes variantes apportées par les commentaires 😉
  
  Reply
Cascador

April 18, 2014

Hello,

Vu la taille de ton disque dur, quel est l’intérêt de viser des tailles aussi petites ?

La “logique” et les bonnes pratiques sont parfois très loin de la réalité. Il y a encore 10 ans, on conseillait systèmatiquement sur les serveurs de faire une partition OS et une partition Data (au cas où plantage, au cas où virus) et depuis je n’ai vu que des collègues (et moi) avoir des emmerdes à cause de partitions trop petites et personne à qui cette bonne pratique n’a jamais servi.

Je ne dis pas que ce n’est pas une bonne pratique mais confrontée à la réalité, il faut y réflechir à deux fois.

Je serai toi, je me méfierai de la taille de /var et de /tmp. Même avec cette merveille qu’est LVM.

Tcho !

Reply
1. Cyril
  
  April 18, 2014
  
  Bonsoir,
  
  Merci pour ce retour rapide 🙂
  
  Je pars du constat que aujourd’hui il est très facile d’agrandir un volume logique, alors qu’il est toujours aussi difficile de réduire la taille d’une partition ou d’un volume logique existant.
  Si je pars sur des partitions physiques, là oui je fais des partitions plus grandes car agrandir une partition coincée entre deux espaces n’est pas toujours évident et sans risque.
  
  Je trouve qu’aujourd’hui LVM apporte une telle souplesse dans la gestion des espaces que je peux me permettre de faire des volumes initialement réduits et les agrandir facilement ensuite, si le besoin s’en fait sentir.
  On a tous notre expérience, et la mienne m’a souvent conduit dans le mur à cause de partitions bien trop grandes au départ, ne me laissant plus d’espaces disponibles sur le disque pour des usages non prévus initialement 😉
  Un disque de 1 Tio peut sembler gros, mais ça va très vite aujourd’hui : au-delà des usages type bases de données, on a de plus en plus d’usages Big Data qui consomment énormément d’espaces.
  
  D’une manière générale, je suis partisan de l’écologie informatique : proportionner les ressources à l’usage actuel, surveiller et adapter si le besoin évolue.
  
  La taille du /tmp sera probablement amenée à évoluer, notamment si j’installe un serveur MySQL par exemple qui utilise ce répertoire pour ses calculs temporaires.
  
  Bonne soirée !
  
  Reply