摘要部分：
目前人们普遍使用的云计算资源在地理位置上往往是分散分布在广泛的区域中（geographically distributed），这是为了能够让计算资源更加靠近使用者，减少带宽开销等。为了最大化的利用这种地域离散型的优势，人们需要有效的资源分配算法（resource allocation algorithm）来最小化通信开销和延时。这篇文章即是提出一种资源分配的算法。算法的主要目标是最小化不同数据中心之间的最大距离，其次逐层深入的优化次级的资源选取。最后通过仿真来评估算法的performance。
1. Introduction
一个云端管理和自动化软件的重要职责就是资源分配（resource allocation）。用户申请云端的服务以及一些额外需求（如连接connection等），由管理软件提供资源的合理分配。因此resource allocator需要对资源占用情况进行实时的监控。由此可以看出，资源分配算法对云计算性能有着至关重要的影响，尤其是在分布式云环境物理资源分布于不同地理位置和物理数据中心的情况下。
如要提供最佳资源性能，最理想的环境是所有用户需要的VM都处于同一个rack中。如果由于某种目的（如用户特定要求或容灾考虑）不得以让VM资源分处于不同datacenter时，则应该让跨data center的交通保持在最少。
资源分配还需要考虑到分块化的情况以及用户在资源运行的情况下动态改变需求（动态性）的情况，同时还得考虑资源需求成批的进入的情形（requests come in batches），这可能是由于用户提前规划并发出大量未来的需要被schedule的需求。
这篇文章考虑的即是分布式情况下的云系统，用户需求的资源很可能分布于不同的物理实体上。文中重点探究这种情况下的资源分配算法，目的是最小化VM通信之间的最大延时。
2. System Architecture
2.1 分布式云
分布式云通常是由若干分布在不同的地理位置的小型数据中心组成的，而服务提供商往往能够保证这些数据中心之间有着高速的网络连接。分布式云的好处：1.用户可以就近取得资源，这有助于在提供相同服务质量的前提下减少网络所需的capacity；2.分布式云相比传统云系统有着更低的接入延时。
现在传统的intra-data-center网络是基于分级结构(hierarchical manner)，也就是说如果两个需要通信的实体分处于不同地理位置的的rack上那么他们之间的通信很可能跨越了很多层的aggregate switches，因此这种模式下的通信延时很大程度上取决于它们的物理位置。
2.2 云管理和自动化架构
本文中给出的high-level云管理架构：用户给出所需的服务，也即虚拟机的数量以及他们之间所需的连接，cloud automation system会为此做出一个initial assignment。这种assignment是基于可能出现的worst case以及根据后来实际运行时的measurement进行重新优化（reoptimize）。文中假定不同VM之间的connection requirement是已知并可被用于resource allocation，同时用户也可能会提出进一步的要求，如每一个rack上可以放置的VM上的最大数（比如处于容灾考虑）或最小数（为使inter-datacenter流量最少）等。
基于这些需求，云系统自动计算出用户VM的放置情况，output即为这些VM和物理实体机的映射关系。这种映射关系包含了VM被schedule的datacenter，rack，blade 以及CPU，同时也计算出了相应的network configuration。
要根据这些计算结果实现相应的allocation functionality， 云系统需要和两个系统进行互动，一个是网络管理系统（NMS），另一个是本地云管理系统（CMS）。
资源分配的目标是减少inter-datacenter和intra-datacenter的流量的同时最小化数据包传送的path-length从而提升performance，具体是通过以下四步完成的：
1. 数据中心的选取： 数据中心之间的通信延时是最大也是最为重要的，因此首先需要为用户的request选取合适的数据中心。
2. 不同数据中心之间的request-partition：为具体的each VM 分配不同的datacenter资源。
3. Rack，blade和processor的选取： 确定了data center之后进一步选取对应的次一级的资源。
4. VM placement： 将不同的VM分别放置于分配好的物理资源上。
后文即是基于以上四步给出优化算法。
3. Data Center Selection
如前所述，在资源分配的开始，cloud automation system需要选取相应的data center以满足用户限制，优化网络并最大化application performance。 在这一章节中将会介绍相应的算法来选择一组datacenter的subset来放置VM并且最小化datacenter之间的最大距离。
Data center选取问题可以被视为一个子图选择问题（subgraph selection problem），而选取子图的原则可以称为MINDIAMETER。
将数据中心拓扑抽象为图G=(V,E,w,l)，其中V是顶点，代表datacenter，E是边，即两个datacenter之间的连接，w是权重代表每个顶点的可用VM的数量，l是长度代表距离，具体可用跳数（hop）或延时（latency）来表示。
如果用户所要求的VM总数为s，那么MINDIAMETER问题即为寻找一个subgraph，其权重之和至少为s，且拥有最小直径（直径可以立即为任意两个顶点之间距离最大的那条）。
A. 近似复杂度
MINDIAMETER问题是一个NP-困难问题，我们可以通过对最大团问题(MAXCLIQUE)问题简化得到它。“团“是一个两两相邻的点集，最大团问题即是寻找出这个图中最大的团。首先我们创建一个MAXCLIQUE问题图G=(V,E)，我们可以通过它来生成一个MAXDIAMETER的完备图G’。做法如下：如果在G中u和v顶点之间存在边，那么就将G’中的边(u,v)设置为1，否则设置为2。这使符合三角形不等式的。当且仅当G是CLIQUE时，G’的直径为1，否则为2。由此我们就可以找出一个图中的最大团，通过将之前所说的所要寻找的权重s遍历{n,n-1,...,1}来找到直径为1 的subgragh，也就是MINDIAMETER的solution。
注：个人理解下来，所谓MINDIAMETER问题就是让一个图G中顶点之间的距离更平均化，而平均化最理想的情况就是一个团。所以通过MAXCLIQUE问题得到MINDIAMETER问题的解是合理的。
B. 近似算法
这里介绍MINDIAMETER问题的算法，以提供最佳的approximation guarantees。这个算法给出的子图的直径最多为优化后子图直径的两倍。在问题设置上我们假定图是满足三角不等式的，因为我们需要解决的问题中的所有边都是基于的现实中的数据中心之间的实际距离。因此，如果其中(指solution中？)存在违背三角不等式的三个数据中心，我们可以使得让长边由其余短边路径构成，从而强制使其满足三角不等式。
算法1：寻找满足给定起始顶点v和大小s的最小星状子图
1. 输入为一个(G,v,s). 其中图G=(V,E,w,l)，是待查找的完备图，v是星状图的起始顶点 ，s是需要满足的size。
2. 输出为子图G'=(V',E')，其权重(大小)至少为s且由v的最近相邻点组成。
3. 算法初始状态：只有一个点v，因此此时的顶点集V'就是{v}，边集E'为
空，size为顶点v自身的权重。
4-6. 假设点集ui是依照到v点距离从小到大顺序排列的。变量i代表距离起始顶点
第i远的点，初始值i=1，直径变量diameter=0。
7-13. 当size未达到s且i<n(即还未遍历完成所有顶点)的情况下，以由近及远的顺序不断将更多的相邻顶点包含到顶点集V'中，此时图G'的权重即为前一状态下的权重加上新加入的节点权重w(ui),然后变量i自增1，同时由于新加入了节点，需要计算更新后的直径，即max（前一状态直径，新加入节点与图中所有其他节点距离），将其赋值于diameter变量，最后将新加入的边更新如边集E'中。
14-16. 如果遍历结束仍旧达不到需求的最小size值s，那么返回NULL。
以上的FindMinStar(G,v,s)算法用于寻找以顶点v为中心的星形拓扑，通过以到达v点距离增序的形式不断加入新的节点，直到星形拓扑满足weight至少为s。在遍历的过程中不断更新计算当前图的diameter。
算法2：寻找最小直径子图
MinDiameterGraph(G,s)算法中对图G=(V,E,w,l)中的每一个顶点都计算最小星形拓扑，并将结果进行比较得到能够取到最小直径的顶点。
C. 算法分析
在这一部分证明了上文所提出的算法是一个2-approximation algorithm。
由FindMinStar算法找出来的子图假设最长的距离中心点v的长度为L，那么该星状拓扑的直径最大为2L。
而考虑到实际最优解中包含的边长至少为L，所以这个算法是2-approximation algorithm。
4. Machine selection inside datacenter
再通过上述方式对数据中心加以选取之后，我们就需要在每个数据中心内部选取为虚拟机分配的物理资源。一个数据中心可能提供超过用户需求的虚拟机数量，因此选择正确的物理资源组可以提高利用率和performance。
选取machine的基本原则是降低inter-rack communication。例如，在一个有100个rack的datacenter中，一个application所需求的VM最好被安排在邻近的rack上，否则他们之间的通信就需要经过多重aggregation switch，从而增加延时和所需带宽。
在machine的选择的上面，我们可以使用类似于datacenter选择的方式来得到一个2-approximation algorithm最小化machine之间的最大距离。其中，顶点代表不同的rack，weight代表可用的machine数量，而边长则代表rack之间的距离。
正如之前所讲，datacenter的拓扑经常被设计为一种分层（hierarchy）的网络，因此我们可以以一种优化的min-max方式进行机器的选取（即之前所说的最小化最大距离）。这里，我们可以将datacenter的hiararchy考虑为一种tree topology，根节点为root switch，一级子节点为top-level aggregate switch，逐层向下，最后叶节点代表不同的rack。在这个case中我们假设所有的叶节点都有相同的level(也就是到root的距离相同)。同时，我们在每个叶节点上加上label来代表他所能支持的VM的数量。这种模型也可以拓展到blade level，即在之前的rack基础上向下进一步细分。
在machine选择问题上，我们的目标是最小化我们所选取的VM之间的最大通信距离，其本质翻译到算法中也就是在之前的树结构中寻找一个子树，其叶节点的label之和满足要求，同时树的高度最小（也就是尽量不要涉及到高层aggregate switch的通信）。
假设s为在一个datacenter中需要被放置的VM的数量，T为这个datacenter的树结构。树的每个节点都具有两个属性变量：weight代表以它为根的所有可用VM的数量，height代表该节点的高度。需要注意的是，在算法运行之前（也就是初始状态）只有叶节点具有weight属性。
算法3：寻找最小高度树
1. 输入为数据中心的拓扑树T，起始搜寻根节点r一级需要达到的最小权重s。
2. 输出为一个达到最小权重要求且高度最小的子树的根节点，同时算法还会计算这个子树的weight和height。
3-10. 初始判断r是否是叶节点，如果是的话那么高度就是1，如果他的重量满足s那么就返回r，否则返回NULL。
11-12. 变量赋初值，height，weight初始为0，最小高度minheight为无穷，返回的最小树mintree为NULL。
13-23. 在r的下一级子节点中再次迭代使用FindMinHeightTree的方法（递归）。这里有一个问题，在第15行中我认为应该是minheight>height(n)，不然算法永远进入不了这段if语句。
递归的方法大致可以叙述如下。首先迭代的对当前节点的下一级子节点使用FindMinHeightTree的方法，如果下一级不是叶节点，也就是说没有搜寻到底，那么返回的肯定是height=0，weight=0，minheight=∞，mintree=NULL，然后进行更下一级的搜索，直到搜索触底，找到叶节点，此时height=1，weight就是找到叶节点的weight。然后就会在此启用第三行的判断，如果weight不够那么返回的还是NULL。那么由第22行可以知道其上一级父节点的weight就是其下两个子节点相加，而height就变成了height(父节点)也就是2，然后继续迭代，对当前父节点执行第三行的判断，如果weight不够则还是返回NULL，直到weight满足需求s，则返回当前的节点。此时如果满足minheight大于height就把minheight设置为height的值，同时mintree也就是找到的这个节点。
24-30.之前都是对r的子节点的判断，这几行对r自身判断是否满足，也就是说如果遍历r之后mintree还是NULL，也就是说其子节点分别不满足要求，但是weight变量满足，也就是子节点之和满足要求，就说明r本身就是要找的最小树，那么就返回r，否则就返回mintree（也就是之前找到的子节点的mintree或NULL）。
FindMinHeightTree(T,r,s)算法用于寻找一个子树，其开始遍历的起始根节点为r，且总共的weight之和至少为s且具有最小高度。
5. Virtual Machine Placement
在这一章节中，我们提出一种启发式方法来为每个独立的VM分配到数据中心以及数据中心内的CPU上。这个问题是一个graph partitioning和k-cut problems的变体。我们的目标是得到可以应用于云自动系统同时能避免代价过高的计算。
我们将用户的request抽象为图G(V,E)，其中节点代表需要被放置的VM，边代表不同VM之间的通信。我们的目标是将图V分割为不同组C1,C2,...,Cn，并让不同组之间的通信最最小化。图中的每个partition代表了同一个datacenter或rack中的VM。每个partition的size需要有一个上界(upper bound)，也就是这个datacenter或rack中可以available的最大VM数量。因此不像传统的graph partition问题那样声明每一个partition中的具体节点数量，我们的问题中只会声明每一个partition中可以存在至多多少个节点。因为在现实情况下一个系统中可能包含有多于用户需求的VM数量，因此我们是在这么多的VM中满足用户的需求。
算法4：寻找cluster
1. 输入为两个变量：变量图G=(V,E)包含了节点V以及节点之间的通信链路E，边E具有的权重w表示这条链路的通信量需求；变量s代表这个cluster中需要满足的节点数量。
2. 输出为一个cluster中包含的节点集合C。
3-5. 变量赋初始值，v初始为所有节点集V中到达其他所有节点距离通信需求量最大的那个节点。待输出的变量C初始值为空。对于V中所有的节点u，traff(v)初始值都为0。
6-12. 当需求的cluster内节点数s大于|C|且小于|V|（我认为应该是小于，不能理解算法中的大于是什么意思）的前提下，进行如下的循环迭代：每次都将被选取的v节点包含入C集合中，对于所有不包含在C内的节点计算权重，也就是将之前的链路权重属性转化为节点属性节点属性越大表示该节点与C集合内的节点的communication越多。那么我们可以理解，在数次迭代过后C集合外的节点上具有的所谓权重属性即为该节点到所有C集合内部节点通信量之和。同时每一次迭代后都把到改cluster内通信需求最大的那个节点作为下一次的v节点（也就是下一个加入到cluster内的节点）。第11行应该是V-C吧？
13. 最后返回C集合，即满足条件s下包含在cluster内的节点集合。
FindCluster(G,s)用于在一个虚拟机分布的环境G下寻找出满足条件的一组虚拟机（cluster）。选取标准为尽量保证多数通信都存在于该集合内部。算法本质就是通过迭代从一个备选节点v开始每一次选取与cluster内communication最多的节点加入到cluster中去。在现实情况下，即为选择一个最大通信量（此处的通信量可以指带宽或临节点数量等）的VM，并将它放置于datacenter或rack中。
算法5：分割算法
1. 输入为两个变量：第一个变量是图G=(V,E)，同上述一样包含了节点信息和节点之间的communication requirement；第二个变量是集合K={k1,k2,...,kr}，表示k个cluster每个需要分成的size。
2. 输出为一组分好的元素集合C1,C2,...,Cr。分别包含了相应的节点信息。
3-4. 首先让ki进行降序排列，也就是说k1是需要分割size最大的那个。为变量V'赋初值，V'=V。
5-9. 进行r次迭代，每次都在G的子图G'中利用算法4中的FindLucter方法寻找满足条件的cluster，并在找到以后将该cluster划归出G'（也就是V'）之外。
10. 返回r组cluster。
6. 仿真结果
在这一部分中将把本文第三部分中提出的算法(称为Approx)和其他两种算法进行对比：随机算法(Random)和贪心算法(Greedy)。随机算法是随机选取一个datacenter，并在这个datacenter中为一个request分配尽量多的VM。如果这个request中包含比该datacenter更多的VM，那么就随机选取第二个datacenter来分配剩下的VM，直到request被完全满足。Greedy算法是每次都选取可用资源(也就是available VM)最多的那个datacenter，和随机算法一样在那个datacenter中尽量多的放置一个request里的machine，如果request中需求比这个datacenter还要多的VM，那么就再次选取下一个VM数量最大的那个datacenter来放置VM。
为了衡量三种算法的performance，我们创建一个随机的topology和随机的用户请求，并测量任意两个VM之间的最大距离。评估中的datacenter是被安放在一个1000*1000的网格拓扑中，datacenter之间的距离使用两点之间的欧式距离来进行衡量。有5个不同的distributed cloud scenerio，分别包含100，75，50，25，10个datacenter，但是每个cloud scenerio中的平均的总机器数量是一样的，也就是说在一个datacenter中的machine数量是反比于对应的cloud scenerio的。例如，在100个datacenter的scenario中每个datacenter中的机器数量均匀分布于(50,100)中，在50个datacenter的scenario中为(100,200)的均匀分布。而下文中的测试结果都是基于100次测试的平均值。
在第一个实验中我们考察对于单次1000VM的request，不同算法给出的虚拟机分配的diameter。
上图为测量出的diameter结果的对比，可以看出Approx算法给出的拓扑直径明显小于另外两种算法达到79%。Random和Greedy算法有相似的performance。另外可以看出的一点是这个直径的值随着datacenter的数量的减少而减少，这是因为随着datacenter数量减少，每个datacenter中的可用VM增加。因此本实验中较小数量的datacenter可以满足更密集的需求。
然后我们来探究不同云系统在面对一系列用户请求（多次请求）时的表现。我们将其分为两套实验，第一种实验是100次request，每个request的需求均匀分布在50-100个VM之间，我们将这个实验称为large request。第二种实验是500次request，每个request的需求均匀分布于10-20个VM之间，我们称之为small request。需要强调的是从以上两种方案可以看出，在两种实验中的平均VM请求是一样的，只是前者是“少次多量”，后者是“多次少量”。
图6和图7分别是large request和small request在不同方案下的平均diameter的对比。在这两个实验中，贪心算法比随机算法分别降低了32.6%，66.5%，而Approx算法分别比贪心算法降低83.4%和86.4%。对于相同的算法，larger request比smaller request需要更大的diameter。这是因为large request更有可能会被分配到多个datacenter中，这就增加了拓扑的直径。同时我们还看到，当cloud中的datacenter减少时diameter也跟着减少,这和之前的观察结果也一致。
下面我们考察当用户给定一个datacenter中可以放置的最多VM数量的限制时不同算法的performance。此处用的实验方案和之前的一致，即large request和small request，在此之上用户可以声明一个数据中心中最多可以放置多少个VM。具体来讲，用户声明总共需要的VM和每个datacenter中最多防止的VM的比值，这个比值称为resilience，这个值也就是处理一个request最少需要的datacenter的数量。由于Approx比其他两种算法的performance明显要好，所以在这个实验中只对Approx算法进行测试。其他算法在diameter很大的情况下表现相似。
图8和图9分别是large request和small request在Approx算法使用不同resilience情况下的diameter。Resilience增加，diameter跟着增加。这是因为request需要被放置于多个datacenter中，从而增加了diameter。另外我们还可以看到，对于resilience大于2的情况下（2-5），diameter随着datacente数量的减少而增加（对比不同曲线可以得到），这和我们之前看的当resiliency为1的情况是相反的。这是因为，当resilience大于1时，一个request需要多个datacenter来满足。而当datacenter数量越少的时候，由于前面提到这些datacenter是均匀放置于网格拓扑中的，所以他们之间的平均距离也就越大，因此diameter也就越大。
A. VM的分割
这里我们来考察这个算法在分配VM到不同datacenter时的表现。在给定VM之间的连接需求和每个datacenter的可用VM资源的情况下，算法会根据最小inter-datacenter connection的原则来分配VM到不同的datacenter中。和之前一样，这里我们将本文中提出的启发式算法与随机算法和贪心算法进行对比。随机算法为每一个VM随机选择datacenter进行安放，而贪心算法则以降序每次选取最大的datacenter进行VM的放置，且尽可能多的放置VM在该datacenter中。在选择VM的时候则会选择total traffic最多的那个。
在我们的实验中，我们想datacenter发出了100个VM request。这些VM的带宽需求均匀分布于0-1Mbps。我们将这些VM分配给k个datacenter (k=2,...,8)，同时满足每个datacenter中持有的资源为100/k-200/k，也就是说我们将这100个VM分配给具有100-200个VM的k个datacenter中。我们将这个实验运行100次并计算其平均结果。
图10画出了三种算法在不同数量datacenter的情况下的inter-datacenter traffic的情况。三种算法中的inter-datacenter traffic都随着datacenter数量的变大而变大。这是因为，随着datacenter数量的增多，每个datacenter内的VM减少，因此datacenter之间的通信也就会变多。从图中我们还可以看出贪心算法比随机算法要好10.2%，而我们得启发式算法比贪心算法要好4.6%。图11显示和图10相同，区别在于图11中datacenter没有excess capacity (这是什么？)，这里启发式算法的inter-datacenter traffic比之前要高28.2%，这是因为此时datacenter具有更小的capacity。启发式算法比其它两种算法要好4.8%，而另外两种算法的performance大致相同。
图12我们考察的是VM之间的traffic对于inter-datacenter traffic结果上的影响。我们改变VM communication graph中的具有traffic的链路的占比，令这个占比从20%增加至100%从而测试inter-datacenter traffic。这里，datacenter也是没有excess capacity（还是不知道是什么）。 图中展示的是3和5个datacenter的结果，从中可以看出inter-datacenter traffic随着有traffic链路比例的增加而线性增加。
