PowerFlex : Une commutation excessive des rôles des données provoque une latence et des erreurs d’E/S

Dans certaines transitions d’état du cluster, la logique d’équilibrage des rôles du MDM peut produire des basculements de rôles primaires/secondaires rapides et répétés sur de nombreux combs (structures de données internes qui suivent quels nœuds SDS stockent chaque élément de données de volume). Chaque changement de rôle invalide les mappages en peigne côté client (SDC) et force de nouvelles tentatives d’E/S. Lorsque suffisamment de combs sont affectés simultanément, la surcharge de nouvelles tentatives cumulée provoque des pics de latence d’E/S et des erreurs d’E/S sur les hôtes SDC. En fonction de l’environnement hôte, cela peut entraîner des délais d’expiration des E/S d’application, l’entrée des machines virtuelles en lecture seule ou une indisponibilité du système de fichiers.

Ce comportement a été observé dans plusieurs scénarios de déclenchement et ne se limite pas à une procédure opérationnelle unique.

Indicateurs communs

• MDM_DATA_DEGRADED événement suivi d’une latence d’E/S soutenue d’une durée de 1 à 15+ minutes
• Les hôtes SDC signalent des erreurs d’E/S et/ou des expirations d’E/S pendant la fenêtre dégradée
  • VMware (ESXi) : Délais d’expiration de pulsation VMFS, erreurs matérielles SCSI (sense data: 0x4 0x0 0x0), machines virtuelles passant en lecture seule, basculement HA potentiel
  • Linux : Erreurs d’E/S dans les journaux système (/var/log/messages, dmesg), les applications peuvent subir des délais d’expiration d’E/S ou un remontage du système de fichiers en lecture seule
• Les journaux d’événements MDM affichent le système dans l’état DEGRADED plus longtemps que prévu pour une perte de SDS unique
• Le système finit par se rétablir automatiquement à l’état NORMAL sans intervention manuelle (généralement)

Scénario 1 : Perte de SDS anormale (mode sans maintenance)

Quand cela peut se produire :

• Il s’agit d’un scénario rare. Pour que les événements rapides et répétés de changement de rôle se produisent lors d’une perte de SDS anormale, plusieurs conditions spécifiques doivent être réunies simultanément :

• • Environnement à grande échelle : nombre important de nœuds et de volumes SDS
  • Charge d’E/S de production importante : activité d’E/S importante au moment où le SDS échoue
  • La charge applicative de reconstruction dépasse la capacité de traitement : le nombre de lignes de métadonnées nécessitant une reconstruction dépasse la limite par cycle de l’équilibreur MDM de 1 024 lignes

Chaque cycle de rééquilibrage peut traiter jusqu’à 1 024 lignes de métadonnées. Lorsque d’autres lignes doivent être reconstruites, l’équilibreur ne peut pas terminer le plan en cours avant d’en générer un suivant.

Que se passe-t-il ?

• Le SDS se dissocie brusquement du MDM (événement SDS_DECOUPLED)
• Tous les SDC qui étaient connectés à ce SDS perdent leurs connexions → des événements de déconnexion SDC
• Le MDM marque le cluster comme DEGRADED (événement MDM_DATA_DEGRADED)
• Étant donné que le nombre de lignes à reconstruire est supérieur à 1 024, l’équilibreur MDM ne peut pas terminer le plan de rééquilibrage actuel
• L’équilibreur démarre un nouveau plan alors que le plan précédent est toujours en cours d’exécution, ce qui produit des événements de changement de rôle rapides et répétés
• Les SDC clients constatent des défaillances d’E/S continues (IO_FAULT_NOT_PRI, SCSI sense 0x4). Une fois le nombre de nouvelles tentatives atteint, le système d’exploitation hôte signale des erreurs d’E/S, des délais d’expiration ou un système de fichiers en lecture seule
• Preuves de trace MDM :

Lorsque la charge applicative de rééquilibrage dépasse la limite de 1 024 lignes, la trace MDM affiche le seuil franchi :

2026/03/28 22:43:53.246702 MED:7f1f984aedb0:balanceExec_HandleDegradedRows:00343: BALANCER: Storage Pool: 1193844800000000 - 1024 rows processed out of 1098 degraded rows. 0 allocation failures. 0 cumulative allocation failures.

Cela indique que 1 098 lignes ont besoin d’être reconstruites, mais seulement 1 024 ont pu être traitées dans le cycle actuel. Les lignes restantes déclenchent un nouveau plan de rééquilibrage avant la fin du plan précédent, ce qui déclenche une boucle de rétroaction.

Chaîne d’événements :

Log Source     Event / Pattern
MDM events     SDS_DECOUPLED — SDS formally declared dead
MDM events     MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces     Flood of IO_FAULT_NOT_PRI — SDS received IO for a comb it is no longer primary for
ESXi vmkernel  SCSI sense data: 0x4 0x0 0x0 — Hardware error
MDM events     MULTIPLE_SDC_CONNECTIVITY_CHANGES — Mass SDC connectivity storm
MDM events     SDC_DISCONNECTED_FROM_SDS_IP — SDCs losing contact with the failed SDS

SDC_DISCONNECTED_FROM_SDS_IP    SDC disconnected from SDS <name>
SDS_DECOUPLED                   SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

Scénario 2 : Mise hors tension du SDS lors de l’entrée dans le PMM

Quand cela peut se produire :
Il s’agit d’un scénario rare qui nécessite deux événements simultanés :

• Un SDS entre en mode de maintenance protégée (PMM)
• Le SDS échoue ou est mis hors tension avant la fin de la transition PMM

Que se passe-t-il ? 

• Le MDM reçoit la commande d’entrée PMM et l’enregistre comme réussie
• Le SDS se découple de manière inattendue alors que l’entrée PMM est toujours en cours
• Le MDM marque le cluster comme DÉGRADÉ.
• Le répartiteur de rôles entre dans une boucle de changement de rôle soutenue tout au long de la phase d’entrée du PMM
• Les lignes de données non-PMM font l’objet d’un changement de rôle répété sur l’ensemble du pool de stockage
• La tempête persiste jusqu’à ce que le SDS rejoigne le cluster et termine la transition du mode maintenance

Chaîne d’événements :

Log Source  Event / Pattern
MDM events  CLI_COMMAND_SUCCEEDED — enter_protected_maintenance_mode command succeeded
MDM events  SDS_DECOUPLED — SDS decoupled before maintenance mode started
MDM events  MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces  Repeated role-switch operations across non-PMM rows

Exemple de séquence d’événements MDM :

CLI_COMMAND_SUCCEEDED            Command enter_protected_maintenance_mode succeeded
SDS_DECOUPLED                    SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

Lorsque le SDS rejoint à nouveau et que le PMM termine :

SDS_MAINTENANCE_MODE_STARTED     SDS maintenance mode started
MDM_DATA_NORMAL                 The system is now in NORMAL state

Scénario 3 : SDS en mode de maintenance instantanée (IMM)

Quand cela peut se produire :
Un SDS entre ou sort du mode de maintenance instantanée (IMM). Ce scénario se produit lorsqu’un seul SDS est en mode maintenance et que le système ne peut pas décider quel SDS doit gérer les E/S pour des données spécifiques.

Que se passe-t-il ?

• Le système modifie à plusieurs reprises quel SDS est responsable du traitement des mêmes données
• En raison de ces changements constants, les applications ne savent plus où envoyer leurs demandes d’E/S
• Les E/S sont envoyées au mauvais SDS, ce qui entraîne de nouvelles tentatives et des retards
• Les applications subissent une latence ou des délais d’expiration lors des tentatives d’accès aux données affectées

Impact :

• Impact sur le client : Les applications signalent une latence et des délais d’expiration lorsque le SDS est en IMM
• Durée : Se poursuit tant que le SDS est à l’état IMM
• Récupération: Automatique : se résout lorsque le SDS quitte l’IMM

Chaîne d’événements :

Log Source  Event / Pattern
SDS traces  Repeated role-switch operations on the same data
SDS traces  Primary and secondary role switches on identical data

Scénario 4 : SDS quitte le mode de maintenance protégée (PMM)

Quand cela peut se produire :
Un SDS quitte le mode de maintenance protégée (PMM). Ce scénario se produit à chaque sortie du PMM. Ce n’est pas un événement rare, mais la gravité dépend de la durée du fonctionnement du mode maintenance.

Que se passe-t-il ?

• Lorsque le SDS quitte le PMM, le répartiteur de rôles doit réaffecter les segments de données pour inclure le SDS renvoyé
• Le processus de rééquilibrage affecte l’ensemble du pool de stockage, pas seulement les données sur le SDS qui renvoie
• Les changements de rôle se produisent sur de nombreux segments de données au cours de la réintégration
• Les applications peuvent rencontrer de brèves erreurs d’E/S ou de latence à mesure que les attributions de rôles se stabilisent

Impact :

• Impact sur le client : Pour de courtes fenêtres de maintenance (moins de 5 secondes), l’impact est à peine perceptible. Pour une maintenance prolongée avec des E/S actives, des milliers de commutateurs de rôle peuvent se produire, provoquant des blocages d’E/S soutenus
• Durée : Se poursuit pendant la phase de réintégration jusqu’à la fin du rééquilibrage
• Récupération: Automatique

Chaîne d’événements :

Log Source  Event / Pattern
MDM events  Role-switch operations across the storage pool during exit
SDS traces  Repeated role-switch operations during reintegration

Exemple de séquence d’événements MDM :

SDS_MAINTENANCE_MODE_EXIT_STARTED    SDS maintenance mode exit started
SDS_MAINTENANCE_MODE_EXIT_COMPLETED   SDS maintenance mode exit completed

Sorties des journaux :
 

