사례12건

12건 중 10~12번째

1. IL-0266 eqiad 코어 라우터 두 대 사이에 라우팅 루프가 생겨 eqiad 가 다른 데이터센터의 공인 IP 주소에 닿지 못했다

   Wikimedia Foundation2021

   증상

   09시 39분에 알림이 울렸다. 첫 알림은 eqiad 의 Icinga 가 싱가포르 eqsin 의 공인 text-lb 주소에 닿지 못해서 울렸다.

   네트워크 도달 불가

   촉발

   09시 37분쯤 cr1-eqiad 와 cr2-eqiad 에서 BGP 경로 선택에 영향을 주려고 BGP 설정 하나를 뺐다. 이 설정은 BGP "MED" 속성 값을 BGP 경로의 다음 홉까지 가는 OSPF 비용으로 정했다. 설정을 뺀 것은 T295672 작업의 일부였다.

   원인

   설정 변경

   구성 요소

   BGP 라우팅

   기여 요인

   롤백 무효

   감지

   09시 39분에 알림이 울렸다. eqiad 의 Icinga 가 eqsin 같은 엣지 캐시 클러스터를 상태 검사하다가 eqsin 의 공인 text-lb 주소에 닿지 못했다.

   조치

   • 09시 42분 cr1-eqiad 와 cr2-eqiad 두 장비에서 설정 변경을 되돌렸다. 정책이 바뀔 때 경로가 갱신되는 방식 때문에 이것만으로는 바로 풀리지 않았다.
   • 09시 51분 eqiad 라우터 사이의 BGP 세션을 강제로 재설정했고, 문제가 풀렸다.

   후속 조치

   • T295672 티켓에 사고 내용을 더 자세히 적고, "second IXP port" 문제를 다루면서 같은 일이 다시 나지 않도록 BGP 세션을 조정하자는 제안을 올렸다.

   사례 보기
2. IL-0323 s3 주 데이터베이스 마스터 db1075 가 완전히 멈춰 s3 위키 전체가 읽기 전용이 됐다

   Wikimedia Foundation2019

   증상

   s3 의 주 데이터베이스 마스터 db1075 가 응답하지 않아 s3 의 모든 위키가 쓰기를 받지 못하고 읽기 전용이 됐다. 레플리카는 모두 살아 있어 읽기는 정상이었다. Icinga 가 IRC 에 HOST DOWN 을 알렸고 사용자들이 #wikimedia-operations 에 문제를 알렸다.

   쓰기 거부복제 지연지연 시간 증가

   촉발

   db1075 의 RAID 백업 배터리인 BBU 가 고장 나면서 호스트가 완전히 멈췄다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   온콜 호출 미전달수동 조치 악화

   감지

   db1075 의 HOST DOWN 이 보고되면서 문제가 분명해졌다. 하지만 HOST DOWN 알림은 IRC 로만 가고 호출을 보내지 않았다. 알림은 IRC 와 호출로 보내졌고, 첫 SMS 호출은 18:56 UTC 에 나갔다. 사용자들도 #wikimedia-operations 에 문제를 알렸고, 자원봉사자와 직원은 알림보다 먼저 장애를 알아챘다.

   조치

   • BBU 문제이고 호스트가 응답하지 않는 것을 확인한 뒤 19:02 UTC 에 idrac 으로 호스트를 재부팅했다.
   • MySQL 이 19:03 에 InnoDB 복구를 시작해 19:06 에 마쳤다.
   • 19:07 에 db1075 의 read_only=ON 을 직접 풀었다.
   • 19:16 에 puppet 을 다시 직접 돌려 성공했고, pt-heartbeat 가 시작되면서 장애가 끝났다.

   후속 조치

   • 마스터를 쓸 수 없을 때 레플리카를 옮기는 스크립트를 만들거나 고친다. 이번에는 필요하지 않았지만 앞으로의 장애에서는 필요할 수 있다.
   • MediaWiki 의 heartbeat 방식을 고친다. pt-heartbeat 가 슈퍼유저를 쓰지 않게 하고, 단일 장애점을 없애고, puppet 없이 실제 마스터로 자동 전환되게 한다.
   • 이미 BBU 문제를 겪은 같은 배치의 호스트들을 어떻게 할지 정한다.
   • db1075 에 쓸 새 BBU 를 산다.
   • db1075 를 마스터에서 뺀다.
   • 읽기 전용이거나 마스터를 쓸 수 없는 동안 MediaWiki 가 쏟아내는 스팸을 해결한다.
   • 주 데이터베이스 마스터가 HOST DOWN 일 때 호출이 가게 한다.
   • Netbox 에서 하드웨어 오류를 더 잘 추적한다.

   교훈

   BBU 고장이 호스트 전체를 멈추게 해서는 안 됐지만 HP 호스트에서는 전에도 그런 일이 있었다. puppet 으로 띄우는 pt-heartbeat 와 아직 다 뜨지 않은 MySQL 사이의 경합으로 수동 puppet 실행이 실패했는데 아무도 알아채지 못했다. 그 때문에 모든 것이 올라온 뒤에도 복제 지연이 보고돼 장애가 8분 더 길어졌다. 알림은 잘 동작했고 idrac 으로 재부팅한 것도 통했다. 호스트가 깨끗하게 돌아오지 않았다면 새 레플리카를 마스터로 올리는 장애 조치를 손으로 해야 했다.

   사례 보기
