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. # Configurations réseau AWS ParallelCluster utilise Amazon Virtual Private Cloud (VPC) pour la mise en réseau. Le VPC fournit une plate-forme réseau flexible et configurable sur laquelle vous pouvez déployer des clusters. Le VPC doit avoir `DNS Resolution = yes` `DNS Hostnames = yes` et des options DHCP avec le nom de domaine correct pour la région. Le jeu d'options DHCP par défaut spécifie déjà le *AmazonProvidedDNS* requis. Si vous spécifiez plusieurs serveurs de noms de domaine, consultez les [ensembles d'options DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) dans le guide de l'*utilisateur Amazon VPC*. AWS ParallelCluster prend en charge les configurations de haut niveau suivantes : + Un sous-réseau pour les nœuds de tête et de calcul. + Deux sous-réseaux, avec le nœud principal dans un sous-réseau public et des nœuds de calcul dans un sous-réseau privé. Les sous-réseaux peuvent être nouveaux ou existants. Toutes ces configurations peuvent fonctionner avec ou sans adressage IP public. AWS ParallelCluster peut également être déployé pour utiliser un proxy HTTP pour toutes les AWS requêtes. Les combinaisons de ces configurations se traduisent par de nombreux scénarios de déploiement. Par exemple, vous pouvez configurer un sous-réseau public unique avec tous les accès via Internet. Vous pouvez également configurer un réseau entièrement privé à l'aide AWS Direct Connect d'un proxy HTTP pour l'ensemble du trafic. À partir de la AWS ParallelCluster version 3.0.0`SecurityGroups`, `AdditionalSecurityGroups` il est possible de configurer différents `PlacementGroup` paramètres pour chaque file d'attente. Pour plus d'informations, consultez [`HeadNode`](HeadNode-v3.md)/[`Networking`](HeadNode-v3.md#HeadNode-v3-Networking)et [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)et [`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues-Networking). Pour des illustrations de certains scénarios de mise en réseau, reportez-vous aux diagrammes d'architecture suivants. **Topics** + [AWS ParallelCluster dans un seul sous-réseau public](network-configuration-v3-single-subnet.md) + [AWS ParallelCluster en utilisant deux sous-réseaux](network-configuration-v3-two-subnets.md) + [AWS ParallelCluster dans un seul sous-réseau privé connecté à l'aide de AWS Direct Connect](network-configuration-v3-single-subnet-direct-connect.md) + [AWS ParallelCluster avec AWS Batch planificateur](network-configuration-v3-batch.md) + [AWS ParallelCluster dans un seul sous-réseau sans accès à Internet](aws-parallelcluster-in-a-single-public-subnet-no-internet-v3.md) # AWS ParallelCluster dans un seul sous-réseau public Dans cette configuration, toutes les instances du cluster doivent se voir attribuer une adresse IP publique afin d'accéder à Internet. Pour ce faire, procédez comme suit : + Assurez-vous qu'une adresse IP publique est attribuée au nœud principal en activant le paramètre « Activer l'attribution automatique des IPv4 adresses publiques » pour le sous-réseau utilisé dans [`HeadNode`](HeadNode-v3.md)/[`Networking`](HeadNode-v3.md#HeadNode-v3-Networking)/[`SubnetId`](HeadNode-v3.md#yaml-HeadNode-Networking-SubnetId)ou en attribuant une adresse IP élastique dans [`HeadNode`](HeadNode-v3.md)//. [`Networking`[`ElasticIp`](HeadNode-v3.md#yaml-HeadNode-Networking-ElasticIp)](HeadNode-v3.md#HeadNode-v3-Networking) + Assurez-vous qu'une adresse IP publique est attribuée aux nœuds de calcul en activant le paramètre « Activer l'attribution automatique des IPv4 adresses publiques » pour le sous-réseau utilisé dans [`Scheduling`](Scheduling-v3.md)//[`SlurmQueues`[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds)ou en définissant [`AssignPublicIp`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-AssignPublicIp): true dans [`Scheduling`](Scheduling-v3.md)//[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues). [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) + Si vous définissez un type d'p4dinstance, ou un autre type d'instance doté de plusieurs interfaces réseau ou d'une carte d'interface réseau reliée au nœud principal, vous devez définir [`HeadNode`](HeadNode-v3.md)/[`Networking`](HeadNode-v3.md#HeadNode-v3-Networking)/sur [`ElasticIp`](HeadNode-v3.md#yaml-HeadNode-Networking-ElasticIp)`true`pour fournir un accès public. AWS public ne IPs peut être attribué qu'aux instances lancées avec une seule interface réseau. Dans ce cas, nous vous recommandons d'utiliser une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) pour fournir un accès public aux nœuds de calcul du cluster. Pour plus d'informations sur les adresses IP, consultez la section [Attribuer une IPv4 adresse publique lors du lancement de l'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) dans le *Guide de l'utilisateur Amazon EC2 pour les instances Linux.* + Vous ne pouvez pas définir un type d'hp6idinstance p4d ou un autre type d'instance doté de plusieurs interfaces réseau ou d'une carte d'interface réseau pour calculer des nœuds, car le AWS public ne IPs peut être attribué qu'aux instances lancées avec une seule interface réseau. Pour plus d'informations sur les adresses IP, consultez la section [Attribuer une IPv4 adresse publique lors du lancement de l'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) dans le *Guide de l'utilisateur Amazon EC2 pour les instances Linux.* Pour plus d'informations, consultez la section [Activation de l'accès à Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access) dans le *guide de l'utilisateur Amazon VPC*. ![\[ParallelCluster in a single public subnet\]](http://docs.aws.amazon.com/fr_fr/parallelcluster/latest/ug/images/single-public-subnet.png) La configuration de cette architecture nécessite les paramètres suivants : ``` # Note that all values are only provided as examples HeadNode: ... Networking: SubnetId: subnet-12345678 # subnet with internet gateway #ElasticIp: true | false | eip-12345678 Scheduling: Scheduler: slurm SlurmQueues: - ... Networking: SubnetIds: - subnet-12345678 # subnet with internet gateway #AssignPublicIp: true ``` # AWS ParallelCluster en utilisant deux sous-réseaux Dans cette configuration, seul le nœud principal du cluster doit disposer d'une adresse IP publique. Vous pouvez y parvenir en activant le paramètre « Activer l'attribution automatique des IPv4 adresses publiques » pour le sous-réseau utilisé dans [`HeadNode`](HeadNode-v3.md)/[`Networking`](HeadNode-v3.md#HeadNode-v3-Networking)/[`SubnetId`](HeadNode-v3.md#yaml-HeadNode-Networking-SubnetId)ou en attribuant une adresse IP élastique dans [`HeadNode`](HeadNode-v3.md)//. [`Networking`[`ElasticIp`](HeadNode-v3.md#yaml-HeadNode-Networking-ElasticIp)](HeadNode-v3.md#HeadNode-v3-Networking) Si vous définissez un type d'instance p4d ou un autre type d'instance doté de plusieurs interfaces réseau ou d'une carte d'interface réseau reliée au nœud principal, vous devez définir [`HeadNode`](HeadNode-v3.md)/[`Networking`](HeadNode-v3.md#HeadNode-v3-Networking)/sur [`ElasticIp`](HeadNode-v3.md#yaml-HeadNode-Networking-ElasticIp)`true`pour fournir un accès public. AWS public ne IPs peut être attribué qu'aux instances lancées avec une seule interface réseau. Pour plus d'informations sur les adresses IP, consultez la section [Attribuer une IPv4 adresse publique lors du lancement de l'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses) dans le *Guide de l'utilisateur Amazon EC2 pour les instances Linux.* Cette configuration nécessite une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) ou un proxy interne dans le sous-réseau utilisé pour les files d'attente, afin de donner accès à Internet aux instances de calcul. ![\[ParallelCluster using two subnets\]](http://docs.aws.amazon.com/fr_fr/parallelcluster/latest/ug/images/two-subnets.png) La configuration pour utiliser un sous-réseau privé existant pour les instances de calcul nécessite les paramètres suivants : ``` # Note that all values are only provided as examples HeadNode: ... Networking: SubnetId: subnet-12345678 # subnet with internet gateway #ElasticIp: true | false | eip-12345678 Scheduling: Scheduler: slurm SlurmQueues: - ... Networking: SubnetIds: - subnet-23456789 # subnet with NAT gateway #AssignPublicIp: false ``` # AWS ParallelCluster dans un seul sous-réseau privé connecté à l'aide de AWS Direct Connect Lorsque [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`AssignPublicIp`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-AssignPublicIp)est défini sur`false`, les sous-réseaux doivent être correctement configurés pour utiliser le proxy pour tout le trafic. L'accès au Web est requis pour les nœuds de tête et de calcul. ![\[ParallelCluster in a single private subnet connected using Direct Connect\]](http://docs.aws.amazon.com/fr_fr/parallelcluster/latest/ug/images/single-private-DirectConnect.png) La configuration de cette architecture nécessite les paramètres suivants : ``` # Note that all values are only provided as examples HeadNode: ... Networking: SubnetId: subnet-34567890 # subnet with proxy Proxy: HttpProxyAddress: http://proxy-address:port Ssh: KeyName: ec2-key-name Scheduling: Scheduler: slurm SlurmQueues: - ... Networking: SubnetIds: - subnet-34567890 # subnet with proxy AssignPublicIp: false Proxy: HttpProxyAddress: http://proxy-address:port ``` # AWS ParallelCluster avec AWS Batch planificateur Lorsque vous l'utilisez `awsbatch` comme type de planificateur, AWS ParallelCluster crée un environnement informatique AWS Batch géré. L' AWS Batch environnement gère les instances de conteneur Amazon Elastic Container Service (Amazon ECS). Ces instances sont lancées dans le sous-réseau configuré dans le [`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-Networking-SubnetIds)paramètre [`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues-Networking)/. AWS Batch Pour fonctionner correctement, les instances de conteneur Amazon ECS ont besoin d'un accès réseau externe pour communiquer avec le point de terminaison du service Amazon ECS. Cela se traduit par les scénarios suivants : + L'ID de sous-réseau spécifié pour la file d'attente utilise une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) pour accéder à Internet. Nous avons recommandé cette approche. + Les instances lancées dans le sous-réseau de file d'attente possèdent des adresses IP publiques et peuvent accéder à Internet via une passerelle Internet. De plus, si vous êtes intéressé par les tâches parallèles sur plusieurs nœuds (voir la [AWS Batch documentation](https://docs.aws.amazon.com/batch/latest/userguide/multi-node-parallel-jobs.html#mnp-ce)) : AWS Batch les tâches parallèles à nœuds multiples utilisent le mode `awsvpc` réseau Amazon ECS. Cela confère à vos conteneurs de tâches parallèles à nœuds multiples les mêmes propriétés réseau que les instances Amazon EC2. Chaque conteneur de tâche parallèle à plusieurs nœuds obtient sa propre interface réseau Elastic, une adresse IP privée principale et un nom d'hôte DNS interne. L'interface réseau est créée dans le même sous-réseau Amazon VPC que sa ressource de calcul hôte. Tous les groupes de sécurité appliqués à vos ressources de calcul lui sont également appliqués. Lorsque vous utilisez Amazon ECS Task Networking, le mode `awsvpc` réseau ne fournit pas d'interfaces réseau élastiques avec des adresses IP publiques pour les tâches utilisant le type de lancement Amazon EC2. Pour accéder à Internet, les tâches utilisant le type de lancement Amazon EC2 doivent être lancées dans un sous-réseau privé configuré pour utiliser une passerelle NAT. Vous devez configurer une [passerelle NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) afin de permettre au cluster d'exécuter des tâches parallèles sur plusieurs nœuds. ![\[ParallelCluster with a NAT Gateway\]](http://docs.aws.amazon.com/fr_fr/parallelcluster/latest/ug/images/two-subnets-batch.png) Toutes les configurations et considérations précédentes sont également valables pour AWS Batch. Voici un exemple de configuration AWS Batch réseau. ``` # Note that all values are only provided as examples HeadNode: ... Networking: SubnetId: subnet-12345678 # subnet with internet gateway, NAT gateway or proxy #ElasticIp: true | false | eip-12345678 #Proxy: #HttpProxyAddress: http://proxy-address:port Ssh: KeyName: ec2-key-name Scheduling: Scheduler: awsbatch AwsBatchQueues: - ... Networking: SubnetIds: - subnet-23456789 # subnet with internet gateway, NAT gateway or proxy #AssignPublicIp: true | false ``` Dans la [`Networking`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues-Networking)section [`Scheduling`](Scheduling-v3.md)/[`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)/, [`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-Networking-SubnetIds)il s'agit d'un type de liste mais, actuellement, un seul sous-réseau est pris en charge. Pour plus d’informations, consultez les rubriques suivantes : + [AWS Batch environnements informatiques gérés](https://docs.aws.amazon.com/batch/latest/userguide/compute_environments.html#managed_compute_environments) + [AWS Batch tâches parallèles sur plusieurs nœuds](https://docs.aws.amazon.com/batch/latest/userguide/multi-node-parallel-jobs.html) + [Mise en réseau des tâches Amazon ECS avec le mode réseau awsvpc](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html) # AWS ParallelCluster dans un seul sous-réseau sans accès à Internet Un sous-réseau sans accès à Internet n'autorise pas les connexions entrantes ou sortantes vers Internet. Cette AWS ParallelCluster configuration peut aider les clients concernés par la sécurité à renforcer davantage la sécurité de leurs AWS ParallelCluster ressources. AWS ParallelCluster les nœuds sont créés AWS ParallelCluster AMIs à partir de ceux-ci et incluent tous les logiciels nécessaires pour exécuter un cluster sans accès à Internet. De cette façon, AWS ParallelCluster vous pouvez créer et gérer des clusters avec des nœuds qui n'ont pas accès à Internet. Dans cette section, vous découvrirez comment configurer le cluster. Vous découvrirez également les limites liées à l'exécution de clusters sans accès à Internet. ![\[AWS ParallelCluster en utilisant un sous-réseau et sans Internet\]](http://docs.aws.amazon.com/fr_fr/parallelcluster/latest/ug/images/networking_single_subnet_no_internet.png) **Configuration des points de terminaison VPC** Pour garantir le bon fonctionnement du cluster, les nœuds du cluster doivent être en mesure d'interagir avec un certain nombre de AWS services. Créez et configurez les [points de terminaison VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html) suivants afin que les nœuds de cluster puissent interagir avec les AWS services, sans accès à Internet : ------ #### [ Commercial and AWS GovCloud (US) partitions ] | Service | Nom du service | Type | | --- | --- | --- | | Amazon CloudWatch | com.amazonaws. *region-id*.journaux | Interface | | CloudFormation | com.amazonaws. *region-id*.formation sur le cloud | Interface | | Amazon EC2 | com.amazonaws. *region-id*.ec2 | Interface | | Amazon S3 | com.amazonaws. *region-id*.s3 | Passerelle | | Amazon DynamoDB | com.amazonaws. *region-id*.dynamodb | Passerelle | | AWS Secrets Manager\$1\$1 | com.amazonaws. *region-id*.secretsmanager | Interface | | AWS Équilibrage de charge élastique\$1\$1\$1 | com.amazonaws. *region-id*. équilibrage de charge élastique | Interface | | AWS Mise à l'échelle automatique\$1\$1\$1 | com.amazonaws. *region-id*.mise à l'échelle automatique | Interface | ------ #### [ China partition ] | Service | Nom du service | Type | | --- | --- | --- | | Amazon CloudWatch | com.amazonaws. *region-id*.journaux | Interface | | CloudFormation | cn.com.amazonaws. *region-id*.formation sur le cloud | Interface | | Amazon EC2 | cn.com.amazonaws. *region-id*.ec2 | Interface | | Amazon S3 | com.amazonaws. *region-id*.s3 | Passerelle | | Amazon DynamoDB | com.amazonaws. *region-id*.dynamodb | Passerelle | | AWS Secrets Manager\$1\$1 | com.amazonaws. *region-id*.secretsmanager | Interface | | AWS Équilibrage de charge élastique\$1\$1\$1 | com.amazonaws. *region-id*. équilibrage de charge élastique | Interface | | AWS Mise à l'échelle automatique\$1\$1\$1 | cn.com.amazonaws. *region-id*.mise à l'échelle automatique | Interface | ------ \$1\$1 Ce point de terminaison n'est requis que lorsqu'il [`DirectoryService`](DirectoryService-v3.md#DirectoryService-v3.properties)est activé, sinon il est facultatif. \$1\$1\$1 Ces points de terminaison ne sont nécessaires que lorsqu'ils [LoginNodes](LoginNodes-v3.md)sont activés, sinon ils sont facultatifs. Toutes les instances du VPC doivent disposer de groupes de sécurité appropriés pour communiquer avec les points de terminaison. Vous pouvez le faire en ajoutant des groupes de sécurité [`AdditionalSecurityGroups`](HeadNode-v3.md#yaml-HeadNode-Networking-AdditionalSecurityGroups)sous [`HeadNode`](HeadNode-v3.md)et [`AdditionalSecurityGroups`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-AdditionalSecurityGroups)sous les [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)configurations. Par exemple, si les points de terminaison VPC sont créés sans spécifier explicitement de groupe de sécurité, le groupe de sécurité par défaut est associé aux points de terminaison. En ajoutant le groupe de sécurité par défaut à`AdditionalSecurityGroups`, vous activez la communication entre le cluster et les points de terminaison. **Note** Lorsque vous utilisez des politiques IAM pour restreindre l'accès aux points de terminaison VPC, vous devez ajouter les éléments suivants au point de terminaison VPC Amazon S3 : ``` PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: "*" Action: - "s3:PutObject" Resource: - !Sub "arn:${AWS::Partition}:s3:::cloudformation-waitcondition-${AWS::Region}/*" ``` **Désactivez Route 53 et utilisez les noms d'hôte Amazon EC2** Lors de la création d'un Slurm cluster, AWS ParallelCluster crée une zone hébergée Route 53 privée qui est utilisée pour résoudre les noms d'hôte des nœuds de calcul personnalisés, tels que`{queue_name}-{st|dy}-{compute_resource}-{N}`. Route 53 ne prenant pas en charge les points de terminaison VPC, cette fonctionnalité doit être désactivée. En outre, AWS ParallelCluster il doit être configuré pour utiliser les noms d'hôte Amazon EC2 par défaut, tels que. `ip-1-2-3-4` Appliquez les paramètres suivants à la configuration de votre cluster : ``` ... Scheduling: ... SlurmSettings: Dns: DisableManagedDns: true UseEc2Hostnames: true ``` **Avertissement** Pour les clusters créés avec [`SlurmSettings`[`Dns`](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns)](Scheduling-v3.md#Scheduling-v3-SlurmSettings)//[`DisableManagedDns`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns)et [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames)définis sur`true`, le DNS Slurm `NodeName` ne résout pas le problème. Utilisez Slurm `NodeHostName` plutôt le. **Note** **Cette note n'est pas pertinente à partir de AWS ParallelCluster la version 3.3.0.** Pour les versions AWS ParallelCluster prises en charge avant la version 3.3.0 : Lorsqu'il `UseEc2Hostnames` est défini sur`true`, le fichier Slurm de configuration est défini avec les `epilog` scripts AWS ParallelCluster `prolog` et : `prolog`s'exécute pour ajouter des informations `/etc/hosts` sur les nœuds aux nœuds de calcul lorsque chaque tâche est allouée. `epilog`s'exécute pour nettoyer le contenu écrit par`prolog`. Pour ajouter des `epilog` scripts personnalisés `prolog` ou personnalisés, ajoutez-les respectivement aux `/opt/slurm/etc/pcluster/epilog.d/` dossiers `/opt/slurm/etc/pcluster/prolog.d/` or. **Configuration du cluster** Découvrez comment configurer votre cluster pour qu'il s'exécute dans un sous-réseau sans connexion Internet. La configuration de cette architecture nécessite les paramètres suivants : ``` # Note that all values are only provided as examples ... HeadNode: ... Networking: SubnetId: subnet-1234567890abcdef0 # the VPC of the subnet needs to have VPC endpoints AdditionalSecurityGroups: - sg-abcdef01234567890 # optional, the security group that enables the communication between the cluster and the VPC endpoints LoginNodes: # optional, if enabled, requires creation and configuration of VPC endpoints for AWS Elastic Load Balancing (ELB) and Auto Scaling services Pools: - ... Networking: SubnetIds: - subnet-1234567890abcdef0 # the VPC of the subnet needs to have VPC endpoints attached AdditionalSecurityGroups: - sg-1abcdef01234567890 # optional, the security group that enables the communication between the cluster and the VPC endpoints Scheduling: Scheduler: Slurm # Cluster in a subnet without internet access is supported only when the scheduler is Slurm. SlurmSettings: Dns: DisableManagedDns: true UseEc2Hostnames: true SlurmQueues: - ... Networking: SubnetIds: - subnet-1234567890abcdef0 # the VPC of the subnet needs to have VPC endpoints attached AdditionalSecurityGroups: - sg-1abcdef01234567890 # optional, the security group that enables the communication between the cluster and the VPC endpoints ``` + [`SubnetId(s)`](HeadNode-v3.md#yaml-HeadNode-Networking-SubnetId): le sous-réseau sans accès à Internet. Pour permettre la communication entre AWS ParallelCluster et les AWS services, les points de terminaison du VPC doivent être attachés au VPC du sous-réseau. Avant de créer votre cluster, vérifiez que l'[attribution automatique de l' IPv4 adresse publique est désactivée](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) dans le sous-réseau pour garantir que les `pcluster` commandes ont accès au cluster. + [`AdditionalSecurityGroups`](HeadNode-v3.md#yaml-HeadNode-Networking-AdditionalSecurityGroups): le groupe de sécurité qui permet la communication entre le cluster et les points de terminaison VPC. Facultatif : + Si les points de terminaison du VPC sont créés sans spécifier explicitement de groupe de sécurité, le groupe de sécurité par défaut du VPC est associé. Par conséquent, indiquez le groupe de sécurité par défaut à`AdditionalSecurityGroups`. + Si des groupes de sécurité personnalisés sont utilisés lors de la création du cluster, and/or les points de terminaison VPC ne `AdditionalSecurityGroups` sont pas nécessaires tant que les groupes de sécurité personnalisés permettent la communication entre le cluster et les points de terminaison VPC. + [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler): Le planificateur de clusters. `slurm`est la seule valeur valide. Seul le Slurm planificateur prend en charge un cluster dans un sous-réseau sans accès à Internet. + [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings): Les Slurm paramètres. Consultez la section précédente *Désactiver Route53 et utiliser les noms d'hôte Amazon EC2*. **Limites** + *Connexion au nœud principal via SSH ou Amazon DCV :* lors de la connexion à un cluster, assurez-vous que le client de la connexion peut atteindre le nœud principal du cluster via son adresse IP privée. Si le client ne se trouve pas dans le même VPC que le nœud principal, utilisez une instance de proxy dans un sous-réseau public du VPC. Cette exigence s'applique à la fois aux connexions SSH et DCV. L'adresse IP publique d'un nœud principal n'est pas accessible si le sous-réseau n'a pas accès à Internet. Les `dcv-connect` commandes `pcluster ssh` et utilisent l'adresse IP publique si elle existe ou l'adresse IP privée. Avant de créer votre cluster, vérifiez que l'[attribution automatique de l' IPv4 adresse publique est désactivée](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) dans le sous-réseau pour garantir que les `pcluster` commandes ont accès au cluster. L'exemple suivant montre comment vous connecter à une session DCV exécutée dans le nœud principal de votre cluster. Vous vous connectez via une instance proxy Amazon EC2. L'instance fonctionne en tant que serveur Amazon DCV pour votre PC et en tant que client pour le nœud principal du sous-réseau privé. Connectez-vous via DCV via une instance de proxy dans un sous-réseau public : 1. Créez une instance Amazon EC2 dans un sous-réseau public, qui se trouve dans le même VPC que le sous-réseau du cluster. 1. Assurez-vous que le client et le serveur Amazon DCV sont installés sur votre instance Amazon EC2. 1. Attachez une politique AWS ParallelCluster utilisateur à l'instance proxy Amazon EC2. Pour de plus amples informations, veuillez consulter [AWS ParallelCluster exemples de politiques `pcluster` utilisateur](iam-roles-in-parallelcluster-v3.md#iam-roles-in-parallelcluster-v3-example-user-policies). 1. Installez AWS ParallelCluster sur l'instance proxy Amazon EC2. 1. Connect via DCV à l'instance proxy Amazon EC2. 1. Utilisez la `pcluster dcv-connect` commande sur l'instance de proxy pour vous connecter au cluster à l'intérieur du sous-réseau sans accès à Internet. + *Interaction avec d'autres AWS services :* seuls les services strictement requis par AWS ParallelCluster sont répertoriés ci-dessus. Si votre cluster doit interagir avec d'autres services, créez les points de terminaison VPC correspondants.