기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# SageMaker HyperPod FAQ
다음 자주 묻는 질문을 사용하여 SageMaker HyperPod 사용 관련 문제를 해결합니다.
**Topics**
+ [Amazon CloudWatch에서 내 SageMaker HyperPod 클러스터의 로그 그룹을 찾을 수 없는 이유는 무엇인가요?](#hyperpod-faqs-q1)
+ [HyperPod는 `slurm.conf` 및 `gres.conf`와 같은 Slurm 구성 파일에서 특히 어떤 구성을 관리하나요?](#hyperpod-faqs-q2)
+ [HyperPod의 Slurm 노드에서 어떻게 Docker를 실행하나요?](#hyperpod-faqs-q3)
+ [SageMaker HyperPod 플랫폼에서 Slurm과 함께 NVIDIA Collective Communications Library(NCCL)를 사용할 때 병렬 훈련 작업이 실패하는 이유는 무엇인가요?](#hyperpod-faqs-q4)
+ [Slurm에서 Docker 또는 Enroot 컨테이너를 시작하기 위해 P 인스턴스의 로컬 NVMe 스토어를 사용하려면 어떻게 해야 하나요?](#hyperpod-faqs-q5)
+ [EFA 보안 그룹을 설정하는 방법은 무엇인가요?](#hyperpod-faqs-q6)
+ [HyperPod 클러스터 노드를 모니터링하려면 어떻게 해야 하나요? HyperPod에서 내보낸 CloudWatch 지표가 있나요?](#hyperpod-faqs-q7)
+ [HyperPod 클러스터 노드에 추가 스토리지를 추가할 수 있나요? 클러스터 인스턴스의 로컬 인스턴스 스토어는 제한됩니다.](#hyperpod-faqs-q8)
+ [재부팅 후 컴퓨팅 노드가 'DOWN' 또는 'DRAINED'로 표시되는 이유는 무엇인가요?](#hyperpod-faqs-q9)
+ [메모리 부족(OOM) 문제로 인해 노드가 계속 드레이닝되는 이유는 무엇인가요?](#hyperpod-faqs-q10)
+ [작업이 완료된 후 리소스가 제대로 정리되도록 하려면 어떻게 해야 하나요?](#hyperpod-faqs-q11)
## Amazon CloudWatch에서 내 SageMaker HyperPod 클러스터의 로그 그룹을 찾을 수 없는 이유는 무엇인가요?
기본적으로 에이전트 로그와 인스턴스 시작 로그는 HyperPod 플랫폼 계정의 CloudWatch로 전송됩니다. 사용자 수명 주기 스크립트의 경우 수명 주기 구성 로그가 계정의 CloudWatch로 전송됩니다.
HyperPod 서비스 팀이 제공하는 [샘플 수명 주기 스크립트](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)를 사용하는 경우 `/var/log/provision/provisioning.log`에 작성된 수명 주기 구성 로그를 찾을 수 있으며 이 문제가 발생하지 않습니다.
그러나 수명 주기 프로비저닝에서 로그를 수집하는 데 사용자 지정 경로를 사용하고 계정의 CloudWatch 에 나타나는 로그 그룹을 찾을 수 없는 경우 수명 주기 스크립트에 지정된 로그 파일 경로와 HyperPod 클러스터 인스턴스에서 실행되는 CloudWatch 에이전트가 무엇을 찾는지 일치하지 않기 때문일 수 있습니다. 이 경우 CloudWatch 에이전트에 로그를 전송하려면 수명 주기 스크립트를 올바르게 설정하고 그에 따라 CloudWatch 에이전트 구성을 설정해야 합니다. 문제를 해결하려면 다음 옵션 중 하나를 선택합니다.
+ **옵션 1:** 수명 주기 스크립트를 업데이트하여 `/var/log/provision/provisioning.log`에 로그를 작성합니다.
+ **옵션 2:** CloudWatch 에이전트를 업데이트하여 로깅 수명 주기 프로비저닝을 위한 사용자 지정 경로를 찾습니다.
1. 각 HyperPod 클러스터 인스턴스에는 `/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json`의 JSON 형식의 CloudWatch 에이전트 구성 파일이 포함되어 있습니다. 구성 파일에서 필드 이름 `logs.logs_collected.files.collect_list.file_path`을 찾습니다. HyperPod에 의한 기본 설정으로 키-값 페어는 `"file_path": "/var/log/provision/provisioning.log"`에 설명된 대로 [인스턴스 수준에서 SageMaker HyperPod 로깅](sagemaker-hyperpod-cluster-management-slurm.md#sagemaker-hyperpod-cluster-management-slurm-logging-at-instance-level)이어야 합니다. 다음 코드 조각은 JSON 파일이 HyperPod 기본 구성으로 어떻게 표시되는지 보여줍니다.
```
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/provision/provisioning.log",
"log_group_name": "/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]",
"log_stream_name": "LifecycleConfig/[InstanceGroupName]/{instance_id}",
"retention_in_days": -1
}
]
}
},
"force_flush_interval": 3
}
```
1. `"file_path"` 필드 이름의 값을 수명 주기 스크립트에 사용하는 사용자 지정 경로로 바꿉니다. 예를 들어 `/var/log/custom-provision/custom-provisioning.log`에 쓰도록 수명 주기 스크립트를 설정한 경우 다음과 같이 값과 일치하도록 값을 업데이트합니다.
```
"file_path": "/var/log/custom-provision/custom-provisioning.log"
```
1. 구성 파일로 CloudWatch 에이전트를 다시 시작하여 사용자 지정 경로 적용을 완료합니다. 예를 들어 다음 CloudWatch 명령은 1단계의 CloudWatch 에이전트 구성 파일로 CloudWatch 에이전트를 다시 시작하는 방법을 보여줍니다. 자세한 내용은 [CloudWatch 에이전트 설치](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html)를 참조하세요.
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -s -c \
file:/opt/aws/amazon-cloudwatch-agent/sagemaker_cwagent_config.json
```
## HyperPod는 `slurm.conf` 및 `gres.conf`와 같은 Slurm 구성 파일에서 특히 어떤 구성을 관리하나요?
HyperPod 에서 Slurm 클러스터를 생성하면 HyperPod 에이전트는 [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html) 및 [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html) 파일을 `/opt/slurm/etc/`에 설정하여 HyperPod 클러스터 생성 요청 및 수명 주기 스크립트를 기반으로 Slurm 클러스터를 관리합니다. 다음 목록은 HyperPod 에이전트가 처리하고 덮어쓰는 특정 파라미터를 보여줍니다.
**중요**
HyperPod에서 관리하는 이러한 파라미터를 변경하지 않는 것이 좋습니다.
+ [https://slurm.schedmd.com/slurm.conf.html](https://slurm.schedmd.com/slurm.conf.html)에서 HyperPod는, `ClusterName`, `SlurmctldHost`, `PartitionName` 및 `NodeName` 같은 기본 파라미터를 설정합니다.
또한 [자동 노드 복구 및 자동 재개](sagemaker-hyperpod-resiliency-slurm-auto-resume.md) 기능을 활성화하려면 HyperPod에 다음과 같이 설정된 `TaskPlugin` 및 `SchedulerParameters` 파라미터가 필요합니다. HyperPod 에이전트는 기본적으로 필요한 값으로 이러한 두 파라미터를 설정합니다.
```
TaskPlugin=task/none
SchedulerParameters=permit_job_expansion
```
+ [https://slurm.schedmd.com/gres.conf.html](https://slurm.schedmd.com/gres.conf.html)에서 HyperPod는 GPU 노드의 `NodeName`을 관리합니다.
## HyperPod의 Slurm 노드에서 어떻게 Docker를 실행하나요?
HyperPod에서 실행되는 Slurm 노드에서 Docker를 실행하는 데 도움이 되도록 HyperPod 서비스 팀은 클러스터 생성을 위한 수명 주기 구성의 일부로 포함할 수 있는 설정 스크립트를 제공합니다. 자세한 내용은 [HyperPod에서 제공하는 기본 수명 주기 스크립트](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 및 [HyperPod의 Slurm 컴퓨팅 노드에서 Docker 컨테이너 실행](sagemaker-hyperpod-run-jobs-slurm-docker.md) 섹션을 참조하세요.
## SageMaker HyperPod 플랫폼에서 Slurm과 함께 NVIDIA Collective Communications Library(NCCL)를 사용할 때 병렬 훈련 작업이 실패하는 이유는 무엇인가요?
기본적으로 Linux OS는 `#RemoveIPC=yes` 플래그를 설정합니다. NCCL을 사용하는 Slurm 및 mpirun 작업은 루트 사용자가 아닌 세션에서 프로세스 간 통신(IPC) 리소스를 생성합니다. 이러한 사용자 세션은 작업 프로세스 중에 로그아웃될 수 있습니다.
Slurm 또는 mpirun으로 작업을 실행할 때 `systemd`에서 사용자가 로그인하지 않았음을 감지하면 IPC 리소스가 정리됩니다. Slurm 및 mpirun 작업은 사용자가 로그인하지 않아도 실행될 수 있지만 그러기 위해서는 시스템 수준에서 정리를 비활성화하고 Slurm 수준에서 정리를 설정해야 합니다. 자세한 내용은 [Systemd in the NCCL documentation](https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/troubleshooting.html#systemd)을 참조하세요.
시스템 수준에서 정리를 비활성화하려면 다음 단계를 완료하세요.
1. Slurm 및 NCCL을 사용하는 훈련 작업을 실행하는 경우 `/etc/systemd/logind.conf` 파일에서 `#RemoveIPC=no` 플래그를 설정합니다.
1. 기본적으로 Slurm은 공유 리소스를 정리하지 않습니다. 공유 리소스를 정리하려면 Slurm 에필로그 스크립트를 설정하는 것이 좋습니다. 이 정리는 공유 리소스가 많고 훈련 작업 후 정리하려는 경우에 유용합니다. 다음은 예제 스크립트입니다.
```
#!/bin/bash
: <<'SUMMARY'
Script: epilog.sh
Use this script with caution, as it can potentially delete unnecessary resources and cause issues if you don't use it correctly.
Note: You must save this script in a shared in a shared location that is accessible to all nodes in the cluster, such as /fsx volume.
Workers must be able to access the script to run the script after jobs.
SUMMARY
# Define the log directory and create it if it doesn't exist
LOG_DIR="//epilogue" #NOTE: Update PLACEHOLDER to be a shared value path, such as /fsx/epilogue.
mkdir -p "$LOG_DIR"
# Name the log file using the Slurm job name and job ID
log_file="$LOG_DIR/epilogue-${SLURM_JOB_NAME}_${SLURM_JOB_ID}.log"
logging() {
echo "[$(date)] $1" | tee -a "$log_file"
}
# Slurm epilogue script to clean up IPC resources
logging "Starting IPC cleanup for Job $SLURM_JOB_ID"
# Clean up shared memory segments by username
for seg in $(ipcs -m | awk -v owner="$SLURM_JOB_USER" '$3 == owner {print $2}'); do
if ipcrm -m "$seg"; then
logging "Removed shared memory segment $seg"
else
logging "Failed to remove shared memory segment $seg"
fi
done
# Clean up semaphores by username
for sem in $(ipcs -s | awk -v user="$SLURM_JOB_USER" '$3 == user {print $2}'); do
if ipcrm -s "$sem"; then
logging "Removed semaphore $sem"
else
logging "Failed to remove semaphore $sem"
fi
done
# Clean up NCCL IPC
NCCL_IPC_PATH="/dev/shm/nccl-*"
for file in $NCCL_IPC_PATH; do
if [ -e "$file" ]; then
if rm "$file"; then
logging "Removed NCCL IPC file $file"
else
logging "Failed to remove NCCL IPC file $file"
fi
fi
done
logging "IPC cleanup completed for Job $SLURM_JOB_ID"
exit 0
```
에필로그 파라미터에 대한 자세한 내용은 [Slurm documentation](https://slurm.schedmd.com/slurm.conf.html#OPT_Epilog)을 참조하세요.
1. 생성한 에필로그 스크립트를 가리키는 줄을 컨트롤러 노드의 `slurm.conf` 파일에 추가합니다.
```
Epilog="/path/to/epilog.sh" #For example: /fsx/epilogue/epilog.sh
```
1. 다음 명령을 실행하여 스크립트의 권한을 변경하고 실행 가능하게 만듭니다.
```
chown slurm:slurm /path/to/epilog.sh
chmod +x /path/to/epilog.sh
```
1. 모든 변경 사항을 적용하려면 `scontrol reconfigure`를 실행합니다.
## Slurm에서 Docker 또는 Enroot 컨테이너를 시작하기 위해 P 인스턴스의 로컬 NVMe 스토어를 사용하려면 어떻게 해야 하나요?
헤드 노드의 기본 루트 볼륨은 일반적으로 100GB EBS 볼륨으로 제한되므로 로컬 NVMe 인스턴스 스토어를 사용하도록 Docker 및 Enroot를 설정해야 합니다. NVMe 스토어를 설정하고 Docker 컨테이너를 시작하는 데 사용하는 방법을 알아보려면 [HyperPod의 Slurm 컴퓨팅 노드에서 Docker 컨테이너 실행](sagemaker-hyperpod-run-jobs-slurm-docker.md) 섹션을 참조하세요.
## EFA 보안 그룹을 설정하는 방법은 무엇인가요?
EFA 지원 인스턴스를 사용하여 HyperPod 클러스터를 생성하려면 보안 그룹 자체를 오가는 모든 인바운드 및 아웃바운드 트래픽을 허용하도록 보안 그룹을 설정해야 합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [1단계: EFA 지원 보안 그룹 준비](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security)를 참조하세요.
## HyperPod 클러스터 노드를 모니터링하려면 어떻게 해야 하나요? HyperPod에서 내보낸 CloudWatch 지표가 있나요?
HyperPod 클러스터의 리소스 사용률을 관찰하려면 HyperPod 클러스터를 Amazon Managed Grafana 및 Amazon Managed Service for Prometheus와 통합하는 것이 좋습니다. 다양한 오픈 소스 Grafana 대시보드 및 내보내기 패키지를 사용하면 HyperPod 클러스터 리소스와 관련된 지표를 내보내고 시각화할 수 있습니다. Amazon Managed Grafana 및 Amazon Managed Service for Prometheus에서 SageMaker HyperPod를 설정하는 방법에 대한 자세한 내용은 [SageMaker HyperPod 클러스터 리소스 모니터링](sagemaker-hyperpod-cluster-observability-slurm.md) 섹션을 참조하세요. SageMaker HyperPod는 현재 시스템 지표를 Amazon CloudWatch 로 내보내는 것을 지원하지 않습니다.
## HyperPod 클러스터 노드에 추가 스토리지를 추가할 수 있나요? 클러스터 인스턴스의 로컬 인스턴스 스토어는 제한됩니다.
워크로드에 기본 인스턴스 스토리지가 충분하지 않은 경우 인스턴스당 추가 스토리지를 구성할 수 있습니다. [2024년 6월 20일 릴리스](sagemaker-hyperpod-release-notes.md#sagemaker-hyperpod-release-notes-20240620)부터 SageMaker HyperPod 클러스터의 각 인스턴스에 Amazon Elastic Block Store(EBS) 볼륨을 추가할 수 있습니다. 이 기능은 2024년 6월 20일 이전에 생성된 SageMaker HyperPod 클러스터의 기존 인스턴스 그룹에 적용할 수 없습니다. 2024년 6월 20일 이전에 생성된 기존 SageMaker HyperPod 클러스터를 패치하고 새 인스턴스 그룹을 추가하여 이 기능을 활용할 수 있습니다. 이 기능은 2024년 6월 20일 이후에 생성된 모든 SageMaker HyperPod 클러스터에 대해 완전히 유효합니다.
## 재부팅 후 컴퓨팅 노드가 'DOWN' 또는 'DRAINED'로 표시되는 이유는 무엇인가요?
이는 일반적으로 Slurm의 제어 인터페이스 대신 `sudo reboot`를 사용하여 노드를 재부팅할 때 발생합니다. 노드를 올바르게 재부팅하려면 Slurm 명령 `scontrol reboot nextstate=resume `를 사용하세요. 이렇게 하면 Slurm이 노드 상태를 적절하게 제어하고 재부팅 후 정상 작업을 재개할 수 있습니다.
GPU 인스턴스(예: NVIDIA P5)의 경우 노드가 Slurm의 기본 시간 제한(60초) 내에 부팅 프로세스를 완료할 수 없는 경우에도 이 문제가 발생할 수 있습니다. 이 문제를 해결하려면 `slurm.conf`의 `TimeToResume` 파라미터를 300초로 늘리세요. 이렇게 하면 GPU 인스턴스가 드라이버를 부팅하고 초기화할 수 있는 충분한 시간을 확보할 수 있습니다.
## 메모리 부족(OOM) 문제로 인해 노드가 계속 드레이닝되는 이유는 무엇인가요?
OOM 문제는 작업이 노드의 메모리 용량을 초과할 때 발생합니다. 이를 방지하려면 `cgroups`을 구현하여 작업당 메모리 한도를 적용하세요. 이렇게 하면 단일 작업이 전체 노드에 영향을 미치지 않도록 예방할 수 있고 격리 및 안정성이 향상됩니다.
`slurm.conf`의 설정 예시:
```
TaskPlugin=task/cgroup
```
`cgroup.conf`의 설정 예시:
```
CgroupAutomount=yes
ConstrainCores=yes
CgroupPlugin=autodetect
ConstrainDevices=yes
ConstrainRAMSpace=yes
ConstrainSwapSpace=yes
SignalChildrenProcesses=yes
MaxRAMPercent=99
MaxSwapPercent=80
MinRAMSpace=100
```
자세한 내용은 [Control Group in Slurm](https://slurm.schedmd.com/cgroups.html), [Cgroup and PAM-based login control for Slurm compute nodes](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils/pam_adopt_cgroup_wheel.sh#L197), [Configure Cgroups for Slurm](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/16-enable-cgroups)을 참조하세요.
## 작업이 완료된 후 리소스가 제대로 정리되도록 하려면 어떻게 해야 하나요?
작업이 완료된 후 리소스를 자동으로 정리하도록 에필로그 스크립트를 구현합니다. 작업이 예기치 않게 충돌하거나, 정상적인 정리를 방해하는 버그가 포함되거나, 공유 메모리 버퍼(프로세스와 GPU 드라이버 간에 공유된 것 포함)가 할당된 상태로 유지되는 경우 리소스가 올바르게 정리되지 않을 수 있습니다.
에필로그 스크립트는 GPU 메모리 지우기, 임시 파일 제거, 파일 시스템 탑재 해제와 같은 작업을 수행할 수 있습니다. 이러한 스크립트는 리소스가 단일 작업에만 할당되지 않는 경우 제한이 있습니다. 자세한 지침과 샘플 스크립트는 [SageMaker HyperPod 플랫폼에서 Slurm과 함께 NVIDIA Collective Communications Library(NCCL)를 사용할 때 병렬 훈련 작업이 실패하는 이유는 무엇인가요?](#hyperpod-faqs-q4) 질문의 두 번째 글머리 기호를 참조하세요. 자세한 내용은 [Enable Slurm epilog script](https://catalog.workshops.aws/sagemaker-hyperpod/en-US/07-tips-and-tricks/18-slurm-epilogue)를 참조하세요.