Dans notre précédent chapitre, nous avons conclu qu’avec un SGBD NoSQL, les critères de performance, évolutivité et haute disponibilité sont privilégiés, présentant avantages et inconvénients suivants :
- Avantages :
- Haute évolutivité ;
- Informatique distribuée ;
- Réduction des coûts grâce à une approche commodity hardware ;
- Flexibilité sur le schéma des données ;
- Aucune relation compliquée.
- Inconvénients :
- Pas de standardisation ;
- Cohérence éventuelle non intuitive à programmer pour les développeurs des applications ;
- Personnalisation dans la protection et la sauvegarde des données.
Comme tout environnement hautement disponible, les mécanismes de réplication synchrone ou temps réel natif n’excluent pas de faire une sauvegarde pour sécuriser les données. Effectivement Veeam ne concurrence pas ces mécanismes natifs. Mais en environnement NoSQL, il peut être nécessaire de faire un arbitrage entre disponibilité et cohérence des données afin d’introduire le minimum de latence (temps de réponse pour le client) ; il est donc nécessaire de mettre en place une stratégie de protection des données entre réplication et sauvegarde.
- Veeam prend en charge la sauvegarde des nœuds des réplicas du cluster Cassandra sans arrêt de service afin de pouvoir sécuriser la cohérence des données du cluster.
Cette approche complètera le niveau de protection et couvrira les scénarios suivants :
- La corruption des données ;
- La suppression des données suite à une erreur humaine, suite à une attaque et l’exécution de script malveillant ou autre.
Le but d’une sauvegarde Veeam dans ce contexte est de renforcer la protection des données (par l’augmentation de la rétention, un support dédié, l’externalisation, …) ainsi que de minimiser les arrêts de service pour atteindre l’objectif d’une entreprise Always-On.
Sauvegarde du moteur NoSQL Cassandra avec Veeam
En architecture distribuée avec une réplication synchrone mono-Datacenter ou multi-Datacenter, il est important de sauvegarder la base de données. Comme exemple, nous retenons le moteur de base de données Cassandra. La raison de ce choix est que Cassandra met à disposition des outils pour faire des snapshots applicatifs de la base de données via l’outil Nodetool, ce qui offre la possibilité d’assurer une sauvegarde cohérente.
Afin de pouvoir faire une sauvegarde cohérente d’une base Cassandra, il est important de comprendre comment celle-ci fonctionne. Comme de nombreux moteurs de base de données NoSQL, Cassandra est orientée performance et disponibilité. Afin de garantir un niveau de performance élevé, toute nouvelle donnée en écriture est stockée dans un premier temps dans le fichier Commit Log afin d’assurer la durabilité de l’instruction, puis en RAM dans la MemTable.
Principe de fonctionnement du moteur Cassandra
La MemTable est ensuite flushée sur disques dans la SSTable (qui correspond à la base de données) en fonction de la configuration du moteur Cassandra. Donc pour réaliser une sauvegarde cohérente, il est nécessaire de flusher la MemTable au moment de la sauvegarde.
Cassandra en environnement cluster
Cassandra est du type « Availability ; Partition Tolerance », et a fait le choix de la haute disponibilité et du partitionnement. Donc pour assurer la cohérence, un arbitrage entre performance et cohérence doit être réalisé au travers des mécanismes de réplication du cluster afin de garantir les 2 contraintes suivantes :
- La durabilité : avec l’écriture sur chaque nœud dans la MemTable et le fichier commit Log
- La cohérence: avec des réplications sur d’autres nœuds du cluster Cassandra et un acquittement qui respecte la durabilité de l’écriture (écriture en MemTable et Commit Log).
Les paramètres de réplication disponibles avec Cassandra sont :
Configuration réplication – comportement à l’écriture
Configuration réplication – comportement à la lecture
Pour une cohérence totale entre tous les nœuds du cluster, il faut mettre en place une réplication de type ALL. Cette configuration aura un impact important sur la disponibilité des données pour le client applicatif et finira par introduire de la latence applicative non souhaitée pour l’application. Ce phénomène est dû au fait de devoir figer tous les nœuds du cluster pendant l’acquittement de la réplication pour assurer la cohérence ; ce qui n’est pas le but principal attendu avec un SGBD NoSQL de type AP.
Le premier élément de protection des données sera une réplication entre les nœuds du cluster. Dans une stratégie de réplication différente au type ALL, il est important de pouvoir compléter celle-ci avec une sauvegarde. Dans ce cas, et en fonction de la topologie du cluster, le principal inconvénient sera qu’à un instant T les nœuds du cluster ne possèderont pas la même donnée, ce qui fera apparaitre un éventuel problème de cohérence au sein même du cluster.
Pour pallier cet inconvénient, il est important de sécuriser la cohérence des données au travers de la sauvegarde. Avec le moteur Cassandra, nous avons la possibilité de piloter avec Veeam des snapshots applicatifs des bases de données afin de compléter simplement la protection des données.
Mise en place d’une stratégie de sauvegarde cohérente Veeam pour Cassandra
Prérequis et environnement testé :
- OS : Debian 8 64 Bits + VMware Tools
- Cluster Cassandra 3.0 virtualisé 2 nœuds
- Scripts pre-freeze et post-thaw installés sur le serveur de sauvegarde.
L’accès SSH à Cassandra et les VMware Tools doivent être configurés et démarrés. Dans le cas contraire, il ne sera pas possible d’exécuter les scripts pre-freeze et post-thaw nécessaire à la sauvegarde cohérente.
Procédure de sauvegarde cohérente de la base de données
Création de scripts pre-freeze et post-thaw
Le moteur Cassandra intègre l’utilitaire de ligne de commande NodeTool. Il est utilisé pour administrer le moteur de base de données et offre la possibilité de réaliser des snapshots de la base de données. Il sera donc possible, via cet outil d’effectuer une sauvegarde cohérente sans arrêter les services. Nous allons réaliser une sauvegarde Veeam de type application-aware processing et piloter les scripts qui nous permettrons de mettre la base dans un état cohérent et consistant.
Exemple de workflow pre-freeze
Exemple de script pre-freeze
Nous utilisons la commande Nodetool avec le paramètre flush pour forcer le flush de la MemTable sur disque puis nous réalisons la prise de snapshot via le paramètre snapshot pour assurer la cohérence. Pour finir, le process de sauvegarde réalise le snapshot VM de VMware pour préparer la sauvegarde des données.
Exemple de workflow post-thaw
Exemple de script post-thaw
Nous utilisons toujours la commande Nodetool de Cassandra avec le paramètre clearsnapshot afin de supprimer les snapshots de la base donnée pour finir notre tâche de sauvegarde.
| Note : S’il existe une stratégie de sauvegarde locale basée sur des snapshots Cassandra, il sera nécessaire de modifier le script fourni en exemple pour identifier et supprimer le snapshot créé par la tâche de sauvegarde Veeam. |
Création de scripts pre-freeze et post-thaw
Après création et validation des scripts, il suffit de les copier dans un répertoire du serveur de sauvegarde Veeam – C:\scripts dans cet exemple. Effectivement, le serveur de sauvegarde Veeam injecte les scripts dans la machine sauvegardée pour les exécuter localement.
Démarrer l’assistant de configuration de la tâche de sauvegarde.
Configuration tâche de sauvegarde – Assistant de création
Pour réaliser la sauvegarde cohérente sans faire d’arrêt de service, sélectionner le mode application-aware processing.
Configuration tâche de sauvegarde – Sélection application-aware processing
Et sélectionner les scripts à exécuter au sein de la VM à sauvegarder.
Configuration tâche de sauvegarde – Sélection des scripts à exécuter
Après avoir finalisé la tâche de sauvegarde, il suffit de démarrer le job et de suivre le déroulement de la sauvegarde.
Exécution du job de sauvegarde – Statistiques
Comportement et résultat pendant la sauvegarde
Pendant la sauvegarde et juste après l’exécution du script Pre_SnapDB.sh, vous pouvez apercevoir le snapshot de la base de données.
Conclusion
En nous appuyant sur les outils du SGBD Cassandra, nous venons de compléter la protection du cluster Cassandra sans interruption de service (arrêt du nœud ou de la base de données avec une sauvegarde cohérente). Cette sauvegarde étant réalisée depuis un nœud réplica du cluster Cassandra, nous pouvons protéger les données du SGBD sans introduire de latence applicative pendant la sauvegarde.
Dans notre prochain et dernier article, nous aborderons la restauration des données avec Universal Application Item Recovery (U-AIR). Cette méthode sera utilisée pour restaurer la donnée à partir d’un snapshot applicatif du moteur Cassandra.