1、飞天（Apsara）简介
2、伏羲系统架构
3、增量式资源管理协议
4、容错任务调度
1、飞天（Apsara）简介
阿里云飞天（Apsara）是由阿里云开发的一个大规模分布式计算系统，其中包括飞天内核和飞天开放服务。
飞天内核负责管理数据中心Linux集群的物理资源，控制分布式程序运行， 隐藏下层故障恢复和数据冗余等细节，有效提供弹性计算和负载均衡。飞天内核体系架构主要包含四大块：
- 分布式系统底层服务：协调服务(女娲)，远程过程调用(夸父)，安全管理(钟馗)；
- 分布式文件系统（盘古）；
- 分布式资源管理和任务调度系统（伏羲）
- 集群部署和监控：集群监控（神农）、集群部署（大禹）。
飞天开放服务为用户应用程序提供了计算和存储两方面的接口和服务，包括：
- 弹性计算服务(Elastic ComputeService，简称ECS)：
- 开放存储服务(Open Storage Service，简称OSS)；
- 开放结构化数据服务(Open Table Service，简称OTS)；
- 关系型数据库服务(Relational Database Service，简称RDS)；
- 开放数据处理服务(Open Data Processing Service，简称ODPS/Maxcompute)；
- 基于弹性计算服务提供了云服务引擎(Aliyun Cloud Engine，简称ACE)作为第三方应用开发和Web 应用运行和托管的平台。
2、伏羲系统架构
伏羲(Fuxi)是飞天平台内核中负责资源管理和任务调度的模块，同时也为应用开发提供了一套编程基础框架。伏羲同时支持强调响应速度的在线服务和强调处理数据吞吐量的离线任务。在伏羲中，这两类应用分别简称为Service和Job。
- 资源管理方面：伏羲主要负责调度和分配集群的存储、计算等资源给上层应用；管理运行在集群节点上任务的生命周期；在多用户运行环境中，支持计算额度、访问控制、作业优先级和资源抢占，在保证公平的前提下，达到有效地共享集群资源。
- 任务调度方面：伏羲面向海量数据处理和大规模计算类型的复杂应用，提供了一个数据驱动的多级流水线并行计算框架，在表述能力上兼容MapReduce、Map-Reduce-Merge等多种编程模式；自动检测故障和系统热点，重试失败任务，保证作业稳定可靠运行完成;具有高可扩展性，能够根据数据分布优化网络开销。
伏羲采用通用的主从架构，它有三个组件：中央资源管理器（称为FuxiMaster），分布式节点管理器（称为FuxiAgent，也叫Tubo）和应用程序主机（Application Master）。
- Fuxi Master
为了在不同的应用程序之间调度集群资源，伏羲主要从生产者和消费者的角度做出决策。例如，有多少资源可供调度以及每个应用程序的具体要求是什么。 FuxiMaster 是两者之间的匹配者。它不仅被动地从每台机器收集所有的空闲资源/虚拟资源，而且还收集来自所有 Application Master 的资源请求。由于来自双方的高度动态信息，FuxiMaster必须及时收集信息并快速公平地执行调度。当应用程序不再需要分配的资源，FuxiMaster 应该尽快将其重新安排到另一个应用程序以获得更高的集群利用率。在安排之后，结果将被传递给相关的 Application master 和 FuxiAgent 。此后，FuxiMaster 可以在资源量保证和 FuxiAgent 基于调度指令支持的每个应用过程的隔离条件下，使用该资源来启动必要的计算过程。
- Fuxi Agent
一台 FuxiAgent 将在每台机器上运行，充当双重角色。 第一种是定期收集本地信息和状态，并将其报告给 FuxiMaster 进行进一步的调度判断。 第二个是通过流程监控、环境保护和流程隔离来确保应用程序流程正常执行。为了实现过程隔离，我们采用了三个方案，这是FuxiAgent最重要的任务。
首先，只要 FuxiAgent 从 FuxiMaster 获得了足够的资源，FuxiAgent 就会启动一个应用程序的流程。 我们将此程序称为资源容量保证。 具体而言，当资源容量减少且应用程序主机没有选择一个进程停止时，FuxiAgent 将强制终止该应用程序的一个进程以确保资源容量。其次，每个过程都配有 Cgroup 软硬限制。 当机器遇到资源过载时，将终止一个或多个进程以将机器负载维持在可接受的阈值内。一个简单的规则是选择实际资源使用超过其自身资源使用的进程。 第三，利用沙箱将不同的进程与诸如访问之类的无效操作隔离开来。实际上，为每个进程创建了不同的根文件夹，以防止来自其他进程的干扰和资源访问。
- Application Master
不同的计算范例（例如MapReduce，Spark或Storm等）将由不同的 Application Master 表示，它们负责特定应用程序的执行逻辑。上图说明了这些组件如何相互协作：
用户首先向 FuxiMaster 提交启动应用程序（例如MapReduce作业）的请求，请求中带有描述信息，其包含必要的信息，例如应用程序类型，master package的位置和应用程序特定信息。然后，FuxiMaster 为这个 Application Master 找到一个拥有充足资源的 FuxiAgent，并请求FuxiAgent启动相应Application Master。一旦启动，Application Master 就会检索应用程序描述，并确定作业执行的不同阶段的资源需求，包括适当的并行度，每次分配的粒度和首选位置。之后，它以增量方式向 FuxiMaster 发送资源分配请求，并等待 FuxiMaster 的资源授予和撤销（如果有）。收到资源授予后，Application Master 将相应的工作计划发送到相应的 FuxiAgent。工作计划包含启动特定流程的必要信息，例如其包位置，资源使用限制和启动参数。收到新的工作计划后，FuxiAgent 启动 Application worker 并使用 Linux Cgroup 来强制执行资源限制。 FuxiAgent监视 worker 的状态，如果崩溃则重新启动它。与此同时，Application worker 还将自己注册到Application Master。当不再需要 worker 时，Application worker 发出增量请求以将授予的资源返回给 FuxiMaster。
3、增量式资源管理协议
在本节中，我们介绍了一个高效的资源管理协议，允许伏羲支持阿里巴巴的规模。我们首先介绍协议设计背后的基本思想。 然后，我们描述协议中使用的关键数据结构。 接着，我们描述了调度算法，该算法以称为位置树的数据结构为中心。最后我们总结本节，其中考虑了多租户和可扩展性。
（1）基本思想（Basic Idea）
增量调度(Incremental Scheduling)：考虑一个拥有数十万个并发任务的集群，平均运行数十秒，资源需求/供应情况每秒会改变数万次。 以如此快的速度做出及时的调度决策意味着 FuxiMaster 无法在每个决策过程中重新计算所有机器上的CPU、内存和其它资源到所有应用程序任务的完整映射。使用基于位置树的增量调度，仅计算已更改的部分。 例如，当{2CPU，10GB}的资源在机器A上释放时，我们只需要决定机器A的等待队列中的哪个应用程序应该获得该资源。 无需考虑其他机器或其它应用程序。 根据这种直观但有效的基于位置的方法，可以实现微秒级别调度。
增量通信（Incremental Communication）: 同样，在由数千个应用程序和机器组成的环境中，不同组件（如FuxiMaster，Application Master 和 FuxiAgent）之间的大量消息通信将是一个不可忽视的因素，它会极大地影响 FuxiMaster 的性能。 应用程序可能需要运行数十万个进程。一个简单的迭代过程不断询问未满的填充资源将占用太多带宽，并在集群繁忙时变得更糟。
出于这个原因，我们尝试通过仅在发生更改时从 Application Master 和 FuxiAgent 向FuxiMaster 发送消息来减少洪泛消息。此外，仅传输增量部分。应用程序可以以增量方式发布其资源需求。在最简单的形式中，应用程序仅指定一次资源需求并等待迭代分配资源，并在退出时返回资源。另一方面，这样的协议要求在 FuxiMaster 和 Application Master 中维护状态，并且在不同实体之间保持一致性时容易出现许多问题。例如，我们必须确保在发送方生成更改的部分后，更改的部分可以在发送方和接收方以相同的顺序进行分发和处理。此外，我们必须确保处理重复增量消息的幂等性，这种重复增量消息的情况可能是由于临时通信故障而发生的。总之，我们必须确保两个通信对等体之间的整个信息版本完全相同。作为安全措施，Application Master 定期与FuxiMaster 交换资源的完整状态，以解决任何可能的不一致问题。
如下图所示，给出了一个简化的例子来说明增量调度和通信的原理。 我们将 ScheduleUnit 定义为资源的单元大小，例如1核CPU，1GB内存。 小矩形中的数字1到8表示按时间顺序排列的步骤，如下面的顺序所述：
- 1）AppMaster 1 申请集群中10个 ScheduleUnits（简称SU_A）的资源。 详细要求包括：a）一个SU_A包含一个CPU内核和2GB内存; b）如果M1（M1表示 FuxiAgent 1 所在的机器）上的免费资源可用，则M1上至少有2个SU_As; c）其他机器没有位置偏好; d）最多需要10个SU_A；
- 2）在收到 AppMaster 1 的请求后，FuxiMaster 将在安排之前检查可用资源，检查 AppMaster 1 的组配额可用性。 在这种情况下，可以满足M1上的2个单位资源（实际上在该机器上分配了3个单位）。 在M2上分配3个单元并在M3上分配2个单元后，Application Master 在群集中的任何机器上仍需要另外2个单元的可用资源。 值得注意的是，根据我们提出的增量策略，AppMaster1 不需要在此更新其对SU_A的资源请求；
- 3）AppMaster 2 恰好在M3上返回1个单位的资源；
- 4）收到返回消息后，FuxiMaster 会检查其等待队列，并将AppMaster 1 识别为具有最高优先级的应用程序。由于其单位尺寸远小于AppMaster 2，因此可以满足2个单位的要求。因此，调度决策是在从机器M3上的AppMaster 2撤销一个单元资源之后将2个单元的资源分配给AppMaster 1。在时间4中，增量调度结果也以增量消息的方式分别传送到相关的Application Master和FuxiAgent；
- 5）在不同的机器上从AppMaster 1返回8个单位的资源，消息以增量模式到达FuxiMaster；
- 6）收到此消息后，FuxiMaster会执行调度并将这些返回的资源分配给队列中的其他等待应用程序；
- 7）AppMaster 1 中剩余的更多资源以增量方式返回；
- 8）重复相同的过程，在此期间 FuxiMaster 通过建议的增量通信和调度来调度并将这些返回的资源分配给其他等待的应用程序。
（2）关键数据结构（Key Data Structure）
1）资源描述：包括物理和虚拟资源
在运行不同类型计算任务的大型集群上，进程实际上需要在不同维度上有不成比例资源需求，例如， CPU，内存。 Fuxi将所有这些不同的需求整合到一个统一的多维资源描述中，其中包括目前物理资源的CPU和内存，但未来可以很容易地扩展到更多维度。 它可用于描述单个节点的总资源和可用资源以及资源请求的数量。 所有资源分配都基于此资源描述抽象，同时必须满足此描述的所有维度。
除了物理资源之外，我们还引入了“虚拟资源”的概念，使应用程序能够轻松限制节点上某个任务的并发性。 例如，要在集群中运行名为ASort的分布式排序应用程序，如果我们只允许在同一节点上运行5个并发计算进程，我们可以将每个节点配置为仅包含5个虚拟资源。 我们可以为虚拟资源命名（例如，'ASortResource'），并且必须配置ASort应用程序以为每个计算过程请求一个'ASortResource'。 可以随时更改每个节点上的总虚拟资源。、
2）资源请求
资源请求包括 ScheduleUnit 定义，每个 ScheduleUnit 的数量以及其他属性（位置首选项，避免的机器列表，优先级等）。它从应用程序主机发送到 FuxiMaster 以申请资源。 ScheduleUnit是资源的单元大小描述，例如 {1核心CPU，1GB Memoryg }。资源可以分为三级树层次结构：机器，机架和集群。一台机器可以拥有数十个CPU内核和几千兆字节的内存，而一个机架由数十台或数百台机器组成。相应地，具有数千台机器的数十个机架构成一个集群。每个应用程序都可以在一台特定机器或集群内某些机架或机器中的任何机器上请求资源。这主要取决于应用程序计算过程首选的数据位置（例如，计算最好发生在数据驻留的位置或至少在同一网络交换机中）。任何后续资源请求都基于此 ScheduleUnit，它只需要指定每台机器/机架/集群上的此单元的数量（参见上图）。每个应用程序可以有多个ScheduleUnit，每个单元具有相同或不同的优先级但不同的单元大小。 FuxiMaster中的调度将基于不同的调度单元。
此外，Application Master 可以在第一次提交请求后随时动态更改其资源请求。数量可以是正数或负数，分别表示资源请求的增加或减少。当由于检测到一些坏节点或者返回未使用的资源，或者某些实例的备份运行需要更多资源等事实而调整位置偏好时，可能会发生这种情况。使用10个 mapper 和一个 reducer 为例进行map-reduce作业，我们需要首先请求10个 mapper。如果FuxiMaster 仅授予6个单位，则无需向 FuxiMaster 发送新请求以获得额外的4个单位资源。 FuxiMaster会自动将请求插入到调度程序的等待队列中。当可用资源时，随后将向应用程序主机授予额外的4个单元资源。当一些 mapper 完成时，Application Master 通过相同的协议返回资源，但只需要发送单元号。
3）资源响应
资源授予者赋予 Application Master 在特定节点上运行工作进程的权限。无论 Application Master 请求哪种级别的资源（机器，机架或群集），特定计算机上的资源都将在调度后授予每个应用程序。 FuxiMaster 将在消息响应中以（M1,3），（M2,4），...，（Mn，1）的形式通知被授予资源的 Application Master，附加每个资源量。数量可以是正数或负数，分别表示资源的授予或撤销。资源撤销意味着先前提供的资源授权不再有效，可能是由于诸如节点关闭或抢占等原因。Application Master可能通过在适当的时候终止相应的 App worker 来对消息做出回应，或者 App worker 将不自觉地由FuxiAgent终止。 Fuxi区分开任务（执行实际工作的应用程序进程）和容器（授予资源的单位）的概念。Application Master 收到授权后，它会明确控制其生命周期，并可以重用容器来运行多个任务。这是Fuxi和Yarn之间的主要差异之一。在Yarn的实现中，任务和任务的资源之间没有分离。每当任务完成时，节点管理器总是回收资源，即使 Application Master 有更多准备好的任务要执行。因此，资源管理器必须进行额外轮次的重新安排，从而产生大量开销和不必要的请求消息。
（3）基于位置树的调度
FuxiMaster 调度器维护两个数据结构：可用资源池和位置树。收到 Application Master 的资源请求后，FuxiMaster将检查空闲资源池，并尝试找到符合应用程序本地要求的免费资源。同时，还将考虑负载平衡。如果空闲资源不足，资源请求将在FuxiMaster 的调度程序中排队。不同的机器，机架和集群具有各自的等待队列，并且在同一机器，机架或集群上请求资源的应用程序将被放入同一队列中。机器，机架和集群上的这些队列构成了一个位置树。
特别地，这种基于位置树的调度是Fuxi和Yarn之间的另一个主要区别。 Fuxi 在 FuxiMaster 调度器中将这些不满足的资源请求排队，并在资源释放时自动将资源授予 Application Master。通过这种方式，我们可以在提高集群利用率的同时加速资源释放和重新调度。当一个 Application Master 返回一台机器的资源时，将选择某个等待的应用程序来获取已释放的资源。优先级是主要考虑因素，具有更高优先级的应用程序将首先获得资源。当优先级相同时，将考虑等待时间。此外，等待在计算机队列上的应用程序将优先于等待在计算机所属的机架/群集队列上的应用程序。目标是在优先级相同的情况下确保集群整体局部性计算。应用程序可以选择在特定计算机，某个机架或群集中的任何计算机上等待，并且在同一树上等待的所有应用程序都按优先级和提交时间排序。下图可以被示为调度树的示例。 App1 等待 M1 上4个单位的资源和 M2 上4个单位的资源，而 Rack1，Rack2 和整个集群上分别有9个单元、4个单元和14个单元。当满足任何这些等待请求时，资源将被分配给 App1，相关的等待请求将减少分配的单位数量。
（4）其它设计考虑
1）多租户支持（Multi-Tenancy Support）:
至于公平性，引入了资源配额概念。通过这种方式，一个群集可以具有多个配额组，而每个应用程序必须属于一个且仅属于一个组。当来自一个配额组的应用程序处于空闲状态且无法占用所有资源时，来自其他配额组的应用程序可以使用它。当所有配额组都忙时，将确保每个组的最小配额。动态配额调整超出了本文的范围，不会详细介绍。要实施配额重新分配，FuxiMaster必须通过抢占来撤销具有配额限制的应用程序的一些资源授予。当来自一个配额组的应用程序的资源请求增加并且不满足最小资源配额时，将抢占过度使用资源的配额组以为该配额组腾出空间。除了配额抢占之外，我们还提供优先级抢占，主要针对优先级较高的应用程序迟交其资源请求但集群资源恰好全部被调度出去的情况。此时，在配额组中具有最低优先级的应用程序将被抢占，以便为更高的应用程序腾出空间。第二级是配额优先。
2）优先请求处理（Prioritized Request Handling）:
作为群集中唯一的中央主人，FuxiMaster容易成为瓶颈，因为必须及时传输，处理和响应大量消息和请求。 例如，当午夜在生产集群中批量启动数千个作业时，FuxiMaster可能会遇到资源的峰值请求。 更糟糕的是，FuxiMaster 还承担了很多同行的资源调度、信息传播的重要职责，这将占用 FuxiMaster 大量的处理时间。 此外，由于故障是一种常规现象，以至于FuxiMaster需要具备解决集群可用性保证和容错问题的能力，这将大大加重其负担。
为了分散峰值请求并减轻负担，我们提出了多层次和优先级响应机制，我们将FuxiMaster完成的工作分为不同的重要性和延迟要求。在这种情况下，请求处理顺序根据紧急优先级确定。具体而言，资源回复和重新分配等紧急请求将由事件触发，以便及时响应，同时实现更高的集群利用率。此外，一些类似的请求（例如，频繁改变来自一个应用程序的资源请求）被紧凑地合并并以批处理模式处理，从而减轻了通信开销。相反，其它重量级的但不紧急的请求，例如配额自动调整或坏节点检测，将以卷起的方式以固定的时间间隔（例如，每分钟一次）捕获。由于这些策略，高度命令性的项目可以获得更多的处理时间和即时响应，从而提高资源管理的有效性。
4、容错任务调度
不同的计算任务可以在Fuxi的资源管理框架之上实现。 在本文中，我们专注于一个特定的批处理数据流处理编程模型以及如何在作业调度中实现容错。 在接下来的部分中，我们将首先展示Fuxi工作模型的概述，然后讨论两种技术：用户透明故障恢复和多级黑名单。 最后，我们分享了我们在实际优化方面的经验。
（1）整体回顾
Fuxi Job使用DAG（有向无环图）来呈现一般用户工作流程，类似于 Tez 和 Dryad 等其他系统。 配置Fuxi DAG工作非常简单。 该框架接受JSON文件作为工作描述。 我们以下图为例来解释工作描述。 JSON文件有一个字段“任务”，它描述了每个任务的属性，包括可执行二进制路径和其它用户自定义参数。 字段“管道”描绘了所有数据，每个数据具有与任务相关联的“源”和“目的地”接入点。 圆形数字澄清了右侧JSON le和DAG gure之间的对应关系。 用户使用Fuxi Job SDK和编程API嵌入他们的任务逻辑。 对于 data shuffle，我们将公共数据运算符（如sort，merge-sort，reduce）封装到一个名为 Streamline 的库以及已发布的SDK中。 该库可以方便Fuxi的使用来定制作业的用户逻辑。
伏羲工作模式的设计主要考虑因素是容错。我们设计了用户透明的故障转移方案来处理 Fuxi Master 或 Fuxi Agent 崩溃的故障。我们还设计了 Job Master 来恢复所有的实例状态，包括 Job Master重新启动时正在运行的实例。此外，还采用多级黑名单策略来处理一般的机器故障，如磁盘挂起、网络断开等。
（2）任务执行
我们提供了大量的命令行工具供用户操作。作业执行的整个生命周期包括以下阶段，除了用户启动和停止作业外，所有这些阶段都是全自动的。
Job 提交：用户应首先根据Fuxi SDK中定义的接口函数编写具体的任务逻辑代码。此后，用户代码被编译并构建为包含在gzip文件中的可执行二进制文件。然后将包装上传到Fuxi系统。准备之后，用户可以将具有JSON文件描述的作业提交给FuxiMaster。接着工作生命周期从此时开始。
Job Master 启动：当收到作业提交时，FuxiMaster会调度可用的 FuxiAgent 以启动 JobMaster 进程并将命令发送给它。选定的 FuxiAgent 将快速启动 JobMaster流程，该流程将向 FuxiMaster 报告作业运行状态。
Instance 调度：JobMaster 解析作业描述后，它将通过资源协议从FuxiMaster请求适当的资源。该请求包含机器级别首选项和群集中的任意计算机。根据FuxiMaster提供的资源，JobMaster 确定要执行的任务以及相应的 TaskMaster 开始计划其实例。在调度期间考虑数据位置和负载平衡。当在实例或机器中发现故障时，TaskMaster 将重新调度实例以容忍磁盘错误或网络拥塞。
Job 监控：所有 TaskWorkers 将定期向 TaskMaster 报告其状态，包括执行进度。用户还可以通过命令行工具从 JobMaster 查询整个作业状态。 此外，为了便于故障诊断，实例故障细节被封装在报告的状态中。
（3）容错
从作业执行的角度来看，故障可以分为三类：a）FuxiMaster，FuxiAgent和JobMaster过程失败，可能导致整个工作失败; b）机器或网络故障，导致其上运行的实例出现故障; c）由于硬件和/或软件性能下降而导致实例长尾。
1）用户透明的故障恢复（User Transparent Failure Recovery）
Fuxi系统中的所有角色，包括FuxiMaster，Fuxi-Agent 和 JobMaster都可以支持用户透明的故障转移。在这里，我们描述了详细的设计和实现。
FuxiMaster 故障转移： FuxiMaster作为中心管理点对系统整体可用性有重大影响。我们采用典型的热备份方法，在集群中启动两个FuxiMaster流程，以获得高可用性。通过使用在飞天锁服务上的分布式锁，这两个 Master 是相互排斥的。抓取锁的Primary Master 将负责重新调度源，而另一个Master处于待机状态。当 Primary FuxiMaster崩溃时，备用设备将立即抓住锁并成为新的 Primary Master。
为了重建整个资源调度结果，Fuxi-Master需要在崩溃之前检查所有状态的checkpoint。另一方面，所有状态的完整record checkpoint 都会严重影响FuxiMaster的调度性能。为了减少状态簿记的开销并加速状态恢复，我们将状态分为硬状态和软状态。只有作业描述和集群级别机器黑名单等硬状态才被一个轻量级的checkpoint记录。checkpoint 仅在提交或停止作业时执行。在FuxiMaster故障转移期间，运行时会从所有 FuxiAgent 和 Application Master 收集软状态。下图描述了 FuxiMaster 经历故障转移时的必要信息。仅从 checkpoint 加载应用程序配置，而其它计划资源信息全部从 FuxiAgent 和 Application Master 收集。每个Application Master将其ScheduleUnit配置、资源请求和位置首选项重新发送到 FuxiMaster。同时，每个FuxiAgent为每个Application Master 重新发送该机器上的资源分配。 FuxiMaster将使用上述信息重建调度状态，从而保持所有资源分配和现有进程稳定。此外，Application Master 将在整个故障转移期间保留已分配的资源。
FuxiAgent 故障转移：FuxiAgent 也支持透明故障转移。在故障转移期间，FuxiAgent首先收集先前启动的运行进程信息，然后从每个相应的 Application Master 请求完整的 worker 列表。在 FuxiMaster 为每个应用程序提供的完全授权资源量之后，FuxiAgent 将在故障转移之前重建完整状态。
JobMaster 故障转移：JobMaster 进程崩溃可能导致整个作业失败。因此，JobMaster 必须支持具有数千台商用机器的真实集群中的用户透明故障转移。对于故障转移，JobMaster会导出所有实例状态的 snapshot。snapshot 的导出由任何实例状态改变的事件执行，因此它为 JobMaster 实例调度带来非常小的开销。这种 job snapshot 也是轻量级的，因为只记录“运行”等状态。当JobMaster进程重新启动时，它将首先加载实例状态的 snapshot，从TaskWorker收集状态，并在崩溃之前最终恢复内部实例调度结果。在没有JobMaster进程的情况下，所有 worker 仍在不间断地运行实例。对于长时间运行的实例，这种透明的主故障转移非常有用。
2）故障节点检测和多级黑名单机制（Faulty Node Detection and Multilevel Blacklist Mechanism）
部分故障或性能下降是应用程序难以处理的，并且可能导致最佳的长尾执行或最终导致整个集群崩溃的级联故障。我们设计了一个多级机器黑名单，以从资源调度中消除这种机器。在集群级别，我们在每个 FuxiAgent 和 FuxiMaster 之间保持心跳，以指示每个集群节点的运行状况。一旦 FuxiMaster 发出心跳超时，FuxiAgent 将从调度资源列表中删除，并且资源撤销将发送到JobMaster，以便 JobMaster 可以从超时 FuxiAgent 迁移正在运行的实例。我们还引入了一个插件方案，用于从操作系统收集硬件信息，以帮助判断机器运行状况。磁盘统计信息，机器负载和网络 I/O 信息均被收集以计算分数。一旦某个机器长时间得分太低，FuxiMaster 也会将机器标记为不可用。使用此插件架构，管理员可以向列表中添加更多检查项并自定义指定的错误检测。在作业级别，JobMaster 将根据 worker的状态以及FuxiAgent收集的故障信息估算机器运行状况。估计也以多级方式执行。特别地，如果在计算机上报告一个实例失败，则该计算机将被添加到实例的黑名单中。如果某台机器被一定数量的实例标记为坏机器，则该机器将被添加到任务的黑名单中，不再被此任务使用。在不同的作业中，如果同一台机器被不同的JobMasters标记为故障机器，FuxiMaster会将此机器变为禁用模式。为避免滥用此故障机器检测和黑名单，可以配置上限。
为了处理长尾实例，我们还采用了备份实例模式，当发现原始实例运行速度比其它实例慢得多时，它将启动具有相同输入数据的另一个实例。备份实例方案有三个标准。首先，大多数总实例（例如，90％）已经完成，在这种情况下，长尾实例的判断和平均实例运行时间的估计可能是有意义的。其次，长尾实例必须已经运行了几倍于从完成的实例估计的平均实例运行时间。最后，由于输入数据有时偏差，实例可能真的运行很长时间。要将此类实例与长尾区分开，用户还应在配置作业描述中的备份实例架构时指定实例的正常运行时间。
（4）大规模处理
大规模工作面临的挑战有两个原因：在考虑最佳数据局部性和负载平衡的同时调度大量实例的性能，和大规模实例之间的大量小型文件。在本节中，我们将介绍几种用于在生产环境中扩展作业框架的技术。为了解决规模问题，我们在 Fuxi Job 框架中设计了一个两级分层调度模型。从技术上讲，每个作业只有一个 JobMaster 对象，它负责高级任务调度。 JobMaster首先解析工作描述并分析shuffe管道以确定任务拓扑顺序。每次只安排输入数据就绪的任务，然后执行。 JobMaster与FuxiMaster进行通信以进行资源协商，并与FuxiAgent进行通信以启动/停止worker。此分层模型如下图所示。当JobMaster打算执行任务时，会创建一个单独的TaskMaster对象。 TaskMaster将执行细粒度实例调度以确定执行每个实例的工作者。对于实例调度程序，我们设计了一个考虑以下因素的高效算法：
a）将实例安排给具有最多本地输入数据的 worker；
b）将实例统一安排给可用的worker，从而使计算和网络负载平衡；
c）通过每次仅扫描未分配的实例来递增地执行调度。
实验中我们观察到，花费不到3秒来安排10万个实例，这证明了所提出的调度算法的有效性。 然后将计划的实例发送到实际执行实例的计划任务 worker 程序。 总的来说，我们设计了一个分层的作业调度模型，它解耦了DAG任务调度和任务实例调度，有效地加强了任务执行的并行性。 实验结果表明，该模型对大规模工作具有重要意义。
参考论文：《Fuxi：a Fault-Tolerant Resource Management and Job Scheduling System at Internet Scale》
