多副本和raid技术

传统技术局限
随着存储系统规模爆炸式增长，依赖硬件设备保障系统可靠性的传统理念遭遇到极大挑战。对PB级海量存储系统而言，单纯的硬件容错技术已经很难确保系统可靠性，而依靠文件系统实现的文件级容错又存在各种限制和不足，企业级用户亟待一种规范、平滑、可靠又经济的方式来支撑海量存储系统稳定性。

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过程中增加多次格式转换，影响性能效率，徒增管理维护难度。

其次，分布式文件系统虽然提供POSIX兼容界面，但并非全集实现，而是仅仅实现其中部分常用子集。应用使用这些文件系统提供的资源时，部署和维护工作需要大量专业人员深度介入，而且完整系统从实施到稳定工作的调试周期很长，某些大规模复杂系统的稳定周期甚至以年计算。

主流分布式文件系统均来源于开源项目，虽然其活跃度和技术开放性成就了许多定制化灵活性，但同时也带来了版本分支繁多、技术规范度难以保证、未来升级变化难以预期、技术支持有限等诸多问题。

容错池对比传统容错技术
智能容错池综合了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都是这个例子。每个技术都有它的特点和应用场景，用户需要综合性能、可靠以及管理、成本等维度综合考虑。

转自：https://chuansongme.com/n/393032