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'une boîte 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 l’installation du système d’exploitation sur une grosse partition de 1,3 To est une très mauvaise idée.

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?

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

• pour séparer le système d’exploitation de vos données d’utilisateur et d’application . Jusqu'à la sortie de RHEL 7, aucun chemin de mise à niveau n'était pris en charge et une mise à niveau majeure nécessitait une réinstallation, puis le fait de disposer par exemple de /homedonnées (d'application) sur des partitions distinctes (ou des volumes LVM) vous permet de conserver facilement les données utilisateur. et les données de l’application et effacez 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énuant ainsi les risques opérationnels posés par 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. En fonction de 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.

• Fournir des 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. Dans les configurations de base de données, le problème n’est pas tant de se poser sur un serveur généraliste, mais il est également courant d’attribuer certaines piles (disques) à des fins différentes pour éviter les conflits d’IO, par exemple un disque séparé pour les journaux de transaction, des disques séparés pour les données réelles de la base de données et des disques séparés. disques pour l'espace temporaire. .

• Boot Vous aurez peut-être besoin d'une /bootpartition séparée . Historiquement pour résoudre les problèmes d'initialisation au-delà de la limite du cylindre de 1024 dans le BIOS, il est aujourd'hui 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.

En règle générale, je vous recommande de partitionner votre volume principal sous forme d'un volume physique Linux LVM unique et volumineux , puis de créer des volumes logiques qui répondent à vos besoins actuels et pour le reste de votre espace disque, laissez-le non attribué jusqu'à ce que vous en ayez besoin .

Vous pouvez ensuite développer ces volumes et leurs systèmes de fichiers en fonction des 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 la réduction des systèmes de fichiers sur ces derniers n’est pas très bien prise en charge et devrait probablement être évitée.

Le concept d’utilisation de plusieurs partitions est qu’une partition complète au mauvais endroit ne fera pas que le système 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 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 des 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.

Le principal problème 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.

La racine de l'utilisateur a son dossier de départ ( /root) en dehors de /homepour cette raison. 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.

Ceci est la raison pour laquelle vous créez normalement des points de montage séparés pour /var, /tmpet /homed'être en mesure de se connecter au moins en tant que root pour réparer le système lorsque l' un des autres partitions est rempli.

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 raisonnablement petit et augmenter là où vous en sentez le besoin.

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

Changer une disposition de partition est une chose un peu dure 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 plus souvent. Imaginez la situation si l’une de vos partitions est pleine et que 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, on ne peut tout simplement pas en dire autant. La flexibilité du système est un inconvénient terrible. Leur véritable motivation est qu’ils aiment simplement jouer avec les cartes de partition .

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

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"), raison pour laquelle / 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 la raison pour laquelle 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 symblier dans 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’ya 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 des journaux, quotas sur les répertoires personnels, par exemple). La seule vraie question est donc de savoir combien de systèmes de fichiers distincts vous préoccupez?

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

IMHO c'est à vous entièrement. Considérons d’abord quelques points, bien que cela soit tout à fait relatif.

• 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 façon dont vous définissez l'utilisation pour 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 ordinateur 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 de niveau 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 logicielle installée

si vous utilisez mountpoint / var

• ceci est un problème complexe et dépend énormément de la base logicielle 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

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 fassent entièrement penser, 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 peut être configuré pour fonctionner dans un environnement de périphérique "logiciel" qui ne change pas,

• de même, vous voudrez peut-être demander quelle est la stratégie de protection des 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 saisir la mauvaise commande (par exemple, rm -rf *) entraînera 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.

-

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 à partir d’une autre. Et, sûrement, vous devez sauvegarder la partition système au moins une fois quelques mois.

Ma réponse courte est que même un poste de travail ne devrait jamais utiliser "une grande partition". Récemment, j’ai essayé cela contre mon bon jugement car c’était «juste un ordinateur portable» et l’installateur automatique utilisait une seule partition, et j’ai juste cliqué sur le bouton.

Lorsque je suis allé installer une distribution différente, j'ai ensuite dû repartitionner mes disques car l'installateur ne va pas installer sur une distribution existante. Il peut et gardera votre / home intact si c'est sur sa propre partition. Donc, j'ai fini par démarrer un live-cd gparted et réduire la partition, en créant de nouvelles partitions pour / home et autres, en déplaçant mes données vers les nouvelles partitions, puis en démarrant dans le programme d'installation pour le nouveau système d'exploitation.

Idéalement, mettez / sur un disque SSD, / home sur un disque dur, / var sur un disque dur, / usr pourrait se trouver sur un disque SSD ou un disque dur en fonction de la fréquence à laquelle vous prévoyez de procéder à la mise à niveau. / tmp sur un disque dur. Je crée généralement une autre partition pour les fichiers multimédias partagés tels que les MP3 et les films contenant des liens symboliques depuis mon dossier / home. Notez que / sbin fait partie de root et est / bin et / root. C’est la différence entre / bin et / usr / bin, c’est-à-dire que / usr peut ne pas être disponible tant que tous vos lecteurs ne sont pas montés. La commande mount ne peut donc pas figurer dans / usr! Je garde habituellement quelques partitions supplémentaires pour d'autres distributions Linux, comme celle-ci qui se trouve sur mon disque dur, au cas où je bousillerais vraiment quelque chose, j'ai un autre système en direct prêt à effectuer le travail de récupération.

Pour un serveur où vous devrez peut-être déplacer des éléments, ajouter du stockage de manière dynamique, et qui doit rester actif tout le temps, utilisez LVM!

Vous n'avez pas à installer de logiciel dans / usr / local, vous pouvez installer tous les logiciels dans un préfixe différent, qui peut-être dans / home. La plupart des logiciels peuvent le faire lorsque vous le compilez à partir du source, en exécutant par exemple ./configure --prefix=/home/bin

Étant donné que vous êtes biologiste, vous pourriez être intéressé par de nombreux logiciels qui ne sont pas correctement emballés dans un RPM ou un deb et vous devrez le compiler à partir de la source de toute façon.

Je suis un administrateur système pour un système HPC avec de nombreux biologistes parmi nos utilisateurs. Nous installons tous les logiciels qu’ils demandent dans un système / apps / files, je sais donc qu’il est possible de le faire pour la plupart des logiciels. être très dur. Pour résoudre ce problème, mes collègues et moi-même avons écrit sur un outil appelé EasyBuild (Free et open source). Il peut compiler et installer des logiciels à partir des sources, les installer dans un autre dossier et créer automatiquement un fichier de module d'environnement , de sorte vous pouvez réellement avoir 2 versions différentes du même logiciel installé et ne pas avoir de conflits.

Consultez notre liste de paquets que nous pouvons installer avec une seule commande. En tant que biologiste, vous pourriez en reconnaître beaucoup ;-)

Disclaimer: Je suis un développeur d'EasyBuild

Je pense qu'en général, pour un utilisateur débutant / introducteur * ix, le fait d'avoir le moins de partitions possible peut fonctionner jusqu'à ce que vous en appreniez davantage sur la nature du système. Cependant, vous ne pouvez pas simplement avoir une partition et dans votre cas, monsieur, pour plusieurs raisons.

La première raison, généralement plus pratique, est que la plupart des systèmes Linux requièrent une partition swap (généralement entre 1 et 2 * votre RAM) et requièrent également un système séparé, des partitions de démarrage ou des partitions personnelles. Dans le cas de systèmes Linux sous UEFI, une partition EFI (seulement 500 Mo).

La deuxième raison, spécifiquement applicable à votre situation, est que prendre 6 disques de 300 Go et de les transformer en un raid 6 n’est pas, pour le moins, la solution optimale. Bien que cette nouvelle technologie reconnaisse le Raid 6 comme étant un système universellement meilleur, l’algorithme de segmentation est davantage requis et l’espace requis pour stocker les informations (par rapport au RAID 5) est plus volumineux.

Sans oublier que le RAID 6 nécessite du matériel supplémentaire. Ce qui devrait être utilisé, à mon humble avis, dans votre cas, pour acheter des disques plus gros afin d’éviter les pannes de disque, les temps morts, la récupération en cas de sinistre ou les coûts d’aide technique supplémentaires. Je comprends que certains, peut-être d’autres, seront en désaccord avec moi et je tiens à réaffirmer que lorsque les disques grossiront au cours des deux prochaines années (car leur prix a baissé au cours des dernières années), RAID6, pour les baies plus grandes les grandes sociétés à revenu seront un choix évident. Cependant, dans ce cas, je ne suggère pas l'utilisation de RAID 6.

Pour le deuxième problème (non basé sur le RAID), la création d’une partition géante lorsqu’une copie en miroir peut vous convenir, cependant, si vous souhaitez optimiser l’efficacité, utilisez des disques plus grands et plusieurs partitions. De cette façon, si vous rencontrez une erreur de double disque, vous n'aurez aucun temps d'arrêt sur certains points de montage, selon le répertoire / dev + / dir.

Assurez-vous au moins que votre / sys (système, noyau, etc.) fonctionne séparément afin que, si pour une raison quelconque votre noyau décide de ne pas démarrer, vous pouvez simplement utiliser un noyau de récupération, un démarrage à distance ou PXE, votre disque, etc. large accès à vos informations pendant le processus de d-récupération.

Votre entreprise ne s’intéressera peut-être pas à ces accents tant que le système fonctionnera, mais j’essaie d’expliquer les raisons pour lesquelles les gens font des choses. J'aimerais aussi en savoir plus des autres, pour et contre cet argument et pour soulever d'autres points. Si vous n'êtes pas d'accord, dites-moi pourquoi. Poster-- Je vais vous PM aussi quelques liens.

Un amour pour notre communauté Linux Spencer Reiser

PS Surtout sur les serveurs de réseau ou les systèmes disponibles au grand public, même si via des identifiants, il serait vraiment préférable de séparer vos partitions. D'autres peuvent entrer plus ici, j'ai besoin de plus de café.