8620-84511745

Blog Post

OpenStack 高可用和灾备方案(下)

(转发)2016-05-25 Sammy Liu OpenStack中国社区

屏幕快照 2016-05-27 下午2.29.03.png OpenStack 高可用和灾备方案(上)这篇文章介绍了OpenStack高可用的基础知识,本文将详细介绍补分OpenStack提供者的详细HA方案。

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

这里 (https://github.com/beekhof/osp-ha-deploy)有完整的 RDO HA 部署方案: 屏幕快照 2016-05-27 下午2.32.26.png 该配置最少需要五台机器:

  • 一台(物理或者虚拟)服务器部署 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 方式。

屏幕快照 2016-05-27 下午2.37.58.png

屏幕快照 2016-05-27 下午2.39.00.png

屏幕快照 2016-05-27 下午2.41.49.png

屏幕快照 2016-05-27 下午2.42.46.png

关于 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:

屏幕快照 2016-05-27 下午3.00.23.png 其中:

  • 使用 Pacemaker 控制 Neutron Agent,实现 A/P HA
  • API 服务运行在多个节点上,使用 HAProxy 实现负载均衡,提供 VIP
  • RabbitMQ A/A
  • Mysql A/A
各 HA 组件之间的关系:

屏幕快照 2016-05-27 下午3.03.45.png

屏幕快照 2016-05-27 下午3.04.30.png

各组件被调用的方式:

屏幕快照 2016-05-27 下午3.05.03.png 点评:与 RDO 方案一样,该 HA 也是一个彻底的 HA 方案,消除了整个系统的 SPOF。但是,与 RDO 相比分散式控制节点相比,Mirantis 的集中式控制节点上运行的服务较多,可能会影响其性能,但是在小规模云环境中节省了硬件成本。

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

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

屏幕快照 2016-05-27 下午3.08.56.png

  • 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

屏幕快照 2016-05-27 下午3.13.00.png 特征:

3.5 Paypal OpenStack 生产系统 HA

屏幕快照 2016-05-27 下午3.15.25.png 特征:

  • 使用硬件负载均衡 F5
  • 使用商业 SDN
  • 使用 Monit 监控和重启各服务
  • 使用 Pacemaker
  • 用在生成系统,优化进行中
3.6 Oracel OpenStack HA:A/P HA

CRM:Oracel Clusterware(Oracle Grid Infrastructure Release 12c Release 1 or later)

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

屏幕快照 2016-05-27 下午3.19.19.png 结论:该方案比不上前面几个公司的方案,因为:

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

好不容易找到一个国内公司的方案,来源在 这里(https://www.ibm.com/developerworks/cn/cloud/library/1408_zhangxl_openstack/):

屏幕快照 2016-05-27 下午3.41.43.png 特征:

  • 使用 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 提议(https://wiki.openstack.org/wiki/DisasterRecovery):

屏幕快照 2016-05-27 下午3.43.52.png 状态:

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

可以参考 更多文档,包括 Preparing for the Worst Case Scenario: A Vision for OpenStack Disaster Recovery(http://redhatstackblog.redhat.com/2013/10/31/preparing-for-the-worst-case-scenario-a-vision-for-openstack-disaster-recovery/)和 Disaster Recovery Enablement in OpenStack(http://redhatstackblog.redhat.com/2013/11/26/disaster-recovery-enablement-in-openstack/)。

Posted in Openstack on May 09, 2016