一文了解 SmartX 超融合硬盘健康检测机制与运维实践

磁盘故障是存储系统内最常见的问题之一， 需要在存储系统设计和日常运维管理中重点关注。

SmartX 超融合集群如何监测磁盘健康状况？

在实际使用时会为运维人员带来哪些帮助？

SmartX 售后技术经理张瑞松在视频中分享了 SmartX 集群硬盘健康检测机制和客户运维实践，希望能为有需求的读者提供参考。

以下为根据视频整理的文字内容。

我们这次分享的主题是“集群磁盘亚健康检测机制以及运维的最佳实践”。在集群管理界面上，有时会看到集群硬盘不健康或者亚健康的告警。为什么会出现这种情况？

我们知道，所有的硬盘都是消耗品，使用寿命是有限的。随着硬盘的持续使用，会出现各种各样的因素导致硬盘性能下降以及故障，因此需要我们被动地进行更换。根据已收集到的数据，一块正常硬盘在持续使用的情况下，出现故障的高峰期一般是在出厂后的第 1.5 年到第 3 年之间。

基于这种情况，SmartX 超融合产品增加了硬盘健康检查的功能。该功能自 SMTX OS 4.0.10 版本正式增加，欲了解功能特性，请阅读：怎样在“坏盘时刻”保持优雅。我们也会在下面进行详细解读。

1 SmartX 超融合集群硬盘健康检查功能

1.1 技术目标

• 系统可以主动并快速地探测、隔离异常硬盘并开始恢复数据，减少异常硬盘对用户系统的影响。
• 当检测到硬盘异常之后，发出报警并展示硬盘的状态，同时系统进行相应的处理：
  • 减少售后的现场等待时间、简化售后的处理操作。
  • 通过报警，明确展示硬盘的当前状态，提示用户在资源许可的情况下进行硬件替换操作。

1.2 实现方式

监测磁盘健康状态可通过三种方式实现。一是开源工具 S.M.A.R.T. 检测技术，二是 SmartX 自研的 disk-health 硬盘健康检查工具，三是 SmartX 超融合集群的数据巡检功能。

1.2.1 S.M.A.R.T.

S.M.A.R.T. 是一种使用比较广泛的磁盘分析检测技术，早在 90 年代末就基本普及到每一块硬盘（包括 IDE、SCSI），允许磁盘在运行的时候将自身的若干参数记录下来，包括型号、容量、温度、密度、扇区、寻道时间、传输、误码率等。硬盘开始运行后，部分参数会发生变化，若某一参数超过报警阈值，则说明硬盘接近损坏，此时硬盘虽然在工作，但已经变得不可靠了，随时可能出现故障。

部分参数值如下：

其中有几个重要参数：

另外，S.M.A.R.T. 会监控 SSD 剩余使用寿命，默认每 6 小时检查一次。

1.2.2 disk-health

SmartX 自研工具 disk-health 会根据硬盘的异常情况将其划分为不健康盘、亚健康盘、S.M.A.R.T. 自检不通过盘和寿命不足盘。

1）不健康盘

SmartX 分布式块存储 ZBS 内部根据 I/O 的实际返回情况自动探测，在发现如下 I/O 异常的场景会将硬盘标记为不健康盘：

• 坏盘：I/O 返回错误累积超过 100 次（SSD、HDD）或 checksum 错误累积超过 100 次（HDD）。
• 慢盘 I：发生过 I/O 错误且超时 30s（SSD、HDD）。

2）亚健康盘

亚健康盘指没有达到不健康盘程度，但依旧不健康的硬盘。

• 满足以下条件即会被判定为慢盘 II：通过监控硬盘最近 90s（6 * 15s）内的相关数据进行判断，两种类型的硬盘需在连续 6 个 15s 内分别同时满足以下条件：
  HDD
  • 平均延迟 > 3s。
  • IOPS < 50。
  • 读写速度 <= 50MiB/s。
    SSD
  • 平均延迟 > 500ms。
  • IOPS < 5000。
  • 读写速度 <= 150MiB/s。
• 满足以下条件也会被标记为亚健康盘（0 < IO error < 100）：对硬盘的读写出现错误（小于 100 次）、checksum 出现错误（小于 100 次）。

3）S.M.A.R.T. 自检不通过盘

smartctl 工具的相关参数显示硬盘自检结果不通过。

4）寿命不足盘

因硬盘寿命不足触发提示性告警，建议用户更换硬盘。

1.2.3 数据巡检

1）功能介绍

SmartX 超融合集群中的数据巡检功能可以主动探测硬盘静默损坏导致的数据不一致问题，并触发数据恢复，保护数据安全。

2）实现机制

