内容


将并行处理大规模生物信息的管道应用移植到云上

一个转移、稳定和管理大量数据集的案例分析

Comments

该项目的目标是为了实现一个商业基因分析应用程序,可以获得极大的可扩展性并控制相关成本。该应用程序已被设计出来,内部运行在高性能计算 (HPC) 类的基础架构上,而且该基础架构的容量即将达到其限制。同时,分析量预计会迅速增加。因此,人们希望尝试将应用程序移植到云环境中。

另外,时间限制阻止了我们重新设计原始应用程序的可能,只允许我们对应用程序的组织方式进行较小的改变。我们首先将从 IT 角度简要概述计算基因组学产生的问题。

了解生物体基因组序列的常规方法涉及到以下步骤:

  1. 将原始基因组的多个副本(通常为 30-60 个)分解成大量随机重叠的片段 (fragment),每个片段都有固定的长度(例如,30-200 个碱基对)。
  2. 读取每个短片段的序列,这会产生大量的小文件。
  3. 使用之前已了解的生物体基因组(“参照基因组”),对参照基因组上每个序列片段的位置进行最佳猜测。这似乎是一种合理的方法,因为每个物种的基因组通常没有太大区别。
  4. 使用统计方法确定重组基因组每个位置上最有可能的碱基对。鉴于数据压缩之目的,可以采用 deltas 的形式表达该方法:单核苷酸多态性(表示给定位置的基因突变),或者插入或缺失(indels),表示整个基因组长度发生了变化。

因为基因组非常巨大(例如,人类基因组的长度为 33 亿个碱基对),所以二级分析意味着大量的计算和数据挑战。在考虑使用读质量数据 (read-quality data) 时,每个传入的碱基对都是通过 1 字节的信息进行编码的。因此,包含 60 个碎片(完整 DNA 分子)的传入数据集大约将包含 3.3*109 * 60 或 200GB 左右的数据,假设在 CPU 和存储媒介之间有大量聚合的 I/O 连接性,内核计算时间大约是 500 到 2,500 个小时。

过去,处理这类问题属于超级计算机或 HPC 范围内的事。需要使用一个快速的大型中心文件系统;输入数据集也应放在该系统中;而参与其中的大型无状态服务器场将执行此项计算。

虽然处理这样一个数据集看上去像是很容易管理,但在合理的时间范围内处理成千上万这样的数据集却是一个挑战。其中的一个限制因素是:随着基因组序列成本的不断下降而导致的需求增长,构建和运营大量处理系统所需的资本投资将持续增长。

出于这个原因,云计算成为一个极具吸引力的模式。它能够提供大量具有可变定价的计算能力,并且可以根据需要来租用服务器,不需要的时候将其返还。但是,要充分利用云,必须克服以下难题:

  • 数据需要高效地通过 WAN 在云上往返传递,并且需要使用适当的工具集。
  • 需要选择云存储产品类型的恰当组合,因为云不可能提供快速的、昂贵的 HPC 类型存储。
  • 作业编排需考虑存储结构和相应的扩展。
  • 基本的水平云扩展模式须体现在基础架构中。
  • 如果可能的话,必须选择云硬件、软件和虚拟化的最佳组合。

本文其余部分的结构如下:

  • 简介:提供相关工作的概况并介绍其他背景知识。
  • 第 2 部分:介绍 IBM® SmartCloud™ Enterprise 的基础知识。
  • 第 3 部分:介绍我们为移植系统选择的系统基础架构。
  • 第 4 部分:介绍结果并提供现状基础架构与可替代物之间的比较。
  • 第 5 部分:讨论结果并汲取教训。
  • 结束语:描述潜在的未来工作方向并总结本文要点。

目前,一些云供应商可以采用即付即用的模式提供大量计算功能。在某些情况下,为了确保与工作负载的一致性,客户可以选择使用底层硬件。

所以,最近几年也有一些被设计为在云中运行的基因组工作流的成功示例。这些研究人员选择使用的方法是:选择一个云系统(如,Amazon Elastic Compute Cloud, Amazon EC2),按 “原样” 处理它,并对应用程序进行深入改进,以便利用云计算的强大功能。

