[[149855]]

【引自Reboot運維開發的博客】我借用一個高可用性的定義：高可用性H.A.(High Availability)指的是通過盡量縮短因日常維護操作(計劃)和突發的系統崩潰(非計劃)所導致的停機時間，以提高系統和應用的可用性。它與被認為是不間斷操作的容錯技術有所不同。HA系統是目前企業防止核心計算機系統因故障停機的最有效手段。

那么高可用，就是高可用性良好的系統。多少算高呢？我以前待過的BAT某公司喜歡用小數點以后幾個9來衡量。當然小數點前面默認就是99。大家普遍認為4個9是還不錯的，5個9是核心業務應該具備的。怎么計算呢？這個我后面也可以說一說算法。

對于運維工程師來說，要是能運維一個可用性非常高的系統，我想是一件幸事。系統能高可用，運維處理報警的優先級就不用那么高了。大冬天晚上收個報警，也不用立刻從被窩里面爬起來連VPN處理了。可用性越高，運維工程師睡覺越安心。

影響高可用的因素與計算方式

影響可用性的因素都有哪些?讓我們來捋捋。一個服務分為軟件、硬件。拿一個網站來講解。

假設有個網站，域名是www.51reboot.com。部署了一個nginx，部署在一臺服務器上，這臺服務器在一個叫做zw的電信機房。

用戶從瀏覽器輸入www.51reboot.com開始，直到他在瀏覽器上能打開這個網頁內容為止，有哪些步驟?

第一步，域名解析

第二步，向著服務器發起HTTP請求

第三步，請求走網絡，到達服務器所在機房的交換機

第四步，數據走幾層交換機之后，到達服務器網卡

第五步，網卡數據經過OS，到達Nginx

第六步，Nginx收到HTTP請求

第七步，Nginx調用ThinkPHP框架(這里假定是這個框架)

第八步，PHP連接Mysql數據庫獲取數據

第九步，PHP處理數據

第十步，Nginx返回數據到用戶端

第十一步，用戶端瀏覽器完整接收數據之后，渲染完畢

粗略的分為11個步驟。這里涉及：DNS、服務器、交換機、OS、Nginx、ThinkPHP、PHP、Mysql

服務器又可以分為：磁盤，以及其它部件如CPU、內存。之所以這樣分，是因為磁盤作為存儲部件是最容易壞的一個部件。

好了，我們接下來算一算，51reboot這個網站的可用性是多少。一次可用，相當于上面的十一個步驟都得正常才叫可用。那么就要考慮了，DNS的可用性是多少，服務器不宕機(可用性)是多少、Nginx之類的軟件的可用性是多少、Mysql、磁盤的可用性是多少、網絡的可用性是多少等等。這些可用性的乘積，就是該網站的可用性。

這里還沒有考慮更多實際情況。比如，Mysql如果和Web端不在同一臺機器上、甚至不在同一個機房，或者部署的Nginx實例不止1個，等等。

上面我們講了可用性怎么計算。下面我們來看看監控系統的高可用。

先定性，再定量

這是我的原則，事情都是先定性，看是否有必要，再定量，看需要定到多少，具體量化。監控系統本身是監控別的服務和系統是否正常運行的。如果監控系統自身可用性不足，會嚴重影響監控效果。甚至可以說就是沒有什么用處，有大隱患。

這里還涉及了另外一個問題，就是監控系統自身的監控。以后會開篇幅來講。

前面說了，監控系統本身必須高可用。那下面我們就看這個高可用需要怎么量化。讀者覺得應該達到小數點之后幾個9?我個人覺得至少2個9。也就是 99.99%。否則業務部門的兄弟們急了，因為他們的系統如果要求是99.999%，沒人能證明啊！監控系統本身才是99.99%。

如何達到高可用99.99%

這是今天這篇要討論的另外一個核心問題了。要達到高可用性，還要看系統的架構。按照有沒有單點來區分，系統有兩類，一類是有單點的架構，一類是沒有單點的架構。講到這里我們有必要說一下什么叫做單點。單點簡單來說就是系統里面的某個部位，它在系統里面部署的時候，是一個唯一存在。這個唯一存在不能擴展性的部署一個兄弟實例出來。這種唯一存在將來就最有可能是系統里面的老大難，因為它出了問題，沒有兄弟能頂上。

但，我又要說但是了。沒有單點，不代表說完全百分之百的沒有問題。例如，我們采用Hash的辦法，負載均衡的方式，部署了2個Nginx實例。當其中一個實例掛掉的時候，僅影響了50%的請求。不能算整個系統掛掉了。但這個系統的穩定性依然堪憂，我們不能說它的可用性有多高。 如果Hash計算能夠結合了實例的健康狀態，不健康的自動從hash計算的池子里面摘掉，那可用性就大大提升了。

綜上，以及綜合我們上一篇，監控系統要想達到高可用，必須要采用去中心化的架構來做。就是讓整個系統里面沒有任何一個環節是單點。因為單點就意味著瓶頸，意味著可用性提升很難很復雜，不容易做高。

具體說怎么才能去單點。我們從監控系統本身的數據流來分析。

數據采集，這個要分類來說。一個是帶內的，跑在OS上的代理Agent。這個的高可用，是另外一個領域的事情，就是怎么寫一個高可用的、魯棒性非常好的客戶端。我們以后分開篇幅說。

另外是帶外的。比如，HTTP或者端口監控，或者存活監控。我們拿存活監控來舉例吧！比如說，我們通過ping的方式，來監控服務器是否存活。那么，我們需要一個批量發ping包的探測器。這個也是一個數據采集端。只是沒有在OS上來采集。當然它也存在魯棒性的問題，但這是另外一個領域的事情，我們這一篇不談。這個客戶端，如果它掛了，可想而知，被它監控的服務器都失去監控了。所以，我們要提高Ping監控模塊或者叫環節的可用性。一個最簡單辦法，我們用兩個監控點來監控同一批服務器。但新的問題又來了，倆監控點監控同一臺服務器，什么情況下可以斷定這個服務器掛了呢？這個是另外一個監控數據合并的問題，我們也放到以后的篇章里面去討論。另外一個提高可用性的辦法，就是ping監控點部署兩個，但兩個之間不要同時生效，但兩個節點之間有心跳，一個掛了，另外一個接管，也是一個辦法，但切換略復雜。

數據采集回來了，要做處理。這個處理或者叫計算環節的高可用，有不少現成的辦法。第一，部署兩個計算實例，但兩個實例需要能互備或者同時發揮作用。第二，純分布式辦法。

存儲和Web的分布式方案就更多了。

還有一個最關鍵的地方，如何實現無狀態。只有無狀態了，才能達到簡單的部署切換，就可以支撐高可用。這個問題我們留待之后來講。（未完待續）