Partitionnement du serveur Unix et disposition du système de fichiers


29

Il y a beaucoup d'informations contradictoires sur le partitionnement du serveur Unix sur Internet, j'ai donc besoin de quelques conseils sur la façon de procéder.

Jusqu'à présent, sur les serveurs I dans notre environnement de test, je ne me souciais pas vraiment du partitionnement et j'ai configuré un seul monolithique /plus une partition de swap. Ce schéma de partitionnement ne semble pas être une bonne idée pour nos serveurs de production. J'ai trouvé un bon point de départ ici , mais il semble très vague sur les détails.


Fondamentalement, j'ai un serveur sur lequel je vais exécuter une pile LAMP de base (Apache, PHP et MySQL). Il devra gérer les téléchargements de fichiers (jusqu'à 2 Go). Le système dispose d'une matrice RAID 1 de 2 To.

Je prévois de définir:

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

Est-ce que cela semble sain d'esprit, ou suis-je trop compliqué?


1
Quel est votre objectif final? Qu'essayez-vous exactement d'accomplir?
Scott Pack

9
Quelle que soit votre décision, je vous suggère d'utiliser LVM pour définir vos partitions, puis d'allouer de l'espace de manière conservatrice, en laissant de l'espace disque non alloué. Ensuite, lorsque vous décidez que vous avez besoin de plus d'espace quelque part, vous pouvez simplement étendre le LV et le système de fichiers.
ktower

Réponses:


33

Une chose à garder à l'esprit lors de la disposition de vos partitions sont les modes de défaillance. Cette question est généralement de la forme: "Que se passe-t-il lorsque la partition x se remplit?" Dearest voretaq7 a soulevé la situation avec un plein /causant un certain nombre de problèmes difficiles à diagnostiquer. Regardons quelques situations plus spécifiques.

Que se passe-t-il si votre partition contenant des journaux est pleine? Vous perdez des données d'audit / de rapport et est parfois utilisé par des attaquants pour masquer leur activité. Dans certains cas, votre système n'authentifiera pas les nouveaux utilisateurs s'il ne peut pas enregistrer leur événement de connexion.

Que se passe-t-il sur un système basé sur RPM lorsqu'il /varest plein? Le gestionnaire de packages n'installe ni ne met à jour les packages et, selon votre configuration, peut échouer en silence.

Remplir une partition est facile, surtout lorsqu'un utilisateur est capable d'y écrire. Pour le plaisir, exécutez cette commande et voir comment vous pouvez rapidement créer un fichier assez grand: cat /dev/zero > zerofile.

Cela va au-delà du remplissage des partitions également, lorsque vous placez des emplacements sur différents points de montage, vous pouvez également personnaliser leurs options de montage.

Que se passe-t-il lorsque /dev/n'est pas monté avec noexec? Comme il /devest généralement supposé être maintenu par le système d'exploitation et ne contenir que des périphériques, il était fréquemment (et parfois encore) utilisé pour masquer les programmes malveillants. Le fait de quitter noexecpermet de lancer des fichiers binaires qui y sont stockés.

Pour toutes ces raisons, et plus encore, de nombreux guides de durcissement discuteront du partitionnement comme l'une des premières étapes à effectuer. En fait, si vous construisez un nouveau serveur, la façon de partitionner le disque est presque exactement la première chose que vous devez décider, et souvent la plus difficile à modifier ultérieurement. Il existe un groupe appelé Center for Internet Security qui produit des tas de guides de configuration faciles à lire. Vous pouvez probablement trouver un guide pour votre système d'exploitation spécifique et voir les détails qu'ils pourraient dire.

Si nous regardons RedHat Enterprise Linux 6, le schéma de partitionnement recommandé est le suivant:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

