高い可用性とスケーラビリティの実現 - ARR およびハードウェア ロード バランサー
公開日: 2008 年 11 月 13 日 (作業者: wonyoo (英語))
更新日: 2009 年 2 月 16 日 (作業者: wonyoo (英語))
要約
このドキュメントでは、高い可用性とスケーラビリティを実現するために、Application Request Routing (ARR) をネットワーク負荷分散 (NLB) と組み合わせて使用する方法について規範的なガイダンスを提供しています。ARR とハードウェア ロード バランサーとの連携関係を示すために、このドキュメントでは F5 BIG-IP ハードウェア ロード バランサーを使用します。
概要
Microsoft Application Request Routing (ARR) for IIS 7.0 は、HTTP ヘッダー、サーバー変数、および負荷分散アルゴリズムに基づいて HTTP 要求をコンテンツ サーバーに転送するプロキシ ベースのルーティング モジュールです。一般的な ARR 展開を以下の図に示します。
.jpg "Ee886283.ARR Overview(ja-jp,TechNet.10).jpg")
ARR では、コンテンツ サーバーに対して高い可用性とスケーラビリティを提供していますが、展開全体の可用性とスケーラビリティは高くありません。これには、次の理由があります。
- ARR は単一障害点である。
- コンテンツ サーバーのスケーラビリティが、単一の ARR サーバーの最大容量によって制限されている。
上記の課題を克服するために、ハードウェア ロード バランサー (F5 BIG-IP など) と組み合わせた複数の ARR サーバーの使用を検討することができます。ARR をアクティブ/パッシブ モードで展開すると、高可用性のみが実現されます。または、アクティブ/アクティブ モードで展開すると、高い可用性とスケーラビリティの両方を実現できます。このホワイトペーパーでは、ARR と F5 BIG-IP を一緒に展開して、ARR のコア シナリオを有効にし、かつ、全体的に高い可用性とスケーラビリティを実現する方法について説明しています。
Application Request Routing および F5 BIG-IP の使用
ARR は、IIS 7.0 上のモジュールとして構築され、第 7 層 (アプリケーション) でルーティングの決定を行うように設計されています。より正確には、ARR ではルーティングの決定を行うための受信 HTTP 要求ヘッダーとサーバー変数の検査を別の IIS 7.0 モジュールである URL 書き換え に依存しています。この設計を前提に、管理者はアプリケーション レベルの情報に基づき、インテリジェントなルーティング規則を作成できます。例を以下に示します。
- ホスト名 (HTTP_HOST): ホスト名に基づき、複数の異なるコンテンツ サーバーにトラフィックをルーティングします。
- 要求されたリソース (URL): ファイル拡張子に基づき、要求されたリソースが静的コンテンツ用か動的コンテンツ用かを判断し、その判断に応じて要求をルーティングします。
- クライアント情報 (HTTP_USER_AGENT): ブラウザーの種類とバージョンに基づき、要求を適切なコンテンツ サーバーにルーティングします。
- カスタム ヘッダー (アプリケーションで Cookie として設定されます): ユーザー設定やユーザー ID など、アプリケーションによって設定された Cookie 情報に基づき、トラフィックをルーティングします。
上記は、ほんの一例にすぎません。HTTP ヘッダーおよびサーバー変数の全一覧については、付録 A を参照してください。
F5 Big-IP の第 3 層および第 4 層の機能によって、第 7 層 (HTTP ヘッダーやサーバー変数など) に基づくルーティングの決定を行う際に、ARR の機能が強化されます。同じように、ARR 自体にはフォールト トレラント展開機能がなく、ARR 層での高可用性を実現するには、以下で説明するように、他の補完的なテクノロジやソリューションに依存する必要があります。
.jpg "Ee886283.ARR and LB(ja-jp,TechNet.10).jpg")
シナリオ 1: HTTP ベースのルーティングおよび負荷分散
HTTP ベースのルーティングおよび負荷分散シナリオにより、3 層展開アーキテクチャが実現します。各階層の内容を以下に示します。
- 第 1 層 (Web): 静的コンテンツを処理し、残りの動的な要求を第 2 層サーバーにルーティングして負荷分散する 2 つの目的があります。
- 第 2 層 (アプリケーション): ビジネス ロジックに依存した動的コンテンツを処理します。
- 第 3 層 (データ): データを保存します。
3 層展開の図を以下に示します。
.jpg "Ee886283.3 tier overview(ja-jp,TechNet.10).jpg")
上記の例は、静的コンテンツと動的コンテンツを区別するルーティング規則を示していますが、別の一般的なシナリオでは、プレゼンテーションの要求と Web サービスの要求が区別されています。
オプション 1: アクティブ/パッシブ
アクティブ/パッシブ モードでは、一般的に ARR サーバーが 2 台あり、1 台のサーバーが要求を処理している間、もう 1 台のサーバーはフェールオーバー サーバーとしてスタンバイします。前述したように、この構成では単一障害点を排除して高可用性を実現しますが、コンテンツ サーバーの総体的な容量は、単一の ARR サーバーの最大容量によって制限されるので、スケールアウトされたソリューションではありません。
この手順では、2 台の ARR サーバーが同じように構成されているため、共有構成が使用されています。F5 BIG-IP は、すべての要求を ARR アクティブ サーバーにルーティングし、必要な場合のみ、要求を ARR パッシブ サーバーにルーティングするように構成されています。
ARR のホスト名アフィニティ機能を除き、2 台の ARR サーバー間で共有する必要があるランタイム状態情報はありません。そのため、このシナリオでは、ARR または F5 BIG-IP で特別な構成は必要ありません。ARR のサーバー アフィニティ機能を使用する場合でも、F5 BIG-IP の要求のルーティング先が以前はパッシブ サーバーで、現在はアクティブ サーバーであるとき、アフィニティ化された状態情報は、要求ヘッダー内の Cookie を使用してパッシブ サーバーから利用できます。
このシナリオは、ARR Version 1 リリースで完全にサポートされています。
ARR の構成
手順 1: 2 台の ARR サーバーで共有構成を有効にする
- このドキュメントの手順に従って、IIS 7.0 で共有構成をセットアップします。
手順 2: ARR を使用して、3 層展開アーキテクチャを構成する
このドキュメントの手順に従って、3 層展開アーキテクチャで ARR を構成します。
上記のドキュメントを簡単にまとめると、以下の方法について説明しています。
- ARR サーバーで静的コンテンツを使用できるようにする方法。
- ARR サーバーから直接処理されるように、静的コンテンツの URL 書き換え規則を作成する方法。
- アプリケーション サーバーに転送されるように、動的コンテンツの URL 書き換え規則を作成する方法。
F5 BIG-IP の構成
このシナリオでは、2 台以上で構成される ARR サーバーのプールに負荷分散を行う仮想サーバーを作成します。 選択した負荷分散方法で、ARR プライマリ サーバーが稼働している間、このサーバーにすべてのトラフィックが送信されるようにします。 ARR プライマリ サーバーが使用できなくなった時点で、すべてのトラフィックが BIG-IP LTM から ARR セカンダリ サーバーに送信されるようにします。
手順 1: ARR サーバーのプールを構成する
- [ローカル トラフィック] セクションで、[プール] をクリックします。 次に、[作成] ボタンをクリックして、プールを作成します。
- 一意の名前であればどれでも、プールに使用できます。例では、「ARR_Pool」を使用します。
- [ヘルス モニタ] では、カスタムの HTTP モニターまたは既定の HTTP モニターを使用できます。
- [負荷分散方式] の設定は、「ラウンド ロビン」のままにすることができます。 このシナリオでは、ARR サーバーはアクティブとパッシブだけなので、負荷分散は使用しません。
- [優先度グループの有効化] が有効になっていることを確認します。 これにより、BIG-IP が優先順位の最も高い値を持つサーバー (複数あり) にトラフィックを送信するように構成されます。 サーバー (場合によって複数) を使用できない場合、BIG-IP は次に優先順位の最も高い値を持つ ARR サーバーにトラフィックを送信します。
- このシナリオでは、10.0.0.1 の ARR サーバーの優先順位の値は「1」で、10.0.0.2 の優先順位の値は「2」に設定されています。すべてのトラフィックは、10.0.0.2 の ARR サーバーが停止するまで、このアドレスに送信されます。サーバーの停止後、トラフィックは 10.0.0.1 に送信されます。
.jpg "Ee886283.diag-1(ja-jp,TechNet.10).jpg")
手順 2: ARR サーバーのプールを構成する
- [ローカル トラフィック] セクションで、[仮想サーバー] をクリックします。 次に、[作成] ボタンをクリックして、仮想サーバーを作成します。
- 一意の名前であれば任意の名前を仮想サーバーに使用できます。例では、「ARR_VS」を使用します。
- [リダイレクト先] では、ユーザーが使用するブラウザーをポイントする IP アドレスを使用できます。 この特定の例では、「65.197.145.23」を使用します。 [サービス ポート] は、「80」を使用します。
- 仮想サーバーの [種類] セクションには、複数のオプションがあります。 ARR に依存してルーティングを行うので、パフォーマンスが最適化されるように設計された「Performance HTTP」を選択できます。
- [既定のプール] では、手順 1 で作成したプールを選択します。
.jpg "Ee886283.diag-2(ja-jp,TechNet.10).jpg")
- この時点で、この仮想サーバーに接続でき、適切な ARR サーバーに送信されます。
オプション 2: アクティブ/アクティブ
アクティブ/アクティブ モードでは、2 台以上の ARR サーバーを使用できます。高可用性のみを実現するアクティブ/パッシブ モードとは異なり、この構成では、高い可用性とスケーラビリティの両方が実現します。
前述したように、複数の ARR サーバーが同じように構成されているため、共有構成が使用されています。F5 BIG-IP は、使用できる正常な ARR サーバーすべてに対して受信要求の負荷分散を実行し、要求をコンテンツ サーバーに転送するように構成されています。
サーバー アフィニティ機能が F5 BIG-IP で使用されているかどうかに関係なく、ARR サーバー上で特別な構成は必要ありません。1 つ目の理由として、ARR サーバーでは、同じ方法で構成されるように単一の共有構成が使用されることが挙げられます。2 つ目の理由は、ARR では使用するサーバー アフィニティ情報を保存するためにクライアントの Cookie を使用するので、この情報は要求ごとに使用可能となり、すべての ARR サーバーで共有できることです。
このシナリオは、ARR Version 1 リリースで完全にサポートされています。
ARR の構成
アクティブ/アクティブの ARR の構成は、アクティブ/パッシブの場合と同じです。主な違いは、F5 の構成方法です。
手順 1: 2 台の ARR サーバーで共有構成を有効にする
- このドキュメントの手順に従って、IIS 7.0 で共有構成をセットアップします。
手順 2: ARR を使用して、3 層展開アーキテクチャを構成する
このドキュメントの手順に従って、3 層展開アーキテクチャで ARR を構成します。
上記のドキュメントを簡単にまとめると、以下の方法について説明しています。
- ARR サーバーで静的コンテンツを使用できるようにする方法。
- ARR サーバーから直接処理されるように、静的コンテンツの URL 書き換え規則を作成する方法。
- アプリケーション サーバーに転送されるように、動的コンテンツの URL 書き換え規則を作成する方法。
F5 BIG-IP の構成
このシナリオでは、使用できる ARR サーバーはすべてアクティブであり、負荷分散されたトラフィックの送信先候補と見なされます。BIG-IP LTM を使用して、ARR フロント エンド サーバーの健常性とパフォーマンスを判断し、パフォーマンスが最も優れたサーバーにトラフィックを送信します。
手順 1: ARR サーバーのプールを構成する
- [ローカル トラフィック] セクションで、[プール] をクリックします。 次に、[作成] ボタンをクリックして、プールを作成します。
- 一意の名前であれば任意の名前をプールに使用できます。例では、「ARR_Pool」を使用します。
- [ヘルス モニタ] では、カスタムの HTTP モニターまたは既定の HTTP モニターを使用できます。
- トラフィックを分散する対象となる ARR サーバーが複数あるので、ニーズに最適な負荷分散方法を選択します。 前提として、ARR サーバーのハードウェア特性がすべて同じようなものであれば、動的な負荷分散方法 (最速モード、監視モード、予測モードなど) により、パフォーマンス ベースの分散が可能となります。
.jpg "Ee886283.diag-3(ja-jp,TechNet.10).jpg")
手順 2: 仮想サーバーを構成する
- [ローカル トラフィック] セクションで、[仮想サーバー] をクリックします。 次に、[作成] ボタンをクリックして、仮想サーバーを作成します。
- 一意の名前であれば任意の名前を仮想サーバーに使用できます。例では、「ARR_VS」を使用します。
- [リダイレクト先] では、ユーザーが使用するブラウザーをポイントする IP アドレスを使用できます。 この特定の例では、「65.197.145.23」を使用します。 [サービス ポート] は、「80」を使用します。
- 仮想サーバーの [種類] セクションには、複数のオプションがあります。 ARR に依存してルーティングを行うので、パフォーマンスが最適化されるように設計された「Performance HTTP」を選択できます。
- [既定のプール] では、手順 1 で作成したプールを選択します。
.jpg "Ee886283.shared hosting and ARR(ja-jp,TechNet.10).jpg")
シナリオ 2: ホスト名アフィニティを使用した共有ホスト
このシナリオでは、ARR のホスト名アフィニティ機能を使用して、共有ホスト展開を有効にします。これには次のメリットがあります。
- 従来の共有ホスト展開で必要とされていた手動による管理とメンテナンスを削減する。
- 既存のサーバー リソースを最大限に活用しながら、すべてのサーバー リソースが均等に使用されるようにする。
- 簡単に環境をスケールアウトできる。
- 追加の処理能力を売り込むためのビジネス機会を創出する。
共有ホストおよび ARR の詳細については、このドキュメントを参照してください。
ARR を使用した共有ホスト環境の図を以下に示します。
オプション 1: アクティブ/パッシブ
前述したように、アクティブ/パッシブ モードでは、一般的に ARR サーバーが 2 台あり、1 台のサーバーが要求を処理している間、もう 1 台のサーバーはフェールオーバー サーバーとしてスタンバイします。この構成では単一障害点を排除して高可用性を実現しますが、コンテンツ サーバーの総体的な容量は、単一の ARR サーバーの最大容量によって制限されるので、スケールアウトされたソリューションではありません。
この手順では、2 台の ARR サーバーが同じように構成されているため、共有構成が使用されています。F5 BIG-IP は、すべての要求を ARR アクティブ サーバーにルーティングし、必要な場合のみ、要求を ARR パッシブ サーバーにルーティングするように構成されています。
ARR のホスト名アフィニティ機能では、ホスト名に基づき、要求を特定のサーバー (RC 内のサーバー グループ) にアフィニティ化します。ホスト名とコンテンツ サーバー間のアフィニティ化されたマッピングのランタイム状態情報は、ARR サーバーのインスタンス内のメモリに保存されます。ARR Version 1 リリースでは、ARR は Microsoft External Cache for IIS 7.0 を活用し、このランタイム状態を複数の ARR サーバー間で共有して維持します。このシナリオの詳細については、このドキュメントを参照してください。
このシナリオは、ARR Version 1 リリースで完全にサポートされています。
ARR の構成
手順 1: 2 台の ARR サーバーで共有構成を有効にする
- このドキュメントの手順に従って、IIS 7.0 で共有構成をセットアップします。
手順 2: ARR を使用して、3 層展開アーキテクチャを構成する
このドキュメントの手順に従って、3 層展開アーキテクチャで ARR を構成します。
上記のドキュメントを簡単にまとめると、以下の方法について説明しています。
- ARR サーバーで静的コンテンツを使用できるようにする方法。
- ARR サーバーから直接処理されるように、静的コンテンツの URL 書き換え規則を作成する方法。
- アプリケーション サーバーに転送されるように、動的コンテンツの URL 書き換え規則を作成する方法。
手順 3: External Cache を有効にして構成する
- このドキュメントの手順に従って、ARR と組み合わせて使用する External Cache を有効にして構成します。
F5 BIG-IP の構成
このシナリオでは、2 台以上で構成される ARR サーバーのプールに負荷分散を行う仮想サーバーを作成します。 選択した負荷分散方法で、ARR プライマリ サーバーが稼働している間、このサーバーにすべてのトラフィックが送信されるようにします。 ARR プライマリ サーバーが使用できなくなった時点で、すべてのトラフィックが BIG-IP LTM から ARR セカンダリ サーバーに送信されるようにします。
手順 1: ARR サーバーのプールを構成する
- [ローカル トラフィック] セクションで、[プール] をクリックします。 次に、[作成] ボタンをクリックして、プールを作成します。
- 一意の名前であればどれでも、プールに使用できます。例では、「ARR_Pool」を使用します。
- [ヘルス モニタ] では、カスタムの HTTP モニターまたは既定の HTTP モニターを使用できます。
- [負荷分散方式] の設定は、「ラウンド ロビン」のままにすることができます。 このシナリオでは、ARR サーバーはアクティブとパッシブだけなので、負荷分散は使用しません。
- [優先度グループの有効化] が有効になっていることを確認します。 これにより、BIG-IP が優先順位の最も高い値を持つサーバー (場合によって複数) にトラフィックを送信するように構成されます。 サーバー (場合によって複数) を使用できない場合、BIG-IP は次に優先順位の最も高い値を持つ ARR サーバーにトラフィックを送信します。
- このシナリオでは、10.0.0.1 の ARR サーバーの優先順位の値は「1」で、10.0.0.2 の優先順位の値は「2」に設定されています。すべてのトラフィックは、10.0.0.2 の ARR サーバーが停止するまで、このアドレスに送信されます。サーバーの停止後、トラフィックは 10.0.0.1 に送信されます。
手順 2: 仮想サーバーを構成する
- [ローカル トラフィック] セクションで、[仮想サーバー] をクリックします。 次に、[作成] ボタンをクリックして、仮想サーバーを作成します。
- 一意の名前であれば任意の名前を仮想サーバーに使用できます。例では、「ARR_VS」を使用します。
- [リダイレクト先] では、ユーザーが使用するブラウザーをポイントする IP アドレスを使用できます。 この場合、使用します。 [サービス ポート] は、「80」を使用します。
- 仮想サーバーの [種類] セクションには、複数のオプションがあります。 ARR に依存してルーティングを行うので、パフォーマンスが最適化されるように設計された「Performance HTTP」を選択できます。
- [既定のプール] では、手順 1 で作成したプールを選択します。
- この時点で、この仮想サーバーに接続でき、適切な ARR サーバーに送信されます。
オプション 2: アクティブ/アクティブ (ARR)
アクティブ/アクティブ モードでは、2 台以上の ARR サーバーを使用できます。高可用性のみを実現するアクティブ/パッシブ モードとは異なり、この構成では、高い可用性とスケーラビリティの両方が実現します。
複数の ARR サーバーが同じように構成されているため、共有構成が使用されています。F5 BIG-IP は、使用できる正常な ARR サーバーすべてに対して受信要求の負荷分散を実行し、要求をコンテンツ サーバーに転送するように構成されています。
前述したように、ホスト名とコンテンツ サーバー間のアフィニティ化されたマッピングのランタイム状態情報は、ARR サーバーのインスタンス内のメモリに保存されます。複数の ARR サーバー間でこの情報を共有するために、Microsoft External Cache for IIS 7.0 が使用されます。External Cache の詳細については、このドキュメントを参照してください。
ARR の構成
アクティブ/アクティブの ARR の構成は、アクティブ/パッシブの場合と同じです。主な違いは、F5 の構成方法です。
手順 1: 2 台の ARR サーバーで共有構成を有効にする
- このドキュメントの手順に従って、IIS 7.0 で共有構成をセットアップします。
手順 2: ARR を使用して、3 層展開アーキテクチャを構成する
このドキュメントの手順に従って、3 層展開アーキテクチャで ARR を構成します。
上記のドキュメントを簡単にまとめると、以下の方法について説明しています。
- ARR サーバーで静的コンテンツを使用できるようにする方法。
- ARR サーバーから直接処理されるように、静的コンテンツの URL 書き換え規則を作成する方法。
- アプリケーション サーバーに転送されるように、動的コンテンツの URL 書き換え規則を作成する方法。
手順 3: External Cache を有効にして構成する
- このドキュメントの手順に従って、ARR と組み合わせて使用する External Cache を有効にして構成します。
F5 BIG-IP の構成
このシナリオでは、使用できる ARR サーバーはすべてアクティブであり、負荷分散されたトラフィックの送信先候補と見なされます。BIG-IP LTM を使用して、ARR フロント エンド サーバーの健常性とパフォーマンスを判断し、パフォーマンスが最も優れたサーバーにトラフィックを送信します。
手順 1: ARR サーバーのプールを構成する
- [ローカル トラフィック] セクションで、[プール] をクリックします。 次に、[作成] ボタンをクリックして、プールを作成します。
- 一意の名前であれば任意の名前をプールに使用できます。例では、「ARR_Pool」を使用します。
- [ヘルス モニタ] では、カスタムの HTTP モニターまたは既定の HTTP モニターを使用できます。
- トラフィックを分散する対象となる ARR サーバーが複数あるので、ニーズに最適な負荷分散方法を選択します。 前提として、ARR サーバーのハードウェア特性がすべて同じようなものであれば、動的な負荷分散方法 (最速モード、監視モード、予測モードなど) により、パフォーマンス ベースの分散が可能となります。
.jpg "Ee886283.510_fig1(ja-jp,TechNet.10).jpg")
手順 2: 仮想サーバーを構成する
- [ローカル トラフィック] セクションで、[仮想サーバー] をクリックします。 次に、[作成] ボタンをクリックして、仮想サーバーを作成します。
- 一意の名前であれば任意の名前を仮想サーバーに使用できます。例では、「ARR_VS」を使用します。
- [リダイレクト先] では、ユーザーが使用するブラウザーをポイントする IP アドレスを使用できます。 この場合、使用します。 [サービス ポート] は、「80」を使用します。
- 仮想サーバーの [種類] セクションには、複数のオプションがあります。 ARR に依存してルーティングを行うので、パフォーマンスが最適化されるように設計された「Performance HTTP」を選択できます。
- [既定のプール] では、手順 1 で作成したプールを選択します。
まとめ
このホワイトペーパーでは、主に 2 つの ARR シナリオについて検討し、複数の ARR サーバーを展開して、F5 BIG-IP を使用することにより、高い可用性とスケーラビリティを実現しました。
付録
付録 A: ルーティングの決定の規則作成に使用可能な HTTP ヘッダーとサーバー変数の全一覧
| ALL_HTTP | ALL_RAW | APPL_MD_PATH |
| APPL_PHYSICAL_PATH | CERT_COOKIE | CERT_FLAGS |
| CERT_ISSUER | CERT_KEYSIZE | CERT_SECRETKEYSIZE |
| CERT_SERIALNUMBER | CERT_SERVER_ISSUER | CERT_SERVER_SUBJECT |
| CERT_SUBJECT | CONTENT_LENGTH | CONTENT_TYPE |
| DOCUMENT_ROOT | GATEWAY_INTERFACE | HTTP_ACCEPT |
| HTTP_ACCEPT_ENCODING | HTTP_ACCEPT_LANGUAGE | HTTP_CONNECTION |
| HTTP_CONTENT_LENGTH | HTTP_HOST | HTTP_IF_MODIFIED_SINCE |
| HTTP_IF_NONE_MATCH | HTTP_REFERER | HTTP_UA_CPU |
| HTTP_USER_AGENT | HTTPS | HTTPS_KEYSIZE |
| HTTPS_SECRETKEYSIZE | HTTPS_SERVER_ISSUER | HTTPS_SERVER_SUBJECT |
| INSTANCE_ID | INSTANCE_META_PATH | LOCAL_ADDR |
| PATH_INFO | PATH_TRANSLATED | QUERY_STRING |
| REMOTE_ADDR | REMOTE_HOST | REMOTE_PORT |
| REMOTE_USER | REQUEST_FILENAME | REQUEST_METHOD |
| REQUEST_URI | SCRIPT_FILENAME | SCRIPT_NAME |
| SERVER_ADDR | SERVER_NAME | SERVER_PORT |
| SERVER_PORT_SECURE | SERVER_PROTOCOL | SERVER_SOFTWARE |
| URL |