Win2003高可用之道1:服务器集群
本文是Windows Server 2003高可用性解决方案系列的开篇之作。尽管本文将要介绍的一些技术在早期windows 版本中也有介绍（像一些组件、附加程序或者是微软软件包中收购的第三方产品），不过，最新的版本具有更好的功能、稳定性和可管理性。
在Win 2003操作系统中，有两种获得高可用性的基本途径。一是采用服务器集群 (Server Clustering)方式，需要使用 Windows Server 2003 企业版或数据中心版。二是内嵌在Windows Server 2003的各版本中（包括标准版和Web版）的网络负载均衡(Network Load Balancing，NLB)。
在计算机系统设计中，这两种方式在有效消除 “单点失效”上都有独到之处。而且，这两种方式都有一个以冗余设计为基本特征的共性： 都以多台物理服务器来提高可用性，并为不同的资源（如服务或应用）采用相同配置的实例（instance）。这两种方式的主要差异在于这些实例的定义和实现不尽相同。
对于负载均衡，每个例程永久依附于所运行的物理服务器上，只要该服务器在工作，它都保持激活状态。换句话说，在服务器群工作时所有实例都在同时运行。然而，对于服务器集群技术而言，对于每个高可用资源来说，不管该集群有多少个成员服务器，都只能有一个实例在运行。当前运行特定高可靠性源的服务器拥有该源，并负责处理所有服务请求。
这种基础构架原理带来了很多挑战。既然NLB集群拥有多达32个实例在并列的服务器中运行，就需要有一种附加机制来决定到底哪一个实例来负责处理针对任意时刻产生的、任意高可用性源客户请求。必须能对每一个新引入的请求做出决定，可能必需根据配置情况独立运行。
对于服务器集群，相应的处理却很少，因为只有一个实例对应一个高可用性源。然而，付出的代价是增加了高可用性源服务器指定逻辑的复杂性，特别是该高可用性源以前的指定服务器失效后。
本文将介绍该指定逻辑以及它的具体实现方式。后续文章将以相同的方式论述网络负载均衡技术。
Win2003高可用之道1:服务器集群
http://publish.it168.com/2007/0629/20070629009101.shtml
Win2003高可用之道2:服务器集群
http://publish.it168.com/2007/0629/20070629010801.shtml
服务器集群
作为集群服务器的一个整体，加入集群的服务器（也被称为节点）必须能够与其他所有服务器互动。这可以通过建立冗余网络连接，尽量减少故障发生的可能性来实现。这样，每个节点至少应该有两个网络适配器。这两种连接构成了私有和公共的两个组，也称为“仅针对内部的集群通信”和“针对全部的通信”。在对每个成员服务器的集群安装过程中，这两种组织方式就已经被确定和配置好了。
第一组包含指定用于内部节点的链路和组内业务。尽管第二组的主要目的是传送客户与集群间的服务请求和响应，它也可以作为第一种组织方式的备份。根据在集群（和预算）中的节点数目，你可以使用各种不同的技术来实现节点的内部连接。在最简单的情况下（只有两个节点），通过直连网线就可以实现连接。当加入集群的服务器数目很大时（由Windows Server 2003企业版和数据中心版支持的服务器数目达到了8个），就必须使用一个专用的集线器或交换机。
为了优化内部节点通信——这对集群正常运行是很关键的——我们建议消除在私有网络接口上不必要的网络通信。这可以通过以下方式来实现：
- 关闭运行在TCP/IP协议之上的NetBIOS。在接口属性的高级TCP/IP设置对话框中WINS标签之NetBIOS部分中有相关选项。
- 取消对Microsoft网络文件和打印机共享——该共享配置在接口属性对话框中的常规标签（General tab）中。
- 设置适当的速度和双工模式，而不是依赖自动检测选项——在网络适配器属性对话框的高级标签中完成。
- 保证静态IP地址的可用性——而不是使用动态主机配置协议或自动私有IP寻址方式。
- 不使用默认网关， “使用以下DNS服务器地址”选项应为空，它位于因特网协议特性连接对话框。
在Windows Sever 2003中，不再需要关闭媒体感知特性。该特性可以通过更改基于Windows 2000的集群成员注册表来实现。
尽管有这些附加措施，节点间的通信仍然可能失效。因此有必要提供附加安全机制来防止一种叫“首脑分裂”局面的发生。该情况下，不能确定集群源的状态的独立节点会同时试图去激活他们自己。这样就与上述的服务器集群原则想违背，并且会导致严重问题，比如基于磁盘资源的数据讹误。
仲裁指定
为防止这种错误的发生，每个集群包含一个称为仲裁的指定源，可用专用磁盘卷标来实现。通常情况下，该卷标上含有一对镜像磁盘，以增加容错水平。镜像磁盘的最优容量为
更具体的说，节点在预设定时间间隔（每1.2秒）中,以用户数据报协议（UDP）包的格式交换“心跳”信号，以确认其网络接口的可操作性。两个连续包的缺省将触发可能发生了地址集群问题的应对机制。在基于Windows 2000服务器的应用中，该机制包括激活当前仲裁服务器上的所有源，同时，关闭其它所有节点上的源。这样就有效的保证了每个源只有一个实例在线运行,不过，在一些特定情况下，会产生不期望的结果。
尽管这种情况极少发生，还是有可能仲裁拥有者所有接口的连接都断掉的同时，余下的节点仍保持与客户网络通信的能力。结果，用户请求无法到达集群源，尽管这些源仍在运行,但是在位于无法访问到的节点上。然而其余的节点如果能获取仲裁以及所有其他源的拥有权的话，将完全有能力处理这些请求。
在基于Windows Server 2003 的集群处理没有“心跳”信号过程中，引入附加逻辑可以解决这个问题。当检测到没有“心跳”信号时，节点先检查任意指定的公开网络接口是否可以操作，而不是运行后续程序，如果可以，再检测客户网络是否可达。这可以通过向外部系统发送ICMP回送请求（比如执行PING命令）来实现的——一一般为这些接口配置了默认网关。如果拥有仲裁的节点在所有这些测试中有一个不能通过的话，它将自动使包括仲裁源在内的所有源处于失效状态。如果其他节点发现它们的网络连接仍然工作，将能轻而易举的建立一个新的仲裁服务器,并且将所有集群源的控制权交给它。
除了在通信发生故障后协助源仲裁外，仲裁还提供另一种重要的功能——存储最新的集群配置。该配置存储在仲裁卷的MSCS文件夹的两个文件中——集群存储检测点文件CHKxxx.tmp 和 仲裁日志Quolog.log。第一个文件存储了配置数据库的一个备份，是运行仲裁资源的服务器上存储于%SystemRoot%ClusterCLUSDB文件中的集群注册表池的内容的镜像。该数据库被复制到所有其他节点，并被导入到它们的注册表中（维持该信息的单一主备份以保证其一致性），每个新集群配置发生改变后都要进行复制，如果所有节点是在运行的。否则，改变被打上时戳记录在Quolog.log文件中，用于一旦离线节点恢复在线状态后的配置数据库中。了解这些情况对于解决大多数严重的集群问题是很重要的。
正如以上所提到的，仲裁是以物理磁盘上的一个卷来实现的。不过，具体的实现细节可由很多因素来确定，比如说节点数目、服务器集群类型和存储技术。该系列的后续文章中，我们将讨论这些因素并继续进行我们的服务器集群原理相关论述。