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安裝

系列文章連結：

<a href="http://www.agilesharp.com/u/yanyangtian/Blog.aspx/t-199">IIS負載均衡-Application Request Route詳解第二篇：建立與配置Server Farm</a>

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

增強應用的可用性與擴充性

更好的利用伺服器資源

使得應用程式的部署更加友善，并且支援衛星部署管理與熱替換

更低的管理成本，使得共享宿主的部署成為可能

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

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=105" target="_blank"></a>

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

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

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來實作的。至于如何實作的，其實也很簡單，這裡暫且不說。

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

如果使用了用戶端親緣性，就可以在應用中使用傳統的Session和Cache，而沒有必要使用分布式的Session和Cache。這裡，以Session為例子，因為很多的時候，我們都需要将一個站點應用部署到多個伺服器上，如果在某些地方使用了Session，特别儲存使用者的一些資料的時候，就需要使用分布式的Session，使用者登入就是一個最明顯的例子（避免使用者從伺服器A上登入，當下一次請求在B伺服器處理的時候，還需要再次登入）。使用用戶端親緣性，ARR就可以将同一個使用者的請求再次轉發到使用者第一次請求的伺服器上。

使用用戶端親緣性，就在一定程度上面失去了負載均衡的意義。因為設定了用戶端親緣性，即使使用者初次請求的伺服器現在壓力很大，那麼ARR還是會将使用者的請求轉發過去。

用戶端親緣性，失去了高可用性。因為很有可能現在處理使用者請求的伺服器已經當機了，雖然ARR有健康檢查機制，但是ARR還是可以将請求發給當機的伺服器，導緻請求無法處理。 

5.宿主名親緣性

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

6.伺服器分組

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

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

ARR與IIS內建，并且，通過了可視化的，便于操作的可視化操作界面。

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

在ARR中，可以定義特定的跟蹤規則，當請求處理失敗之後檢視跟蹤資訊，便于診斷。

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

ARR依賴于以下元件：

Microsoft URL Rewrite Module for IIS 7.0.

Microsoft Web Farm Management Version 1 for IIS 7.0.

Microsoft Application Request Routing Version 1 for IIS 7.0.

Microsoft External Cache Version 1 for IIS 7.0.

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

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

下面開始進入安裝：

1. 下載下傳ARR：

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

2. 現在ARR內建在Web 安裝平台中，如下：

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=106" target="_blank"></a>

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

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

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=107" target="_blank"></a>

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

5.配置應用程式池

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

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

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=108" target="_blank"></a>

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

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=109" target="_blank"></a>

并且，我們設定agilesharp站點的應用程式池為IIS的內建模式。這個時候，因為這個站點其實隻是暴露給外面，真正的請求處理在B和C伺服器。是以，我們要設定這個agilesharp的站點的應用程式池，進而它源源不斷的接受HTTP請求（應用程式池預設是不會不斷的介紹請求的，它有一個時間的延時，這個延時的時間往往就是預設的請求處理時間），然後由ARR轉發。

設定如下：

<a href="http://www.agilesharp.com/Services/BlogAttachment.ashx?AttachmentID=110" target="_blank"></a>

将Idle Time-out (minutes)設定為0,然後儲存就OK了。 

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

本文轉自yanyangtian51CTO部落格，原文連結：http://blog.51cto.com/yanyangtian/817136 ，如需轉載請自行聯系原作者