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
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
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 /optDé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 /homeLes 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
).
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
)
Sinon on pourrait aussi réduire le /home.
3°) le /usrLà 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 localesDans 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
).
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à
)
N'hésitez pas si vous avez des questions sur certains choix.
Dernière modification par dcpc007 (02-05-2013 16:00:09)