{"id":"IL-0537","org":"Sakura Internet","date":"2012-06-25","docs":[],"title":{"en":"Sakura Cloud host servers repeatedly lost their storage connection, about five minutes per port switchover","ko":"사쿠라 클라우드의 호스트 서버와 스토리지 장치 사이 연결이 몇 달 동안 되풀이해 끊겼다"},"domain":["networking","database"],"impact":{"scope":"Storage access of Sakura Cloud users' servers, cut for about five minutes at each interface switchover, and also at each Subnet Manager cut-off","users":"Sakura Cloud users","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Sakura Internet wrote that it could not test the storage device at its performance limit, because it could not prepare as many servers as the design capacity and used load generated from predictions, so it could not respond quickly and accurately to problems in real operation. Packet loss on the InfiniBand port kept the device below its expected performance and took three months to fix by firmware, and its engineers could not grasp the whole of the device's specification and behaviour. Sakura Internet concluded that its process for choosing and validating the storage device had serious problems.","ko":"사쿠라인터넷은 스토리지 장치의 선정과 검증 과정에 큰 문제가 있었다고 돌아봤다. 검증 때는 설계 사양에 맞는 최대 수용 대수만큼 서버를 준비하지 못하고, 예측으로 만든 부하로 성능을 확인했다. 그래서 성능 한계에서 하는 시험이 부족했고, 실제 운영에서 난 문제에 빠르고 정확하게 대응하지 못했다. InfiniBand 포트의 패킷 손실은 펌웨어 업데이트로 풀렸지만 대응을 마치기까지 석 달이 걸렸다. 자사 엔지니어가 스토리지 장치의 사양과 동작을 다 파악하지 못해서, 제조사와 긴밀히 협력했어도 조사와 확인에 오랜 시간이 걸렸다."},"related":[],"sources":[{"url":"https://cloud.sakura.ad.jp/news/wp-content/uploads/2012/06/storagehoukoku20120625a.pdf","kind":"official-status","archived":"https://web.archive.org/web/20260421190527/https://cloud.sakura.ad.jp/news/wp-content/uploads/2012/06/storagehoukoku20120625a.pdf"}],"summary":{"en":"Sakura Cloud, released on 15 November 2011, kept users' disks on a storage device connected to the host servers over an InfiniBand network. From early December the storage device's network interface lost packets intermittently as access grew. The interface's two-port redundancy relied on ICMP monitoring, which read the packet loss as a failure and switched to the standby port, and each switchover cut storage access for about five minutes. From late December a second problem appeared: the interface stopped answering the presence checks of the InfiniBand Subnet Manager, and the Subnet Manager cut the device off the network. These cuts were part of a series of storage failures that ran intermittently from the first failure on 9 December 2011 to the end of March 2012.\n\nIn early January Sakura Internet changed the interface monitoring from ICMP to a check of the LINK state, so the device switched ports only on a physical link down, which ended the failover problem, and changed the Subnet Manager's check from its normal mode, judged insufficient, to heavy sweep mode, which ended the Subnet Manager cut-offs. The packet loss itself continued until a firmware update of the storage device on 19 March. A second storage device was added on 12 March and servers that could move were migrated to it to spread the load, and with lower load on the first device no disk disconnection failures occurred from April onwards. In its review Sakura Internet wrote that the device had not been tested at its performance limit, that packet loss on the InfiniBand port took three months to fix by firmware, and that its engineers could not fully understand the device's specification and behaviour, so investigation with the manufacturer took a long time. Sakura Internet decided to replace the storage with a new device developed in-house.","ko":"사쿠라인터넷은 2011년 11월 15일 사쿠라 클라우드를 정식으로 출시했다. 12월 중순부터 호스트 서버와 스토리지 장치 사이의 트래픽이 늘면서 둘 사이의 네트워크 연결이 끊기는 문제가 났다. 2011년 12월 9일의 첫 장애부터 2012년 3월 말까지 스토리지 장애가 간헐적으로 이어졌고, 이 연결 끊김은 그 원인 가운데 하나였다.\n\n첫째 원인은 네트워크 인터페이스의 이중화 감시였다. 스토리지 장치의 네트워크 인터페이스는 두 포트로 이중화돼 있었고, ICMP 로 운영 포트를 감시했다. 12월 초부터 간헐적인 패킷 손실 때문에 감시 장치가 ICMP 가 일정 시간 끊겼다고 판정하고 예비 포트로 전환했다. 전환할 때마다 호스트와 스토리지 장치 사이의 통신이 5분 정도 끊겼다. 조사해 보니 인터페이스는 고장 나지 않았고 접근량이 늘어 패킷을 잃고 있었다. 사쿠라인터넷은 1월 초 감시 방식을 ICMP 에서 LINK 상태 확인으로 바꿔 물리적으로 링크가 내려갔을 때만 예비 포트로 바뀌게 했고, 이로써 이중화 구성의 문제는 사라졌다. 패킷 손실 자체는 3월 19일 스토리지 장치 펌웨어 업데이트로 없어졌다.\n\n둘째 원인은 InfiniBand 의 Subnet Manager 였다. 12월 하순부터 스토리지 장치의 네트워크 인터페이스가 Subnet Manager 의 생존 확인에 응답하지 않아 장치가 네트워크에서 떨어졌다고 판단되는 일이 몇 번 났다. 인터페이스에 물리적인 이상이 없었으므로, 사쿠라인터넷은 1월 초 보통 모드의 확인 방식이 부족하다고 보고 heavy sweep 모드로 바꿔 문제를 없앴다. 3월 12일에는 두 번째 스토리지 장치를 더해 사용자 서버를 옮기며 부하를 나눴다. 첫 번째 스토리지도 부하가 줄면서 안정됐고, 4월 이후로는 디스크 연결이 끊기는 장애가 나지 않았다. 사쿠라인터넷은 끝내 기존 스토리지를 자체 개발한 전혀 다른 스토리지 장치로 바꾸기로 했다."},"trigger":{"en":"Traffic between the host servers and the storage device grew from mid-December 2011, after the service launched on 15 November 2011.","ko":"2011년 11월 15일 서비스를 시작한 뒤 12월 중순부터 호스트 서버와 스토리지 장치 사이의 트래픽이 늘었고, 스토리지 장치의 네트워크 인터페이스에서 패킷 손실이 나기 시작했다."},"severity":"unknown","symptoms":["storage-disconnected","packet-loss"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":null,"components":["block-storage","infiniband"],"root_cause":"capacity","remediation":[{"text":{"en":"Switched the network interface monitoring from ICMP to a LINK state check, so the device fails over only on a physical link down","ko":"1월 초 스토리지 장치 네트워크 인터페이스의 감시 방식을 ICMP 에서 LINK 상태 확인으로 바꿔, 물리적으로 링크가 내려갔을 때만 예비 포트로 전환되게 했다."}},{"text":{"en":"Changed the InfiniBand Subnet Manager's check from normal mode to heavy sweep mode","ko":"1월 초 Subnet Manager 의 확인 방식을 보통 모드에서 heavy sweep 모드로 바꿔 스토리지 장치가 네트워크에서 떨어지는 문제를 없앴다."}},{"text":{"en":"Updated the storage device firmware on 19 March, which stopped the packet loss","ko":"3월 19일 스토리지 장치의 펌웨어를 업데이트해 장치의 패킷 손실을 없앴다."}},{"text":{"en":"Added a second storage device on 12 March and migrated servers to it to reduce and spread the load","ko":"스토리지 부하를 줄이려고 3월 12일 두 번째 스토리지 장치를 더했고, 옮길 수 있는 서버를 두 번째 장치로 옮겨 부하를 나눴다."}}],"action_items":[{"text":{"en":"Replace the current storage with an entirely different new storage device","ko":"기존 스토리지를 자체 개발한 전혀 다른 새 스토리지 장치로 바꾼다."}},{"text":{"en":"Test the new storage in an environment equal to its maximum capacity under real load, with a free beta before paid service","ko":"새 스토리지는 장치의 최대 수용 대수에 맞는 테스트 환경을 준비해 실제로 부하를 걸어 시험했다. 유료 정식 서비스 전에 다시 무료 베타 테스트 기간을 두고, 사용자가 만족할 때까지 시험을 되풀이한다."}},{"text":{"en":"Use network interface drivers and similar parts equivalent to those already proven on the host servers","ko":"새 스토리지의 네트워크 인터페이스 드라이버 같은 부품은 지금까지 운영에서 문제가 없던 호스트 서버와 같은 것을 썼다."}},{"text":{"en":"Develop the new storage with in-house engineers so Sakura Internet can manage and operate it itself","ko":"새 스토리지는 사쿠라인터넷이 직접 관리하고 운영할 수 있도록 자사 엔지니어가 개발했다."}}],"contributing":["automation-amplified","staging-not-representative","limited-debug-access"],"recurrence_of":null,"symptoms_text":{"en":"From mid-December 2011, after Sakura Cloud launched, traffic between the host servers and the storage device grew, and the network connection between the hosts that carry users' servers and the storage device was cut again and again. Each cut caused by a port switchover lasted about five minutes.\n\nThe storage device's network interface has two ports in a redundant pair. The active port was watched with ICMP (ping), and when ICMP replies stopped for a set period the port was treated as failed and the device switched to the standby port. From early December the interface lost packets intermittently, the monitor saw ICMP stop for the set period, and the device switched ports; the switchover itself cut communication with the hosts for about five minutes. Later investigation found that the interface was not faulty: the packet loss came from the growing volume of access.\n\nFrom late December, storage access was also cut off several times for a different reason. The storage network runs on InfiniBand, where a Subnet Manager (SM) manages connections between devices. The storage device's network interface stopped answering the SM's presence checks, so the SM judged the device to be gone from the network and cut it off, although the interface showed no physical fault.","ko":"사쿠라 클라우드에서 사용자 서버를 수용한 호스트 서버와 스토리지 장치 사이의 통신이 되풀이해 끊겼다. 포트 전환 때문에 끊길 때는 한 번에 5분 정도 끊겼다. 이 끊김은 2011년 12월부터 간헐적으로 되풀이됐다.\n\n스토리지 장치의 네트워크 인터페이스는 포트 두 개로 이중화돼 있었다. 감시 장치는 운영 포트를 ICMP, 곧 ping 으로 감시하다가 응답이 일정 시간 끊기면 고장으로 보고 예비 포트로 바꿨다. 12월 초부터 이 인터페이스에서 패킷 손실이 간헐적으로 났고, 감시 장치가 ICMP 가 일정 시간 끊겼다고 판정해 예비 포트로 전환했다. 이 전환 때문에 호스트와 스토리지 장치 사이의 통신이 5분 정도 끊겼다.\n\n12월 하순부터는 이와 다른 이유로 스토리지 장치에 접근하지 못하는 장애가 몇 번 났다. 스토리지 네트워크는 InfiniBand 를 쓴다. InfiniBand 네트워크에는 장치 사이의 연결을 관리하는 Subnet Manager, 줄여서 SM 이 필요하다. 스토리지 장치의 네트워크 인터페이스가 SM 의 생존 확인에 응답하지 않자 SM 이 장치가 네트워크에서 떨어졌다고 판단해 네트워크가 끊겼다. 인터페이스에 물리적인 이상은 보이지 않았다.\n\n처음에는 네트워크 인터페이스가 고장 난 것으로 판정됐다. 조사해 보니 인터페이스는 고장 나지 않았고, 접근량이 늘어서 패킷을 잃고 있었다. 감시 방식을 바꾼 뒤에도 패킷 손실 자체는 남아 있었고, 이를 없애는 데 3월 19일 펌웨어 업데이트까지 석 달이 걸렸다."},"updated_at":"2026-11-14T12:34:18.009227Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0537","org_slug":"sakura-internet"}