PowerFlex: Datenintegritätsprobleme beim Upgrade des Betriebssystems ohne Upgrade von DasCache

Beispiel

• DasCache ist ordnungsgemäß konfiguriert (mit /dev/disk-by-id).
• SDS befand sich im Wartungsmodus, bevor der Befehl yum für das Upgrade des Betriebssystems verwendet wurde. Nach dem Upgrade des Betriebssystems wurde der Wartungsmodus "SDS beenden" verwendet. Kurz darauf beginnt die Anwendung, Dateninkonsistenzen (DI) zu melden.
• In diesem speziellen Fall wurden zwei SDS-Betriebssysteme aktualisiert, jedoch kann ein einzelnes SDS-Betriebssystemupgrade das Problem ebenfalls auslösen.

Hinweis: Nach dem Upgrade des SDS-Betriebssystems konnte der DasCache-Dienst aus irgendeinem Grund (wird noch untersucht) nicht gestartet werden. Der SDS-Dienst wurde erfolgreich ohne den DasCache gestartet, obwohl die Festplattengeräte/der SDS fehlschlagen sollten und der Dienst zum Schutz der Daten nicht gestartet werden sollte.

 

Problem

Vor dem BS-Upgrade lautete die SDS-DasCache-Version:

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

SDS wechselte in den Wartungsmodus, um das Betriebssystem zu aktualisieren:

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;

Das SDS-Betriebssystemupgrade von RH 7.2 auf RH 7.6 wurde mithilfe von yum update durchgeführt:
 

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

Der SDS-Server wurde neu gestartet, aber der DasCache-Service konnte nicht gestartet werden:

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

Nach dem Betriebssystemupgrade hatte die SDS-DasCache-Version immer noch dieselbe Version, da der DasCache nicht aktualisiert wurde:
 

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

Hinweis: Aus einem unbekannten Grund (wird noch untersucht) wurde der SDS-Service erfolgreich gestartet, obwohl die SDS-/Festplattengeräte hätten fehlschlagen müssen. Sobald der SDS den Wartungsmodus verlässt, sollte ab diesem Zeitpunkt ein DI gemeldet werden.

SDS beendet den Wartungsmodus:
 

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. 

Kurz nachdem der SDS den Wartungsmodus beendet hat, beginnt die Anwendung (in diesem Fall VMware-Datenspeicher und -VMs) über DI zu berichten:

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.

Auswirkungen

DI/DL
 

Ursache

Wenn DasCache mit PowerFlex verwendet wird, werden die Festplattengeräte dem SDS mit einer weiteren Schicht zur Verfügung gestellt, d. h. der SDS liest/schreibt Lese-/Schreibvorgänge in den DasCache und später werden die Daten auf die Festplattengeräte geleert.

Wenn der DasCache-Service nicht gestartet werden kann, schlägt der SDS standardmäßig die Laufwerksgeräte fehl, um die Daten auf den Laufwerksgeräten zu schützen. Auf diese Weise kann der SDS NICHT direkt auf die Laufwerke zugreifen.  

In diesem Fall wurde das SDS-Betriebssystem aktualisiert, jedoch wurde das DasCache-Paket nicht aktualisiert, was dazu führte, dass der SDS-Dienst erfolgreich gestartet wurde und der DasCache umgangen wurde, sobald der SDS Daten direkt von der Festplatte gelesen/geschrieben hat. Es gab eine Lücke in den Daten, da DasCache nicht alle Daten auf die Festplattengeräte geleert hat, was schließlich zu DI führte.

Hinweis: Der Grund, warum der SDS-Service erfolgreich gestartet werden konnte, wird noch untersucht. 
 

Problemumgehung

Es gibt keine Problemumgehung für das Problem, wenn der SDS den Wartungsmodus bereits verlässt und sich der DasCache-Service in einem fehlerhaften Zustand befindet.

Für den Fall, dass das Betriebssystem aktualisiert wurde und sich SDS noch im Wartungsmodus befindet, gibt es zwei Möglichkeiten, eine DI zu vermeiden:

• 1. Starten Sie vom alten Kernel (in diesem Fall Version 3.10.0-327)
  2. Führen Sie ein Upgrade von DasCache durch, damit es der Kernel-Version entspricht, und starten Sie den SDS-Service neu, wie im folgenden Verfahren beschrieben: KB 000195110

Betroffene Versionen

Alle PowerFlex-Versionen
 

Behoben in Version

Nicht zutreffend – wird noch untersucht