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.
È 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.
RocksMQ | NATS | Pulsar | Kafka | |
---|---|---|---|---|
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:
Interrompere tutte le operazioni DDL.
Chiamare l'API FlushAll e arrestare Milvus al termine dell'esecuzione della chiamata API.
Cambiare
msgStreamType
innatsmq
e apportare le modifiche necessarie alle impostazioni NATS inspec.dependencies.natsmq
.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 inspec.dependencies.natsmq.server.storeDir
.
- Nei registri è presente una voce di registro che riporta
(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 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 valoretrue
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: {}
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 valoretrue
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: