close
프로필 배경
프로필 로고

IT 나누기

지식 공유/Server · 2026. 7. 23. fullscreen 넓게보기

중첩 본딩의 위험과 MLAG를 이용한 2:2 단일 본딩 40G 구성 방법

반응형

네트워크 일반형

중첩 본딩의 위험과 MLAG를 이용한 2:2 단일 본딩 40G 구성 방법

10GbE 포트 4개를 단순히 여러 단계로 본딩하는 방식은 장애 감지, 해시 분산, MAC 주소 학습 및 복구 절차를 복잡하게 만든다. 이 글에서는 중첩 본딩을 피해야 하는 이유와 두 대의 스위치에 각각 2포트를 연결한 뒤 MLAG와 LACP를 이용해 하나의 40G 논리 본드로 구성하는 방법을 설명한다.

구성 목표

목표는 서버에 장착된 10GbE NIC 4개를 이용하여 최대 40Gbps의 집계 대역폭과 스위치 이중화를 동시에 확보하는 것이다. 물리 연결은 스위치 A에 2포트, 스위치 B에 2포트를 연결하는 2:2 구조로 설계한다.

```
2:2 단일 본딩 구성 요소
구성 요소 수량 역할
서버 10GbE 포트 4개 하나의 802.3ad 본드에 참여
MLAG 스위치 2대 서버에 하나의 논리 LACP 파트너처럼 동작
스위치별 서버 연결 2개 각 스위치가 20Gbps의 물리 용량 제공
MLAG Peer Link 권장 2포트 이상 상태 동기화 및 필요한 경우 데이터 전달
서버 논리 인터페이스 1개 bond0 또는 팀 인터페이스

MLAG는 서버의 LAG 또는 본드에 속한 포트를 서로 다른 물리 스위치에 연결하면서도 서버가 이를 하나의 논리 스위치에 연결된 링크로 인식하게 한다. 이를 통해 링크 장애뿐 아니라 스위치 한 대의 장애에도 대응할 수 있다.

중첩 본딩이란 무엇인가

중첩 본딩은 이미 집계된 논리 인터페이스를 다시 다른 본딩이나 집계 그룹의 멤버로 넣는 구조를 의미한다. 예를 들어 물리 NIC 두 개로 만든 bond0와 다른 물리 NIC 두 개로 만든 bond1을 다시 상위 bond2에 넣는 방식이다. 

eth0 ─┐
  ├─ bond0 ─┐
```

eth1 ─┘         │
├─ bond2
eth2 ─┐         │
├─ bond1 ─┘
eth3 ─┘
```

스위치에서도 두 개의 하위 LAG를 다시 상위 LAG처럼 취급하거나, 서버에서는 본딩하고 가상화 계층에서 다시 팀 구성을 추가하는 사례가 있다. 그러나 IEEE 802.3ad LACP는 일반적으로 하나의 논리 집계 인터페이스와 하나의 논리 파트너 사이의 멤버 링크를 관리하는 구조다. 여러 단계의 독립적인 해시와 장애 상태를 겹치면 각 계층이 전체 물리 상태를 정확히 이해하기 어려워진다.

중첩 본딩의 주요 위험

독립적인 해시 계산으로 인한 불균형

하위 본드와 상위 본드가 각각 별도의 해시를 수행하면 특정 하위 그룹에 트래픽이 몰릴 수 있다. 상위 계층에서는 두 개의 논리 인터페이스가 동일한 용량으로 보이더라도, 하위 계층의 실제 멤버 상태나 흐름 분포는 다를 수 있다.

예를 들어 상위 본드가 특정 흐름을 bond0에 배치하고, bond0의 해시도 같은 물리 NIC에 여러 흐름을 배치하면 일부 10GbE 링크만 포화되고 나머지 링크는 거의 사용되지 않을 수 있다.

장애 감지 지연과 부분 장애 은폐

하위 본드의 멤버 한 개가 장애를 일으켜도 상위 본드에서는 하위 본드 인터페이스 자체가 여전히 정상 상태로 보일 수 있다. 이 경우 상위 계층은 실제 용량 감소를 인식하지 못하고 계속 동일한 비율로 트래픽을 전달한다.

LACP 상태 불일치

LACP는 Actor와 Partner의 시스템 ID, 포트 키, 집계 상태를 기준으로 멤버를 하나의 Aggregator에 포함한다. 중간에 또 다른 논리 집계 계층이 존재하면 실제 물리 포트의 LACP 상태와 상위 인터페이스 상태가 분리될 수 있다.

패킷 순서 변경 가능성

여러 계층에서 서로 다른 해시 정책을 적용하거나 장애 시 재분배가 연속적으로 발생하면 동일 세션의 패킷 경로가 예상보다 자주 변경될 수 있다. TCP는 일부 순서 변경을 복구할 수 있지만, 대량의 재정렬은 재전송과 처리량 저하로 이어질 수 있다.

장애 원인 추적의 복잡성

물리 NIC, 하위 본드, 상위 본드, 브리지, 가상 스위치, MLAG 포트채널을 각각 확인해야 하므로 운영 복잡도가 크게 증가한다. 인터페이스 카운터만으로는 어느 계층에서 드롭이나 불균형이 발생했는지 판단하기 어렵다.

벤더 지원 범위 이탈

운영체제나 NIC 드라이버가 논리 본드를 다른 본드의 멤버로 사용하는 구성을 허용하더라도, 해당 구성이 공식적으로 지원되거나 검증되었다는 의미는 아니다. 특히 LACP, SR-IOV, OVS, 하이퍼바이저 가상 스위치가 함께 사용되면 지원 범위를 반드시 확인해야 한다.

```

