国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

Rails如果運(yùn)用在正式上線(xiàn)的服務(wù)，便是相當(dāng)需要配置為Cluster(叢集)服務(wù)。不過(guò)大部分使用Rails來(lái)建立Cluster通常都是藉著Apache mod_proxy，但在一些情況之下，他只有好設(shè)定的優(yōu)點(diǎn)而已。另一種方式是利用一些Plugin及設(shè)定去模擬Cluster的行為，不過(guò)這樣便是消耗CPU的時(shí)間。

網(wǎng)路上可以看見(jiàn)許多Cluster的文章，但多半都是介紹單方面的功能，或是許多實(shí)做的細(xì)節(jié)牽扯在一起。這篇文章用商業(yè)服務(wù)的整體規(guī)劃來(lái)看Cluster及Rails之間的種種問(wèn)題與解決方法。文章後面附帶了一節(jié)是要解釋如何解讀apache menchmark的數(shù)據(jù)。而各位如果想要瞭解的是效能，數(shù)據(jù)上的差異，已經(jīng)有一篇相當(dāng)棒的可以參考：
http://blog.kovyrin.net/2006/08/28/ruby-performance-results/

Cluster(叢集)

Cluster中文翻譯為叢集，意指利用多臺(tái)電腦完成同一工作來(lái)達(dá)到一般單臺(tái)電腦不可能負(fù)擔(dān)的運(yùn)算量或是穩(wěn)定度。Cluster基本上分做兩種，一個(gè)是純粹作為計(jì)算的Computing Cluster目的是進(jìn)行平行運(yùn)算。一個(gè)是用來(lái)提供各種Internet服務(wù)的Application Cluster。其中Application Cluster有兩種實(shí)做方式，F(xiàn)ailover 方式，又可以稱(chēng)做HA(High Availability)，主要目的是提供不會(huì)中斷的服務(wù)，而另一個(gè)Load Balance方式，就是要提供承受高度負(fù)載的服務(wù)。一般人難以理解的部分，就是會(huì)將承受高負(fù)載與不會(huì)中斷這兩件事弄混，其實(shí)這兩項(xiàng)工作並非有直接相關(guān)，管理者可是硬體成本考量是否都要做。

既然是Application Cluster，對(duì)於Internet上最主要的服務(wù)如HTTP，F(xiàn)TP，Mail等，便有相當(dāng)成熟的軟體的解決方案。 這些解決方案通常是透過(guò)Windows
Server或是Unix Server來(lái)實(shí)做，而在這邊我要推薦Linux。Linux的多工排程效率較Windows好，在高負(fù)載的時(shí)候核心不會(huì)因?yàn)檫^(guò)於忙碌而呈現(xiàn)容易當(dāng)機(jī)等不穩(wěn)定狀態(tài)，而Linux本來(lái)在很早期就有比Windows更完善的開(kāi)放原碼專(zhuān)案來(lái)解決這些問(wèn)題，其中最著名的套件就是Linux-HA。

硬體的解決方案也不是沒(méi)有，稱(chēng)做Layer 4 Switch，雖然有較親切的UI讓管理員快速設(shè)定，不過(guò)價(jià)格也昂貴許多。

一般來(lái)說(shuō)HTTP Cluster的架構(gòu)大概會(huì)如下圖，而這裡更加上DB的部分，來(lái)說(shuō)明商業(yè)服務(wù)是怎樣運(yùn)作的。在這裡特別標(biāo)出一個(gè)紅色箭頭表示為Failover的架構(gòu)，當(dāng)然DB的部分也是可以，不過(guò)也是比較複雜所以日後再談。這樣的切割，也會(huì)影響到硬體的需求。基本上來(lái)說(shuō)跑Web的東西，不管是用什麼Server的軟硬體，就是吃CPU(關(guān)連到一次request的速度)與記憶體(關(guān)連到最大負(fù)載人數(shù))。而對(duì)資料庫(kù)而言，CPU就不見(jiàn)得，記憶體的要求會(huì)遠(yuǎn)比跑Web來(lái)得高。我會(huì)建議一般的Web Server為一般幾萬(wàn)塊的PC即可，使用好一點(diǎn)的CPU，記憶體為2G。但資料庫(kù)就不能草率，盡量購(gòu)買(mǎi)高級(jí)的伺服器，並具有RAID5或6的硬碟儲(chǔ)存，及4G以上的記憶體。

