HPC系统管理最佳实践分享：德州超算中心（TACC）
HPC开始融入AI; HDD将很快消失，只会存在SSD和磁带 -> 需要颠覆； 从应用和存储系统角度，很多时候没有把闪存利用好 -> 需要颠覆。 性能是重要的，可靠性/可维护性也非常重要 -> 需要颠覆； 成本是最后一道阻碍 -> 需要颠覆。
Source: Tommy Minyard, Best Practices in HPC Systems Management: TACC Update, Mar 9, 2023
演讲全文：
实际上，Gerardo刚刚提到的基准测试很有趣，从系统管理的角度来看，这在这些系统上是一个重要的方面，不仅用于对集群进行基准测试和测试，还用于回归测试，当你对系统进行更改时，你希望能够回到之前的状态，并确保不会出现性能下降。我们有时会做一些BIOS更新，突然之间，我们在整个系统中的性能下降了两三个百分点，所以这真的应该如此，所以这很重要。我要说的另一个方面关于基准测试是确保你构建和调整基准测试，以满足你的客户群体的运行需求。我知道你的客户群体可能相对有限。从我们的角度来看，我们必须支持数百个不同的应用领域和领域空间——从他们自己的定制研究生编写的代码，一直到用户实际上并不了解的社区代码，他们只想运行一个预编译和优化的版本。从我们的角度来看，重要的是我们要尽量捕捉尽可能多的不同基准应用。
实际上，我们正在进行这个过程。Frontera实际上是我们正在进行的第一个项目的一部分，这是为了部分得到美国国家科学基金会资助的领先级计算设施，现在我们正在计划在2025年部署的内容，查看所有处理器等等。所以Gerard没有提到的一方面是关于基准测试的，而且我们强烈建议你做的一件事是对你的基准测试报告重要的内容进行表征。进行屋顶线性模型分析，找出浮点基础的千兆赫兹，处理器的频率是否重要，内存带宽是否重要？找出这些特征，因为你需要能够预测下一个系统，并弄清楚你在下一个硬件上会获得多少性能，随着技术的变化，情况变得越来越复杂，我们发现不幸的是，某些技术在某些应用中表现更好，而其它技术在其它应用中表现更好。因此，构建一个通用的计算机变得越来越困难，你往往不得不构建更多异构类型的系统，其中你的环境内有不同类型的硬件，以支持它，但是我稍后会详细讨论这一点。
对于那些不了解我的人，我现在正在谈论，我是TACC的高级计算系统主管。我在那里工作了将近20年。我见证了整个计算机发展的历史，事实上，我刚刚告诉Keith，我们部署的第一台系统大约有2万亿次的性能，现在你的一个单个插槽的性能已经超过了2万亿次。我们甚至开玩笑说，我们的第一个大规模系统Ranger，它是在2017-2008年的时间框架内部署的，性能超过了400万亿次。不好意思，是400万亿次，所以现在你只需要两个或至少是未来的一个或两个这些节点，就能够超越我们现在所做的。所以我要谈谈我们当前的生产系统。基本上，我们在去年没有真正添加任何新系统。我们一直在关注的一个重点是Lone Star 6。它是在2021年部署的。现在已经有一年的生产历史了。我们已经进行了一轮更新。我将谈谈我们在其中遇到的一些挑战。仍在运营Stampede2。它已经投入使用六年了。这对于一个HPC系统来说是相当长的寿命。现在我们有一些硬件故障方面的困难。主要问题是HDD，我们的存储阵列的HDD故障率要高得多，远高于我们预期的寿命。事实上，我想两年前，我们在其中一个阵列中发生了三个驱动器的故障，必须从中恢复，但是有一些机制可以做到这一点，但现在它变得老旧了。我们已经提出了替换它的建议。我们希望今年晚些时候能够用资金进行替换，但不幸的是，他们不再提供3000万美元的系统。资金只有大约1000万美元。
所以，Frontera实际上是我们的旗舰系统。它已经投入使用。现在我们正在进行第三年的投产，实际上即将进入第四年的投产，所以它一直都非常出色。它有超过8000个节点，我将在很大程度上谈到它，主要是因为尽管它一直在投产，但也是我们进行很多评估的地方。我们希望尝试进行这些“一对一”的比较，以找出未来哪些技术将会发挥作用。因此，我们已经添加了很多硬件，包括文件系统、互联不同类型的技术到Frontera，以查看我们是否可以在8000个客户端的条件下推动界限，看看东西是否仍然在这个规模下运作。
让我进入Frontera的话题。再次简要概述一下硬件摘要，所以当你将所有内容放在一起时，我们基本上有8340个节点。我们主要使用Cascade Lake处理器。这些是80 8180，80 8280的处理器。现在它们是每个节点28核56线程，对于我们在这里运行的通用目的应用程序来说，是一个非常好的处理器。性能非常出色；每个核心的内存带宽保持相对一致。而且，英特尔在处理器方面做得很不错，他们在每个核心的内存带宽上保持相对一致，因此随着越来越多的核心进入插槽，它们保持了相对一致。但是挑战当然是，你有AMD处理器，它们有更多的核心，这也是我们在Lone Star 6上使用的内容。还有一些其它的亮点：它支持HDR InfiniBand。我们有主干级（director-class）的交换机。所以，我们有六个这样的大型网络交换机将所有内容连接在一起。然后，我们在这个系统上使用了DDN的存储。我们使用了HDD和闪存存储的混合。我们在闪存存储方面遇到的问题是，我们正在使用他们的IME闪存缓冲技术。如果你还没有尝试过，那么不幸的是，它在某些应用程序中效果不错，但实际上在我们使用的许多应用程序中效果不佳。所以不幸的是，它实际上并没有解决我们闪存性能方面的问题。所以我们现在正在评估一些不同的选择。实际上，我即将在一些这些硬件上部署Weka，因为它实际上对硬件是不加区分的，他们有更多的软件支持。我们进行了一次小规模的评估，我正要从我们的72台服务器中选32台来部署Weka，并看看我们是否能够解决这个问题。这是一个一年期的POC计划，我们计划这样做。稍后我还会详细谈一些有关内容。
计算节点，这是我们首次部署时的一个新内容，但这些都是直接液冷的系统。所以请为此做好准备，一切都在不断向前发展，我们开始看到越来越多的直接液冷、浸入式和其它技术。对于这些插座所输入的电力来说，空气是不够的。我们已经在测试一些全新的Sapphire Rapids节点。这是一个千瓦的节点，仅有两个插座和内存。因此，能够冷却它在使用空气冷却变得越来越具有挑战性。我们目前的Frontera系统中，我们已经将每个机架的功率推到了60千瓦。而我们的浸入式系统，我们将机架的功率推到了70千瓦。我们计划在2025年部署的Frontera的后续系统，我们预计将机架的功率提升到了100千瓦以上。所以，作为系统管理员，要为你的设施做好准备，准备好开始将水输送到机架上，或者使用某种二次回路，因为如果你正在大规模部署，这可能会变得非常普遍。
所以，如果你在图片中注意到，你会看到我们的系统基本上有冷却回路，这是提供大部分冷却的部分，但是由于只有处理器是冷却的，机箱内部仍然有其它电源需要进行冷却，因此我们在背面放置了冷却门。所以大约有75%的冷却来自于直接液冷，25%的冷却来自于冷冻门。所以，冷冻门提供了大约15千瓦的冷却，这使得整个房间的温度都是均衡的。这对我们来说是一个不错的解决方案，因为它适合我们的设施，而且我们实际上在那里没有太多的空气冷却。所以，我们确实需要确保我们能够将尽可能多的冷却直接送到系统中。所以我们非常喜欢这些节点；这些是每个机箱中的四个节点。机箱的设计方式非常出色，它们一直都表现得非常出色。事实上，我们的stampede2系统上也有很多这些节点。然后，作为Lone Star 6系统的一部分，我们还有AMD的后续机箱。
就机架本身而言，当你开始考虑冷却等方面时，这也非常重要。我们不得不转向非常深的机架。所以，我们不仅在机架的后部进行电力分配，你还有机架的后部是网络区域。现在你还必须在机架的后部放置冷却水分配或某种液冷分配。每个单独的节点都有自己的连接到液冷管道的液冷连接。因此，我们不得不在机架的后部添加一个附属组件。当你看Frontera的机架时，它们现在大约有五英尺半深，其中很多都是为了能够提供液冷管道而腾出的额外空间。所以当你开始设计和规划未来的这些系统时，还要考虑到这些内容。
对我们来说，还要重要的一点是我们能够在硬件上工作。在这种情况下，所有节点都是后部可访问的。因此，我们必须能够将节点从内部拿出来，里面有所有的液冷管道、所有的电源分配以及机架中的InfiniBand和Gigi电缆。因此，我们确实与Dell合作，设计和布局机架，以便我们仍然可以从机架中拿出所有硬件并对其进行维修。在TACC，我们自己进行硬件维修。我们有几个员工现场维护和保持系统运行。我们将在接下来的几分钟里谈到我们在节点上所做的大量工作。因此，对我们来说，能够在笔记本上工作并不需要断开或关闭其它节点，也不需要管理系统中的其它内容，这对我们非常重要。顺便说一句，这适用于我部署的每个系统。Cray、Sun、SGI等以前的系统，内存模块会失效。你会不得不不时更换一个节点中的内存模块。我不在乎供应商说什么；它们会失效，而且随着时间的推移，它们将会失效。
这是Frontera的布局。所以，实际上，它被放置在一个非常小的空间中，而这是由于液冷冷却。关于这些机架的另一个特点是它们略微宽一些。它们是30英寸宽的机架，而不是24英寸宽的机架。因此，你会注意到它们在瓷砖上的对齐不太精确。因此，在机架的两端和中间位置，我们放置了冷却分配单元。每个冷却分配单元都是750千瓦。而且它们是冗余的。所以我们有足够的冷却能力来支持一行。所以，它可以在一个或两个之上运行。我们可以失去一个，仍然可以运行。CDU中还有冗余的泵。实际上，我们对CDU和整体冷冻门非常满意。它们表现得非常出色。供应商在某些困境下也与我们合作得非常好。CoolIT是销售人员，但Cooltera实际上是制造商。他们位于英国，我们非常喜欢他们的CDU，并且当我们在某些方面遇到一些问题时，他们与我们合作。这就像在某些区域出现了一些热点，我们对泵和CDU进行了一些调整，从而能够在整个系统中获得更好、更分布均匀的冷却。
所以，我要指出存储实际上位于顶部的一行。实际上，我们的数据中心有一些UPS，只为存储和交换机供电。我们不会为计算硬件使用UPS；电力太大了。当Frontera运行全速时，我们的Linpack功率约为5.5兆瓦。所以这对于运行系统来说是相当大的功率。我提到了机架是液冷的。另外，有趣的是，核心交换机也是液冷的。所以当我说液冷正在来临时，即使你部署了主干级（director-class）的交换机，你也会使用液冷。
现在我要花一些时间来谈谈我们在过去一年中在系统上进行的一些最新更新和挑战。再次强调，我们正在努力跟上BIOS更新和iDRAC更新。我们已经更新到了最新的216.1 BIOS和iDRAC 6.10。我们倾向于等待一些版本，例如我们没有部署iDRAC的6.0版本。我们喜欢等到版本的点版本出来，让它们排除所有有趣的小问题。我常常与供应商开玩笑，如果软件中有错误或问题，我们的一个用户将会找到它，因为不可避免地他们在这方面很擅长。所以从我们的角度来看，确保我们有一个足够稳定的版本非常重要，但我们确实想要尝试跟上。操作系统也是同样的情况。我们通常不会去使用操作系统的0版本，我们通常会等到0.1版本出来，只是为了等待尽可能长的时间。我们在这个系统上仍在运行Mellanox OFED 5.4。我们计划更新到5.7版本，现在可能甚至比5.8版本还要新，但我们确实更新了去年HCA的固件和交换机，解决了我们长期以来一直存在的问题之一。自适应路由现在在规模上可以工作。自从部署Frontera以来，我们已经遇到了一个长期的问题，实际上已经有几年了，就是刚开始时一切正常，但过一段时间后，自适应路由会开始导致死锁或某种路由问题。原来是与我们的核心交换机固件有关。一旦我们更新了固件，我们就有了自适应路由。不足之处是自适应路由并不总是对所有应用程序都有帮助，所以效果因人而异。因此，你可能需要对自适应路由进行一些实验。如果你的应用程序中存在大量的全对全FFT（快速傅里叶变换）等全部对全部通信，它绝对会有帮助。如果你的用户导致你的网络出现拥塞，我认为自适应路由也会在这方面有所帮助。我们在这方面遇到挑战的地方是小消息，不幸的是，它会显著增加延迟。这是我们在规模上遇到的问题。我们遇到的其中一个问题是MPI屏障。这里的时间是应该的两倍，而屏障在MPI中经常用于任务的同步等。不幸的是，这会影响某些应用程序的性能。因此，你可能需要使用自适应路由进行测试。在我们的系统上，我们基本上将一个服务通道设置为自适应路由。这是InfiniBand的好处；你可以在服务通道上进行一些控制。所以，我们在一个服务通道上打开了自适应路由，我们告诉用户，当你要在其上进行基准测试时，在相同的作业脚本中，将环境变量设置为在没有自适应路由的服务通道上运行。然后在其下一个作业脚本的条目中，所以你使用了相同的节点，你有了一对一，打开自适应路由，并重新运行完全相同的基准测试，看看你会得到什么结果。同样，一些代码看到了一些改进，不幸的是，一些代码变慢了。因此，从系统管理员的角度来看，从我们的角度来看，这变得更具挑战性，因为现在我不能只是告诉用户使用这种优化，使用这种，使用这种设置，使用这种。它就像你得自己去测试和弄清楚一些方法。这也适用于编译器。所以，我们在系统上部署了一个API。不幸的是，我们发现使用新的4300或C编译器，某些代码的运行速度会变慢。但我们与英特尔团队密切合作，试图确保所有在旧版本中的改进实际上都得到了新版本编译器的实现。我们当然不想因为升级编译器版本而损失性能。所以这是一个仍在进行中的工作，我们仍在努力中。但好消息是，它们仍然使用了一个API构建的老旧编译器。因此，如果需要，你仍然可以返回并使用老旧编译器。
另一个重要的事情是，这也是我们一直在努力解决的问题，因为我们一直在与DDN合作，试图保持DDN软件的最新状态。因此，我们运行DDN硬件的EXAScaler设备版本。这意味着Lustre在控制器上运行。因此，有两个不同的组成部分需要更新。一个是控制器操作系统，另一个是EXAScaler Lustre版本，是操作系统的一部分。我们现在正在做的是实际上已经升级到了控制器版本，但我们没有升级EXAScaler。他们要求我们等待，因为他们发现了一些错误，并不希望我们部署。但是我们正在努力，希望在今年晚些时候部署最新的Lustre服务器版本。
所以，另一个重要的事情，我在去年的演讲中提到过，就是我们抽出时间来进行这些全面规模的运行。其中一些实际上是为了推动用户在系统上能够做些什么的界限。对于那些运行过操作系统的人来说，在正常生产过程中获得完整的系统访问权限实际上是不可行的。如果你想要运行一个基准测试，你将会耗尽资源，试图耗尽大量资源来获得在整个系统上安排大型作业的机会。因此，对于这些情况，我们已经采取了一些措施，例如，在24小时内，你可以专门访问系统上的所有8,000个节点。然后，你可以在8192个节点上运行，使用8K的二次幂设置，你可以在24小时内或在应用程序运行期间运行任何基准测试。实际上，我们有一些人在这些德州规模的运行中进行生产运行，他们只想在24小时内生成数据。然后，在接下来的三个月里，他们基本上会处理和分析他们生成的数据。所以，这对我们来说非常有益，可以推动软件，确保一切正常。它还允许我们在规模上进行测试，比如进行MPI规模测试，进行Lustre或文件系统的客户端软件规模测试。我们在Frontera上测试了VAST，Weka等规模，我们是在一个德州规模里做的，这使我们可以检验系统，也让用户找出什么问题可以解决。这也有助于我们为下一个系统做计划，因为不可避免地对于NSF的资金，你显然必须展示和证明为什么需要获得资金，其中一部分是其背后的科学场景。我们允许人们在这个规模下解决他们在正常生产中通常无法解决的科学问题。
所以，我们已经在系统上通过了超过五百万个作业。它一直是一个相当大的工作平台。有趣的是，如果你查看系统上消耗的时间数，绝大多数时间都用在了我们认为的大型作业上。即单个作业中使用了超过512个节点。实际上，这是一个令人震惊的大作业数量和计算周期数量，我们经常在此情况下，一组人经常每天运行2,000个节点，即2048个节点。队列中有一个作业，然后一个接一个，每天都有一个，他们每天都在2,000个节点上运行，并且在每个分配周期内都会消耗完他们的时间。正如我所提到的，对于我们来说，真正重要的是评估硬件和测试，我马上就会谈到这个。
所以，我们有一些常规的运营挑战。过去一年里，我们真正遇到的一个问题是，我们已经将用户控制在某种程度上。过去一年，由于用户执行了不良操作，我们的文件系统中断较少。但不幸的是，几乎总是当系统出现问题或系统出现问题时，通常都是某个用户在执行一些不良操作。而且通常需要一段时间。我想花几分钟讲讲系统泄漏，也就是冷却系统泄漏的问题。所以，系统应该是设计为零泄漏的。不幸的是，事情发生时，事实证明我们的某些冷却块上制造的密封件存在问题，我们已经有相当数量的这些情况。实际上，我认为我们已经从最初的8,000个节点中更换了大约500个，而这只是开始更换。到最后，我们可能会不得不再更换几千个。这是一个巨大的挑战，因为不幸的是，从我们的角度来看，我们在看到泄漏之前通常已经太晚了，通常意味着节点已经因某种电压错误或其它问题而发生故障。现在，我们有点幸运的是，我们能够在损坏硬件组件之前捕捉到一些泄漏，因为次级冷却液是乙二醇溶液，就像防冻液一样。当它沾在主板上或服务器插槽内时，它们会被破坏。所以每次发生泄漏时，我们基本上都会损失一个主板，可能还有一些内存模块，至少一两个CPU，这取决于发生了什么。但好消息是，显然它们进行了一些分析，结果是那些糟糕的密封件中的一个5美分的垫圈存在制造问题。一旦达到处理器运行的某个温度，垫圈就会融化，然后会发生泄漏。好消息是，我们获得的所有新密封件都是修复的。我们没有看到问题再次出现，但这也意味着我们已经告诉了戴尔和其它供应商，你必须在服务器内部放置泄漏检测。我们必须在泄漏超出服务器或在机架内传播到周围其它服务器之前得到通知。这是他们在较新的硬件上实施的内容。尽管泄漏检测现在已经内置在系统中。所以不幸的是，作为早期采用者，这是我们面临的挑战之一，也是我们在这个领域受到影响的地方，希望你都不必遭受相同的问题。
之前我提到的另一件事，这也对回归测试等很重要。去年我们进行了一个Lustre升级，实际上破坏了我们的一些应用程序。这是那种情况，让人很费解。你无法复现它。你必须在20个节点上运行两个小时，然后一个节点就会死掉，但我无法告诉你哪个节点会死掉。这次的好消息是我能够进行迭代，最终找到了一个代码，我能够在几个小时内复现它。因此，我们开始检查Lustre客户端版本。我们从已知工作的版本开始，然后逐步升级版本，然后我们最终找到了使事情出现问题的版本。然而，我们花了大约三个星期的时间来进行测试，最终找到了出现问题的版本，一旦我们向他们指出了那个版本，他们终于能够调试出问题并提供修复版本。好消息是，我知道它何时起作用，因为我可以运行这个应用程序，它不会再次失败。不利之处是，我无法百分之百地复现它。我只知道它会失败；我只是不能告诉他们哪一个会失败。
正如我所提到的，我们终于解决了那个长期存在的自适应路由问题，当然，这与应用程序的性质有很大关系。所以，你必须自己测试。但现在我要谈谈的是未来的技术。这也是我现在非常关注的领域，因为我们正在努力为下一个大型系统做计划。因此，对于那些不知道NSF领导阶层计算设施项目是什么的人来说，它是NSF办公室的一个大型设施项目。计划是构建一个将提供Frontera性能的10倍的系统，并且我们计划在Frontera投入运营后的五到六年内交付。在这段时间内实现10倍的性能是相当具有挑战性的，如果不投入大量的节点和大量的资金来解决这个问题。
所以，我们现在正在努力找出哪家处理器供应商，哪种加速器技术适合我们。因此，我们花了很多时间收集在我们系统上运行的应用程序。而且，这也与之前讨论的基准测试讨论有关。我们正在努力寻找一个特征套件的应用程序，我们可以将其作为科学案例，来说明这些应用程序是新系统将要解决的科学问题。其次，作为验收测试，因为我们必须弄清楚系统是否按照供应商在那个时间框架内所声称的那样运行。
我们的高性能计算人员（不是系统团队，而是高性能计算人员）已经对在我们的系统上运行的应用程序进行了很多分析。我们从各个领域中选择了一些应用程序。实际上，我们从各个领域中选择了20个应用程序，我们打算从不同的架构和环境上运行这些应用程序，以弄清楚a）它们是否有效，是否会产生性能，以及b）我们想要在未来部署什么来支持这些应用程序？
我有一份我们一直在测试的不同加速器的列表。我们有一个来自NVIDIA的ARM处理器。这是Ampere，是Grace推出之前的第一个版本。不幸的是，它有点受限。它没有矢量指令。它没有许多64位改进，但它是一个80核的处理器，实际上，如果你的应用程序没有很好地矢量化，它的性能还不错。更重要的是，它里面有两个A100，所以这是我们用于开发的一个东西，以确认应用程序将在ARM环境中构建并在那些设备上运行，使用NVIDIA的GPU。
我们得到了一些全新的英特尔Sapphire Rapids硬件，多亏了Keith。这些东西太棒了。我不知道你是否已经接触过Sapphire Rapids，但我们对Sapphire Rapids的HBM性能印象非常深刻。我们的那些对内存带宽敏感的应用程序获得了1.8倍，甚至2倍的性能，这超过了普通Sapphire Rapids与DDR5的内存带宽敏感性能。因此，如果你对内存带宽敏感，并且有这样的应用程序，我强烈建议你测试一下Sapphire Rapids。Sapphire Rapids的主要限制是每个插槽64GB，因此如果是双插槽节点，则每个节点只有128GB。从我们的角度来看，这很适合大多数应用程序。这是HBM的一部分。是的，没有DDR5。我们已经在Cache模式下进行了测试，效果还不错，但当然，一旦超出缓存范围，性能就会下降。你会获得DDR性能。我们仍在进行相当多的实验，但像我说的，HBM的性能非常令人印象深刻，每秒超过一TB的内存带宽，经过测量。所以，如果你的应用程序对内存带宽敏感，这是一个非常好的选择。
我目前还没有Genoa处理器，我已经订购了一些。有趣的是，新的AMD处理器，我们关注的是，他们在处理器上放了更多的核心，但却没有提供足够多的内存带宽来跟上节点上所有核心的速度。所以，对我们来说，那个96核的处理器是否好，或者那个64核、频率更高的处理器是否更好，还不清楚。现在，你有很多参数可以在AMD上进行调整。我有几个NEC的矢量加速器。这些非常有趣，当你安装它们并安装软件后，它们在软件环境方面做得很好。但它回到了我们早期在Stampede 1上使用Knights Corner卡时所做的事情之一。它就像是你计算机内部的一台计算机，因为它在运行自己的操作系统，运行自己的东西，你需要进行所有的编译等。但如果你有高度矢量化的代码，比如你在旧的SDI Altix上运行的代码，或者使用高比特矢量算法的代码，这些加速器表现得非常出色。挑战在于它就像在你的计算机内部有一台计算机，你需要管理多个操作系统、多个事物。我们还没有能够在NEC上进行大规模的测试。我们没有足够的资源。所以，对我们来说，它在Pi方面的表现还不清楚。但是如果你有一个矢量代码，这些加速器表现得非常好。我们还测试了一些富士通的ARM64处理器。这些是带有HBM的64位ARM处理器。不幸的是，它们的性能没有达到我们的预期，也没有达到我们认为可以实现的性能水平。我们认为其中一部分是由于软件，他们没有正确调整编译器。他们在x86处理器上并没有像英特尔那样进行大量的改进。跟着他们的本地平台或者是带着像Gray这样的富士通平台，这就是我们遇到的问题。因为我很长时间以来一直无法获得富士通的编译器许可证，因为获取所有许可证非常麻烦。看起来，这就是我们的问题。我们尝试了ARM编译器，当然，当时GCC的性能并不好。我们需要重新回过头，但我还没有富士通编译器的许可证。那么你看到了多大的改进，提高了10倍？好的，我们需要重新审视一下。所以，这是系统管理员面临的挑战。我们有这个整个参数空间，试图弄清楚所有事物将如何安排。15。好吧，他们不具备数值计算方面的能力。他们有很多内存带宽，但是是的，还好，我们刚刚接触到一些Next Silicon。这些都是一些专门的加速卡。有点有趣的是，他们试图分析软件并重新调整软件，使其在加速器上运行得更好。我们还处于早期测试阶段，但是，它可能在适用范围内表现不错。但对于一般用途，它可能不如其它加速器适用。
我们还面临的一个重要挑战是GPU的使用。当然，AI和机器学习，在加速器上表现非常出色。我们的问题是，我们还没有很多的AI和机器学习应用。大多数人正在处理的只是一些单节点的小问题，我们是高性能计算，我们希望你能使用更多的节点，获得更高的性能。但他们说，不，我的问题适合这里，我只需要这两个GPU，就可以了。这就像，我们正在努力找到AI和机器学习。我理解，作为公司和大量客户数据的集合，AI和机器学习可能真的非常有用。但这不是我们目前拥有的数据。这使得构建下一个系统变得更加具有挑战性，因为我们正在权衡我们应该在下一个系统中放多少GPU，应该放多少加速器。我们在Frontera上得到的一个很大的赞誉是，它主要是基于CPU的系统，我们的很多用户发现它很好用。他们编译、运行，无需担心，无需重新编写应用程序代码，无需进行移植，他们已经知道如何进行调优。这对他们来说是一个非常舒适的环境。但我们也有一些问题，一个问题是鸡生蛋还是蛋生鸡，我们是否必须强制他们，是否只购买一个存GPU的系统，强制他们，除非你重新编写你的应用程序代码，否则你不能运行？但这会让很多人被淘汰。是的，David需要追踪，不，NSF没有强制我们追求Teraflops，我对此非常高兴，因为我认为，就像Gerard说的，Teraflops没有任何意义。所有Linpack所做的就是测试你的系统是否能够为可能在这台设备上执行的最大问题维持适当的功耗和冷却。从我们的角度来看，Linpack的Flops是没有意义的。我们不追求Flops，但从我们的角度来看，也有一些应用程序会得到很大的加速，分子动力学代码。它们在我们的系统上消耗了大量的计算周期，大约25%，甚至可能达到30%的计算周期都在这些系统上运行。这些是LAMMPS、AMBER、NAMD等类型的代码，它们实际上已经有了相当不错的GPU端口，可以在相同时间内比CPU多3到4倍的性能。好的，那就值得购买额外的GPU成本。但我们也不想放弃大部分应用领域，只支持那些使用GPU的用户。所以，我们预计在下一个系统中仍然会有大量的CPU部分，这是我们设计的目标。但我们正在不断地增加GPU，不再只是一个小型的GPU子系统，它正在变成系统的一个更大的部分。实际上，从设计角度来看，就凭借所提供的大量Flops，它可能占据系统中大部分的Flops。但是，我们做了20个应用程序，我认为只有6或7个应用程序中有GPU，而且有时只有一小部分应用程序已经移植到GPU上。
所以，另一个我们在基准应用程序方面面临的挑战是，当然，我们拥有一个应用程序，比如我们得到了一个AMD，我们得到了一个NAMD的版本，然后他们说，“哦，不，Nvidia有这个其它的优秀版本，他们在这边进行了重新编写，但从实际解决的问题来看，它与这个版本完全不同。”那么，在这种情况下，你如何进行苹果对苹果的比较，因为这是不同的算法、不同的方法？所以，这变得更加具有挑战性。我想花点时间谈谈文件系统。你们中的很多人可能在自己的环境中都在挣扎于文件系统，这可能是薄弱环节，也可能是导致我们系统停机的最常见原因，当文件服务器发生故障，或者通常发生了某些导致崩溃的情况时。因此，因为这个原因，我们正在尝试寻找除了Lustre之外的其它解决方案。
我们过去确实做过Lustre，我们在Lone Star 6上部署了BeeGFS，效果还不错，它有一些小小的特殊情况，我们在ACL和一些其它小的小问题上遇到了困难。但问题是，这些都是为HDD设计的。我们有了闪存，那么我们该怎么办呢？在闪存上，你可以做一些HDD不能做的事情，比如擦除你的编码和其它一些好的东西。我一直在争论，而我在很多问题上的看法是，在某个时间点上，我认为HDD将无法跟上。我认为随着闪存容量的提升，闪存的普及，每个人的手机上都有闪存，内存的开发量以及即将到来的容量，这个HDD改进的2TB增量在容量上将无法跟上未来系统的需求。
所以，我们一直在试图弄清楚闪存方面要做些什么。我提到过，我们在目前的Frontera系统上有一些IME硬件，我们将其用作突发缓冲，我们将会拿走其中一半，并部署Weka。我们在其中的8个节点上使用了Weka，并且效果还不错。我们看到的Weka的一个优点是，如果你处理大量的小文件，它在处理大量的小文件时效果非常好。但有一件事情困扰着我们，那就是性能不稳定。我们会运行一些应用程序，有时我们可以在服务器端看到它们的带宽达到每秒50、60 GB，而其它时候它们只有大约10GB。在文件系统内部，我们没有足够的机制来理解正在发生的情况，以及为什么我们会看到这种奇怪的性能变化。但我们希望，如果我们能够进行大规模部署，我们可以获得更好的测量结果。我们希望进行长期的评估。他们只为我们提供了几个月的授权，所以我们只在几个月内进行了测试。我们希望能够进行更大规模的测试。
对我们来说，另一个重要的问题是，我们知道这些IME硬件在我们的用户群中效果不佳，因此我们希望在这些硬件上部署其它解决方案，而Weka是我们目前可以在这些硬件上部署的东西。Vast是另一个我们也测试过的。在这种情况下，他们向我们提供了硬件评估，因为他们将硬件作为其文件系统软件的一部分出售给你。因此，我们将其连接到了我们的InfiniBand网络中。Vast的重要之处在于，我们成功地在超过6,000个客户端上进行了测试。所以，我们进行了一些关于Vast的性能测试，我感到非常惊讶，这是那种你认为它的广告可能过于美好，而实际使用时，你会发现哇，它实际上真的很好用。我的意思是，我喜欢开玩笑，任何供应商提供给我们硬件，我们就会找到某种方法来破坏它。我们确实破坏了它，但实际上并不是他们的问题，那是硬件问题。这也没关系，我们理解，我手上的一个节点出现了硬件问题，但我们完全在进行大量测试。我的意思是，我们以全速运行，每秒写入或读取70GB，不时地写入大约10或15GB。我们将一台服务器下线，文件系统仍然在运行，没有问题，性能下降，读取性能下降到了大约40GB，但没关系，它还是可用的，它仍然在工作。将服务器重新联机，性能恢复，一切正常。这是我们从系统管理角度一直以来渴望的东西，一个在硬件出现故障时不会离线的文件系统。它不需要进行故障切换，不需要进行恢复，不需要进行所有这些操作，Vast就能做到。所以我们还没有在Weka上测试过这一点，但是我们计划一旦我们得到评估，我们将用类似的方式测试Weka。
我们目前在Weka方面的问题是它受限于4,000个客户端，所以我们还不能将它挂载在Frontera的全部8,000个节点上，但他们正在努力克服这个限制。我们还希望能够测试即将推出的其它将使用闪存的产品。不过，不足之处是我们需要在未来一个月左右就决定在下一个系统上部署什么。我们在4月初有一个最终的设计评审会议，所以我们必须做出一些正式的决策。我们尽量在硬件技术方面做出尽可能多的晚期决策，因为这个领域一直在变化，而且变得越来越困难。从系统管理的角度来看，现在情况变得越来越困难，因为现在我们不仅要处理不同的硬件技术，还要处理各种不同的软件。
关于这些文件系统，我担心的是，对于Lustre，我有源代码，我可以进去，我可以获得很多东西，我可以深入了解发生了什么。但我对其中一些系统有些担忧，因为它们在某种程度上是黑盒。如果服务器内部发生了什么问题，或者他们那边发生了什么问题，我将无法像在Lustre上那样清楚地了解发生了什么。我知道Lustre上的服务器消息意味着不好的事情，我可以观察到很多这些东西。但在Vast和Weka上，我没有相同的机制，所以，它是通过我们的InfiniBand网络连接的，Weka也一样，它们都通过InfiniBand进行IP传输。Vast可能有一些原生的InfiniBand支持，但是你必须通过IP over IB来启动挂载连接，就像一个本地的计划情况。所以他们确实通过NFS进行了超载，我理解是这样。因此，你必须安装另一个客户端。它会编译到他们的内核中，当你执行挂载命令时，它会像挂载NFS一样挂载。
有趣的是，你可以给它一个IP范围，以便它知道它有多个服务器可以挂载。这也是你控制不同客户端带宽访问的方式。因此，你可以说，这些客户端只能连接这些服务器，这些客户端可以连接这些服务器，所以你实际上也可以在这方面有一些服务质量保障。所以，它非常灵活。另一个重要的事情，我之前没有提到，是压缩比，这也是闪存将要提供给我们的东西。我们开玩笑说，他们说：“噢，是的，我们获得了很好的压缩效果。”不，是的，我们将在用户生成的数据上获得压缩效果。所以，我们实际上复制了一部分临时文件系统。我们在Vast文件系统上总共添加了大约1PB的存储空间，所以我们从我们的临时文件系统中复制了约400TB。我们只复制了用户生成的检查点文件，只是开始将它们复制过去。有趣的是，我们认为我们不会从其中的一个用户那里获得任何压缩效果，但我们平均获得了约1.8的压缩比。所以这还不错，比我们预期的要好。他们说：“啊，是的，你应该能够达到大约2”，我们认为2可能太激进了。但是，将400TB的数据压缩到大约220TB的原始容量，这还不错。现在，你通过闪存还获得了更多的价值，因为你在实际运行中还获得了压缩效果。所以我对这些文件系统有一些希望。
成本现在确实是一个重要的问题。我们考虑过在今年晚些时候部署一个闪存文件系统，但是现在每PB的成本实在太高了。但是一旦下一代的PLC，即在QLC之后的下一代技术，以及NVMe驱动器的容量达到目前的32TB，或者在不久的将来翻倍，闪存将会成为主流。所以我们的印象是，到2025年或2026年左右，我们可能只会使用闪存和磁带，也许还会有一些HDD，但不会太多。我可以谈上几个小时，所以如果你们有问题或者其它事情，随时打断我。我喜欢即兴演讲。你有什么问题？
所以，迄今为止，我还没有接触过那些系统进行基准测试。从我们的角度来看，很多时候进行基准测试是一种比较系统的方法。但从系统管理员的角度来看，我进行基准测试的很大一部分原因是为了回归测试。所以我希望确保对系统的更改不会减慢或影响性能。HPC小组通常为我构建基准测试，并提供作业脚本。然后我知道他们应该运行什么。我和Laura以及Sean花了大约一个小时在系统维护之后在Frontera上运行基准测试，只是为了确保。因为我们会运行I/O基准测试、InfiniBand基准测试，然后在系统上运行应用程序基准测试。我们希望确保我们获得良好的一致性性能。并且，他们的性能不会随着时间的推移而下降。所以，我从2019年Frontera首次投入生产时开始，仍然保存着基准测试的数据文件。所以如果需要，我可以随时重新运行。
我们需要能够在规模上进行测试。所以我们希望能够随着时间的推移获得对Aurora的访问。我知道它仍然在建设中，我了解Frontera甚至还没有被完全接受。所以，我们的HPC团队希望能够获得对这些系统的访问，以进行评估。所以，基准测试是...好的，Lone Star 6，我们已经在这个系统上进行了一年以上的生产。我们实际上扩展了这个系统的GPU子系统。我们退役了我们的其它IBM Longhorn系统，并将它从生产中拿出来。所以我们需要一个替代的GPU。所以我们用来运行该系统的资金来购买和扩展Lone Star 6上的GPU基础。
我在上次的能源会议上提到过，但我们还添加了一组虚拟计算节点。我们在节点上添加了KVM，一个小型的虚拟化层。我们在节点上放置了七个硬盘。我们在这里的做法实际上是将其中一个128核节点划分为七个16核实例。这样，那些不能使用节点上所有128个核心，或者不需要节点上所有内存，并且只想运行后处理、一些串行预处理等小问题的用户，我们可以为他们提供这些16核实例。然后他们可以以更低的费率运行在这些实例上，因此他们不需要支付整个节点的费用。是的，是的，所以他们仍然可以访问InfiniBand卡。他们仍然可以本地挂载文件系统。
有几个方面，我们选择使用虚拟机而不是尝试划分cgroups并共享节点的原因是，我们可以确保它们有自己的本地临时空间。许多在我们节点上运行的人喜欢使用本地临时空间。我们有大约300 GB的SSD供他们使用。另外，我们可以将它们固定在特定的系统核心上运行，以减少对系统中其他人的影响。不幸的是，它们仍然共享一些资源，如CPU和InfiniBand卡等。因此，如果节点负载较重，你将会看到一些性能影响。但是我们面临的挑战是，我们仍然有很多用户不需要太多的CPU，他们无法在一个节点上使用128个核心。因此，只需划分一小部分即可。这些已经变得相当流行，所以我们正在考虑在一些其它节点上添加一些更多的驱动器，以便我们可以这样做。但从这个学习者的角度来看，每个虚拟计算实际上在这方面就是一个slurm计算节点。所以，再说一次，从系统管理员的角度来看，实际上我们的角色是使用户的生活更轻松。因此，从我们的角度来看，这是一种为用户提供更轻松的方式，尽管会增加一些管理开销。
另一个重要的事情是我们获得了8个全新的H100 GPU，如果你还没有在这些H100 GPU上进行过基准测试，它们是非常令人印象深刻的。不足之处是它们的内存带宽并没有得到很大的提升。我认为与A100相比，内存带宽提升了约30%。但是它们提供的核心数和浮点运算量几乎是A100的两倍。实际上，我们现在面临的一个挑战是这些GPU是PCIe Gen 5。我们的服务器是Gen 4，而且我们的服务器设计时并没有考虑到这些卡所需的电源。我们当前的服务器每个卡最多只能运行310瓦，而这些卡每个卡需要350瓦。因此，我们刚刚购买了一些全新的Genoa，这是一种PCIe Gen 5，它在节点上提供了更多的电源，以便我们可以将这些H100 GPU安装到其中，并希望从H100节点中获得充分的功率。
这就是Lone Star 6的一个计算节点实际上的样子。所以这是我们的一个节点。基本上，你有两个插槽完全填充，256GB的DIMM。处理器本身性能很好。如果你可以使用节点上的所有128个核心，它们实际上可以胜过同时期推出的Ice Lake节点。Ice Lake节点的问题是，如果你有更多的串行进程，可能无法很好地扩展到所有128个核心。或许你想运行所有的Ice Lake节点。它们的频率爆发性提升得更好一些。但我们还有很多1U节点，我们还有很多浸泡式节点。
这就是我之前谈到的一个方面，我们有空冷机架。我们在这里的做法是，我们的机架的功率限制约为25千瓦。所以，如果你注意到，我们实际上并没有完全填充机架。我们将GPU节点放在了机架底部，那里的散热充足，而常规CPU节点放在了机架顶部。通过这种配置，我们能够在每个机架中放置一个交换机。对于大部分的计算节点，我们实际上进行了浸泡。所以我们使用了GRC的油浸式箱，IceRacks。它们每个机架可达到80千瓦。然而，布线和完全填充机架还是有些挑战的。你可以在这里看到，基本上是所有的节点都在油中，但没有安装任何内容。然后，一旦你在后墙上安装了所有的电源分配单元，安装了所有的InfiniBand（所有黑色的铜缆线），安装了InfiniBand交换机。
InfiniBand交换机基本上安装在这里的小地方。你可以看到有一些用于放置交换机的机架安装位置。所有的电源分配单元都安装在这里的后面。我们拿掉了这个电缆管理臂，它碍事。所以你可以在这里看到我们所有的电源分配单元。我们每个机架有五个这样的三相电源分配单元，240伏特。你可以在这里看到InfiniBand交换机。我们不得不将它们竖直安装。我们不得不将它们倒置。那是因为InfiniBand交换机内部使用了热管。如果将热管安装在错误的方向，它们就不起作用。在手册中没有提到不能竖直安装交换机。我们已经核查过，甚至向他们询问过。他们说：“嗯，手册中没有提到不能竖直安装它们。”但显然他们没有考虑到这一点，你需要将它们竖直安装在一个方向上。这是我们在一切都安装好之后才偶然发现的事情。直到我们开始插入电缆，交换机开始过热，我们才注意到大约有一半的上行电缆运行时，交换机的热故障指示灯开始亮起。作为将来的参考经验。
关于这些机架的好处是你可以在上面放上漂亮的装饰。由于系统上没有闪烁的灯光，我们必须以其它方式使其看起来漂亮。所以我们只是在系统上贴上一个小装饰，使其看起来漂亮。我之前提到过BeeGFS。这是我们非常早期的BeeGFS部署。它工作得很好。不幸的是，我们没有像Lustre那样拥有所有的工具。所以我们不得不编写一些其它的工具来跟踪，例如哪些客户端对文件系统造成了最大的影响等等，以及消耗了多少带宽等等。我们就是没有像在Lustre中那样监控这些的能力。但我们仍在努力，希望能够实施一些改进，与ThinkParQ团队合作改进一些方面。
我确实想提一下，关于回归测试和基准测试之类的。所以我们在我们的系统上尝试做的一件事是，提供各种编译器和MPI库。部分原因是并不是每个应用都最适合于某个库，我们意识到我们需要提供一些多样性，以便人们可以进行一些比较。另一方面，如果其中一个的性能优于另一个，我们也有能力从一个过渡到另一个。有趣的是，现在有多个MPI，它们是ABI兼容的。对用户来说，好处是他们可以编译他们的代码一次，然后只需通过模块切换从Intel MPI切换到MVAPICH，而不必重新编译他们的代码。
实际上，最近这非常重要，因为在我们的128核节点上，我们偶然遇到一个应用程序，如果在一个节点上使用超过96个核心，突然之间你会遇到奇怪的性能波动，就像是，这是怎么回事？因此，我们开始进行调查，看起来，你在节点上运行top命令，负载显示128，也就是说有128个任务，但你开始查看单个任务，你会发现，它们实际上并没有以100%的CPU运行。它们在变来变去，在D状态和其它状态之间切换。我们能够迅速做的一件事情是，这很奇怪。看起来可能是一个MPI问题，与进程绑定等有关。因此，我们很快就能够从Intel MPI切换到MVAPICH，问题迎刃而解。就像是，能在128个核心上运行。所以我们现在知道是一个Intel MPI的问题，我们能够追溯回去，找出只是一个Intel MPI的调优选项问题。但同样，这是有多个编译器和多个MPI的好处之一，你可以进行比较，找出，如果一个性能不如你预期，你可以尝试另一个，看看是否获得更好的性能。这个因地制宜。如今，要弄清楚什么是最好的通用方法变得非常复杂。
因此，我们仍然支持Intel编译器。通常情况下，它仍然是性能最好的。我们也有AMD编译器供用户使用。只是没有完全支持。当我说完全支持时，这意味着我们不构建在MPI堆栈之上构建的所有库和所有应用程序等其它内容。
让我稍微跳到后面一些，跳过这个。那只是我们安装的内容。好的，所以再说一次，我想我之前已经提到了一些这些事情，但同样，我们看到的一个情况是，AMD处理器的每个核心性能不如一些Xeon核心。但如果你能在节点上使用所有128个核心，它将胜过Ice Lake节点上的80个核心。我们还有额外的扩展，因此，我们设计了这个系统，所以我们的核心交换机，我们有16个核心交换机。目前，它们只有约三分之二被填充，所以我们可以扩展这个系统。我们只需要电源和空间，希望很快会有系统退役的硬件。
一个备受关注但我们仍未弄清楚的问题是可组合性。好的，所以在Frontier上，在Lone Star 6上，我们实际上购买了一些GigaIO。我们将其部署出去，试图让它运行。我们仍然在摸索中，试图理解可组合性的价值主张。目前，构建可组合性所需的PCI Fabric非常昂贵，我们不得不构建两个Fabric。我必须有这个InfiniBand Fabric和另一个Fabric才能实现可组合性。从我们的角度来看，GPU几乎总是被充分利用的。所以，我没有多余的东西来移动。我实际上不能这么做。
从我们的角度来看，可组合性，听起来当然很好，听起来很棒，但从管理的角度和管理的角度来看，试图以这种方式进行管理，我认为目前还不太可行。当然，前进时，CXL和其它一些即将到来的技术可能会提供更多的可组合性。但目前从我们的角度来看，事实上，我们已经测试过，我们有一些液体的东西，我们有GigaIO，一些是你必须在内核上支持某些东西才能支持一些东西，我还不准备升级到最新的内核。我们的用户还没有准备好。我们还没有测试过。我们还没有，我们还没有做好准备。所以无论如何，我很好奇。我是说，有没有人，有没有人有可组合性或测试过它的其它经验？我也想要一些反馈，因为从我们的角度来看，我们还没有完全确定其价值主张，因为我们看到了成本，他们为我们提供了一些建议，我得为可组合性支付那么多额外的费用。为什么我不只是多买些GPU？所以，没有反馈？好吧，我没有读完整个项目。
正如我之前提到的，我们正在考虑增加更多的虚拟机。我们需要更多的硬盘来支持这个。如果你的系统中有无法利用节点上所有资源的用户，你可能也应该考虑这个。随着节点变得越来越复杂和庞大，有一件事情我们正在考虑，应该在A100中完全支持。你还可以将GPU划分为实例。它们应该在GPU中有MIG或其它东西，可以在GPU中划分出七个实例。所以在我们这边，有一些关于可能制作小型GPU子系统的讨论，主要用于课程。从这个角度来看，我们面临的一个问题是，有一个大型培训班正在进行中，有100名学生参加。好吧，我只有80个GPU节点，我不能将所有节点都分配给这个班级。如果我可以将一个GPU节点划分为七个实例，那么我可以在课程中支持更多的学生，这可能是划分GPU的一个用例。
正如我之前提到的，这是我之前暗示过的，要小心使用旧的MPI版本，如Intel MPI版本。它们在系统上的128个核心上可能运行得不太好。
所以，关于Stampy 2，基本上与Stampede 2相同。我们将运营扩展到今年9月。我们已经将新的Ice Lake硬件添加到其中，替换了一些较旧的Knights Landing。我们承诺会将Knights Landing运行到夏天。所以在7月1日之后，我很确定我们将开始停用更多的Knights Landing硬件。我们已经开始拆除Knights Landing硬件。它们的保修期已经过了，所以我们已经开始。我认为我们至少已经削减了三个机箱。我们已经失去了12个节点。我们正在拿取DIMM、处理器和其它设备，以保持我们的其它硬件运行。
去年，我们将这个系统升级到了CentOS 7.9，同时升级了OPA和Lustre客户端。系统上有近1100万个作业。从周期来看，它一直是一个非常大的工作平台。事实上，我查看了整个NSF社区，所有其它系统的分配总和还不如仅仅Stampede 2多。所以，当它于今年晚些时候下线时，对于用户来说可能会有些挑战，主要是因为没有其它资源可供他们真正运行。所以我们希望NSF会很快获得一些资金，并引入一些新的系统。
我还要提到，这个系统已经运行了五年。我想去年我们只做了两次维护。我们只是让它运行，保持它，关心它，确保系统运行良好。但现在，我们不计划对系统进行太多更新。
我还想提及另一个最新的话题，我本来想在我的评估中涵盖的，那就是互连。这也是我们在这个领域关心的另一个大问题。Mellanox仍然与我们合作得很好，作为Nvidia的一部分，肯定在支持和继续他们的路线图和开发。但是，我们也在关注Cornelis。他们正在努力。我们在Stampede 2上运行了OPA，效果还不错，OPA相对于InfiniBand确实有一些优势。
但我没有提到的另一个是我们正在评估Rockport Networks。所以我们在大约380个节点上部署了Rockport Networks，并一直在测试。它确实有一些有趣的方面，无需有供电的交换机，这是一件独特的事情。但是，我们当然关心其可行性，因为他们是一家小公司，风险投资支持，没有大客户的情况下他们能够存活多久。所以我们在关注这一点。
当然，还有Cray HPE的Slingshot，我们也在关注。所以希望能对此进行一些测试。但是，有人现在只使用以太网吗？让我看看，只使用以太网，没有InfiniBand，没有RoCE的低延迟。是的，你如何找到配置RoCE？配置RoCE容易吗？好的，一个，两个。是的，确实。这是我经常听到关于RoCE的事情。我自己没有测试过，但是设置初始配置有点困难。但一旦设置好了，它就可以正常工作。
还有一件我好奇的事情，你有没有进行大规模的延迟测量？嗯，延迟还不错，没有看到非常高的延迟。网卡越来越好，交换机也越来越好。是的，Mellanox也是，但是即使是Broadcom的网卡，它们也在变得越来越好。他们试图降低延迟。以太网有一些优势，InfiniBand并不一定具备，你不需要子网管理器，它完全是分布式的，有一些优势。
我担心的是拥塞，或者当网络中有很多流量时，会怎么样。你还有一个问题吗？是的，我是说，你怎么知道它在工作？这是一个很好的问题。我唯一知道它在工作的方式是，当子网管理器表示它实际上已经正确地进行了路由，并且我在其上运行了IB diagnet来测试所有自适应路由方面的东西，并报告它们是正确的。
当然，当我们的网络出现错误，我们会遇到死锁问题时，它也会报告相同的东西。但是，我能看到的是，我不知道的是，当我运行我的应用程序时，它是否使用多个路径，它选择了哪些路径，它是如何选择的？我们无法透明地看到其中的任何情况，而我也不清楚那些机制，是的，很难。我是说，甚至只是快照当前网络中正在发生的事情，以查看发生的拥塞程度都非常困难，因为同时测量所有数据几乎是不可能的。
是的，不清楚，就像我说的，我们可以看到一些应用程序改进，如果你正在进行所有通信，我们确实看到较大消息大小的带宽有所提高。我们还看到屏障时间增加了一倍，我们看到自适应路由会在延迟方面产生一些影响。但是，除了报告工作正常之外，没有其它方法可以知道它实际上在工作。他们肯定希望你使用。他们给我寄来了一个设备，一个UFM设备，我两周前收到的，但我还没有机会将其放到那里，但我会看看它的工作情况。那么，还有其它的问题吗？我今天大部分时间都会在附近，所以如果你有问题，在午餐时间找我聊天，我乐意分享一些关于构建系统的恐怖故事，战斗故事，以及关于这些问题的想法。
---【本文完】---
近期受欢迎的文章：
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解