MLAG가 필요한 이유

일반적인 LACP 포트채널은 하나의 논리 장비를 기준으로 구성한다. 서로 독립된 두 스위치에 서버의 본드 멤버를 나누어 연결하면 서버는 서로 다른 LACP System ID를 가진 두 파트너를 발견할 수 있다. 이 상태에서는 4개 포트가 하나의 정상적인 Aggregator에 들어가지 않거나, 일부 포트만 활성화될 수 있다.

MLAG는 두 물리 스위치가 서버 방향에서 공통된 논리 시스템처럼 동작하도록 제어 상태를 동기화한다. 서버는 4개의 링크를 하나의 LACP 파트너와 협상하는 것으로 인식하고, 두 스위치의 포트를 하나의 논리 LAG에 포함할 수 있다. MLAG의 핵심 목적은 서로 다른 스위치에 연결된 링크를 하나의 LAG로 운용하여 스위치 수준의 이중화와 active-active 전달을 제공하는 것이다.

MLAG 없이 두 스위치에 연결

  • LACP 파트너 시스템 ID가 달라질 수 있음
  • 4개 링크가 하나의 Aggregator로 결합되지 않을 수 있음
  • active-backup 설계가 필요할 수 있음
  • 전체 링크를 동시에 사용하기 어려움

MLAG를 이용해 연결

  • 두 스위치가 하나의 논리 LACP 파트너처럼 동작
  • 4개 링크를 하나의 본드에 포함
  • active-active 트래픽 전달 가능
  • 링크와 스위치 장애 모두 대응 가능

2:2 단일 본딩 40G 토폴로지

                         ┌─────────────────────────────┐
                     │          Linux Server       │
                     │                             │
                     │  eth0  eth1  eth2  eth3     │
                     │    \    |      |    /       │
                     │     \   |      |   /        │
                     │      bond0: 802.3ad          │
                     │      Aggregate: 40Gbps      │
                     └──────┬──┬──────┬──┬─────────┘
                            │  │      │  │
                       10G  │  │10G   │  │ 10G
                            │  │      │  │
                  ┌─────────┘  │      │  └─────────┐
                  │            │      │            │
            ┌─────▼────────────▼─┐  ┌─▼────────────▼─────┐
            │     Switch A       │  │      Switch B      │
            │                    │  │                    │
            │ Ethernet 1, 2      │  │ Ethernet 1, 2     │
            │ Port-Channel 10    │  │ Port-Channel 10   │
            │ MLAG ID 10         │  │ MLAG ID 10        │
            └─────────┬──────────┘  └──────────┬─────────┘
                      │                        │
                      ├────── MLAG Peer Link ──┤
                      │                        │
                      └──── Peer Keepalive ────┘

서버에서는 네 포트를 각각 별도의 본드로 나누지 않고 모두 하나의 bond0에 직접 포함한다. 스위치 A와 B에서는 서버 연결 포트를 동일한 MLAG ID를 가진 포트채널로 구성한다.

서버와 스위치의 논리 구성 관계
서버 포트 연결 스위치 스위치 포트채널 MLAG ID
eth0 Switch A Port-Channel 10 10
eth1 Switch A Port-Channel 10 10
eth2 Switch B Port-Channel 10 10
eth3 Switch B Port-Channel 10 10

트래픽 분산 방식과 성능 한계

40G는 집계 대역폭이다

4개의 10GbE 링크를 LACP로 묶었다고 해서 하나의 TCP 연결이 40Gbps로 전송되는 것은 아니다. LACP 본딩은 일반적으로 패킷 또는 프레임의 헤더 정보를 해시하여 하나의 흐름을 특정 멤버 링크에 배치한다. 따라서 하나의 세션은 보통 하나의 10GbE 링크 용량에 제한된다.

Linux 본딩 드라이버는 여러 물리 인터페이스를 하나의 논리 본드로 구성하며, 802.3ad 모드에서는 전송 해시 정책을 사용해 트래픽을 멤버 포트에 배분한다.

예상 가능한 처리량 예시
트래픽 조건 예상 최대치 설명
단일 TCP 흐름 약 10Gbps 이하 하나의 흐름이 일반적으로 하나의 멤버 링크를 사용
서로 다른 2개 흐름 최대 약 20Gbps 해시 결과가 서로 다른 멤버로 분산될 때
충분히 다양한 다중 흐름 최대 약 40Gbps 4개 링크에 비교적 균등하게 분산될 때
스위치 한 대 장애 최대 약 20Gbps 남은 스위치의 2개 링크만 사용
링크 한 개 장애 최대 약 30Gbps 나머지 3개 링크로 재분배

해시 정책 선택

Linux에서 자주 사용하는 정책은 layer2, layer2+3, layer3+4다. 다수의 서버와 다수의 TCP 또는 UDP 세션을 분산하려는 환경에서는 layer3+4가 유리할 수 있지만, 네트워크 구성, 프래그먼테이션, 스위치 해시 정책 및 운영체제 지원 범위를 함께 검토해야 한다.

  • layer2: MAC 주소를 중심으로 해시한다.
  • layer2+3: MAC 주소와 IP 주소를 조합한다.
  • layer3+4: IP 주소와 TCP 또는 UDP 포트를 조합한다.

구성 절차

  1. 스위치 두 대의 MLAG 호환성 확인

    동일 모델, 동일 또는 호환되는 운영체제 버전, MLAG 기능 및 라이선스 요구사항을 확인한다.

  2. MLAG Peer Link 구성

    두 스위치 사이에 충분한 용량과 이중성을 가진 Peer Link를 구성한다.

  3. Peer Keepalive 또는 Backup 경로 구성

    가능하면 Peer Link와 물리적으로 분리된 관리망 또는 별도 L3 경로를 사용한다.

  4. 서버 연결 포트채널 생성

    각 스위치의 서버 연결 2포트를 하나의 로컬 포트채널에 포함한다.

  5. 동일한 MLAG ID 적용

    스위치 A와 B의 서버용 포트채널에 동일한 MLAG ID를 지정한다.

  6. VLAN과 MTU 정렬

    서버 포트채널, Peer Link, 상위 네트워크의 VLAN 허용 목록과 MTU를 일치시킨다.

  7. 서버에서 4포트 단일 LACP 본드 생성

    네 개의 물리 NIC를 하나의 bond0에 직접 포함한다.

  8. LACP와 MLAG 상태 검증

    모든 멤버가 Collecting 및 Distributing 상태인지 확인한다.

  9. 다중 흐름 성능 시험

    여러 병렬 세션을 생성하고 각 물리 포트 카운터가 증가하는지 확인한다.

  10. 장애 시험

    링크, 스위치, Peer Link를 순차적으로 차단하여 서비스 영향과 복구 시간을 측정한다.

Linux 서버 4포트 LACP 본딩 예시

다음 예시는 Ubuntu 계열 Netplan 구성이다. 실제 NIC 이름, IP 주소, VLAN, MTU 및 라우팅 값은 운영 환경에 맞게 변경해야 한다.

Netplan 구성

