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

Une plongée approfondie dans la conception de clusters flexibles

Rédigé par:

Ceci est la deuxième partie d'une série de blogs en cinq parties qui examinera de plus près notre nouveau suite de services de données Cela aidera nos clients à simplifier radicalement la gestion des données de fichiers à grande échelle. Nous avons parlé de Performances en cache NVMe dans notre article précédent. Ici, nous fournissons un aperçu de Dynamic Scale. Les prochains blogs de cette série approfondiront les autres nouveaux services de données inclus dans cette annonce.

Lors de la conception de Qumulo plateforme de données de fichiers, nous prenons en considération en permanence les problèmes que nos clients tentent de résoudre. Nos clients sont nos champ magnétique, et ils stimulent le développement et l'innovation de nos produits.

Pour les aider dans leurs missions, nous sortons rapidement de nouvelles fonctionnalités et plateformes logicielles qui améliorent à la fois les coûts et les performances de nos clients. En fait, nous avons récemment annoncé un nouvelle suite de services de données pour aider à simplifier radicalement la façon dont nos clients gèrent des quantités massives de données de fichiers.

Notre objectif est de rendre simple et rentable pour les entreprises et les organisations gouvernementales la mise à l'échelle, la sécurisation et l'obtention de hautes performances dans leurs environnements de données complexes et non structurés.

Innovation sans limitation

Pour garantir que nos clients puissent profiter des améliorations de la technologie matérielle sans migration de données, Qumulo améliore continuellement notre plate-forme de données de fichiers afin que les clients puissent combiner des nœuds de différents types dans un seul cluster. Nous pensons que vous ne devriez pas être empêché d'avoir accès aux dernières technologies.

Nous avons récemment introduit Qumulo Dynamic Scale, qui permet aux administrateurs d'exploiter les plates-formes matérielles nouvellement qualifiées avec les derniers processeurs, mémoire et périphériques de stockage sans avoir besoin de mises à niveau de chariot élévateur, de migrations de données ou de gestion de pool de stockage complexe. Les utilisateurs de Qumulo peuvent désormais ajouter de nouvelles plates-formes qualifiées dans des environnements existants sans avoir besoin de gérer différents pools de stockage ou d'effectuer une migration de données. Les nouvelles plates-formes sont simplement ajoutées à l'environnement existant, les données sont automatiquement redistribuées et les performances et capacités accrues sont automatiquement mises à la disposition des utilisateurs et des applications.

Alors, qu'a fait l'équipe d'ingénierie de Qumulo pour activer des nœuds de différents types dans un seul cluster? C'est quelque chose que nous appelons la «compatibilité des nœuds».

Notre première étape dans ce travail a été de prendre en charge les nœuds de clustering avec des quantités de stockage similaires, afin que les clients utilisant des serveurs HPE Apollo puissent ajouter des nœuds HPE Gen10 à leurs clusters HPE Gen9.

Compatibilité des nœuds: comprendre l'architecture de protection des données

Dès le premier jour, Qumulo s'est concentré sur l'architecture et le développement d'une plate-forme de données de fichiers qui fournirait à nos clients la dernière technologie, sans créer de limitations artificielles sur les fonctionnalités de la plate-forme de données de fichiers. La plate-forme de données de fichiers de Qumulo est conçue pour que la couche du système de fichiers n'ait pas besoin de savoir quoi que ce soit sur les dimensions sous-jacentes du matériel - toute cette action se déroule plus bas dans la pile.

Pour que les différents types de nœuds fonctionnent ensemble, l'équipe d'ingénierie de Qumulo devait travailler sur les composants responsables de la disposition des objets système internes (à ne pas confondre avec le stockage d'objets de l'utilisateur final) sur les ressources de stockage du cluster. Les mises en page sont optimisées pour protéger contre la perte de données et garantir la disponibilité des données. Ceci est important pour qu'en cas de panne d'un disque ou de panne d'un nœud, le client puisse continuer à utiliser le cluster et continuer à accéder à ses données.

Le travail s'est concentré sur deux éléments clés: le restriper, qui présente les magasins protégés (ou «PStores») qui stockent les données et métadonnées du système de fichiers (partie du système de protection sur le schéma ci-dessus); et le DKV, qui fournit un magasin de valeurs-clés distribuées rapide à utiliser par le système de protection et le système de transaction.

Le restriper

Le restaurateur est chargé de s'assurer que les données sont en sécurité après une panne de composant. Il décide des disques sur lesquels les PStores vivent dans le système. Un PStore se compose d'un certain nombre de Block Stores («BStores»), dont chacun vit sur un disque spécifique. Les données sont encodées sur les BStores à l'aide d'un schéma appelé Codage d'effacement, afin que le système puisse tolérer un certain nombre de pannes de disques et / ou de nœuds, tout en fournissant autant d'espace utilisable que possible.

