CN105376269A

CN105376269A - 虚拟机存储***及其实现方法和装置

Info

Publication number: CN105376269A
Application number: CN201410390308.1A
Authority: CN
Inventors: 高原; 全小飞; 广小明
Original assignee: China Telecom Corp Ltd
Current assignee: Tianyi Cloud Technology Co Ltd
Priority date: 2014-08-11
Filing date: 2014-08-11
Publication date: 2016-03-02
Anticipated expiration: 2034-08-11
Also published as: CN105376269B

Abstract

本发明公开一种虚拟机存储***及其实现方法和装置，该方法包括接收客户端操作***的写请求，将写请求数据缓存在虚拟机缓存中，根据服务器的状态将写请求数据上传到服务器。本发明的虚拟机存储***及其实现方法和装置，在接收到写请求之后，通过将写请求数据缓存在虚拟机缓存中，并根据服务器的状态将写请求数据上传到服务器，可以解决云计算中虚拟机存储***中由写突发而产生的拥堵问题。

Description

虚拟机存储***及其实现方法和装置

技术领域

本发明涉及云计算领域，尤其涉及一种虚拟机存储***及其实现方法和装置。

背景技术

在云计算中，虚拟机运行时所需的软件资源都存放在存储服务器上。现有技术中，虚拟机存储***是由位于客户端的虚拟磁盘接口、虚拟机监控器(VirtualMachineMonitor，VMM)和位于服务器的输入输出(inputandoutput，IO)服务及虚拟磁盘映像所组成，其中，VMM主要负责处理与服务器的交互，缓存管理则依赖于客户端操作***的内部机制。虚拟机存储的特点是在客户端操作***下层，通过虚拟技术屏蔽客户端操作***与服务器交互的细节，使得客户端操作***及其应用程序无需本质改动就可以按照云计算的模式运行。

但是，在云计算环境中，由于虚拟存储对上层进行了网络和服务器细节的屏蔽，客户端操作***则无法了解当前网络和服务器的状况，因此无法正确选择上传数据的时机。即使客户端上没有进程占用虚拟磁盘，服务器仍然可能处于繁忙状态。客户端有可能在服务器繁忙的情况下持续提交写请求，这样，一方面会使得服务器更加繁忙，甚至在缓冲区溢出造成数据丢失，浪费带宽资源；另一方面客户端操作***不能在期望的时间内得到服务器响应，造成相关程序运行缓慢或崩溃。

发明内容

有鉴于此，本公开要解决的一个技术问题是：如何解决云计算中虚拟机存储***中由写突发而产生的拥堵问题。

第一方面，本公开提供一种虚拟机存储***实现方法，包括：

接收客户端操作***的写请求；

将写请求数据缓存在虚拟机缓存中；

根据服务器的状态将写请求数据上传到服务器。

其中，根据服务器的状态将写请求数据上传到服务器包括：

判断服务器的状态，若服务器的状态为空闲，则将写请求的数据上传到服务器，若服务器的状态为繁忙，则将写请求数据缓存在虚拟机缓存中。

可选地，将写请求数据缓存在虚拟机缓存中包括：将写请求数据缓存在非易失性存储器。

和/或

该虚拟机存储***实现方法还包括：

根据写请求数据的类型将写请求数据上传到服务器。

进一步地，根据写请求数据的类型将写请求数据上传到服务器包括：

若写请求数据为用户数据，则将写请求数据上传到服务器；和/或

若写请求数据为内存交换数据和/或临时数据，则将写请求数据存储在非易失性存储器；

和/或

该虚拟机存储***实现方法还包括：

若写请求数据为临时数据，将临时数据缓存到内存中，将至少一个临时数据合并为总临时数据后，存储到非易失性存储器。

可选地，非易失性存储器包括日志磁盘。

可选地，若客户端或服务器发生意外重启时，还包括：

读取日志磁盘中保存的控制段；

从控制段开始扫描日志磁盘，找到分配段、提交段所标识的数据段；

依次上传分配段、提交段所标识的数据段；

上传完毕后，正常启动客户端操作***。

可选地，该虚拟机存储***实现还包括：

将日志磁盘中的数据段提交到服务器；

当接收到服务器返回的接收确认后，更改数据段的控制段为提交段；

当接收到服务器返回的提交确认后，更改数据段的控制段为可用段；

回收可用段标识的数据段。

可选地，该虚拟机存储***实现还包括：

接收客户端操作***的读请求；

根据读请求在虚拟机缓存中查找读请求对应的数据；

若在虚拟机缓存中查找到读请求对应的数据，则读取数据，若在虚拟机缓存中未查找到读请求对应的数据，则将读请求发送到服务器。

第二方面，本公开提供一种虚拟机存储***实现装置，包括：

接收模块，用于接收客户端操作***的写请求；

缓存模块，与接收模块相通信，用于将写请求数据缓存在虚拟机缓存中；

控制模块，与缓存模块相通信，用于根据服务器的状态将写请求数据上传到服务器。

其中，控制模块还用于：判断服务器的状态，若服务器的状态为空闲，则将写请求的数据上传到服务器，若服务器的状态为繁忙，则将写请求数据缓存在虚拟机缓存中。

可选地，缓存模块用于将写请求数据缓存在非易失性存储器；

和/或

该装置还包括：

控制模块还用于根据写请求数据的类型将写请求数据上传到服务器。

可选地，控制模块还用于：

和/或

装置还包括：

