logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 02-05-2013 15:43:35

dcpc007
Membre
Inscription : 02-05-2013

Schéma de partitionnement pour serveur

Bonjour,

J'essaye de normaliser un peu nos futures installations de serveurs.

Notamment niveau schéma de partitionnement, j'en ai marre de retrouver les vieux serveurs avec /boot, / et swap uniquement ...
Dans l'idéal pour faciliter la gestion j'aimerai avoir un socle commun pour tous les serveurs.

J'avoue que pour notre environnement ça va être très compliqué car :
- différents "matériels" : récup de "vieux" serveurs, nouveaux serveurs tout neufs et bientôt virtualisation de masse => configurations très différentes (espace disque surtout)
- différents buts : serveurs d'infra (NIS, DHCP, Supervision,...), serveurs applis légers et serveurs applis plus lourd (des wiki d'entreprise, GED, applis LAMP, applis tomcat,...)

Je pars sur une base de Debian Wheezy, avec un volume de disque de 72 Go pour base.
1°) ça correspond aux vieux serveurs, et raisonnable pour la virtualisation
2°) le matos récent aura plus, et qui peut le moins, peut le plus smile

Un principe de base va être de partitionner à la mode "serveur" avec du LVM et non en poste de travail de grouillot ! Ceci pour des tas de raisons plutôt bien expliquées un peu partout.
Je sais qu'un partitionnement "fort" entraîne une perte d'espace disque (car il faut une marge pour chaque partition), mais ça limite les problèmes système.
Reste le détail à déterminer, et là il n'y a pas de règle fixe.

Voici donc là où j'en suis de mes réflexions et je suis preneur des différents avis :

Partitionnement de base :

* /boot en primaire de 250Mo (primaire car des anciens restes de prérequis pour les boot non compatible si /boot en lvm smile et ça coûte pas cher comme contrainte).
* LVM pour le reste du disque :
- /         :  1 Go (il ne devrait pas y avoir besoin de beaucoup plus normalement)
- /var    : 15 Go (ça devrait suffire pour la plupart des besoins de base)
- /tmp   :   1 Go (pas de gros besoins normalement)
- /home : 20 Go (Bon là j'hésite, car utilisateurs avec /home sur le réseau via NIS + automount => voir détails ci -dessous)
- /usr    :   9 Go (J'hésite aussi à séparer le /usr > voir détails)
- swap   : 7.5 Go (8Go ?  je crois que c'est ce que l’installeur Debian m'a mis pour un test sur un serveur avec 8Go de RAM .... => à revoir peut-être plutôt 4 Go)

- espace non affecté : ~18 Go (pour ajout partitions optionnelles ou extend lvm en cas de besoin).
- /opt    : 10 Go? (optionnel : sert pour serveurs avec applis hors packaging Debian)

Discussions en cours :

1°) le /opt
Déjà choix d'utilisation du /opt au lieu du /usr/local pour les applis installées manuellement (les 2 seraient valables mais au moins c'est visible et non "planqué" au milieu du /usr, et faut bien trancher).
Par contre optionnel car je ne vois pas l'intérêt quand même d'avoir un /opt de 10Go sur une machine faisant serveur NIS par exemple.
Pour la taille ça dépendra des besoins en applis non packagées (dur à dire actuellement)

2°) le /home
Les comptes utilisateurs ont actuellement déjà un home sur le réseau (NIS  + automount sur un SAN) => pas besoin d'espace local pour eux.

