切断中のスタンバイデプロイメントに ArcGIS Enterprise デプロイメントを複製できます。 プライマリデプロイメントに障害が発生したり、アクセス不能になったりした場合は、スタンバイデプロイメントにフェイルオーバーすることができます。
スタンバイデプロイメントは、通常は別のネットワークかサブネットワーク上で動作します。場合によっては、プライマリデプロイメントとはまったく別の地域にあることもあります。 スタンバイデプロイメントを使用する場合は、ArcGIS Enterprise クライアントが、必要なときにスタンバイデプロイメントにアクセスできることを確認してください。
地理的な冗長性
プライマリ データ センターとスタンバイ データ センターが地理的に離れた場所にあれば、地理的な冗長性を持たせることができます。 いずれかのデータ センターにハリケーンなどの自然災害が発生した場合でも、スタンバイ データ センターをアクティブにし、運用を再開できます。
地理的な冗長性を正常に行うには、次の特定の要件を満たす必要があります。
- プライマリ環境とスタンバイ環境は同一にする必要があります。 各データ センターの ArcGIS Enterprise デプロイメント内のコンピューターの数は同じでなければなりません。また、これらのコンポーネントへのアクセスに使用されている URL も同じでなければなりません。
- ArcGIS Server ディレクトリの名前は同じでなければなりません。 ディレクトリへのパスは異なる可能性がありますが、プライマリ環境とスタンバイ環境ではフォルダー名を同じにする必要があります。
- プライマリ環境とスタンバイ環境の ArcGIS Server サイトに登録されたフォルダーは異なるパスを持つ可能性がありますが、フォルダー名は同じにする必要があり、同じソース データの正確なコピーを含む必要があります。
- 地理的な冗長性は、一般にアクティブ/パッシブ アプローチを採用しているので、スタンバイ ArcGIS Enterprise デプロイメントに複製するデータとコンテンツには整合性を持たせる必要があります。
- 地理的な冗長性を成功させるには、サードパーティのコンポーネントを利用します。 たとえば、プライマリ データ センターからスタンバイに切り替えるときに、ArcGIS Enterprise ユーザーの操作が中断されないようにするには、グローバル サイト セレクターまたはグローバル ドメイン名システム (DNS) サーバーが重要です。
障害や自然災害の発生時にダウンタイムを最小限に抑えるために、可用性の高い、地理的に冗長性を持つ ArcGIS Enterprise をデプロイすることができます。 これは、必要となるコンピューター数が多くメンテナンスも煩雑なので、非常に複雑なデプロイメントです。 2 つの個別のデータ センターを構成し、そのそれぞれに可用性の高い ArcGIS Enterprise デプロイメントを実装します。 各データ センターで、すべてのコンピューターを同じように名前を付け、単一障害点をなくします。可用性の高いファイル サーバーやデータベースに存在するかどうかにかかわらず、データ、すべての Web サーバーとロード バランサー、および ArcGIS Enterprise コンポーネントが含まれます。 プライマリデプロイメントのバックアップは常に作成され、別のデータ センターにあるスタンバイデプロイメントへの復元は、即座に実行されるか、またはプライマリデプロイメントに障害が発生したときに実行されます。
複製したデプロイメントの計画
まず、必要なコンピューター数を決定します。 次に、複製した ArcGIS Enterprise デプロイメントに対して、次の障害復旧要件を計画します。
- [重複]: 両方のデータ センターと ArcGIS Enterprise デプロイメントに同じアーキテクチャが含まれることを確認します。
- 複製: プライマリ データ センターのコンテンツとデータをバックアップし、スタンバイに復元します。
- 監視: 障害がいつ発生したかログで確認し、スタンバイ データ センターへのフェイルオーバーが必要なほど深刻な障害であるかどうかを判断します。
- [フェイルオーバー]: ArcGIS Enterprise 内の別のコンポーネントにフェイルオーバーするか、あるいは ArcGIS Enterprise デプロイメント全体を別のデータ センターにフェイルオーバーするかを決定します。
デプロイメントの複製を計画する際は、次の点にも注意してください。
- webgisdr ユーティリティを使用しても、マップ サービスのキャッシュ タイルは移動しません。 GIS Server サイトで使用中のマップ サービスまたはホスト タイル レイヤーのキャッシュがデプロイメントに含まれている場合、キャッシュ タイルが格納されているすべてのディレクトリ (たとえば、C:\arcgisserver\directories\ または <ArcGIS Server installation directory>/arcgis/server/usr/directories の下の arcgiscache ディレクトリ全体) のバックアップを作成します。 対応するスタンバイデプロイメントの arcgiscache ディレクトリにコピーを手動でデプロイします。
- webgisdr ユーティリティを使用して切断中のスタンバイデプロイメントに ArcGIS Enterprise を複製する場合、複数の ArcGIS Server クラスターはサポートされていません。
- 両方のデプロイメント内にあるすべてのコンピューターは、同一のオペレーティング システムを使用する必要があります。 たとえば、プライマリデプロイメントを Windows コンピューター、スタンバイデプロイメントを Linux にすることはできません。
- webgisdr ユーティリティには、バックアップ ファイルの作成時の ArcGIS Enterprise コンポーネントのソフトウェア バージョンが記録されます。 ファイルのインポート先となるスタンバイデプロイメントは、プライマリデプロイメントと同じバージョンでなければなりません。
コンピューターの要件の決定
必要となるコンピューターの数は、ArcGIS Enterprise の構成によって異なります。 少なくとも 2 台のコンピューターが必要です。 ArcGIS Enterprise デプロイメントに保存されているデータとサービスの数がそれほど多くなく、時空間ビッグ データ ストアとグラフ ストアが含まれておらず、アクセスする人も多くない場合は、単一コンピューターの GIS Server サイトでプライマリデプロイメントを構成し、同じコンピューターに Portal for ArcGIS と ArcGIS Data Store をインストールすることができます。 複製したスタンバイデプロイメントを保存するには、2 台目のコンピューターが必要です。
ArcGIS Enterprise デプロイメントの使用頻度が多い場合 (たとえば、アクセスするユーザー数が多い、組織において多数のアイテムが保存されている、デプロイメントが頻繁に修正されているなど) は、単一コンピューターまたは複数コンピューターの GIS Server サイトが必要になる場合があります。その場合は、Portal for ArcGIS と ArcGIS Data Store をそれぞれ別々に GIS Server 以外のコンピューターにインストールしてください。 複数のホスト シーン レイヤーを公開する場合は、別のコンピューターにシーン キャッシュ データベースを保存するよう ArcGIS Data Store (タイル キャッシュ データ ストア) を構成することをお勧めします。 グラフ ストアを使用する場合はコンピューターがもう 1 台必要となります。 時空間ビッグ データ ストアを使用する場合は、少なくともコンピューターがもう 1 台必要となります。 この場合は、次の公式に従って、必要なコンピューター数を計算します。
(<number of GIS Server machines> + 1 Portal for ArcGIS machine + <number of machines in the data store>) X 2
なお、スタンバイ デプロイメントは常時アクセスされないため、ArcGIS ライセンスを追加する必要はありません。プライマリに障害が発生した場合にのみ、アクティブなデプロイメントにします。
重複のデプロイメントに必要な設定
複製した ArcGIS Enterprise デプロイメントで効果的な障害復旧を確実に行うには、プライマリ デプロイメントにあるシステム設定、セキュリティ構成、ストレージ場所の範囲をスタンバイ デプロイメントで重複する必要があります。 定期的にバックアップを作成し、複製されたデプロイメント間の整合性を確保することは、障害発生時のダウンタイムを最小化するための最善策です。 デプロイメント全体で以下の点に注意する必要があります。 次に例を示します。
- マップ サービスは共有フォルダーのデータか、データベース接続を介したデータに依存します。
- ユーザーがポータルへのアクセスに使用するパブリック URL と、フェデレーション サーバーに使用されるサービス URL。
ヒント:
ホスト名の整合性を確保するために、DNS エントリを使用するか、複製したデプロイメントのコンピューター上の hosts ファイルを変更します。 このためには、パブリック ポータル URL として機能する別のコンピューターをセットアップすることをお勧めします。 このコンピューターに ArcGIS Web Adaptor またはリバース プロキシ サーバーをインストールし、ポータルおよびサーバー コンピューター上で hosts ファイルを変更できます。
- ユーザー負荷に対応するパフォーマンス問題を避けるために、データ センターのコンピューター数を一致させる必要があります。
次のシステム設定とセキュリティ設定は、各デプロイメントに固有で同じでない可能性があるため、webgisdr のインポートを実行する前に、各デプロイメントで設定する必要があります。
- サーバー名を含むフォワード プロキシ情報。
- ポータルに使用される privatePortalURL と、フェデレーション サーバーに使用される管理 URL。
- ポータルのプロキシ機能によって承認されたアドレスのリストを含むセキュリティ設定。
- ユーザー ストアおよびグループ ストアのアイデンティティ ストアの構成情報 (適用される場合)。
- SAML および LDAP ID プロバイダーの設定。
10.4 以降では、webgisdr ユーティリティを実行するときに、ソースとターゲットのデプロイメント全体で同一である必要があるアイテムと設定のリストが短くなりました。 最新バージョンの Portal for ArcGIS と ArcGIS Server における変更の概要を以下の表に示します。
webgisdr ユーティリティを実行するとき、デプロイメント全体でこのアイテムまたは設定は同一である必要がありますか？
| アイテムまたは設定 | 10.4.x | 10.5.x、10.6 | 10.6.1 以降 |
|---|---|---|---|
パブリック ポータル URL | はい | はい | はい |
フェデレーション サーバーのサービス URL | はい | はい | はい |
ArcGIS Data Store 以外の登録済みデータ ストア | はい | はい | はい |
...webgisdr.properties ファイルのアカウント資格情報 | はい | はい | はい |
ArcGIS Server のディレクトリ パス (例: arcgisjobs) | はい | はい | No |
セキュリティ情報 (LDAP URL、プロキシ情報) | はい | はい | No |
デプロイメントタイプ (単一コンピューターまたは高可用性) | はい | No | No |
プライベート ポータル URL | はい | No | No |
フェデレーション サーバーの管理 URL | はい | No | No |
コンピューター名 | はい | No | No |
ポータル コンテンツ ディレクトリのストレージ タイプ | はい | はい | はい |
ポータル コンテンツ ディレクトリのパス (ファイル システムを使用する場合) | No | No | No |
ポータル コンテンツ ディレクトリの認証情報 (クラウド ストレージを使用する場合) | No | No | No |
ArcGIS Server の構成ストア | No | No | No |
ArcGIS Enterprise の複製
webgisdr ユーティリティを使用すると、ポータル コンテンツ、フェデレーション ArcGIS Server サイト、ArcGIS Data Store コンテンツ (リレーショナル データ ストアとタイル キャッシュ データ ストア) をファイルにエクスポートして、復元のためにスタンバイ コンピューターに移動させることができます。 このユーティリティは、Portal for ArcGIS、ArcGIS Server、ArcGIS Data Store で構成された設定を保持し、ポータルで作成されたすべてのコンテンツに加え、公開中にホスティング サーバーやデータ ストアにコピーされたデータのコピーも作成します。
このユーティリティは、ホスティング サーバー サイトまたはフェデレーション ArcGIS Server サイトに登録されたデータベースまたはフォルダーからデータをコピーしません。 データをスタンバイの ArcGIS Enterprise デプロイメントに複製し、スタンバイ コンピューター上のサービスが複製されたデータにアクセスできるようにするかどうかは、管理者が判断します。
データ ソースを ArcGIS Server サイトに登録する場合は、データにアクセスする方法に関する具体的な情報を提供します。 この情報は、スタンバイデプロイメントとプライマリデプロイメントの両方で同じでなければなりません。 たとえば、ソース データとして使用しているファイル ジオデータベースをスタンバイデプロイメントにコピーする場合は、そのファイル ジオデータベースへのディレクトリ パスをプライマリデプロイメントと同じにする必要があります。 また、データベースをプライマリデプロイメントの ArcGIS Server サイトに登録した際に提供した接続情報と同じ情報を使用して、スタンバイデプロイメントから、そのデータベースへのアクセスが可能でなければなりません。
Linux 環境内の cron ジョブとして webgisdr ユーティリティを実行できます。 また、ユーティリティが実行されているコンピューターと ArcGIS Enterprise コンポーネントとの間で通信が行われていれば、ポータルがインストールされているコンピューターとは別のコンピューターにユーティリティを移動し、そこから実行することも可能です。
ArcGIS Enterprise バックアップがプライマリデプロイメントからエクスポートされた直後に、スタンバイデプロイメントに復元する必要があります。 そうすると、増分バックアップが誤った順序で復元されることを回避できます。また、プライマリデプロイメントに障害が発生しても、データの損失やダウンタイムを最小限に抑えることができます。 バックアップを即座に復元しなかった場合、バックアップをインポートしたり、スタンバイデプロイメントにフェイルオーバーしたりする際にオーバーヘッドが余分に生じることがあります。
また、バックアップ作成時にプライマリデプロイメントに何らかの誤りがあり、バックアップをスタンバイにインポートするプロセスが自動化されている場合、こうした設定ミスがスタンバイデプロイメントにインポートされることも考慮に入れる必要があります。
ArcGIS Enterprise デプロイメントの複製については、「障害復旧の構成」をご参照ください。
ArcGIS Enterprise の監視
複製された環境でも可用性の高い環境でも、監視は重要です。 可用性の高い環境では、デプロイメントの一部は手動で操作しなくてもフェイルオーバーします。 たとえば、ArcGIS Enterprise のプライマリ ポータルに障害が発生すると、ソフトウェアは手動操作を行うことなくスタンバイに即座にフェイルオーバーします。 同様に、ArcGIS Server と ArcGIS Data Store コンポーネントに障害が発生しても、単一障害点がないのでシステムは通常どおり動作します。 ArcGIS Enterprise が明らかに停止しているわけではないので、ArcGIS Enterprise デプロイメントの特定のコンポーネントに障害が発生したときに管理者に通知する仕組みを備えておく必要があります。
ArcGIS Monitor を使用して、デプロイメントの Portal for ArcGIS、ArcGIS Server、およびリレーショナル ArcGIS Data Store コンポーネントの健全性を解析できます。 また、デプロイメントを複製する前に、Portal Index Taskを実行して、プライマリ ポータル コンピューターの Index Status をクエリすることもできます。 登録済みの PostgreSQL、Oracle、または Microsoft SQL Server データベースをデプロイメントで使用する場合、ArcGIS Monitor のギャラリー内にあるいずれかの Egdb タスクを使用して、それらのデータベースの統計情報を監視できます。
登録済みのフォルダー、ビッグ データ ファイル共有、ラスター データ ストア、タイル キャッシュ、および時空間ビッグ データ ストアへの接続の整合チェックを自動化するには、ArcGIS Server の REST API で Python または選択したスクリプト言語を使用する必要があります。
複製された環境では、フェイルオーバーを行うには手動操作が必要です。そのため、フェイルオーバーの要否を判断するには、デプロイメントを監視し、障害がいつ発生したのかを把握しなければなりません。
プライマリからスタンバイにデプロイメントを復元する操作を自動化している場合は、バックアップやファイル移動、復元操作が正常に行われるよう、これらのプロセスを監視する必要があります。
フェイルオーバーについて
ArcGIS Enterprise では、Portal for ArcGIS、ArcGIS Server、ArcGIS Data Store には独自のフェイルオーバー機構があります。 可用性の高い構成では、各コンポーネントは ArcGIS Enterprise 全体を停止しなくてもフェイルオーバーすることができます。
複製されたデプロイメントをプライマリ データ センターからスタンバイ データ センターにフェイルオーバーするには、通常は組織の IT 部門が介入し、グローバル サイト セレクター (GSS) またはグローバル DNS が使用されます。 通常、組織のメンバーは、少数の URL を通じて ArcGIS Enterprise デプロイメントにアクセスします (ポータル URL の場合は https://myportalwa.organization.com/portal、ArcGIS Server サービス URL の場合は https://myserverwa.organization.com/server)。 GSS またはグローバル GNS は、各ホスト名に IP アドレスを割り当てることができます。 別のデータ センターにフェイルオーバーする必要がある場合、GSS またはグローバル DNS は、スタンバイ データ センターに関連付けられた IP アドレスに myportalwa.organization.com および myserverwa.organization.com ホスト名を再度割り当てます。 クライアントとユーザーには影響ありませんが、すべてのリクエストはスタンバイ データ センターに送信されます。 プライマリ データ センターがオンラインに復旧すると、プライマリ サイト ホストの IP アドレスを、元のデータ センター内の IP アドレスに割り当て直すことができます。 その場合は、スタンバイで動作していたときに作成された新しいコンテンツやデータがすべてプライマリ データ センターに含まれるよう、スタンバイとプライマリのデータを一致させる必要があります。
ホスティング サーバーまたはフェデレートされた ArcGIS Server サイトの登録データベース (エンタープライズ ジオデータベースまたはデータベース) のデータが修正された場合は、データベース レプリケーション ツールを使用し、更新されたデータを元のプライマリ ArcGIS Enterprise デプロイメントに含めます。 ArcGIS Enterprise デプロイメントの ArcGIS Server サイトに登録されたファイルベースのデータ ソース (ファイル ジオデータベースなど) に変更が加えられた場合は、編集されたファイルを元の保存先ディレクトリにコピーします。 最後に、webgisdr ユーティリティを使用して ArcGIS Enterprise バックアップをスタンバイからエクスポートし、プライマリにインポートします。 このユーティリティにより、関連付けられたホスト フィーチャ レイヤー データ、シーン レイヤー データ、ポータルに登録された新しいサービスなどのポータル コンテンツが、元のプライマリ ArcGIS Enterprise デプロイメントに複製されます。