流量控管
- 應該請行銷人員事先通知系統管理人員何時會發行銷簡訊,以便提早設定 web server 的流量限制 (concurrent sessions),以免瞬間倒台。雖然超出流量限制的 user 無法連線成功,但只要 retry 就可能連的上。這樣的作法可確保 web server 不會倒台,在能力範圍內提供最多的服務。
- DB server 倒台時可能要花很長時間才能回復,在這些 downtime 時損失的流量是難以挽回的。
- 平常應該透過壓力測試,或者流量分析的歷史紀錄來評估每台 Web server 最多可接受多少個concurrent sessions,以便進行上述的流量限制。
- Web server concurrent sessions 的設定應慢慢逐步放寬,以免瞬間超過 server 的負荷量而倒台。
- 要注意 Apache httpd.conf 裡面的「MaxClients」設定值,若設定值過高可能造成 server 無法負荷(甚至造成接 console 也無反應,沒有螢幕,必須重開機)。(預設值為256)
- 上線前要作 end to end 的測試(包含所有備用機),備用機的狀態應該調整到只要 VIP 一 enable,就會有流量進來的程度,只是在 VIP 設定中暫時 disable,保持隨時可以上線的狀態。本次準備的一台備用機因 OS 環境與正式環境差太多 (如 Apache 版本、Apache modules 版本等),最後無法即時在當天 config 完成並上線提供服務。
- 設備的 RAM 應提早估計是否夠用,臨時要調 server 使用的 RAM 相當困難(e.g., 創見門市不賣 server 使用的 RAM,價錢也蠻貴的),頂多只能把閒置的 server 停機來支援 (等到活動結束又要安排時間把 server 組態回復原狀,又要再花時間測試、驗證)。
- IBM X3650/X3850 M2 的 RAM 無法讓 IBM X3850 使用。
另外補充一點,MySQL DB 瞬間倒台(RAM 被吃光) 以後,除了緊急擴充 RAM 以外,還討論了以下兩種方案:
- 維持 active/standby:如此當 active server 倒台的時候 backup server 可接手服務,資料也比較不會有不一致的問題。但是現況是 backup server 的 RAM 比 active server 還弱!因此若 active server 倒台,backup server 一定撐不住 (而且會更快倒),也就無法發揮「接手服務」的功能。
- 將 Web Server & DB Server 分群:如上所述,當倒台時由於 backup server 實際上無法接手 active server 的服務,因此不如設定 n 台 web server 對應 active DB server,另外 m 台 web server 對應到 backup DB server,在兩台 DB Server 資料隨時雙向同步的狀況下,同時讓兩台 DB server 一起提供服務。有的考量是怕資料會不一致,而且萬一某一台 server 倒掉了就沒人接手了。
最後經過討論,仍決定維持方案1 (active/standby),幸好到後來 DB 有撐住。以當天的 loading 來看,若 RAM 沒有擴充可能會撐不住,但研判改寫程式才是 DB loading 能降低的主因(動態網頁-->靜態網頁),也許未來遇到像這次可預期的超大需求的時候可以提早調整程式。
個人的感想是採用方案二可以提供更好的效能,因為發生硬體障礙的機率應該是遠低於把所有的流量都導向 active server 而造成倒台。而且一旦 active server 倒台,服務會完全停擺 (standby server 一接手就會馬上倒),除非把 web server 的流量限制設定的很嚴格,才能讓 DB 維持運作。
若採用分群,則兩台 DB server 的 loading 都不會太高,倒台的機率就會大大降低,但最重要的前提是兩台 server 間的資料可以完美的同步,最後每一筆資料都要能由 timestamp 來排序。
在 MySQL HA Overview 一文中官方也說明了如何提供 HA 的架構,很值得仔細研究。
個人的感想是採用方案二可以提供更好的效能,因為發生硬體障礙的機率應該是遠低於把所有的流量都導向 active server 而造成倒台。而且一旦 active server 倒台,服務會完全停擺 (standby server 一接手就會馬上倒),除非把 web server 的流量限制設定的很嚴格,才能讓 DB 維持運作。
若採用分群,則兩台 DB server 的 loading 都不會太高,倒台的機率就會大大降低,但最重要的前提是兩台 server 間的資料可以完美的同步,最後每一筆資料都要能由 timestamp 來排序。
在 MySQL HA Overview 一文中官方也說明了如何提供 HA 的架構,很值得仔細研究。
其他感想
- 要擴充實體機器是相當麻煩的,遠比擴充 VM 困難的多,特別是網路設定的部份(設定 IP、VIP 等,不小心還會插錯 switch…而且插錯 switch 挺難查的,可能會造成明明網路有通,但是 apache 接不到 HTTP request 的詭異情況)。
- 如果活動真的很盛大,瞬間湧入超大的流量,那麼 DB Server 有可能會瞬間倒台,時間推測在幾十秒到一分鐘之間。假設系統架設在 Amazon EC2 上,能不能在這麼短的時間內 clone 一台新的 server 並且立刻上線提供服務?雖然說在虛擬化環境中可在短短數分鐘內就新增一台 server,相較於擴充實體 server 已經是非常快速,但要應付瞬間如此大量的需求可能還是不足,最理想的狀況是能夠在數秒鐘,或者 10 秒內就擴充第一台 server,讓整個 DB cluster 能夠撐下去,之後就比較有餘裕來進一步擴充了。
沒有留言:
張貼留言