تكوين تخزين الرسائل مع مشغل Milvus
يستخدم Milvus RocksMQ أو Pulsar أو Kafka لإدارة سجلات التغييرات الأخيرة، وإخراج سجلات الدفق، وتوفير اشتراكات السجل. يقدم هذا الموضوع كيفية تكوين تبعيات تخزين الرسائل عند تثبيت Milvus مع مشغل Milvus. لمزيد من التفاصيل، راجع تكوين تخزين الرسائل مع مشغل Milvus في مستودع مشغل Milvus.
يفترض هذا الموضوع أنك قمت بنشر مشغل Milvus.
تحتاج إلى تحديد ملف تكوين لاستخدام مشغل Milvus لبدء تشغيل مجموعة 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 و NATS و Pulsar و Kafka مدعومة في وضع Milvus المستقل ووضع المجموعة.
RocksMQ | ناتس | بولسار | كافكا | |
---|---|---|---|---|
الوضع المستقل | ✔️ | ✔️ | ✔️ | ✔️ |
الوضع العنقودي | ✖️ | ✖️ | ✔️ | ✔️ |
هناك أيضًا قيود أخرى لتحديد تخزين الرسائل:
- يتم دعم مخزن رسائل واحد فقط لمثيل Milvus واحد. ومع ذلك لا يزال لدينا توافق مع الإصدارات السابقة مع تعيين مخازن رسائل متعددة لمثيل واحد. الأولوية كما يلي:
- الوضع المستقل: RocksMQ (افتراضي)> بولسار > كافكا
- الوضع العنقودي: بولسار (افتراضي)> كافكا > كافكا
- لا تشارك النتات المقدمة في 2.3 في قواعد الأولوية هذه للتوافق مع الإصدارات السابقة.
- لا يمكن تغيير تخزين الرسائل أثناء تشغيل نظام ميلفوس.
- يتم دعم إصدار كافكا 2.x أو 3.x فقط.
تكوين RocksMQ
RocksMQ هو مخزن الرسائل الافتراضي في نظام Milvus المستقل.
في الوقت الحالي، يمكنك فقط تكوين RocksMQ كمخزن للرسائل في نظام Milvus المستقل باستخدام مشغل Milvus.
مثال
يقوم المثال التالي بتكوين خدمة 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
: عندما يكون صحيحًا، سيتم حذف PVC عندما يتم حذف مثيل MilvuspersistentVolumeClaim.spec
: مواصفات Kubernetes PVC القياسيةaccessModes
: عادةًReadWriteOnce
لتخزين الكتلstorageClassName
: فئة التخزين الخاصة بمجموعتكstorage
: حجم وحدة التخزين الثابتة
تكوين NATS
NATS هو تخزين رسائل بديل لـ NATS.
مثال
يقوم المثال التالي بتكوين خدمة 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: {}
لترحيل تخزين الرسائل من RocksMQ إلى NATS، قم بما يلي:
أوقف جميع عمليات DDL.
قم باستدعاء واجهة برمجة التطبيقات FlushAll ثم أوقف Milvus بمجرد انتهاء تنفيذ استدعاء واجهة برمجة التطبيقات.
تغيير
msgStreamType
إلىnatsmq
وإجراء التغييرات اللازمة على إعدادات NATS فيspec.dependencies.natsmq
.ابدأ تشغيل ميلفوس مرة أخرى وتحقق مما إذا كان:
- إدخال سجل يقرأ
mqType=natsmq
موجود في السجلات. - يوجد دليل باسم
jetstream
في الدليل المحدد فيspec.dependencies.natsmq.server.storeDir
.
- إدخال سجل يقرأ
(اختياري) قم بالنسخ الاحتياطي وتنظيف ملفات البيانات في دليل تخزين RocksMQ.
الاختيار بين RocksMQ و NATS؟
يستخدم RocksMQ CGO للتفاعل مع RocksDB ويدير الذاكرة بنفسه، بينما يقوم NATS المدمج في تثبيت Milvus بتفويض إدارة الذاكرة إلى جامع القمامة الخاص بـ Go (GC).
في السيناريو الذي تكون فيه حزمة البيانات أصغر من 64 كيلوبايت، يتفوق RocksDB من حيث استخدام الذاكرة واستخدام وحدة المعالجة المركزية ووقت الاستجابة. من ناحية أخرى، إذا كانت حزمة البيانات أكبر من 64 كيلوبايت، يتفوق NATS من حيث وقت الاستجابة مع وجود ذاكرة كافية وجدولة GC مثالية.
في الوقت الحالي، يُنصح باستخدام NATS للتجارب فقط.
تكوين بولسار
يدير Pulsar سجلات التغييرات الأخيرة، ويخرج سجلات الدفق، ويوفر اشتراكات السجل. يتم دعم تكوين Pulsar لتخزين الرسائل في كل من Milvus المستقل و Milvus cluster. ومع ذلك، مع مشغل Milvus، يمكنك فقط تكوين Pulsar كمخزن للرسائل لمجموعة Milvus العنقودية. أضف الحقول المطلوبة ضمن spec.dependencies.pulsar
لتكوين Pulsar.
pulsar
يدعم external
و inCluster
.
بولسار خارجي
external
يشير إلى استخدام خدمة بولسار خارجية. تتضمن الحقول المستخدمة لتكوين خدمة بولسار خارجية ما يلي:
external
: تشير القيمةtrue
إلى أن ميلفوس يستخدم خدمة بولسار خارجية.endpoints
: نقاط نهاية بولسار.
مثال
يقوم المثال التالي بتكوين خدمة بولسار خارجية.
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: {}
بولسار داخلي
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: {}
pulsar.inCluster.values
كما هو موضح في المثال السابق.بافتراض أن ملف التكوين اسمه milvuscluster.yaml
، قم بتشغيل الأمر التالي لتطبيق التكوين.
kubectl apply -f milvuscluster.yaml
تكوين كافكا
Pulsar هو مخزن الرسائل الافتراضي في مجموعة Milvus. إذا كنت تريد استخدام كافكا، أضف الحقل الاختياري msgStreamType
لتكوين كافكا.
kafka
يدعم external
و inCluster
.
كافكا الخارجية
external
يشير إلى استخدام خدمة كافكا خارجية.
تتضمن الحقول المستخدمة لتكوين خدمة كافكا خارجية ما يلي:
external
: تشير القيمةtrue
إلى أن ميلفوس يستخدم خدمة كافكا خارجية.brokerList
: قائمة الوسطاء لإرسال الرسائل إليهم.
مثال
يقوم المثال التالي بتكوين خدمة كافكا خارجية.
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 في المشغل الإصدار 0.8.5 أو إصدار أعلى.
كافكا الداخلية
inCluster
يشير إلى أنه عند بدء تشغيل مجموعة Milvus، تبدأ خدمة كافكا تلقائيًا في المجموعة.
مثال
يقوم المثال التالي بتكوين خدمة كافكا داخلية.
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.inCluster.values
.
على افتراض أن ملف التكوين اسمه milvuscluster.yaml
، قم بتشغيل الأمر التالي لتطبيق التكوين.
kubectl apply -f milvuscluster.yaml
ما التالي
تعرف على كيفية تكوين تبعيات Milvus الأخرى باستخدام مشغل Milvus: