네트워크 구성 · 9 min read · Nov 30, 2025

리눅스에서 페일오버 및 고가용성 네트워크 본딩 구성 방법

이 튜토리얼은 리눅스 서버에서 네트워크 본딩을 구성하는 방법을 설명합니다. 시작하기 전에 네트워크 본딩이 무엇인지, 그리고 그것이 무엇을 하는지 설명하겠습니다. 윈도우 환경에서는 네트워크 본딩을 네트워크 팀이라고 부르며, 이는 서버 아키텍처가 주요 이더넷 케이블 중 하나에 고장이 발생하거나 잘못 구성된 경우에 고가용성과 페일오버를 제공하는 데 도움이 되는 기능입니다.

일반적으로 이는 프로덕션 용도로 서버를 설정할 때 구현해야 하는 모범 사례이자 필수 기능입니다. 리눅스 환경 구성에서도 이 기능을 수행할 수 있지만, 먼저 네트워크 관리자가 서버에 연결된 스위치가 네트워크 본딩을 지원하는지 확인해야 합니다. 서버 환경에서 구현할 수 있는 여러 본딩 모드가 있습니다. 아래는 사용 가능한 모드와 그 기능의 목록입니다:

  • Balance-rr
    이 모드는 라운드 로빈 정책을 통해 로드 밸런싱 및 장애 허용(페일오버) 기능을 제공합니다. 즉, 첫 번째 사용 가능한 슬레이브에서 마지막 슬레이브까지 패킷을 순차적으로 전송합니다.
  • Active-Backup
    이 모드는 활성-백업 정책을 통해 장애 허용 기능을 제공합니다. 본딩 이더넷이 활성화되면, 이더넷 슬레이브 중 하나만 활성화됩니다. 다른 이더넷 슬레이브는 현재 활성 슬레이브가 다운될 경우에만 활성화됩니다. 이 모드를 선택하면 본딩 MAC 주소가 외부에서 하나의 네트워크 어댑터에만 표시됩니다. 이는 스위치의 혼란을 피하기 위함입니다.
  • Balance-xor
    이 모드는 로드 밸런싱 및 장애 허용 기능을 제공합니다. 선택된 전송 해시 정책에 따라 전송합니다. 대체 전송 정책은 xmit_hash_policy 옵션을 통해 선택할 수 있습니다.
  • Broadcast
    이 모드는 장애 허용 기능만 제공합니다. 모든 슬레이브 이더넷 인터페이스에서 모든 것을 전송합니다.
  • 802.3ad
    이 모드는 로드 밸런싱 및 장애 허용 기능을 제공합니다. 동일한 속도 및 이중 설정을 공유하는 집합 그룹을 생성합니다. 활성 집합기에서 모든 슬레이브 이더넷 인터페이스를 활용하며, 802.3ad 사양을 기반으로 합니다. 이 모드를 구현하려면 ethtool이 각 슬레이브의 속도 및 이중 모드를 검색하기 위한 기본 드라이버를 지원해야 합니다. 스위치도 동적 링크 집합을 지원해야 합니다. 일반적으로 이는 상세 구성을 위해 네트워크 엔지니어의 개입이 필요합니다.
  • Balance-TLB
    이 모드는 이름 TLB가 전송 로드 밸런싱을 나타내듯이 로드 밸런싱 기능을 제공합니다. 이 모드에서는 구성 tlb_dynamic_lb = 1인 경우, 나가는 트래픽이 각 슬레이브의 현재 부하에 따라 분배됩니다. 구성 tlb_dynamic_lb = 0인 경우 로드 밸런싱이 비활성화되며, 해시 분포만 사용하여 로드가 분배됩니다. 이 모드에서는 ethtool이 각 슬레이브의 속도를 검색하기 위한 기본 드라이버를 지원해야 합니다.
  • Balance-ALB
    이 모드는 이름 TLB가 적응형 로드 밸런싱을 나타내듯이 로드 밸런싱 기능을 제공합니다. balance-tlb와 유사하지만, 송신 및 수신 트래픽 모두 본딩됩니다. ARP 협상을 통해 로드 밸런싱을 달성합니다. 본딩 드라이버는 로컬 시스템에서 전송되는 ARP 응답을 가로채고, 소스 하드웨어 주소를 본드의 슬레이브 중 하나의 고유 하드웨어 주소로 덮어씁니다. 이 모드에서는 ethtool이 각 슬레이브의 속도를 검색하기 위한 기본 드라이버를 지원해야 합니다.

  1. 사전 참고

