Dans les architectures de virtualisation actuelles, certains choix techniques font toute la différence entre une plateforme qui tient bon sous la charge et un cluster qui s’essouffle dès que les I/O montent. Le Raw Disk Mapping, souvent abrégé en RDM, fait partie de ces options de stockage un peu discrètes, mais capables de changer le comportement d’un socle VMware sur des applications critiques. En donnant à des machines virtuelles un accès direct à des LUN de SAN, le Raw Disk Mapping contourne une partie de la couche VMFS classique, avec à la clé des gains de performance sensibles sur certains profils de charges, mais aussi des limites bien réelles en matière de souplesse et de fonctionnalités avancées.
Pour une PME industrielle qui fait tourner un ERP très bavard en lecture/écriture, pour un établissement de santé qui s’appuie sur un cluster SQL au cœur de son dossier patient, ou pour une maison de Champagne qui synchronise en temps quasi réel ses données de production entre deux caves, comprendre les avantages et contraintes du Raw Disk Mapping n’est plus un luxe technique, c’est devenu un sujet de pilotage d’infrastructure. Entre la promesse de « coller » au plus près du disque et la nécessité de garder une gestion des disques maîtrisable par l’équipe IT, l’arbitrage n’est pas si théorique que cela. Ce qui se joue derrière RDM, c’est un équilibre entre contrôle, simplicité et capacité à absorber l’avenir.
- RDM permet à une VM de dialoguer presque directement avec un LUN de SAN, là où un VMDK reste encapsulé dans un datastore VMFS.
- Le Raw Disk Mapping vise des workloads bien identifiés : bases de données exigeantes, clusters, besoins de réplication SAN avancée.
- Les avantages en termes de performance se paient par des limites sur certaines fonctions VMware, surtout en mode physique.
- La bonne décision consiste souvent à mixer RDM et VMDK, et non à opposer les deux approches de stockage.
- Une gestion des disques propre (zoning, masquage, documentation) conditionne 80 % du succès d’un déploiement RDM.
Raw Disk Mapping et VMware : définition concrète et cas d’usage clés
Sur le terrain, un RDM n’est pas un objet mystérieux, c’est avant tout un petit fichier de mappage stocké sur un volume VMFS. Ce fichier agit comme un proxy vers un LUN physique présenté par le SAN. Du point de vue de la VM, ce disque RDM ressemble à un disque SCSI classique. Du point de vue de l’administrateur, ce n’est pas un VMDK comme les autres, mais un raccourci vers un volume brut situé hors du datastore.
Concrètement, le Raw Disk Mapping introduit une couche minimale d’abstraction, juste ce qu’il faut pour que vSphere puisse inventorier le disque, l’affecter à une VM, l’inclure dans certains workflows, tout en laissant la plupart des I/O filer directement vers le LUN. Cette mécanique explique à la fois les gains potentiels de performance et les particularités de la gestion des disques en mode RDM.
Comment fonctionne un RDM dans la chaîne de stockage VMware
Dans une architecture typique, un client comme l’entreprise fictive « Atelier Verre & Métal » héberge ses serveurs applicatifs sur un cluster ESXi connecté à un SAN fibre. Ses volumes critiques (base ERP, reporting temps réel) sont exposés sous forme de LUN distincts. Pour ces LUN, l’équipe IT a choisi le Raw Disk Mapping plutôt que de créer de nouveaux datastores VMFS.
La chaîne est alors la suivante : le SAN présente un LUN, les hôtes ESXi le détectent et vSphere permet de créer un fichier de mappage RDM dans un datastore existant. Ce fichier ne stocke pas les blocs de données, il enregistre l’identifiant du LUN et quelques métadonnées. Quand la VM envoie une requête disque, ESXi lit le mapping et envoie l’I/O presque directement vers le LUN sous-jacent, sans passer par la logique de gestion de fichier VMDK.
- LUN sur le SAN, formaté ou non selon le cas d’usage.
- Fichier RDM sur un datastore VMFS, jouant le rôle de pointeur.
- VM configurée avec ce disque comme s’il s’agissait d’un volume SCSI classique.
- ESXi faisant le lien entre commande SCSI de la VM et LUN cible.
| Élément | Rôle dans le RDM | Point de vigilance |
|---|---|---|
| LUN SAN | Volume physique recevant les données | Capacité dédiée, QoS, réplication |
| Fichier RDM | Proxy entre VM et LUN | Emplacement, sauvegarde de configuration |
| VM | Consommateur de blocs, OS invité | Drivers, alignement partitions |
| ESXi | Router des I/O vers le bon LUN | Zoning, compatibilité HCL |
Ce fonctionnement intéresse tout particulièrement les équipes qui ont besoin d’aligner une VM sur des fonctions avancées de stockage côté baie : snapshots SAN, réplication synchrone, fonctionnalités spécifiques du constructeur. Là où un VMDK se contente souvent de ce que VMFS lui offre, un RDM laisse passer ces raffinements.
Les deux modes RDM : physique et virtuel, deux logiques très différentes
Dans les consoles VMware, choisir un RDM implique de trancher entre deux modes de compatibilité : mode physique et mode virtuel. Derrière cette apparente subtilité se cachent en réalité deux stratégies d’architecture opposées. En mode physique, presque toutes les commandes SCSI sont passées telles quelles au LUN, ce qui libère le plein potentiel du matériel mais coupe une portion des services VMware habituels.
En mode virtuel, les commandes transitent par une couche d’abstraction plus épaisse. L’hyperviseur garde la main sur les opérations de snapshot côté VM, sur certaines métriques et sur des outils comme Storage vMotion. En échange, une petite partie de la performance pure est perdue par rapport au mode physique. Pour un cluster SQL partagé entre plusieurs nœuds, beaucoup d’architectes privilégient le mode physique, tandis que pour un gros serveur de fichiers nécessitant des snapshots applicatifs fréquents, le mode virtuel paraît plus raisonnable.
| Mode RDM | Fonctionnalités VMware | Profil de performance |
|---|---|---|
| Physique | Fonctions limitées (snapshots VM souvent indisponibles) | Accès très proche du matériel, faible overhead |
| Virtuel | Compatibilité snapshots, clones, certaines migrations | Overhead modéré, I/O légèrement filtrées |
Autrement dit, accepter ou non de renoncer aux snapshots VMware au profit de la réplication SAN n’est pas un détail. C’est un choix stratégique de gestion des disques et de PRA, qui se prépare sur table avant d’attaquer le moindre assistant de configuration.
RDM, stockage et performances : quand l’accès direct change la donne
Les discours sur la performance du Raw Disk Mapping sont souvent tranchés : certains y voient un graal, d’autres une optimisation marginale. La réalité observée sur des plateformes de tailles variées est plus nuancée. RDM n’est pas une baguette magique, mais quand il est aligné sur la bonne charge, l’impact sur les temps de réponse et la régularité des I/O est bien tangible.
Le personnage d’« Atelier Verre & Métal » illustre bien le sujet. Leur ERP maison répétait des pics d’I/O aléatoires chaque fin de mois. Malgré une baie SAN solide, les VMDK hébergeant la base de données saturaient ponctuellement, avec des latences qui faisaient hurler la comptabilité. Après un passage d’un volume critique en RDM, les pics sont devenus prévisibles, contenus, et surtout mieux corrélés aux graphes de la baie elle-même. On ne gagne pas toujours 50 % de débit, mais on récupère une courbe plus lisible, donc plus pilotable.
Où se situent réellement les gains de performance du RDM
Il serait naïf d’affirmer que tout RDM surpasse systématiquement tout VMDK. En revanche, trois axes de gains reviennent régulièrement dans les retours de production : la baisse de latence sur les petites écritures, la constance de débit sur les fenêtres de charge et la capacité à exploiter les optimisations natives de la baie.
On l’observe surtout sur des workloads qui frappent en continu un seul volume : grosses bases SQL, journaux de transactions, files de messages, clusters de fichiers distribués. Plus la logique applicative s’approche d’un dialogue direct avec un disque, plus le Raw Disk Mapping relève d’un bon sens architectural plutôt que d’une lubie d’ingénieur.
- Latence : quelques millisecondes gagnées sur des milliers de requêtes finissent par compter.
- Débit soutenu : moins d’aléas liés à la contention dans le système de fichiers VMFS.
- Observabilité : les métriques SAN correspondent mieux au ressenti applicatif.
- Offload : certaines copies ou snapshots gérés côté baie ne passent plus par ESXi.
| Type de charge | VMDK sur VMFS | RDM bien configuré |
|---|---|---|
| Base OLTP très bavarde | Latence variable, sensibilité aux autres VMs du datastore | Latence plus stable, dépend surtout du SAN |
| Serveur de fichiers bureautique | Performances suffisantes, snapshots pratiques | Gain faible, complexité inutile |
| Cluster MSCS | Contraintes fortes, parfois non supporté | Aligné avec les prérequis de clustering |
Les pièges de performance à éviter avec RDM
Un point trop peu abordé : un RDM mal câblé peut donner un résultat pire qu’un VMDK soigné. Un zoning approximatif, un LUN partagé sans politique claire de QoS, un oubli d’alignement des partitions dans la VM, et l’accès direct devient source de frustration plutôt que de fluidité.
Autre écueil vu chez plusieurs clients : multiplier les RDM comme des confettis, par réflexe « plus c’est brut, mieux c’est ». Résultat, une topologie SAN illisible, des migrations de baies complexes, et des équipes d’astreinte réticentes à toucher au moindre volume. Sur ce point, une règle simple mérite d’être gravée sur le mur de la salle serveur : réserver le Raw Disk Mapping à ce qui justifie un audit de charge complet.
- Limiter le nombre de LUN RDM par VM pour garder une cartographie mentale possible.
- Isoler les LUN critiques sur des groupes de disques ou des pools dédiés.
- Documenter chaque RDM : VM cible, application, mode, dépendances de PRA.
| Mauvaise pratique | Conséquence | Alternative recommandée |
|---|---|---|
| RDM pour toutes les VM par défaut | Complexité, erreurs humaines, coûts de gestion | RDM réservé aux workloads identifiés comme sensibles |
| LUN partagés sans politique de QoS | Contention imprévisible, pics de latence | Segmentation par classes de service sur la baie |
| Absence de doc PRA | Restauration et bascule incertaines | Schéma clair stockage / VM / application |
En résumé, RDM n’est pas un raccourci magique vers un « super disque », c’est un contrat plus direct entre la VM et le SAN, qui exige une hygiène de stockage irréprochable.
Configuration pratique : mettre en place un Raw Disk Mapping sans se piéger
Entre la théorie séduisante et les fenêtres de configuration du vSphere Client, il y a parfois un fossé. La configuration d’un Raw Disk Mapping reste pourtant assez linéaire, à condition de poser quelques jalons au départ : quels LUN sont éligibles, quel mode (physique ou virtuel), quel datastore accueillera les fichiers de mapping, comment sera gérée la sauvegarde.
« Atelier Verre & Métal » a procédé en trois temps : inventaire SAN, choix des LUN à passer en RDM, puis tests sur un environnement de préproduction en clonant la base principale. Cette approche évite l’écueil classique du « on bascule en prod et on verra bien ». En matière de gestion des disques, le temps passé à maqueter un scénario restreint vaut souvent une semaine de débogage économisée.
Étapes clés pour configurer un RDM dans VMware
La séquence suivante couvre l’essentiel pour une VM donnée :
- Identifier le LUN sur la baie (nom, numéro, taille, pool de disques).
- Vérifier que le LUN est bien visible et présenté aux hôtes ESXi concernés.
- Depuis la VM, ajouter un nouveau disque en choisissant « Raw Device Mapping ».
- Sélectionner le LUN, le mode (physique ou virtuel) et le datastore qui stockera le fichier de mapping.
- Configurer ensuite le système invité : partitionnement, formatage, éventuelle migration de données.
Chaque étape paraît triviale, mais le moindre flou sur le LUN cible peut envoyer une VM en production écrire sur un volume censé être gelé pour de la réplication. D’où l’intérêt d’adopter un nommage explicite côté SAN et côté vSphere, avec une cohérence jusque dans les libellés visibles par les équipes support.
| Étape | Acteur principal | Erreur classique |
|---|---|---|
| Création du LUN | Administrateur stockage | Capacité sous-dimensionnée, absence d’étiquetage clair |
| Présentation aux ESXi | Stockage / Virtualisation | Zoning approximatif, masquage incomplet |
| Création du fichier RDM | Virtualisation | Choix du mauvais LUN parmi plusieurs tailles similaires |
| Configuration OS invité | Admin système | Partition mal alignée, absence de tests de charge |
Bonnes pratiques de compatibilité, sauvegarde et surveillance
Une fois le RDM en place, le travail ne s’arrête pas. Il faut encore se pencher sur trois volets : la compatibilité avec les versions de VMware, l’intégration dans la stratégie de sauvegarde, et la surveillance en continu des performances. Sur le premier point, les matrices HCL restent la référence : certains constructeurs imposent encore des restrictions sur la combinaison de RDM et de fonctions spécifiques.
Pour la sauvegarde, deux grands chemins se dessinent : déléguer au SAN grâce aux snapshots de baie, ou rester dans la sphère des agents à l’intérieur de la VM. Dans un cas, la gestion des disques se rapproche du monde physique, avec ses jobs de réplication et de clones. Dans l’autre, la VM reste pilotée classiquement par la solution de backup existante, qui doit bien comprendre qu’elle parle à un disque RDM.
- Vérifier le support de RDM par la solution de sauvegarde (qu’elle soit agent ou image-based).
- Mettre en place des métriques de latence par LUN dans les dashboards.
- Planifier des revues trimestrielles des RDM existants pour éviter les volumes orphelins.
| Aspect | Risque sans contrôle | Mesure recommandée |
|---|---|---|
| Compatibilité versions VMware | Fonctions désactivées après upgrade | Validation sur environnement de test avant montée de version |
| Sauvegarde | Volumes non protégés ou restaure complexe | Stratégie claire SAN vs agents, test de restauration régulier |
| Monitoring | Détection tardive de la saturation d’un LUN | Alertes sur latence, IOPS, capacité, par LUN RDM |
Un RDM bien né, c’est un RDM dont le cycle de vie est pensé dès le départ : création, exploitation, montée de version, migration possible vers un autre schéma de stockage si l’application évolue.
Comparer RDM et VMDK : avantages, limites et critères de choix
Au moment de concevoir une nouvelle plateforme, la tentation est forte de poser la question de manière binaire : RDM ou VMDK. En pratique, les environnements les plus stables et lisibles s’appuient souvent sur un mix des deux, chacun occupant le terrain qui lui correspond. D’un côté, les VMDK constituent un socle souple pour la majorité des machines virtuelles. De l’autre, le Raw Disk Mapping se réserve aux zones sensibles, celles où l’accès direct au LUN fait sens.
Refuser tout RDM par principe revient à se priver d’un outil utile. Tout passer en RDM par réflexe de performance est tout aussi discutable. La bonne approche passe par une grille de lecture où entrent en jeu le type d’application, les attentes de temps de rétablissement, le profil de l’équipe IT et la trajectoire à trois ans de l’infrastructure.
Tableau comparatif RDM vs VMDK
Pour clarifier le terrain, le tableau suivant condense les différences structurantes entre les deux options de stockage :
| Critère | VMDK sur VMFS | RDM |
|---|---|---|
| Type d’accès | Abstrait, via système de fichiers VMFS | Accès direct au LUN via fichier de mappage |
| Fonctionnalités VMware | Large support (snapshots, clones, Storage vMotion) | Dépend du mode, souvent réduit en mode physique |
| Complexité de gestion | Faible, standard pour la plupart des équipes | Plus élevée, nécessite maîtrise SAN |
| Performance I/O | Bonne pour la majorité des usages | Avantage sur les charges très exigeantes |
| Portabilité | Très bonne (fichiers facilement migrables) | Liée au LUN et à la baie sous-jacente |
- VMDK pour la flexibilité, l’automatisation, l’industrialisation des déploiements.
- RDM pour quelques volumes critiques, identifiés et documentés.
- Mix des deux dans une même VM possible, avec partition claire des rôles.
Méthode simple pour décider : quand choisir RDM, quand rester en VMDK
Une approche pragmatique consiste à passer chaque application au tamis de trois questions : la sensibilité à la latence, la dépendance à des fonctions SAN spécifiques, et l’importance des fonctions VMware de confort (snapshots, clones). Une base OLTP au cœur du chiffre d’affaires, qui doit tirer parti de la réplication synchrone de la baie, coche souvent les cases en faveur du RDM.
À l’inverse, un intranet documentaire, un serveur web de campagne ou un outil métier utilisé quelques heures par jour profitent davantage d’un VMDK classique. Pour ces usages, les avantages d’un provisioning souple, de snapshots rapides avant mise à jour et de migrations transparentes entre datastores surpassent largement les hypothétiques gains de performance brute.
| Profil d’application | Recommandation | Justification |
|---|---|---|
| Base de données transactionnelle critique | RDM sur LUN dédié | Latence, réplication SAN, prévisibilité des I/O |
| Serveur d’applications métier | VMDK | Besoin de snapshots fréquents, cycles projet rapides |
| Cluster de fichiers partagé | RDM (souvent exigé par l’éditeur) | Compatibilité clustering et partage de disque |
| VM de test / recette | VMDK | Replicabilité, clones rapides, faible criticité |
Pour résumer, RDM gagne sa place à la table dès qu’une application dicte ses propres règles en matière d’I/O ou de stockage externe. Le reste du temps, un VMDK bien dimensionné reste un choix équilibré.
Avantages réels et limites structurelles du Raw Disk Mapping en 2025
Avec le recul accumulé sur plusieurs générations de vSphere, le Raw Disk Mapping a désormais un historique suffisant pour qu’on cesse de le traiter comme une nouveauté. En 2025, son intérêt ne se discute plus sur la base de promesses, mais sur des patterns observés dans des environnements de toute taille. RDM remplit bien son rôle quand il est utilisé de manière ciblée, mais il impose aussi des garde-fous très concrets.
Les directions informatiques qui gèrent des dizaines de sites ou plusieurs data centers le savent : plus le parc grossit, plus chaque exception au modèle standard (ici, les volumes RDM) demande un effort de coordination. D’où l’intérêt de poser noir sur blanc ce que l’on gagne et ce que l’on perd à chaque fois qu’on opte pour un accès direct au LUN.
Les principaux avantages du RDM, au-delà du discours marketing
Les bénéfices qui reviennent systématiquement dans les retours clients ne sont pas si nombreux, mais ils sont nets :
- Intégration forte avec le SAN : snapshots, clones, réplication gérés côté baie.
- Performance ciblée sur quelques disques, sans réarchitecturer tout le cluster.
- Compatibilité avec certains scénarios de clustering qui exigent un disque partagé de type RDM.
- Transparence pour certains outils de stockage qui « voient » la VM comme un serveur physique.
Sur un plan très concret, cela permet par exemple à une maison de Champagne qui réplique ses volumes de production vers un second site de s’appuyer sur les capacités natives de sa baie, tout en gardant ses serveurs dans une couche de virtualisation robuste. Le RDM agit comme passerelle entre ces deux mondes.
| Avantage | Impact métier | Exemple typique |
|---|---|---|
| Snapshots SAN rapides | Fenêtres de sauvegarde réduites | Copies quasi instantanées pour reporting |
| Latence plus faible | Temps de réponse applicatifs améliorés | Portails clients, ERP, trading |
| Disques partagés supportés | Haute disponibilité applicative | Clusters Microsoft, Oracle RAC |
Des limites à ne pas minimiser : complexité, évolutivité, standardisation
Côté revers de la médaille, trois catégories de contraintes méritent d’être assumées dès le départ : la complexité, la dépendance accrue au SAN, et la difficulté à standardiser les déploiements. Un RDM ajoute une brique de configuration entre le monde VMware et le monde stockage. Cette brique doit être comprise par toutes les équipes amenées à toucher aux VM ou aux baies.
Sur des plateformes distribuées, l’automatisation (Infrastructure as Code, templates de VM, blueprints) tourne souvent autour de VMDK. Introduire des RDM oblige à définir des exceptions, des scripts spécifiques, des garde-fous. Certains projets de cloud privé font ainsi le choix d’interdire RDM hors cas dûment justifiés, précisément pour ne pas casser la logique de standardisation.
| Limite | Conséquence potentielle | Mesure d’atténuation |
|---|---|---|
| Moins de fonctions VMware en mode physique | Processus de sauvegarde et de clones plus rigides | Basculer les protections au niveau SAN |
| Dépendance au constructeur de baie | Difficulté à migrer vers un autre fournisseur | Prévoir un scénario de migration hors RDM |
| Complexité de diagnostic | Incidents plus longs à analyser | Instrumentation fine et documentation claire |
- Former l’équipe sur les chemins I/O spécifiques aux RDM.
- Limiter les fournisseurs de baies impliqués dans les scénarios RDM.
- Écrire une politique explicite « quand et comment utiliser RDM ».
Un RDM ne devient un atout qu’à la condition d’être traité comme un élément de design global, pas comme un simple bouton « plus rapide » dans l’interface de la console.
Dans quels cas le Raw Disk Mapping apporte-t-il un vrai gain par rapport à un VMDK ?
Le Raw Disk Mapping devient intéressant dès qu’une application se montre sensible à la latence disque, exploite des fonctions avancées de la baie SAN (snapshots, réplication matérielle) ou impose un partage de disque entre plusieurs nœuds de cluster. Typiquement, les bases de données transactionnelles critiques, certains clusters Microsoft ou Oracle, ainsi que des workloads temps réel tirent parti d’un accès plus direct au LUN. Pour des serveurs web, des applications métiers peu intenses en I/O ou des environnements de test, un VMDK bien dimensionné reste généralement suffisant.
RDM et snapshots VMware sont-ils compatibles ?
Tout dépend du mode choisi. En mode virtuel, un RDM se comporte en grande partie comme un VMDK et reste compatible avec les snapshots VMware, ce qui simplifie la sauvegarde image-based ou les retours arrière rapides. En mode physique, la plupart des fonctions de snapshot au niveau de la VM ne sont plus disponibles, car les commandes SCSI sont transmises directement au LUN. Dans ce cas, il faut basculer la stratégie de protection vers des snapshots SAN ou des agents à l’intérieur de la VM.
Le Raw Disk Mapping complique-t-il la gestion des PRA et de la réplication ?
RDM ne complique pas forcément un plan de reprise d’activité, mais il déplace le centre de gravité vers la baie de stockage. Quand un volume critique est en RDM, la réplication et les bascules sont souvent gérées côté SAN, avec des mécanismes de clones ou de mirroring. Cela exige une bonne coordination entre équipes stockage et virtualisation, ainsi qu’une documentation précise des correspondances LUN/VM. Si votre PRA repose surtout sur des snapshots VMware et des réplications de datastores, un usage massif de RDM peut en revanche rigidifier l’architecture.
Peut-on mélanger RDM et VMDK dans une même machine virtuelle ?
Oui, et c’est même une pratique fréquente. Une VM peut tout à fait utiliser un VMDK pour son système d’exploitation et quelques données secondaires, tout en s’appuyant sur un ou plusieurs disques RDM pour les volumes applicatifs les plus sensibles. Cette approche hybride permet de conserver la souplesse des VMDK pour le quotidien, tout en réservant le Raw Disk Mapping aux zones où l’accès direct au LUN et les capacités SAN spécifiques ont un intérêt métier démontré.
RDM est-il toujours pertinent face aux nouvelles technologies de stockage NVMe et SDS ?
Les baies NVMe, le stockage défini par logiciel et les appliances hyperconvergées ont changé le paysage, mais n’ont pas rendu RDM obsolète. Le Raw Disk Mapping reste utile dans les scénarios où une application attend un disque très proche du matériel ou doit dialoguer avec des fonctions SAN précises. En revanche, dans des architectures hyperconvergées, tout-VMDK et centrées sur la mobilité des workloads, RDM perd souvent de son intérêt au profit d’un modèle purement virtualisé. L’arbitrage se fait au cas par cas, en regardant les exigences de chaque application plutôt qu’en suivant une mode technologique.
