內容預覽：
HA，High Availability，中文翻譯為高可用。
其運行機制是監控群集中的ESXi主機及虛擬機，通過配置合適的策略，當群集中的ESXi主機或虛擬機發生故障，可以自動到其他的ESXi主機上進行重新啟動，最大限度保證重要服務不中斷。
2.1 針對ESXi主機硬件故障的保護（HA和FT技術）
2.2 針對零停機計划內的維護（vMotion）
2.3 針對ESXi主機計划外停機和災難的保護（HA和FT技術）
3.1. HA運行的基本原理
當在群集啟用HA時，系統會自動選舉一台ESXi主機作為首選主機（也稱為Master主機），其余的ESXi主機作為從屬主機（也稱為Slave主機）。Master主機與vCenter Server進行通信，並監控所有受保護的從屬主機（也稱為Slave主機）的狀態。Master主機使用管理網絡和數據存儲檢測信號來確定故障的類型。當不同類型的ESXi主機故障時，Master主機檢測並相應地處理故障，讓虛擬機重新啟動。當Master主機本身出現故障時，Slave主機會重新選舉產生Master主機。
3.2. Master/Slave選舉機制
3.2.1). Master/Slave主機的選舉是存儲最多的ESXi主機，如果ESXi主機的存儲相同時，會使用MOID(Managed Objective ID,數值大的為Master，)來進行選舉。當Master主機產生后，會通告給其他Slave主機。當選舉產生的Master主機故障時，會重新選舉產生新的Master主機
3.2.2). Master主機監控所有Slave主機，當Slave主機出現故障時重啟啟動虛擬機
3.2.3). Master主機監控所有被保護虛擬機的電源狀態，如果被保護的虛擬機出現故障，將重啟虛擬機
3.2.4). Master主機發送心跳信息給Slave主機，讓Slave主機知道Master的存在
3.2.5). Master主機執行狀態信息給vCenter Server，vCenter Server正常情況下只和Master主機通信
3.2.6). Slave主機監視本地運行的虛擬機狀態，把這些虛擬機運行狀態的顯著變化發送給Master主機
3.2.7). Slave主機監控Master主機的健康狀態，如果Master主機出現故障，Slave主機將參與與Master主機的選舉
3.3. Esxi主機的故障類型
3.3.1) 主機停止運行
主機由於物理硬件故障或電源等原因引起故障
3.3.2) 主機與網絡隔離
一個或多個slave丟失了所有的管理網絡連接，這樣的slave既不能聯系到master也不能聯系到其他ESXi hosts。這種情況下，slave主機通過存儲網絡來通知master，它已經是隔離狀態。
我們知道HA使用管理網絡及存儲設備進行通信監測狀態，如果Master主機不能通過管理網絡與Slave主機通信，那么會通過存儲來確認ESXi主機是否存活，這樣的機制可以讓HA判斷主機是否處於網絡隔離狀態。在這種情況下，Slave主機通過heartbeat datastores來通知Master主機它已經是隔離狀態，具體上這個Slave是通過一個特殊的二進制文件--host-Xpoweron，來通知Master主機能夠采取適當的措施來確保保護虛擬機。Master主機看到這個標志后，就知道Slave主機已經是隔離狀態，然后Master主機通過HA鎖定其他文件（datastores上的其他文件），當Slave主機看到這些文件已經被鎖定，就知道Master主機正在重新啟動虛擬機，然后Slave主機可以執行配置過的隔離響應動作（如關機或者關閉電源）
3.3.3) 主機與網絡分區
一個或多個slave通過管理網絡聯系不到master，這樣的slave雖不能聯系到master但能聯系到其他ESXi hosts，這種情況下，vSphere HA能夠了使用存儲網絡來檢測分離的主機是否存活以及否要保護它們里面的虛擬機。
3.4. ESXi主機故障的響應方式
3.4.1) 虛擬機重新啟動優先級
3.4.2) 主機隔離響應
4.1. esxi host 物理服務器故障
4.2. 虛擬機故障
4.3. 虛擬機操作系統故障
4.4. Application 故障
5.1. 按插槽及插槽大小
5.1.1). 插槽大小由每個虛擬機的CPU和內存決定，取CPU和內存的需求最大值，通過上圖虛擬機可以得知插槽大小為2GHz CPU和2GB內存。
5.1.2). HA計算CPU組件的方法是先獲取每台已打開電源虛擬機的CPU預留，如果沒有為虛擬機指定CPU預留，則系統會為其分配一個默認值32MHz。
5.1.3). HA計算內存組件的方法是先獲取每台已打開電源虛擬機的內存預留，如果沒有為虛擬機指定內存預留，則系統會為其分配一個默認值。
5.1.4). 插槽計算：用主機的CPU資源數除以插槽大小的CPU組件，然后將結果化整。對主機內存資源數進行同樣的計算。然后，比較這兩個數字，較小的那個數字即為主機可以支持的插槽數。
5.2 接入控制策略--按靜態主機數量定義故障切換容量
所謂按靜態主機數量定義故障切換容量策略，就是允許HA群集中幾台ESXi主機可以發生故障，如果設置為1，當群集中有1台ESXi主機發生故障時，故障ESXi主機上的虛擬機會重新啟動。同時這個策略需要使用插槽及插槽大小的概念。
5.3 接入控制策略--通過預留一定百分比的群集資源來定義故障切換容量
5.3.1). 計算出主機的CPU和內存資源總和，從而得出虛擬機可使用的主機資源總數。
5.3.2). 生產環境需要注意的是，預留資源越多，ESXi主機在非故障切換時能夠運行的虛擬機就會減少。
5.4 接入控制策略--使用指定故障切換主機
4.4.1). 在主機發生故障時，vSphere HA 將嘗試在任一指定的故障切換主機上重新啟動其虛擬機。如果不能使用此方法（例如，故障切換主機發生故障或者資源不足時），則 vSphere HA 會嘗試在群集內的其他主機上重新啟動這些虛擬機。
4.4.2). 為了確保故障切換主機上擁有可用的空閑容量，將阻止您打開虛擬機電源或使用 vMotion 將虛擬機遷移到故障切換主機。而且，為了保持負載平衡，DRS 也不會使用故障切換主機。
選擇接入控制策略時，應當考慮的因素很多。應當基於可用性需求和群集的特性選擇 vSphere HA 接入控制策略。
6.1） 選擇什么樣的接入控制策略？
生產環境比較常見的是選擇按靜態主機數量定義故障切換容量、預留一定百分比的群集資源來定義故障切換容量這兩種策略。
選擇前者的話，如果群集中某一台虛擬機所需的CPU或內存資源較大(3,3)，而其他虛擬機所需的CPU或內存資源比較平均，會影響到ESXi主機支持的插槽數量計算。
因此，如果群集中虛擬機所需的CPU和內存資源差距較大，推薦使用使用預留一定百分比的群集資源來定義故障切換容量策略。
6.2） 避免資源碎片
“群集資源的百分比”策略不解決資源碎片問題。
通過將插槽定義為虛擬機最大預留值，“群集允許的主機故障數目”策略的默認配置可避免資源碎片。
使用“指定故障切換主機”策略不會出現資源碎片，因為該策略會為故障切換預留主機。
6.3） 故障切換資源預留的靈活性
為故障切換保護預留群集資源時，接入控制策略所提供的控制粒度會有所不同。“群集允許的主機故障數目”策略允許設置多個主機作為故障切換級別。“群集資源的百分比”策略最多允許指定 100% 的群集 CPU 或內存資源用於故障切換。通過“指定故障切換主機”策略可以指定一組故障切換主機。
6.4） 群集的異構性
從虛擬機資源預留和主機總資源容量方面而言，群集可以異構。在異構群集內，“群集允許的主機故障數目”策略可能過於保守，因為在定義插槽大小時它僅考慮最大虛擬機預留，而在計算當前故障切換容量時也假設最大主機發生故障。其他兩個接入控制策略不受群集異構性影響。
7.1) vCenter Server
HA這個高級特性必須依賴於vCenter Server才能實現，沒有vCenter Server將無法啟用HA
7.2) 啟用vMotion
當ESXi主機發生故障時，HA會選擇新的ESXi主機對虛擬機進行重新啟動， 這個過程實質是遷移主機，而遷移主機使用的技術是vMotion，也就是說啟用vMotion是前提。
7.3) 網絡冗余
HA本身要求網絡具有冗余功能，特別是管理網絡，如果管理網絡沒有冗余，HA會給出對應的配置錯誤提示。
7.4) 安裝VMware Tools
它不僅是添加了虛擬機的驅動程序，一些HA的檢測機制也是通過VMware Tools完成的。
7.5) 群集ESXi主機數量
將多台ESXi主機添加到一個群集的目的，是可以統一管理及使用高級特性。但是每台ESXi主機的資源是有限的，必須合適考慮群集中ESXi主機的數量，特別是這個群集中ESXi主機數量少於5台，而運行的虛擬機數量超過50台的情況需要特別注意。
當某台ESXi主機發生物理故障，上面的虛擬機需要在其他ESXi主機上重新啟動時，要考慮其他ESXi主機資源使用情況。如果資源不夠，可能會導致虛擬機無法重新啟動，或啟動后性能較低。
8.1) 如果啟用虛擬機組件保護（VMCP），vSphere HA可以檢測到數據存儲可訪問性故障，並為受影響的虛擬機提供自動恢復。
當發生數據存儲可訪問性故障時，受影響的主機無法再訪問特定數據存儲的存儲路徑，可確定vSphere HA將對此類故障作出的響應，從創建事件警報到虛擬機在其他主機上重新啟動。
8.2) 錯誤狀況和虛擬機響應選項
8.2.1) 虛擬機重新啟動優先級
重新啟動優先級用於確定主機發生故障或主機隔離時虛擬機的重新啟動順序。優先級較高的虛擬機將首先啟動。
8.2.2) 針對主機隔離的響應
主機內的虛擬機將在正常運行的其他主機上重新啟動
8.3) 存在兩種類型的數據存儲可訪問性故障
8.3.1) PDL（permanent device loss 永久設備丟失）：是在存儲設備報告主機無法再訪問數據存儲時發生的不可恢復的可訪問性丟失，如果不關閉虛擬機的電源，此狀況將無法恢復。
8.3.2) APD（All-Paths-Down 全部路徑異常）：暫時性或未知的可訪問性丟失，或I/O處理中的任何其他未識別的延遲，此類型的可訪問性問題是可恢復的。
a). 關閉虛擬機電源再重新啟動虛擬機（保守）：
受影響的Vms會被關閉電源，然后在連接正常的ESXi主機上重啟。如果故障主機無法與Master主機通訊則將無法激活
b). 關閉虛擬機電源再重新啟動虛擬機（積極）：
受影響的Vms會被關閉電源，無論是否有主機可以通過重啟承載這些Vms。不論Master主機是否存在，是否能和其它主機通訊以及是否有足夠的資源
8.3.3) APD 的虛擬機故障切換延遲：140S以后
8.4) VMCP恢復時間軸
8.4.1) 以下時間軸以圖形方式顯示VMCP如何從存儲故障進行恢復
► T=0；檢測到存儲故障，vSphere HA將啟動恢復過程。對於PDL事件，將立即啟動工作流並重新啟動群集中正常主機上的虛擬機。如果是APD事件導致存儲丟失。APD超時定時器將啟動（默認為140秒）。
► T=140s：主機將聲明APD超時，到無響應存儲設備的非虛擬機I/O都將失敗。
► 介於T=140s和320s之間：這是APD的虛擬機故障延遲定義的時間段，默認為3分鍾，長時間無法訪問存儲可能導致客戶機應用程序不穩定，如果此時間段的APD己清除，重置虛擬機的選項將可用。
► T=320s：經過APD的虛擬機故障切換延遲時間（APD超時后3分鍾）后，vSphere HA將啟動APD恢復響應。
8.5) 虛擬機監控敏感度：
8.5.1) 故障時間間隔（30S）：如果在30S的時間間隔內未收到主機與虛擬機間的檢測信號，vSphere HA會重新啟動虛擬機。
8.5.2) 最短正常運行時間（120S）：發現故障后，不會立即重啟虛擬機，先進行120S的和存儲I/O的信息監測，以免故障誤判。das.iostatsinterval
8.5.3) 每個虛擬機的最大重置次數（3次）
為了避免因非瞬態錯誤而反復重置虛擬機，默認情況下，在某個可配置的時間間隔內將對虛擬機僅重置三次，在對虛擬機執行過三次重置后，指定的時間結束之前，vSphere HA 不會在后續故障出現后進一步嘗試重置虛擬機，可以使用每個虛擬機的最大重置次數自定義設置來配置重置次數。
8.5.4) 最大重置時間段（1小時）