이 튜토리얼에서는 32비트 버전의 Oracle Linux 6.4를 사용하고 있습니다. Oracle Linux에서 구성이 이루어지지만, 이 단계는 CentOS 및 Red Hat OS 배포판과 64비트 시스템에도 적용 가능하다는 점에 유의하시기 바랍니다. 예제 설정의 최종 결과는 이더넷 네트워크 중 하나를 비활성화하더라도 본딩 서버에 연결이 유지됨을 보여줄 것입니다. 이 예제에서는 활성-백업 정책인 모드 1을 사용하여 네트워크 본딩을 적용하는 방법을 보여드리겠습니다.

  1. 설치 단계

이 과정에서는 설치가 필요하지 않습니다. 서버의 기본 리눅스 설치에는 네트워크 본딩 구성을 위한 모든 필수 패키지가 포함되어 있습니다.

  1. 구성 단계

구성을 시작하기 전에, 먼저 서버에 최소 2개의 이더넷 인터페이스가 구성되어 있는지 확인해야 합니다. 이를 확인하기 위해 네트워크 구성 폴더로 이동하여 사용 가능한 이더넷 인터페이스를 나열합니다. 아래는 단계입니다:

cd /etc/sysconfig/network-scripts/  
ls *ifcfg*eth*

결과는 다음과 같습니다:

ifcfg-eth0 ifcfg-eth1

현재 서버에 ETH0 및 ETH1이라는 2개의 이더넷 인터페이스가 설정되어 있음을 확인하십시오.

이제 BOND0이라는 본딩 인터페이스를 구성하겠습니다. 이 인터페이스는 ETH0 및 ETH1의 물리적 이더넷 인터페이스를 포함하는 가상 이더넷 인터페이스가 될 것입니다. 아래는 단계입니다:

vi ifcfg-bond0
DEVICE=bond0  
ONBOOT=yes  
MASTER=yes  
IPADDR=172.20.43.110  
NETMASK=255.255.255.0  
GATEWAY=172.20.43.1  
BONDING_OPTS="mode=1 miimon=100"  
TYPE=Ethernet

그런 다음 실행:

ls *ifcfg*bon*

결과는:

ifcfg-bond0

그게 전부입니다. BOND0 인터페이스 내부에 IP 주소를 포함시켰습니다. 이 IP 주소는 서버에 연결된 유일한 IP 주소가 될 것입니다. 프로세스를 진행하기 위해 BOND0 인터페이스와 관련된 물리적 이더넷 인터페이스를 수정해야 합니다. 아래는 단계입니다:

vi ifcfg-eth0
DEVICE=eth0  
TYPE=Ethernet  
ONBOOT=yes  
NM_CONTROLLED=no  
MASTER=bond0  
SLAVE=yes 
vi ifcfg-eth1
DEVICE=eth1  
TYPE=Ethernet  
ONBOOT=yes  
NM_CONTROLLED=no  
MASTER=bond0  
SLAVE=yes

완료되었습니다. ETH0 및 ETH1 인터페이스의 수정을 완료했습니다. 두 인터페이스 내부의 IP 주소를 제거하고 MASTER = bond0을 추가했습니다. 이는 두 인터페이스가 이더넷 BOND0 인터페이스에 전념하는 가상 인터페이스가 될 것임을 확인하기 위해 필요합니다.

구성을 진행하기 위해 /etc/modprobe.d에 bonding.conf라는 본딩 구성 파일을 생성하겠습니다. 아래는 단계입니다:

vi /etc/modprobe.d/bonding.conf
alias bond0 bonding  
options bond0 mode=1 miimon=100 
modprobe bonding

위 구성을 기반으로, BOND0 인터페이스를 사용하여 본딩 모듈을 구성했습니다. 또한 본딩 구성을 활성-백업 정책인 모드 = 1을 사용하도록 할당했습니다. 옵션 miimon = 100은 본딩 서버가 인터페이스 상태를 밀리초 단위로 모니터링하는 주기를 나타냅니다. 위 설명에 따라 이 모드는 서버 네트워크 구성에서 장애 허용 기능을 제공합니다.

모든 설정이 완료되었으므로, 새로운 구성을 로드하기 위해 네트워크 서비스를 재시작하겠습니다. 아래는 단계입니다:

