高可用負載均衡最佳實踐三: 設計

高可用負載均衡最佳實踐三: 設計

http://www.sina.com.cn   2009年11月02日 18:06   IT168.com

【內容導航】

• 第1頁：系統整體架構
• 第2頁：部件/工具選擇

關鍵詞 文本Tag： 服務器集羣 操做系統 linux 負載均衡 服務器操做系統 高可用

　　【IT168 專稿】 （接前文1，2）高可用、可擴展、負載均衡方案包括硬件和軟件兩個主要的方面.硬件有服務器、交換機、遠程管理設備；軟件包括操做系統、負載均衡軟件、web應用軟件（這裏是apache和php）、數據庫軟件mysql、監控軟件Nagios 等。

　　1、系統整體架構

　　高可用、可擴展、負載均衡的整體架構分爲負載均衡層、應用層、數據庫層及共享文件系統三層。其中數據庫和共享文件可當作同一個層次，圖1展現了這個層次邏輯。
 

　　（一） 整體架構中各層的做用

　　◆負載均衡層：

　　負載均衡層負責負載轉發或失敗切換，通常狀況下由2個服務器組成一組，一個充當主服務器，另外一個充當備用服務器。用戶的請求首先達到負載均衡層，而後負載均衡設備根據指定的算法把負載轉發到第二層的某個應用服務器，應用服務器響應這個請求並進行相應的處理（如進行數據庫鏈接、讀寫文件等操做），而後把數據返直接返還給用戶（這是DR模式），或者先返還給負載均衡器，封包後再返還用戶（這是NAT模式）。

　　使用主備方式的負載均衡環境，當主設備發生故障或失效時，備份負載均衡器會自動接管它的工做-即失敗切換（Failover）功能。

　　與通常應用層負載均衡（如apache負載均衡）不一樣的是，內核層的負載均衡具有對後面真實應用服務器進行健康檢查/存活檢查的功能，一旦真實應用服務器的某個主機實效，負載均衡器能自動地把故障隔離；而當這個故障得也恢復時，則再把它再加入先前的轉發隊列。

　　◆ web應用層：

　　web應用層由兩個或2個以上的物理服務器組成，運行諸如apache+php之類的應用，本方案的具體應用是apache+php。在這些物理服務器上，運行相同的應用，但物理服務器的配置能夠不相同；爲求得一致的性能，可使用硬件配置徹底相同的服務器。

　　Web應用層一個比較困難的問題是數據同步。假定有3個web應用服務器，如今須要修改某些php程序，能夠選擇的操做方式有：

　　一、 登陸每一個服務器，逐個進行修改，或者用scp複製到其餘服務器。

　　二、 修改其中的一個服務器的文件，使用rsync這樣的工具進行同步。

　　三、 共享文件系統，如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的共享數據進行同步備份。圖2說明了其結構特徵。
 

　　這種架構除了性能問題而外，還存在單點故障，一旦這個NFS服務器發生故障，全部靠共享提供數據的應用就再也不可用，儘管用rsync方式同步數據到另一個服務器上作NFS服務的備份，但這對提升整個系統的性能毫無幫助。基於這樣一種需求，咱們須要對NFS服務器進行優化或採起別的解決方案，然而優化並不能對應對日益增多的客戶端的性能要求，所以惟一的選擇只能是採起別的解決方案了；經過調研，分佈式文件系統是一個比較合適的選擇。採用分佈式文件系統後，服務器之間的數據訪問再也不是一對多的關係（1個NFS服務器，多個NFS客戶端），而是多對多的關係，這樣一來，單個磁盤的i/o下降，從而使得整個存儲系統的性能大幅提高。

　　到目前爲止，有數十種以上的分佈式文件系統解決方案可供選擇，如lustre,hadoop,Pnfs等等。我嘗試了PVFS,hadoop,moosefs這三種應用，參看了lustre、KFS等諸多技術實施方法，最後選擇了moosefs（如下簡稱MFS）這種分佈式文件系統來做爲共享存儲服務器。爲何要選它呢？

　　一、 實施起來簡單。MFS的安裝、部署、配置相對於其餘幾種工具來講，要簡單和容易得多。

　　二、 不停服務擴容。MFS框架作好後，隨時增長服務器擴充容量；擴充和減小容量皆不會影響現有的服務。注：hadoop也實現了這個功能。

　　三、 恢復服務容易。除了MFS自己具有高可用特性外，手動恢復服務也是很是快捷的，緣由參照第1條。

　　四、 我在實驗過程當中獲得做者的幫助，這讓我非常感激。

　　MFS特性（根據官方網站翻譯）

　　★ 高可靠性（數據能被分紅幾個副本存儲在不一樣的計算機裏）

　　★ 經過增長計算機或增長新的硬盤動態擴充可用磁盤空間

　　★ 能夠設置刪除文件的空間回收時間

　　[root@mysql-bk serydir]# mfsgettrashtime bind-9.4.0.tar.gz

　　bind-9.4.0.tar.gz: 600

