ArcGIS Server は、複数コンピューターのサイトの構成をサポートしています。複数コンピューターのサイトでは、2 台以上の GIS サーバーを 1 つの論理単位として管理および使用できるため、GIS サーバーを追加/削除することでサイトの処理能力を簡単に調整できる高い柔軟性が ArcGIS Server 管理者にもたらされます。また、複数コンピューターのサイトでは、複数台の GIS サーバーにわたるサービスの公開および更新プロセスを簡素化できます。
複数コンピューターの配置でサイトを正常に機能させるには、各 GIS サーバーのバージョン番号を同じにする必要があります。さらに、サイトに参加する各 GIS サーバーにも同じライセンスを適用する必要があります。
一般的な複数コンピューター構成では、GIS サーバーのプールの前にサード パーティ製リバース プロキシ サーバーまたはネットワーク ロード バランサーを配置する必要があります。
複数コンピューター構成の主な特徴として、すべての GIS サーバーは同じ構成ストアとサーバー ディレクトリを共有します。この方式では、管理者は ArcGIS Server Manager を使用して任意の GIS サーバーにログインし、サイト内のすべてのコンピューターに影響を及ぼす変更を適用することができます。
GIS サーバー、サーバー ディレクトリ、および構成ストア
複数コンピューター構成に含まれるすべての GIS サーバーは同じ構成ストアとサーバー ディレクトリを共有するため、構成ストアとサーバー ディレクトリ用のネットワーク上の場所を選択する必要があります。
通常は、ドメイン アカウントが ArcGIS Server アカウントとして選択されます。この理由は、ネットワーク リソースへのデータ アクセス権限の管理が簡素化されるからです。ただし、ユーザー独自のセキュリティ ポリシーによっては、ローカル アカウントを使用することもできます。ArcGIS Server アカウント (ローカルまたはドメイン) は、構成ストアとサーバー ディレクトリが配置されているネットワーク共有への書き込みアクセス権限を備えている必要があります。詳細については、「ArcGIS Server で使用するアカウント」をご参照ください。
複数コンピューターのサイトでは、すべての GIS サーバー コンピューターは最初、ポート 4004 以上を使用する単一クラスターに属します。10.4 の ArcGIS for Server は、新規のインストールにおいて、デフォルトで単一クラスター モードに設定されます。このモードには、クラスター内にあるコンピューター間の負荷分散機能は含まれていません。これにより、サイト内のコンピューター間のネットワーク トラフィックが減少し、ネットワーク上の負荷が軽減されて、サイト内の GIS サーバーの監視が改善されます。10.4 にアップグレードすると、現在単一クラスター モードを使用していない単一クラスターを使用して、このモードがサイトで有効化されます。すでに単一クラスター モードを使用している単一クラスター サイトと、以前のリリースのクラスターが複数あるサイトは、アップグレード時に設定が維持されます。
サイトが複数のクラスターを使用している場合、各クラスター内のすべての GIS サーバー間で負荷分散に対処します。基本的に、クラスターは、専用のサービス セットを実行する GIS サーバーの独立したグループです。
たとえば、受信リクエストがクラスター内外の特定のコンピューターに対する要求であっても、そのリクエストはクラスター内で利用可能な GIS サーバーに割り当てられます。リクエストを割り当てられた GIS サーバーは、マップの描画、住所座標の検索、ジオプロセシング ツールの実行などを行い、処理結果をクライアントに返します。コンピューターがオフラインの場合や、要求されたサービスが別のクラスター内で実行されている場合、リクエストはそのサービスを含むクラスターに転送されます。そのクラスター内にある GIS サーバー コンピューターは、それに応じてリクエストを負荷分散および処理します。
データ
他の配置シナリオでも述べているように、ファイルベースのデータを使用するときは、GIS サーバーのローカル リソースを使用することを強くお勧めします。これには、すべての GIS サーバー間でデータを複製しなければならないというデメリットがありますが、ネットワーク トラフィックが軽減され、結果としてサービスのパフォーマンスが向上します。該当する場合は、このオプションを検討して使用する必要があります。すべてのコンピューターでデータをローカルに保存することが現実的なアプローチであるかどうかは、多くの場合、データのサイズと更新の頻度によって決まります。
この配置状況でデータベースを使用する場合は、常に専用のハードウェアを使用することが重要です。データベース層を GIS サーバー層から独立させておいてください。
サード パーティ製リバース プロキシ サーバーまたはネットワーク ロード バランサー
この構成では、ArcGIS Server クライアントが直接 GIS サーバーに接続することはありません。代わりに、ArcGIS Server クライアントは、セキュリティ機能を備え、サイト全体の耐障害性を高める中間層を介して接続します。
セキュリティの観点から、サイトの使用と管理のために同じチャンネルにアクセスすることは推奨されません。一般的に、管理タスクは、ポート 6080 や 6443 などを介して GIS サーバーに直接アクセスできるネットワークのセクションまたは特定のコンピューターのみを通して有効になります。このような制限を解決するには、特定の IP アドレスのみが Administrator Directory のサーバーにアクセスできるように指定します。この設定は、サーバーのセキュリティ構成の allowedAdminAccessIPs プロパティで制御されます。サーバーへのアクセスを制限するためのこのプロパティの構成方法については、「セキュリティ構成の更新」の例をご参照ください。
クライアント アプリケーションからのリクエストは、常にリバース プロキシを経由するため、管理エンド ポイントは一切使用されません。大部分のサード パーティ製プロキシでは、特定の URL パターンを含む受信リクエストをフィルタリングできるようになっています。ArcGIS Server Administrator Directory (http://gisserver.domain.com:6080/arcgis/admin) または ArcGIS Server Manager (http://gisserver.domain.com:6080/arcgis/manager) にあるリソースを使用する受信リクエストをブロックすると、リバース プロキシを経由するすべての管理タスクを効果的にブロックできます。
リバース プロキシは、サイトのロード バランサーとしても機能します。この構成には、ラウンドロビン方式などの単純な負荷分散アルゴリズムが適しています。
ネットワーク ロード バランサーが状態チェック機能に対応している場合は、ArcGIS Server の状態チェック エンドポイントを使用して、サイトがリクエストを受け取れるかどうかを確認できます。これは、サイトでソフトウェアまたはハードウェアの障害があるかどうかを迅速に確認する場合に便利です。詳細については、ArcGIS REST API の「状態チェック」をご参照ください。
リバース プロキシ サーバーを ArcGIS Server と統合する方法については、「ArcGIS Server でのリバース プロキシ サーバーの使用」をご参照ください。
メリット
- 単一の ArcGIS Server サイトで、多数のコンピューターの ArcGIS Server とそのサービスを簡単に管理することができます。
- GIS サーバー コンピューターの追加および削除によって、サイトの容量を容易に調整できます。
- GIS サーバー間で負荷分散に対処します。
デメリット
- 共有されたネットワークの場所で ArcGIS Server ディレクトリとデータを使用すると、負荷が高い場合にサービスのパフォーマンスに悪影響を及ぼす可能性があります。
- サード パーティ製ロード バランサーについて理解する必要があります。
- Web 層認証をサポートしていません。Web 層認証を利用するには、「ArcGIS Web Adaptor を使用した複数コンピューターの配置」をご参照ください。