彩神大发排列五_神彩大发排列五官方 - 彩神大发排列五,神彩大发排列五官方是新浪网最重要的频道之一,24小时滚动报道国内、国际及社会新闻。每日编发新闻数以万计。

openStack灾备方案说明

  • 时间:
  • 浏览:3

结论:该方案比不上前面几次公司的方案,为什么会么会让:

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

为什么会么会让那此优点,该方案被血块采用。具体配置请参考 OpenStack High Availability Guide 。

(4)DHCP Agent 的 HA

HA 实现细节:

该方案大慨可不还可不可以三台服务器。以 RDO 提供的案例为例,它由三台机器搭建成有二个多 Pacemaker A/A集群,在该集群的每个节点上运行:

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

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

云环境的 HA 将包括:

(4)RabbitMQ 和 Mysql HA

可不还可不可以能从别的高度上看待两者的区别:

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

几次概念:

(1)在使用非共享存储时,cinder-volume 系统tcp连接受 Pacemaker 监控,在其停止的并且重启。你你这人方案下,存储控制节点宕机句子,后面 的所有卷后会 损失掉。为什么会么会让,在生产环境中,可不还可不可以使用下一种方案。

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

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

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

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

价值形式:

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

该方案将 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 提供了多种原生的 HA 方案:

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

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

(3)Juno 引入的 DVR

对 HA 来说,往往使用共享存储,曾经句子,RPO =0 ;同時 往往使用 Active/Active (双活集群) HA 模式来使得 RTO 几乎0,为什么会么会让使用 Active/Passive 模式的 HA 句子,则可不还可不可以将 RTO 减少到最小限度。HA 的计算公式是[ 1 - (宕机时间)/(宕机时间 + 运行时间)],亲们常常用几次 9 表示可用性:

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

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

其中:

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

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

Mirantis 推荐在生产环境中使用带大慨有二个多控制节点的 HA:

价值形式:

其余有些前提条件:

该 HA 方案的现象是:

从每个 API 服务来看:

该方案增加了有二个多配置项 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 上。

关于 MariaDB:

参考链接和文档:

该配置大慨可不还可不可以五台机器:

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

在数据级容灾土土办法下,所建立的异地容灾中心可不还可不可以简单地把它理解成有二个多远程的数据备份中心。数据级容灾的恢复时间比较长,为什么会么会让相比有些容灾级别来讲它的费用比较低,为什么会么会让构建实施也相对简单。

DHCP 协议自身就支持多个 DHCP 服务器,为什么会么会让,只可不还可不可以在多个网卡控制节点上,为每个租户网络创建多个 DHCP Agent,就能实现 DHCP 的 HA 了。

点评:HP 的 A/A 方案是不彻底的,甚至是有些怪异(为那此不有二个多控制节点做有二个多A/A 集群呢?),为什么会么会让大慨 Horizon、 Ceilomter 和 Neutron Agents 这么实现 HA,它只实现了 API,DB 和 MQ 的 HA。

这里只讨论 cinder-volume。

在测试环境中,亲们常常将虚机创建在本地磁盘上,这么,在机器宕机句子,那此虚机将永远也回不来了。为什么会么会让,在生产环境中,可不还可不可以将虚机部署在 cinder-volume 为什么会么会让共享的存储比如 RDB 为什么会么会让 NFS 上。曾经句子,在虚机损坏时,可不还可不可以从共享存储上将其恢复(使用 nova evacuate 功能)。  使用 Pacemaker 部署 A/P 方案(同类于 2.3 中 cinder-volume A/P HA)句子,生产环境中计算节点的数据往往远远超过 Corosync 集群中节点数目的限制。就该需求,RadHat 提出了亲们的使用 Pacemaker Remote 技术的  计算节点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 。

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

其中:

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

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

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

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

HA 将服务分为两类:

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

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

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

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

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

OpenStack 官方认为,在满足其 HA 要求的情况汇报下,可不还可不可以实现 IaaS 的 99.99% HA,为什么会么会让,这不包括单个客户机的 HA。

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

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

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

(1) OpenStack 高可用方案概述

来源: TCP 官网

该 HA 方案具有以下优点:

(3)使用 Mysql Galera 时,所有节点有的是 Master 节点,都可不还可不可以接受服务,为什么会么会让这里有个现象,Mysql Galera 不想克隆qq Write-intent locks。有二个多用户可不还可不可以在不同节点上获取到同两根记录,为什么会么会让必须有二个多可不还可不可以修改成功,曾经会得到有二个多 Deadlock 错误。对于你你这人情况汇报,Nova 使用 retry_on_deadlock 机制来重试,比如@oslo_db_api.wrap_db_retry(max_retries=5, retry_on_deadlock=True)。默认有的是重试 5 次。为什么会么会让,你你这人机制速度不高,文章作者提供了一种新的机制。

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

部署土土办法如下:

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

(来源: Mirantis 官网 )

情况汇报:

为什么会么会让,可不还可不可以就看实际部署中,你你这人方案用得较少,只就看 Oracel 在使用你你这人方案。

( 来源 )

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

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

价值形式:

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

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

( 来源及高清大图 )

云控制节点上运行的服务中,API 服务和內部工作组件有的是无情况汇报的,为什么会么会让很容易就可不还可不可以实现 A/A HA;曾经就要求 Mysql 和 RabbitMQ 也实现 A/A HA,而它们各人 有的是 A/A 方案。为什么会么会让,Mysql Gelera 方案要求三台服务器。为什么会么会让只想用两台服务器句子,则必须实现 A/P HA。

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

要实现 OpenStack HA,有二个多最基本的要求是那此节点有的是冗余的。根据每个节点上部署的软件特点和要求,每个节点可不还可不可以采用不同的 HA 模式。为什么会么会让,选用 HA 模式有个基本的原则:

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

(5)LBaas Agent HA

(1)根据该文章中的有二个多调查,被调查的 220 多个用户中,150 个在用 Mysql Galera,20 多个在用单 Mysql,必须有二个多用 PostgreSQL。