Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Configuraciones de red
AWS ParallelCluster utiliza Amazon Virtual Private Cloud (VPC) para las redes. VPC proporciona una plataforma de red flexible y configurable en la que puede implementar clústeres.
La VPC debe tener DNS Resolution = yes, DNS Hostnames = yes y opciones de DHCP con el nombre de dominio correcto para la región. El conjunto de opciones de DHCP predeterminado ya especifica los AmazonProvidedDNS necesarios. Si especifica más de un servidor de nombres de dominio, consulte Conjuntos de opciones de DHCP en la Guía del usuario de Amazon VPC.
AWS ParallelCluster admite las siguientes configuraciones de carácter general:
-
Una subred para los nodos principal y de computación.
-
Dos subredes: el nodo principal en una subred pública, y los nodos de computación en una subred privada. Las subredes pueden ser nuevas o existentes.
Todas estas configuraciones pueden funcionar con o sin direcciones IP públicas. AWS ParallelCluster también se puede implementar para usar un proxy HTTP para todas las solicitudes de AWS. La combinaciones de estas configuraciones se traducen en muchos casos de implementación. Por ejemplo, puede configurar una única subred pública con todos los accesos a través de Internet. O bien, puede configurar una red totalmente privada mediante AWS Direct Connect y un proxy HTTP para todo el tráfico.
A partir de AWS ParallelCluster versión 3.0.0, es posible configurar distintos ajustes SecurityGroups, AdditionalSecurityGroups y PlacementGroup para cada cola. Para obtener más información, consulte HeadNode/Networking y SlurmQueues/Networking y AwsBatchQueues/Networking.
Consulte los siguientes diagramas de arquitectura para ver ilustraciones de algunos de estos escenarios de redes.
Temas
AWS ParallelCluster en una subred pública única
La configuración de esta arquitectura requiere los siguientes valores de configuración:
# 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
En esta configuración, a todas las instancias del clúster se les debe asignar una IP pública para poder acceder a Internet. Para ello, haga lo siguiente:
-
Asegúrese de que al nodo principal se le asigne una dirección IP pública activando la configuración “Habilitar la asignación automática de direcciones IPv4 públicas” para la subred utilizada en HeadNode/Networking/SubnetId o asignando una IP elástica en HeadNode/Networking/ElasticIp.
-
Asegúrese de que a los nodos de computación se les asigne una dirección IP pública activando la configuración “Habilitar la asignación automática de direcciones IPv4 públicas” para la subred utilizada en Scheduling/SlurmQueues/Networking/SubnetIds o estableciendo AssignPublicIp: verdadero en Scheduling/SlurmQueues/Networking.
-
Si define un tipo de instancia p4d u otro tipo de instancia que tenga varias interfaces de red o una tarjeta de interfaz de red para el nodo principal, debe configurar HeadNode/Networking/ElasticIp en
truepara proporcionar acceso público. Las IP públicas de AWS solo se pueden asignar a instancias lanzadas con una única interfaz de red. En este caso, le recomendamos que utilice una puerta de enlace NAT para proporcionar acceso público a los nodos de computación del clúster. Para obtener más información sobre las direcciones IP, consulte Asignación de una dirección IPv4 pública durante el lanzamiento de una instancia en la Guía del usuario de Amazon EC2 para instancias de Linux. -
No puede definir un tipo de instancia p4d o hp6id, ni otro tipo de instancia que tenga varias interfaces de red o una tarjeta de interfaz de red para los nodos de computación, porque las IP públicas de AWS solo se pueden asignar a instancias lanzadas con una única interfaz de red. Para obtener más información sobre las direcciones IP, consulte Asignación de una dirección IPv4 pública durante el lanzamiento de una instancia en la Guía del usuario de Amazon EC2 para instancias de Linux.
Para obtener más información, consulte Habilitar acceso a Internet en la Guía del usuario de Amazon VPC.
AWS ParallelCluster con dos subredes
La configuración para usar una subred privada existente para instancias de computación requiere los siguientes valores de configuración:
# 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
En esta configuración, solo se requiere que el nodo principal del clúster tenga asignada una IP pública. Puede hacerlo activando la configuración “Habilitar la asignación automática de direcciones IPv4 públicas” para la subred utilizada en HeadNode/Networking/SubnetId o asignando una IP elástica en HeadNode/Networking/ElasticIp.
Si define un tipo de instancia p4d u otro tipo de instancia que tenga varias interfaces de red o una tarjeta de interfaz de red para el nodo principal, debe configurar HeadNode/Networking/ElasticIp en true para proporcionar acceso público. Las IP públicas de AWS solo se pueden asignar a instancias lanzadas con una única interfaz de red. Para obtener más información sobre las direcciones IP, consulte Asignación de una dirección IPv4 pública durante el lanzamiento de una instancia en la Guía del usuario de Amazon EC2 para instancias de Linux.
Esta configuración requiere una puerta de enlace NAT o un proxy interno en la subred utilizada para las colas, a fin de dar acceso a Internet a las instancias de computación.
AWS ParallelCluster en una única subred privada conectada mediante AWS Direct Connect
La configuración de esta arquitectura requiere los siguientes valores de configuración:
# 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
Cuando se establece Scheduling/SlurmQueues/Networking/AssignPublicIp en false, las subredes deben configurarse correctamente para utilizar el proxy para todo el tráfico. Se requiere acceso a Internet tanto para los nodos principales como para los de computación.
AWS ParallelCluster con el programador AWS Batch
Al usar awsbatch como tipo de programador, AWS ParallelCluster crea un entorno informático administrado de AWS Batch. El entorno AWS Batch gestiona instancias de contenedores de Amazon Elastic Container Service (Amazon ECS). Estas instancias se lanzan en la subred configurada en el parámetro AwsBatchQueues/Networking/SubnetIds. Para que AWS Batch funcione correctamente, las instancias de contenedor de Amazon ECS necesitan acceso de red externo para comunicarse con el punto de conexión de servicio de Amazon ECS. Esto se traduce en los siguientes casos:
-
El ID de subred especificado para la cola utiliza una puerta de enlace NAT para acceder a Internet. Recomendamos este enfoque.
-
Las instancias que se lanzan en la subred de la cola tienen direcciones IP públicas y pueden llegar a Internet a través de una puerta de enlace de Internet.
Además, si le interesan los trabajos paralelos de varios nodos (de los documentos de AWS Batch):
Los trabajos paralelos de varios nodos de AWS Batch utilizan el modo de red awsvpc de Amazon ECS. Esto proporciona a los contenedores de trabajos paralelos de varios nodos las mismas propiedades de redes que poseen las instancias de Amazon EC2. Cada contenedor de trabajos paralelos de varios nodos obtiene su propia interfaz de red elástica, una dirección IP privada principal y un nombre de host DNS interno. La interfaz de red se crea en la misma subred de Amazon VPC como su recurso de computación de host. Los grupos de seguridad que se hayan aplicado a los recursos informáticos se aplicarán también a ella.
Cuando usa la integración de redes de tareas de Amazon ECS, el modo de red awsvpc no proporciona interfaces de red elásticas con direcciones IP públicas para tareas que utilizan el tipo de lanzamiento de Amazon EC2. Para obtener acceso a Internet, las tareas que utilizan el tipo de lanzamiento Amazon EC2 se deben lanzar en una subred privada configurada para utilizar una puerta de enlace NAT.
Debe configurar una puerta de enlace NAT para permitir que el clúster ejecute trabajos paralelos de varios nodos.
Todas las configuraciones y consideraciones anteriores también son válidas para AWS Batch. A continuación, se muestra un ejemplo de archivo de configuración de redes de AWS Batch.
# 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
En la sección Scheduling/AwsBatchQueues/Networking, SubnetIds es un tipo de lista, pero actualmente solo se admite una subred.
Para obtener más información, consulte los siguientes temas:
AWS ParallelCluster en una subred individual sin acceso a Internet
Una subred sin acceso a Internet no permite conexiones entrantes ni salientes a Internet. Esta configuración de AWS ParallelCluster puede ayudar a los clientes preocupados por la seguridad a mejorar aún más la seguridad de sus recursos de AWS ParallelCluster. Los nodos de AWS ParallelCluster se crean a partir de AMI de AWS ParallelCluster que incluyen todo el software necesario para ejecutar un clúster sin acceso a Internet. De esta forma, AWS ParallelCluster puede crear y administrar clústeres con nodos que no tienen acceso a Internet.
En esta sección, aprenderá a configurar el clúster. También obtendrá información sobre las limitaciones de la ejecución de clústeres sin acceso a Internet.
Configuración de puntos de conexión de VPC
Para garantizar el correcto funcionamiento del clúster, los nodos del clúster deben poder interactuar con varios servicios de AWS.
Cree y configure los siguientes puntos de conexión de VPC para que los nodos del clúster puedan interactuar con los servicios de AWS sin acceso a Internet:
** Este punto de conexión solo es obligatorio cuando está activado DirectoryService; de lo contrario, es opcional.
Todas las instancias de la VPC deben tener los grupos de seguridad adecuados para comunicarse con los puntos de conexión. Para ello, agregue grupos de seguridad a AdditionalSecurityGroups en el HeadNode y los AdditionalSecurityGroups y en las configuraciones de las SlurmQueues. Por ejemplo, si los puntos de conexión de VPC se crean sin especificar un grupo de seguridad de forma explícita, el grupo de seguridad predeterminado se asociará a los puntos de conexión. Al agregar el grupo de seguridad predeterminado a AdditionalSecurityGroups, se habilita la comunicación entre el clúster y los puntos de conexión.
nota
Cuando utilice políticas de IAM para restringir el acceso a los puntos de conexión de VPC, debe añadir lo siguiente al punto de conexión de VPC de Amazon S3:
PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: "*" Action: - "s3:PutObject" Resource: - !Sub "arn:${AWS::Partition}:s3:::cloudformation-waitcondition-${AWS::Region}/*"
Deshabilitar Route 53 y utilizar nombres de host de EC2
Al crear un clúster de Slurm, AWS ParallelCluster crea una zona alojada privada de Route 53 que se utiliza para resolver los nombres de host de los nodos de computación personalizados, por ejemplo {queue_name}-{st|dy}-{compute_resource}-{N}. Como Route 53 no admite puntos de conexión de VPC, esta característica debe estar deshabilitada. Además, AWS ParallelCluster debe configurarse para usar los nombres de host de EC2 predeterminados, como ip-1-2-3-4. Aplique los siguientes ajustes a la configuración del clúster:
... Scheduling: ... SlurmSettings: Dns: DisableManagedDns: true UseEc2Hostnames: true
aviso
En el caso de los clústeres creados con los ajustes SlurmSettings/Dns/DisableManagedDns y UseEc2Hostnames establecidos en true, el DNS no resuelve el NodeName de Slurm. En su lugar, use el NodeHostName de Slurm.
nota
Esta nota no es pertinente a partir de AWS ParallelCluster versión 3.3.0.
Para las versiones de AWS ParallelCluster compatibles anteriores a 3.3.0:
Cuando UseEc2Hostnames se establece en true, el archivo de configuración de Slurm se configura con los scripts AWS ParallelCluster, prolog y epilog:
-
prologse ejecuta para añadir información de los nodos a/etc/hostssobre los nodos de computación cuando se asigna cada trabajo. -
epilogse ejecuta para limpiar el contenido escrito porprolog.
Para añadir los scripts prolog o epilog personalizados, agréguelos a las carpetas /opt/slurm/etc/pcluster/prolog.d/ o /opt/slurm/etc/pcluster/epilog.d/, respectivamente.
Configuración del clúster
Aprenda a configurar el clúster para que se ejecute en una subred sin conexión a Internet.
La configuración de esta arquitectura requiere los siguientes valores de configuración:
# 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 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): la subred sin acceso a Internet.
Para habilitar la comunicación entre los servicios AWS ParallelCluster y AWS, la VPC de la subred debe tener los puntos de conexión de VPC asociados. Antes de crear el clúster, compruebe que la asignación automática de direcciones IPv4 públicas esté deshabilitada en la subred para garantizar que los comandos de
pclustertengan acceso al clúster. -
AdditionalSecurityGroups: el grupo de seguridad que habilita la comunicación entre el clúster y los puntos de conexión de VPC.
Opcional:
-
Si los puntos de conexión de VPC se crean sin especificar un grupo de seguridad de forma explícita, se asociará el grupo de seguridad predeterminado de la VPC. Por lo tanto, proporcione el grupo de seguridad predeterminado a
AdditionalSecurityGroups. -
Si se utilizan grupos de seguridad personalizados al crear el clúster o los puntos de conexión de VPC, no se necesita
AdditionalSecurityGroups, siempre que los grupos de seguridad personalizados permitan la comunicación entre el clúster y los puntos de conexión de VPC.
-
-
Scheduler: el programador de clústeres.
slurmes el único valor válido. Solo el programador Slurm admite un clúster en una subred sin acceso a Internet. -
SlurmSettings: la configuración de Slurm.
Consulte la sección anterior Deshabilitar Route 53 y utilizar los nombres de host de EC2.
Limitaciones
-
Conexión al nodo principal a través de SSH o NICE DCV: al conectarse a un clúster, asegúrese de que el cliente de la conexión pueda llegar al nodo principal del clúster a través de su dirección IP privada. Si el cliente no está en la misma VPC que el nodo principal, use una instancia de proxy en una subred pública de la VPC. Este requisito se aplica a las conexiones SSH y DCV. No se puede acceder a la IP pública de un nodo principal si la subred no tiene acceso a Internet. Los comandos
pcluster sshydcv-connectutilizan la IP pública, si existe, o la IP privada. Antes de crear el clúster, compruebe que la asignación automática de direcciones IPv4 públicas esté deshabilitada en la subred para garantizar que los comandos depclustertengan acceso al clúster.El siguiente ejemplo muestra cómo puede conectarse a una sesión de DCV que se ejecute en el nodo principal del clúster. La conexión se realiza a través de una instancia de EC2 del proxy. La instancia funciona como un servidor NICE DCV para su PC y como cliente para el nodo principal de la subred privada.
Conéctese a través de DCV a través de una instancia proxy en una subred pública:
-
Cree una instancia de EC2 en una subred pública, que esté en la misma VPC que la subred del clúster.
-
Asegúrese de que el cliente y el servidor NICE DCV estén instalados en la instancia de EC2.
-
Asocie una política de usuario de AWS ParallelCluster a la instancia de EC2 del proxy. Para obtener más información, consulte AWS ParallelCluster ejemplos pcluster de políticas de usuario.
-
Instale AWS ParallelCluster en la instancia de EC2 del proxy.
-
Conéctese a través de DCV a la instancia de EC2 del proxy.
-
Utilice el comando
pcluster dcv-connectde la instancia del proxy para conectarse al clúster dentro de la subred sin acceso a Internet.
-
-
Interacción con otros servicios de AWS: arriba solo figuran los servicios estrictamente necesarios para AWS ParallelCluster. Si el clúster debe interactuar con otros servicios, cree los puntos de conexión de VPC correspondientes.
