AWS ParallelCluster 문제 해결 - AWS ParallelCluster
로그 검색 및 보존스택 배포 문제 해결다중 대기열 모드 클러스터의 문제 해결단일 대기열 모드 클러스터의 문제 해결배치 그룹 및 인스턴스 시작 문제교체할 수 없는 디렉터리Amazon의 문제 해결 DCVAWS Batch 통합을 통한 클러스터의 문제 해결리소스 생성 실패 시 문제 해결IAM 정책 크기 문제 해결추가 지원

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

AWS ParallelCluster 문제 해결

AWS ParallelCluster 커뮤니티는 Wiki 에 대한 많은 문제 해결 팁을 제공하는 AWS ParallelCluster GitHub Wiki 페이지를 유지합니다. 알려진 문제 목록을 알아보려면 알려진 문제를 참조하세요.

로그 검색 및 보존

로그는 문제를 해결하는 데 유용한 리소스입니다. 로그를 사용하여 AWS ParallelCluster 리소스 문제를 해결하려면 먼저 클러스터 로그 아카이브를 만들어야 합니다. AWS ParallelCluster GitHub Wiki의 클러스터 로그 아카이브 생성 주제에 설명된 단계에 따라 이 프로세스를 시작합니다.

실행 중인 클러스터 중 하나에 문제가 발생하는 경우 문제 해결을 시작하기 전에 pcluster stop <cluster_name> 명령을 실행하여 클러스터를 STOPPED 상태로 만들어야 합니다. 이렇게 하면 예상치 못한 비용이 발생하는 것을 방지할 수 있습니다.

pcluster의 작동이 중지되거나 로그를 보존하면서 클러스터를 삭제하려면 pcluster delete —keep-logs <cluster_name> 명령을 실행하세요. 이 명령을 실행하면 클러스터가 삭제되지만 Amazon 에 저장된 로그 그룹은 유지됩니다 CloudWatch. 이 명령에 대한 자세한 내용은 pcluster delete 설명서를 참조하세요.

스택 배포 문제 해결

클러스터 생성에 실패하고 스택 생성을 롤백하는 경우 다음 로그 파일을 살펴보고 문제를 진단할 수 있습니다. 이 로그에서 ROLLBACK_IN_PROGRESS의 출력을 찾아보겠습니다. 장애 메시지는 다음과 같아야 합니다.

$ pcluster create mycluster
Creating stack named: parallelcluster-mycluster
Status: parallelcluster-mycluster - ROLLBACK_IN_PROGRESS                        
Cluster creation failed.  Failed events:
  - AWS::EC2::Instance MasterServer Received FAILURE signal with UniqueId i-07af1cb218dd6a081

문제를 진단하려면 --norollback 플래그를 포함하여 pcluster create를 사용하여 클러스터를 다시 생성하세요. 그런 다음 클러스터SSH로:

$ pcluster create mycluster --norollback
...
$ pcluster ssh mycluster

헤드 노드에 로그인한 후에는 오류를 정확히 찾는 데 사용할 수 있는 세 개의 기본 로그 파일을 찾을 수 있습니다.

  • /var/log/cfn-init.log는 cfn-init 스크립트의 로그입니다. 먼저 이 로그를 확인하세요. 이 로그에 Command chef failed와 같은 오류가 표시될 수 있습니다. 오류 메시지와 관련된 자세한 내용은 이 줄 바로 앞에 있는 줄을 참조하세요. 자세한 내용은 cfn-init을 참조하세요.

  • /var/log/cloud-init.log은 cloud-init에 대한 로그입니다. cfn-init.log에 아무것도 표시되지 않으면 다음으로 이 로그를 확인해 보세요.

  • /var/log/cloud-init-output.log은 cloud-init이 실행한 명령의 출력입니다. 여기에는 cfn-init의 출력이 포함됩니다. 대부분의 경우 이러한 유형의 문제를 해결하기 위해 이 로그를 볼 필요가 없습니다.

다중 대기열 모드 클러스터의 문제 해결

