🚀 جرب Zilliz Cloud، الـ Milvus المدارة بالكامل، مجاناً — تجربة أداء أسرع بـ 10 أضعاف! جرب الآن>>

milvus-logo
LFAI
الصفحة الرئيسية
  • دليل الإدارة
  • Home
  • Docs
  • دليل الإدارة

  • إدارة التبعيات

  • مع مشغل ميلفوس

  • تخزين الكائنات

تكوين تخزين الكائنات باستخدام مشغل Milvus

يستخدم Milvus MinIO أو S3 كمخزن كائنات لاستمرار الملفات واسعة النطاق، مثل ملفات الفهرس والسجلات الثنائية. يقدم هذا الموضوع كيفية تكوين تبعيات تخزين الكائنات عند تثبيت Milvus مع مشغل 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 على التوالي.

تكوين تخزين الكائنات

تستخدم مجموعة Milvus العنقودية MinIO أو S3 كمخزن كائنات لاستمرار الملفات واسعة النطاق، مثل ملفات الفهرس والسجلات الثنائية. أضف الحقول المطلوبة ضمن spec.dependencies.storage لتكوين تخزين الكائنات، الخيارات الممكنة هي external و inCluster.

تخزين الكائنات الداخلية

بشكل افتراضي، يقوم مشغل Milvus بنشر MinIO داخل المجموعة لـ Milvus. فيما يلي مثال على التكوين لتوضيح كيفية استخدام MinIO كمخزن كائنات داخلي.

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  dependencies:
    # Omit other fields ...
    storage:
      inCluster:
        values:
          mode: standalone
          resources:
            requests:
              memory: 100Mi
        deletionPolicy: Delete # Delete | Retain, default: Retain
        pvcDeletion: true # default: false

بعد تطبيق التكوين أعلاه، سيتم تشغيل MinIO داخل الكتلة في الوضع المستقل مع حد ذاكرة يصل إلى 100 ميغابايت. لاحظ أن

  • يحدد الحقل deletionPolicy سياسة الحذف الخاصة بـ MinIO داخل الكتلة. يتم تعيينه افتراضيًا على Delete ولديه Retain كخيار بديل.

    • Delete يشير إلى أن تخزين الكائنات داخل الكتلة يتم حذفه عند إيقاف مثيل Milvus الخاص بك.
    • Retain يشير إلى أنه يتم الاحتفاظ بمخزن الكائنات داخل الكتلة كخدمة تبعية لبدء تشغيل مثيل Milvus الخاص بك في وقت لاحق.
  • يحدد الحقل pvcDeletion ما إذا كان سيتم حذف PVC(مطالبة وحدة التخزين الدائمة) عند حذف وحدة تخزين الكائنات داخل الكتلة MinIO.

الحقول الموجودة ضمن inCluster.values هي نفسها الموجودة في مخطط Milvus Helm، ويمكنك العثور عليها هنا.

تخزين الكائنات الخارجية

يشير استخدام external في ملف YAML القالب إلى استخدام خدمة تخزين كائنات خارجية. لاستخدام وحدة تخزين كائنات خارجية، تحتاج إلى تعيين الحقول بشكل صحيح ضمن spec.dependencies.storage و spec.config.minio في ملف Milvus CRD.

