Google Cloud での OpenShift の障害復旧

障害復旧（DR）は、Google Cloud上の OpenShift Container Platform にデプロイされたアプリケーションの継続性を維持するために不可欠です。このドキュメントでは、 Google Cloudの OpenShift を使用した DR のアーキテクチャ オプションの概要について説明します。これにより、組織は障害発生時のダウンタイムを最小限に抑え、迅速な復旧を実現できます。

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

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

DR の計画

DR の計画は、クラウドで本番環境のワークロードを実行するうえで重要なコンポーネントです。OpenShift と Google Cloud は堅牢なインフラストラクチャ レベルの冗長性を提供しますが、致命的な障害から迅速に復旧するようにアプリケーションを設計して構成する必要があります。

効果的な DR の計画には、階層化されたアプローチが必要です。まず、迅速な再デプロイのために、アプリケーションとシステムの明確な目標復旧時間（RTO）と目標復旧時点（RPO）を定義します。

最後に、シークレットと認証情報も復元可能で、安全に管理されている必要があります。これらの要素をすべて考慮することで、別のリージョンに新しい OpenShift クラスタをすばやく作成したり、非アクティブなセカンダリ クラスタにフェイルオーバーしたりできる DR 態勢を確立できます。このセカンダリ クラスタは、障害が発生するまでオフラインのままです。障害が発生すると、セカンダリ クラスタが起動してオンラインになり、ダウンタイムを最小限に抑えてオペレーションを引き継ぎます。

DR のアーキテクチャ

Google Cloudの OpenShift で DR に使用できるデプロイ アーキテクチャには、さまざまなオプションがあります。これらのオプションは、費用、複雑さ、可用性にそれぞれ異なる影響を与えます。次の表に、これらのアーキテクチャの概要を示します。

アーキテクチャ 説明 ユースケース メリット デメリット
アクティブ / パッシブ 1 つのクラスタがアクティブですべてのトラフィックを処理し、もう 1 つのクラスタがパッシブで引き継げるように備えています。データはパッシブ クラスタに複製されます。 RTO と RPO の要件が中程度のアプリケーションに適しています。 実装が簡単で、スタンバイ クラスタの費用が削減されます。 フェイルオーバー時間とデータ同期の遅延の可能性により、RTO が長くなります。
アクティブ / 非アクティブ アクティブ / パッシブと同様ですが、非アクティブ クラスタは DR のイベントが発生するまで使用されません。データは定期的にバックアップされます。 RTO と RPO の値を大きくできる費用重視の環境に最適です。 非アクティブ時の運用コストが低く、セカンダリ システムがアクティブに実行されていない DR（コールド DR）に適しています。 データが古くなる可能性がありますが、有効化と同期に時間がかかるため RTO が長くなります。
アクティブ / アクティブ 両方のクラスタがアクティブで、リージョン間のロード バランシングとデータ レプリケーションを使用してトラフィックを処理します。 ダウンタイムの最小化と高可用性を必要とするクリティカルなアプリケーション。 RTO と RPO が最も短く、継続的な可用性を実現します。 複雑さとコストが最も高く、堅牢なネットワークとデータ同期が必要です。

次のステップ