DBaaS : Nutanix s’attaque au « cauchemar » des snapshots de bases MongoDB shardées

Une intégration certifiée par MongoDB pour gérer les clusters shardés

Parmi ces ajouts, l’intégration certifiée entre NDB et MongoDB Ops Manager constitue la nouveauté majeure. Ops Manager est l’utilitaire principal de gestion automatisée et de supervision des backups de la fameuse base de données NoSQL. Ici, NDB est connecté à cet outil à travers l’API réservée aux éditeurs tiers de solutions de backups.

Dans cette intégration, NDB ne remplace pas Ops Manager. L’utilitaire de MongoDB sert toujours à gérer les sauvegardes, les restaurations, mais Nutanix y ajoute sa technologie Time Machine, dédiée à la restauration point-in-time (à un instant donné). Elle permet de créer des snapshots de bases de données sources ainsi que de leurs logs de transactions.

Selon Nutanix, il s’agit d’accélérer la restauration pour des applications critiques. L’éditeur assure qu’elles peuvent avoir lieu en quelques minutes.

Les snapshots sont gérés au niveau de la couche de stockage. La création des instantanés serait également rapide.

« Lorsqu’un snapshot est déclenché, Nutanix crée un nouveau vDisk avec accès en lecture/écriture : le vDisk d’origine dont l’instantané a été pris et le nouveau vDisk font tous deux référence à la même carte de blocs sous-jacente, sans création de nouveaux blocs de données au moment de la prise d’instantané », précise l’éditeur dans un billet de blog. « Comme il s’agit principalement d’une opération axée sur les métadonnées, la création de snapshots est quasi instantanée et largement indépendante de la taille du jeu de données ».

De ce fait, la création d’un snapshot pour un dataset de 50 To ou de 500 Go se ferait « en un temps comparable ». L’opération de restauration bénéficierait de la même capacité. Dans la console, la récupération des logs peut être configurée toutes les 15, 30 ou 60 minutes. La création de snapshot peut être planifiée de manière quotidienne, hebdomadaire, mensuelle ou trimestrielle.

Et de présenter un benchmark mené par son partenaire Tata Consultancy Services. Sur un cluster de trois nœuds totalisant 40 To et 20 bases de données PostgreSQL, la restauration complète prendrait 22 minutes, tandis que les clones créés à partir des snapshots peuvent être provisionnés en 16 minutes. Nutanix ne relaie pas les performances de son service avec MongoDB.

Avec NDB 2.10, Nutanix cible plus particulièrement les clients ayant opté pour MongoDB Enterprise Advanced, la licence Self-Hosted la mieux dotée du catalogue de l’éditeur. 

Les grands groupes qui choisissent cette option doivent généralement gérer des déploiements d’envergure. Du fait des gros volumes de données et des exigences de conformité, ceux-là peuvent recourir au sharding pour distribuer les grandes collections de documents sur plusieurs machines, de plus en plus souvent en cloud hybride.

Le déploiement de nouveaux clusters réclame généralement le concours de plusieurs équipes, rappelle Nutanix.

« Les équipes responsables de l’infrastructure gèrent l’approvisionnement des machines virtuelles et du stockage, les administrateurs de bases de données configurent les serveurs de configuration, les shards et les routeurs Mongo, tandis que les équipes de sauvegarde synchronisent les instantanés avec les agents Ops Manager », expliquent les porte-parole de l’éditeur.

Pour éviter la désynchronisation de ces opérations, NDB doit automatiser non seulement la création et la récupération des snapshots (un « cauchemar » quand les données sont shardées, dixit Nutanix), mais également le provisionnement des clusters shardés, sur site et dans le cloud (AWS, Azure).

Concernant ce point, comme pour la création des snapshots, NDB permet d’enclencher l’extension des clusters shardés en jouant le rôle de donneur d’ordre pour Ops Manager. De plus, Nutanix se charge de patcher l’OS des VM et d’installer l’agent de collecte de log MongoDB, tandis qu’Ops Manager gère les mises à jour des bases de données.

Nutanix dit ainsi offrir « un seul flux de travail pour provisionner des VM, la configuration réseau, le stockage et MongoDB, que ce soit avec des clusters shardés ou des replica sets ».

Ici, les machines virtuelles Linux (RHEL ou Rocky Linux) peuvent être déployées à l’aide d’AHV, l’hyperviseur de Nutanix ou ESXI, celui de VMWare. Pour tous les déploiements multicloud, le recours au service managé Nutanix Cloud Clusters (NC2) est nécessaire.

MySQL, SQL Server : Nutanix corrige quelques oublis en faveur des DBA

Pour MySQL et SQL Server, les ajouts sont mineurs, mais visent d’après l’éditeur à supprimer les « frictions » rencontrées par le passé par les DBA.

NDB 2.10 permet désormais d’assigner explicitement des adresses IP pour les VM, les clusters, les groupes de disponibilité (AG) et les Failover Cluster Instances pendant le provisionnement, et non plus après comme auparavant. Cela obligeait à réassigner les adresses IP et à mettre à jour les DNS manuellement. De même, il n’était pas possible de choisir simplement les disques durs cibles pour les fichiers de données, les fichiers de logs et TempDB lors du provisionnement. C’est maintenant possible.

Concernant MySQL, Nutanix permettait le déploiement des clusters de haute disponibilité uniquement depuis une API ou son CLI. Un nouvel écran dans l’interface de NDB doit « éviter des heures de tâches répétées et les dérives de configuration ».

Nutanix Database Service à cheval entre la sauvegarde et l’orchestration DBaaS

Malgré sa versatilité et l’ambition de Nutanix d’en faire un orchestrateur de bases de données managées, NDB reste avant tout un gestionnaire de sauvegardes et de restauration. Par exemple, après la cyberattaque qu’il a subie en 2021, le groupe français Manutan a remplacé Netbackup (alors portée par Veritas, désormais fournie par Cohesity) par NDB, en corrélation avec les solutions de cloud privé de Nutanix.

Sur ce segment spécifique, NDB peut donc être mis en face des solutions de Percona (PostgreSQL, MySQL, MongoDB), NetApp (Oracle, SQL Server), et en partie de Rubrik (SQL Server, Oracle, SAP HANA, Apache Cassandra, DataStax, MongoDB).

Sur la gestion de configuration et de déploiement, les témoignages ne sont pas légion (trois avis sur Gartner Peer Insights, un seul sur G2), mais sont globalement positifs. Il faut aussi dire que les solutions comparables ne courent pas les rues. Parmi elles : Percona, Severalnines (ClusterControl), et dans une moindre mesure HPE Morpheus.

Les fonctions de déploiement de SGBD de Red Hat OpenShift sont rudimentaires, tandis que les fournisseurs comme Aiven ne proposent pas de déploiements hybrides (uniquement multicloud).

Si elle permet les provisionnements on premise, la plateforme NetApp Instaclustr ne prend pas en charge MongoDB (elle couvre déjà Cassandra, Kafka, OpenSearch, PostgreSQL, Cadence et Clickhouse). De plus, le control plane réside dans le cloud.

Précisons que la majorité des entreprises délèguent la gestion des SGBD aux fournisseurs cloud, américains ou non.