基于容器的科学工作流云计算平台＊

代强，赵亦辉

(成都中蓝信息技术有限责任公司，四川 成都 610041)

0 引言

科学数据量正在迅速增长。科学研究显然具有工具依赖性，例如用于基因组研究的下一代测序（NGS）。云平台已成为进行科学分析的有前途的解决方案，因为它们能够提供强大、弹性和经济的存储和计算能力[1]。由于云平台的灵活性，科学家能够根据需要构建自己的数据分析平台。科学工作流程是一个使用多种科学工具的数据处理管道。这些由不同编程语言开发的工具依赖于大量的库、二进制文件和配置文件，导致了很多的工具安装问题。当工具缺乏文档或多个工具有冲突的依赖关系时，情况会更令人失望。此外，如果我们考虑操作系统、库和工具版本，那么再现整个工具执行环境是非常具有挑战性的。

一些研究[2-4]发现，容器技术，如Docker[5]，是解决科学工具依赖性问题的一个很好的解决方案。通过将所有依赖项打包到Dockerimages 中，工具安装过程将不那么痛苦。同时，它保证了良好的再现性。

许多科学工作流程系统如Galaxy[7]和Nextflow，被提出来帮助科学家定义、提交、监控和管理科学工作流程。多亏了这些系统，科学家才能够专注于他们的研究问题而不必担心工作流执行机制的细节。然而，对于科学工作流程系统来说，工具安装的问题是大问题，因为科学家需要运行不同的工作流程，其中包括大量的科学工具。Galaxy 支持Docker 来解决这个问题。然而，它只在单个计算节点上运行容器，这显然限制了计算能力。为了充分利用可用的计算资源，我们应该能够以可扩展的方式在多个节点的集群中运行容器化的科学工具。

容器集群系统，如Kubernetes，帮助用户在多个节点的集群上运行容器。然而，大多数现有的科学工作流系统都不适用于容器集群系统。一些使用容器集群系统的工作流系统依赖于它们自己的专有执行引擎[2-3]，而其他工作流系统则在不支持容器技术的传统集群系统上运行任务[7]。

在本文中，我们建议使用容器集群系统作为科学工作流系统的执行引擎，这带来了很多好处。首先，它解决了科学的工具安装问题。我们可以将科学工具打包到Docker 映像中，然后在下载相应的映像后，可以在容器内的任何启用Docker 的主机上运行这些工具。其次，它保证了高水平的科学再现性，因为Docker 镜像保证了相同的工具执行环境。第三，基于容器的方法提高了资源利用率。此外，容器集群系统可以同时运行MapReduce 或Webapplication 等其他任务，这将大大提高整个集群的总体资源利用率。

为了研究利用容器集群系统作为科学工作流系统执行引擎的可行性，我们开发了原型平台，我们的初步评估结果表明，容器集群系统为数据密集型工作流引入了微不足道的性能开销，考虑到其巨大优势，使其成为科学工作流的一个有前途的执行引擎。

1 背景和相关工作

1.1 科学的工作流程系统

科学工作流是一种使用多种科学工具的数据处理管道，通常表示为有向无环图（DAG），其中节点表示数据处理任务，边表示数据流。基因组测序中使用的工作流程如，RNA Seq，包括科学工具，TopHat 和Cufflink。组成科学工作流程的科学工具是使用不同的编程语言[16]开发的，它们依赖于大量的库、二进制文件和配置文件。因此，安装和配置科学工具对科学家来说很重要，因为他们不是计算机专家。

在生物学和天文学等各种科学界，有很多科学工作流程系统，旨在帮助科学家定义、提交、监测和管理科学工作流程。例如，Galaxy[7]是一个用于基因组研究的基于Web 的工作流系统。AWE/Shock 由一个对象存储系统和一个专有的执行引擎组成，它也是一个专注于运行生物信息学管道的工作流系统。使用Nextflow 编程模型，科学家能够轻松创建并行的科学管道。对于Pegasus，来自多个领域的科学家已经使用了十多年。科学工作流程系统通常为用户提供图形编辑器或编程脚本来定义和提交他们的工作流程。至于工作流的执行，大多数工作流系统都能够将任务提交给传统的集群资源管理系统。例如，HTCondor可以用作Galaxy、Nextflow 和Pegasus的执行引擎。其他工作流系统如AWE/Shock，都有自己的专有执行引擎。

1.2 容器集群系统

与虚拟机技术相比，容器技术是一种更轻量级的虚拟化技术，它还能够隔离应用程序。在同一主机上运行的多个容器与主机共享同一内核，而共存的虚拟机运行其独立的内核。因此，容器技术能够提供接近本机的性能、更高的密度和更快的启动/停止时间。Linux 内核功能，如Namespaces 和Cgroups，是容器技术的重要构建块。命名空间是将容器与主机和其他容器隔离开来的关键，而C 组可以限制容器的CPU 和内存等主机资源的使用。尽管容器技术已经存在了十多年，但直到近几年，随着名为Docker 的容器工具的普及，它才越来越受欢迎。

事实上，Docker 已经成为业界广泛使用的事实上的标准容器工具。通过使用Docker，我们可以方便地创建、停止、重新启动和删除容器。这种良好的用户友好性为Docker 的成功做出了很大贡献。将应用程序及其依赖性打包到轻量级Docker 映像中的能力是Docker 的另一个高级功能。我们可以下载Docker 镜像并在任何启用Docker 的主机上运行应用程序，而无需担心费力的安装步骤。这对我们解决工具安装和云部署问题有很大帮助。容器集群系统彼此非常不同，但他们都有一个主/从体系结构。主节点将容器调度到从节点，从节点负责执行容器。例如，谷歌在Borg上运行了近十年的内容，包括网络搜索、Gmail和谷歌文档。因此，容器集群系统也可以用于运行科学工作流程。

2 平台体系结构

2.1 科学计算平台

本文讨论的科学计算平台由科学工作流程系统、容器集群系统、存储系统和各种科学工具组成。科学家使用科学工作流程系统来提交、监控和管理他们的工作流程。组成工作流的科学工具将在容器内执行，容器集群系统负责调度和执行这些容器。所有输入和输出数据都存储在存储系统中。

所提出的体系结构，利用容器集群系统作为科学工作流的执行引擎。像Skyport 这样的现有系统将工作流系统和执行引擎紧密耦合，而我们的平台则将工作流系统与执行引擎解耦。工作流系统和执行引擎的解耦大大提高了科学计算平台的灵活性；也就是说，用户能通过熟悉的工作流系统和合适的容器集群系统来运行他们的工作流。

理论上，除了具有特定硬件要求的工具（例如，高RAM）外，我们提出的平台能够运行几乎任何类型的科学工作流程。此外，与其他工作流平台不同，我们的平台上不需要预先安装任何科学工具或其依赖性。科学工具在容器中运行，可以在计算集群的任何节点上进行调度。如果没有容器，任务可以在安装了所需工具的特定节点上运行。

由于系统的复杂性，在云上部署或复制科学计算平台是非常具有挑战性的，尤其是对于缺乏计算机技能的科学家来说。为了解决云部署问题，所提出的架构在Docker 容器中运行整个平台。由于容器技术的强大可移植性，该平台可以在任何云上创建，而不会出现供应商锁定问题。

事实上，有许多科学工作流程系统在不同的科学界很受欢迎。对于容器集群系统，我们也有很多选择。对于存储系统，共享文件系统、对象存储系统或其他存储系统也可以是候选系统。最终，我们计划为各种选择提供支持，然后科学家将有充分的灵活性来选择和组合他们喜欢的组件，以在云上构建定制的科学计算平台。选择合适的容器集群系统可能会显著影响用户应用程序的性能。

2.2 Galaxy工作流科学计算平台

作为案例研究，我们选择了广泛使用的生物工作流系统Galaxy 来构建原型平台。Galaxy 为科学家提供了一个网络界面来定义他们的工作流程。四个广泛使用的容器集群系统充当执行引擎。所有科学工具都在Docker容器中运行。目前，我们使用NFS 作为存储系统，并计划在未来的工作中尝试其他存储系统来提高可扩展性。

为了研究利用容器集群系统作为科学工作流系统执行引擎的可行性，我们将Galaxy 与Docker Swarm、Kubernetes 和Mesos/Aurora 三个通用容器集群系统集成。此外，我们还支持HTCondor，这是一个在HPC 社区广泛使用的传统集群系统。HTCondors 最近支持Docker。

我们在Galaxy 中实现了四个作业运行程序作为容器集群系统的接口。作业运行程序负责提交，监控和删除相应容器集群系统上的作业。将作业提交到不同容器集群系统的能力提高了我们平台的灵活性。此外，对这些容器集群系统做比较对于促进容器集群系统在科学工作流方面的应用也很有价值。

2.3 Docker的实现设置

我们实现了两个选项来运行容器中的所有内容，Docker in Docker 和Sibling Docker。我们还实现了两种在没有容器的情况下运行集群从机的选项，即Docker 中的Tool 和without Docker，以研究容器化一切的灵活性和开销。

⑴ Docker中的Docker：对 于Docker 的Docker，clusterslave 容器直接在主机上运行，而科学工具容器在slave 容器内运行。运行在主机上的Docker 守护进程启动集群从容器，而运行在slavecontainer 内的Docker 后台进程负责管理科学工具容器。集群从进程请求内部Docker守护程序启动、监视和删除科学工具容器。我们不限制从属容器的资源使用，例如CPU 和内存，这意味着从属容器能够消耗尽可能多的主机资源。Docker 中的Docker 通过引入两层Dockerization，有效地解决了集群从属和科学工具的部署问题。Docker 中Docker 比Sibling Dockersion 更容易实现，因为它是Docker 原生支持的，尤其是在Docker 1.8.0 之后自动安装到容器中的Cgroupsis。事实上，Docker-in-Docker 方法最初是在虚拟云提供商（VCP）项目[6]中提出的，它是我们平台在容器中运行一切的直观方法。

⑵ Sibling Docker：Sibling Docker，集群从属容器和科学工具容器在主机上并排运行，即从属容器和科技工具容器都在同一台主机上运行。只有一个Docker 守护进程在主机上运行，它负责管理从属容器和科研工具容器。通过使用Docker 卷或环境变量将Docker RemoteAPI 端点（即Unix 套接字或TCP 套接字）映射到从属容器，来自clusterslave的所有容器管理请求都将发送到外部Docker 守护进程。因此，科学工具容器是由外部Docker 守护进程启动的，而科学工具容器直接在主机上运行。与Docker中的Docker一样，我们对slavecontainer 没有设置资源限制，因此主机的所有资源对于集群slave都是“可见的”，科学工具容器能够确保所有主机资源。从用户的角度来看，Sibling Docker 的工作原理与Docker 中的Docker 相同，因为它们都在容器中运行集群从属工具以及科学工具。Sibling Docker 只能部署在安装了特定版本Docker 的主机上，这使得Sibling Docker 方法的可移植性不如Docker方法中的Docker。

⑶Docker 中的工具：当只有科学工具在Docker容器中运行，而集群从机直接在主机上运行时，我们将其命名为Docker 中工具。主机上的Docker 守护进程会实例化工具容器，以响应集群从机的请求。对于Docker 方法中的Tool，我们不必担心工具安装问题，因为所有容器都在基于相应Docker 映像的Docker 容器中运行，其中已经打包了科学工具及其依赖项。这大大提高了平台的灵活性，因为我们可以在任何节点上运行几乎任何科学工具，而无需在这些节点上安装任何工具。然而，我们必须手动安装和配置容器集群系统，这通常是有挑战性的。根据我们的实验经验，安装容器集群系统，包括Docker Swarm、Kubernetes、Mesos/Aurora 和HTCondor，由于其大量的依赖性、多个系统组件、复杂的配置文件和准确的文档，所以非常困难。此外，当我们想要在云上部署或复制平台时，这种方法会引起很多麻烦。总之，在容器中运行科学工具有很大好处，但仅仅将科学工具容器化并不能解决本文讨论的问题。

3 结论

容器技术是解决科学计算平台依赖性问题的理想技术，其近年来越来越受欢迎。像Docker Swarm这样的容器集群系统，由于其固有的性能和巨大的灵活性，是科学工作流系统的有前途的执行引擎。此外，通过利用容器技术，我们可以在几分钟内轻松地在任何云上部署您的科学计算平台。根据我们的实验结果，Docker 中的Sibling Dockeran 和Docker 的性能几乎相同。得益于它的完全封装，Docker 中的Docker 比Sibling Docker 具有更好的可移植性。而对于Sibling Docker 来说，它只引入了一层Docker 虚拟化，可简化容器管理。因此，必须在更好的可移植性和更容易的管理之间进行权衡。