Virtualisation du stockage : fonctionnement et cas d'usage

La virtualisation du stockage sépare les ressources visibles par les applications des équipements physiques qui contiennent leurs données. Un logiciel associe des volumes logiques ou des chemins de fichiers au stockage sous-jacent. Les administrateurs peuvent ainsi gérer la capacité et l'emplacement des données sans rendre chaque changement matériel visible aux utilisateurs.

Pour une équipe informatique qui prépare un renouvellement du stockage, un environnement de machines virtuelles ou un pool partagé plus important, les questions sont concrètes : quelle ressource est virtualisée, où fonctionne le logiciel et que se passe-t-il en cas de saturation ou de panne ? Ce guide présente les principales approches, leurs limites et les vérifications à effectuer avant de déplacer des données de production.

Qu'est-ce que la virtualisation du stockage ?

La SNIA définit la virtualisation du stockage comme l'application de la virtualisation aux services ou aux équipements de stockage. Une mise en œuvre courante regroupe des ressources physiques en pools et présente du stockage logique aux serveurs. Elle peut aussi masquer l'emplacement des fichiers derrière un espace de noms stable.

Ce stockage virtuel repose toujours sur des disques physiques, des contrôleurs et, dans certains cas, un réseau de stockage. Un pool peut fournir plusieurs volumes logiques plutôt qu'un seul immense disque virtuel. L'administrateur peut attribuer des volumes distincts aux applications tout en gérant ensemble la capacité qui les alimente.

Prenons un volume de base de données et un volume d'environnement de test issus du même pool. Chaque application voit la ressource qui lui est attribuée. Le système de stockage suit l'emplacement des données et applique les règles configurées de placement et de protection. Partager un pool ne signifie pas que les applications doivent pouvoir lire leurs données respectives.

Comment fonctionne la virtualisation du stockage ?

Une couche de virtualisation maintient la correspondance entre une ressource logique et son support physique. Pour le stockage en blocs, elle traduit les adresses logiques en emplacements sur le stockage sous-jacent. Pour les fichiers, elle peut diriger une demande portant sur un chemin vers le serveur ou le partage qui contient le fichier.

Plusieurs couches peuvent coexister. Le système d'exploitation invité voit un disque virtuel, l'hyperviseur stocke ce disque dans un datastore, et ce dernier utilise des volumes fournis par une baie de stockage. Lors d'un diagnostic, représentez ce chemin complet. Un disque invité apparemment sain ne prouve pas que le pool sous-jacent dispose d'assez d'espace libre.

Le gestionnaire de volumes logiques Linux, LVM, fournit un exemple concret. Dans l'architecture LVM décrite par Red Hat, des volumes physiques alimentent un groupe de volumes, à partir duquel sont alloués les volumes logiques. Le système d'exploitation peut les utiliser sans faire de chaque disque physique une destination distincte pour les applications.

Les métadonnées enregistrent ces relations. Leur protection et leur récupération comptent autant que celles des données. Si un service de correspondance devient indisponible, les applications peuvent perdre l'accès alors que les disques fonctionnent encore. La procédure de récupération dépend de la mise en œuvre et des composants touchés.

Virtualisation en blocs et virtualisation de fichiers

Ces catégories décrivent l'interface virtualisée. Elles ne précisent pas si le logiciel fonctionne sur un hôte, une baie ou un équipement réseau.

Approche	Ce que voit le client	Points à évaluer
Virtualisation en blocs	Un périphérique ou un volume logique en blocs, par exemple une LUN présentée sur un réseau de stockage	Compatibilité de l'hôte, latence, accès multichemin, capacité et partage pris en charge
Virtualisation de fichiers	Des fichiers et des dossiers accessibles dans un espace de noms logique	Permissions, stabilité des chemins, comportement des clients et disponibilité des cibles

Virtualisation en blocs

Le serveur accède à un périphérique logique sur lequel il installe généralement un système de fichiers, même si certaines applications gèrent directement les blocs. La couche de stockage assure la correspondance sous cette interface. Le stockage en blocs est courant pour les disques de machines virtuelles et les bases de données, mais le protocole seul ne garantit ni faible latence ni débit élevé.

Partager du matériel de stockage ne revient pas non plus à autoriser plusieurs hôtes à écrire sur le même volume. L'accès simultané exige une application, un système de fichiers ou une configuration en cluster compatible. Vérifiez explicitement cette conception avant de présenter une même unité logique à plusieurs serveurs physiques.

Virtualisation de fichiers

Un espace de noms stable peut simplifier la navigation entre plusieurs serveurs de fichiers et permettre de changer les cibles derrière des chemins familiers. Par exemple, les espaces de noms DFS de Microsoft regroupent des dossiers partagés de différents serveurs dans une vue logique et redirigent les clients vers les cibles correspondantes.

Un espace de noms commun ne regroupe pas, à lui seul, l'espace libre dans un pool de blocs et ne réplique pas les fichiers. Identifiez les composants chargés des déplacements, des copies, des permissions et du basculement. Un stockage en réseau NAS utilisant NFS ou Server Message Block (SMB) nécessite toujours une conception adaptée pour la disponibilité et la sauvegarde.

Où fonctionne la couche de virtualisation ?

Les approches sur hôte, sur baie et dans le réseau décrivent son emplacement. Ce choix détermine les équipements à gérer et les composants dont dépendent les charges de travail.

Emplacement	Rôle habituel	Question de préparation
Sur l'hôte	Un logiciel exécuté sur un serveur gère ses ressources de stockage	Comment gérer la configuration, la récupération et les ressources de chaque hôte ?
Sur la baie	Un contrôleur gère des ressources logiques sur les supports compatibles	Quels équipements et quelles fonctions cette baie prend-elle en charge ?
Dans le réseau	Un service ou un équipement présente le stockage sur le réseau dédié	Comment maintenir les chemins, la disponibilité des contrôleurs et le débit ?

Les termes « in-band » et « out-of-band » concernent une autre distinction : le chemin des données. En mode in-band, le trafic traverse le composant de virtualisation. En mode out-of-band, les fonctions de correspondance ou de contrôle sont séparées du principal chemin de transfert. Le guide de virtualisation du stockage de la SNIA explique cette terminologie. Aucune approche ne garantit automatiquement de meilleures performances ; une virtualisation sur baie ne doit pas être assimilée par défaut à un fonctionnement out-of-band.

Virtualisation du stockage, des serveurs et stockage cloud

La virtualisation des serveurs permet à une machine physique d'héberger des machines virtuelles dotées de leur propre système d'exploitation. La virtualisation du stockage concerne les volumes ou l'accès aux fichiers qu'elles utilisent. Un serveur physique peut employer du stockage virtualisé sans héberger de machines virtuelles, et une VM peut utiliser un disque virtuel reposant sur un stockage local.

Si vous choisissez aussi l'environnement de calcul, notre guide des machines virtuelles avec GPU traite cette décision distincte. La conception du stockage exige ses propres vérifications de capacité, de performance et de récupération.

Le stockage cloud décrit la manière dont le stockage est fourni et consommé. La virtualisation peut faire partie de sa mise en œuvre, tandis que l'API, la facturation, les permissions et la disponibilité définissent le service reçu. Les volumes Amazon EBS illustrent des périphériques en blocs que les clients attachent à des instances cloud. Notre guide du stockage cloud présente les choix de services plus largement.

Le stockage défini par logiciel utilise des logiciels pour fournir et gérer des services de stockage ; il peut inclure la virtualisation et d'autres fonctions. Une infrastructure hyperconvergée réunit calcul et stockage dans une plateforme commune. Aucun de ces termes ne précise à lui seul la protection d'un volume ou la capacité utile restante.

Pour les conteneurs, les PersistentVolumes de Kubernetes fournissent des ressources de stockage dont le cycle de vie est indépendant d'un Pod donné. Le stockage sous-jacent et la politique de récupération déterminent toujours le devenir des données. Comparez les machines virtuelles et les conteneurs séparément du choix de leur stockage persistant.

Avantages et cas d'usage

Provisionnement et gestion de la capacité

La mise en commun peut faciliter l'attribution de capacité disponible et réduire le nombre d'équipements qu'une équipe applicative doit manipuler. Une gestion centralisée peut aussi rendre le provisionnement et la supervision plus cohérents. Le gain est particulièrement pertinent lorsque les équipes passent du temps à déplacer des allocations entre des systèmes jusque-là séparés.

Pour le développement et les tests, les fonctions compatibles de clonage ou d'instantané peuvent accélérer la préparation d'environnements. Pour une infrastructure de bureaux virtuels, il faut surtout vérifier que le stockage partagé supporte de nombreuses ouvertures de session simultanées. La disponibilité des fonctions et les performances doivent être vérifiées sur la plateforme retenue.

Remplacement du matériel et mobilité des données

Des volumes logiques stables peuvent réduire les changements nécessaires dans les applications lors d'un renouvellement matériel. Certaines plateformes permettent une migration pendant que les charges continuent de fonctionner, sous réserve de leurs prérequis et restrictions.

Déplacer des données vers un autre support physique exige toujours de les transférer. Le processus de migration des partitions de stockage d'IBM comprend une copie et une synchronisation avant que la destination reprenne les entrées-sorties des hôtes. Modifier les correspondances ne supprime pas ce travail. Prévoyez le temps et la bande passante nécessaires, puis vérifiez la destination avant de retirer la source.

Limites et risques à prévoir

Le provisionnement fin ne crée pas de capacité physique

Le provisionnement fin, ou thin provisioning, alloue de l'espace à mesure que les données sont écrites au lieu de réserver immédiatement toute la taille logique. Il peut améliorer l'utilisation du stockage, mais permet aussi d'allouer plus de capacité logique que le support physique n'en offre. La documentation des volumes fins de Red Hat décrit leur utilisation d'un pool partagé.

À titre d'exemple, quatre volumes logiques de 10 To pourraient reposer sur un pool fin de 20 To utiles. Si leurs données occupent 8 To au total, elles tiennent à cet instant ; les quatre volumes ne peuvent pas chacun atteindre 10 To sans ajouter de capacité ou libérer de l'espace. Les instantanés, les métadonnées et les besoins de protection doivent aussi entrer dans le calcul propre à la plateforme.

Configurez des alertes sur l'utilisation réelle et sa croissance, désignez une personne pour y répondre et mesurez le délai d'extension. Vérifiez les limites des données et des métadonnées lorsque la solution les expose. Une alerte reçue après l'échec des écritures arrive trop tard pour permettre une augmentation planifiée.

Les performances dépendent du chemin complet des entrées-sorties

Mesurez la latence, les IOPS, le débit et le temps d'exécution de l'application avec un mélange représentatif de lectures et d'écritures. Incluez les pics de concurrence, les migrations en arrière-plan, la réplication et les opérations de récupération. Une latence moyenne peut masquer des requêtes lentes importantes pour les utilisateurs ; examinez aussi les percentiles élevés.

Recherchez les contrôleurs saturés, les limites réseau, le comportement du cache et les charges concurrentes. Combiner des supports rapides et lents ne rend pas tous les volumes aussi rapides. Toute politique de hiérarchisation ou de qualité de service doit être testée avec la charge qu'elle doit servir.

Disponibilité et sécurité exigent une configuration explicite

Une couche de stockage commune peut augmenter le nombre d'applications touchées par une panne. Cartographiez les dépendances aux contrôleurs, aux commutateurs, à l'alimentation, aux services de gestion et aux métadonnées. Des chemins redondants ne sont utiles que s'ils évitent la panne visée et si l'hôte sait les utiliser correctement.

Limitez l'accès administratif, isolez les clients ou les applications selon les besoins et vérifiez les affectations de volumes ainsi que les permissions des fichiers. Examinez le chiffrement et la récupération des clés du produit choisi. La virtualisation seule ne constitue pas une frontière de sécurité qui dispenserait de ces contrôles.

Instantanés et réplication exigent un plan de récupération

Les instantanés peuvent faciliter un retour rapide à un état antérieur, et la réplication peut placer des copies ailleurs. Leur utilité dépend de la cohérence, de la conservation, des droits d'accès et de leur indépendance par rapport à la panne. Une copie exposée aux mêmes identifiants ou à la même défaillance de stockage peut ne pas permettre la récupération attendue.

Broadcom précise que les instantanés VMware ne sont pas des sauvegardes : ils dépendent du disque virtuel d'origine. Utilisez un processus de sauvegarde compatible et testez la récupération de l'application et de ses données. Notre comparaison de la synchronisation et de la sauvegarde traite une autre confusion fréquente sur les copies.

Les vérifications avant l'adoption

1. Définissez le problème. Précisez le résultat attendu : provisionnement plus simple, continuité des chemins, migration matérielle ou autre objectif mesurable. Évitez d'ajouter une couche sans avantage opérationnel clair.
2. Inventoriez les dépendances. Recensez les équipements, les protocoles, les systèmes d'exploitation, les hyperviseurs, les firmwares, les pilotes et les responsabilités d'assistance. Validez les combinaisons exactes prises en charge.
3. Estimez la capacité utile. Incluez les données actuelles, leur croissance, les instantanés, les répliques, les réserves et les délais d'extension. Distinguez les allocations logiques de l'espace réellement disponible.
4. Testez des charges représentatives. Comparez le comportement des applications avant et après le changement, y compris pendant les pics, une migration et une panne contrôlée.
5. Prouvez la récupération et le retour arrière. Restaurez les données et la configuration nécessaire, puis documentez comment inverser ou arrêter la migration. Précisez qui autorise chaque étape.
6. Organisez l'exploitation. Attribuez la supervision, les mises à jour, la gestion de capacité et la récupération. Incluez les licences, l'assistance, la formation et une future migration de sortie dans le coût estimé.

Questions fréquentes

Un disque virtuel est-il la même chose que la virtualisation du stockage ?

Un disque virtuel est une ressource présentée à une machine. La virtualisation du stockage est la technique plus générale qui relie le stockage logique à son support. Un disque virtuel peut reposer sur plusieurs couches ; sa taille seule renseigne peu sur la capacité physique ou la résilience.

Faut-il un SAN pour virtualiser le stockage ?

Non. Un réseau de stockage SAN est l'un des contextes possibles. La gestion de volumes sur l'hôte peut employer des équipements locaux, tandis que les espaces de noms de fichiers interviennent à un autre niveau. Choisissez selon le problème d'accès et de gestion à résoudre.

Quand la virtualisation du stockage est-elle utile ?

Elle mérite d'être évaluée lorsque des systèmes séparés compliquent le provisionnement, le remplacement matériel ou la gestion de capacité. Elle peut apporter peu à une petite installation simple qui répond déjà aux besoins. La décision doit reposer sur des avantages mesurés et un plan de récupération testé.