**Aidez à améliorer cette page** Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page. Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Exécuter un entraînement de machine learning sur Amazon EKS avec Elastic Fabric Adapter Cette rubrique décrit comment intégrer Elastic Fabric Adapter (EFA) aux pods déployés dans votre cluster Amazon EKS. Elastic Fabric Adapter (EFA) est une interface réseau pour les instances Amazon EC2 qui vous permet d'exécuter des applications nécessitant des niveaux élevés de communications inter-nœuds à grande échelle sur AWS. Son interface matérielle sur mesure de contournement du système d'exploitation améliore les performances des communications entre instances, ce qui est essentiel à la mise à l'échelle de ces applications. Avec EFA, les applications de calcul haute performance (HPC) utilisant l'interface de passage de message (MPI) et les applications Machine Learning (ML) utilisant la bibliothèque de communications collectives (NCCL) de NVIDIA peuvent atteindre des milliers de ou. CPUs GPUs Vous bénéficiez ainsi des performances applicatives des clusters HPC sur site avec l'élasticité et la flexibilité à la demande du AWS cloud. L'intégration d'EFA aux applications exécutées sur des clusters Amazon EKS permet de réduire le temps nécessaire à l'exécution des applications d'entraînement distribué à grande échelle sans avoir à ajouter d'autres instances à votre cluster. Pour plus d'informations sur l'EFA, consultez [Elastic Fabric Adapter](https://aws.amazon.com/hpc/efa/). ## Types d’instances avec EFA Le *plug-in AWS EFA Kubernetes Device* prend en charge tous les types d'instances Amazon EC2 dotés d'EFA. Pour consulter la liste de tous les types d’instances qui disposent d’EFA, consultez [Types d’instances pris en charge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) dans le *Guide de l’utilisateur Amazon EC2*. Toutefois, pour exécuter rapidement des applications ML, nous recommandons qu'une instance dispose de puces d'accélération matérielle telles que les puces NVidia GPUs, [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/) ou [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/), en plus de l'EFA. Pour obtenir la liste des types d’instances disposant de puces d’accélération matérielle et d’EFA, consultez [Calcul accéléré](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types) dans le *Guide de l’utilisateur Amazon EC2*. Lorsque vous comparez les types d’instance afin de faire votre choix, tenez compte du nombre de cartes réseau EFA disponibles pour ce type d’instance, ainsi que du nombre de cartes accélératrices, de la quantité de CPU et de la quantité de mémoire. Vous pouvez attribuer un EFA maximum par carte réseau. Une EFA compte comme une interface réseau. Pour connaître le nombre d’EFA disponibles pour chaque type d’instance disposant d’EFA, consultez la liste des [cartes réseau](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) dans le *Guide de l’utilisateur Amazon EC2*. ## Interfaces EFA et EFA uniquement Un *Elastic Fabric Adapter (EFA)* est une interface réseau qui combine les fonctionnalités d'un adaptateur réseau élastique (ENA) et d'une interface de contournement du système d'exploitation, alimentée par AWS le protocole Scalable Reliable Datagram (SRD). Les fonctionnalités EFA permettent aux applications de communiquer directement avec le matériel pour un transport à faible latence. Vous pouvez choisir d’accéder uniquement aux capacités EFA à l’aide d’interfaces *EFA uniquement*, limitant ainsi la communication aux interfaces au sein de la même zone de disponibilité. Pour créer des nœuds pouvant disposer d’interfaces EFA uniquement, vous devez utiliser un modèle de lancement EC2 personnalisé et définir le `InterfaceType` sur `efa-only`. Dans votre modèle de lancement personnalisé, vous ne pouvez pas définir la carte réseau `0` comme interface EFA uniquement, car il s’agit de la carte réseau principale et de l’interface réseau de l’instance EC2. Vous devez disposer de la version `1.18.5` ou ultérieure de CNI VPC pour les interfaces EFA uniquement. Si vous utilisez Amazon Linux 2, la version ami doit être `v20240928` ou ultérieure pour les interfaces EFA uniquement. La procédure suivante vous guide pour créer un cluster EKS avec des nœuds `eksctl` dotés d'interfaces NVidia GPUs et EFA. Vous ne pouvez pas utiliser `eksctl` pour créer des nœuds et des groupes de nœuds qui utilisent des interfaces EFA uniquement. ## Conditions préalables + Un cluster Amazon EKS existant. Si vous ne disposez pas d’un cluster existant, veuillez en créer un à l’aide de [Mise en route avec Amazon EKS](getting-started.md). Votre cluster doit être déployé dans un VPC disposant d'au moins un sous-réseau privé ayant suffisamment d'adresses IP disponibles dans lequel déployer des nœuds. Le sous-réseau privé doit disposer d'un accès Internet sortant fourni par un appareil externe, tel qu'une passerelle NAT. Si vous prévoyez d'utiliser `eksctl` pour créer votre groupe de nœuds, `eksctl` peut également créer un cluster pour vous. + Version `2.12.3` ou version ultérieure `1.27.160` ou version ultérieure de l'interface de ligne de AWS commande (AWS CLI) installée et configurée sur votre appareil ou AWS CloudShell. Pour vérifier votre version actuelle, utilisez `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Les gestionnaires de packages tels que `yum` Homebrew pour macOS ont souvent plusieurs versions de retard sur la dernière version de la AWS CLI. `apt-get` Pour installer la dernière version, consultez la section [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) et [configuration rapide avec aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) dans le *Guide de l'utilisateur de l'interface de ligne de AWS commande*. La version de la AWS CLI installée AWS CloudShell peut également avoir plusieurs versions de retard par rapport à la dernière version. Pour le mettre à jour, consultez la section [Installation de la AWS CLI dans votre répertoire](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) de base dans le *guide de AWS CloudShell l'utilisateur*. + L'outil de ligne de commande `kubectl` est installé sur votre appareil ou AWS CloudShell. La version peut correspondre à celle utilisée par votre cluster Kubernetes, ou différer d’au plus une version mineure, qu’elle soit antérieure ou plus récente. Par exemple, si la version de votre cluster est `1.29`, vous pouvez utiliser la version `kubectl` `1.28`, `1.29` ou `1.30`. Pour installer ou mettre à niveau `kubectl`, veuillez consulter [Configuration de `kubectl` et `eksctl`](install-kubectl.md). + Vous devez avoir installé le plug-in CNI Amazon VPC pour Kubernetes version `1.7.10` ou ultérieure avant de lancer des composants master qui prennent en charge plusieurs adaptateurs Elastic Fabric, tels que `p4d` ou `p5`. Pour plus d’informations sur la mise à jour de votre plug-in CNI Amazon VPC pour Kubernetes, consultez [Attribuer IPs à des pods avec l'Amazon VPC CNI](managing-vpc-cni.md). + Pour les instances p6-b200, vous devez utiliser le plug-in périphérique EFA Device Plugin version v0.5.6 ou ultérieure. **Important** Une considération importante requise pour adopter EFA avec Kubernetes est la configuration et la gestion de Huge Pages en tant que ressource dans le cluster. Pour plus d'informations, consultez [Gérer Huge Pages](https://kubernetes.io/docs/tasks/manage-hugepages/scheduling-hugepages/) dans la documentation Kubernetes. Les instances Amazon EC2 sur lesquelles le pilote EFA est installé pré-allouent 5128 pages géantes de 2 Mo, que vous pouvez demander comme ressources à utiliser dans vos spécifications de tâche. ## Créer un groupe de nœuds La procédure suivante vous aide à créer un groupe de nœuds avec un groupe de nœuds `p4d.24xlarge` sauvegardé avec des interfaces EFA et GPUDirect RDMA, et à exécuter un exemple de test NVIDIA Collective Communications Library (NCCL) pour les performances NCCL multi-nœuds à l'aide de. EFAs L'exemple peut être utilisé comme modèle de formation en profondeur distribuée sur Amazon EKS à l'aide de EFAs. 1. Déterminez quels types d'instances Amazon EC2 prenant en charge l'EFA sont disponibles dans la AWS région dans laquelle vous souhaitez déployer des nœuds. *region-code*Remplacez-le par la AWS région dans laquelle vous souhaitez déployer votre groupe de nœuds. ``` aws ec2 describe-instance-types --region region-code \ --filters Name=network-info.efa-supported,Values=true \ --query "InstanceTypes[*].[InstanceType]" --output text ``` Lorsque vous déployez des nœuds, le type d'instance que vous souhaitez déployer doit être disponible dans la AWS région dans laquelle se trouve votre cluster. 1. Déterminez dans quelles zones de disponibilité le type d'instance que vous souhaitez déployer est disponible. Dans ce didacticiel, le type d'`p5.48xlarge`instance est utilisé et doit être renvoyé dans la sortie pour la AWS région que vous avez spécifiée à l'étape précédente. Lorsque vous déployez des nœuds dans un cluster de production, remplacez-les *p5.48xlarge* par n'importe quel type d'instance renvoyé à l'étape précédente. ``` aws ec2 describe-instance-type-offerings --region region-code \ --location-type availability-zone --filters Name=instance-type,Values=p4d.24xlarge,p5.48xlarge \ --query 'InstanceTypeOfferings[*].Location' --output text ``` L'exemple qui suit illustre un résultat. ``` us-west-2a us-west-2c us-west-2b ``` Notez les zones de disponibilité renvoyées pour une utilisation ultérieure. Lorsque vous déployez des nœuds sur un cluster, votre VPC doit disposer de sous-réseaux avec des adresses IP disponibles dans l'une des zones de disponibilité renvoyées dans la sortie. 1. Créez un groupe de nœuds à l’aide de `eksctl`. Vous avez besoin d'`0.215.0`une version ou d'une version ultérieure de l'outil de ligne de `eksctl` commande installée sur votre appareil ou AWS CloudShell. Pour installer ou mettre à jour `eksctl`, veuillez consulter [Installation](https://eksctl.io/installation) dans la documentation de `eksctl`. 1. Copiez le contenu suivant dans un fichier nommé *efa-cluster.yaml*. Remplacez les exemples de valeurs par les vôtres. Vous pouvez remplacer `p5.48xlarge` par une instance différente. Dans ce cas, assurez-vous que les valeurs de `availabilityZones` sont des zones de disponibilité renvoyées pour le type d'instance à l'étape 1. ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-efa-cluster region: region-code version: "1.XX" iam: withOIDC: true availabilityZones: ["us-west-2a", "us-west-2c"] managedNodeGroups: - name: my-efa-ng instanceType: p5.48xlarge minSize: 1 desiredCapacity: 2 maxSize: 3 availabilityZones: ["us-west-2a"] volumeSize: 300 privateNetworking: true efaEnabled: true ``` 1. Créez un groupe de nœuds gérés dans un cluster existant. ``` eksctl create nodegroup -f efa-cluster.yaml ``` Si vous ne disposez pas d’un cluster existant, vous pouvez exécuter la commande suivante pour créer un cluster et le groupe de nœuds. ``` eksctl create cluster -f efa-cluster.yaml ``` **Note** Comme le type d'instance utilisé dans cet exemple l'est GPUs, le plug-in pour appareil NVIDIA Kubernetes est `eksctl` automatiquement installé sur chaque instance lorsque vous utilisez Amazon Linux 2. Cela n’est pas nécessaire pour Bottlerocket, car le plug-in NVIDIA device est créé dans la variante EKS NVIDIA de Bottlerocket. Lorsque `efaEnabled` est défini sur `true` dans la configuration du groupe de nœuds, `eksctl` déploie également automatiquement le plug-in de périphérique EFA sur les nœuds. ### Utilisation de Bottlerocket avec EFA La version 1.28.0 et les versions ultérieures de l’AMI Bottlerocket incluent la prise en charge officielle d’EFA. Pour utiliser Bottlerocket pour les nœuds compatibles EFA, spécifiez `amiFamily: Bottlerocket` dans votre configuration. Si vous devez utiliser un identifiant AMI personnalisé, vous devez utiliser des `nodeGroups` standard au lieu de `managedNodeGroups`. Voici un exemple de configuration : ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-efa-bottlerocket-cluster region: region-code version: "1.XX" iam: withOIDC: true availabilityZones: ["us-west-2a", "us-west-2c"] managedNodeGroups: - name: my-efa-bottlerocket-ng instanceType: p5.48xlarge minSize: 1 desiredCapacity: 2 maxSize: 3 availabilityZones: ["us-west-2a"] volumeSize: 300 privateNetworking: true efaEnabled: true amiFamily: Bottlerocket bottlerocket: enableAdminContainer: true settings: kernel: sysctl: "vm.nr_hugepages": "3000" # Configures 3000 * 2Mi = 6000Mi hugepages ``` Le paramètre sysctl `vm.nr_hugepages` ci-dessus configure le nombre de pages géantes de 2 Mi. Dans cet exemple, 3000 signifie 3000 \$1 2 Mi = 6000 Mi de pages géantes. ### Vérifier l’installation du plug-in de périphérique EFA Lorsque vous créez un groupe de nœuds avec `efaEnabled: true`, `eksctl` déploie automatiquement le plug-in du périphérique Kubernetes EFA pour vous. Vous pouvez vérifier que le plug-in de périphérique est installé et fonctionne correctement : 1. Vérifiez le DaemonSet statut : ``` kubectl get daemonsets -n kube-system ``` Exemple de sortie : ``` NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE aws-efa-k8s-device-plugin-daemonset 2 2 2 2 2 6m16s ... ``` Ici, le plug-in de l'appareil EFA DaemonSet s'exécute sur deux nœuds. Les deux sont READY et AVAILABLE. 1. Vérifiez ensuite les pods créés par DaemonSet : ``` kubectl get pods -n kube-system -l name=aws-efa-k8s-device-plugin ``` Exemple de sortie : ``` NAME READY STATUS RESTARTS AGE aws-efa-k8s-device-plugin-daemonset-d68bs 1/1 Running 0 6m16s aws-efa-k8s-device-plugin-daemonset-w4l8t 1/1 Running 0 6m16s ``` Les pods du plug-in de périphérique EFA sont dans un état Running, ce qui confirme que le plug-in est correctement déployé et opérationnel. 1. Vérifiez l’enregistrement des ressources : Vous pouvez vérifier que la ressource `vpc.amazonaws.com/efa` est enregistrée auprès du kubelet en décrivant les nœuds : ``` kubectl describe nodes ``` Si la ressource EFA est correctement enregistrée, elle apparaîtra dans la liste sous Capacity et Allocatable resources du nœud. Par exemple : ``` Capacity: ... vpc.amazonaws.com/efa: 4 Allocatable: ... vpc.amazonaws.com/efa: 4 ``` Cette sortie confirme que le nœud reconnaît la ressource EFA, la rendant disponible pour les pods qui la demandent. ## (Facultatif) Tester les performances de l’EFA Nous vous recommandons de tester la configuration EFA. Vous pouvez utiliser les [tests NCCL](https://github.com/aws-samples/awsome-distributed-training/tree/main/micro-benchmarks/nccl-tests) dans le `aws-samples/awsome-distributed-training` référentiel sur. GitHub Les [tests NCCL](https://github.com/NVIDIA/nccl-tests) évaluent les performances du réseau à l’aide de la bibliothèque Nvidia Collective Communication Library. Les étapes suivantes permettent de soumettre des tests NCCL sur Amazon EKS. 1. Déployez l’opérateur Kubeflow MPI : Pour les tests NCCL, vous pouvez appliquer l'opérateur MPI Kubeflow. L'opérateur MPI facilite l'exécution d'un entraînement distribué de style AllReduce sur Kubernetes. Pour plus d'informations, consultez la section [Opérateur MPI activé](https://github.com/kubeflow/mpi-operator) GitHub. 1. Exécutez le test de performance NCCL multi-nœuds pour vérifier le RDMA/EFA : GPUDirect Pour vérifier les performances du NCCL avec GPUDirect RDMA sur EFA, exécutez le test de performance NCCL standard. Pour plus d'informations, consultez le dépôt officiel des [tests NCCL sur](https://github.com/NVIDIA/nccl-tests.git). GitHub Procédez comme indiqué ci-dessous pour exécuter un test de performance NCCL à deux nœuds. Dans l'exemple de tâche de test NCCL, chaque travailleur demande huit GPUs, 5210 Mo`hugepages-2Mi`, quatre et 8 000 Mo de mémoire EFAs, ce qui signifie en fait que chaque travailleur consomme toutes les ressources d'une instance. `p5.48xlarge` 1. Créez le MPIJob manifeste : Copiez ce qui suit dans un fichier nommé `nccl-tests.yaml` : ``` apiVersion: kubeflow.org/v2beta1 kind: MPIJob metadata: name: nccl-tests spec: runPolicy: cleanPodPolicy: Running backoffLimit: 20 slotsPerWorker: 8 mpiReplicaSpecs: Launcher: replicas: 1 template: spec: restartPolicy: OnFailure containers: - image: public.ecr.aws/hpc-cloud/nccl-tests:latest imagePullPolicy: IfNotPresent name: test-nccl-launcher env: - name: PATH value: $PATH:/opt/amazon/efa/bin:/usr/bin command: - /opt/amazon/openmpi/bin/mpirun - --allow-run-as-root - --tag-output - -np - "16" - -N - "8" - --bind-to - none - -x - PATH - -x - LD_LIBRARY_PATH - -x - NCCL_DEBUG=INFO - -x - NCCL_BUFFSIZE=8388608 - -x - NCCL_P2P_NET_CHUNKSIZE=524288 - -x - NCCL_TUNER_PLUGIN=/opt/amazon/ofi-nccl/lib/x86_64-linux-gnu/libnccl-ofi-tuner.so - --mca - pml - ^cm,ucx - --mca - btl - tcp,self - --mca - btl_tcp_if_exclude - lo,docker0,veth_def_agent - /opt/nccl-tests/build/all_reduce_perf - -b - "8" - -e - "16G" - -f - "2" - -g - "1" - -c - "1" - -n - "100" Worker: replicas: 2 template: spec: nodeSelector: node.kubernetes.io/instance-type: "p5.48xlarge" containers: - image: public.ecr.aws/hpc-cloud/nccl-tests:latest imagePullPolicy: IfNotPresent name: nccl-tests-worker volumeMounts: - name: shmem mountPath: /dev/shm resources: limits: nvidia.com/gpu: 8 hugepages-2Mi: 5120Mi vpc.amazonaws.com/efa: 32 memory: 32000Mi requests: nvidia.com/gpu: 8 hugepages-2Mi: 5120Mi vpc.amazonaws.com/efa: 32 memory: 32000Mi volumes: - name: shmem hostPath: path: /dev/shm ``` 1. Appliquez les tests NCCL : MPIJob Soumettez le `MPIJob` en appliquant le manifeste. Cela créera deux instances Amazon EC2 `p5.48xlarge`. ``` kubectl apply -f nccl-tests.yaml ``` L'exemple qui suit illustre un résultat. ``` mpijob.kubeflow.org/nccl-tests created ``` 1. Vérifiez que la tâche a démarré les pods : Affichez vos pods en cours d’exécution. ``` kubectl get pods ``` L'exemple qui suit illustre un résultat. ``` NAME READY STATUS RESTARTS AGE nccl-tests-launcher-nbql9 0/1 Init:0/1 0 2m49s nccl-tests-worker-0 1/1 Running 0 2m49s nccl-tests-worker-1 1/1 Running 0 2m49s ``` L’opérateur MPI crée un pod de lancement et deux pods de travail (un sur chaque nœud). 1. Vérifiez que la tâche s’exécute correctement avec les journaux : Consultez le journal du pod `nccl-tests-launcher`. Remplacez *nbql9* par la valeur de votre sortie. ``` kubectl logs -f nccl-tests-launcher-nbql9 ``` Si le test s’est terminé avec succès, vous pouvez déployer vos applications qui utilisent la bibliothèque Nvidia Collective Communication Library.