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

Présentation technique du fichier cloud hybride Qumulo

Résumé : Qumulo File Fabric (QF2) est un système de stockage de fichiers moderne et hautement évolutif qui couvre le centre de données et le cloud public. Il s'adapte à des milliards de fichiers, coûte moins cher et a un coût total de possession inférieur à celui des anciennes appliances de stockage. C'est également le système de stockage de fichiers le plus performant sur site et dans le cloud. Ses analyses intégrées en temps réel permettent aux administrateurs de gérer facilement les données, quelle que soit leur empreinte ou leur emplacement dans le monde. Lorsque les gens voient QF2 en action pour la première fois, ils demandent souvent : "Comment peut-il faire cela ?" Cet article répond à cette question. Nous allons passer sous le capot et expliquer certaines des techniques avancées qui donnent à QF2 ses capacités uniques.

Stockage moderne et hautement évolutif

Qumulo File Fabric (QF2) est un système de stockage de fichiers moderne et hautement évolutif qui couvre le centre de données et le cloud public. Il s'adapte à des milliards de fichiers, coûte moins cher et a un coût total de possession inférieur à celui des anciennes appliances de stockage. C'est également le système de stockage de fichiers le plus performant sur site et dans le cloud. Ses analyses intégrées en temps réel permettent aux administrateurs de gérer facilement les données, quelle que soit leur empreinte ou leur emplacement dans le monde.

QF2 déplace les données de fichiers là où elles sont nécessaires quand elles sont nécessaires, par exemple, entre des clusters sur site et des clusters qui s'exécutent dans le cloud. QF2 vous permet de stocker et de gérer des ensembles de données volumineux, dans plusieurs environnements, partout dans le monde. Le logiciel de QF2 s'exécute sur du matériel standard de l'industrie sur site ou sur des instances cloud et des ressources de stockage cloud. QF2 a été conçu dès le départ pour répondre aux exigences actuelles d'évolutivité et de mobilité des données. Il s'agit du premier système de stockage de fichiers universel au monde.

Qumulo est un nouveau type de société de stockage, entièrement basé sur des logiciels avancés. Qumulo fait partie d'une tendance plus large de l'industrie des logiciels dont la valeur augmente par rapport au matériel. Le matériel de base exécutant des logiciels distribués avancés est la base incontestée de l'informatique moderne à faible coût et évolutive. Cela est tout aussi vrai pour le stockage de fichiers à grande échelle.

Lorsque les gens voient QF2 en action pour la première fois, ils demandent souvent : "Comment peut-il faire cela ?" Répondre à cette question est la raison d'être de cet article. Nous allons passer sous le capot et expliquer certaines des techniques avancées qui donnent à QF2 ses capacités uniques.

Mobilité des données, évolutivité linéaire et portée mondiale

Pour l'évolutivité, QF2 a une architecture distribuée où de nombreux nœuds informatiques individuels fonctionnent ensemble pour former un cluster avec des performances évolutives et un système de fichiers unique et unifié. Les clusters QF2, à leur tour, fonctionnent ensemble pour former une structure de stockage distribuée à l'échelle mondiale mais hautement connectée, liée par des relations de réplication continues.

Les clients interagissent avec les clusters QF2 à l'aide de protocoles de fichiers standard, de l'API REST QF2 et d'une interface utilisateur graphique (GUI) Web pour les administrateurs de stockage.

Ce diagramme montre les connexions entre les clients, les clusters QF2 composés de nœuds exécutant Qumulo Core et plusieurs clusters QF2, comprenant la structure, s'exécutant dans plusieurs environnements et emplacements géographiques.

QF2 est un système modulaire. À mesure que les demandes augmentent sur un cluster QF2, vous ajoutez simplement des nœuds ou des instances. La capacité et les performances évoluent de manière linéaire, et cela est vrai que le cluster QF2 fonctionne dans un centre de données sur site ou dans le cloud public.

Ce qui est inclus dans QF2

QF2 comprend à la fois des logiciels et des services. Il est disponible avec une tarification par abonnement simple et transparente. Voici un schéma de ce qui est inclus dans un abonnement QF2. Qumulo Core est le logiciel qui s'exécute sur chaque nœud d'un cluster QF2. Il comprend de puissantes analyses en temps réel et des quotas de capacité, ainsi qu'une réplication continue et des instantanés. Ces fonctionnalités reposent sur le système de fichiers hautement évolutif QF2 qui, contrairement à d'autres systèmes, inclut une agrégation intégrée en temps réel des métadonnées de fichiers.

Le système de fichiers QF2 repose sur un puissant système de gestion de données de pointe appelé Qumulo Scalable Block Store (SBS). SBS utilise les principes des bases de données distribuées massivement évolutives et est optimisé pour les besoins spécialisés des données basées sur des fichiers. Le magasin de blocs évolutif est la couche de blocs du système de fichiers QF2, ce qui rend ce système de fichiers plus simple à mettre en œuvre et extrêmement robuste. SBS offre également au système de fichiers une évolutivité massive, des performances optimisées et une protection des données.

QF2 fournit une surveillance et une analyse des tendances basées sur le cloud dans le cadre de l'abonnement QF2, ainsi qu'un support client complet. La surveillance du cloud inclut la détection proactive d'événements tels que les pannes de disque pour prévenir les problèmes avant qu'ils ne surviennent. L'accès aux tendances historiques permet de réduire les coûts et d'optimiser les flux de travail pour une utilisation optimale de votre investissement de stockage.

Votre choix d'environnements d'exploitation

Le logiciel Qumulo Core s'exécute dans le cloud public et sur du matériel standard de l'industrie dans votre centre de données. Qumulo Core fonctionne actuellement sur la propre série QC de serveurs boîte blanche de Qumulo et sur les serveurs Apollo de Hewlett-Packard Enterprise (HPE). Étant donné que QF2 est indépendant du matériel, il ne dépend d'aucun fournisseur de matériel et, en fait, vous pouvez vous attendre à ce que Qumulo ajoute la prise en charge des serveurs d'un certain nombre d'OEM.

L'approche logicielle uniquement de QF2 signifie qu'il n'y a aucune dépendance vis-à-vis de composants propriétaires coûteux tels que la NVRAM, les commutateurs InfiniBand et le stockage flash propriétaire. Au lieu de cela, QF2 s'appuie sur des disques durs (HDD) et des disques SSD avec un micrologiciel standard disponible auprès des fabricants de disques. La combinaison de disques SSD et de disques durs standard pour la hiérarchisation automatique des données chaudes et froides est l'une des raisons pour lesquelles QF2 offre des performances flash au prix du stockage d'archives.

