dimanche , 24 juin 2018
Templates by BIGtheme NET
Home / VMware / La sauvegarde sous vSphere 5

La sauvegarde sous vSphere 5

Généralité

Le passage en environnement virtualisé est l’occasion de revoir en profondeur les architectures de sauvegarde. Les technologies et méthodologies doivent être adaptées parce que les problématiques sont différentes. Une VM n’est pas sauvegardée comme un serveur classique. Ce sujet étant souvent complexe, il doit faire l’objet d’un projet à part entière afin de moderniser et d’industrialiser les méthodes de travail. Une implémentation réussie de la sauvegarde permet de tirer profit des avantages de la virtualisation et sert de levier pour réduire les coûts. A contrario, une mauvaise implémentation de la sauvegarde peut avoir des conséquences catastrophiques pour l’ensemble du système d’information.
Dans ce chapitre, après avoir défini certains concepts nous détaillons les fonctionnalités clés qui permettent de faire face aux problématiques de cet environnement.

1. Qu’est-ce qu’une sauvegarde ?

La sauvegarde est une copie exacte (copie physique) d’une donnée de production, créée dans le but de pouvoir restaurer une donnée source corrompue ou détruite. Cette sauvegarde peut être créée de différentes façons :
  • En copiant la donnée à des instants précis.
  • En répliquant cette donnée : la donnée est toujours identique à l’originale même en cas de changement de celle-ci.

2. Objectifs des sauvegardes

La sauvegarde a deux objectifs principaux :
  • Opérationnel : pour restaurer les données dans le cas de suppression accidentelle, perte ou corruption des données (attaque de virus par exemple).
  • Plan de Reprise d’Activité : pour restaurer les données en cas de sinistre majeur.

3. Impact Business

Il faut toujours avoir à l’esprit que ce qui est le plus important dans la sauvegarde, c’est la restauration !
Nous rencontrons souvent des responsables informatiques qui mettent en place des systèmes de sauvegarde sans se soucier de la façon dont ils vont pouvoir restaurer. Il convient de se poser un certain nombre de questions qui ont un impact direct avec le business. En voici une liste non exhaustive :
  • Quels sont les RPO et RTO ?
  • Quelle est la nature des données à sauvegarder : est-ce que ce sont des applications, un système d’exploitation, une base de données, une messagerie, des fichiers plats, des fichiers de logs, des fichiers journaux d’une base de données, un système de fichiers, de la vidéo… ?
  • Quand et où les restaurations sont-elles réalisées ?
  • Quelles sont les fenêtres de sauvegardes ?
  • Quelles sont les restaurations demandées les plus fréquentes ?
  • Dans le cas où une application est sauvegardée, est-elle bien consistante ?
  • Quelle est la politique de rétention à mettre en œuvre : combien de sauvegardes quotidiennes, hebdomadaires, mensuelles et annuelles à conserver ?
  • Faut-il externaliser les sauvegardes ?
  • Quel est le lien et la bande passante entre les sites distants et le site centralisé ?
  • Quel est le taux moyen de modifications des données à sauvegarder par jour ?
  • Les données sont-elles cryptées ou compressées ?

4. La méthode traditionnelle de sauvegarde

L’utilisation d’agents pour la sauvegarde est la méthode utilisée traditionnellement dans un environnement physique. Elle consiste à installer un agent applicatif dont le but est de mettre en cohérence l’application avant la sauvegarde afin d’avoir une image restaurable. L’agent envoie les données par le réseau à des moments définis au serveur qui s’occupe de les sauvegarder sur un média tel qu’un lecteur de bandes ou des disques durs.
Les médias de sauvegarde utilisés historiquement sont les bandes magnétiques qui possèdent l’avantage de stocker de très grosses volumétries à moindre coût et de pouvoir externaliser les bandes dans un endroit sans frais de fonctionnement. L’utilisation de disques durs est possible en faisant de l’émulation de bandes : on appelle cela des VTL (Virtual Tape Library) afin d’offrir une plus grande souplesse d’utilisation et des temps d’accès rapide sans rien changer de l’architecture logicielle de sauvegarde en place.
En environnement physique traditionnel, faire tourner un agent de sauvegarde est envisageable car les ressources du serveur sur lequel tourne l’applicatif sont généralement disponibles. Rappelons qu’en moyenne, seulement 10 % des ressources d’un serveur sont utilisées, les ressources sont donc disponibles pour un agent de sauvegarde.
Mais si cette méthode est éprouvée, elle engendre une surcharge de travail importante pour les équipes informatique. Elle nécessite le déploiement d’agents, des mises à jour et de la maintenance. Les agents consomment de façon intensive les ressources des serveurs (CPU, mémoire, réseau et stockage) et la restauration est souvent laborieuse (elle est souvent plus lente et par étapes). De plus, cela nécessite une gestion des médias qui est souvent sujette à des erreurs de manipulations ou des oublis…

