Agrandir
/
OpenZFS prend en charge de nombreuses topologies de disques complexes, mais la "pile en spirale assise sur un bureau" n'en fait toujours pas partie.
Jim Salter
commentaires des lecteurs
102
avec 48 affiches participantes, y compris l'auteur de l'histoire
Partagez cette histoire
Partager sur Facebook
Partager sur Twitter
Partager sur Reddit
Le développeur fondateur d'OpenZFS, Matthew Ahrens, a ouvert un communiqué de presse pour l'une des fonctionnalités les plus recherchées de l'histoire de ZFS, l'extension RAIDz, la semaine dernière. La nouvelle fonctionnalité permet à un utilisateur ZFS d'étendre la taille d'un seul vdev RAIDz. Par exemple, vous pouvez utiliser la nouvelle fonctionnalité pour transformer un RAIDz1 à trois disques en un RAIDz1 à quatre, cinq ou six disques.
Lectures complémentaires
ZFS 101—Comprendre le stockage et les performances ZFS
OpenZFS est un système de fichiers complexe, et les choses vont nécessairement devenir un peu compliquées pour expliquer le fonctionnement de la fonctionnalité. Donc, si vous êtes un débutant ZFS, vous pouvez vous référer à notre ZFS 101 complet
introduction
.
Extension du stockage dans ZFS
En plus d'être un système de fichiers, ZFS est une matrice de stockage et un gestionnaire de volumes, ce qui signifie que vous pouvez lui fournir toute une pile de périphériques de disque, pas un seul. Le cœur d'un système de stockage ZFS est le
zpool
— il s'agit du niveau le plus fondamental du stockage ZFS. Les
zpool
contient à son tour
vdev
, et
vdev
contiennent des disques réels en leur sein. Les écritures sont divisées en unités appelées
enregistrements
ou
blocs
, qui sont ensuite répartis de manière semi-équitable entre les
vdev
.
Un stockage
vdev
peut être l'un des cinq types suivants : un seul disque, un miroir,
RAIDz1
,
RAIDz2
, ou
RAIDz3
. Vous pouvez ajouter plus
vdev
à un
zpool
, et tu peux
attacher
plusieurs disques sur un seul ou un miroir
vdev
. Mais gérer le stockage de cette manière nécessite une planification et une budgétisation à l'avance, ce dont les amateurs et les homelabbers ne sont souvent pas très enthousiastes.
Conventionnel
RAID
, qui ne partage pas le concept de « pool » avec ZFS, offre généralement la possibilité d'étendre et/ou de remodeler une baie en place. Par exemple, vous pouvez ajouter un seul disque à un ensemble de six disques
RAID6
tableau, le transformant ainsi en un sept disques
RAID6
déployer. Subir un remodelage en direct peut être assez douloureux, en particulier sur des baies presque complètes ; il est tout à fait possible qu'une telle tâche nécessite une semaine ou plus, les performances de la baie étant limitées à un quart ou moins de la normale tout le temps.
Historiquement, ZFS a évité ce type d'expansion. ZFS a été développé à l'origine pour une utilisation professionnelle, et le remodelage des baies en direct est généralement un non-starter dans le monde des affaires. Réduire les performances de votre stockage à des niveaux inutilisables pendant des jours coûte généralement plus cher en salaires et en frais généraux que l'achat d'un tout nouvel ensemble de matériel. L'expansion en direct est également potentiellement très dangereuse car elle implique la lecture et la réécriture de toutes les données et met le tableau dans une condition temporaire et beaucoup moins bien testée "moitié ceci, moitié cela" jusqu'à ce qu'elle se termine.
Pour les utilisateurs disposant de nombreux disques, le nouveau
RAIDz
Il est peu probable que l'expansion change de manière significative la façon dont ils utilisent ZFS. Il sera toujours à la fois plus simple et plus pratique à gérer
vdev
comme des unités complètes plutôt que d'essayer de fouiner à l'intérieur. Mais les amateurs, les homelabbers et les petits utilisateurs qui exécutent ZFS avec un seul
vdev
tirera probablement beaucoup parti de la nouvelle fonctionnalité.
Comment ça marche?
Agrandir
/
Dans cette diapositive, nous voyons un RAIDz1 à quatre disques (à gauche) étendu à un RAIDz1 à cinq disques (à droite). Notez que les données sont toujours écrites en quatre bandes larges !
Matthieu Ahrens
D'un point de vue pratique, le nouveau
vdev
la fonction d'extension ajoute simplement de nouvelles capacités à une commande existante, à savoir,
zpool attacher
, qui est normalement utilisé pour ajouter un disque à un seul disque
vdev
(en le transformant en un
miroir vdev
) ou ajouter un disque supplémentaire à un
miroir
(par exemple, tourner un disque à deux
miroir
dans un trois disques
miroir
).
Publicité
Avec le nouveau code, vous pourrez
attacher
de nouveaux disques sur un disque existant
RAIDz
vdev aussi. Cela étend le vdev en largeur mais ne change pas le
vdev
tapez, de sorte que vous pouvez tourner un six-disque
RAIDz2
vdev dans un sept disques
RAIDz2
vdev, mais vous
ne peut pas
le transformer en un sept disques
RAIDz3
.
Lors de la délivrance de votre
zpool attacher
commande, l'expansion commence. Au cours de l'expansion, chaque
bloquer
ou
enregistrer
est lu à partir du
vdev
étendu et est ensuite réécrit. Les secteurs de la réécriture
bloquer
sont répartis entre tous les disques du
vdev
, y compris le(s) nouveau(x) disque(s), mais la largeur de la bande elle-même n'est pas modifiée. Donc un
vdev RAIDz2
étendu de six disques à dix sera toujours plein de bandes de six larges une fois l'extension terminée.
Ainsi, alors que l'utilisateur verra l'espace supplémentaire rendu disponible par les nouveaux disques, l'efficacité de stockage des données étendues ne se sera pas améliorée en raison des nouveaux disques. Dans l'exemple ci-dessus, nous sommes passés d'un système à six disques
RAIDz2
avec une efficacité de stockage nominale de 67 % (quatre secteurs sur six sont des données) sur dix disques
RAIDz2
. Données
nouvellement
écrites sur les dix disques RAIDz2 a une efficacité de stockage nominale de 80 %—huit secteurs sur dix sont des données—mais les anciennes données étendues sont toujours écrites sur six bandes larges, elles ont donc toujours l'ancienne efficacité de stockage de 67 %.
Il convient de noter qu'il ne s'agit pas d'un état inattendu ou bizarre pour un vdev—
RAIDz
utilise déjà une largeur de bande dynamique et variable pour tenir compte
blocs
ou
enregistrements
trop petit pour rayer tous les disques en un seul
vdev
.
Par exemple, si vous écrivez un seul bloc de métadonnées (les données contenant le nom, les autorisations et l'emplacement d'un fichier sur le disque), il tient dans un seul
secteur
sur disque. Si vous écrivez ce bloc de métadonnées dans un bloc de dix
RAIDz2
, vous n'écrivez pas une bande complète de
dix de large - à la place, vous écrivez une sous-dimensionnéebloquer
seulement trois disques de large ; une seule donnée
secteur
plus deux parité
secteurs
. Donc le "sous-dimensionné"
blocs
dans une nouvelle extension
RAIDz
vdev n'est pas un sujet de confusion pour ZFS. Ils sont juste un autre jour au bureau.
Y a-t-il un impact durable sur les performances ?
Comme nous l'avons vu ci-dessus, une nouvelle version élargie
RAIDz vdev
ne ressemblera pas tout à fait à une conception conçue de cette façon dès la "naissance" - du moins, pas au début. Bien qu'il y ait plus de disques dans le mix, la structure interne des données n'est pas modifiée.
Ajout d'un ou plusieurs nouveaux disques au
vdev
signifie qu'il devrait être capable d'un débit un peu plus élevé. Même si l'héritage
blocs
ne couvrent pas toute la largeur du
vdev
, les disques ajoutés signifient plus de broches pour répartir le travail. Cela ne fera probablement pas augmenter la vitesse à couper le souffle, cependant - six bandes larges sur un sept disques
vdev
signifie que vous ne pouvez toujours pas lire ou écrire deux
blocs
simultanément, de sorte que toute amélioration de la vitesse est susceptible d'être mineure.
L'impact net sur les performances peut être difficile à prévoir. Si vous étendez à partir d'un six disques
RAIDz2
sur un sept disques
RAIDz2
, par exemple, votre configuration d'origine à six disques n'avait besoin d'aucun remplissage. Un 128Ko
bloquer
peut être coupé uniformément en quatre morceaux de données de 32KiB, avec deux morceaux de parité de 32KiB. Le même record partagé entre
Sept
les disques nécessitent un rembourrage car 128 Ko/cinq éléments de données ne sortent pas sur un nombre pair de secteurs.
Publicité
De même, dans certains cas, en particulier avec un petit
taille d'enregistrement
ou
tailleblocvol
set : la charge de travail par disque individuel peut être nettement moins difficile dans l'ancienne configuration plus étroite que dans la plus récente et plus large. Un 128Ko
bloquer
divisé en morceaux de 32KiB pour une largeur de six
RAIDz2
peut être lu ou écrit plus efficacement
par disque
qu'un divisé en morceaux de 16KiB pour une dizaine de large
RAIDz2
, par exemple, c'est donc un peu fou si plus de disques mais des morceaux plus petits fourniront plus de débit que moins de disques mais des morceaux plus gros.
La seule chose dont vous pouvez être certain, c'est que la nouvelle configuration étendue devrait généralement fonctionner aussi bien que la version originale non étendue et qu'une fois que la majorité des données est (ré)écrite dans la nouvelle largeur, la
vdev
ne fonctionnera pas différemment ou ne sera pas moins fiable que celui qui a été conçu de cette façon dès le départ.
Pourquoi ne pas remodeler les enregistrements/blocs pendant l'expansion ?
Il peut sembler étrange que le processus d'expansion initial ne réécrive pas tous les
blocs
à la nouvelle largeur pendant son exécution - après tout, il lit et réécrit les données de toute façon, n'est-ce pas ? Nous avons demandé à Ahrens pourquoi la largeur d'origine avait été laissée telle quelle, et la réponse se résume à "c'est plus facile et plus sûr de cette façon".
Un facteur clé à reconnaître est que techniquement, l'expansion
n'est pas
en mouvement
blocs
; ça bouge juste
secteurs
. La façon dont il est écrit, le code d'extension n'a pas besoin de savoir où la logique de ZFS
bloquer
les limites sont—la routine d'expansion n'a aucune idée si un individu
secteur
est la parité ou les données, sans parler de ce qui
bloquer
il appartient à.
L'expansion pourrait traverser tous les
bloquer
pointeurs pour localiser
bloquer
limites, et
alors
il saurait lequel
secteur
appartient à quoi
bloquer
et comment remodeler le
bloquer
, mais selon Ahrens, faire les choses de cette façon serait extrêmement envahissant pour le format sur disque de ZFS. L'extension devrait être continuellement mise à jour
cartes de l'espace
au
métadalles
pour tenir compte des changements dans la taille sur disque de chaque
bloquer
- et si le
bloquer
fait partie d'un
base de données
Plutôt qu'un
zvol
, mettez également à jour la comptabilisation de l'espace par jeu de données et par fichier.
Si cela vous démange vraiment de savoir que vous avez quatre bandes larges sur un vdev fraîchement cinq larges, vous pouvez simplement lire et réécrire vos données vous-même une fois l'expansion terminée. La façon la plus simple de le faire est d'utiliser
instantané zfs
,
zfs envoyer
, et
zfs recevoir
reproduire l'intégralité
ensembles de données
et
zvols
. Si les propriétés ZFS ne vous inquiètent pas, un simple
mv
l'opération fera l'affaire.
Cependant, nous vous recommandons dans la plupart des cas de vous détendre et de laisser ZFS faire son travail. Votre sous-dimensionné
blocs
à partir de données plus anciennes ne nuisent vraiment à rien, et comme vous supprimez et/ou modifiez naturellement des données au cours de la vie du
vdev
, la plupart d'entre eux seront réécrits naturellement si nécessaire, sans avoir besoin d'une intervention de l'administrateur ou de longues périodes de charge de stockage élevée en raison de la lecture et de la réécriture obsessionnelle de tout en même temps.
Quand l'extension RAIDz arrivera-t-elle en production ?
Le nouveau code d'Ahrens ne fait encore partie d'aucune version d'OpenZFS, et encore moins ajouté aux référentiels de quiconque. Nous avons demandé à Ahrens quand nous pourrions nous attendre à voir le code en production, et malheureusement, cela prendra un certain temps.
Il est trop tard pour que l'extension RAIDz soit incluse dans la prochaine version OpenZFS 2.1, attendue très bientôt (la version 2.1 release candidate 7 est disponible dès maintenant). Il devrait être inclus dans la prochaine version majeure d'OpenZFS ; il est trop tôt pour des dates concrètes, mais les versions majeures se produisent généralement environ une fois par an.
D'une manière générale, nous nous attendons à ce que l'expansion de RAIDz atteigne la production comme Ubuntu et FreeBSD vers août 2022, mais ce n'est qu'une supposition. TrueNAS peut très bien le mettre en production plus tôt que cela, car ixSystems a tendance à extraire les fonctionnalités ZFS du maître avant qu'elles n'atteignent officiellement le statut de version.
Matt Ahrens a présenté l'extension RAIDz au FreeBSD Developer Summit—son discours commence à 1 heure 41 minutes dans cette vidéo.
