可软件定义的存储逻辑二——Energy适应性的分布式存储系统

这个论文[3]提出了一个灵活的、可扩展的分布式存储系统，给它取名字flexStore。这个分布式存储系统可以非常好的适应数据中心中不停变化的能源，给去重的虚拟机磁盘IO存取带来很好的性能。研究人员研究并提出了一种智能的控制来对付数据中心供电的限制，因为有可能存储阵列的节点密度增加了，也有可能绿色能源和传统能源混合一起给数据中心供电。在这个存储框架中最重要的一个部件就是处于框架当中的策略引擎（policy
engine），他是一个软件层，给应用程序提供自定义性能需求的接口，当然也提供能源相关的策略。然后策略引擎通过不断调整存储资源分配的方式，将这些策略在存储系统中实施。

最后他们还做了一些实验。实验表明这个系统可以很好的适应工作负载（workload）和供电限制的变化，系统的目标是最小化这个变化对性能的影响。原型还显示这个适应性的备份策略在供电充足的情况下，可以减少大概65%的IO延迟，而在供电不足的情况下可以减少大于40%的IO延迟。

note: 我在之前的那个可软件定义的存储逻辑的那个博客中，是这么描述那个论文的：“ 这篇论文和IOFlow相比较，更加注重软件定义存储的框架（是利用已有的框架来创建新的框架，然后使用已有的协议），而不是像IOFlow那样注重通信的协议。并且，这个框架还是软件定义环境的框架，而不仅仅是存储的框架，不过全文注重说了存储（更有挑战性）...”那个文章比较全面的定义了软件定义存储的框架，并且和SDE结合在一起;而这个论文专注于energy
adaptive的replica系统。

green energy

首先介绍了一个叫做可扩展存储架构（scale-out storage architecture）的技术，在这种架构中，性能和可靠性至关重要，所以往往需要在多个节点中复制某个数据块，但是多副本消耗了更多的资源，给数据中心带来了增大的cost。除了复制策略，数据中心也可能用到网络RAID技术，但是这种技术在资源消耗方面更加昂贵，也会影响在高负载情形下的性能。

除了性能和可靠性，对于数据中心的存储系统，能耗也是一个至关重要的因素。有一个调查显示存储能耗在整个数据中心的能耗中占40%以上。所以现在大型研究都在寻求绿色能源来供给，而绿色能源的使用给数据中心的供电情况带来了变化，考虑到绿色能源的特点，能源的充足和缺乏在不停的变化着，有时候能源可能会缺乏。比如google有一个green计划，他的首页是这么说的：

“在 Google，我们一直致力于全部使用可再生能源来支持我们的企业运营。除了考虑可以带来的环境效益外，我们也把可再生能源视为一种商业机遇，并持续投资以加速其发展。我们相信，通过使用可再生能源来支持网络运作，我们将为每个人创造更美好的未来。”



所以数据中心架构和服务需要适应这种绿色能源（green）的变化性和不确定性，当绿色能源供给不足的时候，且作为备份的常规能源电网也不可用时，即使如此，性能的下降也需要在让人能够接受的程度。而当绿色能源充足时，就完全不需要消耗常规能源（来自电网）。这种灵活的操作对于将绿色能源集成到数据中心是非常重要的。对于这种需求，这些研究者先前已经研究过EAC（ENERGY
ADAPTIVE COMPUTING），在数据中心中提供智能控制，关闭过度供给的能源并且自动适应变化的可用的能源供给。软件定义存储SDS的出现为存储提供了更好的管理接口，本文提出的flexStore就是一个软件定义的能自适应和管理存储资源的系统。

系统设计目标、架构和原型实现

在green energy的数据中心，为了容灾，虚拟机备份是很重要的，当使用的green energy的能源充足，备份数可以多一点，当能源不足时，我们也可以通过适当的减少虚拟机的备份数量来适应能源的备份。那么怎么样的调整，才能使在满足能源的要求时，使得性能的减少最少来保证QoS呢？这也是这个flexStore架构的目标。为了达到这个目标，我们需要首先分析一下能源和性能的关系。

虚拟机去重

为什么虚拟机需要去重？因为数据中心有很多的虚拟机，但是往往虚拟机走着相同的操作系统和配置，所以存放的时候可以去重，可以大量的减少磁盘空间。

去重一般来说怎么做？

去重有哪些难度？

很多论文中都提到了，比如[1][2]。但不是写作此文的目的。

虚拟机副本模型

为了数据的安全和数据中心的容错性，一般会给虚拟机创建几个副本，但是为了性能或者容错性的不同，有几个不同的模型，这里给出了三种模型。

强一致性：写操作，当全部副本都写入后，再返回；

弱一致性：写操作，当一个副本写入后就返回，只有需要换副本的时候，再复制；

flexstore模型：写操作，当一个副本写入后就返回，每隔一定的时间同步副本。

A：性能和能源的关系

数据中心副本的使用是为了数据的容灾，另一方面是为了虚拟机负载平衡的需要。在多虚拟机的情况下，随着数据副本的增加，IO延迟会减少（多虚拟机分布式的访问replica，replica越多，IO队列越小，IO延迟越小），但是副本的增大使得能源消耗增加。所以在使用绿色能源的数据中心，能源的限制导致了数据副本数的减少，IO延迟增大。如果能源充足的话，数据可以有足够的副本数，也就不会影响数据的延迟。

如下图所示。随着VM副本数的增加，IO延迟变小，能量的消耗变大。



在使用虚拟化的大型数据中心中，一个很具体的应用就是：虚拟机去重，然后多副本存储在下层的存储系统中。我们考虑虚拟机环境的工作方式，设计了flexStore架构（要保证虚拟机磁盘的性能，也要做到去重）。

B：flexStore的组件

flexStore的组件如图2。这个论文按照data plane和Control plane的方式来介绍flexStore的组件。Data
plane是异构的存储系统with 不同类型的存储设备，而Control plane控制平面提供了可编程的接口使得可以控制数据的放置和布局。

数据中心虚拟机的环境和虚拟机管理按照下面描述的Metadata 管理和Chunk storage 所述。

Metadata管理：元数据管理器组件放在FUSE文件系统上面（这个文件系统用来存放 VM 的disk chunks），这个文件系统还需要执行去重的功能，也作为“适配器”层为虚拟机提供“块语义“。

Chunk storage: VM的disk划分为chunk object存放在下层的存储设备上面，传统的存储系统为了使用存储通常使用LUN（块存储）或者NAS 卷（文件存储）的统一接口，而flexStore通常使用replica的接口。这个存储系统是一个分布式的对象存储系统（SHA1
hash）。flexStore存储系统给一个chunk提供几个备份。虚拟机在某个时候只分配给某个副本，并且读写那个副本。



那么data plane做了什么呢？虚拟机的卷创建好了之后，虚拟机就可以直接读写这个卷了。Host上面会有必要的设备驱动或者hypervisor来和不同的存储系统进行通信。这个驱动的主要作用就是将VM的块请求传递给下层的存储系统。另外data plane中还包含计数器和monitor，来监控读写请求的数目，以及相关的延迟，然后把监控到的数据传递给Policy
engine，PE(Policy engine)再根据系统的情况按照某些算法自动执行相关的策略。也提供了接口使得可以控制平面可以控制数据的layout，比如在energy不充足的时候将数据整合到更少的磁盘上面去，这些接口对应着控制平面的（migratedata across storage devices/replicas等）。

原型实现

Metadata manager

• Chunk 存储：replica

• FUSE模块（VM的磁盘挂载在FUSE目录中）

• Process：当VM执行任何vdisk的IO操作时，metadata manager会将这个IO请求转化为固定大小的chunk（SHA1 Hash）；在内存中维持一个hashmap；metadata manager通过thrift
client和存储系统交互。

底层存储系统（storage system）

• Thrift server和元数据管理的thrift client交互（key-valve：SHA1 哈希值和存储的chunk）

• 也和policy engine的client交互

通过getLogSize() API来得到new chunk 的amount，并且告知policy engine的client（Log用来存储新的chunk，当同步的时候只有这些new chunk才同步）；而Policy engine client的相关策略比如data
transfer传递给存储系统。

Policy engine

• 分布式的：每个host上面的client+central coordinator

• Client：和meta data manager交互来收集信息：比如VM disk file的访问次数，磁盘节点的访问次数，然后将这些local state告知central

• client+central coordinator：维持a global view of the system:存储节点数，活跃的host数目和可用的power

• Central coordinator定期向client搜集信息。然后将global信息反馈给client，client再选择the list loaded nodes来存储data或者move data。

• Client 会在以下情况发起data transfer操作：

1）replica上面不同步的数据大小超过阈值

2）replica上的load超过了阈值

3）VM disk的IO延迟超过了阈值

4）the replica 要关闭了，或者一个新的replica要开启了。

实际的数据转移只发生在nodes之间。

C:适应的副本一致性（和energy相关）算法

副本总是需要同步的，而在flexStore模型系统中，我们让副本每隔一定的周期（假设这里是当某个replica的log文件（new chunks）大小达到了阈值，然后这个replica开始diverging，这个replica的其他副本开始和它同步）。当满足这个副本的power和带宽的条件下，怎样分流才能够使得分流最大，也就是说能同步的replica越多，会使得workload的QoS越大。这里采用的适应性的副本一致性算法也就是要解决这样一个问题。

考虑一个有N个副本的数据中心，如下图所示，虚拟机被分配给一个replica，而且这个replica负责虚拟机的读写。当新的chunk加入这个replica，这个replica还要不停的分流，使得其他的副本保持一致性。



论文中对这个算法描述的很清楚，大概如下：








这 是一个整数线性规划问题，当N=2/3的时候，policy engine可以在很快的时间内求得最优解......

实验和评价

实验环境是Amazon的IaaS平台:

• 4 EC2 M1.xlarge instances that have 4vCPUs and 15 GB of RAM each as the storage nodes which ran the storage software

• 8 EC2 M1.large instances that have 2 vCPUs and 7.5 GB of RAM each were used as hosts on which the metadata manager component and the distributed policy engine module ran

• All EC2 instances ran Ubuntu Server 13.04 as the operating system.

• A maximum of 4 VMs on each of the hosts.

两种workload：Fio和MSR Cambridge trace

Fio：压力测试

MSR Cambridge trace：模拟真实环境中的数据

去重率：25%-75%

• Fio： a standard benchmark to evaluate file system workloads

• MSR Cambridge trace： The traces were collected over a period of 7 days from 36 different volumes in a Microsoft datacenter。

• each VM replayed one out of the four traces. The use of real workload traces in the evaluations helps to demonstrate the behavior of flexStore in a real datacenter.

实验1：系统 tradeoff

从图中可以看出：副本越多，IO延迟越小。通过这个实验可以发现：增加副本数可以减少多少IO延迟；从这个实验可以让我们知道怎么配置系统：因为减少的能源让系统的副本数变少, 我们需要动态的精确的知道系统的性能变化，并作出相应的权衡。

实验2:自适应的一致性

存储系统某个服务于VM的replica的logfile的大小（阈值）可以是个变量，通过图6我们知道：logfile大小为100M的时候，读写IO延迟最小，于是就选择这个logfile的大小当做是阈值（因为这个值会使得workload的read IO延迟最小）。然后实验测试了strong，weak和flexstore（用前面测试出来的这个logfile阈值）三种一致性模型的平均IO延迟。发现strong模型会使得写延迟很大，根据前面的分析这是显而易见的。而weak模型和flexStore的模型读写延迟差不多，当然改变那个logfile的大小可能会对实验结果有一些影响。

实验3：cache的影响

在VM的host端增大内存的大小，也就是增大了cache buffer。这样测试发现cache大的情况平均延迟比内存小的时候小一些。

VM的去重率和存储节点的cache大小也是影响延迟的一个很重要的因素。如果内存一样大，去重率为75%的比25%的延迟小，因为去重率高，肯定会有很多重复的数据在cache中，这样就可以减少cache不命中了。然后存储节点的RAM 内存越大，也表示这里的buffer cache越大，在相同去重率的情况下也将会导致更小的延迟。

实验4：energy adaptation

实验对比了weak和flexStore两种情况下对能源的适应，也就是当能源紧张的时候，副本数变少，这个时候IO延迟就会增大，但是weak模型会在一段时间内变得很大，然后再降下去（和flexStore一瞬间后增长到的一样），然后或者能源充足了，这个时候flexstore的IO延迟也就是突然变小了（而weak的这个时间要长的多），因为weak模型的其他关闭的replica没有总是在update，而flexStore的replica即使断电了，update也总是要进行的（利用grown能源），并且像SSD这样的设备也不怎么耗电。



另外当我们在计算一致性模型的时候我们发现其实分配给IO和同步的资源是可以相互制约的，所以我们通过在能源改变的时候，调节IO带宽，这也可以改变延迟。如果能够优化带宽，则能够带来更小的延迟。


。。。

为减少datacenter能耗的其它研究

写卸载技术（write offloading technique）[4]是为了将处于spun down状态的磁盘(为了减少数据中心的能源的消耗，将某些磁盘处于spun down状态（我猜就是让这些磁盘处于休息状态吧）)的写请求重定向到别的存储设备，之后等这个设备再次工作了再将这个数据块写回，总之是为了减少能源消耗的问题。

也有些人提出了MAID技术[5]，来代替原来的高性能RAID技术，同时又可以减少能耗。在一个系统中有一些作为cache的磁盘来存储热数据，而其他的非cache磁盘可以保持spun-down状态。

还有的研究设计了分布式的文件系统，优化数据在存储节点中的布局，使得有些节点在没有必要的时候可以关闭，以此来减少能耗[6]。以及一种去中心化的SAN去重技术[]。和前面这些提到的为了减少能耗的技术不同的是，flexStore能够更加灵活动态的去适应能源的变化。

参考文献

[1] http://www.cs.cuhk.edu.hk/~cslui/PUBLICATION/middleware11.pdf
[2] http://www.cs.cuhk.edu.hk/~cslui/PUBLICATION/middleware11.pdf
[3]M. Murugan, K. Kant, A. Raghavan and David H.C. Du, "flexStore: A software defined, energy adaptive distributed storage framework", IEEE 22nd International Symposium On Modeling, Analysis and Simulation Of Computer
And Telecommunication Systems (MASCOTS 2014), Paris, France.

[4]https://www.usenix.org/conference/fast-08/write-loading-practical-power-management-enterprise-storage

[5]http://www.cs.cmu.edu/~dga/15-849/S09/papers/maid-sc2002.pdf

[6]http://web.mit.edu/amdragon/www/pubs/dede-usenix09.pdf