Question Est-ce vraiment grave d'installer Linux sur une grosse partition?


Nous allons exécuter CentOS 7 sur notre nouveau serveur. Nous avons 6 disques de 300 Go dans raid6 interne au serveur. (Le stockage est en grande partie externe sous la forme d'un boîtier RAID de 40 To.) Le volume interne atteint environ 1,3 To s'il est formaté comme un seul volume. Notre administrateur système pense que c'est une très mauvaise idée d'installer le système d'exploitation sur une grosse partition de 1,3 To.

Je suis biologiste. Nous installons constamment de nouveaux logiciels à exécuter et à tester, dont la plupart se trouvent dans / usr / local. Cependant, comme nous avons environ 12 biologistes non avertis en informatique qui utilisent le système, nous recueillons également beaucoup de données cruelles dans / home. Notre dernier serveur avait une partition de 200 Go pour /, et après 2,5 ans, il était plein à 90%. Je ne veux pas que cela se reproduise, mais je ne veux pas non plus aller à l'encontre des conseils d'experts!

Comment pouvons-nous utiliser au mieux les 1,3 To disponibles pour nous assurer que cet espace est disponible quand et où il est nécessaire, sans toutefois créer un cauchemar de maintenance pour l'administrateur système?


91
2017-09-18 08:12


origine


Utilisez LVM et redimensionnez à volonté - thanasisk
@thanasisk La volonté de redimensionner à volonté est un mythe, car il n'y a pas de système de fichiers sous Linux pouvant être mis en ligne rétréci. ext2 avait un tel patch dans les temps anciens. - peterh
@ PeterHorvath - alors êtes-vous heureux si je remplace "redimensionner" par "développer"? - thanasisk
Il est un peu irréaliste de s'attendre à ce que tout ce que vous configurez maintenant soit optimal dans deux ans et demi! Et le fait que des utilisateurs non avertis sèment la pagaille est une raison de plus pour séparer le système d'exploitation des données. - JamesRyan
@PeterHorvath J'ai lu votre commentaire plusieurs fois pour le comprendre. Vous avez écrit que vous seriez heureux si un système de fichiers pouvant se développer existait et j'ai signalé un système de fichiers qui existe. C'est tout. - gparent


Réponses:


Les principales raisons (historiques) du partitionnement sont les suivantes:

  • à séparez le système d'exploitation de vos données utilisateur et d'application. Jusqu'à la sortie de RHEL 7, aucun logiciel n'était pris en charge. chemin de mise à niveau et une mise à niveau majeure nécessiterait une réinstallation, puis par exemple /home et d'autres données (d'application) sur des partitions séparées (ou des volumes LVM) vous permettent de conserver facilement les données utilisateur et les données d'application et d'effacer la ou les partitions du système d'exploitation.

  • Les utilisateurs ne peuvent pas se connecter correctement et votre système commence à échouer de manière intéressante lorsque vous manquez complètement d'espace disque. Plusieurs partitions vous permettent d’attribuer un espace disque dur réservé au système d’exploitation et de le séparer de la zone où les utilisateurs et / ou des applications spécifiques sont autorisés à écrire (par exemple, /home /tmp/ /var/tmp/ /var/spool/ /oradata/ etc.) , atténuation du risque opérationnel des utilisateurs et / ou des applications mal comportés.

  • Quota. Le quota de disque permet à l'administrateur d'empêcher un utilisateur individuel d'utiliser tout l'espace disponible, perturbant ainsi le service fourni à tous les autres utilisateurs du système. Un quota de disque individuel est attribué par système de fichiers. Par conséquent, une seule partition, et donc un seul système de fichiers, ne représente qu'une seule quotité de disque. Plusieurs partitions (LVM) désignent plusieurs systèmes de fichiers permettant une gestion plus détaillée des quotas. Selon votre scénario d'utilisation, vous pouvez par exemple autoriser chaque utilisateur 10 Go dans son répertoire de base, 2 To dans le répertoire / data de la matrice de stockage externe et configurer une grande zone de travail partagée où tout le monde peut importer des ensembles de données trop volumineux pour leur répertoire de base. et où la politique devient "full is full" mais quand cela se produit, rien ne casse non plus.

  • Fournissant chemins d'E / S dédiés. Vous pouvez avoir une combinaison de disques SSD et de disques en rotation et vous feriez bien de les traiter différemment. Le problème qui se pose dans un serveur polyvalent n’est pas vraiment un problème, mais il est assez courant dans les configurations de base de données d’affecter également certaines piles (disques) à des objectifs différents pour éviter les conflits d’IO, par exemple. disque séparé pour les journaux des transactions, disques séparés pour les données réelles de la base de données et disques séparés pour l'espace temporaire. .

  • Démarrage Vous pouvez avoir besoin d'un autre /boot cloison. Historiquement pour résoudre les problèmes d'initialisation au-delà de la limite du cylindre de 1024 dans le BIOS, il est plus souvent nécessaire de prendre en charge les volumes chiffrés, de prendre en charge certains contrôleurs RAID, les HBA qui ne prennent pas en charge le démarrage à partir d'un réseau SAN ou de systèmes de fichiers non pris en charge immédiatement par le programme d'installation, etc.

  • Réglage Vous aurez peut-être besoin de différentes options de réglage ou même de systèmes de fichiers complètement différents.

