IaaS中关键应用部署优化

在基础设施即服务云中优化关键应用的部署

摘要

本文针对需要对所需资源容量提供保障的关键租户应用，扩展了经典的数据中心资源分配优化问题。我们确定了一组具有代表性的用户可发布的约束和新的优化目标，并建立了相应的数学模型及整数规划模型。通过一个典型的网络功能虚拟化应用作为案例研究，我们验证了该方法的可行性，并进行了初步的可扩展性评估。结果表明，在单一优化问题中结合租户与提供商的冲突目标具有显著优势。

关键词 ：数据中心资源分配优化；虚拟机放置；基础设施即服务；IaaS；整数线性规划；网络功能虚拟化；NFV；关键应用的部署。

1 引言

当代通用云服务为各种工作负载提供了一种极具吸引力且经过验证的选项，从网页服务到大数据分析均适用。资源池化是这些服务的基本特征，“不同的物理和虚拟资源根据需求动态分配和重新分配”（NIST，2011）。为了降低运营成本，运营商通过将工作负载整合到最少数量的主机上，并将未使用的资源下线，持续且独立于租户地优化这种映射。在基础设施即服务（IaaS）领域，此活动称为分配优化，指的是将虚拟机（VM）分配给运行它们的虚拟机监控器。

激进的分配优化得以实现，得益于租户已学会接受的云服务属性：
- 通常，租户应用程序到资源的映射对租户是隐藏的——他们甚至无法观察，更不用说控制它了
- 非功能性服务参数即使有指定，也仅被粗略地指定
- 服务级别协议（SLA）对提供商非常宽松。

在这种情况下，服务的非功能性属性（如性能）可能存在显著的可变性（Li 等，2012 年）被视为一种既定事实。此处的可变性包括不稳定性以及异质性。聚焦于基础设施即 服务（IaaS）的性能，这意味着虚拟资源性能并不会随着时间推移或跨实例保持一致—— 即使提供商使用某种粗略的容量度量（例如亚马逊网络服务的“EC2计算单元”）进行规定。

性能不稳定（在某种程度上还包括异质性）的根本原因就是租户共享资源。正如进程在操作系统中竞争有限的CPU时间一样（也通过缓存等方式间接影响彼此），同一虚拟机监控器上的虚拟机可能会相互影响性能。主机、操作系统和网络虚拟化技术确实提供了一系列用于租户性能隔离的机制——通俗地说，即避免“嘈杂邻居” 效应。这些功能的有效性各不相同：例如，CPU使用上限通常是实现虚拟机CPU性能隔离的有效方法，但对于计算密集型应用，缓存和内存带宽可能成为瓶颈（金等， 2013）。时效性关键应用可能需要专用资源（例如，专用CPU核心）以确保稳定性能。然而，尽管提供商可以使用这些手段，对租户而言，性能隔离仍然是云服务中不可观测且不可控制的方面。其他运行时额外功能保障机制（例如，运行时容错技术）也同样如此。

随着对时效性关键和极高可用性应用的“云化”需求不断增加，这一现状正在迅速改变。为了真正实现此类系统的应用级性能和可靠性保障，租户必须能够对运营商满足其（虚拟）资源需求的方式提出各种约束条件。这些约束条件必须经过仔细选择，以确保租户确实拥有足够的控制权，同时又为提供商留出充分的机会进行有效的分配优化。此类约束条件的示例可能包括虚拟机需要专用的物理主机子系统，或针对虚拟机或虚拟机类型的亲和性与反亲和规则。本文的主要目标是首次对该新场景下的基础设施即服务（IaaS）运营商资源分配优化问题进行研究。

1.1 通用云中的分配优化

IaaS向租户提供虚拟化资源，其中最重要的是可按需创建和销毁的虚拟机。资源的快速弹性以及按使用量计费使租户能够持续将其资源使用情况适应动态变化的需求。通过这种方式，即使云资源的“单位成本”高于自有资源，IaaS仍可显著降低租户的整体运营成本。从提供商的角度来看，IaaS可以高效地提供服务，因为将大量资源共享给彼此相对独立的租户，能够对变化的工作负载实现“统计复用”（温曼， 2012），再加上简单的规模经济效应。然而，通常情况下，租户对其预留资源在物理资源上的部署仅有有限且间接的影响，这使得关键应用易受多种故障影响，例如共模硬件和容量故障（科奇斯等，2013）。这一点不仅适用于当前的通用公共 IaaS云，也基本适用于主流开源IaaS软件框架。

运营商和租户在实现各自优化目标时存在冲突。运营商力求将租户虚拟机尽可能整合到最少数量的虚拟机监控器上，通过关闭未使用的主机来节省电力和冷却成本（曼恩，2015c）。可靠性、可用性、性能稳定性和同质性属于次要考虑因素 （Iosup 等，2011）；如有需要，租户必须在其应用层面为应用程序配备适当的弹性机制。实施这些机制——例如，维持在线备用容量——会产生严重的成本影响。因此，冗余也必须进行动态管理，同时考虑可变应用工作负载以及可变性能可靠性 （巴雷特等，2013）。

1.2 关键应用的新兴用户需求

许多新兴的云交付服务必须满足各种服务等级目标（SLO）上的严格约束。一个典型的例子是网络功能虚拟化（NFV）（欧洲电信标准协会，2012年）：当前电信领域推动将网络功能从专用设备迁移到基础设施即服务（IaaS）的趋势。这一演进过程的第一步是电信提供商将现有的传统设备几乎不做修改地迁移至一组虚拟机中，并通过标准网络虚拟化或越来越多地通过软件定义网络（SDN）将其连接起来。这些所谓的虚拟化网络功能（VNF）提供的电信服务范围广泛，从简单的IP数据包流处理到复杂的IP多媒体子系统规范。关键的是，它们必须提供telco-grade服务；即允许的延迟、响应时间以及可用性阈值都非常严格（Dräxler 等，2017）。

为了在服务层面满足这些要求，租户需要在底层基础设施即服务（IaaS）服务上执行类似严格的非功能性需求。理想情况下，租户应能够以约束条件的形式，将这些需求提交给运营商，这些约束条件基于已确立的资源服务属性（及其指标）进行表述。例如，虚拟机单核处理能力的可变性（通过测量单线程执行时可用CPU周期数量的变异系数，并在较小的滑动窗口内求和）应低于某个预定义值。随后，运营商应能根据这一声明式请求做出相应的部署决策，包括配置适当的隔离机制。

这种理想化方法存在两个主要问题。首先，对于表征NFV基础设施即服务（ IaaS）资源服务的属性（和指标）尚未达成共识。NFV服务质量指标规范（ETSI， 2014）确立了速度、准确性和可靠性类别，并定义了参与VNF交付的虚拟机（ VM）和虚拟网络（VN）最重要的属性和指标；然而，该规范较新，因此应用经验仍然不足。此外，（ETSI，2014）对已知可能的云服务缺陷覆盖不完整，仅聚焦于现有NFV应用视角下被认为最重要的“痛点”。其他云服务质量属性/指标和 KPI分类体系在这一用途上更不合适；例如，服务测量指数（SMI）（CSMIC， 2013）强调与业务相关的服务属性，却牺牲了运行时技术合规性的表达。其次，从指标约束条件推导出分配和配置决策一直是一项复杂的任务；在许多情况下，这在理论上可行，但实际不可行。因此，一种切实可行的方法是结合使用资源服务质量约束以及用户发出的明确分配和配置指令。欧洲电信标准协会（ETSI）发布的各种 NFV架构指南和接口规范（参见ETSI，2013）遵循了这一模式。

现在尝试建立这些的明确分类法还为时过早。然而，ETSI NFV 基础设施即服务规范中的适用部分可被解读为：使用户能够请求在虚拟机监控器领域中已存在的功能——只是在当前云环境中对租户不可见且无法请求。根据NFV规范、我们在服务质量虚拟化设计方面的先前经验以及当前针对电信NFV应用的工作（见下文）表明，租户可能希望请求至少以下部署属性：

1. 关于虚拟机监控器主机的可划分资源，容量保证能够为虚拟机提供即使在细粒度时间尺度下也保持稳定的保障。当前技术条件下，属于此类的资源包括CPU周期、 I/O带宽（可能涉及网络附加存储）、网络数据包或数据速率以及物理内存空间。现代虚拟机监控器可以配置为对这些容量提供配额保证。由于这些保证是通过调度实现的，因此以这种方式抽象出的“专用”资源并不一定是完美的；然而，至少在CPU调度方面，甚至实时虚拟机监控器也正在出现（适用于不同级别的实时性要求）。

