• О компании Milvus
  • Начать работу
  • Понятия
  • Руководство пользователя
  • Импорт данных
  • Инструменты искусственного интеллекта
  • Руководство по администрированию
  • Инструменты
  • Интеграции
  • Учебные пособия
  • Часто задаваемые вопросы
  • API Reference

Настройка хранилища сообщений с помощью Milvus Operator

В Milvus 3.x Woodpecker является очереди сообщений по умолчанию (см. Woodpecker). С помощью Milvus Operator также можно настроить RocksMQ, Pulsar или Kafka для управления журналами последних изменений, вывода потоковых журналов и предоставления подписок на журналы. В этом разделе описано, как настроить зависимости хранилища сообщений при установке Milvus с помощью Milvus Operator. Более подробную информацию см. в разделе «Настройка хранилища сообщений с помощью Milvus Operator » в репозитории Milvus Operator.

В данном разделе предполагается, что вы уже развернули Milvus Operator.

Дополнительную информацию см. в разделе «Развертывание Milvus Operator ».

Для запуска кластера Milvus с помощью Milvus Operator необходимо указать файл конфигурации.

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

Для настройки сторонних зависимостей достаточно отредактировать шаблон кода в файле ` milvus_cluster_default.yaml `. В следующих разделах описано, как настроить объектное хранилище, etcd и Pulsar соответственно.

Прежде чем начать

В приведенной ниже таблице указано, поддерживаются ли RocksMQ, Pulsar, Kafka и Woodpecker в автономном и кластерном режимах Milvus.

RocksMQPulsarKafkaWoodpecker
Автономный режим✔️✔️✔️✔️
Кластерный режим✖️✔️✔️✔️

Существуют также другие ограничения при указании хранилища сообщений:

  • Поддерживается только одно хранилище сообщений для одного экземпляра Milvus. Однако мы по-прежнему обеспечиваем обратную совместимость с настройкой нескольких хранилищ сообщений для одного экземпляра. Приоритет определяется следующим образом:
    • автономный режим: Woodpecker (по умолчанию) > RocksMQ > Pulsar > Kafka
    • кластерный режим: Woodpecker (по умолчанию) > Pulsar > Kafka
  • Хранилище сообщений нельзя изменить во время работы системы Milvus.
  • Поддерживаются только версии Kafka 2.x или 3.x.
  • Ограничения обновления: Ограничения, связанные с очередями сообщений: при обновлении до версии Milvus v3.0.1 необходимо сохранить текущий выбор системы очередей сообщений. Переключение между различными системами очередей сообщений во время обновления не поддерживается. Поддержка смены систем очередей сообщений будет доступна в будущих версиях.

Настройка RocksMQ

RocksMQ являлся хранилищем сообщений по умолчанию в автономной версии Milvus до версии 2.5.x (с версии 2.6.x его заменил Woodpecker).

В настоящее время настроить RocksMQ в качестве хранилища сообщений для автономной версии Milvus можно только с помощью 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: Стандартная спецификация PVC в Kubernetes
  • accessModes: Обычно используется класс хранения « ReadWriteOnce » для блочного хранилища
  • storageClassName: Класс хранения вашего кластера
  • storage: Размер постоянного тома

Настройка Woodpecker

Woodpecker — это облачный журнал предварительной записи (WAL), разработанный для объектного хранилища. Он обеспечивает высокую пропускную способность, низкие эксплуатационные затраты и плавную масштабируемость. Подробнее см. в разделе «Woodpecker».

Настройка Pulsar

Pulsar управляет журналами недавних изменений, выводит потоковые журналы и обеспечивает подписку на журналы. Настройка Pulsar в качестве хранилища сообщений поддерживается как в автономном режиме Milvus, так и в кластере Milvus. Однако с помощью Milvus Operator вы можете настроить Pulsar в качестве хранилища сообщений только для кластера Milvus. Добавьте необходимые поля в разделе « spec.dependencies.pulsar » (Настройки хранилища сообщений), чтобы настроить Pulsar.

pulsar Поддерживаются external и inCluster.

«External 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, вычислительные ресурсы Pulsar BookKeeper и другие параметры конфигурации.
Полный список элементов конфигурации для настройки внутренней службы Pulsar см. в файле values.yaml. Добавьте элементы конфигурации по мере необходимости в раздел « pulsar.inCluster.values », как показано в предыдущем примере.

Предполагая, что файл конфигурации называется milvuscluster.yaml, выполните следующую команду, чтобы применить конфигурацию.

kubectl apply -f milvuscluster.yaml

Настройка Kafka

До версии 2.5.x Pulsar являлся хранилищем сообщений по умолчанию в кластере Milvus (начиная с версии 2.6.x его заменил Woodpecker). Если вы хотите использовать 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 поддерживаются в версии Operator 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:

ПереведеноDeepL

Попробуйте Managed Milvus бесплатно

Zilliz Cloud работает без проблем, поддерживается Milvus и в 10 раз быстрее.

Начать
Обратная связь

Была ли эта страница полезной?