CloudStack4.2.1/RHEL6.3 KVM HA高可用性测试

一、前言：

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

CloudStack的HA功能分为VM的HA和Host的HA

比较：

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改在哪台主机上面运行，所以就冲突了。但是报这个资源不足的错误，我表示无法接受。