모범 사례

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

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

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

공유 파일 시스템: 공유 파일 시스템을 사용할 때는 워크플로를 처리하기에 충분한 네트워크 대역폭과 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에서의 향상된 네트워킹을 참조하십시오.

• Elastic Fabric Adapter: 높은 수준의 규모 조정 가능한 인스턴스 간 통신을 지원하려면 네트워크에 맞는 EFA 네트워크 인터페이스를 선택하는 것이 좋습니다. EFA의 맞춤형 운영 체제(OS) 바이패스 하드웨어는 AWS 클라우드의 온디맨드 탄력성과 유연성을 통해 인스턴스 간 통신을 향상합니다. 각 Slurm 대기열 ComputeResource이 Efa를 사용하도록 구성할 수 있습니다. EFA를 사용하는 방법에 대한 자세한 내용은 을 AWS ParallelCluster참조하십시오. Elastic Fabric Adapter

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

  EFA에 대한 자세한 정보는 Linux 인스턴스용 Amazon EC2 사용자 설명서의 Elastic Fabric Adapter를 참조하세요.

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

모범 사례: 예산 알림

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

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

현재 각 AWS ParallelCluster 마이너 버전은 CLI와 함께 독립적입니다. pcluster 클러스터를 새 마이너 또는 패치 버전으로 옮기려면 새 버전의 CLI를 사용하여 클러스터를 다시 생성해야 합니다.

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

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

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

  • SharedStorage / EbsSettings / VolumeId

  • SharedStorage / EfsSettings / FileSystemId

  • SharedStorage / FsxLustreSettings / FileSystemId

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

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

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

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

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

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

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

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

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

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