探讨自适应协同流水线的远程复制系统

时间：2023-03-03 18:35:51 硕士毕业论文我要投稿

相关推荐

探讨自适应协同流水线的远程复制系统

　　1 引言
　　一直以来，数据保护都是IT 行业和工业中的热门话题。特别是近几年，经历过几次大的灾难之后，一些具备完善的数据保护机制的企业能够很快恢复，但是许多其他的企业则由于数据丢失而破产。因此，数据保护技术受到人们越来越多的关注。远程复制是一种流行的数据保护技术。它通过维护主站点与地域上相隔的远端站点的实时镜像，实现对本地的自然或人为的灾难的容灾。目前，有两种典型的远程镜像策略：同步方式和异步方式[1]。因为同步方式对RTT[2]（Round Trip Time）极为敏感，所以异步方式更受人们的喜爱。
　　本文中，我们提出了一个新的协同流水线模型来描述远程复制系统。“协同”的意思是流水线跨越主站点，网络和远程复制站点。因为每个子任务都有相应的“所有者”，所以我们不能任意地分裂它们来平衡流水线的各个阶段。为此，我们提出了自适应成组传输策略。写请求被成组传输到远程站点，而且每个组的大小（组与组之间的时间间隔）会根据主站点和远程备份站点的处理速度动态调整。在我们设计的模型中，实现了数据压缩和加密，分别用来降低网络传输压力和增强安全性。这些操作给CPU 带来了大量的负荷。因此，我们设计了三种加速方法：细粒度流水线、多线程流水线和混合流水线。
　　论文后面的篇幅组织如下：在第2 节中我们重点介绍近年来的相关工作。在第3 节，我们将详细阐释我们系统的基础架构，并提出自适应协同流水线。在第4 节，我们将从大量实验结果中介绍该系统的实现并对其的测试。最后，在第5 节我们将作2 出结论并展望下一步的工作。
　　2 相关工作
　　EMC Symmetrix Remote Data Facility（SRDF）[3]应用了块级的同步远程复制技术，但是如果设备的性能降到阈值一下，它将切换到半同步模式。Veritas Volume Replicator（VVR）[4]是一种逻辑卷级别的远程复制系统。它支持多远程复制，并应用日志和事务机制实现异步远程复制。Dot Hill 的成组远程复制服务[5]，源卷采用即时快照，然后向一个或多个远程复制系统传输传输快照数据更新。
　　网络应用的快照镜像[1]使用快照保证备份卷的更新。WAFL 文件系统习惯于跟踪已经更新的数据块。Seneca[6]延迟向远程站点发送成组更新来期待发生写结合。写操作仅在组中结合，并且在远程站点，每个组必须被原子地操作以防止数据不一致的事件发生。
　　类似于VVR 和Dot Hill 的远程复制服务，我们的原型也在逻辑卷层实现。像Seneca 一样，更新操作被成组发送到远程站点提高性能。我们的原型中还采用了自适应机制。然而，这种自适应是基于异步模式和流水线阶段平衡而不是网络条件的自适应。
　　还有许多其他的远程复制产品，例如IBM 的Extended Remote Copy （XRC）[7]，HPContinuous Access Storage Appliance （CASA）[8]等等。在近几年的学术研究中，[9] 又提出了一种新的模型，在该模型中同步和异步模式由上层应用程序或系统指定。[2]并使用ForwardError Correction （FEC）和“回调”机制来实现高可靠性。
　　3 自适应协同流水线
　　显示了我们原型的架构。它是一个在Linux 的LVM2[10]上实现的异步远程镜像系统。NBD（网络块设备，Network Block Device）[11]用于主从站点间的数据传输。当一个写请求到达时就被复制。原始请求被放到本地队列，复制的请求被放到远程队列。在远程队列中的请求在一定时间间隔内被成组发送到备份站点。因为NBD 通过TCP 协议传输消息，所以只要每个组都能够原子地传输到备份站点就能保证一致性。为了减轻网络传输压力，请求在发送前先进行压缩。然后进行加密操作来报证安全性。从计算复杂性上考虑，先压缩后加密明显优于先加密后压缩。因此，在备份站点，请求在被提交前先解密再解压。
　　3.1 协同流水线
　　为了保证最大吞吐量，一个显而易见的方法是主从站点的操作并行进行，即当一个组被发送出去后并不等待，而是主站点继续处理下一个组，备份站点处理前一个。所以我们可以用两阶段（stage）流水线模型来描述请求处理的过程。我们分别叫这两阶段为主阶段和备份阶段。这是一个“协同”流水线，每个组被主从站点协作处理。我们知道，对于一个已知任务，阶段越多，每阶段的大小越接近，流水线的性能就越好。然而。协同流水线的一些特殊属性与之相悖。
　　对于传统流水线而言，要提高单一流水线的速度，必须把任务划分成很小的单元。例如：
　　现代CPU 的流水线通常有超过20 个阶段。然而，协同流水线一般由8 个子任务组成。包括把 bio 集合成组，压缩，加密，成组传输，解密，解压，写磁盘和回应。因为它是一个软件流水线，进一步的任务分解会导致交互开销过大。更何况我们不能准确地预知一些阶段的执行时间（主要是磁盘操作和网络传输，它们的性能很大程度上依赖系统的当前状态）。对于高效率的流水线来说，这是一个严重的阻碍。
　　一些典型的分布式流水线模型，例如流水线的高斯估测法[12]，将任务分解成相同大小的子任务，并把它们分发到合适的处理器上。然而在协同流水线中，每个子任务都有特定的“主人”，所以不能把它们任意分配给其他的处理器。例如：备份站点不能进行数据压缩，而必须有主站点完成。这个继承下来的不可变的任务映射使平衡负载变得困难。而且，即便我们把任务分成相同大小的子任务，处理器仍然会有空闲。此外，如果我们想通过加深流水线的深度来提高性能，我们就必须同等地进一步分解主站点和备份站点。
　　3.2 自适应成组传输
　　就像上面所提到的，在发送完前一个组后，主站点可以立即处理下一个组。在单用户系统中，这种“尽力而为”的策略保证了最优性能，但是它也有一些缺点。
　　如果两个站点的速度不同，例如，主站点比备份站点快，在“尽力而为”策略下，两个站点将会不同步。如果应用程序将压力加在存储子系统上，主从站点之间的裂隙将会越来越大，直到主站点用尽系统资源。然后主站点会放慢速度来等待备份站点的应答，好释放足够的资源。这样使用户体验很不稳定（主站点的应答时间）。此外，对于多用户系统来说，一个处理器用尽所有系统资源不是好方法。这会严重影响系统的稳定性和其他处理器的性能。
　　总而言之，尽力而为的策略不能很好地协调主从站点的关系。或者，它通过用尽系统资源来“协调”两个站点。所以我们介绍一个自适应成组算法进行协调工作。当系统初始化时我们设置一个组间隔。这个间隔明确了请求积累和成组处理的时间段。即前一阶段积累的请求在下一阶段被成组处理。每完成一个组的操作，我们就会调整组时间间隔，使主从站点的执行时间接近。因此，当组间时间间隔最终达到稳定时，主从站点将有相同的执行时间（都和组间时间间隔相同）。值得注意的是磁盘操作和网络传输的执行时间不和组大小成比例。所以，虽然两个站点的时间间隔都变长或变短，但是增加迅速的那一方（通常是主站点）会比增长慢的那一方（通常是备份站点，包括磁盘操作和网络传输）时间间隔长，所以组间时间间隔是收敛的。
　　不同于尽力而为的策略，当主从站点步调不一致时，自适应成组算法使较快的站点睡眠一段时间而不立即处理下一个组，即减慢较快的站点的速度来促使两站点间保持平衡。这样做的优点是显而易见的：执行速度快的站点不会耗尽系统资源，因此不会系统中其他的处理器。另一个优势是自适应成组传输对网络状况有很好的适应性。如果网络波动，由于时间间隔的调整，主从站点可以自动并及时地适应网络速度。下面的自适应公式用来调整组间间隔。
　　公式中curr T 和next T 分别表示当前和下一个时间间隔， pri T 和back T 分别表示主阶段和备份阶段的执行时间。在我们的实现中， pri T 包括成组，压缩，加密和发送组花费的时间，back T包括传输分组，解密，解压，写磁盘和应答所需时间。α 和β 是值在0 和1 之间的调整因子。它们决定了组间间隔接近真实处理时间的快慢和流水线适应网络改变的快慢。面对持续的繁重的负荷，我们使用组大小的阈值来控制一个组中最大请求数目：
　　其中total N 表示已经被处理的总的请求数量；total T 表示总的处理时间；也就是说，统计量评估处理能力，并且用来设置下一个阈值next N 。说明了自适应成组算法。当主阶段完成后，公式(1)用来调整组间间隔。如果住阶段时间比当前时间间隔短，主站点将会睡眠一段时间。当主站点接收到应答时使用公式(2)。
　　自适应成组算法有不同的变体用于不同的用途。例如，我们可以将组间间隔设置的较短或较长。这些暗示了RPO 的可接受范围（恢复点对象[13]）。此外，组大小的阈值可以用于提供QoS。我们可以调整组大小的阈值和时间间隔的比例来合理安排资源的占有。
　　3.3 加速技术
　　数据压缩/解压和加密/解密给CPU 带来了大量的压力。考虑到多核系统的普遍性，可以利用并行技术实现自适应协同流水线的加速。我们设计了两种加速方案：细粒度流水线和多线程流水线。把这两种方法相结合形成了混合流水线。
　　细粒度流水线加速单一流水线的通用方法是加深流水线的层次，即把任务分成更小的单元，是流水线变长，增加执行的并行度。然而，就像我们在上面提到的，对于协同流水线，我们不能任意重分解流水线。从而，我们必须将主阶段和备份阶段分成相同数量，相同大小的小阶段。很难将现存的两个阶段分成完全相同的小阶段，我们采取以下两种策略：
　　——我们根据经验手动将这两个现存的阶段分解。在我们的实现方式里，主阶段被分成两个子阶段：压缩阶段包括成组和数据压缩；加密阶段包括数据加密和成组发送。备份阶段也相应地分成两个阶段：计算阶段包括接收组，数据解密和解压；I/O 处理阶段包括写磁盘和发送应答信息。主从站点均调用两个线程。每个线程负责一个子阶段。
　　——很明显，经验仅仅保证四个阶段近似相等。为了使它们更接近，也要面对动态地改变，自适应成组算法又一次被用到。每个阶段完成后，就应用相应地自适应公式来调整组间时间间隔。
　　多线程流水线另一种直观的加速方法是把每个阶段并行地分解成子阶段而不是分成更多的小阶段。因为每个组中包括成百上千的请求，简单有效的分解技术是数据划分。在我们的实现中，每个组被分成两个相同大小的子组，且主从站点各调用两个线程。每个线程负责一个子组。它们并行地处理子组之后出于一致性地考虑，串行地发送出去。
　　类似于细粒度流水线，多线程流水线也面临着负载平衡的问题。幸运的是，在这种方式下，问题解决起来容易得多。注意，请求的计算时间和数据大小是成比例的。如果负载中包括的请求都有相同的大小（例如，在我们的实验中，由Iometer 生成负载），那么如果根据请求数量来分割子组将很容易保证负载平衡。此外，我们可以根据字节总数分割子组。
　　串行网络传输似乎是多线程流水线的一个阻碍。但是花在这上面的时间只是总执行时间的一小部分，因此串行网络传输并没有对系统的性能造成很大影响。我们的实验结果也证实了这一点。
　　此外，多线程流水线比细粒度流水线更灵活。它甚至可以用来处理不对等的协同流水线。
　　例如，如果备份站点是主站点的两倍，备份站点可以用主站点的两倍的线程数来达到它们之间的执行时间的平衡。
　　混合流水线我们的实验结果显示，不论是四阶段流水线还是双线程流水线都完全占用CPU。理论上，加深流水线或用更多的线程都能充分利用CPU 的能力。然而，像我们上面提到的，太深的流水线会导致严重的交互负担。后一个策略，把一个组分成若干小组可能导致负载不平衡。而太多的线程也会增加交互负担，所以我们结合这两个策略。主从阶段都分成两个子阶段，并且每个子阶段用多线程技术进一步加速。我们可以称这种方法为混合流水线。
　　事实上，细粒度流水线是组间并行，即同一时刻，每个组仅由一个处理器处理，几个组同时由多个处理器处理。多线程流水线是组内并行，即各个组一个接一个地被处理，每个组被多个处理器同时处理。混合流水线是二维并行。
　　4 实验评估
　　4.1 原型实现
　　自适应成组算法是在Linux 的LVM2 下作为“远程复制”实现的。类似于LVM2 下的快照模型，我们的模型把远程镜像当做本地卷的附加卷，并实现了三种加速算法。底层的操作系统是RedHat AS server 5（内核版本是2.6.18-128.el5）。并使用LVM2 2.02.39，device mapper1.02.28 和NBD 2.8.8。压缩/解压算法用的是LZW 算法[14]，加密/解密算法用的是AES 算法[15]。为保证组的自动提交，备份站点使用了日志机制。
　　4.2 实验建立
　　所有的实验都在2.66GHz 的英特尔双核Xeon 节点下进行的。一个作为主站点，另一个作为备份站点。每台机器有2GB 的内存和由6 个37GB 的SAS 硬盘组成的RAID-5 硬件。
　　两个节点由千兆以太网相连。为了测试三种并行的模型，我们将备份站点的日志机制关闭来让CPU 承受更多的负载。α 和β 均被置成0.5。组间间隔初始化为30 毫秒。我们用Iometer[16]
　　来产生负载。由于写请求触发了远程复制模型，我们仅需要测试写负载。不像其他专门的状态，顺序写负载也被使用。为了评估异步模式在性能上的影响，我们记录经过一段时间Iometer 显示的性能曲线趋于稳定时的实验结果。每个数据点都是三个样本的平均值。
　　4.3 实验结果
　　我们首先进行基准线测试。显示出了结果。“pri”主站点中的RAID-5 设备，“back”代表备份站点中的RAID-5 设备。“LVM”代表主站点的源卷，“Async”代表没有自适应成组算法的异步远程复制系统。“simple batch”代表有自适应成组算法但是没有数据压缩和加密。
　　我们可以看出，自适应成组算法的性能很好，尽管和纯磁盘操作还有一定差距。
　　显示了数据压缩和加密在性能上的影响。“compression”表示仅进行压缩，不进行加密；“encryption”表示仅加密不压缩；“batch”表示既压缩又加密。和我们预期的一样，引入压缩很大程度上提高了性能，因为网络传输压力减少；而由于复杂的计算度使加密严重影响了性能。而最终版本的性能在这两者之间。
　　显示出3 种并行模型很大程度上提高了性能。我们可以看到三种模型均明显加速了流水线。细粒度流水线和多线程流水线显示出几乎相同的性能。混合流水线提供了更好的性能。因为CPU 没有过载——在混合流水线测试中CPU 只有87%的占用率。
　　我们也跟踪了组间间隔（组大小）。结果显示在中。组间间隔分别被初始化为30毫秒和15 毫秒。请求大小是4KB。我们记录了前20 个时间段的组大小。可以看出自适应成组算法确实是主从站点协作很好。组间间隔迅速趋向稳定。
　　我们还测试了随机写的性能。所示，与顺序写相比，随机写性能在串行和并行版本之间的差距在减小。原因是I/O 部分在整个运行时间中的比例增加了，而且三种并行模型仅加速了计算部分。
　　5 结论和进一步工作
　　本文中，我们展示了一种新型的远程复制系统的协同流水线模型。不同于传统的流水线模型，这种新的模型充分利用了处理器的计算能力。为了解决主从阶段的不平衡性，我们提出了自适应成组算法。为了减轻由于压缩，加密和TCP/IP 协议栈造成的CPU 高负载的情况，我们设计了三种并行的模型：细粒度流水线，多线程流水线和混合流水线。在我们的原型中实现了这些技术。实验结果表明，自适应协同流水线模型有效地平衡了主从阶段，三种并行方式提供了更好的性能。
　　我们所有的实验都是基于局域网环境。在广域网环境下测试我们的模型是下一步我们要进行的重要工作。用有效的纠删码进行进一步容错（Error Correcting）也是我们的下一步计划研究的内容。

