Proxmox et stockage iSCSI/NFS : optimisation des performances, gestion des timeouts et optimisation des montages

Lorsque des VM dans Proxmox réagissent avec retard ou que des opérations de stockage semblent bloquer de manière aléatoire, un dépannage structuré aide. Ce document pratique commence par le message principal : l’optimisation des performances iSCSI/NFS dans Proxmox n’est pas un paramètre isolé, mais une orchestration coordonnée des réglages de l’hôte, du réseau et du Target. Lisez la chaîne de vérification, des exemples de configuration concrets, des procédures de test et une stratégie de repli claire.

Aperçu : caractéristiques des protocoles et impact en exploitation

iSCSI est du block‑storage : l’hôte voit une LUN comme un disque local. Sur l’hôte interviennent la couche bloc Linux, l’ordonnanceur I/O et Multipath (Device Mapper). NFS est un système de fichiers distribué sur TCP (NFSv3/v4). Les images de VM sont des fichiers ; pour NFS, la sémantique de montage (p. ex. hard/soft, timeo, retrans) gouverne le comportement en cas de perturbation de connexion. Les deux protocoles réagissent différemment aux pertes de paquets, problèmes de MTU, switch‑hashing ou limites de threads côté serveur.

Classer correctement les groupes de symptômes

Avant de modifier quoi que ce soit, classifiez le problème. Groupes typiques :

• Limite de performance : faible bande passante ou trop peu d’IOPS, sans erreur.
• Timeouts et blocages : I/O bloqué, tâches en attente (sur NFS souvent lié aux montages hard).
• Erreurs/corruption : erreurs I/O, stale file handle, incohérences de données.

La contre‑mesure diffère : l’augmentation du débit exige souvent des modifications des files d’attente/ordonnanceurs, les timeouts nécessitent l’ajustement de la logique de retry et des configurations de redondance.

Chaîne de vérification : Host → Netzwerk → Target (procéder systématiquement)

Les changements dans la chaîne de stockage doivent toujours être réversibles et effectués pas à pas. Exécutez la séquence suivante :

• Vérifications hôte : statistiques I/O, ordonnanceur, processus
• Vérifications réseau : erreurs, MTU, retransmissions, LACP
• Vérifications Target : threading, queue‑depth, politique d’export/du Target

Hôte : commandes rapides pour diagnostic de base

# Pakete für Diagnose
apt-get update && apt-get install -y sysstat multipath-tools open-iscsi fio blktrace

# Laufende Messwerte (lesen Sie r_await/w_await, avgqu-sz, %util)
iostat -xz 1 5

# Prozesse mit hoher IO‑Wait
pidstat -d 1 3

# Blockdevices und Schedulers
lsblk -o NAME,MAJ:MIN,ROTA,RO,SIZE,MODEL
cat /sys/block/sdX/queue/scheduler

Important : r_await/w_await indiquent les latences ; avgqu‑sz la longueur de la file d’attente. Des valeurs élevées indiquent un embouteillage ou une gestion de file d’attente insuffisante.

Réseau : vérifications de bout en bout

# Link‑Fehler, Drops
ip -s link show dev eth1

# TCP Retransmits/Statistiken
ss -i dst 10.10.20.10:2049  # Beispiel NFS
ss -s

# MTU Test mit Ping (Jumbo)
ping -M do -s 8972 10.10.20.10

Vérifiez que les Jumbo Frames fonctionnent de manière cohérente sur tous les éléments. Le hashing LACP peut regrouper les flux sur un seul lien physique et ainsi annuler l’avantage d’avoir plusieurs liens.

Paramètres spécifiques à Proxmox et définitions de stockage

Proxmox gère le stockage dans /etc/pve/storage.cfg (un fichier de configuration de cluster). Veillez à ce que les références aux périphériques bloc prennent en compte Multipath : pointez vers /dev/mapper/mpath* plutôt que /dev/sdX, afin que la redondance des chemins soit effective.

Exemple : storage.cfg pour iSCSI avec LVM

