Graph
Cases2 cases
1 to 2 of 2
IL-0367Azure Storage in Central US rejected VM disk I/O, taking down VMs and the SQL Database and Cosmos DB services on themMicrosoft Azure2024- Symptoms
From 21:40 UTC on 18 July 2024, virtual machines in the Azure Central US region lost access to their disks, and the services running on those VMs failed. Azure SQL Database and SQL Managed Instance showed unhealthy nodes and login failures, Cosmos DB requests failed, and service management operations failed across many Azure services.
- Trigger
Routine changes to the VM host fleet led to a new allow list of VM host address ranges being generated and published to all Storage scale units in Central US. Recent network configuration changes had made some of the infrastructure file servers that hold the source data unreachable from the server generating the list, so the published list was incomplete.
- Root cause
- Component
- Contributing factor
- Detection
Service monitoring detected the drop in VM availability at 22:06 UTC while the allow list update was being published. SQL monitoring detected unhealthy nodes and login failures within one minute of SQL becoming unavailable, and monitoring flagged the availability drop for Cosmos DB, SQL DB and SQL DB Managed Instance at 22:14 UTC.
- Remediation
- Halted the allow list update workflow worldwide
- Paused all deployments in the Central US region
- Paused compute buildout deployments in all regions
- Updated the configuration of all Storage scale units in Central US, restoring storage availability by 02:55 UTC
- Started geo-failovers for SQL databases with automatic failover policies
- Restarted SQL gateway nodes to refresh their caches and route connections to the right nodes
- Forced completion of SQL failovers that had not completed
- Failed over the Cosmos DB control plane and active-passive accounts with a write region in Central US
- Cancelled customer-triggered graceful switch region operations that blocked Cosmos DB failovers
- Removed locks on Cosmos DB service metadata to force-complete stuck failovers
- Repaired impacted Cosmos DB partitions for single-region accounts
- Repaired backend nodes and failed Cosmos DB accounts back to Central US, redoing failback where it failed
- Action items
- Make the allow list generation workflow detect incomplete source information and halt
- Alert on storage requests rejected by allow list checks
- Deploy allow lists one Availability Zone and storage type at a time, over 24 hours
- Add VM health checks and an automatic stop to the allow list deployment workflow
- Reevaluate the policy for Microsoft-managed failover of SQL failover groups
- Fix the Cosmos DB failback workflow that broke some MongoDB drivers for MongoDB API accounts
- Fix Cosmos DB failback for accounts with private endpoints so it does not need redoing
- Make the storage data-plane firewall reject invalid allow lists and keep the last-known-good state
- Improve Azure NetApp Files monitors so impacting events are detected and classified in time
- Monitor more Azure NetApp Files service metrics to correlate similar events faster
- Make the SQL Service Fabric cluster location change notifications reliable under load
- Make SQL geo-failover workflows more robust so they complete
- Remove the issues that delayed 5% of Cosmos DB failovers
- Migrate Azure DevOps customer metadata to the right geography
- Decouple Azure NetApp Files regional reads and writes to keep this class of issue to one region
- Evaluate caching to reduce Azure NetApp Files reliance on stored utilization data
- Add automatic per-partition failover for Cosmos DB multi-region active-passive accounts
- Build the Resilient Ephemeral OS disk improvement so VMs survive storage incidents better
IL-0530Virtual router controllers in us-central1 ran out of memory in a loop, cutting networking for new and migrated VMsGoogle Cloud2023- Symptoms
On 5 October 2023 in us-central1, newly created VMs waited a long time before their networking worked, and VMs that had been live migrated lost connectivity for a long time after the migration. Networking telemetry showed cross-region packet loss to and from us-central1 from 03:08 US/Pacific. Health check state of VMs reached load balancers late.
- Trigger
A management plane behaviour change, meant to decouple the processing of API updates to Instance Groups and Network Endpoint Groups used as load balancer backends, was deployed in us-central1 after rolling out to several other regions without incident.
- Root cause
- Component
- Contributing factor
- Detection
Engineers were alerted to slowness in the virtual network control plane in us-central1 at 21:45 US/Pacific on 4 October, before the packet loss started, and to controller failures from memory exhaustion at 02:11 on 5 October. Networking telemetry showed cross-region packet loss from 03:08.
- Remediation
- Increased the memory allocated to the virtual network router controllers
- Rolled back the management plane change in us-central1
- Restarted by hand the routers that were still not accepting updates
- Action items
- Alert proactively on memory risks and unexpected memory increases
- Refactor the deployment configuration so engineers can reallocate memory much faster
- Re-evaluate existing practices and add safety mechanisms for API reconciliation
- Make management plane changes more visible across teams so the changes can be correlated faster
- Adjust the deployment footprint so a regional API change is less likely to exhaust memory across the region at once
- Optimise memory use in the traffic routers and their controllers
These 2 cases involve Cloud block storage 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 cause2
Configuration change1 case
- Contributing factor
- Organisation
Faulty deployment1 case
- Contributing factor
- Organisation