中国硕士论文网提供大量免费硕士毕业论文,如有业务需求请咨询网站客服人员！

参考文献
[1] Patterson, R.H., Manley, S., Federwisch, M., Hitz, D., Kleiman, S., Owara, S.: SnapMirror:
File-System-Based Asynchronous Mirroring for Disaster Recovery. In:Proceedings of the 1st USENIX Conference
on File and Storage Technologies, FAST 2002, Monterey, California, USA (Jan 2002) 117–129
[2] Weatherspoon, H., Ganesh, L., Marian, T., Balakrishnan, M., Birman, K.: Smoke and Mirrors: Reflecting
Files at a Geographically Remote Location Without Loss of Performance. In: Proceedings of the 7th USENIX
Conference on File and Storage Technologies, FAST 2012, San Francisco, California, USA (Feb 2012) 211–224
[3] EMC SRDF - Zero Data Loss Solutions for Extended Distance Replication. Technical Report P/N
300-006-714, EMC Corporation (Apr 2012)
[4] VERITAS Volume Replicator (tm) 3.5 Administrator’s Guide (Solaris). Technical Report 249505, Symantec
Corporation, Mountain View, CA, USA (Jun 2002)
[5] Secure Data Protection With Dot Hills Batch Remote Replication. White Paper, dot Hill Corporation (Jul
2012)
[6] Ji, M., Veitch, A.C., Wilkes, J.: Seneca: Remote Mirroring Done Write. In: Proceedings of the General Track:
2003 USENIX Annual Technical Conference, San Antonio, Texas, USA (Jun 2003) 253–268
[7] DFSMS/MVS Version 1 Remote Copy Administrator’s Guide and Reference 4th edition. Technical Report
SC35-0169-03, IBM Corporation (Dec 1997)
[8] HP OpenView continuous access storage appliance. White Paper, Hewlett-Packard Company (Nov 2002)
[9] Liu, X., Niv, G., Shenoy, P.J., Ramakrishnan, K.K., van der Merwe, J.E.: The Case for Semantic Aware
Remote Replication. In: Proceedings of the 2006 ACM Workshop On Storage Security And Survivability,
StorageSS 2006, Alexandria, VA, USA (Oct 2006) 79–84
[10] LVM.
[10] Breuer, P.T., Lopez, A.M., Ares, A.G.: The Network Block Device. Linux Journal 2000(73) (2000) 40
[12] Grama, A., Gupta, A., Karypis, G., Kumar, V.: Introduction to Parallel Computing, Second Edition.
Addison-Wesley, Essex, England (2003)
[13] Keeton, K., Santos, C.A., Beyer, D., Chase, J.S., Wilkes, J.: Designing for Disasters. In: Proceedings of the
3rd USENIX Conference on File and Storage Technologies, FAST 2004, San Francisco, California, USA (Mar
2004) 59–72
[14] Welch, T.A.: A Technique for High-Performance Data Compression. IEEE Computer 17(6) (1984) 8–19
[15] NIST Advanced Encryption Standard(AES). Federal Information Processing Standards Publication (2001)
[16] Iometer.

【探讨自适应协同流水线的远程复制系统】相关文章：

探讨消防自动喷水灭火系统08-25

浅析贝叶斯网络在自适应超媒体系统中应用研究05-29

可视化远程会商系统及其维护09-19

探讨山东省区域创新系统建设05-11

探讨基于多种通信方式并存的配网自动化通信系统06-01

基于电话网络的热网远程控制系统设计05-11