傳統的架站方式(非雲端運算/虛擬化環境)要如何應付超大量的流量

前陣子我負責維運的網站由於配合行銷活動的關係，在短時間內湧入超大的流量，而這個系統是用傳統的架構(也就是用多台實體 server 做 load-balance，配合網路的 VIP 設定以 IP-hashing 分流)做的，在應付這種超大流量的時候顯得力不從心，以下紀錄採用如此架構要應付超大流量時，要注意的地方。

流量控管

1. 應該請行銷人員事先通知系統管理人員何時會發行銷簡訊，以便提早設定 web server 的流量限制 (concurrent sessions)，以免瞬間倒台。雖然超出流量限制的 user 無法連線成功，但只要 retry 就可能連的上。這樣的作法可確保 web server 不會倒台，在能力範圍內提供最多的服務。
2. DB server 倒台時可能要花很長時間才能回復，在這些 downtime 時損失的流量是難以挽回的。
3. 平常應該透過壓力測試，或者流量分析的歷史紀錄來評估每台 Web server 最多可接受多少個concurrent sessions，以便進行上述的流量限制。
4. Web server concurrent sessions 的設定應慢慢逐步放寬，以免瞬間超過 server 的負荷量而倒台。
5. 要注意 Apache httpd.conf 裡面的「MaxClients」設定值，若設定值過高可能造成 server 無法負荷(甚至造成接 console 也無反應，沒有螢幕，必須重開機)。(預設值為256)
   

硬體設備

1. 上線前要作 end to end 的測試(包含所有備用機)，備用機的狀態應該調整到只要 VIP 一 enable，就會有流量進來的程度，只是在 VIP 設定中暫時 disable，保持隨時可以上線的狀態。本次準備的一台備用機因 OS 環境與正式環境差太多 (如 Apache 版本、Apache modules 版本等)，最後無法即時在當天 config 完成並上線提供服務。
2. 設備的 RAM 應提早估計是否夠用，臨時要調 server 使用的 RAM 相當困難(e.g., 創見門市不賣 server 使用的 RAM，價錢也蠻貴的)，頂多只能把閒置的 server 停機來支援 (等到活動結束又要安排時間把 server 組態回復原狀，又要再花時間測試、驗證)。
3. IBM X3650/X3850 M2 的 RAM 無法讓 IBM X3850 使用。

另外補充一點，MySQL DB 瞬間倒台(RAM 被吃光) 以後，除了緊急擴充 RAM 以外，還討論了以下兩種方案：

1. 維持 active/standby：如此當 active server 倒台的時候 backup server 可接手服務，資料也比較不會有不一致的問題。但是現況是 backup server 的 RAM 比 active server 還弱！因此若 active server 倒台，backup server 一定撐不住 (而且會更快倒)，也就無法發揮「接手服務」的功能。
2. 將 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 的架構，很值得仔細研究。

其他感想

1. 要擴充實體機器是相當麻煩的，遠比擴充 VM 困難的多，特別是網路設定的部份(設定 IP、VIP 等，不小心還會插錯 switch…而且插錯 switch 挺難查的，可能會造成明明網路有通，但是 apache 接不到 HTTP request 的詭異情況)。
2. 如果活動真的很盛大，瞬間湧入超大的流量，那麼 DB Server 有可能會瞬間倒台，時間推測在幾十秒到一分鐘之間。假設系統架設在 Amazon EC2 上，能不能在這麼短的時間內 clone 一台新的 server 並且立刻上線提供服務？雖然說在虛擬化環境中可在短短數分鐘內就新增一台 server，相較於擴充實體 server 已經是非常快速，但要應付瞬間如此大量的需求可能還是不足，最理想的狀況是能夠在數秒鐘，或者 10 秒內就擴充第一台 server，讓整個 DB cluster 能夠撐下去，之後就比較有餘裕來進一步擴充了。

參考資料

1. Apache httpd.conf : MaxClients
2. MySQL HA Overview

[MySQL] 設定資料庫定期自動備份

