Gemini Enterprise Agent Platform 학습 클러스터는 컴퓨팅 노드의 안정성과 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)
자동화된 상태 점검 및 복구
노드 안정성을 보장하기 위해 학습 클러스터는 다음 자동 점검 모음을 사용하여 노드 상태를 지속적으로 모니터링합니다. 학습 클러스터는 Slurm 프롤로그(작업 시작 전) 및 에필로그(작업 완료 후) 중에 상태 점검을 실행합니다.
상태 점검 모음
- GPU 상태:
nvidia-smi,dcgmi,xid코드 모니터링을 비롯한 세부적인 개별 GPU 진단을 실행합니다. - 디스크 사용량: 공간 부족으로 인해 작업이 실패하지 않도록 중요한 파티션(
/,/mnt/localssd,/mnt/localdisk)의 디스크 사용량이 많지는 않은지 확인합니다. - 네트워크 상태: 기본 네트워크 인터페이스에 IPv4 주소가 있는지 확인합니다. 문제가 발견되면 인터페이스를 재설정하여 자체 복구를 시도합니다.
- CPU 부하: 시스템의 부하 평균을 모니터링하고 사전 정의된 임계값을 초과하면 경고를 로깅합니다.
장애 복구 프로세스
확인에서 심각한 복구 불가 오류가 감지되면 Gemini Enterprise Agent Platform 학습 클러스터가 자동으로 실패 복구 프로세스를 시작합니다. 표준 프로세스에는 장애 노드 드레이닝, 영향을 받는 Slurm 작업 다시 대기열에 추가, 드레이닝된 노드 삭제 및 다시 생성하여 정상 상태로 복원하는 작업이 포함됩니다.
이 자동 복구에는 다음 조건이 적용됩니다.
재시작 한도: 영향을 받는 Slurm 작업이 이미 설정된 횟수만큼 다시 시작된 경우 복구 프로세스가 건너뛰어집니다.
GPU 사용률: 노드에서 실행 중인 작업 이 사용 가능한 모든 GPU를 사용하지 않는 경우 노드 삭제 및 다시 생성도 건너뛰어집니다. 이 경우 새 작업이 예약되지 않도록 노드만 드레이닝됩니다.
모든 복구 작업은 프로젝트의 로그에 복원력 이벤트로 기록됩니다. 이러한 이벤트를 노드의 Slurm 상태와 비교하여 차트로 표시하려면 대시보드로 복원력 이벤트 모니터링을 참조하세요.
장애 컴퓨팅 노드 수동 관리
학습 클러스터는 장애 컴퓨팅 노드를 수동으로 신고하고 관리하기 위한 API를 제공하며, 이는 자동화된 상태 점검으로 문제를 해결할 수 없는 경우에 특히 유용합니다. 이러한 작업은 한 번에 하나의 노드에서만 실행할 수 있습니다.
| 작업 | 설명 | 권장되는 상황 |
|---|---|---|
| 노드 삭제 | 클러스터에서 지정된 장애 노드를 삭제합니다. 기본 작업입니다. | 일반적인 오류 또는 노드가 응답하지 않고 재활용해야 하는 경우 |
| 장애로 호스트 신고 | 기본 물리적 호스트가 잘못된 것으로 신고하여 복구 또는 이전 프로세스를 트리거합니다. | GPU 노드를 호스팅하는 실제 머신에서 하드웨어 장애가 의심되는 경우 |
작업 1: 장애 노드 삭제
이 작업은 지정된 노드를 삭제합니다. 이 작업의 결과는 노드가 Slurm에 의해 '정적' 또는 '동적'으로 분류되는지에 따라 달라집니다.
정적 노드: 삭제된 노드의 색인이 노드 풀의 최소 노드 수보다 작으면 동일한 이름과 사양으로 새 컴퓨팅 노드가 다시 생성됩니다.
동적 노드: 삭제된 노드의 색인이 최소 노드 수보다 크면 예약된 보류 중인 워크로드가 있는 경우에만 다시 생성됩니다. 그렇지 않으면 삭제됩니다.
이 예시에서는 gcurl 별칭을 사용하며, 이는 API 엔드포인트와 상호작용하기 위한 인증된 편리한 단축 명령입니다. 다음 명령어는 필요한 승인 헤더를 포함하는 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 역할 부여
이 기능을 사용하려면 에이전트 플랫폼 서비스 에이전트에 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 워크플로를 빌드하는 데 중요한 단계입니다.
- 학습 작업 모니터링 및 디버깅: 노드가 복구되었거나 장애로 인해 작업이 다시 시작된 시점을 파악하는 방법을 비롯하여 학습 작업의 진행 상황, 리소스 사용률, 상태를 추적합니다.
- Gemini Enterprise Agent Platform Pipelines로 복원력 있는 작업 조정: 프로덕션 환경의 경우 Gemini Enterprise Agent Platform Pipelines를 사용하여 클러스터에 복원력 있는 학습 작업을 제출하는 자동화된 반복 가능한 워크플로를 만듭니다.
- 모델 관리 및 배포: 복원력 있는 학습 작업이 완료되면 Gemini Enterprise Agent Platform Model Registry를 사용하여 모델 아티팩트를 버전 관리한 후 엔드포인트에 모델을 배포하여 온라인 추론 요청을 처리합니다.