HA架构：高可用性简介

当组织的计算机系统和应用程序由于计划外停机而无法访问时，声誉损害可能与财务损失一样严重。如果受影响的系统需要数小时才能重新上线，则尤其如此。为防止停机时间延长，您应该为您的 IT 基础架构实施高可用性 (HA) 架构，使您能够实现高达 99.999% 的正常运行时间并将服务中断降至最低。本文更详细地解释了 HA 架构。

HA架构的定义

有些组织要求他们的系统 24/7 全天候运行。对于这些组织，HA 架构是必不可少的。虽然 HA 不保证系统不会受到计划外中断的影响，但它可以最大限度地减少此类中断对您的操作的影响。响应速度更快的系统是 HA 的另一个好处。

HA 架构可确保您的系统启动并运行，并且在面对不可预见的情况（如硬件和软件故障）时可供用户访问。有了它，您可以使用多个组件来确保持续且响应迅速的服务。您必须确保这些组件相互补充，否则您只会为您的应用程序添加潜在的故障点，从而增加停机的可能性。

以下是 HA 架构必须具备的四个特征：

• 冗余硬件：缺乏冗余硬件意味着在服务器崩溃后重新启动之前无法处理任何请求。发生这种情况时，停机是不可避免的。因此，您的 HA 架构必须包括备份硬件，例如在生产硬件崩溃时自动接管的服务器或服务器集群。
• 冗余软件和应用程序：为防止在生产环境中使用的软件和应用程序出现故障时出现潜在的停机时间，您的 HA 架构必须包含备份软件和应用程序。
• 冗余数据：由于某种原因而离线的数据库服务器可能会对您的生产环境造成严重破坏。您的 HA 架构应该包括备份数据库服务器的规定，只要生产数据库服务器脱机，就可以将处理转移到这些服务器上。
• 无单点故障：单个组件的故障不应使整个基础架构崩溃。通过硬件、软件和数据的冗余，消除了单点故障。

对于不需要持续运行的组织，HA 可能不是必需的，尤其是因为它需要投资新的硬件和软件，并且会增加您的维护和其他相关成本。在决定 HA 架构之前，请确保将与向基础架构添加更多组件相关的成本考虑在内。如果您决定将 HA 集成到您的基础架构中，那么选择云而不是本地基础架构可以帮助您的组织节省成本。确保回报值得您投入额外组件的投资。

如何获得高可用性

理想的 HA 架构应包括确保冗余、数据备份和恢复、自动故障转移和负载平衡的元素。

冗余

如上所述，冗余是 HA 的一个关键特征，尽管它会增加实现 HA 的成本。采用冗余时，您可以从五种模型中进行选择，随着需要更多组件，每种模型的成本都会逐渐增加。

• N+1 模型：这需要对基础架构中的每个组件进行独立备份。它可以是主动/被动的，这意味着备用组件处于待机状态并准备好在主要组件出现故障时接管，也可以是主动/主动，这意味着备用组件与主要组件同时运行。尽管这是成本最低的模型，但它并非完全多余。因此，它可能并不完全适合大型系统。
• N+2 模型：这类似于 N+1 模型，但每个主要组件需要两个备用组件。如果一个备份组件也发生故障，则另一个备份组件将接管。
• 2N 模型：这使运行系统所需的资源数量增加了一倍。例如，如果一个系统需要四台服务器来运行，那么 2N 模型会向系统添加另外四台服务器，从而使服务器总数为八台。因此，即使多个组件出现故障，系统也始终具有运行能力。
• 2N+1 模型：这类似于 2N 模型，只是它添加了另一个备份组件，当额外容量出现停机问题时可以接管。
• 地理冗余：这是最昂贵的模型，因为它将系统分布在多个位置的服务器中。当一个位置出现故障时，另一个站点会接管，从而保持您的运营正常运行。鉴于其成本，如果您决定采用这种模式，那么与在全球拥有数据中心的云服务提供商签约是您的最佳选择。

数据备份与恢复

