Depuis le rachat de VMware par Broadcom, les DSI font face à des augmentations de prix considérables, les incitant à faire évoluer leur infrastructure IT (SI, métier) vers des solutions plus vertueuses.
Du côté des hyperviseurs, la solution open source Proxmox VE fait partie des alternatives à VMware possédant le plus le vent en poupe. Face à cette montée en puissance, les éditeurs de solutions logicielles connexes à la virtualisation commencent donc logiquement à intégrer le support de Proxmox VE dans leurs offres. C’est notamment le cas de Veeam, acteur majeur sur les solutions de sauvegarde et historiquement beaucoup utilisé avec VMware. Proxmox VE est ainsi supporté depuis la version 12.2 (Août 2024) de sa Veeam Data Platform.
Nous saluons l’effort de Veeam de s’ouvrir à l’open source et nous avons souhaité tester leur solution sur un cluster Proxmox VE. Dans cet article, nous vous partageons notre retour d’expérience en termes d’installation et d’utilisation, avec un focus sur les fonctionnalités de sauvegarde et de restauration les plus importantes.
Dépendances et prérequis pour l’utilisation de Veeam avec Proxmox VE
Dépendances
A partir de la version 12.2 de Veeam Data Platform, le support de Proxmox VE est intégré de base, aucun plugin ni option ne sont nécessaires pour en bénéficier.
Les dépendances pour mettre en place le backup de clusters Proxmox VE sur Veeam sont similaires à celles pour les autres solutions de virtualisation.
Si vous possédez déjà un déploiement Veeam fonctionnel, votre nouvelle plateforme Proxmox VE s’intégrera parfaitement dans votre infrastructure actuelle. Si vous souhaitez mettre en place une nouvelle solution, nous vous donnons des éléments ci-dessous mais vous pouvez vous reporter à la documentation d’installation déjà disponible pour VMware.
Prérequis
La documentation Proxmox VE n’est pas encore complète et ne contient pas le chapitre concernant les prérequis et l’architecture physique à mettre en place. De notre côté chez Enix, voici ce que nous avons mis en place pour nos tests :
- VM sur Proxmox (Proxmoxception 😀) avec :
- 6 vCPU en mode host afin de profiter de la totale performance de la machine (Xeon E5-2680 v4)
- 12 GB de RAM
- un disque de boot pour l’OS et le cache de Veeam de 256GB en SSD
- 2 disques SAS de 8TB 7200rpm dédiés en mode Virtio-blk passthru pour le BackupRepository Veeam
- Windows Server 2022
- Veeam Backup and Replication version 12.2
D’après nos tests, nous considérons qu’il s’agit de la configuration minimale à mettre en place sur Veeam pour une plateforme de backup stable et performante. Dans la vraie vie, ceci dépendra bien entendu de la quantité de datas que vous souhaitez sauvegarder, du nombre de nœuds, etc…
Par ailleurs, si vous avez une solution de backup centralisée avec plusieurs usages dédiés à Veeam vous pouvez tout à fait mettre en place des machines Backup Proxy, des Datastore indépendants et tout ce que propose Veeam, le plugin Proxmox VE s’intégrera avec tout cela.
Architecture globale de la solution Veeam Data Platform pour Proxmox VE
La documentation officielle de Veeam pour Proxmox VE présente de façon claire l’architecture et les interactions entre les différents composants. Pour ceux qui n’ont cependant pas envie de tout lire ou les allergiques à l’anglais, nous allons condenser les informations importantes en guise de quick start.
La première chose à prendre en compte est l’architecture réseau. Nous n’allons parler que du cas le plus simple (si vous voulez faire une architecture compliquée vous devrez lire la documentation de toute façon 🙂) qui concerne notre setup de test avec une seule instance de serveur de backup Veeam autonome.
Ce schéma (extrait de la documentation) nous permet de comprendre rapidement le fonctionnement global du système, tout à fait classique pour une solution de backup :
- Via le plugin Proxmox VE, le serveur de backup communique directement avec les nodes d’un cluster pour connaître ses ressources (VMs, disques, network) et éventuellement créer des VMs.
- Via le plugin, il synchronise les tâches de backup ou restore avec un worker qui s’occupe de faire le travail, ceci permet d’offloader la charge des tâches de backups en dehors du serveur Veeam et de “scaler” la solution automatiquement avec les plateformes connectées au service.
- Le worker est quant à lui au cœur du système, il communique avec le serveur Proxmox VE pour démarrer les tâches de backup et accéder aux ressources des VMs en direct, et il envoie ceci au Backup Repository via le Data Mover.
C’est un bon schéma de principe mais quels sont plus précisément ces composants et comment cela se traduit pour notre infrastructure ? Commençons par la partie simple, tout ce qui est à droite dans le schéma est complètement géré par Veeam, dans notre cas ces composants sont installés sur notre serveur de backup windows.
Quant au mystérieux worker, qui est-ce ? Comment est-il déployé ?
Et bien le worker Veeam est une VM qui tourne à l’intérieur du cluster Proxmox VE que l’on souhaite sauvegarder. C’est une solution élégante qui permet d’avoir un composant entièrement personnalisable et contrôlé par Veeam sans avoir à toucher à l’installation des nodes Proxmox VE.
Dans une solution classique, il faudrait déployer du logiciel externe et le maintenir directement sur l’installation de l’OS du node. Cela peut être compliqué à gérer sur le long terme, aussi bien du côté Veeam pour s’adapter aux évolutions rapides de la base logicielle Proxmox VE, que du côté des utilisateurs pour s’assurer d’avoir un worker à jour et compatible avec notre version de l’hyperviseur. D’autant que les utilisateurs de proxmox sont attachés au modèle open source et un grand nombre d’entre eux pourraient ne pas forcément apprécier d’avoir des logiciels propriétaires externes installés sur leurs base d’OS.
Un point important à noter cependant : toute VM nécessite des ressources dédiées sur l’hyperviseur, à l’inverse d’un agent logiciel qui tournerait sur l’OS. Ceci doit être pris en compte lors du dimensionnement des ressources de la solution de Backup.
Configuration d’un cluster Proxmox VE dans Veeam Manager
Afin de profiter de la solution, il faut bien évidemment commencer par connecter notre cluster Proxmox VE à Veeam. La documentation étant bien faite sur ce point nous n’allons pas fournir de procédure mais attirer votre attention sur les points importants qui ne sont pas forcément explicites dans la documentation :
- Le communication entre Veeam et Proxmox VE se base à la fois sur l’API et des connections SSH, il est donc nécessaire d’utiliser un utilisateur realm @pam de proxmox qui possède les droits root sur l’OS et Administrator dans l’API proxmox. Pour nos tests nous avons utilisé root@pam mais sur un système en production faites bien attention : il n’y a pas de support des clefs SSH, il est donc nécessaire de donner au manager le mot de passe de cet utilisateur qu’il doit conserver ;
- Si vous possédez un cluster Proxmox VE et non un node isolé, ce qui est le cas le plus courant normalement, il est nécessaire d’ajouter un par un tous les nodes du cluster dans l’interface de gestion de Veeam Backup. Si vous avez un cluster de 3 nodes ce n’est pas trop un problème, mais si vous en avez 50 et qu’ils sont régulièrement remplacés il faut prendre en compte ce point ;
- Chaque nœud Proxmox VE nécessite un espace de stockage configuré afin d’accueillir les snapshots des VMs à sauvegarder si le stockage sur lequel elles sont ne le supporte pas. C’est le cas de LVM en mode non thin par ex. Dans ce cas, il faut un stockage (local de préférence) suffisamment performant et dimensionné en taille pour supporter cette charge.
Comme vu précédemment, la solution nécessite la mise en place d’un “worker” Veeam qui est une VM déployée dans le cluster proxmox VE. Ce worker fait l’interface entre le Backup Server, le Backup Repository et le cluster Proxmox VE lui-même.
Lorsque vous connectez un node Proxmox VE au backup manager il vous est automatiquement proposé l’ajout d’un worker sur ce node. Si vous avez raté l’information et donc pas déployé un worker à ce moment, il faut aller dans Backup infrastructure -> Backup proxies -> Add Proxmox VE worker pour lancer la procédure. Je vous donne le tips parce que j’ai cherché quelques minutes pour le trouver dans l’interface 🙂.
Les ressources nécessaires au déploiement du Worker VM pour 4 backup en parallèle sont les suivantes. A noter que l’outil adapte automatiquement les ressources de la VM en fonction du nombre de jobs autorisés :
- 6 CPU
- 6 GB RAM
- 100GB disk
La stack logicielle de Veeam est basée sur la distribution Rocky Linux, elle-même dérivée de Red Hat.
Avec cette configuration, chaque worker est capable d’effectuer 4 jobs de backup en parallèle. C’est la limite par défaut utilisée à la fois pour un worker sur un cluster PVE, et pour un job de backup. Il est tout à fait possible de modifier cette limite dans la configuration avancée d’un worker comme pour les jobs. Il faut cependant bien tenir compte des ressources nécessaires sur le serveur de backup et le repository afin de bien gérer les flux. Il faut donc les dimensionner en fonction de la taille de votre cluster, du nombre de VMs à sauvegarder et du temps que vous vous donnez pour effectuer ces derniers backups.
Pour vous faire gagner du temps, nous avons compilé les informations importantes et les incompatibilités que vous pouvez rencontrer lors de la configuration de ce worker :
- Open vSwitch n’est pas supporté pour la configuration de la VM Worker, seulement Simple bridge ou les nouveaux réseaux SDN sont disponibles lors de la configuration de la VM ;
- Si votre configuration réseau nécessite la configuration d’un tag vlan sur l’interface réseau de la VM, il faut le faire après la création de celle-ci par Veeam, comme si vous configuriez n’importe quelle autre VM du cluster. L’outil de Veeam ne le propose pas directement. Pensez cependant à **le faire rapidement pendant l’installation **sinon vous aurez une erreur à la fin vous indiquant que le manager ne peut pas communiquer avec le nouveau worker ;
- Le stockage que vous sélectionnez pour l’installation de la VM doit supporter les snapshots, sinon l’installation finira par échouer.
Pour les curieux, voici le processus technique de création de la VM worker par Veeam :
- Push d’une ISO PveWorker_1.0.0.439.img sur le premier stockage qui supporte les ISOs. Attention, cela ne sera pas forcément votre stockage préféré pour cela et ce n’est pas configurable ;
- Création d’une VM avec l’image ISO et un disque de 100GB sur le stockage précisé lors des étapes de configuration. Configuration des ressources CPU et RAM associés qui correspondent au nombre de threads de backup que vous avez configuré dans les options avancées ;
- Premier boot de la VM qui consiste à installer l’OS de base à partir de l’ISO CD sur le disque de la VM puis arrêt de celle-ci ;
- Création d’un “Snapshot” de la VM avant de procéder à sa configuration finale ;
- Reboot de la VM avec une configuration réseau injectée par cloud-init ;
- Installation des mises à jour de l’OS et des outils Veeam dans le worker lors de ce boot. A noter que ceci est effectué à chaque boot de la VM worker.
Dans l’idéal, il faut configurer un worker Veeam sur chaque node du cluster Proxmox VE afin que les backups soient exécutés en “local”. Si ce n’est pas le cas, Veeam remonte des messages de warning peu explicites évoquant le backup impossible en mode HotAdd et utilisation du mode “Network”. Pour comprendre la différence entre les différents types de modes (sachant que le plus performant proposé par Veeam, “Direct Storage Access”, n’est pas encore disponible pour Proxmox VE) je vous invite à consulter la documentation.
Cependant, lors des tests sur notre architecture simplifiée (qui ne passe que par des connections réseaux et des redirections SSH pour le trafic entre l’hyperviseur et le worker node) nous n’avons pas constaté de différence de performance visible sur les backups entres les 2 modes à condition que le réseau soit bien dimensionné. Ceci n’est cependant qu’une impression et pas du tout une mesure réelle, et il est préférable de suivre la recommandation.
Processus de sauvegarde Veeam pour Proxmox VE
Compliance et types de backups
Veeam supporte le backup de tous les disques configurés pour une VM, quel que soit le système de stockage en backend géré par proxmox (NFS, iSCSI, LVM, ZFS, …). Ceci est possible car le process de backup s’attache directement au processus linux qemu exécuté par l’hyperviseur.
Le mode de stockage du disque en backend est donc complètement abstrait pour le worker Veeam. C’est cela qui lui permet de streamer directement les données d’un disque pendant son utilisation et donc d’effectuer des backup “snapshot” qui sont fiables.
Il n’y a donc pas de différence dans les features des backups par rapport aux autres solutions et il est possible d’effectuer des full backups et des backups incrémentaux.
Les fonctionnalités de Changed Block Tracking de Veeam qui permettent d'éviter de relire toutes les datas d’un disque d’une VM lors d’un backup sont fonctionnelles sous Proxmox grâce à l’utilisation des Qemu Dirty Bitmaps. Cela utilise donc une solution native qui ne nécessite pas de configuration supplémentaire particulière.
Configuration des sauvegardes
Pour sauvegarder des VMs, il faut créer un job de backup et configurer la durée de rétention, le backup repository à utiliser, etc… tout ceci est complètement standard et ne nécessite pas d’explications particulières.
Cependant, il est important de comprendre le processus de sélection des VMs à backup par un job. Par défaut, il faut ajouter les VMs d’un cluster une par une au job de backup. Ceci est très contraignant, mais il est également possible de choisir toutes les VMs d’un cluster ou toutes les VMs d’un node hyperviseur. On peut aussi ajouter des règles d’exclusion pour certaines VMs.
Une chose manquante pour nous est l’impossibilité de sélectionner les VMs par Pool de ressources Proxmox VE. Dans notre cas d’usage, nous aimons bien créer des jobs de backup différents pour différentes plateformes qui sont organisés dans des Pools, ceci afin d’avoir des paramètres de backup différents (rétention, récurrence, etc…). Nous n’avons pas forcément les mêmes politiques de backup pour notre plateforme de production et celle de staging. C’est encore plus une nécessité dans le cas d’un cluster multi-tenant où chaque client peut avoir sa propre politique de backup ou son propre backup repository. Avec l’intégration actuelle de Veeam il est possible de créer 2 jobs de backup différents, mais il faudra sélectionner les VMs de chaque jobs à la main et bien gérer les modifications lors de l’ajout ou la suppression de VMs.
Un autre manque dans l’intégration avec Proxmox VE : pour gérer l’exclusion de certains disques d’une VM au backup, il faut passer par la configuration du backup job et ajouter des exclusions manuelles spécifiques. Il est dommage de ne pas utiliser les flags de configuration des disques backup=0 de Proxmox VE.
Quick backup manuel
Si comme moi vous aimez faire un backup rapide d’une VM avant d’effectuer une intervention particulièrement complexe sur l’infrastructure, il est pratique d’effectuer un backup instantané rapide. Je trouve ce processus dans Veeam loin d’être optimal. Il consiste à effectuer un backup VeeamZip. Cela est d’une part difficile à trouver dans l’interface mais en plus très long car la fonctionnalité n’utilise pas le système de backup classique de Veeam. Le backup de cette VM n’est pas lié à un job, il n’est pas stocké de la même manière dans le repository de backup et il n’utilise pas l’historique de backups précédent. Ensuite il génère une capsule de backup autonome ce qui s’avère très long pour une grosse VM. Cela revient à faire un ZIP de toutes les datas de la VM, alors que l’on aurait simplement préféré avoir un nouveau “snapshot” de cette VM pour effectuer une restauration rapide (“quick restore”) en cas de problème.
Processus de restauration Veeam pour Proxmox VE
Le processus de restore d’une VM est tout ce qu’il y a de plus simple et de plus classique. Son fonctionnement sous Proxmox VE est identique à celui pour les autres hyperviseurs supportés par Veeam Data Platform.
Lors d’une demande de restauration d’une VM, il est possible de choisir entre deux options :
- “Restore to Original location” : Dans ce cas, la VM avec la même ID actuellement sur le node Proxmox originel va être arrêtée, ses datas supprimées et recréée à partir des datas du backup. Ceci n’est pas du tout notre manière préférée d’effectuer une restauration car elle pourrait s’avérer bien pire que rien du tout en cas d’erreur de manipulation. Cette méthode écrase les données actuelles de votre VM originale et toute possibilité de retour en arrière est alors impossible.
- “Restore to New location, or with different settings” : Le choix à privilégier selon nous. Dans ce cas, on peut restaurer la VM en parallèle de l’originale afin de tester la sauvegarde et de vérifier que l’on restaure bien les bonnes datas avant de remettre la machine en production. Il faudra cependant faire attention à arrêter manuellement la machine d’origine pour éviter des conflits réseaux ou avec d’autres ressources. Un point à noter, comme pour la création de la VM worker, Veeam ne supporte pas les tags de VLAN pour la configuration réseau de la VM qui est restaurée. Il est nécessaire de les rajouter à la main depuis l’UI proxmox afin d’avoir une nouvelle VM fonctionnelle.
A noter que pour l’instant le système de “Instant Recovery” de Veeam qui permet de démarrer rapidement une nouvelle VM sans avoir terminé sa restauration complète n’est pas supporté pour Proxmox VE.
Enfin, une fonctionnalité que nous n’avons pas encore testée, qui pourrait simplifier les migrations et faire l’objet d’un autre article est la restauration de sauvegardes entre des hyperviseurs différents, typiquement d’une VM ESXi vers une VM Proxmox VE.
Fonctions de Backup integrity
Au sein de SureBackup Veeam, les fonctionnalités de Backup Integrity sont bien supportées comme sur les autres hyperviseurs : scans réguliers, signature des backups, multiples copies vers différents sites, archivage sur bande, etc.
Cependant, le Full recoverability testing qui consiste à créer un Virtual LAB n’est pas encore supporté sur un cluster Proxmox VE. Il vous faudra donc une instance VMware ou Hyper-V en plus afin de profiter de cette fonctionnalité.
Conclusions
Avant de vous fournir une conclusion complète, il vous faudra patienter encore un peu ! Nous publierons dans les jours prochains un second article traitant plus en détail des performances ainsi qu’une comparaison sur une période plus longue entre la solution de sauvegarde de Veeam et Proxmox Backup Server éditée par les mêmes équipes que la virtualisation Proxmox VE.
Cependant, on peut déjà noter que si vous utilisez déjà la solution Veeam Data Platform pour d’autres solutions de virtualisation, vous pouvez l’utiliser sans crainte pour votre nouvelle plateforme de virtualisation Proxmox VE.
Même si toutes les options disponibles avec d’autres hyperviseurs ne sont pas encore supportées, la sauvegarde de clusters Proxmox VE avec Veeam est fonctionnelle de manière fiable pour de la production, y compris sur des systèmes avec des données critiques et des architectures complexes. Vous n’aurez pas besoin de déployer de ressources supplémentaires (en dehors de l’espace disque nécessaire évidemment 🙂), et pas de surcoût de licences puisque le support de Proxmox VE est intégré par défaut dans les licences Veeam universelles (il faudra tout de même posséder un nombre de licences correspondant au nodes que vous ajoutez).
Ne ratez pas nos prochains articles DevOps et Cloud Native! Suivez Enix sur Linkedin!