استخدام خدمة الويب Amazon Web Service (AWS) S3 كمخزن كائنات خارجي

  • تكوين الوصول إلى AWS S3 بواسطة AK/SK

    يمكن الوصول إلى دلو S3 عادةً عن طريق زوج من مفتاح وصول ومفتاح سري للوصول. يمكنك إنشاء كائن Secret لتخزينها في Kubernetes الخاص بك على النحو التالي:

    # # change the <parameters> to match your environment
    apiVersion: v1
    kind: Secret
    metadata:
      name: my-release-s3-secret
    type: Opaque
    stringData:
      accesskey: <my-access-key>
      secretkey: <my-secret-key>
    

    ثم يمكنك تكوين دلو AWS S3 كمخزن كائن خارجي:

    # # change the <parameters> to match your environment
    apiVersion: milvus.io/v1beta1
    kind: Milvus
    metadata:
      name: my-release
      labels:
        app: milvus
    spec:
      # Omit other fields ...
      config:
        minio:
          # your bucket name
          bucketName: <my-bucket>
          # Optional, config the prefix of the bucket milvus will use
          rootPath: milvus/my-release
          useSSL: true
      dependencies:
        storage:
          # enable external object storage
          external: true
          type: S3 # MinIO | S3
          # the endpoint of AWS S3
          endpoint: s3.amazonaws.com:443
          # the secret storing the access key and secret key
          secretRef: "my-release-s3-secret"
    
  • تكوين الوصول إلى AWS S3 بواسطة AssumeRole

    وبدلاً من ذلك، يمكنك جعل Milvus يصل إلى دلو AWS S3 الخاص بك باستخدام AssumeRole، بحيث يتم تضمين بيانات الاعتماد المؤقتة فقط بدلاً من AK/SK الفعلي الخاص بك.

    إذا كان هذا هو ما تفضله، فأنت بحاجة إلى إعداد دور على وحدة تحكم AWS الخاصة بك والحصول على ARN الخاص به، والذي عادةً ما يكون على شكل arn:aws:iam::<your account id>:role/<role-name>.

    ثم قم بإنشاء كائن ServiceAccount لتخزينه في Kubernetes الخاص بك على النحو التالي:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: my-release-sa
      annotations:
        eks.amazonaws.com/role-arn: <my-role-arn>
    

    بمجرد تعيين كل شيء، قم بالرجوع إلى ServiceAccount أعلاه في ملف YAML القالب، وقم بتعيين spec.config.minio.useIAM إلى true لتمكين AssumeRole.

    apiVersion: milvus.io/v1beta1
    kind: Milvus
    metadata:
      name: my-release
      labels:
        app: milvus
    spec:
      # Omit other fields ...
      components:
        # use the above ServiceAccount
        serviceAccountName: my-release-sa
      config:
        minio:
          # enable AssumeRole
          useIAM: true
          # Omit other fields ...
      dependencies:
        storage:
          # Omit other fields ...
          # Note: you must use regional endpoint here, otherwise the minio client that milvus uses will fail to connect
          endpoint: s3.<my-bucket-region>.amazonaws.com:443
          secretRef: "" # we don't need to specify the secret here
    

استخدم Google Cloud Storage (GCS) كمخزن كائنات خارجي

تخزين كائنات AWS S3 ليس الخيار الوحيد. يمكنك أيضًا استخدام خدمة تخزين الكائنات من موفري السحابة العامة الآخرين، مثل Google Cloud.

  • تكوين الوصول إلى GCS بواسطة AK/SK

    يشبه التكوين في الغالب تكوين استخدام AWS S3. ما زلت بحاجة إلى إنشاء كائن Secret لتخزين بيانات الاعتماد الخاصة بك في Kubernetes الخاص بك.

    # # change the <parameters> to match your environment
    apiVersion: v1
    kind: Secret
    metadata:
      name: my-release-gcp-secret
    type: Opaque
    stringData:
      accesskey: <my-access-key>
      secretkey: <my-secret-key>
    

    بعد ذلك، ما عليك سوى تغيير endpoint إلى storage.googleapis.com:443 وتعيين spec.config.minio.cloudProvider إلى gcp على النحو التالي:

    # # change the <parameters> to match your environment
    apiVersion: milvus.io/v1beta1
    kind: Milvus
    metadata:
      name: my-release
      labels:
        app: milvus
    spec:
      # Omit other fields ...
      config:
        minio:
          cloudProvider: gcp
      dependencies:
        storage:
          # Omit other fields ...
          endpoint: storage.googleapis.com:443
    
  • تكوين وصول GCS عن طريق AssumeRole

    على غرار AWS S3، يمكنك أيضًا استخدام هوية عبء العمل للوصول إلى GCS ببيانات اعتماد مؤقتة إذا كنت تستخدم GKE كمجموعة Kubernetes الخاصة بك.

    يختلف الشرح التوضيحي لـ ServiceAccount عن ذلك الخاص بـ AWS EKS. تحتاج إلى تحديد اسم حساب خدمة GCP بدلاً من الدور ARN.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: my-release-sa
      annotations:
        iam.gke.io/gcp-service-account: <my-gcp-service-account-name>
    

    بعد ذلك، يمكنك تهيئة مثيل Milvus الخاص بك لاستخدام ServiceAccount أعلاه وتمكين AssumeRole عن طريق تعيين spec.config.minio.useIAM إلى true على النحو التالي:

    labels:
        app: milvus
    spec:
      # Omit other fields ...
      components:
        # use the above ServiceAccount
        serviceAccountName: my-release-sa
      config:
        minio:
          cloudProvider: gcp
          # enable AssumeRole
          useIAM: true
          # Omit other fields ...  
    

ما التالي

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

جرب Managed Milvus مجاناً

Zilliz Cloud خالي من المتاعب، ويعمل بواسطة Milvus ويعمل بسرعة 10 أضعاف.

ابدأ
التعليقات

هل كانت هذه الصفحة مفيدة؟