关键概念¶
冗余和故障转移¶
高可用性通过冗余硬件运行每个服务的冗余实例来实现。如果运行某个服务的一个硬件组件发生故障，系统可以故障转移到使用在未发生故障的硬件上运行的该服务的另一个实例。
高可用性的关键方面是消除单点故障 (SPOF)。SPOF 是单个设备或软件，如果发生故障会导致系统停机或数据丢失。为了消除 SPOF，请检查是否存在以下冗余机制：
网络组件，例如交换机和路由器
应用程序和自动服务迁移
存储组件
设施服务，例如电力、空调和消防保护
如果某个组件发生故障并且备份系统必须承担其负载，大多数高可用性系统会尽快更换故障组件以保持必要的冗余。这样可以最大限度地减少在降级保护状态下花费的时间。
大多数高可用性系统在发生多个独立（非连锁）故障时会发生故障。在这种情况下，大多数实现倾向于保护数据而不是维持可用性。
高可用性系统通常实现 99.99% 或更高的正常运行时间百分比，大致相当于每年少于一小时的累计停机时间。为了实现这一点，高可用性系统应将故障后的恢复时间保持在约一到两分钟，有时甚至更短。
OpenStack 目前满足其自身基础设施服务对此类可用性要求，这意味着 OpenStack 基础设施本身可以实现 99.99% 的正常运行时间。但是，OpenStack 不保证单个客户实例的 99.99% 可用性。
本文档讨论了一些实现高可用性系统的常见方法，重点是核心 OpenStack 服务以及与 OpenStack 紧密相关的其他开源服务。
您需要解决在 OpenStack 环境中运行的任何应用程序软件的高可用性问题。重要的是要确保您的服务是冗余且可用的。如何实现这一点由您决定。
主动/被动与主动/主动¶
有状态服务可以配置为主动/被动或主动/主动，定义如下：
- 主动/被动配置
维护一个冗余实例，可以在主动服务发生故障时启动。例如，OpenStack 将写入主数据库，同时维护一个灾难恢复数据库，如果主数据库发生故障，则可以启动该数据库。
有状态服务的主动/被动安装通常维护一个可替换的资源，在需要时可以启动。请求使用 虚拟 IP 地址 (VIP) 处理，该地址有助于在最少重新配置的情况下恢复服务。一个单独的应用程序（例如 Pacemaker 或 Corosync）监控这些服务，并在必要时启动备份。
- 主动/主动配置
每个服务也有一个备份，但同时管理主系统和冗余系统。这样，如果发生故障，用户可能不会注意到。备份系统已经在线，并在主系统修复并恢复在线时承担增加的负载。
通常，无状态服务的主动/主动安装维护一个冗余实例，并且请求使用虚拟 IP 地址和负载均衡器（例如 HAProxy）进行负载均衡。
有状态服务的主动/主动安装通常包括冗余服务，所有实例都具有相同状态。换句话说，对数据库的一个实例的更新会更新所有其他实例。这样，对一个实例的请求与对任何其他实例的请求相同。负载均衡器管理到这些系统的流量，确保始终由运行中的系统处理请求。
集群和仲裁¶
仲裁指定在冗余节点集群中必须正常运行的最小节点数，才能使集群保持正常运行。当一个节点发生故障并且故障转移将控制权转移到其他节点时，系统必须确保数据和流程保持正常。为了确定这一点，将比较剩余节点的内容，如果存在差异，则实施多数规则算法。
因此，高可用性环境中的每个集群都应具有奇数个节点，并且仲裁定义为超过节点的一半。如果多个节点发生故障，导致集群大小降至低于仲裁值，则集群本身将发生故障。
例如，在七节点集群中，仲裁应设置为 floor(7/2) + 1 == 4。如果仲裁为四，并且四个节点同时发生故障，则集群本身将发生故障，而如果不超过三个节点发生故障，则将继续运行。如果拆分为三个和四个节点的派对，则具有四个节点仲裁的派对将继续运行多数派，并停止或隔离少数派（具体取决于集群配置中的无仲裁策略）。
仲裁也可以设置为三，仅作为配置示例。
注意
我们不建议将仲裁设置为小于 floor(n/2) + 1 的值，因为它可能会在网络分区的情况下导致脑裂。
当四个节点同时发生故障时，集群将继续运行。但是，如果拆分为三个和四个节点的派对，则具有三个仲裁的派对将使双方都尝试隔离对方并托管资源。如果未启用隔离，它将直接运行每个资源的两个副本。
这就是为什么将仲裁设置为小于 floor(n/2) + 1 的值很危险。但是，在某些特定情况下，例如在 100% 确定其他节点已关闭的时间点，可能需要这样做。
在配置 OpenStack 环境用于学习或演示目的时，可以关闭仲裁检查。生产系统应始终启用仲裁运行。
