모범 사례 - AWS ParallelCluster
모범 사례: 헤드 노드 인스턴스 유형 선택모범 사례: 네트워크 성능모범 사례: 예산 알림모범 사례: 클러스터를 새 AWS ParallelCluster 마이너 또는 패치 버전으로 이동

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

모범 사례

다음 섹션에서는 네트워크 성능 및 예산 알림 AWS ParallelCluster이 포함된 사용 모범 사례를 제공합니다.

모범 사례: 헤드 노드 인스턴스 유형 선택

헤드 노드가 작업을 실행하지는 않지만 헤드 노드의 기능과 크기 조정은 클러스터의 전체 성능에 매우 중요합니다. 헤드 노드에 사용할 인스턴스 유형을 선택할 때는 다음 특성을 고려하세요.

클러스터 크기: 헤드 노드는 클러스터의 규모 조정 로직을 관리하고 새 노드를 스케줄러에 연결하는 역할을 합니다. 노드 수가 많은 클러스터를 스케일 업하거나 스케일 다운하려면 헤드 노드에 추가 컴퓨팅 파워를 제공하세요.

공유 파일 시스템: 공유 파일 시스템을 사용하는 경우 워크플로를 처리하기에 충분한 네트워크 대역폭과 충분한 Amazon EBS 대역폭을 가진 인스턴스 유형을 선택합니다. 헤드 노드가 클러스터에 충분한 NFS 서버 디렉터리를 노출하고 컴퓨팅 노드와 헤드 노드 간에 공유해야 하는 아티팩트를 처리할 수 있는지 확인합니다.

모범 사례: 네트워크 성능

네트워크 성능은 고성능 컴퓨팅(HPC) 애플리케이션에 매우 중요합니다. 신뢰성 있는 네트워크 성능이 없으면 이러한 애플리케이션이 예상대로 작동할 수 없습니다. 네트워크 성능을 최적화하려면 다음 모범 사례를 고려하세요.

  • 배치 그룹: 를 사용하는 경우 Slurm, 각 구성 고려 Slurm 클러스터 배치 그룹 를 사용하는 대기열입니다. 클러스터의 배치 그룹은 단일 가용 영역 내에 있는 인스턴스의 논리적 그룹입니다. 자세한 내용은 Amazon EC2 사용 설명서의 배치 그룹을 참조하세요. 대기열의 Networking 섹션에서 PlacementGroup을 지정할 수 있습니다. 각 컴퓨팅 리소스는 대기열의 배치 그룹에 할당됩니다. 컴퓨팅 리소스의 Networking 섹션에서 PlacementGroup를 지정하면 해당 특정 컴퓨팅 리소스가 해당 배치 그룹에 할당됩니다. 컴퓨팅 리소스 배치 그룹 사양은 컴퓨팅 리소스의 대기열 사양보다 우선합니다. 자세한 내용은 SlurmQueues/Networking/PlacementGroup 및 SlurmQueues/ComputeResources/Networking/PlacementGroup 섹션을 참조하세요.

    Networking:
  PlacementGroup:
    Enabled: true
    Id: your-placement-group-name

    또는 배치 그룹을 AWS ParallelCluster 생성하세요.

    Networking:
  PlacementGroup:
    Enabled: true

    AWS ParallelCluster 버전 3.3.0부터 배치 그룹 생성 및 관리가 수정됩니다. 대기열에 name 또는 Id 없이 배치 그룹을 활성화하도록 지정하면 대기열 전체에 대해 하나의 관리형 그룹이 할당되는 대신 각 컴퓨팅 리소스에 고유한 관리형 배치 그룹이 할당됩니다. 이렇게 하면 용량 부족 오류를 줄이는 데 도움이 됩니다. 전체 대기열에 하나의 배치 그룹이 필요한 경우 이름이 지정된 배치 그룹을 사용할 수 있습니다.

    SlurmQueues/Networking/PlacementGroup/Name이 SlurmQueues/Networking/PlacementGroup/Id의 기본 대안으로 추가되었습니다.

    자세한 내용은 Networking 단원을 참조하십시오.

  • 향상된 네트워킹: 향상된 네트워킹을 지원하는 인스턴스 유형을 선택하는 것이 좋습니다. 이 권장 사항은 모든 현재 세대 인스턴스에 적용됩니다. 자세한 내용은 Amazon EC2 사용 설명서의 Linux에서 향상된 네트워킹을 참조하세요.

  • 탄력적 패브릭 어댑터: 인스턴스 간 통신에서 확장 가능한 인스턴스를 높은 수준으로 지원하려면 EFA 네트워크에 대한 네트워크 인터페이스를 선택하는 것이 좋습니다. EFA의 사용자 지정 운영 체제(OS) 바이패스 하드웨어는 의 온디맨드 탄력성과 유연성을 통해 인스턴스 간 통신을 개선합니다 AWS 클라우드. 각 를 구성할 수 있습니다.Slurm ComputeResource 를 사용할 대기열입니다Efa. EFA 와 함께 를 사용하는 방법에 대한 자세한 내용은 섹션을 AWS ParallelCluster참조하세요Elastic Fabric Adapter.

    ComputeResources:
  - Name: your-compute-resource-name
    Efa:
      Enabled: true

    에 대한 자세한 내용은 Linux 인스턴스용 Amazon 사용 설명서의 탄력적 패브릭 어댑터를 EFA참조하세요. EC2

  • 인스턴스 대역폭: 대역폭은 인스턴스 크기에 따라 조정됩니다. 다양한 인스턴스 유형에 대한 자세한 내용은 Amazon 사용 설명서의 Amazon EBS최적화 인스턴스 및 Amazon EBS 볼륨 유형을 참조하세요. EC2

