OpenStack 系列（架构篇 2）- 运维需求

发表于

本篇博文翻译自 OpenStack 官网 ^1

以下内容描述运维因素如何影响 OpenStack 云平台设计。

网络设计

​ 对于集群式 OpenStack 的网络设计需考虑集群内互联需求、客户访问他们的云上资源需求、运维管理集群访问需求。并且还需要考虑这些网络的带宽、延迟以及可靠性。

​ 额外还需考虑监控、告警。如果你在采用外部供应商的，需要在你的对照列表定义 SLA，包括运维因素如带宽、延迟、抖动等。

​ 网络资源是需求增长型的，确保网络设计能满足扩张和升级。例如，运维人员新增 IP 地址块，扩大带宽容量。另外，还需要考虑纳管软硬件的生命周期事件，比如升级、退役、中断。做到云平台服务中断不影响相关的租户。

​ 运维方面的考虑需要贯穿整个网络设计过程，包括管理和维护 IP 地址集以及 VLAN 标签 ID、GRE 隧道 ID 和 MPLS 标签。比如，如果需要变更整个网络的 IP 地址，其中一环重排号，网络设计就一定要支持该功能。

​ 当考虑明确的运维因素，网络侧需着重考虑地址使用状况。例如，需考虑到隐性的 IPv4 地址耗尽、迁移至 IPv6 以及使用私有网络来隔离应用接收或产生的不同种类流量。在 IPv4 迁移至 IPv6 时，应用应当参考 IP 地址存储的最佳实践。我们建议尽量避免强依赖于 IPv4 特性而无法迁移至 IPv6 协议，或在两者间实现出现偏差。

​ 为隔离流量，需运维应用为数据库和存储网络流量，分别创建各自的租户网络。为服务启用公共网络，需能支持客户端直接来自互联网的访问。在隔离流量之外，还需考虑服务质量和安全性，以确保每个网络都满足各自的服务要求。

​ 同时，也需考虑网络流量路由表。对于某些应用，需为路由开发复杂的策略框架。为创建路由策略满足业务需求，也需考虑传输流量的经济成本，昂贵的链路 VS 更便宜的链路，还有额外的带宽、延迟、抖动等。

​ 最后，要考虑网络事件如何响应。设计中需考虑到传输负载迁移过程，遇上失败的场景。一旦没有正确规划网络容量，容错流量可能会加重其它的端口或网络链路，导致关联性失败场景出现。这种情况，迁移容错流量到其他链路，链路过载即需继续迁移到更适宜的链路上，直到整张网络不可用为止。

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，就需要考虑到它的有限性。如果云平台需要提供超过这些组件的等级承诺，那将需考虑额外的冗余性。这些因素将是混合云平台的要点，且涵盖了各种第三方依赖。

支持和维护

​ 运维人员需对 OpenStack 云平台环境提供支持、管理及维护工作。他们所需技能会依据平台的大小和部署目的不同而有所区别。

​ 运维人员维护功能需考虑以下方面：

维护工作表

​ 操作系统打补丁、硬件/固件升级、数据中心关联的变更、以及 OpenStack 组件小版本升级，都是持续的运维工作。OpenStack 项目每六个月的发布周期，同样要考虑到这持续的维护成本。总的方案也得考虑到存储和网络方面的维护，以及底层负载的潜在影响。

可靠性和可用性

​ 可靠性和可用性依赖于大多少组件的可用性和服务提供商的服务级别。总的需覆盖网络、存储系统、数据中心和操作系统。

关于更多维护 OpenStack 云平台环境可参考 官方运维指引。

日志和监控

​ OpenStack 云平台需要准确的监控平台来识别和管理错误。

​ 核心的指标包括：

  • 镜像磁盘使用率
  • 计算 API 响应耗时

​ 日志和监控并不能有效地区别多站点 OpenStack 云平台。这些工具在运维指引日志和监控小节有更多描述。日志和监控是每个站点的基础部件，处于公共中心化位置。

​ 当尝试部署日志和监控组件到中心化位置时，一定要认真考虑到内部网络链路负载情况。

管理软件

​ 管理软件包括集群、日志、监控和告警系统，这些都是云平台常用的。这些也同样影响到整个 OpenStack 云平台的设计，一定要考虑统计到额外的资源占用，比如 CPU、RAM、存储和网络带宽。

​ 集群管理软件，如 Corosync 或 Pacemaker，主要用于云基础设施构建高可用性，部署所需配置的复杂度也很高。官方高可用指引 提供了更多关于安装和 Corosync 和 Pacemaker 的细节，设计时需考虑到这些软件的打包。

​ 潜在受影响设计因素有：

  • OS-hypervisor 集成

    确保日志、监控、告警工具选型能支持到 OS-hypervisor 集成

  • 网络硬件

    网络硬件选型同样要能支持日志、监控、和告警集成

数据库

​ 大部分 OpenStack 组件都需要访问后端数据库服务，来存储状态和配置信息。选择一款合适的后端数据库，要能支持 OpenStack 服务列表的可用性和容错。

​ MySQL 是 OpenStack 默认数据库，其它兼容的数据库同样可用。

​ 数据库的高可用方案会根据选型而有所不同。MySQL 有多种方案，可用复制技术如 Galera 来支持主主模式集群；主备模式可用各种共享存储。各种潜在的方案都会有所影响到设计：

  • 采用 Galera/MariaDB 需要至少三个 MySQL 节点。
  • MongoDB 有它独自的高可用方式。
  • OpenStack 的设计，通常并不需要共享存储。但是，为了高可用设计，部分组件需要依实际情况而定。

运维人员访问系统

​ 云管系统一种趋势，将它们部署到云平台内部。运维人员需要能访问他们来解决重大故障。

​ 对于一个集成性的系统，需确保网络结构能打通所有的云平台。同样，需认真考虑到这些系统实际性能和可靠度，以及更低的响应延迟。

​ 云平台持续演进，包括外部所纳管的系统，即使提前做好准备，也不太可用做到没有变更。另外，各大云供应商提供的基础设施和暴露的都会不一样。这会导致各故障提供的根因分析报告都会有所不同。