Prince George Electric Cooperative (PGEC), une coopérative d’électricité en Virginie (États-Unis), a migré 33 machines virtuelles de VMware vers Proxmox Virtual Environment (VE) en seulement deux semaines, avec seulement cinq fenêtres de maintenance nocturnes. Selon le cas publié par Proxmox, cette migration a permis de réduire d’environ 20 % les coûts liés aux licences et à l’exploitation, tout en remplaçant une infrastructure de reprise après sinistre basée sur un seul serveur par deux clusters de trois nœuds.
Les clés de la migration de PGEC vers Proxmox en 30 secondes
- PGEC a transféré 33 machines virtuelles de VMware vSphere vers Proxmox VE en deux semaines.
- La migration a utilisé l’assistant d’importation intégré de ESXi dans Proxmox, avec la reconstruction de certaines machines en fonction de leur charge.
- La nouvelle architecture intègre des clusters de trois nœuds pour la production et la reprise après sinistre.
- PGEC estime une économie d’environ 20 % par rapport au coût de maintien sous VMware.
- L’environnement offre un objectif RTO de quatre heures et RPO de 12 heures, avec des tests trimestriels de récupération.
Le projet est né de deux problématiques simultanées. PGEC utilisait VMware vSphere 7.0.3 et devait passer à vSphere 8, assorti d’un modèle de licence basé sur le nombre de cœurs, ce qui aurait considérablement augmenté les coûts prévus. Par ailleurs, leur infrastructure de reprise après sinistre reposait sur un seul serveur avec stockage local, ne permettant pas de reproduire intégralement l’environnement de production en cas d’incident grave.
Pour la coopérative, la décision ne se limitait pas à remplacer un hyperviseur. Le budget initialement prévu pour les licences VMware a été, selon Proxmox, réaffecté à l’expansion de l’infrastructure physique et à la construction d’un second environnement en cluster, capable de supporter des charges lors d’une restauration.
Le projet a été mené en partenariat avec Richweb, partenaire de Proxmox, qui a également assuré la gestion ultérieure de l’infrastructure.
Deux clusters Proxmox pour la production et la reprise
PGEC a restructuré son infrastructure autour de deux clusters Proxmox VE : l’un dédié à la production, l’autre à la reprise après sinistre, complétés par Proxmox Backup Server pour la sauvegarde et la restauration des VM.
Le cluster de production utilise trois serveurs Dell PowerEdge R740, chacun équipé de 768 Go de RAM. Le stockage principal provient d’une baie Pure Storage X20R4, connectée via iSCSI et NFS.
Les copies locales sont stockées sur un dispositif HVENS Vault basé sur un Dell R750, où fonctionnent Proxmox VE et Proxmox Backup Server en ZFS.
Le second cluster, situé sur le site de reprise, est également constitué de trois nœuds, composés de serveurs Dell PowerEdge R630, chacun doté de 512 Go de RAM. Cette configuration permet de quitter l’ancien modèle basé sur un seul serveur, en proposant une infrastructure en cluster.
Les sauvegardes sont répliquées de la production vers la localisation de reprise via une connexion 10G E-Line exploitant le réseau Ruralband de PGEC.
L’architecture de reprise inclut aussi un autre Dell R750 servant de HVENS Vault. Le stockage est réparti en deux niveaux : SSD et HDD pour le stockage de Proxmox Backup Server, et un ensemble NVMe sur ZFS destiné aux restaurations en direct.
Ce dernier composant a une fonction précise : en cas de scénario de récupération, les machines virtuelles peuvent être restaurées directement depuis Proxmox Backup Server sur le stockage NVMe, puis fonctionner dans le cluster à trois nœuds de la localisation secondaire.
Richweb procède à des tests trimestriels de cette procédure de récupération avec un ensemble défini de VM de production. Selon le cas publié par Proxmox, ces tests ont toujours donné des résultats satisfaisants.
Une migration concentrée en cinq nuits
La migration des 33 machines virtuelles s’est achevée en deux semaines. Pour limiter l’impact sur les services, les interventions ont été réparties sur cinq fenêtres de maintenance nocturnes.
Certaines VM ont été migrées via l’assistant d’importation ESXi intégré à Proxmox VE. D’autres ont été reconstruites en fonction de leur complexité et de leurs spécificités.
L’opération a aussi pris en compte la criticité de chaque système pour les opérations quotidiennes de la coopérative.
Le projet comprenait également une consolidation supplémentaire : PGEC a retiré trois serveurs Dell R720 exécutant KVM pour Ruralband. Ces charges ont été transférées dans le nouvel environnement en cluster après augmentation de la mémoire des serveurs de production.
Le résultat est une infrastructure où les VM de PGEC et les charges de Ruralband sont regroupées dans une plateforme commune, avec capacité de clustering et de reprise.
Le coût de VMware, un facteur déclencheur
PGEC explique que la montée en version de VMware vSphere 7.0.3 à vSphere 8 impliquait de passer à un modèle de licence basé sur le nombre de cœurs. Pour une organisation à ressources limitées, cela aurait rapidement accru la facture.
Leur analyse comparait également le coût d’une infrastructure de reprise adaptée en restant sous VMware. Selon le cas publié par Proxmox, cette solution aurait, en combinant matériel neuf et licences, été plus onéreuse que la migration vers Proxmox.
Richweb a alors proposé une architecture avec Proxmox VE permettant de privilégier l’achat de matériel et de stockage, plutôt que l’accroissement des coûts de licences.
“Rester sur VMware et construire une solution de reprise sur cette plateforme n’était simplement pas envisageable pour PGEC, nous avons donc conçu une solution adaptée à la croissance, à un prix qui leur permettait de privilégier le matériel plutôt que des licences coûteuses.”
Cette déclaration provient de Grady Larsen, directeur commercial de Richweb, et fait partie du cas publié par Proxmox.
PGEC estime une réduction d’environ 20 % des coûts de licences et d’exploitation par rapport à VMware. Il s’agit d’un chiffre issu de leur projet spécifique publié par Proxmox, à ne pas généraliser à d’autres installations.
Par ailleurs, la migration a modifié la répartition des dépenses : plutôt que de consacrer une part importante au coût des licences, PGEC a investi dans l’augmentation de la mémoire, du stockage, ainsi que dans les nœuds de production et de récupération.
| Élément | Avant la migration | Après la migration |
|---|---|---|
| Plateforme principale | VMware vSphere 7.0.3 | Proxmox VE |
| Machines virtuelles migrées | VMware | 33 VM transférées |
| Production | Environnement VMware existant | 3 nœuds Dell R740 |
| Reprise après sinistre | 1 serveur avec stockage local | 3 nœuds Dell R630 |
| Copies de sauvegarde | Infrastructure précédente | Proxmox Backup Server |
| Stockage de la reprise | Serveur unique | NVMe ZFS pour restauration |
| Fenêtres de migration | Non applicable | 5 nuits |
| Coût déclaré | Référence VMware | Environ 20 % de moins en licences et exploitation |
| Objectifs RTO/RPO | Non indiqué | RTO de 4 heures, RPO de 12 heures |
| Tests de récupération | Limitée par le système précédent | Trimestriels |
Les données proviennent du cas d’étude de PGEC publié par Proxmox et ne constituent pas une comparaison générale des coûts entre les deux plateformes.
La reprise après sinistre à une nouvelle échelle
L’un des aspects clés du projet ne réside pas seulement dans la migration des 33 VM. PGEC a également remplacé son ancien modèle de reprise basé sur un serveur unique par une infrastructure en cluster de trois nœuds.
Ce design permet à la localisation secondaire de faire fonctionner les VM restaurées sur un stockage NVMe. Richweb réalise des tests trimestriels pour valider cette procédure avec des charges sélectionnées.
PGEC fixe un RTO (Recovery Time Objective) de quatre heures, c’est-à-dire le délai cible pour la reprise, ainsi qu’un RPO (Recovery Point Objective) de 12 heures, définissant la perte maximale de données acceptable dans le cadre de cette architecture.
L’environnement est également géré en mode service par Richweb. Le fournisseur garantit les mises à jour, la surveillance de l’infrastructure ainsi que la planification des évolutions. La supervision 24/7 du matériel et de l’environnement Proxmox est également assurée.
Selon Sarat Yellepeddi, président et CEO de PGEC, cette solution permet aux équipes internes de gagner en efficience dans leurs opérations quotidiennes :
“Nos équipes IT internes ont gagné en efficacité dans nos opérations quotidiennes grâce à la migration vers Proxmox.”
La nouvelle plateforme leur permet de consacrer plus de temps aux applications, tout en passant moins de temps à gérer l’infrastructure sous-jacente.
Fondée en 1939, PGEC dessert aujourd’hui plus de 12 000 membres via un réseau de près de 1 300 kilomètres de lignes électriques dans six comtés de Virginie. Par sa filiale Ruralband, elle fournit également la connectivité à fibre optique jusqu’au domicile dans sa zone d’intervention.
Ce cas est particulièrement intéressant, car il combine trois décisions stratégiques dans un seul projet : abandon du modèle de virtualisation précédent, extension de la capacité physique, construction d’une infrastructure de reprise distribuée en trois nœuds. La migration des VM n’est qu’une étape, la nouvelle architecture étant beaucoup plus large et résiliente.
Proxmox souligne aussi que PGEC a pu réaliser cette migration sans ingénieurs spécialisés en interne, grâce à l’accompagnement de Richweb. Cela illustre un exemple concret de migration gérée, bien que les coûts, délais et architecture dépendent nécessairement de chaque contexte spécifique.
Questions fréquentes
Combien de machines virtuelles PGEC a-t-elle migré depuis VMware ?
PGEC a transféré 33 VM de VMware vers Proxmox VE en deux semaines, en répartissant l’opération sur cinq fenêtres de maintenance nocturnes.
Quel apport en économies pour PGEC avec Proxmox ?
Selon le cas publié par Proxmox, PGEC a réduit d’environ 20 % ses coûts de licences et d’exploitation par rapport à VMware.
Quelle infrastructure de reprise après sinistre utilise PGEC ?
La nouvelle reprise repose sur un cluster de trois nœuds Dell PowerEdge R630, utilisant Proxmox VE, Proxmox Backup Server et du stockage NVMe ZFS pour la restauration des VM.
Quels sont le RTO et le RPO du système PGEC ?
Le système de reprise est conçu pour un RTO de quatre heures et un RPO de 12 heures, avec des tests trimestriels sur un ensemble défini de VM critique.