我们的工作实质上在以下几个方面有所不同:

  • 我们在工作时间范围内改变原始应用程序的能力是有限的。虽然这种限制肯定会产生设计瑕疵,但我们认为这很常见。
  • 由于主要关注点是总成本,所以通过追踪数据字节,试图确保它们以最短的距离进行传输,并关注性能,识别和消除所有瓶颈,我们可以进行近乎全面的设计。
  • 我们在 IBM SmartCloud Enterprise 中处理本文提出的所有工作。因为我们与支持和开发 IBM SmartCloud Enterprise 的团队保持密切联系,所以我们有一个将云的基础架构视为白盒子 (white box) 的特殊机会,并使用这些信息作为操作指南。
  • 我们能够进行调优云配置的试验,以便将来更好地支持这类数据密集型工作负载。

总而言之,在我们的脑海中,许多数据密集型应用程序都是使用自定义的昂贵的超级计算机或 HPC 集群编写的。希望我们的体验和决策制定过程对那些试图增加稳定性并降低应用程序所支持的任务的处理成本的人们有所帮助。

介绍云环境

IBM SmartCloud Enterprise 是一个虚拟化的基础架构即服务 (IaaS) 产品,支持用户在即付即用模式下借用资源,并以小时为单位给大部分资源进行定价。其计算节点将 Kernel Virtual Machine (KVM) 用作虚拟机管理程序和直接附加硬盘,为其虚拟机 (VM) 提供具有最佳性价比的临时存储。此外,IBM SmartCloud Enterprise 提供了每次可以附加到某个 VM 的网络连接存储块存储器。VM 以 1Gbps 的速度与块存储器和虚拟机进行连接。

IBM SmartCloud Enterprise 由多个位于世界各地的数据中心(称为:pod)组成。在许多情况下,只需要在一个 pod(即离数据资源最近的 pod)上安装可部署拓扑。但是,多 pod 拓扑并不常见,因为数据可能来自世界各地,而且 pod 的有效容量也有所不同。

IBM SmartCloud Enterprise 提供了几种 VM,从 32 位 Copper 到 64 位 Platinum,并且每种类型都有按小时收费的不同临时存储分配。持久性(块)云存储在多个增量中也是可用的,并且可以按容量以及 I/O 每秒的操作次数来计费。IBM SmartCloud Enterprise 内外的数据传输也会根据流量产生费用。

在云堆栈中寻找机会

要最大程度地降低处理成本,必须寻找堆栈中的机会。需要重点关注的区域是:

  • 云内外的数据传输。这些数据通过 WAN 传输并且十分昂贵。实际传输的数据量很重要,会导致与网络错误、处理实时数据集能力、网络延迟(进行长距离数据传输时)、数据压缩和安全性有关的挑战。
  • 云中的数据传输。根据使用云资源和存储产品组合的情况,这些成本也不低。例如,您应该考虑计算节点的生命周期,确保它们不会闲置太长时间来等待完成开始执行计算之前的数据加载。
  • 云存储各层的结构。处理大数据时,必须将其分割成多个独立的层,而且每层可能具有不同的服务级别。图 1 描述了高级别数据流:所有的云存储层都是有弹性的,并且试用期较长的存储层显示为较深的颜色。数据通过 WAN 载入云中,然后通过 LAN 或 WAN 在存储层间移动(如果存储层位于不同地理位置上的云 pod 中)。
    图 1. 高级别数据流
    图形展示高级别数据流
    图形展示高级别数据流
  • 工作流编排。该编排必须是云感知的,并且会依赖所有存储层、数据传输、速度和故障恢复的结构等信息。
  • 云基础架构堆栈的优化。正如前面所提到的,需要针对大数据而优化云计算。

这些问题将在以下小节中详细介绍。

云中的弹性存储层

强加于存储系统的主要要求看上去很简单:长期存储数据时,需要采用比较便宜的存储,它应该能够支持弹性计算层(能在完成创建之后快速提供数据,并最大程度地缩短初始化时间),在计算期间,存储应该是快速同时也是安全的。

很明显,这些要求使得存储必须选择一个多层基础架构,因为没有一个存储层可能满足上述所有要求(参见 图 1)。

