Red Hat remplace le stockage d’OpenShift par le compliqué Ceph
Avec 6 mois de retard, l’éditeur dote sa distribution Kubernetes d’un système qui lui apporte le mode objet. Des outils sont censés avoir gommé l’aridité de cette technologie, mais la migration restera difficile.
Red Hat lance ces jours-ci une nouvelle version 4.2 de son système de stockage persistant pour container OCS (OpenShift Container Storage) qui n’est plus basée sur le système de fichiers Gluster, mais sur Ceph. Ce choix technologique, qui avait suscité une polémique lors de son annonce, est censé permettre aux containers gérés par OpenShift de mieux adresser les traitements lourds sur les données, comme dans le cas des applications de Machine Learning et d’analytique.
Selon Red Hat, Ceph étant un système de stockage multiprotocole, il est aussi le moyen de fournir aux entreprises une solution plus complète, qui gère tout à la fois les stockages en mode bloc, fichier et objet. Jusque-là, pour l’objet, les utilisateurs d’OCS devaient se rabattre sur une distribution OpenStack additionnelle qui servait à bâtir des appliances S3 sur site. Ceph, en plus d’intégrer le mode objet dans la même licence, sert aussi à supporter plus de volumes : 5 000 dans l’actuelle version 2.3 d’OCS et a priori 10 000 dans la prochaine 4.3.
« OCS 4.2 bénéficie de surcroît de la technologie de Noobaa que nous avons rachetée en 2018 et qui permet de migrer des données d’un stockage objet local à un volume S3 hébergé en cloud public. Cela signifie que les développeurs gagneront à stocker les données de leurs applications en mode objet, de sorte que, via l’utilisation de notre API S3, ces applications puissent fonctionner, quel que soit l’endroit où se trouvent leurs données, c’est-à-dire qu’elles deviendront plus portables », explique Sudhir Prasad, directeur des produits de la division Stockage et Infrastructures Hyperconvergées chez Red Hat.
OCS s’adresse aux utilisateurs d’OCP (OpenShift Container Platform), lequel revient désormais à une distribution Kubernetes depuis son passage en version 4. De fait, toutes les commandes relatives au stockage et fournies par OCS s’utilisent depuis la console d’administration d’OCP. Selon Red Hat, OCP en version Kubernetes serait déjà utilisé par 1 300 entreprises et 40 à 50 % d’entre elles auraient souscrit une licence pour OCS.
Combattre la complexité induite par Ceph
Ceph était déjà une option possible à l’installation des précédentes versions d’OCS 4. La nouveauté de cette 4.2 est qu’elle gomme le principal reproche que les utilisateurs ont formulé : ce système de fichiers – dont le symbole est une pieuvre… – était jusque-là bien trop compliqué à administrer.
« Nos équipes ont planché sur ce problème afin que Ceph soit intégré aux autres outils d’installation, de configuration et d’administration. Nous avons fait en sorte que Ceph devienne aussi simple d’usage qu’un service cloud : on double-clique pour l’utiliser. Néanmoins, cela a pris du temps », indique Sudhir Prasad qui reconnaît que la sortie d’OCS 4.2 était initialement prévue pour l’été de l’année dernière.
Ceph bénéficie en l’occurrence à présent d’un « opérateur Rook » dédié, à savoir un outil qui permet de configurer et de contrôler des volumes de stockage sans connaissance particulière : « les développeurs eux-mêmes peuvent l’utiliser. Ils indiquent la capacité dont ils ont besoin et OCS provisionne pour eux le stockage nécessaire », assure Sudhir Prasad.
Reste un problème : migrer l’existant sur Ceph n’est pas trivial. Certes, Red Hat propose bien un outil CAM (Cluster Application Migration) qui a d’abord été conçu pour migrer OCP 3 à OCP 4 et qui est censé simplifier ici les opérations. Néanmoins, cet outil ne met pas à jour l’existant ; il déplace juste les données d’un ancien cluster vers un nouveau, ce qui suppose que les utilisateurs commencent déjà par acheter du matériel en plus.
« Il faut comprendre que la majorité des utilisateurs qui basculeront sur Ceph sont ceux qui migrent en même temps d’OCP3 à OCP4. C’est une transition importante, à l’occasion de laquelle les entreprises renouvellent aussi leur cluster avec des caractéristiques plus adaptées » élude Sudhir Prasad.
« Il faut surtout prendre plusieurs précautions critiques ».
Henry BaltazarAnalyste, 451 Research
« Il faut surtout prendre plusieurs précautions critiques », rétorque pour sa part l’analyste du bureau 451 Research, Henry Baltazar. « Les utilisateurs qui passent de Gluster à Ceph ont tout intérêt à conserver une copie de leurs données, à restaurer en cas de problème probable. Et s’ils basculent dans l’espoir de profiter de la migration de données en cloud public, je leur recommande aussi de muscler fortement leur réseau pour supporter les volumes qu’il faudra exporter, voire rapatrier », dit-il.
Un calendrier qui se délaie…
La prochaine version 4.3 d’OCS devait, dans le calendrier original, sortir ces jours-ci. Du fait du retard pris par OCS 4.2, il faudra plutôt encore attendre plusieurs semaines. En attendant, une beta est disponible. Ces caractéristiques montrent l’arrivée d’un chiffrement plus élaboré et la possibilité de choisir, y compris depuis l’opérateur Rook, la nature des disques à provisionner.
En revanche, la possibilité d’utiliser OCS directement sur un serveur, sans passer ni par des containers ni par des VMs, semble avoir été reportée à plus tard. Celle-ci permettra de déployer OCS sur des baies de stockage externes, alors que, pour l’heure, il ne fonctionne que depuis les disques directement rattachés aux serveurs qui exécutent OCP.
Les alternatives à OCS existent. Citons les systèmes de stockage mis au point pour Kubernetes par Portworx, StorageOS ou encore MayaData. Et Henry Baltazar suppose que la concurrence va d’autant plus s’amplifier que tous les fournisseurs de stockage traditionnel dotent en ce moment leurs solutions de connecteurs pour les adapter à Kubernetes. Il suggère que, avec une telle effervescence, Red Hat a tout intérêt à ne plus trop prendre de retard sur son calendrier.
Pour approfondir sur Administration et supervision du Cloud
