Avec la virtualisation, est-il toujours judicieux d'utiliser plusieurs points de montage?

15

En 2013, est-il judicieux d'avoir encore plusieurs points de montage sur une nouvelle image Linux, ou allouer tout l'espace à / est-il plus logique?

Je préfère éviter le redémarrage nécessaire pour augmenter la taille d'un point de montage. Je préfère également surveiller l'espace d'une seule monture. Je préfère savoir que le serveur entier utilise plus de 70% d'espace disque, par rapport à des points de montage individuels.

Jeremy Mullin
la source
Pourquoi devez-vous redémarrer pour augmenter la taille d'un point de montage? Je pense que tous les systèmes de fichiers courants pris en charge en ligne se développent à ce stade.
derobert

Réponses:

17

Bien sûr, c'est toujours utile. Vous ne voulez pas qu'un processus incontrôlable remplisse un journal et provoque / pour saturer le disque. De plus, si vous utilisez quelque chose comme LVM, vous pouvez faire une expansion en ligne des volumes.

Avec de nombreuses machines virtuelles, vous voudrez quand même séparer les E / S. Vous allez probablement vouloir vos bases de données sur des broches distinctes et la seule façon d'y parvenir est d'avoir un point de montage séparé pour l'emplacement de votre base de données. Mis à part les bases de données, il offre une flexibilité plus granulaire si vous devenez trop grand pour votre conception d'origine.

Donc, en bref, oui, il y a encore de bonnes raisons de le faire en 2013.

MDMarra
la source
La machine ne plantera-t-elle toujours pas même si / var (ou / tmp) est plein quand même?
onionjake
2
@onionjake Non, pas nécessairement. Mais ils planteront s'ils se /remplissent.
ewwhite
Merci pour la note sur les journaux hors de contrôle. Ces machines virtuelles particulières utilisent un SAN, donc je pense que les E / S sont déjà distribuées et ne me préoccupent pas dans cette situation particulière.
Jeremy Mullin
En outre, si vous souhaitez qu'une seule machine virtuelle couvre plusieurs pools VMFS dans ESXi, vous devrez utiliser plusieurs disques virtuels (qui apparaissent comme des disques physiques pour la machine virtuelle). Vous pouvez toujours les combiner en un seul point de montage avec LVM si vous le voulez vraiment, mais c'est une mauvaise pratique, à mon avis.
Paul Gear
5

De nos jours, je n'utiliserais pas trop de supports séparés, mais probablement quelques-uns clés seraient utiles dans l'administration du système.

Juste 2 ou 3, esp. avec une taille variable. Cela dépend de ce que vous utilisez. Je dirais juste / (relativement stable) et / var (changeant). Selon le système d'exploitation et la géométrie du disque, / boot peut également être nécessaire. / tmp est probablement un montage tmpfs configuré par le programme d'installation.

Les volumes changeants (/ var principalement, mais pourraient être seulement / var / log et / var / lib / mysql etc.) sont généralement ce dont vous devez vous soucier et planifier l'expansion. Donc, si possible, utilisez lvm, etc. pour faciliter le redimensionnement.

johnshen64
la source
1
Personnellement, j'utilise LVM et le démarrage doit être sur sa propre partition, ne faisant pas partie d'un groupe de volumes, je crois (si vous utilisez grub legacy).
4

Oui, j'utilise toujours plusieurs partitions sur des machines virtuelles et des points de montage pour les besoins de surveillance, de sécurité et de maintenance.

Je ne suis pas un fan des machines virtuelles à point de montage unique ou limité (sauf s'il s'agit de machines jetables). Je traite les machines virtuelles de la même manière que je traite les serveurs physiques. L'alignement des partitions avec certains des standards de la hiérarchie du système de fichiers Linux est toujours logique en termes de séparation logique des exécutables, des partitions de données, du stockage temporaire et des journaux. Cela facilite également la réparation du système. Cela est particulièrement vrai avec les machines virtuelles et les serveurs dérivés d'un modèle.

(BTW, je n'aime pas non plus LVM sur les machines virtuelles ... Planifiez mieux !! )

Dans mes systèmes, j'essaie de faire ce qui suit:

  • / est généralement petit et ne grandit pas beaucoup.
  • /boot est de taille prévisible et la croissance est contrôlée par la fréquence des mises à jour du noyau.
  • /tmpdépend de l'application et de l'environnement, mais peut être dimensionné de manière appropriée. Le surveiller séparément permet de mesurer les comportements anormaux et protège le reste du système.
  • /usr Devrait être prévisible, contenant des exécutables, etc.
  • /varaugmente, mais la quantité de données peut être réduite. Agréable de pouvoir le mesurer séparément.
  • Et une partition de croissance. Dans ce cas, il est /data, mais si cela était un système de base de données, il peut être /var/lib/mysqlou /var/lib/pgsql... Notez qu'il est un dispositif de bloc différent, /dev/sdb. Il s'agit simplement d'un autre VMDK sur cette machine virtuelle, il peut donc être redimensionné indépendamment du VMDK contenant les vraies partitions du système d'exploitation.

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              12G  2.5G  8.8G  23% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             291M  131M  145M  48% /boot
/dev/sda7             2.0G   68M  1.9G   4% /tmp
/dev/sda3             9.9G  3.5G  5.9G  38% /usr
/dev/sda6             6.0G  892M  4.8G  16% /var
/dev/sdb1             360G  271G   90G  76% /data

La séparation de certaines de ces partitions facilite beaucoup l'identification des tendances et la détection des comportements anormaux; par exemple /var, un cœur de 4 Go se vide , un processus qui épuise /tmp,

Ordinaire entrez la description de l'image ici

Anormal. L'augmentation soudaine /varn'aurait pas été facile à détecter si une grande /partition avait été utilisée. entrez la description de l'image ici


Récemment, j'ai dû appliquer un cocktail de paramètres et d'attributs de montage de système de fichiers (nodev, nosuid, noexec, noatime, nobarrier) pour un modèle de VM renforcé de sécurité. Le partitionnement était une exigence absolue pour cela car certaines partitions nécessitaient des paramètres spécifiques qui ne pouvaient pas être appliqués globalement. Un autre point de données.

ewwhite
la source
2

Bien sûr, les multiples points de montage ont toujours leurs avantages, un serveur virtualisé ou non.

Mais avec la virtualisation, vous utilisez probablement aussi des modèles de machines virtuelles, non? Et votre système de surveillance, comme Nagios (avec NConf?) Prend également en charge les modèles? Si c'est le cas, vous ne devez passer par ce combat de point de montage mental qu'une seule fois.

Retour au sujet.

Je l' habitude de partager mes systèmes ainsi: /, /home, /usr, /var, /tmp(et peut - être un autre point de montage pour les données), mais c'était surpuissant et un tracas. De nos jours, une simple image du système d'exploitation avec seulement /, peut-être avec une image distincte /varest un chemin à parcourir pour moi; puis, si un serveur virtuel a besoin de plus de stockage pour les données, je lui donne une autre image disque et je la monte là où c'est nécessaire.

Janne Pikkarainen
la source
Comment détectez-vous les problèmes dans, disons, /optou /tmpsous une configuration à partition unique?
ewwhite
Si un serveur commence à consommer rapidement son espace disque, quelque chose comme cela du -m --max-depth=4 / | sort -nr | head -n 30 | lessest étonnamment efficace. Et dans un cadre contrôlé. environnement surveillé, combien de places potentielles avez-vous pour ce genre de choses, de toute façon? /var/log, /tmp, /opt/*/log, Peut - être autre chose? Pas trop difficile.
Janne Pikkarainen
1

Pour les serveurs de fichiers, j'ai également tendance à monter le /homevolume sur sa propre partition / disque et à utiliser l' noexecoption lors du montage. Paranoïa, mais empêche les utilisateurs d'exécuter des fichiers à partir de leurs dossiers personnels.

De plus, j'ai tendance à mettre le /bootvolume sur un miroir RAID 1 sur tous les disques, mais encore une fois, la vieille pratique que je poursuis ne voit pas encore d'inconvénient

Canadian Luke
la source
1
La question concernait les serveurs virtuels, donc le bit sur / boot sur RAID 1 ne s'applique pas. Mais c'est définitivement une bonne idée sur les serveurs physiques.
Paul Gear