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