跳转到： 导航, 搜索

HAGuideImprovements/TOC

(原始文档已移动至页面底部供参考。)

建议修订

此规范参考了 https://blueprints.launchpad.net/openstack-manuals/+spec/improve-ha-guide 蓝图。

策略和假设

  1. 受众是有一些 OpenStack 安装经验的人，而不是首次用户
  2. 重点关注 OpenStack 核心服务的安装
  3. 按合理的顺序结构化指南 -- 采取的步骤
  4. 避免与安装指南的冗余；对于 HA 和非 HA 安装步骤相同的步骤，请链接到安装指南中的相应部分
  5. 一个指南适用于所有 Linux 发行版/平台
  6. 强调基于开源组件的合理标准部署。我们可以根据需要提供一些关于替代方案的说明（例如，使用商业负载均衡器可能比依赖 HAProxy 更好），并可能链接到 OpenStack Marketplace。
  7. 对于每个组件，将讨论主动/主动与主动/被动配置，而不是像当前指南那样将指南划分为 A/A 和 A/P 部分。

结构/大纲

HA 介绍和概念

冗余和故障转移

OpenStack 环境中单个节点的故障转移过程包括所有现有节点角色和已安装组件的故障转移过程。以下是每个组件或角色故障转移的基本信息。

控制器节点

通常，以下组件包含在 OpenStack 控制器节点的标准布局中

网络组件

硬件

绑定接口。

路由

配置是静态路由，没有虚拟路由器冗余协议 (VRRP) 或类似的技术用于网关故障转移。

端点 (VIP 地址)

需要描述 Linux 命名空间内的 VIP 故障转移以及预期的 SLA。

LB (HAProxy)

HAProxy 在每个控制器节点上运行，并且不同步状态。HAProxy 的每个实例将其前端配置为仅从 VIP 地址接受连接，并以负载均衡方式终止它们作为相应服务的实例列表。例如，任何 OpenStack API 服务。这使得 HAProxy 的实例独立运行，并与网络端点 (VIP 地址) 故障转移一起透明故障转移，并共享相同的 SLA。

DB (MySQL)

使用 Galera 的 MySQL 在 HAProxy 后面运行。始终配置一个活动后端和一个备份后端。由于 Galera 同步复制，因此没有从属滞后。因此，故障转移过程在 HAProxy 检测到其活动后端关闭并切换到标记为“UP”的备份后端时完成。如果没有任何后端处于活动状态（例如，如果 Galera 集群无法接受连接），则故障转移过程仅在 Galera 集群完成重新组装时完成。SLA 通常不超过 5 分钟。

AMQP (RabbitMQ)

RabbitMQ 节点在应用程序和基础设施层上都进行故障转移。应用程序层由 Oslo 消息传递配置选项控制多个 AMQP 主机。如果 AMQP 节点失败，应用程序将在指定的重新连接间隔内重新连接到配置的下一个节点。指定的重新连接间隔构成其 SLA。在基础设施层上，SLA 是 RabbitMQ 集群重新组装的时间。可能存在几种情况。当 Mnesia keeper 节点失败时，它是 RabbitMQ 相应 Pacemaker 资源的 master 时，将发生完整的 AMQP 集群停机间隔。通常，其 SLA 不超过几分钟。当另一个节点失败时，它是 RabbitMQ 相应 Pacemaker 资源的 slave 时，将不会发生任何 AMQP 集群停机。

Memcached 后端

需要描述 memcache_pool 后端如何故障转移。SLA 是几分钟。

OpenStack 无状态组件

需要参考 OpenStack HA/admin/ops 指南，描述 OpenStack 中 API 和其他无状态服务的故障转移过程。

OpenStack 有状态组件

需要参考 OpenStack HA/admin/ops 指南，描述 OpenStack 中的故障转移过程，包括 Neutron 及其代理。

存储组件

CEPH-MON

需要描述。

CEPH RADOS-GW

需要描述。

SWIFT-all

需要描述。

存储节点 (CEPH-OSD)

需要描述。

存储节点 (Cinder-LVM)

运行 cinder-volume 服务的 Cinder 节点无法故障转移。当节点失败时，其上的所有 LVM 卷都将不可用。为了使其可用，需要共享存储。

计算节点

计算节点无法故障转移。当节点失败时，在其上运行的所有实例都将不可用。为了使其可用，需要实例 HA 功能。

Mongo DB 节点

需要描述。

Zabbix 节点

需要描述。

无状态/有状态，主动/被动，主动/主动

请参阅

仲裁机制

服务应使用奇数个节点，等于或大于 3。另请参阅 https://review.openstack.org/#/c/153283/。

单控制器 HA 模式

HA 环境在配置至少三个控制器节点之前实际上并非高度可用，但它使用 Pacemaker、Corosync 和用于管理 HA 环境的其他实用程序运行。要使其高度可用，请添加两个或更多控制器节点。每个控制器集群应包括奇数个节点 -- 1 个节点、3 个节点、5 个节点等等。

存储后端

(优先级：1) 此部分包含的概念多于实际过程；我们的期望是讨论的特定技术具有自己的配置文档，可以参考这些文档。

本节描述了构成存储整体 HA 功能的数据平面（基础设施）元素；换句话说，如何确保系统发生故障时数据不会丢失。讨论的主题包括 RAID、纠删编码等，并描述它们提供的保护以及不提供的保护。

我们还将简要介绍可用的选项。最后，我们可以说明 cinder 支持多个存储提供程序（Ceph、EMC、NetApp、SolidFire 等），并且可以从存储提供程序的文档中获取更多详细信息。

Swift 结合了控制平面和数据平面，因此我们将涵盖两者的某些方面。

硬件设置

通常，HA 可以在受 Linux 内核支持的任何硬件上配置和运行。请参阅 http://www.linux-drivers.org/。

作为参考，您还可以使用 Ubuntu 支持的硬件。请参阅 http://www.ubuntu.com/certification/。

基本环境

(优先级：1)

  1. 在每个节点上安装 O/S（链接到安装指南，例如 https://docs.openstack.org/juno/install-guide/install/apt/content/ch_basic_environment.html
  2. 安装 Memcached（验证 Oslo 是否支持哈希同步；如果是，则不需要负载均衡。请参阅 https://docs.openstack.org/high-availability-guide/content/_memcached.html
  3. 在每个控制器上运行 NTP 服务器，并配置其他节点使用它们全部进行同步。链接到 https://docs.openstack.org/juno/install-guide/install/apt/content/ch_basic_environment.html#basics-ntp

基本 HA 设施

(优先级：1)

  1. 安装 pacemaker、crmsh、corosync、cluster-glue、fence-agents（仅限 Fedora）、resource-agents。（修改：https://docs.openstack.org/high-availability-guide/content/_install_packages.html）
  2. Pacemaker 的 OCF 脚本（RA）需要什么替代方案？请参阅 https://bugs.launchpad.net/openstack-manuals/+bug/1349398
  3. 设置并启动 Corosync 和 Pacemaker。坚持使用 Ubuntu/Debian 的“crm”工具和 RHEL/Fedora 的“pcs”（修改 https://docs.openstack.org/high-availability-guide/content/_set_up_corosync.html；修改：https://docs.openstack.org/high-availability-guide/content/_start_pacemaker.html）
  4. 设置基本的集群属性（修改：https://docs.openstack.org/high-availability-guide/content/_set_basic_cluster_properties.html））
  5. 配置 Pacemaker 集群的 fencing（链接到 http://clusterlabs.org/doc/）
  6. 配置 VIP（保留：https://docs.openstack.org/high-availability-guide/content/s-api-vip.html）
  7. API 服务 -- 这些属于此处还是特定部分？（修改 Glance API：https://docs.openstack.org/high-availability-guide/content/s-glance-api.html 和修改 Cinder API：https://docs.openstack.org/high-availability-guide/content/s-cinder-api.html）
  8. 调度器
  9. 控制器上的 Memcached 服务（保留：https://docs.openstack.org/high-availability-guide/content/_memcached.html，链接到 http://code.google.com/p/memcached/wiki/NewStart 获取具体信息）

安装和配置 MySQL

(优先级：2)

  1. 两个节点加上 GARBD。
  2. 使用 Galera 的 MySQL 变体：涵盖主要选项（Galera Cluster for MySQL、Percona XtraDB Cluster 和 MariaDB Galera Cluster），并链接到资源以了解安装和初始配置选项（例如，SST）。
  3. Pacemaker 多状态克隆资源用于 Galera 集群
  4. Pacemaker 资源代理用于 Galera 集群管理
  5. 由于脑裂问题，不建议使用 MySQL DRBD 配置

RabbitMQ 消息代理

(优先级：2)

RabbitMQ 团队正在创建他们自己的指南，我们将链接到该指南。本节将包含一些基本概念和配置信息，但有关详细信息和高级任务，请参考 RabbitMQ 文档。

  1. 安装并配置控制器上的消息代理；请参阅 https://docs.openstack.org/juno/install-guide/install/apt/content/ch_basic_environment.html#basics-prerequisites
  2. Oslo 消息传递用于主动/主动
  1. 我认为服务需要一些特殊的配置，超过两个节点？
  1. 不需要主动/被动 AMQP；而是使用镜像队列的两个节点主动/主动集群
  2. Pacemaker 多状态克隆资源用于 RabbitMQ 集群
  3. Pacemaker 资源代理用于 RabbitMQ 集群管理
  4. 不建议使用 DRBD 用于 RabbitMQ

Keystone 身份服务

(优先级：3，依赖于：基础设施)

  1. 安装指南中的概念：https://docs.openstack.org/juno/install-guide/install/apt/content/keystone-concepts.html
  2. 安装指南，用于配置先决条件、安装和配置组件以及完成安装：https://docs.openstack.org/juno/install-guide/install/apt/content/keystone-install.html
  3. 配置 Keystone 以使用 HA MySQL 和 HA RabbitMQ
  4. 将 Keystone 资源添加到 Pacemaker
  5. 更改 keystone.conf 中的绑定参数
  6. 配置 OpenStack 服务以使用 HA Keystone

Glance 镜像服务

(优先级：5，依赖于：swift、keystone、基础设施)

  1. 安装指南中的基础知识 (https://docs.openstack.org/juno/install-guide/install/apt/content/ch_keystone.html)
  2. 配置 Glance 以使用 HA MySQL 和 HA RabbitMQ
  3. 将 OpenStack Image API 资源添加到 Pacemaker，配置 OpenStack Image 服务 API，配置 OpenStack 服务以使用 HA Image API（修改：https://docs.openstack.org/high-availability-guide/content/s-keystone.html）
  4. 配置 OpenStack Image 服务 API (https://docs.openstack.org/high-availability-guide/content/_configure_openstack_image_service_api.html)
  5. 配置 OpenStack 服务以使用 HA Image API (https://docs.openstack.org/high-availability-guide/content/_configure_openstack_services_to_use_high_available_openstack_image_api.html)
  6. Glance 是否应使用冗余存储后端，例如 Swift 或 Ceph？

Cinder 块存储服务

cinder-api

每个控制器节点上运行一个 cinder-scheduler 实例。API 进程是无状态的，并且仅通过放置在它们前面的负载均衡器（例如 HAProxy）以主动/主动模式运行。负载均衡器会定期检查特定的 API 后端服务器是否当前可用，并将 HTTP 请求以轮询方式转发到可用的后端。例如，任何 OpenStack API 服务。这使得 HAProxy 的实例独立运行，并与网络端点 (VIP 地址) 故障转移一起透明故障转移，并共享相同的 SLA。

cinder-scheduler

每个控制器节点上运行一个 cinder-scheduler 实例。cinder-scheduler 实例以主动/主动模式工作。RPC 请求在正在运行的调度器实例之间分发。

cinder-volume (LVM 后端)

cinder-volume 服务在存储节点上运行，并且无法使用 LVM 后端以 HA 模式工作。

cinder-volume (Ceph 后端)

默认情况下，使用 Ceph 后端的 cinder-volume 服务在 Controller 节点上以 HA 模式运行。

Swift 对象存储

(优先级：4，依赖于：keystone, infrastructure)

  1. 基本安装指南
  2. 该安装指南涵盖了基本的存储节点冗余，但仅部署了一个代理服务器。我们是否需要讨论添加代理服务器和负载均衡它们的过程？另外，关于添加存储节点以及讨论区域/可用域呢？

Nova 计算服务

OpenStack Compute 由许多服务组成。HA 实现是特定于服务的。

Nova API

API 进程是无状态的，以 active/active 模式运行，并在其前面放置一个负载均衡器（例如 HAProxy）。负载均衡器会定期检查特定的 API 后端服务器是否可用，并将 HTTP 请求转发到可用的后端，采用轮询方式。API 在集群的所有 Controller 节点上启动 - 只要至少有一个 nova-api-* 实例可用，API 请求就会得到满足。

nova-scheduler

每个 Controller 节点运行一个 nova-scheduler 实例。nova-scheduler 实例以 active-active 模式工作。RPC 请求在正在运行的 scheduler 实例之间分发。

nova-conductor

如果使用，nova-conductor 实例以 active/active 模式在集群的每个 Controller 节点上运行。RPC 请求在正在运行的 Controller 实例之间分发。

nova-compute

每个 Compute 节点运行一个 nova-compute 实例。Compute 节点代表一个故障域：如果其中一个 Compute 节点发生故障，它只会影响在该特定节点上运行的虚拟机。在这种情况下，可以将受影响的虚拟机迁移到集群的其他 Compute 节点。请注意，从故障的 compute 节点迁移虚拟机不会自动执行。

nova-network

当用作 HA 的一部分时，nova-network 在集群的每个 Compute 节点上运行（所谓的 multi-host 模式）。这些节点中的每一个都必须能够访问公共网络。nova-network 为在此特定 Compute 节点上运行的虚拟机提供 DHCP/网关，因此 Compute 节点代表 nova-network 的一个故障域：其中一个 Compute 节点的故障不会影响任何其他 Compute 节点。

nova-novncproxy, nova-consoleauth, nova-objectstore

在集群的每个 Controller 节点上以 active/active 模式运行一个实例。请注意，端点需要可被云的用户访问。

可用域

请参阅 OpenStack 文档中的可用域和主机聚合。

Heat 编排

heat 服务由以下部分组成

  • 几个 API 服务：原生、与 AWS CloudFormation 兼容以及与 AWS CloudWatch 兼容。
  • heat-engine 执行实际的编排。

默认情况下，每个服务都部署在每个 controller 上，为 API（API 冗余）和 heat engine 提供水平可扩展性。

API 服务放置在 HAProxy 后面，就像其他 OpenStack API 一样。为了增加冗余度和/或扩展部署，只需添加更多的 Controller 即可。

关于 Corosync 的说明

目前，heat engine 处于 Corosync/Pacemaker 的控制之下。这是在 LP Bug 1387345 修复之前的一个代码遗留问题，当时需要 Pacemaker 控制才能手动强制运行 heat engine 的单个实例。

关于故障转移的说明

heat engine 不支持自动故障转移。如果由给定的 heat-engine 处理的堆栈发生故障并使堆栈处于 IN_PROGRESS 状态，则没有其他 heat-engine 会自动接管堆栈以进行进一步处理。如果随后（重新）启动了 heat-engine 的另一个实例，则所有处于 IN_PROGRESS 状态且未分配活动引擎的堆栈将自动置于 FAILED 状态。用户然后可以手动尝试使用相同的模板进行“恢复”更新，删除堆栈或重复堆栈操作（例如，对于非修改堆栈操作，如“检查”）。

Ceilometer 遥测和 MongoDB

可以使用 Ceilometer 和 MongoDB 作为遥测服务。MongoDB 是 Ceilometer 的默认存储后端。

Ceilometer 由以下服务组成

  • Ceilometer API - 面向现实世界的服务。它的目标是提供查询和查看收集器服务记录的数据的 API。
  • Ceilometer collector - 一种设计用于收集和记录由通知创建并由轮询代理发送的事件和计量数据的守护程序。
  • Ceilometer notification agent - 一种设计用于侦听消息队列上的通知并将它们转换为事件和样本的守护程序。
  • Ceilometer polling agents（central 和 compute）- 创建用于轮询 OpenStack 服务并构建 Meters 的守护程序。Compute agent 仅从 OpenStack 计算服务轮询数据。通过服务 API 对非计算资源进行轮询由通常在 Cloud Controller 节点上运行的 central agent 处理。
  • Ceilometer alarm services（evaluator 和 notifier）- 用于评估和使用预定义的告警规则的守护程序。

Ceilometer-api、ceilometer-agent-notification 和 ceilometer-collector 在所有 Controller 节点上运行。ceilometer-agent-compute 在每个 Compute 节点上运行并轮询其计算资源。

Ceilometer-api 服务放置在 HAProxy 后面，符合为所有 OpenStack API 设计的实践。使用轮询策略选择 ceilometer-api 服务进行请求处理。

关于 Corosync 的说明

ceilometer-agent-central 和 ceilometer-alarm-evaluator 服务由 Pacemaker 监控。集群中应该只有一个 ceilometer-agent-central，以避免来自其他以 HA 模式运行的 OpenStack 服务的样本重复。

集群中也应该只有一个正在运行的 ceilometer-alarm-evaluator 服务，因为告警评估器向 ceilometer-alarm-notifier 发送信号。

请注意，如果运行多个实例，Ceilometer 可能会发送一些激活信号并导致意外操作。

关于故障转移的说明

Ceilometer 故障不会影响其他服务的性能，除了使用 Ceilometer 告警组件的服务（例如 Heat）。

所有其他服务仅影响 Ceilometer 米表收集。损坏的 ceilometer-collector 不会从 AMQP 队列轮询数据，也不会将数据保存到存储后端（HA 模式下的 MongoDB）。因此，AMQP 后端的 notification.info 队列可能会被发布但未收集的消息阻塞。通知代理和轮询代理故障会导致无法获取通知和轮询米表。Ceilometer API 故障会破坏告警流程和 API 本身的工作。

数据库服务 (Trove)

(优先级 9：依赖于：neutron, nova, glance, keystone, infrastructure)

  1. 基本安装指南
  2. 需要有关如何应用 HA 的详细信息

Sahara

(优先级 9：依赖于：neutron, nova, glance, keystone, infrastructure)

  1. 基本安装指南 (https://docs.openstack.org/juno/install-guide/install/apt/content/ch_sahara.html )
  2. 应该链接到 Sahara 文档，讨论 OpenStack HA 与 Hadoop HA 以及它们如何协同工作，尽管在 https://docs.openstack.org/developer/sahara/userdoc/installation.guide.html 处的安装说明目前没有提及 HA

其他

  1. 配置 Pacemaker 服务组，以确保 VIP 链接到 API 服务资源
  2. 用于 Pacemaker RA 的 Systemd 替代 OCF 脚本
  3. MariaDB/Percona 与 Galera 替代 MySQL
  4. 安装并配置 HAProxy 用于 API 服务和带有 Galera 集群的 MySQL 负载均衡
  5. 提及冗余硬件负载均衡器对于无状态服务（如 REST API）的价值
  6. 描述将单个节点扩展到 3 个节点 HA
  7. Ceph？
  8. Murano？

原始版本供参考

注意：这是我们开始修改的基础版本。

I. OpenStack 高可用性简介

  1. 无状态与有状态服务
  2. 主动/被动
  3. 主动/主动

II. 使用主动/被动实现 HA

1. Pacemaker 集群堆栈

  1. 安装软件包
  2. 设置 Corosync
  3. 启动 Corosync
  4. 启动 Pacemaker
  5. 设置基本集群属性

2. 云控制器集群堆栈

  1. 高可用性 MySQL
  2. 高可用性 RabbitMQ

3. API 节点集群堆栈

  1. 配置 VIP
  2. 高可用性 OpenStack Identity
  3. 高可用性 OpenStack Image API
  4. 高可用性 Cinder API
  5. 高可用性 OpenStack Networking Server
  6. 高可用性 Ceilometer Central Agent
  7. 配置 Pacemaker 组

4. 网络控制器集群堆栈

  1. 高可用性 Neutron L3 Agent
  2. 高可用性 Neutron DHCP Agent
  3. 高可用性 Neutron Metadata Agent
  4. 管理网络资源

III. 使用主动/主动实现 HA

5. 数据库

  1. MySQL with Galera
  2. Galera 监控脚本
  3. 提供高可用性数据库的其他方法

6. RabbitMQ

  1. 安装 RabbitMQ
  2. 配置 RabbitMQ
  3. 配置 OpenStack 服务以使用 RabbitMQ

7. HAproxy 节点 8. OpenStack Controller 节点

  1. 运行 OpenStack API 和调度器
  2. Memcached

9. OpenStack 网络节点

  1. 运行 Neutron DHCP Agent
  2. 运行 Neutron L3 Agent
  3. 运行 Neutron Metadata Agent
检索自 "https://wiki.openstack.org/w/index.php?title=HAGuideImprovements/TOC&oldid=81606"