點開看屬性後,咱們發現是這樣node
發現了嗎?Over-committed,若是翻譯過來就是資源過載,或者說資源過量使用了,那麼這個狀態是怎麼出現的呢?算法
出現這個狀態之後會出現什麼問題?怎麼解決?api
今天咱們就談一談在SCVMM中over-committed的算法,知道SCVMM是如何確認一個羣集是否過載後,就知道如何避免它,帶來種種問題也就能解決了測試
SCVMM 2012 羣集的過載檢查主要是用來確認整個羣集是否能夠在最大容許宕機節點數(這個值咱們暫時記爲R)宕掉後,將運行在這些節點上的VM在其它可用節點上啓動,值就是上圖中配置的:Cluster reserve(nodes)。羣集先將羣集狀態預設爲overcommitted ,而後經過檢查算法運算後,再確認羣集狀態是什麼狀況。優化
那麼過載會有什麼危險呢?spa
1.一個完美的系統,有!這種符號看上去就很不爽,因此我要解決它……好吧,我是強迫症翻譯
1.系統在overcommited後,此時若是發生了節點失敗,業務就有可能不能正常failover,換句話說,有可能重要的VM根本沒有資源啓動了,想一想下場吧,誰管理這個系統誰就會死的很慘3d
2.在進行VMM的動態優化的時候,由於overcommited狀態,動態優化就不能正常的工做……這個之後我再發一篇文章專門寫VMM動態優化component
3.……暫時還沒想到
算法一共有四種,只要其中任意一種算法經過了檢查,就將羣集狀態置爲「OK」,不然保持「overcommitted 」狀態。但要說明的是:overcommited這個狀態,只是針對內存的,CPU使用咱們是無論的
如今我先把四種算法列出來,以下表:
能夠看出來評估方法有兩個,分別是proof和slot,檢測策略也有兩個,分別是simple和full,四種算法就是策略的評估方法的組合2*2=4種
下面分別說一下評估方法和策略,可是看說明可能不太明白我寫的是什麼是意思,你能夠大概過一遍,而後看下面的算法詳解,而後回來再看,應該就明白了
這個算法評估整個羣集是否知足以下條件:在R節點上的VM除去最大內存開銷的VM,都已經切換到羣集中的其它節點上,以後最大開銷內存的VM沒有可用的主機進行切換,這是一種最差狀況假設
經過一個將R節點上的最大VM作爲一個標準SLOT,而後計算 H節點的可用SLOT數,以後評估是H節點是否能夠放置R節點的全部SLOT
簡單檢查算法不考慮具體節點,只在整個羣集上作一個假設。在羣集中選定最大VM作爲標準(內存 or slot)。一樣的,在進行餘量(slot或者內存量)檢測的時候,會在全部節點內選擇最小的餘量進行統計。須要注意的是,最大VM可能與最低slot是同一個節點,可是進行簡單檢查的時候不考慮這一點
複雜檢測算法是窮舉羣集中的每一種N(R,H)組合. 進行檢測的時候, slot數 , 最大 VM , H節點的內存和SLOT統計都按具體指定的組合進行從新計算,此檢查算法最大的風險就是N(R,H)組合量有可能變的很大,具體來講就是有N^R種,爲了不這種大量的運算,這個算法只會在 N^R < 5000才使用。
這裏可能能夠簡單列一個羣集組成作爲參考
羣集值
主機節點值
這些變量值會在每一個主機上進行計算,會預先計算出來後將值代入下面的計算公式中
有幾點須要注意
1. 每一個VM須要額外的64MB用以hyper-v監控程序開銷,可是爲了方便計算,下面的算法不把這個值代入計算了
2. Stopped, saved state, paused 和running 狀態的VM也都要參與計算.
3. 若是虛擬機使用的是動態內存,則用當前分配的值用以公式計算
終於到了算法部分了,看上去好像計算複雜,其實看明白了以爲這個算法也不是特別麻煩,下面把四種算法說明一下
- SlotSize = 羣集中VM配置的最大內存值
- 在每一個主機上計算:AvailableSlots, UsedSlots ,TotalSlots
- 計算TotalSlotsRemaining=sum(主機組中H個最小TotalSlots) 注意是所有節點按TotalSlots排序後,從小到大取H個TotalSlots
- If Sum(UsedSlots) <= TotalSlotsRemaining, 則羣集沒有過載,狀態置爲OK.
須要計算各類R與H的每種組合狀況
- SlotSize = R中最大內存開銷VM
- 計算每一個主機上的AvailableSlots, UsedSlots ,TotalSlots
- TotalSlotsRemaining =H主機的TotalSlots 總數
- 若是Sum(UsedSlots) > TotalSlotsRemaining, 羣集狀態可能爲 overcommitted.
- 若是每種組合的Sum(UsedSlots) <= TotalSlotsRemaining , 羣集狀態則爲OK
- LargestClusterVM = 羣集中最大內存開銷VM
- 計算全部主機的AdditionalMemory, VM數
- TotalAdditionalSpace = sum(主機組中H個最小AdditionalMemory) ,與Slot Simple算法中的TotalSlotsRemaining值計算方式同樣- TotalOrphanedVMs = sum(最大VM*R) – LargestClusterVM.
- 若是 TotalOrphanedVMs <= TotalAdditionalSpace, 羣集狀態爲OK.
特別注意: 若是 TotalOrphanedVMs =0, LargestClusterVM > 0 and TotalAdditionalSpace = 0, 羣集可能爲overcommitted
須要計算各類R與H的每種組合狀況
- LargestClusterVM = R中最大內存開銷VM
- 在全部主機上計算AdditionalMemory, VM數- TotalAdditionalSpace = Sum (H主機AdditionalMemory)
- TotalOrphanedVMs =Sum (R主機的vm內存) – LargestClusterVM.
- 若是 TotalOrphanedVMs > TotalAdditionalSpace, 羣集可能overcommitted.
- 若是 TotalOrphanedVMs = 0, LargestClusterVM > 0 and TotalAdditionalSpace = 0, 可能overcommitted.
若是每種組合的 TotalOrphanedVMs < TotalAdditionalSpace , 羣集狀態爲OK.
算法說完了,最後說一點:以上這些算法,通通都不會把羣集狀態標記爲過載
…………
是否是以爲白白浪費了時間看這篇文章了,那我這說什麼夢話呢,明明是說怎麼檢測過載!
其實在一開始的時候已經說了,VMM對於羣集狀態都置都認爲是overcommitted的,換句話說,就是默認值是過載的,狀態算法只負責標記狀態OK。因此若是上面的算法不能證實羣集沒有過載,SCVMM就會顯示羣集狀態爲overcommitted,反之,只要有任意一個算法證實羣集未過載纔會把狀態置爲OK
此外,這裏還有一個處理邏輯:就是在進行Full Complexity檢查中,只要有一組計算結果爲可能過載或者過載(這裏也說明了上面我在進行算法說明的時候,爲何有幾處寫的是」可能」overcommit),那麼就當即中止本次檢測,羣集狀態爲overcommited
好了,終於到了例行的你們期待的demo了,若是隻說算法不進行個演示,這個概念的確比較抽象,
場景:4節點羣集,主機爲 4x 32GB hosts. 系統保留內存 9GB. 64MB的hyper-v監控須要內存不參與計算(徹底就是圖我方便), Cluster reserve (R)爲2,羣集組成以下圖,,即R=2,H=2,N=4:
Slot Simple Example
- Slot size = 8GB
- TotalSlotsRemaining = sum(2個最小slot)= (1+3) = 4
- TotalUsedSlots = 7
判斷:TotalUsedSlots > TotalSlotsRemaining, 此方法測試未經過
Slot Full Example
- TotalUsedSlots = 7
上表中每一行都表明一個組合的運算中間值和結果
判斷:能夠看到有部分TotalUsedSlots > TotalSlotsRemaining,因此這個方法檢測未經過(這裏說一句,其實不用都算出來,只要有一組數據檢測沒經過這個運算就已經結束了)
Proof Simple Example
- LargestClusterVM = 8GB
- TotalAdditionalSpace = sum(H個最小AdditionalMemory)= 0GB + 5GB = 5GB.
- TotalOrphanedVMs = (8GB + 8GB) – 8GB = 8GB.
判斷:TotalOrpanedVMs > TotalAdditionalSpace, 此方法檢測失敗
Proof Full Example
表中每一行仍是表明一組RH組合的運算中間值和結果
判斷:能夠看出每一組的 (Orphaned – LargestVM <= AdditionalMemory),條件都知足了,因此羣集狀態置爲:「OK」