Si vous utilisez des partitions matérielles, vous devez plus ou moins bien le faire au moment de l'installation. Une partition volumineuse n'est donc pas la pire des solutions, mais elle comporte certaines des restrictions ci-dessus.

Je recommande généralement de partitionner votre volume principal en tant que seul grand volume physique Linux LVM et alors créer des volumes logiques qui répondent à vos besoins actuels et pour le reste de votre espace disque, laisser non assigné jusqu'au besoin.

Vous pouvez ensuite développer ces volumes et leurs systèmes de fichiers selon vos besoins (opération triviale pouvant être effectuée sur un système actif), ou en créer d'autres également.

La réduction des volumes LVM est triviale mais souvent rétrécir les systèmes de fichiers sur eux n'est pas très bien pris en charge et devrait probablement être évité.


103
2017-09-18 09:49



En ce qui concerne les performances, je pense qu’il est également intéressant de souligner que, dans le cas d’un système de fichiers, une réponse rapide est nécessaire et que 'df' renvoie des informations utiles beaucoup plus rapidement que 'du -s $ DIRNAME'. - symcbean
Je ne suis pas sûr d'être d'accord avec "jusqu’à ... RH7 ... aucun chemin de mise à niveau pris en charge". J'ai depuis longtemps fait des mises à niveau prises en charge, et définitivement mis à niveau les systèmes RH4-> 5. seulement À ma connaissance, RH5-> RH6 manquait d'un tel chemin - et j'ai l'impression que RH a été complètement fessé par ses utilisateurs pour ce manque. +1 pour le reste d'une excellente réponse, cependant. - MadHatter
À quoi faites-vous référence avec "Jusqu'à la publication de RHEL 7, aucun chemin de mise à niveau n'était pris en charge"? RHEL prendra-t-il en charge les mises à niveau entre les versions principales à partir de RHEL 7 et les versions ultérieures? - Markus Hallmann
Les mises à niveau ont fonctionné, mais selon chapeau rouge la politique générale est toujours la suivante: Red Hat ne prend pas en charge les mises à niveau sur place entre les versions principales de Red Hat Enterprise Linux.  et un peu de nuance plus bas Red Hat prend actuellement en charge les mises à niveau de Red Hat Enterprise Linux 6 à Red Hat Enterprise Linux 7 pour des cas d'utilisation spécifiques / ciblés uniquement. et voici le manuel vérifier - HBruijn


