사례1건

1건 중 1~1번째

1. IL-0537 사쿠라 클라우드의 호스트 서버와 스토리지 장치 사이 연결이 몇 달 동안 되풀이해 끊겼다

   Sakura Internet2012

   증상

   사쿠라 클라우드에서 사용자 서버를 수용한 호스트 서버와 스토리지 장치 사이의 통신이 되풀이해 끊겼다. 포트 전환 때문에 끊길 때는 한 번에 5분 정도 끊겼다. 이 끊김은 2011년 12월부터 간헐적으로 되풀이됐다.

   스토리지 연결 끊김패킷 손실

   촉발

   2011년 11월 15일 서비스를 시작한 뒤 12월 중순부터 호스트 서버와 스토리지 장치 사이의 트래픽이 늘었고, 스토리지 장치의 네트워크 인터페이스에서 패킷 손실이 나기 시작했다.

   원인

   용량 한계

   구성 요소

   클라우드 블록 스토리지InfiniBand 패브릭

   기여 요인

   자동화 증폭스테이징 불일치디버그 접근 제한

   조치

   • 1월 초 스토리지 장치 네트워크 인터페이스의 감시 방식을 ICMP 에서 LINK 상태 확인으로 바꿔, 물리적으로 링크가 내려갔을 때만 예비 포트로 전환되게 했다.
   • 1월 초 Subnet Manager 의 확인 방식을 보통 모드에서 heavy sweep 모드로 바꿔 스토리지 장치가 네트워크에서 떨어지는 문제를 없앴다.
   • 3월 19일 스토리지 장치의 펌웨어를 업데이트해 장치의 패킷 손실을 없앴다.
   • 스토리지 부하를 줄이려고 3월 12일 두 번째 스토리지 장치를 더했고, 옮길 수 있는 서버를 두 번째 장치로 옮겨 부하를 나눴다.

   후속 조치

   • 기존 스토리지를 자체 개발한 전혀 다른 새 스토리지 장치로 바꾼다.
   • 새 스토리지는 장치의 최대 수용 대수에 맞는 테스트 환경을 준비해 실제로 부하를 걸어 시험했다. 유료 정식 서비스 전에 다시 무료 베타 테스트 기간을 두고, 사용자가 만족할 때까지 시험을 되풀이한다.
   • 새 스토리지의 네트워크 인터페이스 드라이버 같은 부품은 지금까지 운영에서 문제가 없던 호스트 서버와 같은 것을 썼다.
   • 새 스토리지는 사쿠라인터넷이 직접 관리하고 운영할 수 있도록 자사 엔지니어가 개발했다.

   교훈

   사쿠라인터넷은 스토리지 장치의 선정과 검증 과정에 큰 문제가 있었다고 돌아봤다. 검증 때는 설계 사양에 맞는 최대 수용 대수만큼 서버를 준비하지 못하고, 예측으로 만든 부하로 성능을 확인했다. 그래서 성능 한계에서 하는 시험이 부족했고, 실제 운영에서 난 문제에 빠르고 정확하게 대응하지 못했다. InfiniBand 포트의 패킷 손실은 펌웨어 업데이트로 풀렸지만 대응을 마치기까지 석 달이 걸렸다. 자사 엔지니어가 스토리지 장치의 사양과 동작을 다 파악하지 못해서, 제조사와 긴밀히 협력했어도 조사와 확인에 오랜 시간이 걸렸다.

   사례 보기

원인별1