理解 OpenStack 高可用(HA)(1):OpenStack 高可用和灾备方案 [OpenStack HA and DR]

  • 时间:
  • 浏览:3

  业界有多少除理方案:

    对 HA 来说,往往使用共享存储,另另一个多 话语,RPO =0 ;一同往往使用 Active/Active (双活集群) HA 模式来使得 RTO 几乎0,可能使用 Active/Passive 模式的 HA 话语,则可不才能将 RTO 减少到最小限度。HA 的计算公式是[ 1 - (宕机时间)/(宕机时间 + 运行时间)],亲戚亲戚他们 常常用多少 9 表示可用性:

各 HA 组件之间的关系:

要实现 OpenStack HA,另一个多 多最基本的要求是那此节点都在冗余的。根据每个节点上部署的软件特点和要求,每个节点都可不才能采用不同的 HA 模式。否则,选取 HA 模式有个基本的原则:

    可不才能话语,都可不才能使用 Pacemaker + Corosync 搭建两节点集群实现 A/P HA 方案。由主服务器实际提供服务,在其故障时由 Pacemaker 将服务切换到被服务器。OpenStack 给其组件提供了各种Pacemaker RA。对 Mysql 和 RabbitMQ 来说,都可不才能使用 Pacemaker + Corosync + DRBD 实现 A/P HA。具体请参考 理解 OpenStack 高可用(HA)(4):RabbitMQ 和 Mysql HA。具体配置请参考 OpenStack High Availability Guide。

    L3 Agent 比较特殊,可能它是所有 openstack (core)services 中唯另一个多 多有情况报告的,否则,必须使用传统的在多个节点上部署多个实例使用LB来做HA。Neutron 并都在的调度器(scheduler)支持在多个网络节点上部署多个L3 Agent,否则,由 L3 Agent 管理的 Virtual Router 自身可不才能有HA的实现。它的HA的Neutron 原生实现包括如下几种最好的最好的措施:

本系列会分析OpenStack 的高可用性(HA)概念和除理方案:

(2)在使用共享存储时,考虑到目前代码中指在的资源竞争(参考这里),该服务必须实现为 A/P HA 最好的最好的措施,也却说说在某个时刻,必须主节点上的 cinder-volume 在运行。RedHat 某些 ticket 蕴含具体的分析。目前,cinder-volume 还没法内在的 HA 实现,必须借助第三方软件比如 Pacemaker。A/A 的实现在 Liberty 中正在进行,请 参见 和 某些。

OCF RAs, as used by Red Hat and SUSE

特征:

从 HA 角度来讲:

(5)RabbitMQ HA

(来源)

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

该方案合适可不才能三台服务器。以 RDO 提供的案例为例,它由三台机器搭建成另一个多 多 Pacemaker A/A集群,在该集群的每个节点上运行:

(2)Neutron L3 Agent HA - VRRP (虚拟路由冗余协议)

该 HA 方案具有以下优点:

(3)集中式检查

另一个多 多异地容灾系统,往往包括本地的 HA 集群和异地的 DR 数据中心。另一个多 多示类似下(来源:百度文库):

    从底下都可不才能看出,除了 DHCP Agent 天生就通过配置都可不才能实现 A/A HA 以及 L3 HA 以外,其它的组件的 HA 都在 A/P 的,否则实现的技术都可不才能是原生的,也都可不才能使用 Pacemaker,也都可不才能结合起来使用。比如 RDO 的方案:

(a)Juno 中引入的 Automatic L3 Agent Failover (当 VR 所在的 L3 Agent 失效的前一天,Neutron 自动将它 failover 到其它某个 L3 Agent 上)

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

Neutron 提供了多种原生的 HA 方案:

  使用 Pacemaker + Corosync 搭建两节点(可能多节点) A/P 集群。在主节点上,由 Pacemaker 启动 Neutron 的各种服务。 

