不要忽视闲置功率: Kepler的公有云能耗利用率指标

这篇博客文章旨在强调在公共云等多租户环境中闲置功率的影响及其在软件能源归属和核算方面的透明度需求和影响。

作者：Sunyanan Choochotkaew, Marcelo Amaral, Huamin Chen

相较于负载直接产生的功率，空闲功率，通常包括开机功率和控制（管理）平面进程消耗的功率。在多个租户共享计算的公共云环境中，空闲功率的划分和归因是一项具有挑战性的工作。由于在最大利用率下空闲功率占节点总功率的比例可以达到 20%到 60%。这篇博客文章旨在强调透明、细粒度的能源指标的重要性，这些指标区分了公共云计算中软件能源归属中的闲置功率和动态（负载）功率。Kepler^[1]通过区分闲置功率和动态（负载）功率的做法和解决方案，在多个租户共享的公有云环境下实现了透明，细粒度能源指标，完成了这项挑战。

量化软件可持续性指标

根据国际能源署（International Energy Agency (IEA)^[2]）在数据中心和数据网络传输（Data Centres and Data Transmission Networks segment^[3]）中的内容，据估计，2022 年全球数据中心用电量约为全球最终电力需求的 1-1.3%，过去几年的年增长率为 20-40%。EU Energy Efficiency Directive (EED)^[4]将要求装机容量大于 500 千瓦的欧盟数据中心从 2024 年 5 月起报告其总能耗。

绿色软件基金会（Green Software Foundation (GSF)^[5]）是一个是在 Linux 基金会下成立的一个非营利组织，尝试打造一个值得信赖的绿色软件建设生态系统。它为软件系统定义了一个计算碳排放率的新标准 SCISoftware Carbon Intensity (SCI)^[6]。这个规范已经在 2024 年 1 季度纳入ISO standard status^[7]这标志着绿色软件建设之旅中的一个重要里程碑。

Software Carbon Intensity 计算基于一下公式：

SCI = ((E * I) + M) per R

名词解释（给出英文原文供参考）：

• E – 软件所消耗的能源/Energy consumed by a software system
• I - 区域特定碳强度/region-specific carbon Intensity
• M – 操作系硬件系统的具体碳排放/embodied eMissions of the hardware needed to operate a software system
• R – 功能单元，参考对比的基础单元/functional unit, a Reference unit for comparison.

该标准允许使用细粒度数据。这种类型的数据可以包括数据中心、单个机器（例如，VM/节点）、单个服务（例如，API 调用或 ML 训练运行）、执行包（例如，pod 或容器）或单个进程的信息。

能耗表示一段时间内的累计用电量。关于虚拟机多租户环境的功率计算，Greenhouse Gas Protocol (GHG)^[8]提供了以下具体指南：

P(vm) = U(vm) ⋅ Size(vm) ⋅ P(dyn) + P(base)/n

