1.概述
随着信息化水平的不断提高，信息数据的重要性在当今社会日益凸显。由于信息系统面临自然灾害、硬件失效、战争等诸多灾难性的风险和威胁，信息系统的可用性和容灾能力等问题日益成为人们关注的焦点。平衡数据的可用性、存取的性能以及构建和维护系统的成本是设计容灾系统必须考虑的问题。与此同时，数据快照(Snapshot)、持续数据保护(Continuous Data Protection， CDP)、远程镜像等相关技术也得到了广泛的使用并形成了许多成熟的容灾产品或相关开源软件。但现有的容灾系统存在如下缺点：
(1)当对数据量巨大的本地端进行容灾保护时，许多容灾系统需要将原始数据迁移至容灾系统中，从而造成业务的长时间停滞，因此，容灾系统不能保证在不改变本地端存储架构的前提下对本地端容灾保护。虽然利用软件RAID的镜像功能与存储区域网络(Storage Area Network, SAN)结合可以构建远程镜像系统进行容灾，并能将数据动态地同步到异地容灾端，而不会造成业务的长时间的停滞，但软件RAID 在对本地端加镜像保护时会将其超级块信息写入本地端存储设备的末端，从而可能覆盖本地端存储设备中的有用数据。类似的还有分布式复制块设备(Distributed Replicated Block Device, DRBD)，它同样可以进行动态构建，但是也会将其超级块信息写入到本地端存储设备。
(2)有的容灾系统依赖于特定硬件设备或驱动。例如：EMC 公司的SRDF 必须构建于本公司的Symmetrix 网络存储系统之上；SnapMirror依赖于NetAPP 公司的存储设备以及嵌入在设备底层的WAFL 文件系统。另外，还有许多容灾系统要求异地容灾端的存储设备必须和本地端的存储设备型号一致，因为不同厂家的磁盘阵列产品无法直接做数据同步。
本文运用动态镜像加载技术和基于吸拉式日志的异步数据传输方法，设计一种基于存储虚拟化的动态容灾系统。
2.体系结构
2.1 总体架构
动态容灾系统由一系列用户态程序和内核驱动组成，包括本地端的管理模块、通信模块、镜像模块以及块日志处理模块，异地端的管理模块、通信模块、块日志解析模块。体系结构如图1 所示。
图1 动态容灾系统的体系结构
2.2 存储设备
由于Linux 操作系统下各种块设备驱动都会向用户层提供通用块设备接口，这一机制保证了动态容灾系统的通用性和灵活性。存储池表示数据存储容器，是各种异构存储设备的统称，如硬盘、盘阵、网络虚拟盘，逻辑卷等。本地存储池是本地服务器端原始数据的存储载体，异地存储池是异地容灾端数据的存储载体，本地存储池与异地存储池可以为不同类型的存储设备。
镜像/日志存储池部署于本地，是用于存储镜像同步数据以及日志数据的块设备。它基于存储虚拟化技术，具体类型(硬盘、逻辑卷或其他块设备)可以由用户指定，通过存储区域网络映射到异地端，对本地端跟异地端而言，它是公共的存储空间，其中可以使用各种协议，如FC、iSCSI等。由于通常情况下对于较远距离的异地容灾而言，网络数据的传输速度远不及本地的存储设备，因此在容灾系统中镜像/日志存储池可以起到很好的缓冲作用。镜像/日志存储池具体空间布局如图2 所示。
图2 镜像/日志存储池空间布局
它的设计借鉴了快照的基本思想，空间分为2 个部分，第1 部分空间为原始数据区(代号为A)，它与本地存储池空间大小相等，用于同步模式下保持与本地存储池完全一致的数据副本，以及开启异步模式时保存本地存储池数据的快照；第2 部分空间为日志数据区(代号为B)起缓冲作用，用于以日志形式记录开启异步模式时上层传下来的写操作请求拷贝，也就相当于开启异步模式时生成了快照，B 部分为生成快照后的增量数据日志。
2.3 应用程序部分
管理模块和通信模块都为应用程序。本地端的管理模块负责与内核模块以及通信模块的交互，比如管理设备，监控并报告设备状态等，而本地端的通信模块负责与异地端的通信模块的通信，并向异地端的通信模块传递控制信息，接收并向本地端管理模块报告从异地端传来的相关反馈信息。
异地端的通信模块负责检查网络是否通畅以及监听来自本地端通信模块的控制信息、状态信息以及日志表头信息并将接收到的信息传递给异地端的管理模块。异地端管理模块负责与异地端的块日志解析模块的交互，功能包括设备管理，监控并报告设备状态，向通信模块反馈相关信息，获取日志表头信息传予日志解析模块。通过本地端与异地端的交互同时判断本地端的服务器是否异常，当本地端服务器失效时，系统能在较短时间内将服务从本地端切换至异地端，并在异地端启动与本地端相同的用户进程，保证服务的不间断。
2.4 内核驱动部分
镜像模块是容灾系统本地端内核驱动的一部分，负责向子设备接收并转发从上层传来的读写请求。在同步模式下，镜像模块将本地存储池数据同步到镜像/日志存储池，维持本地存储池和镜像/日志存储池A 部分的数据的完全一致性。在异步模式下，镜像模块收到上层应用程序传来的写请求时，将数据写入本地存储池的同时通过块日志处理模块将数据以日志形式写入镜像/日志存储池的B 部分。在仅存在本地存储池故障的情况下，镜像模块还能向上层管理模块反馈相关信息，并且结合块日志处理模块分析镜像/日志存储池的AB 两部分来处理上层读写请求，从而保证整个系统的正常工作，而无需将服务迁移到异地端。
块日志处理模块是容灾系统本地端内核驱动的另一部分，负责与镜像模块交互。在异步模式下，块日志处理模块接收从镜像模块传来的写请求，然后将每个写请求转为日志，以一定的格式写于镜像/日志存储池的B 部分。块日志处理模块还配合镜像模块向上层提供镜像服务，如果遇到仅本地存储池故障的情况，块日志处理模块通过日志的记录和解析处理上层读写请求，而不影响服务的持续性。
镜像/日志存储池通过存储区域网络技术映射到异地端，块日志解析模块通过读取并解析镜像/日志存储池的映射盘上的数据，并将解析结果发送给异地存储池。块日志的处理是在异步模式下进行的，首先块日志解析模块会将镜像/日志存储池的A 部分的数据之间拷贝到异地存储池，然后再解析镜像/日志存储池B 部分的块日志，由日志还原出写操作并将其发送到异地存储池，从而保证数据的严格一致性。
3.关键技术
本节将详细介绍动态容灾系统涉及的2 种关键技术，即动态镜像加载技术和吸拉式日志技术的具体实现。
3.1 动态镜像加载技术
动态容灾系统的突出特点是能够在本地服务器短暂停服务时进行动态加载容灾保护，而且不改变本地服务原有的存储架构。要达到这一目的，必须保证数据拷贝和上层来的数据写请求处理可以同时进行，这就用到了动态镜像加载技术。动态镜像加载技术是将包含构建容灾系统的本地子设备信息的超级块以文件形式保存于系统盘上，在虚拟块设备中的镜像模块中使用内核多线程来对数据进行处理。以文件形式保存超级块就不会破坏本地存储池上的数据。镜像子模块的体系结构如图3 所示。
图3 镜像模块的体系结构
当对本地端加载容灾保护时，只需要短暂停服务，期间将镜像模块插入，然后就可以启动本地端原来的服务，此时镜像模块就会开始工作，进行同步。同步过程对上层应用而言是透明的。
在同步过程中用到了带状态的位图机制来记录数据的非一致性块。由图3 可以看出，上层写请求到来时需要将写请求拷贝后分发至2 个子设备，进行同步以及处理上层来写请求都可以使数据一致化，一旦数据一致，就对位图进行相应的处理。在内核态下需要创建2 个线程，一个为同步线程，另一个为管理线程。同步线程负责从本地存储池读取数据，将其转换为写请求后添加到同步请求链表交予管理线程处理。管理线程一方面处理同步请求的提交另一方面处理上层写请求的提交，并管理位图。同步过程中有写请求到来时，大致处理步骤如下：
(1)同步线程从本地存储池读取一个数据块，创建同步写请求，获取同步请求链表的互斥锁，将该写请求添加到同步请求链表，释放互斥锁。
(2)当上层写请求到来时，考虑到可能出现对一个子设备写请求提交完成了而另一个写请求提交未完成造成不一致的情况，所以需要先将位图对应的位进行非一致性化处理(这里置为状态A)，然后将该写请求复制并设置成发往2个子设备的写请求，获取写请求处理链表的互斥锁，将2个写请求添加到写请求处理链表，释放互斥锁。
(3)在管理线程中，将写请求处理链表中的请求提交，查看位图状态，如果位图一致或为状态A，同步请求链表中对应的写请求丢弃，然后将同步请求链表中剩余的写请求提交。每种类型的写请求提交完成后都对位图进行相应的一致性化处理。
3.2 吸拉式日志技术
在常规的异步数据复制中，用的是推送式的数据传输方法，这就面临着许多问题，而这些问题会令系统实现困难并且效率低。其中一个就是本地端内存中数据积压问题，另一个常见的则是数据一致性问题。用位图技术以及写合并技术可以解决本地端数据积压的问题，但破坏了数据的时序一致性。用一致性组的方法可以保证组内的一致性，但是需要快照技术作为辅助。
然而，网络吸拉式日志方法可以很好地解决这些问题。由于通常情况下对于较远距离的异地容灾系统而言，网络数据的传输速率并不及硬盘的1/10，因此本地硬盘在异地容灾系统中可以作为很好的缓冲设备。
在本地端启动异步模式后，发向镜像/日志存储池的写请求以日志的方式写入其部分B，而与此同时，异地端的日志解析模块先将镜像/日志存储池部分A 的数据(相当于同步模式转异步模式时生成了快照)直接拷贝至异地存储池，然后读取部分B 的日志，并进行解析，得出数据后再写入异地存储池。由于本地端负责写入，异地端负责读取，这就会出现竞争问题。
日志在镜像/日志存储池的B 部分中以双链表的方式进行组织管理。一个链表作为读链表，由异地端负责读取，一个链表作为写链表，接收本地端的写请求日志，当异地端将读链表读完后，释放空间，写链表变化角色为读链表，新建的写链表继续接收上层传来的写请求。锁由本地端集中管理，通过异地端与本地端的交互是对链表头进行简单的加锁/解锁操作，即解决了竞争问题。
这样通过日志就将对本地存储池的数据写入过程完整地还原到异地存储池上，保证了数据的严格时序一致性。由于镜像/日志存储池实际上是本地存储设备，它与本地存储池数据的写入是并行的，因此，并未对原系统性能产生较大影响。
4.性能测试与分析
4.1 测试环境
本节介绍系统测试的硬件和软件环境，由于本文系统基于软件实现，不依赖于底层硬件和设备，故测试过程中本地端跟异地容灾端选取了不同的硬件环境。本地端采用的是戴尔T110 工作站，具体配置为：Intel Xeon X3430 四核CPU，4 GB DDR2 667 内存，原始数据盘为160 GB SATA硬盘，日志数据盘为250 GB SATA 硬盘。异地容灾端采用的是戴尔Inspiron 530 微型机，具体配置为：Intel Core E4400双核CPU，2 GB DDR2 667 内存，备份数据盘为160 GB SATA 硬盘。本地端跟异地容灾端的操作系统都是采用Linux，内核版本为2.6.18。
4.2 测试结果与分析
本文使用广泛使用的iozone 测试工具来对本地端不同情况下硬盘读写效率进行测试。分别测试了本地存储池(sdb)、镜像/日志存储池(sdc)、同步过程中、同步完成后以及异步状态下的随机读性能和随机写性能。为消除随机性带来的误差，每项测试进行10 次并取平均值。随机读性能结果如图4 所示。
图4 随机读性能
可以看出，无论是在构建容灾系统的同步过程中、同步完成后还是在异步模式下，容灾系统虚拟块设备的读性能都与本地盘的读性能相差不大，这是因为上层应用程序发来的读请求都是直接发往本地盘，而在同步过程中，本地盘不仅要处理上层应用程序的读请求还需要处理同步读请求，所以，其在同步过程中的读性能相比其他情况下的读性能要低。
随机写性能如图5 所示。
图5 随机写性能
可以看出，在同步过程中、同步完成后以及在异步模式下，容灾系统的虚拟块设备的随机写性能与本地盘相比有所下降，但带来的写性能开销并没有超过20%。因为在这些情况下，容灾系统虚拟块设备需要将上层传来的写请求进行复制，并分发至本地盘和镜像/日志盘，当2个盘的写请求处理完成后，针对上层的写请求才返回。而在同步过程中，本地盘不仅要处理上层应用程序的写请求还需要处理同步写请求，所以，其在同步过程中的写性能相比其他情况下的写性能要低。
经过以上比较和分析可以得出以下结论：在同步模式下，本文系统对原系统的性能影响不超过10%；在异步模式下，对原系统的性能影响不超过20%。由此可见，该系统在成功提供对本地数据保护的同时，仅对原系统带来较小的读写性能缺失。
5.结束语
本文基于存储虚拟化技术，以软件方式实现一种动态容灾系统，保证了数据一致性和服务的高可用性。实验结果证明，该系统动态加载后对原系统带来较小的性能缺失。此外，下一步针对该系统还可做如下改进：通过本地端对日志数据进行压缩存放，远程端读取后解压缩可以减小网络负载，降低灾难发生时数据丢失；通过本地端对日志进行加密，远程端读取后解密可以提供系统安全性。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：一种基于存储虚拟化的动态容灾系统
相关文章
