Configurer le stockage des messages avec Milvus Operator

Dans Milvus 3.x, Woodpecker est la file d'attente de messages par défaut (voir Woodpecker). Avec Milvus Operator, vous pouvez également configurer RocksMQ, Pulsar ou Kafka pour gérer les journaux des modifications récentes, générer des journaux de flux et fournir des abonnements aux journaux. Cette rubrique explique comment configurer les dépendances de stockage des messages lorsque vous installez Milvus avec Milvus Operator. Pour plus de détails, consultez la section « Configurer le stockage des messages avec Milvus Operator » dans le référentiel Milvus Operator.

Cette rubrique part du principe que vous avez déployé Milvus Operator.

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 vous suffit de modifier le modèle de code disponible à l’adresse milvus_cluster_default.yaml pour configurer les dépendances tierces. Les sections suivantes expliquent comment configurer respectivement le stockage d’objets, etcd et Pulsar.

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.

Il existe également d'autres restrictions concernant la configuration du stockage des messages :

• Un seul stockage de messages est pris en charge par instance Milvus. Cependant, la rétrocompatibilité est assurée pour les instances configurées avec plusieurs stockages de messages. L'ordre de priorité est le suivant :
  • mode autonome : Woodpecker (par défaut) > RocksMQ > Pulsar > Kafka
  • mode cluster : Woodpecker (par défaut) > Pulsar > Kafka
• Le stockage des messages ne peut pas être modifié pendant que le système Milvus est en cours d'exécution.
• Seules les versions 2.x ou 3.x de Kafka sont prises en charge.
• Restrictions de mise à niveau: Restrictions relatives aux files d'attente de messages: lors de la mise à niveau vers Milvus v3.0.2, 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 versions futures.

Configurer RocksMQ

RocksMQ était le stockage de messages par défaut dans Milvus en mode autonome jusqu'à la version 2.5.x (remplacé par Woodpecker à partir de la version 2.6.x).

Exemple

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

Options de configuration clés :

• msgStreamType: rocksmq : définit explicitement RocksMQ comme file d'attente de messages
• persistence.enabled: Active le stockage persistant des données RocksMQ
• persistence.pvcDeletion: Si la valeur est « true », le PVC sera supprimé lors de la suppression de l’instance Milvus
• persistentVolumeClaim.spec: Spécification PVC Kubernetes standard
• accessModes: Généralement « ReadWriteOnce » pour le stockage en blocs
• storageClassName: Classe de stockage de votre cluster
• storage: Taille du volume persistant

Configurer Woodpecker

Woodpecker est un journal d’écriture anticipée (WAL) natif du cloud, conçu pour le stockage objet. Il offre un débit élevé, une faible charge opérationnelle et une évolutivité transparente. Pour plus de détails, consultez la documentation sur Woodpecker.

Configurer Pulsar

Pulsar gère les journaux des modifications récentes, génère des flux de journaux et permet de s’abonner à ces journaux. La configuration de Pulsar en tant que stockage de messages est prise en charge aussi bien dans Milvus en mode autonome que dans un cluster Milvus. Cependant, avec Milvus Operator, vous ne pouvez configurer Pulsar comme stockage de messages que pour un cluster Milvus. Remplissez 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 permettant de configurer un service Pulsar externe sont les suivants :

• external: Une valeur « true » indique que Milvus utilise un service Pulsar externe.
• endpoints: Les points de terminaison de Pulsar.

Exemple

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, lors du démarrage d’un cluster Milvus, un service Pulsar démarre automatiquement au sein du 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: {}            

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 était le stockage de messages par défaut dans un cluster Milvus jusqu’à la version 2.5.x (remplacé par Woodpecker à partir de la version 2.6.x). 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: Une valeur « true » indique que Milvus utilise un service Kafka externe.
• brokerList: La liste des brokers 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 à partir de la version v0.8.5 de l’opérateur.

Kafka interne

inCluster indique que, lors du démarrage d’un cluster Milvus, un service Kafka démarre automatiquement au sein du cluster.

Exemple

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

Retrouvez ici la liste complète des éléments de configuration nécessaires pour configurer un service Kafka interne. 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

Étapes suivantes

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

• Configurer le stockage d’objets avec Milvus Operator
• Configurer le stockage des métadonnées avec Milvus Operator