这是我们使用的三层结构法:

  • 长期存储层。长期存储基于一组永久存储卷(每个 2TB),对基因组输入数据和结果进行存档。此处的目标是最大程度地降低成本。提供较低数据吞吐率和最低总存储成本的相对较大的存储量是通过廉价的 32 位 Copper 进行挂载的。根据使用案例,该层可支持 WAN 上的数据传输。或者,可以使用它来备份临时数据缓存,因为丢失任何 VM 都不会对其造成什么影响。图 2 演示了后者的运行场景,在这里,存储层由几个 32 位 Copper VM 组成,并且每个 VM 都附有一个 2TB 的存储块。在以前,一个 VM 只可以附加一个存储快。我们进行了将存储块聚集到一个连续空间中的试验,但通常我们会避免这样做,因为我们喜欢简单一些。
    图 2. 长期存储层
    图像显示了长期存储层
    图像显示了长期存储层
  • 临时数据缓存。因为使用了分布式文件系统 General Purpose File System-Shared Nothing Cluster (GPFS-SNC) 和中型实例的临时存储,所以该层既有良好的性能,又具有成本效益。通常使用该层通过 WAN 接收数据传输,并通过使用并行数据传输为计算层提供高吞吐率。此外,我们可以水平扩展该层,以适应更多的存储空间或更高的性能要求。我们通常习惯使用 64 位的 Bronze VM,每个有 0.85TB 大小的临时磁盘和 2 个复制因子,用于确保组成该层的所有 VM 中都不会出现故障。
    图 3. 数据缓存和运行时集群存储
    图像显示了数据缓存和运行时集群存储
  • 计算集群(运行时)存储。在计算期间,我们更改了应用程序,以便在临时数据的每个计算节点中(几乎完全)使用直接本地附加的存储。在该层中,我们通常使用 64 位的 Gold VM,而且每个 VM 都有 1TB 的临时存储。因为原始应用程序要求使用连续的可寻址存储空间,所有我们使用 GPFS-SNC 对其进行模仿。对该层进行优化,以提高性能,从而不必再进行复制。如果任何 VM 出现故障(小概率事件),我们只需删除集群并从头开始重新计算。请注意,该存储层最为昂贵且最具弹性,因为它可能在瞬间消失(参见 图 3)。

云内外的数据传输

在我们进行这项工作时,IBM 云中并没有提供共享对象存储服务。但是,在我们确定通过 WAN 传入的数据的目的是临时数据缓存之后(参见 图 1),我们意识到我们可以设计一个简单的解决方案,并以 Linux 平台提供的所有传统工具为基础。

我们仍需克服这些主要挑战,也就是说,最大程度地提高实际传送的数据量(采用数据压缩、重复删除等功能),最大程度地提高吞吐量而不考虑延迟,执行错误恢复,支持实时数据集和安全性。

有趣的是,我们观察到 Amazon Simple Storage Service (Amazon S3) 使用 HTTP 来传送数据(这不是最优机制),而它最受欢迎的界面却模仿自 rsync。其他解决方案是使用的是非 TCP 协议,比如 Hybrid SCP (HSCP),这是一个开源产品。用户还可以使用一系列商业解决方案。

原始输入数据实际上是短小的随机读取序列,就像是生物体的 DNA 片段,而且因为有很多这样的片段(接近 4fragment_length),所有我们认为这类数据自身很难实现重复数据删除。

根据使用网络模拟器进行的测试,我们发现使用 gzip 简单压缩数据可以降低所传输数据的大小。我们还发现,由于并行管道数量充足,并行的 FTP 能使网络宽带饱和。

我们最终选择使用 Secure Shell (SSH) 上的 rsync 作为 Data Transfer Utility (DTU) 的基础,并按以下步骤进行扩展:

  1. 我们创建了一个可产生多个可配置的并行 rsync 传输的层,让可用宽带达到饱和。
  2. 我们使用 UNIX®cron 工具实现了一个调度机制,该机制会重启故障传输(尽管源节点已被重启)。这还有助于我们处理实时数据集:rsync 知道会出现了哪些新文件,并且只传送这些文件。
  3. 我们为 DTU 创建了一个 “退出钩子 (exit hook)”,以便在一个或多个数据目标节点上执行指定命令,使端到端编排成为可能。

