milvus-logo
LFAI
Casa
  • Guida all'amministrazione
    • Gestire le dipendenze

Configurazione dell'archiviazione dei messaggi con Milvus Operator

Milvus utilizza RocksMQ, Pulsar o Kafka per la gestione dei log delle modifiche recenti, l'output dei log dei flussi e la fornitura di sottoscrizioni ai log. Questo argomento illustra come configurare le dipendenze dello storage dei messaggi quando si installa Milvus con Milvus Operator. Per maggiori dettagli, consultate Configurazione dell'archiviazione dei messaggi con Milvus Operator nel repository di Milvus Operator.

Questo argomento presuppone che abbiate installato Milvus Operator.

Per ulteriori informazioni, vedere Distribuzione di Milvus Operator.

È necessario specificare un file di configurazione per utilizzare Milvus Operator per 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 terzi. Le sezioni seguenti illustrano come configurare rispettivamente object storage, etcd e Pulsar.

Prima di iniziare

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

RocksMQNATSPulsarKafka
Modalità standalone✔️✔️✔️✔️
Modalità cluster✖️✖️✔️✔️

Ci sono anche altre limitazioni per specificare l'archiviazione dei messaggi:

  • È supportato un solo archivio messaggi per un'istanza Milvus. Tuttavia, esiste ancora una compatibilità con più archivi di messaggi impostati per un'istanza. La priorità è la seguente:
    • modalità standalone: RocksMQ (predefinito) > Pulsar > Kafka
    • modalità cluster: Pulsar (predefinito) > Kafka
    • I nats introdotti nella versione 2.3 non partecipano a queste regole di priorità per compatibilità con il passato.
  • L'archiviazione dei messaggi non può essere modificata mentre il sistema Milvus è in funzione.
  • È supportata solo la versione di Kafka 2.x o 3.x.

Configurare RocksMQ

RocksMQ è il deposito di messaggi predefinito in Milvus standalone.

Attualmente è possibile configurare RocksMQ come archivio messaggi per Milvus standalone solo con Milvus Operator.

Esempio

L'esempio seguente configura un servizio RocksMQ.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: milvus
spec:
  dependencies: {}
  components: {}
  config: {}

Configurare NATS

NATS è un archivio di messaggi alternativo per NATS.

Esempio

L'esempio seguente configura un servizio NATS.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: milvus
spec:
  dependencies: 
    msgStreamType: 'natsmq'
    natsmq:
      # server side configuration for natsmq.
      server: 
        # 4222 by default, Port for nats server listening.
        port: 4222 
        # /var/lib/milvus/nats by default, directory to use for JetStream storage of nats.
        storeDir: /var/lib/milvus/nats 
        # (B) 16GB by default, Maximum size of the 'file' storage.
        maxFileStore: 17179869184 
        # (B) 8MB by default, Maximum number of bytes in a message payload.
        maxPayload: 8388608 
        # (B) 64MB by default, Maximum number of bytes buffered for a connection applies to client connections.
        maxPending: 67108864 
        # (√ms) 4s by default, waiting for initialization of natsmq finished.
        initializeTimeout: 4000 
        monitor:
          # false by default, If true enable debug log messages.
          debug: false 
          # true by default, If set to false, log without timestamps.
          logTime: true 
          # no log file by default, Log file path relative to.. .
          logFile: 
          # (B) 0, unlimited by default, Size in bytes after the log file rolls over to a new one.
          logSizeLimit: 0 
        retention:
          # (min) 3 days by default, Maximum age of any message in the P-channel.
          maxAge: 4320 
          # (B) None by default, How many bytes the single P-channel may contain. Removing oldest messages if the P-channel exceeds this size.
          maxBytes:
          # None by default, How many message the single P-channel may contain. Removing oldest messages if the P-channel exceeds this limit.    
          maxMsgs: 
  components: {}
  config: {}

Per migrare lo storage dei messaggi da RocksMQ a NATS, procedere come segue:

  1. Interrompere tutte le operazioni DDL.

  2. Chiamare l'API FlushAll e arrestare Milvus al termine dell'esecuzione della chiamata API.

  3. Cambiare msgStreamType in natsmq e apportare le modifiche necessarie alle impostazioni NATS in spec.dependencies.natsmq.

  4. Avviare nuovamente Milvus e verificare se:

    • Nei registri è presente una voce di registro che riporta mqType=natsmq.
    • Una directory denominata jetstream è presente nella directory specificata in spec.dependencies.natsmq.server.storeDir.
  5. (Facoltativo) Eseguite il backup e la pulizia dei file di dati nella directory di archiviazione di RocksMQ.

Scegliere tra RocksMQ e NATS?

RockMQ usa CGO per interagire con RocksDB e gestisce la memoria da solo, mentre il NATS puro di Go incorporato nell'installazione di Milvus delega la gestione della memoria al garbage collector (GC) di Go.

Nello scenario in cui il pacchetto di dati è più piccolo di 64 kb, RocksDB ha prestazioni migliori in termini di utilizzo della memoria, della CPU e del tempo di risposta. D'altra parte, se il pacchetto di dati è superiore a 64 kb, NATS eccelle in termini di tempo di risposta con una memoria sufficiente e una pianificazione GC ideale.

Attualmente, si consiglia di utilizzare NATS solo per gli esperimenti.

Configurare Pulsar

Pulsar gestisce i log delle modifiche recenti, produce i log dei flussi e fornisce sottoscrizioni ai log. La configurazione di Pulsar per l'archiviazione dei messaggi è supportata sia in Milvus standalone che in Milvus cluster. Tuttavia, con Milvus Operator, è possibile configurare Pulsar come archivio messaggi solo per Milvus cluster. Aggiungere i campi richiesti 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 nel cluster.

Esempio

L'esempio seguente configura 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: {}            
Questo esempio specifica il numero di repliche di ciascun componente di Pulsar, le risorse di calcolo di Pulsar BookKeeper e altre configurazioni.
Trovate gli elementi di configurazione completi per configurare un servizio Pulsar interno in values.yaml. Aggiungere le voci di configurazione necessarie in pulsar.inCluster.values, come mostrato nell'esempio precedente.

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

kubectl apply -f milvuscluster.yaml

Configurare Kafka

Pulsar è il sistema di archiviazione dei messaggi predefinito in un cluster Milvus. Se si desidera utilizzare Kafka, aggiungere il campo opzionale msgStreamType per configurare Kafka.

kafka supporta external e inCluster.

Kafka esterno

external indica l'uso 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 nella versione dell'operatore v0.8.5 o superiore.

Kafka interno

inCluster indica che all'avvio di un cluster Milvus, un servizio Kafka si avvia automaticamente nel cluster.

Esempio

L'esempio seguente configura 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 si trovano gli elementi di configurazione completi per configurare un servizio Kafka interno. Aggiungere le voci di configurazione necessarie sotto kafka.inCluster.values.

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

kubectl apply -f milvuscluster.yaml

Cosa succede dopo

Imparare a configurare altre dipendenze di Milvus con Milvus Operator:

Tradotto daDeepL

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started
Feedback

Questa pagina è stata utile?