KoreaDevKNOWLEDGE SHARING

콘텐츠 유형학습하기

AI INFRASTRUCTURE · 03 / 12

인터커넥트와 AI 패브릭

server 내부 bus부터 Ethernet·InfiniBand·RDMA와 scale-out fabric까지 연결하고 링크 상태를 증거로 인수합니다.

난이도
중급
구성
핵심 단원 4개 · 판단 활동 · 3단계 평가

NEW HIRE ONBOARDING

첫 업무를 받는 순서로 시작합니다

중학교를 졸업하고 처음 IT 업무를 맡은 신입사원도 따라올 수 있도록, 어려운 정의보다 상황·할 일·증거·보고할 경계를 먼저 확인합니다.

  1. 01

    상황을 한 문장으로 읽기

    물리 신호에서 route·queue·RDMA·분산 workload까지 계층별 counter를 연결해 cable 교체와 설정 변경의 근거를 만듭니다.

  2. 02

    오늘 맡은 일

    배선과 fabric 인수 시험의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

  3. 03

    완료를 보여 주는 증거

    공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

  4. 04

    멈추고 선임에게 확인할 경계

    8개 node 중 한 node의 RDMA throughput만 낮고 symbol error가 증가합니다. 첫 행동은?

낯선 용어 먼저 풀기

Carrier(물리 신호 감지)
interface가 상대측 link 신호를 감지하는 상태이며 정상 데이터 전달의 충분조건은 아닙니다.

이 과정의 운영 질문

빠른 link가 아니라 재현 가능한 collective 경로를 어떻게 인수할까?

물리 신호에서 route·queue·RDMA·분산 workload까지 계층별 counter를 연결해 cable 교체와 설정 변경의 근거를 만듭니다.

CORE UNIT 2 / 4

Ethernet과 switching

주소·VLAN·route와 congestion 경계를 설명합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

network namespace 관리자·switch read-only. 격리 VLAN 198.51.100.0/24.

3앞 단원 「신호·link·port의 기초」에서 어떤 증거를 남겼습니까?

양 끝 port, module, speed/FEC와 10분 counter 증가량을 연결해 정상 또는 격리 판정을 내리면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. Ethernet과 switching의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. Ethernet과 switching의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. Ethernet과 switching의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
Ethernet과 switching 실습 환경과 안전 경계
하드웨어2-port NIC fixture·leaf/spine 배선표
소프트웨어Ubuntu 24.04·iproute2·ethtool·rdma-core
필요 권한network namespace 관리자·switch read-only
네트워크격리 VLAN 198.51.100.0/24

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Ubuntu Server 24.04 LTS · rdma-core 50.x fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장host 주소에서 확인을 시작합니다
  2. 2장L2 전달의 실습 대상을 고정합니다
  3. 3장L3 경로의 출력과 의미를 구분합니다
  4. 4장queue 결과의 진행과 중단을 결정합니다
  5. 5장Ethernet과 switching의 복구를 재검증합니다
Ethernet과 switching의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · host 주소에서 확인을 시작합니다

다음 연결: L2 전달의 실습 대상을 고정합니다

  1. host 주소에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. L2 전달의 실습 대상을 고정합니다

    실습 상황:: 같은 subnet ping은 되지만 remote service가 안 되는 fixture에서 잘못된 route를 찾습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, VLAN·MTU·gateway 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. L3 경로의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 source 선택·gateway neighbor·path MTU가 설계와 일치하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. queue 결과의 진행과 중단을 결정합니다

    L2와 L3 경계를 구분하고 실제 선택된 route와 MTU 시험으로 실패 위치를 한 계층까지 좁히면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. Ethernet과 switching의 복구를 재검증합니다

    설계와 다른 route나 VLAN을 찾으면 변경 전 설정을 보존하고 owner에게 대조 결과를 전달합니다. 수정 뒤 small packet과 path-MTU packet, service request를 순서대로 재검증합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

host 주소에서 switch queue까지 Ethernet 경로를 좁힙니다

VLAN(가상 LAN): 동일한 물리 switch에서도 Ethernet broadcast 영역을 논리적으로 나누는 구성입니다.

Ethernet 전달은 MAC learning, VLAN, IP subnet, route, ARP/ND와 queue의 연속입니다. 같은 switch에 꽂혔다는 사실만으로 같은 broadcast domain이나 통신 가능성을 보장하지 않습니다.