En cas de perte de disque, le restriper est le composant qui s'occupe de la reconstruction des données qui se trouvaient sur le disque perdu. À cette fin, Qumulo conserve un peu d'espace libre sur tous les autres disques du système à cet effet.

Dans l'image ci-dessus, nous voyons un cluster avec 8 disques durs de 8 To, chacun ayant un espace de 1 To de réserve conservé sur un côté. Si un disque tombe en panne, nous pouvons reconstruire les 7 To de données maintenant manquantes en utilisant l'espace disponible; les temps de reprotection sont minimisés en répartissant uniformément l'espace disponible dans le système de fichiers.

Le DKV

Le DKV stocke les données de paires clé-valeur qui doivent être disponibles globalement, ainsi que accessibles en écriture et en lecture à partir de n'importe quel nœud. Les valeurs qu'il stocke sont essentiellement une série d'octets, la taille maximale étant légèrement inférieure à 4 Ko. L'utilisation principale du DKV est de stocker les métadonnées PStore, y compris sur lequel des disques les BStores de chaque PStore vivent.

L'espace clé DKV est divisé en un certain nombre de partitions de taille égale que nous appelons des fragments. Chaque partition est mise en miroir sur plusieurs volumes KV. Lorsque le système de fichiers Qumulo écrit sur une clé DKV, il écrit les données dans tous les miroirs avant le retour de l'appel API. De cette façon, lorsque le système lit à partir d'une clé DKV, il peut lire à partir d'un miroir arbitraire.

L'espace clé DKV est divisé en un certain nombre de partitions de taille égale que nous appelons des fragments. Chaque partition est mise en miroir sur plusieurs volumes KV, qui sont les artefacts physiques qui vivent sur les disques SSD du cluster.

Un quorum dans Qumulo est l'ensemble des ressources physiques que le cluster est actuellement en mesure d'utiliser - c'est l'ensemble des nœuds et des disques en ligne. Lorsque cet ensemble de ressources change - disons qu'un disque doit être remplacé ou qu'un nœud se déconnecte - le quorum actuel est rapidement abandonné, un certain nombre de tâches en cours d'exécution dans le système sont arrêtées, puis nous remettons le système en ligne dans un nouveau quorum avec le nouvel ensemble de ressources. La plate-forme de données de fichiers Qumulo reconnaît les changements dans les ressources et exécute diverses opérations de récupération pour s'assurer que les données du cluster restent disponibles, tout en étant protégées contre les futures pannes de ressources.

La récupération du DKV après un changement de quorum est vraiment simple. Pour chaque partition, nous choisissons un miroir disponible arbitraire comme source et faisons de nouvelles copies identiques de ce miroir pour une utilisation dans le nouveau quorum. Ainsi, même si une écriture en vol n'avait été écrite que dans un sous-ensemble des miroirs lorsque le quorum précédent s'est terminé, le nouvel ensemble de miroirs sera cohérent car ils ont été copiés à partir du même miroir source.

Qumulo n'utilise que des SSD prenant en charge les écritures atomiques de 4 KiB (même en cas de perte de puissance inattendue), nous pouvons donc également garantir que pour toute écriture en vol, nous verrons strictement soit l'ancienne valeur, soit la nouvelle valeur - il y a gagné '' t être des blocs partiellement écrits. Les disques SSD que nous utilisons ne suppriment jamais les écritures reconnues (encore une fois, même en cas de perte de puissance), nous pouvons donc garantir que nous verrons la nouvelle valeur pour toutes les écritures enregistrées comme terminées.

Obtenir la compatibilité des nœuds pour le restriper

Maintenant que nous comprenons l'architecture de protection des données de basse altitude, le défi pour l'équipe du projet Qumulo était de faire fonctionner cette architecture sur différents systèmes qu'un client peut inclure dans un seul cluster. Chaque nœud doit découvrir la «géométrie» du cluster en demandant à un nœud de demander à chaque autre nœud de lui dire combien de disques il possède, quelle est leur taille, etc.

Vous vous souvenez de cet espace libre que nous conservons sur chaque disque? Nous avons besoin que cet espace soit uniformément réparti, de sorte que la reconstruction des données à partir d'un disque perdu puisse aller aussi vite que possible, sans surcharger les disques individuels du système. L'algorithme glouton du restriper a été écrit pour être gourmand en termes d'espace utilisé sur les disques. Donc, si les disques étaient de tailles différentes, l'objectif serait de placer le même nombre de BStores sur chaque disque.

Mais ce n'est clairement pas ce que nous voulons. Cela obligerait la reprotection à écrire davantage de données reconstruites sur les plus gros disques du système, car ils disposent d'une plus grande partie de l'espace disponible. Soit cela ralentira la reprotection, soit nous devrons avoir un impact plus important sur la charge de travail du client pour que l'heure reste la même.

La résolution de ce problème était assez simple - nous venons de retravailler l'algorithme pour être gourmand en termes d'espace libre. Cette approche a des limites et ne fonctionne que pour des nœuds de taille similaire, mais il s'agissait d'un changement progressif rapide qui nous a permis de fournir rapidement des avantages à certains clients.

