华为与RAID2.0+

华为与RAID2.0+

今天和群友聊天的时候提到了他的一台阵列三天内挂了三块盘导致RAID彻底挂掉，想起来了许久之前搞过的一台华为存储，堪称奇迹。 废话不多讲，先上图感受一下。

只能说，相当震撼，虽然已经提前得知了108块盘里坏了24块（实际亮灯27块），但亲眼看到的时候还是感觉到极强的视觉冲击力。

下面细说说这个事

由于离职的时候已经将工作文件打包给了同事，这些包含客户信息的文件也都不存在我自己这里了，所以只能靠记忆和零散的聊天记录来描述了。

这台存储是S2600TC，根据产品文档的介绍采用了RAID 2.0+技术

• RAID2.0+底层虚拟化

  RAID2.0+底层虚拟化技术将物理硬盘空间划分为多个小粒度的数据块，基于数据块构建RAID组和实现资源管理，资源管理更加精细化。RAID2.0+底层虚拟化技术能够实现硬盘自动负载均衡，提升存储性能，提高存储空间利用率和数据重构速度，以及精细管理存储空间，是很多高级存储技术的实现基础。

现场这台存储业务已经offline，得亏是RAID2.0+，物理磁盘上再切逻辑Chunk再组CKG，在逻辑层面上实现冗余。跟现场用户一起吭哧吭哧的搬了三箱子备盘过去之后，就开始检查存储当前状态，DiskDomain001容量55.12TB，已分配52.54TB，健康状态为故障，规划HotSpare是2.58TB，Used Hot Spare是10.01TB，Domain看状态是系统朝数据池借了7.43TB的Chunk作为热备，覆盖了二十块坏盘的容量，下属Pool总容量46.7TB，已分配42TB，多数故障盘状态为Fault，少量为Pre-Fault，也就是说数据还有那么一点微小的可能性没受影响。

先排优先级，从日志里看哪些盘坏的最为严重，最为紧迫，死马当活马医的时候就是敢甩开手干，优先更换最危险的离线盘，例如那些已经彻底 Offline、出现大量读错误、系统日志显示无法读取或即将失败的盘。因为已经被系统标记为 Fault/Offline 的盘很难继续提供正常业务服务了，但并不意味着整个盘完全无法读取，系统会尝试从尚可读的扇区“抠”出数据来做重建，但如果这类盘在阵列管理界面或日志中显示大量不可恢复的 I/O 错误（硬读错、坏块），则说明它随时可能彻底瘫痪或已“读不动”数据了，留着它能用来恢复数据的数学期望也最低，换盘需求最为紧迫。

而且由于RAID2.0+的结构，每块物理盘会被切分成多个 Chunk，不同 Chunk 参与到不同 CKG 的 RAID 组中，如果某块故障盘的 Chunk 分布在大量 CKG 中，那么这块盘一旦彻底失效，就会导致更多 CKG 一起降级或丢失，风险更大，所以故障盘对整体的影响面越大，也越应该优先更换，以减少后续继续读盘时进一步出现读错、导致更多 CKG 不可用的风险。

列出故障盘清单，捋清楚优先级，在实验性的更换了一块硬盘之后，看console输出的数据是从从两块已经标记fault，状态为offline的盘，读了超过新盘物理容量的数据过来重建，看到这个情况的时候心里就大概有谱了，在机房地板上坐了一下午盯完三块硬盘的更换情况之后（确实太慢了，600G的盘，基本上一块要花掉一个半小时），算了算CKG的数量和所需时间，这台存储能不能正常上线就看那些Pre-Fault的盘能不能顶得住重建时的读写了，跟用户沟通说明情况之后开始教用户的现场工程师硬盘更换流程，告知更换顺序，离场。

后续得知，用户因硬盘更换重建所需的时间过长，放弃了此设备的恢复，从工程师的角度来讲这件事真的蛮可惜的，但从用户的角度来看，一台存储能放任坏到接近四分之一的盘，大约也不重要就是了。