Par contre je prévois d'imposer des comptes applicatifs pour les applis locales (au lieu de tout faire en root comme actuellement smile ).
Mais je ne sais pas encore quel type de données mettre dedans (quels sont les cas recommandés ?), à part les paramètres du compte (bashrc,...), soit quasi rien.
idées : appli web --> rerooter le home des données ici (genre /var/ww/html/monAppli -> /home/monAppli/html/*, voir aussi la reco du /srv pour ce cas)
appli bdd : déplacer la base /var/lib/mysql/<monAppli> vers le home aussi ?, mettre les logs applis dedans ? mettre les backup locaux comme dump sql ?

Je vais aussi peut-être créer un compte d'exploit générique, qui pourrait servir pour les install et débug => avec un peu de donnée locale du coup ? (ou bien re un /home réseau NIS smile )

Sinon on pourrait aussi réduire le /home.

3°) le /usr
Là plus dur. Je n'utiliserai pas la reco d'avoir un /usr partagé sur le réseau. Je ne forcerai pas le /usr en lecture seule même pour root (hors temporaire pour install). => à priori séparer le /usr est juste une perte de place et une prise de tête pour évaluer le sizing.

Mais ... du coup ça fait un gros volume à remettre dans /, et en cas de pépin, si ça tombe dans le / c'est dur a débugguer. => il y aurait cet intérêt. Plus les outils d'analyse de FS sont plus efficaces sur plusieurs petits FS que sur un gros.

Debian semble recommander 5-6Go je crois, j'ai mis 9 pour avoir une marge (cas de lib32, ou applis plus volumineuses).

4°) l'espace non attribué
J'ai déjà vu cette technique mise en place qui profite de la souplesse apportée à LVM.
Cela évite surtout le jour où on a besoin de faire un lvreduce sur une partition avec de l'espace libre, qui peut poser quelques soucis des fois (moins avec les OS modernes je pense qui font "tous" du reduce à chaud même je crois).
En gros on garde une marge, et en cas de besoin spécifique on alloue une partie de ce pool à un lv.

Il faut toutefois faire attention je crois, un LV qui a été étendu se retrouve à 2 emplacements sur le disque du coup et ça doit impacter les perfs (pour un même volume, il faut chercher à 2 endroits éloignés du disque) surtout si on le fait plusieurs fois.

5°) espace pour svg locales
Dans tout ça je n'ai pas encore défini d'emplacement "fixe" pour les sauvegardes locales, comme les dump de bdd qui ne se sauvegardent pas "à chaud" (comme personne ne fait plus hein smile ).
Je vois plus un FS /backup ou bien utiliser les /home locaux pour ça (quitte même à créer un user backup sur les serveurs avec espace local et crontab spécifique ?)

Une autre note : il faut que je retrouve l'info, mais on peut aussi réduire/désactiver le % d'espace réservé au système sur chaque FS (5% par défaut), surtout sur les gros volumes.

Voilà yikes)
N'hésitez pas si vous avez des questions sur certains choix.

Dernière modification par dcpc007 (02-05-2013 16:00:09)

Hors ligne

#2 02-05-2013 16:09:06

dcpc007
Membre
Inscription : 02-05-2013

Re : Schéma de partitionnement pour serveur

Autre discussion pour la réservation des 5%.
C'est vrai que perdre 5% dur un gros volume c'est un peu bête.
D'un autre côté, même si sous linux la fragmentation n'est pas aussi sensible que sous Windows, elle existe quand même.
Donc remplir un FS à 95% n'est pas recommandé non plus. Alors faire sauter la réservation pour pouvoir remplir le disque à 98% .... est-ce un bien au final ?

Hors ligne

#3 07-05-2013 14:32:05

dcpc007
Membre
Inscription : 02-05-2013

Re : Schéma de partitionnement pour serveur

En relisant ce post et quelques autres doc, notammentsur le site debian, je propose une variante au vu des contraintes (le /home à priori peu utilisé) :

Partitionnement de base :
* /boot en primaire de 250Mo (primaire car des anciens restes de prérequis pour les boot non compatible si /boot en lvm  et ça coûte pas cher comme contrainte).
* LVM pour le reste du disque :
- /         :  3 Go (il ne devrait pas y avoir besoin de beaucoup plus normalement)
- /var    : 25 Go (volume agrandi pour serveur ayant des applis style mysql)
- /tmp   :   3 Go (pas de gros besoins normalement, mais un peu agrandi)
- /home : 10 Go (là je garde quand même 10Go au cas où pour un besoin local de déposer des grosses sources appli, image DVD,...)
- /usr    : 10 Go (J'hésite aussi à séparer le /usr > voir détails)
- swap   :  4 Go (devrait suffire pour des serveurs même avec 8 ou 16Go de RAM, et si c'est une VM de 2Go de RAM c'est juste un peu de disque perdu)
- espace non affecté : ~17 Go (pour ajout partitions optionnelles ou extend lvm en cas de besoin).
- /opt    : 10 Go? (optionnel : sert pour serveurs avec applis hors packaging Debian)
- /data, /opt/data ou /srv : (optionnel aussi : données applicatives spécifiques)

Dernière modification par dcpc007 (07-05-2013 14:59:18)

Hors ligne

#4 07-05-2013 15:15:01

Anonyme
Invité

Re : Schéma de partitionnement pour serveur

Personnellement, je dis vive la méthode :

poste de travail de grouillot


Ta simplification ne me semble pas évidente à gérer pour couvrir tous les cas à moins de prendre des marges énormes.

#5 07-05-2013 15:46:32

dcpc007
Membre
Inscription : 02-05-2013

Re : Schéma de partitionnement pour serveur

oui je parle de ça car même pour un utilisateur "de base" il est recommandé partout de faire à minima :
- /
- swap
- /home

ici les serveur de prod sont juste en / et swap !! avec déjà 2 crash serveur cause FS pleins avec logs mal (pas) gérés + un OS hs suite a petite panne disque ... oui ça me gonfle un peu de voir ça, c'est pas du travail propre (et j'ai voulu rester poli smile )


Et bien sûr qu'il n'y aura pas de config qui répondra à tous les cas possibles. Mais il faut bien commencer par définir une base assez générique, et ensuite j'ai déjà prévu des parties optionnelles pour des cas spécifiques et une partie variable dans le LVM.
Reste le swap, c'est difficile de définir un standard entre un petit serveur d'admin (genre NIS) virtualisé que tu va mettre à 1Go pour économiser, et unserveur BDD appli avec 64Go RAM.

Mais pareil, il faut bien définir un standard qui essaye de répondre à 80% des cas mini (la regle du 80/20 ou 90/10), déjà beaucoup mieux je trouve que gérer chaque serveur au cas par cas et au final n'en avoir aucun de similaire ! Comme c'est le cas actuellement chez nous, avec 15 serveurs applis pour 11 versions d'OS sur 2 distrib, et je crois pas avoir 2 serveurs configurés pareils, hormis ceux qu'on vient de cloner en virtuel pour faire des machines de test/dév)

Dernière modification par dcpc007 (07-05-2013 15:53:00)

Hors ligne

#6 13-06-2013 14:57:51

dcpc007
Membre
Inscription : 02-05-2013

Re : Schéma de partitionnement pour serveur

Tiens je me réponds à moi-même, car encore un 3ème serveur perdu grâce à un partitionnement de / + swap uniquement. Secteurs défectueux, donc forcément sur le /.
le fsck permet qd même de booter, mais impossible d'accéder à des parties complètes du disque, dont le /proc ... pas de raid, pas de svg complète, machien trop vieille pour avoir du spare en état, et hop à la benne !

Hors ligne

Pied de page des forums