L'un des serveurs que j'administre exécute le type de configuration que vous décrivez. Il dispose de six disques durs de 1 To avec un pool RAIDZ crypté LUKS. J'ai également deux disques durs de 3 To dans un miroir ZFS crypté LUKS qui sont échangés chaque semaine pour être retirés du site. Le serveur utilise cette configuration depuis environ trois ans et je n'ai jamais eu de problème avec.
Si vous avez besoin de ZFS avec cryptage sous Linux, je recommande cette configuration. J'utilise ZFS-Fuse, pas ZFS sous Linux. Cependant, je crois que cela n'aurait aucune incidence sur le résultat autre que ZFS sur Linux aura probablement de meilleures performances que la configuration que j'utilise.
Dans cette configuration, les données redondantes sont chiffrées plusieurs fois car LUKS n'est pas "au courant" de Z-RAID. Dans la solution LUKS-on-mdadm, les données sont chiffrées une fois et simplement écrites plusieurs fois sur les disques.
Gardez à l'esprit que LUKS n'est pas au courant du RAID. Il sait seulement qu'il se trouve au-dessus d'un périphérique bloc. Si vous utilisez mdadm pour créer un périphérique RAID et ensuite luksformat
, c'est mdadm qui réplique les données chiffrées sur les périphériques de stockage sous-jacents, pas LUKS.
La question 2.8 de la FAQ LUKS aborde la question de savoir si le chiffrement doit être au-dessus du RAID ou inversement . Il fournit le diagramme suivant.
Filesystem <- top
|
Encryption
|
RAID
|
Raw partitions
|
Raw disks <- bottom
Parce que ZFS combine la fonctionnalité RAID et le système de fichiers, votre solution devra ressembler à ce qui suit.
RAID-Z and ZFS Filesystem <-top
|
Encryption
|
Raw partitions (optional)
|
Raw disks <- bottom
J'ai répertorié les partitions brutes comme facultatives car ZFS s'attend à ce qu'il utilise le stockage de blocs bruts plutôt qu'une partition. Bien que vous puissiez créer votre zpool à l'aide de partitions, ce n'est pas recommandé car cela ajoutera un niveau de gestion inutile, et il devra être pris en compte lors du calcul de votre décalage pour l'alignement des blocs de partition.
Cela n'entraverait-il pas considérablement les performances d'écriture? [...] Mon processeur prend en charge Intel AES-NI.
Il ne devrait pas y avoir de problème de performances tant que vous choisissez une méthode de chiffrement prise en charge par votre pilote AES-NI. Si vous avez cryptsetup 1.6.0 ou une version plus récente, vous pouvez exécuter cryptsetup benchmark
et voir quel algorithme fournira les meilleures performances.
Cette question sur les options recommandées pour LUKS peut également être utile.
Étant donné que vous disposez d'une prise en charge du chiffrement matériel, vous êtes plus susceptible de rencontrer des problèmes de performances en raison d'un mauvais alignement de partition.
ZFS sous Linux a ajouté la ashift
propriété à la zfs
commande pour vous permettre de spécifier la taille du secteur pour vos disques durs. Selon la FAQ liée, ashift=12
dirait que vous utilisez des disques avec une taille de bloc 4K.
La FAQ LUKS indique qu'une partition LUKS a un alignement de 1 Mo. Les questions 6.12 et 6.13 en discutent en détail et fournissent également des conseils sur la façon d'agrandir l'en-tête de partition LUKS. Cependant, je ne suis pas sûr qu'il soit possible de le rendre suffisamment grand pour garantir que votre système de fichiers ZFS sera créé sur une frontière 4K. J'aimerais savoir comment cela fonctionne pour vous s'il s'agit d'un problème que vous devez résoudre. Étant donné que vous utilisez des lecteurs de 2 To, vous pourriez ne pas rencontrer ce problème.
ZFS sera-t-il au courant des pannes de disque lorsqu'il fonctionne sur des conteneurs LUKS de mappeur de périphériques par opposition aux périphériques physiques?
ZFS sera conscient des pannes de disque dans la mesure où il peut les lire et y écrire sans problème. ZFS nécessite un stockage en bloc et ne se soucie pas ou ne connaît pas les spécificités de ce stockage et d'où il vient. Il ne garde trace que des erreurs de lecture, d'écriture ou de somme de contrôle qu'il rencontre. C'est à vous de surveiller la santé des périphériques de stockage sous-jacents.
La documentation ZFS contient une section sur le dépannage qui mérite d'être lue. La section sur le remplacement ou la réparation d'un périphérique endommagé décrit ce que vous pouvez rencontrer lors d'un scénario de défaillance et comment vous pouvez le résoudre. Vous feriez la même chose ici que pour les appareils qui n'ont pas ZFS. Vérifiez le journal système pour les messages de votre pilote SCSI, contrôleur HBA ou HD et / ou logiciel de surveillance SMART, puis agissez en conséquence.
Qu'en est-il de la déduplication et des autres fonctionnalités ZFS?
Toutes les fonctionnalités ZFS fonctionneront de la même manière, que le stockage sous-jacent soit chiffré ou non.
Sommaire
- ZFS sur les appareils cryptés LUKS fonctionne bien.
- Si vous disposez d'un chiffrement matériel, vous ne verrez pas de performances baisser tant que vous utilisez une méthode de chiffrement prise en charge par votre matériel. Utilisez
cryptsetup benchmark
pour voir ce qui fonctionnera le mieux sur votre matériel.
- Considérez ZFS comme un RAID et un système de fichiers combinés en une seule entité. Voir le diagramme ASCII ci-dessus pour savoir où il s'insère dans la pile de stockage.
- Vous devrez déverrouiller chaque périphérique de bloc crypté LUKS utilisé par le système de fichiers ZFS.
- Surveillez la santé du matériel de stockage de la même manière que maintenant.
- Soyez conscient de l'alignement des blocs du système de fichiers si vous utilisez des disques avec des blocs 4K. Vous devrez peut-être expérimenter avec les options luksformat ou d'autres paramètres pour obtenir l'alignement dont vous avez besoin pour une vitesse acceptable.