多副本和raid技术
传统技术局限
随着存储系统规模爆炸式增加，依赖硬件设备保障系统可靠性的传统理念遭遇到极大挑战。对PB级海量存储系统而言，单纯的硬件容错技术已经很难确保系统可靠性，而依靠文件系统实现的文件级容错又存在各类限制和不足，企业级用户亟待一种规范、平滑、可靠又经济的方式来支撑海量存储系统稳定性。web
RAID技术局限性
磁盘阵列中RAID技术的最大问题，在于重建时间窗口过长。据统计，2TB容量磁盘的RAID5重建时间通常在3-10天。也就是说，即便RAID5保护的系统中已经配置有冗余热备盘，数据仍然将不可避免的经历3-10天无冗余保护的危险期。在这段时间内，若是再有磁盘故障，不管是否有其余冗余热备盘，都将形成数据丢失系统停机。算法
此外，RAID技术要求磁盘规格严格统一，甚至要求磁盘firmware版本精确一致，不一样规格磁盘混用每每形成各类不可预期故障。然而现实环境中某型号规格磁盘的存市周期很是短，故障发生时每每很难采购到全新同规格磁盘。数据库
技术上RAID5和RAID6算法的写惩罚明显影响性能，因此磁盘阵列对RAID组磁盘数量都有严格限制，普通磁盘阵列RAID组上限为16颗磁盘，一些中高端磁盘阵列对磁盘数量的限制更严，只容许3+1或7+1的RAID5方式。这些限制都使RAID技术很难直接支持海量系统的扩展能力和灵活性。服务器
分布式文件系统局限性
近年来HDFS（Hadoop Distributed File System）、GFS（Google File System）、Ceph、MooseFS等处理海量数据的文件系统，均内嵌多重拷贝功能，以解决数据可靠性问题。可是，依赖文件系统多重拷贝机制又为系统带来不少新的障碍。分布式
首先，分布式文件系统不适合用于块级访问方式。当数据库等应用须要使用裸设备空间资源时，分布式文件系统不得不经过附加功能层，把文件仿真为裸设备。导致数据IO过程当中增长屡次格式转换，影响性能效率，徒增管理维护难度。svg
其次，分布式文件系统虽然提供POSIX兼容界面，但并不是全集实现，而是仅仅实现其中部分经常使用子集。应用使用这些文件系统提供的资源时，部署和维护工做须要大量专业人员深度介入，并且完整系统从实施到稳定工做的调试周期很长，某些大规模复杂系统的稳定周期甚至以年计算。oop
主流分布式文件系统均来源于开源项目，虽然其活跃度和技术开放性成就了许多定制化灵活性，但同时也带来了版本分支繁多、技术规范度难以保证、将来升级变化难以预期、技术支持有限等诸多问题。性能
容错池对比传统容错技术
智能容错池综合了RAID和分布式文件系统容错的优点，同时消除了传统技术的局限。容错引擎在后台自动复制多重数据副本，并实时监控副本状态。当部分数据离线时，智能容错池引擎能够利用空余空间及时恢复离线数据，从而保证存放在容错池中的数据一直保有足够的冗余度。
容错池实现机制
容错引擎在数据正常写入的过程当中，同步建立冗余副本，本章节将描述建立和维护数据副本的工做层次及其工做机制。大数据
引擎在IO路径中的位置
处理数据冗余的机制在Target端透明实现，Initiator端无需任何特殊驱动，仅以标准系统IO调用访问磁盘驱动，而SCSI-3指令也是经标准SAN协议发送请求和数据。
容错引擎所提供的虚拟磁盘界面与传统磁盘阵列使用方式彻底相同，能够经由任何SAN协议链接到主机服务器，而在主机端呈现的即为标准磁盘。任何操做系统和应用均能以使用普通磁盘的方式使用该虚拟磁盘。操作系统
存储池与虚拟磁盘
磁盘阵列中的空间资源由虚拟化存储网关统一管理，具体而言就是将磁盘阵列提供的LD（Logical Drive）添加入存储池。由存储池管理的LD被切割为多个片断，资源片断大小能够在4MB-512MB范围内任意设置。
存储池自己并不具容量概念，不是可访问的逻辑设备。用户须要在存储池中建立指定大小的VD（Virtual Disk），并将VD映射给主机Initiator端口。每个VD在主机中呈现的即为标准磁盘驱动器。
在动态池中建立的VD，其容量不受存储池实际资源空间的限制，能够在规定上限（目前版本为1PB）内任意指定空间大小。
在无冗余度设置即容错级别为0时，VD的可靠性依赖于存储池中全部LD的可靠性。任何一个LD离线，都有可能形成VD数据丢失或损坏。
冗余度级别
存储池中设置的冗余度级别，决定了数据块副本的数量，目前冗余度级别共分5级。最低的0级冗余表明不建立副本，而1级冗余表示仅建立一份副本……以此类推，最高的4级冗余系统中有4份原始数据块的副本，即连同原始数据块共有5份相同的数据。下图是1级冗余状况下的数据块分布示例。
由图示可见，每一个数据块在实际介质中均保存有两份，且这两份数据分散在不一样的LD中。任意一个LD离线时，全部数据块都可正常访问，VD中数据依然保持完整。
考虑到多个LD可能来自同一磁盘阵列设备，一台发生故障可能形成多个LD同时离线，为此容错池内还可选设置分组功能。用户能够将同一磁盘阵列提供的LD划分入同组，每一个组即对应一个磁盘阵列物理设备。当组信息存在时，容错池引擎会优先跨组间散列排布冗余数据块。
故障状态及修复机制
当故障发生时，VD的数据虽然不会丢失，但因为部分数据块副本离线，其冗余度会下降。以下图所示，当LD3发生故障离线时，部分数据块将处于无冗余保护状态。
健康监测引擎实时监测数据块冗余状态，当故障发生时，冗余度下降的数据块会被标注为更低的冗余度级别。在上图示例中，两个受到影响的数据块冗余级别由1级下降为0级。
故障修护引擎监测到实际冗余度级别低于其设定级别时，便当即启动修复过程，即在容错池中寻找空闲空间，并建立数据块副本，直至全部数据块都恢复到设定级别。若是容错池空闲空间不足，引擎会给出提示信息要求增长LD或扩展示有LD容量。新增容量就位时，未完成的修复工做当即从新开始。
全部故障修复彻底基于非日志机制，避免了引入新的逻辑故障点。
传统的存储仍是使用RAID方式，由于RAID方式很是成熟，也能够节省空间。好比RAID 5，利用率通常都在80%以上。若是采用多副本技术，空间的利用率就不是特别划算。但后来随着大数据的出现，不少分布式文件系统采用多副本方式，如HDFS通常就是采用3副本的冗余方式（也有不少NAS采用纠删码方式，这样利用率大大提升，是拿计算换容量的例子），所以文件级别的多副本流行起来。由于通常这种平台都是商用的存储服务器，存储成本比较低，直接采用多副本技术，在分布式处理、多数据中心容灾等互联网应用的场景下比传统RAID更合适，这是典型的采起空间换性能和可靠性的例子。信核科技的块级多副本技术，在高端存储里面也有相似的例子，好比IBM的XIV，就是一种块级2副本技术，只是这个副本数量不像信核同样能够选择。另外，前段时间，一个网友告诉我，国内有一个华云网际的FusionStor云存储采用的也是相似IBM XIV同样的块级2副本技术。听说这个产品H3C都OEM过去了，而且美其名曰包装为“零存储”。
其实，华为的RAID 2.0+也具备信核所说的同时具备传统RAID和分布式的特色，并且空间利用率更高，但因为要作XOR，须要损耗一些计算资源。
所以，你们发现，通常采用专门硬件的存储厂商，仍是喜欢采用传统的RAID或者改进后的RAID方式。若是是SDS的软件厂商，不须要采用专门的硬件，而是采用普通存储服务器，通常就采用块级多副本技术，如VMWARE的VSAN、华为的Fusionstorage、IBM的XIV，信核的容错池和华云网际的FusionStor都是这个例子。每一个技术都有它的特色和应用场景，用户须要综合性能、可靠以及管理、成本等维度综合考虑。