5. Les problématiques de sauvegarde en environnement virtuel

a. Risques de contentions

L’un des objectifs de la virtualisation est d’atteindre de hauts niveaux de consolidation afin de réduire les coûts. Il faut que les ressources disponibles des serveurs hôtes soient entièrement dédiées aux applicatifs. Les agents de sauvegarde utilisent et consomment ces ressources de façon importante. Il n’est donc pas recommandé d’utiliser des agents dans les Guest OS qui risquent de dégrader fortement les performances et qui peuvent engendrer des contentions.
Cependant dans certains cas et pour certaines applications de type base de données, messagerie, etc. il est nécessaire d’installer des agents dans le Guest OS afin d’apporter une plus grande finesse de paramétrage et une granularité pour la restauration. Par exemple avec des agents de messagerie, il est possible de restaurer uniquement un e-mail.

b. Criticité des fichiers

Tout le contenu du disque virtuel est représenté par un fichier principal vmdk qui contient le système d’exploitation, la configuration, les applications et les données. Ce fichier est très critique et une erreur de manipulation de la part d’un administrateur comme sa suppression accidentelle par exemple peut être catastrophique. Il faut donc considérer cette criticité avec la plus grande précaution et proposer des solutions permettant de restaurer rapidement le fichier vmdk.

c. Volumétrie importante

Dans un environnement virtuel, il est possible de sauvegarder l’image entière d’une VM. Cette image engendre des volumétries très importantes au regard des données traditionnellement sauvegardées en environnement physique. Il faut donc adapter les technologies pour accueillir de telles volumétries et tenir les délais impartis dans les fenêtres de sauvegarde (en général de 8 heures la nuit).

d. Meilleurs niveaux de service exigés

La mise en place d’une infrastructure virtuelle doit améliorer considérablement les niveaux de service : SLA (Service Level Agreement). Ce niveau d’exigence attendu pour remettre un système en production avec le moins de perte de données est plus important. Il faut pouvoir accéder directement et rapidement aux données sauvegardées et la restauration ne doit durer que quelques minutes.
Dans ce contexte, il est compréhensible que les anciennes méthodes de sauvegarde traditionnellement utilisées sur bande ou VTL ne sont pas adaptées. Il faut donc prévoir des technologies performantes exploitant les spécificités de la virtualisation.
 images_ch5fig1

 

Le serveur proxy doit pouvoir accéder au Datastore (LUN VMFS, NFS et/ou RDM) hébergeant les VM. La sauvegarde se réalise au travers du réseau LAN ou SAN.
Lorsque les VADP sont utilisées pour sauvegarder une VM, c’est le mécanisme de snapshot (cf. section Les snapshots – Snapshots de VM dans ce chapitre) qui entre en jeu. Les sauvegardes réalisées avec VADP peuvent garantir une consistance au niveau applicatif sous certains environnements Windows grâce à VSS (Volume Shadow copy Service). De plus, avec le support de Changed Block Tracking (cf. section dédiée dans ce chapitre), les sauvegardes et les restaurations sont extrêmement rapides réduisant la bande passante réseau car seuls les blocs modifiés sont transférés vers le serveur de sauvegarde.

Les différents niveaux de restauration

