26O06a
네. 이번에는 quoting에서 확인된 실제 NIC 장수를 기준으로 다시 잡았습니다. 특히 GPU는 ConnectX-7 ×4가 장착되어 있지만, NDR 스위치/광모듈/케이블 수량을 역산하면 4장 중 2장만 실제 NDR Fabric에 연결되는 설계로 보는 것이 가장 일관됩니다.
1. NDR400 InfiniBand 설계
구성은 다음처럼 보는 것을 권장합니다.
MQM9700 Spine-01
56 / 64
/ | \
/ | \
┌───────┴──────┴────────┐
│ │
MQM9790 MQM9790
Leaf-01 ... Leaf-04
│ │
├──── GPU CX-7 │
├──── AIStor CX-7 │
│ │
└──────── Spine-02 ──────┘
MQM9700GPU 한 대는:
XE9780
├─ CX7-0 ── 400G NDR ── Leaf-X ACTIVE
├─ CX7-1 ── 400G NDR ── Leaf-Y ACTIVE
│
├─ CX7-2 미연결 / Reserve
└─ CX7-3 미연결 / ReserveAIStor 한 대는:
SR650 V4
├─ CX7-0 ── 400G NDR ── Leaf-X
└─ CX7-1 ── 400G NDR ── Leaf-Y여기서 Leaf-X ≠ Leaf-Y가 되도록 하는 게 중요합니다. 같은 서버의 두 NDR 포트를 동일 Leaf에 연결하지 않는 것을 권장합니다.
수량도 정확히 맞습니다.
| 구분 | 계산 | NDR 400G links |
|---|---|---|
| GPU | 12 × 2 active | 24 |
| AIStor | 55 × 2 | 110 |
| Server-facing | 134 | |
| Leaf↔Spine | 112 | |
| 총 Cable | 134 + 112 | 246 |
| Leaf capacity | 4 × 64 | 256 |
| Spare | 10 |
따라서 현재 스위치 BOM은 우연히 맞는 수준이 아니라 GPU당 CX-7 2장만 연결하는 것을 전제로 계산된 설계일 가능성이 높습니다.
NDR400_Revised_GPU12_AIStor55.drawioNDR400 InfiniBand Draw.io 다운로드
2. 일반 100GbE Ethernet 설계
여기서는 세 서버군의 차이가 명확합니다.
Compute와 AIStor는 100G가 4포트이므로 기존 사이트의 bond0=Public / bond1=Private 구조를 그대로 가져갈 수 있습니다.
Public Fabric
Leaf-A Leaf-B
│ │
100G 100G
│ │
└──── bond0 ─────┘
│
Compute/AIStor
│
┌──── bond1 ─────┐
│ │
100G 100G
│ │
Private-A Private-B
K8s/Cilium특히 NIC 카드 장애까지 고려해서 같은 dual-port NIC의 두 포트를 하나의 bond에 몰지 않고:
NIC-A/p0 + NIC-B/p0 → bond0
NIC-A/p1 + NIC-B/p1 → bond1로 만드는 것을 권장합니다. 그러면 NIC-A 카드 전체가 죽어도 bond0와 bond1 모두 NIC-B 쪽으로 살아남습니다.
반면 GPU는 Broadcom dual-port 100GbE ×1뿐이라 총 2포트입니다. 따라서 저는 현재 BOM을 유지한다면:
GPU Broadcom
port0 ──100G── Private Leaf-A
\
bond1
/
port1 ──100G── Private Leaf-B처럼 두 포트를 모두 bond1/Kubernetes Private에 배정하겠습니다.
GPU에는 별도의 bond0를 만들지 않고:
External Client
│
Public Fabric
│
Compute / Infra
Ingress / LB
│
Private Fabric
│
GPU Pod경로로 외부 서비스를 제공합니다. GPU node가 직접 Public network에 붙을 이유도 줄어들어서 보안/운영 측면에서도 괜찮은 구조입니다.
Ethernet_Revised_3Cluster_NIC_Bond.drawio일반 Ethernet NIC/Bond Draw.io 다운로드
최종적으로 서버 한 대를 보면
GPU는 2×100G → bond1, 2×400G CX-7 → NDR, 나머지 2×CX-7 → reserve가 됩니다.
AIStor는 2×100G → bond0, 2×100G → bond1, 2×400G CX-7 → NDR입니다.
Compute는 2×100G → bond0, 2×100G → bond1이고 NDR은 없습니다.
그래서 전체적으로는 아주 깔끔하게 세 plane으로 분리됩니다.
AI Platform
┌────────────┼─────────────┐
│ │ │
bond0 bond1 NDR400
│ │ │
PUBLIC PRIVATE InfiniBand
│ │ │
External/S3 Kubernetes GPU↔GPU
API/Ingress Cilium GPU↔AIStor
BGP/ECMP AIStor↔AIStor여기서 한 가지는 최종 네트워크 상세설계 전에 반드시 확정해야 합니다. 100G Ethernet switch가 두 Leaf를 MLAG/MC-LAG/EVPN multihoming으로 제공하는지입니다. 그래야 Compute/AIStor의 2×100G LACP bond0/bond1과 GPU의 2×100G bond1을 active-active로 설계할 수 있습니다. 그 기능이 없다면 bonding mode를 active-backup으로 하거나 L3 routed dual-homing으로 설계를 바꿔야 합니다.
네. 지금까지 확인한 NDR BOM과 실제 서버 수량을 기준으로 보면, NDR Fabric은 oversubscription이 있습니다. 단순 포트/대역폭 기준으로는 약 1.20:1입니다.
현재 구성은 GPU 12대에서 CX-7 4장 중 2장만 연결하므로 12 × 2 = 24개의 400G 링크, AIStor 55대는 CX-7 2장을 모두 연결하므로 55 × 2 = 110개의 400G 링크입니다. 따라서 server-facing downlink는 총 134 × 400G = 53.6 Tbps입니다.
반면 Leaf→Spine은 BOM상 112 × 400G = 44.8 Tbps입니다.
따라서:
[
Oversubscription = \frac{53.6}{44.8}
= \frac{134}{112}
\approx \mathbf{1.196:1}
]
즉 약 1.20:1 oversubscription입니다.
Leaf 단위로 보면
4대의 MQM9790 Leaf에 112개 uplink를 균등하게 나누면 Leaf당 28×400G uplink = 11.2 Tbps입니다.
서버 downlink를 앞서처럼 34 / 34 / 34 / 32로 배치한다면:
| Leaf | Server Downlink | Spine Uplink | Oversubscription |
|---|---|---|---|
| Leaf-01 | 34×400G = 13.6T | 28×400G = 11.2T | 1.21:1 |
| Leaf-02 | 34×400G = 13.6T | 28×400G = 11.2T | 1.21:1 |
| Leaf-03 | 34×400G = 13.6T | 28×400G = 11.2T | 1.21:1 |
| Leaf-04 | 32×400G = 12.8T | 28×400G = 11.2T | 1.14:1 |
| 전체 | 53.6T | 44.8T | 1.20:1 |
따라서 1:1 non-blocking fabric은 아닙니다.
다만 이것이 곧바로 GPU↔AIStor가 항상 20% 느려진다는 뜻은 아닙니다. 동일 Leaf 내 GPU↔AIStor 트래픽은 Spine을 통과하지 않기 때문입니다.
Same Leaf
GPU ─400G─┐
│
Leaf
│
AIStor─400G┘
→ Spine uplink 사용 안 함다른 Leaf로 가야 할 때만:
GPU
│400G
Leaf-01
│
│ Leaf→Spine
▼
Spine
│
▼
Leaf-03
│400G
AIStor이 경로가 됩니다.
그래서 GPU와 AIStor를 같은 rack/Leaf에 적절히 섞어 배치하고 locality-aware하게 traffic을 만들면 실제 workload에서 느끼는 oversubscription은 1.20:1보다 작을 수 있습니다.
그런데 GPU↔AIStor만 보면 또 다른 관점이 있습니다
GPU NDR 총량은:
[
12 × 2 × 400G = \mathbf{9.6 Tbps}
]
AIStor NDR 총량은:
[
55 × 2 × 400G = \mathbf{44 Tbps}
]
입니다.
즉 순수하게 GPU 12대가 AIStor 55대에서 데이터를 읽고 쓰는 트래픽만 생각하면 GPU 측 최대 9.6T가 먼저 제한점입니다. 44.8T의 Leaf-Spine aggregate보다 훨씬 작습니다.
따라서 현재 1.20:1 oversubscription이 실제 문제가 될 가능성이 더 큰 상황은 GPU↔AIStor + AIStor↔AIStor + GPU↔GPU/NCCL이 동시에 fabric을 크게 사용하는 경우입니다.
특히 distributed training에서는 GPU↔GPU NCCL traffic이 상당할 수 있기 때문에 단순히 "AIStor가 44T니까 충분하다"라고 판단하면 안 됩니다.
결론
현재 NDR 설계에 대한 제 판단은:
1.20:1 oversubscribed fabric이 맞지만, 수치 자체는 심한 oversubscription은 아니다.
다만 사진에 적혀 있던 1:1.03 / 1:1.1 Blocking이라는 표현은 현재 확인된 134 server links / 112 spine links의 단순 산술과는 일치하지 않습니다. 현재 수량으로는 1.196:1 ≈ 1.20:1이 맞습니다.
그래서 업체에는 이 부분을 이렇게 확인하는 게 좋습니다.
“GPU 12대×2 NDR + AIStor 55대×2 NDR 기준 server-facing 134×400G이고 LF-SP가 112×400G이므로 aggregate blocking ratio는 약 1.20:1로 계산됩니다. 제안서의 1:1.03 / 1:1.1 blocking ratio는 어떤 traffic model 및 topology 기준으로 산정된 값인지 확인 부탁드립니다.”
그리고 성능을 최우선으로 본다면 blocking ratio 숫자보다 더 중요한 것은 GPU의 두 CX-7이 어느 Leaf에 연결되는지, AIStor 두 CX-7의 Leaf 분산, GPU↔NIC PCIe affinity, GPU/AIStor rack locality, NCCL traffic과 storage traffic이 동일 NDR fabric을 동시에 얼마나 사용하는지입니다.
이 다섯 가지를 포함한 NDR 성능 검증 체크리스트/PoC 항목을 만들어 실제 구축 전에 검증하는 것이 좋습니다.
아니요. NDR InfiniBand에는 Cilium Native Routing + BGP + ECMP 구조를 그대로 적용하지 않습니다. 이번 설계에서는 Ethernet/IP plane과 InfiniBand/RDMA plane을 명확하게 분리해서 생각하는 게 맞습니다.
개념적으로는 다음과 같습니다.
Kubernetes Node
┌─────────────────────────────┐
│ │
│ 100GbE NDR400 │
│ bond1 CX-7 │
│ │ │ │
└────┼─────────────────┼──────┘
│ │
▼ ▼
Ethernet Fabric InfiniBand Fabric
│ │
Cilium Native IB Subnet Manager
BGP LID/GID
ECMP Adaptive Routing
PodCIDR P_Key
│ │
Kubernetes IP RDMA / NCCL
Network GPUDirect즉 기존 환경의 Cilium/BGP/ECMP는 100GbE Ethernet 쪽에 그대로 유지하고, NDR에는 InfiniBand 고유의 control/data plane을 사용합니다.
Ethernet에서는 지금 방식 그대로
예를 들어 GPU node가:
bond1
├─ 100G → Private Leaf-A
└─ 100G → Private Leaf-B
↓
Cilium Native Routing
↓
BGP advertisement
↓
Leaf / Spine ECMP
↓
PodCIDR / Service traffic처럼 동작할 수 있습니다.
여기서 Cilium이 Pod의 IP connectivity를 담당하고 BGP가 PodCIDR이나 필요한 Service prefix를 네트워크에 광고합니다.
InfiniBand는 완전히 다른 방식
NDR에서는:
GPU
│
CX-7
│ 400G NDR
▼
IB Leaf
│
▼
IB Spine
│
▼
IB Leaf
│
CX-7
│
AIStor가 되고 여기에 Cilium BGP를 태우지 않습니다.
InfiniBand fabric에서는 Subnet Manager(SM) 가 핵심입니다. SM이 topology를 발견하고 LID를 할당하고 forwarding/routing 정보를 구성합니다.
그래서 대략 대응시켜 보면:
| Ethernet/K8s | InfiniBand |
|---|---|
| Ethernet Fabric | InfiniBand Fabric |
| Cilium Native Routing | 해당 없음 |
| BGP | Subnet Manager |
| IP Prefix | LID/GID 기반 addressing |
| ECMP | IB multipath / Adaptive Routing |
| VLAN/VRF | P_Key/Partition |
| TCP/UDP | RDMA Verbs |
| NIC | HCA (ConnectX-7) |
| 일반 DMA | GPUDirect RDMA 가능 |
완전히 1:1 대응되는 개념은 아니지만 설계 관점에서는 이렇게 생각하면 이해하기 쉽습니다.
특히 ECMP와 Adaptive Routing 차이가 중요합니다
Ethernet에서는 보통:
Spine-1
/ \
Server → Leaf Leaf → Server
\ /
Spine-2
BGP ECMP
→ flow hash
→ path 선택을 사용합니다.
IB에서도 Spine이 2대라 여러 경로가 존재하지만, 이를 BGP ECMP로 처리하는 게 아닙니다.
Quantum-2 기반 InfiniBand에서는 Subnet Manager의 routing 및 Adaptive Routing 등의 기능으로 fabric path를 활용할 수 있습니다.
즉 이번 2 Spine + 4 Leaf NDR 구조에서 확인해야 하는 것은:
"ECMP 설정되어 있나요?"
보다는
"Subnet Manager의 routing engine과 Adaptive Routing이 어떤 정책으로 구성됩니까?"
가 더 정확한 질문입니다.
Kubernetes에서는 두 네트워크를 어떻게 같이 쓰나?
이 부분이 이번 아키텍처에서 중요합니다.
GPU Pod가 있다고 하면 기본 Kubernetes network는:
GPU Pod
│
eth0
│
Cilium
│
bond1
│
100GbE Ethernet입니다.
반면 학습 workload에서 RDMA가 필요하면:
GPU Pod
│
├─ eth0
│ ↓
│ Cilium
│ ↓
│ bond1 / Ethernet
│
└─ RDMA device
↓
ConnectX-7
↓
NDR InfiniBand처럼 두 datapath가 동시에 존재하게 됩니다.
따라서 저는 NDR를 bond2 같은 것으로 만들어 Cilium에 넣는 구조를 권하지 않습니다.
NCCL traffic 예를 들면
GPU-1과 GPU-2가 distributed training을 한다면:
Kubernetes control/service traffic
Pod-1
│ eth0
▼
Cilium
│
bond1
│
100G Ethernet
│
Cilium
▼
Pod-2와 별도로 실제 GPU collective traffic은:
GPU-1
│
GPUDirect
│
CX-7
│
400G NDR
│
IB Fabric
│
400G NDR
│
CX-7
│
GPUDirect
▼
GPU-2가 될 수 있습니다.
즉 Cilium은 이 NCCL NDR data path의 중간에 있지 않습니다.
이게 오히려 성능 측면에서 원하는 구조입니다.
GPU ↔ AIStor도 같은 원칙
이번 환경에서는 이것이 특히 중요합니다.
GPU Node
┌──────────┐
K8s/Cilium ←──│ 100GbE │
│ │
RDMA ─────────│ CX-7 │
└────┬─────┘
│
NDR400
│
IB Leaf/Spine
│
NDR400
│
┌────┴─────┐
S3/IP ←──│ 100GbE │ AIStor
RDMA ←──│ CX-7 │
└──────────┘따라서 AIStor 접근에도 두 종류의 경로가 존재할 수 있습니다.
일반 S3/IP access는:
Pod → Cilium → bond1/bond0 → Ethernet → AIStor S3 endpoint
이고, AIStor가 지원하는 RDMA data path를 구성하면:
GPU/Memory → CX-7 → NDR IB → CX-7 → AIStor
라는 별도의 고속 경로가 됩니다.
여기서도 ClusterMesh가 NDR connectivity를 만들어 주는 것은 아닙니다. GPU Cluster와 AIStor Cluster가 서로 다른 Kubernetes cluster여도 물리적인 InfiniBand fabric과 필요한 RDMA endpoint 구성이 제대로 되어 있다면 NDR data plane은 별도로 성립할 수 있습니다.
이번 환경에서는 이렇게 역할을 고정하는 것을 권장합니다
전체 AI Infrastructure
┌─────────────────────────────────────────────────────────┐
│ 100G Ethernet Fabric │
│ │
│ Cilium Native Routing │
│ BGP + ECMP │
│ │
│ • Kubernetes Node │
│ • PodCIDR │
│ • Service/VIP │
│ • ClusterMesh │
│ • API / Monitoring │
│ • 일반 S3/IP │
└────────────────────────┬────────────────────────────────┘
│
Control / IP Plane
┌────────────────────────┴────────────────────────────────┐
│ NDR400 IB Fabric │
│ │
│ Subnet Manager / UFM │
│ IB Routing │
│ Adaptive Routing │
│ P_Key / Partition │
│ │
│ • NCCL │
│ • GPUDirect RDMA │
│ • GPU ↔ GPU │
│ • GPU ↔ AIStor RDMA │
│ • AIStor ↔ AIStor RDMA │
└─────────────────────────────────────────────────────────┘
│
AI Data Plane그래서 현재 설계 방향은 "기존 Cilium/BGP/ECMP 설계를 NDR에도 적용"이 아니라, "Ethernet은 기존 방식을 계승하고 NDR은 별도의 IB fabric으로 최적화"가 맞습니다.
그리고 이 관점에서 보면 앞서 계산한 NDR 1.20:1 oversubscription을 평가할 때도 Ethernet ECMP를 어떻게 설정할지가 아니라 Quantum-2의 routing/adaptive routing, GPU/AIStor의 Leaf 배치, rail 설계, Subnet Manager/UFM 설정을 봐야 합니다.
특히 다음 단계에서 GPU의 2×CX-7을 어떤 Leaf에 연결할지와 AIStor의 2×CX-7을 어떤 Leaf에 연결할지를 구체적인 GPU01~12 / Storage01~55 / Leaf01~04 포트 매핑으로 설계해 보는 게 좋습니다. 이걸 잘 잡아야 현재 1.20:1 NDR fabric에서 실제 성능을 최대한 끌어낼 수 있습니다.
현재 전제인 Cilium Native Routing + BGP + ECMP를 최대한 살린다면, 제 1순위는 EVPN-MH가 아니라 아예 서버-facing도 L3 dual-homing입니다. 다만 질문하신 세 가지 중 하나를 선택해야 하고 서버에서 bond0/bond1 = 2×100G LACP Active-Active를 유지하려면 EVPN-MH가 가장 자연스럽습니다.
핵심은 Cilium이 이미 BGP로 PodCIDR 등을 Leaf에 광고하고 ECMP를 쓰고 있다는 점입니다. 이 환경은 본질적으로 L3 routed fabric과 잘 맞습니다.
Spine-1 Spine-2
\ /
\ BGP/ECMP /
\ /
Leaf-A Leaf-B
│ │
100G │ │ 100G
│ │
└── Server ┘
bond1여기서 서버의 두 링크까지 각각 L3로 독립시키면 MLAG 계열 자체가 필요 없습니다. Cilium/BGP/ECMP 철학과 가장 잘 맞고, Leaf 간 peer-link 같은 L2 상태 의존성도 줄어듭니다.
하지만 기존 환경처럼 반드시 서버에:
bond1
├── 100G → Leaf-A
└── 100G → Leaf-B
802.3ad / LACP
Active + Active를 만들고 싶다면 Leaf-A/B가 하나의 LAG 상대처럼 보여야 합니다. 이때 세 후보를 비교하면 대략 이렇습니다.
| 방식 | 서버 LACP A/A | Leaf간 상태 의존 | BGP/EVPN Fabric 적합성 | 이번 환경 |
|---|---|---|---|---|
| MRAG 계열 | 가능 | 높음 | 보통 | △ |
| MC-RAG/MC-LAG | 가능 | 높음 | 보통 | ○ |
| EVPN-MH | 가능 | 상대적으로 낮음 | 매우 좋음 | ◎ |
따라서 Leaf-Spine 자체를 BGP EVPN 기반으로 설계한다면 EVPN-MH를 권합니다.
구조는 이렇게 됩니다.
BGP / EVPN Fabric
┌────────────────────────┐
│ │
Spine-1 Spine-2
│ │
┌────┴────────────────────────┴────┐
│ │
Leaf-A ============================ Leaf-B
│ EVPN-MH / ESI │
│ │
100G 100G
│ │
└──────────────┬───────────────────┘
│
bond1
LACP A/A
│
Kubernetes Node
│
Cilium
│
BGP PodCIDR여기서 중요한 점은 두 종류의 BGP를 구분하는 것입니다.
Cilium의 BGP는 주로:
Cilium
│
└─ BGP → Leaf
PodCIDR
Service VIP 등을 광고하는 것이고, Fabric의 BGP EVPN은:
Leaf ↔ Spine ↔ Leaf
│
EVPN
│
MAC/IP reachability
Ethernet Segment
ESI / multihoming을 담당합니다. 같은 BGP 기술을 사용하지만 역할과 address family가 다릅니다.
그런데 bond1은 굳이 LACP가 필요한가?
여기가 설계 결정의 핵심입니다.
현재 bond1은 Kubernetes/Cilium native-routing network입니다. 즉 Pod traffic이 L2 network에 의존하는 구조가 아니라 BGP를 통해 routed되는 구조입니다.
그래서 새 환경을 처음부터 설계한다면 저는 다음 두 안을 비교하겠습니다.
안 A — 기존 방식 최대 계승
Node
│
bond1 2×100G LACP
│ │
Leaf-A Leaf-B
│ │
└── EVPN-MH ──┘
│
BGP/EVPN Fabric장점은 서버가 하나의 bond1 IP만 가지므로 Linux/Kubernetes 운영이 단순하고, 기존 운영 방식과 비슷하며, 여러 flow 기준 200G aggregate도 가능합니다.
안 B — L3 Native Dual-Homing
Kubernetes Node
/ \
100G 100G
/ \
Leaf-A Leaf-B
\ /
\── BGP/ECMP ─/서버-facing까지 L3로 처리할 수 있다면 EVPN-MH/MLAG에 대한 의존성을 없앨 수 있습니다.
대규모 Kubernetes routed fabric이라는 관점에서는 B안이 더 깔끔한 방향입니다. 다만 Cilium host routing, node IP 구성, BGP peering 방식, failure handling 등을 현재 운영 모델과 맞춰야 하므로 기존 환경을 그대로 이전하는 것보다 설계 변경 폭이 큽니다.
그래서 현재 프로젝트라면
제가 설계 우선순위를 정한다면:
1순위
L3 dual-homing + BGP/ECMP
2순위
EVPN-MH + LACP
3순위
MC-LAG/MC-RAG 계열 + LACP
입니다.
특히 GPU/AIStor/Compute가 총 127대이고, Cilium Native Routing + BGP + ECMP를 이미 운영해 본 환경이라면 단순히 "200G bond를 만들기 위해 MLAG부터 넣는다"보다는 L3 ECMP를 서버 edge까지 확장할 수 있는지를 먼저 검토하는 편이 좋습니다.
다만 bond0(Public)과 bond1(Private)을 반드시 같은 방식으로 할 필요도 없습니다. 예를 들어 bond0 = EVPN-MH/LACP, Kubernetes의 bond1 = L3/BGP/ECMP처럼 역할별로 다르게 설계하는 것도 충분히 가능합니다.
이 프로젝트에서는 오히려 이 bond1 LACP/EVPN-MH vs bond1 L3 dual-homing/BGP ECMP 비교가 중요한 설계 포인트입니다. 원하시면 다음 답변에서 두 방식을 GPU/Compute/AIStor의 실제 NIC 2/4/4포트에 대입해서 포트 단위 구성도와 장애 시 traffic path까지 비교해드릴게요.
좋습니다. 지금 확정된 실제 NIC 구성을 그대로 대입하면, 두 방식의 차이가 꽤 명확해집니다.
먼저 결론부터 말하면, 이번 환경에서는 bond0(Public)은 EVPN-MH/LACP, bond1(Kubernetes Private)은 L3 dual-homing + BGP/ECMP의 혼합형을 우선 검토하는 게 좋습니다. 다만 GPU는 Ethernet이 2포트뿐이라 예외적으로 더 신중해야 합니다.
1. 실제 NIC 기준
| 서버 | Ethernet NIC | 총 100G Port | 현재 역할 |
|---|---|---|---|
| GPU XE9780 ×12 | Broadcom Dual-port ×1 | 2 | Private/K8s 위주 |
| Compute DL380 ×60 | Intel E810 Dual-port ×2 | 4 | Public + Private |
| AIStor SR650 ×55 | Broadcom Dual-port ×2 | 4 | Public + Private |
NDR400/CX-7은 이번 비교에서 제외합니다. NDR은 별도의 InfiniBand fabric입니다.
방식 A — EVPN-MH + LACP
기존 bond0/bond1 운영 모델과 가장 비슷합니다.
GPU — 2 ports
GPU는 100G 포트가 딱 2개이므로 둘 다 Private에 사용합니다.
GPU XE9780
Broadcom Dual-port 100G
┌─────────────────────────┐
│ │
│ p0 100G p1 100G │
└───┬──────────────┬──────┘
│ │
│ │
Private Leaf-A Private Leaf-B
│ │
└──── EVPN-MH ──┘
│
LACP bond1
│
2 × 100G
Active-ActiveLinux에서는 개념적으로:
bond1
├─ p0 → Leaf-A
└─ p1 → Leaf-B
mode = 802.3ad정상 시 200G aggregate, 일반적으로 single flow는 최대 100G 수준입니다.
Leaf-A 또는 p0 장애 시:
Before
p0 ─100G─ Leaf-A ACTIVE
p1 ─100G─ Leaf-B ACTIVE
↓ Leaf-A 장애
p0 ── X
p1 ─100G─ Leaf-B ACTIVE
→ 100G로 계속 서비스즉 200G → 100G로 degradation됩니다.
GPU는 Public 포트가 없으므로 외부 트래픽은 Compute/Infra의 Ingress/LB를 거치는 구조가 됩니다.
Compute — 4 ports
E810 dual-port 카드가 두 장이므로 제가 권했던 물리 배치는 카드 장애까지 고려해서 bond를 두 카드에 걸쳐 구성하는 것입니다.
Compute DL380
E810-A E810-B
┌────────────┐ ┌────────────┐
│ p0 p1 │ │ p0 p1 │
└─┬──────┬───┘ └─┬──────┬───┘
│ │ │ │
│ │ │ │
Public-A Private-A Public-B Private-B
│ │ │ │
└──────┼───────────────────────┘ │
│ │
bond0 = E810-A/p0 + E810-B/p0
Public 2×100G LACP
bond1 = E810-A/p1 + E810-B/p1
Private 2×100G LACP따라서 정상 시:
bond0 = 200G aggregate
bond1 = 200G aggregate입니다.
이렇게 하면 E810-A 카드 전체가 죽어도:
E810-A
p0 X
p1 X
E810-B
p0 → bond0 Public 100G
p1 → bond1 Private 100G가 되어 Public/Private 모두 살아 있습니다.
이게 NIC-A 하나를 Public, NIC-B 하나를 Private으로 통째로 나누는 것보다 훨씬 좋은 이유입니다.
AIStor — 4 ports
AIStor도 동일한 원칙입니다.
AIStor SR650
Broadcom-A Broadcom-B
┌────────────┐ ┌────────────┐
│ p0 p1 │ │ p0 p1 │
└─┬──────┬───┘ └─┬──────┬───┘
│ │ │ │
Public-A Private-A Public-B Private-B
bond0
A/p0 + B/p0
↓
Public Leaf-A/B
↓
EVPN-MH
↓
200G aggregate
bond1
A/p1 + B/p1
↓
Private Leaf-A/B
↓
EVPN-MH
↓
200G aggregateAIStor에서도 한 NIC 카드 장애 후 각각 100G씩 남습니다.
방식 B — L3 Dual-Homing + BGP/ECMP
여기서는 중요한 변화가 생깁니다.
두 100G 포트를 하나의 LACP bond로 묶는 사고방식에서 벗어납니다.
Node
/ \
100G 100G
│ │
Leaf-A Leaf-B
\ /
\--- BGP/ECMP -/각 링크가 독립된 routed path가 됩니다.
Compute/AIStor에서 적용
Private 쪽을 예로 들면:
Compute Node
E810-A/p1 E810-B/p1
100G 100G
│ │
│ L3 │ L3
▼ ▼
Private Leaf-A Private Leaf-B
│ │
└──── BGP/ECMP ────┘여기서는 Leaf가 LACP peer가 아닙니다.
개념적으로:
Node
│
├── path A → Leaf-A
│
└── path B → Leaf-B
BGP
│
ECMP
│
Spine가 됩니다.
따라서 EVPN-MH나 MLAG가 없어도 됩니다.
장애 시 차이가 더 재미있습니다
EVPN-MH 방식에서는 Leaf-A가 죽으면:
bond1
/ \
100G 100G
X │
Leaf-A Leaf-B
X │
▼
FabricLACP가 member 하나를 제거합니다.
결과:
2×100G → 1×100G
입니다.
L3+BGP/ECMP에서는:
Node
/ \
path-A path-B
X │
Leaf-A Leaf-B
X │
▼
SpineBGP/BFD/route convergence에 의해 죽은 path가 ECMP에서 빠집니다.
역시 결과는:
2×100G path → 1×100G path
입니다.
즉 최종 결과는 비슷하지만 장애를 처리하는 계층이 다릅니다.
| EVPN-MH/LACP | L3+BGP/ECMP | |
|---|---|---|
| Link 장애 감지 | LACP/link | Routing/BFD/link |
| Leaf 장애 처리 | EVPN-MH/LACP | BGP convergence |
| 경로 선택 | LAG hash | ECMP hash |
| Leaf 간 L2 multihoming | 필요 | 불필요 |
| Peer-link 의존 | 구현에 따라 | 없음 |
| Kubernetes routed fabric 궁합 | 좋음 | 매우 좋음 |
Cilium을 넣으면 L3 방식의 장점이 커짐
현재 환경의 핵심 조건이 바로 이것입니다.
Kubernetes
│
Cilium
│
Native Routing
│
Cilium BGP
│
Leaf
│
BGP / ECMP
│
Spine이미 Pod network를 routed network로 운영하고 있습니다.
예를 들어:
Pod
10.20.1.15
│
Cilium
│
Node
├────100G──── Leaf-A
│
└────100G──── Leaf-B
│
ECMP가 가능하다면 L2 multihoming을 굳이 추가할 이유가 줄어듭니다.
단, GPU는 L3 방식에서 주의
이게 이번 설계에서 가장 중요한 예외입니다.
GPU에는 Ethernet 포트가 딱 2개밖에 없습니다.
GPU
Broadcom
├─ p0 100G
└─ p1 100GEVPN-MH라면 매우 간단합니다.
p0 ─ Leaf-A
\
bond1
/
p1 ─ Leaf-B
bond1 IP = X.X.X.XKubernetes 입장에서는 그냥 하나의 node interface입니다.
반면 routed dual-homing은:
p0 100G ─── Leaf-A
L3 subnet-A
p1 100G ─── Leaf-B
L3 subnet-B처럼 두 독립 L3 interface가 됩니다.
그러면 Kubernetes Node IP를 무엇으로 할지, Cilium의 node addressing/route advertisement를 어떻게 할지, host-originated traffic의 source address/path symmetry를 어떻게 처리할지까지 설계해야 합니다.
따라서 단순히:
"Cilium BGP를 쓰니까 bond1을 없애자."
라고 바로 결정하는 건 권하지 않습니다.
Public bond0는 오히려 EVPN-MH가 편함
Compute/AIStor의 Public network는 Kubernetes Pod routing과 성격이 다릅니다.
External Client
│
Router/FW
│
Public Fabric
/ \
Leaf-A Leaf-B
\ /
\ LACP/
bond0
│
Compute여기서는 굳이 서버까지 BGP를 내려서:
Server ↔ Leaf-A BGP
Server ↔ Leaf-B BGP를 할 필요가 없는 경우가 많습니다.
특히 Ingress/LB, 관리 endpoint, AIStor S3 VIP 등을 제공한다면 EVPN-MH + LACP가 운영상 단순합니다.
그래서 제가 이번 환경에서 권하는 Hybrid
전체를 한 가지 방식으로 통일하기보다 역할에 따라 나누는 방안을 검토하겠습니다.
Internet / Enterprise
│
FW/Router
│
┌──────── Public Fabric ────────┐
│ │
Public Leaf-A Public Leaf-B
│ │
└────── EVPN-MH / LACP ────────┘
│
bond0
Compute / AIStor
================================================================
Kubernetes Fabric
Spine-1 Spine-2
\ /
\ BGP/ECMP /
\ /
Private Leaf-A Private Leaf-B
│ │
100G 100G
│ │
└────┬──────┘
│
K8s Node
│
Cilium Native
│
BGP/ECMP
bond1 대신 L3 dual-homing그리고 별도로:
GPU / AIStor
│
CX-7 NDR400
│
Quantum-2 Leaf
│
Quantum-2 Spine
│
InfiniBand
→ Cilium/BGP와 별도입니다.
서버별로 최종 후보를 정리하면
| 서버 | Public | Private/K8s | NDR |
|---|---|---|---|
| GPU ×12 | 없음 | 2×100G EVPN-MH/LACP 또는 L3 dual-homing | 2×400G active |
| Compute ×60 | 2×100G EVPN-MH/LACP | 2×100G L3/BGP/ECMP | 없음 |
| AIStor ×55 | 2×100G EVPN-MH/LACP | 2×100G L3/BGP/ECMP | 2×400G |
| PowerScale | 별도 검토 | 외부 Storage | 없음 |
Compute와 AIStor는 저는 Hybrid 쪽으로 기울어집니다.
GPU는 조금 다릅니다. 기존 운영환경과 최대한 동일하게 가져가는 것이 우선이라면 GPU의 2×100G는 EVPN-MH/LACP bond1으로 두는 것이 훨씬 단순합니다. 실제 고성능 GPU traffic은 NDR400으로 빠지기 때문에 Ethernet bond1을 L3 dual-homing으로 바꿔 얻는 이점도 Compute보다 상대적으로 작습니다.
따라서 현실적인 1차 설계안은 오히려 다음과 같습니다.
GPU: Private
bond1 2×100G EVPN-MH/LACP
Compute: Publicbond0 EVPN-MH/LACP+ Private2×100G L3/BGP/ECMP
AIStor: Publicbond0 EVPN-MH/LACP+ Private2×100G L3/BGP/ECMP
NDR: 완전 별도 InfiniBand fabric
다만 Private L3 dual-homing을 실제로 채택하기 전에 현재 Cilium의 BGP peering이 "Node↔Leaf 직접 BGP"인지, 아니면 별도 router/ToR를 경유하는 구조인지를 확인해야 합니다. 이 한 가지에 따라 새 환경에서의 최적 구성이 상당히 달라집니다.
네. 현재가 Node ↔ Leaf 직접 BGP라면, 지금 이야기하는 세 방식의 차이를 이해하는 게 특히 중요합니다. 먼저 용어부터 바로잡으면 node-leak가 아니라 아마 Node–Leaf direct BGP peering을 말씀하신 것으로 보입니다.
핵심 차이는 이겁니다.
MLAG/EVPN-MH는 “두 물리 링크를 하나의 논리적 L2/LAG처럼 만드는 방법”이고, L3 Dual-Homing은 “두 링크를 처음부터 서로 독립적인 L3 경로로 사용하는 방법”입니다.
1. MLAG / MC-LAG
가장 익숙한 형태입니다. 서버는 Leaf-A와 Leaf-B라는 서로 다른 스위치에 연결되어 있지만, 두 Leaf가 서버에게는 하나의 LACP 상대방처럼 보이게 합니다.
Kubernetes Node
┌───────────────┐
│ bond1 │
│ 802.3ad │
└───┬───────┬───┘
100G│ │100G
│ │
Leaf-A === Leaf-B
↑
MLAG Peer
/ \
Spine-1 Spine-2서버에서는:
bond1
├─ NIC-A/p1
└─ NIC-B/p1
mode = 802.3ad정상 상태에서는 두 포트 모두 Active이고 200G aggregate입니다. 한 Leaf가 죽으면 나머지 100G로 계속 동작합니다.
여기서 MC-LAG, MLAG, MC-RAG/MRAG 등은 벤더에 따라 명칭과 구현이 조금씩 다릅니다. 기본 목표는 동일합니다.
두 개의 물리적인 스위치를 하나의 LAG termination처럼 동작시키는 것입니다.
문제는 Leaf-A/B 사이에 상태 동기화가 필요하다는 것입니다.
Leaf-A ======== Leaf-B
Peer-Link
MAC sync
LACP state
failure state
forwarding state그래서 두 Leaf가 어느 정도 하나의 논리적 시스템처럼 묶입니다.
2. EVPN-MH
EVPN Multihoming도 서버 입장에서는 놀랍게도 비슷하게 보일 수 있습니다.
Node
┌──────────┐
│ bond1 │
│ LACP │
└─┬──────┬─┘
100G│ │100G
│ │
Leaf-A Leaf-B
\ /
\ /
EVPN-MH
│
BGP EVPN
│
Spines서버에서는 여전히:
bond1 = 2×100G
LACP일 수 있습니다.
차이는 Leaf 쪽입니다.
MLAG은 Leaf-A/B가 proprietary 또는 vendor-specific peer 관계를 강하게 맺는 경우가 많지만, EVPN-MH는 BGP EVPN control plane을 이용하여 multihoming 정보를 fabric에 전달합니다.
여기서 중요한 개념이 ESI입니다.
Node
/ \
Leaf-A Leaf-B
\ /
\ /
Ethernet Segment
ESILeaf-A와 Leaf-B가 이 서버 연결을 동일 Ethernet Segment로 인식합니다.
EVPN control plane이:
"This Ethernet Segment는
Leaf-A와 Leaf-B를 통해 도달 가능하다."라는 정보를 fabric에 알립니다.
그래서 대규모 BGP EVPN/VXLAN fabric에서는 MLAG보다 EVPN-MH가 architecture상 더 자연스러운 경우가 많습니다.
3. L3 Dual-Homing
이건 앞의 두 개와 철학이 완전히 다릅니다.
bond/LACP를 만들지 않습니다.
Node
┌─────────┐
│ │
NIC-A NIC-B
100G 100G
│ │
│ L3 L3 │
│ │
Leaf-A Leaf-B
│ │
└────┬────┘
│
BGP/ECMP
│
Spine예를 들어 주소를 단순화해서 표현하면:
Node NIC-A
10.1.1.2/31
│
│ BGP
│
10.1.1.3/31
Leaf-A
Node NIC-B
10.1.2.2/31
│
│ BGP
│
10.1.2.3/31
Leaf-BNode가 두 Leaf와 각각 BGP peer를 맺습니다.
그리고 Node의 loopback 또는 PodCIDR을 양쪽으로 광고합니다.
PodCIDR
10.100.1.0/24
│
Node
/ \
BGP BGP
/ \
Leaf-A Leaf-B
\ /
\ ECMP /
\ /
SpineFabric에서는:
10.100.1.0/24
next-hop → Node via Leaf-A
next-hop → Node via Leaf-B라는 두 경로를 가질 수 있습니다.
이게 L3 ECMP입니다.
지금 사용 중인 Cilium Native + Node–Leaf BGP와 연결하면
사용자께서 말씀하신 현재 환경이 정말:
Cilium Node
│
├── BGP → Leaf-A
│
└── BGP → Leaf-B구조라면 이미 상당 부분 L3 Dual-Homing 철학에 가깝습니다.
예를 들어 Node-01이:
PodCIDR
10.10.1.0/24를 가지고 있다면 Cilium BGP Control Plane이 Leaf에 이를 광고할 수 있습니다.
Spine
/ \
Leaf-A Leaf-B
\ /
\ /
Node-01
│
Cilium
│
10.10.1.0/24외부에서 Pod로 들어오는 traffic은 ECMP를 이용해:
Traffic
│
Spine
/ \
50% 50%
/ \
Leaf-A Leaf-B
\ /
\ /
Node-01처럼 분산될 수 있습니다.
물론 실제 분산은 flow hashing 결과라 정확히 50:50을 보장하는 것은 아닙니다.
그러면 MLAG와 L3 Dual-Homing의 결정적인 차이는?
예를 들어 서버에 100G 두 개가 있다고 합시다.
MLAG / EVPN-MH
서버가 보는 것은 하나의 interface입니다.
NIC1 ─┐
├── bond1 ── 10.1.1.10
NIC2 ─┘
200G aggregate네트워크가 아래쪽 복잡성을 숨깁니다.
반면 L3 Dual-Homing은 서버가:
NIC1 ── L3 Path-A
NIC2 ── L3 Path-B라는 두 개의 독립적인 path를 인식합니다.
이게 Kubernetes/Cilium 환경에서는 상당히 중요한 차이입니다.
장애가 나면 어떻게 다른가
Leaf-A가 장애났다고 해보겠습니다.
MLAG/EVPN-MH:
정상
Node
├─100G─ Leaf-A
└─100G─ Leaf-B
↓
Leaf-A 장애
Node
├── X
└─100G─ Leaf-B
LACP member 제거
200G → 100GL3 Dual-Homing:
정상
Node
├─ BGP ─ Leaf-A
└─ BGP ─ Leaf-B
↓
Leaf-A 장애
Node
├── X
└─ BGP ─ Leaf-B
BGP/BFD convergence
ECMP path 제거역시 물리적으로는 200G → 100G가 됩니다.
하지만 장애 처리 주체가 다릅니다.
MLAG/EVPN-MH → L2/LACP multihoming
L3 Dual-Homing → Routing/BGP/ECMP
입니다.
NIC 하나가 죽어도 마찬가지
Node
/ \
NIC-A NIC-B
100G 100G
│ │
Leaf-A Leaf-BNIC-A 장애:
MLAG
LACP:
member A DOWN
member B ACTIVEL3 Dual-Homing
BGP:
Path A withdrawn
Path B remains둘 다 서비스는 유지됩니다.
Leaf–Spine uplink 장애에서는 L3의 장점이 더 명확
예를 들어:
Spine-1 Spine-2
\ /
\ /
Leaf-A
│
NodeLeaf-A→Spine-1 link가 죽더라도 BGP/ECMP fabric이라면:
Leaf-A → Spine-2경로가 남습니다.
즉 redundancy가 계층 전체에 동일한 routing 원리로 적용됩니다.
Node
│
BGP
│
Leaf
│
BGP/ECMP
│
Spine이것이 Clos IP fabric이 강력한 이유 중 하나입니다.
세 가지를 한 번에 비교하면
| 항목 | MLAG/MC-LAG | EVPN-MH | L3 Dual-Homing |
|---|---|---|---|
| 서버 연결 | L2 | L2 | L3 |
| 서버 LACP | 필요 | 보통 사용 | 불필요 |
| 서버 bond | 사용 | 사용 가능 | 일반적인 LACP bond 불필요 |
| 두 Leaf | 하나의 논리 LAG peer처럼 | EVPN Ethernet Segment | 완전 독립 |
| Control Plane | MLAG vendor mechanism | BGP EVPN | BGP |
| Path 분산 | LAG hash | LAG + EVPN | ECMP |
| Leaf간 peer 의존 | 높음 | 낮출 수 있음 | 없음 |
| Leaf 장애 | LACP/MH 처리 | EVPN/LACP 처리 | BGP/BFD |
| L2 확장 | 가능 | 강점 | 최소화 |
| Cilium Native Routing | 가능 | 가능 | 매우 잘 맞음 |
| Node–Leaf BGP | 별도 구성 | 별도 구성 | 설계의 핵심 |
| 운영 철학 | L2 redundancy | EVPN fabric | IP routed fabric |
여기서 아주 중요한 부분: Cilium BGP와 Node BGP
현재 환경을 확인할 때 이 부분을 꼭 구분해야 합니다.
"Cilium이 Leaf와 BGP peer한다"면 실제로는 Cilium BGP Control Plane이 PodCIDR/Service prefix 등을 광고하는 역할일 가능성이 높습니다.
그렇다고 해서 자동으로:
"서버의 두 물리 NIC 자체도 완전한 L3 ECMP dual-homing이다."
라는 의미는 아닙니다.
예를 들어 현재 구조가 이렇게 되어 있을 수도 있습니다.
Node
┌───────────────┐
│ Cilium │
│ │ │
│ BGP │
│ │ │
│ bond1 │
└──────┬────────┘
│
LACP 2×25G
/ \
Leaf-A Leaf-B이것도 Cilium Node→Leaf BGP입니다.
하지만 아래 물리 network는 여전히 MLAG/LACP입니다.
반대로 진짜 L3 dual-homing은:
Node
┌───────────────┐
│ Cilium │
│ │
│ Path-A Path-B │
└───┬─────┬─────┘
│ │
BGP BGP
│ │
Leaf-A Leaf-B입니다.
이 둘은 전혀 다릅니다.
따라서 기존 환경에서 확인할 것은 4개면 됩니다
기존 Kubernetes node 한 대에서 다음을 확인하면 거의 판별됩니다.
ip -br link
ip -br addr
cat /proc/net/bonding/bond1
ip route그리고 Cilium 쪽 BGP 상태도 확인합니다. 사용 중인 Cilium 버전에 맞는 CLI/API로 BGP peers와 advertised routes를 보면 됩니다.
결과가:
bond1
slave: eno1
slave: eno2
mode: 802.3ad라면 물리적으로는 LACP multihoming입니다.
그 위에서 Cilium BGP를 돌리고 있을 수 있습니다.
반대로:
eno1 → Leaf-A L3
eno2 → Leaf-B L3
bond1 없음이고 두 Leaf와 독립적인 routing adjacency/path를 형성하고 있다면 L3 dual-homing에 가깝습니다.
이번 신규 환경에서는 이 확인 결과가 상당히 중요합니다
만약 기존 환경이 실제로:
2×25G
↓
bond1 / LACP
↓
MLAG Leaf pair
↓
Cilium BGP
↓
PodCIDR였다면 신규 환경에서 가장 보수적인 업그레이드는:
2×100G
↓
bond1 / LACP
↓
EVPN-MH
↓
Cilium BGP
↓
PodCIDR입니다.
반면 기존 환경이 진짜:
NIC-A ─ BGP ─ Leaf-A
NIC-B ─ BGP ─ Leaf-B
↓
ECMP였다면 신규도 L3 Dual-Homing을 그대로 계승하는 것이 훨씬 자연스럽습니다.
따라서 다음 판단을 하기 전에 기존 노드 한 대에서 ip -br link, ip -br addr, /proc/net/bonding/bond1, ip route와 Cilium BGP peer/route 상태만 확보하면, 제가 그 결과를 보고 현재 환경이 MLAG+LACP 위의 Cilium BGP인지 진짜 L3 Dual-Homing+BGP/ECMP인지 정확히 구조도로 역설계해드릴 수 있습니다.
네. 지금 말씀하신 정보로 L3 Dual-Homing은 제외할 수 있습니다.
현재 구조는 대략:
K8s Node
├─ NIC-1 ──┐
└─ NIC-2 ──┤ bond1
│ 802.3ad / LACP
│
Leaf-A / Leaf-B
│
Cilium BGP이고, 이제 확인할 핵심은 Leaf-A/B가 이 LACP를 어떤 방식으로 제공하느냐, 즉 전통적인 MLAG/MC-LAG(MC-RAG 포함)인지 EVPN-MH인지입니다.
가장 확실하게 구분하려면 스위치 쪽 정보가 필요합니다. 서버의 bond1 정보만으로는 둘을 구분하기 어렵습니다. 서버에서는 둘 다 그냥 하나의 LACP partner처럼 보일 수 있기 때문입니다.
확인 우선순위는 다음 정도면 충분합니다.
-
Leaf 스위치 제조사와 정확한 모델명
- Juniper, Arista, Cisco, NVIDIA/Spectrum 등
- 모델까지 있으면 해당 벤더에서 MLAG/MC-LAG/EVPN-MH 중 무엇을 사용하는지 범위를 상당히 좁힐 수 있습니다.
-
Leaf-A/B 사이 연결 및 설정
peer-link,ICCP,ICL,MLAG,MC-LAG,MC-AE,MC-RAG같은 설정이 있으면 전통적인 MLAG 계열일 가능성이 큽니다.- 반대로
EVPN,ESI,Ethernet Segment,DF election,ES route,ES-import RT등이 나오면 EVPN-MH입니다.
-
서버 연결 포트의 switch config
예를 들어 이런 정도만 있어도 됩니다.
Leaf-A
interface xxx
...
lacp ...
ae/port-channel ...그리고 동일 서버가 연결된 Leaf-B쪽 interface 설정도 있으면 좋습니다.
- BGP 설정
특히 address-family를 봐야 합니다.
예를 들어:
router bgp ...
address-family ipv4 unicast만 있다면 이것만으로 EVPN-MH라고 할 수 없습니다.
반면:
router bgp ...
address-family l2vpn evpn과 함께 ESI/Ethernet Segment 설정이 존재한다면 EVPN-MH일 가능성이 매우 높습니다.
여기서 현재 사용 중인 Cilium BGP와 EVPN BGP를 혼동하면 안 됩니다.
Cilium BGP
Node ───────────────→ Leaf
IPv4 Unicast
PodCIDR 등
EVPN
Leaf ───────────────→ Spine/RR
L2VPN EVPN
MAC/IP, ESI 등둘 다 BGP이지만 목적이 완전히 다릅니다.
아주 빠르게 판별하는 방법
네트워크 담당자에게 다음처럼 물어보면 됩니다.
"현재 서버가 Leaf-A/Leaf-B에 LACP dual-homing되어 있는데, Leaf pair의 multi-chassis LAG가 MLAG/MC-LAG(MC-RAG) 방식인가요, 아니면 BGP EVPN Ethernet Segment/ESI 기반 EVPN Multihoming인가요?"
그리고 한 가지를 더 물어보세요.
"Leaf 간 peer-link/ICL이 필요한 구조인가요, 아니면 EVPN Type-1/ESI 기반으로 multihoming을 처리하나요?"
답이:
Leaf-A ===== Leaf-B
Peer-link
MLAG/ICCP라면 MLAG/MC-LAG 계열,
Spine/RR
/ \
BGP EVPN BGP EVPN
/ \
Leaf-A Leaf-B
\ /
\--- ESI ----/
Node라면 EVPN-MH로 보면 됩니다.
기존 서버에서 지금 바로 확인 가능한 정보도 있음
서버에서 아래 결과를 주시면 제가 먼저 분석해볼 수 있습니다.
cat /proc/net/bonding/bond1특히 다음 항목이 중요합니다.
Bonding Mode
LACP rate
Transmit Hash Policy
802.3ad info
LACP active
Aggregator ID
Partner Mac Address
Partner Key
Slave Interface
Actor Churn State
Partner Churn State
Actor/Partner details다만 이것으로 LACP가 정상적으로 하나의 multi-chassis system에 붙어 있다는 것은 확인할 수 있어도, 그것이 MLAG인지 EVPN-MH인지 최종 판별하는 데는 Leaf 설정이 가장 확실합니다.
따라서 가능하면 ① Leaf 제조사/모델, ② Leaf-A/B 서버 연결 포트 config, ③ BGP config 중 l2vpn evpn 부분, ④ Leaf 간 peer-link 관련 config 중 하나만 가져오셔도 됩니다. 특히 스위치 설정 일부나 show 명령 출력 스크린샷이 있으면 제가 MLAG/MC-LAG/EVPN-MH 중 무엇인지 바로 판별해 보겠습니다.
네, 큰 방향에서는 맞습니다. 다만 정확히는 두 가지를 분리해서 봐야 합니다.
① 두 Leaf가 하나의 LAG를 지원하느냐 → 두 100G 링크를 Active-Active로 묶을 수 있는지 결정하고,
② Active-Active라고 해서 단일 세션이 200G가 되는 것은 아닙니다.
예를 들어 Compute node의 bond1을 보면:
Compute Node
┌──────────────┐
E810-A/p1 100G│ │100G E810-B/p1
─────────┤ bond1 ├─────────
└──────────────┘
│ │
▼ ▼
Private Leaf-A Private Leaf-B
│ │
└──── MLAG / MC-LAG ──────┘
│
Private FabricMLAG/MC-LAG가 지원되는 경우
Leaf-A와 Leaf-B는 물리적으로는 별도 스위치지만 서버 입장에서는 하나의 LACP LAG peer처럼 보이게 할 수 있습니다.
서버에서는 예를 들어:
bond1
mode = 802.3ad
slave1 = E810-A/p1 → Leaf-A
slave2 = E810-B/p1 → Leaf-B가 되고 두 링크가 모두 forwarding 상태가 됩니다.
따라서:
100G + 100G → 최대 aggregate 200Gbps
입니다.
하지만 중요한 차이가 있습니다.
TCP Flow #1 ────────────────→ 100G Link A
TCP Flow #2 ────────────────→ 100G Link B
TCP Flow #3 ────────────────→ 100G Link A
TCP Flow #4 ────────────────→ 100G Link B
Aggregate ≈ 200GLACP가 source/destination IP, TCP/UDP port 등의 hash를 이용해 flow를 각 member에 배분하기 때문입니다.
반면:
하나의 TCP connection
Server ==========================> AIStor
최대 ~100G처럼 하나의 flow를 두 물리 링크에 50G+50G로 쪼개서 200G로 보내는 구조는 일반적인 LACP가 아닙니다.
따라서 표현은:
2×100G LACP = 200G aggregate bandwidth / 일반적으로 100G per-flow ceiling
이라고 하는 게 정확합니다.
MLAG/MC-LAG가 없는 두 개의 독립 Leaf라면
이 경우가 중요합니다.
Server
bond1
/ \
100G 100G
│ │
▼ ▼
Leaf-A Leaf-B
X───────────X
독립 LACP systemLeaf-A와 Leaf-B가 서로 독립적인 LACP system이면 일반적으로 서버의 하나의 802.3ad bond를 두 스위치에 걸쳐 구성하면 안 됩니다.
이 경우 가장 단순한 선택은:
bond1 mode = active-backup
Server
/ \
ACTIVE STANDBY
100G 100G
│ │
▼ ▼
Leaf-A Leaf-B입니다.
정상 상태:
사용 가능 bandwidth = 100G
Leaf-A/NIC-A/link 장애:
Before
NIC-A ─100G─ Leaf-A ACTIVE
NIC-B ─100G─ Leaf-B STANDBY
After Leaf-A failure
NIC-A ─ X
NIC-B ─100G─ Leaf-B ACTIVE즉 200G 성능이 목적이라기보다는 100G + redundancy입니다.
그래서 업체에 확인해야 할 질문
100G Ethernet switch 설계 업체에 이렇게 물어보시면 됩니다.
Public/Private Leaf pair가 각각 MLAG/MC-LAG 또는 EVPN Multihoming을 지원하여, 서버에서 서로 다른 두 Leaf로 연결된 2×100GbE를 하나의 802.3ad LACP bond로 Active-Active 구성할 수 있는 구조인지 확인 부탁드립니다. 가능하다면 서버당 aggregate 200Gbps 사용을 위한 LAG 구성과 hashing policy도 같이 확인 부탁드립니다.
그리고 추가로 Peer-Link / ICCP / EVPN Ethernet Segment가 어떤 방식인지, Leaf 장애 시 convergence가 얼마나 걸리는지도 받는 게 좋습니다.
EVPN Multihoming은 약간 다른 개념입니다
MLAG/MC-LAG와 EVPN Multihoming은 목표는 비슷하지만 구현 방식은 다릅니다.
전통적인 MLAG은 대략:
Server
LACP
/ \
Leaf-A====Leaf-B
↑
MLAG peer처럼 Leaf-A/B 사이에 MLAG peer 관계를 구성합니다.
EVPN Multihoming은 보통 VXLAN/EVPN fabric에서:
EVPN Fabric
Spine / Route Reflector
/ \
Leaf-A Leaf-B
\ /
\ LACP /
Server처럼 Ethernet Segment/ESI와 EVPN control plane을 사용해 multi-homing을 처리합니다.
신규 Leaf-Spine fabric을 EVPN/VXLAN으로 구축한다면 EVPN Multihoming을 선택할 수도 있고, 장비/설계에 따라 MLAG를 사용할 수도 있습니다.
현재 우리 서버 구성에 적용하면
| 서버 | 100G NIC | MLAG + LACP일 때 | Active-Backup일 때 |
|---|---|---|---|
| GPU | Broadcom dual ×1 = 2 ports | bond1 200G aggregate | bond1 100G active |
| Compute | E810 dual ×2 = 4 ports | bond0 200G + bond1 200G | 각각 100G active |
| AIStor | Broadcom dual ×2 = 4 ports | bond0 200G + bond1 200G | 각각 100G active |
그래서 지금 설계에서 100G Ethernet switch 기종과 Leaf pair 구성 방식은 꽤 중요한 확인사항입니다.
특히 GPU는 Ethernet 포트가 2개뿐이라 두 포트를 모두 bond1에 넣기로 했으므로 차이가 큽니다.
MLAG/LACP
GPU bond1
100G Active + 100G Active
↓
최대 200G aggregate
Active-Backup
GPU bond1
100G Active + 100G Standby
↓
최대 100G다만 GPU의 실제 학습 데이터/NCCL 고속 경로는 NDR400 InfiniBand 2×400G로 별도 설계했기 때문에, GPU 노드에서 Ethernet bond1이 100G냐 200G냐가 NCCL/RDMA 성능을 직접 결정하는 것은 아닙니다. bond1은 Kubernetes/Cilium/일반 IP traffic 쪽 영향이 더 큽니다.
그리고 한 단계 더 중요한 확인사항이 있습니다. MLAG 지원 여부만 확인하면 끝나는 게 아니라, Leaf→Spine uplink capacity도 확인해야 합니다. 서버 55대가 모두 2×100G Active-Active라고 해도 Leaf uplink가 부족하면 서버 NIC에서는 200G가 떠도 fabric 전체에서는 oversubscription이 발생합니다.
따라서 다음으로 100G Ethernet 스위치 모델/수량/포트 정보를 주시면, 제가 GPU 12 + Compute 60 + AIStor 55 기준으로 필요 100G 포트 수 → Leaf 수량 → Leaf-Spine uplink → oversubscription ratio → 실제 bond0/bond1 예상 aggregate bandwidth까지 계산해볼 수 있습니다.
