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