PowerFlex : Problèmes d’intégrité des données lors de la mise à niveau du système d’exploitation sans mise à niveau de DasCache

Scénario

• DasCache est configuré correctement (à l’aide de /dev/disk-by-id).
• Le SDS était en mode maintenance avant d’utiliser la commande yum pour mettre à niveau le système d’exploitation. Après la mise à niveau du système d’exploitation, quittez le mode de maintenance SDS et, peu après, l’application commence à signaler l’incohérence des données (DI).
• Dans ce cas spécifique, deux systèmes d’exploitation SDS ont été mis à niveau, mais une seule mise à niveau du système d’exploitation SDS peut également déclencher le problème.

Remarque : Après la mise à niveau du système d’exploitation SDS, le service DasCache n’a pas pu démarrer, pour une raison quelconque (toujours à l’étude), le service SDS a démarré avec succès sans DasCache bien qu’il soit censé mettre en échec les périphériques de disque/SDS et que le service ne devrait pas démarrer afin de protéger les données.

 

Symptômes

Avant la mise à niveau du système d’exploitation, la version de DasCache du SDS était la suivante :

fiop-1.5.14.rel-R3_9_Win_Linux.41_3.10.0_327.el7.x86_64.x86_6

Le SDS est passé en mode maintenance pour mettre à niveau le système d’exploitation :

6457 2021-04-28 09:19:09.196 MDM_CLI_CONF_COMMAND_RECEIVED INFO Command enter_maintenance_mode received, User: 'admin'. [10252559] SDS: ID: 82c410860000000d;

La mise à niveau du système d’exploitation SDS de RH 7.2 vers RH 7.6 a été effectuée à l’aide de yum update :
 

Apr 28 10:28:16 redhat-cust-1 yum[351251]: Updated: libgcc-4.8.5-36.el7.x86_64
Apr 28 10:28:16 redhat-cust-1 yum[351251]: Updated: redhat-release-server-7.6-4.el7.x86_64
Apr 28 10:28:16 redhat-cust-1 yum[351251]: Installed: 1:grub2-common-2.02-0.76.el7.noarch
Apr 28 10:28:16 redhat-cust-1 yum[351251]: Updated: setup-2.8.71-10.el7.noarch
Apr 28 10:28:17 redhat-cust-1 yum[351251]: Updated: filesystem-3.2-25.el7.x86_64
Apr 28 10:28:17 redhat-cust-1 yum[351251]: Updated: 32:bind-license-9.9.4-72.el7.noarch
Apr 28 10:28:18 redhat-cust-1 yum[351251]: Installed: 1:grub2-pc-modules-2.02-0.76.el7.noarch
Apr 28 10:28:19 redhat-cust-1 yum[351251]: Updated: tzdata-2018e-3.el7.noarch
Apr 28 10:28:19 redhat-cust-1 yum[351251]: Updated: kbd-misc-1.15.5-15.el7.noarch
Apr 28 10:28:19 redhat-cust-1 yum[351251]: Updated: 1:quota-nls-4.01-17.el7.noarch
Apr 28 10:28:19 redhat-cust-1 yum[351251]: Updated: 1:emacs-filesystem-24.3-22.el7.noarch
Apr 28 10:28:20 redhat-cust-1 yum[351251]: Updated: ncurses-base-5.9-14.20130511.el7_4.noarch
Apr 28 10:28:20 redhat-cust-1 yum[351251]: Updated: nss-softokn-freebl-3.36.0-5.el7_5.x86_64
Apr 28 10:28:24 redhat-cust-1 yum[351251]: Updated: glibc-common-2.17-260.el7.x86_64

Le serveur SDS a été redémarré, mais le service DasCache n’a pas pu démarrer :

Apr 28 10:47:04 [localhost] fio.init: Starting Fio devices: Failed
Apr 28 10:47:04 [localhost] systemd: fio.service: main process exited, code=exited, status=4/NOPERMISSION
Apr 28 10:47:04 [localhost] systemd: Failed to start Block Driver Interface to Flashsoft Cache.
Apr 28 10:47:04 [localhost] systemd: Unit fio.service entered failed state.
Apr 28 10:47:04 [localhost] systemd: fio.service failed.

[root@Node]# fscli -l
Starting fio service failed

Après la mise à niveau du système d’exploitation, la version de DasCache SDS était toujours sur la même version, car DasCache n’était pas mis à niveau :
 

fiop-1.5.14.rel-R3_9_Win_Linux.41_3.10.0_327.el7.x86_64.x86_6

Remarque : Pour une raison inconnue (toujours en cours d’investigation), le service SDS a démarré avec succès, bien qu’il ait dû échouer pour les périphériques SDS/disque. À ce stade, une fois que le SDS quitte le mode maintenance, une DI doit être signalée.

SDS quitte le mode maintenance :
 

6507 2021-04-28 10:01:54.700 MDM_CLI_CONF_COMMAND_RECEIVED INFO Command exit_maintenance_mode received, User: 'admin'. [10303510] SDS: ID: 82c410860000000d;
6508 2021-04-28 10:01:54.740 CLI_COMMAND_SUCCEEDED INFO Command exit_maintenance_mode succeeded. [10303510] 
6509 2021-04-28 10:04:00.111 SDS_MAINTENANCE_MODE_ENDED INFO SDS 10.1.150.50-RedHat (ID 82c410860000000d) has exited maintenance mode. 

Peu de temps après que le SDS a quitté le mode maintenance, l’application (dans ce cas, il s’agissait de datastores et de machines virtuelles VMware) commence à générer des rapports sur DI :

2021-04-29T04:12:37.697Z cpu12:982259)WARNING: Res3: 4232: Volume 5e6bb636-01b03ca0-5350-246e96905870 ("DS_SQL_PD2PB_01") might be damaged on the disk. Resource cluster metadata corruption has been detected.

Impact

DI/DL
 

Cause

Lorsque DasCache est utilisé avec PowerFlex, les périphériques de disque sont exposés au SDS avec une couche supplémentaire, de sorte que le SDS lit/écrit dans le DasCache, et que les données soient ensuite vidées sur les périphériques de disque.

De par la conception, lorsque le service DasCache ne parvient pas à démarrer, le SDS ne parvient pas à protéger les données qu’ils contiennent. De cette façon, le SDS ne sera PAS en mesure d’accéder directement aux périphériques de disque.  

Dans ce cas, le système d’exploitation SDS a été mis à niveau, cependant, le package DasCache n’a pas été mis à niveau, ce qui a entraîné le démarrage réussi du service SDS et le contournement de DasCache, une fois que le SDS lisait/écrivait des données directement à partir du disque, il y avait un écart dans les données car DasCache n’a pas vidé toutes les données sur les périphériques de disque, ce qui a finalement conduit à DI.

Remarque : La raison pour laquelle le service SDS a pu démarrer avec succès fait toujours l’objet d’une enquête. 
 

Solution

Il n’existe aucune solution de contournement pour le problème si le SDS quitte déjà le mode maintenance et que le service DasCache est en état d’échec.

Si le système d’exploitation a été mis à niveau et que le SDS est toujours en mode maintenance, il existe deux options pour éviter une DI :

• 1. Démarrage à partir de l’ancien noyau (dans ce cas, la version 3.10.0-327)
  2. Mettez DasCache à niveau pour qu’il corresponde à la version du noyau et redémarrez le service SDS, comme décrit dans la procédure suivante KB 000195110

Versions affectées

Toutes les versions de PowerFlex
 

Problème résolu dans la version

S/O - toujours en cours d’enquête