Réussir sa migration technique : D'un cluster VMware vSAN à Proxmox Ceph

Le premier article posait le cadre stratégique de la migration VMware vers Proxmox. Celui-ci entre dans le vif du sujet technique. Trois domaines concentrent l'essentiel des questions lors d'un projet de migration : le réseau et la sécurité, le stockage hyperconvergé, et la méthode de bascule des charges de travail. Voici ce qu'il faut savoir avant de commencer.

Réseau et sécurité : ce que Proxmox couvre vraiment

NSX-T est souvent cité comme le point de blocage majeur d'une migration VMware. La réalité est plus nuancée. Proxmox dispose d'un module SDN natif, introduit en version 7 et consolidé en version 8, qui couvre les besoins de segmentation réseau de la grande majorité des infrastructures.

Les zones VLAN et VXLAN permettent d'isoler les environnements multi-tenant, de créer des réseaux overlay entre nœuds, et de router le trafic inter-zones via des VRF ou un simple-router intégré.

Pour les infrastructures qui utilisaient NSX-T principalement pour la micro-segmentation et l'isolation réseau, Proxmox SDN suffit.

Le pare-feu Proxmox : un atout sous-estimé

Au-delà du SDN, Proxmox intègre un pare-feu complet, géré depuis l'interface web, applicable à trois niveaux distincts : le datacenter pour les règles globales, le nœud physique, et chaque VM ou conteneur individuellement. Cette granularité est précisément ce que propose NSX-T avec son pare-feu distribué. L'implémentation Proxmox repose sur nftables, natif dans le noyau Linux, sans aucune dépendance propriétaire.

L'écosystème open source permet d'aller bien plus loin en matière de sécurité continue :

• Wazuh s'intègre comme agent sur chaque VM pour constituer un SIEM/XDR complet : détection d'intrusion, analyse comportementale, corrélation d'événements et alerting en temps réel.
• CrowdSec vient en complément pour la protection comportementale et le partage communautaire de réputation IP. C'est un pare-feu qui apprend en permanence de l'ensemble du réseau de ses utilisateurs.
• BunkerWeb joue le rôle de WAF applicatif open source, déployable en conteneur LXC ou VM directement sur le cluster Proxmox, pour protéger les applications web exposées.

L'ensemble de cette stack, firewall Proxmox natif, Wazuh, CrowdSec et BunkerWeb, constitue une posture de sécurité continue qui n'a rien à envier aux fonctionnalités de NSX-T Intelligence.

Les limites réelles du SDN Proxmox

Là où Proxmox SDN montre ses limites, c'est sur les fonctionnalités d'infrastructure réseau avancées. Le load balancer distribué n'est pas natif : HAProxy ou MetalLB prennent le relais. Les VPN IPsec et SSL entre sites nécessitent une appliance dédiée, OPNsense, VyOS ou WireGuard selon les besoins. Le routage BGP dynamique passe par FRRouting, déployé en VM sur le cluster.

Ce ne sont pas des blocages, mais des choix d'architecture à anticiper lors de la phase de conception. L'avantage est que chaque composant est open source, documenté et maintenu activement.

vSAN vers Ceph : une migration très praticable

C'est probablement la bonne surprise de l'écosystème Proxmox. Ceph est intégré nativement dans l'interface de gestion depuis plusieurs années. Le déploiement d'un cluster de stockage distribué se fait directement depuis la GUI, sans outils tiers, sans scripts complexes. Notre article dédié à Ceph sur Proxmox multi-AZ détaille la logique de la CRUSH map pour ceux qui souhaitent aller plus loin.

La parité fonctionnelle avec vSAN est élevée sur les points essentiels :

• Ceph RBD assure le stockage bloc distribué pour les disques de VMs.
• CephFS couvre les besoins de stockage fichier partagé.
• La tolérance aux pannes est configurable via les CRUSH maps et le facteur de réplication.
• Le chiffrement des données au repos est disponible via dm-crypt sur les OSD.
• Le tableau de bord Ceph intégré dans Proxmox 8 fournit une supervision en temps réel des performances et de la santé du cluster.

Réplication inter-sites : le rôle de ZFS et Ceph

Un point important à clarifier : Proxmox Backup Server (PBS) est un outil de sauvegarde, pas de réplication inter-datacenters. Son rôle est d'assurer des sauvegardes incrémentielles dédupliquées et compressées des VMs et conteneurs, ce qu'il fait très bien. La réplication entre sites repose sur d'autres mécanismes.

