ja_mageia

摘要：本文介绍了新奥特非编网络中使用的群集技术原理，通过案例分析了群集技术的局限性。
关键字：群集、非编网络、仲裁日志、MSCS。
 

    目前非编网络在电视台已经很普及了，主机系统作为数据处理、存储与维护的核心，需要完成各种数据处理，是整个非编系统的心脏，它为系统提供数据存储和处理的基本动力，其重要性是不言而喻的。因此，主机及数据库系统通常采用双机群集模式，双机系统具有可用性高、配置灵活及易于升级扩展等优势。双机结构中，两台主机可以运行相同的应用，共同完成一个任务；也可以运行不同的应用。当某个主机出现故障时，另外一台主机可以接管故障主机上运行的业务，从而有效地保证了业务的连续性，这不仅消除了单点故障，而且对于冗余设计的双机系统来说，故障发生后系统性能基本不受影响。只有在所有服务器均满负荷运行时，故障的发生才会降低系统的整体性能。

服务器安装了微软的操作系统，使用的是微软的MSCS群集软件。群集技术，保证了域控制器、DNS、SQL Server、MDC服务的连续运行，双机模式下二台服务器共享一个SCSI阵列，通常该阵列上还保存了非编的工程文件和高压缩比素材。
 

      这里先简单的介绍微软群集技术的原理。
 

      微软的服务器操作系统提供了三种支持群集的技术：网络负载平衡 (NLB)、组件负载平衡 (CLB) 和 Microsoft 群集服务 (MSCS)。中小型非编网络中一般使用MSCS。
 

      MSCS 故障转移功能是通过群集中连接的多台计算机中的冗余实现的，每台计算机都具有独立的故障状态。冗余要求在群集中的多台计算机上安装应用程序。但是，应用程序任何时刻只在一个节点上处于联机状态。每个节点各有2块网卡，其中一块网卡用网线相连到另一个节点的网卡，俗称“心跳线”，用以监视节点的状态，当该应用程序出现故障或该服务器停机时，此应用程序将在另一个节点上重新启动。 
 

  每个节点都具有自己的内存、系统磁盘、操作系统和群集资源的子集。如果某一节点出现故障，另一个节点将接管故障节点的资源，（此过程称为“故障转移”）。然后，群集服务将在新节点上注册资源的网络地址，以便将客户端流量路由至当前拥有该资源的可用系统。当故障资源恢复联机状态时，MSCS 可配置为适当地重新分配资源和客户端请求（此过程称为“故障回复”）。要使应用程序恢复到发生故障转移时的那一点，节点必须能够访问保持应用程序状态的共享存储器。 

    每个群集都有一种特定资源 ，即所谓的仲裁资源。仲裁资源可能是执行以下操作的任何资源： 

　　 • 提供一种旨在实现成员身份和群集状态决定的仲裁机制。 

　　 • 提供物理性存储空间以存储配置信息。 

　　 仲裁日志只是一种用于服务器群集化功能的配置数据库。它保存了多种配置信息，比如群集的成员服务器都有哪些、群集中安装了哪些资源以及这些资源处于何种状态（例如，是联机还是脱机）。默认情况下，该仲裁日志位于 \ MSCS\quolog.log 。 

　　 仲裁在群集中非常重要，其主要原因有两个。以下介绍了这两个原因。 

　　 一致性 

　　 由于群集的基本设计理念就是多台物理服务器充当一个虚拟服务器的作用 ， 因此每个物理服务器在群集配置方式上是否具有一致的状态 ， 将显得非常关键。对所有同群集有关的配置信息而言，仲裁充当了最具权威性的仓库。如果群集服务无法读取仲裁日志，它将不会启动，因为它无法保证群集是否处于一致性的状态，而这又是群集最主要的要求之一。 

　　 斡旋作用 