在這個(gè)例子裡面，我們可以看見(jiàn)由四臺(tái)Real Web Server及三臺(tái)Real DB Server所組成的Web及DB Cluster。而Virtual Server本身不具備任何的服務(wù)資料(如程式碼或圖片...等)，只有一個(gè)能力就是將連線(xiàn)重新導(dǎo)向到Real Server，而導(dǎo)向的方式有相當(dāng)多種，之後會(huì)討論。這樣子利用重新導(dǎo)向來(lái)將服務(wù)負(fù)載分散給Real Server的方式就稱(chēng)做Load Balance。

此外可以注意到 Virtual Server 2，除了上述的功能之外，就是可以偵測(cè)Virtual Server 1當(dāng)機(jī)或是無(wú)法服務(wù)的時(shí)候，自動(dòng)將自己的IP位置取代Virtual Server 1。這樣子的方式就稱(chēng)做Failover。

IP配置的方式

IP是一個(gè)很大的問(wèn)題，由現(xiàn)今商業(yè)服務(wù)的環(huán)境看來(lái)，沒(méi)有實(shí)體IP根本無(wú)法進(jìn)行任何服務(wù)。傳統(tǒng)的作法有三種，NAT，Direct Routing，Tunneling。

整體分析起來(lái)商業(yè)服務(wù)比較適合使用Direct Routing，但缺點(diǎn)也是有多少Real Server就需要多少實(shí)體IP。如果只是單純一兩個(gè)Real Server，又不太容易弄到很多實(shí)體IP，或許較適合NAT。

本篇文章強(qiáng)調(diào)商業(yè)服務(wù)，所以我會(huì)使用DR(direct routing)做為例子。

實(shí)做

一個(gè)簡(jiǎn)單的Load Balance環(huán)境

接下來(lái)的章節(jié)，要用一個(gè)簡(jiǎn)單的實(shí)例跟大家說(shuō)明如何安裝軟體，而這不是文章後面測(cè)試所使用的環(huán)境。

假設(shè)有這些機(jī)器，如下：
D1(Director Server 1): P4 2.0G, 768M RAM, 10.1.1.60
R1(Real Server 1): P4 2.0G, 768M RAM, 10.1.1.61
R2(Real Server 2): P4 2.0G, 768M RAM, 10.1.1.62
OS：Fedora 6

Director Server就是要用來(lái)做Load Balance的機(jī)器，目的也是為了剛剛所說(shuō)進(jìn)行連線(xiàn)重新導(dǎo)向。

1. Bind 9實(shí)做RRDNS
2. Linux Virtual Server(ldirectord+ipvsadm)
3. Apache mod_proxy
4. HAProxy

Bind是一套相當(dāng)著名的DNS服務(wù)軟體，我想Internet上九成都是使用這個(gè)來(lái)當(dāng)作DNS服務(wù)，他有一個(gè)功能就是可以利用輪替(Round Robin)的方式來(lái)讓查詢(xún)者找到不同的IP，藉此將連線(xiàn)導(dǎo)向不同的機(jī)器。你可以試著下nslookup www.google.com指令，會(huì)注意到每次回來(lái)的3個(gè)IP順序是不太一樣的，而OS會(huì)自動(dòng)以第一個(gè)IP作為你這次連線(xiàn)的對(duì)象。其實(shí)在這裡拿RRDNS來(lái)比有點(diǎn)不太適合，因?yàn)樗麃K不是針對(duì)封包來(lái)進(jìn)行負(fù)載平衡，而只是單純切換IP而已。不過(guò)這個(gè)方式確實(shí)是早期進(jìn)行負(fù)載平衡的方式，就連現(xiàn)在都還可以在各處看見(jiàn)。

Linux Virtual Server計(jì)畫(huà)實(shí)行已經(jīng)相當(dāng)久遠(yuǎn)，目的就是利用ipvsadm這一個(gè)以IP為主的負(fù)載平衡程式來(lái)達(dá)到讓所有使用TCP/IP的通訊協(xié)定都可以進(jìn)行負(fù)載平衡。由於他是由Linux Kernel所支援，效率相當(dāng)好，佔(zhàn)用CPU資源相當(dāng)?shù)牡?。不過(guò)因?yàn)閕pvsadm並無(wú)法針對(duì)任何layer 4以上的封包資料進(jìn)行分析，並不像接下來(lái)談到的proxy一樣具有先分析HTTP再傳送的能力，如果將這個(gè)功能都寫(xiě)進(jìn)去，那要做在Kernel裡就不太可能了。再者ipvsadm要手動(dòng)設(shè)定也是一件難事，所以靠著ldirectord可以進(jìn)行較簡(jiǎn)單的設(shè)定。

Apache也是眾所皆知的HTTP Server，自2.0版開(kāi)始對(duì)Proxy的功能大幅度地支援，儘管沒(méi)有Squid功能強(qiáng)大，卻整合了Apache，讓他可以進(jìn)行一些意想不到的作法如Reverse Proxy。以往Proxy都是單向地，從Server到Client，而Reverse Proxy是反過(guò)來(lái)，可以處理Client HTTP Post到Server的資料。也因此加上一些改善，雙向的Proxy可以完全變成HTTP負(fù)載平衡軟體。使用Apache執(zhí)行其實(shí)是有一點(diǎn)浪費(fèi)效能的，另一個(gè)HAProxy就是純粹做負(fù)載平衡的，而本身也有簡(jiǎn)單的快取能力。

這四種方法其實(shí)區(qū)別只在於，萬(wàn)一有任何Real Server掛掉的時(shí)候，正要連線(xiàn)的那個(gè)人是否會(huì)斷線(xiàn)，換句話(huà)說(shuō)就是Director是否有辦法偵測(cè)到連線(xiàn)對(duì)向是否斷線(xiàn)。結(jié)論是mod_proxy與haproxy都可以偵測(cè)到，除非機(jī)器全部掛掉，或是director自己死掉，不然使用者完全不會(huì)感受到任何的中斷。而RRDNS就完全沒(méi)有辦法，ipvsadm也是至少會(huì)有一次連線(xiàn)會(huì)中斷。其實(shí)這個(gè)結(jié)論也是合理的，相對(duì)的代價(jià)就是使用Proxy方式消耗的CPU會(huì)較高。

安裝Bind 9與RRDNS

Bind的安裝已經(jīng)有很好的文章，請(qǐng)參考
http://turtle.ee.ncku.edu.tw/~tung/dns/bind_conf.html

在FC6上只要yum install bind就可以安裝。

要進(jìn)行的設(shè)定很簡(jiǎn)單，首先先修改named.conf，在options區(qū)塊裡面加入一行

接著修改你的正查設(shè)定檔(如果你的domain是test.com就應(yīng)該是test.com.hosts)。根據(jù)本例子，我改成：

請(qǐng)注意測(cè)試機(jī)器的DNS Server當(dāng)然就要設(shè)定成D1了，一旦使用nslookup成功地查到兩個(gè)會(huì)變動(dòng)的IP，那接著測(cè)試的時(shí)候URL就可以使用http://www.test.com。

安裝ipvsadm及l(fā)directord

參考文章：
http://zh.linuxvirtualserver.org/files/lvs.pdf
http://zh.linuxvirtualserver.org/node/272

基本上安裝了ipvsadm後就可以下指令手動(dòng)進(jìn)行負(fù)載平衡，而ldirectord只是有比較好看的設(shè)定檔。

