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

  • 时间:
  • 浏览:0
  • 来源:大发5分排列3_大发5分排列3官方

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

(来源及高清大图)

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

HA 将服务分为两类:

(3)使用 Mysql Galera 时,所有节点并能 Master 节点,都能并能接受服务,但会 这里有个问题,Mysql Galera 不用好友克隆 Write-intent locks。一一3个用户能并能在不同节点上获取到同根小记录,但会 并能并能一一3个并能修改成功,以并能 得到一一3个 Deadlock 错误。对于你这个 情況,Nova 使用 retry_on_deadlock 机制来重试,比如@oslo_db_api.wrap_db_retry(max_retries=5, retry_on_deadlock=True)。默认并能 重试 5 次。但会 ,你这个 机制带宽不高,文章作者提供了并并能 新的机制。

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

关于 MariaDB:

(3)集中式检查

Mirantis 推荐在生产环境中使用带相当于一一3个控制节点的 HA:

该 HA 方案具有以下优点:

云环境的 HA 将包括:

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

OpenStack 部署环境中,各节点能并能分为几类:

   HA 实现细节:

masakari, by NTT, 

各 HA 组件之间的关系:

(1)在使用非共享存储时,cinder-volume 程序运行池池受 Pacemaker 监控,在其停止的之前 重启。你这个 方案下,存储控制节点宕机励志的话 ,后面 的所有卷并能 损失掉。但会 ,在生产环境中,并能 使用下并并能 方案。

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

    大体上讲,容灾能并能分为3个级别:数据级别、应用级别以及业务级别。

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

(1)L2 Agent HA: L2 agent 只在所在的网络但会 计算节点上提供服务,但会 它是不并能 HA的。

(3)DHCP Agent 的 HA

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

 这里只讨论 cinder-volume。

(4)分布式健康检查

    该方案增加了一一3个配置项 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 中的一一3个都能并能承担无情況网络包的转发任务。但会 ,南-北网络但会 会受影响,但会 NAT 只所处于一一3个router 上。但会 ,reschedule 后,浮动 IP 也会无法工作,但会 它们与 router 的 内部人员端口的绑定关系不用被设置到新的router 上。

HA 并能 使用冗余的服务器组成集群来运行负载,包括应用和服务。你这个 冗余性并能并能将 HA 分为两类:

  但会 ,能并能看了实际部署中,你这个 方案用得较少,只看了 Oracel 在使用你这个 方案。

    该方案将 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,具体请参考 这篇文章 中描述的最好的土办法。

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

指通过建立异地容灾中心,做数据的远程备份,在灾难所处之前 要确保原有的数据不用丢失但会 遭到破坏。但在数据级容灾你这个 级别,所处灾难时应用是会中断的。

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

那些方案之间的对比:

结论:该方案比不上前面几条公司的方案,但会 :

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

OpenStack 官方认为,在满足其 HA 要求的情況下,能并能实现 IaaS 的 99.99% HA,但会 ,这不包括单个客户机的 HA。

跟 metadata service 相关的组件包括:

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

   部署最好的土办法如下:

  其中:

    L3 Agent 比较特殊,但会 它是所有 openstack (core)services 中唯一一一3个有情況的,但会 ,并能并能使用传统的在多个节点上部署多个实例使用LB来做HA。Neutron 并并能 的调度器(scheduler)支持在多个网络节点上部署多个L3 Agent,但会 ,由 L3 Agent 管理的 Virtual Router 自身并能 有HA的实现。它的HA的Neutron 原生实现包括如下几种最好的土办法:

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

(注意,但会 虚机在启动过程中并能 访问 qrouter,这也好多好多 说,要求虚机所在的子网并能 但会 加在到了一一3个 Virtual router 上,但会 ,它是无法通过 qrouter 走的,除非走 qdhcp)

但会 更完整性地看出完整性的路径(图中红色线条,从VM现在开使,到 NOVA-API Metadata 现在开使):

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

价值形式:

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

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

来源:TCP 官网

(5)LBaas Agent HA

