无保证的租户可W与有保证的租户公平地利用未使用的 带宽了。
[0175] 在Sponge化t中，如果运S个租户请求的费用均为Nkv = 10$/小时，E-F运行时机制 会将未分配的带宽化-Bx-y+Bz-t+Ba-B = 700Mbps)按照权重Nkv分给租户们。运样，每个租户 使用它们新的带宽保证作为函数R的输入。所W，=个租户最终的限速结果分别为Rx~^y = 333Mbps,Ra~^b = 233Mbps and Rz一T=666Mbps。
[0176] E-F运行时机制在物理链路上运行良好，参见图8a和图8b，但怎样将它部署到树状 拓扑上是一个挑战。因为每台服务器有租户A的虚拟机，E-F运行时机制会把所有的租户A的 虚拟机的未保证的链路看作是一条有保证的链路。运个特殊的有保证链路，它有最小带宽， 可W被分配到所有与有租户A的虚拟机的服务器连接的其他物理链路上。具体来说，租户t 的服务器i的带宽保证被设置为S- bcmc/wi加'/4:
[0177] S handwi'dthLt 二 rmn[S - handwi(ith;-叶'jyj e V。i 丰 j. S - handwiAtl.护j?二 nil打- bandwid化I叫 E Path(i, f), i，j eVt, i 丰 j
[0179]其中，Vt是所有有租户t的虚拟机的服务器，PatKi，j)是虚拟机i到虚拟机j之间 的物理链路的集合。图9中，有4台服务器上有租户A的虚拟机。服务器a有3条物理链路与其 他有A的虚拟机的服务器相连。运S条链路的最小可分配带宽分别为90Mbps，60Mbps和 60Mbps。所W服务器a的特殊带宽保证链路的最终带宽保证为60Mbps。其余几台服务器，所 有链接到其他服务器的物理链路是一样的。所W服务器b到d的带宽也是60Mbps。
[0180] 具体地，按服务器粒度为无保证租户设定带宽保证，其中按服务器粒度为无保证 租户设定带宽保证是E-F运行时机制的核屯、。它在存在未被分配的带宽资源时，为无保证租 户在服务器粒度设定带宽保证，从而使无保证租户和有保证租户间的分配更公平。下述的 按服务器粒度为无保证租户设定带宽保证算法通过计算按费用比例分配未分配的带宽，得 到服务器SO可W在每条从SO到服务器Sj的链路可W获得多少带宽，并用最小值作为链路的 保证值。并将从SO到其他服务器的最小保证值分配到租户t在服务器SO中的保证值。根据树 状拓扑的功能(一般用于数据中屯、架构），从某一叶节点开始访问所有的叶子节点意味着遍 历整个树，需要经过其中每一条链路。因此，St中所有服务器有着相同的保证带宽Bt,选取St [0]作为服务器SO用来计算保证值不是必须的，可W任意选取St中的服务器。
[0181] 下面给出按服务器粒度为无保证租户设定带宽保证算法：
[0182] 对于无保证租户t，执行W下操作：
[0183] 该方法需要W下参数：
[0184] t:-个无保证的租户；
[018日]T:租户t和其他与t克争的租户；
[0186] Mi: T中，租户i的付款；
[0187] St:含有租户t的虚拟机的服务器；
[0188] :链路P中未使用自勺带宽。
[0189] 步骤（1) .se;rverso = St[0]
[0190] 步骤(2).初始化数量计数器j = l，随着组合过程的推进，每经过1个数，计数器增 加 j = j+l，当服务器&在奋中时，在每个记数单位中执行W下步骤：
[0191] 步骤(2.1 ).获取从服务器SQ到服务器Sj的保证值：
[0193] 步骤(3).将从SO到其他服务器的最小保证值设置为租户t在服务器SO中的保证值：
[0194] Bt = min(BtS。-吗），VSj 巨St, j-单 0
[0195] 步骤(4).返回 Bt。
[0196] 在下面过程中，给出了Sponge化t的实验评估结果。
[0197] 在运一部分，本实施例评估1)FGV巧由象模型，2)第一阶段排队策略与第二阶段分 配策略的最优组合，W及3)已实现的E-F运行时机制的目标。本实施例从虚拟机层面评估了 FGVC模型节省带宽的效果。进一步说，本实施例的实验分别评估了 FGVC模型和两阶段虚拟 机放置算法的有效性和高效性。此外，本实施例评估了每一个租户的吞吐率和响应时间。最 后，本实施例还证明了在实际云平台中实现虚拟机到虚拟机间的带宽保证是可行的。
[0198] 下面从租户层仿真方面进行解释说明。
[0199 ]为了评估前两个方面，本实施例用Py thon实现了 FGV对莫型、5个排队策略、3个分配 策略和Oktopus的V对莫型（一种使用相同带宽分配方式的软管模型）。下表1示出了应用种类 分布。
[0200]表 1
[0202] 仿真设置:本实施例的仿真器使用由1个核屯、层交换机、4个汇聚层交换机、80个 ToR交换机和1600台服务器组成的3层的树状拓扑模拟实际的云数据中屯、。为了使实验简洁 明了，所有的服务器的CPU和内存有相同的配置，且每台服务器有4个虚拟机槽。服务器、ToR 路由和聚合路由的上行带宽分别为100Mbps、Kibps和lOCibps。
[0203] 实验的数据集来源于bing.com，包含许多组服务请求数据。服务请求由多种任务 类型(交互式应用或批处理任务)和通信模式(如线形、星形、网形等)组成。本实施例从Bing 的工作流中选取了 20000组服务数据，大致可分为四类，如表1所示。运20000组虚拟机请求 满足泊松分布，其平均到来时间(A)为0.02,任务的执行时间满足指数分布，任务离开速率 (y)为0.00002。
[0204] 首先，本实施例评估了FGV对莫型，而后定量分析了通过优化模型节省的带宽，并和 V对莫型做比较。
[0205] 带宽节省：如上所述，虚拟机请求可W被分为四类。第一类是批处理任务（如 MapReduce)。此类拓扑是星形的，可W通过FGVC模型优化约77%的带宽（图10)。第二类是交 互式应用（如3层网络应用），3层网络应用的拓扑是线状的，通过FGVC可W节省18%的带宽。 另外两种拓扑是全连接的通信模式W及孤立的、无交互的模式，所W与VC模型相比，没有节 省带宽。FGVC模型对所有20000个任务的带宽优化率达到48%。在VC模型中，每个节点有着 同样的带宽保证，运很容易使某些节点成为瓶颈。通过W上分析可W发现，FGVC模型在较集 中的网络拓扑中有着更好的节省带宽的性能。
[0206] 吞吐率:本实施例根据所有任务完成的时间比较吞吐率，因为较短的任务完成的 时间在持续任务的场景下意味着更高的吞吐率。图11表示了 3种不同的分配策略与不同的 排队策略组合的完成时间。best-fit与LRRF租户是最优的，引物运个组合使平台的碎片最 小化，W接纳更多之后到来的任务。worst-fit与SRRF组合最优，因为运个组合能更好地在 每个单位时间内为后面的任务遗留最小的碎片。另一方面，SRRF与worst-fit分配策略结合 是最优的，因为运个组合尽可能在每个单位时间为之后到来的大任务保留最大的空间。本 实施例用20000个虚拟机请求完成了实验，20000个请求的总花费在定价模型下是一致的。 云平台的利润率越大，任务的完成时间就越短，正如LRRF与first-fit相结合，其利润率是 最大的。
[0207] 本实施例还在利润率和虚拟机利用率方面比较了性能最优的FGVC+LRRF+first-fit组合和传统的VC+FCFS+first-fit组合。在图12a中，本实施例画出了运两种方案每秒钟 的利润率。在达到稳态之前，二者的利润率基本相同，因为此时平台的资源充足。但当达到 稳态时，本实施例的解决方案的平均利润为17.60，而之前的解决方案为15.34，本实施例提 出d方案比传统的方案提升了 12.84%。虚拟机利用率的结果也基本一致，如图12b所示，本 实施例提出的方案在稳态时利用率为99.50%，比传统方案提升32.20%。
[0208] 为了评估新方案的完整性和鲁棒性，本实施例改变带宽资源W及平台负载的大 小，比较 VC+FCFS+first-fit，FGVC+FCFS+first-fit和FGVC+LRRF+first-fitS种方案的性 能，结果如13a所示。在带宽资源不同的情况下，实验结果如图所示。随着任务的平均带宽请 求增大，任务的完成时间也随之变长，但本实施例的方案总是最优的。当本实施例改变平台 负载时，结果与之类似，如图13b所示。从图中可W发现，FGVC在组合中起着非常重要的作 用。
[0209] 响应时间：本实施例的方案还从租户的角度考虑了响应时间。图14a和图14b分别 展示了 15种组合策略的平均等待时间和平均队列长度。从图中本实施例可W总结出，FCFS 使得平台的响应时间最佳，因为调度机制每次都用贪屯、法将等待最长时间的任务最先处 理，运对于减小平均等待时间和等待队列长度效果明显。本实施例发现，从云平台响应时间 的角度，FGVC+FCFS+best-fit是最优的租户策略。
[0210] 本实施例还在更细粒度对响应时间进行了分析。图15a展示了每个任务的等待时 间。图15b展示了每个任务的队列长度。基于VC模型的解决方案中，虚拟机请求的等待时间 不断增加，而在基于FGV对莫型的方案中，等待时间稳定。
[0211]图16a和图1化中，本实施例改变平均带宽大小和平台负载，比较S种解决方案的 平均等待时间和平均咧咧长度。改变平均带宽请求大小得到的实验结果如图16a所示。随着 平均带宽请求变大，平均等待时间也随之增大，但FGVC+FCFS+best-fit始终是最优的。改变 平台负载时，趋势是相同的，如图16b所示。综上所述，FGV对莫型对于优化响应时间最重要的 因素。
[0212] 另外，给出了应用层面的实验验证结果。
[0213] 本实施例通过一个小型原型的部署评估了E-F运行时机制。评估的目标有：1)展示 E-F运行时机制即使在最坏的情况下也能提供带宽保证;2)展示E-F运行时机制实现了有保 证租户和无保证租户间的公平分享3)展示E-F运行时机制是高效利用的。本实施例在两种 情形下展示了高效公平运行机制的W上目标：多对一场景和MapReduce场景，就像 ElasticSwitch一样。
[0214]试验台设置:本实施例在小型数据中屯、试验台上实现了 SpongeNet,它由7台物理 机组成了2层树状拓扑，如图17。本实施例在运个数据中屯、部署了化enStack，其中包括1个 控制节点和6个计算节点。每个服务器有着2GHz Intel Xeon E5-2620CUPS和16GB内存。1层 (如服务器和ToR交换机之间）和2层的带宽分别是230和700Mbps。
[0215] 多对一场景:两个虚拟机X和Z同在服务器1上，属于两个不同的租户，运两个租户 的其他的虚拟机处于其他的服务器节点上，如图18a所示。虚拟机Z接收来自多个虚拟机的 数据，而虚拟机X接收来自于单一虚拟机的数据。他们争用绿色的物理链路，如图18b。
[0216] 在ElasticSwitch中，X和Z都有着相同的IOOMb带宽保证，代表在230Mbps上可W提 供的最大保证带宽。图19a比较了X在四种解决方案下的吞吐率：无保护、静态预留 (Oktopus) ,ElasticSwitch和Sponge化t。SpongeNet在运两个有保证租户的场景中，与 ElasticSwitch有着类似的表现。即使当Z的发送方在不断增加时，SpongeNet仍会为X提供 带宽保证。同时，当没有发送方与Z通信时，SpongeNet可W将全部的物理链路提供给X，运实 现