Noisy Neighbor 策略

https://blueprints.launchpad.net/watcher/+spec/noisy-neighbor-strategy

本规范描述了一种新的策略，用于识别并迁移 Noisy Neighbor（吵闹邻居），即位于同一宿主机上时，会对更高优先级 VM 的 Last Level Cache (LLC) 产生负面影响的较低优先级 VM。

问题描述

在多租户云环境中，Noisy Neighbor 是一个大问题。一些较低优先级的 VM 可能会通过垄断 CPU、I/O 和网络带宽，对更高优先级的 VM 的性能产生负面影响。已经存在一些策略来解决其中一些问题，例如 CPU 利用率以及使用缓存占用率阈值作为指标来识别 Noisy Neighbor 的算法。这些算法过于简单，没有考虑到 VM 之间的交互，包括任何性能影响以及 VM 之间的相对优先级。例如，一个 VM 可能会使用 50% 的缓存占用率，但可能没问题。这完全取决于 VM 的优先级。此算法利用 IPC、LLC 和 VM 的相对优先级。

LLC（Last Level Cache），或 X86 中的 L3 缓存，至关重要，并且限制了节点上所有应用程序或 VM 共享的系统级资源。如果一个 VM 占用大部分 L3 缓存，则节点上的其他 VM 可能会因缺乏足够的 L3 缓存而饿死，从而导致性能下降。

用例

作为 OpenStack 操作员，我需要找到影响我的高优先级 VM 的 Noisy Neighbor VM，并将它们迁移到没有 Noisy Neighbor 问题的另一个节点。

提议的变更

  • 添加一个新的目标 - “Noisy Neighbor 迁移”

  • 扩展基础策略类，添加一个新的策略 - “Noisy Neighbor 解决方案”

  • 使用 Ceilometer 客户端获取以下指标来检测 LLC Noisy Neighbor

    • cpu_l3_cache – VM 的 LLC 占用率

  • 检测 Noisy Neighbor 的算法

    • 按照 VM 的“watcher-priority”（在 VM 元数据中设置）的顺序监控所有 VM 的 L3 缓存。例如，watcher-priority 为“1”的 VM 的 L3 缓存将在 watcher-priority 为“8”的 VM 之前被监控。

    • 如果 VM 的 L3 缓存下降超过阈值，则将其标记为高优先级。然后开始监控 L3 缓存，按照 VM 的“watcher-priority”的相反顺序。

    • 如果 VM 的 L3 缓存（以“watcher-priority”的相反顺序搜索的 VM）增加超过阈值，则该 VM 是 Noisy Neighbor。

    • 寻找没有 Noisy Neighbor 问题的节点，并将 Noisy VM 迁移到那里。

备选方案

无

数据模型影响

无

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

查询指标可能会在运行策略时导致轻微的性能下降。

其他部署者影响

要启用 LLC 指标，需要最新的支持 CMT 的 Intel 服务器。还需要 collectd 来收集 LLC 指标数据。

开发人员影响

无

实现

负责人

主要负责人

<prudhvi-rao-shedimbi>

工作项

  1. 定义 IPC 和 LLC 的适当阈值

  2. 编写 execute 函数以定位 Noisy Neighbor

  3. 选择用于实时迁移的目标节点。

依赖项

测试

需要单元测试和功能测试。

文档影响

添加关于如何使用此策略的文档。

参考资料

http://www.intel.com/content/www/us/en/architecture-and-technology/resource-director-technology.html

历史

无