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

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

Обзор

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

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

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

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

Эти типы машин обеспечивают дисковое хранилище 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==--

Подробнее см. в разделе Настройка управляемых узлов с помощью шаблонов запуска.

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

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..."

Собственный 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.