AWS PCS 구축 가이드
서울 리전 · 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가 이후 GPU 서브넷·FSx·placement group의 위치를 전부 결정합니다.

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

0-3. 쿼터 신청

0-4. 도구 준비

aws --version                       # pcs 서브커맨드가 있는 최신 AWS CLI v2
aws pcs list-clusters --region ap-northeast-2   # 권한·엔드포인트 확인 (pcs.ap-northeast-2.amazonaws.com)

1-1. 만들 것

• VPC — 권장 /16, DNS hostnames + DNS resolution 활성(PCS 요구사항)
• 퍼블릭 서브넷 1개 — NAT Gateway, (선택) login 노드
• 프라이빗 GPU 서브넷 1개 — Step 0의 AZ, /20
• 프라이빗 서브넷 1개 — login CNG / FSx 마운트타깃 / PCS 클러스터 ENI (GPU 서브넷과 분리)
• 클러스터 보안그룹 — 자기참조(self-referencing) all-traffic 인바운드/아웃바운드. PCS가 컨트롤러 ENI와 모든 노드에 붙이는 SG
• EFA 보안그룹 — 자기참조 all-traffic (EFA 트래픽은 SG 자기참조가 필수)
• (선택) SSH 보안그룹 — login 노드 22, 신뢰 CIDR만
• (선택) S3 / ECR / CloudWatch / SSM VPC 엔드포인트 — NAT 데이터 처리 비용 절감

AWS 공식 레시피 aws-hpc-recipes/recipes/net/hpc_large_scale이 PCS 요구사항을 만족하는 VPC를 만들어 줍니다. CIDR만 아래 표에 맞춰 조정하십시오.

1-2. GPU 서브넷 사이징 — 노드당 17 IP

2-1. 계층 구조

2-2. 만들 때 지킬 것

• FSx for Lustre를 GPU 서브넷과 같은 AZ에 생성 (AZ 간 전송 비용·지연 회피)
• 파일시스템 보안그룹에 클러스터 SG 인바운드 허용 (Lustre 988, 1018–1023 / OpenZFS 111·2049·20001–20003)
• S3 버킷 생성 + Lustre DRA(Data Repository Association) 연동
• 마운트는 PCS가 대신 해주지 않습니다 PCS 차이 — Step 3의 lifecycle action mount-fsx.sh가 수행

3-1. AMI — PCS-ready DLAMI를 ID로 고정

# 최신 PCS-ready DLAMI (Deep Learning Base GPU AMI, Ubuntu 24.04 기반)
aws ssm get-parameter --region ap-northeast-2 \
  --name /aws/service/pcs/ami/dlami-base-ubuntu2404/x86_64/latest/ami-id \
  --query "Parameter.Value" --output text

# Description에 소스 DLAMI 날짜 / PCS Agent 버전 / 내장 Slurm 버전이 적혀 있음 — 기록해 두십시오
aws ec2 describe-images --region ap-northeast-2 --image-ids ami-xxxxxxxx \
  --query 'Images[0].[Name,Description,CreationDate]' --output table

3-2. Node lifecycle actions — user data 대신 이것을 쓰십시오

PCS Agent 1.5.0-1 이상에서 PCS가 지정 스테이지에 S3 스크립트를 내려받아 실행합니다(3회 재시도·백오프 내장, 스크립트별 로그). launch template user data보다 실패 처리와 관측이 훨씬 낫습니다.

3-3. 스크립트 목록 (S3 s3://${SCRIPT_BUCKET}/lifecycle/)

인스턴스 프로파일에 해당 버킷 s3:GetObject(+ s3:GetObjectVersion)와 CloudWatch Logs 쓰기 권한을 부여합니다.

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

3-4. 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)
lctl set_param llite.*.max_read_ahead_mb=1024
lctl set_param llite.*.statahead_max=512

디렉터리별 striping은 login 노드에서 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 오버헤드만 증가

클러스터는 컨트롤러입니다. 노드는 아직 없습니다. 여기서 정하는 것은 사이즈·버전·accounting·클러스터 레벨 Slurm 파라미터입니다.

aws pcs create-cluster --region ap-northeast-2 \
  --cluster-name llm-poc \
  --scheduler type=SLURM,version=26.05 \
  --size MEDIUM \
  --networking subnetIds=${CTRL_SUBNET_ID},securityGroupIds=${CLUSTER_SG_ID} \
  --slurm-configuration file://cluster-slurm.json

