DataStax veut faciliter le déploiement cloud de Cassandra avec Kubernetes

Kubernetes, la solution pour gérer la complexité de Cassandra à large échelle

Hier, DataStax a annoncé la disponibilité d’un nouvel opérateur Kubernetes open source. Ce composant doit aider à l’émergence d’un effort communautaire pour faciliter les déploiements de Cassandra sur l’orchestrateur de containers. De son côté, l’éditeur avait présenté une version managée du SGBD NoSQL dans le cloud à la fin de l’année dernière.

Un opérateur est un manifeste qui automatise le déploiement d’une application ou d’un service sur un cluster Kubernetes. De nombreux éditeurs conçoivent leurs propres opérateurs, Instaclustr – lui aussi éditeur d’une version d’Apache Cassandra – est l’un d’entre eux.

Si DataStax et Instaclustr ont clairement des offres qui se chevauchent, leur objectif est différent, déclare Jason Bloomberg, président de la société d’analyse et de conseil Intellyx.

« Le point fort de DataStax repose sur les scénarios hybrides IT et multi-cloud, tandis qu’Instaclustr se concentre sur la prise en charge d’une gamme de produits d’infrastructure de données open source dans des environnements de cloud public et multicloud », affirme Jason Bloomberg.

Un seul opérateur pour toutes les orchestrer

Selon Sam Ramji, chief strategy officer, chez DataStax, il n’y a pas moins de huit opérateurs Kubernetes différents sur le marché. Les éditeurs cherchent en effet à adapter cette base de données, historiquement installée sur site dans le cloud. 

Mais le CSO considère que les opérateurs pour Cassandra sont configurés pour des versions spécifiques de la base de données NoSQL. À l’inverse, il fait valoir que DataStax tente de créer une approche open source généralisée qui fonctionnera pour un large éventail d’applications et de déploiements de Cassandra sur Kubernetes.

Sam Ramji aimerait voir une collaboration forte de la part de la communauté open source autour de l’opérateur Cassandra. DataStax veut que d’ici un an sa proposition devienne un standard.

Le 30 mars, DataStax a également donné l’accès à un proxy sidecar de gestion d’API open source.

Cassandra est typiquement gérée en ligne de commande avec des API Java Management Extensions (JMX). Le module API Management adopte une approche modernisée offrant une interface extensible à laquelle les développeurs peuvent se connecter pour la gestion de la base, selon Patrick McFadin, vice-président des relations avec les développeurs chez DataStax.

« Techniquement parlant, un nœud correspond à un processus JVM (Java Virtual Machine) en cours d’exécution. Le sidecar est établi à côté de ce nœud en fonctionnement », explique Patrick McFadin.

Il ajoute que chaque nœud Cassandra est indépendant et dispose de sa propre API REST pour les opérations en cours à son niveau, mais il peut également invoquer des opérations à l’échelle du cluster.

De nombreux tests et développements à mener

L’API Management complète l’opérateur Kubernetes dans le but de faciliter le déploiement et la gestion de Cassandra par les administrateurs. 

« Le side-car Management API et les opérateurs Kubernetes vont rendre Cassandra beaucoup plus facile à exploiter, parce qu’à l’heure actuelle, il y a beaucoup d’ajustements manuels et beaucoup d’expertise est nécessaire », avoue Sam Ramji.

« La gestion d’API est vraiment essentielle. Il ne suffit pas de dire à l’opérateur ‘déploie mon cluster’, il y a encore beaucoup de nuances à prendre en compte après cela », assure Patrick McFadin. « J’espère qu’avec l’API Management, nous pourrons nous lancer dans cette approche généralisée pour qu’en quelques frappes ou en cliquant sur un bouton, vous puissiez démarrer vos nœuds ».

Les deux projets sont disponibles sur GitHub et sont compatibles avec Apache Cassandra 3.11.6 et 4.0 Alpha3. Le Cass Operator (le nom officiel de l’opérateur Kubernetes pour Cassandra) nécessite également la version 1.12 des clusters K8s. Pour l’instant, l’opérateur a pour charge d’émuler un Data Center Cassandra. Tout comme avec une installation directe sur un serveur physique, un cluster doit contenir trois nœuds sur un « rack », sur un cluster Kubernetes.

Par ailleurs, il n’est pas recommandé d’utiliser le Cass Operator en production. La version 1.0 ne supporte pas les fonctionnalités de réparation, de backup et de restauration inclus dans Cassandra. L’équipe de DataStax précise que la désinstallation de ce système provoque la destruction des données contenues dans le cluster.