流量控管
- 應該請行銷人員事先通知系統管理人員何時會發行銷簡訊，以便提早設定 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 能夠撐下去，之後就比較有餘裕來進一步擴充了。
