Milvus QueryNode mit lokaler Festplatte konfigurieren

Dieser Artikel beschreibt, wie Sie Milvus QueryNode für die Verwendung von lokalem Plattenspeicher konfigurieren.

Überblick

Milvus ist eine auf künstliche Intelligenz ausgerichtete Vektordatenbank, die auf die effiziente Speicherung und Abfrage großer Mengen von Vektordaten zugeschnitten ist. Sie ist ideal für Aufgaben wie Bild- und Videoanalyse, natürliche Sprachverarbeitung und Empfehlungssysteme. Um eine optimale Leistung zu gewährleisten, ist es von entscheidender Bedeutung, die Festplattenleselatenz zu minimieren. Die Verwendung lokaler NVMe-SSDs wird dringend empfohlen, um Verzögerungen zu vermeiden und die Systemstabilität zu erhalten.

Zu den wichtigsten Funktionen, bei denen lokale Festplattenspeicher ins Spiel kommen, gehören:

• Chunk-Cache: Vorladen von Daten in den lokalen Festplatten-Cache für eine schnellere Suche.
• MMap: Ordnet den Dateiinhalt direkt im Speicher zu, um die Speichereffizienz zu verbessern.
• DiskANN-Index: Erfordert Festplattenspeicher für eine effiziente Indexverwaltung.

In diesem Artikel konzentrieren wir uns auf den Einsatz von Milvus Distributed auf Cloud-Plattformen und auf die Konfiguration des QueryNode zur Verwendung von NVMe-Plattenspeicher. In der folgenden Tabelle sind die empfohlenen Maschinentypen der verschiedenen Cloud-Anbieter aufgeführt.

Diese Maschinentypen bieten NVMe-Festplattenspeicher. Sie können den Befehl lsblk auf den Instanzen dieser Maschinentypen verwenden, um zu prüfen, ob sie über NVMe-Plattenspeicher verfügen. Wenn dies der Fall ist, können Sie mit dem nächsten Schritt fortfahren.

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

Konfigurieren von Kubernetes für die Verwendung einer lokalen Festplatte

Um den QueryNode von Milvus Distributed so zu konfigurieren, dass er NVMe-Plattenspeicher verwendet, müssen Sie die Worker Nodes der Kubernetes-Zielcluster so konfigurieren, dass sie die Container und Images auf einer NVMe-Platte speichern. Das Verfahren hierfür variiert je nach Cloud-Anbieter.

AWS

Bei der Verwendung von Amazon EKS können Sie verwaltete Knoten mit Startvorlagen anpassen, in denen Sie Konfigurationseinstellungen für Ihre Knotengruppen angeben können. Im Folgenden finden Sie ein Beispiel dafür, wie Sie eine NVMe-Festplatte auf den Arbeitsknoten Ihres Amazon EKS-Clusters einbinden:

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

Details finden Sie unter Anpassen von verwalteten Knoten mit Startvorlagen.

GCP

Führen Sie den folgenden Befehl aus, um lokalen SSD-Speicher auf Google Kubernetes Engine (GKE)-Clustern bereitzustellen und Arbeitslasten so zu konfigurieren, dass sie Daten von lokalem SSD-gestütztem ephemerem Speicher verwenden, der an Knoten in Ihrem Cluster angeschlossen ist:

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

Einzelheiten finden Sie unter Bereitstellung von lokalem SSD-Speicher auf GKE.

Azure

Um ein Virtual Machine Scale Set (VMSS) mit lokalem NVMe-Plattenspeicher zu erstellen, müssen Sie benutzerdefinierte Daten an die VM-Instanzen übergeben. Im Folgenden finden Sie ein Beispiel dafür, wie Sie eine NVMe-Festplatte an die VM-Instanzen in der VMSS anhängen:

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 und TecentCloud

Um einen Knotenpool zu erstellen, der lokale SSD-Volumes verwendet, müssen wir benutzerdefinierte Daten übergeben. Im Folgenden finden Sie ein Beispiel für benutzerdefinierte Daten.

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

Ihr eigener IDC

Wenn Sie Ihre eigene IDC betreiben und Ihre Container so konfigurieren möchten, dass sie standardmäßig das Dateisystem auf einer neu eingehängten NVMe-Platte in containerd verwenden, führen Sie folgende Schritte aus:

• Hängen Sie die NVMe-Platten ein.

  Vergewissern Sie sich, dass Ihre NVMe-Platte ordnungsgemäß auf Ihrem Host-Rechner eingehängt ist. Sie können sie in ein Verzeichnis Ihrer Wahl einhängen. Wenn Sie sie z. B. in /mnt/nvme einbinden, stellen Sie sicher, dass sie korrekt eingerichtet ist und Sie die Platte unter /mnt/nvme sehen können, indem Sie lsblk oder df -h ausführen.

• Aktualisieren Sie die containerd-Konfiguration.

  Ändern Sie die containerd-Konfiguration, um das neue Mount als Root-Verzeichnis für den Container-Speicher zu verwenden.

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

  Suchen Sie den Abschnitt [plugins."io.containerd.grpc.v1.cri".containerd], und ändern Sie die Einstellungen snapshotter und root wie folgt：

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

• Starten Sie containerd neu.

  Starten Sie den containerd-Dienst neu, um die Änderungen zu übernehmen.

  sudo systemctl restart containerd
  

Überprüfen der Festplattenleistung

Es wird empfohlen, die Festplattenleistung mit Fio zu überprüfen. Fio ist ein beliebtes Tool zum Benchmarking der Festplattenleistung. Im Folgenden finden Sie ein Beispiel dafür, wie Sie Fio zum Testen der Festplattenleistung ausführen.

• Setzen Sie den Test-Pod auf dem Knoten mit der NVMe-Festplatte ein.

  kubectl create -f ubuntu.yaml
  

  Die Datei ubuntu.yaml lautet wie folgt:

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

• Führen Sie Fio aus, um die Festplattenleistung zu testen.

  # 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
  

  Und die Ausgabe sollte wie folgt aussehen:

  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 bereitstellen

Sobald die Überprüfungsergebnisse zufriedenstellend sind, können Sie Milvus Distributed mit den folgenden Schritten bereitstellen:

Tipps für den Einsatz von Milvus Distributed mit Helm

Der QueryNode-Pod verwendet standardmäßig NVMe-Festplatten als EmptyDir-Volumes. Es wird empfohlen, NVMe-Festplatten unter /var/lib/milvus/data innerhalb des QueryNode-Pods zu mounten, um eine optimale Leistung zu gewährleisten.

Einzelheiten zur Bereitstellung von Milvus Distributed mit Helm finden Sie unter Ausführen von Milvus in Kubernetes mit Helm.

Tipps für die Bereitstellung von Milvus Distributed mit Milvus Operator

Der Milvus Operator konfiguriert den QueryNode-Pod automatisch für die Verwendung von NVMe-Festplatten als EmptyDir-Volumes. Wir empfehlen Ihnen, die folgenden Konfigurationen zur benutzerdefinierten Ressource MilvusCluster hinzuzufügen:

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

Dadurch wird sichergestellt, dass der QueryNode-Pod die NVMe-Festplatte als Datenvolumen verwendet. Einzelheiten zur Bereitstellung von Milvus Distributed mit Milvus Operator finden Sie unter Ausführen von Milvus in Kubernetes mit Milvus Operator.