Chinaunix首页 | 论坛 | 博客
  • 博客访问: 9287837
  • 博文数量: 1669
  • 博客积分: 16831
  • 博客等级: 上将
  • 技术积分: 12594
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-25 07:23
个人简介

柔中带刚,刚中带柔,淫荡中富含柔和,刚猛中荡漾风骚,无坚不摧,无孔不入!

文章分类

全部博文(1669)

文章存档

2023年(4)

2022年(1)

2021年(10)

2020年(24)

2019年(4)

2018年(19)

2017年(66)

2016年(60)

2015年(49)

2014年(201)

2013年(221)

2012年(638)

2011年(372)

分类: 云计算

2014-06-16 10:13:50

CloudStack4.2.1/RHEL6.3 KVM HA高可用性测试
2014-03-24 19:25:46
原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://systems.blog.51cto.com/2500547/1382827

一、前言:

据官方称Cloudstack的HA(高可用)功能在4.2.1 SP3中已经修复一些bug,遂测试其可用性。

CloudStackHA功能分为VMHAHostHA

比较:

CS4.2.1 HA+KVM
区别
前提
备注
基于VM
启用VM的HA功能后,如果VM异常宕机(crash)
或者进程被异常终止(而并非主机原因),
CS会自动检测并尝试在当前主机重新开启该VM
1.VM被从内部(init 0, halt ,shutdown)关闭,或进程被杀掉。
2.不能使用cloudstack控制界面关闭。
如果是使用cloudstack控制界面关闭,那该VM不会进行HA
尝试。
如果是前提1中方法导致VM关闭,CS会自动重新启动该VM。
基于HOST
启用主机的HA功能后,如果物理主机异常宕机或
者出现物理损坏,CS会尝试将在该主机上面的虚
拟机,在打了HA tag的主机上面重新启动。
1.不能使用reboot,shutdown这些命令关闭物理主机。
2.必须是被动、异常关闭,而不是主动关闭主机。
3.比如:系统crash、断电,网络故障等。

原理:cloudstack-manager在内存中记录物理主机存活

状态,如果manager通过cloudstack-agent接收到物理主

机正常关闭时则把内存信息中的该物理主机T除掉,

那么主动T的情况下,是不会发生HA切换的。

即使是因为物理主机网络异常触发的HA,所有VM都会被
关闭并且在打了HA标签的主机上重新启动。
所以就是VM重新在其他服务器上启动的过程。
基于VM+HOST
2者结合,才真正实现高可用性。

生产中,推荐该做法。
基于VM和基于HOST的高可用实际是为了尽可能的考虑稳定性和服务的持续性。
面对生产环境,很难讲会发生什么样的事情,单一的VM高可用和HOST的高可用都可能带来所谓的单点故障。所以,在规划CloudStack部署时。应该考虑到各方面的隐患和潜在故障来源。网络波动,存储性能,硬件问题,系统资源不足等问题可能会造成的抽风。。。

更多介绍,大家可以看下暗黑魔君大牛的牛作:CloudStack 实现VM高可用特性

二、操作步骤

Cloudstack与Cloudplatform操作步骤一样。据Citrix的售后顾问称,其两者并无太大差别。几乎一样。

另外,这里操作步骤还是把暗黑魔君大牛的直接拿来用。 总结的挺好,我书读的不多,暗黑君可别打我。


大致如下步骤:

   1.设置全局变量中的HA标签

   2.给需要成为VM高可用特性的主机打上HA标签

   3.创建支持VM高可用特性的计算方案

   4.通过普通模板使用HA计算方案,创建实例

5.对一台启动高可用的VM进行手动关机或杀进程,测试VM高可用(虚拟机自动启动)

   6.对一台服务器进行关机操作,测试HOST高可用(其上的虚拟机自动在启动HA的主机上启动)


1.设置全局变量中的HA标签
在全局设置中,查找ha字段,并在值中填写标记:ha (按自己需求写)
修改完以后重启cloudstack-management服务:
/etc/init.d/cloudstack-management restart

2.给需要成为VM高可用特性的主机打上HA标签

没有设置ha.tag 时,在kvm主机的详细信息中,是没有”已启用高可用性“字段的。

没有这是ha.tag 之前:


设置ha.tag以后:

当前看到”已启用高可用性“值为No.
但该选项又不支持修改,如果想开启该项,很简单,只需将主机标签处填写与ha.tag一样的值即可,编辑主机标签为ha,然后保存,刷新再看,高可用会自动开启:

