比较传统网格与高性能计算

た入场券 2022-08-02 02:23 145阅读 0赞

并行计算是一种将应用程序设计为能够在大型并行计算环境中工作的方法。在网格系统中，某一操作或等式的执行是为了给并行执行任务 提供一种结构，工作单元的执行和接收顺序不是连续的，并且不依赖于前面的代码迭代。尽管从总体上说，这两种系统（并行计算和网格）的模型是趋同的，但这两 个系统的传统编程模型仍然是不同的。在这篇文章中，我们将查看并行计算、网格和它们的趋同性。

高性能计算概述

术语 *高性能计算*  (HPC) 指通常使用很多处理器（作为单个机器的一部分）或者某一集群中组织的几台计算机（作为单个计算资源操作）的计算系统和环境。有许多类型的  HPC   系统，其范围从标准计算机的大型集群，到高度专用的硬件。

大多数基于集群的 HPC  系统使用高性能网络互连，比如那些来自   InfiniBand  或   Myrinet  的网络互连。基本的网络拓扑和组织可以使用一个简单的总线拓扑，在性能很高的环境中，网状网络系统在主机之间提供较短的潜伏期，所以可改善总体网络性能和 传输速率。

图 1  显示了标准总线拓扑中使用标准   Ethernet  的   HPC  解决方案或专门的网络连接解决方案的布局示例。

**图 1. HPC  总线网络拓扑**  
  ![Image 1][]

图 2  显示了一网状   HPC  系统。在网状网络拓扑中，该结构支持通过缩短网络节点之间的物理和逻辑距离来加快跨主机的通信。

**图 2. HPC  网状网络拓扑**  
  ![Image 1][]

尽管网络拓扑、硬件和处理硬件在 HPC  系统中很重要，但是使系统如此有效的核心功能是由操作系统和应用软件提供的。

HPC 系统使用的是专门的操作系统，这些操作系统被设计为看起来像是单个计算资源。正如您从图  1   和图  2   中可以看到的，其中有一个控制节点，该节点形成了  HPC  系统和客户机之间的接口。该控制节点还管理着计算节点的工作分配。

对于典型 HPC  环境中的任务执行，有两个模型：*单指令/ 多数据* (SIMD) 和*多指令/ 多数据* (MIMD)。 SIMD   在跨多个处理器的同时执行相同的计算指令和操作，但对于不同数据范围，它允许系统同时使用许多变量计算相同的表达式。  MIMD  允许   HPC  系统在同一时间使用不同的变量执行不同的计算，使整个系统看起来并不只是一个没有任何特点的计算资源（尽管它功能强大），可以同时执行许多计算。

不管您是使用 SIMD  还是   MIMD ，典型   HPC  的基本原理仍然是相同的：整个   HPC  单元的操作和行为像是单个计算资源，它将实际请求的加载展开到各个节点。 HPC   解决方案也是专用的单元，被专门设计和部署为能够充当（并且只充当）大型计算资源。

网格计算概述

网格对于高性能计算系统而言是相对较新的新增内容，它有自己的历史，并在不同的环境中有它自己的应用。网格计算系统的关键元素是网格中的各个节点， 它们不是专门的专用组件。在网格中，各种系统常常基于标准机器或操作系统，而不是基于大多数并行计算解决方案中使用的严格受控制的环境。位于这种标准环境 顶部的是应用软件，它们支持网格功能。

网格可能由一系列同样的专用硬件、多种具有相同基础架构的机器或者由多个平台和环境组成的完全异构的环境组成。专用计算资源在网格中并不是必需的。许多网格是通过重用现有基础设施组件产生新的统一计算资源来创建的。

不需要任何特别的要求就可以扩展网格，使进一步地使用节点变得比在典型 HPC  环境中还要轻松。有了   HPC  解决方案，就可以设计和部署基于固定节点数的系统。扩展该结构需要小心规划。而扩展网格则不用考虑那么多，节点数会根据您的需要或根据可用资源动态地增加 和减少。

尽管有了拓扑和硬件，网格就可以以图 1  和图   2  中所示结构的相同结构为基础，但使用标准网络连接组件支持网格也是有可能的。您甚至可以交叉常规网络边界，在  WAN   或互联网上合并计算资源，如图  3   所示。

**图 3.  网格网络架构**  
  ![Image 1][]

作为执行模型和环境，网格还被设计成在操作和执行方面更具灵活性。尽管可以使用网格解决诸如 HPC  解决方案之类的计算任务，但网格可能更灵活，可以使用各种节点执行不同的计算、表达式和操作。网格并不只是一种没有任何特点的计算资源，可将它分布到各种 节点中使用，并且一直运行到作业和操作都已完成。这使得网格在不同计算和组件的执行顺序对于剩余任务的连续执行不那么重要的地方变得更加实用。