이 섹션은 에서 AWS ParallelCluster 버전 2.9.0 이상을 사용하여 설치된 클러스터와 관련이 있습니다.Slurm 작업 스케줄러. 다중 대기열 모드에 대한 자세한 내용은 다중 대기열 모드 섹션을 참조하세요.

키 로그

다음 표에서는 헤드 노드의 키 로그 개요를 제공합니다.

/var/log/cfn-init.log

이는 AWS CloudFormation init 로그입니다. 여기에는 인스턴스가 설정될 때 실행된 모든 명령이 들어 있습니다. 초기화 문제를 해결하는 데 유용합니다.

/var/log/chef-client.log

이것은 Chef 클라이언트 로그입니다. Chef/를 통해 실행된 모든 명령이 포함되어 있습니다CINC. 초기화 문제를 해결하는 데 유용합니다.

/var/log/parallelcluster/slurm_resume.log

이것은 ResumeProgram 로그입니다. 동적 노드용 인스턴스를 시작하며 동적 노드 시작 문제를 해결하는 데 유용합니다.

/var/log/parallelcluster/slurm_suspend.log

이것은 SuspendProgram 로그입니다. 동적 노드의 인스턴스가 종료될 때 직접적으로 호출되며 동적 노드 종료 문제를 해결하는 데 유용합니다. 이 로그를 확인할 때는 clustermgtd 로그도 확인해야 합니다.

/var/log/parallelcluster/clustermgtd

이것은 clustermgtd 로그입니다. 이 대몬은 대부분의 클러스터 작업을 관리하는 중앙 대몬(daemon)으로 실행됩니다. 시작, 종료 또는 클러스터 작업 문제를 해결하는 데 유용합니다.

/var/log/slurmctld.log

이는 Slurm control daemon log. AWS ParallelCluster dosn은 조정 결정을 내리지 않습니다. 대신 를 충족하기 위해 리소스를 시작하려고 시도합니다.Slurm 요구 사항. 규모 조정 및 할당 문제, 작업 관련 문제, 스케줄러 관련 시작 및 종료 문제에 유용합니다.

컴퓨팅 노드의 키 노트는 다음과 같습니다.

/var/log/cloud-init-output.log

이것은 cloud-init 로그입니다. 여기에는 인스턴스가 설정될 때 실행된 모든 명령이 들어 있습니다. 초기화 문제를 해결하는 데 유용합니다.

/var/log/parallelcluster/computemgtd

이것은 computemgtd 로그입니다. 이것은 헤드 노드의 clustermgtd 대몬(daemon)이 오프라인 상태인 드문 상황에서 각 컴퓨팅 노드에서 실행되어 노드를 모니터링합니다. 예상치 못한 종료 문제를 해결하는 데 유용합니다.

/var/log/slurmd.log

이는 Slurm 데몬 로그를 계산합니다. 초기화 및 컴퓨팅 장애 관련 문제를 해결하는 데 유용합니다.

노드 초기화 문제 해결

이 섹션에서는 노드 초기화 문제를 해결하는 방법을 다룹니다. 여기에는 노드가 시작, 전원 공급 또는 클러스터 조인에 실패하는 문제가 포함됩니다.

헤드 노드:

해당 로그:

  • /var/log/cfn-init.log

  • /var/log/chef-client.log

  • /var/log/parallelcluster/clustermgtd

  • /var/log/parallelcluster/slurm_resume.log

  • /var/log/slurmctld.log

/var/log/cfn-init.log및 /var/log/chef-client.log 로그를 확인하세요. 이 로그에는 헤드 노드가 설정될 때 실행된 모든 작업이 포함되어야 합니다. 설정 중에 발생하는 대부분의 오류에는 /var/log/chef-client.log 로그에 오류 메시지가 있을 것입니다. 클러스터 구성에 사전 설치 또는 설치 후 스크립트가 지정된 경우 로그 메시지를 통해 스크립트가 성공적으로 실행되는지 다시 확인하세요.

클러스터를 생성할 때 헤드 노드는 컴퓨팅 노드가 클러스터에 조인할 때까지 기다려야 클러스터에 조인할 수 있습니다. 따라서 컴퓨팅 노드가 클러스터에 조인하지 못하면 헤드 노드도 조인하지 못합니다. 사용하는 컴퓨팅 노드 유형에 따라 다음 일련의 절차 중 하나를 수행하여 이러한 유형의 문제를 해결할 수 있습니다.

동적 컴퓨팅 노드:

  • ResumeProgram 로그(/var/log/parallelcluster/slurm_resume.log)에서 컴퓨팅 노드 이름을 검색하여 해당 노드와 함께 ResumeProgram이 직접 호출된 적이 있는지 확인합니다. (ResumeProgram이 호출되지 않은 경우 slurmctld 로그(/var/log/slurmctld.log)를 확인하여 Slurm 노드ResumeProgram로 호출을 시도한 적이 있습니다.)

  • 권한이 올바르지 않으면 ResumeProgram가 ResumeProgram를 자동으로 실패하게 할 수 있습니다. ResumeProgram 설정을 AMI 수정하여 사용자 지정을 사용하는 경우 가 slurm 사용자 소유ResumeProgram이며 744 (rwxr--r--) 권한이 있는지 확인합니다.

  • ResumeProgram이 직접 호출되면 해당 노드에 대한 인스턴스가 시작되었는지 확인하세요. 시작된 인스턴스가 없는 경우 시작 실패를 설명하는 오류 메시지를 볼 수 있을 것입니다.

  • 인스턴스가 시작된 경우 설정 프로세스 중에 문제가 있을 수 있습니다. ResumeProgram 로그에서 해당 프라이빗 IP 주소와 인스턴스 ID를 확인할 수 있습니다. 또한 특정 인스턴스의 대응하는 설정 로그를 볼 수 있습니다. 컴퓨팅 노드 설정 오류의 문제를 해결하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.

정적 컴퓨팅 노드:

  • clustermgtd(/var/log/parallelcluster/clustermgtd) 로그를 확인하여 해당 노드의 인스턴스가 시작되었는지 확인합니다. 시작되지 않은 경우 시작 실패를 자세히 설명하는 명확한 오류 메시지가 표시될 것입니다.

  • 인스턴스가 시작되면 설정 프로세스 중에 몇 가지 문제가 있습니다. ResumeProgram 로그에서 해당 프라이빗 IP 주소와 인스턴스 ID를 확인할 수 있습니다. 또한 특정 인스턴스의 대응하는 설정 로그를 볼 수 있습니다.

  • 컴퓨팅 노드:

    • 적용 가능한 로그:

      • /var/log/cloud-init-output.log

      • /var/log/slurmd.log

    • 컴퓨팅 노드가 시작된 경우 먼저 /var/log/cloud-init-output.log를 확인하세요. 헤드 노드의 /var/log/chef-client.log와 비슷한 설정 로그가 들어 있을 것입니다. 설정 중에 발생하는 대부분의 오류에는 /var/log/cloud-init-output.log 로그에 오류 메시지가 있을 것입니다. 클러스터 구성에 사전 설치 또는 설치 후 스크립트가 지정된 경우 해당 스크립트가 성공적으로 실행되었는지 확인하세요.

    • 에 대한 수정과 AMI 함께 사용자 지정을 사용하는 경우 Slurm 구성의 경우 Slurm 컴퓨팅 노드가 클러스터에 조인하는 것을 방지하는 관련 오류입니다. 스케줄러 관련 오류의 경우 /var/log/slurmd.log 로그를 확인하세요.

예상치 못한 노드 교체 및 종료 문제 해결

이 섹션에서는 특히 노드가 예기치 않게 교체되거나 종료되는 경우 노드 관련 문제를 해결하는 방법을 계속 살펴봅니다.

  • 적용 가능한 로그:

    • /var/log/parallelcluster/clustermgtd (헤드 노드)

    • /var/log/slurmctld.log (헤드 노드)

    • /var/log/parallelcluster/computemgtd (컴퓨팅 노드)

  • 노드가 예기치 않게 교체되거나 종료됨

    • clustermgtd로그(/var/log/parallelcluster/clustermgtd)를 확인하여 clustermgtd가 노드를 교체 또는 종료했는지 확인합니다. clustermgtd가 모든 일반적인 노드 유지 관리 작업을 처리한다는 점에 유의하세요.

    • clustermgtd가 노드를 교체하거나 종료한 경우 해당 노드를 그렇게 처리한 이유를 설명하는 메시지가 있을 것입니다. 이유가 스케줄러와 관련된 경우(예: 노드가 DOWN에 있기 때문) slurmctld 로그에서 자세한 내용을 확인하세요. 이유가 AmazonEC2과 관련된 경우 교체가 필요한 Amazon EC2 관련 문제를 자세히 설명하는 유용한 메시지가 있어야 합니다.

    • 가 노드를 종료하지 clustermgtd 않은 경우 먼저 이것이 Amazon 에 의한 예상 종료인지EC2, 보다 구체적으로 스팟 종료인지 확인합니다. 컴퓨팅 노드에서 computemgtd실행되는 는 clustermgtd가 비정상으로 확인되면 노드를 종료하는 조치를 취할 수도 있습니다. computemgtd로그(/var/log/parallelcluster/computemgtd)를 확인하여 computemgtd이 노드를 종료했는지 확인하세요.

  • 노드에 장애가 발생한 경우

    • slurmctld로그(/var/log/slurmctld.log)를 확인하여 작업이나 노드가 실패한 이유를 확인하세요. 단, 노드에 장애가 발생하면 작업이 자동으로 다시 대기열에 추가된다는 점에 유의하세요.

    • 해당 노드가 시작되었음을 slurm_resume 보고하고 해당 노드EC2에 대해 Amazon에 해당 인스턴스가 없다고 몇 분 후에 clustermgtd보고하는 경우 설정 중에 노드가 실패할 수 있습니다. 컴퓨팅(/var/log/cloud-init-output.log)에서 로그를 검색하려면 다음 단계를 따르세요.

      • 작업을 제출하여 허용 Slurm 새 노드를 스핀업합니다.

      • 노드가 시작된 후 이 명령을 사용하여 종료 보호를 활성화합니다.

        aws ec2 modify-instance-attribute --instance-id i-xyz --disable-api-termination

      • 이 명령을 사용하여 노드에서 콘솔 출력을 검색합니다.

        aws ec2 get-console-output --instance-id i-xyz --output text

문제가 있는 인스턴스 및 노드 교체, 종료 또는 전원 끄기

  • 적용 가능한 로그:

    • /var/log/parallelcluster/clustermgtd (헤드 노드)

    • /var/log/parallelcluster/slurm_suspend.log (헤드 노드)

  • 대부분의 경우 clustermgtd가 모든 예상 인스턴스 종료 작업을 처리합니다. clustermgtd 로그에서 노드 교체 또는 종료에 실패한 이유를 확인하세요.

  • 동적 노드에 scaledown_idletime 장애가 발생한 경우 SuspendProgram 로그를 확인하여 특정 노드를 인수로 사용하여 SuspendProgram이 slurmctld에 의해 직접 호출되었는지 확인하세요. SuspendProgram는 실제로 어떤 작업도 수행하지 않습니다. 그보다는 호출될 때만 로그를 기록합니다. 모든 인스턴스 종료 및 NodeAddr 재설정은 clustermgtd에 의해 수행됩니다.Slurm 는 이후 노드를 SuspendTimeout 자동으로 POWER_SAVING 상태로 되돌립니다.

기타 알려진 노드 및 작업 문제 해결

알려진 문제의 또 다른 유형은 작업을 할당하지 못하거나 규모 조정 결정을 내리지 못할 AWS ParallelCluster 수 있다는 것입니다. 이 유형의 문제에서는 에 따라 리소스 AWS ParallelCluster 만 시작, 종료 또는 유지 관리합니다.Slurm 지침. 이러한 문제의 경우 slurmctld 로그를 확인하여 문제를 해결하세요.

