기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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` 파일을 사용하는 클러스터는 지속적 프로비저닝과 호환되지 않습니다.
**참고**
현재 Slurm 클러스터의 지속적 프로비저닝에서는 API 기반 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 오류가 발생합니다.
## 최소 용량 요구 사항(MinCount)
MinCount 기능을 사용하면 인스턴스 그룹이 `InService` 상태로 전환되기 전에 성공적으로 프로비저닝해야 하는 최소 인스턴스 수를 지정할 수 있습니다. 이 기능은 조정 작업을 더 잘 제어하고 부분적으로 프로비저닝된 인스턴스 그룹을 워크로드 훈련에 효과적으로 사용할 수 없는 시나리오를 방지하는 데 도움이 됩니다.
**중요**
MinCount는 최소 용량을 영구적으로 보장하지 않습니다. 인스턴스 그룹이 처음가 될 때만 지정된 최소 인스턴스 수를 사용할 수 있도록 합니다`InService`. 비정상 인스턴스 교체 또는 유지 관리 활동과 같은 정상 작동 중에 MinCount 미만으로 잠시 감소할 수 있습니다.
### MinCount 작동 방식
MinCount가 활성화된 인스턴스 그룹을 생성하거나 업데이트하면 다음 동작이 발생합니다.
+ **새 인스턴스 그룹**: 최소 MinCount 인스턴스가 성공적으로 프로비저닝되고 준비될 때까지 인스턴스 그룹은 `Creating` 상태를 유지합니다. 이 임계값이 충족되면 인스턴스 그룹이 로 전환됩니다`InService`.
+ **기존 인스턴스 그룹**: 기존 인스턴스 그룹에서 MinCount를 업데이트할 때 새 MinCount 요구 사항이 충족될 `Updating` 때까지 상태가 로 변경됩니다.
+ **연속 조정**: TargetCount가 MinCount보다 큰 경우 연속 조정 시스템은 TargetCount에 도달할 때까지 추가 인스턴스를 계속 시작하려고 시도합니다.
+ **제한 시간 및 롤백**: 3시간 이내에 MinCount를 충족할 수 없는 경우 시스템은 인스턴스 그룹을 마지막으로 알려진 정상 상태로 자동 롤백합니다. 롤백 동작에 대한 자세한 내용은 [자동 롤백 동작을](#sagemaker-hyperpod-scaling-slurm-mincount-rollback) 참조하세요.
### MinCount 작업 중 인스턴스 그룹 상태
MinCount가 구성된 인스턴스 그룹은 다음과 같은 상태 동작을 나타냅니다.
생성 중
CurrentCount < MinCount일 때 새 인스턴스 그룹의 경우. 인스턴스 그룹은 최소 용량 요구 사항이 충족될 때까지이 상태를 유지합니다.
업데이트 중
MinCount가 수정되고 CurrentCount < MinCount인 기존 인스턴스 그룹의 경우. 인스턴스 그룹은 새로운 최소 용량 요구 사항이 충족될 때까지이 상태를 유지합니다.
서비스 중
MinCount ≤ CurrentCount ≤ TargetCount인 경우. 인스턴스 그룹을 사용할 준비가 되었으며 모든 변경 작업이 차단 해제됩니다.
`Creating` 또는 `Updating` 상태 중에는 다음과 같은 제한이 적용됩니다.
+ `BatchAddClusterNodes`, `BatchDeleteClusterNodes`또는와 같은 변형 작업이 차단`UpdateClusterSoftware`됨
+ MinCount 및 TargetCount 값을 수정하여 구성 오류를 수정할 수 있습니다.
+ 클러스터 및 인스턴스 그룹 삭제는 항상 허용됩니다.
### 자동 롤백 동작
인스턴스 그룹이 3시간 이내에 MinCount에 도달할 수 없는 경우 시스템은 무한 대기를 방지하기 위해 롤백을 자동으로 시작합니다.
+ **새 인스턴스 그룹**: MinCount 및 TargetCount가 (0, 0)으로 재설정됩니다.
+ **기존 인스턴스 그룹**: MinCount 및 TargetCount가 마지막 `InService` 상태에서 해당 값으로 복원됩니다.
+ **종료할 인스턴스 선택**: 롤백 중에 인스턴스를 종료해야 하는 경우 시스템은 비정상 인스턴스를 먼저 선택한 다음 가장 최근에 프로비저닝된 인스턴스를 선택합니다.
+ **상태 전환**: 인스턴스 그룹은 롤백 시작 후 즉시 `InService` 상태로 전환되므로 연속 조정 시스템이 롤백 설정에 따라 용량을 관리할 수 있습니다.
MinCount가 업데이트될 때마다 3시간 제한 시간이 재설정됩니다. 예를 들어 MinCount를 여러 번 업데이트하면 가장 최근 업데이트부터 제한 시간이 새로 시작됩니다.
### MinCount 이벤트
시스템은 MinCount 작업을 추적하는 데 도움이 되는 특정 이벤트를 내보냅니다.
+ **최소 용량 도달**: 인스턴스 그룹이 MinCount에 성공적으로 도달하고 로 전환되면 내보내집니다. `InService`
+ **롤백 시작**됨: 3시간 제한 시간이 만료되고 자동 롤백이 시작될 때 발생합니다.
[ListClusterEvents](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_ListClusterEvents.html)를 사용하여 이러한 이벤트를 모니터링하여 MinCount 작업의 진행 상황을 추적할 수 있습니다.
### API 사용
MinCount는 인스턴스 그룹 구성에서 `MinInstanceCount` 파라미터를 사용하여 지정됩니다.
```
aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--instance-groups '[
{
"InstanceGroupName": "controller-machine",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {"NodeType": "Controller"},
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 2
},
{
"InstanceGroupName": "my-login-group",
"InstanceType": "ml.c5.xlarge",
"InstanceCount": 1,
"SlurmConfig": {"NodeType": "Login"},
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1
},
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.c5.xlarge",
"MinInstanceCount": 1,
"InstanceCount": 2,
"SlurmConfig": {
"NodeType": "Compute",
"PartitionNames": ["p1"]
},
"LifeCycleConfig": {
"SourceS3Uri": "s3://'$BUCKET_NAME'",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "'$EXECUTION_ROLE'",
"ThreadsPerCore": 1
}
]' \
--vpc-config '{
"SecurityGroupIds": ["'$SECURITY_GROUP'"],
"Subnets": ["'$SUBNET'"]
}' \
--node-provisioning-mode Continuous
```
MinCount 사용에 대한 주요 고려 사항:
+ `MinInstanceCount` [CreateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateCluster.html) 또는 [UpdateCluster](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_UpdateCluster.html) 요청에 지정된 인스턴스 그룹의 값이 0과 `InstanceCount` (포함) 사이여야 합니다.
+ 를 0(기본값)`MinInstanceCount`으로 설정하면 표준 연속 조정 동작이 유지됩니다.
+ 클러스터 생성 중에 `MinInstanceCount` 컨트롤러 및 로그인 InstanceGroup 기본값이 1로 설정됩니다.
+ 를 `MinInstanceCount`로 설정하면 `InstanceCount` all-or-nothing 조정하지 않습니다.
+ MinCount는가 로 `NodeProvisioningMode` 설정된 클러스터에만 사용할 수 있습니다. `Continuous`