ArcGIS Enterprise on Kubernetes では、ArcGIS Enterprise 組織サイトをバックアップして、後で復元してデータ損失とダウンタイムを回避することができます。 障害が発生した場合は、最新のバックアップを復元してバックアップが作成された時点に組織サイトを復元することができます。 新たに配置した組織サイトにバックアップを復元する場合、ソースとターゲットの環境で次の設定を同一にする必要があります。
- 完全修飾ドメイン名 (FQDN) とコンテキスト パス (https://dnsalias.domain.com/context)
- レジストリのホストおよびリポジトリ (docker.io および esridocker)
- Kubernetes 名前空間 (arcgis)
- Kubernetes クラスター ドメイン (cluster.local)
- Kubernetes サービス DNS の接尾辞 (svc.cluster.local)
- FSGroup および補足グループ ID (カスタム値を使用して配置されている場合)
注意:
これらの設定は、配置時に指定しました。
管理者は、バックアップ ファイルを格納する永続ボリューム (PV) を指定する必要があります。 組織サイトがバックアップされると、バックアップ ファイルはこの PV に保存されます。 この PV には利用可能なバックアップがリストされ、そのバックアップ ストアに格納されている任意のバックアップ ファイルを、実行中の配置と同じリリースから復元することができます。
以下で PV がサポートされています。
- EBS ボリュームや Azure ディスクなどのブロック ストレージ デバイス
- Azure ファイルなどのファイル ストレージ
- Amazon Elastic File System
- 組織内でプロビジョニングされたネットワーク ファイル システム (NFS) 共有
バックアップ ストアが既存の PV にバインドするには、アクセス モードが [ReadWriteOnce] に設定されている必要があります。 動的にプロビジョニングされた PV の場合、別の場所で復元しやすくなるよう、再要求ポリシーを [維持] に設定します。 ホスト バックアップ ストア タイプでは、1 つのバックアップ ストアから基となるオブジェクト ストアへの接続のみが許可されます。
バックアップは、手動で作成することも、ArcGIS Enterprise Manager を使用して 1 回限りまたは反復的なバックアップ スケジュールで自動的に作成することもできます。
バックアップを作成する頻度を決定するには、まず、組織が障害時に許容できるデータ損失の量を識別します。 たとえば、組織が 1 日分のデータ損失を許容できる場合、組織サイトを毎日バックアップする必要があります。
バックアップの作成または復元にかかる時間とバックアップのサイズは、組織サイト内のアイテムの数、Web レイヤーの数、関連データのサイズ、バックアップが格納されている場所の詳細など、さまざまな要因によって異なります。 復元プロセスをテストすると、プロセスにかかる一般的な時間を把握して、障害復旧計画を実践することもできます。
バックアップ構成
組織サイトのバックアップを作成する前に、ステージングの場所を定義し、配置のバックアップ ストアを登録する必要があります。 バックアップ ストアの登録では、ラベル セレクターを使用して既存の PV にバインドするか、ストレージ クラスを使用して新しい PV を動的にプロビジョニングすることができます。 バックアップ ストアは、登録プロセスの一環として、PV にバインドする永続ボリューム クレーム (PVC) を作成します。 また、異なるストレージ クラスまたはプロビジョニング方法を使用して、複数のバックアップ ストアを登録することもできます。
ArcGIS Enterprise Manager を使用してバックアップを作成できます。 バックアップが作成されると、システム データ ストアに次のデータが格納されます。
- ホストされた地理空間データ
- 組織のアイテムとコンテンツ
- サーバー構成ストア
- システム構成プロパティ
ArcGIS Enterprise on Kubernetes では、各バックアップにタイムスタンプが付けられ、組織サイトの完全バックアップとして構成されます。 エンタープライズ ジオデータベースや、ファイル システムの別の場所にあるような Kubernetes 環境の外部にあるデータは、バックアップされません。 データベース ベンダーや IT 部門の推奨事項に基づいて、このデータをバックアップします。
データ損失を防止するために定期的なバックアップを実行することをお勧めします。 また、ソフトウェアの更新をインストールしたり新しいリリースにアップグレードしたりする前に、バックアップを作成する必要もあります。
バックアップを作成する前に、次の手順を実行する必要があります。
- ステージングの場所の登録
- バックアップ ストアの登録
ステージングの場所およびバックアップ ストアの登録
組織サイト内にある各コンポーネントは、最初はバックアップ プロセス中に別々にバックアップされます。 ステージングされたファイルとフォルダーのサイズは大きくなる場合があるため、まず、十分な格納領域があるようにステージング場所を構成する必要があります。 ステージングの場所には、各バックアップをバックアップ ストアに移動する前に一時的に格納するために PV が使用されます。
ステージングの場所はテンポラリ データに使用されるため、動的にプロビジョニングされる PV を含むストレージ クラスを使用する必要があります。
注意:
バックアップが作成された元の組織にアクセスできなくなった場合は、特定の手順に従ってバックアップ ストアを登録し、既存のバックアップを取得する必要があります。 詳細については、「元の組織サイトにアクセスできない場合のバックアップの復元」をご参照ください。
ステージングの場所およびバックアップ ストアを登録するには、次の手順を実行します。
- 組織の管理者として ArcGIS Enterprise Manager にサイン インします。
- [バックアップ] ボタンをクリックします。
- バックアップ ページで、[バックアップ ストアの登録] をクリックします。
- ステージングの場所に関する次の情報を入力します。
- [サイズ (GiB)] - ステージング場所の PV のサイズ。 最小サイズは 16 GiB です。 各ストアのバックアップを格納するのに十分に大きなサイズである必要があります。
- [ストレージ クラス名] - ストレージ クラス名。
- 登録対象のバックアップ ストアのタイプを選択します。
- Amazon S3
- Azure Blob
- Google クラウド ストレージ
- システム管理ストレージ
- Amazon S3 を使用している場合は、次の情報を入力します。
- [バックアップ ストア名] - バックアップ ストアの名前。 名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
- [バケット名] - バックアップを保存するために Amazon S3 で作成されたバケットの名前。
- [領域] - バケットが作成された領域を指定します。
- [認証タイプ] - [アクセス キー] または [IAM ロール] を選択します。
- 認証タイプとしてアクセス キーを使用するなら、次の情報を入力します。
- [アクセス キー] - IAM ユーザーのアクセス キーを貼り付けるか、入力します。
- [シークレット キー] - IAM ユーザーのシークレット キーを貼り付けるか、入力します。
- Azure Blob を使用するなら、次の情報を入力します。
- [バックアップ ストア名] - バックアップ ストアの名前。 名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
- [コンテナー名] - バックアップ保存のために Azure で作成されたコンテナーの名前。
- [ストレージ アカウント] - コンテナーの上位に位置する親ストレージ アカウントの名前。
- [認証タイプ] - [ストレージ アカウント キー] または [マネージド ID] を選択します。
- 認証タイプとしてストレージ アカウント キーを使用するなら、次の情報を入力します。
- [アカウント キー] - 関連付けられているストレージ アカウントのプライマリ アカウント キーまたはセカンダリ アカウント キーを貼り付けるか、入力します。
- Google Cloud Storage を使用するなら、次の情報を入力します。
- [バックアップ ストア名] - バックアップ ストアの名前。 名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
- [バケット名] - バックアップを保存するために Google Cloud Storage で作成されたバケットの名前。
- [アクセス キー] - サービス アカウントのアクセス キーを貼り付けるか、入力します。
- [シークレット キー] - サービス アカウントのシークレット キーを貼り付けるか、入力します。
注意:
マルチリージョンのバケットはストレージの可用性と冗長性を向上させますが、バックアップの作成時または復元時にパフォーマンスの低下や予期しない遅延を招く可能性があります。 リージョナル、デュアルリージョン、マルチリージョンのクラウド ストレージ間の違いと場所に関する考慮事項については、Google Cloud のドキュメントをご参照ください。
- システム管理ストレージを使用するなら、次の情報を入力します。
- [ボリューム タイプ] - PVC が既存の PV にバインドする必要がある場合は [静的] を選択します。 指定したストレージ クラスを使用して新しい PV をプロビジョニングする必要がある場合は、[動的] を選択します。
- [バックアップ ストア名] - バックアップ ストアの名前を定義します。 これは、以前に登録されたバックアップ ストアの名前と一致する必要があります。 この名前に使用できるのは、小文字のアルファベット、数字、およびハイフンだけで、先頭または末尾にハイフンを使用してはいけません。
- [サイズ (GiB)] - バックアップ ストアの PV のサイズを定義します。 最小サイズは 32 GiB で、静的バインドを使用する場合は、この値が既存の PV のサイズと一致する必要があります。 この値が既存の PV のサイズよりも大きい場合、PVC は PV とバインドしません。
- [ストレージ クラス名] - ストレージ クラスは既存の PV のストレージ クラスと一致する必要があります。
- [ラベル セレクター] - 静的プロビジョニングに必要で、ラベルは既存の PV のラベルと一致する必要があります。
- [登録] をクリックします。
注意:
ストレージ クラスが定義されていない既存の PV にバインドする場合は、ストレージ クラス名を空白のままにします。 クラスターにデフォルトのストレージ クラスが構成されている場合、DefaultStorageClass アドミッション コントローラーによってデフォルトのストレージ クラスが追加され、PVC がバインドされないようにします。 この場合、管理者は PV にストレージ クラスの指定を追加するか、デフォルトのストレージ クラスの構成を削除する必要があります。ストレージ プロバイダーが PV の拡張を許可していない場合は、バックアップ ストアのサイズを検討します。 この場合、組織が保持しているデータ量と、作成するバックアップの数を評価します。 元のバックアップ ストアの格納領域が不足した場合は、古いバックアップを削除するか、新しいバックアップ ストアを登録します。
ストレージ プロバイダーが PV の拡張をサポートしている場合は、ボリュームの構成を変更できます。 PV のサイズを変更できるかどうかは、ストレージ クラスの [allowVolumeExpansion] 設定で決定されます。 これを true に設定する必要があります。 詳細については、環境固有のドキュメントをご確認ください。
次に、バックアップを作成します。