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