openStack灾备方案说明

  • 时间:
  • 浏览:1
  • 来源:uu快3玩法_uu快3新平台_棋牌

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

部署法律方式如下:

内外部:

其余这俩前提条件:

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

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

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

DHCP 协议自身就支持多个 DHCP 服务器,否则 ,只前要在多个网卡控制节点上,为每个租户网络创建多个 DHCP Agent,就能实现 DHCP 的 HA 了。

清况 :

OpenStack 部署环境中,各节点可不前要分为几类:

哪几只概念:

( 来源 )

关于 MariaDB:

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

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

HA 前要使用冗余的服务器组成集群来运行负载,包括应用和服务。这俩 冗余性也可不前要将 HA 分为两类:

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

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

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

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

(5)LBaas Agent 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 。

HA 实现细节:

目前,OpenStack 上那末实现 DR。 I BM 和 RedHat 联合发起的 DRaas 提议 :

在测试环境中,我门我门我门我门常常将虚机创建在本地磁盘上,那末,在机器宕机句子,哪此虚机将永远也回不来了。否则 ,在生产环境中,前要将虚机部署在 cinder-volume 可能性共享的存储比如 RDB 可能性 NFS 上。那末 句子,在虚机损坏时,可不前要从共享存储上将其恢复(使用 nova evacuate 功能)。  使用 Pacemaker 部署 A/P 方案(类事 2.3 中 cinder-volume A/P HA)句子,生产环境中计算节点的数据往往远远超过 Corosync 集群中节点数目的限制。就该需求,RadHat 提出了我门我门我门我门的使用 Pacemaker Remote 技术的  计算节点HA 方案 。

对 HA 来说,往往使用共享存储,那末 句子,RPO =0 ;共同往往使用 Active/Active (双活集群) HA 模式来使得 RTO 几乎0,可能性使用 Active/Passive 模式的 HA 句子,则前要将 RTO 减少到最小限度。HA 的计算公式是[ 1 - (宕机时间)/(宕机时间 + 运行时间)],我门我门我门我门常常用哪几只 9 表示可用性:

各组件被调用的法律方式:

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

该方案增加了有有一5个配置项 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 中的有有一5个都可不前要承担无清况 网络包的转发任务。否则 ,南-北网络可能性会受影响,可能性 NAT 只居于于有有一5个router 上。否则 ,reschedule 后,浮动 IP 也会无法工作,可能性它们与 router 的 内外部端口的绑定关系不需要被设置到新的router 上。

(5)OpenStack 和 VMware 的高可用性比较

云环境的 HA 将包括:

(3)使用 Mysql Galera 时,所有节点完整篇 都是 Master 节点,都可不前要接受服务,否则 这里有个问题,Mysql Galera 不需要一键复制 Write-intent locks。有有一5个用户可不前要在不同节点上获取到同根小绳子 记录,否则 那末有有一5个不利于修改成功,那末 会得到有有一5个 Deadlock 错误。对于这俩 清况 ,Nova 使用 retry_on_deadlock 机制来重试,比如@oslo_db_api.wrap_db_retry(max_retries=5, retry_on_deadlock=True)。默认完整篇 都是重试 5 次。否则 ,这俩 机制传输时延不高,文章作者提供了并否有新的机制。

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

内外部:

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

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

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

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

其中:

也可不前要从别的高度上看待两者的区别:

否则 ,可不前要看一遍实际部署中,这俩 方案用得较少,只看一遍 Oracel 在使用这俩 方案。

从每个 API 服务来看:

该方案将 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) 。

(3)Juno 引入的 DVR

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

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

可能性哪此优点,该方案被多量采用。具体配置请参考 OpenStack High Availability Guide 。

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

参考链接和文档:

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

(2)在使用共享存储时,考虑到目前代码中居于的资源竞争(参考 这里 ),该服务那末实现为 A/P HA 法律方式,也就说 说在某个时刻,那末主节点上的 cinder-volume 在运行。RedHat 这俩   ticket 带有具体的分析。目前,cinder-volume 还那末内在的 HA 实现,那末借助第三方软件比如 Pacemaker。A/A 的实现在 Liberty 中正在进行,请  参见 和 这俩  。

其中:

在数据级容灾法律方式下,所建立的异地容灾中心可不前要简单地把它理解成有有一5个远程的数据备份中心。数据级容灾的恢复时间比较长,否则 相比这俩容灾级别来讲它的费用比较低,否则 构建实施也相对简单。

这里只讨论 cinder-volume。

HA 将服务分为两类:

该 HA 方案具有以下优点:

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

来源: TCP 官网

( 来源及高清大图 )

该配置合适前要五台机器:

大体上讲,容灾可不前要分为5个级别:数据级别、应用级别以及业务级别。

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

(1)Juno 中引入的 Automatic L3 Agent Failover (自动 L3 Agent 切换)

(1)根据该文章中的有有一5个调查,被调查的 220 多个用户中,80 个在用 Mysql Galera,20 多个在用单 Mysql,那末有有一5个用 PostgreSQL。

(来源: Mirantis 官网 )

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

(1) OpenStack 高可用方案概述

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

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

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

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

(1)在使用非共享存储时,cinder-volume 进程受 Pacemaker 监控,在其停止的前一天重启。这俩 方案下,存储控制节点宕机句子,顶端的所有卷完整篇 都是损失掉。否则 ,在生产环境中,前要使用下并否有方案。

要实现 OpenStack HA,有有一5个最基本的要求是哪此节点完整篇 都是冗余的。根据每个节点上部署的软件特点和要求,每个节点可不前要采用不同的 HA 模式。否则 ,选折 HA 模式有个基本的原则:

(4)RabbitMQ 和 Mysql HA

该 HA 方案的问题是:

该节点上安装有 L3 Agent,L2 Agent,LBaas,VPNaas,FWaas,Metadata Agent 等 Neutron 组件,其中部分组件提供了原生的HA 支持。

内外部:

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

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

(4)DHCP Agent 的 HA

(2) Juno 中引入的 VRRP (Virtual Router Redundancy Protocol)方案

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

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

结论:该方案比不上前面哪几只公司的方案,可能性:

云控制节点上运行的服务中,API 服务和内内外部工作组件完整篇 都是无清况 的,否则 很容易就可不前要实现 A/A HA;那末 就要求 Mysql 和 RabbitMQ 也实现 A/A HA,而它们各自 完整篇 都是 A/A 方案。否则 ,Mysql Gelera 方案要求三台服务器。可能性只想用两台服务器句子,则那末实现 A/P HA。

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