在当今竞争激烈的环境中，“时间就是金钱”这句格言具有了字面意义。保持您企业的数据在线和可访问是整体系统正常运行时间的基础。无论是数据库后端、Web 服务器还是用作电子邮件和用户目录的网络文件系统 (NFS)，数据存储层的中断都可能是灾难性的。

提高站点整体可靠性的最具成本效益的方法是实施故障转移集群。故障转移集群涉及将多台计算机汇集在一起，每台计算机都是文件系统、数据库或应用程序的候选服务器。这些系统中的每一个都监控集群中其他系统的健康状况。如果其中一个集群成员发生故障，其他成员将接管故障节点的服务。接管通常以对访问数据的客户端系统透明的方式执行。

典型的故障转移集群实现包括连接到一组共享存储单元（例如磁盘）的多台系统，这些存储单元连接到共享 SCSI 或光纤通道总线。每个集群成员通常通过网络（例如，以太网）和/或点对点串行连接监控其他成员的健康状况。从历史上看，企业级集群产品一直是 Digital、HP 或 IBM 等专有供应商的领域。最近，基于 Linux 的可行集群产品已经出现，它们可以在商用硬件上运行。

在 Web 上快速浏览一下，您会发现各种基于 Linux 的集群替代方案。它们中的大多数在纸面上看起来都很棒。它们将吹嘘在由任意数量节点组成的集群上为大量服务提供惊人的快速故障转移时间。很容易陷入购买错误集群产品的陷阱。事实是，并非所有高可用性集群替代方案都能安全地提高数据的可靠性和可用性。相反，选择错误类型的产品可能会使您宝贵的文件系统和数据库容易受到损坏。一些产品忽略提及这一事实；其他产品只有在您深入研究相关的白皮书后才会说明这一事实。

在 UNIX/Linux 高可用性业务领域工作超过七年，我目睹了集群产品的兴衰。看到集群产品被推广用于它们不适合执行的工作，真是令人不安。将最终用户数据置于损坏的风险之中，给整个集群领域带来了坏名声。我通过多年的调查总结出一个简单的四点检查清单，作为评估高可用性集群产品是否符合您需求的指南。事实上，这些要点并非 UNIX 或 Linux 所特有；它们适用于任何硬件和操作系统实现。因此，在投入任何资金（以及您公司的数据）到高可用性集群解决方案之前，请确保您了解该解决方案如何保护您免受以下四种故障场景的影响

我们将详细讨论这些要点，并指出典型的陷阱。但在分析这四个要点之前，至关重要的是要了解数据完整性的全部意义。数据完整性的基本要点是了解您的数据是准确和最新的。听起来很简单。在集群环境中，维护数据的完整性至关重要，甚至超越了数据可用性。

使用示例有助于说明这一点。图 1 中的图表描述了一个双节点集群（为简单起见，我使用双节点集群，这些概念也适用于由两个以上节点组成的集群），集群成员 A 和 B 连接到带有磁盘 1 的共享 SCSI 总线。

图 1. 带有共享 SCSI 总线的双节点集群

典型的操作系统通过文件系统提供对基于磁盘的存储的访问，而文件系统又访问磁盘存储。通常，文件系统挂载磁盘卷，然后容纳用户访问。为了提高性能，文件系统实现通常将文件系统数据的最新副本缓存在内存中。因此，您的数据（由节点 A 提供服务）的最新版本实际上是系统 A 内存中缓存的内容加上磁盘数据的组合。

现在将此示例扩展到另一个集群成员（节点 B）。如果节点 B 要挂载相同的文件系统并访问它，那么您的文件系统的真实内容现在将包括节点 A 的内存中缓存的数据、节点 B 的内存中缓存的数据以及磁盘数据。要使这项工作正确运行，需要实现一个文件系统，该文件系统协调多个系统的内存中缓存数据以及磁盘数据。这种模型，其中所有集群成员可以同时挂载相同的文件系统，被称为集群文件系统。很少有 UNIX 产品实现集群文件系统，并且今天没有 Linux 变体实现生产就绪的集群文件系统（尽管正在进行努力，请参阅 GFS 项目 http://www.gfs.lcse.umn.edu/）。

在没有集群文件系统的情况下，如果多个集群成员同时访问相同的文件系统会发生什么？可能的后果包括

当文件系统的数据或元数据变得混乱时，就会发生数据损坏。要纠正数据损坏问题，通常意味着从磁带备份恢复（您定期执行此操作，对吧？）。这里的问题是，由于备份频率相对于事务速率较低，因此从数据损坏中恢复所需的时间通常以天而不是您期望从部署高可用性集群中获得的少量分钟或秒来衡量。

上述关于要求集群成员同步其对文件系统数据的访问以防止数据损坏的概念也适用于数据库。大多数数据库实现不允许多个集群成员同时为相同的底层磁盘数据提供服务。对此的显着例外包括 Oracle Parallel Server（目前正在移植到 Linux）和 Informix Extended Parallel Server。

所有这一切的结果是，您选择的集群实现必须确保单个文件系统或数据库在任何时间点只能由单个集群成员提供服务——这非常简单，如果您可以找到在所有情况下都执行此操作的集群产品。现在，让我们继续了解这在前面提到的四种场景下如何成立。