这个公式参考了ICT Sector Guidance built on the GHG Protocol Product Life Cycle Accounting and Reporting Standard^[9]`6-34 页的内容。

名词解释（给出英文原文供参考）：

• P(vm) - VM 的用电量/power consumption of the VM
• U(vm) - VM 的利用率/utilization of the VM
• Size(vm) - VM 的大小/size of the VM
• P(dyn) - 设备的动态能耗/dynamic power range of the device
• P(base) - 系统的空闲/基础/开机能耗/Idle, or base, power consumption is when the VMM is operating but no VMs are executed on the system
• n - VM 的数量/the number of VMs running on the server

为了实现更环保的软件，我们需要在应用程序的设计、开发和交付过程中降低功耗和 SCI（Software Carbon Intensity）分数。

空闲功率：隐藏在公有云下的能耗

在 2019 年，RightScale's survey^[10]的调研中显示，在 800 家组织中，超过 94%的组织已经采用了云计算，31%的组织优先考虑公共云，54%的组织计划在 12 个月内将其工作负载迁移到公共云，以提高资源效率。Accenture's report in 2020^[11]强调公共云迁移可以大幅减少碳排放（高达 84%）和能源消耗（高达 64%）。

公共云作为多租户环境运行，用户在其中购买在众多用户之间共享的计算资源。各种工具，如CodeCarbon^[12]，CarbonTracker^[13]，Scapphandre^[14]，和Kepler^[15]，可用于估计与代码执行包装或实时资源利用率观察相关联的能源消耗和碳排放。

然而，确定如何将功耗归因于基础设施服务仍然具有挑战性。GSF 的 SCI 标准规定，能源消耗应包括保留或供应的硬件消耗的所有能源，而不仅仅是应用程序运行时使用的硬件。这包括空闲功率，不仅包括静态功率，还包括应用程序运行所需的功能项目（如 kubelet 或控制平面）所消耗的能量。

根据SPECpower 基准^[16]，活动空闲功耗可以变化很大，在最大利用率下功耗的 20%到 60%之间。从绝对值来看，这从 100 瓦到 1300 瓦不等，相当于一个家庭中经典灯泡或空调的功耗（尽管碳排放存在差异）。当考虑 GPU 功耗时，空闲功率可能甚至更高。

空闲功率审计和透明度的重要性

空闲功率和动态功率之间的区别在研究文献中得到了广泛的研究1^[17]. 大多数当前用于测量应用程序功耗的工具往往忽略了这一区别。将空闲功率与动态功率隔离是至关重要的，原因包括将功耗公平地归因于应用程序，并帮助创建更准确的功率模型。

动态能源消耗与资源使用直接相关。另一方面，空闲功率是与资源利用率无关的基本功耗。使用资源利用率来估计功耗的功率模型将仅准确地反映动态功率。空闲功率是一种恒定的功耗，必须归因于所有正在运行的应用程序。

为了说明公平分配闲置能源的想法，可以想象一种共管公寓，业主无论是否使用自己的房屋，都要向房主协会（HOA）支付费用。公寓中较大的家庭可能会支付更高的费用，就像分配了更多资源的虚拟机或具有更多进程的应用程序应该承担更大比例的闲置电力使用一样。

Kepler 通过对闲置和动态能源的仔细跟踪，促进了电力使用的更公平分配，并完善了电力消耗模型。在 Kepler 中，空闲功率和动态功率消耗的总和被称为绝对功率消耗。

为了进一步说明闲置电力归属中透明度的重要性，请参阅以下示例按资源请求参考OpenCost 规范^[18]其中工作负载成本是通过“最大（请求，使用）”来计算的。

假设我们有一个 16 核服务器 X 的线性功率模型的服务器，由一个简单的公式描述，如下所示，其中 Idle=200，Coeff=8：

Power Consumption (P) = Idle Power (Idle) + Dynamic Power Consuming Factor (Coeff) _ Resource Utilization (x)

能耗 (P) = 空闲功率 (Idle) + 负载功率因子(Coeff) _ 资源利用率(x)

让我们来分析一下上图所示的估计能耗。我们将考虑一个服务器托管两个客户端或应用程序，它们请求相同数量的资源，但在各种场景中使用它们的方式不同。我们还将检查一个只有一个客户端的场景进行比较。

• 情况 1: 两个客户请求并使用了相同数量的资源

在第一种情况下，客户端 A 和客户端 B 都使用节点 CPU 的 10%（因此每个客户端使用总利用率的 50%），节点的总功耗为 360W。由于两个客户端使用和请求的资源量相同，因此任何能源消耗分配都是公平的。然后，使用每个客户端的资源消耗的分数（50%）并乘以绝对能量消耗，将 180W 与每个客户端相关联。

• 情况 2: 一名客户被调离

在第二种情况下，客户端 B 被调离，将客户端 A 单独留在服务器上。这里，总节点功率为 280W，完全分配给客户端 A。该功率基于功率模型，其中空闲功率为 200W。如第一种情况所示，使用 20%节点 CPU 的两个应用程序的负载功率为 160W，这意味着每个客户端的负载功耗为 80W。因此，由于客户端 A 在第二种情况下仍消耗 10%的 CPU，因此其负载功耗保持在 80W。

• 情况 3: 资源利用率更高的新客户

现在考虑第三种资源利用率不均衡的情况：客户端 A 仍然使用 10%的 CPU，但客户端 B 现在使用节点 40%的 CPU。如果我们只使用节点的绝对功耗 600W，客户端 B 80%的资源利用率导致总功耗为 480W 其中客户端 A 占 120W。但是，如果我们隔离 200W 的空闲能耗，客户端 B 的功耗将为 420W（320W 用于负载+100W 用于空闲能耗），而客户端 A 的能耗将为 180W（80W 用于负载，因为它仍使用 10%的 CPU+100W 作为空闲能耗）。

• 情况四: 资源利用率较低的新客户

情况四与第三种情况类似，但客户 B 使用的资源比客户 A 少，这进一步说明了闲置功率分配不公平的可能性。

在第三种情况下，隔离闲置电源可以增强可预测性和清晰度。该方法划分恒定功率（不受资源使用的影响），并仅根据资源使用情况定义动态功率。具体来说，根据功率模型，客户端 A 的负载功率为 80W。通过基于资源比率和绝对功率来分配空闲功率，客户端 A 获得 40W 的空闲功率，而客户端 B 获得 160W 的空闲电力。绝对功率而言，客户端 A 仅接收到 40W 的空闲功率，而客户端 B 具有 160W 的空闲功率。

这些闲置功率的不平等分布凸显了不公平，因为闲置功率消耗与资源利用率无关。基于资源请求应用功耗比率并不能准确地反映与实际资源利用率相对应的实际动态功耗。

仅仅基于资源利用率，很难证明向一个客户端提供比另一个客户端更多的空闲功率是合理的。空闲功率的公平分配可以考虑应用程序的大小，也可以在所有应用程序之间均匀地分配空闲功率成本。

译者注：我们不妨假设用户 A 的能耗恒定为 80w 的负载能耗，然后考察在情况 1 ～ 4 中，不同空闲功率计算方式对于用户 A 总能耗的影响。

估算闲置功率的挑战

既然我们了解了隔离和报告空闲功率的重要性，让我们深入研究 Kepler 如何应对估计空闲功率的挑战，尤其是在某些信息（如共处一地的虚拟机数量）可能被掩盖的云环境中。

在裸机上，当服务器利用率接近零时，我们可以通过识别功耗的最小点来估计空闲功率[2，3]。然而，我们计划通过回归分析来扩展这个模型，以发现繁忙系统中的空闲功率。

由于未知的物理规格和租户（VM）数量，估计虚拟专用云中的空闲功率是一项挑战。为了解决这个问题，我们开发了一个训练框架，专注于单独提取和训练动态功率模型。这种方法减少了对未知因素的依赖，并增强了虚拟机的节能优化4^[19].

正如我们在上一篇博客文章中所讨论的那样5^[20]，我们禁用了在虚拟机上运行的容器的空闲电源。我们仍然需要解决闲置电力的归属和核算问题。为了找到平衡，我们正在开发一种基于有限信息估计虚拟机空闲功率的方法，特别是在物理核心固定到虚拟核心而没有过度规划并且虚拟机模拟相同 CPU 架构的情况下。对于这些，我们可以使用在类似 CPU 架构上训练的功率模型来基于内核计数来估计 VM 空闲功率。例如，如果我们的 64 个核的模型预测空闲功率为 160W，那么具有 8 个虚拟核的 VM 将估计大约 20W（即 160/8）。

然而，需要注意的是，如示例的情况 2 所示，在不了解所有共享租户所请求的资源的情况下，云浪费可能仍无法在用户级别得到充分考虑。

结论

用户层面的完全能耗核算仍然是一个挑战，需要在行业内进行进一步的研究和合作。公共云效率的透明、细粒度的能源指标十分重要，需要解决诸如空闲功率归属和估计等挑战。Kepler 这样的工具为可持续的云计算实践铺平了道路。

收获

• SCI 标准量化了软件系统的碳排放率，并促进了可持续性的细粒度数据使用。从业者之间的合作对于在软件设计、开发和交付过程中集体降低 SCI 指标至关重要。

• 透明的能源指标，如 Kepler 提供的每个功能单元的闲置和动态功率，对于促进可持续和节能的云计算实践至关重要。

• 尽管取得了进展，但仍存在一些问题，需要在行业内进行进一步的研究和合作。

采取行动

• 阅读Green Software^[21]的相关资料
• 探索和尝试Kepler^[22]
• 加入 CNCF Slack #kepler-project^[23]讨论组

参考文献:

[1] Guillaume Fieni, Romain Rouvoy, Lionel Seinturier. SmartWatts: Self-Calibrating Software-Defined Power Meter for Containers. IEEE CCGRID 2020. https://ieeexplore.ieee.org/document/9139675

[2] Marcelo Amaral, Huamin Chen, Tatsuhiro Chiba, Rina Nakazawa, Sunyanan Choochotkaew, Eun Kyung Lee, Tamar Eilam. Kepler: A framework to calculate the energy consumption of containerized applications. IEEE CLOUD WIP 2023. https://www.computer.org/csdl/proceedings-article/cloud/2023/048100a069/1QJi0ffK3ug

[3] Marcelo Amaral, Huamin Chen, Tatsuhiro Chiba, Rina Nakazawa, Sunyanan Choochotkaew, Eun Kyung Lee, Tamar Eilam. Process-based Efficient Power Level Exporter. IEEE CLOUD 2024 (in press).

[4] Advancing Cloud Sustainability: A Versatile Framework for Container Power Model Training. IEEE MASCOTS Workshop 2023. https://www.computer.org/csdl/proceedings-article/mascots/2023/10387542/1TKR5vzaWXe

[5] Exploring Kepler’s potentials: unveiling cloud application power consumption, https://www.cncf.io/blog/2023/10/11/exploring-keplers-potentials-unveiling-cloud-application-power-consumption/