Omnissa Access は、共有 NFS マウントを使用したバックアップおよびリストア モデルによるディザスタ リカバリをサポートします。このモデルでは、セカンダリ クラスタはプライマリ クラスタによって生成されたバックアップ データにアクセスできます。ディザスタ リカバリ イベントが宣言されると、セカンダリ クラスタは手動でプライマリに昇格され、読み取り/書き込みトラフィックを処理します。元のサイトへのフェイルバックは計画された手動操作であり、自動的には発生しません。元のプライマリが使用可能になると、計画されたフェイルバックが実行されるまでセカンダリ ロールのままになります。
このトピックでは、NFS バックアップ ストレージの構成、バックアップ スケジュールの管理、必要なブートストラップ ノード データのバックアップ、フェイルオーバー中のバックアップからの Omnissa Access のリストア方法について説明します。
前提条件
ディザスタ リカバリを構成する前に、次の条件を満たしていることを確認します。
- レプリケートされた NFS 共有が構成され、プライマリ クラスタ ノードとセカンダリ クラスタ ノードの両方からネットワーク経由でアクセスできます。
- セカンダリ クラスタは、ソース クラスタと同じアセット バンドル バージョンを使用して展開されます。
- プライマリ クラスタのブートストラップ ノードに対する管理アクセス権があり、シークレットと構成ファイルをバックアップできます。
NFS サーバでの NFS エクスポートの構成
バックアップ サービスは root として実行されるため、NFS エクスポートには no_root_squash オプションが含まれている必要があります。NFS サーバで、/etc/exports のエクスポート構成を確認します。
cat /etc/exports
出力には、次の形式のエントリが含まれているはずです。
<NFS-MOUNT-POINT> <NFS-CLIENT-IP>(rw,sync,no_subtree_check,no_root_squash)
<NFS-CLIENT-IP> は、マウントへのアクセスが許可されるすべてのクラスタ ノードをカバーする IP アドレス範囲または IP アドレスのセットです。たとえば、ソース クラスタ ノードが 10.48.34.100 から 10.48.34.105 の範囲のアドレスを使用する場合は、<NFS-CLIENT-IP> を 10.48.34.0/24 に設定して、完全なサブネットをカバーします。フェイルオーバー中にセカンダリ クラスタがプライマリに昇格する場合、そのノード アドレスも許可された IP アドレス範囲内に収める必要があります。
NFS バックアップのための profile.yml の構成
サービスを展開する前に、共有 NFS マウントにバックアップを書き込むよう、ソース クラスタを構成する必要があります。これらのバックアップは、フェイルオーバー中にセカンダリ クラスタをリストアするために使用されます。
-
ソース クラスタのブートストラップ ノードで、
/root/<cluster_name>/profile.ymlを開きます。 -
次の行を見つけ、NFS サーバの詳細を入力してコメント解除します。
nfs_host: <NFS-HOST-IP> nfs_path: <NFS-MOUNT-POINT> nfs_version: 4 -
ファイルを保存し、このガイドのフェーズ 4 およびフェーズ 5 の説明に従ってサービスの展開を続行します。
**注：**最初のサービス展開の前に NFS の詳細が
profile.ymlに含まれていなかった場合は、後で追加し、バックアップ依存サービスを再展開します。> ```bash > wso services deploy -s postgres > wso services deploy -s control-plane-backup > wso services deploy -s opensearch > ``` -
セカンダリ クラスタ上の別のマシンから NFS マウントにアクセス可能であることを確認するには、別の仮想マシンから次のコマンドを実行します。
# Mount the NFS share manually to test connectivity mount -t nfs <NFS-IP>:<NFS-MOUNT-POINT> /mnt # List the NFS exports visible to the client showmount -e <NFS-IP>showmount -eの出力には、構成されたマウント ポイントのエントリが含まれている必要があります。<NFS-MOUNT-POINT> <NFS-IP>
ブートストラップ ノード データのバックアップ
リストアを続行するには、プライマリ ブートストラップ ノードの次の項目をセカンダリ ブートストラップ ノードで使用できる必要があります。ディザスタ リカバリ イベントが発生する前に、これらの項目を安全な場所にバックアップします。
Omnissa では、自動バックアップ操作による干渉を回避するため、このデータをサービス バックアップに使用されるのと同じ NFS サーバ上の、別の NFS マウントに保存することをお勧めします。
| 項目 | プライマリ ブートストラップ ノードのパス |
|---|---|
| TLS 証明書 | /root/<cluster_name>/cp-cluster/secrets/cp-cluster/tls |
| Vault のシール解除キーとルート キー | /root/<cluster_name>/cp-cluster/secrets/cp-cluster/vault |
| サービス展開環境変数 | /root/<cluster_name>/additional_env_vars.env |
| Access サービス プロファイル | /root/<cluster_name>/access/access-profile.yml |
バックアップの頻度と保持の構成
ブートストラップ ノードの additional_env_vars.env ファイルに環境変数を設定することで、バックアップの作成頻度と保持期間を制御できます。これらの設定により、障害発生時に失われる可能性のあるデータの最大量である、目標復旧ポイント (RPO) が決定されます。
| 変数 | 説明 |
|---|---|
POSTGRESQL_FULL_BACKUP_CRON_SCHEDULE | データベースのフル バックアップの cron スケジュール |
POSTGRESQL_DIFF_BACKUP_CRON_SCHEDULE | データベースの差分バックアップの cron スケジュール |
CONTROL_PLANE_BACKUP_CRON_SCHEDULE | 制御プレーン コンポーネント バックアップの cron スケジュール（Nomad、Consul、Vault） |
KEEP_DAYS_CP | 制御プレーン バックアップの保持期間（日） |
WALG_RETENTION_DAYS | データベース バックアップの保持期間（日） |
KEEP_DAYS_POSTGRES_BACKUP_LOGS | データベース バックアップのログ ファイルの保持期間（日） |
データベースのバックアップ タイプ
Omnissa Access は、PostgreSQL データベースに 2 つの補助バックアップ タイプを使用します。
フル バックアップ
フル バックアップは、特定の時点での PostgreSQL データ ディレクトリ全体の完全なスナップショットをキャプチャします。フル バックアップは自己完結型で、追加のバックアップ ファイルなしでリストアできます。デフォルトでは、データベースのフル バックアップは毎日午前 5 時 (UTC) に 1 回実行され、差分バックアップのベースラインとして機能します。
差分バックアップ
差分バックアップでは、最新のフル バックアップ以降に変更されたデータ ページのみがキャプチャされます。差分バックアップは、フル バックアップよりも小さく、短い時間で完了できますが、自己完結型ではありません。差分バックアップからリストアするには、最新のフル バックアップと差分バックアップの両方が必要です。デフォルトでは、差分バックアップは毎日午後 5 時 (UTC) に 1 回実行されます。
フル バックアップ ジョブと差分バックアップ ジョブを組み合わせて、1 日全体のデータがカバーされます。スケジュール設定されたバックアップ間で障害が発生した場合、リストアでは最新のフル バックアップの上に最新の差分が適用されるため、潜在的なデータ損失は約 12 時間以内に制限されます。
差分バックアップ チェーンの深さ
1 つのフル バックアップの上に適用できる差分バックアップ レイヤーの最大数は、2 で固定されています。この制限は、WALG_DELTA_MAX_STEPS によって内部的に適用されており、構成できません。
Full Backup (base)
└── Delta 1 (changes since Full Backup)
└── Delta 2 (changes since Delta 1) ← maximum chain depth
チェーンが構成された最大値に達すると、WAL-G は、スケジュール設定された次の差分バックアップを新しいフル バックアップに自動的に昇格します。
フル バックアップと差分バックアップのスケジュールは調整できますが、連続するフル バックアップの間で実行される差分バックアップは 2 回以下にする必要があります。この制限の超過はサポートされていません。
FQDN およびネットワーク要件
エンドユーザーまたはコネクタの構成を変更せずにフェイルオーバーをサポートするには、ディザスタ リカバリ イベントが発生する前にセカンダリ クラスタが次の要件を満たしている必要があります。
- セカンダリ クラスタ エンドポイントの TLS 証明書は、プライマリ クラスタと同じ完全修飾ドメイン名 (FQDN) に対して有効である必要があります。証明書のローテーション プロセスは、プライマリ サイトとセカンダリ サイトの両方を一貫してカバーする必要があります。
- ファイアウォール ルールでは、プライマリ クラスタ エンドポイントとセカンダリ クラスタ エンドポイントの両方への送信トラフィックを許可する必要があります。公開された IP アドレス範囲は、両方のサイトでアクティブに管理する必要があります。
- コネクタ セッションの状態はセカンダリ ゲートウェイで完全に再構築可能である必要があります。プライマリ クラスタにのみ存在するセッション ストレージへの必須の依存関係がないようにする必要があります。
バックアップからの Omnissa Access のリストア
この手順では、フェイルオーバー中にセカンダリ クラスタを新しいプライマリとして有効にする方法について説明します。リストアが完了すると、セカンダリ クラスタはすべての読み取りおよび書き込みトラフィックを処理します。元のプライマリ クラスタは、再び使用可能になると、計画されたフェイルバックが実行されるまで新しいセカンダリとして扱われます。
**重要：**この手順を開始する前に、元のプライマリ クラスタにセカンダリ クラスタからアクセスできないことを確認します。リストア中に元のクラスタがまだアクセスできる状態になっていると、OpenSearch および PostgreSQL が元のクラスタからリストアされたクラスタにノードを追加しようとする場合があります。
**注：**Omnissa では、本番環境にディザスタ リカバリを展開する前に、本番環境以外の環境で時間を測定したリストア ドリルを実行することをお勧めします。これにより、実際のデータ ボリュームに基づいて目標復旧時間 (RTO) の現実的な予測が確立されます。
前提条件
リストア手順を開始する前に、次の点を確認します。
- セカンダリ クラスタは、すべての Omnissa Access サービス イメージが一致していることを確認するために、ソース クラスタと同じアセット バンドル バージョンを使用して展開されます。
- 「ブートストラップ ノード データのバックアップ」にリストされているブートストラップ ノード データが、セカンダリ ブートストラップ ノードでアクセスできる状態になっています。
手順
手順 1：セカンダリ クラスタの展開
ソース クラスタと同じアセット バンドル バージョンを使用して、新しい仮想マシンをプロビジョニングし、それらに制御プレーン アセット バンドルを展開します。セカンダリ クラスタには、ソース クラスタと同じ構成が必要です。
**重要：**この手順では、CP プラットフォーム サービス（Vault、Consul、Nomad）のみを展開します。この段階では Omnissa Access サービスを展開しないでください。Access サービスは、手順の後半でリストアされます。
続行する前に、セカンダリ ブートストラップ ノードのディレクトリ /root/<cluster_name>/cp-cluster/secrets/cp-cluster をバックアップします。
**推定所要時間：**30 分
手順 2：セカンダリ クラスタ ノードのスナップショット作成
制御プレーンが正常に展開されたら、すべてのセカンダリ クラスタ ノードの仮想マシン スナップショットを作成します。これらのスナップショットは、ディザスタ リカバリ手順を再起動する必要がある場合に、不具合がないことが確認されたリストア ポイントとなります。
**注：**リストア手順の間に任意の時点でこれらのスナップショットに戻す場合は、続行する前に Vault がセカンダリ クラスタでシール解除されていることを確認します。適切な認証情報を使用して Vault ユーザー インターフェイスにログインし、Vault のステータスが「シール解除」であることを確認します。
手順 3：セカンダリ クラスタへのシークレットのコピー
バックアップの場所からセカンダリ クラスタの backup_secrets ディレクトリに tls フォルダと vault フォルダをコピーします。
- バックアップした
tlsフォルダを次のようにコピーします →/root/<cluster_name>/cp-cluster/backup_secrets/tls - バックアップした
vaultフォルダを次のようにコピーします →/root/<cluster_name>/cp-cluster/backup_secrets/vault
コピー後、次のようにセカンダリ ブートストラップ ノードの backup_secrets ディレクトリに両方のフォルダが含まれていることを確認します。
ls -lrt backup_secrets/
total 0
drwxr-x---. 2 root root 64 May 7 07:46 tls
drwxr-x---. 4 root root 30 May 7 07:46 vault
手順 4：バックアップのリストアの計画
セカンダリ クラスタ ディレクトリから、次のコマンドを実行してバックアップを確認し、リストア ポイントを確認します。
wso cp plan-restore-backup
特定の時点からリストアするには、期間を指定して -a フラグを使用します。例：
| フラグ | 意味 |
|---|---|
-a 1d | 1 日前までの最新バックアップ |
-a 2h | 2 時間前までの最新バックアップ |
-a 30m | 30 分前までの最新バックアップ |
このフラグは、リストア操作の RPO を設定します。
手順 5：制御プレーン コンポーネントのリストア
この手順では、Consul のキー値データと Vault シークレットをセカンダリ クラスタにリストアします。
-
セカンダリ クラスタで Vault がシール解除されていることを確認します。
-
リストア コマンドを実行する前に、セカンダリ ブートストラップ ノードの
backup_secretsにtlsフォルダとvaultフォルダが存在することを確認します。ls -lrt /root/<cluster_name>/cp-cluster/backup_secrets/出力には、
tlsとvaultの両方のディレクトリが表示されます。drwxr-x---. 2 root root 64 <date> tls drwxr-x---. 4 root root 30 <date> vault -
クラスタ ディレクトリから、次のコマンドを実行します。
wso cp restore-backupこのコマンドで、Consul のキー値データと Vault シークレットがセカンダリ クラスタにリストアされます。期待される出力：
Imports KV in case of disaster recovery Backing up control plane credentials Restoring vault Restoring control plane credentials Resetting vault integration tokens Resetting vault integration token in nomad Resetting vault PKI integration token Updated vault with secrets after restore during Disaster recovery Adding PKI root and intermediate CA to truststore Deploying vault Restarting vault servers Unsealing Vault Enabling consul and nomad integration with vault Deploying consul Configuring consul connect CA provider Restarting the consul leader Restarting nomad scheduler agent Cleaning up Generating environment file with cluster details and secret tokens**注：**この手順でエラーが発生した場合は、すべてのセカンダリ クラスタ仮想マシンを手順 2 で作成したスナップショットに戻し、セカンダリ クラスタで Vault がシール解除されていることを確認して、手順 3 から手順を再開します。
**推定所要時間：**15 分
手順 6：サービスのリストア
この手順では、データベースとすべてのサービスをリストアします。この手順ではバックアップは作成されません。
-
環境変数ファイルをバックアップの場所からセカンダリ ブートストラップ ノードにコピーします。
/root/<cluster_name>/additional_env_vars.env -
Access サービス プロファイルをセカンダリ ブートストラップ ノードにコピーします。
/root/<cluster_name>/access/access-profile.yml -
access-profile.ymlファイルで、次の手順を実行します。ip_ignore_list_for_xff_headerフィールドとfqdn.ipフィールドを更新して、セカンダリ クラスタの IP アドレスと構成を反映します。- Nomad サブネットを
ip_ignore_list_for_xff_headerリストに追加します。- **注：**デフォルト値は
172.26.64.0/20です。カスタム サブネットを使用して展開する場合は、ip_ignore_list_for_xff_headerフィールドのサブネット値を対応する値に更新します。
- **注：**デフォルト値は
-
FQDN をセカンダリ クラスタに送信するように DNS サーバを更新します。
-
元のプライマリ クラスタがオフラインであるか、アクセスできないことを確認します。
-
次のコマンドを実行して、すべてのサービスをリストアします。
wso services restore --cps_image <cps-image>**注：**この手順で失敗したジョブがある場合は、パージして同じコマンドを再発行します。
特定のサービスのみをリストアするには、
-sフラグを含めます。wso services restore -s <service-name> --cps_image <cps-image>ここで、
<cps-image>は、ソース クラスタの展開に一致する制御プレーン サービスのイメージ タグです。**注：**この手順でエラーが発生した場合は、すべてのセカンダリ クラスタ仮想マシンを手順 2 で作成したスナップショットに戻し、セカンダリ クラスタで Vault がシール解除されていることを確認して、手順 3 から手順を再開します。
**推定所要時間：**75 分以上。実際の時間は、PostgreSQL および OpenSearch のデータ量に応じて直線的に長くなります。
手順 7：リストアの完了とバックアップ操作の再開
次のコマンドを実行してリストアされたデータを確認し、新しく昇格したプライマリ クラスタでバックアップ操作を有効にします。
wso services restore-complete --cps_image <cps-image>
**推定所要時間：**10 分
目標復旧時間
目標復旧時間 (RTO) の合計は、PostgreSQL および OpenSearch のデータ量によって異なります。予想される最小 RTO は約 2 時間で、実際の時間はデータ ボリュームに比例して増加します。Omnissa では、本番フェイルオーバーでこの手順をそのまま実行する前に、リストア ドリルを実行して時間を測定し、展開に固有の RTO 数値を確立することをお勧めします。
このページは役に立ちましたか?