network:
```

version: 2
renderer: networkd

ethernets:
enp65s0f0:
mtu: 9000
enp65s0f1:
mtu: 9000
enp129s0f0:
mtu: 9000
enp129s0f1:
mtu: 9000

bonds:
bond0:
interfaces:
- enp65s0f0
- enp65s0f1
- enp129s0f0
- enp129s0f1
mtu: 9000
addresses:
- 192.0.2.10/24
routes:
- to: default
via: 192.0.2.1
nameservers:
addresses:
- 192.0.2.53
- 192.0.2.54
parameters:
mode: 802.3ad
lacp-rate: fast
mii-monitor-interval: 100
transmit-hash-policy: layer3+4
```

적용 전 주의사항

sudo netplan generate
```

sudo netplan try
sudo netplan apply
```

Linux 본딩 상태 확인

cat /proc/net/bonding/bond0
```

ip -br link
ip -br address
ip route
ethtool bond0
networkctl status bond0
```

정상 상태에서는 다음 항목을 확인해야 한다.

  • Bonding Mode: IEEE 802.3ad Dynamic link aggregation
  • 4개의 Slave Interface가 모두 표시되는지 확인
  • 각 멤버의 MII Status가 up인지 확인
  • 각 멤버의 Aggregator ID가 동일한지 확인
  • Actor와 Partner의 LACP 정보가 정상인지 확인
  • 링크 속도가 각각 10000Mbps로 인식되는지 확인

NetworkManager nmcli 예시

sudo nmcli connection add \
```

type bond 
ifname bond0 
con-name bond0 
bond.options "mode=802.3ad,lacp_rate=fast,miimon=100,xmit_hash_policy=layer3+4"

sudo nmcli connection add type ethernet ifname enp65s0f0 
con-name bond0-enp65s0f0 master bond0

sudo nmcli connection add type ethernet ifname enp65s0f1 
con-name bond0-enp65s0f1 master bond0

sudo nmcli connection add type ethernet ifname enp129s0f0 
con-name bond0-enp129s0f0 master bond0

sudo nmcli connection add type ethernet ifname enp129s0f1 
con-name bond0-enp129s0f1 master bond0

sudo nmcli connection modify bond0 
ipv4.method manual 
ipv4.addresses 192.0.2.10/24 
ipv4.gateway 192.0.2.1 
ipv4.dns "192.0.2.53 192.0.2.54" 
802-3-ethernet.mtu 9000

sudo nmcli connection up bond0
```

MLAG 스위치 구성 예시

Switch A 개념 구성

! 1. MLAG peer-link용 포트채널
```

interface Ethernet49
channel-group 1000 mode active

interface Ethernet50
channel-group 1000 mode active

interface Port-Channel1000
description MLAG_PEER_LINK
switchport mode trunk

! 2. MLAG peer 통신용 VLAN 및 SVI
vlan 4094
name MLAG_PEER

interface Vlan4094
ip address 169.254.100.1/30

! 3. MLAG 도메인
mlag configuration
domain-id DC-MLAG-01
local-interface Vlan4094
peer-address 169.254.100.2
peer-link Port-Channel1000
peer-address heartbeat 192.0.2.202

! 4. 서버 연결 포트
interface Ethernet1
description SERVER01_NIC1
channel-group 10 mode active

interface Ethernet2
description SERVER01_NIC2
channel-group 10 mode active

interface Port-Channel10
description SERVER01_BOND0
switchport mode trunk
switchport trunk allowed vlan 100,200
mlag 10
```

Switch B 개념 구성

interface Ethernet49
```

channel-group 1000 mode active

interface Ethernet50
channel-group 1000 mode active

interface Port-Channel1000
description MLAG_PEER_LINK
switchport mode trunk

vlan 4094
name MLAG_PEER

interface Vlan4094
ip address 169.254.100.2/30

mlag configuration
domain-id DC-MLAG-01
local-interface Vlan4094
peer-address 169.254.100.1
peer-link Port-Channel1000
peer-address heartbeat 192.0.2.201

interface Ethernet1
description SERVER01_NIC3
channel-group 10 mode active

interface Ethernet2
description SERVER01_NIC4
channel-group 10 mode active

interface Port-Channel10
description SERVER01_BOND0
switchport mode trunk
switchport trunk allowed vlan 100,200
mlag 10
```