首先，数据巡检会周期性检测副本的 Generation 信息。Generation 是块存储的数据版本号，初始状态为 0，每次数据块（extent）被写入数据都会触发 Generation 数值加 1，检测周期是 30 秒。由于采用两副本的机制，每隔 30 秒检会检测一下这两份数据的 Generation 信息是否一致，如果不一致，就认为 Generation 信息低的数据块可能是发生了预料外的状况，在这种情况下就会触发数据恢复，保证数据的一致性。

另外，数据巡检还会周期性检测副本的 checksum 信息。对集群写入的数据会同步生成 checksum 信息，用于在读取数据时进行校验。检测以磁盘为单位进行扫描，两个硬盘之间的扫描间隔为 5 分钟，扫描速率为 5MB/s、IOPS = 20，这样能够最大限度降低巡检对集群性能的影响，且同一时间只会对一个节点的一个硬盘进行检测，不会占用集群和节点上的更多的 l/O。

以上 Generation 校验和 checksum 校验互相独立，互不影响，以此来保证底层数据的完整性。

3）适用版本

数据巡检功能适用于 SMTX OS 4.0.11 及以上版本、SMTX OS 5.0.1 及以上版本、SMTX ZBS 5.0.0 及以上版本。

2 异常硬盘处理流程

接下来，跟大家介绍一下应该怎样处理出现问题的硬盘。

2.1 处理逻辑

当系统将一块磁盘定位为不健康盘后，会自动对其进行隔离，不会再往上写入数据，且会将盘上的数据全部迁移走，等完成隔离操作后，这块盘会被自动从系统里踢掉。

对于被判定为亚健康、 S.M.A.R.T. 检测不通过以及寿命不足的硬盘，这些盘只是对比正常硬盘而言性能没有那么好，并不是完全不可用。所以针对这种类型的硬盘，系统会发出相应的告警提示，然后由客户来评判是将这块盘立刻卸载，还是先保留一段时间。

上述不同硬盘异常场景均会触发告警，并且在告警信息中体现不同的异常状态分类。

下面分别介绍不健康盘和亚健康盘出现故障时的处理流程。

2.2 不健康盘处理流程

2.2.1 故障确认

通过 Web 管理界面（CloudTower）登录后，可以查看到不健康硬盘被自动卸载完成，处于未挂载状态。

点击“查看故障信息”，显示如下：

我们可以通过硬盘健康检测工具查看出现问题的原因：

• 在故障告警产生的对应节点上执行以下命令，查看 sdc 的状态。
  zbs-node show_disk_status sdc
  zbs-node show_disk_status /dev/sdc
• 使用 sdc 的序列号，在集群中任意一个节点上输入以下命令，查看 sdc 的状态。
  zbs-node show_disk_status -s PHYS826003JB480BGN

其中 S.M.A.R.T. 检测不通过，该项指标显示为 True，可以看到下方指标已经超过了默认的设置阈值 10，达到了 12，导致检测结果不通过。

zbs-node show_disk_status -s PHYS826003JB480BGN 输出字段含义如下：

也可以通过查看 Message 日志的形式查看问题。

2.2.2 更换流程

step 1 确认服务器 SN，定位物理服务器位置。

step 2 Web 界面（CloudTower）点亮磁盘，标记磁盘物理位置。

step 3 线下执行拔出故障盘，更换新硬盘。

step 4 Web UI 识别，点击挂载磁盘。

step 5 挂载用途：

a. HDD 选择挂载为“数据盘”，挂载时间通常约 11s 左右。

b. SSD 可选择挂载为“含元数据分区的的缓存盘”和“缓存盘”，按照默认挂载即可。“含元数据分区的缓存盘”需要重建软 RAID 1，挂载时间约 10min 左右；“缓存盘”挂载时间通常约 11s 左右。 

2.3 亚健康盘处理流程

通过 Web 管理界面（CloudTower）登录后，硬盘正常处于”挂载“状态；具体的故障原因，可点击“查看故障信息” 显示如下：

亚健康盘只是不符合预期性能的硬盘，因此并不会直接去对它进行卸载操作。

2.3.1 故障确认

流程和方法与不健康盘一致。

2.3.2 更换流程

step 1 确认服务器 SN。

step 2 磁盘卸载前，确认集群无数据恢复。

step 3 Web 界面（CloudTower）点击“卸载”。

step 4 硬盘卸载完成后，状态变更为”未挂载“（卸载时间和硬盘上数据多少有关）。如果计划换盘，建议提前点击卸载硬盘，等到卸载完成以后，再到机房现场进行更换。

step 5 Web 界面（CloudTower）点击”闪灯“， 标记物理磁盘位置。

step 6 线下更换故障盘，插入新硬盘。

step 7 Web 界面（CloudTower），点击”挂载“磁盘。

step 8 挂载用途：

a. HDD 选择挂载为”数据盘“，挂载时间通常约 11s 左右。

