Le SDS PowerFlex se ferme les sockets sans problème réseau

Scénario
Le SDS signale que les sockets sont fermés par des processus distants (SDC, SDS, MDM) et qu’aucun événement d’arrêt de la carte NIC, aucune perte de trames ou perte de paquets n’a été observé. 

Symptômes
Le journal des événements signale une perte de connectivité SDS, un découplage ou une reconnexion : 

2017-11-11 16:52:12.101 SDS_RECONNECTED           INFO     	 SDS: xyz_d35 (ID 67211111110089) reconnected 
2017-11-11 16:52:13.690 MDM_DATA_FAILED           CRITICAL 	 The system is now in DATA FAILURE state. Some data is unavailable. 
2017-11-11 16:52:15.791 MDM_DATA_DEGRADED         ERROR    	 The system is now in DEGRADED state. 

Avant cela, nous voyons des erreurs comme les suivantes dans les traces SDS.

Le SDS a essayé d’envoyer, et il a fallu >1 seconde pour répondre :

11/11 16:52:04.527408 0x7ff0b19eaeb0:contNet_OscillationNotif:01720: Con 672cb111110099 - Oscillation of type 5 (RPC_LINGERED_1SEC) reported

Le socket avec un homologue a été fermé de l’autre côté en raison de leur manque de réception de nos keepalives de niveau inférieur d’envoi :

11/11 16:52:06.241105 0x7ff0b19e1eb0:contNet_OscillationNotif:01720: Con a71d2b5d00000078 - Oscillation of type 1 (SOCKET_DOWN) reported 

Voici un autre exemple de ce type :

11/11 16:52:06.241224 0x7ff0b19e1eb0:contNet_OscillationNotif:01720: Con a71d2b3c00000057 - Oscillation of type 2 (IO_ERROR) reported

Autres indicateurs :
Itérations
Le minuteur keepalive de mise en réseau de niveau inférieur de ScaleIO est mesuré en itérations, d’une durée de 100 millisecondes.

Le délai d’expiration MDM-SDS> est de 20 itérations, ou 2 s, tandis que le délai d’expiration keepalive MDM-MDM est de 3 itérations ou 300 ms.

Vingt itérations dépassées :

11/11 16:52:11.685281 0x7ff752d1beb0:netPath_IsKaNeeded:01858:  :: Connected Live CLIENT path 0x7ff6e2192a00 of portal 0x7ff6e2192900 net 0x7ff7480e1110 socket 210 inflights 0 didn't receive message for 20 iterations from 10.124.162.109:7072. Marking as down  

Sockets défaillants Ces traces d’empreintes indiquent quand les sockets se sont arrêtés :

11/11 16:52:09.787793 0x7ff752cf7eb0:tgtMgr_TgtOscCB:07696: Con 672cba7400000089 Network address 10.124.130.109 - Oscillation of type SOCKET_DOWN reported

11/11 16:52:11.685290 0x7ff752d1beb0:tgtMgr_TgtOscCB:07696: Con 672cba7400000089 Network address 10.124.162.109 - Oscillation of type RCV_KA_DISCONNECT reported
11/11 16:52:11.685308 0x7ff752cf7eb0:tgtMgr_TgtOscCB:07696: Con 672cba7400000089 Network address 10.124.162.109 - Oscillation of type SOCKET_DOWN reported

Cette impression indique que le dernier socket d’un SDS est tombé en panne et qu’il s’agit du point auquel le SDS est considéré comme déconnecté :

11/11 16:52:11.685319 0x7ff752cf7eb0:tgtMgr_TgtDisconnectCB:07818: Tgt: 672cba7400000089 ConId: 672cba7400000089

Le MDM émet une commande addmdm pour que le SDS se reconnecte. 

Défaillance d’E/S bloquée
Nous savons qu’IO_FAULT_BLOCKED se produit lorsque le SDS refuse les E/S, car il ne peut pas atteindre le MDM, mais ces informations sont incomplètes.

Le SDS envoie des connexions persistantes au MDM toutes les secondes, et si le MDM ne l’obtient pas pendant 5 s, le SDS est considéré comme ayant expiré et est marqué comme découplé.

Le MDM envoie au SDS un message « continuez à travailler » toutes les secondes. C’est lorsque le SDS ne reçoit pas ce message pendant 5 s qu’il refuse les E/S avec IO_FAULT_BLOCKED : 

