Cet article a été rédigé pour vous aider à choisir la solution qui vous convient et à comprendre les différences entre les SDS tels que Gluster, Ceph et Vstorage (Virtuozzo).
Le texte utilise des liens vers des articles contenant une divulgation plus détaillée de certains problèmes, de sorte que les descriptions seront aussi brèves que possible, en utilisant des points clés sans fioritures inutiles et des informations d'introduction que vous pouvez, si vous le souhaitez, obtenir indépendamment sur Internet.
En fait, bien sûr, les sujets abordés nécessitent le ton du texte, mais dans le monde moderne, de plus en plus de gens n'aiment pas beaucoup lire))), vous pouvez donc lire rapidement et faire un choix, et si quelque chose ne va pas pas clair, suivez les liens ou les mots peu clairs sur Google))), et cet article est comme un emballage transparent pour ces sujets profonds, montrant le remplissage - les principaux points clés de chaque décision.
Gloussement
Commençons par Gluster, qui est activement utilisé par les fabricants de plates-formes hyperconvergées avec SDS basées sur l'open source pour les environnements virtuels et peut être trouvé sur le site Web de RedHat dans la section stockage, où vous pouvez choisir parmi deux options SDS : Gluster ou Ceph.
Gluster se compose d'une pile de traducteurs - des services qui effectuent tout le travail de distribution de fichiers, etc. Brick est un service qui dessert un disque, Volume est un volume (pool) qui unit ces briques. Vient ensuite le service de distribution de fichiers en groupes à l'aide de la fonction DHT (table de hachage distribuée). Nous n'inclurons pas le service Sharding dans la description puisque les liens ci-dessous décriront les problèmes qui y sont associés.
Lors de l'écriture, l'intégralité du fichier est stockée dans brick et sa copie est simultanément écrite dans brick sur le deuxième serveur. Ensuite, le deuxième fichier sera écrit dans le deuxième groupe de deux briques (ou plus) sur des serveurs différents.
Si les fichiers ont à peu près la même taille et que le volume n'est constitué que d'un seul groupe, alors tout va bien, mais dans d'autres conditions, les problèmes suivants découleront des descriptions :
- l'espace dans les groupes est utilisé de manière inégale, cela dépend de la taille des fichiers et s'il n'y a pas assez d'espace dans le groupe pour écrire un fichier, vous recevrez une erreur, le fichier ne sera pas écrit et ne sera pas redistribué à un autre groupe ;
- lors de l'écriture d'un fichier, les IO ne vont qu'à un seul groupe, les autres sont inactifs ;
- vous ne pouvez pas obtenir les E/S de l'intégralité du volume lors de l'écriture d'un fichier ;
- et le concept général semble moins productif en raison du manque de distribution des données en blocs, où il est plus facile d'équilibrer et de résoudre le problème de la distribution uniforme, et non comme maintenant le fichier entier est placé dans un bloc.
D'après la description officielle nous arrivons également involontairement à comprendre que gluster fonctionne comme un stockage de fichiers en plus du RAID matériel classique. Il y a eu des tentatives de développement pour couper (Sharding) les fichiers en blocs, mais tout cela est un ajout qui impose des pertes de performances sur l'approche architecturale déjà existante, ainsi que l'utilisation de composants librement distribués avec des limitations de performances comme Fuse. Il n'existe aucun service de métadonnées, ce qui limite les performances et les capacités de tolérance aux pannes du stockage lors de la distribution de fichiers en blocs. De meilleurs indicateurs de performance peuvent être observés avec la configuration « Distributed Replicated » et le nombre de nœuds doit être d'au moins 6 pour organiser une réplique 3 fiable avec une répartition de charge optimale.
Ces résultats sont également liés à la description de l’expérience utilisateur et par rapport à , ainsi qu'une description de l'expérience permettant de comprendre cette configuration plus productive et plus fiable.
L'image montre la répartition de la charge lors de l'écriture de deux fichiers, où les copies du premier fichier sont réparties sur les trois premiers serveurs, qui sont combinés dans le groupe de volume 0, et trois copies du deuxième fichier sont placées sur le deuxième groupe de volume 1 sur trois. les serveurs. Chaque serveur possède un disque.
La conclusion générale est que vous pouvez utiliser Gluster, mais en sachant qu'il y aura des limitations en termes de performances et de tolérance aux pannes qui créeront des difficultés dans certaines conditions d'une solution hyperconvergée, où des ressources sont également nécessaires pour les charges informatiques des environnements virtuels.
Il existe également certains indicateurs de performance Gluster qui peuvent être atteints sous certaines conditions, limitées à
Céph
Examinons maintenant Ceph à partir des descriptions d'architecture que j'ai pu Il y a aussi une comparaison entre , où l'on comprend immédiatement qu'il est conseillé de déployer Ceph sur des serveurs séparés, puisque ses services nécessitent toutes les ressources matérielles sous charge.
Architecture plus complexe que Gluster et il existe des services tels que des services de métadonnées, mais l'ensemble de la pile de composants est assez complexe et peu flexible pour l'utiliser dans une solution de virtualisation. Les données sont stockées en blocs, ce qui semble plus productif, mais dans la hiérarchie de tous les services (composants), il y a des pertes et des latences sous certaines charges et conditions d'urgence, par exemple les suivantes
De la description de l'architecture, le cœur est CRUSH, grâce auquel l'emplacement de stockage des données est sélectionné. Vient ensuite PG – c’est l’abstraction (groupe logique) la plus difficile à comprendre. Des PG sont nécessaires pour rendre CRUSH plus efficace. L'objectif principal de PG est de regrouper des objets pour réduire la consommation de ressources, augmenter les performances et l'évolutivité. Adresser des objets directement, individuellement, sans les combiner dans un PG coûterait très cher. OSD est un service pour chaque disque individuel.
Un cluster peut avoir un ou plusieurs pools de données à des fins différentes et avec des paramètres différents. Les pools sont divisés en groupes de placement. Les groupes de placement stockent les objets auxquels les clients accèdent. C'est là que se termine le niveau logique et que commence le niveau physique, car chaque groupe de placement se voit attribuer un disque principal et plusieurs disques de réplique (dont le nombre dépend exactement du facteur de réplication du pool). En d'autres termes, au niveau logique, l'objet est stocké dans un groupe de placement spécifique et au niveau physique, sur les disques qui lui sont attribués. Dans ce cas, les disques peuvent être physiquement situés sur différents nœuds ou même dans différents centres de données.
Dans ce schéma, les groupes de placement apparaissent comme un niveau nécessaire à la flexibilité de l'ensemble de la solution, mais en même temps, comme un maillon supplémentaire dans cette chaîne, ce qui suggère involontairement une perte de productivité. Par exemple, lors de l'écriture de données, le système doit les diviser en ces groupes, puis au niveau physique en disque principal et disques pour les répliques. Autrement dit, la fonction de hachage fonctionne lors de la recherche et de l'insertion d'un objet, mais il existe un effet secondaire : des coûts et des restrictions très élevés pour la reconstruction du hachage (lors de l'ajout ou de la suppression d'un disque). Un autre problème de hachage est l’emplacement clairement défini des données qui ne peuvent pas être modifiées. Autrement dit, si le disque est soumis à une charge accrue, le système n'a pas la possibilité de ne pas y écrire (en sélectionnant un autre disque), la fonction de hachage oblige les données à être localisées conformément à la règle, quelle que soit leur gravité. le disque l'est, donc Ceph consomme beaucoup de mémoire lors de la reconstruction du PG en cas d'auto-réparation ou d'augmentation du stockage. La conclusion est que Ceph fonctionne bien (bien que lentement), mais uniquement en l'absence de mise à l'échelle, de situations d'urgence ou de mises à jour.
Il existe bien sûr des options pour augmenter les performances grâce à la mise en cache et au partage de cache, mais cela nécessite un bon matériel et il y aura toujours des pertes. Mais dans l’ensemble, Ceph semble plus tentant que Gluster en termes de productivité. De plus, lors de l'utilisation de ces produits, il est nécessaire de prendre en compte un facteur important : il s'agit d'un haut niveau de compétence, d'expérience et de professionnalisme avec un grand accent sur Linux, car il est très important de tout déployer, configurer et maintenir correctement, ce qui impose encore plus de responsabilités et de charges à l'administrateur.
Stockage
L'architecture semble encore plus intéressante , qui peut être utilisé conjointement avec un hyperviseur sur les mêmes nœuds, sur le même , mais il est très important de tout configurer correctement pour obtenir de bonnes performances. Autrement dit, déployer un tel produit dès le départ sur n'importe quelle configuration sans prendre en compte les recommandations conformément à l'architecture sera très simple, mais pas productif.
Ce qui peut coexister pour le stockage à côté des services de l'hyperviseur kvm-qemu, et ce ne sont là que quelques services où une hiérarchie compacte et optimale de composants a été trouvée : service client monté via FUSE (modifié, non open source), service de métadonnées MDS (Service de métadonnées), service Blocs de données du service Chunk, qui au niveau physique équivaut à un disque et c'est tout. En termes de vitesse, bien sûr, il est optimal d'utiliser un schéma tolérant aux pannes avec deux répliques, mais si vous utilisez la mise en cache et les journaux sur des disques SSD, alors le codage tolérant aux erreurs (effacer le codage ou raid6) peut être décemment overclocké sur un schéma hybride ou encore mieux sur all flash. L'EC (effacement du codage) présente certains inconvénients : lors de la modification d'un bloc de données, il est nécessaire de recalculer les montants de parité. Pour contourner les pertes associées à cette opération, Ceph écrit sur EC de manière différée et des problèmes de performances peuvent survenir lors d'une certaine requête, lorsque, par exemple, tous les blocs doivent être lus, et dans le cas de Virtuozzo Storage, l'écriture des blocs modifiés. est réalisé selon l'approche « log-structured file system » qui minimise les coûts de calcul de parité. Pour estimer approximativement les options avec accélération du travail avec et sans EC, il existe – les chiffres peuvent être approximatifs en fonction du coefficient de précision du fabricant de l'équipement, mais le résultat des calculs est une bonne aide pour planifier la configuration.
Un simple schéma des composants de stockage ne signifie pas que ces composants n'absorbent pas mais si vous calculez tous les coûts à l'avance, vous pouvez compter sur une collaboration aux côtés de l'hyperviseur.
Il existe un système permettant de comparer la consommation de ressources matérielles par les services de stockage Ceph et Virtuozzo.
Si auparavant il était possible de comparer Gluster et Ceph à l'aide d'anciens articles, en utilisant les lignes les plus importantes d'entre eux, alors avec Virtuozzo, c'est plus difficile. Il n'y a pas beaucoup d'articles sur ce produit et les informations ne peuvent être tirées que de la documentation sur ou en russe si l'on considère le Vstorage comme le stockage utilisé dans certaines solutions hyperconvergées dans des entreprises comme et Acronis.
Je vais essayer d'aider avec une description de cette architecture, donc il y aura un peu plus de texte, mais cela prend beaucoup de temps pour comprendre la documentation vous-même, et la documentation existante ne peut être utilisée comme référence qu'en révisant le tableau de contenus ou une recherche par mot-clé.
Considérons le processus d'enregistrement dans une configuration matérielle hybride avec les composants décrits ci-dessus : l'enregistrement commence à aller vers le nœud à partir duquel le client l'a initié (le service de point de montage FUSE), mais le composant maître du service de métadonnées (MDS) le fera bien sûr. diriger le client directement vers le service de bloc souhaité (blocs CS du service de stockage), c'est-à-dire que MDS ne participe pas au processus d'enregistrement, mais dirige simplement le service vers le bloc requis. En général, nous pouvons donner une analogie à l’enregistrement en versant de l’eau dans des barils. Chaque baril est un bloc de données de 256 Mo.
Autrement dit, un disque correspond à un certain nombre de ces barils, c'est-à-dire le volume du disque divisé par 256 Mo. Chaque copie est distribuée sur un nœud, la seconde presque en parallèle sur un autre nœud, etc... Si nous avons trois répliques et qu'il y a des disques SSD pour le cache (pour lire et écrire des journaux), alors la confirmation de l'écriture aura lieu après l'écriture. le journal sur le SSD et la réinitialisation parallèle à partir du SSD se poursuivront sur le disque dur, comme en arrière-plan. Dans le cas de trois réplicas, l'enregistrement sera validé après confirmation du SSD du troisième nœud. Il peut sembler que la somme de la vitesse d'écriture de trois SSD puisse être divisée par trois et nous obtiendrons la vitesse d'écriture d'une réplique, mais les copies sont écrites en parallèle et la vitesse de latence du réseau est généralement supérieure à celle du SSD, et en fait les performances d'écriture dépendront du réseau. À cet égard, afin de voir les IOPS réelles, vous devez charger correctement l'intégralité du Vstorage en , c'est-à-dire tester la charge réelle, et non la mémoire et le cache, où il est nécessaire de prendre en compte la taille correcte du bloc de données, le nombre de threads, etc.
Le journal d'enregistrement mentionné ci-dessus sur le SSD fonctionne de telle manière que dès que des données y pénètrent, elles sont immédiatement lues par le service et écrites sur le disque dur. Il existe plusieurs services de métadonnées (MDS) par cluster et leur nombre est déterminé par un quorum, qui fonctionne selon l'algorithme Paxos. Du point de vue du client, le point de montage FUSE est un dossier de stockage du cluster qui est simultanément visible par tous les nœuds du cluster, chaque nœud a un client monté selon ce principe, ce stockage est donc disponible pour chaque nœud.
Pour la performance de l'une des approches décrites ci-dessus, il est très important, au stade de la planification et du déploiement, de configurer correctement le réseau, où il y aura un équilibrage dû à l'agrégation et à la bande passante du canal réseau correctement sélectionnée. En agrégation, il est important de choisir le bon mode de hachage et les bonnes tailles de trame. Il existe également une très forte différence avec le SDS décrit ci-dessus, celui-ci est fusionné avec la technologie fast path dans Virtuozzo Storage. Ce qui, en plus du fusible modernisé, contrairement à d'autres solutions open source, augmente considérablement les IOPS et permet de ne pas être limité par la mise à l'échelle horizontale ou verticale. En général, par rapport aux architectures décrites ci-dessus, celle-ci semble plus puissante, mais pour un tel plaisir, il faut bien sûr acheter des licences, contrairement à Ceph et Gluster.
Pour résumer, nous pouvons souligner le premier des trois : Virtuozzo Storage occupe la première place en termes de performances et de fiabilité de l'architecture, Ceph occupe la deuxième place et Gluster occupe la troisième place.
Les critères selon lesquels Virtuozzo Storage a été sélectionné : il s'agit d'un ensemble optimal de composants architecturaux, modernisés pour cette approche Fuse avec un chemin rapide, un ensemble flexible de configurations matérielles, une consommation moindre de ressources et la possibilité de partager avec le calcul (informatique/virtualisation), c'est-à-dire qu'il est tout à fait adapté à une solution hyperconvergée dont il fait partie. La deuxième place revient à Ceph car il s'agit d'une architecture plus productive que Gluster, en raison de son fonctionnement en blocs, ainsi que de scénarios plus flexibles et de la capacité de travailler dans des clusters plus grands.
Il est prévu d'écrire une comparaison entre vSAN, Space Direct Storage, Vstorage et Nutanix Storage, de tester Vstorage sur des équipements HPE et Huawei, ainsi que des scénarios d'intégration de Vstorage avec des systèmes de stockage matériels externes, donc si vous avez aimé l'article, ce serait C'est agréable d'avoir des commentaires de votre part, ce qui pourrait augmenter la motivation pour de nouveaux articles, en tenant compte de vos commentaires et souhaits.
Source: habr.com