View a markdown version of this page

Create compute node group for login nodes in AWS PCS - AWS PCS

Create compute node group for login nodes in AWS PCS

A compute node group is virtual collection of compute nodes (EC2 instances) that AWS PCS launches and manages. When you define a compute node group, you specify common traits such as EC2 instance types, minimum and maximum instance count, target VPC subnets, preferred purchase option, and custom launch configuration. AWS PCS efficiently launches, manages, and terminates compute nodes in a compute node group, according to these settings.

In this step, you will launch a static compute node group that provides interactive access to the cluster. You can use SSH or Amazon EC2 Systems Manager (SSM) to log in to it, then run shell commands and manage Slurm jobs.

To create the compute node group

  • Open the AWS PCS console and navigate to Clusters.

  • Select the cluster named get-started

  • Navigate to Compute node groups and choose Create.

  • In the Compute node group setup section, provide the following:

    • Compute node group name – Enter login.

  • Under Computing configuration, enter or select these values:

    • EC2 launch template – Choose the launch template where the name is login-getstarted-lt

    • IAM instance profile – Choose the instance profile named AWSPCS-getstarted-role

    • Subnets – Select the subnet where the name starts with hpc-networking:PublicSubnetA. Login nodes run in a public subnet so that you can reach them to log in and submit work.

    • Instances – Select c6i.xlarge.

    • Scaling configuration – For Min. instance count, enter 1. For Max. instance count, enter 1. Fixing both counts at 1 keeps a single login node running at all times as a stable entry point to the cluster.

  • Under Additional settings, specify the following:

    • AMI ID – Select an AMI you want to use, that has a name in the following format:

      aws-pcs-sample_ami-al2023-platform-slurm-version
      Note

      Sample AMIs for Slurm 25.05 and previous versions use Amazon Linux 2 (amzn2) instead of Amazon Linux 2023 (al2023).

      For more information about the sample AMIs, see Using sample Amazon Machine Images (AMIs) with AWS PCS.

  • In the Node lifecycle actions section, add scripts that mount shared storage and forward node logs. Choose Add script for each of the following actions. Scripts run from top to bottom within a stage, so add them in the order shown. For more information about the scripts that AWS maintains, see AWS-maintained scripts.

    1. configure-cloudwatch-logs – Forwards each node's lifecycle action logs to Amazon CloudWatch Logs. Configure it first so the actions that follow have their output captured from the node's first boot.

      • Lifecycle stage – Select nodeBootstrapped.

      • Script location – Enter s3://aws-pcs-repo-region/aws-pcs-node-lifecycle-scripts/configure-cloudwatch-logs-v1-latest.sh, replacing region with your cluster's AWS Region.

      • Name – Enter configure-cloudwatch-logs.

      • Arguments – Leave this field empty. The script automatically sends logs to the /aws/pcs/cluster-id/lifecycle log group.

      • Error handling behavior – Select CONTINUE.

      • Execution policy – Select FIRST_BOOT_ONLY.

    2. configure-efs-homes – Mounts the Amazon EFS file system as the home-directory base at /home and configures the node to create each user's home directory on first login.

      • Lifecycle stage – Select nodeBootstrapped.

      • Script location – Enter s3://aws-pcs-repo-region/aws-pcs-node-lifecycle-scripts/configure-efs-homes-v1-latest.sh, replacing region with your cluster's AWS Region.

      • Name – Enter configure-efs-homes.

      • Arguments – Enter --efs-id efs-file-system-id --home-base /home --options tls, replacing efs-file-system-id with the ID of the EFS file system you created earlier in the tutorial.

      • Error handling behavior – Select CONTINUE.

      • Execution policy – Select EVERY_BOOT.

    3. mount-fsx-lustre – Mounts the FSx for Lustre file system at /shared for high-performance shared scratch storage.

      • Lifecycle stage – Select nodeBootstrapped.

      • Script location – Enter s3://aws-pcs-repo-region/aws-pcs-node-lifecycle-scripts/mount-fsx-lustre-v1-latest.sh, replacing region with your cluster's AWS Region (for example, us-east-1).

      • Name – Enter mount-fsx-lustre.

      • Arguments – Enter --fsx-dns-name fsx-dns-name --mount-name mount-name --mount-point /shared, replacing fsx-dns-name with the DNS name and mount-name with the Mount name that you noted when you created the FSx for Lustre file system.

      • Error handling behavior – Select CONTINUE.

      • Execution policy – Select EVERY_BOOT.

    4. set-shared-dir-mode – Sets /shared to world-writable, sticky permissions (mode 1777) so that any user can create files in it. It runs after mount-fsx-lustre so that it applies to the mounted file system.

      • Lifecycle stage – Select nodeBootstrapped.

      • Script location – Enter https://aws-hpc-recipes.s3.us-east-1.amazonaws.com/main/recipes/pcs-scripts/open_shared_dir/assets/set-shared-dir-mode-v1.0.0.sh. This community script is published by HPC Recipes for AWS.

      • Name – Enter set-shared-dir-mode.

      • Arguments – Enter --path /shared --mode 1777.

      • Error handling behavior – Select CONTINUE.

      • Execution policy – Select EVERY_BOOT.

  • Choose Create compute node group.

The Status field shows Creating while the compute node group is being provisioned. You can proceed to the next step in the tutorial while it is in progress.