Vertex AI 학습 클러스터는 컴퓨팅 노드의 안정성과 Slurm 작업의 안정성을 보장하기 위해 포괄적인 상태 점검 시스템을 통합합니다. 이 시스템은 자동 복구 옵션과 수동 복구 옵션을 모두 제공합니다. 작업 실행 중에 자동화된 프로세스가 실행되어 GPU 상태 및 디스크 사용량과 같은 중요 구성요소를 모니터링하고 실패한 노드를 자동으로 교체합니다. 사용자 개입이 필요한 상황의 경우 학습 클러스터에서 reportFaultyNodes API를 제공하므로 특정 결함이 있는 노드를 수동으로 삭제하거나 기본 호스트에서 의심되는 하드웨어 장애를 신고할 수 있습니다.
테스트 워크로드를 실행하여 GPU 기능 확인
1단계: SSH를 사용하여 클러스터 노드에 연결
Cloud Shell 또는 Google Cloud 콘솔에서 IAP를 사용하여 로그인 노드에 연결합니다. 다음 예는 Cloud Shell의 명령어를 보여줍니다.
gcloud compute ssh --zone $ZONE "Login Node Name" --tunnel-through-iap --project $PROJECT_ID
2단계: 표준 Slurm 명령어 실행
로그인 노드에 연결한 후 몇 가지 표준 Slurm 명령어를 실행하여 클러스터가 올바르게 작동하는지 확인합니다.
~$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
partition1* up infinite 2 idle hcsa3m1236-a3mnodeset-[0-1]
다음으로 일괄 작업을 제출합니다.
~$ sbatch --qos normal --wrap "echo start! && sleep 10s && echo done!"
홈 디렉터리에 slurm-job-id.out 파일이 생성된 것을 확인할 수 있습니다.
3단계: GPU 워크로드 실행
다음 콘텐츠를 홈 디렉터리에 test.sh라는 스크립트 파일로 저장합니다.
#!/bin/bash
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=1
#SBATCH --cpus-per-task=4
#SBATCH --gres=gpu:8
#SBATCH --job-name=nvidia_smi
srun nvidia-smi -L
스크립트의 권한을 755로 설정하여 실행 가능하게 만든 다음 Slurm 작업을 제출합니다.
~$ sbatch ./test.sh
Slurm은 스크립트의 출력을 slurm-job-id.out이라는 파일에 저장합니다.
예상 출력:
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-f75045e8-4d87-49d1-2eb9-39ec2baddf9b)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-b91556d8-5215-d0ed-50b8-a88720e5b29c)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-7600155a-0036-35f5-9489-a7b4ed0ce887)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-a402e125-7841-033f-f08b-7921526c121f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-20eef8f8-b2c7-1716-5ce7-7f64475bd2c0)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-65463286-e587-b52f-4d5b-8880eecbf0e7)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-d5ff75e7-dd54-edf6-a684-33c26fc365e1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-26e81ae2-11fd-9d7e-95b6-c186e5173007)
GPU 0: NVIDIA H100 80GB HBM3 (UUID: GPU-e66a185a-b40c-81d9-d35d-19cab811df34)
GPU 1: NVIDIA H100 80GB HBM3 (UUID: GPU-d23e5cf7-afd8-bec2-1487-9e27eeb6aae0)
GPU 2: NVIDIA H100 80GB HBM3 (UUID: GPU-4dde1b05-ea5e-01e9-5c1e-e1c0d3b4b113)
GPU 3: NVIDIA H100 80GB HBM3 (UUID: GPU-3a0d734a-6fb8-d841-a97f-d6846553ea7f)
GPU 4: NVIDIA H100 80GB HBM3 (UUID: GPU-76fe0d37-08b2-a3a6-8ddf-55501426bc7c)
GPU 5: NVIDIA H100 80GB HBM3 (UUID: GPU-9e0a41e1-b399-8934-01af-6198b749c02a)
GPU 6: NVIDIA H100 80GB HBM3 (UUID: GPU-dddd09ee-c944-1098-9c4e-d96f8762ecb1)
GPU 7: NVIDIA H100 80GB HBM3 (UUID: GPU-df52c109-0ac1-30cc-226b-85b1a8a6bc16)
클러스터 상태 확인
이 섹션에서는 학습 클러스터 이미지에 사전 설치된 클러스터 상태 스캐너(CHS) 도구를 사용하여 학습 클러스터를 테스트하는 방법을 보여줍니다. CHS 도구는 클러스터의 상태를 확인하고 DCGM 진단 및 NCCL 테스트와 같은 테스트를 실행하여 클러스터가 워크로드를 실행할 준비가 되었는지 확인합니다.
클러스터의 로그인 노드에서 다음 스크립트를 실행하여 CHS 도구를 사용하여 테스트를 실행할 수 있습니다.
export CLUSTER_ID=<your_cluster_id>
export PARTITION=a3u
export MACHINE_TYPE=a3-ultragpu-8g
cd ~
/opt/cluster-health-scanner/deploy/slurm/cluster-validation.sh \
--nodelist=${CLUSTER_ID}-${PARTITION}-[0-1] \
--nodes=2 \
--partition=${PARTITION} \
--machine-type=${MACHINE_TYPE} \
--relative-exec-path=../../opt/cluster-health-scanner/deploy/slurm \
--results-dir=results
테스트가 성공적으로 실행되면 다음 두 가지 결과가 제공됩니다.
- 요약 출력: 간단한 요약이 콘솔에 출력되며, 이는 다음 예시와 유사해야 합니다.
- 세부 로그: 전체 보고서는
~/results디렉터리에 저장된 세부 로그를 참고하세요.
Starting DCGM Diagnostics...
DCGM diagnostics passing on all nodes!
Starting NCCL all_reduce_perf...
CURR_NODES: cluster-id-0
cluster-id-1
NCCL test passing on all nodes!
자동 상태 점검 및 복구
노드 안정성을 보장하기 위해 학습 클러스터는 다음 자동 검사 모음을 사용하여 노드 상태를 지속적으로 모니터링합니다. 학습 클러스터는 Slurm 프롤로그(작업 시작 전) 및 에필로그(작업 완료 후) 중에 상태 점검을 실행합니다.
상태 점검 스위트
- GPU 상태:
nvidia-smi,dcgmi,xid코드 모니터링을 비롯한 세부적인 개별 GPU 진단을 실행합니다. - 디스크 사용량: 공간 부족으로 인해 작업이 실패하지 않도록 중요한 파티션(
/,/mnt/localssd,/mnt/localdisk)의 디스크 사용량이 많지는 않은지 확인합니다. - 네트워크 상태: 기본 네트워크 인터페이스에 IPv4 주소가 있는지 확인합니다. 문제가 발견되면 인터페이스를 재설정하여 자체 복구를 시도합니다.
- CPU 로드: 시스템의 평균 로드를 모니터링하고 사전 정의된 기준점을 초과하면 경고를 기록합니다.
실패 복구 프로세스
확인에서 심각한 복구 불가 오류가 감지되면 Vertex AI 학습 클러스터가 자동으로 실패 복구 프로세스를 시작합니다. 표준 프로세스에는 결함이 있는 노드를 드레이닝하고, 영향을 받는 Slurm 작업을 다시 대기열에 추가한 다음, 드레이닝된 노드를 삭제하고 다시 만들어 정상 상태로 복원하는 작업이 포함됩니다.
이 자동 복구에는 다음 조건이 적용됩니다.
다시 시작 제한: 영향을 받는 Slurm 작업이 이미 설정된 횟수만큼 다시 시작된 경우 복구 프로세스가 건너뜁니다.
GPU 사용률: 노드에서 실행되는 작업이 사용 가능한 GPU를 모두 사용하지 않는 경우에도 노드 삭제 및 재생성이 건너뜁니다. 이 경우 노드는 새 작업이 예약되지 않도록만 드레인됩니다.
결함이 있는 컴퓨팅 노드 수동 관리
트레이닝 클러스터는 결함이 있는 컴퓨팅 노드를 수동으로 보고하고 관리하는 API를 제공하며, 이는 자동 상태 점검으로 문제가 해결되지 않는 경우에 특히 유용합니다. 이러한 작업은 한 번에 하나의 노드에서만 실행할 수 있습니다.
| 작업 | 설명 | 권장되는 상황 |
|---|---|---|
| 노드 삭제 | 클러스터에서 지정된 결함이 있는 노드를 삭제합니다. 기본 작업입니다. | 일반적인 오류 또는 노드가 응답하지 않아 재활용해야 하는 경우 |
| 장애로 호스트 신고 | 기본 물리적 호스트가 잘못된 것으로 신고하여 복구 또는 이전 프로세스를 트리거합니다. | GPU 노드를 호스팅하는 실제 머신에서 하드웨어 장애가 의심되는 경우 |
작업 1: 결함이 있는 노드 삭제
이 작업은 지정된 노드를 삭제합니다. 이 작업의 결과는 노드가 Slurm에 의해 '정적' 또는 '동적'으로 분류되는지에 따라 달라집니다.
정적 노드: 삭제된 노드의 인덱스가 노드 풀의 최소 노드 수보다 작으면 동일한 이름과 사양으로 새 컴퓨팅 노드가 다시 생성됩니다.
동적 노드: 삭제된 노드의 색인이 최소 노드 수보다 큰 경우 예약된 대기 중인 워크로드가 있는 경우에만 다시 생성됩니다. 그렇지 않으면 삭제됩니다.
이 예에서는 API 엔드포인트와 상호작용하기 위한 편리한 인증된 바로가기인 gcurl 별칭을 사용합니다. 다음 명령어는 필수 승인 헤더를 포함하는 curl의 별칭을 만듭니다.
alias gcurl='curl -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json"'
노드를 삭제하는 API 요청
결함이 있는 노드를 삭제하려면 다음 POST 요청을 실행하세요. NODE_ID는 CLUSTER_ID-NODEPOOL_ID-INDEX 형식이어야 합니다.
gcurl -X POST https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes -d '{"nodeActions": [{"nodeId": "NODE_ID"}]}'
작업 상태 확인
작업 상태를 확인하여reportFaultyNodes 작업의 결과를 모니터링할 수 있습니다.
gcurl https://REGION-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID
작업 2: 호스트를 장애로 신고하기
하드웨어 오류가 의심되면 GPU 노드의 실제 호스트에 장애가 있는 것으로 신고할 수 있습니다.
지원되는 VM: A3 Ultra 및 A4 High-GPU
노드 상태: API를 호출하기 전에 타겟 노드가
RUNNING상태여야 합니다. 호출이 성공하면REPAIRING으로 전환되고 호스트가 복구되거나 새 호스트에서 노드가 다시 생성된 후RUNNING으로 돌아갑니다. 이는 최선의 노력에 해당하는 작업입니다.
기본 요건: IAM 역할 부여
이 기능을 사용하려면 Vertex AI 서비스 에이전트에 Compute 인스턴스 관리자(v1)(roles/compute.instanceAdmin.v1) 역할을 부여해야 합니다.
PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") gcloud projects add-iam-policy-binding PROJECT_ID\ --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.iam.gserviceaccount.com" \ --role="roles/compute.instanceAdmin.v1"
호스트 신고를 위한 API 요청
다음 POST 요청을 실행하여 기본 호스트에 장애가 있는 것으로 보고합니다. 이때 관찰된 동작과 faultReasons에 대한 설명을 하나 이상 제공해야 합니다.
behavior 필드에는 다음 값 중 하나를 사용해야 합니다.
| 동작 | 설명 |
|---|---|
PERFORMANCE |
VM에 연결된 GPU의 성능이 클러스터의 다른 GPU에 비해 문제가 있고, 로그에 XID 오류가 표시되지 않으며, Compute Engine에서 무음 데이터 손상과 같은 다른 일반적인 실패 패턴을 감지하지 않습니다. |
SILENT_DATA_CORRUPTION |
VM에서 데이터 손상이 발생하지만 VM은 계속 실행됩니다. 이는 vCPU 결함, 소프트웨어 버그 또는 커널 문제와 같은 문제로 인해 발생할 수 있습니다. |
UNRECOVERABLE_GPU_ERROR |
XID를 사용하여 복구 불가 GPU 오류를 식별했습니다. |
BEHAVIOR_UNSPECIFIED |
VM에 어떤 문제가 있는지 잘 모르겠습니다. |
다음은 API 요청의 예입니다.
gcurl -X POST \
https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/modelDevelopmentClusters/CLUSTER_ID:reportFaultyNodes \
-d '{"nodeActions": [{"nodeId": "NODE_ID", "reportFaultyHost": {"faultReasons": [{"behavior": "BEHAVIOR_1", "description": "DESCRIPTION_1"}, {"behavior": "BEHAVIOR_2", "description": "DESCRIPTION_2"}]}}]}'
요약 정리
자동 상태 점검과 이 페이지에 자세히 설명된 수동 제어를 모두 활용하면 복원력이 뛰어난 학습 환경을 유지할 수 있습니다. 결함이 있는 노드를 삭제하거나 하드웨어 문제를 보고하여 클러스터 상태를 선제적으로 관리하면 최대 가동시간을 보장하고 학습 작업을 성공적으로 완료할 수 있습니다. 지속적이거나 복잡한 문제의 경우 항상 Google Cloud 지원팀에 문의하여 심층 진단과 지원을 받는 것이 좋습니다.
다음 단계
내결함성을 위해 학습 클러스터를 구성하는 것은 완전하고 프로덕션에 즉시 사용 가능한 MLOps 워크플로를 빌드하는 데 중요한 단계입니다.
- 학습 작업 모니터링 및 디버깅: 노드가 복구되었거나 장애로 인해 작업이 다시 시작된 시점을 파악하는 방법을 비롯하여 학습 작업의 진행 상황, 리소스 사용률, 상태를 추적합니다.
- Vertex AI Pipelines로 복원력 있는 작업 조정: 프로덕션 환경의 경우 Vertex AI Pipelines를 사용하여 클러스터에 복원력 있는 학습 작업을 제출하는 자동화된 반복 가능한 워크플로를 만듭니다.
- 모델 관리 및 배포: 복원력 있는 학습 작업이 완료되면 Vertex AI Model Registry를 사용하여 모델 아티팩트를 버전 관리한 후 엔드포인트에 모델을 배포하여 온라인 추론 요청을 처리합니다.