Comment SdV a migré 1 200 VM à chaud de VMware vers Proxmox
Soucieux de l’avenir de ses possibilités de licence VMware depuis le rachat de ce dernier par Broadcom, l’hébergeur a cherché des alternatives. Deux ans après, son directeur technique dresse un bilan du passage à Proxmox VE.
En 2024, alors que Broadcom vient de mettre la main sur VMware et s’apprête à bouleverser son mode de licence avec des tarifs à la hausse, l’hébergeur Web SdV, certifié ISO 27001 et HDS, s’est mis à chercher des alternatives à VSphere, la solution de mise en production des machines virtuelles de VMware et dont il était un spécialiste.
« En tant que partenaires du programme VSPP (VMware Service Provider Program), nous n’étions pas directement concernés par la fin des licences perpétuelles, mais il y a eu clairement un flou sur l’avenir de ce programme », se souvient Mathieu Heckenauer, le directeur technique de SdV. Une incitation au changement qui l’avait d’ailleurs profondément peiné : « Nous étions un utilisateur VMware de longue date et nous avons pu mener de grands projets de migration par le passé, grâce à sa capacité de migrer à chaud les VM. J’étais vraiment fan des technologies VMware », ajoute-t-il.
« Nous n’étions pas directement concernés par la fin des licences perpétuelles, mais il y a eu clairement un flou sur l’avenir de ce programme. »
Mathieu HeckenauerDirecteur technique de SdV
Précisons que ce programme VSPP constituait alors la pierre angulaire du business model de l’hébergeur. Créé il y a 40 ans, à l’époque de SdV Gretel et du Minitel, l’hébergeur alsacien compte aujourd’hui plus de 300 clients, parmi lesquels de gros sites de presse, dont Les Échos, Ouest-France, le Télégramme. Il accompagne également des structures comme Uni-Médias (groupe Crédit Agricole) pour l’hébergement de ses titres numériques.
Proxmox davantage adapté aux besoins de l’hébergeur
Les solutions de virtualisation Microsoft Hyper-V, Nutanix AHV et OpenStack sont mises sur la table. Les deux premières options ont été rapidement écartées, afin de ne pas retomber dans le même schéma de dépendance qu’avait SdV vis-à-vis de VMware. OpenStack aussi, mais plutôt du fait de sa complexité. Et c’est finalement vers la solution Open source Proxmox VE que se porte le choix du directeur technique.
« L’hébergement Web n’impose pas de grosses exigences en termes de fonctions : nous avions besoin d’une virtualisation de base, de déplacer les machines virtuelles à chaud, de haute disponibilité. Nous voulions aussi pouvoir déployer la solution sur une infrastructure hyperconvergée avec puissance de traitement et stockage sur les mêmes machines. Sur tous ces critères, Proxmox cochait toutes les cases », explique Mathieu Heckenauer.
« Nos équipes ont monté des maquettes à échelle réelle. [...] La qualité de service délivrée à nos clients ne devait en aucun cas être impactée par ce changement de technologie. »
Mathieu HeckenauerDirecteur technique de SdV
Divers tests sont menés en amont du projet afin de vérifier les capacités réelles de Proxmox VE, notamment concernant la possibilité de reproduire la configuration vSAN Stretched Cluster de VMware avec le système de stockage Open source Ceph.
« Nos équipes ont monté des maquettes à échelle réelle. Il s’agissait d’une migration majeure pour SdV et la qualité de service délivrée à nos clients ne devait en aucun cas être impactée par ce changement de technologie. Sur cette maquette, nous avons simulé à peu près toutes les pannes imaginables et nous avons été satisfaits des résultats », assure notre interlocuteur, qui se félicite des résultats alors obtenus.
Faire preuve d’ingéniosité pour une migration indolore
Après avoir validé le bon fonctionnement de Proxmox VE sur les briques de traitements internes, le véritable chantier de la migration démarre avec les VM des clients de l’hébergeur. La première phase a été de dresser leur inventaire afin de les regrouper par spécificités techniques. Il s’agissait de définir le meilleur moyen de convertir chaque groupe de VM dans le nouveau format.
L’équipe devait notamment traiter une problématique particulière. « Proxmox venait juste de dévoiler son outil de migration et la bonne pratique du moment était d’exporter les VM puis de les réimporter à froid. Il s’agit d’une méthode lourde et totalement inadaptée à notre contexte ; nous avions 1 200 VM à migrer et nous n’allions pas arrêter les bases de données de nos clients pendant des heures pour le faire » dit Mathieu Heckenauer.
« Nous avions 1 200 VM à migrer et nous n’allions pas arrêter les bases de données de nos clients pendant des heures pour le faire. »
Mathieu HeckenauerDirecteur technique de SdV
Les ingénieurs vont jouer sur le fait que Proxmox sait lire le format d’image-disque VMDK de VMware. Cela va permettre d’exécuter les scripts d’adaptation directement sur le contenu de ces fichiers et de les convertir au tout dernier moment au format Proxmox, plutôt que partir d’images disques vierges dans lesquelles les contenus des VMDK sont copiés avec des adaptations. Cette approche n’impose plus qu’un arrêt de production d’une minute en moyenne par VM.
« Ce délai réduit rendait gérable la migration pour nos clients. Avec tous les tests que nous avons pu mener en amont et cette garantie d’un délai de migration réduit, nous pouvions convenir avec eux du moment où la migration était lancée. Et nous avons ainsi migré l’ensemble de nos clients sans problème majeur », se félicite Mathieu Heckenauer.
Cette migration à chaud a aussi permis à l’hébergeur de mener l’opération sans devoir déployer des serveurs supplémentaires. La bascule s’est opérée simplement en utilisant la réserve de puissance des machines en place. « Nos serveurs n’étaient chargés qu’à 60 % », indique le directeur technique. Il ajoute que cette opération in situ n’empêchait aucunement l’équipe de revenir en arrière en cas de problème. Mais cela n’a pas été nécessaire.
En revanche, sur le volet stockage, SdV a dû renforcer ses infrastructures pour mettre en œuvre Ceph : « VSAN se contentait de deux copies des données pour fonctionner. Ceph en requiert de trois à quatre. Cela a un impact sur les volumes de stockage, mais c’est quelque chose que nous avions bien identifié en phase amont du projet et ce n’était pas une surprise au moment de la migration », témoigne Mathieu Heckenauer.
Il note qu’il reste possible de réduire la taille du stockage, en activant la compression. Mais son équipe n’a pas souhaité prendre cette direction qui aurait pu engendrer de la latence.
L’approche Infra-as-code a limité l’impact de la migration sur les process internes
En matière de conduite du changement en interne, Mathieu Heckenauer n’a pas eu à se heurter à des freins de la part de ses équipes. Bien au contraire.
« J’ai eu la chance de pouvoir m’appuyer sur une équipe très motivée et qui se félicitait de pouvoir travailler sur une solution Open Source de plus dans notre écosystème. Alors que VMware reste attaché à Windows pour ses outils du quotidien, Proxmox se rapproche beaucoup plus de Linux. Et si les interfaces ne sont pas les mêmes, les concepts restent très proches. Toute l’équipe était ravie », dit le directeur technique, qui précise la forte appétence de ses collaborateurs pour les outils Open source.
Il a tout de même fallu réécrire de nombreux scripts qui avaient été conçus pour les API VMware. L’approche du directeur technique a été d’isoler au maximum chaque brique d’infrastructure via l’approche de l’Infrastructure-as-Code. Cette couche d’abstraction a permis de limiter les problèmes d’incompatibilité avec tous les outils tiers, notamment ceux liés au monitoring de la plateforme, aux sauvegardes et aux procédures de restauration de l’activité en cas d’incident.
« Cette couche d’abstraction nous a clairement permis de limiter le coût d’intégration de Proxmox à notre infrastructure », conclut Mathieu Heckenauer.
Il ajoute que toutes les appliances tierces mises en œuvre par SdV reposent généralement sur un système virtualisé avec KVM, mais ce détail n’a posé aucun problème lors de la migration vers Proxmox VE.
