标签:flexstore sds 分布式存储 绿色能源 deduplication replica
这个论文[3]提出了一个灵活的、可扩展的分布式存储系统,给它取名字flexStore。这个分布式存储系统可以非常好的适应数据中心中不停变化的能源,给去重的虚拟机磁盘IO存取带来很好的性能。研究人员研究并提出了一种智能的控制来对付数据中心供电的限制,因为有可能存储阵列的节点密度增加了,也有可能绿色能源和传统能源混合一起给数据中心供电。在这个存储框架中最重要的一个部件就是处于框架当中的策略引擎(policy engine),他是一个软件层,给应用程序提供自定义性能需求的接口,当然也提供能源相关的策略。然后策略引擎通过不断调整存储资源分配的方式,将这些策略在存储系统中实施。
最后他们还做了一些实验。实验表明这个系统可以很好的适应工作负载(workload)和供电限制的变化,系统的目标是最小化这个变化对性能的影响。原型还显示这个适应性的备份策略在供电充足的情况下,可以减少大概65%的IO延迟,而在供电不足的情况下可以减少大于40%的IO延迟。
note: 我在之前的那个可软件定义的存储逻辑的那个博客中,是这么描述那个论文的:“ 这篇论文和IOFlow相比较,更加注重软件定义存储的框架(是利用已有的框架来创建新的框架,然后使用已有的协议),而不是像IOFlow那样注重通信的协议。并且,这个框架还是软件定义环境的框架,而不仅仅是存储的框架,不过全文注重说了存储(更有挑战性)...”那个文章比较全面的定义了软件定义存储的框架,并且和SDE结合在一起;而这个论文专注于energy adaptive的replica系统。
首先介绍了一个叫做可扩展存储架构(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模型:写操作,当一个副本写入后就返回,每隔一定的时间同步副本。
数据中心副本的使用是为了数据的容灾,另一方面是为了虚拟机负载平衡的需要。在多虚拟机的情况下,随着数据副本的增加,IO延迟会减少(多虚拟机分布式的访问replica,replica越多,IO队列越小,IO延迟越小),但是副本的增大使得能源消耗增加。所以在使用绿色能源的数据中心,能源的限制导致了数据副本数的减少,IO延迟增大。如果能源充足的话,数据可以有足够的副本数,也就不会影响数据的延迟。
如下图所示。随着VM副本数的增加,IO延迟变小,能量的消耗变大。
在使用虚拟化的大型数据中心中,一个很具体的应用就是:虚拟机去重,然后多副本存储在下层的存储系统中。我们考虑虚拟机环境的工作方式,设计了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等)。
? Chunk 存储:replica
? FUSE模块(VM的磁盘挂载在FUSE目录中)
? Process:当VM执行任何vdisk的IO操作时,metadata manager会将这个IO请求转化为固定大小的chunk(SHA1 Hash);在内存中维持一个hashmap;metadata manager通过thrift client和存储系统交互。
? 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传递给存储系统。
? 分布式的:每个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之间。
副本总是需要同步的,而在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.
|
从图中可以看出:副本越多,IO延迟越小。通过这个实验可以发现:增加副本数可以减少多少IO延迟;从这个实验可以让我们知道怎么配置系统:因为减少的能源让系统的副本数变少, 我们需要动态的精确的知道系统的性能变化,并作出相应的权衡。
存储系统某个服务于VM的replica的logfile的大小(阈值)可以是个变量,通过图6我们知道:logfile大小为100M的时候,读写IO延迟最小,于是就选择这个logfile的大小当做是阈值(因为这个值会使得workload的read IO延迟最小)。然后实验测试了strong,weak和flexstore(用前面测试出来的这个logfile阈值)三种一致性模型的平均IO延迟。发现strong模型会使得写延迟很大,根据前面的分析这是显而易见的。而weak模型和flexStore的模型读写延迟差不多,当然改变那个logfile的大小可能会对实验结果有一些影响。
VM的去重率和存储节点的cache大小也是影响延迟的一个很重要的因素。如果内存一样大,去重率为75%的比25%的延迟小,因为去重率高,肯定会有很多重复的数据在cache中,这样就可以减少cache不命中了。然后存储节点的RAM 内存越大,也表示这里的buffer cache越大,在相同去重率的情况下也将会导致更小的延迟。
另外当我们在计算一致性模型的时候我们发现其实分配给IO和同步的资源是可以相互制约的,所以我们通过在能源改变的时候,调节IO带宽,这也可以改变延迟。如果能够优化带宽,则能够带来更小的延迟。
。。。
写卸载技术(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.
[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
可软件定义的存储逻辑二——Energy适应性的分布式存储系统
标签:flexstore sds 分布式存储 绿色能源 deduplication replica
原文地址:http://blog.csdn.net/yin_wuzhe/article/details/41281833