Konfigurieren der Nachrichtenspeicherung mit Milvus Operator

Milvus verwendet RocksMQ, Pulsar oder Kafka für die Verwaltung von Protokollen der letzten Änderungen, die Ausgabe von Stream-Protokollen und die Bereitstellung von Protokollabonnements. In diesem Thema wird erläutert, wie Sie die Abhängigkeiten für den Nachrichtenspeicher konfigurieren, wenn Sie Milvus mit Milvus Operator installieren. Weitere Details finden Sie unter Konfigurieren des Nachrichtenspeichers mit Milvus Operator im Milvus Operator Repository.

Dieses Thema setzt voraus, dass Sie Milvus Operator installiert haben.

Sie müssen eine Konfigurationsdatei für die Verwendung von Milvus Operator angeben, um einen Milvus-Cluster zu starten.

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

Sie müssen nur die Codevorlage in milvus_cluster_default.yaml bearbeiten, um die Abhängigkeiten von Dritten zu konfigurieren. In den folgenden Abschnitten wird beschrieben, wie Sie Objektspeicher, etcd und Pulsar konfigurieren.

Bevor Sie beginnen

Die folgende Tabelle zeigt, ob RocksMQ, NATS, Pulsar und Kafka im Standalone- und Clustermodus von Milvus unterstützt werden.

Es gibt noch weitere Einschränkungen bei der Angabe des Nachrichtenspeichers:

• Es wird nur ein Nachrichtenspeicher für eine Milvus-Instanz unterstützt. Es besteht jedoch Abwärtskompatibilität mit mehreren Nachrichtenspeichern für eine Instanz. Die Priorität ist wie folgt:
  • Standalone-Modus: RocksMQ (Standard) > Pulsar > Kafka
  • Clustermodus: Pulsar (Voreinstellung) > Kafka
  • Nats, die in 2.3 eingeführt wurden, nehmen aus Gründen der Abwärtskompatibilität nicht an diesen Prioritätsregeln teil.
• Der Nachrichtenspeicher kann nicht geändert werden, während das Milvus-System läuft.
• Es wird nur die Kafka-Version 2.x oder 3.x unterstützt.

RocksMQ konfigurieren

RocksMQ ist der Standard-Nachrichtenspeicher in Milvus Standalone.

Beispiel

Das folgende Beispiel konfiguriert einen RocksMQ-Dienst.

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

NATS konfigurieren

NATS ist ein alternativer Nachrichtenspeicher für NATS.

Beispiel

Im folgenden Beispiel wird ein NATS-Dienst konfiguriert.

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

Um den Nachrichtenspeicher von RocksMQ zu NATS zu migrieren, gehen Sie wie folgt vor:

1. Stoppen Sie alle DDL-Vorgänge.

2. Rufen Sie die FlushAll-API auf und stoppen Sie Milvus, sobald die Ausführung des API-Aufrufs beendet ist.

3. Ändern Sie msgStreamType in natsmq und nehmen Sie die erforderlichen Änderungen an den NATS-Einstellungen in spec.dependencies.natsmq vor.

4. Starten Sie Milvus erneut und überprüfen Sie, ob:

   • Ein Protokolleintrag, der mqType=natsmq lautet, ist in den Protokollen vorhanden.
   • Ein Verzeichnis mit dem Namen jetstream in dem in spec.dependencies.natsmq.server.storeDir angegebenen Verzeichnis vorhanden ist.

5. (Optional) Sichern und bereinigen Sie die Datendateien im RocksMQ-Speicherverzeichnis.

Pulsar konfigurieren

Pulsar verwaltet Protokolle der letzten Änderungen, gibt Stream-Protokolle aus und bietet Protokollabonnements. Die Konfiguration von Pulsar für die Nachrichtenspeicherung wird sowohl in Milvus standalone als auch in Milvus cluster unterstützt. Mit Milvus Operator können Sie Pulsar jedoch nur als Nachrichtenspeicher für Milvus-Cluster konfigurieren. Fügen Sie die erforderlichen Felder unter spec.dependencies.pulsar hinzu, um Pulsar zu konfigurieren.

pulsar unterstützt external und inCluster.

Externer Pulsar

external gibt die Verwendung eines externen Pulsar-Dienstes an. Die Felder zur Konfiguration eines externen Pulsar-Dienstes umfassen:

• external: Ein true Wert zeigt an, dass Milvus einen externen Pulsar-Dienst verwendet.
• endpoints: Die Endpunkte von Pulsar.

Beispiel

Das folgende Beispiel konfiguriert einen externen Pulsar-Dienst.

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

Interner Pulsar

inCluster zeigt an, dass beim Start eines Milvus-Clusters automatisch ein Pulsar-Dienst im Cluster gestartet wird.

Beispiel

Das folgende Beispiel konfiguriert einen internen Pulsar-Dienst.

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

Unter der Annahme, dass die Konfigurationsdatei den Namen milvuscluster.yaml trägt, führen Sie den folgenden Befehl aus, um die Konfiguration anzuwenden.

kubectl apply -f milvuscluster.yaml

Konfigurieren Sie Kafka

Pulsar ist der Standardspeicher für Nachrichten in einem Milvus-Cluster. Wenn Sie Kafka verwenden möchten, fügen Sie das optionale Feld msgStreamType hinzu, um Kafka zu konfigurieren.

kafka unterstützt external und inCluster.

Externes Kafka

external gibt die Verwendung eines externen Kafka-Dienstes an.

Folgende Felder werden zur Konfiguration eines externen Kafka-Dienstes verwendet:

• external: Der Wert true zeigt an, dass Milvus einen externen Kafka-Dienst verwendet.
• brokerList: Die Liste der Makler, an die die Nachrichten gesendet werden sollen.

Beispiel

Das folgende Beispiel konfiguriert einen externen Kafka-Dienst.

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-Konfigurationen werden in der Version operator v0.8.5 oder höher unterstützt.

Internes Kafka

inCluster gibt an, dass beim Start eines Milvus-Clusters automatisch ein Kafka-Dienst im Cluster gestartet wird.

Beispiel

Das folgende Beispiel konfiguriert einen internen Kafka-Dienst.

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

Hier finden Sie die vollständige Konfiguration für einen internen Kafka-Dienst. Fügen Sie die Konfigurationselemente nach Bedarf unter kafka.inCluster.values hinzu.

Unter der Annahme, dass die Konfigurationsdatei den Namen milvuscluster.yaml trägt, führen Sie den folgenden Befehl aus, um die Konfiguration anzuwenden.

kubectl apply -f milvuscluster.yaml

Was kommt als nächstes?

Erfahren Sie, wie Sie andere Milvus-Abhängigkeiten mit Milvus Operator konfigurieren können:

• Konfigurieren Sie Objektspeicher mit Milvus Operator
• Konfigurieren Sie Meta-Speicher mit Milvus Operator