實做
XoWDER <a href="http://htxqorlfylyd.com/">htxqorlfylyd</a>, [url=http://nncgwdypqkde.com/]nncgwdypqkde[/url], [link=http://rmcilgzwcjup.com/]rmcilgzwcjup[/link], http://pwphtynrvypg.com/
安裝Bind 9與RRDNS
Bind的安裝已經有很好的文章,請參考
http://turtle.ee.ncku.edu.tw/~tung/dns/bind_conf.html
在Fedora 6上只要yum install bind就可以安裝。
要進行的設定很簡單,首先先修改named.conf,在options區塊裡面加入一行
rrset-order {order cyclic;}; |
接著修改你的正查設定檔(如果你的domain是test.com就應該是test.com.hosts)。根據本例子,我改成:
www IN A 10.1.1.61 IN A 10.1.1.62 |
請注意測試機器的DNS Server當然就要設定成V1了,一旦使用nslookup成功地查到兩個會變動的IP,那接著測試的時候URL就可以使用http://www.test.com。
安裝ipvsadm及ldirectord
參考文章:
http://zh.linuxvirtualserver.org/files/lvs.pdf
http://zh.linuxvirtualserver.org/node/272
基本上安裝了ipvsadm後就可以下指令手動進行負載平衡,而ldirectord只是有比較好看的設定檔。
V1機器:
yum install ipvsadm #清除 ipvsadm -C #建立Virtual Server IP 及使用演算法 ipvsadm -A -t 10.1.1.60:80 -s rr #串接兩個Real Server IP ipvsadm -a -t 10.1.1.60:80 -r 10.1.1.61:80 -g ipvsadm -a -t 10.1.1.60:80 -r 10.1.1.62:80 -g |
接著在R1及R2上,你要設定好一個lo(loopback)的alias並且將IP設定為10.1.1.60,你可以建立/etc/sysconfig/network-scripts/ifcfg-lo:0或是使用xwindow的網路設定來編輯。
R1及R2機器:
加入
net.ipv4.ip_forward = 1 net.ipv4.conf.lo.arp_ignore = 1 net.ipv4.conf.lo.arp_announce = 2 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 |
接著
sysctl -p vi /etc/sysconfig/network-scripts/ifcfg-lo:0 |
內容為
DEVICE=lo:0 IPADDR=10.1.1.60 NETMASK=255.255.255.255 ONBOOT=yes |
最後
由於request封包是透過ipvsadm轉送過來,real server必須做一件事情就是不要更動封包裡的mac address,而將這個mac address當作response的mac address而送回去,如此client收到的資料才會正常。
安裝apache+mod_proxy
mod_proxy在2.0版後就是預設模組,而FC6上也算是內建的套件。如果你還沒安裝的話,就yum install httpd。
編輯/etc/httpd/conf/httpd.conf
加入
BalancerMember http://10.1.1.61:3000
<proxy>BalancerMember http://10.1.1.62:3000</proxy> |
重新啟動之後就可以試試看了,不過要注意這樣的設定就是全部交由後端處理,事實上還可以加一些設定讓apache處理靜態資料的時候直接回傳節省時間。
安裝 haproxy
到了這個小節,你會發現工作越來越簡單,就請各位參考
http://lightyror.wordpress.com/2007/06/04/%e5%9c%a8-centos-%e5%ae%89%e8%a3%9d-ruby-on-rails
雖然透過rubyworks他會啟動一些不見得是使用者需要的服務監控程式,不過就請各位自行killall吧。
編輯/etc/haproxy.haproxy.conf
global及default區段都不用動,而注意到listen區段,語法是listen {appname} {ip:port}
修改成
listen appli1-rewrite 0.0.0.0:80 stats enable cookie SERVERID rewrite balance roundrobin server app1_1 10.1.1.61:3000 cookie app1inst1 check inter 2000 rise 2 fall 5 server app1_2 10.1.1.62:3000 cookie app1inst2 check inter 2000 rise 2 fall 5 |
之後service haproxy start即可
AB(Apache Benchmark)數據解讀
為什麼我們需要測試?
在進行正式服務之前,你一定要先跑跑看你做出來的東西效率怎樣。仔細規劃了半天,設定了半天,結果效能很差,那一定是哪裡做錯了。
AB(Apache Benchmark)顧名思義是一套apache http
server所附的,用來測試http效能的程式,通常裝好server程式就也會有這個程式了。
ab指令的語法是 ab -c {同時進行的request數量} -t {時間} {url} 或是 ab -c {同時進行的request數量} -n {次數} {url}
ab的測試方式有兩種:
- -t {秒數}
- -n {request次數}
兩種方式都可以取得可以觀察的數據,不過如果-n太少的話,就沒有意義。我通常都是使用-t 30或是-t
60。而這樣的測試有另一個好處是,在測試的其中,可以找真的人在一定時間內去實際點點看你的程式,如果時間都過去了(先別跟他講已經跑完了),他還是覺
得速度沒有差,那表示效能有到使用者能夠接受的感受。而需要效能數據,其實也是為了使用經驗法則推算出應用程式最多可以容納幾個使用者註冊。
AB跑出來的結果,在以下舉個一個例子來解讀:
[root@test ~]# ab -c 20 -t 30 http://some.machine.com/test/ #這裡是版權宣告 This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking xxx (be patient) #這裡會將完成的HTTP要求次數顯示出來,如果每超過5000會再次顯示 Finished 1028 requests
#主機資訊 Server Software: Apache/2.2.3 Server Hostname: xxx Server Port: 80
Document Path: /test/ #要注意,如果傳輸的資料大小超過1MB,表示使用ADSL的人多少會因為資料量感受到緩慢 #,就可能不會是準確的測試結果 Document Length: 8943 bytes
#這裡表示你下了 -c 20 Concurrency Level: 20 #總測試時間,應該不會跟-t的時間差太遠 Time taken for tests: 30.27095 seconds Complete requests: 1028 #這裡的Fail表示在TCP階段就連線失敗,如果fail太多次,出來的數據絕對不正確 Failed requests: 0 Write errors: 0 Total transferred: 9478392 bytes HTML transferred: 9197475 bytes #每秒鐘的Request次數,可以視為效能的指標。因為這次測試我們使用了-c 20 #表示在20個人同時連線的情況下,還可以保持每秒34個request。 Requests per second: 34.24 [#/sec] (mean) #表示這20個人裡「平均」每個人感受到的回應時間(不包括瀏覽器顯示出來的時間) #約是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] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 49 382.7 0 3000 Processing: 91 519 1287.7 262 20913 Waiting: 90 518 1287.7 260 20912 Total: 91 569 1542.9 262 21543
#這個曲線圖比較重要,算是ab的數據價值所在。這裡表示了這20個人所感受到的 #回應速度曲線,可以從0.2秒到21秒不等。也就是說,在這裡約有20*90%=18人, #他們感受到的速度會低於1秒,而其他人會高於1秒。這個比平均數值還要更能表達 #使用者大多都是感受到什麼速度,因為在伺服器很忙碌的情況下,會有像21秒這種 #數值,這是會大大地拖累平均速度及每秒request數。 Percentage of the requests served within a certain time (ms) 50% 262 66% 327 75% 397 80% 449 90% 730 95% 1338 98% 5224 99% 8504 100% 21543 (longest request) |
曲線圖繪製出來是這樣:
如同上述,我們可以從曲線圖瞭解平均使用者感受到的回應速度,從這個例子可以看出,約8成的使用者感受到的都是低於5秒,表示有很好的效能。
結論
要建議商業用的服務是個大工程,並不是三言兩語可以講的清楚而,絕大多數要靠著硬體環境與經驗的配合。而我本身的經驗,使用apache真的不管在
啥角度來看都是最棒的web server,但是就不一定能夠適合當Virtual
Server。因此好的管理者心裡總是會構思許多不同的解決方案,而更要瞭解許多方案背後架構,原理,穩定度,效能等問題,而不應該只考慮哪個是否難做。
但讓我覺得可惜的是,網路上大部分文章會誤導比較沒有經驗的管理者,而去強調三步安裝。我相信一個很穩定,能夠承受高負載的商業Web服務叢集,絕對不是
靠著簡單好裝就能夠完成重要的工作的。
直到現在我的綜合感受還是認為haproxy+apache+fastcgi來跑rails是最穩定且效能良好的選擇,但也是設定上稍微繁雜的。