VMware vSphere 5.1 群集深入解析（十五）-DRS推薦嚮導
VMwarevSphere
5.1
ClusteringDeepdive
HA.DRS.StorageDRS.StretchedClusters
DuncanEpping&FrankDenneman
TranslateByTim2009/翻譯：Tim2009
目錄
版權
關於作者
知識點
前言
第一部分vSphere高可用性
第二部分vSphereDRS（分散式資源排程）
第六章DRS推薦嚮導
第三部分vSphere儲存DRS
第四部分群集架構的擴充套件
第二部分vSphereDRS（分散式資源排程）
第六章DRS推薦嚮導
一些DRS設定和功能會受到DRS遷移建議的影響，本章需要仔細看看各種設定，它們對DRS計算和負載均衡過程的影響。
虛擬機器規格大小和初始位置
當虛擬機器上電，DRS將選擇目標主機作為虛擬機器的初始放置位置，只要虛擬機器的初始位置不引起群集不平衡，DRS傾向於放置它到註冊主機上。在初始位置期間，DRS接受最壞的場景，因為它不會有虛擬機器的資源利用率的初始資料，那麼DRS就假設記憶體需求和CPU需求等於配置大小。
超大的虛擬機器的引入會造成群集的臨時不平衡，引起無謂的虛擬機器遷移活動，如果群整合員能夠提供100%的資源，可要求DRS進行群集資源碎片整理，遷移虛擬機器以騰出空間。
如果虛擬機器的實際利用率可以媲美其配置大小，額外的遷移行為被預料到，因為它們將盡快幫助群集達到一個平衡的狀態，但是，如果虛擬機器是超大的（其有效使用率比不上DRS的初始期望），通過多次DRS多次遷移，可能需要重新平衡群集。
我們都知道，許多組織仍然基於假定服務或者應用的高負載生命週期來配置虛擬機器的大小，這是歷史上物理機大小的使用策略，使用虛擬機器的好處之一就是它的靈活性，它在生命週期提供虛擬機器的大小調整，我們建議利用這些機制，並納入到你的服務目錄和日常運作。為了最有效的利用你的資源，根據當前或者不久的將來的負載來定義虛擬機器的大小。
基本設計原則
根據當前或者不久的將來的負載來定義虛擬機器的大小
MaxMovesPerHost
DRS評估群集，基於群集平衡狀態和需求來為遷移提供建議，在每次呼叫週期重複該過程，為了儘量減少CPU和記憶體的開銷，DRS建議每次DRS呼叫週期內建議限制遷移的數量，最終，在單個呼叫期間，沒有更高優先順序的建議，那麼更多的遷移將被完成，最重要的是，需求可能在呼叫期間發生改變，這會使得之前的建議過時。
vCenter基於每個遷移的平均時間，vMotion數量，DRS排程週期長度來計算每主機的限制。
PollPeriodSec：
預設情況下，PollPeriodSec-DRS呼叫週期長度-是300秒，但可以設定為60秒到3600秒之間的任意值，縮短時間間隔會因為額外的群集均衡計算而增加vCenter呼叫消耗，由於更小的時間視窗也減少了允許vMotion的數量，導致群集不平衡的週期較長，增加PollPeriodSec值會降低vCenter進行群集平衡計算的頻繁度，每個週期允許更多的vMotion操作，不幸的是，由於群集較長的評估週期，離開不平衡群集的狀態也較長。
vMotion併發：
關於vMotion提到的深度支援，vSphere5.1允許你在一臺10GbE處理能力的主機上，可以執行8個併發的vMotion，對於1GbE，限制是4個併發vMotion，但是，vSphere5.1包含了多網絡卡vMotion支援：設定多個活動的網絡卡加入vMotion埠組，允許為vMotion操作平均可用頻寬，即使是單一vMotion，也可以利用所有可用網絡卡來減少vMotion的時間。
預計總遷移時間
DRS認為從以前的遷移觀察到平均遷移時間，平均遷移時間取決於許多變數，如源和目標主機負載，虛擬機器的活動記憶體，鏈路速度，可用頻寬和vMotion過程中使用的物理網路的延遲。
基本設計原則
當設計DRS群集，考慮採用vMotion的要求，通過提供足夠的頻寬，群集可以更迅速的達到資源平衡，從而導致虛擬機器有更好的資源分配（效能也會提高）。
規則
為了控制虛擬機器的位置，vSphere5.1同時提供了虛擬機器到虛擬機器（VM-VM）和虛擬機器到主機（VM-Host）的規則
VM-VM的關聯性規則指定了虛擬機器可以呆在一起，執行在同一個主機（關聯規則）或者他們不允許在同一主機（違反規則）
VM-Host關聯性規則制定了哪些虛擬機器在一個DRS組，或者應該執行在一個主機上的DRS組
VM-VM關聯規則
一個VM-VM關聯規則指定了虛擬機器應該執行在同一個主機上
圖85：關聯規則
關聯規則用作保留虛擬交換機的網路流量，減少物理網路的流量，例如，保持同一個主機上前端和後端伺服器的應用程式，虛擬交換機裡遺留的內部應用網路流量，較少延遲和減少物理網路鏈路上的負載和元件。
關聯性規則通常建議從記憶體中獲得更大的益處，通過同一ESXi主機包含有多個相同的伺服器，透明頁的共享可能會降低實體記憶體量，但是，由於現代的CPU架構和板載記憶體控制子系統，節省的記憶體可能不會如預期的一樣大，今天，大多數CPU架構包括非統一記憶體架構（NUMA），NUMA為每個處理器提供單獨的記憶體，基於相對位置的記憶體，導致不同的記憶體器不同儲存時間，為了避免額外的延遲引起交叉CPU記憶體訪問，ESXi的兩個處理器（NUMA節點）之間不會共享頁面。
為了進一步擴大記憶體管理，如果ESXi主機配置了最新的AMD或者Intel型別的處理器，這些處理器支援硬體虛擬化技術，如Intel擴充套件頁面（EPT）和AMD的快速虛擬化索引（RVI），這些硬體擴充套件協助記憶體管理單元（MMU）的虛擬化，允許VMkernel依靠硬體跟蹤作業系統裡的記憶體對映，為了優化客戶記憶體對映和VMkernel記憶體對映之間的同步效能，大頁面被用於減少這些表裡的頁面數量，大頁面（2MB）不通過記憶體透明共享（TPS）知道大頁面被分解成小頁面（4KB），而且只發生在ESXi主機超過了記憶體閾值的時候，空閒記憶體閾值在第13章中解釋。大頁面，當為了優化整合記憶體應用了VM-VM關聯規則，NUMA和硬體虛擬化協助能減少記憶體透明共享（TPS）的有效性
VM-VM違反關聯規則
一個VM-VM違反關聯規則是為了實現相反的關聯規則：它指定了哪些虛擬機器不允許執行在同一個主機上。
圖86：違反關聯規則
假如多個虛擬機器，反關聯規則在主機發生故障後提供靈活性服務，這類服務如域控制器（ActiveDirectorydomaincontrollers），DNS伺服器和WEB伺服器群。通過單獨的主機上執行這些虛擬機器，它可以在ESXi主機發生故障期間維護服務的可用性。
另一個例子是分離網路密集負載的虛擬機器，如果他們將被放置在一臺主機上，他們可能讓該主機的網路吞吐量飽和，因為DRS不知道網路使用率，它監控CPU和記憶體的需求，一個反關聯性規則來阻止DRS這樣做，將它們放置在同一個主機上來解決這個問題。
VM-VM關聯規則-對HA的影響
注意，VMwareHA不知道VM-VM關聯和反關聯的規則，主機發生故障後，VMwareHA可能在同一個主機上重新啟動該虛擬機器，但是DRS將在下一次呼叫期間（15分鐘）糾正這個衝突。
VM-VM關聯規則-對DRS的影響
VM-VM關聯規則限制遷移的選擇和放置，更多的約束在移動性上，在確定最佳的虛擬機器位置來達到群集平衡之前，DRS將首先遵從關聯規則和糾正違反的約束。在小的群集或者大的群集都有大量的規則，這些行為可能導致欠佳的群集平衡和資源分配。雖然DRS可能暫時違反VM-VM關聯規則如果必要的虛擬機器安置，它將在下一次呼叫週期糾正衝突，如果可能會再次影響資源分配。
VM-Host關聯規則
VM-Host關聯規則指定是否虛擬機器屬於虛擬機器的DRS組或者應該執行在ESXi主機的主機DRS組。
VM-Host關聯和反關聯規則被配置被認為是強制性的規則，表現在vSphere客戶端“必須執行”或者優先規則，表現為“應該執行”。
圖87：VM-Host關聯規則
VM-Host關聯規則建立了一組虛擬機器和一組ESXi主機之間的關聯，請注意VMDRS組能獨立執行在位於主機DRS組清單中ESXi主機上，它們是不需要運行同一臺主機的主機DRS組中-除非主機組保護只有一個主機，當然。
關聯VM-Host規則可用於隔離子群集裡主機上的虛擬機器，以遵從ISV許可規定，VM-Host反關聯規則可能被用來通過不同的故障域隔離虛擬機器以提高可用性，例如故障域能夠通過一個刀鋒伺服器機箱或者塔式主機或者一組機架伺服器連線到同一個電源，VM-Host關聯規則由三部分組成。
虛擬機器DRS組
主機DRS組
指定（例如，必須/應該執行其上）
注意
VM-Host關聯規則適用於一個特定的群集，因此，他們只包含屬於特定群集裡的虛擬機器和ESXi主機。
虛擬機器DRS組：虛擬機器DRS組包括適用於虛擬機器的規則，請注意，如果一臺虛擬機器被從群集中移除，它會自動從虛擬機器DRS組移除，但是，如果虛擬機器想返回群集，它不能自動返回。
主機DRS組：主機DRS組包括適用於ESXi主機的規則，類似於虛擬機器的行為，如果一個ESXi主機被從群集移除，它會自動從主機DRS組移除，但是，如果主機想返回群集，它不能自動返回。
指定：兩種不同型別的VM-Host規則是可用的，一個VM-Host關聯規則要麼是一個“必須”規則要麼是個“應該”規則。
應該（not）執行：“應該”規則是DRS和DPM的有利規則。DRS和DPM盡最大的努力試圖滿足這些規則，但是必要情況下DRS和DPM也能違反規則
必須（not）執行：“必須”規則是HA，DRS和DPM的強制規則，它指定ESXi主機的DRS組，迫使指定的虛擬機器執行或者不執行在ESXi主機上。
有利規則
有利規則設計用來影響DRS遷移建議。如果它不過量使用主機的CPU和記憶體，DRS執行有利規則，在計算負載平衡期間，DRS執行有利規則，如果他們同其它的需求產生衝突，DRS放棄規則清單，並在無有利規則情況下重新初始化計算負載平衡。
DRS不向HA提供任何相關的有利規則，由於HA不知道這些“應該”規則，在主機發生故障的安置過程中它可能不知道違反規則，在下一次DRS呼叫週期內，DRS標識約束和問題（4分-優先順序2）遷移建議，以糾正衝突，如果可能的話，根據DRS的自動化級別，它將顯示相關建議或者自行糾正這種情況。
強制規則
強制規則適用於DRS，DPM，HA以及使用者啟動的操作，當生成或者執行操作時，DRS需要考慮強制規則，如果規則衝突，將不會產生任何建議，例如，如果與強制規則衝突，DRS將拒絕請求進入維護模式。
如果虛擬機器上設定了預留，DRS會考慮預留和強制性規則，在虛擬機器放置和開啟電源期間必須滿足這兩方面的要求，如果DRS不能滿足要求之一，虛擬機器不通電或者不產生遷移到目的主機的建議。
當強制規則被建立，當前虛擬機器的放置與規則產生衝突，DRS糾正衝突或衝突不能糾正就報告一個錯誤。
重要的是要認識到，在主機發生故障重啟虛擬機器期間，HA不會與強制規則產生衝突，HA將會故障轉移虛擬機器，如果可能，如果vCenter可用，HA將傳送一份活動清單（哪些虛擬機器需要故障轉移的清單）給vCenter，並定期檢查vCenter是否釋放了足夠的資源使HA能處理故障轉移操作，如果達到虛擬機器配置的重啟重試次數還不能重新啟動虛擬機器，它將產生一個錯誤。
使用者操作，如執行虛擬機器從外部的主機vMotion到主機DRS組，違反強制性規則將失敗，指出主機不相容。
符合強制性規則至關重要，當DRS被禁用，它們不能被刪除，值得強調：即使禁用了DRS，如果與強制規則衝突，強制規則將仍然影響HA、使用者操作，群集繼續跟蹤、報告和警告。例如如果vMotion操作與強制規則衝突，群集將拒絕vMotion操作，原因是不相容。如果管理員明確這樣做強制規則可以被禁用，如果管理員打算禁用DRS，它應該在禁用DRS之前移除強制規則，請注意，一旦DRS被禁用，vCenter不再顯示DRS選項，禁止使用者檢視和管理規則，當DRS再次啟用，規則將被顯示，禁用DRS不會孤立規則。
如果結果與強制規則衝突，DPM不會讓ESXi主機進入待機模式。此外，如果這些需求都符合強制規則，DPM才會開啟ESXi主機電源。
強制規則在虛擬機器移動位置上有更多的限制，限制虛擬機器可以在哪些主機上執行，另外，HA和DPM操作被約束，例如，強制規則：
限制DRS選擇主機去負載平衡群集
限制HA選擇主機開啟虛擬機器
限制DPM選擇主機斷電
當DRS進行群集碎片整理，當HA基於百分比的接入控制，資源碎片可能產生，在故障轉移期間，群集的資源碎片整理有HA提出請求，為了滿足這一要求，DRS移動虛擬機器為了騰出足夠的空間來啟動所有出故障的虛擬機器，在碎片整理過程中，DRS被允許使用多點遷移，也就是說建立獨立遷移鏈，例如，VM-A遷移到Host2，VM-B從host2遷移到host3，強制規則減少遷移選擇，只允許虛擬機器在DRS主機組內移動。
一個虛擬機器是多個強制規則的成員，設定了被限制只能允許在清單上兩個DRS主機組的主機上。例如規則1允許VM2執行在4個主機ESXi-01,-02,-03和ESXi-04上。規則2允許虛擬機器執行在主機ESXi-03,-04,-05和ESXi-06上，最終的結果是，虛擬機器只允許執行在相容子集的主機上，也就是ESXi-03和ESXi-04.
圖88：相容子集
規則行為
強制規則必須被遵守，有利規則被執行，如果它們不過量使用主機或者引起約束衝突，這些行為可以限制DRS在其目標實現群集負載平衡，正如你能想象的，強制關聯規則使故障排除複雜化，例如，試圖確定為什麼虛擬機器不能從高利用率的主機遷移到低利用率的主機？
當建立了一個規則與另外一個活動規則發生衝突，舊的規則覆蓋掉新的規則，DRS將禁用新規則，當建立一個新規則，一條規則衝突的訊息會顯示，新的規則將被禁用。
由於它們限制行為，強制規則應該被謹慎使用，只有在特定的情況下，例如授權請求，有利的規則能滿足可用性要求，如在刀片機箱之間或者其它故障域之間分離虛擬機器。
基本設計原則
有節制的使用VM-Host和VM-VM管理規則，規則在負載平衡計算上對其效率有影響；當規則被配置，DRS演算法具有更少的選擇。
強制管理規則應用於DRS，HA和手工操作，儘管當DRS被禁用，謹慎使用強制規則。
組織規則的影響
許多使用者建立規則，但忘記建立備份或者歸納文件。違反關聯規則可以扮演一個重要的角色，在滿足一定的SLA或者BC/DR要求和建立備份或者合理的記錄歸檔，使用PowerCli，規則可以很容易的從vCenter的資料庫中提取出來。
虛擬機器自動化級別
自動化級別時為了單個虛擬機器可以自定義去覆蓋DRS群集自動化級別，自動化級別有五種模式：
全自動
半自動
手動
預設（群集自動級別）
禁用
每個自動化級別的行為有所不同：
表21：DRS行為自動化級別
預設自動化級別不在上表的清單中，因為它是群集自動化級別，當群集自動化級別被修改，單獨的自動化級別也最好修改。
禁用自動化級別
如果一個虛擬機器的自動化級別設定為禁用，然後禁用這臺虛擬機器的DRS操作，DRS不會生成遷移建議或者生成初始化位置的建議，虛擬機器將在註冊主機上啟動，一個啟動的虛擬機器自動化級別設定為禁用，但還是消耗群集資源，將影響DRS負載平衡計算，在計算產生建議期間，DRS忽略設定了自動化級別禁用的虛擬機器，並選擇主機上的其它虛擬機器，如果DRS必須在自動化級別的虛擬機器和手動自動級別的虛擬機器之間選擇，DRS偏愛自動性的虛擬機器超過手動級別的虛擬機器。
手動自動級別
當一個虛擬機器被配置了手動自動級別，DRS既產生初始位置建議，也產生負載平衡遷移建議，但是使用者需要手工批准這些建議。
半自動級別
在部分自動級別下DRS自動為虛擬機器安排位置，但是生成的遷移建議需要手工批准。
手工和半自動級別對群集平衡的影響
當任何其它自動級別被禁用，DRS假定使用者將手工接收產生的遷移建議，這意味著DRS將繼續將虛擬機器放在群集平衡和資源利用率的分析中，在分析過程中，DRS模擬群集內虛擬機器的移動，每個沒有被禁用的虛擬機器，將包括在選擇遷移建議的過程中，如果某一特定的虛擬機器移動提供了高的收益和比較低的風險，DRS會為移動生成一個遷移建議，因為DRS被限制一個特定數目的遷移，它可能放棄關於虛擬機器的幾乎相似的建議，現在就有問題在這個場景下，當這個虛擬機器goodness級別與預設自動接近，建議可能遷移的虛擬機器配置手工自動級別，如果使用者監控每個每次DRS呼叫就應該沒有問題，當問題發生重新檢查遷移建議，這是不現實的期望如同DRS每5分鐘執行一次。
我們已經看到了這樣一個場景，一組虛擬機器配置了手工模式，在資源過量使用的狀態下，它變成了虛擬機器的陷阱，使用者不監控vCenter中的DRS選項和已經遺失的建議，這導致虛擬機器本身資源匱乏，而且會更糟，它影響了群集裡的多個虛擬機器，因為DRS生成了遷移建議，它放棄其它合適的移動，且不能達到最佳的平衡。
禁用半自動級別與禁用手動級別
禁用DRS對虛擬機器在其它操作和資源可用性上有一些負面的影響，如將主機置於維護模式或者在進入維護模式之後給虛擬機器加電，同時選中註冊主機，當合適的虛擬機器可用它可能在該主機上開啟且擁有足夠的資源，但是禁用自動級別避免的之前描述的場景的發生。
半自動級別自動將虛擬機器至於合適的位置，而手工模式建議將虛擬機器至於合適的主機，半自動在選擇位置時提供最少的運營開銷，但在正常的操作期間手工級別產生大量的開銷。
風險與回報
選擇一個自動級別幾乎是一個風險與回報的遊戲，設定自動級別禁用可能影響一些操作的程式，但是當生成遷移建議時允許DRS去忽略虛擬機器，並拿出群集平衡替代解決方案。設定自動級別為半自動或者手動將提供你更好的初始化位置建議和更簡化的維護模式過程，但是當vCenter中DRS選項脫離監控，將產生不平衡的風險和資源匱乏情況。
虛擬化vCenter的思考
大多數管理員在有災難發生的情況跟蹤虛擬化vCenterServer。當災難發生後，例如資料中心範圍的斷電，vCenter虛擬機器已經註冊到ESXi主機，你只需要啟動該主機，然後手工開啟vCenter虛擬機器的電源即可。
這種方法的一個替代方法就是將vCenter置於資料儲存上，在災難發生後在隨機的一臺ESXi主機上註冊和開啟該虛擬機器，這樣做的工作量比vCenterServer虛擬機器禁用DRS要大，但是在正常操作期間它可能提供更好的效能。
由於擴充套件虛擬架構和增加相關功能，vCenter在每天的運營管理中越來越重要，合適的場景中保證良好的效能比額外的功能更有必要。但兩種方法都有優點。
總的來說，你應該安裝您的環境和舒適度來選擇自動化級別，嘗試虛擬機器儘可能的在DRS全自動的模式下，在虛擬機器不是全自動模式之前，DRS認為這些虛擬機器的遷移是為了群集負載平衡。
VM自動化級別對DRS負載平衡計算的影響
同大家認為的相反，虛擬機器設定自動化級別禁用仍然會影響當前主機負載標準偏差（CHLSD）的計算（通過主機的容量CHLSD作為活動工作負載被分配），DRS不需要知道虛擬機器在該階段的自動化級別。在計算推薦建議期間，DRS忽略虛擬機器設定了禁用自動化級別，並選擇主機上的其它虛擬機器，如果DRS必須在虛擬機器設定自動化級別和手工自動級別中選擇，它會選擇設定虛擬機器自動多過設定虛擬機器手動。
轉載於:https://blog.51cto.com/virtualbox/1199802