华为与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的盘能不能顶得住重建时的读写了,跟用户沟通说明情况之后开始教用户的现场工程师硬盘更换流程,告知更换顺序,离场。
后续得知,用户因硬盘更换重建所需的时间过长,放弃了此设备的恢复,从工程师的角度来讲这件事真的蛮可惜的,但从用户的角度来看,一台存储能放任坏到接近四分之一的盘,大约也不重要就是了。