アクティブ / パッシブ設定の障害復旧戦略

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

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

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

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

次のアーキテクチャ図は、上の OpenShift のアクティブ / パッシブ デプロイ シナリオ を示しています Google Cloud。

アクティブ / パッシブ デプロイ。以下の説明を参照。

上の図に示すように、障害復旧のアクティブ / パッシブ デプロイでは、プライマリ リージョンの OpenShift クラスタがすべての本番環境トラフィックを処理します。別のリージョンのセカンダリ クラスタは、プライマリに障害が発生した場合に引き継ぐ準備を維持しています。この設定により、セカンダリ クラスタが事前にプロビジョニングされ、ウォーム状態（必要なインフラストラクチャとアプリケーション コンポーネントが設定されているが、必要になるまでトラフィックをアクティブに処理しない状態）になるため、ダウンタイムを最小限に抑えることができます。アプリケーション データはパッシブ クラスタに複製され、データ損失が最小限に抑えられ、RPO に沿ったものになります。

リージョン クラスタの一つがプライマリ（アクティブ）サイトとして機能し、すべての本番環境トラフィックを処理します。別のリージョンにあるセカンダリ クラスタは、障害復旧のスタンバイです。セカンダリ クラスタはウォーム状態に保たれ、プライマリ クラスタで障害が発生した場合に、最小限の遅延で引き継げるように備えています。

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

このアーキテクチャには次の構成があります。

  • プライマリ OpenShift クラスタ（アクティブ）: プライマリ Google Cloud リージョンに配置され、本番環境のワークロードを実行し、 通常の動作条件下ですべてのユーザー トラフィックをアクティブに提供します。
  • セカンダリ OpenShift クラスタ（パッシブ）: 障害分離のために別のGoogle Cloud リージョンに配置され、ウォーム スタンバイ クラスタとして機能します。部分的に設定されて実行されており、プライマリ システムに障害が発生した場合に引き継げるように備えています。必要なインフラストラクチャ、OpenShift 構成、アプリケーション コンポーネントがデプロイされていますが、フェイルオーバー イベントがトリガーされるまで、本番環境のトラフィックは処理されません。
  • Google Cloud リージョン: 障害復旧の基盤となる地理的に分離されたロケーション。リージョンを分離することで、1 つのリージョンに影響する大規模なイベントがスタンバイ クラスタに影響しないようにします。
  • グローバル外部 HTTPS ロードバランサ: アプリケーション トラフィックの単一のグローバル エントリ ポイントとして機能します。通常、すべてのトラフィックをプライマリ（アクティブ）クラスタに転送するように構成されています。ヘルスチェックは、プライマリ クラスタの可用性をモニタリングします。
  • データ レプリケーション メカニズム: プライマリ クラスタからセカンダリ クラスタに重要なアプリケーション データ（データベースや永続ボリュームの状態など）をコピーする継続的なプロセスまたはツール。この方法によりデータの整合性が確保され、フェイルオーバー時のデータ損失が最小限に抑えられ、RPO を満たすことができます。
  • モニタリングとヘルスチェック: プライマリ クラスタとそのアプリケーションの健全性と可用性を継続的に評価するシステム（Cloud Monitoring、ロードバランサのヘルスチェック、内部クラスタ モニタリングなど）。これらのシステムは、障害を迅速に検出するために重要です。
  • フェイルオーバー メカニズム: プライマリで回復不能な障害が検出されたときに、プライマリからセカンダリ クラスタにトラフィックをリダイレクトする事前定義されたプロセス（手動、半自動、完全自動）。このプロセスでは通常、グローバル ロードバランサのバックエンド構成を更新してセカンダリ クラスタをターゲットにし、新しいアクティブ サイトにします。
  • VPC ネットワーク: データ レプリケーションと 管理のためにリージョン間の必要な接続を作成する基盤となる Google Cloud ネットワーク インフラストラクチャ。

使用するプロダクト

ユースケース

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

  • コールド復元で実現可能な RTO よりも短い RTO（数分から数時間など）を必要とするアプリケーション。コールド復元では、すぐにアクセスできないバックアップからデータが復元されます。
  • 継続的なデータ レプリケーションが可能で、RPO を最小限に抑える必要があるシステム（数分から数秒など）。
  • ダウンタイムの制限が厳しく、ウォーム スタンバイ クラスタの維持費用がダウンタイムによるビジネスへの影響によって正当化される、ビジネス クリティカルなアプリケーションを運用している規制対象業界。

設計上の考慮事項

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

アプリケーションの状態と構成の保護

OpenShift Container Platform は OADP を提供し、クラスタで実行されているアプリケーションに包括的な障害復旧保護を提供します。これを使用して、コンテナ化されたアプリケーションと仮想マシンの両方で使用される Kubernetes オブジェクトと OpenShift オブジェクト（Deployment、Service、ルート、PVC、ConfigMap、Secret、CRD など）をバックアップできます。ただし、OADP はクラスタの完全なバックアップと復元をサポートしていません。バックアップの構成とスケジュール設定の方法、復元オペレーションの方法については、Red Hat のドキュメントをご覧ください。

OADP は、アプリケーションで使用されるブロック ストレージと NFS ストアに依存する永続ボリュームのバックアップと復元プロセスを提供します。これらのプロセスを実行するには、Restic や Kopia などのツールを使用してスナップショットを作成するか、ファイルレベルのバックアップを実行します。

OADP は、オブジェクト定義のバックアップ、構成の整合性の確保、必要に応じて特定のアプリケーションや名前空間の復元に役立ち、データ複製を補完します。

アクティブ / パッシブ構成で RPO と RTO をさらに短縮するには、プライマリ リージョンとセカンダリ リージョン間のデータ レプリケーションを構成することをおすすめします。

データ レプリケーションは、セカンダリ クラスタがシームレスに引き継ぐことができるようにするために重要です。次のセクションで説明するように、プライマリ クラスタからセカンダリ クラスタへのデータ レプリケーションの実装は、アプリケーションが使用するストレージ タイプによって異なります。

ブロック ストレージ（永続ボリューム）

Google Persistent Disk 非同期レプリケーションを使用して、プライマリ リージョンからセカンダリ リージョンにデータをコピーします。この方法では、プライマリ リージョンにプライマリ ディスクを作成し、セカンダリ リージョンにセカンダリ ディスクを作成して、それらの間でレプリケーションを設定します。整合性グループを使用すると、両方のディスクに共通の時点のレプリケーション データが含まれるようになり、DR に使用されます。詳細については、Persistent Disk の非同期レプリケーションを構成するをご覧ください。

PersistentVolume オブジェクト

OpenShift で、これらのディスクにリンクする PersistentVolumes オブジェクトを両方のクラスタに作成し、アプリケーションが両方のクラスタで同じ Persistent Volume Claim（PVC）を使用していることを確認します。

アプリケーション レベルのレプリケーション

一部のアプリケーション（データベースやメッセージ キューなど）には、クラスタ間で構成できる組み込みのレプリケーション機能があります。Pub/Sub などのマネージド サービスを使用して、特定のタイプのアプリケーション データやイベントのレプリケーションを容易にすることもできます

データベースのバックアップ

アプリケーションはさまざまな種類のデータベース プロダクトに依存する可能性があります。このドキュメントでは、データベース バックアップの設計上の考慮事項を説明するために、PostgreSQL をデータベースの例として使用します。

クラスタ内データベース オペレータを使用したセルフホスト型バックアップ

CloudNative PostgreSQL Operator などのデータベース オペレータを使用すると、PostgreSQL クラスタのスケジュール設定されたバックアップと障害復旧を容易に行うことができます。CloudNative PostgreSQL Operator は、pg_basebackup などのツールとネイティブに統合され、ストリーミング レプリケーション バックアップをサポートします。耐久性と復元のために、Google Cloud Storage（Cloud Storage）などのクラウド ストレージ サービスにバックアップを保存できます。

プライマリ リージョンで停止が発生した場合でもデータを利用できるように、プライマリ リージョン クラスタとセカンダリ リージョン クラスタ間でストリーミング レプリケーションを設定できます。このストリーミング レプリケーションは、通常、リージョン内では同期的に行われ、リージョン間では非同期的に行われます。構成手順の詳細については、CloudNativePG のドキュメントをご覧ください。

障害が発生した場合は、バックアップを新しい PostgreSQL クラスタに復元して、ダウンタイムとデータ損失を最小限に抑えることができます。次に、CloudNative PostgreSQL オペレーターを使用してスケジュールされたバックアップを有効にする構成スニペットの例を示します。

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0 * * *"
  backupOwnerReference: self
cluster:
  name: pg-backup

マネージド サービス

Cloud SQL などのマネージド データベースには、バックアップとレプリケーションの機能が組み込まれています。プライマリ データベース インスタンスからセカンダリ リージョンのレプリカへの非同期レプリケーションを設定することをおすすめします。詳細については、 Cloud SQL でのレプリケーションについてをご覧ください。OpenShift で、各クラスタの正しいデータベース接続文字列を指すようにシークレットまたは構成マップを構成します。

非同期レプリケーションでは RPO がゼロにならないため、最新のデータ書き込みが失われる可能性があります。データ損失を軽減するようにアプリケーションを設計する必要があります。別のレプリケーション方法の使用を検討してください。

Cloud SQL の自動バックアップを有効にすることもおすすめします。詳細については、 オンデマンドバックアップと自動バックアップを作成して管理するをご覧ください。

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

プライマリ クラスタで障害が発生した場合、Cloud DNS はヘルスチェックとフェイルオーバー ポリシーに基づいて、トラフィックをセカンダリ リージョン クラスタに自動的にリダイレクトします。

セカンダリ クラスタがリードレプリカからプライマリにプロモートされると、アクティブ サイトとして引き継ぎ、本番環境のトラフィックを処理します。このプロモーションは、データベースの書き込みを受け入れるために必要です。

