Configuration de Milvus QueryNode avec un disque local

Cet article décrit comment configurer Milvus QueryNode pour utiliser le stockage sur disque local.

Vue d'ensemble

Milvus est une base de données vectorielle axée sur l'IA et conçue pour le stockage et la récupération efficaces de grandes quantités de données vectorielles. Elle est idéale pour des tâches telles que l'analyse d'images et de vidéos, le traitement du langage naturel et les systèmes de recommandation. Pour garantir des performances optimales, il est essentiel de minimiser la latence de lecture du disque. L'utilisation de disques SSD NVMe locaux est fortement recommandée pour éviter les retards et maintenir la stabilité du système.

Les principales caractéristiques où le stockage sur disque local entre en jeu sont les suivantes :

• Cache de morceaux: Précharge les données dans le cache du disque local pour une recherche plus rapide.
• MMap: Mappage du contenu des fichiers directement dans la mémoire pour une meilleure efficacité de la mémoire.
• Index DiskANN: Nécessite un stockage sur disque pour une gestion efficace de l'index.

Dans cet article, nous nous concentrerons sur le déploiement de Milvus Distributed sur des plates-formes en nuage et sur la manière de configurer le QueryNode pour utiliser le stockage sur disque NVMe. Le tableau suivant répertorie les types de machines recommandés par les différents fournisseurs de cloud.

Ces types de machines offrent un stockage sur disque NVMe. Vous pouvez utiliser la commande lsblk sur les instances de ces types de machines pour vérifier si elles disposent d'un stockage sur disque NVMe. Si c'est le cas, vous pouvez passer à l'étape suivante.

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

Configurer Kubernetes pour utiliser le disque local

Pour configurer le QueryNode de Milvus Distributed afin d'utiliser le stockage sur disque NVMe, vous devez configurer les nœuds de travail des clusters Kubernetes cibles afin de stocker les conteneurs et les images sur un disque NVMe. La procédure à suivre varie en fonction des fournisseurs de cloud.

AWS

Lorsque vous utilisez Amazon EKS, vous pouvez personnaliser les nœuds gérés avec des modèles de lancement, dans lesquels vous pouvez spécifier des paramètres de configuration pour vos groupes de nœuds. Voici un exemple de montage d'un disque NVMe sur les nœuds de travail de votre cluster 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==--

Pour plus d'informations, voir Personnaliser les nœuds gérés avec des modèles de lancement.

GCP

Pour provisionner le stockage SSD local sur les clusters Google Kubernetes Engine (GKE) et configurer les charges de travail pour qu'elles consomment des données à partir du stockage éphémère soutenu par SSD local attaché aux nœuds de votre cluster, exécutez la commande suivante :

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

Pour plus de détails, voir Provisionnement du stockage SSD local sur GKE.

Azure

Pour créer un ensemble de machines virtuelles (VMSS) avec un stockage sur disque NVMe local, vous devez transmettre des données personnalisées aux instances de machines virtuelles. L'exemple suivant montre comment attacher un disque NVMe aux instances VM dans le 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

Pour créer un pool de nœuds qui utilise des volumes SSD locaux, nous devons passer des données personnalisées. Voici un exemple de données personnalisées.

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

Votre propre IDC

Si vous exécutez votre propre IDC et souhaitez configurer vos conteneurs pour qu'ils utilisent par défaut dans containerd le système de fichiers d'un disque NVMe nouvellement monté, procédez comme suit :

• Montez les disques NVMe.

  Assurez-vous que votre disque NVMe est correctement monté sur votre machine hôte. Vous pouvez le monter dans un répertoire de votre choix. Par exemple, si vous le montez sur /mnt/nvme, assurez-vous qu'il est correctement configuré et que vous pouvez voir le disque disponible sur /mnt/nvme en exécutant lsblk ou df -h.

• Mettre à jour la configuration de containerd.

  Modifiez la configuration de containerd pour utiliser le nouveau montage comme répertoire racine pour le stockage des conteneurs.

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

  Localisez la section [plugins."io.containerd.grpc.v1.cri".containerd], et modifiez les paramètres snapshotter et root comme suit：

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

• Redémarrez containerd.

  Redémarrez le service containerd pour appliquer les modifications.

  sudo systemctl restart containerd
  

Vérifier les performances du disque

Il est conseillé de vérifier les performances du disque à l'aide de Fio, un outil populaire d'évaluation des performances des disques. Voici un exemple d'exécution de Fio pour tester les performances du disque.

• Déployez le pod de test sur le nœud avec le disque NVMe.

  kubectl create -f ubuntu.yaml
  

  Le fichier ubuntu.yaml est le suivant :

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

• Exécutez Fio pour tester les performances du disque.

  # 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
  

  La sortie devrait ressembler à ceci :

  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
  

Déployer Milvus Distribué

Une fois que les résultats de la vérification sont satisfaisants, vous pouvez déployer Milvus Distributed en suivant les étapes suivantes :

Conseils pour le déploiement de Milvus Distributed à l'aide de Helm

Le pod QueryNode utilise par défaut des disques NVMe en tant que volumes EmptyDir. Il est conseillé de monter les disques NVMe sur /var/lib/milvus/data dans les pods QueryNode pour garantir des performances optimales.

Pour plus de détails sur le déploiement de Milvus Distributed à l'aide de Helm, voir Exécuter Milvus dans Kubernetes avec Helm.

Conseils pour le déploiement de Milvus Distributed à l'aide de Milvus Operator

Milvus Operator configure automatiquement le pod QueryNode pour utiliser des disques NVMe en tant que volumes EmptyDir. Il est conseillé d'ajouter les configurations suivantes à la ressource personnalisée MilvusCluster:

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

Cela garantira que le pod QueryNode utilise le disque NVMe comme volume de données. Pour plus de détails sur le déploiement de Milvus Distributed à l'aide de Milvus Operator, voir Exécuter Milvus dans Kubernetes avec Milvus Operator.