一、EHPC产品的基本架构

主要从三个层次设计这款产品，最底层是资源层面，是按照HPC行业的方式对资源进行编排，形成一个可理解的HPC业务集群。这个集群不仅包含ECS实例，还包括存储资源和HPC作业调度所需的调度管理资源，共同组成一套集群网络，其中包括通用的VPC网络和高性能的RDMA网络。

在资源层之上，提供了EHPC的服务层，该层面基于HPC应用的特点，提供集群资源管理、HPC应用管理、软件栈部署、HPC作业的生命周期管理调度，以及基于作业负载的弹性资源伸缩等一系列孵化功能。

最上层，根据HPC业务的特点，提供了相应的使用界面。这些界面包括供IT运维人员使用的控制台，供HPC业务用户使用的HPC PORTAL，以及供第三方开发者使用的Open API，以便他们使用平台化的服务。

二、架构中新发布的功能特点及采用的技术方案

1. 资源层

今年新发布了基于英特尔八代处理器的HPC实例（HPC 8I实例）。为什么要定义这些实例呢？实际上，自2017年发布EHPC产品以来，已经积累了大量的HPC应用性能数据，涵盖了工业仿真、EDI和生命科学等领域。根据这些性能数据，构建了一些性能特征库，包含了各类HPC应用，以雷达图的方式分析这些应用的典型诉求，并根据这些诉求设计硬件产品。

在HPC实例方面，采用了两个策略，第一个是采用八代最通用的实例，使客户可以在阿里云几乎所有地域和可用区获得这些基础设施，确保最大的可供应性。同时，针对HPC的特点，在生成HPC实例时，会对其实施一些性能上的增强，如提升主频的提升、单核内存带宽的提升等，单核内存带宽在流体类的应用中是非常重要的性能指标，并按HPC行业的特点默认关闭超线程（HT）来售卖。在实例方面，这些增强使得典型应用如CFD（流体）和SDNA（结构）在汽车和大装备制造方面广泛使用的软件中，都能获得明显的性能提升。

第二个方面是，HPC实例默认都会配套RDMA网络来销售。RDMA网络的技术细节刚才已有详细介绍，这里不再赘述。我想强调的是，在软件栈方面，很多客户上云时都会关心他们的软件是否能在云上顺畅运行。这主要是因为HPC软件的底层网络大多基于IB，而IB对网络的基础设施有很大的要求，而云上网络是以以太网为基础的。

但IB它在链路层是不一样的，因此，我们在RDMA网络的技术选型中，非常重视软件接口选择在哪一层。我们现在的RDMA网络选择支持IB Verbs这一层，这是源于我们的全部支持，但是很多厂商可能会选择library这一层，立法会是2014年左右才开始活跃的组织，当然现在是非常活跃的，但问题是在面向线下的传统制造业客户时，发现很多软件还是比较古老的软件站，他们甚至一直在使用DAPO软件通讯库，这样的话，如果你要迁移到Liv fabric是必然要修改应用的运行代码或运行脚本的，这会给他们带来不便，而且对fabric层面会屏蔽掉lobs的能力，导致软件的网络的使用在性能或在功能上会有一些差别，所以选择对接的城市在verbs这一层，实际上它跟IB的通信源语是一模一样，客户的代码几乎是不需要任何改动，可以直接在云上使用ERDM网络启用云上的HPCA业务。

另外，在资源、网络和硬件都已提供后，如何更高效地使用云上的HPC集群也是客户关心的问题。客户经常会问，提供了类似IB的RDMA网络和高性能实例，他们跟线下的高阻屏、大内存的机器做一个比拼，是否能保证每一个作业都能最大性能地运行。这确实是一个云计算本身带来的问题。因为云计算的机房不可能像线下的HPC机房一样规划好特定的机柜或机器给HPC使用，保证他们在最近的网络互联环境中是不太可能的，因为我们是一个多住的环境，客户时时刻刻都在弹性的使用云上的资源，那么在网络胖数下可能就会有空隙，我们一次开出来的资源可能就分布在不同的网络交安机下、不同的胖数节点下和不同的机房，这时候如果客户这样使用投递作业，很可能一个作业的多节会投递到多个节点上，这样会导致实际上看上去使用了RDM网络，但它的性能并没有达到预期的效果。

今年推出了拓扑感知的弹性伸缩能力。这是基于两个层次的网络感知和调度能力，专门针对HPC业务做的一个特性。这两个层次分别是底层的弹性计算服务层和网络拓扑感知的交付策略，以及上层的EHPC服务层的作业调度策略。在交付ECS资源时，会根据网络拓扑现状做就近的交付，而就近交付以前ECS是有部署级概念，但部署级可能主要是打散，并且只保证一定的可用性，但对于HPT场景来说。是专门提供了一个低时延的部署级，这个低时延的部署级是一个聚拢的策略，尽可能的把交付出来的ECS在同一个网络环境下、同就近的交换机或就近的胖数结构下，但实际情况是我们是一个云计算，不可能说真，正交付64台、128台机器，把他们都放在一个交换机上，这是不现实的。

