建立一百万核心集群并不容易，但这里有一些提示，帮助让您在正确的路径上实现极端尺度HPC

当亚马逊与我们接洽，希望建立另一个100万内核的集群时，这一次是与一个实际的客户进行生产负载，我想起了理查德•布兰森(Richard Branson)的一句名言:

“如果有人为你提供了一个惊人的机会，但你不确定你可以做到，说是 - 然后学习如何在以后做！”

当然，我们说我们可以做到，但不是因为引用，但由于极端规模是我们的业务。虽然我们完全有望面对新的挑战，但我们认为集体团队包括“最聪明，最聪明”的团队，加上了一些深夜，会破解这个并展示一些辉煌的结果。我们是对的。

让我们快速查看客户视角来的解决方案，为您提供一些初步上下文。Western Digital希望继续他们的创新遗产，并希望云端确定几乎无限制的规模如何允许他们更快地解决业务问题。基本上他们想要做的是在云中的100万个核心上运行250万次验证测试，而不是在离散的内部部署集群上运行20天。20天加急下到8个小时......那些是更改的市场上市时间！团队聚集在一起计划并与AWS，[Altair]和Western Digital的成员一起执行此功能。

在这篇博客中，我解释了构建这样一个集群的挑战，以及我们的团队如何能够解决这些挑战，努力建立一个在极端规模下运行工作负载的更详细的蓝图。

因此，让我们来看看我们面临的挑战，因为我们逐步加强了对具有更多工作量的更大和更大的群集的测试。很喜欢剥落洋葱，我们确定并解决了我们对新的可扩展性水平的问题，但每次我们最终找到要解决的新瓶颈。

简而言之，构建和管理云中群集的标准方法不适用于极度尺度。DNS服务器，API性能并重新启动机制，所有正常工作都从框中工作。但是当你到达这些超级大小的集群时，事情开始突破，因为在传统方式管理的所有派系之间存在太多的活动和沟通。

为了详细说明，由于其高度动态性质，极端刻度集群与标准的内部部署集群不同。首先，这些极端级别的集群需要使用现货实例是具有成本效益的，这意味着机器来并转到现场实例。我们看到剩余的速度大约为10-25个实例每分钟，这意味着必须配置新实例，所需的作业在调度程序和新的作业中被开始，所需的新作业将在回收的实例上离开的作业。侧面注意：WDC的集装箱工作量确实是检查点的很棒，因为它使重启更有效。相比之下，身份内部群集坐在您身上，并且物理节点在执行期间从集群中脱离群集相对较少。

In the cloud, we want to load work as the cluster spins up to avoid waste (i.e., you certainly don’t want to wait for the full 1 million cores before starting work), and we were adding instances through the spot fleets API at a rate of 675 per minute. At the same time, instances were going away and 1000s of jobs per second were being submitted, which resulted in increasing the work for the scheduler exponentially. With a static cluster, the scheduler is mostly focused on job submission and completion and isn’t worrying about such a high rate of new and disappearing instances. S we needed a new mechanism for handling this infrastructure.

因此，让我们开始剥离洋葱并看看我们所面临的挑战以及我们如何改编基础设施来处理它们中的每一个。

挑战＃1：我们知道从容器注册表中获取大容器的大门将大大减慢该实例的配置，并且可能是可能压倒码头登记处。我们决定将工作负载码头图像烘烤到亚马逊机器图像（AMI）中，以便在实例启动并运行后，它们已准备好滚动

挑战＃2：vpc中使用的标准AWS DNS并没有达到这个规模所需的水平。为了解决这个问题，我们在解决方案中实现了一个自定义DNS，并使用直接ip进行反向查找，以最大化原始速度并避免DNS延迟和节流。

挑战＃3：API调用可以在规模上非常昂贵，因此我们需要更好的方法来监视群集和管理活动，因为实例出现并进行了。当新推出的实例上线时，他们将它们的Specs（实例类型，IP地址，VCPU数，内存等）注册到Redis集群的ElastiCache中。然后，Navops启动然后使用此数据来查找和管理实例，它比制作AWS API调用更高效和可扩展，以检测新实例。

挑战＃4：与挑战＃3有关，整体解决方案需要新的高性能监控和管理基础架构，用于处理实例添加和磨损，作业重新启动和群集性能。这就是我们在Navops发布的一部分提供一些新的基础架构的地方。我们使用Elasticache，Grafana，ProMetheus，甚至建造了我们自己的高性能分布式RPC解决方案，我们称幻想曲（参见下面的图表，概述了各种组件及其角色）。

挑战＃5:我们需要一种机制来跨40000个实例快速读取大量数据。在这次运行中，我们使用Amazon Simple Storage Service (Amazon S3)作为存储后端。要在如此大规模的情况下支持如此快的数据访问速度，只需要很少的调优工作，因为S3带宽扩展得很好，最高可达7500 PUT/s。

牵牛星的极端尺度建筑

以下是读者可能会发现有趣的运行的一些数据和统计数据，这可能有助于填写一些空白：

• 我们在不到8小时内完成了250万个任务。
• 这些工作覆盖了美国东部(北维吉尼亚)地区的所有六个可用区。该集群在1小时32分钟内增长到100万个vcpu，并以满负荷运行了6个小时。
• 当没有任务需要调度或运行时，Altair Navops Launch开始关闭实例，并在大约1小时内完成整个集群的关闭。
• Altair网格引擎能够以超过99％的时间内容保持工作的实例。
• 运行使用C3，C4，M4，R3，R4和M5实例的组合。

Navops启动控制台显示实例数量，内核数量，实例类型，利用率和作业细节:

令人印象深刻的群集利用核心：

这个项目的成功最让我印象深刻的是，它表明公司可以完全重新考虑如何管理HPC工作负载。访问本质上无限的计算能力决定性地改变了竞争格局，并可以帮助组织更快地向市场交付更高质量的产品。这难道不是云的美丽之处吗?在云计算中，在1M的核心集群上8小时内完成250万个任务的成本与在100K的集群上花费80个小时的成本是一样的。

在这个项目上有更多背景，您可以享受阅读杰夫Barr的博客帖子在云规模的西方数字硬盘模拟文章由Bala Thekkedath在极端规模HPC：西方的数字公司如何在AWS上利用几乎无限的HPC能力 - 在他们寻求加速创新并建立更好的产品中。

想要了解有关如何在云中大大提高竞争力的更多信息？今天联系我们。