host는 destination이 local subnet인지 판단하고, remote이면 gateway MAC으로 frame을 보냅니다. switch는 VLAN 안에서 MAC을 전달하며 router가 subnet을 넘깁니다. congestion은 egress queue에 쌓여 drop과 tail latency를 만듭니다.

통신 실패를 firewall 탓으로 단정하기 전에 local address·route·neighbor·VLAN·path 순서로 경계를 좁힙니다. packet capture는 최소 범위와 민감 정보 처리 규칙 안에서 사용합니다.

교육 사례에서 송신 port는 VLAN 120의 tagged frame을 보내지만 수신 port는 untagged VLAN 130으로 설정되어 있습니다. 양쪽 link가 up이고 IP 주소가 맞아도 같은 연결 경로가 아닙니다. 작은 ping 실패를 곧바로 route 문제로 보면 그 아래 VLAN 경계를 놓칩니다. port mode와 allowed VLAN, MAC 학습을 먼저 확인한 뒤 IP와 MTU로 올라갑니다.

host IP·prefix·MTU, MAC learning·VLAN, route·gateway·neighbor, egress queue·drop 네 계층마다 사실인 것과 확인 명령, 어긋났을 때 나타나는 증상을 나란히 적은 4열 표
그림 읽는 법 왼쪽 첫 열의 배지 1부터 4까지가 경계를 좁히는 순서이고, 각 행은 그 계층에서 사실인 것 · 확인 명령과 보이는 값 · 어긋났을 때 나타나는 증상을 나란히 놓습니다. 1행에서는 `ip -br address`로 `198.51.100.23/24`를 읽어 destination이 local subnet인지 판단하고, `ping -c 4 -M do -s 8972`가 `0% packet loss`면 해당 시험 조건에서 지정한 payload 크기의 ICMP 왕복에 성공했다는 뜻이며, 경로 모든 구간의 MTU가 같다는 증명은 아닙니다. 2행이 눈으로 보이지 않는 자리로, 송신 port가 tagged VLAN 120인데 수신 port가 untagged VLAN 130이면 양 끝 link가 up이고 IP가 맞아도 의도한 broadcast domain이 아닐 수 있으므로 port mode·VLAN mapping·MAC 학습을 대조합니다. 3행에서는 `ip route get`이 실제로 선택된 `via 198.51.100.1`과 `src 198.51.100.23`을 보여 주고, neighbor가 `REACHABLE`이 아니어도 STALE 등은 유효한 entry일 수 있습니다. FAILED나 INCOMPLETE가 지속되는지와 재요청 시 상태를 확인한 뒤 firewall 가설을 검토합니다. 4행에서는 부하 중 drop과 RTT 분포를 확인합니다. 작은 ping 성공과 service 지연만으로 queue discard를 단정하지 않고 같은 시간 구간의 queue counter·application 지연·부하를 대조합니다. 맨 아래 정리 상자대로 local address → route → neighbor → VLAN → path 순서로 좁히고, 설계와 다른 route나 VLAN을 찾으면 변경 전 설정을 보존해 owner에게 전달합니다. 색을 구별하지 않아도 배지 번호와 열 제목만으로 읽을 수 있으며, 표 안의 주소와 VLAN 번호는 저자 구성 교육용 예시입니다. 랙 배선이나 switch 외형은 담지 않고 확인 순서와 판단 기준만 담습니다. 자료: Linux Networking Documentation · NVIDIA Networking Documentation을 바탕으로 저자 구성.
왜 이런가
host는 destination이 local subnet인지 판단하고, remote이면 gateway MAC으로 frame을 보냅니다. switch는 VLAN 안에서 MAC을 전달하며 router가 subnet을 넘깁니다. congestion은 egress queue에 쌓여 drop과 tail latency를 만듭니다.
언제 문제가 되는가
VLAN·MTU·gateway 불일치 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
jumbo frame은 양 끝 host만 맞춰서는 안 됩니다. 경로의 각 구간이 필요한 frame·packet 크기를 수용하는지와 encapsulation overhead를 확인합니다. 장비마다 MTU 표시 기준이 다를 수 있으므로 숫자가 같다는 사실만으로 통과시키지 않습니다.
직접 확인하는 방법
source와 destination의 IP·prefix·MTU를 대조합니다. neighbor entry가 어떤 interface에서 어떤 MAC으로 해석되는지 확인합니다.
이 절을 정리하면L2와 L3 경계를 구분하고 실제 선택된 route와 MTU 시험으로 실패 위치를 한 계층까지 좁히면 성공입니다.

CHAPTER 1 / 5

host 주소에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. source와 destination의 IP·prefix·MTU를 대조합니다. 2. neighbor entry가 어떤 interface에서 어떤 MAC으로 해석되는지 확인합니다. 3. route get으로 실제 선택된 source·gateway·interface를 봅니다. 4. 부하 중 queue drop과 RTT 분포가 증가하는지 측정합니다.

CHAPTER 2 / 5

L2 전달의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
ip -br address
ip route get 198.51.100.80
ip neigh show dev enp65s0f0np0
ping -c 4 -M do -s 8972 198.51.100.80

CHAPTER 3 / 5

L3 경로의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
198.51.100.80 via 198.51.100.1 dev enp65s0f0np0 src 198.51.100.23
198.51.100.1 lladdr 02:00:00:00:00:01 REACHABLE
4 packets transmitted, 4 received, 0% packet loss

CHAPTER 4 / 5

queue 결과의 진행과 중단을 결정합니다

CHAPTER 5 / 5

Ethernet과 switching의 복구를 재검증합니다

CONCRETE CASES

같은 subnet ping은 되지만 remote service가 안 되는 fixture에서 잘못된 route를 찾습니다.

통신 실패를 firewall 탓으로 단정하기 전에 local address·route·neighbor·VLAN·path 순서로 경계를 좁힙니다. packet capture는 최소 범위와 민감 정보 처리 규칙 안에서 사용합니다.

잘못된 대응과 확인할 경계

jumbo frame은 양 끝 host만 맞춰서는 안 됩니다. 경로의 각 구간이 필요한 frame·packet 크기를 수용하는지와 encapsulation overhead를 확인합니다. 장비마다 MTU 표시 기준이 다를 수 있으므로 숫자가 같다는 사실만으로 통과시키지 않습니다.

설계와 다른 route나 VLAN을 찾으면 변경 전 설정을 보존하고 owner에게 대조 결과를 전달합니다. 수정 뒤 small packet과 path-MTU packet, service request를 순서대로 재검증합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 같은 subnet ping은 되지만 remote service가 안 되는 fixture에서 잘못된 route를 찾습니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, VLAN·MTU·gateway 불일치 조건이 보이면 다음 변경으로 넘어가지 마십시오.

198.51.100.80 via 198.51.100.1 dev enp65s0f0np0 src 198.51.100.23
198.51.100.1 lladdr 02:00:00:00:00:01 REACHABLE
4 packets transmitted, 4 received, 0% packet loss

값 자체를 외우는 것이 아니라 source 선택·gateway neighbor·path MTU가 설계와 일치하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

jumbo frame은 양 끝 host만 맞춰서는 안 됩니다. 경로의 각 구간이 필요한 frame·packet 크기를 수용하는지와 encapsulation overhead를 확인합니다. 장비마다 MTU 표시 기준이 다를 수 있으므로 숫자가 같다는 사실만으로 통과시키지 않습니다.

KEY TERMS

이번 단원 핵심 용어

VLAN(가상 LAN)
동일한 물리 switch에서도 Ethernet broadcast 영역을 논리적으로 나누는 구성입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

Ethernet과 switching의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 3 / 4

RDMA와 AI fabric

RDMA 적용 조건과 lossless 설계의 trade-off를 판정합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

network namespace 관리자·switch read-only. 격리 VLAN 198.51.100.0/24.

3앞 단원 「Ethernet과 switching」에서 어떤 증거를 남겼습니까?

L2와 L3 경계를 구분하고 실제 선택된 route와 MTU 시험으로 실패 위치를 한 계층까지 좁히면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. RDMA와 AI fabric의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. RDMA와 AI fabric의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. RDMA와 AI fabric의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
RDMA와 AI fabric 실습 환경과 안전 경계
하드웨어2-port NIC fixture·leaf/spine 배선표
소프트웨어Ubuntu 24.04·iproute2·ethtool·rdma-core
필요 권한network namespace 관리자·switch read-only
네트워크격리 VLAN 198.51.100.0/24

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Ubuntu Server 24.04 LTS · rdma-core 50.x fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장RDMA 장치에서 확인을 시작합니다
  2. 2장전송 경로의 실습 대상을 고정합니다
  3. 3장혼잡 제어의 출력과 의미를 구분합니다
  4. 4장collective의 진행과 중단을 결정합니다
  5. 5장RDMA와 AI fabric의 복구를 재검증합니다
RDMA와 AI fabric의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · RDMA 장치에서 확인을 시작합니다