第二层调度是EHPC服务，在客户投递作业时，我们会根据实际网络拓扑情况，把作业需要的资源投递到就近的实例中去。因为HPV作业虽然它一个集群可能有64个节点或128个节点，但它的作业并没有那么大的可扩展性，一个作业可能有2个节点、4个节点或8个节点运行，在作业调度层面把网络拓普的信息融合到调度策略逻辑中，在调度进行决策的作业、决策投递时，把作业投递到就近的节点上，这样就能最大化地利用我们的拓扑感知能力，使得客户的每一个作业都能获得最好的运行性能。

2. 服务层

资源层讲的是如何设计资源，如何编排资源和作业，而服务层的设计与实施是基于不同的HPC（高性能计算）业务场景来提供多样化的集群组网方案。这里包含四种方式，每种方式都代表着不同的组网策略。前几种方式主要利用的是公共云上的资源，这些资源的差异主要在于被EHPC（弹性高性能计算）托管的有多少。所谓托管，即由我们负责资源的管理与维护，客户无需为此操心。在第一种情况下，客户的所有资源都保留在其自己的账号下，而我们则通过后台监控和网络接入的方式切入到调度器，影响并优化其调度器的决策。这种方式允许客户自定义HPC调度资源，从而实现最大化的定制性。

然而，在后续的方式中，我们提供了更高程度的托管服务。特别是第三种方式，是今年新发布的一种计算环境。该环境继承了HPC的调度逻辑和策略，但所有的计算和调度资源均由EHPC托管。稍后会详细介绍这种环境。

至于最后一种混合云集群方式，它实际上是一个组合方案，并非单一存在。它可以与前面的方式相结合，通过proxy（代理节点）或调度器插件，将线下的调度器与线上的资源相结合，Bust 的使用云上的资源。这包括云上的ECS（弹性计算服务）资源和Instant计算资源（即第三种计算环境）。也是今年新发布的计算环境，在这种新的计算环境中，我们根据CPU和内存的实际使用量来计费，而不指定具体的规格。我们在底层屏蔽了实际规格，以便为客户实际的业务计算进行优化。这些优化包括向HPC调度器的适配，以保持客户使用HPC调度器和作业提交的习惯。此外，在计算环境方面还进行了成本优化。以前客户在作业投递前就需要选择实例规格，但在Instant环境,是在作业投递之后,根据当前的库存和费用情况，选择最合适的计算资源进行计算。

在数据管理方面，由于数据不被托管，而在托管与不托管之间需要有一个高效的数据互联，为了实现高效的数据互联，我们还提供了存储加速和缓存功能。同时，作为针对HPC行业客户的产品，通过Adapter能力仍然保持与HPC调度器的互联方式。客户即使在线下或其他云上使用HPC调度器，也能与我们的计算环境进行对接，并使用我们的计算资源。这是Instant本身的架构。

关于混合云，它可以与我们其他的服务形态相互连接。我们通过ESPC plugin机制实现了这一点，这是一套我们定义的组件接口，开放给第三方使用。第三方可以通过定义或实现这套接口，将其自己的HPC调度器与阿里云资源或EHPC进行互联。通过第三方调度器，客户同样可以高效地使用云上的资源。

在服务层方面，还提到了可观测性设计。这主要是针对云上的HPC业务模型来设计的，分为三个层次。首先是资源层面，HPC业务希望观测到集群维度的运行情况，包括性能、存储、网络、CPU等资源的变化情况和核数的变化趋势。在资源层面，我们还考虑了HPC的特殊性，例如HPC实例，ECS实例跑到70%以上可能会有告警，这样就要通知客户进行扩容，但HPC业务并不是这样，HPC业务是一个机器持续跑在70%以下，说明HPC应用跑的有问题，而HPC应用在占用资源后通常是以百分百的利用率在运行，因此在告警策略上做了相应的调整。

例如没有跑满资源，可能会产生告警，这就说明资源有一定的浪费。

其次是业务层面，我们会抽象出业务的作业模型，在云上使用EHP服务可观测时,将集群调度器中的每个作业作为一个观测维度，将提交作业的用户作为上一个层次，而用户所属的组织则归结到项目层次。这些层次都与调度器相关联，客户可以在调度策略中将项目、用户和作业分别制定相应的调度规则或资源kaota之类的限制，以实现集群的业务化管理。

最后是性能层面，由于高性能计算、性能模型在很多客户的场景中备受关注，从HPC并行计算的角度出发，一是福田性能，即大部分的科学和工程计算，福田性能自带福田效率的计算、向量化占比的统计这一类的性能工具和分析工具，另一个是并行性，与RDMA网络配套，我们提供了最低延时的网络环境是希望客户能够用到最优的。所以针对NPI，在RDMA上做了很多的性能统计，帮助客户分析NPI的集群通信，哪里是热点？算子在哪里占比更多，在哪里占比更少？或是不是满足一次并行计算所需要的计算需性能需求，比如可能有些算子就是分布不均，在某些节点上太多，在这个方面需要做一些优化，这都是在实际给客户性能联调时做的一些总结。我们把它形成一个产品方案或是产品的技术放在这里，以上就是我们发布的功能和主要的技术方案。

三、小结

综上所述，在EHPC服务层面主要从资源、服务和使用界面三个方面来帮助客户快速地上云，上好云，用好云。在资源层面，根据HPC行业的性能特征设计HPC实例，在服务层面，根据HPC业务场景设计不同的集群形态，并提供不同的集群组网完成不同的计算任务，在使用界面层面，提供行业化的业务入口来降低客户的学习成本，达到更快的上好云。