云上超算与云化超算

“On-demand self-service.”

                            —NIST

云，众说纷纭。说说超算和云。

01 定义

根据美国国家标准与技术研究院对云计算的定义：

首先一条：无需服务供应商人工干预的用户按需自服务。这是"云"的核心价值：从以提供商为中心的"我提供什么，你就用什么"的模式，转变成以用户为中心的"我需要什么，我自己来定"的模式。

02 云上超算

从个人使用的"云音乐"、"云存储"，到生产使用的"云服务器"、"云数据库"，"云"的普及已经深入到生活和工作的方方面面。那么在传统的超算中心擅长的大规模数值计算领域，"云"的表现如何呢? 联旌智能配合用户在公有云上完成了单任务接近一万核计算的可行性测试。整个过程，从无到有，包括自助申请、环境准备、应用测试到资源释放，一共用了不到两个小时。

10分钟 9088核

通过公有云自助申请284台云服务器，单台32核64G内存，互联选用万兆以太网，头节点同时提供nfs服务，不采用任何作业系统，mpirun.hydra 直接用sshd作为bootstrap server。

选择机器类型，设定机器数量，设置登录密码，提交资源申请。五分钟内节点启动完毕。

获取节点列表，设置节点互信，同步配置文件，挂载共享目录。十分钟内集群配置完成。

应用测试一切正常。简直不可思议。十分钟的时间，也许都不够某些物理服务器完成系统自检。"云"显示出了强大的弹性和服务能力。

云超算

测试表明，即使是单任务接近一万核这么大规模的数值计算，公有云也能轻松应对。难怪国内外各大公有云厂家纷纷推出HPC in the Cloud。有些公有云提供裸金属服务器以及100G的IB互联，硬件环境配置甚至超过了很多超算中心。而以互联网速度不断演进的公有云，在硬件更新、技术迭代、服务水平、网络带宽等其他方面更是有先天优势。

03 云化超算

从技术层面来讲，公有云的应用场景已经全面覆盖了传统的超算中心，那超算的未来在何方?  如果依旧停留在以建设方为中心的思路，恐怕结局不会乐观。这个问题不是把机器堆大能解决的，更不是简单的在"计算中心"前面加个"云"字，或者在"超算"后面跟个"云"字就能解决的。

容器

"云"的概念其实早在上世纪九十年代就已经出现，1994年Levy Steven就在"Bill and Andy's Excellent Adventure II" 中提到了cloud的说法。但直到虚拟化技术成熟之后，"云计算"才得到了广泛的应用和关注，技术的进步是新模式出现的前提条件。

有趣的是，现在超算普遍采用的Beowulf架构的出现也是在1994年。

可悲的是，二十多年过去，我们所做的基本上是堆机器。而容器技术的发展让超算应用新模式的出现成为了可能。

虚拟机会有不小的性能开销，这在追求极致性能的超算场景中简直无法接受。容器既满足了隔离的需求，又不带来任何性能损耗，还可以通过打包技术解决应用部署的问题，用在性能敏感、依赖复杂的超算领域再合适不过了。

Containers inside HPC

容器有许多实现，最出名的非Docker莫属，但Docker的设计理念在超算场景有很多不合适，因此出现了专为HPC设计的容器：Singularity和Shifter。关于这几者的详细对比我们不再赘述。

从架构上来讲，Singularity大概是这个样子：

从图中我们可以看出：

Singularity是由mpirun调用的，那么问题来了，只支持Open MPI v2.1.x多个用户共享集群。归根到底，这还是一套传统意义上的超算。

HPC inside Containers

这是容器和超算结合的另一种方案：

一个用户可以有多套私有集群，一套虚拟集群可以多个用户共享。

不同的虚拟集群可以选用不同的操作系统发行版。

用户不需要改变使用习惯。

应用不需要做任何适配。

归根到底，这是超算，更是真正意义上的云。

EaaS高性能计算云平台采用的正是这种方案，也就是Cloudified HPC。

---

相关连接

https://www.wired.com/1994/04/general-magic/

http://webhome.phy.duke.edu/~rgb/brahma/Resources/beowulf/papers/ICPP95/icpp95.html

https://tin6150.github.io/psg/blogger_container_hpc.html

https://www.sylabs.io/guides/2.5/admin-guide/installation_environments.html