计算机

Article通过编排模型提高边缘计算基础设施的效率 †

拉法埃莱·博拉 1,亚历山德罗·卡雷加 2 ID，马泰奥·雷佩托 2,* ID和乔尔乔·罗比诺 2
电气、电子与通信工程及航海建筑系（DITEN），热那亚大学，维亚奥佩拉皮亚13号，意大利热那亚16145； raffaele.bolla@unige.itS3ITI实验室，国家大学电信联盟（CNIT），维亚奥佩拉皮亚13号，意大利热那亚 16145；alessandro.carrega@cnit.it（A.C.）；giorgio.robino@cnit.it（G.R.）*通讯作者： matteo.repetto@cnit.it；电话：+39‐010‐353‐2057 †本文是我们发表于Carrega,A.;Portomauro,G.;Repetto,M.;Robino,G.的论文的扩展版本。该论文 题为《边缘计算中面向服务质量与能效的OpenStack扩展》，发表于2018年4月23日至26日在西班牙巴塞罗 那举行的第三届IEEE雾与边缘移动计算国际会议（FMEC2018）会议录中。
收稿日期：2018年5月22日；接受日期：2018年6月14日；发表日期：2018年6月20日

摘要

边缘计算是一种实现近端计算的有效范式，但不可避免地需要面对移动性问题和流量波动。
尽管软件编排可以在不同边缘基础设施之间提供有效的服务切换，但要实现几乎无服务中断的无缝 操作，必然需要预配置，并使部分网络功能在大多数时间内处于空闲状态，最终导致大量能源浪费 和效率低下。现有的整合算法在这些条件下效果甚微，因为它们缺乏上下文信息，即无法区分哪些 资源是实际使用的，哪些仅仅是为其他目的（如冗余、弹性、扩展、迁移）而预留的。虽然这一概 念相当直接，但其在真实环境中的可行性仍需验证。由于云管理软件中缺乏能效机制，我们开发了 一组针对OpenStack的电源管理和服务质量扩展功能，明确引入更多应用程序上下文信息。本文简 要描述了整体架构，并评估了其效率和有效性。我们分析了性能指标及其与功耗之间的关系，从而 将分析扩展到软件仿真无法研究的具体方面。我们还展示了利用上下文信息可显著提高工作负载整 合在节能方面的有效性。

关键词 ：能效；服务质量；边缘计算

引言

边缘计算是一种有效解决方案，可应对许多传统云范式无法满足的挑战性需求（例如地理分布、 计算邻近性、传输延迟）。它是5G愿景中的关键组成部分，旨在构建大规模的分布式、普适性、异构 和多域环境[1]。边缘计算将成为智能编排平台的有机组成部分，这些平台专门设计用于满足众多垂直 行业的严苛需求：智能制造、能源、电子健康、汽车、媒体与娱乐[2]。

与资源位于一个或少数几个大型数据中心且工作负载可能相当可预测的云不同，边缘计算将不可避免 地面临移动性问题，类似于蜂窝网络中已存在的问题。随着以用户为中心的服务的增长，其特征是
由于交互性和对延迟的严格限制，工作负载预计将遵循用户分布和移动模式，从而导致网络内出现不 均衡、不稳定和非均匀分布。因此，边缘设施的使用率将随着每小时、每日、每周和季节性周期而动 态变化。

硬件虚拟化（尤其是虚拟机监控程序）的异构性导致无法在不同安装环境之间迁移虚拟功能。为 应对这一限制，可针对每个特定的虚拟功能开发适当的管理钩子，以实现不同基础设施中两个运行实 例之间的状态迁移。软件定义网络能够在迁移过程中轻松实现流量复制，从而避免丢包和超时过期。
然而，由于技术和管理问题，资源供给所需的时间不可忽略；例如，可能需要数分钟到数天才能使一 个虚拟机（VM）准备就绪。因此，移动性管理的替代方案要么是在需求发生后进行反应式供给，但 由此产生的延迟可能无法满足大多数高要求应用程序的需求；要么采用主动供给，但这意味着需要运 行可能永远不会被使用的空闲实例。

主动供给本质上就是过度供给。长期以来，它一直是常见的“最省事”的解决方案，但它会导致 整体系统利用率低下，增加功耗，并降低整体效率，因此出于环境和经济原因，如今这种做法已不再 可接受。真正的问题在于需要运行空闲设备，这导致单位实际计算负载的功耗方面效率低下[3]。这种 低效性在云计算范式中也存在，但由于工作负载更具可变性且部署数量更多，因此在边缘计算中更为 严重。

