Win2003高可用之道2:服务器集群
【IT168 专稿】在该系列的第一篇文章中给出了针对嵌入在Windows 2003服务器操作系统平台的两种主要的高可用性技术——服务器集群和网络负载平衡——的简要概述。我们集中论述了服务器集群的一些基本术语和基本设计原理。
如前所述，其中最重要的一点在于为每个集群资源只保持一个实例（确保它的容错性和防止“首脑分裂”的发生）。这是通过源虚拟化和节点间通信两种基本机制来实现的。
源虚拟化技术需要将每个集群服务或应用需要在一定数量的相关软件和硬件部件中实现，比如说磁盘、IP地址、网络名和文件共享，这些部件可以被分配给任何加入该集群的服务器，且必要时易于在这些服务器中进行交换，这使得采用非常具体的方法来搭建这些服务器成为可能。这样他们可以访问相同的共享存储设备、位于同一个子网或属于同一个域。比如说，要建立一个高可用性网络文件共享，你将会使用文件名和访问许可来确定一个运行该共享的磁盘驱动、一个用于远程访问的共享文件IP地址（对应网络名）和目标文件共享。
尽管这听起来似乎很复杂且耗费时间，但是所有必要的源都预先定义好了，使得该过程相当的直截了当。一旦源被确定和配置好（通过指定磁盘驱动器号，分配唯一的IP地址、网络名及文件共享特性来实现），它们将被指派给加入到该集群的任何一个服务器中（只要服务器支持它们）。一旦当前运行源的服务器失效，源可以在节点间很容易的转移。
Win2003高可用之道1:服务器集群
http://publish.it168.com/2007/0629/20070629009101.shtml
Win2003高可用之道2:服务器集群
http://publish.it168.com/2007/0629/20070629010801.shtml
单共享仲裁
通过在集群成员间的冗余网络连接上传递心跳信号，以及决定源的拥有方式的仲裁，内部节点的通信变的很容易。正如我们所指出的，仲裁的另一个重要功能就是存储最新节点配置，随即将其复制到每个节点的专用registry hive中。当节点在启动阶段加入集群时，本地拷贝被引用。因其在集群体系中的重要性，仲裁被用作三种主要服务器集群模式的分类依据：
- 单共享仲裁：仲裁被用作物理磁盘集群源。
- 单本地仲裁：仲裁作被用作本地仲裁集群源。
- 多数节点设置仲裁：仲裁被用作多数节点设置集群源。
单共享仲裁集群是服务器集群应用中迄今为止最流行的。它最接近于传统集群设计（起源于在Windows NT 4.0服务器企业版引入微软集群服务器后对该模式的持续支持），为丰富多样的应用和服务提供高可用性源和简便的安装配置。
正如它们的名字所表示的，单共享仲裁集群使用存储设计，使得每个集群成员能够访问同一组磁盘。尽管底层硬件实现相差很大（比如采用我们后续文章将详细介绍的技术：SCSI, SANs, NAS, or iSCSI），它们的基本前提是一致的。
在群中，任一给定的时间只允许有一个特定源的实例。对于位于高可用性磁盘卷并通过SCSI总线、光纤信道连接或网络基础设施连接到集群内的所有服务器的仲裁源，这一要求同样适用。共享卷的使用权要通过裁定来获取，以保证它仅授予给一个节点，这样就防止了其他节点的同时访问的情况（这很容易导致数据讹误）。
该种裁定是通过内部SCSI命令（比如SCSI预定和SCSI释放）和总线、对象或逻辑单元数（LUN）的重置来处理的。具体情况取决于所应用的存储技术类型。注意，是否支持集群安装要根据对硬件兼容性列表（Windows Server目录的一部分，包含微软认证的所有集群解决方案）的严格依从而定，因此，确定你所准备购买和配置的系统的类型是很关键的。在这里，仲裁以物理磁盘资源的方式实现,需要有一个对于所有集群节点都能够访问的独立卷（集群设置会自动判断所选择的卷是否符合必要的标准）。
不幸的是，搭建集群服务器所需的大多数硬件相对而言非常昂贵（尽管现在这种系统的价格要比几年前要便宜很多），特别是你想要保证包括光纤信道、网络设备（比如适配器和交换机）或磁盘阵列以及它们的控制器在内的每个构件的冗余性的话。尤其对于那些只想开发能具有集群意识的软件或探索将现有应用嵌入到集群环境的可能性的程序员来说，硬件系统的价格还是太昂贵了。
单本地仲裁
为了补救这个问题，微软通过允许在只有本地存储的单个服务器上安装集群（就是大家熟知的单节点集群）的方式来获得这些功能，而不需要专门的硬件设备。很明显，这样的配置不具备任何程度的高可用性，但具备应用开发和测试所要的所有特性。既然本地磁盘没有作为物理磁盘源来使用，在初始设置阶段运行新服务器集群Wizard时，这种集群模式需要用到一种称为本地仲裁的独特源类型，以后我们还会对它进行详细的论述。
尽管有前面所提及的优点（比如显著的高可用性和对大多数硬件平台、应用和服务的兼容性）,单共享仲裁还是有一些局限的。第一个是其所采用的实现技术所固有的局限，比如，依赖基于SCSI共享存储的配置受连接所有集群节点到同一磁盘阵列的SCSI总线最大长度的限制（这迫使你只能将他们放在相同或邻接数据中心的机柜内）。虽然改用Fiber Channel设施连接,该距离可以显著的增加，但对硬件成本并非没有显著影响。将iSCSI 和NAS 引入到可用共享存储选择中可以使价格得到降低，不过还是存在一些需要注意的问题限制了它们的广泛使用（比如不支持NAS设备作仲裁源等）。第二个局限是尽管它有磁盘级的冗余（可以采用有容错功能的磁盘与控制器，通过RAID设置或转接来实现）单共享仲裁还是存在单点失效的问题。
多数节点设置仲裁
针对上面提到的两种局限，设计出一些第三方解决方案。同时，在基于服务器集群的Windows 2003 sever发布时，微软也以多数节点设置（MNS）仲裁的形式提出了自己的补救方案。象本地仲裁一样，MNS定义为一个独立的源，在用New Server Cluster Wizard作集群设置的过程中必需选择。同本地仲裁模式一样，NMS对运行仲裁源的共享存储器的依赖性也被消除了，且不会对高可用性产生负面影响。
在每个本地节点存储仲裁的一个副本（在%SystemRoot%ClusterMNS.%ResourceGUID%$%ResourceGUID%$MSCS文件中，%ResourceGUID%在创建时指派了一个分配给集群的128位唯一标志）可以使冗等级得到提升。正如你可以料到的，有多个仲裁实例时，需要不同的方法来防止“首脑分裂” 场景的出现。通过定义一个独立的规则来确定集群何时可操作（相应的，这对于使客户也能访问其资源也是必需的），该问题可以得到处理。为实现这种情况，要求必须有超过半数的集群节点能运行正常且能和其他节点通信，用来计算这个节点数目的公式如下：
[(MNS集群里总节点数目)/2] + 1
公式中，方括号表示取顶函数，返回大于或等于括号内结果的最小整数。例如，对于5个节点的集群，需要3个节点运行所有的可用源（这同样适用于4节点集群）。很明显，建立一个2节点MNS集群虽然在技术上是可行的，但从可用性的观点来看，这没有任何意义（因为一个节点的瘫痪将使另一个关闭其所有源）。要使一个MNS集群工作，至少要有两个服务器（在3节点集群中）是运行正常的（注意，对于单共享仲裁而言，即使只剩一个节点，它也有能力支持其源）。
这个规则有效的保证了在任何一个给定点，每个集群源都只有一个实例。每个节点的集群服务配置成在导入时间开始运行，并尝试与其他大多数节点建立通信。如果初始化失败，该过程每分钟重复一次。
该解决方案带来了另外的要求，因其体系结构意味着存在多份集群数据拷贝（这不像单共享仲裁模式），需要不断的维护。尽管集群软件本身负责拷贝所有节点间的仲裁配置，但它不能用于业务数据和特定应用数据。通常，有两种方法处理该任务。第一种依赖于嵌入应用的机制（比如SQL Server 2000/2005部署的运行日志）。第二种方式涉及到在文件系统或磁盘块级别上建立的复制。这可以通过软件或硬件得到处理，我们计划在下一篇文章详细阐述该主题。
另外，因为集群源是虚拟的，在单共享仲裁模式下的一些限制仍然存在。特别是对于源失效情况发生时，节点必须能够在没有心跳信号的情况下，检测到其他节点故障。这就要求节点间的往返延迟不能超过500毫秒-这影响到相应的节点之间的最大允许距离。这些节点还必须是属于同一个域且他们的公开与私有网络接口必需各自位于相同的子网（这可以通过设置跨越多个物理位置的集群节点的两个VLAN来实现）。
此外，因为仲裁的更新是通过一个叫%ResourceGUID%$（与先前所列的仲裁位置相关）的网络文件共享来处理的，所以服务器和工作站服务（分别为LanManServer和LanManWorkstation）必须运行在所有集群节点之上，并且为Microsoft 网络共享的文件和打印机必须在私有与公开网络连接上能够打开。
因此，当设计这样一种构架时，紧记该构架的设计将对MNS集群的可用性产生的影响是很重要的。例如，在拥有相同节点数目、由网络连接分开的两点间搭建时，如果两个站点之间的通信量很大（因两边都包含多数接点），这会导致两边都会失效。在这种情况下，建立第三个只有单集群节点的站点（与其他两个站点有专用的网络连接）是很有好处的，可以在需要时专门建立多数节点计数。此外，你也可以强制部分集群节点运行源，虽然这需要手工干涉。
