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.
Proveedor de nube | Tipo de máquina |
---|---|
AWS | Serie R6id |
GCP | Serie N2 |
Azure | Serie Lsv3 |
Nube Alibaba | Serie i3 |
Nube de Tencent | Serie IT5 |
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==--
En el ejemplo anterior, suponemos que el disco NVMe es /dev/nvme1n1
. Debe modificar el script para adaptarlo a su configuración específica.
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
En el ejemplo anterior, suponemos que los discos NVMe son /dev/nvme0n1
y /dev/nvme1n1
. Debe modificar el script para que se adapte a su configuración específica.
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..."
En el ejemplo anterior, asumimos que el disco NVMe es /dev/nvme0n1
. Debe modificar la secuencia de comandos para adaptarla a su configuración específica.
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
ejecutandolsblk
odf -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 configuracionessnapshotter
yroot
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.