Comprendre comment Microsoft VSS fonctionne pour la sauvegarde d'environnements virtualisés

Lancé à l’origine avec Windows Server 2003, l’API de snapshot de Windows, VSS (Microsoft Volume Shadow Copy Service) a largement été adoptée par les fournisseurs d’outils de sauvegarde et par les éditeurs d’applications pour simplifier et accélérer la sauvegarde des applications Windows.

Dans un monde de plus en plus virtualisé, il est toutefois intéressant de comprendre les mécanismes de VSS et la façon dont la technologie a évolué pour s’adapter à la sauvegarde des environnements virtuels. D’autant que si les solutions de sauvegarde de machines virtuelles se multiplient, 46% des environnements informatiques ont encore recours à des agents de sauvegarde dans les VM pour réaliser l'opération. La raison principale est qu’il est impératif dans certains scénarios applicatifs d’assurer la consistance des données (cas notamment des applications transactionnelles s’appuyant sur une couche de base de données).
La plupart des applications de sauvegarde s'appuient sur la capacité des hyperviseurs à notifier les applications clients fonctionnant dans une VM de l'imminence d’une sauvegarde. Un processus de notification qui déclenche la mise en cohérence des données avant sauvegarde.

Dans cet article, dérivé d’une analyse de Jason Buffington, un analyste senior du cabinet Enterprise Strategy Group (ESG), nous allons utiliser l’exemple d’une sauvegarde de SQL Server, mais le scénario de sauvegarde décrit s’applique aussi à de nombreuses applications.

Comprendre les mécanismes de VSS

Pour de nombreuses applications serveur Windows, Microsoft fournit un service essentiel pour faciliter les sauvegardes, baptisé Volume Shadow Copy Service (VSS). L’architecture du service VSS s’appuie sur trois composants principaux :

Le requêteur VSS : ce composant est en général embarqué dans l’agent de sauvegarde fourni par l’application de sauvegarde qui initie le processus de backup.

Le « VSS Writer » : ce composant de VSS est généralement délivré par les applications (typiquement SQL Server, Exchange, le file system Windows…). Sa mission est d'assurer la consistance des données afin que l’état de l’application permette une sauvegarde fidèle de l’application.

Le VSS Provider : ce dernier élément est fourni par la couche de stockage (qu’il s’agisse d’un logiciel de stockage ou d’une baie de stockage). Sa mission est de mettre à disposition de l’application de sauvegarde un instantané des données de l’application à protéger.

Essentiellement, une sauvegarde VSS fonctionne en huit étapes relativement simples:

1. Le requêteur VSS de l’agent de sauvegarde demande à VSS la liste des workloads susceptibles d'être sauvegardées.

2. VSS énumère toutes les applications qui ont enregistré un « VSS Writer ».

3. Le requêteur VSS de l'agent de sauvegarde demande que la charge de travail soit préparée pour la sauvegarde.

4. Le composant VSS Writer de l’application à sauvegarder effectue les opérations nécessaires pour que l’application soit prête à la sauvegarde (mise en cohérence des données, vidage des données en cache…).

5. Après cette préparation des données, le VSS writer de l’application notifie le service VSS et le « VSS Provider » que l’application est dans un état qui rend possible la sauvegarde.

6. Le VSS Provider prend un cliché instantané des données (snapshot) et en informe le requêteur VSS.

7. Le requêteur VSS enregistre le snapshot dans le VSS Provider et envoie les données vers le serveur de sauvegarde.

8. Une fois la sauvegarde achevée, le service VSS notifie le VSS provider qu’il peut libérer l’espace occupé par le snapshot et informe le VSS Provider que les données sont sauvegardées. L’application peut alors réaliser ses tâches de maintenance post-sauvegarde.

VSS dans un environnement virtualisé

Si le processus est relativement simple avec un serveur physique, il se complique un peu lorsque l’on est en en environnement virtualisé. Du fait de l’ajout de la couche d’hypervision, le défi est de comprendre où se situent les différents composants impliqués dans un backup. Pour que la sauvegarde d’une machine virtuelle s’effectue correctement, deux niveaux de conversations de données doivent se produire: d'abord entre le serveur de sauvegarde et de l'hyperviseur (hôte), puis entre les OS invités et leur hôte et/ou le serveur de sauvegarde.

L’hyperviseur Hyper-V de Microsoft dispose de son propre VSS Writer pour assurer la sauvegarde des machines virtuelles. Les composants d'intégration Hyper-V qui sont automatiquement installés dans chaque OS invité Windows incluent un requêteur VSS. Le processus de sauvegarde devient donc un peu plus complexe. Réexaminons donc les différentes étapes d’une sauvegarde utilisant VSS dans un environnement virtualisé.

Du point de vue du serveur hôte (celui sur lequel tourne l’hyperviseur) :

1. et 2. L'agent du logiciel de sauvegarde tourne sur l'hôte Hyper-V et détecte qu’Hyper-V peut être sauvegardé en raison de la présence d’un « VSS writer » propre à l’hyperviseur de Microsoft.

3. Le logiciel de sauvegarde demande la sauvegarde d’une machine virtuelle spécifique.

4. Le « Writer VSS » de l'hôte Hyper-V fait ce qu'il doit faire pour préparer son « application » à la sauvegarde. En l’occurrence, dans ce cas précis, il prépare la VM à être sauvegardée.

C’est à partir de cette étape que les choses se compliquent. Car pour préparer une VM Windows à la sauvegarde, le VSS Writer de l’hôte informe le requêteur VSS de la VM de se comporter comme un agent de backup, ce qui fait que l’intégralité du processus est répétée dans la VM. On parle alors d’un processus VSS récursif.


Dans la VM, les opérations suivantes sont réalisées :

1., 2. et 3. Le requêteur VSS de la VM découvre (via leur VSS Writers) les applications susceptibles d’être protégées par VSS, par exemple SQL Server ou Exchange, et ordonne à ces applications de se préparer à la sauvegarde.

4. Les applications de la VM exécutent les opérations nécessaires pour se préparer à la sauvegarde (purge des journaux, vidage des données en cache…).

5. Dès que les applications rapportent qu’elles sont prêtes à la sauvegarde, leurs VSS Writers respectifs avisent le provider VSS de l’OS Windows de la VM que les données sont prêtes.

6. Le provider VSS de la machine invité réalise un cliché instantané des volumes tel qu’indiqué par les applications.

7. Le requêteur VSS de la VM informe alors son serveur de sauvegarde (qui est en fait l'hôte Hyper-V) que la VM est dans un état protégé et ses applications dans un état consistant.

Maintenant que le contenu de la VM est protégé c’est au tout de son conteneur (la VM) d’être protégé.

Souvenez-vous en effet que dans un modèle de sauvegarde basé sur l'hôte, la machine virtuelle dans son ensemble est « l’application ». Elle est désormais prête à la sauvegarde et le processus peut se poursuivre :

5. Le VSS Writer de l'hôte Hyper-V informe l'OS Windows de l’hôte et les providers VSS sous-jacents que la VM est prête à être « snapshotée ».

6. Le VSS provider réalise le cliché instantané du volume virtuel de la machine virtuelle (fichier VHD).

7. L'agent de sauvegarde basé sur l'hôte qui a demandé la sauvegarde obtient l’accès à ce snapshot et l’utilise pour alimenter le serveur de sauvegarde.

C’est ainsi que fonctionne une opération de sauvegarde VSS récursive. Ce fonctionnement général ne veut pas dire que toutes les solutions de sauvegarde utilisant VSS se valent. Elles diffèrent ainsi en terme d’administration et de gestion des plannings de sauvegarde, en matière de support de la déduplication, dans leur capacité à restaurer tout ou partie d’une VM (et notamment leur capacité à restaurer des fichiers individuels au sein du VHD).

Il est aussi bon de noter que ce processus fonctionne car il y a une intégration complète de la chaîne VSS de l’hyperviseur à l’OS Windows de la machine hôte. Le processus est un tantinet différent avec VMware et les API VMware pour la protection de données (VADP). Les solutions de sauvegarde VMware parviennent au même résultat que les solutions Hyper-V, car elles s’appuient sur les mêmes mécanismes au sein de la machine virtuelle Windows. Mais les mécanismes au niveau hôte sont différents.

Si vous choisissez une stratégie de sauvegarde basée sur l’hôte, veillez à bien comprendre les aspects clés des échanges entre clients et hôte, ainsi que des fonctions importantes comme le nettoyage des VHD au cours du processus récursif. Cela pourrait être la différence entre une récupération réussie et certains VHD ou VMDK.

Jason Buffington est un analyste senior travaillant sur le marché de la protection de données pour Enterprise Strategy Group (ESG). Il a plus de 20 ans d'expérience de l'industrie IT.

Article adapté de l'original en anglais par Christophe Bardy, LeMagIT