理解 OpenStack 高可用（1）：OpenStack 高可用和灾备方案（下）
理解 OpenStack 高可用（1）：OpenStack 高可用和灾备方案（上）这篇文章介绍了OpenStack高可用的基础知识，本文将详细介绍补分OpenStack提供者的详细HA方案。
3. 部分 OpenStack 方案提供者的 HA 方案
3.1 RDO HA
这里 有完整的 RDO HA 部署方案：
该配置最少需要五台机器：
- 一台（物理或者虚拟）服务器部署 nfs server，dhcp，dns
- 一台物理服务器来作为计算节点
- 三台物理服务器组成 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）
- OpenStack 客户端通过 VIP:8774 访问 nova-api
- HAProxy 将请求转到 controller 0 上的 nova-api
- nova-api 通过 VIP：3306 访问 Mysql DB
- 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 备注公司 职位 姓名。寻求报道或投稿，请请发送至邮箱：[email protected]