Niveau : débutant

Bien que je sois un fervent défenseur du FOSS (Free & Open-Source Software), s'il y a bien un logiciel propriétaire dont je ne peux actuellement pas me passer en entreprise, c'est Vmware ESXi / vSphere.
C'est pour moi une suite de logiciels qui n'a pas d'équivalent dans le monde de l'open source.
Bien-sûr, nous avons le couple KVM / OpenStack, mais je pense qu'ils n'ont pas les mêmes objectifs, pas plus qu'ils ne s'adressent au même public.

J'ai donc un host ESXi dans mon lab, avec une douzaine de machines virtuelles qui tournent dessus.
Même si elles ne sont pas en production, je voudrais pouvoir sauvegarder les VMs. Gratuitement, parce que mon budget lab est très limité !
Pour cela, j'utilise l'excellent script ghettoVCB, de William Lam (virtuallyGhetto)
J'explique dans cet article quels sont les prérequis de ce script, comment l'intégrer sur un hôte ESXi, et comment l'utiliser.

Nous avons vu dans l'article précédent comment marchaient les snapshots VMware ESXi, et quelles en étaient les best practices
Best practices pour les snapshots VMware ESXi

Bien que vSphere soit un outil formidable, qui permette de rapidement mettre en place dans l'entreprise des hyperviseurs, des machines virtuelles hautement disponibles, qui se déplacent dans l'infrastructure au gré des ressources disponibles, il a aussi un gros défaut, inhérent à sa nature propriétaire : il est pensé comme une "appliance", et il est très difficile d'y intégrer des outils maison.
Afin de préserver la stabilité de la plateforme et de limiter les demandes "exotiques" au niveau de son support, la société VMware a mis en place tout un écosystème de revendeurs, d'experts, et de solutions tierces, agrées.
C'est aussi un business model cohérent (très fructueux ?! ;-)
Mais toute infrastructure qui ne respecte pas les cas d'école ou les Best Practices est considérée comme non conforme.
Ce qui a un impact sur l'administrateur qui souhaite débuter en mettant en place un lab ou une petite infrastructure virtualisée dans son entreprise, tout en sachant qu'il n'est pas expert, et que ses moyens sont limités.
Il a l'impression de se heurter à un mur, tant du point de vue financier que de la complexité et la taille de l'infrastructure à mettre en place.
Là-dessus, VMware se montre assez "autiste", alors que je considère qu'il faut au contraire savoir commencer petit, par un lab, des maquettes, de la pré-production, pour pouvoir ensuite grandir.

Il n'y a donc pas d'outil de sauvegarde livré avec les hyperviseurs ESXi, et l'intégration même d'outils gratuits, non agrées, tels que le script ghettoVCB peut se révéler délicate ...

Prérequis

- ESXi 3.5, 4.x & 5.x
- Accès Shell activé
- Résolution DNS activée et configurée, si vous souhaitez recevoir les mails d'alerte du script
- Licence minimale "Essentials" (environ 500€), ou supérieure  : l'accès à l'API vShere doit être possible, pour les snapshots : vous trouverez le détail de votre licence dans la configuration de votre ESXi, fonctions autorisées
- Les disques VMs à sauvegarder ne doivent pas être indépendants (persistants), puisque cela est naturellement incompatible avec les snapshots
- Les VMs ne doivent pas déjà contenir des snapshots au moment de la sauvegarde (ils n'ont pas vocation à être permanents, voir l'article sur les Best Practices !)

Limitations

Il existe des variantes du script qui permettraient de faire les sauvegardes le contexte de la haute disponibilité, mais je ne les ai jamais essayé en production, avec des machines qui se baladent en permanence entre les hyperviseurs, en fonction des ressources disponibles.

De plus, le script ne permet pas de sauvegarder la configuration des hyperviseurs eux-mêmes, et lorsque nous avons les moyens de mettre en place une vraie infrastructure hautement disponible, il faut avoir un outil plus complet pour pouvoir reconfigurer un cluster dans des délais raisonnables.
Par exemple, dans le cas d'un PRA (Plan de Reprise d'Activité).

Je conseille donc de limiter son emploi au cadre d'un lab, ou encore d'une petite infrastructure de production, dans laquelle les hosts fonctionnent indépendamment les uns des autres.

Activer SSH

Pour activer le shell, il faut se rendre dans la configuration de l'hyperviseur, via le client graphique, et entrer dans le profil de sécurité :

Accéder aux propriétés de la section Services, et pour l'item SSH, sélectionner la règle démarrer et arrêter avec l'hôte.
Démarrer cette fois-ci le service, si ce n'est déjà fait.

Dans les propriétés du parefeu, vérifier que le serveur SSH (TCP 22) est accessible à toutes les IPs ou au sous-réseau de votre choix.

Vous pouvez alors vous connecter avec l'utilisateur root sur le service SSH de l'hôte.

Pourquoi faire simple, alors que l'on peut faire compliqué ?!

