Cases2 cases
1 to 2 of 2
IL-0240Cloudflare API requests failed and the dashboard slowed for hours after the authentication database lost its replicasCloudflare2020- Symptoms
On 2 November 2020 the Cloudflare API and dashboard were degraded for six hours and 33 minutes. The success rate of API queries dropped at times to 75%, and the dashboard was up to 80 times slower than normal, while Cloudflare's edge network kept working.
- Trigger
At 14:43 UTC a network switch in a control plane data center partly failed: it kept LACP and BGP running but stopped forwarding some packets, and it recovered on its own six minutes later.
- Root cause
- Component
- Contributing factor
- Detection
At 14:43 UTC alerts fired because the misbehaving switch was unreachable to pings. Engineers then saw that the primary authentication database was overwhelmed.
- Remediation
- Shed load from the primary authentication database by slowing SSL certificate pushes to the edge, emails and other features
- Moved API traffic that could use read replicas to the secondary data center by hand
- Sent authentication calls fully back to the primary data center when the dashboard got worse
- Rebuilt the first database replica, which put itself back into service at 21:20 UTC and returned performance to normal
- Ramped the turned-down services back up so asynchronous processing could catch up
- Action items
- Remove the cluster management limitation that requires rebuilding all replicas after a primary is promoted
- Redesign the user sessions system so dashboard traffic can be steered between data centers
- Change the auto-remediation configuration so a database replica is not promoted so quickly
- Tune each system involved to be more resilient to failures of its dependencies
- Lessons
Every system in the chain had redundancy and none failed completely; each only degraded, which made the chain of events much harder to model and foresee. Automating replica promotion so that it could trigger on a minute's notice had been a point of pride, but for at least one database a fast promotion can do more harm than the failure it answers. Most general-purpose cluster managers use Raft or Paxos rather than Byzantine fault tolerant protocols, accepting a rare failure mode in exchange for a protocol that is simpler to implement correctly and debug.
IL-0590F5 load balancers cached a path MTU of 296 after Rackspace reboots, and Mailgun connections failed intermittentlyMailgun2014- Symptoms
On Saturday, September 27, 2014 at 6:50 p.m. UTC, Mailgun saw that all its database replicas and the internal traffic between its environments in all regions were broken and reporting timeouts. Once Rackspace began rebooting cloud instances in its Chicago data center (ORD), Mailgun customers had intermittent connection failures.
- Trigger
Rackspace, Mailgun's parent company and hosting provider, rebooted cloud instances in its Chicago data center (ORD), and the cloud maintenance triggered an error condition on Mailgun's F5 load balancers.
- Root cause
- Component
- Contributing factor
- –
- Detection
Mailgun noticed at 6:50 p.m. UTC on September 27 that all database replicas and the internal traffic between its environments were broken and reporting timeouts.
- Remediation
- The Rackspace networking team cleared the cached path MTU on Mailgun's F5s and on some Rackspace dedicated customers' F5s
- Set up a new virtual IP for Mailgun services
- Changed Mailgun's DNS settings, which forced the remote F5s to clear their caches
- Action items
- Finish the root cause analysis of the F5 path MTU problem with Rackspace
- Make sure maintenance of Mailgun's cloud infrastructure has no impact on Mailgun customers
These 2 cases involve Database replication and Cloud load balancer. 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 cause1
DNS or network fault2 cases
- Component
- Contributing factor
- Organisation