IIS負載均衡-Application Request Route詳解第一篇： ARR介紹

IIS負載均衡-Application Request Route詳解第一篇： ARR介紹

說到負載均衡，相信大家已經不再陌生了，本系列主要介紹在IIS中可以采用的負載均衡的軟件：微軟的Application Request Route模塊。

其實Application Request Route已經有很多文章介紹過了，但是有很多的文檔都是英文的，筆者在項目中，曾經為了使用和測試Application Request Route，將有關的文檔已經轉為中文，在組員之間傳閱，本系列在這些文檔的中，再加入一些使用的心得。

 

本篇議題如下：

Application Request Route介紹

Application Request Route安裝

 

系列文章鏈接：

IIS負載均衡-Application Request Route詳解第一篇： ARR介紹  

IIS負載均衡-Application Request Route詳解第二篇：創建與配置Server Farm

 IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（上） 

IIS負載均衡-Application Request Route詳解第三篇：使用ARR進行Http請求的負載均衡（下） 

IIS負載均衡-Application Request Route詳解第四篇：使用ARR實現三層部署架構

 

 

Application Request Route介紹

 

Application Request Route（后面簡稱為ARR）是一個寄宿於IIS7（及以后的IIS版本）的一個基於代理的模塊，它可以通過判斷Http Headers，Server Variables以及負載均衡算法將HTTP的請求轉發到不同的處理服務器之上。ARR的用處如下：

1. 增強應用的可用性與擴展性
2. 更好的利用服務器資源
3. 使得應用程序的部署更加方便，並且支持衛星部署管理與熱替換
4. 更低的管理成本，使得共享宿主的部署成為可能

 

ARR是基於URL Rewrite Module的，它通過檢測客戶端發來的HTTP請求來做出請求路由的決定。

 

下面，我們就進一步的看看ARR的一些特征：

 

1.基於HTTP請求，做出的請求路由的決定

 

       與硬件的負載均衡不同（在OSI模型的IP層來決定請求的路由方式），ARR是基於應用層來進行負載均衡的，因為在應用層可用的信息更多（其實談到這里，是很有必要把負載均衡的原理講清楚的，但是，因為本系列主要是講述ARR，所以，對已一些底層原理性的概念，不會做過多的涉及，以后計划為朋友們系統的講述負載均衡的原理及其實現,可以參看：負載均衡第一篇-介紹篇）。通過在ARR中使用URL  Rewrite Module，我們就可以實基於Http Headers與Server Variables來實現個更強大的路由規則。

 

2.提供多種負載均衡算法

我們可以自己決定使用哪一種負載均衡算法來進行請求的路由，ARR提供了以下6種算法。

 

3.健康檢查

       我們可以使用“實時通信“和”特定Url測試“來檢查服務器的健康狀況。並且，我們還可以通過使用很多的參數來決定到底什么樣的狀況才是健康的正常的服務器，例如，有人認為只要服務器是開啟的，就是健康的；也有人認為，服務器開啟，並且處理的請求沒有超載是健康的，等等。另外，我們還可以通過使用自己的提供Health Monitoring Provider來實現自己的健康檢查可能。

 

4.客戶端親緣性

       關於親緣性，相信大家不再陌生，我這里稍微的提一下：就是更加傾向於，或者喜歡那個。例如，在SQL Server中可以設置CPU的親緣性，，假設現在有四個CPU，編號分別是A,B,C,D,現在我們SQL Server的CPU親緣性設置到A上，就是說: SQL Server在處理請求的時候，更加喜歡把請求發送給編號為A的CPU來處理，當然也會將請求發送給其他的CPU，但是A的CPU處理請求的機會更多。

 

同理，在ARR中，可以通過設置客戶端的親緣性，ARR主要是通過使用Cookie來實現的。至於如何實現的，其實也很簡單，這里暫且不說。

 

這里就來說說客戶親緣性的一些需要考慮的點：

