Bonjour, lecteurs Habr. Avec cet article, nous ouvrons une série qui parlera du système hyperconvergé AERODISK vAIR que nous avons développé. Au départ, nous voulions tout raconter dans le premier article, mais le système est assez complexe, nous allons donc manger l'éléphant en plusieurs parties.
Commençons l'histoire par l'historique de la création du système, approfondissons le système de fichiers ARDFS, qui est la base de vAIR, et parlons également un peu du positionnement de cette solution sur le marché russe.
Dans les prochains articles, nous parlerons plus en détail des différents composants architecturaux (cluster, hyperviseur, équilibreur de charge, système de surveillance, etc.), du processus de configuration, soulèverons les problèmes de licence, présenterons séparément les tests de crash et, bien sûr, écrireons sur les tests de charge et dimensionnement. Nous consacrerons également un article séparé à la version communautaire de vAIR.
Aerodisk est-il une histoire de systèmes de stockage ? Ou pourquoi avons-nous commencé à faire de l’hyperconvergence en premier lieu ?
Initialement, l’idée de créer notre propre hyperconvergence nous est venue vers 2010. À cette époque, il n’existait ni Aerodisk ni solutions similaires (systèmes hyperconvergés commerciaux en boîte) sur le marché. Notre tâche était la suivante : à partir d'un ensemble de serveurs avec disques locaux, unis par une interconnexion via le protocole Ethernet, il fallait créer un stockage étendu et y lancer des machines virtuelles et un réseau logiciel. Tout cela devait être mis en œuvre sans systèmes de stockage (car il n'y avait tout simplement pas d'argent pour les systèmes de stockage et leur matériel, et nous n'avions pas encore inventé nos propres systèmes de stockage).
Nous avons essayé de nombreuses solutions open source et avons finalement résolu ce problème, mais la solution était très complexe et difficile à répéter. D’ailleurs cette solution était dans la catégorie « Est-ce que ça marche ? Ne touchez pas ! Par conséquent, après avoir résolu ce problème, nous n’avons pas développé davantage l’idée de transformer le résultat de notre travail en un produit à part entière.
Après cet incident, nous avons abandonné cette idée, mais nous avions toujours le sentiment que ce problème pouvait être complètement résolu et que les avantages d'une telle solution étaient plus qu'évidents. Par la suite, les produits HCI lancés par des sociétés étrangères n’ont fait que confirmer ce sentiment.
C'est pourquoi, mi-2016, nous avons repris cette tâche dans le cadre de la création d'un produit à part entière. À cette époque, nous n'avions pas encore de relations avec des investisseurs, nous avons donc dû acheter un stand de développement pour notre propre argent, mais pas très cher. Après avoir collecté les serveurs et commutateurs usagés sur Avito, nous nous sommes mis au travail.
La tâche initiale principale était de créer notre propre système de fichiers, bien que simple, mais propre, capable de distribuer automatiquement et uniformément les données sous forme de blocs virtuels sur le nième nombre de nœuds de cluster, qui sont connectés par une interconnexion via Ethernet. Dans le même temps, le FS doit évoluer correctement et facilement et être indépendant des systèmes adjacents, c'est-à-dire être aliéné de vAIR sous la forme de « juste une installation de stockage ».
Premier concept vAIR
Nous avons délibérément abandonné l'utilisation de solutions open source prêtes à l'emploi pour organiser le stockage étendu (ceph, gluster, lustre, etc.) au profit de notre propre développement, car nous avions déjà beaucoup d'expérience en matière de projets avec elles. Bien entendu, ces solutions elles-mêmes sont excellentes, et avant de travailler sur Aerodisk, nous avons mis en œuvre plus d'un projet d'intégration avec elles. Mais c'est une chose de mettre en œuvre une tâche spécifique pour un client, de former le personnel et, peut-être, d'acheter le soutien d'un grand fournisseur, et c'en est une autre de créer un produit facilement reproductible qui sera utilisé pour diverses tâches, que nous, en tant que vendeur, peut-être même savoir sur nous-mêmes, nous ne le saurons pas. Pour le deuxième objectif, les produits open source existants ne nous convenaient pas, nous avons donc décidé de créer nous-mêmes un système de fichiers distribué.
Deux ans plus tard, plusieurs développeurs (qui ont combiné leurs travaux sur vAIR avec ceux sur le système de stockage Engine classique) ont obtenu un certain résultat.
En 2018, nous avions écrit un système de fichiers simple et l'avions complété par le matériel nécessaire. Le système a combiné des disques physiques (locaux) de différents serveurs dans un pool plat via une interconnexion interne et les a « coupés » en blocs virtuels, puis des périphériques de bloc avec différents degrés de tolérance aux pannes ont été créés à partir des blocs virtuels, sur lesquels des blocs virtuels ont été créés. et exécuté à l'aide des voitures de l'hyperviseur KVM.
Nous ne nous sommes pas trop préoccupés du nom du système de fichiers et l'avons succinctement appelé ARDFS (devinez ce que cela signifie))
Ce prototype avait l'air bien (pas visuellement, bien sûr, il n'y avait pas encore de conception visuelle) et a montré de bons résultats en termes de performances et d'évolutivité. Après le premier résultat réel, nous avons lancé ce projet, en organisant un environnement de développement à part entière et une équipe distincte qui s'occupait uniquement de vAIR.
À ce moment-là, l’architecture générale de la solution avait mûri et n’a pas encore subi de changements majeurs.
Plonger dans le système de fichiers ARDFS
ARDFS est la base de vAIR, qui fournit un stockage de données distribué et tolérant aux pannes sur l'ensemble du cluster. L'une des caractéristiques distinctives (mais pas la seule) d'ARDFS est qu'il n'utilise aucun serveur dédié supplémentaire pour les métadonnées et la gestion. Celui-ci a été conçu à l'origine pour simplifier la configuration de la solution et pour sa fiabilité.
Structure de stockage
Au sein de tous les nœuds du cluster, ARDFS organise un pool logique à partir de tout l'espace disque disponible. Il est important de comprendre qu'un pool n'est pas encore constitué de données ou d'espace formaté, mais simplement de balisage, c'est-à-dire Tous les nœuds sur lesquels vAIR est installé, lorsqu'ils sont ajoutés au cluster, sont automatiquement ajoutés au pool ARDFS partagé et les ressources de disque sont automatiquement partagées sur l'ensemble du cluster (et disponibles pour le stockage futur des données). Cette approche vous permet d'ajouter et de supprimer des nœuds à la volée sans aucun impact sérieux sur le système déjà en cours d'exécution. Ceux. le système est très facile à mettre à l'échelle « en briques », en ajoutant ou en supprimant des nœuds dans le cluster si nécessaire.
Des disques virtuels (objets de stockage pour machines virtuelles) sont ajoutés au-dessus du pool ARDFS, qui sont construits à partir de blocs virtuels d'une taille de 4 mégaoctets. Les disques virtuels stockent directement les données. Le schéma de tolérance aux pannes est également défini au niveau du disque virtuel.
Comme vous l'avez peut-être déjà deviné, pour la tolérance aux pannes du sous-système de disque, nous n'utilisons pas le concept de RAID (Redundant array of Independent Disks), mais utilisons RAIN (Redundant array of Independent Nodes). Ceux. La tolérance aux pannes est mesurée, automatisée et gérée en fonction des nœuds et non des disques. Les disques, bien sûr, sont aussi un objet de stockage, ils sont, comme tout le reste, surveillés, vous pouvez effectuer toutes les opérations standards avec eux, y compris l'assemblage d'un RAID matériel local, mais le cluster fonctionne spécifiquement sur les nœuds.
Dans une situation où vous souhaitez vraiment du RAID (par exemple, un scénario prenant en charge plusieurs pannes sur de petits clusters), rien ne vous empêche d'utiliser des contrôleurs RAID locaux et de créer un stockage étendu et une architecture RAIN par-dessus. Ce scénario est assez réel et est pris en charge par nous, nous en parlerons donc dans un article sur les scénarios typiques d'utilisation de vAIR.
Schémas de tolérance aux pannes de stockage
Il peut exister deux schémas de tolérance aux pannes pour les disques virtuels dans vAIR :
1) Facteur de réplication ou simplement réplication - cette méthode de tolérance aux pannes est aussi simple qu'un bâton et une corde. La réplication synchrone est effectuée entre les nœuds avec un facteur de 2 (2 copies par cluster) ou 3 (3 copies, respectivement). RF-2 permet à un disque virtuel de résister à la panne d'un nœud du cluster, mais « mange » la moitié du volume utile, et RF-3 résistera à la panne de 2 nœuds du cluster, mais réserve les 2/3 du volume utile pour ses besoins. Ce schéma est très similaire à RAID-1, c'est-à-dire qu'un disque virtuel configuré en RF-2 résiste à la panne de n'importe quel nœud du cluster. Dans ce cas, tout ira bien avec les données et même les E/S ne s'arrêteront pas. Lorsque le nœud tombé revient en service, la récupération/synchronisation automatique des données commencera.
Vous trouverez ci-dessous des exemples de distribution des données RF-2 et RF-3 en mode normal et en situation de panne.
Nous disposons d'une machine virtuelle d'une capacité de 8 Mo de données uniques (utiles), qui fonctionne sur 4 nœuds vAIR. Il est clair qu'en réalité, il est peu probable qu'il y ait un si petit volume, mais pour un schéma qui reflète la logique de fonctionnement de l'ARDFS, cet exemple est le plus compréhensible. AB sont des blocs virtuels de 4 Mo contenant des données de machine virtuelle uniques. RF-2 crée respectivement deux copies de ces blocs A1+A2 et B1+B2. Ces blocs sont « disposés » sur les nœuds, évitant ainsi l'intersection des mêmes données sur le même nœud, c'est-à-dire que la copie A1 ne sera pas située sur le même nœud que la copie A2. Idem avec B1 et B2.
Si l'un des nœuds tombe en panne (par exemple le nœud n°3 qui contient une copie de B1), cette copie est automatiquement activée sur le nœud où il n'y a pas de copie de sa copie (c'est-à-dire une copie de B2).
Ainsi, le disque virtuel (et la machine virtuelle, par conséquent) peut facilement survivre à la panne d'un nœud du schéma RF-2.
Le schéma de réplication, bien que simple et fiable, souffre du même problème que RAID1 : pas assez d'espace utilisable.
2) Le codage d'effacement ou codage d'effacement (également connu sous le nom de « codage redondant », « codage d'effacement » ou « code de redondance ») existe pour résoudre le problème ci-dessus. EC est un système de redondance qui offre une haute disponibilité des données avec une surcharge d'espace disque inférieure à celle de la réplication. Le principe de fonctionnement de ce mécanisme est similaire au RAID 5, 6, 6P.
Lors du codage, le processus EC divise un bloc virtuel (4 Mo par défaut) en plusieurs « morceaux de données » plus petits en fonction du schéma EC (par exemple, un schéma 2+1 divise chaque bloc de 4 Mo en 2 morceaux de 2 Mo). Ensuite, ce processus génère des « morceaux de parité » pour les « morceaux de données » qui ne sont pas plus grands que l'une des parties précédemment divisées. Lors du décodage, EC génère les morceaux manquants en lisant les données « survivantes » sur l’ensemble du cluster.
Par exemple, un disque virtuel avec un schéma EC 2 + 1, implémenté sur 4 nœuds de cluster, résistera facilement à la panne d'un nœud du cluster de la même manière que RF-2. Dans ce cas, les frais généraux seront inférieurs, notamment le coefficient de capacité utile pour RF-2 est de 2, et pour EC 2+1 il sera de 1,5.
Pour le décrire plus simplement, l'essentiel est que le bloc virtuel est divisé en 2 à 8 (pourquoi de 2 à 8, voir ci-dessous) « morceaux », et pour ces morceaux des « morceaux » de parité d'un volume similaire sont calculés.
En conséquence, les données et la parité sont réparties uniformément sur tous les nœuds du cluster. Dans le même temps, comme pour la réplication, ARDFS distribue automatiquement les données entre les nœuds de manière à empêcher que des données identiques (copies de données et leur parité) soient stockées sur le même nœud, afin d'éliminer le risque de perte de données due à la réplication. au fait que les données et leur parité se retrouveront soudainement sur un nœud de stockage en panne.
Vous trouverez ci-dessous un exemple, avec la même machine virtuelle de 8 Mo et 4 nœuds, mais avec un schéma EC 2+1.
Les blocs A et B sont divisés en deux morceaux de 2 Mo chacun (deux car 2+1), c'est-à-dire A1+A2 et B1+B2. Contrairement à une réplique, A1 n'est pas une copie de A2, c'est un bloc virtuel A, divisé en deux parties, de même que le bloc B. Au total, nous obtenons deux ensembles de 4 Mo, dont chacun contient deux morceaux de deux Mo. Ensuite, pour chacun de ces ensembles, la parité est calculée avec un volume ne dépassant pas une pièce (soit 2 Mo), on obtient + 2 pièces de parité supplémentaires (AP et BP). Au total, nous avons 4×2 données + 2×2 parité.
Ensuite, les morceaux sont « disposés » entre les nœuds afin que les données ne croisent pas leur parité. Ceux. A1 et A2 ne seront pas sur le même nœud que AP.
En cas de panne d'un nœud (par exemple également le troisième), le bloc tombé B1 sera automatiquement restauré à partir de la parité BP, qui est stockée sur le nœud n°2, et sera activé sur le nœud où se trouve pas de parité B, c'est-à-dire morceau de BP. Dans cet exemple, il s'agit du nœud n°1
Je suis sûr que le lecteur a une question :
« Tout ce que vous avez décrit a longtemps été implémenté à la fois par des concurrents et dans des solutions open source. Quelle est la différence entre votre implémentation d'EC dans ARDFS ? »
Et puis il y aura des fonctionnalités intéressantes d’ARDFS.
Effacement du codage en mettant l’accent sur la flexibilité
Initialement, nous avons fourni un schéma EC X+Y assez flexible, où X est égal à un nombre de 2 à 8, et Y est égal à un nombre de 1 à 8, mais toujours inférieur ou égal à X. Ce schéma est fourni pour la flexibilité. L'augmentation du nombre de morceaux de données (X) dans lesquels le bloc virtuel est divisé permet de réduire les frais généraux, c'est-à-dire d'augmenter l'espace utilisable.
L'augmentation du nombre de morceaux de parité (Y) augmente la fiabilité du disque virtuel. Plus la valeur Y est grande, plus le nombre de nœuds du cluster pouvant échouer est élevé. Bien entendu, l’augmentation du volume de parité réduit la quantité de capacité utilisable, mais c’est le prix à payer pour la fiabilité.
La dépendance des performances sur les circuits EC est presque directe : plus il y a de « pièces », plus les performances sont faibles ; ici, bien sûr, une vision équilibrée est nécessaire.
Cette approche permet aux administrateurs de configurer le stockage étendu avec une flexibilité maximale. Au sein du pool ARDFS, vous pouvez utiliser n'importe quel schéma de tolérance aux pannes et leurs combinaisons, ce qui, à notre avis, est également très utile.
Vous trouverez ci-dessous un tableau comparant plusieurs schémas RF et EC (pas tous possibles).
Le tableau montre que même la combinaison la plus « éponge » EC 8+7, qui permet la perte simultanée de jusqu'à 7 nœuds dans un cluster, « mange » moins d'espace utilisable (1,875 contre 2) que la réplication standard, et protège 7 fois mieux , ce qui rend ce mécanisme de protection, bien que plus complexe, beaucoup plus attractif dans les situations où il est nécessaire d'assurer une fiabilité maximale dans des conditions d'espace disque limité. Dans le même temps, vous devez comprendre que chaque « plus » par rapport à X ou Y sera une surcharge de performances supplémentaire, donc dans le triangle entre fiabilité, économies et performances, vous devez choisir très soigneusement. Pour cette raison, nous consacrerons un article séparé au dimensionnement du codage d’effacement.
Fiabilité et autonomie du système de fichiers
ARDFS s'exécute localement sur tous les nœuds du cluster et les synchronise par ses propres moyens via des interfaces Ethernet dédiées. Le point important est qu'ARDFS synchronise indépendamment non seulement les données, mais également les métadonnées liées au stockage. En travaillant sur ARDFS, nous avons étudié simultanément un certain nombre de solutions existantes et avons découvert que beaucoup synchronisaient les métadonnées du système de fichiers à l'aide d'un SGBD distribué externe, que nous utilisons également pour la synchronisation, mais uniquement pour les configurations, pas pour les métadonnées FS (à ce sujet et d'autres sous-systèmes associés dans le prochain article).
La synchronisation des métadonnées FS à l'aide d'un SGBD externe est, bien sûr, une solution efficace, mais la cohérence des données stockées sur ARDFS dépendrait alors du SGBD externe et de son comportement (et, franchement, c'est une dame capricieuse), qui en notre avis est mauvais. Pourquoi? Si les métadonnées FS sont endommagées, les données FS elles-mêmes peuvent également être dites « au revoir », nous avons donc décidé d'emprunter une voie plus complexe mais plus fiable.
Nous avons créé nous-mêmes le sous-système de synchronisation des métadonnées pour ARDFS, et il vit complètement indépendamment des sous-systèmes adjacents. Ceux. aucun autre sous-système ne peut corrompre les données ARDFS. À notre avis, c'est la méthode la plus fiable et la plus correcte, mais le temps nous dira si c'est réellement le cas. De plus, cette approche présente un avantage supplémentaire. ARDFS peut être utilisé indépendamment de vAIR, tout comme le stockage étiré, que nous utiliserons certainement dans les futurs produits.
En conséquence, en développant ARDFS, nous avons obtenu un système de fichiers flexible et fiable qui vous permet de choisir entre économiser de la capacité ou tout abandonner en termes de performances, ou créer un stockage ultra-fiable à un coût raisonnable, mais en réduisant les exigences de performances.
Associé à une politique de licence simple et à un modèle de livraison flexible (à l'avenir, vAIR est concédé sous licence par nœud et livré sous forme de logiciel ou de progiciel), cela vous permet d'adapter très précisément la solution à une grande variété d'exigences des clients et puis maintenir facilement cet équilibre.
Qui a besoin de ce miracle ?
D’une part, on peut dire qu’il existe déjà sur le marché des acteurs qui ont des solutions sérieuses dans le domaine de l’hyperconvergence, et c’est effectivement vers cela que nous nous dirigeons. Il semble que cette affirmation soit vraie, MAIS...
En revanche, lorsque nous allons sur le terrain et communiquons avec les clients, nous et nos partenaires constatons que ce n'est pas du tout le cas. Il existe de nombreuses tâches liées à l'hyperconvergence : dans certains endroits, les gens ne savaient tout simplement pas que de telles solutions existaient, dans d'autres, cela semblait coûteux, dans d'autres, des tests de solutions alternatives ont été infructueux et, dans d'autres, ils ont interdit d'acheter en raison de sanctions. En général, le champ s'est avéré non labouré, nous sommes donc allés cultiver de la terre vierge))).
Quand le système de stockage est-il meilleur que GKS ?
Lorsque nous travaillons avec le marché, on nous demande souvent quand il est préférable d'utiliser un schéma classique avec des systèmes de stockage, et quand utiliser l'hyperconvergent ? De nombreuses entreprises produisant des GCS (en particulier celles qui n'ont pas de systèmes de stockage dans leur portefeuille) déclarent : « Les systèmes de stockage deviennent obsolètes, uniquement hyperconvergés ! » C’est une déclaration audacieuse, mais elle ne reflète pas entièrement la réalité.
En vérité, le marché du stockage évolue effectivement vers l’hyperconvergence et les solutions similaires, mais il y a toujours un « mais ».
Premièrement, les centres de données et les infrastructures informatiques construits selon le schéma classique avec des systèmes de stockage ne peuvent pas être facilement reconstruits, de sorte que la modernisation et l'achèvement de ces infrastructures restent un héritage pour 5 à 7 ans.
Deuxièmement, l'infrastructure actuellement en construction pour la plupart (c'est-à-dire la Fédération de Russie) est construite selon le schéma classique utilisant des systèmes de stockage, non pas parce que les gens ne connaissent pas l'hyperconvergence, mais parce que le marché de l'hyperconvergence est nouveau, des solutions et les normes ne sont pas encore établies, les informaticiens ne sont pas encore formés, ils ont peu d'expérience, mais ils doivent construire des centres de données ici et maintenant. Et cette tendance durera encore 3 à 5 ans (et puis un autre héritage, voir point 1).
Troisièmement, il existe une limitation purement technique dans les petits délais supplémentaires de 2 millisecondes par écriture (hors cache local, bien sûr), qui constituent le coût du stockage distribué.
Eh bien, n'oublions pas l'utilisation de grands serveurs physiques qui aiment la mise à l'échelle verticale du sous-système de disque.
Il existe de nombreuses tâches nécessaires et populaires pour lesquelles les systèmes de stockage se comportent mieux que GCS. Ici, bien sûr, les fabricants qui n'ont pas de systèmes de stockage dans leur portefeuille de produits ne seront pas d'accord avec nous, mais nous sommes prêts à argumenter raisonnablement. Bien entendu, en tant que développeurs des deux produits, nous comparerons certainement les systèmes de stockage et les GCS dans l'une de nos futures publications, où nous démontrerons clairement lequel est le meilleur dans quelles conditions.
Et dans quels domaines les solutions hyperconvergées fonctionneront-elles mieux que les systèmes de stockage ?
Sur la base des points ci-dessus, trois conclusions évidentes peuvent être tirées :
- Là où 2 millisecondes supplémentaires de latence pour l'enregistrement, qui se produisent systématiquement dans n'importe quel produit (nous ne parlons plus de synthétiques, des nanosecondes peuvent être affichées sur les synthétiques), ne sont pas critiques, l'hyperconvergent convient.
- Là où la charge des grands serveurs physiques peut être transformée en plusieurs petits serveurs virtuels et répartie entre les nœuds, l'hyperconvergence fonctionnera également bien là-bas.
- Là où la mise à l’échelle horizontale est une priorité plus élevée que la mise à l’échelle verticale, GCS fera également l’affaire.
Quelles sont ces solutions ?
- Tous les services d'infrastructure standards (service d'annuaire, messagerie, EDMS, serveurs de fichiers, petits ou moyens systèmes ERP et BI, etc.). Nous appelons cela « l’informatique générale ».
- L'infrastructure des fournisseurs de cloud, où il est nécessaire d'étendre horizontalement de manière rapide et standardisée et de « couper » facilement un grand nombre de machines virtuelles pour les clients.
- Infrastructure de bureau virtuel (VDI), où de nombreuses machines virtuelles de petits utilisateurs s'exécutent et « flottent » silencieusement au sein d'un cluster uniforme.
- Réseaux de succursales, où chaque succursale a besoin d'une infrastructure standard, tolérante aux pannes mais peu coûteuse, composée de 15 à 20 machines virtuelles.
- Toute informatique distribuée (services big data par exemple). Où la charge ne va pas « en profondeur », mais « en largeur ».
- Environnements de test dans lesquels de petits délais supplémentaires sont acceptables, mais il existe des restrictions budgétaires, car ce sont des tests.
Pour le moment, c'est pour ces tâches que nous avons réalisé AERODISK vAIR et c'est sur elles que nous nous concentrons (avec succès jusqu'à présent). Peut-être que cela changera bientôt, parce que... le monde ne reste pas immobile.
Alors ...
Ceci complète la première partie d'une large série d'articles ; dans le prochain article nous parlerons de l'architecture de la solution et des composants utilisés.
Nous acceptons les questions, les suggestions et les différends constructifs.
Source: habr.com