{"id":38542,"date":"2019-10-31T22:24:25","date_gmt":"2019-10-31T19:24:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs\/"},"modified":"2019-10-31T22:24:25","modified_gmt":"2019-10-31T19:24:25","slug":"giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"Solution hyperconvergente AERODISK vAIR. Bas\u00e9e sur le syst\u00e8me de fichiers ARDFS.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Solution<\/p>\n

<\/p>\n

Bonjour, lecteurs de Habr. Cet article marque le d\u00e9but d'une s\u00e9rie qui pr\u00e9sentera notre syst\u00e8me hyperconverg\u00e9 AERODISK vAIR. Dans un premier temps, nous avions pr\u00e9vu de tout expliquer dans cet article d'introduction, mais le syst\u00e8me \u00e9tant assez complexe, nous allons y aller progressivement. <\/p>\n

<\/p>\n

Nous commencerons par l'histoire de la cr\u00e9ation du syst\u00e8me, en nous plongeant dans le syst\u00e8me de fichiers ARDFS, qui constitue la base de vAIR, et en r\u00e9fl\u00e9chissant un peu \u00e0 la position de cette solution sur le march\u00e9 russe. <\/p>\n

<\/p>\n

Dans les articles suivants, nous expliquerons en d\u00e9tail les diff\u00e9rents composants architecturaux (cluster, hyperviseur, r\u00e9partiteur de charge, syst\u00e8me de surveillance, etc.), le processus de configuration, nous aborderons les questions de licence, nous d\u00e9montrerons des tests de r\u00e9sistance et, bien entendu, nous traiterons des tests de charge et du sizing. De plus, un article sera d\u00e9di\u00e9 \u00e0 la version communautaire de vAIR.<\/p>\n

<\/a><\/noindex><\/p>\n

AERODISK, est-ce vraiment une histoire de stockage? Ou pourquoi avons-nous m\u00eame commenc\u00e9 \u00e0 travailler sur l'hyperconvergence?<\/h2>\n

<\/p>\n

L'id\u00e9e de cr\u00e9er notre propre solution hyperconverg\u00e9e nous est venue aux alentours de 2010. \u00c0 l'\u00e9poque, il n'existait ni AERODISK ni de syst\u00e8mes hyperconverg\u00e9s commerciaux sur le march\u00e9. Notre objectif \u00e9tait le suivant : \u00e0 partir d'un ensemble de serveurs avec des disques locaux, interconnect\u00e9s via un protocole Ethernet, cr\u00e9er un stockage distribu\u00e9 et y faire fonctionner des machines virtuelles et un r\u00e9seau logiciel. Le tout devait \u00eatre r\u00e9alis\u00e9 sans syst\u00e8me de stockage (car nous n'avions pas les moyens d'acheter un syst\u00e8me de stockage ni d'en concevoir un \u00e0 l'\u00e9poque).<\/p>\n

<\/p>\n

Nous avons test\u00e9 de nombreuses solutions open source et avons finalement r\u00e9ussi, mais la solution \u00e9tait tr\u00e8s complexe et difficile \u00e0 reproduire. De plus, cette solution relevait de la cat\u00e9gorie \"\u00c7a fonctionne? Ne touche pas!\". Donc, ayant r\u00e9solu ce probl\u00e8me, nous n'avons pas continu\u00e9 \u00e0 d\u00e9velopper l'id\u00e9e de transformer le r\u00e9sultat de notre travail en un produit complet. <\/p>\n

<\/p>\n

Apr\u00e8s cette exp\u00e9rience, nous avons laiss\u00e9 cette id\u00e9e de c\u00f4t\u00e9, mais nous n'avons pas cess\u00e9 de sentir que cette probl\u00e9matique \u00e9tait tout \u00e0 fait soluble et que les avantages d'une telle solution \u00e9taient plus que \u00e9vidents. Par la suite, les produits HCI lanc\u00e9s par des entreprises \u00e9trang\u00e8res n'ont fait que confirmer ce sentiment. <\/p>\n

<\/p>\n

C'est pourquoi, au milieu de l'ann\u00e9e 2016, nous sommes revenus \u00e0 cette t\u00e2che dans le cadre de la cr\u00e9ation d'un produit complet. \u00c0 l'\u00e9poque, nous n'avions pas encore de relations avec des investisseurs, c'est pourquoi nous avons d\u00fb acheter notre stand de d\u00e9veloppement avec nos modestes fonds. En cherchant sur Avito des serveurs et des commutateurs d'occasion, nous nous sommes mis au travail.<\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

