ArcGIS Enterprise の配置が複雑になるにつれて、障害復旧に関しても追加の検討が必要になります。 これらの検討には、配置アーキテクチャを形成するさまざまなシステムに対する洞察が必要です。 多くの技術的シナリオと同様、配置のコア システムおよび従属システムのバックアップに万能な方法はありません。
障害復旧時の復元の成功率を高めるためのフレームワークについて、以下に説明します。 組織は以下のプラクティスを採用して、ArcGIS Enterprise 配置を考慮した障害時の事業継続/障害復旧 (BC/DR) 計画の一環として、標準的な運用手順を定めることができます。
バックアップの作成に関するベスト プラクティス
ArcGIS Enterprise 組織および参照されるデータ ソースのバックアップを作成する際は、以下のベスト プラクティスを確認してください。
ArcGIS Enterprise のバックアップ
ArcGIS Enterprise 組織は、Portal for ArcGIS サイト、すべてのフェデレーション ArcGIS Server サイトとその関連データ、および ArcGIS Data Store に含まれるデータで構成されています。 コンポーネントのバックアップは、付属の WebGISDR (Web GIS Disaster Recovery) ツールを使用するか、サードパーティ ツールを使用してコンピューターベースおよびイメージベースのバックアップを行うことができます。
WebGISDR ツールは Portal for ArcGIS に付属しているコマンド ライン ユーティリティで、このユーティリティを使用すると、組織のコンテンツおよびデータ、フェデレーション ArcGIS Server サイトの情報、リレーショナルおよびタイル キャッシュ データ ストアに含まれるデータをバックアップできます。 このツールは、復旧を実行する際に機能的な配置が必要になりますが、基本配置のコンポーネントおよび追加のフェデレーション サイトの一貫性を維持する際に特に役立ちます。
WebGIS DR バックアップ プロセス以外に、次の点を考慮する必要があります。
- ArcGIS Mission Server または ArcGIS Notebook Server のフェデレーション サイト - これらのいずれかを使用している場合、ArcGIS Mission Server ドキュメントと ArcGIS Notebook Server ドキュメントの手順に従い、バックアップを作成します。
- 時空間ビッグ データ ストアとグラフ ストアのバックアップ - 時空間ビッグ データ ストアまたはグラフ ストア (あるいは両方) をホスティング サーバーに登録している場合は、ArcGIS Data Store の backupdatastore ユーティリティを使用して、それぞれのバックアップを作成します。
- ArcGIS GeoEvent Server サイト構成 - ArcGIS GeoEvent Server 構成のバックアップは、バックアップ構成ファイルを使用して管理します。
オブジェクト ストアは 11.0 では一時的フィーチャ レイヤーの応答キャッシュに使用されるため、復旧シナリオ時にデータを保持する必要はありません。
ほとんどの仮想化プラットフォームでは、実行中の仮想コンピューターのスナップショットを取得できるため、目標復旧時間を低減することができます。 これらは有用ですが、大規模な BC/DR 計画の一環として使用する耐久性の高いバックアップとは見なされません。
メンテナンス期間の前またはメンテナンスの実行中にバックアップを取得する場合、スナップショットにより実現される低い目標復旧時間が、そのツールを使用する理由になります。 サードパーティ バックアップを取得する場合、Portal for ArcGIS と ArcGIS Data Store の基になるデータ層コンポーネントがそれらのバックアップ方法と統合されていないため、稼働中のデータベースのライブ バックアップを取得することに関連した一定のリスクを伴います。 このリスクを最小化するには、スナップショットおよびイメージベースのバックアップを、稼働中の ArcGIS Enterprise コンポーネントのサービスを停止した後に取得する必要があります。
ファイル共有を使用して共有ポータルのコンテンツ ディレクトリ、構成ストア、ArcGIS Server サイトのルート ディレクトリをホストするアーキテクチャの場合、仮想コンピューターのスナップショットやイメージベースのバックアップなどのサードパーティ バックアップ ツールを使用する際は、それらの場所のバックアップの一貫性を考慮することが重要です。 たとえば、管理者が Portal for ArcGIS のアップグレードに失敗した後、スナップショットを復元してロールバックする場合、コンテンツ ディレクトリがアップグレード プロセスによって変更され、復元したインスタンス上のデータベースに含まれる情報と一致しなくなる可能性があります。 サードパーティ ツールを使用する際のこれらの影響を最小限に抑えるには、組織内でコンテンツの公開または編集が行われていない停止期間中にバックアップを取得する必要があります。 これには、ArcGIS Enterprise コンポーネントおよび関連するファイル共有の両方が含まれます。
ArcGIS Data Store を他のコンポーネントとは別にバックアップすることで、そのコンポーネントで障害が発生した場合のデータ損失を最小限に抑えることができます。 リレーショナルおよびタイル キャッシュ データ ストアのスケジュールされたバックアップは、WebGISDR ユーティリティおよびその他のバックアップ ツールのスケジュールとは別に実行できます。
参照されるデータ ソースのバックアップ
ArcGIS Server は、エンタープライズ ジオデータベース、登録済みのファイル共有、およびクラウド ストアを含む多くのソースからコンテンツを提供できます。 これらの外部データ ソースも、配置の障害復旧計画に含める必要があります。 バックアップの取得や別の場所へのデータの複製については、ベンダーの手順に従うことをお勧めします。
参照されるサービスが提供するデータを含むエンタープライズ ジオデータベースは、各組織の目標復旧時点に従い、ベンダーが提供するツールを使用してバックアップする必要があります。 このデータは ArcGIS Server サービスによって参照されているため、公開されたサービスを含むサイトと独立してデータベースの復旧を実行した場合、公開されたサービスの一貫性がバックエンド データベース テーブルと同期しなくなる可能性があります。 このため、ArcGIS Enterprise 配置内のすべてのコンポーネントでバックアップのスケジュールを揃えることが重要になります。
ネットワーク ファイル共有では、イメージベースまたはファイル システムベースのバックアップ ツールを使用してデータをパッケージ化し、配置の障害領域の外部に存在する耐久性の高いストレージ ソリューションに転送することができます。
クラウド ストアを別の領域にバックアップまたは複製して、復旧可能性と耐久性を高める必要があります。 複製されたストアをアーカイブまたはコールド ストレージを使用して配置し、全体的なコストを削減することもできます。
バックアップするタイミング
バックアップを取得する頻度はいくつかの要因に応じて異なりますが、最も重要な要因はバックアップが完了するまでの時間です。 バックアップ プロセスはシステム リソースの使用率に影響を与えるため、完全バックアップは通常、主要な営業時間以外の時間にスケジュール設定されます。 各バックアップ タイプにおいて、システムがバックアップされる頻度は、ArcGIS Enterprise 配置によって異なります。
たとえば、運用エンタープライズ ジオデータベースは、目標復旧時点を低減するため、15 分おきに増分バックアップされることがあります。 最も重要なデータは、損失する可能性のあるデータ量を低減するため、このデータベース インスタンス内に格納する必要があります。 多くの参照サービスと静的コンテンツを含む ArcGIS Enterprise 配置では、バックアップを取得する頻度は毎日または毎週でもかまいません。一方、ホスト フィーチャ サービスの使用率が高く、Web マップおよびアプリケーションが頻繁に作成される配置では、バックアップの時間間隔を短くすることを目標にしてください。
バックアップの整合チェック
バックアップが正常に完了したことを監視し、障害が発生した場合は管理者に警告する必要があります。 WebGISDR ツールでは、バックアップが正常に完了したかどうかを判断するために、スクリプト実行時の終了コードを使用することができます。 0 はバックアップが成功したことを表し、0 以外のコードは失敗したことを表します。 統合して、バックアップの整合性を担当するチームに電子メールまたは SMS で通知できるアラート ツールがいくつか用意されています。 多くのサードパーティ バックアップ ツールは同様の機能を提供しているか、他のサービスと統合してアラートを提供することができます。
組織の BC/DR 計画を整合チェックするもう 1 つの重要な側面は、半定期的に復元訓練を実施することです。 これは、管理者が障害時に機能バックアップから復元するための準備と、以下の復元計画の整合チェックを確実に行うのに役立ちます。
バックアップ ファイルを保存する期間
バックアップ ファイルの保存期間は、空きディスク容量や、復元オプションでどの程度の柔軟性が求められるかによって異なります。 最後の完全バックアップの前の時間に復元する必要がない場合は、最終完全バックアップと、それ以降に作成した増分バックアップを保持しておくことができます。
WebGISDR ツールで作成された増分バックアップは累積的です。つまり、最終完全バックアップに最新の増分バックアップを適用することができます。 したがって、少なくとも最終完全バックアップと、それ以降に作成された最新の増分バックアップを保持しておく必要があります。
また、古いバックアップをストレージ メディアなどの別の場所に移すこともできます。 そうすると、最終完全バックアップの前に主なデータやサービスが削除されていても、ファイルは手元に残っています。
注意:
WebGISDR ユーティリティには、バックアップの作成時の ArcGIS Enterprise コンポーネントのソフトウェア バージョンが記録されます。 復元先の配置は、バックアップを作成した時点のバージョンにする必要があります。 さらに、同じ種類のオペレーティング システムに復元する必要があります。 たとえば、Linux 上の ArcGIS Enterprise 配置のバックアップを作成して、それを Windows コンピューターに復元することはできません。組織の復元に関するベスト プラクティス
作成したバックアップを使用して ArcGIS Enterprise 組織を復元する際は、以下のベスト プラクティスを確認してください。
復元する内容
管理者が自由に選択できる複数のバックアップ タイプがある場合、配置全体を元に戻すのではなく、より細やかな方法でコンポーネントを復元できます。 マップまたはイメージ サービスのキャッシュが削除された場合、それらのファイルのみをバックアップから復旧する必要があります。 同様に、エンタープライズ ジオデータベースからテーブルが誤って削除された場合、他のコンポーネントに影響を与えることなく、そのデータベースを復旧することができます。
ホスト フィーチャ レイヤーに不適切な編集が行われ、データをロールバックする必要がある場合、管理者は ArcGIS Enterprise 配置全体を復元せずにリレーショナル データ ストアのみを復元することができます。 これにより、復元がデータベース内に格納されている他のデータに与える影響を軽減できますが、その間に作成されたホスト サービスが存在する場合、ArcGIS Server サイトは復元されたデータベース テーブルとの一貫性がなくなり、影響を受けるサービスの手動クリーンナップと再公開が必要になる可能性があります。
また、データ センターやクラウド領域などの大規模な機能停止が発生し、ArcGIS Enterprise 配置全体と外部データ ソースの復元が必要になる場合もあります。 これは非常に極端な例ですが、復元された環境が完全に機能するよう適切な計画が必要です。
復元する方法
ArcGIS Enterprise 配置が広範囲にわたって機能停止した場合、利用可能なバックアップのタイプに応じて複数の復旧オプションがあります。 WebGISDR ユーティリティを使用した近傍サイトへのレプリケーションは、配置の復旧にかかる時間を短縮する最も重要な方法です。一方、スピンアップと復元が可能なコールド スタンバイ サイトを用意することで、復旧訓練を簡単に実施できるとともに、復旧にかかる時間を全体的に短縮できます。
復旧の手順を決定する際は、最短の目標復旧時点および目標復旧時間を実現するオプションを最初に試行する必要があります。 これにより、復元の成功レベルに関して最速でフィードバックを得ることができます。 管理者がバックアップ戦略を十分に理解し、過去に定期的に復元をテストしたことがある場合も、障害シナリオでの復旧にかかる時間を短縮できます。
ArcGIS Enterprise には内部コンポーネントおよび外部コンポーネントにわたる複数の層が存在するため、これらのコンポーネントを復元する順序は、復元後の配置の安定性に影響を与えます。 ArcGIS Enterprise コンピューターおよびコンポーネントを復元する前に、参照されるすべてのデータ ソースを最初に利用できるようにし、データベース インスタンスや外部ファイル共有などの ArcGIS Enterprise 環境からアクセスできることを確認する必要があります。
周囲の依存関係が整い次第、ArcGIS Enterprise 配置を一貫性がある状態に復元する必要があります。 これにより、ホスティング サーバー サイトにホスト フィーチャ サービスが公開されている場合に、リレーショナル データ ストアに従属データ テーブルが存在しなかったり、フェデレーション サイトに存在しなくなったサービスのアイテムが組織に格納されていたりすることがないようにします。
復元後の整合チェック
復元操作が完了したら、業務に不可欠なデータおよび ArcGIS Enterprise 配置の広範囲にわたる機能に対する整合チェックを実施する必要があります。 これは、業務の中心的な部署および各部門が最も重要なコンテンツを確認するためのチェックリストを作成したり、自動スクリプト作成により実現できます。 自動化されたスクリプトを使用してこの整合チェックに取り組むことで、アイテムおよびサービスを手動で確認するよりも短い時間で、より確実に復元を成功させることができます。
バックアップおよび復元操作の自動化
重大なデータ損失を防ぎ、ダウンタイムを削減するため、定期的にバックアップを作成することをお勧めします。 バックアップの作成頻度は、許容するデータ損失の量を定義する組織サイトの RPO (Recovery Point Objective) に応じて決定されます。 たとえば、12 時間以上のデータ損失を許容できない場合、12 時間より短い周期でバックアップを作成するスケジュールを定義します。
Linux でのバックアップの作成と復元は、CronJob やその他のスケジュール設定ソフトウェアを使用して自動化できます。 組織サイト内のデータ量は、バックアップの作成頻度やバックアップを復元する速度にも影響します。 スケジュール タスクを設定する前に、そのタスクの所要時間をテストすることで、次のタスクが実行される前にバックアップまたは復元操作が完了していることを確認できます。
さらに、バックアップまたは復元操作が成功しているかどうかを判断する必要があります。 WebGISDR ツールは出力ファイルをサポートしており、操作の結果を JSON として記録するため、この JSON を解析することでバックアップの有無、失敗したコンポーネントの有無、および各コンポーネントの所要時間を判断できます。 このファイルをバックアップおよび復元ロジックに統合することで、管理者に失敗またはアクション アイテムを通知できます。