控制模块还用于若写请求数据为临时数据，将临时数据缓存到内存中，将至少一个临时数据合并为总临时数据后，存储到非易失性存储器。

可选地，非易失性存储器包括日志磁盘。

可选地，若客户端或服务器发生意外重启时，控制模块还用于：

读取日志磁盘中保存的控制段；

依次上传分配段、提交段所标识的数据段；

上传完毕后，正常启动客户端操作***。

可选地，控制模块还用于：

将日志磁盘中的数据段提交到服务器；

回收可用段标识的数据段。

可选地，该装置还包括：

接收模块用于：接收客户端操作***的读请求；

控制模块还用于：

根据读请求在虚拟机缓存中查找读请求对应的数据；

第三方面，本公开提供一种虚拟机存储***，包括：

配置有虚拟机存储***实现装置的客户端；

服务器，与客户端相通信，用于为客户端的用户提供服务。

本公开提供的虚拟机存储***及其实现方法和装置，在接收到写请求之后，通过将写请求数据缓存在虚拟机缓存中，并根据服务器的状态将写请求数据上传到服务器，可以解决云计算中虚拟机存储***中由写突发而产生的拥堵问题。

根据下面参考附图对示例性实施例的详细说明，本发明的其它特征及方面将变得清楚。

附图说明

图1A示出本发明一实施例的虚拟机存储***实现方法的流程图。

图1B示出本发明一实施例的虚拟存储***的结构示意图。

图2示出本发明另一实施例的虚拟机存储***实现方法的流程图。

图3A示出本发明一实施例的虚拟机存储***实现方法的VMCache的结构图。

图3B示出本发明一实施例的虚拟机存储***实现方法的流程示意图。

图4A示出本发明一实施例的虚拟机存储***实现方法的页面映射管理的示意图。

图4B示出本发明一实施例的虚拟机存储***实现方法的内存缓存布局的示意图。

图4C示出本发明一实施例的虚拟机存储***实现方法的日志磁盘结构示意图。

图4D示出本发明一实施例的虚拟机存储***实现方法的段状态转移的示意图。

图4E示出本发明一实施例四的虚拟机存储***实现方法的段布局的示意图。

图5A示出本发明一实施例的虚拟机存储***实现方法中读方法的流程图。

图5B示出本发明一实施例的虚拟机存储***实现方法中写方法的流程图。

图6示出本发明一实施例的虚拟机存储***实现方法中数据恢复方法的流程图。

图7示出本发明一实施例的虚拟机存储***实现方法中延迟提交确认方法的流程图。以及

图8示出本发明一实施例的虚拟机存储***实现装置的结构框图。

具体实施方式

下面参照附图对本发明进行更全面的描述，其中说明本发明的示例性实施例。

图1A示出本发明一实施例的虚拟机存储***实现方法的流程图。如图1A所示，该虚拟机存储***实现方法主要包括：

步骤S102，接收客户端操作***的写请求。

步骤S104，将写请求数据缓存在虚拟机缓存中。

步骤S106，根据服务器的状态将写请求数据上传到服务器。

具体地，图1B示出本发明一实施例的虚拟存储***的结构示意图，如图1B所示，客户端操作***11包括应用程序12、文件***13、虚拟机内存管理14、虚拟磁盘接口15等，VMM包括IO处理器16,、虚拟机缓存17以及网络存储协议客户端18等。VMM19按照功能可以划分为IO处理器16、虚拟机缓存17和网络存储协议客户端18，其中，网络存储协议客户端18可以基于网络存储***(NetworkFileSystem，NFS)或者小型计算机***接口(InternetSmallComputerSystemInterface，iSCSI)等***的客户端10。IO处理器16负责接收客户端操作***11的读写请求，对请求进行分类、排队与调度；VMCache主要负责管理VMM19中的写缓存；网络存储协议客户端18负责实现网络存储协议的客户端10与服务器20进行通信。

客户端操作***11通过VMM19与服务器20实现交互，缓存管理依赖于VMM19中的虚拟机缓存17(VirtualMachineCache，VMCache)，该虚拟机缓存17特别是写请求缓存独立于客户端操作***11，以块为粒度执行，跨平台较高，同时不需要改动操作***既可以方便的移植到其他***，可移植能力较高。云计算中，多种操作***可以动态加载到该客户端10运行。

具体地，当客户端操作***11的读写请求到达VMM19后，先在IO处理器16中排队，IO处理器16再根据一定的策略如先入先出策略(FirstInFirstOut，FIFO)从队列中选择一个请求，传递给VMCache。写请求先保存在VMCache中，再由VMCache来决定这些数据是否需要上传及何时上传的问题。当写请求数据写入VMCache，对于客户端操作***11而言，写请求就已经完成，无需再关心这些数据何时上传到服务器20。这样就可以将原来的同步操作变为异步操作，减少响应的时间。网络存储协议客户端18会将接收到的请求封装为网络存储协议报文，依照网络存储协议发送给服务器20。待服务器20的处理结果返回后，可以逐层上传，返回给客户端操作***11，完成相关请求。

进一步地，步骤S106还可以包括：

判断服务器20的状态，若服务器20的状态为空闲，则将写请求的数据上传到服务器20，若服务器20的状态为繁忙，则将写请求数据缓存在虚拟机缓存17中。

具体地，客户端10根据服务器20的状态将写请求数据上传到服务器20，当服务器20繁忙时，客户端操作***11提交的写请求可以先暂时存放在虚拟机缓存17中，待服务器20空闲时，再将数据上传。

