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