Rails如果運用在正式上線的服務，便是相當需要配置為叢集(Cluster)服務。不過大部分使用Rails來建立叢集通常都是藉著 Apache mod_proxy，但在一些情況之下，他只有好設定的優點而已。另一種方式是利用一些Plugin及設定去模擬叢集的行為，不過這樣便是消耗 CPU的時間。 網路上可以看見許多叢集的文章，但多半都是介紹單方面的功能，或是許多實做的細節牽扯在一起。這篇文章用商業服務的整體規劃來看叢集及 Rails之間的種種問題與解決方法。文章後面附帶了一節是要解釋如何解讀apache benchmark的數據。而各位如果想要瞭解的是效能，數據上的差異，已經有一篇相當棒的可以參考： http://blog.kovyrin.net/2006/08/28/ruby-performance-results/ 本文章也同步發佈在我的blog http://kiwi.csie.chu.edu.tw/blog/archives/138 叢集(Cluster)Cluster中文翻譯為叢集，意指利用多台電腦完成同一工作來達到一般單台電腦不可能負擔的運算量或是穩定度。叢集基本上分做兩 種，一個是純粹作為計算的Computing Cluster (高效能計算叢集)，目的是進行平行運算。一個是用來提供各種Internet服務的，稱做Application Cluster (應用服務叢集)。其中Application 叢集有兩種實做方式，Failover (備援)方式，又可以稱做HA(High Availability)，主要目的是提供不會中斷的服務，而另一個Load Balance (負載平衡)方式，就是要提供承受高度負載的服務。一般人難以理解的部分，就是會將承受高負載與不會中斷這兩件事弄混，其實這兩項工作並非有直接相關，管理者可視硬體成本考量是否都要做。 既然是應用服務叢集，對於Internet上最主要的服務如HTTP Web，FTP，Mail等，便有相當成熟的軟體的解決方案。 這些解決方案通常是透過Windows Server或是Unix Server來實做，而在這邊我要推薦Linux。Linux的多工排程效率較Windows好，在高負載的時候核心不會因為過於忙碌而呈現容易當機等不 穩定狀態，而Linux本來在很早期就有比Windows更完善的開放原碼專案來解決這些問題，其中最著名的套件就是Linux-HA。 硬體的解決方案也不是沒有，稱做Layer 4 Switch，雖然有較親切的UI讓管理員快速設定，不過價格也昂貴許多。 一般來說Web叢集的架構大概會如下圖，而這裡更加上DB的部分，來說明商業服務是怎樣運作的。在這裡特別標出一個紅色箭頭表示為備援的架
構，當然DB的部分也是可以，不過也是比較複雜所以日後再談。這樣的切割，也會影響到硬體的需求。基本上來說跑Web的東西，不管是用什麼Server的
軟硬體，就是吃CPU(關連到一次request的速度)與記憶體(關連到最大負載人數)。而對資料庫而言，CPU就不見得，記憶體的要求會遠比跑Web
來得高。我會建議一般的Web伺服器為一般幾萬塊的PC即可，使用好一點的CPU，記憶體為2G。但資料庫就不能草率，盡量購買高級的伺服器，並具有
RAID5或6的硬碟儲存，及4G以上的記憶體。  在這個例子裡面，我們可以看見由四台Real Web Server及三台Real DB Server所組成的Web及DB叢集。而Virtual Server本身不具備任何的服務資料(如程式碼或圖片...等)，只有一個能力就是將連線重新導向到Real Server，而導向的方式有相當多種，之後會討論。這樣子利用重新導向來將服務負載分散給Real Server的方式就稱做負載平衡。 此外可以注意到 Virtual Server 2，除了上述的功能之外，就是可以偵測Virtual Server 1當機或是無法服務的時候，自動將自己的IP位置取代Virtual Server 1。這樣子的方式就稱做備援。
IP配置的方式IP是一個很大的問題，由現今商業服務的環境看來，沒有實體IP根本無法進行任何服務。傳統的作法有三種，NAT，Direct Routing，Tunneling。 >
NAT的方式是使用linux防火牆內建的虛擬IP對實體IP轉譯器來達成，其作法與現今的任何IP分享器無異，只是將同一個技術用在叢集服務上而 已。較常見的例子如一般網路上的論壇，如果人數較多，而論壇管理員又比較沒有經費取得多個實體IP，那就可以利用這個方式。Direct Routing方式的作法最單純，就是把所有要服務的伺服器都設定為實體IP，加上小小的arp修改，接著交給Virtual Server程式來處理就可以了。而Tunneling的方式最複雜，要用linux的VPN功能建立加密通道。之所以有這個方式，絕大多數都是因為伺服 器之間相隔一個很大的範圍，例如說台北與台南的伺服器。這個方式由於成本太高，比較少人在使用。 整體分析起來商業服務比較適合使用Direct Routing，但缺點也是有多少Real Server就需要多少實體IP。如果只是單純一兩個Real Server，又不太容易弄到很多實體IP，或許較適合NAT。 本篇文章強調商業服務，所以我會使用DR(direct routing)做為例子。 實做一個簡單的負載平衡環境接下來的章節，要用一個簡單的實例跟大家說明如何安裝軟體，而這不是文章後面測試所使用的環境。 假設有這些機器，如下：
 Virtual Server就是要用來做負載平衡的機器，目的也是為了剛剛所說進行連線重新導向。
Bind是一套相當著名的DNS服務軟體，我想Internet上九成都是使用這個來當作DNS服務，他有一個功能就是可以利用輪替(Round Robin)的方式來讓查詢者找到不同的IP，藉此將連線導向不同的機器。你可以試著下nslookup www.google.com指令，會注意到每次回來的3個IP順序是不太一樣的，而OS會自動以第一個IP作為你這次連線的對象。其實在這裡拿 RRDNS來比有點不太適合，因為他並不是針對封包來進行負載平衡，而只是單純切換IP而已。不過這個方式確實是早期進行負載平衡的方式，就連現在都還可 以在各處看見。 Linux Virtual Server計畫實行已經相當久遠，目的就是利用ipvsadm這一個以IP為主的負載平衡程式來達到讓所有使用TCP/IP的通訊協定都可以進行負載平 衡。由於他是由Linux Kernel所支援，效率相當好，佔用CPU資源相當的低。不過因為ipvsadm並無法針對任何layer 4以上的封包資料進行分析，並不像接下來談到的proxy一樣具有先分析HTTP再傳送的能力，如果將這個功能都寫進去，那要做在Kernel裡就不太可 能了。再者ipvsadm要手動設定也是一件難事，所以靠著ldirectord可以進行較簡單的設定。 Apache也是眾所皆知的HTTP Server，自2.0版開始對Proxy的功能大幅度地支援，儘管沒有Squid功能強大，卻整合了Apache，讓他可以進行一些意想不到的作法如 Reverse Proxy。以往Proxy都是單向地，從Server到Client，而Reverse Proxy是反過來，可以處理Client HTTP Post到Server的資料。也因此加上一些改善，雙向的Proxy可以完全變成HTTP負載平衡軟體。使用Apache執行其實是有一點浪費效能的， 另一個HAProxy就是純粹做負載平衡的，而本身也有簡單的快取能力。 這四種方法其實區別只在於，萬一有任何Real Server掛掉的時候，正要連線的那個人是否會斷線，換句話說就是Director是否有辦法偵測到連線對向是否斷線。結論是mod_proxy與 haproxy都可以偵測到，除非機器全部掛掉，或是director自己死掉，不然使用者完全不會感受到任何的中斷。而RRDNS就完全沒有辦法， ipvsadm也是至少會有一次連線會中斷。其實這個結論也是合理的，相對的代價就是使用Proxy方式消耗的CPU會較高。 小結文章到此介紹了Web叢集服務的觀念，以及一個簡單的實做案例。接下來的下集要為各位介紹各種Virtual Server的實做方式，以及分析各種方式對於Rails的優缺點。 |