Cet article cherche à répondre à une question qui m’a été adressée sur ce site sur une solution de backup d’ESX sur un serveur SYS. Malheureusement, après 4 ans d’hébergement gracieux en datacenter, j’ai dû récemment rendre l’espace et de-commissionner mon ESXi 4.1. Je n’ai donc pas les moyens, contrairement aux autres articles, de monter rapidement et à peu de frais une infrastructure de test et il s’agit plus d’une présentation de quelques idées pour améliorer le backup d’un ESX en standalone.

Dans un Environnement Professionnel

Ici, il s’agit d’une présentation de mon expérience professionnelle et je suis loin d’avoir vu tous les environnement possibles. Mais en général, on ne fait pas de backup des VMs ! Absurde !? Pas vraiment, les VMs tournent sur des batteries de serveurs-lames (exemple de solution HP), les datastores sont supportés par des filers (netapp, EMC, etc.), et toute les données spécifiques sont hébergées sur d’autres points de montage filer, que ce soit

• les contenus statiques, vidéos etc.
• web apps
• les fichiers de config
• bases de données (quoique généralement les BDD ne sont pas virtualisées)
• les logs

En gros, les VMs fonctionnent comme des drones décérébrés, elles contiennent des serveurs applicatifs bruts (apache, tomcat, jboss, etc.) et rien d’autre. Pour redéployer les VMs, on les clone, on dispose de templates ou de script d’installation mais entre deux paliers applicatifs, elles restent identiques à l’adresse IP près.
Bilan, je ne suis pas sûr que les systèmes au niveau ESX soient bien pensés pour réaliser des backups de VM. Normalement, les filers sont des systèmes robustes avec de nombreux mécanismes pour éviter la perte de données, on risque donc plutôt de faire face à :

• des problèmes de corruptions de données (les BDD sont « dumpées » et copiées dans tous les sens)
• perte d’un équipement (tout le matériel est redondé, les configs sont copiées automatiquement)
• un feu dans le datacenter. Et là on parle de « Disaster Recovery » avec PRA ou multi-site

Bien sûr, cela ne représente que les environnements dans lesquels j’ai travaillé et je ne doute pas qu’il existe de nombreux type de configurations/besoins mais quand je farfouille sur les détails de la sécurisation de cloud d’OVH :

Qu’il s’agisse de serveurs virtuels (instances), de stockage ou d’archivage, le Cloud doit inspirer confiance et apporter toutes les garanties pour jouer pleinement son rôle d’alternative fiable à vos propres infrastructures.
Toutes nos ressources sont ainsi garanties avec 99,99% de disponibilité.
Pour l’archivage et le stockage, on y ajoute une fiabilité (durabilité) de 99,999999999% sur les fichiers déposés

Observez comment les serveurs virtuels ne sont pas repris dans le critère de durabilité. Comprenez, en cas de pertes d’un Datacenter, vos instances seront disponibles, mais dans quel état, nul ne le sait…

Les Solutions VMware

VMware propose un ensemble de solutions de backup des serveurs virtuels:

• vSphere Data Protection avec la version Advanced
• vSphere Replication sur lequel se base Site Recovery Manager
• et la solution non-officielle du pauvre ghettovcb

Toutes ces solutions se basent sur la même idée, on réalise un snapshot de la VM, on backup le snapshot et on l’efface après. Pour simplifier, Data Protection décharge cette activité sur une VM dédiée, gère la déduplication (on ne sauvegarde que le delta entre deux backup) et permet de récupérer les fichiers individuellement à l’intérieur des backups. La version Advanced permet en plus, à l’aide d’agent dans les VMs, de sauvegarder les BDD Microsoft Exchange, SQL Server. vSphere Relication synchronise les disques des VMs (!= snapshot) en transférant les deltas d’un site à l’autre.

Face à cela, ghettovcb est vraiment la solution basique mais est gratuite et ne nécessite pas vSphere.

Peut-on vraiment faire mieux ?

Sauf à aller installer des agents ou mettre en place des scripts dans ses VMs qui vont sauvegarder de manière ciblée les données, la réponse est non. On a besoin de sauvegarder les fichiers vmdk, voyez ça comme l’équivalent virtuel de réaliser une copie du disque dur de son serveur physique. VMware essaye de proposer des optimisations à l’aide de déduplications et en ne transférant que les deltas d’un backup à l’autre… Mais pas de miracle.