Atteindre la compatibilité des nœuds pour le DKV

Comme indiqué, l'utilisation principale du DKV est de stocker des données sur l'emplacement des PStores.

Historiquement, l'équipe d'ingénierie de Qumulo a choisi de réserver un petit nombre de clés au début de l'espace clé pour d'autres cas d'utilisation futurs, mais tout après une certaine clé est un PStore. Lorsque nous avons conçu le DKV pour la première fois, nous voulions faire du nombre de fragments DKV une fonction triviale de la taille du cluster, nous avons donc décidé de rendre chaque fragment suffisamment grand pour stocker un nombre défini de nœuds PStores. De nouveaux fragments sont ajoutés au DKV à mesure que les nœuds sont ajoutés au cluster, en fonction du nombre de nœuds.

Si nous ajoutons des nœuds de tailles différentes à un cluster, ce calcul ne fonctionnera pas de la même manière. Lorsque les nouveaux nœuds sont plus grands que les nœuds existants, nous devons ajouter des fragments DKV plus rapidement. Mais avec un seul volume KV par SSD, ce n'est pas toujours possible, tout en conservant notre capacité à récupérer des pertes de disques et de nœuds.

Pour que le DKV soit flexible sur le moment où nous ajoutons plus de fragments pour tenir compte des nœuds de stockage de différentes tailles, nous devions également provisionner des volumes KV supplémentaires sur les disques SSD du cluster. Étant donné que les volumes eux-mêmes sont petits (moins de 100 Mo), nous avons choisi d'utiliser un nombre constant de volumes par SSD, même si cela surprovisionnerait désormais l'espace d'une marge relativement plus importante dans certains cas. Cela simplifie le code de mise en page, au détriment de la consommation d'une petite quantité d'espace SSD.

L'ajout de nouveaux volumes KV au moment de la récupération DKV n'est pas une option, nous avons donc fourni une API que le restaurateur peut appeler pour libérer de l'espace, une fois le système opérationnel. Cette négociation de taille se produit lorsque le restaurateur se prépare à créer des PStores, soit juste après la création initiale du cluster, soit après l'ajout de nouveaux nœuds. Une fois que le système de protection a déterminé le nombre de PStores que le système doit avoir, le restaurateur appelle l'API de négociation pour demander l'espace. Si de nouvelles partitions sont nécessaires, des volumes KV supplémentaires seront ajoutés si nécessaire, et une mise en page pour les nouvelles partitions sera trouvée et ajoutée à la mise en page DKV actuelle. Une fois que la nouvelle partition a été mise en page, la nouvelle partition est disponible pour une utilisation à l'échelle du cluster. Au terme d'une négociation réussie, le restriper reprend le contrôle et ajoute les nouveaux PStores, qui fournissent la capacité utilisable au client.

Il est intéressant de noter que bien que ce qui se passe sous les couvertures soit complexe, l'interaction entre le restriper et le DKV est très simple. Et les couches ne sont plus enchevêtrées. Le DKV ne sait rien du nombre de PStores qu'un cluster particulier devrait avoir. Les nouveaux clusters ne démarrent qu'une seule partition qui peut stocker un nombre défini de clés - toutes les plates-formes matérielles utilisent la même taille de volume initiale, puis lorsque le système de protection sait combien de PStores il veut, il demande juste l'espace.

La conception du DKV offre une énorme flexibilité - la flexibilité que Qumulo utilise pour relever les défis de nos clients. Combiné à notre simple amélioration du restriper, nous avons pu ouvrir la voie pour que les clients disposant de clusters HPE Apollo Gen9 puissent continuer à étendre leurs clusters lorsqu'ils ne pouvaient plus acheter de nœuds Gen9.

À l'avenir, nous généraliserons la compatibilité des nœuds afin que tous nos clients puissent profiter de la nouvelle technologie, à mesure qu'elle continue à arriver sur le marché, et que les volumes de données des clients continuent d'exploser, et nous sommes convaincus que nos systèmes conçus de manière flexible peut être adapté pour gérer ce qui se passe ensuite.

EN SAVOIR PLUS

Pour voir ces nouveaux services de données en action, inscrivez-vous à notre Événement virtuel exclusif Q-Connect Du 8 au 16 décembre! Chez Q-Connect, les participants auront l'opportunité de se connecter en direct avec nos experts techniques et nos clients Qumulo pour voir comment notre plateforme de données de fichiers simplifie radicalement la gestion des données d'entreprise.

Contactez-nous ici si vous souhaitez organiser une réunion ou demander une démonstration. Et Abonnez-vous à notre blog pour des meilleures pratiques et ressources plus utiles!

PS! L'équipe d'ingénierie de Qumulo est embauche et nous avons plusieurs offres d'emploi ouvertes - vérifiez-les ici et en apprendre davantage sur la vie chez Qumulo.

Articles Similaires

Remonter en haut