Multi-DC for high availability

Multi-DC for high availability#

複数のデータセンターマルチDCにわたってハイブリッドマネージャーHMを展開すると、Postgresデータベースクラスターの高可用性とディザスターリカバリーが提供されます。この設定により、単一のインターフェイスから異なる地理的な場所にあるデータベースを管理できます。

!!!重要 これは、HMインストール自分自身のリカバリーを除きます。これは、 back up and restore separately する必要があります。

複数のデータセンターにHMを展開すると、Postgresデータベースクラスターの高可用性とディザスターリカバリーが得られます。それにより、次のことができます。

  • データベース損失DRを生き延びる — 1つまたは2つのウォームセカンダリPostgresデータベースを準備しておきます。プライマリデータセンターが利用できない場合は、セカンダリの場所でレプリカをプロモートし、サービスを復元します。

  • ダウンタイムRTOの最小化 —複数の地理的に分散した書き込みエンドポイントDHA Postgresクラスターを使用するか、迅速なフェイルオーバーシングルノード、HA、およびAHA Postgresクラスターを活用して、メンテナンスまたは計画外のサイトの停止中にサービスを迅速に復元します。

  • データの保護RPO - 2番目のデータセンターへの継続的レプリケーションにより、単一サイトのバックアップのみと比較して、潜在的なデータ損失が削減されます。

  • 爆風半径を縮小します —一方のデータセンターの障害、構成ミス、またはノイジーネイバーは、他方のデータセンターをダウンさせません。

  • コンプライアンス/主権を満たす —制御を集中させながら、特定の地域または施設にコピーを保持します。

  • 大規模な運用 —読み取りトラフィックを分割し、アップグレードを段階的に行うか、データセンター全体でブルー/グリーンのカットオーバーを実行します。

  • 一元管理—単一のプライマリHMがすべてのリモートKubernetesクラスターにわたってデータベースを管理し、地理的冗長性を提供しながら管理を簡素化します。

アーキテクチャとロール ハブアンドスポーク#

HMは、ハブアンドスポークモデルを使用して、マルチプルのデータセンターを管理します。コントロールプレーン管理ソフトウェアとデータプレーン実際のPostgresデータベースを区別することが重要です。

プライマリザ・ハブ#

プライマリロケーションは「真実のソース」であり、完全なHMコントロールプレーンがアクティブな唯一のサイトです。次のプロセスは、プライマリまたはハブが所有しています。

  • HMコンソールUI 単一のウィンドウ。プライマリのURLにログインして、すべてのリージョンのデータベースを管理します。

  • セントラルスケジューラー プライマリは、データベースノードが存在する場所を決定し、セカンダリにプロビジョニング指示を送信します。

  • IDプロバイダー SPIREの信頼のルートとして機能し、すべてのセカンダリの場所に安全なIDを発行します。

  • オブザーバビリティハブ ThanosとLokiを使用して、すべての場所からメトリックとログを単一のビューに集約します。

セカンダリスポーク#

セカンダリは、管理ではなく実行のために設計された「リーン」インストールです。これらは独自の独立したコンソールを実行しませんが、プライマリまたはハブからの通信と管理を促進するコンポーネントを実行します。

  • HM内部ビーコンエージェント UIの代わりに、セカンダリはHM内部ビーコンエージェントを実行します。このエージェントはプライマリにハートビートを返し、ローカルKubernetesリソースノード、ストレージを中央スケジューラーで利用できるようにします。

  • ローカル実行 クラスターをセカンダリの場所に展開すると、プライマリはセカンダリのローカルオペレータにPostgresポッドをプロビジョニングするように指示します。

データプレーンとストレージ#

コントロールプレーンはハブアンドスポークですが、データは環境全体で同期されたままです。

  • Postgresクラスター DC-AにプライマリPostgresクラスターを展開し、DC-BおよびDC-Cに非同期レプリカを展開できます。分散高可用性PGDの場合、データグループとWitnessノードを3つの場所すべてに分散できます。

  • ユニファイドストレージ すべての場所は、一貫したオブジェクトストア構成を共有する必要があります。これにより、あるデータセンターで生成されたバックアップとWALファイルは、別のデータセンターでリカバリーにすぐに利用できます。

トポロジ#

次のトポロジを使用してマルチDCセットアップを展開できます。

  • プライマリおよびデータのみのHM これは、1つのプライマリHMと少なくとも1つのデータ専用HMを使用した基本的なセットアップです。これにより、2つの場所にPostgresクラスターを展開できます。

  • 複数のデータ専用HMを使用した統合管理 単一のプライマリHMから複数のリモートKubernetesクラスターにわたってデータベースを管理します。このアーキテクチャは、各ターゲットの場所で軽量のデータ専用のフットプリントを維持しながら、統合されたコントロールプレーンを提供します。

  • PGD用の3つのHM 最適なPGD展開分散および高度な高可用性Postgresクラスター、特に2つのデータグループと1つの監視グループを使用する場合、3ロケーショントポロジをお勧めします。この構成により、適切な分散コンセンサスのためのクォーラムが保証されます。

復元力とフェイルオーバー#

データセンター全体でさまざまなデータベーストポロジを組み合わせて使用できるため、サイトに障害が発生した場合の影響は異なります。フェールオーバーは、ハイブリッドマネージャー環境全体を一度に実行するのではなく、データベースクラスターごとに実行されます。次にいくつかの例を示します。

Database topology

Setup

Recovery action

RTO (Time)

RPO (Data)

Single-Node

No replicas, located in DC-A.

Full restore: Must recreate the cluster from object storage/backup.

High: depends on DB size and restore speed.

Medium: Up to the last backup/WAL archive.

Single-Node + Replica

Single-node in DC-A, replica in DC-B.

Manual promotion: Promote the replica in DC-B to a standalone primary.

Low: is driven by runbook and DNS updates.

Very low: Seconds (based on async replication lag).

HA cluster

Primary/Replicas in DC-A, replica in DC-B.

Manual promotion: Promote the cross-DC replica in DC-B to primary.

Low: is driven by runbook and DNS updates.

Very low: Seconds (based on async replication lag).

DHA cluster

Data Groups in DC-A and DC-B, witness in DC-C.

Automatic: PGD maintains quorum; surviving nodes stay writable.

Near zero: Instant, limited only by DNS/LB TTL.

Zero: If using sync commit, otherwise near-zero.

リカバリーの違いは、マルチDCセットアップと、特定のデータベースクラスターごとに選択したトポロジの両方に依存します。

ローカルHAとマルチDCフェールオーバー ディザスターリカバリーの観点から、シングルインスタンスとHAクラスターは両方とも、プライマリサイトに障害が発生した場合、セカンダリの場所へのプロモーションが必要です。ただし、 HAクラスターローカルレプリカを使用すると、内部復元力が提供されます。同じデータセンター内のプライマリインスタンスの障害から自動的に復旧できます。ローカルスタンバイがない単一インスタンス展開では、データベースを完全に再起動するか、完全なクロスロケーションフェールオーバーを実行して、ローカルの中断から復旧する必要があります。

RTO目標復旧時間 これはダウンタイムです。手動プロモーションシングルノード+レプリカまたはHAクラスターの場合、RTOはフェールオーバープレイブックを実行できる速度によって制限されます。

RPO目標復旧ポイント これは、データの損失です。マルチDCの標準である非同期レプリケーションの場合、これは通常数秒のRPOになります。同期レプリケーションの場合、ゼロRPOを達成できますが、これにより、リモートデータセンターがデータを確認するのを待機するため、すべての書き込みに遅延が追加されます。

分散高可用性DHAクラスターのネットワーク遅延#

分散高可用性クラスターPGDを搭載したクラスターがコンセンサスの問題に対応する速さと、存在するネットワーク遅延の量の間には、固有のトレードオフがあります。レイテンシーが長くなると、より緩やかなコンセンサス設定が必要になり、障害の検出と対応に時間がかかる可能性があります。一部のRaft設定は、HMコンソールから直接構成できない場合があります。

リージョンをまたがるクラウド環境と比較して、オンプレミスの密結合環境では、遅延はあまり問題になりません。高レイテンシーシナリオに対応するように、よりリラックスしたRaft設定を構成できます。

pg CLIを使用して、クラスターと対話し、コンソールに公開されていない構成設定、特にRaft設定を調整できます。 bdr run on nodes ファンクションを使用して、他のノードでコマンドを実行します。

マルチDC環境のHMバックアップとDR#

HMは2つの方法を使用してデータを保護しますマルチDCセットアップでは、これらのロールは固有です。

Barman (Cross-DC) バックアップはグローバルオブジェクトストアに保存されます。これは、場所を超えたディザスターリカバリーのための主要なツールです。

ボリュームスナップショットローカル 特定のデータセンターにローカルなディスクベースのバックアップ。これらは、正常なサイト内での高速な「ポイントインタイム」リカバリーに使用します。

サイトの停止中にHybrid ManagerコントロールプレーンとPostgresデータベースの両方を復旧できるように保証には、以下を確認してください。

  • プライマリHMメタデータ構成、ユーザー、クラスター定義がバックアップされ、プライマリデータセンターの外部に保存されていることを確認します。

  • 共有バックアップにライブでアクセスするには、すべてのHMインスタンスプライマリおよびセカンダリに同一のedb-object-storage シークレットが必要です。

  • 場所ごとに automated backup schedules を個別に構成する必要があります。設定はサイト間で自動的に同期しません。

  • 組織は、プライマリサイトの停止のためにHMコンソールがダウンしている場合に restore a database using the CLI の方法を知っています。

現在の制限#

これらは、マルチDC展開の現在の制限です。

  • 最大3つの場所プライマリと1つのセカンダリ、またはプライマリと2つのセカンダリ。

  • 手動フェイルオーバー プライマリがダウンしている場合、セカンダリの場所のいずれかでレプリカを昇格させます。

  • 同じクラウド/オンプレミスファミリー クロスCSPマルチDCはサポートされていません。

目次