服务器群集技术

群集（Cluster）技术
群集（Cluster）技术是近几年兴起的发展高性能计算机的一项技术。

它是一组相互独立的计算机，利用高速通信网络组成一个单一的计算机系统，并以单一系统的模式加以管理。

其出发点是提供高可靠性、可扩充性和抗灾难性。

一个群集包含多台拥有共享数据存储空间的服务器，各服务器通过内部局域网相互通信。

当一台服务器发生故障时，它所运行的应用程序将由其他服务器自动接管。

在大多数模式下，群集中所有的计算机拥有一个共同的名称，群集内的任一系统上运行的服务都可被所有的网络客户所使用。

概述
群集技术使得网络主管们可按其所需向网络中添加资源而无需对网络结构进行大规模的改动。

网络主管们都清楚一件事——两点之间直线最短，然而在实际工作中他们却总是花费大量宝贵的时间绕道而行，尤其是在维护和升级各种服务器时更是如此。

他们总是喜气洋洋地抱回一台崭新的服务器，在用过一段时间后才发现它无法承受庞大的网络流量所带来的压力。

于是这台当初崭新的机器便被淘汰掉，代之以一台更新更庞大的机器，最后依然是同样的结局。

网络就像是一个永远无法完工的建筑工地一样。

这正是群集技术所要解决的问题。

通过将众多计算机协同起来完成一样工作，群集技术使网络具有了无限的可伸缩性，就像一座房子，无需将其推倒重建也可以使其焕然一新，并且由于被群集在一起的计算机可以协同工作，系统的可用性也大大地提高了。

一旦某个结点出现故障或无法工作了，群集中的任何一台机器都可以接替它完成工作。

更吸引人的是，群集技术使网络管理人员不用再为设计服务器的能力而费神了。

它允许你依照需要向网络中添加资源，量体裁衣。

这种为网络度身订做服务器的方法使得网管工作更有效率且更为节约资金。

它省去了因服务器能力不足而带来的麻烦，避免了因服务器能力强大得超过了实际需要而带来的浪费。

这一切听起来很美妙，但群集技术也被冲突和复杂性所困扰着，要使其正常运转就必须对不同的网络架构及其优缺点都有所了解。

它还意味着你必须先解决几个难题：首先，将软件与硬件群集结合起来是比较困难的；其次，已有的应用程序需要被大量改写；第三，这项技术并不是唯一的和最好的解决方法。

在某些情况下，采用对称多机处理(SMP,Symmetrical Multiprocessing)服务器可能是更好的方法。

群集分类
不幸的是，“群集”一词用法广泛且意义含混不清。

今天，“群集”一词至少有三种指称对象——服务器群(Server Farm)、双机热备份群集(Failover Cluster)和耦合群集(Coupled Cluster)。

服务器群是一种最古老和最简单的解决方法。

它由一系列节点机组成，这些节点机从一个称为“管理器”的中心单元处获取任务。

当网络中存在着大量的计算和处理需求而节点机之间的通讯量很低时，这种方法不失为一种简单有效且强大有力的技术。

Pixar动画制作室使用一个服务器群来完成电影《玩具总动员》的动画设计工作。

在这一过程中，总体的应用是由许多小的、精细复杂的子任务组成的。

每一个子任务都由群集中的一台节点机单独完成。

群集所具有的最基本的容错性能保证了，一旦对某台机器发出的请求失败，“管理器”可以将这一请求重新分配给其它机器。

然而，服务器群技术是以“严格的平行”而著称的。

当遇到需要所有机器协同完成
一样工作的情况(这种情况是很常见的)时，这一模式便不再适用了。

双机热备份群集代表了另一种相对古老且极为简单的网络架构。

它把精力放在了可用性而非可伸缩性上。

它通常由两个节点组成——一个主节点和一个备份节点。

两个节点共同来提供不间断的服务。

如果一台机器出现了故障，另一台会马上接替它工作。

通过利用紧密地协同在一起共同完成同一工作的多台机器，耦合群集所关注的不再是简单的可用性或可升级性问题了。

与服务器群不同，在耦合群集中每台机器的工作不再是相对独立的了。

它需要进行大量的跨节点通讯。

与双机热备份群集不同的是，可用性是由整个群体共同来提供的。

这意味着耦合群集有能力从容地处理多点故障。

四个优势
与SMP这样的单机解决方案相比，耦合群集技术至少有4个较为明显的优势——绝对可伸缩性、相对可伸缩性、高可用性和高性价比。

绝对可伸缩性是耦合群集技术最明显的优势。

在处理能力方面，庞大的群集可以令最庞大的独立服务器相形见绌。

相对可伸缩性是指网络通过使群集不断成长而满足其不断增加的应用需求的能力。

耦合群集在这方面的优势更加明显。

