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改在哪臺主機上面運行，所以就衝突了。但是報這個資源不足的錯誤，我表示無法接受。