Cases39 cases

31 to 35 of 39

1. IL-0245 Acquia Cloud Enterprise sites in US-East went down when their web servers could no longer reach the Memcache servers

   Acquia2019

   Symptoms

   On 7 February 2019 from 22:17 to 23:25 UTC, some Acquia Cloud Enterprise sites in US-East became unstable or went down for multiple customers. The web servers could not reach the Memcache servers, PHP processes on the web servers were blocked, and the sites became unavailable.

   Service outageNetwork unreachable

   Trigger

   While setting up a temporary file system to store diagnostic data, a rule was deleted by mistake from a VPC security group.

   Root cause

   Operator error

   Component

   VPC route tables and firewall rulesIn-memory cache

   Contributing factor

   Ignored early signal

   Detection

   Acquia's configuration drift alerting fired, but the alert was not seen in time to shorten the outage.

   Remediation

   • Restored the missing rule in the security group by hand

   Action items

   • Correct the internal workflow with all involved teams to prevent similar mistakes
   • Alert internal teams faster about configuration drift in VPC security groups

   View case
2. IL-0472 Node-to-pod traffic and DNS failed on Tinder's 605-node Flannel cluster when every node's ARP cache passed gc_thresh3

   Tinder2019

   Symptoms

   In the early morning of 8 January 2019 Tinder's platform had a persistent outage. Communication from nodes to pods failed, and so did DNS lookups, because DNS ran inside the Kubernetes cluster.

   Service outageNetwork unreachableDNS resolution failures

   Trigger

   Earlier that morning, pod and node counts on the cluster were scaled up in response to an unrelated increase in platform latency.

   Root cause

   Capacity exhaustion

   Component

   Linux kernelCNI plugin

   Contributing factor

   Unreviewed defaults

   Remediation

   • Raised gc_thresh1, gc_thresh2 and gc_thresh3 on the nodes
   • Restarted Flannel so it re-registered the missing networks

   Lessons

   Tinder lists the outage among its learnings about network fabric limits: with Flannel over VXLAN, every node, and every pair of nodes that exchange pod traffic, adds entries to each node's ARP table, so at 605 nodes the default gc_thresh3 hard cap was exceeded on all nodes.

   View case
3. IL-0261 Discord went fully offline twice as short network losses on Google Cloud sessions nodes wedged Erlang distribution

   Discord2017

   Symptoms

   On 17 and 18 November 2017 nodes of Discord's 'sessions' cluster on Google Cloud Platform lost network connectivity for short periods, 16 times in all. Engineers saw a service impact, a node whose service had died and restarted, and pages for low memory on other sessions nodes; twice the failure cascaded and Discord was completely offline for about 30 minutes.

   Network unreachableMemory pressureService outage

   Trigger

   A software change that Google rolled out to the Google Cloud Platform networking stack on Friday introduced a bug that made VMs in Discord's sessions cluster lose network connectivity for short periods.

   Root cause

   Cloud provider outage

   Component

   Service discovery

   Contributing factor

   Limited debug accessHarmful manual action

   Detection

   At 11:52 PST on 17 November engineers noticed a service impact and escalated it in the incident chat. Later affected nodes showed up as pages to the on-call engineer for low memory on sessions nodes, and on 18 November as a page for a networking incident on sessions-1-11 together with issue reports that the customer experience team escalated from support channels.

   Remediation

   • Forcefully terminated sessions nodes whose Erlang distribution port had failed
   • Escalated the Google support ticket to P1 and notified the Technical Account Manager
   • Restarted several core Discord services on 17 November, making clients reconnect over about 20 minutes
   • Began terminating and rebooting the entire sessions cluster after seeing that rebooted machines did not fail again
   • Disabled message sending globally on 18 November to help the service recover
   • Restarted all members of the sessions cluster
   • Re-enabled message sending after the initial all clear
   • Google rolled back the software change made to its networking stack

   Action items

   • Continue the project to improve how Discord's Erlang clusters handle node failure
   • Expand how upgrades to these services are load tested so the rollout can be completed safely
   • Replace the HTTP library used by Discord's Elixir/Erlang services
   • Fix the instability seen in Erlang's net_kernel component
   • Replace the pieces of the service discovery component that degraded with more performant implementations
   • Work with Google on the issues Discord met while working with Google on this incident
   • Expand the internal procedure for communicating with Google so the progress of P1 issues is tracked

   Lessons

   Discord concluded that performance and stability issues in its own system, in Erlang's net_kernel, the service discovery component and the HTTP library, were what turned short network losses on part of the fleet from isolated issues for some users into two full system outages.

   View case
