Pourquoi les files d'attente de stockage partagé ralentissent-elles plusieurs machines virtuelles de serveur domestique ?

Les files d'attente de stockage partagées ralentissent plusieurs VM de serveurs domestiques car les disques virtuels indépendants soumettent finalement des requêtes aux mêmes adaptateurs hôtes, contrôleurs, chemins réseau et disques physiques. Chaque VM peut avoir sa propre file d'attente virtuelle tout en attendant derrière le travail généré par d'autres VM à un niveau partagé inférieur.

Le ralentissement n'est donc pas déterminé uniquement par les IOPS d'une VM. La taille des requêtes, le mélange lecture/écriture, le comportement de synchronisation, la profondeur de file d'attente, le support de stockage et le moment des pics de chaque VM voisine se combinent en un ordre de service physique unique et un budget de latence fini.

Où les files d'attente séparées des VM deviennent-elles partagées ?

Chaque invité soumet des E/S via un contrôleur virtuel, mais les requêtes des VM convergent vers des ressources physiques partagées sous la frontière de l'invité. L'hyperviseur, le système de fichiers hôte, l'adaptateur de stockage et le périphérique de support fusionnent le travail de plusieurs disques virtuels.

Une VM peut signaler une file d'attente interne courte alors que ses requêtes attendent dans une file d'attente hôte ou périphérique que l'invité ne peut pas voir. C'est pourquoi l'utilisation du disque côté invité seule ne suffit pas à expliquer une latence d'application élevée.

Le chemin complet compte : ordonnanceur invité, contrôleur virtuel, file d'attente hôte, protocole de stockage réseau, contrôleur RAID et support physique peuvent chacun ajouter de l'attente. La couche la plus étroite et saturée devient la limite partagée.

Comment une VM devient-elle un voisin bruyant du stockage ?

Dans une infrastructure partagée, une charge de travail peut monopoliser les files d'attente de stockage et augmenter la latence pour des charges autrement calmes. Une sauvegarde, une compaction de base de données, une mise à jour ou un scan de gros fichiers peut provoquer ce pic.

La VM bruyante n'a pas besoin de dépasser la taille de son disque virtuel ou son allocation CPU. Elle doit seulement émettre suffisamment d'E/S en attente pour occuper le chemin de service partagé plus rapidement que le stockage ne peut traiter les requêtes.

Les machines virtuelles voisines subissent alors une latence de pointe plus élevée, même si leur demande moyenne de débit est faible. Un serveur DNS, une base de données domotique ou un service d'authentification peut sembler lent parce qu'une VM multimédia effectue un scan ou écrit intensivement.

Quand la profondeur de la file d'attente se transforme-t-elle en attente ?

Un certain nombre d’E/S en attente est utile car il maintient le stockage performant occupé, mais des files profondes révèlent un goulot d’étranglement du stockage. Au-delà du parallélisme utile de l’appareil, les requêtes supplémentaires augmentent le temps de résidence au lieu d’augmenter proportionnellement le travail accompli.

La profondeur de file est un compte à un niveau, pas une propriété universelle de la machine virtuelle. Une profondeur invitée de huit, une profondeur d’adaptateur hôte de plusieurs centaines, et une file matérielle NVMe sont des emplacements différents avec des limites différentes.

La profondeur de file augmente la latence après saturation. Le débit peut rester élevé tandis que les requêtes interactives des machines virtuelles attendent plus longtemps derrière le même flux soutenu.

Pourquoi l’architecture des files peut-elle changer la montée en charge des machines virtuelles ?

Un chemin hérité peut forcer de nombreuses opérations à passer par moins de voies de commande, tandis que le stockage à file unique sérialise plus de travail. Plusieurs machines virtuelles amplifient cette différence architecturale car leurs requêtes arrivent simultanément.

Les files parallèles réduisent la contention des verrous et permettent à différents cœurs CPU de soumettre et d’exécuter des tâches avec moins de sérialisation. Elles ne créent pas une performance de stockage illimitée ; le contrôleur, le réseau, la NAND ou les disques imposent toujours un plafond physique.

Le protocole et le chemin du pilote influencent donc la manière dont le système atteint la saturation. Un chemin plus parallèle peut préserver le débit et réduire la charge CPU, tandis qu’un chemin plus ancien peut créer une file dominante plus rapidement.

Pourquoi les HDD et le NVMe réagissent-ils différemment ?

Le Flash et le NVMe peuvent utiliser le NVMe qui supporte plus de commandes parallèles, tandis qu’un actionneur de HDD dessert encore les emplacements physiques principalement par mouvement mécanique.

Plusieurs machines virtuelles peuvent transformer des charges de travail séquentielles individuelles en un schéma physique aléatoire. Sur les disques durs (HDD), les requêtes entrelacées augmentent les déplacements de la tête et le délai de rotation ; sur les SSD, la même concurrence peut améliorer l'utilisation jusqu'à ce que les contrôleurs internes ou la mémoire NAND soient saturés.

Un support plus rapide réduit le temps de service mais n'élimine pas la mise en file d'attente. Les écritures synchrones, la collecte des déchets, le travail RAID, la latence réseau et quelques grandes requêtes peuvent encore retarder les petites opérations sensibles à la latence.

Comment la QoS et la séparation des charges de travail réduisent-elles les interférences ?

Le contrôle le plus fort est de limiter la quantité de travail partagé qu'une VM peut créer. l'isolation des charges de travail empêche la contention entre locataires en donnant aux services sensibles à la latence une frontière de ressources séparée.

Sur un serveur domestique, cela peut signifier des limites d'IOPS par VM, des priorités, des disques virtuels séparés, un pool SSD dédié aux bases de données, ou la planification des sauvegardes et analyses en dehors des heures interactives.

Mesurez la latence au niveau de l'hôte et l'occupation des files d'attente avec les métriques par VM. Les contrôles d'équité peuvent réduire le débit maximal d'une VM occupée, mais ils empêchent une charge de travail de lot de consommer le budget de temps de réponse de chaque service.

FAQ

Chaque VM a-t-elle sa propre file d'attente de stockage ?

Elle peut avoir des files d'attente virtuelles, mais ces files finissent par se regrouper dans les files d'attente partagées de l'hôte, de l'adaptateur, du contrôleur et du dispositif physique.

Une VM de sauvegarde peut-elle ralentir une VM base de données non liée ?

Oui. Une sauvegarde soutenue peut remplir les files d'attente partagées et consommer la bande passante du disque, augmentant la latence de la VM base de données même lorsque le CPU et la mémoire sont disponibles.

Une profondeur de file d'attente plus élevée est-elle toujours mauvaise ?

Non. Une certaine profondeur expose le parallélisme et augmente le débit. Cela devient nuisible lorsque le travail en attente dépasse la capacité parallèle utile et que les requêtes passent principalement plus de temps à attendre.

Le NVMe éliminera-t-il les problèmes de stockage liés au voisin bruyant ?

Non. Le NVMe offre plus de files d'attente parallèles et un temps de service plus court, mais les ressources finies de NAND, contrôleur, CPU, RAID et réseau peuvent toujours être saturées.

Conclusion finale

Plusieurs machines virtuelles de serveur domestique ne possèdent pas de disques physiques indépendants simplement parce qu'elles voient des disques virtuels indépendants. Leurs requêtes se regroupent dans des files d'attente partagées où les pics, les schémas d'accès mixtes et le parallélisme limité des dispositifs créent une latence de voisin bruyant. La surveillance consciente des files d'attente, les limites par VM, la planification et les niveaux de stockage séparés rendent la capacité partagée utile sans permettre à une VM de contrôler le temps de réponse de chaque application.