À propos de Milvus
Commencer
Concepts
Guide de l'utilisateur
Modèles
Milvus Migration
Guide d'administration
Outils
Intégrations
Tutoriels
FAQ
API Reference

(Obsolète) Déployer un cluster Milvus sur EC2

Cette rubrique décrit comment déployer un cluster Milvus sur Amazon EC2 avec Terraform et Ansible.

Cette rubrique est obsolète et sera bientôt supprimée. Il est conseillé de se référer à Déployer un cluster Milvus sur EKS à la place.

Provisionnement d'un cluster Milvus

Cette section décrit comment utiliser Terraform pour provisionner un cluster Milvus.

Terraform est un outil logiciel d'infrastructure en tant que code (IaC). Avec Terraform, vous pouvez provisionner l'infrastructure en utilisant des fichiers de configuration déclaratifs.

Conditions préalables

Installer et configurer Terraform
Installer et configurer AWS CLI

Préparer la configuration

Vous pouvez télécharger des fichiers de configuration modèles sur Google Drive.

main.tf

Ce fichier contient la configuration pour le provisionnement d'un cluster Milvus.
variables.tf

Ce fichier permet d'éditer rapidement les variables utilisées pour configurer ou mettre à jour un cluster Milvus.
output.tf et inventory.tmpl

Ces fichiers stockent les métadonnées d'un cluster Milvus. Les métadonnées utilisées dans cette rubrique sont public_ip pour chaque instance de nœud, private_ip pour chaque instance de nœud et tous les ID d'instance EC2.

Préparer les variables.tf

Cette section décrit la configuration qu'un fichier variables.tf contient.

Nombre de nœuds

Le modèle suivant déclare une variable index_count utilisée pour définir le nombre de nœuds d'index.

La valeur de index_count doit être supérieure ou égale à un.
```
variable "index_count" {
  description = "Amount of index instances to run"
  type        = number
  default     = 5
}
```
Type d'instance pour un type de nœud

Le modèle suivant déclare une variable index_ec2_type utilisée pour définir le type d'instance des nœuds d'index.
```
variable "index_ec2_type" {
  description = "Which server type"
  type        = string
  default     = "c5.2xlarge"
}
```

Autorisation d'accès

Le modèle suivant déclare une variable key_name et une variable my_ip. La variable key_name représente la clé d'accès AWS. La variable my_ip représente la plage d'adresses IP pour un groupe de sécurité.

variable "key_name" {
  description = "Which aws key to use for access into instances, needs to be uploaded already"
  type        = string
  default     = ""
}

variable "my_ip" {
  description = "my_ip for security group. used so that ansible and terraform can ssh in"
  type        = string
  default     = "x.x.x.x/32"
}

Préparer main.tf

Cette section décrit les configurations que doit contenir un fichier main.tf.

Fournisseur de cloud et région

Le modèle suivant utilise la région us-east-2. Voir Régions disponibles pour plus d'informations.
```
provider "aws" {
  profile = "default"
  region  = "us-east-2"
}
```

Groupe de sécurité

Le modèle suivant déclare un groupe de sécurité qui autorise le trafic entrant provenant de la plage d'adresses CIDR représentée par my_ip déclarée dans variables.tf.

resource "aws_security_group" "cluster_sg" {
  name        = "cluster_sg"
  description = "Allows only me to access"
  vpc_id      = aws_vpc.cluster_vpc.id

  ingress {
    description      = "All ports from my IP"
    from_port        = 0
    to_port          = 65535
    protocol         = "tcp"
    cidr_blocks      = [var.my_ip]
  }

  ingress {
    description      = "Full subnet communication"
    from_port        = 0
    to_port          = 65535
    protocol         = "all"
    self             = true
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Name = "cluster_sg"
  }
}

VPC

Le modèle suivant spécifie un VPC avec le bloc CIDR 10.0.0.0/24 sur un cluster Milvus.