因为我们选择使用 rsync 作为底层引擎,所以 DTU 使用起来简单而又直观。例如,我们能让大部分 rsync 选项对过滤数据有效。

云中的数据传输

云中大数据的优化数据传输也会引起一些特有的问题。

首先,从根本上讲数据传输必须是并行的,并且符合 “多对多” 概念。这类似于上一节讨论的问题,但在该案例中事实证明,数据可能扩展到多个源和目标节点(参见 图 3),并且每个节点有一个最大宽带吞吐量(例如 1Gbps,和 IBM SmartCloud Enterprise 一样)。通过编排 N 源和 M 目标 VM 之间的数据传输,我们可以将最大吞吐量增加 max(N,M) 倍。

其次,要真正实现并行,数据传输系统需要了解并执行数据和 VM 之间的亲和性规则。换句话说,系统需要足够智能,能够计算任何数据子集的源和目标 VM 并编排其传输。

第三,传输机制必须是可靠的,而且能够在合理时间时间范围内从故障中恢复。任何云环境都包含其 VM 和网络的一定非零故障率。

第四,如果存储和计算系统群需要在地理上进行隔离,系统需要足够灵活,能够支持短距离 (LAN) 和长距离 (WAN) 传输。例如,当某个云 pod 正在维护而无法提供计算时,就会出现这种情况。

图 4 演示了一个案例,四个 VM 在源集群与目标集群之间相传输数据。存储直接附加到每个 VM 上(与 图 3 进行比较)。数据亲和性规则控制着源集群和目标集群中的数据分布,并阻止使用任何群内网络。四个数据传输都在无网关的情况下同时运行。

图 4. 4x4 并行文件传送
图像显示了 4x4 并行文件传送
图像显示了 4x4 并行文件传送

在将 Apache Hadoop Distributed File System 用于源和目标数据集群时,通常会使用 distcp 来加快数据传输。由于我们依赖于完全可移植操作系统界面 [面向 UNIX] (POSIX) 兼容文件系统在两端进行传输,所以最终决定使用 rsync 和 SSH 作为基础,实现一个自定义数据传输子系统。rsync 负责较快地恢复临时网络中断,并提供高级过滤功能,让我们能够强制执行数据局部性规则。SSH 提供了端到端的安全性。因为该机制是基于 TCP 的,所以,如果必须在 WAN 上强制执行该机制,则不会遭受灾难性的性能损失(在源和目标集群必须地理隔离时)。

工作流编排

整个过程实际上由完全不同的两个步骤组成:将数据加载到云中和从云中加载数据,以及云中的数据处理。

云中的数据交换

如前所述,我们设计并开发了一种独立的、基于 “组件化” rsync 的 DTU, 用它来处理云内外的数据传输。必须将 DTU 安装在每个客户服务器上,客户服务器挂载了包含原始输入数据的文件系统,并通过 UNIX cron 工具进行调度,以便监视所有输入文件的文件系统。

一旦发现新的数据集,DTU 就会通过一些并行 rsync 进程(执行数据推送)启动传输。完成传输后,DTU 会调用编排模块 Elastic HPC Service (eHPCs) 指示它现在开始处理数据。

图 5 描述了该流程。图中所有节点在传输时必须存在。DTU 连接到云中的一个冗余网关,该网关也可以充当云数据缓存存储集群的客户端。当活动网关收到数据时,它会将这些数据写入 GPFS-SNC 集群。因为传输正在进行,所以数据在存储缓存节点之间条带化。应注意的是,DTU 没有采用与其余编排工作兼容的方式实现 “数据到节点” 亲和力的智能方式。所以它依赖 GPFS-SNC 执行条带化。因此,需要执行额外步骤来实现此亲和力。我们尝试了包含或排除该步骤的情况。此外,我们还尝试了使用 GPFS-SNC 来促进这类数据传输。

图 5. 数据加载和准备
图像显示了数据加载和准备

在完成数据处理并将结果存入数据缓存层之后,DTU 将会获得数据并将这些数据拉入客户节点,同时还会整理数据缓存文件系统中的空间(未在图 5 中显示)。数据缓存层中的节点数最终会是一个数据处理吞吐量函数,我们可以手动扩展它。如果需要处理来自不同区域的数据,则需要将 “处理单元” 拓扑复制到离数据最近的 IBM SmartCloud Enterprise pod 上,因为处理单元之间是相互独立的。

云中的数据处理

虽然数据缓存层在传输开始前就应该已经存在,但在比较昂贵的计算层上并不是这样:您可以根据需要创建数据缓存层。据我们所知,工作量是不断变化的,所以弹性计算层的设计点对于我们的成本控制目标非常关键。

图 6 概述了云中的处理工作流:

  1. eHPCs 编排器提供了一个全新的计算集群。如果该策略支持集群重用,那么编排器将会使用闲置集群或调度繁忙集群上的工作流,除非队列已排满。
  2. 将输入数据加载到计算集群。
  3. 数据在计算集群中进行处理。由于有数据分区,所以此步骤中几乎没有网络流量,除了按如下所示移动数据时产生的流量。和输入一样,结果会在计算集群节点之间自动分区。
  4. 结果通过与亲和性规则一致的并行传输移动到数据缓存层。
  5. eHPC 可能会使集群崩溃,或者允许它一直闲置(即缓存它),具体情况取决于所用的策略。
图 6. 云中的处理工作流
图像显示了云中的处理工作流
图像显示了云中的处理工作流

图 7 侧重于数据片段,因为它们是在云中进行处理的。图中的深色表示节点。为了简便起见,所示的计算节点数量与数据缓存集群中的节点数是相等的。请注意,尽量简洁地实现数据到节点的亲和性规则,以便最大程度地减少网络流量。

得到所有片段的比对(按染色体和区域)结果后,我们需要计算新的亲和性规则,以便公平地重新分配节点间的染色体区域。完成数据移动步骤之后,节点将再次处于近乎自主的状态,每个节点只处理分配给它的片段。从概念上讲,该工作流类似于 Langmead et al.,只是不是 Hadoop 或 MapReduce 编排的。

图 7. 云中的数据流
图像显示了云中的数据流
图像显示了云中的数据流

弹性 HPC Sevice

之前,我们介绍了必须在云中运行工作流的基本问题,了解到工作流提交期间所需的计算集群可能是存在的,也可能是不存在的。因为这个问题并不适用于我们将要移植的应用程序或生物信息,所以我们开始着手定义和创建一个可以完成此任务的独立组件。我们将该组件称为 Elastic HPC Service,与基于 Hadoop 的 Amazon Elastic MapReduce (Amazon EMR) 进行区别。

我们的基本需求和基础架构原则是:

  • 组件应作为一个具有中立界面的服务来实现。
  • 它应支持多级工作流。
  • 服务应该提供多节点集群并在集群上运行工作流。
  • 服务应提供多种集群类型(例如,Hadoop、Platform LSF 和 Open Grid Scheduler)。
  • 服务应该是可扩展的,以便支持多种云类型。
  • 服务应该是轻量级的、直观的且易于使用的。

图 8 概述了 eHPC 对象模型,该模型只有四个主要对象。Job 对象是工作单元。它既有相关的可执行参数,也有输入输出参数。一个工作流可以包含一个或多个 Job 以及连接它们的逻辑。每个工作流必须指定一个需要运行的 Cluster集群 是云中的一个 Nodes 集合。Cluster 也有一个类型,比如 Hadoop Cluster、GPFS-SNC Cluster 等。节点 是一个计算容量单元。为了简便起见,eHPC 没有提供自己的认证系统:它利用底层云中的认证系统。

图 8. eHPC 对象模型
图像显示了 eHPC 对象模型

设计 eHPC 时,我们试图在不会导致特性过多的情况下整合该领域中其他工作流引擎的最佳特性(尤其是 Amazon EMR, Jaql 和 Oozie)。Amazon Cloud Formation 是一个功能丰富的最新拓扑自动化框架,它也能提供大量资源,虽然它最终针对不同的目标集。

图 9 展示了 eHPC 如何提供 Hadoop 集群。与 Amazon EMR 类似,eHPC 没有隐藏它提供的功能强大的计算引擎特性集(在本示例中是 Hadoop)。用户依然可以直接访问引擎。但他们没有必要这样做:eHPC 能采用与 Hadoop、IBM Tivoli ® Workload Scheduler LoadLeveler® 或 Open Grid Scheduler 无关的方式编排工作流。但我们需要尽量利用底层引擎功能来管理集群,以便提高 eHPC 的可扩展性。

图 9. eHPC 提供了一个 Hadoop 集群
图像显示了 eHPC 提供的一个 Hadoop 集群

图 10 展示了一个样例工作流提交请求。这个特殊工作流由两个步骤组成,必须按顺序执行。第一步是发出 sleep 600 命令;第二步是发出 sleep 1200 命令。工作流规定了类型 1 集群的依赖性(64 位 RHEL),包含两个位于德国的 Copper 节点。cluster_placement=3 参数表明 eHPC 能够自主管理集群的生命周期:如果这样的集群已存在并且可用,那么 eHPC 会直接使用它;否则会创建一个集群。

图 10. eHPC 工作流提交
图像显示了 eHPCs 的工作流提交
图像显示了 eHPCs 的工作流提交

eHPC 非常有用,因为在开发、测试和生产环境运行的过程中,它可以帮助我们管理遍布多个云中的众多计算集群。

具体实现

前面介绍的技术组合对于将应用程序准确移植到云中非常有效。计算亲和性的数据执行是帮助降低不必要网络流量的关键因素。eHPC 确保处理棘手流量所需的资源弹性。在这一节中,我们将会简要介绍特定的可量化结果,比如数据传输、存储和云 VM 性能。

应用程序性能

图 11 提供了一个在 8 节点 64 位 Gold 集群上运行的基因组测序管道 Ganglia Monitoring 图表。首先(第 1 步)从设计缓存层将数据加载到计算集群(绿色峰值表示输入网络流量)。

图 11. 应用程序性能概要
图像显示了应用程序的性能概要

然后(第 2 步),将会进行基因组数据处理。在这种情况下,执行任务大约需要 30 个小时:输入数据的加载(第 1 步)大约需要 30 分钟,而处理(第 2 步)需要 29 个小时。

在处理期间,除了在进行数据加载、移动和结果传输(一些群内网络流量有时占用空间,因为一些节点上有空间限制)时,网络是相当空闲的。在第 2 步的排队阶段,CPU 完全加载,但在染色体重组期间则会减少加载。请注意,对于直接连接的临时磁盘(图中未显示),可以扩展 I/O。我们必须将每个节点上的 GPFS-SNC 缓存大小增加到 4GB 来实现性能优化。

WAN 数据传输性能

我们进行了两组测试来识别优化数据传输机制。首先,使用 Simena 网络模拟器创建往返时间 (RTT) 为 90ms 的 10Mbps WAN,以便模拟横跨大西洋的数据传输。然后,我们选择了一个包含 64 个文件的数据文件夹,文件夹的大小为 128MB。我们在未压缩情况下模拟通过 WAN 传输文件夹并将其压缩为 tar 格式(因此其大小下降为 66GB)。图 12 显示了相关结果。

图 12. 模拟的 WAN 数据传输速度测试
图像显示了模拟的 WAN 数据传输速度测试
图像显示了模拟的 WAN 数据传输速度测试

我们使用了 Riverbed Steelhead 网络优化器、Filezilla、HSCP 和普通的 SCP 工具。gzip 和 FTP(用于测试的两种并行传输)的结合使用提供了最佳的总体时间并且使网络连接饱和。正如我们前面所提到的,在处理大量基因组数据时,重复删除功能可能无法奏效。

第二组测试是在 IBM SmartCloud Enterprise 中进行的,涉及到位于 Durham、North Carolina 和 Ehningen 数据中心的活动 VM。在给定时间内传输率会因为数据中心的加载而产生变化,而 图 13 显示了一个典型结果,其中的吞吐量 (MB/s) 是根据并行传送量来绘制的。FTP 比 rsync 稍快一些,由于后者的开销(启动和加密),峰值吞吐量在两次测试中都是相同的,大约为 85MB/s。因为物理节点有 1GE 适配器,所以速度大约为 125MB/s。我们使用了运行 RHEL 5.5 的 64 位 Bronze 节点,测量出的 RTT 为 103ms;传输一个包含五个 1GB 文件的文件夹。

