PowerFlex: Problemas de integridad de datos cuando se actualiza el SO sin actualizar DasCache

Situación

• DasCache está configurado correctamente (mediante /dev/disk-by-id).
• SDS estaba en modo de mantenimiento antes de usar el comando yum para actualizar el SO. Después de la actualización del SO, se utilizó exit SDS maintenance mode y, poco después, la aplicación comienza a informar sobre la incoherencia de datos (DI).
• En este caso específico, se actualizaron dos SO SDS; sin embargo, una sola actualización del SO SDS también podría desencadenar el problema.

Nota: Después de la actualización del sistema operativo SDS, el servicio DasCache no se inició, por algún motivo (aún en investigación), el servicio SDS se inició correctamente sin DasCache, a pesar de que se suponía que fallaría en los dispositivos de disco/SDS y el servicio no se iniciaría para proteger los datos.

 

Síntomas

Antes de la actualización del SO, la versión de DasCache de SDS era:

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

SDS ingresó al modo de mantenimiento para actualizar el SO:

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 actualización del SO SDS de RH 7.2 a RH 7.6 se realizó mediante 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

El servidor SDS se reinició, pero el servicio DasCache no se pudo iniciar:

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

Después de la actualización del sistema operativo, la versión de DasCache de SDS seguía siendo la misma, ya que DasCache no se actualizó:
 

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

Nota: Por algún motivo desconocido (aún en investigación), el servicio SDS se inició correctamente, aunque debería haber fallado en los dispositivos SDS/disco. A partir de este punto, una vez que el SDS salga del modo de mantenimiento, se debe informar una DI.

Modo de mantenimiento de salida del SDS:
 

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. 

Poco después del modo de mantenimiento de salida del SDS, la aplicación (en este caso, eran las VM y los almacenes de datos de VMware) comienza a informar sobre la 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.

Impacto

DI/DL
 

Causa principal

Cuando se utiliza DasCache con PowerFlex, los dispositivos de disco se exponen al SDS con una capa más, de esa manera, el SDS lee/escribe en el DasCache y, posteriormente, los datos se vacían en los dispositivos de disco.

Por diseño, cuando el servicio DasCache no se inicia, el SDS falla en los dispositivos de disco para proteger los datos en los dispositivos de disco; de esa manera, el SDS NO podrá acceder directamente a los dispositivos de disco.  

En este caso, el SO del SDS se actualizó; sin embargo, el paquete DasCache no se actualizó, lo que provocó que el servicio SDS se iniciara correctamente y omitiera el DasCache. Una vez que el SDS leía/escribía datos directamente desde el disco, había una brecha en los datos, ya que DasCache no había vaciado todos los datos a los dispositivos de disco, lo que finalmente conducía a la inserción de datos.

Nota: El motivo por el cual el servicio SDS pudo iniciarse correctamente aún se está investigando. 
 

Solución alternativa

No hay ninguna solución alternativa para el problema si el SDS ya sale del modo de mantenimiento y el servicio DasCache está en un estado fallido.

En caso de que el SO se haya actualizado y el SDS siga en modo de mantenimiento, hay dos opciones para evitar una DI:

• 1. Arranque desde el kernel anterior (en este caso, la versión 3.10.0-327)
  2. Actualice DasCache para que coincida con la versión del kernel y reinicie el servicio SDS, como se describe en el siguiente procedimiento de la base de conocimientos 000195110

Versiones afectadas

Todas las versiones de PowerFlex
 

Problema corregido en la versión

N/D - aún en investigación