La principale t\u00e2che initiale \u00e9tait de cr\u00e9er notre propre syst\u00e8me de fichiers, bien que simple, mais qui pourrait automatiquement et uniform\u00e9ment r\u00e9partir les donn\u00e9es sous forme de blocs virtuels sur un nombre n de n\u0153uds de cluster, interconnect\u00e9s par Ethernet. Ce syst\u00e8me de fichiers devait \u00eatre facilement \u00e9volutif et ind\u00e9pendant des syst\u00e8mes adjacents, c'est-\u00e0-dire pouvoir \u00eatre d\u00e9tach\u00e9 de vAIR en tant que \u00ab simple stockage \u00bb.<\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

Le premier concept de vAIR<\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

Nous avons d\u00e9lib\u00e9r\u00e9ment \u00e9vit\u00e9 d'utiliser des solutions open source pr\u00eates \u00e0 l'emploi pour organiser un stockage distribu\u00e9 (ceph, gluster, lustre et similaires) en faveur de notre propre d\u00e9veloppement, car nous avions d\u00e9j\u00e0 une exp\u00e9rience de projet significative avec eux. Sans aucun doute, ces solutions sont excellentes en soi, et avant de travailler sur Aerodisk, nous avons r\u00e9alis\u00e9 plusieurs projets d'int\u00e9gration avec elles. Mais il y a une diff\u00e9rence entre r\u00e9aliser une t\u00e2che sp\u00e9cifique pour un client, former le personnel et, \u00e9ventuellement, acheter le support d'un grand fournisseur, et cr\u00e9er un produit facilement reproductible qui sera utilis\u00e9 pour diff\u00e9rentes t\u00e2ches, dont nous, en tant que fournisseur, ne serons peut-\u00eatre m\u00eame pas conscients. Pour cet objectif, les produits open source existants ne nous convenaient pas, c'est pourquoi nous avons d\u00e9cid\u00e9 de d\u00e9velopper notre propre syst\u00e8me de fichiers distribu\u00e9.
\nApr\u00e8s deux ans de travail de plusieurs d\u00e9veloppeurs (qui combinaient leur travail sur vAIR avec celui d'un stockage classique Engine), nous avons obtenu un certain r\u00e9sultat.<\/p>\n

<\/p>\n

D'ici 2018, nous avions \u00e9crit un syst\u00e8me de fichiers tr\u00e8s simple et l'avions compl\u00e9t\u00e9 par l'encadrement n\u00e9cessaire. Le syst\u00e8me combinait via un interconnect interne des disques physiques (locaux) de diff\u00e9rents serveurs en un seul pool plat et les \u00ab d\u00e9coupait \u00bb en blocs virtuels ; ensuite, des dispositifs de bloc \u00e9taient cr\u00e9\u00e9s \u00e0 partir de ces blocs virtuels avec un certain niveau de tol\u00e9rance aux pannes, sur lesquels des machines virtuelles \u00e9taient cr\u00e9\u00e9es et ex\u00e9cut\u00e9es \u00e0 l'aide de l'hyperviseur KVM. <\/p>\n

<\/p>\n

Nous n'avons pas vraiment cherch\u00e9 \u00e0 compliquer le nom de notre syst\u00e8me de fichiers et l'avons sobrement appel\u00e9 ARDFS (devinez ce que cela signifie))<\/p>\n

<\/p>\n

Ce prototype avait fi\u00e8re allure (pas visuellement, bien s\u00fbr, il n'y avait pas encore de design \u00e0 l'\u00e9poque) et montrait de bonnes performances et une bonne \u00e9volutivit\u00e9. Apr\u00e8s le premier r\u00e9sultat concret, nous avons donn\u00e9 le feu vert \u00e0 ce projet, en organisant un environnement de d\u00e9veloppement complet et une \u00e9quipe distincte qui s'occupait uniquement de vAIR.<\/p>\n

<\/p>\n

\u00c0 ce moment-l\u00e0, l'architecture g\u00e9n\u00e9rale de la solution s'\u00e9tait justement form\u00e9e et n'a pas subi de changements majeurs depuis.<\/p>\n

<\/p>\n

Plong\u00e9e dans le syst\u00e8me de fichiers ARDFS<\/h2>\n

<\/p>\n

ARDFS est la base de vAIR, qui fournit un stockage de donn\u00e9es distribu\u00e9 et tol\u00e9rant aux pannes pour l'ensemble du cluster. L'une des (mais pas la seule) caract\u00e9ristiques distinctives d'ARDFS est qu'il n'utilise aucun suppl\u00e9ment de serveurs d\u00e9di\u00e9s<\/a> pour la gestion et le contr\u00f4le. Cela a \u00e9t\u00e9 con\u00e7u d\u00e8s le d\u00e9part pour simplifier la configuration de la solution et pour sa fiabilit\u00e9. <\/p>\n

<\/p>\n

Structure de stockage<\/h3>\n

<\/p>\n

\u00c0 travers toutes les n\u0153uds du cluster, ARDFS organise un pool logique de tout l'espace disque disponible. Il est important de comprendre que le pool n'est pas encore des donn\u00e9es ni un espace format\u00e9, mais simplement un balisage, c'est-\u00e0-dire que tous les n\u0153uds avec vAIR install\u00e9s, lorsqu'ils sont ajout\u00e9s au cluster, sont automatiquement int\u00e9gr\u00e9s au pool ARDFS et les ressources de disque deviennent automatiquement partag\u00e9es sur tout le cluster (et disponibles pour un stockage futur des donn\u00e9es). Cette approche permet d'ajouter et de supprimer des n\u0153uds \u00e0 la vol\u00e9e sans impact s\u00e9rieux sur le syst\u00e8me d\u00e9j\u00e0 en fonctionnement. Cela signifie que le syst\u00e8me est tr\u00e8s facile \u00e0 \u00e9voluer \u00ab brique par brique \u00bb, en ajoutant ou en retirant des n\u0153uds au cluster si n\u00e9cessaire.<\/p>\n

<\/p>\n

Au-dessus du pool ARDFS, des disques virtuels (objets de stockage pour les machines virtuelles) sont ajout\u00e9s, qui sont construits \u00e0 partir de blocs virtuels de 4 m\u00e9gaoctets. Les donn\u00e9es sont directement stock\u00e9es sur ces disques virtuels. Au niveau des disques virtuels, un sch\u00e9ma de tol\u00e9rance aux pannes est \u00e9galement d\u00e9fini. <\/p>\n

<\/p>\n

Comme vous pouvez d\u00e9j\u00e0 le deviner, pour la r\u00e9silience du syst\u00e8me de stockage, nous n'utilisons pas le concept de RAID (Redundant array of independent Disks), mais nous utilisons RAIN (Redundant array of independent Nodes). C'est-\u00e0-dire que la r\u00e9silience est mesur\u00e9e, automatis\u00e9e et g\u00e9r\u00e9e en fonction des n\u0153uds, et non des disques. Les disques, bien s\u00fbr, sont \u00e9galement un objet de stockage, ils, comme tout le reste, sont surveill\u00e9s, et toutes les op\u00e9rations standard peuvent \u00eatre effectu\u00e9es avec eux, y compris la cr\u00e9ation de RAID mat\u00e9riel local, mais le cluster op\u00e8re uniquement sur des n\u0153uds. <\/p>\n

<\/p>\n

Dans une situation o\u00f9 l'on d\u00e9sire vraiment RAID (par exemple, un sc\u00e9nario supportant de multiples pannes sur de petits clusters), rien n'emp\u00eache d'utiliser des contr\u00f4leurs RAID locaux et de cr\u00e9er au-dessus un stockage \u00e9tendu et une architecture RAIN. Ce sc\u00e9nario est tout \u00e0 fait viable et nous le supportons, c'est pourquoi nous en parlerons dans l'article sur les sc\u00e9narios typiques d'application de vAIR.<\/p>\n

<\/p>\n

Sch\u00e9mas de r\u00e9silience du stockage<\/h3>\n

<\/p>\n

Il peut y avoir deux sch\u00e9mas de r\u00e9silience des disques virtuels dans vAIR :<\/p>\n

<\/p>\n

1) Facteur de r\u00e9plication ou simplement r\u00e9plication \u2013 cette m\u00e9thode de r\u00e9silience est aussi simple que \u00ab une b\u00e2ton et une corde \u00bb. Elle consiste en une r\u00e9plication synchrone entre les n\u0153uds avec un facteur de 2 (2 copies par cluster) ou 3 (3 copies, respectivement). RF-2 permet au disque virtuel de supporter la panne d'un n\u0153ud dans le cluster, mais \u00ab consomme \u00bb la moiti\u00e9 de l'espace utile, tandis que RF-3 supportera la panne de 2 n\u0153uds dans le cluster, mais r\u00e9servera d\u00e9j\u00e0 2\/3 de l'espace utile \u00e0 ses propres besoins. Ce sch\u00e9ma ressemble beaucoup \u00e0 RAID-1, c'est-\u00e0-dire qu'un disque virtuel configur\u00e9 en RF-2 est r\u00e9sistant \u00e0 la panne de n'importe quel n\u0153ud du cluster. Dans ce cas, les donn\u00e9es seront en s\u00e9curit\u00e9 et m\u00eame l'entr\u00e9e-sortie ne s'arr\u00eatera pas. Lorsque le n\u0153ud d\u00e9faillant sera de retour, la r\u00e9cup\u00e9ration automatique\/synchronisation des donn\u00e9es commencera. <\/p>\n

<\/p>\n

Ci-dessous des exemples de distribution des donn\u00e9es RF-2 et RF-3 en mode normal et en cas de pannes.<\/p>\n

<\/p>\n

Nous avons une machine virtuelle de 8 Mo de donn\u00e9es uniques (utiles) fonctionnant sur 4 n\u0153uds vAIR. Il est \u00e9vident qu'en r\u00e9alit\u00e9, un tel petit volume sera peu probable, mais cet exemple est le plus clair pour illustrer la logique de fonctionnement de l'ARDFS. AB repr\u00e9sente des blocs virtuels de 4 Mo contenant des donn\u00e9es uniques de la machine virtuelle. Avec RF-2, deux copies de ces blocs A1+A2 et B1+B2 sont cr\u00e9\u00e9es. Ces blocs sont \"r\u00e9partis\" sur les n\u0153uds, \u00e9vitant la duplication des m\u00eames donn\u00e9es sur un seul n\u0153ud, c'est-\u00e0-dire que la copie A1 ne sera pas sur le m\u00eame n\u0153ud que la copie A2. Il en va de m\u00eame pour B1 et B2.<\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

En cas de d\u00e9faillance d'un des n\u0153uds (par exemple, le n\u0153ud n\u00b03, o\u00f9 se trouve la copie B1), cette copie est automatiquement activ\u00e9e sur un n\u0153ud o\u00f9 sa copie (c'est-\u00e0-dire la copie B2) n'est pas pr\u00e9sente. <\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

Ainsi, le disque virtuel (et la VM, par cons\u00e9quent) peuvent facilement survivre \u00e0 la d\u00e9faillance d'un n\u0153ud dans le sch\u00e9ma RF-2.<\/p>\n

<\/p>\n

Le sch\u00e9ma de r\u00e9plication, malgr\u00e9 sa simplicit\u00e9 et sa fiabilit\u00e9, souffre du m\u00eame probl\u00e8me que le RAID1 : peu d'espace utile.<\/p>\n

<\/p>\n

