기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Slurm을 사용하여 SageMaker HyperPod 클러스터 오케스트레이션
SageMaker HyperPod의 Slurm 지원은 기계 학습(ML) 워크로드를 실행하고 대규모 언어 모델(LLM), 확산 모델 및 파운데이션 모델(FM)과 같은 최첨단 모델을 개발하기 위한 탄력적 클러스터를 프로비저닝하는 데 도움이 됩니다. AWS Trainium 및 NVIDIA A100 및 H100 그래픽 처리 장치(GPU)와 같은 수천 개의 액셀러레이터로 구동되는 대규모 컴퓨팅 클러스터를 구축하고 유지 관리하는 데 수반되는 차별화되지 않은 헤비 리프트를 제거하여 FMs 개발을 가속화합니다. H100 GPUs 액셀러레이터가 실패하면 SageMaker HyperPod의 복원력 기능은 클러스터 인스턴스가 결함 있는 하드웨어를 즉시 자동으로 감지하고 교체하므로 ML 워크로드 실행에 집중할 수 있습니다. 또한 SageMaker HyperPod 에서 수명 주기 구성 지원을 통해 필요에 맞게 컴퓨팅 환경을 사용자 지정하고 Amazon SageMaker AI 분산 훈련 라이브러리로 구성하여 AWS에서 최적의 성능을 달성할 수 있습니다.
**클러스터 작동**
콘솔 사용자 인터페이스(UI)를 통해 그래픽으로, AWS 명령줄 인터페이스(CLI) 또는를 통해 프로그래밍 방식으로 SageMaker HyperPod 클러스터를 생성, 구성 및 유지 관리할 수 있습니다 AWS SDK for Python (Boto3). Amazon VPC를 사용하면 클러스터 네트워크를 보호하고 가장 빠른 처리량을 제공하는 Amazon FSx for Lustre와 같은 VPC의 리소스로 클러스터를 구성할 수도 있습니다. 인스턴스 그룹을 클러스터링하고 클러스터 리소스 및 사용자가 작동할 수 있는 작업을 제한하는 데 다양한 IAM 역할을 부여할 수도 있습니다. 자세한 내용은 [SageMaker HyperPod Slurm 클러스터 작업](sagemaker-hyperpod-operate-slurm.md)를 참조하세요.
**ML 환경 구성**
SageMaker HyperPod는 HyperPod 클러스터에 ML 환경을 설정하는 [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami)를 실행합니다. 사용 사례를 지원하는 수명 주기 스크립트를 제공하여 DLAMI에 대한 추가 사용자 지정을 구성할 수 있습니다. 수명 주기 스크립트를 설정하는 방법에 대한 자세한 내용은 [SageMaker HyperPod 시작하기](smcluster-getting-started-slurm.md) 및 [수명 주기 스크립트를 사용하여 SageMaker HyperPod 클러스터 사용자 지정](sagemaker-hyperpod-lifecycle-best-practices-slurm.md) 섹션을 참조하세요.
**작업 예약**
HyperPod 클러스터를 성공적으로 생성한 후 클러스터 사용자는 클러스터 노드(예: 헤드 또는 컨트롤러 노드, 로그인 노드, 작업자 노드)에 로그인하고 기계 학습 워크로드 실행을 위한 작업을 예약할 수 있습니다. 자세한 내용은 [SageMaker HyperPod 클러스터의 작업](sagemaker-hyperpod-run-jobs-slurm.md)를 참조하세요.
**하드웨어 장애에 대한 복원력**
SageMaker HyperPod는 클러스터 노드에서 상태 확인을 실행하고 워크로드 자동 재개 기능을 제공합니다. HyperPod의 클러스터 복원력 기능을 사용하면 결함이 있는 노드를 16개 이상의 노드가 있는 클러스터의 정상 노드로 교체한 후 마지막으로 저장한 체크포인트에서 워크로드를 재개할 수 있습니다. 자세한 내용은 [SageMaker HyperPod 클러스터 복원력](sagemaker-hyperpod-resiliency-slurm.md)를 참조하세요.
**클러스터 생성 및 관리**
SageMaker HyperPod 리소스 사용률 지표 및 수명 주기 로그는 Amazon CloudWatch 에서 찾을 수 있으며, SageMaker HyperPod 리소스에 태그를 지정하여 관리할 수 있습니다. 각 `CreateCluster` API 실행은 `-` 형식으로 명명된 고유한 로그 스트림을 생성합니다. 로그 스트림에서 호스트 이름, 실패한 수명 주기 스크립트의 이름, `stdout` 및 `stderr`와 같은 실패한 스크립트의 출력을 확인할 수 있습니다. 자세한 내용은 [SageMaker HyperPod 클러스터 관리](sagemaker-hyperpod-cluster-management-slurm.md) 단원을 참조하십시오.
**SageMaker AI 도구와 호환**
SageMaker HyperPod를 사용하면 SageMaker AI 분산 데이터 병렬 처리(SMDDP) 라이브러리와 같이 SageMaker AI에서 제공하는 AWS 최적화된 집합 통신 라이브러리로 클러스터를 구성할 수 있습니다. [SageMaker ](data-parallel.md) SMDDP 라이브러리는 NVIDIA A100 GPU로 구동되는 가장 성능이 뛰어난 SageMaker AI 기계 학습 인스턴스를 위한 AWS 컴퓨팅 및 네트워크 인프라에 최적화된 `AllGather` 작업을 구현합니다. GPUs 자세한 내용은 [HyperPod에서 Slurm을 사용하여 분산 훈련 워크로드 실행](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)를 참조하세요.
**UltraServers를 사용한 인스턴스 배치**
SageMaker AI는 다른 UltraServer를 사용하기 전에 한 UltraServer에서 모든 인스턴스를 사용하도록 최선의 노력을 하는 전략에 따라 UltraServer 내의 인스턴스에 작업을 자동으로 할당합니다. 예를 들어 인스턴스 14개를 요청하고 훈련 계획에 UltraServer가 2개 있는 경우 SageMaker AI는 첫 번째 UltraServer에서 모든 인스턴스를 사용합니다. 인스턴스 20개를 요청했고 훈련 계획에 UltraServer가 2개 있는 경우 SageMaker AI는 첫 번째 UltraServer에서 인스턴스 17개를 모두 사용한 다음, 두 번째 UltraServer에서 인스턴스 3개를 사용합니다.
**Topics**
+ [
# SageMaker HyperPod 시작하기
](smcluster-getting-started-slurm.md)
+ [
# SageMaker HyperPod Slurm 클러스터 작업
](sagemaker-hyperpod-operate-slurm.md)
+ [
# 수명 주기 스크립트를 사용하여 SageMaker HyperPod 클러스터 사용자 지정
](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [
# SageMaker HyperPod 다중 헤드 노드 지원
](sagemaker-hyperpod-multihead-slurm.md)
+ [
# SageMaker HyperPod 클러스터의 작업
](sagemaker-hyperpod-run-jobs-slurm.md)
+ [
# SageMaker HyperPod 클러스터 리소스 모니터링
](sagemaker-hyperpod-cluster-observability-slurm.md)
+ [
# SageMaker HyperPod 클러스터 복원력
](sagemaker-hyperpod-resiliency-slurm.md)
+ [
# Slurm을 사용한 향상된 클러스터 작업을 위한 지속적 프로비저닝
](sagemaker-hyperpod-scaling-slurm.md)
+ [
# SageMaker HyperPod 클러스터 관리
](sagemaker-hyperpod-cluster-management-slurm.md)
+ [
# SageMaker HyperPod FAQ
](sagemaker-hyperpod-faq-slurm.md)
# SageMaker HyperPod 시작하기
첫 번째 SageMaker HyperPod 클러스터 생성을 시작하고 SageMaker HyperPod의 클러스터 작업 기능을 알아봅니다. SageMaker AI 콘솔 UI 또는 AWS CLI 명령을 통해 SageMaker HyperPod 클러스터를 생성할 수 있습니다. 이 자습서에서는 인기 있는 워크로드 스케줄러 소프트웨어인 Slurm을 사용하여 새 SageMaker HyperPod 클러스터를 생성하는 방법을 보여줍니다. 이 자습서를 진행한 후에는 AWS Systems Manager 명령()을 사용하여 클러스터 노드에 로그인하는 방법을 알게 됩니다`aws ssm`. 이 자습서를 완료한 후 [SageMaker HyperPod Slurm 클러스터 작업](sagemaker-hyperpod-operate-slurm.md)도 확인하여 SageMaker HyperPod 기본 작업에 대해 자세히 알아보고 프로비저닝된 클러스터에서 작업을 예약하는 방법을 알아보려면 [SageMaker HyperPod 클러스터의 작업](sagemaker-hyperpod-run-jobs-slurm.md)을 참조하세요.
**작은 정보**
실제 예제 및 솔루션을 찾으려면 [SageMaker HyperPod 워크숍](https://catalog.workshops.aws/sagemaker-hyperpod)도 참조하세요.
**Topics**
+ [
# SageMaker AI 콘솔을 사용하여 SageMaker HyperPod 시작하기
](smcluster-getting-started-slurm-console.md)
+ [
# CloudFormation 템플릿을 사용하여 SageMaker HyperPod 클러스터 생성
](smcluster-getting-started-slurm-console-create-cluster-cfn.md)
+ [
# 를 사용하여 SageMaker HyperPod 시작하기 AWS CLI
](smcluster-getting-started-slurm-cli.md)
# SageMaker AI 콘솔을 사용하여 SageMaker HyperPod 시작하기
다음 자습서에서는 새 SageMaker HyperPod 클러스터를 생성하고 SageMaker AI 콘솔 UI를 통해 Slurm으로 설정하는 방법을 보여줍니다. 자습서를 따라 세 개의 Slurm 노드인 `my-controller-group`, `my-login-group` 및 `worker-group-1`이 있는 HyperPod 클러스터를 생성합니다.
**Topics**
+ [
## 클러스터 생성
](#smcluster-getting-started-slurm-console-create-cluster-page)
+ [
## 리소스 배포
](#smcluster-getting-started-slurm-console-create-cluster-deploy)
+ [
## 클러스터를 삭제하고 리소스를 정리합니다.
](#smcluster-getting-started-slurm-console-delete-cluster-and-clean)
## 클러스터 생성
**SageMaker HyperPod 클러스터** 페이지로 이동하여 **Slurm** 오케스트레이션을 선택하려면 다음 단계를 따르세요.
1. [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/)에서 Amazon SageMaker AI 콘솔을 엽니다.
1. 왼쪽 탐색 창에서 **HyperPod 클러스터**를 선택하고 **클러스터 관리**를 선택합니다.
1. **SageMaker HyperPod 클러스터** 페이지에서 **HyperPod 클러스터 생성**을 선택합니다.
1. **HyperPod 클러스터 생성** 드롭다운에서 **Slurm에 의해 오케스트레이션됨**을 선택합니다.
1. Slurm 클러스터 생성 페이지에는 두 가지 옵션이 있습니다. 필요에 맞는 옵션을 선택하세요.
1. **빠른 설정** - 기본 설정으로 즉시 시작하려면 **빠른 설정**을 선택합니다. 이 옵션을 사용하면 SageMaker AI는 클러스터를 생성하는 과정에서 VPC, 서브넷, 보안 그룹, Amazon S3 버킷, IAM 역할 및 FSx for Lustre와 같은 새 리소스를 생성합니다.
1. **사용자 지정 설정** - 기존 AWS 리소스와 통합하거나 특정 네트워킹, 보안 또는 스토리지 요구 사항이 있는 경우 **사용자 지정 설정**을 선택합니다. 이 옵션을 사용하면 기존 리소스를 사용하거나 새 리소스를 생성할 수 있으며 필요에 가장 적합한 구성을 사용자 지정할 수 있습니다.
## 빠른 설정
**빠른 설정** 섹션에서 다음 단계에 따라 Slurm 오케스트레이션을 사용하여 HyperPod 클러스터를 생성합니다.
### 일반 설정
새 클러스터의 이름을 지정합니다. 클러스터를 생성한 후에는 이름을 변경할 수 없습니다.
### 인스턴스 그룹
인스턴스 그룹을 추가하려면 **그룹 추가**를 선택합니다. 각 인스턴스 그룹을 다르게 구성할 수 있으며 다양한 인스턴스 유형을 가진 여러 인스턴스 그룹으로 구성된 이종 클러스터를 생성할 수 있습니다. 클러스터를 배포하려면 컨트롤러 및 컴퓨팅 그룹 유형에 인스턴스 그룹을 하나 이상 추가해야 합니다.
**중요**
한 번에 하나의 인스턴스 그룹을 추가할 수 있습니다. 여러 인스턴스 그룹을 생성하려면 각 인스턴스 그룹에 대해 프로세스를 반복합니다.
이 단계를 따라 인스턴스 그룹을 추가합니다.
1. **인스턴스 그룹 유형**에서 인스턴스 그룹의 유형을 선택합니다. 이 자습서에서는 `my-controller-group`에 **컨트롤러(헤드)**를, `my-login-group`에 **로그인**을, `worker-group-1`에 **컴퓨팅(워커)**을 선택합니다.
1. **이름**에 인스턴스 그룹의 이름을 지정합니다. 이 자습서에서는 `my-controller-group`, `my-login-group` 및 `worker-group-1`라는 인스턴스 그룹을 세 개 생성합니다.
1. **인스턴스 용량**에서 온디맨드 용량 또는 훈련 계획을 선택하여 컴퓨팅 리소스를 예약합니다.
1. **인스턴스 유형**에서 인스턴스 그룹의 인스턴스를 선택합니다. 이 자습서에서는 `my-controller-group`에 대해 `ml.c5.xlarge`, `my-login-group`에 대해 `ml.m5.4xlarge`, `worker-group-1`에 `ml.trn1.32xlarge`를 선택합니다.
**중요**
할당량이 충분하고 계정에 대해 할당되지 않은 IP 주소가 충분한 인스턴스 유형을 선택해야 합니다. 할당량을 보거나 추가로 요청하려면 [SageMaker HyperPod 할당량](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas) 섹션을 참조하세요.
1. **인스턴스 수량 **에서 클러스터 사용에 대한 인스턴스 할당량을 초과하지 않는 정수를 지정합니다. 이 자습서에서는 세 그룹 모두에 대해 **1**을 입력합니다.
1. **대상 가용 영역**에서 인스턴스를 프로비저닝할 가용 영역을 선택합니다. 가용 영역은 가속화된 컴퓨팅 용량의 위치와 일치해야 합니다.
1. **인스턴스당 추가 스토리지 볼륨(GB) - 선택 사항**에서 1\$116,384 사이의 정수를 지정하여 추가 Elastic Block Store(EBS) 볼륨의 크기를 기가바이트(GB) 단위로 설정합니다. EBS 볼륨은 인스턴스 그룹의 각 인스턴스에 연결됩니다. 추가 EBS 볼륨의 기본 탑재 경로는 `/opt/sagemaker`입니다. 클러스터가 성공적으로 생성된 후 클러스터 인스턴스(노드)에 SSH를 넣고 `df -h` 명령을 실행하여 EBS 볼륨이 올바르게 마운트되었는지 확인할 수 있습니다. 추가 EBS 볼륨을 연결하면 *Amazon Elastic Block Store 사용 설명서*의 [Amazon EBS 볼륨](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) 섹션에 설명된 대로 안정적이고 인스턴스가 아니며 독립적으로 지속되는 스토리지가 제공됩니다.
1. **인스턴스 그룹 추가**를 선택합니다.
### 빠른 설정 기본값
이 섹션에는 클러스터 생성 프로세스 중에 생성되는 모든 새 AWS 리소스를 포함하여 클러스터 생성에 대한 모든 기본 설정이 나열됩니다. 기본 설정을 검토합니다.
## 사용자 지정 설정
**사용자 지정 설정** 섹션에서 다음 단계에 따라 Slurm 오케스트레이션을 사용하여 HyperPod 클러스터를 생성합니다.
### 일반 설정
새 클러스터의 이름을 지정합니다. 클러스터를 생성한 후에는 이름을 변경할 수 없습니다.
**인스턴스 복구**에서 **자동 - *권장*** 또는 **없음**을 선택합니다.
### 네트워킹
클러스터 생성을 위한 네트워크 설정을 구성합니다. 클러스터를 생성한 후에는 이 설정을 변경할 수 없습니다.
1. **VPC**의 경우, SageMaker AI에 VPC에 대한 액세스 권한을 부여하는 VPC가 이미 있는 경우 자체 VPC를 선택합니다. 새 VPC를 생성하려는 경우 *Amazon Virtual Private Cloud 사용 설명서*의 [VPC 생성](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)의 지침을 따르세요. 기본 SageMaker AI VPC를 사용하기 위해 **없음** 상태로 둘 수 있습니다.
1. **VPC IPv4 CIDR 블록**에 VPC의 시작 IP를 입력합니다.
1. **가용 영역**에서 HyperPod가 클러스터의 서브넷을 생성할 가용 영역(AZ)을 선택합니다. 가속화된 컴퓨팅 용량의 위치와 일치하는 AZ를 선택합니다.
1. **보안 그룹**의 경우, 보안 그룹을 생성하거나 VPC 내에서 리소스 간 통신을 허용하는 규칙이 구성된 보안 그룹을 최대 5개 선택합니다.
### 인스턴스 그룹
인스턴스 그룹을 추가하려면 **그룹 추가**를 선택합니다. 각 인스턴스 그룹을 다르게 구성할 수 있으며 다양한 인스턴스 유형을 가진 여러 인스턴스 그룹으로 구성된 이종 클러스터를 생성할 수 있습니다. 클러스터를 배포하려면 인스턴스 그룹을 하나 이상 추가해야 합니다.
**중요**
한 번에 하나의 인스턴스 그룹을 추가할 수 있습니다. 여러 인스턴스 그룹을 생성하려면 각 인스턴스 그룹에 대해 프로세스를 반복합니다.
이 단계를 따라 인스턴스 그룹을 추가합니다.
1. **인스턴스 그룹 유형**에서 인스턴스 그룹의 유형을 선택합니다. 이 자습서에서는 `my-controller-group`에 **컨트롤러(헤드)**를, `my-login-group`에 **로그인**을, `worker-group-1`에 **컴퓨팅(워커)**을 선택합니다.
1. **이름**에 인스턴스 그룹의 이름을 지정합니다. 이 자습서에서는 `my-controller-group`, `my-login-group` 및 `worker-group-1`라는 인스턴스 그룹을 세 개 생성합니다.
1. **인스턴스 용량**에서 온디맨드 용량 또는 훈련 계획을 선택하여 컴퓨팅 리소스를 예약합니다.
1. **인스턴스 유형**에서 인스턴스 그룹의 인스턴스를 선택합니다. 이 자습서에서는 `my-controller-group`에 대해 `ml.c5.xlarge`, `my-login-group`에 대해 `ml.m5.4xlarge`, `worker-group-1`에 `ml.trn1.32xlarge`를 선택합니다.
**중요**
할당량이 충분하고 계정에 대해 할당되지 않은 IP 주소가 충분한 인스턴스 유형을 선택해야 합니다. 할당량을 보거나 추가로 요청하려면 [SageMaker HyperPod 할당량](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas) 섹션을 참조하세요.
1. **인스턴스 수량 **에서 클러스터 사용에 대한 인스턴스 할당량을 초과하지 않는 정수를 지정합니다. 이 자습서에서는 세 그룹 모두에 대해 **1**을 입력합니다.
1. **대상 가용 영역**에서 인스턴스를 프로비저닝할 가용 영역을 선택합니다. 가용 영역은 가속화된 컴퓨팅 용량의 위치와 일치해야 합니다.
1. **인스턴스당 추가 스토리지 볼륨(GB) - 선택 사항**에서 1\$116,384 사이의 정수를 지정하여 추가 Elastic Block Store(EBS) 볼륨의 크기를 기가바이트(GB) 단위로 설정합니다. EBS 볼륨은 인스턴스 그룹의 각 인스턴스에 연결됩니다. 추가 EBS 볼륨의 기본 탑재 경로는 `/opt/sagemaker`입니다. 클러스터가 성공적으로 생성된 후 클러스터 인스턴스(노드)에 SSH를 넣고 `df -h` 명령을 실행하여 EBS 볼륨이 올바르게 마운트되었는지 확인할 수 있습니다. 추가 EBS 볼륨을 연결하면 *Amazon Elastic Block Store 사용 설명서*의 [Amazon EBS 볼륨](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) 섹션에 설명된 대로 안정적이고 인스턴스가 아니며 독립적으로 지속되는 스토리지가 제공됩니다.
1. **인스턴스 그룹 추가**를 선택합니다.
### 수명 주기 스크립트
Amazon S3 버킷에 저장될 기본 수명 주기 스크립트 또는 사용자 지정 수명 주기 스크립트를 사용하도록 선택할 수 있습니다. [Awesome Distributed Training GitHub 리포지토리](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/7.sagemaker-hyperpod-eks/LifecycleScripts)에서 기본 수명 주기 스크립트를 볼 수 있습니다. 수명 주기 스크립트에 대한 자세한 내용은 [수명 주기 스크립트를 사용하여 SageMaker HyperPod 클러스터 사용자 지정](sagemaker-hyperpod-lifecycle-best-practices-slurm.md) 섹션을 참조하세요.
1. **수명 주기 스크립트**에서 기본 또는 사용자 지정 수명 주기 스크립트를 사용하도록 선택합니다.
1. **수명 주기 스크립트용 S3 버킷**의 경우 새 버킷을 생성하거나 기존 버킷을 사용하여 수명 주기 스크립트를 저장하도록 선택합니다.
### 권한
HyperPod가 사용자를 대신하여 필요한 AWS 리소스를 실행하고 액세스할 수 있도록 허용하는 IAM 역할을 선택하거나 생성합니다.
### 스토리지
HyperPod 클러스터에 프로비저닝되도록 FSx for Lustre 파일 시스템을 구성합니다.
1. **파일 시스템**에서 기존 FSx for Lustre 파일 시스템을 선택하여 새 FSx for Lustre 파일 시스템을 생성하거나, FSx for Lustre 파일 시스템을 프로비저닝하지 않습니다.
1. **스토리지 단위당 처리량**에서 프로비저닝된 스토리지의 TiB당 사용할 수 있는 처리량을 선택합니다.
1. **스토리지 용량**에 용량 값을 TB 단위로 입력합니다.
1. **데이터 압축 유형**에서 **LZ4**를 선택하여 데이터 압축을 활성화합니다.
1. **Lustre 버전**의 경우 새 파일 시스템에 권장되는 값을 확인합니다.
### 태그 - 선택 사항
**태그 - *선택 사항*의** 경우 키 및 값 페어를 새 클러스터에 추가하고 클러스터를 AWS 리소스로 관리합니다. 자세한 내용은 [AWS 리소스 태그 지정](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) 섹션을 참조하세요.
## 리소스 배포
**빠른 설정** 또는 **사용자 지정 설정**을 사용하여 클러스터 구성을 완료한 후 다음 옵션을 선택하여 리소스 프로비저닝 및 클러스터 생성을 시작합니다.
+ **제출** - SageMaker AI가 기본 구성 리소스를 프로비저닝하고 클러스터를 생성하기 시작합니다.
+ **CloudFormation 템플릿 파라미터 다운로드** - 구성 파라미터 JSON 파일을 다운로드하고 AWS CLI 명령을 실행하여 CloudFormation 스택을 배포하여 구성 리소스를 프로비저닝하고 클러스터를 생성합니다. 필요한 경우 다운로드한 파라미터 JSON 파일을 편집할 수 있습니다. 이 옵션을 선택하는 경우 [CloudFormation 템플릿을 사용하여 SageMaker HyperPod 클러스터 생성](smcluster-getting-started-slurm-console-create-cluster-cfn.md)의 추가 지침을 참조하세요.
## 클러스터를 삭제하고 리소스를 정리합니다.
SageMaker HyperPod 클러스터 생성을 성공적으로 테스트한 후 클러스터를 삭제할 때까지 `InService` 상태에서 계속 실행됩니다. 온디맨드 요금을 기준으로 지속적인 서비스 요금이 발생하지 않도록 온디맨드 SageMaker AI 인스턴스를 사용하여 생성된 클러스터를 사용하지 않을 때는 삭제하는 것이 좋습니다. 이 자습서에서는 두 인스턴스 그룹으로 구성된 클러스터를 생성했습니다. 이 중 하나는 C5 인스턴스를 사용하므로 [SageMaker HyperPod 클러스터 삭제](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-delete-cluster)의 지침에 따라 클러스터를 삭제해야 합니다.
그러나 예약된 컴퓨팅 용량이 있는 클러스터를 생성한 경우 클러스터의 상태는 서비스 청구에 영향을 주지 않습니다.
이 자습서에 사용된 S3 버킷에서 수명 주기 스크립트를 정리하려면 클러스터 생성 중에 사용한 S3 버킷으로 이동하여 파일을 완전히 제거합니다.
클러스터에서 워크로드 실행을 테스트한 경우 데이터를 업로드했거나 Amazon FSx for Lustre 및 Amazon Elastic File System과 같은 다른 S3 버킷 또는 파일 시스템 서비스에 아티팩트를 저장했는지 확인합니다. 발생하는 요금을 방지하려면 스토리지 또는 파일 시스템에서 모든 아티팩트와 데이터를 삭제합니다.
# CloudFormation 템플릿을 사용하여 SageMaker HyperPod 클러스터 생성
HyperPod용 CloudFormation 템플릿을 사용하여 SageMaker HyperPod 클러스터를 생성할 수 있습니다. 계속하려면 AWS CLI 를 설치해야 합니다.
**Topics**
+ [
## 콘솔에서 리소스를 구성하고 CloudFormation을 사용하여 배포
](#smcluster-getting-started-slurm-console-create-cluster-deploy-console)
+ [
## 리소스를 구성하고 CloudFormation을 사용하여 배포
](#smcluster-getting-started-slurm-console-create-cluster-deploy-cfn)
## 콘솔에서 리소스를 구성하고 CloudFormation을 사용하여 배포
를 사용하여 리소스를 구성 AWS Management Console 하고 CloudFormation 템플릿을 사용하여 배포할 수 있습니다.
단계는 다음과 같습니다.
1. ***제출**을 선택하는 대신* [SageMaker AI 콘솔을 사용하여 SageMaker HyperPod 시작하기](smcluster-getting-started-slurm-console.md)의 자습서 끝에 있는 **CloudFormation 템플릿 파라미터 다운로드**를 선택합니다. 자습서에는 클러스터를 성공적으로 생성하는 데 필요한 중요한 구성 정보가 포함되어 있습니다.
**중요**
**제출**을 선택하면 클러스터를 삭제할 때까지 동일한 이름의 클러스터를 배포할 수 없습니다.
**CloudFormation 템플릿 파라미터 다운로드**를 선택하면 ** AWS CLI를 사용하여 구성 파일을 사용하여 클러스터 생성** 창이 페이지 오른쪽에 나타납니다.
1. ** AWS CLI를 사용하여 구성 파일을 사용하여 클러스터 생성** 창에서 **구성 파라미터 파일 다운로드**를 선택합니다. 파일이 머신에 다운로드됩니다. 필요에 따라 구성 JSON 파일을 편집하거나 변경이 필요하지 않은 경우 그대로 둘 수 있습니다.
1. 터미널에서 파라미터 파일 `file://params.json`의 위치로 이동합니다.
1. [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) AWS CLI 명령을 실행하여 구성된 리소스를 프로비저닝하고 HyperPod 클러스터를 생성할 CloudFormation 스택을 배포합니다.
```
aws cloudformation create-stack
--stack-name my-stack
--template-url https://aws-sagemaker-hyperpod-cluster-setup.amazonaws.com/templates-slurm/main-stack-slurm-based-template.yaml
--parameters file://params.json
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
1. 리소스 프로비저닝 상태를 보려면 [CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation)로 이동합니다.
클러스터 생성이 완료되면 SageMaker HyperPod 콘솔의 메인 창에 있는 **클러스터**에서 새 클러스터를 확인합니다. **상태** 열에서 표시되는 상태를 확인할 수도 있습니다.
1. 클러스터 상태가 `InService`로 전환되면 클러스터 노드에 로그인을 시작할 수 있습니다. 클러스터 노드에 액세스하고 ML 워크로드 실행을 시작하려면 [SageMaker HyperPod 클러스터의 작업](sagemaker-hyperpod-run-jobs-slurm.md) 섹션을 참조하세요.
## 리소스를 구성하고 CloudFormation을 사용하여 배포
SageMaker HyperPod용 CloudFormation 템플릿을 사용하여 리소스를 구성하고 배포할 수 있습니다.
단계는 다음과 같습니다.
1. [sagemaker-hyperpod-cluster-setup](https://github.com/aws/sagemaker-hyperpod-cluster-setup) GitHub 리포지토리에서 SageMaker HyperPod용 CloudFormation 템플릿을 다운로드합니다.
1. [create-stack](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/create-stack.html) AWS CLI 명령을 실행하여 구성된 리소스를 프로비저닝하고 HyperPod 클러스터를 생성할 CloudFormation 스택을 배포합니다.
```
aws cloudformation create-stack
--stack-name my-stack
--template-url URL_of_the_file_that_contains_the_template_body
--parameters file://params.json
--capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
```
1. 리소스 프로비저닝 상태를 보려면 CloudFormation 콘솔로 이동합니다.
클러스터 생성이 완료되면 SageMaker HyperPod 콘솔의 메인 창에 있는 **클러스터**에서 새 클러스터를 확인합니다. **상태** 열에서 표시되는 상태를 확인할 수도 있습니다.
1. 클러스터 상태가 `InService`로 전환되면 클러스터 노드에 로그인을 시작할 수 있습니다. 클러스터 노드에 액세스하고 ML 워크로드 실행을 시작하려면 [SageMaker HyperPod 클러스터의 작업](sagemaker-hyperpod-run-jobs-slurm.md) 섹션을 참조하세요.
# 를 사용하여 SageMaker HyperPod 시작하기 AWS CLI
HyperPod용 AWS CLI 명령을 사용하여 첫 번째 SageMaker HyperPod 클러스터를 생성합니다.
## Slurm을 사용하여 첫 번째 SageMaker HyperPod 클러스터 생성
다음 자습서에서는 [SageMaker HyperPod 에 대한AWS CLI 명령](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-cli)을 통해 새 SageMaker HyperPod 클러스터를 생성하고 Slurm으로 설정하는 방법을 보여줍니다. 자습서에서는 , `my-login-group`및 라는 세 개의 Slurm 노드가 있는 HyperPod 클러스터`my-controller-group`를 생성합니다`worker-group-1`.
API 기반 구성 접근 방식을 사용하면를 사용하여 CreateCluster API 요청에서 Slurm 노드 유형 및 파티션 할당을 직접 정의할 수 있습니다`SlurmConfig`. 따라서 별도의 `provisioning_parameters.json` 파일이 필요하지 않으며 기본 제공 검증, 드리프트 감지 및 per-instance-group FSx 구성을 제공합니다.
1. 먼저 수명 주기 스크립트를 준비하고 Amazon S3 버킷에 업로드합니다. 클러스터를 생성하는 동안 HyperPod는 각 인스턴스 그룹에서 실행됩니다. 다음 명령을 사용하여 수명 주기 스크립트를 Amazon S3에 업로드합니다.
```
aws s3 sync \
~/local-dir-to-lifecycle-scripts/* \
s3://sagemaker-//src
```
**참고**
를 사용하는 S3[SageMaker HyperPod의 IAM 역할은](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) 특정 접두사로 시작하는 Amazon S3 버킷에 대한 액세스`AmazonSageMakerClusterInstanceRolePolicy`만 허용`sagemaker-`하므로 S3 버킷 경로는 접두사 로 시작해야 합니다. Amazon S3
처음부터 시작하는 경우 [Awsome Distributed Training GitHub 리포지토리](https://github.com/aws-samples/awsome-distributed-training/) 에 제공된 샘플 수명 주기 스크립트를 사용합니다. 다음 하위 단계에서는 샘플 수명 주기 스크립트를 다운로드하여 Amazon S3 버킷에 업로드하는 방법을 보여줍니다.
1. 수명 주기 스크립트 샘플 사본을 로컬 컴퓨터의 디렉터리에 다운로드합니다.
```
git clone https://github.com/aws-samples/awsome-distributed-training/
```
1. [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config) 디렉터리로 이동하여 수명 주기 스크립트 세트를 찾을 수 있습니다.
```
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
수명 주기 스크립트 샘플에 대한 자세한 내용은 [수명 주기 스크립트를 사용하여 SageMaker HyperPod 클러스터 사용자 지정](sagemaker-hyperpod-lifecycle-best-practices-slurm.md) 섹션을 참조하세요.
1. `s3://sagemaker-//src`에 스크립트를 업로드하세요. 이렇게 하려면 Amazon EC2 콘솔에을 사용하거나 AWS CLI Amazon S3 명령을 실행합니다.
```
aws s3 sync \
~/local-dir-to-lifecycle-scripts/* \
s3://sagemaker-//src
```
**참고**
API 기반 구성을 사용하면 `provisioning_parameters.json` 파일을 생성하거나 업로드할 필요가 없습니다. Slurm 구성은 다음 단계의 CreateCluster API 요청에 직접 정의됩니다.
1. [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html) 요청 파일을 JSON 형식으로 준비하고 `create_cluster.json`으로 저장합니다.
API 기반 구성을 사용하면 `SlurmConfig` 필드를 사용하여 각 인스턴스 그룹에 대한 Slurm 노드 유형 및 파티션 할당을 지정합니다. 또한를 사용하여 클러스터 수준 Slurm 설정을 구성합니다`Orchestrator.Slurm`.
`ExecutionRole`의 경우 [SageMaker HyperPod 사용을 위한 사전 조건](sagemaker-hyperpod-prerequisites.md)에서 관리형 `AmazonSageMakerClusterInstanceRolePolicy`로 생성한 IAM 역할의 ARN을 제공합니다.
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole",
"InstanceStorageConfigs": [
{
"EbsVolumeConfig": {
"VolumeSizeInGB": 500
}
}
]
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
}
}
```
**SlurmConfig 필드:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
**Orchestrator.Slurm 필드:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
**SlurmConfigStrategy 옵션:**
+ `Managed` (권장): HyperPod는 무단 변경(드리프트 `slurm.conf` 감지)을 완전히 관리하고 감지합니다. 드리프트가 감지되면 업데이트가 실패합니다.
+ `Overwrite`: HyperPod는 업데이트 `slurm.conf` 시 덮어쓰고 수동 변경 사항은 무시합니다.
+ `Merge`: HyperPod는 수동 변경 사항을 보존하고 API 구성과 병합합니다.
**FSx for Lustre 추가(선택 사항):**
FSx for Lustre 파일 시스템을 컴퓨팅 노드에 탑재하려면 인스턴스 그룹의 `FsxLustreConfig` `InstanceStorageConfigs`에를 추가합니다. 이를 위해서는 사용자 지정 VPC 구성이 필요합니다.
```
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-0abc123def456789.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "abcdefgh"
}
}
],
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
}
```
**FSx for OpenZFS 추가(선택 사항):**
FSx for OpenZFS 파일 시스템을 탑재할 수도 있습니다.
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-0xyz789abc123456.fsx.us-west-2.amazonaws.com",
"MountPath": "/shared"
}
}
]
```
**참고**
각 인스턴스 그룹은 최대 하나의 FSx for Lustre 및 하나의 FSx for OpenZFS 구성을 가질 수 있습니다. 인스턴스 그룹마다 다른 파일 시스템을 탑재할 수 있습니다.
**VPC 구성 추가(FSx에 필요):**
FSx를 사용하는 경우 사용자 지정 VPC 구성을 지정해야 합니다.
```
{
"ClusterName": "my-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-//src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam:::role/HyperPodExecutionRole"
},
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"VpcConfig": {
"SecurityGroupIds": ["sg-0abc123def456789a"],
"Subnets": ["subnet-0abc123def456789a"]
}
}
```
1. 다음 명령을 실행하여 클러스터를 생성합니다.
```
aws sagemaker create-cluster --cli-input-json file://complete/path/to/create_cluster.json
```
이렇게 하면 생성된 클러스터의 ARN이 반환됩니다.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster"
}
```
리소스 제한으로 인해 오류가 발생하는 경우 계정의 할당량이 충분한 인스턴스 유형으로 변경하거나 [SageMaker HyperPod 할당량](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-quotas)에 따라 추가 할당량을 요청해야 합니다.
**일반적인 검증 오류:**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/smcluster-getting-started-slurm-cli.html)
1. `describe-cluster`를 실행하여 클러스터의 상태를 확인합니다.
```
aws sagemaker describe-cluster --cluster-name my-hyperpod-cluster
```
응답 예제:
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/my-hyperpod-cluster",
"ClusterName": "my-hyperpod-cluster",
"ClusterStatus": "Creating",
"InstanceGroups": [
{
"InstanceGroupName": "my-controller-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Controller"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.m5.4xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Login"
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.trn1.32xlarge",
"InstanceCount": 1,
"CurrentCount": 0,
"TargetCount": 1,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["partition-1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://sagemaker-/src",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/HyperPodExecutionRole"
}
],
"Orchestrator": {
"Slurm": {
"SlurmConfigStrategy": "Managed"
}
},
"CreationTime": "2024-01-15T10:30:00Z"
}
```
클러스터 상태가 **InService**로 전환되면 다음 단계로 진행합니다. 클러스터 생성에는 일반적으로 10\$115분이 소요됩니다.
1. `list-cluster-nodes`를 실행하여 클러스터 노드의 세부 정보를 확인합니다.
```
aws sagemaker list-cluster-nodes --cluster-name my-hyperpod-cluster
```
응답 예제:
```
{
"ClusterNodeSummaries": [
{
"InstanceGroupName": "my-controller-group",
"InstanceId": "i-0abc123def456789a",
"InstanceType": "ml.c5.xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:35:00Z"
},
{
"InstanceGroupName": "my-login-group",
"InstanceId": "i-0abc123def456789b",
"InstanceType": "ml.m5.4xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:35:00Z"
},
{
"InstanceGroupName": "worker-group-1",
"InstanceId": "i-0abc123def456789c",
"InstanceType": "ml.trn1.32xlarge",
"InstanceStatus": {
"Status": "Running",
"Message": ""
},
"LaunchTime": "2024-01-15T10:36:00Z"
}
]
}
```
`InstanceId`는 클러스터 사용자가 로그인(`aws ssm`)하는 데 필요한 것입니다. 클러스터 노드에 로그인하고 ML 워크로드를 실행하는 방법에 대한 자세한 내용은 [SageMaker HyperPod 클러스터의 작업](sagemaker-hyperpod-run-jobs-slurm.md) 섹션을 참조하세요.
1. AWS Systems Manager 세션 관리자를 사용하여 클러스터에 연결합니다.
```
aws ssm start-session \
--target sagemaker-cluster:my-hyperpod-cluster_my-login-group-i-0abc123def456789b \
--region us-west-2
```
연결되면 Slurm이 올바르게 구성되었는지 확인합니다.
```
# Check Slurm nodes
sinfo
# Check Slurm partitions
sinfo -p partition-1
# Submit a test job
srun -p partition-1 --nodes=1 hostname
```
## 클러스터를 삭제하고 리소스를 정리합니다.
SageMaker HyperPod 클러스터 생성을 성공적으로 테스트한 후 클러스터를 삭제할 때까지 `InService` 상태에서 계속 실행됩니다. 온디맨드 요금을 기준으로 지속적인 서비스 요금이 발생하지 않도록 온디맨드 SageMaker AI 용량을 사용하여 생성된 클러스터를 사용하지 않을 때는 삭제하는 것이 좋습니다. 이 자습서에서는 세 개의 인스턴스 그룹으로 구성된 클러스터를 생성했습니다. 다음 명령을 실행하여 클러스터를 삭제해야 합니다.
```
aws sagemaker delete-cluster --cluster-name my-hyperpod-cluster
```
이 자습서에 사용되는 Amazon S3 버킷에서 수명 주기 스크립트를 정리하려면 클러스터 생성 중에 사용한 Amazon S3 버킷으로 이동하여 파일을 완전히 제거합니다.
```
aws s3 rm s3://sagemaker-//src --recursive
```
클러스터에서 모델 훈련 워크로드 실행을 테스트한 경우 데이터를 업로드했는지 또는 Amazon FSx for Lustre 및 Amazon Elastic File System과 같은 다른 Amazon S3 버킷 또는 파일 시스템 서비스에 아티팩트를 저장했는지도 확인합니다. 요금이 발생하지 않도록 하려면 스토리지 또는 파일 시스템에서 모든 아티팩트와 데이터를 삭제합니다.
## 관련 주제
+ [SageMaker HyperPod Slurm 구성](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-configuration)
+ [수명 주기 스크립트를 사용하여 SageMaker HyperPod 클러스터 사용자 지정](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)
+ [InstanceStorageConfigs 통한 FSx 구성](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-slurm-fsx-config)
+ [SageMaker HyperPod Slurm 클러스터 작업](sagemaker-hyperpod-operate-slurm.md)
# SageMaker HyperPod Slurm 클러스터 작업
이 섹션에서는 SageMaker AI 콘솔 UI 또는 AWS Command Line Interface (CLI)를 통해 SageMaker HyperPod를 관리하는 방법에 대한 지침을 제공합니다. 시각적 인터페이스를 선호하든 명령으로 작업하든 SageMaker HyperPod와 관련된 다양한 작업을 수행하는 방법을 알아봅니다.
**Topics**
+ [
# SageMaker 콘솔을 사용하여 SageMaker HyperPod Slurm 클러스터 관리
](sagemaker-hyperpod-operate-slurm-console-ui.md)
+ [
# 를 사용하여 SageMaker HyperPod Slurm 클러스터 관리 AWS CLI
](sagemaker-hyperpod-operate-slurm-cli-command.md)
# SageMaker 콘솔을 사용하여 SageMaker HyperPod Slurm 클러스터 관리
다음 주제에서는 콘솔 UI를 통해 SageMaker HyperPod를 관리하는 방법에 대한 지침을 제공합니다.
**Topics**
+ [
## SageMaker HyperPod 클러스터 생성
](#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster)
+ [
## SageMaker HyperPod 클러스터 찾아보기
](#sagemaker-hyperpod-operate-slurm-console-ui-browse-clusters)
+ [
## 각 SageMaker HyperPod 클러스터의 세부 정보 보기
](#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters)
+ [
## SageMaker HyperPod 클러스터 편집
](#sagemaker-hyperpod-operate-slurm-console-ui-edit-clusters)
+ [
## SageMaker HyperPod 클러스터 삭제
](#sagemaker-hyperpod-operate-slurm-console-ui-delete-cluster)
## SageMaker HyperPod 클러스터 생성
SageMaker HyperPod 콘솔 UI를 통해 새 SageMaker HyperPod 클러스터를 생성하는 방법에 대해서는 [SageMaker AI 콘솔을 사용하여 SageMaker HyperPod 시작하기](smcluster-getting-started-slurm-console.md)의 지침을 참조하세요.
## SageMaker HyperPod 클러스터 찾아보기
SageMaker HyperPod 콘솔 메인 페이지의 SageMaker HyperPod 콘솔 메인 창에 있는 **클러스터**에서, 생성된 모든 클러스터가 **클러스터** 섹션 아래에 표시되어야 합니다. 클러스터 섹션은 클러스터, 해당 ARN, 상태 및 생성 시간에 대한 요약 뷰를 제공합니다.
## 각 SageMaker HyperPod 클러스터의 세부 정보 보기
콘솔 기본 페이지의 **클러스터**에서 클러스터 **이름**이 링크로 활성화됩니다. 각 클러스터의 세부 정보를 보려면 클러스터 이름 링크를 선택합니다.
## SageMaker HyperPod 클러스터 편집
1. SageMaker HyperPod 콘솔의 메인 창에 있는 **클러스터**에서 업데이트할 클러스터를 선택합니다.
1. 클러스터를 선택하고 **편집**을 선택합니다.
1. ** 편집** 페이지에서 기존 인스턴스 그룹의 구성을 편집하고, 인스턴스 그룹을 더 추가하고, 인스턴스 그룹을 삭제하고, 클러스터의 태그를 변경할 수 있습니다. 변경한 후 **제출**을 선택합니다.
1. **인스턴스 그룹 구성** 섹션에서 **인스턴스 그룹 생성**을 선택하여 인스턴스 그룹을 더 추가할 수 있습니다.
1. **인스턴스 그룹 구성** 섹션에서 **편집**을 선택하여 구성을 변경하거나 **삭제**를 선택하여 인스턴스 그룹을 영구적으로 제거할 수 있습니다.
**중요**
인스턴스 그룹을 삭제할 때는 다음 사항을 고려하세요.
SageMaker HyperPod 클러스터는 항상 하나 이상의 인스턴스 그룹을 유지해야 합니다.
제거 전에 모든 중요 데이터가 백업되었는지 확인합니다.
제거 프로세스는 실행 취소할 수 없습니다.
**참고**
인스턴스 그룹을 삭제하면 해당 그룹과 연결된 모든 컴퓨팅 리소스가 종료됩니다.
1. **태그** 섹션에서 클러스터의 태그를 업데이트할 수 있습니다.
## SageMaker HyperPod 클러스터 삭제
1. SageMaker HyperPod 콘솔의 메인 창에 있는 **클러스터**에서 삭제할 클러스터를 선택합니다.
1. 클러스터를 선택하고 **삭제**를 선택합니다.
1. 클러스터 삭제를 위한 팝업 창에서 클러스터 정보를 주의 깊게 검토하여 삭제할 올바른 클러스터를 선택했는지 확인합니다.
1. 클러스터 정보를 검토한 후 **예, 클러스터 삭제**를 선택합니다.
1. 이 삭제를 확인하려면 텍스트 필드에 **delete**를 입력합니다.
1. 팝업 창의 오른쪽 하단 모서리에서 **삭제**를 선택하여 클러스터 삭제 요청 전송을 완료합니다.
# 를 사용하여 SageMaker HyperPod Slurm 클러스터 관리 AWS CLI
다음 주제에서는 JSON 형식으로 SageMaker HyperPod API 요청 파일을 작성하고 AWS CLI 명령을 사용하여 실행하는 방법에 대한 지침을 제공합니다.
**Topics**
+ [
## 새 클러스터 생성:
](#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster)
+ [
## 클러스터 설명
](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster)
+ [
## 클러스터 노드의 세부 정보 나열
](#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes)
+ [
## 클러스터 노드의 세부 정보 설명
](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster-node)
+ [
## 클러스터 나열
](#sagemaker-hyperpod-operate-slurm-cli-command-list-clusters)
+ [
## 클러스터 구성 업데이트
](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster)
+ [
## 클러스터의 SageMaker HyperPod 플랫폼 소프트웨어 업데이트
](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software)
+ [
## 클러스터 스케일 다운
](#sagemaker-hyperpod-operate-slurm-cli-command-scale-down)
+ [
## 클러스터 삭제
](#sagemaker-hyperpod-operate-slurm-cli-command-delete-cluster)
## 새 클러스터 생성:
1. 수명 주기 구성 스크립트를 준비하고 와 같은 S3 버킷에 업로드합니다`s3://sagemaker-amzn-s3-demo-bucket/lifecycle-script-directory/src/`. 다음 2단계에서는 지정된 S3 버킷에 `on_create.sh`라는 진입점 스크립트가 있다고 가정합니다.
**중요**
S3 경로를 `s3://sagemaker-`로 시작하도록 설정해야 합니다. [SageMaker HyperPod의 IAM 역할](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod)에는 관리형 [https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-cluster.html](https://docs.aws.amazon.com/sagemaker/latest/dg/security-iam-awsmanpol-cluster.html)가 연결되어 있으므로 특정 접두사가 `sagemaker-`인 S3 버킷에 액세스할 수 있습니다.
1. [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html) API 요청 파일을 JSON 형식으로 준비합니다. 수명 주기 스크립트 세트 실행의 일부로 클러스터 생성 중에 사용할 `provisioning_parameters.json` 파일에서 설계한 Slurm 클러스터와 일치하도록 인스턴스 그룹을 구성해야 합니다. 자세한 내용은 [수명 주기 스크립트를 사용하여 SageMaker HyperPod 클러스터 사용자 지정](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)를 참조하세요. 다음 템플릿에는 Slurm 클러스터의 최소 요구 사항을 충족하는 두 개의 인스턴스 그룹이 있습니다. 컨트롤러(헤드) 노드 1개와 컴퓨팅(워커) 노드 1개. `ExecutionRole`의 경우 [SageMaker HyperPod의 IAM 역할](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) 섹션에서 관리형 `AmazonSageMakerClusterInstanceRolePolicy`로 생성한 IAM 역할의 ARN을 제공합니다.
```
// create_cluster.json
{
"ClusterName": "your-hyperpod-cluster",
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
// Optional: Configure an additional storage per instance group.
"InstanceStorageConfigs": [
{
// Attach an additional EBS volume to each instance within the instance group.
// The default mount path for the additional EBS volume is /opt/sagemaker.
"EbsVolumeConfig":{
// Specify an integer between 1 and 16384 in gigabytes (GB).
"VolumeSizeInGB": integer,
}
}
]
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.p4d.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster"
}
],
// Optional
"Tags": [
{
"Key": "string",
"Value": "string"
}
],
// Optional
"VpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
}
}
```
수명 주기 스크립트를 통해 클러스터 구조를 설계하는 방법에 따라 `InstanceGroups` 파라미터에서 최대 20개의 인스턴스 그룹을 구성할 수 있습니다.
`Tags` 요청 파라미터의 경우 SageMaker HyperPod 클러스터를 AWS 리소스로 관리하기 위한 사용자 지정 태그를 추가할 수 있습니다. 태그 지정을 지원하는 다른 AWS 서비스에서 추가하는 것과 동일한 방식으로 클러스터에 태그를 추가할 수 있습니다. 일반적인 AWS 리소스 태그 지정에 대한 자세한 내용은 [AWS 리소스 태그 지정 사용 설명서를](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) 참조하세요.
`VpcConfig` 요청 파라미터에 사용할 VPC의 정보를 지정합니다. 자세한 내용은 [사용자 지정 Amazon VPC를 사용하여 SageMaker HyperPod 설정](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc) 섹션을 참조하세요.
1. 다음과 같이 [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-cluster.html) 명령을 실행합니다.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
그러면 새 클러스터의 ARN이 반환됩니다.
## 클러스터 설명
[describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster.html)를 실행하여 클러스터의 상태를 확인합니다. 클러스터의 이름 또는 ARN을 지정할 수 있습니다.
```
aws sagemaker describe-cluster --cluster-name your-hyperpod-cluster
```
클러스터 상태가 **InService**로 전환되면 다음 단계로 진행합니다. 이 API를 사용하면 다른 HyperPod API 작업을 실행하여 장애 메시지를 검색할 수도 있습니다.
## 클러스터 노드의 세부 정보 나열
[list-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-cluster-nodes.html)를 실행하여 클러스터 노드의 키 정보를 확인합니다.
```
aws sagemaker list-cluster-nodes --cluster-name your-hyperpod-cluster
```
이렇게 하면 응답이 반환되고 `InstanceId`는 응답에 로깅(`aws ssm` 사용)하는 데 사용해야 하는 것입니다.
## 클러스터 노드의 세부 정보 설명
[describe-cluster-node](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/describe-cluster-node.html)를 실행하여 클러스터 노드의 세부 정보를 검색합니다. list-cluster-nodes 출력에서 클러스터 노드 ID를 가져올 수 있습니다. 클러스터의 이름 또는 ARN을 지정할 수 있습니다.
```
aws sagemaker describe-cluster-node \
--cluster-name your-hyperpod-cluster \
--node-id i-111222333444555aa
```
## 클러스터 나열
[list-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-clusters.html)를 실행하여 계정의 모든 클러스터를 나열합니다.
```
aws sagemaker list-clusters
```
추가 플래그를 추가하여 클러스터 목록을 필터링할 수도 있습니다. 이 명령이 하위 수준에서 실행되는 것과 필터링을 위한 추가 플래그에 대한 자세한 내용은 [ListClusters](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusters.html) API 참조를 참조하세요.
## 클러스터 구성 업데이트
[update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html)를 실행하여 클러스터 구성을 업데이트합니다.
**참고**
`UpdateCluster` API를 사용하여 SageMaker HyperPod 클러스터에서 인스턴스 그룹을 스케일 다운하거나 전체 인스턴스 그룹을 제거할 수 있습니다. 인스턴스 그룹을 스케일 다운하거나 삭제하는 방법에 대한 추가 지침은 [클러스터 스케일 다운](#sagemaker-hyperpod-operate-slurm-cli-command-scale-down) 섹션을 참조하세요.
1. JSON 형식으로 `UpdateCluster` 요청 파일을 생성합니다. 업데이트할 올바른 클러스터 이름과 인스턴스 그룹 이름을 지정해야 합니다. 인스턴스 유형, 인스턴스 수, 수명 주기 구성 진입점 스크립트 및 스크립트 경로를 변경할 수 있습니다.
1. `ClusterName`의 경우 업데이트할 클러스터 이름을 선택합니다.
1. `InstanceGroupName`의 경우
1. 기존 인스턴스 그룹을 업데이트하려면 업데이트하려는 인스턴스 그룹의 이름을 지정합니다.
1. 새 인스턴스 그룹을 추가하려면 클러스터에 없는 새 이름을 지정합니다.
1. `InstanceType`의 경우
1. 기존 인스턴스 그룹을 업데이트하려면 처음에 지정한 인스턴스 유형을 그룹에 일치시켜야 합니다.
1. 새 인스턴스 그룹을 추가하려면 그룹을 구성할 인스턴스 유형을 지정합니다.
1. `InstanceCount`의 경우
1. 기존 인스턴스 그룹을 업데이트하려면 원하는 인스턴스 수에 해당하는 정수를 지정합니다. 더 높거나 낮은 값(0까지)을 제공하여 인스턴스 그룹을 스케일 업하거나 스케일 다운할 수 있습니다.
1. 새 인스턴스 그룹을 추가하려면 1 이상의 정수를 지정합니다.
1. `LifeCycleConfig`의 경우 인스턴스 그룹을 업데이트하려는 대로 `SourceS3Uri` 및 `OnCreate` 값을 모두 변경할 수 있습니다.
1. `ExecutionRole`의 경우
1. 기존 인스턴스 그룹을 업데이트하려면 클러스터 생성 중에 연결한 것과 동일한 IAM 역할을 계속 사용합니다.
1. 새 인스턴스 그룹을 추가하려면 연결할 IAM 역할을 지정합니다.
1. `ThreadsPerCore`의 경우
1. 기존 인스턴스 그룹을 업데이트하려면 클러스터 생성 중에 지정한 것과 동일한 값을 계속 사용합니다.
1. 새 인스턴스 그룹을 추가하려면 인스턴스 유형별로 허용되는 옵션 중에서 원하는 값을 선택할 수 있습니다. 자세한 내용은 인스턴스 유형을 검색하고 *Amazon EC2 사용 설명서*의 [인스턴스 유형당 CPU 코어 및 CPU 코어당 스레드](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-options-supported-instances-values.html)에 있는 참조 테이블의 **코어당 유효한 스레드** 열을 참조하세요.
다음 코드 조각은 사용할 수 있는 JSON 요청 파일 템플릿입니다. 이 API의 요청 구문 및 파라미터에 대한 자세한 내용은 [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) API 참조를 참조하세요.
```
// update_cluster.json
{
// Required
"ClusterName": "name-of-cluster-to-update",
// Required
"InstanceGroups": [
{
"InstanceGroupName": "name-of-instance-group-to-update",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
// Optional: Configure an additional storage per instance group.
"InstanceStorageConfigs": [
{
// Attach an additional EBS volume to each instance within the instance group.
// The default mount path for the additional EBS volume is /opt/sagemaker.
"EbsVolumeConfig":{
// Specify an integer between 1 and 16384 in gigabytes (GB).
"VolumeSizeInGB": integer,
}
}
]
},
// add more blocks of instance groups as needed
{ ... }
]
}
```
1. 다음 `update-cluster` 명령을 실행하여 요청을 제출합니다.
```
aws sagemaker update-cluster \
--cli-input-json file://complete/path/to/update_cluster.json
```
## 클러스터의 SageMaker HyperPod 플랫폼 소프트웨어 업데이트
[update-cluster-software](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster-software.html)를 실행하여 SageMaker HyperPod 서비스에서 제공하는 소프트웨어 및 보안 패치로 기존 클러스터를 업데이트합니다. `--cluster-name`에서 업데이트할 클러스터의 이름 또는 ARN을 지정합니다.
**중요**
이 API를 실행하기 전에 작업을 백업해야 합니다. 패치 프로세스는 루트 볼륨을 업데이트된 AMI로 대체합니다. 즉, 인스턴스 루트 볼륨에 저장된 이전 데이터가 손실됩니다. 인스턴스 루트 볼륨에서 Amazon S3 또는 Amazon FSx for Lustre로 데이터를 백업해야 합니다. 자세한 내용은 [SageMaker HyperPod에서 제공하는 백업 스크립트 사용](#sagemaker-hyperpod-operate-slurm-cli-command-update-cluster-software-backup) 단원을 참조하십시오.
```
aws sagemaker update-cluster-software --cluster-name your-hyperpod-cluster
```
이 명령은 [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) API를 호출합니다. API 직접 호출 후 SageMaker HyperPod는 클러스터 인스턴스에 사용할 수 있는 최신 DLAMI가 있는지 확인합니다. DLAMI 업데이트가 필요한 경우 SageMaker HyperPod는 최신 [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami)를 사용하도록 클러스터 인스턴스를 업데이트하고 클러스터 생성 또는 업데이트 중에 지정한 Amazon S3 버킷에서 수명 주기 스크립트를 실행합니다. 클러스터가 이미 최신 DLAMI를 사용하고 있는 경우 SageMaker HyperPod는 클러스터를 변경하거나 수명 주기 스크립트를 다시 실행하지 않습니다. SageMaker HyperPod 서비스 팀은 보안을 강화하고 사용자 경험을 개선하기 위해 정기적으로 새 [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami)를 출시합니다. 항상 최신 SageMaker HyperPod DLAMI로 업데이트하는 것이 좋습니다. 보안 패치를 위한 향후 SageMaker HyperPod DLAMI 업데이트는 [Amazon SageMaker HyperPod 릴리스 정보](sagemaker-hyperpod-release-notes.md)를 사용하여 후속 조치를 취하세요.
**작은 정보**
보안 패치가 실패하면 [클러스터 설명](#sagemaker-hyperpod-operate-slurm-cli-command-describe-cluster)의 지침에 따라 [https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html) API를 실행하여 실패 메시지를 검색할 수 있습니다.
**참고**
프로그래밍 방식으로만 이 API를 실행할 수 있습니다. 패치 기능은 SageMaker HyperPod 콘솔 UI에서 구현되지 않습니다.
### SageMaker HyperPod에서 제공하는 백업 스크립트 사용
SageMaker HyperPod는 *Awsome Distributed Training GitHub 리포지토리*에서 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/patching-backup.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/patching-backup.sh)의 데이터를 백업하고 복원하는 스크립트를 제공합니다. 스크립트는 다음 두 함수를 제공합니다.
**패치 적용 전에 S3 버킷에 데이터를 백업하려면**
```
sudo bash patching-backup.sh --create
```
명령을 실행한 후 스크립트는 대기열에 작업이 있는지 `squeue`를 확인하고, 대기열에 작업이 없으면 Slurm을 중지하고, `mariadb`를 백업하고, `LOCAL_ITEMS`에 정의된 디스크에 로컬 항목을 복사합니다. `LOCAL_ITEMS`에 파일 및 디렉터리를 더 추가할 수 있습니다.
```
# Define files and directories to back up.
LOCAL_ITEMS=(
"/var/spool/slurmd"
"/var/spool/slurmctld"
"/etc/systemd/system/slurmctld.service"
"/home/ubuntu/backup_slurm_acct_db.sql"
# ... Add more items as needed
)
```
또한 제공된 스크립트에 사용자 지정 코드를 추가하여 사용 사례에 맞는 애플리케이션을 백업할 수 있습니다.
**패치 적용 후 S3 버킷에서 데이터를 복원하려면**
```
sudo bash patching-backup.sh --restore
```
## 클러스터 스케일 다운
SageMaker HyperPod 클러스터의 인스턴스 수를 스케일 다운하거나 인스턴스 그룹을 삭제하여 리소스 할당을 최적화하거나 비용을 절감할 수 있습니다.
`UpdateCluster` API 작업을 사용하여 인스턴스 그룹에서 지정된 수까지 인스턴스를 무작위로 종료하거나 `BatchDeleteClusterNodes` API 작업을 사용하여 특정 인스턴스를 종료하여 스케일 다운합니다. `UpdateCluster` API를 사용하여 전체 인스턴스 그룹을 완전히 제거할 수도 있습니다. 이러한 방법을 사용하여 스케일 다운하는 방법에 대한 자세한 내용은 [SageMaker HyperPod 클러스터 스케일 다운](smcluster-scale-down.md) 섹션을 참조하세요.
**참고**
Slurm 컨트롤러 노드로 구성된 인스턴스는 제거할 수 없습니다. Slurm 컨트롤러 노드를 삭제하려고 하면 `NODE_ID_IN_USE` 오류 코드와 함께 검증 오류가 발생합니다.
## 클러스터 삭제
[Delete-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-cluster.html)를 실행하여 클러스터를 삭제합니다. 클러스터의 이름 또는 ARN을 지정할 수 있습니다.
```
aws sagemaker delete-cluster --cluster-name your-hyperpod-cluster
```
# 수명 주기 스크립트를 사용하여 SageMaker HyperPod 클러스터 사용자 지정
SageMaker HyperPod는 항상 실행 중인 컴퓨팅 클러스터를 제공합니다. 이 클러스터는 수명 주기 스크립트를 작성하여 SageMaker HyperPod에 클러스터 리소스를 설정하는 방법을 알려주기 때문에 사용자 지정이 가능합니다. 다음 주제는 오픈 소스 워크로드 관리자 도구를 사용하여 SageMaker HyperPod 클러스터를 설정하기 위해 수명 주기 스크립트를 준비하는 모범 사례입니다.
다음 주제에서는 SageMaker HyperPod 에서 Slurm 구성을 설정하기 위한 수명 주기 스크립트를 준비하기 위한 심층 모범 사례를 설명합니다.
## 상위 수준 개요
다음 절차는 HyperPod 클러스터를 프로비저닝하고 Slurm으로 설정하는 주요 흐름입니다. 단계는 ***상향식*** 접근 방식 순서대로 배치됩니다.
1. HyperPod 클러스터에서 Slurm 노드를 생성하는 방법을 계획합니다. 예를 들어 두 개의 Slurm 노드를 구성하려면 HyperPod 클러스터에 두 개의 인스턴스 그룹을 설정해야 합니다.
1. Slurm 구성을 준비합니다. 다음 방법 중 하나를 선택합니다.
+ **옵션 A: API 기반 구성(권장) -** 각 인스턴스 그룹 `SlurmConfig` 내에서를 사용하여 `CreateCluster` API 페이로드에서 직접 Slurm 노드 유형 및 파티션을 정의합니다. 이 접근 방식을 사용하면 다음과 같습니다.
+ `provisioning_parameters.json` 파일이 필요하지 않음
+ Slurm 토폴로지는 인스턴스 그룹 정의와 함께 API 페이로드에 정의됩니다.
+ FSx 파일 시스템은를 통해 per-instance-group 구성됩니다. `InstanceStorageConfigs`
+ 구성 전략은를 통해 제어됩니다. `Orchestrator.Slurm.SlurmConfigStrategy`
인스턴스 그룹의 `SlurmConfig` 예:
```
{
"InstanceGroupName": "gpu-compute",
"InstanceType": "ml.p4d.24xlarge",
"InstanceCount": 8,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
```
+ **옵션 B: 레거시 구성** - 인 `provisioning_parameters.json` 파일을 준비합니다[provisioning\$1parameters.json 구성 양식](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm). 에는 HyperPod 클러스터에 프로비저닝할 Slurm 노드 구성 정보가 포함되어야 `provisioning_parameters.json` 합니다. 이는 1단계의 Slurm 노드 설계를 반영해야 합니다.
1. 수명 주기 스크립트 세트를 준비하여 소프트웨어 패키지를 설치하고 사용 사례에 맞게 클러스터에 환경을 설정하도록 HyperPod에 Slurm을 설정합니다. 수명 주기 스크립트를 중앙 Python 스크립트(`lifecycle_script.py`)에서 순서대로 일괄 실행하도록 구성하고 진입점 쉘 스크립트(`on_create.sh`)를 작성하여 Python 스크립트를 실행해야 합니다. 진입점 쉘 스크립트는 5단계 후반부에서 HyperPod 클러스터 생성 요청에 제공해야 하는 항목입니다.
또한 `resource_config.json`가 클러스터 생성 중에 HyperPod에서 생성할 것으로 예상되는 스크립트를 작성해야 합니다. `resource_config.json`에는 IP 주소, 인스턴스 유형 및 ARN과 같은 HyperPod 클러스터 리소스 정보가 포함되어 있으며 이는 Slurm을 구성하는 데 사용해야 합니다.
1. 이전 단계의 모든 파일을 폴더로 수집합니다. 폴더 구조는 2단계에서 선택한 구성 접근 방식에 따라 달라집니다.
옵션 A(API 기반 구성)를 선택한 경우:
폴더에는 사용자 지정 설정 작업에 대한 수명 주기 스크립트만 필요합니다. Slurm 구성 및 FSx 탑재는 API 페이로드를 기반으로 HyperPod에서 자동으로 처리됩니다.
```
└── lifecycle_files // your local folder
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scripts to be fed into lifecycle_script.py
```
**참고**
API 기반 구성을 사용할 때는 `provisioning_parameters.json` 파일이 필요하지 않습니다.
옵션 B(레거시 구성)를 선택한 경우:
폴더에는 `provisioning_parameters.json` 및 전체 수명 주기 스크립트 세트가 포함되어야 합니다.
```
└── lifecycle_files // your local folder
├── provisioning_parameters.json
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scrips to be fed into lifecycle_script.py
```
1. 모든 파일을 S3 버킷에 업로드합니다. S3 버킷 경로를 복사하고 유지합니다. 접두사 `sagemaker-`로 시작하는 S3 버킷 경로만 허용하는 [`AmazonSageMakerClusterInstanceRolePolicy`](security-iam-awsmanpol-AmazonSageMakerClusterInstanceRolePolicy.md)로 연결된 [SageMaker HyperPod의 IAM 역할](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod)를 선택해야 하므로 `sagemaker-`로 시작하는 S3 버킷 경로를 생성해야 합니다. 다음 명령은 모든 파일을 S3 버킷에 업로드하는 예제 명령입니다.
```
aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src
```
1. HyperPod 클러스터 생성 요청을 준비합니다.
+ 옵션 1:를 사용하는 경우의 지침에 따라 JSON 형식(`create_cluster.json`)으로 클러스터 생성 요청을 AWS CLI작성합니다[새 클러스터 생성:](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-create-cluster).
+ 옵션 2: SageMaker AI 콘솔 UI를 사용하는 경우 [SageMaker HyperPod 클러스터 생성](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster)의 지침에 따라 HyperPod 콘솔 UI에서 **클러스터 요청 생성** 양식을 작성합니다.
이 단계에서는 1단계와 2단계에서 계획한 것과 동일한 구조로 인스턴스 그룹을 생성해야 합니다. 또한 요청 양식에서 5단계의 S3 버킷을 지정해야 합니다.
1. 클러스터 생성 요청을 제출합니다. HyperPod는 요청에 따라 클러스터를 프로비저닝한 다음 HyperPod 클러스터 인스턴스에서 `resource_config.json` 파일을 생성하고 수명 주기 스크립트를 실행하는 클러스터에 Slurm을 설정합니다.
다음 주제에서는 HyperPod 클러스터 생성 중에 제대로 작동하도록 구성 파일 및 수명 주기 스크립트를 구성하는 방법에 대해 자세히 설명합니다.
**Topics**
+ [
## 상위 수준 개요
](#sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-highlevel-overview)
+ [
# HyperPod에서 제공하는 기본 수명 주기 스크립트
](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)
+ [
# HyperPod가 Slurm 구성 파일에서 관리하는 특정 구성
](sagemaker-hyperpod-lifecycle-best-practices-slurm-what-hyperpod-overrides-in-slurm-conf.md)
+ [
# Slurm 로그 교체
](sagemaker-hyperpod-slurm-log-rotation.md)
+ [
# Amazon FSx for Lustre 및 Amazon FSx for OpenZFS를 HyperPod 클러스터에 탑재
](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-setup-with-fsx.md)
+ [
# HyperPod에서 Slurm 클러스터를 생성하기 전에 JSON 구성 파일 검증
](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md)
+ [
# HyperPod Slurm 클러스터에서 프로덕션 워크로드를 실행하기 전에 런타임 검증
](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-runtime.md)
+ [
# HyperPod 클러스터 노드에서 대화형으로 수명 주기 스크립트 개발
](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-develop-lifecycle-scripts.md)
# HyperPod에서 제공하는 기본 수명 주기 스크립트
이 섹션에서는 ***하향식*** 접근 방식으로 HyperPod에서 Slurm을 설정하는 기본 흐름의 모든 구성 요소를 안내합니다. `CreateCluster` API를 실행하기 위한 HyperPod 클러스터 생성 요청을 준비하는 것부터 시작하여 계층 구조에 대해 자세히 살펴보고 수명 주기 스크립트로 이동합니다. [Awsome Distributed Training GitHub 리포지토리](https://github.com/aws-samples/awsome-distributed-training/) 에 제공된 샘플 수명 주기 스크립트를 사용합니다. 리포지토리를 복제하려면 다음 명령을 실행합니다.
```
git clone https://github.com/aws-samples/awsome-distributed-training/
```
SageMaker HyperPod에서 Slurm 클러스터를 설정하기 위한 기본 수명 주기 스크립트는 [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)에서 확인할 수 있습니다.
```
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
```
다음 흐름도는 기본 수명 주기 스크립트를 설계하는 방법에 대한 자세한 개요를 보여줍니다. 다이어그램 아래의 설명과 절차 안내서는 HyperPod `CreateCluster` API 호출 중에 어떻게 작동하는지 설명합니다.
![\[HyperPod 클러스터 생성 및 수명 주기 스크립트의 구조에 대한 자세한 흐름도입니다.\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod-lifecycle-structure.png)
***그림:** HyperPod 클러스터 생성 및 수명 주기 스크립트의 구조에 대한 자세한 흐름도입니다. (1) 점선 화살표는 상자가 “called into”인 위치로 이동되며 구성 파일 및 수명 주기 스크립트 준비의 흐름을 보여줍니다. 이는 `provisioning_parameters.json` 및 수명 주기 스크립트 준비부터 시작됩니다. 그런 다음 집합 실행을 위해 `lifecycle_script.py`에 순서대로 코딩됩니다. 또한 `lifecycle_script.py` 스크립트 실행은 HyperPod 인스턴스 터미널에서 실행할 `on_create.sh` 쉘 스크립트에 의해 수행됩니다. (2) 실선 화살표는 기본 HyperPod 클러스터 생성 흐름과 상자가 "called into" 또는 "submitted to"로 호출되는 방법을 보여줍니다. `on_create.sh`는 콘솔 UI의 `create_cluster.json` 또는 **클러스터 생성** 요청 양식에서 클러스터 생성 요청에 필요합니다. 요청을 제출하면 HyperPod는 요청의 지정된 구성 정보와 수명 주기 스크립트를 기반으로 `CreateCluster` API를 실행합니다. (3) 점선 화살표는 클러스터 리소스 프로비저닝 중에 HyperPod 플랫폼이 클러스터 인스턴스에 `resource_config.json`을 생성함을 나타냅니다. `resource_config.json`에는 클러스터 ARN, 인스턴스 유형 및 IP 주소와 같은 HyperPod 클러스터 리소스 정보가 포함되어 있습니다. 클러스터 생성 중에 `resource_config.json` 파일을 예상할 수 있도록 수명 주기 스크립트를 준비해야 합니다. 자세한 내용은 아래 절차 가이드를 참조하세요.*
다음 절차 가이드에서는 HyperPod 클러스터 생성 중에 발생하는 작업과 기본 수명 주기 스크립트를 설계하는 방법을 설명합니다.
1. `create_cluster.json` – HyperPod 클러스터 생성 요청을 제출하려면 JSON 형식의 `CreateCluster` 요청 파일을 준비합니다. 이 모범 사례 예제에서는 요청 파일의 이름이 `create_cluster.json`이라고 가정합니다. 인스턴스 그룹으로 HyperPod 클러스터를 프로비저닝하려면 `create_cluster.json`을 작성합니다. 가장 좋은 방법은 HyperPod 클러스터에서 구성하려는 Slurm 노드 수와 동일한 수의 인스턴스 그룹을 추가하는 것입니다. 설정하려는 Slurm 노드에 할당할 인스턴스 그룹에 고유한 이름을 지정해야 합니다.
또한 S3 버킷 경로를 지정하여 전체 구성 파일 및 수명 주기 스크립트 세트를 `CreateCluster` 요청 양식의 필드 이름 `InstanceGroups.LifeCycleConfig.SourceS3Uri`에 저장하고, 항목 쉘 스크립트의 파일 이름(`on_create.sh` 명칭)을 `InstanceGroups.LifeCycleConfig.OnCreate`에 지정해야 합니다.
**참고**
HyperPod 콘솔 UI에서 **클러스터 제출 생성** 양식을 사용하는 경우 콘솔은 사용자를 대신하여 `CreateCluster` 요청 채우기 및 제출을 관리하고 백엔드에서 `CreateCluster` API를 실행합니다. 이 경우 `create_cluster.json`를 생성할 필요가 없습니다. 대신 **클러스터 생성** 제출 양식에 올바른 클러스터 구성 정보를 지정해야 합니다.
1. `on_create.sh` - 각 인스턴스 그룹에 대해 명령을 실행하고, 스크립트인 실행하여 소프트웨어 패키지를 설치하고, Slurm을 사용하여 HyperPod 클러스터 환경을 설정하려면 진입점 쉘 스크립트인 `on_create.sh`를 제공해야 합니다. 준비해야 할 두 가지 사항은 Slurm을 설정하기 위해 HyperPod에 필요한 `provisioning_parameters.json`와 소프트웨어 패키지를 설치하기 위해 수명 주기 스크립트 세트입니다. 이 스크립트는 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/on_create.sh)의 샘플 스크립트에 표시된 대로 다음 파일을 찾아 실행하기 위해 작성되어야 합니다.
**참고**
전체 수명 주기 스크립트 세트를 `create_cluster.json`에서 지정한 S3 위치에 업로드해야 합니다. 또한 `provisioning_parameters.json`를 동일한 위치에 배치해야 합니다.
1. `provisioning_parameters.json` – [provisioning\$1parameters.json 구성 양식](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-provisioning-forms-slurm)입니다. `on_create.sh` 스크립트는 이 JSON 파일을 찾고 경로 식별을 위한 환경 변수를 정의합니다. 이 JSON 파일을 통해 Slurm 노드와 Slurm용 Amazon FSx와 같은 스토리지 옵션을 구성하여 통신할 수 있습니다. `provisioning_parameters.json`에서 `create_cluster.json`에 지정한 이름을 사용하여 HyperPod 클러스터 인스턴스 그룹을 설정 방식에 따라 적절하게 Slurm 노드에 할당해야 합니다.
다음 다이어그램은 두 JSON 구성 파일인 `create_cluster.json` 및 `provisioning_parameters.json`을 작성하여 HyperPod 인스턴스 그룹을 Slurm 노드에 할당하는 방법의 예를 보여줍니다. 이 예제에서는 컨트롤러(관리) 노드, 로그인 노드(선택 사항) 및 컴퓨팅(작업자) 노드라는 세 개의 Slurm 노드를 설정하는 경우를 가정합니다.
**작은 정보**
이 두 JSON 파일을 검증하는 데 도움이 되도록 HyperPod 서비스 팀은 검증 스크립트인 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py)를 제공합니다. 자세한 내용은 [HyperPod에서 Slurm 클러스터를 생성하기 전에 JSON 구성 파일 검증](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-validate-json-files.md)를 참조하세요.
![\[.json 파일 간의 직접 비교.\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod-lifecycle-slurm-config.png)
***그림:** `create_cluster.json` HyperPod 클러스터 생성과 `provisiong_params.json` Slurm 구성을 직접 비교합니다. `create_cluster.json`의 인스턴스 그룹 수는 Slurm 노드로 구성하려는 노드 수와 일치해야 합니다. 그림의 예제의 경우 세 개의 인스턴스 그룹으로 구성된 HyperPod 클러스터에 세 개의 Slurm 노드가 구성됩니다. 이에 따라 인스턴스 그룹 이름을 지정하여 HyperPod 클러스터 인스턴스 그룹을 Slurm 노드에 할당해야 합니다.*
1. `resource_config.json` - 클러스터 생성 중에 `lifecycle_script.py` 스크립트는 HyperPod 에서 `resource_config.json` 파일을 예상하도록 작성됩니다. 이 파일에는 인스턴스 유형 및 IP 주소와 같은 클러스터에 대한 정보가 포함되어 있습니다.
`CreateCluster` API를 실행하면 HyperPod는 파일을 `create_cluster.json` 기반으로 `/opt/ml/config/resource_config.json`에서 리소스 구성 파일을 생성합니다. 파일 경로는 `SAGEMAKER_RESOURCE_CONFIG_PATH`라는 환경 변수에 저장됩니다.
**중요**
`resource_config.json` 파일은 HyperPod 플랫폼에서 자동으로 생성되므로 생성할 필요가 없습니다. 다음 코드는 `create_cluster.json` 이전 단계를 기반으로 클러스터 생성에서 생성되는 `resource_config.json`의 예를 보여주고 백엔드에서 어떤 일이 발생하고 자동 생성된 `resource_config.json`이 어떻게 보일지 이해하는 데 도움이 됩니다.
```
{
"ClusterConfig": {
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz",
"ClusterName": "your-hyperpod-cluster"
},
"InstanceGroups": [
{
"Name": "controller-machine",
"InstanceType": "ml.c5.xlarge",
"Instances": [
{
"InstanceName": "controller-machine-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
},
{
"Name": "login-group",
"InstanceType": "ml.m5.xlarge",
"Instances": [
{
"InstanceName": "login-group-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
},
{
"Name": "compute-nodes",
"InstanceType": "ml.trn1.32xlarge",
"Instances": [
{
"InstanceName": "compute-nodes-1",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-2",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-3",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
},
{
"InstanceName": "compute-nodes-4",
"AgentIpAddress": "111.222.333.444",
"CustomerIpAddress": "111.222.333.444",
"InstanceId": "i-12345abcedfg67890"
}
]
}
]
}
```
1. `lifecycle_script.py` - 프로비저닝되는 동안 HyperPod 클러스터에서 Slurm을 설정하는 수명 주기 스크립트를 집합적으로 실행하는 기본 Python 스크립트입니다. 이 스크립트는 `on_create.sh`에 지정되거나 식별된 경로에서 `provisioning_parameters.json` 및 `resource_config.json`을 읽고 관련 정보를 각 수명 주기 스크립트에 전달한 다음 수명 주기 스크립트를 순서대로 실행합니다.
수명 주기 스크립트는 Slurm 설정, 사용자 생성, Conda 또는 Docker 설치와 같이 클러스터 생성 중에 소프트웨어 패키지를 설치하고 필수 또는 사용자 지정 구성을 설정할 수 있는 완전한 유연성을 가진 스크립트 세트입니다. 샘플 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py) 스크립트는 리포지토리에서 Slurm 데몬 시작([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/start_slurm.sh)), Amazon FSx for Lustre 탑재([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/mount_fsx.sh)), MariaDB 계정 설정([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_mariadb_accounting.sh)) 및 RDS 계정 설정([https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_rds_accounting.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/setup_rds_accounting.sh))과 같은 다른 기본 수명 주기 스크립트를 실행할 준비가 되어 있습니다. 또한 스크립트를 더 추가하고, 동일한 디렉터리에 패키징하고, `lifecycle_script.py`에 코드 라인을 추가하여 HyperPod가 스크립트를 실행할 수 있습니다. 기본 수명 주기 스크립트에 대한 자세한 내용은 *Awsome Distributed Training GitHub 리포지토리*의 [3.1 수명 주기 스크립트](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#31-lifecycle-scripts)도 참조하세요.
**참고**
HyperPod는 클러스터의 각 인스턴스에서 [SageMaker HyperPod DLAMI](sagemaker-hyperpod-ref.md#sagemaker-hyperpod-ref-hyperpod-ami)를 실행하며 AMI에는 클러스터와 HyperPod 기능 간의 호환성을 준수하는 소프트웨어 패키지가 사전 설치되어 있습니다. 사전 설치된 패키지를 다시 설치하는 경우 호환되는 패키지를 설치할 책임이 있으며 일부 HyperPod 기능이 예상대로 작동하지 않을 수 있습니다.
기본 설정 외에도 [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils) 폴더 아래에서 다음 소프트웨어를 설치하기 위한 스크립트를 더 많이 사용할 수 있습니다. `lifecycle_script.py` 파일은 설치 스크립트를 실행하기 위한 코드 라인을 포함하도록 이미 준비되었습니다. 따라서 다음 항목을 참조하여 해당 행을 검색하고 설명하지 않고 활성화하세요.
1. 다음 코드 라인은 [Docker ](https://www.docker.com/), [Enroot](https://github.com/NVIDIA/enroot) 및 [Pyxis](https://github.com/NVIDIA/pyxis)를 설치하기 위한 것입니다. 이러한 패키지는 Slurm 클러스터에서 Docker 컨테이너를 실행하는 데 필요합니다.
이 설치 단계를 활성화하려면 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) 파일에서 `enable_docker_enroot_pyxis` 파라미터를 `True`로 설정합니다.
```
# Install Docker/Enroot/Pyxis
if Config.enable_docker_enroot_pyxis:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type)
```
1. HyperPod 클러스터를 [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) 및 [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)와 통합하여 HyperPod 클러스터 및 클러스터 노드에 대한 지표를 Amazon Managed Grafana 대시보드로 내보낼 수 있습니다. 지표를 내보내고 Amazon Managed Grafana에서 [Slurm 대시보드](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/), [NVIDIA DCGM Exporter 대시보드](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/) 및 [EFA 지표 대시보드](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/)를 사용하려면 [Prometheus용 Slurm 내보내기](https://github.com/vpenso/prometheus-slurm-exporter), [NVIDIA DCGM 내보내기](https://github.com/NVIDIA/dcgm-exporter) 및 [EFA 노드 내보내기](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md)를 설치해야 합니다. Amazon Managed Grafana 워크스페이스에서 수출자 패키지를 설치하고 Grafana 대시보드를 사용하는 방법에 대한 자세한 내용은 [SageMaker HyperPod 클러스터 리소스 모니터링](sagemaker-hyperpod-cluster-observability-slurm.md) 섹션을 참조하세요.
이 설치 단계를 활성화하려면 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) 파일에서 `enable_observability` 파라미터를 `True`로 설정합니다.
```
# Install metric exporting software and Prometheus for observability
if Config.enable_observability:
if node_type == SlurmNodeType.COMPUTE_NODE:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()
if node_type == SlurmNodeType.HEAD_NODE:
wait_for_scontrol()
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
ExecuteBashScript("./utils/install_prometheus.sh").run()
```
1. **2단계**의 모든 구성 파일과 설정 스크립트를 **1단계**의 `CreateCluster` 요청에 제공한 S3 버킷에 업로드해야 합니다. 예를 들어, `create_cluster.json`에 다음이 있다고 가정하겠습니다.
```
"LifeCycleConfig": {
"SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src",
"OnCreate": "on_create.sh"
}
```
그런 다음 `"s3://sagemaker-hyperpod-lifecycle/src"`에는 `on_create.sh`, `lifecycle_script.py`, `provisioning_parameters.json` 및 기타 모든 설정 스크립트가 포함되어야 합니다. 다음과 같이 로컬 폴더의 파일을 준비했다고 가정합니다.
```
└── lifecycle_files // your local folder
├── provisioning_parameters.json
├── on_create.sh
├── lifecycle_script.py
└── ... // more setup scrips to be fed into lifecycle_script.py
```
파일을 업로드하려면 다음과 같이 S3 명령을 사용합니다.
```
aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src
```
# HyperPod가 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`을 관리합니다.
# Slurm 로그 교체
SageMaker HyperPod는 Slurm 데몬 로그에 대한 자동 로그 교체를 제공하여 디스크 공간 사용량을 관리하고 시스템 성능을 유지하는 데 도움이 됩니다. 로그 교체는 로그가 과도한 디스크 공간을 소비하지 않도록 방지하고 최신 로깅 정보를 유지하면서 이전 로그 파일을 자동으로 보관 및 제거하여 최적의 시스템 작업을 보장하는 데 매우 중요합니다. 클러스터를 생성할 때 Slurm 로그 교체가 기본적으로 활성화됩니다.
## 로그 교체 작동 방식
활성화되면 로그 교체 구성은 다음과 같습니다.
+ 컨트롤러, 로그인 및 컴퓨팅 노드의 `/var/log/slurm/` 폴더에 `.log` 있는 확장명으로 모든 Slurm 로그 파일을 모니터링합니다.
+ 크기가 50MB에 도달하면 로그를 교체합니다.
+ 로그 파일을 삭제하기 전에 최대 2개의 교체된 로그 파일을 유지합니다.
+ 교체 후 Slurm 데몬(`slurmctld`, `slurmd`및 `slurmdbd`)에 SIGUSR2 신호를 보냅니다.
## 교체된 로그 파일 목록
Slurm 로그는 `/var/log/slurm/` 디렉터리에 있습니다. 로그 교체는와 일치하는 모든 파일에 대해 활성화됩니다`/var/log/slurm/*.log`. 교체가 발생하면 교체된 파일에는 숫자 접미사(예: )가 있습니다`slurmd.log.1`. 다음 목록은 전체 목록은 아니지만 자동으로 교체되는 몇 가지 중요한 로그 파일을 보여줍니다.
+ `/var/log/slurm/slurmctld.log`
+ `/var/log/slurm/slurmd.log`
+ `/var/log/slurm/slurmdb.log`
+ `/var/log/slurm/slurmrestd.log`
## 로그 교체 활성화 또는 비활성화
다음 예제와 같이 클러스터 수명 주기 `config.py` 스크립트의 스크립트에 있는 `enable_slurm_log_rotation` 파라미터를 사용하여 로그 교체 기능을 제어할 수 있습니다.
```
class Config:
# Set false if you want to disable log rotation of Slurm daemon logs
enable_slurm_log_rotation = True # Default value
```
로그 교체를 비활성화하려면 다음 예제와 같이 파라미터를 `False`로 설정합니다.
```
enable_slurm_log_rotation = False
```
**참고**
수명 주기 스크립트는 클러스터 생성 중에 모든 Slurm 노드(컨트롤러, 로그인 및 컴퓨팅 노드)에서 실행됩니다. 클러스터에 추가될 때 새 노드에서도 실행됩니다. 로그 교체 구성 업데이트는 클러스터 생성 후 수동으로 수행해야 합니다. 로그 교체 구성은에 저장됩니다`/etc/logrotate.d/sagemaker-hyperpod-slurm`. 로그 파일이 과도한 디스크 공간을 소비하지 않도록 로그 교체를 활성화하는 것이 좋습니다. 로그 교체를 비활성화하려면 `sagemaker-hyperpod-slurm` 파일의 각 줄 시작 `#` 부분에를 추가하여 `sagemaker-hyperpod-slurm` 파일을 삭제하거나 내용을 주석 처리합니다.
## 기본 로그 교체 설정
교체된 각 로그 파일에 대해 다음 설정이 자동으로 구성됩니다.
| 설정 | 값 | 설명 |
| --- | --- | --- |
| rotate | 2 | 유지할 교체된 로그 파일 수 |
| size | 50MB | 교체 전 최대 크기 |
| copytruncate | enabled | 원본 로그 파일을 복사하고 잘라냅니다. |
| compress | disabled | 교체된 로그는 압축되지 않습니다. |
| missingok | enabled | 로그 파일이 누락된 경우 오류 없음 |
| notifempty | enabled | 빈 파일을 교체하지 않음 |
| noolddir | enabled | 교체된 파일은 동일한 디렉터리에 유지됩니다. |
# Amazon FSx for Lustre 및 Amazon FSx for OpenZFS를 HyperPod 클러스터에 탑재
Amazon FSx for Lustre 공유 파일 시스템을 HyperPod 클러스터에 탑재하려면 다음을 설정합니다.
1. Amazon VPC를 사용합니다.
1. HyperPod 클러스터 인스턴스가 VPC 내에서 통신하려면 SageMaker HyperPod 의 IAM 역할에 [사용자 지정 Amazon VPC를 사용하여 SageMaker HyperPod 설정](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-optional-vpc)를 연결해야 합니다.
1. `create_cluster.json`에 다음 VPC 정보를 포함합니다.
```
"VpcConfig": {
"SecurityGroupIds": [ "string" ],
"Subnets": [ "string" ]
}
```
Amazon VPC 설정에 대한 자세한 팁은 [SageMaker HyperPod 사용을 위한 사전 조건](sagemaker-hyperpod-prerequisites.md) 섹션을 참조하세요.
1. Amazon FSx for Lustre로 Slurm 구성을 완료하려면 다음 방법 중 하나를 사용할 수 있습니다. 계정의 Amazon FSx for Lustre 콘솔에서 또는 AWS CLI 명령을 실행하여 Amazon FSx 정보를 찾을 수 있습니다`aws fsx describe-file-systems`.
**옵션 A: API 기반 구성(권장)**
각 인스턴스 그룹 `InstanceStorageConfigs` 내에서를 사용하여 CreateCluster API 페이로드에서 Amazon FSx 구성을 직접 지정합니다. 이 접근 방식은 FSx for Lustre와 FSx for OpenZFS를 모두 지원하며 per-instance-group FSx 구성을 허용합니다.
```
"InstanceStorageConfigs": [
{
"FsxLustreConfig": {
"DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx",
"MountName": "1abcdefg"
}
}
]
```
FSx for OpenZFS의 경우 `FsxOpenZfsConfig` 대신를 사용합니다.
```
"InstanceStorageConfigs": [
{
"FsxOpenZfsConfig": {
"DnsName": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"MountPath": "/fsx-openzfs"
}
}
]
```
자세한 내용은 [AWS CLI를 사용하여 SageMaker HyperPod 시작하기를 참조하세요](sagemaker-hyperpod-quickstart.md).
**옵션 B: 레거시 구성**
[HyperPod에서 제공하는 기본 수명 주기 스크립트](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 섹션의 그림과 `provisioning_parameters.json` 같이에서 Amazon FSx DNS 이름과 Amazon FSx 탑재 이름을 지정합니다.
```
"fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"fsx_mountname": "1abcdefg"
```
# HyperPod에서 Slurm 클러스터를 생성하기 전에 JSON 구성 파일 검증
클러스터 생성 요청을 제출하기 전에 JSON 구성 파일을 검증하려면 구성 검증 스크립트 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/validate-config.py)를 사용합니다. 이 스크립트는 HyperPod 클러스터 구성 JSON 파일과 Slurm 구성 JSON 파일을 구문 분석하고 비교하며, 두 파일 간에 리소스 구성이 잘못되었는지 여부를 식별하고 Amazon EC2, Amazon VPC 및 Amazon FSx 리소스에서도 식별합니다. 예를 들어 [HyperPod에서 제공하는 기본 수명 주기 스크립트](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md) 섹션의 `create_cluster.json` 및 `provisioning_parameters.json` 파일을 검증하려면 다음과 같이 검증 스크립트를 실행합니다.
```
python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json
```
다음은 성공적인 검증의 예시 출력입니다.
```
✔️ Validated instance group name worker-group-1 is correct ...
✔️ Validated subnet subnet-012345abcdef67890 ...
✔️ Validated security group sg-012345abcdef67890 ingress rules ...
✔️ Validated security group sg-012345abcdef67890 egress rules ...
✔️ Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com
✔️ Validated FSx Lustre mount name abcdefgh
✅ Cluster Validation succeeded
```
# HyperPod Slurm 클러스터에서 프로덕션 워크로드를 실행하기 전에 런타임 검증
HyperPod의 Slurm 클러스터에서 프로덕션 워크로드를 실행하기 전에 런타임을 확인하려면 런타임 검증 스크립트 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/hyperpod-precheck.py)를 사용합니다. 이 스크립트는 Slurm 클러스터에 Docker를 실행하기 위해 설치된 모든 패키지가 있는지, 클러스터에 제대로 탑재된 FSx for Lustre 파일 시스템과 파일 시스템을 공유하는 사용자 디렉터리가 있는지, Slurm 데몬이 모든 컴퓨팅 노드에서 실행 중인지 확인합니다.
한 번에 여러 노드에서 스크립트를 실행하려면 다음 예제 명령과 같이 `srun`를 사용하여 8개의 노드로 구성된 Slurm 클러스터에서 스크립트를 실행합니다.
```
# The following command runs on 8 nodes
srun -N 8 python3 hyperpod-precheck.py
```
**참고**
스크립트가 제공하는 런타임 검증 함수 및 검증을 통과하지 못하는 문제를 해결하기 위한 지침과 같은 검증 스크립트에 대한 자세한 내용은 *Awsome Distributed Training GitHub 리포지토리*에서 [워크로드를 실행하기 전에 런타임 검증](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod#35-runtime-validation-before-running-workloads)을 참조하세요.
# HyperPod 클러스터 노드에서 대화형으로 수명 주기 스크립트 개발
이 섹션에서는 HyperPod 클러스터를 반복적으로 생성 및 삭제하지 않고 수명 주기 스크립트를 대화형으로 개발하는 방법을 설명합니다.
1. 기본 수명 주기 스크립트를 사용하여 HyperPod 클러스터를 생성합니다.
1. 클러스터 노드에 로그인합니다.
1. 노드에서 스크립트(`configure_xyz.sh`)를 편집하고 반복적으로 실행하여 스크립트를 개발합니다.
1. HyperPod는 수명 주기 스크립트를 루트 사용자로 실행하므로 개발 중에 `configure_xyz.sh`를 루트 사용자로 실행하여 HyperPod 에서 실행되는 동안 스크립트가 동일한 조건에서 테스트되는지 확인하는 것이 좋습니다.
1. 다음과 유사한 코드 줄을 추가하여 스크립트를 `lifecycle_script.py`에 통합합니다.
```
ExecuteBashScript("./utils/configure_xyz.sh").run()
```
1. 업데이트된 수명 주기 스크립트를 처음에 기본 수명 주기 스크립트 업로드에 사용한 S3 버킷에 업로드합니다.
1. 새 HyperPod 클러스터를 생성하여 `lifecycle_script.py`의 통합 버전을 테스트합니다. 수동 인스턴스 교체를 사용하여 새 인스턴스를 생성하여 업데이트된 수명 주기 스크립트를 테스트할 수도 있습니다. 자세한 지침은 [노드 수동 교체를](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance.html#sagemaker-hyperpod-resiliency-slurm-replace-faulty-instance-replace) 참조하세요. 작업자 노드만 교체할 수 있습니다.
# SageMaker HyperPod 다중 헤드 노드 지원
단일 SageMaker HyperPod Slurm 클러스터에 여러 컨트롤러(헤드) 노드를 생성할 수 있으며, 하나는 기본 컨트롤러 노드 역할을 하고 다른 하나는 백업 컨트롤러 노드 역할을 합니다. 기본 컨트롤러 노드는 컴퓨팅(워커) 노드를 제어하고 Slurm 작업을 처리하는 역할을 합니다. 백업 컨트롤러 노드는 기본 컨트롤러 노드를 지속적으로 모니터링합니다. 기본 컨트롤러 노드에 장애가 있거나 응답하지 않는 경우 백업 컨트롤러 노드 중 하나가 자동으로 새 기본 컨트롤러 노드로 역할을 맡습니다.
SageMaker HyperPod Slurm 클러스터에서 다중 컨트롤러 노드를 구성하면 몇 가지 주요 이점이 있습니다. 컨트롤러 헤드 노드를 제공하여 단일 컨트롤러 노드 장애 위험을 제거하고, 더 빠른 복구로 백업 컨트롤러 노드에 대한 자동 장애 조치를 활성화하며, 자체 회계 데이터베이스와 Slurm 구성을 독립적으로 관리할 수 있습니다.
## 주요 개념
다음은 Slurm 클러스터에 대한 SageMaker HyperPod 다중 컨트롤러(헤드) 노드 지원과 관련된 개념에 대한 세부 정보를 제공합니다.
**컨트롤러 노드**
컨트롤러 노드는 클러스터의 작업을 관리하고 조정하기 위해 중요한 Slurm 서비스를 실행하는 클러스터 내의 Amazon EC2 인스턴스입니다. 특히 [Slurm 컨트롤러 대몬(slurmctld)](https://slurm.schedmd.com/slurmctld.html)과 [Slurm 데이터베이스 대몬(slurmdbd)](https://slurm.schedmd.com/slurmdbd.html)을 호스팅합니다. 컨트롤러 노드를 헤드 노드라고도 합니다.
**기본 컨트롤러 노드**
기본 컨트롤러 노드는 Slurm 클러스터에서 활성 상태이고 현재 제어 중인 컨트롤러 노드입니다. Slurm에서 클러스터 관리를 담당하는 기본 컨트롤러 노드로 식별됩니다. 기본 컨트롤러 노드는 사용자로부터 명령을 수신하고 실행하여 작업을 실행하기 위해 컴퓨팅 노드의 리소스를 제어하고 할당합니다.
**백업 컨트롤러 노드**
백업 컨트롤러 노드는 Slurm 클러스터의 비활성 및 대기 컨트롤러 노드입니다. Slurm에 의해 현재 클러스터를 관리하지 않는 백업 컨트롤러 노드로 식별됩니다. 백업 컨트롤러 노드는 대기 모드에서 [Slurm 컨트롤러 대몬(slurmctld)](https://slurm.schedmd.com/slurmctld.html)을 실행합니다. 백업 컨트롤러 노드에서 실행되는 모든 컨트롤러 명령은 실행을 위해 기본 컨트롤러 노드로 전파됩니다. 기본 컨트롤러 노드를 지속적으로 모니터링하고 기본 컨트롤러 노드에 장애가 있거나 응답하지 않는 경우 기본 컨트롤러 노드의 책임을 맡는 것이 주요 목적입니다.
**컴퓨팅 노드**
컴퓨팅 노드는 [Slurm 워커 대몬(slurmd)](https://slurm.schedmd.com/slurmd.html)을 호스팅하는 클러스터 내의 Amazon EC2 인스턴스입니다. 컴퓨팅 노드의 기본 기능은 기본 컨트롤러 노드에서 실행되는 [Slurm 컨트롤러 대몬(slurmctld)](https://slurm.schedmd.com/slurmctld.html)에 의해 할당된 작업을 실행하는 것입니다. 작업이 예약되면 컴퓨팅 노드는 [Slurm 컨트롤러 대몬(slurmctld)](https://slurm.schedmd.com/slurmctld.html)으로부터 노드 자체 내에서 해당 작업에 필요한 작업 및 계산을 수행하라는 지침을 받습니다. 컴퓨팅을 워커 노드라고도 합니다.
## 작동 방식
다음 다이어그램은 다양한 AWS 서비스가 함께 작동하여 SageMaker HyperPod Slurm 클러스터에 대한 여러 컨트롤러(헤드) 노드 아키텍처를 지원하는 방법을 보여줍니다.
![\[SageMaker HyperPod 다중 헤드 노드 아키텍처 다이어그램\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod/hyperpod-multihead-architecture.png)
SageMaker HyperPod 다중 컨트롤러(헤드) 노드 아키텍처를 지원하기 위해 함께 작동하는 AWS 서비스에는 다음이 포함됩니다.
**AWS SageMaker HyperPod 다중 컨트롤러 노드 아키텍처를 지원하기 위해 함께 작동하는 서비스**
| 서비스 | 설명 |
| --- | --- |
| IAM(AWS Identity and Access Management) | 액세스 권한을 제어할 두 개의 IAM 역할을 정의합니다. 하나는 컴퓨팅 노드 인스턴스 그룹에 대한 역할이고 다른 하나는 컨트롤러 노드 인스턴스 그룹에 대한 역할입니다. |
| Amazon RDS for MariaDB | 작업 레코드와 측정 데이터를 보관하는 Slurm의 회계 데이터를 저장합니다. |
| AWS Secrets Manager | Amazon FSx for Lustre에서 액세스할 수 있는 자격 증명을 저장하고 관리합니다. |
| Amazon FSx for Lustre | Slurm 구성 및 런타임 상태를 저장합니다. |
| Amazon VPC | HyperPod 클러스터와 해당 리소스가 배포되는 격리된 네트워크 환경을 제공합니다. |
| Amazon SNS | 기본 컨트롤러(헤드) 노드와 관련된 상태 변경(Slurm 컨트롤러가 ON 또는 OFF 상태임)이 있는 경우 관리자에게 알림을 보냅니다. |
HyperPod 클러스터 자체는 컨트롤러 노드(기본 및 백업)와 컴퓨팅 노드로 구성됩니다. 컨트롤러 노드는 컴퓨팅 노드 전반의 워크로드를 관리하고 모니터링하는 Slurm 컨트롤러(SlurmCtld) 및 데이터베이스(SlurmDBd) 구성 요소를 실행합니다.
컨트롤러 노드는 Amazon FSx for Lustre 파일 시스템에 저장된 Slurm 구성 및 런타임 상태에 액세스합니다. Slurm 회계 데이터는 Amazon RDS for MariaDB 데이터베이스에 저장됩니다.는 컨트롤러 노드의 데이터베이스 자격 증명에 대한 보안 액세스를 AWS Secrets Manager 제공합니다.
Slurm 컨트롤러 노드에 상태 변경(Slurm 컨트롤러가 `ON` 또는 `OFF` 상태임)이 있는 경우 Amazon SNS는 추가 작업을 위해 관리자에게 알림을 보냅니다.
이 다중 컨트롤러 노드 아키텍처는 단일 컨트롤러(헤드) 노드의 단일 장애 지점을 제거하고, 빠른 자동 장애 조치 복구를 지원하며, Slurm 회계 데이터베이스 및 구성에 대한 제어 기능을 제공합니다.
# SageMaker HyperPod Slurm 클러스터에 대해 다중 컨트롤러 노드 설정
이 주제에서는 수명 주기 스크립트를 사용하여 SageMaker HyperPod Slurm 클러스터에 다중 컨트롤러(헤드) 노드를 구성하는 방법을 설명합니다. 시작하기 전에 [SageMaker HyperPod 사용을 위한 사전 조건](sagemaker-hyperpod-prerequisites.md)에 나열된 사전 조건을 검토하고 [수명 주기 스크립트를 사용하여 SageMaker HyperPod 클러스터 사용자 지정](sagemaker-hyperpod-lifecycle-best-practices-slurm.md)의 수명 주기 스크립트를 숙지하세요. 이 주제의 지침은 Amazon Linux 환경에서 AWS CLI 명령을 사용합니다. 이러한 명령에 사용되는 환경 변수는 명시적으로 보존되지 않는 한 현재 세션에서 사용할 수 있습니다.
**Topics**
+ [
# CloudFormation 스택을 사용하여 리소스 프로비저닝
](sagemaker-hyperpod-multihead-slurm-cfn.md)
+ [
# IAM 정책 생성 및 연결
](sagemaker-hyperpod-multihead-slurm-iam.md)
+ [
# 수명 주기 스크립트 준비 및 업로드
](sagemaker-hyperpod-multihead-slurm-scripts.md)
+ [
# SageMaker HyperPod 클러스터 생성
](sagemaker-hyperpod-multihead-slurm-create.md)
+ [
# 중요 참고 사항 고려
](sagemaker-hyperpod-multihead-slurm-notes.md)
+ [
# 환경 변수 참조 검토
](sagemaker-hyperpod-multihead-slurm-variables-reference.md)
# CloudFormation 스택을 사용하여 리소스 프로비저닝
HyperPod Slurm 클러스터에 여러 컨트롤러 노드를 설정하려면 [기본 리소스 프로비저닝](#sagemaker-hyperpod-multihead-slurm-cfn-basic) 및의 두 CloudFormation 스택을 통해 리소스를 프로비저닝 AWS 합니다[다중 컨트롤러 노드를 지원하는 추가 리소스 프로비저닝](#sagemaker-hyperpod-multihead-slurm-cfn-multihead).
## 기본 리소스 프로비저닝
다음 단계에 따라 Amazon SageMaker HyperPod Slurm 클러스터에 대한 기본 리소스를 프로비저닝합니다.
1. [sagemaker-hyperpod.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod.yaml) 템플릿 파일을 머신에 다운로드합니다. 이 YAML 파일은 Slurm 클러스터에 대해 생성할 다음 리소스를 정의하는 CloudFormation 템플릿입니다.
+ 컴퓨팅 노드 인스턴스 그룹에 대한 실행 IAM 역할
+ 수명 주기 스크립트를 저장할 Amazon S3 버킷
+ 퍼블릭 및 프라이빗 서브넷(프라이빗 서브넷은 NAT 게이트웨이를 통해 인터넷에 액세스할 수 있음)
+ 인터넷 게이트웨이/NAT 게이트웨이
+ Amazon EC2 보안 그룹 두 개
+ 구성 파일을 저장할 Amazon FSx 볼륨
1. 다음 CLI 명령을 실행하여 라는 CloudFormation 스택을 생성합니다`sagemaker-hyperpod`. `PrimarySubnetAZ` 및 `BackupSubnetAZ`에서 클러스터의 가용 영역(AZ) ID를 정의합니다. 예를 들어, *use1-az4*는 `us-east-1` 리전의 가용 영역에 대한 AZ ID입니다. 자세한 내용은 [Availability Zone IDs](https://docs.aws.amazon.com//ram/latest/userguide/working-with-az-ids.html) 및 [여러 AZ에서 SageMaker HyperPod 클러스터 설정](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-multiple-availability-zones) 섹션을 참조하세요.
```
aws cloudformation deploy \
--template-file /path_to_template/sagemaker-hyperpod.yaml \
--stack-name sagemaker-hyperpod \
--parameter-overrides PrimarySubnetAZ=use1-az4 BackupSubnetAZ=use1-az1 \
--capabilities CAPABILITY_IAM
```
자세한 내용은 AWS Command Line Interface 참조의 [배포](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/deploy/)를 참조하세요. 스택 생성을 완료하는 데 몇 분이 걸릴 수 있습니다. 완료되면 명령줄 인터페이스에 다음이 표시됩니다.
```
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - sagemaker-hyperpod
```
1. (선택 사항) [CloudFormation 콘솔](https://console.aws.amazon.com/cloudformation/home)에서 스택을 확인합니다.
+ 왼쪽 탐색에서 **스택**을 선택합니다.
+ **스택** 페이지에서 **sagemaker-hyperpod**를 찾아 선택합니다.
+ **리소스** 및 **출력**과 같은 탭을 선택하여 리소스 및 출력을 검토합니다.
1. 스택(`sagemaker-hyperpod`) 출력에서 환경 변수를 생성합니다. 이러한 변수의 값을 [다중 컨트롤러 노드를 지원하는 추가 리소스 프로비저닝](#sagemaker-hyperpod-multihead-slurm-cfn-multihead)에 사용합니다.
```
source .env
PRIMARY_SUBNET=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`PrimaryPrivateSubnet`].OutputValue' --output text)
BACKUP_SUBNET=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`BackupPrivateSubnet`].OutputValue' --output text)
EMAIL=$(bash -c 'read -p "INPUT YOUR SNSSubEmailAddress HERE: " && echo $REPLY')
DB_USER_NAME=$(bash -c 'read -p "INPUT YOUR DB_USER_NAME HERE: " && echo $REPLY')
SECURITY_GROUP=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`SecurityGroup`].OutputValue' --output text)
ROOT_BUCKET_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`AmazonS3BucketName`].OutputValue' --output text)
SLURM_FSX_DNS_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`FSxLustreFilesystemDNSname`].OutputValue' --output text)
SLURM_FSX_MOUNT_NAME=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`FSxLustreFilesystemMountname`].OutputValue' --output text)
COMPUTE_NODE_ROLE=$(aws --region $REGION cloudformation describe-stacks --stack-name $SAGEMAKER_STACK_NAME --query 'Stacks[0].Outputs[?OutputKey==`AmazonSagemakerClusterExecutionRoleArn`].OutputValue' --output text)
```
이메일 주소와 데이터베이스 사용자 이름을 묻는 메시지가 표시되면 다음과 같은 값을 입력합니다.
```
INPUT YOUR SNSSubEmailAddress HERE: Email_address_to_receive_SNS_notifications
INPUT YOUR DB_USER_NAME HERE: Database_user_name_you_define
```
변수 값을 확인하려면 `print $variable` 명령을 사용합니다.
```
print $REGION
us-east-1
```
## 다중 컨트롤러 노드를 지원하는 추가 리소스 프로비저닝
다음 단계에 따라 여러 컨트롤러 노드가 있는 Amazon SageMaker HyperPod Slurm 클러스터에 대한 추가 리소스를 프로비저닝합니다.
1. [sagemaker-hyperpod-slurm-multi-headnode.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/sagemaker-hyperpod-slurm-multi-headnode.yaml) 템플릿 파일을 머신에 다운로드합니다. 이 두 번째 YAML 파일은 Slurm 클러스터에서 여러 컨트롤러 노드 지원을 위해 생성할 추가 리소스를 정의하는 CloudFormation 템플릿입니다.
+ 컨트롤러 노드 인스턴스 그룹에 대한 실행 IAM 역할
+ Amazon RDS for MariaDB 인스턴스
+ Amazon SNS 주제 및 구독
+ AWS Secrets Manager Amazon RDS for MariaDB에 대한 자격 증명
1. 다음 CLI 명령을 실행하여 라는 CloudFormation 스택을 생성합니다`sagemaker-hyperpod-mh`. 이 두 번째 스택은 CloudFormation 템플릿을 사용하여 여러 컨트롤러 노드 아키텍처를 지원하는 추가 AWS 리소스를 생성합니다.
```
aws cloudformation deploy \
--template-file /path_to_template/slurm-multi-headnode.yaml \
--stack-name sagemaker-hyperpod-mh \
--parameter-overrides \
SlurmDBSecurityGroupId=$SECURITY_GROUP \
SlurmDBSubnetGroupId1=$PRIMARY_SUBNET \
SlurmDBSubnetGroupId2=$BACKUP_SUBNET \
SNSSubEmailAddress=$EMAIL \
SlurmDBUsername=$DB_USER_NAME \
--capabilities CAPABILITY_NAMED_IAM
```
자세한 내용은 AWS Command Line Interface 참조의 [배포](https://docs.aws.amazon.com//cli/latest/reference/cloudformation/deploy/)를 참조하세요. 스택 생성을 완료하는 데 몇 분이 걸릴 수 있습니다. 완료되면 명령줄 인터페이스에 다음이 표시됩니다.
```
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - sagemaker-hyperpod-mh
```
1. (선택 사항) [AWS Cloud Formation 콘솔](https://console.aws.amazon.com/cloudformation/home)에서 스택을 확인합니다.
+ 왼쪽 탐색에서 **스택**을 선택합니다.
+ **스택** 페이지에서 **sagemaker-hyperpod-mh**를 찾아 선택합니다.
+ **리소스** 및 **출력**과 같은 탭을 선택하여 리소스 및 출력을 검토합니다.
1. 스택(`sagemaker-hyperpod-mh`) 출력에서 환경 변수를 생성합니다. 이러한 변수의 값을 사용하여 [수명 주기 스크립트 준비 및 업로드](sagemaker-hyperpod-multihead-slurm-scripts.md)에서 구성 파일(`provisioning_parameters.json`)을 업데이트합니다.
```
source .env
SLURM_DB_ENDPOINT_ADDRESS=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmDBEndpointAddress`].OutputValue' --output text)
SLURM_DB_SECRET_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmDBSecretArn`].OutputValue' --output text)
SLURM_EXECUTION_ROLE_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmExecutionRoleArn`].OutputValue' --output text)
SLURM_SNS_FAILOVER_TOPIC_ARN=$(aws --region us-east-1 cloudformation describe-stacks --stack-name $MULTI_HEAD_SLURM_STACK --query 'Stacks[0].Outputs[?OutputKey==`SlurmFailOverSNSTopicArn`].OutputValue' --output text)
```
# IAM 정책 생성 및 연결
이 섹션에서는 IAM 정책을 생성하고 [다중 컨트롤러 노드를 지원하는 추가 리소스 프로비저닝](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-multihead)에서 생성한 실행 역할에 연결하는 방법을 설명합니다.
1. GitHub 리포지토리에서 [IAM policy example](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/1.AmazonSageMakerClustersExecutionRolePolicy.json)을 머신에 다운로드합니다.
1. [create-policy](https://docs.aws.amazon.com//cli/latest/reference/iam/create-policy.html) CLI 명령을 사용하여 다운로드한 예시로 IAM 정책을 생성합니다.
```
aws --region us-east-1 iam create-policy \
--policy-name AmazonSagemakerExecutionPolicy \
--policy-document file://1.AmazonSageMakerClustersExecutionRolePolicy.json
```
명령의 예시 출력입니다.
```
{
"Policy": {
"PolicyName": "AmazonSagemakerExecutionPolicy",
"PolicyId": "ANPAXISIWY5UYZM7WJR4W",
"Arn": "arn:aws:iam::111122223333:policy/AmazonSagemakerExecutionPolicy",
"Path": "/",
"DefaultVersionId": "v1",
"AttachmentCount": 0,
"PermissionsBoundaryUsageCount": 0,
"IsAttachable": true,
"CreateDate": "2025-01-22T20:01:21+00:00",
"UpdateDate": "2025-01-22T20:01:21+00:00"
}
}
```
1. [attach-role-policy](https://docs.aws.amazon.com//cli/latest/reference/iam/attach-role-policy.html) CLI 명령을 사용하여 [다중 컨트롤러 노드를 지원하는 추가 리소스 프로비저닝](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-multihead)에서 생성한 Slurm 실행 역할에 `AmazonSagemakerExecutionPolicy` 정책을 연결합니다.
```
aws --region us-east-1 iam attach-role-policy \
--role-name AmazonSagemakerExecutionRole \
--policy-arn arn:aws:iam::111122223333:policy/AmazonSagemakerExecutionPolicy
```
이 명령은 출력을 생성하지 않습니다.
(선택 사항) 환경 변수를 사용하는 경우 다음은 예시 명령입니다.
+ 역할 이름 및 정책 이름을 가져오는 방법
```
POLICY=$(aws --region $REGION iam list-policies --query 'Policies[?PolicyName==AmazonSagemakerExecutionPolicy].Arn' --output text)
ROLENAME=$(aws --region $REGION iam list-roles --query "Roles[?Arn=='${SLURM_EXECUTION_ROLE_ARN}'].RoleName" —output text)
```
+ 정책 연결
```
aws --region us-east-1 iam attach-role-policy \
--role-name $ROLENAME --policy-arn $POLICY
```
자세한 내용은 [SageMaker HyperPod의 IAM 역할](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod) 단원을 참조하십시오.
# 수명 주기 스크립트 준비 및 업로드
필요한 리소스를 모두 생성한 후에는 SageMaker HyperPod 클러스터에 대한 [수명 주기 스크립트](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts)를 설정해야 합니다. 이러한 [수명 주기 스크립트](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts)는 기본 HyperPod Slurm 클러스터를 생성하는 데 사용할 수 있는 [기본 구성](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)을 제공합니다.
## 수명 주기 스크립트 준비
다음 단계를 따라 수명 주기 스크립트를 가져오세요.
1. GitHub 리포지토리에서 [lifecycle scripts](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts)를 머신으로 다운로드합니다.
1. [cp](https://docs.aws.amazon.com//cli/latest/reference/s3/cp.html) CLI 명령을 사용하여 [기본 리소스 프로비저닝](sagemaker-hyperpod-multihead-slurm-cfn.md#sagemaker-hyperpod-multihead-slurm-cfn-basic)에서 생성한 Amazon S3 버킷에 [수명 주기 스크립트](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts)를 업로드합니다.
```
aws s3 cp --recursive LifeCycleScripts/base-config s3://${ROOT_BUCKET_NAME}/LifeCycleScripts/base-config
```
## 구성 파일 생성
다음 단계에 따라 구성 파일을 생성하고 수명 주기 스크립트를 저장하는 곳과 동일한 Amazon S3 버킷에 업로드합니다.
1. 다음 구성이 포함된 `provisioning_parameters.json`이라는 구성 파일을 생성합니다. `slurm_sns_arn`은 선택 사항입니다. 제공되지 않으면 HyperPod는 Amazon SNS 알림을 설정하지 않습니다.
```
cat < /tmp/provisioning_parameters.json
{
"version": "1.0.0",
"workload_manager": "slurm",
"controller_group": "$CONTOLLER_IG_NAME",
"login_group": "my-login-group",
"worker_groups": [
{
"instance_group_name": "$COMPUTE_IG_NAME",
"partition_name": "dev"
}
],
"fsx_dns_name": "$SLURM_FSX_DNS_NAME",
"fsx_mountname": "$SLURM_FSX_MOUNT_NAME",
"slurm_configurations": {
"slurm_database_secret_arn": "$SLURM_DB_SECRET_ARN",
"slurm_database_endpoint": "$SLURM_DB_ENDPOINT_ADDRESS",
"slurm_shared_directory": "/fsx",
"slurm_database_user": "$DB_USER_NAME",
"slurm_sns_arn": "$SLURM_SNS_FAILOVER_TOPIC_ARN"
}
}
EOF
```
1. 수명 주기 스크립트를 저장하는 곳과 동일한 Amazon S3 버킷에 `provisioning_parameters.json` 파일을 업로드합니다.
```
aws s3 cp /tmp/provisioning_parameters.json s3://${ROOT_BUCKET_NAME}/LifeCycleScripts/base-config/provisioning_parameters.json
```
**참고**
API 기반 구성을 사용하는 경우 `provisioning_parameters.json` 파일이 필요하지 않습니다. API 기반 구성을 사용하면 CreateCluster API 페이로드에서 직접 Slurm 노드 유형, 파티션 및 FSx 탑재를 정의할 수 있습니다. 자세한 내용은 [를 사용하여 SageMaker HyperPod 시작하기를 참조하세요 AWS CLI](smcluster-getting-started-slurm-cli.md).
## Amazon S3 버킷의 파일 확인
모든 수명 주기 스크립트와 `provisioning_parameters.json` 파일을 업로드하고 나면 Amazon S3 버킷은 다음과 유사해집니다.
![\[Amazon Simple Storage Service 콘솔에서 Amazon S3 버킷에 업로드된 모든 수명 주기 스크립트를 보여주는 이미지입니다.\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-scripts-s3.png)
자세한 내용은 [Start with base lifecycle scripts provided by HyperPod](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.html)를 참조하세요.
# SageMaker HyperPod 클러스터 생성
필요한 모든 리소스를 설정하고 스크립트를 Amazon S3 버킷에 업로드한 후 클러스터를 생성할 수 있습니다.
1. 클러스터를 생성하려면 [https://docs.aws.amazon.com//cli/latest/reference/sagemaker/create-cluster.html](https://docs.aws.amazon.com//cli/latest/reference/sagemaker/create-cluster.html) AWS CLI 명령을 실행합니다. 이 생성 프로세스가 완료되는 데 최대 15분이 걸릴 수 있습니다.
```
aws --region $REGION sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--vpc-config '{
"SecurityGroupIds":["'$SECURITY_GROUP'"],
"Subnets":["'$PRIMARY_SUBNET'", "'$BACKUP_SUBNET'"]
}' \
--instance-groups '[{
"InstanceGroupName": "'$CONTOLLER_IG_NAME'",
"InstanceType": "ml.t3.medium",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$SLURM_EXECUTION_ROLE_ARN'",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "'$COMPUTE_IG_NAME'",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$COMPUTE_NODE_ROLE'",
"ThreadsPerCore": 1
}]'
```
실행에 성공하면 명령은 다음과 같이 클러스터 ARN을 반환합니다.
```
{
"ClusterArn": "arn:aws:sagemaker:us-east-1:111122223333:cluster/cluster_id"
}
```
1. (선택 사항) 클러스터의 상태를 확인하려면 SageMaker AI 콘솔([https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/))을 사용할 수 있습니다. 왼쪽 탐색 창에서 **HyperPod 클러스터**를 선택한 다음 **클러스터 관리**를 선택합니다. 클러스터 이름을 선택하여 클러스터 세부 정보 페이지를 엽니다. 클러스터가 성공적으로 생성되면 클러스터 상태가 **InService**로 표시됩니다.
![\[Amazon SageMaker AI 콘솔에 여러 컨트롤러 노드가 있는 HyperPod Slurm 클러스터를 보여주는 이미지입니다.\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-multihead-cluster.png)
# 중요 참고 사항 고려
이 섹션에서는 도움이 될 수 있는 몇 가지 중요한 정보를 제공합니다.
1. 다중 컨트롤러 Slurm 클러스터로 마이그레이션하려면 다음 단계를 완료하세요.
1. [CloudFormation 스택을 사용하여 리소스 프로비저닝](sagemaker-hyperpod-multihead-slurm-cfn.md)의 지침에 따라 필요한 모든 리소스를 프로비저닝합니다.
1. [수명 주기 스크립트 준비 및 업로드](sagemaker-hyperpod-multihead-slurm-scripts.md)의 지침에 따라 업데이트된 수명 주기 스크립트를 업로드합니다. `provisioning_parameters.json` 파일을 업데이트할 때 기존 컨트롤러 그룹을 `worker_groups` 섹션으로 이동하고 `controller_group` 섹션에 새 컨트롤러 그룹 이름을 추가합니다.
1. [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) API 직접 호출을 실행하여 새 컨트롤러 그룹을 생성하고 원래 컴퓨팅 인스턴스 그룹과 컨트롤러 그룹을 유지합니다.
1. 컨트롤러 노드 수를 스케일 다운하려면 [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) CLI 명령을 사용합니다. 각 컨트롤러 인스턴스 그룹에 대해 최소 1개의 컨트롤러 노드까지 스케일 다운할 수 있습니다. 즉, 컨트롤러 노드 수를 0으로 스케일 다운할 수 없습니다.
**중요**
2025년 1월 24일 이전에 생성된 클러스터의 경우 [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/update-cluster.html) CLI 명령을 실행하기 전에 먼저 [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) API를 사용하여 클러스터 소프트웨어를 업데이트해야 합니다.
다음은 컨트롤러 노드 수를 스케일 다운하는 CLI 명령의 예입니다.
```
aws sagemaker update-cluster \
--cluster-name my_cluster \
--instance-groups '[{
"InstanceGroupName": "controller_ig_name",
"InstanceType": "ml.t3.medium",
"InstanceCount": 3,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket1",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "slurm_execution_role_arn",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "compute-ig_name",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 2,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket1",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "compute_node_role_arn",
"ThreadsPerCore": 1
}]'
```
1. 컨트롤러 노드를 일괄 삭제하려면 [batch-delete-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/batch-delete-cluster-nodes.html) CLI 명령을 사용합니다. 각 컨트롤러 인스턴스 그룹에 대해 하나 이상의 컨트롤러 노드를 유지해야 합니다. 모든 컨트롤러 노드를 일괄 삭제하려는 경우 API 작업이 작동하지 않습니다.
**중요**
2025년 1월 24일 이전에 생성된 클러스터의 경우 [batch-delete-cluster-nodes](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/batch-delete-cluster-nodes.html) CLI 명령을 실행하기 전에 먼저 [UpdateClusterSoftware](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateClusterSoftware.html) API를 사용하여 클러스터 소프트웨어를 업데이트해야 합니다.
다음은 컨트롤러 노드를 일괄 삭제하는 CLI 명령의 예입니다.
```
aws sagemaker batch-delete-cluster-nodes --cluster-name my_cluster --node-ids instance_ids_to_delete
```
1. 클러스터 생성 문제를 해결하려면 SageMaker AI 콘솔의 클러스터 세부 정보 페이지에서 실패 메시지를 확인하세요. CloudWatch 로그를 사용하여 클러스터 생성 문제를 해결할 수도 있습니다. CloudWatch 콘솔에서 **로그 그룹**을 선택합니다. 그런 다음, `clusters`를 검색하여 클러스터 생성과 관련된 로그 그룹 목록을 확인합니다.
![\[CloudWatch 콘솔의 Amazon SageMaker HyperPod 클러스터 로그 그룹을 보여주는 이미지입니다.\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod/hyperpod-lifecycle-multihead-logs.png)
# 환경 변수 참조 검토
다음 환경 변수는 [SageMaker HyperPod Slurm 클러스터에 대해 다중 컨트롤러 노드 설정](sagemaker-hyperpod-multihead-slurm-setup.md)의 자습서에서 정의되고 사용됩니다. 이러한 환경 변수는 명시적으로 보존되지 않는 한 현재 세션에서만 사용할 수 있습니다. `$variable_name` 구문을 사용하여 정의됩니다. 키/값 페어가 있는 변수는 AWS생성된 리소스를 나타내고 키가 없는 변수는 사용자 정의입니다.
**환경 변수 참조**
| 변수 | 설명 |
| --- | --- |
| \$1BACKUP\$1SUBNET | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1COMPUTE\$1IG\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1COMPUTE\$1NODE\$1ROLE | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1CONTOLLER\$1IG\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1DB\$1USER\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1EMAIL | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1PRIMARY\$1SUBNET | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1POLICY | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1REGION | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1ROOT\$1BUCKET\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SECURITY\$1GROUP | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1DB\$1ENDPOINT\$1ADDRESS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1DB\$1SECRET\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1EXECUTION\$1ROLE\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1FSX\$1DNS\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1FSX\$1MOUNT\$1NAME | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
| \$1SLURM\$1SNS\$1FAILOVER\$1TOPIC\$1ARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/sagemaker-hyperpod-multihead-slurm-variables-reference.html) |
# SageMaker HyperPod 클러스터의 작업
다음 주제에서는 컴퓨팅 노드에 액세스하고 프로비저닝된 SageMaker HyperPod 클러스터에서 ML 워크로드를 실행하는 절차와 예제를 제공합니다. HyperPod 클러스터에서 환경을 설정한 방식에 따라 HyperPod 클러스터에서 ML 워크로드를 실행하는 방법은 다양합니다. HyperPod 클러스터에서 ML 워크로드를 실행하는 예제는 [Awsome Distributed Training GitHub 리포지토리](https://github.com/aws-samples/awsome-distributed-training/)에서도 제공됩니다. 다음 주제에서는 프로비저닝된 HyperPod 클러스터에 로그인하고 샘플 ML 워크로드 실행을 시작하는 방법을 안내합니다.
**작은 정보**
실제 예제 및 솔루션을 찾으려면 [SageMaker HyperPod 워크숍](https://catalog.workshops.aws/sagemaker-hyperpod)을 참조하세요.
**Topics**
+ [
# SageMaker HyperPod 클러스터 노드에 액세스
](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md)
+ [
# SageMaker HyperPod 클러스터에서 Slurm 작업 예약
](sagemaker-hyperpod-run-jobs-slurm-schedule-slurm-job.md)
+ [
# HyperPod의 Slurm 컴퓨팅 노드에서 Docker 컨테이너 실행
](sagemaker-hyperpod-run-jobs-slurm-docker.md)
+ [
# HyperPod에서 Slurm을 사용하여 분산 훈련 워크로드 실행
](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)
# SageMaker HyperPod 클러스터 노드에 액세스
형식의 SageMaker HyperPod 클러스터 호스트 이름으로 AWS CLI 명령을 실행하여 AWS Systems Manager (SSM)`aws ssm start-session`을 통해 **InService** 클러스터에 액세스할 수 있습니다`sagemaker-cluster:[cluster-id]_[instance-group-name]-[instance-id]`. [SageMaker HyperPod 콘솔](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-view-details-of-clusters)에서 클러스터 ID, 인스턴스 ID 및 인스턴스 그룹 이름을 검색하거나 [AWS CLI SageMaker HyperPod](sagemaker-hyperpod-operate-slurm-cli-command.md#sagemaker-hyperpod-operate-slurm-cli-command-list-cluster-nodes)의 명령에서 `describe-cluster` 및 `list-cluster-nodes`을 실행하여 검색할 수 있습니다. 예를 들어 클러스터 ID가 `aa11bbbbb222`이고 클러스터 노드 이름이 이고 `controller-group`클러스터 노드 ID가 `i-111222333444555aa`인 경우SSM `start-session` 명령은 다음과 같아야 합니다.
**참고**
사용자에게 HyperPod 클러스터 노드에 대한 액세스 권한을 부여하면 사용자가 노드에 사용자 관리형 소프트웨어를 설치하고 작동할 수 있습니다. 사용자에 대해 최소 권한 원칙을 유지해야 합니다.
를 설정하지 않은 경우에 제공된 지침을 AWS Systems Manager따릅니다[클러스터 사용자 액세스 제어를 위한 설정 AWS Systems Manager 및 Run As](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm).
```
$ aws ssm start-session \
--target sagemaker-cluster:aa11bbbbb222_controller-group-i-111222333444555aa \
--region us-west-2
Starting session with SessionId: s0011223344aabbccdd
root@ip-111-22-333-444:/usr/bin#
```
참고로 처음에는 루트 사용자로 연결됩니다. 작업을 실행하기 전에 다음 명령을 실행하여 `ubuntu` 사용자로 전환합니다.
```
root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
HyperPod 클러스터의 실제 사용을 위한 고급 설정은 다음 주제를 참조하세요.
**Topics**
+ [
## SageMaker HyperPod 클러스터 노드에 액세스하기 위한 추가 팁
](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-tips)
+ [
## Amazon FSx 공유 공간을 통해 다중 사용자 환경 설정
](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-fxs-shared-space)
+ [
## HyperPod 클러스터를 Active Directory와 통합하여 다중 사용자 환경 설정
](#sagemaker-hyperpod-run-jobs-slurm-access-nodes-multi-user-with-active-directory)
## SageMaker HyperPod 클러스터 노드에 액세스하기 위한 추가 팁
**HyperPod에서 제공하는 `easy-ssh.sh` 스크립트를 사용하여 연결 프로세스 간소화**
이전 프로세스를 단일 라인 명령으로 만들기 위해 HyperPod 팀은 클러스터 정보를 검색하고, 이를 SSM 명령으로 집계하고, 컴퓨팅 노드에 연결하는 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh) 스크립트를 제공합니다. 이 스크립트는 `describe-cluster` 및 `list-cluster-nodes` 명령을 실행하고 SSM 명령을 완료하는 데 필요한 정보를 구문 분석하므로 필요한 HyperPod 클러스터 정보를 수동으로 찾을 필요가 없습니다. 다음 예제에서는 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/easy-ssh.sh) 스크립트를 사용하는 방법을 명령합니다. 성공적으로 실행되면 클러스터에 루트 사용자로 연결됩니다. 또한 코드 조각을 인쇄하여 SSM 프록시를 통해 HyperPod 클러스터를 원격 호스트로 추가하여 SSH를 설정합니다. SSH를 설정하면 Visual Studio Code와 같은 로컬 개발 환경을 HyperPod 클러스터와 연결할 수 있습니다.
```
$ chmod +x easy-ssh.sh
$ ./easy-ssh.sh -c
Cluster id:
Instance id:
Node Group:
Add the following to your ~/.ssh/config to easily connect:
$ cat <> ~/.ssh/config
Host
User ubuntu
ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
EOF
Add your ssh keypair and then you can do:
$ ssh
aws ssm start-session --target sagemaker-cluster:_-
Starting session with SessionId: s0011223344aabbccdd
root@ip-111-22-333-444:/usr/bin#
```
참고로 처음에는 루트 사용자로 연결됩니다. 작업을 실행하기 전에 다음 명령을 실행하여 `ubuntu` 사용자로 전환합니다.
```
root@ip-111-22-333-444:/usr/bin# sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
**HyperPod 컴퓨팅 노드를 원격 호스트로 사용하여 SSH에 쉽게 액세스할 수 있도록 설정**
로컬 시스템의 SSH를 사용하여 컴퓨팅 노드에 대한 액세스를 더욱 단순화하기 위해 `easy-ssh.sh` 스크립트는 이전 섹션과 같이 HyperPod 클러스터를 원격 호스트로 설정하는 코드 조각을 출력합니다. 코드 조각은 자동으로 생성되므로 로컬 디바이스의 `~/.ssh/config` 파일에 직접 추가할 수 있습니다. 다음 절차에서는 SSM 프록시를 통해 SSH를 사용하여 쉽게 액세스할 수 있도록 를 설정하여 사용자 또는 클러스터 사용자가 직접 를 실행`ssh `하여 HyperPod 클러스터 노드에 연결할 수 있도록 하는 방법을 보여줍니다.
1. 로컬 장치에서 사용자 이름이 원격 호스트인 HyperPod 컴퓨팅 노드를 `~/.ssh/config` 파일에 추가합니다. 다음 명령은 `easy-ssh.sh` 스크립트에서 자동으로 생성된 코드 조각을 `~/.ssh/config` 파일에 추가하는 방법을 보여줍니다. 올바른 클러스터 정보가 있는 `easy-ssh.sh` 스크립트의 자동 생성 출력에서 복사해야 합니다.
```
$ cat <> ~/.ssh/config
Host
User ubuntu
ProxyCommand sh -c "aws ssm start-session --target sagemaker-cluster:_- --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
EOF
```
1. HyperPod 클러스터 노드에서 로컬 디바이스의 퍼블릭 키를 HyperPod 클러스터 노드의 `~/.ssh/authorized_keys` 파일에 추가합니다.
1. 로컬 시스템에서 퍼블릭 키 파일을 인쇄합니다.
```
$ cat ~/.ssh/id_rsa.pub
```
이렇게 하면 키가 반환됩니다. 이 명령의 출력을 복사합니다.
(선택 사항) 퍼블릭 키가 없는 경우 다음 명령을 실행하여 퍼블릭 키를 생성합니다.
```
$ ssh-keygen -t rsa -q -f "$HOME/.ssh/id_rsa" -N ""
```
1. 클러스터 노드에 연결하고 사용자로 전환하여 키를 추가합니다. 다음 명령은 `ubuntu` 사용자로 액세스하는 예제입니다. SSH를 사용하여 쉽게 액세스할 수 있도록 설정할 사용자 이름으로 `ubuntu`를 바꿉니다.
```
$ ./easy-ssh.sh -c
$ sudo su - ubuntu
ubuntu@ip-111-22-333-444:/usr/bin#
```
1. `~/.ssh/authorized_keys` 파일을 열고 파일 끝에 퍼블릭 키를 추가합니다.
```
ubuntu@ip-111-22-333-444:/usr/bin# vim ~/.ssh/authorized_keys
```
설정을 완료한 후 다음과 같이 간소화된 SSH 명령을 실행하여 HyperPod 클러스터 노드에 사용자로 연결할 수 있습니다.
```
$ ssh
ubuntu@ip-111-22-333-444:/usr/bin#
```
또한 호스트를 사용하여 [Visual Studio Code Remote - SSH](https://code.visualstudio.com/docs/remote/ssh) 와 같은 로컬 디바이스의 IDE에서 원격으로 개발할 수 있습니다.
## Amazon FSx 공유 공간을 통해 다중 사용자 환경 설정
Amazon FSx 공유 공간을 사용하여 SageMaker HyperPod의 Slurm 클러스터에서 다중 사용자 환경을 관리할 수 있습니다. HyperPod 클러스터 생성 중에 Amazon FSx로 Slurm 클러스터를 구성한 경우 클러스터 사용자를 위한 워크스페이스를 설정하는 것이 좋습니다. 새 사용자를 생성하고 Amazon FSx 공유 파일 시스템에서 사용자의 홈 디렉터리를 설정합니다.
**작은 정보**
사용자가 사용자 이름과 전용 디렉터리를 통해 클러스터에 액세스할 수 있도록 하려면 AWS Systems Manager 사용 설명서의[Linux 및 macOS 관리형 노드에 대한 Run As 지원 켜기](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-run-as.html)에서 제공된 **Linux 및 macOS 관리형 노드에 대한 다음으로 실행 지원을 켜기** 절차 아래 5단계의 **옵션 2**에 안내된 대로 태그를 지정하여 IAM 역할 또는 사용자와 연결해야 합니다. 또한 [클러스터 사용자 액세스 제어를 위한 설정 AWS Systems Manager 및 Run As](sagemaker-hyperpod-prerequisites.md#sagemaker-hyperpod-prerequisites-ssm) 섹션도 참조하세요.
**SageMaker HyperPod에서 Slurm 클러스터를 생성하는 동안 다중 사용자 환경을 설정하려면**
SageMaker HyperPod 서비스 팀은 기본 수명 주기 스크립트 샘플의 일부로 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh) 스크립트를 제공합니다.
1. 다음 형식으로 생성해야 하는 `shared_users.txt`라는 텍스트 파일을 준비합니다. 첫 번째 열은 사용자 이름, 두 번째 열은 고유한 사용자 IDs 세 번째 열은 Amazon FSx 공유 공간의 사용자 디렉터리입니다.
```
username1,uid1,/fsx/username1
username2,uid2,/fsx/username2
...
```
1. HyperPod 수명 주기 스크립트용 S3 버킷에 `shared_users.txt` 및 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh) 파일을 업로드해야 합니다. 클러스터 생성, 클러스터 업데이트 또는 클러스터 소프트웨어 업데이트가 진행되는 동안 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/add_users.sh)는 `shared_users.txt`에서 읽고 사용자 디렉터리를 올바르게 설정합니다.
**새 사용자를 생성하고 SageMaker HyperPod에서 실행되는 기존 Slurm 클러스터에 추가하려면 **
1. 헤드 노드에서 다음 명령을 실행하여 사용자를 생성하는 데 도움이 되는 스크립트를 저장합니다. sudo 권한으로 이를 실행해야 합니다.
```
$ cat > create-user.sh << EOL
#!/bin/bash
set -x
# Prompt user to get the new user name.
read -p "Enter the new user name, i.e. 'sean':
" USER
# create home directory as /fsx/
# Create the new user on the head node
sudo useradd \$USER -m -d /fsx/\$USER --shell /bin/bash;
user_id=\$(id -u \$USER)
# add user to docker group
sudo usermod -aG docker \${USER}
# setup SSH Keypair
sudo -u \$USER ssh-keygen -t rsa -q -f "/fsx/\$USER/.ssh/id_rsa" -N ""
sudo -u \$USER cat /fsx/\$USER/.ssh/id_rsa.pub | sudo -u \$USER tee /fsx/\$USER/.ssh/authorized_keys
# add user to compute nodes
read -p "Number of compute nodes in your cluster, i.e. 8:
" NUM_NODES
srun -N \$NUM_NODES sudo useradd -u \$user_id \$USER -d /fsx/\$USER --shell /bin/bash;
# add them as a sudoer
read -p "Do you want this user to be a sudoer? (y/N):
" SUDO
if [ "\$SUDO" = "y" ]; then
sudo usermod -aG sudo \$USER
sudo srun -N \$NUM_NODES sudo usermod -aG sudo \$USER
echo -e "If you haven't already you'll need to run:\n\nsudo visudo /etc/sudoers\n\nChange the line:\n\n%sudo ALL=(ALL:ALL) ALL\n\nTo\n\n%sudo ALL=(ALL:ALL) NOPASSWD: ALL\n\nOn each node."
fi
EOL
```
1. 다음 명령으로 스크립트를 실행합니다. 사용자의 이름과 사용자가 액세스하도록 허용하려는 컴퓨팅 노드 수를 추가하라는 메시지가 표시됩니다.
```
$ bash create-user.sh
```
1. 다음 명령을 실행하여 사용자를 테스트할 수 있습니다.
```
$ sudo su - && ssh $(srun hostname)
```
1. `shared_users.txt` 파일에 사용자 정보를 추가하여 새 컴퓨팅 노드 또는 새 클러스터에서 사용자를 생성합니다.
## HyperPod 클러스터를 Active Directory와 통합하여 다중 사용자 환경 설정
실제 사용 사례에서 HyperPod 클러스터는 일반적으로 기계 학습(ML) 연구원, 소프트웨어 엔지니어, 데이터 과학자, 클러스터 관리자 등 여러 사용자가 사용합니다. 서로의 작업에 영향을 주지 않고 자체 파일을 편집하고 자체 작업을 실행합니다. 다중 사용자 환경을 설정하려면 Linux 사용자 및 그룹 메커니즘을 사용하여 수명 주기 스크립트를 통해 각 인스턴스에 여러 사용자를 정적으로 생성합니다. 그러나 이 접근 방식의 단점은 사용자 추가, 편집 및 제거와 같은 업데이트를 수행할 때 모든 인스턴스에서 일관된 구성을 유지하기 위해 클러스터의 여러 인스턴스에서 사용자 및 그룹 설정을 복제해야 한다는 것입니다.
이를 해결하기 위해 LDAP[(Lightweight Directory Access Protocol)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) 및 [LDAP over TLS/SSL(LDAPS)](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)을 사용하여 [AWS Microsoft Active Directory용 Directory Service 같은 디렉터리 서비스와 통합할 수 있습니다](https://aws.amazon.com/directoryservice/). HyperPod 클러스터에서 Active Directory 및 다중 사용자 환경을 설정하는 방법에 대한 자세한 내용은 [원활한 다중 사용자 로그인을 위해 HyperPod 클러스터를 Active Directory와 통합](https://aws.amazon.com/blogs/machine-learning/integrate-hyperpod-clusters-with-active-directory-for-seamless-multi-user-login/) 블로그 게시물을 참조하세요.
# SageMaker HyperPod 클러스터에서 Slurm 작업 예약
표준 Slurm `sbatch` 또는 `srun` 명령을 사용하여 훈련 작업을 시작할 수 있습니다. 예를 들어 8노드 훈련 작업을 시작하려면 `srun -N 8 --exclusive train.sh` SageMaker HyperPod를 실행하여 `conda`, `venv`, `docker`, 및 `enroot`를 포함한 다양한 환경에서 훈련을 지원할 수 있습니다. SageMaker HyperPod 클러스터에서 수명 주기 스크립트를 실행하여 ML 환경을 구성할 수 있습니다. 가상 환경으로도 사용할 수 있는 Amazon FSx와 같은 공유 파일 시스템을 연결할 수도 있습니다.
다음 예제에서는 Amazon FSx 공유 파일 시스템이 있는 SageMaker HyperPod 클러스터에서 완전 샤딩된 데이터 병렬 처리(FSDP) 기술로 Llama-2를 훈련하기 위한 작업을 실행하는 방법을 보여줍니다. [Awsome Distributed Training GitHub 리포지토리](https://github.com/aws-samples/awsome-distributed-training/) 에서 더 많은 예제를 찾을 수도 있습니다.
**작은 정보**
모든 SageMaker HyperPod 예제는 [Awsome Distributed Training GitHub 리포지토리](https://github.com/aws-samples/awsome-distributed-training/)의 `3.test_cases` 폴더에서 사용할 수 있습니다.
1. [Awsome Distributed Training GitHub 리포지토리](https://github.com/aws-samples/awsome-distributed-training/)를 복제하고 훈련 작업 예제를 Amazon FSx 파일 시스템에 복사합니다.
```
$ TRAINING_DIR=/fsx/users/my-user/fsdp
$ git clone https://github.com/aws-samples/awsome-distributed-training/
```
1. [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/10.FSDP/0.create_conda_env.sh) 스크립트 실행. 이렇게 하면 Amazon FSx 파일 시스템에 `conda` 환경이 생성됩니다. 클러스터의 모든 노드가 파일 시스템에 액세스할 수 있는지 확인합니다.
1. 다음과 같이 단일 노드 슬러밍 작업을 시작하여 가상 Conda 환경을 구축합니다.
```
$ srun -N 1 /path_to/create_conda_env.sh
```
1. 환경이 구축된 후 공유 볼륨의 환경 경로를 가리키면 훈련 작업을 시작할 수 있습니다. 동일한 설정으로 단일 노드 및 다중 노드 훈련 작업을 모두 시작할 수 있습니다. 작업을 시작하려면 다음과 같이 작업 시작 스크립트(엔트리 포인트 스크립트라고도 함)를 생성합니다.
```
#!/usr/bin/env bash
set -ex
ENV_PATH=/fsx/users/my_user/pytorch_env
TORCHRUN=$ENV_PATH/bin/torchrun
TRAINING_SCRIPT=/fsx/users/my_user/pt_train.py
WORLD_SIZE_JOB=$SLURM_NTASKS
RANK_NODE=$SLURM_NODEID
PROC_PER_NODE=8
MASTER_ADDR=(`scontrol show hostnames \$SLURM_JOB_NODELIST | head -n 1`)
MASTER_PORT=$(expr 10000 + $(echo -n $SLURM_JOBID | tail -c 4))
DIST_ARGS="--nproc_per_node=$PROC_PER_NODE \
--nnodes=$WORLD_SIZE_JOB \
--node_rank=$RANK_NODE \
--master_addr=$MASTER_ADDR \
--master_port=$MASTER_PORT \
"
$TORCHRUN $DIST_ARGS $TRAINING_SCRIPT
```
**작은 정보**
SageMaker HyperPod 의 자동 재개 기능을 사용하여 하드웨어 장애에 대한 훈련 작업을 더 탄력적으로 만들려면 진입점 스크립트에서 `MASTER_ADDR` 환경 변수를 올바르게 설정해야 합니다. 자세한 내용은 [자동 노드 복구 및 자동 재개](sagemaker-hyperpod-resiliency-slurm-auto-resume.md)를 참조하세요.
이 자습서에서는 이 스크립트가 `/fsx/users/my_user/train.sh`로 저장된다고 가정합니다.
1. `/fsx/users/my_user/train.sh`의 공유 볼륨에 이 스크립트를 사용하여 다음 `srun` 명령을 실행하여 Slurm 작업을 예약합니다.
```
$ cd /fsx/users/my_user/
$ srun -N 8 train.sh
```
# HyperPod의 Slurm 컴퓨팅 노드에서 Docker 컨테이너 실행
SageMaker HyperPod 에서 Slurm을 사용하여 Docker 컨테이너를 실행하려면 [Enroot](https://github.com/NVIDIA/enroot) 및 [Pyxis](https://github.com/NVIDIA/pyxis)를 사용해야 합니다. HyperPod Enroot 패키지는 Docker 이미지를 Slurm이 이해할 수 있는 런타임으로 변환하는 데 도움이 되는 반면, Pyxis는 `srun` 명령안 `srun --container-image=docker/image:tag`을 통해 런타임을 Slurm 작업으로 예약할 수 있도록 합니다.
**작은 정보**
Docker, Enroot 및 Pyxis 패키지는 [HyperPod에서 제공하는 기본 수명 주기 스크립트](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)에 설명된 대로 수명 주기 스크립트 실행의 일환으로 클러스터 생성 중에 설치해야 합니다. HyperPod 클러스터를 생성할 때 HyperPod 서비스 팀이 제공하는 [기본 수명 주기 스크립트](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)를 사용합니다. 이러한 기본 스크립트는 기본적으로 패키지를 설치하도록 설정되어 있습니다. [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) 스크립트에는 패키지를 설치하기 위한 부울 유형 파라미터가 `True`(`enable_docker_enroot_pyxis=True`)로 설정된 `Config` 클래스가 있습니다. 이는 [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils) 폴더에서 `install_docker.sh` 및 `install_enroot_pyxis.sh` 스크립트를 호출하는 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py) 스크립트에서 호출되고 구문 분석됩니다. 설치 스크립트는 패키지의 실제 설치가 이루어지는 곳입니다. 또한 설치 스크립트는 실행 중인 인스턴스에서 NVMe 스토어 경로를 감지하고 Docker 및 Enroot의 루트 경로를 `/opt/dlami/nvme`로 설정할 수 있는지 여부를 식별합니다. 새 인스턴스의 기본 루트 볼륨은 100GB EBS 볼륨으로만 `/tmp`에 탑재되며, 실행하려는 워크로드에 LLM 훈련이 포함되고 따라서 크기가 큰 Docker 컨테이너가 필요한 경우 이 볼륨은 사라집니다. 로컬 NVMe 스토리지에 P 및 G와 같은 인스턴스 패밀리를 사용하는 경우 `/opt/dlami/nvme`에 연결된 NVMe 스토리지를 사용해야 하며 설치 스크립트가 구성 프로세스를 처리해야 합니다.
**루트 경로가 제대로 설정되었는지 확인하려면**
SageMaker HyperPod의 Slurm 클러스터 컴퓨팅 노드에서 다음 명령을 실행하여 수명 주기 스크립트가 제대로 작동하고 각 노드의 루트 볼륨이 `/opt/dlami/nvme/*`로 설정되어 있는지 확인합니다. 다음 명령은 Slurm 클러스터의 컴퓨팅 노드 8개에 대한 Enroot 런타임 경로 및 데이터 루트 경로를 확인하는 예를 보여줍니다.
```
$ srun -N 8 cat /etc/enroot/enroot.conf | grep "ENROOT_RUNTIME_PATH"
ENROOT_RUNTIME_PATH /opt/dlami/nvme/tmp/enroot/user-$(id -u)
... // The same or similar lines repeat 7 times
```
```
$ srun -N 8 cat /etc/docker/daemon.json
{
"data-root": "/opt/dlami/nvme/docker/data-root"
}
... // The same or similar lines repeat 7 times
```
런타임 경로가 `/opt/dlami/nvme/*`로 올바르게 설정되었는지 확인한 후 Enroot 및 Pyxis를 사용하여 Docker 컨테이너를 빌드하고 실행할 준비가되었습니다.
**Slurm을 사용하여 Docker를 테스트하려면**
1. 컴퓨팅 노드에서 다음 명령을 시도하여 Docker 및 Enroot가 제대로 설치되었는지 확인합니다.
```
$ docker --help
$ enroot --help
```
1. [NVIDIA CUDA Ubuntu](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda) 이미지 중 하나를 실행하여 Pyxis 및 Enroot가 올바르게 설치되었는지 테스트합니다.
```
$ srun --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY nvidia-smi
pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
DAY MMM DD HH:MM:SS YYYY
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 |
| N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
```
스크립트를 생성하고 다음과 같이 `sbatch` 명령을 실행하여 테스트할 수도 있습니다.
```
$ cat <> container-test.sh
#!/bin/bash
#SBATCH --container-image=nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
nvidia-smi
EOF
$ sbatch container-test.sh
pyxis: importing docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
pyxis: imported docker image: nvidia/cuda:XX.Y.Z-base-ubuntuXX.YY
DAY MMM DD HH:MM:SS YYYY
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.141.03 Driver Version: 470.141.03 CUDA Version: XX.YY |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 |
| N/A 40C P0 27W / 70W | 0MiB / 15109MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=============================================================================|
| No running processes found |
+-----------------------------------------------------------------------------+
```
**Docker를 사용하여 테스트 Slurm 작업을 실행하려면**
Docker를 사용하여 Slurm 설정을 완료한 후 사전 구축된 Docker 이미지를 가져오고 SageMaker HyperPod에서 Slurm을 사용하여 실행할 수 있습니다. 다음은 SageMaker HyperPod에서 Docker 및 Slurm을 사용하여 훈련 작업을 실행하는 방법을 안내하는 샘플 사용 사례입니다. SageMaker AI 모델 병렬화(SMP) 라이브러리를 사용한 Llama 2 모델의 모델 병렬 훈련 예시를 보여줍니다.
1. SageMaker AI 또는 DLC에서 배포한 사전 구축된 ECR 이미지 중 하나를 사용하려면 HyperPod 클러스터에 [SageMaker HyperPod의 IAM 역할](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod)를 통해 ECR 이미지를 가져올 수 있는 권한을 부여해야 합니다. 자체 또는 오픈 소스 Docker 이미지를 사용하는 경우 이 단계를 건너뛸 수 있습니다. [SageMaker HyperPod의 IAM 역할](sagemaker-hyperpod-prerequisites-iam.md#sagemaker-hyperpod-prerequisites-iam-role-for-hyperpod)에 다음 권한을 추가합니다. 이 자습서에서는 [SMP 라이브러리와 함께 사전 패키징된 SMP Docker 이미지](distributed-model-parallel-support-v2.md#distributed-model-parallel-supported-frameworks-v2)를 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr-public:*",
"ecr:GetDownloadUrlForLayer",
"ecr:GetAuthorizationToken",
"sts:*"
],
"Resource": "*"
}
]
}
```
------
1. 컴퓨팅 노드에서 리포지토리를 복제하고 SMP를 사용한 훈련의 예제 스크립트를 제공하는 폴더로 이동합니다.
```
$ git clone https://github.com/aws-samples/awsome-distributed-training/
$ cd awsome-distributed-training/3.test_cases/17.SM-modelparallelv2
```
1. 이 자습서에서는 SMP Docker 이미지를 가져와서 Docker 컨테이너를 빌드하고 Enroot 런타임으로 [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/docker_build.sh) 실행하는 샘플 스크립트를 실행합니다. 원하는 대로 수정할 수 있습니다.
```
$ cat docker_build.sh
#!/usr/bin/env bash
region=us-west-2
dlc_account_id=658645717510
aws ecr get-login-password --region $region | docker login --username AWS --password-stdin $dlc_account_id.dkr.ecr.$region.amazonaws.com
docker build -t smpv2 .
enroot import -o smpv2.sqsh dockerd://smpv2:latest
```
```
$ bash docker_build.sh
```
1. 배치 스크립트를 생성하여 `sbatch`를 사용하여 훈련 작업을 시작합니다. 이 자습서에서 제공된 샘플 스크립트 [https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh](https://github.com/aws-samples/awsome-distributed-training/blob/main/3.test_cases/17.SM-modelparallelv2/launch_training_enroot.sh)는 8개의 컴퓨팅 노드에 합성 데이터세트가 있는 700억 파라미터 Llama 2 모델의 모델 병렬 훈련 작업을 시작합니다. 훈련 스크립트 세트는 [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2/scripts)에 제공되며 `launch_training_enroot.sh`는 진입점 스크립트로 `train_external.py`를 사용합니다.
**중요**
SageMaker HyperPod에서 Docker 컨테이너를 사용하려면 이 경우 HyperPod 컴퓨팅 노드인 호스트 시스템의 `/var/log` 디렉터리를 컨테이너의 `/var/log` 디렉터리에 탑재해야 합니다. Enroot에 다음 변수를 추가하여 설정할 수 있습니다.
```
"${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}"
```
```
$ cat launch_training_enroot.sh
#!/bin/bash
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0
#SBATCH --nodes=8 # number of nodes to use, 2 p4d(e) = 16 A100 GPUs
#SBATCH --job-name=smpv2_llama # name of your job
#SBATCH --exclusive # job has exclusive use of the resource, no sharing
#SBATCH --wait-all-nodes=1
set -ex;
###########################
###### User Variables #####
###########################
#########################
model_type=llama_v2
model_size=70b
# Toggle this to use synthetic data
use_synthetic_data=1
# To run training on your own data set Training/Test Data path -> Change this to the tokenized dataset path in Fsx. Acceptable formats are huggingface (arrow) and Jsonlines.
# Also change the use_synthetic_data to 0
export TRAINING_DIR=/fsx/path_to_data
export TEST_DIR=/fsx/path_to_data
export CHECKPOINT_DIR=$(pwd)/checkpoints
# Variables for Enroot
: "${IMAGE:=$(pwd)/smpv2.sqsh}"
: "${HYPERPOD_PATH:="/var/log/aws/clusters":"/var/log/aws/clusters"}" # This is needed for validating its hyperpod cluster
: "${TRAIN_DATA_PATH:=$TRAINING_DIR:$TRAINING_DIR}"
: "${TEST_DATA_PATH:=$TEST_DIR:$TEST_DIR}"
: "${CHECKPOINT_PATH:=$CHECKPOINT_DIR:$CHECKPOINT_DIR}"
###########################
## Environment Variables ##
###########################
#export NCCL_SOCKET_IFNAME=en
export NCCL_ASYNC_ERROR_HANDLING=1
export NCCL_PROTO="simple"
export NCCL_SOCKET_IFNAME="^lo,docker"
export RDMAV_FORK_SAFE=1
export FI_EFA_USE_DEVICE_RDMA=1
export NCCL_DEBUG_SUBSYS=off
export NCCL_DEBUG="INFO"
export SM_NUM_GPUS=8
export GPU_NUM_DEVICES=8
export FI_EFA_SET_CUDA_SYNC_MEMOPS=0
# async runtime error ...
export CUDA_DEVICE_MAX_CONNECTIONS=1
#########################
## Command and Options ##
#########################
if [ "$model_size" == "7b" ]; then
HIDDEN_WIDTH=4096
NUM_LAYERS=32
NUM_HEADS=32
LLAMA_INTERMEDIATE_SIZE=11008
DEFAULT_SHARD_DEGREE=8
# More Llama model size options
elif [ "$model_size" == "70b" ]; then
HIDDEN_WIDTH=8192
NUM_LAYERS=80
NUM_HEADS=64
LLAMA_INTERMEDIATE_SIZE=28672
# Reduce for better perf on p4de
DEFAULT_SHARD_DEGREE=64
fi
if [ -z "$shard_degree" ]; then
SHARD_DEGREE=$DEFAULT_SHARD_DEGREE
else
SHARD_DEGREE=$shard_degree
fi
if [ -z "$LLAMA_INTERMEDIATE_SIZE" ]; then
LLAMA_ARGS=""
else
LLAMA_ARGS="--llama_intermediate_size $LLAMA_INTERMEDIATE_SIZE "
fi
if [ $use_synthetic_data == 1 ]; then
echo "using synthetic data"
declare -a ARGS=(
--container-image $IMAGE
--container-mounts $HYPERPOD_PATH,$CHECKPOINT_PATH
)
else
echo "using real data...."
declare -a ARGS=(
--container-image $IMAGE
--container-mounts $HYPERPOD_PATH,$TRAIN_DATA_PATH,$TEST_DATA_PATH,$CHECKPOINT_PATH
)
fi
declare -a TORCHRUN_ARGS=(
# change this to match the number of gpus per node:
--nproc_per_node=8 \
--nnodes=$SLURM_JOB_NUM_NODES \
--rdzv_id=$SLURM_JOB_ID \
--rdzv_backend=c10d \
--rdzv_endpoint=$(hostname) \
)
srun -l "${ARGS[@]}" torchrun "${TORCHRUN_ARGS[@]}" /path_to/train_external.py \
--train_batch_size 4 \
--max_steps 100 \
--hidden_width $HIDDEN_WIDTH \
--num_layers $NUM_LAYERS \
--num_heads $NUM_HEADS \
${LLAMA_ARGS} \
--shard_degree $SHARD_DEGREE \
--model_type $model_type \
--profile_nsys 1 \
--use_smp_implementation 1 \
--max_context_width 4096 \
--tensor_parallel_degree 1 \
--use_synthetic_data $use_synthetic_data \
--training_dir $TRAINING_DIR \
--test_dir $TEST_DIR \
--dataset_type hf \
--checkpoint_dir $CHECKPOINT_DIR \
--checkpoint_freq 100 \
$ sbatch launch_training_enroot.sh
```
다운로드 가능한 코드 예시를 찾으려면 *Awsome Distributed Training GitHub 리포지토리*의 [Run a model-parallel training job using the SageMaker AI model parallelism library, Docker and Enroot with Slurm](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2#option-2----run-training-using-docker-and-enroot)을 참조하세요. SageMaker HyperPod에서 Slurm 클러스터를 사용한 분산 훈련에 대한 자세한 내용은 [HyperPod에서 Slurm을 사용하여 분산 훈련 워크로드 실행](sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload.md)의 다음 주제로 진행하세요.
# HyperPod에서 Slurm을 사용하여 분산 훈련 워크로드 실행
SageMaker HyperPod는 대규모 언어 모델(LLM) 및 파운데이션 모델(FM) 훈련의 워크로드에 특화되었습니다. 이러한 워크로드에는 여러 병렬 처리 기법을 사용하고 ML 인프라 및 리소스에 최적화된 작업이 필요한 경우가 많습니다. SageMaker HyperPod를 사용하면 다음과 같은 SageMaker AI 분산 훈련 프레임워크를 사용할 수 있습니다.
+ AWS에 최적화된 집합 통신 작업을 제공하는 [SageMaker AI distributed data parallelism (SMDDP) library](data-parallel.md)입니다.
+ 다양한 모델 병렬화 기법을 구현하는 [SageMaker AI model parallelism (SMP) library](model-parallel-v2.md)입니다.
**Topics**
+ [
## SageMaker HyperPod에서 SMDDP 사용
](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smddp)
+ [
## SageMaker HyperPod 클러스터에서 SMP 사용
](#sagemaker-hyperpod-run-jobs-slurm-distributed-training-workload-smp)
## SageMaker HyperPod에서 SMDDP 사용
[SMDDP 라이브러리](data-parallel.md)는 분산 데이터 병렬 훈련의 컴퓨팅 성능을 개선하는 집합 통신 라이브러리입니다. SMDDP 라이브러리는 다음과 같은 오픈 소스 분산 훈련 프레임워크에서 작동합니다.
+ [PyTorch 분산 데이터 병렬(DDP)](https://pytorch.org/docs/stable/notes/ddp.html)
+ [PyTorch 완전 샤딩 데이터 병렬 처리(FSDP)](https://pytorch.org/docs/stable/fsdp.html)
+ [DeepSpeed](https://github.com/microsoft/DeepSpeed)
+ [Megatron-DeepSpeed](https://github.com/microsoft/Megatron-DeepSpeed)
SMDDP 라이브러리는 SageMaker HyperPod에 대해 다음을 제공하여 키 집합 통신 작업의 통신 오버헤드를 해결합니다.
+ 라이브러리는에 `AllGather` 최적화되어 있습니다 AWS. `AllGather`는 샤딩된 데이터 병렬 훈련에 사용되는 키 작업으로, 인기 있는 라이브러리에서 제공하는 메모리 효율적인 데이터 병렬 처리 기법입니다. 여기에는 SageMaker AI 모델 병렬화(SMP) 라이브러리, DeepSpeed Zero Redundancy Optimizer(ZeRO) 및 PyTorch 완전 샤딩 데이터 병렬화(FSDP)가 포함됩니다.
+ 라이브러리는 AWS 네트워크 인프라와 SageMaker AI ML 인스턴스 토폴로지를 완전히 활용하여 최적화된 node-to-node 통신을 수행합니다.
**샘플 데이터 병렬 훈련 작업을 실행하려면**
SMDDP 라이브러리를 사용하여 데이터 병렬 처리 기술을 구현하는 다음 분산 훈련 샘플을 살펴보세요.
+ [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/12.SM-dataparallel-FSDP)
+ [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/13.SM-dataparallel-deepspeed)
**SageMaker HyperPod에서 SMDDP 라이브러리를 사용하기 위한 환경을 설정하려면**
다음은 SageMaker HyperPod 에서 SMDDP 라이브러리를 사용하기 위한 훈련 환경 요구 사항입니다.
+ PyTorch v2.0.1 이상
+ CUDA v11.8 이상
+ 3보다 큰 `libstdc++` 런타임 버전
+ Python v3.10.x 이상
+ SMDDP 라이브러리에서 지원하는 인스턴스 유형인 `ml.p4d.24xlarge` 및 `ml.p4de.24xlarge`
+ `imdsv2` 훈련 호스트에서 활성화됨
분산 훈련 작업을 실행하는 방법에 따라 SMDDP 라이브러리를 설치하는 두 가지 옵션이 있습니다.
+ SMDDP 바이너리 파일을 사용한 직접 설치입니다.
+ SMDDP 라이브러리와 함께 사전 설치된 SageMaker AI Deep Learning Containers(DLC) 사용.
SMDDP 라이브러리 또는 SMDDP 바이너리 파일의 URL이 사전 설치된 Docker 이미지는 SMDDP 라이브러리 설명서의 [지원되는 프레임워크](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks)에 나열되어 있습니다.
**SageMaker HyperPod DLAMI에 SMDDP 라이브러리를 설치하려면**
+ `pip install --no-cache-dir https://smdataparallel.s3.amazonaws.com/binary/pytorch//cuXYZ/YYYY-MM-DD/smdistributed_dataparallel-X.Y.Z-cp310-cp310-linux_x86_64.whl`
**참고**
Conda 환경에서 작업하는 경우 `pip` 대신 `conda install`를 사용하여 PyTorch를 설치해야 합니다.
```
conda install pytorch==X.Y.Z torchvision==X.Y.Z torchaudio==X.Y.Z pytorch-cuda=X.Y.Z -c pytorch -c nvidia
```
**Docker 컨테이너에서 SMDDP 라이브러리를 사용하려면**
+ SMDDP 라이브러리는 SageMaker AI 딥 러닝 컨테이너(DLC)에 사전 설치됩니다. SMDDP 라이브러리가 있는 PyTorch용 SageMaker AI 프레임워크 DLC 목록을 찾으려면 SMDDP 라이브러리 설명서의 [Supported Frameworks](https://docs.aws.amazon.com/sagemaker/latest/dg/distributed-data-parallel-support.html#distributed-data-parallel-supported-frameworks)를 참조하세요. SMDDP 라이브러리를 사용하기 위해 필요한 종속 항목이 설치된 자체 Docker 컨테이너를 가져올 수도 있습니다. SMDDP 라이브러리를 사용하도록 사용자 지정 Docker 컨테이너를 설정하는 방법에 대한 자세한 내용은 [SageMaker AI 분산 데이터 병렬 라이브러리로 자체 Docker 컨테이너 만들기](data-parallel-bring-your-own-container.md) 섹션도 참조하세요.
**중요**
Docker 컨테이너에서 SMDDP 라이브러리를 사용하려면 호스트 시스템의 `/var/log` 디렉터리를 컨테이너의 `/var/log`에 탑재합니다. 컨테이너를 실행할 때 다음 옵션을 추가하여 이 작업을 수행할 수 있습니다.
```
docker run -v /var/log:/var/log ...
```
일반적으로 SMDDP를 사용하여 데이터 병렬 훈련 작업을 실행하는 방법을 알아보려면 [SageMaker AI 분산형 데이터 병렬화 라이브러리를 사용한 분산 훈련](data-parallel-modify-sdp.md) 섹션을 참조하세요.
## SageMaker HyperPod 클러스터에서 SMP 사용
[SageMaker AI model parallelism (SMP) library](model-parallel-v2.md)는 다음과 같은 다양한 [최첨단 모델 병렬화 기법](model-parallel-core-features-v2.md)을 제공합니다.
+ 완전히 샤딩된 데이터 병렬 처리
+ 전문가 병렬 처리
+ FP16/BF16 및 FP8 데이터 유형을 사용한 혼합 정밀도 훈련
+ 텐서 병렬 처리
SMP 라이브러리는 PyTorch FSDP, NVIDIA Megatron 및 NVIDIA Transformer Engine과 같은 오픈 소스 프레임워크와도 호환됩니다.
**샘플 모델 병렬 훈련 워크로드를 실행하려면**
SageMaker AI 서비스 팀은 [https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2](https://github.com/aws-samples/awsome-distributed-training/tree/main/3.test_cases/17.SM-modelparallelv2)에서 SMP 라이브러리와 모델 병렬화를 구현하는 샘플 훈련 작업을 제공합니다.
# SageMaker HyperPod 클러스터 리소스 모니터링
SageMaker HyperPod 클러스터 리소스 및 소프트웨어 구성 요소를 포괄적으로 관찰하려면 클러스터를 [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html) 및 [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)와 통합합니다. Amazon Managed Service for Prometheus와의 통합을 통해 HyperPod 클러스터 리소스와 관련된 지표를 내보낼 수 있으므로 성능, 사용률 및 상태에 대한 인사이트를 얻을 수 있습니다. Amazon Managed Grafana와의 통합을 통해 클러스터의 동작을 모니터링하고 분석하기 위한 직관적인 인터페이스를 제공하는 다양한 Grafana 대시보드를 통해 이러한 지표를 시각화할 수 있습니다. 이러한 서비스를 활용하면 HyperPod 클러스터를 중앙 집중식으로 통합하여 분산 훈련 워크로드의 사전 모니터링, 문제 해결 및 최적화를 촉진할 수 있습니다.
**작은 정보**
실제 예제 및 솔루션을 찾으려면 [SageMaker HyperPod 워크숍](https://catalog.workshops.aws/sagemaker-hyperpod)도 참조하세요.
![\[Amazon Managed Service for Prometheus 및 Amazon Managed Grafana를 사용하여 SageMaker HyperPod를 구성하는 방법에 대한 개요입니다.\]](http://docs.aws.amazon.com/ko_kr/sagemaker/latest/dg/images/hyperpod-observability-architecture.png)
그림: 이 아키텍처 다이어그램은 Amazon Managed Service for Prometheus 및 Amazon Managed Grafana를 사용하여 SageMaker HyperPod를 구성하는 개요를 보여줍니다.
다음 주제로 이동하여 SageMaker HyperPod 클러스터 관찰 가능성을 설정합니다.
**Topics**
+ [
# SageMaker HyperPod 클러스터 관찰성을 위한 사전 조건
](sagemaker-hyperpod-cluster-observability-slurm-prerequisites.md)
+ [
# HyperPod 클러스터에 지표 내보내기 패키지 설치
](sagemaker-hyperpod-cluster-observability-slurm-install-exporters.md)
+ [
# HyperPod 클러스터의 헤드 노드에서 Prometheus 설정 검증
](sagemaker-hyperpod-cluster-observability-slurm-validate-prometheus-setup.md)
+ [
# Amazon Managed Grafana 작업 영역 설정
](sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws.md)
+ [
# 내보낸 메트릭 참조
](sagemaker-hyperpod-cluster-observability-slurm-exported-metrics-reference.md)
+ [
# Amazon SageMaker HyperPod Slurm 지표
](smcluster-slurm-metrics.md)
# SageMaker HyperPod 클러스터 관찰성을 위한 사전 조건
[HyperPod 클러스터에 지표 내보내기 패키지 설치](sagemaker-hyperpod-cluster-observability-slurm-install-exporters.md)에 대한 단계를 진행하기 전에 다음 사전 조건이 충족되었는지 확인합니다.
## IAM Identity Center 활성화
SageMaker HyperPod 클러스터에 대한 관찰 가능성을 활성화하려면 먼저 IAM Identity Center를 활성화해야 합니다. 이는 Amazon Managed Grafana 워크스페이스와 Amazon Managed Service for Prometheus를 설정하는 CloudFormation 스택을 배포하기 위한 사전 조건입니다. 이 두 서비스 모두 인증 및 권한 부여를 위해 IAM Identity Center가 필요하므로 모니터링 인프라의 안전한 사용자 액세스 및 관리를 보장합니다.
IAM Identity Center 활성화에 대한 자세한 지침은 *AWS IAM Identity Center 사용 설명서*의 [IAM Identity Center 활성화](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html) 섹션을 참조하세요.
IAM Identity Center를 성공적으로 활성화한 후 다음 구성 절차 전반에서 관리 사용자 역할을 할 사용자 계정을 설정합니다.
## SageMaker HyperPod 관찰성을 위한 CloudFormation 스택 생성 및 배포
SageMaker HyperPod 관찰 가능성을 위한 CloudFormation 스택을 생성하고 배포하여 Amazon Managed Service for Prometheus 및 Amazon Managed Grafana를 사용하여 실시간으로 HyperPod 클러스터 지표를 모니터링합니다. 스택을 배포하려면 [IAM Identity Center](https://console.aws.amazon.com/singlesignon)도 미리 활성화해야 합니다.
Amazon VPC 서브넷, Amazon FSx for Lustre 파일 시스템, Amazon S3 버킷 및 HyperPod 클러스터 관찰 스택을 생성하는 데 필요한 IAM 역할을 설정하는 데 도움이 되는 샘플 CloudFormation 스크립트 [https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/4.prometheus-grafana/cluster-observability.yaml](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/4.prometheus-grafana/cluster-observability.yaml)를 사용합니다.
# HyperPod 클러스터에 지표 내보내기 패키지 설치
SageMaker HyperPod 팀이 제공하는 [기본 구성 수명 주기 스크립트](sagemaker-hyperpod-lifecycle-best-practices-slurm-slurm-base-config.md)에는 다양한 지표 내보내기 패키지의 설치도 포함됩니다. 설치 단계를 활성화하려면 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) 파일에서 `enable_observability=True` 파라미터를 설정해야 합니다. 수명 주기 스크립트는 다음 오픈 소스 지표 내보내기 패키지를 사용하여 클러스터를 부트스트랩하도록 설계되었습니다.
| | | |
| --- |--- |--- |
| 이름 | 스크립트 배포 대상 노드 | 내보내기 설명 |
| [Prometheus용 Slurm 내보내기](https://github.com/vpenso/prometheus-slurm-exporter) | 헤드(컨트롤러) 노드 | Slurm 계정 지표를 내보냅니다. |
| [EFA(Elastic Fabric Adapter) 노드 내보내기](https://github.com/aws-samples/awsome-distributed-training/tree/main/4.validation_and_observability/3.efa-node-exporter) | 컴퓨팅 노드 | 클러스터 노드 및 EFA에서 지표를 내보냅니다. 패키지는 [Prometheus 노드 내보내기](https://github.com/prometheus/node_exporter) 의 포크입니다. |
| [NVIDIA Data Center GPU Management(DCGM) 내보내기](https://github.com/NVIDIA/dcgm-exporter) | 컴퓨팅 노드 | NVIDIA GPU의 상태 및 성능에 대한 NVIDIA DCGM 메트릭을 내보냅니다. |
[https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/config.py) 파일에서 `enable_observability=True`를 사용하면 [https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py](https://github.com/aws-samples/awsome-distributed-training/blob/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/lifecycle_script.py) 스크립트에서 다음 설치 단계가 활성화됩니다.
```
# Install metric exporting software and Prometheus for observability
if Config.enable_observability:
if node_type == SlurmNodeType.COMPUTE_NODE:
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()
if node_type == SlurmNodeType.HEAD_NODE:
wait_for_scontrol()
ExecuteBashScript("./utils/install_docker.sh").run()
ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
ExecuteBashScript("./utils/install_prometheus.sh").run()
```
컴퓨팅 노드에서 스크립트는 NVIDIA Data Center GPU Management(DCGM) 내보내기와 EFA(Elastic Fabric Adapter) 노드 내보내기를 설치합니다. DCGM Exporter는 NVIDIA GPU에서 지표를 수집하는 Prometheus용 Exporter로, GPU 사용량, 성능 및 상태를 모니터링할 수 있습니다. 반면 EFA 노드 내보내기는 HPC 클러스터에서 지연 시간이 짧고 고대역폭 통신에 필수적인 EFA 네트워크 인터페이스와 관련된 지표를 수집합니다.
헤드 노드에서 스크립트는 Prometheus용 Slurm 내보내기 및 [Prometheus 오픈 소스 소프트웨어](https://prometheus.io/docs/introduction/overview/)를 설치합니다. Slurm 내보내기는 Prometheus에 Slurm 작업, 파티션 및 노드 상태와 관련된 지표를 제공합니다.
수명 주기 스크립트는 모든 내보내기 패키지를 도커 컨테이너로 설치하도록 설계되었으므로 Docker 패키지도 헤드 노드와 컴퓨팅 노드 모두에 설치해야 합니다. 이러한 구성 요소에 대한 스크립트는 *Awsome Distributed Training GitHub 리포지토리*의 [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config/utils) 폴더에 편리하게 제공됩니다.
내보내기 패키지와 함께 설치된 HyperPod 클러스터를 성공적으로 설정한 후 다음 주제로 이동하여 Amazon Managed Service for Prometheus 및 Amazon Managed Grafana 설정을 완료합니다.
# HyperPod 클러스터의 헤드 노드에서 Prometheus 설정 검증
내보내기 패키지와 함께 설치된 HyperPod 클러스터를 성공적으로 설정한 후, Prometheus가 HyperPod 클러스터의 헤드 노드에 제대로 설정되어 있는지 확인합니다.
1. 클러스터의 헤드 노드에 연결합니다. 노드 액세스 방법에 대한 지침은 [SageMaker HyperPod 클러스터 노드에 액세스](sagemaker-hyperpod-run-jobs-slurm-access-nodes.md) 섹션을 참조하세요.
1. 다음 명령을 실행하여 수명 주기 스크립트 `install_prometheus.sh`에서 생성된 Prometheus 구성 및 서비스 파일이 컨트롤러 노드에서 실행되고 있는지 확인합니다. 출력은 활성 상태를 **active (running)**로 표시해야 합니다.
```
$ sudo systemctl status prometheus
• prometheus service - Prometheus Exporter
Loaded: loaded (/etc/systemd/system/prometheus.service; enabled; preset:disabled)
Active: active (running) since DAY YYYY-MM-DD HH:MM:SS UTC; Ss ago
Main PID: 12345 (prometheus)
Tasks: 7 (limit: 9281)
Memory: 35M
CPU: 234ms
CGroup: /system.slice/prometheus.service
-12345 /usr/bin/prometheus--config.file=/etc/prometheus/prometheus.yml
```
1. 다음과 같이 Prometheus 구성 파일을 검증합니다. 출력은 다음과 유사해야 하며, 3개의 내보내기가 올바른 컴퓨팅 노드 IP 주소로 구성되어 있어야 합니다.
```
$ cat /etc/prometheus/prometheus.yml
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_timeout: 15s
scrape_configs:
- job_name: 'slurm_exporter'
static_configs:
- targets:
- 'localhost:8080'
- job_name: 'dcgm_exporter'
static_configs:
- targets:
- ':9400'
- ':9400'
- job_name: 'efa_node_exporter'
static_configs:
- targets:
- ':9100'
- ':9100'
remote_write:
- url:
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500
sigv4:
region:
```
1. Prometheus가 Slurm, DCGM 및 EFA 지표를 올바르게 내보내고 있는지 테스트하려면 헤드 노드의 포트 `:9090`에서 Prometheus에 대해 다음 `curl` 명령을 실행합니다.
```
$ curl -s http://localhost:9090/metrics | grep -E 'slurm|dcgm|efa'
```
컨트롤러 노드에서 Prometheus 원격 쓰기 구성을 통해 Amazon Managed Service for Prometheus Workspace로 내보낸 지표를 사용하여 다음 주제로 이동하여 Amazon Managed Grafana 대시보드를 설정하여 지표를 표시할 수 있습니다.
# Amazon Managed Grafana 작업 영역 설정
Amazon Managed Service for Prometheus를 데이터 소스로 사용하여 새 Amazon Managed Grafana 작업 영역을 생성하거나 기존 Amazon Managed Grafana 작업 영역을 업데이트합니다.
**Topics**
+ [
## Grafana 작업 영역을 생성하고 Amazon Managed Service for Prometheus를 데이터 소스로 추가합니다.
](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-create)
+ [
## Grafana 작업 영역을 열고 데이터 소스 설정을 완료합니다.
](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-connect-data-source)
+ [
## 오픈 소스 Grafana 대시보드 가져오기
](#sagemaker-hyperpod-cluster-observability-slurm-managed-grafana-ws-import-dashboards)
## Grafana 작업 영역을 생성하고 Amazon Managed Service for Prometheus를 데이터 소스로 추가합니다.
Amazon Managed Service for Prometheus의 지표를 시각화하려면 Amazon Managed Grafana 작업 영역을 생성하고 Amazon Managed Service for Prometheus를 데이터 소스로 사용하도록 설정합니다.
1. Grafana 작업 영역을 생성하려면 *Amazon Managed Service for Prometheus 사용 설명서*에서 [작업 영역 생성](https://docs.aws.amazon.com/grafana/latest/userguide/AMG-create-workspace.html#creating-workspace)의 지침을 따르세요.
1. 13단계에서 Amazon Managed Service for Prometheus를 데이터 소스로 선택합니다.
1. 17단계에서는 관리자 사용자와 IAM Identity Center의 다른 사용자를 추가할 수 있습니다.
자세한 정보는 다음 리소스도 참조하세요.
+ *Amazon Managed Service for Prometheus 사용 설명서*에서 [Amazon Managed Service for Prometheus와 함께 사용할 Amazon Managed Grafana 설정](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-amg.html)
+ Amazon [Managed Grafana 사용 설명서의 AWS 데이터 소스 구성을 사용하여 Amazon Managed Service for Prometheus를 데이터 소스로 추가](https://docs.aws.amazon.com/grafana/latest/userguide/AMP-adding-AWS-config.html) **
## Grafana 작업 영역을 열고 데이터 소스 설정을 완료합니다.
Amazon Managed Grafana 작업 영역을 성공적으로 생성하거나 업데이트한 후 작업 영역 URL을 선택하여 작업 영역을 엽니다. 그러면 IAM Identity Center에서 설정한 사용자의 사용자 이름과 암호를 입력하라는 메시지가 표시됩니다. 관리자를 사용하여 로그인하여 작업 영역 설정을 완료해야 합니다.
1. 작업 영역 **홈** 페이지에서 **앱**, **AWS 데이터 소스** 및 **데이터 소스**를 선택합니다.
1. **데이터 소스** 페이지로 이동하여 새 **데이터 소스**를 선택합니다.
1. **서비스**에 Amazon Managed Service for Prometheus를 선택합니다.
1. **데이터 소스 찾아보기 및 프로비저닝** 섹션에서 Amazon Managed Service for Prometheus 워크스페이스를 프로비저닝한 AWS 리전을 선택합니다.
1. 선택한 리전의 데이터 소스 목록에서 Amazon Managed Service for Prometheus에 대한 소스를 선택합니다. HyperPod 관찰 스택에 대해 설정한 Amazon Managed Service for Prometheus 작업 영역의 리소스 ID와 리소스 별칭을 확인해야 합니다.
## 오픈 소스 Grafana 대시보드 가져오기
Amazon Managed Service for Prometheus를 데이터 소스로 사용하여 Amazon Managed Grafana 작업 영역을 성공적으로 설정한 후에는 Prometheus에 대한 지표 수집을 시작한 다음 차트, 정보 등을 보여주는 다양한 대시보드를 보기 시작해야 합니다. Grafana 오픈 소스 소프트웨어는 다양한 대시보드를 제공하며 Amazon Managed Grafana로 가져올 수 있습니다.
**오픈 소스 Grafana 대시보드를 Amazon Managed Grafana로 가져오려면**
1. Amazon Managed Grafana 작업 영역의 **홈** 페이지에서 **대시보드**를 선택합니다.
1. UI 텍스트 **새로 만들기**를 사용하여 드롭다운 메뉴 버튼을 선택하고 **가져오기**를 선택합니다.
1. [Slurm 대시보드](https://grafana.com/grafana/dashboards/4323-slurm-dashboard/)에 URL을 붙여넣습니다.
```
https://grafana.com/grafana/dashboards/4323-slurm-dashboard/
```
1. **로드**를 선택합니다.
1. 이전 단계를 반복하여 다음 대시보드를 가져옵니다.
1. [Node Exporter 전체 대시보드](https://grafana.com/grafana/dashboards/1860-node-exporter-full/)
```
https://grafana.com/grafana/dashboards/1860-node-exporter-full/
```
1. [NVIDIA DCGM Exporter 대시보드](https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/)
```
https://grafana.com/grafana/dashboards/12239-nvidia-dcgm-exporter-dashboard/
```
1. [EFA 지표 대시보드](https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/)
```
https://grafana.com/grafana/dashboards/20579-efa-metrics-dev/
```
1. [FSx for Lustre 지표 대시보드](https://grafana.com/grafana/dashboards/20906-fsx-lustre/)
```
https://grafana.com/grafana/dashboards/20906-fsx-lustre/
```
# 내보낸 메트릭 참조
다음 섹션에서는 SageMaker HyperPod 관찰성을 위해 CloudFormation 스택을 성공적으로 구성할 때 SageMaker HyperPod에서 Amazon Managed Service for Prometheus로 내보낸 지표의 포괄적인 목록을 제공합니다. Amazon Managed Grafana 대시보드에서 시각화된 이러한 지표 모니터링을 시작할 수 있습니다.
## Slurm 내보내기 대시보드
SageMaker HyperPod의 Slurm 클러스터에 대한 시각화된 정보를 제공합니다.
**메트릭의 유형**
+ **클러스터 개요:** 노드, 작업 및 해당 상태의 총 수를 표시합니다.
+ **작업 메트릭:** 시간 경과에 따른 작업 수 및 상태 시각화.
+ **노드 메트릭:** 노드 상태, 할당 및 사용 가능한 리소스를 표시합니다.
+ **파티션 메트릭:** CPU, 메모리 및 GPU 사용률과 같은 파티션별 지표를 모니터링합니다.
+ **작업 효율성:** 사용된 리소스를 기반으로 작업 효율성을 계산합니다.
**메트릭의 목록**
| 지표 이름 | 설명 |
| --- | --- |
| slurm\$1job\$1count | Slurm 클러스터의 총 작업 수 |
| slurm\$1job\$1state\$1count | 각 상태의 작업 수(예: 실행 중, 보류 중, 완료됨) |
| slurm\$1node\$1count | Slurm 클러스터의 노드 총 수입니다. |
| slurm\$1node\$1state\$1count | 각 상태의 노드 수(예: 유휴, 할당, 혼합) |
| slurm\$1partition\$1node\$1count | 각 파티션의 노드 수 |
| slurm\$1partition\$1job\$1count | 각 파티션의 작업 수 |
| slurm\$1partition\$1alloc\$1cpus | 각 파티션에 할당된 총 CPU 수 |
| slurm\$1partition\$1free\$1cpus | 각 파티션에서 사용 가능한 총 CPU 수 |
| slurm\$1partition\$1alloc\$1memory | 각 파티션에 할당된 총 메모리 |
| slurm\$1partition\$1free\$1memory | 각 파티션에서 사용 가능한 총 메모리 |
| slurm\$1partition\$1alloc\$1gpus | 각 파티션에 할당된 총 GPU |
| slurm\$1partition\$1free\$1gpus | 각 파티션에서 사용 가능한 총 GPU |
## 노드 내보내기 대시보드
HyperPod 클러스터 [노드에서 Prometheus 노드 내보내기](https://github.com/prometheus/node_exporter)가 수집한 시스템 지표의 시각화된 정보를 제공합니다.
**메트릭의 유형**
+ **시스템 개요:** CPU 부하 평균 및 메모리 사용량 표시.
+ **메모리 메트릭:** 총 메모리, 여유 메모리 및 스왑 공간을 포함한 메모리 사용률 시각화.
+ **디스크 사용량:** 디스크 공간 사용률 및 가용성을 모니터링합니다.
+ **네트워크 트래픽:** 시간 경과에 따라 수신 및 전송되는 네트워크 바이트를 표시합니다.
+ **파일 시스템 지표:** 파일 시스템 사용량 및 가용성 분석.
+ **디스크 I/O 지표:** 디스크 읽기 및 쓰기 활동을 시각화합니다.
**메트릭 목록**
내보낸 지표의 전체 목록은 [노드 내보내기](https://github.com/prometheus/node_exporter?tab=readme-ov-file#enabled-by-default) 및 [procfs](https://github.com/prometheus/procfs?tab=readme-ov-file) GitHub 리포지토리를 참조하세요. 다음 표에는 CPU 로드, 메모리 사용량, 디스크 공간 및 네트워크 활동과 같은 시스템 리소스 사용률에 대한 인사이트를 제공하는 지표의 하위 집합이 나와 있습니다.
| 지표 이름 | 설명 |
| --- | --- |
| node\$1load1 | 1분 로드 평균 |
| node\$1load5 | 5분 로드 평균 |
| node\$1load15 | 15분 로드 평균 |
| node\$1memory\$1MemTotal | 총 시스템 메모리 |
| node\$1memory\$1MemFree | 무료 시스템 메모리 |
| node\$1memory\$1MemAvailable | 프로세스에 할당할 수 있는 메모리 |
| node\$1memory\$1Buffers | 커널에서 버퍼링에 사용하는 메모리 |
| node\$1memory\$1Cached | 커널에서 파일 시스템 데이터를 캐싱하는 데 사용되는 메모리 |
| node\$1memory\$1SwapTotal | 사용 가능한 총 스왑 공간 |
| node\$1memory\$1SwapFree | 자유 스왑 공간 |
| node\$1memory\$1SwapCached | 한 번 교체된 메모리는 다시 교체되었지만 여전히 교체 중입니다 |
| node\$1filesystem\$1avail\$1bytes | 사용 가능한 디스크 공간(바이트) |
| node\$1filesystem\$1size\$1bytes | 총 디스크 공간(바이트) |
| node\$1filesystem\$1free\$1bytes | 여유 디스크 공간(바이트) |
| node\$1network\$1receive\$1bytes | 수신된 네트워크 바이트 |
| node\$1network\$1transmit\$1bytes | 전송된 네트워크 바이트 |
| node\$1disk\$1read\$1bytes | 읽은 디스크 바이트 |
| node\$1disk\$1written\$1bytes | 작성된 디스크 바이트 |
## NVIDIA DCGM 내보내기 대시보드
NVIDIA [DCGM 내보내기](https://github.com/NVIDIA/dcgm-exporter)에서 수집한 NVIDIA GPU 지표의 시각화된 정보를 제공합니다.
**지표의 유형**
+ **GPU 개요:** GPU 사용률, 온도, 전력 사용량 및 메모리 사용량 표시.
+ **온도 지표: 시간 경과에 따른 GPU 온도** 시각화.
+ **전력 사용량:** GPU 전력 소비 및 전력 사용량 추세 모니터링.
+ **메모리 사용률:** 사용된 메모리, 사용 가능한 메모리 및 총 메모리를 포함하여 GPU 메모리 사용량을 분석합니다.
+ **팬 속도:** GPU 팬 속도 및 변형 표시.
+ **ECC 오류:** GPU 메모리 ECC 오류 및 보류 중인 오류 추적.
**메트릭 목록**
다음 표에는 클록 주파수, 온도, 전력 사용량, 메모리 사용률, 팬 속도 및 오류 지표를 포함하여 NVIDIA GPU 상태 및 성능에 대한 인사이트를 제공하는 지표 목록이 나와 있습니다.
| 메트릭 이름 | 설명 |
| --- | --- |
| DCGM\$1FI\$1DEV\$1SM\$1CLOCK | SM 클럭 주파수(MHz) |
| DCGM\$1FI\$1DEV\$1MEM\$1CLOCK | 메모리 클럭 주파수(MHz) |
| DCGM\$1FI\$1DEV\$1MEMORY\$1TEMP | 메모리 온도(C) |
| DCGM\$1FI\$1DEV\$1GPU\$1TEMP | GPU 온도(C) |
| DCGM\$1FI\$1DEV\$1POWER\$1USAGE | 전력 소비(W) |
| DCGM\$1FI\$1DEV\$1TOTAL\$1ENERGY\$1CONSUMPTION | 부팅 이후 총 에너지 소비(mJ) |
| DCGM\$1FI\$1DEV\$1PCIE\$1REPLAY\$1COUNTER | 총 PCIe 재시도 횟수 |
| DCGM\$1FI\$1DEV\$1MEM\$1COPY\$1UTIL | 메모리 사용률(%) |
| DCGM\$1FI\$1DEV\$1ENC\$1UTIL | 인코더 사용률(%) |
| DCGM\$1FI\$1DEV\$1DEC\$1UTIL | 디코더 사용률(%) |
| DCGM\$1FI\$1DEV\$1XID\$1ERRORS | 발생한 마지막 XID 오류의 값 |
| DCGM\$1FI\$1DEV\$1FB\$1FREE | 프레임 버퍼 메모리 없음(MiB) |
| DCGM\$1FI\$1DEV\$1FB\$1USED | 사용된 프레임 버퍼 메모리(MiB) |
| DCGM\$1FI\$1DEV\$1NVLINK\$1BANDWIDTH\$1TOTAL | 모든 레인의 총 NVLink 대역폭 카운터 수 |
| DCGM\$1FI\$1DEV\$1VGPU\$1LICENSE\$1STATUS | vGPU 라이선스 상태 |
| DCGM\$1FI\$1DEV\$1UNCORRECTABLE\$1REMAPPED\$1ROWS | 수정할 수 없는 오류에 대해 다시 매핑된 행 수 |
| DCGM\$1FI\$1DEV\$1CORRECTABLE\$1REMAPPED\$1ROWS | 수정 가능한 오류에 대해 다시 매핑된 행 수 |
| DCGM\$1FI\$1DEV\$1ROW\$1REMAP\$1FAILURE | 행 재매핑 실패 여부 |
## EFA 지표 대시보드
[EFA 노드 내보내기](https://github.com/aws-samples/awsome-distributed-training/blob/main/4.validation_and_observability/3.efa-node-exporter/README.md)에서 수집한 P 인스턴스에 장착된 [Amazon Elastic Fabric Adapter(EFA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)의 지표에 대한 시각화된 정보를 제공합니다.
**메트릭 유형**
+ **EFA 오류 지표:** 할당 오류, 명령 오류 및 메모리 맵 오류와 같은 오류를 시각화합니다.
+ **EFA 네트워크 트래픽:** 수신 및 전송된 바이트, 패킷 및 작업 요청을 모니터링합니다.
+ **EFA RDMA 성능:** 전송된 바이트 및 오류율을 포함한 RDMA 읽기 및 쓰기 작업 분석.
+ **EFA 포트 수명:** 시간 경과에 따른 EFA 포트 수명 표시.
+ **EFA 연결 유지 패킷:** 수신된 연결 유지 패킷 수를 추적합니다.
**메트릭 목록**
다음 표에는 오류, 완료된 명령, 네트워크 트래픽 및 리소스 사용률을 포함하여 EFA 작업의 다양한 측면에 대한 인사이트를 제공하는 지표 목록이 나와 있습니다.
| 메트릭 이름 | 설명 |
| --- | --- |
| node\$1amazonefa\$1info | /sys/class/infiniband/의 숫자가 아닌 데이터는 값이 항상 1입니다. |
| node\$1amazonefa\$1lifespan | 포트 수명 |
| node\$1amazonefa\$1rdma\$1read\$1bytes | RDMA로 읽은 바이트 수 |
| node\$1amazonefa\$1rdma\$1read\$1resp\$1bytes | RDMA를 사용한 읽기 응답 바이트 수 |
| node\$1amazonefa\$1rdma\$1read\$1wr\$1err | RDMA의 읽기 쓰기 오류 수 |
| node\$1amazonefa\$1rdma\$1read\$1wrs | RDMA가 있는 읽기 rs 수 |
| node\$1amazonefa\$1rdma\$1write\$1bytes | RDMA로 작성된 바이트 수 |
| node\$1amazonefa\$1rdma\$1write\$1recv\$1bytes | RDMA로 쓰고 받은 바이트 수 |
| node\$1amazonefa\$1rdma\$1write\$1wr\$1err | 오류 RDMA로 작성된 바이트 수 |
| node\$1amazonefa\$1rdma\$1write\$1wrs | 쓰인 wrs RDMA의 바이트 수 |
| node\$1amazonefa\$1recv\$1bytes | 수신한 바이트 수 |
| node\$1amazonefa\$1recv\$1wrs | 수신한 바이트 wrs 수 |
| node\$1amazonefa\$1rx\$1bytes | 수신한 바이트 수 |
| node\$1amazonefa\$1rx\$1drops | 삭제된 패킷 수 |
| node\$1amazonefa\$1rx\$1pkts | 수신된 패킷 수 |
| node\$1amazonefa\$1send\$1bytes | 전송된 바이트 수 |
| node\$1amazonefa\$1send\$1wrs | 전송된 wrs 수 |
| node\$1amazonefa\$1tx\$1bytes | 전송된 바이트 수 |
| node\$1amazonefa\$1tx\$1pkts | 전송된 패킷 수 |
## FSx for Lustre 지표 대시보드
[Amazon CloudWatch](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html)에서 수집한 [Amazon FSx for Lustre 파일 시스템의 메트릭](https://docs.aws.amazon.com/fsx/latest/LustreGuide/monitoring-cloudwatch.html)에 대한 시각화된 정보를 제공합니다.
**참고**
Grafana FSx for Lustre 대시보드는 Amazon CloudWatch를 데이터 소스로 사용하며, 이는 Amazon Managed Service for Prometheus를 사용하도록 구성한 다른 대시보드와 다릅니다. FSx for Lustre 파일 시스템과 관련된 지표를 정확하게 모니터링하고 시각화하려면 Amazon CloudWatch를 데이터 소스로 사용하도록 FSx for Lustre 대시보드를 구성하여 FSx for Lustre 파일 시스템이 배포되는 AWS 리전 위치를 동일하게 지정합니다.
**메트릭의 유형**
+ **DataReadBytes:** 각 파일 시스템 읽기 작업의 바이트 수.
+ **DataWriteBytes:** 각 파일 쓰기 작업의 바이트 수.
+ **DataReadOperations:** 읽기 작업 수.
+ **DataWriteOperations:** 쓰기 작업 수.
+ **MetadataOperations:** 메타 데이터 작업 수.
+ **FreeDataStorageCapacity:** 사용 가능한 스토리지 용량.
# Amazon SageMaker HyperPod Slurm 지표
Amazon SageMaker HyperPod는 HyperPod 클러스터의 상태와 성능을 모니터링하는 데 사용할 수 있는 Amazon CloudWatch 지표 세트를 제공합니다. 이러한 지표는 HyperPod 클러스터에서 실행되는 Slurm 워크로드 관리자에서 수집되며 `/aws/sagemaker/Clusters` CloudWatch 네임스페이스에서 사용할 수 있습니다.
## 클러스터 수준 지표
HyperPod에 사용할 수 있는 클러스터 수준 지표는 다음과 같습니다. 이러한 지표는 `ClusterId` 차원을 사용하여 특정 HyperPod 클러스터를 식별합니다.
| CloudWatch 지표 명칭 | 참고 | Amazon EKS Container Insights 지표 이름 |
| --- | --- | --- |
| cluster\$1node\$1count | Slurm 클러스터의 총 노드 수 | cluster\$1node\$1count |
| cluster\$1idle\$1node\$1count | 클러스터의 유휴 노드 수 | 해당 사항 없음 |
| cluster\$1failed\$1node\$1count | 클러스터의 실패한 노드 수 | cluster\$1failed\$1node\$1count |
| cluster\$1cpu\$1count | 클러스터의 총 CPU 코어 수 | node\$1cpu\$1limit |
| cluster\$1idle\$1cpu\$1count | 클러스터의 유휴 CPU 코어 수 | 해당 사항 없음 |
| cluster\$1gpu\$1count | 클러스터의 총 GPU 수 | node\$1gpu\$1limit |
| cluster\$1idle\$1gpu\$1count | 클러스터의 유휴 GPU 수 | 해당 사항 없음 |
| cluster\$1running\$1task\$1count | 클러스터의 실행 중인 Slurm 작업 수 | 해당 사항 없음 |
| cluster\$1pending\$1task\$1count | 클러스터의 보류 중인 Slurm 작업 수 | 해당 사항 없음 |
| cluster\$1preempted\$1task\$1count | 클러스터의 선점된 Slurm 작업 수 | 해당 사항 없음 |
| cluster\$1avg\$1task\$1wait\$1time | 클러스터의 Slurm 작업에 대한 평균 대기 시간 | 해당 사항 없음 |
| cluster\$1max\$1task\$1wait\$1time | 클러스터의 Slurm 작업에 대한 최대 대기 시간 | 해당 사항 없음 |
## 인스턴스 수준 지표
HyperPod에 사용할 수 있는 인스턴스 수준 지표는 다음과 같습니다. 또한 이러한 지표는 `ClusterId` 차원을 사용하여 특정 HyperPod 클러스터를 식별합니다.
| CloudWatch 지표 명칭 | 참고 | Amazon EKS Container Insights 지표 이름 |
| --- | --- | --- |
| node\$1gpu\$1utilization | 모든 인스턴스의 평균 GPU 사용률 | node\$1gpu\$1utilization |
| node\$1gpu\$1memory\$1utilization | 모든 인스턴스의 평균 GPU 메모리 사용률 | node\$1gpu\$1memory\$1utilization |
| node\$1cpu\$1utilization | 모든 인스턴스의 평균 CPU 사용률 | node\$1cpu\$1utilization |
| node\$1memory\$1utilization | 모든 인스턴스의 평균 메모리 사용률 | node\$1memory\$1utilization |
# 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"
```
# Slurm을 사용한 향상된 클러스터 작업을 위한 지속적 프로비저닝
Slurm 오케스트레이션으로 생성된 Amazon SageMaker HyperPod 클러스터는 이제 대규모 AI/ML 워크로드를 실행할 때 유연성과 효율성을 높일 수 있는 기능인 지속적 프로비저닝을 지원합니다. 지속적 프로비저닝을 사용하면 훈련을 빠르게 시작하고, 원활하게 규모를 조정하고, 작업을 중단하지 않고 유지 관리를 수행하고, 클러스터 작업을 세부적으로 파악할 수 있습니다.
**참고**
지속적 프로비저닝은 Slurm 오케스트레이션으로 생성된 새 HyperPod 클러스터에 대한 선택적 구성으로 사용할 수 있습니다. 현재 이전 조정 모델을 사용하는 기존 클러스터는 지속적 프로비저닝으로 마이그레이션할 수 없습니다.
## 작동 방식
지속적 프로비저닝 시스템은 기존의 all-or-nothing 조정 모델을 대체하는 원하는 상태 아키텍처를 도입합니다. 이전 모델에서 인스턴스 그룹을 완전히 프로비저닝할 수 없는 경우 전체 클러스터 생성 또는 업데이트 작업이 실패하고 롤백됩니다. 지속적인 프로비저닝을 통해 시스템은 부분 용량을 수락하고 나머지 인스턴스를 비동기적으로 계속 프로비저닝합니다.
지속적 프로비저닝 시스템:
+ **요청 수락**: 각 인스턴스 그룹의 대상 인스턴스 수를 기록합니다.
+ **프로비저닝 시작**: 모든 인스턴스 그룹에 대해 인스턴스를 병렬로 시작하기 시작합니다.
+ **우선 순위 노드 먼저 프로비저닝**: 클러스터는 하나 이상의 컨트롤러 노드(로그인 인스턴스 그룹이 지정된 경우 로그인 노드 하나)가 성공적으로 프로비저닝된 `InService` 후 로 전환됩니다.
+ **진행 상황 추적**: 각 인스턴스 시작 시도를 모니터링하고 상태를 기록합니다.
+ **실패 처리**: 작업자 노드에 대해 실패한 시작을 비동기적으로 자동으로 재시도합니다.
연속 프로비저닝은 기본적으로 비활성화되어 있습니다. 이 기능을 사용하려면 `CreateCluster` 요청`Continuous`에서를 `NodeProvisioningMode`로 설정합니다.
지속적 프로비저닝을 활성화하면 이전 작업이 완료될 때까지 기다리지 않고 여러 규모 조정 작업을 동시에 시작할 수 있습니다. 이렇게 하면 동일한 클러스터에서 서로 다른 인스턴스 그룹을 동시에 규모 조정하고 여러 규모 조정 요청을 동일한 인스턴스 그룹에 제출할 수 있습니다.
## 우선 순위 기반 프로비저닝
Slurm 클러스터는 작업자 노드가 작업을 등록하고 수락하기 전에 컨트롤러 노드가 작동해야 합니다. 지속적 프로비저닝은 우선 순위 기반 프로비저닝을 통해 이를 자동으로 처리합니다.
1. 컨트롤러 인스턴스 그룹이 먼저 프로비저닝됩니다.
1. 컨트롤러 노드 하나가 정상이면 로그인 노드와 작업자 노드가 병렬로 프로비저닝을 시작합니다.
1. 클러스터는 컨트롤러 노드 하나가 가동되고 로그인 노드 하나가 가동`InService`되면(로그인 인스턴스 그룹이 지정된 경우) 로 전환됩니다. 로그인 인스턴스 그룹을 지정하지 않으면 컨트롤러 노드가 프로비저닝되는 `InService` 즉시 클러스터가 로 전환됩니다.
1. 용량 제약으로 인해 즉시 프로비저닝할 수 없는 작업자 노드는 비동기 재시도 루프에 들어가고 사용 가능하게 되면 Slurm 클러스터에 자동으로 추가됩니다.
## 컨트롤러 장애 처리
클러스터를 생성하는 동안 컨트롤러 노드가 프로비저닝에 실패하면 오류의 재시도 가능 여부에 따라 동작이 달라집니다.
**재시도 가능한 오류**(예: 비정상 인스턴스 또는 일시적 실패):
+ HyperPod는 인스턴스를 지속적으로 교체하고 컨트롤러가 나타날 때까지 프로비저닝을 재시도합니다.
+ 이미 프로비저닝된 작업자 및 로그인 노드는 계속 사용할 수 있지만 컨트롤러가 정상 상태가 될 `InService` 때까지 클러스터가 로 전환되지 않습니다.
**재시도할 수 없는 오류**(예: 컨트롤러 인스턴스 유형에 사용할 수 있는 용량 없음 또는 수명 주기 스크립트 실패):
+ 클러스터는 로 표시됩니다`Failed`.
+ 실패 이유에 대한 알림을 받으며 다른 인스턴스 유형 선택, 수명 주기 스크립트 수정 또는 다른 가용 영역에서 재시도와 같은 수정 조치를 취해야 합니다.
## 사전 조건
지속적 프로비저닝을 사용하려면 각 인스턴스 그룹의 `SlurmConfig` 필드에서 API 페이로드를 통해 Slurm 프로비저닝 파라미터(노드 유형, 파티션 이름)를 제공해야 합니다. Amazon S3의 레거시 `provisioning_parameters.json` 파일을 사용하는 클러스터는 지속적 프로비저닝과 호환되지 않습니다.
**참고**
기존 클러스터 마이그레이션, API 기반 Slurm 토폴로지를 통한 다중 헤드 노드 구성,와 같은 기능은 현재 Slurm 클러스터에서 지속적 프로비저닝에서 지원되지 않습니다`SlurmConfigStrategy`. 지속적 프로비저닝은 `slurm.conf` 관리를 위한 병합 모드에서만 작동합니다.
## 사용량 측정
지속적 프로비저닝이 사용되는 HyperPod 클러스터는 인스턴스 수준 측정 기능을 사용하여 실제 리소스 사용량을 반영하는 정확한 청구서를 제공합니다. 이 측정 접근 방식은 각 인스턴스를 독립적으로 추적하므로 기존의 클러스터 수준 청구와 다릅니다.
**인스턴스 수준 청구**
지속적 프로비저닝을 사용하면 클러스터 수준 상태 변경을 기다리지 않고 개별 인스턴스 수준에서 청구가 시작되고 중지됩니다. 이러한 접근 방식에는 다음과 같은 이점이 있습니다.
+ **정확한 청구**: 수명 주기 스크립트 실행이 시작되면 청구가 시작됩니다. 수명 주기 스크립트가 실패하면 인스턴스 프로비저닝이 재시도되고 수명 주기 스크립트 런타임 기간에 대한 요금이 부과됩니다.
+ **독립 측정**: 각 인스턴스의 결제 수명 주기는 별도로 관리되므로 계단식 결제 오류를 방지할 수 있습니다.
+ **실시간 결제 업데이트**: 인스턴스가 수명 주기 구성 스크립트를 실행하기 시작하면 결제가 시작되고 인스턴스가 종료 상태가 되면 결제가 중지됩니다.
**청구 수명 주기**
HyperPod 클러스터의 각 인스턴스는 다음 청구 수명 주기를 따릅니다.
+ **결제 시작**: 인스턴스가 성공적으로 시작되고 수명 주기 구성 스크립트 실행을 시작하는 경우.
+ **결제 계속**: 인스턴스의 운영 수명 동안.
+ **결제 중지**: 종료 이유에 관계없이 인스턴스가 종료 상태가 되는 경우입니다.
**참고**
가동에 실패한 인스턴스에 대해서는 청구가 시작되지 않습니다. 용량 부족 또는 기타 문제로 인해 인스턴스 청구가 실패하는 경우 실패한 시도에 대해서는 요금이 부과되지 않습니다. 청구서는 인스턴스 수준에서 계산되며 비용은 클러스터의 Amazon 리소스 이름(ARN)으로 집계 및 보고됩니다.
## 지속적 프로비저닝이 활성화된 클러스터 생성
**참고**
수명 주기 구성 스크립트를 준비하고 실행 역할이 액세스할 수 있는 Amazon S3 버킷에 업로드합니다. 자세한 내용은 [SageMaker HyperPod Slurm 클러스터 작업](sagemaker-hyperpod-operate-slurm.md) 단원을 참조하십시오.
JSON 형식으로 `CreateCluster` API 요청 파일을 준비합니다. `NodeProvisioningMode`를 `Continuous` 로 설정하고 각 인스턴스 그룹의 `SlurmConfig` 필드에 Slurm 토폴로지 정보를 제공합니다.
```
// create_cluster.json
{
"ClusterName": "my-training-cluster",
"NodeProvisioningMode": "Continuous",
"Orchestrator": {
"Slurm": {}
},
"InstanceGroups": [
{
"InstanceGroupName": "controller-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Controller"
}
},
{
"InstanceGroupName": "login-group",
"InstanceType": "ml.m5.xlarge",
"InstanceCount": 1,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Login"
}
},
{
"InstanceGroupName": "worker-gpu-a",
"InstanceType": "ml.p5.48xlarge",
"InstanceCount": 16,
"LifeCycleConfig": {
"SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["gpu-training"]
}
}
],
"VpcConfig": {
"SecurityGroupIds": ["sg-12345678"],
"Subnets": ["subnet-12345678"]
}
}
```
`create-cluster` 명령을 실행하여 요청을 제출합니다.
```
aws sagemaker create-cluster \
--cli-input-json file://complete/path/to/create_cluster.json
```
그러면 새 클러스터의 ARN이 반환됩니다.
```
{
"ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}
```
## Slurm 구성 관리
지속적 프로비저닝은 `slurm.conf` 파티션 관리를 위한 병합 모드에서만 작동합니다. 병합 모드에서 HyperPod는에서 수정한 것 외에도 파티션 구성 변경 사항을 추가로 적용합니다`slurm.conf`. HyperPod는의 파티션 관련 섹션`slurm.conf`(예: 파티션 이름 및 노드 이름 항목)만 업데이트합니다. 다른 Slurm 구성 파라미터는 수정되지 않습니다. 이는 다음을 의미합니다.
+ 에 대한 수동 편집`slurm.conf`은 보존됩니다.
+ 수정 사항과 HyperPod의 예상 상태 간의 충돌에 대한 자동 드리프트 감지 또는 해결은 없습니다.
`SlurmConfigStrategy` 파라미터(`Managed`, `Merge`, `Overwrite`)는 지속적 프로비저닝에서 지원되지 않습니다. `SlurmConfigStrategy` 값을 전달하면 API 오류가 발생합니다.
# SageMaker HyperPod 클러스터 관리
다음 주제에서는 SageMaker HyperPod 클러스터 로깅 및 관리에 대해 설명합니다.
## SageMaker HyperPod 이벤트 로깅
SageMaker HyperPod의 모든 이벤트 및 로그는 로그 그룹 이름 `/aws/sagemaker/Clusters/[ClusterName]/[ClusterID]`로 Amazon CloudWatch에 저장됩니다. `CreateCluster` API에 대한 모든 호출은 새 로그 그룹을 생성합니다. 다음 목록에는 각 로그 그룹에서 수집된 사용 가능한 모든 로그 스트림이 포함되어 있습니다.
| | |
| --- |--- |
| 로그 그룹 이름 | 로그 스트림 이름 |
| /aws/sagemaker/Clusters/[ClusterName]/[ClusterID] | LifecycleConfig/[instance-group-name]/[instance-id] |
## 인스턴스 수준에서 SageMaker HyperPod 로깅
클러스터 인스턴스 구성 중에 CloudWatch에 게시된 LifecycleScript 로그에 액세스할 수 있습니다. 생성된 클러스터 내의 모든 인스턴스는 `LifecycleConfig/[instance-group-name]/[instance-id]` 형식으로 구분 가능한 별도의 로그 스트림을 생성합니다.
`/var/log/provision/provisioning.log`에 기록된 모든 로그는 이전 CloudWatch 스트림에 업로드됩니다. [https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config](https://github.com/aws-samples/awsome-distributed-training/tree/main/1.architectures/5.sagemaker-hyperpod/LifecycleScripts/base-config)의 샘플 LifecycleScripts는 자신의 `stdout` 및 `stderr`를 이 위치로 리디렉션합니다. 사용자 지정 스크립트를 사용하는 경우 CloudWatch 에서 사용할 수 있는 `/var/log/provision/provisioning.log` 위치에 로그를 작성합니다.
**수명 주기 스크립트 로그 마커**
수명 주기 스크립트에 대한 CloudWatch 로그에는 실행 진행 상황을 추적하고 문제를 식별하는 데 도움이 되는 특정 마커가 포함되어 있습니다.
| | |
| --- |--- |
| 마커 | 설명 |
| START | Indicates the beginning of lifecycle script logs for the instance |
| [SageMaker] Lifecycle scripts were provided, with S3 uri: [s3://bucket-name/] and entrypoint script: [script-name.sh] | Indicates the S3 location and entrypoint script that will be used |
| [SageMaker] Downloading lifecycle scripts | Indicates scripts are being downloaded from the specified S3 location |
| [SageMaker] Lifecycle scripts have been downloaded | Indicates scripts have been successfully downloaded from S3 |
| [SageMaker] The lifecycle scripts succeeded | Indicates successful completion of all lifecycle scripts |
| [SageMaker] The lifecycle scripts failed | Indicates failed execution of lifecycle scripts |
이러한 마커는 수명 주기 스크립트 실행 프로세스에서 문제가 발생한 위치를 빠르게 식별하는 데 도움이 됩니다. 실패 문제를 해결할 때 로그 항목을 검토하여 프로세스가 중지되거나 실패한 위치를 식별합니다.
**수명 주기 스크립트 실패 메시지**
수명 주기 스크립트가 존재하지만 실행 중에 실패하면 CloudWatch 로그 그룹 이름과 로그 스트림 이름이 포함된 오류 메시지가 표시됩니다. 여러 인스턴스에서 수명 주기 스크립트 오류가 발생하는 경우 오류 메시지는 실패한 인스턴스를 하나만 나타내지만 로그 그룹에는 모든 인스턴스에 대한 스트림이 포함되어야 합니다.
[DescribeCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_DescribeCluster.html) API를 실행하거나 SageMaker 콘솔에서 클러스터 세부 정보 페이지를 확인하여 오류 메시지를 볼 수 있습니다. 콘솔에는 CloudWatch **로그 스트림으로 직접 이동하는 수명 주기 스크립트 로그 보기** 버튼이 제공됩니다. 오류 메시지의 형식은 다음과 같습니다.
```
Instance [instance-id] failed to provision with the following error: "Lifecycle scripts did not run successfully. To view lifecycle script logs,
visit log group ‘/aws/sagemaker/Clusters/[cluster-name]/[cluster-id]' and log stream ‘LifecycleConfig/[instance-group-name]/[instance-id]’.
If you cannot find corresponding lifecycle script logs in CloudWatch, please make sure you follow one of the options here:
https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-faq-slurm.html#hyperpod-faqs-q1.” Note that multiple instances may be impacted.
```
## 리소스에 태그 지정
AWS 태깅 시스템은 리소스를 관리, 식별, 구성, 검색 및 필터링하는 데 도움이 됩니다. SageMaker HyperPod는 태그 지정을 지원하므로 클러스터를 AWS 리소스로 관리할 수 있습니다. 클러스터를 생성하거나 기존 클러스터를 편집하는 동안 클러스터에 대한 태그를 추가하거나 편집할 수 있습니다. 일반적인 태그 지정에 대한 자세한 내용은 [AWS 리소스 태그 지정을 참조하세요](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
### SageMaker HyperPod 콘솔 UI 사용
[새 클러스터 생성](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-create-cluster) 및 [클러스터 편집 시](sagemaker-hyperpod-operate-slurm-console-ui.md#sagemaker-hyperpod-operate-slurm-console-ui-edit-clusters) 태그를 추가, 편집 또는 제거할 수 있습니다.
### SageMaker HyperPod API 사용
[CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html) 또는 [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) API 요청 파일을 JSON 형식으로 작성할 때는 `Tags` 섹션을 편집합니다.
### SageMaker AI에 태그 AWS CLI 지정 명령 사용
**클러스터에 태그를 지정하려면**
다음과 같이 [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/add-tags.html)를 사용합니다.
```
aws sagemaker add-tags --resource-arn cluster_ARN --tags Key=string,Value=string
```
**클러스터의 태그를 해제하려면**
다음과 같이 [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/delete-tags.html)를 사용합니다.
```
aws sagemaker delete-tags --resource-arn cluster_ARN --tag-keys "tag_key"
```
**리소스에 대한 태그를 나열하려면**
다음과 같이 [https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-tags.html](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-tags.html)를 사용합니다.
```
aws sagemaker list-tags --resource-arn cluster_ARN
```
# 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)를 참조하세요.