3. IL-0458 Toolforge 쿠버네티스 API 서버가 재시작 뒤 올라오지 못해 몇 시간 동안 클러스터 전체가 멈췄다

   Wikimedia Foundation2019

   증상

   18:45 에 toolschecker 의 icinga 검사 "All k8s nodes healthy" 가 알림을 울렸다. 쿠버네티스 API 서버가 응답하지 않아 모니터링에서도 사용자 쪽에서도 클러스터가 완전히 내려간 것처럼 보였다. 사용자는 webservice 명령으로 도구를 띄울 수 없었고 kubectl 로 상태를 보거나 도구를 다룰 수도 없었다.

   컨트롤 플레인 무응답서비스 중단TLS 인증서 오류

   촉발

   18:30 에 maintain-kubeusers 프로세스가 쿠버네티스 API 서버를 재시작했다. 재시작한 API 서버는 etcd 에 다시 연결해야 했는데, 전날 밤 퍼핏 변경으로 CA 인증서가 etcd 서버의 것과 어긋나 있어 연결하지 못했다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버etcd구성 관리 도구

   기여 요인

   늦게 드러난 변경수동 조치 악화런북 부재

   감지

   처음 울린 것은 http://checker.tools.wmflabs.org/k8s/nodes/ready 를 검사하는 icinga 알림이었다. 18:45 에 toolschecker 의 "All k8s nodes healthy" 검사가 울렸다.

   조치

   • 19:10 과 20:30 에 쿠버네티스 마스터를, 20:18 에 etcd 클러스터를 재부팅했지만 도움이 되지 않았다.
   • 21:06 에 백업을 떠 둔 뒤 잦은 raft 선출을 원인에서 빼려고 etcd 클러스터를 노드 하나로 줄였다.
   • 노드를 다시 넣다 클러스터가 무너진 뒤 여러 시도 끝에 백업에서 etcd 전체 재해 복구를 해 00:25 쯤 etcd 를 원래 용량으로 되돌렸다.
   • 01:28 에 API 서버가 쓰는 CA 를 etcd 서버의 CA 로 바꿨고, 통신과 서비스가 돌아왔다. 퍼핏이 곧 이 변경을 되돌렸다.
   • 01:43 에 etcd 퍼핏 CA 인증서를 /var/lib/puppet/client/ssl/certs/ca.pem 에 두었고, 퍼핏이 이 인증서를 가져가 장애가 안정적으로 끝났다.

   후속 조치

   • etcd 클러스터 운영 절차를 문서로 남긴다. 작업 번호는 T232769 다.
   • Toolforge 쿠버네티스 업그레이드로 etcd 와 쿠버네티스의 오류 보고를 개선하고, 도구를 추가할 때 API 서버를 재시작하지 않아도 되게 한다. 작업 번호는 T214513 이다.
   • kube2proxy 가 API 서버 장애를 더 잘 견디게 만들어 본다. 작업 번호는 T232770 이다.
   • 퍼핏 CA 인증서를 점검한다. tools 프로젝트 안에 CA 인증서가 둘 이상 있어서는 안 된다. 작업 번호는 T232772 다.
   • 쿠버네티스 컨트롤 플레인을 고가용성으로 만든다. 작업 번호는 T142862 다.

   교훈

   etcd 처럼 원래 말썽이 잦은 구성 요소가 해법 찾기를 헷갈리게 했다. 퍼핏 인증서는 위험하다. 아주 오래된 쿠버네티스 버전은 로그에 남기는 오류 메시지가 형편없다. 팀은 CA 인증서가 아니라 etcd 를 고치려다 상황을 더 나쁘게 만들었다. 문제는 API 서버를 재시작할 때에야 드러났다. etcd 클러스터에는 문서화되지 않은 오래된 특이점이 있었고, etcd 재해 복구와 노드 교체 절차는 문서로 남아 있지 않았다. 이 셋이 겹쳐 해법을 찾는 데 오래 걸렸다. 교차 교육이 있었다면 도움이 됐을 수 있지만, 이번 일은 어차피 여럿이 함께 풀어야 했다.

   사례 보기

원인별7