一起数据灾难谈RAID0+1及RAID1+0转载

简介:
本文转自: http://blog.51cto.com/sun510/1887314
近日,遇到一例4块盘SCSI RAID0+1的数据恢复,由4块36G SCSI组成。客户称是做了两组RAID1。出故障后,RAID状态里3块盘OFFLINE。
  按我的理解,这个应该是两组逻辑盘(分别做的RAID1),那即使是3块盘OFFLINE,也应该有一组逻辑盘是可以正常工作的。但客户用装在别的硬盘上的WINDOWS访问此阵列时,也无法识别阵列的逻辑盘。这样的话,很多就解释不通了,只能仔细分析了。
  拿下硬盘,单独接在SCSI适配器上,进入系统,无异常,可以识别出4块物理硬盘。分析,无明显RAID信息区域,之后,对4块盘做比较,结论是1、3号盘及2、4号盘每组都有相同性,但后面有大量不一致数据。1号盘及2号盘里有分区表,每个分区表里的描述都大约指出原逻辑盘分区总和大约68G。据此,可知有以下三种情况:
  1、两组RAID0,但1、3号及2、4号均有部分完全相同的数据,应该可以排除。
  2、RAID1+0(即两两做RAID1,再做RAID0,这种安全级别高,客户是集成商做的,可能性最大),一段时间内,两组RAID1中先后都有一块硬盘离线(此后就相当于RAID0,再不能提供任何冗余)。再后来,又有一块硬盘离线,系统崩溃。这种情况非常符合RAID里的表现。
  3、RAID0+1(即两两做RAID0,再做RAID1,这种不太好,推断可能性不大)
  根据分析后,发现除1、3组成的RAID,无任何错误,认为应该是对了。重组数据。直接写回RAID,系统正常可以启动。文件访问也正常。
  本来以为已经完美解决了。结果很短的时间内收到客户电话,称数据严重滞后,是两年前的东西。
  一细想,大悟。
  真实的情况应该是:用户做了RAID0+1,结果组成RAID1中的其中一组RAID0中有一块盘离线(应该为1或3),导致整个RAID0离线(两块离线了),之后一直以单RAID0的方式工作(想起来竟然两年有余,汗!),直到最近,剩下的一组RAID0中有一块盘离线,RAID彻底瘫痪。用户使用的RAID卡为ADAPTEC的0通道RAID卡,比较低端,无法安全缓冲数据,最后离线时,因数据部分未写入等原因导致文件系统一致性有问题。
  重新组织3及5号盘,修正错误,数据100%恢复成功。
  此案例中突显RAID0+1及RAID1+0的安全差别,细细说说吧。
  RAID0+1:
  结构为,两块以上(含两块)硬盘先做条带(RAID0),组成相同的两组一级逻辑盘。再将两组逻辑盘做镜像(RAID1)。如下图:
一起数据灾难谈RAID0+1及RAID1+0转载
  RAID0+1的冗余性(安全性):只要有一块盘出错,它所在的RAID0就会整体离线,只能靠最外层的RAID1的冗余来支撑。实际上,只能允许一块盘出错,这样如果在4块以上的硬盘盘阵中,安全性实际会差得多。
  利用率:1/2
  效率:读与写均可以实现N/2(N为硬盘总数)的理论带宽
  实现:容易,控制器无需强劲处理能力,通常也无需大缓冲。
  RAID1+0:
  结构为,两块以上硬盘先做镜像(RAID1),组成相同的两组或两组以上一级逻辑盘。再将两组(或两组以上)逻辑盘做条带(RAID0)。如下图:
