Linux LACP 본딩: 구성, 검증 및 문제 해결

Linux LACP 본딩은 여러 이더넷 인터페이스를 단일 논리 링크로 결합하여 더 많은 총 대역폭을 제공하고 물리적 NIC 간 자동 장애 조치 기능을 제공합니다. 이는 IEEE 802.3ad 표준을 사용하며, 양측(서버와 스위치)이 어떤 링크가 활성화될지 및 트래픽이 어떻게 분배될지 협상합니다. 이 글에서는 LACP가 실제로 어떤 역할을 하는지, 다른 Linux 본딩 모드 대신 LACP를 선택해야 하는 경우, 최신 Linux 서버에서 LACP를 구성하는 방법, 그리고 작동 여부를 확인하는 방법에 대해 다룹니다.

링크 어그리게이션과 LACP란 무엇인가요?

링크 어그리게이션은 여러 개의 물리적 네트워크 연결을 하나의 논리적 채널로 결합하는 기술입니다. 이는 링크 그룹 전체의 총 가용 대역폭을 늘리고, 구성원 링크 중 하나가 다운될 경우 자동 페일오버를 제공하는 두 가지 목적을 수행합니다.

LACP(Link Aggregation Control Protocol)는 IEEE 802.3ad에서 정의한 링크 집계(link aggregation)의 동적 버전입니다. LACP는 양쪽 끝단의 정적 구성에 의존하는 대신, 서버와 스위치 간에 LACPDU라고 하는 제어 패킷을 교환합니다. 양측은 어떤 링크를 집계 그룹에 포함시킬지 협상하고, 각 링크의 상태를 모니터링하며, 조건이 변함에 따라 구성원을 그룹에 추가하거나 제외합니다.

리눅스 환경에서 LACP는 커널 본딩 드라이버의 모드 4(802.3ad)로 실행됩니다. 이 드라이버는 IP 주소를 소유하는 논리 인터페이스(일반적으로 bond0)를 생성하고, eth0 와 eth1 와 같은 물리적 인터페이스는 본딩의 하위 요소가 됩니다. OS 관점에서는 하나의 네트워크 인터페이스가 존재합니다. 물리적 회선 관점에서는 여러 개의 병렬 이더넷 링크가 존재합니다.

사람들이 흔히 기대하지만 LACP가 구체적으로 수행하지 않는 몇 가지 사항:

• 단일 TCP 연결은 여전히 하나의 물리적 링크를 통해 전송됩니다. LACP는 흐름 내의 패킷이 아닌 흐름 자체를 분산합니다. 1GbE 링크 두 개를 본딩하더라도 단일 다운로드 속도가 1Gbps를 초과하지는 않습니다.
• LACP를 사용하려면 802.3ad를 지원하는 스위치가 필요합니다. 비관리형 스위치나 LACP를 지원하지 않는 스위치와는 본딩을 형성할 수 없습니다.
• 모든 구성 링크는 동일한 속도와 듀플렉스 모드로 작동해야 합니다. 1GbE 포트를 10GbE 포트와 결합할 수는 없습니다.

Linux 본딩 모드: LACP를 사용할 때

Linux 본딩 드라이버는 7가지 모드를 지원합니다. 실제 운영 환경에서는 이 중 3가지 모드를 주로 사용합니다.

모드 1: 액티브-백업

하나의 구성 인터페이스만 활성화되고 나머지는 대기 상태로 유지됩니다. 활성화된 인터페이스에 장애가 발생하면 수백 밀리초 이내에 다른 인터페이스가 역할을 인수합니다. 스위치 구성이 필요하지 않으므로, 스위치를 제어할 수 없거나 스위치가 802.3ad를 지원하지 않는 경우 이 모드가 적합합니다. 중복성은 확보되지만 추가 대역폭은 확보되지 않습니다.

모드 4: 802.3ad (LACP)