图 13. rsync 吞吐量与线程数量
图像显示了 rsync 吞吐量与线程数量
图像显示了 rsync 吞吐量与线程数量

DTU 通常基于并行 rsync,提供了良好性能,有时性能接近极限值 125MB/s(每节点)。我们还压缩了输入数据并减少文件数量,以弥补 rsync 启动时间。

存储性能

在数据缓存和计算层间(都运行 GPFS-SNC)传输数据时,我们通常会关注 NxM 并行模式。该步骤实际上将数据传输和计算所需的数据亲和力的实施相结合;因此,结果在某种程度上未达到最佳标准。图 14 显示了 8x8 传送情况下的具体细节。8 个计算节点中的每个节点都从对应存储节点启动了一个数据进栈操作。因为将数据置于存储集群时使用了标准 GPFS-SNC 条带化方法,所以产生了内部网络流量(第 1 部分中的绿线)。

图 14. 将数据加载到计算集群
图像显示了如何将数据加载到计算集群

为了进一步提高性能,提供了两个备选方案:

  • 因为了解应用程序特征,所以我们可以执行数据亲和性规则,然后通过并行 rsync/SSH 执行 NxM 数据传输。如图 14 所示,rsync/SSH 进程会带来更高的系统和用户 CPU 使用。
  • 通过将存储集群的文件系统直接挂载到计算集群中,GPFS-SNC 负责定位每个块,并以最佳方式进行数据移动。因为存储文件系统挂在在所有节点上,所以数据传输方法是简单的 copy 命令。与第一个方案相比,数据传输性能更快,而且 CPU 利用率更低(参见图 14 的第 2 部分)。

当数据是本地数据时,我们验证了 GPFS-SNC 的执行与本地文件系统相当。图 15 比较了 GPFS-SNC 与 ext3 的读和写操作。我们已经对一个 64 位 Gold VM 上的 IOzone 进行了该测试。这个文件大小为 1G,而记录大小为 1MB。传送模式是 O_DIRECT,GPFS-SNC 复制因子分别是 8 节点集群上的 1、2 和 3。结果表明,GPFS-SNC 和具有本地写入亲和性的 ext3 一样快。启用数据复制时,写入吞吐量受节点中 1GE 适配器的限制。GPFS-SNC 使用本地写入亲和力创建了连续文件系统优于我们的移植工作的实现。

图 15. GPFS-SNC 与 ext3 性能
图像显示了 GPFS-SNC 与 ext3 的性能

实验的 Iridium VM 大小

因为 IBM SmartCloud Enterprise VM 资源(CPU 和临时磁盘 I/O)以前是不受限的,所以我们在共享云 pod 中体验了运行工作负载的性能可变性。这就是众所周知的 “噪音临近效应(noisy neighbor effect)”。因此,我们以 “专用” VM 大小进行实验,这将占用整个物理节点的 VM 大小(称为 "Iridium")。图 16图 17 显示,Iridium VM 展现了几次运行中大幅减少性能的可变性。在所有情况下,都使用 8 节点集群,并且处理时间是以任务实际的完成时间来进行记录的。我们确定图 16 中的 runs 1 和 runs 2 至少在一个物理节点上发生碰撞。流量 4 有一个显而易见的缓慢 VM,但它不与集群中的其他任何 VM 共享物理节点。

图 16. 64 位 Gold VM 上的处理时间
图像显示了 64 位 Gold VM 上的处理时
图 17. 64 位 Iridium VM 上的处理时间
图像显示了 64 位 Iridium VM 上处理时间

即使不同样例的运行时间不同,但数据大小和质量变化不超过 15% ,因此不能用处理时间解释这种可变性。

处理成本

总成本由几个主要部分组成:WAN 上的数据/结果来回传输、数据缓存层中的暂时存储和计算本身。图 18 演示了在 IBM SmartCloud Enterprise 中使用基础架构进行一个实例数据集的处理时所需成本的组成。在这个示例中,我们将 64 位 SUSE Bronze VM 用作数据缓存存储,并将 64 位 SUSE Gold VM 用作计算层。列出的 VM 定价仅供参考,在实际情况下可能有所变化。为了简便起见,我们没有考虑长期存储云层;我们假定所有的数据在缓存层中仅存储 48 个小时。

