4-14一种虚拟化环境下关系型数据库存储新模型结题3项目研究总结报告

1、一种适用于虚拟化环境的关系型数据库新模型，,，广州 510630华南师范大学计算机学院摘要: 在虚拟化环境下，本课题拟提出一种基于“同步-异步”的关系型数据库新模型，以改进传统基于“异步-同步”数据库模型存在的“性能干扰过大”、“用户脏数据的可靠性较低”以及“数据库异步处理逻辑过于复杂”等问题。为了在现有虚拟化系统中实现该创新性模型，需要在虚拟机层次和虚拟机管理器层次分别加入强制用户数据同步策略（同步数据库脏数据）和写缓存结构（异步处理来自虚拟机数据库的写请求）。前者应尽可能地对现有典型数据库保持透明，以增强其在现有系统中的普适性，而后者应该尽可能地精简其运行逻辑，以保证虚拟机管理器层次的简洁

2、性和可靠性。这种新型模型的实现将有助于加强关系型数据库与云计算技术（也即系统虚拟化）之间的契合度，具有较大的科学和实践意义。: 虚拟化，写缓存，关系型数据库引言:课题研究背景,目的及意义随着云计算的普及，例如阿里云公司推出的云数据库 RDS 服务（Relational Database Service），再加上云相关安全保障措施的逐渐完善，例如英特尔公司最近SGX 技术（Software Guard eXtens），越来越多的企业和机构愿意将自身的私有数据库迁移至云端，以节省相应的硬件投入和管理维护成本。但是，由于系统环境结合的复杂性，需要重新审视数据库的特性和当前云计算技术（也即系统虚拟化）

3、之间的契合度。首先，关系型数据库具备特殊的特性。相较于其他应用程序，关系型数据库拥有更加丰富的数据类型和复杂多变的。以基于 InnoDB引擎的系统为例，除了常见的元数据流和常规数据流之外，其还会生成特有的二进制日志数据流、事务日志数据流、索引数据流、二次写缓冲数据流、锁信息数据流以及数据字典流等等。这些不仅需要数据库协议栈设计出特定的异步运行逻辑与之匹配并对其进行驾驭，尽可能地保持可接受的性能，从而会产生的 CPU 负载。并且，由于数据的复杂性，在真实的数据库运行环境中，这些数据流还会交错，互相之间产生随机 I/O，从而引起数据库性能的影响，甚至还会造成系统的不稳定性，对用户数据造成损失。其次

4、，虚拟化环境下，因为虚拟机管理器（Virtual Machine Monitor， VMM）的介入，数据库在设备时会呈现间接交互的特点，降低其设备的效率。并且，为了保持数据库虚拟机的写入语义，VMM 会使用强制同步的方法将来自于数据库虚拟机（指安装了数据库Database，简称 VMDB）的写入数据流直接刷入至的虚拟机， Virtual Machine硬件。最终，多个数据库虚拟机会在共享碎片化 I/O 与数据库设备上进行资源竞争，极易催生全局的碎片化 I/O，而这些原有的随机 I/O 互相叠加并放大，最终使得数据库性能。本课题拟提出一种基于“同步异步”的虚拟化数据库新模型对上述问题进行缓解和改

5、进。具体而言，在虚拟机数据库，对位于内存缓冲区中的脏数据页采用同步逻辑处理，以此（1）绕开数据库复杂的脏数据处理流程，解耦刷新线程的繁乱运行逻辑，从而节约服务器整合物理上的 CPU 资源；（2）将脏数据页在其被产生的第一时间内转移出虚拟机地址空间，避免虚拟机发生错误（例如用户操作或系统运行错误）而导致虚拟机数据库的用户数据丢失现象。另一方面，在 VMM 层次，则使用异步方式对上层数据库虚拟机的同步写请求进行调节，以此：（1）改进由于上层数据库虚拟机的同步操作而带来的性能损失问题；（2）开辟一写请求缓冲窗口，在全局角度，对多个数据库虚拟机之间的数据写入流进行统筹规划以缓解随机 I/O 的严重性，