# 상태 확인 (CREATING → ACTIVE, 수 분~수십 분)
aws pcs get-cluster --region ap-northeast-2 --cluster-identifier llm-poc \
  --query 'cluster.[status,endpoints,slurmConfiguration.authKey]' --output json

cluster-slurm.json — 클러스터 레벨 Slurm 파라미터(허용 목록 항목만):

{
  "scaleDownIdleTimeInSeconds": 600,
  "accounting": { "mode": "STANDARD", "defaultPurgeTimeInDays": 180 },
  "slurmCustomSettings": [
    { "parameterName": "DefMemPerCPU",             "parameterValue": "40000" },
    { "parameterName": "PreemptType",              "parameterValue": "preempt/qos" },
    { "parameterName": "PreemptMode",              "parameterValue": "REQUEUE" },
    { "parameterName": "JobRequeue",               "parameterValue": "1" },
    { "parameterName": "PriorityWeightQOS",        "parameterValue": "10000" },
    { "parameterName": "PriorityWeightFairshare",  "parameterValue": "1000" },
    { "parameterName": "PriorityWeightAge",        "parameterValue": "100" },
    { "parameterName": "AccountingStorageEnforce", "parameterValue": "limits,qos" },
    { "parameterName": "AccountingStorageTRES",    "parameterValue": "cpu,mem,node,billing,gres/gpu" },
    { "parameterName": "HealthCheckProgram",       "parameterValue": "/opt/ops/health/periodic-check.sh" },
    { "parameterName": "HealthCheckInterval",      "parameterValue": "300" },
    { "parameterName": "HealthCheckNodeState",     "parameterValue": "IDLE" },
    { "parameterName": "Prolog",                   "parameterValue": "/opt/ops/health/prolog-gpu-quick.sh" },
    { "parameterName": "Epilog",                   "parameterValue": "/opt/ops/health/epilog-on-failure.sh" },
    { "parameterName": "PrologFlags",              "parameterValue": "Contain" }
  ]
}

PCS 차이 ParallelCluster의 Efa: Enabled: true에 해당하는 스위치가 PCS에는 없습니다. EC2 launch template에 17개 네트워크 인터페이스를 직접 정의하고, CNG가 그 템플릿을 참조합니다. 가장 빠른 길은 awslabs add-cng-p6-b300.yaml(p6-b300 전용 CloudFormation)을 그대로 쓰거나 그 launch template 부분을 가져오는 것입니다.

5-1. 규칙 — P5/P6-B200 템플릿을 복사하면 실패합니다

5-2. launch template 본문 (요지)

LaunchTemplateData:
  ImageId: ami-xxxxxxxx                    # Step 3에서 pin한 PCS-ready DLAMI / 커스텀 AMI
  IamInstanceProfile: { Arn: ${INSTANCE_PROFILE_ARN} }   # CNG의 --iam-instance-profile-arn과 동일
  BlockDeviceMappings:
    - DeviceName: /dev/sda1
      Ebs: { VolumeSize: 500, VolumeType: gp3, DeleteOnTermination: true }
  Placement:                                # ODCR/On-Demand 경로만. Capacity Block이면 이 블록 삭제
    GroupId: ${CLUSTER_PLACEMENT_GROUP_ID}
  CapacityReservationSpecification:        # ODCR
    CapacityReservationTarget: { CapacityReservationId: ${CR_ID} }
  # Capacity Block이면 위 블록 대신:
  #   InstanceMarketOptions: { MarketType: capacity-block }
  #   CapacityReservationSpecification: { CapacityReservationTarget: { CapacityReservationId: cr-xxxx } }
  MetadataOptions: { HttpTokens: required, HttpPutResponseHopLimit: 2 }
  NetworkInterfaces:
    # ---- card 0: ENA 전용 (InterfaceType 지정하지 않음). 일반 트래픽 SG는 여기에만 ----
    - DeviceIndex: 0
      NetworkCardIndex: 0
      SubnetId: ${GPU_SUBNET_ID}
      Groups: [${CLUSTER_SG_ID}, ${EFA_SG_ID}]
      DeleteOnTermination: true
    # ---- card 1~16: EFA. DeviceIndex는 전부 0 ----
    - DeviceIndex: 0
      NetworkCardIndex: 1
      InterfaceType: efa                   # efa-only 아님 (5-3)
      SubnetId: ${GPU_SUBNET_ID}
      Groups: [${EFA_SG_ID}]
      DeleteOnTermination: true
    # ... NetworkCardIndex 2 ~ 16 동일하게 반복 (총 16개) ...
  TagSpecifications:
    - ResourceType: instance
      Tags: [{ Key: Project, Value: llm-training }]