2) Le codage par effacement ou erasure coding (\u00e9galement connu sous les noms de \u00ab codage redondant \u00bb, \u00ab codage d'effacement \u00bb ou \u00ab code de redondance \u00bb) existe pr\u00e9cis\u00e9ment pour r\u00e9soudre le probl\u00e8me ci-dessus. EC est un sch\u00e9ma de redondance qui assure une haute disponibilit\u00e9 des donn\u00e9es avec des frais g\u00e9n\u00e9raux d'espace disque moindres que ceux de la r\u00e9plication. Le principe de fonctionnement de ce m\u00e9canisme est similaire \u00e0 celui du RAID 5, 6, 6P. <\/p>\n

<\/p>\n

Lors du codage, le processus EC divise le bloc virtuel (par d\u00e9faut 4 Mo) en plusieurs \u00ab morceaux de donn\u00e9es \u00bb plus petits en fonction du sch\u00e9ma EC (par exemple, le sch\u00e9ma 2+1 divise chaque bloc de 4 Mo en 2 morceaux de 2 Mo). Ensuite, ce processus g\u00e9n\u00e8re pour les \u00ab morceaux de donn\u00e9es \u00bb des \u00ab morceaux de parit\u00e9 \u00bb d'une taille ne d\u00e9passant pas celle des parties pr\u00e9c\u00e9demment divis\u00e9es. Lors du d\u00e9codage, EC g\u00e9n\u00e8re les morceaux manquants en lisant les donn\u00e9es \u00ab survivantes \u00bb \u00e0 travers le cluster. <\/p>\n

<\/p>\n

Par exemple, un disque virtuel avec un sch\u00e9ma EC 2 + 1, d\u00e9ploy\u00e9 sur 4 n\u0153uds d'un cluster, peut r\u00e9sister \u00e0 la d\u00e9faillance d'un n\u0153ud dans le cluster tout aussi bien que le RF-2. Dans ce cas, les frais g\u00e9n\u00e9raux seront moindres, en particulier le facteur d'utilit\u00e9 dans RF-2 est de 2, tandis que pour EC 2+1, il sera de 1,5. <\/p>\n

<\/p>\n

Pour r\u00e9sumer simplement, le principe consiste \u00e0 diviser un bloc virtuel en 2 \u00e0 8 (pourquoi de 2 \u00e0 8, voir ci-dessous) \u00ab morceaux \u00bb, et pour ces morceaux, des \u00ab morceaux \u00bb de parit\u00e9 de volume similaire sont calcul\u00e9s. <\/p>\n

<\/p>\n

Les donn\u00e9es et leur parit\u00e9 sont donc uniform\u00e9ment r\u00e9parties sur tous les n\u0153uds du cluster. Comme pour la r\u00e9plication, ARDFS r\u00e9partit automatiquement les donn\u00e9es sur les n\u0153uds afin d'\u00e9viter que des donn\u00e9es identiques (copies des donn\u00e9es et de leur parit\u00e9) ne soient stock\u00e9es sur un m\u00eame n\u0153ud, afin d'exclure la possibilit\u00e9 de perdre des donn\u00e9es si les donn\u00e9es et leur parit\u00e9 se retrouvaient soudainement sur un n\u0153ud de stockage qui tomberait en panne. <\/p>\n

<\/p>\n

Voici un exemple, avec la m\u00eame machine virtuelle de 8 Mo et 4 n\u0153uds, mais avec un sch\u00e9ma EC 2+1. <\/p>\n

<\/p>\n

Les blocs A et B sont divis\u00e9s en deux morceaux de 2 Mo chacun (en deux parce que 2+1), c'est-\u00e0-dire en A1+A2 et B1+B2. Contrairement \u00e0 la r\u00e9plique, A1 n'est pas une copie de A2, c'est un bloc virtuel A, s\u00e9par\u00e9 en deux parties, il en va de m\u00eame pour le bloc B. Au total, nous obtenons deux ensembles de 4 Mo, chacun contenant deux morceaux de deux m\u00e9gaoctets. Ensuite, pour chacun de ces ensembles, on calcule la parit\u00e9 d'un volume ne d\u00e9passant pas un morceau (c'est-\u00e0-dire 2 Mo), ce qui nous donne en plus + 2 morceaux de parit\u00e9 (A-P et B-P). En tout, nous avons 4\u00d72 donn\u00e9es + 2\u00d72 de parit\u00e9.<\/p>\n

<\/p>\n

Ensuite, les morceaux sont 'r\u00e9partis' sur les n\u0153uds de mani\u00e8re \u00e0 ce que les donn\u00e9es ne croisent pas leur parit\u00e9. C'est-\u00e0-dire que A1 et A2 ne seront pas sur le m\u00eame n\u0153ud que A-P.<\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

En cas de d\u00e9faillance d'un n\u0153ud (disons, le troisi\u00e8me), le bloc B1 tomb\u00e9 sera automatiquement restaur\u00e9 \u00e0 partir de la parit\u00e9 B-P, qui est stock\u00e9e sur le n\u0153ud n\u00b02, et sera activ\u00e9 sur le n\u0153ud o\u00f9 il n'y a pas de parit\u00e9 B, c'est-\u00e0-dire le morceau B-P. Dans cet exemple, c'est le n\u0153ud n\u00b01.<\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

Je suis s\u00fbr que le lecteur se pose la question :<\/p>\n

<\/p>\n

\u00ab Tout ce que vous avez d\u00e9crit a d\u00e9j\u00e0 \u00e9t\u00e9 r\u00e9alis\u00e9 par des concurrents et dans des solutions open source, quelle est la diff\u00e9rence avec votre impl\u00e9mentation EC dans ARDFS ? \u00bb<\/p><\/blockquote>\n

Et ensuite, nous parlerons des caract\u00e9ristiques int\u00e9ressantes du fonctionnement d'ARDFS.<\/p>\n

<\/p>\n

Codage de rupture ax\u00e9 sur la flexibilit\u00e9<\/h3>\n

<\/p>\n

Initialement, nous avons pr\u00e9vu un sch\u00e9ma EC X+Y assez flexible, o\u00f9 X est un nombre de 2 \u00e0 8, et Y est un nombre de 1 \u00e0 8, mais toujours inf\u00e9rieur ou \u00e9gal \u00e0 X. Ce sch\u00e9ma est con\u00e7u pour la flexibilit\u00e9. Augmenter le nombre de morceaux de donn\u00e9es (X) sur lesquels un bloc virtuel est divis\u00e9 permet de r\u00e9duire les co\u00fbts g\u00e9n\u00e9raux, c'est-\u00e0-dire d'augmenter l'espace utile.
\nL'augmentation du nombre de morceaux de parit\u00e9 (Y) accro\u00eet la fiabilit\u00e9 du disque virtuel. Plus la valeur de Y est \u00e9lev\u00e9e, plus le nombre de n\u0153uds dans le cluster peut tomber en panne. Bien s\u00fbr, augmenter le volume de parit\u00e9 r\u00e9duit la capacit\u00e9 utile, mais c'est le prix \u00e0 payer pour la fiabilit\u00e9. <\/p>\n

<\/p>\n

La d\u00e9pendance des performances par rapport aux sch\u00e9mas EC est presque directe : plus il y a de \u00ab morceaux \u00bb, plus la performance est faible. Il est donc clair qu'une vue \u00e9quilibr\u00e9e est n\u00e9cessaire. <\/p>\n

<\/p>\n

Cette approche permet aux administrateurs de configurer de mani\u00e8re maximale et flexible le stockage \u00e9tendu. Dans le cadre de la pool ARDFS, il est possible d'utiliser n'importe quels sch\u00e9mas de tol\u00e9rance de panne et leurs combinaisons, ce qui est \u00e9galement tr\u00e8s utile \u00e0 notre avis. <\/p>\n

<\/p>\n

Ci-dessous se trouve un tableau comparatif de plusieurs (mais non tous les) sch\u00e9mas RF et EC.<\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

Il ressort du tableau que m\u00eame la combinaison EC 8+7 la plus 'extr\u00eame', permettant la perte simultan\u00e9e de jusqu'\u00e0 7 n\u0153uds dans le cluster, consomme moins d'espace utile (1,875 contre 2) que la r\u00e9plication standard, tout en prot\u00e9geant 7 fois mieux, ce qui rend ce m\u00e9canisme de protection, bien que plus complexe, significativement plus attrayant dans les situations o\u00f9 il est n\u00e9cessaire d'assurer une fiabilit\u00e9 maximale en raison d'un manque d'espace disque. Il est \u00e0 comprendre que chaque 'plus' \u00e0 X ou Y sera une surcharge suppl\u00e9mentaire sur les performances, il est donc crucial de faire un choix tr\u00e8s attentif dans le triangle entre fiabilit\u00e9, \u00e9conomies et performances. Pour cette raison, nous consacrerons un article s\u00e9par\u00e9 au sizing de l'encodage \u00e0 distance.<\/p>\n

<\/p>\n

\"Solution<\/p>\n

<\/p>\n

Fiabilit\u00e9 et autonomie du syst\u00e8me de fichiers<\/h3>\n

<\/p>\n

ARDFS est ex\u00e9cut\u00e9 localement sur tous les n\u0153uds du cluster et synchronise ses propres moyens via des interfaces Ethernet d\u00e9di\u00e9es. Un point important est que ARDFS synchronise non seulement les donn\u00e9es, mais aussi les m\u00e9tadonn\u00e9es relatives au stockage. Pendant le d\u00e9veloppement d'ARDFS, nous avons \u00e9galement \u00e9tudi\u00e9 un certain nombre de solutions existantes et d\u00e9couvert que beaucoup synchronisent les m\u00e9tadonn\u00e9es du syst\u00e8me de fichiers \u00e0 l'aide d'une base de donn\u00e9es distribu\u00e9e externe, que nous utilisons \u00e9galement pour la synchronisation, mais uniquement des configurations et non des m\u00e9tadonn\u00e9es FS (nous aborderons ce sujet et d'autres syst\u00e8mes connexes dans le prochain article). <\/p>\n

<\/p>\n

La synchronisation des m\u00e9tadonn\u00e9es du FS \u00e0 l'aide d'une SGBD externe est une solution fonctionnelle, mais la coh\u00e9rence des donn\u00e9es stock\u00e9es sur ARDFS d\u00e9pendrait alors de cette SGBD externe et de son comportement (qui est, il faut le dire, une dame capricieuse), ce qui, \u00e0 notre avis, est probl\u00e9matique. Pourquoi ? Si les m\u00e9tadonn\u00e9es du FS se d\u00e9t\u00e9riorent, on pourrait aussi dire \u00ab au revoir \u00bb aux donn\u00e9es du FS, c'est pourquoi nous avons d\u00e9cid\u00e9 de prendre une voie plus complexe mais fiable. <\/p>\n

<\/p>\n

Nous avons d\u00e9velopp\u00e9 nous-m\u00eames le sous-syst\u00e8me de synchronisation des m\u00e9tadonn\u00e9es pour ARDFS, et il fonctionne compl\u00e8tement ind\u00e9pendamment des sous-syst\u00e8mes adjacents. Autrement dit, aucun autre sous-syst\u00e8me ne peut endommager les donn\u00e9es d'ARDFS. \u00c0 notre avis, c'est la voie la plus fiable et correcte, mais le temps nous montrera si cela est r\u00e9ellement le cas. De plus, cette approche pr\u00e9sente un avantage suppl\u00e9mentaire. ARDFS peut \u00eatre utilis\u00e9 ind\u00e9pendamment de vAIR, simplement comme un stockage \u00e9tendu, ce dont nous tirerons n\u00e9cessairement parti dans nos futurs produits.<\/p>\n

<\/p>\n

En fin de compte, en d\u00e9veloppant ARDFS, nous avons obtenu un syst\u00e8me de fichiers flexible et fiable qui permet de choisir o\u00f9 \u00e9conomiser sur la capacit\u00e9 ou allouer toute la performance, ou faire du stockage un super fiable \u00e0 un co\u00fbt mod\u00e9r\u00e9 tout en r\u00e9duisant les exigences de performance. <\/p>\n

<\/p>\n

Avec une politique de licences simple et un mod\u00e8le de fourniture flexible (pour faire simple, vAIR est licenci\u00e9 par n\u0153uds et est fourni soit en logiciel, soit sous forme de PAK), cela permet de bien adapter la solution aux diverses exigences des clients et de maintenir facilement cet \u00e9quilibre par la suite. <\/p>\n

<\/p>\n

Qui a besoin de cette merveille ?<\/h2>\n

<\/p>\n

D'une part, on peut dire qu'il y a d\u00e9j\u00e0 des acteurs sur le march\u00e9 avec des solutions s\u00e9rieuses dans le domaine de l\u2019hyperconvergence, et o\u00f9 nous, en fait, tentons de nous imposer. Il semble que cette affirmation soit vraie, MAIS\u2026<\/p>\n

<\/p>\n

D'autre part, en allant \u00ab sur le terrain \u00bb et en discutant avec les clients, nous et nos partenaires constatons que ce n'est pas du tout le cas. Il y a de nombreuses t\u00e2ches pour l'hyperconvergence ; certaines personnes ne savaient tout simplement pas que de telles solutions existent, d'autres trouvaient cela co\u00fbteux, d'autres encore avaient des tests infructueux d'alternatives, et dans certains cas, il est m\u00eame interdit d'acheter en raison de sanctions. En gros, le champ s'est av\u00e9r\u00e9 inexplor\u00e9, c'est pourquoi nous avons d\u00e9cid\u00e9 de d\u00e9fricher cette terre))). <\/p>\n

<\/p>\n

Quand un SCD est-il meilleur qu'un GKS ?<\/h3>\n

<\/p>\n

Au fur et \u00e0 mesure de notre travail sur le march\u00e9, on nous demande souvent quand il est pr\u00e9f\u00e9rable d'appliquer le sch\u00e9ma classique avec un stockage en r\u00e9seau (SAN) et quand \u2013 une solution hyperconvergente ? De nombreuses entreprises \u2013 fabricants de GKS (surtout celles qui n'ont pas de SAN dans leur portefeuille) disent : \u00ab Le SAN est obsol\u00e8te, l'hyperconvergence est la seule voie ! \u00bb. C'est une d\u00e9claration audacieuse, mais elle ne refl\u00e8te pas enti\u00e8rement la r\u00e9alit\u00e9. <\/p>\n

<\/p>\n

\u00c0 vrai dire, le march\u00e9 du SAN se tourne effectivement vers les solutions hyperconvergentes et similaires, mais il y a toujours un \u00ab mais \u00bb.<\/p>\n

<\/p>\n

Tout d'abord, les centres de donn\u00e9es et les infrastructures informatiques construits selon le sch\u00e9ma classique avec un SAN ne peuvent pas simplement \u00eatre reconvertis, donc la modernisation et l'extension de ces infrastructures \u2014 c'est un h\u00e9ritage qui va durer encore 5 \u00e0 7 ans.<\/p>\n

<\/p>\n

Deuxi\u00e8mement, les infrastructures qui sont actuellement construites en masse (en Russie, par exemple) sont r\u00e9alis\u00e9es selon le sch\u00e9ma classique en utilisant un SAN, non pas parce que les gens ne connaissent pas l'hyperconvergence, mais parce que le march\u00e9 de l'hyperconvergence est nouveau, les solutions et normes ne sont pas encore \u00e9tablies, les informaticiens ne sont pas encore form\u00e9s, l'exp\u00e9rience est limit\u00e9e, et il faut construire des centres de donn\u00e9es ici et maintenant. Cette tendance va encore durer de 3 \u00e0 5 ans (et puis un autre h\u00e9ritage, voir le point 1).<\/p>\n

<\/p>\n

Troisi\u00e8mement, une limitation purement technique concernant des d\u00e9lais suppl\u00e9mentaires de 2 millisecondes pour l'\u00e9criture (sans tenir compte du cache local, bien s\u00fbr), qui sont le prix \u00e0 payer pour un stockage distribu\u00e9. <\/p>\n

<\/p>\n

Et n'oublions pas l'utilisation de grands serveurs physiques, qui appr\u00e9cient l'\u00e9volutivit\u00e9 verticale des syst\u00e8mes de stockage.<\/p>\n

<\/p>\n

Il existe de nombreuses t\u00e2ches n\u00e9cessaires et populaires o\u00f9 le SAN fonctionne mieux que l'hyperconvergence. Certes, les fabricants qui n'ont pas de SAN dans leur portefeuille ne seront pas d'accord avec nous, mais nous sommes pr\u00eats \u00e0 d\u00e9battre de mani\u00e8re argument\u00e9e. Bien entendu, en tant que d\u00e9veloppeurs des deux produits, nous r\u00e9aliserons dans une de nos futures publications une comparaison entre le SAN et l'hyperconvergence, o\u00f9 nous d\u00e9montrerons clairement dans quelles conditions chacun est le meilleur.<\/p>\n

<\/p>\n

Et o\u00f9 les solutions hyperconvergentes fonctionneront-elles mieux que le SAN ?<\/h3>\n

