您的位置：首页 > 编程语言 > Python开发

常见的几种语言C,C#,JAVA,Python的运行原理

2015-10-31 01:01 796 查看

集群的可扩展性及其分布式体系结构(3)--下

文档选项

将此页作为电子邮件发送

级别：初级

林凡, 辰讯软件工作室研发部经理

2004 年 6 月 01 日

这篇文章是《集群的可扩展性及其分布式体系结构》的第三篇。主要介绍集群的软硬件结构的层次结构模型、主要的分类方法和决定集群设计的四大要素：HA、SSI、作业管理和通信。笔者旨在通过几个不同切入点的分析，构筑集群的抽象模型，使读者在现实中分析、设计集群时有所参考。
集群设计首要考虑的几大问题

前面讲的是对于集群几类主流的归类方法。可是当你考虑将你的集群作成什么样的系统，让它具备什么功能，能够满足什么需求的时候，这些归类方法却不是那么重要。在使用或者构造一个集群之前，首先根据应用的需求，要重点分析以下的几个主要问题，这些问题并非互相独立，而是彼此互相影响的综合因素。

可用性支持

即我们通常所说的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（联机事务处理）数据库。

回页首

结束语

在了解了集群的分布式体系结构、概念、可扩展性以及分类方式和几大要素后，相信大家对集群的基本理念已经有了一个初步的认识。集群的相关技术是一个非常复杂的体系，其中任何一点都可以足以讨论出几本书来。但我的初衷并非如此，这三篇文章仅作抛砖引玉，为随后的个案分析作一点铺垫。以后的内容将重点集中在几类主流的集群上，希望通过今后的深入分析，使大家能够更深入了解集群在现实中如何实现和应用。

关于作者


		林凡，现于厦门大学从事Linux相关的科研工作。于集群技术由很大的兴趣，希望能与志同道合的朋友一起交流。您可以通过电子邮件 iamafan@21cn.com和他联系。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航