alex_aldo - Fotolia
Les roadmaps de Red Hat Ceph et Gluster se concentrent sur l’hyperconvergence et les conteneurs
Les feuilles de route de Red Hat Ceph et Gluster storage reflètent l'accent croissant mis par l'éditeur sur les infrastructures hyperconvergés, les conteneurs et le Big Data, ainsi que sur l'amélioration des performances de ses solutions.
Les feuilles de route de Ceph et Gluster, les deux technologies à la base de l’offre de stockage de Red Hat illustrent l’accent croissant mis sur l’hyperconvergence, les conteneurs et le Big Data par l’éditeur.
Les « roadmaps » de Red Hat n’ont rien de vraiment secret, car elles suivent les travaux réalisés dans les communautés open source Ceph et Gluster. Mais Red Hat a le contrôle sur l’intégration des nouvelles fonctionnalités open source dans le code de ses produits commercialement supportés. Et le fournisseur ajoute souvent des améliorations et des paquets additionnels, ainsi que des guides de performance et de calibrage, à ses outils.
Par exemple, Red Hat a récemment lancé Red Hat Hyperconverged Infrastructure. Ce produit d’infrastructure hyperconvergée, combinant Red Hat Gluster Storage et Red Hat Virtualization, cible les sites distants et les succursales (ROBO).
La feuille de route à long terme dévoilée par le chef de produit de Gluster chez Red Hat indique que l’éditeur n’entend pas en rester là. Il prévoit prochainement de supporter des configurations plus petites (à partir de un nœud), ainsi que des configurations plus massives (plus de neuf nœuds). Le minimum actuel est un cluster à trois nœuds et le maximum supporté dans Red Hat HCI est de neuf serveurs physiques.
« Nous cherchons à répondre aux besoins des clients qui doivent aller plus de neuf nœuds », a déclaré Sayan Saha, directeur produits pour l’activité de stockage de Red Hat. « Et nous avons aussi constaté que dans les environnements ROBO, beaucoup de gens veulent débuter par un nœud. Ils comprennent qu’ils n’obtiendront pas la redondance, mais ils veulent commencer à un parce que c’est tout l’espace dont ils disposent ».
Les utilisateurs de Red Hat Hyperconverged Infrastructure doivent pour l’instant installer la solution sur leur propre matériel. Mais Saha a expliqué que Red Hat espère trouver un partenaire d’appliance validé pour fournir des appliances intégrées au début de 2018.
Changement majeur de Back-End en vue pour Ceph
Red Hat continue à recommander Ceph pour des configurations à grande échelle nécessitant un accès en mode bloc et du stockage objet, mais il préconise Gluster pour des cas plus modestes d’utilisation hyperconvergée et pour des déploiements NAS en mode scale-out.
Un changement majeur pour la prochaine mouture de Red Hat Ceph est l’intégration d’un nouveau back-end de stockage objet. Baptisé BlueStore, il est conçu pour surmonter les limitations du système de fichiers XFS sur lequel Ceph s’appuie actuellement pour écrire des données sur le disque.
La communauté Open Source de Ceph a déjà adopté BlueStore, mais Red Hat ne l’intégrera en version supportée que dans Ceph Storage 3.0, qui est attendu en principe avant la fin 2017, selon Neil Levine, directeur produits chez Red Hat. La date de disponibilité générale de BlueStore n’est toutefois pas encore finalisée.
« BlueStore est l’un des plus grands changements apporté à l’architecture de Ceph au cours des dernières années », a déclaré Levine. « BlueStore permet d’écrire nativement sur les périphériques de stockage bloc. Le bénéfice évident est que vous supprimez une abstraction majeure, de sorte que vous obtenez un énorme gain de performance ».
Levine explique que l’élimination de la couche XFS augmenterait les performances sans devoir changer de matériel. Il indique que BlueStore devrait aussi permettre aux clients de combiner des supports de stockage de natures différentes. « Ils pourront choisir des disques SSD pour les métadonnées et des disques durs plus lents pour les données en mode blocs.
Levine considère que la technologie BlueStore est “un composant très très critique de la pile, car c’est celui qui écrit réellement les données”.
Levine explique que le déploiement de BlueStore ne nécessitera pas une mise à jour majeure de l’infrastructure pour les utilisateurs actuels de Red Hat Ceph. Toutefois, les clients devront réinitialiser individuellement les disques en les reformatant, une tâche qui pourrait nécessiter beaucoup de temps pour les clusters avec plus de 1000 disques. La roadmap de Red Hat prévoit cependant un outil conçu pour guider les utilisateurs sur la meilleure approche à adopter pour la mise à jour de grands clusters, selon Levine.
“BlueStore promet beaucoup en termes de performance, mais il est aussi très complexe et difficile à livrer. C’est pourquoi nous prenons notre temps pour le faire”, a déclaré Levine.
Le support de CephFS et iSCSI attendu dans Ceph 3.0
Les fonctionnalités supplémentaires hautement demandées pour Red Hat Ceph 3.0 incluent la disponibilité générale du système de fichiers CephFS et le support d’iSCSI pour le stockage en mode blocs. Levine a déclaré que l’implémentation iSCSI est suffisamment mûre pour supporter des applications de stockage secondaire sur Ceph. Les principaux cas d’utilisation de CephFS devraient concerner les déploiements de clouds OpenStack, selon Levine.
Le Ceph RADOS Block Device (RBD) est le back-end principal utilisé en parallèle de l’API Cinder d’OpenStack. Levine indique que la version 11 de Red Hat OpenStack Platform (OSP) supportera les déploiements hyperconvergents, en colocalisant les fonctions de compute et de stockage Ceph sur les mêmes nœuds. Elle supportera aussi la réplication Cinder avec Ceph RBD.
Levine a déclaré que la version 12 d’OSP, qui est pour l’instant prévue pour la fin 2017 supporterait le service de partage de fichiers OpenStack Manila avec CephFS, le déploiement de Ceph en conteneurs, ainsi que les volumes RBD chiffrés.
La version actuelle de Red Hat Ceph, la 2.3, lancée en juin 2017, a déjà ajouté une interface NFS légère pour permettre aux utilisateurs d’accéder aux données de stockage objet via NFS. Elle a aussi apporté le support des déploiements conteneurisés de Ceph, un meilleur support de l’API Simple Storage Service (S3) d’Amazon AWS et le support du système de fichier client S3A d’Hadoop. L’intégration du système de fichiers Apache Hadoop S3A permet à Hadoop de lire et écrire des donnés sur un service de stockage objet compatible S3 (donc sur Ceph).
Levine estime que le Big Data est une opportunité de croissance intéressante pour les systèmes de stockage objet. Il a indiqué que Red Hat mettrait à disposition des guides de performance et de calibrage pour permettre aux clients d’optimiser Ceph pour une utilisation avec de grands jeux de données.
Le support de Ceph dans un format conteneurisé est un prélude à l’utilisation de Kubernetes pour gérer le système de stockage, un point sur lequel Red Hat devrait travailler l’année prochaine, selon Levine. Il a déclaré : “le support des conteneurs est une fondation importante pour nombre de changements que nous pouvons faire plus tard.”
Les fonctionnalités à venir pour Red Hat Gluster
Red Hat travaille aussi à faire de Gluster la plate-forme de stockage persistante par défaut pour Red Hat OpenShift. “Ceph continuera probablement d’être un pair d’OpenShift, même s’il ne fonctionnera pas dans OpenShift. Openshift vise les développeurs d’applications alors que Ceph se concentre sur l’infrastructure”, a déclaré Levine. “Gluster est bien mieux adapté à la cible d’OpenShift. Ils ne veulent pas vraiment s’inquiéter de tous les détails de stockage. Ils n’essaient pas de faire un environnement de stockage de 10 Po massivement évolutif et de l’optimiser. Ils ont juste besoin de services de stockage pour une application ».
Red Hat Gluster Storage (RHGS) peut être exécuté à l’intérieur d’OpenShift dans des conteneurs ou à l’extérieur d’OpenShift, dans un cluster dédié accessible via le réseau. Il peut aussi tourner dans des machines virtuelles, en frontal de baies NAS ou SAN, ou être déployé sur les infrastructures d’Amazon Web Services, Microsoft Azure ou Google Cloud.
Les nouvelles fonctionnalités ciblées par conteneur dans RHGS cette année incluent le support iSCSI, celui de l’API S3 pour l’accès aux données stockées dans un volume Gluster, et le multiplexage de briques — une brique est un répertoire gluster — pour réduire la consommation de CPU, de mémoire et de ports et augmenter le nombre de volumes par grappe.
Parmi les autres fonctionnalités attendues, figurent la géoréplication active-active et GFProxy deux fonctions issues de travaux réalisés par Facebook, un des utilisateurs majeurs de Gluster.
La géoréplication active-active, également connue sous le nom de réplication multimaître, permet à un seul volume Gluster de couvrir plusieurs sites. Les lectures sont locales et les écritures sont propagées entre les sites distants. Les mises à jour d’un volume Gluster peuvent se produire à partir de plusieurs emplacements géographiques. La géoréplication active-active est prévue dans RHGS 3.4 à la fin de cette année ou au début de l’année 2018.
Le GFProxy développé par Facebook est conçu pour répondre au problème de désactivation des clients qui se produit avec des mises à niveau presque simultanées de serveurs et de clients Gluster. Saha explique que Facebook a remplacé la logique côté client par un proxy léger et a déplacé cette logique sur le serveur pour lisser le processus de mise à jour, de sorte que les clients changent moins fréquemment. GF Proxy est attendu l’année prochaine avec RHGS 4.0.
Une autre caractéristique clé de RHGS 4.0 devrait être une couche d’administration remaniée, appelée GlusterD 2.0, pour étendre le nombre de nœuds par cluster et mieux gérer l’état des nœuds du cluster.
Saha a enfin expliqué que RHGS 3.4 apportera la possibilité pour Gluster de sauvegarder des données dans des services objet compatibles S3. Cette fonctionnalité est attendue en toute fin 2017 ou au début 2018.
Adapté d'un article en anglais de SearchStorage.com par la rédaction du MagIT
