web-dev-qa-db-fra.com

Meilleur ordre de RAID, LVM et LUKS

Je vais installer un serveur de fichiers avec Debian GNU/Linux 8.

Je souhaite disposer du logiciel RAID-1 utilisant mdadm ainsi que des disques chiffrés utilisant LUKS. J'aime aussi la flexibilité d'avoir LVM.

Il y a différentes façons de le faire. L'une des méthodes consiste à: Commencez par configurer RAID-1 à l'aide de mdadm. Configurez ensuite les PV LVM pour couvrir le répertoire/dev/mdX créé. Configurez ensuite les LV et chiffrez ceux qui utilisent LUKS. Puis formatez-les avec un système de fichiers, disons ext4. Cela donne une mise en page comme ceci:

RAID --> LVM --> LUKS --> ext4

Ou je pourrais le faire dans un ordre différent:

RAID --> LUKS --> LVM --> ext4

Ou peut-être même:

LVM --> RAID --> LUKS --> ext4

Et peut-être même un ordre totalement différent.

Quels sont les avantages et les inconvénients des différentes approches? Qu'est-ce qui donne les meilleures performances, sécurité, maintenabilité, etc.?

Y at-il une "meilleure façon" de le faire?

linuxdebianraidlvmluks
12
Thomas

Premièrement, l'ordre de LUKS et de LVM dépend du choix de mots de passe LUKS ou d'autres paramètres pour différents LV. Si, par exemple, vous devez configurer différents mots de passe pour différentes LV, vous devez absolument placer LUKS au-dessus de LVM. Par ailleurs, si tous les LV partagent le même mot de passe et les mêmes paramètres tels que keylen, vous souhaiterez que LUKS soit situé sous LVM, de sorte que vous n’ayez pas à vous préoccuper de la surcharge liée à la présence de plusieurs partitions LUKS (pensez à ce que vous voulez). devoir faire lorsque vous devez changer le mot de passe).

Deuxièmement, vous voulez presque toujours que le niveau RAID soit au niveau le plus bas. Ainsi, lorsqu'un disque meurt, il peut être échangé facilement et de manière transparente. Si vous deviez mettre en place un système RAID au-dessus de LVM, il vous faudrait remplacer un PV lorsqu'un disque meurt, ce serait très pénible. De plus, le RAID au-dessus de LVM annulerait totalement la flexibilité de LVM. Vous devrez alors probablement configurer à nouveau la deuxième couche de LVM au-dessus du RAID!

Par conséquent, dans la plupart des cas, il suffit d'utiliser un seul mot de passe, cela suffirait:

RAID -> LUKS -> LVM -> ext4

Dans certains cas, vous devrez peut-être utiliser LVM pour combiner plusieurs périphériques RAID en un volume important. Vous pouvez alors:

RAID -> LVM -> LUKS (-> LVM) -> ext4

Théoriquement, l'ordre ne devrait pas affecter beaucoup les performances, si chaque couche est correctement configurée , et en pratique, je n'ai pas vu cette configuration présenter une performance particulièrement mauvaise. La chose la plus importante est probablement l'alignement:

  1. assurez-vous que vos partitions sont alignées sur 1 Mo (très important pour les disques SSD);
  2. pour la couche RAID, choisissez judicieusement la taille du bloc ;
  3. pour LVM, assurez-vous de définir --dataalignment pour qu'il corresponde à la taille du bloc RAID ( , ceci pourrait être utile).

De même, si vous utilisez le disque SSD, assurez-vous d'activer la procédure de passation de LUKS TRIM/DISCARD en ajoutant rd.luks.options=discard à /etc/default/grub et discard à /etc/crypttab (ce que je fais sous Red Hat/Fedora Linux. Peut-être un peu différent sous Debian.) LVM et RAID devrait automatiquement supporter la suppression si vous utilisez un noyau new-ish.

Bien sûr, ce ne sont que des directives générales. Si vous avez des besoins particuliers, n'hésitez pas à mettre à jour votre question ou votre commentaire ici.

16
Yan Li

Si vous voulez tout le RAID, LUKS et LVM, je recommanderais RAID -> LUKS -> LVM -> FS. RAID --> LVM --> LUKS --> LVM --> FS n'est pas meilleur que RAID -> LUKS -> LVM - pour étendre des volumes, ajoutez simplement plus de périphériques RAID -> LUKS à un groupe de volumes.

RAID --> LVM --> LUKS --> FS - chiffrer uniquement des volumes logiques particuliers a la particularité de ne pas tout chiffrer par défaut (peut être considéré comme un avantage ou un inconvénient), mais cela facilitera l'extension de la racine FS.

L'extension de LUKS au-dessus des volumes logiques est une source commune de problèmes lorsque les utilisateurs les développent/les redimensionnent dans le mauvais ordre. Avoir LUKS sur tout le périphérique RAID md simplifiera le redimensionnement - ajoutez un nouveau périphérique md, créez LUKS en plus, ajoutez un périphérique à /etc/crypttab (au moins sur Fedora et RHEL clones) et élargissez votre groupe de volumes. Si la racine FS se trouve sur le groupe de volumes, vous devrez ajouter une autre entrée rd.luks.uuid à la cmdline du noyau (edit /etc/default/grub et régénérer grub. cfg.)

LUKS -> RAID est généralement faux - les données seront chiffrées plusieurs fois, consommant plus de cycles de la CPU sans gain. Il est également possible de remplacer par erreur un disque en panne par un nouveau sans configurer LUKS en cas de défaillance d'un disque.

Étendre et rétrécir:

Quand vous étendez, commencez toujours par le bas de la pile, et rétrécissez par le haut.

Exemple:

Extension RAID -> LVM -> LUKS -> FS (les deux premières étapes sont facultatives s'il existe suffisamment d'espace libre dans le groupe de volumes):

  1. Ajoutez de nouveaux disques et créez md RAID.
  2. Ajoutez un périphérique mdX au groupe de volumes.
  3. Étendre le volume logique.
  4. Étendre le périphérique LUKS.
  5. Étendre FS.

Réduction RAID -> LVM -> LUKS -> FS:

  1. Réduire FS.
  2. Réduire le périphérique LUKS.
  3. Réduire le volume logique.
3
Martian