2. 某些应用对当前不可划分资源的争用较为敏感，例如CPU缓存以及各种主机内部带宽（内存、设备总线、互连）。为了保护这类应用，租户可能希望请求专用的物理资源。在虚拟化中，目前大多数可用的是将CPU核心或核心组专用于虚拟机（至少对于对称多处理系统而言）。另一项需求可能是将虚拟机绑定到特定核心，以避免在核心或 CPU之间迁移所带来的性能影响。虚拟机也可能需要对物理设备（如网络接口卡和本地存储）的专用访问，但这一需求的目的可能是提升性能，而非确保性能容量保证。

3. 从部署到虚拟机监控器的角度来看，大多数运行时可靠性技术所提出的要求可以表述为虚拟机之间的反亲和性和亲和性规则。构成容错集群的虚拟机通常需要分布在不同的物理主机上，以防范虚拟机监控器主单点故障。相反，在实现看门狗模式时，最优解可能是将工作与看门狗虚拟机运行在同一台主机上。亲和规则对于应用程序性能也可能至关重要，因为位于同一主机上的虚拟机间通信通常比跨网络通信快得多。

4. 有必要禁止虚拟机热迁移，以避免在将正在运行的虚拟机从一台主机迁移到另一台主机过程中可能出现的短暂但可检测的虚拟机停顿。

在面向关键应用（特别是网络功能虚拟化）的基础设施即服务中，两个最基本的资源服务是虚拟机和虚拟网络。我们针对虚拟机提出了上述部署需求分类——尽管虚拟网络同样具有不可忽视的部署方面。在本研究中，我们选择聚焦于关键应用中虚拟机部署优化这一开放性问题，并将讨论范围限制在物理配置中：
- 主机间网络连接的物理延迟没有显著差异（或这种差异对应用程序无关紧要）
- 带宽瓶颈可能是主机网络接口卡，而不是网络架构。

这些假设在大型数据中心的规模下可能不成立，但对于单个机架或相连的本地机架组通常是成立的。这已经处于当前用于网络功能虚拟化的商业数据中心‘云单元’ 的规模范围内；此外，许多关键分布式应用仍保持这种数据中心级别的局部性，而整个集群的地理分布则被视为一个独立的问题。因此，我们的结果以直接适用的结果应对开放性问题，并有望为更广泛且数学上更具挑战性的集成虚拟机和虚拟网络部署优化问题提供有用的见解。

2 先前工作

如何最优地将虚拟机分配给可用的物理机（PMs）这一优化问题在最近几年受到了广泛关注，从而提出了多种问题模型和算法。

在一些研究中，仅考虑了虚拟机的CPU负载和物理机的CPU容量（Beloglazov 等， 2012；Ghosh 和 Naik，2012；Guazzone 等，2012；Lago 等，2011；Chowdhury 等， 2013）。同时考虑其他资源维度，如内存（Gao 等，2013；Bartók 和 Mann，2015），甚至内存、磁盘和/或网络I/O（Biran 等，2012；He 等，2012；Rodero 等，2012； Tomás 和 Tordsson，2014），会使问题略微复杂化，但在实践中更具实用性。优化的目标在许多情况下是活跃的物理机数量（Breitgand 和 Epstein，2012；Ribas 等，2012； Shi 等，2013；Song 等，2014），通常还结合其他指标，如服务等级协议违规次数（ Beloglazov 等，2012；Bobroff 等，2007；Verma 等，2009；Zhu 等，2009）。关于所用问题模型的更多细节可参见Mann（2015b）。

关于文献中已提出的算法技术，情况稍显单一。许多研究者建议利用虚拟机分配问题与著名的装箱问题之间的相似性，并将首次适应和最佳适应等装箱启发式算法应用于虚拟机分配（Beloglazov 和 Buyya，2012；Bobroff 等，2007；Jung 等，2010；Tomás 和 Tordsson，2014；Verma 等，2009）。然而，实际上虚拟机分配问题比装箱问题困难得多（Mann，2015a），这限制了这些启发式算法仅适用于最简单的虚拟机分配问题。其他研究者建议使用元启发式算法，如遗传算法和蚁群优化（Gao 等，2013；Gmach 等，2008），或复杂的专有启发式算法（ Ahvar 等，2015）。也有一些尝试采用混合整数线性规划及相关技术为虚拟机分配设计精确算法（Guenter 等，2011；Li 等，2011）。

3 提出的方法

