大型網站的高可用分析

本文主要分析網站的高可用性，從應用需求、用戶角度展開分析。

1.1 高可用性

“高可用性”(High Availability) 通常用來描述一個系統，經過特殊設計，減少停止服務的時間，從而使其服務保持高度的可使用性。

計算機系統的可靠性用平均無故障時間(MTTF)來度量，即計算機系統平均能夠正常運行多長時間，才會發生一次故障。系統的可靠性能越高，平均無故障時間 越長。可維護性用平均維修時間(MTTR)來度量，即系統發生故障后維修和重新恢復正常運行平均花費時間。系統的可維護性越好，平均維修時間越短。計算機 系統的可用性定義為：MTTF/(MTTF+MTTR)*100%。

舉例來說，淘寶網在2010年成交額為300億，則每分鐘成交額為5—10萬，那么對淘寶來說，其后臺系統的高可用，對企業運營非常重要。淘寶數據負責人 寧海元指出，淘寶系統，可用性至少需要99.999%。那么對于taobao.com系統，在一年365天，系統停止服務時間為5分15秒。

1.2 確保高可用性

高可用性的衡量指標

%availability=(TotalElapsed Time – Sum of Inoperative Times) / Total Elapsed Time

其中：

TotalElapsed Time 為系統總時間，包括可提供服務時間+停止服務時間。

Sumof Inoperative Times 為停止服務時間，包括宕機時間+維護時間。

1.2.1 如何確保高可用

可用性越高越好，提高可用性主要從一下幾個方面入手：

(1)系統架構

(2)容災性

(3)監控報警

(4)故障轉移

1.2.1.1 系統架構

系統架構，指整個網站后臺系統的架構。好的系統架構，主要從下面幾個方面考慮：

(1)操作系統的選擇，從穩定性、安全性和可維護性考慮，unix和linux性能遠遠好于windows，從成本考慮，Linux遠遠低于windows 和unix。

(2)負載均衡器的選擇，硬件負載均衡器性能和穩定性高于軟件負載均衡器。但成本上，軟件比如haproxy、LVS優于硬件(比如F5、Netscaler)。

(3)web server的選擇，Nginx優于傳統的Apache。

(4)各級緩存的選擇與應用，varnish、squid、memcached。

(5)網站開發語言的選擇，與開發有關，主要分為需要編譯性的語言和不需要編譯性的語言。

(6)數據庫的選擇，傳統的關系數據庫中，Oracle優于MySQL，但Oracle收費遠遠高于MySQL，實際上，Oracle有兩種收費模式，一種是按用戶數，一種是按主機處理器個數。而MySQL有免費的版本。

(7)底層存儲設備的選擇，比如機械磁盤和固態硬盤的選擇。

(8)避免單點故障問題，在邏輯架構上，避免單點故障，避免出現割點。

1.2.1.2 容災性

容災性能對系統非常重要，比如服務器因為斷電，導致數據文件的不一致，因為發生自然或者非自然災害比如火災導致的磁盤損壞，發生數據丟失等。所以容災很重要，主要從以下幾個方面提高容災性能：

(1)服務器熱備機的部署，當發生故障后，熱備機能馬上使用，提供服務。這里的服務器主要指web server 、應用服務器、數據庫服務器等。

(2) 數據備份，比如做定期備份、熱備份、增量備份，甚至需要做主從備份，來提高抗災性能。并且從底層存儲設備上進行備份，比如做RAID。

(3) 做雙線網絡交換，盡量優化設計網絡，避免因為核心交換機故障，而影響服務。網絡上避免單點故障。

1.2.1.3 監控報警

監控是指對在線服務和非服務的在線服務器和相應的進程進行狀態檢測，當出現宕機或者某項服務進程僵死之后，能夠在盡量短的時間獲得該信息，然后通過報警系統將信息發送到一線運維人員。所以，監控報警，直接影響宕機時間。監控報警，主要從以下幾個方面展開：

