高可用性¶
数据平面和控制平面¶
在设计 OpenStack 云时，重要的是要考虑由 服务级别协议 (SLA) 规定的需求。这包括维护正在运行的计算服务实例、网络、存储以及运行在这些资源之上的其他服务的可用性所需的关键服务。这些服务通常被称为数据平面服务，通常预计始终可用。
剩余的服务，负责创建、读取、更新和删除 (CRUD) 操作、计量、监控等，通常被称为控制平面。SLA 可能规定这些服务的较低正常运行时间要求。
构成 OpenStack 云的服务具有许多您需要了解的要求，以便能够满足 SLA 条款。例如，为了为计算服务提供最少量的存储，需要消息队列和数据库服务以及它们之间的网络连接。
如果数据平面和控制平面系统之间存在逻辑和物理分离，则可以简化持续维护操作。然后，例如，可以在不影响客户的情况下重启控制器。如果一项服务故障影响整个服务器的运行（吵闹的 邻居），控制平面和数据平面之间的分离可以实现快速维护，对客户运营的影响有限。
消除每个站点内的单点故障¶
OpenStack 适合以高度可用的方式部署，预计至少使用 2 台服务器。这些服务器可以运行所有相关服务，例如消息队列服务，例如 RabbitMQ 或 QPID，以及适当部署的数据库服务，例如 MySQL 或 MariaDB。随着云中服务的扩展，后端服务也需要扩展。监控和报告服务器利用率和响应时间，以及对系统进行负载测试，将有助于确定扩展决策。
OpenStack 服务本身应部署在多台服务器上，这些服务器不代表单点故障。可以通过将这些服务置于具有多个 OpenStack 服务器作为成员的高可用负载均衡器后面来实现可用性。
有少量 OpenStack 服务旨在一次只能在一个地方运行（例如，ceilometer-agent-central 服务）。为了防止这些服务成为单点故障，可以使用集群软件（例如 Pacemaker）来控制它们。
在 OpenStack 中，基础设施对于提供服务至关重要，应始终可用，尤其是在使用 SLA 时。确保网络可用性是通过设计网络架构来实现的，以便不存在任何单点故障。交换机数量、路由和电源冗余以及网络绑定以提供多样化的路由到高度可用的交换机基础设施，都应计入核心基础设施。
在决定网络功能时必须小心。目前，OpenStack 支持传统的网络 (nova-network) 系统和更新的、可扩展的 OpenStack Networking (neutron)。OpenStack Networking 和传统网络都有各自的优点和缺点。它们都是有效的受支持选项，适用于 OpenStack 运维指南 中描述的不同网络部署模型。
在使用 Networking 服务时，OpenStack 控制器服务器或单独的 Networking 主机处理路由，除非选择了动态虚拟路由器的路由模式。将路由直接运行在控制器服务器上会混合数据平面和控制平面，并可能导致性能和故障排除方面出现复杂问题。可以使用第三方软件和外部设备来帮助维护高度可用的三层路由。这样做允许常见的应用程序端点控制网络硬件，或以安全的方式提供复杂的多层 Web 应用程序。也可以完全从 Networking 中删除路由，而是依赖于硬件路由功能。在这种情况下，交换机基础设施必须支持三层路由。
应用程序设计也必须考虑底层云基础设施的功能。如果计算主机不提供无缝的实时迁移功能，那么必须预计如果计算主机发生故障，该实例和任何本地于该实例的数据将被删除。但是，当向用户提供实例具有高水平的正常运行时间保证的期望时，必须以一种消除计算主机消失时任何单点故障的方式部署基础设施。这可能包括使用企业存储上的共享文件系统或 OpenStack 块存储来提供与服务功能相匹配的保证级别。
如果使用包含对集中存储的共享访问权的存储设计，请确保该设计也没有单点故障，并且该解决方案的 SLA 与或超过数据平面的预期 SLA。
消除多区域设计中的单点故障¶
一些服务通常在多个区域之间共享，包括身份服务和仪表板。在这种情况下，必须确保支持这些服务的数据库已复制，并且在失去单个区域的情况下，可以维护对每个站点多个工作者的访问。
应在站点之间部署多个网络链接，以提供所有组件的冗余。这包括存储复制，存储复制应隔离到专用网络或 VLAN，并能够分配 QoS 以控制复制流量或为该流量提供优先级。
注意
如果数据存储变化很大，网络要求可能会对维护站点运营成本产生重大影响。
如果设计包含多个站点，则在两个站点中维护对象可用性的能力对对象存储设计和实施具有重大影响。它也会对站点之间的 WAN 网络设计产生重大影响。
如果运行的云中的应用程序不了解云，则应有明确的措施和期望来定义基础设施可以和不能支持的内容。一个例子是在站点之间共享存储。这是可能的，但是这种解决方案并非 OpenStack 原生，需要第三方硬件供应商来满足这种要求。另一个例子可以在能够直接消耗对象存储中资源的应用程序中看到。
连接两个以上的站点会增加挑战并为设计考虑因素增加复杂性。多站点实施需要规划以解决内部和外部连接所使用的其他拓扑。一些选项包括全网状拓扑、集线器端口、脊叶和 3D Torus。
有关 OpenStack 中高可用性的更多信息，请参阅 OpenStack 高可用性指南。
站点丢失和恢复¶
停机会导致部分或完全丢失站点功能。应实施策略来了解和规划恢复场景。
部署的应用程序需要继续运行，更重要的是，您必须考虑如果站点不可用，它对应用程序的性能和可靠性的影响。
重要的是要了解当站点关闭时，站点之间对象和数据的复制会发生什么。如果这导致队列开始堆积，请考虑这些队列可以安全存在多长时间，直到发生错误。
停机后，确保站点在重新上线时恢复运营。我们建议您设计恢复以避免竞争条件。
复制站点间数据¶
传统上，复制一直是保护对象存储实施的最佳方法。存储架构中存在各种复制方法，例如同步和异步镜像。大多数对象存储和后端存储系统在存储子系统层实现用于复制的方法。对象存储还会根据云的需求定制复制技术。
组织必须在数据完整性和数据可用性之间找到正确的平衡。复制策略也可能影响灾难恢复方法。
跨不同的机架、数据中心和地理区域进行复制会增加对确定和确保数据位置的关注。对于应用程序的良好性能，保证数据是从最近或最快的存储访问的可能是必要的。
注意
在使用嵌入式对象存储方法时，请确保不要发起额外的复制，因为这可能会导致性能问题。
