The Will Will Web

記載著 Will 在網路世界的學習心得與技術分享

Microsoft Azure Web Sites 如何設定自動復原機制

我的部落格已經移往 Microsoft Azure Web Sites (MAWS) 代管數月,剛搬上去的時候確實不太穩定,畢竟我原本的伺服器有 8GB 記憶體,搬上 MAWS 之後只剩下 1.7GB 可用 (為了省錢),可使用的資源差很多,也因此發現自己的部落格在資源不足的情況下,穩定度極差。為了讓我的網站能夠穩定運作,我研究了一下,發現今年年初 MAWS 有個 ALWAYS ON 更新,可以讓網站在出問題時「自動復原」,這功能拯救了我,網站也從此穩定許多,來看看這要怎麼用吧!

由於 MAWS 上面的網站,預設會在沒有人點擊網站的情況下被關閉,這樣會導致網站在接受下一個 HTTP 要求時速度較慢,因此你必須先啟用該網站的 ALWAYS ON 功能,如下圖示:

※請注意ALWAYS ON 功能僅適用於「標準」模式下的 Azure 網站。

啟用之後,要設定「自動復原」就相對簡單的多,我們先看一下以下網站的 web.config 設定範例:

<system.webServer>
    <monitoring>
        <triggers>
        </triggers>
        <actions value="ACTION" />
    </monitoring>
</system.webServer>

上述設定區段中,<monitoring> 就是 MAWS 支援的網站監控功能設定區段,在這設定裡面 <triggers> 是用來定義「觸發的事件」,可以一個以上,稍後會有些實際範例。而 <actions> 就是當事件觸發時要執行什麼動作,通常都會把 value 指定為 Recycle,也就是回收應用程式集區的意思。

以下有幾種需要「自動復原」網站的使用情境:

1. 依據「記憶體使用量」來回收 (Recycle) 應用程式集區

這也是我網站主要的設定,也就是針對記憶體使用超量時執行應用程式集區的回收工作,讓負責執行網站的應用程式集區重新啟動。以下範例即設定當記憶體用量超過 700MB 時自動回收應用程式集區!

<system.webServer>
    <monitoring>
        <triggers>
            <memory privateBytesInKB="700000" />
        </triggers>
        <actions value="Recycle" />
    </monitoring>
</system.webServer>

2. 依據網站的回應速度來回收 (Recycle) 應用程式集區

這也是我部落格的一個考量指標,依據那些回應時間非常長的狀況,來強制回收應用程式集區。如下範例即設定當 HTTP 要求的執行的時間超過 45 秒,而且在 10 分鐘以內發生超過 20 次的話,即觸發回收動作!

<system.webServer>
    <monitoring>
        <triggers>
            <slowRequests timeTaken="00:00:45" count="20" timeInterval="00:10:00" />
        </triggers>
        <actions value="Recycle" />
    </monitoring>
</system.webServer>

這裡的 timeInterval 屬性,會在該網站第一個 HTTP 要求進來並啟動應用程式集區後開始計時,並開始累積 slowRequests 發生的數量,等到了定義的 timeInterval 時間區間 (例如 10 分鐘) 之後,就會將累計的次數歸零,並重新開始計算。如果在 timeInterval 時間內到達觸發的條件,就會引發回收應用程式集區,因此 timeInterval 將會重新開始計算,原本累計的次數也會歸零。

3. 依據 HTTP 要求的執行次數到達一定數字後,自動回收應用程式集區

這也是一個常見的解決方法,當你不確定網站到底是因為什麼而當掉時,可以設定當 HTTP 要求次數達到一個數字後,自動回收應用程式集區。以下設定即代表當在 10 分鐘以內 HTTP 要求次數達 1 萬次後,自動回收應用程式集區。

<system.webServer>
    <monitoring>
        <triggers>
            <requests count="10000" timeInterval="00:10:00" />
        </triggers>
        <actions value="Recycle" />
    </monitoring>
</system.webServer>

上述觸發條件成立後,都會自動被記錄一筆事件到事件檢視器紀錄中,而儲存事件的檔案就放在你的 Azure 網站目錄的上層目錄中。如下圖示,我用 FileZilla 登入該網站,然後回上兩層,這時你會看到一個 LogFiles 資料夾,在裡面有個 eventlog.xml 檔案,裡面紀錄了你的 Azure 網站所有的事件紀錄。

