logo资料库

高性能云计算 High-performance Cloud Computing翻译.doc

第1页 / 共10页
第2页 / 共10页
第3页 / 共10页
第4页 / 共10页
第5页 / 共10页
第6页 / 共10页
第7页 / 共10页
第8页 / 共10页
资料共10页,剩余部分请下载后查看
2009 年第 10 届普适系统、算法和网络国际研讨会 高性能云计算:从科学应用的角度 摘要:科学计算往往需要可用的数量庞大的计算机来执行大规模实验。传统上,这些需求已通过使用高性 能计算机解决方案和安装集群和超级计算机等设施来解决,这些设施很难建立,维护和操作。云计算为科 学家提供了利用计算基础设施的完全新模式。计算资源,存储资源,以及应用程序,可动态提供的(和现 有的基础设施集成)基础上按使用量付费。他们不需要的时候,这些资源可以被释放。提供这种服务通常 是在保证所需服务质量的服务水平协议范围内。Aneka,一个企业云计算解决方案,通过利用私有云和公有 云的计算资源向用户提供所需的服务质量。其灵活性和基础设施服务支持多种编程模式,使 Aneka 适用各 种不同的场景:从财务应用程序到科学计算。作为在云中进行的科学计算案例,提出了利用 Aneka 进行基 因表达数据分类和脑功能磁共振成像工作流程执行的初步案例研究。 关键字:科学计算,计算科学,云计算,高性能计算 一、引言 科学计算包括数学模型和数值求解技术来解决科学,社会科学和工程问题。这些模型往 往需要大量的计算资源进行大规模的实验,或计算复杂性削减到一个合理的时间框架。这些 需求已初步具有专用高性能计算(HPC)的基础设施,如集群或同一部门联网的机器群,这 些基础设施由“CPU 周期清道夫”管理,如秃鹰软件。随着网格计算的到来,给科学家提供 了新的机会:与电网完全类比,计算网格可以按需提供“马力”从事大型实验,依托机器的 网络潜在的延伸到世界各地。计算网格引入新的功能,动态发现服务,依靠大量属于管理域 的资源和发现满足应用要求的最佳机器设置的能力。科学计算网格已变得如此成功,以至于 许多国际项目导致了建立世界范围的基础设施提供给科学计算。开放科学电网,最初设想使 大型强子对撞机数据分析便利,连接 25000 台主机设备和为不同学科的数据密集型研究提供 支持,比如生物,化学,粒子物理,地理信息系统。欧洲高效电子科学网络起初由欧盟委员 会资助,连接亚欧、美国超过 91 个机构,建立世界最大的各种科学的计算网格基础设施。 TeraGRID 是一个国家科学基金会资助的项目,提供科学家大量的建立在 9 个资源提供商伙 伴网站的资源顶部。它被用于 4000 个用户,200 多所大学的在分子生物学,海洋科学,地 球科学,数学,神经科学,设计与制造,以及其他学科的先进研究。这些仅仅是科学网格计 算最具代表性的例子。 尽管网格技术在科学计算上的广泛使用,由大量运用上述计算网格的项目证实,有些问 题仍然不像描述的使用这种技术这么容易。有些问题是官僚的:这些网格在全球范围内分享, 研究团体要提交提案描述他们希望来进行的研究类型。这种做法导致了竞争地使用科学网 格,使小型研究项目无法获得。其他问题是技术,更重要的是:在大多数情况下的科学网格 功能预包装应用程序将被执行的环境,有时具体的工具和 API 不得不使用,有可能在宿主操 作系统或运行环境所提供的服务有限制。虽然网格计算有动态发现的服务,以及对各种应用 的运行环境,在实践中一组有限的选项供科学家选择,有时它们不能有足够的弹性来应付需 求。一个实际的例子,关于具体软件的使用,可能在程序执行的运行环境中无法使用。在一 1
般情况下,运行在科学网格中的应用程序以任务包的形式实现,应用程序,工作流程和 MPI (消息传递接口)并行过程。一些科学实验无法适应这些模型,必须进行重组或重新设计来 使用科学网格。鉴于官僚问题可以是一个小问题,技术问题是科学计算的基本障碍。从这个 方面上讲,PlanetLab 提出的基于虚拟机的方法很有用。PlanetLab 是用于开发,部署和访 问行星规模服务的开放平台。用户赋予一个接入 PlanetLab 基础设施节点集虚拟机的刀片 机,因此,一个刀片机可按照具体用途完全定制。目前,PlanetLab 是作为一个试验台主要 用于计算机网络和分布式系统的研究,它是唯一能够访问隶属于企业和大学的 PlanetLab 节点的基础设施。这使得它被用于计算科学相当有限。 云计算,目前提供 IT 服务出现的新趋势,许多上述问题可以解决。通过虚拟化技术手 段,云计算为最终用户提供一个涵盖整个计算堆栈的各种服务,从硬件到应用级,按每使用 收取。另一个重要的特征,科学家可以从中受益,能够根据应用需求和用户预算来自动伸缩 使用计算基础设施的规模大小。科学家通过使用基于云技术可以很容易获得大型分布式基础 设施和完全定制自己的执行环境,从而实现实验中完美的设置。此外,通过租用的按每使用 支付的基础设施上,他们可以在没有任何容量计划立即获得所需的资源,当他们不再需要时, 可以自由地释放资源。云计算为提供 IT 服务的每级计算堆栈提供灵活的机制:从硬件级到 应用级。硬件设备和应用解决方案分别由硬件虚拟化和软件即服务提供。这使得有非常多的 选择可供科学家,足以满足他们的任何具体研究需要。 云计算解决方案的热度正在快速增长。结果,他们已经在很多领域被采用了,如社交网 络,商业应用和信息传递网络。目前,计算科学利用云计算仍然是有限,但实现这一目标的 第一步已经完成了。今年,能源部(DOE)的国家实验室开始探索利用云计算服务进行科学 计算。在 2009 年 4 月,雅虎公司宣布,它已经扩展了在美国各大顶尖大学的合作关系,推 动云计算的研究和计算科学和工程的应用。第一个基于云的计算科学基础设施,科学云,已 经由芝加哥大学,伊利诺伊,普渡大学和马萨里克大学共同部署。从研究观点,初步的研究 已经进行了可行性的科学计算用云计算。一些研究通过分析使用的高性能计算科学应用的表 现或科学实验在亚马逊云计算基础设施的表现来调查使用云计算技术的好处。 不同的解决方案可从传统的科学网格移动到云计算模式中。一些厂商,如亚马逊网络服 务和 VMWare 靠硬件级虚拟化和按需提供计算和存储资源来提供服务。谷歌 AppEngine 和微 软 Azure 更侧重于通过实施一个具体的应用模式来实现应用程序级的虚拟化,充分利用其巨 大的基础设施和按需服务。其他的解决方案提供最终用户一个云计算应用程序的平台,从而 提供用户一个更好的服务质量。Aneka 是一个用于开发应用程序的云计算平台,可以按需利 用虚拟资源的 CPU 周期,桌面台式机和集群。它支持多种编程模式,提供科学家表达他们的 应用程序逻辑的不同选择:任务包,分布式线程,数据流,或 MapReduce。它的服务导向架 构提供用户一个完全定制的基础设施,能够满足应用程序所需的服务质量。 本文的其余部分的组织如下:第一,我们通过云计算参考模型和范例的关键要素概述云 计算。然后,我们将介绍 Aneka,并详细讨论它的特征,强调如何支持计算科学。作为个案 研究,我们将介绍基因表达数据的分类和在亚马逊 EC2 上执行的科学工作流程。最后讨论关 于作为科学计算有效支持的云计算的未来发展方向的思考和展望。 二、 云的发展 云计算这个术语包括许多方面,范围从最终用户在使用这项技术带来新机遇的经验到系 统实现使这些机会变成现实。在本节中,我们将给出云计算的特征,引入云计算参考模型, 并确定这项新技术提供的关键服务。 A 云的定义 虽然,云计算这个术语过于宽泛,很难给出一个单一的定义,它有可能确定一些这方面 2
趋势特点的关键要素。阿布鲁斯特等认为,“云计算不仅指通过互联网的应用程序作为服务, 而且是数据中心的硬件和软件系统提供这些服务”。然后,他们定义云是由硬件和软件构成 的数据中心。Buyya 等给出一个更具结构化的定义,定义为“并行和分布式的互联和虚拟化 的计算机的集合,是动态供应和作为一个或多个统一的计算资源提出了基于服务水平协议组 成的系统类型”。云计算的特征的主要特点之一是提供基础设施和软件作为服务的能力。更 确切地说,它是一种技术,旨在提供随需应变的按每使用支付的 IT 资源。先前趋势仅限于 特定的用户类,或者特定种类的 IT 资源。云计算的目标是成为全球性的:它提供了上述服 务给各行各业,从最终用户在因特网上的个人文件到企业外包其整个 IT 基础设施到外部数 据中心。 B 云计算的参考模型 图 1 给出了一个云计算述设想的方案概述。它提出了一个分层视图包括 IT 基础设施, 服务和应用程序,即构成云计算堆栈。它可以区分四个不同的层次,从系统向最终用户逐步 过渡。堆栈的最低级的特点是物理资源部署在基础设施之上这些资源可以是不同的类型:集 群,数据中心,备用台式机。基础设施支持商业云部署更可能由数百或上千台机器的数据中 心构成,而私有云能提供更多的异构环境,即使是备用台式机的的空闲 CPU 周期用于计算工 作量。这一级提供云的“马力”。 物理基础设施由核心中间件层管理,其目的是为应用程序提供适当的运行环境,并利用 最佳的物理资源。为了提供优质的服务,如应用程序隔离,服务质量,沙盒,核心中间件可 以依靠虚拟化技术。在不同的虚拟化解决方案中,硬件级虚拟化和编程语言级的虚拟化是最 流行的。硬件级虚拟化保证应用程序完全隔离和通过虚拟机的物理资源分割,如内存和 CPU。 编程级虚拟化提供沙盒,托管执行应用程序开发一种具体技术或编程语言。(即 Java,.NET, 和 Python)的。在此之上,核心中间件提供一系列广泛的服务,可以协助服务提供者给最 终用户提供专业的和商业的服务。这些服务包括:开票和服务质量协商,接入控制,执行管 理和监督,会计和计费。连同物理基础设施,核心中间件代表部署在云端的应用程序的平台 之上。很少有直接用户级来访问这一层。更普遍的是,核心中间件提供的服务可通过一个用 户级中间件接入。这提供了环境和工具简化了开发和部署云应用。它们是:Web2.0 接口, 命令行工具,库和编程语言。用户级中间件构成了到云端的应用程序接入点。 C 云计算服务产品 由云计算堆栈公开的服务种类繁多,可分组为三种主要的产品,提供给最终用户,科研 机构和企业。它们是:基础设施即服务(IaaS),平台即服务(PaaS),和软件即服务(SaaS)。 图 2 给出了这样的分类。 术语基础设施即服务或硬件即服务指的是基于虚拟化或物理资源的基础设施向商品一 样提供给消费者。这些资源满足对最终用户对内存,CPU 类型和能力,存储,并在大多数情 况下操作系统的需求。用户按使用计费的基础上支付,必须建立他们的系统在这些资源之上, 被托管和管理在卖方所拥有的数据中心。亚马逊是提供基础设施即服务解决方案的主要公司 之一。亚马逊弹性计算云(EC2)提供了一个大的计算基础设施和基于硬件虚拟化的服务。 通过使用亚马逊网络服务,用户可以创建亚马逊机器映像(AMIs),并将它们保存为可以运 行多个实例的模板。它可以运行 Windows 或 Linux 虚拟机和用户费用按运行每实例每小时收 取。亚马逊还通过亚马逊简单存储服务(S3)提供存储服务,用户可以使用 Amazon S3 访问 来自任何地方接入的大量数据。 平台即服务解决方案提供一个应用程序或开发平台,用户可以开发自己的应用程序在云 端运行。PaaS 的实现提供了一个应用程序框架和一组 API,可被开发人员用来编程或组成云 端的应用程序。在某些情况下,PaaS 的解决方案通常作为一个综合系统交付,同时提供一 个开发平台和应用程序在这之上执行的 IT 基础设施。采用这一策略的公司主要有谷歌和微 3
软。 谷歌 AppEngine 是一个用于开发可伸缩的 Web 应用的平台,运行在谷歌基础设施服务器 上。它提供了一套 API 和应用程序模型,允许开发者谷歌提供的另外服务,如邮件,数据存 储,内存缓存和其它的。按照所提供的应用模型,开发人员可以用 Java,Python 和 JRuby 创建应用程序。这些应用程序将运行在一个沙箱中,AppEngine 会按需自动调整。谷歌提供 了一个免费但有限的服务,同时利用每天和每分钟配额,应用需要专业的服务。Azure 是微 软提供为开发云端可扩展应用的解决方案。这是一个云服务操作系统的平台,作为 Azure 服务平台的开发,运行时间,控制环境。通过使用微软 Azure 的 SDK,开发人员可以利用.NET 框架创建服务。这些服务必须通过微软 Azure 门户上传,为了在 Windows Azure 上执行。附 加服务用来构建企业应用程序,如工作流执行和管理,Web 服务业务流程,和获得 SQL 数据。 Aneka 是 Manjrasoft 的产品,是一个纯粹的软件即服务,并提供最终用户和开发者在云 端使用.NET 技术开发分布式应用程序的一个平台技术。该 Aneka 核心价值是一个面向服务 的运行环境- Aneka 容器-这是部署在物理和虚拟基础设施,并允许由不同的编程模型开发 的应用程序的执行。Aneka 提供了一个软件开发工具包(SDK)帮助开发人员开发任何语言 支持.NET 云应用程序,和在 Windows 和 Linux 系统上建立和部署云的工具集。作为一个纯 粹的平台即服务解决方案,Aneka 不提供的 IT 硬件基础设施建立计算云,但系统管理员可 以轻松地通过在集群上部署 Aneka 容器,数据中心,简单的桌面电脑,甚至在亚马逊机器映 像上捆绑来建立 Aneka 云。 软件即服务解决方案是在云计算堆栈的顶端,它们提供最终用户集成的服务,包括硬件, 开发平台和应用程序。用户不能定制服务,但可以访问云端特定的应用程序。软件即服务实 现的历史是谷歌提供的办公自动化,如谷歌文档和谷歌日历,免费提供给因特网用户,而且 是专业优质的服务。 Salesforce.com 和 Clarizen.com 的商业解决方案例子是,分别服务提供在线客户关系 管理和项目管理服务。 表一给出了一些最具代表性公司在提供云计算基础设施即服务/平台即服务的功能比 较。在论文其余的部分,我们将主要集中在 Aneka,以及它如何被用来在云端进行科学计算。 二、 ANEKA Aneka 是一个软件平台和在云端开发分布式应用程序的框架。它按需利用台式机和服务 器或数据中心异构网络的计算资源。Aneka 为开发人员提供了丰富的 API,以便透明地利用 这些资源和通过各种编程抽象来表示应用程序逻辑。系统管理员可以利用一系列工具监测和 控制部署的基础设施。通过互联网公共云提供给任何人,而企业的私有云由一些访问受限的 节点构成。 灵活且面向服务设计的 Aneka 及其它完全可定制的体系结构使 Aneka 云能够支持不同的 方案。Aneka 云可以提供纯净的财务应用所需的计算能力,可以是一个分布式计算的教学参 考模型,也可以构成一个更复杂的网络组件,用来满足大规模科学实验的需要。这也是由各 种应用程序模式通过可扩展的编程模型集来实现。为开发者上线他们的分布式应用程序定义 逻辑和抽象。作为一个例子,为了运行科学实验,可能依靠一个经典的任务模式包,或者为 了实现应用程序作为一个相互作用的线程或 MPI 进程的集合,相互关联的任务集定义一个工 作流程,或一系列 MapReduce 的任务。如果可用的选项不符合要求的,是有可能的用新的编 程抽象无缝扩展系统。 Aneka 云可建立在不同的物理基础设施之上,与其他云计算解决方案集成,如亚马逊 EC2,以按需扩展它们的能力。在这种特殊情况下,Aneka 充当中间人,减少用户的应用程 序访问公共云。作为应用服务提供商,通过使用精细和复杂的定价政策,最大限度地利用所 4
租的虚拟资源和分享用户花费。一个特别重要的是届时,当 Aneka 集成公共云会计和定价服 务如何运作。 图 3 给出了 Aneka 架构概述。为了开发云计算应用程序,给开发者提供了软件开发工具 包组成的框架来编程,一个监测和管理 Aneka 云的管理工具包和一个可配置的基于容器的服 务,构成 Aneka 云的基石。在本节我们将主要集中于三个主要特点:Aneka 云架构,应用模 型和 Aneka 和公共云整合提供的服务。 A Aneka 云 Aneka 云是一个软件守护进程的集合-所谓容器-可托管在物理或虚拟资源,通过因特网 或专用 Intranet 连接。Aneka 容器是整个系统的基石,并公开一个自定义应用程序运行环 境服务的集合。 它为单一节点提供了基本管理功能,并利用托管服务来执行所有的其他操作。我们可以 识别光纤和基础服务。光纤服务通过平台抽象层与节点直接交互,执行硬件分析和动态资源 配置。基础服务识别 Aneka 基础设施的核心系统,他们提供基本特征集,每个 Aneka 容器可 专用于执行具体的任务集。Aneka 的主要特点之一是能够通过不同的编程模型来提供多种分 布式应用程序上线的方法; 执行服务主要是关注提供实现这些模型的中间件。额外的服务横 向到整个堆栈由容器托管的服务,如持久性和安全性。 容器的网络可以是不同部署方案的结果:它可以代表一个完全由相同管理域的物理机 (台式机和集群)构成的私有云,如企业或大学部。另一方面,一个完全虚拟的基础设施是 可能的,整个 Aneka 云可以托管在公共云,如亚马逊 EC2 或桉树管理的私人数据中心。混合 系统也允许的,他们也是最常见的。在这种情况下,当地的基础设施利用额外的虚拟资源扩 展,如图 4 所示。 Aneka 云能按需伸缩和提供其他节点或释放时一些不再需要的节点。这些节点可以是虚 拟或物理资源。物理节点可以通过网络只需关闭节点中的容器就能释放,而在虚拟资源情况 下,它还需要终止托管容器的虚拟机。这个过程可以手动执行或由调度对云状态弹性和自主 地管理。除供应政策,托管在虚拟机或物理资源中的容器没有区别,因为所有的硬件相关的 任务都封装在平台抽象层。如图 3 所示,供应模块属于光纤服务,并公开其服务给其他操作 不同的组件。 一个服务集总是部署在 Aneka 云端。除了光纤服务,该容器的执行核心是基础服务,履 行管理 Aneka 云的基本操作。其中,会员服务在所有云节点跟踪和提供注册表起关键作用, 可用于通过特定配置或操作系统动态发现网络或节点服务。比如,它们可以利用调度服务来 定位所有的节点,支持一个给定编程模型执行。其他组件提供特权基本功能,如支持特权执 行的文件传输和资源预留。 Aneka 容器定制取代基础服务。甚至,Aneka 容器可在任何层配置和定制,执行服务常 用来区分节点。如图 4 所示,一个典型的配置功能部署,调度服务安装在有限数量的节点上, 大部分容器配置为计算资源。此方案确定了主从拓扑结构,这是唯一的 Aneka 的可能选择, 这可能只适合一些编程模型。一个基于调度和元调度的分层拓扑可以为大型基础设施和重负 载条件提供更好的解决方案。 这个简短的概述提供了关于 Aneka 云和它的内部结构的一个总体思路的设计原则。下面, 我们将介绍 Aneka 应用模型开发的功能如何提供定制的运行环境来支持不同的应用程序编 程模式。 B Aneka 应用模型 Aneka 应用模型定义了基本抽象,构成托管在 Aneka 云端的分布式应用程序。它确定了 每一个具体实施必须满足的要求,为了无缝地集成到 Aneka 并利用所有托管在云中可用的服 5
务。应用模型还指定了对运行环境的总体要求,预计来运行是建立在一个特定模型之上的应 用程序。 不同于其他中间件的实现 Aneka 不支持单任务的执行,但任何单位的用户代码在一个分 布式应用程序中执行。Aneka 中的应用程序有一系列执行单元构成,其性质取决于具体所用 的编程模型。一个应用程序是在 Aneka 中部署,配置和在应用级安全操作的联合。执行单元 构成应用程序的逻辑。单元调度和执行的方法具体到它们属于的编程模型。通过使用这种通 用模式,框架提供了一套跨越所有支持的编程模型的服务:仓储,持久性,档案管理,监理, 会计和安全性。 为了实现具体的编程模型 Aneka 开发者必须: •定义将被软件工程师用于架构分布式应用程序的抽象,并确定其执行逻辑; •提供执行服务的实施,要求管理 Aneka 云的抽象执行; •实现一个客户端组件与执行服务协调,管理客户端执行。 这些组件对于任何编程模型的不同实现是普遍的。当前版本的 Aneka 支持四种不同的编 程模型。它们是:任务模型,线程模型,MapReduce 模型和参数扫描模型(PSM)。其他正 在开发中,如角色模型,MPI 模型和工作流。 表二给出了这些模型的一个功能比较和演示了 Aneka 应用模型的灵活性。对于每个模型, 其中的应用程序类型或场景,自然适合该模型进行了简要介绍。表提供了每个模式的简要说 明,代表 Aneka 中应用程序,执行单元以及执行服务。它还提供了一个用户和系统的观点。 C 会计,定价和与公共云整合 Aneka 提供了一个基础设施,允许建立私有,公共和混合云。在云环境中,尤其是在公 共云和混合云例子中,重要的是要落实机制,控制资源和使用定价,以便向用户收费,尽可 能减少花费最大限度地利用系统。会计和定价是为 Aneka 中的应用程序实现定价机制的一项 任务。 会计服务负责跟踪系统使用情况统计和分类每个用户和应用程序。信息是根本,用来估 计必须向每个用户收取的花费和决定应用程序如何对用户花费负责。当前会计服务的实现能 够追踪每个应用程序每个执行单元所花的时间,并保存各单位执行历史。然后这些数据使用 被选中的定价策略,以确定向用户收取的金额。例如,一个简单的政策可以分配到每个资源 的价格和确定每个应用程序的产生的费用,通过简单地计算所有应用程序的执行单位的加权 总和。其他政策能够考虑到一个应用程序使用的具体服务。 当 Aneka 云完全部署或与公共云整合时,这两个组件的作用变得更加重要。在这种情况 下,当确定用户的账单时,利用虚拟公共资源产生的费用要加以考虑。混合云构成一个具有 挑战性的场景:在这里,置备虚拟资源以满足与用户签订的服务级别协议(SLA)。为了面 对这一挑战,Aneka 提供了一个对象模型允许第三方无缝地整合不同的调度算法,可以协调 他们的活动和资源配置服务。当前执行仍处于初期阶段,设计一个模型,其中的调度程序可 以访问多个资源池,实时跟踪每个活动实例的花费。池的基本策略是试图尽可能重用,为了 最小化公共虚拟资源的花费,实例已经在运行。不同的调度算法可以插入到该模型,因此, 开发人员可以提供多个策略,决定何时增长或收缩构成 Aneka 云的节点集。 三、 案例分析 在本节中,我们将讨论两个在云端科学计算的实际应用程序。案例研究都已在亚马逊 EC2 基础设施上实现。第一个案例研究是使用 Aneka 云将基因表达数据集进行分类,而第二个案 例是提出一个 fMRI 脑功能成像工作流的执行,并与传统的网格进行同样试验的性能进行比 较。在两个案例下,提出一个使用云技术的成本分析。 A 基因表达数据的分类 6
基因表达分析是一次性测量活动-表达-成千上万个基因,创造一个细胞功能的全球画 面。剖面分析,这是基因活动的测量,帮助研究人员识别基因和疾病之间的关系,以及细胞 是如何应对一个特定的治疗。其中最有希望的支持基因剖面分析的技术是 DNA 芯片技术,特 别有助于癌症预防。这种技术的一个缺点是产生大量的数据:每个病人的 DNA 纹印就是成千 上万的基因组织成一个序列,其状态(或活动)由特定的颜色或序列中的黑点表示。基于这 些原因,癌症的诊断分析的分类不能没有计算机技术的帮助。 在不同的分类方法中,CoXCS 分类方法在基因表达数据集的分类上特别有效果。CoXCS 是基于特征空间分区的协同进化学习分类法。它通过引入协同进化方法扩展了 XCS 模型。图 5 给出了 CoXCS 内在逻辑的原理图的例子:独立种群分类器的收集是通过使用训练数据集的 特征空间的不同分区。经过反复的迭代,每个独立种群的选定分类器根据一些遗传策略转化 为不同的种群。然后,进化过程反复进行,直至达到一个特定的阈值。 CoXCS 内部架构,基于特征空间分割,不仅优于原有 XCS 的基因表达数据集分类,也是 所有的经典方法。表三表示当应用两个样品基因表达数据集时,不同的分类方法的性能比较。 从测试阶段所获得的结果可以发现,CoXCS 的精度肯定比其他分类方面所取得的结果要好。 使用 CoXCS 的唯一的缺点是把分类器演化成一个稳定的形式需要很长的计算时间。CoXCS 的内在并行允许分布式和更快的执行。云 CoXCS 是基于云的 CoXCS 实施,利用 Aneka 计算云 为每次迭代分配独立种群分类器进化。为了迅速拥有的云 CoXCS 的工作原型,我们把它作为 后代工具包的一个策略实施。后代是一个允许快速成型策略的软件环境。这是基于客户端的 工作流,可以通过 Aneka 和其它中间件来执行。 云 CoXCS 中算法实现和 CoXCS 中一样,因此,我们期望有相同的精度和获得一个在训练 期间几乎线性加速。为了验证假设,我们在亚马逊 EC2 基础设施上部署一个 Aneka 云,并进 行一些初步的测试。这些实验让我们研究执行时不同设置的影响和云 CoXCS 的性能。我们进 行了两个实验:一次使用不同的基因表达数据集,第二次部署不同的实例类型在亚马逊 EC2 的计算节点上。 我们没有改变 CoXCS 的参数,已固定为下列值:独立人口每 5000 人;勘探/开发率设定 为 0.3;所有数据集分 20 个区;迁移率设置为 10%的人口大小;5 个单独的迁移阶段和 100 次独立迭代用于迁移阶段的人口演化。 关于部署基础设施,两个不同的亚马逊映像被使用:主映像和从映像。主映像是一个 Aneka 容器调度和文件分期服务用于 Windows Server 2003 操作系统任务模式为特征的一个 实例。从映像托管一个配置执行服务的容器,部署在红旗 Linux 4.1.2 (kernel: 2.6.1.7) 上。为实验部署的云由一个主节点和多个从节点组成,从节点按需增加。实验用来比较不同 的云设置。两种不同的映像类型用于测试从节点实例:m1.small 和 c1.medium。对于主节点, 我们使用 m1.small 实例类型测试。 表四描述两种用于实验的不同云设置的特征。可以看出,c1.medium 实例建模为双核机, 并提供计算能力是 m1.small 提供的两倍。计算能力体现在 EC2 计算单元。在这两种情况下, 得到每个阶段完整的并行,因为 Aneka 调度器每个核心调度一个任务。因此,c1.medium 实 例每次将处理两个任务。 为了验证实验,我们使用了交叉验证技术。为了支持交叉验证,BRCA 数据集被分为两份, 而前列腺数据集被分成 4 份。表五记录了两种设置的执行时间。 两种不同设置上进行的实验表明,在两种情况下,执行前列腺数据集所花的时间大约是 BRCA 数据集执行时间的四倍。这非常合理,因为 BRCA 基因样本的数量是前列腺数据集样本 数量的四分之一。 另一个有趣的事实是,执行 c1.medium 安装需要大量的时间完成。平均约 32%以上相应 的 m1.small 设置的运行。由于单 CoXCS 执行的任务设计为一个单线程进程,它没有从两个 7
核心中受益。此外,在整个学习进程中执行时间的增加能由事实解释,两项任务是竞争共享 资源,如高速缓存,总线,内存和文件系统。另一个要考虑的问题是 CoXCS 任务在 Aneka 运行环境中执行,Aneka 在双核机上分享。为此,在基础级的基础设施上的一些小操作按顺 序执行。最后,CoXCS 任务是计算任务,使用相当大的内存量来进行学习阶段。这可能会在 一个多核心设置中造成重大的缓存未命中。 更有趣的是有关预算用来进行实验的考虑。鉴于使用的分区数量大,单 CoXCS 任务拥有 的时间相当有限。在 BRCA 数据集的案件中,在不到一个小时的时间完成所有的探索,在前 列腺数据集案例中不到两个小时的时间。尽管有不同的时序,这些执行使两个不同的设置花 费相同的时间。如果我们考虑到亚马逊提供的粒度不能足以提供有效的定价模式,由于执行 时间有着显著差异(平均 32%)。现行会计制度在 Aneka 中实施,每分钟跟踪执行任务,它 被设计成多个用户之间共享虚拟资源。通过让 Aneka 作为云提供者和最终用户的中间人,实 行更有效的计费策略。 B 功能磁共振成像工作流程 脑成像技术为重点在处理从磁共振成像扫描仪获取的图像数据。处理后的图像将被医务 人员和科学家做进一步分析。是功能磁共振成像(fMRI)特别想确定哪些部分大脑反应是某 些特定刺激的响应。为了实现这一目标,首先,磁共振成像扫描仪收集到的脑图像要转化, 以减少解剖变异,从一个主题自然分化为另一个。这个过程被称为特殊正常化或图像登记 (IR)。一旦这一步完成,图像和地图集比较,这是一个参考图像由各脑图像的平均所得, 并作为最后一步,具体的功能磁共振成像分析程序执行。 图 6 给出了顺序步骤的功能磁共振成像分析的可视化表示。功能磁共振成像的整个过程 中,只有空间正常化,其中涉及复杂操作的序列,被建模为一个工作流程。如图 6 所示,在 自然界,这样的工作流程是数据和计算密集型。 一个典型的情况时使用 10 到 40 幅脑图像进行不同的分组反复执行分析。每个输入图像 约为 16MB。对 20 张图片,总输入工作流是 640MB。工作流的每个进程输出数据大小在 20MB 到 40MB 之间。在 40 幅脑图像的例子中,数据处理的总大小超过 20GB。1-subject 红外工作 流的完美执行时间在单机上大约是 69 分钟,不包括转化数据的时间。在分布式执行设置中, 数据传输时间和管理费用是大块的,执行的总时间显着增加。 最初的实验,在第二届 IEEE 国际可扩展计算挑战赛期间展示执行 20 幅脑图像,2009 年 CCGrid 大会在中国上海举行。这里介绍的实验结果是部分展示,是两名获奖者其中一人 的的竞赛结果。 部署系统用来运行实验完全托管在 Amazon 云基础设施上。执行工作流由 Gridbus 工作 流引擎管理,处理工作流中任务执行如图 7 所示。实验由 2,10,20 幅脑图像重复执行,在亚 马逊云上执行,云亚马逊 EC2 作为计算资源的提供者,S3 为存储输入数据。执行结果与在 Grid'5000 执行相同的工作流进行比较,网络中的每个计算节点都作为存储和计算资源。用 于比较两个执行结果的指标是完工时间(系统第一次提交任务的提交时间和执行最后出口任 务的输出到达时间的差额)和工作流执行成本。在 Grid'5000 执行成本假定为零。 图 8 比较了不同数量脑图像的工作流完工时间。对于大量的脑图像,我们观察到使用 EC2 时完工时间减少。对于 2 幅脑图像,完工时间变化并不显着。完工时间的差异主要在于缩短 EC2 虚拟节点数据传输时间,和在 Grid'5000 多个物理站点之间传输相比。对于一个大的工 作流(20 幅脑图像)个人档案传输时间会累积起来,导致总完工时间产生显著影响,当和 Grid'5000 的结果相比。 图 9 比较了完工时间的变化与 EC2 使用成本。执行过程中数据传输和存储花费很小,因 为计算节点都是云数据中心的一部分。随着执行节点数目由 2 个增加至 20 个 EC2 节点,分 析 20 幅脑图像的工作流完工时间从 391 分钟至 107 分钟显着降低。云节点的使用成本从 5.2 8
分享到:
收藏