D1機(jī)器：

接著在R1及R2上，你要設(shè)定好一個(gè)lo(loopback)的alias並且將IP設(shè)定為10.1.1.60，你可以建立/etc/sysconfig/network-scripts/ifcfg-lo:0或是使用xwindow的網(wǎng)路設(shè)定來(lái)編輯。

R1及R2機(jī)器：

加入

接著

內(nèi)容為

最後
service network restart

由於request封包是透過(guò)ipvsadm轉(zhuǎn)送過(guò)來(lái)，real server必須做一件事情就是不要更動(dòng)封包裡的mac address，而將這個(gè)mac address當(dāng)作response的mac address而送回去，如此client收到的資料才會(huì)正常。

安裝apache+mod_proxy

mod_proxy在2.0版後就是預(yù)設(shè)模組，而FC6上也算是內(nèi)建的套件。如果你還沒(méi)安裝的話(huà)，就yum install httpd。
編輯/etc/httpd/conf/httpd.conf
加入

重新啟動(dòng)之後就可以試試看了，不過(guò)要注意這樣的設(shè)定就是全部交由後端處理，事實(shí)上還可以加一些設(shè)定讓apache處理靜態(tài)資料的時(shí)候直接回傳節(jié)省時(shí)間。

安裝 haproxy

到了這個(gè)小節(jié)，你會(huì)發(fā)現(xiàn)工作越來(lái)越簡(jiǎn)單，就請(qǐng)各位參考

http://lightyror.wordpress.com/2007/06/04/%e5%9c%a8-centos-%e5%ae%89%e8%a3%9d-ruby-on-rails/

雖然透過(guò)rubyworks他會(huì)啟動(dòng)一些不見(jiàn)得是使用者需要的服務(wù)監(jiān)控程式，不過(guò)就請(qǐng)各位自行killall吧。
編輯/etc/haproxy.haproxy.conf
global及default區(qū)段都不用動(dòng)，而注意到listen區(qū)段，語(yǔ)法是listen {appname} {ip:port}
修改成

之後service haproxy start即可

AB(Apache Benchmark)數(shù)據(jù)解讀

ab指令的語(yǔ)法是 ab -c {同時(shí)進(jìn)行的request數(shù)量} -t {時(shí)間} {url} 或是 ab -c {同時(shí)進(jìn)行的request數(shù)量} -n {次數(shù)} {url}
ab的測(cè)試方式有兩種：
1. -t {秒數(shù)}
2. -n {request次數(shù)}
兩種方式都可以取得可以觀察的數(shù)據(jù)，不過(guò)如果-n太少的話(huà)，就沒(méi)有意義。我通常都是使用-t 30或是-t 60。而這樣的測(cè)試有另一個(gè)好處是，在測(cè)試的其中，可以找真的人在一定時(shí)間內(nèi)去實(shí)際點(diǎn)點(diǎn)看你的程式，如果時(shí)間都過(guò)去了(先別跟他講已經(jīng)跑完了)，他還是覺(jué)得速度沒(méi)有差，那表示效能有到使用者能夠接受的感受。而需要效能數(shù)據(jù)，其實(shí)也是為了使用經(jīng)驗(yàn)法則推算出應(yīng)用程式最多可以容納幾個(gè)使用者註冊(cè)。

以下舉個(gè)一個(gè)例子來(lái)解讀：