图 18. 样例处理成本分析
图像显示了样例处理成本分析

我们学到的知识

正如您从 图 11 所了解到的,自定义编排在云处理期间使用系统资源进行合理工作。在大多数时候,CPU 是瓶颈,本地磁盘 I/O 占据了另一大部分的小孩,而网络 I/O 也许是所有组件当中最可控制的,占据了第三的位置。

我们所获得的数据暗示着许多方面都有机会进一步改善。当提到 CPU 时钟(可通过 VM 访问)时,要求仔细研究 Hypervisor 对磁盘 I/O 密集型负载的影响。除了通过优化虚拟云来处理大数据之外,设计不使用虚拟化的大数据无疑也是明智之举。

同样,确保您对进行虚拟化的和无虚拟化的磁盘 I/O 进行了比较,并优化了 delta 数据。最后,与 IBM SmartCloud Enterperis 以前提供的主轴与核心(spindle-to-core)比率相比,大数据环境可能需要更高的主轴与核心比率。

云中的数据传输意味着执行额外的工作。图 14 是支持使用 GPFS-SNC 作为集群数据加载的有力证据,但是,当存储和计算集群在物理上彼此隔离时,GPFS-SNC 表现不够良好。

图 16 所示,VM 性能可变性对处理时间有巨大的影响。如果控制 VM 性能是不可能的,那么您必须借助 Hadoop 之类的技术,该技术可以复制贯穿多个节点的数据,从而重新安排工作,使其远离缓慢节点。

图 18 中可以看出,云中大多数处理成本来自计算本身。但是,我们觉得最终可以通过选择合适硬件和算法改进来处理该组件,而 WAN 传输组件却更难控制,并有可能会控制云中的整个基因组处理成本。

大数据问题

目前的大数据 定义与数据集紧密相关,以至于常规工具无法恰当处理它。有一点需要着重指出的是,独立数据集的大小通常约为 200GB。因为基因组是相互独立的,我们早就已经注意到,适当的自动化受到云计算的支持,所以可以独立运行处理管道而不是创建和维护工具,这些工具可以适应 10 倍或 100 倍的大数据和计算量。

因此,对我们而言,计算和数据存储单元的最佳大小足够处理一个基因组。可以从云中快速请求计算单元并返回到云中,不会产生空闲时间。本案例中的规模经济减少了对云的弹性限制(例如,配置/接触配置时间),可以更有效地将作业打包到计算节点中(如 图 11 所示,有时 CPU 没有 100% 得到利用)。这将以复杂性和安全性为代价,因为不同数据集可能需要彼此隔离。

MapReduce 相似性

有一点需要重点注意的是,我们最终采用的处理管道的基础架构并不是完全不同于 Hadoop 支持的 Langmead、Schatz 和 et al.。从根本上讲,与计算移动成本相比,以该任务为目的的数据移动成本更高;因此,这里的大数据方法比无状态的节点 HPC 方法更合适。

如简介中所述,时间限制阻止了我们修改应用程序。所以,我们无法将其转移到 Hadoop 框架中。但是,我们可以通过自定义编排解决 Hadoop 通常处理的任务(例如,重新安排故障存储上的任务)并调整 IBM 云的这些设置。存储故障确实并不常见,所以我们有理由不复制运行时存储。

结束语

我们十分清楚云计算非常适合生物信息学工作负载。我们也非常清楚,需要仔细挑选云硬件来正确支持大型的、数据密集型的工作负载。例如,我们会设想一个非虚拟化环境,该环境中的每个核心都有大量直接附加的主轴。节点互连可能需要也可能不需要从 1Gbps 级别开始升级。您需更通过更多的测试来确定硬件配置的最佳范围。

随着计算和存储价格的持续下降,我们期望网络数据传输成本在总成本中发挥较大作用。因此,我们应考虑采用具有较小模块化 pod 的分层云,而且这些 pod 更接近云供应商内部部署的数据源和较大的溢出 pod。

另一个要探讨的领域是仔细研究不同基因组的不同 DNA 片段的出现频率,以实现数据压缩。这是一个比较棘手的问题,但在特定机制中可能会找到机会。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=936776
ArticleTitle=将并行处理大规模生物信息的管道应用移植到云上
publish-date=07082013