기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# SageMaker HyperPod 클러스터 복원력
SageMaker HyperPod through Slurm 오케스트레이션은 다음과 같은 클러스터 복원력 기능을 제공합니다.
**Topics**
+ [상태 모니터링 에이전트](sagemaker-hyperpod-resiliency-slurm-cluster-health-check.md)
+ [자동 노드 복구 및 자동 재개](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)
+ [Slurm을 사용하여 수동으로 노드 교체 또는 재부팅](sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.md)
# 상태 모니터링 에이전트
이 섹션에서는 SageMaker HyperPod가 클러스터 인스턴스 상태를 정기적으로 모니터링하여 액셀러레이터(GPU 및 Trainium 코어) 및 네트워킹(EFA)과 같은 디바이스 관련 문제를 모니터링하는 데 사용하는 상태 확인 세트를 설명합니다. SageMaker HyperPod 상태 모니터링 에이전트(HMA)는 각 GPU 기반 또는 Trainium 기반 인스턴스의 상태를 지속적으로 모니터링합니다. 인스턴스 또는 GPU 실패를 감지하면 에이전트는 인스턴스를 비정상으로 표시합니다.
SageMaker HyperPod HMA는 EKS와 Slurm 오케스트레이터 모두에 대해 동일한 상태 확인을 수행합니다. HMA에 대한 자세한 내용은 섹션을 참조하세요[상태 모니터링 시스템](sagemaker-hyperpod-eks-resiliency-health-monitoring-agent.md).
# 자동 노드 복구 및 자동 재개
**참고**
2025년 9월 11일부터 Slurm 오케스트레이션을 사용하는 HyperPod는 이제 상태 모니터링 에이전트를 지원합니다. 이 기능을 사용하려면 [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html)를 실행하고 최신 버전의 AMI로 업데이트합니다.
이 섹션에서는 Amazon SageMaker HyperPod의 두 가지 보완적인 복원력 기능인 수동 개입 없이 장애가 있는 인프라를 대체하는 자동 노드 복구와 하드웨어 장애 후 마지막 체크포인트에서 훈련 작업을 다시 시작하는 자동 재개 기능에 대해 설명합니다.
## 자동 노드 복구 작동 방식
클러스터 생성 또는 업데이트 중에 클러스터 관리자 사용자는 클러스터 수준의 `Automatic`(권장) 및 `None` 사이에서 노드(인스턴스) 복구 옵션을 선택할 수 있습니다. `Automatic`로 설정하면 SageMaker HyperPod가 자동으로 재부팅되거나 결함이 있는 노드를 교체합니다.
**중요**
`Automatic` 옵션을 설정하는 것이 좋습니다. 기본적으로 클러스터는 자동 노드 복구로 설정됩니다.
자동 노드 복구는 상태 모니터링 에이전트, 기본 상태 확인 및 심층 상태 확인에서 문제가 발견될 때 실행됩니다. `None`로 설정하면 상태 모니터링 에이전트는 오류가 감지될 때 인스턴스에 레이블을 지정하지만 영향을 받는 노드에서 복구 작업을 자동으로 시작하지는 않습니다. 이 옵션은 권장하지 않습니다.
## Amazon SageMaker HyperPod 자동 재개 기능을 사용하여 훈련 작업 실행
이 섹션에서는 하드웨어 장애가 발생할 경우 마지막으로 저장된 체크포인트에서 훈련 작업을 자동으로 복구할 수 있는 제로 터치 복원력 인프라를 제공하는 SageMaker HyperPod 자동 재개 기능을 사용하여 훈련 작업을 실행하는 방법을 설명합니다.
자동 재개 기능을 사용하면 하드웨어 장애 또는 훈련 간 일시적인 문제로 인해 작업이 실패하는 경우 SageMaker HyperPod 자동 재개는 노드 교체 워크플로를 시작하고 결함이 있는 노드를 교체한 후 작업을 다시 시작합니다. 자동 재개를 사용하는 동안 작업이 실패할 때마다 다음 하드웨어 검사가 실행됩니다.
| 카테고리 | 유틸리티 이름 | 인스턴스 유형 호환성 | 설명 |
| --- | --- | --- | --- |
| 액셀러레이터 | NVIDIA SMI | GPU | [nvidia-smi](https://developer.nvidia.com/nvidia-system-management-interface) 유틸리티는 GPU를 관리 및 모니터링하기 위한 잘 알려진 CLI입니다. 기본 제공 상태 확인기는 nvidia-smi의 출력을 구문 분석하여 인스턴스의 상태를 확인합니다. |
| 액셀러레이터 | Neuron sysfs | Trainium | Trainium 기반 인스턴스의 경우 Neuron 드라이버가 직접 전파하는 [Neuron sysfs](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/tools/neuron-sys-tools/neuron-sysfs-user-guide.html)의 카운터를 읽고 Neuron 디바이스의 상태를 확인합니다. |
| Network | EFA | GPU 및 Trainium | EFA(Elastic Fabric Adaptor) 디바이스의 진단을 돕기 위해 EFA 상태 확인기는 인스턴스 내에서 사용 가능한 모든 EFA 카드를 사용하여 일련의 연결 테스트를 실행합니다. |
**참고**
[일반 리소스(GRES)](https://slurm.schedmd.com/gres.html)가 Slurm 노드에 연결된 경우 Slurm은 일반적으로 노드 교체와 같은 노드 할당 변경을 허용하지 않으므로 실패한 작업을 재개할 수 없습니다. 명시적으로 금지되지 않는 한 HyperPod 자동 재개 기능은 GRES 지원 노드와 연결된 결함이 있는 모든 작업을 자동으로 다시 대기열에 추가합니다. 이 프로세스에는 작업을 중지하고 작업 대기열에 다시 배치한 다음 처음부터 작업을 다시 시작하는 작업이 포함됩니다.
**Slurm에서 SageMaker HyperPod 자동 재개 기능 사용**
SageMaker HyperPod 자동 재개를 Slurm과 함께 사용하는 경우 `salloc` 또는 `sbatch`를 사용하여 획득한 독점 할당 내에서 작업을 실행해야 합니다. 어떤 경우든 작업을 재개할 때 모든 설정 단계가 단일 `srun` 명령으로 실행되도록 하려면 진입점 스크립트를 수정해야 합니다. 진입점 스크립트를 통해 작업 단계가 중지되기 전에 실행 중이었던 환경과 일치하도록 교체된 노드의 환경을 설정하는 것이 중요합니다. 다음 절차에서는 환경을 일관되게 유지하고 단일 `srun` 명령으로 실행하도록 진입점 스크립트를 준비하는 방법을 보여줍니다.
**작은 정보**
`sbatch`를 사용하는 경우 환경을 설정하고 단일 `srun` 명령을 사용하여 별도의 스크립트를 생성하여 배치 스크립트를 간단하게 유지할 수 있습니다.
1. 다음 코드 예제를 사용하여 스크립트를 생성하고 `train_auto_resume.sh`로 저장합니다. 이 스크립트는 이전에 교체된 노드에 대해 수행된 수동 구성이 없다고 가정하여 훈련 환경 설정을 배포합니다. 이렇게 하면 환경이 노드에 구애받지 않으므로 노드를 교체할 때 작업을 재개하기 전에 노드에서 동일한 환경이 프로비저닝됩니다.
**참고**
다음 코드 예제는 작업과 연결된 Slurm 노드 목록을 검색하는 방법을 보여줍니다. SageMaker HyperPod가 작업을 자동 재개한 후 값이 오래되었을 수 있으므로 Slurm에서 제공하는 `$SLURM_JOB_NODELIST` 환경 변수를 사용하지 마세요. 다음 코드 예제에서는 `SLURM_JOB_NODELIST`를 대체할 새 `NODE_LIST` 변수를 정의한 다음 `NODE_LIST` 변수에서 `MASTER_NODE` 및 `MASTER_ADDR` 변수를 설정하는 방법을 보여줍니다.
```
#!/bin/bash
# Filename: train_auto_resume.sh
# Sample containerized script to launch a training job with a single srun which can be auto-resumed.
# Place your training environment setup here.
# Example: Install conda, docker, activate virtual env, etc.
# Get the list of nodes for a given job
NODE_LIST=$(scontrol show jobid=$SLURM_JOBID | \ # Show details of the SLURM job
awk -F= '/NodeList=/{print $2}' | \ # Extract NodeList field
grep -v Exc) # Exclude nodes marked as excluded
# Determine the master node from the node list
MASTER_NODE=$(scontrol show hostname $NODE_LIST | \ # Convert node list to hostnames
head -n 1) # Select the first hostname as master node
# Get the master node address
MASTER_ADDR=$(scontrol show node=$MASTER_NODE | \ # Show node information
awk -F= '/NodeAddr=/{print $2}' | \ # Extract NodeAddr
awk '{print $1}') # Print the first part of NodeAddr
# Torchrun command to launch the training job
torchrun_cmd="torchrun --nnodes=$SLURM_NNODES \
--nproc_per_node=1 \
--node_rank=$SLURM_NODE \
--master-addr=$MASTER_ADDR \
--master_port=1234 \
"
# Execute the torchrun command in the 'pytorch' Conda environment,
# streaming output live
/opt/conda/bin/conda run --live-stream -n pytorch $torchrun_cmd
```
**작은 정보**
위의 스크립트를 사용하여 작업에 대한 추가 종속성을 설치하기 위한 명령을 더 추가할 수 있습니다. 그러나 클러스터 생성 중에 사용되는 수명 [주기 스크립트 세트에 종속성 설치 스크립트](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)를 보관하는 것이 좋습니다. 공유 디렉터리에서 호스팅되는 가상 환경을 사용하는 경우 이 스크립트를 사용하여 가상 환경을 활성화할 수도 있습니다.
1. 하드웨어 실패 시 `srun` 명령을 자동으로 재시도해야 함을 나타내는 `--auto-resume=1` 플래그를 추가하여 SageMaker HyperPod 자동 재개가 활성화된 작업을 시작합니다.
**참고**
`sbatch` 또는 `salloc`를 사용하여 리소스 할당을 설정한 경우 할당 내에서 여러 `srun` 명령을 실행할 수 있습니다. 장애가 발생할 경우 SageMaker HyperPod 자동 재개 기능은 플래그 `--auto-resume=1`가 있는 `srun` 명령의 현재 [작업 단계](https://slurm.schedmd.com/job_launch.html#step_allocation)에서만 작동합니다. 즉, `srun` 명령에서 자동 재개를 활성화하는 것은 리소스 할당 세션 내에서 시작된 다른 `srun` 명령에는 적용되지 않습니다.
다음은 `auto-resume`이 사용 설정된 `srun` 명령의 예입니다.
**sbatch 사용**
환경을 설정하기 위한 대부분의 로직은 이미 `train_auto_resume.sh`에 있으므로 배치 스크립트는 간단하고 다음 코드 예제와 유사해야 합니다. 다음 배치 스크립트가 `batch.sh`로 저장된다고 가정합니다.
```
#!/bin/bash
#SBATCH --nodes 2
#SBATCH --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
다음 명령을 사용하여 앞의 배치 스크립트를 실행하세요.
```
sbatch batch.sh
```
**salloc 사용**
먼저 독점 할당을 획득하고 `--auto-resume` 플래그와 진입점 스크립트로 `srun` 명령을 실행합니다.
```
salloc -N 2 --exclusive
srun --auto-resume=1 train_auto_resume.sh
```
## 자동 노드 복구와 자동 재개가 함께 작동하는 방식
자동 노드 복구 시스템과 자동 재개 시스템이 모두 활성화되면 장애 처리에 대한 조정된 접근 방식을 따릅니다. HMA가 하드웨어 장애를 감지하면 작업 수준 상태에 관계없이 노드가 드레이닝 대상으로 표시됩니다. 노드 자동 복구를 활성화하면 노드에서 실행 중인 모든 작업이 종료되면 노드가 자동으로 교체됩니다. 이 시나리오에서 자동 재개가 활성화된 작업의 경우 단계에서 종료 상태가 0이 아닌 경우 자동 재개가 시작됩니다(노드가 교체되면 작업이 재개됨). 자동 재개가 활성화되지 않은 작업은 간단히 종료되므로 관리자 또는 사용자가 수동으로 다시 제출해야 합니다.
**참고**
자동 재개를 사용하는 경우 하드웨어 장애가 감지되면 노드가 항상 교체됩니다(재부팅되지 않음).
# Slurm을 사용하여 수동으로 노드 교체 또는 재부팅
이 단원에서는 노드를 수동으로 재부팅하거나 교체해야 하는 경우와 둘 다 수행하는 방법에 대해 설명합니다.
## 노드를 수동으로 재부팅하거나 교체해야 하는 경우
HyperPod 자동 재개 기능은 Slurm 노드의 상태가 `fail` 또는 `down`으로 바뀌는지 모니터링합니다. `sinfo`를 실행하여 Slurm 노드의 상태를 확인할 수 있습니다.
노드가 멈춰 있거나 응답하지 않고 자동 재개 프로세스가 노드를 복구하지 않는 경우 복구를 수동으로 시작할 수 있습니다. 노드 재부팅과 교체의 선택은 문제의 특성에 따라 달라집니다. 시스템 중단, 메모리 누수, GPU 드라이버 문제, 커널 업데이트 또는 중단 프로세스와 같은 임시 또는 소프트웨어 관련 문제가 발생할 때 재부팅하는 것이 좋습니다. 그러나 GPUs 장애, 메모리 또는 네트워킹 장애, 반복 상태 확인 실패 또는 여러 번의 재부팅 시도 후에도 응답하지 않는 노드와 같은 영구적이거나 하드웨어 관련 문제가 발생하는 경우 노드 교체가 더 적절한 솔루션입니다.
## 노드를 수동으로 재부팅하거나 교체하는 방법
SageMaker HyperPod는 수동 노드 복구를 위한 두 가지 방법을 제공합니다. 선호하는 접근 방식은 모든 오케스트레이터에서 작동하는 더 빠르고 투명한 복구 프로세스를 제공하는 SageMaker HyperPod 재부팅 및 교체 APIs를 사용하는 것입니다. 또는와 같은 기존 Slurm 명령을 사용할 수 `scontrol update`있지만이 레거시 방법을 사용하려면 Slurm의 컨트롤러 노드에 직접 액세스해야 합니다. 두 방법 모두 동일한 SageMaker HyperPod 복구 프로세스를 활성화합니다.
## 재부팅 API를 사용하여 수동으로 노드 재부팅
**BatchRebootClusterNodes**를 사용하여 SageMaker HyperPod 클러스터에서 결함이 있는 노드를 수동으로 재부팅할 수 있습니다.
다음은를 사용하여 클러스터의 두 인스턴스에서 재부팅 작업을 실행하는 예제입니다 AWS Command Line Interface.
```
aws sagemaker batch-reboot-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## API 교체를 사용하여 수동으로 노드 교체
**BatchReplaceClusterNodes**를 사용하여 SageMaker HyperPod 클러스터에서 결함이 있는 노드를 수동으로 교체할 수 있습니다.
다음은를 사용하여 클러스터의 두 인스턴스에서 교체 작업을 실행하는 예제입니다 AWS Command Line Interface.
```
aws sagemaker batch-replace-cluster-nodes \
--cluster-name arn:aws:sagemaker:ap-northeast-1:123456789:cluster/test-cluster \
--node-ids i-0123456789abcdef0 i-0fedcba9876543210
```
## Slurm을 사용하여 수동으로 노드 재부팅
scontrol Slurm 명령을 사용하여 노드 복구를 트리거할 수도 있습니다. 이러한 명령은 Slurm 컨트롤 플레인과 직접 상호 작용하고 동일한 기본 SageMaker HyperPod 복구 메커니즘을 호출합니다.
다음 명령에서 를 재부팅하려는 결함이 있는 인스턴스의 Slurm 노드 이름(호스트 이름)으로 바꿉니다.
```
scontrol update node= state=fail reason="Action:Reboot"
```
이렇게 하면 노드가 지정된 이유와 함께 실패로 표시됩니다. SageMaker HyperPod는 이를 감지하고 인스턴스를 재부팅합니다. 작업 중에 노드 상태를 변경하거나 Slurm 컨트롤러를 다시 시작하지 마세요.
## Slurm을 사용하여 수동으로 노드 교체
다음과 같이 scontrol update 명령을 사용하여 노드를 교체할 수 있습니다.
다음 명령에서를 교체하려는 결함이 `` 있는 인스턴스의 Slurm 노드 이름(호스트 이름)으로 바꿉니다.
```
scontrol update node= state=fail reason="Action:Replace"
```
이 명령을 실행하면 노드가 `fail` 상태로 전환되고, 현재 실행 중인 작업이 완료될 때까지 대기하며, 정상 인스턴스로 대체되고, 동일한 호스트 이름으로 복구됩니다. 이 프로세스는 가용 영역에서 사용 가능한 인스턴스와 수명 주기 스크립트를 실행하는 데 걸리는 시간에 따라 시간이 걸립니다. 업데이트 및 교체 프로세스 중에는 노드의 상태를 수동으로 다시 변경하거나 Slurm 컨트롤러를 다시 시작하지 마세요. 이렇게 하면 교체가 실패할 수 있습니다. 노드가 오랜 시간 후에도 복구되지 않거나 `idle` 상태로 전환되지 않으면 [AWS 지원 부서에](https://console.aws.amazon.com/support/) 문의하세요.
## 노드를 수동으로 강제 변경
결함이 있는 노드가 `fail` 상태에서 계속 중단되면 시도할 수 있는 마지막 수단은 노드 상태를 `down`으로 강제 변경하는 것입니다. 여기에는 관리자 권한(sudo 권한)이 필요합니다.
**주의**
다음 명령을 실행하기 전에 주의 깊게 진행하세요. 강제로 모든 작업이 종료되고 저장되지 않은 모든 작업이 손실될 수 있습니다.
```
scontrol update node= state=down reason="Action:Replace"
```