• ZFS send/receive permet la réplication asynchrone de datasets entiers entre deux sites via SSH, avec une granularité au niveau du snapshot. C'est la solution la plus légère pour des environnements sans Ceph.
• RBD mirroring (réplication asynchrone entre clusters Ceph) couvre les besoins de PRA avec des RPO configurables.
• Le Ceph Stretch Cluster permet une synchronisation synchrone entre deux sites géographiques, mais exige une architecture réseau dédiée et un nœud arbitre (monitor tiebreaker).

Dimensionnement Ceph : les règles de base

Quelques invariants à respecter pour un cluster Ceph fiable sous Proxmox :

• Trois nœuds minimum pour garantir le quorum et la tolérance à la perte d'un nœud avec un facteur de réplication à 3. En dessous, le cluster peut se retrouver en état dégradé sans possibilité de recovery automatique.
• Un réseau dédié pour le trafic de réplication Ceph, séparé du réseau de gestion et du réseau des VMs. Un minimum de 10 Gbps est recommandé ; 25 Gbps devient la norme sur les déploiements récents à haute densité.
• Des SSD ou NVMe pour les métadonnées (WAL et DB BlueStore). Les OSD peuvent être des disques rotatifs pour les données froides, mais les journaux sur SSD sont non négociables pour les performances en écriture.

Méthodologie de migration par vagues

Une migration VMware vers Proxmox réussie suit toujours la même logique : audit complet, pilote isolé, migration par vagues, bascule des services critiques en dernier. Voici la méthode que nous appliquons.

• Phase 1 : audit et inventaire. Lister l'intégralité des VMs, datastores, réseaux VLAN, dépendances applicatives et licences OS. Identifier les VMs qui utilisent des fonctionnalités VMware-spécifiques : VGPU, PCI passthrough, intégration Horizon, scripts vSphere. Ce sont elles qui dicteront le calendrier.
• Phase 2 : pilote Proxmox en parallèle. Déployer un cluster de 3 nœuds Proxmox en environnement de production isolé. Valider Ceph sur le stockage, configurer le SDN, tester la haute disponibilité. Migrer 5 à 10 VMs non critiques en utilisant virt-v2v ou l'import OVA pour valider la chaîne de conversion.
• Phase 3 : migration par vagues. Procéder par priorité inverse, les charges les moins critiques d'abord. Chaque vague doit être validée en production pendant au minimum deux semaines avant de passer à la suivante.
• Phase 4 : bascule des services critiques. Planifier des fenêtres de maintenance courtes. Vérifier en amont que les plans HA sont actifs, que les sauvegardes PBS fonctionnent, que les alertes Grafana et Prometheus sont configurées, et que les runbooks de rollback sont écrits et testés.
• Phase 5 : décommissionnement VMware. Maintenir l'infrastructure VMware en parallèle pendant au moins un mois après la dernière bascule. Ne désactiver les licences qu'une fois la stabilité confirmée en production Proxmox.

Conversion des VMs : les outils à connaître

La conversion des disques VMware (VMDK) vers les formats Proxmox (qcow2 ou raw) est outillée et documentée.

• virt-v2v est l'outil de référence pour les migrations depuis ESXi : il convertit le format disque, injecte les drivers VirtIO et supprime les VMware Tools en une seule passe.
• qm importdisk et qm importovf couvrent les imports manuels depuis des fichiers OVA/OVF.
• Les VMs Windows nécessitent l'installation de qemu-guest-agent en remplacement des VMware Tools pour les fonctions de snapshot cohérent et de communication avec l'hyperviseur. Sur Linux, le remplacement est transparent.

Greenhoster déploie et opère votre cluster Proxmox

Greenhoster conçoit, déploie et opère des infrastructures Proxmox sur des serveurs dédiés français, éthiques et écologiques. Nous intervenons sur l'ensemble de la chaîne : architecture Ceph, configuration SDN, mise en place de la stack sécurité (Wazuh, CrowdSec, BunkerWeb), et accompagnement des équipes techniques tout au long de la migration.

Reprenez la maîtrise de votre infrastructure en sortant de la dépendance VMware/Broadcom. Contactez-nous pour étudier votre projet.