Le principe derrière toutes ces modifications est de les empêcher de se toucher et / ou de limiter ce qui peut être fait sur une partition spécifique. Prenez /tmppar exemple les options . Cela signifie qu'aucun nœud de périphérique ne peut y être créé, aucun programme ne peut être exécuté à partir de là, et le bit set-uid ne peut être défini sur rien. De par sa nature même, il /tmpest presque toujours accessible en écriture dans le monde entier et est souvent un type spécial de système de fichiers qui n'existe qu'en mémoire. Cela signifie qu'un attaquant pourrait l'utiliser comme un point de transfert facile pour supprimer et exécuter du code malveillant, puis planter (ou simplement redémarrer) le système effacera toutes les preuves. Étant donné que la fonctionnalité de /tmpne nécessite aucune de ces fonctionnalités, nous pouvons facilement désactiver les fonctionnalités et éviter cette situation.

Les lieux de stockage des journaux, /var/loget /var/log/auditsont cloisonner le tampon pour les aider à l' épuisement des ressources. De plus, auditd peut effectuer certaines tâches spéciales (généralement dans des environnements à sécurité élevée) lorsque son stockage de journaux commence à se remplir. En le plaçant sur sa partition, cette détection de ressources fonctionne mieux.

Pour être plus verbeux et citer mount(8), c'est exactement ce que sont les options utilisées ci-dessus:

noexec Ne pas autoriser l'exécution directe de fichiers binaires sur le système de fichiers monté. (Jusqu'à récemment, il était de toute façon possible d'exécuter des binaires en utilisant une commande comme /lib/ld*.so / mnt / binary. Cette astuce échoue depuis Linux 2.4.25 / 2.6.0.)

nodev N'interprète pas les caractères et ne bloque pas les périphériques spéciaux du système de fichiers.

nosuid Ne permet pas aux bits set-user-identifier ou set-group-identifier de prendre effet. (Cela semble sûr, mais est en fait plutôt dangereux si suidperl (1) est installé.)

Du point de vue de la sécurité, ce sont de très bonnes options à connaître car elles vous permettront de mettre des protections sur le système de fichiers lui-même. Dans un environnement hautement sécurisé, vous pouvez même ajouter l' noexecoption à /home. Il sera plus difficile pour votre utilisateur standard d'écrire des scripts shell pour le traitement des données, par exemple l'analyse des fichiers journaux, mais cela les empêchera également d'exécuter un binaire qui élèvera les privilèges.

N'oubliez pas non plus que le répertoire de base par défaut de l'utilisateur root est /root. Cela signifie qu'il sera dans le /système de fichiers, pas dans /home.

Le montant exact que vous donnez à chaque partition peut varier considérablement en fonction de la charge de travail du système. Un serveur typique que j'ai géré nécessitera rarement une interaction avec une personne et, en tant que tel, la /homepartition n'a pas besoin d'être très grande du tout. La même chose s'applique /varcar elle a tendance à stocker des données plutôt éphémères qui sont créées et supprimées fréquemment. Cependant, un serveur Web utilise généralement /var/wwwcomme terrain de jeu, ce qui signifie que celui-ci doit également être sur une partition distincte ou /var/doit être agrandi.

Dans le passé, j'ai recommandé ce qui suit comme références.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

Ceux-ci doivent être examinés et ajustés en fonction de l'objectif du système et du fonctionnement de votre environnement. Je recommanderais également d'utiliser LVM et de ne pas allouer l'intégralité du disque. Cela vous permettra d'agrandir ou d'ajouter facilement des partitions si de telles choses sont nécessaires.


1
L' noexecobservation est importante en général - il est considéré comme une bonne pratique de monter /tmpavec l' noexecindicateur pour éviter que des utilisateurs malveillants ne téléchargent des rootkits via des exploits de sécurité du navigateur. De même /homeest souvent monté nosuidcar il n'y a aucune raison pour que les binaires setuid soient là. Re: /devet noexec, sur de nombreux (mais pas tous) les systèmes modernes /devsont souvent un devfssystème de fichiers et ne permettent pas aux utilisateurs de créer / stocker des fichiers réguliers (sur FreeBSD, il renvoie " Operation not supported", sur Ubuntu, le udevsystème de fichiers monté sur /devvous permet de créer des fichiers réguliers. ).
voretaq7