上週開始持續調整以 Joomla 架設的資產管理系統，其中一個需求是自動定期備份 DB，如此便可追蹤這些設備在一段時間內的變化(其實我還是覺得如果要作版本控管的話，用 svn 或者 git 之類的版本控管軟體會更好…)，當發生不幸的意外時也才能迅速的將寶貴的資料還原。

由於 Joomla 的資料都存在 MySQL DB 中，因此今天就 survey 了一下讓 MySQL 定期排程備份的作法。

I.以 shell script 呼叫 mysqldump 執行備份，將此 script 寫入 crontab 排程中

參考資料：MySQL 備份 shell script。這 script 的核心非常簡單，只有一行而已 (其他更 fancy 的工具應該也是呼叫這個 MySQL 內建的 dump 工具)：

mysqldump -u $db_user -h $db_host -p$db_passwd $db | $GZIP -9 > "$backup_dir/backup.0/$time.$db.gz"

而 crontab 的編寫也是玩 Linux / Unix 的基本功，可參考：鳥哥的 Linux 私房菜-第十六章、例行性工作排程 (crontab)。以這個方法來備份 MySQL 大概是最不求人、也相當普遍的作法。

II.利用 Navicat full version 來作

參考資料：[教學] MySQL 定期自動備份。這是一個可安裝在 Windows / Linux / Mac OS X 平台的 client 端軟體，安裝和操作都相當方便 (畫面蠻漂亮的)。雖然說 Navicat 有推出一個免費的 Navicat Lite，但是免費版連手動執行 backup 都做不到呀！因此它就很遺憾的出局了，但是有錢買來用的話應該相當好用 (最貴的授權要台幣一萬出頭)，看來這軟體也是相當的知名。

III.利用 phpMyBackupPro (pMBP) 來作

2010-03-23 補充：[網管人雜誌] MySQL 專用備份工具-phpMyBackupPro (長篇的詳細說明)

參考資料：Web 介面的 MySQL 備份工具-phpMyBackupPro, 官方網站下載頁面在這裡，這是個 host 在 SourceForge 的 open source 專案，所以是免費的！安裝的過程非常簡單，在 Windows 平台上只要把解縮後的 phpMyBackupPro 資料夾複製到 Apache 的根目錄下即可。

2010-03-23 補充：在 Linux 平台上安裝也很簡單，只要把資料夾 export 及檔案 global_conf.php 設定權限為 0777 就可以了。執行身分為 apache。

其中最重要的一點是，若 DB 中有儲存中文資料，要依照論壇中 slimn 前輩提供的修改方式來調整，經過測試確實有效 (Windows 平台 OK, 目前在 Linux 測試機上仍為亂碼 [2010-03-23])：

以下補充教學文章中沒有特別說明的設定畫面。

在 configuration tab中，可設定僅備份指定 DB：

在 backup tab 中，記得要手動選取欲執行備份的 DB：

在 backup tab 中可設定是否要壓縮備份產出的 .sql 檔，有 gzip / zip 格式：

在 schedule backup tab 中，可設定自動執行備份的週期：

包括每小時、每6小時、每12小時、每天、每週、每月等等週期。

在 schedule backup tab 中，也可自訂定期備份 php 檔的檔名：

在 import tab 中，若已經執行過備份，則可觀看指定備份檔(.sql) 的各項資訊：

包括執行備份的日期時間、DB Name、file size 等。

關於 schedule backup：

在Web 介面的 MySQL 備份工具-phpMyBackupPro一文中提到，schedule backup 感覺不太實用，因為排程備份的作法是一段 php 程式碼，而phpMyBackupPro 只是負責幫你產出這段 code，必須要另外加工讓這段 code 能夠定時執行 (不管是利用網頁的 META Refresh 或者在 crontab 中定期用 wget 去 request 這個 php 網頁)。但我覺得 phpMyBackupPro 還可提供備份後自動上傳到 FTP、自動寄送 mail 等等，而且檢視/還原 backup 檔案的介面也十分簡便，安裝和設定也很容易就可以上手，還是很不錯用的啦！