L’utilisation de plusieurs partitions a pour principe qu’une partition complète au mauvais endroit ne fera pas que le système tout entier fonctionne de manière inattendue.

Considérez un processus sur la machine remplissant un fichier journal assez rapidement au point qu’il n’ya plus d’espace libre. Sur un ordinateur à partition unique, cela pourrait alors, par exemple, empêcher le système d'écrire de nouvelles données dans / tmp. Si un autre processus souhaite écrire dans / tmp, il se terminera probablement avec une erreur, ce qui provoquera un comportement inattendu.

Cela peut être évité si vous utilisez différentes partitions pour les emplacements où les utilisateurs ou les processus écrivent normalement (/ home, / var, / tmp).

Je vous recommande de vérifier sur votre ancien serveur quels dossiers ont tendance à devenir gros. Vous pouvez le faire en ligne de commande avec

du -h -d 1 / 2> /dev/null

Vous verrez où la plupart des données sont accumulées et concevez votre prochain système de manière appropriée. Le "-d 1" limite la sortie à un seul niveau de profondeur de dossier, ce qui la rend plus lisible.


17
2017-09-18 08:38





Le problème principal avec une seule grande partition est que, si vous remplissez le système de fichiers, il est possible qu’aucune connexion ne soit plus possible.

L’utilisateur root a son dossier personnel (/root) en dehors de /home à cause de ce. Si le système de fichiers est saturé dans certaines circonstances, même root ne peut pas se connecter ni réparer le système.

C’est la raison pour laquelle vous créez normalement des points de montage distincts pour /var, /tmp et /home pouvoir vous connecter au moins en tant que root pour réparer le système lorsque l’une des autres partitions est pleine.


12
2017-09-18 08:23



sur certains systèmes de fichiers (ext3, par exemple), vous pouvez laisser un petit espace réservé à l'utilisateur root pour empêcher ce comportement. vous devriez utiliser des quotas pour empêcher cela, de même pour / tmp qui est souvent oublié. - Dennis Nolte
@ DennisNolte j'ai oublié /tmp. Merci, je vais ajouter ceci à ma réponse. - Uwe Plonus
@DennisNolte l'espace réservé aidera, mais je pense que la maintenance est plus difficile que d'utiliser différentes partitions, car vous devez configurer correctement les quotas. - Uwe Plonus
Je pense une raison plus importante pour /root être à l'extérieur /home est-ce que sur certaines installations /home sera sur un lecteur réseau. En cas de problème pour le monter sur le réseau, les fichiers root restent accessibles. (Cela peut être comparé à la façon dont il y a habituellement un éditeur de texte dans /bin, au cas où /usr je ne pense pas que ce soit un scénario plus courant dans la pratique, ces jours-ci, que /home remplir tout le chemin. - Eliah Kagan


IMHO, avoir une partition comme / est tout à fait raisonnable.

Mais vous pouvez utiliser lvm (gestionnaire de volumes logiques). Utilisez tous les disques en tant que groupe lvm, mais créez de petits disques logiques pour /, / home, / usr et ceux que votre administrateur système préfère. Mettez ensuite un peu de surveillance, vous le savez, quand votre système commence à se saturer et développez les disques dont vous avez besoin. lvresize et resize2fs sont des outils en ligne et vous pouvez effectuer une expansion sans redémarrer le serveur. Cependant, vous ne pouvez pas réduire les disques, vous devez donc commencer assez petit et augmenter là où vous en avez le plus besoin.


10
2017-09-18 08:22





La configuration de linux avec une grosse partition ne pose que peu de problèmes, mais elle offre de gros avantages.

Changer une disposition de partition est une chose un peu difficile et risquée, que vous ne pouvez souvent pas faire sans de longues périodes d'immobilisation.

Son seul avantage est que vous disposez d'une protection contre les problèmes de saturation du disque. Mais vous trouverez ces problèmes beaucoup souvent. Imaginez la situation si l’une de vos partitions est pleine et vous ne pouvez pas utiliser l'espace des autres partitions, même si elles sont presque vides!

