この構成は、ロード バランサーが常にすべてのサイトに負荷を分散するよう構成される、単一コンピューターの高可用性配置 (アクティブ/パッシブ)のバリエーションです。この構成ではスタンバイ サイトは存在しません。
このアーキテクチャでは、ArcGIS Server の配置の容量を増やすために、2 つ以上のサイトがサードパーティ製ロード バランサーの内側に構成されます。この手法は、「単一コンピューターの配置」および「リバース プロキシ サーバーを使用した単一コンピューターの配置」で述べたいくつかの高可用性の制限に対応するため、またはコンピューターを追加してスケール アップするために使用できます。
複数コンピューターによるサイトを使用することでスケール アップし、高可用性を実現できますが、アクティブ/アクティブの配置にはメリットと制限事項があります。以下ではこれらのメリットと制限事項について説明します。
概説すると、単一コンピューターのアクティブ/アクティブ アーキテクチャの概念は、単一コンピューターのサイトのクローンを作成して、そのサイトのインスタンスをロード バランサーの内側に独立して配置するというものです。この構成は技術的には複数コンピューターのサイトと呼ぶことはできません。その理由は、それぞれのサイトが互いに独立し、1 台の GIS サーバーから構成され、独自の構成ストアとサーバー ディレクトリを備えているからです。
複数コンピューターの ArcGIS Server サイト配置では、サーバーの管理を大幅に簡素化できます。しかし、サービスの数と設定が明確に定義され、静的なままであるシナリオでは、アクティブ/アクティブ アーキテクチャを使用することで、複数コンピューターのサイトを大きく凌ぐパフォーマンス上のメリットを得ることができます。これは、特にキャッシュ マップ サービスの場合に当てはまります。
GIS サーバー、サーバー ディレクトリ、および構成ストア
各 GIS サーバーには、独自のローカル構成ストアとキャッシュ、ジョブ、およびシステム ディレクトリが存在する必要があります。これにより、最大限のパフォーマンスが保証され、相互依存性を最小限に維持できます。反対に出力ディレクトリは、各サイト間で共有される必要があります。詳細については、下の「その他の考慮事項」をご参照ください。
データ
この場合、「単一コンピューターの高可用性配置 (アクティブ/パッシブ)」に記載されたものと同じ考慮事項が適用されます。
リバース プロキシ サーバー
この構成では、サードパーティ製のロード バランサーが必要です。少なくとも、このコンポーネントを使用して、すべてのサイト間に負荷を分散します。ロード バランサーは、ラウンド ロビンや最小接続数など、負荷を分散するためのさまざまな構成を備えています。適切な負荷分散方式は、ホストされているサービスとそれらのサービスの使用状況によって異なります。通常、ロード バランサーは、さまざまなオプションも利用して障害に対処します。たとえば、ハードウェアまたはネットワークの障害のため使用不可になっているコンピューターや、利用できない特定の ArcGIS Server サービスにリクエストを転送しないようにするルールをロード バランサーに適用できます。この配置状況で提案されている単一コンピューターのサイトを使用する場合、特定のコンピューターに送信されたリクエストはそのコンピューターで処理されることが保証されます。
通常、ロード バランサー自体が、リバース プロキシ サーバーの役割も果たします (「リバース プロキシ サーバーを使用した単一コンピューターの配置」を参照)。場合によっては、すでにリバース プロキシ サーバーをロード バランサーから独立して構成している場合もあります。
ネットワーク ロード バランサーが状態チェック機能に対応している場合は、ArcGIS Server の状態チェック エンドポイントを使用して、サイトがリクエストを受け取れるかどうかを確認できます。これは、サイトでソフトウェアまたはハードウェアの障害があるかどうかを迅速に確認する場合に便利です。詳細については、ArcGIS REST API の「状態チェック」をご参照ください。
ArcGIS Web Adaptor の使用はオプションであり、通常、このシナリオで Web 層認証を利用したい場合にのみ必要になります。ArcGIS Web Adaptor は、GIS サーバーと同じコンピューターに構成することも、あるいは、専用のコンピューターに構成することもできます。いずれの場合も、ArcGIS Web Adaptor を使用する場合は、サイトごとに個別の ArcGIS Web Adaptor を構成する必要があります。
その他の考慮事項
サイトでのサービスの同期状態の維持
実際の複数コンピューターのサイトとは異なり、この構成では、ロード バランサーの内側にあるすべてのサイトがまったく同じコンテンツをホストし、同じセキュリティ モデルに従う必要があります。管理者は、ロード バランサーから見て、すべてのサイトがまったく同じになるようにする必要があります。
プライマリ サイトとフェイルオーバー サイト間で ArcGIS Server サービスの同期を維持するために役立つ方法がいくつかあります。
- スクリプト: ArcGIS Server は、管理タスク (サービスの公開やサービスのセキュリティ設定の変更など) のスクリプトの作成に使用できる REST ベースの管理用 API を備えています。ユーザーは独自のスクリプトを作成して、配置に関係するすべての GIS サーバーに一貫して変更を適用することができます。 スクリプトは、サービスのセキュリティの変更や上書きなど、微調整を行う必要がある場合に特に便利です。詳細については、「ArcGIS Server 管理のスクリプト」をご参照ください。
- 仮想化: 仮想環境で操作を行う場合、仮想コンピューターのテンプレートを作成および使用して、新しいサイトを立ち上げることができます。各テンプレートには、GIS サービスで必要なデータのコピーが含まれます (データベースが使用されている場合を除く)。また、テンプレートには、公開および構成されているすべてのサービスも含まれます。既存のサービスの追加や更新などの変更が必要な場合、新しいテンプレートを作成し、後で新しい仮想コンピューターを起動して、ロード バランサーの下で使用されている既存の GIS サーバー コンピューターのプールをこれらの新しいコンピューターで置き換えることができます。仮想コンピューターのテンプレートは、古くなった GIS サーバーを迅速に復元するためにも使用できます。
この配置パターンで変更をサイトに適用する場合に推奨される手順は以下のとおりです。
- 管理上の変更は、まず、スタンバイ モードにあるサイトに対して行います。たとえば、アクティブにリクエストを処理していないサイトで新しいサービスを追加し、別のサービスのセキュリティを変更します。これにより、プライマリ サイトを使用しているアプリケーションには何も影響がないことが保証されます。
- 変更を行ったスタンバイ サイトにすべてのリクエストを渡すようロード バランサーを手動で構成します。
- アイドル状態のサイトに同じ変更を適用します。
- リクエストが元のプライマリ サイトに送られるようにロード バランサーの構成を元に戻して、スタンバイ サイトをスタンバイ モードのままにします。
上記の手順でサイトに対して行った変更は、ArcGIS Server Manager、スクリプト、または仮想イメージを使用して手動で適用できます。
出力ディレクトリの共有
一部の ArcGIS Server サービスの操作では、1 つ以上の出力ディレクトリ内のリソースを参照します。たとえばマップ サービスは、画像を出力ディレクトリに書き込み、それらの画像をリクエストのレスポンスで URL を介して参照する場合があります。クライアントがその画像を正常に取得するには、アクティブ/アクティブ構成内のすべてのサイトが同じ出力ディレクトリを参照する必要があります。これを実現するには、出力ディレクトリをネットワーク リソース上に配置し、それらを各サイトで共有します。
出力ディレクトリを使用するサービスの操作を以下に示します。
- フィーチャ サービスのレプリカの作成(フィーチャ サービス)
- ラスター画像のダウンロード(イメージ サービス)
- モバイル サービスとモバイル レイヤーのリソースの取得 (マップ サービスのモバイル機能)
- マップ画像のエクスポート(マップ サービス)
- スケマティック ダイアグラムのエクスポート(マップ サービスのスケマティック機能)
- Web マップのエクスポート(ジオプロセシング サービス)
ジオプロセシング サービスの非同期実行
ArcGIS Server ジオプロセシング サービスは、同期実行モードと非同期実行モードをサポートしています。同期実行は、ステートレスなリクエスト/レスポンス パターンに従い、アクティブ/アクティブ構成で完全にサポートされています。非同期実行は、ステートフルなリクエスト/レスポンス パターンに従います (これがデフォルトです)。アクティブ/アクティブ構成で非同期実行を使用するには、以下を考慮する必要があります。
- 非同期ジオプロセシング ジョブを送信すると、送信されたジョブとその出力を参照するジョブ ID が返されます。元のリクエストを受信した ArcGIS Server サイトのみが、この ID を認識できます。そのため、アクティブ/アクティブ構成で非同期実行を使用する場合、ロード バランサーでアフィニティ (固定的なセッションとも呼ばれる) を定義する必要があります。これにより、非同期のジオプロセシング サービスおよびマップ サービスの出力に高可用性が提供されます。ロード バランサーのベンダーに問い合わせて、固定的なセッションを有効化することによる影響を把握してください。
- ジオプロセシング サービスが出力をレンダリングするためにマップ サービスを使用せず、「ファイル」タイプの出力が定義されていない場合は、ジオプロセシング サービスで同期実行を選択することができます。ロード バランサーでの固定的なセッションは必要ありません。
トークンベースのセキュリティの使用
トークンベースの認証 (GIS 層認証とも呼ばれる) を使用している場合、この構成内のすべてのサイトがまったく同じ共有トークン鍵を使用することが重要です。それ以外の場合、一方のコンピューター向けに生成されたトークンは、他方のコンピューターに対して使用されるときに有効になりません。複数のサイト間で共有トークン鍵を複製する方法については、「ArcGIS トークンについて」と「ArcGIS Server Manager でのトークン設定の編集」をご参照ください。
メリット
- 概念的にわかりやすい構成になっています。GIS サーバー間の相互依存性が最小限に抑えられているため、古くなったか、故障したコンピューターの取り替え、アップグレードの適用、GIS サーバーのプールからのコンピューターの削除を、サービスを中断したり、リクエストを中止したりすることなく必要に応じて簡単に実施することができます。
- マップ タイルがコンピューターごとにローカルに保存されている場合、この構成を使用すると、複数コンピューターのサイトと比べてパフォーマンス上の大きなメリットが得られます。キャッシュ マップ サービスの容量を増やすことがユーザーの目的である場合は、この構成が最も適しています。
デメリット
- すべてのサイトを同期状態に維持する必要があります。これにより、管理上のオーバーヘッドが増加するため、変更頻度が高い多数のコンピューターまたはサービス/キャッシュが存在する場合にはこの配置パターンが実用的ではないことがあります。
- サードパーティ製ロード バランサーに関する知識が必要です。