모범 사례: 예산 알림

에서 리소스 비용을 관리하려면 AWS Budgets 작업을 사용하여 예산을 생성하는 것이 AWS ParallelCluster좋습니다. 선택한 AWS 리소스에 대해 정의된 예산 임계값 알림을 생성할 수도 있습니다. 자세한 내용은AWS Budgets 사용 설명서의 예산 작업 구성을 참조하세요. 마찬가지로 Amazon CloudWatch 을 사용하여 결제 경보를 생성할 수도 있습니다. 자세한 내용은 예상 AWS 요금을 모니터링하기 위한 결제 경보 생성을 참조하세요.

모범 사례: 클러스터를 새 AWS ParallelCluster 마이너 또는 패치 버전으로 이동

현재 각 AWS ParallelCluster 마이너 버전은 pcluster 와 함께 자체 포함되어 있습니다CLI. 클러스터를 새 마이너 또는 패치 버전으로 이동하려면 새 버전의 를 사용하여 클러스터를 다시 생성해야 합니다CLI.

클러스터를 새 마이너 또는 패치 버전으로 이동하는 프로세스를 최적화하려면 다음을 수행하는 것이 좋습니다.

  • Amazon EFS 및 FSx for Lustre와 같이 클러스터 외부에서 생성된 외부 볼륨에 개인 데이터를 저장합니다. 이렇게 하면 나중에 한 클러스터에서 다른 클러스터로 데이터를 쉽게 이동할 수 있습니다.

  • 다음 유형을 사용하여 공유 스토리지 시스템을 생성합니다. AWS CLI 또는 를 사용하여 이러한 시스템을 생성할 수 있습니다 AWS Management Console.

    클러스터 구성의 파일 시스템 또는 볼륨을 기존 파일 시스템 또는 볼륨으로 정의합니다. 이렇게 하면 클러스터를 삭제해도 파일이 보존되고 새 클러스터에 연결할 수 있습니다.

    Amazon EFS 또는 FSx for Lustre 파일 시스템을 사용하는 것이 좋습니다. 두 시스템 모두 동시에 여러 클러스터에 연결할 수 있습니다. 또한 기존 클러스터를 삭제하기 전에 두 시스템 중 하나를 새 클러스터에 연결할 수 있습니다.

  • 사용자 지정 부트스트랩 작업을 사용하여 사용자 지정 를 사용하는 대신 인스턴스를 사용자 지정합니다AMI. 대신 사용자 지정 를 사용하는 경우 새 버전 릴리스AMI마다 해당 를 삭제하고 다시 생성AMI해야 합니다.

  • 다음 순서대로 이전 권장 사항을 적용하는 것이 좋습니다.

    1. 기존 파일 시스템 정의를 사용하도록 기존 클러스터 구성을 업데이트하세요.

    2. pcluster 버전을 확인하고 필요한 경우 업데이트하세요.

    3. 새 클러스터를 만들고 테스트합니다. 새 클러스터를 테스트할 때는 다음을 확인하세요.

      • 새 클러스터에서 데이터를 사용할 수 있는지 확인합니다.

      • 애플리케이션이 새 클러스터에서 작동하는지 확인합니다.

    4. 새 클러스터를 완전히 테스트하고 운영하여 기존 클러스터가 더 이상 필요하지 않은 후에는 삭제하세요.