高考中國主要包含“高考志願通”志願填報系統 的研究開發 、
產品運
營；高考中國網站（www.gaokaochina.com
)
的開發、維護與運營。
“高考志願通”是經過數十位全國高考志願填報指導專家、計算機網絡 專家、數 學模型專家和數據 統 計專家歷時多年精心打造。成爲中國第一套高考志願填報綜合分析系統，信息最全最新的高考志願填報綜合分析系統，分析最科學、最 精確的填報指導系統。
目前已經開發了服務全國高考考生的志願填報輔助參考系統——《高考志願通》網絡版，光盤版和校園版。高考志願通每年服務上百萬考生，目 前在全國20多個省市設立銷售機構。
他全國獨創的位次、線差、曲線填報方式，爲考生們科學合理的填報志願，提供了方法和依據，讓所有家長和考生一看就能夠清楚明白好用的 系統。從03年推廣至今，深受家長和考生們的好評。高達98%以上的志願填報成功率，幫助考生實現上大學、上好大學好專業 的夢想。
高考中國網站（www.gaokaochina.com )是 以刊登高考最新動態、高考新聞、招生信息、各大院校最新信息、備考輔導、政策法規等高考相關內容爲主。高考中國網站本着發佈最新最全 的高考信息爲目標，爲高考生打造一個專業的高考門戶網站。
1.1 高考中國網現行的運行架構
高考中國網的基本架構是典型的LAMP架構,即系統採用linux ,應用 使用apache 整合php ,然後加上開源 數據庫 mysql .經驗證明,這 是一個比較高效而且節省成本的解決 方案 :除了硬 件而外,每個組件都是免費的。當初，由於用戶 數量少，就 把所有的組件都安裝在一個服務器 硬件 上面；其主要目的是節省帶寬費、託管費以及硬件購置費。圖1-1是其基本結構邏輯。
![]()
![01.jpg]()
圖1-1 所有應用運行在一個服務主機上的邏輯圖
隨着公司商業推廣的進行，訪問該網站的用戶數量急劇增加。加之高考即將臨近，估計未來幾個月內，用戶數量可能成幾何級的增長，這對於 公司來說，應該是件好事。但是，隨着用戶的增長，現行的平臺 將無法支撐更大規模 的訪問服務。
由於是商業網站，保證其365*7*24可用是必須的了。以一個服務器運行所有程序 ，將可能面臨如下幾 個問題：
◆ 故障：只要任何一個組件服務出故障，整個服務都會停止。
◆ 擴展：爲提高性 能 或存儲容量，可以增加內存 等部件，但 總有一個限度。
◆ 性能：用戶越多，性能越差，速度越慢。
◆ 帶寬：用戶越多，消耗的帶寬也就越大，但是單個服務器的帶寬是固定的，理論值是1G，當帶寬消耗帶一定量時，即不能提供 訪問，也無法在增加帶寬。
◆ 硬件冗餘：服務器任何一個部件實效，整個網站的服務都不再可用。
把這些不利狀況歸納起來，就是現行的網站不具備高可用、可擴展、負載 均衡的特 點。儘管當前網站運行狀況還能應付，但對於上述幾個方面的憂慮卻令企業負責人寢食難安，他要求務必在高考來臨之前解決這些問題。
1.2 功能 需求
本系統爲典型的互 聯網 服務型網站,需要達到365*7*24可提供訪問服務,用現在流行的專業術語描述,就是高可用、可擴展、負載均衡 的架構；只有這樣的架構，纔有可能達到這個要求。
1.2.1 高可用
高可用是指在一段時間內（通常是一年），系統能正常提供服務的時間，它是以一個百分比來度量，如可用性99.99%。當然，沒 有任何人能保證系統可用性達到100%，但可以通過良好的設計 ，不斷地 接近100%。對外宣稱小數點後能到達9的個數，是一個技術 團隊 實力的體現。
1.2.2 可擴展
用戶的增加，引起訪問數乃至流量的增加，這種情形下，需要對系統進行擴容，以應對這種快速增長。對於提供高可用服務的互聯網網站，其 對可擴展的基本要求就 是在保持系統服務不終止的情況下，透明的擴充容量，即用戶不知道擴容的存在，或者說是擴容不對現有的服務產生任何負面作用。這 些擴展主要包括：帶寬擴展、 服務器擴展、存儲容量擴展、數據庫擴展等，當然也包括主機增加內存等方面的擴展。只要能保證可以在線擴展，我們就可以認爲系統具有很 好的擴展性。
1.2.3負載均衡
一個應用或服務由數個物理服務器提供,並且每個物理服務器運行的應用或服務是相同的,我們可以讓用戶的訪問通過某種控制策略,把 負載分攤到不同的物理服務 器,從而保持每個物理服務器有比較合理的負載。同時,負載均衡還具備故障隔離的功能,當某些物理服務器失效時，自動從負載轉發隊列剔 除故障服務器，一旦故 障得以恢復，用戶訪問負載則自動加載上來。負載均衡一般是2層架構：轉發器和真實提供服務或應用的服務器。除了真實服務器可以失效且 不影響服務外，轉發器 也能做到其中一個失效，另外一個自動失敗切換，從來保持服務的可用性。
當整個系統的負載趨於飽和時，通過增加物理服務器和擴充物理帶寬來擴容。增加物理服務器以後，系統的負載情況將重新在所有集羣的物理 服務器之間按照指定的 算法重新達到新的均衡。例如：現在有50000個併發連接，4個機器，按照wlc 等權值的負載策略，則每個物理服務器的大概連接數爲1250；此時再增加一個服務器，負載策略不變，則穩定後的每個物理服務器連接數 大概爲1000。
1.2.4 平臺狀態可視化
儘管有前面描述的措施保證系統的高可用、可擴展及負載均衡，但我們還需要隨時知道系統的運行狀態，一旦有機器失效或者某個服務不可 用，應當及時發現並及時 處理，而不要讓故障一直積累，直到所有的服務都不可用以後，再來處理就談不上什麼高可用了。因此，監控平臺的啓用是不可或缺的了，有 了它，就相當於多了一 雙“眼睛”，隨時隨地，我們都可以知道整個平臺是否正常運行。
監控平臺可視化可以以以下幾個方面予以表現：
◆ web方式，即通過瀏覽器觀看被監控的對象 ；如正常狀態下，其 狀態（status）是以綠色填充並顯示一個OK。
◆郵件通知，發生故障時，到達設定重試次數和探測間隔時間後發送郵件給管理 員或相關人員，報 告問題的大致情況。
◆手機短信，這是非常有用和及時的功能。深夜時分，再也沒可能看web頁面 或查閱郵件，可以一 旦發生故障，手機短信卻能隨時通知管理員所發生的故障。
一般情況下，這3者是同時進行的：上班時間通過瀏覽器查看頁面顯示、打開郵件程序定時收取郵件、保持手機24小時在線。
第二章 方案選擇
根據前文的需求描述,我們有幾種可供選擇的方案,這些方案主要包括: 主機部件擴容、應用分離以及高可靠、可擴展、負載均衡等幾種方 案，下面我們分別對這幾種方案進行說明，然後再選擇最終的方案。
2.1 主機部件擴容
仍然是一個單獨的物理服務器，所有相關應用運行在它上面，爲了獲得更好的處理能力，可以通過增加處理器數量或更換頻率更高的處理器、增 加更大的硬盤、更換更大帶寬的網絡適配器（如幾個千兆網卡綁定）、使用磁盤陣列等方式，達到一定限度的性能增加。
2.1.1 主機部件擴容的優點
主機部件擴容的主要優點包括：
1、 不改變系統的邏輯。增加部件後，開機就能運行原來的應用。
2、 節省空間。在物理服務器機箱內增建部件，不會再增加佔用idc機房的機位。
3、 節省能源和線纜等。
4、 硬件維護簡單。
5、 維護成本低。一個服務器，不必僱用專業的運維人員，人力資源成本極低。
2.1.2 主機部件擴容的缺點
單個物理服務器擴容，一般需要停機關閉電源後才能操作，這意味着在擴容的時候服務不可用。同時，由於總線速度/帶寬等方面的限制，擴 容到一定程度後，性能 的增長效果反而會下降。另外一個瓶頸就是不具備高可用和可擴展性性，隨着用戶的增加，訪問的迅猛增加，故障率增加導致服務不可用的幾 率大大增加。因此要靠 部件擴容來應對用戶增長，是不可能從根本上解決問題的。
2.1.3 主機部件擴容成本組成
主要的成本是購買服務器配件，如cpu、內存等。
2.2 應用分拆
應用分拆就是再購買一個服務器，把相關應用單獨分佈在獨立的服務器上。例如把apache和php部署在一個物理服務器，mysql 數據庫單獨部署在一個物理服務器。圖2-1是其邏輯結構。
![]()
![02.jpg]()
圖2-1 應用拆分後的邏輯圖
2.2.1 應用分拆的優點
應用分拆的主要優點包括：
1、 平臺結構更加簡潔。這對於排除故障很有幫助，同時對調試工作，也是很有利的。
2、 更高的系統性能。
3、 維護成本較低。只增加了一個服務器。
4、 故障概率降低。舉例來說，原來所有的應用都在一個服務器上，系統運行過程可能產生較高的磁盤I/O;應用分拆後，單 個服務器的磁盤I/O理所當然的降低，出故障的機率也就降低了。
5、 數據可靠性得以增強。當以單個服務器單個硬盤運行所有應用的時候，文件 系統或硬盤發生故 障，存儲在磁盤上的數據可能全部丟失；而使用2個服務器分開來運行web和數據庫以後，數據全部丟失的可能性降低了—web服務器的 硬盤壞了，不會引起數據庫服務器數據的丟失；反之亦然。
2.2.2 應用分拆的缺點
應用分拆的主要缺點包括：
1、 成本增加。這些增加的成本有購買服務器的成本和增加託管機位的成本。
2、 增加能源耗費和線纜。
3、 維護複雜度增加。要維護2個服務器。
4、 存在單點故障，不能實現高可用，更不能應對未來不斷增長的業務需求。
2.3 高可用、可擴展、負載均衡解決方案
高可用、可擴展、負載均衡的方案是在應用分拆的基礎 上， 通過增加冗餘物理服務器來避免單點故障。可擴展性表現在系統強大的容量伸縮能力，可以根據用戶數量，隨時增加或減少資源（服務器或帶 寬），而不會對正常的 服務產生影響。要保證365*7*24不間斷服務，高可用、可擴展、負載均衡這幾項往往需要結合在一起，才能到達理想的效果。
2.3.1高可用、可擴展、負載均衡解決方案的優點
高可用、可擴展、負載均衡的方案的主要優點包括：
1、 高可用。降低了系統故障恢復時間，從而降低運營壓力和由此帶來的負面影響。試想一般的場景，當系統不可用時，來自 用戶或同事的催促會對系統運維人員產生巨大的壓力，這種壓力隨停機時間的增加越發令人恐慌。
2、 高可靠性。由於冗餘服務器的使用，最大限度地減少了單點故障，這就保證了業務的持續性和穩定性。
3、 可擴展性。通過增加物理服務器，極大地增強了運算能力和處理速度。
4、 負載均衡能力。不但增強了系統的總體吞吐能力，而且還具備故障隔離和失敗切換的功能，這也是保證系統高可用的一個方面。
5、 降低長期維護成本。
6、 不能保證100%的高可用。
7、 可以應對不斷增長的業務需求。
2.3.1高可用、可擴展、負載均衡解決方案的缺點
高可用、可擴展、負載均衡解決方案的缺點主要有：
1、 先期投入成本較高。需要購置更多的服務器、增加機位、僱用專職技術維護人員。
2、 實現技術複雜。
3、 需要更改應用程序邏輯或程序本身。
4、 需要更多的輔助資源，如監控系統、共享存儲系統等。
2.4 方案選擇
通過前面的對比，可以知道每種方案都有其優勢和不足，但從業務本身特點和着眼於將來這些方面考慮，高可用、可擴展、負載均衡的方案應 該是不二之選。根據筆 者以前實施的數個類似的實際應用，這個方案是經得起考驗的、也是成熟的。據調查，目前有不少互聯網網站也採用了這樣的架構；同時也有 一些機構開始考慮採用 筆者所發佈的方案。
筆者已經實施的高可用、可擴展、負載均衡的網站有：某某心理網、某某技術在線、某某論壇、某某通行證、某某在線收藏等等。
第三章 高可用、可擴展、負載均衡方案設計
高可用、可擴展、負載均衡方案包括硬件和軟件 兩個主要的方面.硬 件有服務器、交換機、遠程管理設備；軟件包括操作系統、負載均衡軟件、web應用軟件（這裏是apache和php）、數據庫軟件 mysql、監控軟件Nagios 等。
3.1 系統總體架構
高可用、可擴展、負載均衡的總體架構分爲負載均衡層、應用層、數據庫層及共享文件系統三層。其中數據庫和共享文件可看成同一個層次， 圖3-1展示了這個層次邏輯。
![]()
![03.jpg]()
圖3-1 3層結構的高可用、可擴展、負載均衡結構
3.1.1 總體架構中各層的作用
◆負載均衡層：
負載均衡層負責負載轉發或失敗切換，一般情況下由2個服務器組成一組，一個充當主服務器，另一個充當備用服務器。用戶的請求首先達到 負載均衡層，然後負載 均衡設備根據指定的算法把負載轉發到第二層的某個應用服務器，應用服務器響應這個請求並進行相應的處理（如進行數據庫連接、讀寫文件 等操作），然後把數據 返直接返還給用戶（這是DR模 式 ），或者先返還給負載均衡器，封包後再返還用戶（這是NAT模式）。
使用主備方式的負載均衡環境，當主設備發生故障或失效時，備份負載均衡器會自動接管它的工作—即失敗切換（Failover）功能。
與一般應用層負載均衡（如apache負載均衡）不同的是，內核層的負載均衡具備對後面真實應用服務器進行健康檢查/存活檢查的功 能，一旦真實應用服務器的某個主機實效，負載均衡器能自動地把故障隔離；而當這個故障得也恢復時，則再把它再加入先前的轉發隊列。
◆ web應用層：
web應用層由兩個或2個以上的物理服務器組成，運行諸如apache+php之類的應用，本方案的具體應用是 apache+php。在這些物理服務器上，運行相同的應用，但物理服務器的配置可以不相同；爲求得一致的性能，可以使用硬件配置完 全相同的服務器。
Web 應用層一個比較困難的問 題是數據同步。假定有3個web應用服務器，現在需要修改某些php程序，可以選擇的操作方式有：
1、 登錄每個服務器，逐個進行修改，或者用scp複製到其他服務器。
2、 修改其中的一個服務器的文件，使用rsync這樣的工具 進行同 步。
3、 共享文件系統，如NFS、分佈式文件系統等。
方法1和2是把應用所需的文件/數據在每個服務器上各自保存一份，當其中的任何一個服務器的數據發生變化，則需要以某種方 式把變化同步到其他服務器。方法 3是所有服務器共享同一份數據，因此不存在數據同步的問題。在筆者的某個工作場景中，曾有過用方法2同步各服務器數據的經歷，這種方 式耗費系統/網絡資 源，特別是需要的同步數據巨大無比時，系統性能下降更是明顯。同時，怎樣選擇同步間歇，也難以權衡—同步間歇短了，前一次同步還未完 成，後一個同步又開始 了，如此堆積，佔用大量的系統資源；同步間歇長了，用戶的訪問結果會不一致（如bbs發帖子，卻很長時間顯示不出來，因爲其他用戶訪 問的可能是另外沒有同 步過數據的服務器）。對於web應用類型的集羣服務，最合適的方式就是共享文件系統這樣的方式。即保證了數據的一致性，又有較好的速 度和性能。爲保證數據 的可靠性和性能，本案採用分佈式文件系統moosefs 作爲web應用的共享存儲。
◆ 數據庫層:
在互連網領域,mysql無疑是使用得最多的數據庫平臺,估計其在數據庫市場的佔用率超過40%。Mysql先被SUN system 收購，SUN 又被 ORACLE收購，讓人眼花繚亂，以至於不少人對開源數據庫的未來發展擔憂。但這些，並不妨礙mysql的易用性和受歡迎的程 度。
爲了保證mysql的高可用性，mysql有2種方法來實現：主從複製和mysql cluster(中文 翻譯成“簇”)。在 實際應用中，很少聽說有人使用mysql cluster，因爲這個配置過程過於複雜，而且還有很多地方不完善。對於一般的應用場 景，使用mysql主從複製（一主一從或一主多從）就能滿足要求。如果負載再大一些的應用，可以再增加讀寫分離的機制 ，提高性 能和可靠性。本方案初始設計使用一主一從的方式，同時使用腳本 ，在夜間 用戶訪問少的時候，對整個數據庫進行完全備份。
數據庫數據的存儲，即可以放在本地硬盤，也可以使用分佈式共享存儲系統。使用分佈式共享存儲系統，能大大提高其性能和速度。分佈式共 享系統將在下面介紹。
◆ 分佈式文件系統
在以前的項目裏，筆者曾經用單個服務器以nfs的方式共享存儲給應用層的服務器，當用戶數量少於一定規模的時候，似乎也能很好的工 作。爲了保證數據的安全性，增加一臺服務器用rsync對這個nfs的共享數據進行同步備份。圖3-2說明了其結構特徵。
圖3-2 應用程序共享NFS文件系統
![]()
![04.jpg]()
這種架構除了性能問題而外，還存在單點故障，一旦這個NFS服務器發生故障，所有靠共享提供數據的應用就不再可用，儘管用 rsync方式同步數據到另外一 個服務器上做NFS服務的備份，但這對提高整個系統的性能毫無幫助。基於這樣一種需求，我們需要對NFS服務器進行優化或採取別的解 決方案，然而優化並不 能對應對日益增多的客戶端 的 性能要求，因此唯一的選擇只能是採取別的解決方案了；通過調研，分佈式文件系統是一個比較合適的選擇。採用分佈式文件系統後，服務器 之間的數據訪問不再是 一對多的關係（1個NFS服務器，多個NFS客戶端），而是多對多的關係，這樣一來，單個磁盤的i/o降低，從而使得整個存儲系統的 性能大幅提升。
到目前爲止，有數十種以上的分佈式文件系統解決方案可供選擇，如lustre,hadoop,Pnfs等等。我嘗試了 PVFS,hadoop, moosefs這三種應用，參看了lustre、KFS等諸多技術實施方法，最後選擇了moosefs（以下簡稱MFS）這種分佈式 文件系統來作爲共享存 儲服務器。爲什麼要選它呢？
1、 實施起來簡單。MFS的安裝、部署、配置相對於其他幾種工具來說，要簡單和容易得多。
2、 不停服務擴容。MFS框架 做好後，隨 時增加服務器擴充容量；擴充和減少容量皆不會影響現有的服務。注：hadoop也實現了這個功能。
3、 恢復服務容易。除了MFS本身具備高可用特性外，手動恢復服務也是非常快捷的，原因參照第1條。
4、 我在實驗過程中得到作者的幫助，這讓我很是感激。
MFS特性（根據官方網站翻譯）
★ 高可靠性（數據能被分成幾個副本存儲在不同的計算機裏）
★ 通過增加計算機或增加新的硬盤動態擴充可用磁盤空間
★ 可以設置刪除文件的空間回收時間
復
制代碼
文件被刪除10分鐘後（600秒），才真正刪除文件，回收磁盤空間。
★ 爲文件創建快照
MFS文件系統的組成
1、 元數據服務器。在整個體系中負責管理管理文件系統，目前MFS只支持一個元數據服務器master，這是一個單點故障，需要 一個性能穩定的服務器來充當。希望今後MFS能支持多個master服務器，進一步提高系統的可靠性。
2、 數據存儲服務器chunkserver。真正存儲用戶數據的服務器。存儲文件時，首先把文件分成塊，然後這些塊在數據服務器 chunkserver之間複製（複製份數可以手工指定，建議設置副本數爲3）。數據服務器可以是多個，並且數量越多，可使用的“磁 盤空間”越大，可靠性 也越高。
3、 客戶端。使用MFS文件系統來存儲和訪問的主機稱爲MFS的客戶端，成功掛接MFS文件系統以後，就可以像以前使 用NFS一樣共享這個虛擬性的存儲了。
圖3-3展示了moossfs文件系統的基本結構：
![]()
![05.jpg]()
圖3-3 moosefs 文件系統體系結構（圖片來源：http://www.moosefs.com/pages/mfs.html ）
3.1.2 網絡劃分
根據業務特點，以及需要應對用戶數急劇增加的要求，需要對這個系統進行網絡劃分。本系統需要劃分出兩個網段，一個公網網段和一個內部 /私有網段。
公網網段（全球唯一ip地址）提供給負載均衡器和應用服務器使用。爲了提供最高的訪問轉發性能，負載均衡採用直接路由的模式（DR），因 此真實提供服務的應用服務器也得使用與負載均衡器相同網段的公網ip地址。圖3-4是直接路由模式的訪問路徑。
![]()
![06.jpg]()
圖3-4 用戶訪問路徑
從這個圖示我們可以得知，用戶發出請求後先經過負載均衡器，再被轉發到真實的應用服務器，數據返還時，直接給用戶了，而不必經過負載 均衡器，這極大地增強了網絡的吞吐能力。
內部網絡主要是在應用服務器、數據庫、共享存儲之間進行通訊使用。使用192.168這樣的私有地址，即保證了系統的安全，又減少了 它對其他部分的影響。
應用服務器同時屬於這個兩個網段，因此它需要者少有兩個網卡用於網絡連接。
3.1.3系統架構評價
高考中國網高可用、可擴展、負載均衡設計方案，基本解決了單點故障（數據庫和分佈式文件系統的元數據服務器還是存在單點故障）；可 擴展能力得以大大提高— 應用服務器可以按需擴展、分佈式文件系統可以按需擴展、數據庫從服務器可以按需擴展—這種擴展可以線形的增強性能和速度；負載均衡方 面，負載均衡器具備內 核級的負載均衡功能、分佈式文件系統也具備數據存儲和訪問的負載均衡功能、mysql數據庫在實現讀寫分離後，也可實現良 好的負載均衡能力。
因此，從局部到整體，都具備了高可用、可擴展、負載均衡的能力，這些措施，強有力的保證了系統的持續服務，同時也具備了非常靈活的伸 縮特性。
3.2 部件/工具選擇
部件/工具選擇主要在硬件和軟件這個兩個方面，根據前文的設計，也按3層模式來說明各層的部件選擇。
3.2.1 負載均衡層的部件選擇
◆硬件
本層需要服務器2臺，並且不需要太高的配置即可勝任，使用市場上入門 級的服務 器即可滿足要求，爲了減少託管機櫃的佔用，使用1u尺寸的機架式服務器是最佳的選擇。表3-1是某個生產環境負載均衡器的硬件配置。
這個服務器是在市場上組裝的，當然，如果預算資金充足，可以自行購買品牌機。由於負載均衡的主要任務是轉發，系統運行時負載非常的 小，所以也可以使用配置更低一點的服務器或者使用其他淘汰下來的機器。
◆軟件
軟件包括2個部分：操作系統和應用程序。在本方案中，完全選擇開源且免費的軟件方案。
操作系統方面，使用centos 和 FreeBSD。由於lvs已經包含在linux發行版的內核中，因此在負載均衡器中使用centos5.2作爲操作系統，比 選擇freebsd要有優勢（也可以選擇freebsd，不過配置起來要複雜一些）。
應用程序方面，負載均衡器使用lvs及keepalived來實現負載均衡，同時實現負載均衡器本身的失敗切換 （failover）–主負載均衡器失效備 份負載均衡器自動接管轉發、主負載均衡器恢復後負載自動被主負載均衡器接管。也有另外的方案可供選擇，如lvs+heatbeat。 不過這與 keepalived的方案相比較，配置操作更復雜。Keepalived安裝成功以後，僅僅需要使用一個配置文件，就實現了我們所 要的全部功能；而用 heartbeat 則需要撰寫資源文件、撰寫運行腳本等等。
通過下列站點取得負載均衡所需的軟件資源：
1、 操作系統 centos 5.2。 http://www.centos.org
2、 Lvs內核ipvsadm-1.24。 http://www.linuxvirtualserver.org
3、 負載均衡失敗切換框架工具 keepalived-1.1.17. http://www.keepalived.org
3.2.2 應用層部件選擇
應用層主要是運行web服務，它由apache整合php來完成。爲了使用分佈式共享文件系統，需要額外的軟件來實現文件 系統的掛接。要使apache發 揮更好的性能，需要使用apache的worker模式（默認是prefork）。在worker模式下，通過查看進程數，可以發現 開啓的進程數遠遠少於 默認的prefork模式。Worker模式需要4G以上的內存支持才能發揮較好的作用。
◆硬件
與負載均衡層所需的服務器硬件相比，所需的硬件要求差別不是太大。因此我們可以採用與負載均衡層相同的配置，增加內存到8G。從 成本看，增加4G內存大概 就是增加幾百元的成本而已。前文描述過，應用層至少需要2個以上的服務器，建議初始配置使用3個服務器，以後根據業務需求再逐步擴充 服務器的數量。反之也 可以根據用戶數量的降低減少服務器數量。表3-2是某個生產環境的服務器硬件配置。
◆軟件
基於使用開源軟件的宗旨，本層的操作系統可使用Centos或FreeBSD，甚至是其他GNU/linux或者solaris。應 用程序包括了web應 用apache和php;共享文件系統的掛接需要Fuse(系統默認安裝)及掛接程序,本方案採用moosefs文件系統。
通過下列站點取得負載均衡所需的軟件資源：
1、 操作系統 centos 5.2。 http://www.centos.org
2、 web程序apache。 http://www.apache.org
3、 php程序。http://www.php.net
4、 分佈式文件掛接工具moosefs. http://www.moosefs.org .
3.2.3 分佈式文件系統及數據庫層部件的選擇
本層包含數據庫和分佈式文件系統。對於數據庫來說，需要更快的處理能力，即頻率更高的cpu和更大的內存；而對於分佈式文件系統，則 需要大容量的硬盤，以便可以存儲更多的數據。
◆硬件
（一）數據庫硬件
主從複製最少要2個服務器，本方案初始設計使用2個服務器，一主一從。以後可以根據業務增長實現擴充，形成一主多從、速寫分離的方 式。這樣既保證了數據安 全，又能大幅提高負載。數據庫服務器仍然使用1u機架式服務器，安裝4核雙cpu，16G內存，300G sas硬盤2個（做成raid 10）。數據庫文件即可使用本地硬盤存儲，也可以使用分佈式文件系統。
（二）分佈式文件系統硬件
分佈式文件系統由2個部分組成：元數據服務器master和數據存儲服務器chunkserver。其中元數據服務器需要的配置要求 不高，按負載均衡器那 個標準配置就可以；數據存儲服務器則儘可能地增加硬盤數量也獲得最大的容量。初始配置時，使用一個元數據服務器，3個數據存儲服務 器。數據存儲服務器採用 2u機架式服務器，安裝6個1T sata硬盤，做成RAID 5，再用一個單獨的sata安裝硬盤來安裝操作系統，這樣可以獲得4.5T的可用磁盤空間來共享。3個服務器可提供總容量大概爲 13T存儲空間。以後再隨 業務增長增加數據存儲服務器。
◆軟件
（一）、數據庫
包括操作系統和數據庫兩個部分。操作系統可以是centos或freebsd。
數據庫可從 http://www.mysql.org 獲得。
（二）、分佈式文件系統
分佈式文件可以運行在各種類unix平臺，因此可以根據自己的喜好選擇開源和免費的操作系統。元數據庫服務器、數據存儲服務器及分佈 式文件客戶端（即第2層的應用服務器）都使用同一個軟件moosefs,它們之間的差別在於安裝過程配置過程使用哪些選項。
從http://www.moosefs.org 可以取得分佈式文件系統所需的軟件moosefs.
3.2.4 網絡設備選擇
出於安全和速度考慮,我們把網絡分成內外兩個網段,這兩個網段在物理上分離開,即使用兩個交換機.在我們這個方案裏,暫時沒有考慮交 換機的高可用性,因此 對交換機本身的質量要求比較高.具體的配置是:外網交換機使用100M 的cisco交換機,型號爲ws-c3560-48TS;內網使用華爲千兆交換機，型號是H3C S5100-SI。爲簡化管理，減少後期維護成本，交換機只設置了snmp community 用於服務器的流量監控和統計（每個有流量的端口對應一個服務器，就沒有必要再在每個服務器上配置和啓用snmp服務）。一個需要注意 的地方是，應用服務器 同時連接這兩個網絡，爲了安全，請勿在任何雙網絡的服務器設置NAT。
服務器的託管一般是在遠離辦公室的專用的機房，在通常情況下，如果出現不能登錄服務器等故障，需要親自跑到機房去處理，這很費時、費 錢。爲了解決這個問 題，需要購買一個KVM over ip的網絡設備，初始投資大概在5000元，安裝配置好KVM之後，基本上就不用去機房現場操作。
第4章 輔助功能—監控系統的設計
通過上述合理的方案設計,系統已經具備很高的可用性,即便有一些服務器實效或發生故障,也不會中斷服務。但是，發生故障或失效的服務 器，還是需要處理和恢 復服務的，不要等到所有服務都停了，才知道發生了故障。爲了隨時知道整個系統的運行狀態，我們需要一雙“眼睛”，時刻監控每個對象的 運行情況，如當某個服 務器負載過高時，給系統管理員發送報警信息。一旦有了這樣一個平臺，就實現了所有服務的可視性。
4.1 監控平臺選擇
這裏使用網絡監控軟件Nagios,個人認爲它最大的好處是可以發故障報警短信—只要Nagios監控的對象發生故障，系 統就會自動發送短信到手機上。下面摘錄Nagios官方網站的描述：
Nagios is an open source host, service and network monitoring program. Who uses it? Lots of people, including many big companies and organizations：Nagios是一個用來監控主機、服務和網絡的開放源碼軟件，很多大的公司或組織都在使用它。
Nagios 是開源的GNU源碼包，可以安裝在各種類unix平臺，如centos、freebsd、solaris 等，並且在各個平臺的安裝方法基本上是相同的。
Nagios爲了方便我們的管理工作，提供了至少3種表現手段：
1、web方式，即通過瀏覽器觀看被監控的對象；如正常狀態下，其狀態（status）是以藍色填充並顯示一個OK。
2、郵件通知，發生故障時，到達設定重試次數和探測間隔時間後發送郵件給管理員或相關人員，報告問題的大致情況。
4、 手機短信，這是非常有用和及時的功能了；晚上熟睡中，再也沒可能看web頁面或查閱郵件，可以一旦發生故障，相關人員馬上就 能知道發生故障。
一般情況下，這3者是同時進行的：上班時間開個瀏覽器看頁面顯示、打開郵件程序定時收取郵件、手機24小時在線。
4.2 nagios的監控對象
監控應該具備效率和有效性，不要把所有的對象都放在監控裏面，否則會發生類似“狼來了”這樣的問題。
4.2.1 負載均衡層監控對象
負載均衡層主要監控包括存活檢查及vip服務狀態檢查。
負載均衡器有2個服務器，首先需要知道的是這2個服務器是否存活。由於負載均衡器運行中既不耗費資源又不產生大的日誌（日 志直接輸出屏幕了），爲了保證其轉發效率和性能，不必再在上面安裝NRPE(nagios遠程插件 執行)。
用戶的訪問通常被指引到負載均衡設定的vip（在DR模式中，所有的服務器都用這個vip實現負載均衡功能），監控系統只需模擬用戶 訪問vip的url頁面，即可獲知服務是否正常。
4.2.2 應用服務器層監控對象
應用服務器層需要監控的對象可歸納成2種：服務監控和資源監控。服務監控的目的是掌握服務的存活情況，資源監控是爲了掌握系統的運行 情況。在實際運行中，系統狀態往往可以預測服務是否會出現問題，如較高的負載、較多的連接數、分區超過可用容量的80%等等。
應用層服務開啓了2個基本的網絡服務：sshd服務和web服務。前者用於遠程連接，後者用於web服務。當我們配置了對 sshd和web服務監控以後，默認狀況下已經啓用了服務器的存活檢查，所以不必單獨列出存活檢查這個項目。
資源監控包括：負載監控、磁盤使用空間監控、進程數監控、ip連接數監控這4個項目。Nagios服務器本身不能像監控服務一樣直接 監控系統資源，它需要 在被監控的服務器上安裝NRPE-nagios remote plug execute,由NRPE收集信息，然後返還信息給nagios服 務器。
圖4-1是一個nagios監控真實服務器的運行狀況。
![]()
![07.jpg]()
圖4-1 nagios監控服務器和主機資源示意圖
應用服務器以fuse方式掛接和訪問moosefs分佈式文件系統，在監控資源裏，加入了磁盤使用的空間檢查，假如分佈式文件系統不 可用，則也可以通過這個磁盤監控可以體現出來。
4.2.3 數據庫層監控和分佈式文件系統監控
數據庫除了監控系統資源及服務端口外,需要額外創建一個空的數據庫和一個權限極低的帳號,NRPE通過這個賬號登陸mysql即可實 現對mysql數據庫 有效的監控.在數據庫複製過程中,輔助服務器很有可能複製失敗而停止數據同步,nagios用常規的插件無法檢查同步失敗,所 以需要手動寫個腳本,然後根 據腳本的輸出來判別是否正常.在把腳本整合到NRPE.
分佈式文件系統的監控分成兩個部分:元數據服務器和數據存儲服務器.除了監控系統資源外,還要監控這兩者服務。元數據服務器和數據存 儲服務器分別使用不同 的端口進行監聽，監控元數據服務器，用tcp 9420端口；監控數據存儲服務器，用tcp 9422端口。再綜合應用服務器層對磁盤空間利用的監控情況，我們就可以很準確的知道整個moosefs分佈式文件系統的運行狀況。
第5章 高可用、可擴展、負載均衡的總體架構技術實現
架構規劃和設計好以後，就需要選擇服務商，把設備放入idc機房，連接線纜，準備測試，無誤後上線運行。
5.1 選擇服務商及硬件上架
由於特殊的原因，中國的網絡形成了劃江而治的格局，這導致南北互聯很大的問題，即網通和電信互訪效果極差，要達到南北用戶都能快速的 訪問網站，得使用第三 方的idc機房。第三方的idc機房有兩種可選，一種是雙線機房，另一種是BGP機房。這兩種機房相比較，BGP效果最佳，但價格最 貴，可根據自己的資金 預算和性能要求來權衡使用哪一類機房。另外在選定前先測試一下機房的網絡狀況，同時瞭解其電力供應，空調設施已經服務器堆放密度，最 好觀察一下是否有知名 的網站也放置在這裏？
託管上選定以後，就要放置設備，接上電源、網線等線纜進行物理連接，爲開機運行做好準備，如果有必要，則需要對交換機作一些設置。原 則上是不需設置則不設置，保持簡單化總是對的。
在本方案中，我們採用了短信報警的機制，監控服務器本身並不發送短信的能力，因此需要選擇短信服務商，購買其服務，然後通過接口程序 來實現發送報警短信的功能。
5.2 安裝操作系統及部署相關軟件
除了負載均衡器而外，其他兩層的底層操作系統可以是任何一種類unix環境。理論上，負載均衡器也可以是其他類型的unix，如 freebsd，但這些系 統都不能linux來得方便，因爲lvs已經集成在各個linux的發行版裏了，不需要額外的處理，就可以實現lvs的轉發（主要內 核模塊是 ip_vs）。本方案以開源爲宗旨，並且考慮以節省成本，因此所有服務器都安裝和運行centos5。
5.2.1 負載均衡層的軟件部署
負載均衡層要實現負載均衡、故障隔離、失敗切換（負載均衡器之間failover）這3個功能，需要ipvsadm和 keepalived這個兩個工具緊 密配合來實現。Ipvsadm是lvs的核心，由它完成負載均衡和包轉發，但它本身沒有故障隔離和失敗切換的機制。在其他 人實施的一些項目裏，有采用 heartbeat這樣的工具來實現故障隔離和失敗切換。但heartbeat太複雜了—要寫ipvsadm腳本、要寫資源文件、要 安裝 ldirectord等等。現在我們採用keepalived這個工具，只需要一個配置文件，即可輕鬆實現故障隔離、失敗切換。
Lvs即可在安裝系統是選擇安裝，也可在系統安裝完成後下載ipvsadm源碼進行安裝。當按需求配置好 keepalived以後，運行keepalived 後，將能夠查看到lvs的內核模塊ip_vs已經被加載。
負載均衡器採用DR(直接路由)模式進行包轉發，這種方式可獲得最大的網絡吞吐能力。在DR模式下，負載均衡器與後面的真實服務器 （即本方案中應用服務器層）使用一個公用的ip地址，稱爲vip（virtual ip）。
5.2.2 應用層軟件部署
應用層涉及的軟件比較多，它主要包括apache、php、mysql 客戶端、分佈式文件系統客戶端、lvs客戶端等幾個部分。看 起來類別比較多，但只要配置好一個服務器以後，然後複製這個過程即可。這是因爲負載均衡服務器之間存在配置一致性的特點。
安裝步驟：
1、 安裝apache,php,mysql客戶端，並整合apache與php。
2、 安裝分佈式文件系統moosefs，接着掛接共享存儲。
3、 編寫lvs客戶端腳本，並賦予執行權限。腳本的內容大致如下：
複製代碼
4、 安裝和配置Nagios
遠程執行插件（Nagios Remote Plug Execute）。
5、 複製程序開發人員編寫的程序到apache設定的站點的根文檔目錄 ，檢查 apache語法，無誤後啓動apache。
6、 執行lvs客戶端腳本，運行 ip add檢查其正確性。
7、 啓動NRPE,並測試其正確性。
8、 總體檢查其正確性。
5.2.3 數據庫及分佈式文件系統部署
數據庫分主從兩個部分，主從數據庫的安裝方法是相同的，只要稍微改一下從服務器的選項文件，就能實現主從服務器之間的數據同步。爲 了更進一步保證數據安全性，可以寫一個腳本，自動執行一個全數據備份。
分佈式文件系統moosefs的原數據服務器和數據存儲服務器的安裝方法也是相同的，不同的地方在於啓動命令 和其關聯的配置文件。 存儲服務器之間的配置（只軟件及配置文件）是相同的，因此只要配置好其中的一個後，把這個配置文件複製到其它服務器相同的路徑即可。
爲了實現nagios的有效監控，需要在數據庫系統和分佈式文件系統安裝和配置nrpe.
5.3 測試
測試過程包括功能測試和性能測試 。
功能測試是逐個測試3層結構中各部分的功能是否正常，然後再模擬用戶行爲訪問站點，看總體功能是否實現。例如，在瀏覽器中輸入網站域 名（通過dns把網站域名指向LVS的vip地址），然後註冊用戶，成功後用這個功能登陸，看一切是否正常。
性能測試就是進行一些破壞性測試或者模擬大量用戶進行訪問。在這裏，最主要的是破壞性測試。在3層結構中，通過逐層逐個啓停服務甚至 服務器，看用戶訪問是 否正常。如停掉主負載均衡器，觀察輔助負載均衡器能否自動接管轉發服務；主負載均衡器恢復，轉發能不能再回到原來的狀態。
性能測試過程：
1、 負載均衡器啓停測試，主要目的在於其失敗切換failover功能。前文描述過，不再說明。
2、 應用服務器啓停測試,主要目的在於其故障隔離功能。當停掉一個web服務時，用戶訪問是否正常，再停掉一個web服務，情況 有怎樣？
3、 分佈式文件系統測試。停止其中的一個數據存儲服務，觀察從瀏覽器訪問網站是否受影響。再停止一個數據存儲服務器，情況又會如 何？
4、 數據庫測試。關閉從數據庫，觀察從瀏覽器訪問網站是否受影響。再啓動輔助服務器，看數據同步是否能再進行。
5、 做上述測試時，監控系統是否發送報警信息？
5.4 加固和平臺運行
加固主要是在系統安全性方面考慮。目前出於商業利益方面的原因，ddos攻擊相當的流行。要防範ddos攻擊，單靠主機本身的防火牆 如iptables或 傳統的硬件防火牆，基本沒效果。如果預算充足一點（其實前面的設計已經節省了大筆費用），買個防ddos流量攻擊的硬件設備部署在網 絡的前端，可以有效地 抵擋大部分非法訪問和攻擊。
當一切準備就緒，就可以正式上線，通知用戶可以使用本網站了。
第六章 方案實施後的效果
截至本文撰寫之時，高考中國網www.gaokaochina.com 目前已經上線運行有半個多月，運行狀況十分良好；目前的併發在線ip數只有幾百個，等到高考結束，學生填報自願時，流量就會急劇增 加，到那個時候，再觀察其運行狀況，以決定其伸縮。
附錄
主要參考資料
1.開源監控利器nagios實戰,田逸,http://net.it168.com/a2009/0309/267/000000267878.shtml
2.基於LVS的互聯網應用架設攻略,田逸,http://server.it168.com/server/2007-12-11/200712110855723.shtml
3.Nagios遠程監控軟件的安裝與配置詳解 ,田逸,http://netsecurity.51cto.com/art/200706/48728.htm
4.分佈式文件系統MFS(moosefs)實現存儲共享,田逸,http://net.it168.com/a2009/0403/270/000000270867.shtml
總體拓撲圖：
![]()
![08.jpg]()
“高考志願通”是經過數十位全國高考志願填報指導專家、計算機網絡 專家、數 學模型專家和數據 統 計專家歷時多年精心打造。成爲中國第一套高考志願填報綜合分析系統，信息最全最新的高考志願填報綜合分析系統，分析最科學、最 精確的填報指導系統。
目前已經開發了服務全國高考考生的志願填報輔助參考系統——《高考志願通》網絡版，光盤版和校園版。高考志願通每年服務上百萬考生，目 前在全國20多個省市設立銷售機構。
他全國獨創的位次、線差、曲線填報方式，爲考生們科學合理的填報志願，提供了方法和依據，讓所有家長和考生一看就能夠清楚明白好用的 系統。從03年推廣至今，深受家長和考生們的好評。高達98%以上的志願填報成功率，幫助考生實現上大學、上好大學好專業 的夢想。
高考中國網站（www.gaokaochina.com )是 以刊登高考最新動態、高考新聞、招生信息、各大院校最新信息、備考輔導、政策法規等高考相關內容爲主。高考中國網站本着發佈最新最全 的高考信息爲目標，爲高考生打造一個專業的高考門戶網站。
1.1 高考中國網現行的運行架構
高考中國網的基本架構是典型的LAMP架構,即系統採用linux ,應用 使用apache 整合php ,然後加上開源 數據庫 mysql .經驗證明,這 是一個比較高效而且節省成本的解決 方案 :除了硬 件而外,每個組件都是免費的。當初，由於用戶 數量少，就 把所有的組件都安裝在一個服務器 硬件 上面；其主要目的是節省帶寬費、託管費以及硬件購置費。圖1-1是其基本結構邏輯。
圖1-1 所有應用運行在一個服務主機上的邏輯圖
隨着公司商業推廣的進行，訪問該網站的用戶數量急劇增加。加之高考即將臨近，估計未來幾個月內，用戶數量可能成幾何級的增長，這對於 公司來說，應該是件好事。但是，隨着用戶的增長，現行的平臺 將無法支撐更大規模 的訪問服務。
由於是商業網站，保證其365*7*24可用是必須的了。以一個服務器運行所有程序 ，將可能面臨如下幾 個問題：
◆ 故障：只要任何一個組件服務出故障，整個服務都會停止。
◆ 擴展：爲提高性 能 或存儲容量，可以增加內存 等部件，但 總有一個限度。
◆ 性能：用戶越多，性能越差，速度越慢。
◆ 帶寬：用戶越多，消耗的帶寬也就越大，但是單個服務器的帶寬是固定的，理論值是1G，當帶寬消耗帶一定量時，即不能提供 訪問，也無法在增加帶寬。
◆ 硬件冗餘：服務器任何一個部件實效，整個網站的服務都不再可用。
把這些不利狀況歸納起來，就是現行的網站不具備高可用、可擴展、負載 均衡的特 點。儘管當前網站運行狀況還能應付，但對於上述幾個方面的憂慮卻令企業負責人寢食難安，他要求務必在高考來臨之前解決這些問題。
1.2 功能 需求
本系統爲典型的互 聯網 服務型網站,需要達到365*7*24可提供訪問服務,用現在流行的專業術語描述,就是高可用、可擴展、負載均衡 的架構；只有這樣的架構，纔有可能達到這個要求。
1.2.1 高可用
高可用是指在一段時間內（通常是一年），系統能正常提供服務的時間，它是以一個百分比來度量，如可用性99.99%。當然，沒 有任何人能保證系統可用性達到100%，但可以通過良好的設計 ，不斷地 接近100%。對外宣稱小數點後能到達9的個數，是一個技術 團隊 實力的體現。
1.2.2 可擴展
用戶的增加，引起訪問數乃至流量的增加，這種情形下，需要對系統進行擴容，以應對這種快速增長。對於提供高可用服務的互聯網網站，其 對可擴展的基本要求就 是在保持系統服務不終止的情況下，透明的擴充容量，即用戶不知道擴容的存在，或者說是擴容不對現有的服務產生任何負面作用。這 些擴展主要包括：帶寬擴展、 服務器擴展、存儲容量擴展、數據庫擴展等，當然也包括主機增加內存等方面的擴展。只要能保證可以在線擴展，我們就可以認爲系統具有很 好的擴展性。
1.2.3負載均衡
一個應用或服務由數個物理服務器提供,並且每個物理服務器運行的應用或服務是相同的,我們可以讓用戶的訪問通過某種控制策略,把 負載分攤到不同的物理服務 器,從而保持每個物理服務器有比較合理的負載。同時,負載均衡還具備故障隔離的功能,當某些物理服務器失效時，自動從負載轉發隊列剔 除故障服務器，一旦故 障得以恢復，用戶訪問負載則自動加載上來。負載均衡一般是2層架構：轉發器和真實提供服務或應用的服務器。除了真實服務器可以失效且 不影響服務外，轉發器 也能做到其中一個失效，另外一個自動失敗切換，從來保持服務的可用性。
當整個系統的負載趨於飽和時，通過增加物理服務器和擴充物理帶寬來擴容。增加物理服務器以後，系統的負載情況將重新在所有集羣的物理 服務器之間按照指定的 算法重新達到新的均衡。例如：現在有50000個併發連接，4個機器，按照wlc 等權值的負載策略，則每個物理服務器的大概連接數爲1250；此時再增加一個服務器，負載策略不變，則穩定後的每個物理服務器連接數 大概爲1000。
1.2.4 平臺狀態可視化
儘管有前面描述的措施保證系統的高可用、可擴展及負載均衡，但我們還需要隨時知道系統的運行狀態，一旦有機器失效或者某個服務不可 用，應當及時發現並及時 處理，而不要讓故障一直積累，直到所有的服務都不可用以後，再來處理就談不上什麼高可用了。因此，監控平臺的啓用是不可或缺的了，有 了它，就相當於多了一 雙“眼睛”，隨時隨地，我們都可以知道整個平臺是否正常運行。
監控平臺可視化可以以以下幾個方面予以表現：
◆ web方式，即通過瀏覽器觀看被監控的對象 ；如正常狀態下，其 狀態（status）是以綠色填充並顯示一個OK。
◆郵件通知，發生故障時，到達設定重試次數和探測間隔時間後發送郵件給管理 員或相關人員，報 告問題的大致情況。
◆手機短信，這是非常有用和及時的功能。深夜時分，再也沒可能看web頁面 或查閱郵件，可以一 旦發生故障，手機短信卻能隨時通知管理員所發生的故障。
一般情況下，這3者是同時進行的：上班時間通過瀏覽器查看頁面顯示、打開郵件程序定時收取郵件、保持手機24小時在線。
第二章 方案選擇
根據前文的需求描述,我們有幾種可供選擇的方案,這些方案主要包括: 主機部件擴容、應用分離以及高可靠、可擴展、負載均衡等幾種方 案，下面我們分別對這幾種方案進行說明，然後再選擇最終的方案。
2.1 主機部件擴容
仍然是一個單獨的物理服務器，所有相關應用運行在它上面，爲了獲得更好的處理能力，可以通過增加處理器數量或更換頻率更高的處理器、增 加更大的硬盤、更換更大帶寬的網絡適配器（如幾個千兆網卡綁定）、使用磁盤陣列等方式，達到一定限度的性能增加。
2.1.1 主機部件擴容的優點
主機部件擴容的主要優點包括：
1、 不改變系統的邏輯。增加部件後，開機就能運行原來的應用。
2、 節省空間。在物理服務器機箱內增建部件，不會再增加佔用idc機房的機位。
3、 節省能源和線纜等。
4、 硬件維護簡單。
5、 維護成本低。一個服務器，不必僱用專業的運維人員，人力資源成本極低。
2.1.2 主機部件擴容的缺點
單個物理服務器擴容，一般需要停機關閉電源後才能操作，這意味着在擴容的時候服務不可用。同時，由於總線速度/帶寬等方面的限制，擴 容到一定程度後，性能 的增長效果反而會下降。另外一個瓶頸就是不具備高可用和可擴展性性，隨着用戶的增加，訪問的迅猛增加，故障率增加導致服務不可用的幾 率大大增加。因此要靠 部件擴容來應對用戶增長，是不可能從根本上解決問題的。
2.1.3 主機部件擴容成本組成
主要的成本是購買服務器配件，如cpu、內存等。
2.2 應用分拆
應用分拆就是再購買一個服務器，把相關應用單獨分佈在獨立的服務器上。例如把apache和php部署在一個物理服務器，mysql 數據庫單獨部署在一個物理服務器。圖2-1是其邏輯結構。
圖2-1 應用拆分後的邏輯圖
2.2.1 應用分拆的優點
應用分拆的主要優點包括：
1、 平臺結構更加簡潔。這對於排除故障很有幫助，同時對調試工作，也是很有利的。
2、 更高的系統性能。
3、 維護成本較低。只增加了一個服務器。
4、 故障概率降低。舉例來說，原來所有的應用都在一個服務器上，系統運行過程可能產生較高的磁盤I/O;應用分拆後，單 個服務器的磁盤I/O理所當然的降低，出故障的機率也就降低了。
5、 數據可靠性得以增強。當以單個服務器單個硬盤運行所有應用的時候，文件 系統或硬盤發生故 障，存儲在磁盤上的數據可能全部丟失；而使用2個服務器分開來運行web和數據庫以後，數據全部丟失的可能性降低了—web服務器的 硬盤壞了，不會引起數據庫服務器數據的丟失；反之亦然。
2.2.2 應用分拆的缺點
應用分拆的主要缺點包括：
1、 成本增加。這些增加的成本有購買服務器的成本和增加託管機位的成本。
2、 增加能源耗費和線纜。
3、 維護複雜度增加。要維護2個服務器。
4、 存在單點故障，不能實現高可用，更不能應對未來不斷增長的業務需求。
2.3 高可用、可擴展、負載均衡解決方案
高可用、可擴展、負載均衡的方案是在應用分拆的基礎 上， 通過增加冗餘物理服務器來避免單點故障。可擴展性表現在系統強大的容量伸縮能力，可以根據用戶數量，隨時增加或減少資源（服務器或帶 寬），而不會對正常的 服務產生影響。要保證365*7*24不間斷服務，高可用、可擴展、負載均衡這幾項往往需要結合在一起，才能到達理想的效果。
2.3.1高可用、可擴展、負載均衡解決方案的優點
高可用、可擴展、負載均衡的方案的主要優點包括：
1、 高可用。降低了系統故障恢復時間，從而降低運營壓力和由此帶來的負面影響。試想一般的場景，當系統不可用時，來自 用戶或同事的催促會對系統運維人員產生巨大的壓力，這種壓力隨停機時間的增加越發令人恐慌。
2、 高可靠性。由於冗餘服務器的使用，最大限度地減少了單點故障，這就保證了業務的持續性和穩定性。
3、 可擴展性。通過增加物理服務器，極大地增強了運算能力和處理速度。
4、 負載均衡能力。不但增強了系統的總體吞吐能力，而且還具備故障隔離和失敗切換的功能，這也是保證系統高可用的一個方面。
5、 降低長期維護成本。
6、 不能保證100%的高可用。
7、 可以應對不斷增長的業務需求。
2.3.1高可用、可擴展、負載均衡解決方案的缺點
高可用、可擴展、負載均衡解決方案的缺點主要有：
1、 先期投入成本較高。需要購置更多的服務器、增加機位、僱用專職技術維護人員。
2、 實現技術複雜。
3、 需要更改應用程序邏輯或程序本身。
4、 需要更多的輔助資源，如監控系統、共享存儲系統等。
2.4 方案選擇
通過前面的對比，可以知道每種方案都有其優勢和不足，但從業務本身特點和着眼於將來這些方面考慮，高可用、可擴展、負載均衡的方案應 該是不二之選。根據筆 者以前實施的數個類似的實際應用，這個方案是經得起考驗的、也是成熟的。據調查，目前有不少互聯網網站也採用了這樣的架構；同時也有 一些機構開始考慮採用 筆者所發佈的方案。
筆者已經實施的高可用、可擴展、負載均衡的網站有：某某心理網、某某技術在線、某某論壇、某某通行證、某某在線收藏等等。
第三章 高可用、可擴展、負載均衡方案設計
高可用、可擴展、負載均衡方案包括硬件和軟件 兩個主要的方面.硬 件有服務器、交換機、遠程管理設備；軟件包括操作系統、負載均衡軟件、web應用軟件（這裏是apache和php）、數據庫軟件 mysql、監控軟件Nagios 等。
3.1 系統總體架構
高可用、可擴展、負載均衡的總體架構分爲負載均衡層、應用層、數據庫層及共享文件系統三層。其中數據庫和共享文件可看成同一個層次， 圖3-1展示了這個層次邏輯。
圖3-1 3層結構的高可用、可擴展、負載均衡結構
3.1.1 總體架構中各層的作用
◆負載均衡層：
負載均衡層負責負載轉發或失敗切換，一般情況下由2個服務器組成一組，一個充當主服務器，另一個充當備用服務器。用戶的請求首先達到 負載均衡層，然後負載 均衡設備根據指定的算法把負載轉發到第二層的某個應用服務器，應用服務器響應這個請求並進行相應的處理（如進行數據庫連接、讀寫文件 等操作），然後把數據 返直接返還給用戶（這是DR模 式 ），或者先返還給負載均衡器，封包後再返還用戶（這是NAT模式）。
使用主備方式的負載均衡環境，當主設備發生故障或失效時，備份負載均衡器會自動接管它的工作—即失敗切換（Failover）功能。
與一般應用層負載均衡（如apache負載均衡）不同的是，內核層的負載均衡具備對後面真實應用服務器進行健康檢查/存活檢查的功 能，一旦真實應用服務器的某個主機實效，負載均衡器能自動地把故障隔離；而當這個故障得也恢復時，則再把它再加入先前的轉發隊列。
◆ web應用層：
web應用層由兩個或2個以上的物理服務器組成，運行諸如apache+php之類的應用，本方案的具體應用是 apache+php。在這些物理服務器上，運行相同的應用，但物理服務器的配置可以不相同；爲求得一致的性能，可以使用硬件配置完 全相同的服務器。
Web 應用層一個比較困難的問 題是數據同步。假定有3個web應用服務器，現在需要修改某些php程序，可以選擇的操作方式有：
1、 登錄每個服務器，逐個進行修改，或者用scp複製到其他服務器。
2、 修改其中的一個服務器的文件，使用rsync這樣的工具 進行同 步。
3、 共享文件系統，如NFS、分佈式文件系統等。
方法1和2是把應用所需的文件/數據在每個服務器上各自保存一份，當其中的任何一個服務器的數據發生變化，則需要以某種方 式把變化同步到其他服務器。方法 3是所有服務器共享同一份數據，因此不存在數據同步的問題。在筆者的某個工作場景中，曾有過用方法2同步各服務器數據的經歷，這種方 式耗費系統/網絡資 源，特別是需要的同步數據巨大無比時，系統性能下降更是明顯。同時，怎樣選擇同步間歇，也難以權衡—同步間歇短了，前一次同步還未完 成，後一個同步又開始 了，如此堆積，佔用大量的系統資源；同步間歇長了，用戶的訪問結果會不一致（如bbs發帖子，卻很長時間顯示不出來，因爲其他用戶訪 問的可能是另外沒有同 步過數據的服務器）。對於web應用類型的集羣服務，最合適的方式就是共享文件系統這樣的方式。即保證了數據的一致性，又有較好的速 度和性能。爲保證數據 的可靠性和性能，本案採用分佈式文件系統moosefs 作爲web應用的共享存儲。
◆ 數據庫層:
在互連網領域,mysql無疑是使用得最多的數據庫平臺,估計其在數據庫市場的佔用率超過40%。Mysql先被SUN system 收購，SUN 又被 ORACLE收購，讓人眼花繚亂，以至於不少人對開源數據庫的未來發展擔憂。但這些，並不妨礙mysql的易用性和受歡迎的程 度。
爲了保證mysql的高可用性，mysql有2種方法來實現：主從複製和mysql cluster(中文 翻譯成“簇”)。在 實際應用中，很少聽說有人使用mysql cluster，因爲這個配置過程過於複雜，而且還有很多地方不完善。對於一般的應用場 景，使用mysql主從複製（一主一從或一主多從）就能滿足要求。如果負載再大一些的應用，可以再增加讀寫分離的機制 ，提高性 能和可靠性。本方案初始設計使用一主一從的方式，同時使用腳本 ，在夜間 用戶訪問少的時候，對整個數據庫進行完全備份。
數據庫數據的存儲，即可以放在本地硬盤，也可以使用分佈式共享存儲系統。使用分佈式共享存儲系統，能大大提高其性能和速度。分佈式共 享系統將在下面介紹。
◆ 分佈式文件系統
在以前的項目裏，筆者曾經用單個服務器以nfs的方式共享存儲給應用層的服務器，當用戶數量少於一定規模的時候，似乎也能很好的工 作。爲了保證數據的安全性，增加一臺服務器用rsync對這個nfs的共享數據進行同步備份。圖3-2說明了其結構特徵。
圖3-2 應用程序共享NFS文件系統
這種架構除了性能問題而外，還存在單點故障，一旦這個NFS服務器發生故障，所有靠共享提供數據的應用就不再可用，儘管用 rsync方式同步數據到另外一 個服務器上做NFS服務的備份，但這對提高整個系統的性能毫無幫助。基於這樣一種需求，我們需要對NFS服務器進行優化或採取別的解 決方案，然而優化並不 能對應對日益增多的客戶端 的 性能要求，因此唯一的選擇只能是採取別的解決方案了；通過調研，分佈式文件系統是一個比較合適的選擇。採用分佈式文件系統後，服務器 之間的數據訪問不再是 一對多的關係（1個NFS服務器，多個NFS客戶端），而是多對多的關係，這樣一來，單個磁盤的i/o降低，從而使得整個存儲系統的 性能大幅提升。
到目前爲止，有數十種以上的分佈式文件系統解決方案可供選擇，如lustre,hadoop,Pnfs等等。我嘗試了 PVFS,hadoop, moosefs這三種應用，參看了lustre、KFS等諸多技術實施方法，最後選擇了moosefs（以下簡稱MFS）這種分佈式 文件系統來作爲共享存 儲服務器。爲什麼要選它呢？
1、 實施起來簡單。MFS的安裝、部署、配置相對於其他幾種工具來說，要簡單和容易得多。
2、 不停服務擴容。MFS框架 做好後，隨 時增加服務器擴充容量；擴充和減少容量皆不會影響現有的服務。注：hadoop也實現了這個功能。
3、 恢復服務容易。除了MFS本身具備高可用特性外，手動恢復服務也是非常快捷的，原因參照第1條。
4、 我在實驗過程中得到作者的幫助，這讓我很是感激。
MFS特性（根據官方網站翻譯）
★ 高可靠性（數據能被分成幾個副本存儲在不同的計算機裏）
★ 通過增加計算機或增加新的硬盤動態擴充可用磁盤空間
★ 可以設置刪除文件的空間回收時間
- [root@mysql-bk serydir]# mfsgettrashtime bind-9.4.0.tar.gzbind-9.4.0.tar.gz: 600
★ 爲文件創建快照
MFS文件系統的組成
1、 元數據服務器。在整個體系中負責管理管理文件系統，目前MFS只支持一個元數據服務器master，這是一個單點故障，需要 一個性能穩定的服務器來充當。希望今後MFS能支持多個master服務器，進一步提高系統的可靠性。
2、 數據存儲服務器chunkserver。真正存儲用戶數據的服務器。存儲文件時，首先把文件分成塊，然後這些塊在數據服務器 chunkserver之間複製（複製份數可以手工指定，建議設置副本數爲3）。數據服務器可以是多個，並且數量越多，可使用的“磁 盤空間”越大，可靠性 也越高。
3、 客戶端。使用MFS文件系統來存儲和訪問的主機稱爲MFS的客戶端，成功掛接MFS文件系統以後，就可以像以前使 用NFS一樣共享這個虛擬性的存儲了。
圖3-3展示了moossfs文件系統的基本結構：
圖3-3 moosefs 文件系統體系結構（圖片來源：http://www.moosefs.com/pages/mfs.html ）
3.1.2 網絡劃分
根據業務特點，以及需要應對用戶數急劇增加的要求，需要對這個系統進行網絡劃分。本系統需要劃分出兩個網段，一個公網網段和一個內部 /私有網段。
公網網段（全球唯一ip地址）提供給負載均衡器和應用服務器使用。爲了提供最高的訪問轉發性能，負載均衡採用直接路由的模式（DR），因 此真實提供服務的應用服務器也得使用與負載均衡器相同網段的公網ip地址。圖3-4是直接路由模式的訪問路徑。
圖3-4 用戶訪問路徑
從這個圖示我們可以得知，用戶發出請求後先經過負載均衡器，再被轉發到真實的應用服務器，數據返還時，直接給用戶了，而不必經過負載 均衡器，這極大地增強了網絡的吞吐能力。
內部網絡主要是在應用服務器、數據庫、共享存儲之間進行通訊使用。使用192.168這樣的私有地址，即保證了系統的安全，又減少了 它對其他部分的影響。
應用服務器同時屬於這個兩個網段，因此它需要者少有兩個網卡用於網絡連接。
3.1.3系統架構評價
高考中國網高可用、可擴展、負載均衡設計方案，基本解決了單點故障（數據庫和分佈式文件系統的元數據服務器還是存在單點故障）；可 擴展能力得以大大提高— 應用服務器可以按需擴展、分佈式文件系統可以按需擴展、數據庫從服務器可以按需擴展—這種擴展可以線形的增強性能和速度；負載均衡方 面，負載均衡器具備內 核級的負載均衡功能、分佈式文件系統也具備數據存儲和訪問的負載均衡功能、mysql數據庫在實現讀寫分離後，也可實現良 好的負載均衡能力。
因此，從局部到整體，都具備了高可用、可擴展、負載均衡的能力，這些措施，強有力的保證了系統的持續服務，同時也具備了非常靈活的伸 縮特性。
3.2 部件/工具選擇
部件/工具選擇主要在硬件和軟件這個兩個方面，根據前文的設計，也按3層模式來說明各層的部件選擇。
3.2.1 負載均衡層的部件選擇
◆硬件
本層需要服務器2臺，並且不需要太高的配置即可勝任，使用市場上入門 級的服務 器即可滿足要求，爲了減少託管機櫃的佔用，使用1u尺寸的機架式服務器是最佳的選擇。表3-1是某個生產環境負載均衡器的硬件配置。
| 表3-1 負載均衡服務器的配置及成本 | ||
| 名稱 | 描 述 | 單價 |
| CPU | Intel Xeon 5405 2.0G | ￥1320 |
| 主板 | Intel S5000VSA | ￥1780 |
| 硬盤 | 希捷500G ST3500320NS | ￥580 |
| 內存 | 南亞4G/667 FBD NT8GTT72U4PB6UD-3C | ￥740 |
| 機箱 | 聯智 1U機箱（型號：1365） | ￥420 |
| 電源 | 臺達500瓦電源 | ￥720 |
| 風扇 | 酷冷1U純銅 | ￥150 |
| 合計（含稅 3% ） | ￥ 5900 | |
這個服務器是在市場上組裝的，當然，如果預算資金充足，可以自行購買品牌機。由於負載均衡的主要任務是轉發，系統運行時負載非常的 小，所以也可以使用配置更低一點的服務器或者使用其他淘汰下來的機器。
◆軟件
軟件包括2個部分：操作系統和應用程序。在本方案中，完全選擇開源且免費的軟件方案。
操作系統方面，使用centos 和 FreeBSD。由於lvs已經包含在linux發行版的內核中，因此在負載均衡器中使用centos5.2作爲操作系統，比 選擇freebsd要有優勢（也可以選擇freebsd，不過配置起來要複雜一些）。
應用程序方面，負載均衡器使用lvs及keepalived來實現負載均衡，同時實現負載均衡器本身的失敗切換 （failover）–主負載均衡器失效備 份負載均衡器自動接管轉發、主負載均衡器恢復後負載自動被主負載均衡器接管。也有另外的方案可供選擇，如lvs+heatbeat。 不過這與 keepalived的方案相比較，配置操作更復雜。Keepalived安裝成功以後，僅僅需要使用一個配置文件，就實現了我們所 要的全部功能；而用 heartbeat 則需要撰寫資源文件、撰寫運行腳本等等。
通過下列站點取得負載均衡所需的軟件資源：
1、 操作系統 centos 5.2。 http://www.centos.org
2、 Lvs內核ipvsadm-1.24。 http://www.linuxvirtualserver.org
3、 負載均衡失敗切換框架工具 keepalived-1.1.17. http://www.keepalived.org
3.2.2 應用層部件選擇
應用層主要是運行web服務，它由apache整合php來完成。爲了使用分佈式共享文件系統，需要額外的軟件來實現文件 系統的掛接。要使apache發 揮更好的性能，需要使用apache的worker模式（默認是prefork）。在worker模式下，通過查看進程數，可以發現 開啓的進程數遠遠少於 默認的prefork模式。Worker模式需要4G以上的內存支持才能發揮較好的作用。
◆硬件
與負載均衡層所需的服務器硬件相比，所需的硬件要求差別不是太大。因此我們可以採用與負載均衡層相同的配置，增加內存到8G。從 成本看，增加4G內存大概 就是增加幾百元的成本而已。前文描述過，應用層至少需要2個以上的服務器，建議初始配置使用3個服務器，以後根據業務需求再逐步擴充 服務器的數量。反之也 可以根據用戶數量的降低減少服務器數量。表3-2是某個生產環境的服務器硬件配置。
| 表3-2一個組裝服務 器的配置及成本 | ||
| 名稱 | 描 述 | 單價 |
| CPU | Intel Xeon 5405 2.0G | ￥1320 |
| 主板 | Intel S5000VSA | ￥1780 |
| 硬盤 | 希捷500G ST3500320NS | ￥580 |
| 內存 | 南亞8G/667 FBD NT8GTT72U4PB6UD-3C | ￥1740 |
| 機箱 | 聯 智1U機箱（型號：1365） | ￥420 |
| 電源 | 臺達500瓦電源 | ￥720 |
| 風扇 | 酷冷1U純銅 | ￥150 |
| 合計（含稅 3% ） | ￥ 6900 | |
◆軟件
基於使用開源軟件的宗旨，本層的操作系統可使用Centos或FreeBSD，甚至是其他GNU/linux或者solaris。應 用程序包括了web應 用apache和php;共享文件系統的掛接需要Fuse(系統默認安裝)及掛接程序,本方案採用moosefs文件系統。
通過下列站點取得負載均衡所需的軟件資源：
1、 操作系統 centos 5.2。 http://www.centos.org
2、 web程序apache。 http://www.apache.org
3、 php程序。http://www.php.net
4、 分佈式文件掛接工具moosefs. http://www.moosefs.org .
3.2.3 分佈式文件系統及數據庫層部件的選擇
本層包含數據庫和分佈式文件系統。對於數據庫來說，需要更快的處理能力，即頻率更高的cpu和更大的內存；而對於分佈式文件系統，則 需要大容量的硬盤，以便可以存儲更多的數據。
◆硬件
（一）數據庫硬件
主從複製最少要2個服務器，本方案初始設計使用2個服務器，一主一從。以後可以根據業務增長實現擴充，形成一主多從、速寫分離的方 式。這樣既保證了數據安 全，又能大幅提高負載。數據庫服務器仍然使用1u機架式服務器，安裝4核雙cpu，16G內存，300G sas硬盤2個（做成raid 10）。數據庫文件即可使用本地硬盤存儲，也可以使用分佈式文件系統。
（二）分佈式文件系統硬件
分佈式文件系統由2個部分組成：元數據服務器master和數據存儲服務器chunkserver。其中元數據服務器需要的配置要求 不高，按負載均衡器那 個標準配置就可以；數據存儲服務器則儘可能地增加硬盤數量也獲得最大的容量。初始配置時，使用一個元數據服務器，3個數據存儲服務 器。數據存儲服務器採用 2u機架式服務器，安裝6個1T sata硬盤，做成RAID 5，再用一個單獨的sata安裝硬盤來安裝操作系統，這樣可以獲得4.5T的可用磁盤空間來共享。3個服務器可提供總容量大概爲 13T存儲空間。以後再隨 業務增長增加數據存儲服務器。
◆軟件
（一）、數據庫
包括操作系統和數據庫兩個部分。操作系統可以是centos或freebsd。
數據庫可從 http://www.mysql.org 獲得。
（二）、分佈式文件系統
分佈式文件可以運行在各種類unix平臺，因此可以根據自己的喜好選擇開源和免費的操作系統。元數據庫服務器、數據存儲服務器及分佈 式文件客戶端（即第2層的應用服務器）都使用同一個軟件moosefs,它們之間的差別在於安裝過程配置過程使用哪些選項。
從http://www.moosefs.org 可以取得分佈式文件系統所需的軟件moosefs.
3.2.4 網絡設備選擇
出於安全和速度考慮,我們把網絡分成內外兩個網段,這兩個網段在物理上分離開,即使用兩個交換機.在我們這個方案裏,暫時沒有考慮交 換機的高可用性,因此 對交換機本身的質量要求比較高.具體的配置是:外網交換機使用100M 的cisco交換機,型號爲ws-c3560-48TS;內網使用華爲千兆交換機，型號是H3C S5100-SI。爲簡化管理，減少後期維護成本，交換機只設置了snmp community 用於服務器的流量監控和統計（每個有流量的端口對應一個服務器，就沒有必要再在每個服務器上配置和啓用snmp服務）。一個需要注意 的地方是，應用服務器 同時連接這兩個網絡，爲了安全，請勿在任何雙網絡的服務器設置NAT。
服務器的託管一般是在遠離辦公室的專用的機房，在通常情況下，如果出現不能登錄服務器等故障，需要親自跑到機房去處理，這很費時、費 錢。爲了解決這個問 題，需要購買一個KVM over ip的網絡設備，初始投資大概在5000元，安裝配置好KVM之後，基本上就不用去機房現場操作。
第4章 輔助功能—監控系統的設計
通過上述合理的方案設計,系統已經具備很高的可用性,即便有一些服務器實效或發生故障,也不會中斷服務。但是，發生故障或失效的服務 器，還是需要處理和恢 復服務的，不要等到所有服務都停了，才知道發生了故障。爲了隨時知道整個系統的運行狀態，我們需要一雙“眼睛”，時刻監控每個對象的 運行情況，如當某個服 務器負載過高時，給系統管理員發送報警信息。一旦有了這樣一個平臺，就實現了所有服務的可視性。
4.1 監控平臺選擇
這裏使用網絡監控軟件Nagios,個人認爲它最大的好處是可以發故障報警短信—只要Nagios監控的對象發生故障，系 統就會自動發送短信到手機上。下面摘錄Nagios官方網站的描述：
Nagios is an open source host, service and network monitoring program. Who uses it? Lots of people, including many big companies and organizations：Nagios是一個用來監控主機、服務和網絡的開放源碼軟件，很多大的公司或組織都在使用它。
Nagios 是開源的GNU源碼包，可以安裝在各種類unix平臺，如centos、freebsd、solaris 等，並且在各個平臺的安裝方法基本上是相同的。
Nagios爲了方便我們的管理工作，提供了至少3種表現手段：
1、web方式，即通過瀏覽器觀看被監控的對象；如正常狀態下，其狀態（status）是以藍色填充並顯示一個OK。
2、郵件通知，發生故障時，到達設定重試次數和探測間隔時間後發送郵件給管理員或相關人員，報告問題的大致情況。
4、 手機短信，這是非常有用和及時的功能了；晚上熟睡中，再也沒可能看web頁面或查閱郵件，可以一旦發生故障，相關人員馬上就 能知道發生故障。
一般情況下，這3者是同時進行的：上班時間開個瀏覽器看頁面顯示、打開郵件程序定時收取郵件、手機24小時在線。
4.2 nagios的監控對象
監控應該具備效率和有效性，不要把所有的對象都放在監控裏面，否則會發生類似“狼來了”這樣的問題。
4.2.1 負載均衡層監控對象
負載均衡層主要監控包括存活檢查及vip服務狀態檢查。
負載均衡器有2個服務器，首先需要知道的是這2個服務器是否存活。由於負載均衡器運行中既不耗費資源又不產生大的日誌（日 志直接輸出屏幕了），爲了保證其轉發效率和性能，不必再在上面安裝NRPE(nagios遠程插件 執行)。
用戶的訪問通常被指引到負載均衡設定的vip（在DR模式中，所有的服務器都用這個vip實現負載均衡功能），監控系統只需模擬用戶 訪問vip的url頁面，即可獲知服務是否正常。
4.2.2 應用服務器層監控對象
應用服務器層需要監控的對象可歸納成2種：服務監控和資源監控。服務監控的目的是掌握服務的存活情況，資源監控是爲了掌握系統的運行 情況。在實際運行中，系統狀態往往可以預測服務是否會出現問題，如較高的負載、較多的連接數、分區超過可用容量的80%等等。
應用層服務開啓了2個基本的網絡服務：sshd服務和web服務。前者用於遠程連接，後者用於web服務。當我們配置了對 sshd和web服務監控以後，默認狀況下已經啓用了服務器的存活檢查，所以不必單獨列出存活檢查這個項目。
資源監控包括：負載監控、磁盤使用空間監控、進程數監控、ip連接數監控這4個項目。Nagios服務器本身不能像監控服務一樣直接 監控系統資源，它需要 在被監控的服務器上安裝NRPE-nagios remote plug execute,由NRPE收集信息，然後返還信息給nagios服 務器。
圖4-1是一個nagios監控真實服務器的運行狀況。
圖4-1 nagios監控服務器和主機資源示意圖
應用服務器以fuse方式掛接和訪問moosefs分佈式文件系統，在監控資源裏，加入了磁盤使用的空間檢查，假如分佈式文件系統不 可用，則也可以通過這個磁盤監控可以體現出來。
4.2.3 數據庫層監控和分佈式文件系統監控
數據庫除了監控系統資源及服務端口外,需要額外創建一個空的數據庫和一個權限極低的帳號,NRPE通過這個賬號登陸mysql即可實 現對mysql數據庫 有效的監控.在數據庫複製過程中,輔助服務器很有可能複製失敗而停止數據同步,nagios用常規的插件無法檢查同步失敗,所 以需要手動寫個腳本,然後根 據腳本的輸出來判別是否正常.在把腳本整合到NRPE.
分佈式文件系統的監控分成兩個部分:元數據服務器和數據存儲服務器.除了監控系統資源外,還要監控這兩者服務。元數據服務器和數據存 儲服務器分別使用不同 的端口進行監聽，監控元數據服務器，用tcp 9420端口；監控數據存儲服務器，用tcp 9422端口。再綜合應用服務器層對磁盤空間利用的監控情況，我們就可以很準確的知道整個moosefs分佈式文件系統的運行狀況。
第5章 高可用、可擴展、負載均衡的總體架構技術實現
架構規劃和設計好以後，就需要選擇服務商，把設備放入idc機房，連接線纜，準備測試，無誤後上線運行。
5.1 選擇服務商及硬件上架
由於特殊的原因，中國的網絡形成了劃江而治的格局，這導致南北互聯很大的問題，即網通和電信互訪效果極差，要達到南北用戶都能快速的 訪問網站，得使用第三 方的idc機房。第三方的idc機房有兩種可選，一種是雙線機房，另一種是BGP機房。這兩種機房相比較，BGP效果最佳，但價格最 貴，可根據自己的資金 預算和性能要求來權衡使用哪一類機房。另外在選定前先測試一下機房的網絡狀況，同時瞭解其電力供應，空調設施已經服務器堆放密度，最 好觀察一下是否有知名 的網站也放置在這裏？
託管上選定以後，就要放置設備，接上電源、網線等線纜進行物理連接，爲開機運行做好準備，如果有必要，則需要對交換機作一些設置。原 則上是不需設置則不設置，保持簡單化總是對的。
在本方案中，我們採用了短信報警的機制，監控服務器本身並不發送短信的能力，因此需要選擇短信服務商，購買其服務，然後通過接口程序 來實現發送報警短信的功能。
5.2 安裝操作系統及部署相關軟件
除了負載均衡器而外，其他兩層的底層操作系統可以是任何一種類unix環境。理論上，負載均衡器也可以是其他類型的unix，如 freebsd，但這些系 統都不能linux來得方便，因爲lvs已經集成在各個linux的發行版裏了，不需要額外的處理，就可以實現lvs的轉發（主要內 核模塊是 ip_vs）。本方案以開源爲宗旨，並且考慮以節省成本，因此所有服務器都安裝和運行centos5。
5.2.1 負載均衡層的軟件部署
負載均衡層要實現負載均衡、故障隔離、失敗切換（負載均衡器之間failover）這3個功能，需要ipvsadm和 keepalived這個兩個工具緊 密配合來實現。Ipvsadm是lvs的核心，由它完成負載均衡和包轉發，但它本身沒有故障隔離和失敗切換的機制。在其他 人實施的一些項目裏，有采用 heartbeat這樣的工具來實現故障隔離和失敗切換。但heartbeat太複雜了—要寫ipvsadm腳本、要寫資源文件、要 安裝 ldirectord等等。現在我們採用keepalived這個工具，只需要一個配置文件，即可輕鬆實現故障隔離、失敗切換。
Lvs即可在安裝系統是選擇安裝，也可在系統安裝完成後下載ipvsadm源碼進行安裝。當按需求配置好 keepalived以後，運行keepalived 後，將能夠查看到lvs的內核模塊ip_vs已經被加載。
負載均衡器採用DR(直接路由)模式進行包轉發，這種方式可獲得最大的網絡吞吐能力。在DR模式下，負載均衡器與後面的真實服務器 （即本方案中應用服務器層）使用一個公用的ip地址，稱爲vip（virtual ip）。
5.2.2 應用層軟件部署
應用層涉及的軟件比較多，它主要包括apache、php、mysql 客戶端、分佈式文件系統客戶端、lvs客戶端等幾個部分。看 起來類別比較多，但只要配置好一個服務器以後，然後複製這個過程即可。這是因爲負載均衡服務器之間存在配置一致性的特點。
安裝步驟：
1、 安裝apache,php,mysql客戶端，並整合apache與php。
2、 安裝分佈式文件系統moosefs，接着掛接共享存儲。
3、 編寫lvs客戶端腳本，並賦予執行權限。腳本的內容大致如下：
- [root@tj-pp3 conf]# more /usr/local/bin/lvs_real#!/bin/bash#description : start realserverVIP=61.135.22.101
- /etc/rc.d/init.d/functions
- case “$1″ in
- start)
- echo ” start LVS of REALServer ”
- /sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
- echo “1″ >/proc/sys/net/ipv4/conf/lo/arp_ignore
- echo “2″ >/proc/sys/net/ipv4/conf/lo/arp_announce
- echo “1″ >/proc/sys/net/ipv4/conf/all/arp_ignore
- echo “2″ >/proc/sys/net/ipv4/conf/all/arp_announce
- ;;
- stop)
- /sbin/ifconfig lo:0 down
- echo “close LVS Directorserver”
- echo “0″ >/proc/sys/net/ipv4/conf/lo/arp_ignore
- echo “0″ >/proc/sys/net/ipv4/conf/lo/arp_announce
- echo “0″ >/proc/sys/net/ipv4/conf/all/arp_ignore
- echo “0″ >/proc/sys/net/ipv4/conf/all/arp_announce
- ;;
- *)
- echo “Usage: $0 {start|stop}”
- exit 1
- esac
5、 複製程序開發人員編寫的程序到apache設定的站點的根文檔目錄 ，檢查 apache語法，無誤後啓動apache。
6、 執行lvs客戶端腳本，運行 ip add檢查其正確性。
7、 啓動NRPE,並測試其正確性。
8、 總體檢查其正確性。
5.2.3 數據庫及分佈式文件系統部署
數據庫分主從兩個部分，主從數據庫的安裝方法是相同的，只要稍微改一下從服務器的選項文件，就能實現主從服務器之間的數據同步。爲 了更進一步保證數據安全性，可以寫一個腳本，自動執行一個全數據備份。
分佈式文件系統moosefs的原數據服務器和數據存儲服務器的安裝方法也是相同的，不同的地方在於啓動命令 和其關聯的配置文件。 存儲服務器之間的配置（只軟件及配置文件）是相同的，因此只要配置好其中的一個後，把這個配置文件複製到其它服務器相同的路徑即可。
爲了實現nagios的有效監控，需要在數據庫系統和分佈式文件系統安裝和配置nrpe.
5.3 測試
測試過程包括功能測試和性能測試 。
功能測試是逐個測試3層結構中各部分的功能是否正常，然後再模擬用戶行爲訪問站點，看總體功能是否實現。例如，在瀏覽器中輸入網站域 名（通過dns把網站域名指向LVS的vip地址），然後註冊用戶，成功後用這個功能登陸，看一切是否正常。
性能測試就是進行一些破壞性測試或者模擬大量用戶進行訪問。在這裏，最主要的是破壞性測試。在3層結構中，通過逐層逐個啓停服務甚至 服務器，看用戶訪問是 否正常。如停掉主負載均衡器，觀察輔助負載均衡器能否自動接管轉發服務；主負載均衡器恢復，轉發能不能再回到原來的狀態。
性能測試過程：
1、 負載均衡器啓停測試，主要目的在於其失敗切換failover功能。前文描述過，不再說明。
2、 應用服務器啓停測試,主要目的在於其故障隔離功能。當停掉一個web服務時，用戶訪問是否正常，再停掉一個web服務，情況 有怎樣？
3、 分佈式文件系統測試。停止其中的一個數據存儲服務，觀察從瀏覽器訪問網站是否受影響。再停止一個數據存儲服務器，情況又會如 何？
4、 數據庫測試。關閉從數據庫，觀察從瀏覽器訪問網站是否受影響。再啓動輔助服務器，看數據同步是否能再進行。
5、 做上述測試時，監控系統是否發送報警信息？
5.4 加固和平臺運行
加固主要是在系統安全性方面考慮。目前出於商業利益方面的原因，ddos攻擊相當的流行。要防範ddos攻擊，單靠主機本身的防火牆 如iptables或 傳統的硬件防火牆，基本沒效果。如果預算充足一點（其實前面的設計已經節省了大筆費用），買個防ddos流量攻擊的硬件設備部署在網 絡的前端，可以有效地 抵擋大部分非法訪問和攻擊。
當一切準備就緒，就可以正式上線，通知用戶可以使用本網站了。
第六章 方案實施後的效果
截至本文撰寫之時，高考中國網www.gaokaochina.com 目前已經上線運行有半個多月，運行狀況十分良好；目前的併發在線ip數只有幾百個，等到高考結束，學生填報自願時，流量就會急劇增 加，到那個時候，再觀察其運行狀況，以決定其伸縮。
附錄
主要參考資料
1.開源監控利器nagios實戰,田逸,http://net.it168.com/a2009/0309/267/000000267878.shtml
2.基於LVS的互聯網應用架設攻略,田逸,http://server.it168.com/server/2007-12-11/200712110855723.shtml
3.Nagios遠程監控軟件的安裝與配置詳解 ,田逸,http://netsecurity.51cto.com/art/200706/48728.htm
4.分佈式文件系統MFS(moosefs)實現存儲共享,田逸,http://net.it168.com/a2009/0403/270/000000270867.shtml
總體拓撲圖：
