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 Operator dans le référentiel Milvus Operator.

Cette rubrique suppose 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 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, NATS, Pulsar et Kafka sont pris en charge dans Milvus en mode autonome et en 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
  • Les nats introduits dans la version 2.3 ne participent pas à ces règles de priorité pour des raisons de compatibilité ascendante.
• Le stockage des messages ne peut pas être modifié lorsque le système Milvus est en cours d'exécution.
• Seule la version 2.x ou 3.x de Kafka est prise en charge.

Configuration de RocksMQ

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

Exemple de configuration

L'exemple suivant configure un service RocksMQ.

apiVersion: milvus.io/v1alpha1
kind: Milvus
metadata:
  name: milvus
spec:
  dependencies: {}
  components: {}
  config: {}

Configuration de NATS

NATS est un stockage de messages alternatif pour NATS.

Exemple

L'exemple suivant configure un service 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: {}

Pour migrer le stockage de messages de RocksMQ vers NATS, procédez comme suit :

1. Arrêtez toutes les opérations DDL.

2. Appeler l'API FlushAll et arrêter Milvus une fois que l'appel API a fini de s'exécuter.

3. Remplacer msgStreamType par natsmq et apporter les modifications nécessaires aux paramètres NATS dans spec.dependencies.natsmq.

4. Redémarrer Milvus et vérifier si :

   • Une entrée de journal indiquant mqType=natsmq est présente dans les journaux.
   • Un répertoire nommé jetstream est présent dans le répertoire spécifié dans spec.dependencies.natsmq.server.storeDir.

5. (Facultatif) Sauvegarder et nettoyer les fichiers de données dans le répertoire de stockage RocksMQ.

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 à la fois 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: {}            

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

Apprenez à configurer d'autres dépendances Milvus avec Milvus Operator :

• Configurer le stockage d'objets avec Milvus Operator
• Configurer le méta stockage avec Milvus Operator