{"id":"IL-0475","org":"Microsoft Azure","date":"2024-06-08","docs":["https://github.com/microsoft/superbenchmark"],"title":{"en":"Azure A100 InfiniBand all-reduce bandwidth dropped when over half of ToR switches' redundant uplinks were down","ko":"Azure A100 InfiniBand 클러스터에서 ToR 스위치의 이중화 업링크가 절반 넘게 끊겨 2노드 all-reduce 대역폭이 크게 떨어졌다"},"domain":["ai-infra","azure","networking"],"impact":{"scope":"24-node A100 testbed with 192 InfiniBand NICs: all-reduce bus bandwidth of multiple 2-node pairs dropped significantly","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Redundant links let the network keep working while degradation builds up, and only some traffic patterns slow down, so the loss is not a simple failure that monitoring of running workloads catches. Repairing just enough links to unblock the current workload does not restore the redundancy and makes the next incident more likely; Microsoft argues for stressing the hardware with standalone tests before incidents.","ko":"부품 단위의 이중화는 성능 저하를 숨기고, 시간이 지나면 장애를 더 잦게 만든다. 이중화가 일부 끊겨 생기는 점진적인 성능 저하는 기존 워크로드를 모니터링해서는 제때 찾기 어려우므로, 하드웨어에 부하를 거는 별도 테스트로 찾아야 한다. 장애 대응에서 이중화를 일부만 고치면 당장의 워크로드는 살아나지만 신뢰성은 떨어진다. 그래서 장애가 나기 전에 구성 요소를 미리 검증해 이중화를 모두 되살려야 한다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2402.06194","kind":"paper","archived":"https://web.archive.org/web/20260205003520/https://arxiv.org/abs/2402.06194"}],"summary":{"en":"The SuperBench paper by Microsoft describes how hardware redundancy in Azure's AI infrastructure hides gradual degradation, which the authors call gray failure. Azure A100 clusters use over-provisioned InfiniBand networks with several redundant links between ToR switches and aggregation switches, and Microsoft found that more than half of those redundant links must work to avoid a performance regression from congestion, so at most half can be broken. Figure 3 of the paper plots the cumulative distribution of 2-node all-reduce bandwidth at different redundancy ratios for a real case on a 24-node, 192-NIC fat-tree testbed whose ToR switches each had 25% redundant uplinks. When some edge switches had over half of their redundant links down, multiple 2-node pairs running traffic together lost much of their all-reduce bus bandwidth, and the bandwidth of every pair returned to normal only after operators repaired the redundant links of all involved ToR switches to at least 50%.\n\nThe paper adds that troubleshooting usually repairs only enough redundancy to unblock the current workload, for example replacing one of several broken links, which leaves the infrastructure more likely to have the next incident when any single link fails. In Azure's A100 clusters the mean time between incidents was 17.5 hours, 38.1% of incidents took more than a day to recover, and troubleshooting started only when customers raised incidents. SuperBench, deployed in Azure for more than two years, runs benchmarks before incidents to find defective components such as these links.","ko":"Azure A100 클러스터는 ToR 스위치와 집선 스위치 사이에 이중화 링크를 여러 개 둔 여유 있는 InfiniBand 네트워크를 쓴다. Microsoft 저자들은 혼잡으로 인한 성능 저하를 피하려면 이중화 링크의 절반보다 많이 살아 있어야 한다는 것을 확인했다. 즉 끊겨도 되는 이중화 링크는 많아야 절반이다. InfiniBand NIC 192개를 쓰는 24노드 fat-tree 테스트베드에서는 ToR 스위치마다 업링크의 25%가 여유분이었다. 일부 엣지 스위치에서 이중화 링크가 절반 넘게 끊기자, 동시에 트래픽을 보내는 여러 2노드 쌍의 all-reduce 버스 대역폭이 크게 떨어졌다. 운영자가 관련된 모든 ToR 스위치의 이중화 링크를 50% 이상으로 고친 뒤에야 모든 2노드 쌍의 대역폭이 정상으로 돌아왔다.\n\n논문은 이것을 하드웨어 이중화가 만드는 회색 장애의 예로 든다. 회색 장애는 부품이 완전히 고장 나지 않은 채 겉으로 드러나지 않게 성능만 떨어지는 상태다. 이중화 링크가 일부 끊기면 상태가 좋고 나쁨 둘로 갈리지 않고 서서히 나빠지며, 일부 워크로드에는 초기에 영향이 없다. 장애 대응에서는 멈춘 워크로드를 빨리 다시 돌리려고 끊긴 링크 중 하나만 바꾸는 경우가 많다. 이렇게 하면 당장의 장애는 끝나지만, 다음 링크 하나만 나빠져도 다시 장애가 난다. Azure A100 클러스터의 장애 간 평균 시간은 17.5시간이었고 장애의 38.1%는 복구에 하루 넘게 걸렸다."},"trigger":{"en":"Some edge (ToR) switches of the testbed had more than half of their redundant uplinks to the aggregation switches down.","ko":"InfiniBand ToR 스위치와 집선 스위치 사이의 이중화 업링크가 일부 엣지 스위치에서 절반 넘게 끊겼다."},"severity":"unknown","symptoms":["throughput-degraded"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"The drop showed in the 2-node all-reduce bandwidth measured across node pairs on the testbed. In production, Azure's troubleshooting began only when customers raised incidents.","ko":"24노드 테스트베드에서 여러 2노드 쌍에 동시에 트래픽을 보내며 all-reduce 버스 대역폭의 누적 분포를 재 보았고, 이중화 비율에 따라 분포가 크게 달라지는 것을 확인했다."},"components":["infiniband"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"Repaired the redundant links of every involved ToR switch to at least 50%, which brought all 2-node pairs back to normal all-reduce bandwidth","ko":"운영자가 관련된 모든 ToR 스위치의 이중화 링크를 최소 50%까지 고쳤고, 그 뒤 모든 2노드 쌍의 all-reduce 대역폭이 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"Validate infrastructure components proactively with SuperBench benchmarks before incidents instead of relying on reactive troubleshooting","ko":"장애가 난 뒤에 고치는 대신, 장애가 나기 전에 클라우드 AI 인프라의 구성 요소를 미리 검증하는 SuperBench를 쓴다."}}],"contributing":["monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"On a 24-node Azure A100 testbed with 192 InfiniBand NICs in a fat-tree topology, several 2-node pairs that ran traffic at the same time showed a significant drop in all-reduce bus bandwidth. Some edge switches had more than half of their redundant uplinks down.\n\nMicrosoft describes this as gradual degradation rather than a binary good or bad state. In Azure A100 clusters each InfiniBand top-of-rack (ToR) switch has several redundant uplinks, and when part of them break only some traffic patterns, such as all-to-all collective communication, lose throughput to congestion. Workloads that barely use the A100 GPUs or the network, such as ResNet training, do not trigger the problem early on, so monitoring the workloads already running does not reveal the lost redundancy in time.","ko":"Azure A100 클러스터의 24노드 테스트베드에서 여러 2노드 쌍이 동시에 트래픽을 보낼 때 all-reduce 버스 대역폭이 크게 떨어졌다. 이 성능 저하는 좋고 나쁨 둘로 갈리지 않고 서서히 나빠지는 형태였다.\n\n테스트베드는 InfiniBand NIC 192개를 쓰는 fat-tree 구성이었고, ToR 스위치마다 업링크의 25%가 이중화용 여유분이었다. 일부 엣지 스위치에서 이중화 링크가 절반 넘게 끊기자 2노드 all-reduce 대역폭 분포가 정상에서 벗어났다.\n\n이중화 링크가 일부만 끊긴 동안에는 ResNet 학습처럼 GPU와 네트워크를 다 쓰지 않는 워크로드에는 문제가 드러나지 않았다. all-to-all 같은 집합 통신에서는 혼잡 때문에 처리량이 떨어졌다. 기존 워크로드를 모니터링하는 것만으로는 이런 부분적인 이중화 손실을 제때 찾기 어려웠다."},"updated_at":"2026-11-14T12:34:12.200881Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0475","org_slug":"microsoft-azure"}