可能更全部地看出全部的路径(图中红色线条,从VM刚开使,到 NOVA-API Metadata 刚开使):

    该方案将 NAT 和 L3 Agent 部署到虚机所在的计算节点,在网络控制节点上只部署 DHCP 和 SNAT。该方案除理了 L3 Agent 和 Metadata Agent 的 H/A 难题。目前,将 DHCP Agent 改成分布式,VPNaas 以及 FWaas 的修改工作可能在进行中。用户可不才能使用第三方软件提供 SNAT 的 HA 方案。都可不才能参考 理解 OpenStack 高可用(HA)(3):Neutron 分布式虚拟路由(Neutron Distributed Virtual Routing)。

    目前 Neutron LBaaS 代理服务是无法通过其自带的 HAProxy 插件 实现高可用的。实现 HAProxy 高可用常见的方案是使用 VRRP (Virtual Router Redundancy Protocol ,虚拟路由冗余协议),不过 LBaaS HAProxy 插件目前还不支持该协议。否则,必须使用 Pacemaker + 共享存储(放置 /var/lib/neutron/lbaas/ 目录) 的最好的最好的措施来部署 A/P 最好的最好的措施的 LBaas Agent HA,具体请参考 这篇文章 中描述的最好的最好的措施。

也都可不才能从别的角度上看待两者的区别: 

点评:HP 的 A/A 方案是不彻底的,甚至是某些怪异(为那此不另一个多 多控制节点做另一个多 多A/A 集群呢?),可能合适 Horizon、 Ceilomter 和 Neutron Agents 没法实现 HA,它只实现了 API,DB 和 MQ 的 HA。

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

各组件被调用的最好的最好的措施:

Master SQL Server 指在故障时,切换到 Standby SQL Server,继续提供数据库服务:

2016/10/23 某些更新:

从每个 API 服务来看:

(3)使用 Mysql Galera 时,所有节点都在 Master 节点,都都可不才能接受服务,否则这里有个难题,Mysql Galera 可不还能能 克隆好友 Write-intent locks。另一个多 多用户都可不才能在不同节点上获取到同一根绳子 记录,否则只另一个多 多多才能修改成功,另另一个多 会得到另一个多 多 Deadlock 错误。对于某些情况报告,Nova 使用 retry_on_deadlock 机制来重试,比如@oslo_db_api.wrap_db_retry(max_retries=5, retry_on_deadlock=True)。默认都在重试 5 次。否则,某些机制传输传输速率不高,文章作者提供了并都在新的机制。

(来源:Mirantis 官网)

特征:

指通过建立异地容灾中心,做数据的远程备份,在灾难指在前一天要确保原有的数据可不还能能 丢失可能遭到破坏。但在数据级容灾某些级别,指在灾难时应用是会中断的。

关于共享 DB 的多少说明 (主要来自 这篇文章):

结论:该方案比不上前面多少公司的方案,可能:

(4)分布式健康检查

云环境的 HA 将包括:

(1)在使用非共享存储时,cinder-volume 线程受 Pacemaker 监控,在其停止的前一天重启。某些方案下,存储控制节点宕机话语,底下的所有卷都会损失掉。否则,在生产环境中,可不才能使用下并都在方案。

    DHCP 协议自身就支持多个 DHCP 服务器,否则,只可不才能在多个网卡控制节点上,通过修改配置,为每个租户网络创建多个 DHCP Agent,就能实现 DHCP 的 HA 了。

   部署最好的最好的措施如下:

来源:TCP 官网

(b)Juno 中引入的 VRRP (Virtual Router Redundancy Protocol)方案 (由 VRRP/Keepalived 控制 VR 的 VIP 和 VMAC 的 failover)

  

HA 可不才能使用冗余的服务器组成集群来运行负载,包括应用和服务。某些冗余性也都可不才能将 HA 分为两类:

(1)根据该文章中的另一个多 多调查,被调查的 220 多个用户中,60 个在用 Mysql Galera,20 多个在用单 Mysql,只另一个多 多多用 PostgreSQL。

跟 metadata service 相关的组件包括:

在主机房中心指在灾难时,切换到备份机房(总公司机房中心)上,恢复应用和服务:

OpenStack 的各提供商中,就该需求,RadHat 使用的是上述的第二种方案,具体方案在 计算节点HA 方案:

