Configurar o armazenamento de mensagens com o Milvus Operator
O Milvus usa RocksMQ, Pulsar ou Kafka para gerenciar logs de alterações recentes, gerar logs de fluxo e fornecer assinaturas de log. Este tópico apresenta como configurar as dependências de armazenamento de mensagens quando você instala o Milvus com o Milvus Operator. Para obter mais detalhes, consulte Configurar o armazenamento de mensagens com o Milvus Operator no repositório do Milvus Operator.
Este tópico pressupõe que você tenha implantado o Milvus Operator.
É necessário especificar um ficheiro de configuração para utilizar o Milvus Operator para iniciar um cluster Milvus.
kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml
Só é necessário editar o modelo de código em milvus_cluster_default.yaml
para configurar dependências de terceiros. As secções seguintes apresentam como configurar o armazenamento de objectos, etcd, e Pulsar respetivamente.
Antes de começar
A tabela abaixo mostra se o RocksMQ, NATS, Pulsar e Kafka são suportados no modo autônomo e de cluster do Milvus.
RocksMQ | NATS | Pulsar | Kafka | |
---|---|---|---|---|
Modo autónomo | ✔️ | ✔️ | ✔️ | ✔️ |
Modo de cluster | ✖️ | ✖️ | ✔️ | ✔️ |
Existem também outras limitações para especificar o armazenamento de mensagens:
- Só é suportado um armazenamento de mensagens para uma instância Milvus. No entanto, continuamos a ter compatibilidade retroactiva com vários armazenamentos de mensagens definidos para uma instância. A prioridade é a seguinte:
- modo autónomo: RocksMQ (padrão) > Pulsar > Kafka
- modo de cluster: Pulsar (padrão) > Kafka
- Nats introduzidos na versão 2.3 não participam dessas regras de prioridade por compatibilidade com versões anteriores.
- O armazenamento de mensagens não pode ser alterado enquanto o sistema Milvus estiver a funcionar.
- Apenas a versão 2.x ou 3.x do Kafka é suportada.
Configurar o RocksMQ
O RocksMQ é o armazenamento de mensagens padrão no Milvus standalone.
Atualmente, só é possível configurar o RocksMQ como o armazenamento de mensagens para o Milvus standalone com o Milvus Operator.
Exemplo de configuração
O exemplo a seguir configura um serviço RocksMQ.
apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
name: milvus
spec:
dependencies: {}
components: {}
config: {}
Configurar NATS
O NATS é um armazenamento de mensagens alternativo para o NATS.
Exemplo
O exemplo a seguir configura um serviço 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: {}
Para migrar o armazenamento de mensagens do RocksMQ para o NATS, faça o seguinte:
Interrompa todas as operações DDL.
Chame a API FlushAll e, em seguida, pare o Milvus quando a chamada da API terminar de ser executada.
Altere
msgStreamType
paranatsmq
e faça as alterações necessárias nas configurações do NATS emspec.dependencies.natsmq
.Inicie novamente o Milvus e verifique se:
- Existe uma entrada de registo que indica
mqType=natsmq
nos registos. - Um diretório com o nome
jetstream
está presente no diretório especificado emspec.dependencies.natsmq.server.storeDir
.
- Existe uma entrada de registo que indica
(Opcional) Faça backup e limpe os arquivos de dados no diretório de armazenamento do RocksMQ.
Escolher entre RocksMQ e NATS?
O RockMQ usa o CGO para interagir com o RocksDB e gerencia a memória por si só, enquanto o NATS puro-GO incorporado na instalação do Milvus delega seu gerenciamento de memória ao coletor de lixo (GC) do Go.
No cenário em que o pacote de dados é menor que 64 kb, o RocksDB tem um desempenho melhor em termos de uso de memória, uso de CPU e tempo de resposta. Por outro lado, se o pacote de dados for maior que 64 kb, o NATS se sobressai em termos de tempo de resposta com memória suficiente e agendamento ideal do GC.
Atualmente, é aconselhável usar o NATS apenas para experimentos.
Configurar o Pulsar
O Pulsar gerencia logs de mudanças recentes, gera logs de fluxo de saída e fornece assinaturas de log. A configuração do Pulsar para armazenamento de mensagens é suportada tanto no Milvus standalone quanto no Milvus cluster. No entanto, com o Milvus Operator, só é possível configurar a Pulsar como armazenamento de mensagens para o Milvus cluster. Adicione os campos obrigatórios em spec.dependencies.pulsar
para configurar a Pulsar.
pulsar
suporta external
e inCluster
.
Pulsar externo
external
indica o uso de um serviço Pulsar externo. Os campos usados para configurar um serviço Pulsar externo incluem:
external
: Um valortrue
indica que o Milvus usa um serviço Pulsar externo.endpoints
: Os endpoints do Pulsar.
Exemplo de configuração
O exemplo a seguir configura um serviço Pulsar externo.
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 que quando um cluster Milvus é iniciado, um serviço Pulsar é iniciado automaticamente no cluster.
Exemplo
O exemplo a seguir configura um serviço 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
como mostrado no exemplo anterior.Supondo que o arquivo de configuração tenha o nome milvuscluster.yaml
, execute o seguinte comando para aplicar a configuração.
kubectl apply -f milvuscluster.yaml
Configurar o Kafka
O Pulsar é o armazenamento de mensagens padrão em um cluster Milvus. Se pretender utilizar o Kafka, adicione o campo opcional msgStreamType
para configurar o Kafka.
kafka
suporta external
e inCluster
.
Kafka externo
external
indica a utilização de um serviço Kafka externo.
Os campos utilizados para configurar um serviço Kafka externo incluem:
external
: Um valortrue
indica que o Milvus utiliza um serviço Kafka externo.brokerList
: A lista de corretores para os quais enviar as mensagens.
Exemplo de configuração
O exemplo seguinte configura um serviço Kafka externo.
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"
# ...
As configurações SASL são suportadas na versão v0.8.5 ou superior do operador.
Kafka interno
inCluster
indica que quando um cluster Milvus é iniciado, um serviço Kafka é iniciado automaticamente no cluster.
Exemplo
O exemplo a seguir configura um serviço 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: {}
Encontre os itens de configuração completos para configurar um serviço Kafka interno aqui. Adicione itens de configuração conforme necessário em kafka.inCluster.values
.
Supondo que o ficheiro de configuração tenha o nome milvuscluster.yaml
, execute o seguinte comando para aplicar a configuração.
kubectl apply -f milvuscluster.yaml
O que se segue
Saiba como configurar outras dependências do Milvus com o Milvus Operator: