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

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

  • التكوين

  • عقدة الاستعلام باستخدام القرص المحلي

تكوين Milvus QueryNode مع القرص المحلي

توضح هذه المقالة كيفية تكوين Milvus QueryNode Milvus QueryNode لاستخدام تخزين القرص المحلي.

نظرة عامة

Milvus هي قاعدة بيانات متجهة تركز على الذكاء الاصطناعي مصممة خصيصًا لتخزين واسترجاع كميات هائلة من البيانات المتجهة بكفاءة. وهي مثالية لمهام مثل تحليل الصور والفيديو ومعالجة اللغة الطبيعية وأنظمة التوصيات. لضمان الأداء الأمثل، من الضروري تقليل زمن انتقال القراءة على القرص إلى الحد الأدنى. يوصى بشدة باستخدام محركات أقراص NVMe SSD المحلية لمنع التأخير والحفاظ على استقرار النظام.

تتضمن الميزات الرئيسية التي يتم فيها تشغيل تخزين القرص المحلي ما يلي:

  • ذاكرة التخزين المؤقت للقطع: التحميل المسبق للبيانات في ذاكرة التخزين المؤقت للقرص المحلي للبحث بشكل أسرع.
  • MMap: تعيين محتويات الملف مباشرة في الذاكرة لتحسين كفاءة الذاكرة.
  • فهرس DiskANN: يتطلب تخزين القرص لإدارة الفهرس بكفاءة.

في هذه المقالة، سنركز على نشر Milvus Distributed على المنصات السحابية، وكيفية تكوين QueryNode لاستخدام تخزين القرص NVMe. يسرد الجدول التالي أنواع الأجهزة الموصى بها لمختلف موفري السحابة.

مزود السحابةنوع الجهاز
AWSسلسلة R6id
GCPسلسلة N2
أزورسلسلة Lsv3
علي بابا كلاودسلسلة i3
سحابة تينسنتسلسلة IT5

توفر أنواع الأجهزة هذه تخزين قرص NVMe. يمكنك استخدام الأمر lsblk في مثيلات هذه الأنواع من الأجهزة للتحقق مما إذا كانت تحتوي على وحدة تخزين قرص NVMe. إذا كان لديهم ذلك، يمكنك المتابعة إلى الخطوة التالية.

$ lsblk | grep nvme
nvme0n1     259:0    0 250.0G  0 disk 
nvme1n1     259:1    0 250.0G  0 disk 

تكوين Kubernetes لاستخدام القرص المحلي

لتهيئة QueryNode من Milvus Distributed لاستخدام تخزين قرص NVMe، تحتاج إلى تكوين العقد العاملة لمجموعات Kubernetes المستهدفة لتخزين الحاويات والصور على قرص NVMe. يختلف الإجراء الخاص بذلك اعتمادًا على موفري السحابة.

AWS

عند استخدام Amazon EKS، يمكنك تخصيص العُقد المُدارة باستخدام قوالب التشغيل، حيث يمكنك تحديد إعدادات التكوين لمجموعات العقد الخاصة بك. فيما يلي مثال على كيفية تركيب قرص NVMe على العقد العاملة في مجموعة Amazon EKS الخاصة بك:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
echo "Running custom user data script"
if ( lsblk | fgrep -q nvme1n1 ); then
    mkdir -p /mnt/data /var/lib/kubelet /var/lib/docker
    mkfs.xfs /dev/nvme1n1
    mount /dev/nvme1n1 /mnt/data
    chmod 0755 /mnt/data
    mv /var/lib/kubelet /mnt/data/
    mv /var/lib/docker /mnt/data/
    ln -sf /mnt/data/kubelet /var/lib/kubelet
    ln -sf /mnt/data/docker /var/lib/docker
    UUID=$(lsblk -f | grep nvme1n1 | awk '{print $3}')
    echo "UUID=$UUID     /mnt/data   xfs    defaults,noatime  1   1" >> /etc/fstab
fi
echo 10485760 > /proc/sys/fs/aio-max-nr

--==MYBOUNDARY==--

في المثال أعلاه، نفترض أن قرص NVMe هو /dev/nvme1n1. تحتاج إلى تعديل البرنامج النصي ليتوافق مع التكوين الخاص بك.

للحصول على التفاصيل، راجع تخصيص العقد المدارة باستخدام قوالب التشغيل.

GCP

لتوفير تخزين محلي SSD على مجموعات محرك Google Kubernetes Engine (GKE)، وتكوين أحمال العمل لاستهلاك البيانات من التخزين المؤقت المدعوم بـ SSD المحلي المدعوم بـ SSD والمتصل بالعقد في مجموعتك، قم بتشغيل الأمر التالي:

gcloud container node-pools create ${POOL_NAME} \
    --cluster=${CLUSTER_NAME} \
    --ephemeral-storage-local-ssd count=${NUMBER_OF_DISKS} \
    --machine-type=${MACHINE_TYPE}

لمزيد من التفاصيل، راجع توفير تخزين SSD محلي على GKE.

أزور

لإنشاء مجموعة مقياس آلة افتراضية (VMSS) مع وحدة تخزين أقراص NVMe محلية، تحتاج إلى تمرير بيانات مخصصة إلى مثيلات الآلة الافتراضية. فيما يلي مثال على كيفية إرفاق قرص NVMe بمثيلات الآلة الافتراضية في VMSS:

mdadm -Cv /dev/md0 -l0 -n2 /dev/nvme0n1 /dev/nvme1n1
mdadm -Ds > /etc/mdadm/mdadm.conf 
update-initramfs -u

mkfs.xfs /dev/md0
mkdir -p /var/lib/kubelet
echo '/dev/md0 /var/lib/kubelet xfs defaults 0 0' >> /etc/fstab
mount -a

في المثال أعلاه، نفترض أن أقراص NVMe هي /dev/nvme0n1 و /dev/nvme1n1. تحتاج إلى تعديل البرنامج النصي لمطابقة التكوين الخاص بك.

علي بابا كلاود وتيسنت كلاود

لإنشاء تجمع عقدة يستخدم وحدات تخزين SSD محلية، نحتاج إلى تمرير بيانات مخصصة. فيما يلي مثال على البيانات المخصصة.

#!/bin/bash
echo "nvme init start..."
mkfs.xfs /dev/nvme0n1
mkdir -p /mnt/data
echo '/dev/nvme0n1 /mnt/data/ xfs defaults 0 0' >> /etc/fstab
mount -a

mkdir -p /mnt/data/kubelet /mnt/data/containerd /mnt/data/log/pods
mkdir -p  /var/lib/kubelet /var/lib/containerd /var/log/pods

echo '/mnt/data/kubelet /var/lib/kubelet none defaults,bind 0 0' >> /etc/fstab
echo '/mnt/data/containerd /var/lib/containerd none defaults,bind 0 0' >> /etc/fstab
echo '/mnt/data/log/pods /var/log/pods none defaults,bind 0 0' >> /etc/fstab
mount -a

echo "nvme init end..."

في المثال أعلاه، نفترض أن قرص NVMe هو /dev/nvme0n1. تحتاج إلى تعديل البرنامج النصي لمطابقة التكوين الخاص بك.

IDC الخاص بك

إذا كنت تقوم بتشغيل IDC الخاص بك وتريد تكوين الحاويات الخاصة بك لاستخدام نظام الملفات على قرص NVMe المثبت حديثًا بشكل افتراضي في الحاوية (Contirond)، فاتبع الخطوات التالية:

  • قم بتركيب أقراص NVMe.

    تأكد من تركيب قرص NVMe بشكل صحيح على جهازك المضيف. يمكنك تحميله إلى دليل من اختيارك. على سبيل المثال، إذا قمت بتحميله على /mnt/nvme ، فتأكد من إعداده بشكل صحيح ويمكنك رؤية القرص متاحًا على /mnt/nvme عن طريق تشغيل lsblk أو df -h.

  • تحديث تكوين الحاويةd.

    قم بتعديل تكوين containerd لاستخدام التثبيت الجديد كدليل جذر لتخزين الحاوية.

    sudo mkdir -p /mnt/nvme/containerd /mnt/nvme/containerd/state
    sudo vim /etc/containerd/config.toml
    

    حدد موقع القسم [plugins."io.containerd.grpc.v1.cri".containerd] ، وقم بتعديل الإعدادات snapshotter و root على النحو التالي :

    [plugins."io.containerd.grpc.v1.cri".containerd]
    snapshotter = "overlayfs"
    root = "/mnt/nvme/containerd"
    state = "/mnt/nvme/containerd/state"
    
  • أعد تشغيل الحاوية.

    أعد تشغيل خدمة containerd لتطبيق التغييرات.

    sudo systemctl restart containerd
    

التحقق من أداء القرص