一起数据灾难谈RAID0+1及RAID1+0转载
  RAID1+0的冗余性(安全性):只要有一块盘出错,它所在的RAID1中不会有问题,所以每组RAID1中都允许有一块盘离线。安全性:损坏两块盘崩溃的机会只有2/(N-1)。
  利用率:1/2
  效率:读与写均可以实现N/2(N为硬盘总数)的理论带宽
  实现:容易,控制器无需强劲处理能力,通常也无需大缓冲。

  上述分析,可以明显看到,RAID1+0比RAID0+1的安全级别会高很多,其他参数却相同。所以,需要安全级别高的场合下,一定要选择RAID1+0。实际上,RAID0+1是华而不实的结构,很少会有它的适用场合。本文提及的案例,如果用户使用的是RAID1+0,出故障的概率便会低得多了。
















本文转自lq201151CTO博客,原文链接:http://blog.51cto.com/liuqun/2044290 ,如需转载请自行联系原作者





相关文章
|
安全 架构师 编译器
鲲鹏开发重点-–扭转x86乾坤的挑战,ARM64内存模型
因为X86及其CISC架构生态的封闭性,中国市场对未来处理器的选择,将是更开放、更模块化的RISC架构。 鲲鹏处理器就是符合这个潮流的创新产品和生态,将直面一系列挑战,和Apple一样赢得这场挑战,来扭转X86的封闭性的乾坤,创造出中国的处理器新生态。
1544 0
鲲鹏开发重点-–扭转x86乾坤的挑战,ARM64内存模型
|
Java 开发者 Docker
五种常用的 Spring Boot 热部署方式
【2月更文挑战第5天】
4088 0
五种常用的 Spring Boot 热部署方式
|
4月前
|
监控 Linux C#
《C#与.NET Core跨平台开发的融合架构与实践逻辑》
本文深入解析了利用C#与.NET Core开发跨平台桌面应用的核心逻辑,探讨如何突破操作系统壁垒实现文件管理、图像处理和系统监控等功能的统一体验。阐述了.NET Core对不同系统底层差异的抽象与适配,包括文件系统规则的转化、图形硬件调用的平衡、系统内核信息的解读,以及C#语言特性在跨平台开发中的互补作用。强调跨平台开发需培养“系统无关”的抽象思维,通过技术融合实现功能逻辑与用户体验的跨平台一致性,重塑桌面应用的开发边界。
114 0
|
6月前
|
存储 缓存 数据可视化
HarmonyOS5云服务技术分享--云存储指南
本文详解HarmonyOS云存储实战技巧,涵盖文件上传、下载、元数据操作及删除等核心功能。通过简单易懂的示例代码,助你快速上手。云存储支持自动同步、精细权限管理与海量存储,适合处理用户头像、游戏存档等场景。文中还提供避坑指南、进阶技巧和最佳实践,帮助开发者高效利用云存储功能,减少开发障碍。附完整代码示例,欢迎交流!
|
新能源 测试技术 数据库
校园车辆管理系统的设计与实现(论文+源码)_kaic
校园车辆管理系统的设计与实现(论文+源码)_kaic
|
2天前
|
弹性计算 运维 搜索推荐
三翼鸟携手阿里云ECS g9i:智慧家庭场景的效能革命与未来生活新范式
三翼鸟是海尔智家旗下全球首个智慧家庭场景品牌,致力于提供覆盖衣、食、住、娱的一站式全场景解决方案。截至2025年,服务近1亿家庭,连接设备超5000万台。面对高并发、低延迟与稳定性挑战,全面升级为阿里云ECS g9i实例,实现连接能力提升40%、故障率下降90%、响应速度提升至120ms以内,成本降低20%,推动智慧家庭体验全面跃迁。
|
3天前
|
数据采集 人工智能 自然语言处理
3分钟采集134篇AI文章!深度解析如何通过云无影AgentBay实现25倍并发 + LlamaIndex智能推荐
结合阿里云无影 AgentBay 云端并发采集与 LlamaIndex 智能分析,3分钟高效抓取134篇 AI Agent 文章,实现 AI 推荐、智能问答与知识沉淀,打造从数据获取到价值提炼的完整闭环。
352 91