🚀 Попробуйте Zilliz Cloud, полностью управляемый Milvus, бесплатно — ощутите 10-кратное увеличение производительности! Попробовать сейчас>

milvus-logo
LFAI
Главная
  • Руководство по администрированию
  • Home
  • Docs
  • Руководство по администрированию

  • Конфигурация

  • QueryNode с использованием локального диска

Настройка Milvus QueryNode с локальным диском

В этой статье описывается, как настроить Milvus QueryNode на использование локального дискового хранилища.

Обзор

Milvus - это векторная база данных, ориентированная на ИИ и предназначенная для эффективного хранения и извлечения огромных объемов векторных данных. Она идеально подходит для таких задач, как анализ изображений и видео, обработка естественного языка и рекомендательные системы. Для обеспечения оптимальной производительности очень важно минимизировать задержку чтения данных с диска. Для предотвращения задержек и поддержания стабильности системы настоятельно рекомендуется использовать локальные твердотельные накопители NVMe.

Ключевые функции локального дискового хранилища включают в себя:

  • Кэш чанков: Предварительная загрузка данных в локальный дисковый кэш для ускорения поиска.
  • MMap: Сопоставление содержимого файлов непосредственно в память для повышения эффективности использования памяти.
  • Индекс DiskANN: Требует дискового хранилища для эффективного управления индексами.

В этой статье мы сосредоточимся на развертывании Milvus Distributed на облачных платформах и на том, как настроить QueryNode на использование дискового хранилища NVMe. В следующей таблице перечислены рекомендуемые типы машин различных облачных провайдеров.

Облачный провайдерТип машины
AWSСерия R6id
GCPСерия N2
AzureСерия Lsv3
Alibaba Cloudсерия i3
Tencent CloudСерия 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

Чтобы создать хранилище Local SSD на кластерах Google Kubernetes Engine (GKE) и настроить рабочие нагрузки на потребление данных из эфемерного хранилища Local 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.

Azure

Чтобы создать набор масштабирования виртуальных машин (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. Вам необходимо изменить сценарий в соответствии с конкретной конфигурацией.

Alibaba Cloud и TecentCloud

Чтобы создать пул узлов, использующий тома Local 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-диске по умолчанию в containerd, выполните следующие действия:

  • Смонтируйте NVMe-диски.

    Убедитесь, что NVMe-диск правильно смонтирован на хост-машине. Вы можете смонтировать его в каталог по своему выбору. Например, если вы монтируете его в /mnt/nvme, убедитесь, что он правильно установлен и вы можете увидеть диск, доступный по адресу /mnt/nvme, запустив lsblk или df -h.

  • Обновите конфигурацию containerd.

    Измените конфигурацию 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.

    Перезапустите службу 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, выполнив следующие шаги:

Советы по развертыванию Milvus Distributed с помощью Helm

Подкад QueryNode по умолчанию использует NVMe-диски в качестве томов EmptyDir. Для обеспечения оптимальной производительности рекомендуется монтировать NVMe-диски на /var/lib/milvus/data внутри подкад QueryNode.

Подробнее о том, как развернуть Milvus Distributed с помощью Helm, читайте в разделе Запуск Milvus в Kubernetes с помощью Helm.

Советы по развертыванию Milvus Distributed с помощью Milvus Operator

Milvus Operator автоматически настраивает подкад QueryNode на использование NVMe-дисков в качестве томов EmptyDir. Рекомендуется добавить следующие конфигурации в пользовательский ресурс MilvusCluster:

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

Это обеспечит использование стручком QueryNode NVMe-диска в качестве тома данных. Подробнее о том, как развернуть Milvus Distributed с помощью Milvus Operator, читайте в разделе Запуск Milvus в Kubernetes с помощью Milvus Operator.

Попробуйте Managed Milvus бесплатно

Zilliz Cloud работает без проблем, поддерживается Milvus и в 10 раз быстрее.

Начать
Обратная связь

Была ли эта страница полезной?