如何解决生物信息大规模计算的问题

前言

生物信息的一个重点就是数据的处理与分析，随着基因行业在临床和科研方面的应用逐渐加深与扩大，样本数量的越来越多，加之分析过程本身也是高并发的过程，如何快速、高效、准确的获得分析结果变成了一个问题。为了应对这个问题，我们需要大量的机器去处理这些作业。当你有一台机器，你可以随时看着这台机器是不是可以继续投递任务，但是拥有一千台甚至是一万台机器的时候，那就已经超出了你的能力程度了。

针对生物信息的计算需求，GeneDock开发了Flash分布式调度平台（简称Flash），它承担了平台的基因分析任务的管理，调度和监控。

特点

Flash针对生物信息高并发、多框架的特点，具有以下特点。

- 多框架：为了更加灵活的接入多种计算框架，Flash采用了双层调度：第一层，由作业调度中心（Dispatch Center）统一资源调配，通过筛选后选择合适的计算框架（Slave）给作业；第二层，框架通过自身的调度器将资源分配给作业。
- 高扩展性：大多分布式计算框架都具有其高可扩展性。在双层调度的特性下，作业调度中心的统一资源调配不会影响到各框架自身的扩展性。
- 容错性：大规模的计算环境下，容错是保证系统高可用的一个保障。在各框架自身的容错性能下，作业调度中心会通过检测各框架的心跳及时掌握框架的实时状态，同时各框架的服务也通过主备模式保证服务的高可用性。
- 安全与隔离：Flash各框架之间是完全隔离互不影响，各服务之间使用grpc通信并使用docker化部署。各框架执行器使用docker执行用户任务，保证资源的隔离与互不干扰。

总体架构

图1 Flash架构图

用户通过Client/API向任务解析层提交一个完整的任务描述，通过任务解析层的DAG解析与资源预估，进入作业调度中心进行框架的选择，获得可运行框架的信息并向框架提交作业。框架接收到作业后通过自身的资源管理器和调度器将作业分发给框架的执行器。

双层调度策略

图2 双层调度策略示意图

作业调度中心

作业调度中心管理所有框架的使用和生命周期，对所有框架的资源进行统一的调配。

作业进入调度中心后，通过指定的框架名称（Framework Name）、依赖作业的运行框架（Dependency Filter）、cpu、memory、磁盘类型（disk type）、是否需要网络（network）等筛选出可选运行的框架。其中依赖作业的运行框架的筛选可以保证数据的Locality，减少跨框架使用数据资源的发生，提高运行效率。

框架自身调度模块

每一个框架接入时会根据自身的特性实现或接入一个调度模块，解析作业描述、管理和调控框架自身的计算资源。

框架接收到作业后，通过自身的调度模块，通过对cpu、mem等（各框架有所差别）申请计算资源，选择合适的机器执行作业。

计算节点的执行器接收到作业后，一般会进行以下动作：

- 作业初始化： 主要包括 Docker Image 的下载，运行数据的下载
- 用户作业命令执行： 启动容器并执行用户提供的命令
- 作业资源回收： 主要包括上传作业产出数据，作业运行日志，执行器日志，资源监控数据，作业报告数据等

高扩展性

框架扩展

双层调度使得我们可以接入不同的计算框架，实现框架层的扩展。目前我们已经实现ECS框架和DIKU ON ECS框架。

计算资源的扩展

计算资源的扩展取决于框架自身的扩展性能。好的扩展性能，计算框架的资源增加对系统行为产生极小的变化。例如我们ECS框架借助高效的队列服务，降低了服务的通信开销，增加了任务的处理速率，使得资源的水平扩展获得了极大的提升。

容错性

系统发生错误时，系统有对错误进行规避和恢复的能力。大规模的计算环境下，机器的故障会是一个常见的问题，这些故障包括机器的硬件与软件等多个方面。

框架层的容错

由于机器故障，经常会导致框架服务的不可用，我们通过以下两点解决这种问题：

1. 作业调度中心通过ZooKeeper Watcher机制及时掌握各机器的健康状况，当出现服务不可用时，会及时保存作业信息，等待服务的恢复。
2. 我们通过服务的主备模式，实现服务的自动恢复：

图3 主备模式主动恢复服务示意图

1. 无故障情况下，框架有一个主服务和多个备服务，主服务负责正常的rpc通信和处理，备服务只用来监控主服务的状态。
2. 当主服务出现故障不可用时，框架短暂出现为不可用状态，各备服务也发现主服务的不可用。
3. 备服务通过选主，产生新的主服务，新的主服务恢复相关数据并开始正常的rpc通信和任务处理。

框架内容错

各框架实现自身的容错机制：

1. 当执行器节点出现故障时，可以批量重试改节点的所有作业
2. 当执行结束后，通过退出码可以判断某些作业的失败原因，并且判断是否该作业需要重试

安全与隔离

Flash平台运行的作业，来自不同的用户的临床数据，所以作业运行的安全与隔离就尤为重要。

通信安全

Flash所有服务的通信通过grpc，保证通信的安全、快速。

框架的隔离

框架与框架之间相互独立，框架只通过grpc与作业调度中心进行通信，各框架可以是一套单独的通信、运行、存储系统，互不影响。

执行环境的隔离

作业的最终执行都在容器中，通常我们使用docker容器执行作业，docker在资源隔离、快速迁移、秒级启动等多方面的性能完全满足我们对执行环境的隔离需求。

docker registry的安全性

GeneDock将自身的鉴权系统接入到registry当中，用户可以安全的操作自身的docker镜像。

展望

Flash平台的基本功能都已经实现，但是后续在各方面性能都还有很大的提升价值

- 跨框架的重试：当作业在框架内重试失败时，根据失败原因，可以进行跨框架的作业重试
- 接入更多的框架：根据生物信息的计算需求，可以接入常用的sge、torque、Hadoop等计算框架
- 更大规模的计算资源：不断延伸框架的扩展性，实现更大规模的计算资源调度
- 作业资源估计：随着作业数的越来越多，通过机器学习实现更加精确的作业资源估计
- 更加丰富的可视化功能：满足用户对作业运行时或运行后的可视化需求

阅读原文：https://www.genedock.com/blog/2017/03/25/20170325-flash/