Certains éditeurs tirent profit de ces API pour faire des restaurations au niveau de l’image complète de la VM (Full VM) ou au niveau fichier dans les Guest OS (File Level Restore).
  • La restauration complète de la VM (Full VM) permet de restaurer l’intégralité de la VM et tous les fichiers associés. L’intérêt de ce mode est de sauvegarder directement la machine virtuelle complète avec son OS et ses applications et de pouvoir restaurer la machine virtuelle dans son intégralité. Mais il faut faire attention aux volumétries qui peuvent devenir très importantes si des techniques telles que la compression ou la déduplication ne sont pas utilisées.
  • La restauration au niveau fichier (File Level) permet de restaurer des répertoires et fichiers à l’intérieur du Guest OS sans devoir restaurer l’image entière de la VM. Lorsqu’une restauration au niveau fichier est lancée, le serveur proxy se voit présenter les volumes de la machine virtuelle sous la forme d’un point de montage et permet de ne restaurer que le fichier dont on a besoin. Aucune volumétrie locale n’est nécessaire sur le serveur proxy puisque c’est un point de montage.
Cette méthode n’est possible qu’avec certains logiciels de sauvegarde. Certains logiciels créent des index nécessaires lors de la sauvegarde afin de pouvoir restaurer les fichiers par la suite car ils sont incapables de monter une sauvegarde. Il faut bien se renseigner auprès de l’éditeur sur ce point.
Certains éditeurs proposent cette possibilité en couplant les VADP avec d’autres API, par exemple les API vix fournies par VMware.

3. Sauvegardes avec agents

Cette méthode traditionnelle avec agents est utilisée principalement pour les VM ayant des applications de type base de données. Ces VM sont des cas d’exception nécessitant de conserver les agents dans la machine virtuelle car la gestion des logs et des bases s’effectue lors des sauvegardes. L’agent permet aussi une restauration granulaire des tables et des enregistrements alors qu’en mode Full VM, l’intégralité de la machines virtuelle doit être restaurée pour retrouver la donnée manquante. Par exemple pour des serveurs de messagerie de type exchange où il est préférable de restaurer le mail plutôt que toute la banque d’information.
Au moment où le snapshot est créé, le fichier web.vmdk se fige et passe en mode lecture seule. Plus aucune donnée n’est écrite dans ce fichier original. Toutes les modifications seront inscrites dans le nouveau fichier créé qui se nommera xxx0001-delta.vmdk.
Ce fichier ne représente donc que les différences entre l’instant où a été réalisé le snapshot et les modifications réalisées depuis le snapshot. Il est important de garantir un état application consistant avant de faire le snapshot.

c. Précautions à prendre avec les snapshots

Il n’est pas conseillé de garder un snapshot VMware trop longtemps car plus les données sont modifiées, plus le snapshot grossit.
Dans un environnement de production, les snapshots doivent être utilisés pendant un laps de temps défini pour réaliser une mise en observation et revenir en arrière dans le cas où cela ne fonctionne pas. La durée conseillée d’un snapshot ne doit pas excéder 1 ou 2 jours.
Un snapshot pouvant grossir sans limite, il peut ainsi occuper tout l’espace du datastore et mettre en péril l’ensemble des VM (plantage, corruption…).
Les abaques actuelles donnent un taux moyen de modification d’un snapshot de 20 % de la volumétrie totale de la VM par tranches de 24 H.
Rappel : les snapshots VMware ne fonctionnent pas avec des disques de type Rdmp.
Une mauvaise manipulation des snapshots peut rendre la VM inutilisable. Il est donc important de prendre en considération les points suivants :
  • Un Reverse Snapshot est destructif, toutes les modifications ainsi que les fichiers xxxdelta.vmdk sont définitivement détruits.
  • Ne jamais supprimer manuellement les fichiers xxxdelta.vmdk dans le répertoire de la VM. Il faut utiliser Snapshot Manager dans vCenter pour faire les opérations.
Il est important de bien comprendre la mécanique et l’utilisation des snapshots. Pour cela il est fortement conseillé de mettre en place une procédure et de s’y tenir. En cas de doute, faire des sauvegardes avant toute manipulation.

images_ch5fig20

Cette fonction, uniquement pour les VM avec un virtual hardware version 7 ou 8, liste les changements de blocs réalisés (depuis la dernière sauvegarde) dans un fichier -ctk.vmdk dans le répertoire de chaque VM pour chacun des virtual disks sur lesquels CBT est activé (cela représente quelques dizaines de Mo). Les applications peuvent faire une requête au VMkernel afin que celui-ci retourne les blocs d’un disque virtuel qui ont été changés depuis la dernière sauvegarde.

images_ch5fig30

