您的位置:首页 > 大数据 > 云计算

OpenStack云计算与HPC之一: 前言和OpenStack与HPC虚拟化

2018-02-11 13:53 686 查看
此篇文章翻译编辑自OpenStack全球悉尼峰会《Crossroad of Cloud and HPC》。
一、前言
OpenStack®是领先的开源云计算IaaS平台,助力世界上许多非常著名的科学研究机构。令人惊讶的是,科学研究学科包含了一些最流行的OpenStack云应用案例,面对科学研究计算IT基础设施的挑战,OpenStack提供了令人信服的解决方案。
在科学研究工作中,高性能计算(HPC)和高吞吐量计算(HTC)工作负载要求大规模扩展能力和集群网络:大量的存储、高性能的计算和高速的网络,并且作业和基础设施需要具备可管理性。OpenStack开发社区正在迅速扩展服务以支持这些需求。通过OpenStack私有云管理资源,研究人员能够在满足业务需求的IT环境中工作。软件定义的基础设施具有动态性、自动化的特性,减少了浪费在安装和配置过程中的时间,使研究人员能够最大限度地投入到研发工作上。
本文旨在介绍高性能计算系统架构师和研究计算经理,他们通过探索云计算的优势为HPC工作带来好处,也可以被当前的OpenStack用户用来深入研究OpenStack其他功能。这是对OpenStack的重要功能、注意事项和进一步阅读的深入探讨。在每个部分都包含描述真实的体系结构和操作的用户案例。
OpenStack和HPC虚拟化。描述并解决与虚拟化相关的开销。
案例研究:蒙纳士大学蒙纳士高等研究计算混合(MonARCH)集群和爆炸联合NeCTAR研究云。

OpenStack和HPC网络结构。介绍几种在OpenStack云中提供HPC网络独特需求的解决方案。
案例研究:剑桥大学RDMA(远程直接内存访问)-生物信息学云。
案例研究:俄亥俄州立大学网络计算实验室(NOWLAB)。
OpenStack和HPC数据。介绍HPC数据要求,OpenStack与HPC存储基础架构的集成,并提供实现高性能数据管理的方法。
案例研究:安大略癌症研究所(OICR)癌症基因组合作实验室(The Collaboratory)。
案例研究:用于微生物生物信息学的云基础设施(CLIMB)。
案例研究:威康信托桑格研究所。
OpenStack和HPC工作负载管理。HPC与业务云工作负载管理之间的差异,以及OpenStack为传统HPC工作负载管理带来的好处。
案例研究:Bright Computing按需集群。
案例研究:俄亥俄州立大学网络计算实验室(NOWLAB)。
案例研究:洛斯阿拉莫斯国家实验室(LANL)。
案例研究:墨尔本大学斯巴达集群。
OpenStack和HPC基础架构管理。将HPC基础架构作为OpenStack裸金属管理的差异、优势和局限性。
案例研究:Chameleon是由芝加哥大学、德克萨斯州高级计算中心(TACC)、德克萨斯大学圣安东尼奥分校(UTSA)、西北大学和俄亥俄州立大学领导的计算机科学实验测试平台。
案例研究:匹兹堡超级计算机中心桥梁项目“将研究界与HPC和大数据联系在一起”。案例研究:平方公里阵列。
OpenStack和研究云联盟。支持研究机构之间合作的基础设施。案例研究:欧洲核研究中心(CERN)的联合身份。案例研究:北欧电子基础设施合作(NEIC)。案例研究:EGI联合云。

1.1 开放性和社区协作
OpenStack的开放性的意义是四个开放规定:开放源码、开放设计、开放开发和开放社区。社区发展和协作为全球科学组织定义OpenStack价值。来自学术界和尖端企业的科学家、教师、HPC工程师、运营商和开发人员都充分参与了充满活力的OpenStack科学研究。
HPC工程师将为OpenStack不断发展的代码库做出贡献,以满足所有科学工作负载的严格工作负载要求。
科学组织的成员以如下各种方式进行合作:
OpenStack运营商邮件列表,在主题中使用[scientific-wg]。
互联网中继聊天(IRC)。
OpenStack科学工作组。
工作组在OpenStack上代表和推进了研究和高性能计算的用例和需求。数百名会员喜欢这个跨机构合作的伟大论坛、在线和面对面的活动。