Cloud SQL の DR を設定するには、 Google Cloud SQL の障害復旧のドキュメントに記載されている手順に沿って操作します。 非同期データベースまたはストレージ レプリケーションを使用すると、RPO がゼロ以外になり、アプリケーションが最新の書き込みの損失を許容できるようになります。 別のレプリケーション方法の使用を検討してください。

シークレットの安全な管理

データベース パスワード、API キー、TLS 証明書などのシークレットは、DR の重要な要素です。これらのシークレットを新しいクラスタで安全かつ確実に復元できる必要があります。

シークレット管理の一般的なアプローチは次のとおりです。

  • 外部シークレットを使用する: 外部シークレット オペレーターなどのツールを使用して、Google Secret Manager からシークレットを pull します。
  • OADP Operator でシークレットをバックアップする: 外部 ストアを使用しない場合は、シークレットがバックアップに含まれていることを確認します。
  • 定期的なローテーション: シークレットを定期的にローテーションし、シークレット管理戦略が DR シナリオに対応していることを確認します。
  • テスト: ステージング済みの環境でシークレットの復元をテストし、提供された認証情報ですべてのサービスを開始できることを確認します。
  • 検証: DR クラスタに、外部ストアからシークレットを取得するために必要な IAM ロールまたは認証方法があることを検証します。

ネットワーキングとトラフィックの管理

Google Cloudのグローバル外部 HTTPS ロードバランサをプライマリの Ingress ポイントとして使用して、複数の OpenShift クラスタ（プライマリ クラスタとセカンダリ クラスタなど）間でトラフィックを分散します。このグローバル サービスは、近接性、健全性、可用性に基づいて、ユーザー リクエストを適切なバックエンド クラスタに転送します。

グローバル ロードバランサを OpenShift クラスタに接続するには、次のいずれかの方法を使用します。

  • リージョン ロードバランサ（インターネット NEG）を使用する: 各 OpenShift クラスタの Ingress サービス（OCP ルーター）を公開するリージョン ロードバランサの外部 IP アドレスを指すようにGoogle Cloud インターネット ネットワーク エンドポイント グループ（NEG）を構成します。グローバル ロードバランサは、これらのリージョン ロードバランサの IP にトラフィックをルーティングします。このアプローチでは抽象化レイヤが提供されますが、追加のネットワークへのホップが発生します。
  • Pod の直接ルーティング（Compute Engine_VM_IP_PORT NEGs）: OpenShift Ingress Controller のインテグレーションを構成して、Compute Engine_VM_IP_PORT タイプの Google Cloudネットワーク エンドポイント グループ（NEG）を使用します。このアプローチにより、グローバル ロードバランサは、内部 PodIP:TargetPort を使用して OpenShift Ingress Controller（ルーター）Pod を直接ターゲットにできます。この方法では、余分なホップと追加のノードプロキシをバイパスします。通常、レイテンシが短縮され、グローバル ロードバランサからのより直接的なヘルスチェックが可能になります。

どちらの構成でも、グローバル ロードバランサは異なるリージョンのクラスタ間でトラフィックの分散を効果的に管理できます。詳細については、外部バックエンドを使用してグローバル外部アプリケーション ロードバランサを設定するをご覧ください。

VPC

VPC の管理には、次のアプローチをおすすめします。

  • 共有 VPC: 共有 VPC を使用して、プライマリ クラスタとセカンダリ クラスタの両方のネットワーク管理を一元化します。この方法を使用することで管理が簡素化され、リージョン間で一貫したネットワーク ポリシーを適用できます。
  • グローバル動的ルーティング: VPC 内でグローバル動的ルーティングを有効にして、リージョン間でルートを自動的に伝播し、クラスタ間のシームレスな接続を確保します。
  • カスタムモード VPC: カスタムモード VPC を使用し、クラスタが実行されるリージョンに特定のサブネットを作成します。これは、Compute Engine_VM_IP_PORT ルーティングなどのメソッドで必要な VPC ネイティブ Pod ネットワーキングで必要になることがよくあります。
  • VPC ネットワーク ピアリング: リージョンとクラスタごとに個別の VPC ネットワークを使用する必要がある場合は、VPC ネットワーク ピアリングを使用してリージョンとクラスタを接続します。

サブネットと IP アドレス

各リージョンにリージョン サブネットを作成して、ネットワーク セグメンテーションを維持し、IP アドレスの競合を回避します。

ルーティングの問題を防ぐため、リージョン間で IP 範囲が重複しないようにします。

Red Hat Service Mesh を使用したクラスタ間トラフィック

OpenShift はサービス メッシュの連携をサポートしています。これにより、複数の OpenShift クラスタにデプロイされたサービス間の通信が可能になります。この関数は、フェイルオーバーやデータ レプリケーション中にサービスがクラスタ間で通信する必要がある DR シナリオで特に役立ちます。

プライマリ クラスタとセカンダリ クラスタ間のサービス メッシュ連携を設定する方法については、 Red Hat のドキュメントをご覧ください。

デプロイ

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

次のステップ