기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS ParallelCluster 문제 해결 AWS ParallelCluster 커뮤니티는 [AWS ParallelCluster GitHub Wiki에 대한 다양한 문제 해결 팁을 제공하는 Wiki](https://github.com/aws/aws-parallelcluster/wiki/) 페이지를 유지 관리합니다. 알려진 문제 목록을 알아보려면 [알려진 문제](https://github.com/aws/aws-parallelcluster/wiki#known-issues-)를 참조하세요. **Topics** + [로그 검색 및 보존](#retrieving-and-preserve-logs) + [스택 배포 문제 해결](#troubleshooting-stack-creation-failures) + [다중 대기열 모드 클러스터의 문제 해결](#multiple-queue-mode) + [단일 대기열 모드 클러스터의 문제 해결](#troubleshooting-issues-in-single-queue-clusters) + [배치 그룹 및 인스턴스 시작 문제](#placement-groups-and-instance-launch-issues) + [교체할 수 없는 디렉터리](#directories-cannot-be-replaced) + [Amazon DCV의 문제 해결](#nice-dcv-troubleshooting) + [AWS Batch 통합을 통한 클러스터 문제 해결](#clusters-with-aws-batch-integration) + [리소스 생성 실패 시 문제 해결](#troubleshooting-resource-fails-to-create) + [IAM 정책 크기 문제 해결](#troubleshooting-policy-size-issues) + [추가 지원](#getting-support) ## 로그 검색 및 보존 로그는 문제를 해결하는 데 유용한 리소스입니다. 로그를 사용하여 AWS ParallelCluster 리소스 문제를 해결하려면 먼저 클러스터 로그 아카이브를 만들어야 합니다. [AWS ParallelCluster GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki/)의 [클러스터 로그 아카이브 생성](https://github.com/aws/aws-parallelcluster/wiki/Creating-an-Archive-of-a-Cluster's-Logs) 항목에 설명된 단계에 따라 이 프로세스를 시작하세요. 실행 중인 클러스터 중 하나에 문제가 발생하는 경우 문제 해결을 시작하기 전에 ``pcluster stop` ` 명령을 실행하여 클러스터를 `STOPPED` 상태로 만들어야 합니다. 이렇게 하면 예상치 못한 비용이 발생하는 것을 방지할 수 있습니다. `pcluster`의 작동이 중지되거나 로그를 보존하면서 클러스터를 삭제하려면 ``pcluster delete` —keep-logs ` 명령을 실행하세요. 이 명령을 실행하면 클러스터는 삭제되지만 Amazon CloudWatch에 저장된 로그 그룹은 보존됩니다. 이 명령에 대한 자세한 내용은 [`pcluster delete`](pcluster.delete.md) 설명서를 참조하세요. ## 스택 배포 문제 해결 클러스터 생성에 실패하고 스택 생성을 롤백하는 경우 다음 로그 파일을 살펴보고 문제를 진단할 수 있습니다. 이 로그에서 `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`](pluster.create.md)를 사용하여 클러스터를 다시 생성하세요. 그런 다음 SSH로 클러스터에 연결합니다. ``` $ pcluster create mycluster --norollback ... $ pcluster ssh mycluster ``` 헤드 노드에 로그인한 후에는 오류를 정확히 찾는 데 사용할 수 있는 세 개의 기본 로그 파일을 찾을 수 있습니다. + `/var/log/cfn-init.log`는 `cfn-init` 스크립트의 로그입니다. 먼저 이 로그를 확인하세요. 이 로그에 `Command chef failed`와 같은 오류가 표시될 수 있습니다. 오류 메시지와 관련된 자세한 내용은 이 줄 바로 앞에 있는 줄을 참조하세요. 자세한 내용은 [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html)을 참조하세요. + `/var/log/cloud-init.log`은 [cloud-init](https://cloudinit.readthedocs.io/)에 대한 로그입니다. `cfn-init.log`에 아무것도 표시되지 않으면 다음으로 이 로그를 확인해 보세요. + `/var/log/cloud-init-output.log`은 [cloud-init](https://cloudinit.readthedocs.io/)이 실행한 명령의 출력입니다. 여기에는 `cfn-init`의 출력이 포함됩니다. 대부분의 경우 이러한 유형의 문제를 해결하기 위해 이 로그를 볼 필요가 없습니다. ## 다중 대기열 모드 클러스터의 문제 해결 이 섹션은 Slurm 작업 스케줄러와 함께 AWS ParallelCluster 버전 2.9.0 이상을 사용하여 설치된 클러스터와 관련이 있습니다. 다중 대기열 모드에 대한 자세한 내용은 [다중 대기열 모드](queue-mode.md) 섹션을 참조하세요. **Topics** + [키 로그](#key-logs) + [노드 초기화 문제 해결****](#troubleshooting-node-initialization-issues) + [예상치 못한 노드 교체 및 종료 문제 해결****](#troubleshooting-unexpected-node-replacements-and-terminations) + [문제가 있는 인스턴스 및 노드 교체, 종료 또는 전원 끄기****](#replacing-terminating-or-powering-down-problematic-instances-and-nodes) + [기타 알려진 노드 및 작업 문제 해결****](#troubleshooting-other-known-node-and-job-issues) ### 키 로그 다음 표에서는 헤드 노드의 키 로그 개요를 제공합니다. `/var/log/cfn-init.log` 이것이 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 데몬 로그입니다. 조정 결정을 내 AWS ParallelCluster 리지 않습니다. 오히려 Slurm 요구 사항을 충족하는 리소스를 시작하려고 시도할 뿐입니다. 규모 조정 및 할당 문제, 작업 관련 문제, 스케줄러 관련 시작 및 종료 문제에 유용합니다. 컴퓨팅 노드의 키 노트는 다음과 같습니다. `/var/log/cloud-init-output.log` 이것은 [cloud-init](https://cloudinit.readthedocs.io/) 로그입니다. 여기에는 인스턴스가 설정될 때 실행된 모든 명령이 들어 있습니다. 초기화 문제를 해결하는 데 유용합니다. `/var/log/parallelcluster/computemgtd` 이것은 `computemgtd` 로그입니다. 이것은 헤드 노드의 `clustermgtd` 대몬(daemon)이 오프라인 상태인 드문 상황에서 각 컴퓨팅 노드에서 실행되어 노드를 모니터링합니다. 예상치 못한 종료 문제를 해결하는 데 유용합니다. `/var/log/slurmd.log` 이것은 Slurm 컴퓨팅 대몬(daemon) 로그입니다. 초기화 및 컴퓨팅 장애 관련 문제를 해결하는 데 유용합니다. ### 노드 초기화 문제 해결**** 이 섹션에서는 노드 초기화 문제를 해결하는 방법을 다룹니다. 여기에는 노드가 시작, 전원 공급 또는 클러스터 조인에 실패하는 문제가 포함됩니다. 헤드 노드:**** 해당 로그: + `/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`)를 확인하여가 노드`ResumeProgram`로 호출을 시도Slurm했는지 확인할 수 있습니다.) + 권한이 올바르지 않으면 `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` 로그에 오류 메시지가 있을 것입니다. 클러스터 구성에 사전 설치 또는 설치 후 스크립트가 지정된 경우 해당 스크립트가 성공적으로 실행되었는지 확인하세요. + Slurm 구성을 수정하여 사용자 지정 AMI를 사용하는 경우 컴퓨팅 노드가 클러스터에 조인하지 못하게 하는 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` 로그에서 자세한 내용을 확인하세요. 이유가 Amazon EC2와 관련된 것이라면 교체가 필요한 Amazon EC2 관련 문제를 자세히 설명하는 정보 메시지가 있을 것입니다. + 가 노드를 종료하지 `clustermgtd` 않은 경우 먼저 이것이 Amazon EC2에 의한 예상 종료인지, 특히 스팟 종료인지 확인합니다. 컴퓨팅 노드에서 `computemgtd`실행되는는 `clustermgtd`가 비정상으로 확인되면 노드를 종료하는 작업을 수행할 수도 있습니다. `computemgtd`로그(`/var/log/parallelcluster/computemgtd`)를 확인하여 `computemgtd`이 노드를 종료했는지 확인하세요. + 노드에 장애가 발생한 경우**** + `slurmctld`로그(`/var/log/slurmctld.log`)를 확인하여 작업이나 노드가 실패한 이유를 확인하세요. 단, 노드에 장애가 발생하면 작업이 자동으로 다시 대기열에 추가된다는 점에 유의하세요. + `slurm_resume`이 해당 노드가 시작되었다고 보고하고 `clustermgtd`가 몇 분 후에 Amazon EC2에 해당 노드에 대응하는 인스턴스가 없다고 보고하면 설정 중에 노드가 실패할 수 있습니다. 컴퓨팅(`/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`](scaling-section.md#scaledown-idletime) 장애가 발생한 경우 `SuspendProgram` 로그를 확인하여 특정 노드를 인수로 사용하여 `SuspendProgram`이 `slurmctld`에 의해 직접 호출되었는지 확인하세요. `SuspendProgram`는 실제로 어떤 작업도 수행하지 않습니다. 그보다는 직접 호출될 때만 로그를 기록합니다. 모든 인스턴스 종료 및 `NodeAddr` 재설정은 `clustermgtd`에 의해 수행됩니다. Slurm은 `SuspendTimeout` 이후에 노드를 자동으로 `POWER_SAVING` 상태로 되돌립니다. ### 기타 알려진 노드 및 작업 문제 해결**** 알려진 또 다른 유형의 문제는가 작업을 할당하지 못하거나 조정 결정을 내리지 못할 AWS ParallelCluster 수 있다는 것입니다. 이러한 유형의 문제에서는 만 Slurm 지침에 따라 리소스를 AWS ParallelCluster 시작, 종료 또는 유지 관리합니다. 이러한 문제의 경우 `slurmctld` 로그를 확인하여 문제를 해결하세요. ## 단일 대기열 모드 클러스터의 문제 해결 **참고** 버전 2.11.5부터 SGE 또는 Torque 스케줄러 사용을 지원하지 AWS ParallelCluster 않습니다. 이 섹션은 다음 두 구성 중 하나를 사용하는 다중 대기열 모드가 없는 클러스터에 적용됩니다. + 2.9.0 이전 AWS ParallelCluster 버전과 SGE, Torque또는 Slurm 작업 스케줄러를 사용하여 시작되었습니다. + AWS ParallelCluster 버전 2.9.0 이상 및 SGE 또는 Torque 작업 스케줄러를 사용하여 시작되었습니다. **Topics** + [키 로그](#key-logs-1) + [시작 및 조인 작업 실패 문제 해결****](#troubleshooting-failed-launch-and-join-operations) + [규모 조정 문제 해결](#troubleshooting-scaling-issues) + [기타 클러스터 관련 문제 해결](#troubleshooting-other-cluster-related-issues) ### 키 로그 다음 로그 파일은 헤드 노드의 키 로그입니다. AWS ParallelCluster 버전 2.9.0 이상의 경우: `/var/log/chef-client.log` 이것은 CINC(chef) 클라이언트 로그입니다. 여기에는 CINC를 통해 실행된 모든 명령이 포함됩니다. 초기화 문제를 해결하는 데 유용합니다. 모든 AWS ParallelCluster 버전의 경우: `/var/log/cfn-init.log` 이것은 `cfn-init` 로그입니다. 여기에는 인스턴스 설정 시 실행된 모든 명령이 포함되므로 초기화 문제를 해결하는 데 유용합니다. 자세한 내용은 [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html)을 참조하세요. `/var/log/clustermgtd.log` 이것은 Slurm 스케줄러용 `clustermgtd` 로그입니다. `clustermgtd`는 대부분의 클러스터 작업을 관리하는 중앙 대몬(daemon)으로 실행됩니다. 시작, 종료 또는 클러스터 작업 문제를 해결하는 데 유용합니다. `/var/log/jobwatcher` 이것은 SGE 및 Torque 스케줄러의 `jobwatcher` 로그입니다. `jobwatcher`는 스케줄러 대기열을 모니터링하고 Auto Scaling 그룹을 업데이트합니다. 노드 스케일 업과 관련된 문제를 해결하는 데 유용합니다. `/var/log/sqswatcher` 이 로그는 SGE 및 Torque 스케줄러에 대한 `sqswatcher` 로그입니다. `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스케줄러를 사용할 때 각 컴퓨팅 노드에서 실행되는 대몬(daemon)입니다. 유휴 상태인 경우 노드를 스케일 다운합니다. 이 로그는 리소스 스케일 다운과 관련된 모든 문제에 유용합니다. ### 시작 및 조인 작업 실패 문제 해결**** + 적용 가능한 로그:**** + `/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`](pcluster-config.md#pcluster-config-convert)를 실행하여 그렇게 할 수 있습니다. ultra-large-scale 클러스터의 경우 시스템에 대한 추가 튜닝이 필요할 수 있습니다. 자세한 내용은에 문의하십시오 지원. ## 배치 그룹 및 인스턴스 시작 문제 노드 간 지연 시간을 최소화하려면 배치 그룹**을 사용하세요. 배치 그룹은 인스턴스가 동일한 네트워킹 백본에 위치하도록 보장합니다. 요청이 이루어질 때 사용 가능한 인스턴스가 충분하지 않으면 `InsufficientInstanceCapacity` 오류가 반환됩니다. 클러스터 배치 그룹을 사용할 때 이 오류가 발생할 가능성을 줄이려면 [`placement_group`](cluster-definition.md#placement-group) 파라미터를 `DYNAMIC`으로 설정하고 [`placement`](cluster-definition.md#placement) 파라미터를 `compute`로 설정합니다. 고성능 공유 파일 시스템이 필요한 경우 [FSx for Lustre](https://aws.amazon.com/fsx/lustre/)를 사용하는 것이 좋습니다. 헤드 노드가 배치 그룹에 있어야 하는 경우 헤드 및 컴퓨팅 노드 모두에 대해 동일한 인스턴스 유형과 서브넷을 사용합니다. 이렇게 하면 [`compute_instance_type`](cluster-definition.md#compute-instance-type) 파라미터는 [`master_instance_type`](cluster-definition.md#master-instance-type) 파라미터와 동일한 값을 가지며 [`placement`](cluster-definition.md#placement) 파라미터는 `cluster`로 설정되고 [`compute_subnet_id`](vpc-section.md#compute-subnet-id) 파라미터는 지정되지 않습니다. 이 구성에서는, [`master_subnet_id`](vpc-section.md#master-subnet-id) 파라미터 값이 컴퓨팅 노드에 사용됩니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 시작 문제 해결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) 및 [배치 그룹 규칙 및 제한](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#concepts-placement-groups)을 참조하세요. ## 교체할 수 없는 디렉터리 다음 디렉터리는 노드 간에 공유되므로 교체할 수 없습니다. `/home` 여기에는 기본 사용자 홈 폴더(Amazon Linux의 `/home/ec2_user`, CentOS의 `/home/centos`, `/home/ubuntu`의 Ubuntu)가 포함됩니다. `/opt/intel` 여기에는 Intel MPI, Intel Parallel Studio 및 관련 파일이 포함됩니다. `/opt/sge` 버전 2.11.5부터 SGE 또는 Torque 스케줄러 사용을 지원하지 AWS ParallelCluster 않습니다. 여기에는 Son of Grid Engine 및 관련 파일이 포함됩니다. (조건부, [`scheduler`](cluster-definition.md#scheduler)` = sge`의 경우에만 해당.) `/opt/slurm` 여기에는 Slurm Workload Manager 및 관련 파일이 포함됩니다. (조건부, [`scheduler`](cluster-definition.md#scheduler)` = slurm`의 경우에만 해당.) `/opt/torque` 버전 2.11.5부터 SGE 또는 Torque 스케줄러 사용을 지원하지 AWS ParallelCluster 않습니다. 여기에는 Torque Resource Manager 및 관련 파일이 포함됩니다. (조건부, [`scheduler`](cluster-definition.md#scheduler)` = torque`의 경우에만 해당.) ## Amazon DCV의 문제 해결 **Topics** + [Amazon DCV용 로그](#nice-dcv-troubleshooting-logs) + [Amazon DCV 인스턴스 유형 메모리](#nice-dcv-troubleshooting-memory) + [Ubuntu Amazon DCV 문제](#nice-dcv-troubleshooting-modules) ### Amazon DCV용 로그 Amazon DCV에 대한 로그는 `/var/log/dcv/` 디렉터리의 파일에 기록됩니다. 이러한 로그를 검토하면 문제를 해결하는 데 도움이 될 수 있습니다. ### Amazon DCV 인스턴스 유형 메모리 Amazon DCV를 실행하려면 인스턴스 유형에 1.7GiB 이상의 RAM이 있어야 합니다. Nano 및 micro 인스턴스 유형에 Amazon DCV를 실행할 메모리가 부족합니다. ### Ubuntu Amazon DCV 문제 Ubuntu의 DCV 세션을 통해 Gnome 터미널을 실행하는 경우 로그인 셸을 통해를 AWS ParallelCluster 사용할 수 있는 사용자 환경에 자동으로 액세스하지 못할 수 있습니다. 사용자 환경은 openmpi 또는 intelmpi 같은 환경 모듈과 기타 사용자 설정을 제공합니다. Gnome 터미널의 기본 설정으로 인해 쉘이 로그인 쉘로 시작되지 않습니다. 즉, 쉘 프로파일이 자동으로 소싱되지 않고 AWS ParallelCluster 사용자 환경이 로드되지 않습니다. 쉘 프로파일을 올바르게 소싱하고 AWS ParallelCluster 사용자 환경에 액세스하려면 다음 중 하나를 수행합니다. + **기본 터미널 설정 변경** 1. Gnome 터미널에서 **편집** 메뉴를 선택합니다. 1. **환경설정**을 선택한 다음 **프로필**을 선택합니다. 1. **명령**을 선택하고 **로그인 쉘로 명령 실행**을 선택합니다. 1. 새 터미널을 엽니다. + **명령줄을 사용하여 사용 가능한 프로필을 가져올 수 있습니다.** ``` $ source /etc/profile && source $HOME/.bashrc ``` ## AWS Batch 통합을 통한 클러스터 문제 해결 이 섹션은 AWS Batch 스케줄러 통합이 있는 클러스터와 관련이 있습니다. ### 헤드 노드 문제 헤드 노드 관련 설정 문제는 단일 대기열 클러스터와 동일한 방식으로 해결할 수 있습니다. 이러한 문제에 대한 자세한 내용은 [단일 대기열 모드 클러스터의 문제 해결](#troubleshooting-issues-in-single-queue-clusters) 섹션을 참조하세요. ### AWS Batch 다중 노드 병렬 작업 제출 문제 를 작업 스케줄러 AWS Batch 로 사용할 때 다중 노드 병렬 작업을 제출하는 데 문제가 있는 경우 AWS ParallelCluster 버전 2.5.0으로 업그레이드해야 합니다. 이것이 가능하지 않은 경우 다중 [AWS Batch를 통해 노드 병렬 작업을 제출하는 데 사용되는 클러스터를 자체 패치하기](https://github.com/aws/aws-parallelcluster/wiki/Self-patch-a-Cluster-Used-for-Submitting-Multi-node-Parallel-Jobs-through-AWS-Batch) 항목에 자세히 설명된 해결 방법을 사용할 수 있습니다. ### 컴퓨팅 문제 AWS Batch 는 서비스의 규모 조정 및 컴퓨팅 측면을 관리합니다. 컴퓨팅 관련 문제가 발생하는 경우 AWS Batch [문제 해결](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html) 설명서에서 도움말을 참조하세요. ### 작업 실패 작업이 실패할 경우 ``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](https://console.aws.amazon.com/cloudformation/) 이동합니다. 1. 이름이 parallelcluster-*cluster\$1name*인 스택을 선택합니다. 1. **이벤트** 탭을 선택합니다. 1. **논리적 ID**별로 리소스 이벤트 목록을 스크롤하여 생성에 실패한 리소스의 **상태**를 확인합니다. 하위 작업을 만들지 못한 경우 역방향으로 진행하여 실패한 리소스 이벤트를 찾아보세요. 1. 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 량, 이름 요구 사항 및 문자 제한을](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) 참조하여 역할에 연결된 관리형 정책의 할당량을 확인합니다. 관리형 정책 크기가 할당량을 초과하는 경우 정책을 둘 이상의 정책으로 분할하세요. IAM 역할에 연결된 정책 수의 할당량을 초과하는 경우, 추가 역할을 생성하고 할당량을 충족하도록 역할을 역할 간에 정책을 분배하세요. ## 추가 지원 알려진 문제 목록은 기본 [GitHub Wiki](https://github.com/aws/aws-parallelcluster/wiki) 페이지 또는 [문제](https://github.com/aws/aws-parallelcluster/issues) 페이지를 참조하세요. 더 긴급한 문제는에 문의 지원 하거나 [새 GitHub 문제를](https://github.com/aws/aws-parallelcluster/issues) 여세요.