[[149855]]

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

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

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

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

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

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

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

第一步，域名解析

第二步，向著服務(wù)器發(fā)起HTTP請求

第三步，請求走網(wǎng)絡(luò)，到達服務(wù)器所在機房的交換機

第四步，數(shù)據(jù)走幾層交換機之后，到達服務(wù)器網(wǎng)卡

第五步，網(wǎng)卡數(shù)據(jù)經(jīng)過OS，到達Nginx

第六步，Nginx收到HTTP請求

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

第八步，PHP連接Mysql數(shù)據(jù)庫獲取數(shù)據(jù)

第九步，PHP處理數(shù)據(jù)

第十步，Nginx返回數(shù)據(jù)到用戶端

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

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

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

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

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

上面我們講了可用性怎么計算。下面我們來看看監(jiān)控系統(tǒng)的高可用。

先定性，再定量

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

這里還涉及了另外一個問題，就是監(jiān)控系統(tǒng)自身的監(jiān)控。以后會開篇幅來講。

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

如何達到高可用99.99%

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

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

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

具體說怎么才能去單點。我們從監(jiān)控系統(tǒng)本身的數(shù)據(jù)流來分析。

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

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

數(shù)據(jù)采集回來了，要做處理。這個處理或者叫計算環(huán)節(jié)的高可用，有不少現(xiàn)成的辦法。第一，部署兩個計算實例，但兩個實例需要能互備或者同時發(fā)揮作用。第二，純分布式辦法。

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

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