service network restart
인터페이스 eth0 종료: [ OK ]  
인터페이스 eth1 종료: [ OK ]  
루프백 인터페이스 종료: [ OK ]  
루프백 인터페이스 시작: [ OK ]  
인터페이스 bond0 시작: [ OK ]

훌륭합니다. 이제 위에서 만든 새로운 구성을 로드했습니다. 네트워크 목록에 BOND0이라는 새로운 인터페이스가 표시됩니다. 또한 ETH0 및 ETH1 인터페이스에는 IP 주소가 할당되지 않고, 오직 BOND0 인터페이스만 IP를 표시하는 것을 확인할 수 있습니다.

ifconfig
bond0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
inet addr:172.20.43.110 Bcast:172.20.43.255 Mask:255.255.255.0  
inet6 addr: fe80::a00:27ff:fe61:e488/64 Scope:Link  
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1  
RX packets:1723 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:0  
RX bytes:147913 (144.4 KiB) TX bytes:108429 (105.8 KiB) 
eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:103486 (101.0 KiB) TX bytes:105439 (102.9 KiB) 
eth1 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:632 errors:0 dropped:0 overruns:0 frame:0  
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:44487 (43.4 KiB) TX bytes:3288 (3.2 KiB) 
lo Link encap:Local Loopback  
inet addr:127.0.0.1 Mask:255.0.0.0  
inet6 addr: ::1/128 Scope:Host  
UP LOOPBACK RUNNING MTU:16436 Metric:1  
RX packets:208 errors:0 dropped:0 overruns:0 frame:0  
TX packets:208 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:0  
RX bytes:18080 (17.6 KiB) TX bytes:18080 (17.6 KiB)

본딩 상태를 다음 명령어로 확인할 수도 있습니다:

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) 
Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: None  
Currently Active Slave: eth0  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0 
Slave Interface: eth0  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:61:e4:88  
Slave queue ID: 0 
Slave Interface: eth1  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:c8:46:40  
Slave queue ID: 0

위에서 보시다시피, ETH0 및 ETH1 인터페이스를 활성-백업 모드를 사용하여 본딩 구성으로 성공적으로 변환했습니다. 이제 서버는 ETH0 인터페이스를 사용하고 있으며, ETH1은 백업 인터페이스로 설정되어 있습니다.

  1. 테스트 단계

이제 모든 것이 예상대로 구성되었습니다. 우리가 만든 구성이 올바른지 확인하기 위해 간단한 테스트를 수행하겠습니다. 이 테스트를 위해 새로운 서버(또는 리눅스 데스크탑)에 로그인하고 본딩 서버에 핑을 보내 연결이 간헐적으로 발생하는지 확인하겠습니다. 아래는 단계입니다:

login as: root  
[email protected]'s password:  
Last login: Wed Sep 14 12:50:15 2016 from 172.20.43.80
ping 172.20.43.110
PING 172.20.43.110 (172.20.43.110) 56(84) bytes of data.  
64 bytes from 172.20.43.110: icmp_seq=1 ttl=64 time=0.408 ms  
64 bytes from 172.20.43.110: icmp_seq=2 ttl=64 time=0.424 ms  
64 bytes from 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms  
64 bytes from 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms  
64 bytes from 172.20.43.110: icmp_seq=5 ttl=64 time=0.554 ms  
64 bytes from 172.20.43.110: icmp_seq=6 ttl=64 time=0.443 ms  
64 bytes from 172.20.43.110: icmp_seq=7 ttl=64 time=0.663 ms  
64 bytes from 172.20.43.110: icmp_seq=8 ttl=64 time=0.961 ms  
64 bytes from 172.20.43.110: icmp_seq=9 ttl=64 time=0.461 ms  
64 bytes from 172.20.43.110: icmp_seq=10 ttl=64 time=0.544 ms  
64 bytes from 172.20.43.110: icmp_seq=11 ttl=64 time=0.412 ms  
64 bytes from 172.20.43.110: icmp_seq=12 ttl=64 time=0.464 ms  
64 bytes from 172.20.43.110: icmp_seq=13 ttl=64 time=0.432 ms

이 시간 동안 본딩 서버로 돌아가서 이더넷 인터페이스 ETH0를 끄겠습니다. 아래는 단계입니다:

ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88  
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1  
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0  
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0  
collisions:0 txqueuelen:1000  
RX bytes:103486 (201.0 KiB) TX bytes:105439 (122.9 KiB) 
ifdown eth0

