PowerFlex: Problemi di integrità dei dati durante l'aggiornamento del sistema operativo senza l'aggiornamento di DasCache

Scenario

• DasCache è configurato correttamente (usando /dev/disk-by-id).
• SDS era in modalità di manutenzione prima di utilizzare il comando yum per aggiornare il sistema operativo. Dopo l'aggiornamento del sistema operativo, è stata utilizzata la modalità di manutenzione SDS per uscire e, poco dopo, l'applicazione inizia a segnalare l'incoerenza dei dati (DI).
• In questo caso specifico, sono stati aggiornati due sistemi operativi SDS, tuttavia anche un singolo aggiornamento del sistema operativo SDS potrebbe attivare il problema.

Nota: Dopo l'aggiornamento del sistema operativo SDS, il servizio DasCache non si avvia, per qualche motivo (ancora in fase di analisi), il servizio SDS è stato avviato correttamente senza DasCache, anche se avrebbe dovuto fallire i dispositivi disco/SDS e il servizio non dovrebbe avviarsi per proteggere i dati.

 

Sintomi

Prima dell'aggiornamento del sistema operativo, la versione di SDS DasCache era:

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

L SDS è entrato in modalità di manutenzione per aggiornare il sistema operativo:

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;

L'aggiornamento del sistema operativo SDS da RH 7.2 a RH 7.6 è stato eseguito utilizzando 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

Il server SDS è stato riavviato, ma il servizio DasCache non è riuscito ad avviarsi:

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

Dopo l'aggiornamento del sistema operativo, la versione di SDS DasCache era ancora la stessa, in quanto DasCache non era stata aggiornata:
 

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

Nota: Per qualche ragione sconosciuta (ancora in fase di indagine) il servizio SDS è stato avviato correttamente, anche se avrebbe dovuto avere esito negativo sui dispositivi SDS/disco. Da questo punto in poi, una volta che l SDS esce dalla modalità di manutenzione, è necessario segnalare un'AIDI.

L SDS esce dalla modalità di manutenzione:
 

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 dopo l'uscita dell SDS dalla modalità di manutenzione, l'applicazione (in questo caso, i datastore VMware e le VM) inizia a segnalare l'input:

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.

Impatto

DI/DL
 

Root cause:

Quando DasCache viene utilizzato con PowerFlex, i dispositivi disco sono esposti all'SDS con un ulteriore livello, in questo modo l SDS legge/scrive su DasCache e successivamente i dati vengono scaricati sui dispositivi disco.

Per impostazione predefinita, quando il servizio DasCache non si avvia, l SDS impedisce ai dispositivi disco di proteggere i dati sui dispositivi disco, in questo modo l SDS NON sarà in grado di accedere direttamente ai dispositivi disco.  

In questo caso, il sistema operativo SDS è stato aggiornato, tuttavia, il pacchetto DasCache non è stato aggiornato, il servizio SDS si è avviato correttamente e bypassando DasCache, una volta che SDS stava leggendo/scrivendo i dati direttamente dal disco, si è verificato un divario nei dati poiché DasCache non ha scaricato tutti i dati sui dispositivi disco, causando infine DI.

Nota: Il motivo per cui il servizio SDS potrebbe essere avviato correttamente è ancora oggetto di indagine. 
 

Soluzione alternativa

Non esiste una soluzione alternativa per il problema se l SDS esce già dalla modalità di manutenzione e il servizio DasCache è in uno stato di errore.

Nel caso in cui il sistema operativo sia stato aggiornato e l SDS sia ancora in modalità di manutenzione, sono disponibili due opzioni per evitare un DI:

• 1. Eseguire l'avvio dal vecchio kernel (in questo caso, versione 3.10.0-327)
  2. Aggiornare DasCache in modo che corrisponda alla versione del kernel e riavviare il servizio SDS, come descritto nella seguente procedura 000195110

Versioni interessate

Tutte le versioni di PowerFlex
 

Risolto nella versione

N/A - ancora in fase di indagine