【博文推薦】云平臺中的可用性集
在Azure當(dāng)中有地緣組的概念(http://maomaostyle.blog.51cto.com/2220531/1585696),之前的博文也提到過，這是一種提高“性能”或者說是盡可能減少系統(tǒng)間延遲的手段，是出于性能保障的，那么從可用性角度而言，就要提到“可用性集(Availability set)”，Availability set是目前云平臺上非常流行的一項“基本”功能，主要是提供一種高可用性的保障，在Azure當(dāng)中對虛擬機(jī)提供***99.95%的SLA承諾，注意是***，因為如果用戶期望獲得99.95%的可用性，前提是你的虛擬機(jī)實例要放置在可用性集中才可以，那么就來具體瞅瞅何為可用性集。
公有云服務(wù)無論是微軟的，阿里的或者亞馬遜的，都有類似的功能，只不過可能名稱不一樣，以Azure為例，默認(rèn)創(chuàng)建虛機(jī)時提供可用性集的配置選項，如下圖：
同樣也可以在創(chuàng)建虛擬機(jī)之后再配置可用性集，如下圖:
例如我創(chuàng)建了一個叫做AS01的可用性集，在門戶中會顯示一個提醒，也就是說，當(dāng)前可用性集中只有一臺VM，這并沒有任何意義，因為可用性集是要保證至少 兩臺或兩臺以上數(shù)量的VM放置在可用性集中才有效果，為什么呢，因為同一個可用性集中的VM會被部署在不同的RACK上面，這個RACK可以簡單理解為一 個機(jī)架，或者說是一個單故障點，那么假設(shè)你有三個VM實例，可能有一臺被部署在RACK1，另外兩臺在RACK2上，因此即便RACK2出問題宕了，但是底層會保證RACK1上仍留存一個在運行的VM實例。
在我的Azure訂閱中再創(chuàng)建一臺VM放置在之前準(zhǔn)備好的AS01可用性集中，如下圖:
此時可以看到在AS01中包含了兩臺虛擬機(jī)實例，此時vm01與vm02一定是被部署在不同的“RACK”上面的，稍后會對此做更詳盡的解釋，如下圖:
#p#
上面提到的是Azure公有云當(dāng)中的可用性集，那么在私有云中是否也具備這樣的能力呢，答案是肯定的，下圖依然是基于微軟的私有云解決方案system center，隨便找一臺云中的虛擬機(jī)查看屬性，在硬件配置中可以看到可用性集的管理，通過UI界面可以直接創(chuàng)建和分配可用性集，如下圖:
分配后通過刷新虛擬機(jī)的動作就可以顯示出當(dāng)前所屬的可用性集，通過下圖可以看出私有云方案中虛擬機(jī)可以同屬于多個可用性集，也就是說如果一套業(yè)務(wù)系統(tǒng)中的 某一臺虛擬機(jī)與其他前端或后端可復(fù)用，那么就比較適合下圖中的場景，例如我有兩個web server公用一個SQL服務(wù)器，那么web server01與SQL是一個可用性集，web server02與SQL是另外一個可用性集。
上圖中是對VMM中的虛擬機(jī)進(jìn)行可用性集管理，同樣也可以通過windows cluster進(jìn)行操作，因為在cluster中的一個屬性“antiaffinityclassnames”對應(yīng)的就是VMM中的 availability set，所以通過PowerShell對某一個對象賦值，例如下圖：
然后回到VMM進(jìn)行對該虛擬機(jī)進(jìn)行刷新，依然可以達(dá)到同樣的效果。
當(dāng)虛擬機(jī)具備了可用性集的屬性之后，那么他在遷移的時候底層架構(gòu)會做判斷，例如下圖中我有兩個節(jié)點，分別把一個可用性集中的兩臺虛擬機(jī)部署在了每一個節(jié)點 上，那么在試圖遷移其中一個VM實例時，會有提醒告訴用戶當(dāng)前主機(jī)之允許一個可用性集成員，當(dāng)然這是個warning，并不會強(qiáng)制限制后續(xù)操作。
#p#
但是從我個人角度來看，winserver+system center私有云當(dāng)中的可用性集并無法和公有云比擬，可以說完全無可比性，為什么呢，因為首先在多租戶場景中可用性集的存在是非常有必要的，但是私有云的方案并無法滿足租戶粒度的隔離，也就是說，在VMM中創(chuàng)建一個可用性集就是唯一的，但是在真正的云平臺上，不同租戶一定要在自己的隔離邊界中創(chuàng)建可用性集，而不是僅依賴平臺級的能力，那么Azure中的可用性集又是如何實現(xiàn)的呢？
首先Azure中的可用性集適用于兩個場景，一個就是計劃性維護(hù)，就是世紀(jì)互聯(lián)會做頂定期的平臺維護(hù)，好比網(wǎng)游公司的定期維護(hù)一樣，這種維護(hù)窗口內(nèi)的reboot是用戶無法選擇的，是一定要接受的。另外一種就是非計劃性維護(hù)，也就是因為的RACK宕機(jī)。
兩種維護(hù)都依賴于兩個關(guān)鍵詞，即FD(fault domain)和UD(update domain)，可以稱為故障域和更新域，故障域就好比一個單故障點，好似上面提到的“RACK”而更新域則是針對每一臺虛擬機(jī)實例，例如在計劃維護(hù)時需要對租戶的虛擬機(jī)進(jìn)行reboot，此時如果Azure發(fā)現(xiàn)某個租戶的虛擬機(jī)不在可用性集中，那么直接就reboot了，如果發(fā)現(xiàn)在一個可用性集中，就會按照UD順序來進(jìn)行重啟，而不會一下子全reboot，以此來保障業(yè)務(wù)連續(xù)性。
同理在部署時，可用性集會考慮FD的分布，來盡量打散多個VM實例，以通過在不同的故障域中放置資源來抵消單點故障帶來的破壞性影響。
因此在理解了可用性集的工作機(jī)制后，對于如何配置和規(guī)劃資源也需要動動腦筋，從***實踐上來看，對于一套應(yīng)用系統(tǒng)，不同層次中的虛擬機(jī)應(yīng)該放置在不同的可用性集中，以避免在一個可用性集中混淆了不同功能的虛擬機(jī)實例，例如下圖中若是錯誤的將Web層與Data層的虛機(jī)放置在一個可用性集中，那么在例行維護(hù)中可能會導(dǎo)致錯誤的reboot順序而產(chǎn)生業(yè)務(wù)中斷。
回到剛才的demo中，在AS01中存在兩臺虛擬機(jī)時，可以在云服務(wù)中查看到當(dāng)前的FD與UD信息，比如這里故障域和更新域都是不一樣的，下圖中分別是0和1。
而在三臺實例的時候，更新域是0，1，2，而故障域則是0，1，0，也就是說如果故障域0出現(xiàn)了問題，但至少故障域1上還會有VM02在運行，同理在reboot時候，更新域0，1，2會依照順序來啟動而不會同時發(fā)生reboot，對于一個可用性集中的更新域數(shù)量，msdn中表示是5個，第六臺虛擬機(jī)將會按照***臺來做放置計數(shù)，第七臺按照第二臺來識別，以此類推。
#################################################################
可用性集是一個非常實用且必要的功能，希望在windows和system center的下一版本中，通過私有云也能夠?qū)崿F(xiàn)更加靈活的可用性集配置。