MLAG Peer Link는 단순한 장애 감지 링크가 아니다. MLAG 제어 정보 교환뿐 아니라 토폴로지와 트래픽 방향에 따라 데이터 트래픽을 전달할 수 있으므로, 장애 상황과 비대칭 트래픽을 고려해 용량을 산정해야 한다.

설정 정합성 항목

두 MLAG 피어에서 반드시 확인할 항목
항목 요구사항 불일치 시 영향
MLAG Domain ID 동일 피어 관계 형성 실패
서버 Port-Channel의 MLAG ID 동일 하나의 논리 LAG로 동작하지 않음
VLAN 허용 목록 동일 특정 VLAN의 단방향 통신 또는 블랙홀
Native VLAN 동일 태깅 불일치 및 VLAN 누수
MTU 경로 전체에서 일치 대형 프레임 드롭
LACP 모드 일반적으로 active 권장 LACP 협상 지연 또는 미형성
STP 설정 벤더 권장값 적용 루프 또는 예상치 못한 포트 차단
MLAG System ID 논리적으로 일관 서버 측 Aggregator 분리

장애 시나리오별 동작

서버 링크 한 개 장애

장애 링크는 본드와 포트채널에서 제외되고 나머지 3개 링크가 계속 전달한다. 집계 물리 용량은 40Gbps에서 30Gbps로 감소한다. 기존 흐름 중 장애 링크에 배치된 흐름은 남은 링크로 재해시될 수 있다.

스위치 한 대 전체 장애

장애 스위치에 연결된 2개 링크가 동시에 내려가고, 서버는 나머지 스위치의 2개 링크로 통신을 유지한다. 정상적인 2:2 구성이라면 집계 물리 용량은 최대 20Gbps로 감소하지만 연결성은 유지되어야 한다.

MLAG Peer Link 장애

Peer Link만 장애이고 두 스위치가 모두 동작하는 상황은 가장 주의해야 한다. 두 장비가 서로의 상태를 동기화하지 못하면 Split Brain 또는 Dual-Primary 상황이 발생할 수 있다.

벤더 구현에 따라 Secondary 피어의 MLAG 멤버를 차단하거나, Keepalive 결과를 이용해 특정 포트를 비활성화한다. Peer Link와 Keepalive가 동시에 단절되는 경우를 반드시 시험해야 한다.

Peer Link와 Keepalive 동시 장애

두 스위치가 상대방을 장애로 판단하면서 자신이 Primary라고 동작할 수 있다. 이 상태에서는 MAC 주소 중복, 잘못된 전달, 루프, ARP 이상 또는 블랙홀 위험이 커진다. 따라서 Peer Link와 Keepalive는 가능한 한 서로 다른 물리 경로와 장애 영역에 배치한다.

서버 NIC 드라이버 또는 펌웨어 이상

물리 링크가 Up 상태더라도 실제 패킷 전달이 불가능한 단방향 장애가 발생할 수 있다. 단순한 링크 캐리어 기반 miimon만으로 감지되지 않는 장애가 있는지 검토하고, 스위치 카운터, NIC 오류 카운터 및 상위 헬스 체크를 함께 사용한다.

구성 검증 방법

1. 물리 링크 확인

for nic in enp65s0f0 enp65s0f1 enp129s0f0 enp129s0f1
```

do
echo "===== ${nic} ====="
ethtool "${nic}" | grep -E "Speed|Duplex|Link detected"
done
```

각 NIC가 다음 조건을 만족하는지 확인한다.

  • Speed: 10000Mb/s
  • Duplex: Full
  • Link detected: yes

2. LACP Aggregator 확인

cat /proc/net/bonding/bond0

네 개 멤버의 Aggregator ID가 다르다면 MLAG 또는 LACP 파라미터가 일치하지 않을 가능성이 있다. 파트너 MAC 주소나 Partner Key가 스위치별로 다르게 표시되는지도 확인한다.

3. 포트별 트래픽 확인

watch -n 1 '
```

ip -s link show enp65s0f0
ip -s link show enp65s0f1
ip -s link show enp129s0f0
ip -s link show enp129s0f1
'
```

여러 흐름을 발생시킨 상태에서 네 인터페이스의 TX 및 RX 카운터가 모두 증가하는지 확인한다. 정확히 동일한 비율일 필요는 없지만 한 포트만 지속적으로 포화된다면 해시 분포를 검토해야 한다.