该方案相当于并能 三台服务器。以 RDO 提供的案例为例,它由三台机器搭建成一一3个 Pacemaker A/A集群,在该集群的每个节点上运行:

(2)L3 Agent HA

    从后面 能并能看出,除了 DHCP Agent 天生就通过配置能并能实现 A/A HA 以及 L3 HA 以外,其它的组件的 HA 并能 A/P 的,但会 实现的技术能并能是原生的,并能并能使用 Pacemaker,并能并能结合起来使用。比如 RDO 的方案:

并能并能从别的高度上看待两者的区别: 

价值形式:

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

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

从每个 API 服务来看:

各组件被调用的最好的土办法:

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

该配置相当于并能 五台机器:

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

从 HA 高度来讲:

    云控制节点上运行的服务中,API 服务和内部人员工作组件并能 无情況的,但会 很容易就能并能实现 A/A HA;另一一一3个就要求 Mysql 和 RabbitMQ 也实现 A/A HA,而它们人个 并能 A/A 方案。但会 ,Mysql Gelera 方案要求三台服务器。但会 只想用两台服务器励志的话 ,则并能并能实现 A/P HA,但会 引入一一3个 Arbiter 来做 A/A HA。

几条概念:

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

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

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

参考链接和文档:

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

  其余其他前提条件:

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

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

价值形式:启用多个心跳网时,解决策略单一,引起用户业务不用说要的中断

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

在数据级容灾最好的土办法下,所建立的异地容灾中心能并能简单地把它理解成一一3个远程的数据备份中心。数据级容灾的恢复时间比较长,但会 相比其他容灾级别来讲它的费用比较低,但会 构建实施也相对简单。

2016/10/23 其他更新:

(4)Pacemaker 和 OpenStack Resource Agent (RA)

(c)Juno 引入的 DVR

    在测试环境中,你们都都常常将虚机创建在本地磁盘上,并能并能,在机器宕机励志的话 ,那些虚机将永远也回不来了。但会 ,在生产环境中,并能 将虚机部署在 cinder-volume 但会 共享的存储比如 RDB 但会 NFS 上。另一一一3个励志的话 ,在虚机损坏时,能并能从共享存储上将其恢复(使用 nova evacuate 功能)。 使用 Pacemaker 部署 A/P 方案(之类于 2.3 中 cinder-volume A/P HA)励志的话 ,生产环境中计算节点的数据往往远远超过 Corosync 集群中节点数目的限制。

价值形式:

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

(5)RabbitMQ HA

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

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

  该 HA 方案的问题是:

其中:

(来源:Mirantis 官网)

选取 树:

点评:HP 的 A/A 方案是不彻底的,甚至是其他怪异(为那些不一一3个控制节点做一一3个A/A 集群呢?),但会 相当于 Horizon、 Ceilomter 和 Neutron Agents 并能并能实现 HA,它只实现了 API,DB 和 MQ 的 HA。

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

Neutron 包括好多好多 有的组件,比如 L3 Agent,L2 Agent,LBaas,VPNaas,FWaas,Metadata Agent 等 Neutron 组件,其中帕累托图组件提供了原生的HA 支持。那些组件之间的联系和区别:

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

  业界有几条解决方案:

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

情況:

价值形式:太简单粗暴,容易引起误杀和数据损坏

(4)Metadata agent 和 proxy 的 HA

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

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

 价值形式:

OCF RAs, as used by Red Hat and SUSE

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

  

(1)根据该文章中的一一3个调查,被调查的 220 多个用户中,400 个在用 Mysql Galera,20 多个在用单 Mysql,并能并能一一3个用 PostgreSQL。

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

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

(来源)

要实现 OpenStack HA,一一3个最基本的要求是那些节点并能 冗余的。根据每个节点上部署的软件特点和要求,每个节点能并能采用不同的 HA 模式。但会 ,选取 HA 模式有个基本的原则:

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

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

    并能 励志的话 ,能并能使用 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。

(1)OpenStack 高可用方案概述

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

但会 那些优点,该方案被血块采用。具体配置请参考 OpenStack High Availability Guide。

(6)MySQL HA