resource "aws_vpc" "cluster_vpc" {
  cidr_block = "10.0.0.0/24"
  tags = {
    Name = "cluster_vpc"
  }
}

resource "aws_internet_gateway" "cluster_gateway" {
  vpc_id = aws_vpc.cluster_vpc.id

  tags = {
    Name = "cluster_gateway"
  }
}

Sous-réseaux (facultatif)

Le modèle suivant déclare un sous-réseau dont le trafic est acheminé vers une passerelle internet. Dans ce cas, la taille du bloc CIDR du sous-réseau est la même que celle du bloc CIDR du VPC.

resource "aws_subnet" "cluster_subnet" {
  vpc_id                  = aws_vpc.cluster_vpc.id
  cidr_block              = "10.0.0.0/24"
  map_public_ip_on_launch = true

  tags = {
    Name = "cluster_subnet"
  }
}

resource "aws_route_table" "cluster_subnet_gateway_route" {
  vpc_id       = aws_vpc.cluster_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.cluster_gateway.id
  }

  tags = {
    Name = "cluster_subnet_gateway_route"
  }
}

resource "aws_route_table_association" "cluster_subnet_add_gateway" {
  subnet_id      = aws_subnet.cluster_subnet.id
  route_table_id = aws_route_table.cluster_subnet_gateway_route.id
}

Instances de nœuds (nœuds)

Le modèle suivant déclare une instance de nœud MinIO. Le fichier modèle main.tf déclare des nœuds de 11 types. Pour certains types de nœuds, vous devez définir root_block_device. Voir EBS, Ephemeral et Root Block Devices pour plus d'informations.

resource "aws_instance" "minio_node" {
  count         = var.minio_count
  ami           = "ami-0d8d212151031f51c"
  instance_type = var.minio_ec2_type
  key_name      = var.key_name
  subnet_id     = aws_subnet.cluster_subnet.id 
  vpc_security_group_ids = [aws_security_group.cluster_sg.id]

  root_block_device {
    volume_type = "gp2"
    volume_size = 1000
  }
  
  tags = {
    Name = "minio-${count.index + 1}"
  }
}

Appliquer la configuration

Ouvrez un terminal et accédez au dossier dans lequel se trouve main.tf.
Pour initialiser la configuration, exécutez terraform init.
Pour appliquer la configuration, exécutez terraform apply et entrez yes lorsque vous y êtes invité.

Vous avez maintenant provisionné un cluster Milvus avec Terraform.

Démarrer le cluster Milvus

Cette section décrit comment utiliser Ansible pour démarrer le cluster Milvus que vous avez provisionné.

Ansible est un outil de gestion de la configuration utilisé pour automatiser le provisionnement du cloud et la gestion de la configuration.

Conditions préalables

Ansible Controller est installé.

Télécharger le Playbook de déploiement de nœuds Milvus Ansible

Cloner le dépôt Milvus à partir de GitHub pour télécharger le manuel de déploiement de nœuds Ansible Milvus.

git clone https://github.com/milvus-io/milvus.git

Configurer les fichiers d'installation

Les fichiers inventory.ini et ansible.cfg sont utilisés pour contrôler les variables d'environnement et les méthodes de vérification de connexion dans le playbook Ansible. Dans le fichier inventory.ini, la section dockernodes définit tous les serveurs des moteurs Docker. La section ansible.cfg définit tous les serveurs des coordinateurs Milvus. La section node définit tous les serveurs des nœuds Milvus.

Entrez le chemin local vers le Playbook et configurez les fichiers d'installation.

$ cd ./milvus/deployments/docker/cluster-distributed-deployment

`inventory.ini`

Configurer inventory.ini pour diviser les hôtes en groupes en fonction de leur rôle dans le système Milvus.

Ajouter des noms d'hôtes et définir le groupe docker et vars.

[dockernodes] #Add docker host names.
dockernode01
dockernode02
dockernode03

[admin] #Add Ansible controller name.
ansible-controller

[coords] #Add the host names of Milvus coordinators.
; Take note the IP of this host VM, and replace 10.170.0.17 with it.
dockernode01

[nodes] #Add the host names of Milvus nodes.
dockernode02

[dependencies] #Add the host names of Milvus dependencies.
; dependencies node will host etcd, minio, pulsar, these 3 roles are the foundation of Milvus. 
; Take note the IP of this host VM, and replace 10.170.0.19 with it.
dockernode03

[docker:children]
dockernodes
coords
nodes
dependencies

[docker:vars]
ansible_python_interpreter= /usr/bin/python3
StrictHostKeyChecking= no

; Setup variables to control what type of network to use when creating containers.
dependencies_network= host
nodes_network= host

; Setup varibale to control what version of Milvus image to use.
image= milvusdb/milvus-dev:master-20220412-4781db8a

; Setup static IP addresses of the docker hosts as variable for container environment variable config.
; Before running the playbook, below 4 IP addresses need to be replaced with the IP of your host VM
; on which the etcd, minio, pulsar, coordinators will be hosted.
etcd_ip= 10.170.0.19
minio_ip= 10.170.0.19
pulsar_ip= 10.170.0.19
coords_ip= 10.170.0.17

; Setup container environment which later will be used in container creation.
ETCD_ENDPOINTS= {{etcd_ip}}:2379 
MINIO_ADDRESS= {{minio_ip}}:9000
PULSAR_ADDRESS= pulsar://{{pulsar_ip}}:6650
QUERY_COORD_ADDRESS= {{coords_ip}}:19531
DATA_COORD_ADDRESS= {{coords_ip}}:13333
ROOT_COORD_ADDRESS= {{coords_ip}}:53100
INDEX_COORD_ADDRESS= {{coords_ip}}:31000

`ansible.cfg`

ansible.cfg Contrôler l'action du playbook, par exemple, la clé SSH, etc. Ne configurez pas de phrase de passe via la clé SSH sur les hôtes docker. Sinon, la connexion SSH d'Ansible échouera. Nous recommandons de configurer le même nom d'utilisateur et la même clé SSH sur les trois hôtes et de configurer le nouveau compte utilisateur pour qu'il exécute sudo sans mot de passe. Sinon, vous recevrez des erreurs indiquant que le nom d'utilisateur ne correspond pas au mot de passe ou que vous ne disposez pas de privilèges élevés lors de l'exécution du playbook Ansible.

[defaults]
host_key_checking = False
inventory = inventory.ini # Specify the Inventory file
private_key_file=~/.my_ssh_keys/gpc_sshkey # Specify the SSH key that Ansible uses to access Docker host

`deploy-docker.yml`

deploy-docker.yml définit les tâches lors de l'installation de Docker. Voir les commentaires du code dans le fichier pour plus de détails.

---
- name: setup pre-requisites # Install prerequisite
  hosts: all
  become: yes
  become_user: root
  roles:
    - install-modules
    - configure-hosts-file

- name: install docker
  become: yes
  become_user: root
  hosts: dockernodes
  roles:
    - docker-installation

Tester la connectivité d'Ansible

Testez la connectivité avec Ansible.

$ ansible all -m ping

Ajoutez -i dans la commande pour spécifier le chemin du fichier d'inventaire si vous ne l'avez pas spécifié dans ansible.cfg, sinon Ansible utilise /etc/ansible/hosts.

Le terminal renvoie le message suivant :

dockernode01 | SUCCESS => {
"changed": false,
"ping": "pong"
}
ansible-controller | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
dockernode03 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
dockernode02 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Check the Playbook Syntax (Vérifier la syntaxe du Playbook)

Vérifiez la syntaxe du Playbook.

$ ansible-playbook deploy-docker.yml --syntax-check

Normalement, le terminal renvoie le message suivant :