本文将经典的基础设施即服务分配优化问题模型（曼恩，2015c）扩展至关键应用的虚拟机放置。为此，我们扩展了部署必须遵守的约束条件集，并修改了优化目标，以同时反映租户和提供商的目标。

除了总CPU容量外，物理核心也作为一级概念存在。主机可以被开启或关闭。租户虚拟机可以是已经存在的，也可以是刚刚请求并等待配置的。“未来”虚拟机目前尚未请求，但租户已声明将来需要这些虚拟机，提供商可能会被要求保证能够及时提供这些未来的虚拟机。对于某些虚拟机，租户可能决定禁止迁移（从而限制数据中心优化过程中虚拟机分配的重新调整）。

所有虚拟机都有计算负载和其他资源负载需求。我们重点关注计算容量，因为它是处理其他容量类型的代表性问题，并且目前在网络功能虚拟化（NFV）中受到重视。虽然“其他负载”需求以每种容量类型为基础表示为单个标量，但计算容量需求则以每CPU核心的负载形式给出，或以请求的专用核心数形式给出。虚拟机的负载可被标记为必须保证的容量。

为了实现集群和应用可靠性，租户可以要求将一组虚拟机中的最多k个虚拟机部署在同一台主机上。在传统的可靠性术语中，这是一种副本集分配约束，但该机制也可用于表达多种多样的反亲和规则。亲和规则可以类似地引入；我们选择省略这些规则以简化模型，因为反亲和规则对于关键应用而言更为重要。

在大多数通用云数据中心资源分配优化的研究中，目标函数是通过开机主机数量来衡量的能耗。我们引入了两个额外的因素：在不启动更多虚拟机监控器（通常耗时较长的操作）的情况下能够满足的未来请求量，以及单主机故障的影响。前者通过数量进行建模用于可分配的“未来”虚拟机数量，而后者表示由于主机故障导致任何租户可能丢失的虚拟机最大数量。为了突出这两个目标之间的权衡，我们选择从中构建一个加权综合目标函数。我们对建模最优性的方法旨在作为一个代表性示例；与多方面优化常见情况一样，什么是“最优”解在很大程度上取决于具体问题。

接下来，我们将介绍一个数学模型以及适用于该方法的整数规划模型，并附上一个案例研究。

4 问题形式化

可用的物理机集合表示为P。物理机p ∈ P 具有pcn(p) ∈]+核心数（物理机 CPU核心）以及pcc(p) ∈+每核心的计算容量。物理机p 的核心集合表示为 p C(p)；此外，设
$$
PC = \bigcup_{p \in P} C(p)
$$
表示所有物理机核心数的集合。除了中央处理器之外，其他资源维度的容量由 cap(p, r) ∈+给出，其中p ∈ P 且 r ∈ R ={memory,ingressPacketRate, egressPacketRate, IOPS}。

一组虚拟机 V 由三个子集组成：V = V0 ∪ V1 ∪ V2, ，其中 V0, V1, 和 V2 是两两互不相交的。V0 包含已被物理机容纳的虚拟机，而 V1 包含当前需要分配的新请求虚拟机。V2 包含未来虚拟机的预留资源，这些虚拟机目前无需分配；它们仅代表未来工作负载的指示。

对于每个虚拟机 v ∈ V，其处理器核心数（vCPUs）用 vcn(v)∈]+ 表示，虚拟机每核心请求的计算容量用 vcc(v) ∈+ 表示，其核心集合用 vC(v) 表示。所有虚拟机核心的集合用
$$
VC = \bigcup_{v \in V} vC(v)
$$
所有虚拟机及每个资源维度的负载如下所示：
- 如果客户为给定的虚拟机和给定的资源维度请求了保证容量，则该值用作该虚拟机的负载
- 否则，对于现有虚拟机（v ∈ V0），可以使用其当前负载，或基于历史观测数据对未来短期负载进行估计；但如果该值高于请求容量，则使用请求容量
- 否则，将使用请求容量的特定百分比，考虑到用户通常会高估其虚拟机所需的容量（Reiss 等，2012年）。

对于任意虚拟机 v ∈ V 及其核心 vc ∈ vC(v)，vcl(v, vc) ∈+ 表示该虚拟机核心的计算负载。对于虚拟机 v ∈ V 以及任何其他资源类型 r ∈ R，vload(v, r) ∈+ 表示其在该资源维度上的负载。

存在一个虚拟机到物理机的当前映射，由函数 map0: V0 → P 表示。我们的目标是计算一个新的映射 map: V′→ P，其中 V′ ⊆ V0 ∪ V1， 即V0 ∪ V1 中的所有虚拟机必须被映射到物理机上，并且可能还包括V2 中的一些虚拟机。

映射成本由三项组成。第一项是活跃的物理机数量。如果至少有一个虚拟机被映射到某台物理机，则该物理机称为活跃的。非活跃的物理机可以切换到睡眠模式，从而显著降低其能耗。因此，为了节约能源，应最小化活跃的物理机数量，记为 A(map)，并按如下方式计算
$$
A(map) = \left| { p \in P \mid \exists v \in V’, map(v) = p } \right|
$$
映射成本的第二项奖励将V2中的虚拟机分配到物理机。分配到物理机的V2中虚拟机的数量由 B(map) = |V′ \ (V0 ∪ V1)| 给出。

映射成本的第三项用于惩罚物理机故障对租户造成的影响。为了更精确地描述这一点，设T表示租户集合，对于每个t ∈ T，令VT(t) ⊆ V表示属于该租户的一组虚拟机。（因此，子集VT(t)，t ∈ T构成了V的一个划分）。令C(map)表示分配到同一物理机上的属于同一租户的虚拟机最大数量。显然，这代表了物理机故障对租户造成的最坏影响，即受影响的虚拟机数量的最大值，其可按如下方式计算：
$$
C(map) = \max_{t \in T, p \in P} \left| { v \in VT(t) \mid map(v) = p } \right|
$$
我们希望最小化的总体目标函数是
$$
\alpha \cdot A(map) - \beta \cdot B(map) + \gamma \cdot C(map)
$$
其中α、 β和γ为给定的非负常量。需要注意的是，A(映射)和C(映射)需要最小化，而B(映射)需要最大化。

由映射编码的解决方案必须满足以下容量约束：
$$
\forall p \in P, \forall r \in R: \sum_{v \in V, map(v) = p} vload(v, r) \leq cap(p, r)
\quad (1)
$$
这些涉及除中央处理器之外的所有资源类型。对于中央处理器，情况更为复杂，因为某些虚拟机可能需要专用核心。令Vded ⊆ V表示请求了专用CPU核心的一组虚拟机，Vnonded= V \ Vded表示其余的虚拟机。对于物理机p ∈ P，令Vded(p, map) ={v ∈ Vded: map(v) = p}表示需要专用核心且映射到p的虚拟机集合，Vnonded(p, map) ={v ∈ Vnonded: map(v) = p}表示不需要专用核心且映射到 p的虚拟机集合。映射到物理机 p ∈ P的虚拟机可以在p的中央处理器上进行调度，当且仅当满足以下所有约束条件时：
$$
\forall v \in V_{ded}(p, map) \cup V_{nonded}(p, map): vcc(v) \leq pcc(p)
\quad (2)
$$
$$
\sum_{v \in V_{ded}(p, map)} vcn(v) \leq pcn(p)
\quad (3)
$$
And
$$
\sum_{v \in V_{nonded}(p, map)} \sum_{vc \in vC(v)} vcl(v, vc) \leq \left( pcn(p) - \sum_{v \in V_{ded}(p, map)} vcn(v) \right) \cdot pcc(p)
\quad (4)
$$
约束(2)确保每个虚拟机都被映射到具有足够容量核心的物理机上。约束(3)确保物理机p的核心数足以满足映射到其上的需要专用核心的虚拟机，而约束(4)确保物理机p中剩余用于不需要专用核心的虚拟机的核心具有足够的总容量。

关键虚拟机的进一步特殊约束条件可表述如下：
- 中的虚拟机 v 不得迁移
1. 如果 v ∈ V0：
$$
map(v) = map_0(v)
\quad (5)
$$
2. 如果v ∈ V1, ，则必须以不会导致SLA违规的方式放置v，因为v的放置位置将不能再更改。原则上，如果映射到同一物理机的多个不可迁移的虚拟机开始大量使用相同的资源，则可能会出现问题，因为此类过度使用无法通过迁移来补救。然而，我们的方法确保需要保证容量的虚拟机（关键虚拟机通常属于此类别）确实获得该容量（因为在分配决策过程中，我们使用所需容量作为此类虚拟机的负载，即使其实际负载较低），从而避免此类虚拟机发生SLA违规。
- 对于一组虚拟机 V ⊆ V, 最多有 k 个可以分配到同一物理机：
$$
\forall p \in P: \left| { v \in V \mid map(v) = p } \right| \leq k
\quad (6)
$$

5 整数线性规划模型

设n = |V | 且m = | P|。虚拟机的索引为vi(i = 1, …, n)，物理机的索引为pj (j = 1, …, m)。为了将上述问题表述为整数线性规划(ILP)，引入以下二进制变量：
$$
Alloc_{i,j} =
\begin{cases}
1 & \text{if } v_i \text{ is allocated on } p_j \
0 & \text{otherwise}
\end{cases}
$$
$$
Active_j =
\begin{cases}
1 & \text{if } p_j \text{ is active} \
0 & \text{otherwise}
\end{cases}
$$
此外，还有一个整数变量C，对应于上述的C(映射)。

使用这些变量，整数规划可以表述如下（除非另有说明，i = 1, …, n 且 j = 1, …, m）：
$$
\text{minimise } \alpha \sum_{j=1}^{m} Active_j - \beta \sum_{i \in V_2} \sum_{j=1}^{m} Alloc_{i,j} + \gamma \cdot C
\quad (7)
$$
$$
\text{subject to } \sum_{j=1}^{m} Alloc_{i,j} = 1, \quad \forall v_i \in V_0 \cup V_1
\quad (8)
$$
$$
\sum_{j=1}^{m} Alloc_{i,j} \leq 1, \quad \forall v_i \in V_2
\quad (9)
$$
$$
Alloc_{i,j} \leq Active_j, \quad \forall i, j
\quad (10)
$$
$$
\sum_{i: v_i \in VT(t)} Alloc_{i,j} \leq C, \quad \forall t \in T, \forall j
\quad (11)
$$
$$
\sum_{i=1}^{n} vload(v_i, r) \cdot Alloc_{i,j} \leq cap(p_j, r), \quad \forall j, \forall r \in R
\quad (12)
$$
$$
vcc(v_i) \cdot Alloc_{i,j} \leq pcc(p_j), \quad \forall i, j
\quad (13)
$$
$$
\sum_{i: v_i \in V_{ded}} vcn(v_i) \cdot Alloc_{i,j} \leq pcn(p_j), \quad \forall j
\quad (14)
$$
$$
\sum_{i=1}^{n} cpu_load(i, j) \cdot Alloc_{i,j} \leq pcn(p_j) \cdot pcc(p_j), \quad \forall j
\quad (15)
$$
$$
Alloc_{i,j} = 0, \quad \text{if } v_i \in V_0 \text{ must not be migrated and } map_0(v_i) \neq p_j
\quad (16)
$$
$$
\sum_{i: v_i \in V’} Alloc_{i,j} \leq k, \quad \text{if at most } k \text{ of } V’ \text{ can be on the same PM}, \forall j
\quad (17)
$$
$$
Alloc_{i,j} \in {0,1}, \quad Active_j \in {0,1}, \quad \forall i, j
\quad (18)
$$
目标函数(7)与之前相同，包含活跃的物理机数量、V2中可分配的虚拟机数量，以及同一物理机上同一租户的最大虚拟机数量。公式(8)确保V0 ∪ V1中的每个虚拟机恰好被分配到一个物理机，而公式(9)确保V2中的每个虚拟机至多被分配到一个物理机。约束条件(10)确保对于至少分配了一个虚拟机的物理机pj ，Activej= 1成立。结合目标函数，这保证了Activej= 1仅对容纳至少一个虚拟机的那些物理机成立。采用类似逻辑，约束条件(11)确保C的值至少为C(map)；结合目标函数，可保证C恰好取此值。

约束条件(12)–(17)主要是将约束条件(1)–(6)用二进制变量Alloci, j进行的直接表述。(15)中的量
$$
cpu_load(i, j)
$$
表示虚拟机vi 若被分配到物理机pj上所消耗的CPU容量，其计算方式如下：
$$
cpu_load(i, j) =
\begin{cases}
vcn(v_i) \cdot pcc(p_j) & \text{if } v_i \in V_{ded} \
\sum_{vc \in vC(v_i)} vcl(v_i, vc) & \text{if } v_i \in V_{nonded}
\end{cases}
$$
如果 vi ∈ Vnonded，那么这是 vi 的总CPU负载，且不依赖于 j。如果 vi ∈ Vded，则它可能高于 vi 的总CPU负载，并且还依赖于 j。然而，从整数规划的角度来看，最重要的是对于每个 i、j，cpu_load(i, j) 是一个常量。

6 案例研究

为了展示我们的方法，我们对一个特定的、非平凡的NFV应用的部署进行建模，针对成本函数中的不同权重值求解该问题并解释结果。在当前的工具链中，我们使用 Gurobi优化（2015）作为求解器。可扩展性分析见第6.4节。

6.1 Clearwater项目

根据Clearwater项目网站（http://www.projectclearwater.org）的介绍，“ Clearwater是一种IP多媒体子系统（IMS）的开源实现，从头开始设计，专为在云中进行大规模可扩展部署而优化，旨在为数百万用户提供语音、视频和消息服务”。核心而言，Clearwater是一个基于标准的（VoIP）电话‘交换中心’，正迅速成为NFV研究中的标准示例。（IMS服务需要提供的大量更复杂的服务在此项工作中无关紧要。）大型电信设备供应商均有各自的IMS实现；然而，Clearwater是开源的，并且明确设计为可在NFV IaaS环境中作为所谓的虚拟网络功能进行部署。它以一种将IMS标准定义的各种功能组件直接映射到其组件服务的方式来实现IMS标准。

可以将所有Clearwater组件部署到单个VM或单个物理主机上；但其主要设计意图是以分布式方式进行部署，即将组件服务实例放置在独立的虚拟机中。 展示了典型分布式Clearwater部署的拓扑结构；几乎所有组件均可通过运行相同组件代码的虚拟机集群进行扩展。

作为参考，我们简要描述了各组件的功能。更多详细信息，请感兴趣的读者参考 IMS标准（3GPP，2015）以及Clearwater项目的文档（Project Clearwater，2015）。
- 博诺 实现了P‐CSCF IMS功能——作为用户与SIP路由器之间的边缘代理。
- Sprout SIP路由器，负责大部分I‐CSCF和S‐CSCF功能。它处理客户端认证，并在用户（和应用服务器）之间路由SIP请求，例如呼叫建立和拆除消息流。Sprout还内置了MMTel应用服务器，以支持多媒体通信。
- 家园 是一种家庭用户服务（HSS），即用于存储用户数据的 IMS 标准设施。家园可以作为镜像，也可以作为主存储。

6.2 初始部署

我们从一个假设的（但符合实际情况的）Clearwater部署开始案例研究，该部署的资源分配是手动完成的。数据中心中可用的有两台“大型”和两台“小型”物理机；它们的容量列于表1中。 展示了荷马、家园、两个博诺、两个sprout实例以及另一租户的两台虚拟机对中央处理器、内存和IOPS容量的使用情况。具体数值数据见表2。（注意：sprout实例具有两个核心数，而其他Clearwater组件均具有单个核心数。另一租户的两台虚拟机分别具有两个和四个核心数。）为了简化讨论，我们省略了网络（速率）容量，因为在我们实际经验中的部署场景中，网络容量并不是主要关注点。

表1 可用物理机类型的参数
物理机类型
大型物理机
小型物理机

显然，该部署在多个方面都不够理想。两台较小的物理机（小PM1、小PM2）的 I/O 能力已达到饱和，而两台较大的机器资源利用率却较低。此外，小PM2 的空闲内存非常紧张。总体而言，这种部署方式效率低下，部分资源已饱和，同时又存在大量未使用的资源。通过更优的部署方案，我们或许可以关闭一台或两台机器。

另一个方面涉及容错性。在通用云环境中，通常无法在一个区域内部设置物理冗余规则。这就可能导致同一集群的虚拟机被部署在同一物理机上，从而影响容错性。在本案例中，两个 Sprout 实例位于同一物理机上，两个 bono 实例也是如此。

表2 初始部署中虚拟机的资源利用率
VM
Sprout1
Sprout2
波诺1
波诺2
荷马
家园
其他虚拟机1
其他虚拟机2

6.3 优化部署

我们现在转向使用优化框架来指导部署。为此，我们需要明确各个虚拟机的资源使用情况，以及这些容量是否需要保证、虚拟机所需的CPU核心数以及核心是否必须为专用，还有任何尚未完成的“未来”预留资源。在本例中，这些信息如表3所示。此外，为了保证更高的容错级别，我们规定每台物理机上最多只能分配一个bono实例和一个 sprout实例。

我们使用不同的权重求解整数线性规划问题。在第一次运行中，α被设为较高值（整合最为重要），导致活跃的物理机数量显著减少，如 所示。该部署实现了良好的整合效果，并具备所需的反亲和性属性。然而，也存在一些缺点：单个节点上存在过多同一租户的虚拟机，一旦某台机器发生故障，将造成较大影响。另一个问题是系统未为未来的bono实例预留资源（根据表3，该租户未来将增加一个 bono实例）：由于bono实例不能共置，当租户请求第三个bono实例时，必须启动一台新的物理机，这需要不可忽略的时间。

表3 示例中虚拟机类型的资源配置
虚拟机类型
Bono
sprout
荷马
家园
其他1
其他2

所示的部署也为保留的未来虚拟机分配了容量，同时仍然仅使用三台物理机，而不是原先的四台。该预留在小型物理机SmallPM2上以“bono3”的名称显示。当然，此分配也遵守所有容量和反亲和性约束条件。

最后一次运行配置了较高的γ，旨在更好地分布属于同一租户的虚拟机。求解器实现了一种部署方案，使得同一物理机上属于同一租户的虚拟机最大数量为两台（在此前的分配中，该数量为三台），且活跃的物理机数量仍仅为三台，如 所示。

我们的案例研究表明，根据不同的提供商优先级调整权重能够以预期的方式改变部署的工程特性。协调这三个本质上相互矛盾的优化目标，并找到最能描述提供商意图的权重集，是本文未涉及的问题；未来，我们计划评估决策理论和运筹学中的标准方法在此问题上的适用性。

6.4 初步可扩展性评估

为了评估我们方法的可扩展性，我们对前述设置采用了合成式扩展：将四个物理主机复制n次，从而形成一个包含4n台物理机的微型数据中心，并将待分配的虚拟机集合也复制n次（n = 2, 3, 4…）。求解器运行在一台配备Intel Core i7处理器和16GB内存的工作站上。我们为求解器设定了30秒截止阈值。当在此时间限制内未找到最优解时，求解被中断，求解器返回截至目前获得的最优目标值以及最优解的最佳下界。我们所使用的求解器采用了随机化和并行化技术；因此，从大约100个物理主机开始，运行时间（以及强制性的求解中断）表现出显著差异。为此，我们选择展示使用单线程和相同种子值进行的单次求解任务的结果。

显示了找到的最优目标值和报告的界限； 显示了求解器运行时间。该扩展模式具有代表性，即运行时间如预期呈指数级增长；然而，即使对于约150台物理主机，我们仍可在半分钟内获得近似最优结果。可以认为，我们的基础场景以及扩展方式在一定程度上是人为设定的，还需进一步评估；尽管如此，该实验已表明，当需要快速决策时，该方法至少对于数十台服务器是可行的；而对于长期的数据中心再优化和决策预计算（允许数十分钟运行时间的情况），可处理的规模至少还要大一个数量级。

从本研究一开始就很清楚，使用现成工具进行纯整数线性规划建模和求解对于数据中心规模问题并不可行。我们的主要重点是首次尝试建立建模基础；目前已有大量技术有望实现数据中心规模下的高效决策。修改现有的各种启发式方法以用于数据中心分配优化只是其中一个选择；我们还计划评估增量求解技术和分层方法的适用性。需要指出的是，即使使用现成的求解器，我们已经能够覆盖完整的单机架规模范围——这使得我们的结果可直接应用于数据中心典型的“构建模块”内部。机架内分配本身就是一个重要问题。由于主机之间的通信在此处速度最快（且主机间数据传输的整体成本最低），许多分布式应用更倾向于将所有紧密耦合组件部署在同一机架内（可能在宏观尺度上还包括额外组件；例如，这些组件组的松散耦合实例位于“其他位置”）。我们的方法可直接应用于此类情况下的部署优化。

7 结论

在本文中，我们扩展了经典的数据中心资源分配优化问题，以适用于需要对其希望消耗的资源容量提供保障的关键租户应用。我们确定了一组具有代表性的用户可发布的约束条件和新的优化目标，并建立了一个数学模型及相应的整数规划模型，将租户和提供商目标结合到一个联合优化问题中。通过一个典型的NFV应用，我们验证了该方法的可行性，并展示了初步的可扩展性结果。后续工作将集中在为该建模框架建立可扩展至大量主机的求解方法，并进一步建模更多关键应用，以提升实际适用性。