milvus-logo
LFAI
Home
  • Guide d'administration

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.

Fournisseur de cloudType de machine
AWSSérie R6id
GCPSérie N2
AzureSérie Lsv3
Alibaba CloudSérie i3
Tencent CloudSérie IT5

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==--

Dans l'exemple ci-dessus, nous supposons que le disque NVMe est /dev/nvme1n1. Vous devez modifier le script pour qu'il corresponde à votre configuration spécifique.

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

Dans l'exemple ci-dessus, nous supposons que les disques NVMe sont /dev/nvme0n1 et /dev/nvme1n1. Vous devez modifier le script pour qu'il corresponde à votre configuration spécifique.

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

Dans l'exemple ci-dessus, nous supposons que le disque NVMe est /dev/nvme0n1. Vous devez modifier le script pour qu'il corresponde à votre configuration spécifique.

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.

Traduit parDeepLogo

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started
Feedback

Cette page a-t - elle été utile ?