Et il s’agit d’une solution brutale qui ne vient pas sans inconvénients. Le plus évident est qu’il s’agit de snapshots réalisés à chaud et les données sont dans un état… Soyons clair, n’importe quel crado-snapshot d’un serveur nginx configuré en reverse proxy fera l’affaire, mais s’il s’agit d’une base de données (BDD), là je n’y mettrais surtout pas ma main à couper. Et ce n’est probablement pas un hasard si Data Protection Advanced vient avec des agents embarqués dans les VMs qui réalisent ces backups de BDD. Quant au vSphere Replication, il ne transfère même pas un état de la mémoire (page 5 du pdf) contrairement au snapshot.

Tout cela pour expliquer pourquoi OVH (mais pas qu’eux) ne s’engage que sur la disponibilité des instances virtuelles. Elles redémarreront, certes, mais rien ne dit qu’elles fonctionneront. Et au passage, j’en profite pour rappeler que toutes les fonctions avancées de VMware (vMotion, HA, vCloud Director, etc.) sont géniales, mais mal maîtrisées, elles mèneront au désastre.

Pour Répondre à la Question Initiale

« Ghettovcb, c’est galère pour les backups sur Kimsufi ».
Effectivement, le premier problème est le temps de transfert vers un KS limité à ~11 Mo/s, de plus ghettovcb sauvegarde sur les datastores de l’ESX ce qui limite à du NFS, iSCSI ou FC SAN.

Utiliser l’espace de backup qui vient avec SYS
C’est la première idée qui me vient en tête. Il est de base à 100Go, mais passer à 500 Go ne coûte que 10€ HT/mois ce qui correspond au prix d’un vieux KS. Il autorise aussi le protocole NFS (en bêta) que je n’ai pas encore testé, mais je constate régulièrement des débits en FTP de ~60 à 80Mo/s en DL et ~25 Mo/s en UL.
On a donc des transferts 5x plus rapides et automatisés. Le transfert d’un backup d’un Windows de 40Go devrait donc se faire en moins de 15 min. Celui d’un serveur debian de 5Go en moins de 2 min. Cela me parait correct.

Utiliser l’espace de backup comme un datastore NFS pour héberger les VMs
Ça c’est tentant. On a les performance d’un disque sata moyen. Pour un serveur web ou reverse proxy avec un peu de cache/mémoire, cela devrait largement suffire. Pour une BDD, cela pourrait être juste, mais en même temps, vu les problèmes de corruption …
une bonne idée pourrait être de jouer avec des VMs « hybrides ». Par exemple:

• Serveur web: la VM est sur le datastore local pour l’OS avec un 2ème disque vmdk sur le datastore NFS pour les données. Backup mensuel du vmdk local.
• BDD : la VM sur le datastore local pour les performances et un disque dans le datastore NFS pour les dumps. Backup quotidien du vmdk local si la BDD est critique

Ghettovcb est assez souple pour permettre des exécutions dans le crontab avec différents fichiers de config et des politiques par VM.

• Le backup mensuel en utilisant le datastore sur le KS pour les VMs non critiques
• Le backup quotidien avec le fichier de config utilisant le datastore NFS (sur le backup SYS) pour les VMs critiques
• On défini par VM les vmdk a sauvegarder, cela ne sert à rien de sauvegarder les VMDK de données dans mon exemple

Pour dormir tranquille, cela me parait toujours une bonne idée de continuer à passer des scripts de backup par VM. Cela ne coûte pas grand chose, et si on se loupe avec ghettovcb…

Une dernière chose, par défaut, ghettovcb utilise les paramètres suivants:

VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0

Plus d’information sont disponibles sur ce lien, mais dans tout les cas, éteindre une VM avant d’en réaliser un snapshot (POWER_VM_DOWN_BEFORE_BACKUP=0) est la garantie d’un backup parfait. Ce n’est pas une solution absurde pour un Desktop virtuel.

Pour Conclure

Voilà, je n’ai pas vraiment de meilleure option gratuite. En fait, je soupçonne VMware de mettre gratuitement à disposition ESXi pour populariser ses outils et convaincre les départements de r&d et ingénierie des entreprises de faire la conversion. A part ça, ESXi en standalone n’est pas vraiment adapté à un environnement de production mais plutôt de tests/bidouille. Bien sûr Ce n’est que mon avis 🙂

Néanmoins, il est tout a fait possible, même si je n’ai pas testé, d’obtenir des résultats satisfaisants d’un point de vue backup pour peu que l’on ait un minimum d’infrastructure derrière (espace de backup de SYS). Dans tous les cas, et j’y est passé du temps, il est vraiment important de comprendre les mécanismes de base de VMware/ESX avant d’utiliser ces outils et de tester les backups sous peine d’être déçu du résultat.