Certains administrateurs système professionnels ont une opinion totalement différente à ce sujet. Ils disent qu'avoir plusieurs partitions peut rendre votre système plus fiable et vous devez savoir, avant votre partitionnement, quelle sera la taille de vos partitions. À mon avis, cela ne peut tout simplement pas être dit, c’est un inconvénient terrible pour la flexibilité du système, et leur véritable motivation est qu’ils sont simplement aimer jouer avec les cartes de partition.

Il y a un système simple nommé lvm, qui permet le déplacement / redimensionnement à la volée de "partitions" (dans sa terminologie, volumes). Mais sur un seul serveur de département local, IMHO, il n’est normalement pas nécessaire.


9
2017-09-18 08:43



Quel genre d'administrateur masochiste aime jouer avec les cartes de partition ??? La partie amusante est la construction du noyau, puis-je obtenir un Amen??? - bishop
Amen! Passons maintenant à l'argument selon lequel les administrateurs aiment jouer avec les partitions. J'aimerais simplement contrer cela avec le fait que Linux a probablement 100 types de systèmes de fichiers différents. Selon les modèles d'utilisation, choisir le bon système de fichiers pour une tâche donnée peut signifier la différence entre un système optimal et un système non fonctionnel. Et peut-être avez-vous simplement besoin de ce système de fichiers dans quelques dossiers. Là. - Lennart Rolland


Le partitionnement a deux raisons principales:

  1. Pour garder les données statiques à l'écart des données non statiques
  2. Pour garder les données publiques à l'écart des données privées

La première raison est la plus évidente: vous devez isoler les zones qui se remplissent de fichiers de celles qui ne le font pas, et vous souhaitez en particulier protéger / pour éviter un système qui ne démarre plus. Par exemple, le répertoire / var est généralement le lieu de stockage des fichiers journaux (var signifie "variable") et c’est pourquoi / var tend à être monté sur une partition distincte de /.

La deuxième raison ci-dessus est moins citée (la dernière fois que je l'ai entendue lors d'un cours sur Veritas Volume Manager il y a environ 15 ans) et concerne uniquement les systèmes où de nombreuses personnes se connectent et effectuent un travail.

Un partitionnement efficace est un art. C’est peut-être pour cette raison que certains administrateurs système le poussent un peu trop loin (IMO). Non seulement vous devez connaître le système de fichiers de l'intérieur, mais vous devez également connaître l'utilisation prévue. Personnellement, je pense que c’est une approche plutôt démodée qui devient de moins en moins pertinente par rapport à la façon dont les serveurs sont utilisés aujourd’hui.

En tant que développeur de logiciels, je suis particulièrement marre du département Opérations qui construit des machines virtuelles avec des schémas de partitionnement irréfléchis qui limitent sévèrement la taille de / tmp, / home, / var et /, quel que soit l'espace disque total disponible, ne montez pas des choix évidents comme / usr ou / opt séparément. Ces machines vont généralement mettre tout ce qui est laissé sur l’espace disque demandé dans un volume "/ stuff" que vous finirez inévitablement par installer et symloser tout, mais ce n’est pas une consolation. Le résultat final est que nous passons souvent plus de temps à mélanger des fichiers et à envoyer des courriels d'avertissement qu'à un travail réel.

Il n'y a rien de mauvais en soi d'avoir une seule partition. Quel que soit le système utilisé, surveillez de manière proactive l'utilisation de votre disque et appliquez des stratégies de gestion judicieuses (rotation du journal, quotas sur les répertoires personnels, par exemple). La seule véritable question est donc de savoir combien de systèmes de fichiers distincts vous préoccupez?

Je dirais donc: à moins que vous ne soyez sûr à 100% de votre capacité à partitionner le système efficacement pour votre cas d'utilisation particulier, ne partitionnez pas du tout..


3
2017-09-18 09:41



Exactement. Ok, peut-être que la séparation des données public-privé devrait être effectuée par les autorisations du système de fichiers et de vos services. - peterh


IMHO c'est à vous entièrement. Considérons d’abord quelques points, bien qu’ils soient tout à fait relatifs.

  • Ce système sera-t-il administré fréquemment?
  • Ce système sera-t-il utilisé par un ou plusieurs utilisateurs?
  • Ce système servira-t-il de bureau ou de serveur, ou les deux?

Puisqu'on peut considérer (presque) n'importe quel répertoire, un point de montage doit également considérer ce qui contient des données en croissance et ce qui contient des données en croissance.

Vous seriez surpris de voir combien un système Linux (peu de données en croissance) a besoin de fonctionner et combien de données sont consommées (généralement / var / opt / home / srv)

Cela dépend également de la manière dont vous définissez l'utilisation de ce système, qui décrit les exigences en matière de partitionnement. L'utilisation pour LVM inclus.

Un système de bureau typique nécessiterait environ 20 Go pour l’installation de charges logicielles, le reste de la tâche étant alors attribué à un serveur dédié / home. LVM entraîne des frais généraux mineurs sur votre système et, dans ce cas particulier, ne présente pas un tel avantage. Bien que les opinions puissent différer.

Sur un serveur, le logiciel installé est moins susceptible d'être aussi dynamique que pour un système de bureau. Il est également plus sage d'avoir des points de montage réels pour des composants de système de fichiers typiques tels que / tmp / var / usr / home / opt / srv. L'utilisation de LVM ici n'est pas obligatoire.

Cela permet une grande modularité de votre système, mais permet également de faire des choses stupides telles que le clonage de cette partition dans une VM, par exemple. Ou créer une sauvegarde au niveau du bloc en utilisant dd.

Sur la base de quelques expériences, voici quelques notes. Pensez également à disposer de plusieurs points de montage permettant un contrôle accru. Affecter un périphérique de disque rapide ou lent à un point de montage peut faire toute la différence et peut considérablement augmenter l'efficacité des coûts.

Mounpoint /

  • 1 Go (si vous utilisez des points de montage distincts pour / var / usr / opt / home / tmp)
  • +10 ou même +20 Go si vous utilisez comme système de bureau avec un / home séparé

si vous utilisez mountpoint / home

  • attribuer tout l'espace libre s'il est utilisé, / home ne

si vous utilisez mountpoint / opt

si vous utilisez mountpoint / usr

  • ceci est un problème complexe et dépend énormément de la base de logiciels installée

si vous utilisez mountpoint / var

  • ceci est un problème complexe et dépend énormément de la base de logiciels installée
  • Par exemple, les bases de données écrivent leurs données ici sur des systèmes basés sur Debian, si ce n’est tous les systèmes Linux.
  • avoir un / var / tmp séparé n'est pas déraisonnable

si vous utilisez mountpoint / tmp

  • considérer que tmpfs existe et alloué / tmp à la RAM
  • considérer que certaines applications peuvent écrire beaucoup de données ici

2
2017-09-18 14:18





Tout d'abord, je me demande pourquoi vous posez même cette question ici: vous êtes un biologiste qui discute avec un administrateur système apparemment compétent en ce qui concerne les subtilités du partitionnement de disque dur! (sans vouloir vous offenser, demandez-vous vraiment pourquoi vous ne faites pas confiance à votre administrateur système).