b. SSD 可选择挂载为”含元数据分区的缓存盘“ 和”缓存盘“，按照默认挂载即可。”含元数据分区的缓存盘“ 需要重建软 RAID 1， 挂载时间约 10 min 左右；”缓存盘“，挂载时间通常约 11s 左右。

3 disk-health 局限性

首先，disk-health 只是基于系统内 I/O 去检测硬盘是否健康，无法判断是否因为 HBA 卡导致了故障。如果 HBA 卡出现故障，可能导致 HBA 卡及 HBA 卡下面的所有硬盘在接触 I/O 时都会被标记为亚健康或不健康，出现误判现象。

因此如果遇到一个节点上多块硬盘出现问题，建议先联系一下 SmartX 工程师，由工程师协助定位。或者直接联系硬件报修，检查一下 RAID 卡是否出现了问题。

另外，由于我们的集群采用两副本机制，写数据时一份数据写到本地，另一份数据写到另一个节点上。如果因为网络异常导致节点存储链路异常，可能也会增加对应的 l/O error。这种情况可能也需要进行单独排查。

某些软件因素也会导致硬盘无法正常读写，这种情况虽然不属于硬盘故障，但会增加 I/O error 的计数。

总之，如果遇到了类似的硬盘告警提示，建议使用前面提供的命令，通过后台进行相关调查、辅助确认。

4 硬盘故障运维实践

4.1 背景

某客户数据中心集群在一周内收到 17 块数据盘出现亚健康或不健康的告警，涉及 3 套集群。截至集群问题正式处理完成，累计故障硬盘 74 块，涉及 7 套集群。

在故障发生一周内，由于硬盘持续出现亚健康和不健康告警，并非短时间内大量硬盘同时故障，因此亚健康和故障硬盘的告警会自动触发数据迁移操作，避免业务数据的损失。同时由于硬盘故障所在集群有足够的磁盘空间冗余，可以安全快速地实现故障磁盘数据的迁移和平衡，因此没有发生节点级别或集群级别的故障，也没有造成数据损失，对生产无任何影响。

4.2 故障确认

step 1 使用亚健康硬盘检测工具，发现某硬盘出现 I/O error。

step 2 看 Message 日志，确认 I/O error 出现原因：该硬盘在短时间内连续两次出现 medium error 的情况。

step 3 smartctl 工具查看对应的 error 日志，发现有对应的读 error 的情况，也有不正常写入延迟。

4.3 调研结果

我们将客户 17 块盘出现的问题进行收集整理，发现基本上大多数硬盘型号、固件相同，硬盘通电时间都在 1.9 年以上，故障原因以 medium error 为主。

我们把调查结果分享给客户，建议协调对应的硬件厂商和专门的硬盘厂商进行分析。

在硬盘分析时，发现其中一块硬盘磁头的脏污染特别严重，SEM 的成分分析显示磁头含有 Si 这种物质。硬盘的研发后线深入分析后反馈，碟片工艺在生产时会包含 Si 物质残留，属于正常情况。但是 Si 在低负载的情况下，会吸收空气里的水分而膨胀，导致硬盘上的盘面出现水汽沉积，形成糊状脏污，业务压力增加更容易造成头碟接触，污染磁头，影响磁头飞行高度，增加读写错误率。现场调研后发现，该服务器上的硬盘并没有插满，其中大概一到两个硬盘槽位上使用的是硬盘的占位符，后者对比实际的硬盘来说，会增加空气的流通面积，再叠加硬盘低负载的使用情况，更容易增加水汽沉积，一直到使用大约 1.9 年后，糊状污染真正开始影响硬盘的读写。

4.4 处理结果

最终客户跟硬件厂商协调，将这些故障节点上的所有硬盘进行了批量替换。为了保证客户节点上硬盘批量替换的效率，SmartX 配合客户提供了基于节点维度的硬盘批量更换方案，目前所有受影响服务器的硬盘已全部完成替换。

5 硬盘运维最佳实践建议

您还可以通过以下文章，了解更多 SmartX 超融合如何降低运维难度：

• 如何做到 IT 基础架构软硬件升级简单又不停机？
• 通过弹性副本恢复策略平衡数据恢复速度与业务 I/O 性能
• 不止弹性，更加灵活。一文了解 SmartX 超融合如何扩容
• 一文了解如何系统验证分布式存储可靠性
• 接管 K8s 部署运维，基础架构团队是否做好准备？| SmartX 趋势分享
• VMware 虚拟机向国产虚拟化平台迁移？一文了解 SMTX 迁移工具原理与实践
• 基于 Terraform 实现 SmartX 超融合“基础设施即代码”（附金融行业实践）
• SmartX 发布管理平台 CloudTower 2.0 版本

点击链接或扫描下方二维码，下载《SmartX 超融合技术原理与特性解析合集（含 VMware 对比详情）》，深入了解 SmartX 超融合对运维管理的支持功能特性。