耦合群集的相对可伸缩性使得网络主管们不必再在价格低廉但有可能很快就不能满足需求的小系统和昂贵、庞大的但却可能由于应用不足而闲置的大机器之间做出痛苦的选择了。

耦合群集淘汰了那种叉车式的推倒重来的升级方法，因为在每次系统升级时这种方法都使得以前的投资付之东流。

能否提供高可用性与网络的可伸缩性同样重要。

由于每台节点机都有其自己的总线、供电系统和磁盘系统，任何一处单点失效故障都无法使整个群集瘫痪。

在多数情况下，容错性都可以由软件来实现。

麻烦的是，这类软件的开发通常是比较困难的。

耦合群集在性价比上也胜过了具有高处理能力的服务器。

通过使用通用的构建模块，花上少得多的钱就可以构建一个与单个大型服务器具有相同或更高计算能力的耦合群集。

面临的难题
群集技术有明显的优势，但其缺陷也同样不容忽视。

开发群集环境下的应用程序主要是程序员而不是网络主管们的工作。

但如果想提供最优化的代码，程序开发者就需要尽量多地了解一些关于网络流量的信息。

从本质上讲，编写得出色的这类应用程序必须能够解决3个主要问题：系统部分失效、共享内存及对群集的管理。

对系统部分失效的处理能力是指当系统的某个子设备出现故障时它的容错和适应能力，这一能力是对商务应用程序的最基本要求。

独立的工作站和SMP主机永远不需要处理这类问题，因为单独的一台机器不是正在运行就是宕机了。

群集则不然，它的任何一部分都有可能失效。

不同的应用程序对此的反应是不一样的。

需要指出的是，“失效”在这里不仅仅是指硬件，如果某个应用程序需要使用某段内存，却被告知该内存段无法被访问，进程就会失败。

有两种办法可以用来对付部分失效。

高可用性群集可以最大限度地确保每台机器的正常运转。

在这类群集中很少出现某个节点失效或因所需的系统资源无法获得而使进程中止的情况。

另一种方法是通过容错技术来实现的。

容错群集确保系统的全部资源总是可以获得
的。

这种特性是交易处理系统所必需的，所有系统承诺了的交易过程都必须具有容错特性。

那么，企业级网络的主管们应该采取哪种方案呢?对于新手，高可用性系统比较容易管理。

这种系统一般都比较保险。

网管们首先要注意系统是否听话，比如在无法对子设备中的数据进行访问后系统是否正常或重新发送失败了的请求是否方便等。

重发请求是目前最简单且最普遍的对付请求失败的方法。

这一方法通常是由查询管理器来实现的，它反复地重试失败了的请求直到它们得到响应，这样便将故障部分与客户端分离开来。

对付请求失败的另一个方法是所谓的“伙伴系统”(Buddy System)。

在该系统中，每台节点机都与一个独立磁盘冗余阵列(RAID，Redundent Array of Independent Disk)子系统相连，再通过RAID子系统与另一节点机(伙伴机)相连。

在系统正常运行时，每台节点机都只访问自己的RAID。

一旦某节点因故障而失效，其伙伴机将自动处理所有的对失效节点机的存储设备的访问。

这样便使得在接受请求的节点机失效时，发出请求的节点机可以通过访问其伙伴机来完成请求过程。

这种方法以最低的成本实现了节点与磁盘系统的高容错性。

系统错误可能会加重伙伴机的工作负荷而影响其性能，但数据仍可以被访问到。

共享内存也不失为一种好办法，至少对于耦合群集来说是这样的。

正如前面所提到的，共享内存的目的是使整个群集在应用程序看来仿佛是一个单独的实体。

有几家公司出售专为共享内存式耦合群集而优化了的硬件，称为SMC。

这些机器设备简化应用程序的接口，使得应用程序不必再为群集中的每个独立元素而花费精力了。

但这种方法有两个缺陷。

首先，SMC加重了防止系统部分失效的应用程序的负担——某个请求的失败甚至会引起整个进程的失败。

通过改写程序，让程序将失败了的请求发送给群集中的其它节点或许可以避免类似的故障，但这样做便使得共享内存变得没有意义了。

其次，应用程序的效率会依数据是来自于本机内存或缓存还是其它节点而呈现出巨大的差异。

如何有效地对群集进行管理也是一个难题。

最基本的一个问题是，现有的群集管理工具都还不成熟，理论上，管理工具应该具备两点特性。

首先，它们应该确保所有的机器具有相同的功能，或者至少差异不是很大。

这并不是说所有的硬件必须完全一样，但节点的功能至少应该是对称的或接近于对称的。

从网络管理的角度来看，这意味着任何两节点都可以在功能上互相替代，因而对所有的节点的监控和配置也应该是一样的。

其次，管理工具应该能够通过一台远程终端对所有的节点进行监控和配置，而通常的做法却是通过分别登录到每台节点机上来对其进行管理，这并不是一个好办法。