Vous pouvez également créer des clusters QF2 dans le cloud public (actuellement, AWS). Les nœuds des clusters QF2 basés sur le cloud exécutent le même logiciel Qumulo Core que les clusters QF2 sur site. Contrairement à d'autres systèmes de stockage de fichiers basés sur le cloud, un cluster QF2 exécuté dans le cloud public n'a pas de limites strictes en termes de performances et de capacité. Les deux peuvent être augmentés en ajoutant des nœuds (instances de calcul et stockage de blocs). QF2 est la seule solution pour le cloud qui vous permet d'adapter de manière flexible à la fois la capacité et les performances.

Lorsqu'il s'exécute dans le cloud, QF2 utilise le stockage en bloc dans le cloud d'une manière similaire à la combinaison SSD/HDD sur site. QF2 utilise le stockage en bloc à faible latence comme cache devant le stockage en bloc économique à latence plus élevée. Dans le reste de l'article, nous parlerons des disques SSD et des disques durs, mais les concepts abordés s'appliquent également à l'utilisateur de QF2 de ressources de stockage de blocs à latence plus faible et plus élevée dans le cloud public.

Sur chaque nœud d'un cluster QF2, Qumulo Core s'exécute dans l'espace utilisateur Linux plutôt que dans l'espace noyau. Le mode noyau est principalement destiné aux pilotes de périphériques qui fonctionnent avec un matériel spécifique. En fonctionnant dans l'espace utilisateur, QF2 peut fonctionner dans une grande variété de configurations et d'environnements, et également fournir des fonctionnalités à un rythme beaucoup plus rapide.

L'exécution dans l'espace utilisateur signifie également que QF2 peut avoir ses propres implémentations de protocoles cruciaux tels que SMB, NFS, LDAP et Active Directory. Par exemple, l'implémentation de NFS par QF2 s'exécute en tant que service système et a ses propres notions d'utilisateurs et de groupes distincts du système d'exploitation sous-jacent sur lequel il s'exécute.

L'exécution dans l'espace utilisateur améliore également la fiabilité de QF2. En tant que processus indépendant de l'espace utilisateur, QF2 est isolé des autres composants du système qui pourraient introduire une corruption de la mémoire, et les processus de développement QF2 peuvent utiliser des outils avancés de vérification de la mémoire qui permettent de détecter les erreurs de codage liées à la mémoire avant la publication du logiciel. En utilisant une stratégie à double partition pour les mises à niveau logicielles, Qumulo peut automatiquement mettre à jour le système d'exploitation et le logiciel Qumulo Core pour des mises à niveau rapides et fiables. Vous pouvez facilement redémarrer QF2 sans avoir à redémarrer le système d'exploitation, le nœud ou le cluster.

Fichiers et répertoires massivement évolutifs

Lorsque vous avez un grand nombre de fichiers, la structure des répertoires et les attributs des fichiers eux-mêmes deviennent des mégadonnées. Par conséquent, les processus séquentiels tels que les parcours d'arborescence, qui sont fondamentaux pour le stockage hérité, ne sont plus réalisables en termes de calcul. Au lieu de cela, interroger un système de fichiers volumineux et le gérer nécessite une nouvelle approche qui utilise des algorithmes parallèles et distribués.

QF2 fait exactement cela. Il est unique dans la façon dont il aborde le problème de l'évolutivité. Sa conception met en œuvre des principes similaires à ceux utilisés par les bases de données distribuées modernes à grande échelle. Le résultat est un système de fichiers avec des caractéristiques d'échelle inégalées. En revanche, les appliances de stockage héritées n'ont tout simplement pas été conçues pour gérer l'ampleur massive de l'encombrement des données d'aujourd'hui.