11/11 16:52:12.007045 0x7ff0b0cdfeb0:ioh_NewRequest:05490: Write to comb f778038007f - Done rc is IO_FAULT_BLOCKED (Lba 6721528 8), volume 6e1a2f4a0000075d (dit)
11/11 16:52:12.008825 0x7ff0b0ec5eb0:ioh_NewRequest:05490: Write to comb f78803903fc - Done rc is IO_FAULT_BLOCKED (Lba 5031040 6), volume 6e1a2f4c0000075f (dit)
11/11 16:52:12.017262 0x7ff0b26daeb0:ioh_NewRequest:05490: Write to comb f768037003e - Done rc is IO_FAULT_BLOCKED (Lba 15106144 16), volume 6e1a2f490000075c (dit)

Impact

Perte de connectivité SDS

À l’état data_degraded ou en mode de maintenance instantanée, cela peut entraîner une indisponibilité des données.

La cause de l’échec des E/S dans cet exemple est que le bail SDS (5 s) n’a pas expiré, mais que le délai d’expiration du réseau de niveau inférieur (2 s) a expiré.

La cause première est une ou plusieurs des raisons suivantes : 

1- Problèmes
de TCP/réseau A- Cela se manifestera probablement par des retransmissions TCP, ce qui indique des problèmes matériels/de configuration. (problèmes de câble, de carte NIC, de commutateur, etc.) comme on le voit dans la sortie de 

sar -n ETCP 1

Qui se présente comme suit :

 Linux 3.10.0-693.5.2.el7.x86_64 (SIO-DCOE-96O-3)        12/13/2017      _x86_64_        (48 CPU)

04:33:44 PM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s
04:33:45 PM      0.00      0.00     50.00      0.00      0.00
04:33:46 PM      2.00      0.00     75.00      0.00      0.00
04:33:47 PM      0.00      0.00    223.00      0.00      0.00
04:33:48 PM      0.00      0.00    106.00      0.00      0.00
04:33:49 PM      2.00      0.00     58.00      0.00      0.00
04:33:50 PM      0.00      0.00      5.00      0.00      0.00
04:33:51 PM      0.00      0.00      7.00      0.00      0.00
04:33:52 PM      2.00      0.00      2.00      0.00      0.00
04:33:53 PM      0.00      0.00      1.00      0.00      0.00
^C

04:33:53 PM      0.00      0.00      0.00      0.00      0.00
Average:         0.65      0.00     99.00      0.00      0.00

Références :

• Vert = un seul chiffre/s
• Jaune = haut à deux chiffres jusqu’à 50/s
• Rouge = >50/s

B-Dans le cas d’anciennes distributions Linux, telles que SusE 11 SP3 sur nos SVM, on peut surveiller les retransmissions réseau avec la commande suivante :

watch -d -n 2 "netstat -s |grep retrans"

Les résultats ci-dessous mettent en surbrillance les caractères qui ont été mis à jour au cours du dernier intervalle :

Every 2.0s: netstat -s |grep retrans                                                                                                                                                   Wed Dec 13 09:55:10 2017

    1244070 segments retransmited

2- Problèmes de processeur, manque de processus.
Cela se manifeste par une pause simultanée dans les traces de chaque composant SIO, avec de nombreuses sockets qui se ferment en tant que premières lignes de la trace lors de la reprise. 
Le fichier LIA, SDS, MDM/TB, SDC/messages montre l’écart.
La trace LIA, par exemple, affiche les sockets LIA→SDS qui se ferment après un délai d’expiration de 3 secondes (30 itérations x 100 ms) :

11/11 16:52:11.597227 0x7f44c41c6eb0:netPath_IsKaNeeded:01858:  :: Connected Live SERVER path 0x7f44c4195690 of portal 0x7f44c4192bb0 net 0x83b040 socket 8 inflights 0 didn't receive message for 30 iterations from 127.0.0.1:43228. Marking as down
11/11 16:52:12.031195 0x7f44c419eeb0:liaNet_DisconnectedNotif:01553: Con aed disconnected
11/11 16:52:12.158383 0x7f44c419eeb0:liaNet_ConnectedNotif:01483: Con aed  connected

3- Peut-être avons-nous un bug quelque part dans SIO. Il est probable qu’un thread non réseau retienne un processeur et ne permette pas à quelque chose d’autre de s’exécuter, etc.

Solution

Aucune solution de contournement générale

Versions concernées

Tous

Problème résolu dans la version

Sans objet