<\/p>\n

Sur la base des th\u00e8ses ci-dessus, on peut tirer trois conclusions \u00e9videntes : <\/p>\n

<\/p>\n

    \n
  1. L\u00e0 o\u00f9 les 2 millisecondes suppl\u00e9mentaires de latence \u00e0 l'\u00e9criture, qui se manifestent de mani\u00e8re uniforme dans n'importe quel environnement de production (ici, nous ne parlons pas de tests synth\u00e9tiques, car dans les tests synth\u00e9tiques, on peut montrer des nanosecondes), ne sont pas critiques, l'hyperconvergence conviendra.<\/li>\n
  2. L\u00e0 o\u00f9 la charge des grands serveurs physiques peut \u00eatre transform\u00e9e en de nombreuses petites machines virtuelles et r\u00e9partie sur des n\u0153uds, l'hyper-convergence s'y int\u00e9grera \u00e9galement tr\u00e8s bien.<\/li>\n
  3. L\u00e0 o\u00f9 l'\u00e9volutivit\u00e9 horizontale est plus prioritaire que l'\u00e9volutivit\u00e9 verticale, l'hyper-convergence s'y int\u00e9grera \u00e9galement parfaitement.<\/li>\n<\/ol>\n

    <\/p>\n

    Quelles sont ces solutions ?<\/h3>\n

    <\/p>\n

      \n
    1. Tous les services d'infrastructure standard (service d'annuaire, courrier, GED, serveurs de fichiers, syst\u00e8mes ERP et BI petits ou moyens, etc.). Nous les appelons \u00ab calculs g\u00e9n\u00e9raux \u00bb. <\/li>\n
    2. L'infrastructure des fournisseurs de cloud, o\u00f9 il est n\u00e9cessaire de s'\u00e9tendre horizontalement rapidement et de mani\u00e8re standardis\u00e9e et de \u00ab d\u00e9couper \u00bb facilement un grand nombre de machines virtuelles pour les clients.<\/li>\n
    3. Infrastructure des bureaux virtuels<\/a> (VDI), o\u00f9 de nombreuses petites machines virtuelles d'utilisateurs sont lanc\u00e9es et \u00e9voluent tranquillement \u00e0 l'int\u00e9rieur d'un cluster homog\u00e8ne.<\/li>\n
    4. Les r\u00e9seaux d'agences, o\u00f9 chaque agence doit obtenir une infrastructure standard, tol\u00e9rante aux pannes, mais en m\u00eame temps peu co\u00fbteuse, compos\u00e9e de 15 \u00e0 20 machines virtuelles.<\/li>\n
    5. Tous les calculs distribu\u00e9s (services big data, par exemple). L\u00e0 o\u00f9 la charge va \u00ab lat\u00e9ralement \u00bb, plut\u00f4t qu'\u00ab en profondeur \u00bb. <\/li>\n
    6. Environnements de test, o\u00f9 de l\u00e9gers retards suppl\u00e9mentaires sont acceptables, mais il y a des restrictions budg\u00e9taires car il s'agit de tests.<\/li>\n<\/ol>\n

      <\/p>\n

      Pour le moment, c'est pr\u00e9cis\u00e9ment pour ces t\u00e2ches que nous avons cr\u00e9\u00e9 AERODISK vAIR et c'est sur cela que nous nous concentrons (avec succ\u00e8s jusqu'\u00e0 pr\u00e9sent). Cela pourrait bient\u00f4t changer, car le monde ne reste pas immobile.<\/p>\n

      <\/p>\n

      Alors\u2026<\/h3>\n

      <\/p>\n

      Ceci conclut la premi\u00e8re partie d'un grand cycle d'articles, dans le prochain article nous parlerons de l'architecture de la solution et des composants utilis\u00e9s.<\/p>\n

      <\/p>\n

      Nous serons ravis de recevoir vos questions, suggestions et d\u00e9bats constructifs.<\/p>\n

      Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28919,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Solution hyper-convergente AERODISK vAIR. Bas\u00e9 sur le syst\u00e8me de fichiers ARDFS | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0413\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 AERODISK vAIR. \u041e\u0441\u043d\u043e\u0432\u0430 \u2014 \u0444\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 ARDFS | ProHoster","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:24:25+00:00","article:modified_time":"2019-10-31T19:24:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38542","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 13:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:07:40","updated":"2026-02-09 13:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/38542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}