AWS ParallelCluster 구축 가이드
서울 리전 · p6-b300 · 대규모 LLM 학습 환경

일정상 가장 앞에 와야 하는 단계입니다. 다른 모든 작업이 여기에 의존합니다.

0-1. p6-b300 가용 AZ 조회

aws ec2 describe-instance-type-offerings --region ap-northeast-2 \
  --location-type availability-zone \
  --filters Name=instance-type,Values=p6-b300.48xlarge \
  --query 'InstanceTypeOfferings[].Location' --output table

여기서 나온 AZ가 이후 서브넷·FSx·placement group의 위치를 전부 결정합니다.

0-2. 용량 예약 — 두 경로 중 선택

0-3. EC2 쿼터 신청

0-4. 도구 준비

pip install aws-parallelcluster==3.16.1
pcluster version

1-1. 만들 것

• VPC — 권장 /16, DNS hostnames + DNS resolution 활성
• 퍼블릭 서브넷 1개 — head node, login nodes
• 프라이빗 서브넷 1개 (컴퓨트 전용) — Step 0에서 확인한 AZ, 크기는 아래 표
• NAT Gateway — 컴퓨트 서브넷 라우팅 테이블에 경로 추가
• (선택) S3 / ECR / CloudWatch VPC 엔드포인트 — NAT 데이터 처리 비용 절감

1-2. 컴퓨트 서브넷 사이징

EFA 레이아웃(Step 5d)에 따라 노드당 IP 소비가 달라집니다.

2-1. 계층 구조

2-2. 만들 때 지킬 것

• FSx for Lustre를 컴퓨트와 같은 AZ에 생성 (AZ 간 전송 비용·지연 회피)
• 파일시스템 보안그룹에 컴퓨트 / head / login 인바운드 허용
• S3 버킷 생성 + Lustre DRA(Data Repository Association) 연동

3-1. 스크립트 목록과 실행 지점

S3 버킷에 업로드하고, head/compute/login IAM에 해당 버킷 읽기 권한을 부여합니다.

3-2. Lustre 런타임 튜닝 — 기본값은 대규모 GPU에 맞지 않습니다

# 데이터 경로 (OSC) — 체크포인트 쓰기 처리량
lctl set_param osc.*.max_rpcs_in_flight=32       # 기본 8
lctl set_param osc.*.max_dirty_mb=512            # 기본 32
lctl set_param osc.*.max_pages_per_rpc=1024      # 기본 256(1MB) → 4MB/RPC

# 메타데이터 경로 (MDC) — Python import, HF 캐시 walk에 결정적
lctl set_param mdc.*.max_rpcs_in_flight=64
lctl set_param mdc.*.max_mod_rpcs_in_flight=32

# read-ahead (llite) — 4TB 메모리 노드에서는 크게 잡아도 무리 없음
lctl set_param llite.*.max_read_ahead_mb=1024
lctl set_param llite.*.statahead_max=512

디렉터리별 striping은 login/head 노드에서 1회만 실행합니다.

lfs setstripe -c -1 -S 4M /fsx/checkpoints   # 전 OST 분산 — 대용량 순차 쓰기
lfs setstripe -c -1 -S 4M /fsx/datasets      # 전 노드 순차 읽기
lfs setstripe -c 8  -S 4M /fsx/containers    # .sqsh 이미지 (5–30 GB)
lfs setstripe -c 1        /fsx/logs          # small append — 넓게 펴면 lock 오버헤드만 증가

# /etc/needrestart/conf.d/90-slurm.conf
$nrconf{override_rc}{qr(^slurmd)} = 0;

ParallelCluster의 Slurm accounting은 고객이 MySQL 호환 DB를 준비해야 합니다. 팀별 GPU 쿼터를 강제하려면 필수입니다.

• Amazon Aurora MySQL 또는 RDS MySQL 생성 (head node에서 도달 가능한 위치)
• DB 자격증명을 Secrets Manager에 저장 → ARN 확보
• head node IAM에 해당 시크릿 읽기 권한 부여
• DB 보안그룹에 head node 인바운드 3306 허용

블록별로 나눠 설명합니다. 각 블록 아래에 그 설정에서 실제로 문제가 되는 항목을 붙였습니다. 5f에 2노드 검증용 전체 파일을 실었습니다.

5a. Region / Image / HeadNode

Region: ap-northeast-2

Image:
  Os: ubuntu2404              # ⚠ 변경 불가 — 되돌릴 수 없는 결정 #1

HeadNode:
  InstanceType: m6i.8xlarge
  Ssh:
    KeyName: ${SSH_KEY}
    AllowedIps: ${TRUSTED_CIDR}     # 0.0.0.0/0 금지
  Networking:
    SubnetId: ${PUBLIC_SUBNET_ID}
  LocalStorage:
    RootVolume:
      Size: 1024
      VolumeType: gp3
      Iops: 16000
      Throughput: 1000
  Iam:
    AdditionalIamPolicies:
      - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
    S3Access:
      - BucketName: ${SCRIPT_BUCKET}
        EnableWriteAccess: false
  CustomActions:
    OnNodeConfigured:
      Script: s3://${SCRIPT_BUCKET}/head-setup.sh

5b. LoginNodes

LoginNodes:
  Pools:
    - Name: login
      Count: 2
      InstanceType: m6i.4xlarge
      GracetimePeriod: 30          # 노드 교체 전 사용자 사전 통보 (분, 3~120)
      Networking:
        SubnetIds: [${PUBLIC_SUBNET_ID}]   # 풀당 서브넷 1개만
      Iam:
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
      CustomActions:
        OnNodeConfigured:
          Script: s3://${SCRIPT_BUCKET}/login-setup.sh

5c. SlurmSettings

Scheduling:
  Scheduler: slurm
  SlurmSettings:
    ScaledownIdletime: 60
    QueueUpdateStrategy: DRAIN
    EnableMemoryBasedScheduling: true
    CustomSlurmSettingsIncludeFile: s3://${SCRIPT_BUCKET}/slurm-extra.conf
    Database:                          # Step 4에서 준비
      Uri: ${AURORA_ENDPOINT}:3306
      UserName: ${DB_USER}
      PasswordSecretArn: ${SECRET_ARN}

5d. GPU 큐 — 이 문서에서 가장 중요한 블록

먼저 EFA 레이아웃을 선택하십시오.

(A) 기본 레이아웃 설정입니다.

  SlurmQueues:
    - Name: gpu
      CapacityType: ONDEMAND            # 또는 CAPACITY_BLOCK
      JobExclusiveAllocation: false
      CustomSlurmSettings:                # ⚠ 이 큐가 만드는 'gpu' 파티션을 잠금 (Step 7 참조)
        Hidden: YES
        AllowGroups: root
      HealthChecks:
        Gpu:
          Enabled: false              # ⚠ p6-b300에서는 반드시 false
      Networking:
        SubnetIds: [${PRIVATE_SUBNET_ID}]  # 단일 AZ
        AssignPublicIp: false           # ⚠ EFA 다중 NIC → 필수
        PlacementGroup:
          Enabled: true                # CAPACITY_BLOCK이면 false
      ComputeSettings:
        LocalStorage:
          EphemeralVolume:
            MountDir: /opt/dlami/nvme    # 로컬 NVMe 활용
          RootVolume:
            Size: 500
            VolumeType: gp3
      Iam:
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
        S3Access:
          - BucketName: ${SCRIPT_BUCKET}
            EnableWriteAccess: false
      ComputeResources:
        - Name: b300
          InstanceType: p6-b300.48xlarge
          MinCount: 2                  # 전량 static — 2노드 검증 → 16 → 125 순으로 증가
          MaxCount: 2
          Efa:
            Enabled: true              # 3.15.0+ 가 EFA-only 자동 구성
          CapacityReservationTarget:
            CapacityReservationId: ${CRID}
      CustomActions:
        OnNodeStart:
          Script: s3://${SCRIPT_BUCKET}/compute-start.sh
        OnNodeConfigured:
          Sequence:
            - Script: s3://${SCRIPT_BUCKET}/lustre-tuning.sh
            - Script: s3://${SCRIPT_BUCKET}/gpu-healthcheck-startup.sh
            - Script: s3://${SCRIPT_BUCKET}/dcgm-exporter.sh

Capacity Block 경로라면 큐 블록이 이렇게 바뀝니다. 아래는 달라지는 부분만 적은 것이며, CustomSlurmSettings·HealthChecks·ComputeSettings·Iam·CustomActions는 위 (A) 블록과 동일하게 유지합니다.

    - Name: gpu
      CapacityType: CAPACITY_BLOCK
      Networking:
        SubnetIds: [${PRIVATE_SUBNET_ID}]
        AssignPublicIp: false
        PlacementGroup:
          Enabled: false              # CB는 PG 불가
      ComputeResources:
        - Name: b300-cb1                # 블록당 최대 64대 →
          InstanceType: p6-b300.48xlarge
          MinCount: 64                  # MinCount == MaxCount 필수
          MaxCount: 64
          Efa: { Enabled: true }
          CapacityReservationTarget:
            CapacityReservationId: cr-xxxxxxxx
        - Name: b300-cb2                # 125노드는 CB 2개 = CR 2개
          InstanceType: p6-b300.48xlarge
          MinCount: 61
          MaxCount: 61
          Efa: { Enabled: true }
          CapacityReservationTarget:
            CapacityReservationId: cr-yyyyyyyy

5e. 스토리지 / 관측 / 타임아웃

SharedStorage:
  - Name: fsx
    MountDir: /fsx
    StorageType: FsxLustre
    FsxLustreSettings:
      FileSystemId: ${FSX_ID}          # ⚠ 외부 생성한 것을 ID로 참조
  - Name: home
    MountDir: /home
    StorageType: FsxOpenZfs
    FsxOpenZfsSettings:
      VolumeId: ${OPENZFS_VOLUME_ID}

Monitoring:
  DetailedMonitoring: true
  Logs:
    CloudWatch:
      Enabled: true
      RetentionInDays: 90
  Dashboards:
    CloudWatch:
      Enabled: true

DevSettings:
  Timeouts:
    HeadNodeBootstrapTimeout: 3600    # 기본값은 부족할 수 있음
    ComputeNodeBootstrapTimeout: 3600

Tags:
  - Key: Project
    Value: llm-training

5f. 전체 파일 — 2노드 검증용 cluster-config.yaml

위 블록을 합친 파일입니다. ${...}는 실제 값으로 치환하십시오. 16노드로 갈 때는 MinCount/MaxCount와 slurm-extra.conf의 Nodes= 범위만 바뀝니다.

Region: ap-northeast-2

Image:
  Os: ubuntu2404

HeadNode:
  InstanceType: m6i.8xlarge
  Ssh:
    KeyName: ${SSH_KEY}
    AllowedIps: ${TRUSTED_CIDR}
  Networking:
    SubnetId: ${PUBLIC_SUBNET_ID}
  LocalStorage:
    RootVolume: { Size: 1024, VolumeType: gp3, Iops: 16000, Throughput: 1000 }
  Iam:
    AdditionalIamPolicies:
      - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
    S3Access:
      - { BucketName: ${SCRIPT_BUCKET}, EnableWriteAccess: false }
  CustomActions:
    OnNodeConfigured:
      Script: s3://${SCRIPT_BUCKET}/head-setup.sh

LoginNodes:
  Pools:
    - Name: login
      Count: 2
      InstanceType: m6i.4xlarge
      GracetimePeriod: 30
      Networking:
        SubnetIds: [${PUBLIC_SUBNET_ID}]
      Iam:
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
      CustomActions:
        OnNodeConfigured:
          Script: s3://${SCRIPT_BUCKET}/login-setup.sh

Scheduling:
  Scheduler: slurm
  SlurmSettings:
    ScaledownIdletime: 60
    QueueUpdateStrategy: DRAIN
    EnableMemoryBasedScheduling: true
    CustomSlurmSettingsIncludeFile: s3://${SCRIPT_BUCKET}/slurm-extra.conf
    Database:                          # accounting 미사용 시 이 블록 삭제
      Uri: ${AURORA_ENDPOINT}:3306
      UserName: ${DB_USER}
      PasswordSecretArn: ${SECRET_ARN}
  SlurmQueues:
    - Name: gpu
      CapacityType: ONDEMAND
      JobExclusiveAllocation: false
      CustomSlurmSettings:
        Hidden: YES
        AllowGroups: root
      HealthChecks:
        Gpu: { Enabled: false }
      Networking:
        SubnetIds: [${PRIVATE_SUBNET_ID}]
        AssignPublicIp: false
        PlacementGroup: { Enabled: true }
      ComputeSettings:
        LocalStorage:
          EphemeralVolume: { MountDir: /opt/dlami/nvme }
          RootVolume: { Size: 500, VolumeType: gp3 }
      Iam:
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
        S3Access:
          - { BucketName: ${SCRIPT_BUCKET}, EnableWriteAccess: false }
      ComputeResources:
        - Name: b300
          InstanceType: p6-b300.48xlarge
          MinCount: 2
          MaxCount: 2
          Efa: { Enabled: true }
          CapacityReservationTarget:
            CapacityReservationId: ${CRID}
      CustomActions:
        OnNodeStart:
          Script: s3://${SCRIPT_BUCKET}/compute-start.sh
        OnNodeConfigured:
          Sequence:
            - Script: s3://${SCRIPT_BUCKET}/lustre-tuning.sh
            - Script: s3://${SCRIPT_BUCKET}/gpu-healthcheck-startup.sh
            - Script: s3://${SCRIPT_BUCKET}/dcgm-exporter.sh

SharedStorage:
  - Name: fsx
    MountDir: /fsx
    StorageType: FsxLustre
    FsxLustreSettings: { FileSystemId: ${FSX_ID} }
  - Name: home
    MountDir: /home
    StorageType: FsxOpenZfs
    FsxOpenZfsSettings: { VolumeId: ${OPENZFS_VOLUME_ID} }

Monitoring:
  DetailedMonitoring: true
  Logs:
    CloudWatch: { Enabled: true, RetentionInDays: 90 }
  Dashboards:
    CloudWatch: { Enabled: true }

DevSettings:
  Timeouts:
    HeadNodeBootstrapTimeout: 3600
    ComputeNodeBootstrapTimeout: 3600

Tags:
  - { Key: Project, Value: llm-training }

# 1) 설정 검증만 — 리소스를 만들지 않습니다. 반드시 먼저 실행하십시오.
pcluster create-cluster -n llm-poc -c cluster-config.yaml --dryrun true

# 2) 생성 (2노드 검증 구성으로 시작)
pcluster create-cluster -n llm-poc -c cluster-config.yaml

# 3) 상태 확인
pcluster describe-cluster -n llm-poc

# 4) 실패 시 로그
pcluster list-cluster-log-streams -n llm-poc
pcluster get-cluster-log-events -n llm-poc --log-stream-name <stream>

접속

# login node 인스턴스 ID 확인 후 SSM 세션
aws ec2 describe-instances --region ap-northeast-2 \
  --filters "Name=tag:parallelcluster:cluster-name,Values=llm-poc" \
            "Name=tag:parallelcluster:node-type,Values=LoginNode" \
            "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].InstanceId' --output text

aws ssm start-session --target <instance-id> --region ap-northeast-2

7-1. 두 계층의 역할 — 파티션만으로는 독점을 막을 수 없습니다

7-2. slurm-extra.conf (S3에 업로드)

# ---- 자원 할당 단위 ----
# 멀티스레딩 활성(기본) 기준: 192 vCPU / 8 GPU = 24
# DisableSimultaneousMultithreading을 켰다면 96/8 = 12로 조정
DefCPUPerGPU=24
DefMemPerGPU=480000

# ---- 스케줄링 / 우선순위 ----
SchedulerType=sched/backfill
PriorityType=priority/multifactor
PriorityWeightPartition=100000
PriorityWeightQOS=1000
PriorityWeightFairshare=100         # 1단계는 파티션/QoS 우선순위 중심. fair-share를 실제로 쓰려면 Partition과 같은 자릿수로

# ---- Preemption ----
PreemptType=preempt/partition_prio
PreemptMode=REQUEUE

# ---- 내결함성 ----
JobRequeue=1
KillWait=300                    # 시간 초과 시 SIGTERM → SIGKILL 간격 (기본 30초). 체크포인트 저장 여유
# UnkillableStepTimeout은 SIGKILL 이후 "죽지 않는 프로세스" 판정 대기시간 — 체크포인트와 무관, 기본값 유지

# ---- Health check (Step 8) — ⚠ 반드시 로컬 디스크 경로. /fsx에 두면 Lustre 장애 = 전 노드 drain·교체 ----
HealthCheckProgram=/opt/ops/health/periodic-check.sh
HealthCheckInterval=300
HealthCheckNodeState=IDLE
Prolog=/opt/ops/health/prolog-gpu-quick.sh
Epilog=/opt/ops/health/epilog-on-failure.sh

# ---- Accounting ----
AccountingStorageTRES=cpu,mem,node,billing,gres/gpu
AccountingStorageEnforce=limits,qos,associations

# ---- 파티션 (노드 이름 규칙: <queue>-st-<computeresource>-<n>) ----
# ⚠ 존재하지 않는 노드를 참조하면 slurmctld가 기동하지 않습니다. 단계별로 Nodes= 범위를 맞추십시오.
#    2노드 검증 : 네 파티션 모두 gpu-st-b300-[1-2]
#    16노드 파일럿: 아래 값
#    125노드    : [1-125] 등으로 갱신 (Step 10)
# GraceTime = 선점(REQUEUE)당할 때 SIGTERM 후 유예 시간(초) — 체크포인트 저장용
PartitionName=debug     Nodes=gpu-st-b300-[1-2]   Priority=100   MaxTime=00:30:00    Default=NO  State=UP AllowQOS=debug_qos     GraceTime=120
PartitionName=normal    Nodes=gpu-st-b300-[1-8]   Priority=200   MaxTime=1-00:00:00  Default=YES State=UP AllowQOS=normal_qos    GraceTime=600
PartitionName=large     Nodes=gpu-st-b300-[1-16]  Priority=300   MaxTime=7-00:00:00  Default=NO  State=UP AllowQOS=large_qos     GraceTime=600
PartitionName=exclusive Nodes=gpu-st-b300-[1-16]  Priority=1000  MaxTime=14-00:00:00 Default=NO  State=UP PreemptMode=REQUEUE AllowQOS=exclusive_qos

7-3. 계정과 QoS 생성 (head node에서)

# 팀 계정
sacctmgr --immediate add account team-a Description="Team A"
sacctmgr --immediate add account team-b Description="Team B"

# 사용자 등록 (OS 계정이 먼저 존재해야 함)
sacctmgr --immediate add user name=${USER} account=team-a

# QoS 생성 및 제한 (여러 개는 name=a,b,c 형식)
sacctmgr --immediate add qos name=debug_qos,normal_qos,large_qos,exclusive_qos
sacctmgr -i modify qos debug_qos     set MaxJobsPerUser=1 MaxSubmitJobsPerUser=2 Priority=1000
sacctmgr -i modify qos normal_qos    set MaxJobsPerUser=4 MaxSubmitJobsPerUser=8 Priority=2000
sacctmgr -i modify qos large_qos     set Priority=3000
sacctmgr -i modify qos exclusive_qos set MaxJobsPerUser=1 MaxSubmitJobsPerUser=2 Priority=10000

# ★ 팀별 GPU 총량 상한 — 독점 방지의 핵심
sacctmgr -i modify account team-a set GrpTRES=gres/gpu=64
sacctmgr -i modify account team-b set GrpTRES=gres/gpu=64

# 계정별 사용 가능 QoS와 기본값 (모든 팀 계정에 반복)
sacctmgr -i modify account team-a set qos+=debug_qos,normal_qos,large_qos DefaultQOS=normal_qos
sacctmgr -i modify account team-b set qos+=debug_qos,normal_qos,large_qos DefaultQOS=normal_qos
# exclusive_qos는 필요한 팀에만 별도 부여

# 확인
sacctmgr show assoc format=account,user,qos,defaultqos,grptres
scontrol show partition | grep -E 'PartitionName|Default|AllowQos'   # 기본 파티션이 normal인지, gpu가 Hidden인지

내장 체크를 끈 대신 직접 구성합니다. 1,000 GPU가 며칠씩 도는 환경에서 이 단계는 선택이 아닙니다.

8-1. 3단계 배치 (AWS 문서 권고 모델)

8-2. 이것이 자동 교체로 연결됩니다 — 핵심

AWS 문서 원문입니다.

AWS ParallelCluster replaces drained or failed static nodes (and terminates dynamic ones), so draining a node with a confirmed fault results in it being replaced.

8-3. job 내결함성

• JobRequeue=1 + sbatch --requeue로 제출
• KillWait=300(시간 초과) + 파티션 GraceTime=600(선점) — SIGTERM 뒤 SIGKILL까지의 여유 시간
• 학습 스크립트는 sbatch --signal=B:USR1@600으로 종료 600초 전 시그널을 받아 체크포인트를 저장하고 스스로 종료

8-4. pcluster-diag

ParallelCluster 3.16.0부터 공식 AMI에 진단 도구 pcluster-diag가 포함됩니다. 노드에서 온디맨드로 실행할 수 있습니다. 장애 조사 시 가장 먼저 돌려보십시오.

8-5. 스크립트 골격

동작 원리를 보이기 위한 최소 골격입니다. 실제 판정 기준(Xid 코드 목록, 허용 온도, 재시도 횟수)은 2노드 검증에서 실측 후 확정하십시오. 네 파일 모두 compute-start.sh가 S3에서 /opt/ops/health/로 복사합니다.

# compute-start.sh (OnNodeStart) — 헬스체크 스크립트 로컬 복사 + needrestart 가드
#!/bin/bash
set -euo pipefail
mkdir -p /opt/ops/health
aws s3 sync s3://${SCRIPT_BUCKET}/health/ /opt/ops/health/ --region ap-northeast-2
chmod 755 /opt/ops/health/*.sh
if [ -d /etc/needrestart ]; then
  mkdir -p /etc/needrestart/conf.d
  echo '$nrconf{override_rc}{qr(^slurmd)} = 0;' > /etc/needrestart/conf.d/90-slurm.conf
fi

# prolog-gpu-quick.sh — 수 초 이내. GPU/EFA 결함만 실패(exit 1)로 처리
#!/bin/bash
LOG=/var/log/ops-prolog.log
fail(){ echo "$(date -Is) job=$SLURM_JOB_ID FAIL: $*" >> $LOG
        scontrol update NodeName=$(hostname -s) State=DRAIN Reason="prolog: $*"; exit 1; }
timeout 10 nvidia-smi --query-gpu=count --format=csv,noheader >/dev/null 2>&1 || fail "nvidia-smi"
n=$(nvidia-smi -L 2>/dev/null | wc -l); [ "$n" -eq 8 ] || fail "gpu count $n"
# 최근 부팅 이후 치명 Xid (79 fallen off bus, 74 NVLink, 48 DBE, 63/64 row remap)
if journalctl -k -b --no-pager | grep -E 'NVRM: Xid .*: (79|74|48|63|64),' -q; then fail "xid"; fi
efa=$(ls /sys/class/infiniband/ 2>/dev/null | wc -l); [ "$efa" -eq 16 ] || fail "efa devices $efa"
exit 0    # 스토리지·네트워크 등 그 외 문제는 로그만 남기고 통과

# epilog-on-failure.sh — job이 실패했을 때만 level-2 진단 (노드에 다른 job이 없을 때만)
#!/bin/bash
[ "${SLURM_JOB_EXIT_CODE:-0}" = "0" ] && exit 0
running=$(squeue -h -w $(hostname -s) -t RUNNING | wc -l)
[ "$running" -gt 0 ] && exit 0            # 공유 노드에서 dcgmi diag 금지
if ! timeout 900 dcgmi diag -r 2 > /var/log/ops-epilog-diag.$SLURM_JOB_ID.log 2>&1; then
  scontrol update NodeName=$(hostname -s) State=DRAIN Reason="epilog: dcgmi diag -r 2 failed job=$SLURM_JOB_ID"
fi
exit 0

# periodic-check.sh (HealthCheckProgram, IDLE 노드에서 5분마다) — 가볍게
#!/bin/bash
nvidia-smi --query-gpu=temperature.gpu,ecc.errors.uncorrected.volatile.total --format=csv,noheader 2>/dev/null  | awk -F, '{ if ($1+0 > 90 || $2+0 > 0) bad=1 } END { exit bad }'  || scontrol update NodeName=$(hostname -s) State=DRAIN Reason="periodic: temp/ecc"
exit 0

# gpu-healthcheck-startup.sh (OnNodeConfigured) — job 없음, 수 분 허용
#!/bin/bash
set -e
nvidia-smi topo -m > /var/log/ops-topo.log
[ $(ls /sys/class/infiniband/ | wc -l) -eq 16 ]
timeout 1800 dcgmi diag -r 3 > /var/log/ops-startup-diag.log     # 실패 시 exit≠0 → 노드가 큐에 들어오지 않음

9-1. 인프라 기본

sinfo -N -l
scontrol show nodes | grep -E 'NodeName|State|CfgTRES|Gres'

# 파티션 — 기본 파티션이 normal이고 gpu가 Hidden/root 전용인지
scontrol show partition | grep -E 'PartitionName|Default|Hidden|AllowGroups|AllowQos'

# GPU 인식 — 8개, gres/gpu=8
srun -p normal -N1 --gres=gpu:8 nvidia-smi

# EFA 열거 — 16 도메인이어야 함
srun -p normal -N1 fi_info -p efa | grep -c domain
srun -p normal -N1 ls /sys/class/infiniband/

# 스토리지
df -h /fsx /home
lfs df -h /fsx

9-2. NCCL 다중 노드 — 가장 중요한 성능 검증

# 컨테이너 이미지 (태그 고정). enroot는 '#' 레지스트리 구분자를 씁니다
enroot import -o /fsx/nccl-tests.sqsh \
  "docker://public.ecr.aws#hpc-cloud/nccl-tests:<tag>"

# 2노드 / 16 GPU all_reduce
srun -p normal -N2 --ntasks-per-node=8 --gres=gpu:8 \
  --container-image=/fsx/nccl-tests.sqsh \
  all_reduce_perf -b 8 -e 16G -f 2 -g 1

합격 기준

• 로그에 NET/OFI Selected provider is efa 와 found 16 nics
• # Out of bounds values : 0 / OK
• busbw가 메시지 크기에 따라 증가하고 대형 메시지에서 포화

9-3. 스토리지 성능

• Lustre 튜닝 적용 전/후 순차 쓰기 처리량 비교
• 실제 체크포인트 저장 1회 소요시간 측정 → Capacity Block 종료 시각 계획에 사용(Step 0)
• 로컬 NVMe 캐시 적용 시 데이터 로딩 시간 변화
• ENA 350 Gbps가 병목인지 판정 → 레이아웃 (B) 전환 여부 결정

9-4. 장애 리허설 필수

9-5. 멀티유저

• GrpTRES=gres/gpu=N 초과 제출이 실제로 거부되는지
• MaxJobsPerUser 초과 제출이 막히는지
• 낮은 우선순위 파티션 job이 높은 우선순위 job에 의해 실제로 preempt(requeue) 되는지
• sacct -a -S <date> -E now 로 사용자별 집계가 나오는지
• 일반 사용자가 -p gpu로 제출하면 거부되는지 (QoS 우회 차단 확인)
• --signal=B:USR1@600을 쓴 job이 scancel·선점 시 실제로 체크포인트를 남기는지

# MinCount/MaxCount만 올리고 업데이트
pcluster update-cluster -n llm-poc -c cluster-config.yaml

scontrol create reservation ReservationName=maint_for_update user=root \
  starttime=now duration=infinite flags=maint,ignore_jobs \
  nodes=gpu-st-b300-[15-16]

# 작업 후 해제
scontrol delete ReservationName=maint_for_update