다음 연결: 전송 경로의 실습 대상을 고정합니다

  1. RDMA 장치에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 전송 경로의 실습 대상을 고정합니다

    실습 상황:: 격리된 두 node fixture에서 RDMA device mapping과 성능 시험 조건을 검토합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, retry·pause·tail latency 급증 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 혼잡 제어의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 RDMA port와 netdev mapping이 맞고 명시한 조건에서 목표 bandwidth를 재현하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. collective의 진행과 중단을 결정합니다

    device·GID·message size·duration·평균/최저 bandwidth와 오류 counter를 포함한 시험표를 작성하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. RDMA와 AI fabric의 복구를 재검증합니다

    성능이 낮으면 먼저 link·NUMA·PCIe mapping과 단일 flow를 확인합니다. PFC·ECN을 동시에 바꾸지 말고 한 변경 뒤 host와 switch 양쪽 counter를 재측정합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

RDMA 장치에서 collective 성능까지 조건을 연결합니다

RDMA(Remote Direct Memory Access, 원격 메모리 직접 접근): 지원 NIC와 transport를 통해 원격 메모리로 데이터를 전달하는 방식입니다.

Remote Direct Memory Access(RDMA)는 remote memory 전송에서 CPU와 kernel data path의 개입을 줄이지만, 자동으로 빠르고 무손실인 network를 만들지는 않습니다.

RDMA device·GID·queue pair·memory registration이 맞아야 하며 RoCE는 Ethernet의 loss·congestion 설계와 함께 운영됩니다. Priority Flow Control(PFC)을 과도하게 쓰면 head-of-line blocking과 pause storm이라는 새 failure mode가 생깁니다.

기능 확인은 device가 보인다는 단계, 작은 message가 통과하는 단계, 목표 message size와 동시성에서 bandwidth·latency·retry가 허용되는 단계로 나눕니다.

교육 사례에서 일반 TCP 시험은 통과했지만 RDMA 시험의 연결이 성립하지 않았습니다. TCP 통신 가능은 RDMA device와 GID, queue pair 설정을 증명하지 않습니다. RoCE라면 IP·GID·MTU·혼잡 제어 경로를, InfiniBand라면 해당 fabric 관리 상태를 구분해 조사합니다. 두 transport의 설정을 하나의 공통 명령으로 취급하지 않습니다.

RDMA device·GID, queue pair, congestion control, collective 성능 네 단계마다 사실인 것과 확인 명령, 어긋났을 때 나타나는 증상을 나란히 적은 4열 표
그림 읽는 법 왼쪽 첫 열의 배지 1부터 4까지가 기능을 나누어 확인하는 순서이고, 각 행은 그 단계에서 사실인 것 · 확인 명령과 보이는 값 · 어긋났을 때 나타나는 증상을 나란히 놓습니다. 1행에서는 `rdma link show`의 `mlx5_0/1 state ACTIVE`와 `ibdev2netdev`의 `mlx5_0 port 1 ==> enp65s0f0np0`이 RDMA device 이름과 Ethernet netdev 이름의 짝을 보여 주는데, TCP 시험이 통과해도 이 짝과 GID는 증명되지 않습니다. 2행은 연결이 성립하는 자리로, server와 client가 같은 device·port·GID index를 쓰지 않으면 link는 ACTIVE인데 연결만 성립하지 않습니다. 3행은 transport가 갈리는 자리이며 RoCE는 Ethernet의 loss·congestion 설계와 함께, InfiniBand는 해당 fabric 관리 상태를 따로 봅니다. PFC를 과도하게 쓰면 head-of-line blocking과 pause storm이라는 새 failure mode가 생기므로 PFC·ECN은 한 번에 하나만 바꾸고 host와 switch 양쪽 counter를 다시 잽니다. 4행이 판정이 갈리는 자리로 `BW average[Gb/sec] 94.7`처럼 명시한 조건에서 재현되는지 보고, retry·pause·tail latency가 급증하면 다음 변경으로 넘어가지 않습니다. 색을 구별하지 않아도 배지 번호와 열 제목만으로 읽을 수 있으며, 표 안의 식별자와 수치는 저자 구성 교육용 예시입니다. HCA 카드의 생김새나 fabric 배선도는 담지 않고 확인 순서와 판단 기준만 담습니다. 자료: NVIDIA Networking Documentation · Linux Networking Documentation을 바탕으로 저자 구성.
왜 이런가
RDMA device·GID·queue pair·memory registration이 맞아야 하며 RoCE는 Ethernet의 loss·congestion 설계와 함께 운영됩니다. Priority Flow Control(PFC)을 과도하게 쓰면 head-of-line blocking과 pause storm이라는 새 failure mode가 생깁니다.
언제 문제가 되는가
retry·pause·tail latency 급증 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
운영망에서 무단 bandwidth test를 실행하면 실제 workload와 switch queue에 영향을 줍니다. 격리 창구와 rate 조건을 승인받습니다.
직접 확인하는 방법
rdma link와 GID가 설계된 netdev·VLAN을 가리키는지 봅니다. server/client가 같은 device·port·GID index 조건을 쓰는지 맞춥니다.
이 절을 정리하면device·GID·message size·duration·평균/최저 bandwidth와 오류 counter를 포함한 시험표를 작성하면 성공입니다.