利用这种可变长度灵活性和较孤立任务的网格解决方案的一个好例子是计算机合成电影和特技效果中的表演。在这里，生成的顺序并不重要。单帧或更大的多 秒的片段可以彼此单独呈现。尽管最终目标是让电影以正确的顺序播放，但最后五分钟是否在最初的五分钟之前完成是无关紧要的；稍后可以用正确的顺序将它们衔 接在一起。

网格与传统 HPC  解决方案之间的其他主要不同是：  HPC  解决方案设计用于提供特定资源解决方案，比如强大的计算能力以及在内存中保存大量数据以便处理它们的能力。另一方面，网格是一种分布式计算资源，这意味着 网格可以根据您的需要共享任何组件，包括内存、 CPU   电源，甚至是磁盘空间。

因为这两个系统之间存在这些不同，因此开发出了简化该过程的不同编程模型和开发模型。

并行计算

HPC 解决方案的专用特性在开发应用程序以使用这种能力时提供了一些好处。大多数  HPC   系统将自己表现为单个计算资源，因此它成为一种编程责任，需要通过专用库来构建一个能够分布到整个资源中的应用程序。

HPC 环境中的应用程序开发通常是通过专用库来处理，这极大简化了创建应用程序的过程以及将该应用程序的任务分配到整个  HPC   系统中的过程。

最流行的解决方案之一是 *消息传递接口*  (MPI)。 MPI   提供了一个创建工作的简化方法，使用消息传递在各个节点之间交换工作请求。作为开发过程的一部分，您可能知道想要使用的处理器（在这里指单独节点，而非单 独  CPU  ）的数量。 HPC   环境中的劳动分工取决于应用程序，并且很显然还取决于  HPC  环境的规模。如果您将进行的工作分配依赖于多个步骤和计算，那么   HPC  环境的并行和顺序特性将在网格的速度和灵活性方面起到重要作用。

一旦分配好工作，就可以给每个节点发送一条消息，让它们执行自己的那部分工作。工作被放入 HPC  单元中同时发送给每个节点，通常会期望每个节点同时给出结果作为响应。来自每个节点的结果通过  MPI   提供的另一条消息返回给主机应用程序，然后由该应用程序接收所有消息，这样工作就完成了。图   4  中显示了这种结构的一个示例。

**图 4. HPC  功能图**  
  ![Image 1][]

执行模型通常是固定的，并且连续到完成某个单个应用程序。例如，如果将一项任务分配给 256  个单元，而您的   HPC  系统中有   64  个节点，那么您需要   4  个过程迭代来完成工作。工作通常是并行完成的，在整个应用程序完成之前，所有  64   个节点都仍将保持忙碌。在整个过程中， HPC   系统充当一台机器。尽管消息已经被用来在多个计算节点中分配工作，但整个应用程序被有效地操作为一个单独的应用程序。

其他 HPC  库和接口的工作方式类似，具体的方式取决于开发用于   HPC  环境中的应用程序。无论什么时候，都可以将工作分配和执行看作一个单独的过程。尽管应用程序的执行可能要排队等候，但一旦应用程序开始运行，将立即在  HPC   系统的所有节点上执行该工作的各个组件。

为了处理多个同时发生的应用程序，多数 HPC  系统使用了一个不同应用程序在其中可以使用不同处理器  / 节点设置的系统。例如   256  个节点的   HPC  系统可以同时执行两个应用程序，如果每个应用程序都使用整个计算资源的一个子集的话。

网格编程

网格的分布式（常常是非专用的）结构需要为工作的执行准备一个不同的模型。因为网格的这种特性，无法期望同时执行各种工作单元。有许多因素影响了工作的执行时间，其中包括工作分配时间以及每个网格节点的资源的有效功率。

因为各个节点中存在的不同之处和工作被处理的方式，网格使用了一个将网格节点的监视与工作单元的排队系统相结合的系统。该监视支持网格管理器确定各个节点上的当前负载。然后在分配工作时使用该信息，把要分配的工作单元分配给没有（或有少量）当前资源负载的节点。

所以，整个网格系统基于一系列的队列和分布，通过在节点之间共享负载，在节点变得可用时将工作分配给队列中的每个节点，使网格作为一个整体得到更有效的使用。

响应和结果都同样地在网格控制器上进行排队，以便在处理完所有工作单元（及其结果）时将它们收集到应用程序的最终结果集中。图 5  中显示了这样一个示例。

**图 5.  网格功能图**  
  ![Image 1][]

网格模型允许使用各种级别的资源、工作单元规模和分配级别，而不只是 HPC  解决方案使用的执行模型提供的那些。大多数网格支持使用每个将被排队和分配的应用程序的各种工作单元同时执行多个工作请求。例如，可以在一些节点仍然在完 成  Job 1   上的工作时开始  Job 2   上的工作，为了完成工作，两项作业以某种动态的方式使用相同数量的可用节点。

此过程的灵活特性不但允许以更动态更适应的方式执行工作，还允许网格与各种硬件和平台一起使用。即使网格中的某些节点比其他一些节点更快或更慢一 些，也不再有任何关系；它们可以在自己（比较）空闲的时间完成工作，并且结果将被排队。其间，更快的系统可能被分配更多的工作并完成更多的工作单元。

出现这种不利现象是因为需要更繁重的管理费用来观察和监视各个节点，以便能够在节点间有效分配工作。在异构环境中，还必须考虑不同的平台，并开发跨支持环境兼容的应用程序。但在网格空间中，Web  服务已简化了该过程，使分配工作变得更容易，不必担心这些不同。

在查看 Web  服务的效果之前，我们将查看   HPC  和网格之间的会合区域，并了解这将如何影响不同的执行模型。

会合区域

HPC 和网格环境之间存在一些类似之处，在许多方面，这二者都出现了一些会合和分歧，不同的团体利用了这两个系统的各自优点。许多网格环境已从  HPC   解决方案的扩展中产生，基于  HPC   环境中的工作，网格中使用的许多技术得到了优化和采用。

一些显而易见的类似之处是工作被分配到更小的单元和组件中的方式，以及各个工作节点之间的工作分配方式。在 HPC  环境中，这种劳动分配通常受到严格控制，并且是根据您的可用资源进行的。网格使用了一种更灵活的模型，该模型允许将工作分配给大小不标准的单元，因此可以 在截然不同的网格节点数组之间分配工作。

尽管工作的分配方式上存在不同，但分配的基本原则仍然是相同的：先确定工作及其分配方式，然后相应地创建工作单元。例如，如果遇到计算问题，可以通过创建不同的参数集，利用将应用于每个节点的每个集合的变量来分配工作。

HPC 系统中使用的消息传递结构和系统也已开发并适用于网格系统。许多  HPC   消息传递库使用共享内存结构来支持节点之间的工作单元分配。

在网格中，共享的内存环境是不存在的。此外，工作是利用标准网络连接（通常使用 TCP/IP ）上发送的不同消息来分配的。系统的核心没有什么不同：我们将交换包含工作参数的消息。只有交换信息的物理方法是不同的。

Web 服务的影响

尽管平台独立 HPC  系统非常常见（比如   MPI ，它支持多个平台和架构），但   HPC  解决方案并不能直接使用，并且许多使用仍然依赖于架构的统一。

典型网格的不同特性导致工作分配方式发生了变化。因为网格节点可能基于不同平台和架构，所以在不同公用和私用网络上，需要某种以平台为核心的交换工作和请求的方法，该方法使分配工作变得更容易，不必担心目标环境。

Web 服务基于开放标准，使用  XML   来分配和交换信息。该效果实质上将消除在平台和架构间共享信息的复杂性。您可以编写一系列支持不同操作的   Web  服务，而不是编写跨网格执行的二进制应用程序，这些   Web  服务是为各种节点和平台量身订做的。部署   Web  服务的费用也比较低，这使得它们对于不使用专用计算节点的网格中的操作比较理想。

通过消除兼容性问题并简化信息分配方法，Web  服务使网格的扩展变得更轻松。使用   HPC  解决方案，通常必须使用基于相同硬件的节点来扩展   HPC  环境的功能。而使用网格，特别是在使用   Web  服务时，系统几乎可以在任何平台上扩展。

网格和 Web  服务的其他问题是由于不再应用关闭的   HPC  系统和内部   HPC  系统而导致的常见分配和安全考虑事项。在   WAN  或公用网络上使用网络节点时尤为如此。对于   HPC  解决方案，系统的安全可通过硬件的统一特性得到控制；对于某一位置上的所有机器，安全性更容易控制。

为了提高 Web  服务的互操作性，特别是在网格环境中，  OASIS  团队开发了许多   Web  服务标准。这些标准都是通过其   WS  前缀来标识的。通用规范包含一些顶级   Web  服务支持和全面保护规范，用于发现   Web  服务和选项以及信息交换（通过   WS-Security ）。

更深一层的标准提供了用来共享资源和信息的标准化方法（WS-Resource  和   WS-Resource Framework ）、用来可靠地交换消息的标准化方法（ WS-Reliable Messaging  ）、用于事件通知的标准化方法（ WS-Notification ），甚至是用于   Web  服务管理的标准化方法（  WS-Distributed Management ）。

出于安全考虑，可以将 WS-Reliable Messaging  交换与   WS-Security  标准包装在一起，这定义了用于身份验证、授权和消息交换加密的方法和过程。

通过将 Web  服务标准支持、安全规范和您自己的定制   Web  服务组件结合在一起，可以构建一个使用多个平台和环境的高效网格。然后可以在  LAN   环境中使用应用程序，或者安全地通过公用网络提供与典型  HPC  解决方案同样强大的计算资源，但具有扩展的灵活性和对网格技术的标准支持。

[Image 1]: