{"id":"IL-0133","org":"Nebius","date":"2026-08-19","docs":[],"title":{"en":"A storm shut down cooling at Nebius's us-central1 data center, and a disk hot-plug bug kept Managed Kubernetes control planes down for hours after power returned","ko":"폭풍으로 데이터센터 냉각이 멈춰 us-central1 리전 전체가 내려갔고, 디스크 핫플러그 버그로 Managed Kubernetes 컨트롤 플레인 약 140개의 복구가 길어졌다."},"domain":["kubernetes","ai-infra"],"impact":{"scope":"The whole us-central1 region: GPU and CPU compute (about a third of running VMs interrupted), external VM connectivity, object, block and file storage, Managed Kubernetes control planes, Token Factory inference, managed platform services, and the regional console and API","users":"Customers with resources in us-central1","region":"us-central1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Facility monitoring that runs on the same system it watches goes silent in exactly the failure it should report, and with no alert on the room temperature trend there was no practical window to shed heat load in a controlled way. A cold start of a whole region exercised recovery paths built for isolated failures: single-attempt VM recovery, conservative rate limits and stale disk attachments all needed manual work. The longest part of the outage was restoring customer resources, Managed Kubernetes control planes above all, so Nebius is extending its recovery drills to that layer.","ko":"시설 감시는 감시 대상 시스템과 독립돼 있어야 한다. 폭풍과 관련된 사건 하나가 냉각 설비와 그 고장을 알렸어야 할 건물 관리 시스템을 함께 껐다. 환경 데이터에도 알림이 있어야 한다. 한 시간 뒤에야 울린 알림은 원인이 아니라 결과인 부품 과열을 알린 것이었다.\n\n리전 단위 복구는 연습한 절차여야 한다. 이전 장애 뒤에 개선한 것들은 의도대로 작동했다. 컨트롤 플레인 랙에 먼저 전원을 넣었고, 네트워크 게이트웨이는 전원이 돌아오고 약 두 시간 안에 살아났고, 오브젝트 스토리지는 자동으로 복구됐다. 하지만 의존 계층 사이의 복구 순서는 장애 중에 손으로 정하고 조율해야 했다. 복구 자동화는 개별 장애뿐 아니라 대량 장애에도 맞게 설계해야 한다. 한 번만 시도하는 복구, 보수적인 속도 제한, 장애로 멈춘 인스턴스와 사용자가 멈춘 인스턴스를 구분하지 못하는 점 때문에 대규모 수작업이 필요했다.\n\n모니터링과 트래픽 관리는 리전이 무너져도 함께 무너지지 않아야 한다. 모니터링 구성 요소는 시작 과정도 데이터도 리전 안의 구성 요소에 기대고 있었다. 전역 콘솔 트래픽 관리에 쓰는 리전 헬스 체크는 리전이 정상이 아닌데도 정상이라고 보고해 트래픽을 잠깐 리전으로 되돌렸다."},"related":[],"sources":[{"url":"https://nebius.com/blog/posts/incident-post-mortem-analysis-us-central1-service-disruption-on-august-19","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"Around 08:30 UTC a storm-related event at the building hosting us-central1 took the building management system offline and shut down the chilled-water cooling loop. The building management system is also what monitors the facility, so neither the facility operator nor Nebius received a facility-level alert. The data halls overheated within about two hours, and servers, network switches and rack power systems shut down on thermal protection. By the time a controlled reduction of heat load was considered, about a quarter of the affected servers had already shut down. Nebius reached the facility operator at 10:46, cooling was switched to manual bypass at 11:15 with rack rear doors opened, temperatures began to fall at 11:45, and tripped racks were re-energised from 12:11, control-plane racks first. The facility was thermally stable about six hours after the event.\n\nRestoring the platform took much longer than restoring the facility. The regional infrastructure control plane did not come back on its own after power returned and needed about two hours of manual work, until 12:42. Automatic VM recovery makes a single attempt per instance and is rate-limited to protect the platform during isolated failures. It was launched for about a third of all running instances in the region; about a third of those attempts succeeded, and most of the rest failed on stale disk attachment state left on hosts that had lost power abruptly. Block-storage host components were restarted between 13:41 and 13:56 to clear the stale state, but many earlier attempts had already failed and were not retried automatically, and the recovery rate limits were raised by hand around 14:25.\n\nManaged Kubernetes stayed down longest because of a bug in Compute disk hot-plug: when an instance was recovered, a secondary data disk could be left unattached. Managed Kubernetes control planes keep their state on such disks, so hundreds of recovered control-plane instances came up without their data disk. The bug was identified at 18:17, a controlled stop and start of affected control-plane instances was tested on one cluster by 18:30, and it was applied at scale between 19:36 and 19:55, which cut the clusters with an unreachable control plane from 55 to 8. All Managed Kubernetes clusters were reported healthy at 21:58. The incident was fully mitigated at 08:38 UTC on 20 August, when all reserved GPU capacity was confirmed restored; repair of the remaining on-demand nodes went on for several more days. The hot-plug bug has been fixed and the fix deployed to all regions.","ko":"2026년 8월 19일 08:30 UTC 무렵, 폭풍과 관련된 사건으로 us-central1 리전이 들어 있는 데이터센터 건물의 건물 관리 시스템이 꺼지고 냉수 냉각 루프가 멈췄다. 능동 냉각이 끊긴 데이터 홀은 약 두 시간 만에 과열됐고, 서버와 네트워크 스위치와 랙 전원 장치가 열 보호로 꺼지기 시작했다. 흡기 온도는 최고 58.5 °C 까지 올랐다. 시설을 감시하는 시스템이 바로 그 건물 관리 시스템이어서 시설 수준의 알림은 운영사에도 Nebius 에도 가지 않았다. Nebius 는 10:15 부품 과열 알림으로 처음 움직였고 10:21 에 장애를 선언했다. 시설 운영사가 냉각을 수동 우회 모드로 돌렸고, 사건이 시작되고 약 여섯 시간 뒤 온도가 안정됐다. 그동안 GPU 와 CPU 컴퓨트, VM 외부 연결, 오브젝트와 블록과 파일 스토리지, Managed Kubernetes, Token Factory, 관리형 플랫폼 서비스, 리전 콘솔과 API 가 모두 영향을 받았고 실행 중이던 VM 의 약 3분의 1이 중단됐다.\n\n플랫폼 복구는 시설 복구보다 훨씬 오래 걸렸다. 리전 인프라 컨트롤 플레인은 전원이 돌아와도 스스로 살아나지 않아 약 두 시간 동안 손으로 되살려야 했다. 자동 VM 복구는 인스턴스마다 한 번만 시도하고 속도 제한이 걸려 있었다. 리전에서 돌던 인스턴스의 약 3분의 1에 자동 복구가 걸렸고 그중 약 3분의 1만 성공했다. 나머지는 갑자기 꺼진 호스트에 남은 디스크 연결 상태 때문에 주로 스토리지 연결 오류로 실패했고, 실패한 시도는 다시 시도되지 않았다.\n\n가장 오래 걸린 것은 Managed Kubernetes 였다. 컨트롤 플레인은 상태를 보조 데이터 디스크에 두는데, 관리형 디스크 핫플러그 기능의 버그 때문에 인스턴스를 복구할 때 이 데이터 디스크가 연결되지 않은 채로 남을 수 있었다. 그래서 복구된 컨트롤 플레인 인스턴스 수백 개가 데이터 디스크 없이 올라왔고 클러스터는 계속 내려가 있었다. 18:17 에 원인을 찾았고, 영향받은 컨트롤 플레인 인스턴스를 통제된 방식으로 멈췄다 다시 시작하는 완화책을 18:30 까지 한 클러스터에서 시험했다. 19:36 에서 19:55 사이에 이를 대규모로 적용해 컨트롤 플레인에 접근할 수 없는 클러스터가 55개에서 8개로 줄었고, 21:58 에 모든 클러스터가 정상으로 보고됐다. 장애는 8월 20일 08:38 에 완전히 완화됐다. 버그는 그 뒤 고쳐져 모든 리전에 배포됐다."},"trigger":{"en":"A storm-related event at the data center building took the building management system offline and shut down the chilled-water cooling loop.","ko":"폭풍과 관련된 사건이 데이터센터 건물에 영향을 줘 건물 관리 시스템이 꺼지고 냉수 냉각 루프가 멈췄다."},"severity":"unknown","symptoms":["control-plane-unresponsive","service-unavailable","monitoring-down"],"timeline":{"detected_after":"1h 45m","resolved_after":"24h"},"date_kind":"incident","detection":{"en":"No facility-level alert fired, because the storm also disabled the building management system that monitors the facility. Engineers acted on component over-temperature alerts that paged on-call at 10:15 UTC, after InfiniBand degradation, GPU over-temperature alerts and customer reports; the temperature rise from about 09:15 was visible on dashboards but had no alert.","ko":"시설을 감시하는 건물 관리 시스템이 같은 사건으로 꺼져 시설 수준의 알림이 없었다. 대시보드에는 09:15 무렵부터 온도 상승이 보였지만 이 지표에 알림이 없어 나중에야 확인했다. 09:40 무렵부터 InfiniBand 패브릭 저하와 GPU 과열 알림이 쌓였고, 엔지니어가 실제로 반응한 첫 신호는 10:15 의 핵심 부품 온도 알림이었다. 장애는 10:21 에 선언됐다."},"components":["datacenter-facility","block-storage","etcd","infiniband"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"had the facility operator switch cooling to manual bypass mode and opened rack rear doors to vent heat","ko":"시설 운영사가 냉각을 수동 우회 모드로 돌리고 랙 뒷문을 열어 열을 뺐다."}},{"text":{"en":"re-energised tripped racks, control-plane racks first","ko":"차단된 랙에 컨트롤 플레인 랙부터 전원을 다시 넣었다."}},{"text":{"en":"restored the regional infrastructure control plane by manual intervention","ko":"리전 인프라 컨트롤 플레인을 손으로 되살렸다."}},{"text":{"en":"restarted block-storage host components to clear stale disk attachment state","ko":"블록 스토리지 호스트 구성 요소를 재시작해 갑작스러운 전원 차단으로 남은 디스크 연결 상태를 지웠다."}},{"text":{"en":"raised the VM recovery rate limits by hand for the region-scale recovery","ko":"개별 장애에 맞춰 둔 VM 복구 속도 제한을 리전 규모 복구에 맞게 손으로 올렸다."}},{"text":{"en":"started the affected Managed Kubernetes control-plane instances by hand","ko":"접근할 수 없는 Managed Kubernetes 클러스터의 컨트롤 플레인 인스턴스를 손으로 시작했다."}},{"text":{"en":"applied a controlled stop and start to control-plane instances whose data disk had been left unattached","ko":"영향받은 컨트롤 플레인 인스턴스를 통제된 방식으로 멈췄다 다시 시작하는 완화책을 대규모로 적용했다."}},{"text":{"en":"identified and started 104 customer VMs that the incident had stopped","ko":"장애로 멈춘 고객 VM 104개를 찾아 시작했다."}}],"action_items":[{"text":{"en":"Complete a joint resilience review with the facility operator covering redundancy of facility-management and monitoring systems, cooling that keeps running when those fail, electrical protection of cooling equipment and on-site response","ko":"시설 운영사와 함께 회복력 검토를 마친다. 검토 범위는 시설 관리 시스템과 감시 시스템의 이중화, 그 시스템이 고장 나도 냉각 설비가 계속 도는지 여부, 냉각 설비의 전기 보호, 현장 대응 인력이다."}},{"text":{"en":"Add facility-level environmental alerting on cooling plant state and room temperature trend that pages on-call independently of the building management system","ko":"냉각 설비 상태와 실내 온도 추세를 보는 시설 수준의 환경 알림을 만든다. 이 알림은 건물 관리 시스템과 상관없이, 워크로드 증상이 나타나기 전에 온콜 엔지니어를 호출한다."}},{"text":{"en":"Set up a documented emergency escalation path with the facility operator, with an on-call contact tree and guaranteed response times","ko":"시설 운영사와 비상 에스컬레이션 경로를 문서로 만든다. 온콜 연락망과 보장된 응답 시간을 담는다."}},{"text":{"en":"Define an emergency heat-load reduction procedure with criteria, ownership and mechanics for shutting down or degrading workloads during a cooling loss","ko":"냉각이 끊겼을 때 워크로드를 끄거나 줄이는 비상 열 부하 감축 절차를 정한다. 기준과 책임자와 방법을 분명히 한다."}},{"text":{"en":"Establish a dependency-ordered region cold-start procedure with clear ownership for each service layer","ko":"서비스 계층마다 책임자를 정하고 의존 순서를 따르는 리전 콜드 스타트 절차를 정식으로 마련한다. 콜드 스타트는 꺼진 리전 전체를 처음부터 다시 올리는 일을 말한다."}},{"text":{"en":"Run regular region-scale recovery drills that cover VMs, storage attachments and Managed Kubernetes clusters","ko":"리전 단위 복구 훈련을 정기적으로 하고, 핵심 플랫폼 구성 요소와 고객 워크로드인 VM, 스토리지 연결, Managed Kubernetes 클러스터를 처음부터 끝까지 검증한다."}},{"text":{"en":"Fix the disk-attachment bug that extended the Managed Kubernetes outage and deploy the fix to all production regions","ko":"Managed Kubernetes 장애를 늘린 디스크 연결 버그를 고치고 모든 운영 리전에 배포했다."}},{"text":{"en":"Improve the recovery policies Compute users can configure, and move all Managed Kubernetes control-plane nodes to the improved policy","ko":"Compute 사용자가 인스턴스 복구 정책을 설정하는 방법을 개선하고, 모든 Managed Kubernetes 컨트롤 플레인 노드를 개선된 복구 정책으로 옮긴다."}},{"text":{"en":"Automate reconciliation of stale storage attachment state after abrupt host failures","ko":"호스트가 갑자기 고장 난 뒤 남은 스토리지 연결 상태를 자동으로 정리해, 손대지 않아도 디스크를 마운트하고 지울 수 있게 한다."}},{"text":{"en":"Remove in-region dependencies from monitoring startup and recovery, and extend cross-region monitoring","ko":"모니터링 스택의 시작과 복구 경로에서 리전 내부 의존을 없애고, 리전 간 모니터링을 넓혀 리전 자체 모니터링이 약해져도 그 리전을 볼 수 있게 한다."}},{"text":{"en":"Make regional health checks used for global traffic management reflect real service availability","ko":"전역 트래픽 관리에 쓰는 리전 헬스 체크가 실제 서비스 가용성을 반영하게 해, 비정상 리전에서 트래픽을 빼고 너무 일찍 되돌리지 않게 한다."}}],"contributing":["single-point-of-failure","monitoring-blind-spot","no-alert-on-limit","no-runbook","overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"On 19 August 2026 the first equipment-level signs in Nebius's us-central1 region appeared around 09:40 UTC: the InfiniBand fabric degraded and GPU over-temperature alerts began to accumulate. Customer reports followed shortly after 10:00. At 10:15 on-call engineers were paged on critical component temperature alerts, and the incident was declared at 10:21.\n\nRegional dashboards had shown the temperature rising from about 09:15, but no alert existed on that metric, and the rise was only noticed in retrospect. Between about 10:40 and 11:00 rack power systems tripped on thermal overload and took down racks that hosted regional control-plane and network gateway components; peak air inlet temperature reached 58.5 °C. VMs lost external connectivity from about 11:00 to 12:50, requests to the regional S3 endpoint failed from about 10:40 to 13:27, block and file storage operations failed or hung, Token Factory models were partly or fully unavailable from about 10:37, and the regional console and API endpoints were down. Customer-facing metrics and logs for regional resources were missing or incomplete, and the responders' own monitoring was weakened because it depended on components inside the region. At 11:01 a health check wrongly reported the region as recovered and sent part of the console traffic back to it for about seven minutes.\n\nManaged Kubernetes user cluster control planes became unavailable across the region. After power returned, the first recovery wave between 15:43 and 16:05 brought about half of them back; the rest either failed recovery or came back unhealthy. Around 16:15 about 140 clusters were estimated unreachable. Starting control-plane instances by hand restored about another quarter of the affected clusters by around 17:00, but at 18:11 79 clusters still had an unreachable control plane with their etcd data unavailable.","ko":"2026년 8월 19일 09:40 UTC 무렵부터 InfiniBand 패브릭 성능 저하와 GPU 과열 알림이 쌓이기 시작했고, 10:00 이 조금 지나 첫 고객 제보가 들어왔다. 10:15 에 핵심 부품 온도 알림으로 온콜 엔지니어가 호출됐다.\n\n10:40 에서 11:00 사이에 랙 전원 장치가 과열로 차단되면서 리전 컨트롤 플레인과 네트워크 게이트웨이를 올린 랙까지 내려갔다. 리전 S3 엔드포인트 요청은 10:40 무렵부터 실패했고, Token Factory 에 배포된 모델은 10:37 무렵부터 일부 또는 전부 쓸 수 없었다. 11:00 에는 리전 VM 의 외부 연결이 완전히 끊겼다. 리전 전체에서 Managed Kubernetes 사용자 클러스터의 컨트롤 플레인에 접근할 수 없게 됐고, 리전 콘솔과 공개 API 도 쓸 수 없었다. 고객용 지표와 로그는 비거나 빠졌고, 리전 안의 구성 요소에 기대던 대응팀의 모니터링도 약해졌다.\n\n전원이 돌아온 뒤에도 Managed Kubernetes 는 쉽게 살아나지 않았다. 15:43 에서 16:05 사이의 첫 복구에서 컨트롤 플레인의 절반가량이 돌아왔지만, 나머지는 복구에 실패하거나 비정상 상태로 올라왔다. 16:15 무렵 팀은 약 140개 클러스터에 접근할 수 없다고 추정했고, 컨트롤 플레인 인스턴스를 손으로 시작해 17:00 무렵 4분의 1을 더 살렸다. 18:11 에도 79개 클러스터는 컨트롤 플레인에 접근할 수 없었고 컨트롤 플레인 데이터인 etcd 를 읽을 수 없었다. 블록 스토리지에서도 갑자기 꺼진 호스트의 디스크 일부가 오래된 연결 상태로 남아 마운트도 삭제도 되지 않았다.\n\n나중에 대시보드를 돌아보니 09:15 무렵부터 리전 온도가 오르는 것이 보였지만 이 지표에는 알림이 없었다. 건물 관리 시스템이 꺼져 시설 쪽 알림도 오지 않았다."},"updated_at":"2026-11-10T00:00:35.302852Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0133","org_slug":"nebius"}