Il faut maintenant comprendre une chose :
le système que vous avez sous vos yeux, y compris le répertoire /etc, ne sont pas persistants, permanents, dans les versions 4.X et 5.X d'ESXi.
A chaque démarrage de la machine, les fichiers sont intégralement recrées : la partition racine réside en mémoire vive !
Pour des raisons de sécurité, de performance, ou tout simplement pour décourager le bricoleur ?

Nous ne pouvons donc pas :
- y stocker de nouveaux fichiers
- modifier la configuration via la ligne de commande
- planifier de nouveaux jobs
- ne serait-ce qu'ajouter des règles firewall personnalisées !

Bien-sûr, il y a une façon, un peu tordue, pour contourner ces limitations ...

Lorsqu'on regarde dans le fichier /var/spool/cron/crontabs/root, nous nous apercevons de la présence d'un fichier /sbin/auto-backup.sh
# cat /var/spool/cron/crontabs/root
#min hour day mon dow command
1    1    *   *   *   /sbin/tmpwatch.py
1    *    *   *   *   /sbin/auto-backup.sh
0    *    *   *   *   /usr/lib/vmware/vmksummary/log-heartbeat.py
*/5  *    *   *   *   /sbin/hostd-probe

Lorsque l'auto-backup est exécuté, automatiquement ou manuellement, les fichiers "de référence" sont sauvegardés.
C'est le cas pour le fichier qui va nous intéresser, à savoir /etc/rc.local.d/local.sh (les commandes lancées au démarrage du host)

Il va donc falloir nous plier à une gymnastique bien particulière : d'abord déployer les fichiers dont nous avons besoin à partir d'un volume VMFS local ou NFS, au démarrage de la machine, et ensuite planifier l’exécution automatique des tâches, le tout en nous servant du fichier /etc/rc.local.d/local.sh comme point d'entrée.

Une autre façon, plus propre, mais plus compliquée, est d'utiliser VIB Author.
Le programme permet de construire des paquets VIB (vSphere Installation Bundle).
VMware fournit un paquet RPM qui permet de l'installer, mais je n'ai que des Debian / Ubuntu à ma disposition.
Je considère qu'avoir un paquet VIB est important lorsqu'on a beaucoup de serveurs à gérer, que ça permet de gérer le déploiement, le versionning facilement.
Mais que pour un ou deux serveurs, c'est une méthode juste ... "overkill",  et totalement inefficace d'un point de vue gestion du temps.

Pour ceux qui souhaitent essayer la méthode VIB Author, voici un très bon article :
Creating Custom VIBs For ESXi 5.0 & 5.1 with VIB Author Fling

Ajout de règles firewall "e-mail sortant" (optionnel)

Nous allons créer une règle personnalisée, smtp sortant, et la placer dans un fichier email.xml :

<ConfigRoot>
  <service>
    <id>email</id>
    <rule id="0000">
      <direction>outbound</direction>
      <protocol>tcp</protocol>
      <porttype>dst</porttype>
      <port>25</port>
    </rule>
    <enabled>true</enabled>
    <required>false</required>
  </service>
</ConfigRoot>

Idéalement, il faudrait la placer dans le répertoire /etc/vmware/firewall/, mais l'emplacement n'est pas sauvegardé.
Nous allons donc la placer sur un datastore local, persistant, ici nommé datastore1.
Le chemin exact sera : /vmfs/volumes/datastore1/local/email.xml

Nous demandons sa copie au démarrage vers le bon emplacement, et sa prise en compte par le firewall, en éditant le fichier /etc/rc.local.d/local.sh :
cp /vmfs/volumes/datastore1/local/email.xml /etc/vmware/firewall/email.xml
esxcli network firewall refresh

Exécuter ces lignes cette fois-ci.
Pour sauvegarder les nouveaux réglages, exécuter /sbin/auto-backup.sh

Vérifier que les règles ont bien été prises en compte :
esxcli network firewall ruleset list

Le script GhettoVCB

Vous pourrez télécharger la dernière version sur GitHub :
https://github.com/lamw/ghettoVCB

Nous pouvons placer le script ghettoVCB.sh et le fichier de configuration ghettoVCB.conf dans le répertoire /vmfs/volumes/datastore1/local/
Il faut donner les droits d'exécution au script :
chmod 700 /vmfs/volumes/datastore1/local/ghettoVCB.sh

A noter qu'il est nécessaire d'indiquer explicitement le ficher de configuration, lors de l'exécution.
Sinon, le script utilisera les valeurs par défaut, sans parcourir le fichier de configuration (ce n'est pas évident sur la documentation officielle ...)

Vous trouverez les options expliquées en détail sur le site officiel.
Pour ma part, je détaillerai juste les options que j'estime utiles, et surtout pourquoi.

ghettoVCB.sh - Free alternative for backing up VM's for ESX(i) 3.5, 4.x & 5.x

Le fichier de configuration

Voici mon fichier de configuration à moi :

VM_BACKUP_VOLUME=/vmfs/volumes/ghetto/esxi
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP=0
ENABLE_NON_PERSISTENT_NFS=1
UNMOUNT_NFS=1
NFS_SERVER=192.168.0.3
NFS_VERSION=nfs
NFS_MOUNT=/mydata/backups
NFS_LOCAL_NAME=ghetto
NFS_VM_BACKUP_DIR=esxi
SNAPSHOT_TIMEOUT=15
EMAIL_LOG=1
EMAIL_SERVER=relay.xxxxxxxx.fr
EMAIL_SERVER_PORT=25
EMAIL_DELAY_INTERVAL=1
EMAIL_TO=Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
EMAIL_FROM=monitoring@xxxxxxxx.fr
WORKDIR_DEBUG=0
VM_SHUTDOWN_ORDER=
VM_STARTUP_ORDER=

J'utilise le serveur NFS 192.168.0.3, les backups seront placés dans le répertoire local /mydata/backups/esxi/, concaténation de : NFS_MOUNT/NFS_VM_BACKUP_DIR
J'utilise un montage NFS non persistant, qui sera monté au début de la sauvegarde, et démonté lorsqu'elle sera terminée.
Par prudence (ou paranoïa ;-) : autant j'ai d'autres montages NFS permanents, dont je me sers pour stocker les machines, autant je considère que les sauvegardes ne doivent jamais être accessibles en permanence.
Qu'il peut y avoir une mauvaise manipulation ou un acte malfaisant, et qu'il faut isoler la sauvegarde pour ne pas tout perdre en même temps.

DISK_BACKUP_FORMAT
Je décide d'utiliser le format "thin". A vrai dire, je n'ai remarqué aucune différence de taille dans les backups, mais c'est le format par défaut.

VM_BACKUP_ROTATION_COUNT
Je décide de stocker trois sauvegardes pour chaque VM, parce que j'ai de la place sur mon filer, et parce que je peux m’apercevoir d'un problème bien après qu'il soit survenu.
Je voudrais donc avoir trois points de sauvegarde.

A noter qu'il est obligatoire d'utiliser un point de montage local, et l'emplacement (local) de la sauvegarde sera la concaténation suivante : /vmfs/volumes/NFS_LOCAL_NAME/NFS_VM_BACKUP_DIR
NFS_LOCAL_NAME correspond au nom du datastore temporaire qui sera utilisé pour le montage NFS.
Il faut donc bien faire attention à ce qu'il soit unique.

J'ai activé l'envoi d'e-mails de rapport, grâce à la variable EMAIL_LOG

Vous pouvez donc enfin lancer la sauvegarde grâce à la commande :
/vmfs/volumes/datastore1/local/ghettoVCB.sh -a -g /vmfs/volumes/datastore1/local/ghettoVCB.conf

L'option -a permet de sauvegarder toutes les machines virtuelles sur l'hyperviseur.
L'option -g permet d'indiquer le chemin du fichier de configuration (sinon seules les valeurs par défaut seront utilisées)

Si le script ne s'exécute pas correctement, il faut revérifier les prérequis.
Pour rappel, l'API vSphere doit être autorisée par la licence, les disques persistants ne seront pas sauvegardés, car incompatibles avec les snapshots, et il ne doit pas y avoir de snapshot présent au moment de la sauvegarde.

Planification de la sauvegarde

Maintenant que la sauvegarde est bien configurée et fonctionnelle, il faut planifier son exécution automatique.
Puisque la partition racine d'ESXi est effacée à chaque reboot, il faut faire en sorte que le cron soit reconstruit à chaque démarrage.

Pour cela, il faut arrêter le service crond, mettre en écriture le fichier /var/spool/cron/crontabs/root, le modifier, le remettre en lecture seule, et redémarrer crond.

Pour cela, éditons le fichier /etc/rc.local.d/local.sh, et ajoutons les lignes suivantes :
/bin/kill $(cat /var/run/crond.pid)
chmod +w /var/spool/cron/crontabs/root
/bin/echo "0 2 * * 2,5 /vmfs/volumes/datastore1/local/ghettoVCB.sh -a -g /vmfs/volumes/datastore1/local/ghettoVCB.conf" >> /var/spool/cron/crontabs/root
chmod -w /var/spool/cron/crontabs/root
crond

Dans mon cas, j'ai planifié l'exécution automatique à 2h du matin, tous les mardi et vendredi

Exécuter ces lignes cette fois-ci.
Pour sauvegarder les nouveaux réglages, exécuter de nouveau /sbin/auto-backup.sh

Conclusion

Autant VMware ESXi est un logiciel extraordinaire, autant la mise en place de customisations entre les versions 3.5 et l'actuelle, la 5.1, s'est terriblement compliquée ...
Toutefois, nous avons maintenant des hyperviseurs ESXi sauvegardés d'une façon tout à fait satisfaisante.
En cas de problème, il suffit pour la restauration, d'uploader les images vmdk obtenues dans le datastore qui correspond, ou d'utiliser le script ghettoVCB-restore.sh, sur lequel je ne m'attarderai pas.

Partager l'article

• Précédent
• Suivant