资源健康度和干扰检测讨论

[zwzhang0107]

TODO

[zwzhang0107]

1. 梳理待采集指标&&热点衡量策略、SLA 定义 (ddl: 9.13）

2. 数据流和干扰检测框架设计（ddl: 9.20）
   https://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/forecasting/20230613-framework-of-prediction-and-detection.md

[Suozz]

1. 梳理待采集指标&&热点衡量策略、SLA 定义 (ddl: 9.13）

2. 数据流和干扰检测框架设计（ddl: 9.20）
   https://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/forecasting/20230613-framework-of-prediction-and-detection.md

• 指标文档提到 discussion @zhouxin
• 对齐内外 ebpf 指标采集框架（尽量风险低，成本低）@zhouxin@zuowei
• 中心侧框架搭建 ddl: 10.1 后 @zuowei
• koordetecter 最新代码 （调度延迟） @zuowei

[zxustc]

指标列表（RFC）

CPU:
CPU PSI
run delay
runq len
runq slower
task switch counts
CPU 频率
MEM:
内存 PSI
同步内存申请耗时
内存回收函数耗时
compaction 耗时
同步 compaction 耗时
memcg 限制导致内存回收耗时
kswapd 触发次数
异步整理触发次数
分配内存过程中发生 retry 的次数
同步回收触发次数
同步整理触发次数
refault 次数
page cache/buffer 大小
slab 总数
slab 不可回收数
OOM
compaction 失败次数
IO:
io psi
磁盘利用率
cpu io wait

进度

cpu 侧指标已经完成，得益于alinos cloud-kernel 的统计能力，几乎没有使用到 eBPF；@zhouxin

合作模式

alinos cloud-kernel 的统计能力，对 eBPF 的依赖降低。待评估：@zhouxin
向社区提交代码可行性

TODO

1. koordetector 代码评估 @zhouxin
2. ebpf/proc 获取的指标粒度可能有较大差异，需要评估（长期） @zhouxin @zuowei
3. 现有的 kernel 中，cgroup 下暴露的指标是否足够，是否需要 ebpf? （长期）@zhouxin @zuowei
4. 中心侧框架搭建 ddl: 10月 @zuowei

[zwzhang0107]

1018

• 指标评估 延到月底：
  • koordetector 代码评估 @zhouxin
  • ebpf/proc 获取的指标粒度可能有较大差异，需要评估（长期） @zhouxin @zuowei
  • 现有的 kernel 中，cgroup 下暴露的指标是否足够，是否需要 ebpf? （长期）@zhouxin @zuowei
  • alinos cloud-kernel 的统计能力，对 eBPF 的依赖降低。待评估：@zhouxin
    向社区提交代码可行性
• 中心侧框架搭建 ddl: 10月 @zuowei

[zxustc]

1025

• 指标评估 延到月底：

1. koordetector 代码评估 @zhouxin
2. ebpf/proc （容器粒度）获取的指标粒度可能有较大差异，需要评估（长期） @zhouxin @zuowei
   block latency/wait latency 等指标已经可以反应 业务性能衰退原因；
   on cpu time 可以直接关联到业务性能；
   /proc 获取 整机信息（包括一些信息和指标），包括 内存和 cpu 维度；
   cgroup cpuacct - sched_statistics: wait latency/queue latency(queue other latency and queue sibling latency)
   - block latency / io block latency
3. 现有的 kernel 中，cgroup 下暴露的指标是否足够，是否需要 ebpf? （长期）@zhouxin @zuowei
4. alinos cloud-kernel 的统计能力，对 eBPF 的依赖降低。待评估：@zhouxin
5. 向社区提交代码可行性

• 中心侧框架搭建 ddl: 11月中旬 @zuowei

[zxustc]

现有问题

1. 混部场景上，同一个 node 上不同的 pod 可能存在干扰，导致 pod 性能受损；
2. 调度场景上，pod 可能会被调度到资源短缺的节点，导致 pod 启动即受损；

我们对系统侵入较小的各类指标已经采集完毕，在各类业务场景中也观察到，业务性能衰减时，往往伴随着系统指标的飙升。因此，我们具有了将业务性能与系统指标关联的信心。在系统指标可观测的场景下，设计基于干扰指标的调度决策中心，期望实现：

1. 收集节点压力数据，为调度器提供调度模型，支撑 pod 首次调度时的节点选取，最大化利用节点资源，避免业务开机即受损；
2. 收集业务性能指标与节点系统指标，为单机稳定性组件提供业务受损模型，支持业务性能受损时单机侧组件的及时干预，实现分钟级的性能恢复。

期望解决的问题

1. 可以输出一个能够识别调度干扰等问题导致 pod 受损的模型；解决同一个 node 上的业务之间的干扰；
2. 输出一个 workload 偏好资源的模型，指导调度策略；
3. 输出一个 node 的健康度 crd 模型，由调度器决定是否可以调度；指导节点的选择，避免高压力节点被调度；例如高内存带宽任务的合理打散；

[zxustc]

结合社区已有预测组建的设计思路，尝试提出组件结构：


其中输出的模型有三类：

1. pod 干扰检测模型；
2. node 健康度模型；
3. pod 资源偏好模型。

[zxustc]

1. 单机侧链路开发中，完成指标数据本地数据库固化；单机侧组件链路打通工作，开发中；
2. 新人 rampup 中；

[andrewzrant]

这块哪里可以看到设计文档或者思路吗？想了解一下相关的设计思路，只看了disscussion还是有一些模糊