资源碎片的管理和再利用从以上的例举中，我们可以了解到，随着计算框架多样性的发展，资源管理框架则必须慢慢的实现和优化资源碎片的管理。对于资源碎片，我们一般会有两个方向需要研究，一是“去碎片”，换句话说就是减少碎片的产生或者优先产生可复用的碎片，二遍是碎片的管理和再利用。
这里我先简单的描述下整个方案的运行流程。
- 每一个 Workload Manager 会启动一个独立的 Resource Proxy。
- 当用户提交了一个 A 类型的任务时，Workload Manager 会通过自己的 Resource Proxy 向资源层的 Resource Manager 申请资源。Proxy 会维护管理申请到的资源。
- 当用户提交了另一个 A 类型的任务时，Workload Manager 会通过 Proxy 向 Resource Manager 申请新的资源。如果 RM 没有新的资源时，Proxy 会按照某一种策略平衡两个任务，尽量使得两个任务都有适当的资源运行。
- 如果 Proxy 中发生资源强占的行为，并且用户指定了不同的资源配比（例如第一个任务的 Task 需求 2 个 CPU 核和 3G 内存，第二个任务的 Task 需求 1 个 CPU 核和 2G 内存）。那么 Proxy 中就会产生资源碎片。
- 每个 Resource Proxy 会设置一个资源共享池，并且会将 Proxy 已经产生的碎片放到资源共享池中。
- 当用户提交一个 B 类型的任务时，并且 RM 没有空余的资源分配给 B 类型的任务时。RM 会同步所有 Resource Proxy 中资源池的信息，并且会拼接多个资源池中同个机器的碎片，进而将满足 B 类型任务需求的资源，分配给 B 任务。
- 当又有新的 A 类型任务提交到系统，并且 Proxy 剩余的资源碎片可以满足新的 A 类型任务时，Proxy 会重新要回该自己借出去的碎片资源。
以上便是整个资源碎片处理流程的简要描述，后面我将通过几个 Case 来详细描述该方案的工作过程。
Case 1，资源的分配流程（资源足够的时候）首先，每一种 Workload 都有独立的 Workload Manager，这一点类似于 Yarn 的 Application Master。并且每一个 Workload Manager 会启动一个 Resource Proxy（在 Workload Manager 内和外都可以）。当有任务提交时，Workload Manager 会通过 Proxy 向 RM 申请资源。当 RM 返回适当的资源给 Proxy 后，Proxy 会维护这些资源的信息。RM 则负责管理和维护整个集群资源的状态。具体流程可以参见如下的示意图
图 2. 资源分配的流程 1 Case 2，资源分配流程（资源不足够的时候）当 A Workload Manager 提交了一个比较大的任务，且每个 Task 需求 4G 内存和 4 个 CPU 核的资源时，A Workload Manager 对应的 Proxy 会获取集群中所有可用的 4G 内存和 4 个 CPU 核的资源块。我们暂且忽略每个机器上产生的碎片（也可以认为所有机器上的资源刚好是 4G 内存和 4 个 CPU 核数或整数倍）。此时，如果 A Workload Manager 又提交一个优先级更高的任务，且需求的资源配比是 3G 内存和 3 个 CPU 核数，那么 Proxy 中将发生资源强占（集群中，RM 没有剩余的资源再分配给这个任务）。2 次提交的 A 类型任务会强占第一次的 A 类型任务所拿到的资源，这样一来，Proxy 中将产生 1G 内存和 1 个 CPU 核数的资源碎片剩余。这时候 Proxy 会将所有的碎片放到自己的共享池中（Resource Shared Pool），并将该资源信息同步给 RM。如果此时，B Workload Manager 提交一个任务，资源需求的配比刚好是 1G 内存和 1 个 CPU 核，那么 RM 会先检查集群是否有可用的资源，如果没有，则检查 Proxy 内共享池中资源的信息。由于共享池中的碎片刚好满足 B 任务的需求，RM 则会将碎片授予 B 类型 Workload 使用。需要注意，这里只是一个比较简单的方案，如果要在实际的产品中应用这样的方案，还需要考虑很多因素。例如当 Proxy 中共享池的资源配比大于 B 的需求时，那么共享池依然会二次产生碎片。如果再将二次产生的碎片分配给其他任务时，必然会加大资源管理层（RM）的负担。尤其是当资源真正的拥有者 A Workload 需要回收资源时，就必须尽快杀死使用其碎片的 Workload（这里便是 B）。所以当 Workload 为短 Task 的时候（每个 Task 运行时间比较短），重复利用资源碎片会大大提高资源利用率。但如果全是长 Task（每个 Task 运行时间特别长），那么资源碎片的回收，会经常引起任务的重复运行（re-run）。这样反而有可能只加重了资源管理层（RM）和任务管理层（Workload Manager）的负担，从而降低了系统的性能。因此在优化的过程中，需要进行任务长度的预判（从历史数据中），从而适当的动态调节碎片的使用度。大致的工作流程如下图所示。
图 3. 资源分配图 2 Case 3，融合多个资源池服务新的 Workload这里我们必须有一个客观的前提，资源永远是有限的。对于这个 Case，我们还需要假设另一个前提：有两个类型的 Workload A 和 B，并且都在集群中占用了一定的资源运行各自的 Workload。如果两种类型的 Workload，先提交的任务需求的资源配比都是 4G 内存和 4 个 CPU 核数（每个 Task），并且对应的 Proxy 已经从 RM 拿到适当的资源。这时候两个 Proxy 都维护了一部分 4G 内存和 4 CPU 核数的资源块。在随后的任务中，两个类型的 Workload 又再次提交了高优先级的 Workload，且资源需求配比是 3G 内存和 3 个 CPU 核数（每个 Task）时，这时候两个 Proxy 都会发生资源强占行为，并产生 1G 内存和 1 个 CPU 核的资源块碎片。Proxy 随后会将自己的碎片放入各自的资源共享池中，并同步信息给 RM。如果这时候有新的 Workload 类型 C，提交了一个新的任务，资源配比需求是 2G 内存和 2 个 CPU 核数（每个 Task），那么 RM 会遍历两个共享池的资源碎片，并将同个机器的上的碎片拼接到一起，分配给 C 的任务。工作示意图如下。
图 4. 资源分配示意图 3 Case 4，资源碎片的整理拼接在 Case 3 中，我们已经看到了资源碎片的拼接。在这个示例中，我们可以详细探讨下碎片的整理和再利用。首先，我们要理解一个 Proxy 负责为一种类型 Workload 的申请并管理资源。在实际的生产环境中，用户一般可以在提交任务时，配置该次任务的资源需求配比。当多次任务的资源配比不一致时，就很容易在 Proxy 中产生资源碎片。多个 Proxy 就会积攒更多的碎片，而且碎片的资源块大小一般也是不同的。这时候，每个 Proxy 会将各自的碎片放入自己建立的共享池中。Proxy 会将共享池的资源暴露给 RM，作为可用的资源，供 RM 分配。RM 一般会优先分配非碎片的资源，当有新的 Workload 请求资源，且资源不足时，RM 首先会查询各个 Proxy 中共享池资源的状态，然后将碎片以 Host 为单位进行拼接，如果该机器也有未分配出去的资源碎片，也将一同被拼接，最后将满足条件的资源快分配给新的 Workload。工作示意图如下。
图 5. 资源碎片的拼接 结束语本文中只简单的阐述了一种碎片再利用的方式，而要彻底的解决多维度调度中所产生的碎片还要考虑很多其他的因素。对于文章一开始所提及的两个方向，一是如何减少碎片的产生或者优先产生易于再利用的碎片，二是如何再利用已经产生的碎片，本文所想表达的是如何再利用碎片资源，这是建立在碎片已经产生的之后的处理方式。有兴趣的读者，也可以研究下第一个方向。对于第二个方向，本文也只是一个简述，如果要真正的在产品中实现中，则还需要考虑更多的细节，如借出碎片的归还问题，以及碎片资源拼接后再次产生的碎片该如何处理等等。希望读者能从本文建立一些资源碎片处理的初步印象。 |