(1)L2 Agent HA: L2 agent 只在所在的网络可能计算节点上提供服务,否则它是必须HA的。

Neutron 包括什么都的组件,比如 L3 Agent,L2 Agent,LBaas,VPNaas,FWaas,Metadata Agent 等 Neutron 组件,其中部分组件提供了原生的HA 支持。那此组件之间的联系和区别:

(2)Pacemaker-remote: 突破Corosync的集群规模限制,

小结: OpenStack 云/网络/存储 控制节点 HA 集群

特征:启用多个心跳网时,除理策略单一,引起用户业务无可不才能的中断

(1)OpenStack 高可用方案概述

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

都可不才能参考 RedHat 的更多文档,包括 Preparing for the Worst Case Scenario: A Vision for OpenStack Disaster Recovery 和 Disaster Recovery Enablement in OpenStack。

(2)L3 Agent HA

这里 有全部的 RDO HA 部署方案:

 这里只讨论 cinder-volume。

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

HA 将服务分为两类:

(6)MySQL HA

可能那此优点,该方案被少许采用。具体配置请参考 OpenStack High Availability Guide。

那此方案之间的对比:

选取树:

(1)Controller 节点通过管理网 Ping 所有 Compute 节点,Controller 节点检查nova service-list,对出难题的节点 Evacuate

    在测试环境中,亲戚亲戚他们 常常将虚机创建在本地磁盘上,没法,在机器宕机话语,那此虚机将永远也回不来了。否则,在生产环境中,可不才能将虚机部署在 cinder-volume 可能共享的存储比如 RDB 可能 NFS 上。另另一个多 话语,在虚机损坏时,都可不才能从共享存储上将其恢复(使用 nova evacuate 功能)。 使用 Pacemaker 部署 A/P 方案(类似 2.3 中 cinder-volume A/P HA)话语,生产环境中计算节点的数据往往远远超过 Corosync 集群中节点数目的限制。

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

    云环境包括另一个多 多广泛的系统,包括硬件基础设施、IaaS层、虚机和应用。以 OpenStack 云为例:

(3)Neutron L3 Agent HA - DVR (分布式虚机路由器)