6、比如：减小重写操作对底层硬件的所施加的压力、对虚拟机的写入流进行重新排序形成顺序特征的写入流从而提高性能、针对底层特殊的介质而制定特定的优化等。总而言之，本课题的对现有数据库优化方法可以部署到现有常见的云计算平台之上，具有较为广阔的应用前景和的应用价值，针对其中的性问题的研究将具有重要的理论意义和现实系统意义。本课题的研究目的为：（1）在虚拟化环境下，缓解数据库协议栈的 CPU消耗，时间内数据库事务的吞吐率；（2）在数据库服务器整合场景下，改善虚拟机数据块在共享上离散分布的特点底层设备在应对并发流时的服务带宽；（3）在数据库服务器整合场景下，增强各个数据库实例的性能性，使得一个虚拟机的数据库性

7、能不会被其他虚拟机的异常 I/O 行为而引起大幅度波动。1.基本介绍本课题将对数据库虚拟化的“同步-异步”写操作模型进行深入研究，拟对原有虚拟化系统进行两个改变，即：（1）在虚拟机数据库系统使用同步的方式来处理用户的事务或写入操作；（2）在 VMM 使用异步的方式来处理虚拟机数据库的写入请求。此时，来自于数据库的高级语义，例如事务，将会转换为低级的块级写入请求。根据上述对原有虚拟化数据库系统的改变，本课题的研究内容将分为两个方面，第一，在虚拟机层次上，对数据库的异步处理事务逻辑进行同步化；第二，在 VMM 层次，设计一缓存结构，以实现异步化处理虚拟机的块级缓存结构。这两个研究内容之间的关系如图

8、 1 所示：前者主要为了实现虚拟机数据库脏数据的可靠性、简化数据页内存缓冲页的异步管理逻辑、节省额外的 CPU资源（因为同步方式更为简单）以虚拟化整合上的用户任务之并行性和并发性；后者则首先为了缓解前者的同步方式则可能导致的性能严重下降、全局调节写入流以改善碎片化 I/O、为底层的具体方法。硬件提供量身定做的优化图 1 研究内容之间的逻辑关系和层次关系2 系统设计与实现所需的技术路线如图 3 所示，本项目拟采用的技术如下：一、虚拟机数据库的强制同步策略的技术路线对于使用了通用 I/O 库的应用程序，只需要将这些应用程序部署到一个挂载了同步标志位的文件系统上就可以将其所有的异步 I/O 写操作透

9、明地转换成同步 I/O 的形式。但是对于大型的数据库系统，例如Server，因为它们都使用了自身的缓存机制，一般会绕过了底层文件系统的管理，因此，需要研究一种特制的同步策略，以对它们的绑定参数进行额外的设置以形成同步 I/O 流。二、设计 VMM 写缓存结构的技术路线对于 VMM 层次的写缓存结构，本项目拟基于“用户空间 I/O进程” 的虚拟化技术，在 VMM 中添加一个针对于数据库虚拟机的写缓存，让虚拟机数据库的读写流程绕过主机文件系统的高速页面缓存，以此来减少数据冗余。当VMM 用户空间的相关 I/O进程在打开虚拟机镜像文件时候，其会附带直接 I/O 的标志位，从而绕过主机文件系统自带的缓

10、存行为。当前主流的开源虚拟化系统，例如 QEMU-KVM，都使用基于“用户空间 I/O进程” 的虚拟化技术。因此，VMM 写缓存的设计方式在一定程度上从该结构上铺展开来。 在这个结构中，每一个虚拟机在 VMM 的用户空间都会对应一个 I/O进程，拥有自身独立的虚拟内存地址空间， 并且和它对应的虚拟机内存空间是互相开来的。因此，在该进程的地址空间的虚拟机写操作数据，可以从虚拟机的异常事件中保存下来。图 3 本课题拟采用的基本技术路线示意图4.2 拟解决一、研究重点和难点如何在 VMM 层设计合适的写缓存结构以保持 VMM 的简洁性？写缓存的基本功能包括了用于数据库虚拟机的写操作的内存分配、用于将

