Acropolis Hypervisor est le troisième hyperviseur supporté par Nutanix. Cette offre de virtualisation entièrement construite par Nutanix repose sur le couple KVM/Qemu. Ceci étant dit, Nutanix a conservé réellement que la base de KVM/Qemu et 99% des fonctionnalités de AHV (et donc du code) ont été entièrement refaites/repensées pour s’inscrire dans la trajectoire « Enterprise Cloud ».

 Jusqu’à maintenant pour sauvegarder une machine virtuelle sur AHV, il fallait soit deployer des agents de sauvegarde dans les VM, soit utiliser le logiciel Simpana avec Intellisnap de Commvault pour realiser une sauvegarde sans agent.

Pas toujours evident de répondre aux besoins des clients en terme de sauvegarde avec ces deux alternatives, le déploiement d’agent dans les VMs étant souvent associé à une méthode non adaptée lorsque l’on parle de plate-forme de virtualisation et l’adoption d’un nouvel outil de sauvegarde demande l’adhesion des équipes techniques et souvent implique une migration des outils/processus de backup.

C’est la raison pour laquelle il était indispensable de disposer d’une API de sauvegarde pour AHV. L’objectif est de permettre à des solutions de sauvegardes du marché de venir s’interfacer avec l’Acropolis Distributed Storage Fabric pour opérer une sauvegarde sans agent. Pour que cette sauvegarde soit la plus optimisée, il fallait également fournir une fonction de CBT, souvent appelé « Changed Block Trancking ». Chez Nutanix cette fonction de CBT fait reference a « Change Regional Metadata ». De cette manière on peut également envisager des sauvegardes incrémentalles et différentielles pour réduire les fenêtres de sauvegardes.

Avec cette version 5.0 de l’Acropolis OS, Nutanix lève le voile sur la version 3.0 des ces REST API. Ces nouvelles API permettent au logiciel de sauvegarde d’interroger le système à la recherche des données (métadonnées) modifiées entre deux snapshots.

Pour comprendre un peu mieux le fonctionnement cette API, voici les principales étapes du workflow de creation de snapshot :

1. Connexion et authentification aux REST API v3.0 du cluster
2. Utilisation de l’API /vm_snapshot pour créer soit un snapshot « application consistent », soit un snapshot « crash consistent »
3. Analyse du contenu du snapshot via une requête GET sur l’UUID du snapshot
4. Dans le cas d’un backup full, tous les fichiers presents dans le snapshot sont lus. Dans le cas d’une VM sur AHV, le fichier de configuration de la VM (fichier xml) doit être demandé à Cassandra par le biais d’autres APIs, puis sauvegardé dans le snapshot avec le(s) vdisk(s)
5. Dans le cas d’une sauvegarde incrementale ou différentielle, l’API va s’appuyer sur le « Changed Region Tracking » pour réclamer les métadata ayant été modifiées entre ce snapshot et le snapshot de référence. Seule les données modifiées sont lues
6. Si le snapshot pris à l’étape 2 n’est plus nécessaire alors une requête DELETE est envoyée via l’API /vm_snashot pour le supprimer
7. Si le snapshot pris à l’étape 2 doit être conservé comme snapshot de référence pour une sauvegarde incrementale ou différentielle, alors on declare une date d’expiration sur ce snapshot via une requête PUT.

Il s’agit de la premiere version de cette API et comme toute premiere version il y a quelques restrictions. Pour le moment les Volume Group ne peuvent pas être sauvegardés par ce mécanisme. Cette API est disponible pour le moment que pour AHV. Assez logiquement, il est fort probable que les autres hyperviseur supportés par Nutanix puisse bénéficier de cette alternative de sauvegarde dans les prochaines version de AOS.

La bonne nouvelle, c’est que l’apparition de cette API avec prise en charge du « Change Block Tracking » va s’en doute permettre à d’autres acteurs du monde du backup (Veeam, Rubrik etc…)de venir s’intégrer au ADSF et prendre en charge la sauvegarde des machines virtuelles en environnement Acropolis Hypervisor.