(http://techbackground.blogspot.com/2013/06/metadata-via-quantum-router.html)

其中:

   某些方案要求使用多个网络控制节点,每个节点上运行另一个多 多 L3 Agent。在某个 Agent 死了时,Router 会被部署到别的 Agent 上。某些方案,除了上述的难题外,切换时间过长是其主要难题。

(5)LBaas Agent HA

本文的重点是讨论 OpenStack 作为 IaaS 的 HA。 

    本文转自SammyLiu博客园博客,原文链接:http://www.cnblogs.com/sammyliu/p/4741967.html,如需转载请自行联系原作者

    云控制节点上运行的服务中,API 服务和组织组织结构工作组件都在无情况报告的,否则很容易就都可不才能实现 A/A HA;另另一个多 就要求 Mysql 和 RabbitMQ 也实现 A/A HA,而它们各自 都在 A/A 方案。否则,Mysql Gelera 方案要求三台服务器。可能只想用两台服务器话语,则必须实现 A/P HA,可能引入另一个多 多 Arbiter 来做 A/A HA。

情况报告:

    两者相互关联,互相补充,互有交叉,一同又有显著的区别:

    大体上讲,容灾都可不才能分为一个多级别:数据级别、应用级别以及业务级别。

(4)Metadata agent 和 proxy 的 HA

该配置合适可不才能五台机器:

  其中:

(注意,可能虚机在启动过程中可不才能访问 qrouter,这也却说说,要求虚机所在的子网可不才能可能添加到了另一个多 多 Virtual router 上,否则,它是无法通过 qrouter 走的,除非走 qdhcp)

(3)DHCP Agent 的 HA

(https://www.hastexo.com/system/files/neutron_packet_flows-notes-handout.pdf)

 特征:

(c)Juno 引入的 DVR

关于 MariaDB:

在数据级容灾最好的最好的措施下,所建立的异地容灾中心都可不才能简单地把它理解成另一个多 多远程的数据备份中心。数据级容灾的恢复时间比较长,否则相比某些容灾级别来讲它的费用比较低,否则构建实施也相对简单。

参考链接和文档:

特征:太简单粗暴,容易引起误杀和数据损坏

  该 HA 方案的难题是:

(2)以 Nova 为例,Mysql 使用 Write-intent locks 机制来保证多个连接一同访问数据库中的同一根绳子 记录时的互斥。以给新建虚机分配 IP 地址为例,该锁机制保证了另一个多 多 IP 可不还能能 分给另一个多 多用户。

多少概念:

OpenStack 部署环境中,各节点都可不才能分为几类:

    高可用性是指提供在本地系统单个组件故障情况报告下,能继续访问应用的能力,无论某些故障是业务流程、物理设施、IT软/硬件的故障。最好的可用性, 都在你在的一台机器宕机了,否则使用你的服务的用户全部感觉必须。你的机器宕机了,在该机器上运行的服务肯定得做故障切换(failover),切换有另一个多 多维度的成本:RTO (Recovery Time Objective)和 RPO(Recovery Point Objective)。RTO 是服务恢复的时间,最佳的情况报告是 0,这愿因分析服务立即恢复;最坏是无穷大愿因分析服务永远恢复不了;RPO 是切换时向前恢复的数据的时间长度,0 愿因分析使用同步的数据,大于 0 愿因分析有数据丢失,比如 ” RPO = 1 天“ 愿因分析恢复时使用一天前的数据,没法一天之内的数据就丢失了。否则,恢复的最佳结果是 RTO = RPO = 0,否则某些太理想,可能要实现话语成本太高,全球估计 Visa 等少数多少公司能实现,可能几乎实现。

    该方案增加了另一个多 多配置项 allow_automatic_l3agent_failover。当它的值为 True 时,L3 plugin 去周期性地检查所有有管理 Virtual Router 的 L3 Agent 的情况报告。可能某 L3 Agent 死了,受它管理的 Router 会重新被 schedule 到别的 L3 Agent 上。 Neutron L3 Plugin 通过判断该 L3 Agent 算不算在规定时间(agent_down_time)内有发回心跳消息来判断它算不算活着。指在多种 L3 Agent 未能及时上报心跳否则 router 依然在转发网络包的可能。否则某些实现可能会指在 L3 Agent 被认为死了否则其 router namespace 依然在转发网络包和响应 ARP 请求而愿因分析的难题。可能网络后端不阻止死掉了的 agent 使用 route 的 IP 地址,那新老 namespace 就可能指在冲突。某些冲突可不还能能 断掉 E-W 网络,可能新老 namespace 中的另一个多 多都都可不才能承担无情况报告网络包的转发任务。否则,南-北网络可能会受影响,可能 NAT 只指在于另一个多 多router 上。否则,reschedule 后,浮动 IP 也会无法工作,可能它们与 router 的 组织组织结构端口的绑定关系可不还能能 被设置到新的router 上。

masakari, by NTT, 

好不容易找到另一个多 多国内公司的方案,来源在 这里:

Mirantis 推荐在生产环境中使用带合适另一个多 多控制节点的 HA:

特征:

(以上资料来自 基于Fuel的超融合一体机 by 周征晟 / 2015-06-27)

否则,“数据源是一切关键性业务系统的生命源泉”,否则数据级容灾必不可少。

    该方案使用多余另一个多 多的网络控制节点,提供 A/P HA。具体请参考我的另一篇文章 理解 OpenStack 高可用(HA)(2):Neutron L3 Agent HA 之 虚拟路由冗余协议(VRRP)。其主要特点为:

OpenStack 官方认为,在满足其 HA 要求的情况报告下,都可不才能实现 IaaS 的 99.99% HA,否则,这不包括单个客户机的 HA。

  当另一个多 多节点失效时,恢复(recovery)过程会被触发,Pacemaker 会依次:

  否则,都可不才能都看实际部署中,某些方案用得较少,只都看 Oracel 在使用某些方案。

(来源及高清大图)

  其余某些前提条件:

(4)Pacemaker 和 OpenStack Resource Agent (RA)

   HA 实现细节: