使用Microsoft Windows 2000 群集服务的高可用性解决方案
使用Microsoft Windows 2000 群集服务的高可用性解决方案
Microsoft Corporation
2002 年3 月
适用于：
Microsoft? BizTalk? Server 2002
Microsoft Windows? 2000 群集服务
摘要：学习如何使用Microsoft Windows 2000 的群集服务组件来设计和部署Microsoft BizTalk Server 2002 的高可用性实现方案。
?第一部分包含群集的重要性以及部署群集需要考虑的软件、硬件和成本等问题的一般信息。
?第二部分包含设置群集的详细步骤。
目录
第一部分
?简介：保障数据的传递和正常运行时间
?群集服务的工作原理
?在BizTalk Server 中使用群集服务
?故障转移的工作原理
?确定正确的群集配置
?在服务器组中使用多个群集的较高级别保护
第二部分
?简介
?群集资源和BizTalk Server
?规划BizTalk Server 的群集配置
?BizTalk Server 群集设置要求
?群集设置
?升级到Biztalk Server 2002
?疑难解答
?参考书目
第一部分
简介：保障数据的传递和正常运行时间
许多公司都使用Microsoft? BizTalk? Server 来处理其业务所依赖的核心数据。这些业务丝毫不能出错，一个简单的硬件故障所造成的停机延误就意味着大量的金钱损失。BizTalk Server 利用强大的事务支持来保障数据传递，该事务支持包含以下ACID 属性：可分性、一致性、隔离性和持久性。此外，还应使用Microsoft Windows? 2000 群集服务以避免用于将数据永久保存在本地磁盘的任何服务器发生硬件故障。Windows 2000 Advanced Server 和Windows 2000 Datacenter Server 都包含此组件。利用Microsoft Windows 2000 群集服务，
BizTalk Server 可以支持主动/被动群集，从而在Orchestration 方案中提供高可用性。
群集服务允许将两台或多台服务器组合在一起并作为一个服务器群集共同工作，从而确保关键任务应用程序和资源对客户端始终可用。服务器群集允许用户和管理员在访问服务器或节点上的某些资源时将这些服务器或节点当作单个系统，而不是一个个独立的计算机。
高可用性解决方案的设计着重在可用的预算内尽量减少故障。通过结合强大的存储系统（独立磁盘冗余阵列[RAID]），群集服务利用冗余服务器故障转移功能为在本地永久保存数据的服务器提供可靠性找到了一种经济而有效的方法。
冗余服务器不会在本地硬盘永久保存任何数据，而服务器将永久保存数据，必须对这两类服务器加以区分。BizTalk Server 允许组中的所有服务器通过网络访问单个BizTalk Server 数据库服务器，这已经提供了相当程度的冗余和可伸缩性。如果组中的任何一台服务器出现故障，其他服务器将接管其工作并继续访问数据库服务器。这是可以实现的，因为组中的任何一台服务器都不会将工作数据永久地保存在其本地磁盘上。但是，如果远程数据库服务器由于任何原因而变得不可用，那么组中的所有服务器都将表现为非活动状态。而群集服务可以确保即使在服务器出现全面故障的情况下中央数据库服务器仍然可以响应服务数据库的访问请求，从而解决了这一单点故障问题。
是否使用群集服务取决于以下两个因素：
?当将重要数据保存在本地磁盘的服务器变得不可用时，业务所能允许的停机时间。
?为提供满意冗余所需的附加硬件和软件的可用预算。
一个简单的冗余也至少需要两台服务器。
群集服务的工作原理
图 1 所示为一个包含两个节点的群集，显示了称为“无共享”结构的群集的基本实现方案。这里需要注意一个基本概念，即两台服务器都连接在同一个物理磁盘子系统上。但是在任何特定时间内，只有其中一台服务器能够“拥有”和控制磁盘存储。由两台服务器（节点）所共享的磁盘子系统部分称为共享存储。
图1：无共享群集，服务器 A 处于主动状态
服务器 A 当前处于主动状态，也就是说它享有对共享存储的完全控制权。服务器 B 正在运行但处于被动状态，并且准备在另一个节点出现故障时接管共享存储。Microsoft SQL Server?的实例在主动节点上运行，并且（作为一项规定）始终在拥有共享存储的群集节点上运行。本例中，磁盘包含了支持SQL Server 数据库所需的所有必要的物理文件，必须具备这些数据库，BizTalk Server 才能正常运行。该实现方案称为主动/被动SQL Server 群集。
SQL Server 的实例和包含数据库的共享存储称为“虚拟”资源，因为它们并不永久属于任何特定服务器。这意味着其他计算机可以访问SQL Server 数据库，而不必知道这两台服务器哪一台处于主动状态。群集服务将处理所有必要的进程以使此过程完全透明。要连接到数据库服务器，用户和应用程序需要使用一个“虚拟服务器”名称，该名称必须是唯一的并且要与群集中两个节点的服务器名称区分开来。
如果服务器 A 出现硬件故障，所有虚拟资源（即SQL Server 实例和磁盘存储）将自动作为一个组转移到服务器 B 并继续运行。此过程不会导致数据丢失。图 2 所示为新配置，称为主动/被动。要在正常运行期间充分利用这两台服务器，一个经济而有效的方法是在每台服务器上运行不同的虚拟资源。在这种配置下，每台服务器都作为另一台服务器的故障转移节点。
图2：主动/被动群集，服务器 B 处于主动状态
大多数经Microsoft 认证其硬件与Windows 2000 Advanced Server 操作系统兼容的主要硬件提供商都支持群集服务。如今，许多业务都实现了功能强大的企业级服务器的群集，使用Windows 2000 Advanced Server 的服务器可以包含多达8 个处理器，使用Windows 2000 Datacenter Server 的服务器可以包含多达32 个处理器。
在BizTalk Server 中使用群集服务
使用群集服务的主要目的是保障用于在其磁盘子系统上永久保存数据的服务器的正常运行时间。要彻底防止BizTalk Server 出现硬件故障，应在以下四个区域实现群集：
?SQL Server 数据库。BizTalk Server 需要四个数据库才能正常运行：Message Management、Shared Queue、Tracking 和Orchestration。至少应该使用群集服务保护这些数据库以免出现服务器故障。
?消息队列。BizTalk Server 可以使用消息排队（Windows 2000 Server 操作系统的一项功能，也称为MSMQ）来接收或发送数据。
队列通常用于应用程序之间的集成，其中需要很大的吞吐量，并且事务处理的读写非常关键。可以按照与SQL Server 基本相同的方法将消息排队群集为一个虚拟资源。
?文件共享。BizTalk Server 可以接收或发送标准的文本文件格式（逗号分隔值或固定宽度）的数据。如果用于存储这些文件的服务器出现故障，BizTalk Server 将无法处理数据。当较长的停机时间威胁到业务的运转时，可以使用群集来保护文件共享。
?Web 分布式创作和版本控制(WebDA V) 储备库（可选）。为防止包含BizTalk Server 储备库信息的节点的本地驱动器出现故障，可以将文件放在共享群集磁盘资源中。此外，这一配置还允许从任何群集节点方便地访问储备库文件。
在查看典型BizTalk Server 实现中的数据流时，保护这些数据存储显然是非常重要的。图 3 所示为公开的区域。
图3：实现群集故障保护的区域
通过保护接收函数来保证进入BizTalk Server 的数据流
每个入站数据源都通过接收函数传递到BizTalk Server 中。BizTalk Server 在事务相关环境中读取所有数据，以确保不会丢失任何数据。将数据传递到BizTalk Server 的方法很多，但有两种特别的数据（即平面文件和消息排队队列）在被传入之前将被永久保存在数据存储区中。当BizTalk Server 完全群集时，只需从虚拟消息排队实例或虚拟文件共享中读取这些数据即可。
注意：如果不打算使用平面文件或消息排队队列，则不必群集这些资源。
在BizTalk Server 处理数据时保护数据
在BizTalk Server 成功接收数据后，它会立即将这些数据保存到SQL Server 数据库中。这将当作全是全非型事务的一部分来完成，也用于确保不会丢失数据。如果如前面所述使用了SQL Server 群集实例，则数据库服务器出现故障将不会影响BizTalk Server 继续进行处理。
为执行XML 文档的常规处理操作，BizTalk Server 使用WebDAV 向磁盘读取和写入XML 储备库数据。这一重要的数据储备库包含XML 文档规范、映射规范和平面文件转换规范（称为“信封”）等文件的目录。WebDAV 是作为Internet 信息服务(IIS) 的一部分而提供的一项功能。
虽然在读取储备库数据时使用了一些缓存，但BizTalk Server 最终还是需要直接从磁盘上获取全新的副本。可以使用群集来确保即使在IIS 及其所依赖的磁盘存储不可用时，处理过程也不会受到影响。
保护来自BizTalk Server 的出站数据
BizTalk Server 完成对XML 数据的处理后，将使用出站端口将数据发送到目的地。从BizTalk Server 发送数据的方法很多，但只有平面文件和消息排队队列在很大程度上依赖于永久保存的数据存储的可用性。与BizTalk Server 中所有其他数据处理操作一样，写入数据的过程也是在全是全非型事务环境中进行的，以确保不会丢失数据。
默认情况下，当目标服务器不可用时，BizTalk Server 将使用重试机制。然而，如果吞吐量的要求很高并且停机会造成严重问题，则采用群集不失为一个明智的选择。从群集中获益最明显的出站BizTalk Server 端口是消息排队队列和平面文件。
保护BizTalk Orchestration
当需要更复杂的业务规则时，可以使用BizTalk Orchestration 这一强大功能来确保长时间运行或进行复杂的事务处理。
如果使用了BizTalk Orchestration 并且为满足吞吐量要求需要稳定的正常运行时间，则应采用群集来保护BizTalk Server 储备库数据文件、Orchestration 数据库和消息排队队列。图 4 所示为BizTalk Orchestration 在群集中的角色，以及它与其他组件之间的交互。
图4：BizTalk Orchestration 在群集中的角色
故障转移的工作原理
故障转移有两种类型：计划的（手动）故障转移和那些由于服务器硬件或软件问题所引起的故障转移。
计划的故障转移
当服务器需要进行维护或升级时，可以执行手动故障转移。手动故障转移需要指示群集服务将所有资源从一个节点移至另一个节点。在前面介绍的两节点示例中，这一操作包括移动共享存储和SQL Server 实例。故障转移的速度很快，因此当一台服务器完成升级或维护任务后，可以将群集资源恢复到该服务器，然后在第二台服务器上执行升级或维护任务。如果没有群集服务，则在执行维护工作时，服务器可能在很长一段时间内都无法使用。
服务器硬件出现故障时的自动故障转移
群集服务始终在两个群集节点上运行，并不断监视每台服务器以确保所有资源均工作正常。如果发生严重的硬件故障或意外错误，所有资源都将自动转移到另一个节点而无需人工干预。
在结构良好的服务器配置中，监视工具（例如由Microsoft Operations Manager 2000 提供的监视工具）将立即检测到此类故障转移。并且这些工具将通知相应的操作人员，服务器出现了故障需要引起注意。如有必要，可以将监视工具配置为自动运行其他脚本。
使故障转移完全透明
ACID 属性被认为是确保数据不会丢失的关键因素。如果BizTalk Server 位于发送数据过程的中间环节，则表示它处于事务环境中。当出现硬件故障时，事务将被回滚。群集资源被成功转移到另一个节点之后，BizTalk Server 将自动重试该事务。如果向BizTalk Server 传递数据的应用程序在编写时符合标准事务处理规则并且具有自动重试机制，则在故障转移过程中应该不会造成太大的影响。
在考虑高可用性BizTalk Server 实现方案的初始设计时，消息排队提供的技术非常有用。即使目标服务器暂时不可用，消息排队也可以启用松散耦合的消息模型，并确保XML 消息的传递。
作为如何通过消息排队使故障转移完全透明的一个示例，图 5 显示了一个通过网络将多个XML 消息发送到虚拟消息排队队列的源应用程序。虚拟队列作为一个群集实例运行，并且当前在服务器 A 上处于主动状态。源服务器将消息排队安装为独立的客户端，这表示在同一服务器上有一个消息排队的本地实例在运行。
图5：将XML 消息发送到消息排队队列的源应用程序
如果服务器 A 崩溃并进行故障转移，则当共享存储从服务器 A 转移到服务器 B 时，消息排队的虚拟实例将暂时不可用。在此期间，源应用程序可以继续向消息队列发送XML 消息而不会被中断。这是可以实现的，因为消息排队能够截取消息并自动将其收集到本地出站队列中。应用程序并不需要了解有关故障转移的任何信息。
图6：故障转移期间消息缓存在本地的出站队列中
在成功完成故障转移并且虚拟消息排队实例恢复联机后，源服务器上的消息排队服务会将中断期间收集的所有消息发送到目标服务器。一切都继续正常进行，所有消息都会得到处理。
图7：故障转移后，缓存的消息被发送到目标服务器
确定正确的群集配置
需要对BizTalk Server 配置中的哪些服务器进行群集最终取决于业务所允许的停机时间和可用的服务器预算。如果容量很小，则可以只使用两台较高性能的服务器（两节点群集），来设计一个包括所有公开区域的完整BizTalk Server 群集实现方案。
许多业务都需要使用BizTalk Server 来处理大量的文档，这时可以选择使用BizTalk Server 的扩展功能来分担负载。下面将介绍这两种
方案的配置选项。
警告：BizTalk Server 支持主动/被动群集配置，也就是说，在一个群集中不能同时存在两个BizTalk Messaging Service
主动实例或两个BizTalk Orchestration 主动实例。如果在一个群集中，BizTalk Messaging Service 实例和BizTalk
Orchestration 实例运行在两个不同的群集节点上，则该群集仍属于主动/被动配置。还支持SQL Server、消息排队和
Internet 信息服务(IIS) 的主动/主动配置。
BizTalk Server 两节点群集配置
使用包含两台服务器的群集配置可以为BizTalk Server 配置一个完整的故障转移解决方案。这可以保护前面介绍的所有公开区域免受服务器故障的影响。
重要信息：如果BizTalk Server 需要处理的文档量非常大，则不适合采用这种解决方案。在确定群集设计之前，必须
先确定数据量和峰值吞吐量要求。
在确定群集中服务器的大小时，需假定所有虚拟资源在某一时刻都只能在一个节点上运行。服务器大小的示例将在稍后的大小设置原则中介绍，但那只是一个指导性信息，对于特定的实现，只有通过充分的强度测试才能准确评估服务器要求。
对于此处介绍的BizTalk Server 实现，我们假定将存储用于以下元素：
?用于将文件传入和传出BizTalk Server 的文件共享
?消息排队队列
?SQL Server
?WebDA V 储备库
图8 所示的群集配置充分利用了两个节点，并为所有公开区域提供了故障转移保护，从而使两台服务器互相充当对方的主动/被动故障转移服务器。
图8：互相充当主动/被动故障转移的两台服务器
在此配置中，SQL Server 正常情况下在服务器 A 上运行，如果服务器 A 出现故障则转移到服务器B；而BizTalk Server 正常情况下在服务器 B 上运行，如果服务器 B 出现故障则转移到服务器A。
上面介绍的将SQL Server 实例和BizTalk Server 实例分开的做法对于大多数情况而言在逻辑上都是最好的选择。然而，这并不表示必须一直保持这种配置。任何时候需要优化性能时，都可以使用手动故障转移将各种群集资源从一台服务器转移到另一台服务器上。例如，如果比较注重BizTalk Orchestration 的性能，则可以将具有虚拟BizTalk Orchestration 实例的组移到虚拟SQL Server 实例所在的节点上来运行，这样可以获得更好的性能。
结合BizTalk Server 组和群集服务
当可伸缩性和高可用性都很重要时，可以使用高性能配置。图9 就显示了这样的配置，它充分利用了BizTalk Server 组和群集服务的功能。
图9：BizTalk Server 组和群集服务的高性能配置
在这种配置中，主要问题是如何获得BizTalk Server 数据库的高可用性。为此，只有SQL Server 实例被群集，组中的每个BizTalk Server 实例都将访问此虚拟实例。有关群集SQL Server 的详细信息，请参阅SQL Server 2000 Failover Clustering（英文）白皮书。
这里有一个基本假设，即，组中的一个BizTalk Server 发生故障时并不会造成严重障碍，因为：
?如果组中的一个BizTalk Server 出现故障，还有其他三个BizTalk Server 实例在运行并继续处理数据。
?所有BizTalk Server 都不依赖本地磁盘来接收或发送数据，而是使用其他数据交换方法，例如HTTP 或应用程序集成组件(AIC)。
- 或者-
数据永久保存在每个BizTalk Server 本地，但停机的严重性不足以要求增加额外费用以部署更多的群集。
在服务器组中使用多个群集的较高级别保护
有些客户要求在配置中针对服务器故障提供完整的保护。同时，他们需要BizTalk Server 组的扩展功能以达到负载平衡。在这些情况下，及时传递数据对业务至关重要，因此额外的硬件成本将成为次要考虑因素。
图10 显示了客户如何使用三个群集来部署高可用性和可伸缩性的BizTalk Server 实现方案。
图10：用于高可用性和可伸缩性实现的三个群集
群集 1 是主动/主动配置，包含两个SQL Server 实例。使用最频繁的数据库是BizTalk Server Tracking 和Queue 数据库，因此将它们分布在两个节点之间以达到最佳负载平衡。这样可以充分利用群集中的两台服务器，同时获得数据库的最佳性能。有关SQL Server 群集的详细信息，请参阅SQL Server 2000 Failover Clustering（英文）白皮书。
群集 2 是BizTalk Messaging Service 的主动/被动实现。此BizTalk 服务的使用最为频繁，它处理所有接收函数并进行处理。在此配置中，被动节点处于非活动状态，以备将来扩展时使用。
群集 3 是节点A 所拥有的BizTalk Messaging Service 的主动/被动实现。此BizTalk 服务经过优化，专门处理由群集 2 上的BizTalk Server 放入数据库工作队列中的项目。为获得最佳性能，BizTalk Orchestration 被分隔开并作为主动/被动配置而独立地在群集3 的节点B 上运行，因为它的使用率非常高并且需要调用大量的自定义组件。其单独运行是出于性能和安全两方面的原因。
注意，群集 2 上需要消息排队以支持节点 A 上的BizTalk Messaging。同样在群集 3 上也需要消息排队以支持节点 A 上的BizTalk Messaging 和节点B 上的BizTalk Orchestration。
BizTalk Server 的另一个高可用性实现是使用四个节点的群集配置。其中，BizTalk Messaging 在一个节点上处于活动状态，在出现故障时可以转移到其他三个节点中的任何一个；BizTalk Orchestration 在另一个节点上处于活动状态，在出现故障时可以转移到其他三个节点中的任何一个；SQL Server 群集在其余两个节点上。
第二部分
简介
第一部分介绍了如何使用Microsoft? Windows? 2000 的群集服务组件为Microsoft BizTalk? Server 提供高可用性的各种选择方案。还介绍了群集的一些基本术语和概念。本部分将详细介绍如何在前面介绍的配置中实现BizTalk Server，包括以下内容：
?硬件和软件要求
?设置BizTalk Server 资源和资源组
?从BizTalk Server 2000 SP1A 升级到BizTalk Server 2002
?疑难解答
在本文接下来的部分中，我们将假设群集设置已经完成并且已经安装和测试了群集服务。有关详细信息，请参阅Step-by-Step Guide to Installing Cluster Service（英文）、Microsoft Knowledge Base 文章Microsoft Cluster Service Installation Resources（Q259267，英文）和INF:Installation Order for SQL Server 2000 Enterprise Edition on Microsoft Cluster Server（Q243218，英文），以及Windows Clustering Technologies（英文）Web 站点。
群集资源和BizTalk Server
在群集服务实现中，通过组合以下核心群集资源可以创建“虚拟服务器”：
?网络IP 地址。在网络上标识此虚拟服务器的唯一IP 地址。
?网络名称。客户端可以通过一个唯一的网络名称访问此虚拟服务器。
?物理磁盘。将被视为虚拟服务器的本地磁盘存储。
设置完这些资源后，它们可以作为一个组一起进行故障转移。这些资源必须按照上面列出的顺序联机。该组构成了任何虚拟服务器的基础，在单个群集上可以运行多个这样的组。
在BizTalk Server 实现中，我们将按照所显示的顺序向虚拟服务器组添加以下附加资源：
?Microsoft 分布式事务协调器(MS DTC)。BizTalk Messaging 要求该组中包含MS DTC 以确保数据的传递。它必须属于BizTalk Messaging 所在的组。
?消息排队。BizTalk Server 将执行消息排队队列的“事务性”读取操作。为此，必须将该队列视为BizTalk Server 所在服务器的本地队列。本例中，BizTalk Server 在虚拟服务器上运行，因此此虚拟消息排队实例被视为虚拟服务器的本地实例。
?IIS WebDA V 储备库（可选）。默认情况下，IIS WebDA V 储备库存储在安装了BizTalk Messaging 的群集的第一个节点的本地驱动器上。在该节点出现故障时为确保运行，可将IIS 实例设置为虚拟实例并将文件存放在共享磁盘上。有关详细信息，请参阅Microsoft KB 文章How to Configure Clustered IIS Virtual Servers on Windows 2000 Advanced Server（Q248025，英文）。
?BizTalk Messaging。当前面所述的所有资源都按照列出的顺序联机后，BizTalk Messaging 便已作好联机所需的所有准备了，并
且可以开始运行。
?XLANG Scheduler Engine（可选）。此资源可以在与BizTalk Messaging 相同的组中运行，或在运行于其他节点的单独的虚拟服务器上运行。
?XLANG Schedule Restart Service（可选）。此资源必须在与XLANG Scheduler Engine 相同的组中运行。它确保在群集上以受控的方式启动和终止Orchestration 计划。
规划BizTalk Server 的群集配置
在规划群集实现之前，有必要先了解特定环境的性能特征。弄清楚最有可能出现瓶颈的位置并反映到全局结构中，这将有助于您确定最佳的配置。基于所需解决方案的独特性能特征和要求，选择在不同的计算机上部署不同的解决方案组件，然后确定群集这些资源的最佳配置。有关规划群集的详细要求列表，请参阅Microsoft Windows 2000 Server Deployment Planning Guide（英文）和Microsoft KB 文章Microsoft Cluster Service Installation Resources（Q259267，英文）。
重要的决策因素
在确定群集配置之前，应考虑有关群集元素的以下信息。
BizTalk Messaging
可以将BizTalk Server 的实例配置为执行接收函数、处理/发送函数或两者兼顾。本文主要讨论接收消息排队消息。在初始设置之后，您只需添加独立的服务器以帮助分担负载即可方便地进行扩展，以便进行更多的处理。如果计划在执行接收函数过程中频繁使用消息排队，则最好选择至少一个群集节点来专门负责此类接收活动。
可以调整BizTalk Server 和消息排队以获取快速读取和存储消息排队消息的性能。花些时间执行一个小型的模拟测试将有助于评估此活动的服务器负载。
SQL Server
如果数据库负载并非是关键问题，则可以将Microsoft SQL Server 安装在与BizTalk Server 相同的群集节点上，以优化性能。服务器的大小需要进行相应调整，并且在这种情况下每个群集通常至少需要两个处理器。
但在以下情况下，则需要将SQL Server 安装在其自己专用的群集节点上：
?将有很多处理服务器访问BizTalk Server 数据库，从而大大增加了SQL Server 实例的负载。
?将频繁使用BizTalk Server 的跟踪功能。
?消息排队和BizTalk Messaging 的模拟测试结果表明，有必要专门使用一台服务器执行BizTalk Messaging 并将数据库活动移到单独的服务器上。
?需要很大的空间以备将来扩展使用。
BizTalk Orchestration
如果BizTalk Orchestration 功能的使用较少，则可以在与BizTalk Messaging 相同的组中运行XLANG Scheduling Engine。由于BizTalk Orchestration 要频繁使用消息排队，通过限制全局配置中组和磁盘资源的数量，可以使群集配置变得更简单。
然而，由于并发运行多个计划，频繁使用BizTalk Orchestration 会导致CPU 的使用率较高并增加内存消耗。在这些情况下，必须使用缓冲机制来防止并发运行的计划数量超出服务器的处理能力。也可以在单独的计算机上运行XLANG Scheduler Engine。可以选择将其放
在Biztalk Messaging 的被动节点上，即，BizTalk Messaging 正常情况下在节点 A 上运行，而BizTalk Orchestration 正常情况下在节点B 上运行。
以这种方式将BizTalk Server 的两个基本组件分开还可以简化稍后进行的优化各节点性能的操作。
为确保BizTalk Orchestration 能提供容错能力，需要确保永久保存了存储在内存中的数据。这可以通过使用事务控制来完成。有关BizTalk Orchestration 事务控制的详细信息，请参阅Orchestration Part 2:Transactions, Exceptions, Debugging（英文）。
重要信息：注意，有时所有资源组可能需要在同一个群集节点上运行一段时间。因此，每个节点都应该具有足够的内
存和足够的CPU 资源以处理上述情况。
硬件因素
规划群集配置时需要考虑的一个主要因素就是硬件成本。各大硬件厂商提供了很多可供选择的硬件产品，从基本的共享小型计算机系统接口(SCSI) 磁盘阵列到完整的存储区域网络(SAN) 解决方案都有。
对于SCSI 磁盘阵列，组中的磁盘资源通常相当于单独的物理磁盘驱动器阵列。每个阵列均配置为RAID 5（使用奇偶校验进行拆分），或者有时候配置为RAID 10 （同时使用拆分和镜像）。像SAN 这样的比较昂贵的解决方案则提供了更加灵活的方法，包括使用光纤信道交换。不管选择何种硬件，都请确保它在Microsoft Windows Hardware Compatibility List（英文）范围之内。
从简单性角度来讲，最简单的群集配置就是主动/被动配置，其中所有必要的BizTalk Server 资源都属于一个组。
图11 显示的就是这样一个配置。建议选择一个单独的磁盘作为仲裁磁盘。在这类配置中，磁盘子系统具有两个单独的磁盘阵列。
注意：在整篇文章中都将涉及到仲裁磁盘，它是一个共享磁盘，群集服务使用它来存储有关群集配置和群集资源状态
的重要信息。因此，建议使用大约具有500 MB（最少100 MB）磁盘资源的单独组作为仲裁磁盘。
图11：简单的主动/被动配置
如果性能是至关重要的因素，则可能需要附加组以使SQL Server 和/或BizTalk Orchestration 可以在另一个群集节点上运行，如下图所示。这种情况需要使用三组磁盘阵列。此配置使得两个节点互相作为对方的主动/被动备用节点。
图12：两个节点都处于主动状态并且互为对方的被动备用节点
BizTalk Server 群集设置要求
有关确保您的硬件与Windows 群集服务兼容以及有关设置和安装群集服务的详细信息，请参阅Microsoft KB 文章Microsoft Cluster Service Installation Resources（Q259267，英文）和Step-by-Step Guide to Installing Cluster Service（英文）中的核对表。将要加入群集的每台计算机还要考虑以下针对BizTalk Server 的特定要求。
大小设置原则
每台计算机都需要有足够的CPU、内存和磁盘空间，以便在故障转移到单个节点上时能处理所有的群集资源。只有对预计的吞吐量进行分析并进行负载模拟测试，才能得出准确的服务器要求。不过，这里也有一些设置服务器大小的通用原则：
?CPU。在低容量的情况下可以允许每个节点配备一个CPU，但在故障转移群集中则可能行不通。无论是所有资源都在单个节点上运行，还是将组分到两个节点上，都需要具有足够的容量以处理高峰期间的负载。由于要接管发生故障的节点的资源，故障转移可能会大大降低该节点上CPU 的处理能力。因此，建议至少使用两个CPU，并且需要使用随本文提供的工具通过负载模拟测试来加以验证。
?内存。确保所有节点都具有足够的内存，以便在发生故障转移时执行所有的处理任务。作为通用原则，如果BizTalk Messaging、BizTalk Orchestration 或SQL Server 三者只有一个位于群集节点上，则服务器的最低内存配置可为 1 GB。如果BizTalk Messaging、BizTalk Orchestration 或SQL Server 三者中的任何两个位于同一个节点上，则每个节点（将SQL Server 的最大内存使用量设置为 1 GB）至少需要 2 GB，如果三者都位于同一个群集节点上，则至少需要 3 GB。
?磁盘存储要求。最好为消息排队保留2 GB（最多），至少为BizTalk Server 数据库保留50 GB。Tracking 数据库消耗的空间最多，并且会根据容量和所选择的跟踪选项而迅速增长。如果对跟踪没有什么要求（这不太可能），或者吞吐量很小，则磁盘空间的要求要小得多。
软件要求
需要以下软件产品和相应的许可证：
?Windows 2000 Advanced Server 或具有SP2 或更高版本的Windows 2000 Datacenter Server
?具有SP1 或更高版本的Microsoft SQL Server 2000 Enterprise Edition
注意：不管是在与BizTalk Server 相同的群集上还是在单独的群集上，这里都假设SQL Server 被群集为
BizTalk Server 的任何高可用性解决方案的一部分。
?具有SP1A 或更高版本的BizTalk Server 2000 Enterprise Edition，或者包含BizTalk Orchestration（可选）的BizTalk Server 2002 Enterprise Edition
?Microsoft Visio? 2000 标准版SR-1A（可选，仅在针对BizTalk Orchestration 节点的设计时体验时才会需要）
群集设置
在设置基本的群集硬件并安装和配置群集服务之后，本文将着重讨论BizTalk Server 的安装和配置。假设现在已经完成了以下步骤：
?基本的群集硬件已配置完毕。
?已经安装了群集服务。
?为仲裁磁盘准备了单独的组，其中只包括网络名称、IP 地址和仲裁磁盘。
重要信息：请勿在此组中添加其他资源。
有关详细说明，请参阅Microsoft KB 文章INF:Installation Order for SQL Server 2000 Enterprise Edition on Microsoft Cluster Server
（Q243218，英文）和Microsoft Cluster Service Installation Resources（Q259267，英文），以及Step-by-Step Guide to Installing Cluster Service （英文）和Windows Clustering Technologies（英文）Web 站点。
开始之前，请确保所有必要的资源都已准备就绪，确保已经读完本文，并确保可以方便地查阅各种参考资料。
重要信息：在继续之前，请测试所有的组以确保能进行正确的故障转移。
本文详细介绍了“集成SQL Server 和BizTalk Server 群集”部署方案的步骤，这是最直接的配置。对于其他部署设计，在配置各个群集时可以忽略某些步骤。以下各部分将要介绍的步骤包括：
1.为BizTalk Messaging、BizTalk Orchestration 和SQL Server 创建群集组
2.安装MS DTC (ComClust) 并将其配置为能识别群集
3.安装消息排队
4.向BizTalk Messaging 组添加虚拟消息排队资源
5.为每个虚拟消息排队实例添加管理控制台
6.测试消息排队故障转移
7.安装Microsoft Visio 2000 Standard Edition SR-1A（可选）
8.在群集上安装SQL Server 2000
9.测试SQL Server 故障转移
10.安装BizTalk Server
11.将BizTalk Server 配置为群集资源
12.测试BizTalk Server 故障转移
13.测试XLANG Scheduler Engine 故障转移
为BizTalk Messaging、BizTalk Orchestration 和SQL Server 创建群集组
1.在“开始”菜单上，指向“设置”，单击“控制面版”，双击“管理工具”，然后双击Cluster Administrator（群集管理器）。
2.在File（文件）菜单上，指向New（新建），然后单击Group（组）。屏幕将显示New Group（新建组）窗口。
3.在Name（名称）框中，键入BizTalk Messaging Group（BizTalk Messaging 组），然后单击Next（下一步）。
4.在Preferred Owners（首选所有者）窗口中，将一个节点资源移动到BizTalk Messaging Group（BizTalk Messaging 组）。
注意：此步骤为可选步骤。它可以提供故障回复保护，但并不影响故障转移保护。
5.单击Finish（完成）。
6.在File（文件）菜单上，指向New（新建），然后单击Resource（资源）。屏幕将显示New Resource（新建资源）窗口。
7.在Name（名称）框中，键入IP 地址。在Description（描述）框中，键入BizTalk Messaging 组的IP 地址。在Resource type
（资源类型）列表中，选择IP address（IP 地址）。在Group（组）列表中，选择刚才创建的BizTalk Messaging 组。单击Next （下一步）。
8.在File（文件）菜单上，指向New（新建），然后单击Resource（资源）。屏幕将显示New Resource（新建资源）窗口。
9.在Name（名称）框中，键入网络名称。在Description（描述）框中，键入BizTalk Messaging 组的网络名称。在Resource type
（资源类型）列表中，选择Network Name（网络名称）。在Group（组）列表中，选择刚才创建的BizTalk Messaging 组。单击Next（下一步）。
重复步骤 2 到8 以创建BizTalk Orchestration 组。重复步骤2 到4 以创建SQL Server 组。
注意：在SQL Server 的安装过程中已经为SQL Server 创建了IP 地址和资源名称，因此此处不需要再创建。
图13：Cluster Administrator（群集管理器）屏幕
安装MS DTC (ComClust) 并将其配置为可以识别群集
Microsoft 分布式事务协调器(MS DTC) 必须能够识别群集。建议将此资源放在BizTalk Messaging 组，而不要放在与仲裁磁盘相同的组中。对于群集中的每台计算机，每次在一台计算机上执行以下步骤：
1.登录到其中一个节点并启动Cluster Administrator（群集管理器）。
2.在File（文件）菜单上，单击Move group to（将组移至）。移动到另一个节点，其中包含除BizTalk Messaging 组之外的任何
具有物理磁盘资源的组。
确保要在其中创建MS DTC 资源的组具有磁盘、IP 地址和网络名称等资源。
3.从\winnt\system32 文件夹中将DTCLog 文件夹复制到BizTalk Messaging 组的物理磁盘中。
4.在组中创建DTC 资源。
a.使用群集管理器应用程序，单击BizTalk Messaging Group（BizTalk Messaging 组）。
b.在File（文件）菜单上，指向New（新建），然后单击Resource（资源）。屏幕将显示New Resource（新建资源）窗
口。
c.在Name（名称）框中，键入MS DTC。在Resource type（资源类型）列表中，选择Distributed Transaction Coordinator
（分布式事务协调器）。在Group（组）列表中，选择BizTalk Messaging Group（BizTalk Messaging 组）。单击Next
（下一步）。
d.将群集中的每台计算机都当作可能的资源所有者。单击Next（下一步）。
e.为网络名称、共享磁盘和IP 地址添加资源相关性。单击Finish（完成）。
注意：请将此资源保持为脱机状态。
5.在第一个节点上打开命令提示符窗口，并运行comclust.exe。
6.在第二个节点上打开命令提示符窗口，并运行comclust.exe。
7.验证MS DTC 资源处于联机状态。
8.测试故障转移。
如果配置MS DTC 时出现问题，请参阅Microsoft KB 文章Microsoft Distributed Transaction Coordinator (MSDTC) Recovery Techniques in Windows 2000 Cluster Server（Q243204，英文）。
安装消息排队
对于群集中的每台计算机，每次在一台计算机上执行以下步骤：
1.单击“开始”，指向“设置”，单击“控制面板”，然后双击“添加/删除程序”。
2.单击“添加/删除Windows 组件”。
屏幕将显示“Windows 组件向导”。
3.选择Message Queuing Service（消息排队服务）复选框，然后单击Next（下一步）。
注意：确保将每台计算机都配置为MSMQ 服务器，而不仅仅是一个独立的客户端。
根据您是否在环境中配置了Microsoft Active Directory?，选择相应的消息排队安装选项。如果没有Active Directory，
则BizTalk Server 必须始终使用本地队列，这样可以显著提高性能。使用公共队列可以获得更大的灵活性和更强的功
能。
向BizTalk Messaging 组添加虚拟消息排队资源
BizTalk Messaging 和BizTalk Orchestration 都需要使用消息排队的本地实例来执行事务性读取操作。在群集资源组中，术语“本地”是指虚拟服务器的名称（网络名称）。由于BizTalk Server 将在此虚拟服务器名称的环境中运行，因此必须在BizTalk Messaging 组中安装消息排队的虚拟实例以使其显示为本地。
重要信息：如果是第一次将消息排队作为群集资源安装在此服务器上，则可以跳过这一段。否则，请执行以下步骤以
确保在添加虚拟消息排队群集资源之前完全清空注册表。
如果计算机先前位于另一个群集中，并且其消息排队资源的名称与现在要配置的消息排队的名称相同，则会存在一个
已知的问题。由于前一次安装在注册表中遗留下一些不正确的注册表项，因此消息排队资源在配置完后可能无法联机。
如果是这样，请确保删除每台计算机（先前配置在另一个群集中）的以下注册表项下的条目：
HKEY_LOCAL_COMPUTER\SOFTWARE\Microsoft\
Message Queuing\Clustered QMs
1.启动Cluster Administrator（群集管理器）。
2.右击BizTalk Messaging Group（BizTalk Messaging 组），指向New（新建），然后单击Resource（资源）。
3.在Name（名称）框中，键入Message Queuing（消息排队）。在Resource type（资源类型）框中，选择Message Queuing（消
息排队），然后单击Next（下一步）。
4.在Possible Owners（可能的所有者）窗口中，确保所有节点都被选择为可能的所有者。单击Next（下一步）。
5.在Dependencies（相关性）窗口中，为网络名称和共享磁盘添加资源相关性。单击Finish（完成）。
6.将资源联机。
7.测试故障转移。
在虚拟消息排队实例配置完毕并联机后，本地的消息排队实例将自动停止，因此只有一项服务处于运行状态。检查“控制面板”中的“服务”图标，将看到消息排队服务的本地实例和虚拟实例。虚拟消息排队实例的物理文件将自动创建在名为MSMQ 的文件夹下的共享磁盘资源中。不必为虚拟消息排队实例更改启动设置。但是，如果还需要消息排队的本地实例，例如当BizTalk Server 组件使用本地消息排队实例时，则有必要为群集创建一般应用程序资源（该资源可以手动启动以用于此本地消息排队实例），并且XLANG Schedule Restart Service 必须依赖于此资源。有关详细信息，请参阅Microsoft KB 文章, INFO:Using the MSMQ Service on a Windows 2000-Based Cluster （Q310775，英文）和Windows 2000 帮助中的Installing Message Queuing on a server cluster（英文）。
为每个虚拟消息排队实例添加管理控制台
在正常情况下，管理消息排队队列的正确方法是从“管理工具”菜单中打开“计算机管理器”。然而，要管理消息排队的虚拟实例，打开管理控制台的步骤将有所不同。在此情况下，管理控制台必须在虚拟服务器环境中运行，而不是在本地计算机上运行。这可以通过自动启动管理控制台来完成，如下所示：
1.启动Cluster Administrator（群集管理器）。
2.右击BizTalk Messaging Group（BizTalk Messaging 组），指向New（新建），然后单击Resource（资源）。
3.在Name（名称）框中，键入Manage Virtual Message Queuing（管理虚拟消息排队）。在Resource type（资源类型）列表中，
选择Generic Application（一般应用程序），然后单击Next（下一步）。
图14：New Resource（新建资源）屏幕
4.在Possible Owners（可能的所有者）窗口中，允许资源在群集中的所有服务器上运行。单击Next（下一步）。
5.在Dependencies（相关性）窗口中，在资源中添加以下相关性：
?网络名称
?先前添加的消息排队虚拟实例的名称
6.单击Next（下一步）。将显示Generic Application Parameters（一般应用程序参数）屏幕。
7.在Command line（命令行）框中，键入CMD.exe /C compmgmt.msc。
注意：此命令在每个节点本地运行。如果它们在您的服务器上的位置不同，请更改Windows 系统路径和驱
动器号。
8.在Current directory（当前目录）框中，键入BizTalk Messaging 组的共享磁盘的驱动器号(J:\)。
9.选择Allow application to interact with desktop（允许应用程序与桌面交互）和Use Network Name for computer name（将网络
名用作计算机名）复选框。单击Next（下一步）。
构建高可用性HIS 近几年来，我国的HIS系统建设已从单纯的经济管理逐步向以病人为中心的临床应用发展，如联机检验数据采集、PACS系统以及电子病历等等，使医院对HIS系统的依赖程度越来越高，这就要求HIS系统需要达到7X24小时永不间断地高效可靠运行，计算机集群系统能够较好地满足这一要求。 1集群系统及其基本架构 1.1 集群的概念 集群就是把多个独立的计算机连接在一起，面对客户机作为一个虚拟整体，使整个系统能够提供更大的可用性、更好的可伸缩性和更强的容灾能力。 1.2 集群系统的基本构成 一个集群系统通常由多个服务器(或称为节点)、共享存储子系统和使节点可以进行信息传递的内部节点连接构成。图1为两节点集群的基本架构。 每个集群节点具有两类资源：非共享资源和共享资源。非共享资源包括安装网络操作系统的本地硬盘、系统页面文件（虚拟内存）。本地安装的应用程序，以及特定节点访问的各种文件。共享资源包括存储在共享设备中的文件，每个集群节点使用共享存储系统访问集群的quorum资源和应用程序数据库等。 1.3 集群系统中的几个重要组件 ①后台共享存储设备：所有的节点都必须与至少一个集群系统的共享存储设备相连。共享存储设备将存储集群本身的系统数据及应用程序所产生的数据。 ②集群内部网络通讯：这个网络提供信息传递的服务，被称为心跳网络，它用来传递各个节点的状态。内部连接可采用高带宽的通讯机制（例如千兆以太网），以确保集群中的节点可以快速交换信息和同步数据。 ③公共网络：为客户端提供访问服务的网络，这个网络为其它的应用服务提供必要的网络通讯基础。 ④虚拟的前台界面：所有的节点被合为一组，有一个虚拟的服务器名称，为了管理集群系统，也需要为集群提供一个名称。应用程序在集群环境下运行的时候，也需要创建自己的虚拟服务器名称，便于客户端的访问。 1.4 集群中节点的运行模式 在集群中节点可以有几种运行模式，取决于实际应用环境。 ①Active/passive模式。在两个节点集群环境中，其中一个集群节点处理所有集群应用请求而另外一个节点则只简单地等待那个起作用的节点失效。这种Active/passive集群方式从性能价格比方面来讲并不合算，因为其中一个服务器在大多数时间处于空闲状态。但在失效时应用可以完全使用另一个服务器的处理能力，所以这种配置比较适用于一些关键业务环境。 ②Active/active模式。在集群中每一个节点都作为一个虚拟的服务器，当一个应用运行在节点A时，节点B不需要处于空闲状态以等待节点A的失效，节点B可以在为节点A的资源提供失效恢复能力的同时运行它自己的集群相关应用。由于这种模式各个系统都是独立运行，因此在资源的应用上其效率要更高一些。但一个Active/active方式的节点必须具备相应的能够处理两个节点上的负载的能力（在发生失效恢复事件时），否则接管了失效节点的服务也会很快因不堪重负而垮掉。 ③3-active/passive模式。Microsoft Windows 2000 Datacenter Server支持这种配置方式，由三个服务器共同作为一个虚拟服务器运行，第四个服务器作为备份服务器，当虚拟服务器中任何一个服务器出现故障，备份服务器接管其原有的应用和资源。这种集群环境提供更强大的处理能力，适用于更高的企业用户需求，能够满足更多的客户访问。
VMware Workstation 中故障转移集群配置指南
目录 一、群集介绍 (3) 二、群集专业术语 (3) 三、实验环境介绍及要求 (4) 1、拓扑图 (4) 2、软件配置说明 (4) (1) DC软件配置信息 (4) (2) Cluster Node A软件配置信息 (4) (3) Cluster Node B软件配置信息 (5) 3、硬件配置要求 (5) (1) 网卡 (5) (2) 共享磁盘 (5) 四、安装群集前的准备工作 (6) 1、创建共享磁盘 (6) (1) 创建用来保存共享磁盘的目录 (6) (2) 创建仲裁磁盘 (6) (3) 创建数据共享磁盘 (7) (4) 验证共享磁盘是否成功创建 (7) (5) 附加共享磁盘 (8) 2、网络及系统配置 (10) (1) 创建群集服务帐户 (10) (2) 添加群集A记录 (12) (3) ClusterNodeA上的共享磁盘配置 (12) (4) 网络配置 (16) (5) ClusterNodeB上的共享磁盘配置 (21) 五、安装群集服务 (24) 1、在A节点上新建一个群集 (24) 2、将B节点加入现有群集 (29) 六、配置群集服务 (35) 1、群集网络配置 (35) 2、心跳适配器优先化 (37) 3、仲裁磁盘配置 (38) 4、创建一个启动延迟（此操作非必需） (39) 5、测试群集安装 (40) 七、故障转移测试 (42) 1、初级测试 (42) 2、高级测试 (44) (1) 手工模拟故障1次 (44) (2) 手工连续模拟故障4次 (45) (3) 停止群集服务测试 (47) (4) 模拟意外断电时故障转移 (49) 八、结束语 (50)
本指南提供关于在运行Microsoft? Windows? Server 2003 Enterprise Edition和Windows Server 2003 Datacenter Edition操作系统的服务器上创建和配置使用共享磁盘的典型的单一仲裁设备多节点服务器群集的步骤指导。 介绍 服务器群集是一组协同工作并运行Microsoft群集服务（Microsoft Cluster Service，MSCS）的独立服务器。服务器群集为资源和应用程序提供高可用性、故障恢复、可伸缩性和可管理性。 服务器群集允许客户端在出现故障和计划中的暂停时，依然能够访问应用程序和资源。如果群集中的某一台服务器由于故障或维护需要而无法使用，资源和应用程序将转移到可用的群集节点上。 Windows群集（Windows Clustering）解决方案使用了名词“高可用性”而非“容错”。容错技术提供更高层次的弹性和恢复能力。容错服务器通常使用深层硬件冗余，加上专门的软件，几乎可以即时地恢复任何单一的硬件或软件错误。这些解决方案要比Windows群集（Windows Clustering）解决方案昂贵得多，因为组织必须为处于空闲状态等待错误的冗余硬件支付费用。 服务器群集无法保证无间断运作，但是确实能够为多数关键任务应用程序提供足够的可用性。群集服务可以对应用程序和资源进行监控，并能够自动识别和恢复众多故障状况。这为在群集中管理工作负荷提供了灵活性。另外，还提高了整个系统的可用性。 群集服务（Cluster service）的优点包括： ·高可用性：通过服务器群集，资源（例如：磁盘驱动器和Internet协议（IP）地址）的所有权会自动从故障服务器转移到可用的服务器。当群集中的某个系统或应用程序发生故障时，群集软件会在可用的服务器上重新启动故障应用程序，或者将工作从故障节点分散到剩下的节点上。由此，用户只在瞬间感觉到服务的暂停。 ·故障恢复：当故障服务器重新回到其预定的首选所有者的联机状态时，群集服务将自动在群集中重新分配工作负荷。该特性可配置，但默认禁用。 ·可管理性：您可以使用“群集管理器”工具 （CluAdmin.exe），将群集作为一个单一的系统进行管理，并对犹如运行于一个单一服务器的应用程序实施管理。您可以将应用程序转移到群集中的其它服务器。“群集管理器”可用于手动平衡服务器的工作负荷，并针对计划维护释放服务器。您还可以监控群集的状态、所有节点以及来自网络任何地方的资源。 ·可伸缩性：群集服务可扩展以满足需求的增长。当群集监督应用程序的总体负荷超出了群集的能力范围时，可以添加附加的节点。 本文档提供有关针对连接到共享群集存储设备并运行Server 2003 Enterprise Edition或Windows Server 2003的服务器创建和配置服务器群集的指导。本文档的目的是为了指引您完成安装典型群集的步骤，并未解释如何安装群集应用程序。而对于实施非传统仲裁模型，
高可用性集群系统的实现 《Linux企业应用案例精解》第8章主要介绍一下虚拟化技术应用。本节为大家介绍高可用性集群系统的实现。 8.3.5 高可用性集群系统的实现（1） VMware Infrastructure 的体系结构和典型配置 资源动态分配和高可用性的实现为构建高可用性集群系统提供了有力的保障，采用VMwae构建铁路企业高可用性集群，不需要为系统中的每台服务器分别添置备用服务器，就可以有效地降低系统成本，在基于VMware的我企业高可用性集群中，备用服务器安装了VMware ESX Server，与数据库服务器、Web服务器、OA服务器和文件服务器等构成高可用性集群，同时采用数据库备份服务器实现差额计划备份。 使用VMware提供的虚拟基础架构解决方案，服务器不再需要随着业务增加而添加，整个IT基础架构能得到有效控制并可充分发挥效能。只有当整体资源出现不足的时候，才需要增加服务器。而且对系统资源的
添加也非常简单，不再需要做繁琐的硬件维护以及业务迁移，只需要简单地将新服务器安装VMWARE? INFRASTRUCTURE 3软件，并添加到已有的VMWARE? INFRASTRUCTURE 3架构中即可，新增资源将自动分配到各个最需要的业务环境中。 在HA和DRS功能的共同支撑下，虚拟机的稳定、不间断运行得到了保证，而且，在没有搭建Cluster环境的情况下，迁移、升级依旧能不中断服务。哪怕是硬件升级、添加，正常停机维护等情况，也能够保证所有的业务正常运行，客户端访问服务器不产生业务中断现象。新的服务器虚拟化架构中另一个重点是VMware HA 的部署，它是整个服务器系统安全、可靠运行的一道防线。传统的热备机方式最大的问题就是容易造成资源的大量闲置；在正常运行状态下，所有备机服务器都处于闲置状态，不仅造成计算资源的空耗，而且还浪费大量的电力和散热资源，投资回报率非常低。 如何应对Linux系统软件包的依赖性问题 不管是初步跨入Linux殿堂的新手还是，具有多年经验的专家，在安装或编译软件包的过程中或多或少的都会遇到包的依赖问题从而导致安装过程无法继续，比如管理员在安装php软件包需要libgd.so文件，而这个文件属于gb软件包。但是在安装gb软件包时，可能这个软件包跟其他软件包又具有依赖关系，又需要安装其他软件包才行。这时有的管理员便失去耐心。在遇到这种Linux软件包依赖关系问题，该如何解决呢?在谈这个具体的措施之前，先跟大家聊聊Linux系统里的软件爱你依赖性问题。 我们把处理rpm依赖性故障的策略可以分成两类解决依赖性故障的自动方法和手工方法。但当安装不属于发行一部分的软件包时自动方法是不可用的。在描述如何手工解决依赖性故障后，将简要描述如何使用自动方法之一（YUM），但首先需要了解它们是什么及rpm如何强制实施它们。 一、什么是依赖性 程序依赖于程序代码的共享库，以便它们可以发出系统调用将输出发送到设备或打开文件等（共享库存在于许多方面，而不只局限于系统调用）。没有共享库，每次程序员开发一个新的程序，每个程序员都需要从头开始重写这些基本的系统操作。当编译程序时，程序员将他的代码链接到这些库。如果链接是静态的，编译后的共享库对象代码就添加到程序执行文件中；如果是动态的，编译后的共享库对象代码只在运行时需要它时由程序员加载。动态可执行文件依赖于正确的共享库或共享对象来进行操作。RPM依赖性尝试在安装时强制实施动态可执行文件的共享对象需求，以便在以后--当程序运行时--不会有与动态链接过程有关的任何问题。
1.业务连续 1.1.共享存储集群 业务系统运营时，服务器、网络、应用等故障将导致业务系统无常对外提供业务，造成业务中断，将会给企业带来无法估量的损失。针对业务系统面临的运营风险，Rose提供了基于共享存储的高可用解决方案，当服务器、网络、应用发生故障时，Rose可以自动快速将业务系统切换到集群备机运行，保证整个业务系统的对外正常服务，为业务系统提供7x24连续运营的强大保障。 1.1.1.适用场景 基于共享磁盘阵列的高可用集群，以保障业务系统连续运营 硬件结构：2台主机、1台磁盘阵列
主机 备机心跳 磁盘阵列 局域网 1.1. 2.案例分析 某证券公司案例 客户需求分析 某证券公司在全国100多个城市和地区共设有40多个分公司、100多个营业部。经营围涵盖：证券经纪，证券投资咨询，与证券交易、证券投资活动有关的财务顾问，证券承销与保荐，证券自营，证券资产管理，融资融券，证券投资基金代销，金融产品代销，为期货公司提供中间介绍业务，证券投资基金托管，股票期权做市。 该证券公司的系统承担着企业的部沟通、关键信息的传达等重要角色，随着企业的业务发展，系统的压力越来越重。由于服务器为单机运行，如果发生意外宕机，将会给企业的日常工作带来不便，甚至
给企业带来重大损失。因此，急需对服务器实现高可用保护，保障服务器的7×24小时连续运营。 解决方案 经过实际的需求调研，结合客户实际应用环境，推荐采用共享存储的热备集群方案。部署热备集群前的单机环境：业务系统，后台数据库为MySQL，操作系统为RedHat6，数据存储于磁盘阵列。 在单机单柜的基础上，增加1台备用主机，即可构建基于共享存储的热备集群。增加1台物理服务器作为服务器的备机，并在备机部署系统，通过Rose共享存储热备集群产品，实现对应用的高可用保护。如主机上运行的系统出现异常故障导致宕机，比如应用服务异常、硬件设备故障，Rose将实时监测该故障，并自动将系统切换至备用主机，以保障系统的连续运营。
微软服务器群集和Oracle设备安装方法 --针对IBM服务器 一、安装操作系统及应用软件。（服务器为X336） 1．硬件连接：将两台服务器线路连接好，除了EXP400暂时不连接，或连接好不开EXP400磁盘柜。 2．始安装操作系统（WIN2000 AD），此时主、从服务器可并行同时安装。 3．IBM ServerGuide 7.2.03引导盘引导服务器。 1)选择安装语言为English （NEXT） 2)选择键盘、国家（NEXT） 3)ServerGuide应用简介（NEXT） 4)选择要安装的操作系统WIN2000 Advance Server （NEXT） 5)设置时间、日期（NEXT） 6)安装新机器，选择清除硬盘所有信息（NEXT） 7)配置ServerRAID，此时只有本地两块硬盘，配置为RAID1，配置完成退 出（NEXT） 8)服务器自动重起 9)创建系统分区为15000MB （NEXT） 10)输入服务器名（规则见《TFDS安装说明》）、WIN2K AD安装序列号 （NEXT） 11)服务器网络设置，默认（NEXT） 12)同时连接服务器数输入500 （NEXT） 13)设置时区（+8 BEIJING），默认语言（Chinese PRC）,默认输入法 （SIMPLIFILED CHINESE）（NEXT） 14)选择添加群集组件（Cluster Serives）（NEXT） 15)自动COPY ServerGuide 光盘内容，完成后光盘自动弹出 16)在光驱中放入WIN2000 AD安装光盘（NEXT） 17)确认光盘系统版本（NEXT） 18)同意安装条例（NEXT） 19)自动COPY WIN2000 AD 光盘内容，完成后光盘自动弹出（NEXT） 20)等待45分钟，操作系统安装完成 注：若有落下的页面则为默认选择即可。 4．进入系统，进入磁盘管理将光驱盘符为Z，将硬盘空余空间分为逻辑分区D。 5．将WIN2000 AD安装光盘全部内容COPY到D盘下WIN2K目录内。 6．将MCAFEE杀毒软件、远程管理软件及WIN2K 系统补丁文件均COPY 到D盘。 7．装SP4（注意：要用TFDS安装光盘提供的正规版本安装，大小约为128MB）。 8．装WIN2K系统补丁（注意：不要安装震荡波补丁）。 9．装MCAFEE7。1杀毒软件及远程管理软件。 以上操作均可两台服务器并行同时安装。
双机热备、集群及高可用性入门
什么是双机热备？ 双机热备这一概念包括了广义与狭义两种意义。 从广义上讲，就是对于重要的服务，使用两台服务器，互相备份，共同执行同一服务。当一台服务器出现故障时，可以由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续提供服务。(相关文章：为什么需要双机热备？) 双机热备由备用的服务器解决了在主服务器故障时服务不中断的问题。但在实际应用中，可能会出现多台服务器的情况，即服务器集群。(相关文章：双机软件与集群软件的异同) 双机热备一般情况下需要有共享的存储设备。但某些情况下也可以使用两台独立的服务器。(相关文章：双机热备的实现模式) 实现双机热备，需要通过专业的集群软件或双机软件。(相关文章：双机与集群软件的选择) 从狭义上讲，双机热备特指基于active/standby方式的服务器热备。服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。在同一时间内只有一台服务器运行。当其中运行着的一台服务器出现故障无法启动时，另一台备份服务器会通过软件诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用。(相关文章：双机热备、双机互备与双机双工的区别) 为什么要做双机热备？ 双机热备针对的是服务器的故障。 服务器的故障可能由各种原因引起，如设备故障、操作系统故障、软件系统故障等等。一般地讲，在技术人员在现场的情况下，恢复服务器正常可能需要１０分钟、几小时甚至几天。从实际经验上看，除非是简单地重启服务器（可能隐患仍然存在），否则往往需要几个小时以上。而如果技术人员不在现场，则恢复服务的时间就更长了。 而对于一些重要系统而言，用户是很难忍受这样长时间的服务中断的。因此，就需要通过双机热备，来避免长时间的服务中断，保证系统长期、可靠的服务。 决定是否使用双机热备，正确的方法是要分析一下系统的重要性以及对服务中断的容忍程度，以此决定是否使用双机热备。即，你的用户能容忍多长时间恢复服务，如果服务不能恢复会造成多大的影响。 在考虑双机热备时，需要注意，一般意义上的双机热备都会有一个切换过程，这个切换过程可能是一分钟左右。在切换过程中，服务是有可能短时间中断的。
高可用性系统部署方案 2010年2月5日 1.1 概述 1.1.1 前言 在金融工程系统应用中，对服务器的安全性、可靠性要求较高，在服务器故障情况下，要求尽可能短的时间内恢复运行，并且能对故障发生时的数据进行恢复和处理，而能否实现这一功能是一个系统是否达到高可用性的主要指标。
高可用性可体现于应用系统和数据库存储两部分，应用系统部分重点是主备机达到故障自动切换，而数据存储部分注重数据的完整性、安全性和故障转移。 1.1.2 目前情况 股指套利、算法交易、交易网关等系统在使用上需要作整个架构部署的高可用性考虑，但目前只是部分或没有作整个系统的高可用性方案及实现。 1.1.3 参考文档 附件：SQL2005数据镜像方案测试报告_20100204.doc 1.2 高可用性需求 即要实现高可用性，又要控制成本投入，实施部署也要可操作性强是这次方案的主要目标，基于此目标，本方案对成本很高的共享磁盘阵列的故障转移群集和第三方商业故障系统不作为实现技术方案。 本方案解决的高可用性需求如下： 1、应用主服务器故障发生时，连接能够短时间内自动连接到备机继续工作。 2、数据库主服务器发生时，备机上要有完整的数据，并且连接到主数据库的连 接会话能很快的重新连接到备机上继续工作 3、应用系统和数据库的服务器均能达到自动故障切换转移，以达到快速故障恢 复的目的。 4、服务器数量尽可能少，成本投入不能太高。 1.3 解决方案 出于安全和可靠性考虑，建议数据库和应用系统部署在不同的服务器上，以减少性能上的彼此影响。以算法交易服务应用为例，在母单下得较多的时候会出现系统CPU和内存上的较大消耗，如果再加上数据库的占用资源，很容易出现系统负载过重，故在方案中将应用系统与数据库分布在不同服务器，便于管理及提高整体性能。
关于系统稳定性策略的探讨 1.前言 系统作为业务系统的核心，其运行稳定性和高可用性至关重要。因此，需要通过高可用性设计来尽量减少系统的计划内和计划外停机，并在系统出现故障时及时响应、快速恢复，以保障关键数据和业务系统的运行稳定性和可持续访问性。其中： 1.计划内停机是指管理员有组织、有计划安排的停机，比如升级硬件微码、升 级软件版本、调整数据库库表、更换硬件设备、测试系统新功能等时，可能需要的停止系统运行。 2.计划外停机是指非人为安排的、意外的停机，比如当硬件出现重大故障、应 用程序停止运行、机房环境遭到灾难性的破坏时所引起的业务系统停止运行。 目前，对于计划内和计划外停机，可通过消除系统中的单点失效来尽量减少停机时间。同时，通过采用可在线维护（固件升级、在线扩充、故障部件更换）的设备，并通过负载均衡机制实现应用系统的在线升级、维护，将有效消除计划内停机对业务系统的影响。此外，由于系统中采用了全面的负载均衡设计，并针对系统失效提供了可靠的数据备份恢复和多点容灾保护，因而能够有效减少系统计划外停机的恢复时间。 在造成系统宕机的原因方面，有统计中表明并非都是硬件问题。其中，硬件问题只占40％，软件问题占30％，人为因素占20％，环境因素占10％。因此，高可用性设计应尽可能地考虑到上述所有因素。对于系统而言，其整体的可用性将取决于内部的应用系统、主机、数据库等多种因素；同时，训练有素的系统维护人员和良好的服务保障也是确保系统稳定运行和故障快速恢复的关键。 2.应用系统 系统在应用软件架构设计中应从渠道层、渠道管理层、业务处理层等不同
层面通过多种措施和策略的综合设计来提高应用系统的高可用性和稳定性。 在渠道管理层和业务处理层的设计中，要考虑设置应用负载均衡、应用软件失效备援、vip服务通道、流量控制、故障隔离等机制。 1.应用负载均衡 应用软件负载均衡通过多个层次上不同的负载均衡策略一起实现整体的负载均衡，应用负载均衡的设计思路是将大量的并发访问或数据流量分担到多台节点设备上分别处理和将单个重负载的运算分担到多台节点设备上做并行处理来达到负载均衡的效果，从而提高服务响应速度，提高服务器及其他资源的利用效率，避免服务请求集中于单一节点导致拥塞。 2.应用软件失效备援 应用软件构建在面向服务的架构、设计思想上，应用服务具有较高的可灵活部署性。通过这种灵活性，结合系统基础设施的规划、部署可以实现应用软件的失效备援。系统可以考虑实现基于应用服务和基于应用服务管理框架的多种应用软件失效备援机制。 基于应用服务的失效备援是在应用服务管理框架中可以实现应用服务的冗余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应的冗余服务。 基于应用服务管理框架的失效备是将应用服务框架在系统中冗余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应的冗余的应用服务管理框架。 3.vip服务通道 在系统中，从系统运行稳定性、持续性及处理性能的角度，配合物理设备、系统支撑软件（数据库系统、操作系统）的相关措施，应用软件可通过构建VIP服务通道的方式降低应用服务运行期间的相互影响。服务通道可以基于不同业务产品或不同应用服务管理框架的不同粒度来设置，从而满足部分应用处理资源只响应特定的服务请求或不同的服务监听响应不同的通道传递过来的服务申请的功能。 4.流量控制 在系统中，从系统运行稳定性、持续性角度，配合物理设备、系统支撑软
故障转移群集可以配置使用多种不同的配置。组成群集的服务器可以是活跃状态或不活跃状态，而不同服务器可以被配置为在活跃服务器故障后立刻接管相应的资源。一般故障转移的过程只需要几分钟的时间，至于时间的长短主要取决于群集的配置和具体应用，当节点处于活跃状态时，该节点上可以使用所有资源。 当服务器故障后，在这台服务器上配置了故障转移群集的资源组就会被其他服务器所接管。当故障服务器重新上线后，群集服务可以配置为允许让原服务器进行故障回复，或者是让当前服务器继续处理新的客户端请求。本文章将讲述基 于Windows Server 2008 R2的故障转移群集实现。 安装“故障转移群集”： 下面就开始在两个节点上安装群集服务。在此以server1为例，安装方法是：打开服务器管理器图标----添加功能，从中选择“故障转移群集”。 当两个节点安装完群集服务后，我们需要运行群集配置验证程序，来检查节点服务器、网络和存储设备是否符合群集要求。 仅当完整配置(服务器、网络和存储)可以通过“验证配置”向导中的所有测试时，微软才支持故障转移群集解决方式，另外，解决方案中的所有硬件组件均必须标记为“certified for windows server 2008 R2”。 方法是在server1或者是server2上进入故障转移群集管理器，单击“验证配置”。如下图所示：
因为我们需要验证的是群集中的所有节点，所以我们需要把所有节点都添加进来，如下图所示： 点击“下一步”之后，我们需要“运行所有测试”，如下图所示：
给出验证清单，也就是所要进行验证的项目。点击，下一步之后，开始出现下面的验证过程：
【赛迪网独家特稿】集群技术是使用特定的连接方式，将相对于超级计算机便宜许多的计算机设备结合起来，提供与超级计算机性能相当的并行处理技术。早在七十年代就有人提出可以使用这种集群技术完成并行处理，但是由于受到当时网络交换技术的限制，集群系统在性能上与其他并行处理系统相距甚远，直到网络技术逐渐成熟的今天，它才具备了与超级计算机相匹敌的能力。 什么是集群 集群（Cluster）技术是指一组相互独立的计算机，利用高速通信网络组成一个计算机系统，每个群集节点（即集群中的每台计算机）都是运行其自己进程的一个独立服务器。这些进程可以彼此通信，对网络客户机来说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据，并以单一系统的模式加以管理。一个客户端（Client）与集群相互作用时，集群像是一个独立的服务器。 计算机集群技术的出发点是为了提供更高的可用性、可管理性、可伸缩性的计算机系统。一个集群包含多台拥有共享数据存储空间的服务器，各服务器通过内部局域网相互通信。当一个节点发生故障时，它所运行的应用程序将由其他节点自动接管。在大多数模式下，集群中所有的节点拥有一个共同的名称，集群内的任一节点上运行的服务都可被所有的网络客户所使用。 集群的特点 1．提供强大处理能力的高性能计算机系统：计算机集群可以通过负载均衡、并行处理、时间片处理等多种形式，将多台计算机形成高性能计算机集群。对用户端（Client）而言，计算机集群则是一个单一的系统，可以为用户提供高性能的计算机系统，而用户不用关心有多少计算机承担了系统实现的任务，而只需要关注系统的整体处理能力。因此，计算机集群可以用多台普通性能的计算机组成具有高性能的计算机系统，承担只有超级计算机才能胜任的工作。 2．提供高可用性的计算机系统：通过计算机集群技术组成的系统，可以确保数据和应用程序对最终用户的高可用性，而不管故障属于什么类型。即当计算机集群中的节点计算机出现软硬件故障的时候，高可用性集群提供了对软件和硬件失败后的接替。它将服务器镜像到备用系统或节点中，当主节点上的系统崩溃时，冗余节点就从替补角色转换到正式角色，并自动投入应用，从而保证了系统运行的不间断。
高可用报告 一、 高可用分析 1、三个概念 失效(fault)：指设备或程序自身固有缺陷导致的瞬间或永久性的功能失常。 错误(error)：由失效导致的系统内部不正确行为。错误可以被发现并进行纠正。 故障(failure)：指由于出现错误导致了系统产生了不正确的结果。 2、平均故障发生时间MTTF ( Mean Time To Failure ) MTTF 是一个统计上可测量的参数 MTTF 寿命 MTTF= 1 / 稳态运行期间的故障发生率 N 台机器T 时间内故障数: E = (N ×T)/ MTTF 3 可靠性: 系统连续提供服务的能力，MTTF: Mean Time To Failure 可维护性:修复故障使系统恢复正常的能力，MTTR: Mean Time To Repair 4、可用性(Availability) 可用性= MTTF / (MTTF + MTTR) 例: MTTF=5000小时, MTTR=1天, 则可用性为： 5000/(5000+24) = 99.52% 5、提高可用性的途径 1) 提高 MTTF 2) 降低 MTTR 二、硬件高可用 （一） Cluster 中硬件HA 的目标 1、 问题的起源：单点故障问题及其应对策略
单点故障：某些硬件或软件部件，它们的故障会导致整个系统的崩溃。[6] 机群系统可能出现的单点故障有： ●处理器或节点 ●存储程序或数据的磁盘 ●适配器、控制器和连接节点到磁盘的电缆 ●用户访问机群节点的网络。 ●应用程序 应对策略：通过系统地消除那些单点故障来尽可能使更多的故障成为部分故障。[6]解决机群中的单点故障问题：解决大多数的单点故障问题并不需要使用任何分层软件产品。计算从任何特殊错误中恢复所需人工干涉的总时间和精力。然后再考虑系统能否承受停机造成的损失，以及能否提供全天操作中必须的人工干预。对于机群设计者而言，这将有助于决定是使用人工干预来管理还是需要采取其它措施来满足高可用性的要求。 ?节点故障 在机群中，当一个节点提供的服务是关键性的话，那么当该节点失效时，机群中必须有另外的节点来代替它的资源，向终端拥护提供相同的服务。 包括以下步骤： 1、在备用节点的网络适配器配置失效节点的地址，或者提示用户（或改变客户端应用程序） 使用一个替换的地址。 2、在故障和备用节点之间引入和改变所有组的卷，并且装上所有需要的文件系统。 3、修复存储在故障节点内部磁盘上的所有应用程序和数据。 4、执行任何鉴定性的应用程序。 假定后备节点在关键服务中还没有被网络访问。这样，每个节点需要额外的网络适配器，这个节点将被备份。如果用户通过串行连接访问失效节点，每个终端应该物理上重连接到后备节点的端口上。如果外部磁盘没有连接到失效节点和后备节点之间的通用总线上，则需要手工将他们从一个转换到另一个。所有关键数据被保存在外部磁盘上。如果最后的后备节点变为不可用，所有关键数据则被保存至节点的内部磁盘。 ?磁盘和I/O总线故障 为了防止包括磁盘的外部I/O通道中的任何部分出错，应该在两路I/O总线上将磁盘镜象或者使用从节点到存储子系统有双重路径的磁盘阵列系统。 ?网络适配器故障 为了防止网络适配器故障，每个提供关键服务的节点需要配置备用网络适配器。这个适配器连接到与用户正在访问的主适配器相同的网络主干上。如果网络适配器失效，可以将备用适配器的地址改为失效适配器的地址。另外一种方法是始终有一个热备份的网络适配器可以随时替代出错适配器。这种方法从故障中恢复的时间更短，因为系统安装备用适配器无需停机。 ?网络故障 如果用户正在和一个节点通信时网络主干停止工作，解决方案之一是人工地将所有机群节点和客户端机器切换到另外一个主干上。即便有足够的时间和精力去这样做，还得保证没有松散的连接或网络设备（路由器、集线器或网桥）故障引起主干失效。另外一个解决方案是连接一个终端的子集到备用节点的串口上，这样还可以提供最小级别的服务。在这种情况下应用程序必须被设计成允许用户既可以通过网络连接到终端也可以通过串口连接到终端。 ?应用程序故障 根据应用程序的设计，为监控应用程序使用的后台程序，并及时对状态改变作出反应，应该使用AIX子系统资源控制器。 2、人工干预的缺点 根据上述的讨论，依据故障的不同类型。包括检测故障所花时间，很明显从任何机群故障中人工恢复的时间为30分钟到几个小时。这对许多应用在重要场合的机群来说已经是不可容忍的了。
VMware vSphere创建Windows Server 2008 R2 + SQL Server 2008 R2群集1.打开WMware vSphere Client，登录vCenter； 2.进入vCenter控制台，点击地址栏“清单”-“虚拟机和模板”； 3.从左边列表中选择win2008r2模板，点击“部署为新虚拟机”，打开【部署模板】向导；
4.【名称和位置】界面，“名称”栏键入第一台虚拟机名称，并在“清单位置”选择VM数据中心位置， 点击“下一步”； 5.【主机/群集】界面，选择虚拟机安装到哪台主机或群集上，点击“下一步”；
6.【存储器】界面，“选择虚拟磁盘格式”选为“Thin Provision”，并选择虚拟机存储位置，点击“下一 步”； 7.【客户机自定义】界面，直接点击“下一步”；
8.【即将完成】界面显示部署信息，点击“完成”确认创建新虚拟机； 9.等待vCenter创建新虚拟机完成后，对该虚拟机的属性进行编辑； 1)编辑“网络适配器”，根据虚拟机的IP地址选择“网络连接”-“网络标签”；
2)由于Windows故障转移群集需要两块网卡，所以需添加一块网络适配器； 3)Windows Server 2008 R2 + SQL Server 2008 R2群集需使用至少三块共享磁盘（仲载、MSDTC、
数据），所以需依次添加三块虚拟硬盘，点击【虚拟机属性】界面“添加”按键打开【添加硬件】向导，选择“硬盘”，点击“下一步”； 4)此虚拟机为群集的第一个节点虚拟机，应选择“创建新的虚拟磁盘”，点击“下一步”； 5)调整磁盘容量，选择“厚置备置零”，“位置”必须是两台群集虚拟机都能找到的位置，本教程的
Linux下高可用集群方案很多，本文介绍的是性价比比较高的一种: 使用Heartbeat 2.0配置Linux高可用性集群。 一、准备工作 你首先需要两台电脑，这两台电脑并不需要有相同的硬件（或者内存大小等），但如果相同的话，当某个部件出现故障时会容易处理得多。接下来您需要决定如何部署。你的集群是通过Heartbeat 软件产生在两台电脑之间心跳信号来建立的。为了传输心跳信号，需要在节点之间存在一条或多条介质通路（串口线通过modem电线，以太网通过交叉线，等等）。现在可以开始配置硬件了。既然想要获得高可用性（HA），那么您很可能希望避免单点失效。在本例中，可能是您的null modem线/串口，或者网卡（NIC）/ 交叉线。因此便需要决定是否希望为每个节点添加第二条串口null modem连线或者第二条NIC/交叉线连接。我使用一个串口和一块额外的网卡来作为heartbeat的通路，这是因为我只有一条null modem线和一块多余的网卡，并且认为有两种介质类型传输heartbeat信号比较好。硬件配置完成之后，便需要安装操作系统以及配置网络（我在本文中使用的是RedHat）。假设您有两块网卡，那么有一块应该配置用于常规网络用途，另一块作为集群节点之间的专用网络连接（通过交叉线）。例如，假设集群节点有如表-1下的IP地址： 表-1集群节点的IP地址 输入如下命令检查您的配置： ifconfig 这将显示您的网卡及其配置。也可以使用命令“netstat –nr”来获得网络路由信息。如果一切正常，接下来要确定可以来两个节点之间通过所有接口ping通对方。如果使用了串口，便需要检测其连接情况。把一个节点作为接收者，输入命令： cat
如何构建高可用性高扩展性的系统
1高可用性 1.1避免故障 1.1.1明确使用场景 保持系统简单 1.1.2设计可容错系统 Fail Fast原则 主流程任何一步出现问题，就应该快速结束接口和对象设计要严谨 能否被重复调用 多线程并发环境下是否有异常 对象类型是否需要检查 1.1.3设计具备自我保护能力的系统对第三方资源持怀疑态度，提供降级措施1.1.4限制使用资源 内存
防止集合容量过大造成OOM 及时释放不再使用的对象 文件 网络 连接资源 线程池 1.1.5其他角度 分析可能的风险 1.2及时发现故障 1.2.1监控报警系统 1.2.2日志系统和分析系统1.3及时故障处理 1.3.1降级 1.3.2限流 1.4访问量上涨的应对策略
1.4.1垂直伸缩 增加配置 1.4.2水平伸缩 增加机器 1.4.3拆分 按业务拆库 按规则拆表 1.4.4读写分离 实时性要求不高、读多写少的系统如何快速地从写库复制到读库 1.4.5其他 容量规划 2高可扩展性 2.1垂直伸缩 2.1.1高访问量
增加CPU 锁 线程数 单线程程序 增加内存 cache JVM堆 2.1.2大数据量 分表 单表数据量减少 跨表查询、分页查询复杂度提升2.1.3计算能力 线程数提升 2.2水平伸缩 2.2.1高访问量
SNA（Shared Nothing Architecture）有状态的部分，放入缓存或数据库中有状态的情况 存在内存的状态 广播同步 例如session同步 单台机器容量有限 分布式缓存 一致性hash 文件 直连存储DAS((Direct-Attached Storage) 网络存储 NAS(Network Attached Storage) SAN(Storage Area Network) 分布式文件系统 GFS HDFS 数据库问题 cache
Windows server 2012 Hyper-V故障转移群集 和终端用户相比，企业用户对于业务的连续性和可靠性更为在意。相对而言，企业一般不会将追逐单一硬件的性能排在第一位。 如何衡量业务是否持续可用，一般使用"x 个9"这种方式来定义。如我们常说的"3 个9"，即表示年可用性为99.9%，也即意味着一年只能有76 个小时的系统停机时间。对于单台物理服务器而言，这意味着该设备一年内不能出现硬件损坏的情况，否则更换配件和重新上架的时间过长，很容易导致可用性等级超出这个标准。 像"5 个9"，甚至"6 个9"这种高可用性是如何实现的呢？可想而知，通过单台物理服务器来实现这种目标将是非常苛刻且成本高昂的。 常见的可用性与相应的可允许停机时间如表8-1 所示。 为了满足企业对业务持续可用的追求，降低年故障停机时间，系统、网络、存储各大厂商都引入了"群集"的概念。"群集"的作用是通过多台硬件同时运行来实现的，当故障发生时，通过快速且自动化的切换故障服务器，从而实现业务的持续运行。和传统的硬件故障或网络故障发生后，需要人为参与排障不同的是，群集技术是不需要人为参与的，可以做到全自动运行。当故障发生时第一时间转移故障节点，从而极大限度的提升业务持续可用的能力。 Windows Server 2012 R2 作为新一代的Cloud OS，其Hyper-V 角色自然也拥有"群集" 的能力。Windows 下的群集技术被称之为"故障转移群集"，Hyper-V 角色的故障转移群集目的很明确：当群集内某一台Hyper-V 主机出现故障无法提供服务时，可由群集内的其他主机快速接管任务，继续为用户提供持续可用的服务。
PLUSWELL多机集群、数据备份解决方案 北京蓝科泰达科技有限公司 2008年7月
一：概述 企业和事业单位的运转越来越依赖于计算机系统，如果一旦这个数据处理中心无法正常运转，就会造成业务停顿，导致不可挽回的损失。 而现有的双机热备份设备存在价格高昂，成本较高的情况，往往使用户望而却步。而用户寻求底成本的纯软件方案又往往因产品不容易维护，纯软件双机方案不稳定等因素，往往给用户造成不必要的使用麻烦。有时因护理不当造成数据损坏，发生更大的事故。 蓝科泰达凭借其丰富的研发经验，为您提供高可用性系列产品和优质的服务，推出了蓝科泰达双机容错打包解决方案，目的在于保证数据永不丢失和系统永不停顿，同时为用户节省大量的开支。蓝科泰达容错系统结合了蓝科泰达磁盘阵列产品的安全可靠性与双机容错技术高可用性的优点，相互配合二者的优势。蓝科泰达磁盘阵列针对双机容错技术做了许多优化和改进，满足了双机硬件的连接要求，根据应用环境的实际情况，适用于Windows2000平台以上，开放源代码Linux 平台，SCO UNIX平台上的多种双机热备软件。 二、需求分析 企业关键业务一旦中断，企业的日常运作将受到致命的影响，那么就要求我们的系统在最短的时间内将系统恢复到正常状态。 所以我们要求双机软件能够实现以下几点： 1、异常终端检测 2、网络故障，系统故障，应用程序故障等全系统检测 3、当高可用系统中的某个节点故障，无须人工干预自动切换，保障系统运行 4、速度快（快速恢复） 贵单位业务平台，是以Windwos 2003 Server系统平台为基础，以SQL Server核心的数据 库应用系统，该系统对稳定性要求很高、系统实时性和可用性提出要有连续运行的能力，系统一旦出现故障，其损失是惨重的。 因此，建议用户采用高可用技术，高可用系统在各个节点间保持的间歇的通讯，使系统中的独立节点组合成整体的一套系统，并使用PlusWell 软件可以保障该系统中的某一节点故障都可 被PlusWell 软件所监控，如主服务器应用程序、网卡、操作系统，均纳入公共的安全体系，确 保7*24的不停机。 比较典型的危及系统安全应用和系统错误主要有： （1）进程错误，比如用户应用与文件数据库的连接异常中断或用户进程发生错误。 （2）文件系统故障，由于异常操作或其它原因造成文件系统内部部分信息丢失或不一致。 （3）操作系统故障，操作系统本身的系统调用问题及底层的应用驱动在安装或更新出现冲突； （4）网络线缆故障。 （5）介质问题，网络连接或物理硬盘也可能会出现问题。 方案拓扑：
双机热备份方式 在双机热备份方式中，主服务器运行应用，备份服务器处于空闲状态，但实时监测主服务器的运行状态。一但主服务器出现异常或故障，备份服务器立刻接管主服务器的应用。也就是目前通常所说的active/standby 方式，主要通过纯软件方式实现双机容错。 LAN HeartBeat Active Standby AppA DiskArray 当前应用最广泛的双机热备份软件主要有LifeKeeper,Rose HA, DataWare和MSCS。 Rose工作模式: 1)双主机通过一条TCP/IP网络线以及一条RS-232电缆线相联 2)双主机各自通过一条SCSI电缆线与RAID相联 3)主机NT1为active，主机NT2为standby 4)主机NT1处理作业和数据，主机NT2作为热备份机 5)主机NT1故障后，主机NT2自动接管主机NT1的作业和数据 6)主机NT2同时接管NT1的主机名(Host)及网络地址(IP) 7)主机NT1的作业将在主机NT2上自动运行 8)主机NT1的客户(client)可继续运行，无需重新登录 9)主机NT1修复后，自动接管原来的作业和数据，主机NT2继续作备份机 双机互备份方式 在这种方式中，没有主服务器和备份服务器之分，两台主机互为备份。主机各自运行不同应用，同时还相互监测对方状况。当任一台主机宕机时，另一台主机立即接管它的应用，以保证业务的不间断运行。也就是目前通常所说的Active/Active方式，主要通过纯软件方式实现双机容错。通常情况下,支持双机热备的软件都可以支持双机互备份方式,当前应用最广泛的双机互备软件主要有LifeKeeper,Rose HA, DataWare和MSCS。 以Rose 为例：