1 引言 一直以来，数据保护都是IT 行业和工业中(3)
2013-06-12 01:03
导读：自适应成组算法有不同的变体用于不同的用途。例如，我们可以将组间间隔设置的较短或较长。这些暗示了RPO 的可接受范围（恢复点对象[13]）。此外，组
自适应成组算法有不同的变体用于不同的用途。例如，我们可以将组间间隔设置的较短或较长。这些暗示了RPO 的可接受范围（恢复点对象[13]）。此外，组大小的阈值可以用于提供QoS。我们可以调整组大小的阈值和时间间隔的比例来合理安排资源的占有。
3.3 加速技术
数据压缩/解压和加密/解密给CPU 带来了大量的压力。考虑到多核系统的普遍性，可以利用并行技术实现自适应协同流水线的加速。我们设计了两种加速方案：细粒度流水线和多线程流水线。把这两种方法相结合形成了混合流水线。
细粒度流水线加速单一流水线的通用方法是加深流水线的层次，即把任务分成更小的单元，是流水线变长，增加执行的并行度。然而，就像我们在上面提到的，对于协同流水线，我们不能任意重分解流水线。从而，我们必须将主阶段和备份阶段分成相同数量，相同大小的小阶段。很难将现存的两个阶段分成完全相同的小阶段，我们采取以下两种策略：
——我们根据经验手动将这两个现存的阶段分解。在我们的实现方式里，主阶段被分成两个子阶段：压缩阶段包括成组和数据压缩；加密阶段包括数据加密和成组发送。备份阶段也相应地分成两个阶段：计算阶段包括接收组，数据解密和解压；I/O 处理阶段包括写磁盘和发送应答信息。主从站点均调用两个线程。每个线程负责一个子阶段。
——很明显，经验仅仅保证四个阶段近似相等。为了使它们更接近，也要面对动态地改变，自适应成组算法又一次被用到。每个阶段完成后，就应用相应地自适应公式来调整组间时间间隔。
多线程流水线另一种直观的加速方法是把每个阶段并行地分解成子阶段而不是分成更多的小阶段。因为每个组中包括成百上千的请求，简单有效的分解技术是数据划分。在我们的实现中，每个组被分成两个相同大小的子组，且主从站点各调用两个线程。每个线程负责一个子组。它们并行地处理子组之后出于一致性地考虑，串行地发送出去。
您可以访问中国科教评价网（www.NsEac.com）查看更多相关的文章。
类似于细粒度流水线，多线程流水线也面临着负载平衡的问题。幸运的是，在这种方式下，问题解决起来容易得多。注意，请求的计算时间和数据大小是成比例的。如果负载中包括的请求都有相同的大小（例如，在我们的实验中，由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]。为保证组的自动提交，备份站点使用了日志机制。
