Slurm 클러스터에서 플렉스 시작 VM 사용

이 가이드에서는 Gemini Enterprise Agent Platform에서 Slurm을 사용하여 Flex Start VM을 구성하고 사용하는 방법을 설명합니다. 이 통합을 통해 학습 워크로드에 유연한 VM 프로비저닝 모델을 사용할 수 있습니다.

구성 및 클러스터 생성

클러스터의 구성을 정의하기 전에 먼저 다음 일회성 기본 요건 단계를 완료하여 필요한 서비스 계정에 플렉스 시작 리소스를 관리할 권한이 부여되었는지 확인해야 합니다.

Google API 서비스 에이전트의 권한 확인

  • 컨텍스트: Gemini Enterprise Agent Platform의 Slurm은 관리형 인스턴스 그룹을 사용하여 Flex Start VM 인스턴스를 동적으로 프로비저닝하고 수명 주기를 관리합니다. Google API 서비스 에이전트는 관리형 인스턴스 그룹의 기본 Compute Engine 리소스를 만들고 관리합니다. 관리형 인스턴스 그룹 및 IAM 문서에 자세히 설명되어 있듯이 이 서비스 계정에는 VM 인스턴스를 생성, 삭제, 나열할 수 있는 권한과 서비스 계정 ID를 연결할 수 있는 권한이 필요합니다.
  • 작업: Google API 서비스 에이전트(PROJECT_NUMBER@cloudservices.gserviceaccount.com)에 이미 편집자 역할 (roles/editor)이 있는지 확인합니다.
    • '예'인 경우: 추가 조치를 취하지 않아도 됩니다. 편집자 역할에는 일반적으로 필요한 모든 권한이 포함됩니다.
    • '아니요': 기본 편집자 역할이 부여되지 않은 경우 MIG가 작동하도록 다음 역할을 명시적으로 부여해야 합니다.
      • Compute 인스턴스 관리자 (v1) (roles/compute.instanceAdmin.v1) - VM 인스턴스를 만들고, 나열하고, 삭제하는 데 필요합니다.
      • 서비스 계정 사용자 (roles/iam.serviceAccountUser) - 새 VM에 서비스 계정을 연결하는 데 필요합니다.

유연한 시작 프로비저닝 모델로 Slurm 클러스터 만들기

Flex Start 프로비저닝 모델을 사용하는 Slurm 클러스터를 만들려면 API를 사용하여 클러스터 생성 요청을 제출할 때 클러스터 사양의 노드 풀 구성 내에서 provisioning_model를 지정해야 합니다.

구성 스니펫 예시: 다음 JSON 구성을 cluster_config.json라는 파일에 저장합니다. 이 예시에서는 slurm_spec을 명시적으로 사용합니다. 자리표시자 (예: <project-id>, <region>, <zone>)를 실제 값으로 바꿉니다.

{
  "display_name": "flexvm",
  "name": "projects/<project-id>/locations/<region>/modelDevelopmentClusters/",
  "network": {
    "network": "projects/<project-id>/global/networks/default",
    "subnetwork": "projects/<project-id>/regions/<region>/subnetworks/default"
  },
  "node_pools": [
    {
      "id": "login",
      "machine_spec": { "machine_type": "n2-standard-8" },
      "scaling_spec": { "min_node_count": 1, "max_node_count": 1 },
      "enable_public_ips": "true",
      "zone": "<zone>",
      "boot_disk": { "boot_disk_type": "pd-standard", "boot_disk_size_gb": 120 }
    },
    {
      "id": "a3u",
      "machine_spec": {
        "machine_type": "a3-ultragpu-8g",
        "accelerator_type": "NVIDIA_H200_141GB",
        "accelerator_count": 8
      },
      "provisioning_model": "FLEX_START",
      "flex_start_max_duration": "604800s",
      "scaling_spec": { "min_node_count": 0, "max_node_count": 2 },
      "zone": "<zone>",
      "enable_public_ips": "true",
      "boot_disk": { "boot_disk_type": "hyperdisk-balanced", "boot_disk_size_gb": 400 }
    }
  ],
  "orchestrator_spec": {
    "slurm_spec": {
      "home_directory_storage": "projects/<project-id>/locations/<zone>/instances/<filestore-id>",
      "partitions": [ { "id": "a3u", "node_pool_ids": [ "a3u" ] } ],
      "login_node_pool_id": "login"
    }
  }
}