[root@dsa1 ~]# ab -c 20 -t 30 http://some.machine.com/test/#這裡是版權(quán)宣告This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/Copyright 2006 The Apache Software Foundation, http://www.apache.org/Benchmarking xxx (be patient)#這裡會(huì)將完成的req次數(shù)顯示出來(lái)，如果每超過(guò)5000會(huì)再次顯示Finished 1028 requests#主機(jī)資訊Server Software:        Apache/2.2.3Server Hostname:        xxxServer Port:            80Document Path:          /test/#要注意，如果傳輸?shù)馁Y料大小超過(guò)1MB，表示使用ADSL的人多少會(huì)因?yàn)橘Y料量感受到緩慢#，就可能不會(huì)是準(zhǔn)確的測(cè)試結(jié)果Document Length:        8943 bytes#這裡表示你下了 -c 20Concurrency Level:      20#總測(cè)試時(shí)間，應(yīng)該不會(huì)跟-t的時(shí)間差太遠(yuǎn)Time taken for tests:   30.27095 secondsComplete requests:      1028#這裡的Fail表示在TCP階段就連線(xiàn)失敗，如果fail太多次，出來(lái)的數(shù)據(jù)絕對(duì)不正確Failed requests:        0Write errors:           0Total transferred:      9478392 bytesHTML transferred:       9197475 bytes#每秒鐘的Request次數(shù)，可以視為效能的指標(biāo)。因?yàn)檫@次測(cè)試我們使用了-c 20#表示在20個(gè)人同時(shí)連線(xiàn)的情況下，還可以保持每秒34個(gè)request。Requests per second:    34.24 [#/sec] (mean)#表示這20個(gè)人裡「平均」每個(gè)人感受到的回應(yīng)時(shí)間(不包括瀏覽器顯示出來(lái)的時(shí)間)#約是584ms，也就是0.58秒。Time per request:       584.185 [ms] (mean)Time per request:       29.209 [ms] (mean, across all concurrent requests)Transfer rate:          308.25 [Kbytes/sec] receivedConnection Times (ms)min  mean[+/-sd] median   maxConnect:        0   49 382.7      0    3000Processing:    91  519 1287.7    262   20913Waiting:       90  518 1287.7    260   20912Total:         91  569 1542.9    262   21543#這個(gè)曲線(xiàn)圖比較重要，算是ab的數(shù)據(jù)價(jià)值所在。這裡表示了這20個(gè)人所感受到的#回應(yīng)速度曲線(xiàn)，可以從0.2秒到21秒不等。也就是說(shuō)，在這裡約有20*90%=18人，#他們感受到的速度會(huì)低於1秒，而其他人會(huì)高於1秒。這個(gè)比平均數(shù)值還要更能表達(dá)#使用者大多都是感受到什麼速度，因?yàn)樵谒欧骱苊β档那闆r下，會(huì)有像21秒這種#數(shù)值，這是會(huì)大大地拖累平均速度及每秒request數(shù)。Percentage of the requests served within a certain time (ms)50%    26266%    32775%    39780%    44990%    73095%   133898%   522499%   8504100%  21543 (longest request)

曲線(xiàn)圖繪製出來(lái)是這樣：

結(jié)論

其實(shí)這篇文章寫(xiě)的滿(mǎn)混亂的，好幾件事情堆在一起講，而無(wú)法把每件事情講的比較詳細(xì)。不管如何要建議商業(yè)用的服務(wù)是個(gè)大工程，並不是三言?xún)烧Z(yǔ)可以講的清楚。而我本身的經(jīng)驗(yàn)，使用apache真的不管在啥角度來(lái)看都是最棒的web server，但是從來(lái)也沒(méi)有人說(shuō)他是最棒的director。因此好的管理者心裡總是會(huì)構(gòu)思許多不同的解決方案，而更要瞭解許多方案背後架構(gòu)，原理，穩(wěn)定度，效能等問(wèn)題，而不管哪個(gè)是否難做。但讓我覺(jué)得可惜的是，網(wǎng)路上大部分文章會(huì)誤導(dǎo)比較沒(méi)有經(jīng)驗(yàn)的管理者，設(shè)定簡(jiǎn)單或是好裝不見(jiàn)得就是好東西。

儘管我無(wú)法一一解釋我曾經(jīng)測(cè)試過(guò)了什麼，而直到現(xiàn)在我的綜合感受還是認(rèn)為haproxy+apache+fastcgi來(lái)跑rails是最穩(wěn)定且效能良好的選擇，但也是設(shè)定上稍微繁雜的。