(1)  監控主機CPU使用情況，負載情況。

(2)  監控主機內存使用情況。

(3)  監控主機IO外設，主要以磁盤為主。如磁盤的讀寫、磁盤使用量等。

(4)  監控主機網卡使用情況。網卡是否損壞，是否招到DDOS攻擊。

(5)  監控應用進程，包括web server ，應用服務器等。

(6)  監控數據庫使用情況。包括用戶的請求數、緩存使用量等。

(7)  監控交換設備的使用情況。網絡入、出的流量。

(8)  監控IDC機房溫度、濕度等。

(9)  防火墻、入侵檢測等安全檢測、監控等。

通過上面的各項監控、得到相應數值，應用監控繪圖軟件，把相應的數值繪畫出來，現有監控繪圖軟件有mrtg、cacti、nagios等。然后設置一個報 警閾值，如果超過該閾值，那么通過報警系統，比如短信、msn、郵件、甚至是聲音完成報警功能。典型的報警系統如圖3-2-1-3所示。

                                                                                     圖3-2-1-3

如圖3-2-1-3所示，監控服務器從servers上收集系統信息，如果發現系統的某項狀態指數超過預設的閾值，則發送郵件到運維人員。同時，把相應的 報警信息發送到短信運營商的短信網關服務器，然后短信網關服務器發送短信到運維人員手機中，完成短信報警。上述報警過程，傳送郵件報警信息，是基于 TCP/IP協議，而傳送短信報警信息，是基于gprs網絡。

1.2.1.4 故障轉移

故障轉移是指，當對用戶提供服務的服務器或者相應的應用進程發生故障后，比如服務器宕機、進程僵死之后，備用服務器能夠在盡量短的時間內啟用，提供服務。這樣能夠最大限度減少損失，保證用戶的正常服務。所以，做好故障轉移，要解決以下兩個問題：

(1)  實時監測故障問題。

(2)  準確快速切換服務器問題。

針對不同層次的服務，監測機制也不同，詳細情況，在3.2.1.3已經闡述。下面主要論述一下故障切換問題。

故障切換包括負載均衡器的故障切換、主機os的故障切換、web server的故障切換、應用進程的故障切換、數據庫的故障切換、存儲系統的故障切換、DNS的故障切換、交換設備的故障切換等。下面主要分析進程僵死的故障轉移和服務器宕機的故障轉移。

進程僵死故障轉移案例，常見的web server僵死故障轉移如圖3-2-1-4所示。

                                                                                    圖3-2-1-4-1

如圖3-2-1-4-1所示，當主機172.29.141.112的web server 對外提供服務時，通過在主機172.29.141.113上部署監控程序Monitor_nginx.sh來監控主機172.29.141.112上面的 web server進程運行情況，一旦發現172.29.141.112上web server停止服務，馬上報警，先更改172.29.141.113的ip地址為172.29.141.112，再啟用其自身的web server,完成故障轉移。此外，也可以在兩服務器上同時部署監控程序Monitor_nginx.sh，完成互相監控。

服務器宕機故障轉移案例，常見的服務器宕機故障轉移，如圖3-2-1-4-2所示。

                                                                 圖3-2-1-4-2

如圖3-2-1-4-2所示，服務器A和服務器B同時部署，但服務器A提供服務，而服務器B作為熱備機。監控系統單獨部署。當服務器A宕機之后，監控系統會檢測到這一信息，然后通過浮動更改服務器B的ip地址，完成故障切換。

1.3 本文小結

本文主要闡述了網站后臺系統的高可用性，分析了高可用性的定義和應用需求，重點闡述了如何做到高可用。通過從不同應用級別，如主機、存儲、網絡、外設、數據庫、安全等各個級別進行分析，最后詳細論述了web server的故障轉移和主機系統的故障轉移。

原文地址：http://blog.csdn.net/longxibendi/article/details/6629192