Slurm 클러스터 만들기의 단계에 따라 인증하고 요청을 제출합니다.

최대 플렉스 시작 기간: 선택적으로 플렉스 시작 인스턴스의 최대 실행 기간을 설정할 수 있습니다. 노드 풀 구성에서 flex_start_max_duration 필드를 사용하여 값을 초 단위 문자열로 지정하고 's'를 추가합니다(예: 2일의 경우 '172800s'). 생략하면 시스템에서 기본적으로 7일로 설정됩니다.

운영 수명 주기 및 복원력

Gemini Enterprise Agent Platform 환경에서 Slurm의 Flex Start 노드 수명 주기를 이해하는 것은 작업을 계획하는 데 매우 중요합니다.

유연한 시작 제약 조건

모든 Flex Start VM에는 flex_start_max_duration 설정으로 정의된 고정된 최대 실행 기간이 있습니다.

  • 기간 제한: 기본적으로 flex_start_max_duration은 7일로 설정됩니다. 노드 풀 구성에서 30초에서 최대 7일 (604,800초) 사이의 맞춤 flex_start_max_duration를 지정하여 이 제한을 재정의하고 예상 작업 런타임에 더 적합하게 조정할 수 있습니다.
  • 종료: 이 한도에 도달하면 Compute Engine에서 인스턴스를 엄격하게 종료합니다.

노드 확장 동작

다음 섹션에서는 정적 및 동적이라는 두 가지 사용 가능한 확장 전략을 설명합니다.

정적 노드

정적 노드를 사용하면 항상 사용할 수 있는 고정 리소스 풀 (예: min_node_count > 0)을 유지할 수 있습니다.

  • 프로비저닝: 클러스터 생성 또는 크기 조절 시 최소 노드 수를 충족하기 위해 노드가 즉시 요청됩니다.
  • 만료 및 복구: 정적 유연한 시작 노드가 flex_start_max_duration에 도달하고 Compute Engine에 의해 종료되면 시스템은 정의된 클러스터 용량을 복원하기 위해 자동으로 노드를 다시 만듭니다. 이 주기를 통해 Slurm 작업이 노드를 기다리는지 여부와 관계없이 정적 풀이 채워진 상태로 유지됩니다.

동적 노드

동적 노드를 사용하면 필요할 때만 클러스터를 확장할 수 있습니다.

  • 프로비저닝: 작업이 대기열에 추가되면 (PENDING 상태로 전환) Slurm 스케줄러는 관리형 인스턴스 그룹을 만들고 크기 조절 요청을 실행하여 리소스를 요청합니다.
  • 만료 및 복구: 만료 시 시스템은 노드에서 Slurm 작업이 대기 중인 경우에만 새 Flex Start 노드를 프로비저닝합니다.

클러스터 복원력 및 자동 복구

Gemini Enterprise Agent Platform의 Slurm은 작업 수명 주기의 주요 단계에서 노드 상태를 모니터링합니다. 상태 점검은 작업 시작 전 (프롤로그)과 완료 후 (에필로그)에 모두 실행되어 작업 안정성을 유지하는 데 도움이 됩니다.

  • 하드웨어 오류 처리: 서비스에서 심각한 하드웨어 문제(예: GPU 오류)를 감지하면 비정상 VM을 자동으로 복구하도록 설계되어 있습니다.
  • 자동 교체: 작업이 아직 PENDING 상태이거나 노드 장애로 인해 PENDING으로 다시 대기열에 추가된 경우 시스템은 비정상 VM을 교체하기 위해 새 플렉스 시작 인스턴스를 자동으로 프로비저닝합니다. 이렇게 하면 워크로드가 수동 개입 없이 정상적인 하드웨어에서 계속 진행될 수 있습니다.