11、这些写操作最终刷入磁盘的刷新策略、以及缓存替换算法等。这些操作在虚拟化数据库系统运行期间会被频繁调用，因此需要遵循高效的设计原则。VMM 写缓存拟使用链表来虚拟机的写请求相关信息，链表上的每一个节点代表一个特定的写请求，其中相关的元数据信息包含了 4 个字段：（1）offset，用来表示 该写请求对应的镜像文件的偏移量，即写入的位置；（2）buffer，用来指代即将写入设备的脏数据本身；（3）size 字段用来表示这段脏数据的大小；（4）dirty 标志位，表示该写操作的数据是否已经刷入设备，该字段用来标识一个新的写操作是否可以直接使用旧的写操作的内存空间，以减小 CPU 的开销。这些节点按照

12、它们的到达时间在链表里执行操作，这种简单的方式不仅可 以提高 VMM 写缓存的接收效率，还可以让刷新线程以一种简单的扫描逻辑对特定的写请求集合进行最终的写回。为了实现内存的重用功能， 减小在 VMM 层次对写请求的空间进行频繁分配和回收内存的开销，VMM 写缓存拟使用两种类型的链表对写请求进行管理，如图 4 所示： （1）Dirty 链表，用于新的写请求；（2）Clean 链表，用于保留已经执行了最 终写回过程的写请求的内存空间。Clean 链表里的节点的所属内存空间可以被新来的 写请求所重用， 此时该节点需要从 Clean 链表里脱离出来，重新设置 dirty 字段，然后到 Dirty 链表

13、里。如图展示了内存地址空间的数据的结构，其中基树是整个块级缓存结构的，使用 offset字段来寻找 Dirty 链表中特定的写请求。需要注意的是 Dirty 链表中的写请求节点的信息会在被写回后清除，也就是说，不能通过基树查询Clean链表中的节点信息。图 4 本课题拟采用的写缓存结构在虚拟机在发生关闭、和迁移等事件时，刷新进程能唤醒。 另外一个基于定时器的软中断例程也 会每隔一段时间阈值即被调用，以实现刷新进程的周期性刷新功能。 在 刷新进程执行真正的写回过程时，特别加入了两个针对磁盘设备的优化措施，对其进行加速：(1) 第一个拟采用的优化是重排序过程， 当前刷新进程使用具有 稳定特性的归并

14、排序算法，以避免具有多个相同 offset 字段的重写请求颠倒了写入位置而发生不一致的文件系统错误;(2) 第二个拟采用的优化则是对已经排好序的写请求进行合并操作，它可以把一些写请求 对连续的块地址进行写入的多个操作合并为一个操作，以批处理的发送方式处理，进一步优化虚拟机在频繁调用系统接口时的开销。最后，在调用刷新进程的过程中是以阻塞形式进行的，以防止多个刷新进程并发执行可能造成的乱序状态。总之，虽然在典型的虚拟化环境下， 每次这种异步到同步的 I/O 转换都会引起一次虚拟机数据库上下文切换，但是由于强制同步模块在虚拟机文件系统的同步 I/O 化节省了一些在原本异步路径上的 CPU 消耗，因此

15、，在多个虚拟机同时运行的情况下， 反而可以利用这些 CPU 资源来调度某些工作流 的并发I/O 线程而带来整体性能的的单机体系结构上。，尤其是在现阶段 流行的基于多核 CPU 架构一个应用程序转换后的同步写操作在到达了其虚拟机系统之后，会在高速页面缓存中留下一份拷贝，可以让之后的相同数据的读操作在缓存中命中。VM 写缓存模块虽然不在执行方向的缓存逻辑，但是在接收到来自于虚拟机的读写操作后，仍然需要在缓存里检查是否命中，以保持数据的一致性。这也间接的在主机的异步结构上给了读操作第二次内存命中机会，而不是在其来到 VMM 之后，直接被发送到设备上执行昂贵的磁盘寻址操作。二、如何在物理机器时防止 V

16、MM 内还没有刷入磁盘的数据丢失？有两个可选方式来保持用户语义，第一，采用非易失内存设备，比如相变存储，来实现物理机器时还没有刷入磁盘的虚拟机数据的完整性；第二，利用UPS 非中断电源，可以防止断电此类突发事件对数据库虚拟机的脏数据造成的丢失现象。3 系统性能测试及优化效果实验环境:3-1 磁盘设备的写入优化测试本小节测试 FlushCtrl 组件对特定设备的写入过程的优化效果，其实验场景在基于传统的磁盘设备之上进行。在该场景中，总共启动 5 台虚拟机，分别在 HypeGear、Async-Sync、以及 Async-Async 三种写操作模式下测试。另外，本实验还配备了额外的 5 台客户机，

