操作需求¶
本节描述了影响 OpenStack 云设计的操作因素。
网络设计¶
OpenStack 集群的网络设计包括关于集群内部互连需求、允许客户端访问其资源以及操作员管理集群的访问需求的决策。您应该考虑这些网络的带宽、延迟和可靠性。
考虑关于监控和告警的其他设计决策。如果您使用的是外部提供商，服务级别协议 (SLA) 通常在您的合同中定义。带宽、延迟和抖动等操作因素可以包含在 SLA 中。
随着网络资源需求的增加，请确保您的网络设计能够适应扩展和升级。操作员会添加额外的 IP 地址块并增加额外的带宽容量。此外，请考虑管理硬件和软件生命周期事件，例如升级、退役和中断，同时避免对租户造成服务中断。
在整体网络设计中考虑可维护性。这包括管理和维护 IP 地址的能力，以及对覆盖标识符的使用，包括 VLAN 标签 ID、GRE 隧道 ID 和 MPLS 标签。例如，如果您可能需要更改网络上的所有 IP 地址，这是一种称为重新编号的过程，那么设计必须支持此功能。
在考虑某些操作现实时，解决网络重点应用。例如，考虑 IPv4 地址即将耗尽、迁移到 IPv6 以及使用私有网络来隔离应用程序接收或生成的不同类型的流量。在 IPv4 到 IPv6 的迁移中，应用程序应遵循存储 IP 地址的最佳实践。我们建议您避免依赖于未移植到 IPv6 协议或实现方式不同的 IPv4 功能。
为了隔离流量，允许应用程序为数据库和存储网络流量创建私有租户网络。为需要从 Internet 直接访问客户端的服务使用公共网络。在隔离流量后，请考虑 服务质量 (QoS) 和安全性，以确保每个网络具有所需的的服务级别。
还要考虑网络流量的路由。对于某些应用程序，开发一个用于路由的复杂策略框架。为了创建满足业务需求的路由策略，除了带宽、延迟和抖动要求外，还要考虑通过昂贵的链路传输流量与通过更便宜的链路传输流量的经济成本。
最后，考虑如何响应网络事件。在故障场景中，从一个链路到另一个链路的负载转移可能是一个设计因素。如果您没有正确规划网络容量，故障转移流量可能会使其他端口或网络链路不堪重负，并创建一个级联故障场景。在这种情况下，故障转移到某个链路的流量会使该链路不堪重负，然后转移到后续链路，直到所有网络流量停止。
SLA 考虑因素¶
服务级别协议 (SLA) 定义了将影响 OpenStack 云设计的可用性级别，以提供冗余和高可用性。
影响设计的 SLA 条款包括
API 可用性保证，这意味着多个基础设施服务和高度可用的负载均衡器。
网络正常运行时间保证，影响交换机设计，可能需要冗余交换和电源。
网络安全策略要求。
在任何大于几个主机的环境中，有两个领域可能受 SLA 约束
数据平面 - 提供虚拟化、网络和存储的服务。客户通常要求这些服务持续可用。
控制平面 - 辅助服务，例如 API 端点和控制 CRUD 操作的服务。此类别中的服务通常受不同的 SLA 预期约束，并且可能更适合在与数据平面服务分离的硬件或容器上运行。
为了有效地运行云安装，初始停机计划包括创建支持计划维护和计划外系统故障的流程和架构。
重要的是，在 SLA 协商中确定负责监控和启动计算服务实例（如果发生中断）的责任方。
升级、修补和更改配置项可能需要某些服务的停机时间。停止构成控制平面的服务可能不会影响数据平面。可能需要实时迁移计算实例才能对需要数据平面组件停机时间的操作执行任何操作。
许多服务超出了纯 OpenStack 代码的范围，这会影响云设计满足 SLA 的能力，包括
数据库服务，例如
MySQL或PostgreSQL。提供 RPC 的服务，例如
RabbitMQ。外部网络连接。
物理限制，例如电源、机架空间、网络布线等。
共享存储，包括基于 SAN 的阵列、存储集群，例如
Ceph，和/或 NFS 服务。
根据设计，某些网络服务功能可能同时属于控制平面和数据平面类别。例如，neutron L3 Agent 服务可能被视为控制平面组件，但路由器本身将是数据平面组件。
在具有多个区域的设计中，SLA 还应考虑共享服务的使用，例如身份服务和仪表板。
任何 SLA 协商还必须考虑到对设计的关键方面依赖第三方。例如，如果组件（例如存储系统）存在 SLA，则 SLA 必须考虑到此限制。如果云所需的 SLA 超过云组件商定的正常运行时间水平，则需要额外的冗余。这在涉及多个第三方的情况下，在混合云设计中至关重要。
支持和维护¶
操作人员支持、管理和维护 OpenStack 环境。他们的技能可能因安装的规模和目的而异而专业化或多样化。
操作员的维护功能应予以考虑
- 维护任务
操作系统修补、硬件/固件升级以及与数据中心相关的更改，以及 OpenStack 组件的次要和发布升级都是持续的操作任务。OpenStack 项目的六个月发布周期需要作为持续维护成本的一部分来考虑。该解决方案应考虑存储和网络维护以及对底层工作负载的影响。
- 可靠性和可用性
可靠性和可用性取决于许多支持组件的可用性以及服务提供商采取的预防措施。这包括网络、存储系统、数据中心和操作系统。
有关管理和维护 OpenStack 环境的更多信息，请参阅 OpenStack 操作指南。
日志记录和监控¶
OpenStack 云需要适当的监控平台来识别和管理错误。
注意
我们建议利用现有的监控系统，以查看它们是否能够有效地监控 OpenStack 环境。
需要捕获的关键指标包括
镜像磁盘利用率
对计算 API 的响应时间
日志记录和监控对于多站点 OpenStack 云没有显着差异。操作指南中的 日志记录和监控 仍然适用。日志记录和监控可以基于每个站点提供，也可以在公共集中位置提供。
尝试将日志记录和监控设施部署到集中位置时，必须注意放置在站点间网络链接上的负载
管理软件¶
提供集群、日志记录、监控和警报细节的云环境管理软件通常被使用。这会影响并影响整体 OpenStack 云设计，并且必须考虑额外的资源消耗，例如 CPU、RAM、存储和网络带宽。
诸如 Corosync 或 Pacemaker 之类的集群软件的包含主要由云基础设施的可用性和支持部署后配置的复杂性决定。 OpenStack 高可用性指南 提供了有关 Corosync 和 Pacemaker 的安装和配置的更多详细信息，如果需要在设计中包含这些软件包，则可以参考。
其他潜在的设计影响包括
- OS-hypervisor 组合
确保所选的日志记录、监控或警报工具支持建议的 OS-hypervisor 组合。
- 网络硬件
网络硬件选择需要得到日志记录、监控和警报软件的支持。
数据库软件¶
大多数 OpenStack 组件需要访问后端数据库服务来存储状态和配置信息。选择一个合适的后端数据库，以满足 OpenStack 服务的可用性和容错要求。
MySQL 是 OpenStack 的默认数据库，但其他兼容的数据库可用。
注意
Telemetry 使用 MongoDB。
所选的高可用性数据库解决方案根据所选数据库而变化。例如，MySQL 提供了几个选项。使用诸如 Galera 之类的复制技术进行主动-主动集群。对于主动-被动使用某种形式的共享存储。这些潜在的解决方案都会对设计产生影响
采用 Galera/MariaDB 的解决方案至少需要三个 MySQL 节点。
MongoDB 具有自己的高可用性设计考虑因素。
OpenStack 设计通常不包括共享存储。但是，对于某些高可用性设计，某些组件可能需要它，具体取决于特定的实现。
操作员访问系统¶
云操作系统托管在云环境中的趋势越来越明显。操作员需要访问这些系统才能解决重大事件。
确保网络结构将所有云连接起来，形成一个集成系统。还要考虑状态转换，这些状态转换必须可靠且延迟最小，才能实现系统的最佳性能。
如果云的很大一部分位于外部管理的系统上，请为可能无法进行更改的情况做好准备。此外，云提供商可能在基础设施必须如何管理和暴露方面有所不同。这可能导致根本原因分析的延迟，因为提供商坚持认为责任在于其他提供商。
