PowerFlex 3.X : Les écritures lentes sur le disque du système d’exploitation peuvent provoquer plusieurs problèmes MDM.

Un certain nombre de scénarios peuvent se présenter en raison d’un disque de système d’exploitation lent sur un MDM.

Lorsque les MDM s’exécutent sur des disques du système d’exploitation qui prennent trop de temps à écrire, les symptômes suivants peuvent être observés :

• La mise en maintenance d’un SDS entraîne la déconnexion du MDM principal.

• Un événement de reconstruction entraîne la déconnexion du MDM maître et éventuellement des MDM esclaves.

• Le basculement MDM ne fonctionne pas ; Les MDM esclaves ne peuvent pas assumer les responsabilités du MDM maître et donc aucun MDM n’est maître.

• La sortie de « scli --query_cluster » indique que les MDM esclaves ne sont pas synchronisés occasionnellement.

• Erreurs d’E/S dans les écritures du SDC.

Dans tous les scénarios, le message « Harden took too long » s’affiche dans les logs trc MDM :

08/12 03:36:42.336327 0x7f64207f4eb0:replFile_WriteUnlocked:00667: WARNING: Harden took too long: 1360 ms
08/12 03:36:44.811987 0x7f6420668eb0:replFile_WriteUnlocked:00667: WARNING: Harden took too long: 1840 ms
08/12 03:36:46.463661 0x7f642072eeb0:replFile_WriteUnlocked:00667: WARNING: Harden took too long: 2210 ms

Impact

Si les écritures de référentiel du MDM dépassent le seuil de renforcement, le MDM n’est pas synchronisé.
Cela signifie que le cluster MDM n’est pas synchronisé et que les processus MDM redémarrent. 
Si les MDM redémarrent rapidement/de manière répétée, exécutez des scénarios d’indisponibilité des données (lorsqu’il n’y a aucun MDM principal disponible), comme dans le cluster MDM arrêté après des basculements répétés. 

Lorsque le MDM maître doit apporter des modifications à l’état des blocs de données, il doit écrire ces changements d’état dans le fichier de référentiel MDM, puis synchroniser ces modifications avec les MDM esclaves. Lorsque ces écritures sont terminées, le MDM informe les SDS que les modifications sont finalisées et qu’ils peuvent transmettre des E/S d’écriture aux SDC à partir de la copie primaire uniquement (jusqu’à ce que la reconstruction soit terminée). S’il faut plus de 500 millisecondes (1/2 seconde) au MDM maître pour écrire les modifications dans le référentiel local, les messages « Harden took too long » s’affichent dans les journaux trc du MDM. Cela empêche le MDM de répondre assez rapidement aux demandes des SDS et peut provoquer des erreurs d’E/S sur les SDC. Le MDM reste dans cet état jusqu’à ce que les E/S puissent écrire dans le référentiel en moins de 500 millisecondes ou après 10 secondes lorsqu’un changement de propriété MDM se produit au sein du cluster. 

La solution consiste à résoudre le problème de latence du disque du système d’exploitation.  

Cela peut être dû à :

• Reconstructions RAID (les nœuds Ready Nodes 14G disposent de cartes BOSS avec 2 disques SATA m.2 dans RAID1)

• Usure/âge du disque

• Dimensionnement/sélection incorrect des disques du système d’exploitation (disques durs, disques SSD lents/bon marché, etc., généralement uniquement dans les configurations logicielles uniquement)

• Bogues dans le contrôleur de disque/firmware de disque du système d’exploitation

• Panne de disque/état de panne prédictive 

• Mais la cause la plus fréquente est la charge d’E/S superflue sur le disque du système d’exploitation. 

Dans tous les cas, il est nécessaire de surveiller/profiler les performances du disque du système d’exploitation.

La latence du disque peut être surveillée par sar ou iostat. 

L’outil le plus simple et le plus universellement disponible est iostat. 

Exécutez 

iostat -xtN 1

Et observez les temps d’attente, signalés en millisecondes. 

Toutes les versions sont concernées.