5-3. 반드시 지킬 것 5가지

1. InterfaceType: efa(efa-only 아님). awslabs 주석: "PCS requires InterfaceType: efa (not efa-only) to propagate the interface configuration to the launch instances request correctly." → 노드당 17 IP(Step 1).
2. SecurityGroupIds(템플릿 최상위)를 쓰지 마십시오. NetworkInterfaces를 정의한 템플릿에서는 각 인터페이스의 Groups로만 SG를 지정해야 합니다. 클러스터 SG는 primary에, EFA SG는 전부에.
3. pcs-<id>-do-not-delete 이름의 PCS 관리형 템플릿을 CNG에 지정하지 마십시오.
4. 템플릿 버전 추적. CNG를 version=1로 고정하면 이후 템플릿 수정이 노드에 반영되지 않습니다. CloudFormation이면 !GetAtt LaunchTemplate.LatestVersionNumber, CLI면 version='$Latest' 또는 수정 후 CNG 업데이트.
5. user data는 비워두거나 최소로. 부트스트랩 로직은 lifecycle actions(Step 3)로. 단 MIG 모드 전환처럼 재부팅이 필요한 것만 cloud-init boothook으로 여기에.

aws ec2 run-instances --region ap-northeast-2 --dry-run \
  --launch-template LaunchTemplateId=${LT_ID},Version='$Latest' \
  --instance-type p6-b300.48xlarge --count 1
# "DryRunOperation" = 템플릿·서브넷·SG·용량 예약 참조가 문법적으로 유효. "InvalidParameter..."면 배선 오류

6-1. Login CNG (PoC) — 본운영은 standalone 권장

aws pcs create-compute-node-group --region ap-northeast-2 \
  --cluster-identifier llm-poc \
  --compute-node-group-name login \
  --subnet-ids ${LOGIN_SUBNET_ID} \
  --custom-launch-template id=${LOGIN_LT_ID},version='$Latest' \
  --iam-instance-profile-arn ${INSTANCE_PROFILE_ARN} \
  --ami-id ${AMI_ID} \
  --scaling-configuration minInstanceCount=2,maxInstanceCount=2 \
  --instance-configs instanceType=m6i.4xlarge \
  --purchase-option ONDEMAND \
  --node-lifecycle-actions file://lifecycle-login.json

6-2. GPU CNG — 전량 static

aws pcs create-compute-node-group --region ap-northeast-2 \
  --cluster-identifier llm-poc \
  --compute-node-group-name gpu-b300-a \
  --subnet-ids ${GPU_SUBNET_ID}                     # ⚠ 단일 서브넷 = 단일 AZ \
  --custom-launch-template id=${GPU_LT_ID},version='$Latest' \
  --iam-instance-profile-arn ${INSTANCE_PROFILE_ARN} \
  --ami-id ${AMI_ID} \
  --scaling-configuration minInstanceCount=2,maxInstanceCount=2   # static. 2 → 16 → 64 \
  --instance-configs instanceType=p6-b300.48xlarge \
  --purchase-option ONDEMAND                       # Capacity Block이면 CAPACITY_BLOCK \
  --slurm-configuration 'slurmCustomSettings=[{parameterName=Features,parameterValue=b300},{parameterName=Weight,parameterValue=10}]' \
  --node-lifecycle-actions file://lifecycle-gpu.json

lifecycle-gpu.json (Step 3의 스크립트 목록을 그대로 옮긴 것):

