アクティブ / 非アクティブのセットアップの障害復旧戦略

このドキュメントでは、 Google Cloud 上の OpenShift デプロイのアクティブ / 非アクティブの障害復旧を計画して実装し、障害発生時のダウンタイムを最小限に抑え、迅速な復旧を実現する方法について説明します。データのバックアップ、コードとしての構成の管理、シークレットの処理に関するベスト プラクティスを提供し、障害発生時にアプリケーションを迅速に復元できるようにします。

このドキュメントは、 Google Cloudにデプロイされた Red Hat OpenShift Container Platform 上のアプリケーションの可用性と復元性を維持するシステム管理者、クラウド アーキテクト、アプリケーション デベロッパーを対象としています。

このドキュメントは、障害が発生した場合にワークロードの高可用性を維持し、迅速に復元するためのアプリケーション レベルの戦略に焦点を当てたシリーズの一部です。障害復旧のベスト プラクティスを読んでいることを前提としています。このシリーズのドキュメントは次のとおりです。

障害復旧のアーキテクチャ

アクティブ / 非アクティブの DR では、セカンダリ リージョンをスタンバイとして維持し、災害発生時にのみアクティブにします。データが継続的に複製されるアクティブ / パッシブ設定とは異なり、この戦略では、Cloud Storage に保存される定期的なバックアップに依存します。フェイルオーバー時にインフラストラクチャがプロビジョニングされ、データが復元されます。OpenShift API for Data Protection（OADP）と統合された Velero などのツールを使用して、定期的なバックアップを実行できます。この方法はコストを最小限に抑えることができるため、復旧に時間がかかっても許容できるアプリケーションに最適です。また、組織が拡張された目標復旧時間（RTO）と目標復旧時点（RPO）に沿って対応するうえでも役立ちます。

アクティブ / パッシブの障害復旧シナリオでは、データはスタンバイ リージョンに定期的にバックアップされますが、アクティブに複製されません。インフラストラクチャはフェイルオーバー プロセスの一部としてプロビジョニングされ、データは最新のバックアップから復元されます。Velero オープンソース プロジェクトに基づく OpenShift API for Data Protection（OADP）を使用して、定期的なバックアップを実行できます。これらのバックアップは、バージョニングが有効になっている Cloud Storage バケットに保存することをおすすめします。障害発生時には、OADP を使用してクラスタのコンテンツを復元できます。このアプローチでは、継続的なコストを最小限に抑えることができますが、アクティブ / パッシブと比較して RTO が長くなり、RPO が高くなる可能性があります。この設定は、目標復旧時間が長いアプリケーションに適しています。

次の図は、アクティブ / 非アクティブ デプロイとフェイルオーバー プロセスを示しています。

フェイルオーバー プロセス

フェイルオーバー プロセスは次のとおりです。

  1. DR イベントは、モニタリング対象サービスが使用不可になったときにトリガーされます。
  2. パイプラインは、DR リージョンにインフラストラクチャを自動的にプロビジョニングします。
  3. 新しい OpenShift クラスタがプロビジョニングされます。
  4. アプリケーション データ、シークレット、オブジェクトは、OADP を介して最新のバックアップから復元されます。
  5. Cloud DNS レコードが更新され、DR リージョンのリージョン ロードバランサを参照するようになります。

上の図に示すように、2 つの別々の OpenShift リージョン クラスタがデプロイされます。それぞれ異なる Google Cloud リージョン（us-central1 や europe-west1 など）にデプロイされます。各クラスタは、リージョン内で高可用性を実現し、冗長性を確保するために複数のゾーンを使用する必要があります。

アクティブ / 非アクティブの DR シナリオのコンポーネントの説明

このアーキテクチャは、次の構成になっています。

  • プライマリ リージョン（リージョン A）: 本番環境のトラフィックを処理する完全に機能する OpenShift クラスタが含まれています。
  • セカンダリ リージョン（リージョン B）: 最初は最小限のリソース（VPC とサブネット）が含まれています。フェイルオーバー中にインフラストラクチャ（Compute Engine インスタンスと OCP）がプロビジョニングされます。
  • バックアップ ストレージ: Google Cloud Storage バケットには、定期的なバックアップ（アプリケーション オブジェクトの OADP または Velero、PV、データベースのバックアップ）が保存されます。バケットには、バージョニングとクロスリージョン レプリケーションを使用することをおすすめします。
  • 構成管理: Git リポジトリには、Infrastructure as Code（IaC、Terraform など）と Kubernetes または OpenShift マニフェスト（GitOps 用）が保存されます。
  • バックアップ ツール: Cloud Storage へのスケジュール バックアップを実行するようにプライマリ クラスタで構成された OADP（Velero）。
  • オーケストレーション: スクリプトまたは自動化ツールは、フェイルオーバー中にインフラストラクチャのプロビジョニングと復元プロセスをトリガーします。

使用するプロダクト

ユースケース

アクティブ / 非アクティブ DR は、次のユースケースにおすすめします。

  • RTO が長くても許容されるアプリケーション（数分から数時間など）。
  • 費用最適化が重要であり、スタンバイ クラスタの継続的な実行費用が過大になる環境。主な継続費用は、コンピューティング インスタンスの実行ではなく、オブジェクト ストレージに対するものです。
  • 開発、テスト、重要度の低い本番環境のワークロード。
  • 復元時間が重要ではないアーカイブ システムまたはバッチ処理システム。

設計上の考慮事項

このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、設計に関する推奨事項について説明します。

アプリケーション構成をコードとして管理する（GitOps）

GitOps アプローチを採用して、すべてのクラスタとアプリケーションの構成を Git リポジトリに保存することをおすすめします。このアプローチでは、別のクラスタで確実に実行されていることがわかっている状態への同期を有効にすることで、DR シナリオでの迅速な復元が可能になります。バックアップにより、ランタイム状態のスナップショットを確保できますが、障害発生後にアプリケーション ロジック、マニフェスト、インフラストラクチャ定義を迅速に再デプロイする信頼性の高い方法も必要です。

OpenShift GitOps Operator を使用する

Argo CD に基づく OpenShift GitOps Operator は、OpenShift 環境内で GitOps パターンを直接実装するための Red Hat がサポートする方法を提供します。クラスタの状態と選択した構成を継続的に調整し、Git リポジトリに保存するプロセスを自動化します。

OpenShift GitOps Operator のコントローラは、クラスタの状態がこのリポジトリで定義された構成と一致することを継続的に確認します。リソースがドリフトしている場合や欠落している場合は、自動的に調整されます。詳細については、Red Hat OpenShift GitOps についてをご覧ください。

DR シナリオの実行

障害が発生した場合は、次の操作を行います。

  • 別のリージョンに新しい OpenShift クラスタを設定します。
  • OpenShift GitOps Operator をインストールします。
  • Git リポジトリを参照する同じアプリケーション マニフェストを適用します。

Operator は、クラスタの状態をリポジトリと一致するように同期し、コードで定義されたデプロイ、サービス、ルート、オペレーター、その他のリソースを迅速に再デプロイします。

DR 中に問題が発生しないように、次のことをおすすめします。

  • Git リポジトリで厳格なブランチ戦略とタグ付け戦略を維持して、DR に適した安定した構成を特定できるようにします。
  • DR クラスタにネットワーク接続があり、Git リポジトリにアクセスするための適切な権限があることを確認します。
  • フェイルオーバー時の手動介入を回避するために、すべてのリソースタイプをコードとして含めます（インフラストラクチャ コンポーネント、アプリケーション ワークロード、構成など）。

ファイアウォール ルール

統合ファイアウォール ポリシーを定義し、両方のクラスタに一貫して適用して、トラフィック フローを制御し、セキュリティを強化します。

最小権限の原則に従います。つまり、インバウンド トラフィックとアウトバウンド トラフィックをアプリケーションの機能に必要なもののみに制限します。

デプロイ

このリファレンス アーキテクチャに基づくトポロジーをデプロイする方法については、Red Hat のドキュメントをご覧ください。

次のステップ