尽管文献中已提出了大量能效算法，但我们认为这些算法都是以“盲目”的方式运行的，即它们 并未考虑到应用程序在业务流程中可能扮演的不同角色。事实上，大多数应用程序可能大部分时间都 处于活跃和工作状态，但其他一些应用程序可能仅作为备份副本用于冗余或扩展目的。在某些情况下 （例如公用事业计费），某些业务流程每月仅密集运行几天，其余时间则完全处于空闲状态。当每个 应用程序部署在独立虚拟机中时（如今这种情况十分常见），如果有明确的使用模式信息可供参考， 整合算法在效率和服务质量方面都将得到显著提升。

我们工作的主要创新在于探索这一机会。粗略地说，我们认为用户可以将未使用的虚拟机置于特 殊状态（类似于通过合上笔记本电脑的盖子来使其进入休眠），并且该信息可用于选择性地对仅托管 未使用虚拟机的服务器应用更激进的节能机制。从更抽象的角度来看，这意味着在整合过程中引入了 更多的“上下文”信息。尽管虚拟机状态的频繁和及时变更对人工操作而言可能较为繁琐，但软件编 排工具（例如OpenBaton[4]）的出现使得这些操作能够轻松地与其他重要的生命周期管理操作（如 扩展、备份、弹性）实现自动化。

在最近的一篇论文[5],中，我们已经探讨了边缘计算中高效虚拟化框架的设计，旨在平衡服务质 量（QoS）与能效（EE）。我们提出了一组针对OpenStack（一种知名的云管理软件）的功能和语 义扩展，以实现对服务质量与能效的更好管理。我们之前的工作仅提供了有限的实验验证，特别是在 能效方面。事实上，仅在网络重新配置（转发路径变化）期间测量了丢包率和抖动，并收集了服务器 和交换机的功耗特征。在本文中，我们在该实验基础设施的基础上，分析其有效性（即节能效果）和 效率（即每瓦特有效工作量），这些方面无法通过仿真进行真实评估。我们进一步深入研究了部署策 略与功耗之间的关系；同时表明，即使采用非常简单的整合策略，利用上下文信息也能取得优于现有 实践的效果。最后，我们证明了我们的方法在使用率与功耗之间实现了更好的线性关系。

本文组织如下。我们在第2节中回顾相关工作。在第3节中，我们进一步阐述了本研究的主要动机， 以及服务编排与工作负载整合之间的关系。在第4节中，我们描述了节能型基础设施的实现，该基础设 施为服务质量（QoS）和电源管理提供支持。在第5节中，我们报告了测试平台的评估和数值分析结果。
最后，在第6节中给出结论。

相关工作

云基础设施的能效意味着在实际计算中使用最少的能源。这在很大程度上取决于功耗与性能之间 更理想的线性关系[6],，通常通过利用现有的节能机制来实现：性能调节（例如，CPU电压/频率的 动态调节）、低功耗空闲，以及最重要的消除空闲时段。事实上，运行空闲服务器会浪费大量能源来 维持系统的运行，而未执行任何有用的工作。基于这一前提，将虚拟机运行在最少数量的服务器上， 同时关闭或使所有未使用的设备进入睡眠状态，通常是节能最有效的解决方案。将虚拟机集中在一起 并选择活动服务器的过程通常被称为工作负载“整合”。

与我们的研究目的类似，白柳等人[7]考虑了备份副本和链路的存在，并通过仿真研究了它们数 量变化时功耗的改变情况。然而，他们的研究重点仅在于网络本身的功耗。李等人[8]研究了过度供 给（例如应对工作负载的突发峰值）对功耗的影响。他们提出的工作负载整合策略仅考虑了服务器， 而未考虑任何网络指标。在此情况下，他们基于名为iVIC的虚拟化基础设施进行了实际实现。布亚等 人[9],再次通过仿真对工作负载整合情况下服务级别协议的违规情况进行了评估。

尽管文献中提出了大量算法，但工作负载整合在真实测试平台中的可行性、有效性和效率尚未得 到充分研究。赫勒等人[10]分析了冗余和保护裕度如何影响功耗；他们的工作以最小化数据中心网络 的功耗为目标将虚拟机放置在服务器上，但未考虑计算服务器所消耗的能量。由于整合算法的基础是 能够在服务器之间迁移虚拟机，沃斯鲁伊斯等人[11]研究了实时迁移对应用响应时间的影响。

最近，贝洛格拉佐夫等人[12]提出了OpenStackNeat，用于平衡服务质量与能耗。他们的框 架通过监控虚拟机的CPU利用率，估算每台服务器上的过载/欠载状态，并利用OpenStack应用程序 编程接口（API）实现服务器之间的虚拟机实时迁移。他们的整合策略是不感知功耗的，因为仅使用 了利用率指标。尽管节能可以通过将空闲服务器置入睡眠状态来实现，但他们的硬件不支持该状态， 因此他们仅对节能进行了估算。与我们的方法相比，Neat未包含功耗监控框架、软件定义网络以及针 对应用程序的具体上下文信息。罗西涅乌等人[13]实现了Kwapi，这是一种OpenStack扩展，用 于从服务器收集实时功耗测量数据。我们在实现[14],中使用了该框架，并进一步扩展以同时收集网 络设备的功耗数据。奇马等人[15]也在其实现的用于能效的OpenStack扩展中使用了Kwapi。这项 工作与我们的目标非常相似：构建一个具备增强型API以进行电源管理的高能效云基础设施。该API 包含用于更改服务器电源状态（睡眠/活动）的特定命令。作者测量了实时迁移的迁移时间和服务停机 时间，并采用类似于Neat的不感知功耗的整合策略评估了节能效果。我们的研究采用了类似的方法， 但additionally包含了用于带宽预留的软件定义网络，以及虚拟机的上下文信息，从而实现了更好的 服务质量管理和更激进的整合策略。

一种节能计算范式

随着云服务的兴起，预计未来几年数据中心的使用率仍将继续增长。数据中心已经占据了整体能 耗的相当大份额（约2%）[16],因此节能已成为高层管理的首要任务之一。

引入更高效的硬件、节能机制以及节能型基础设施设计已显著降低了此前对能耗的预测，但持续 增长的趋势仍促使人们付出更多努力。事实上，有关数据中心可持续性的最新报告显示，大型设施已 接近理想的有效性水平，而小型设施（如预期用于边缘计算的设施）仍有很大的改进空间[16,17], 。

特别是，真正的挑战在于每次有用计算工作所消耗的功率。在这方面，我们认为，在服务与虚拟 化基础设施之间共享更多上下文信息是一种必要的演进，能够比当前更显著地提升效率，有效平衡性 能、服务质量与功耗。

效率与有效性

数据中心能效的普遍优化目标通常是电源使用效率（PUE），其定义为设施总能耗（包括冷却、 照明、电力分配损耗）与IT设备能耗之比。然而，这一参数的实际意义仍存在争议，因为它未考虑 IT设备的效率[18,19]。例如，在服务器利用率较低的情况下，维持整个基础设施运行所消耗的功率与 实际计算服务不成比例。工作负载整合明确追求计算使用效率，旨在实现功耗与基础设施使用率之间 更接近线性关系。

大多数整合算法的共同弱点是仅考虑静态指标（即中央处理器、内存、带宽需求），而忽略了资 源的当前利用率。低利用率最可能发生在可变工作负载的情况下；这在计费应用、视频流以及其他许 多使用较为可预测的周期性模式的服务中是一种典型情况。正如我们之前讨论的，这类应用程序通常 按峰值负载进行配置，以避免因技术和管理上的配置流程引起的服务中断和延迟。

解决功耗与数据中心有效生产力之间的线性关系问题，一些近期的提议将CPU利用率作为整合的 主要指标[12,15]。该方法能够实现更高的效率，但需要一定时间来检测过载情况，从而可能导致服务 级别协议（SLA）的违反。事实上，我们认为用户应当了解任何潜在的性能违规情况，并应因其愿意 参与更激进的节能机制而获得奖励（例如，通过动态且上下文感知的定价方案[20]）。

边缘应用程序的更多上下文

我们的能效方案源于基于云的应用程序的新型软件开发和编排范式，例如TOSCA[21] 和 ETSIMANO[22]。这些范式将复杂应用程序构建成基本组件（服务图中的节点或虚拟功能）的逻 辑拓扑，并将其部署在独立的虚拟机或容器中。这些模型广泛使用元数据和注释来驱动（半）自动化 编排过程；我们的思路是引入有关服务质量（QoS）和能效的特定上下文信息，以用于设计高级整合 策略[14]。

具体而言，我们考虑每个虚拟机的以下类型的上下文信息：

•服务级别，与服务的关键性以及预期的服务质量（CPU负载、网络带宽）相关；
•可用性，表示该组件在下一个时间段内是否会被使用。

我们通过与每个虚拟机相关联的彩色标签来建模上述信息：

•红色，适用于那些对处理、内存、可用性和带宽要求有严格承诺的虚拟机；
•黄色，适用于那些未接近其性能极限运行的虚拟机，因此在QoS约束方面具有一定灵活性；
•绿色，用于未使用（空闲）的虚拟机

红色标签分配给承载最关键软件且具有严格QoS约束的虚拟机。作为更高费用的补偿，用户期望 在此情况下不发生超量分配和实时迁移。例如，始终假设为完全CPU使用，而网络带宽则根据声明的 最大吞吐量进行预留。黄色标签分配给标准虚拟机，允许进行超量分配。在这种情况下，CPU使用率 可假定等于声明的平均负载，而网络预留可使用平均或等效带宽值。最后，绿色标签分配给空闲和未 使用的虚拟机。这些虚拟机可以承受极端的超量分配和激进的节能机制，前提是它们能在极低延迟内 恢复可用（即，低于几秒）。

除了标签外，我们还将最大/平均CPU利用率和网络吞吐量需求作为元数据包含在服务图中。这 种分类可以轻松扩展到更多类别，并为服务质量提供更丰富的语义。

节能型基础设施

我们的节能型基础设施在以往具有相似目标的研究基础上进行了构建和扩展[12,13,15]。目标是设 计一个对任何特定编排模型和整合算法均保持无关性的框架。在这方面，该框架旨在通过实现对网络 流量和电源管理的更好控制，从而扩展现有的管理软件。图1展示了我们节能型基础设施的架构，其 包括：

•计算硬件和虚拟机监控程序，具有节能机制；
•云管理软件（CMS），该软件实现了基础设施即服务（IaaS）型号；
•软件定义网络（SDN），可完全编程以根据带宽请求优化网络路径；网络设备中也提供节能机制；
•监控，用于从所有服务器和网络设备收集功耗和CPU利用率的测量数据；
•管理接口，允许与基础设施进行使用和管理方面的交互。

我们的节能型基础设施实现了基础设施即服务型号，并提供两种接口：北向和东向。

北向接口旨在部署和运行应用程序。它包含用于创建、销毁和管理云资源的所有应用程序编程接 口；此外，我们设想增加额外的语义以指定第3.2节中讨论的上下文信息。尽管这些应用程序编程接口 可由人工使用，但我们期望通过编排工具实现应用程序生命周期的自动化。

东向接口提供对控制和管理功能的访问。除了云管理软件中的典型管理操作（例如，用户管理、 提供商网络、虚拟机监控程序管理、虚拟机迁移）外，我们还包含电源管理和软件定义网络功能。如 图1所示，该接口通常由整合算法使用。我们在先前的工作中描述了一个利用上下文信息的新型算法示 例[14]。

计算服务器

计算服务器支持ACPI电源状态，以及可选的其他节能机制（动态电压/频率调节、低功耗空闲）。
目前我们仅使用ACPIS3状态（也称为“待机”、“睡眠”或“挂起到内存”）。这是最有用的电源 状态之一，因为它几乎切断了所有电源，同时可在几百毫秒内恢复完全运行。我们计划在未来的更新 中增加对其他节能机制的更多控制。关于这些状态的远程控制，DTMF通用信息模型中已提供[23]并 映射到IPMI[24],但大多数商用设备并不支持该功能。由于缺乏对特定接口的广泛支持，当前使用自 定义API将电源状态从ACPIS0切换至S3（即将设备置于睡眠状态），而使用网络唤醒将其从ACPI S3恢复至ACPIS0（恢复完全运行）。

我们的安装使用了QEMU/KVM虚拟机监控程序，这是OpenStack的默认选择（见下文）。

云管理软件

我们使用开源的OpenStack框架作为云管理软件。我们的安装包括认证（Keystone）、计算 （Nova）、网络（Neutron）、镜像（Glance）、存储（Cinder）和遥测（Ceilometer）模块。

虚拟网络采用NeutronML2插件，并结合基于软件的openvswitch交换机。租户网络使用VLAN封 装，因为这是物理交换机中由OpenFlow管理的唯一隧道协议。网络节点部署在专用机器上。所有计 算节点均连接共享文件系统，从而实现虚拟机监控程序之间的虚拟机实时迁移。

软件定义网络

软件定义网络由运行openvswitch的OpenFlow软件交换机构成。我们倾向于在商用台式机上运 行的软件交换机，而非商用硬件，因为后者不支持ACPI电源状态，无法用于功耗的实时测试。除了 OpenFlow之外，网络设备还提供了GAL接口（绿色抽象层[25]），这是一种最近提出的标准，用于 报告和修改能耗相关特性（电源状态、功耗/性能关系等）。GAL用于收集每个设备的功耗配置文件 （例如，描述能耗如何随不同情况变化的特征）

利用率水平），并将其电源状态从工作状态(ACPIS0)更改为睡眠状态(ACPIS3)。设备通过 Wake‐on‐Lan协议从ACPIS3恢复到S0，重新进入完全运行状态。

使用OpenDayLight作为网络控制器。我们利用l2switch功能提供所有节点之间的完全连接，同 时在具有带宽要求的虚拟机之间配置显式流。该方法将OpenFlow规则的数量限制为具有QoS需求的 特定流（这些流将映射到高优先级流量类别），而对于辅助流量（例如DNS查询和DHCP）则回退到 尽力而为的泛洪行为。

