Linux에서 장애 조치 및 고가용성 네트워크 본딩을 구성하는 방법

이 페이지에서

1. 서문
2. 설치 단계
3. 구성 단계
4. 테스트 단계

이 자습서에서는 Linux 서버에서 네트워크 본딩을 구성하는 방법에 대해 설명합니다. 시작하기 전에 네트워크 결합이 무엇이며 어떤 역할을 하는지 설명하겠습니다. Windows 환경에서 네트워크 본딩을 네트워크 티밍이라고 합니다. 이는 모든 서버 아키텍처가 기본 이더넷 케이블 중 하나에 오작동이 있거나 잘못 구성된 시나리오에서 고가용성 및 장애 조치를 제공하는 데 도움이 되는 기능입니다.

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

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

1. 서문

이 튜토리얼에서는 32비트 버전의 Oracle Linux 6.4를 사용하고 있습니다. 구성이 Oracle Linux에서 수행되더라도 이 단계는 CentOS 및 Red Hat OS 배포판과 64Bit 시스템에도 적용할 수 있습니다. 예제 설정의 최종 결과는 이더넷 네트워크 중 하나를 비활성화한 경우에도 본딩 서버에 대한 연결이 연결된 상태로 유지됨을 보여줍니다. 이 예제에서는 활성 백업 정책인 모드 1을 사용하여 네트워크 본딩을 적용하는 방법을 보여줍니다.

2. 설치 단계

이 프로세스에는 설치가 필요하지 않습니다. 서버의 기본 Linux 설치에는 네트워크 본딩 구성에 필요한 모든 패키지가 포함됩니다.

3. 구성 단계

구성을 시작하기 전에 먼저 서버에 최소 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

Shutting down interface eth0: [ OK ]
Shutting down interface eth1: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface 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은 백업 인터페이스로 사용됩니다.

4. 테스트 단계

이제 모든 것이 예상대로 구성되었습니다. 우리가 만든 구성이 올바른지 확인하기 위해 간단한 테스트를 해봅시다. 이 테스트를 위해 새 서버(또는 Linux 데스크톱)에 로그인하고 본딩 서버에 핑을 시작하여 테스트 중에 간헐적인 연결이 발생하는지 확인합니다. 다음은 단계입니다.

login as: root
'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을 종료했지만 여전히 본딩 서버에 핑하고 액세스할 수 있음을 알 수 있습니다. 이제 테스트를 1개 더 해보자. 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

엄지척! 우리는 본딩 서버를 성공적으로 구성하고 입증하여 네트워크 장애 조치 조건에서 재해 복구 시나리오를 제공합니다.