- 追加された行はこの色です。
- 削除された行はこの色です。
Open棟梁Project - マイクロソフト系技術情報 Wiki
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>冗長化アーキテクチャ]]
* 目次 [#r23a84e8]
#contents
*概要 [#d748ee1e]
Microsoft Application Request Routing Version 1 for IIS
-Application Request Routing モジュールの使用~
https://technet.microsoft.com/ja-jp/library/ee886282.aspx
>HTTP ヘッダー、サーバー変数、および負荷分散アルゴリズムに基づいて~
HTTP 要求をコンテンツ サーバーに転送するプロキシ ベースのルーティング モジュール
--アプリケーションの可用性とスケーラビリティを向上させる。
--コンテンツ サーバーのリソースを効果的に活用する。
--パイロット管理および A/B テストを含め、アプリケーションの展開を容易にする。
--管理コストを削減し、共有ホストに機会を創出する。
負荷分散クラスタからフェイルオーバークラスタのクラスタリングが可能。
*モジュール [#i130fc91]
ルーティングの決定を行うための受信 HTTP 要求の検査を URL 書き換えモジュール に依存しているため、~
Application Request Routing の機能を有効にするには URL 書き換えモジュールが必要。
*機能 [#c2995241]
**HTTP に基づくルーティングの決定 [#y9481e06]
-ルーティングの決定がアプリケーション レベルで行われる。
-URL 書き換えモジュールとの連携により、~
HTTP ヘッダーおよびサーバー変数に基づいて強力なルーティング規則を作成できます。
**負荷分散アルゴリズム [#sebc1082]
-HTTP 要求の処理に最適なコンテンツ サーバを判断する際に、~
ユーザーによって選択された負荷分散アルゴリズムが適用される。
-6 つのアルゴリズムが提供される。~
https://technet.microsoft.com/ja-jp/library/dd443524.aspx
***ラウンド ロビンの重み付け [#m0f9f7da]
-トラフィックの着信方向の要求の数と、標準化された重みに基づいて分散される。
-各サーバーには、同じ要求の分布やカスタム分布が表示されます。
***トラフィックの加重合計 [#y3e98c66]
-トラフィックの要求と応答のバイト単位のサイズに基づいて分散される。
-データの量が負荷分散されるように要求がルーティングされる。
-均一な分布では、データ量が最も少ないサーバは次の要求を受信する。
***最小の要求 [#we6263c7]
-ARR と各アプリケーション サーバーの間の HTTP 要求の現在の数に基づいて分散される。
-HTTP 要求の現在の数を最小限にする。
***最小限のレスポンスタイム [#iade6153]
-最も高速なサーバーからのレスポンス・タイムに基づいて分散される。
-トラフィックが最もすばやく対応することができる。
***サーバー変数のハッシュ [#q52b5ce7]
サーバー変数のハッシュ値に基づいて分散される。
***クエリ文字列のハッシュ [#hf31af97]
クエリ文字列の値のハッシュ値に基づいて分散される。
***ハッシュを要求 [#jf1058e6]
サーバー変数または URL のハッシュ値に基づいて分散される。
**健常性の監視 [#o06af160]
コンテンツ サーバーの健常性を判定する際に、
-現状のトラフィックと特定の URL テストの両方が使用される。
--サーバーの健常性を定義するための構成パラメーターのセットが提供される。
-現状のトラフィックと特定の URL テストを使用しない場合、~
RSCA API を呼び出して、サーバーの健常性を設定する~
カスタムの健常性監視プロバイダーを使用することもできる。
**クライアント アフィニティ [#h497f17b]
Cookie を使用して、クライアントからコンテンツ サーバーへのすべての要求をアフィニティ化。~
これにより、NAT の背後にあるクライアントを識別し、各クライアントは個別に扱われる。
**ホスト名アフィニティ [#g62dac7f]
共有ホスト提供者向けの特別な機能。
展開トポロジを変更して、管理を最小限に抑えて合理化。
**複数のサーバー グループ [#i9dfd88c]
複数のサーバー グループ (環境内のコンテンツ サーバーの論理グループ) を管理できる。
**UI を使用した管理および監視 [#labe0bc5]
構成設定および集計されたランタイム統計は、IIS マネージャーを使用して管理/表示。
**失敗した要求トレース規則 [#f70c5694]
トラブルシューティングおよび診断用のトレース。
*クラスタの組合せ [#sd234943]
高い可用性とスケーラビリティの実現 - ARR および NLB~
http://technet.microsoft.com/ja-jp/library/ee886284.aspx
-https://technet.microsoft.com/dynimg/IC365771.jpg
>ARR では、コンテンツ サーバーに対して~
高い可用性とスケーラビリティを提供していますが、~
展開全体の可用性とスケーラビリティは高くありません。
>これには、次の理由があります。
-ARR は単一障害点である。
-コンテンツ サーバーのスケーラビリティが、~
単一の ARR サーバーの最大容量によって制限されている。
>上記の課題を克服するために、管理者はNLBと組み合わせた~
複数の ARR サーバーの使用を検討することができます。
-https://technet.microsoft.com/dynimg/IC365781.jpg
>ARR は、
--アクティブ/パッシブ モードで展開して、高可用性のみ実現できます。
--または、アクティブ/アクティブ モードで展開して、~
高い可用性とスケーラビリティの両方を実現できます。
>ARR と NLB を一緒に展開して、
-ARR のコア シナリオを有効にし、
-かつ、全体的に高い可用性とスケーラビリティを実現する
>方法について説明しています。
>NLB は、Windows Server 2008 のすべてのSKU（製品ラインアップ）で使用できます。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