Donc, quelques observations:

  • 1,3 To n'est plus un gros disque. 2 To est une taille de disque SATA plus ou moins standard dans le monde des ordinateurs de bureau de nos jours.

  • il est peu probable qu'une installation de Linux Distro nécessite plus de 100 Go. Certes, la taille de / (racine) et (swap) devrait être facilement déterminée en tant que nombres supérieurs délimités en les surdimensionnant généreusement (pour racine) ou par les instructions de configuration du système (swap).

  • Le point de montage de / home doit pointer sur un élément du serveur RAID 40 To. Il n'est pas nécessaire que ces données, les répertoires personnels des utilisateurs, se trouvent n'importe où sur ce périphérique racine. Les placer sur le serveur RAID vous offre probablement une meilleure protection. De plus, il s’agit très probablement d’une installation NAS facilement extensible, alors que le peu de RAID intégré au serveur ne l’est probablement pas.

  • vous devriez probablement placer votre logiciel spécial dans une partition distincte (point de montage de / usr / local / bin, etc.) afin de pouvoir le conserver dans les mises à jour du système d'exploitation et les analyses de la partition racine. Sinon, vous serez peut-être obligé de réinstaller vos applications logicielles "spéciales" après une mise à niveau / une correction du système d'exploitation, etc.

  • Si vous souhaitez vous soucier de l'administration de votre système, je poserais une question différente: quel est le processus de récupération après sinistre une fois que le bâtiment prend feu et que les serveurs et les boîtiers RAID sont détruits? À moins que les données qui vous intéressent ne vous reviennent en tête, c’est une question que tout utilisateur devrait poser à son personnel informatique / administrateur système. La stratégie devrait inclure des questions telles que "comment allons-nous reproduire le matériel dont nous avons besoin" et "combien de temps cela prendra-t-il avant que nous puissions être à nouveau opérationnels". Une discussion sur la virtualisation de vos serveurs peut aider à résoudre les problèmes liés aux dépendances matérielles et à rétablir le fonctionnement sans avoir à reconfigurer votre système d’exploitation (car il pourrait être configuré pour fonctionner dans un environnement de périphérique "logiciel" qui ne change pas, même lorsque la le matériel sous-jacent est complètement différent)

  • de même, vous voudrez peut-être demander quelle est la stratégie pour protéger les données utilisateur contre les pertes de données d'erreur de programme et d'utilisateur. Enregistrer un fichier vide sur le très bon brouillon de votre document de recherche ou demander à un utilisateur de taper la mauvaise commande (rm -rf * par exemple) provoquera la perte de données aussi sûrement qu'un tremblement de terre, un incendie ou un autre dommage physique. Les solutions de récupération de fichier individuelle sont un peu différentes (ou peuvent l'être!) De celles qui sont les plus utiles pour la récupération après sinistre en gros.

  • -

2
2017-09-23 13:10





Cela permet de sauvegarder, de restaurer ou de réinstaller le système d'exploitation indépendamment des données de l'utilisateur. Cela vous donne la liberté, l'indépendance et la sécurité.

  1. Il est beaucoup plus facile de migrer vers une autre distribution Linux tout en préservant la majorité absolue des données utilisateur.

  2. Il est facile d’annuler les mises à jour erronées en appliquant la sauvegarde de la partition du système d’exploitation (le double démarrage est requis). Cette sauvegarde peut même être assez ancienne - vous pouvez l'appliquer et la mettre à jour ultérieurement vers la version sciemment stable.

  3. Il est simple de revenir à la version précédente du système d’exploitation si vous n’aimez pas la "mise à niveau majeure" récemment appliquée (le double démarrage est requis).

Pour tirer le meilleur parti de cette approche, vous devez également configurer le double démarrage (peut également être CentOS / CentOS), de manière à pouvoir écraser une partition du système d’exploitation lors de l’exécution du système d’exploitation. Et, bien sûr, vous devez sauvegarder la partition système au moins une fois quelques mois.


2
2017-09-18 11:13



Et pourquoi -1? Voyez-vous une attente sans fil pour la correction du bogue comme une approche plus professionnelle? A été corrigé en trois semaines, BTW. - h22
Je ne sais pas, mais compensé. Si vous en voyez de semblables, faites-le également. - peterh