CDCレプリケーションの設定

このガイドでは、Milvus Operatorを使用して2つのスタンドアロンMilvusクラスタをデプロイし、ソースクラスタからターゲットクラスタへのCDCレプリケーションを設定する方法を示します。

例では

  • source-cluster をプライマリクラスタとして使用します。
  • target-cluster スタンバイクラスタとして
  • milvus Milvusクラスタの名前空間として使用します。
  • milvus-operator Milvus Operatorのネームスペースとして使用します。

始める前に、Milvus CDCを読んで、プライマリ-スタンバイ・モデルとフェイルオーバー・オプションを理解してください。

前提条件

  • Milvus v2.6.16以降。
  • Milvus Operator v1.3.4以降。
  • Kubernetesクラスタが利用可能である。
  • ソースクラスタとターゲットクラスタがネットワークを介して互いに接続できる。
  • 両方のMilvusクラスタの管理者認証情報を持っている。
  • 各クラスタの物理チャネル数がわかっている。

ステップ1: Milvus Operatorのアップグレード

Milvus Operator Helmリポジトリを追加します:

helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/

リポジトリを更新します:

helm repo update zilliztech-milvus-operator

Milvus Operatorをインストールまたはアップグレードします:

helm -n milvus-operator upgrade --install milvus-operator \
  zilliztech-milvus-operator/milvus-operator \
  --create-namespace

Operator podが実行されていることを確認します:

kubectl get pods -n milvus-operator

出力例

NAME                               READY   STATUS    RESTARTS   AGE
milvus-operator-6f7d8c9c7d-xm4tj   1/1     Running   0          54s

ステップ2: ソースクラスタのデプロイ

milvus_source_cluster.yaml という名前のファイルを作成します:

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: source-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: standalone
  components:
    image: milvusdb/milvus:v2.6.16
    cdc:
      replicas: 1
  dependencies:
    msgStreamType: woodpecker

設定を適用します:

kubectl create namespace milvus
kubectl apply -f milvus_source_cluster.yaml

ソース・クラスター・ポッドが実行されていることを確認します:

kubectl get pods -n milvus

出力例:

NAME                                                   READY   STATUS    RESTARTS   AGE
source-cluster-etcd-0                                  1/1     Running   0          3m
source-cluster-minio-6d8f7d9b9f-9t7j2                  1/1     Running   0          3m
source-cluster-milvus-standalone-7f8d9c8f6d-r2m5x      1/1     Running   0          2m
source-cluster-milvus-cdc-66d64747bd-sckxj             1/1     Running   0          2m

source-cluster-milvus-cdc-... などのCDCポッドがRunning の状態になっていることを確認します。

ステップ3: ターゲット・クラスタのデプロイ

milvus_target_cluster.yaml という名前のファイルを作成します:

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: target-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: standalone
  components:
    image: milvusdb/milvus:v2.6.16
    cdc:
      replicas: 1
  dependencies:
    msgStreamType: woodpecker

ターゲットクラスタでもCDCコンポーネントが有効になっています。ターゲットがスタンバイの間はアイドル状態ですが、切り替え後にターゲットがプライマリになる場合は必要です。

設定を適用します:

kubectl apply -f milvus_target_cluster.yaml

ターゲット・クラスタのポッドが起動していることを確認します:

kubectl get pods -n milvus | grep -E 'NAME|target-cluster'

出力例:

NAME                                                   READY   STATUS    RESTARTS   AGE
target-cluster-etcd-0                                  1/1     Running   0          3m
target-cluster-minio-5f7c8d9b6f-k8s2q                  1/1     Running   0          3m
target-cluster-milvus-standalone-66dc8d9f7f-5n6bp      1/1     Running   0          2m
target-cluster-milvus-cdc-7f8c9d6b8c-q4t9m             1/1     Running   0          2m

ステップ4: クラスタ情報の準備

両方のクラスタのMilvusサービスアドレスを取得します:

kubectl get svc -n milvus | grep -E 'NAME|source-cluster|target-cluster'

出力例

NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)              AGE
source-cluster-milvus                 ClusterIP   10.98.124.90     <none>        19530/TCP,9091/TCP   8m
target-cluster-milvus                 ClusterIP   10.109.234.172   <none>        19530/TCP,9091/TCP   3m

2種類のアドレスを準備します:

  • クラスタアドレスはレプリケーション構成に書き込まれ、CDCコンポーネントによって使用されます。これらのアドレスはCDCポッドから到達可能でなければなりません。
  • クライアントアドレスはPythonクライアントがMilvus APIを呼び出すときにのみ使用されます。Kubernetesクラスタ外でPythonクライアントを実行する場合は、ロードバランサ、イングレス、ポートフォワードなど、通常のアクセス方法でMilvusサービスを公開します。

両方のクラスタの接続情報とpchannelリストを準備します:

source_cluster_addr = "http://source-cluster-milvus.milvus.svc.cluster.local:19530"
target_cluster_addr = "http://target-cluster-milvus.milvus.svc.cluster.local:19530"

source_client_addr = source_cluster_addr
target_client_addr = target_cluster_addr

# If your Python client runs outside the Kubernetes cluster, replace only
# source_client_addr and target_client_addr with externally reachable addresses.
# Keep source_cluster_addr and target_cluster_addr reachable from CDC pods.
# For example:
# source_client_addr = "http://127.0.0.1:19530"
# target_client_addr = "http://127.0.0.1:19531"

source_cluster_token = "root:Milvus"
target_cluster_token = "root:Milvus"

