Configurazione dell'archiviazione dei messaggi con Milvus Operator

In Milvus 3.x, Woodpecker è la coda di messaggi predefinita (vedere Woodpecker). Con Milvus Operator, è inoltre possibile configurare RocksMQ, Pulsar o Kafka per la gestione dei log delle modifiche recenti, l'output dei log di flusso e la fornitura di sottoscrizioni ai log. Questo argomento illustra come configurare le dipendenze di archiviazione dei messaggi quando si installa Milvus con Milvus Operator. Per ulteriori dettagli, consultare Configurare l'archiviazione dei messaggi con Milvus Operator nel repository di Milvus Operator.

Questo argomento presuppone che Milvus Operator sia già stato distribuito.

È necessario specificare un file di configurazione per utilizzare Milvus Operator e avviare un cluster Milvus.

kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml

È sufficiente modificare il modello di codice in milvus_cluster_default.yaml per configurare le dipendenze di terze parti. Le sezioni seguenti illustrano come configurare rispettivamente l'object storage, etcd e Pulsar.

Prima di iniziare

La tabella sottostante mostra se RocksMQ, Pulsar, Kafka e Woodpecker sono supportati in Milvus in modalità standalone e in modalità cluster.

Esistono anche altre limitazioni relative alla specificazione dell'archivio messaggi:

• È supportato un solo archivio messaggi per ogni istanza di Milvus. Tuttavia, è garantita la retrocompatibilità con più archivi messaggi configurati per una singola istanza. L’ordine di priorità è il seguente:
  • modalità standalone: Woodpecker (predefinito) > RocksMQ > Pulsar > Kafka
  • modalità cluster: Woodpecker (impostazione predefinita) > Pulsar > Kafka
• L'archivio messaggi non può essere modificato mentre il sistema Milvus è in esecuzione.
• Sono supportate solo le versioni 2.x o 3.x di Kafka.
• Limiti dell’aggiornamento: Limiti relativi alle code di messaggi: durante l’aggiornamento a Milvus v3.0.1, è necessario mantenere la scelta attuale della coda di messaggi. Il passaggio da un sistema di code di messaggi a un altro durante l’aggiornamento non è supportato. Il supporto per la modifica dei sistemi di code di messaggi sarà disponibile nelle versioni future.

Configurazione di RocksMQ

RocksMQ era l’archivio messaggi predefinito in Milvus standalone fino alla versione 2.5.x (sostituito da Woodpecker a partire dalla versione 2.6.x).

Esempio

L'esempio seguente illustra la configurazione di un servizio RocksMQ.

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: milvus
spec:
  mode: standalone
  dependencies:
    msgStreamType: rocksmq
    rocksmq:
      persistence:
        enabled: true
        pvcDeletion: true
        persistentVolumeClaim:
          spec:
            accessModes: ["ReadWriteOnce"]
            storageClassName: "local-path"  # Specify your storage class
            resources:
              requests:
                storage: 10Gi  # Specify your desired storage size
  components: {}
  config: {}

Opzioni chiave di configurazione:

• msgStreamType: rocksmq: imposta esplicitamente RocksMQ come coda dei messaggi
• persistence.enabled: Abilita l'archiviazione persistente dei dati di RocksMQ
• persistence.pvcDeletion: Se impostato su true, il PVC verrà eliminato quando l’istanza di Milvus viene eliminata
• persistentVolumeClaim.spec: Specifiche standard del PVC di Kubernetes
• accessModes: In genere ReadWriteOnce per lo storage a blocchi
• storageClassName: La classe di archiviazione del proprio cluster
• storage: Dimensione del volume persistente

Configurazione di Woodpecker

Woodpecker è un Write-Ahead Log (WAL) cloud-native progettato per lo storage a oggetti. Offre un throughput elevato, un basso overhead operativo e una scalabilità senza soluzione di continuità. Per ulteriori dettagli, consultare Woodpecker.

Configurazione di Pulsar

Pulsar gestisce i log delle modifiche recenti, genera log di flusso e fornisce sottoscrizioni ai log. La configurazione di Pulsar come archivio di messaggi è supportata sia nella versione standalone di Milvus che nel cluster Milvus. Tuttavia, con Milvus Operator, è possibile configurare Pulsar come archivio di messaggi solo per il cluster Milvus. Aggiungere i campi obbligatori in spec.dependencies.pulsar per configurare Pulsar.

pulsar Supporta external e inCluster.

Pulsar esterno

external indica l’utilizzo di un servizio Pulsar esterno. I campi utilizzati per configurare un servizio Pulsar esterno includono:

• external: Un valore true indica che Milvus utilizza un servizio Pulsar esterno.
• endpoints: Gli endpoint di Pulsar.

Esempio

L'esempio seguente configura un servizio Pulsar esterno.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  dependencies: # Optional
    pulsar: # Optional
      # Whether (=true) to use an existed external pulsar as specified in the field endpoints or 
      # (=false) create a new pulsar inside the same kubernetes cluster for milvus.
      external: true # Optional default=false
      # The external pulsar endpoints if external=true
      endpoints:
      - 192.168.1.1:6650
  components: {}
  config: {}           

Pulsar interno

inCluster indica che all’avvio di un cluster Milvus, un servizio Pulsar si avvia automaticamente all’interno del cluster.

Esempio

L'esempio seguente illustra come configurare un servizio Pulsar interno.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  dependencies:
    pulsar:
      inCluster:
        values:
          components:
            autorecovery: false
          zookeeper:
            replicaCount: 1
          bookkeeper:
            replicaCount: 1
            resoureces:
              limit:
                cpu: '4'
              memory: 8Gi
            requests:
              cpu: 200m
              memory: 512Mi
          broker:
            replicaCount: 1
            configData:
              ## Enable `autoSkipNonRecoverableData` since bookkeeper is running
              ## without persistence
              autoSkipNonRecoverableData: "true"
              managedLedgerDefaultEnsembleSize: "1"
              managedLedgerDefaultWriteQuorum: "1"
              managedLedgerDefaultAckQuorum: "1"
          proxy:
            replicaCount: 1
  components: {}
  config: {}            

Supponendo che il file di configurazione si chiami ` milvuscluster.yaml`, eseguire il comando seguente per applicare la configurazione.

kubectl apply -f milvuscluster.yaml

Configurazione di Kafka

Pulsar era l’archivio predefinito dei messaggi in un cluster Milvus fino alla versione 2.5.x (sostituito da Woodpecker a partire dalla versione 2.6.x). Se si desidera utilizzare Kafka, aggiungere il campo opzionale msgStreamType per configurare Kafka.

kafka Supporta external e inCluster.

Kafka esterno

external indica l’utilizzo di un servizio Kafka esterno.

I campi utilizzati per configurare un servizio Kafka esterno includono:

• external: Un valore true indica che Milvus utilizza un servizio Kafka esterno.
• brokerList: L'elenco dei broker a cui inviare i messaggi.

Esempio

L'esempio seguente configura un servizio Kafka esterno.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  config:
    kafka:
      # securityProtocol supports: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL 
      securityProtocol: PLAINTEXT
      # saslMechanisms supports: PLAIN, SCRAM-SHA-256, SCRAM-SHA-512
      saslMechanisms: PLAIN
      saslUsername: ""
      saslPassword: ""
  # Omit other fields ...
  dependencies:
    # Omit other fields ...
    msgStreamType: "kafka"
    kafka:
      external: true
      brokerList: 
        - "kafkaBrokerAddr1:9092"
        - "kafkaBrokerAddr2:9092"
        # ...

Le configurazioni SASL sono supportate a partire dalla versione v0.8.5 dell’operatore.

Kafka interno

inCluster indica che, all’avvio di un cluster Milvus, un servizio Kafka si avvia automaticamente all’interno del cluster.

Esempio

L'esempio seguente illustra come configurare un servizio Kafka interno.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec: 
  dependencies:
    msgStreamType: "kafka"
    kafka:
      inCluster: 
        values: {} # values can be found in https://artifacthub.io/packages/helm/bitnami/kafka
  components: {}
  config: {}

Qui è possibile trovare tutte le voci di configurazione necessarie per configurare un servizio Kafka interno. Aggiungere le voci di configurazione necessarie nella sezione " kafka.inCluster.values".

Supponendo che il file di configurazione si chiami milvuscluster.yaml, eseguire il comando seguente per applicare la configurazione.

kubectl apply -f milvuscluster.yaml

Prossimi passi

Scopri come configurare altre dipendenze di Milvus con Milvus Operator:

• Configurare l’Object Storage con Milvus Operator
• Configurare Meta Storage con Milvus Operator