理解 OpenStack 高可用（1）：OpenStack 高可用和灾备方案（下）

理解 OpenStack 高可用（1）：OpenStack 高可用和灾备方案（上）这篇文章介绍了OpenStack高可用的基础知识，本文将详细介绍补分OpenStack提供者的详细HA方案。

3. 部分 OpenStack 方案提供者的 HA 方案

3.1 RDO HA

这里 有完整的 RDO HA 部署方案：

该配置最少需要五台机器：

1. 一台（物理或者虚拟）服务器部署 nfs server，dhcp，dns
2. 一台物理服务器来作为计算节点
3. 三台物理服务器组成 pacemaker 集群，创建多个虚机，安装各种应用

特征：

• 每个集群使用三个节点，全部采用 A/A 模式，除了 cinder-volume 和 LBaas。RedHat 不认为 A/P 模式是真正的 HA。
• 提供使用 Pacemaker 或者 Keepalived 两套方案。
• 将 API 和内部无状态组件按功能组分布到各个专有集群，而不是放在一个集群上。
• Cinder 这里标识为 A/A HA，但是不包括 cinder-volume。
• 计算节点 HA 使用 2.4 部分描述的 HA 方式。

Service	Process	Mode	HA stragegy
Support services	MariaDB - Galera	A/A	HAProxy / app cluster
Support services	RabbitMQ	A/A	App cluster / service config
Support services	HAProxy	A/A	Keepalived
Support services	MongoDB	A/A	App cluster （ceilometer 和 heat 会使用）
Support services	Memcached	A/A	Service configuration
Keystone	openstack-keystone	A/A	HAProxy
Glance	openstack-glance-api	A/A	HAProxy
Glance	openstack-glance-registry	A/A	HAProxy （向 glance-api 提供 REST API）
Nova	openstack-nova-api	A/A	HAProxy
Nova	openstack-nova-cert	A/A
Nova	openstack-nova-compute	A/A	参见 2.4 部分描述
Nova	openstack-nova-scheduler	A/A
Nova	openstack-nova-conductor	A/A
Nova	openstack-nova-novncproxy	A/A	HAProxy
Cinder	openstack-cinder-api	A/A	HAProxy
Cinder	openstack-cinder-scheduler	A/A
Cinder	openstack-cinder-volume	A/P	No HA （RH 不把 A/P HA 当作HA！）。参考这里
Cinder	openstack-cinder-backup	A/A
Neutron	neutron-server	A/A	HAProxy
Neutron	neutron-dhcp-agent	A/A	Multiple DHCP agents
Neutron	neutron-l3-agent	A/A	L3 HA
Neutron	neutron-metadata-agent	A/A
Neutron	neutron-lbaas-agent	A/P	目前的设计不允许 A/A
Neutron	neutron-openvswitch-agent	A/A
Neutron	neutron-metering-agent	A/A
Horizon	httpd	A/A	HAProxy
Ceilometer	openstack-ceilometer-api	A/A	HAProxy
Ceilometer	openstack-ceilometer-central	A/A	Workload partitioning: tooz + Redis
Ceilometer	openstack-ceilometer-compute	A/A
Ceilometer	openstack-ceilometer-alarm-notifier	A/A
Ceilometer	openstack-ceilometer-evaluator	A/A
Ceilometer	openstack-ceilometer-notification	A/A
Heat	openstack-heat-api	A/A	HAProxy

关于 MariaDB：

• 它是数据库管理系统 MySQL 的一个分支，主要由开源社区在维护，采用 GPL 授权许可。开发这个分支的原因之一是：甲骨文公司收购了 MySQL 后，有将 MySQL 闭源的潜在风险，因此社区采用分支的方式来避开这个风险。
• MariaDB 的目的是完全兼容MySQL，包括 API 和命令行，使之能轻松成为 MySQL 的代替品。除了作为一个Mysql的“向下替代品”，MariaDB包括的一些新特性使它优于MySQL。这篇文章 有 Mysql 和 MariaDB 对比分析。

不由得赞一下 RDO 的文档！想起来之前去拜访一个 OpenStack 初创公司，CTO 说他们基本上是参考 RDO 做方案，看起来是很有道理的。

3.2 Mirantis OpenStack 6.0 HA 方案：A/A 方案

Mirantis 推荐在生产环境中使用带至少三个控制节点的 HA：

其中：

• 使用 Pacemaker 控制 Neutron Agent，实现 A/P HA
• API 服务运行在多个节点上，使用 HAProxy 实现负载均衡，提供 VIP
• RabbitMQ A/A
• Mysql A/A

各 HA 组件之间的关系：

各组件被调用的方式：

点评：与 RDO 方案一样，该 HA 也是一个彻底的 HA 方案，消除了整个系统的 SPOF。但是，与 RDO 相比分散式控制节点相比，Mirantis 的集中式控制节点上运行的服务较多，可能会影响其性能，但是在小规模云环境中节省了硬件成本。

3.3 HP Helion 的 HA 方案：A/A方案

系统组成：（两节点 HAProxy + Keepalived 集群） + 第三个控制节点 +（RabbitMQ Cluster + Queue 镜像）+（Galera + Mysql）

1. OpenStack 客户端通过 VIP:8774 访问 nova-api
2. HAProxy 将请求转到 controller 0 上的 nova-api
3. nova-api 通过 VIP：3306 访问 Mysql DB
4. HAProxy 将请求转到 controller 1 上的 Mysql 实例

点评：HP 的 A/A 方案是不彻底的，甚至是有些怪异（为什么不三个控制节点做一个A/A 集群呢？），因为至少 Horizon、 Ceilomter 和 Neutron Agents 没有实现 HA，它只实现了 API，DB 和 MQ 的 HA。

3.4 TCP Cloud OpenStack HA

特征：

• 系统组成：Pacemaker, Corosync, HAProxy, Galera + IBM 硬件比如 Storwize V7000
• 使用三阶段集群 A/A 集群
• 提供 99.99% 的服务可靠性
• 没看到虚机 HA

来源：TCP 官网

3.5 Paypal OpenStack 生产系统 HA

特征：

• 使用硬件负载均衡 F5
• 使用商业 SDN
• 使用 Monit 监控和重启各服务
• 使用 Pacemaker
• 用在生成系统，优化进行中

3.6 Oracel OpenStack HA：A/P HA

CRM：Oracel Clusterware（Oracle Grid Infrastructure Release 12c Release 1 or later）

组成：两个控制节点 + 两个网络节点组成的集群。除了网络节点上的组件外，别的组件都部署在控制节点上。

结论：该方案比不上前面几个公司的方案，因为：

• 只提供两节点 A/P 方案，可靠性和 CTO 比不上三节点方案
• 需要使用共享存储比如 NFS 来实现 A/P HA 模式的 DB 和 MQ，容易脑裂
• 不使用免费的 Pacemaker，部署成本增加。

3.7 网易 OpenStack 云的 HA 方案

好不容易找到一个国内公司的方案，来源在 这里：

特征：

• 使用 keepalived 管理的 HAProxy
• 控制节点应该是 A/A HA 方案
• 没有看到计算节点和网络控制节点的 HA 方案，似乎没有用 neutron，而是用 nova-network

• 高可用 RabbitMQ 集群和主备 MySQL，以及 memcache 集群是额外部署的

  3.5 小结

• RDO > Mirantis > HP >> Oracel

• HA 是生产环境中的部署必须有的
• HA 模式方面，A/A HA 方案为主流
• 数据库方面，Mysql Galera 为主流
• MQ 方面，RabbitMQ 集群 + 镜像消息队列为主流
• CRM 方面，Pacemaker 三节点集群是主流
• 负载均衡方面，HAProxy 是主流
• 网络方面，Neutron 新的 HA 方案包括 VRRP 和 DVR 还未成熟，尚未真正进入生产环境
• 存储方面，OpenStack 需要解决 cinder-volume 的 A/A 实现
• 计算方面，OpenStack 需要原生的虚机 HA 实现

4. OpenStack DR

目前，OpenStack 上没有实现 DR。 IBM 和 RedHat 联合发起的 DRaas 提议:

状态：

• 目前没有详细的方案，只有一个概要设计，还处于 Gap 识别和补齐阶段。
• 具体的实现主要集中在cinder 侧元数据（Juno IBM 实现了部分的 Volume Replication 功能）、业务数据同步相关，但是目前进展不乐观。

可以参考 RedHat 的更多文档，包括 Preparing for the Worst Case Scenario: A Vision for OpenStack Disaster Recovery 和 Disaster Recovery Enablement in OpenStack。

---

作者信息：刘世民（Sammy Liu），IBM 云架构师，十余年IT行业从业经历，在电信、企业软件、存储以及云计算等领域做过研发、管理和架构设计等工作。从 2012 年开始学习 OpenStack，对其核心模块有较深入的了解；带领过团队开发OpenStack模块。

责编：陈晨 联系请添加微信：violace95 备注公司 职位 姓名。寻求报道或投稿，请请发送至邮箱：chenchenjs@csdn.net