[连载型] Neutron系列（22）：OpenStack 高可用和灾备方案 [OpenStack HA and DR]【下】

问题导读：







1.RDD HA的部署方案都有哪些？
2.什么是A/A 方案？
3.网易 OpenStack 云的 HA 方案是什么？










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

3.1 RDO HA

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

 

<ignore_js_op>

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

 

• 一台（物理或者虚拟）服务器部署 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：

 

<ignore_js_op>

 

其中：

 

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

 

各 HA 组件之间的关系：

 

<ignore_js_op>

 

各组件被调用的方式：

 

<ignore_js_op>

 

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

 

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

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

 

<ignore_js_op>

 

• 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

<ignore_js_op>

 

特征：

 

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

3.5 Paypal OpenStack 生产系统 HA

<ignore_js_op>

 

特征：

 

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

3.6 Oracel OpenStack HA：A/P HA

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

 

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

 

<ignore_js_op>

 

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

 

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

3.7 网易 OpenStack 云的 HA 方案

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

 

<ignore_js_op>

 

特征：

 

• 使用 keepalived 管理的 HAProxy
• 控制节点应该是 A/A HA 方案
• 没有看到计算节点和网络控制节点的 HA 方案，彷佛没有用 neutron，而是用 nova-network
• 高可用 RabbitMQ 集群和主备 MySQL，以及 memcache 集群是额外部署的

3.8 小结

• 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 提议:

 

<ignore_js_op>

 

状态：

 

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

 

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

参考连接和文档：

• deepdiveintohighlyavailableopenstackarchitecture-openstacksummitvancouver2015-150520154718-lva1-app6891.pdf
• RDO 官网
• OpenStack 官网
• Mirantis-OpenStack-6.0-ReferenceArchitecture (1).pdf