{ "stages": {
  "nodeBootstrapped": [
    { "name": "Mount FSx",            "scriptSource": { "scriptLocation": "s3://${SCRIPT_BUCKET}/lifecycle/mount-fsx.sh" },
      "arguments": ["${FSX_ID}", "${FSX_MOUNT_NAME}", "${OPENZFS_DNS}"], "executionPolicy": "EVERY_BOOT", "onError": "TERMINATE" },
    { "name": "Local NVMe",           "scriptSource": { "scriptLocation": "s3://${SCRIPT_BUCKET}/lifecycle/local-nvme.sh" },
      "executionPolicy": "EVERY_BOOT", "onError": "TERMINATE" },
    { "name": "Node hardening",       "scriptSource": { "scriptLocation": "s3://${SCRIPT_BUCKET}/lifecycle/node-hardening.sh" },
      "executionPolicy": "FIRST_BOOT_ONLY", "onError": "CONTINUE" },
    { "name": "Install Enroot Pyxis", "scriptSource": { "scriptLocation": "s3://${SCRIPT_BUCKET}/lifecycle/install-enroot-pyxis.sh" },
      "executionPolicy": "FIRST_BOOT_ONLY", "onError": "TERMINATE" },
    { "name": "GPU healthcheck startup", "scriptSource": { "scriptLocation": "s3://${SCRIPT_BUCKET}/lifecycle/gpu-healthcheck-startup.sh" },
      "executionPolicy": "EVERY_BOOT", "onError": "TERMINATE" },
    { "name": "DCGM exporter",        "scriptSource": { "scriptLocation": "s3://${SCRIPT_BUCKET}/lifecycle/dcgm-exporter.sh" },
      "executionPolicy": "FIRST_BOOT_ONLY", "onError": "CONTINUE" },
    { "name": "CloudWatch logs",      "scriptSource": { "scriptLocation": "s3://${SCRIPT_BUCKET}/lifecycle/configure-cloudwatch-logs.sh" },
      "arguments": ["/aws/pcs/llm-poc"], "executionPolicy": "FIRST_BOOT_ONLY", "onError": "CONTINUE" }
  ],
  "nodeReady": [
    { "name": "Warmup srun",          "scriptSource": { "scriptLocation": "s3://${SCRIPT_BUCKET}/lifecycle/warmup-srun.sh" },
      "executionPolicy": "EVERY_BOOT", "onError": "CONTINUE" }
  ]
} }

6-3. Capacity Block 경로 — CNG를 블록 수만큼

# 블록 1 (최대 64대) → CNG gpu-b300-a, LT-A(cr-aaaa 참조)
aws pcs create-compute-node-group ... --compute-node-group-name gpu-b300-a \
  --custom-launch-template id=${LT_A},version='$Latest' \
  --scaling-configuration minInstanceCount=64,maxInstanceCount=64 \
  --purchase-option CAPACITY_BLOCK ...

# 블록 2 (61대) → CNG gpu-b300-b, LT-B(cr-bbbb 참조)
aws pcs create-compute-node-group ... --compute-node-group-name gpu-b300-b \
  --custom-launch-template id=${LT_B},version='$Latest' \
  --scaling-configuration minInstanceCount=61,maxInstanceCount=61 \
  --purchase-option CAPACITY_BLOCK ...

# 두 CNG를 하나의 큐에 매핑 → 사용자에게는 단일 파티션 (Step 7)

• 블록마다 launch template이 따로 필요합니다(CapacityReservationId가 다름).
• 블록이 scheduled여도 CNG를 만들 수 있고, active가 되면 노드가 올라옵니다. 상태가 payment-failed 등이면 사용 불가.
• min = max = 예약 수량으로 두십시오. 예약 창 전체가 과금되므로 0에서 올리면 유휴 시간이 낭비입니다.
• 만료 후 복구 = 새 블록을 참조하는 새 LT 버전으로 CNG 업데이트(운영 주의사항).

aws pcs list-compute-node-groups --region ap-northeast-2 --cluster-identifier llm-poc
aws pcs get-compute-node-group --region ap-northeast-2 --cluster-identifier llm-poc \
  --compute-node-group-identifier gpu-b300-a --query 'computeNodeGroup.[status,errorInfo]'
# 노드가 안 올라오면: EC2 콘솔 인스턴스 상태 → /var/log/amazon/pcs/ (SSM) → CloudWatch Logs(lifecycle)

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

7-2. 계정과 QoS 생성 (login 노드에서)

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

# 사용자 등록 (OS 계정이 먼저 존재해야 함 — SSSD/LDAP 또는 로컬)
sacctmgr --immediate add user name=alice 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  MaxWall=00:30:00
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 PreemptMode=REQUEUE Preempt=normal_qos,large_qos

# ★ 팀별 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

7-3. 큐 생성 — CNG 매핑 + 파티션 레벨 설정

# 두 CNG(gpu-b300-a, gpu-b300-b)를 하나의 파티션으로. Capacity Block 2블록이면 이렇게
for q in debug normal large exclusive; do :; done   # 아래 4개를 각각 생성

