Cases39 cases

37 to 39 of 39

1. IL-0519 Apps on the cloud.gov PaaS became unavailable after an AWS security group change blocked their outbound traffic

   cloud.gov2016

   Symptoms

   From 9:28am Pacific Time on 8 March 2016, applications on the cloud.gov PaaS that relied on outbound traffic to reach the services they depended on became unavailable, and at one point every application on cloud.gov was down.

   Network unreachableService outage

   Trigger

   At 9:28am Pacific Time on 8 March 2016 a contractor at Aquilent changed the AWS security group settings, one of several changes made in the process of achieving ATO for the platform.

   Root cause

   Configuration change

   Component

   VPC route tables and firewall rules

   Contributing factor

   –

   Remediation

   • Added exceptions for individual applications, which restored some of them
   • Rolled back the security group change, which restored all applications

   Action items

   • Put all security group configuration into version control and make changes through pull requests
   • Monitor the applications running on cloud.gov and alert the cloud.gov team when they do not work as expected
   • Use CF security groups instead of AWS security groups and make the current rules visible to the cloud.gov team and the teams using it
   • Create a notification system to reach the key contact of each application on the platform
   • Create a more accurate staging environment to test changes like this

   View case
2. IL-0258 FastMail was unreachable for almost two hours when the GRE tunnels carrying its traffic from Level 3 went down

   Fastmail2016

   Symptoms

   At 4.50am Melbourne time on Sunday 7 February (evening of 6 February UTC), FastMail became unavailable and stayed unreachable for almost two hours. Traffic to FastMail's public IP range never made it into FastMail's own network.

   Service outageNetwork unreachable

   Trigger

   The GRE tunnels between Level 3 and NYI, which carried FastMail's filtered traffic into its network, went down.

   Root cause

   Dependency failure

   Component

   DDoS protection serviceBGP routing

   Contributing factor

   Limited debug access

   Detection

   NYI, the datacentre provider, noticed the failure quickly.

   Remediation

   • NYI escalated with Level 3's support until FastMail's public IP ranges were pointed back to NYI

   Action items

   • Go back to DDoS protection from Black Lotus under NYI's explicit control
   • Build nginx frontends in the Los Angeles datacentre that reach NYI over the secondary network, and point DNS to them if NYI's primary network fails
   • Add hardware in Amsterdam and change the delivery system so it depends less on NYI
   • Work with NYI to understand its processes for detecting and responding to network faults

   Lessons

   Much of FastMail's and NYI's reliability had come from NYI controlling its own infrastructure. With protection always on at Level 3, NYI could not restore the routes itself, and FastMail calls the resulting delay in restoring service unacceptable.

   View case
3. IL-0337 EBS volumes in one US East Availability Zone got stuck after a network change cut EBS nodes off from their replicas

   Amazon Web Services2011

   Symptoms

   From 12:47 AM PDT on 21 April 2011, a subset of Amazon EBS volumes in one Availability Zone of the US East Region could no longer serve reads or writes, and EC2 instances that tried to use them got stuck as well. AWS called these "stuck" volumes. EBS API calls across the whole US East Region also returned high error rates and latencies during two periods on the first day.

   Storage disconnected or stale mountsNetwork unreachableControl plane lagHigh error rateFailover failureData loss

   Trigger

   During a routine network change to upgrade the capacity of the primary EBS network in one Availability Zone, traffic was to be shifted off one of the redundant routers. The shift was executed incorrectly and sent the traffic onto the lower-capacity replication network instead of the other primary router, which could not carry it.

   Root cause

   Operator error

   Component

   Cloud block storageDatabase

   Contributing factor

   Automation amplificationRetry stormNo headroomExcessive blast radiusSignal buried in noise

   Remediation

   • Rolled back the incorrect traffic shift, which restored network connectivity
   • Disabled all new Create Volume requests in the affected Availability Zone at 2:40 AM PDT
   • Disabled all communication between the degraded EBS cluster and the EBS control plane from 8:20 AM PDT
   • Stopped EBS servers in the degraded cluster from futilely contacting other servers for free space
   • Changed the EBS control plane so new EBS-backed instance launches stopped failing
   • Moved spare server capacity physically from across the US East Region into the degraded cluster
   • Adjusted the negotiation throttles so the new servers could join without flooding the old ones
   • Built a separate EBS control plane partitioned to the affected zone and finer-grained throttles, then processed the backlog
   • Restored the remaining volumes from S3 snapshots taken early in the event
   • Restored volumes on failed machines that had no snapshot after forensic work
   • Intervened by hand on the RDS multi-AZ instances that did not fail over automatically

   Action items

   • Audit the change process and add automation to prevent the traffic shift mistake
   • Change capacity planning and alarming to keep the extra safety capacity needed for large recovery events
   • Change the retry logic in EBS nodes to back off harder and reconnect to previous replicas instead of searching for new nodes
   • Test and deploy the fix for the race condition that crashed EBS nodes
   • Fix the RDS bug that kept multi-AZ instances from failing over automatically
   • Improve the EBS control plane timeout logic to prevent thread exhaustion when one zone's cluster is slow
   • Make the EBS control plane aware of Availability Zones so it sheds load when over capacity
   • Move more EBS control plane functions into per-cluster services that run in the same zone as the cluster
   • Offer multiple Availability Zones to Amazon VPC customers
   • Provide better tools for building multi-AZ applications that survive the loss of a zone
   • Host free webinars and publish whitepapers on fault-tolerant architecture
   • Build the fine-grained control and throttling used in recovery into the EBS nodes and automate the recovery models
   • Look at changes that keep volumes working while a cluster is degraded, including the ability to take a snapshot of a stuck volume
   • Send more frequent and detailed customer updates and staff developer support more widely during events
   • Develop tools that show through the APIs whether instances are impaired

   Lessons

   AWS writes that with more spare capacity the cluster would have absorbed the re-mirroring requests without a storm, and that it now understands how much capacity large recovery events need. The event also showed that the EBS control plane let a failure in one Availability Zone affect the others, so more work is needed to make zones behave as if completely independent. AWS adds that some customers had critical components in a single zone, and that multi-AZ deployments need to become easier to design and run.

   View case

By root cause10