需要定期进行完整的数据备份以确保 HA，并且应该包含在您的灾难恢复计划中。确保定期测试您的数据备份，并确保它们可以立即恢复。此外，您应该通过将数据存储在多个位置的辅助服务器或备用实例中来复制数据。这些位置中的数据应始终与您的主要位置中的数据同步。当灾难袭击您的主要位置时，其他位置应该准备好接管。

带故障检测的自动故障转移

在发生故障的情况下，备份系统应准备好在称为自动故障转移的过程中立即接管。及时的故障检测对于该系统的工作至关重要。

具有自动故障转移的 HA 架构如下所示：

• 有一个主系统和一个称为热备用的备份系统。
• 在主系统和备用系统之间进行持续监控。
• 当主系统出现故障时，备用系统或热备用系统会自动接管。新请求现在由备份系统处理，它现在就像主系统一样。
• 当主系统中的问题得到解决后，它会重新上线并恢复其原来的角色。热备用恢复为备份。

用户在上述过程中不知道有任何变化。如果处理得当，故障转移对他们来说是透明的。

负载均衡

HA 架构使用负载平衡确保更好和更可靠的应用程序性能，该过程涉及使用基于硬件或软件的解决方案在多个服务器之间分配网络流量。您应该配置负载均衡器以使用适合您要求的算法。常见的负载均衡算法包括：

• 循环：负载平衡器将传入请求定向到第一台服务器，然后是第二台服务器，依此类推。
• 最少连接：负载均衡器找到连接数量最少的服务器，并将传入流量定向到该服务器。
• 源 Internet 协议 (IP) 哈希：负载均衡器始终根据源的 IP 地址定向请求。这涉及寻找最接近传入请求的服务器。

负载平衡本身并不能保证 HA，因为它仍然可能是单点故障。要解决此潜在问题，您应该为负载平衡解决方案实施冗余。

如何衡量高可用性

虽然经常互换使用，但可用性和正常运行时间彼此不同。虽然系统可以启动并运行，但由于网络问题等因素，用户不一定可以使用它。此外，正常运行时间只是可用性的一个方面，而停机时间是另一个方面。

可用性是指系统在特定时期内工作的概率。以百分比表示，它是评估与托管解决方案的潜在供应商的服务水平协议 (SLA) 时要考虑的重要指标。

要计算可用性，请考虑以下因素：

• 年营业时间
• 待机时间
• 用于年度预防性维护的总时间
• 用于年度纠正性维护的总时间
• 等待行政和后勤延误所花费的时间

可用性的理想度量被称为五个 9或给定时间段内的 99.999% 可用性。这意味着一年中的停机时间略高于五分钟。如果 24/7 运营对您的组织至关重要，那么您应该争取 99.999% 的可用性。

高可用性集群的类型

服务器集群是支持 HA 架构的服务器组。使用专用网络连接持续监控集群中每个节点的运行状况。当一个节点宕机时，另一个节点接管它的操作。

在设计 HA 架构时，您可以从不同的集群类型中进行选择，包括：

• 主动/被动集群：在这种集群类型中，有一个始终处于活动状态的主节点，这意味着它处理来自用户的所有请求。备份节点是被动的或非活动的，这意味着它无法处理传入的请求。但是，当主节点出现故障时，被动节点会接管。当主节点的问题得到解决后，它会继续处理所有请求，而备份节点会再次回到被动状态。
• 主动/主动集群：在这种集群类型中，节点都是活动的，可以处理传入的请求。当一个节点出现故障时，其他活动节点之一将接管。当另一个节点的问题得到解决时，请求会再次分发到集群内的所有节点。
• 无共享与共享磁盘集群：对于无共享集群，每个节点都有自己的数据库，该数据库与其他节点中的数据库同步。因此，当一个节点出现故障时，其他节点仍然可以运行。因此，无共享集群对于实现 HA 至关重要。相比之下，共享磁盘集群的特点是所有节点共享一个数据库，这意味着当数据库宕机时，所有节点也会宕机。