Problèmes de performances d’écriture de PowerFlex
Summary: Après avoir effectué la maintenance du réseau, les performances d’écriture de certains SDS sont désormais médiocres.
Symptoms
Scénario
- Ce problème se produit après une opération de maintenance réseau sur les commutateurs en haut du rack (TOR), généralement un redémarrage des commutateurs.
- Les nœuds SDS utilisent une liaison LACP pour les réseaux de données.
- Seuls les nœuds SDS utilisant les commutateurs où la maintenance a été effectuée sont affectés.
- Les performances d’écriture peuvent atteindre des centaines de millisecondes pour un certain pool de stockage/disque physique.
- Les performances de lecture d’un même ensemble de SDS sont normales.
- Le « NET_LONG_RCV_GRP_PROCESS » dans le diag_counters.txt montre que les valeurs grimpent rapidement, tandis que la dernière fois qu’elles sont incrémentées reste basse.
Exemple :
Comp :: Counter :: Value :: ExtData :: Last Counted(Ms) NET :: NET_LONG_RCV_GRP_PROCESS :: 3756453 :: 0xffffffff :: 3120 NET :: NET_LONG_RCV_GRP_PROCESS :: 3825395 :: 0xffffffff :: 960 NET :: NET_LONG_RCV_GRP_PROCESS :: 3705906 :: 0xffffffff :: 1320 NET :: NET_LONG_RCV_GRP_PROCESS :: 4094919 :: 0xffffffff :: 1230 NET :: NET_LONG_RCV_GRP_PROCESS :: 3954725 :: 0xffffffff :: 1390 NET :: NET_LONG_RCV_GRP_PROCESS :: 3594178 :: 0xffffffff :: 420 NET :: NET_LONG_RCV_GRP_PROCESS :: 3702403 :: 0xffffffff :: 680 NET :: NET_LONG_RCV_GRP_PROCESS :: 3830299 :: 0xffffffff :: 510 NET :: NET_LONG_RCV_GRP_PROCESS :: 3491713 :: 0xffffffff :: 330 NET :: NET_LONG_RCV_GRP_PROCESS :: 4155343 :: 0xffffffff :: 690
Dans cet exemple, la valeur de la troisième colonne est élevée (et augmente si vous regardez en direct). La cinquième colonne indique la dernière fois qu’elle a été rencontrée, soit moins d’une seconde pour une bonne partie des SDS.
Dans un système PowerFlex sain, la troisième colonne ne sera pas comptabilisée et la cinquième colonne comptera, car la dernière fois que vous l’avez rencontrée augmente avec le temps.
Pour surveiller les compteurs en direct, les commandes suivantes peuvent être exécutées :
#Set la variable pour les SDS du domaine de protection concerné. Saisissez ici le nom approprié du disque physique.
pd=<PD_NAME>
#Set la variable pour le nombre de SDS dans le domaine de protection. Exécutez-le tel quel.
num=`scli --query_protection_domain --protection_domain_name $pd |grep Protection |awk '{print $16}'`
#login pour permettre à la dernière commande de fonctionner.
scli --login --username admin
#Watch le compteur approprié à partir de la commande « query_diag_counters » pour chaque SDS.
watch -d -n 1 "for x in \$(scli --query_all_sds | grep -A $num $pd | grep ID | awk '{print \$5}'); do echo \$x; scli --query_diag_counters | grep -A30 \$x | grep -Em1 '\$x|NET_LONG_RCV_GRP_PROCESS'; done"
Dans un système sain, attendez-vous à ce que la cinquième colonne compte régulièrement au fil du temps et que la troisième colonne soit statique. Si le temps de la cinquième colonne reste bas et que la troisième colonne compte à rebours, il s’agit d’un symptôme du problème.
Impact
Les performances d’écriture sont médiocres pour les clients.
Cause
Le « NET_LONG_RCV_GRP_PROCESS » suivi ci-dessus indique que l’envoi des données TCP à un SDS distant a pris plus de 1 s.
Ce retard peut se produire en raison d’une petite fenêtre initiale de congestion TCP après la maintenance du réseau et du fait que le paramètre de paquets OOO (Out of Order) n’est pas correctement défini dans le système d’exploitation. Cela empêche les sockets SDS de communiquer efficacement, ce qui entraîne de multiples retransmissions TCP et une réduction de la taille des segments. Cela crée une latence plus élevée sur les écritures, car cela n’affectera que le SDS vers les sockets SDS.
La latence de lecture n’est pas affectée, car les SDC (clients) communiquent avec un seul SDS par demande d’E/S en lecture et ne dépendent pas de la communication SDS à SDS TCP.
Resolution
Pour une solution de contournement immédiate, redémarrez le service SDS sur chaque nœud affecté. Utilisez le mode maintenance lors du redémarrage du processus SDS. Un « pkill sds » est suffisant une fois que le nœud est en maintenance.
Pour éviter que ce problème ne se reproduise à l’avenir, procédez comme suit :
- Appliquez les paramètres sysctl décrits dans cet article public de la base de connaissances :
Les nœuds Storage Data Server peuvent ne pas contenir de paramètres de réglage système corrects, ce qui peut entraîner des problèmes de performances
- Si vous utilisez RHEL/CentOS 7, mettez à jour la version du noyau du système d’exploitation sur les nœuds SDS vers « 3.10.0-1160.66.1 » ou une version ultérieure
Version concernée
PowerFlex 3.x
Problème résolu dans la version
RCM version 3.6.3.2 ou ultérieure
IC version 38.363.02 ou ultérieure