{"id":"IL-0367","org":"Microsoft Azure","date":"2024-07-18","docs":["https://learn.microsoft.com/azure/cosmos-db/nosql/conceptual-resilient-sdk-applications","https://status.dev.azure.com/_history","https://learn.microsoft.com/azure/azure-sql/database/disaster-recovery-guidance?view"],"title":{"en":"Azure Storage in Central US rejected VM disk I/O, taking down VMs and the SQL Database and Cosmos DB services on them","ko":"Central US 의 Azure Storage 가 VM 디스크 요청을 거부해 VM 과 그 위의 SQL Database, Cosmos DB 가 멈췄다"},"domain":["azure","database"],"impact":{"scope":"VM availability in Central US and the services on those VMs, including SQL Database, SQL Managed Instance, Cosmos DB, Database for MariaDB, Database for MySQL and PostgreSQL flexible servers and Azure Resource Manager; new Azure NetApp Files volumes could not be created in any region","users":"unknown","region":"Central US"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://azure.status.microsoft/en-us/status/history/?trackingId=1K80-N_8","kind":"official-status","archived":null}],"summary":{"en":"Azure VMs with persistent disks use disks backed by Azure Storage. As a defence-in-depth measure, Storage scale units accept disk reads and writes only from network address ranges known to belong to the physical hosts that run VMs, and an allow list of those ranges is published to every Storage scale unit in a region as hosts are added and removed, at least once a day in large regions. The list is built from one file per datacenter on a set of infrastructure file servers. On 18 July 2024 some of those file servers could not be reached from the generating server after recent network configuration changes; the workflow did not notice the missing files and published an allow list with incomplete VM host address ranges. The allow list deployment went through the region in batches within about an hour, did not check for drops in VM availability and did not follow Safe Deployment Practices (SDP) such as Availability Zone sequencing, so Storage servers across the region rejected disk requests from the affected VM hosts.\n\nVMs in many control-plane and data-plane clusters failed, and the services built on them failed with them, including Azure SQL Database and Managed Instance, Cosmos DB, the Database for MySQL and PostgreSQL flexible servers, Azure Resource Manager, Azure DevOps, Privileged Identity Management and Azure NetApp Files, and through them parts of Microsoft 365, Dynamics 365 and Microsoft Entra. Once the incomplete allow list was identified as the trigger, Microsoft halted the allow list update workflow worldwide and updated the configuration of every Storage scale unit in Central US, which restored storage availability at 02:55 UTC on 19 July.\n\nDatabase recovery took most of the next day. For SQL, Microsoft started failovers for databases with automatic failover policies within an hour, promoting the geo-secondary and pointing the failover group (FOG) endpoint to the new primary. Less than 0.5% of those failovers did not complete, because failover workflows were terminated or throttled under high demand on the service manager component, and engineers forced those failovers to completion by hand. After storage came back 98% of SQL databases recovered, while about 2% needed gateway node restarts because the metadata on the gateway nodes was out of sync with replica placement; all SQL databases were verified as recovered at 22:00 UTC on 19 July. Cosmos DB failed over its control plane and the active-passive accounts whose write region was Central US, finishing 95% of account failovers by 02:29 UTC; the other 5% needed customer-started region switches cancelled or locks on service metadata removed. Single-region Cosmos DB accounts were brought back through partition repairs, and failback to Central US had to be redone for some MongoDB API accounts and for accounts with private endpoints.","ko":"Azure VM 의 영구 디스크는 Azure Storage 에 있다. 다층 보안 방어의 하나로, 스토리지 스케일 유닛은 Azure VM 이 도는 물리 호스트에 속한다고 알려진 네트워크 주소 범위에서 온 디스크 읽기와 쓰기 요청만 받는다. VM 호스트가 늘고 줄면 이 주소가 바뀌고, 바뀐 주소를 허용 목록으로 만들어 리전의 모든 스토리지 스케일 유닛에 배포한다. 큰 리전에서는 보통 하루 한 번 이상 갱신한다.\n\n2024년 7월 18일에는 일상적인 VM 호스트 변경에 맞춰 허용 목록을 새로 만들고 있었다. 목록의 원본은 인프라 파일 서버 여러 대에 데이터센터마다 파일 하나씩 있다. 최근 그 파일 서버들의 네트워크 설정이 바뀌어, 목록을 만드는 서버가 그중 일부에 접근하지 못했다. 목록을 만드는 워크플로는 빠진 원본 파일을 알아채지 못했고, VM 호스트 주소 범위가 덜 담긴 허용 목록을 리전의 모든 스토리지 스케일 유닛에 배포했다. 스토리지 서버는 정보가 빠진 VM 호스트에서 오는 VM 디스크 요청을 모두 거부했다. 배포는 묶음 단위였지만 보통 한 시간 안에 리전 전체에 퍼졌다. 이 배포 워크플로는 VM 가용성 하락을 확인하지 않았고 가용 영역 순서대로 배포하는 것 같은 Safe Deployment Practices 를 따르지 않아, 영향이 리전 전체로 번졌다.\n\nVM 이 멈추자 Azure SQL Database 와 SQL Managed Instance 의 컨트롤 플레인과 데이터 플레인 클러스터가 비정상이 되어 서비스 관리 작업과 연결이 실패했다. 장애 1시간 안에 자동 장애 조치 정책이 있는 데이터베이스의 장애 조치를 시작했다. 하지만 서비스 관리자 구성 요소에 요청이 몰려 장애 조치 워크플로가 끊기거나 스로틀링됐고, 0.5% 미만은 손으로 마무리해야 했다. 스토리지 복구 뒤 데이터베이스 98%가 돌아왔고, 약 2%는 게이트웨이 노드의 메타데이터가 실제 복제본 위치와 어긋나 게이트웨이 노드를 재시작해야 했다. Cosmos DB 는 컨트롤 플레인과 데이터 플레인이 Azure Storage 에 OS 디스크를 둔 Azure Virtual Machine Scale Sets 위에 있어 같이 멈췄다. 다중 리전 쓰기 계정은 영향이 없었다. Central US 에 쓰기 리전이 있는 액티브-패시브 계정은 다른 리전으로 장애 조치될 때까지 쓰기를 못 했다. Central US 단일 리전 계정은 파티션이 영향받은 노드에 있으면 멈췄다. Cosmos DB 에 기대는 Azure Resource Manager 와 Privileged Identity Management 도 영향을 받았다.\n\n원인을 확인한 뒤 허용 목록 갱신 워크플로를 전 세계에서 멈추고, Central US 의 모든 스토리지 스케일 유닛의 설정을 고쳐 7월 19일 02:55 UTC 에 스토리지 가용성을 되살렸다. 그 위의 서비스는 실패 규모가 커서 복구에 시간이 더 걸렸다. Cosmos DB 는 19:30 UTC 쯤 모든 데이터베이스의 영향을 완화했고, SQL DB 와 SQL Managed Instance 는 22:00 UTC 에 모든 데이터베이스의 복구를 확인했다."},"trigger":{"en":"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.","ko":"일상적인 VM 호스트 변경에 맞춰 스토리지 허용 목록을 새로 만들 때, 목록을 만드는 서버가 네트워크 설정이 바뀐 인프라 파일 서버 일부에 접근하지 못했다. 그래서 VM 호스트 주소 범위 일부가 빠진 목록이 Central US 의 모든 스토리지 스케일 유닛에 배포됐다."},"severity":"unknown","symptoms":["storage-disconnected","service-unavailable","high-error-rate","failover-failed","stale-service-routing"],"timeline":{"detected_after":"26m","resolved_after":"24h 20m"},"date_kind":"incident","detection":{"en":"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.","ko":"허용 목록이 Central US 에 배포되는 동안 서비스 모니터링이 VM 가용성 하락을 잡았고, 엔지니어링 팀이 투입됐다. VM 가용성 하락을 잡은 시각은 22:06 UTC 로, 고객 영향이 시작되고 26분 뒤였다. SQL 모니터링은 SQL 을 쓸 수 없게 된 지 1분 안에 비정상 노드와 로그인 실패를 잡았고, 22:14 UTC 에는 모니터링이 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다."},"components":["block-storage","database","failover-manager"],"root_cause":"config-change","remediation":[{"text":{"en":"Halted the allow list update workflow worldwide","ko":"원인을 확인한 뒤 허용 목록 갱신 워크플로를 전 세계에서 멈췄다."}},{"text":{"en":"Paused all deployments in the Central US region","ko":"23:27 UTC 에 Central US 리전의 모든 배포를 멈췄다."}},{"text":{"en":"Paused compute buildout deployments in all regions","ko":"23:35 UTC 에 모든 리전의 컴퓨트 증설 배포를 멈췄다."}},{"text":{"en":"Updated the configuration of all Storage scale units in Central US, restoring storage availability by 02:55 UTC","ko":"Central US 리전의 모든 스토리지 스케일 유닛의 설정을 고쳐 7월 19일 02:55 UTC 에 스토리지 가용성을 되살렸다."}},{"text":{"en":"Started geo-failovers for SQL databases with automatic failover policies","ko":"장애 1시간 안에 자동 장애 조치 정책이 있는 SQL 데이터베이스의 장애 조치를 시작했다. geo-secondary 를 새 프라이머리로 올리고 장애 조치 그룹 엔드포인트가 새 프라이머리를 가리키게 했다."}},{"text":{"en":"Restarted SQL gateway nodes to refresh their caches and route connections to the right nodes","ko":"SQL 게이트웨이 노드를 재시작해 캐시를 새로 고치고, 연결이 올바른 노드로 가게 했다."}},{"text":{"en":"Forced completion of SQL failovers that had not completed","ko":"끝나지 않은 SQL 장애 조치를 강제로 완료했다."}},{"text":{"en":"Failed over the Cosmos DB control plane and active-passive accounts with a write region in Central US","ko":"영향이 시작된 직후, Central US 에 쓰기 리전이 있는 다중 리전 액티브-패시브 계정을 위해 Cosmos DB 컨트롤 플레인의 장애 조치를 시작했다. 이어 고객 계정을 다른 리전으로 장애 조치했다."}},{"text":{"en":"Cancelled customer-triggered graceful switch region operations that blocked Cosmos DB failovers","ko":"일부 계정에서는 고객이 Azure 포털에서 시작한 \"graceful switch region\" 작업이 Microsoft 가 시작한 서비스 관리 장애 조치를 막고 있었다. 이런 계정에서는 그 작업을 취소했다."}},{"text":{"en":"Removed locks on Cosmos DB service metadata to force-complete stuck failovers","ko":"일부 계정은 오래 도는 컨트롤 작업이 서비스 메타데이터에 잠금을 잡고 있어 장애 조치가 끝나지 않았다. 이런 계정은 그 잠금을 지워 장애 조치를 강제로 완료했다."}},{"text":{"en":"Repaired impacted Cosmos DB partitions for single-region accounts","ko":"장애 조치와 함께, 비정상으로 표시된 Cosmos DB 파티션을 고치는 작업을 따로 진행했다. 이 작업으로 Central US 단일 리전 계정의 가용성을 09:41 UTC 까지 99.9% 넘게 되살렸고, 19:30 UTC 쯤 모든 데이터베이스의 영향을 완화했다."}},{"text":{"en":"Repaired backend nodes and failed Cosmos DB accounts back to Central US, redoing failback where it failed","ko":"08:51 UTC 부터는 백엔드 노드 수리가 진행되는 대로, Microsoft 가 장애 조치했던 Cosmos DB 계정을 Central US 로 되돌렸다. Central US 를 먼저 읽기 리전으로 추가했고, 쓰기 리전을 다시 Central US 로 옮길지는 고객이 정하게 했다."}}],"action_items":[{"text":{"en":"Make the allow list generation workflow detect incomplete source information and halt","ko":"허용 목록을 만드는 워크플로가 원본 정보가 빠진 것을 알아채면 멈추게 고친다."}},{"text":{"en":"Alert on storage requests rejected by allow list checks","ko":"스토리지 요청이 허용 목록 검사에서 거부되면 알림을 보낸다."}},{"text":{"en":"Deploy allow lists one Availability Zone and storage type at a time, over 24 hours","ko":"허용 목록 배포를 가용 영역과 스토리지 종류에 따라 차례로 진행하고, 배포 기간을 24시간으로 늘린다."}},{"text":{"en":"Add VM health checks and an automatic stop to the allow list deployment workflow","ko":"허용 목록 배포 워크플로에 VM 상태 확인을 더하고, 이상이 보이면 배포를 자동으로 멈춘다."}},{"text":{"en":"Reevaluate the policy for Microsoft-managed failover of SQL failover groups","ko":"Microsoft 가 SQL 장애 조치 그룹의 장애 조치를 시작하는 정책을 다시 검토하고, 고객이 장애 조치를 직접 관리하라는 권고를 다시 알린다."}},{"text":{"en":"Fix the Cosmos DB failback workflow that broke some MongoDB drivers for MongoDB API accounts","ko":"Cosmos DB 페일백 워크플로를 고친다. 이 워크플로 때문에 MongoDB API 계정 일부에서 특정 버전의 MongoDB 드라이버가 모든 리전에 연결하지 못했다."}},{"text":{"en":"Fix Cosmos DB failback for accounts with private endpoints so it does not need redoing","ko":"프라이빗 엔드포인트가 있는 Cosmos DB 계정이 페일백 뒤 Central US 에 연결하지 못하던 문제를 고쳐, Microsoft 가 페일백을 다시 하지 않아도 되게 한다."}},{"text":{"en":"Make the storage data-plane firewall reject invalid allow lists and keep the last-known-good state","ko":"스토리지 데이터 플레인 방화벽이 잘못된 허용 목록 배포를 알아채고 마지막으로 정상이던 상태를 계속 쓰게 한다."}},{"text":{"en":"Improve Azure NetApp Files monitors so impacting events are detected and classified in time","ko":"Azure NetApp Files 의 여러 모니터 로직을 고쳐 영향을 주는 이벤트를 제때 잡고 알맞게 분류하게 한다."}},{"text":{"en":"Monitor more Azure NetApp Files service metrics to correlate similar events faster","ko":"Azure NetApp Files 의 여러 서비스 지표를 더 모니터링해 비슷한 문제를 잡고 관련 이벤트를 더 빨리 서로 연결해 보게 한다."}},{"text":{"en":"Make the SQL Service Fabric cluster location change notifications reliable under load","ko":"SQL 이 쓰는 Service Fabric 클러스터 위치 변경 알림 메커니즘이 부하가 클 때도 믿을 만하게 동작하게 한다."}},{"text":{"en":"Make SQL geo-failover workflows more robust so they complete","ko":"SQL 지역 장애 조치 워크플로를 견고하게 만들어 장애 조치가 끝까지 완료되게 한다."}},{"text":{"en":"Remove the issues that delayed 5% of Cosmos DB failovers","ko":"Cosmos DB 장애 조치의 5%를 늦춘 문제를 없앤다."}},{"text":{"en":"Migrate Azure DevOps customer metadata to the right geography","ko":"Azure DevOps 의 모든 고객 메타데이터를 알맞은 지리 영역으로 옮겨, 한 장애가 여러 지리 영역에 걸쳐 영향을 주지 않게 한다."}},{"text":{"en":"Decouple Azure NetApp Files regional reads and writes to keep this class of issue to one region","ko":"Azure NetApp Files 의 리전 사이 읽기와 쓰기를 분리해, 이런 종류의 문제가 한 리전 안에서 끝나게 한다."}},{"text":{"en":"Evaluate caching to reduce Azure NetApp Files reliance on stored utilization data","ko":"Azure NetApp Files 가 저장소에 둔 사용률 데이터에 덜 기대도록 캐시를 쓰는 방안을 검토한다."}},{"text":{"en":"Add automatic per-partition failover for Cosmos DB multi-region active-passive accounts","ko":"Cosmos DB 다중 리전 액티브-패시브 계정에 파티션 단위 자동 장애 조치를 넣어, 영향받은 파티션을 자동으로 처리하게 한다."}},{"text":{"en":"Build the Resilient Ephemeral OS disk improvement so VMs survive storage incidents better","ko":"SQL 과 Cosmos DB 를 위해 Azure Virtual Machines 가 Resilient Ephemeral OS disk 개선을 진행해, 스토리지 장애에도 VM 이 더 잘 버티게 한다."}}],"contributing":["unsafe-failure-mode","no-staged-rollout","blast-radius-too-wide","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"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.\n\nStorage scale units rejected every disk request from the VM hosts whose address ranges were missing from the storage allow list. Service monitoring saw VM availability drop at 22:06 UTC, and VM availability reached its lowest point at 22:45 UTC, when the deployment of the incomplete allow list finished. Storage scale units that host Premium v2 and Ultra Disk were not affected.\n\nThe Cosmos DB request success rate in Central US fell to 82% at its lowest point, with about 50% of the VMs running Cosmos DB in the region down; the infrastructure failed step by step over 68 minutes across several availability zones. Some applications saw errors even though their Cosmos DB accounts could serve traffic in other regions, which the first investigation traced to client-side timeouts. For Azure SQL, less than 0.5% of the databases that were failed over did not finish the failover, and after storage recovered about 2% of databases stayed unavailable because gateway nodes routed connections using metadata that no longer matched where the replicas were.\n\nBecause the impact was widespread and the first visible symptom looked like a drop in VM disk traffic to Storage scale units, engineers needed time to rule out other causes before linking the failures to the incomplete storage allow list, which was confirmed as the cause at 00:45 UTC.","ko":"Central US 리전에서 VM 가용성이 떨어졌고, 그 VM 에 기대는 여러 Azure 서비스에서 연결 실패와 서비스 관리 작업 실패가 났다. 서비스 모니터링은 7월 18일 22:06 UTC 에 VM 가용성 하락을 잡았고, 22:14 UTC 에 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.\n\nAzure Storage 의 스토리지 스케일 유닛이 VM 호스트에서 오는 디스크 읽기와 쓰기 요청을 거부했다. 처음 보인 주된 증상은 스토리지 스케일 유닛으로 가는 VM 디스크 트래픽이 줄어든 것이었다. Premium v2 와 Ultra Disk 를 제공하는 스토리지 스케일 유닛은 영향을 받지 않았다.\n\nAzure SQL Database 와 SQL Managed Instance 에서는 SQL 모니터링이 장애 1분 안에 리전의 비정상 노드와 로그인 실패를 잡았다. 장애 조치를 한 데이터베이스 중 0.5% 미만은 장애 조치가 끝나지 않았다. 장애 조치 그룹 엔드포인트를 쓰지 않는 애플리케이션은 한동안 옛 프라이머리에 계속 쓰기를 보냈다. 스토리지가 돌아온 뒤에도 데이터베이스 약 2%는 게이트웨이 노드의 메타데이터가 실제 복제본 위치와 어긋나 계속 연결할 수 없었다.\n\nCosmos DB 는 Central US 리전 전체의 요청 성공률이 가장 낮을 때 82%까지 떨어졌고, 리전에서 Cosmos DB 를 돌리는 VM 의 약 50%가 내려갔다. 인프라는 여러 가용 영역에 걸쳐 68분 동안 차례로 내려갔다. 데이터베이스 계정이 다른 리전에서 트래픽을 받을 수 있었던 고객 일부도 연결 문제로 클라이언트 쪽 타임아웃이 났고, 애플리케이션 오류를 봤다.\n\n영향은 다른 서비스로도 번졌다. Central US 의 Cosmos DB 에 백엔드 상태를 둔 Azure Resource Manager 는 미국의 다른 리전에서도 호출이 간헐적으로 실패했고, 재시도해서 다른 리전으로 가면 성공했다. Azure NetApp Files 는 모든 리전에서 새 볼륨 생성이 실패했다.\n\n고객 영향은 21:40 UTC 에 시작됐고, 22:45 UTC 에 허용 목록 배포가 끝나면서 리전의 VM 가용성이 가장 낮아졌다. 스토리지는 7월 19일 02:55 UTC 에 복구됐지만 그 위의 서비스는 복구에 더 오래 걸렸다. SQL DB 와 SQL Managed Instance 는 19일 22:00 UTC 에 모든 데이터베이스의 복구가 확인됐다.\n\n영향이 넓었고 주된 증상이 스토리지로 가는 VM 디스크 트래픽 감소로 보였기 때문에, 다른 원인을 하나씩 배제하고 불완전한 허용 목록을 원인으로 찾기까지 시간이 걸렸다. 22:30 UTC 에 SQL DB 영향이 조사 중이던 스토리지 장애와 관련 있다는 것을 알아냈고, 00:45 UTC 에 일부가 빠진 허용 목록이 근본 원인으로 확인됐다."},"updated_at":"2026-11-14T12:34:01.972455Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0367","org_slug":"microsoft-azure"}