Incident Library
적용된 필터 구성 요소NIC·케이블·스위치 포트 링크조직OpenAI모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례1건

1건 중 1~1번째

  1. 증상

    OpenAI 의 Cluster A 에서 50K GPU 로 돌던 운영 사전 학습 작업의 처리량이 1분 동안 약 25% 떨어졌다. 같은 시각 T0 스위치 한 대의 광 트랜시버에 달린 링크 네 개가 짧은 간격으로 연달아 내려갔다 올라왔다.

    촉발

    T0 스위치의 광 트랜시버 하나가 순간적으로 오작동해 그 트랜시버의 링크 네 개가 짧은 간격으로 연달아 플래핑했다.

    원인
    구성 요소
    기여 요인
    –
    감지

    NIC 와 T0 스위치가 각각 링크가 내려간 것을 기록했고, 두 기록의 시각은 정확히 같지 않았다. 작업 처리량 그래프와 노드별 패킷 손실률 그래프에 이 사건이 나타났다.

    조치
    • MRC 가 플래핑으로 잃은 패킷을 빠르게 복구해서 작업이 받은 영향은 비교적 작았다.
    교훈

    논문은 NIC 와 T0 사이의 링크를 잃으면 성능이 떨어진다고 했다. 다만 이런 사건은 대부분 잠깐이고, 작업이 노드를 빼지 않고도 금방 원래 속도로 돌아오는 경우가 많다고 했다. NIC 와 T0 사이의 링크와 T0 스위치는 눈에 띄는 영향을 주므로 T1 스위치보다 더 조심해서 다뤄야 한다고 했다. 단일 장애 지점도 남아 있다고 했다. 800 Gb/s NIC 광 모듈을 200 Gb/s 링크 네 개로 나눠 쓰므로 NIC 쪽 트랜시버 자체가 플래핑하면 그 NIC 의 포트를 모두 잃는다. 그러면 QP 가 실패하므로 작업이 이 상황을 견디지 못한다. 논문은 다른 광 설계를 쓰면 이 문제를 아예 피할 수 있을 것이라고 했다.

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

이 사례에서 가장 많이 나오는 구성 요소: NIC·케이블·스위치 포트 링크. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1