Configuring multiple data centers for Hybrid Manager

目次

Configuring multiple data centers for Hybrid Manager#

概要#

複数のデータセンターでハイブリッドマネージャーHMを実行する理由は何ですか?#

マルチDCは、 PostgresワークロードとHybrid ManagerHMコントロールプレーンCPの高可用性とディザスターリカバリーを提供します。

  • サイト損失DRの生き残り ウォームなセカンダリサイトの準備をしておきます。プライマリDCが利用できない場合は、セカンダリでレプリカをプロモートし、サービスを復元します。

  • ダウンタイムHAを最小限に抑える ワークロードがもう一方のサイトで継続されているときに、一方のサイトでメンテナンスまたは移行を実行します。

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

  • ブラスト半径を減らす 一方のDCの障害、構成ミス、またはノイジーネイバーは、他方のDCをダウンさせません。

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

  • 大規模な動作 読み取りトラフィックを分割したり、アップグレードをステージしたり、DC全体でブルー/グリーンのカットオーバーを実行したりします。

RTO/RPOの概要#

  • RTO サービスの復元時間 通常は分、プロモーション/カットオーバーランブックおよびDNS/LBの変更によって駆動されます。

RPOデータ損失ウィンドウ#

  • 非同期レプリケーションDC全体で共通 非常に低いですが、ゼロではありませんベストエフォート秒。

  • 同期レプリケーション 遅延依存 ゼロデータ損失に近づくことができますが、クロスDC遅延が追加され、堅牢な低遅延リンクが必要です。

このガイドが役立つこと#

  • 同じプロバイダー/オンプレミスファミリー上の2つのHMクラスタープライマリ↔セカンダリを接続します。

  • オブジェクトストレージ同一のedb-object-storageシークレットを調整して、バックアップ/アーティファクトを両方のDCで使用できるようにします。

  • SPIREフェデレーション8444/TCPを介したトラストドメインを有効にして、プラットフォームIDがクロスサイトで動作するようにします。

  • プライマリがセカンダリを管理対象場所として登録し、そこでプロビジョニングできるようにエージェントビーコンを配線します 9445/TCP

  • オプショナル クロスサイトメトリックとログのフェデレーションテレメトリThanos/Loki 。

  • 一方のDCにプライマリ、もう一方のDCにレプリカを使用してPostgresトポロジを準備します。レプリカを昇格させることにより手動フェイルオーバーを実行します。

電流制限#

  • 2つのサイトプライマリとセカンダリ。

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

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

アーキテクチャの概要#

  • コントロールプレーン 2つのHMクラスター、SPIREを介してフェデレーション。プライマリは、ビーコンを介してロケーションとしてセカンダリを「管理」します。

  • データノード DC-AのPostgresプライマリ、DC-Bのレプリカデフォルトで非同期。

  • ストレージ バックアップ/アーティファクトのためのサイト全体での共有/一貫したオブジェクトストア構成。

  • テレメトリオプショナル サイト全体でメトリック/ログを表示するためのThanos/Lokiフェデレーション。

これは誰に向けたものですか?#

これは、単一のDCが提供できるよりも高い復元力を必要とし、明確に定義されたRTO / RPO目標を使用して手動でリハーサルされたフェイルオーバープレイブックを実行することに慣れているチーム向けです。

前提条件#

アーキテクチャの前提条件#

  • 2つのHMクラスターが使用できますプライマリとセカンダリKubernetesコンテキスト構成済み。

  • 各クラスターには、一意のSPIRE信頼ドメインがあります。

  • ネットワーク接続

    • 8444/TCPクラスター間でオープンSPIREバンドルエンドポイント。

    • 9445/セカンダリ→プライマリからのTCPビーコンgRPC.

    • ツール: kubectl、jq、およびYAMLをローカルで編集する場合はyq.

    • 同じプロバイダー/オン-premファミリークロスクラウドなし。

  • ツール - jq 、yq 、AWSコマンドライン

  • スクリプト - この手順全体で使用を参照するスクリプトが多数あります。スクリプトにアクセスするには、 EDB Professional Services または EDB Support Center に連絡してください。

必要な環境変数を検出して設定する#

  1. kubectl に、どのクラスターがプライマリとセカンダリであるかを指示します

後続のすべての検出コマンドで使用するkubeコンテキストを設定します。

export KUBE_CONFIG_PRIMARY_CONTEXT="<primary-kube-ctx-or-arn>"
export KUBE_CONFIG_SECONDARY_CONTEXT="<secondary-kube-ctx-or-arn>"

  1. プライマリポータルのFQDNを検出しますビーコン/テレメトリによって使用されます

プライマリクラスターでビーコンゲートウェイホストを照会し、PRIMARY_PORTAL_URL としてエクスポートします。

export PRIMARY_PORTAL_URL="$(
kubectl --context "$KUBE_CONFIG_PRIMARY_CONTEXT" \
    -n upm-beacon get gw beacon-server -o json \
| jq -r .spec.servers[1].hosts[0]
)"

  1. (オプション)セカンダリポータルのFQDNを検出する

テレメトリもフェデレートする場合は、セカンダリポータルホストをSECONDARY_PORTAL_URL としてキャプチャし、それに応じて環境変数を設定します。

export SECONDARY_PORTAL_URL="$(
kubectl --context "$KUBE_CONFIG_SECONDARY_CONTEXT" \
    -n upm-beacon get gw beacon-server -o json \
| jq -r .spec.servers[1].hosts[0]
)"

  1. プライマリのビーコンgRPCエンドポイントを導き出す

ビーコンは、プライマリポータルホストの:9445 でリッスンします。

export BEACON_SERVER_ENDPOINT_PRIMARY="${PRIMARY_PORTAL_URL}:9445"

  1. プライマリのSPIRE信頼ドメインを検出します

プライマリからSPIREサーバー構成を読み取り、 TRUST_DOMAIN_PRIMARY をエクスポートします。

export TRUST_DOMAIN_PRIMARY="$(
kubectl --context "$KUBE_CONFIG_PRIMARY_CONTEXT" \
    -n spire-system get cm spire-server \
    -o jsonpath="{[data][server\.conf]}" \
| jq -r .server.trust_domain
)"

  1. セカンダリのSPIRE信頼ドメインを検出します

セカンダリでも同じことを行い、TRUST_DOMAIN_SECONDARY をエクスポートします。

export TRUST_DOMAIN_SECONDARY="$(
kubectl --context "$KUBE_CONFIG_SECONDARY_CONTEXT" \
    -n spire-system get cm spire-server \
    -o jsonpath="{[data][server\.conf]}" \
| jq -r .server.trust_domain
)"

  1. 管理対象セカンダリの場所のラベルを選択します

任意の一意のラベルを選択しますプライマリでmanaged-<label> として表示されます。

export SECONDARY_LOCATION_NAME="secondary"

  1. (EKS / IRSAヘルパーのオプション) EKS識別子を設定します

ヘルパーを使用してS3信頼ポリシーを更新し、オブジェクトストアシークレットをコピーする場合にのみこれを行います。このステップには、PRIMARY_EKS 、SECONDARY_EKS 、およびAWS_PROFILE が必要です。

export PRIMARY_EKS="<region>:<primary-eks-name>"
export SECONDARY_EKS="<region>:<secondary-eks-name>"
export AWS_PROFILE="<aws-profile>"

  1. 続行する前のサニティチェック

キー変数が設定されていることを確認します欠品している場合はエラーになります。

: "${KUBE_CONFIG_PRIMARY_CONTEXT:?}"; : "${KUBE_CONFIG_SECONDARY_CONTEXT:?}"
: "${PRIMARY_PORTAL_URL:?}"; : "${BEACON_SERVER_ENDPOINT_PRIMARY:?}"
: "${TRUST_DOMAIN_PRIMARY:?}"; : "${TRUST_DOMAIN_SECONDARY:?}"
: "${SECONDARY_LOCATION_NAME:?}"

