À quel point est-ce vraiment mauvais d'installer Linux sur une grande partition?
Nous exécuterons CentOS 7 sur notre nouveau serveur. Nous avons 6 disques de 300 Go en raid6 internes au serveur. (Le stockage est en grande partie externe sous la forme d'une boîte de raid de 40 To.) Le volume interne atteint environ 1,3 To s'il est formaté en 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 grande partition de 1,3 To.
Je suis biologiste. Nous installons constamment de nouveaux logiciels à exécuter et à tester, dont la plupart atterrissent dans/usr/local. Cependant, comme nous avons environ 12 biologistes non avertis en informatique qui utilisent le système, nous collectons également beaucoup de débris à la maison/à domicile. Notre dernier serveur avait une partition de 200 Go pour /, et après 2,5 ans, elle était pleine à 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 l'espace est disponible quand et où il est nécessaire mais ne pas créer un cauchemar de maintenance pour l'administrateur système?
Les principales raisons (historiques) du partitionnement sont les suivantes:
à séparez le système d'exploitation de vos données d'utilisateur et d'application. Jusqu'à la sortie de RHEL 7, il n'y avait pas de prise en charge chemin de mise à nivea et une mise à niveau de la version majeure nécessiterait une réinstallation, puis avoir par exemple
/homeEt d'autres données (d'application) sur des partitions séparées (ou volumes LVM) vous permet 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 d'espace disque. Plusieurs partitions vous permettent d'attribuer un espace disque dur réservé pour le système d'exploitation et de le garder séparé de la zone où les utilisateurs et/ou les applications spécifiques sont autorisés à écrire (par exemple
/home /tmp/ /var/tmp/ /var/spool/ /oradata/Etc.), atténuation du risque opérationnel d'utilisateurs et/ou d'applications mal comportés.Quota. Le quota de disque permet à l'administrateur d'empêcher un utilisateur individuel d'utiliser tout l'espace disponible, interrompant ainsi le service à tous les autres utilisateurs du système. Un quota de disque individuel est attribué par système de fichiers, donc une seule partition et donc un seul système de fichiers signifie seulement 1 quota de disque. Les partitions multiples (LVM) signifient plusieurs systèmes de fichiers permettant une gestion plus granulaire des quotas. En fonction de votre scénario d'utilisation, vous pouvez par exemple autoriser chaque utilisateur à 10 Go dans son répertoire personnel, 2 To dans le répertoire/data sur la baie de stockage externe et à configurer une grande zone de travail partagée où n'importe qui peut vider des jeux de données trop volumineux pour leur répertoire personnel. et où la politique devient "pleine est pleine" mais quand cela se produit, rien ne se casse non plus.
Fournir dédié IO chemins. Vous pouvez avoir une combinaison de SSD et de disques tournants et feriez bien de les traiter différemment. Pas tellement un problème dans un serveur à usage général , mais assez courant dans les configurations de base de données consiste à affecter également certaines broches (disques) à différentes fins pour éviter les conflits IO, par exemple, un disque séparé pour les journaux de transactions, des disques séparés pour les données de base de données réelles et des disques séparés pour l'espace temporaire.
Boot Vous pourriez avoir besoin d'une partition
/bootSéparée. Historiquement, pour résoudre les problèmes de démarrage du BIOS au-delà de la limite de 1024 cylindres, de nos jours, il est plus souvent nécessaire de prendre en charge les volumes chiffrés, pour prendre en charge certains contrôleurs RAID, HBA qui ne prennent pas en charge le démarrage à partir de SAN ou file- systèmes non immédiatement pris en charge par l'installateur, etc.Réglage Vous pouvez avoir 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 dures, vous devez plus ou moins bien faire les choses au moment de l'installation, puis une seule grande partition n'est pas la pire, mais elle s'accompagne de certaines des restrictions ci-dessus.
En général, je recommande de partitionner votre volume principal en seul grand volume physique Linux LVM puis créer des volumes logiques qui correspondent à vos besoins actuels et pour le reste de votre espace disque, - laisser non attribué jusqu'à ce que nécessaire.
Vous pouvez ensuite étendre ces volumes et leurs systèmes de fichiers selon vos besoins (ce qui est une opération banale qui peut être effectuée sur un système en direct), ou en créer également d'autres.
La réduction des volumes LVM est triviale mais souvent la réduction des systèmes de fichiers sur ceux-ci n'est pas très bien supportée et devrait probablement être évitée.
Le concept de l'utilisation de plusieurs partitions est qu'une partition complète au mauvais endroit ne fera pas fonctionner l'ensemble du système de manière inattendue.
Considérez un processus sur la machine qui remplit un fichier journal assez rapidement au point qu'il n'y a plus d'espace libre disponible. Sur une machine à partition unique, cela pourrait alors, par exemple, empêcher le système d'écrire de nouvelles données dans/tmp. S'il existe un autre processus qui souhaiterait écrire dans/tmp, il se terminerait probablement par une erreur, provoquant 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 votre ancien serveur quels dossiers ont tendance à devenir gros. Vous pouvez le faire sur la ligne de commande avec
du -h -d 1 / 2> /dev/null
Vous verrez où le plus de données sont accumulées et concevrez 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 le remplissage du système de fichiers est possible qu'aucune connexion ne soit plus possible.
La racine utilisateur a son dossier de base (/root) en dehors de /home à cause de ce. Si le système de fichiers est rempli dans certaines circonstances, même root ne peut pas se connecter et ne peut pas réparer le système.
C'est la raison pour laquelle vous créez normalement des points de montage séparés pour /var, /tmp et /home pour pouvoir se connecter au moins en tant que root pour réparer le système lorsque l'une des autres partitions est remplie.
À mon humble avis, 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 tout ce que votre administrateur système préfère. Ensuite, mettez en place une surveillance, vous le savez, lorsque votre système commence à être plein et développez les disques dont vous avez besoin. lvresize et resize2fs sont des outils en ligne et vous pouvez faire de l'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 avez besoin.
Il y a un minimum de problèmes autour de la configuration à grande partition unique de Linux, mais elle a de grandes récompenses.
Changer une disposition de partition est une chose un peu difficile et risquée, ce que vous ne pouvez souvent pas faire sans de longs temps d'arrêt.
Son seul avantage est que vous disposez d'une protection contre les problèmes de saturation du disque. Mais vous trouverez souvent ces problèmes . Imaginez la situation, si l'une de vos partitions est pleine et vous ne pouvez pas utiliser l'espace sur les autres partitions, même si elles sont presque vides !
Certains administrateurs système professionnels ont une opinion totalement différente à ce sujet. Ils disent que le fait d'avoir plusieurs partitions peut rendre votre système plus fiable et vous devez savoir avant votre partitionnement la taille de vos partitions. À mon avis, cela ne peut tout simplement pas être dit, c'est un terrible inconvénient de la flexibilité du système, et leur véritable motivation est qu'ils aiment simplement jouer avec les cartes de partition .
Il existe un système simple nommé lvm , qui permet le déplacement/redimensionnement à la volée des "partitions" (dans sa terminologie, les volumes). Mais sur un seul serveur de département local, à mon humble avis, il n'est normalement pas nécessaire.
Il y a deux raisons principales au partitionnement:
- Pour éloigner les données statiques des données non statiques
- Pour éloigner les données publiques des données privées
La première raison est la plus évidente - vous devez isoler les zones qui se rempliront de fichiers de celles qui ne le font pas, et vous voulez particulièrement protéger /, pour éviter un système non amorçable. Par exemple, le répertoire/var est généralement l'endroit où les fichiers journaux seront stockés (var signifie "variable") et c'est pourquoi/var a tendance à être monté sur une partition distincte de /.
La deuxième raison ci-dessus est moins citée (je l'ai entendue pour la dernière fois lors d'un cours Veritas Volume Manager il y a environ 15 ans) et elle n'est vraiment pertinente que pour les systèmes où de nombreuses personnes se connectent et effectuent un travail.
Il y a quelque chose d'un art pour un partitionnement efficace, et c'est peut-être pourquoi il y a des administrateurs système qui vont un peu trop loin (OMI). Non seulement vous devez connaître le système de fichiers à l'envers, mais vous devez également connaître l'utilisation prévue. Personnellement, je pense que c'est une approche plutôt ancienne qui devient de moins en moins pertinente pour la façon dont les serveurs sont utilisés aujourd'hui.
En tant que développeur de logiciels, j'en ai particulièrement marre du département Ops qui crée des machines virtuelles avec des schémas de partitionnement irréfléchis qui restreignent considérablement la taille de/tmp,/home,/var et /, quel que soit l'espace disque total disponible, mais 'montez pas des choix évidents comme/usr ou/opt séparément. Ces machines placent généralement tout ce qui reste de l'espace disque que vous avez demandé dans un volume "/ stuff" dans lequel vous finissez inévitablement par tout installer et créer des liens symboliques, mais ce n'est guère une consolation. Le résultat net est que nous passons souvent plus de temps à déplacer les fichiers et à envoyer des e-mails d'avertissement qu'à faire un vrai travail.
Il n'y a rien de intrinsèquement "mauvais" à avoir une seule partition. Sur n'importe quel système, vous devez surveiller de manière proactive votre utilisation du disque et utiliser des stratégies de gestion judicieuses (par exemple, rotation des journaux, quotas sur les répertoires personnels), donc la seule vraie question est: de combien de systèmes de fichiers distincts voulez-vous vous soucier?
Je dirais donc: à moins que vous ne soyez sûr à 100% de votre capacité à partitionner efficacement le système pour votre cas d'utilisation particulier, ne partitionnez pas du tout.
Je dois d'abord me demander pourquoi vous posez même cette question ici, étant un biologiste qui se dispute avec un administrateur système apparemment compétent concernant les points les plus fins du partitionnement du disque dur! (aucune infraction, je me demande vraiment pourquoi vous ne faites pas confiance à votre administrateur système).
Donc, quelques observations:
1.3 TB n'est plus un gros disque. 2 TB est une taille de disque SATA plus ou moins standard dans le monde du bureau ces jours-ci).
il est peu probable qu'une installation de Linux Distro nécessite plus de 100 Go. Certes, la taille de/(root) et (swap) devrait être facilement déterminée en tant que nombres à limite supérieure en les sur-dimensionnant généreusement (pour root) ou par des directives de configuration du système (swap).
le point de montage pour/home doit pointer vers quelque chose hors de votre serveur RAID de 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 mettre sur le serveur RAID vous offre probablement une meilleure protection de toute façon. Et, c'est très probablement une installation NAS NAS facilement extensible, alors que le petit RAID intégré dans la boîte du serveur ne l'est probablement pas.
vous devriez probablement mettre votre logiciel spécial dans une partition séparée (point de montage pour/usr/local/bin, etc.) afin de pouvoir le conserver dans les mises à jour du système d'exploitation et les suppressions de partition racine. Sinon, vous êtes confronté à la possibilité que vous deviez réinstaller vos applications logicielles "spéciales" après une mise à niveau/correction/quoi que ce soit du système d'exploitation.
si vous voulez vous soucier de l'administration de votre système, je poserais une question différente: quel est le processus de reprise 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 dont vous vous souciez restent entièrement dans votre tête, c'est une question que chaque utilisateur devrait poser à ses informaticiens/administrateurs 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 de pouvoir être de nouveau opérationnel". Une discussion sur la virtualisation de vos serveurs pourrait aider à résoudre les problèmes liés aux dépendances matérielles et à remettre les choses en marche et à fonctionner sans qu'il soit nécessaire de reconfigurer votre système d'exploitation (car il pourrait être configuré pour s'exécuter dans un environnement de périphérique "logiciel" qui ne change pas, même lorsque le le matériel sous-jacent est complètement différent)
de même, vous voudrez peut-être vous demander quelle est la stratégie de protection des données utilisateur contre les pertes de données de programme et d'erreur 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) entraînera une perte de données tout aussi sûrement qu'un tremblement de terre ou un incendie ou d'autres dommages physiques. Les solutions pour la récupération de fichiers individuels sont un peu différentes (ou peuvent l'être!) De celles les plus utiles pour la récupération après sinistre en gros.
-
À mon humble avis, c'est à vous de décider. Considérons d'abord quelques choses, bien qu'elles soient entièrement relatives.
- 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 comme un point de montage, il faut é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 à quel point un système Linux (des données quelque peu croissantes) a besoin de fonctionner et combien est consommé par des données croissantes (généralement/var/opt/home/srv)
Cela dépend également de la façon dont vous définissez l'utilisation de ce système qui décrit les exigences de partitionnement. L'utilisation de LVM incluse.
Un système de bureau typique nécessiterait environ 20 Go pour installer des charges de logiciels, avoir tout le reste affecté à un dédié/à la maison fera alors l'affaire. LVM cause des frais généraux mineurs sur votre système et dans ce cas particulier n'est pas d'un grand avantage. Bien que les opinions puissent différer.
Sur un serveur, il est moins probable que les logiciels installés soient aussi dynamiques que pour un système de bureau. Il est également plus sage d'avoir des points de montage réels pour les composants typiques du système de fichiers tels que/tmp/var/usr/home/opt/srv L'utilisation de LVM ici est recommandée pour ne pas dire obligatoire.
Cela offre une grande modularité de votre système, il permet également de faire des choses idiotes telles que le clonage de cette partition dans un VM par exemple. Ou créer une sauvegarde de niveau bloc en utilisant dd.
Basé sur une certaine expérience, voici quelques notes. Pensez également à ce que plusieurs points de montage permettent un meilleur contrôle, l'attribution d'un périphérique de disque rapide ou lent à un point de montage peut faire toute la différence et augmenter considérablement l'efficience des coûts.
Mounpoint /
- 1 Go (si vous utilisez des points de montage séparés pour/var/usr/opt/home/tmp)
- +10 ou même +20 Go en cas d'utilisation en tant que 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 délicat et dépend énormément de la base logicielle installée
si vous utilisez mountpoint/var
- ceci est délicat 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, sinon tous 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érez que certaines applications peuvent écrire beaucoup de données ici
Cela permet de sauvegarder, restaurer ou réinstaller le système d'exploitation indépendamment des données utilisateur. Cela vous donne la liberté, l'indépendance et la sécurité.
Il est beaucoup plus facile de migrer vers une autre distribution Linux tout en préservant la majorité absolue des données utilisateur.
Il est facile de rétablir les mises à jour de bogues en appliquant la sauvegarde de la partition du système d'exploitation (un 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.
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 (un double démarrage est requis).
Pour le plus grand potentiel de cette approche, vous devez également configurer le double démarrage (peut également être CentOS/CentOS), afin que vous puissiez remplacer une partition du système d'exploitation tout en exécutant le système d'exploitation d'une autre. Et, vous devez sûrement sauvegarder la partition système au moins une fois tous les quelques mois.
Vous n'avez pas besoin d'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 de la source, en exécutant par exemple ./configure --prefix=/home/bin
Puisque vous êtes un 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 quand même le compiler à partir de la source.
Je suis un administrateur système pour un système HPC avec beaucoup de biologistes parmi nos utilisateurs, nous installons tous les logiciels qu'ils demandent sous un système/apps/file, donc je sais qu'il est possible de le faire pour la plupart des logiciels, cependant, parfois cela pourrait être très dur. Pour résoudre ce problème, mes collègues et moi avons écrit sur un outil appelé EasyBuild (gratuit et open source) Il peut compiler et installer des logiciels à partir des sources, et les installer dans un dossier différent, et créer automatiquement un module d'environnement fichier pour vous, donc vous pouvez réellement avoir 2 versions différentes du même logiciel installé, et ne pas avoir de conflits.
Jetez un oeil à notre liste de packages nous pouvons installer avec une seule commande, en tant que biologiste, vous pourriez en reconnaître beaucoup ;-)
Avertissement: je suis un développeur d'EasyBuild
Ma réponse courte est que même un bureau ne devrait jamais utiliser "une seule grande partition". J'ai récemment essayé cela contre mon meilleur jugement parce que 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 dû repartitionner mes disques car le programme d'installation ne va pas installer sur une distribution existante. Il peut et gardera votre/home intact s'il se trouve sur sa propre partition. Donc, j'ai fini par démarrer un live-cd gparted et réduire la partition, créer de nouvelles partitions pour/home et d'autres, déplacer mes données vers les nouvelles partitions, puis enfin démarrer dans le programme d'installation pour le nouveau système d'exploitation.
Idéalement, mettez/sur un SSD,/home sur un disque dur,/var sur un disque dur,/usr pourrait être sur un SSD ou HDD selon la fréquence à laquelle vous prévoyez de mettre à niveau./tmp sur un disque dur. Je crée généralement une autre partition pour les fichiers multimédias partagés comme les fichiers mp3 et les films avec des liens symboliques depuis ma/home. Notez que/sbin fait partie de root, et est/bin et/root. C'est la différence entre/bin et/usr/bin,/usr est un élément qui pourrait ne pas être disponible tant que tous vos lecteurs ne sont pas montés, donc la commande mount ne peut pas être dans/usr! Je garde généralement quelques partitions supplémentaires pour d'autres distributions Linux, comme celle-ci est sur mon disque dur au cas où je bousillerais quelque chose de vraiment mauvais, j'ai un autre système en direct prêt à travailler avec la récupération.
Pour un serveur sur lequel vous devrez peut-être déplacer des éléments, ajouter du stockage de manière dynamique et qui doit rester en permanence, utilisez LVM !!!
Je pense qu'en général, pour un utilisateur débutant/d'introduction * ix, avoir le moins de partitions peut fonctionner jusqu'à ce que l'on en sache davantage sur la nature du système. Cependant, vous ne pouvez pas simplement avoir une seule séparation et dans votre cas, monsieur, pour plusieurs raisons.
La première raison, plus pratique pour le public, est que la plupart des systèmes Linux nécessitent une partition de swap (généralement entre 1 et 2 * votre RAM) nécessitent également un système séparé, des partitions de démarrage ou à la maison et dans le cas de l'UEFI démarrant des systèmes linux une partition EFI (seulement 500 Mo).
La deuxième raison, spécifiquement applicable à votre situation, est que prendre 6 disques de 300 Go et en faire un raid 6 n'est pas, pour le moins, la mise en forme optimale. Bien que, nouvelle technologie, salue Raid 6 comme un système universellement meilleur, l'algorithme de répartition est plus nécessaire et l'espace requis pour stocker des informations (par rapport à RAID 5) est plus grand.
Sans oublier que RAID 6 nécessite un 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 d'arrêt, la reprise après sinistre ou les coûts d'assistance technique supplémentaires. Je comprends que certains, beaucoup peut-être, seront en désaccord avec moi et je tiens à réaffirmer que lorsque les disques deviendront plus grands au cours des deux prochaines années (car ils ont baissé de prix au cours des dernières années) RAID6, pour les baies plus grandes et les grandes sociétés de 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 RAID), la création d'une partition géante en miroir peut fonctionner pour vous, cependant, si vous souhaitez maximiser l'efficacité, utilisez des disques plus gros et plusieurs partitions. De cette façon, si vous avez une panne de double disque, vous n'aurez aucun temps d'arrêt sur certains points de montage ou peu en fonction du répertoire/dev + /.
Faites au moins que votre/sys (système, noyau, etc.) s'exécute séparément de sorte 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, un démarrage sur disque, etc. votre noyau et avoir une entreprise - un large accès à vos informations pendant le processus de d-recovery.
Votre entreprise peut ne pas se soucier de ces accents tant que le système fonctionne, mais j'essaie d'expliquer les raisons pour lesquelles les gens font des choses. J'aimerais également en savoir plus des autres, pour et contre cet argument, et soulever d'autres points. Si vous n'êtes pas d'accord, faites-moi savoir pourquoi. Poster-- Je vais PM vous aussi quelques liens.
Un amour pour notre communauté Linux Spencer Reiser
PS Surtout sur les serveurs ou systèmes réseau disponibles pour le grand public, même si via des informations d'identification, il serait vraiment préférable de séparer vos partitions. D'autres peuvent entrer plus ici, j'ai besoin de plus de café.