Incident Library

IL-0537 Sakura Internet · 2012-06-25 (게시일)networkingdatabase

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

사쿠라인터넷은 2011년 11월 15일 사쿠라 클라우드를 정식으로 출시했다. 12월 중순부터 호스트 서버와 스토리지 장치 사이의 트래픽이 늘면서 둘 사이의 네트워크 연결이 끊기는 문제가 났다. 2011년 12월 9일의 첫 장애부터 2012년 3월 말까지 스토리지 장애가 간헐적으로 이어졌고, 이 연결 끊김은 그 원인 가운데 하나였다.

첫째 원인은 네트워크 인터페이스의 이중화 감시였다. 스토리지 장치의 네트워크 인터페이스는 두 포트로 이중화돼 있었고, ICMP 로 운영 포트를 감시했다. 12월 초부터 간헐적인 패킷 손실 때문에 감시 장치가 ICMP 가 일정 시간 끊겼다고 판정하고 예비 포트로 전환했다. 전환할 때마다 호스트와 스토리지 장치 사이의 통신이 5분 정도 끊겼다. 조사해 보니 인터페이스는 고장 나지 않았고 접근량이 늘어 패킷을 잃고 있었다. 사쿠라인터넷은 1월 초 감시 방식을 ICMP 에서 LINK 상태 확인으로 바꿔 물리적으로 링크가 내려갔을 때만 예비 포트로 바뀌게 했고, 이로써 이중화 구성의 문제는 사라졌다. 패킷 손실 자체는 3월 19일 스토리지 장치 펌웨어 업데이트로 없어졌다.

둘째 원인은 InfiniBand 의 Subnet Manager 였다. 12월 하순부터 스토리지 장치의 네트워크 인터페이스가 Subnet Manager 의 생존 확인에 응답하지 않아 장치가 네트워크에서 떨어졌다고 판단되는 일이 몇 번 났다. 인터페이스에 물리적인 이상이 없었으므로, 사쿠라인터넷은 1월 초 보통 모드의 확인 방식이 부족하다고 보고 heavy sweep 모드로 바꿔 문제를 없앴다. 3월 12일에는 두 번째 스토리지 장치를 더해 사용자 서버를 옮기며 부하를 나눴다. 첫 번째 스토리지도 부하가 줄면서 안정됐고, 4월 이후로는 디스크 연결이 끊기는 장애가 나지 않았다. 사쿠라인터넷은 끝내 기존 스토리지를 자체 개발한 전혀 다른 스토리지 장치로 바꾸기로 했다.

심각도
–
영향 범위
Storage access of Sakura Cloud users' servers, cut for about five minutes at each interface switchover, and also at each Subnet Manager cut-off
영향 사용자
Sakura Cloud users
지역
–
감지까지
–
복구까지
–

증상

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

스토리지 장치의 네트워크 인터페이스는 포트 두 개로 이중화돼 있었다. 감시 장치는 운영 포트를 ICMP, 곧 ping 으로 감시하다가 응답이 일정 시간 끊기면 고장으로 보고 예비 포트로 바꿨다. 12월 초부터 이 인터페이스에서 패킷 손실이 간헐적으로 났고, 감시 장치가 ICMP 가 일정 시간 끊겼다고 판정해 예비 포트로 전환했다. 이 전환 때문에 호스트와 스토리지 장치 사이의 통신이 5분 정도 끊겼다.

12월 하순부터는 이와 다른 이유로 스토리지 장치에 접근하지 못하는 장애가 몇 번 났다. 스토리지 네트워크는 InfiniBand 를 쓴다. InfiniBand 네트워크에는 장치 사이의 연결을 관리하는 Subnet Manager, 줄여서 SM 이 필요하다. 스토리지 장치의 네트워크 인터페이스가 SM 의 생존 확인에 응답하지 않자 SM 이 장치가 네트워크에서 떨어졌다고 판단해 네트워크가 끊겼다. 인터페이스에 물리적인 이상은 보이지 않았다.

처음에는 네트워크 인터페이스가 고장 난 것으로 판정됐다. 조사해 보니 인터페이스는 고장 나지 않았고, 접근량이 늘어서 패킷을 잃고 있었다. 감시 방식을 바꾼 뒤에도 패킷 손실 자체는 남아 있었고, 이를 없애는 데 3월 19일 펌웨어 업데이트까지 석 달이 걸렸다.

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

원인

원인 용량 한계

구성 요소 클라우드 블록 스토리지InfiniBand 패브릭
기여 요인 자동화 증폭스테이징 불일치디버그 접근 제한
촉발
2011년 11월 15일 서비스를 시작한 뒤 12월 중순부터 호스트 서버와 스토리지 장치 사이의 트래픽이 늘었고, 스토리지 장치의 네트워크 인터페이스에서 패킷 손실이 나기 시작했다.

감지

–

조치

후속 조치

교훈

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

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 클라우드 블록 스토리지, InfiniBand 패브릭. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.