VMware vSphere 5.1 群集深入解析（二十八）

VMware vSphere

5.1

Clustering Deepdive

HA.DRS.Storage DRS.Stretched Clusters

Duncan Epping &Frank Denneman

Translate By Tim2009 / 翻譯：Tim2009

目錄

版權

關于作者

知識點

前言

第一部分 vSphere高可用性

第一章 介紹vSphere高可用性

第二章 高可用組件

第三章 基本概念

第四章 重新啟動虛擬機

第五章 增加高可用靈活性（網絡冗余）

第六章 訪問控制

第七章 虛擬機和應用監控

第八章 集成

第九章 匯總

第二部分 vSphere DRS（分布式資源調度）

第一章 vSphere DRS介紹

第二章 vMotion和EVC

第三章 DRS動態配額

第四章 資源池與控制

第五章 DRS計算推薦

第六章 DRS推薦向導

第七章 DPM介紹

第八章 DPM計算推薦

第九章 DPM推薦向導

第十章 匯總

第三部分 vSphere存儲DRS

第一章 vSphere存儲DRS介紹

第二章 存儲DRS算法

第三章 存儲I/O控制（SIOC）

第四章 數據存儲配置

第五章 數據存儲架構與設計

第六章 對存儲vMotion的影響

第七章 關聯性

第八章 數據存儲維護模式

第九章 總結匯總

第四部分 群集架構的擴展

第一章 群集架構的擴展

第二章 vSphere配置

第三章 故障排錯

第四章 總結匯總

第五章 附錄

第四部分 群集架構的擴展

第二章 vSphere配置

這種情況下，我們的重點是擴展群集環境中vSphere HA，vSphere DRS和存儲DRS之間的關系，以及圍繞這些vSphere組件在設計和運作方面經常被忽視和低估的考慮。歷來很多重點放在存儲層，而很少考慮工作負載如何配置和管理。

如我們之前提到的，擴展群集關鍵的驅動力是工作負載平衡和災難避免。怎樣確認我們的環境是處在合理的平衡中而沒有影響可用性或者大幅減少操作開銷？我們怎樣建立配置需求和持續管理過程，我們怎樣定期驗證我們仍然滿足我們的需求？定義和遵從需求失敗會使環境混亂難以管理、各種故障場景難以預測，也會希望它來幫助你。事實上，忽略過程會導致故障事件中產生額外的停機時間。

這三個VMware vSphere功能每一個都有特別的配置需求，能加強你環境的彈性和工作負載的可用性，通過這一部分，架構建議將產生，這些建議將基于測試期間的各種場景發現的問題。每一個故障場景測試在接下來的章節中都被記錄，請記住，這些故障場景直接應用這些實例的配置，基于你的實施和配置選項你的環境可能會受到額外故障。

vSphere HA 特性

我們的實例環境中有4臺主機和一個統一擴展存儲解決方案。當全部站點發生故障是需要考慮彈性架構的一個場景，我們建議開啟接入控制（Admission Control），工作負載的可用性是許多擴展群集環境的主要驅動力，它建議有足夠的容量允許全站點故障，盡管如此，兩個站點將平等的分配主機，來確保所有的工作負載能通過HA重新開始，建議配置接入控制策略為50%。

我們建議使用基于百分比的策略來提供架構的靈活性和減少操作開銷，盡管新主機加入環境中沒有必要改變百分比，而且沒有整合率偏差，導致使用虛擬機級別預留資源的風險，更多詳情請見第6章。

HA使用心跳檢測機制來驗證主機的狀態，如第3章解釋的有兩個心跳檢測機制；稱為網絡和數據存儲心跳檢測，網絡心跳檢測時HA驗證主機的主要機制，數據存儲心跳檢測是一旦網絡心跳檢測失敗通過HA來確定主機狀態的另一種機制。

如果主機沒有收到任何的心跳檢測，它檢測是否僅僅是從其它主機隔離或者網絡中完全隔離。這個過程包括了Ping主機的默認網關，或者一個或者多個手工設置的隔離地址來代替主機網關，從而加強隔離檢測的可靠性。我們建議指定最少兩個額外的隔離地址并且每個地址能到本地網絡，即使在站點之間連接失敗的情況下，開啟HA能夠驗證完整的網絡隔離，并提供冗余允許一個IP故障。

但是，如果主機被隔離，vSphere HA觸發響應，這在之前有解釋過，叫做隔離響應，當主機同管理網絡之間的連接斷開，觸發隔離響應來保證妥善管理虛擬機。隔離響應在第三章有深入討論，根據使用不同的存儲和物理網絡完成，隔離響應用來在需要時做出決定，我們提到在第四章，表3中支持的決定。

在我們的測試環境中，一部分這些地址將屬于Frimley 數據中心，另一部分屬于Bluefine數據中心，屏幕截圖顯示了怎樣配置多個隔離地址的實例，vSphereHA高級設置使用das.isolationaddress，更詳細的如何配置可以在KB 文章 1002117中找到。

為了vSphere HA數據存儲心跳在任何故障場景中都運行正常，我們建議增加數據存儲心跳的數量為2-4，最少的數據存儲心跳為2，最大為5，擴展群集環境中建議4，這樣將提供本地的全冗余。還建議定義4個指定數據存儲為優先數據存儲心跳，選擇一個站點的2個然后選擇另一個站點的2個。這樣做即使站點之間發生連接故障也允許vSphere HA的數據存儲心跳。如果站點之間發生連接故障后站點還存在部分網絡，這些數據存儲將非常有用。

數據存儲心跳的數量能通過HA高級設置das.heartbeatDsPerHost.進行增加。

我們建議使用“選擇考慮加入我的首選項的任何群集數據存儲”，它將允許vSphere HA選擇任意4個設計的數據存儲，我們手工選擇變得不可用，原因是如果我們建議的站點間4個心跳連接失敗，vCenter將最終在一個站點上，這樣另一個站點的主機就沒有機會HA來改變數據存儲心跳。這個設置的截屏如下。

圖163：數據存儲心跳

vSphere 5.0 U1永久設備丟失（PDL）增強

vSphere 5.0 U1版本中，介紹了永久設備丟失（PDL）的條件—允許數據存儲上的虛擬機自動故障轉移，我們將在其中一個故障場景中展示一個PDL環境，溝通的環境是通過陣列控制器經過一個指定的SCSI代碼到ESXi，這些條件聲明一個設備（LUN）將不可用，并且可能是永久不可用。當存儲管理員設置這個LUN脫機，這個實例場景通過陣列通信，當撤回訪問LUN，不統一的環境發生故障期間用來確定ESXi進行合適的行動，應該注意的是當全部存儲發生故障，可能生成永久磁盤丟失的情況，在陣列和ESXi主機之間沒有通信的可能，這個狀態通過ESXi主機來識別當做所有路徑斷開（APD）。

重要的是認識到接下來的設置只應用PDL環境，而不是APD環境，在我們的故障環境中，我們將論證兩種環境的不同行為。

為了允許vSphere HA響應PDL環境，vSphere U1里介紹了兩個高級設置，第一個主機設置是disk.terminateVMOnPDL Default。這個設置在/etc/vmware/settings里配置，由默認設置為“True”，注意這是每主機的設置，主機需要重新啟動這個設置才生效，當數據存儲進入了PDL狀態，這個設置確保殺掉虛擬機。PDL環境中一旦殺掉虛擬機，數據存儲就磁盤I/O初始化。如果虛擬機的文件沒有在同一個數據存儲上，并且PDL存在其中一個數據存儲上，通過HA虛擬機可能不會重新啟動，vSphere 5.1里修正了這個問題，為了確保PDL環境中能通過HA進行遷移，我們建議設置disk.terminateVMonPDL Default 為“True”，并將虛擬機文件放置單個數據存儲上，請注意當數據存儲沒有產生I/O，虛擬機只是被殺掉，虛擬機可以恢復活動的。正在運行密集內存負載而數據存儲沒有產生I/O的虛擬機可能恢復活動狀態。

第二個設置是vSphere HA的高級設置，稱之為das.maskCleanShutdown Enabled。vSphere 5.0 U1中介紹了這個設置，默認是禁用的，需要設置你的HA群集為“True”，這個設置允許HA觸發PDL環境中自動殺掉的虛擬機重啟，HA不能區分虛擬機是被PDL殺掉還是被管理員關閉，設置標記“True”假定是前者。注意在APD期間用戶關機將被行為標記

我們建議設置das.maskCleanShutdown Enabled 為“True”，為了限制PDL環境數據存儲上虛擬機的停機時間，當das.maskCleanShutdown Enabled沒有設置“True”，PDL環境也存在，disk.terminateVMonPDL Default被設置為“True”,殺掉虛擬機后，虛擬機重新啟動不會發生，HA將假定虛擬機是管理員斷電（或者關閉）。

vSphere DRS

vSphere DRS在很多環境中用來分配群集負載。vSphere DRS提供很多其它功能來幫助擴展環境，我們建議開啟vSphere DRS允許群集的主機之間的負載平衡，vSphere DRS 負載平衡計算是基于CPU和內存的使用情況，同樣，關于存儲和網絡資源利用率和流量也必須小心照顧，為了避免擴展群集環境中非預期的存儲和網絡流量開銷，我們建議執行vSphere DRS關聯規則來允許合乎邏輯和可預測的分開虛擬機，這將幫我們提高可用性，負責架構服務的AD，DNS虛擬機，這將有助于確保這些服務跨站點分離。

vSphere DRS關聯規則還幫助阻止存儲不要的停機時間和網絡流量過載，我們建議調整vSphere VM-Host的存儲配置關聯規則，我們的意思設置VM-Host關聯規則，這樣虛擬機偏向于運行在同一站點的主機上，同時數據存儲陣列的主要讀/寫節點進行配置。例如，我們的測試配置中，虛擬機存儲在Frimley-01數據存儲設置了VM-Host關聯規則是偏向于Frimley數據中心的主機。這樣確保了站點間網絡連接發生故障時，虛擬機不會斷開與存儲系統的連接。VM-Host關聯規則配置取決于這些建議，從而確保虛擬機呆在主數據存儲本地。巧合的是所有的讀I/O來自于它們站點的本地虛擬機，注意：不同存儲廠商使用不同的技術來描述LUN到陣列或者控制器的關系，在這個章節我們將使用通用術語“Storage Site Affinity”，“Storage Site Affinity”意味著偏向于LUN的本地讀寫訪問。

我們建議執行“should rules”，這些在HA發生故障時都能夠被沖突，服務的可用性應該一直勝過性能。在“Must rule”情況下，HA將不會同設置的規則沖突，在站點或主機發生故障時它可能導致服務中斷。一個數據中心發生故障的場景，“Must rules”將使它不可能為vSphere HA重啟虛擬機，同時他們沒有關聯規則請求來允許虛擬機在其它數據中心的主機上開啟。vSphere DRS同HA的溝通這些規則，把他們存儲在允許啟動的兼容性列表。vSphere DRS還有一個注意的地方，在某些情況下，如果大量的主機不平衡和激進建議設置，會與“Should rule”沖突。盡管非常罕見，我們建議監控對你的工作負載產生可用性和性能有沖突的規則。

我們建議手工定義創建站點的一組主機，基于數據存儲關聯規則添加虛擬機到這個站點上，在我們的場景中只有限制數量的虛擬機被發布，我們建議使用vCenter Orchestrator或者Power CLI自動定義站點關聯規則，如果沒有選擇自動，我們推薦使用一個通用的命名慣例，簡化創建這些組，我們建議這些組定期驗證，來確保屬于組的虛擬機有正確的站點關聯規則。

接下來的截屏描述了用于該場景的配置，在第一張截圖中，所有的虛擬機應保持在Bluefin本地的虛擬機組內。

圖164：DRS組-虛擬機

接下來，創建一個本地包括所有主機的Bluefin 主機組。

圖165：DRS組-主機

最終，Bluefin本地創建好了一個新的規則，定義了連接到主機組虛擬機組“should run on”規則

圖166：VM-Host規則

兩邊本地都應該完成，直接導致了4個組合2個規則。

圖167：結果-管理規則

調整關聯性規則沖突

DRS分配了高優先級來調整關聯性規則沖突，在調用期間，DRS的主要目標是調整任何沖突和為群集主機組主機清單上虛擬機生成遷移建議，這些移動的優先級比負載平衡高，所以將在負載平衡之前開始虛擬機遷移。

DRS默認每5分鐘調用一次，但是如果群集檢測到更改DRS還是會觸發，當主機重新連接上群集，DRS被調用，并生成建議來調整任何識別的沖突。我們的測試展示了在主機重新連接群集后的30秒內DRS生成建議來調整關聯規則沖突。注意DRS限制了vMotion網絡的總吞吐量，這意味著在所有的管理規則沖突被調整之前，可能需要多次調用。

vSphere Storage DRS

當定義的性能或者容量閾值超出，Storage DRS從管理員角度和虛擬機、磁盤平衡來考慮啟用激進的單一數據存儲，存儲DRS確保你的工作負載中足夠的磁盤資源可用，我們建議開啟存儲DRS。

存儲DRS使用存儲vMotion在數據存儲群集內的數據存儲上來遷移虛擬機，由于底層擴展存儲系統使用同步復制，一個遷移或者一系列遷移將對重復流量有影響，導致在移動磁盤的時候出現網絡資源爭用，可能引起虛擬機臨時不可用。從站點的角度，如果虛擬機不一起遷移它們的磁盤，在同一訪問配置中遷移漫游數據存儲還可能導致額外的I/O延遲。例如，如果Frimley主機上的虛擬機有磁盤遷移到Bluefin的數據存儲上，它將繼續操作，但可能降低性能。虛擬機讀取磁盤受制于站點B讀取虛擬iSCSI IP延遲的增加和受制于站點間的延遲。

當遷移發生時能夠控制，我們建議配置存儲DRS手工模式，這允許人工驗證每個建議，并允許在非峰值時間應用建議，同時獲得操作的益處和初始化位置的效率。

我們建議基于存儲配置遵從存儲站點關聯來創建數據存儲群集，站點A關聯的數據存儲不能同站點B的數據存儲相互混合。這將允許操作的一致性和緩和DRS VM-Host關聯規則的創建和持續。因此當數據存儲群集和定義存儲站點關聯邊界之間的虛擬機被遷移，建議來保證所有的vSphere DRS VM-Host關聯規則被更新。我們建議調整數據存儲群集和VM-Host關聯規則的命名約定，以簡化配置和管理流程。

命名約定在我們的測試中用來給數據存儲和數據存儲群集一個特別的站點名稱，從而簡化站點上發布虛擬機的DRS主機關聯性。在我們的站點“Bluefin”和“Frimley”里的站點特指存儲見下圖。請注意vCenter映射功能不能用來查看存儲當前的站點關聯，同時也不能顯示數據存儲群集的對象。

圖168：數據存儲群集架構