기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS ParallelCluster 문제 해결 다음 섹션에서는 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** + [클러스터를 생성하려는 경우](troubleshooting-fc-v3-create-cluster.md) + [작업을 실행하려는 경우](troubleshooting-fc-v3-run-job.md) + [클러스터를 업데이트하려는 경우](troubleshooting-fc-v3-update-cluster.md) + [스토리지에 액세스하려는 경우](troubleshooting-fc-v3-access-storage.md) + [클러스터를 삭제하려는 경우](troubleshooting-fc-v3-delete-cluster.md) + [AWS ParallelCluster API 스택 업그레이드 시도](troubleshooting-fc-v3-upgrade-stack-v3.md) + [컴퓨팅 노드 초기화 오류가 표시되는 경우](troubleshooting-fc-v3-compute-node-initialization-v3.md) + [클러스터 상태 지표 문제 해결](troubleshooting-v3-cluster-health-metrics.md) + [클러스터 배포 문제 해결](troubleshooting-v3-cluster-deployment.md) + [Terraform을 사용한 클러스터 배포 문제 해결](troubleshooting-v3-terraform.md) + [규모 조정 문제 해결](troubleshooting-v3-scaling-issues.md) + [배치 그룹 및 인스턴스 시작 문제](troubleshooting-v3-placemment-groups.md) + [디렉터리 교체](troubleshooting-v3-dirs-must-keep.md) + [Amazon DCV의 문제 해결](troubleshooting-v3-nice-dcv.md) + [AWS Batch 통합을 통한 클러스터 문제 해결](troubleshooting-v3-batch.md) + [Active Directory와의 다중 사용자 통합 문제 해결](troubleshooting-v3-multi-user.md) + [사용자 지정 AMI 문제 해결](troubleshooting-v3-custom-amis.md) + [`cfn-hup`이 실행 중이 아닐 때의 클러스터 업데이트 제한 시간 문제 해결](troubleshooting-v3-cluster-update-timeout.md) + [네트워크 문제 해결](troubleshooting-v3-networking.md) + [`onNodeUpdated` 사용자 지정 작업에서 클러스터 업데이트가 실패한 경우](troubleshooting-v3-on-node-updated.md) + [사용자 지정 Slurm 구성에서 오류가 표시되는 경우](troubleshooting-v3-custom-slurm-config.md) + [클러스터 경보](troubleshooting-v3-cluster-alarms.md) + [오류 또는 실패를 유발하는 OS 구성 변경 사항 해결](resolving-os-configuration-changes.md) # 클러스터를 생성하려는 경우 AWS ParallelCluster 버전 3.5.0 이상을 사용하여 클러스터를 생성하고를 로 `--rollback-on-failure` 설정하여 클러스터 생성에 실패한 경우 [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md) CLI 명령을 `false`사용하여 상태 및 실패 정보를 가져옵니다. 이 경우 `pcluster describe-cluster` 출력의 예상 `clusterStatus`은 `CREATE_FAILED`입니다. `failureCode` 및 `failureReason`을 찾으려면 출력의 `failures` 섹션을 확인하세요. 그 후 다음 섹션에서 일치하는 `failureCode`를 찾아 추가 문제 해결 도움말을 찾아보세요. 자세한 내용은 [`pcluster describe-cluster`](pcluster.describe-cluster-v3.md) 항목을 참조하세요. 다음 섹션에서는 헤드 노드의 로그(예: `/var/log/cfn-init.log` 및 `/var/log/chef-client.log` 파일)를 확인하는 것이 좋습니다. AWS ParallelCluster 로그 및 로그를 보는 방법에 대한 자세한 내용은 [디버깅을 위한 키 로그](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) 및 섹션을 참조하세요[로그 검색 및 보존](troubleshooting-v3-get-logs.md). 가 없는 경우 CloudFormation 콘솔로 `failureCode`이동하여 클러스터 스택을 확인합니다. `HeadNodeWaitCondition` 또는 다른 리소스의 실패에 대해 알아보려면 `Status Reason`에서 추가 실패 상세 정보를 확인하세요. 자세한 내용은 [에서 CloudFormation 이벤트 보기 `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events) 항목을 참조하세요. 헤드 노드의 `/var/log/cfn-init.log` 및 `/var/log/chef-client.log` 파일을 확인합니다. 헤드 노드 생성 실패로 인해 클러스터 생성에 실패하고 클러스터 로그를 클러스터 로그 그룹에서 사용할 수 없는 경우 실패 시 클러스터를 유지하고 `--rollback-on-failure` =를 지정`True`하고 헤드 노드 자체 내에서 로그를 검색해야 합니다. ## `failureCode`가 `OnNodeConfiguredExecutionFailure`일 시 + **왜 실패했나요?** 구성 내 헤드 노드 섹션의 `OnNodeConfigured`에 클러스터를 생성하기 위한 사용자 지정 스크립트를 제공했습니다. 하지만 사용자 지정 스크립트가 실행되지 않았습니다. + **해결 방법은?** `/var/log/cfn-init.log` 파일을 확인하여 실패에 대해 자세히 알아보고 사용자 지정 스크립트에서 문제를 해결하는 방법을 알아보세요. 이 로그의 끝부분에서 `Running command runpostinstall` 메시지 뒤에 `OnNodeConfigured` 스크립트와 관련된 실행 정보가 표시될 수 있습니다. ## `failureCode`가 `OnNodeConfiguredDownloadFailure`일 시 + **왜 실패했나요?** 구성 내 헤드 노드 섹션의 `OnNodeConfigured`에 클러스터를 생성하기 위한 사용자 지정 스크립트를 제공했습니다. 하지만 사용자 지정 스크립트가 다운로드되지 않았습니다. + **해결 방법은?** URL이 유효하고 액세스가 올바르게 구성되어 있는지 확인하세요. 사용자 지정 부트스트랩 스크립트의 구성에 대한 자세한 내용은 [사용자 지정 부트스트랩 작업](custom-bootstrap-actions-v3.md) 항목을 참조하세요. `/var/log/cfn-init.log` 파일을 확인하세요. 이 로그의 끝부분에서 `Running command runpostinstall` 메시지 다음에 다운로드를 포함한 `OnNodeConfigured` 스크립트 처리와 관련된 실행 정보가 표시될 수 있습니다. ## `failureCode`가 `OnNodeConfiguredFailure`일 시 + **왜 실패했나요?** 구성 내 헤드 노드 섹션의 `OnNodeConfigured`에 클러스터를 생성하기 위한 사용자 지정 스크립트를 제공했습니다. 하지만 클러스터 배포에서 사용자 지정 스크립트 사용이 실패했습니다. 즉각적인 원인을 확인할 수 없으며 추가 조사가 필요합니다. + **해결 방법은?** `/var/log/cfn-init.log` 파일을 확인하세요. 이 로그의 끝부분에서 `Running command runpostinstall` 메시지 뒤에 `OnNodeConfigured` 스크립트 처리와 관련된 실행 정보가 표시될 수 있습니다. ## `failureCode`가 `OnNodeStartExecutionFailure`일 시 + **왜 실패했나요?** 구성 내 헤드 노드 섹션의 `OnNodeStart`에 클러스터를 생성하기 위한 사용자 지정 스크립트를 제공했습니다. 하지만 사용자 지정 스크립트가 실행되지 않았습니다. + **해결 방법은?** `/var/log/cfn-init.log` 파일을 확인하여 실패에 대해 자세히 알아보고 사용자 지정 스크립트에서 문제를 해결하는 방법을 알아보세요. 이 로그의 끝부분에서 `Running command runpreinstall` 메시지 뒤에 `OnNodeStart` 스크립트와 관련된 실행 정보가 표시될 수 있습니다. ## `failureCode`가 `OnNodeStartDownloadFailure`일 시 + **왜 실패했나요?** 구성 내 헤드 노드 섹션의 `OnNodeStart`에 클러스터를 생성하기 위한 사용자 지정 스크립트를 제공했습니다. 하지만 사용자 지정 스크립트가 다운로드되지 않았습니다. + **해결 방법은?** URL이 유효하고 액세스가 올바르게 구성되어 있는지 확인하세요. 사용자 지정 부트스트랩 스크립트의 구성에 대한 자세한 내용은 [사용자 지정 부트스트랩 작업](custom-bootstrap-actions-v3.md) 항목을 참조하세요. `/var/log/cfn-init.log` 파일을 확인하세요. 이 로그의 끝부분에서 `Running command runpreinstall` 메시지 다음에 다운로드를 포함한 `OnNodeStart` 스크립트 처리와 관련된 실행 정보가 표시될 수 있습니다. ## `failureCode`가 `OnNodeStartFailure`일 시 + **왜 실패했나요?** 구성 내 헤드 노드 섹션의 `OnNodeStart`에 클러스터를 생성하기 위한 사용자 지정 스크립트를 제공했습니다. 하지만 클러스터 배포에서 사용자 지정 스크립트 사용이 실패했습니다. 즉각적인 원인을 확인할 수 없으며 추가 조사가 필요합니다. + **해결 방법은?** `/var/log/cfn-init.log` 파일을 확인하세요. 이 로그의 끝부분에서 `Running command runpreinstall` 메시지 뒤에 `OnNodeStart` 스크립트 처리와 관련된 실행 정보가 표시될 수 있습니다. ## `failureCode`가 `EbsMountFailure`일 시 + **왜 실패했나요?** 클러스터 구성에 정의된 EBS 볼륨이 탑재되지 못했습니다. + **해결 방법은?** `/var/log/chef-client.log` 파일에서 실패 세부 정보를 확인하세요. ## `failureCode`가 `EfsMountFailure`일 시 + **왜 실패했나요?** 클러스터 구성에 정의된 Amazon EFS 볼륨이 탑재되지 못했습니다. + **해결 방법은?** 기존 Amazon EFS 파일 시스템을 정의한 경우 클러스터와 파일 시스템 간에 트래픽이 허용되는지 확인하세요. 자세한 내용은 [`SharedStorage`](SharedStorage-v3.md)/[`EfsSettings`](SharedStorage-v3.md#SharedStorage-v3-EfsSettings)/[`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId)를 참조하세요. `/var/log/chef-client.log` 파일에서 실패 세부 정보를 확인하세요. ## `failureCode`가 `FsxMountFailure`일 시 + **왜 실패했나요?** 클러스터 구성에 정의된 Amazon FSx 파일 시스템이 탑재되지 못했습니다. + **해결 방법은?** 기존 Amazon FSx 파일 시스템을 정의한 경우 클러스터와 파일 시스템 간에 트래픽이 허용되는지 확인하세요. 자세한 내용은 [`SharedStorage`](SharedStorage-v3.md)/[`FsxLustreSettings`](SharedStorage-v3.md#SharedStorage-v3-FsxLustreSettings)/[`FileSystemId`](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId)를 참조하세요. `/var/log/chef-client.log` 파일에서 실패 세부 정보를 확인하세요. ## `failureCode`가 `RaidMountFailure`일 시 + **왜 실패했나요?** 클러스터 구성에 정의된 RAID 볼륨이 탑재되지 못했습니다. + **해결 방법은?** `/var/log/chef-client.log` 파일에서 실패 세부 정보를 확인하세요. ## `failureCode`가 `AmiVersionMismatch`일 시 + **왜 실패했나요?** 사용자 지정 AMI를 생성하는 데 사용되는 AWS ParallelCluster 버전은 클러스터를 구성하는 데 사용되는 AWS ParallelCluster 버전과 다릅니다. CloudFormation 콘솔에서 클러스터 CloudFormation 스택 세부 정보를 확인하고에서 AWS ParallelCluster 버전 및 AMI에 `Status Reason` 대한 추가 세부 정보를 `HeadNodeWaitCondition` 확인합니다. 자세한 내용은 [에서 CloudFormation 이벤트 보기 `CREATE_FAILED`](troubleshooting-v3-cluster-deployment.md#troubleshooting-v3-cluster-deployment-events) 단원을 참조하십시오. + **해결 방법은?** 사용자 지정 AMI를 생성하는 데 사용되는 AWS ParallelCluster 버전이 클러스터를 구성하는 데 사용되는 AWS ParallelCluster 버전과 동일한지 확인합니다. 사용자 지정 AMI 버전 또는 `pcluster` CLI 버전을 변경하여 동일하게 만들 수 있습니다. ## `failureCode`가 `InvalidAmi`일 시 + **왜 실패했나요?** 사용자 지정 AMI는를 사용하여 빌드되지 않았으므로 유효하지 않습니다 AWS ParallelCluster. + **해결 방법은?** `pcluster build-image` 명령을 사용하여 AMI를 상위 이미지로 만들어 AMI를 생성합니다. 자세한 내용은 [`pcluster build-image`](pcluster.build-image-v3.md) 항목을 참조하세요. ## `failureCode`가 `HeadNodeBootstrapFailure`이며 `failureReason`이 헤드 노드 설정에 실패했습니다. + **왜 실패했나요?** 즉각적인 원인을 확인할 수 없으며 추가 조사가 필요합니다. 예를 들어 클러스터가 보호 상태일 수 있는데, 이는 정적 컴퓨팅 플릿을 프로비저닝하지 못했기 때문일 수 있습니다. + **해결 방법은?** `/var/log/chef-client.log.` 파일에서 실패 세부 정보를 확인하세요. **참고** `RuntimeError` 예외 `Cluster state has been set to PROTECTED mode due to failures detected in static node provisioning`가 표시되면 클러스터가 보호 상태인 것입니다. 자세한 내용은 [보호 모드를 디버깅하는 방법](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3) 항목을 참조하세요. ## `failureCode`가 `HeadNodeBootstrapFailure`이며 `failureReason`이 클러스터 생성 시간이 초과되었습니다. + **왜 실패했나요?** 기본적으로 클러스터 생성을 완료하는 데 걸리는 시간 제한은 30분입니다. 클러스터 생성이 이 기간 내에 완료되지 않으면 시간 초과 오류와 함께 클러스터 생성이 실패합니다. 여러 가지 이유로 클러스터 생성 시간이 초과될 수 있습니다. 예를 들어 헤드 노드 생성 실패, 네트워크 문제, 헤드 노드에서 실행하는 데 너무 오래 걸리는 사용자 지정 스크립트, 컴퓨팅 노드에서 실행되는 사용자 지정 스크립트의 오류 또는 컴퓨팅 노드 프로비저닝의 긴 대기 시간으로 인해 시간 초과 실패가 발생할 수 있습니다. 즉각적인 원인을 확인할 수 없으며 추가 조사가 필요합니다. + **해결 방법은?** `/var/log/cfn-init.log` 및 `/var/log/chef-client.log` 파일에서 실패 세부 정보를 확인하세요. AWS ParallelCluster 로그 및 로그 가져오기 방법에 대한 자세한 내용은 [디버깅을 위한 키 로그](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-key-logs) 및 [로그 검색 및 보존](troubleshooting-v3-get-logs.md)을 참조하세요. 이러한 로그에서 다음을 발견할 수 있습니다. + **`chef-client.log` 끝부분에 `Waiting for static fleet capacity provisioning`가 표시되는 경우** 이는 정적 노드의 전원이 켜질 때까지 기다릴 때 클러스터 생성 시간이 초과되었음을 나타냅니다. 자세한 내용은 [컴퓨팅 노드 초기화 오류가 표시되는 경우](troubleshooting-fc-v3-compute-node-initialization-v3.md) 항목을 참조하세요. + **`cfn-init.log` 끝부분에 `OnNodeConfigured` 또는 `OnNodeStart` 노드 스크립트가 종료되지 않았다고 표시되는 경우** 이는 `OnNodeConfigured` 또는 `OnNodeStart` 사용자 지정 스크립트를 실행하는 데 시간이 오래 걸리고 시간 초과 오류가 발생했음을 나타냅니다. 사용자 지정 스크립트에서 오랜 시간 실행으로 이어질 수 있는 문제가 있는지 확인합니다. 사용자 지정 스크립트를 실행하는 데 시간이 오래 걸리는 경우 다음 예와 같이 클러스터 구성 파일에 `DevSettings` 섹션을 추가하여 제한 시간을 변경하는 것이 좋습니다. ``` DevSettings: Timeouts: HeadNodeBootstrapTimeout: 1800 # default setting: 1800 seconds ``` + **로그를 찾을 수 없거나 헤드 노드가 성공적으로 생성되지 않았습니다.** 헤드 노드가 성공적으로 생성되지 않아 로그를 찾을 수 없을 수 있습니다. 이 경우 CloudFormation 스택 이벤트와 헤드 노드 콘솔 로그를 확인하여 추가 장애 세부 정보를 얻을 수 있습니다. Amazon EC2 콘솔을 통해 또는 다음 Amazon EC2 CLI 명령을 실행하여 헤드 노드 콘솔 로그를 검색할 수 있습니다. ``` aws ec2 get-console-output --instance-id HEAD_NODE_INSTANCE_ID --output text ``` ## `failureCode`가 `HeadNodeBootstrapFailure`이며 `failureReason`이 헤드 노드 부트스트랩에 실패했습니다. + **왜 실패했나요?** 즉각적인 원인을 확인할 수 없으며 추가 조사가 필요합니다. + **해결 방법은?** `/var/log/cfn-init.log` 및 `/var/log/chef-client.log` 파일을 확인합니다. ## `failureCode`가 `ResourceCreationFailure`일 시 + **왜 실패했나요?** 클러스터 생성 프로세스 중 일부 리소스 생성이 실패했습니다. 실패는 다양한 이유로 발생할 수 있습니다. 예를 들어 용량 문제나 잘못 구성된 IAM 정책으로 인해 리소스 생성 실패가 발생할 수 있습니다. + **해결 방법은?** CloudFormation 콘솔에서 클러스터 스택을 보고 추가 리소스 생성 실패 세부 정보를 확인합니다. ## `failureCode`가 `ClusterCreationFailure`일 시 + **왜 실패했나요?** 즉각적인 원인을 확인할 수 없으며 추가 조사가 필요합니다. + **해결 방법은?** CloudFormation 콘솔에서 클러스터 스택을 보고 추가 실패 상세 정보를 찾기 위해 `Status Reason`에서 `HeadNodeWaitCondition`을 확인하세요. `/var/log/cfn-init.log` 및 `/var/log/chef-client.log` 파일을 확인합니다. ## CloudFormation 스택에서 `WaitCondition timed out...`가 표시되는 경우 자세한 내용은 [`failureCode`가 `HeadNodeBootstrapFailure`이며 `failureReason`이 클러스터 생성 시간이 초과되었습니다.](#create-cluster-head-node-bootstrap-timeout-failure-v3) 항목을 참조하세요. ## CloudFormation 스택에서 `Resource creation cancelled`가 표시되는 경우 자세한 내용은 [`failureCode`가 `ResourceCreationFailure`일 시](#create-cluster-resource-creation-failure-v3) 단원을 참조하십시오. ## CloudFormation 스택에서 `Failed to run cfn-init...` 또는 기타 오류 표시 추가 실패 세부 정보는 `/var/log/cfn-init.log` 및 `/var/log/chef-client.log`를 확인하세요. ## `INFO: Waiting for static fleet capacity provisioning`로 끝나는 `chef-client.log`이 표시되는 경우 이는 정적 노드의 전원이 켜질 때까지 기다릴 때 발생하는 클러스터 생성 타임아웃과 관련이 있습니다. 자세한 내용은 [컴퓨팅 노드 초기화 오류가 표시되는 경우](troubleshooting-fc-v3-compute-node-initialization-v3.md) 항목을 참조하세요. ## `Failed to run preinstall or postinstall in cfn-init.log`가 표시되는 경우 클러스터 구성 `HeadNode` 섹션에 `OnNodeConfigured` 또는 `OnNodeStart` 스크립트가 있습니다. 스크립트가 제대로 작동하지 않습니다. `/var/log/cfn-init.log` 파일에서 사용자 지정 스크립트 오류 세부 정보를 확인하세요. ## CloudFormation 스택에서 `This AMI was created with xxx, but is trying to be used with xxx...`가 표시되는 경우 자세한 내용은 [`failureCode`가 `AmiVersionMismatch`일 시](#create-cluster-ami-version-mismatch-v3) 항목을 참조하세요. ## CloudFormation 스택에서 `This AMI was not baked by AWS ParallelCluster...`가 표시되는 경우 자세한 내용은 [`failureCode`가 `InvalidAmi`일 시](#create-cluster-invalid-ami-v3) 항목을 참조하세요. ## `pcluster create-cluster` 명령이 로컬에서 실행되지 않는 경우 로컬 파일 시스템의 `~/.parallelcluster/pcluster-cli.log`에서 오류 세부 정보를 확인하세요. ## 추가 지원 [클러스터 배포 문제 해결](troubleshooting-v3-cluster-deployment.md)의 문제 해결 지침을 따르세요. 시나리오가 [GitHub의에 있는 GitHub 알려진 문제](https://github.com/aws/aws-parallelcluster/wiki) AWS ParallelCluster 에서 다루어지는지 확인합니다. GitHub # 작업을 실행하려는 경우 다음 섹션에서는 작업 실행 중에 문제가 발생할 경우 가능한 문제 해결 솔루션을 제공합니다. ## `srun` 대화형 작업이 `srun: error: fwd_tree_thread: can't find address for , check slurm.conf` 오류가 발생하여 실패합니다. + **왜 실패했나요?** `srun` 명령을 실행하여 작업을 제출한 다음 업데이트가 완료된 후 Slurm 대몬(daemon)을 다시 시작하지 않고 `pcluster update-cluster` 명령을 사용하여 대기열 크기를 늘렸습니다. Slurm은 통신을 최적화하기 위해 Slurm 대몬(daemon)을 트리 계층으로 구성합니다. 이 계층 구조는 대몬(daemon)이 시작될 때만 업데이트됩니다. `srun`를 사용하여 작업을 시작한 다음 `pcluster update-cluster` 명령을 실행하여 대기열 크기를 늘린다고 가정해 보겠습니다. 업데이트의 일부로 새 컴퓨팅 노드가 시작됩니다. 그런 다음 새 컴퓨팅 노드 중 하나에 작업을 Slurm 대기열에 추가합니다. 이 경우 Slurm 대몬(daemon)과 `srun`는 모두 새 컴퓨팅 노드를 감지하지 못합니다. `srun`은 새 노드를 감지하지 못하므로 오류가 반환됩니다. + **해결 방법은?** 모든 컴퓨팅 노드에서 Slurm 대몬(daemon)을 재시작한 다음 `srun`를 사용하여 작업을 제출하세요. 컴퓨팅 노드를 재시작하는 `scontrol reboot` 명령을 실행하여 Slurm 대몬(daemon) 재시작을 예약할 수 있습니다. 자세한 내용은 Slurm 설명서의 [scontrol reboot](https://slurm.schedmd.com/scontrol.html#OPT_reboot)를 참조하세요. 대응하는 `systemd` 서비스의 재시작을 요청하여 컴퓨팅 노드에서 Slurm 대몬(daemon)을 수동으로 재시작할 수도 있습니다. ## 작업이 `squeue` 명령을 실행한 `CF` 상태에서 멈췄습니다. 동적 노드의 전원을 켤 때 발생하는 문제일 수 있습니다. 자세한 내용은 [컴퓨팅 노드 초기화 오류가 표시되는 경우](troubleshooting-fc-v3-compute-node-initialization-v3.md) 항목을 참조하세요. ## 대규모 작업을 실행한 후 `nfsd: too many open connections, consider increasing the number of threads in /var/log/messages`가 표시된 경우 네트워크로 연결된 파일 시스템에서 네트워크 제한에 도달하면 I/O 대기 시간도 늘어납니다. 네트워크가 네트워킹 및 I/O 지표 모두에 대한 데이터를 쓰는 데 사용되므로 소프트 록업이 발생할 수 있습니다. 5세대 인스턴스에서는 패킷 카운터를 노출하기 위해 ENA 드라이버가 사용됩니다. 이러한 카운터는 네트워크가 인스턴스 대역폭 제한에 도달할 AWS 때에 의해 형성된 패킷 수를 계산합니다. 이러한 카운터가 0보다 큰지 확인할 수 있습니다. 0보다 크다면 대역폭 한도를 초과한 것입니다. `ethtool -S eth0 | grep exceeded`를 실행하여 이러한 카운터를 볼 수 있습니다. 네트워크 한도를 초과하는 것은 NFS 연결을 너무 많이 지원한 결과인 경우가 많습니다. 이는 네트워크 한도에 도달하거나 초과할 때 가장 먼저 확인해야 할 사항 중 하나입니다. 예를 들어 다음 출력은 누락된 패키지를 표시합니다. ``` $ ethtool -S eth0 | grep exceeded bw_in_allowance_exceeded: 38750610 bw_out_allowance_exceeded: 1165693 pps_allowance_exceeded: 103 conntrack_allowance_exceeded: 0 linklocal_allowance_exceeded: 0 ``` 이 메시지가 표시되지 않도록 헤드 노드 인스턴스 유형을 성능이 더 좋은 인스턴스 유형으로 변경하는 것이 좋습니다. 데이터 스토리지를 NFS 공유로 내보내지 않는 공유 스토리지 파일 시스템(예: Amazon EFS 또는 Amazon FSx)으로 옮기는 것을 고려해 보세요. 자세한 내용은 [공유 스토리지](shared-storage-quotas-integration-v3.md) 및 GitHub의 AWS ParallelCluster Wiki [모범 사례를](https://github.com/aws/aws-parallelcluster/wiki/Best-Practices) 참조하세요. ## MPI 작업 실행 ### 디버그 모드 활성화 OpenMPI 디버그 모드를 활성화하려면 [디버깅에 도움이 되는 Open MPI의 제어 기능](https://www-lb.open-mpi.org/faq/?category=debugging#debug-ompi-controls)을 참조하세요. IntelMPI 디버그 모드를 활성화하려면 [기타 환경 변수](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/other-environment-variables.html)를 참조하세요. ### 작업 출력에서 `MPI_ERRORS_ARE_FATAL` 및 `OPAL ERROR`이 표시되는 경우 이러한 오류 코드는 애플리케이션의 MPI 계층에서 가져온 것입니다. 애플리케이션에서 MPI 디버그 로그를 가져오는 방법은 [디버그 모드 활성화](#run-job-mpi-enable-v3) 항목을 참조하세요. 이 오류가 발생하는 원인은 응용 프로그램이 OpenMPI와 같은 특정 MPI 구현용으로 컴파일되었고 IntelMPI와 같은 다른 MPI 구현을 사용하여 응용 프로그램을 실행하려고 하기 때문일 수 있습니다. 동일한 MPI 구현으로 애플리케이션을 컴파일하고 실행하고 있는지 확인하세요. ### 관리형 DNS를 비활성화한 상태에서 `mpirun` 사용 [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Dns](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Dns)/[DisableManagedDNS](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-DisableManagedDns) 및 [UseEc2Hostnames](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames)을 `true`로 설정하여 생성한 클러스터의 경우 DNS에서 Slurm 노드 이름을 확인하지 않습니다. Slurm은 MPI 프로세스가 `nodenames` 활성화되지 않은 경우 및 Slurm 컨텍스트에서 MPI 작업이 실행되는 경우 MPI 프로세스를 부트스트랩할 수 있습니다. [Slurm MPI 사용 설명서](https://slurm.schedmd.com/mpi_guide.html)의 지침에 따라 Slurm으로 MPI 작업을 실행하는 것이 좋습니다. # 클러스터를 업데이트하려는 경우 다음 섹션에서는 클러스터를 업데이트하는 동안 발생할 수 있는 문제에 대한 가능한 문제 해결 솔루션을 제공합니다. ## `pcluster update-cluster` 명령이 로컬에서 실행되지 않습니다. 로컬 파일 시스템의 `~/.parallelcluster/pcluster-cli.log`에서 오류 세부 정보를 확인하세요. ## `pcluster describe-cluster` 명령으로 `clusterStatus`가 `UPDATE_FAILED`로 표시되는 경우 ### 근본 원인 장애의 근본 원인을 식별하기 위해 시작점은 헤드 노드`/var/log/chef-client.log`에서 클러스터 스택 이벤트 및를 살펴보는 것입니다. 가능한 원인은 하나 이상의 클러스터 노드가 업데이트를 적용하지 않았기 때문입니다. 로그`/var/log/chef-client.log`에서를 찾아 헤드 노드의에서 업데이트하지 못한 노드 목록을 검색할 수 `Check cluster readiness` 있습니다. [GitHub 알려진 문제에](https://github.com/aws/aws-parallelcluster/wiki) 문제가 언급되어 있는지 확인합니다. AWS ParallelCluster GitHub ### 방지 클러스터에 있는 하나 이상의 노드가 업데이트를 성공적으로 적용하지 못하면 클러스터 업데이트가 실패할 수 있습니다. 클러스터 업데이트 실패 위험을 줄이려면 업데이트를 시작하기 전에 손상된 노드를 종료하는 것이 좋습니다. 중단될 수 있는 노드의 예로는 예상 에픽 지속 시간보다 오래 `COMPLETING` 상태로 멈춘 컴퓨팅 노드가 있습니다. 이러한 노드를 감지하려면 다음 명령을 실행하여 필요에 맞게 `threshold` 값을 조정할 수 있습니다(값은 에픽에 대해 예상되는 최대 기간보다 커야 함). ``` $ scontrol show nodes --json | jq -r --argjson threshold 60 ' .nodes[] | select(.state | index("COMPLETING")) | select((now - .last_busy.number) > $threshold) | .name ' ``` ### 복구 중 업데이트가 실패하면 롤백은 클러스터의 상태를 복구할 것으로 예상되는 메커니즘입니다. 롤백에 실패한 경우 클러스터 상태는 결정적이지 않습니다. 이 경우 실패의 증폭을 방지하기 위해가 `clustermgtd` 중지되었을 수 있습니다. 헤드 노드에서 다음 명령을 실행하여 시작하는 것이 좋습니다. Python 버전을 버전과 함께 제공되는 AWS ParallelCluster 버전으로 조정합니다. ``` $ /opt/parallelcluster/pyenv/versions/3.12.11/envs/cookbook_virtualenv/bin/supervisorctl start clustermgtd ``` ## 클러스터 업데이트 제한 시간이 초과되었습니다. `cfn-hup`가 실행되지 않는 것과 관련된 문제일 수 있습니다. `cfn-hup` 대몬(daemon)이 외부 원인으로 종료되면 자동으로 다시 시작되지 않습니다. `cfn-hup`가 실행되고 있지 않으면 클러스터 업데이트 중에 CloudFormation 스택이 예상대로 업데이트 프로세스를 시작하지만 헤드 노드에서 업데이트 절차가 활성화되지 않아 결국 스택 배포 시간이 초과됩니다. [`cfn-hup`이 실행 중이 아닐 때의 클러스터 업데이트 제한 시간 문제 해결](troubleshooting-v3-cluster-update-timeout.md)에서 자세한 내용을 참조하여 문제를 해결하세요. # 스토리지에 액세스하려는 경우 스토리지에 액세스하기 위한 문제 해결 팁에 대해 알아봅니다. ## 외부 Amazon FSx for Lustre 파일 시스템 사용 클러스터와 파일 시스템 간에 트래픽이 허용되는지 확인합니다. 파일 시스템은 포트 988, 1021, 1022 및 1023을 통한 인바운드 및 아웃바운드 TCP 트래픽을 허용하는 보안 그룹에 연결되어 있어야 합니다. 보안 그룹 설정에 대한 자세한 내용은 [FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-FsxLustreSettings-FileSystemId)를 참조하세요. ## 외부 Amazon Elastic File System 파일 시스템 사용 클러스터와 파일 시스템 간에 트래픽이 허용되는지 확인합니다. 파일 시스템은 포트 988, 1021, 1022 및 1023을 통한 인바운드 및 아웃바운드 TCP 트래픽을 허용하는 보안 그룹에 연결되어 있어야 합니다. 보안 그룹 설정에 대한 자세한 내용은 [FileSystemId](SharedStorage-v3.md#yaml-SharedStorage-EfsSettings-FileSystemId)를 참조하세요. # 클러스터를 삭제하려는 경우 클러스터를 삭제하는 동안 오류가 발생하면 다음 섹션에서 일반적인 시나리오에 대한 문제 해결 팁을 제공합니다. ## `pcluster delete-cluster` 명령이 로컬에서 실행되지 않습니다. 로컬 `~/.parallelcluster/pcluster-cli.log` 파일 시스템에서 파일을 확인합니다. ## 클러스터 스택 삭제에 실패했습니다. 클러스터 스택이 삭제되지 않는 경우 CloudFormation 스택 이벤트 메시지를 확인하세요. AWS ParallelCluster GitHub의 [GitHub 알려진 문제](https://github.com/aws/aws-parallelcluster/wiki)에 사용자가 겪은 문제가 실려 있는지 확인하세요. # AWS ParallelCluster API 스택 업그레이드 시도 AWS ParallelCluster API 스택을 업그레이드할 때 `UPDATE_FAILED`와 같은 오류가 발생하는 경우 GitHub의 [AWS ParallelCluster Wiki](https://github.com/aws/aws-parallelcluster/wiki)에서 **알려진 문제** 섹션의 솔루션을 확인하는 것이 좋습니다. 예를 들어, 가능한 한 가지 문제를 식별하고 완화 옵션을 제공하는 [ECR 리소스에 대한 ParallelCluster API 스택 업그레이드 실패](https://github.com/aws/aws-parallelcluster/wiki/(3.0.0-3.1.4)-ParallelCluster-API-Stack-Upgrade-Fails-for-ECR-resources)를 참조하세요. # 컴퓨팅 노드 초기화 오류가 표시되는 경우 다음 섹션에서는 컴퓨팅 노드 초기화에 오류가 발생할 때의 문제 해결 팁을 제공합니다. 여기에는 부트스트랩 오류, 로그 오류 확인, 그리고 특정 상황에 적용되는 시나리오가 없는 경우 참조해야 할 항목이 포함됩니다. **Topics** + [`clustermgtd.log`에서 `Node bootstrap error`가 표시되는 경우](compute-node-initialization-bootstrap-error-v3.md) + [온디맨드 용량 예약(ODCR) 또는 영역별 예약 인스턴스를 구성했습니다.](compute-node-initialization-odcr-v3.md) + [작업 실행 실패 시 `slurm_resume.log`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `An error occurred (VcpuLimitExceeded)`이 표시되는 경우](compute-node-initialization-vpc-limit-v3.md) + [작업 실행 실패 시 `slurm_resume.log`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `An error occurred (InsufficientInstanceCapacity)`이 표시되는 경우](compute-node-initialization-ice-failure-v3.md) + [노드가 `Reason (Code:InsufficientInstanceCapacity)...`으로 `DOWN` 상태로 표시되는 경우](compute-node-initialization-down-nodes-v3.md) + [`slurm_resume.log`에서 `cannot change locale (en_US.utf-8) because it has an invalid name`가 표시되는 경우](compute-node-initialization-locale-v3.md) + [이전 시나리오 중 어느 것도 제 상황에 적용되지 않습니다.](compute-node-initialization-not-found-v3.md) # `clustermgtd.log`에서 `Node bootstrap error`가 표시되는 경우 이 문제는 컴퓨팅 노드의 부트스트랩 실패와 관련이 있습니다. 클러스터 보호 모드 문제를 디버깅하는 방법에 대한 자세한 내용은 [보호 모드를 디버깅하는 방법](slurm-protected-mode-v3.md#slurm-protected-mode-debug-v3) 항목을 참조하세요. # 온디맨드 용량 예약(ODCR) 또는 영역별 예약 인스턴스를 구성했습니다. ## P4d, P4de 및 AWS Trainium(Trn)과 같이 여러 네트워크 인터페이스가 있는 인스턴스를 포함하는 ODCRs 클러스터 구성 파일에서 `HeadNode`가 퍼블릭 서브넷에 있고 컴퓨팅 노드가 프라이빗 서브넷에 있는지 확인합니다. ## ODCR이 대상으로 지정된 ODCR인 경우 ### [ODCR(온디맨드 용량 예약)로 인스턴스 시작](launch-instances-odcr-v3.md)에 나와 있는 지침을 따라 이미 `/opt/slurm/etc/pcluster/run_instances_overrides.json`를 설치했는데도 `Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'.`가 표시되는 경우 대상 ODCRs과 함께 AWS ParallelCluster 버전 3.1.1\$13.2.1을 사용하고 [실행 인스턴스 재정의 JSON 파일](launch-instances-odcr-v3.md)도 사용하는 경우 JSON 파일의 형식이 올바르지 않을 수 있습니다. `clustermgtd.log`에서 다음과 같은 오류가 발생할 수 있습니다. ``` Unable to read file '/opt/slurm/etc/pcluster/run_instances_overrides.json'. Using default: {} in /var/log/parallelcluster/clustermgtd. ``` 다음을 실행하여 JSON 파일 형식이 올바른지 확인합니다. ``` $ echo /opt/slurm/etc/pcluster/run_instances_overrides.json | jq ``` ### 클러스터 생성 실패 시 `clustermgtd.log`에서 또는 작업 실행 실패 시 `slurm_resume.log`에서 `Found RunInstances parameters override.`이 표시되는 경우 [실행 인스턴스 재정의 JSON 파일](launch-instances-odcr-v3.md)을 사용하는 경우 `/opt/slurm/etc/pcluster/run_instances_overrides.json` 파일에서 대기열 이름과 컴퓨팅 리소스 이름을 올바르게 설정했는지 확인하세요. ### 작업 실행 실패 시 `slurm_resume.log`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `An error occurred (InsufficientInstanceCapacity)`이 표시되는 경우 #### PG-ODCR(배치 그룹 ODCR) 사용 연결된 배치 그룹이 있는 ODCR을 만들 때는 구성 파일에 동일한 배치 그룹 이름을 사용해야 합니다. 클러스터 구성에서 대응하는 [배치 그룹 이름](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)을 설정합니다. #### 영역 예약 인스턴스 사용 클러스터 구성에서 `PlacementGroup`/`Enabled`를 `true`로와 함께 영역 예약 인스턴스를 사용하는 경우 다음과 같은 오류가 표시될 수 있습니다. ``` We currently do not have sufficient trn1.32xlarge capacity in the Availability Zone you requested (us-east-1d). Our system will be working on provisioning additional capacity. You can currently get trn1.32xlarge capacity by not specifying an Availability Zone in your request or choosing us-east-1a, us-east-1b, us-east-1c, us-east-1e, us-east-1f. ``` 영역 예약 인스턴스가 동일한 UC(또는 스파인)에 배치되지 않아 이러한 현상이 나타날 수 있으며, 배치 그룹을 사용할 때 용량 부족 오류(ICE)가 발생할 수 있습니다. 클러스터 구성에서 `PlacementGroup` 그룹 설정을 비활성화하여 클러스터가 인스턴스를 할당할 수 있는지 확인하면 이 경우를 확인할 수 있습니다. # 작업 실행 실패 시 `slurm_resume.log`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `An error occurred (VcpuLimitExceeded)`이 표시되는 경우 사용 중인 특정 Amazon EC2 인스턴스 유형에 대한 계정의 vCPU 한도를 확인하세요. vCPU가 0개 또는 요청한 것보다 더 적으면 한도 증가를 요청하세요. 현재 한도를 확인하고 새 한도를 요청하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 서비스 할당량](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)을 참조하세요. # 작업 실행 실패 시 `slurm_resume.log`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `An error occurred (InsufficientInstanceCapacity)`이 표시되는 경우 용량 부족 문제가 발생했습니다. [https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/)를 따라서 문제를 해결하세요. # 노드가 `Reason (Code:InsufficientInstanceCapacity)...`으로 `DOWN` 상태로 표시되는 경우 용량 부족 문제가 발생했습니다. [https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/)를 따라서 문제를 해결하세요. AWS ParallelCluster의 빠른 용량 부족 장애 조치 모드에 대한 자세한 내용은 섹션을 참조하세요[Slurm 클러스터 빠른 용량 부족 장애 조치](slurm-short-capacity-fail-mode-v3.md). # `slurm_resume.log`에서 `cannot change locale (en_US.utf-8) because it has an invalid name`가 표시되는 경우 `yum` 설치 프로세스에 실패하여 로케일 설정이 일관되지 않은 상태로 남아 있는 경우 이 문제가 발생할 수 있습니다. 예를 들어, 사용자가 설치 프로세스를 종료할 때 이러한 문제가 발생할 수 있습니다. **원인을 확인하려면 다음 작업을 수행합니다.** + `su - pcluster-admin`를 실행합니다. 쉘에 `cannot change locale...no such file or directory`과 같은 오류가 표시됩니다. + `localedef --list`를 실행합니다. 빈 목록을 반환하거나 기본 로케일을 포함하지 않습니다. + `yum history` 및 `yum history info #ID`를 사용하여 마지막 `yum` 명령을 확인합니다. 마지막 ID에 `Return-Code: Success`가 있나요? 마지막 ID에 `Return-Code: Success`가 없으면 설치 후 스크립트가 성공적으로 실행되지 않았을 수 있습니다. 문제를 해결하려면 `yum reinstall glibc-all-langpacks`를 사용하여 로케일을 다시 빌드해 보세요. 다시 빌드한 후에 문제가 해결됐으면 `su - pcluster-admin`가 오류나 경고를 표시하지 않습니다. # 이전 시나리오 중 어느 것도 제 상황에 적용되지 않습니다. 컴퓨팅 노드 초기화 문제를 해결하려면 [노드 초기화 문제 해결](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init)을 참조하세요. 시나리오가 [GitHub의에 있는 GitHub 알려진 문제](https://github.com/aws/aws-parallelcluster/wiki) AWS ParallelCluster 에서 다루어지는지 확인합니다. GitHub # 클러스터 상태 지표 문제 해결 클러스터 상태 지표는 AWS ParallelCluster 버전 3.6.0부터 AWS ParallelCluster Amazon CloudWatch 대시보드에 추가됩니다. 다음 섹션에서는 대시보드 상태 지표와 문제 해결을 위해 취할 수 있는 조치에 대해 알아볼 수 있습니다. **Topics** + [**인스턴스 프로비저닝 오류** 그래프 참조](#troubleshooting-v3-cluster-health-metrics-instance-provisioning) + [**비정상 인스턴스 오류** 그래프 보기](#troubleshooting-v3-cluster-health-metrics-unhealthy-instance) + [**컴퓨팅 플릿 유휴 시간** 그래프 보기](#troubleshooting-v3-cluster-health-metrics-idle-time-errors) ## **인스턴스 프로비저닝 오류** 그래프 참조 `Instance Provisioning Errors` 그래프에 0이 아닌 값이 표시되면 slurm 노드를 지원하는 Amazon EC2 인스턴스가 `CreateFleet` 또는 `RunInstance` API에서 시작되지 못한 것입니다. ### `IAMPolicyErrors` 확인 + **어떻게 된 걸까요?** 권한이 충분하지 않고 오류 코드 `UnauthorizedOperation`이 발생하여 여러 인스턴스가 시작되지 못했습니다. + **해결 방법은?** 사용자 지정 [`InstanceRole`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceRole) 또는 [`InstanceProfile`](HeadNode-v3.md#yaml-HeadNode-Iam-InstanceProfile)을 구성한 경우, IAM 정책을 확인하고 올바른 보안 인증 정보를 사용하고 있는지 확인하세요. `clustermgtd` 파일에서 정적 노드 오류 세부 정보를 확인하세요. `slurm_resume.log` 파일에서 동적 노드 오류 세부 정보를 확인하세요. 세부 정보를 사용하여 추가해야 하는 누락된 권한에 대해 자세히 알아보세요. ### `VcpuLimitErrors` 확인 + **어떻게 된 걸까요?** AWS ParallelCluster 클러스터 컴퓨팅 노드에 대해 구성한 특정 Amazon EC2 인스턴스 유형에 AWS 계정 대한의 vCPU 제한에 도달했기 때문에에서 인스턴스를 시작하지 못했습니다. + **해결 방법은?** 정적 노드의 경우 `clustermgtd` 파일에서 `VcpuLimitExceeded` 오류를 확인하고, 추가 세부 정보를 보려면 동적 노드용 `slurm_resume.log` 파일을 확인하세요. 이 문제를 해결하려면 vCPU 한도 증가를 요청할 수 있습니다. 현재 한도를 확인하고 새 한도를 요청하는 방법에 대한 자세한 내용은 *Linux 인스턴스용 Amazon Elastic Compute Cloud 사용 설명서*의 [Amazon Elastic Compute Cloud 서비스 할당량](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-resource-limits.html)을 참조하세요. ### `VolumeLimitErrors` 확인 + **어떻게 된 걸까요?** 에 대한 Amazon EBS 볼륨 한도에 도달 AWS 계정했으며 오류 코드 `InsufficientVolumeCapacity` 또는 로 인스턴스를 시작할 AWS ParallelCluster 수 없습니다`VolumeLimitExceeded`. + **해결 방법은?** `clustermgtd` 파일에 정적 노드가 있는지 확인하고 `slurm_resume.log` 파일에 동적 노드가 있는지 확인하여 추가 볼륨 제한 세부 정보를 확인하세요. 이 문제를 해결하려면 다른를 사용하거나 AWS 리전기존 볼륨을 AWS 정리하거나 지원 센터에 문의하여 Amazon EBS 볼륨 한도 증가 요청을 제출할 수 있습니다. ### `InsufficientCapacityErrors` 확인 + **어떻게 된 걸까요?** AWS ParallelCluster 에는 Amazon EC2 인스턴스를 백 노드로 시작하는 데 충분한 용량이 없습니다. + **해결 방법은?** `clustermgtd` 파일에서 정적 노드가 있는지 확인하고, `slurm_resume.log` 파일에 동적 노드가 있는지 확인하여 용량 부족 오류 세부 정보를 확인하세요. 문제를 해결하려면 [https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-insufficient-capacity-errors/) 지침을 따르세요. ### `OtherInstanceLaunchFailures` + **어떻게 된 걸까요?** 컴퓨팅 노드를 지원하는 Amazon EC2 인스턴스가 `CreateFleet` 또는 `RunInstance` API로 시작되지 않았습니다. + **해결 방법은?** `clustermgtd` 파일에서 정적 노드가 있는지 확인하고, `slurm_resume.log` 파일에 동적 노드가 있는지 확인하여 오류 세부 정보를 확인하세요. ## **비정상 인스턴스 오류** 그래프 보기 + **어떻게 된 걸까요?** 여러 컴퓨팅 인스턴스가 시작되었지만 나중에 비정상으로 종료되었습니다. + **해결 방법은?** 비정상 노드 문제 해결에 대한 자세한 내용은 [예상치 못한 노드 교체 및 종료 문제 해결****](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-unexpected-node-replacements-and-terminations) 섹션을 참조하세요. ### `InstanceBootstrapTimeoutError` 확인 + **어떻게 된 걸까요?** 인스턴스는 `resume_timeout`(동적 노드의 경우) 또는 `node_replacement_timeout`(정적 노드의 경우) 내에서 클러스터에 조인할 수 없습니다. 이는 네트워크가 컴퓨팅 노드에 맞게 올바르게 구성되지 않은 경우 발생할 수 있으며, 컴퓨팅 노드에서 실행되는 사용자 지정 스크립트를 완료하는 데 시간이 너무 오래 걸리는 경우 발생할 수 있습니다. + **해결 방법은?** 동적 노드의 경우 `clustermgtd` 로그(`/var/log/parallelcluster/clustermgtd`)에서 컴퓨팅 노드 IP 주소 및 다음과 같은 오류를 확인합니다. ``` Node bootstrap error: Resume timeout expires for node ``` 정적 노드의 경우 `clustermgtd` 로그(`/var/log/parallelcluster/clustermgtd`) 에서 컴퓨팅 노드 IP 주소 및 다음과 같은 오류를 확인합니다. ``` Node bootstrap error: Replacement timeout expires for node ... in replacement. ``` 더 자세한 내용은 `/var/log/cloud-init-output.log` 파일에서 오류를 확인하세요. `clustermgtd` 및 `slurm_resume` 로그 파일에서 문제가 있는 컴퓨팅 노드 IP 주소를 검색할 수 있습니다. ### `EC2HealthCheckErrors` 확인 + **어떻게 된 걸까요?** 인스턴스가 Amazon EC2 상태 확인에 실패했습니다. + **해결 방법은?** 이 문제를 해결하는 방법에 대한 자세한 내용은 [상태 확인에 실패한 인스턴스 문제 해결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)을 참조하세요. ### `ScheduledEventHealthCheckErrors` 확인 + **어떻게 된 걸까요?** 인스턴스가 Amazon EC2 예약 이벤트 상태 확인에 실패했으며 비정상입니다. + **해결 방법은?** 이 문제를 해결하는 방법에 대한 자세한 내용은 [인스턴스의 예약 이벤트](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html)를 참조하세요. ### `NoCorrespondingInstanceErrors` 확인 + **어떻게 된 걸까요?** AWS ParallelCluster 가 노드를 지원하는 인스턴스를 찾을 수 없습니다. 부트스트랩 작업 중에 노드가 자체 종료되었을 수 있습니다. [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)/[`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)\$1[`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured) 스크립트 또는 네트워크 오류가 `NoCorrespondingInstanceErrors`를 발생시킬 수 있습니다. + **해결 방법은?** 자세한 내용은 컴퓨팅 노드의 `/var/log/cloud-init-output.log`을 확인하세요. ## **컴퓨팅 플릿 유휴 시간** 그래프 보기 ### `MaxDynamicNodeIdleTime`이 **유휴 시간 스케일다운** 임계값보다 훨씬 긴 것으로 확인됨 + **어떻게 된 걸까요?** 인스턴스가 제대로 종료되지 않습니다. `MaxDynamicNodeIdleTime`은 Amazon EC2 인스턴스가 지원하는 동적 노드가 유휴 상태인 최대 시간을 초 단위로 표시합니다. **유휴 시간 스케일다운** 임계값은 클러스터 구성 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 파라미터에서 파생됩니다. 컴퓨팅 노드가 유휴 **시간 스케일 다운 초 이상 유휴** 상태인 경우는 노드의 Slurm 전원을 끄고 백업 인스턴스를 AWS ParallelCluster 종료합니다. 이 경우, 무언가 인스턴스 종료를 방해하고 있습니다. + **해결 방법은?** 이 문제에 대한 자세한 내용은 [규모 조정 문제 해결](troubleshooting-v3-scaling-issues.md)에서 [문제가 있는 인스턴스 및 노드 교체, 종료 또는 전원 끄기****](troubleshooting-v3-scaling-issues.md#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)를 참조하세요. # 클러스터 배포 문제 해결 클러스터 생성에 실패하고 스택 생성을 롤백하는 경우 로그 파일을 살펴보고 문제를 진단할 수 있습니다. 실패 메시지는 다음 출력과 같을 수 있습니다. ``` $ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \ --cluster-configuration cluster-config.yaml { "cluster": { "clusterName": "mycluster", "cloudformationStackStatus": "CREATE_IN_PROGRESS", "cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387", "region": "eu-west-1", "version": "3.15.0", "clusterStatus": "CREATE_IN_PROGRESS" } } $ pcluster describe-cluster --cluster-name mycluster --region eu-west-1 { "creationTime": "2021-09-06T11:03:47.696Z", ... "cloudFormationStackStatus": "ROLLBACK_IN_PROGRESS", "clusterName": "mycluster", "computeFleetStatus": "UNKNOWN", "cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387", "lastUpdatedTime": "2021-09-06T11:03:47.696Z", "region": "eu-west-1", "clusterStatus": "CREATE_FAILED" } ``` **Topics** + [에서 CloudFormation 이벤트 보기 `CREATE_FAILED`](#troubleshooting-v3-cluster-deployment-events) + [CLI를 사용하여 로그 스트림을 볼 수 있습니다.](#troubleshooting-v3-cluster-deployment-cli-logstreams) + [`rollback-on-failure`을 사용하여 실패한 클러스터를 다시 생성합니다.](#troubleshooting-v3-cluster-deployment-cli-fail-rollback) ## 에서 CloudFormation 이벤트 보기 `CREATE_FAILED` 콘솔 또는 AWS ParallelCluster CLI를 사용하여 `CREATE_FAILED` 오류에 대한 CloudFormation 이벤트를 보고 근본 원인을 찾을 수 있습니다. **Topics** + [CloudFormation 콘솔에서 이벤트 보기](#troubleshooting-v3-cluster-deployment-cloudformation) + [CLI를 사용하여 `CREATE_FAILED`의 CloudFormation 이벤트를 보고 필터링할 수 있습니다.](#troubleshooting-v3-cluster-deployment-cli-events) ### CloudFormation 콘솔에서 이벤트 보기 CloudFormation 콘솔을 사용하여 `"CREATE_FAILED"` 상태를 일으킨 원인에 대한 자세한 내용을 확인할 수 있습니다. **콘솔에서 CloudFormation 오류 메시지를 확인합니다.** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) 이동합니다. 1. 이름이 *cluster\$1name*인 스택을 선택합니다. 1. **이벤트** 탭을 선택합니다. 1. **논리적 ID**별로 리소스 이벤트 목록을 스크롤하여 생성에 실패한 리소스의 **상태**를 확인합니다. 하위 작업을 만들지 못한 경우 역방향으로 진행하여 실패한 리소스 이벤트를 찾아보세요. 1. 예를 들어, 다음 상태 메시지가 표시되면 현재 vCPU 한도를 초과하지 않는 인스턴스 유형을 사용하거나 vCPU 용량을 더 요청해야 합니다. ``` 2022-02-04 16:09:44 UTC-0800 HeadNode CREATE_FAILED 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). ``` ### CLI를 사용하여 `CREATE_FAILED`의 CloudFormation 이벤트를 보고 필터링할 수 있습니다. 클러스터 생성 문제를 진단하려면 `CREATE_FAILED` 상태를 필터링하여 [`pcluster get-cluster-stack-events`](pcluster.get-cluster-stack-events-v3.md) 명령을 사용할 수 있습니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [AWS CLI 출력 필터링](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html)을 참조하세요. ``` $ pcluster get-cluster-stack-events --cluster-name mycluster --region eu-west-1 \ --query 'events[?resourceStatus==`CREATE_FAILED`]' [ { "eventId": "3ccdedd0-0f03-11ec-8c06-02c352fe2ef9", "physicalResourceId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387", "resourceStatus": "CREATE_FAILED", "resourceStatusReason": "The following resource(s) failed to create: [HeadNode]. ", "stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387", "stackName": "mycluster", "logicalResourceId": "mycluster", "resourceType": "AWS::CloudFormation::Stack", "timestamp": "2021-09-06T11:11:51.780Z" }, { "eventId": "HeadNode-CREATE_FAILED-2021-09-06T11:11:50.127Z", "physicalResourceId": "i-04e91cc1f4ea796fe", "resourceStatus": "CREATE_FAILED", "resourceStatusReason": "Received FAILURE signal with UniqueId i-04e91cc1f4ea796fe", "resourceProperties": "{\"LaunchTemplate\":{\"Version\":\"1\",\"LaunchTemplateId\":\"lt-057d2b1e687f05a62\"}}", "stackId": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f02-11ec-a3b9-024fcc6f3387", "stackName": "mycluster", "logicalResourceId": "HeadNode", "resourceType": "AWS::EC2::Instance", "timestamp": "2021-09-06T11:11:50.127Z" } ] ``` 이전 예제에서는 헤드 노드 설정에 장애가 발생했습니다. ## CLI를 사용하여 로그 스트림을 볼 수 있습니다. 이러한 문제를 디버깅하려면 [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md)으로 `node-type`를 필터링한 다음 로그 스트림 콘텐츠를 분석하여 헤드 노드에서 이용 가능한 로그 스트림을 나열하는 방법이 있습니다. ``` $ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \ --filters 'Name=node-type,Values=HeadNode' { "logStreams": [ { "logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init", "logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init", ... }, { "logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client", "logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.chef-client", ... }, { "logStreamArn": "arn:aws:logs:eu-west-1:xxx:log-group:/aws/parallelcluster/mycluster-202109061103:log-stream:ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init", "logStreamName": "ip-10-0-0-13.i-04e91cc1f4ea796fe.cloud-init", ... }, ... ] } ``` 초기화 오류를 찾는 데 사용할 수 있는 두 가지 기본 로그 스트림은 다음과 같습니다. + `cfn-init`은 `cfn-init` 스크립트의 로그입니다. 먼저 이 로그 스트림을 확인합니다. 이 로그에서 `Command chef failed` 오류를 확인할 수 있을 것입니다. 오류 메시지와 관련된 자세한 내용은 이 라인 바로 앞에 있는 라인을 참조하세요. 자세한 내용은 [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html)을 참조하세요. + `cloud-init`은 [cloud-init](https://cloudinit.readthedocs.io/)에 대한 로그입니다. `cfn-init`에 아무것도 표시되지 않으면 다음으로 이 로그를 확인해 보세요. [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md)을 사용하여 로그 스트림의 콘텐츠를 검색할 수 있습니다(검색되는 이벤트 수를 제한하는 `--limit 5` 옵션 참고). ``` $ pcluster get-cluster-log-events --cluster-name mycluster \ --region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init \ --limit 5 { "nextToken": "f/36370880979637159565202782352491087067973952362220945409/s", "prevToken": "b/36370880752972385367337528725601470541902663176996585497/s", "events": [ { "message": "2021-09-06 11:11:39,049 [ERROR] Unhandled exception during build: Command runpostinstall failed", "timestamp": "2021-09-06T11:11:39.049Z" }, { "message": "Traceback (most recent call last):\n File \"/opt/aws/bin/cfn-init\", line 176, in \n worklog.build(metadata, configSets)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 135, in build\n Contractor(metadata).build(configSets, self)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 561, in build\n self.run_config(config, worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 573, in run_config\n CloudFormationCarpenter(config, self._auth_config).build(worklog)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/construction.py\", line 273, in build\n self._config.commands)\n File \"/usr/lib/python3.7/site-packages/cfnbootstrap/command_tool.py\", line 127, in apply\n raise ToolError(u\"Command %s failed\" % name)", "timestamp": "2021-09-06T11:11:39.049Z" }, { "message": "cfnbootstrap.construction_errors.ToolError: Command runpostinstall failed", "timestamp": "2021-09-06T11:11:39.049Z" }, { "message": "2021-09-06 11:11:49,212 [DEBUG] CloudFormation client initialized with endpoint https://cloudformation.eu-west-1.amazonaws.com", "timestamp": "2021-09-06T11:11:49.212Z" }, { "message": "2021-09-06 11:11:49,213 [DEBUG] Signaling resource HeadNode in stack mycluster with unique ID i-04e91cc1f4ea796fe and status FAILURE", "timestamp": "2021-09-06T11:11:49.213Z" } ] } ``` 이전 예제에서 실패는 `runpostinstall` 실패로 인해 발생했으므로 이 오류는 [`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)의 `OnNodeConfigured` 구성 파라미터에 사용된 사용자 지정 부트스트랩 스크립트의 내용과 엄격하게 관련되어 있습니다. ## `rollback-on-failure`을 사용하여 실패한 클러스터를 다시 생성합니다. AWS ParallelCluster 는 로그 그룹에 클러스터 CloudWatch 로그 스트림을 생성합니다. CloudWatch 콘솔 사용자 지정 대시보드**** 또는 로그 그룹****에서 이러한 로그를 볼 수 있습니다. 자세한 내용은 [Amazon CloudWatch Logs와 통합](cloudwatch-logs-v3.md) 및 [Amazon CloudWatch 대시보드](cloudwatch-dashboard-v3.md) 항목을 참조하세요. 사용 가능한 로그 스트림이 없는 경우 [`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions) 사용자 지정 부트스트랩 스크립트 또는 AMI 관련 문제로 인해 오류가 발생할 수 있습니다. 이 경우 생성 문제를 진단하려면 `false`로 설정된 `--rollback-on-failure` 파라미터를 포함하여 [`pcluster create-cluster`](pcluster.create-cluster-v3.md)를 사용하여 클러스터를 다시 생성하세요. 그 후 다음과 같이 SSH를 사용하여 클러스터를 확인합니다. ``` $ pcluster create-cluster --cluster-name mycluster --region eu-west-1 \ --cluster-configuration cluster-config.yaml --rollback-on-failure false { "cluster": { "clusterName": "mycluster", "cloudformationStackStatus": "CREATE_IN_PROGRESS", "cloudformationStackArn": "arn:aws:cloudformation:eu-west-1:xxx:stack/mycluster/1bf6e7c0-0f01-11ec-a3b9-024fcc6f3387", "region": "eu-west-1", "version": "3.15.0", "clusterStatus": "CREATE_IN_PROGRESS" } } $ pcluster ssh --cluster-name 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`의 출력이 포함됩니다. 대부분의 경우 이러한 유형의 문제를 해결하기 위해 이 로그를 볼 필요가 없습니다. # Terraform을 사용한 클러스터 배포 문제 해결 이 섹션은 Terraform을 사용하여 배포된 클러스터와 관련이 있습니다. ## ParallelCluster API를 찾을 수 없음 ParallelCluster API를 찾을 수 없으므로 계획이 실패할 수 있습니다. 이 경우 반환된 오류는 다음과 같습니다. ``` Planning failed. Terraform encountered an error while generating this plan. ╷ │ Error: Unable to retrieve ParallelCluster API cloudformation stack. │ │ with provider["registry.terraform.io/aws-tf/aws-parallelcluster"], │ on providers.tf line 6, in provider "aws-parallelcluster": │ 6: provider "aws-parallelcluster" { │ │ operation error CloudFormation: DescribeStacks, https response error StatusCode: 400, RequestID: REQUEST_ID, api error ValidationError: Stack with id PCAPI_STACK_NAME does not exist ``` 이 오류를 해결하려면 클러스터를 생성할 계정에 ParallelCluster API를 배포합니다. [Terraform을 사용하여 클러스터 생성](tutorial-create-cluster-terraform.md)을(를) 참조하세요. ## 사용자가 ParallelCluster API를 호출할 권한이 없음 Terraform 프로젝트를 배포하기로 맡은 IAM 역할/사용자가 ParallelCluster API와 상호 작용할 권한이 없기 때문에 계획이 실패할 수 있습니다. 이 경우 반환된 오류는 다음과 같습니다. ``` Planning failed. Terraform encountered an error while generating this plan. │ Error: 403 Forbidden │ │ with module.parallelcluster_clusters.module.clusters[0].pcluster_cluster.managed_configs["DemoCluster01"], │ on .terraform/modules/parallelcluster_clusters/modules/clusters/main.tf line 35, in resource "pcluster_cluster" "managed_configs": │ 35: resource "pcluster_cluster" "managed_configs" { │ │ {{"Message":"User: USER_ARN is not authorized to perform: execute-api:Invoke on resource: PC_API_REST_RESOURCE with an explicit deny"} │ } ``` 이 오류를 해결하려면 ParallelCluster API 역할을 사용하여 API와 상호 작용하도록 ParallelCluster 공급자를 구성합니다. ``` provider "aws-parallelcluster" { region = var.region profile = var.profile api_stack_name = var.api_stack_name **use_user_role** **= true** } ``` # 규모 조정 문제 해결 이 섹션은 Slurm 작업 스케줄러와 함께 AWS ParallelCluster 버전 3.0.0 이상을 사용하여 설치된 클러스터와 관련이 있습니다. 다중 대기열 구성에 대한 자세한 내용은 [다중 대기열 구성](configuration-of-multiple-queues-v3.md) 섹션을 참조하세요. 실행 중인 클러스터 중 하나에 문제가 있는 경우 문제 해결을 시작하기 전에 다음 명령을 실행하여 클러스터를 `STOPPED` 상태로 전환하세요. 이렇게 하면 예상치 못한 비용이 발생하는 것을 방지할 수 있습니다. ``` $ pcluster update-compute-fleet --cluster-name mycluster \ --status STOP_REQUESTED ``` [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md) 명령을 사용하고 헤드 노드 또는 실패한 노드 중 하나의 `private-dns-name`로 필터링하여 클러스터 노드에서 이용 가능한 로그 스트림을 나열할 수 있습니다. ``` $ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \ --filters 'Name=private-dns-name,Values=ip-10-0-0-101' ``` 그다음 [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md) 명령을 사용하고 다음 섹션에서 언급된 키 로그 중 하나에 대응하는 `--log-stream-name`를 전달하여 로그 스트림의 내용을 검색하고 분석할 수 있습니다. ``` $ pcluster get-cluster-log-events --cluster-name mycluster \ --region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init ``` AWS ParallelCluster 는 로그 그룹에 클러스터 CloudWatch 로그 스트림을 생성합니다. CloudWatch 콘솔 사용자 지정 대시보드**** 또는 로그 그룹****에서 이러한 로그를 볼 수 있습니다. 자세한 내용은 [Amazon CloudWatch Logs와 통합](cloudwatch-logs-v3.md) 및 [Amazon CloudWatch 대시보드](cloudwatch-dashboard-v3.md)를 참조하세요. **Topics** + [디버깅을 위한 키 로그](#troubleshooting-v3-key-logs) + [작업 실행 실패 시 `slurm_resume.log`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `InsufficientInstanceCapacity` 오류가 표시되는 경우](#compute-node-initialization-ice-failure-v3-c2) + [노드 초기화 문제 해결](#troubleshooting-v3-node-init) + [예상치 못한 노드 교체 및 종료 문제 해결****](#troubleshooting-v3-unexpected-node-replacements-and-terminations) + [문제가 있는 인스턴스 및 노드 교체, 종료 또는 전원 끄기****](#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3) + [대기열(파티션) `Inactive` 상태](#troubleshooting-v3-queues) + [기타 알려진 노드 및 작업 문제 해결](#troubleshooting-v3-other-node-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/parallelcluster/compute_console_output` - 이 로그는 예기치 않게 종료된 정적 컴퓨팅 노드 샘플 하위 집합의 콘솔 출력을 기록합니다. 정적 컴퓨팅 노드가 종료되고 CloudWatch에서 컴퓨팅 노드 로그를 사용할 수 없는 경우 이 로그를 사용하세요. Amazon EC2 콘솔을 사용하거나 인스턴스 콘솔 출력을 AWS CLI 검색할 때 수신하는 `compute_console_output log` 콘텐츠는 동일합니다. 컴퓨팅 노드의 키 로그는 다음과 같습니다. + `/var/log/cloud-init-output.log` - [cloud-init](https://cloudinit.readthedocs.io/) 로그입니다. 여기에는 인스턴스가 설정될 때 실행된 모든 명령이 들어 있습니다. 이를 사용하여 초기화 문제를 해결할 수 있습니다. + `/var/log/parallelcluster/computemgtd` - 이것은 `computemgtd` 로그입니다. 이것은 헤드 노드의 `clustermgtd` 대몬(daemon)이 오프라인 상태인 드문 상황에서 각 컴퓨팅 노드에서 실행되어 노드를 모니터링합니다. 이를 사용하여 예상치 못한 종료 문제를 해결할 수 있습니다. + `/var/log/slurmd.log` - 이것은 Slurm 컴퓨팅 대몬 로그입니다. 이를 사용하여 초기화 및 컴퓨팅 실패 문제를 해결할 수 있습니다. ## 작업 실행 실패 시 `slurm_resume.log`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `InsufficientInstanceCapacity` 오류가 표시되는 경우 클러스터에서 Slurm 스케줄러를 사용하는 경우 용량 부족 문제가 발생하는 것입니다. 인스턴스 시작이 요청되었을 때 사용 가능한 인스턴스가 부족하면 `InsufficientInstanceCapacity` 오류가 반환됩니다. 정적 인스턴스 용량의 경우 `/var/log/parallelcluster/clustermgtd`의 `clustermgtd` 로그에서 오류를 찾을 수 있습니다. 동적 인스턴스 용량의 경우 `/var/log/parallelcluster/slurm_resume.log`의 `ResumeProgram` 로그에서 오류를 찾을 수 있습니다. 메시지는 다음 예제와 유사합니다. ``` An error occurred (InsufficientInstanceCapacity) when calling the RunInstances/CreateFleet operation... ``` 사용 사례에 따라 다음 방법 중 하나를 사용하여 이러한 유형의 오류 메시지가 나타나지 않도록 하세요. + 배치 그룹이 활성화되어 있는 경우 해당 그룹을 비활성화하세요. 자세한 내용은 [배치 그룹 및 인스턴스 시작 문제](troubleshooting-v3-placemment-groups.md) 항목을 참조하세요. + 인스턴스의 용량을 예약하고 ODCR(온디맨드 용량 예약)로 인스턴스를 시작합니다. 자세한 내용은 [ODCR(온디맨드 용량 예약)로 인스턴스 시작](launch-instances-odcr-v3.md) 항목을 참조하세요. + 다양한 인스턴스 유형으로 여러 컴퓨팅 리소스를 구성합니다. 워크로드에 특정 인스턴스 유형이 필요하지 않은 경우 여러 컴퓨팅 리소스로 빠르게 부족한 용량 장애 조치를 활용할 수 있습니다. 자세한 내용은 [Slurm 클러스터 빠른 용량 부족 장애 조치](slurm-short-capacity-fail-mode-v3.md) 항목을 참조하세요. + 동일한 컴퓨팅 리소스에서 여러 인스턴스 유형을 구성하고 다중 인스턴스 유형 할당을 활용하세요. 다중 인스턴스 구성에 관한 자세한 내용은 [Slurm을 사용하여 여러 인스턴스 유형 할당](slurm-multiple-instance-allocation-v3.md) 및 [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)를 참조하세요. + 클러스터 구성 [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds) 안의 서브넷 ID를 변경하여 대기열을 다른 가용 영역으로 옮기세요. + 워크로드가 밀접하게 연결되지 않은 경우 대기열을 여러 가용 영역에 분산시키세요. 다중 서브넷 구성에 관한 자세한 내용은 [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds)을 참조하세요. ## 노드 초기화 문제 해결 이 섹션에서는 노드 초기화 문제를 해결하는 방법을 다룹니다. 여기에는 노드가 시작, 전원 공급 또는 클러스터 조인에 실패하는 문제가 포함됩니다. **Topics** + [헤드 노드](#troubleshooting-v3-node-init.head-node) + [컴퓨팅 노드](#troubleshooting-v3-node-init.compute-node) ### 헤드 노드 적용 가능한 로그: + `/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` 로그에 오류 메시지가 있을 것입니다. `OnNodeStart` 또는 `OnNodeConfigured` 스크립트가 클러스터의 구성에 지정되어 있으면 로그 메시지를 통해 스크립트가 성공적으로 실행되는지 다시 확인하세요. 클러스터를 생성할 때 헤드 노드는 컴퓨팅 노드가 클러스터에 조인할 때까지 기다려야 클러스터에 조인할 수 있습니다. 따라서 컴퓨팅 노드가 클러스터에 조인하지 못하면 헤드 노드도 조인하지 못합니다. 사용하는 컴퓨팅 노드 유형에 따라 다음 일련의 절차 중 하나를 수행하여 이러한 유형의 문제를 해결할 수 있습니다. ### 컴퓨팅 노드 + 적용 가능한 로그: + `/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` 로그를 확인하세요. **동적 컴퓨팅 노드:** + `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를 확인할 수 있습니다. 또한 특정 인스턴스의 대응하는 설정 로그를 볼 수 있습니다. 스팟 인스턴스가 지원하는 컴퓨팅 노드:**** + 스팟 인스턴스를 처음 사용하고 작업이 PD(보류 중) 상태인 경우 `/var/log/parallelcluster/slurm_resume.log` 파일을 다시 확인하세요. 아마도 다음과 같은 오류가 표시될 것입니다. ``` 2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for Amazon EC2 Spot Instances. ``` 스팟 인스턴스를 사용할 경우 계정에 `AWSServiceRoleForEC2Spot` 서비스 연결 역할이 있어야 합니다. 를 사용하여 계정에서이 역할을 생성하려면 다음 명령을 AWS CLI실행합니다. ``` $ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com ``` 자세한 내용은 사용 설명서[스팟 인스턴스 작업](spot-v3.md)의 및 *Amazon EC2 * AWS ParallelCluster 사용 설명서의 [스팟 인스턴스 요청에 대한 서비스 연결 역할을 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests). ## 예상치 못한 노드 교체 및 종료 문제 해결**** 이 섹션에서는 특히 노드가 예기치 않게 교체되거나 종료되는 경우 노드 관련 문제를 해결하는 방법을 계속 살펴봅니다. + 적용 가능한 로그:**** + `/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-1234567890abcdef0 \ --instance-initiated-shutdown-behavior "{\"Value\": \"stop\"}" ``` + 종료 방지 기능을 활성화합니다. ``` $ aws ec2 modify-instance-attribute \ --instance-id i-1234567890abcdef0 \ --disable-api-termination ``` + 쉽게 식별할 수 있도록 노드에 태그를 지정합니다. ``` $ aws ec2 create-tags \ --resources i-1234567890abcdef0 \ --tags Key=Name,Value=QUARANTINED-Compute ``` + `parallelcluster:cluster-name` 태그를 변경하여 클러스터에서 노드를 분리합니다. ``` $ aws ec2 create-tags \ --resources i-1234567890abcdef0 \ --tags Key=parallelcluster:clustername,Value=QUARANTINED-ClusterName ``` + 이 명령을 사용하여 노드에서 콘솔 출력을 검색합니다. ``` $ aws ec2 get-console-output --instance-id i-1234567890abcdef0 --output text ``` ## 문제가 있는 인스턴스 및 노드 교체, 종료 또는 전원 끄기**** + 적용 가능한 로그:**** + `/var/log/parallelcluster/clustermgtd` (헤드 노드) + `/var/log/parallelcluster/slurm_suspend.log` (헤드 노드) + 대부분의 경우 `clustermgtd`가 모든 예상 인스턴스 종료 작업을 처리합니다. `clustermgtd` 로그에서 노드 교체 또는 종료에 실패한 이유를 확인하세요. + 동적 노드에 [`SlurmSettings` 속성](Scheduling-v3.md#Scheduling-v3-SlurmSettings.properties) 장애가 발생한 경우 `SuspendProgram` 로그를 확인하여 특정 노드를 인수로 사용하여 `SuspendProgram`이 `slurmctld`에 의해 직접 호출되었는지 확인하세요. `SuspendProgram`는 실제로 어떤 작업도 수행하지 않습니다. 그보다는 직접 호출될 때만 로그를 기록합니다. 모든 인스턴스 종료 및 `NodeAddr` 재설정은 `clustermgtd`에 의해 수행됩니다. Slurm은 `SuspendTimeout` 이후에 노드를 자동으로 `POWER_SAVING` 상태로 되돌립니다. + 부트스트랩 장애로 인해 컴퓨팅 노드에 계속 장애가 발생하는 경우, [Slurm 클러스터 보호 모드](slurm-protected-mode-v3.md)가 활성화된 상태로 시작되는지 확인하세요. 보호 모드가 활성화되지 않은 경우 보호 모드 설정을 수정하여 보호 모드를 활성화하세요. 부트스트랩 스크립트 문제 해결 및 수정 ## 대기열(파티션) `Inactive` 상태 `sinfo`를 실행했을 때 출력에 `AVAIL` 상태가 `inact`인 대기열이 표시되면 클러스터에 [Slurm 클러스터 보호 모드](slurm-protected-mode-v3.md)가 활성화되어 있고 대기열이 사전 정의된 기간 동안 `INACTIVE` 상태로 설정되어 있었을 수 있습니다. ## 기타 알려진 노드 및 작업 문제 해결 알려진 또 다른 유형의 문제는 작업을 할당하지 못하거나 조정 결정을 내리지 못할 AWS ParallelCluster 수 있다는 것입니다. 이러한 유형의 문제에서는 AWS ParallelCluster 가 Slurm 지침에 따라서만 리소스를 시작, 종료 또는 유지 관리합니다. 이러한 문제의 경우 `slurmctld` 로그를 확인하여 문제를 해결하세요. # 배치 그룹 및 인스턴스 시작 문제 노드 간 지연 시간을 최소화하려면 배치 그룹**을 사용하세요. 배치 그룹은 인스턴스가 동일한 네트워킹 백본에 위치하도록 보장합니다. 요청이 이루어질 때 사용 가능한 인스턴스가 충분하지 않으면 `InsufficientInstanceCapacity` 오류가 반환됩니다. 클러스터 배치 그룹을 사용할 때 오류가 발생할 가능성을 줄이려면 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking)/[`PlacementGroup`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup)/[`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-PlacementGroup-Enabled) 파라미터를 `false`로 설정합니다. 용량 액세스를 추가로 제어하려면 [ODCR(온디맨드 용량 예약)으로 인스턴스를 시작](launch-instances-odcr-v3.md)하는 것을 고려하세요. 자세한 내용은 *Linux 인스턴스용 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)을 참조하세요. # 디렉터리 교체 일부 디렉터리는 교체할 수 없습니다. 디렉터리를 교체하는 데 문제가 있는 경우 그럴 수 있습니다. 다음 디렉터리는 노드 간에 공유되므로 교체할 수 없습니다. + `/opt/intel` - 여기에는 Intel MPI, Intel Parallel Studio 및 관련 파일이 포함됩니다. + `/opt/slurm` - 여기에는 Slurm 워크로드 매니저 및 관련 파일이 포함됩니다. (조건부, `Scheduler: slurm`의 경우에만 해당.) # Amazon DCV의 문제 해결 **Topics** + [Amazon DCV용 로그](#troubleshooting-v3-nice-dcv-logs) + [Ubuntu Amazon DCV 문제](#troubleshooting-v3-nice-dcv-modules) ## Amazon DCV용 로그 Amazon DCV에 대한 로그는 `/var/log/dcv/` 디렉터리의 파일에 기록됩니다. 이러한 로그를 검토하면 문제를 해결하는 데 도움이 될 수 있습니다. Amazon DCV를 실행하려면 인스턴스 유형에 1.7기비바이트(GiB) 이상의 RAM이 있어야 합니다. 나노 및 마이크로 인스턴스 유형에는 Amazon DCV를 실행하기에 충분한 메모리가 없습니다. AWS ParallelCluster 는 로그 그룹에 Amazon DCV 로그 스트림을 생성합니다. CloudWatch 콘솔 사용자 지정 대시보드**** 또는 로그 그룹****에서 이러한 로그를 볼 수 있습니다. 자세한 내용은 [Amazon CloudWatch Logs와 통합](cloudwatch-logs-v3.md) 및 [Amazon CloudWatch 대시보드](cloudwatch-dashboard-v3.md) 섹션을 참조하세요. ## Ubuntu Amazon DCV 문제 Ubuntu의 Amazon 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 스케줄러 통합, 특히 헤드 노드 문제, 컴퓨팅 문제, 작업 실패 및 제한 시간 오류가 있는 클러스터에 대해 가능한 문제 해결 팁을 제공합니다. **Topics** + [헤드 노드 문제](#troubleshooting-v3-batch-head-node) + [컴퓨팅 문제](#troubleshooting-v3-batch-compute-nodes) + [작업 실패](#troubleshooting-v3-batch-job-fail) + [엔드포인트 URL의 연결 시간 초과 오류](#troubleshooting-v3-batch-connect-timeout) ## 헤드 노드 문제 Slurm 클러스터와 동일한 방식으로 헤드 노드 설정 문제를 해결할 수 있습니다(Slurm 전용 로그 제외). 이러한 문제에 대한 자세한 내용은 [헤드 노드](troubleshooting-v3-scaling-issues.md#troubleshooting-v3-node-init.head-node) 섹션을 참조하세요. ## 컴퓨팅 문제 AWS Batch 는 서비스의 규모 조정 및 컴퓨팅 측면을 관리합니다. 컴퓨팅 관련 문제가 발생하는 경우 AWS Batch [문제 해결](https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html) 설명서에서 도움말을 참조하세요. ## 작업 실패 작업이 실패할 경우 [`awsbout`](awsbatchcli.awsbout-v3.md) 명령을 실행하여 작업 출력을 검색할 수 있습니다. [`awsbstat`](awsbatchcli.awsbstat-v3.md) 명령을 실행하여 Amazon CloudWatch에 저장된 작업 로그로 연결되는 링크를 얻을 수도 있습니다. ## 엔드포인트 URL의 연결 시간 초과 오류 다중 노드 병렬 작업이 `Connect timeout on endpoint URL` 오류로 실패하는 경우 + `awsbout` 출력 로그에서 작업이 `Detected 3/3 compute nodes. Waiting for all compute nodes to start.` 출력의 다중 노드 병렬인지 확인합니다. + 컴퓨팅 노드 서브넷이 퍼블릭인지 확인합니다. 다중 노드 병렬 작업은에서 사용 시 퍼블릭 서브넷 사용을 지원하지 않습니다 AWS Batch AWS ParallelCluster. 컴퓨팅 노드와 작업에는 프라이빗 서브넷을 사용하세요. 자세한 내용을 알아보려면AWS Batch 사용 설명서**의 [컴퓨팅 환경 고려 사항](https://docs.aws.amazon.com/batch/latest/userguide/multi-node-parallel-jobs.html#mnp-ce)을 참조하세요. 컴퓨팅 노드의 프라이빗 서브넷을 구성하려면 [AWS ParallelCluster AWS Batch 스케줄러 사용](network-configuration-v3-batch.md)을 참조하세요. # Active Directory와의 다중 사용자 통합 문제 해결 이 섹션은 Active Directory와 통합된 클러스터와 관련이 있습니다. Active Directory 통합 기능이 예상대로 작동하지 않는 경우 SSSD 로그가 유용한 진단 정보를 제공할 수 있습니다. 이러한 로그는 클러스터 노드의 `/var/log/sssd`에 있습니다. 기본적으로 클러스터의 Amazon CloudWatch 로그 그룹에도 저장됩니다. **Topics** + [Active Directory 관련 문제 해결](#troubleshooting-v3-multi-ad-specific) + [디버그 모드 활성화](#troubleshooting-v3-multi-user-debug) + [LDAPS에서 LDAP로 이동하는 방법](#troubleshooting-v3-multi-user-ldaps-ldap) + [LDAPS 서버 인증서 검증을 비활성화하는 방법](#troubleshooting-v3-multi-user-ldaps-verify) + [암호 대신 SSH 키를 사용하여 로그인하는 방법](#troubleshooting-v3-multi-user-ssh-login) + [사용자 암호 및 만료된 암호를 재설정하는 방법](#troubleshooting-v3-multi-user-reset-passwd) + [조인한 도메인을 확인하는 방법](#troubleshooting-v3-multi-user-domain-verify) + [인증서 문제를 해결하는 방법](#troubleshooting-v3-multi-user-certificates) + [Active Directory와의 통합이 제대로 작동하는지 확인하는 방법](#troubleshooting-v3-multi-user-ad-verify) + [컴퓨팅 노드 로그인 문제를 해결하는 방법](#troubleshooting-v3-multi-user-ad-compute-node-login) + [다중 사용자 환경에서 SimCenter StarCCM\$1 작업과 관련된 알려진 문제](#troubleshooting-v3-multi-user-ad-starccm) + [사용자 이름 확인과 관련된 알려진 문제](#troubleshooting-v3-multi-user-name-resolution) + [홈 디렉터리 생성 문제를 해결하는 방법](#troubleshooting-v3-multi-home-directory) ## Active Directory 관련 문제 해결 이 섹션은 Active Directory 유형별 문제 해결과 관련이 있습니다. ### Simple AD + `DomainReadOnlyUser` 값은 사용자에 대한 Simple AD 디렉터리 기본 검색과 일치해야 합니다. `cn=ReadOnlyUser,cn=Users,dc=corp,dc=example,dc=com` `Users`에 `cn`을 참고하세요. + 기본 관리자 사용자는 `Administrator`입니다. + `Ldapsearch`에는 사용자 이름 앞에 NetBIOS 이름이 있어야 합니다. `Ldapsearch` 구문은 다음과 같아야 합니다. ``` $ ldapsearch -x -D "corp\\Administrator" -w "Password" -H ldap://192.0.2.103 \ -b "cn=Users,dc=corp,dc=example,dc=com" ``` ### AWS Managed Microsoft AD + `DomainReadOnlyUser` 값은 사용자에 대한 AWS Managed Microsoft AD 디렉터리 기본 검색과 일치해야 합니다. `cn=ReadOnlyUser,ou=Users,ou=CORP,dc=corp,dc=example,dc=com` + 기본 관리자 사용자는 `Admin`입니다. + `Ldapsearch` 구문은 다음과 같아야 합니다. ``` $ ldapsearch -x -D "Admin" -w "Password" -H ldap://192.0.2.103 \ -b "ou=Users,ou=CORP,dc=corp,dc=example,dc=com" ``` ## 디버그 모드 활성화 SSSD의 디버그 로그는 문제를 해결하는 데 유용할 수 있습니다. 디버그 모드를 활성화하려면 클러스터 구성을 다음과 같이 변경하여 클러스터를 업데이트해야 합니다. ``` DirectoryService: AdditionalSssdConfigs: debug_level: "0x1ff" ``` ## LDAPS에서 LDAP로 이동하는 방법 LDAPS(TLS/SSL을 사용하는 LDAP)에서 LDAP로 전환하는 것은 권장되지 않습니다. LDAP만으로는 암호화가 제공되지 않기 때문입니다. 하지만 테스트 목적과 문제 해결에는 유용할 수 있습니다. 클러스터를 이전 구성 정의로 업데이트하여 클러스터를 이전 구성으로 복원할 수 있습니다. LDAPS에서 LDAP로 이동하려면 클러스터 구성을 다음과 같이 변경하여 클러스터를 업데이트해야 합니다. ``` DirectoryService: LdapTlsReqCert: never AdditionalSssdConfigs: ldap_auth_disable_tls_never_use_in_production: True ``` ## LDAPS 서버 인증서 검증을 비활성화하는 방법 테스트 또는 문제 해결을 위해 헤드 노드에서 LDAPS 서버 인증서 검증을 일시적으로 비활성화하는 것이 유용할 수 있습니다. 클러스터를 이전 구성 정의로 업데이트하여 클러스터를 이전 구성으로 복원할 수 있습니다. LDAPS 서버 인증서 검증을 사용하지 않도록 설정하려면 클러스터 구성에서 다음과 같이 변경하여 클러스터를 업데이트해야 합니다. ``` DirectoryService: LdapTlsReqCert: never ``` ## 암호 대신 SSH 키를 사용하여 로그인하는 방법 SSH 키는 처음으로 암호를 사용하여 로그인한 후 `/home/$user/.ssh/id_rsa`에 생성됩니다. SSH 키로 로그인하려면 암호로 로그인하고 SSH 키를 로컬로 복사한 다음 평소와 같이 이를 사용하여 암호 없이 SSH 작업을 수행해야 합니다. ``` $ ssh -i $LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip ``` ## 사용자 암호 및 만료된 암호를 재설정하는 방법 사용자가 클러스터에 액세스할 수 없는 경우 [AWS Managed Microsoft AD 암호가 만료되었을 수 있습니다](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_password_policies.html). 암호를 재설정하려면 디렉터리에 대한 쓰기 권한이 있는 사용자 및 역할과 함께 다음 명령을 실행합니다. ``` $ aws ds reset-user-password \ --directory-id "d-abcdef01234567890" \ --user-name "USER_NAME" \ --new-password "NEW_PASSWORD" \ --region "region-id" ``` [`DirectoryService`](DirectoryService-v3.md)/[`DomainReadOnlyUser`](DirectoryService-v3.md#yaml-DirectoryService-DomainReadOnlyUser)의 비밀번호를 재설정한 경우: 1. [`DirectoryService`](DirectoryService-v3.md)/[`PasswordSecretArn`](DirectoryService-v3.md#yaml-DirectoryService-PasswordSecretArn) 암호를 새 암호로 업데이트해야 합니다. 1. 새 암호 값에 맞게 클러스터를 업데이트하세요. 1. `pcluster update-compute-fleet` 명령을 사용하여 컴퓨팅 플릿을 중지합니다. 1. 클러스터 헤드 노드 내에서 다음 명령을 실행합니다. ``` $ sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh ``` 암호를 재설정하고 클러스터를 업데이트한 후에는 사용자의 클러스터 액세스를 복원해야 합니다. 자세한 내용은Directory Service 관리 안내서**의 [사용자 암호 재설정](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_reset_password.html)을 참조하세요. ## 조인한 도메인을 확인하는 방법 다음 명령은 헤드 노드가 아닌 도메인에 가입된 인스턴스에서 실행해야 합니다. ``` $ realm list corp.example.com \ type: kerberos \ realm-name: CORP.EXAMPLE.COM \ domain-name: corp.example.com \ configured: kerberos-member \ server-software: active-directory \ client-software: sssd \ required-package: oddjob \ required-package: oddjob-mkhomedir \ required-package: sssd \ required-package: adcli \ required-package: samba-common-tools \ login-formats: %U \ login-policy: allow-realm-logins ``` ## 인증서 문제를 해결하는 방법 LDAPS 통신이 작동하지 않는 경우 TLS 통신 오류 때문일 수 있으며, 이는 인증서 문제 때문일 수 있습니다. **인증서에 대한 참고 사항:** + 클러스터 구성 `LdapTlsCaCert`에 지정된 인증서는 도메인 컨트롤러용 인증서를 발급한 전체 CA(인증 기관) 체인의 인증서를 포함하는 PEM 인증서 번들이어야 합니다. + PEM 인증서 번들은 PEM 인증서를 연결하여 만든 파일입니다. + PEM 형식의 인증서(일반적으로 Linux에서 사용됨)는 base64 DER 형식의 인증서(일반적으로 Windows에서 내보내는 인증서)와 동일합니다. + 도메인 컨트롤러용 인증서를 하위 CA에서 발급한 경우 인증서 번들에는 하위 CA와 루트 CA의 인증서가 모두 포함되어야 합니다. 문제 해결 확인 단계:**** 다음 확인 단계에서는 명령이 클러스터 헤드 노드 내에서 실행되고 도메인 컨트롤러가 `SERVER:PORT`에 연결할 수 있다고 가정합니다. 인증서와 관련된 문제를 해결하려면 다음 확인 단계를 따르세요. **확인 단계:** 1. Active Directory 도메인 컨트롤러에 대한 연결을 확인하세요.**** 도메인 컨트롤러에 연결할 수 있는지 확인합니다. 이 단계가 성공하면 도메인 컨트롤러에 대한 SSL 연결이 성공하고 인증서가 확인됩니다. 사용자의 문제는 인증서와 관련이 없습니다. 이 단계가 실패하면 다음 확인을 진행하세요. ``` $ openssl s_client -connect SERVER:PORT -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE ``` 1. 인증서 검증 확인:**** 로컬 CA 인증서 번들이 도메인 컨트롤러에서 제공한 인증서를 검증할 수 있는지 확인하세요. 이 단계가 성공하면 문제는 인증서와 관련된 것이 아니라 다른 네트워킹 문제와 관련이 있는 것입니다. 이 단계가 실패하면 다음 확인을 진행하세요. ``` $ openssl verify -verbose -CAfile PATH_TO_CA_BUNDLE_CERTIFICATE PATH_TO_A_SERVER_CERTIFICATE ``` 1. Active Directory 도메인 컨트롤러에서 제공된 인증서를 확인하세요.**** 도메인 컨트롤러가 제공한 인증서의 내용이 예상한 것과 같은지 확인하세요. 이 단계가 성공하면 컨트롤러 확인에 사용된 CA 인증서에 문제가 있을 수 있습니다. 다음 문제 해결 단계로 이동하세요. 이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 인증서를 수정하고 문제 해결 단계를 다시 실행해야 합니다. ``` $ openssl s_client -connect SERVER:PORT -showcerts ``` 1. 인증서 내용 확인:**** 도메인 컨트롤러가 제공한 인증서의 내용이 예상한 것과 같은지 확인하세요. 이 단계가 성공하면 컨트롤러 확인에 사용된 CA 인증서에 문제가 있을 수 있습니다. 다음 문제 해결 단계로 이동하세요. 이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 인증서를 수정하고 문제 해결 단계를 다시 실행해야 합니다. ``` $ openssl s_client -connect SERVER:PORT -showcerts ``` 1. 로컬 CA 인증서 번들의 내용을 확인하세요.**** 도메인 컨트롤러 인증서를 검증하는 데 사용되는 로컬 CA 인증서 번들의 내용이 예상과 같은지 확인하세요. 이 단계가 성공하면 도메인 컨트롤러에서 제공하는 인증서에 문제가 있을 수 있습니다. 이 단계가 실패할 경우 도메인 컨트롤러용으로 발급된 CA 인증서 번들을 수정하고 문제 해결 단계를 다시 실행해야 합니다. ``` $ openssl x509 -in PATH_TO_A_CERTIFICATE -text ``` ## Active Directory와의 통합이 제대로 작동하는지 확인하는 방법 다음 두 가지 검사가 성공하면 Active Directory와의 통합이 작동하는 것입니다. 확인:**** 1. 디렉터리에 정의된 사용자를 검색할 수 있습니다.**** 클러스터 헤드 노드 내에서 `ec2-user`로서: ``` $ getent passwd $ANY_AD_USER ``` 1. 사용자 비밀번호를 제공하여 헤드 노드에 SSH로 연결할 수 있습니다.**** ``` $ ssh $ANY_AD_USER@$HEAD_NODE_IP ``` 검사 1이 실패하면 검사 2도 실패할 것으로 예상됩니다. 추가 문제 해결 확인: + 사용자가 디렉터리에 있는지 확인하세요. + [디버그 로깅](#troubleshooting-v3-multi-user-debug) 활성화 + LDAPS 문제를 배제하려면 [LDAPS에서 LDAP로 이동하여](#troubleshooting-v3-multi-user-ldaps-ldap) 암호화를 일시적으로 비활성화하는 것이 좋습니다. ## 컴퓨팅 노드 로그인 문제를 해결하는 방법 이 섹션은 Active Directory와 통합된 클러스터의 컴퓨팅 노드에 로그인하는 것과 관련이 있습니다. 를 사용하면 클러스터 컴퓨팅 노드에 대한 AWS ParallelCluster암호 로그인이 설계상 비활성화됩니다. 모든 사용자는 자신의 SSH 키를 사용하여 컴퓨팅 노드에 로그인해야 합니다. 클러스터 구성에서 [`GenerateSshKeysForUsers`](DirectoryService-v3.md#yaml-DirectoryService-GenerateSshKeysForUsers)가 활성화된 경우 사용자는 첫 번째 인증(예: 로그인) 후 헤드 노드에서 SSH 키를 검색할 수 있습니다. 사용자가 헤드 노드에서 처음으로 인증하는 경우 디렉터리 사용자를 위해 자동으로 생성되는 SSH 키를 검색할 수 있습니다. 사용자의 홈 디렉터리도 생성됩니다. sudo-user가 헤드 노드의 사용자로 처음 전환할 때도 이런 일이 발생할 수 있습니다. 사용자가 헤드 노드에 로그인하지 않은 경우 SSH 키는 생성되지 않으며 사용자는 컴퓨팅 노드에 로그인할 수 없습니다. ## 다중 사용자 환경에서 SimCenter StarCCM\$1 작업과 관련된 알려진 문제 이 섹션은 Siemens의 Simcenter StarCCM\$1 전산 유체 역학 소프트웨어가 다중 사용자 환경에서 시작한 작업과 관련이 있습니다. 내장된 IntelMPI를 사용하도록 구성된 StarCCM\$1 v16 작업을 실행하는 경우 기본적으로 MPI 프로세스는 SSH를 사용하여 부트스트랩됩니다. 사용자 이름 확인이 잘못되게 하는 알려진 [Slurm 버그](https://bugs.schedmd.com/show_bug.cgi?id=13385)로 인해 작업이 실패하고 `error setting up the bootstrap proxies` 같은 오류가 발생할 수 있습니다. 이 버그는 AWS ParallelCluster 버전 3.1.1 및 3.1.2에만 영향을 줍니다. 이러한 문제를 방지하려면 IntelMPI가 Slurm을 MPI 부트스트랩 방법으로 사용하도록 강제하세요. [IntelMPI 공식 설명서](https://www.intel.com/content/www/us/en/develop/documentation/mpi-developer-reference-linux/top/environment-variable-reference/hydra-environment-variables.html)에 설명된 대로 StarCCM\$1를 시작하는 작업 스크립트로 환경 변수 `I_MPI_HYDRA_BOOTSTRAP=slurm`를 내보냅니다. ## 사용자 이름 확인과 관련된 알려진 문제 이 섹션은 작업 내에서 사용자 이름을 검색하는 것과 관련이 있습니다. [Slurm의 알려진 버그](https://bugs.schedmd.com/show_bug.cgi?id=13385)로 인해 `srun` 없이 작업을 실행하면 작업 프로세스 내에서 검색된 사용자 이름은 `nobody`일 수 있습니다. 이 버그는 AWS ParallelCluster 버전 3.1.1 및 3.1.2에만 영향을 줍니다. 예를 들어 디렉터리 사용자로 명령 `sbatch --wrap 'srun id'`을 실행하면 올바른 사용자 이름이 반환됩니다. 하지만 디렉터리 사용자로 `sbatch --wrap 'id'`를 실행하면 사용자 이름으로 `nobody`가 반환될 수 있습니다. 다음 해결 방법을 사용할 수 있습니다. 1. 가능하면 `'srun'` 대신 `'sbatch'`를 사용하여 작업을 시작하세요. 1. 다음과 같이 클러스터 구성에서 [AdditionalSssdConfigs](DirectoryService-v3.md#yaml-DirectoryService-AdditionalSssdConfigs)를 설정하여 SSSD 열거를 활성화합니다. ``` AdditionalSssdConfigs: enumerate: true ``` ## 홈 디렉터리 생성 문제를 해결하는 방법 이 섹션은 홈 디렉터리 생성 문제와 관련이 있습니다. 다음 예와 같은 오류가 표시되면 헤드 노드에 처음 로그인했을 때 홈 디렉터리가 자동으로 생성되지 않은 것입니다. 또는 sudoer에서 헤드 노드의 Active Directory 사용자로 처음 전환했을 때 홈 디렉터리가 자동으로 생성되지 않은 경우도 있습니다. ``` $ ssh AD_USER@$HEAD_NODE_IP /opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1 __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ Could not chdir to home directory /home/PclusterUser85: No such file or directory ``` 홈 디렉터리 생성 실패는 클러스터 헤드 노드에 설치된 `oddjob` 및 `oddjob-mkhomedir` 패키지로 인해 발생할 수 있습니다. 홈 디렉터리와 SSH 키가 없으면 사용자는 클러스터 노드에 작업이나 SSH를 제출할 수 없습니다. 시스템에 `oddjob` 패키지가 필요한 경우 `oddjobd` 서비스가 실행 중인지 확인하고 PAM 구성 파일을 새로 고쳐 홈 디렉터리가 생성되었는지 확인하세요. 이렇게 하려면 다음 예와 같이 헤드 노드에서 명령을 실행하세요. ``` sudo systemctl start oddjobd sudo authconfig --enablemkhomedir --updateall ``` 시스템에 `oddjob` 패키지가 필요하지 않은 경우 패키지를 제거하고 PAM 구성 파일을 새로 고쳐 홈 디렉터리가 생성되었는지 확인하세요. 이렇게 하려면 다음 예와 같이 헤드 노드에서 명령을 실행하세요. ``` sudo yum remove -y oddjob oddjob-mkhomedir sudo authconfig --enablemkhomedir --updateall ``` # 사용자 지정 AMI 문제 해결 이 섹션에서는 사용자 지정 AMI 문제에 대한 가능한 문제 해결 팁을 제공합니다. 사용자 지정 AMI를 사용할 때 다음 경고가 표시됩니다. ``` "validationMessages": [ { "level": "WARNING", "type": "CustomAmiTagValidator", "message": "The custom AMI may not have been created by pcluster. You can ignore this warning if the AMI is shared or copied from another pcluster AMI. If the AMI is indeed not created by pcluster, cluster creation will fail. If the cluster creation fails, please go to https://docs.aws.amazon.com/parallelcluster/latest/ug/troubleshooting.html#troubleshooting-stack-creation-failures for troubleshooting." }, { "level": "WARNING", "type": "AmiOsCompatibleValidator", "message": "Could not check node AMI ami-0000012345 OS and cluster OS alinux2 compatibility, please make sure they are compatible before cluster creation and update operations." } ] ``` 올바른 AMI가 사용되고 있다고 확신하는 경우 이러한 경고를 무시해도 됩니다. 나중에 이러한 경고를 보지 않으려면 다음 태그로 사용자 지정 AMI에 태그를 지정합니다. 여기서 `my-os`는 `alinux2`, , `alinux2023`, `ubuntu2404``ubuntu2204``rhel8`, 또는 중 하나`rhel9`이고 "*3.15.0"*은 사용 중인 `pcluster` 버전입니다. ``` $ aws ec2 create-tags \ --resources ami-yourcustomAmi \ --tags Key="parallelcluster:version",Value="3.15.0" Key="parallelcluster:os",Value="my-os" ``` # `cfn-hup`이 실행 중이 아닐 때의 클러스터 업데이트 제한 시간 문제 해결 `cfn-hup` 헬퍼는 리소스 메타데이터의 변경 사항을 감지하고 변경 사항이 감지되면 사용자 지정 작업을 실행하는 대몬(daemon)입니다. 이것이 `UpdateStack` API 작업을 통해 실행 중인 Amazon EC2 인스턴스에 대한 구성 업데이트를 수행하는 방법입니다. 현재 `cfn-hup` 대몬은 `supervisord`에 의해 실행됩니다. 하지만 실행 후에는 `cfn-hup` 프로세스가 `supervisord` 제어에서 분리됩니다. 외부 행위자가 `cfn-hup` 대몬을 종료할 경우 대몬은 자동으로 다시 시작되지 않습니다. `cfn-hup`가 실행되고 있지 않으면 클러스터 업데이트 중에 CloudFormation 스택이 예상대로 업데이트 프로세스를 시작하지만 헤드 노드에서 업데이트 절차가 활성화되지 않아 결국 스택은 시간이 초과됩니다. 클러스터 로그 `/var/log/chef-client`에서 업데이트 레시피가 호출되지 않는 것을 확인할 수 있습니다. **장애 발생 시 `cfn-hup`를 확인하고 다시 시작하세요.** 1. 헤드 노드에서 `cfn-hup`가 실행 중인지 확인합니다. ``` $ ps aux | grep cfn-hup ``` 1. 헤드 노드에서 `cfn-hup` 로그 `/var/log/cfn-hup.log` 및 `/var/log/supervisord.log`을 확인하세요. 1. `cfn-hup`가 실행 중이 아니면 다음을 실행하여 다시 시작해 보세요. ``` $ sudo /opt/parallelcluster/pyenv/versions/cookbook_virtualenv/bin/supervisorctl start cfn-hup ``` # 네트워크 문제 해결 이 섹션에서는 네트워크 문제가 발생할 때, 특히 단일 퍼블릭 서브넷 문제의 클러스터를 처리할 때의 문제 해결 팁을 제공합니다. ## 단일 퍼블릭 서브넷 안의 클러스터 문제 컴퓨팅 노드 중 하나에서 `cloud-init-output.log`를 확인하세요. 노드가 Slurm 초기화 중에 중단되었음을 나타내는 다음과 같은 내용이 발견되면 DynamoDB VPC 엔드포인트가 누락되었기 때문일 가능성이 큽니다. DynamoDB 엔드포인트를 추가합니다. 자세한 내용은 [AWS ParallelCluster 인터넷에 액세스할 수 없는 단일 서브넷의](aws-parallelcluster-in-a-single-public-subnet-no-internet-v3.md) 항목을 참조하세요. ``` ruby_block[retrieve compute node info] action run[2022-03-11T17:47:11+00:00] INFO: Processing ruby_block[retrieve compute node info] action run (aws-parallelcluster-slurm::init line 31) ``` # `onNodeUpdated` 사용자 지정 작업에서 클러스터 업데이트가 실패한 경우 [`HeadNode`](HeadNode-v3.md)/[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)/[`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated) 스크립트가 실패하면 업데이트가 실패하고 롤백 시 스크립트가 실행되지 않습니다. 롤백이 완료된 후 필요한 정리를 수동으로 수행하는 것은 사용자의 책임입니다. 예를 들어 `OnNodeUpdated` 스크립트가 구성 파일의 필드 상태(예: `true`에서 `false`로)를 변경한 후 실패한 경우 해당 필드 값을 업데이트 전 상태(예: `false`에서 `true`로)로 수동으로 복원해야 합니다. 자세한 내용은 [사용자 지정 부트스트랩 작업](custom-bootstrap-actions-v3.md) 항목을 참조하세요. # 사용자 지정 Slurm 구성에서 오류가 표시되는 경우 AWS ParallelCluster 버전 3.6.0부터는 단일 `prolog` 또는 `epilog` 스크립트를 사용자 지정 Slurm 구성에 포함시켜 더 이상 대상으로 지정할 수 없습니다. AWS ParallelCluster 버전 3.6.0 이상에서는 각 `prolog` 및 `Epilog` 폴더에서 사용자 지정 `Prolog` 및 `epilog` 스크립트를 찾아야 합니다. 이러한 폴더는 기본적으로 다음을 가리키도록 구성되어 있습니다. + `Prolog`는 `/opt/slurm/etc/scripts/prolog.d/`를 가리킵니다. + `Epilog`는 `/opt/slurm/etc/scripts/epilog.d/`를 가리킵니다. `90_plcuster_health_check_manager` 프롤로그 스크립트와 `90_pcluster_noop` 에필로그 스크립트는 제자리에 두는 것이 좋습니다. Slurm는 스크립트를 알파벳 역순으로 실행합니다. `Prolog` 및 `Epilog` 폴더 모두에 적어도 헌 개 이상의 파일이 포함되어 있어야 합니다. 자세한 내용은 [Slurm 및 `prolog``epilog`](slurm-prolog-epilog-v3.md) 및 [Slurm 구성 사용자 지정](slurm-configuration-settings-v3.md) 섹션을 참조하세요. # 클러스터 경보 최적의 성능을 보장하려면 클러스터 상태 모니터링이 필수적입니다. AWS ParallelCluster 를 사용하면 클러스터 헤드 노드에 대한 여러 CloudWatch 기반 경보를 모니터링할 수 있습니다. 이 섹션에서는 명명 규칙, 경보를 트리거하는 특정 조건, 제안된 문제 해결 단계를 포함하여 각 유형의 헤드 노드 클러스터 경보에 대한 세부 정보를 제공합니다. 클러스터 경보의 명명 규칙은 `CLUSTER_NAME-COMPONENT-METRIC`입니다. 예를 들어, `mycluster-HeadNode-Cpu`입니다. + `CLUSTER_NAME-HeadNode`: 헤드 노드의 전체 상태를 나타냅니다. 아래 경보 중 하나 이상이 있으면 빨간색입니다. + `CLUSTER_NAME-HeadNode-Health`: Amazon EC2 상태 확인 실패가 하나 이상 있는 경우 빨간색입니다. 경보가 발생하는 경우 [상태 확인이 실패한 인스턴스 문제 해결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html)을 살펴보는 것이 좋습니다. + `CLUSTER_NAME-HeadNode-Cpu`: CPU 사용률이 90%를 초과하는 경우 빨간색입니다. 경보가 발생하는 경우 `ps -aux --sort=-%cpu | head -n 10`을 사용하여 CPU를 가장 많이 소비하는 프로세스를 확인합니다. + `CLUSTER_NAME-HeadNode-Mem`: 메모리 사용률이 90%보다 큰 경우 빨간색입니다. 경보가 발생하는 경우 `ps -aux --sort=-%mem | head -n 10`을 사용하여 메모리를 가장 많이 소비하는 프로세스를 확인합니다. + `CLUSTER_NAME-HeadNode-Disk`: 경로 /에서 점유 디스크 공간이 90%보다 큰 경우 빨간색입니다. 경보가 발생하는 경우 대부분의 스페이스를 사용하는 폴더를 `du -h --max-depth=2 / 2> /dev/null | sort -hr`로 확인합니다. # 오류 또는 실패를 유발하는 OS 구성 변경 사항 해결 AWS ParallelCluster 노드에 OS 구성을 변경할 때 클러스터 생성, 업데이트 또는 작업 실패를 일으킬 수 있는 다양한 문제가 발생할 수 있습니다. 이 섹션에서는 일반적인 OS 구성 관련 문제를 식별하고 해결하는 방법에 대한 지침을 제공합니다. ## 일반적인 OS 구성 문제 ### 로캘 구성 문제 가장 일반적인 OS 구성 문제 중 하나는 로캘 설정과 관련이 있습니다. 다음과 같은 오류가 표시되는 경우: ``` cannot change locale (en_US.utf-8) because it has an invalid name ``` 이는 일반적으로 다음과 같은 경우에 발생합니다. + `yum` 설치 프로세스가 실패하여 로캘 설정이 일관되지 않은 상태로 남음 + 사용자가 설치 프로세스를 조기에 종료함 + 로캘 패키지가 누락되었거나 손상되었습니다. #### 진단 방법 1. pcluster-admin 사용자로 전환할 수 있는지 확인합니다. ``` $ su - pcluster-admin ``` 와 같은 오류가 표시되면 문제가 `cannot change locale...no such file or directory`확인된 것입니다. 1. 사용 가능한 로캘을 확인합니다. ``` $ localedef --list ``` 이렇게 하면 빈 목록이 반환되거나 기본 로캘이 포함되지 않으면 로캘 구성이 중단됩니다. 1. 마지막 `yum` 명령을 확인합니다. ``` $ yum history $ yum history info #ID ``` 마지막 ID에 `Return-Code: Success`가 없으면 설치 후 스크립트가 성공적으로 실행되지 않았을 수 있습니다. #### 해결 방법 언어 팩을 다시 설치하여 로캘을 다시 빌드합니다. ``` $ sudo yum reinstall glibc-all-langpacks ``` 다시 빌드한 후 다음을 실행하여 문제가 해결되었는지 확인합니다. ``` $ su - pcluster-admin ``` 오류나 경고가 표시되지 않으면 문제가 해결된 것입니다. ### OS 패키지 충돌 사용자 지정 패키지를 설치하거나 시스템 패키지를 수정할 때 충돌이 발생하여 클러스터가 제대로 작동하지 않을 수 있습니다. #### 진단 방법 1. chef-client 로그에서 패키지 관련 오류를 확인합니다. ``` $ less /var/log/chef-client.log ``` 1. cfn-init 로그에서 패키지 종속성 충돌을 찾습니다. ``` $ less /var/log/cfn-init.log ``` #### 해결 방법 1. 특정 패키지에서 문제가 발생하는 경우 다시 설치해 보십시오. ``` $ sudo yum reinstall package-name ``` 1. 종속성 충돌의 경우 충돌하는 패키지를 제거해야 할 수 있습니다. ``` $ sudo yum remove conflicting-package ``` 1. 문제가 지속되면 `pcluster build-image` 명령을 사용하여 필요한 패키지가 사전 설치된 사용자 지정 AMI를 생성하는 것이 좋습니다. 자세한 내용은 [AWS ParallelCluster AMI 사용자 지정](custom-ami-v3.md) 단원을 참조하십시오. ### 시스템 구성 파일 수정 중요한 시스템 구성 파일을 수정하면 특히 이러한 파일을에서 관리하는 경우 클러스터 오류가 발생할 수 있습니다 AWS ParallelCluster. #### 진단 방법 1. Chef-client 로그에서 특정 구성 파일을 언급하는 오류가 있는지 확인합니다. ``` $ grep -i "config" /var/log/chef-client.log ``` 1. 구성 파일에서 권한 또는 구문 오류를 찾습니다. ``` $ less /var/log/cfn-init.log ``` #### 해결 방법 1. 수정된 구성 파일을 원래 상태로 복원합니다. ``` $ sudo cp /etc/file.conf.bak /etc/file.conf ``` 1. 시스템 구성 파일을 지속적으로 변경해야 하는 경우 파일을 직접 수정하는 대신 사용자 지정 부트스트랩 작업을 사용합니다. ``` HeadNode: CustomActions: OnNodeConfigured: Script: s3://bucket-name/config-script.sh ``` 자세한 내용은 [사용자 지정 부트스트랩 작업](custom-bootstrap-actions-v3.md) 단원을 참조하십시오. 1. 시스템 파일을 직접 변경해야 하는 구성 변경의 경우 사용자 지정 AMI를 생성하는 것이 좋습니다. 자세한 내용은 [AWS ParallelCluster AMI 사용자 지정](custom-ami-v3.md) 단원을 참조하십시오. ### 커널 업데이트 및 호환성 문제 커널 업데이트는 특정 AWS 서비스, 특히 Amazon FSx for Lustre와의 호환성 문제를 일으킬 수 있습니다. #### 진단 방법 1. 커널 업데이트가 적용되었는지 확인합니다. ``` $ uname -r ``` 1. 로그에서 Amazon FSx 탑재 실패를 찾습니다. ``` $ grep -i "fsx" /var/log/chef-client.log ``` #### 해결 방법 1. Ubuntu 22.04의 경우 해당 커널에 대한 Amazon FSx 클라이언트가 없으므로 최신 커널로 업데이트하지 마세요. 자세한 내용은 [운영 체제 고려 사항](operating-systems-v3.md#OS-Consideration-v3) 단원을 참조하십시오. 1. 커널을 이미 업데이트했는데 문제가 발생하는 경우 호환되는 커널 버전으로 다운그레이드하는 것이 좋습니다. ``` $ sudo apt install linux-image-previous-version ``` 1. 영구 커널 사용자 지정의 경우 필요한 특정 커널 버전으로 사용자 지정 AMI를 생성합니다. 자세한 내용은 [AWS ParallelCluster AMI 사용자 지정](custom-ami-v3.md) 단원을 참조하십시오. ## OS 구성 변경 모범 사례 OS 구성 변경 시 문제를 최소화하려면: 1. **사용자 지정 부트스트랩 작업 사용**: 시스템 파일을 직접 수정하는 대신 `OnNodeStart` 또는 `OnNodeConfigured` 스크립트를 사용하여 제어된 방식으로 변경합니다. 자세한 내용은 [사용자 지정 부트스트랩 작업](custom-bootstrap-actions-v3.md) 단원을 참조하십시오. 1. **사용자 지정 AMIs**: OS를 크게 수정하려면 실행 중인 인스턴스를 변경하는 `pcluster build-image` 대신를 사용하여 사용자 지정 AMI를 생성합니다. 자세한 내용은 [AWS ParallelCluster AMI 사용자 지정](custom-ami-v3.md) 단원을 참조하십시오. 1. **변경 사항 테스트 우선**: 프로덕션 클러스터에 변경 사항을 적용하기 전에 작은 테스트 클러스터에서 변경 사항을 테스트하여 호환성을 확인합니다. 1. **문서 변경**: 문제 해결을 용이하게 하기 위해 모든 OS 구성 변경 사항을 추적합니다. 1. **백업 구성 파일**: 시스템 구성 파일을 수정하기 전에 백업을 생성합니다. ``` $ sudo cp /etc/file.conf /etc/file.conf.bak ``` 1. **변경 후 로그 확인**: OS 구성을 변경한 후 로그에 오류가 있는지 확인합니다. ``` $ less /var/log/cfn-init.log $ less /var/log/chef-client.log ``` 이러한 지침을 따르면 OS 구성 변경으로 인해 클러스터 장애가 발생할 위험을 최소화하고 발생하는 문제를 보다 효과적으로 해결할 수 있습니다.