Le système de fichiers QF2 repose sur une couche de blocs virtualisée appelée SBS. Dans QF2, les tâches chronophages telles que la protection, les reconstructions et le choix des disques contenant les données se produisent dans la couche SBS, sous le système de fichiers. (Nous parlerons plus en détail des blocs virtuels protégés et des transactions plus tard dans l'article.)

La fonctionnalité de bloc protégé virtualisé de SBS est un énorme avantage pour le système de fichiers QF2. Dans les systèmes de stockage hérités qui n'ont pas de SBS, la protection s'effectue fichier par fichier ou à l'aide de groupes RAID fixes, ce qui introduit de nombreux problèmes difficiles tels que des temps de reconstruction longs, un stockage inefficace de petits fichiers et une gestion coûteuse des dispositions de disque. Sans couche de bloc virtualisée, les systèmes de stockage hérités doivent également mettre en œuvre la protection des données au sein de la couche de métadonnées elle-même, et cette complexité supplémentaire limite la capacité de ces systèmes à optimiser les transactions distribuées pour leurs structures de données d'annuaire et leurs métadonnées.

Pour l'évolutivité des fichiers et des répertoires, le système de fichiers QF2 utilise largement les structures de données d'index connues sous le nom de Arbres B. Les arbres B sont particulièrement bien adaptés aux systèmes qui lisent et écrivent un grand nombre de blocs de données car ce sont des structures de données « peu profondes » qui minimisent la quantité d'E/S requises pour chaque opération à mesure que la quantité de données augmente. Avec les arbres B comme base, le coût de calcul de la lecture ou de l'insertion de blocs de données augmente très lentement à mesure que la quantité de données augmente. Les arbres B sont idéaux pour les systèmes de fichiers et les index de bases de données très volumineux, par exemple.

Dans QF2, les arbres B sont basés sur des blocs. Chaque bloc est de 4096 octets. Voici un exemple qui montre la structure d'un B-tree.

Chaque bloc 4K peut avoir des pointeurs vers d'autres blocs 4K. Cet arbre B particulier a un facteur de branchement de 3, où un facteur de branchement est le nombre d'enfants (sous-nœuds) à chaque nœud de l'arbre.

Même s'il y a des millions de blocs, la hauteur d'un arbre B dans SBS, de la racine jusqu'à l'emplacement des données, peut n'être que de deux ou trois niveaux. Par exemple, dans le diagramme, pour rechercher l'étiquette q avec la valeur d'index 1, le système ne parcourt que deux niveaux de l'arbre.

Le système de fichiers QF2 utilise des arbres B à de nombreuses fins différentes.

Il y a un inode B-tree, qui agit comme un index de tous les fichiers. La liste d'inodes est une technique d'implémentation de système de fichiers standard qui rend la vérification de la cohérence du système de fichiers indépendante de la hiérarchie des répertoires. Les inodes aident également à rendre efficaces les opérations de mise à jour telles que les déplacements de répertoires.

Les fichiers et les répertoires sont représentés sous forme d'arborescences B avec leurs propres paires clé/valeur, telles que le nom du fichier, sa taille et sa liste de contrôle d'accès (ACL) ou ses autorisations POSIX.

Les données de configuration sont également un arbre B et contiennent des informations telles que l'adresse IP et le cluster.

En fait, le système de fichiers QF2 peut être considéré comme un arbre d'arbres. Voici un exemple.

L'arbre de niveau supérieur est appelé le super arbre B. Lorsque le système démarre, le traitement commence là. La racine est toujours stockée à la première adresse (« paddr 1.1 ») du tableau de blocs virtuels protégés. L'arbre racine fait référence à d'autres arbres B. Si le système de fichiers QF2 a besoin d'accéder aux données de configuration, par exemple, il accède à l'arborescence B de configuration. Pour trouver un fichier particulier, le système interroge l'arbre B d'inodes en utilisant le numéro d'inode comme index. Le système parcourt l'arbre d'inodes jusqu'à ce qu'il trouve le pointeur vers le fichier B-tree. À partir de là, le système de fichiers peut rechercher n'importe quoi sur le fichier. Les répertoires sont traités comme des fichiers.

S'appuyer sur des arbres B qui pointent vers un stockage de blocs protégé virtualisé dans SBS est l'une des raisons pour lesquelles dans QF2 un système de fichiers avec un billion de fichiers est réalisable.

Visibilité et contrôle en temps réel avec QumuloDB

QF2 est conçu pour faire plus que stocker des données de fichiers. Il vous permet également de gérer vos données et vos utilisateurs en temps réel. Les administrateurs d'appliances de stockage héritées sont gênés par la « cécité des données ». Ils ne peuvent pas obtenir une image précise de ce qui se passe dans leur système de fichiers. QF2 est conçu pour donner exactement ce type de visibilité, quel que soit le nombre de fichiers et de répertoires. Vous pouvez, par exemple, obtenir un aperçu immédiat des tendances de débit et des hotspots. Vous pouvez également définir des quotas de capacité en temps réel, ce qui évite la surcharge de provisionnement de quota chronophage du stockage hérité. Les informations sont accessibles via une interface utilisateur graphique et il existe également une API REST qui vous permet d'accéder aux informations par programmation.

Les fonctionnalités d'analyse intégrées du système de fichiers QF2 sont fournies par un composant appelé QumuloDB.

Lorsque les gens découvrent les analyses en temps réel de QF2 et les regardent effectuer à grande échelle, leur première question est généralement : "Comment cela peut-il être si rapide ?" Les performances révolutionnaires des analyses en temps réel de QF2 sont possibles pour trois raisons.

Premièrement, dans le système de fichiers QF2, les analyses QumuloDB sont intégrées et entièrement intégrées au système de fichiers lui-même. Dans les systèmes hérités, les requêtes de métadonnées reçoivent une réponse en dehors du système de fichiers principal par un composant logiciel indépendant.

Deuxièmement, comme le système de fichiers QF2 repose sur des arbres B, l'analyse QumuloDB peut utiliser un système innovant d'agrégats en temps réel, que nous décrivons dans la section suivante.

Enfin, les analyses QumuloDB sont possibles car le système de fichiers QF2 a une conception simplifiée en raison de son utilisation des index B-tree et des blocs et transactions protégés virtualisés du Qumulo Scalable Block Store (SBS).

Agrégation de métadonnées en temps réel

Dans le système de fichiers QF2, les métadonnées telles que les octets utilisés et le nombre de fichiers sont agrégées au fur et à mesure que les fichiers et les répertoires sont créés ou modifiés. Cela signifie que les informations sont disponibles pour un traitement rapide, sans parcours coûteux de l'arborescence du système de fichiers.

QumuloDB maintient des résumés de métadonnées à jour. Il utilise les arbres B du système de fichiers
pour collecter des informations sur le système de fichiers au fur et à mesure que des modifications se produisent. Divers champs de métadonnées sont résumés dans le système de fichiers pour créer un index virtuel. Les analyses de performances que vous voyez dans l'interface graphique et que vous pouvez extraire avec l'API REST sont basées sur des mécanismes d'échantillonnage intégrés au système de fichiers QF2. Des techniques d'échantillonnage statistiquement valides sont possibles en raison de la disponibilité de résumés de métadonnées à jour qui permettent aux algorithmes d'échantillonnage de donner plus de poids aux répertoires et fichiers plus volumineux.

L'agrégation des métadonnées dans QF2 utilise une approche ascendante et descendante.

Au fur et à mesure que chaque fichier (ou répertoire) est mis à jour avec de nouvelles métadonnées agrégées, son répertoire parent est marqué « sale » et un autre événement de mise à jour est mis en file d'attente pour le répertoire parent. De cette manière, les informations du système de fichiers sont collectées et agrégées tout en étant transmises dans l'arborescence. Les métadonnées se propagent depuis l'inode individuel, au niveau le plus bas, jusqu'à la racine du système de fichiers lorsque les données sont accessibles en temps réel. Chaque opération de fichier et de répertoire est prise en compte, et ces informations se propagent finalement jusqu'au cœur même du système de fichiers. Voici un exemple.

L'arborescence de gauche regroupe les informations sur les fichiers et les répertoires et les intègre dans les métadonnées. Une mise à jour est ensuite mise en file d'attente pour le répertoire parent. L'information remonte, des feuilles à la racine.

Parallèlement à la propagation ascendante des événements de métadonnées, un parcours périodique commence au sommet du système de fichiers et lit les informations agrégées présentes dans les métadonnées. Lorsque le parcours trouve des informations agrégées récemment mises à jour, il élague sa recherche et passe à la branche suivante. Il suppose que les informations agrégées sont à jour dans l'arborescence du système de fichiers à partir de ce point vers les feuilles (y compris tous les fichiers et répertoires contenus) et n'ont pas besoin d'aller plus loin pour des analyses supplémentaires. La majeure partie du résumé des métadonnées a déjà été calculée et, idéalement, la traversée n'a besoin que de résumer un petit sous-ensemble des métadonnées pour l'ensemble du système de fichiers. En effet, les deux parties du processus d'agrégation se rencontrent au milieu sans qu'aucune n'ait à explorer l'arborescence complète du système de fichiers de haut en bas.

Requêtes d'échantillonnage et de métadonnées

Un exemple d'analyse en temps réel de QF2 est ses rapports sur les points chauds de performance. Voici un exemple de l'interface graphique.

Représenter chaque opération de débit et IOPS dans l'interface graphique serait irréalisable dans les grands systèmes de fichiers. Au lieu de cela, les requêtes QumuloDB utilisent un échantillonnage probabiliste pour fournir une approximation statistiquement valide de ces informations. Les totaux pour les opérations de lecture et d'écriture IOPS, ainsi que les opérations de lecture et d'écriture de débit d'E/S, sont générés à partir d'échantillons collectés à partir d'un tampon en mémoire de 4,096 XNUMX entrées qui est mis à jour toutes les quelques secondes.

Le rapport affiché ici affiche les opérations qui ont le plus grand impact sur le cluster. Ceux-ci sont représentés sous forme de points chauds dans l'interface graphique.

La capacité de QF2 à utiliser un échantillonnage probabiliste statistiquement valide n'est possible qu'en raison des métadonnées résumées pour chaque répertoire (octets utilisés, nombre de fichiers) qui sont continuellement mises à jour par QumuloDB. C'est un avantage unique des techniques logicielles avancées de QF2 que l'on ne trouve dans aucun autre système de stockage de fichiers.

Quotas en temps réel

Tout comme l'agrégation en temps réel des métadonnées permet l'analyse en temps réel de QF2, elle permet également des quotas de capacité en temps réel. Les quotas permettent aux administrateurs de spécifier la capacité qu'un répertoire donné est autorisé à utiliser pour les fichiers. Par exemple, si un administrateur voit qu'un utilisateur non autorisé provoque une croissance trop rapide d'un sous-répertoire, l'administrateur peut instantanément limiter la capacité du répertoire de cet utilisateur.

Dans QF2, les quotas sont déployés immédiatement et n'ont pas besoin d'être provisionnés. Ils sont appliqués en temps réel et les modifications de leurs capacités sont immédiatement mises en œuvre. Un avantage secondaire est que les quotas attribués aux répertoires se déplacent avec eux et que les répertoires eux-mêmes peuvent être déplacés vers et hors des domaines de quota.

Contrairement à certains autres systèmes, les quotas Qumulo ne nécessitent pas de diviser le système de fichiers en volumes. De plus, avec QF2, le déplacement d'un quota ou le déplacement de répertoires entre des domaines de quotas n'implique pas de longs parcours d'arborescence, de planification de tâches ou de processus fastidieux en plusieurs étapes. Les quotas dans QF2 peuvent être appliqués à n'importe quel répertoire, même ceux imbriqués. Si une allocation a plus d'un quota en raison de répertoires imbriqués, tous les quotas doivent être satisfaits afin d'allouer l'espace demandé.

Étant donné que les limites de quota dans QF2 sont enregistrées en tant que métadonnées au niveau du répertoire, les quotas peuvent être spécifiés à n'importe quel niveau de l'arborescence des répertoires. Lorsqu'une opération d'écriture se produit, tous les quotas pertinents doivent être satisfaits. Ce sont des limites strictes. La précision et l'agilité des quotas en temps réel de QF2 sont possibles car l'agrégateur intégré maintient continuellement à jour le résumé de la quantité totale de stockage utilisée par répertoire.

Instantanés

Les instantanés permettent aux administrateurs système de conserver l'état d'un système de fichiers ou d'un répertoire à un moment donné. Si un fichier ou un répertoire est modifié ou supprimé involontairement, les utilisateurs ou les administrateurs peuvent le rétablir dans son état enregistré.

Les instantanés dans QF2 ont une implémentation extrêmement efficace et évolutive. Un seul cluster QF2 peut avoir un nombre pratiquement illimité d'instantanés simultanés sans dégradation des performances ou de la capacité.

Les instantanés sont implémentés en tant qu'écritures de bloc hors place. Lorsqu'un instantané est pris et que des blocs sont modifiés, ils sont écrits dans une nouvelle colonne vertébrale de blocs B-tree. Les blocs existants qui n'ont pas été modifiés sont liés à la nouvelle colonne vertébrale et sont maintenant partagés. La nouvelle colonne vertébrale modifiée a été écrite "hors de propos" mais fait toujours référence aux données existantes, partageant les blocs inchangés. Aucun espace n'est utilisé par l'instantané tant que les données ne sont pas modifiées ou supprimées.

Par exemple, supposons que vous ajoutiez un fichier de 4 Mo au système de fichiers QF2, puis que vous preniez un instantané. Une fois l'instantané créé, la quantité de capacité utilisée n'est toujours que de 4 Mo. Ensuite, vous modifiez une région de 1 Mo de votre fichier. Les nouvelles données (1 Mo) sont écrites hors de leur place et associées à la version "live" du fichier. 3 Mo des 4 Mo de données d'origine sont partagés entre la version en direct et la version capturée dans l'instantané. L'utilisation totale du stockage pour ce fichier est maintenant de 5 Mo.

Les instantanés sont une fonction de sécurité qui aide à rendre le système de fichiers résilient au cas où les utilisateurs supprimeraient ou modifieraient par erreur des données de fichiers. Par exemple, si certaines données sont accidentellement supprimées, les utilisateurs peuvent récupérer des fichiers à partir d'un instantané pris précédemment. Des fichiers uniques ou des répertoires entiers peuvent être restaurés en les copiant dans le système de fichiers en direct.

Lorsque l'espace est insuffisant, les administrateurs décident souvent de supprimer des instantanés pour libérer de l'espace de stockage. Étant donné que les instantanés partagent des données, la suppression d'un instantané ne récupère généralement pas une quantité d'espace égale à la somme de tous les fichiers qu'il contient. Dans les systèmes hérités, il est difficile de savoir combien d'espace serait, en fait, récupéré.

Les instantanés dans QF2 tirent parti de l'intelligence intégrée au système de fichiers. Les administrateurs peuvent calculer la quantité de stockage qui serait réellement récupérée s'ils supprimaient un ensemble d'instantanés.

Réplication continue

QF2 fournit une réplication continue sur les clusters de stockage, que ce soit sur site ou dans le cloud public. Une fois qu'une relation de réplication entre un cluster source et un cluster cible a été établie et synchronisée, QF2 assure automatiquement la cohérence des données.

La réplication continue dans QF2 exploite les fonctionnalités avancées d'instantané de QF2 pour garantir des répliques de données cohérentes. Avec les instantanés QF2, une réplique sur le cluster cible reproduit l'état du répertoire source à des moments précis. Les relations de réplication QF2 peuvent être établies par répertoire pour une flexibilité maximale.

Qumulo applique des algorithmes intelligents pour gérer la réplication, vous n'avez donc pas à le faire. QF2 se réplique aussi souvent que possible sans impact négatif sur les performances globales du cluster. La réplication continue dans QF2 est asynchrone à sens unique à ce jour ; c'est-à-dire qu'il existe une source et une cible en lecture seule. Les modifications apportées au répertoire source sont propagées de manière asynchrone vers la cible.

Le magasin de blocs évolutif Qumulo (SBS)

Maintenant que nous avons examiné les composants internes du système de fichiers QF2, passons aux stratégies avancées de QF2 pour la gestion des blocs distribués trouvées dans le Qumulo Scalable Block Store. Voici un aperçu de ce qu'il y a à l'intérieur de SBS.

SBS fournit une couche virtuelle transactionnelle de blocs de stockage protégés. Au lieu d'un système où chaque fichier doit déterminer sa protection, la protection des données existe sous le système de fichiers, au niveau du bloc.

La protection basée sur les blocs de QF2, telle qu'implémentée par SBS, offre des performances exceptionnelles dans les environnements qui contiennent des pétaoctets de données et des charges de travail avec des tailles de fichiers mixtes.

Le SBS présente de nombreux avantages, notamment :

  • Temps de reconstruction rapide en cas d'échec du lecteur de disque
  • La possibilité de continuer les opérations de fichiers normales pendant les opérations de reconstruction
  • Aucune dégradation des performances due à un conflit entre les écritures de fichier normales et les écritures de reconstruction
  • Efficacité de stockage égale pour les petits fichiers comme pour les gros fichiers
  • Rapport précis de l'espace utilisable
  • Transactions efficaces qui permettent aux clusters QF2 de s'adapter à plusieurs centaines de nœuds
  • Une hiérarchisation intégrée des données chaudes / froides qui fournit des performances Flash aux prix des archives.

Pour comprendre comment SBS obtient ces avantages, nous devons examiner son fonctionnement.

Blocs virtuels protégés

La totalité de la capacité de stockage d'un cluster QF2 est conceptuellement organisée en un seul espace d'adressage virtuel protégé, illustré ici.

Chaque adresse protégée dans cet espace stocke un bloc d'octets de 4 Ko. Par "protégé", nous entendons que tous les blocs sont récupérables même si plusieurs disques tombaient en panne. La protection sera expliquée plus en détail plus loin dans cet article.

L'ensemble du système de fichiers est stocké dans l'espace d'adressage virtuel protégé fourni par SBS, y compris les données utilisateur, les métadonnées de fichier, la structure de répertoire, les analyses et les informations de configuration. En d'autres termes, le magasin protégé agit comme une interface entre le système de fichiers et les données basées sur les blocs enregistrées sur les périphériques de blocs connectés. Ces périphériques peuvent être des disques virtuels formés en combinant des SSD et des HDD ou des ressources de stockage en mode bloc dans le cloud.

Notez que les blocs de l'espace d'adressage protégé sont répartis sur tous les nœuds ou instances du cluster QF2. Cependant, le système de fichiers QF2 ne voit qu'un tableau linéaire de blocs entièrement protégés.

Protection des données basée sur le codage d'effacement

La protection contre la perte de données en cas de panne de disque inclut toujours une certaine forme de redondance ou de duplication des informations sur les périphériques de stockage. La forme la plus simple de protection des données est la mise en miroir. La mise en miroir signifie qu'il existe au moins deux copies complètes des données protégées. Chaque copie réside sur un disque différent afin qu'elle soit récupérable si l'un des disques tombe en panne.

La mise en miroir est simple à mettre en œuvre mais présente des inconvénients par rapport aux techniques de protection plus modernes. La mise en miroir est un gaspillage en termes d'espace requis pour protéger les données et ne gère qu'une seule panne de disque, ce qui n'est généralement pas un niveau de sécurité suffisamment élevé à mesure que la densité des nœuds et la taille des clusters augmentent.

D'autres stratégies de protection des données comprennent Répartition RAID. RAID est livré avec une administration extrêmement complexe et des temps de reconstruction lents qui obligent l'administrateur à choisir entre une reconstruction trop longue et une efficacité de stockage inacceptable.5

SBS met en œuvre sa protection des données basée sur des blocs avec une technique efficace appelée codage d'effacement (CE). SBS utilise les codes Reed-Solomon. EC est plus rapide, plus configurable et plus économe en espace que les alternatives telles que la mise en miroir et la répartition RAID.

EC encode les données de bloc à l'aide de segments redondants qui sont stockés sur un ensemble de supports physiques différents. En raison de l'efficacité d'EC, une plus grande partie du disque est disponible pour les données par rapport aux schémas RAID et de mise en miroir, ce qui réduit le coût par To utilisable.

Le codage d'effacement peut être configuré avec des compromis pour les performances, le temps de récupération en cas de défaillance du support physique et le nombre de défaillances simultanées autorisées. Dans cet article, nous utiliserons la notation (m, n) pour indiquer une configuration EC spécifique, où m indique le nombre total de blocs de supports physiques qui seront utilisés pour encoder en toute sécurité n blocs utilisateur. Le codage a la propriété que jusqu'à m – n blocs peuvent être détruits sans perte de données utilisateur. En d'autres termes, la survie de n'importe quelle collection de n disques est suffisante pour récupérer toutes les données utilisateur, même si certains des disques défaillants contenaient des données utilisateur. L'efficacité du codage peut être calculée comme le nombre n / m, ou le rapport des blocs utilisateur divisé par tous les blocs.

EC est le plus facile à comprendre avec des exemples. Voici un exemple simple appelé encodage (3,2).

Un codage (3,2) nécessite trois blocs (m = 3), stockés sur trois périphériques physiques distincts pour coder en toute sécurité deux blocs (n = 2). Deux des blocs contiennent les données utilisateur que nous voulons protéger et le troisième est appelé bloc de parité. Le contenu du bloc de parité est calculé par l'algorithme de codage d'effacement. Même ce schéma simple est plus efficace que la mise en miroir: vous écrivez seulement un bloc de parité pour deux blocs de données. Dans un codage (3, 2), si le disque contenant l'un des trois blocs tombe en panne, les données utilisateur des blocs 1 et 2 sont protégées.

Voici comment cela fonctionne. Si le bloc de données 1 est disponible, il vous suffit de le lire. Il en va de même pour le bloc de données 2. Cependant, si le bloc de données 1 est en panne, le système EC lit le bloc de données 2 et le bloc de parité et reconstruit la valeur du bloc de données 1 à l'aide de la formule Reed-Solomon (qui dans cet exemple particulier est juste XOR au niveau du bit). De même, si le bloc de données 2 réside sur le disque défaillant, les systèmes lisent le bloc de données 1 et le bloc de parité. SBS s'assure que les blocs se trouvent sur des broches différentes afin que le système puisse lire les blocs simultanément.

Un codage (3,2) a une efficacité de 2/3 (n/m), soit 67 %. Bien qu'il soit meilleur que l'efficacité de 50 % de la mise en miroir en termes de stockage de données, l'encodage (3,2) ne peut toujours protéger que contre une seule panne de disque.

Au minimum, QF2 utilise l'encodage (6, 4), qui stocke un tiers de données utilisateur en plus dans le même espace que la mise en miroir, mais peut tolérer deux pannes de disque au lieu d'une seule comme le fait la mise en miroir. Même si deux blocs contenant des données utilisateur ne sont pas disponibles, le système n'a toujours besoin que de lire les deux blocs de données restants et les deux blocs de parité pour récupérer les données manquantes.

Distribution de blocs virtuels protégés sur des nœuds

De nombreuses considérations pratiques doivent être prises en compte lors de la mise en œuvre de la technologie EC dans des systèmes avec une évolutivité massive. Pour faciliter le processus d'écriture des blocs de parité requis (et pour restaurer les données en cas de défaillance d'un disque), SBS divise son espace d'adressage virtuel de blocs 4K en segments logiques appelés magasins protégés.