단일 대기열 모드 클러스터의 문제 해결

참고

버전 2.11.5부터 AWS ParallelCluster 의 사용을 지원하지 않습니다.SGE 또는 Torque 스케줄러.

이 섹션은 다음 두 구성 중 하나를 사용하는 다중 대기열 모드가 없는 클러스터에 적용됩니다.

  • 2.9.0 이전 AWS ParallelCluster 버전을 사용하여 시작 및 SGE, Torque, 또는 Slurm 작업 스케줄러.

  • AWS ParallelCluster 버전 2.9.0 이상을 사용하여 시작 및 SGE 또는 Torque 작업 스케줄러.

키 로그

다음 로그 파일은 헤드 노드의 키 로그입니다.

AWS ParallelCluster 버전 2.9.0 이상의 경우:

/var/log/chef-client.log

이는 CINC (chef) 클라이언트 로그입니다. 여기에는 를 통해 실행된 모든 명령이 포함됩니다CINC. 초기화 문제를 해결하는 데 유용합니다.

모든 AWS ParallelCluster 버전의 경우:

/var/log/cfn-init.log

이것은 cfn-init 로그입니다. 여기에는 인스턴스 설정 시 실행된 모든 명령이 포함되므로 초기화 문제를 해결하는 데 유용합니다. 자세한 내용은 cfn-init을 참조하세요.

/var/log/clustermgtd.log

에 대한 clustermgtd 로그입니다.Slurm 스케줄러. clustermgtd는 대부분의 클러스터 작업 작업을 관리하는 중앙 집중식 데몬으로 실행됩니다. 시작, 종료 또는 클러스터 작업 문제를 해결하는 데 유용합니다.

/var/log/jobwatcher

에 대한 jobwatcher 로그입니다.SGE 그리고 Torque scheduler. 는 스케줄러 대기열을 jobwatcher 모니터링하고 Auto Scaling 그룹을 업데이트합니다. 노드 스케일 업과 관련된 문제를 해결하는 데 유용합니다.

/var/log/sqswatcher

에 대한 sqswatcher 로그입니다.SGE 그리고 Torque 스케줄러. 는 성공적인 초기화 후 컴퓨팅 인스턴스에서 보낸 인스턴스 준비 이벤트를 sqswatcher 처리합니다. 또한 스케줄러 구성에 컴퓨팅 노드를 추가합니다. 이 로그는 노드 또는 노드가 클러스터에 조인하지 못한 이유를 해결하는 데 유용합니다.

컴퓨팅 노드의 키 로그는 다음과 같습니다.

AWS ParallelCluster 버전 2.9.0 이상

/var/log/cloud-init-output.log

이것은 Cloud init 로그입니다. 여기에는 인스턴스가 설정될 때 실행된 모든 명령이 들어 있습니다. 초기화 문제를 해결하는 데 유용합니다.

AWS ParallelCluster 2.9.0 이전 버전

/var/log/cfn-init.log

이는 CloudFormation init 로그입니다. 여기에는 인스턴스가 설정될 때 실행된 모든 명령이 들어 있습니다. 초기화 문제를 해결하는 데 유용합니다.

모든 버전

/var/log/nodewatcher

를 사용할 때 각 컴퓨팅 노드에서 실행되는 nodewatcher 로그 nodewatcher 데몬입니다.SGE 그리고 Torque 스케줄러. 유휴 상태인 경우 노드를 스케일 다운합니다. 이 로그는 리소스 스케일 다운과 관련된 모든 문제에 유용합니다.

시작 및 조인 작업 실패 문제 해결

  • 적용 가능한 로그:

    • /var/log/cfn-init-cmd.log(헤드 노드 및 컴퓨팅 노드)

    • /var/log/sqswatcher(헤드 노드)

  • 노드 시작에 실패한 경우 /var/log/cfn-init-cmd.log 로그를 확인하여 특정 오류 메시지를 확인하세요. 대부분의 경우 노드 시작 실패는 설정 실패로 인해 발생합니다.

  • 설치에 성공했는데도 컴퓨팅 노드가 스케줄러 구성에 조인하지 못한 경우 /var/log/sqswatcher 로그를 확인하여 sqswatcher의 이벤트 처리 여부를 확인하세요. 대부분의 경우 이러한 문제는 sqswatcher가 이벤트를 처리하지 않았기 때문입니다.

규모 조정 문제 해결

  • 적용 가능한 로그:

    • /var/log/jobwatcher(헤드 노드)

    • /var/log/nodewatcher(컴퓨팅 노드)

  • 스케일 업 문제: 헤드 노드의 경우 /var/log/jobwatcher 로그를 확인하여 jobwatcher 대몬(daemon)이 필요한 노드 수를 적절하게 계산하고 Auto Scaling 그룹을 업데이트했는지 확인하세요. 참고로 jobwatcher는 스케줄러 대기열을 모니터링하고 Auto Scaling 그룹을 업데이트합니다.

  • 스케일 다운 문제: 컴퓨팅 노드의 경우 문제가 있는 노드의 /var/log/nodewatcher 로그를 확인하여 노드가 스케일 다운된 이유를 확인하세요. 참고로, 컴퓨팅 노드가 유휴 상태인 경우 nodewatcher 대몬(daemon)은 컴퓨팅 노드를 스케일 다운합니다.

알려진 문제 중 하나는 대규모 클러스터, 특히 컴퓨팅 노드가 500개 이상인 클러스터에서 무작위 컴퓨팅 노트가 실패한다는 것입니다. 이 문제는 단일 대기열 클러스터의 확장 아키텍처 제한과 관련이 있습니다. 대규모 클러스터를 사용하려는 경우 는 AWS ParallelCluster 버전 v2.9.0 이상을 사용하며 는 를 사용합니다.Slurm이 문제를 방지하려면 를 업그레이드하고 다중 대기열 모드 지원 클러스터로 전환해야 합니다. pcluster-config convert를 실행하여 그렇게 할 수 있습니다.

초대형 클러스터의 경우 시스템에 대한 추가 규모 조정이 필요할 수 있습니다. 자세한 내용은 에 문의하세요 AWS Support.

배치 그룹 및 인스턴스 시작 문제

노드 간 지연 시간을 최소화하려면 배치 그룹을 사용하세요. 배치 그룹은 인스턴스가 동일한 네트워킹 백본에 위치하도록 보장합니다. 요청이 이루어질 때 사용 가능한 인스턴스가 충분하지 않으면 InsufficientInstanceCapacity 오류가 반환됩니다. 클러스터 배치 그룹을 사용할 때 이 오류가 발생할 가능성을 줄이려면 placement_group 파라미터를 DYNAMIC으로 설정하고 placement 파라미터를 compute로 설정합니다.

고성능 공유 파일 시스템이 필요한 경우 를 FSx Lustre 에 사용하는 것이 좋습니다.

헤드 노드가 배치 그룹에 있어야 하는 경우 헤드 및 컴퓨팅 노드 모두에 대해 동일한 인스턴스 유형과 서브넷을 사용합니다. 이렇게 하면 compute_instance_type 파라미터는 master_instance_type 파라미터와 동일한 값을 가지며 placement 파라미터는 cluster로 설정되고 compute_subnet_id 파라미터는 지정되지 않습니다. 이 구성에서는, master_subnet_id 파라미터 값이 컴퓨팅 노드에 사용됩니다.

자세한 내용은 Amazon EC2 사용 설명서의 인스턴스 시작 문제 및 배치 그룹 역할 및 제한 문제 해결을 참조하세요. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups

교체할 수 없는 디렉터리

다음 디렉터리는 노드 간에 공유되므로 교체할 수 없습니다.

/home

여기에는 기본 사용자 홈 폴더(/home/ec2_userAmazon Linux의 경우 , /home/centos CentOS, 및 /home/ubuntu의 Ubuntu).

/opt/intel

여기에는 Intel MPI, Intel Parallel Studio 및 관련 파일이 포함됩니다.

/opt/sge
참고

버전 2.11.5부터 AWS ParallelCluster 의 사용을 지원하지 않습니다.SGE 또는 Torque 스케줄러.

여기에는 다음이 포함됩니다.Son of Grid Engine 및 관련 파일. (조건부, scheduler = sge의 경우에만 해당.)

/opt/slurm

여기에는 다음이 포함됩니다.Slurm Workload Manager 및 관련 파일. (조건부, scheduler = slurm의 경우에만 해당.)

/opt/torque
참고

버전 2.11.5부터 AWS ParallelCluster 의 사용을 지원하지 않습니다.SGE 또는 Torque 스케줄러.

여기에는 다음이 포함됩니다.Torque Resource Manager 및 관련 파일. (조건부, scheduler = torque의 경우에만 해당.)

Amazon의 문제 해결 DCV

Amazon용 로그 DCV

Amazon의 로그는 /var/log/dcv/ 디렉터리의 파일에 기록DCV됩니다. 이러한 로그를 검토하면 문제를 해결하는 데 도움이 될 수 있습니다.

Amazon DCV 인스턴스 유형 메모리

Amazon 를 실행RAM하려면 인스턴스 유형에 1.7기가비바이트(GiB ) 이상이 있어야 합니다DCV.Nano 그리고 micro 인스턴스 유형에 Amazon 를 실행할 메모리가 충분하지 않습니다DCV.

Ubuntu Amazon DCV 문제

Ubuntu에서 DCV 세션을 통해 Gnome 터미널을 실행하는 경우 로그인 쉘을 통해 를 AWS ParallelCluster 사용할 수 있는 사용자 환경에 자동으로 액세스하지 못할 수 있습니다. 사용자 환경은 openmpi 또는 intelmpi 같은 환경 모듈과 기타 사용자 설정을 제공합니다.

Gnome 터미널의 기본 설정으로 인해 쉘이 로그인 쉘로 시작되지 않습니다. 즉, 쉘 프로파일이 자동으로 소싱되지 않고 AWS ParallelCluster 사용자 환경이 로드되지 않습니다.

쉘 프로파일을 올바르게 소싱하고 AWS ParallelCluster 사용자 환경에 액세스하려면 다음 중 하나를 수행합니다.

  • 기본 터미널 설정 변경

    1. Gnome 터미널에서 편집 메뉴를 선택합니다.

    2. 환경설정을 선택한 다음 프로필을 선택합니다.

    3. 명령을 선택하고 로그인 쉘로 명령 실행을 선택합니다.

    4. 새 터미널을 엽니다.

  • 명령줄을 사용하여 사용 가능한 프로필을 가져올 수 있습니다.

    $ source /etc/profile && source $HOME/.bashrc

AWS Batch 통합을 통한 클러스터의 문제 해결

이 섹션은 AWS Batch 스케줄러 통합이 있는 클러스터와 관련이 있습니다.

헤드 노드 문제

헤드 노드 관련 설정 문제는 단일 대기열 클러스터와 동일한 방식으로 해결할 수 있습니다. 이러한 문제에 대한 자세한 내용은 단일 대기열 모드 클러스터의 문제 해결 섹션을 참조하세요.

AWS Batch 다중 노드 병렬 작업 제출 문제

를 작업 스케줄러 AWS Batch 로 사용할 때 다중 노드 병렬 작업을 제출하는 데 문제가 있는 경우 AWS ParallelCluster 버전 2.5.0으로 업그레이드해야 합니다. 이것이 가능하지 않은 경우 다중 AWS Batch를 통해 노드 병렬 작업을 제출하는 데 사용되는 클러스터를 자체 패치하기 항목에 자세히 설명된 해결 방법을 사용할 수 있습니다.

컴퓨팅 문제

AWS Batch 는 서비스의 크기 조정 및 컴퓨팅 측면을 관리합니다. 컴퓨팅 관련 문제가 발생하면 문제 AWS Batch 해결 설명서의 도움말을 참조하세요.

작업 실패

작업이 실패할 경우 awsbout 명령을 실행하여 작업 출력을 검색할 수 있습니다. awsbstat -d 명령을 실행하여 Amazon 에 저장된 작업 로그에 대한 링크를 가져올 수도 있습니다 CloudWatch.

리소스 생성 실패 시 문제 해결

이 섹션은 클러스터 리소스를 생성하지 못한 경우와 관련이 있습니다.

리소스가 생성되지 않으면 다음과 같은 오류 메시지가 ParallelCluster 반환됩니다.

pcluster create -c config my-cluster
Beginning cluster creation for cluster: my-cluster
WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with 
id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the 
Internet (e.g. a NAT Gateway and a valid route table).
WARNING: The instance type 'p4d.24xlarge' cannot take public IPs. Please make sure that the subnet with
id 'subnet-1234567890abcdef0' has the proper routing configuration to allow private IPs reaching the Internet 
(e.g. a NAT Gateway and a valid route table).
Info: There is a newer version 3.0.3 of AWS ParallelCluster available.
Creating stack named: parallelcluster-my-cluster
Status: parallelcluster-my-cluster - ROLLBACK_IN_PROGRESS                   
Cluster creation failed.  Failed events:
- AWS::CloudFormation::Stack MasterServerSubstack Embedded stack 
arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789 
was not successfully created: 
The following resource(s) failed to create: [MasterServer]. 
- AWS::CloudFormation::Stack parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL The following resource(s) failed to create: [MasterServer]. 
- AWS::EC2::Instance MasterServer You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the 
specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.  
(Service: AmazonEC2; Status Code: 400; Error Code: VcpuLimitExceeded; Request ID: a9876543-b321-c765-d432-dcba98766789; Proxy: null)
}

예를 들어 이전 명령 응답에 상태 메시지가 표시되면 현재 vCPU 제한을 초과하지 않는 인스턴스 유형을 사용하거나 더 많은 vCPU 용량을 요청해야 합니다.

CloudFormation 콘솔을 사용하여 "Cluster creation failed" 상태에 대한 정보를 볼 수도 있습니다.

콘솔에서 CloudFormation 오류 메시지를 봅니다.

  1. 에 로그인 AWS Management Console 하고 https://console.aws.amazon.com/cloudformation으로 이동합니다.

  2. parallelcluster-라는 스택을 선택합니다.cluster_name.

  3. 이벤트 탭을 선택합니다.

  4. 논리적 ID별로 리소스 이벤트 목록을 스크롤하여 생성에 실패한 리소스의 상태를 확인합니다. 하위 작업을 만들지 못한 경우 역방향으로 진행하여 실패한 리소스 이벤트를 찾아보세요.

  5. AWS CloudFormation 오류 메시지의 예:

    2022-02-07 11:59:14 UTC-0800	MasterServerSubstack	CREATE_FAILED	Embedded stack 
arn:aws:cloudformation:region-id:123456789012:stack/parallelcluster-my-cluster-MasterServerSubstack-ABCDEFGHIJKL/a1234567-b321-c765-d432-dcba98766789
was not successfully created: The following resource(s) failed to create: [MasterServer].

IAM 정책 크기 문제 해결

IAM 및 AWS STS 할당량, 이름 요구 사항 및 문자 제한을 참조하여 역할에 연결된 관리형 정책의 할당량을 확인합니다. 관리형 정책 크기가 할당량을 초과하는 경우 정책을 둘 이상의 정책으로 분할하세요. IAM 역할에 연결된 정책 수의 할당량을 초과하는 경우 추가 역할을 생성하고 할당량을 충족하기 위해 정책을 배포합니다.

추가 지원

알려진 문제 목록은 기본 GitHub Wiki 페이지 또는 문제 페이지를 참조하세요. 더 긴급한 문제는 에 문의 AWS Support 하거나 새 문제를 엽니다. GitHub