OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目。

它的社区拥有超过130家企业及1350位开发人员,这些机构与个人都将OpenStack作为基础设施即服务(IaaS)资源的通用前端。OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性。做为云计算IAAS层事实标准。OpenStack广泛的应用与各行各业。到眼下为止OpenStack社区并没有一个完整的虚拟机HA解决方式。

起初社区觉得虚拟机的HA不是云平台层次的特性,不应该在云平台层面来实现,虚拟机的HA应该通过应用层面的HA来实现。可是非常多应用不是默认做了应用层面的HA,OpenStack又缺少这样一个重要的特性。所以非常多公司针对虚拟机的HA提出了自己的解决方式。近期社区也開始关注虚拟机的HA的是实现。这篇文章针对OpenStack中的虚拟机HA的进展和几个公司的虚拟机HA实现进行介绍。

最后在结合各种方案的长处的基础上,介绍了一个虚拟机的HA的实现方案。

一、OpenStack中虚拟机HA的历史和现状

OpenStack中虚拟机的HA的最初讨论能够见这篇文章, 作为Nova项目的重要贡献者。他的文章对虚拟机的HA的实现有着广泛的影响。

这篇文章也给出了虚拟机HA实现的基本思路。解决问题须要一些关键的部件:

监控(Monitoring)- 系统检測到虚拟化层的故障

隔离(或是围栏。Fencing) - 系统隔离故障计算节点

恢复(Recovery) - 从故障的虚拟化上恢复虚拟机

下边是OpenStack中针对虚拟机HA的一些解决方式;

1.      Nova中的支持

Nova已经具备了一些HA的功能。

1)  在nova中提供了Evacuate命令来实现,将VM从失败的Compute节点在目标节点上rebuild。

这一功能的实现须要依赖源节点和目标节点间有共享存储。

2)  在VM的HA其中,对于Compute节点是否故障的推断须要很的精细,眼下在Openstack中每一个nova-compute服务启动时都会启动一个定时器。定期的将心跳写入到数据库中,这样能够从控制节点方便的知道Compute节点的状态。

可是Openstack只拥有这些功能还不足以完毕对VM HA功能的完美支持。

1)  仅仅是通过nova-compute服务来确定Compute节点的状态时不可靠的。比如仅仅是nova-compute服务失效,或者网络闪断时,也会造成心跳的过期,从而对是否进行HA不能进行准确的推断。因此须要通过其它方式来确保准确获得节点的状态。

最主要是OpenStack的最佳实践部署。一般是管理、业务和存储网段是单独的网段,这时Nova Service的服务状态仅仅能反映出管理网段的状态,不能反映出存储和业务网段的nova-compute节点的状态。

2)  Openstack没有对VM进行加锁,因此在进行Evacuate命令时,会出现脑裂(同一个disk启动多个VM的情况)。

3)  对于须要保护的虚拟机须要提供一个列表,用来表明哪些VM是用来保护的。

眼下的Evacuate命令会奖失败主机上的全部虚拟机无区别进行rebuild这种实现也是不太合理的。

2.      neutron+VRRP

为了防止防止arp欺骗。Neutron是不同意一个port上边绑定多个IP地址的。

Neutron在Havana Release添加了一个 “Allowed-Address-Pairs”的功能,同意虚拟机的一个port绑定附加的IP作为浮动IP。

这样在虚拟机中能够安装VRRP实现软件,比Keepalived等,浮动IP配置为额外添加的IP,多个虚拟机绑定的port都绑定这个额外的浮动IP。两个虚拟机通过VRRP能够选出一个主对外提供服务。

这个方法首先配置复杂,须要在Neutron中为须要參与HA的port绑定额外的IP。还要在虚拟机中配置VRRP支持软件,配置复杂。这个方法不能算是一个完整的方案,相当于为应用层的HA实现方案做了一个Neutron中的支持功能。

详细參考这篇文章。

3.  Heat Restarter

Heat的HA特性是OpenStack多模块配合实现的,当中涉及到Nova,Ceilometer,Heat-cfn-api,Heat-cloudwatch。Heat-cfntools等。

Nova->提供虚拟机

Ceilometer->发送告警

Heat-cfntools->监控虚拟机状态

当虚拟机上的应用进程down了。首先通过重新启动应用进程尝试解决。假设解决不了。重新启动或者重建虚拟机。假设还是解决不了,重建整个stack。从这一点上来看Heat HA的功能要比单纯的虚拟机HA的功能强大非常多。

可是对于普通的Web无状态应用,通过OS::Heat::HARestarter删除原有虚拟机,然后又一次创建或许适合的。可是假设是数据库之类的有状态应用呢?怎么保证原有数据库中数据的不丢失。后端卷虚拟机?那又怎么保证使用原来的fixed-ip?

正式因为HARestarter是通过删除原有虚拟机的方式和虚拟机的一些依赖资源,Openstack社区已经在Kilo版本号废弃了HARestarter

4.      OpenStack中的虚拟机HA方案的设想

二、各大公司的实现方案

1.      Masakari

Masakari 是日本NTT公司提供的一套虚拟HA方案。 Masakari支持虚拟机进程,虚拟化进程和计算节点进程的监控。通过shell脚本监控虚拟机进程,Nova-compute服务和计算节点状态。

虚拟机进程挂了->通过虚拟机的API关闭和启动虚拟机。

虚拟化进程挂了->通过Nova-compute API设置Nova-compute服务为down状态。

Nova-compute进程挂了->疏散计算节点上的虚拟机。

Masakari的架构:

masakari-controller :  这个HA服务的控制器。

masakari-instancemonitor : 检測虚拟机进程是否挂掉了。

masakari-processmonitor : 检測Nova-compute是否挂了。

masakari-hostmonitor : 检測计算节点是否挂了。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

该方案可取之处在于:对于虚拟机HA的解决方式中考虑了三个不同层次的故障。可是没有考虑虚拟机脑裂和计算节点的隔离。对于通常的OpenStack部署,都会存在管理、业务和存储三个网段的状态,简单的通过一个网段去监控计算节点的状态是不够的。

2.      Redhat 方案

部署方式例如以下:

使用 Pacemaker 集群作为控制平面

将计算节点做为 Partial members 增加到 Pacemaker 集群中,受其管理和监控。

这时候,其数目不受 Corosync 集群内节点总数的限制。

HA 实现细节:

Pacemaker通过pacemaker_remote依照顺序(neutron-ovs-agent -> ceilometer-compute ->nova-compute) 来启动计算节点上的各种服务。前面的服务启动失败,后面的服务不会被启动。

Pacemaker 监控和每一个计算节点上的 pacemaker_remote 的连接,来检查该节点是否处于活动状态。

发现它不能够连接的话,启动恢复(recovery)过程。

Pacemaker 监控每一个服务的状态,假设状态失效,该服务会被重新启动。重新启动失败则触发防护行为(fencing action);当全部服务都被启动后,虚机的网络会被恢复,因此,网络仅仅会短时间受影响。

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

1)  执行nova service-disable

2)  将该节点关机

3)  等待 nova 发现该节点失效了

4)  将该节点开机

5)  假设节点启动成功。运行novaservice-enable

6)  假设节点启动失败。则运行 novaevacuate把该节点上的虚机移到别的可用计算节点上。

当中:

l 步骤(1)和 (5)是可选的,其主要目的是防止 nova-scheduler 将新的虚机分配到该节点。

l 步骤(2)保证机器肯定会关机。

l 步骤(3)中眼下 nova 须要等待一段较长的超时时间才干推断节点 down 了。

Liberty 中有个 Blueprint 来加入一个
Nova API 将节点状态直接设置为 down。

l 其余一些前提条件:

l 虚机必须部署在 cinder-volume 或者共享的暂时存储比方 RBD 或者 NFS 上,这样虚机evaculation 将不会造成数据丢失。

l 假设虚机不使用共享存储。则必须周期性地创建虚机的快照并保存到 Glance 中。在虚机损坏后,能够从 Glance 快照上恢复。可是。这可能会导致状态或者数据丢失。