Cette fonction est disponible en vmdk et rdmv (pas disponible en rdmp).
CBT existe pour les disques en mode type thin et thick sur tous les datastores NFS, VMFS.
Cela ne fonctionne pas si le virtual disk est attaché à un shared virtual SCSI bus et avec des VM avec des snapshots.
L’activation du Changed Block Tracking (ctkEnabled) se réalise dans les paramètres avancés de la VM (version 7 ou 8 au niveau de la version du virtual hardware).
L’activation prend effet après la réalisation d’un cycle stun-unstun sur la VM. Un cycle stun-unstun est défini par VMware lorsqu’une des actions suivantes est réalisée :
  • Power on
  • Resume après suspend
  • Migrate
  • Création Suppression ou revert d’un Snapshot.
À noter que CBT est issue de la technologie Storage vMotion sous vSphere 4 (appelé DBT Dirty Block Tracking qui utilise cette méthode pour déterminer rapidement quels sont les blocs modifiés à transférer).

2. La déduplication

Il faut utiliser des technologies adaptées comme la compression et la déduplication afin de réduire l’espace de stockage.
La déduplication ne copie qu’une seule fois les fichiers (ou blocs) identiques qui se trouvent sur le disque en réduisant considérablement l’espace de stockage nécessaire. Cette technologie fiabilise les sauvegardes et permet de répliquer les sauvegardes avec une faible utilisation du WAN.
La déduplication est certainement la technologie la plus efficace pour lutter contre le gaspillage. Exemple : lors d’un envoi d’un e-mail composé d’une pièce jointe de 3 Mo à 100 personnes, cela représente un espace consommé de 300 Mo. Avec la déduplication l’espace de stockage consommé ne représente que 3 Mo.
Pourquoi la déduplication est-elle bien adaptée aux environnements virtuels ?
Les VM étant souvent créées à partir d’un Template, il est probable qu’un nombre important de blocs sur le disque soient identiques. La déduplication permet de réduire considérablement l’espace de stockage en supprimant les données redondantes.
Plusieurs possibilités sont envisageables : la déduplication à la source est réalisée au début du processus de sauvegarde avant que les données ne soient envoyées sur la solution de sauvegarde. Ainsi, la bande passante réseau est préservée ce qui peut être très intéressant dans certains environnements mais il faut veiller à ne pas consommer trop de ressources du serveur hôte.
Voici quelques produits du marché proposant cette technologie : EMC Avamar, Symantec Puredisk, Atempo Hyperstream, Commvault…
La déduplication sur la cible intervient au niveau de la solution de sauvegarde ce qui préserve le serveur source d’une charge de travail supplémentaire mais ne réduit pas les besoins en bande passante réseau.
Il faut donc adapter la technologie à utiliser en fonction de ses propres contraintes.
En méthode traditionnelle avec une sauvegarde Full et Incremental, le déplacement de données est de l’ordre de 150 à 200 %/semaine.
L’efficacité en environnement virtuel est impressionnante puis qu’avec la déduplication, le déplacement de données ne représente plus seulement qu’entre 2 et 7 % des données.
Attention les technologies employées par les différentes solutions du marché sont différentes : il faut bien distinguer la déduplication réalisée lors des jobs de sauvegarde (lors d’une sauvegarde on ne renvoie que les blocs qui ne sont pas identiques) d’une déduplication qui ne se fait qu’au sein d’une VM. Il faut bien se renseigner sur ce point auprès de l’éditeur.

3. LAN free

Sur les machines physiques, les sauvegardes passent la majorité du temps par les cartes réseau. La quantité de données étant toujours plus importante, les fenêtres de sauvegarde explosent alors que la production nécessite de plus en plus de disponibilité.
La virtualisation permet de sauvegarder à travers les liens SAN sans passer par le réseau (LAN Free backup) et ainsi de bénéficier des performances du stockage et de son réseau pour diminuer la durée des sauvegardes.
Un autre avantage de sauvegarder à travers le réseau de stockage est de ne pas impacter l’utilisation processeur de cette machine comme le fait une sauvegarde avec agent dans une machine physique. Ceci lui permet de fournir même pendant les sauvegardes une puissance CPU dédiée à l’application hébergée.
Il existe des proxys NDMP permettant de décharger l’activité de déduplication au niveau d’un serveur dédié.

 

About sebihiy

Check Also

cert

VMware Certification

VMware certification établit la norme pour les professionnels de l’IT et valide les organisations de ...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>