SBS gère chaque pstore individuellement, ce qui rend le schéma de mappage qui associe l'espace d'adressage protégé aux disques plus flexible. Tous les pstores 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 blocs virtuels protégés à des régions de stockage contiguës qui résident sur des disques virtuels des nœuds du cluster QF2. Les régions contiguës sont appelées bstores.

La carte des pstores vers les bstores est stockée par chaque nœud du cluster. 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). Chaque bstore se voit allouer un espace contigu sur son disque dur associé, tandis que l'espace sur le SDD associé du bstore est alloué dynamiquement. Les métadonnées d'un bstore existent également sur son SSD associé. Les métadonnées Bstore incluent des informations telles que les adresses utilisées et une carte qui indique quelles adresses de bloc dans le stockage SSD de référence bstore et lesquelles se trouvent sur le disque dur.

Lors d'une lecture ou d'une écriture, le pstore décide quels bstores doivent être accessibles.

Lorsqu'un client du système de fichiers lance une opération d'écriture, il entre dans SBS sous la forme d'un 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 simultanément 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 indiquant que l'écriture a eu lieu.

Les blocs de données contenant des données utilisateur et des blocs de parité sont tous deux écrits dans les bstores. Un bstore particulier, pour sa durée de vie, contient soit des blocs de parité, soit des blocs de données, mais pas les deux. Comme EC 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 choix de EC. Pour conserver la cohérence de la taille du pstore, 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 l'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, QF2 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 exige 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 QF2 peut utiliser la mise en miroir intégrée qui se trouve dans chaque bloc de stockage élastique. Les clusters QF2 à nœud unique dans le cloud utilisent le codage d'effacement (5, 4).