以下は、テレメトリーまたはEKSヘルパーを実行する場合のオプションのチェックです。

: "${SECONDARY_PORTAL_URL:?Set if doing telemetry federation}" || true
: "${PRIMARY_EKS:?Set if using EKS helper}" || true
: "${SECONDARY_EKS:?Set if using EKS helper}" || true
: "${AWS_PROFILE:?Set if using EKS helper}" || true

注釈

後で新しいシェルを開くか、新しいCIステップを実行する場合、これらのエクスポートを再実行しますまたはファイルに保存してソースします。

場所をまたがるオブジェクトストレージ#

HMは、バックアップ、アーティファクト、WAL、および内部バンドルにオブジェクトストアを使用します。 マルチDCでは、両方のクラスターが同じオブジェクトストア構成を使用する必要があります 。

キー要件#

各クラスターには、デフォルトの名前空間にedb-object-storage という名前の同一のKubernetesシークレットが必要です。

注釈

セカンダリの場所にHMをインストールする前に、edb-object-storage を作成/同期します。

プライマリのインストール中にオブジェクトストレージを設定するときに、初期シークレットを作成します。これをセカンダリに複製します。

#  Clean slate on Secondary

kubectl delete secret \
- -context=$KUBE_CONFIG_SECONDARY_CONTEXT \
- n default edb-object-storage || true

#  Copy Primary → Secondary

kubectl get secret \
- -context=$KUBE_CONFIG_PRIMARY_CONTEXT \
- n default edb-object-storage -o yaml | \
kubectl apply \
- -context=$KUBE_CONFIG_SECONDARY_CONTEXT \
- n default -f -

EKS IRSAトラストポリシー#

サービスアカウントIRSAのS3 + IAMロールを使用する場合、ロールは両方のクラスターのOIDCプロバイダーを信頼する必要があります。

  1. 信頼ポリシーを手動で更新して両方のOIDC発行者を含める、または

  2. ヘルパーobject-storage-on-multi-dc.sh ヘルパースクリプトを取得します。

  3. ヘルパースクリプトを使用してシークレットをコピーし、OIDCプロバイダーをロールの信頼ポリシーに自動的に追加します。

./object-storage-on-multi-dc.sh \
-p <region>:<primary-eks-name> \
-s <region>:<secondary-eks-name>[,<region>:<another-eks>] \
-a <aws-profile>

object-storage-on-multi-dc.sh ヘルパースクリプトは、プライマリのedb-object-storageシークレットからIAMロールARNを読み取り、同じシークレットを各セカンダリにコピーし、セカンダリクラスターのOIDCプロバイダーがロール信頼ポリシーにない場合は追加します。

  1. 検証チェックリスト

    • シークレットは同一です .dataのみを比較します。

    • 両方のクラスターはバケットをリスト/書き込むことができます簡単なポッド/ジョブテスト。

    • IRSAロールの信頼には、両方のOIDCプロバイダーEKSの場合が含まれます。

セットアップオプション#

オプションAワンショットまたはオプションBステップバイステップを選択します。同じ最終状態に到達します。

オプションA — クイックスタートマスタースクリプト#

マスタースクリプトは、オブジェクトストレージ同期、SPIREフェデレーション、ビーコン配線、およびオプションのテレメトリを1つのパスで実行します。

  1. master-install.sh スクリプトを取得します。

  2. 次のスクリプトを実行します。

cd scripts/multi-dc
./master-install.sh

  1. 便利なフラグ

./master-install.sh --dry-run \
--skip-object-store --skip-federation --skip-beacon --skip-telemetry

  1. 確認します。

  • SPIREフェデレーションがリストされていることを確認します。

