电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: 浅谈大数据资源管理层中的资源碎片（3） [打印本页]

作者: look_w 时间: 2018-6-24 14:33 标题: 浅谈大数据资源管理层中的资源碎片（3）

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，资源碎片的整理拼接

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)