高可用性指南改进¶
https://blueprints.launchpad.net/openstack-manuals/+spec/improve-ha-guide
本指南为 OpenStack 云运维人员提供配置细节和最佳实践指南，用于构建高度可用的云环境。如果 OpenStack 要“赢得企业级市场”，这一点至关重要。本次重构将为读者提供从初始安装到采用 OpenStack 云高可用性组件之间更具逻辑性的流程。此外，它应该通过减少重复内容来降低文档团队的维护负担。我们已经准备了 高可用性指南重构的目录草案 以及包含内容的起始说明。
问题描述¶
这将是一份高可用性安装指南；关于如何管理现有高可用性环境（例如如何从故障组件中恢复）的信息超出了本项目的范围。
战略假设是
我们假设用户已经按照安装指南中的信息构建了至少一个“学习”OpenStack 环境，然后才尝试设置高可用性环境。高可用性指南应面向具有一些 OpenStack 安装经验的用户。
高可用性指南的结构应尽可能与安装指南平行。这意味着安装信息将按顺序构建，围绕 OpenStack 组件而不是高可用性策略（主动/被动 vs 主动/主动）。高级流程是
- 高可用性介绍和概念
- 硬件设置
- 在开始高可用性部署或升级之前，我们假设已就位的 инфраструктура 先决条件
- 高可用性网络：仅 neutron（非常高级，转交网络指南）
- 控制器服务的高可用性配置
- 存储服务的高可用性配置，包括对 Ceph 优势的简要讨论以及转交 Ceph 文档以获取配置细节
- 计算节点服务的高可用性配置
- 其他高可用性配置（ceilometer 与 MongoDB、heat、trove）
高可用性指南将大量引用安装指南，然后补充这些信息。例如，“按照安装指南中的说明安装和配置 xx 组件，然后执行这些额外的配置。” 这将最大限度地减少内容重复。
同样，我们预计网络指南将处理高可用性网络配置，而高可用性指南将引用该材料。
高可用性指南应强调基于开源组件的合理标准部署。我们可以根据需要提供一些关于替代方案的说明（例如，使用商业负载均衡器可能比依赖 HAProxy 更好）。
通常，高可用性指南应仅涵盖核心 OpenStack 服务。其他项目（例如 sahara 和 murano）应在其文档中涵盖高可用性配置。
高可用性指南应涵盖所有合适的 Linux 发行版/平台。
我们将尽可能重用现有高可用性指南中的材料，并进行修改以增强和更新信息。修订后的文档将以 RST 编写；现有内容将在添加到新文档时进行转换。
将尝试合并 Juno 和 Kilo 版本的材料，识别这些版本配置等方面的差异。
提议的变更¶
该指南应保留在 ha-guide 存储库中，并使用当前分配的审查人员集合。该指南应根据上述问题描述中的假设进行重写。
该源可以设置为使用 intersphinx 以支持高可用性指南和安装指南之间大量的交叉引用。如果这不可行，该指南必须使用 HTML 链接来实现相同的功能。
备选方案¶
- 保持当前结构，在主动/主动和主动/被动之间进行划分。这会将用户弄清楚应该以什么顺序执行的任务的责任放在用户身上。
- 将所有高可用性配置信息完全合并到安装指南中。这将真正使创建和维护安装指南的过程复杂化，并会破坏安装指南易于理解的目标，尤其是对于那些对 OpenStack 来说是新手，并且可能对 Linux 来说也是新手的人。
- 创建一个全面的高可用性安装指南，复制安装指南中的相关信息。这将造成维护噩梦。
- 将所有高可用性配置信息委托给各个组件的文档。这将使用户很难获得有关如何为环境实施高可用性的“大图景”。虽然我们计划在网络和许多非核心服务的文档中涵盖高可用性的细节，但我们需要一份单独的文档，详细说明如何配置主要控制器服务以实现高可用性，并为所有高可用性配置提供路线图。
实现¶
负责人¶
- 主要负责人
- mattgriffin
- 其他贡献者
- <launchpad-id 或 None>
工作项¶
根据 https://wiki.openstack.org/wiki/HAGuideImprovements/TOC 进行修订。
为 RST 创建构建和自动化，而不是 DocBook，特别是考虑到大部分内容都是新的，并且当前的主动/主动和主动/被动结构将被放弃。
与安装指南平行结构。
大量依赖网络指南场景。
依赖项¶
- 可能需要与安装指南紧密链接。请务必密切跟踪安装指南的任何蓝图改进。
测试¶
测试高可用性集群需要大量的硬件，可能还需要一个实验室。
除非另有说明，本文档根据 知识共享署名 3.0 许可协议 授权。请参阅所有 OpenStack 法律文件。