Red Hat dévoile sa feuille de route pour le stockage

C’est promis, Ceph aura bientôt des fonctions de haut niveau qui le feront sortir de son giron technophile et OCS, sa déclinaison pour Kubernetes, cessera de cumuler les retards.

On en sait désormais un peu plus sur les intentions de Red Hat concernant ses technologies de stockage, à savoir le SDS Ceph, qui sert à bâtir de grands clusters NAS/objet, et OpenShift Container Storage (OCS), sa déclinaison plus particulière pour accompagner les clusters applicatifs Kubernetes.

Ceph aura bientôt les fonctions de haut niveau qui lui manquent pour enfin sortir de son giron technophile : de la déduplication, qui réduit le nombre de disques, et de la réplication en miroir, qui répond aux besoins de reprise d’activité après sinistre. Red Hat vient par ailleurs de dévoiler un tableau de bord amélioré, qui facilite le déploiement, l’utilisation et l’automatisation de son SDS.

« Red Hat a vocation à s’adresser aux entreprises qui développent leurs applications en interne. Il était temps qu’ils résolvent un curieux paradoxe : ces entreprises-là n’ont ni le temps ni les ressources à consacrer à l’administration d’un système de stockage aussi technico-technique que Ceph », commente Scott Sinclair, analyste chez Enterprise Strategy Group, qui se félicite des nouvelles orientations que prend Red Hat concernant ses solutions de stockage.

Concernant les performances, la communauté Open source en charge de Ceph s’est lancée dans un projet ambitieux, baptisé « Crimson ». Il consiste à prendre en charge des technologies de mémoire persistante comme les barrettes et SSD 3D XPoint, alias Optane chez Intel, ou encore les nouveaux SSD NVMe de type ZNS (Zoned NameSpaces), dans lesquels des secteurs sont dédiés à des applications.

Sage Weil, l’architecte de Red Hat en charge de Ceph, espère avoir un prototype fonctionnel pour Pacific, la version Open source de Ceph qui doit être publiée en 2021. Red Hat devrait inclure une préversion de Crimson dans la déclinaison commerciale qui sortira simultanément, Ceph Storage 6.0.

OCS ne retardera plus le déploiement d’OpenShift Container Platform

Parallèlement au développement de Ceph, Red Hat entend synchroniser le développement d’OpenShift Container Storage avec celui de sa distribution Kubernetes OpenShift Container Platform (OCP). Il s’agit surtout de rattraper un certain retard : OCS 4.2 est sorti en janvier alors qu’il était prévu pour la fin de l’été 2019 et OCS 4.3, initialement prévu pour décembre dernier, n’a été publié qu’à la mi-avril. Pire, plusieurs de ses fonctions-clés ne sont finalement disponibles qu’en préversion. Il faudra attendre la version 4.4, initialement programmée pour ce mois de mai, pour avoir des logiciels prêts pour la mise en production.

Le problème est que les versions d’OCS vont de pair avec les mêmes numéros de version d’OCP et que les retards du premier freinent l’adoption du second.

Sudhir Prasad, en charge chez Red Hat des produits d’administration pour le stockage, estimait il y a un an qu’OCS permettait à un peu plus de 400 clients de gérer des clusters de stockage qui grimpaient parfois jusqu’à 300 To de capacité. Cette année, Red Hat indique une hausse des ventes de cette manière : OpenShift Container Platform compterait plus de 1 300 clients et environ 40 à 50 % d’entre eux utiliseraient OCS. Mais c’est un succès en demi-teinte : selon Sudhir Prasad, dans la plupart des cas les entreprises utiliseraient les anciennes versions 3.11 d’OCS et OCP. Très peu de clients auraient consenti à migrer vers la génération 4.x.

Les retards d’OCS n’ont pas beaucoup surpris les observateurs dans le contexte de la révision majeure du produit qu’incarne la génération 4.x. Celle-ci concrétise l’abandon du système de fichiers historique, Gluster, pour passer à Ceph. De plus, Ceph est censé ici offrir bien plus que ses protocoles de stockage en mode blocs, fichiers et objets. Il doit aussi apporter les outils nécessaires pour rendre le stockage objet S3 plus évolutif, avec la prise en charge des grandes bases de données dans le contexte des nouvelles applications d’analytique et de Machine Learning.

