Web Farm
發表於 : 2005-05-23 09:47:37
http://www.pczone.com.tw/vbb3/showthrea ... ge=3&pp=20
以弟所認知的觀念，首先回答原發問者第一篇的問題
一般所謂的 "Web Farm"
大部份是指將 traffic share 到多台的伺服器中
原因與目的不外乎兩大類：
1. Load Balance
因為一台機器負荷不了過多使用者的需求，所以分散到多台伺服器中
如此便可以服務更多的使用者
2. High Availability
任何機器都有當機的可能性，而如果把request分散到多台伺服器中
那任何一台機器當機，只會影響到與該機器建立連線的部份使用者而已
只要重新連線一次即可
上端的設備會偵測若該機器無法提供服務，則不會把封包送往該當機的server
而 Solution 方面
誠如前面的 linux_xp 兄所言，Free 的 Solution 很多
但弟想提另一個管理上的觀點
為什麼有這麼多的 Free Solution 可以省錢
但是鮮有大企業會採用？
個人認為
當企業成長到一定的規模後
對老闆、管理者而言，重要的不是買什麼設備、設備的價格如何
而是設備是否穩定？出問題的時候，是否可以得到最好的support馬上解決？
在大場合的線上服務裡，尤其是牽涉到 $$ 的線上交易、電子商務
常常停機幾分鐘，就會損失許多收入
而且對於提供主機代管的企業而言
(各ISP如HiNet、SeedNet、Sparq，電訊業者如和宇寬頻、是方電訊... etc 的IDC )
停機影響到的不是這些公司 而是這些公司的客戶
如果無預警的斷線多來幾次 會使客戶信心大幅降低而流失
在業界間的評價也會負向，沒有人願意再 Co-location 在該公司的機房
因此有強力廠商support、業界評價良好、有多處成功案例保證的solution
才會是老闆所考量的
在此給 Black-H 兄的建議是 - 視公司的需求
=============================================================================
如果現在跑一台 server , 想擴充到 2~3 台
且場合和用途沒有那麼 critical 的話
那找一些 free solution 是最經濟的方案了
(但請考慮到後續的maintain問題, 不是每個人都有能力maintain這樣的load balancer)
如果你是用 apache 的話
試試這個 Module
http://www.backhand.org/mod_backhand/
它可以讓你簡單的將 loading share 到多台機器裡
如果從 L3 的角度作 Server Load Balance 的話
其他OS的話 可以試試 IP-Filter
http://coombs.anu.edu.au/~avalon/
它是一套 free 的 kernel-space packet filter , 可以作 firewall/NAT/redirect packet..
另舉個 Linux 上 Free 的 Solution :
http://www.linuxvirtualserver.org/
在多數的 Linux Distribution 中已建有這個功能
載入 ipvs module , 然後用 ipvsadm 來設定即可 (要先裝有 ipvsadm 套件)
詳細設定方法可以 man ipvsadm
另外 , 在 RedHat Enterprise Linux 中, 也提供了這一系列的solution
叫 Red Hat Cluster Suite
http://www.redhat.com/docs/manuals/csgfs/
load balance 的方式很多
(weighted) round robin/(weighted) least-connection/locality-based least-connection/destination-hashing/source-hashing ...
顧名思義一下應該不難懂~
要注意的是 , 這些前端的 traffic dispatcher 並不負責後端資料 synchronize 的問題
不管是 web source、session、database , 都是你要用其他方式解決的
web source 的部份比較簡單
用 ftp/sftp/rsync/ , 有新版本的source時 放到毎台 web server 裡面就好了
或甚至幾台 server 直接 mount 同一個 nfs server 都可以解決(performance會差一點)
session 的部份
註:此處的session是指需要與使用者互動(例如login)而產生的session
弟對php比較熟悉 , 僅以其作為例子
php 的 session 預設是存在當台機器的 /tmp 下 (這path當然可以改)
所以如果同一個user , 第一個 connection 建往 web1
下一個 connection 卻往 web2 丟的話
web2 上沒有這個 session ... user 很可能會被 logout
有這樣的需求的話 , 就需要做 persistence
ipvs的 persistence 可以讓同樣的 source ip , 進到同一台 server 中
如此就不會有上述的問題 ...
(但是 load balance 的效果就會差一點, 比較不平均)
如果不做 persistence 的話 , 讓所有的 servers 掛同一個 storage 也是可以
便宜點就用 NFS , 要買設備就掛 SAN/NAS ...etc
最後一段 database 的部份 ...
這個部份, 並不如 linux_xp 兄所想的那麼困難
辦的到也不能領貝爾獎...
實際上, 現在就已經有 Free Solution 了
弟只見識過 MySQL 的部份, 僅就此部份提供一點經驗
MySQL 從 4.0 起 support 所謂的 replication
可以把 Master Database 上的資料 , 幾乎是"即時"同步到 Slave Database 上
雖然不能在 Slave 上作寫入的動作(insert/update/delete...etc)
但是可以從 web source 端控制好
讓寫入的動作往 master database 作, 讀取的動作從 slave database 作
如此可以初步的分散loading ...
要求高一點的 , 也可以作雙Master的架構
也就是兩台機器互作 replication
兩台都可以當 master , client 端可以 read/write 到任一台
也可以上端架個 load balancer , 由它去分配就好了
而在 MySQL 4.1 開始 , 支援所謂的 Cluster
這裡的 Cluster 和前面幾篇文章所提的 "叢集式運算系統" 不一樣
指的是 MySQL Database Server 本身, 也以用很多台同時運作
如此不管是分散loading、互作備援、... 都很容易
詳情請見 MySQL 的文件
http://dev.mysql.com/doc/mysql/en/NDBCluster.html
如果 Database 部份的 loading 並不重
只是重在 web server 部份的話
就很容易處理
一台 Load Balancer , 和幾台 web server 串
幾台 web server 再和 database 接起來就好了
如果考量到 Load Balancer 一掛, 有再多台 web server 都沒用的話
可以試試 Linux 上的 HA 機制
http://www.linux-ha.org/
前面忘了提, 這裡補充一下
其實最單純、最簡單的 solution 是從 DNS 著手
如果你可用的 public ip 夠的話
讓一個 domain name 的 A 紀錄 bind 兩個不同的 ip
就可以把 user share 到這兩台 server 上了
只是如前面的兄台所述 , 機器掛掉了還是照丟
會有 1/x 的機率連不上 :p
考慮到救回機器需要時間 , 最好是把放出去的 TTL 縮短
這樣救機器的時候 可以暫時把該筆 A 紀錄拿掉
避免外面的 DNS server 因 cache , 而一直回答那個掛掉的 ip ...
=============================================================================
如果老闆要求一些比較中型的 solution
要有廠商support、且經training後maintain的人員易尋的
可以考慮國內許多業者的設備
例如眾至、友旺、德恩、亞盛 ... etc
弟沒有這方面的經驗 可能留待其他前輩來分享了!
=============================================================================
而真正大型的場合 目前幾乎都是舶來品的天下
如 Nortel/F5/Cisco/Foundry/Radware/Fortegate ... etc
不是說國產品不好
而是這些國外大廠的設備在全世界有許多成功的案例
且確有其過人之處
穩定性自不在話下, performance 方面也比國產的設備高出許多
concurrent session 都可以 handle 幾百萬 ...
像這類型高檔的網路設備, 功能一大堆
做 router/L2~L7 switch/load balancer/dns/wan controller/NAT/ ... 都可以
的確是很難給一個明確的稱呼法 至少各廠商命的名都不一樣
不過弟比較習慣的介紹稱法是 Application Switch 或 Layer 7 Switch
弟只對 Nortel Alteon Series 和 F5 BigIP Series 比較熟悉
提僅一些經驗供參考
基本上 這兩系列的設備底層是完全不同的
Nortel Alteon Series 是偏 switch base 的設備
把一顆switch , 裡面放了很多顆 processor
每一顆專職不同的任務,
例如處理User的interface、處理 L2的部份、處理L3/L4/Server Load Balance的部份...etc
F5 BigIP Series 的底層是用FreeBSD兜起來的
其上的使用者介面也是跑 apache 而已
但是人家底層 kernel 改的好, 跑起來 performance 好, 就可以賣很多 $$ .......
兩個設備作比較的話 (個人觀點)
論效能以 Alteon 較好
論操作介面以 F5 較為 friendly
Alteon長處在 L3/L4 的 Server Load Balance
而 F5 則是處理 L7 的部份功能較為強大, 可以依據封包的任何一個部份作處理
例如先前提到的 persistence
這類的網路設備都可以有更多的 solution
例如依據 SSL id/Source ip/Destination/Cookie , 或封包的任一個指定的部份作 persistence
再來是HA的部份
有兩台的時候
不管是作 Active-StandBy / Active-Active(互作StandBy) 都很容易
一台死掉, 另一台馬上會 take over
Alteon 用 VRRP 互相 check
F5 則是中間串一條類似 RS-232 的線 , 用自己的 protocol 在 check ...
這部份個人認為 F5 的能力較好
兩台間會互相 backup 對方的 session ,
因此在 on-line 的情況下 , 任何切換、拔線 的動作
user幾乎都沒感覺的 ...
使用這類設備只有一個缺點 ： 貴 ！！ (買過的人就知道 :~ )
=============================================================================
找幾間 SI , 或者有經驗的人
開出你們的預算
請他幫你們評估一下
相信很快就可以找出你們適合的方式！
如果只是單純的 performance 不好 , 也許 tuning 一下就解決了
就不用這麼勞神費力 :p
=============================================================================
以上是弟在這部份的一些觀點, 還請大家不吝指教
以下的 , 是對前面幾位兄台提出的觀點有些疑惑 , 希望彼此討論一下
linux_xp 兄所提的 Cluster (叢集式運算系統)
真的可以適用在 web farm 的場合嗎?
如果 os 跑 linux/bsd , server 跑 apache
apache 的設計中根本沒有處理這種 parallel computing 的地方
那即使幾台機器作成 cluster 了 , apache 自己會去分配任務嗎 ?
如果 http server 沒有這個能力
那要導入 cluster 這樣的 solution , 是不是 http server 要重新 design 過 ?
再來是 bonding 的部份
弟的觀念裡 , 這個技術是讓機器上的多張網卡 bind 同樣的 mac address
從這個角度去想
應該只有在一般的小型 L2 switch 上可以運作 ?
小switch上有幾 KB 的 mac address table
可以記憶每個 port 上進出封包的 mac address
遇到要傳送的 packet , destination mac address 在 table 裡的話
可以直接送往該 port , 而不用重新 broadcast 一次
從這樣的理論看來, 幾張網卡間也不需要所謂的協調
不管封包從哪張進來 都是進到 kernel
但這個機制 ...
在 Hub 上不會動 ... 因為每次 broadcast
插了幾張網卡 就會收幾份同樣的封包進來 好像沒什麼幫助 ...
在中階的 Switch 上也不會動
不同的 port 中出現同樣的 mac address
那 Spanning Tree 不就起來了 @@"
結果就是只有一個 port 會動 ... 其他的port會block ...
所以為什麼這樣的 solution 很好 , 卻少見在大地方使用
大地方通常就直接用 Gb/10Gb 的 NIC 了 ...
不知道弟這樣的觀點有沒有錯誤呢？
再來是弟想分享一個自己的理念
如果靠一套 phpMyAdmin 可以管好 database 的話
那大部份的 DBA 大概都要失業了 ...
它的 web 介面是很方便沒有錯
但是還是有很多地方是它做不到的...
而且愈方便的工具 危險性也愈大
再者是, 愈習慣用這些工具的人 , 就會愈疏於一般指令的使用
甚至連 SQL 都不會下了 ...
弟就遇過管Database的人, 到一個沒有 phpMyAdmin 的地方
連 Grant permission 都不會下...帳號開半天開不出來 ....
所以弟認為會用工具沒什麼稀奇 大家都會
不靠工具而能管好系統的人 才是真正熟悉系統的人
不知各位兄台以為然否 ?
野人獻曝一下 , 期收拋磚引玉之效
還望各位前輩不吝指正錯誤
以弟所認知的觀念，首先回答原發問者第一篇的問題
一般所謂的 "Web Farm"
大部份是指將 traffic share 到多台的伺服器中
原因與目的不外乎兩大類：
1. Load Balance
因為一台機器負荷不了過多使用者的需求，所以分散到多台伺服器中
如此便可以服務更多的使用者
2. High Availability
任何機器都有當機的可能性，而如果把request分散到多台伺服器中
那任何一台機器當機，只會影響到與該機器建立連線的部份使用者而已
只要重新連線一次即可
上端的設備會偵測若該機器無法提供服務，則不會把封包送往該當機的server
而 Solution 方面
誠如前面的 linux_xp 兄所言，Free 的 Solution 很多
但弟想提另一個管理上的觀點
為什麼有這麼多的 Free Solution 可以省錢
但是鮮有大企業會採用？
個人認為
當企業成長到一定的規模後
對老闆、管理者而言，重要的不是買什麼設備、設備的價格如何
而是設備是否穩定？出問題的時候，是否可以得到最好的support馬上解決？
在大場合的線上服務裡，尤其是牽涉到 $$ 的線上交易、電子商務
常常停機幾分鐘，就會損失許多收入
而且對於提供主機代管的企業而言
(各ISP如HiNet、SeedNet、Sparq，電訊業者如和宇寬頻、是方電訊... etc 的IDC )
停機影響到的不是這些公司 而是這些公司的客戶
如果無預警的斷線多來幾次 會使客戶信心大幅降低而流失
在業界間的評價也會負向，沒有人願意再 Co-location 在該公司的機房
因此有強力廠商support、業界評價良好、有多處成功案例保證的solution
才會是老闆所考量的
在此給 Black-H 兄的建議是 - 視公司的需求
=============================================================================
如果現在跑一台 server , 想擴充到 2~3 台
且場合和用途沒有那麼 critical 的話
那找一些 free solution 是最經濟的方案了
(但請考慮到後續的maintain問題, 不是每個人都有能力maintain這樣的load balancer)
如果你是用 apache 的話
試試這個 Module
http://www.backhand.org/mod_backhand/
它可以讓你簡單的將 loading share 到多台機器裡
如果從 L3 的角度作 Server Load Balance 的話
其他OS的話 可以試試 IP-Filter
http://coombs.anu.edu.au/~avalon/
它是一套 free 的 kernel-space packet filter , 可以作 firewall/NAT/redirect packet..
另舉個 Linux 上 Free 的 Solution :
http://www.linuxvirtualserver.org/
在多數的 Linux Distribution 中已建有這個功能
載入 ipvs module , 然後用 ipvsadm 來設定即可 (要先裝有 ipvsadm 套件)
詳細設定方法可以 man ipvsadm
另外 , 在 RedHat Enterprise Linux 中, 也提供了這一系列的solution
叫 Red Hat Cluster Suite
http://www.redhat.com/docs/manuals/csgfs/
load balance 的方式很多
(weighted) round robin/(weighted) least-connection/locality-based least-connection/destination-hashing/source-hashing ...
顧名思義一下應該不難懂~
要注意的是 , 這些前端的 traffic dispatcher 並不負責後端資料 synchronize 的問題
不管是 web source、session、database , 都是你要用其他方式解決的
web source 的部份比較簡單
用 ftp/sftp/rsync/ , 有新版本的source時 放到毎台 web server 裡面就好了
或甚至幾台 server 直接 mount 同一個 nfs server 都可以解決(performance會差一點)
session 的部份
註:此處的session是指需要與使用者互動(例如login)而產生的session
弟對php比較熟悉 , 僅以其作為例子
php 的 session 預設是存在當台機器的 /tmp 下 (這path當然可以改)
所以如果同一個user , 第一個 connection 建往 web1
下一個 connection 卻往 web2 丟的話
web2 上沒有這個 session ... user 很可能會被 logout
有這樣的需求的話 , 就需要做 persistence
ipvs的 persistence 可以讓同樣的 source ip , 進到同一台 server 中
如此就不會有上述的問題 ...
(但是 load balance 的效果就會差一點, 比較不平均)
如果不做 persistence 的話 , 讓所有的 servers 掛同一個 storage 也是可以
便宜點就用 NFS , 要買設備就掛 SAN/NAS ...etc
最後一段 database 的部份 ...
這個部份, 並不如 linux_xp 兄所想的那麼困難
辦的到也不能領貝爾獎...
實際上, 現在就已經有 Free Solution 了
弟只見識過 MySQL 的部份, 僅就此部份提供一點經驗
MySQL 從 4.0 起 support 所謂的 replication
可以把 Master Database 上的資料 , 幾乎是"即時"同步到 Slave Database 上
雖然不能在 Slave 上作寫入的動作(insert/update/delete...etc)
但是可以從 web source 端控制好
讓寫入的動作往 master database 作, 讀取的動作從 slave database 作
如此可以初步的分散loading ...
要求高一點的 , 也可以作雙Master的架構
也就是兩台機器互作 replication
兩台都可以當 master , client 端可以 read/write 到任一台
也可以上端架個 load balancer , 由它去分配就好了
而在 MySQL 4.1 開始 , 支援所謂的 Cluster
這裡的 Cluster 和前面幾篇文章所提的 "叢集式運算系統" 不一樣
指的是 MySQL Database Server 本身, 也以用很多台同時運作
如此不管是分散loading、互作備援、... 都很容易
詳情請見 MySQL 的文件
http://dev.mysql.com/doc/mysql/en/NDBCluster.html
如果 Database 部份的 loading 並不重
只是重在 web server 部份的話
就很容易處理
一台 Load Balancer , 和幾台 web server 串
幾台 web server 再和 database 接起來就好了
如果考量到 Load Balancer 一掛, 有再多台 web server 都沒用的話
可以試試 Linux 上的 HA 機制
http://www.linux-ha.org/
前面忘了提, 這裡補充一下
其實最單純、最簡單的 solution 是從 DNS 著手
如果你可用的 public ip 夠的話
讓一個 domain name 的 A 紀錄 bind 兩個不同的 ip
就可以把 user share 到這兩台 server 上了
只是如前面的兄台所述 , 機器掛掉了還是照丟
會有 1/x 的機率連不上 :p
考慮到救回機器需要時間 , 最好是把放出去的 TTL 縮短
這樣救機器的時候 可以暫時把該筆 A 紀錄拿掉
避免外面的 DNS server 因 cache , 而一直回答那個掛掉的 ip ...
=============================================================================
如果老闆要求一些比較中型的 solution
要有廠商support、且經training後maintain的人員易尋的
可以考慮國內許多業者的設備
例如眾至、友旺、德恩、亞盛 ... etc
弟沒有這方面的經驗 可能留待其他前輩來分享了!
=============================================================================
而真正大型的場合 目前幾乎都是舶來品的天下
如 Nortel/F5/Cisco/Foundry/Radware/Fortegate ... etc
不是說國產品不好
而是這些國外大廠的設備在全世界有許多成功的案例
且確有其過人之處
穩定性自不在話下, performance 方面也比國產的設備高出許多
concurrent session 都可以 handle 幾百萬 ...
像這類型高檔的網路設備, 功能一大堆
做 router/L2~L7 switch/load balancer/dns/wan controller/NAT/ ... 都可以
的確是很難給一個明確的稱呼法 至少各廠商命的名都不一樣
不過弟比較習慣的介紹稱法是 Application Switch 或 Layer 7 Switch
弟只對 Nortel Alteon Series 和 F5 BigIP Series 比較熟悉
提僅一些經驗供參考
基本上 這兩系列的設備底層是完全不同的
Nortel Alteon Series 是偏 switch base 的設備
把一顆switch , 裡面放了很多顆 processor
每一顆專職不同的任務,
例如處理User的interface、處理 L2的部份、處理L3/L4/Server Load Balance的部份...etc
F5 BigIP Series 的底層是用FreeBSD兜起來的
其上的使用者介面也是跑 apache 而已
但是人家底層 kernel 改的好, 跑起來 performance 好, 就可以賣很多 $$ .......
兩個設備作比較的話 (個人觀點)
論效能以 Alteon 較好
論操作介面以 F5 較為 friendly
Alteon長處在 L3/L4 的 Server Load Balance
而 F5 則是處理 L7 的部份功能較為強大, 可以依據封包的任何一個部份作處理
例如先前提到的 persistence
這類的網路設備都可以有更多的 solution
例如依據 SSL id/Source ip/Destination/Cookie , 或封包的任一個指定的部份作 persistence
再來是HA的部份
有兩台的時候
不管是作 Active-StandBy / Active-Active(互作StandBy) 都很容易
一台死掉, 另一台馬上會 take over
Alteon 用 VRRP 互相 check
F5 則是中間串一條類似 RS-232 的線 , 用自己的 protocol 在 check ...
這部份個人認為 F5 的能力較好
兩台間會互相 backup 對方的 session ,
因此在 on-line 的情況下 , 任何切換、拔線 的動作
user幾乎都沒感覺的 ...
使用這類設備只有一個缺點 ： 貴 ！！ (買過的人就知道 :~ )
=============================================================================
找幾間 SI , 或者有經驗的人
開出你們的預算
請他幫你們評估一下
相信很快就可以找出你們適合的方式！
如果只是單純的 performance 不好 , 也許 tuning 一下就解決了
就不用這麼勞神費力 :p
=============================================================================
以上是弟在這部份的一些觀點, 還請大家不吝指教
以下的 , 是對前面幾位兄台提出的觀點有些疑惑 , 希望彼此討論一下
linux_xp 兄所提的 Cluster (叢集式運算系統)
真的可以適用在 web farm 的場合嗎?
如果 os 跑 linux/bsd , server 跑 apache
apache 的設計中根本沒有處理這種 parallel computing 的地方
那即使幾台機器作成 cluster 了 , apache 自己會去分配任務嗎 ?
如果 http server 沒有這個能力
那要導入 cluster 這樣的 solution , 是不是 http server 要重新 design 過 ?
再來是 bonding 的部份
弟的觀念裡 , 這個技術是讓機器上的多張網卡 bind 同樣的 mac address
從這個角度去想
應該只有在一般的小型 L2 switch 上可以運作 ?
小switch上有幾 KB 的 mac address table
可以記憶每個 port 上進出封包的 mac address
遇到要傳送的 packet , destination mac address 在 table 裡的話
可以直接送往該 port , 而不用重新 broadcast 一次
從這樣的理論看來, 幾張網卡間也不需要所謂的協調
不管封包從哪張進來 都是進到 kernel
但這個機制 ...
在 Hub 上不會動 ... 因為每次 broadcast
插了幾張網卡 就會收幾份同樣的封包進來 好像沒什麼幫助 ...
在中階的 Switch 上也不會動
不同的 port 中出現同樣的 mac address
那 Spanning Tree 不就起來了 @@"
結果就是只有一個 port 會動 ... 其他的port會block ...
所以為什麼這樣的 solution 很好 , 卻少見在大地方使用
大地方通常就直接用 Gb/10Gb 的 NIC 了 ...
不知道弟這樣的觀點有沒有錯誤呢？
再來是弟想分享一個自己的理念
如果靠一套 phpMyAdmin 可以管好 database 的話
那大部份的 DBA 大概都要失業了 ...
它的 web 介面是很方便沒有錯
但是還是有很多地方是它做不到的...
而且愈方便的工具 危險性也愈大
再者是, 愈習慣用這些工具的人 , 就會愈疏於一般指令的使用
甚至連 SQL 都不會下了 ...
弟就遇過管Database的人, 到一個沒有 phpMyAdmin 的地方
連 Grant permission 都不會下...帳號開半天開不出來 ....
所以弟認為會用工具沒什麼稀奇 大家都會
不靠工具而能管好系統的人 才是真正熟悉系統的人
不知各位兄台以為然否 ?
野人獻曝一下 , 期收拋磚引玉之效
還望各位前輩不吝指正錯誤