　　文件被刪除10分鐘後（600秒），才真正刪除文件，回收磁盤空間。

　　★ 爲文件建立快照

　　MFS文件系統的組成

　　一、 元數據服務器。在整個體系中負責管理管理文件系統，目前MFS只支持一個元數據服務器master，這是一個單點故障，須要一個性能穩定的服務器來充當。但願從此MFS能支持多個master服務器，進一步提升系統的可靠性。

　　二、 數據存儲服務器chunkserver。真正存儲用戶數據的服務器。存儲文件時，首先把文件分紅塊，而後這些塊在數據服務器chunkserver之間複製（複製份數能夠手工指定，建議設置副本數爲3）。數據服務器能夠是多個，而且數量越多，可以使用的"磁盤空間"越大，可靠性也越高。

　　三、 客戶端。使用MFS文件系統來存儲和訪問的主機稱爲MFS的客戶端，成功掛接MFS文件系統之後，就能夠像之前使用NFS同樣共享這個虛擬性的存儲了。

　　圖3展現了moossfs文件系統的基本結構：
 

　　（二） 網絡劃分

　　根據業務特色，以及須要應對用戶數急劇增長的要求，須要對這個系統進行網絡劃分。本系統須要劃分出兩個網段，一個公網網段和一個內部/私有網段。

　　公網網段（全球惟一ip地址）提供給負載均衡器和應用服務器使用。爲了提供最高的訪問轉發性能，負載均衡採用直接路由的模式（DR），所以真實提供服務的應用服務器也得使用與負載均衡器相同網段的公網ip地址。圖4是直接路由模式的訪問路徑。
 

　　從這個圖示咱們能夠得知，用戶發出請求後先通過負載均衡器，再被轉發到真實的應用服務器，數據返還時，直接給用戶了，而沒必要通過負載均衡器，這極大地加強了網絡的吞吐能力。

　　內部網絡主要是在應用服務器、數據庫、共享存儲之間進行通信使用。使用192.168這樣的私有地址，即保證了系統的安全，又減小了它對其餘部分的影響。

　　應用服務器同時屬於這個兩個網段，所以它須要者少有兩個網卡用於網絡鏈接。

　　（三）系統架構評價

　　高考中國網高可用、可擴展、負載均衡設計方案，基本解決了單點故障（數據庫和分佈式文件系統的元數據服務器仍是存在單點故障）；可擴展能力得以大大提升-應用服務器能夠按需擴展、分佈式文件系統能夠按需擴展、數據庫從服務器能夠按需擴展-這種擴展能夠線形的加強性能和速度；負載均衡方面，負載均衡器具有內核級的負載均衡功能、分佈式文件系統也具有數據存儲和訪問的負載均衡功能、mysql數據庫在實現讀寫分離後，也可實現良好的負載均衡能力。

　　所以，從局部到總體，都具有了高可用、可擴展、負載均衡的能力，這些措施，強有力的保證了系統的持續服務，同時也具有了很是靈活的伸縮特性。

內容導航

　　2、 部件/工具選擇

　　部件/工具選擇主要在硬件和軟件這個兩個方面，根據前文的設計，也按3層模式來講明各層的部件選擇。

　　（一）負載均衡層的部件選擇

　　◆硬件

　　本層須要服務器2臺，而且不須要過高的配置便可勝任，使用市場上入門級的服務器便可知足要求，爲了減小託管機櫃的佔用，使用1u尺寸的機架式服務器是最佳的選擇。表1是某個生產環境負載均衡器的硬件配置。
 

　　這個服務器是在市場上組裝的，固然，若是預算資金充足，能夠自行購買品牌機。因爲負載均衡的主要任務是轉發，系統運行時負載很是的小，因此也可使用配置更低一點的服務器或者使用其餘淘汰下來的機器。

　　◆軟件

　　軟件包括2個部分：操做系統和應用程序。在本方案中，徹底選擇開源且免費的軟件方案。

　　操做系統方面，使用centos和FreeBSD。因爲lvs已經包含在linux發行版的內核中，所以在負載均衡器中使用centos5.2做爲操做系統，比選擇freebsd要有優點（也能夠選擇freebsd，不過配置起來要複雜一些）。

　　應用程序方面，負載均衡器使用lvs及keepalived來實現負載均衡，同時實現負載均衡器自己的失敗切換（failover）--主負載均衡器失效備份負載均衡器自動接管轉發、主負載均衡器恢復後負載自動被主負載均衡器接管。也有另外的方案可供選擇，如lvs+heatbeat。不過這與keepalived的方案相比較，配置操做更復雜。Keepalived安裝成功之後，僅僅須要使用一個配置文件，就實現了咱們所要的所有功能；而用heartbeat 則須要撰寫資源文件、撰寫運行腳本等等。

　　經過下列站點取得負載均衡所需的軟件資源：

　　一、 操做系統 centos 5.2。 http://www.centos.org

　　二、 Lvs內核ipvsadm-1.24。 http://www.linuxvirtualserver.org

　　三、 負載均衡失敗切換框架工具 keepalived-1.1.17. http://www.keepalived.org

　　（二） 應用層部件選擇

　　應用層主要是運行web服務，它由apache整合php來完成。爲了使用分佈式共享文件系統，須要額外的軟件來實現文件系統的掛接。要使apache發揮更好的性能，須要使用apache的worker模式（默認是prefork）。在worker模式下，經過查看進程數，能夠發現開啓的進程數遠遠少於默認的prefork模式。Worker模式須要4G以上的內存支持才能發揮較好的做用。

　　◆硬件

　　與負載均衡層所需的服務器硬件相比，所需的硬件要求差異不是太大。所以咱們能夠採用與負載均衡層相同的配置，增長內存到8G。從成本看，增長4G內存大概就是增長几百元的成本而已。前文描述過，應用層至少須要2個以上的服務器，建議初始配置使用3個服務器，之後根據業務需求再逐步擴充服務器的數量。反之也能夠根據用戶數量的下降減小服務器數量。表2是某個生產環境的服務器硬件配置。
 

　　◆軟件

　　基於使用開源軟件的宗旨，本層的操做系統可以使用Centos或FreeBSD，甚至是其餘GNU/linux或者solaris。應用程序包括了web應用apache和php;共享文件系統的掛接須要Fuse(系統默認安裝)及掛接程序,本方案採用moosefs文件系統。

　　經過下列站點取得負載均衡所需的軟件資源：

　　一、 操做系統 centos 5.2。 http://www.centos.org

　　二、 web程序apache。 http://www.apache.org

　　三、 php程序。http://www.php.net

　　四、 分佈式文件掛接工具moosefs. http://www.moosefs.org.

　　（三） 分佈式文件系統及數據庫層部件的選擇

　　本層包含數據庫和分佈式文件系統。對於數據庫來講，須要更快的處理能力，即頻率更高的cpu和更大的內存；而對於分佈式文件系統，則須要大容量的硬盤，以即可以存儲更多的數據。

　　◆硬件

　　A、數據庫硬件

　　主從複製最少要2個服務器，本方案初始設計使用2個服務器，一主一從。之後能夠根據業務增加實現擴充，造成一主多從、速寫分離的方式。這樣既保證了數據安全，又能大幅提升負載。數據庫服務器仍然使用1u機架式服務器，安裝4核雙cpu，16G內存，300G sas硬盤2個（作成raid 10）。數據庫文件便可使用本地硬盤存儲，也可使用分佈式文件系統。

　　B、分佈式文件系統硬件

　　分佈式文件系統由2個部分組成：元數據服務器master和數據存儲服務器chunkserver。其中元數據服務器須要的配置要求不高，按負載均衡器那個標準配置就能夠；數據存儲服務器則儘量地增長硬盤數量也得到最大的容量。初始配置時，使用一個元數據服務器，3個數據存儲服務器。數據存儲服務器採用2u機架式服務器，安裝6個1T sata硬盤，作成RAID 5，再用一個單獨的sata安裝硬盤來安裝操做系統，這樣能夠得到4.5T的可用磁盤空間來共享。3個服務器可提供總容量大概爲13T存儲空間。之後再隨業務增加增長數據存儲服務器。

　　◆軟件

　　A、數據庫

　　包括操做系統和數據庫兩個部分。操做系統能夠是centos或freebsd。

　　數據庫可從 http://www.mysql.org 得到。

　　B、分佈式文件系統

　　分佈式文件能夠運行在各類類unix平臺，所以能夠根據本身的喜愛選擇開源和免費的操做系統。元數據庫服務器、數據存儲服務器及分佈式文件客戶端（即第2層的應用服務器）都使用同一個軟件moosefs,它們之間的差異在於安裝過程配置過程使用哪些選項。

　　從http://www.moosefs.org 能夠取得分佈式文件系統所需的軟件moosefs.

　　（四）網絡設備選擇

　　出於安全和速度考慮,咱們把網絡分紅內外兩個網段,這兩個網段在物理上分離開,即便用兩個交換機.在咱們這個方案裏,暫時沒有考慮交換機的高可用性,所以對交換機自己的質量要求比較高.具體的配置是:外網交換機使用100M 的cisco交換機,型號爲ws-c3560-48TS;內網使用華爲千兆交換機，型號是H3C S5100-SI。爲簡化管理，減小後期維護成本，交換機只設置了snmp community 用於服務器的流量監控和統計（每一個有流量的端口對應一個服務器，就沒有必要再在每一個服務器上配置和啓用snmp服務）。一個須要注意的地方是，應用服務器同時鏈接這兩個網絡，爲了安全，請勿在任何雙網絡的服務器設置NAT。

　　服務器的託管通常是在遠離辦公室的專用的機房，在一般狀況下，若是出現不能登陸服務器等故障，須要親自跑到機房去處理，這很費時、費錢。爲了解決這個問題，須要購買一個KVM over ip的網絡設備，初始投資大概在5000元，安裝配置好KVM以後，基本上就不用去機房現場操做。

　　下篇文章中，介紹監控系統的設計，敬請關注。