기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS PCS 클러스터 버전 업데이트 문제 해결 이 주제는 클러스터에서 스케줄러 버전을 업데이트할 때 발생할 수 있는 일반적인 문제를 식별하고 해결하는 데 도움이 됩니다. + [업데이트 후 컴퓨팅 노드 연결 실패](#update-troubleshooting-nodes-fail) + [ValidationException에서 업데이트 요청이 거부됨](#update-troubleshooting-validation-error) + [클러스터가 업데이트 중 상태로 유지됨](#update-troubleshooting-stuck-updating) + [업데이트 후 클러스터가 UPDATE\_FAILED 상태로 전환됨](#update-troubleshooting-update-failed) + [구성 구문 분석 오류로 인해 컴퓨팅 노드가 시작되지 않음](#update-troubleshooting-config-parse) + [잘못된 QoS 구성으로 인해 업데이트 후 클러스터를 사용할 수 없음](#update-troubleshooting-qos-bootloop) ## 업데이트 후 컴퓨팅 노드 연결 실패 ### 일반적인 원인 클러스터를 업데이트한 후 새로 시작된 컴퓨팅 노드가 컨트롤러에 등록되지 않습니다. 노드가 시작되지만 `sinfo` 출력에는 나타나지 않으며 컴퓨팅 노드 그룹은 인스턴스를 반복적으로 순환할 수 있습니다. 이는 컴퓨팅 노드 그룹의 AMI에 새 컨트롤러 버전의 호환성 기간을 벗어나는 스케줄러 버전이 포함되어 있을 때 발생합니다. 예를 들어 클러스터를 24.11에서 25.11로 업데이트하지만 컴퓨팅 노드 그룹이 여전히 Slurm 23.11의 AMI를 사용하는 경우 23.11이 25.11의 호환성 기간을 벗어났기 때문에 새 인스턴스를 연결할 수 없습니다. ### 진단 방법 다음 두 위치에서 로그를 확인하여이 문제를 확인할 수 있습니다. **스케줄러 로그** 스케줄러 로깅을 활성화한 경우 CloudWatch Logs의 스케줄러 로그에서 다음과 유사한 오류가 있는지 확인합니다. ``` error: unpack_header: protocol_version 10240 not supported error: slurm_unpack_received_msg: [{{ip-10-0-1-23}}] Incompatible versions of client and server code ``` 이러한 오류는 스케줄러 버전이 호환되지 않는 컴퓨팅 노드가 컨트롤러에 연결을 시도하고 있음을 나타냅니다. 스케줄러 로깅 설정에 대한 자세한 내용은 섹션을 참조하세요[AWS PCS의 스케줄러 로그](monitoring_scheduler-logs.md). **컴퓨팅 노드 인스턴스 로그** 인스턴스 콘솔 출력을 검색하거나 Systems Manager를 통해 연결하고 부트스트랩 로그에서 다음과 유사한 오류가 있는지 확인합니다. ``` error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server error: _establish_configuration: failed to load configs error: slurmd initialization failed ``` 인스턴스 로그 검색에 대한 자세한 내용은 섹션을 참조하세요[인스턴스 로그 검색](troubleshooting-compute-node-bootstrap.md#troubleshooting-compute-node-bootstrap-retrieve-logs). ### 해결 방법 새 클러스터 버전의 호환성 기간 내에 스케줄러 버전이 포함된 AMI를 사용하도록 컴퓨팅 노드 그룹을 업데이트합니다. ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --ami-id {{ami-0123456789abcdef0}} ``` 클러스터와 호환되는 스케줄러 버전을 확인하려면 섹션을 참조하세요[버전 호환성](working-with_clusters_version_update.md#version_update-cluster-compatibility). 올바른 스케줄러 버전으로 사용자 지정 AMIs하는 방법에 대한 자세한 내용은 섹션을 참조하세요[AWS PCS용 Amazon Machine Image(AMIs)](working-with_ami.md). ## ValidationException에서 업데이트 요청이 거부됨 ### 일반적인 원인 `UpdateCluster` 요청은 업데이트가 지원되지 않음을 나타내는 `ValidationException` 오류와 함께 즉시 반환됩니다. 이는 다음과 같은 경우에 발생합니다. + 대상 버전이 현재 버전의 [호환성 기간을](https://slurm.schedmd.com/upgrades.html#compatibility_window) 벗어났습니다. + 대상 버전은 수명 종료(EOL)로 지정되며 더 이상 유효한 업데이트 대상이 아닙니다. + 대상 버전이 현재 버전보다 이전 버전입니다(다운그레이드는 지원되지 않음). ### 해결 방법 대상 버전이 호환성 기간을 벗어나는 경우 여러 단계로 업데이트를 수행합니다. 각 단계는 호환성 기간 내에서 지원되는 버전을 대상으로 해야 합니다. 예를 들어 23.11에서 25.11로 전환하려면 먼저 25.05로 업데이트하고 클러스터가 로 돌아갈 때까지 기다린 `ACTIVE`다음 25.11로 업데이트합니다. 대상 버전이 EOL인 경우 지원되는 최신 버전을 대신 선택합니다. 지원되는 버전에 대한 자세한 내용은 섹션을 참조하세요[AWS PCS의 Slurm 버전](slurm-versions.md). ## 클러스터가 업데이트 중 상태로 유지됨 ### 일반적인 원인 클러스터는 예상보다 오래(20분 이상) `UPDATING` 상태를 유지합니다. 이는 업데이트 프로세스 중에 일시적인 내부 문제로 인해 발생할 수 있습니다. ### 해결 방법 AWS PCS는 `UPDATING` 상태로 멈춘 클러스터를 자동으로 복구합니다. 클러스터가 `ACTIVE` 또는 30분 `UPDATE_FAILED` 이내에 로 돌아가지 않는 경우 AWS Support에 문의하여 지원을 받으세요. ## 업데이트 후 클러스터가 UPDATE\_FAILED 상태로 전환됨 ### 일반적인 원인 업데이트 중에 클러스터가 `UPDATE_FAILED` 상태로 전환됩니다. 이는 일시적인 서비스 오류로 인해 업데이트가 성공적으로 완료되지 않을 때 발생할 수 있습니다. ### 해결 방법 동일한 `UpdateCluster` 요청을 다시 제출하여 업데이트를 재시도합니다. `UPDATE_FAILED` 상태의 클러스터는 새 업데이트 요청을 수락합니다. 업데이트가 계속 실패하면 AWS Support에 문의하십시오. ## 구성 구문 분석 오류로 인해 컴퓨팅 노드가 시작되지 않음 ### 일반적인 원인 클러스터를 업데이트한 후 컴퓨팅 노드가 시작되지 않고 `sinfo` 출력에 표시되지 않습니다. 컴퓨팅 노드 인스턴스 로그에는 다음과 유사한 오류가 표시됩니다. ``` error: _parse_next_key: Parsing error at unrecognized key: {{HashPlugin}} error: Invalid DebugFlag: {{AuditRPCs}} fatal: Unable to process configuration file ``` 이는 스케줄러 버전 23.11을 실행하는 컴퓨팅 노드가 최신 클러스터 버전에서 구성을 수신할 때 발생합니다. 23.11 이후 스케줄러 버전에는 23.11에서 구문 분석할 수 없는 새로운 구성 명령이 도입되었습니다. [호환성 기간](https://slurm.schedmd.com/upgrades.html#compatibility_window) 내의 다른 버전과 달리 23.11 컴퓨팅 노드는 인식할 수 없는 구성 키에서 치명적인 오류가 발생하기 때문에 최신 클러스터에 연결할 수 없습니다. 이 문제는 사용자 지정 AMI가 v1.4.0 이전의 AWS PCS 에이전트 버전을 사용하는 경우에도 발생할 수 있습니다. 이전 에이전트 버전은 컴퓨팅 노드 데몬에 대한 자동 버전 폴백을 지원하지 않습니다. ### 해결 방법 다음 요구 사항에 따라 사용자 지정 AMI를 다시 빌드합니다. + 스케줄러 버전 24.05 이상 + AWS PCS 에이전트 버전 1.4.0 이상 그런 다음 새 AMI를 사용하도록 컴퓨팅 노드 그룹을 업데이트합니다. ``` aws pcs update-compute-node-group \ --cluster-identifier {{my-cluster}} \ --compute-node-group-identifier {{my-cng}} \ --ami-id {{ami-0123456789abcdef0}} ``` 사용자 지정 AMIs[AWS PCS용 Amazon Machine Image(AMIs)](working-with_ami.md). AWS PCS 에이전트 버전에 대한 자세한 내용은 섹션을 참조하세요[AWS PCS 에이전트 버전](pcs-agent-versions.md). ## 잘못된 QoS 구성으로 인해 업데이트 후 클러스터를 사용할 수 없음 ### 일반적인 원인 버전 25.11로 업데이트한 후 클러스터가 `UPDATE_FAILED` 상태가 되거나 스케줄러를 사용할 수 없게 됩니다. 작업을 제출하거나 스케줄러 명령을 실행할 수 없습니다. 스케줄러 로그에는 다음과 유사한 오류가 표시됩니다. ``` error: Invalid Allow/DenyQOS value: {{low}} fatal: Partition {{my-queue}} has an invalid DenyQOS ({{low}}), please check your configuration ``` 이는 대기열(파티션)이 Slurm 회계 데이터베이스에 없는 `DenyQOS`, 또는 `QOS` 설정을 통해 `AllowQOS`QoS 이름을 참조할 때 발생합니다. Slurm 25.11은 스케줄러 시작 시 QoS 참조에 대한 더 엄격한 검증을 도입했습니다. 이전 버전에서는 존재하지 않는 QoS 이름에 대한 참조가 오류 없이 허용되었습니다. ### 해결 방법 버전 25.11로 업데이트하기 전에 대기열 구성에서 참조되는 모든 QoS 이름이 회계 데이터베이스에 있는지 확인합니다. 로그인 노드에 연결하고 다음 명령을 실행하여 QoS가 존재하는지 확인합니다. ``` sacctmgr show qos where name={{low}} format=name ``` QoS가 존재하지 않는 경우 업데이트를 시도하기 전에 생성합니다. ``` sacctmgr add qos {{low}} ``` 또는 클러스터를 업데이트하기 전에 대기열의 Slurm 사용자 지정 설정을 업데이트하여 `AllowQOS`, `DenyQOS`또는 `QOS` 파라미터를 제거하여 대기열 구성에서 QoS 참조를 제거합니다.