{"id":"IL-0411","org":"Meta","date":"2024-10-29","docs":[],"title":{"en":"Lemon nodes in Meta's RSC-1 and RSC-2 GPU clusters failed job after job without being caught by health checks","ko":"헬스 체크를 통과하는 레몬 노드가 Meta 연구 클러스터의 학습 작업을 거듭 실패시켰다"},"domain":["ai-infra"],"impact":{"scope":"Jobs placed on lemon nodes in RSC-1 and RSC-2; before lemon detection 14% of jobs on 512+ GPUs failed","users":"Researchers running ML jobs on RSC-1 and RSC-2","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Finding defective nodes needs historic data, and lemon node detection can improve the completion rate of large jobs by over 30%. A defective node that cannot be removed from capacity leads to restart loops that make large gang-scheduled jobs impossible to run, so recovery from random failures only works once defective nodes are reliably rotated out.","ko":"논문은 결함 있는 노드를 찾으려면 과거 기록이 꼭 필요하다고 밝혔다. 레몬 노드 탐지를 넣으면 대형 작업의 완료율을 30% 넘게 높일 수 있다. 결함 있는 노드에 작업이 거듭 스케줄되면 실패가 잇따르므로, 그런 노드를 확실히 빼낼 수 있어야 무작위 고장에서 회복하는 장치도 제대로 효과를 낸다. 노드를 빼는 부담을 ML 개발자에게 맡기지 않고 레몬 노드를 미리 찾아야 한다."},"related":[],"sources":[{"url":"https://arxiv.org/abs/2410.21680","kind":"paper","archived":"https://web.archive.org/web/20261102020708/https://arxiv.org/abs/2410.21680"}],"summary":{"en":"The paper, by engineers of FAIR at Meta, analyses 11 months of data from Meta's two research clusters, RSC-1 (16k GPUs, general ML) and RSC-2 (8k GPUs, mostly vision), covering 4 million jobs and over 150 million A100 GPU hours. Both are bare-metal DGX clusters with eight A100 80GB GPUs per server, scheduled by Slurm, and the paper views failures through Slurm job states and node health checks. Health checks run every five minutes, and a node that fails a high-severity check is removed and its jobs rescheduled; the design goal is that a bad node never fails a second job. Meta found that some job failures were tied to particular nodes, from misconfiguration, aging or hardware defects, and that health checks did not catch them.\n\nMeta built lemon detection to identify, isolate and replace such nodes in Slurm. Of the tens of signals available on each node, those most correlated with lemon nodes were excl_jobid_count, xid_cnt (unique XID errors), tickets (repair tickets), out_count (times the node was taken out of scheduling), multi_node_node_fails, single_node_node_fails and single_node_node_failure_rate; the thresholds were tuned by hand from a 28-day snapshot of RSC-1. The mechanism identified 40 faulty nodes, 24 on RSC-1 and 16 on RSC-2, with more than 85% accuracy, and more than 85% of the identified nodes failed one of the tests. The paper states that these nodes represent 1.2% of RSC-1's footprint, 13% of daily jobs, and 1.7% of RSC-2's footprint. Their root causes were GPU 28.2%, DIMM 20.5%, PCIE 15.4%, EUD 10.3%, NIC 7.7%, BIOS 7.7%, PSU 5.1%, CPU 2.6% and optics 2.6%. Failures of large jobs on 512 or more GPUs fell from 14% to 4%, which the paper reports as a 10% reduction.","ko":"Meta FAIR 의 엔지니어들이 자사 연구 클러스터 RSC-1 과 RSC-2 의 11개월치 데이터를 분석한 논문이다. RSC-1 은 범용 ML 클러스터로 GPU 16k 규모이고, RSC-2 는 비전 작업 위주로 GPU 8k 규모이며, 데이터는 작업 400만 개와 A100 GPU 시간 1억 5천만 시간이 넘는다. 두 클러스터는 Slurm 으로 작업을 스케줄하고, 작업 전후와 5분마다 도는 헬스 체크로 고장 난 노드를 찾아 뺀다. 노드가 노드 안에서 도는 다른 헬스 체크에 응답하지 않으면 마지막 장치인 Slurm heartbeat 가 이를 NODE_FAIL 로 잡는다. 논문은 실패 원인이 작업 수명의 마지막 10분 안이나 끝난 뒤 5분 안에 감지되면 그 원인을 작업 실패의 원인으로 보았다.\n\n헬스 체크는 무작위로 나는 노드 고장을 잘 찾았지만, 잘못된 설정이나 노화나 하드웨어 결함 때문에 실패가 특정 노드에 몰리는 경우가 있었다. 논문은 이런 노드를 레몬 노드라고 부르고, 작업을 거듭 실패시키지만 헬스 체크나 수리 절차 같은 기존 장치로는 찾지 못하는 서버라고 정의했다. 이런 노드는 실패한 작업이 다시 스케줄될 때마다 새 작업을 받아 다시 실패시켜 ETTR 을 떨어뜨렸다. ETTR 은 Effective Training Time Ratio 로, 쓸 수 있었던 실제 시간 가운데 작업이 의미 있게 진행된 시간의 비율이다. 연구자들이 경험으로 노드를 손으로 빼는 방식은 규모가 커지면 버티지 못했다. 논문은 학습 작업 실패의 가장 중요한 요인 가운데 하나가 NODE_FAIL 이므로 레몬 노드를 미리 다루는 일이 중요하다고 밝혔다.\n\n팀은 노드마다 있는 수십 가지 신호 가운데 레몬 노드와 상관관계가 가장 큰 일곱 가지를 골랐고, RSC-1 의 28일치 데이터로 기준값을 정했다. 기준값은 예측한 레몬 노드의 정확도와 오탐률을 보며 손으로 조정했다. 이 탐지로 RSC-1 에서 24대, RSC-2 에서 16대, 모두 40대의 결함 노드를 85% 넘는 정확도로 찾았다. 찾은 레몬 노드는 RSC-1 전체 규모의 1.2%, 일일 작업의 13%, RSC-2 전체 규모의 1.7% 였다. 찾은 레몬 노드 가운데 85% 넘는 노드가 테스트 하나에서 실패했고, 원인은 GPU 28.2%, DIMM 20.5%, PCIE 15.4%, EUD 10.3%, NIC 7.7%, BIOS 7.7%, PSU 5.1%, CPU 2.6%, Optics 2.6% 였다. 레몬 노드 탐지로 512개 이상의 GPU 를 쓰는 대형 작업의 실패가 14% 에서 4% 로 10%포인트 줄었다."},"trigger":null,"severity":"unknown","symptoms":["training-job-failed"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Meta's lemon detection flags nodes from their history in per-node signals such as excl_jobid_count, xid_cnt, tickets, out_count and node failure counts, because the periodic health checks and repair workflows did not catch them.","ko":"팀은 일부 노드의 작업 실패율이 평균보다 높다는 것을 보고 문제를 알았다. 실패율이 특정 노드에 몰려 있었지만, 통계적으로 의미 있게 판단하려면 오랜 기간의 실패 기록을 봐야 해서 빨리 찾기는 어려웠다."},"components":["gpu-hardware","slurm"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Built lemon detection to proactively identify, isolate and replace lemon nodes in the Slurm scheduler","ko":"레몬 노드를 미리 찾아 Slurm 에서 격리하고 교체하는 레몬 노드 탐지를 설계해 넣었다."}},{"text":{"en":"Identified 40 faulty nodes, 24 on RSC-1 and 16 on RSC-2","ko":"레몬 노드 탐지로 RSC-1 의 24대와 RSC-2 의 16대, 모두 40대의 결함 노드를 찾아냈다."}}],"action_items":[],"contributing":["monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"In Meta's RSC-1 and RSC-2 research GPU clusters, certain nodes had above-average rates of job failures. After each failure the same nodes kept attracting new jobs and failing them too, while health checks and repair workflows did not flag them. Meta calls these servers lemon nodes.\n\nThe paper ties lemon nodes to NODE_FAIL, the catch-all status Slurm gives through its heartbeats when a node stops responding to the health checks running on it, and names NODE_FAIL as one of the most important factors behind training job failures. Large jobs were hit hardest: before lemon detection, 14% of jobs on 512 or more GPUs failed.\n\nBefore the detection was automated, researchers excluded nodes by hand when those nodes had made their jobs fail, based on past experience. That did not scale, and excluding nodes too aggressively risked starving the cluster of capacity. The count of distinct jobs that had excluded a node (excl_jobid_count) did not correlate strongly with node failures, even though a large number of nodes had been excluded by at least one job. Finding a lemon node takes failure history over a long period before the pattern is statistically significant.","ko":"헬스 체크에 걸리지 않는 특정 노드들에서 학습 작업이 평균보다 자주 실패했다. 작업이 실패해 다시 스케줄되면 이 노드들이 새 작업을 또 받았고, 그 작업도 결국 실패했다. 논문은 이런 노드를 레몬 노드라고 불렀다.\n\n레몬 노드와 상관관계가 가장 큰 노드 신호는 excl_jobid_count, xid_cnt, tickets, out_count, multi_node_node_fails, single_node_node_fails, single_node_node_failure_rate 였다. 각각 그 노드를 제외하도록 지정한 서로 다른 작업의 수, 노드가 겪은 서로 다른 XID 오류 수, 노드에 열린 수리 티켓 수, 스케줄러가 노드를 가용 상태에서 뺀 횟수, 노드 때문에 실패한 다중 노드 작업 수, 노드 때문에 실패한 단일 노드 작업 수, 노드의 단일 노드 작업 실패율이다.\n\n피해는 큰 작업에서 컸다. 레몬 노드 탐지를 넣기 전에는 512개 이상의 GPU 를 쓰는 대형 작업의 14% 가 실패했다.\n\n이런 노드는 빨리 찾기 어려웠다. 통계적으로 의미 있는 판단을 하려면 오랜 기간의 실패 기록을 봐야 했다. 실패율이 특정 노드에 몰려 있었기 때문에 팀은 하드웨어가 낡아 가거나 노드에 잘못 설정된 소프트웨어가 돌고 있다고 의심했다.\n\n처음에는 연구자들이 경험에 기대 작업을 실패시키는 노드를 손으로 제외했다. 이 방식은 규모가 커지면 버티지 못했고, 노드를 너무 많이 빼면 용량이 모자랄 수 있었다. RSC-1 의 28일치 데이터를 보니 적지 않은 노드가 적어도 한 작업에서 제외됐지만, 사용자가 남긴 excl_jobid_count 신호는 노드 실패와 상관관계가 강하지 않았다."},"updated_at":"2026-11-14T12:34:06.181912Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0411","org_slug":"meta"}