Incident Library
Applied filters ComponentObject storageOrganisationLinodeClear 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

Cases2 cases

1 to 2 of 2

  1. Symptoms

    On 19 and 20 October 2022, Linode Object Storage in Newark and Atlanta slowed down, became less available and rate limited many requests with "503 - Slow Down" HTTP responses, after the clusters received extremely high inbound traffic in both request count and bandwidth.

    Trigger

    Extremely high inbound traffic, in both total requests and throughput, reached the Newark and Atlanta Object Storage clusters on 19 and 20 October 2022.

    Root cause
    Component
    Contributing factor
    Remediation
    • Fixed the edge rate limiting so it enforces the advertised 750 requests per second per bucket
    • Adjusted Ceph tunables to stop runaway memory use during high-pressure storage events
    • Moved internal Object Storage components hit by resource contention to less busy, higher-performance infrastructure
    • Adjusted performance tunables on internal components and back-end clusters so customers were not rate limited too early
    Action items
    • Refine throughput and bandwidth throttling
    • Scale up the internal Object Storage infrastructure to spread load more efficiently
    • Look for further hardware performance improvements for the internal Object Storage infrastructure
    • Tune the load balancing algorithms to avoid hotspots in the clusters
    Lessons

    Linode's per-bucket rate limiting at the edge is meant to keep excess load off the back end; when it works as intended, the back-end limits, which throttle every client alike, should never come into play.

  2. Symptoms

    In the week of 10 October 2022, Linode Object Storage in Newark had two incidents of reduced performance and availability, on 10 and 16 October, and in some cases the front-end gateways returned 504 gateway timeouts to customers. The second incident began while the first was still being investigated.

    Trigger

    One back-end Object Storage node had a hardware problem that was not an outright failure, so the node kept going up and down.

    Root cause
    Component
    Contributing factor
    Remediation
    • Removed the failed back-end infrastructure from the Object Storage cluster
    Action items
    • Improve detection so subtle problems with failing or misbehaving hardware are found and triaged before they affect the wider cluster
    • Describe Ceph-related events more accurately to on-call administrators and define alerts more clearly
    Lessons

    Hardware that misbehaves without failing outright can cause service-wide problems, and Linode's internal monitoring had gaps in spotting such subtle issues before they affected the wider cluster.

Check your cluster for this

These 2 cases involve Object storage. 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 cause2