在一个实施例中，客户端10的VMM19可以根据服务器20的CPU、内存、磁盘状态、网络占用率等状态，直接或者间接的确定服务器20繁忙还是空闲。举例而言，当客户端10的VMM19检测到服务器20的CPU利用率为90％时，客户端10的VMM19判断得到该时刻服务器20处于繁忙状态，可以继续将写请求数据缓存在虚拟机缓存17中，不将该写请求数据上传；继续检测服务器20CPU利用率，当检测到CPU利用率降低到一定值如50％时，客户端10判断得到该时刻时服务器20处于空闲状态，可以将写请求数据上传到服务器20。

需要说明的是，尽管以CPU利用率作为示例介绍了根据服务器的状态将写请求数据上传到服务器，但本领域技术人员能够理解，本发明应不限于此。事实上，用户可以根据实际应用场景设定服务器状态的标准，在不同的应用场景下的服务器忙闲程度没有统一标准，具体指标应可以由***管理员自行定义。例如可以通过服务器内存利用率、服务器磁盘占用率等来判断服务器状态，只要能达到判断服务状态的效果即可。

本实施例的虚拟机存储***实现方法，在接收到写请求之后，通过将写请求数据缓存在虚拟机缓存中，并根据服务器的状态将写请求数据上传到服务器，可以解决云计算中虚拟机存储***中由写突发而产生的拥堵问题。

图2示出本发明另一实施例的虚拟机存储***实现方法的流程图。图2与图1A、1B相同的步骤或组件具有相同的功能，为简明起见，省略对这些步骤或组件的详细说明。

如图2所示，图2所示的方法与图1A所示方法的主要区别在于，步骤S201之后还可以包括：

步骤S202，将写请求数据缓存在非易失性存储器。

进一步地，该非易失性存储器包括日志磁盘。

具体地，工作在操作***下层的写缓存中保存的数据可能是上层文件***的元数据、日志或者事务性操作相关的数据结构，丢失这些数据可能将影响文件***的故障修复能力，严重时可能导致文件***崩溃。若不能保证非易失性，文件***的直写操作语义就会失效，这将意味着用户在应用软件如Word中保存过的数据也可能丢失。对于用户来说，这是不可接受的。通过将写请求数据缓存在虚拟机缓存中的非易失性存储器如日志磁盘、固态硬盘、非易失性只读存储器(Non-VolatileRandomAccessMemory，NVROM)等，在突然断电或者***崩溃时，缓存中的用户数据不能丢失。可以解决缓存的数据掉电丢失的问题。

进一步地，在步骤S201之后还可以包括：

步骤S204，根据写请求数据的类型决定是否将写请求数据上传到服务器。

进一步地，步骤S204可以包括以下情况：

情况一，若写请求数据为用户数据，则将写请求数据上传到服务器。

情况二，若写请求数据为内存交换数据和/或临时数据，则将写请求数据存储在非易失性存储器。

其中，若写请求数据为临时数据，将临时数据缓存到内存中；将至少一个临时数据合并为总临时数据后，再存储到非易失性存储器。

具体地，内存交换数据(MemoryswapData，MD)是云计算***中为了支持客户端操作***的内存交换(swap)与调页(paging)而产生的写数据。内存交换与调页是现代操作***为了解决物理内存不足而提出的一种利用磁盘空间扩展内存空间的方法，该方法的原理是指定磁盘中的一部份空间作为物理内存的扩展，然后把物理内存中不经常使用的页面或者当前不活动进程的占用页面置换到磁盘中，使得释放出来物理内存空间可以用于其他进程。临时数据(TemporaryData，TD)包括程序运行过程中产生的中间结果、缓存文件及日志文件等。用户数据(UserData，UD)是指由用户编辑或下载的文件，与前两种数据相比，这类数据的生命周期长，需要长期保存。

客户端可以确定服务器的状态，通过VMM中的VMCache的写缓存机制，可以有效管理写缓存。根据云计算中写数据生命周期和共享需求不同的特点，VMCache可以写数据分为临时数据，内存交换数据和用户数据，针对各种数据特点，客户端可以采取不同的写入策略，只需将UD数据写入服务器，MD和TD数据可以存储在VMM本地，通过区分不同的数据类型，过滤了一些不必要上传到服务器的数据，减少了服务器资源的浪费，从而减少了服务器数据的读写操作；并且，对于TD数据，在缓存中积攒到一定量，再写入日志磁盘，从而避免了日志磁盘的频繁读写操作。

本实施例的虚拟机存储***实现方法，通过加入非易失性磁盘，克服写突发引起的拥堵问题，防止数据掉电丢失；客户端将数据分类，从而只需将UD数据写入服务器，MD和TD数据可以存储在VMM本地，从而减少了服务器数据的读写操作；并且，对于TD数据，在缓存中积攒到一定量，再写入日志磁盘，从而避免了日志磁盘的频繁读写操作。

在一个实施例中，示出了一种具体地虚拟机存储***实现方法示例，本实施例中与以上实施例相同的组件或步骤具有相同的功能，为简明起见，省略对这些组件或者步骤的详细说明。

具体地，图3A示出本发明一实施例的虚拟机存储***实现方法的VMCache的结构图，如图3A所示，VMCache主要包括三个主要模块：内存缓存31、日志磁盘32及控制器30。内存缓存31可以是指由VMCache管理的独立于客户端操作***的内存空间。为了避免与客户端操作***内部写缓存重复，VMCache中的内存缓存31用于保存TD类型的写数据，主要作用是将零碎的TD写请求聚集起来统一提交，减少日志磁盘32的访问次数和空间碎片。

