Azure Native Qumulo Maintenant disponible dans l'UE, au Royaume-Uni et au Canada - En savoir plus

Comment mettre en œuvre le codage à effacement

Rédigé par:

Cette histoire vous vient en tant que partie 2 de 2 dans une courte série couvrant codage d'effacement et RAID, deux des méthodes les plus connues pour la protection des données dans les systèmes de stockage. Ci-dessous, nous expliquerons comment le système de fichiers distribué de Qumulo modernise les méthodes de stockage du codage à effacement avec une protection par blocs, et nous explorerons comment implémenter le codage à effacement dans un système de stockage de fichiers. 

Qumulo Core, le fondation du système de fichiers distribué de Qumulo, fournit un stockage de données extrêmement fiable (mesuré en dizaines de milliers d'années de fiabilité). Nous y parvenons en partie grâce à un codage d'effacement efficace, qui est l'un des nombreux services de données fournis en standard avec Qumulo Core, conçu pour protéger vos données.

Implémentation du codage d'effacement dans les systèmes de stockage de fichiers

Il y a de nombreuses considérations pratiques à prendre en compte lors de la mise en œuvre codage d'effacement dans les systèmes de stockage de fichiers. Pour faciliter le processus d'écriture des blocs de parité requis (et pour restaurer les données en cas de panne d'un disque), Bloc de stockage évolutif (SBS) divise son espace d'adressage virtuel de blocs de parité 4K en segments logiques appelés magasins protégés, ou pstores.

 

SBS gère chaque pstore individuellement, ce qui rend plus flexible le schéma de mappage associant l'espace d'adressage protégé aux disques. Tous les magasins ont la même taille. La protection des données est entièrement mise en œuvre au niveau pstore du système. Un pstore peut être considéré comme une table qui mappe des plages d'adresses de bloc virtuel protégées à des régions de stockage contiguës résidant sur des disques virtuels des noeuds du cluster Qumulo.

Les régions contiguës sont appelées bstores. La mappe de pstores à bstores est stockée par chaque nœud du cluster.

pstore contre bstore, quelle est la différence?
  • pstore: Espace d'adressage virtuel divisé en blocs de 4K.
  • bstore: Régions contiguës des blocs virtuels. (les pstores correspondent aux bstores.)[/box]

Pour plus de fiabilité, les nœuds du cluster utilisent un algorithme distribué appelé Paxos pour maintenir un consensus sur les connaissances partagées à l'échelle mondiale, telles que la carte pstore-to-bstore. Le cluster forme un quorum de nœuds pour assurer la sécurité des structures de données critiques du cluster. Chaque bstore utilise un segment d'un disque virtuel spécifique (c'est-à-dire que le bstore est associé à une paire SSD et HDD particulière).

Un espace contigu est attribué à chaque bstore sur le disque dur associé, tandis que l’espace sur le disque SDD associé au bstore est alloué de manière dynamique. Des métadonnées sur un magasin de stockage existent également sur son disque SSD associé. Les métadonnées Bstore incluent des informations telles que les adresses utilisées et une carte qui indique les adresses de bloc dans le stockage SSD de référence bstore et celles qui se trouvent sur le disque dur.

Lors d'une lecture ou d'une écriture, le pstore est utilisé pour décider quels bstores doivent être accédés. Lorsqu'un client du système de fichiers lance une opération d'écriture, celle-ci entre dans SBS sous forme de flux de données brutes. Le système détermine dans quels bstores écrire les données, calcule les données de parité et écrit à la fois les données brutes et les données de parité sur les SSD, même si les SSD se trouvent sur de nombreux nœuds différents. Une fois les données écrites, le client reçoit un accusé de réception que l'écriture a eu lieu.

Les blocs de données qui contiennent des données utilisateur et des blocs de parité sont tous deux écrits dans des bstores. Un bstore particulier, pendant sa durée de vie, contient soit des blocs de parité, soit des blocs de données, mais pas les deux. Étant donné que le codage d'effacement est implémenté au niveau de la couche pstore de SBS, les bstores qui contiennent des blocs de parité et les bstores qui contiennent des blocs de données se comportent de manière identique. La quantité de stockage allouée à un bstore dépend du schéma de codage d'effacement en place. Pour que la taille du pstore reste cohérente, la taille du bstore du système change en fonction du schéma de codage. Par exemple, si le pstore fait 70 Go, alors, avec un encodage 6,4, chaque bstore fait environ 17.5 Go, ce qui divise le pstore en 4 bstores. Pour l'encodage 10,8, les bstores auront environ la moitié de cette taille.

Dans le cloud, Qumulo utilise le même schéma de protection des données que sur site, à une exception près. Sur site, le schéma de protection des données requiert qu'il y ait au moins quatre nœuds dans un cluster. Dans le cloud, il est possible d'avoir un cluster à nœud unique, car le système de fichiers de Qumulo peut utiliser la mise en miroir intégrée qui se trouve dans chaque bloc de stockage élastique. Les clusters Qumulo à nœud unique dans le cloud utilisent le codage d'effacement 5,4.

Jamais en bas pour le compte

Les temps de reconstruction de Qumulo sont mesurés en heures. En revanche, les systèmes de stockage hérités conçus pour les charges de travail avec beaucoup moins de données, ont des temps de reconstruction qui sont mesurés en jours, et certains plus longtemps que cela.

Un grand nombre de fichiers, des charges de travail mixtes et une densité de disque croissante ont tous contribué à la crise des temps de reconstruction pour les appliances de stockage héritées. L'avantage considérable de Qumulo est le résultat direct de la protection avancée basée sur les blocs de SBS. La protection par blocs est idéale pour les charges de travail modernes d'aujourd'hui où il y a des pétaoctets de données et des millions ou des milliards de fichiers, dont beaucoup sont petits.

Le système de protection SBS n'a pas besoin de faire des parcours d'arborescence ou des opérations de reconstruction fichier par fichier. Au lieu de cela, les opérations de reconstruction fonctionnent sur les pstores. Le résultat est que les temps de reconstruction ne sont pas affectés par la taille du fichier. Les petits fichiers sont traités aussi efficacement que les gros fichiers, et il est tout à fait possible de protéger des milliards de fichiers. De plus, le système de fichiers de Qumulo est conçu pour que les temps de reconstruction ne soient pas affectés négativement par la taille du cluster. En fait, le contraire est vrai. Avec Qumulo, les clusters plus volumineux ont en fait des temps de reconstruction plus rapides que les clusters plus petits.

[type de boîte = "ombre"]REMARQUE: Contrairement au stockage hérité, Qumulo répartit les efforts de reconstruction sur les nœuds du cluster, ce qui entraîne des temps de reconstruction plus rapides que le stockage hérité. Et plus le cluster est grand, plus la reconstruction est rapide.[/box]

La raison en est que SBS répartit l'effort de calcul de reconstruction sur les nœuds du cluster. Plus il y a de nœuds, moins chaque nœud doit travailler pendant une reconstruction. Les appliances de stockage héritées avec des temps de reconstruction lents risquent de perdre des données si elles subissent des pannes supplémentaires pendant la période où le système est déjà vulnérable lors d'un processus de reconstruction prolongé.

En d'autres termes, des temps de reconstruction lents ont un impact négatif sur la fiabilité. En règle générale, les administrateurs compensent cela en surprovisionnant (c'est-à-dire en diminuant l'efficacité en ajoutant une redondance des données). Avec les temps de reconstruction rapides de Qumulo, les administrateurs peuvent maintenir leur Temps moyen de perte de données (MTTDL) cibles sans beaucoup de redondance de données, économisant à la fois de l'argent et du temps.

Reconstruire les pstores en cas de panne de disque

Lorsqu'un disque tombe en panne, le magasin protégé existe toujours. Il peut toujours être lu et écrit à partir de. Cependant, certains pstores auront des bstores manquants ou endommagés. Ceux-ci sont appelés pstores dégradés. En raison du codage d'effacement, vous pouvez continuer à lire les pstores dégradés, mais les données ne sont plus entièrement protégées. En d'autres termes, au premier échec, vous avez toujours l'intégrité des données mais êtes un panne de disque plus proche de la perte de données. Pour reprotéger les données, le système fonctionne pstore par pstore (plutôt que fichier par fichier dans les systèmes RAID hérités) pour reconstruire les bstores qui se trouvaient sur le lecteur de disque défaillant.

SBS alloue une petite quantité d'espace disque supplémentaire, il y a donc de la place pour le faire. C'est ce qu'on appelle l'épargne. Étant donné que la carte globale pstore-to-bstore contient l'ID du disque virtuel associé au bstore, ces informations permettent de savoir facilement quels pstore doivent être traités en cas de défaillance d'un disque particulier. Étant donné que la carte qui associe les pstores aux bstores est suffisamment petite pour résider dans la mémoire de chaque nœud, les nœuds peuvent traduire rapidement les adresses de blocs virtuels de pstore en bstore.

Pendant le processus de reconstruction, SBS lit et écrit les bstores de manière séquentielle. Étant donné que les bstores sont disposés de manière contiguë sur le disque, les pstores dégradés peuvent être reconstruits très rapidement. Les opérations séquentielles sont beaucoup plus rapides que de nombreuses petites opérations d'E/S, qui peuvent être lentes et provoquer des conflits de disque. Le processus de reconstruction de SBS est efficace : les disques sont impliqués dans exactement un flux de lecture ou d'écriture à la fois pendant le processus de reconstruction. Aucune E/S aléatoire n'est requise.

De plus, les magasins de base sont suffisamment petits pour que le travail de re-protection soit efficacement réparti sur l'ensemble du cluster.

Business as usual - même pendant les reconstructions

Dans les systèmes de fichiers hérités, les conflits de verrouillage affectent les temps de reconstruction et ralentissent les opérations du système de fichiers standard pendant la reconstruction. Cela est dû au fait que ces opérations sur les fichiers sont en concurrence avec les threads de reconstruction/reprotection. Qumulo utilise une couche d'écriture avec des schémas de verrouillage indépendants afin que les opérations de reconstruction ne soient pas en conflit avec l'utilisation normale du système de fichiers.

En cas d'échec, cela n'a aucun sens d'écrire dans l'ensemble incomplet de bstores dans les pstores dégradés. Les nouvelles écritures ne seraient pas entièrement protégées et cela compliquerait le travail de reconstruction du bstore. Cependant, le cluster ne doit pas subir de temps d'arrêt pendant l'opération de reconstruction et, par conséquent, les opérations d'écriture lancées par l'utilisateur ne peuvent pas attendre qu'un pstore soit à nouveau protégé. Pour effectuer ces écritures, le système ajoute une nouvelle couche de bstores virtuels au pstore dégradé. C'est ce qu'on appelle « pousser une couche ». Les écritures vont à la nouvelle couche de bstores et les lectures combinent les valeurs de chaque couche.

Les nouvelles écritures vont dans la couche supérieure des bstores. Une lecture combine les valeurs de la couche supérieure et de la couche inférieure en utilisant un codage d'effacement. Une fois le bstore reconstruit, la couche push disparaît. Les couches sont construites à l'aide de composants du système de transaction de SBS d'une manière qui les rend non bloquantes.

Efficacité du stockage de petits fichiers

Comme le système de fichiers Qumulo utilise une protection par bloc, les petits fichiers sont aussi efficaces que les gros.

Ils peuvent partager des bandes avec d'autres fichiers et partager la protection. Chaque fichier est constitué des blocs de données, d'au moins un bloc inode et de tous les autres blocs requis. De très petits fichiers sont alignés dans le bloc inode. Le système utilise des blocs 4K et tous les blocs sont protégés selon le rapport de protection du système.

Qumulo efficacité de stockage avec de petits fichiers est un gros avantage par rapport aux appliances de stockage héritées, qui utilisent une mise en miroir inefficace pour les petits fichiers et les métadonnées du système. Les systèmes de stockage existants utilisent également une taille de bloc de 8K, ce qui, avec de petits fichiers, peut créer de grandes inefficacités.

C'est votre espace de stockage - utilisez-en 100 %

Les fichiers utilisateur Qumulo peuvent occuper 100 pour cent de la capacité provisionnée, tandis que le scale-out hérité recommande de n'utiliser que 80 à 85 %. La protection basée sur les blocs de Qumulo ne nécessite aucune capacité fournie par l'utilisateur pour la reprotection, à l'exception d'une petite quantité d'espace de réserve, qui est exclue de la capacité fournie par l'utilisateur.

En revanche, les appliances de stockage héritées mettent en œuvre une protection soit avec des groupes RAID fixes, soit avec un codage d'effacement fichier par fichier, ce qui signifie que la reprotection se produit également au niveau du fichier et nécessite une capacité de récupération fournie par l'utilisateur. (Voir codage d'effacement vs RAID expliqué pour plus de détails.) De plus, le système de fichiers Qumulo rapporte avec précision la capacité disponible pour les fichiers utilisateur.

Là encore, cette prévisibilité est une conséquence de la protection par bloc. Dans les systèmes hérités, l'utilisation du stockage dépend de la taille du fichier. Par conséquent, ces systèmes ne peuvent générer des rapports que sur l'espace brut. Les administrateurs doivent alors deviner leur espace réel. Lorsque vous comparez Qumulo à des systèmes existants, vous voudrez certainement prendre en compte la capacité réellement disponible pour les utilisateurs et pouvant être utilisée dans chaque type de système.

Note de l'éditeur : initialement publié le 11 novembre 2021, cet article a été mis à jour pour plus d'exactitude et d'exhaustivité.

Articles Similaires

Remonter en haut