Configurar Milvus QueryNode con disco local

Este artículo describe cómo configurar Milvus QueryNode para utilizar almacenamiento en disco local.

Visión general

Milvus es una base de datos vectorial centrada en la Inteligencia Artificial diseñada para el almacenamiento y recuperación eficientes de grandes cantidades de datos vectoriales. Es ideal para tareas como el análisis de imágenes y vídeos, el procesamiento del lenguaje natural y los sistemas de recomendación. Para garantizar un rendimiento óptimo, es crucial minimizar la latencia de lectura del disco. El uso de unidades SSD NVMe locales es muy recomendable para evitar retrasos y mantener la estabilidad del sistema.

Entre las características clave en las que entra en juego el almacenamiento en disco local se incluyen:

• Caché de trozos: Precarga los datos en la caché de disco local para una búsqueda más rápida.
• MMap: Asigna el contenido de los archivos directamente a la memoria para mejorar la eficiencia de la memoria.
• Índice DiskANN: Requiere almacenamiento en disco para una gestión eficiente del índice.

En este artículo, nos centraremos en el despliegue de Milvus Distributed en plataformas en la nube y en cómo configurar el QueryNode para utilizar el almacenamiento en disco NVMe. La siguiente tabla enumera los tipos de máquina recomendados de varios proveedores de nube.

Estos tipos de máquinas proporcionan almacenamiento en disco NVMe. Puede utilizar el comando lsblk en las instancias de estos tipos de máquinas para comprobar si disponen de almacenamiento en disco NVMe. Si lo tienen, puede continuar con el siguiente paso.

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

Configurar Kubernetes para utilizar el disco local

Para configurar el QueryNode de Milvus Distributed para que utilice almacenamiento en disco NVMe, debe configurar los nodos trabajadores de los clústeres Kubernetes de destino para que almacenen los contenedores y las imágenes en un disco NVMe. El procedimiento para ello varía en función de los proveedores de nube.

AWS

Al utilizar Amazon EKS, puede personalizar los nodos administrados con plantillas de lanzamiento, en las que puede especificar los ajustes de configuración para sus grupos de nodos. A continuación se muestra un ejemplo de cómo montar un disco NVMe en los nodos trabajadores de su clúster de 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==--

Para obtener más información, consulte Personalización de nodos administrados con plantillas de lanzamiento.

GCP

Para aprovisionar almacenamiento SSD local en clústeres Google Kubernetes Engine (GKE) y configurar las cargas de trabajo para que consuman datos del almacenamiento efímero respaldado por SSD local conectado a los nodos de su clúster, ejecute el siguiente comando:

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

Para obtener más información, consulte Aprovisionamiento de almacenamiento SSD local en GKE.

Azure

Para crear un conjunto de escalado de máquinas virtuales (VMSS) con almacenamiento en disco NVMe local, debe pasar datos personalizados a las instancias de máquinas virtuales. A continuación se muestra un ejemplo de cómo adjuntar un disco NVMe a las instancias VM en el 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 y TecentCloud

Para crear un pool de nodos que utilice volúmenes SSD Locales, necesitamos pasar Datos Personalizados. El siguiente es un ejemplo de datos personalizados.

#!/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..."

Su propio IDC

Si está ejecutando su propio IDC y desea configurar sus contenedores para que utilicen el sistema de archivos de un disco NVMe recién montado por defecto en containerd, siga estos pasos:

• Monta los discos NVMe.

  Asegúrate de que tu disco NVMe está correctamente montado en tu máquina anfitriona. Puedes montarlo en un directorio de tu elección. Por ejemplo, si lo monta en /mnt/nvme, asegúrese de que está correctamente montado y de que puede ver el disco disponible en /mnt/nvme ejecutando lsblk o df -h.

• Actualiza la configuración de containerd.

  Modifica la configuración de containerd para utilizar el nuevo montaje como directorio raíz para el almacenamiento del contenedor.

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

  Localice la sección [plugins."io.containerd.grpc.v1.cri".containerd], y modifique las configuraciones snapshotter y root como sigue：.

  [plugins."io.containerd.grpc.v1.cri".containerd]
  snapshotter = "overlayfs"
  root = "/mnt/nvme/containerd"
  state = "/mnt/nvme/containerd/state"
  

• Reinicia containerd.

  Reinicie el servicio containerd para aplicar los cambios.

  sudo systemctl restart containerd
  

Verificar el rendimiento del disco

Se recomienda verificar el rendimiento del disco utilizando Fio, que es una herramienta popular para la evaluación comparativa del rendimiento del disco. A continuación se muestra un ejemplo de cómo ejecutar Fio para comprobar el rendimiento del disco.

• Despliegue el pod de prueba en el nodo con el disco NVMe.

  kubectl create -f ubuntu.yaml
  

  El archivo ubuntu.yaml es el siguiente:

  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: {}
  

• Ejecute Fio para probar el rendimiento del disco.

  # 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
  

  El resultado debería ser el siguiente

  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
  

Despliegue Milvus Distributed

Una vez que los resultados de la verificación sean satisfactorios, puede desplegar Milvus Distributed con los siguientes pasos:

Consejos para desplegar Milvus Distributed utilizando Helm

El pod QueryNode utiliza discos NVMe como volúmenes EmptyDir por defecto. Se recomienda montar discos NVMe en /var/lib/milvus/data dentro de los pods QueryNode para garantizar un rendimiento óptimo.

Para más detalles sobre cómo desplegar Milvus Distributed utilizando Helm, consulte Ejecutar Milvus en Kubernetes con Helm.

Consejos para desplegar Milvus Distributed utilizando Milvus Operator

Milvus Operator configura automáticamente el pod QueryNode para utilizar discos NVMe como volúmenes EmptyDir. Se recomienda añadir las siguientes configuraciones al recurso personalizado MilvusCluster:

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

Esto garantizará que el pod QueryNode utilice el disco NVMe como volumen de datos. Para más detalles sobre cómo desplegar Milvus Distributed utilizando Milvus Operator, consulte Ejecutar Milvus en Kubernetes con Milvus Operator.