2
@ voretaq7: Oui, utiliser /tmpcomme tremplin est très amusant car il est toujours là et presque jamais verrouillé.
Scott Pack

Merci pour ces conseils. Je vais vérifier noexec car cela améliore la sécurité!
Buzut

12

En ignorant la matrice RAID sous-jacente ( voir cette question pour plus de détails sur les niveaux de matrice RAID et quand vous voulez les utiliser ), concentrons-nous sur la question centrale que vous posez:
"Comment dois-je disposer les systèmes de fichiers de mon serveur Unix?"


Quel est le problème avec une /partition géante ?

Comme vous l'avez noté dans votre question, de nombreuses distributions Linux (en particulier les distributions "Desktop" comme Ubuntu) utilisent une disposition de système de fichiers très simple: /et [swap].

Ce schéma a l'avantage de la simplicité - il est idéal pour les utilisateurs DOS / Windows qui sont habitués à leur PC personnel avec "le disque dur" comme un grand conteneur monolithique ( C:\) dans lequel vous videz des trucs, et vous n'avez pas à vous inquiéter à propos de manquer d'espace sur les systèmes de fichiers - assurez-vous simplement de rester sous la capacité du disque et tout va (au moins théoriquement) bien.

Le système à système de fichiers unique présente cependant plusieurs inconvénients - l'inconvénient le plus souvent cité est que les systèmes Unix ont tendance à très mal réagir lorsque le système de fichiers racine se remplit (au point de refuser de démarrer), et si tout est écrit sur /(la racine) un programme ou un utilisateur capricieux peut supprimer tout le système.
Un seul système de fichiers volumineux est également susceptible de représenter une perte totale en cas de panne du système et de corruption du système de fichiers.

Les problèmes ci-dessus, ainsi qu'un fort sens de l'organisation, expliquent pourquoi les serveurs Unix ont généralement plusieurs systèmes de fichiers.


Comment divisez-vous le système de fichiers Unix?

J'espère donc que vous êtes convaincu qu'il est logique d'avoir plusieurs systèmes de fichiers. La question est maintenant de savoir comment diviser le système en morceaux logiques et comment décider combien d'espace chacun obtient?
La réponse est que vous connaissez et comprenez ce que votre système d'exploitation va mettre où. Le point de départ de cette compréhension est la hierpage de manuel. La plupart des systèmes Unix sont fournis avec (à man hierpartir d'un système Linux et man hierd'un système BSD ), et cela, plus votre connaissance locale de ce que le code que vous installez va faire, vous guidera dans la création d'une disposition de partitionnement saine.

Je vais décrire ici un schéma général de partitionnement, mais ce schéma doit toujours être modifié pour répondre à vos besoins spécifiques.

Un schéma de partitionnement Unix général

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Systèmes de fichiers spéciaux

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

2
Les deux raisons que vous avez énumérées sont aujourd'hui largement obsolètes. ext [234] réserve de l'espace pour root et ne permettra pas aux programmes utilisateurs de tout utiliser pour que le système ne rencontre pas de problèmes de manque d'espace, et tous les systèmes de fichiers modernes utilisent la journalisation pour ne pas être corrompus après un accident.
psusi

2
@psusi L'espace réservé à l'utilisateur root (généralement 5 à 10% de la taille du système de fichiers) ne vous aide pas si l'utilisateur root est celui qui écrit les fichiers qui remplissent le disque (comme c'est souvent le cas avec les fichiers journaux). Il est également incorrect de supposer que, simplement parce qu'un système de fichiers est journalisé, il sera toujours à l'abri de la corruption - la journalisation augmente la robustesse, mais elle ne garantit pas la sécurité (en particulier si vous tombez sur un bogue non découvert dans le code du système de fichiers / journalisation et caillez le journal - Les gens de ReiserFS peuvent raconter de belles histoires à ce sujet depuis les débuts de ce système de fichiers).
voretaq7

2
Ayant un intact /usrou /varn'aide pas si /est corrompu. De même, avoir un intact /n'aide pas (beaucoup) s'il /homeest corrompu. Vous finissez par devoir restaurer à partir de la sauvegarde de toute façon. Sans oublier que ces échecs sont un sur un million, sauf si vous exécutez un nouveau / instable fs.
psusi

4

La pratique de découper le système de fichiers comme ça remonte à l'époque où il n'y avait pas de raid logiciel, et les lecteurs de disque étaient petits, donc vous deviez en utiliser plusieurs, et donc, la seule façon de le faire était de casser le système de fichiers et mettre différents répertoires sur différents lecteurs. L'autre raison historique était que vous pouviez facilement démonter une partition et la dumpsauvegarder, ce que vous ne pouviez pas faire avec la racine. Cet outil est largement tombé en disgrâce ces jours-ci et peut à la place être utilisé sur un instantané LVM même sur la racine.

Il n'y a plus ou peu de raison de le faire. La seule raison qui reste à faire est de vouloir, par exemple, empêcher /tmpde remplir tout le disque.

Cette raison est largement hors de propos ces jours-ci, car la fourniture aux utilisateurs d'un accès shell général a disparu, et ces jours-ci, les serveurs exécutent des services dédiés, tels que des serveurs Web ou de messagerie. Étant donné que vous n'avez pas d'utilisateurs aléatoires capables d'exécuter des commandes arbitraires, vous n'avez généralement pas à vous soucier qu'ils essaient de remplir votre système de fichiers (et même lorsque vous l'avez fait, vous aviez des quotas de disque pour arrêter cela).

En ce qui concerne le niveau de raid à utiliser, vous devez vous rappeler que le but principal du raid n'est pas de protéger les données (c'est à cela que servent les sauvegardes), mais de maintenir la disponibilité. Si vous /tmplancez un raid0, votre serveur tombera quand même et vous devrez aller le réparer si l'un des disques tombe en panne. Vous pouvez également utiliser raid10 au lieu de raid1 afin d'obtenir également de meilleures performances.

Une très bonne raison de NE PAS casser le système de fichiers est que si vous vous trompez d'allocations, vous pouvez vous retrouver avec une partie du système de fichiers pleine malgré qu'il y ait beaucoup d'espace libre ailleurs. Corriger cela peut être difficile, sauf si vous utilisez LVM et que vous avez laissé un espace non attribué.


4
Il y a beaucoup de raisons de continuer à découper un système de fichiers Unix de la manière traditionnelle. S'il n'y avait aucune raison de le faire, nous nous serions arrêtés maintenant - les administrateurs système ne sont PAS CELA attachés aux traditions arcaniques :)
voretaq7

1
@ voretaq7, puis en nommer quelques-uns. Si vous ne le pouvez pas, il est insensé de supposer aveuglément qu'il doit y en avoir.
psusi

1
Il incomberait à ceux qui votent en aval de fournir un contre-argument plutôt que de percher aveuglément la sagesse conventionnelle.
psusi

2
Empêche / var / log de tout prendre en remplissant. Limite la corruption à un système de fichiers. Simplifie les sauvegardes - que ce soit des instantanés ou des règles de traversée de montage, on veut souvent sauvegarder les choses sur des planifications différentes. Simplifie l'imagerie / mises à niveau. Permet de sélectionner les performances des systèmes de fichiers liées à la tâche.
Jeff Ferland

1
@JeffFerland, au mieux c'est une faible raison de mettre / var / log sur sa propre partition, mais pas pour les plusieurs autres partitions. Sauf si vous l'utilisez toujours dump, la sauvegarde de différentes parties du fs n'a pas besoin que ces parties soient sur des partitions différentes. Les mises à niveau ne se soucient pas d'une manière ou d'une autre. L'imagerie n'est pas non plus un très bon moyen de faire les choses.
psusi

3