playbook: deploy-docker.yml

Installer Docker

Installer Docker avec le Playbook.

$ ansible-playbook deploy-docker.yml

Si Docker est installé avec succès sur les trois hôtes, le terminal renvoie le message suivant :

TASK [docker-installation : Install Docker-CE] *******************************************************************
ok: [dockernode01]
ok: [dockernode03]
ok: [dockernode02]

TASK [docker-installation : Install python3-docker] **************************************************************
ok: [dockernode01]
ok: [dockernode02]
ok: [dockernode03]

TASK [docker-installation : Install docker-compose python3 library] **********************************************
changed: [dockernode01]
changed: [dockernode03]
changed: [dockernode02]

PLAY RECAP *******************************************************************************************************
ansible-controller         : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
dockernode01               : ok=10   changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
dockernode02               : ok=10   changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
dockernode03               : ok=10   changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Vérifier l'installation

Connectez-vous aux trois hôtes avec la clé SSH et vérifiez l'installation sur les hôtes.

Pour l'hôte root :

$ docker -v

Pour les hôtes non root :

$ sudo docker -v

Normalement, le terminal renvoie l'information suivante :

Docker version 20.10.14, build a224086

Vérifier l'état de fonctionnement des conteneurs.

$ docker ps

Vérifier la syntaxe

Vérifier la syntaxe de deploy-milvus.yml.

$ ansible-playbook deploy-milvus.yml --syntax-check

Normalement, le terminal renvoie le message suivant :

playbook: deploy-milvus.yml

Créer le conteneur Milvus

Les tâches de création du conteneur Milvus sont définies dans deploy-milvus.yml.

$ ansible-playbook deploy-milvus.yml

Le terminal retourne :

PLAY [Create milvus-etcd, minio, pulsar] *****************************************************************

TASK [Gathering Facts] ********************************************************************************************
ok: [dockernode03]

TASK [etcd] *******************************************************************************************************
changed: [dockernode03]

TASK [pulsar] *****************************************************************************************************
changed: [dockernode03]

TASK [minio] ******************************************************************************************************
changed: [dockernode03]

PLAY [Create milvus nodes] ****************************************************************************************

TASK [Gathering Facts] ********************************************************************************************
ok: [dockernode02]

TASK [querynode] **************************************************************************************************
changed: [dockernode02]

TASK [datanode] ***************************************************************************************************
changed: [dockernode02]

TASK [indexnode] **************************************************************************************************
changed: [dockernode02]

PLAY [Create milvus coords] ***************************************************************************************

TASK [Gathering Facts] ********************************************************************************************
ok: [dockernode01]

TASK [rootcoord] **************************************************************************************************
changed: [dockernode01]

TASK [datacoord] **************************************************************************************************
changed: [dockernode01]

TASK [querycoord] *************************************************************************************************
changed: [dockernode01]

TASK [indexcoord] *************************************************************************************************
changed: [dockernode01]

TASK [proxy] ******************************************************************************************************
changed: [dockernode01]

PLAY RECAP ********************************************************************************************************
dockernode01               : ok=6    changed=5    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
dockernode02               : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
dockernode03               : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Milvus est maintenant déployé sur les trois hôtes.

Arrêter les nœuds

Vous pouvez arrêter tous les nœuds lorsque vous n'avez plus besoin d'un cluster Milvus.

Assurez-vous que le binaire terraform est disponible sur votre site PATH.

Exécutez terraform destroy et entrez yes lorsque vous y êtes invité.
En cas de succès, toutes les instances de nœuds sont arrêtées.

Prochaines étapes

Si vous souhaitez apprendre à déployer Milvus sur d'autres clouds :

Traduit par DeepL

Table de contenu

(Obsolète) Déployer un cluster Milvus sur EC2
Provisionnement d'un cluster Milvus
Démarrer le cluster Milvus
Arrêter les nœuds
Prochaines étapes

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 ?