我所理解的vMware 5.5之vSphere HA

在當前對可用性要求越來越高的今天，高可用成為生產環境必不可少的需求，vSphere HA就是其中一款優秀產品，以下就該產品的工作原理闡述我的理解。

一、vSphere HA功能的先決條件

要實現vSphere HA功能必須具備的四個條件是：共用儲存、網路心跳、儲存心跳、隔離地址。

1.共用儲存

vSphere HA是當Cluster中承當Master角色的主機發現其他Slaver主機宕機時，將Slaver主機上的虛擬機器在其他的Slaver主機上進行重新啟動，所以這就要求所有的Exsi必須能看到同一個共用儲存。

2.網路心跳

Cluster中的Master角色主機通過網路心跳檢測Slaver主機和VM虛擬機器的健康狀態，當我們建立vKernel埠組的時候，裡面有一個Management Traffic選項就是將該埠組宣告為網路心跳。

3.儲存心跳

有時可能我們的Esxi主機是正常的但是由於網路的故障，無法與Master進行通訊，為了避免誤判，所以從vSphere5.0以後引入了儲存心跳，當網路心跳異常時，會觸發儲存心跳的檢測，以便更準確判斷當前故障是由於網路原因還是Esxi主機宕機引起。

4.隔離地址

有時我們的Esxi主機正常，但網路心跳異常，觸發儲存心跳檢測也正常，這時候就會產生2種場景：Partition（分離）和Isolation（隔離），判定哪種情況的依據就是與看與隔離地址的通訊是否正常，所以隔離地址也是必備的條件，在大部分的應用中，隔離地址是預設閘道器，而預設閘道器經常是禁Ping的，這就需要在高階選項中設定多個隔離地址。

二、vSphere HA工作的內容

1.Master主機的選舉

每一個Cluster最多有1台Master，其餘都是Slaver。Master的選舉可由3種情況觸發：

（1）vSphere HA啟用之時。

（2）Cluster內增加新的Esxi主機，或Master主機故障。

（3）原有Cluster產生或消除Partition。

Master主機的選取依據是：

（1）儲存心跳的數量多的Esxi主機位Master，預設情況下儲存心跳都是2個，最多5個。

（2）當儲存心跳一樣時，會比較MOID值，數值大的為Master，MOID是Esxi主機加入Cluter時分配的數值，需要注意的是，它是以首字元的大小進行比較，舉例來說，2台Esxi主機的MOID值分別為90和100，它會認為首字元為9的值大於1，所以Master主機是MOID值為90的Esxi主機。

2.Master主機與Slaver主機的角色任務

（1）Master主機：維護Protect List；通過網路心跳監控Cluster內所有的Esxi Host與Virtual Machine可用性；監控所有On Protected狀態的Virtual Machine的電源狀態，當故障發生時嘗試重新啟動。

（2）Slaver主機：監控自身Host中的Virtual Machine和Master的狀態，當Master發生故障時，從新選舉出新的Master。

3.確定被vSphere HA保護的物件

當Virtual Machine或者Esxi啟動後，vCenter會檢測到它們的資訊，將其寫入Protect List並推播給Master主機，Master主機根據網路心跳和Protect List來最終確定需要實施保護的物件，vCenter與Master之間每5分鐘對比一下Protect List。以下幾種情況會視為Unprotect狀態，不會受到vSphere HA的保護：

（1）Virtual Machine或者Esxi未完全啟動。

（2）人為手動的關機。

（3）Virtual Machine或者Esxi與vCenter無法連線。

（4）Esxi處於維護模式。

（5）Virtual Machine被vMotion走了。

三、常見的vSphere HA故障場景

1.Esxi Host故障

當我們的Esxi Host主機發生故障時，vSphere HA會將故障主機上的Virtual Machine在其他的主機上重新啟動，不同於vMotion的無間斷遷移，vSphere HA它會產生一個較短的停機時間，具體的時間因故障主機的角色不同，時間也不相同，詳細分為：

（1）故障主機為Master主機，前10s進行Master檢測，從第11s開始所有的Slaver主機會認為Master主機已宕機並開始進行為時15s的新一輪選舉，產生新的Master主機，從第26s開始到第35s，新的Master主機會向vCenter讀取Protect List，所以總共的停機時間為35s+GusetOS啟動所需的時間。

（2）故障主機為Slaver主機，由於Slaver主機不需要選舉和讀取Protect List，只需要經過10s的檢測時間，所以停機時間為10s+GusetOS啟動所需的時間。

2.GuestOS故障

首先需要宣告的時Master主機通過安裝在GuestOS上的vMwareTools監控Virtual Machine的心跳，當他發現Virtual Machine心跳丟失或者VMX檔案損壞後會將該虛擬機器在其Host主機上原地重新啟動。

3.Application故障

像GusteOS一樣，要求GuestOS上必須要有vMwareTools，發生故障後會原地重新啟動Virtual Machine然後再重新啟動Application，但要求Application滿足vMware應用程式開發標準ISV，目前幾乎沒有程式支援。或者借助vMware的Application HA對應用程式進行高可用保護，目前支援SQL、Tomcat等應用程式。

4.網路心跳故障

前面在介紹預設閘道器的時候提到過，網路心跳異常有Partition和Isolation 2種情況，下面針對這2種情況作詳細介紹：

（1）Partition（分離），場景如下圖所示

起初Cluster中的網路心跳是正常的，但是突然間網路由於其他原因被分成了2塊，處於右半部份的2個Slaver主機無法連線Master主機，儲存心跳也是正常的，也可以連線隔離地址，此時Partition的條件被觸發，右邊的2台Slaver主機會進行選舉，產生出1台的Master主機，但並不意味著右半部份具備vSphere HA功能，儘管他有Master主機。前面我們提到過1個Cluster只能存在1個Master主機，新產生的這台Master主機無法從vCenter那裡獲取到Protect List，所以右半部份的vSphere HA功能是無效的。當Partition狀態消除後，2台Master之間會重新進行選舉來確定最終的Master主機。

（2）Isolation（隔離），場景如下圖所示

當網路心跳發生故障，Slaver主機無法連線Master主機，也無法連線隔離地址，但是儲存心跳是正常的，此時會觸發Isolation，Esxi會認為自己被隔離了，依照策略執行操作，策略分為leave power on，shutdown和reboot，預設情況下的策略是leave power on。

本文永久更新連結地址：http://www.linuxidc.com/Linux/2017-03/142355.htm