Machine virtuelle, conteneur ou bare metal ? Le bon mode dépend de l’application, du support de son éditeur et des personnes qui l’exploiteront durablement. Un conteneur ne rend pas automatiquement un ancien ERP facile à maintenir. Un serveur physique n’est pas automatiquement plus rapide. Une VM ne dispense pas des sauvegardes et mises à jour. DAXS part donc de la charge réelle : système, dépendances, données, reprise et charge mesurable.
Cette comparaison répond à la question de savoir où exécuter un service. Lorsque les conteneurs applicatifs sont déjà retenus, une autre question suit : Docker Compose ou Kubernetes pour l’exploitation ? Ces deux décisions doivent être prises séparément.
Que sépare-t-on réellement ?
Une machine virtuelle dispose de matériel virtuel et de son propre système invité. Un invité Windows Server peut ainsi côtoyer des invités Linux sur le même hyperviseur. La VM constitue une unité bien délimitée pour les correctifs du système, les snapshots et la restauration ; son application doit néanmoins être sauvegardée de façon cohérente. Proxmox VE utilise KVM pour cette approche.
Un conteneur partage le noyau de l’hôte. Deux formes se distinguent : un conteneur Proxmox LXC est un système Linux léger ; un conteneur applicatif OCI regroupe généralement une application et ses dépendances. Aucun n’est une VM Windows ni une isolation par noyau distinct. OCI exige aussi une construction d’images entretenue, un registre, des correctifs de sécurité et une solution explicite pour les données persistantes. Une VM Linux comme hôte de conteneurs peut délimiter utilement exploitation, sauvegarde et droits ; elle n’est pas techniquement obligatoire dans tous les cas.
Bare Metal exécute directement le système et l’application sur un serveur physique. Cela peut convenir à des contraintes éditeur, du matériel spécialisé ou des exigences de latence démontrées. La consolidation de cet hôte diminue toutefois et la maintenance, les pièces et la reprise dépendent davantage de la machine physique. Ici aussi, mesures et engagements de support priment sur une affirmation générale de performance.
Cinq charges typiques et leur première piste d’évaluation
Les pistes suivantes sont des points de départ pour un essai, pas des validations générales de produits. Documentation éditeur, contrat de licence et test de restauration rendent la décision solide.
| Application | Piste d’évaluation | Question critique |
|---|---|---|
| ERP Windows avec base de données et support éditeur | VM comme point de départ naturel | Quelle combinaison de système invité, hyperviseur, SQL et licences est réellement prise en charge ? |
| Service web Linux interne avec build reproductible | Conteneur applicatif OCI, éventuellement sur VM Linux | Qui construit et actualise les images, vérifie les vulnérabilités et exploite registre, secrets et journaux ? |
| Appliance Linux d’un éditeur | Examiner d’abord une VM prise en charge | L’éditeur accepte-t-il la virtualisation, les périphériques virtuels et le parcours de sauvegarde/restauration prévu ? |
| Base de données avec forte charge d’écriture | VM ou bare metal selon les mesures ; conteneur uniquement avec persistance testée | Comment évoluent latences p95/p99, IOPS, réplication et restauration cohérente en pointe ? |
| Service avec dongle, carte spécialisée ou accès direct à un périphérique | Tester le passthrough de la VM ; envisager le bare metal | Support éditeur, affectation des périphériques et reprise restent-ils possibles après remplacement d’un hôte ? |
Un conteneur de base de données n’est pas mauvais en soi. Sa couche de fichiers inscriptible ne doit cependant pas contenir les données qui doivent survivre à son remplacement. Volumes, cohérence, sauvegarde et restauration doivent être planifiés explicitement. Inversement, une VM ne transforme pas une sauvegarde non testée en reprise fiable.
Six vérifications pour décider
- Éditeur et licence : Vérifier par écrit les systèmes, hyperviseurs, moteurs de conteneurs et contraintes matérielles pris en charge. Les droits Windows Server dépendent notamment de l’édition, des cœurs licenciés, du nombre d’environnements virtuels et du contrat ; « une VM » n’implique pas un prix forfaitaire.
- Isolation et autorisations : Quel service peut influencer les autres ? Les conteneurs disposent de namespaces et de limites de ressources, mais partagent le noyau hôte. Moteur, privilèges, montages, réseau et mises à jour font partie de l’examen de sécurité.
- Mesurer les performances : Relever avec des données réelles les charges CPU, RAM et E/S, les latences p95/p99, les pointes et les fenêtres batch. Choisir le bare metal uniquement pour un supposé « surcoût de virtualisation » peut immobiliser une capacité coûteuse sans résoudre le véritable problème de stockage ou de réseau.
- Données et restauration : Définir RPO et RTO par service. Exercer une restauration complète sur un autre hôte, avec base, configuration, identifiants et dépendances.
- Changements et personnel : Qui corrige le système invité ou le noyau hôte ? Qui reconstruit les images ? Qui peut gérer la nuit un rollback raté ou un remplacement matériel ? Les compétences disponibles limitent le nombre de plateformes exploitables raisonnablement en parallèle.
- Domaine de défaillance : Examiner séparément hôte, stockage, réseau et sauvegarde. Ni un serveur bare metal unique ni plusieurs conteneurs sur un seul hôte ne deviennent hautement disponibles par leur nom.
Comparer l’effort avant d’annoncer des économies
Sur trois ou cinq ans, comparer dans chaque colonne la même application, la même charge et le même objectif de reprise. Comptabiliser migration et mise en place initiales, matériel et pièces, droits des systèmes et applications, support hyperviseur ou moteur, énergie, sauvegarde, supervision et heures annuelles du personnel. Pour OCI s’ajoutent par exemple pipeline de build, registre, entretien des images et éventuelle orchestration. Le bare metal peut nécessiter du matériel de remplacement et une autre fenêtre de maintenance. Pour les VM, compter capacité hôte et systèmes invités. Un cluster existant n’est « gratuit » pour le nouveau service que si réserves, licences et moyens d’exploitation existent réellement.
La formule de base vérifiable est : coût total sur n ans = mise en place et migration initiales + n × (licences annuelles + support + énergie + sauvegarde + heures d’exploitation × coût horaire interne) + renouvellement prévu. n vaut trois ou cinq. Aucun mode n’a un avantage général sans devis précis, mesures de charge et conditions de support. La comparaison doit aussi montrer le coût d’objectifs RPO/RTO non atteints, plutôt que l’exclure du calcul.
Comment DAXS choisirait le mode d’exploitation
DAXS dresserait d’abord une courte liste d’applications avec responsable, flux de données, support éditeur, dépendances et objectif de reprise. Deux candidats réalistes passeraient ensuite un bref test : charge proche de la production, correctifs et mises à niveau, défaillance d’un hôte ou périphérique et restauration sur une autre machine. Le résultat est une décision justifiable par application, pas l’obligation de déplacer tous les services sur une seule plateforme.
Les VM Windows et Linux existantes peuvent souvent être évaluées progressivement ; Proxmox en entreprise décrit la base de virtualisation. Si les conteneurs conviennent, la comparaison entre Docker Compose et Kubernetes aide pour la suite. Pour une charge précise, via Contact DAXS peut réunir validations, mesures et restauration dans une décision d’exploitation.
Sources : Proxmox VE : KVM et LXC · Docker Engine : modèle de sécurité · Docker Engine : données persistantes · Microsoft: Windows Server Virtualization Licensing Guidance.
