[连载型] Neutron系列(22):OpenStack 高可用和灾备方案 [OpenStack HA and DR]【下】...

本文深入探讨了OpenStack高可用性(HA)部署方案,包括RDO、Mirantis、HP等多家公司提供的A/A和A/P模式解决方案。分析了各方案的优缺点,如RDO的彻底HA方案、Mirantis的集中式控制节点以及HP的部分HA实现,并对比了数据库、消息队列、负载均衡等关键组件的HA策略。

问题导读:







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 方式。

 

ServiceProcess
Mode
HA stragegy
Support servicesMariaDB - Galera
A/A
HAProxy / app cluster
Support servicesRabbitMQ
A/A
App cluster / service config
Support servicesHAProxy
A/A
Keepalived
Support servicesMongoDB
A/A
App cluster (ceilometer 和 heat 会使用)
Support servicesMemcached
A/A
Service configuration
Keystoneopenstack-keystone
A/A
HAProxy
Glanceopenstack-glance-api
A/A
HAProxy
Glanceopenstack-glance-registry
A/A
HAProxy (向 glance-api 提供 REST API)
Novaopenstack-nova-api
A/A
HAProxy
Novaopenstack-nova-cert
A/A
 
Novaopenstack-nova-compute
A/A
参见 2.4 部分描述
Novaopenstack-nova-scheduler
A/A
 
Novaopenstack-nova-conductor
A/A
 
Novaopenstack-nova-novncproxy
A/A
HAProxy
Cinderopenstack-cinder-api
A/A
HAProxy
Cinderopenstack-cinder-scheduler
A/A
 
Cinderopenstack-cinder-volume
A/P
No HA (RH 不把 A/P HA 当作HA!)。参考这里
Cinderopenstack-cinder-backup
A/A
 
Neutronneutron-server
A/A
HAProxy
Neutronneutron-dhcp-agent
A/A
Multiple DHCP agents
Neutronneutron-l3-agent
A/A
L3 HA
Neutronneutron-metadata-agent
A/A
 
Neutronneutron-lbaas-agent
A/P
目前的设计不允许 A/A
Neutronneutron-openvswitch-agent
A/A
 
Neutronneutron-metering-agent
A/A
 
Horizonhttpd
A/A
HAProxy
Ceilometeropenstack-ceilometer-api
A/A
HAProxy
Ceilometeropenstack-ceilometer-central
A/A
Workload partitioning: tooz + Redis
Ceilometeropenstack-ceilometer-compute
A/A
 
Ceilometeropenstack-ceilometer-alarm-notifier
A/A
 
Ceilometeropenstack-ceilometer-evaluator
A/A
 
Ceilometeropenstack-ceilometer-notification
A/A
 
Heatopenstack-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

转载于:https://www.cnblogs.com/liuhongru/p/11098422.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值