aws pcs create-queue --region ap-northeast-2 --cluster-identifier llm-poc \
  --queue-name normal \
  --compute-node-group-configurations computeNodeGroupId=${CNG_A_ID} computeNodeGroupId=${CNG_B_ID} \
  --slurm-configuration 'slurmCustomSettings=[
      {parameterName=AllowQos,     parameterValue=normal_qos},
      {parameterName=MaxTime,      parameterValue=1-00:00:00},
      {parameterName=PriorityTier, parameterValue=2},
      {parameterName=GraceTime,    parameterValue=600},
      {parameterName=Default,      parameterValue=YES}]'

aws pcs create-queue ... --queue-name debug     --compute-node-group-configurations computeNodeGroupId=${CNG_A_ID} \
  --slurm-configuration 'slurmCustomSettings=[{parameterName=AllowQos,parameterValue=debug_qos},{parameterName=MaxTime,parameterValue=00:30:00},{parameterName=PriorityTier,parameterValue=1},{parameterName=GraceTime,parameterValue=120}]'
aws pcs create-queue ... --queue-name large     --compute-node-group-configurations computeNodeGroupId=${CNG_A_ID} computeNodeGroupId=${CNG_B_ID} \
  --slurm-configuration 'slurmCustomSettings=[{parameterName=AllowQos,parameterValue=large_qos},{parameterName=MaxTime,parameterValue=7-00:00:00},{parameterName=PriorityTier,parameterValue=3},{parameterName=GraceTime,parameterValue=600}]'
aws pcs create-queue ... --queue-name exclusive --compute-node-group-configurations computeNodeGroupId=${CNG_A_ID} computeNodeGroupId=${CNG_B_ID} \
  --slurm-configuration 'slurmCustomSettings=[{parameterName=AllowQos,parameterValue=exclusive_qos},{parameterName=MaxTime,parameterValue=14-00:00:00},{parameterName=PriorityTier,parameterValue=10},{parameterName=PreemptMode,parameterValue=REQUEUE}]'

8-1. 5단계 배치

8-2. DRAIN된 노드는 어떻게 되돌리나 — 두 경로

8-3. job 내결함성 — KillWait를 바꿀 수 없다는 전제에서

• JobRequeue=1(클러스터) + sbatch --requeue로 제출. 프레임워크 특정 종료코드는 RequeueExit에 등록
• 선점 시 유예 = 큐 GraceTime=600(SIGTERM → SIGKILL 600초)
• 시간 초과·scancel 시 유예 = PCS 차이 KillWait(기본 30초)가 허용 목록에 없어 늘릴 수 없습니다. → 사용자 측 sbatch --signal=B:USR1@600으로 종료 600초 전 시그널을 받아 체크포인트를 저장하고 스스로 종료하는 것이 유일한 수단입니다. 학습 스크립트 템플릿에 기본 포함시키십시오
• UnkillableStepTimeout은 허용 목록에 있지만 체크포인트와 무관합니다(SIGKILL 후에도 죽지 않는 프로세스를 이상 판정하기까지의 대기시간). 공개 예제의 "체크포인트 시간 확보" 설명은 오해입니다

8-4. 스크립트 골격

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

# node-hardening.sh (nodeBootstrapped, FIRST_BOOT_ONLY)
#!/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-pcs-slurm.conf
fi
if mountpoint -q /fsx; then bash /opt/ops/health/lustre-tuning.sh || true; fi