kubectl -n spire-system exec svc/spire-server -c spire-server -- \
/opt/spire/bin/spire-server federation list

  • プライマリに登録されたセカンダリの場所を確認する

kubectl get location

オプションB — 手動セットアップ 詳細/カスタマイズ可能#

必要なスクリプトを取得します#

マルチDCを手動でセットアップするには、これらのスクリプトを取得する必要があります。

  • update_objectstore_secrets.sh

  • apply-federated-domain.sh

  • configure-beacon-primary.sh

  • configure-beacon-secondary.sh

  • install.sh テレメトリーフェデレーションを設定する場合

スクリプトを実行してマルチDCをセットアップする#

これらのスクリプトを次の順序で実行します。

  • update_objectstore_secrets.sh

  • apply-federated-domain.sh

  • configure-beacon-primary.sh

  • configure-beacon-secondary.sh

  • install.sh テレメトリーフェデレーションを設定する場合

  1. オブジェクトストレージの同期

./update_objectstore_secrets.sh
# (EKS only, if IRSA)
./eks-object-storage-on-multi-dc.sh -p $PRIMARY_EKS -s $SECONDARY_EKS -a $AWS_PROFILE

  1. SPIREフェデレーション

./apply-federated-domain.sh $KUBE_CONFIG_PRIMARY_CONTEXT $KUBE_CONFIG_SECONDARY_CONTEXT

  1. 検証します。

kubectl -n spire-system exec svc/spire-server -c spire-server -- \
/opt/spire/bin/spire-server federation list

  1. ビーコンの配線

./configure-beacon-primary.sh   $TRUST_DOMAIN_SECONDARY
./configure-beacon-secondary.sh $BEACON_SERVER_ENDPOINT_PRIMARY $TRUST_DOMAIN_PRIMARY $SECONDARY_LOCATION_NAME

  1. 検証します。

kubectl get location

  1. オプションのテレメトリーフェデレーション

cd thanos && ./install.sh -l secondary -p $PRIMARY_PORTAL_URL -s $SECONDARY_PORTAL_URL
./install.sh -l primary  -p $PRIMARY_PORTAL_URL -s $SECONDARY_PORTAL_URL

cd ../fluent-bit && ./install.sh -l primary -p $PRIMARY_PORTAL_URL -s $SECONDARY_PORTAL_URL
./install.sh -l secondary -p $PRIMARY_PORTAL_URL -s $SECONDARY_PORTAL_URL

SPIREフェデレーションの詳細what/why/how#

SPIREフェデレーションにより、各SPIREサーバーはピア信頼ドメインを信頼し、そのバンドルを継続的に更新できます8444/TCPが必要です。 CRDまたはspire-serverフェデレーションCLIを介して構成できます。

一般的なフローCRDベース

  • 各クラスターからClusterFederatedTrustDomainマニフェストを生成しますヘルパースクリプト。

  • それらをクロス適用しますA→B、B→A。

  • spire-serverフェデレーションリストで検証します。

フェデレーション後 サイトを越える必要があるワークロードIDには、federatesWith: "<peer-trust-domain>" を持つClusterSPIFFEID が必要です。

ビーコン構成プライマリ&セカンダリ#

ビーコンにより、プライマリHMはセカンダリを管理対象「ロケーション」として登録し、そこでプロビジョニングできます。

プライマリ: セカンダリの信頼ドメインを許可します#

  1. 現在の値をエクスポートして編集します。

kubectl get configmap -n edbpgai-bootstrap -l app=edbpgai-bootstrap -o yaml \
| yq .items[0].data["values.yaml"] > /tmp/primary-boot-values.yaml

  1. /tmp/primary-boot-values.yamlを編集します。

beaconServer:
additionalTrustDomains:
    - "<secondary-location-trust-domain>"

  1. エージェントビーコンインストールスクリプトinstall-dev.sh を取得します。

  2. ビーコンを再インストールします。

./install-dev.sh -f <provider> -a install -c upm-beacon -v <beacon-version> -p /tmp/primary-boot-values.yaml

セカンダリ:エージェントをプライマリビーコンにポイントします#

  1. セカンダリから

kubectl get configmap -n edbpgai-bootstrap -l app=edbpgai-bootstrap -o yaml \
| yq .items[0].data["values.yaml"] > /tmp/secondary-boot-values.yaml

  1. /tmp/secondary-boot-values.yaml を編集します。

parameters:
upm-beacon:
    beacon_location_id: "secondary"   # unique label
beaconAgent:
beaconServerAddress: "<primary-portal-fqdn>:9445"
beaconServerTrustDomain: "<primary-trust-domain>"
plaintext: false
tlsInsecure: false
inCluster: false

  1. エージェントビーコンインストールスクリプトinstall-dev.sh を取得します。

  2. ビーコンを再インストールします。

./install-dev.sh -f <provider> -a install -c upm-beacon -v <beacon-version> -p /tmp/secondary-boot-values.yaml

フェデレートエージェントビーコンSPIFFE ID必須#

  1. federate-beacon-spiffe-ids.sh スクリプトを取得します。

  2. セカンダリから実行プライマリ信頼ドメインを含む

./federate-beacon-spiffe-ids.sh "$TRUST_DOMAIN_PRIMARY"
kubectl rollout restart -n upm-beacon deploy/upm-beacon-server
kubectl rollout restart -n upm-beacon deploy/upm-beacon-agent-k8s

  1. プライマリから実行しますセカンダリ信頼ドメインを含む

./federate-beacon-spiffe-ids.sh "$TRUST_DOMAIN_SECONDARY"
kubectl rollout restart -n upm-beacon deploy/upm-beacon-server
kubectl rollout restart -n upm-beacon deploy/upm-beacon-agent-k8s

  1. 登録の検証プライマリ

kubectl get location
# Expect: managed-<SECONDARY_LOCATION_NAME> with recent LASTHEARTBEAT

テレメトリーフェデレーションオプショナル#

クロスサイトのメトリック/ログが必要な場合

Thanosメトリック#

  1. Thanosインストールスクリプトinstall.sh を取得します。

  2. セカンダリ

./install.sh -l secondary -p $PRIMARY_PORTAL_URL -s $SECONDARY_PORTAL_URL

  1. プライマリ:。

./install.sh -l primary -p $PRIMARY_PORTAL_URL -s $SECONDARY_PORTAL_URL

  1. 検証しますポートフォワードthanos-query を検証し、 thanos-query-federated を含むエントリの/api/v1/stores をヒットします。

Fluent Bit/Lokiログ#

  1. Lokiインストールスクリプトinstall.sh を取得します。

  2. プライマリ

./install.sh -l primary -p $PRIMARY_PORTAL_URL -s $SECONDARY_PORTAL_URL

  1. セカンダリ

./install.sh -l secondary -p $PRIMARY_PORTAL_URL -s $SECONDARY_PORTAL_URL

  1. ポートフォワードloki-read を検証し、{app="fluent-forward"} を照会します。

注釈

メトリックとログの値に個別の接頭辞を使用します。

  • “global.metrics_storage_prefix”

  • “upm-loki.logs_storage_prefix”

目標 ワイヤビーコンにより、プライマリHMはセカンダリを管理対象として扱うことができ、DC全体にPGプライマリ/レプリカをプロビジョニングできます。

前提条件の概要#

  • SPIREフェデレーションが既に構成されている2つのHM Kubernetesクラスター同じプロバイダー/オンプレミスファミリー。

  • 共有オブジェクトストアedb-object-storageシークレットは、両方のクラスターに存在および同一です。

  • オープンネットワーク 8444/TCP SPIREバンドルエンドポイント、9445/TCP Beacon gRPC、およびPostgresレプリケーションポート。

  • インストールされるツールjq 、yq 。

