网络架构:设计可伸缩的网格 第 1 部分: 网络架构

  开始的前

  “设计可伸缩网格” 系列教程适用于希望为网格设计可伸缩性、从而实现网格最佳性能开发人员

  有关本系列教程

  网格使您能够利用多台机器处理能力即使用多个网格节点组合在 CPU 或存储空间如果您需要对网格处理能力和性能进行扩展可以向系统添加更多节点但是不能盲目添加这样做最终会达到系统极限此时网格性能不但不会提高反而会降低

  在设计网格时有很多原因都必须考虑到其中很多原因最终会影响网格可伸缩性并且从长远观点来看还会影响处理扩展方式在本教程中我们将介绍影响可伸缩性关键原因设计网格可伸缩性时需考虑策略以及在网格开发的前和开发过程中应该解决和性能和瓶颈相关问题

  有关本教程

  本教程是共分两部分系列教程我们将首先介绍各种区别网格类型以及影响和限制网格解决方案主要原因在了解这些问题同时通过深入了解可以解决这些问题网络技术和拓扑结构研究可能解决方案本教程涉及主题包括:

  网格类型和可能出现问题地方

  网络技术和解决方案

  网络架构和拓扑结构

  先决条件

  您需要熟悉基本网格结构以及网络中主要组件和实现网格部署核心技术和系统

  可伸缩性定义

  在开始介绍如何解决网格可伸缩性问题前需要对可伸缩性做个定义以及确定影响网格可伸缩性些关键问题

  可伸缩性含义是什么?

  通常在任何网格系统中最重要元素是网格性能有很多思路方法都可以对性能进行优化从对单个节点元素进行升级和改进到对整个网络和支持系统进行改进然而网格的所以如此有用它能够将任务分发到多台机器上进行处理因此在改进网格性能时个思路方法就是增加更多节点

  扩展节点数量可能会提高网格性能不过这也可能会产生负面影响所增加节点在分配节点(distribution node)、网络基础设施、支持服务和其他元素上都增加了更多负载这种情况并不少见在增加节点数目时可能会遇到区别瓶颈例如任务吞吐量方面(即可以分发并发请求数量)任务提交/响应率(由网络负载引起)或分发管理器过载(它必须能够处理客户机和各个网格节点的间数据和请求)

  根本上来说可伸缩性并不是有关网格性能它和通过向系统中添加节点来提高网络性能能力有关对于个可伸缩网格系统中其他组件 —— 网络、支持服务、分配节点甚至客户机 —— 都必须成为可伸缩性计划部分

  还有点也非常重要:要牢记使用网格关键原因即在使用大量独立系统时充分利用成本相对较低硬件性能应该避免使用高度专门化硬件处理更高负载情况通过改变应用或者通过优化和改进系统中某些元素使用方式进而改变系统组织和结构应该能够解决可伸缩性问题

  可伸缩性对区别网格类型影响

  网格可伸缩性以及用来改进和优化可伸缩性所使用工具和系统完全取决于您使用网格类型尽管有些通用思路方法和改进可以用于所有网格类型但是某些网格类型可能会出现特定问题这些问题也许对其他网格不会造成影响例如网络性能对于所有网格类型都非常重要但是网络确切参数则取决于网格类型在计算网格中重要原因通常是网络响应速度(延时)而不是原始数据吞吐量(数据传输率)

  下面列出了 4 种关键网格类型其名称并没有完全描述出网格功能不过可以在本教程其余内容中引用还有其他些网格类型和情形不过它们表示了某些参数极端使用方法当我们研究区别可伸缩性主题时会用到4 种主要网格类型有:

  高吞吐量网格 —— 在这种网格中发给每个网格节点各个任务单元通常都非常小每个单元请求和预期执行时间都很小这些网格通常会在计算系统中使用其中请求数量反应了给定或计算区别输入值范围例如在单个作业中可能有 10,000 甚至 100,000 个请求

  高计算量(High-computational)网格 —— 在计算网格中每个节点都负责为或表达式提供 CPU 处理能力每个工作单元持续时间可能会很长(和高吞吐量网格中较短执行时间相比)

  高内存量(High-memory grid)网格 —— 在处理大量数据时使用这种类型网格例如计算机动画绘图、计算流体动力学(CFD)分析或制造和监视系统中处理大量数据集所使用网格

  存储网格 —— 存储网格在需要将大量信息存储在大量计算机上时使用所以数据大小以及从网格存储/检索信息这样负载被分布到网格中

  为便于描述可能存在问题地方请参看图 1图中给出了网格网络基本布局信息流从客户机发往分配节点经过网格节点网格节点和分配节点都使用了支持节点来实现完整功能例如安全性、认证和数据/状态存储在查看网格类型及其可伸缩性问题时我们将介绍橙色(潜在问题)和红色(实际问题)显示警告问题

  图 1. 基本网格布局

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  有了上面定义网格类型让我们了解下影响这些网格类型可伸缩性潜在问题

  高吞吐量网格需求

  在高吞吐量网格中系统中有很多潜在瓶颈和容易出现问题地方必须解决这些问题以提高可伸缩性高请求数和低请求持续时间在某些特殊情况下将导致问题图 2 对这些问题进行了整理总结

  图 2. 高吞吐量网格中可伸缩性问题

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  更详细地介绍说明:

  分配节点就是个潜在瓶颈经过系统请求数会非常多要想生成并发送大量请求 —— 尤其是连续进行这种处理(即请求数将超出网格节点数) —— 就需要大量处理能力

  网格节点和分配节点的间网络也是个潜在瓶颈此处问题并不是由于网络信息量引起(因此也和传输速度无关)请求都非常小相反问题主要根源在于大量数据包以及网络延时网络延时是建立连接速度而不是传输速度在有大量小请求系统(尤其是在这些请求要经过大量主机时)中如果出现较长网络延时就会导致可伸缩性降低

  根据网格应用和组织结构区别支持节点和网络也都可能会出现问题如果网格部分处理过程依赖于大量对安全服务请求或对数据库中数据查询就需要相应地处理这个问题随着网格规模和节点个数增加这些组件上负载也会增加

  由于延时问题缘故高吞吐量网格在网格类型中显得相当特殊对于大部分网格类型来说反而是网络速度更容易出现问题只有高吞吐量网格才需要担心网络延时问题

  高计算量网格需求

  在高计算量网格中单个网格节点最有可能遇到性能问题由于网格节点大量使用 CPU因此这种网格类型中最关键组件就是确保在网格规模变大时为所有节点持续提供作业通常在计算网格中都需要高度并发性您可能会希望相同计算或相同计算组件能够同时完成和大量网格节点同步进行通信能力会增加分配节点负载

  不过网络需求还是很适度您并不总是需要高速连接能力以及高吞吐量网格中所需要那种低延时网络;不过您网络确需要能够和众多节点进行同步通信例如如果每个请求大小为 10 KB那么理论上个 10 Mbps 以太网网络只能并发处理 125 个这种传输实际上您很少会达到最大处理能力 80%也就是 100 个并发交换

  虽然确切限制显然依赖于网格网络和应用不过图 3 对这些限制进行了整理总结

  图 3. 高计算量网格中可伸缩性问题

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  您还会注意到网格节点也被显示为可能出现问题地方了由于作业计算特性这个问题确实存在节点要能够接受任务并对其进行处理点非常重要要实现最佳性能和可伸缩性您必须尝试并满足性能以及跨网格节点加载需要“Bandwidth management in grids”(请参看 参考资料)文提供了有关处理这些问题更多信息

  高内存量网格需求

  高内存量网格例如 CFD 分析中使用网络依赖于和网格节点进行交换大量数据这些数据可以是由分配节点直接提供也可以是由支持节点间接提供结果通过分配节点返回到支持节点

  不管信息源是什么网络性能以及可以快速交换大量信息能力是网格可伸缩性关键如果您增加了节点个数网络速度太慢就可能意味着节点在那里空等数据而不是处理请求下面整理总结了这些限制:

  图 4. 高内存量网格可伸缩性问题

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  我们可以确定下面问题:

  网络性能 —— 具体来说就是按照能够保持节点非常繁忙速率交换信息能力 —— 这种能力非常重要不过这种能力并发性并不是十分重要这是由于任务特性决定;区别节点可能会以区别速率对信息进行处理因此网络上并发负载很少

  支持节点或分配节点(至少是要处理数据源)必须能够处理大量数据量尽管总并发网络负载应该不成问题但是对于支持节点来说数据聚集会很高还需要记住支持节点必须能够在物理上以保持系统繁忙速度提供信息;并且尽可能保持网络饱和从而使网格节点保持繁忙状态

  分配节点需要能够从网格节点接受响应它们需求和上面介绍支持节点类似分配节点上数据集中程度要远远高于网络上其他地方如果分配节点负责为网格节点提供信息那么数据集中程度仍然会非常高

  通常在高内存量网格中来自网格节点结果数据被聚集到个数据结构中并被发送回客户机因此主要问题依然在于网格内部而并没有超出网格范围点对于最后种网格解决方案 —— 存储网格并不适用

  存储网格需求

  在存储网格中通常会有来自客户机大量信息(或者说大量较小请求)它们会首先通过客户机网络接口集中在最终通过分配节点分发到适当网格节点上下面整理总结了需要注意几点

  图 5. 存储网格中可扩展性问题

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  关键元素是遍及系统网络当和网格节点或外部客户机交换数据时网格内存有大量数据因此可以很轻松地交换信息

  分配节点是在个典型存储节点中实现可伸缩性最大障碍随着网格节点数目增加会有更多数据需要通过分配节点在内部和外部组件的间进行交换根据网格应用区别分配节点性能可能需要随着网格节点数量线性伸缩例如这就意味着10 个网格节点(需要 10 Mbps 连接来处理数据吞吐量)需要个能够分发 100 Mbps 数据分配节点如果扩展到 100 个节点就需要 1Gbps 分配节点

  网络技术

  从对网格节点和可伸缩性讨论来看显然网络结构、拓扑和所使用技术对于网格可伸缩性都非常关键如果网络环境是不可伸缩那么您网格也将无法伸缩在本节中我们将介绍可以解决核心网络问题主要考虑事项以及些举例技术

  网络延时、速度、吞吐量和可伸缩性

  影响网格可伸缩性关键网络原因有延时、速度、吞吐量和可伸缩性它们解决了网格解决方案中有关网络系统潜在可伸缩性各种问题下面将逐介绍这些问题:

  网络延时是启动网络上两个节点的间通信通道所需要时间延时受到很多原因影响随着网络中节点数目增加这个问题会变得更加严重尽管延时并不会影响数据传输速率但是它确实延迟了传输启动

  网络速度是系统网络接口理论速度物理网络速度通常是指整个网络数据传输速度必须被所有节点共享

  网络吞吐量是网络上单个点可以实现持续不变速度吞吐量是由网络结构/拓扑所决定对于某些网络类型来说吞吐量会比较低这是其结构强制网络通信只通过单个节点传递

  网络可伸缩性决定了多少节点可以连接到网络单个例子上显然网络解决方案可伸缩性和网格可伸缩性的间存在直接关系如果您选择网络解决方案在单个网络中只能支持 100 个节点那么显然这也会成为网格限制

  这些参数结合起来严格控制着网格可伸缩性例如高内存量网格中网格吞吐量尤其是经过分配节点吞吐量要依赖于网络吞吐量

  常用网络硬件

  在谈及常用硬件时我们要讨论是以太网这是大部分计算系统中使用种网络硬件因此其价格低廉并得到很好支持这种支持非常重要硬件使用范围越广泛网格网络部署也就越容易并且您无需担心操作系统是否支持因此可伸缩性也得到了增强它很容易使用并且部署不受限制

  使用以太网和其他些不太常见解决方案(例如 Firewire 或 USB)问题是它们速度和单个网段中所支持节点最大数目有些限制它们还容易产生非常明显延时这是较低延时需要更高成本组件

  使用以太网速度可以达到 10 Gbps(在使用全双工模式时甚至可以达到 20 Gbps)但是其吞吐量要受到单个系统中可以使用最快速率限制通过使用个网络交换机您可以将多个较慢节点吞吐量合并成个吞吐量更大节点例如使用个可以支持 24 台主机、吞吐量为 100Mbps 主机交换机其中每台主机吞吐量为 1Gbps这种情况并不少见

  然而网络最大吞吐量仍然只有 1Gbps这种环境优点是您可以为网格网络中区别元素分配最适当网络接口速度这实际上非常有助于实现可伸缩性

  专用网络硬件

  在使用专用网络硬件时您就要花费更高成本了其优点是您可以获得更高数据传输速率减少网络节点限制并可以显著改善网络延时例如Infiniband 网络标准速度最高可达 30,000 Mbps最多可以支持 10,000 个节点其延时只有 6µs然而要实现这个目标网络拓扑和结构需要遵循更严格规则例如使用 Myrinet 和 QsNet 解决方案时单个网络中被限制为只能有 128 个节点更多网络节点只能通过使用专用网络交换机支持这种交换机让您可以将这些小型网络合并在构成个 4.096 甚至更多节点节点组

  Myrinet 和 QsNet 可能延时是 2µs其结构提供了连接单个节点端到端连接能力而不是以太网所支持总线模型这将导致更低节点间通信时间这对于节点间需要协作计算网格来说非常有用

  这些解决方案吞吐量还受到网络解决方案整体吞吐量限制网络中所有节点都使用了相同网络接口因此具有相同速度和吞吐能力不过它并没有提供以太网提供相同灵活性或聚集样式架构

  网络支持和限制整理总结

  有关网络技术以及其对区别网格类型适用性更详细讨论已经超出了本教程范围不过表 1 对区别技术速度和限制进行了整理总结

  表 1. 定义每种屏幕类型使用对象类