4. IL-0431 During Mackerel's move to AWS, PostgreSQL failed over to a replica that had stopped replicating, losing an hour of data

   Hatena2017

   Symptoms

   On 7 August 2017, while checking the application after the maintenance that moved Mackerel from an on-premises data center to AWS, the team found that data updated during a specific time window was missing. Everything written to the PostgreSQL database between 14:30 and 15:30 JST was gone.

   Data lossReplication lagNetwork unreachable

   Trigger

   One hour after the application was switched to the newly promoted primary db001, db001 lost network connectivity and the database failed over to the standby db002.

   Root cause

   Operator error

   Component

   DatabaseDatabase replicationDatabase failover manager

   Contributing factor

   Overlapping failuresUnreviewed defaultsUnrepresentative stagingAutomation amplification

   Detection

   The team found the missing data while checking how the application behaved after the migration work.

   Remediation

   • Tried to restore the lost updates by hand from the table data left on db001 and gave up
   • Tried point-in-time recovery from the base backup and WAL and gave up
   • Built a new replica db003 with db002 as primary to restore redundancy
   • Kept db001 in maintenance state for investigation
   • Watched db002 for some time to confirm the problem did not recur, then completed the migration

   Action items

   • Change the PostgreSQL replica creation script to set recovery_target_timeline = 'latest' in recovery.conf by default
   • Add a check to a server configuration test tool such as Serverspec that recovery.conf contains recovery_target_timeline = 'latest'

   Lessons

   A setting needed only for a rare layout, such as a grandchild replica during a migration, was applied by hand through a script option and was forgotten. Because recovery_target_timeline = 'latest' is harmless on ordinary standbys too, Hatena now sets it by default whenever a replica is created. The staging rehearsal used the same layout and steps but had the setting right, so it could not catch the mistake. Hatena notes that a similar layout may be used again for a future PostgreSQL upgrade or a move to another region.

   View case
5. IL-0396 New or live-migrated GCE instances, VPN tunnels and network load balancers were unreachable on public IPs for over 2h

   Google Cloud2017

   Symptoms

   On 30 January 2017, Google Compute Engine instances, Cloud VPN tunnels and GCE network load balancers that were created or live migrated between 10:36 and 12:42 PDT could not be reached on their public IP addresses. Resources created earlier, and instances that were not live migrated, kept working.

   Network unreachableProbe failures

   Trigger

   A large set of updates was applied to a rarely used load balancing configuration on the shared layer 2 load balancers.

   Root cause

   Software defect

   Component

   Cloud load balancerNetwork control plane (SDN)

   Contributing factor

   Excessive blast radiusGap in automated tests

   Remediation

   • Restarted the jobs that program changes into the network load balancers, so the stuck changes were processed as a batch
   • Applied the fix zone by zone between 11:36 and 12:42

   Action items

   • Increase the canary timeout so updates that hit the inefficient code path only slow network changes instead of stopping them
   • Improve the inefficient code path
   • Write new tests that check behaviour on a wider range of configurations
   • Accelerate replacing global propagation of address configuration with decentralized routing
   • Add metrics and alerting that identify this kind of issue sooner

   View case

By root cause10