1.2 剑桥大学科学工作组之旅
在剑桥大学,世界级的计算资源支持世界级的研究。一个由建筑师和管理人员组成的专业且经验丰富的团队致力于使剑桥的HPC基础架构处于领先地位。
研究计算本身正在扩大和多样化。大数据分析等非传统HPC需求正在加强。具有不同软件技能和需求的研究人员要求支持新的软件环境。加速变化的速度要求灵活性和敏捷性 - 高性能计算领域的罕见特性。
OpenStack为研究计算提供灵活的基础架构所面临的许多挑战提供了解决方案。通过将计算资源作为OpenStack私有云进行管理,研究人员可以在适合其需求的环境中工作。软件定义的基础设施的动态自动化特性消除了安装时浪费的时间,使研究人员能够最大限度地利用研究时间。
目的是如此简单,但是在生产中使用OpenStack的过程并不简单。虽然剑桥大学的团队在设计和管理HPC基础架构方面有专长,但OpenStack的技能却非常不同。 OpenStack是一个高度复杂的系统,学习曲线陡峭。此外,默认的OpenStack配置不太可能为研究计算环境提供最佳性能。
剑桥的解决方案策略是双重的:与OpenStack生态系统中的供应商建立牢固的关系,积极参与OpenStack社区。
OpenStack最大的资产之一是围绕它建立的受欢迎、友好和乐于助人的社区。然而,尽管OpenStack社区中有许多活跃的用户正在研究计算用例,但没有一个组织团体支持这个用例。
在OpenStack基金会的协助下,很快的组建了团队,成立了科学工作组,剑桥大学作为其联合创始人之一(另一位是澳大利亚墨尔本的莫纳什大学)。
科学工作组的存在是为了支持和推动研究计算用例。我们有许多活跃的成员,来自全球各领域。我们的会员是非正式的,每个人都欢迎。我们通过在OpenStack环境中共享信息、计划事件和研究计算的倡导来相互支持。在这个强大而开放的社区里,我们提出一个科学OpenStack的案例。

二、OpenStack与HPC虚拟化

基于基础设施虚拟化开销的影响,采用OpenStack可能存在疑虑。HPC架构师为什么选择OpenStack?
在本节中,我们将描述OpenStack可以通过虚拟化引入的不同形式的开销,并提供解决方案的技术细节,以减轻、消除或绕过软件定义的基础架构的开销。

2.1 虚拟化的开销
分析通常表明,CPU密集型应用程序的虚拟化开销最小。如果NUMA配置从管理程序传递给guest虚拟机,则内存密集型应用程序的开销也很小。同样,依赖高带宽I/O或网络通信进行批量数据传输的应用程序可以达到接近等效裸机配置的性能水平。如果观察到显著的性能影响,通常可能会导致过度使用硬件资源或“嘈杂的邻居”(可能同样适用于非虚拟化配置的问题)。
但是,仍有一大类应用程序的性能受到虚拟化的显著影响。这里描述一些性能开销的原因。

2.1.1  I/O操作增加虚拟化开销

诸如存储IOPS和网络消息延迟等因素对于HPC应用程序的性能通常是至关重要的。对这些因素敏感的HPC应用程序在传统的虚拟化环境中表现不佳。完全虚拟化的环境每I/O操作会产生额外的开销,这会影响依赖于这种I/O模式的应用程序的性能。
可以通过半虚拟化缓解额外开销。客户操作系统与主机操作系统协作,以提高硬件设备管理的开销。在主机操作系统中执行直接的硬件设备操作,保持硬件的微观管理更接近物理设备。虚拟机管理程序为客户操作系统中的更简单的驱动程序提供更高效的软件接口。通过简化客户操作系统和提供给它的虚拟硬件设备之间的交互,可以提高性能。

2.1.2  虚拟化网络影响性能

所有现代以太网网卡都提供IP、TCP和其他协议的硬件卸载。在不同程度上,这些将用户缓冲区中的数据与链路上的数据包之间所需的转换释放出CPU周期(反之亦然)。
在虚拟化环境中,客户虚拟机的网络流量从虚拟化网络设备传递到管理程序中运行的软件定义网络基础设施。数据包处理通常比典型的HPC配置复杂得多。在这种模式下,硬件卸载功能通常无法运行或无效。因此,虚拟化环境中的网络性能可能比同等的裸机环境性能低,CPU密集度高。

2.1.3  增加虚拟化网络延迟抖动

在不同程度上,虚拟环境会产生更多的系统噪音影响。这些影响导致中断和I/O操作的延迟分布产生更长的尾部。
批量同步并行工作负载在资源的加解锁中迭代,以最慢的作业完成速度运行。如果最慢的作业是由I/O延迟中的抖动影响决定的,则整体应用程序进度会受到虚拟化环境中系统噪声增加的影响。

2.2 OpenStack提供虚拟化HPC
虚拟化领域有相当大的发展活力,不同级别的性能和功能都在不断推出:处理器架构、管理程序、操作系统和云编排等。