1. 如果使用了客戶端親緣性，就可以在應用中使用傳統的Session和Cache，而沒有必要使用分布式的Session和Cache。這里，以Session為例子，因為很多的時候，我們都需要將一個站點應用部署到多個服務器上，如果在某些地方使用了Session，特別保存用戶的一些數據的時候，就需要使用分布式的Session，用戶登錄就是一個最明顯的例子（避免用戶從服務器A上登錄，當下一次請求在B服務器處理的時候，還需要再次登錄）。使用客戶端親緣性，ARR就可以將同一個用戶的請求再次轉發到用戶第一次請求的服務器上。
2. 使用客戶端親緣性，就在一定程度上面失去了負載均衡的意義。因為設置了客戶端親緣性，即使用戶初次請求的服務器現在壓力很大，那么ARR還是會將用戶的請求轉發過去。
3. 客戶端親緣性，失去了高可用性。因為很有可能現在處理用戶請求的服務器已經宕機了，雖然ARR有健康檢查機制，但是ARR還是可以將請求發給宕機的服務器，導致請求無法處理。 

5.宿主名親緣性

理解了上面的“客戶端親緣性“，這里就更加容易理解了。“ 宿主名親緣性”主要使用在共享服務器中的（很多人使用一台服務器，就是站點部署的時候，購買的是“虛擬地址空間”）。我們后面在提到的時候，會詳細講解。

 

6.服務器分組

ARR可以管理很多的服務器組，其中每一組又包含多台服務器服。

 

7.基於圖形化界面的管理與健康

ARR與IIS集成，並且，通過了可視化的，便於操作的可視化操作界面。

 

 

8.制定請求失敗的跟蹤規則

在ARR中，可以定義特定的跟蹤規則，當請求處理失敗之后查看跟蹤信息，便於診斷。

 

Application Request Route安裝

下面，我們就介紹ARR的安裝，便於大家快速上手與學習：

ARR依賴於以下組件：

1. Microsoft URL Rewrite Module for IIS 7.0.
2. Microsoft Web Farm Management Version 1 for IIS 7.0.
3. Microsoft Application Request Routing Version 1 for IIS 7.0.
4. Microsoft External Cache Version 1 for IIS 7.0.

              

ARR的安裝，需要相關的環境，如下：

1. IIS 7.0 以及以后的版本（筆者在Win 7和Server2008中都安裝過，是可以的）

 

下面開始進入安裝：

 

1. 下載ARR：

現在ARR已經發展了2.5的版本，可以說已經很穩定了，筆者也在一些大型項目中已經采用，效果還不錯。

現在地址：http://www.iis.net/download/ApplicationRequestRouting

 

 

2. 現在ARR集成在Web 安裝平台中，如下：

 

3.點擊“Install”，開始安裝

4.安裝之后，打開IIS的控制窗口，如下（Win7系統的界面）：

如果看到有“Server Farms”，就說明安裝OK了。

 

5.配置應用程序池

所有的HTTP請求都需要經過ARR。所以，我們希望在安裝了ARR的服務器上的IIS要必須不停的運行，不停把請求轉發到其他的服務器上面，也就是說：這台安裝了ARR的服務器基本的功能就是請求轉發。

 

假設現在我們手里有3台服務器（編號分別為A,B,C）來部署agilesharp的站點，安排如下：

現在服務器A向外面暴露的地址假設為:159.12.2.15，那么我們在A服務器上建立一個agilesharp的站點，如下：

並且，我們設置agilesharp站點的應用程序池為IIS的集成模式。這個時候，因為這個站點其實只是暴露給外面，真正的請求處理在B和C服務器。所以，我們要設置這個agilesharp的站點的應用程序池，從而它源源不斷的接受HTTP請求（應用程序池默認是不會不斷的介紹請求的，它有一個時間的延時，這個延時的時間往往就是默認的請求處理時間），然后由ARR轉發。

 

設置如下：

將Idle Time-out (minutes)設置為0,然后保存就OK了。 

OK，介紹就到這里，下一篇，我們就來看看一些具體的應用！