image

4. 依據特定 HTTP 回應狀態碼,記錄到事件紀錄檔中

如果你已經知道有特定 HTTP 回應狀態碼會不定時發生,但你想要監控這些壞掉的 HTTP 要求,可以參考以下設定。以下設定為,當 1 分鐘以內,網站回應 500.100 的狀態碼超過 10 次,就要自動記錄該資訊到 eventlog.xml 事件紀錄檔中。

<system.webServer>
    <monitoring>
        <triggers>
            <statusCode>
                <add statusCode="500" subStatusCode="100" win32StatusCode="0" count="10" timeInterval="00:01:00" />
            </statusCode>
        </triggers>
        <actions value="LogEvent" />
    </monitoring>
</system.webServer>

5. 當觸發條件時,執行自訂動作

如果你想當觸發條件成立時,立即取得 w3wp.exe 處理序的完整資訊,這時你可以利用 Windows Sysinternals 工具集中的 ProcDump 工具幫你把所有 w3wp.exe 的處理序都收集下來,供日後分析。

由於處理的動作比較複雜,這時你就可以設定「自訂動作」,來完成這些工作。執行自訂動作的方式很簡單,就是直接執行一個 exe 執行檔,並指定參數。在參數列中,你可以用 %1% 變數來代表 PID (Process ID),如下範例:

<system.webServer>
    <monitoring>
        <triggers>
            <memory privateBytesInKB="700000" />
        </triggers>
        <actions value="CustomAction">
            <customAction exe="d:\home\procdump.exe" parameters="-accepteula w3wp d:\home\w3wp_PID_%1%_" />
        </actions>
    </monitoring>
</system.webServer>

這裡比較值得一提的地方有:

  • 這個 d:\home 路徑,是 Azure 網站預設的根目錄,所有網站都一樣,這是一個虛擬目錄,所以你要存取檔案,都用這個路徑就是了!所以請透過 FTP 把主程式上傳上去,如下圖示:
  • ProcDump 工具在第一次執行時,都會先問你要不要同意 EULA (End User License Agreement),需要你跟程式互動,由於你無法看到命令提示字元介面,所以執行時請務必加上 -accepteula 參數,否則程式可能會無法執行。

結語

我剛把網站搬上雲端時,真的會不太理性。第一,原本網站好好的,搬上去才掛掉,會第一時間怪罪雲端平台太爛。第二,從以前吃到飽的方案換成用多少算多少的計價模式,會覺得越省越好,所以只要被多扣個幾塊錢,就會覺得很貴,心理覺得划不來。第三,以前用遠端桌面隨時可以連到主機看狀況,現在用了超便宜的 Azure 網站,很多東西都碰不到,必須在限制的環境下調整網站設定,心中自然有些抗拒感。

不過,各位也許很難想像,我的部落格一直以來流量都不小,網站擺在公司的機房內以為共用機房比較省錢,誰知道自從把網站搬上 Azure 雲端之後,每個省下的機房費用將近 NT$ 8,000 之多,真是太嚇人了,心中難免會想 “早知道早點搬上去就好了,可以省下不少錢呢!"。

所以,自己的網站搬上雲端後不太穩定,當然不能怪 MAWS 不穩定,上了雲端,很多事情都不太一樣,最重要也最迫切需要改變的是「對資源的思考模式必須做出調整」,為了省錢,你必須斤斤計較,否則你沒辦法享受到飛上雲端的各種好處。

當然,上雲端絕對不單單只有「省錢」這樣簡單而已,對於巨量資料與超大流量的網站服務,透過雲端所帶來的實質效益,也絕對不是金錢可以衡量的,例如可橫向延展(Scale out)的架構、近乎無限的儲存空間、高可用性的架構、全球負載平衡的機制、…等等,都是非常值得投入與學習的部分。

不過,記得不要用傳統 IT 的心態去思考雲端架構的運作,想要飛上雲端,總不能用走在陸地上的邏輯思考,所以腦袋要先跟著變,才會飛的順利。這邊我推薦一本免費電子書 Building Cloud Apps with Microsoft Azure,本書會教你如何利用 Microsoft Azure 建構雲端應用程式,大概將近兩百頁篇幅,有興趣的可以下載回來看看。

 

相關連結

留言評論