Configurazione della replica CDC

Questa guida mostra come distribuire due cluster Milvus standalone con Milvus Operator e configurare la replica CDC da un cluster di origine a uno di destinazione.

Gli esempi utilizzano:

• source-cluster come cluster primario.
• target-cluster come cluster standby.
• milvus come spazio dei nomi per i cluster Milvus.
• milvus-operator come spazio dei nomi per Milvus Operator.

Prima di iniziare, leggete Milvus CDC per capire il modello primario-standby e le opzioni di failover.

Prerequisiti

• Milvus v2.6.16 o successivo.
• Milvus Operator v1.3.4 o successivo.
• È disponibile un cluster Kubernetes.
• I cluster di origine e di destinazione possono connettersi tra loro attraverso la rete.
• Si dispone delle credenziali di amministrazione per entrambi i cluster Milvus.
• Conoscete il numero di canali fisici per ogni cluster.

Passo 1: Aggiornare Milvus Operator

Aggiungete il repository Milvus Operator Helm:

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

Aggiornare il repository:

helm repo update zilliztech-milvus-operator

Installare o aggiornare Milvus Operator:

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

Verificare che il pod operator sia in esecuzione:

kubectl get pods -n milvus-operator

Esempio di output:

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

Passo 2: Distribuzione del cluster sorgente

Creare un file chiamato 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

Applicare la configurazione:

kubectl create namespace milvus
kubectl apply -f milvus_source_cluster.yaml

Verificare che i pod del cluster sorgente siano in esecuzione:

kubectl get pods -n milvus

Esempio di output:

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

Assicurarsi che il pod CDC, ad esempio source-cluster-milvus-cdc-..., sia nello stato Running.

Passo 3: distribuire il cluster di destinazione

Creare un file chiamato 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

Il componente CDC è abilitato anche sul cluster di destinazione. È inattivo mentre il target è in standby, ma è necessario se il target diventa primario dopo lo switchover.

Applicare la configurazione:

kubectl apply -f milvus_target_cluster.yaml

Verificare che i pod del cluster di destinazione siano in esecuzione:

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

Esempio di output:

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

Passo 4: Preparare le informazioni sul cluster

Ottenere gli indirizzi di servizio Milvus per entrambi i cluster:

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

Esempio di output:

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

Preparare due tipi di indirizzi:

• Gli indirizzi dei cluster vengono scritti nella configurazione di replica e utilizzati dai componenti CDC. Questi indirizzi devono essere raggiungibili dai pod CDC.
• Gli indirizzi dei client sono utilizzati solo dal client Python quando si chiamano le API di Milvus. Se si esegue il client Python al di fuori del cluster Kubernetes, esporre i servizi Milvus attraverso il normale metodo di accesso, come un bilanciatore di carico, un ingress o un port-forward.

Preparare le informazioni di connessione e gli elenchi pchannel per entrambi i cluster:

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)
]

Sostituire gli indirizzi con gli indirizzi effettivi dei servizi Milvus nel vostro ambiente. Non impostare source_cluster_addr o target_cluster_addr su un indirizzo di port-forward locale, a meno che i pod CDC non possano raggiungere quell'indirizzo. L'elenco di pchannel deve corrispondere alla distribuzione di Milvus. Non copiate i valori di esempio senza aver controllato la configurazione del vostro cluster.

Passo 5: Creare la configurazione di replica

Creare una configurazione di replica da source-cluster a 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,
        }
    ],
}

Passo 6: Applicare la configurazione di replica

Applicare la stessa configurazione a entrambi i cluster:

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()

Per l'automazione della produzione, utilizzare client separati a vita breve per questa operazione del piano di controllo. In questo modo si evita di condividere lo stesso canale gRPC con il traffico DML dell'applicazione durante la modifica del ruolo del cluster.

Dopo l'applicazione della configurazione, le modifiche scritte su source-cluster vengono replicate su target-cluster.

Passo 7: Verifica della replica dei dati

Per verificare che la replica funzioni:

1. Collegarsi a source-cluster.
2. Creare una raccolta.
3. Inserire i dati nella raccolta.
4. Caricare la raccolta ed eseguire una query o una ricerca su source-cluster.
5. Collegarsi a target-cluster.
6. Eseguire la stessa query o ricerca su target-cluster senza caricare manualmente la raccolta sul cluster di standby.
7. Confermare che i dati previsti sono visibili su entrambi i cluster.

Il cluster di destinazione è un cluster di standby in questa topologia. Non eseguire operazioni DDL o DCL manuali, come load_collection, sul cluster in standby. Tali operazioni devono essere eseguite sul cluster di origine e replicate sul cluster di destinazione.

Il codice di verifica esatto dipende dallo schema di raccolta. Per un flusso di lavoro di base della raccolta Milvus, consultare la documentazione di avvio rapido di Milvus.

Ritardo CDC

Il ritardo del CDC è la finestra di dati tra il cluster primario e quello di standby. È necessario monitorarlo costantemente dopo la configurazione della replica.

Il ritardo del CDC può aumentare quando:

• La velocità di scrittura del primario è elevata.
• La latenza di rete o la perdita di pacchetti aumenta tra i cluster.
• Il cluster di standby è sovraccarico.
• I nodi CDC sono sottoprovisionati.
• Sono in corso operazioni DDL o di importazione di grandi dimensioni.

Utilizzate il ritardo del CDC per guidare le decisioni operative:

• Se il ritardo è basso, la commutazione dovrebbe essere completata più rapidamente.
• Se il ritardo è elevato, il failover potrebbe perdere più dati.

È possibile stimare il ritardo del CDC con la seguente query PromQL:

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

Il risultato è in secondi. Per ogni canale sorgente, la query confronta l'ultimo timetick WAL confermato con l'ultimo timetick replicato da CDC. Se un primario replica su più cluster di standby, l'espressione min by (channel_name) riporta l'avanzamento più lento della replica per quel canale.

Se Prometheus esegue lo scrapping di più cluster Milvus, aggiungere filtri di etichetta che corrispondano alla distribuzione, come namespace o app_kubernetes_io_instance, per evitare di mescolare metriche provenienti da cluster diversi.

DOMANDE FREQUENTI

È necessario chiamare update_replicate_configuration su entrambi i cluster?

Sì. Applicare la stessa topologia a tutti i cluster partecipanti. Se un cluster non è primario al momento della chiamata, aspetta che la topologia venga applicata tramite CDC.

Come scegliere cluster_id?

Utilizzare un ID stabile e unico per ogni cluster. L'ID viene utilizzato anche nei nomi dei canali p e nei riferimenti alla topologia di replica.

È possibile modificare i canali p dopo la configurazione della replica?

È possibile aggiornare la topologia, ma l'elenco dei pchannel deve corrispondere al layout del cluster. Considerate le modifiche ai canali p come un'operazione avanzata e verificate attentamente la replica.