CHAPTER 1 / 5

RDMA 장치에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. rdma link와 GID가 설계된 netdev·VLAN을 가리키는지 봅니다. 2. server/client가 같은 device·port·GID index 조건을 쓰는지 맞춥니다. 3. perftest의 message size·queue depth·duration을 기록합니다. 4. switch pause·ECN·discard와 host retry를 같은 시간대에 비교합니다.

CHAPTER 2 / 5

전송 경로의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
rdma link show
ibdev2netdev
ib_write_bw -d mlx5_0 -i 1 -F --report_gbits 198.51.100.24

CHAPTER 3 / 5

혼잡 제어의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
link mlx5_0/1 state ACTIVE physical_state LINK_UP netdev enp65s0f0np0
mlx5_0 port 1 ==> enp65s0f0np0 (Up)
BW average[Gb/sec] 94.7

CHAPTER 4 / 5

collective의 진행과 중단을 결정합니다

CHAPTER 5 / 5

RDMA와 AI fabric의 복구를 재검증합니다

CONCRETE CASES

격리된 두 node fixture에서 RDMA device mapping과 성능 시험 조건을 검토합니다.

기능 확인은 device가 보인다는 단계, 작은 message가 통과하는 단계, 목표 message size와 동시성에서 bandwidth·latency·retry가 허용되는 단계로 나눕니다.

잘못된 대응과 확인할 경계

운영망에서 무단 bandwidth test를 실행하면 실제 workload와 switch queue에 영향을 줍니다. 격리 창구와 rate 조건을 승인받습니다.

성능이 낮으면 먼저 link·NUMA·PCIe mapping과 단일 flow를 확인합니다. PFC·ECN을 동시에 바꾸지 말고 한 변경 뒤 host와 switch 양쪽 counter를 재측정합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 격리된 두 node fixture에서 RDMA device mapping과 성능 시험 조건을 검토합니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, retry·pause·tail latency 급증 조건이 보이면 다음 변경으로 넘어가지 마십시오.

link mlx5_0/1 state ACTIVE physical_state LINK_UP netdev enp65s0f0np0
mlx5_0 port 1 ==> enp65s0f0np0 (Up)
BW average[Gb/sec] 94.7

값 자체를 외우는 것이 아니라 RDMA port와 netdev mapping이 맞고 명시한 조건에서 목표 bandwidth를 재현하는지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

운영망에서 무단 bandwidth test를 실행하면 실제 workload와 switch queue에 영향을 줍니다. 격리 창구와 rate 조건을 승인받습니다.

KEY TERMS

이번 단원 핵심 용어

RDMA(Remote Direct Memory Access, 원격 메모리 직접 접근)
지원 NIC와 transport를 통해 원격 메모리로 데이터를 전달하는 방식입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

RDMA와 AI fabric의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

CORE UNIT 4 / 4

배선과 fabric 인수 시험

배선표·link·throughput·error counter로 Go/No-Go를 판정합니다.

난이도
중급
구성
강의 5개 · 실습 2개 · 평가

도해·표 자료: 각 강의의 공식 1차 출처를 바탕으로 저자 구성. 원문과 검토일은 해당 강의 끝에서 확인합니다.

PREREQUISITE CHECK

본문을 읽기 전에 확인할 세 가지

정답을 외우는 시험이 아닙니다. 질문을 먼저 생각한 뒤 해설을 열어 이번 과목에서 사용할 바탕 개념을 확인하십시오.

1이 단원에서 실제 장비에 명령을 전송합니까?

아닙니다. 교육용 출력을 브라우저에서 읽고 판단합니다. 별도 재현은 승인된 격리 환경에서만 수행합니다.

2실습 전에 확인할 권한과 환경은 무엇입니까?

