Incident Library

IL-0350 IONOS Cloud · 2026-03-03networkingkubernetes

TXL 클러스터 한 곳의 호스트 네트워크가 끊기고 프로비저닝 대기열이 밀려 여러 서비스가 오래 나빠졌다

2026-03-03 IONOS Cloud 는 TXL 데이터 센터의 한 클러스터에서 고장 난 스위치를 바꾸는 정비를 했다. 정비 중 이 클러스터의 두 토폴로지 가운데 Topology 2 를 계획대로 껐다. 이때 Topology 1 의 모든 스위치는 IPoIB 멀티캐스트 그룹 때문에 Multicast Forwarding Table, 곧 MFT 용량이 이미 빠듯한 위태로운 상태였다. Topology 1 의 스위치 하나에서 링크 흔들림이 일어나 InfiniBand 컨트롤 플레인에 알림이 쏟아졌고, 네트워크 지도를 다시 맞추려고 자동으로 동작하는 자가 치유 장치인 패브릭 resweep 이 시작됐다. MFT 가 이미 꽉 차 있어 재설정에 필요한 재프로그래밍이 실패했고, 실패한 경로 갱신이 몰려 관리 계층이 버티지 못했다. 게이트웨이가 심한 과부하에 빠지고 BGP 세션이 끊겨 클러스터의 호스트 연결이 끊겼다.

IONOS Cloud 는 문제가 난 컨트롤 플레인을 대기 장비로 전환하고, 멈춘 게이트웨이를 재부팅하고, Topology 1 을 정비 상태에서 복구해 네트워크 장애를 풀었다. 그사이 영향을 받은 클러스터에서는 프로비저닝 작업이 성공할 수 없어 그 호스트의 자원에 예정된 변경이 모두 대기열에 쌓였고, 자가 치유에 들어간 서비스들이 작업을 더 넣었다. 네트워크가 돌아온 뒤 밀린 작업이 자원 잠금 지연을 일으켜 처리가 느려졌고, 자가 치유 작업을 기다리던 서비스들이 오래 나쁜 상태로 남았다. IAM 은 장애 중 시작된 IP 할당 정비 작업이 오래 끝나지 않아 Data Center Designer, 곧 DCD 의 프런트엔드에 응답하지 못했다. AI Model Hub 는 Managed Kubernetes 클러스터의 연결이 끊겨 쓸 수 없었고, DBaaS 와 Managed Kubernetes 는 BGP 연결 손실과 프로비저닝 지연을 함께 겪었다.

IONOS Cloud 는 12:54 UTC 에 작업이 밀린 클러스터의 프로비저닝을 잠시 멈췄고, 14:01 UTC 에는 네트워크가 나아지고 있어 프로비저닝을 다시 켜겠다고 알렸다. AI Model Hub 는 14:37 UTC 에, DCD 는 15:25 UTC 에 정상으로 돌아왔다. 21:49 UTC 에 프로비저닝과 DBaaS 가 완전히 돌아오고 밀린 작업이 모두 처리되어 사고가 닫혔다.

심각도
–
영향 범위
Network connectivity for hosts in one TXL cluster, with spillover to the DCD web frontend through IAM, the AI Model Hub, DBaaS, Managed Kubernetes and provisioning of infrastructure changes
영향 사용자
–
지역
TXL data center (Location DE/TXL)
감지까지
–
복구까지
–

증상

2026-03-03 11:36 UTC 에 상태 페이지가 TXL 의 모니터링 알림을 조사하고 있다고 알렸다. 정비 중이던 클러스터 한 곳의 호스트가 연결을 잃었고, 고객은 간헐적인 네트워크 서비스 저하나 중단을 겪었다.

12:01 UTC 에 Data Center Designer, 곧 DCD 와 AI Model Hub 가 영향 목록에 올랐다. DCD 웹 프런트엔드는 그 밑의 IAM 서비스에 닿지 못해 쓸 수 없었다. 장애 중에 시작된 IP 할당 정비 작업이 오래 끝나지 않아 IAM 이 프런트엔드에 응답하지 못했다.

AI Model Hub 서비스 자체는 계속 동작했지만, 그 서비스가 도는 Managed Kubernetes 클러스터의 네트워크가 끊겨 고객이 쓸 수 없었다. 12:09 UTC 에 회복이 보였다가 12:38 UTC 에 DCD 프런트엔드와 AI Model Hub 에서 문제가 다시 나타났다.

12:45 UTC 에 오류 수가 늘어 DBaaS 도 영향 목록에 들어갔다. DBaaS 와 Managed Kubernetes 워크로드를 올린 서버는 BGP 연결을 바로 잃었다. 그 뒤에는 프로비저닝 대기열이 밀려 볼륨 연결과 해제, 자동으로 시작되는 자가 치유 작업이 미뤄졌고, 네트워크가 돌아온 뒤에도 복구가 늦어졌다.

프로비저닝 시스템이 영향을 받은 클러스터의 자원에 연결하지 못해 먼저 대기열에 작업이 크게 쌓였다. 연결 문제로 자가 치유에 들어간 서비스가 작업을 더 넣으면서 작업 수가 기하급수적으로 늘었고, 네트워크가 돌아온 뒤에는 자원 잠금 병목으로 대기열 처리가 느려졌다. 고객이 DCD 에서 인프라 자원을 바꾸는 작업은 오래 걸렸다.

증상 네트워크 도달 불가링크 플래핑서비스 중단

원인

원인 용량 한계

구성 요소 InfiniBand 패브릭네트워크 컨트롤 플레인BGP 라우팅NIC·케이블·스위치 포트 링크모델 허브데이터베이스
기여 요인 자동화 증폭과도한 영향 범위
촉발
TXL 데이터 센터 클러스터의 고장 난 스위치를 바꾸는 정비로 두 토폴로지 가운데 Topology 2 를 계획대로 껐다. 그동안 남은 Topology 1 에서 스위치 하나의 링크 흔들림이 패브릭 resweep 을 일으켰다.

감지

IONOS Cloud 는 TXL 에서 울린 모니터링 알림으로 장애를 알아챘고, 11:36 UTC 에 상태 페이지에 이 알림을 조사하고 있다고 올렸다.

조치

후속 조치

교훈

IONOS Cloud 는 서비스들이 프로비저닝 대기열로 서로 얽혀 있던 점이 서비스 저하를 길게 만든 핵심 요인이었다고 봤다. 앞으로는 서비스마다 견고하게 만드는 것과 함께 프로비저닝 대기열의 결합을 풀어 이번과 같은 파급을 줄이겠다고 했다. 서비스 사이의 의존도 찾아 풀어서 앞으로의 장애가 미치는 범위를 줄이겠다고 했다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: InfiniBand 패브릭, 네트워크 컨트롤 플레인, BGP 라우팅. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.