Cluster 2 Hôtes + Baie de Stockage ME5024

P

pascals07

New Member
Aug 11, 2025
13
1
3
Bonjour, dans notre infrastructure, nous avons deux hôtes connectés à une baie de stockage DELL ME5024.

La connexion s’effectue via iSCSI grâce à une carte Broadcom disposant de deux ports 25 Go.

L’installation date d’un an et, jusqu’ici, nous n’avions rencontré que quelques petits soucis de performance ponctuels.

Cependant, depuis quelques jours, nous observons des lenteurs importantes qui semblent liées au stockage.

Pour l’instant, nous n’arrivons pas à en déterminer la cause, ce qui est problématique, car lors des sauvegardes avec Veeam ou Proxmox Backup Server, les performances s’effondrent et les autres VM sont impactées. Je souhaite donc savoir si d’autres personnes ayant une configuration similaire ont déjà constaté ce type de problème.

Merci la communauté !
 
Bonjour, pas de perte de trames. Les métriques sont bien en dessous des seuils que peuvent encaisser les liens au stockage ...
 
Bonjour,


votre configuration m’a interpellé, car nous travaillons justement sur quelque chose d’assez proche : plusieurs nœuds Proxmox utilisant un stockage SAN partagé via iSCSI/FC.


Si vous cherchez également une solution pour utiliser du LVM-thin partagé dans un cluster Proxmox, avec notamment les snapshots, clones, migrations entre nœuds et HA, j’ai développé un plugin précisément pour ce type d’environnement.


Cela ne résoudra pas forcément le problème de performances que vous décrivez ici — il faudrait d’abord déterminer si le goulot d’étranglement vient de l’iSCSI, du multipath, de la baie ou de la charge générée par les sauvegardes — mais pour la partie stockage partagé du cluster, cela pourrait éventuellement vous être utile.


Le projet est open source :
https://github.com/delltech1/proxmox-sharedlvmthin


Votre environnement avec deux hôtes Proxmox et une ME5024 en iSCSI serait d’ailleurs un cas d’utilisation très intéressant.


N’hésitez pas à y jeter un œil si cela peut vous aider.
 
Merci pour le partage, on va d'abord finir de stabiliser notre souci actuel avant de regarder ça de plus près.
 
Avec plaisir ! Bon courage pour résoudre votre problème actuel. N’hésitez pas à revenir vers moi si vous décidez de tester le projet plus tard ou si vous avez des questions. Tout retour d’expérience sera le bienvenu.
 
Bonjour à tous,


Petit retour complet suite à plusieurs semaines d'investigation intensive sur ce sujet, ça pourra peut-être aider quelqu'un dans une config similaire.


Contexte : cluster Proxmox VE 2 nœuds, ME5024 en iSCSI direct-attach 25GbE (sans switch), Veeam + PBS pour les sauvegardes.


Ce qu'on a écarté :


  • Réseau/switch (hors du chemin, direct-attach)
  • Erreurs physiques sur les NIC (ethtool propre, 0 erreur/drop/CRC)
  • Multipath (fonctionnel, ALUA correct)
  • Défaut matériel côté ME5 (logs contrôleurs propres, confirmé par Dell)

Ce qu'on a trouvé et testé :


  1. Un fil quasi-identique sur ce forum décrit exactement notre pattern (conn error 1022, NOP timeout), avec une analyse PCAP poussée par un ingénieur Blockbridge : la queue SCSI atteint sa profondeur max, les complétions s'arrêtent ~10-12s, la fenêtre TCP de réception s'effondre — verdict : "ça ne ressemble pas au SAN", plutôt un comportement de la pile iSCSI/TCP/workqueue côté initiateur Linux. Toujours non résolu à ce jour sur ce fil.
  2. Dell a identifié une saturation du tier SSD (~95% plein) sur nos pools, avec recommandation d'affinité "Archive" pour réduire la pression — appliqué, en cours d'observation.
  3. Le format qcow2-on-LVM ("Snapshots as Volume-Chain", Tech Preview PVE9) semble avoir un coût de performance documenté (cf. l'article Blockbridge sur le sujet + un autre fil forum où désactiver les Volume-Chain snapshots a fait disparaître un stall similaire). On a reconverti plusieurs VMs en raw pour tester.
  4. Fait important découvert via le support Veeam : une VM qui migre entre nœuds (qm migrate) change potentiellement d'UUID Proxmox — pour Veeam ça équivaut à une nouvelle VM, donc perte du CBT et lecture complète au prochain backup. Si vous migrez souvent vos VMs (comme nous, en mitigation d'incident), ça peut expliquer des durées de backup anormalement longues sans rapport avec le stockage lui-même.
  5. Le fleecing Proxmox (tampon d'écriture local qui amortit les ralentissements du SAN pendant une capture) n'est configurable que via un job planifié ou en CLI (vzdump --fleecing) — pas via le bouton "Backup now" ponctuel sur une VM. Si vous faites des backups manuels sur des VMs en raw simple (sans snapshot), vous n'avez aucun tampon, donc toute latence du SAN se répercute directement sur l'invité.
  6. Un redémarrage complet des VMs (chez nous suite à une maintenance matérielle) réinitialise le CBT pour les disques RAW/VMDK (mais pas QCOW2, contrairement à ce qu'on pensait au départ) — donc une relecture complète massive du SAN au prochain backup, à prévoir/planifier.

Où on en est : toujours en cours d'investigation avec Dell et Proxmox support, mais le tableau se précise couche par couche. Pas de cause unique identifiée à ce stade, plutôt un ensemble de facteurs qui se cumulent.


@Francois_Baillargeon : pas de perte de trame confirmée par ethtool, métriques bien en dessous des seuils des liens 25G — donc pas un souci réseau classique de notre côté.


N'hésitez pas si vous avez des questions ou un cas similaire, ça m'aiderait aussi d'avoir d'autres retours !
 
  • Like
Reactions: Francois Baillargeon
pascals07 said:
Bonjour à tous,


Petit retour complet suite à plusieurs semaines d'investigation intensive sur ce sujet, ça pourra peut-être aider quelqu'un dans une config similaire.


Contexte : cluster Proxmox VE 2 nœuds, ME5024 en iSCSI direct-attach 25GbE (sans switch), Veeam + PBS pour les sauvegardes.


Ce qu'on a écarté :


  • Réseau/switch (hors du chemin, direct-attach)
  • Erreurs physiques sur les NIC (ethtool propre, 0 erreur/drop/CRC)
  • Multipath (fonctionnel, ALUA correct)
  • Défaut matériel côté ME5 (logs contrôleurs propres, confirmé par Dell)

Ce qu'on a trouvé et testé :


  1. Un fil quasi-identique sur ce forum décrit exactement notre pattern (conn error 1022, NOP timeout), avec une analyse PCAP poussée par un ingénieur Blockbridge : la queue SCSI atteint sa profondeur max, les complétions s'arrêtent ~10-12s, la fenêtre TCP de réception s'effondre — verdict : "ça ne ressemble pas au SAN", plutôt un comportement de la pile iSCSI/TCP/workqueue côté initiateur Linux. Toujours non résolu à ce jour sur ce fil.
  2. Dell a identifié une saturation du tier SSD (~95% plein) sur nos pools, avec recommandation d'affinité "Archive" pour réduire la pression — appliqué, en cours d'observation.
  3. Le format qcow2-on-LVM ("Snapshots as Volume-Chain", Tech Preview PVE9) semble avoir un coût de performance documenté (cf. l'article Blockbridge sur le sujet + un autre fil forum où désactiver les Volume-Chain snapshots a fait disparaître un stall similaire). On a reconverti plusieurs VMs en raw pour tester.
  4. Fait important découvert via le support Veeam : une VM qui migre entre nœuds (qm migrate) change potentiellement d'UUID Proxmox — pour Veeam ça équivaut à une nouvelle VM, donc perte du CBT et lecture complète au prochain backup. Si vous migrez souvent vos VMs (comme nous, en mitigation d'incident), ça peut expliquer des durées de backup anormalement longues sans rapport avec le stockage lui-même.
  5. Le fleecing Proxmox (tampon d'écriture local qui amortit les ralentissements du SAN pendant une capture) n'est configurable que via un job planifié ou en CLI (vzdump --fleecing) — pas via le bouton "Backup now" ponctuel sur une VM. Si vous faites des backups manuels sur des VMs en raw simple (sans snapshot), vous n'avez aucun tampon, donc toute latence du SAN se répercute directement sur l'invité.
  6. Un redémarrage complet des VMs (chez nous suite à une maintenance matérielle) réinitialise le CBT pour les disques RAW/VMDK (mais pas QCOW2, contrairement à ce qu'on pensait au départ) — donc une relecture complète massive du SAN au prochain backup, à prévoir/planifier.

Où on en est : toujours en cours d'investigation avec Dell et Proxmox support, mais le tableau se précise couche par couche. Pas de cause unique identifiée à ce stade, plutôt un ensemble de facteurs qui se cumulent.


@Francois_Baillargeon : pas de perte de trame confirmée par ethtool, métriques bien en dessous des seuils des liens 25G — donc pas un souci réseau classique de notre côté.


N'hésitez pas si vous avez des questions ou un cas similaire, ça m'aiderait aussi d'avoir d'autres retours !
Click to expand...
Des résumé comme ça on aime! Gros merci!!
 
You must log in or register to reply here.
Top Bottom
Back