Journaux d’événements MDM : Le journal des événements MDM affiche la séquence au niveau du cluster. Les indicateurs clés sont les opérations de changement de rôle lors de la sortie du mode maintenance.

Journaux de suivi SDS : Sur les nœuds SDS, les journaux de suivi affichent des opérations répétées de changement de rôle lors de la réintégration :

raidComb_SetPriTgtGenNum: combId <id> combGenNum: cur <gen> new <gen>
contCmd_SetCombState: CombId <id> devId <id> PRI->SEC Switch roles
contCmd_SetCombState: CombId <id> devId <id> SEC->PRI Switch roles

Un volume élevé d’entrées de rôles de commutateur dans un court laps de temps (des milliers ou plus en quelques secondes) est l’indicateur définitif côté SDS de ce problème.

Journaux SDC/de l’hôte : Tentatives d’E/S SDC VMware (ESXi) affichant le peigne, le SDS cible et le code d’erreur :

vmkernel log
PowerFlex mapVolIO_Do_CK:1496 :Mit: <addr>. Retrying IO Type WRITE. Failed comb: <id>. SDS_ID <id>. Comb Gen <gen>. Head Gen <gen>.
PowerFlex mapVolIO_Do_CK:1510 :Mit: <addr>. Vol ID <id>. Last fault Status IO_FAULT_NOT_PRI(12). Retry count (1)

En cas de nouvelle tentative d’évacuation, des erreurs SCSI sont renvoyées : 

sense data: 0x4 0x0 0x0   -- SCSI Hardware Error

Conseil de diagnostic : Si vous voyez des erreurs d’E/S sur plusieurs nœuds SDS (pas seulement le nœud qui a eu un problème), cela peut indiquer une tempête de commutateurs de rôles plutôt qu’un comportement dégradé normal. Si les erreurs d’E/S sont isolées sur un seul SDS, il s’agit d’un comportement dégradé attendu.

Scénario 5 : Maintenance Mode Phase Transitions 

Quand cela peut se produire :
Lors de la transition, lorsqu’un SDS entre ou sort du mode maintenance (IMM ou PMM), l’état passe alors de normal à MM, ou de MM à normal.

Que se passe-t-il ?

• L’équilibreur de rôles redistribue les responsabilités en matière de données pour s’adapter au changement
• De brefs sursauts de basculement des rôles se produisent lorsque le système s’installe dans le nouvel arrangement
• Les applications peuvent connaître de brefs pics de latence pendant la transition

Impact :

• Impact sur le client : Pics de latence brefs d’une durée de quelques secondes à quelques minutes. Généralement inférieur aux seuils de délai d’expiration de l’application
• Durée : Dure quelques secondes à quelques minutes, puis s’installe
• Récupération: Automatique

Chaîne d’événements :

Log Source  Event / Pattern
SDS traces  Brief role-switch operations during phase transitions

Un défaut logiciel dans la logique d’équilibrage des rôles du MDM provoque une boucle de rétroaction lorsque le cluster passe à l’état en raison d’une perte SDS ou d’un fonctionnement en mode maintenance.

Dans certaines conditions, le MDM réaffecte à plusieurs reprises les nœuds SDS chargés de servir les E/S aux peignes concernés. Chaque réaffectation invalide la vue mise en cache du SDC de l’emplacement des données, ce qui force de nouvelles tentatives d’E/S. Lorsque de nombreux combs sont affectés simultanément, le volume de réaffectations dépasse la capacité des SDC à effectuer des mises à jour, ce qui entraîne des erreurs d’E/S persistantes sur plusieurs hôtes.

La tempête est généralement auto-limitante. Elle disparaît une fois le cluster stabilisé, mais la durée dépend de la taille du domaine de protection et de la charge d’E/S au moment de l’événement.

Ce problème est résolu dans PowerFlex Core version 4.5.6. Effectuez une mise à niveau vers cette version dès qu’elle sera disponible. Contactez le support Dell pour obtenir des informations sur la chronologie des versions.

Pour les opérations de maintenance planifiées :

• N’effectuez pas de cycle de mise sous tension ou ne redémarrez pas un SDS tant que le MDM n’est pas logé SDS_MAINTENANCE_MODE_STARTED. Vérifiez que le SDS est entièrement passé en mode maintenance avant de procéder à la maintenance physique.
• Surveillez les pics de latence lors de l’entrée ou de la sortie du mode maintenance.

Pour les pannes non planifiées du SDS :

• La tempête se limite d’elle-même et se résout généralement en quelques minutes, à mesure que le cluster se stabilise. Si le problème est observé, recueillez getinfo logs de tous les nœuds SDS du domaine de protection, à partir des MDM de tous les gestionnaires dès que possible après l’événement, et contactez le support Dell.

Dans les rares cas où le problème ne se résout pas de lui-même, la désactivation et la réactivation temporaires de la reconstruction peuvent permettre au MDM de se stabiliser :

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --disable_rebuild

# Patientez 5 à 10 secondes, puis activez la reconstruction : 

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --enable_rebuild