什么是高可用性架构？它为什么如此重要？

实现业务连续性是现代组织的首要关注点。停机可能会导致重大的财务影响，在某些情况下，还会导致无法恢复的数据丢失。

避免服务中断和计划外停机的解决方案是采用高可用性架构。

因为每个企业都高度依赖互联网，所以每一分钟都很重要。这就是公司计算机和服务器必须始终保持运行的原因。

无论您选择容纳自己的 IT 基础架构还是选择在数据中心托管解决方案，在设置 IT 环境时必须首先考虑高可用性。

高可用性定义

高可用架构涉及多个 组件协同工作，以确保在特定时间段内不中断服务。这还包括对用户请求的响应时间。也就是说，可用的系统不仅必须在线，而且还必须响应。

实施能够实现这一目标的 云计算架构 是确保关键应用程序和服务持续运行的关键。即使发生各种组件故障或系统处于高压力下，它们也能保持在线并做出响应。

高度可用的系统包括在尽可能短的时间内从意外事件中恢复的能力。 通过将流程转移到备份组件，这些系统可以最大限度地减少或消除停机时间。这通常需要持续维护、监控和初步深入测试，以确认没有弱点。

高可用性环境包括带有系统软件的复杂服务器集群，用于持续监控系统性能。首要任务是避免计划外的设备停机。如果某个硬件出现故障，则不得在生产期间导致服务完全停止。

对于大型组织而言，不间断地保持运营尤为重要。在这种情况下，几分钟的损失可能会导致声誉、客户和数千美元的损失。只要可用性水平不影响业务运营，高度可用的计算机系统就允许出现故障。

高可用性基础架构具有以下特征：

硬件冗余

软件和应用程序冗余

数据冗余

消除单点故障

如何计算高可用性正常运行时间百分比？

可用性是通过特定系统在特定时期（通常是一年）内保持完全运行的时间来衡量的。

它以百分比表示。请注意，正常运行时间不一定与可用性相同。系统可能已启动并正在运行，但对用户不可用。造成这种情况的原因可能是网络或 负载平衡 问题。

正常运行时间通常用五个 9 的可用性等级来表示。

如果您决定采用托管解决方案，这将 在服务水平协议 (SLA) 中定义。“一个九”的等级意味着保证的可用性为 90%。今天，大多数组织和企业至少需要“三个九”，即 99.9% 的可用性。

企业有不同的可用性需求。那些需要全年全天候运行的设备将瞄准“五个九”，即 99.999% 的正常运行时间。看起来 0.1% 并没有太大的区别。但是，当您将其转换为小时和分钟时，这些数字很重要。

如何实现高可用性

希望实施高可用性解决方案的企业需要了解系统获得高可用性所需的多个组件和要求。为确保业务连续性和可操作性，关键应用程序和服务需要全天候运行。实现高可用性的最佳实践涉及需要满足的某些条件。以下是实现 99.999% 可靠性和正常运行时间的 4 个步骤。

1. 消除单点故障高可用性与冗余

高可用性系统的关键要素是通过在所有级别上实现冗余来消除单点故障 。无论是自然灾害、硬件还是电源故障，IT 基础设施都必须有备用组件来替换故障系统。

存在不同级别的组件冗余。其中最常见的是：

N+1 模型 包括保持系统正常运行所需的设备数量（称为“N”）。 万一发生故障，每个组件都有一个独立的备份 组件。一个例子是为应用服务器使用额外的电源，但这可以是任何其他 IT 组件。该模型通常是主动/被动的。备份组件处于待命状态，等待发生故障时接管。N+1 冗余也可以是主动/主动的。在这种情况下，即使主要组件正常运行，备用组件也能正常工作。请注意，N+1 模型并不是一个完全冗余的系统。

N+2 模型 类似于 N+1。不同之处在于该系统将能够承受两个相同组件的故障。这应该足以让大多数组织保持正常运转。

2N 模型 包含双倍数量的运行系统所需的每个单独组件。该模型的优点是您不必考虑是否存在单个组件或整个系统的故障。您可以将操作完全移至备份组件。

2N+1 型号 提供与 2N 相同级别的可用性和冗余，并添加了另一个组件以改进保护。

最终的冗余是通过地理冗余来实现的。

这是应对自然灾害和其他完全停电事件的唯一机制。在这种情况下，服务器分布在不同区域的多个位置。

这些站点应放置在不同的城市、国家甚至大洲。这样，它们就完全独立了。如果一个地方发生灾难性故障，另一个地方将能够接手并保持业务运行。

这种类型的冗余往往非常昂贵。最明智的决定是从数据中心遍布全球的供应商那里寻求托管解决方案。

除了停电，网络故障是导致业务停机的最常见原因之一。

出于这个原因，网络的设计必须使其保持 24/7/365 全天候运行。为了实现 100% 的网络服务正常运行时间，必须有备用网络路径。他们每个人都应该有冗余的企业级交换机和路由器。

2.数据备份与恢复

数据安全是每个企业最关心的问题之一。高可用性系统必须有完善的数据保护和 灾难恢复计划。

绝对必须有适当的备份。另一个关键是在数据快速丢失、损坏或完全存储故障的情况下恢复的能力。如果您的业务需要较低的 RTO 和 RPO ，并且您无法承受丢失数据的后果，那么可以考虑的最佳选择是使用 数据复制。有许多备份计划可供选择，具体取决于您的业务规模、要求和预算。

数据备份和复制与 IT 高可用性齐头并进。两者都应该仔细计划。在冗余基础架构上创建完整备份对于确保数据弹性至关重要，不容忽视。

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

在高度可用的冗余 IT 基础架构中，系统需要在发生故障时立即将请求重定向到备份系统。这称为 故障转移。早期故障检测对于缩短故障转移时间和确保最大系统可用性至关重要。

我们推荐的高可用性软件解决方案之一是 Carbonite Availability。它适用于任何基础设施，无论是虚拟的还是物理的。

如需快速灵活的基于云的基础架构故障转移和故障恢复，您可以求助于 Cloud Replication for Veeam。故障转移过程适用于整个系统或其可能发生故障的任何部分。每当组件发生故障或 Web 服务器停止响应时，故障转移必须是 无缝 的并且是实时发生的。

该过程如下所示：

机器 1 及其克隆 机器 2 ，通常 称为 热备用。

机器 2 持续监控 机器 1 的状态以发现任何问题。

机器 1 遇到问题。由于多种原因，它失败或关闭。

机器 2 自动联机。现在，每个请求都被路由到 Machine 2 而不是 Machine 1。这对最终用户没有任何影响。他们甚至不知道Machine 1有任何问题 。

修复故障组件的问题后， 机器 1 和 机器 2 恢复其初始角色

故障转移过程的持续时间取决于系统的复杂程度。在许多情况下，这将需要几分钟。但是，它也可能需要几个小时。

规划高可用性必须基于所有这些考虑，以提供最佳结果。每个系统组件都需要符合实现 99.999% 可用性和缩短故障转移时间的最终目标。

4.负载均衡

负载均衡器可以是硬件设备或软件解决方案。其目的是跨多个服务器和组件分发应用程序或网络流量。目标是 提高整体运行性能和可靠性。

它通过有效管理负载和持续监控后端服务器的运行状况来优化计算和网络资源的使用。

负载均衡器如何决定选择哪个服务器？

许多不同的方法可用于跨服务器池分配负载。为您的工作负载选择一种将取决于多种因素。其中一些包括所服务的应用程序类型、网络状态和后端服务器的状态。负载均衡器根据当前传入请求的数量决定使用哪种算法。

一些最常见的负载平衡算法是：

循环赛。 使用循环，负载平衡器将请求定向到第一台服务器。它将向下移动列表到最后一个，然后从头开始。该方法易于实现，应用广泛。但是，它没有考虑服务器是否具有不同的硬件配置以及它们是否可以更快地过载。

最少的连接。 在这种情况下，负载均衡器将选择活动连接数最少的服务器。当请求进来时，负载均衡器不会像轮询那样为列表中的下一个服务器分配连接。相反，它将寻找当前连接最少的一个。在会话持续很长时间的情况下，最少连接方法对于避免 Web 服务器过载特别有用。

源 IP 哈希。 这个算法会根据请求的源IP地址来决定选择哪个服务器。负载均衡器使用源 IP 地址和目标 IP 地址创建唯一的哈希键。这样的密钥使其始终能够将用户的请求定向到同一服务器。

负载均衡器确实在实现高可用性基础架构方面发挥着重要作用。但是，仅仅拥有一个负载均衡器并不意味着您拥有很高的系统可用性。

如果具有负载均衡器的配置仅路由流量以减少单台机器上的负载，则不会使系统具有高可用性。

通过为负载均衡器本身实现冗余，您可以将其作为单点故障消除。

如果您选择这种类型的云计算服务，那么保持高可用性是 DBaaS 提供商可以为您管理的任务之一。了解有关 数据库即服务的更多信息。

最后：实施高可用性架构

无论您经营何种规模和类型的业务，如果没有 云灾难恢复解决方案，任何类型的服务停机都可能代价高昂。

更糟糕的是，它可能会对您的声誉造成永久性损害。通过应用上面列出的一系列最佳实践，您可以降低丢失数据的风险。您还可以最大限度地减少出现生产环境问题的可能性。

如果没有高可用性系统，您离线的机会会更高。

从这个角度来看，停机成本大大超过了精心设计的 IT 基础架构的成本。近年来，托管和云计算解决方案比内部解决方案支持更受欢迎。这样做的主要原因是它 降低了 IT 成本 并增加了更多的灵活性。

无论您选择哪种解决方案，高可用性系统的好处是多方面的：

您可以节省金钱和时间，因为无需重建因存储或其他系统故障而丢失的数据。在某些情况下，中断后无法恢复您的数据。这可能会对您的业务造成灾难性的影响。

更少的停机时间意味着对用户和客户的影响更小。如果您的可用性以五个九来衡量，这意味着几乎没有服务中断。这可以提高员工的生产力并保证客户满意度。

您的应用程序和服务的性能将得到改善。

如果您因服务器问题不符合合同 SLA，您将避免罚款和处罚。