3.创建支持VM高可用特性的计算方案
点击 服务提供→添加计算方案
依次填写如下信息,当然根据自己实际需求填写。
注意:
1.存储类似使用shared及共享存储。
2.开启提供高可用性(VM高可用性)。
3.设置主机标签,跟ha.tag保持一致(HOST高可用性)。
如果只开启提供高可用性,不设置主机ha标签的话,只是开启了VM高可用性。
在填写了主机ha标签的话,就是开启了VM高可用性+HOST高可用性。



4.通过普通模板使用HA计算方案,创建实例

4.1.Setup
   保证提供VM高可用特性的主机处于同一集群中
4.2.Select a template
   选择模版:根据自己环境选择
4.3.Compute offering
   选择kvm-ha方案:
   此步骤一定要选择刚创建的HA方案!

4.4.Data Disk Offering
   根据自己的需求添加,本处由于做测试,不再添加。
   不再演示,略过。
4.5.Affinity
   根据自己的需求添加关联组。
  不再演示,略过。
4.6.Network
   选择自己的网络类型。
   不再演示,略过。
4.7.Review
  最后确认步骤及配置有无问题。
  方便测试,我命名虚拟机为:RHEL6U3-HA-test(可随意定义)


8.Launch VM
  开始创建虚拟机

创建好以后查看虚拟机信息:



5.对一台启动高可用的VM进行手动关机或杀进程,测试VM高可用(虚拟机自动启动)

5.1.从内部使用(init 0, halt ,shutdown)关闭,或将进程干掉。

然后30秒后查看该虚拟机是否重新起来了。

不再演示,唯一注意的是使用这种方法将虚拟机关闭,CS会自动将该VM重新启动。


5.2. 在CloudStack界面中,将该虚拟机关机。

此方法关闭虚拟机,将不再触发ha设置。


6.对一台服务器进行关机操作,测试HOST高可用(其上的虚拟机自动在启动HA的主机上重新启动)

我采用的方法是对服务器强制断电。
模拟kvm001主机异常,看该vm是否会自动跑到另外的服务器上面:
查看management.log:


大约5分钟后,查看该VM的状态:



可以看到这个时候,虚拟机已经在kvm002上面启动成功。


此时kvm001的服务器状态为关闭状态:



由于测试原因,没有截更多的图。只是大致过程。

注意:
1.如果你有2台服务器,那不要在2台主机上面同时设置主机ha标签。设置ha标签的服务器只是备用机,不能在群集里面所以的机器都是备用机。
2.在一个群集中,启用HOST高可用的服务器挂了之后,其上的vm会自动在设置ha标签的服务器上面运行。
如果在所有服务器中全部设置ha标签,巧的是SSVM+CPVM正好也在你关闭的那台服务器上面,,,那,你悲催了。因为新的SSVM+CPVM会被创建,同时会失败。看management日志会得到如下信息:
  1. NFO[storage.secondary.SecondaryStorageManagerImpl](secstorage-1:)Unable tostartsecondary storage vmforstandbycapacity,secStorageVm vmId:4,will recycle itandstartanewone

  2. WARN[cloud.consoleproxy.ConsoleProxyManagerImpl](consoleproxy-1:)Exceptionwhiletrying tostartconsoleproxy

  3. com.cloud.exception.InsufficientServerCapacityException:Unable tocreatea deploymentforVM[ConsoleProxy|v-5-VM]Scope=interfacecom.cloud.dc.DataCenter;id=1

  4.    at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:841)

  5.    at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:577)

  6.    at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:570)

  7.    at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:556)

  8.    at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:928)

  9.    at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1672)

  10.    at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157)

  11.    at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)

  12.    at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)

  13.    at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81)

  14.    at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)

  15.    atjava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

  16.    atjava.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)

  17.    atjava.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)

  18.    atjava.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)

  19.    atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

  20.    atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

  21.    atjava.lang.Thread.run(Thread.java:744)

这个报错熟悉吧。。。意思是说你服务器资源不够了等等。。。
但实际呢,你把其中一台服务器的ha标签给取消就恢复正常了。坑爹。
大概是因为如果群集里面的服务器都开启功能且设置ha标签,没有一个权重设置该vm改在哪台主机上面运行,所以就冲突了。但是报这个资源不足的错误,我表示无法接受。





本文出自 “systems” 博客,请务必保留此出处http://systems.blog.51cto.com/2500547/1382827

阅读(1038) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~