Faire croître un pool ZFS à partir de disques ext4 peuplés

Vous pouvez ajouter des dispositifs à un pool après sa création, mais pas vraiment de la manière dont vous semblez l'envisager.

Avec ZFS, la seule configuration redondante à laquelle vous pouvez ajouter des périphériques est le miroir. Il n'est actuellement pas possible d'ajouter des périphériques supplémentaires à un vdev raidzN après sa création. L'ajout de périphériques à un miroir augmente la redondance mais pas la capacité de stockage disponible.

Il est possible de contourner ce problème dans une certaine mesure, en créant un vdev raidzN de la configuration souhaitée à l'aide de fichiers épars pour le fichier redondance puis en supprimant les fichiers épars avant de remplir le vdev avec des données. Une fois que vous avez des lecteurs disponibles, vous devez zpool replace les fichiers épars (maintenant inexistants) avec ceux-ci. Le problème de cette approche, qui n'est pas qu'un chemin de migration vers une solution plus idéale, est que le pool affichera en permanence le statut DEGRADED ce qui signifie que vous devez regarder de beaucoup plus près pour reconnaître tout réel Dégradation du stockage ; c'est pourquoi je ne le recommande pas vraiment comme solution permanente.

L'ajout naïf de périphériques à un pool ZFS comporte en fait un risque sérieux de diminution de la résilience du pool aux pannes, car tous les vdev de premier niveau doivent être fonctionnels pour que le pool le soit. Ces périphériques de niveau supérieur peuvent avoir des configurations redondantes, mais ce n'est pas nécessaire ; il est parfaitement possible d'exécuter ZFS dans une configuration de type JBOD, auquel cas la défaillance d'un seul périphérique est très susceptible de faire tomber votre pool (mauvaise idée si vous pouvez l'éviter, mais cela vous donne quand même de nombreuses possibilités ZFS même dans une configuration à un seul disque). Fondamentalement, un pool ZFS redondant est constitué d'une combinaison JBOD d'un ou plusieurs périphériques redondants ; un pool ZFS non redondant est constitué d'une combinaison JBOD d'un ou plusieurs périphériques JBOD.

L'ajout de vdev de niveau supérieur ne permet pas non plus à ZFS d'équilibrer les données sur les nouveaux périphériques ; il éventuellement se produit pour les données qui sont réécrites (en raison de la nature de la copie sur l'écriture du système de fichiers et de l'utilisation de la fonction de copie sur l'écriture). favoriser les vdevs avec plus d'espace libre ), mais cela ne se produit pas pour les données qui restent là et sont lues mais jamais réécrites. Vous pouvez le faire en réécrivant les données (par exemple en utilisant la fonction zfs send | zfs recv (en supposant que la déduplication n'est pas activée pour le pool) mais elle vous oblige à prendre des mesures spécifiques.

D'après les chiffres de votre message, c'est le cas :

• 4 × disques de 2TB

• 2 × 4TB disques

• environ 8 To de données

Puisque vous dites que vous voulez une configuration redondante, étant donné ces contraintes (en particulier le jeu de disques disponibles), je suggérerais probablement en regroupant les disques en paires de miroirs. Cela vous donnerait un plan de piscine comme celui-ci :

• réservoir
  • miroir-0
    • 2TBHDD1
    • 2TBHDD2
  • miroir-1
    • 2TBHDD3
    • 2TBHDD4
  • miroir-2
    • 4TBHDD1
    • 4TBHDD2

Cette configuration aura une capacité de stockage accessible à l'utilisateur d'environ 8 To, plus ou moins de métadonnées (vous avez deux miroirs fournissant 2 To chacun, plus un miroir fournissant 4 To, pour un total de 8 To). Vous pouvez ajouter d'autres paires de miroirs plus tard pour augmenter la capacité du pool, ou remplacer une paire de disques de 2 To par des disques de 4 To (mais sachez que le réarrimage en cas de défaillance d'un disque dans une paire de miroirs exerce une forte pression sur le(s) disque(s) restant(s), ce qui, dans le cas de miroirs bidirectionnels, augmente considérablement le risque de défaillance complète du miroir). L'inconvénient de cette configuration est que la piscine sera pratiquement pleine dès le début, et la suggestion générale est de garder les pools ZFS en dessous d'environ 75% de leur capacité. Si vos données ne sont pour la plupart jamais lues, vous pouvez vous en sortir avec moins de marge, mais les performances en pâtiront grandement en particulier sur les écrits. Si votre jeu de données est très exigeant en termes d'écriture, vous voulez absolument que l'allocateur de blocs dispose d'une certaine marge de manœuvre. Ainsi, cette configuration "fonctionnera", pour une certaine définition du mot, mais sera sous-optimale.

Puisque vous pouvez librement ajouter des périphériques miroirs supplémentaires à un vdev, avec un peu de planification, il devrait être possible de le faire de telle sorte que vous ne perdiez aucune de vos données.

Vous pourriez en principe remplacer le miroir-0 et le miroir-1 ci-dessus par un seul vdev raidz1 composé des quatre disques durs de 2 To (ce qui vous donne une capacité de stockage utilisable de 6 To au lieu de 4 To, et la possibilité de survivre à la défaillance d'un disque dur de 2 To avant que vos données ne soient en danger), mais cela signifie que trois de ces disques doivent être engagés initialement dans ZFS. Compte tenu de vos chiffres d'utilisation, cela ressemble à ceci pourrait être possible avec un peu de brassage de données. Je ne recommanderais pas de mélanger des vdev de différents niveaux de redondance, cependant, et je pense que les outils vous obligent même dans ce cas à dire effectivement "oui, je sais vraiment ce que je fais".

Mélange de disques de tailles différentes dans un pool (et notamment dans un seul vdev, sauf comme voie de migration vers des disques de plus grande capacité) n'est pas vraiment recommandé ; dans les configurations vdev miroir et raidzN, le plus petit disque constitutif du vdev détermine la capacité du vdev. Il est possible de mélanger des vdev de capacité différente, mais cela conduira à une configuration de stockage déséquilibrée ; cependant, si la plupart de vos données sont rarement lues, et si elles sont lues séquentiellement, cela ne devrait pas poser de problème majeur.

La meilleure configuration serait probablement d'obtenir trois disques supplémentaires de 4 To, puis de créer un pool composé d'un seul vdev raidz2 constitué de ces cinq disques de 4 To, et de retirer effectivement les disques de 2 To. Cinq disques de 4 To en raidz2 vous donneront 12 To de capacité de stockage (ce qui laisse une bonne marge de progression) et raidz2 vous donne la possibilité de survivre à la défaillance de deux de ces disques, laissant la configuration miroir dans la poussière en termes de résilience aux problèmes de disque. Avec un peu de planification et de brassage des données, il devrait être facile de migrer vers une telle configuration sans perte de données. Le raidz2 à cinq disques est également presque optimal en termes de surcharge de stockage, selon des tests effectués par un utilisateur et publiés sur la liste de discussion ZFS On Linux à la fin du mois d'avril, montrant une capacité de stockage utilisable à 96,4 % de la capacité optimale lors de l'utilisation de périphériques de 1 To, battue seulement par une configuration à six lecteurs par périphérique qui donne 97,3 % dans le même test.

Je réalise que cinq disques de 4 To ne sont peut-être pas pratiques dans un environnement domestique, mais gardez à l'esprit que ZFS est un système de fichiers d'entreprise, et que nombre de ses limitations (en particulier dans ce cas, les limitations sur la croissance des vdev redondants après la création) reflètent cela.

Et n'oubliez jamais, aucun type de RAID n'est sauvegardé . Vous avez besoin des deux pour être raisonnablement protégé contre la perte de données.