network namespace 관리자·switch read-only. 격리 VLAN 198.51.100.0/24.

3앞 단원 「RDMA와 AI fabric」에서 어떤 증거를 남겼습니까?

device·GID·message size·duration·평균/최저 bandwidth와 오류 counter를 포함한 시험표를 작성하면 성공입니다.

TEXTBOOK GUIDE

개념의 배경부터 판단 기준까지 읽는 본문

IT를 처음 접하는 독자도 용어를 암기하지 않고 원인과 결과를 연결할 수 있도록 한 절씩 이어서 설명합니다.

  1. 배선과 fabric 인수 시험의 구성요소와 실패 경계를 구성도로 설명할 수 있다.
  2. 배선과 fabric 인수 시험의 상태를 명령 출력과 관측값으로 판정할 수 있다.
  3. 배선과 fabric 인수 시험의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.
배선과 fabric 인수 시험 실습 환경과 안전 경계
하드웨어2-port NIC fixture·leaf/spine 배선표
소프트웨어Ubuntu 24.04·iproute2·ethtool·rdma-core
필요 권한network namespace 관리자·switch read-only
네트워크격리 VLAN 198.51.100.0/24

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

적용 버전: Ubuntu Server 24.04 LTS · rdma-core 50.x fixture · 원고 검토일: 2026-09-01

CONCEPT FLOW

각 장은 이렇게 연결됩니다

각 장은 따로 외우는 단답이 아닙니다. 왼쪽에서 오른쪽으로 따라가며 앞 장의 개념이 다음 판단에 어떻게 쓰이는지 먼저 살펴보세요.

  1. 1장inventory에서 확인을 시작합니다
  2. 2장단일 link의 실습 대상을 고정합니다
  3. 3장전체 fabric의 출력과 의미를 구분합니다
  4. 4장인수 판정의 진행과 중단을 결정합니다
  5. 5장배선과 fabric 인수 시험의 복구를 재검증합니다
배선과 fabric 인수 시험의 전체 지도입니다. 아래 장문 해설과 각 장을 읽다가 길을 잃으면 이 순서로 돌아오세요.

CONTROLLED EXPLANATION

확인할 증거를 한 단계씩 따라갑니다

현재 설명 · 1/5 · inventory에서 확인을 시작합니다

다음 연결: 단일 link의 실습 대상을 고정합니다

  1. inventory에서 확인을 시작합니다

    원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

  2. 단일 link의 실습 대상을 고정합니다

    실습 상황:: 8-node acceptance fixture에서 평균은 통과하지만 한 node가 18% 느린 결과를 No-Go로 판정하고 증거 package를 만듭니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, node 편차·link flap·오류 증가 조건이 보이면 다음 변경으로 넘어가지 마십시오.

  3. 전체 fabric의 출력과 의미를 구분합니다

    값 자체를 외우는 것이 아니라 동일 revision의 topology에서 node별 collective 결과와 error delta가 인수 기준 안인지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

  4. 인수 판정의 진행과 중단을 결정합니다

    모든 node의 inventory, P50/P95 bandwidth, 최대 편차, error delta와 재시험 조건이 담긴 Go/No-Go 표를 제출하면 성공입니다. 결과에는 실행 시각, 대상 identity, 사용한 명령, 핵심 출력, 판정과 다음 행동을 함께 남깁니다.

  5. 배선과 fabric 인수 시험의 복구를 재검증합니다

    outlier node를 격리하고 cable·port·NUMA·PCIe·firmware 순서로 경계를 좁힙니다. 원인 변경 뒤 전체 matrix를 같은 revision으로 다시 실행합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

개념 해설 01

fabric 인수는 inventory에서 collective까지 단계적으로 진행합니다

Collective(집단 통신): 여러 rank가 정해진 순서로 함께 수행하는 데이터 교환 작업입니다.

fabric 인수는 최고 속도 한 번이 아니라 inventory 완전성, 경로 대칭성, 오류 없는 지속 부하, node별 편차와 복구 가능성을 승인하는 과정입니다.

collective workload는 가장 느린 participant와 barrier에 묶입니다. 평균이 목표를 넘더라도 한 node의 tail latency, 잘못된 NUMA placement, flap이나 corrected error가 있으면 production에서 전체 job을 지연시킵니다.

시험 matrix에는 cable/port identity, firmware, topology, message size, 동시 job 수, 측정 시간과 허용 편차가 포함되어야 합니다. 결과 파일은 revision과 hash를 남깁니다.

교육 사례에서 8개 rank 중 7개는 정상이고 한 rank의 통신 시간이 길어졌습니다. 평균 bandwidth가 목표를 넘더라도 모두가 기다리는 지점에서 전체 작업이 늦어질 수 있습니다. rank별 transport와 경로, message 크기별 결과를 같은 run ID에 묶습니다. 느린 rank의 배치를 바꿨을 때 문제가 따라가는지 비교하면 node와 경로 가설을 구분할 수 있습니다.

inventory·단일 link·전체 collective·오류 delta 네 단계를 통과 기준과 No-Go 조건으로 나눈 fabric 인수 판정표
그림 읽는 법 왼쪽 배지 1부터 4까지가 시험 순서이고, 각 행은 inventory·단일 link·전체 collective·오류 delta 한 단계씩입니다. 셋째 칸이 통과 기준이고 넷째 칸의 No-Go 조건이 하나라도 걸리면 전체 판정은 No-Go입니다. 3행의 1073741824 · algbw 89.4 · busbw 156.5 · error 0과 4행의 rx_crc_errors: 0은 저자 구성 교육용 예시 값이며 장비·driver·cluster마다 달라집니다. 3행의 No-Go 칸이 이 단원의 핵심입니다 — 8 rank 중 1 rank가 18% 느리면 평균 bandwidth가 목표를 넘어도 No-Go로 판정합니다. 아래 초록색 정리 상자에 적힌 대로 collective는 가장 느린 participant의 barrier에 묶이므로, outlier node를 격리하고 cable·port·NUMA·PCIe·firmware 순서로 경계를 좁힌 뒤 같은 revision으로 전체 matrix를 다시 실행합니다. 표는 인수 단계와 판정 기준을 담은 것이며 실제 배선 topology를 그린 그림이 아닙니다. 자료: NVIDIA Networking Documentation · NVIDIA nccl-tests를 바탕으로 저자 구성.
왜 이런가
collective workload는 가장 느린 participant와 barrier에 묶입니다. 평균이 목표를 넘더라도 한 node의 tail latency, 잘못된 NUMA placement, flap이나 corrected error가 있으면 production에서 전체 job을 지연시킵니다.
언제 문제가 되는가
node 편차·link flap·오류 증가 조건이면 진행 근거가 부족합니다.
초보자가 자주 하는 오해
느린 node를 평균에 묻어 승인하면 collective의 barrier 때문에 실제 job 전체가 느려집니다. outlier는 별도 원인과 재시험이 필요합니다.
직접 확인하는 방법
배선표와 실제 port·module·firmware 목록의 완전성을 확인합니다. 각 link를 동일 조건의 point-to-point 시험으로 비교합니다.
이 절을 정리하면모든 node의 inventory, P50/P95 bandwidth, 최대 편차, error delta와 재시험 조건이 담긴 Go/No-Go 표를 제출하면 성공입니다.

CHAPTER 1 / 5

inventory에서 확인을 시작합니다

원인을 추측해서 설정부터 바꾸지 않습니다. 다음 증거를 같은 시각대의 기록으로 묶으면 어느 경계에서 기대 상태가 깨졌는지 다른 운영자도 재현할 수 있습니다.

1. 배선표와 실제 port·module·firmware 목록의 완전성을 확인합니다. 2. 각 link를 동일 조건의 point-to-point 시험으로 비교합니다. 3. 대표 collective를 여러 크기와 반복 횟수로 실행해 분포를 구합니다. 4. 시험 전후 error counter delta와 flap event를 저장합니다.

CHAPTER 2 / 5

단일 link의 실습 대상을 고정합니다

격리 환경 재현용 명령 · 브라우저에서는 실행하지 않습니다
sha256sum topology.csv firmware.txt test-plan.yaml
mpirun -np 8 --hostfile hosts ./all_reduce_perf -b 8M -e 1G -f 2 -g 1
ethtool -S enp65s0f0np0 | grep -Ei 'error|discard|pause'

CHAPTER 3 / 5

전체 fabric의 출력과 의미를 구분합니다

교육용 예상 출력 · 실제 측정값 아님
<hash>  topology.csv
# size count type redop root time algbw busbw error
1073741824 ... 89.4 156.5 0
rx_crc_errors: 0

CHAPTER 4 / 5

인수 판정의 진행과 중단을 결정합니다

CHAPTER 5 / 5

배선과 fabric 인수 시험의 복구를 재검증합니다

CONCRETE CASES

