사례2건

2건 중 1~2번째

1. IL-0127 Llama 3 405B 사전 학습 54일 동안 학습 작업이 예기치 않게 419번 중단되었고, 주된 원인은 GPU 와 HBM3 메모리 고장이었다

   Meta2024

   증상

   Meta 는 최대 16K 개의 H100 GPU 로 Llama 3 405B 를 사전 학습했다. 54일 동안의 기록에서 학습 작업은 모두 466번 중단되었고, 그중 419번이 예기치 않은 중단이었다. 나머지 47번은 펌웨어 업그레이드 같은 자동 유지보수나, 설정과 데이터셋 갱신 같은 운영자 작업에 따른 계획된 중단이었다.

   학습 작업 실패GPU 인식 불가NCCL 타임아웃

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리NCCLPyTorch

   기여 요인

   단일 장애점

   감지

   PyTorch 의 NCCL flight recorder 가 모든 통신 이벤트와 집합 연산마다 걸린 시간을 링 버퍼에 기록했고, NCCLX 워치독이나 하트비트 타임아웃이 나면 추적 데이터를 자동으로 덤프했다. NCCLX 는 통신 라이브러리 상태를 감시하다가 멈춤을 감지하면 자동으로 타임아웃시켰고, 실패한 집합 연산의 내부 상태 스냅샷을 남겼다. 느린 GPU 는 의심스러운 통신에 우선순위를 매겨 보여 주는 도구로 찾았다. 대개 상위 몇 개만 조사해도 찾아낼 수 있었다.

   조치

   • 대부분의 중단은 자동화가 처리했고, 사람이 크게 손을 대야 했던 것은 54일 동안 세 번뿐이었다.

   후속 조치

   • 작업 시작 시간과 체크포인트 시간을 줄였다.
   • PyTorch 의 NCCL flight recorder 로 모든 통신 이벤트와 집합 연산 시간을 기록하고, NCCLX 워치독이나 하트비트 타임아웃이 나면 추적 데이터를 자동으로 덤프하게 했다.
   • 계산이 많이 드는 추적과 메타데이터 수집은 운영 중에 필요할 때만 켜게 했다. 켜고 끄는 일은 코드를 배포하거나 작업을 재시작하지 않고 온라인 설정 변경으로 하게 했다.
   • PyTorch 가 NCCLX 의 내부 상태에 접근하게 해 멈춤을 더 빨리 감지하고 멈춘 위치를 찾게 했다. 실패한 집합 연산의 끝난 전송과 남은 전송은 스냅샷으로 남기게 했다.

   교훈

   동기식 학습은 GPU 하나의 고장에도 작업 전체가 멈출 수 있어 고장에 약하다. 하드웨어 고장은 멈춤으로만 나타나지 않고 느린 straggler 로도 나타나며, straggler 하나가 GPU 수천 개를 느리게 만들 수 있다. 이 규모에서는 기온과 전력망 같은 환경 요인도 학습 성능과 운영에 영향을 준다.

   사례 보기
2. IL-0185 Kubespray 로 만든 클러스터의 첫 번째 control plane 노드 디스크가 I/O 오류로 읽기 전용이 되면서 노드가 죽었다

   Hans H. Kim2023

   증상

   Kubernetes 클러스터의 master 노드에서 디스크 장애가 났다. 커널 로그에 "[HAWKEYE] kernel:: [22329228.540857] blk_update_request: I/O error, dev sda, sector 795030104 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0, at" 오류가 찍혔다.

   노드 NotReady

   촉발

   하드웨어 장애로 master 1번 노드의 sda 디스크에 I/O 오류가 나고 읽기 전용 상태가 됐다.

   원인

   하드웨어 고장

   구성 요소

   Kubesprayetcd노드 루트 디스크컨피그맵과 시크릿

   기여 요인

   단일 장애점

   감지

   커널 로그에 sda 디스크의 blk_update_request I/O 오류가 찍히면서 디스크 장애를 알았다.

   조치

   • Kubespray inventory 의 kube_control_plane 순서를 바꿔 node-2 가 첫 번째 control plane 노드가 되게 했다.
   • 하드웨어 장애가 난 1번 장비를 클러스터에서 제거했다.
   • kubectl edit cm -n kube-public cluster-info 로 cluster-info ConfigMap 의 옛 control plane IP 를 살아 있는 장비의 IP 로 바꾸고 certificate-authority-data 값도 바꿨다.
   • 새 노드에 kubelet 을 비롯한 컴포넌트를 설치하고 kubeadm join --control-plane --skip-phases control-plane-join/etcd 로 control plane 노드를 추가했다.
   • etcd 노드를 따로 추가했다.

   교훈

   Kubespray 는 첫 번째 control plane 노드에 특별한 권한을 주기 때문에, master 세 대로 HA 를 구성해도 1번 노드의 장애 복구는 매우 까다롭다. 복구하려면 inventory 순서를 바꿔 1번 역할부터 다른 노드로 넘겨야 한다. control plane 노드가 죽으면 etcd 쿼럼이 위험해지므로 다른 노드가 더 망가지기 전에 etcd 를 되살려야 한다.

   사례 보기

원인별1