l 控制和计算节点须要安装 RHEL7.1+

l 计算节点须要有防护机制,比方 IPMI,硬件狗等

详细參考这里

3.      海云捷迅的方案

海云捷迅的分布式健康检查方案是我比較认同的一种监控计算节点是否挂掉的方案,考虑了管理、业务和存储三个网段的监控。

同一时候支持应用层的自己定义监控方式。详细參考这里

该方案引入了consul监控工具。通过consul集群在管理、业务和存储三个网段监控计算节点的状态。依据不同的组合情况,做出不同的处理方式。

我觉得是对虚拟机HA方案中的监控部分的深入和精细的控制,能够做到虚拟机的精准恢复,有效的防止虚拟机脑裂情况。

四、总结

鉴于各个公司都在为OpenStack做虚拟机的HA方案,社区也開始考虑实现虚拟机的HA方案。能够參考这里

集成各家方案的长处。尽可能的处理各种虚拟机的异常情况,保证云上应用的高可用。构想的例如以下的虚拟机HA方案,

服务框架:借鉴https://github.com/gryf/mistral-evacuate这个工作的思想,虚拟机HA的服务框架应该是一个相对通用的框架,用来处理各种用户的不同应用场景。

一个通用框架,要能处理不同的用户场景,服务框架还是要有一定的抽象和通用性。这里是HA服务的服务处理流程。

因为隔离和恢复部分基本没有太多的选择,各个公司的虚拟机HA方案中基本差异都在于监控部分,怎样做到精细的监控计算节点的状态。鉴于OpenStack环境基本都是管理、业务和存储网三网分开的部署方式。所以我觉得上边海云捷迅的分布式健康检查方式是比較有用的一种监控方式,再加上Ovirt 中的虚拟机磁盘加锁机制。

我觉得能够比較好的解决虚拟机HA的问题。參考下图:

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

虚拟机HA看似一个简单的需求,可是从上边的各种实现方式来看,都有着各自的有点和缺点。所以这个问题事实上还是挺复杂。欢迎大家就这个问题和我交流。

三、參考文档

https://review.openstack.org/#/c/257809/2

https://etherpad.openstack.org/p/automatic-evacuation

v=yq5nYPKxBCo&feature=youtu.be&t=23m22s">https://www.youtube.com/watch?

v=yq5nYPKxBCo&feature=youtu.be&t=23m22s

https://review.openstack.org/#/c/270015/7/user-stories/draft/ha_vm.rst

https://github.com/gryf/mistral-evacuate

http://blog.clusterlabs.org/blog/2015/openstack-ha-compute/

https://blueprints.launchpad.net/nova/+spec/vm-auto-ha-when-host-broken

Openstack相关技术交流请加群:314889201