Temps de reconstruction rapides

Les temps de reconstruction QF2 sont mesurés en heures. En revanche, les systèmes de stockage hérités, qui ont été conçus pour des charges de travail avec beaucoup moins de données, ont des temps de reconstruction qui se mesurent en jours. 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 des appliances de stockage héritées. L'avantage spectaculaire de QF2 en termes de temps de reconstruction est le résultat direct de la protection avancée basée sur les blocs de SBS.

La protection basée sur les 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 de fichiers, dont beaucoup sont petits. Le système de protection SBS n'a pas besoin d'effectuer des parcours d'arborescence fastidieux 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 la protection de millions de fichiers est tout à fait réalisable.

De plus, QF2 est conçu pour que les temps de reconstruction ne soient pas affectés par la taille du cluster. En fait, le contraire est vrai. Dans QF2, les clusters plus grands ont des temps de reconstruction plus rapides que les clusters plus petits. 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 effectuer de travail lors d'une reconstruction.

Les appliances de stockage héritées avec des temps de reconstruction lents sont vulnérables à des pannes supplémentaires qui peuvent se produire pendant le processus prolongé de reconstruction. En d'autres termes, les 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). Grâce aux temps de reconstruction rapides de QF2, les administrateurs peuvent maintenir leurs cibles de temps moyen avant perte de données (MTTDL) sans trop de redondance, ce qui permet d'économiser du temps et de l'argent.

Reconstruire les pstores

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. Grâce à EC, 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 vous êtes un 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 avec des groupes RAID, comme dans les systèmes hérités) pour reconstruire les bstores qui se trouvaient sur le disque défaillant. SBS alloue une petite quantité d'espace disque supplémentaire afin qu'il y ait de la place pour cela. C'est ce qu'on appelle épargner.

Étant donné que la carte globale pstore à bstore contient l'ID du disque virtuel associé au bstore, cette information permet de savoir facilement quels pstores doivent être traités lorsqu'un disque particulier tombe en panne. É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 rapidement traduire 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 entraîner 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 entrée/sortie aléatoire n'est requise. En outre, les bstores sont suffisamment petits pour que le travail de reprotection soit efficacement réparti sur l'ensemble du cluster.

Opérations de fichier normales non affectées par 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 standard du système de fichiers pendant la reconstruction. Cela est dû au fait que ces opérations sur les fichiers entrent en concurrence avec les threads de reconstruction/reprotection. QF2 utilise la superposition 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 initiées par l'utilisateur ne peuvent pas attendre qu'un pstore soit reproté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. Voici un exemple.

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 EC. 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.

Les petits fichiers sont aussi efficaces que les gros fichiers

Étant donné que le système de fichiers QF2 utilise une protection basée sur les blocs, les petits fichiers sont aussi efficaces que les gros fichiers. Ils peuvent partager des bandes avec d'autres fichiers et ils peuvent partager la protection. Chaque fichier se compose des blocs de données, d'au moins un bloc inode et de tout autre bloc requis. De très petits fichiers sont intégrés dans le bloc inode. Le système utilise des blocs 4K et tous les blocs sont protégés au taux de protection du système.

