PowerFlex：在不升级 DasCache 的情况下升级作系统时的数据完整性问题

情况说明

• DasCache 配置正确（使用 /dev/disk-by-id）。
• 在使用 yum 命令升级作系统之前，SDS 处于维护模式。作系统升级后，使用退出 SDS 维护模式，不久之后，应用程序开始报告数据不一致 （DI）。
• 在此特定情况下，升级了两个 SDS作系统，但是，单个 SDS作系统升级也可能触发该问题。

提醒：SDS作系统升级后，由于某种原因（仍在调查中），DasCache 服务无法启动，SDS 服务在没有 DasCache 的情况下成功启动，尽管它应该使磁盘设备/SDS 失败，并且该服务应该无法启动以保护数据。

 

症状

在作系统升级之前，SDS DasCache 版本为：

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

SDS 进入维护模式以升级作系统：

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;

使用 yum update 执行了从 RH 7.2 到 RH 7.6 的 SDS作系统升级：
 

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

SDS 服务器已重新启动，但 DasCache 服务无法启动：

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

作系统升级后，SDS DasCache 版本仍处于相同版本，因为 DasCache 未升级：
 

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

提醒：由于某种未知原因（仍在调查中），SDS 服务成功启动，尽管它应该已使 SDS/磁盘设备出现故障。从此时起，一旦 SDS 退出维护模式，就应报告 DI。

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. 

在 SDS 退出维护模式后不久，应用程序（在本例中为 VMware 数据存储区和虚拟机）开始报告 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.

影响

DI/DL
 

根本原因

当 DasCache 与 PowerFlex 配合使用时，磁盘设备将通过多一层公开给 SDS，这样，SDS 读/写到 DasCache，稍后数据将刷新到磁盘设备。

按照设计，当 DasCache 服务无法启动时，SDS 会使磁盘设备失败以保护磁盘设备上的数据，这样，SDS 将无法直接访问磁盘设备。  

在这种情况下，SDS作系统已升级，但 DasCache 软件包未升级，导致 SDS 服务成功启动并绕过 DasCache，一旦 SDS 直接从磁盘读取/写入数据，数据中就存在间隙，因为 DasCache 未将所有数据刷新到磁盘设备，最终导致 DI。

提醒：SDS 服务可以成功启动的原因仍在调查中。 
 

解决方法

如果 SDS 已退出维护模式，并且 DasCache 服务处于故障状态，则无法解决此问题。

如果作系统已升级，但 SDS 仍处于维护模式，有两个选项可避免 DI：

• 1. 从旧内核引导（在本例中为版本 3.10.0-327）
  2. 升级 DasCache 以匹配内核版本并重新启动 SDS 服务，如以下过程 KB 000195110中所述

受影响的版本

所有 PowerFlex 版本
 

已修复问题的版本

不适用 — 仍在调查中