博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Mesos DRF算法的论文阅读
阅读量:5879 次
发布时间:2019-06-19

本文共 16893 字,大约阅读时间需要 56 分钟。

hot3.png

<p>dominant resource fairness算法是Mesos的灵魂,不同于hadoop基于slot-based实现的fair scheduler和capacity scheduler,学习阅读了一下论文“Dominant Resource Fairness: Fair Allocation of Multiple Resource Types”,顺便简单地翻译了一下。以下是论文翻译地正文。</p> <p>------------------------------------------------------------------------------</p> <p>我们考虑在一个包括多种资源类型的系统的公平资源分配问题,其中不同用户对资源有不同的需求。为了解决这个问题,我们提出了Dominant Resource Fairness(DRF),一种针对不同资源类型的max-min fairness。首先DRF激励用户去共享资源,如果资源是在用户之间被平均地切分,会保证没有用户会拿到更多资源。其次,DRF 是strategy-proof,用户不能通过欺骗来获取更多地资源分配。然后,RDF是envy-free(非嫉妒),没有一个用户会与其他用户交换资源分配。最后,RDF分配是Pareto efficient,不可能出现既能增加一个用户的资源分配而又不会减少其他用户的资源的情况。</p> <p>我们在mesos 集群资源管理器上实现了一个DRF,显示了它可以比slot-based 公平调度算法得到更好的吞吐量。</p> <h4>Introduce</h4> <p>在任何共享的计算机系统中,资源分配都是一个关键的构建模块。已经提出的最通用的分配策略是max-min fairness,这种策略会最大化系统中一个用户收到的最小分配。假设每一个用户都有足够地请求,这种策略会给予每个用户一份均等的资源。广义的Max-min fairness包括权重(weight)的概念,用户可以获得与它的权重成正比的那一份资源。</p> <p>加权max-min fairness的吸引力源于它的一般性和它能提供性能隔离的能力。加权max-min fairness模型可以支撑许多其他资源分配策略,包括优先级、deadline based allocation等。此外,加权max-min fairness确保隔离,一个用户能确保收到它的那份资源,而不管其它用户的需求。</p> <p>鉴于这些特征,不同精确度的加权或非加权max-min fairness毫不意外地被大量已经提出的算法实现,如round-robin、proportional resource sharing、weighted fair queueing。这些算法已经被应用于不同的资源,包括链路带宽、CPU、内存、存储。</p> <p>尽管已经在公平分配上做了大量地工作和实践,但目前为止主要还是集中在单资源类型的场景下。甚至在多资源类型的环境下,用户有异质资源请求,典型的资源分配做法还是使用单类型资源抽象。比如hadoop和Dryad的公平调度器,这两种广泛使用集群计算框架,在资源分配时使用插槽(slot),slot就是对节点资源按照固定大小进行划分而产生的分区。然而事实是集群中不同的作业队CPU、内存和IO资源有着不同的需求。</p> <p>在这篇文章里,我们会定位在多资源和异质用户请求的环境下公平分配策略所遇到的问题。特别的,我们提出了Dominant Resource Fairness(DRF),一种通用的多资源的max-min fairness分配策略。DRF背后的直观想法是在多环境下一个用户的资源分配应该由用户的dominant share(主导份额的资源)决定,dominant share是在所有已经分配给用户的多种资源中,占据最大份额的一种资源。简而言之,DRF试图最大化所有用户中最小的dominant share(一句话表达了DRF的思想)。举个例子,假如用户A运行CPU密集的任务而用户B运行内存密集的任务,DRF会试图均衡用户A的CPU资源份额和用户B的内存资源份额。在单个资源的情形下,那么DRF就会退化为max-min fairness。</p> <p>DRF的力量在于它所满足的属性。这些属性都被单资源场景下的max-min fairness所满足,但在多资源场景中是不寻常的。有四种这种类型的特性,分别是:sharing incentive、strategy-proofness、Pareto efficiency和envy-freeness。</p> <p>DRF是通过确保系统的资源在用户之间是静态和均衡地进行分配来提供sharing incentive,用户不能获得比其他用户更多的资源。此外,DRF是strategy-proof,用户不能通过谎报其资源需求来获得更多的资源。DRF是Pareto-efficient,在满足其他特性的同时,分配所有可以利用的资源,不用取代现有的资源分配。最后,DRF是envy-free,用户会更喜欢其他用户的资源分配。</p> <p>我们在mesos中实现和评估了DRF,mesos是一种多集群计算框架的资源管理器。可以运行hadoop和MPI。我们将DRF与hadoop和Dryad中所使用的slot-based fair sharing scheme进行比较显示,slot-based fair sharing能导致更差的性能,某些不公平的工作负载惩罚,同时提供更弱的隔离保证。</p> <p>本文主要聚焦数据中心的资源分配,我们相信DRF是可以广泛地应用于用户有异质需求的多资源环境,比如在多核机器上。</p> <h4>2 Motivation</h4> <p>虽然之前关于加权max-min fairness的工作都集中在单一资源的情况,云计算和多核处理器的出现增加了对多资源和异构用户请求的环境下的分配策略的需求。多资源意味着不同种类型的资源,而不是多种可以相互交互的资源实例。</p> <p>为了激励多资源分配的需求,我们在facebook 2000个节点的hadoop集群上测量任务的资源利用率超过一个月时间,见下图。</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212733_yQJV.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-18071" border="0" alt="wps_clip_image-18071" src="http://static.oschina.net/uploads/img/201312/12212734_6OVx.png" width="244" height="205" /></a></p> <p>图中圆球的位置标示了任务的内存和cpu消耗,圆球的大小标示在某一个区域的任务数取对数后的值(logN,N为任务数目),因而大部分任务都是CPU密集的,而现存memory密集的任务大都是reduce操作。</p> <p>现存的集群公平调度器,如Quincy和hadoop fair scheduler都忽略了用户的异质需求(heterogeneity of user demands),以插槽(slot)为粒度进行资源分配,其中一个slot是一个节点上固定比例的资源。这导致了低效的分配,一个slot往往与任务的需求不匹配。</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212735_DLp1.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-6952" border="0" alt="wps_clip_image-6952" src="http://static.oschina.net/uploads/img/201312/12212736_HixB.png" width="244" height="197" /></a></p> <p>(一个月时间内,facebook 2000个节点的集群上任务需求与slot比率的正态分布图,需求与slot比率为2.0表示一个任务需要的CPU或内存是一个slot所包含的CPU或内存的两倍)</p> <p>见上图,上图量化了hadoop mapreduce 公平调度器的公平性和隔离性的级别。这附图显示了任务的CPU需求和slot的CPU share之间的比率的正态分布图以及任务的内存需求和slot的内存share之间的比率的正态分布图。我们简单地使用cpu和内存的总量除以slot数目来计算单个slot的内存和cpu share。比率为1表示任务的需求完美地匹配slot的资源,比率低于1表示任务没有充分地利用slot的资源,比率高于1表示任务已经过载地使用slot的资源,这会导致系统颠簸。图2显示了大部分任务都没有充分利用slot资源或者过载地利用slot资源。修改每台机器的slot不能解决这个问题,这样做可能会导致更低的总利用率或者更多的任务因为过载而导致更差的性能。</p> <h4>3 Allocation Properties</h4> <p>现在我们为多资源和异质请求(heterogeneous requests)设计一个max-min fair分配策略。为了说明这个问题,我们考虑一个有9个cpu和18GB的系统,有两个用户:用户A的每个任务都请求(1CPU,4GB)资源;用户B的每个任务都请求(3CPU,4GB)资源。如何为这种情况构建一个公平分配策略?</p> <p>其中一个可能性是为每个用户分配每一种资源的一半。另一种可能性是为每个用户分配等量的各种资源合计(比如,cpu加上内存)。虽然能比较容易想出多种可能的公平分配,但不清楚如何对这些分配策略进行证明和比较。</p> <p>为了应对这种挑战,我们先从一组特性开始,我们相信任何对多个资源和异构请求的资源分配策略都应该满足这些特征。然后用这些特性指引公平分配策略的指定。我们发现了如下四个特性是重要的。</p> <p>1、sharing incentive:每一个用户都必须更好地共享集群,而不是在集群中专享他们自己的分区。考虑一个集群具有相同的节点(每个节点都一样)和n个用户,一个用户不能在超过1/n资源的集群分区中分配更多的任务。一个用户最多只能分享1/n的资源。</p> <p>2、Strategy-proofness:用户不能从谎报资源请求中得到好处。用户不能通过欺骗来提升它的分配。</p> <p>3、Envy-freeness:一个用户不应该更喜欢其他用户的分配。这点特性包含在公平的概念中。</p> <p>4、Pareto efficiency:不可能出现既能增加一个用户的分配而不会降低至少另一个用户的分配。这个特性非常重要,它使得在满足其他特性的基础上使系统利用率最大化。</p> <p>我们简单地评价一下strategy-proofness和sharing incentive特性,我们相信这两个特性在数据中心环境下特别重要。</p> <p>从我们与云计算运营商的交谈中听到的传闻和证据显示strategy-proofness是非常重要的,因为,用户试探操纵调度器是非常普遍的。比如,yahoo的一个Hadoop MapReduce集群对map和reduce任务有不同的slot。一个用户发现map的slot存在竞争,因此就将他的所有任务都长期地运行在reduce阶段,手工地执行本来应该在mapreduce的map阶段执行地工作。另一个大型搜索公司为用户高利用率的作业提供了专门的机器,这个公司马上就发现用户在他们的代码中散布无限循环用于人为地提升利用率级别。</p> <p>此外,任何满足sharing incentive特性的策略同样也提供性能隔离,因此不管其他用户的需求如何,它都必须保证每个用户的最小分配,(打个比方,一个用户不能比做得拥有1/n集群资源更差的情形)。</p> <p>在单个资源的情况下,max-min fair可以很容易地做到满足以上所有特性。然而,在多资源和异质用户需求的情况下,达到这些特性是不简单的。比如在微观经济理论中首选的公平分配机制 Competitive Equilibrium from Equal Incomes不满足strategy proof。</p> <p>除了以上四种特性,我们考虑另外四种不错的特性:</p> <p>1、Single resource fairness:对于单个资源,解决方案会蜕变为max-min fairness。</p> <p>2、Bottleneck fairness:假如一种资源是紧缺的资源,然后对于这个资源,解决方案必须退化为max-min fairness。</p> <p>3、Population monotonicity:当一个用户离开系统,返还其占用的资源,那么任何剩下的用户的资源分配不会减少。</p> <p>4、Resource monotonicity:假如更多的资源添加到系统中,任何现存用户的资源分配都不会减少。</p> <h4>4 Dominant Resource Fairness(DRF)</h4> <p>我们提出了Dominant Resource Fairness,一种针对多种资源类型的分配策略,满足前一章中的所有四种特征。对于所有用户,DRF会计算分配给用户的每一种资源的占用率(share),用户所有占有率中的最大值称作用户的dominant share,与dominant share对应的资源被称作dominant resource。不同的用户有不同的dominant resource。</p> <p>举个例子,运行计算受限作业(computation-bound)的用户的dominant resource是cpu,而运行IO受限(IO-bound)作业的用户的dominant resource是带宽。</p> <p>在各个用户的dominant share之间,DRF简单地采用最大最小公平(max-min fairness),设法中最大化系统最小的dominant share,然后是第二小的,以此类推。</p> <p>在这一章我们讨论有n个用户和m种资源的计算模型。每个用户都运行相互独立的任务,每个任务都由一个资源需求向量来描述,需求向量执行了这个任务所需要的各种资源的值,比如{1 CPU,&#160; 4GB}。在通常情况下,各种任务都有不同的需求。</p> <p>4.1 一个例子</p> <p>考虑一个9CPU、18GBRAM的系统,拥有两个用户,其中用户A运行的任务的需求向量为{1CPU, 4GB},用户B运行的任务的需求向量为{3CPU,1GB}。</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212737_zlCI.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-18452" border="0" alt="wps_clip_image-18452" src="http://static.oschina.net/uploads/img/201312/12212737_xXnW.png" width="244" height="171" /></a></p> <p>在上述方案中,A的每个任务消耗总cpu的1/9和总内存的2/9,所以A的dominant resource是内存;B的每个任务消耗总cpu的1/3和总内存的1/18,所以B的dominant resource为CPU。DRF会均衡用户的dominant shares,如图三所示,三个用户A的任务总共消耗了{3CPU,12GB},两个用户B的任务总共消耗了{6CPU,2GB};在这个分配中,每一个用户的dominant share是相等的,用户A获得了2/3的RAM,而用户B获得了2/3的CPU。</p> <p>以上的这个分配可以用如下方式计算出来:x和y分别是用户A和用户B的分配任务的数目,那么用户A消耗了{xCPU,4xGB},用户B消耗了{3yCPU,yGB},在图三中用户A和用户B消耗了同等dominant resource;用户A的dominant share为4x/18,用户B的dominant share为3y/9。所以DRF分配可以通过求解以下的优化问题来得到:</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212738_cgx6.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-20068" border="0" alt="wps_clip_image-20068" src="http://static.oschina.net/uploads/img/201312/12212738_llIF.png" width="244" height="103" /></a></p> <p>求解以上问题,可以得出x = 3以及y = 2。因而用户A获得{3CPU,12GB},B得到{6CPU, 2GB}。</p> <p>需要注意的是,DRF并不是总需要使用户的dominant shares相等。当一个用户总的需求是被满足,用户不会需要更多的任务,因此多余的资源可以在其他用户之间进行分配,就好像max-min fairness。此外,如果一种资源被耗尽,那些不需要此种资源的用户仍然可以继续接收到更多其他类型的资源。</p> <h5>DRF Scheduling Algorithm</h5> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212740_Xiol.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-11623" border="0" alt="wps_clip_image-11623" src="http://static.oschina.net/uploads/img/201312/12212740_H81D.png" width="244" height="202" /></a></p> <p>算法1显示了DRF调度的伪码,这个算法会跟踪分配给每个用户的总资源以及用户的dominant share,Si。每一步,DRF都会从拥有最低dominant share的用户中选择一个任务准备运行。假如用户的任务需求能被满足,即系统中有足够可用的资源,那么用户的任务就会被加载启动。我们考虑一般情况,即一个用户拥有不用需求向量的任务,我们使用变量Di来表示用户i下一个要运行加载的任务。为了简单起见,伪码没有捕获任务结束事件,在这种情况下,用户会释放任务的资源,DRF会再一次选择拥有最低dominant share的用户去运行它的任务。</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212742_PQfa.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-12023" border="0" alt="wps_clip_image-12023" src="http://static.oschina.net/uploads/img/201312/12212743_BDro.png" width="475" height="125" /></a></p> <p>考虑4.1的两个用户的简单例子,table1说明了DRF对这个简单例子的分配过程。DRF首先选择B来运行一个任务,结果B的资源占用率变为{3/9,1/18},B的dominant share变成了max{3/9,1/18} = 1/3。接下来DRF选择A,因为此时A的dominant share为0。这个过程持续进行,直到不再可能运行任务新任务,在这种情况下,一般会出现CPU饱和。</p> <p>在以上分配过程的最后,用户A会得到{3CPU, 12GB},同事B得到了{6CPU, 2GB},每一个用户都获得了2/3的dominant resource。</p> <p>注意到,在这个例子中,一旦任何资源达到饱和,那么分配过程就会终止。然而通常情况下,它可以在某些资源已经饱和的情况下继续分配任务,因为有些任务对已经饱和的资源没有任何要求。</p> <p>以上这个算法在实现的时候可以用二叉堆来存储每一个用户的dominant share。对于n个用户,每一次调度决定都消耗了O(logn)时间。</p> <h5>Weighted DRF</h5> <p>在实践中,在许多种情况下,均等地在用户之间分配资源并不是理想的策略。实际上我们可能想要分配更多的资源给运行重要作业的用户,或者给为集群贡献出更多资源的用户。为了达到这个目的,我们提出了Weighted DRF,一个概括了DRF和weighted max-min fairness的算法。</p> <p>在weighted DRF中,每个用户i都关联一个权重向量Wi = {Wi1, ......, Wim},其中Wi,j表示用户i对资源j的权重。那么用户i的dominant share的定义为Si = max{Ui,j /&#160; Wi,j},其中Ui,j是用户i对资源j的占有率。一种特别的情况就是所有用户i的权重都是相等,在这种情况下,Weighted DRF就退化为DRF。</p> <h4>5 Alternative Fair Allocation Policies</h4> <p>在一个多资源的系统中,定义一个公平分配不是件简单的事情,公平这个概念本身就是值得商榷的。在我们所做的努力中,我们在使用DRF之前考虑过多种分配策略,但只有DRF能满足所有四个特性:sharing incentive、strategy-proofness、Pareto efficiency、envy-freeness。</p> <p>在这一章中,我们调查了两种可选的替代者:Asset Fairness,一种简单且直观的策略,为了均衡分配给每个用户的聚合资源;以及Competitive Equilibrium from Equal Incomes(CEEI),一种在微观经济领域的公平分配资源的可选策略。我们将这些策略与DRF进行比较。</p> <h5>5.1 Asset Fairness</h5> <p>Asset Fairness的设计想法是不同资源的相同占用率是等值的,比如1%的cpu使用率和1%内存和1%的带宽使用率是相同的。在这个前提之下,Asset Fairness 尝试去均衡分配给每个用户的聚合资源值(各种资源的累加)。特别地,Asset Fairness会计算每个用户i的聚合资源占用率<a href="http://static.oschina.net/uploads/img/201312/12213416_Uy5A.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/12213416_hSZN.png" width="69" height="27" /></a> ,其中Si,j是用户i对于资源j的占用率。然后在用户的总占用率上使用max-min fairness,比如总是重复地运行拥有最小聚合资源占用率用户的任务。考虑第四章中的例子,系统拥有9CPUS和18GB RAM,既然RAM的GB数量是CPU数量的两倍,一个CPU相当于2GB的RAM。假设1GB的RAM为$1,那么1CPU为¥2,那么可以用户A的每个任务需要花费¥6,而用户B的每个任务需要花费¥7。设置x和y分别为Asset fairness算法分配给用户A和用户B的任务数。</p> <p>Asset-fair分配问题可以通过求解以下问题来得到(这个问题假设用户A和用户B最后得到了相同的聚合资源占用率)</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212744_Unke.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-11722" border="0" alt="wps_clip_image-11722" src="http://static.oschina.net/uploads/img/201312/12212744_gIDj.png" width="244" height="92" /></a></p> <p>求解上面这个问题,可以得到x=2.52,以及y=2.16,。因而用户A得到了{2.5 CPUS,10.1GB},用户B得到了{6.5CPUs,2.2 GB}。</p> <p>这个分配策略的简单性很吸引人,但它有一个重大的缺陷:它违反了sharing incentive特性。Assert fairness可以导致一个用户获取了小于总资源的1/n,其中n为总的用户数目。</p> <h5>5.2 Competitive Equilibrium from Equal Incomes</h5> <p>在微经济理论中,公平分配资源的首选方法是Competitive Equilibrium from Equal Incomes(CEEI),在CEEI中,每个用户在初始化时接收到所有资源的1/n,接下来每个用户会在一个完全竞争的市场与其他用户交易资源。CEEI的输出同时满足envy-free和pareto efficient。</p> <p>更加精准描述是:CEEI分配是由nash bargaining solution给出的,nash bargaining solution会选择可行的分配策略,使得<a href="http://static.oschina.net/uploads/img/201312/12213416_sGW8.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/12213416_O493.png" width="54" height="24" /></a> 最大化,其中<a href="http://static.oschina.net/uploads/img/201312/12213416_dKgV.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/12213416_v5mS.png" width="49" height="31" /></a> 是用户i获取资源<a href="http://static.oschina.net/uploads/img/201312/12213416_ihHy.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/12213416_QdVc.png" width="24" height="27" /></a> 的方式或功能,为了简化对比,我们将一个用户得到其资源分配的方式简化为就是其dominant share,<a href="http://static.oschina.net/uploads/img/201312/12213417_IQQp.png"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="image" border="0" alt="image" src="http://static.oschina.net/uploads/img/201312/12213417_bzXf.png" width="21" height="24" /></a> 。</p> <p>考虑第四章两用户的例子,回忆一下用户A的dominant share为4x/18 = 2x/9,而用户B的dominant share为3y/9 = y/3。其中x为用户A的任务数目,y为用户B的任务数目。最大化商品的dominant shares就等同于最大化商品的x.y。因为CEEI就变为解决如下的优化问题:</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212746_vnng.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-29659" border="0" alt="wps_clip_image-29659" src="http://static.oschina.net/uploads/img/201312/12212746_qtRs.png" width="244" height="108" /></a></p> <p>解决以上问题可以得到x= 45/11,y=18/11。因而用户A获得了{4.1 CPUs, 16.4 GB},同时用户B获得了{4.9 CPUs, 1.6GB}。不幸的是,虽然CEEI同时满足envy-free和Pareto efficient,但不满足strategy-proof特性,因而用户可以通过谎报他们的资源需求来提升他们的资源分配。</p> <h5>5.3 Comparison with DRF</h5> <p>为了给读者对Asset Fairness和CEEI有一个直观的理解,我们在下图中,将三种算法资源分配进行对比。</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212747_lHV0.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-22357" border="0" alt="wps_clip_image-22357" src="http://static.oschina.net/uploads/img/201312/12212748_NtNG.png" width="244" height="174" /></a></p> <p>我们看DRF使得用户的dominant share趋于均衡。而Asset Fairness使得用户的总资源分配的百分比趋于均衡。最后,因为CEEI假设有一个充分竞争市场,它找到了一个满足市场结清的解决方案,使得所有资源都得到分配,不幸的是这个精确的特性使得CEEI可能会被欺骗,用户可以通过声明它需要更多地未充分利用的资源,导致CEEI向这个用户赋予更多的任务来达到市场结清的目标。</p> <h4>6 Analysis</h4> <p>第六章主要从第三章提出的8种分配特性来分析asset fairness、CEEI和DRF。下面这个表显示了三种分配策略支持的不同特征。</p> <p>&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; <a href="http://static.oschina.net/uploads/img/201312/12212749_5RBx.png"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="wps_clip_image-27501" border="0" alt="wps_clip_image-27501" src="http://static.oschina.net/uploads/img/201312/12212749_09LO.png" width="244" height="174" /></a></p> <p>&#160;</p> <p>作者zy,QQ105789990</p>

转载于:https://my.oschina.net/zhengyang841117/blog/184046

你可能感兴趣的文章
java String
查看>>
renhook的使用
查看>>
Linux学习笔记(十二)--命令学习(用户创建、删除等)
查看>>
DOCKER windows 7 详细安装教程
查看>>
养眼美女绿色壁纸
查看>>
U盘启动盘制作工具箱 v1.0
查看>>
增强myEclipse的提示功能
查看>>
Zabbix汉化方法
查看>>
Java I/O系统基础知识
查看>>
Java多线程设计模式(2)生产者与消费者模式
查看>>
基于whoosh的flask全文搜索插件flask-msearch
查看>>
对象并不一定都是在堆上分配内存的
查看>>
刘宇凡:罗永浩的锤子情怀只能拿去喂狗
查看>>
php晚了8小时 PHP5中的时间相差8小时的解决办法
查看>>
JS(JavaScript)的初了解7(更新中···)
查看>>
svn文件管理器的使用
查看>>
Ansible playbook 使用
查看>>
for/foreach/linq执行效率测试
查看>>
js /jquery停止事件冒泡和阻止浏览器默认事件
查看>>
杭电1698--Just a Hook(线段树, 区间更新)
查看>>