# Ausschnitt /etc/pve/storage.cfg
iscsi: iscsi-lun1
        portal 10.10.30.10:3260
        target iqn.example:lun1
        content images,rootdir

lvmthin: local-lvm
        vgname pve
        thinpool data

Si le device iSCSI apparaît d’abord en tant que /dev/sdX, le PV LVM s’y trouvera et Multipath ne sera pas utilisé. Objectif : faire apparaître les LUNs sous /dev/mapper/mpath*.

Multipath : exemple de multipath.conf

# /etc/multipath.conf (vereinfachtes Beispiel)
defaults {
  user_friendly_names yes
  find_multipaths yes
}

blacklist {
  devnode "^sda$"
}

multipaths {
  multipath {
    wwid 3600a0980387example
    alias mpath-data
    path_selector "round-robin 0"
    path_grouping_policy multibus
    failback immediate
  }
}

Explication : wwid identifie le device ; path_selector contrôle la répartition de charge ; find_multipaths facilite la détection. Testez multipath -ll après les modifications.

Finesses NFS : options de montage, nconnect, timeouts

Les montages NFS influent fortement sur le comportement en cas d’incident. Options importantes :

• hard (par défaut pour du stockage critique) : bloque les I/O jusqu’à rétablissement ; plus sûr, mais peut bloquer des threads.
• timeo (timeout en unités de 0,1 s) : définit quand commencent les tentatives de retransmission.
• retrans : nombre de retransmissions avant erreur.
• nconnect : plusieurs connexions TCP par montage pour répartir la charge en parallèle (pris en charge et pertinent uniquement à partir du client Linux‑Client, et si le serveur dispose des threads/CPU nécessaires).

Exemple de montage avec nconnect

# /etc/fstab Beispiel
10.10.20.10:/export/pve /mnt/pve-nfs nfs4 _netdev,hard,timeo=600,retrans=2,noatime,nconnect=4 0 0

# Mount anwenden
mount /mnt/pve-nfs

Conseil : testez nconnect de manière progressive (1→2→4) et surveillez la CPU/les threads du serveur. Si le serveur NFS ne peut pas traiter efficacement les connexions supplémentaires, la latence augmente et les retransmissions peuvent s’accroître.

Tuning iSCSI : timeouts de session, replacement_timeout, Queue‑Depth

iSCSI propose de nombreux paramètres. Les domaines importants sont les timeouts de session (durée pendant laquelle un client attend un rebind), les queue‑depths (nombre d’I/O parallèles autorisés par chemin) et les stratégies de basculement Multipath.

# Beispiel: replacement_timeout anpassen
iscsiadm -m node -T iqn.example:lun1 -p 10.10.30.10 
  --op update -n node.session.timeo.replacement_timeout -v 120

# Login/Logout für Anwendung
iscsiadm -m node -T iqn.example:lun1 -p 10.10.30.10 --logout
iscsiadm -m node -T iqn.example:lun1 -p 10.10.30.10 --login

Explication : un replacement_timeout trop court peut provoquer des erreurs I/O lors de perturbations réseau de courte durée ; une valeur trop longue maintiendra les tâches bloquées plus longtemps. Testez les modifications avec une coupure de lien contrôlée.

Paramètres kernel et système qui aident fréquemment

Certains problèmes peuvent être atténués par du tuning via sysctl. Attention : les modifications doivent être testées et documentées.

# Beispiel sysctl Tuning (Beispiele testen!)
net.core.netdev_max_backlog = 3000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
vm.swappiness = 10

# Anwenden
sysctl -p

Ces paramètres augmentent les buffers réseau et réduisent le swapping. Pour les clusters de production : n’utiliser qu’avec monitoring et un cycle de tests.

Benchmarking : scénarios fio pour une mesure objective

Avant et après toute modification, exécutez des benchmarks reproductibles. Utilisez fio pour simuler des charges typiques de VM (p. ex. 4k random read/write, mixes, gros jobs séquentiels).

# Beispiel fio Jobfile: 4k Random Read/Write für 60s
[global]
ioengine=libaio
direct=1
runtime=60
time_based
group_reporting

[randrw]
bs=4k
rw=randrw
rwmixread=70
numjobs=8
iodepth=64
filename=/dev/mapper/mpath-data

# Ausführen
fio job.fio

Interprétez les latences p50/p99. Concentrez‑vous sur les valeurs p99 (latences en queue), pas seulement sur les moyennes.

Simulation de panne : provoquer des défaillances de manière contrôlée

Un Link‑Drop planifié ou un redémarrage du target montre le comportement réel. Exemple : désactiver brièvement un port de switch de stockage pendant l’exécution de fio et observer.

# Auf dem Host: Port kurz abschalten (nur in Testumgebung)
ip link set dev eth2 down
sleep 5
ip link set dev eth2 up

# Beobachten
dmesg -T | tail -n 50
multipath -ll
journalctl -u multipathd --since "5 minutes ago"

Surveillez si les chemins Multipath sont réactivés ou si les I/O échouent de façon durable. Notez les fenêtres temporelles pour le basculement et la récupération.

Supervision et alertes : ce qu’il faut absolument surveiller

Pour l’exploitation opérationnelle, les métriques suivantes sont essentielles :

• Latences bloc (r_await/w_await), longueur de la file d’attente (avgqu‑sz)
• IOPS et débit
• Retransmissions réseau, erreurs de lien
• Statut Multipath (dead/alive paths)
• Threads du serveur NFS et charge

Implémentez ces métriques dans Prometheus/Grafana ou votre stack de monitoring. Les alertes doivent réagir sur la latence p99, le taux de retransmissions et la perte de chemins, pas seulement sur la bande passante.

Sécurité et cohérence : brèves remarques

Pour iSCSI, utilisez CHAP (Challenge‑Handshake Authentication Protocol) pour l’authentification. Pour NFS, envisagez Kerberos (sec=krb5) pour les données sensibles. Attention : les mécanismes d’authentification peuvent ajouter de la latence et doivent être pris en compte dans les tests.

Pièges courants et comment les éviter

• Référence à /dev/sdX au lieu de /dev/mapper/mpath* : perte de la redondance de chemin.
• nconnect sans capacité serveur : augmenter le nombre de connexions TCP accroît la charge CPU côté serveur.
• Montages en mode soft sur disques VM : entraînent des interruptions I/O et des problèmes d’intégrité des données.
• Jumbo Frames appliqués seulement partiellement : fragmentation, erreurs et retransmissions accrues.
• Modifications du scheduler sans analyse : peuvent détériorer les latences p99.

Checklist concrète avant les modifications

1. Collecter la baseline : iostat, ss, multipath, dmesg.
2. Sauvegarder les fichiers de configuration : /etc/fstab, /etc/multipath.conf, /etc/iscsi/*, /etc/pve/storage.cfg.
3. Tester les modifications sur un hôte, effectuer une simulation de panne.
4. Documenter les changements, disposer de procédures de rollback écrites.
5. Après le déploiement, valider avec fio et une charge de production.

Conclusion et guide d’action

Le tuning de performance Proxmox iSCSI NFS implique de considérer l’hôte, le réseau et le target comme une unité. Commencez par des mesures, implémentez progressivement des changements à faible risque (nconnect, noatime, corrections Multipath), réalisez des tests d’incident contrôlés et documentez les procédures de retour en arrière. Concentrez‑vous sur les latences en queue (p99) et pas seulement sur les valeurs moyennes : c’est déterminant en production pour les temps de réponse et l’expérience utilisateur.

Méthodologie : mesurer → ajuster → tester → déployer. Et : n’appliquez des changements en production qu’avec une stratégie de retour éprouvée. Ainsi, les timeouts deviennent prévisibles et la performance du stockage stable.

Proxmox iSCSI NFS Performance Tuning: Architektur‑ und Betriebsrisiken

En plus de paramètres tels que nconnect ou replacement_timeout, il existe des risques architecturaux souvent négligés lors d’optimisations de performance. Ils concernent les cycles de sauvegarde/instantanés, le thin provisioning, les caches et le type d’émulation de disque de la VM. Pour les décideurs et les exploitants, il est important de comprendre comment ces couches interagissent afin que des changements n’apportent pas de gains à court terme mais entraînent à long terme instabilité ou perte de données.

Instantanés, sauvegardes et tempête d’E/S

Les instantanés (LVM‑thin, ZFS, Array‑Snapshots) peuvent provoquer des pics d’écriture importants lors de la consolidation ou de la création. Les logiciels métier avec de nombreux petits writes montrent alors des latences p99 élevées. Planifiez les fenêtres de sauvegarde en dehors des périodes de charge maximale, limitez les jobs d’instantanés parallèles et surveillez l’occupation du thinpool.

# Thinpool‑Nutzung prüfen (Hosts)
lvs -o+seg_monitor,metadata_percent,data_percent --units m

Fragmentation du thin pool et métadonnées

Une région de métadonnées du thin‑pool pleine ou fragmentée entraîne une dégradation soudaine des performances. Des seuils d’alerte pour metadata_percent doivent être intégrés à votre monitoring (p. ex. Prometheus) ; les shrinks automatiques sont risqués — conservez de la capacité PV libre et des plans de RESTauration détaillés.

Modes de cache, sécurité des données et performance

Proxmox/QEMU propose des options de cache (none, writeback, writethrough). „writeback“ offre souvent les meilleures latences, mais augmente le risque en cas de coupure secteur si les backends de stockage n’ont pas de cache d’écriture persistant (Battery‑Backed Unit/BBU ou NVRAM). „cache=none“ évite les effets de HOST‑CACHING et est souvent plus stable avec iSCSI/Multi‑Path.

# VM‑Konfiguration prüfen
cat /etc/pve/qemu-server/101.conf | grep -E 'scsi|cache'
# Beispiel: scsi0: local-lvm:vm-101-disk-0,size=32G
# cache: writeback

Type de contrôleur et comportement du multipath

Virtio‑SCSI offre souvent un meilleur support fonctionnel pour le multipath que virtio‑blk. Si vos LUNs sont accessibles via Multipath, testez la migration et le basculement avec Virtio‑SCSI, sinon vous risquez que des changements de chemin bloquent les E/S dans la VM.

Déduplication, compression et alignement

La déduplication ou la compression côté array peut dégrader le débit pour des workloads séquentiels et augmenter les latences de queue. Veillez à l’alignement des LUN et à la prise en charge éventuelle de TRIM/DISCARD ; des DISCARDs non planifiés peuvent fragmenter les thinpools.

Exploitation, déploiement et gestion de compatibilité

Effectuez les mises à jour du kernel, du multipath et du client iSCSI dans un groupe canary. Documentez une stratégie de retour claire, p. ex. :

• Rollback der Konfigurationsdatei aus /etc/pve und /etc/multipath.conf
• Déconnexion d’une cible iSCSI pour vérification :

iscsiadm -m node -T iqn.example:lun1 -p 10.10.30.10 --logout

Check‑liste opérationnelle pratique

• Surveillance : latence p99, metadata_percent, état des chemins multipath, retransmissions NFS.
• Test : simuler la consolidation d’instantanés et les jobs de sauvegarde sous charge.
• Déploiement : changements par groupe canary, rollback documenté et fenêtres de maintenance.
• Gouvernance : coordination avec les responsables applicatifs (logiciel métier sur mesure) — les profils d’I/O varient.

Intégrez ces aspects architecturaux tôt : ils empêchent que des gains rapides issus d’optimisations ne débouchent plus tard sur des incidents d’exploitation critiques et des pics de latence imprévisibles. Un processus de test et de release coordonné est souvent plus efficace que le tuning isolé des paramètres.

Pour ce sujet, les timeouts de stockage Proxmox et les options de montage NFS pour Proxmox sont également importants. L’article met ces aspects en perspective de manière claire et montre ce qui compte au quotidien.