Skip To Content

複数クラスター サイトのアップグレード

レガシー:

このトピックでは、廃止された機能を説明します。

10.7 より前のバージョンでは、ArcGIS Server 管理者は ArcGIS Server サイト内でサーバー クラスターを構成することができました。クラスターは、そのクラスターに割り当てられたサービスをサイト内の他のクラスターから分離していました。サイトに複数クラスターを構成する機能は 10.7 で削除されました。

10.7.1 にアップグレードする前に、既存のサイトが 1 つのクラスターで構成されているか (サイトが 10.4 以降の場合に考えられる状況)、複数のクラスターで構成されているかを把握しておく必要があります。ArcGIS Server サイトが 1 つのクラスター (デフォルト) で構成されている場合、何も処置を取る必要はありません。サイトのコンピューターは引き続きすべてのサービスを実行します。

複数のクラスターで構成された ArcGIS Server サイトを 10.7.1 にアップグレードすると、アップグレード プロセスで自動的にサイトに重要な変更がいくつか加えられるため、ユーザー側でそれに応じた処置が必要となります。

複数クラスター サイトについて

ArcGIS Server 10.1 では、サーバー サイトとともにサーバー クラスターが導入されました。クラスターは単一サイトのサブエレメントです。各クラスターは特定のサービス タイプのサービスをホストしたり、特定サイズのリクエストを処理したりできるよう、特別に構成されています。

組織は単一の ArcGIS Web Adaptor を使用してアクセスする単一の ArcGIS Server サイト内に、画像サービスを処理するクラスター、ジオプロセシング サービスを処理するクラスターなどを含めることができました。

複数クラスター サイトにパフォーマンス上の問題があるために、10.4 以降の ArcGIS Server を単一クラスター モードで使用することを推奨していました。

複数のクラスターが存在しない ArcGIS Server サイトでは、サイト内のどのコンピューターでも任意のリクエストを受け取ることができます。ArcGIS Server コンピューター間で負荷分散は行われません。代わりに、ArcGIS Server サイトに構成された Web Adaptor またはサードパーティ製のロード バランサーによって負荷分散が行われます。サービスは、公開および管理操作のパフォーマンス向上のために 10.6 で導入された、最適化された内部アプリケーション サーバーによって管理されます。

複数クラスター サイトのアップグレード動作

サイトが 1 つのクラスターで構成されているか複数のクラスターで構成されているかに関係なく、セットアップ プログラムまたはコマンド ライン ユーティリティのいずれかを使用してサイトをアップグレードできます。

アップグレード プロセスの実行中に、ArcGIS Server のアップグレード ツールは、既存のサイトが複数のクラスターで構成されているかどうかのチェックを行います。複数のクラスターで構成されている場合、このツールは、ユーザーが公開したサービスをすべて停止します。次に、すべてのコンピューターとサービスを、デフォルトと呼ばれる 1 つのクラスターに移動させます。アップグレード ツールは、デフォルト クラスターがすでに存在する場合には、そのクラスターを使用し、存在しない場合には、新しいデフォルト クラスターを作成します。

アップグレードが完了すると、そのサイトが複数クラスター サイトではなくなり、そのサイト内の各コンピューターですべてのサービスが実行されます。これはコンピューターのメモリと処理能力に多大な負担をかける場合があります。このため、ユーザーが公開したすべてのサービスがアップグレードの前に自動的に停止します。これにより、公開したサービスを確認し、これらのサービスをサイト内に保持するか、永続的に削除するか、別の ArcGIS Server サイトに再公開するかを選択する機会が与えられます。停止したすべてのサービスは、手動で再起動または削除するまで、停止したままの状態になります。

クラスター アーキテクチャの代替手法

ArcGIS Server 10.7.1 の管理者として、以前のクラスターの場合と同様に、種類やサイズによってサイトを分離することができます。

たとえば、複数の ArcGIS Server サイトを設定できます。このオプションは、サイト内の各コンピューターで実行する必要がある ArcSOC.exe インスタンスの数が増えるため、多数のサービスを展開し、そのほとんどまたはすべてのサービスが定期的に利用されている場合に特に有効です。

一方、各サービスが受信するトラフィック レベルが大きく異なる場合があります。たとえば、1 つのサービスが複数の同時リクエストを常に処理し、他のサービスがリクエストを受信する頻度が低いような場合です。ここでは、10.7 で導入された共有インスタンス プールを使用して、低頻度のリクエストに対するメモリ使用量を節約しながら、高トラフィックのサービスに共有プールから分離された専用のインスタンス プールを割り当てます。共有インスタンス プールを使用すると、サイトのパフォーマンスが低下したり運用コストが高くなることなく、サイト上で低トラフィックのサービスを大量に実行できます。

共有インスタンスの詳細

サイトのアーキテクチャがハードウェア リソースに多大な負担をかけず、ユーザーに最適なパフォーマンスを提供すると確信できる場合は、すでに停止している公開済みサービスを再起動します。