GP - Fotolia
K8ssandra : l’écrin de Cassandra sur Kubernetes pensé par DataStax
Le principal contributeur à Cassandra a dévoilé K8ssandra, une librairie open source pour déployer Cassandra sur Kubernetes en production. Il tire son savoir-faire du développement d’Astra, sa DbaaS propulsée par un opérateur dédié au célèbre orchestrateur.
DataStax a pris le train Kubernetes tardivement, mais il rattrape son retard. C’est en tout cas ce que laissent à penser les dernières annonces de l’éditeur. En mai dernier, il présentait Astra, une version managée de Cassandra pour simplifier l’administration de ce SGBD complexe à maintenir à l’échelle.
Au cœur de ce produit réside un opérateur Kubernetes associé à une API sidecar, deux composants que DataStax a proposés en open source à la fin du mois de mars 2020. Seulement, ce projet intitulé Cass Operator ne comporte pas d’intégration avec des outils de sauvegarde, de restauration et de réparation.
K8ssandra vient combler ce manque. Sous ce nom se cache une collection de charts Helm pour exécuter Cassandra sur le fameux orchestrateur de containers. Présenté lors de la KubeCon organisée par la CNCF, le projet rassemble le Cass Operator, l’API sidecar, un collecteur de métriques compatible avec Prometheus, et un package Grafana pour les visualiser.
Plus important, il apporte Reaper, une brique pour planifier et gérer les réparations du SGBD NoSQL ainsi que Medusa, un système de backup. Medusa et Reaper ont tous deux été développés par le consultant The Last Prickle, acquis en mars par DataStax.
K8ssandra, une compilation de projets existants
Sur le papier K8ssandra compile des projets existants. « Ce n’est pas une révolution, c’est une évolution », accorde Patrick McFadin, Vice-président Developer Relations chez DataStax. « K8ssandra n’essaye pas de réinventer quoi que ce soit, il s’agit d’assembler des choses, bien établies au sein de la communauté open source, pour vous faciliter le déploiement de Cassandra », confirme-t-il.
« Tout ce qui peut simplifier le processus d’intégration de Cassandra avec Kubernetes trouvera son audience, particulièrement s’ils [les architectes de DataStax] emploient des outils standards comme Helm et les opérateurs » salue Stephen O’Grady, analyste chez RedMonk.
DataStax affirme travailler en étroite collaboration avec les utilisateurs, dont les grands groupes qui recourent à la base de données.
Patrick McFadin cite notamment New Relic, l’éditeur de logiciels de monitoring et d’observabilité. New Relic utilise plusieurs bases de données opérationnelles pour supporter sa plateforme de télémétrie, dont Cassandra, pour stocker les données de séries chronologiques.
« Chaque utilisateur de Cassandra a des besoins fondamentaux lorsqu’il gère un cluster », déclare Tom Offermann, ingénieur logiciel chez New Relic qui voit également d’un bon œil K8ssandra. « Par exemple, ils doivent pouvoir déployer le cluster et être en mesure de surveiller son état de santé. De plus, les utilisateurs veulent pouvoir sauvegarder et restaurer leurs données ».
La majorité des outils présents dans le package K8ssandra visent justement à répondre à ces problématiques. D’ailleurs, DataStax prévoit d’ajouter de nouveaux composants tels que le collecteur de données FluentD et le service de traçage distribué Jaeger. « Nous observons l’intérêt croissant des SRE pour le projet, car ils retrouvent les outils qu’ils manipulent au quotidien. Et parce que Kubernetes est très déclaratif, cela rend les choses beaucoup plus aisées » vante Patrick McFadin.
Préparer les migrations vers le cloud
Cette volonté de simplifier le déploiement de Cassandra sur Kubernetes semble l’arbre qui cache la forêt. En clair, K8ssandra et le Cass Operator (que DataStax espère standardiser auprès des autres éditeurs) restent des moyens.
La communauté de la SGBD NoSQL est mue par deux sujets : la migration vers le cloud et le passage de la dernière version stable de Cassandra, la 3.11 à la 4.0. Cette nouvelle mouture devrait être en disponibilité générale au mois de décembre ou en janvier prochain, selon Sam Ramji, Chief strategy officer chez DataStax.
Sam RamjiChief Strategy Officer, DataStax
« K8ssandra représente l’état de l’art de nos connaissances de tous les composants, les réglages nécessaires et fonctionnels pour configurer Cassandra sur Kubernetes », assure-t-il. « Nous mettrons le projet à jour avec l’évolution de la base de données [et de Kubernetes] ».
Concernant la migration vers le cloud, Sam Ramji constate que certains vétérans de Cassandra essayent de comprendre comment reproduire ce qu’ils ont sur site pour gérer des workloads de machine learning dans le cloud. Là encore, K8ssandra est perçu comme un moyen de déployer des environnements de tests, puis préparer de potentielles migrations. « La connaissance de Kubernetes est la compétence la plus appréciée au sein de la communauté de Cassandra, environ 70 000 personnes », note Sam Ramji.
Seulement, pour la migration de la base de données en cloud, il manque encore quelques composants. « Je pense que la prochaine mise à jour majeure de K8ssandra apportera un moyen de se connecter à un cluster externe », prédit Patrick McFadin. « Le chemin de migration idéal pour porter votre environnement Cassandra dans Kubernetes consiste à créer deux data centers (un ensemble de nœuds dans une zone géographique proche dans la topologie de Cassandra, N.D.L.R.), donc étendre un cluster sur Kubernetes. Cela offrirait la possibilité de migrer vos workloads sans aucun temps d’arrêt », ajoute-t-il.
DataStax et la communauté open source doivent encore percer le secret des Ingress, ces objets qui gèrent l’accès externe aux services dans un cluster. Ce composant n’est en rien permissif, selon Patrick McFadin.
La rencontre de Cassandra avec l’Edge Computing
La même technique pourrait servir à déployer Cassandra selon les préceptes du Edge Computing. « Des clients américains comme AT&T et Verizon essayent de comprendre comment obtenir un tissu cohérent entre leurs applications et leurs données avec la 5G. Cassandra apporte des capacités de réplications intelligentes, le fait de ne pas tout copier les données vers un point d’un environnement. Ainsi, un cluster Edge devient une région Cassandra », explique Sam Ramji.
Kubernetes semble un candidat idéal, mais cela demande à des acteurs comme DataStax d’adapter leur SGBD à ce nouveau paradigme d’architecture. « Nous essayons d’améliorer la gestion des données sur Kubernetes et je pense que la nature distribuée de Cassandra est particulièrement adaptée à l’orchestrateur » vante le Chief Strategy Officer.
La jeune Astra contemple Atlas
Ces principes alimentent également les évolutions d’Astra, pour obtenir une consistance entre le modèle open source et payant. Et parmi les sources d’inspiration de Sam Ramji, on retrouve un concurrent : MongoDB.
Sam RamjiCTO DataStax
« L’idée est de proposer une distribution open source, qui comprend tout ce que nous exploitons dans Astra pour que vous l’utilisiez vous-même. Si vous y pensez, vous savez comment MongoDB a procédé. Ils ont fait un travail incroyable. Ils ont MongoDB, une base de données open source entièrement fonctionnelle et téléchargeable, et ils ont Atlas. Donc, si vous aimez le SGBD open source, et que vous ne voulez pas le gérer, parce que vous avez mieux à faire, alors vous demandez à Mongo de l’effectuer pour vous avec Atlas. Si vous aimez Cassandra, et que vous ne voulez pas l’exploiter vous-même, vous souhaitez peut-être que nous l’opérions pour vous », indique le Chief Strategy Officer.
Toutefois, Astra reste un produit relativement récent. « Nous sommes assez satisfaits de son adoption. Nous avons déjà atteint les 10 000 utilisateurs, mais ils ont principalement essayé le service. Certains y ont trouvé leur compte, d’autres non. Cependant, je vois de nouveaux et d’anciens clients qui emploient Astra à l’échelle pour la simplicité. Par ailleurs, le dernier trimestre a été très bon », assure le responsable.