L'efficacité de QF2 avec les petits fichiers est un gros avantage par rapport aux anciennes appliances de stockage, qui utilisent une mise en miroir inefficace pour les petits fichiers et les métadonnées système.

Toute la capacité fournie est disponible pour les fichiers utilisateur.

Les fichiers utilisateur QF2 peuvent occuper 100 % de la capacité allouée, tandis que l'évolution horizontale recommandée recommande d'utiliser uniquement 80 % à 85 %. La protection basée sur les blocs de QF2 ne nécessite aucune capacité provisionnée par l'utilisateur pour la reprotection, autre qu'une petite quantité d'espace pour la réserve, qui est exclue de la capacité provisionnée 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 provisionnée par l'utilisateur.

De plus, le système de fichiers QF2 signale avec précision la capacité disponible pour les fichiers utilisateur. Encore une fois, cette prévisibilité est une conséquence de la protection par blocs. Dans les systèmes hérités, l'utilisation du stockage dépend de la taille du fichier, de sorte que ces systèmes ne peuvent signaler que l'espace brut. Les administrateurs doivent deviner l'espace dont ils disposent réellement.

Lorsque vous comparez QF2 à des systèmes hérités, vous devez tenir compte de la quantité de capacité provisionnée par l'utilisateur que vous pouvez réellement utiliser dans chaque type de système.

Transactions

Dans SBS, les lectures et les écritures dans l'espace d'adressage virtuel protégé sont transactionnelles. Cela signifie que, par exemple, lorsqu'une opération de système de fichiers QF2 nécessite une opération d'écriture qui implique plus d'un bloc, l'opération écrira soit tous les blocs pertinents, soit aucun d'entre eux. Les opérations de lecture et d'écriture atomiques sont essentielles pour la cohérence des données et la mise en œuvre correcte des protocoles de fichiers tels que SMB et NFS.

Pour des performances optimales, SBS utilise des techniques qui maximisent le parallélisme et l'informatique distribuée tout en maintenant la cohérence transactionnelle des opérations d'E/S. Par exemple, SBS est conçu pour éviter les goulots d'étranglement en série, où les opérations se dérouleraient en séquence plutôt qu'en parallèle.

Le système de transaction de SBS utilise les principes de l'algorithme ARIES pour les transactions non bloquantes, y compris la journalisation à écriture anticipée, la répétition de l'historique pendant les actions d'annulation et la journalisation des actions d'annulation. Cependant, la mise en œuvre des transactions par SBS présente plusieurs différences importantes par rapport à ARIES.

SBS profite du fait que les transactions initiées par le système de fichiers QF2 sont, comme on pouvait s'y attendre, de courte durée, contrairement aux bases de données à usage général où les transactions peuvent durer longtemps. Un modèle d'utilisation avec des transactions de courte durée permet à SBS de réduire fréquemment le journal des transactions pour plus d'efficacité. Les transactions de courte durée permettent une commande d'engagement plus rapide.

En outre, les transactions de SBS sont hautement distribuées et ne nécessitent pas un ordre total défini à l'échelle mondiale des numéros de séquence de style ARIES pour chaque entrée du journal des transactions. Au lieu de cela, les journaux de transactions sont localement séquentiels dans chacun des bstores et coordonnés au niveau mondial à l'aide d'un schéma de commande partiel qui prend en compte les contraintes de commande d'engagement.

Qumulo DB utilise un protocole de verrouillage en deux phases (2PL) pour implémenter la sérialisabilité pour une commande d'engagement cohérente. Les opérations sérialisables sont effectuées par des unités de traitement distribuées (bstores) et ont la propriété que la séquence prévue des opérations peut être reconstruite après coup. L'avantage de l'approche de SBS est que la quantité minimale absolue de verrouillage est utilisée pour les opérations d'E/S transactionnelles, ce qui permet aux clusters QF2 de s'adapter à plusieurs centaines de nœuds.

Hiérarchisation chaud/froid pour l'optimisation de la lecture/écriture

SBS inclut une hiérarchisation intégrée des données chaudes et froides pour optimiser les performances de lecture/écriture.

Lorsqu'il est exécuté sur site, QF2 tire parti de la vitesse des disques SSD et de la rentabilité des disques durs (HDD). Les SSD sont associés à des disques durs de base sur chaque nœud. Cette paire s'appelle un disque virtuel. Il existe un disque virtuel pour chaque disque dur du système.

Les données sont toujours écrites en premier sur les SSD. Étant donné que les lectures accèdent généralement aux données récemment écrites, les SSD agissent également comme un cache. Lorsque les disques SSD sont remplis à environ 80 %, les données les moins consultées sont transmises aux disques durs. Les disques durs offrent une capacité et une lecture/écriture séquentielle de grandes quantités de données.

Lorsqu'il s'exécute dans le cloud, QF2 optimise l'utilisation des ressources de stockage de blocs en associant un stockage de blocs hautes performances à un stockage de blocs moins performant et économique.

Examinons les aspects suivants de la hiérarchisation chaud/froid de SBS :

  • Comment et où les données sont écrites
  • Où les métadonnées sont écrites
  • Comment les données sont expirées
  • Comment les données sont mises en cache et lues

L'écriture initiale

Pour écrire dans un cluster, un client envoie des données à un nœud. Ce nœud sélectionne un pstore ou plusieurs pstores où ces données iront et, en termes de matériel, il écrit toujours sur les SSD ou sur le stockage de blocs à faible latence s'il utilise des ressources cloud. (Rappelez-vous que nous utilisons SSD pour désigner à la fois les SSD sur site et le stockage de blocs à faible latence dans le cloud public ; le comportement est similaire.) Ces SSD seront sur plusieurs nœuds.

