기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 수명 주기 스크립트를 사용하여 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) 참조하세요. 작업자 노드만 교체할 수 있습니다.