PowerFlex: Problemas de integridade dos dados ao fazer upgrade do sistema operacional sem fazer upgrade do DasCache

Situação

• O DasCache está configurado corretamente (usando /dev/disk-by-id).
• O SDS estava no modo de manutenção antes de usar o comando yum para fazer upgrade do sistema operacional. Após o upgrade do SO, o modo de manutenção SDS de saída foi usado e, logo depois, o aplicativo começa a relatar a inconsistência de dados (DI).
• Nesse caso específico, dois SDS OSs foram atualizados, no entanto, um único upgrade do SDS OS também pode desencadear o problema.

Nota: Após o upgrade do SDS OS, o serviço DasCache falhou ao iniciar, por algum motivo (ainda sob investigação), o serviço SDS foi iniciado com sucesso sem o DasCache, embora deveria falhar nos dispositivos de disco/SDS e o serviço deveria falhar ao iniciar para proteger os dados.

 

Sintomas

Antes do upgrade do SO, a versão do SDS DasCache era:

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

O SDS entrou no modo de manutenção para fazer upgrade do sistema operacional:

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;

O upgrade do sistema operacional do SDS do RH 7.2 para o RH 7.6 foi realizado usando a atualização yum:
 

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

O servidor SDS foi reinicializado, mas o serviço DasCache falhou ao 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

Após o upgrade do SO, a versão do SDS DasCache ainda estava na mesma versão, pois o DasCache não recebeu upgrade:
 

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

Nota: Por algum motivo desconhecido (ainda sob investigação), o serviço SDS foi iniciado com sucesso, embora devesse ter falhado nos dispositivos SDS/disco. A partir desse ponto, assim que o SDS sair do modo de manutenção, uma DI deverá ser relatada.

Modo de manutenção de saída do 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. 

Logo após o modo de manutenção de saída do SDS, o aplicativo (neste caso, eram datastores VMware e VMs) começa a gerar relatórios na 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 raiz

Quando o DasCache está sendo usado com o PowerFlex, os dispositivos de disco são expostos ao SDS com mais uma camada, dessa forma, o SDS lê/grava no DasCache e, posteriormente, os dados são liberados para os dispositivos de disco.

Por padrão, quando o serviço DasCache falha ao iniciar, o SDS falha nos dispositivos de disco para proteger os dados nos dispositivos de disco, dessa forma, o SDS NÃO poderá acessar os dispositivos de disco diretamente.  

Nesse caso, o sistema operacional do SDS foi atualizado. No entanto, o pacote DasCache não foi atualizado, o que resultou na inicialização bem-sucedida do serviço SDS e, ao ignorar o DasCache, uma vez que o SDS estava lendo/gravando dados diretamente do disco, houve uma lacuna nos dados, pois o DasCache não liberou todos os dados para os dispositivos de disco, levando ao DI.

Nota: O motivo pelo qual o serviço SDS poderia iniciar com sucesso ainda está sendo investigado. 
 

Solução temporária

Não há solução temporária para o problema se o SDS já sair do modo de manutenção e o serviço DasCache estiver em estado de falha.

Caso o sistema operacional tenha sido atualizado e o SDS ainda esteja no modo de manutenção, há duas opções para evitar uma DI:

• 1. Inicialize a partir do kernel antigo (neste caso, versão 3.10.0-327)
  2. Faça upgrade do DasCache para corresponder à versão do kernel e reinicie o serviço SDS, conforme descrito no seguinte procedimento da KB 000195110

Versões afetadas

Todas as versões do PowerFlex
 

Correção feita na versão

N/A - ainda sob investigação