기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Slurm을 사용한 향상된 클러스터 작업을 위한 지속적 프로비저닝
Slurm 오케스트레이션으로 생성된 Amazon SageMaker HyperPod 클러스터는 이제 대규모 AI/ML 워크로드를 실행할 때 유연성과 효율성을 높일 수 있는 기능인 지속적 프로비저닝을 지원합니다. 지속적 프로비저닝을 사용하면 훈련을 빠르게 시작하고, 원활하게 규모를 조정하고, 작업을 중단하지 않고 유지 관리를 수행하고, 클러스터 작업을 세부적으로 파악할 수 있습니다.
참고
지속적 프로비저닝은 Slurm 오케스트레이션으로 생성된 새 HyperPod 클러스터에 대한 선택적 구성으로 사용할 수 있습니다. 현재 이전 조정 모델을 사용하는 기존 클러스터는 지속적 프로비저닝으로 마이그레이션할 수 없습니다.
작동 방식
지속적 프로비저닝 시스템은 기존의 all-or-nothing 조정 모델을 대체하는 원하는 상태 아키텍처를 도입합니다. 이전 모델에서 인스턴스 그룹을 완전히 프로비저닝할 수 없는 경우 전체 클러스터 생성 또는 업데이트 작업이 실패하고 롤백됩니다. 지속적인 프로비저닝을 통해 시스템은 부분 용량을 수락하고 나머지 인스턴스를 비동기적으로 계속 프로비저닝합니다.
지속적 프로비저닝 시스템:
-
요청 수락: 각 인스턴스 그룹의 대상 인스턴스 수를 기록합니다.
-
프로비저닝 시작: 모든 인스턴스 그룹에 대해 인스턴스를 병렬로 시작하기 시작합니다.
-
우선 순위 노드 먼저 프로비저닝: 클러스터는 하나 이상의 컨트롤러 노드(로그인 인스턴스 그룹이 지정된 경우 로그인 노드 하나)가 성공적으로 프로비저닝된
InService후 로 전환됩니다. -
진행 상황 추적: 각 인스턴스 시작 시도를 모니터링하고 상태를 기록합니다.
-
실패 처리: 작업자 노드에 대해 실패한 시작을 비동기적으로 자동으로 재시도합니다.
연속 프로비저닝은 기본적으로 비활성화되어 있습니다. 이 기능을 사용하려면 CreateCluster 요청Continuous에서를 NodeProvisioningMode로 설정합니다.
지속적 프로비저닝을 활성화하면 이전 작업이 완료될 때까지 기다리지 않고 여러 규모 조정 작업을 동시에 시작할 수 있습니다. 이렇게 하면 동일한 클러스터에서 서로 다른 인스턴스 그룹을 동시에 규모 조정하고 여러 규모 조정 요청을 동일한 인스턴스 그룹에 제출할 수 있습니다.
우선 순위 기반 프로비저닝
Slurm 클러스터는 작업자 노드가 작업을 등록하고 수락하기 전에 컨트롤러 노드가 작동해야 합니다. 지속적 프로비저닝은 우선 순위 기반 프로비저닝을 통해 이를 자동으로 처리합니다.
-
컨트롤러 인스턴스 그룹이 먼저 프로비저닝됩니다.
-
컨트롤러 노드 하나가 정상이면 로그인 노드와 작업자 노드가 병렬로 프로비저닝을 시작합니다.
-
클러스터는 컨트롤러 노드 하나가 가동되고 로그인 노드 하나가 가동
InService되면(로그인 인스턴스 그룹이 지정된 경우) 로 전환됩니다. 로그인 인스턴스 그룹을 지정하지 않으면 컨트롤러 노드가 프로비저닝되는InService즉시 클러스터가 로 전환됩니다. -
용량 제약으로 인해 즉시 프로비저닝할 수 없는 작업자 노드는 비동기 재시도 루프에 들어가고 사용 가능하게 되면 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 클러스터 작업 단원을 참조하십시오.
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 오류가 발생합니다.