930
了解單點故障以及雲上高可用和容災
引言
故障，不管它發生的概率有多低，終歸還是會發生的。
——墨菲定律
概念
單點故障
顧名思義，單個點發生的故障，擴展到雲上的環境，指的就是單個節點發生的故障導致整個鏈路癱瘓。這裏的節點可以是一台服務器，一個數據庫，一台網絡設備，乃至一個應用程序。
打個簡單的比方，一個加工廠流水線隻有甲乙丙丁四名員工，一個加工需求進來，需要甲乙丙丁依次處理方能完成，此時針對流水線的作業，四名員工就是鏈路的單點，任何一人請假或者離職，流水線作業就無法正常，此時就形成了單點故障。
高可用
HA（High Availability）。字麵意思，就是保障高可用性。這裏的可用性，我們通常用平均無故障時間來度量，可以說平均運行多長時間才會發生一次故障，也可以以平均一個周期內非故障時間與總時間的比例來表示。
容災
DR（Disaster Recovery）。字麵意思是災難恢複。在雲上環境我們可以理解為保障災難情況下係統和業務的正常運行。
通常我們容易將高可用和容災混淆，它們都是考慮維持業務的持續性運行，規避單點故障，粗略來說不區分彼此亦無不可，如果需要更好地細分和理解，那麼高可用注重的是維持業務在周期內更長的可運行時間，而容災注重的是極端情況下的業務恢複。
雲上單點故障
隨著雲的日益普及，越來越多人享受到了雲給我們帶來的便利。由於用戶群體多樣化的增加，用戶之間運維水平和故障意識也呈現較大的差距，單點故障成為越來越多人需要麵對的問題。
舉個例子，當前一個常見的簡單業務場景：
尤其針對小型網站服務，很多用戶隻是單一用一台服務器來承載Web應用和數據庫。這種情況下，數據庫、服務器或者服務器上的業務程序出問題了，發生了單點故障，那麼整個業務鏈路就處於不可用狀態。很多用戶抱著僥幸心理，直到發生問題時候才驚醒，然而問題已經出現，損失已無法挽回。
使用誤區
不少用戶在享受雲的便利性和性價比的時候，通常有一些理解的誤區:
1. 雲服務的可用性等同於業務的可用性
雲服務提供商一般都有產品SLA，拿最基礎的雲服務器來說，像阿裏雲基礎的ECS服務器可用性是99.95%，看起來挺高，用戶在使用時候就容易覺得自己的業務在上麵跑就是有這麼高的可用性。然而這裏需要注意的是此可用性是從雲服務器角度來說的，而雲服務器提供給了用戶，操作係統的選擇以及後續係統和軟件環境的部署和維護都是需要用戶考慮的，內核、係統服務、業務程序、安全等各方麵都有可能出現問題，從而影響業務的正常提供，而事實也往往是這些操作係統內的問題引發了業務的癱瘓，所以實際業務可用性通常遠低於雲服務可用性。退一萬步來講，隻論雲服務的可用性，放在一個較長的時間區間，不可用的時間也是一個不可忽視的數值，我們並不知道可能在什麼時候發生，也不應該拿運氣來賭。
2. 用了雲服務，出現問題那肯定都是雲服務商的問題
打個比方，張三買了套房，隨後張三按自己喜好弄了歐式裝修，購置了家電。此時冰箱壞了或者牆紙脫落，張三自然會去找電器和裝修公司理論，而不會想到去找房地產商。
轉化到雲上，其實雲上基礎產品多是IaaS（Infrastructure as a Service）層的服務，仍拿阿裏雲ECS服務器來說，阿裏雲提供服務器資源，用戶購買後可以自由靈活地在上麵部署操作係統和軟件環境，阿裏雲負責保障服務器的正常運行，而用戶則需要對服務器內自己的操作係統和軟件環境的正常運行負責，當然由於底層原因造成的影響仍是需要阿裏雲負責。
觀念的轉變是一個過程，也不是那麼容易，但是劃分清楚職責才有利於整個行業和生態的健康發展。
3. 高可用和容災方案成本太高，劃不來
針對不同的架構、需求和預算，有不同的高可用和容災解決方案，如果實在成本有限，我們也可以優先針對業務鏈路上最容易出現問題的節點做高可用方案。尤其當前各行業競爭激烈，客戶體驗越來越重要，一次故障帶來潛在的客戶流失和體驗下降的損失是不可估量的，而且挽回需要的投入往往比事先規避要大的多。怕什麼就容易來什麼，不如一開始就把潛在的故障風險降低。
4. 一台高配頂多台低配
有的客戶喜歡買一台高配置服務器，性價比高，而且隻要維護一套環境，殊不知單點高配機器一旦出問題，整個業務就完了，而通過多台低配服務器承載業務，能有效地規避單台服務器故障影響整個業務鏈路。
雲上環境的高可用和容災
不管業務是不是在雲上，服務的穩定和連續性總歸是無法回避的話題。從前麵的論述中，我們了解到了高可用性和容災的概念以及單點故障的危害性。雖然雲上的產品已有很高的可用性，我們仍不能忽視構建業務高可用性和容災的重要性。
基本產品
ECS
雲服務器，相當於阿裏雲上的虛擬機，**本身沒有高可用性和容災**，需要通過架構來實現。
SLB
負載均衡，高可用性和容災可以從兩點來闡述：
1. 負載均衡的服務提供是基於集群部署的，各集群有一定數量的節點，避免了單點故障，個別或者部分節點服務器宕機不會影響負載均衡服務的提供。
2. 當前提供的負載均衡實例大多是多可用區實例，主備實例在同城不同可用區機房，當主實例機房出現故障，能及時進行切換，來實現容災和服務的高可用性。
RDS
雲數據庫。
單機基礎版RDS：
隻包含一個節點，沒有備用節點用於故障恢複
https://help.aliyun.com/document_detail/48980.html雙機高可用版RDS：
在同一可用區有主備實例，在主實例出現故障時候可以進行主備切換，具有高可用和容災特性.多可用區RDS：
主備實例在不同可用區
RDS之間還可以用DTS同步和遷移數據。
OSS
依托於阿裏雲底層盤古存儲，文件以chunk分塊方式存儲，默認每塊存三副本，並分布在不同機架的ChunkServer節點上。底層服務器出現宕機也不會導致數據不可用。
可以參考雲盤的三副本技術介紹：
https://help.aliyun.com/document_detail/35108.html
示例介紹
這裏介紹幾種基本的企業高可用和容災架構。
1. 多可用區SLB + 不同可用區ECS
引用幫助文檔的圖，在負載均衡實例下綁定不同可用區的 ECS，當可用區A未出現故障時，用戶訪問流量如藍色實線所示；當可用區A發生故障時，用戶訪問流量的分發將變成紅色虛線，這樣即可以避免因為單個可用區的故障而導致對外服務的不可用，也可以通過不同產品間可用區的選擇來降低延遲。
具體請參考：
https://help.aliyun.com/document_detail/55386.html
2. 多可用區SLB + 不同可用區ECS +高可用RDS
多可用區版RDS：
對於沒有多可用區RDS的地域，可以在對應可用區分別建立一台RDS，其中備用可用區的作為備庫，跟主可用區的RDS實例進行同步。
3. 高可用性-異地容災
基於前麵闡述的同城多可用區情況，在異地也部署一套環境，具體訪問可以配置DNS解析來實現，數據庫同步也可以通過DTS。
最後更新：2017-09-27 03:33:03