　　 仲裁提供的斡旋作用可以避免 “ 各自为政 ” 的情况。当两个或多个群集节点之间的所有网络通讯链路都失效时，会发生“各自为政”的局面。此时，群集可能分成两个或更多个在彼此之间无法交流的“派别”。使用仲裁后，可以保证任何群集资源只会在某一个节点上进入联机状态。这是通过仅允许“拥有”仲裁的一派继续存在，同时将其它派别逐出群集来实现的。

  微软群集服务基于非共享的群集模型。非共享模型规定，尽管群集中有多个节点可以访问设备或资源，但该资源一次只能由一个系统占有和管理。（在 MSCS 群集中，资源是指任何可以联机或脱机、可在群集中进行管理、一次只能由一个节点提供并可在节点之间移动的物理或逻辑组件。）

     由上面的原理我们可以知道MSCS是一种低成本的解决方案，MSCS群集本身也有弱点，就是它依赖仲裁日志，一旦MSCS无法读取仲裁日志，无论有几个节点，服务都将中断。

  
     去年我就遇到了这样的故障，当日下班前进行例行检查，发现主服务器内存不足，于是先关闭备服务器，重启主服务器后，接着开启备服务器，奇怪的是几秒钟后主服务器报警，SQL Server服务停止，共享磁盘阵列不能访问，查看备服务器，发现显示器灯不亮，根本没有启动。于是全部关闭两台服务器，重新开启，2次下来故障依旧，于是第三次只开启了主服务器，系统能正常运行了，向非编厂家咨询，由于情况不明，故打算次日上午再联系。
 

     次日一早，开启备服务器，和之前一样，备服务器显示器灯不亮，然后主服务器的SQL SERVER和共享磁盘阵列不能访问。全部关闭后，再次重启主服务器，问题来了，这次主服务器启动后SQL SERVER和共享磁盘阵列均不能访问，整个网络瘫痪。紧急情况下，查看系统日志，发现有两个相关的错误日志，分别是：
 

事件来源: ClusSvc

事件种类: (128)

事件 ID: 1073

Microsoft 群集服务停止了防止群集中不一致性的操作。 错误代码是 5028。 

事件来源: ClusSvc

事件种类: (4096)

事件 ID: 1148

Microsoft 群集服务遇到一个严重错误。重要的仲裁日志 文件 'T:\MSCS\quolog.log' 已损坏。如果您有仲裁日志文件的备份，您可以 在命令窗口输入 'clussvc -debug -noquorumlogging' 来启动群集服务，将备份的仲裁日志文件复制到仲裁 驱动器中的 MSCS 目录，停止群集服务，再用 'net start clussvc' 重新启动群集服务。 如果没有仲裁日志文件的备份，您可以用 'clussvc -debug -resetquorumlog' 启动 群集服务；这会用群集中可能已损坏的信息创建 新的仲裁日志文件。然后，您可以停止群集服务， 用 'net start clussvc' 命令重新启动。 

    看错误的描述，应该是群集服务崩溃，查看服务管理器，Cluster Service停止，手动启动不成功。于是在命令提示符下输入命令 clussvc-debug -resetquorumlog，用这个命令是因为仲裁日志保存在共享阵列上，已经无法访问，没有备份。运行此命令后，屏幕上输出一大堆提示，过了几分钟，SQL SERVER和共享阵列都能访问了，但Cluster Service服务依旧停止，在重启主服务器后恢复正常。对于备服务器，为了不影响网络运行，断开网络和SCSI线，单机查看故障，后来确定是主板故障无法启动。
 

此次集群服务启动失败，就在于Quolog.log文件被破坏，所以修复的关键在于能够读取一个正常的Quolog.log文件。我采用的方法是设置参数 resetquorumlog让Cluster重建Quolog.log文件。

    至于Quolog.log文件为何被破坏，从第一个错误日志里看，很可能是出现仲裁竞争，仲裁日志记录的信息是由备服务器管理磁盘阵列（一般来讲仲裁日志记录的信息是由主服务器管理盘阵，所以建议开机顺序固定，先主后备），但是由于硬件故障，备服务器无法接管磁盘阵列。这样主服务器先启动，接管了磁盘阵列，但当备服务器启动的时候，根据仲裁信息，要将磁盘阵列切到备机去，而备机又因为出现问题无法接管，就导致了这样的现象。
 

故障虽已解决，但是我们也看到了MSCS群集的脆弱性，由于非编网络的数据库文件也是存放在共享阵列上，一旦MSCS群集故障无法启动，导致共享阵列不能访问，数据库服务也会停止，整个非编网络便瘫痪。
 

      最后需要指出的是，微软群集服务旨在提供高可用性，而不是真正的容错功能。“容错”一词通常用于描述提供更高级别恢复功能的技术。容错服务器通常使用结合了特定软件的高级硬件或数据冗余，为单个硬件或软件故障提供近乎瞬时的恢复。这些解决方案的成本远远高于群集解决方案，因为必须支付冗余硬件的费用，而冗余硬件只不过闲置在那里等待恢复故障。微软群集服务使用价格适宜的标准硬件提供优秀的高可用性解决方案，同时最大程度地利用了计算资源。