高可用性集群的最大好处之一（具有讽刺意味的是被忽视了）是能够干净地将服务从集群成员迁移出去，以便您可以执行例行维护，而不会中断对客户端系统的服务。例如，这允许您将软件升级到最新版本或向系统添加内存，同时保持站点的运行。

如果您认为某个操作系统是防崩溃的，请给我打电话，我会把布鲁克林大桥连同该操作系统一起卖给您。面对现实吧，系统崩溃是生活中的事实；这仅仅是一个最小化其频率的问题。为了响应系统崩溃，其他集群成员将断定服务器已变得无响应，并开始接管以前由故障节点提供的服务。

在发生系统崩溃时，几乎所有故障转移集群实现都会正确接管故障节点的服务。到目前为止一切顺利——看起来几乎任何故障转移集群产品都适合您。没那么快；以下几点将可信的产品与不可信的产品区分开来。

典型的高可用性集群实现由一组集群成员组成，每个成员通过各种“集群互连”监控其他成员的健康状况。从历史上看，许多专有集群供应商都依赖于自定义硬件来实现其集群互连。虽然这提供了可靠的集群实现，但从本质上讲，它往往非常昂贵，并且会将您锁定在单个供应商中。为了提供具有成本效益的替代方案，其他集群实现通过常用的网络互连（通常是以太网）和串行端口连接来监控系统健康状况。在这些配置中，集群成员定期交换消息，并根据响应（或缺乏响应）来判断其他成员是启动还是关闭。这种系统健康状况监控消息的交换通常被称为“心跳”。

基于“心跳”的集群的常见问题是通信分区。这是指集群成员（或一组成员）已启动，但无法相互通信。例如，以下图 2 描述了一个双节点集群，节点之间通过以太网和串行连接交换心跳消息。

图 2. 带有以太网和串行连接的双节点集群

假设您已经设置了高可用性集群，并且去拉斯维加斯度周末了，您的公司的新在线订购系统部署在这种配置中，让您感到自满。进一步想象一下，清洁工不小心用扫帚碰掉了以太网连接。现在，在每个节点上运行的两个集群成员的集群软件必须决定如何响应这种情况，以维护高可用性。由于成员无法通信，他们必须单独做出决定。以下是一些集群产品常用的策略选项

为了避免这些形式的通信分区，常见的集群实践是采用多个通信互连。例如，您可以让系统通过多个以太网或以太网和串行连接的组合来监控彼此的健康状况。同样，您可以让每个网络连接都通过单独的集线器/交换机或成为点对点链路。

大多数集群实现都允许您配置多个通信互连，以消除通信分区的可能性。（如果他们不这样做，您可能应该迅速转向另一个供应商。）

这是任何集群实现都可能面临的最严重的故障场景。如果您之前没有从我这里购买桥梁，那么如果您认为系统永远不会挂起，也许我可以让您对桥梁感兴趣。这是计算机业务中另一个不幸的事实。我们都见过系统神秘地“锁定”，您唯一的补救措施是重置或断电重启系统以使其再次响应。幸运的是，这种情况相对罕见。

正如计算机可以神秘地挂起一样，它们也可以解除挂起。您肯定遇到过系统“锁定”的情况，然后在一段时间后再次变得响应迅速。这可能发生在任何操作系统上。

评估集群产品的关键问题是了解集群在挂起/解除挂起场景中将如何响应。这就是为什么这个问题如此重要的原因：在挂起场景中，节点 A 变得完全无响应。假设您从上一节描述通信故障中吸取了教训，并构建了一个具有两个以太网连接和一个串行连接的集群，以便如果其中任何一个连接发生故障，您的集群仍然可以运行。好吧，为了响应系统挂起，无论您有多少 50 个冗余连接都无关紧要——它们都将无法接收到对系统监控心跳请求的任何响应。为了响应这一点，节点 B 会注意到节点 A 未能响应所有三个通道上的心跳，并断定节点 A 已关闭。在此之后，节点 B 将挂载以前由节点 A 提供服务的文件系统或启动数据库。

此时，节点 A 可能会解除挂起并开始更新文件系统。这导致两个节点同时挂载和修改相同的文件系统的情况，从而造成数据完整性违规。

这是任何集群实现的真正试金石。为了防止数据完整性受到损害（即，系统崩溃或数据无效），集群成员必须在接管故障节点的服务之前，确保故障节点无法修改文件系统或数据库。这通常称为 I/O 隔离或 I/O 屏障。

为了规避这种审查，一些集群产品的所有者会认为节点挂起/解除挂起场景是不太可能发生的。值得庆幸的是，在实践中，系统挂起/解除挂起场景很少发生。但是，在完全忽略此标准之前，请记住，这是您的数据，并且所有数据损坏的影响都处于危险之中。

如果您足够关心系统的可用性以保证集群部署，那么至关重要的是，您选择的故障转移集群实现能够确保在每种四种故障场景下都保持数据完整性。请记住，您 IT 基础设施最宝贵的资产是拥有有效、准确的数据。未能确保数据完整性维护的代价是系统停机时间延长或事务丢失，这两者都可能是灾难性的。