Configurar o Milvus QueryNode com disco local

Este artigo descreve como configurar o Milvus QueryNode para usar o armazenamento em disco local.

Descrição geral

O Milvus é um banco de dados vetorial focado em IA, adaptado para armazenamento e recuperação eficientes de grandes quantidades de dados vetoriais. Ele é ideal para tarefas como análise de imagem e vídeo, processamento de linguagem natural e sistemas de recomendação. Para garantir um desempenho ideal, é crucial minimizar a latência de leitura do disco. O uso de SSDs NVMe locais é altamente recomendado para evitar atrasos e manter a estabilidade do sistema.

Os principais recursos em que o armazenamento em disco local entra em ação incluem:

• Cache de pedaços: Pré-carrega dados no cache de disco local para uma pesquisa mais rápida.
• MMap: Mapeia o conteúdo do ficheiro diretamente para a memória para uma melhor eficiência da memória.
• Índice DiskANN: Requer armazenamento em disco para uma gestão eficiente do índice.

Neste artigo, vamos nos concentrar na implantação do Milvus Distributed em plataformas de nuvem e em como configurar o QueryNode para usar o armazenamento em disco NVMe. A tabela a seguir lista os tipos de máquina recomendados de vários provedores de nuvem.

Esses tipos de máquina fornecem armazenamento em disco NVMe. Pode utilizar o comando lsblk nas instâncias destes tipos de máquina para verificar se têm armazenamento em disco NVMe. Se tiverem, você pode prosseguir para a próxima etapa.

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

Configurar o Kubernetes para usar o disco local

Para configurar o QueryNode do Milvus Distributed para usar o armazenamento em disco NVMe, é necessário configurar os nós de trabalho dos clusters Kubernetes de destino para armazenar os contêineres e as imagens em um disco NVMe. O procedimento para isso varia de acordo com os provedores de nuvem.

AWS

Ao usar o Amazon EKS, é possível personalizar nós gerenciados com modelos de lançamento, nos quais você pode especificar definições de configuração para seus grupos de nós. Segue-se um exemplo de como montar um disco NVMe nos nós de trabalho do seu 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==--

Para obter detalhes, consulte Personalizando nós gerenciados com modelos de inicialização.

GCP

Para provisionar o armazenamento SSD Local em clusters do Google Kubernetes Engine (GKE) e configurar cargas de trabalho para consumir dados do armazenamento efémero suportado por SSD Local anexado a nós no seu cluster, execute o seguinte comando:

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

Para obter detalhes, consulte Provisionamento de armazenamento SSD local no GKE.

Azure

Para criar um conjunto de dimensionamento de máquina virtual (VMSS) com armazenamento de disco NVMe local, você precisa passar dados personalizados para as instâncias de VM. A seguir, um exemplo de como anexar um disco NVMe às instâncias de VM no 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 e TecentCloud

Para criar um pool de nós que utiliza volumes SSD locais, precisamos de passar dados personalizados. A seguir, um exemplo de dados 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..."

Seu próprio IDC

Se estiver a executar o seu próprio IDC e pretender configurar os seus contentores para utilizarem o sistema de ficheiros num disco NVMe recém-montado por predefinição no containerd, siga estes passos:

• Monte os discos NVMe.

  Certifique-se de que o seu disco NVMe está devidamente montado na sua máquina anfitriã. Pode montá-lo num diretório à sua escolha. Por exemplo, se o montar em /mnt/nvme, certifique-se de que está corretamente configurado e que pode ver o disco disponível em /mnt/nvme executando lsblk ou df -h.

• Atualizar a configuração do containerd.

  Modifique a configuração do containerd para usar a nova montagem como o diretório raiz para o armazenamento do contêiner.

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

  Localize a secção [plugins."io.containerd.grpc.v1.cri".containerd] e modifique as definições snapshotter e root da seguinte forma:：

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

• Reinicie o containerd.

  Reinicie o serviço containerd para aplicar as alterações.

  sudo systemctl restart containerd
  

Verificar o desempenho do disco

Aconselha-se a verificar o desempenho do disco utilizando o Fio, que é uma ferramenta popular para avaliar o desempenho do disco. A seguir, um exemplo de como executar o Fio para testar o desempenho do disco.

• Implemente o pod de teste no nó com o disco NVMe.

  kubectl create -f ubuntu.yaml
  

  O ficheiro ubuntu.yaml é o seguinte:

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

• Execute o Fio para testar o desempenho do 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
  

  E a saída deve ser semelhante a esta:

  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
  

Implementar o Milvus Distributed

Quando os resultados da verificação forem satisfatórios, é possível implantar o Milvus Distributed com as etapas a seguir:

Dicas para implantar o Milvus Distributed usando o Helm

O pod QueryNode usa discos NVMe como volumes EmptyDir por padrão. É aconselhável montar os discos NVMe em /var/lib/milvus/data dentro dos pods QueryNode para garantir o desempenho ideal.

Para obter detalhes sobre como implantar o Milvus Distributed usando o Helm, consulte Executar o Milvus no Kubernetes com o Helm.

Dicas para implantar o Milvus Distributed usando o Milvus Operator

O Milvus Operator configura automaticamente o pod QueryNode para usar discos NVMe como volumes EmptyDir. Aconselha-se a adicionar as seguintes configurações ao recurso personalizado MilvusCluster:

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

Isso garantirá que o pod QueryNode use o disco NVMe como o volume de dados. Para obter detalhes sobre como implantar o Milvus Distributed usando o Milvus Operator, consulte Executar o Milvus no Kubernetes com o Milvus Operator.