[RFC]: openYuanrong 多租户资源配额与限额调度机制

### 背景与目标描述.

1. 摘要

本RFC旨在解决当前openYuanrong通智融合算力平台在多租户环境下存在的资源抢占问题。平台目前仅提供逻辑隔离，但缺乏对物理资源（如CPU、内存、GPU）使用量的硬性限制。这导致单一租户提交过量任务时，可能耗尽集群资源，影响其他租户任务的正常调度与执行。本提案计划设计并实现一套资源配额管理与限额调度机制，以确保资源分配的公平性和稳定性。

2. 动机与背景

openYuanrong的设计目标是提供统一的Serverless分布式计算体验。在多个租户（例如，不同的业务团队或用户）共享同一集群的场景下，公平性至关重要。
- 现状：用户（租户）在平台上提交计算任务（如金融估值、风险计算），平台负责调度与执行。但目前资源分配是“尽力而为”的模式。
- 问题：如用户1可无限制提交高强度的“情景模拟”任务，可能占满所有计算资源，导致用户2的“夏普利算法”任务被阻塞，无法得到调度。这不仅影响用户体验，也可能对需要及时响应的关键业务造成损害。

3. 目标

1.  资源配额定义：支持为每个租户定义资源使用上限（配额），例如CPU核数、内存大小、GPU卡数等。
2.  限额调度：调度器在分配任务时，需实时检查租户的资源使用量是否已超过其配额。对超限的任务，将其置于等待队列而非立即调度。
3.  队列优先级：支持为等待队列中的任务设置优先级策略（如先入先出、基于任务紧急度），并在资源释放时按策略调度。
4.  状态可见性：向租户清晰展示其资源使用情况、配额状态以及任务排队信息。

### 建议的方案.

4. 方案概设

4.1 核心概念

-   租户：资源隔离和配额分配的基本单位，可对应一个用户、一个项目或一个部门。
-   资源配额：分配给一个租户的资源上限，可分为：
    -   计算资源配额：CPU、内存、GPU等。
    -   任务数量配额：并发运行的任务实例数上限。
-   资源记账：平台实时跟踪每个租户已消耗的资源量。

4.2 系统架构与组件交互

下图概括性地描述了配额管理的关键流程和组件交互关系：
flowchart TD
    A[用户提交任务] --> B[“任务提交接口”]
    B --> C{调度器检查配额}
    
    C -- 配额充足 --> D[执行任务]
    C -- 配额不足 --> E[“进入等待队列”]
    
    E -- 资源释放/轮询检查 --> C
    D --> F[更新资源使用量]
    F --> G[“资源使用记录器<br>（实时记账）”]
    G --> H[“配额管理器<br>（存储租户配额配置）”]
    
    H -.-> C

上述流程主要涉及以下几个核心组件：

1.  配额管理器：负责存储和管理各租户的配额配置。提供API供查询和校验。
2.  资源使用记录器：实时记录和聚合每个租户当前正在运行的任务所消耗的资源总量。
3.  增强型调度器：这是核心组件。在调度决策前，需查询“资源使用记录器”获取该租户当前已用量，再查询“配额管理器”获取其配额。若 （已用量 + 当前任务请求量）<= 配额，则正常调度；否则，将任务放入特定的等待队列。
4.  等待队列管理器：管理因配额不足而等待的任务，并实现优先级策略。当有任务完成、资源释放后，该管理器会触发对等待任务的重新调度尝试。

5. 场景示例

以您描述的场景为例：

-   租户A（用户1）：配额为 CPU 100核 / 内存 200GB。
-   租户B（用户2）：配额为 CPU 40核 / 内存 80GB。

1.  初始状态：集群资源充足，两租户的任务均正常调度。
2.  租户A提交大量任务：租户A提交了多个大型“情景模拟”任务，这些任务总计需求为 CPU 90核 / 内存 180GB。此时，租户A的资源使用量低于其配额，任务被调度执行。
3.  租户A继续提交任务：租户A又提交了一个需求为 CPU 20核 的任务。调度器计算发现，执行此任务后，租户A的CPU使用量将达 90 + 20 = 110核，超过其 100核 的配额。
4.  任务被限流：该新任务不会被立即调度，而是被放入等待队列。
5.  租户B提交任务：此时，租户B提交一个需求为 CPU 10核 的“夏普利算法”任务。调度器检查发现，租户B的当前使用量远未达到配额。
6.  公平调度：尽管集群总体资源紧张，但租户B的任务因其配额尚未用完而被正常调度执行，从而保证了其业务不受租户A资源泛滥的影响。
7.  资源释放与等待任务处理：当租户A的某些早期任务执行完毕并释放资源后，其资源使用量降至配额以内。调度器会自动从等待队列中取出租户A的那个任务并尝试调度。

6. 总结与后续工作

本RFC提出通过引入资源配额和增强调度器逻辑，解决openYuanrong多租户环境下的资源公平性问题。下一步需要社区讨论的具体工作可能包括：

-   API设计：定义用于设置、查询、修改租户配额的API接口。
-   优先级策略细化：详细定义等待队列的任务优先级规则。
-   监控与度量：设计资源使用率和排队情况的监控指标。

希望此方案能作为社区一个有益的起点，期待与您和其他贡献者进一步讨论和完善它。

### 涉及到的对外API

### 测试验证

测试目标
验证多租户资源配额与限额调度机制能够在并发场景下生效，确保单租户不会超配额占用资源，同时不影响其他未超配额租户的任务调度，并保证资源记账与状态展示准确一致。

核心验证点

配额硬约束生效：当租户资源使用量 + 任务请求量超过配额时，任务必须进入等待队列，不能被调度执行。

多租户公平性：某租户因超配额被限流时，不应影响其他租户在其配额范围内的正常任务调度。

等待队列可用性：等待任务在资源释放后可按既定队列策略（如 FIFO / 优先级）自动重试并被调度。

资源记账准确性：任务在运行、完成、失败或取消等状态切换时，资源使用量能正确增加和回收，不出现资源泄漏或账本漂移。

并发一致性：高并发提交任务场景下，调度器不会突破租户配额上限。

状态可见性：租户可准确看到自身配额、已用资源、等待队列状态及任务被限流原因，信息与实际调度行为一致。

验收标准

任意时刻单租户实际运行资源不超过其配置配额；

资源释放后等待任务可在合理时间内被重新调度；

监控指标与任务状态能够支撑问题定位与审计。

### 期望的反馈时间.

1月版本

### CC List.

### 其他补充信息.

### Before submitting a new issue...

- [x] Make sure you already searched for previous [RFCs](https://gitee.com/openeuler/yuanrong-runtime/issues).

openEuler/yuanrong
Closed

Content Risk Flag

Comments (1)

openEuler/yuanrongClosed .gitee-modal { width: 500px !important; }

Content Risk Flag