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

想你了的他他

　　转载地址：http://www.it165.net/admin/html/201403/2598.html

　　
　　一、前言：
　　据官方称Cloudstack的HA（高可用）功能在4.2.1 SP3中已经修复一些bug，遂测试其可用性。
　　CloudStack的HA功能分为VM的HA和Host的HA
　　比较：
CS4.2.1 HA+KVM区别前提备注基于VM启用VM的HA功能后，如果VM异常宕机（crash）或者进程被异常终止（而并非主机原因），CS会自动检测并尝试在当前主机重新开启该VM1.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+HOST2者结合，才真正实现高可用性。 生产中，推荐该做法。基于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日志会得到如下信息：
　　NFO[storage.secondary.SecondaryStorageManagerImpl](secstorage-1:)Unable tostartsecondary storage vmforstandbycapacity,secStorageVmvmId:4,will recycle itandstartanewone
　　WARN[cloud.consoleproxy.ConsoleProxyManagerImpl](consoleproxy-1:)Exceptionwhiletrying tostartconsoleproxy
　　com.cloud.exception.InsufficientServerCapacityException:Unable tocreatea deploymentforVM[ConsoleProxy|v-5-VM]Scope=interfacecom.cloud.dc.DataCenter;id=1
　　at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:841)
　　at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:577)
　　at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:570)
　　at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:556)
　　at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:928)
　　at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1672)
　　at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157)
　　at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
　　at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)
　　at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81)
　　at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)
　　atjava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
　　atjava.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
　　atjava.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
　　atjava.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
　　atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
　　atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
　　atjava.lang.Thread.run(Thread.java:744)
这个报错熟悉吧。。。意思是说你服务器资源不够了等等。。。但实际呢，你把其中一台服务器的ha标签给取消就恢复正常了。坑爹。大概是因为如果群集里面的服务器都开启功能且设置ha标签，没有一个权重设置该vm改在哪台主机上面运行，所以就冲突了。但是报这个资源不足的错误，我表示无法接受。