2.2.1  虚拟化系统性能的最佳实践

每年两次的OpenStack软件发布会带来新功能的快速开发,从而提高性能和灵活性。
在OpenStack运营商社区中,有一个测试和改进管理程序效率的持续协作过程。调试参数不同配置的经验研究经常被发布和审查,明确的改进会被收集到管理程序性能调优最佳实践的策划指南中。
OpenStack Nova计算服务公开支持许多管理程序功能以提高虚拟化性能。例如:
为虚拟化启用处理器架构扩展。

控制虚拟机管理程序技术,以便高效地管理多个guest虚拟机,例如Kernel Same-Page Merging(KSM)。这可以通过去重复相同的页面来增加CPU开销以换取不同程度的内存使用改善。为了支持内存密集型工作负载,可以配置KSM来防止NUMA节点之间的合并,对于性能至关重要的HPC,它可以完全禁用。

将虚拟内核固定到物理内核。

将物理主机的NUMA拓扑传递给客户主机,使客户主机能够执行NUMA感知的内存分配和任务调度优化。

通过物理CPU的特定处理器模型,可以在高性能科学库中使用特定于模型的体系结构扩展和运行时微体系结构优化。

用大页面支持客户主机内存,减少了主机翻译后备缓冲区(TLB)丢失的影响。

通过使用这些优化技术,CPU绑定和内存绑定工作负载的虚拟化开销通常降低到裸机性能的1至2个百分点。
相反,通过更狭窄地限制虚拟化体系结构,这些调整参数使得在由异构管理程序硬件组成的云基础结构中虚拟机迁移变得更加困难,特别是这可能妨碍实时迁移。

2.2.2  硬件支持的I/O虚拟化

支持单根I / O虚拟化(SR-IOV)的硬件设备使得设备的物理功能的硬件资源能够呈现为许多虚拟化功能。其中的每一个功能都可以单独配置提供给不同的虚拟机。这样一来,网卡的硬件资源可以提供性能接近无额外的开销,同时满足多个虚拟机的不同需求。
通过直接访问物理硬件,SR-IOV网络对软件定义的基础架构提出了一些限制。将安全组策略应用于映射到SR-IOV虚拟功能的网络接口通常是不可能的。这可能会引起外部可访问网络的安全问题,但不应阻止SR-IOV网络在内部用于OpenStack托管的并行工作负载的进程之间的高性能通信。
最近的实验研究发现,将SR-IOV用于高性能网络可将虚拟化的开销降低到网络绑定HPC工作负载的裸金属性能的1-9%。

2.2.3  虚拟化环境中使用物理设备

某些类别的HPC应用程序大量使用GPU、Intel Xeon Phi等硬件加速。
PCI设备形式的专用计算硬件可以通过传递包含在软件定义的基础设施中。该设备直接映射到客户虚拟机的设备列表中,为该虚拟机提供对设备的独占访问权限。
对硬件加速器提出特定要求的虚拟机可以调度到具有可用资源的虚拟机管理程序,并且虚拟机通过从主机环境传递它所需要的硬件来“组合”。
GPU设备的资源管理模型目前不适应SR-IOV。GPU设备完整地传递给客户虚拟机。具有多个GPU的主机系统可以将不同的设备传递给不同的系统。同样,可以将多个GPU设备传递到单个实例中,并且可以在GPU设备之间执行GPUDirect对等数据传输,也可以使用RDMA功能的NIC执行GPUDirect对等数据传输。
但是,设备传递可能会对虚拟内存管理产生性能影响。传递所需的IOMMU配置限制使用透明的巨大页面。因此,内存必须使用传递设备固定在客户虚拟机中。这可能会限制软件定义的基础架构的过度提交虚拟化资源的灵活性(尽管过度提交的资源在HPC用例中通常不值得)。静态的巨大页面仍然可以用来提高虚拟内存的性能。
虚拟化GPU密集型科学工作负载的性能开销仅为裸机性能的百分之一。

有效处理硬件设备的不同策略,这里使用网卡作为例子。在半虚拟化中,虚拟网络设备是在为最有效的软件接口而设计的软件中创建的。在PCI传递中,物理设备从管理程序专门转移到客户虚拟机。在SR-IOV中,物理设备创建了许多虚拟功能,共享物理资源。虚拟功能可以传递给客户虚拟机,将物理设备留在虚拟机管理程序中。

2.3 莫纳什大学的OpenStack虚拟化HPC

从2012年成立以来,澳大利亚科学研究已经从NeCTAR研究云联盟中受益。目前,由全国8个机构组成的NeCTAR是OpenStack的早期采用者,从那时起一直处于该项目开发的前沿。
NeCTAR的联合云计算基础设施支持各种不同要求的科学研究。Monash先进研究计算混合(MonARCH)于2015/2016年投入使用,提供灵活而动态的HPC资源。
MonARCH拥有35个双插座Haswell计算节点和820个CPU核心。 MonARCH利用云爆发技术通过使用来自NeCTAR联盟的资源来弹性增长。基础设施使用56G Mellanox以太网来构建融合的高速网络。云控制平面正在运行Ubuntu Trusty和KVM管理程序。 OpenStack Liberty(截至2016年第三季度)使用Ubuntu分发包(包括由NeCTAR核心服务维护的选定补丁)进行部署,并使用Puppet进行编排和配置。
MonARCH广泛使用SR-IOV来访问其HPC网络结构。高速网络配置为使用虚拟租户网络的VLAN,实现二层RoCEv1(融合以太网上的RDMA)。客户实例使用RDMA来支持紧密耦合的并行MPI工作负载,并可高速访问300TB的Lustre存储。
在MonARCH之后,莫纳什大学最近建立了一个名为M3的混合CPU和GPU集群,这是MASSIVE(多模式澳大利亚科学影像和可视化环境)项目的最新系统。在M3内,基于NVIDIA K80双GPU,有1700个Haswell CPU内核以及16个四GPU计算节点和一个八核GPU计算节点。莫纳什大学云研究小组的工作人员已经将SR-IOV网络和GPU传递集成到他们的计算实例中。



特定的高性能OpenStack类型被定义为需要传递一个或多个专用GPU。这使得一个到四个GPU实例能够在双K80计算节点上同时运行,例如以支持CUDA加速的HPC工作负载和/或多个交互式可视化虚拟工作站。

2.4 OpenStack “Time to Paper” 优化HPC
在评估OpenStack作为研究计算HPC基础架构的时候,应考虑使用资源的科学家的“Time to Paper”度量标准。

对HPC基础设施使用云计算的持怀疑态度,在OpenStack的情况下不可避免地引用了各种虚拟化开销。随着技术的快速发展,这些论点往往是过时的。而且,云计算基础设施呈现出越来越多的权衡,换来越来越多令人信服的新功能。
与传统的HPC系统管理不同,OpenStack提供了如下功能:
标准化
用户可以通过用户友好的Web界面,命令行界面或软件API与系统进行标准化。
弹性资源分配
用户根据需要分配计算资源,独占使用虚拟资源,灵活性和敏捷性。对共享物理资源的程度进行细化控制。
自服务
用户可以自助服务并启动他们选择的软件镜像,无需操作员的协助。用户甚至可以创建自己的软件映像来运行 - 这是一个强大的优势,可以消除管理员的劳动和延迟用户的工作。
安全
由于用户彼此之间有更高的分离程度,并且在网络上彼此隔离,所以增加了安全性。OpenStack的具有HPC实现软件定义的基础架构的所有优点,同时承担最小的开销。在各种形式中,虚拟化在新功能和相应的开销之间取得了平衡。

2.5 深入阅读参考

《OpenStack虚拟机管理程序调优指南》(OpenStack Hypervisor Tuning Guide)详细介绍虚拟化性能的最佳实践。

https://wiki.openstack.org/wiki/Documentation/HypervisorTuningGuide

CERN的OpenStack in Production博客(CERN’s OpenStack  in Production blog)是管理程序调优持续社区化过程的一个很好的案例。http://openstack-in-production.blogspot.co.uk/。

作为虚拟机管理程序开发不断发展的一个例子,MIKELANGELO项目(MIKELANGELO project)目前正在进行优化,以减少使用其sKVM项目的虚拟化I / O的延迟。https://www.mikelangelo-project.eu/2015/10/how-skvm-will-beat-the-io-performance-of-kvm/

有关OpenStack和容器的更多信息。https://www.openstack.org/containers/

介绍GPU和启用RDMA的NIC之间的GPUDirect点对点传输。http://grids.ucs.indiana.edu/ptliupages/publications/15-md-gpudirect%20(3).pdf

ARM体系结构上的虚拟化策略,与x86体系结构进行比较是非常有见地的。http://www.cs.columbia.edu/~cdall/pubs/isca2016-dall.pdf

有关Monash大学MonARCH的更多信息,请参阅R @ CMon博客。https://rcblog.erc.monash.edu.au/
 接下来敬请等待:OpenStack计算与HPC之二:OpenStack与HPC网络结构和OpenStack与HPC数据》
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息