4. 다중 스트림 성능 시험

수신 서버에서 다음 명령을 실행한다.

iperf3 -s

송신 서버에서는 여러 병렬 스트림으로 시험한다.

iperf3 -c 192.0.2.20 -P 16 -t 60
```

iperf3 -c 192.0.2.20 -P 32 -t 60
```

하나의 송신지와 하나의 수신지 조합만으로는 스위치 해시 결과가 제한될 수 있다. 가능하면 여러 클라이언트, 여러 서버, 서로 다른 포트 번호 및 양방향 트래픽을 사용한다.

5. 장애 시험 순서

  1. 서버 NIC 케이블 한 개 제거
  2. 동일 스위치에 연결된 두 링크 중 한 개 차단
  3. 스위치 A에 연결된 서버 링크 두 개 차단
  4. 스위치 A 전원 또는 관련 프로세스 장애 시험
  5. MLAG Peer Link의 한 멤버 차단
  6. MLAG Peer Link 전체 차단
  7. Keepalive 경로 차단
  8. Peer Link와 Keepalive 동시 단절 시험
  9. 복구 후 멤버가 자동으로 정상 편입되는지 확인

6. 패킷 손실과 복구 시간 측정

ping -D -i 0.1 192.0.2.20
```

# 또는 fping 사용

fping -D -p 100 192.0.2.20
```

단순히 “통신이 다시 된다”는 것만 확인하지 말고 장애 발생 시 손실 패킷 수, 복구 시간, TCP 세션 유지 여부 및 애플리케이션 타임아웃을 기록해야 한다.

운영 체크리스트

  • 서버의 4개 NIC가 하나의 본드에 직접 포함되어 있다.
  • 본드 위에 또 다른 본드를 생성하지 않았다.
  • 본딩 모드는 802.3ad다.
  • 네 개의 링크가 동일한 Aggregator에 참여한다.
  • 스위치 두 대의 MLAG 상태가 정상이다.
  • 서버용 포트채널의 MLAG ID가 양쪽에서 동일하다.
  • VLAN, Native VLAN, MTU, LACP 설정이 양쪽에서 일치한다.
  • Peer Link가 단일 물리 링크에 의존하지 않는다.
  • Keepalive 경로가 Peer Link와 분리되어 있다.
  • Peer Link 용량이 장애 시 발생할 수 있는 트래픽을 감당한다.
  • 서버와 스위치의 해시 정책을 검토했다.
  • 단일 스트림과 집계 처리량을 구분해 성능 목표를 정의했다.
  • 링크 장애와 스위치 장애 시험을 완료했다.
  • Split Brain 방지 동작을 검증했다.
  • 운영 중 포트별 트래픽과 오류 카운터를 모니터링한다.

자주 묻는 질문

4개의 10G 포트를 본딩하면 단일 파일 전송도 40G가 되는가?

일반적으로 그렇지 않다. 하나의 TCP 또는 UDP 흐름은 해시 결과에 따라 하나의 물리 링크를 사용하므로 약 10Gbps 수준으로 제한될 수 있다. 여러 독립적인 흐름이 네 링크에 분산되어야 총 40Gbps에 가까운 집계 처리량을 기대할 수 있다.

MLAG 없이 두 스위치에 각각 두 포트를 연결할 수 있는가?

active-backup처럼 하나의 스위치만 활성화하는 방식은 가능할 수 있다. 그러나 두 스위치의 네 포트를 하나의 active-active LACP Aggregator로 사용하려면 두 스위치가 MLAG, MC-LAG, vPC, VLT 또는 이에 준하는 기능을 지원해야 한다.

스위치 한 대가 장애 나면 40G가 유지되는가?

아니다. 2:2 구조에서는 장애 스위치에 연결된 2개의 10G 링크가 제외되므로 남은 집계 물리 용량은 최대 20Gbps다. 이 구성의 목적은 장애 중에도 40G를 유지하는 것이 아니라 연결성을 유지하면서 성능을 단계적으로 축소하는 것이다.

Peer Link도 40G 이상이어야 하는가?