Toutes les écritures se produisent sur des SSD ; SBS n'écrit jamais directement sur le disque dur. Même si un SSD est plein, le système fait de la place pour les nouvelles données en purgeant les données précédemment mises en cache.

Gestion des métadonnées

Généralement, les métadonnées restent sur le SSD. Les données sont généralement écrites dans un bstore à l'adresse disponible la plus basse, de sorte que les données augmentent du début du bstore à la fin. Les métadonnées commencent à la fin du bstore et grandissent vers le début. Cela signifie que toutes les métadonnées se trouvent à droite des données. Voici une illustration de l'emplacement des métadonnées sur un bstore.

QF2 alloue jusqu'à 1 % du bstore sur le SSD aux métadonnées et ne l'expire jamais. Rien dans ce 1% ne va au disque dur. Si jamais les métadonnées dépassent ce 1 %, elles pourraient expirer mais, pour une charge de travail typique, il y a environ 0.1 % de métadonnées. L'espace n'est pas perdu s'il n'y a pas assez de métadonnées pour le remplir. Les données peuvent également utiliser cet espace.

Données expirant

À un moment donné, le système a besoin de plus d'espace sur le SSD, de sorte que certaines données sont expirées ou déplacées du SSD vers le disque dur. Les données sont copiées du SSD vers le HDD puis, une fois sur le HDD, elles sont supprimées du SSD.

L'expiration commence lorsqu'un SSD est plein à au moins 80 % et s'arrête lorsqu'il revient à moins de 80 %. Le seuil de 80 % est une heuristique qui optimise les performances : les écritures sont plus rapides lorsque les SSD se situent entre 0 % et 80 % et que les expirations ne se produisent pas en même temps.

Lorsque les données d'un SSD sont déplacées vers le disque dur, SBS optimise les écritures séquentiellement sur le disque dur de manière à optimiser les performances du disque. Les rafales d'octets volumineux et contigus constituent la méthode la plus efficace possible pour écrire sur le disque dur.t

Mise en cache des données

L'illustration suivante montre tous les caches QF2. Tout ce qui est en vert est un endroit qui peut contenir des données, et cela peut être sur SSD ou HDD.

Les opérations d'E/S QF2 utilisent trois types de caches différents. Le client a toujours un cache de son côté et il existe deux types de caches sur les nœuds. L'un est le cache de transactions, qui peut être considéré comme les données du système de fichiers que le client demande directement. L'autre type est le cache disque, qui sont des blocs de ce disque qui sont conservés en mémoire.

Par exemple, supposons qu'un client connecté au nœud 1 initie une lecture du fichier X. Le nœud 1 découvre que ces blocs sont alloués au nœud 2 et notifie au nœud 2 qu'il veut des données, qui dans cet exemple sont stockées dans un des SSD du nœud 2. Le nœud 2 lit les données et les place dans le cache disque associé à ce SSD. Le nœud 2 répond au nœud 1 et envoie les données. À ce stade, les données entrent dans le cache de transaction du nœud 1, qui informe le client qu'il dispose des données pour le fichier X.

Le nœud auquel le disque est attaché est celui où le cache disque est rempli. Le nœud auquel le client est attaché est l'endroit où le cache de transaction est rempli. Le cache disque contient toujours des blocs et le cache de transaction contient les données des fichiers réels. Le cache de transaction et le cache de disque partagent la mémoire, bien qu'il n'y ait pas de quantité spécifique allouée à l'un ou à l'autre.

Protocoles standard de l'industrie

QF2 utilise les protocoles standards NFSv3 et SMBv2.1.

API REST

QF2 inclut une API REST complète. En fait, toutes les informations représentées dans l'interface graphique QF2 sont générées à partir d'appels à l'API REST QF2. Un onglet dans l'interface graphique fournit une ressource d'auto-documentation des appels d'API REST disponibles. Vous pouvez tester l'API en exécutant des appels sur le cluster actif et en inspectant les demandes et les résultats en temps réel. Voici un exemple de capture d'écran.

Toutes les informations présentées dans l'onglet Analytics de l'interface graphique peuvent être récupérées par programmation avec des appels REST contre l'API et stockées en externe dans une base de données ou envoyées à une autre application telle que Splunk ou Tableau. La plupart des opérations du système de fichiers peuvent également être appelées avec l'API REST.

Conclusion

Nous espérons que cet article a démystifié le fonctionnement interne de QF2 et vous a donné un aperçu des raisons pour lesquelles les percées de performance et d'évolutivité de QF2 sont possibles. Si vous souhaitez des informations supplémentaires, veuillez CONTACTEZ-NOUS.

Points clés

Voici les principaux points soulevés dans cet article.

  • Les données augmentent à un rythme explosif et les charges de travail modernes pèsent plusieurs pétaoctets, peuvent contenir des milliards de fichiers et ces fichiers sont de tailles mixtes.
  • La plupart des systèmes de stockage utilisent des technologies vieilles de plusieurs décennies qui n'ont jamais été conçues pour gérer les charges de travail modernes.
  • QF2 est un système de stockage moderne conçu spécifiquement pour répondre aux charges de travail modernes.
  • QF2 s'exécute sur du matériel standard sur site et dans le cloud.
  • QF2 a une architecture hybride qui utilise des SSD et des HDD.
  • QF2 utilise un schéma de protection par blocs qui fonctionne sous le système de fichiers réel.
  • QF2 a des temps de reconstruction rapides, mesurés en heures. Ils sont de loin les plus rapides de l'industrie.
  • Les fichiers utilisateur peuvent occuper jusqu'à 100 % de la capacité allouée.
  • Les petits fichiers sont aussi efficaces que les gros fichiers.
  • L'ensemble du système de fichiers existe en tant que volume unique.
  • QF2 applique les mêmes techniques que celles utilisées par les grandes bases de données distribuées à son système de fichiers.
  • L'analyse en temps réel donne une visibilité sur ce qui se passe dans le système de fichiers en ce moment.
  • Il existe des rapports précis sur la quantité d'espace utilisable disponible.
  • Les administrateurs peuvent appliquer des quotas en temps réel.
  • Les administrateurs savent combien d'espace réel ils économisent en supprimant des instantanés.
  • QF2 inclut la réplication asynchrone des données à grande échelle.
  • QF2 utilise des protocoles standard tels que NFS et SMB et inclut une API REST.

 


Télécharger

Remonter en haut