Configurando o Milvus no Amazon EKS
Milvus foi projetado desde o início para oferecer suporte ao Kubernetes e pode ser facilmente implantado na AWS. Para criar um cluster de banco de dados vetorial Milvus confiável e elástico, podemos usar o Amazon Elastic Kubernetes Service (Amazon EKS) como o Kubernetes gerenciado, o Amazon S3 como o Object Storage, o Amazon Managed Streaming for Apache Kafka (Amazon MSK) como o Message Storage e o Amazon Elastic Load Balancing (Amazon ELB) como o Load Balancer.
Visão geral da arquitetura do Milvus
Arquitetura do Milvus
O EKS é o serviço Kubernetes gerenciado da Amazon que é executado no EC2 ou sem servidor no Fargate. É ideal para organizações que já usam Kubernetes on-premises, permitindo que migrem suas implantações para a AWS com alterações mínimas.
Este blog usa EC2 para a implantação porque o Fargate não consegue lidar com persistent volume claims (PVCs) necessárias para dependências do Milvus, como o etcd.
Forneceremos orientações passo a passo sobre como implantar um cluster Milvus usando o EKS e outros serviços. Uma versão mais detalhada deste blog está disponível aqui.
Pré-requisitos
AWS CLI
Instale a AWS CLI no seu PC/Mac local ou instância Amazon EC2, que servirá como seu endpoint para as operações abordadas neste documento. Se você usa Amazon Linux 2 ou Amazon Linux 2023, as ferramentas da AWS CLI são instaladas por padrão. Consulte Como instalar a AWS CLI.
Abaixo está uma captura de tela verificando que a AWS CLI está instalada.
% which aws
/usr/local/bin/aws
% aws --version
aws-cli/2.15.34 Python/3.11.8 Darwin/23.5.0 exe/x86_64 prompt/off
Ferramentas do EKS: Kubectl, eksctl, helm
Instale as ferramentas do EKS no dispositivo endpoint preferido, incluindo:
Consulte EKS getting started para etapas detalhadas de instalação. Abaixo está uma captura de tela verificando as instalações e versões em um laptop Mac M2 usando z shell:
% kubectl version
Client Version: v1.30.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
# Download eksctl
ARCH=arm64
PLATFORM=$(uname -s)_$ARCH
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo mv /tmp/eksctl /usr/local/bin
% eksctl version
0.185.0
% helm list --all-namespaces
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
my-milvus default 1 2024-07-09 16:00:14.117945 -0700 PDT deployed milvus-4.1.34 2.4.5
Criar um bucket do Amazon S3
Leia as Regras de nomenclatura de buckets e observe-as ao nomear seu bucket do AWS S3 usando o console da AWS.
Criar um bucket do Amazon S3
Criar uma chave gerenciada pelo cliente do KMS.
A chave do KMS não pode ser uma chave gerenciada pela AWS. Ela deve ser uma chave gerenciada pelo cliente. Depois de criá-la, você precisará aguardar cerca de 10 minutos para que a chave fique ativa antes de poder usá-la no AWS Secrets Manager. Usando o console da AWS, acesse KMS > Customer managed keys.
Criar uma chave gerenciada pelo cliente do KMS. .png
Criar um segredo personalizado no AWS Secrets Manager.
Certifique-se de ter aguardado cerca de 10 minutos após criar sua chave gerenciada pelo cliente do KMS. Agora, crie um novo segredo do AWS Secrets Manager. Usando o console da AWS.
Escolha outro tipo de segredo para o tipo de segredo.
Alterne o editor de pares chave/valor para Texto simples. Insira JSON com chaves correspondendo exatamente a “username” e “password”.
O nome do segredo deve começar com AmazonMSK_.
A chave de criptografia deve ser uma chave gerenciada pelo cliente do KMS, não uma chave gerenciada pela AWS.
Criar um segredo personalizado no AWS Secrets Manager. .png
Criar uma instância do MSK
Em seguida, use o console da AWS para criar um cluster Amazon MSK com o recurso autoCreateTopics do Kafka e a segurança SASL/SCRAM habilitados.
Considerações ao criar o MSK:
A versão estável mais recente do Milvus (v2.4.x) depende do recurso autoCreateTopics do Kafka, portanto, ao criar o MSK, uma configuração personalizada precisa ser usada, assim como a propriedade auto.create.topics.enable precisa ser alterada do padrão false para true.
Além disso, para aumentar a taxa de transferência de mensagens do MSK, recomenda-se aumentar os valores de message.max.bytes e replica.fetch.max.bytes.
auto.create.topics.enable=true
message.max.bytes=10485880
replica.fetch.max.bytes=20971760
Consulte as configurações personalizadas do MSK para obter detalhes.
Criar uma instância do MSK.png
O Milvus não oferece suporte à autenticação baseada em função IAM para o MSK, portanto, ao criar o MSK, habilite a opção de autenticação SASL/SCRAM na configuração de segurança e configure o nome de usuário e a senha no AWS Secrets Manager. Consulte Autenticação de credenciais de login com o AWS Secrets Manager para obter detalhes.
O grupo de segurança do MSK precisa permitir acesso a partir do grupo de segurança ou do intervalo de endereços IP do cluster EKS.
configurações de segurança
Aguarde ~15 minutos para que a instância do MSK seja provisionada. Quando estiver pronta, clique nela e você poderá associar o segredo personalizado do AWS Secrets Manager que criou anteriormente.
AWS Secrets Manager
Criar um cluster Amazon EKS
Há muitas maneiras de criar um cluster EKS, como pelo console, CloudFormation ou eksctl. Consulte o documento Configurar para usar o Amazon EKS.
Esta publicação usará eksctl. eksctl é uma ferramenta simples de linha de comando para criar e gerenciar clusters Kubernetes no Amazon EKS. eksctl fornece a maneira mais rápida e fácil de criar um novo cluster com nós para o Amazon EKS. Para obter mais informações, consulte a documentação oficial do eksctl.
Etapa 1: Crie um arquivo eks_cluster.yaml.
Consulte a documentação do Milvus para ver um exemplo de arquivo .yaml.
Substitua o nome do cluster pelo nome do seu cluster,
Substitua region-code pela região da AWS onde você deseja criar o cluster.
Substitua private-subnet-idx pelas suas sub-redes privadas. Observação: Este arquivo de configuração cria um cluster EKS em uma VPC existente especificando sub-redes privadas. Você também pode remover a configuração de VPC e sub-redes para que o eksctl crie automaticamente uma nova VPC.
**Etapa 2: Execute o comando eksctl create cluster -f eks_cluster.yaml para criar o cluster EKS. **
create cluster -f eks_cluster.yaml
Consulte o Guia de início rápido do Amazon EKS. Este comando criará os seguintes recursos:
Um cluster EKS com a versão especificada.
Um grupo de nós gerenciado com 3 instâncias EC2 m6i.2xlarge.
Um provedor de identidade IAM OIDC e uma ServiceAccount chamada aws-load-balancer-controller serão usados posteriormente ao instalar o AWS Load Balancer Controller.
Um namespace milvus e uma ServiceAccount milvus-s3-access-sa dentro deste namespace. Isso será usado posteriormente ao configurar o S3 como o armazenamento de objetos para o Milvus.
Nota: Para simplificar, a milvus-s3-access-sa recebe permissões de acesso total ao S3. Em implantações de produção, recomenda-se seguir o princípio do menor privilégio e conceder acesso apenas ao bucket S3 específico usado para o Milvus.
- Vários add-ons, onde vpc-cni, coredns, kube-proxy são add-ons principais exigidos pelo EKS. aws-ebs-csi-driver é o driver AWS EBS CSI que permite que clusters EKS gerenciem o ciclo de vida dos volumes Amazon EBS.
% eksctl create cluster -f eks_cluster.yaml
2024-07-10 17:45:32 [ℹ] eksctl version 0.185.0
2024-07-10 17:45:32 [ℹ] using region us-west-2
2024-07-10 17:45:32 [✔] using existing VPC (vpc-84c5b3fc) and
…
2024-07-10 17:45:32 [ℹ] building cluster stack "eksctl-MilvusEKSTest-cluster"
2024-07-10 17:45:33 [ℹ] deploying stack
…
Aguarde a conclusão da criação do cluster. Após a conclusão, você deverá ver uma resposta como a seguinte saída:
% EKS cluster "MilvusEKSTest" in "us-west-2" region is ready
Depois que o cluster for criado, você poderá visualizar os nós executando:
% kubectl get nodes -A -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-172-31-22-240.us-west-2.compute.internal Ready <none> 11m v1.28.8-eks-ae9a62a 172.31.22.240 52.40.226.172 Amazon Linux 2 5.10.219-208.866.amzn2.x86_64 containerd://1.7.11
ip-172-31-31-71.us-west-2.compute.internal Ready <none> 11m v1.28.8-eks-ae9a62a 172.31.31.71 35.165.133.62 Amazon Linux 2 5.10.219-208.866.amzn2.x86_64 containerd://1.7.11
ip-172-31-33-44.us-west-2.compute.internal Ready <none> 11m v1.28.8-eks-ae9a62a 172.31.33.44 35.91.5.162 Amazon Linux 2 5.10.219-208.866.amzn2.x86_64 containerd://1.7.11
Etapa 3: Crie uma ebs-sc StorageClass configurada com GP3 como o tipo de armazenamento e defina-a como a StorageClass padrão.
O Milvus usa etcd como Meta Storage e precisa desta StorageClass para criar e gerenciar PVCs.
- Execute este comando cat.
% cat <<EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
EOF
storageclass.storage.k8s.io/ebs-sc created
- Execute um comando patch após a criação para tornar esta StorageClass a padrão.
% kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
storageclass.storage.k8s.io/gp2 patched
- Verifique se a classe de armazenamento foi configurada corretamente.
% kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
ebs-sc ebs.csi.aws.com Delete WaitForFirstConsumer false 6m39s
gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 44m
Etapa 4: Instale o AWS Load Balancer Controller
Isso será usado posteriormente para o Milvus Service e o Attu Ingress. Consulte as instruções oficiais do EKS Load Balancer Controller.
Adicione o repositório eks-charts e atualize-o.
% helm repo add eks https://aws.github.io/eks-charts
"eks" has been added to your repositories
% helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "eks" chart repository
...Successfully got an update from the "zilliztech" chart repository
...Successfully got an update from the "milvus" chart repository
Update Complete. ⎈Happy Helming!⎈
Instale o AWS Load Balancer Controller. Substitua cluster-name pelo nome do seu cluster. O ServiceAccount chamado aws-load-balancer-controller já foi criado quando o cluster EKS foi criado.
% helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=MilvusEKSTest \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller
NAME: aws-load-balancer-controller
LAST DEPLOYED: Wed Jul 10 19:00:34 2024
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
AWS Load Balancer controller installed!
Verifique se o controller foi instalado com sucesso. A saída deve ser semelhante a:
% kubectl get deployment -n kube-system aws-load-balancer-controller
NAME READY UP-TO-DATE AVAILABLE AGE
aws-load-balancer-controller 2/2 2 2 88s
Implante um Cluster Milvus no Amazon EKS
O Milvus oferece suporte a vários métodos de implantação, como Operator e Helm. Usar o Operator é mais simples, mas o Helm é mais direto e flexível. Portanto, usamos o Helm para a implantação.
Você pode personalizar a configuração por meio dos valores ao implantar o Milvus com o arquivo milvus_helm.yaml.
Por padrão, o Milvus cria minio e pulsar dentro do cluster como Object Storage e Message Storage, respectivamente. Faremos algumas alterações de configuração para torná-lo mais adequado para produção.
Etapa 1: Adicione o repositório Helm do Milvus e atualize-o.
% helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update
"milvus" already exists with the same configuration, skipping
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "eks" chart repository
...Successfully got an update from the "zilliztech" chart repository
...Successfully got an update from the "milvus" chart repository
Update Complete. ⎈Happy Helming!⎈
Etapa 2: Crie um arquivo milvus_cluster.yaml.
O código a seguir personaliza a instalação do Milvus, como configurar o Amazon S3 como object storage, o Amazon MSK como fila de mensagens etc. Forneceremos explicações detalhadas e orientações de configuração após o bloco de código.
#####################################
# Section 1
#
# Configure S3 as the Object Storage
#####################################
# Service account
# - this service account are used by External S3 access
serviceAccount:
create: false
name: milvus-s3-access-sa
# Close in-cluster minio
minio:
enabled: false
# External S3
# - these configs are only used when `externalS3.enabled` is true
externalS3:
enabled: true
host: "s3.<region-code>.amazonaws.com"
port: "443"
useSSL: true
bucketName: "<bucket-name>"
rootPath: "<root-path>"
useIAM: true
cloudProvider: "aws"
iamEndpoint: ""
#####################################
# Section 2
#
# Configure MSK as the Message Storage
#####################################
# Close in-cluster pulsar
pulsar:
enabled: false
# Kafka externo
# - estas configurações são usadas apenas quando `externalKafka.enabled` é true
externalKafka:
enabled: true
brokerList: "<broker-list>"
securityProtocol: SASL_SSL
sasl:
mechanisms: SCRAM-SHA-512
username: "<username>"
password: "<password>"
#####################################
# Seção 3
#
# Exponha o serviço Milvus para ser acessado de fora do cluster (serviço LoadBalancer).
# ou acesse-o de dentro do cluster (serviço ClusterIP). Defina o tipo de serviço e a porta para servi-lo.
#####################################
service:
type: LoadBalancer
port: 19530
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: external #O AWS Load Balancer Controller atende serviços que têm esta anotação
service.beta.kubernetes.io/aws-load-balancer-name : milvus-service #Nome definido pelo usuário dado ao AWS Network Load Balancer
#service.beta.kubernetes.io/aws-load-balancer-scheme: internal # interno ou internet-facing, permitindo posteriormente acesso público via internet
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing" #Coloca o load balancer em sub-redes públicas
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip #Os IPs dos Pods devem ser usados como os IPs de destino (em vez dos IPs dos nós)
#####################################
# Seção 4
#
# Instalando o Attu, a GUI de gerenciamento do Milvus
#####################################
attu:
enabled: true
name: attu
service:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: external
service.beta.kubernetes.io/aws-load-balancer-name : milvus-attu-service
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
labels: {}
type: LoadBalancer
port: 3000
ingress:
enabled: false
#####################################
# Seção 5
#
# Implantação HA dos componentes principais do Milvus
#####################################
rootCoordinator:
replicas: 2
activeStandby:
enabled: true # Habilite active-standby quando definir múltiplas réplicas para o coordenador raiz
resources:
limits:
cpu: 1
memory: 2Gi
indexCoordinator:
replicas: 2
activeStandby:
enabled: true # Habilite active-standby quando definir múltiplas réplicas para o coordenador de índice
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
queryCoordinator:
replicas: 2
activeStandby:
enabled: true # Habilite active-standby quando definir múltiplas réplicas para o coordenador de consulta
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
dataCoordinator:
replicas: 2
activeStandby:
enabled: true # Habilite active-standby quando definir múltiplas réplicas para o coordenador de dados
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
proxy:
replicas: 2
resources:
limits:
cpu: 1
memory: 4Gi
#####################################
# Seção 6
#
# Alocação de recursos do Milvus
#####################################
queryNode:
replicas: 1
resources:
limits:
cpu: 2
memory: 8Gi
dataNode:
replicas: 1
resources:
limits:
cpu: 1
memory: 4Gi
indexNode:
replicas: 1
resources:
limits:
cpu: 4
memory: 8Gi
O código é dividido em seis seções. Siga as instruções a seguir para alterar as configurações correspondentes.
Seção 1: Configure o S3 como o Object Storage. serviceAccount concede ao Milvus acesso ao S3 (aqui é milvus-s3-access-sa, que já foi criado ao criar o cluster EKS).
Substitua <region-code> pela região da AWS onde você criou o cluster.
Substitua <bucket-name> pelo nome do bucket S3 e <root-path> pelo prefixo do bucket S3 (pode estar vazio).
Seção 2: Configure o MSK como o Message Storage.
- Substitua <broker-list> pelo endpoint do MSK para o tipo de autenticação SASL/SCRAM,
e pelo nome de usuário e senha do MSK. Você pode obter <broker-list> nas informações do cliente MSK, conforme mostrado na imagem.
- Substitua <broker-list> pelo endpoint do MSK para o tipo de autenticação SASL/SCRAM,
view client information.jpg
Seção 3: Esta seção expõe o endpoint do serviço Milvus para ser acessado de fora do cluster. Por padrão, o endpoint do Milvus usa o serviço do tipo ClusterIP, que só é acessível dentro do cluster EKS. Você pode alterá-lo para o tipo LoadBalancer, se necessário, para permitir acesso de fora do cluster EKS. O Service do tipo LoadBalancer usa o Amazon NLB como balanceador de carga.
De acordo com as melhores práticas de segurança, aws-load-balancer-scheme é configurado como modo internal por padrão aqui, o que significa que somente o acesso pela intranet ao Milvus é permitido. Se você realmente precisar de acesso pela Internet ao Milvus, precisará alterar internal para internet-facing. Clique para ver as instruções de configuração do NLB.
- Altere a linha para:
aws-load-balancer-scheme: internet-facing
- Altere a linha para:
# service.beta.kubernetes.io/aws-load-balancer-scheme: internal
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
Seção 4: Instale e configure Attu, que é uma ferramenta de administração Milvus de código aberto. Ela possui uma GUI intuitiva que permite interagir facilmente com o banco de dados. Habilitamos o Attu, configuramos o ingress usando AWS ALB e o definimos como tipo internet-facing para que o Attu possa ser acessado pela Internet.
- Clique aqui para o guia de configuração do ALB.
Seção 5: Habilite a implantação HA dos componentes principais do Milvus. De acordo com a arquitetura, já sabemos que o Milvus contém vários componentes independentes e desacoplados. Por exemplo, o serviço coordenador atua como a camada de controle, lidando com a coordenação dos componentes Root, Query, Data e Index. O Proxy na camada de acesso atua como endpoint de acesso ao banco de dados. Esses componentes têm por padrão apenas 1 réplica de pod. Para melhorar a disponibilidade do Milvus, implantar várias réplicas desses componentes de serviço é especialmente necessário.
- Observe que os componentes coordenadores Root, Query, Data e Index devem ser implantados em várias réplicas com a opção activeStandby habilitada.
Seção 6: Ajuste a alocação de recursos dos componentes do Milvus para atender aos requisitos das suas cargas de trabalho. O site do Milvus também fornece uma ferramenta de dimensionamento para gerar sugestões de configuração com base no volume de dados, dimensões de vetores, tipos de índice etc. Ela também pode gerar um arquivo de configuração Helm com um clique.
- A configuração a seguir é a sugestão fornecida pela ferramenta para 1 milhão de vetores de 1024 dimensões e tipo de índice HNSW.
Use o Helm para criar o Milvus (implantado no namespace milvus).
- Observe que você pode substituir demo-milvus por um nome personalizado.
% helm install demo-milvus milvus/milvus -n milvus -f milvus_cluster.yaml
W0710 19:35:08.789610 64030 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
NAME: demo-milvus
LAST DEPLOYED: Wed Jul 10 19:35:06 2024
NAMESPACE: milvus
STATUS: deployed
REVISION: 1
TEST SUITE: None
Execute o seguinte comando para verificar o status da implantação.
% kubectl get deployment -n milvus
NAME READY UP-TO-DATE AVAILABLE AGE
demo-milvus-attu 1/1 1 1 5m27s
demo-milvus-datacoord 2/2 2 2 5m27s
demo-milvus-datanode 1/1 1 1 5m27s
demo-milvus-indexcoord 2/2 2 2 5m27s
demo-milvus-indexnode 1/1 1 1 5m27s
demo-milvus-proxy 2/2 2 2 5m27s
demo-milvus-querycoord 2/2 2 2 5m27s
demo-milvus-querynode 1/1 1 1 5m27s
demo-milvus-rootcoord 2/2 2 2 5m27s
A saída acima mostra que todos os componentes do Milvus estão AVAILABLE, e os componentes de coordenação têm várias réplicas habilitadas.
Acessar e Gerenciar Endpoints do Milvus
Até agora, implantamos com sucesso o banco de dados Milvus. Agora podemos acessar o Milvus por meio de endpoints. O Milvus expõe endpoints via serviços Kubernetes. O Attu expõe endpoints via Kubernetes Ingress.
Acessar Endpoints do Milvus usando Serviços Kubernetes
Execute o seguinte comando para obter os endpoints de serviço:
% kubectl get svc -n milvus
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
demo-etcd ClusterIP 172.20.103.138 <none> 2379/TCP,2380/TCP 62m
demo-etcd-headless ClusterIP None <none> 2379/TCP,2380/TCP 62m
demo-milvus LoadBalancer 172.20.219.33 milvus-nlb-xxxx.elb.us-west-2.amazonaws.com 19530:31201/TCP,9091:31088/TCP 62m
demo-milvus-datacoord ClusterIP 172.20.214.106 <none> 13333/TCP,9091/TCP 62m
demo-milvus-datanode ClusterIP None <none> 9091/TCP 62m
demo-milvus-indexcoord ClusterIP 172.20.106.51 <none> 31000/TCP,9091/TCP 62m
demo-milvus-indexnode ClusterIP None <none> 9091/TCP 62m
demo-milvus-querycoord ClusterIP 172.20.136.213 <none> 19531/TCP,9091/TCP 62m
demo-milvus-querynode ClusterIP None <none> 9091/TCP 62m
demo-milvus-rootcoord ClusterIP 172.20.173.98 <none> 53100/TCP,9091/TCP 62m
Você pode ver vários serviços. O Milvus oferece suporte a duas portas, porta 19530 e porta 9091:
A porta 19530 é para gRPC e API RESTful. Ela é a porta padrão quando você se conecta a um servidor Milvus com diferentes SDKs do Milvus ou clientes HTTP.
A porta 9091 é uma porta de gerenciamento para coleta de métricas, profiling pprof e sondas de integridade dentro do Kubernetes.
Entre eles, o serviço demo-milvus fornece um endpoint de acesso ao banco de dados, que é usado para estabelecer uma conexão com clientes. O endpoint do banco de dados é acessado pelo NLB como balanceador de carga do serviço. Você pode obter o endpoint do serviço NLB na coluna EXTERNAL-IP.
Anote a coluna EXTERNAL-IP do NLB, que neste caso é:
milvus-nlb-xxxx.elb.us-west-2.amazonaws.com 19530:31201/TCP,9091:31088/TCP
Acessar Endpoints do Milvus usando Attu
Quando instalamos o Milvus, também instalamos o Attu, uma ferramenta de administração para gerenciar o Milvus. Execute o seguinte comando para obter o endpoint:
% kubectl get ingress -n milvus
NAME CLASS HOSTS ADDRESS PORTS AGE
demo-milvus-attu <none> * k8s-attu-xxxx.us-west-2.elb.amazonaws.com 80 27s
Você deve ver um ingress chamado demo-milvus-attu, onde a coluna ADDRESS é a URL externa.
Abra o endereço do Ingress em um navegador e veja a seguinte página.
Clique em Connect para fazer login.
interface do attu
Depois de fazer login, você pode gerenciar bancos de dados Milvus por meio de:
gerenciar Milvus usando Attu
Testar o Banco de Dados Vetorial Milvus
Você pode usar o código de exemplo oficial do Milvus para testar se o banco de dados Milvus está funcionando corretamente.
- Etapa 1: Baixe diretamente o código de exemplo hello_milvus.py.
% wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py
- Etapa 2: Modifique o host no código de exemplo para o endpoint Kubernetes do Milvus que obtivemos anteriormente.
print(fmt.format("start connecting to Milvus"))
connections.connect(
"default",
host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com",
port="19530")
- Etapa 3: Execute o código. Se o seguinte resultado for retornado, o Milvus está funcionando normalmente.
% python3 hello_milvus.py
=== start connecting to Milvus ===
Does collection hello_milvus exist in Milvus: False
=== Create collection `hello_milvus` ===
=== Start inserting entities ===
Number of entities in Milvus: 3000
=== Start Creating index IVF_FLAT ===
=== Start loading ===
Agora você configurou o Milvus no EKS com sucesso! PARABÉNS!!!
Conclusão
Este post apresentou o banco de dados vetorial de código aberto Milvus e explicou como implantá-lo na AWS usando serviços gerenciados como Amazon EKS, S3, MSK e ELB para obter maior elasticidade e confiabilidade.
Recursos
Blog do AWS Milvus EKS: https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
Guia do Milvus EKS: https://milvus.io/docs/eks.md
Guia de Configuração do Amazon EKS: https://docs.aws.amazon.com/eks/latest/userguide/setting-up.html
Guia do Usuário do Amazon EKS: https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html
Site Oficial do Milvus: https://milvus.io/
Github do Milvus: https://github.com/milvus-io/milvus
Site Oficial do eksctl: https://eksctl.io/
Arquivos YAML de que você precisará para a instalação:
Arquivo eks_cluster.yaml: https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
Arquivo milvus_helm.yaml: https://raw.githubusercontent.com/milvus-io/milvus-helm/master/charts/milvus/values.yaml
Arquivo milvus_cluster.yaml: Copie/cole de dentro deste blog.
Continue lendo
The AWS Outage Was a Wake-Up Call for Vector Database Cross-Region Disaster Recovery
Zilliz Cloud Had the Answer Before the Crisis. Zilliz Cloud is the world's first vector database with native cross-region disaster recovery.
Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.
Milvus WebUI: A Visual Management Tool for Your Vector Database
Explore Milvus WebUI to monitor, manage, and optimize your vector database with real-time insights, performance tracking, and system health monitoring.