这篇文章是《集群的可扩展性及其分布式体系结构》的第三篇。主要介绍集群的软硬件结构的层次结构模型、主要的分类方法和决定集群设计的四大要素:HA、SSI、作业管理和通信。笔者旨在通过几个不同切入点的分析,构筑集群的抽象模型,使读者在现实中分析、设计集群时有所参考。 分层模型 首先,我们先来看一下组成集群计算机系统主要部件有哪些: * 多个高性能的计算机(PC、工作站或者SMP服务器) * 优秀的操作系统(分层结构或者基于微内核) * 高性能网络开关(千兆位以太网或者类似Myrinet的专有开关网络) * 网络接口卡NIC * 快速通讯协议和服务(如活动消息和快速消息) * 集群中间件(单一系统映象和可用性支持) o 硬件,如DEC的内存通道、硬件DSM和SMP技术 o 操作系统内核或者粘合层,如MC和GLUnix o 应用程序和子系统 + 应用程序,系统管理工具和电子表格 + 实时系统,软件DSM和并行文件系统 + 资源管理器和调度软件,如LSF负载均衡和CODINE分布式网络环境的计算 * 并行编程环境和工具,编译器、PVM、MPI * 应用程序:串行和并行 这些组成部件并非在每一类集群系统中都是必须的,多数系统往往只实现其中的几种,主要是根据具体的需求来定。但如果以参考模型的角度来看,对于理解各个部件所处的位置及其作用来说,建立层次结构描述有助于从整体了解集群。 这里我们发现,集群的组成涵盖了软件到硬件的几乎每一个方面。如果把集群想象成类似OSI互联参考模型一样具有层次结构的话,那么从底层到顶层,覆盖了现有的硬件构造、网络设计、操作系统、中间件以及应用环境等所有层次的技术面。那么,在每一层选择什么样的技术就异显重要。采用现有的成熟的产品技术,可以大大降低构造集群的技术和资金风险,而选择适当的层次和技术点作为突破,又往往是解决性能、安全或者其他特殊需求的关键。 关于集群的设计目的,好处我们在前面已经详尽叙述过,这里不再讨论。简单的说,相对于较低的费用,集群要具备以下的特点: * 高性能 * 可扩展性 * 高吞吐量 * 易用性 * 高可用性 集群的分类方式 其实,往往现实中的产品会是某几个特性的综合。对于这些特性,从不同的参考因素来考虑,集群可以有以下的集中分类方式: 集群的分类 应用目的 我在集群的研究分类时,根据集群的用途通常把集群分为三种: * 强调计算能力的高性能计算(HP)集群,大名鼎鼎的Beawulf集群就是极好的例子。 * 强调可用性的HA商用集群,开放源码社区中的Mon项目和REDHAT的PIRANAHA都是价廉物美的HA集群方案。当然,也别忘了SP2、Trucluster、Solaris MC这些老字号。 * 既有HA的能力,又可以实现HP的集群,强调高吞吐量的综合型集群,比如MOSIX,LVS。 应用总是在变化的。最早集群只为解决计算问题而诞生,随着需求的发展才出现HA商用机群,以及后来的综合性质较强的高吞吐系统,而将来也一定会有更新种类的集群出现。 节点归属 如果从节点的归属情况看,可以分为:专用集群和"兼职"集群(也有叫做独用型和企业型)。 专用型集群往往用于超级计算任务或者用廉价PC组合成大型工作站,具有以下特点: * 一般安装在机房的机架上 * 多数由同类型结点同构地组合而成 * 一般通过一个前端进行访问 该集群主要是为了取代传统的主机或者超级计算机。可以把专用型集群当作单个计算机那样来安装、使用和管理。允许多用户登录到集群上进行交互式作业或批作业。可以大大提高吞吐量,以及缩短响应时间。 构造"兼职"集群主要是为了节省成本并充分利用结点的空闲资源,特点如下: * 结点必须是完整的SMP、工作站或者PC,连接着所有必须的外围设备 * 地理上结点是分布的,不必处在同一个空间内 * 结点可以有多个"属主"(也就是拥有者)。集群管理者对结点的管理权限是有限的。而且,所有者的本地任务优先级往往高于集群的任务 * 集群大多是异构的,互联方式以标准通信网络为基础。 从上面的比较我们不难发现,使用节点资源的方式导致了两种不同归属集群的出现。专有集群中,特定个体并不拥有一个工作站,或者是一个节点,资源是集群范围内共享的,并行计算可以在整个集群上执行。"兼职"集群中个人拥有工作站,应用程序靠"窃取"CPU时间来进行运算。导致这种情况得主要原因是,大多数的工作站的CPU时间都是闲置,即使在高峰期也很少超过50%。我们也把在这种非专用的动态变化的集群上运行的并行程序叫做自适应并行计算。有些文章中的高吞吐集群也属于这一类。 组装方式 组装方式主要取决于互联技术和计算机空间技术。在松耦合的集群中,节点一般是相对独立的PC或者工作站,拥有完整的外围设备:键盘、鼠标、显示器。彼此通过LAN连接,距离上可以是在一个机房,也可以跨楼宇,甚至可以扩展到一个园区(比如校园网)的范围。随着带宽技术的发展,现在的松耦合集群已经可以跨地域范围进行资源整合。例如在网络负载均衡的集群环境中,就有不少解决方案是跨越几个城市进行集群流量平衡的,像网易的站点服务器,263的邮件服务器,可以在不同的城市之间做负载均衡。而对外却能表现出严格的"一致"性,形成统一的资源。 紧耦合集群往往从空间利用率、有效带宽等角度考虑集群的互联。大家都知道,某种程度上,网路的距离和带宽是成反比的。越是短距离的技术越能实现更高的带宽。因此,就有专用集群往往采用了高带宽、低延时的通信网络,并将节点不必要的外围设备去掉,仅仅保留必要的主机(CPU、内存、硬盘),安置在一个或者彼此靠近的机架中。这样,不仅可以充分利用短距离通讯的有效带宽,例如千兆位以太网,甚至是万兆位以太网;还可以大大节省节点占用的空间,同时也方便集中管理。在紧耦合技术发展中,甚至出现了在一个机箱内作集群的产品――Blade Cluster Server 又称 刀片服务器。 刀片服务器是一种HAHD(High Availability High Density,高可用高密度)的低成本服务器平台,是专门为特殊应用行业和高密度计算机环境设计的。其中每一块"刀片"实际上就是一块增强的系统主板。它们可以通过本地硬盘启动自己的操作系统,如Windows NT/2000、Linux、Solaris等等,类似于一个个独立的服务器节点。在这种模式下,每一个主板运行自己的系统,服务于指定的不同用户群,相互之间没有关联。不过可以用SSI软件将这些主板集合成一个单一的集群映像。 在集群模式下,所有的主板可以连接起来提供高速的背板带宽,可以共享资源,为相同的用户群服务。在集群中插入新的"刀片",可以提高整体性能。而由于每块" 刀片"都是热插拔的,就像拔插显卡一样方便,所以系统可以轻松地进行替换,并且将维护时间减少到最小。这种集群在方便管理的同时,也节约了机房机架的宝贵空间,还能充分利用短距离的高性能通信技术,可谓一举多得。 这是两种典型的集群组装方式。左边的松耦合集群安装在一个局域网范围内,通常由一个GB级以太网覆盖;右边的属于紧耦合集群,安装在一个机架中,能够使用更高带宽的通信技术,而且有很高的电气结合度,至于刀片服务器恐怕就要更紧凑一些了。另外我们可以看出,这两个集群应该都是专用型集群。 控制方式 控制分为集中控制和分散控制两种。采用集中控制的集群大多是紧耦合集群,出于空间和管理便利的考虑,允许管理员集中控制所有的结点,其控制界面可以是字符终端也可以是图形GUI。用于并行计算的Beowulf集群采用的就是集中控制的方式,管理员通过shell工具或者X接口操纵主服务器,而具体的计算结点是不可直接访问的。 对于松耦合的集群,采用分散和集中控制混合的方法。由于在松耦合结构上集中控制需要特殊的系统中间层支持,因此实现的难度较大。而成熟的管理协议如 SNMP等就可用于改环境下的资源分配和调度。另外,在松耦合的非专用集群("兼职"集群)中,日常的控制仍由各自的"属主"进行,而闲余的计算时间则交给控制器。 同构性 同构是相对的,完全的同构只是理论模型的理想。上一章节我们提到,各类分布式系统中,SMP的同构性最好,直接反映在单一系统映像这个重要的指标上。大多数情况是,集群结点采用相同的操作系统或者兼容的硬件平台,以尽可能保证二进制代码的可移植性。比如Beowulf集群中,集群结点和服务器采用的都是 Linux核心操作系统,配合标准的PVM和MPI2接口,使得计算任务能够跨越各结点的地址空间,代码和数据表达的一致使之在结点之间能够平滑迁移。 异构特性在集群的发展中日益重要。通过增强的OS扩展API或者中间件层软件,任务可以在异构的结点之间自由移动,实现某种层次上的SSI能力。在负载均衡环境和可用性支持中,一定程度的SSI是必须的。但是,由于无法对二进制的代码和数据结构兼容,必然采用性能更低的中间代码、解释程序或者是扩展动态链接库来实现异构上的"同构",JAVA语言,PVM并行库都在这一领域有着很好的应用。随着WebService和XML技术的发展,将来还有可能在多种不同的编程语言、运行环境中实现令人满意的SSI能力。 安全性 安全性取决于集群结点与外界的互联程度。如果集群的结点不论是物理连接还是IP地址,都是暴露在外的,集群内部的通信完全没有经过保护,我们认为这样的集群系统不具备安全性。黑客或者恶意用户的破坏都会造成集群的不可用。不过这样的集群由于在规划上不需考虑过多,比较容易实施。 如果将集群结点通过防火墙等保护技术隐蔽起来,使集群内部的结点无法从外部非法访问,或者加强结点操作系统本身的安全能力,那么集群系统就具备一定的安全性。因为要考虑安全环境的诸多因素,也必然要增加构造系统的难度。目前,大多数商业集群产品要么使用专有的内部通信协议来实现高效性和安全性,要么与现有的安全产品进行集成,在系统或者网络协议一层扩展安全功能。 集群设计首要考虑的几大问题 前面讲的是对于集群几类主流的归类方法。可是当你考虑将你的集群作成什么样的系统,让它具备什么功能,能够满足什么需求的时候,这些归类方法却不是那么重要。在使用或者构造一个集群之前,首先根据应用的需求,要重点分析以下的几个主要问题,这些问题并非互相独立,而是彼此互相影响的综合因素。 可用性支持 即我们通常所说的HA(High Availability)。集群通过冗余的处理器、存储器、磁盘、I/O设备、网络及操作系统映像等等,提供一种保持成本有效的高可用性。为了挖掘这些多余资源的潜力,需要使用一些技术来平滑可用性。 从关键性事务/任务计算的角度看,例如商用服务器或者重要的数据服务器,集群是一组可以作为单一系统管理的独立服务器配置,它能够共享名字空间,并且设计成可以容忍结点失效以及支持用户透明访问的计算资源,其重点不是性能而是高可用性。 对于HA在不同的应用领域有不同的作法。在OLTP(联机事务处理)中,通常使用联机热备份的方式来解决容错问题。这是冗余的一种体现,概念上也非常简单:在主系统中的软硬件失效时,重要的应用程序和正在处理的任务可以转移到"从"服务器上,这样可以避免故障并保证服务器整体可用性。该过程也叫做 failover(故障屏蔽),虽然会暂时降低服务器的性能,但充分保证了关键任务的正常。这种冗余技术与完全覆盖错误部件的组件级冗余技术不同,它采用的是面向集群的系统级冗余,而组件级冗余为了保证连续服务,往往采用电气手段进行硬件上的替换操作。 系统级容错的难点在与进程与事务迁移,要保证在线事务也能够实时容错,在处理联机事务的这一层次上,就有必要进行进程或者事务迁移的工作。在数据库层、 OS层或者是中间件层,都有不同的厂商针对性的产品来实现。仅我所知的Oracle的数据库产品,IBM的操作系统和中间件产品或者是其他第三方的组件,都有对HA不同程度的实现。 在设计健壮、高可用性的系统时,以下3项要同时考虑:可靠性、可用性及可维护性(简称RAS)。其中可用性标准最令人感兴趣,它结合了可靠性和可维护性两个概念: * 可靠性:测量在没有故障的情况一个系统能工作多长时间。 * 可用性:一个系统可以为用户所使用时间的百分比,即正常运行时间的百分比。 * 可维护性:指系统是否易于维护,包括硬件和软件维护、维修和升级等。 系统的可靠性可表示为发生故障的平均时间MTTF(Mean Time to Failure),即在系统(或系统的一个部件)发生故障前正常运行的平均时间。可维护性指标为直到修复的平均时间MTTR(Mean Time to Repair),即用于修复系统和在修复后将它恢复到工作状态所用的平均时间。系统的可用性定义为: 可用性=MTTF / (MTTF+MTTR) 提高系统的可用性基本上有两种方法:增加MTTF或减少MTTR。增加MTTF要求增加系统的可靠性。计算机工业界千方百计的制造可靠性系统,如今工作站的MTTF范围从几百小时到几千小时。然而,再进一步提高MTTF非常难且花费很大。 集群可以通过减少系统的MTTR以获得可用性,多结点集群的MTTF低于一个工作站,因此集群可靠性低,比工作站发生故障的可能性要大。然而,如果能迅速处理这些故障就可提高更高的可用性。高可用就是能够使集群发生故障是能够快速、平滑切换,保证系统连续运行的一种技术。 单一系统映像 SSI是集群系统必备的能力。并不是指在一个SMP或者一个工作站中,仅有唯一的一份系统映像驻留在内存,而是指从使用者的感觉上看,是一个独立的单一的计算机系统。那么,这也就牵涉到使用者是谁,使用目的和需求是什么,从哪一个层面上去使用该系统等问题。SSI的基本特征大致有: * 单一的系统:理想的情况是,整个集群看上去就是一个多处理机,好像一台巨大的SMP工作站。这一点和分布式系统有所不同。分布式环境中,节点的利用基本属于上述的"兼职"状态,参与并行任务主要通过中心调度器进行,彼此之间更像是一种"协同",而非"统一";同时集群作业又不能干扰本地作业的正常执行。因此,在"单一"能力的表象上相对较弱,甚至不能形成真正的SSI能力。 * 单一的控制入口:逻辑上,对集群系统的管理控制应该是在一个明确的位置进行。所有的管理操作行为都从该控制入口(比如一台专用的监控终端)进入,通过任务队列的排队,请求集群范围内的软硬件资源并适时执行。单一控制入口在设计集群的时候常常被认为不是那么重要。其实,缺乏单一控制能力的集群系统只会使得管理员疲于奔命,忙碌于节点的维护和作业调度的手工操作上,使整个集群成为一个"半自动"的东西。 * 对称能力:类似上一点,如果集群允许用户从其中不同的结点登入的话,要求用户获得的服务能力也必须相同,没有任何"岐视"。因此,除了和权限、管理、安全等敏感问题有关的功能之外,所有的功能和服务都是对等的。 * 资源访问透明:应该说,这一点是SSI能力的精华所在。在使用集群的时候,用户并不知道为其服务的服务器具体位置,所有的操作都感觉是在本地进行的。尽管资源透明的背后或许是一定程度的性能降低,但是从方便用户的角度看,无需处理繁杂的境像点、卷、域等定位的概念,仅有一个根,一个进程空间,一个ip地址,一个IO资源,那必要的性能损失还是划算的。 我们不难发现,上述的两点关于HA和SSI的简单叙述其实隐含着一些线索,将这两个看似不相干的特性联系在一起。如果没有一定的SSI能力,集群也就不称之为集群了。即使是最简单的联机热备份系统,不管是在正常状态还是进行故障接管的时候,所体现的系统"外形"(即从外部用户看来),既是单一的系统(虽然有两台机器),又能提供透明的平滑的服务。没有在OS或者更高层实现SSI的资源统一,是无法做到这种的高可用能力的。可以说,SSI是集群技术的基石,不仅为高可用的需要所服务,也为进一步的性能提高工作,因此,在设计集群的时候,首先要先进行的就是SSI的考虑。 作业管理 作业管理主要涉及任务派发、负载均衡和并行处理等功能。与传统工作站或PC结点不高的利用率相比,集群要达到系统的高利用率,作业管理软件必须提供这些功能功能。那么,在作业管理具体实现中,下面这些概念就显得非常重要了:什么是资源,什么是作业,作业有几种,如何衡量负载(Load),作业的运行包含哪些状态,每个状态又包含那些元素,等等等等,这一切都需要在集群系统中定义并加以体现。作业管理系统设计的好坏,直接关系到集群性能的高低。设计优良的作业管理和调度系统,其可扩展性要好于设计一般的集群,其影响性能的作用远远高于其他几类因素。我们将在随后的篇章里详细分析。 高效通讯 为集群,特别是松耦合的工作站集群建立一个高效的通信子系统比为MPP这样的紧耦合系统建立高效通信子系统更有挑战性。 * 因为集群有更高的结点复杂性,集群结点不能像MPP结点封装得那样紧密。而松耦合的集群应用相对普遍一些。 * 集群内结点之间物理线路的长度要长于MPP结点间的线路长度。即使是集中式的集群也是这样。长线路导致长的互连网络延时。但更重要的是,长线路有更多的可靠性、时钟扭斜和串道(cross-talking)等问题。这些问题要求用可靠的和安全的通信协议来解决,而协议又会增加系统开销。 * 集群一般使用有标准通信协议(如TCP/IP)的商品化网络(如:以太网,ATM)。商品化部件一般遵循Moore定律,但TCP/IP协议的系统开销很大。虽然低级通信协议比标准通信协议有效,但现在没有用于低级通信协议的统一标准。 追求高效往往和集群的可扩展性相抵触。想要高可扩展的集群系统,就要使用一些低效率的商品化网络,更通用的硬件平台,流行的操作系统。在保障了集群的可扩充能力的同时,不可避免的降低了优化性能的可能,采用Open Source的操作系统或许可以解决一些问题。 理想的集群模型 和OSI标准互联参考模型一样,理想的集群只在概念中存在,因为有太多的制约因素左右,实现起来就不太可能了。但不妨把这种理想结构作为研究集群的一种理论基础,有助于对现有集群的分析,和设计时的借鉴。 图:一个理想的集群系统,支持完全的SSI和HA能力 从图上我们可以看出,理想的集群支持各类的结点,可用的有工作站、PC、SMP服务器、甚至超级计算机,结点的操作系统是多用户、多任务和多线程的系统。结点彼此可以是同构甚至是异构的。 结点间由一个或多个高速商品化网络互连。这些网络使用标准的通信协议,传输速度应该比目前使用在以太网上的TCP/IP高两个数量级。商品化网络不但沟通了集群节点,完成必要的通信功能。而且也为实现SAN(存储区域网络)、一致的分布式I/O、一致的内存访问以及其他集群硬件资源的统一访问打下基础。其实,网络仅仅是物理的实现,关于资源的控制却还需借助操作系统来进行。 每个结点的网络接口电路与结点的标准I/O总线(如PCI)相连,所有的驱动模块都是可热拔插,可动态加载的。当处理机或操作系统改变时,只需修改驱动软件并重新加载,不必修改网络或网络接口,也不必重新启动系统。 在结点工作平台上有一组与工作平台相独立的软件子系统,成为集群操作系统,提供操作系统的最基本的核心功能。操作系统之上是特殊的扩展或者中间件层,用于为HA和SSI提供必要的支持。 中间件层之上便是提供高可用性服务的可用性子系统。还有一个单一系统映像层能提供单一的用户入口点、单一的文件层次结构、单一的控制点以及高效的作业管理系统。可以通过编译器或运行时间库技术帮助实现单一存储器,但集群不一定需要支持单一进程空间。 最上层便是集群的管理、控制和应用扩展实现层,用户的入口,管理员的控制,作业的调度都在这一层具体实现。具体可以通过SSI提供的标准API或者动态运行库实现。此外,其他一些扩展子系统也在该层实现,比如分布式的OLTP(联机事务处理)数据库。 结束语 在了解了集群的分布式体系结构、概念、可扩展性以及分类方式和几大要素后,相信大家对集群的基本理念已经有了一个初步的认识。集群的相关技术是一个非常复杂的体系,其中任何一点都可以足以讨论出几本书来。但我的初衷并非如此,这三篇文章仅作抛砖引玉,为随后的个案分析作一点铺垫。以后的内容将重点集中在几类主流的集群上,希望通过今后的深入分析,使大家能够更深入了解集群在现实中如何实现和应用。 |
集群的可扩展性及其分布式体系结构(3)
最新推荐文章于 2022-07-02 14:04:45 发布