欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

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

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

Cluster(叢集)

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

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

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

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

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

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

IP配置的方式

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

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

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

實(shí)做

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

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

假設有這些機器，如下：
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的機器，目的也是為了剛剛所說(shuō)進(jìn)行連線(xiàn)重新導向。

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

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

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

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

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

安裝Bind 9與RRDNS

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

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

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

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

請注意測試機器的DNS Server當然就要設定成D1了，一旦使用nslookup成功地查到兩個(gè)會(huì )變動(dòng)的IP，那接著(zhù)測試的時(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)行負載平衡，而ldirectord只是有比較好看的設定檔。

D1機器：

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

R1及R2機器：

加入

接著(zhù)

內容為

最後
service network restart

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

安裝apache+mod_proxy

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

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

安裝 haproxy

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

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ù)監控程式，不過(guò)就請各位自行killall吧。
編輯/etc/haproxy.haproxy.conf
global及default區段都不用動(dòng)，而注意到listen區段，語(yǔ)法是listen {appname} {ip:port}
修改成

之後service haproxy start即可

AB(Apache Benchmark)數據解讀

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

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

[root@dsa1 ~]# ab -c 20 -t 30 http://some.machine.com/test/#這裡是版權宣告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次數顯示出來(lái)，如果每超過(guò)5000會(huì )再次顯示Finished 1028 requests#主機資訊Server Software:        Apache/2.2.3Server Hostname:        xxxServer Port:            80Document Path:          /test/#要注意，如果傳輸的資料大小超過(guò)1MB，表示使用ADSL的人多少會(huì )因為資料量感受到緩慢#，就可能不會(huì )是準確的測試結果Document Length:        8943 bytes#這裡表示你下了 -c 20Concurrency Level:      20#總測試時(shí)間，應該不會(huì )跟-t的時(shí)間差太遠Time taken for tests:   30.27095 secondsComplete requests:      1028#這裡的Fail表示在TCP階段就連線(xiàn)失敗，如果fail太多次，出來(lái)的數據絕對不正確Failed requests:        0Write errors:           0Total transferred:      9478392 bytesHTML transferred:       9197475 bytes#每秒鐘的Request次數，可以視為效能的指標。因為這次測試我們使用了-c 20#表示在20個(gè)人同時(shí)連線(xiàn)的情況下，還可以保持每秒34個(gè)request。Requests per second:    34.24 [#/sec] (mean)#表示這20個(gè)人裡「平均」每個(gè)人感受到的回應時(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的數據價(jià)值所在。這裡表示了這20個(gè)人所感受到的#回應速度曲線(xiàn)，可以從0.2秒到21秒不等。也就是說(shuō)，在這裡約有20*90%=18人，#他們感受到的速度會(huì )低於1秒，而其他人會(huì )高於1秒。這個(gè)比平均數值還要更能表達#使用者大多都是感受到什麼速度，因為在伺服器很忙碌的情況下，會(huì )有像21秒這種#數值，這是會(huì )大大地拖累平均速度及每秒request數。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)是這樣：

結論

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

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