تكوين تخزين الرسائل باستخدام Milvus Operator

في Milvus 3.x، يُعد Woodpecker قائمة انتظار الرسائل الافتراضية (انظر Woodpecker). باستخدام Milvus Operator، يمكنك أيضًا تكوين RocksMQ أو Pulsar أو Kafka لإدارة سجلات التغييرات الحديثة، وإخراج سجلات التدفق، وتوفير اشتراكات السجلات. يقدم هذا الموضوع شرحًا لكيفية تكوين تبعيات تخزين الرسائل عند تثبيت Milvus باستخدام Milvus Operator. لمزيد من التفاصيل، راجع «تكوين تخزين الرسائل باستخدام Milvus Operator» في مستودع Milvus Operator.

يفترض هذا الموضوع أنك قد قمت بنشر Milvus Operator.

تحتاج إلى تحديد ملف تكوين لاستخدام Milvus Operator لبدء تشغيل مجموعة Milvus.

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

ما عليك سوى تعديل قالب الكود الموجود في « milvus_cluster_default.yaml » لتكوين التبعيات الخارجية. تشرح الأقسام التالية كيفية تكوين تخزين الكائنات وetcd وPulsar على التوالي.

قبل البدء

يوضح الجدول أدناه ما إذا كانت RocksMQ وPulsar وKafka وWoodpecker مدعومة في وضع Milvus المستقل ووضع الكتلة.

هناك أيضًا قيود أخرى تتعلق بتحديد مخزن الرسائل:

• يتم دعم مخزن رسائل واحد فقط لكل مثيل من Milvus. ومع ذلك، لا يزال لدينا توافق مع الإصدارات السابقة في حالة تعيين مخازن رسائل متعددة لمثيل واحد. وترتيب الأولوية كما يلي:
  • الوضع المستقل: Woodpecker (الافتراضي) > RocksMQ > Pulsar > Kafka
  • الوضع العنقودي: Woodpecker (الافتراضي) > Pulsar > Kafka
• لا يمكن تغيير تخزين الرسائل أثناء تشغيل نظام Milvus.
• يتم دعم إصدارات Kafka 2.x أو 3.x فقط.
• قيود الترقية: قيود قائمة انتظار الرسائل: عند الترقية إلى Milvus v3.0.2، يجب الحفاظ على اختيارك الحالي لقائمة انتظار الرسائل. لا يُدعم التبديل بين أنظمة قوائم انتظار الرسائل المختلفة أثناء الترقية. سيتوفر دعم تغيير أنظمة قوائم انتظار الرسائل في الإصدارات المستقبلية.

تكوين RocksMQ

كان RocksMQ هو مخزن الرسائل الافتراضي في Milvus المستقل حتى الإصدار 2.5.x (تم استبداله بـ Woodpecker بدءًا من الإصدار 2.6.x).

مثال

يوضح المثال التالي تكوين خدمة 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: {}

خيارات التهيئة الرئيسية:

• msgStreamType: rocksmq: يعيّن RocksMQ صراحةً كقائمة انتظار الرسائل
• persistence.enabled: تمكّن التخزين الدائم لبيانات RocksMQ
• persistence.pvcDeletion: عند تعيين القيمة إلى «true»، سيتم حذف PVC عند حذف مثيل Milvus
• persistentVolumeClaim.spec: مواصفات PVC القياسية في Kubernetes
• accessModes: عادةً ما يكون ReadWriteOnce للتخزين على شكل كتل
• storageClassName: فئة التخزين الخاصة بمجموعتك
• storage: حجم وحدة التخزين الدائمة

تكوين Woodpecker

Woodpecker هو سجل الكتابة المسبقة (WAL) الأصلي للسحابة والمصمم لتخزين الكائنات. ويوفر إنتاجية عالية وتكاليف تشغيل منخفضة وقابلية توسع سلسة. لمزيد من التفاصيل، راجع Woodpecker.

تكوين Pulsar

يدير Pulsar سجلات التغييرات الحديثة، ويُخرج سجلات التدفق، ويوفر اشتراكات السجلات. يتم دعم تكوين Pulsar لتخزين الرسائل في كل من Milvus المستقل ومجموعة Milvus. ومع ذلك، باستخدام Milvus Operator، لا يمكنك تكوين Pulsar كمساحة تخزين للرسائل إلا لمجموعة Milvus. أضف الحقول المطلوبة ضمن « spec.dependencies.pulsar » لتكوين Pulsar.

pulsar يدعم external و inCluster.

Pulsar الخارجي

external يشير إلى استخدام خدمة Pulsar خارجية. تشمل الحقول المستخدمة لتكوين خدمة Pulsar خارجية ما يلي:

• external: تشير قيمة true إلى أن Milvus يستخدم خدمة Pulsar خارجية.
• endpoints: نقاط نهاية Pulsar.

مثال

يُوضح المثال التالي تكوين خدمة Pulsar خارجية.

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 الداخلي

inCluster يشير إلى أنه عند بدء تشغيل مجموعة Milvus، تبدأ خدمة Pulsar تلقائيًا داخل المجموعة.

مثال

يوضح المثال التالي كيفية تكوين خدمة Pulsar داخلية.

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

بافتراض أن ملف التكوين يسمى milvuscluster.yaml ، قم بتشغيل الأمر التالي لتطبيق التكوين.

kubectl apply -f milvuscluster.yaml

تكوين Kafka

كان Pulsar هو مخزن الرسائل الافتراضي في مجموعة Milvus حتى الإصدار 2.5.x (وحل محله Woodpecker بدءًا من الإصدار 2.6.x). إذا كنت ترغب في استخدام Kafka، فأضف الحقل الاختياري msgStreamType لتكوين Kafka.

kafka يدعم external و inCluster.

Kafka خارجي

external يشير إلى استخدام خدمة Kafka خارجية.

تشمل الحقول المستخدمة لتكوين خدمة Kafka الخارجية ما يلي:

• external: تشير قيمة true إلى أن Milvus يستخدم خدمة Kafka خارجية.
• brokerList: قائمة الوسطاء الذين سيتم إرسال الرسائل إليهم.

مثال

يُوضح المثال التالي تكوين خدمة Kafka خارجية.

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 في الإصدار v0.8.5 أو الأحدث من المشغل.

Kafka الداخلي

inCluster يشير إلى أنه عند بدء تشغيل مجموعة Milvus، تبدأ خدمة كافكا تلقائيًا داخل المجموعة.

مثال

يوضح المثال التالي كيفية تكوين خدمة Kafka داخلية.

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

يمكنك العثور على عناصر التكوين الكاملة لتكوين خدمة Kafka الداخلية هنا. أضف عناصر التكوين حسب الحاجة ضمن " kafka.inCluster.values".

بافتراض أن ملف التكوين يسمى milvuscluster.yaml ، قم بتشغيل الأمر التالي لتطبيق التكوين.

kubectl apply -f milvuscluster.yaml

الخطوة التالية

تعرف على كيفية تكوين تبعيات Milvus الأخرى باستخدام Milvus Operator:

• تكوين تخزين الكائنات باستخدام Milvus Operator
• تكوين تخزين البيانات الوصفية باستخدام Milvus Operator