日志磁盘32可以是附加在客户端上的磁盘，也可以是独立的磁盘，该磁盘以日志结构的形式进行管理，用于缓存客户端运行时产生的各种写数据。日志磁盘32具有三个功能：第一、对于生命周期为一次开关机的数据如TD、MD，将吸收所有写数据的上传请求；第二、当服务器繁忙时，可以通过缓存UD数据以减小写突发对***性能的影响；第三、当客户端或服务器发生意外重启时，可以帮助***恢复UD类型数据。

控制器30是VMCache的核心，主要负责控制内存缓存31、日志磁盘32及服务器之间的数据转移、定位读写请求的存储块及管理内存缓存31和日志磁盘32的存储空间。控制器30中定义了相关的数据结构，包括用于数据定位的块哈希表和块位图，用于日志磁盘32管理的日志头、尾指针和空闲块位图等。

VMCache可以根据不同类型数据的特点来采取不同的缓存策略。图3B示出本发明一实施例的虚拟机存储***实现方法的流程示意图，如图3B所示，当VMCache收到写请求时，分类器34可以先根据写请求数据的类型，将写请求数据调度到不同的等待队列。不同队列中的请求会按照各自的特点区别对待：TD类型数据每次写入的数据块较小，VMCache的内存缓存管理器35会将其先缓存到内存缓存31中，然后再把若干个写请求合并为一个写请求(例如将4个TD数据的数据合并为一个写请求数据)，提交给日志磁盘32。MD类型数据可以是由于客户端操作***内存空间不足以维持当前所有进程同时工作，从客户端操作***管理的内存中分离出一部分到VMM中作为MD的缓存而产生的，其作用不大，所以VMCache可以将MD类型数据直接写入日志磁盘32。TD和MD的生命周期可以在一次开关机之间，也就是说这些数据在客户端重新启动后可以清空，而且在一次开关机内的MD和TD的写入量(2G左右)比日志磁盘32的容量要小得多，可以认为日志磁盘32不会被MD和TD写满，因此，VMCache可以将TD和MD缓存在客户端，不必上传到服务器。但是，UD类型的数据在客户端重新启动后依然有意义，基于对UD安全性的考虑，VMCache可以不在内存缓存31中缓存UD，而是直接将其写入日志磁盘32中。根据服务器状态，VMM可以将缓存在客户端的UD最终将上传到服务器。

本实施例的虚拟机存储***实现方法，在接收到写请求之后，通过将写请求数据缓存在虚拟机缓存中，并根据数据类型和服务器的状态决定是否上传或何时上传，可以解决云计算中虚拟机存储***中由写突发而产生的拥堵问题，防止数据掉电丢失，并减少了服务器数据的读写操作，并且对于TD数据，在缓存中积攒到一定量，再写入日志磁盘，从而避免了日志磁盘的频繁读写操作。

在一实施例中，示出了一种虚拟机存储***实现方法中的虚拟机缓存管理方法。本实施例中与上述实施例相同的组件或步骤具有相同的功能，为简明起见，省略对这些组件或者步骤的详细说明。

具体地，VMCache的缓存管理可以包括：页面映射管理、内存缓存管理以及日志磁盘管理。具体地，图4A示出本发明一实施例的虚拟机存储***实现方法的页面映射管理的示意图，如图4A所示，根据存储空间中的页面是否被更新过，客户端可以将虚拟存储空间中的页面分为更新页面和原始页面。其中，更新页面是指被客户端操作***11修改过的，并在客户端缓存的页面，如图4A中页面1～3。这些页面已在页哈希表42(PageHashTable，PHT)中登记，其中，页哈希表42是控制器中重要的数据结构之一，页哈希表42可以用于记录虚拟存储空间中被改动的页面在客户端缓存中的位置，可以通过查询PHT找到它们的位置。原始页面是指客户端操作***未改动过或已从客户端缓存中清除的页面，如图中页面4～5。这些页面在PHT中没有对应表项，需要访问服务器才可以获得。PHT与虚拟存储空间一一对应，可以通过虚拟磁盘表(VirtualDiskTable，VDT)的PHT指针字段进行访问。

图4B示出本发明一实施例的虚拟机存储***实现方法的内存缓存布局的示意图，如图4B所示，内存缓存由缓存头(RAMHeader)和若干页面(Pages，PGs)组成。其中，缓存头中包括vdisk_id、倒排表及FIFO队列的头部和尾部。在VMCache中，可以设定只有保存TD类型数据的虚拟磁盘才能拥有内存缓存，不同的虚拟磁盘之间不能共享内存缓存。其中，vdisk_id是指拥有该内存缓存实例的虚拟磁盘id；倒排表是以内存缓存中的页面为索引，记录缓存中每个页面与虚拟存储空间中页面的映射关系；FIFO头、尾指针则分别标记了页面分配和回收的位置。

图4C示出本发明一实施例的虚拟机存储***实现方法的日志磁盘结构示意图，如图4C所示，日志磁盘存储空间40可以被划分为一个超级块和两个分区。超级块中可以保存日志磁盘的配置信息，如段大小、分区0和分区1的起始与终结页面号等。分区0主要负责缓存TD和MD类型数据，分区1则负责缓存UD数据。两个分区的结构相同，都是由分区头和若干段组成，分区头记录了指向控制段的指针。段由段头和若干页面组成，段头包括vdisk_id、页倒排表、页位图及段类型4部分，前两个部分与内存缓存头中的对应数据结构的意义相同，页位图主要记录段中的有效页面。段类型有四个可选值，分别为分配段(AssignmentSeGment，ASG)、提交段(CommittingSeGment，CSG)、回收段(RecycleSeGment，RSG)及数据段(DataSeGment，DSG)。前三个类型被统称为控制段，具有标识、管理功能，能够用于标识数据段状态，负责分割不同状态的数据段。除控制段以外，其他所有的段都属于数据段。数据段不具备管理功能，仅用于缓存数据。

为了便于描述，可以给段定义四种状态：空闲(Free)：该数据段处于空闲状态，没有任何数据写入该块；占用(Occupied)：该数据段已缓存数据但尚未提交；提交(Committing)：已经将该数据段的内容提交到服务器，但尚未收到服务器的确认；可用(valid)：收到服务器提交成功的确认并且数据段中的内容与服务器上的对应页面一致。

由于分区0不存在上传服务器的问题，因此其中的段只可能处前两种状态，即空闲或者占用。反之，分区1中段的则可能处于上述4种状态之一。

图4D示出本发明一实施例的虚拟机存储***实现方法的段状态转移的示意图，如图4D所示，段状态转换具体可以包括：写(write)，从内存缓存或者客户端操作***中写入数据到日志磁盘中；提交(commit)：将数据上传到服务器，服务器返回收到的报文确认；提交确认(committedack)：服务器返回确认信息，表明服务器已经将数据写入服务器端的磁盘中；重写(rewrite)：数据段中涉及的页面被上一层修改。

图4E示出本发明一实施例的虚拟机存储***实现方法的段布局的示意图，如图4E所示，日志磁盘分区1中包括不同状态段，在一般情况下，相同状态的段聚集在一起会组成连续的存储空间。不同状态的段则由控制段隔开；ASG是空闲段和占用段边界上的空闲段，CSG是占用段和提交段边界上的占用段，RSG是提交段和可用或空闲段边界上的提交段。值得注意的是，控制段中也可能包含缓存数据，与数据段唯一不同的是控制段的段类型字段的值不是DSG。所以，当数据段状态发生变化时，控制段需要进行相应的调整。若***发生意外重启，故障恢复例程只要扫描一下日志磁盘，就可以恢复到启动前的数据段状态。同时对需要上传的数据段进行区分，保证了UD数据的安全性。

由于扫描整个日志磁盘寻找控制段的时间开销比较大，通常需要几十秒甚至数分钟。为了减少这一开销，可以在分区头中保存指向控制段的指针。这样，启动时只需查询分区头中的指针，就可以定位控制段。但这种方法会出现一个问题是在每次段状态改变时，都需要同步更新控制段指针，这就使得每次写操作都需要改写磁盘上的2个不同位置，从而导致写性能的大幅下降。可以采取定期更新的策略解决这个问题。就是先把这三个指针保存到内存中，每隔一定间隔将磁盘写入一次。该方法实际上就是通过延迟更新来减少了磁盘的写入次数和随机写的概率。当发生意外重启时，分区头中的控制段指针可能已经过时，无法指明控制段的正确位置，此时仍需要通过扫描磁盘的方法来寻找控制段。不过，由于控制段的位置应该在控制段指针所指位置的附近，因此根据控制段指针的提示来扫描磁盘也可以很快的找到，无需扫描整个磁盘。

本实施例的虚拟机存储***实现方法，VMCache引入内存和日志磁盘组合的双层缓存结构，以及基于控制段的日志磁盘管理方法，一方面，可以将不需要上传的写数据保留在客户端，减少读写流量；另一方面保证了***意外重启时，用户数据不丢失；并且，对于TD数据，在缓存中积攒到一定量，再写入日志磁盘，从而避免了日志磁盘的频繁读写操作；VMCache满足云计算需求，可以有效的提升各种类型数据的写性能。

在一实施例中，示出了虚拟机存储***实现方法中的读写方法的示例。本实施例与上述实施例相同的组件或步骤具有相同的功能，为简明起见，省略对这些组件或者步骤的详细说明。

具体地，该虚拟机存储***实现方法还可以包括：

接收客户端操作***的读请求。

根据读请求在虚拟机缓存中查找读请求对应的数据。

进一步地，图5A示出本发明一实施例的虚拟机存储***实现方法中读方法的流程图，如图5A所示，该读方法的流程包括：

步骤S302，客户端操作***发起读请求，读请求的参数可以为<vdisk_id，init_sec，sec_no>，其中init_sec是访问存储区的起始扇区，sec_no是访问扇区的数量。

步骤S304，根据该读请求，查询分页，查询时采用的算法为PGi(i＝1～n)。VMCache以页面为单位，将访问存储区划分为若干个页面PG1～PGn，这样每个请求页面就可以通过<vdisk_id，page_id，sec_bitmap>三元组进行描述。sec_bitmap主要可以用于描述页面中的需要访问扇区在访问存储区尺寸小于页面时的情况。sec_bitmap中的每一个比特代表页面中的一个扇区，1表示对应扇区需要被访问。VMCache可以依次读取每个页面。

步骤S306，对任意一个页面的PGi，以PGi的page_id为索引，在PHT[vdisk_id]中检索对应的表项。若没找到，则表明所需页面不在客户端缓存中，则执行步骤S307；如果找到，则执行步骤S308。

步骤S307，向服务器请求页面。

步骤S308，从内存缓存或日志磁盘中读取页面。例如，设检索到的页面为PGk，从内存或者日志磁盘中读取PGk。

步骤S310，比较扇区位图。可以比较PGk中的有效扇区能否“覆盖”PGi中要访问的扇区，其算式可以为(PGk->sec_bitmap^PGi->sec_bitmap)&PGi->sec_bitmap>0？)；若能覆盖，则读取该页面，并执行步骤S314；若不能覆盖，则执行步骤S312。

步骤S312，向服务器请求页面。根据步骤S310的判断结果，若PGk中的有效扇区不能“覆盖”PGi中要访问的扇区不能覆盖，则从服务器下载PGi。

步骤S316，按扇区位图合并页面，更新缓存中页面。根据sec_bitmap将服务器上的下载页面合并。

步骤S314，判断读请求是否完成。即通过算法ifi＝n？判断是否读取完成，若判断结果为肯定，表示读取完成；若判断结果为否定，则继续读取下一个页面。读取下一个页面时将重复上述过程，直到所有页面读取完毕。

进一步地，图5B示出本发明一实施例的虚拟机存储***实现方法中写方法的流程图，如图5B所示，假设客户端操作***发起写请求，写请求的参数可以为参数为<vdisk_id，init_sec，sec_no>，写请求操作可以根据写数据类型的不同来执行不同的工作流程。具体可以包括以下步骤：

步骤S402，客户端操作***发起写请求，读请求的参数可以为<vdisk_id，init_sec，sec_no>，其中init_sec是访问存储区的起始扇区，sec_no是访问扇区的数量。

步骤S404，判断该写请求数据是否为TD数据。其判断算法可以为ifVDT[vdisk_id]->type＝TD？若判断结果为是，则执行步骤S406，否则执行步骤S415。

步骤S406，VMCache对访问存储区进行分页。

步骤S408，判断该页面是否在内存中存在。设当前页面为PGi，VMCache在PHT[vdisk_id]中搜索PGi对应的页面，若找到，则说明该页面在内存中存在，则执行步骤S410，更新目标页面，修正sec_bitmap值；否则执行步骤S413。

步骤S413，判断缓存中是否有空闲空间，若是，则执行步骤S414，分配一个空闲页面进行写入；否则，表示空间已满，待提交操作回收空间后，重新执行页面写操作。

步骤S411，判断写算法是否完成。其中，通过算法i＝n？判断是否执行完该写算法。若是，则执行步骤S412，写操作完成，否则继续写下一页。

步骤S412，VMCache对访问存储区进行分段，依次写入日志磁盘。分段算法为分段SGj(j＝1...m)。

步骤S416，判断写请求数据类型是否为MD数据。若是，则执行步骤S417，否则，表示该数据为UD数据，执行步骤S419，将UD类型数据可以直接写入日志磁盘分区1中。

步骤S417，写入日志磁盘分区0。具体可以包括对访问存储区进行分段，然后再依次写入每个数据段，更新PHT表。

步骤S419，判断日志磁盘分区1是否有空闲段。若判断结果为是，则表明日志磁盘1未满，则执行步骤S420；若判断结果为否，表明日志磁盘1已满，则待提交操作回收空间后，重新执行写入算法则执行步骤S420。

步骤S420，分配一个空闲段，将写请求数据写入日志磁盘分区1。具体可以包括对访问存储区进行分段，然后再依次写入每个数据段，更新PHT表。

步骤S418，判断写算法是否完成。其中，通过算法j＝m？判断是否执行完该写算法。若是，则执行步骤S412，写操作完成，否则继续写下一段。

本实施例的虚拟机存储***实现方法，在接收到读写请求之后，根据数据类型和服务器的状态决定是否上传或何时上传，可以解决云计算中虚拟机存储***中由写突发而产生的拥堵问题，防止数据掉电丢失。

在一实施例中，示出了虚拟机存储***实现方法中的提交方法的示例。本实施例与上述实施例相同的组件或标号相同的步骤具有相同的功能，为简明起见，省略对这些组件或者步骤的详细说明。

具体地，提交操作是指将“脏”数据从高层缓存写入低层缓存或存储器，然后回收高层缓存空间的过程。VMCache通过后台线程来实施内存缓存和日志磁盘中的数据提交与空间回收。在提交策略中，可以根据提交时机和频率确定提交策略。一种可能的提交策略是积极提交策略，即频繁进行提交，其优点是数据安全性更好，高层缓存经常处于空闲状态，能够有效的处理写突发；缺点是轻负载时高层缓存不但不能有效的减少写流量，反而增加了一层数据拷贝。另一种可能的提交策略是消极提交策略，其优点是能够吸收同一页面的重复写操作，便于针对写操作内容进行优化；其缺点是数据安全性差，由于高层缓存处于常满状态，因此对突发写性能的提升不明显。影响提交策略的因素主要有两个：一个是高层缓存中被占用的缓存块占总容量的比例，也就是缓存“满”的程度，可以简称为占用度；另一个是数据的安全性，也就是数据对可靠性的敏感程度可以简称为可靠敏感度。

在考虑占用度和可靠敏感度的情况下，可以采用一个三元组模型<t_low，t_high，T>来描述提交策略。其中t_low和t_high是表示占用度的两个阈值(t_low<t_high)，可以用t_low和t_high来表示占用度对提交策略的影响。设Co表示当前缓存占用度，当C0<t_low时，不执行提交；当t_low<C0<t_high时，执行空闲时提交；当C0>t_high时，执行“尽力而为”提交。

不同的提交策略可通过调整t_low和t_high来实现。例如t_low越大，提交频率越低，提交策略越消极。在极端情况下，当t_low＝1时，***会在缓存满之后执行提交操作。相反，t_high越小，提交频率越低，提交策略越积极，当t_high＝0时，每次写入缓存后都会“尽力而为”的进行提交。若处于t_low和t_high的中间地带，则说明这个区间的占用度对提交策略的影响不大，***可以根据忙闲情况，自行确定提交时机。

三元组中的最后一个元素T表示相邻两次提交时间间隔的最大值。当距离上次提交时间超过T时，***将启动提交操作，以防止数据丢失。T体现了可靠敏感度对提交策略的影响。在VMCache中，TD和UD的缓存设计涉及到提交的问题。其中TD在***重新启动后会自动清空，所以可靠敏感度不高，T值可设置为无限大；UD的可靠敏感度较高，但UD缓存在日志磁盘的缓存中，在***突然断电或重新启动后，缓存中的数据不会丢失，所以T值也无需设置太小。然而，如果缓存数据长期滞留在客户端，也存在一定的风险。例如：如果用户登陆的客户端A在关闭时，缓存中的UD数据未能上传到服务器，那么用户在其他客户端B登陆时，就无法访问到最新数据。因此T不能设置为无限大。因此，按照工程经验，可将T的值设置为5～10分钟。

在一实施例中，示出了虚拟机存储***实现方法中的故障恢复方法的示例。本实施例与上述实施例相同的组件或标号相同的步骤具有相同的功能，为简明起见，省略对这些组件或者步骤的详细说明。

具体地，客户端及服务器在出现意外重启时，VMCache可以保证UD类型数据的安全性或可恢复性。

例如，若客户机意外重启时，可以从客户端恢复UD数据。图6示出本发明一实施例的虚拟机存储***实现方法中数据恢复方法的流程图，如图6所示，该方法具体可以包括：

步骤S602，读取日志磁盘中保存的控制段；

步骤S604，从控制段开始扫描日志磁盘，找到分配段、提交段所标识的数据段；

步骤S606，依次上传分配段、提交段所标识的数据段；

步骤S608，上传完毕后，正常启动客户端操作***。

具体地，VMCache通过日志磁盘中的控制段来记录重启前的数据状态。当客户端重新启动后，VMCache将按照如下算法，上传未保存UD数据：1)读取分区1在分区头中保存的控制段指针；2)从控制段指针开始扫描日志磁盘，找到ASG、CSG和RSG；3)依次上传ASG到RSG之间的数据段；4)恢复完毕，正常启动***。这样，可以在服务器或者客户端发生意外重启时，能够保证数据不丢失。

进一步地，为防止服务器意外关闭，确保服务器数据仍然保留在客户端，本发明提出了一种延迟提交确认方法。图7示出本发明另一实施例的虚拟机存储***实现方法中延迟提交确认方法的流程图，如图7所示，该方法可以包括：

步骤S702，将日志磁盘中的数据段提交到服务器。

步骤S704，当接收到服务器返回的接收确认，更改该数据段的控制段为提交段。

步骤S706，当接收到服务器返回的提交确认，更改该数据段的控制段为可用段。

步骤S708，回收该可用段标识的数据段。

具体地，当客户机的数据上传到服务器后，服务器先将数据缓存在内存中来提升性能。然而，当服务器发生意外重启时，内存中的数据就可能会丢失。为了防止这种情况的发生，VMCache可以采用延迟提交确认的机制：在客户机上的一个数据段上传到服务器后，服务器仅返回接收确认给客户端。客户端收到确认后，再将数据段的状态调整为提交状态，其中，提交状态的数据段必须保留，不允许回收。服务器把客户机提交的数据段写入磁盘后，会发送提交确认，这时数据段的状态才会转移为可用。在***需要时，可以对可用状态的数据段进行回收。这种延迟确认机制可以在服务器发生意外关闭时，确保服务器内存中的数据仍然保存在客户端的数据段中。因此，在故障恢复后，只需请求客户端重新上传处于提交状态的数据段，就可以恢复数据。

图8示出本发明一实施例的虚拟机存储***实现装置的结构框图。如图8所示，该虚拟机存储***实现装置800主要包括：

接收模块802，用于接收客户端操作***的写请求；

缓存模块804，与接收模块802相连接，用于将写请求数据缓存在虚拟机缓存中；

控制模块806，与缓存模块804相连接，用于根据服务器的状态将写请求数据上传到服务器。

本实施例的虚拟机存储***实现装置，在接收到写请求之后，通过将写请求数据缓存在虚拟机缓存中，并根据服务器的状态将写请求数据上传到服务器，可以解决云计算中虚拟机存储***中由写突发而产生的拥堵问题。

在一实施例中，控制模块806还用于：

在一个实施例中，缓存模块804还用于：

将写请求数据缓存在非易失性存储器。

在一个实施例中，控制模块806还用于：

根据写请求数据的类型将写请求数据上传到服务器。

在一个实施例中，控制模块806还用于：

若写请求数据为内存交换数据和/或临时数据，则将写请求数据存储在非易失性存储器。

在一个实施例中，控制模块806还用于：

若写请求数据为临时数据，将临时数据缓存到内存中；

将至少一个临时数据合并为总临时数据后，存储到非易失性存储器。

在一个实施例中，控制模块806还用于：

将日志磁盘中的数据段提交到服务器；

当接收到服务器返回的接收确认，更改数据段的控制段为提交段；

