• À propos de Milvus
  • Commencer
  • Concepts
  • Guide de l'utilisateur
  • Importation de données
  • Outils d'IA
  • Guide d'administration
  • Outils
  • Intégrations
  • Tutoriels
  • FAQ
  • API Reference

Configurer le stockage des messages avec Milvus Operator

Milvus utilise RocksMQ, Pulsar ou Kafka pour gérer les journaux des modifications récentes, produire des journaux de flux et fournir des abonnements aux journaux. Cette rubrique explique comment configurer les dépendances du stockage des messages lorsque vous installez Milvus avec Milvus Operator. Pour plus de détails, voir Configurer le stockage des messages avec Milvus Oper ator dans le référentiel Milvus Operator.

Cette rubrique suppose que vous avez déployé Milvus Operator.

Voir Déployer Milvus Operator pour plus d'informations.

Vous devez spécifier un fichier de configuration pour utiliser Milvus Operator afin de démarrer un cluster Milvus.

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

Il suffit de modifier le modèle de code dans milvus_cluster_default.yaml pour configurer les dépendances tierces. Les sections suivantes présentent la configuration du stockage d'objets, d'etcd et de Pulsar respectivement.

Avant de commencer

Le tableau ci-dessous indique si RocksMQ, Pulsar, Kafka et Woodpecker sont pris en charge dans Milvus en mode autonome et en mode cluster.

RocksMQPulsarKafkaWoodpecker
Mode autonome✔️✔️✔️✔️
Mode cluster✖️✔️✔️✔️

Il existe également d'autres limitations pour la spécification du stockage des messages :

  • Un seul stockage de messages pour une instance Milvus est pris en charge. Toutefois, il existe toujours une compatibilité ascendante avec les stockages de messages multiples définis pour une instance. La priorité est la suivante
    • mode autonome : RocksMQ (par défaut) > Pulsar > Kafka
    • mode cluster : Pulsar (par défaut) > Kafka
  • Le stockage des messages ne peut pas être modifié lorsque le système Milvus est en cours d'exécution.
  • Seule la version Kafka 2.x ou 3.x est prise en charge.
  • Limitations de la mise à niveau: Limitations de la file d'attente des messages: Lors de la mise à niveau vers Milvus v2.6.15, vous devez conserver votre choix actuel de file d'attente de messages. Le passage d'un système de file d'attente de messages à un autre pendant la mise à niveau n'est pas pris en charge. La prise en charge du changement de système de file d'attente de messages sera disponible dans les prochaines versions.

Configurer RocksMQ

RocksMQ est le stockage de messages par défaut dans Milvus standalone.

Actuellement, il n'est possible de configurer RocksMQ comme stockage de messages pour Milvus standalone qu'avec Milvus Operator.

Exemple de configuration

L'exemple suivant configure un service 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: {}
Principales options de configuration :
  • msgStreamTyperocksmq : Définit explicitement RocksMQ comme file d'attente de messages.
  • persistence.enabled: Active le stockage persistant pour les données RocksMQ
  • persistence.pvcDeletion: Si l'option est vraie, le PVC sera supprimé lorsque l'instance Milvus sera supprimée.
  • persistentVolumeClaim.spec: Spécification standard du PVC Kubernetes
  • accessModes: Généralement ReadWriteOnce pour le stockage en bloc
  • storageClassName: La classe de stockage de votre cluster
  • storage: Taille du volume persistant

Configurer Woodpecker

Woodpecker est un journal en avance sur l'écriture (WAL) conçu pour le stockage d'objets. Il offre un débit élevé, une faible surcharge opérationnelle et une évolutivité transparente. Pour plus de détails, voir Utiliser Woodpecker.

Configurer Pulsar

Pulsar gère les journaux des modifications récentes, produit des journaux de flux et fournit des abonnements aux journaux. La configuration de Pulsar pour le stockage des messages est prise en charge dans Milvus standalone et Milvus cluster. Toutefois, avec Milvus Operator, vous ne pouvez configurer Pulsar comme stockage de messages que pour Milvus cluster. Ajouter les champs obligatoires sous spec.dependencies.pulsar pour configurer Pulsar.

pulsar prend en charge external et inCluster.

Pulsar externe

external indique l'utilisation d'un service Pulsar externe. Les champs utilisés pour configurer un service Pulsar externe sont les suivants :

  • external: Une valeur true indique que Milvus utilise un service Pulsar externe.
  • endpoints: Les points d'extrémité de Pulsar.

Exemple de configuration d'un service Pulsar externe

L'exemple suivant configure un service Pulsar externe.

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 interne

inCluster indique que lorsqu'un cluster Milvus démarre, un service Pulsar démarre automatiquement dans le cluster.

Exemple

L'exemple suivant configure un service Pulsar interne.

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: {}            
Cet exemple spécifie le nombre de répliques de chaque composant de Pulsar, les ressources de calcul de Pulsar BookKeeper et d'autres configurations.
Vous trouverez les éléments de configuration complets pour configurer un service Pulsar interne dans values.yaml. Ajoutez les éléments de configuration nécessaires sous pulsar.inCluster.values comme indiqué dans l'exemple précédent.

En supposant que le fichier de configuration s'appelle milvuscluster.yaml, exécutez la commande suivante pour appliquer la configuration.

kubectl apply -f milvuscluster.yaml

Configurer Kafka

Pulsar est le stockage de messages par défaut dans un cluster Milvus. Si vous souhaitez utiliser Kafka, ajoutez le champ facultatif msgStreamType pour configurer Kafka.

kafka prend en charge external et inCluster.

Kafka externe

external indique l'utilisation d'un service Kafka externe.

Les champs utilisés pour configurer un service Kafka externe sont les suivants :

  • external: La valeur true indique que Milvus utilise un service Kafka externe.
  • brokerList: La liste des courtiers auxquels envoyer les messages.

Exemple

L'exemple suivant configure un service Kafka externe.

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"
        # ...

Les configurations SASL sont prises en charge dans la version 0.8.5 ou supérieure de l'opérateur.

Kafka interne

inCluster indique que lorsqu'un cluster Milvus démarre, un service Kafka démarre automatiquement dans le cluster.

Exemple de configuration

L'exemple suivant configure un service Kafka interne.

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: {}

Vous trouverez les éléments de configuration complets pour configurer un service Kafka interne ici. Ajoutez les éléments de configuration nécessaires sous kafka.inCluster.values.

En supposant que le fichier de configuration s'appelle milvuscluster.yaml, exécutez la commande suivante pour appliquer la configuration.

kubectl apply -f milvuscluster.yaml

Prochaines étapes

Découvrez comment configurer d'autres dépendances Milvus avec Milvus Operator :