Настройка хранилища сообщений в Milvus Operator
Milvus использует RocksMQ, Pulsar или Kafka для управления журналами последних изменений, вывода потоковых журналов и предоставления подписок на журналы. В этой теме описывается настройка зависимостей хранилища сообщений при установке Milvus с Milvus Operator. Дополнительные сведения см. в разделе Настройка хранилища сообщений с Milvus Operator в репозитории Milvus Operator.
В этой теме предполагается, что вы развернули Milvus Operator.
Вам нужно указать файл конфигурации для использования Milvus Operator для запуска кластера Milvus.
kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml
Для настройки сторонних зависимостей достаточно отредактировать шаблон кода в milvus_cluster_default.yaml
. В следующих разделах описывается настройка объектного хранилища, etcd и Pulsar соответственно.
Прежде чем начать
В таблице ниже показано, поддерживаются ли RocksMQ, NATS, Pulsar и Kafka в автономном и кластерном режиме Milvus.
RocksMQ | NATS | Pulsar | Kafka | |
---|---|---|---|---|
Автономный режим | ✔️ | ✔️ | ✔️ | ✔️ |
Кластерный режим | ✖️ | ✖️ | ✔️ | ✔️ |
Существуют и другие ограничения на указание хранилища сообщений:
- Поддерживается только одно хранилище сообщений для одного экземпляра Milvus. Однако у нас сохраняется обратная совместимость с несколькими хранилищами сообщений, установленными для одного экземпляра. Приоритет следующий:
- автономный режим: RocksMQ (по умолчанию) > Pulsar > Kafka
- кластерный режим: Pulsar (по умолчанию) > Kafka
- Наборы, представленные в версии 2.3, не участвуют в этих правилах приоритета в целях обратной совместимости.
- Хранилище сообщений не может быть изменено во время работы системы Milvus.
- Поддерживается только версия Kafka 2.x или 3.x.
Настройка RocksMQ
RocksMQ - это хранилище сообщений по умолчанию в автономной системе Milvus.
В настоящее время настроить RocksMQ в качестве хранилища сообщений для Milvus standalone можно только с помощью Milvus Operator.
Пример
В следующем примере настраивается служба 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: {}
Основные параметры конфигурации:
msgStreamType
: rocksmq: Явно устанавливает RocksMQ в качестве очереди сообщений.persistence.enabled
: Включает постоянное хранение данных RocksMQ.persistence.pvcDeletion
: При значении true, PVC будет удаляться при удалении экземпляра Milvus.persistentVolumeClaim.spec
: Стандартная спецификация Kubernetes PVCaccessModes
: ОбычноReadWriteOnce
для блочного хранилища.storageClassName
: Класс хранилища вашего кластераstorage
: Размер постоянного тома
Настройка NATS
NATS - это альтернативное хранилище сообщений для NATS.
Пример
В следующем примере настраивается служба 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: {}
Чтобы перенести хранилище сообщений с RocksMQ на NATS, сделайте следующее:
Остановите все операции DDL.
Вызовите API FlushAll, а затем остановите Milvus после завершения выполнения вызова API.
Измените
msgStreamType
наnatsmq
и внесите необходимые изменения в настройки NATS наspec.dependencies.natsmq
.Снова запустите Milvus и проверьте:
- В журналах присутствует запись с текстом
mqType=natsmq
. - Каталог с именем
jetstream
присутствует в каталоге, указанном вspec.dependencies.natsmq.server.storeDir
.
- В журналах присутствует запись с текстом
(Необязательно) Создайте резервную копию и очистите файлы данных в каталоге хранения RocksMQ.
Выбор между RocksMQ и NATS?
RocksMQ использует CGO для взаимодействия с RocksDB и самостоятельно управляет памятью, в то время как NATS, встроенный в Milvus, делегирует управление памятью сборщику мусора (GC) Go.
В сценарии, когда пакет данных меньше 64 кб, RocksDB превосходит по использованию памяти, загрузке процессора и времени отклика. С другой стороны, если пакет данных больше 64 кб, NATS превосходит по времени отклика при достаточном объеме памяти и идеальном планировании GC.
В настоящее время рекомендуется использовать NATS только для экспериментов.
Настройка Pulsar
Pulsar управляет журналами последних изменений, выводит потоковые журналы и обеспечивает подписку на журналы. Настройка Pulsar для хранения сообщений поддерживается как в автономном Milvus, так и в кластере Milvus. Однако в Milvus Operator вы можете настроить Pulsar в качестве хранилища сообщений только для кластера Milvus. Для настройки Pulsar добавьте необходимые поля в поле spec.dependencies.pulsar
.
pulsar
Поддерживаются external
и inCluster
.
Внешний Pulsar
external
указывает на использование внешней службы Pulsar. Поля, используемые для настройки внешней службы Pulsar, включают:
external
: Значениеtrue
указывает на то, что Milvus использует внешнюю службу Pulsar.endpoints
: Конечные точки Pulsar.
Пример
В следующем примере настраивается внешняя служба Pulsar.
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
inCluster
указывает, что при запуске кластера Milvus в нем автоматически запускается служба Pulsar.
Пример
В следующем примере настраивается внутренняя служба Pulsar.
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
, как показано в предыдущем примере.Предполагая, что файл конфигурации имеет имя milvuscluster.yaml
, выполните следующую команду, чтобы применить конфигурацию.
kubectl apply -f milvuscluster.yaml
Настройка Kafka
Pulsar - это хранилище сообщений по умолчанию в кластере Milvus. Если вы хотите использовать Kafka, добавьте необязательное поле msgStreamType
для настройки Kafka.
kafka
Поддерживаются external
и inCluster
.
Внешняя Kafka
external
указывает на использование внешней службы Kafka.
Поля, используемые для настройки внешнего сервиса Kafka, включают:
external
: Значениеtrue
указывает на то, что Milvus использует внешнюю службу Kafka.brokerList
: Список брокеров для отправки сообщений.
Пример
В следующем примере настраивается внешний сервис Kafka.
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"
# ...
Конфигурации SASL поддерживаются в версии оператора v0.8.5 или выше.
Внутренний Kafka
inCluster
указывает, что при запуске кластера Milvus в нем автоматически запускается служба Kafka.
Пример
В следующем примере настраивается внутренняя служба Kafka.
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: {}
Полный список элементов конфигурации для настройки внутренней службы Kafka можно найти здесь. Добавьте необходимые элементы конфигурации по адресу kafka.inCluster.values
.
Предполагая, что файл конфигурации имеет имя milvuscluster.yaml
, выполните следующую команду, чтобы применить конфигурацию.
kubectl apply -f milvuscluster.yaml
Что дальше
Узнайте, как настроить другие зависимости Milvus с помощью Milvus Operator: