Incident Library
Applied filters SymptomPacket lossFactorAutomation amplificationClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases6 cases

6 to 6 of 6

  1. Symptoms

    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.

    Trigger

    Traffic between the host servers and the storage device grew from mid-December 2011, after the service launched on 15 November 2011.

    Root cause
    Component
    Contributing factor
    Remediation
    • Switched the network interface monitoring from ICMP to a LINK state check, so the device fails over only on a physical link down
    • Changed the InfiniBand Subnet Manager's check from normal mode to heavy sweep mode
    • Updated the storage device firmware on 19 March, which stopped the packet loss
    • Added a second storage device on 12 March and migrated servers to it to reduce and spread the load
    Action items
    • Replace the current storage with an entirely different new storage device
    • Test the new storage in an environment equal to its maximum capacity under real load, with a free beta before paid service
    • Use network interface drivers and similar parts equivalent to those already proven on the host servers
    • Develop the new storage with in-house engineers so Sakura Internet can manage and operate it itself
    Lessons

    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.

Check your cluster for this

These 6 cases involve Database and API gateway. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause6

Operator error1 case

Contributing factor
Organisation
  1. IL-0348 Scaleway's FR-PAR region lost public internet connectivity when one 100 Gbps backbone link was saturated

Dependency failure1 case

Organisation
  1. IL-0257 canva.com went down for about 50 minutes when 1.5 million requests per second OOM-killed every API Gateway task
    Canva2024

Software defect1 case

Organisation
  1. IL-0347 About 25% of Scaleway FR-PAR-1 hypervisors lost VPC connectivity when both VPC BGP route reflectors got stuck

Cloud provider outage1 case

Organisation
  1. IL-0220 An overloaded AWS Transit Gateway dropped packets on 4 January 2021, and Slack's web tier saturated and went down
    Slack2021

DNS or network fault1 case

Organisation
  1. IL-0240 Cloudflare API requests failed and the dashboard slowed for hours after the authentication database lost its replicas

Capacity exhaustion1 case

Organisation
  1. IL-0537 Sakura Cloud host servers repeatedly lost their storage connection, about five minutes per port switchover