l2switch使用受控泛洪来转发数据包，因此会产生大量的网络流量，但对故障具有极强的弹性， 并且在虚拟机迁移时不需要重新配置。相反，路径的显式配置能够实现基础设施的更好和更高效的利 用，但在发生迁移或故障时需要重新配置，可能导致性能下降和服务中断。这些方面在我们的性能评 估中被明确考虑（参见第5.2节）。

物理交换机中QoS参数（优先级队列、流量整形器、调度机制）的配置尚未实现，但已在开发路 线图中。

监控框架

监控组件的主要目标是通过从不同计量设备获取数据，使用不同的通信协议和数据格式，来收集 来自异构设备的测量数据。为此，我们使用Kwapi[13],一个用于监控功耗并将数据发布到 OpenStackCeilometer的模块化框架。我们扩展了Kwapi以收集虚拟机监控程序的CPU使用率数据， 从而可以构建每个设备的功耗配置文件，即功耗与性能之间的关系[26]。

Kwapi包含驱动程序，可通过SNMP查询商品化功率计、串口/USB瓦特计以及许多近期计算板卡 上可用的IPMI接口；这涵盖了边缘站点中可能部署的大多数硬件，包括带有单主板的传统服务器以及 刀片服务器。

北向和东向接口

北向接口是OpenStackAPI。我们使用更丰富的语义，使用户能够指定上下文信息。这些信息不 会被OpenStack直接使用，因为OpenStack不包含任何特定逻辑，但会通过东向接口暴露给外部管 理软件（例如QoS/整合算法）。

我们的实现利用标准OpenStack接口，基于第3.2节中描述的型号来共享上下文。该抽象模型的 具体实现包含以下信息：

•活动/暂停状态。根据OpenStack文档，虚拟机可以处于不同的稳定状态，大致对应于ACPI电源状 态。我们期望用户使用暂停状态来标识当前未使用的虚拟机（绿色标签，即用于横向扩展或备份的备 用组件），从而隐式请求（临时）低服务级别；
•带宽要求。这些是与每个虚拟机相关联并存储在元数据服务器中的属性，形式为 〈键、值〉，用于扩 展OpenStackAPI中已有的QoS约束（目前OpenStack中的QoS支持非常有限，仅涵盖虚拟机监控 程序中的少数配置，而在物理网络中没有任何支持）；
•服务级别。这也由元数据服务器中的一个属性编码，代表可接受的过度分配程度（黄色/红色标签）。

使用虚拟电源状态（活动/暂停）能更好地将green类与其含义相匹配，有助于检测状态转换，并 允许底层硬件的电源状态实现更平滑的转换。

TheEast接口1是一组用于利用此类基础设施独特功能的控制和管理应用程序编程接口。从图右侧 自上而下，我们看到云API、电源管理接口和网络API。

云API是标准的OpenStack接口，用于管理员模式下获取虚拟化系统的信息（正在运行的虚拟机、 状态、租户网络、VLANID等），并触发虚拟机迁移。它还用于在将虚拟机管理程序置于睡眠状态之 前将其从OpenStack控制器分离，以避免出现不可达错误。

电源管理接口用于：

•检索当前功耗信息；
•通过将服务器和网络设备的功耗与不同的负载条件（中央处理器使用率）相关联来构建功耗特征；
•更改服务器和网络设备的电源状态。

前两个操作依赖于第4.4节中描述的监控框架，而最后一个操作使用网络设备的GAL、计算节点的 自定义接口以及所有设备的Wake‐on‐Lan协议（见第4.1节和第4.3节）。

最后，网络API允许以编程方式配置通信基础设施。我们使用作为OpenDayLight功能提供的 RESTCONF[27],，它通过Yang模型提供高级网络抽象。该接口可根据管理算法计算出的具体策略， 在底层数据路径中设置流。

评估与数值结果

实验设置

我们部署了一个如图2所示的工作测试平台。这是一个小型测试平台，但它具有边缘部署的典型特征， 因为边缘部署的规模并不需要与现代数据中心相同。该测试平台由表1中列出的硬件和虚拟组件组成。

Role	ID	Type	CPU	RAM	Disk	Net
型号			速度核心数
操作系统计算节点	C1	Phy酷睿i7‐6770HQ	2.66GHz 4	32GB	256GB	1 × 1GB
	C2	Phy酷睿i7‐6770HQ	2.66GHz 4	32GB	256GB	1 × 1GB
	C3	Phy酷睿i7‐6770HQ	2.66GHz 4	32GB	256GB	1 × 1GB
操作系统网络节点	NN	VM kvm64	2.30GHz 2	4 GB	32GB	1 × 1GB
操作系统存储节点	SN	Phy酷睿i5‐750	2.67GHz 4	2 GB	750GB	1 × 1GB
网络交换机	S1	Phy凌动N550	1.5GHz 2	2 GB	500GB	4 × 1GB
	S2	Phy凌动N550	1.5GHz 2	2 GB	500GB	2 × 1 GB+ 2 × 100 Mb
	S3	Phy AtomD510	1.66GHz 2	1 GB	120GB	2 × 1GB
	S4	Phy Atom230	1.6GHz 1	4 GB	160GB	2 × 100兆字节

安装的软件为OpenStack的Newton版本和OpenDayLight的Carbon版本。我们使用了bash脚 本和简单的Java程序来触发我们的应用程序编程接口和QoS参数。

根据文献中的类似研究，我们为测试平台选择了低端硬件。事实上，我们的工作采用了创新技术 （节能机制和协议、软件定义网络），而这些技术目前尚未在用于云部署的商用设备中广泛同时提供。

性能

应用节能机制预计会影响应用程序所感知的服务质量（QoS），但在通过仿真评估整合算法时， 这一方面常常被忽视。实际上，虚拟机迁移会中断服务，还需要更改网络配置以重新路由数据包。作 为首个结果，我们扩展了此前工作中已报告的测量数据[5]。

转发路径

我们框架的一个显著特点是与SDN协议（即OpenFlow）的集成，这使得通过配置虚拟机之间的 转发路径（“显式路径”）来实现最佳带宽使用成为可能。当虚拟机迁移到不同的服务器时，底层的 转发路径必须更新，而这可能导致丢包、抖动变化以及连接中断。为了理解网络重新配置可能造成的 影响，我们从C2上的虚拟机向C1上的虚拟机生成了一条UDP流量流。该流量流使用iperf（ https://iperf.fr/）生成，iperf是一个广泛使用的开源工具，用于测试TCP、UDP和SCTP；使用 UDP数据包可以测量性能，而不会受到任何拥塞避免和错误恢复过程的干扰。

我们选择在不迁移虚拟机的情况下更改网络路径的配置，以便仅捕捉由OpenFlow操作带来的影 响。路径从序列〈C1、S1、S3、S2、C2〉更改为 〈C1、S1、S4、S2、C2〉。作为对比，我们还考虑了 OpenDayLight中l2switch功能的原始行为（“纯泛洪”），该功能在我们的框架中用于实现所有节 点之间的完全连接。

图3a显示在低比特率（低于1Mbps）下没有丢包。对于中等速率（10–30Mbps），l 2switch泛洪表现更好，因为无需重新配置。然而，在更高速率下，对于已配置路径的情况，丢包数 量保持相对稳定，而泛洪的丢包数量则迅速上升。这是因为路径重新配置期间会短暂发生丢包，该时 间与流速率无关且固定不变，而泛洪会导致广泛的网络拥塞（见图3b）。

实时迁移

实时迁移是任何整合算法的关键特性，因为它能够在不同服务器之间迁移虚拟机，同时将服务中 断降至最低。然而，关键应用程序可能对服务不连续性较为敏感，因此评估此延迟非常重要。

为了评估实时迁移的影响，我们测量了发生此类事件时执行时间的增加情况。我们考虑了一种转码应 用，该应用具有确定性行为并产生高计算负载。表2列出了转码应用的主要参数。

参数	原始值	最终值
视频长度	约22分52秒	Same
转码工具	ffmpeg3.4.1	N/A
视频流	h264（原生）	mpeg4（原生）
音频流	aac（原生）	mp3（libmp3lame）
容器格式	mp4	avi
转码时间（无迁移）	N/A	约4分6秒

在我们的实验设置中，迁移过程由KVM/QEMU虚拟机管理程序控制。可以在OpenStack配置 文件中设置多个参数来调整此过程；我们发现对性能影响最关键的参数是“实时迁移停机时间”。根 据文档说明，实时迁移会在不停止实例的情况下，将实例的内存从源虚拟机监控程序复制到目标虚拟 机管理程序。该过程以迭代方式进行，反复复制在此期间被实例写入的页面（标记为dirty页面）。为 了避免无限循环，系统会定期短暂暂停实例，以便在没有内存写入干扰的情况下复制剩余的少量页面。

该间隔与前述参数成正比；如果在该间隔内无法完成内存复制，则恢复实例运行，并重新开始该过程。
该过程在连续迭代中线性增加停机时间间隔，直到达到允许的最大值（即实时迁移停机时间参数）； 如果仍无法完成内存的干净复制，则迁移失败。

丢包率；(b)带宽使用)

通过分析视频转码的总处理时间和迁移时间（见图4），上述印象得到了部分证实。在使用两个 较大的停机时间值时，我们测得服务处理时间的增加较小（几乎可以忽略不计）。同时，我们还看到 使用较长的停机时间值时，总迁移时间显著减少。根据此次评估，我们得出结论：设置较长的实时迁 移停机时间值通常对服务性能和迁移性能都有利，因此在后续所有试验中，我们将这些参数固定为 2000毫秒。

可用性

每种节能机制都会带来能力的降低（例如，降低频率、关闭组件），因此在恢复完全运行之前需 要耗费一定时间。在我们的情况下，暂停的虚拟机可能托管在处于睡眠状态的服务器上。使其恢复到 可用状态所需的时间包括数百毫秒的硬件唤醒时间，以及操作系统执行恢复操作所需的额外时间；总 计达到数秒。

上述值比从头开始配置虚拟机要小几个数量级。此外，我们方法背后的主要理念是用户自愿将其 虚拟机置于暂停状态，因此他们清楚重新激活所需的时间。基于这些考虑，我们认为在此阶段无需进 行更精确的测量数据。

能效：性能与功耗

鉴于能效与服务质量的相互对立目标，很自然地会思考它们在我们的范式中是如何实现均衡的。
事实上，这两个方面通常被单独研究，而它们之间的关联并未得到深入探讨。为此，我们分析了整合 如何影响整体效率（即性能与功耗的比值）。假设有六台虚拟机，并选择三种不同的部署策略。每种 部署策略对应不同程度的整合（使用较多或较少的服务器），分别为较保守的整合和激进整合。每种 策略下虚拟机的部署情况如表3所示。在此情况下，我们在静态条件下对整合进行评估，即每次实验 过程中虚拟机的部署保持不变。

策略	计算节点1	计算节点2	计算节点3
1.最大节能	所有虚拟机（VM1–6）	–	–
2.均衡	3个虚拟机（VM1、3、5）	3台虚拟机（VM2、4、6）	–
3.最大性能	2台虚拟机（VM1、4）	2台虚拟机（VM2、5）	2台虚拟机（VM3、6）

我们使用真实数据评估了每种策略下的功耗和性能变化。我们使用stress‐ng工具（ http://kernel.ubuntu.com/~cking/stress-ng/）逐步增加每个虚拟机的CPU负载。我们将100%视为 一台虚拟机的完全利用，因此六台虚拟机的总负载等于600%；增量步长固定为25%。我们按数字顺 序依次增加每个虚拟机的负载，即首先增加虚拟机1的负载，当其达到满载（100%）时，再开始增加 虚拟机2的负载，依此类推，直到最后一台虚拟机（VM6）完全负载。

可以看出，策略1与策略2之间的功耗差距较大（约 增加40%），而策略2与策略3之间的差异较小（图5a）。如果考虑网络拓扑结构（图2），这一点显 而易见：将虚拟机部署在计算节点2上时，需要唤醒两个额外的交换机（S2和S3），而策略1无需这样 做；但从策略2切换到策略3时，无需额外的网络设备。

策略1实现了更大的节能效果，但我们必须同时考虑性能以实现公平比较。为此，我们参考了 stress‐ng指标在满载实验中报告的每秒操作数（即所有虚拟机在100%CPU下运行）。尽管该指标 并非可靠的性能衡量标准，也未设计用于科学精确的基准测试，但足以对不同配置之间的性能进行粗 略的概念性比较。我们注意到，在同一虚拟机监控程序上并发运行一台、两台或三台虚拟机时，性能 几乎保持不变，但在运行六台虚拟机时性能显著下降（图5b）。这并不令人意外，因为计算节点上的 每个处理器具有四个核心并支持超线程；尽管操作系统将其识别为八个虚拟CPU，但超线程并不等同 于拥有额外的真实核心。

为了更好地进行评估，我们在图6中比较了不同策略下三个相关指标的变化情况，并任意将策略 1作为基准参考（100%）：性能、功耗和整体效率。我们采用每秒总操作数作为性能指标，整个基础 设施的功耗作为功耗指标，操作数与功耗之比作为效率指标。我们考虑虚拟机CPU利用率的三个级别： 100%（满载）、75%（高负载）和50%（中等负载）。

图6显示，对于满载利用率，策略2和策略3具有几乎相同的性能（+28%，相对于策略1），但功 耗特征不同（+35%和+44%的增加）。策略1无疑是效率最高的方案（+5%，比其他策略高出+11 %），尽管这以性能下降为代价。可以说策略2优于策略3，因为在相同性能水平下，策略2具有更高 的效率和更低的功耗。相反，策略1与策略2之间的比较并不直接，因为它取决于整体优化目标（可能 偏向性能或节能）。通常情况下，更推荐策略1，因为节能效果大于性能损失，因此相较于其他场景， 其效率更高。

当虚拟机需要的CPU时间较少（即利用率水平较低）时，超量分配的空间更大。事实上，在75% CPU负载下性能提升仅限于15%，而在50%CPU负载下性能提升可忽略不计。由于在所有CPU负载 下的功耗增加相当，这导致从策略1到策略3的效率损失更大。

我们得出结论：当虚拟机未达到100%负载时，更激进的整合（策略1）是最优选择。相反，当虚 拟机完全负载时，较保守的整合能带来更大的性能增益，尽管这会带来轻微的效率损失。总体而言， 较保守的整合更适合对延迟敏感和关键任务应用，因为在这些场景中性能应优先于能效。在设计整合 算法时应考虑这一观察结果；我们整合策略中使用的标签方案能够轻松应对不同的需求，从而支持针 对不同类别的应用程序定制最优整合计划。

整合与节能

我们工作的最后部分致力于通过一个示例应用进行节能评估。目的是比较三种情况：无工作负载 整合、无上下文信息的工作负载整合、以及带上下文信息的工作负载整合。为此，我们开发了一个非 常简单的弹性服务，该服务由一个控制主节点和多个从节点组成，用于负载均衡。弹性应用能够应对 可变工作负载，因为它们会根据当前计算需求进行扩展。在我们的框架中，主节点将处理任务分配给 从节点，我们称之为“调度器”；从节点并行执行计算任务，被称为“工作节点”。该应用是一个视 频转码服务，根据需要使用多个工作节点并行转码多个视频文件，每个工作节点处理一个视频文件。

由于主要目的是节能评估，因此我们未考虑视频排队等更复杂的操作。

我们为调度器分配了一个虚拟机，为工作节点分配了九个虚拟机（工作节点1、工作节点2、…、 工作节点9）；调度器被视为关键服务（“红色”标签），而工作节点则根据当前工作负载暂停或恢 复运行。每个虚拟机具有1个虚拟CPU和2GB内存。为简化起见，我们不进行资源超配，即每台服务 器上虚拟机的最大数量限制为4个（因为每台服务器有四个物理核心）。

我们还开发了一种非常简单的能源管理与整合策略，该策略利用东向接口。它会定期检查虚拟机的状 态（活动与暂停），并通过将虚拟机集群整合到最少数量的服务器上来执行整合，从而最小化总功耗 计算服务器和网络交换机的能耗。此外，它将空闲服务器置于睡眠状态，并在收到“恢复”请求时将 其唤醒。整合的放置策略是一种非常简单的启发式方法，不值得详细讨论。无论上下文信息是否可用，都 应用相同的算法。在后一种情况下，显然在放置决策中不会考虑状态，且只有未托管任何虚拟机的服 务器才能进入睡眠状态。为了在两种情况下进行更公平的比较，我们有意未使用先进且复杂的算法进 行评估。

我们生成了一个九个任务的序列，每个任务的处理时间相同（约21分钟），每90秒生成一个任务。
这导致了钟形利用率曲线。图7a显示了三种不同场景下的实测功耗：（i）无整合；（ii）采用不考虑 上下文信息的整合过程；（iii）采用利用上下文信息的整合方案。

利用率的变化体现在功耗上，当存在更多任务时，功耗会增加（见图7a）。在无上下文信息的情 况下，整合过程将所有虚拟机视为同等重要，而不管其实际利用率和角色如何。这基本上阻止了服务 器进入睡眠状态（因为虚拟机数量相对于服务器数量较多，且不存在超量分配）；只能使一个冗余交 换机进入睡眠状态。相反，当我们的简单编排策略将未使用虚拟机的状态更改为“暂停”时，整合算法会将其分离，从而使部分服务器和交换机可以进入睡眠状态，因此在工作负载较低时能够降低能耗。

图7b显示了两种整合策略相对于无整合场景的节能情况。我们注意到，在两种情况下，随着处 理负载的增加，节能效果都会下降，这符合预期。

图8显示，利用上下文信息，我们可以在服务器利用率和功耗之间实现更好的线性关系。事实上， 在对应低利用率的低功耗情况下，这种线性关系更加明显。与其它场景相比，整体曲线呈现出更明显 的阶梯状，这可归因于测试平台中设备数量较少。当使用更多设备并结合动态电压/频率调节机制时， 阶梯状行为将变得微不足道。

结论

近年来，人们投入了大量精力来设计整合策略，以最大程度地提高节能机制的有效性。这些方法 并未考虑实际上下文，即虚拟资源是否真正被使用，还是仅为其他目的（包括服务迁移、可用性与弹 性）而配置的。编排范式可有效用于在适当的基础设施参数中反映每个虚拟资源的当前角色；例如， 我们插入了元数据，并以类似于物理硬件的方式应用了虚拟电源状态。这使得整合策略更具感知能力， 并为选择性地应用激进的节能机制提供了更好的机会。

通过编排，用户只需承担响应速度和可用性方面轻微的惩罚，而合适的定价方案可以轻松促进他 们参与此类机制的意愿。这正是整体方法的主要优势所在，能够在边缘计算中有效平衡功耗与服务质 量。