Qu'est-ce qui change lorsqu'un NAS domestique stocke des images disque de machines virtuelles ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Lorsqu’un NAS domestique stocke des images disque de machines virtuelles actives, il cesse d’agir uniquement comme une destination pour des fichiers autonomes et devient une partie d’un chemin de stockage bloc virtuel. Les systèmes d’exploitation invités envoient des lectures, écritures, vidages et modifications d’allocation via l’hyperviseur et le réseau vers le NAS. La latence, la durabilité des écritures, la récupération d’espace et les dépendances d’image deviennent donc aussi importantes que la vitesse de transfert.

Ce changement s’applique aux images disque utilisées par des machines virtuelles en fonctionnement. Une image éteinte conservée uniquement pour l’archive ou la sauvegarde se comporte davantage comme un fichier volumineux ordinaire. La distinction est importante car un NAS qui copie rapidement une grande image peut néanmoins fournir des temps de réponse incohérents lorsque plusieurs invités actifs génèrent des E/S petites ou synchrones.

Que stocke réellement le NAS à l’intérieur d’une image disque de machine virtuelle ?

Un système d’exploitation invité voit un périphérique bloc virtuel, mais le NAS peut voir une image RAW, QCOW2, VMDK, VHDX ou similaire. L’invité crée des systèmes de fichiers, des partitions, des fichiers et de l’espace libre à l’intérieur de ce périphérique virtuel. Pour le NAS, ces structures sont des plages de données et de métadonnées à l’intérieur d’un objet image ou d’un volume bloc.

Chaque requête traverse plusieurs couches : le système de fichiers invité, le contrôleur de stockage virtuel, la couche bloc de l'hyperviseur, le pilote d'image, le protocole de stockage en réseau, le système de fichiers NAS ou la cible bloc, et le support physique. La documentation du format d’image disque de QEMU distingue RAW et QCOW2 tout en décrivant des fonctionnalités telles que l’allocation parcimonieuse, les fichiers de base et les instantanés.

Pourquoi le modèle d’E/S devient-il plus mixte et sensible à la latence ?

Un invité en fonctionnement combine les mises à jour du système d'exploitation, l'activité du journal, les données d'application, les journaux, le trafic d'échange ou de fichier de pagination, et les services en arrière-plan. Certaines requêtes sont séquentielles, tandis que d'autres sont petites ou dispersées. Plusieurs machines virtuelles ajoutent des files d'attente indépendantes dont les opérations peuvent arriver au NAS domestique entrelacées plutôt que sous forme d'un flux continu.

Cela ne signifie pas que chaque machine virtuelle produit des E/S aléatoires de 4 Ko. La taille et l'ordre des requêtes dépendent de l'invité, de l'application, du contrôleur virtuel, du cache et de l'hyperviseur. Le changement significatif est que plusieurs charges de travail en blocs peuvent devenir une charge de travail NAS mixte, rendant la latence moyenne, la latence maximale, le délai de mise en file d'attente et la concurrence plus représentatifs que le seul débit séquentiel maximal.

Pourquoi les accusés de réception d'écriture sont-ils plus importants que la bande passante maximale ?

Une application invitée peut demander que des données importantes atteignent un point durable avant de continuer. Cette demande peut passer par un cache invité, un cache de disque virtuel, un hyperviseur, un protocole réseau, un cache NAS, un contrôleur de stockage et un support. Un accusé de réception rapide n'est utile que si chaque couche s'accorde sur la signification de la complétion.

Les noms de protocoles ne déterminent pas la durabilité par eux-mêmes. NFSv3 supporte les écritures instables suivies d'un COMMIT ultérieur, plutôt que d'exiger que chaque écriture soit immédiatement validée de manière synchrone. Le modèle WRITE et COMMIT de NFS a été conçu pour combiner une sémantique de récupération sûre avec une gestion plus efficace des écritures. NFSv4 rapporte également si une écriture a atteint un niveau de stabilité demandé.

La politique de cache peut échanger temps d'attente contre hypothèses de récupération, mais « asynchrone » ne signifie pas automatiquement non sécurisé et « synchrone » ne désigne pas une seule implémentation. Le chemin complet doit être pris en compte : comportement de vidage de l'invité, mode de cache de l'hyperviseur, accusé de réception du protocole, protection du serveur, et si le stockage final peut préserver les données reconnues en cas de défaillances pertinentes.