이제 ETH0 네트워크 인터페이스의 서비스를 종료했습니다. 본딩 상태를 확인해 보겠습니다. 아래는 단계입니다:

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) 
Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: None  
Currently Active Slave: eth1  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0 
Slave Interface: eth1  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:c8:46:40  
Slave queue ID: 0

이제 ETH0 인터페이스가 본딩 상태에서 더 이상 존재하지 않음을 확인할 수 있습니다. 이 시간 동안 이전 테스트 서버로 돌아가서 본딩 서버에 대한 지속적인 핑을 확인하겠습니다.

64 bytes from 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms  
64 bytes from 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms  
64 bytes from 172.20.43.110: icmp_seq=24 ttl=64 time=0.437 ms  
64 bytes from 172.20.43.110: icmp_seq=25 ttl=64 time=0.504 ms  
64 bytes from 172.20.43.110: icmp_seq=26 ttl=64 time=0.401 ms  
64 bytes from 172.20.43.110: icmp_seq=27 ttl=64 time=0.454 ms  
64 bytes from 172.20.43.110: icmp_seq=28 ttl=64 time=0.432 ms  
64 bytes from 172.20.43.110: icmp_seq=29 ttl=64 time=0.434 ms  
64 bytes from 172.20.43.110: icmp_seq=30 ttl=64 time=0.411 ms  
64 bytes from 172.20.43.110: icmp_seq=31 ttl=64 time=0.554 ms  
64 bytes from 172.20.43.110: icmp_seq=32 ttl=64 time=0.452 ms  
64 bytes from 172.20.43.110: icmp_seq=33 ttl=64 time=0.408 ms  
64 bytes from 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms

좋습니다. 이제 ETH0 인터페이스를 종료했음에도 불구하고 여전히 본딩 서버에 핑을 보내고 접근할 수 있음을 확인할 수 있습니다. 이제 한 가지 테스트를 더 해보겠습니다. ETH0 인터페이스를 다시 켜고 ETH1 인터페이스를 끕니다.

ifup eth0  
cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) 
Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: None  
Currently Active Slave: eth1  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0 
Slave Interface: eth1  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:c8:46:40  
Slave queue ID: 0 
Slave Interface: eth0  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:61:e4:88  
Slave queue ID: 0

ETH0 인터페이스가 이미 활성화되어 있으므로 ETH1 인터페이스를 종료하겠습니다.

ifdown eth1
cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) 
Bonding Mode: fault-tolerance (active-backup)  
Primary Slave: None  
Currently Active Slave: eth0  
MII Status: up  
MII Polling Interval (ms): 100  
Up Delay (ms): 0  
Down Delay (ms): 0 
Slave Interface: eth0  
MII Status: up  
Speed: 1000 Mbps  
Duplex: full  
Link Failure Count: 0  
Permanent HW addr: 08:00:27:61:e4:88  
Slave queue ID: 0

이제 테스트 서버로 돌아가서 본딩 서버에 대한 지속적인 핑에서 어떤 일이 발생하는지 확인하겠습니다.

64 bytes from 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms  
64 bytes from 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms  
64 bytes from 172.20.43.110: icmp_seq=86 ttl=64 time=0.401 ms  
64 bytes from 172.20.43.110: icmp_seq=87 ttl=64 time=0.454 ms  
64 bytes from 172.20.43.110: icmp_seq=88 ttl=64 time=0.432 ms  
64 bytes from 172.20.43.110: icmp_seq=89 ttl=64 time=0.434 ms  
64 bytes from 172.20.43.110: icmp_seq=90 ttl=64 time=0.411 ms  
64 bytes from 172.20.43.110: icmp_seq=91 ttl=64 time=0.420 ms  
64 bytes from 172.20.43.110: icmp_seq=92 ttl=64 time=0.487 ms  
64 bytes from 172.20.43.110: icmp_seq=93 ttl=64 time=0.551 ms  
64 bytes from 172.20.43.110: icmp_seq=94 ttl=64 time=0.523 ms  
64 bytes from 172.20.43.110: icmp_seq=95 ttl=64 time=0.479 ms

좋습니다! 우리는 본딩 서버가 네트워크 페일오버 조건에서 재해 복구 시나리오를 처리할 수 있음을 성공적으로 구성하고 증명했습니다.

Share: X/Twitter LinkedIn
#네트워크 구성

새 게시물을 받은 편지함에서 받기

스팸은 없습니다. 언제든지 구독 해지 가능합니다.