# prolog-gpu-quick.sh — 수 초 이내. GPU/EFA 결함만 실패(exit 1). GPU 없는 노드(login)는 즉시 통과
#!/bin/bash
command -v nvidia-smi >/dev/null 2>&1 || exit 0
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
command -v dcgmi >/dev/null 2>&1 || exit 0
[ "${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"
  # 하드 결함 자동 교체를 택했다면: aws ec2 terminate-instances --instance-ids $(ec2-metadata -i | cut -d' ' -f2)
fi
exit 0

# periodic-check.sh (HealthCheckProgram, IDLE 노드에서 5분마다) — 가볍게
#!/bin/bash
command -v nvidia-smi >/dev/null 2>&1 || exit 0
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 (nodeBootstrapped, EVERY_BOOT, TERMINATE) — job 없음, 수 분 허용. exit≠0 → 노드 종료·교체
#!/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 2
# 또는 awslabs 스위트: /opt/ops/health/gpu-cluster-healthcheck/run-lightweight.sh

9-1. 인프라 기본 (login 노드에서)

sinfo -N -l
scontrol show nodes | grep -E 'NodeName|State|CfgTRES|Gres|Sockets|CPUTot'
# 기대: CPUTot=96 (SMT 비활성), Gres=gpu:8, State=idle

scontrol show partition | grep -E 'PartitionName|Default|AllowQos|GraceTime|MaxTime'
# 기대: normal이 Default=YES, 각 큐에 AllowQos

# GPU 인식 — 8개
srun -p normal -N1 --gres=gpu:8 --cpus-per-task=12 nvidia-smi

# EFA 열거 — 16 디바이스
srun -p normal -N1 fi_info -p efa | grep -c domain
srun -p normal -N1 ls /sys/class/infiniband/

# 스토리지 · lifecycle 로그
df -h /fsx /home /opt/dlami/nvme
lfs df -h /fsx
srun -p normal -N1 ls /var/log/amazon/pcs/lifecycle/actions/nodeBootstrapped/

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

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

# 2노드 / 16 GPU all_reduce (awslabs nccl-tests-container.sbatch 참고)
srun -p normal -N2 --ntasks-per-node=8 --gres=gpu:8 --cpus-per-task=12 \
  --container-image=/fsx/containers/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가 메시지 크기에 따라 증가하고 대형 메시지에서 포화. Grafana EFA 대시보드에서 16 디바이스 모두 트래픽

9-3. 스토리지 성능

• Lustre 튜닝 적용 전/후 순차 쓰기 처리량 비교
• 실제 체크포인트 저장 1회 소요시간 측정 → Capacity Block 종료 시각(KST 20:00) 계획에 사용
• 로컬 NVMe 캐시 적용 시 데이터 로딩 시간 변화
• 노드 부팅 → idle까지 소요시간 (DLAMI+lifecycle vs pre-bake) → 125노드 기동 시간 외삽

9-4. 장애 리허설 필수 — MTTR을 숫자로

9-5. 멀티유저

• GrpTRES=gres/gpu=N 초과 제출이 실제로 거부되는지
• MaxJobsPerUser 초과 제출이 막히는지
• exclusive_qos job이 normal job을 실제로 preempt(requeue)하고 GraceTime이 지켜지는지
• 미등록 사용자의 제출이 거부되는지 (그리고 에러 메시지가 무엇인지 — 운영 FAQ에 기록)
• sacct -a -S <date> -E now 로 사용자별 집계가 나오는지

10-1. 노드 수 확장

# ODCR/On-Demand 경로: min/max만 올림 (fleet 정지 불필요)
aws pcs update-compute-node-group --region ap-northeast-2 --cluster-identifier llm-poc \
  --compute-node-group-identifier gpu-b300-a \
  --scaling-configuration minInstanceCount=16,maxInstanceCount=16

# Capacity Block 경로: 블록마다 CNG 추가 → 기존 큐에 매핑 추가
aws pcs create-compute-node-group ... --compute-node-group-name gpu-b300-b --purchase-option CAPACITY_BLOCK ...
aws pcs update-queue --region ap-northeast-2 --cluster-identifier llm-poc --queue-name normal \
  --compute-node-group-configurations computeNodeGroupId=${CNG_A_ID} computeNodeGroupId=${CNG_B_ID}

10-2. Slurm 버전 업그레이드 — 클러스터 재생성 없음 PCS 차이

aws pcs update-cluster --region ap-northeast-2 --cluster-identifier llm-poc \
  --scheduler type=SLURM,version=26.05 \
  --client-token $(uuidgen)

• 업그레이드 중 컨트롤러 일시 중단: 신규 제출·스케줄러 명령·자동 스케일링 정지, 실행 중 job은 계속(Option 1). accounting 데이터 보존
• 한 번에 3개 메이저 버전 이상 건너뛰기 불가. 패치 버전은 PCS가 자동 적용
• EOL 후에는 신규 클러스터 생성 불가, 기존 클러스터는 최대 12개월 무보증 운영. 25.05는 2026-11-30 EOL
• DLAMI는 지원 Slurm 버전을 다중 내장하므로 컨트롤러 업그레이드 시 노드 AMI 교체가 필수는 아니지만, EOL 근접 AMI는 pin을 갱신하십시오