当接收到服务器返回的提交确认，更改数据段的控制段为可用段；

回收可用段标识的数据段。

在一个实施例中，非易失性存储器包括日志磁盘。

在一个实施例中，若客户端或服务器发生意外重启时，控制模块806还用于：

读取日志磁盘中保存的控制段；

依次上传分配段、提交段所标识的数据段；

上传完毕后，正常启动客户端操作***。

在一个实施例中，接收模块802还用于：接收客户端操作***的读请求。控制模块806还用于：根据读请求在虚拟机缓存中查找读请求对应的数据；若在虚拟机缓存中查找到读请求对应的数据，则读取数据，若在虚拟机缓存中未查找到读请求对应的数据，则将读请求发送到服务器。

在一实施例中，本发明还提供了一种虚拟机存储***，包括：配置虚拟机存储***实现装置的客户端；服务器，与客户端相通信，用于为客户端的用户提供服务。

本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。

Claims

1.一种虚拟机存储***实现方法，其特征在于，包括：

接收客户端操作***的写请求；

将所述写请求数据缓存在虚拟机缓存中；

根据服务器的状态将所述写请求数据上传到所述服务器。

2.根据权利要求1所述的方法，其特征在于，根据服务器的状态将所述写请求数据上传到所述服务器包括：

判断所述服务器的状态，若所述服务器的状态为空闲，则将所述写请求的数据上传到所述服务器，若所述服务器的状态为繁忙，则将所述写请求数据缓存在所述虚拟机缓存中。

3.根据权利要求1所述的方法，其特征在于，

将所述写请求数据缓存在虚拟机缓存中包括：将所述写请求数据缓存在非易失性存储器；

和/或

所述方法还包括：

根据所述写请求数据的类型将所述写请求数据上传到所述服务器。

4.根据权利要求3所述的方法，其特征在于，

根据所述写请求数据的类型将所述写请求数据上传到所述服务器包括：

若所述写请求数据为用户数据，则将所述写请求数据上传到所述服务器；和/或

若所述写请求数据为内存交换数据和/或临时数据，则将所述写请求数据存储在所述非易失性存储器；

和/或

所述方法还包括：

若所述写请求数据为临时数据，将所述临时数据缓存到内存中，将至少一个临时数据合并为总临时数据后，存储到所述非易失性存储器。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述非易失性存储器包括日志磁盘。

6.根据权利要求5所述的方法，其特征在于，若客户端或服务器发生意外重启时，还包括：

读取日志磁盘中保存的控制段；

从所述控制段开始扫描所述日志磁盘，找到分配段、提交段所标识的数据段；

依次上传所述分配段、提交段所标识的数据段；

上传完毕后，正常启动客户端操作***。

7.根据权利要求5所述的方法，其特征在于，还包括：

将日志磁盘中的数据段提交到服务器；

当接收到所述服务器返回的接收确认，更改所述数据段的控制段为提交段；

当接收到所述服务器返回的提交确认，更改所述数据段的控制段为可用段；

回收所述可用段标识的数据段。

8.根据权利要求1至4中任一项所述的方法，其特征在于，还包括：

接收客户端操作***的读请求；

根据所述读请求在虚拟机缓存中查找所述读请求对应的数据；

若在所述虚拟机缓存中查找到所述读请求对应的数据，则读取数据，若在所述虚拟机缓存中未查找到所述读请求对应的数据，则将所述读请求发送到服务器。

9.一种虚拟机存储***实现装置，其特征在于，包括：

接收模块，用于接收客户端操作***的写请求；

缓存模块，与所述接收模块相连接，用于将所述写请求数据缓存在虚拟机缓存中；

控制模块，与所述缓存模块相连接，用于根据服务器的状态将所述写请求数据上传到所述服务器。

10.根据权利要求9所述的装置，其特征在于，所述控制模块还用于：判断所述服务器的状态，若所述服务器的状态为空闲，则将所述写请求的数据上传到所述服务器，若所述服务器的状态为繁忙，则将所述写请求数据缓存在所述虚拟机缓存中。

11.根据权利要求9所述的装置，其特征在于，

所述缓存模块用于将所述写请求数据缓存在非易失性存储器；

和/或

所述装置还包括：

所述控制模块还用于根据所述写请求数据的类型将所述写请求数据上传到所述服务器。

12.根据权利要求11所述的装置，其特征在于，

所述控制模块还用于：

和/或

所述装置还包括：

所述控制模块还用于若所述写请求数据为临时数据，将所述临时数据缓存到内存中，将至少一个所述临时数据合并为总临时数据后，存储到所述非易失性存储器。

13.根据权利要求9至12中任一项所述的装置，其特征在于，所述非易失性存储器包括日志磁盘。

14.根据权利要求13所述的装置，其特征在于，若客户端或服务器发生意外重启时，所述控制模块还用于：

读取日志磁盘中保存的控制段；

依次上传所述分配段、提交段所标识的数据段；

上传完毕后，正常启动客户端操作***。

15.根据权利要求13所述的装置，其特征在于，所述控制模块还用于：

将日志磁盘中的数据段提交到服务器；

回收所述可用段标识的数据段。

16.根据权利要求9至12中任一项所述的装置，其特征在于，还包括：

所述接收模块用于：接收客户端操作***的读请求；

所述控制模块还用于：

17.一种虚拟机存储***，其特征在于，包括：

配置有至少一个如权利要求9至16中任一所述的虚拟机存储***实现装置的客户端；

服务器，与所述客户端相通信，用于为客户端的用户提供服务。