Beaucoup d'informations de partitionnement ont été générées lorsque l'espace disque était insuffisant. En conséquence, vous verrez des partitions relativement petites pour un certain nombre de cas. Les tailles de partition requises varient en fonction de l'utilisation du serveur. La plus variable ont tendance à être /tmp, /var, home, /optet /srv. /usra tendance à être d'une taille raisonnable et stable. L'espace pour /peut inclure une ou toutes les autres partitions et leurs besoins d'espace. Le dimensionnement dépend vraiment de ce que vous faites du système.

J'augmenter swapet monter /tmpsur tmpfs. Vous /tmputiliserez ensuite swap comme magasin de sauvegarde, mais utilisez la mémoire disponible. La taille de votre /tmpapparence est extrêmement élevée, mais gérera les téléchargements interrompus qui ne sont pas nettoyés.

J'envisagerais de déplacer les fichiers MySQL vers /srv. Il s'agit d'un niveau relativement nouveau dans la hiérarchie des disques.

Si vous ne connaissez pas vos besoins ultimes, envisagez d'utiliser LVM et d'étendre vos partitions en tant que remplissage.


Soyez prudent en augmentant le swap - Il est bon d'avoir "assez" de swap, mais si vous en avez trop, vous ne l'utiliserez jamais (car au moment où vous permutez autant, les performances du système sont tout simplement trop pénibles). Je dirais que la 4G proposée dans la question est probablement "suffisante" pour une pile LAMP - si vous utilisez la 4G de swap (et que vous effectuez une pagination sur ces données), vous êtes probablement aussi sur le téléphone, car vous criez parce que le site est lent :)
voretaq7

1
@ voretaq7 Peu importe la taille de l'échange si vous l'utilisez pour des programmes actifs. L'utiliser pour des tmpfs où de gros fichiers sont écrits sur le disque mais où des fichiers plus petits restent résidents en mémoire est une utilisation raisonnable du swap. Il économise sur l'écriture de chaque fichier sur le disque lorsque l'intention est de le mettre ailleurs. J'ai suggéré d'augmenter l'espace de swap car il semblait qu'un grand /tmpespace pouvait être requis.
BillThor

Pourquoi ne pas utiliser un fichier standard pour l'échange? N'ont-ils pas été aussi rapides qu'une partition de swap dédiée depuis longtemps?
Chris Smith

@ChrisSmith Un fichier normal doit être presque aussi rapide qu'une partition dédiée, mais il peut ne pas être contigu sur le disque conduisant à des demandes d'E / S divisées. Cela peut être compensé par rayures. En outre, il est relativement facile de supprimer accidentellement un fichier d'échange. Le fichier supprimé ne sera évident qu'au redémarrage du système, lorsqu'il n'aura plus d'espace de swap.
BillThor

@BillThor Cela est vrai - si vous utilisez tmpfset prévoyez de swap en tant que magasin de sauvegarde, vous devriez avoir "assez" de swap pour répondre à vos demandes tmpfs, ainsi qu'une réserve appropriée pour le système. (Ce n'est pas quelque chose auquel je pense normalement puisque le seul système où j'utilise tmpfsest configuré pour ne pas frapper le swap, car il a un surplus de RAM et j'utilise l'espace temporaire pour les petits fichiers qui sont créés / supprimés rapidement :)
voretaq7

2

En fonction de votre architecture - il se peut que vous ne souhaitiez pas réellement utiliser / tmp car il est effacé après chaque redémarrage. Si votre site traite d'un traitement éventuel des téléchargements, le changer en un autre emplacement (via php.ini) peut être une idée; dans lequel vous pouvez en faire n'importe quel point de montage.

Comme suggéré précédemment, il est fortement recommandé d'utiliser LVM et d'incrémenter au besoin.

Je recommanderais également fortement une partition dédiée pour les données MySQL (vous pouvez toujours la monter sous / var / lib / mysql).


C'est généralement une bonne idée de supposer que les fichiers /tmpne seront peut-être pas là plus tard - vous évite les mauvaises surprises plus tard :-)
voretaq7
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.