source_cluster_id = "source-cluster"
target_cluster_id = "target-cluster"

pchannel_num = 16
source_cluster_pchannels = [
    f"{source_cluster_id}-rootcoord-dml_{i}"
    for i in range(pchannel_num)
]
target_cluster_pchannels = [
    f"{target_cluster_id}-rootcoord-dml_{i}"
    for i in range(pchannel_num)
]

アドレスを実際のMilvusサービスのアドレスに置き換えてください。CDCポッドもそのアドレスに到達できる場合を除き、source_cluster_addr またはtarget_cluster_addr をローカルのポートフォワードアドレスに設定しないでください。pchannelリストはMilvusの展開と一致している必要があります。クラスタ構成を確認せずに例の値をコピーしないでください。

ステップ5: レプリケーション構成の作成

source-cluster からtarget-cluster へのレプリケーション構成を作成します:

replicate_config = {
    "clusters": [
        {
            "cluster_id": source_cluster_id,
            "connection_param": {
                "uri": source_cluster_addr,
                "token": source_cluster_token,
            },
            "pchannels": source_cluster_pchannels,
        },
        {
            "cluster_id": target_cluster_id,
            "connection_param": {
                "uri": target_cluster_addr,
                "token": target_cluster_token,
            },
            "pchannels": target_cluster_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": source_cluster_id,
            "target_cluster_id": target_cluster_id,
        }
    ],
}

ステップ6: レプリケーション構成の適用

両方のクラスタに同じ構成を適用します:

from pymilvus import MilvusClient

source_client = MilvusClient(
    uri=source_client_addr,
    token=source_cluster_token,
)
target_client = MilvusClient(
    uri=target_client_addr,
    token=target_cluster_token,
)

try:
    source_client.update_replicate_configuration(**replicate_config)
    target_client.update_replicate_configuration(**replicate_config)
finally:
    source_client.close()
    target_client.close()

プロダクション・オートメーションでは、このコントロール・プレーン操作に別々の短命クライアントを使用します。これにより、クラスタ・ロールの変更中にアプリケーションDMLトラフィックと同じgRPCチャネルを共有することを回避できます。

構成が適用されると、source-cluster に書き込まれた変更がtarget-cluster にレプリケートされます。

ステップ7:データ・レプリケーションの検証

レプリケーションが機能することを確認します:

  1. source-cluster に接続します。
  2. コレクションを作成します。
  3. コレクションにデータを挿入する。
  4. コレクションをロードし、source-cluster でクエリまたは検索を実行する。
  5. target-cluster に接続する。
  6. スタンバイ・クラスタでコレクションを手動でロードせずに、target-cluster で同じクエリまたは検索を実行します。
  7. 期待されるデータが両方のクラスタで表示されていることを確認します。

ターゲット・クラスタは、このトポロジではスタンバイ・クラスタです。load_collection などの手動DDLまたはDCL操作をスタンバイ・クラスタで実行しないでください。これらの操作はソース・クラスタで実行し、ターゲット・クラスタにレプリケートする必要があります。

正確な検証コードはコレクションスキーマに依存します。基本的なMilvusコレクションワークフローについては、Milvusクイックスタートドキュメントを参照してください。

CDCラグ

CDCラグはプライマリクラスタとスタンバイクラスタ間のデータウィンドウです。レプリケーションが構成された後、継続的に監視する必要があります。

CDCラグは以下の場合に増加する可能性があります:

  • プライマリの書き込みレートが高い。
  • クラスタ間のネットワーク遅延またはパケットロスが増加した場合。
  • スタンバイ・クラスタが過負荷になっている。
  • CDCノードのプロビジョニングが不足している。
  • 大規模なDDLまたはインポート処理が実行されている。

CDCのラグを使用して運用上の決定を導きます:

  • ラグが小さい場合、切り替えはより速く完了するはずです。
  • ラグが小さい場合、切り替えはより速く完了するはずです。ラグが大きい場合、フェイルオーバーにより多くのデータが失われる可能性があります。

以下のPromQLクエリでCDCラグを見積もることができます:

clamp_min(
  max by (channel_name) (
    milvus_wal_last_confirmed_time_tick
  )
  -
  min by (channel_name) (
    milvus_cdc_last_replicated_time_tick
  ),
  0
)

結果は秒単位です。各ソース・チャネルについて、このクエリは確認された最新のWALタイムティックとCDCによってレプリケートされた最後のタイムティックを比較します。プライマリが複数のスタンバイ・クラスタにレプリケートする場合、min by (channel_name) 式はそのチャネルの最も遅いレプリケーション進捗を報告します。

Prometheusが複数のMilvusクラスタをスクレイピングする場合は、namespaceapp_kubernetes_io_instance など、デプロイメントにマッチするラベルフィルタを追加して、異なるクラスタのメトリクスが混在しないようにしてください。

よくある質問

両方のクラスタでupdate_replicate_configuration を呼び出す必要がありますか?

はい。参加するすべてのクラスタに同じトポロジを適用します。呼び出し時に一方のクラスタがプライマリでない場合は、CDCを介してトポロジが適用されるまで待機します。

cluster_id はどのように選択すればよいですか?

各クラスタに安定した一意のIDを使用します。このIDはpchannel名やレプリケーション・トポロジーの参照にも使用されます。

レプリケーション設定後にpchannelを変更できますか?

トポロジーを更新することはできますが、pchannelリストはクラスタ・レイアウトと一致している必要があります。pchannelの変更は高度な操作として扱い、その後レプリケーションを慎重に検証してください。