모든 멤버가 트래픽을 처리합니다. 본딩 드라이버와 스위치는 LACP를 사용하여 활성 세트를 협상하고 장애를 감지합니다. 나가는 트래픽은 사용자가 구성한 해시 정책을 사용하여 멤버 간에 균형 있게 분배됩니다. 이는 다중 흐름 워크로드에 대해 중복성과 추가 대역폭을 모두 원할 때 관리형 스위치에 연결된 전용 서버를 위한 표준 선택입니다.

모드 6: balance-alb

스위치 지원 없이 양방향으로 적응형 부하 분산을 수행합니다. 드라이버가 ARP 응답을 가로채 MAC 주소를 재작성하고 들어오는 트래픽을 분배합니다. 작동은 하지만 LACP에 비해 안정성이 떨어집니다. 스위치 측 구성이 정말로 불가능한 경우에만 사용하십시오.

결정 규칙:

• 관리형 스위치가 없거나, 페일오버만 필요한 경우: 모드 1 (active-backup).
• 관리형 스위치가 있고, 다중 흐름이 있으며, 대역폭과 중복성을 모두 원할 경우: 모드 4(LACP).
• 관리형 스위치 구성이 불가능하지만 양방향 부하 분산이 필요한 경우: 모드 6 (balance-alb).

모드 0(balance-rr), 2(balance-xor), 3(broadcast), 5(balance-tlb)도 존재하지만, 최신 하드웨어에서는 거의 적합한 선택이 아닙니다. 특별한 사유가 없는 한 모드 1 또는 모드 4를 선택하십시오.

Linux에서 LACP 본딩 구성

최신 Ubuntu 및 Debian 시스템에서는 netplan을 통해 LACP를 구성합니다. RHEL, CentOS Stream, AlmaLinux 및 Rocky Linux에서는 nmcli 또는 기본 연결 파일을 편집하여 NetworkManager를 사용하십시오.

Netplan (Ubuntu, Debian)

다음 내용을 /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

그런 다음 다음 명령으로 적용합니다 netplan apply. 주요 매개변수:

• mode: 802.3ad LACP를 활성화합니다.
• lacp-rate: fast 기본값인 30초 대신 1초마다 LACPDU를 전송합니다. 스위치 설정과 일치해야 합니다.
• mii-monitor-interval: 100 100ms마다 링크 상태를 확인합니다.
• transmit-hash-policy: layer3+4 소스/대상 IP 및 TCP/UDP 포트를 기준으로 트래픽을 분배합니다. 이는 일반적인 웹 및 데이터베이스 트래픽에 대해 기본 layer2 일반적인 웹 및 데이터베이스 트래픽에 대해 더 나은 부하 분산을 제공합니다.

