사례9건

9건 중 7~9번째

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-0525 Equinix 암스테르담 전원 점검 중 업링크가 하나뿐인 스위치가 꺼져 OpenStreetMap.org 가 7시간 27분 멈춤

   OpenStreetMap Foundation2022

   증상

   2022년 6월 11일 20:18 UTC 부터 OpenStreetMap.org 에 접속할 수 없었다. Equinix 가 암스테르담 데이터센터 AM6 의 전원 A 계통 점검을 시작하고 18분 뒤였고, 암스테르담에 있는 www, API, wiki, planet 서비스가 모두 인터넷과 끊겼다.

   네트워크 도달 불가서비스 중단

   촉발

   2022년 6월 11일 20:00 UTC 에 Equinix 가 암스테르담의 OpenStreetMap 서버에 전원을 대는 전원 A 계통의 5년 주기 점검을 시작했다.

   원인

   하드웨어 고장

   구성 요소

   네트워크 스위치데이터센터 전력·냉각

   기여 요인

   단일 장애점디버그 접근 제한모니터링 사각지대

   조치

   • 운영 팀은 더블린으로 페일오버하거나 업링크를 Switch-2 로 옮기지 않고 Equinix 전원 점검 시간이 끝날 때까지 기다렸다. 장애는 6월 12일 03:45 UTC 에 끝났다.

   후속 조치

   • 진행 중인 장애를 알리는 데 걸리는 시간을 줄인다. 장애 알림은 https://twitter.com/OSM_Tech 로 낸다.
   • 스위치의 PSU 와 팬 상태를 모니터링하고 알림을 건다.
   • Cisco SG550X-48 스위치 Switch-1, Switch-2 와 Cisco Redundant Power System 을 이중 전원을 갖춘 Juniper EX4300 스위치로 바꾼다. 부품 공급 부족으로 설치가 늦어졌고, 2022년 7월 19일 기준 모든 부품이 현장에 도착해 설치를 기다린다.
   • 이중 전원을 받는 대역 외 접속 장비인 4G 모뎀 시리얼 콘솔 서버를 암스테르담에 둔다. 2022년 6월 20~22일 현장 방문 때 설치를 마쳤다.
   • 이중 업링크를 설치한다. 2022년 7월 19일 기준 아직 설치되지 않아 운영 팀이 계속 챙기고 있다.
   • 지금은 실수하기 쉬운 수동 절차인 사이트 페일오버를 더 쉽고, 손이 덜 가고, 덜 위험하게 만든다.
   • 운영 SRE 를 위한 당번 호출 시스템을 들인다. 2022년 7월 19일 기준 업체와 협상 중이다.
   • 한 사람이 24시간 내내 당번을 설 수 없으므로 장기적으로 SRE 팀을 늘린다.
   • 전원, 네트워크, 상위 링크, 서비스 장애에 대비한 장비 페일오버 시험을 계속하고 정식 절차로 만든다.

   사례 보기
3. 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