也谈OpenStack中的虚拟机HA的更多相关文章

  1. Openstack中查看虚拟机console log的几种方法

    Openstack中有时候虚拟机启动不正常,这时可以通过查看虚拟机console log能得到一些有用的信息. 有这些方法可以查看或获取虚拟机console log: 1)openstack控制台图形 ...

  2. 浅谈openstack中使用linux_bridge实现vxlan网络

    openstack环境: 1 版本:ocata 2 系统:ubuntu16.04.2 3 控制节点 1个 + 计算节点 1个 4 控制节点网卡为ens33,ip = 172.171.5.200 ens ...

  3. Openstack中为虚拟机使用CDROM光驱设备

    在Libvirt里处理 在nova里处理 实际效果 怎么卸载 在Libvirt里处理 尝试了下面有几种方法,为虚拟机载入光盘文件: 1.使用ide方式挂载: virsh attach-disk {in ...

  4. OpenStack中的虚拟机(/dev/mapper/centos-root)进行磁盘扩容

    一.虚拟机上先扩展分区: 二.centos系统root登入,新建分区 2.1 [fdisk -l] 最大分区为/dev/sda2,说明新创建的分区将会是sda3(在后面的步骤会进行选择) 2.2 输入 ...

  5. 云计算---记一次黑客攻击openstack创建的虚拟机

    一:问题定位 现象: 近期发现有几台openstack云主机被修改密码并被肉鸡. 黑客操作日志: -- :: ##### root tty1 : #### -- :: top -- :: ##### ...

  6. OpenStack中Keystone的基本概念理解

    原文http://www.kankanews.com/ICkengine/archives/10788.shtml Keystone简介 Keystone(OpenStack Identity Ser ...

  7. 理解 OpenStack 高可用(HA)(2):Neutron L3 Agent HA 之 虚拟路由冗余协议(VRRP)

    本系列会分析OpenStack 的高可用性(HA)概念和解决方案: (1)OpenStack 高可用方案概述 (2)Neutron L3 Agent HA - VRRP (虚拟路由冗余协议) (3)N ...

  8. VMware 接入 Openstack — 使用 Openstack 创建 vCenter 虚拟机

    目录 目录 软件环境 前言 Openstack 接口驱动 使用 KVM 在 Compute Node 上创建虚拟机的流程 使用 VCDirver 在 vCenter 上创建虚拟机的流程 配置 vCen ...

  9. 理解 OpenStack 高可用(HA)(5):RabbitMQ HA

    本系列会分析OpenStack 的高可用性(HA)概念和解决方案: (1)OpenStack 高可用方案概述 (2)Neutron L3 Agent HA - VRRP (虚拟路由冗余协议) (3)N ...

随机推荐

  1. ARM架构--CPU的微架构

    网上确实有说ARM架构的,但是此架构泛指用ARM指令系统的CPU,而不是CPU的微架构.,硬件电路上,要用ARM指令集系统,必然硬件设计电路上要要遵循,ARM指令的特点和寻址方式,所以说高通和苹果的C ...

  2. Revit API创建详图视图

    start //创建详图视图 Transaction ts = new Transaction(doc, "http://greatverve.cnblogs.com"); ts. ...

  3. BoundingBoxUV与BoundingBoxXYZ

    start UIApplication app = commandData.Application; Document doc = app.ActiveUIDocument.Document; ); ...

  4. AngularJS使用OData请求ASP.NET Web API资源的思路

    本篇整理AngularJS使用OData请求ASP.NET Web API资源的思路. 首先给ASP.NET Web API插上OData的翅膀,通过NuGet安装OData. 然后,给control ...

  5. Task Parallel Library02,更进一步

    在前一篇中,了解了Task的基本用法 如果一个方法返回Task,Task<T>,如何获取Task的返回值,获取值的过程会阻塞线程吗? static void Main(string[] a ...

  6. Linux学习10-CentOS搭建nginx负载均衡环境

    前言 当自己的web网站访问的人越来越多,一台服务器无法满足现有的业务时,此时会想到多加几台服务器来实现负载均衡. 网站的访问量越来越大,服务器的服务模式也得进行相应的升级,怎样将同一个域名的访问分散 ...

  7. Unity3d-Particle System系统的学习(一)

    最近看了下Unity3d的粒子系统的相关视频,并且动手操作了下,感觉自己的美工技能又增进了下(开个小玩笑),发现粒子系统所需要记忆的东西还是有点多的. 所以为了不让自己遗忘某些知识点,我准备发布成博客 ...

  8. 快速排序原理及Java实现

    1.基本思想: 快速排序是我们之前学习的冒泡排序的升级,他们都属于交换类排序,都是采用不断的比较和移动来实现排序的.快速排序是一种非常高效的排序算法,它的实现,增大了记录的比较和移动的距离,将关键字较 ...

  9. 用SwipeBackLayout实现滑动关闭当前Activity

    说起SwipeBackLayout,我对它还是有一定怨念的.当时就希望能实现关闭当前Activity的效果,但完全搜不当相关的东西,最后好不容易搜到了这个SwipeBackLayout,觉得可以实现滑 ...

  10. 《Python计算机视觉编程》

    <Python计算机视觉编程> 基本信息 作者: (美)Jan Erik Solem 译者: 朱文涛 袁勇 丛书名: 图灵程序设计丛书 出版社:人民邮电出版社 ISBN:978711535 ...