NetworkManager (RHEL, AlmaLinux, Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

스위치 측

스위치에는 LACP 활성 모드로 구성된 LAG 그룹(종종 포트 채널이라고 함)이 필요하며, 이 그룹의 구성 포트 수는 본드와 동일해야 합니다. 정확한 구문은 벤더에 따라 다르지만, 요구 사항은 동일합니다. 포트는 동일한 VLAN에 속해야 하고, 동일한 속도와 듀플렉스로 설정되어야 하며, 적어도 한쪽에서 LACP 활성 모드를 사용해야 합니다. 양쪽 모두 활성 모드로 설정하는 것이 가장 안전한 구성입니다.

Cisco IOS의 경우:

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

Aruba/ProCurve에서:

trunk 1-2 trk1 lacp

스위치의 lacp_rate 스위치의 설정은 호스트와 일치해야 합니다. 이 부분의 불일치는 가장 흔한 LACP 구성 오류 중 하나이며, 30초마다 간헐적인 플래핑을 유발합니다.

LACP 확인 및 문제 해결

Linux 측에서 본드(bond)의 실시간 상태를 확인합니다:

cat /proc/net/bonding/bond0

출력 결과에서 확인해야 할 네 가지 사항:

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation 모드 4가 로드되었음을 확인합니다.
2. 다음과 같이 나열된 각 하위 인터페이스: MII Status: up 로 나열된 각 하위 인터페이스와 link failure count: 0.
3. 0이 아닌 Partner Mac Address 값을 가집니다. 이 값이 모두 0이라면, 해당 포트가 LACP 활성 LAG에 속하지 않거나 케이블이 잘못된 포트에 연결되어 있어 스위치가 LACP 패킷을 전혀 전송하지 않고 있음을 의미합니다.
4. Aggregator ID 모든 멤버에서 동일합니다. ID가 서로 다르면 멤버들이 실제로 결합되지 않고 독립적으로 작동하고 있음을 의미합니다.

대역폭이 사용되고 있는지 확인하는 가장 빠른 방법은 여러 병렬 스트림(iperf3 -P 8)을 실행하는 것입니다. 총 처리량이 단일 링크의 용량을 초과하면 LACP가 올바르게 부하 분산되고 있는 것입니다. 단일 스트림 테스트에서 하나의 링크 속도가 나타나는 것은 버그가 아니라 정상적인 동작입니다.

가장 흔한 LACP 문제와 그 원인:

• 파트너 MAC 주소가 모두 0인 경우: 스위치 포트가 LACP 활성 LAG에 속하지 않거나, 케이블이 잘못 연결된 것입니다.
• 본딩은 활성화되었으나 처리량이 단일 링크에 고정된 경우: 해시 정책이 layer2로 설정되어 있어, 목적지 MAC에 대해서만 해싱을 수행합니다. layer3+4.
• 30초마다 간헐적으로 연결이 끊어짐: lacp_rate 호스트와 스위치 간 불일치.
• 하위 장치 중 하나는 작동하지만 다른 하나는 트래픽을 전달하지 않습니다: 속도/듀플렉스 불일치이거나, 스위치 측에서 해당 스위치 포트들이 동일한 LAG 그룹에 속해 있지 않습니다.

LACP가 적합하지 않은 경우

LACP는 하나의 호스트와 하나의 스위치(또는 하나의 스위치 스택) 사이의 여러 링크를 통합하여 중복성과 흐름별 대역폭을 확보하는 특정 문제를 해결합니다. LACP가 적합한 도구가 아닌 시나리오도 있습니다.

중복성만 필요하고 스위치가 802.3ad를 지원하지 않는다면, 대신 모드 1(active-backup)을 사용하십시오. 이 모드는 어떤 환경에서도 작동합니다.

섀시 수준의 중복성을 위해 서로 다른 두 스위치 간에 링크를 결합해야 하는 경우, 표준 LACP는 관련이 없는 두 스위치 간을 연결하지 못합니다. 이 경우 두 스위치가 하나의 논리적 LACP 파트너로 작동하는 멀티-섀시 링크 어그리게이션(MLAG)이 필요합니다. 대부분의 엔터프라이즈 스위치 벤더는 이를 자체 브랜드명으로 구현합니다: Cisco vPC, Arista MLAG, Juniper MC-LAG.

단일 트래픽 흐름이 하나의 링크 대역폭을 초과해야 하는 경우, LACP로는 이를 달성할 수 없습니다. 해결책은 더 빠른 물리적 링크를 사용하거나(2개의 10GbE를 1개의 25GbE 또는 40GbE로 교체), 아예 다른 기술을 사용하는 것입니다. SR-IOV는 각 가상 머신(VM)에 하드웨어 가속 가상 NIC를 제공함으로써 가상 머신에 근접 라인 속도의 단일 흐름 성능을 제공하지만, 이는 다른 문제를 해결하는 것이며 고유한 제약 사항이 있습니다. 이는 별도의 게시물에서 다룰 주제입니다.

수많은 동시 연결을 처리하는 대부분의 전용 및 코로케이션 서버의 경우, LACP가 여전히 표준적인 해결책입니다. 해싱을 적용한 두 개의 결합된 10GbE 링크는 layer3+4 해싱을 적용하면 수많은 흐름에 걸쳐 18Gbps 이상의 총 트래픽을 여유롭게 처리할 수 있으며, NIC 또는 케이블 장애가 발생하더라도 패킷 손실 없이 서비스를 유지할 수 있습니다.