Comment les images creuses et le discard modifient-ils l'utilisation de l'espace physique ?

Une VM peut voir un disque virtuel de 500 Go même si son image consomme beaucoup moins d'espace physique. Les formats compacts allouent le stockage au fur et à mesure que l'invité écrit de nouvelles régions, donc la capacité virtuelle, la taille apparente du fichier, les données d'image allouées et l'utilisation physique du NAS peuvent toutes différer. Cela économise de l'espace initial mais rend la comptabilisation de la capacité moins intuitive.

Supprimer un fichier à l'intérieur de la machine invitée libère d'abord de l'espace dans le système de fichiers invité. Pour restituer l'allocation physique, l'invité peut devoir émettre une commande discard ou TRIM, le contrôleur virtuel doit l'accepter, l'hyperviseur et le format d'image doivent la transmettre, et le chemin NAS sous-jacent doit supporter la désallocation. Les contrôles de propagation du discard de QEMU montrent que ce comportement est configuré plutôt qu'automatique.

Même un chemin de suppression fonctionnel peut ne pas faire diminuer immédiatement la longueur apparente de l'image. Les instantanés peuvent encore référencer d'anciens clusters, le système de fichiers peut rapporter différemment les blocs alloués, ou le pilote d'image peut garder des clusters préalloués pour éviter une fragmentation ultérieure. L'espace libre invité et l'espace libre NAS doivent donc être mesurés séparément.

Que rajoutent les instantanés et chaînes de base à la charge de travail ?

QCOW2 peut utiliser des fichiers de base et des superpositions pour qu'une nouvelle image stocke les modifications tout en continuant à lire les blocs inchangés d'une image de base. Son allocation et ses métadonnées d'image sont organisées en clusters, comme décrit par la spécification du format QCOW2. Cette structure permet des clones et instantanés compacts mais crée des dépendances entre les fichiers.

Une lecture active peut être satisfaite par la superposition actuelle ou une couche de base plus ancienne, tandis qu'une nouvelle écriture peut allouer de nouveaux clusters. Les tâches de flux, de validation, de miroir et de sauvegarde peuvent copier ou fusionner des données pendant qu'une VM reste active. Les opérations de blocs en direct de QEMU montrent pourquoi la maintenance des instantanés peut générer un travail de stockage de fond important.

Un instantané n'est pas automatiquement une sauvegarde indépendante. Copier une superposition sans sa base requise peut laisser une chaîne d'images disque incomplète, et une image cohérente en cas de crash peut encore différer d'un point de récupération cohérent avec l'application. Une fois cette distinction claire, un flux de travail distinct de préparation des sauvegardes VM peut couvrir la protection opérationnelle sans servir de preuve pour le mécanisme de stockage.

Dimension de la charge de travail Stockage de fichiers ordinaire Stockage d'image disque de machine virtuelle active Conséquence pratique
Schéma d'accès Souvent de longues lectures ou écritures de fichiers Entrée/sortie mixte générée par l'invité La vitesse séquentielle est moins représentative
Latence Un retard prolonge le temps de copie Un retard peut bloquer une tâche client La latence de queue devient importante
Achèvement de l’écriture Dépend de l’application de copie La sémantique de vidage traverse plusieurs couches La durabilité doit être évaluée de bout en bout
Allocation d’espace La taille du fichier est directement visible Les tailles virtuelle et physique peuvent différer La capacité nécessite plusieurs mesures
Suppression Supprimer un fichier libère son allocation Le rejet côté client doit traverser le chemin de stockage L’espace NAS peut ne pas revenir immédiatement
Snapshots Généralement une copie séparée ou un snapshot d’application Les superpositions peuvent dépendre des images de base La récupération nécessite l’intégrité de la chaîne

Pourquoi chaque VM lente n’est-elle pas un problème de stockage NAS ?

Une VM peut attendre la planification CPU, la pression mémoire, la pagination du client, un verrou d’application, un contrôleur virtuel inadapté, ou des pilotes paravirtualisés manquants. L’hyperviseur peut aussi avoir sa propre file d’attente ou un goulot de cache. Une forte attente d’E/S du client est une raison d’inspecter le stockage, pas une preuve que le NAS est responsable.

Le réseau et le NAS doivent également être séparés. Un lien saturé peut limiter le débit global, mais un lien plus rapide ne peut pas éliminer un média lent, la latence de validation synchrone, une chaîne d’images profonde, ou la contention côté client. Inversement, une faible utilisation du réseau ne prouve pas que le réseau est sain car la charge peut attendre des allers-retours ou un stockage en aval.

Le diagnostic doit suivre le chemin plutôt que de remplacer le matériel en premier. Comparez la latence visible par le client avec l’attente d’E/S de l’hyperviseur, le délai et l’utilisation du réseau, le comportement des files d’attente du NAS, et la latence des dispositifs physiques. Un goulot d’étranglement est plus crédible lorsque les couches adjacentes s’accordent sur l’endroit où les requêtes commencent à attendre.

Que faut-il observer avant d’utiliser un NAS comme stockage pour VM ?

Commencez par identifier si les images sont actives, leurs formats, tailles virtuelles et allouées, profondeur des snapshots, et relations avec les fichiers de base. Notez si le stockage est basé sur des fichiers ou des blocs et quel protocole relie l’hyperviseur au NAS. Ces faits définissent le chemin que les mesures ultérieures doivent expliquer.

Observez à la fois le débit et la latence sous la charge prévue. Séparez une VM de plusieurs VMs, les lectures des écritures, et les rafales courtes de l’activité soutenue. Enregistrez l’attente d’E/S du client, les files d’attente de l’hyperviseur, la latence du protocole, la latence du stockage NAS, ainsi que les tâches de sauvegarde ou de snapshot en arrière-plan. Évitez d’utiliser une seule copie de gros fichier comme test de qualification unique.

FAQ

Un NAS domestique a-t-il besoin de SSD pour les images disque des machines virtuelles ?

Pas universellement. Les SSD offrent généralement une latence d’accès aléatoire plus faible, mais la nécessité dépend du nombre de VM, de la charge, de la concurrence, de l’objectif de latence et du fait que les images soient actives ou archivées. Les compromis plus larges entre supports et capacités relèvent de la décision HDD versus SSD, pas d’une règle universelle pour le stockage VM.

Le 10GbE est-il nécessaire pour exécuter des VM depuis un NAS ?

Non. Une bande passante plus élevée aide lorsque le trafic agrégé approche la limite actuelle du lien, mais elle ne supprime pas la latence du protocole, de la validation, du format d’image ou du support. Une charge de travail plus petite peut tenir dans un lien plus lent, tandis que plusieurs VM actives peuvent bénéficier d’une bande passante supplémentaire et d’une file d’attente réduite en cas de congestion.

Quel protocole est le meilleur pour le stockage VM : NFS, SMB ou iSCSI ?

Il n’y a pas de gagnant inconditionnel. Les protocoles fichiers et blocs exposent des sémantiques différentes de gestion, mise en cache, verrouillage et récupération, et les détails d’implémentation comptent. Une comparaison SMB versus NFS distincte couvre une décision plus large de partage de fichiers mais ne remplace pas les tests spécifiques aux VM ni n’inclut tous les compromis iSCSI.

Pourquoi la suppression de fichiers dans une VM ne libère-t-elle pas d’espace sur le NAS ?

La suppression par l’invité marque d’abord les blocs comme inutilisés à l’intérieur du système de fichiers invité. L’espace physique ne revient que si la suppression ou la désallocation traverse le contrôleur virtuel, l’hyperviseur, le format d’image, le chemin de stockage réseau et la couche d’allocation NAS. Les instantanés ou la préallocation peuvent aussi maintenir les blocs physiques en usage.

Un instantané de VM peut-il remplacer une sauvegarde de l’image disque ?

Non. Un instantané peut dépendre d’une image de base et d’autres couches dans sa chaîne, et il peut partager le même domaine de défaillance de stockage. Une sauvegarde récupérable doit préserver ou supprimer ces dépendances délibérément et doit être testée par une restauration.

Conclusion finale

Un NAS domestique stockant des images disque de machines virtuelles actives devient une partie sensible à la latence du chemin de stockage en bloc virtuel. Évaluez ensemble les E/S mixtes, la durabilité des écritures, l’allocation parcimonieuse, la propagation des suppressions, les dépendances des instantanés et la récupération — et confirmez où les requêtes attendent avant de considérer la bande passante, le protocole ou le support de stockage comme la solution.

Centre Tech & IA

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.