Konfigurieren der Nachrichtenspeicherung mit dem Milvus Operator

In Milvus 3.x ist Woodpecker die Standard-Nachrichtenwarteschlange (siehe Woodpecker). Mit dem Milvus Operator können Sie außerdem RocksMQ, Pulsar oder Kafka konfigurieren, um Protokolle der letzten Änderungen zu verwalten, Stream-Protokolle auszugeben und Protokollabonnements bereitzustellen. In diesem Thema wird erläutert, wie Sie die Abhängigkeiten für den Nachrichtenspeicher konfigurieren, wenn Sie Milvus mit dem Milvus Operator installieren. Weitere Informationen finden Sie unter „Konfigurieren des Nachrichtenspeichers mit dem Milvus Operator “ im Milvus-Operator-Repository.

In diesem Abschnitt wird davon ausgegangen, dass Sie den Milvus Operator bereits bereitgestellt haben.

Sie müssen eine Konfigurationsdatei angeben, um mit Milvus Operator 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 lediglich die Codevorlage unter „ milvus_cluster_default.yaml “ bearbeiten, um Abhängigkeiten von Drittanbietern zu konfigurieren. In den folgenden Abschnitten wird erläutert, wie Sie den Objektspeicher, etcd und Pulsar jeweils konfigurieren.

Bevor Sie beginnen

Die folgende Tabelle zeigt, ob RocksMQ, Pulsar, Kafka und Woodpecker im Milvus-Standalone- und im Cluster-Modus unterstützt werden.

Es gibt außerdem weitere Einschränkungen bei der Festlegung des Nachrichtenspeichers:

• Pro Milvus-Instanz wird nur ein Nachrichtenspeicher unterstützt. Wir bieten jedoch weiterhin Abwärtskompatibilität mit mehreren für eine Instanz festgelegten Nachrichtenspeichern. Die Priorität ist wie folgt:
  • Standalone-Modus: Woodpecker (Standard) > RocksMQ > Pulsar > Kafka
  • Cluster-Modus: Woodpecker (Standard) > Pulsar > Kafka
• Der Nachrichtenspeicher kann nicht geändert werden, während das Milvus-System läuft.
• Es werden nur die Versionen Kafka 2.x oder 3.x unterstützt.
• Einschränkungen beim Upgrade: Einschränkungen bei den Nachrichtenwarteschlangen: Beim Upgrade auf Milvus v3.0.0 müssen Sie Ihre aktuelle Wahl der Nachrichtenwarteschlange beibehalten. Ein Wechsel zwischen verschiedenen Nachrichtenwarteschlangensystemen während des Upgrades wird nicht unterstützt. Die Unterstützung für den Wechsel des Nachrichtenwarteschlangensystems wird in zukünftigen Versionen verfügbar sein.

RocksMQ konfigurieren

RocksMQ war bis zur Version 2.5.x der Standard-Nachrichtenspeicher in Milvus Standalone (ab Version 2.6.x durch Woodpecker ersetzt).

Beispiel

Im folgenden Beispiel wird ein RocksMQ-Dienst konfiguriert.

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

Wichtige Konfigurationsoptionen:

• msgStreamType: rocksmq: Legt RocksMQ explizit als Nachrichtenwarteschlange fest
• persistence.enabled: Aktiviert den persistenten Speicher für RocksMQ-Daten
• persistence.pvcDeletion: Wenn „true“, wird das PVC gelöscht, sobald die Milvus-Instanz gelöscht wird
• persistentVolumeClaim.spec: Standardmäßige Kubernetes-PVC-Spezifikation
• accessModes: In der Regel „ ReadWriteOnce “ für Blockspeicher
• storageClassName: Die Speicherklasse Ihres Clusters
• storage: Größe des persistenten Volumes

Woodpecker konfigurieren

Woodpecker ist ein cloud-natives Write-Ahead-Log (WAL), das für Objektspeicher entwickelt wurde. Es bietet hohen Durchsatz, geringen Betriebsaufwand und nahtlose Skalierbarkeit. Weitere Informationen finden Sie unter Woodpecker.

Pulsar konfigurieren

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

pulsar Unterstützt „ external “ und „ inCluster “.

„External Pulsar“

external Gibt die Verwendung eines externen Pulsar-Dienstes an. Zu den Feldern zur Konfiguration eines externen Pulsar-Dienstes gehören:

• external: Ein Wert unter „ true “ gibt an, dass Milvus einen externen Pulsar-Dienst nutzt.
• 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: {}           

„Internal Pulsar“

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

Beispiel

Das folgende Beispiel zeigt die Konfiguration eines internen Pulsar-Dienstes.

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

Angenommen, die Konfigurationsdatei heißt „ milvuscluster.yaml “, führen Sie den folgenden Befehl aus, um die Konfiguration zu übernehmen.

kubectl apply -f milvuscluster.yaml

Kafka konfigurieren

Pulsar war bis zur Version 2.5.x der Standard-Nachrichtenspeicher in einem Milvus-Cluster (ab Version 2.6.x durch Woodpecker ersetzt). 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.

Zu den Feldern zur Konfiguration eines externen Kafka-Dienstes gehören:

• external: Ein Wert von „ true “ gibt an, dass Milvus einen externen Kafka-Dienst verwendet.
• brokerList: Die Liste der Broker, 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 ab Operator-Version v0.8.5 unterstützt.

„Internal Kafka“

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

Beispiel

Das folgende Beispiel zeigt die Konfiguration eines internen Kafka-Dienstes.

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

Die vollständigen Konfigurationselemente zur Einrichtung eines internen Kafka-Dienstes finden Sie hier. Fügen Sie bei Bedarf Konfigurationselemente unter „ kafka.inCluster.values “ hinzu.

Angenommen, die Konfigurationsdatei heißt „ milvuscluster.yaml “, führen Sie den folgenden Befehl aus, um die Konfiguration zu übernehmen.

kubectl apply -f milvuscluster.yaml

Was kommt als Nächstes

Erfahren Sie, wie Sie andere Milvus-Abhängigkeiten mit dem Milvus Operator konfigurieren:

• Objektspeicher mit dem Milvus Operator konfigurieren
• Meta-Speicher mit dem Milvus Operator konfigurieren