사례2건

2건 중 1~2번째

1. IL-0381 Newark 의 Linode Object Storage 가 두 번 느려지고 일부 요청이 504 gateway timeout 으로 실패했다

   Linode2022

   증상

   10월 10일부터 16일까지 한 주 동안 Newark 의 Linode Object Storage 에서 성능과 가용성이 떨어지는 장애가 두 번 났다. 일부 경우에는 프런트엔드 게이트웨이가 고객에게 504 gateway timeout 으로 응답했다.

   간헐적 타임아웃처리량 저하

   촉발

   백엔드 Object Storage 노드 하나에 하드웨어 문제가 생겼다. 완전한 고장이 아니어서 그 백엔드 인프라가 올라왔다 내려가기를 반복했다.

   원인

   하드웨어 고장

   구성 요소

   오브젝트 스토리지

   기여 요인

   모니터링 사각지대자동화 증폭

   조치

   • 10월 16일 10:31 UTC 에 완전히 고장 난 백엔드 Object Storage 인프라를 클러스터에서 뺐다. 그 뒤 클러스터가 회복하고 프런트엔드 게이트웨이가 정상으로 요청을 처리했다.

   후속 조치

   • 고장 나고 있거나 이상하게 동작하는 하드웨어의 미묘한 문제를 클러스터 전체에 번지기 전에 빨리 찾아 분류하도록 탐지 방법을 개선한다.
   • Ceph 관련 이벤트를 당직 관리자에게 더 정확히 설명하도록 모니터링을 바꿨다. 관리자가 문제를 더 빨리 좁힐 수 있게 알림도 더 분명히 정의했다.

   교훈

   Linode 는 이 장애로 내부 모니터링 시스템의 빈틈이 드러났다고 적었다. 완전히 고장 나지 않고 이상하게 동작하는 하드웨어의 미묘한 문제는 클러스터 전체에 번지기 전에 찾아내야 한다고 봤다.

   사례 보기
2. IL-0427 tr1-13B 학습이 고장 난 GPU 가 있는 노드에서 연달아 두 번 죽었다

   BigScience2021

   증상

   tr1-13B 학습이 여러 시간 돌다가 iteration 43680 에서 죽었고, Slurm 이 이어서 띄운 다음 작업도 시작하자마자 죽었다.

   학습 작업 실패GPU 인식 불가

   촉발

   학습에 배정된 노드 하나의 GPU 에 하드웨어 문제가 생겨 정정할 수 없는 ECC 오류가 났다.

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리Slurm 작업 스케줄러

   기여 요인

   자동화 증폭모니터링 사각지대

   감지

   첫 충돌 때는 아무도 지켜보지 않았고, 스케줄러가 띄운 다음 작업도 죽은 뒤에야 문제를 알았다. 팀은 두 번의 실패를 보고 GPU 하드웨어 문제를 의심했고, JZ 관리자에게 물어 노드 하나가 고장 난 것을 확인했다.

   조치

   • JZ 관리자에게 연락해 노드 하나가 고장 난 것을 확인했다.
   • 다음 학습 작업이 고장 난 노드에 배정되지 않아 학습이 이어졌다.

   후속 조치

   • `#SBATCH --output=%x-%j-%N.out` 처럼 출력 파일 이름에 `%N` 을 넣어 노드마다 로그 파일을 따로 남기고, 그 로그로 어느 노드의 GPU 가 고장인지 가린다.
   • 고장 난 노드의 호스트 이름을 알아내면 `sbatch --exclude=node1,node2,... ` 로 다음 작업에서 그 노드를 뺀다.

   교훈

   예외가 난 노드의 호스트 이름을 알 수 없으면, 다음 작업이 고장 난 노드에 다시 배정돼 학습이 거듭 죽는다. 호스트 이름을 알면 `sbatch --exclude` 로 그 노드를 뺄 수 있으므로, 예외와 노드를 이어 주는 수단이 꼭 있어야 한다.

   사례 보기

원인별1