Configuring a Hybrid Manager deployment across multiple data centers#
Postgresデータベースを複数のデータセンターに展開できるようにするには、最初にHMインストールを2つまたは3つの異なる地理的場所またはリージョンに展開し、 Hub & Spoke or Primary & Secondary architecture をサポートする必要があります。次に、これらのインストールを相互にリンクすると、単一のHMコンソールから管理できます。このガイドは、次のことに役立ちます。
すべてのHMインストール構成ファイルを作成し、展開します。
同じプロバイダー/オンプレミスファミリーで2つ以上のHMインストールHM Kubernetesクラスターを接続します。これらは異なる地理的リージョンにある場合があります。たとえば、プライマリと1つのセカンダリ、またはプライマリと2つのセカンダリを持つことができます。
オブジェクトストレージ同一の
edb-object-storageシークレットを調整するため、すべてのデータセンターでバックアップ/アーティファクトを使用できます。HM内部エージェントビーコンまたは
upm-beacon-agentを接続して、セカンダリが管理対象場所としてプライマリに登録し、そこでプロビジョニングできるようにします9445/TCP。一方のデータセンターにプライマリPostgresクラスターを使用し、他のデータセンターにレプリカPostgresクラスターを使用してPostgresトポロジを準備します。レプリカを昇格させることにより手動フェイルオーバーを実行します。
始める前に#
マルチDC手順を開始する前に、以下についてよく理解してください。
前提条件#
アーキテクチャの前提条件#
このマルチDCセットアップは、単一のプライマリが複数のリーンセカンダリを管理するハブアンドスポークモデルに従います。
ハブクラスター プライマリHMをホストする1つのKubernetesクラスター。このクラスターは、中央の管理プレーンおよびUIとして機能します。
スポーククラスター セカンダリHMをホストする1つまたは2つのKubernetesクラスター。これらは、データベースワークロードの実行ポイントとして機能します。
ネットワーク接続
8444/クラスター間でオープンしたTCP SPIREバンドルエンドポイント.
9445/セカンダリ→プライマリからのTCP Beacon gRPC.
同じプロバイダー/オンプレミスファミリー(クロスクラウドなし)。
共有オブジェクトストレージ 標準のHMインストールでは、個々のKubernetesクラスターHMインストールに専用のオブジェクトストレージが必要です。マルチDC展開の場合、このオブジェクトストレージはすべてのクラスターで共有されます。
必要な情報を収集する#
HMインストール構成ファイルのコピーを2つまたは3つ準備します。 2つの場所に展開する場合は
primary.yaml、secondary.yaml、3つの場所に展開する場合はprimary.yaml、secondaryA.yaml、およびsecondaryB.yamlと名前付けます。これらのファイルはHybridControlPlaneCRマニフェストです。ドメイン名
各HMインストールは、専用のドメイン名で構成し、構成でportal_domain_name
として設定する必要があります。このパラメーターは、プライマリとセカンダリで使用されます。
各HMインストール構成に応じて2つまたは3つのインストールごとにこれらのドメイン名を作成し、この情報を記録します。
場所をまたがるオブジェクトストレージ#
HMは、バックアップ、アーティファクト、WAL、および内部バンドルにオブジェクトストアを使用します。 マルチDCでは、すべてのHMインストールが同じオブジェクトストア構成を使用する必要があります 。
キー要件#
すべてのHMインストールには、デフォルトの名前空間にedb-object-storage
という名前の同一のKubernetesシークレットが必要です。
2つの場所で実行している場合、このシークレットはプライマリとセカンダリに保存します。
3つのデータセンターがある場合、このシークレットをプライマリおよびセカンダリの場所に保存します。
パラメーターの一意性#
このマルチデータセンター展開に関係する2つまたは3つのクラスターは同じオブジェクトストアを使用しているため、すべてのクラスターで特定のパラメーターが異なることを確認する必要があります。
Parameter |
CR path |
Requirement |
Why it matters |
|---|---|---|---|
beacon_location_id |
spec.componentsParameters.upm-beacon.beacon_location_id |
Must be unique per location. |
Human-readable location identifier. Identifies the specific location in the HM console and API. |
internal_backup_folder |
spec.globalParameters.internal_backup_folder |
Must be unique per location AND match the format: ^[0-9a-z]{12}$. |
Separates database backups so that a restore doesn't pull the wrong data. |
metrics_storage_prefix |
spec.globalParameters.metrics_storage_prefix |
Must be unique per location. |
Ensures observability data from each site is stored in its own directory. |
logs_storage_prefix |
spec.componentsParameters.upm-loki.logs_storage_prefix |
Must be unique per location. |
Prevents logs from different locations from overwriting each other in shared storage. |
マルチDCトポロジの構成#
この手順では、ハブアンドスポーク関係を定義します。ハブプライマリはそのすべてのスポークセカンダリについて知っている必要があり、各スポークはハブに到達する方法を知っている必要があります。
次のスタンザを各構成ファイル primary.yaml およびsecondary.yaml
に追加します。 HMインストールごとに前に設定したportal_domain_name
を使用して、domainName 値を入力します。
primary.yaml で ロールprimary
を設定します。このクラスターはハブとして機能します。
secondary.yaml で ロールsecondary
を設定します。このクラスターはスポークとして機能し、
primary.domainName を使用してマネージャーを見つけます。
各HybridControlPlane CRのspec の下にclusterGroups
スタンザを追加します。
apiVersion: edbpgai.edb.com/v1alpha1
kind: HybridControlPlane
metadata:
name: edbpgai
spec:
clusterGroups:
# Set to primary for your Hub, secondary for your Spokes
role: (secondary|primary|standalone)
primary:
domainName: <primary portal domain>
secondaries:
- domainName: <secondary portal domain>
# Add an additional entry here for additional locations
# ... your other spec fields
コンポーネントのセットの削減スポーククラスターのみ#
HMは多数の異なるコンポーネントで構成されており、セカンダリの場所では必要ないものもあります。フルセットをセカンダリの場所に正常にインストールできますが、パラメーターscenarios
をcore
のみに設定し、HMコンソールUIを無効にすることにより、そのリストを削減することをお勧めします。
次のパラメーターをセカンダリロケーションの構成ファイルに追加します。
apiVersion: edbpgai.edb.com/v1alpha1
kind: HybridControlPlane
metadata:
name: edbpgai
spec:
scenarios:
- core
disabledComponents:
- upm-ui
# ... your other spec fields
検証チェックリスト
edb-object-storageシークレットは、すべての場所で同一である必要があります。データのみを比較。すべての場所でバケットをリスト/書き込みできます簡単なポッド/ジョブテスト。
beacon_location_id、internal_backup_folder、metrics_storage_prefix、およびlogs_storage_prefixは以下である必要がありますロケーションごとに一意。scenariosは、セカンダリロケーションのcoreに設定されています。disabledComponentsには、セカンダリロケーション用にリストされたupm-uiコンポーネントがあります。
Hybrid Managerのインストール#
構成ファイルprimary.yaml およびsecondary.yaml
、または3か所のセットアップの場合はprimary.yaml
、secondaryA.yaml およびsecondaryB.yaml
を使用して、各クラスターにハイブリッドマネージャーをインストールします。完全なインストール手順については、
フェーズ5ハイブリッドマネージャーのインストール に従ってください。
配線の検証#
インストールが完了したら、ハブアンドスポークリンクを確認します。
プライマリで、管理対象のセカンダリの場所をリストします。
kubectl get location
各管理ロケーションは、 managed-<LOCATION_ID> managed-primary
およびmanaged-secondary などの名前付けの行として表示され、
LOCATIONID の下にロケーションIDがあり、最近のLASTHEARTBEAT
があります。
NAME SCOPE LOCATIONID LASTHEARTBEAT
managed-primary managed primary 2026-01-15T10:30:00Z
managed-secondary managed secondary 2026-01-15T10:30:00Z
SPIREフェデレーションがすべての場所に存在することを確認します。
edb_notranlate_4 bundle endpoint profile: https_spiffe
およびピアの:8444
URLとの関係ピア信頼ドメインを示すfederation list が表示されます。
プライマリでは、フェデレーションリストに1つまたは2つのエントリセカンダリごとに1つ表示されます。
各セカンダリインスタンスには、1つのエントリプライマリへの関係のみが表示されます。
さまざまなデータセンターにまたがってPostgresデータベースクラスターを作成する#
HMはセカンダリの場所にプロビジョニングできるようになりましたが、実際のデータベーストポロジを選択して作成する必要があります。 HMコンソールで、データベースクラスターを作成し、データベースノードごとに異なる場所を選択してください。
シングルノードおよび高可用性データベースクラスターの場合、 リージョンをまたがってボリュームスナップショットリカバリーを使用する場合、レプリカクラスターの作成が失敗する 中に、 **Replica Clusters** tab を使用して他の場所にレプリカデータベースクラスターを追加します。
高度な高可用性および分散高可用性データベースクラスターの場合、 リージョンをまたがってボリュームスナップショットリカバリーを使用する場合、レプリカクラスターの作成が失敗する 中に、 **Data Groups** tab > **Node Settings** > **Deployment Location** オプションを使用してクラスターデータグループを場所を超えて分散します。
- !!!note PGDのWitnessノードには、少なくとも10GBのディスク領域が必要です。 .. ::
バックアップが両方のデータセンターから共有オブジェクトストアに書き込まれていることを確認します。
操作上の注意事項#
DB TLSは、SPIRE / BeaconプラットフォームIDとは別です。ポリシーごとにPG TLSを構成します。
各DCのストレージクラスがPG IOPS/レイテンシーを満たしていることを確認します。
サイト間でレプリケーションポートを開きます。
検証エンドツーエンド#
プライマリロケーションで、次のチェックを実行して、マルチDCセットアップを検証します。
プライマリ/セカンダリクラスターの関係を検証します。
kubectl -n spire-system exec svc/spire-server -c spire-server -- \
/opt/spire/bin/spire-server federation list
セカンダリの場所が登録されていることを確認します。
kubectl get location
セカンダリへのプロビジョニングを検証する
プライマリから、小規模なテストワークロードをセカンダリの場所に展開します。 - テレメトリオプショナル Thanosストアはフェデレーションピアを表示します。 Lokiクエリーは、secondary. - オブジェクトストレージからタグ付けされたログを返します どちらのクラスターもバケットの読み取り/書き込みができます。シークレットは同じです。
手動フェイルオーバー#
プライマリロケーションからセカンダリロケーションへのデータベースの手動フェイルオーバー手順#
プライマリロケーションへの書き込みを一時停止しますメンテナンスモード/LBカットオーバー。
セカンダリの場所のレプリカをプライマリに昇格させますHMコンソールまたはスクリプトを使用して。
クライアントDNS / LBをセカンダリの場所にリダイレクトします。
観察 書き込みが成功したことを確認します。そして、レプリケーションロールが更新されます。
プライマリロケーションが元に戻ったら、新しいプライマリのレプリカとして再シードします。オプションで、後の削減を計画します。
!!!note セカンダリDCでPostgresデータベースを昇格させている間、HMコンソール自分自身はプライマリで実行されたままです。プライマリDCHMが存在する場所が完全になくなった場合は、 HM disaster recovery guide に従って、他の場所で管理コンソールを復元します。
カットオーバーのためにDNS TTLを十分に低く保ちます。
ダウンタイムを追跡してRTOを測定します。
プロモーション後のバックアップを検証します。
障害対応#
問題 フェデレーション関係がありません
再生成およびクロス適用
ClusterFederatedTrustDomainCRs.8444 / TCPの到達可能性を確認します。
問題 ``kubectl get location`` にリストされていないセカンダリ
両側のビーコン値を再確認します。再起動 Beacon server/agent.
プライマリポータルへの9445/TCPの到達可能性を確認します。トラストドメインが正しいです。
問題 セカンダリ
でオブジェクトストアアクセスが失敗する 再同期
edb-object-storage.EKS / IRSAの場合 セカンダリOIDCがロールの信頼ポリシーに含まれていることを確認します。
問題 テレメトリフェデレーションがありません
正しい-lプライマリ|セカンダリフラグと一意のプレフィックスで再インストールします。
Thanos
/api/v1/storesおよびLoki読み取りAPIを確認します。
問題 レプリカの遅延/接続 - ネットワークACL / SG、TLS証明書、およびストレージパフォーマンスを確認します。
付録B — 簡単な日常チェック#
プライマリの
kubectl get locationは、セカンダリの準備ができていることを示します。Thanos / Lokiフェデレーションは正常な場合有効な場合。
オブジェクトストアの書き込みは両方のDCから成功します。
SLO内のレプリケーションラグ。