항상 모든 정상 트래픽이 Peer Link를 통과하는 것은 아니다. 그러나 비대칭 전달, Single-Attached 장비, 장애 상황 및 특정 제어 동작에서 데이터 트래픽이 Peer Link를 사용할 수 있다. 실제 예상 트래픽과 장애 모델을 기준으로 용량을 산정하고, 최소 두 개 이상의 물리 링크로 이중화하는 것이 바람직하다.

Jumbo Frame을 사용하면 모든 구간의 MTU가 같아야 하는가?

서버 NIC, 본드, VLAN 인터페이스, 서버 연결 포트채널, MLAG Peer Link 및 종단 간 경로가 대형 프레임을 전달할 수 있어야 한다. 중간 구간의 MTU가 작으면 대형 프레임이 드롭되거나 통신이 불안정해질 수 있다.

중첩 본딩이 반드시 동작하지 않는 구성인가?

일부 운영체제나 소프트웨어 조합에서는 설정 자체가 가능할 수 있다. 그러나 다단계 해시, 장애 상태 은폐, 지원 범위 및 운영 복잡성 때문에 동일 목적의 물리 NIC를 하나의 본드에 직접 포함하는 구조가 일반적으로 더 안전하다.

결론

두 대의 스위치와 네 개의 10GbE 서버 포트를 이용해 40G급 집계 네트워크를 구성할 때는 2포트 본드를 두 개 만든 뒤 다시 상위 본드로 묶는 중첩 구조보다, 네 물리 포트를 하나의 802.3ad 본드에 직접 포함하는 방식이 적합하다.

스위치 측에서는 각 장비에 서버 포트 2개를 배치하고 동일한 MLAG ID로 묶어야 한다. 이 구조는 정상 상태에서 네 링크를 active-active로 사용할 수 있고, 링크 한 개 장애 시 30G, 스위치 한 대 장애 시 20G 수준으로 용량을 축소하면서 연결을 유지할 수 있다.

다만 40G는 단일 흐름의 속도가 아니라 여러 흐름이 분산되었을 때의 집계 용량이다. 구축 후에는 LACP Aggregator 상태, 포트별 카운터, 다중 스트림 처리량, Peer Link 장애 및 Split Brain 방지 동작까지 검증해야 한다.

참고 자료

  • Linux Kernel Bonding Driver 문서
  • NVIDIA Cumulus Linux MLAG 문서
  • Arista EOS Multi-Chassis Link Aggregation 문서
  • Red Hat Enterprise Linux Network Bond 구성 문서
  • 콘텐츠 생성 구조 및 HTML 출력 원칙
```

 

2025.11.17 - [지식 공유/Server] - Bonding 설정 가이드 (active-backup · 802.3ad · Bond Mode 비교)

 

Bonding 설정 가이드 (active-backup · 802.3ad · Bond Mode 비교)

Linux Bonding 구성 가이드 (active-backup · 802.3ad · Bond Mode 비교)Bonding은 서버 네트워크 인터페이스를 묶어 고가용성(HA) 또는 부하 분산(LB)을 제공하는 핵심 기술입니다.본 문서에서는 nmcli 기반 설정

one-day-growth.com

2025.11.21 - [지식 공유/Server] - LACP Bonding(802.3ad)

 

LACP Bonding(802.3ad)

LACP 본딩(802.3ad) 1️⃣ LACP 본딩이 단일 NIC보다 무조건 빠른가? 결론부터 말하면 “무조건 빠르다”는 잘못된 표현이며, 정확한 표현은 환경에 따라 대역폭 확장 + 안정성이 크게 강화되는 구조라

one-day-growth.com

 

반응형
저작자표시 변경금지 (새창열림)

'지식 공유 > Server' 카테고리의 다른 글

SUSE OS에서 PostgreSQL 기반 DBMS 대용량 처리 문제 정리  (0) 2026.06.24
SUSE Enterprise 16 SSH 포트 변경과 PuTTY 인증 메시지 정리  (0) 2026.06.24
신규 개발 쿠버네티스 서버 구축과 기존 개발 클러스터 연동 방안  (0) 2026.06.22
WAS WildFly 설치 방법과 기본 설정 순서  (1) 2026.06.20
쿠버네티스 K8s 파드 확인 방법과 운영 시 주의사항  (0) 2026.06.20
지식 공유/Server 관련 글
더 보기

티스토리툴바