يُنصح بالتحقق من أداء القرص باستخدام Fio، وهي أداة شائعة لقياس أداء القرص. فيما يلي مثال على كيفية تشغيل Fio لاختبار أداء القرص.

  • انشر جراب الاختبار على العقدة مع قرص NVMe.

    kubectl create -f ubuntu.yaml
    

    الملف ubuntu.yaml على النحو التالي:

    apiVersion: v1
    kind: Pod
    metadata:
    name: ubuntu
    spec:
    containers:
    - name: ubuntu
        image: ubuntu:latest
        command: ["sleep", "86400"]
        volumeMounts:
        - name: data-volume
            mountPath: /data
    volumes:
        - name: data-volume
        emptyDir: {}
    
  • قم بتشغيل Fio لاختبار أداء القرص.

    # enter the container
    kubectl exec pod/ubuntu -it bash
    
    # in container
    apt-get update
    apt-get install fio -y
    
    # change to the mounted dir
    cd /data
    
    # write 10GB
    fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4K -size=10G -numjobs=10 -runtime=600 -group_reporting -filename=test -name=Rand_Write_IOPS_Test
    
    # verify the read speed
    # compare with the disk performance indicators provided by various cloud providers.
    fio --filename=test --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=64 --runtime=120 --numjobs=128 --time_based --group_reporting --name=iops-test-job --eta-newline=1  --readonly
    

    ويجب أن يبدو الإخراج هكذا:

    Jobs: 128 (f=128): [r(128)][100.0%][r=1458MiB/s][r=373k IOPS][eta 00m:00s]
    iops-test-job: (groupid=0, jobs=128): err= 0: pid=768: Mon Jun 24 09:35:06 2024
    read: IOPS=349k, BW=1364MiB/s (1430MB/s)(160GiB/120067msec)
        slat (nsec): min=765, max=530621k, avg=365836.09, stdev=4765464.96
        clat (usec): min=35, max=1476.0k, avg=23096.78, stdev=45409.13
        lat (usec): min=36, max=1571.6k, avg=23462.62, stdev=46296.74
        clat percentiles (usec):
        |  1.00th=[    69],  5.00th=[    79], 10.00th=[    85], 20.00th=[    95],
        | 30.00th=[   106], 40.00th=[   123], 50.00th=[   149], 60.00th=[ 11469],
        | 70.00th=[ 23462], 80.00th=[ 39584], 90.00th=[ 70779], 95.00th=[103285],
        | 99.00th=[189793], 99.50th=[244319], 99.90th=[497026], 99.95th=[591397],
        | 99.99th=[767558]
    bw (  MiB/s): min=  236, max= 4439, per=100.00%, avg=1365.82, stdev= 5.02, samples=30591
    iops        : min=60447, max=1136488, avg=349640.62, stdev=1284.65, samples=30591
    lat (usec)   : 50=0.01%, 100=24.90%, 250=30.47%, 500=0.09%, 750=0.31%
    lat (usec)   : 1000=0.08%
    lat (msec)   : 2=0.32%, 4=0.59%, 10=1.86%, 20=8.20%, 50=17.29%
    lat (msec)   : 100=10.62%, 250=4.80%, 500=0.38%, 750=0.09%, 1000=0.01%
    lat (msec)   : 2000=0.01%
    cpu          : usr=0.20%, sys=0.48%, ctx=838085, majf=0, minf=9665
    IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
        submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
        complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
        issued rwts: total=41910256,0,0,0 short=0,0,0,0 dropped=0,0,0,0
        latency   : target=0, window=0, percentile=100.00%, depth=64
    

نشر ميلفوس الموزع

بمجرد أن تكون نتائج التحقق مرضية، يمكنك نشر Milvus Distributed بالخطوات التالية:

نصائح لنشر Milvus Distributed باستخدام Helm

تستخدم كبسولة QueryNode أقراص NVMe كوحدات تخزين EmptyDir بشكل افتراضي. يُنصح بتحميل أقراص NVMe على /var/lib/milvus/data داخل كبسولات QueryNode لضمان الأداء الأمثل.

للحصول على تفاصيل حول كيفية نشر Milvus Distributed باستخدام Helm، راجع تشغيل Milvus في Kubernetes باستخدام Helm.

نصائح لنشر ميلفوس الموزع باستخدام مشغل ميلفوس

يقوم مشغل Milvus تلقائيًا بتكوين جراب QueryNode تلقائيًا لاستخدام أقراص NVMe كوحدات تخزين EmptyDir. يُنصح بإضافة التكوينات التالية إلى المورد المخصص MilvusCluster:

...
spec:
  components:
    queryNode:
      volumeMounts:
      - mountPath: /var/lib/milvus/data
        name: data
      volumes:
      - emptyDir:
        name: data

سيضمن ذلك أن تستخدم جراب QueryNode قرص NVMe كوحدة تخزين بيانات. للحصول على تفاصيل حول كيفية نشر ميلفوس الموزعة باستخدام مشغل ميلفوس، راجع تشغيل ميلفوس في Kubernetes باستخدام مشغل ميلفوس.

جرب Managed Milvus مجاناً

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

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

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