重要な値を検出します特記事項にある各クラスターに対して実行します。#

  1. ビーコンが使用するプライマリポータルホストを取得する 追加9445

kubectl get gw beacon-server -n upm-beacon -o json \
| jq -r .spec.servers[1].hosts[0]

  1. 信頼ドメインの取得各クラスターで実行

kubectl get cm spire-server -n spire-system -o jsonpath="{[data][server\.conf]}" \
| jq -r .server.trust_domain

再利用する環境変数をエクスポートします。#

export KUBE_CONFIG_PRIMARY_CONTEXT="<primary-kube-ctx-or-arn>"
export KUBE_CONFIG_SECONDARY_CONTEXT="<secondary-kube-ctx-or-arn>"

export TRUST_DOMAIN_PRIMARY="<primary-trust-domain>"
export TRUST_DOMAIN_SECONDARY="<secondary-trust-domain>"

export BEACON_SERVER_ENDPOINT_PRIMARY="<primary-portal-fqdn>:9445"
export SECONDARY_LOCATION_NAME="secondary"     # any unique label

Multi-DC Beacon Helmのインストールプライマリ#

  1. プライマリの現在のvalues.yaml を抽出します。

kubectl get configmap -n edbpgai-bootstrap -l app=edbpgai-bootstrap -o yaml \
| yq eval .items.0.data["values.yaml"] > /tmp/primary-boot-values.yaml

  1. /tmp/primary-boot-values.yaml を編集して、セカンダリ信頼ドメインを許可します。

beaconServer:
# ...
additionalTrustDomains:
    - "<secondary-location-trust-domain>"

  1. プライマリへのビーコンのインストール/再インストール例

./install-dev.sh -f <provider> -a install -c upm-beacon -v <upm-beacon-version> -p /tmp/primary-boot-values.yaml

マルチDCビーコンHelmインストールセカンダリ#

  1. 現在のvalues.yaml for セカンダリを抽出します。

kubectl get configmap -n edbpgai-bootstrap -l app=edbpgai-bootstrap -o yaml \
| yq eval .items.0.data["values.yaml"] > /tmp/secondary-boot-values.yaml

  1. /tmp/secondary-boot-values.yaml を編集して、このクラスターを管理対象場所として登録し、エージェントをプライマリにポイントします。

parameters:
upm-beacon:
    # name can be anything, just not the same as Primary
    beacon_location_id: "secondary"

beaconAgent:
beaconServerAddress: "<primary-portal-fqdn>:9445"
beaconServerTrustDomain: "<primary-trust-domain>"
plaintext: false
tlsInsecure: false
inCluster: false

  1. セカンダリにビーコンをインストール/再インストールします。

./install-dev.sh -f <provider> -a install -c upm-beacon -v <upm-beacon-version> -p /tmp/secondary-boot-values.yaml

ビーコンクラスターSPIFFEIDフェデレーション両方向#

DCを横断する各ビーコンSPIFFE IDには、federatesWith にピア信頼ドメインを含める必要があります。

両方のクラスターでヘルパースクリプトを使用します。

  1. セカンダリからプライマリ信頼ドメインを追加します。

./federate-beacon-spiffe-ids.sh "$TRUST_DOMAIN_PRIMARY"

kubectl rollout restart -n upm-beacon deploy/upm-beacon-server
kubectl rollout restart -n upm-beacon deploy/upm-beacon-agent-k8s

  1. プライマリからセカンダリ信頼ドメインを追加します。

./federate-beacon-spiffe-ids.sh "$TRUST_DOMAIN_SECONDARY"

kubectl rollout restart -n upm-beacon deploy/upm-beacon-server
kubectl rollout restart -n upm-beacon deploy/upm-beacon-agent-k8s

スクリプトは、ビーコンクラスターSPIFFEIDオブジェクトを見つけ、欠落している場合はfederatesWithリストを作成し、ピア信頼ドメインが存在しない場合は追加します。

