Cases2 cases

1 to 2 of 2

1. IL-0382 Linode Object Storage in Newark and Atlanta returned 503 Slow Down to all clients under very high inbound traffic

   Linode2022

   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.

   High error rateMemory pressure

   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

   Capacity exhaustion

   Component

   Object storage

   Contributing factor

   Unpatched known bugExcessive blast radius

   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.

   View case
2. IL-0534 Amazon S3 in US-EAST-1 could not serve GET, LIST, PUT or DELETE requests for hours while its index subsystem restarted

   Amazon Web Services2017

   Symptoms

   From 9:37AM PST on February 28th, 2017, Amazon S3 in the Northern Virginia (US-EAST-1) Region could not serve requests. AWS services in the region that store data in S3 failed with it, including the S3 console, new Amazon EC2 instance launches, Amazon EBS volumes that needed data from an S3 snapshot, and AWS Lambda.

   Service outage

   Trigger

   While debugging an S3 billing system that was progressing more slowly than expected, an authorized S3 team member followed an established playbook to remove a small number of servers from one S3 subsystem used by the billing process, and entered one input of the command incorrectly.

   Root cause

   Operator error

   Component

   Object storageCloud block storageServerless function platform

   Contributing factor

   No safeguard on destructive changeExcessive blast radiusCircular dependency

   Remediation

   • Restarted the index subsystem, which served GET, LIST and DELETE again from 12:26PM PST
   • Restarted the placement subsystem after the index subsystem worked, restoring PUT by 1:54PM PST

   Action items

   • Change the capacity removal tool to remove capacity more slowly
   • Add safeguards that stop capacity removal when it would take a subsystem below its minimum required capacity
   • Audit other operational tools for similar safety checks
   • Improve the recovery time of key S3 subsystems and start the planned further partitioning of the index subsystem into cells now
   • Run the SHD administration console across multiple AWS regions

   View case

By root cause2