技术 通道 最高速度(Mbps) 典型速度(Mbps) 延时 可伸缩性
以太网(10 Mbps) 1 10 1.2 100µs 1024
以太网(100 Mbps) 1 100 12 100µs 1024
以太网(1 Gbps) 1 1000 125 100µs 1024
以太网(10 Gbps) 1 10000 1250 100µs 1024
Infiniband(x1) 1 2500 162 6µs >10,000
Infiniband (x4) 1 10000 1250 6µs >10,000
Infiniband (x12) 1 30000 3750 6µs >10,000
Myrinet 2 2000 248 6.3µs >10,000
QsNet 2 4200 350 4µs 1024
QsNetII 2 8500 900 1.8µs 4096
SCI 1 1600 200 4µs >512
Firewire >1 400 50 ~100µs 64
Firewire 800 >1 800 100 ~100µs 64
Firewire 1600 >1 1600 200 ~100µs 64
USB >1 12 1.5 ~100µs <128
USB2 >1 480 60 ~100µs <128



  本教程余下内容将介绍以太网网络它不仅容易理解而且还为解决方案结构提供了更多灵活性

  网络结构和性能

  网络硬件肯定会影响所使用网络结构和拓扑结构不要忘记这即使是在网络硬件能力限制的内它也会对网络结构和拓扑结构产生影响要考虑区别结构以充分利用可用功能例如使用以太网的类常用硬件部署非常简单而且价格也不贵然而其对节点数以及总体性能限制可能会限制添加节点能力即使使用专用网络硬件如果单个网络可伸缩性和性能没有达到您需要级别可以将更多网络添加到网络结构中例如以下任或全部思路方法都可以有效地改进总体性能:

  将客户机和网格环境网络分离

  将分配节点到网格节点和网格节点到支持节点网络分离

  将每组网格节点网络分离

  高负载系统(分配/支持节点)使用其他网络接口

  所使用准确模型和解决方案还取决于其他考虑因此本教程后面内容我们将回到讨论主题以及可能解决思路方法

  网络结构和解决方案

  网格整体结构和架构以及可能解决方案依赖于我们已经讨论所有主题现在我们将通过查看几个具体举例了解如何使用前面几节介绍知识解决问题从而获得个更全面解决方案我们将查看些能够更轻松地扩展网格环境解决方案以及每种解决方案局限性

  使用多个网络接口

  分配节点通常都是网格吞吐量主要限制尤其是当网格中节点数目增加时这个问题更加突出随着节点数目增加您可能会达到所使用网络解决方案可伸缩性限制或者是网络带宽限制

  通过将网格节点划分成更小并在成组网格节点和分配节点的间提供个惟接口您就可以在扩展网格同时消除瓶颈问题下面展示了个简单举例

  图 6. 使用多个网络接口

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  每组节点数量取决于带宽需求在高吞吐量或高计算量网格中带宽需求非常低因此每个接口上仅支持 100 个或更多个节点即可在高内存量或存储网格中带宽需求可能产生更小每个接口只有 10 个或 20 个节点

  请记住随着分配节点上网络接口数量增加分配节点需要处理任务和数据数量也会增加这会引发多个问题

  使用子分配节点

  在个网格中如果通过分配节点从客户机发往网格节点数据非常少(例如高吞吐量和高计算量网格中)那么主要限制就是分配节点管理支持执行作业所需要大量并发连接和请求能力随着网格扩展这个问题会愈发严重

  种可能解决方案是控制个分配节点执行任务将分配各个任务单元实际管理分发给多个子分配节点如下图所示

  图 7. 通过附加分配节点对作业进行子分配

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  下面考虑下计算网格中个任务请求它所涉及计算数值范围从 1 到 30,000在 300 个节点网格网络上执行使用如图 7 所示结构您可以将范围 1 到 10,000 计算分发到子分配节点 1 上并在前 100 个网格节点上进行处理;将第 2 部分内容(10,001 到 20,000)分发到子分配节点 2 上;依此类推

  从可伸缩性观点来说这个结构提供了个最佳模型它使您可以根据网络中节点数目和预期任务级别来对主要限制点(分配节点)进行扩展如果您向网格添加了 200 个节点就可以添加另外两个子分配节点来处理作业分发

  在非常大型网格环境中您甚至可以向系统添加额外从而确保每层上分配节点性能都可以匹配它们支持任务级别和网格节点需求例如图 8 给出了 3 层分配节点创建个 2级网格它让您可以更加有效地将任务分发给网格节点主要部分

  图 8. 多层子分配节点

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  使用子分配节点解决方案中分发管理器直接负责创建通过网格分发各个任务单元既然可以分发任务创建因此也可以将分发管理器分发对于分发管理器既是网格瓶颈又是客户端瓶颈网格来说您需要个稍有区别解决方案

  使用分布式分发管理器

  在第 1 部分存储网格举例中系统关键瓶颈是分配节点网络接口在这里不是限制原因不过却可能成为和分配节点处理大量信息有关广泛问题的如果存储节点要处理大量文档网络带宽可能并不会是什么问题问题可能是分配节点必须处理大量数据和请求子分配节点在这种情况中不会有所帮助架构依赖于处理所有请求单个分配节点

  您需要做是将分发负载扩展到多个分配数据节点上同时要保留实际控制并管理分发但却不会直接处理数据节点您可以看到下面这个举例

  图 9. 分布式分发管理器

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  从架构观点来看将任务提交给网格以及分发任务思路方法已经发生了变化可能模型有两个:个需要修改客户机应用因此它可以和网格管理器进行通信来确定使用哪个节点处理剩余查询第 2个模型在客户机和分配数据节点的间使用了个通用负载均衡设备客户机并不清楚自己正在使用是哪个分配数据节点实际上分发管理器只控制网格节点的间任务分发直和各个分配数据节点联系来帮助监视网格负载分布式分发管理器模型具有很好可伸缩性您可以进步向系统添加分配数据节点来处理来自客户机负载

  同样原则也可以适用于其他领域例如您可以在系统中引入多个支持节点它们相互进行通信从而提供数据、认证或其他支持信息然而每个支持节点都分别负责处理组网格节点负载可以直接进行处理也可以通过个负载均衡系统进行处理

  使用单独网络

  如果个网格中支持节点和相关系统是系统瓶颈或者支持它们所需网络负载是限制原因您可以使用很多彼此分离网络它们会将负载从主网格网络上分离出来这是个和本教程开始介绍基本网格结构类似模型不过如果您应用了此处介绍原则并且提供了多个支持组件那么就可以将这个解决方案进步完善

  在图 10 中您可以看到除了为各个网格节点提供连接主网络的外我们还对数据库和安全服务使用了单独网络

  图 10. 分布式分发管理器

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  在这个例子中解决方案需要 3 个单独网络红色表示数据库网络绿色表示安全网络黑色表示分配节点接口连接主网格在每个网格节点中有 3 个单独网络接口 —— 每个网络接口用于网格节点和的通信网络

  使用网格组

  前面解决方案针对系统中特定瓶颈这些解决方案可以解决网格中节点特定网络接口问题以及分发器所引起问题还能解决各个网格组所引起问题我们可以组合这些解决方案从而产生个可伸缩网格事实上可以将它看作种网格类型描述这种解决方案最简单方式是了解整个结构如下所示

  图 11. 网格组

设计可伸缩<img src='/icons/92229de.gif' />网格<img src='/icons/92229dou.gif' />第 1 部分: 网络架构

  在这个解决方案中前面介绍每种建议使用方法都有所区别因此整体解决方案也会区别:

  子分配节点解决方案将任务负载划分到多个分配节点上这可以帮助扩展分发请求负载和网络负载

  使用单独网络来处理区别组件的间通信

  使用单独网络接口来帮助将网络带宽负载划分到各个组件中

  按照分组形式组织支持节点并且通过另外单独网络互相连接以提供协作信息

  每个网格组都有自己专用分配节点和支持节点

  其结果是将每个小组都作为个单独网格进行操作;不过通过连接到主分发管理器整个系统依然可以作为个网格工作

  要使系统工作您需要对现有应用和环境进行很多修改在本系列教程第 2部分和最后部分中我们将更详细地介绍这些内容

  结束语

  网格解决方案可伸缩性对于确保网格可以随业务需求而扩展来说至关重要当您需求扩展到需要个 150 节点网格时如果您网格不能处理这种需求就无法构建个 100 个节点网格以优化您关键应用

  在本教程中我们已经介绍了各种主要网格类型这样就可以确定您网格解决方案中可能存在可伸缩性方面主要障碍的后我们使用大量区别解决方案尝试对各种问题应用网络拓扑来解决具体问题

  这些并不是为问题提供解决方案原因因此在本系列第 2 部分中在最后修改网格应用操作方式的前我们将介绍网格中各个节点遇到具体问题包括硬件改进和操作系统影响

Tags:  组织架构设计 软件架构设计 架构设计 网络架构

延伸阅读

最新评论

发表评论