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

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 建構雲端應用程式,大概將近兩百頁篇幅,有興趣的可以下載回來看看。

相關連結