17、用于扮演客户端的角色，其软硬件配置和 2.4.3 小节所使用的PC 机相同。客户端使用的是 Iometer 测试76，持续不断地向各自虚拟机服务器的虚拟机块设备发送磁盘 I/O 请求。测试文件大小为 1GB，每次写入的块大小为 4KB，测试时间维持在 30 分钟左右。在HypeGear 结构下，这种连续的磁盘写请求会使FlushCtrl 组件持续不断地被调用。图2.10 左侧展现的是客户端发送100%的顺序写入流的带宽值(MB/S)，图2.10 右侧则展现的是当客户端发送100%的随机写入流的每秒完成请求数（IOPS， Input/Output Operations Per Second），其

18、中每个柱状条的长度分别表示当前运行的所有虚拟机性能值的平均值。在顺序磁盘 I/O 流的情况下，HypeGear 结构与 Async-Sync 相比，性能要高出 14%-61%。但是和 Async-Async 模型相比，当虚拟机运行的数目小于等于 3 时， HypeGear 性能略差，这是因为主机充足的 CPU 和内存资源可以让 Async-Async 模型的性能得到充分发挥。但是随着并发虚拟机的数目增多，主机的相关物理资源开始得到饱和，使得 Async-Async 模型的性能开始逐渐下降。图中显示，当并发虚拟机的数目达到 4 台和 5 台时，HypeGear 的性能比Async-Async 模

19、型要分别高出4%和 14%左右。在随机磁盘 I/O 流的情况下，HypeGear 结构与 Async-Sync 相比，性能要高出 90%-500%左右，特别是在有多个并发虚拟机的情况下，性能优势较为明显。与 Async-Async 模型相比，HypeGear 结构在并发虚拟机的数目为 1 台和 2 台时，性能仍然较差，但是并不明显。随着虚拟机并发数目增多时（从 3 台到 5 台）， HypeGear 结构获得了 26%-47%的性能改进。基于上述分析不难发现，尽管 Async-Async 模型可以利用主机的空闲资源，在并发虚拟机数目较少的情况下实现优异的 I/O 性能，但是随着虚拟机的数目增多

20、，这种优势会因为主机的频繁 I/O 冗余活动而，甚至出现的性能影响。HypeGear 结构则可以在顺序和随机的两种 I/O 风格下，根据自身针对磁盘的重排序以及合并的优化策略进行相关性能的，尤其是在并发虚拟机数目较多的情况下。3-2.GearCache 开销测试本小节测试 GearCache 对 VMM 施加的额外开销。在该测试场景中，为了和图2.1 有一个直接的对比，使用的测试方法都与其相同。在内存消耗方面，GearCache总是保持着 64MB 的上限，这是因为有一个阈值 对其进行限制。需要注意的是，这个 64MB 的内存是从虚拟机本身脱取出来的（一个 448MB+64MB 的组合），和另

21、外两种写操作模型的虚拟机内存分配大小是一样的（512MB），并没有使用额外的。如图 2.14 所示，在 CPU 消耗方面，GearCache内存分配来换取相关的性能的 CPU 消耗在测试过程中的平均使用率是 7.8%左右，峰值为 15%。和 Async-Async模型的平均 17.1%的消耗相比，避免了 50%左右的 CPU 消耗。通过使用 Xenoprof 工具对 GearCache 的开销进行更进一步的分析发现， HypeGear 结构相对于 Async-Sync 模型的额外CPU 消耗来自于GearCache 拷贝虚拟机写操作数据之间的开销，占了整个流程的 23%。一个潜在的优化方式是在GearCache行 Hash基于 SHA-1 的 Hash 算法78对每一个虚拟机的写操作内容进。因此，HypeGear 就可以通过比对 Hash 值的方法把带有相同内容的写操作识别出来，从而避免了之后的拷贝开销。3-3 小结针对传统的Async-Sync以及Async-Async写操作模型在CPU消耗过大、用户脏数据的稳定性不高、虚拟机之间的I/O干扰较大、以及主机文件系统I/O冗余活动过多等问题，本章提出了一种基于Sync-Async的写操作模