Outre l’adoption de Ceph, Red Hat remplace aussi dans cette nouvelle génération l’installeur Ansible et la console d’administration Heketi Gluster par l’outil plus global Rook, plus simple à utiliser pour provisionner du stockage. OCS 4.x apporte également la passerelle NooBaa que Red Hat a acquise en 2018 pour muscler le fonctionnement en multicloud.

Le support du couple OCP/OCS en génération 3.x devait initialement prendre fin en juin 2020. Red Hat a abandonné cette idée : finalement, le support d’OCP/OCS 3.11.x sera prolongé jusqu’en juin 2021, officiellement pour alléger la charge de migrer alors que les entreprises subissent encore la pandémie de Covid-19. Il y aura même pour OCS 3.11 un support dit « de maintenance » qui durera jusqu’en juin 2022. Et encore un support optionnel jusqu’en juin 2024.

Lors de son récent Summit 2020, Red Hat a mis en avant l’outil gratuit Cluster Application Migration qui vise à faciliter la migration d’OCP/OCS 3.x vers OCP/OCS 4.x pour les applications et les données. Selon Patric Uebele, responsable produit OCS, cet outil explore de manière autonome les clusters OpenShift et permet de migrer en une seule fois des clusters entiers, voire juste certaines namespaces pour les entreprises qui souhaitent adopter une approche plus granulaire.

Un SDS plus versatile

Dès la version 4.4, Red Hat ajoutera dans les clusters OCS la prise en charge du stockage des serveurs applicatifs, que les disques soient installés à l’intérieur des serveurs ou dans des tiroirs qui leur sont directement rattachés (DAS). Selon Sudhir Prasad, les entreprises auraient été nombreuses à demander cette option « bare-metal », qui permettrait de prendre en compte les applications accédant de manière intensive à leurs données – des applications pour lesquelles on déploie des disques au plus proche des serveurs.

OCS fonctionne pour l’heure uniquement en mode « convergé », c’est-à-dire avec des nœuds de stockage installés dans le même cluster – le même sous-réseau – que les serveurs applicatifs. À terme, Red Hat devrait aussi prendre en charge un mode « indépendant » qui doit permettre aux clusters OpenShift d’utiliser un pool de stockage externe, via un nouveau pilote CSI pour Kubernetes. Cette fonction devrait arriver sur OCS 4.5, a priori en juillet. Elle était initialement prévue pour la version 4.3.

D’autres fonctionnalités sont prévues dans OCS 4.5, notamment le chiffrement FIPS 140-2, l’extension dynamique des volumes et la prise en charge des environnements déconnectés. Red Hat espère aussi étendre le nombre de volumes persistants possibles dans un seul cluster à 10 000, contre 5 000 dans OCS 4.4.

La feuille de route vers OCS 4.6, lequel est prévu d’ici à octobre, comprend des capacités de protection à l’aide de snapshots et de clones, une API de sauvegarde utilisable par des éditeurs tiers, ou encore des options de PRA entre plusieurs clusters.

« Les solutions de stockage de Red Hat sont souvent évaluées par des services qui n’achètent pas du stockage traditionnel. »
Julia PalmerAnalyste, Gartner

« Les solutions de stockage de Red Hat sont souvent évaluées par des services qui n’achètent pas du stockage traditionnel. Ce sont des DevOps ou des architectes cloud qui apprécient les plateformes Software-Defined et Open source. Ils considèrent ces technologies comme un différentiateur essentiel pour passer d’une infrastructure qui dure, à une infrastructure capable de supporter la transformation des activités », commente Julia Palmer, analyste chez Gartner.

Selon elle, OCS est évalué par les DevOps face aux solutions de Portworx, Robin.io, StorageOS, MayaData, Diamanti, ou encore de nouveaux venus comme Arrikto. Quant aux DSI, elles auraient plutôt tendance à comparer OCS avec des solutions de stockage primaire qui offrent un pilote Kubernetes, notamment chez Pure Storage, Dell EMC, Hitachi Vantara, IBM et NetApp.

 

Pour approfondir sur Software Defined Storage

Close