Le stockage est essentiel pour les performances des machines virtuelles. La latence d'entrée-sortie révèle les temps d'attente liés au stockage. Elle peut ralentir les machines virtuelles et frustrer les administrateurs. Cet article explique la latence d'E/S dans Proxmox VE. Vous découvrirez sa signification, les niveaux acceptables et comment en identifier les causes aux niveaux débutant, intermédiaire et avancé.
Qu'est-ce qu'un délai d'E/S dans Proxmox ?
Le délai d'E/S indique combien de temps les processus attendent pour les opérations disque. Proxmox VE affiche le délai d'E/S dans la vue Summary du nœud afin d'aider les administrateurs à détecter les goulots d'étranglement liés au stockage. Il provient de la métrique iowait de la couche bloc Linux, qui mesure le temps d'inactivité du processeur en cas d'E/S en attente. En pratique, le délai d'E/S agrège les temps d'attente de tous les processus sur l'hôte, en échantillonnant périodiquement les statistiques du noyau.
Le délai d'E/S de Proxmox diffère de la charge brute du processeur. Une utilisation élevée du processeur peut refléter un travail de calcul, mais un fort délai d'E/S indique que le stockage ne parvient pas à suivre. Cette métrique permet d'identifier les ralentissements liés au disque. Elle est corrélée au %iowait de Linux affiché par des outils tels que iostat. Lorsque le délai d'E/S augmente, les processus sont bloqués en attente de la fin des lectures ou écritures, ce qui retarde les tâches de machines virtuelles ainsi que des opérations comme les instantanés ou les sauvegardes.
Proxmox échantillonne le délai d'entrée/sortie en vérifiant le nombre de tâches en sommeil ininterrompu (état D) en attente d'E/S disque. Il exprime le temps d'attente agrégé en pourcentage du temps processeur total. Cet échantillonnage fournit une vue au niveau du nœud, distincte des métriques par machine virtuelle. Les administrateurs peuvent la surveiller en temps réel via l'interface web ou récupérer les métriques via des API pour des tableaux de bord externes.
Le délai d'E/S réagit rapidement à la charge de stockage. Par exemple, le clonage d'une machine virtuelle déclenche des lectures disque élevées, ce qui fait augmenter brusquement le délai d'E/S jusqu'à la fin de la copie. De même, des écritures intensives depuis l'intérieur d'une machine virtuelle peuvent l'augmenter. L'observation des tendances du délai d'E/S permet de corréler une réponse lente de la machine virtuelle avec une pression sous-jacente sur le stockage. En résumé, le délai d'E/S représente pour Proxmox la durée d'attente liée au stockage, basée sur l'iowait Linux, aidant ainsi les administrateurs à détecter précocement des problèmes de stockage.
Quel est un délai d'E/S acceptable ?
Un délai d'E/S acceptable garantit que la réactivité des machines virtuelles reste conforme aux niveaux de service. Sous une charge légère ou modérée, des valeurs inférieures à 5 % n'ont généralement aucun impact visible. Des pics atteignant 10 à 15 % peuvent survenir lors d'opérations comme les sauvegardes ou les migrations à chaud sans causer de dommage, à condition qu'ils soient brefs. Toutefois, des valeurs persistantes supérieures à 20 % indiquent généralement une surcharge du stockage nécessitant une intervention.
Le type de charge de travail affecte les seuils. Dans un laboratoire domestique, un léger retard plus élevé peut être tolérable. En production, même de courts pics peuvent perturber les services sensibles à la latence. Posez-vous la question : la charge de travail est-elle critique en termes de latence ? Si oui, visez moins de 5 % la plupart du temps et évitez les longs pics. Si des tâches par lots s'exécutent en dehors des heures d'activité, un retard plus élevé peut être accepté à ce moment-là. Les tendances sont importantes : surveillez le délai d'E/S sur plusieurs jours ou semaines pour repérer une augmentation de la valeur de base.
Observez les tendances : des pics occasionnels pendant les sauvegardes peuvent être normaux s'ils sont planifiés. Mais si la latence d'entrée-sortie reste élevée en période d'inactivité, vérifiez l'état ou la configuration du stockage. De nombreux administrateurs considèrent un taux persistant supérieur à 10 % comme un avertissement et supérieur à 20 % comme critique. Certains trouvent acceptable un taux de 30 % brièvement sous une charge importante, mais évitent de le laisser durer. Des pics très élevés (50 % et plus) provoquent souvent des machines virtuelles inactives et doivent déclencher immédiatement des mesures correctives.
Le stockage différent affecte la tolérance : les baies SSD gèrent plus d'IOPS, montrant une latence inférieure sous charge. Les disques durs ou les pools mixtes peuvent atteindre une latence plus élevée plus tôt. Le stockage réseau comme NFS ou iSCSI peut ajouter de la latence. Pour Ceph ou tout autre stockage distribué, la charge du réseau influence également la latence des entrées-sorties. Comprenez les capacités de votre stockage et adaptez les seuils de latence en conséquence.
La version et la configuration de Proxmox peuvent avoir une importance. Les noyaux et pilotes plus récents améliorent souvent les performances et réduisent l'attente d'entrée/sortie. Les mises à jour de Proxmox VE peuvent inclure un réglage du planificateur ou un meilleur support du multi-file d'attente. Testez toujours les paramètres de seuil après les mises à niveau. En résumé, le délai d'entrée/sortie acceptable dépend de la charge de travail, du stockage et de la tolérance au risque de l'administrateur, mais reste typiquement inférieur à 5 % ; un taux durable supérieur à 20 % nécessite un examen.
Comment connaître la raison du délai d'E/S Proxmox ?
La recherche des causes implique des vérifications en couches, du matériel à l'invité. Commencez par des vérifications de santé simples, puis passez à une analyse approfondie.
1. Vérifier l'état de santé du matériel de base
Premièrement, vérifiez l'état des disques et les métriques de base. Utilisez smartctl -H sur les disques pour confirmer qu'ils indiquent un état sain. Les SSD surchauffés peuvent ralentir, augmentant inopinément le délai d'entrée/sortie. Vérifiez la température des disques via les attributs SMART et les capteurs du serveur. Ensuite, examinez l'état du contrôleur RAID ou du pool ZFS à l'aide de zpool status. Des disques défectueux ou des tableaux dégradés peuvent provoquer des retards.
Test d'entrée/sortie simple : exécutez dd if=/dev/zero of=/path/to/storage/testfile bs=1M count=1024 oflag=direct dans une machine virtuelle de test ou sur l'hôte. Observez la régularité du débit. Des vitesses anormalement basses indiquent des problèmes matériels ou de configuration. À ce stade, vérifiez également le câblage et l'alimentation : des câbles mal branchés ou une alimentation défaillante peuvent affecter les performances du stockage.
2. Surveiller l'activité au niveau du système d'exploitation
Ensuite, surveillez l'activité d'entrée/sortie au niveau du système d'exploitation hôte. Exécutez iostat -x 1 pour afficher l'utilisation des périphériques, les temps d'attente et les longueurs de file d'attente. Recherchez un %util proche de 100 % ou des valeurs élevées de await, signes de saturation. Utilisez iotop pour identifier les processus générant une forte activité d'E/S. Filtrez pour root : sudo iotop -ao. Repérez les processus QEMU ou les sauvegardes accédant intensivement aux disques. Corrélé les pics d'E/S avec les pics de délai d'E/S dans les journaux de l'interface Proxmox.
Vérifiez les états du processeur : utilisez mpstat 1 ou vmstat 1 pour afficher %iowait. Un taux élevé d’iowait correspond à un délai d’entrée/sortie. Toutefois, notez que l’iowait peut masquer des problèmes spécifiques à chaque périphérique ; vérifiez toujours les statistiques par disque. Utilisez lsblk ou df -h pour confirmer quels disques supportent quels machines virtuelles.
Si vous utilisez un stockage réseau, testez la santé du réseau : ping vers le NAS ou la cible de stockage ; iperf3 entre les hôtes pour mesurer la bande passante. Une latence élevée ou un débit faible peut augmenter le délai d'entrée/sortie. Pour NFS/iSCSI, vérifiez les options de montage : des paramètres inadéquats (noasync par rapport à async) peuvent affecter les performances.
3. Inspecter la pile de stockage
Explorez les spécificités de la couche de stockage. Pour ZFS, utilisez zpool iostat -v 1 pour visualiser les E/S au niveau du pool, les statistiques par vdev et la répartition des lectures/écritures. Si l'ARC est petite, les lectures accèdent fréquemment aux disques, augmentant ainsi la latence. Envisagez un réglage de l'ARC : augmentez le cache si la mémoire le permet, tout en conservant une marge pour les machines virtuelles.
Pour LVM, vérifiez l'approvisionnement fin par rapport à l'approvisionnement épais : les pools fins peuvent se fragmenter et provoquer des opérations lentes sur les métadonnées. Utilisez lvs -a -o+seg_monitor pour examiner l'état du pool fin. Pour LVM sur stockage réseau, assurez-vous que l'alignement des volumes correspond aux blocs de stockage sous-jacents afin d'éviter un surplus de charge.
Pour Ceph, surveillez les performances des OSD via le tableau de bord Ceph. Une latence élevée des OSD affecte directement le délai d'E/S de Proxmox. Vérifiez le débit réseau sur les réseaux publics et de cluster. Assurez-vous qu'aucun lien n'est saturé.
Vérifiez les choix de système de fichiers : XFS, ext4 ou ZFS ont des comportements différents en charge. Les charges axées sur les métadonnées peuvent ralentir sur des systèmes de fichiers dont les paramètres de journalisation ne sont pas optimisés. Revoyez les options de montage ; pour ext4, envisagez de désactiver les barrières uniquement si cela est sûr.
4. Examiner la configuration Proxmox
Exécutez pveperf sur les nœuds pour mesurer les performances de base de fsync/sync et des E/S disque. Un faible nombre de fsync/seconde indique des opérations de métadonnées lentes. Comparez les résultats entre les nœuds. Assurez-vous que le matériel et les paramètres sont cohérents.
Dans l'interface graphique Proxmox, observez quelle machine virtuelle provoque un retard d'E/S. Utilisez l'historique des tâches : vérifiez les horodatages au moment où le retard a augmenté. Corrélé avec les opérations des machines virtuelles : sauvegardes, instantanés, migrations à chaud. Envisagez de planifier les tâches intensives en dehors des périodes de pointe.
Vérifiez les paramètres du disque de la machine virtuelle : privilégiez VirtIO SCSI ou VirtIO Block avec un cache configuré sur writeback ou none selon la charge de travail. Évitez les caches non sécurisés en production. Dans le système d'exploitation invité, installez et mettez à jour les pilotes VirtIO pour des performances optimales. Pour les machines virtuelles Windows, utilisez la dernière version de l'ISO VirtIO. Pour les systèmes invités Linux, assurez-vous que les modules virtio-blk ou virtio-scsi sont chargés.
Examinez la configuration du stockage Proxmox : pour le stockage basé sur des répertoires, assurez-vous que les performances du système de fichiers hôte sont suffisantes. Pour LVM-thin, vérifiez la fragmentation du pool thin. Pour ZFS, vérifiez la taille d'enregistrement (recordsize) : choisissez une taille adaptée à la charge de travail de la machine virtuelle (par exemple, 16K pour les bases de données, 128K pour une utilisation générale). Pour Ceph, ajustez les fonctionnalités rbd et la mise en cache.
5. Examiner les journaux
Vérifiez dmesg pour détecter les erreurs du pilote de stockage : délais d'attente, réinitialisations. Les erreurs fréquentes dégradent les performances. Consultez /var/log/syslog et /var/log/kern.log pour repérer les erreurs ou avertissements E/S répétés. Dans les journaux des machines virtuelles situés dans /var/log/pve/tasks, recherchez les erreurs liées aux tâches de sauvegarde ou de migration.
Si vous soupçonnez un problème matériel, vérifiez les journaux RAID ou les outils du fabricant (par exemple, MegaCLI, storcli) pour détecter des avertissements liés au tableau. Pour SMART, examinez les attributs étendus : smartctl -a /dev/sdX pour les secteurs réalloués ou en attente.
6. Ajustement et tests
Régler le planificateur d'E/S Linux : pour les disques rotatifs, privilégiez le planificateur deadline ; pour les SSD, utilisez none ou mq-deadline en mode multi-file d'attente. Modifiez avec : echo mq-deadline > /sys/block/sdX/queue/scheduler. Testez les modifications sous charge contrôlée ; surveillez la latence des E/S avant et après.
Ajuster les paramètres ZFS : taille de l'ARC, emplacement du ZIL/SLOG. Pour des charges de travail axées sur les écritures, placez le périphérique SLOG sur un SSD à faible latence. Assurez-vous que la taille d'enregistrement ZFS correspond à la charge de travail invitée. Pour des écritures aléatoires importantes, une taille d'enregistrement plus petite peut être bénéfique. Surveillez la latence ZFS via zpool iostat.
Pour LVM-thin, exécutez régulièrement thin_repair ou convertissez les données actives en volumes épais si la fragmentation fine est élevée. Pour des charges de travail importantes, envisagez d'allouer des étendues à l'avance.
Réglage de la pile réseau : pour NFS ou iSCSI, ajustez l'unité de transmission maximale (trames géantes) si le réseau le prend en charge. Réglez les tailles de fenêtre TCP pour les liens à forte latence. Pour iSCSI, activez plusieurs sessions ou le multipath pour la redondance et le débit.
Utilisez un benchmarking avancé : exécutez fio dans une machine virtuelle de test ou sur l'hôte pour simuler des charges de travail. Par exemple, fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=4 --size=1G --runtime=60 --group_reporting. Comparez la latence et les IOPS aux capacités attendues.
Examiner les indicateurs au niveau du noyau : utilisez perf ou blktrace pour un suivi approfondi de la couche bloc. Cela permet d'identifier précisément les retards de mise en file d'attente ou les conflits du planificateur. Utilisez iostat -xk 1 et vmstat 1 pendant les tests pour établir des corrélations.
Pour une échelle extrême, envisagez de déporter le stockage : utilisez NVMe-oF ou des baies SAN dédiées. Pour les configurations hyperconvergentes, assurez-vous qu'un réseau de cluster dédié au trafic de stockage avec QoS est en place.
7. Planification des capacités
Suivez la croissance du stockage et les demandes d'IOPS sur plusieurs semaines. Utilisez les données historiques pour prévoir le moment où le stockage atteindra sa saturation. Des outils comme Prometheus avec l'exportateur Proxmox peuvent suivre l'évolution des délais d'E/S au fil du temps. Prévoyez l'ajout de disques ou la migration vers des supports plus rapides avant que des problèmes ne surviennent.
Pour un stockage distribué comme Ceph, prévoyez le nombre d'OSD et la bande passante réseau pour gérer les charges de travail maximales. Utilisez des outils de simulation ou des prototypes pour tester l'architecture.
Envisagez un stockage en couches : placez les disques des machines virtuelles sollicitées sur le pool SSD et ceux peu utilisés sur le pool HDD. Déplacez dynamiquement les machines virtuelles en fonction des modèles d'utilisation. Utilisez la migration de stockage Proxmox pour déplacer les disques.
Solution fiable de sauvegarde de machines virtuelles Proxmox
Avant de modifier les paramètres de stockage, protégez vos données avec une sauvegarde fiable. Vinchin Backup & Recovery est une solution professionnelle de sauvegarde de machines virtuelles de niveau entreprise prenant en charge Proxmox ainsi que VMware, Hyper-V, oVirt, OLVM, RHV, XCP-ng, XenServer, OpenStack, ZStack et plus de 15 environnements. Elle propose des fonctionnalités telles que la sauvegarde incrémentielle permanente, la déduplication et la compression des données, la migration V2V, la politique de limitation, entre autres, tout en offrant de nombreuses protections supplémentaires intégrées.
Sa console web est intuitive. Vous pouvez :
Sélectionnez la machine virtuelle Proxmox à sauvegarder;
Ensuite choisissez le stockage de sauvegarde;
Suivant configurez les stratégies de sauvegarde;
Enfin, soumettez la tâche pour démarrer la sauvegarde.
Vinchin est une solution faisant confiance aux clients du monde entier avec les meilleures évaluations. Essayez un essai gratuit de 60 jours complet et protégez facilement les machines virtuelles Proxmox. Cliquez sur Télécharger l'installateur pour commencer.
Proxmox IO Delay FAQs
Q1 : Quel niveau de délai d'E/S est sécuritaire pour les charges de travail quotidiennes sur Proxmox ?
A1 : Moins de 5 % est normal ; des pics occasionnels à 10–15 % sont acceptables ; une valeur constamment supérieure à 20 % nécessite un examen.
Q2 : Comment puis-je vérifier quelle machine virtuelle provoque un délai d'E/S élevé ?
A2 : Utilisez iotop pour détecter une forte utilisation des E/S disque, puis arrêtez ou mettez en pause la machine virtuelle pour confirmer l'impact.
Q3 : Les tâches de sauvegarde peuvent-elles provoquer un retard d'E/S, et comment le minimiser ?
A3 : Oui ; utilisez des sauvegardes incrémentielles ou incrémentielles permanentes et planifiez des fenêtres en dehors des périodes de pointe pour réduire la charge.
Conclusion
Le délai d'E/S révèle les temps d'attente du stockage pouvant ralentir les machines virtuelles. Vous avez appris ce qu'est le délai d'E/S, pourquoi des valeurs inférieures à 5 % sont idéales, et quand les pics sont significatifs. Vous avez vu comment vérifier l'état du matériel, surveiller les E/S avec des outils tels que iostat et iotop, examiner les piles de stockage allant de ZFS au stockage réseau, et ajuster les paramètres au niveau du système d'exploitation et de Proxmox. Les étapes avancées incluent le traçage approfondi avec fio, la planification des capacités et l'optimisation du planificateur.
Sauvegardez toujours les machines virtuelles avant d'apporter des modifications importantes : la solution Vinchin propose une sauvegarde incrémentielle permanente, la déduplication et bien plus encore pour protéger vos données en toute sécurité. Essayez gratuitement pendant 60 jours la solution Vinchin pour sécuriser votre environnement Proxmox.