配線の検証#

  1. プライマリ上 管理対象セカンダリの場所をリストする必要があります

kubectl get location

  1. 各クラスターに存在するSPIREフェデレーションを検証する

kubectl -n spire-system exec svc/spire-server -c spire-server -- \
/opt/spire/bin/spire-server federation list

  1. 予想されること

  • kubectl get location は、 managed-<SECONDARY_LOCATION_NAME> と最近のLASTHEARTBEAT を表示します。

  • federation list は、 bundle endpoint profile: https_spiffe およびピアの:8444 URLとの1つの関係ピア信頼ドメインを示します。

クロスDC Postgresトポロジを作成する#

この時点で、HMはセカンダリの場所にプロビジョニングできます。 実際のDBトポロジを選択して作成することもできます。

一般的なフロー#

  1. プライマリHMから、プライマリDCにPostgresプライマリを作成します。

  2. プライマリHMから、セカンダリDCにレプリカクラスターを作成します管理対象セカンダリの場所を選択します。

  3. レプリケーションモード同期/非同期を確認し、レプリケーションラグがSLOを満たしていることを監視します。

  4. バックアップが両方のDCから共有オブジェクトストアに書き込まれていることを確認し、リストアをテストします。

操作上の注意事項#

  • DB TLSは、SPIRE / BeaconプラットフォームIDとは別です。ポリシーごとにPG TLSを構成します。

  • 各DCのストレージクラスがPG IOPS/レイテンシーを満たしていることを確認します。

  • サイト間でレプリケーションポートを開きます。

検証エンドツーエンド#

  1. フェデレーション関係を検証する

kubectl -n spire-system exec svc/spire-server -c spire-server -- \
/opt/spire/bin/spire-server federation list

  1. セカンダリの場所が登録されていることを確認するプライマリ

kubectl get location

  1. セカンダリへのプロビジョニングの検証

  • プライマリHMから、小規模なテストワークロードをセカンダリの場所に展開します。

    • テレメトリオプショナル Thanosストアはフェデレーションピアを表示します。 Lokiクエリーは、Secondary.

    • オブジェクトストレージからタグ付けされたログを返します。両方のクラスターはバケットの読み取り/書き込みができます。シークレットは同じです。

手動フェイルオーバーランブック#

プライマリからセカンダリへの手動フェイルオーバー手順#

  1. プライマリへの書き込みを静止しますメンテナンスモード/LBカットオーバー。

  2. セカンダリのレプリカをプライマリにプロモートHMワークフロー/スクリプトごとに。

  3. クライアントDNS / LBをセカンダリにリダイレクトします。

  4. 観察します書き込みが成功したことを確認します。レプリケーションロールが更新されました。

  5. 元のプライマリが戻ったら、新しいプライマリのレプリカとして再シードします。オプションで、後の削減を計画します。

オペレーターのヒント#

  • カットオーバーのためにDNS TTLを十分に低く保ちます。

  • ダウンタイムを追跡してRTOを測定します。

  • プロモーション後のバックアップを検証します。

障害対応#

  • 問題 フェデレーション関係がありません

    • 再生成およびクロス適用 ClusterFederatedTrustDomain CRs.

    • 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証明書、およびストレージパフォーマンスを確認します。

付録A — CLIを介したSPIREフェデレーションオプショナル#

CRDの代わりにspire-serverフェデレーションcreate、list、update、delete、show、freshを使用してフェデレーションを管理できます。 直接サーバー制御を希望する場合、またはデバッグのためにこれを使用します。

付録B — 簡単な日常チェック#

  • プライマリのkubectl get location は、セカンダリの準備ができていることを示しています。

  • Thanos / Lokiフェデレーションは正常な場合有効な場合。

  • オブジェクトストアの書き込みは両方のDCから成功します。

  • SLO内のレプリケーションラグ。

目次