8-node acceptance fixture에서 평균은 통과하지만 한 node가 18% 느린 결과를 No-Go로 판정하고 증거 package를 만듭니다.

시험 matrix에는 cable/port identity, firmware, topology, message size, 동시 job 수, 측정 시간과 허용 편차가 포함되어야 합니다. 결과 파일은 revision과 hash를 남깁니다.

잘못된 대응과 확인할 경계

느린 node를 평균에 묻어 승인하면 collective의 barrier 때문에 실제 job 전체가 느려집니다. outlier는 별도 원인과 재시험이 필요합니다.

outlier node를 격리하고 cable·port·NUMA·PCIe·firmware 순서로 경계를 좁힙니다. 원인 변경 뒤 전체 matrix를 같은 revision으로 다시 실행합니다. 복구 뒤에는 같은 명령과 같은 성공 기준으로 다시 측정합니다. 정상처럼 보인다는 표현만으로 incident를 닫지 않습니다.

INTERACTIVE LAB 1 / 2

실습 1 · 출력에서 판정 근거 찾기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

실습 상황:: 8-node acceptance fixture에서 평균은 통과하지만 한 node가 18% 느린 결과를 No-Go로 판정하고 증거 package를 만듭니다. 수행 지시:: 브라우저에서는 아래의 교육용 출력을 읽고 판정문을 작성합니다. 명령을 실제 장비로 보내지 않습니다. 명령을 별도로 재현하려면 해당 도구와 예제 파일을 갖춘 승인된 격리 환경을 준비해야 합니다. 출력 전체를 저장하고, node 편차·link flap·오류 증가 조건이 보이면 다음 변경으로 넘어가지 마십시오.

<hash>  topology.csv
# size count type redop root time algbw busbw error
1073741824 ... 89.4 156.5 0
rx_crc_errors: 0

값 자체를 외우는 것이 아니라 동일 revision의 topology에서 node별 collective 결과와 error delta가 인수 기준 안인지를 확인해야 합니다. 표시한 값은 교육용 재현 예시이며 실제 장비에서 측정한 결과가 아닙니다. 장비·driver·cluster마다 식별자와 수치는 달라질 수 있습니다.

INTERACTIVE LAB 2 / 2

실습 2 · 중단과 복구 계획 세우기

브라우저 안에서 값을 입력하고 실행 결과와 실패·복구 경로를 확인합니다. 실제 장비나 NAS에는 어떤 명령도 보내지 않습니다.

느린 node를 평균에 묻어 승인하면 collective의 barrier 때문에 실제 job 전체가 느려집니다. outlier는 별도 원인과 재시험이 필요합니다.

KEY TERMS

이번 단원 핵심 용어

Collective(집단 통신)
여러 rank가 정해진 순서로 함께 수행하는 데이터 교환 작업입니다.

UNIT WORKBOOK

개념을 새로운 상황에 적용하는 문제와 기록지

기본 원리 확인에서 시작해 실제 업무 판단으로 확장합니다. 답을 제출하면 정답만이 아니라 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

배선과 fabric 인수 시험의 중단 조건과 복구 증거를 작업 기록으로 작성할 수 있다.

PERSONAL WORKSHEET

내 환경에 옮겨 적는 학습 기록지

입력 내용은 현재 브라우저 화면에만 머물며 저장하거나 외부로 전송하지 않습니다. 민감한 실제 정보 대신 범주와 가명을 사용하십시오.

OFFICIAL SOURCES

공식 자료에서 다시 확인하기

공식 문서와 교육용 출력 판독 검토. 실장비 명령·성능 시험은 미확인입니다.

DECISION ACTIVITY

8개 node 중 한 node의 RDMA throughput만 낮고 symbol error가 증가합니다. 첫 행동은?

먼저 필요한 증거와 중단 기준을 적은 뒤 판단을 선택하십시오.

답 선택

THREE-LEVEL ASSESSMENT

기본 원리에서 운영 판단까지

답을 제출하면 모든 선택지가 맞거나 틀린 이유를 확인할 수 있습니다.

기본 문제 1

carrier가 up이라는 사실이 보장하지 않는 것은?

답 선택
적용 문제 2

MTU 불일치를 찾는 데 알맞은 시험은?

답 선택
종합 문제 3

fabric 인수에서 평균 bandwidth만으로 부족한 이유는?

답 선택

LEARNING RECORD

본문·판단 활동·모든 해설을 확인했나요?

완료 기록은 이 브라우저에만 저장됩니다.