Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 :
- Willy Tarreau <willy at meta-x.org>
- Constantine Gavrilov <const-g at xpert.com>
- Chad N. Tindel <ctindel at ieee dot org>
- Janice Girouard <girouard at us dot ibm dot com>
Note :
------
bonding 드라이버는 원래 커널 2.0에 대한 Donald Becker의 Beowulf 패치에서 파생하였다. 이것은 처음 버전에서 많이 변경되었기 때문에 extreme-linux와 Beowulf 사이트에서 제공하는 툴은 bonding 드라이버와 잘 작동하지 않을 것이다.
새로운 드라이버 버전을 얻으려면 예전 커널을 패치하고, 사용자영역의 툴을 업데이트 해야 한다. 이 문서의 끝에 기록된 링크를 참조하라.
목차
=================
설치(Installation)
Bond 설정(Bond Configuration)
모듈 파라미터(Module Parameters)
다중 Bond 설정(Configuring Multiple Bonds)
설정 변경(Switch Configuration)
Bond 설정 검증(Verifying Bond Configuration)
자주 묻는 질문들(Frequently Asked Questions)
고가용성(High Availability)
Promiscuous Sniffing notes
제약(Limitations)
참고와 링크(Resources and Links)
설치
============
1) bonding 드라이버를 포함한 커널 빌드하기 (Build kernel with the bonding driver)
--------------------------------------------------------------
최신 bond 드라이버 버전을 위해서, 커널 2.4.12 또는 그 이상의 커널을 사용하라
(그렇지 않으면 패치가 필요하다).
‘make menuconfig/xconfig/config’를 사용하여 커널 옵션을 설정한다. “Network device support” 부분에서 “Bonding driver support” 를 선택하라. 하나 이상의 bonding 장치를 설정하고, 드라이버를 모듈로 설치할 것을 권장하는데 이는 드라이버에 파라미터를 넘겨줄 수 있는 유일한 방법이 모듈방식이기 때문이다.
커널과 모듈을 컴파일하고 설치한다.
2) 사용자영역 툴을 받아서 설치하기(Get and install the userspace tools)
------------------------------------------------------
현재 bonding 드라이버 버전은 업데이트된 ifenslave 프로그램을 필요로 한다. Extreme-linux와 beowulf의 것과는 동작하지 않는다. 커널 2.4.12 이상 커널은 Documentaion/network 디렉토리에 ifenslave.c 의 업데이트된 버전을 포함한다. 더 오래된 커널에 대해서는 이 문서의 끝에 기록된 링크를 참고하라.
중요!!! 만일 레드헷 7.1이나 그 이후 버전을 사용하고 있다면 /usr/include/linux가 더 이상 /usr/src/linux/include/linux에 대한 심볼릭 링크가 아니기 때문에 주의해야 한다. 만일 그런 상태에서 ifenslave를 컴파일한다면 ifenslave는 성공한 것처럼 보이지만 bond는 동작하지 않을 것이다. Ifenslaver 컴파일시 –I 옵션의 목적은 /usr/include/linux 에서가 아니라 /usr/src/linux/include/linux/if_bonding.h를 사용하도록 하는 것이다.
Ifenslave.c 를 설치하기 위해서 다음과 같이 수행하라.
# gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave
# cp ifenslave /sbin/ifenslave
Bond 설정(Bond Configuration)
========================
bond0 인터페이스가 설정되었을 때, bonding 드라이버가 자동으로 load 되도록 하기 위해서 /etc/modules.conf에 다음 라인을 추가해야 한다. 특별히 자세한 modules.conf 문법을 위해서는 modules.conf 매뉴얼 페이지를 참조하라. 문서의 모듈 파라미터 부분에서는 bonding 드라이버 파라미터에 대해서 설명한다.
alias bond0 bonding
bond0 네트워크 인터페이스를 정의하기 위해서는 일반적으로 널리 알려진 방법을 사용하라. 최근 레드헷 배포판을 예로 들면, /etc/sysconfig/network-script 디렉토리에 다음과 유사하게 ifcfg-bond0 파일을 생성하라.
DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
(자신의 네트워크에 맞는 값을 넣으시오)
bond의 일부분인 모든 인터페이스는 SALVE와 MASTER를 정의해야 한다. 예를 들어 레드헷의 경우에 eth0와 eth1을 bond 인터페이스 bond0의 부분으로 만들고 싶다면, eth0, eth1의 설정파일(ifcfg-eth0, ifcfg-eth1)은 아래와 유사할 것이다.
DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
ifcfg-eth1설정 파일에 DEVICE=eth1을 사용하라. 만일 두 번째 bonding 인터페이스(bond1)를 설정한다면, 네트워크 인터페이스를 bond1의 슬레이브로 만들기 위해 설정 파일에 MASTER=bond1 이라고 기록한다.
네트워크 서브시스템을 재시작하거나, 관리 툴이 허용한다면 bonding 디바이스만 올리면 된다. 그렇지 않으면 리부팅하라. 레드헷에서는 ‘ifup bond0’ 또는 ‘/etc/rc.d/init.d/network restart’ 실행하면 된다.
만일 배포판의 관리툴이 네트워크 인터페이스 설정에서 master/slave 개념을 지원하지 않는다면, 다음 명령을 사용해서 bonding 디바이스를 수동으로 설정해야 할 것이다.
# /sbin/ifconfig bond0 192.168.1.1 netmask 255.255.255.0 \
broadcast 192.168.1.255 up
# /sbin/ifenslave bond0 eth0
# /sbin/ifenslave bond0 eth1
(자신의 네트워크에 맞는 값을 넣으시오)
적당한 rc 디렉토리안에 이러한 명령이 담긴 스크립트를 생성할 수 있다.
만일 bonding 드라이버가 올라오기 전에 모든 네트워크 드라이버를 올리고 싶다면, 다음 명령을 modules.conf 에 추가함으로써 eth0, eth1 네트워크 드라이버를 bonding 드라이버가 올라오기 전에 올릴 수 있다.
probeall bond0 eth0 eth1 bonding
줄의 끝에 bond0 자체를 참조하지 않도록 주의하라, 그렇지 않으면 modprobe는 끝없이 loop를 돌다가 죽을 것이다.
디바이스 특성(MTU 크기와 같은)을 슬레이브 디바이스에 전달하기 위해서, 디바이스를 슬레이브화 시키기 전에 bond 특성을 설정한다. 특성은 슬레이브화 과정에서 전달된다.
만일 SNMP 가 수행중이라면, bonding 드라이버는 bond에 참가하는 어떤 네트워크 드라이버보다 먼저 올라와야 한다. 이러한 요구사항은 주어진 IP 주소에서 첫 번째로 발견되는 인터페이스와 인터페이스 인덱스(ipAdEntIfIndex)가 연결되기 때문이다. 즉, 각 IP 주소에 대해서 ipAdEntIfIndex는 단 하나가 존재한다. 예를 들어 만일 eth0와 eth1이 bond0의 슬레이브이고, eth0에 대한 드라이버가 bonding 드라이버보다 먼저 올라왔다면, IP 주소에 대한 인터페이스는 eth0 인터페이스와 연결된다. 이러한 설정은 아래와 같다. IP 주소 192.168.1.1은 fiDescr 테이블(ifDescr.2)의 eth0에 대한 인덱스인 인터페이스 인덱스 2를 갖는다.
interfaces.ifTable.ifEntry.ifDescr.1 = lo
interfaces.ifTable.ifEntry.ifDescr.2 = eth0
interfaces.ifTable.ifEntry.ifDescr.3 = eth1
interfaces.ifTable.ifEntry.ifDescr.4 = eth2
interfaces.ifTable.ifEntry.ifDescr.5 = eth3
interfaces.ifTable.ifEntry.ifDescr.6 = bond0
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1
이러한 문제는 bond에 참여하는 다른 네트워크 드라이버보다 먼저 bonding 드라이버를 올림으로써 해결할 수 있다. 아래는 bonding 드라이버를 먼저 올리는 예이다. IP 주소 192.168.1.1은 정확하게 ifDescr.2와 연결된다.
interfaces.ifTable.ifEntry.ifDescr.1 = lo
interfaces.ifTable.ifEntry.ifDescr.2 = bond0
interfaces.ifTable.ifEntry.ifDescr.3 = eth0
interfaces.ifTable.ifEntry.ifDescr.4 = eth1
interfaces.ifTable.ifEntry.ifDescr.5 = eth2
interfaces.ifTable.ifEntry.ifDescr.6 = eth3
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1
어떤 배포판은 ifDescr의 인터페이스 이름을 알리지 않을 수도 있다. IP 주소와 IfIndex 사이의 연결이 유지 될 것이고, Interface_Scan_Next 와 같은 SNMP 함수는 그러한 연결을 알려줄 것이다.
모듈 파라미터(Module Parameters)
==========================
bonding 드라이버의 파라미터는 insmod 명령에 명령라인 인수를 사용해 제공될 수 있다. 일반적으로 이러한 파라미터는 /etc/modules.conf(modules.conf에 대한 매뉴얼 페이지를 참고하라)에 기록한다. 사용 가능한 bonding 드라이버 파라미터를 아래에 기술했다. 만일 파라미터가 기술되지 않았다면 기본값이 사용된다. 초기 bond를 설정할 때, bonding 드라이버 에러 메시지를 살펴보기 위해서 다른 콘솔 창을 열고 “tail –f /var/log/messages”를 실행하는 것을 권장한다.
mode
4가지 bonding 정책 중 하나를 기술한다. 기본값은 round-robin이다.
가능한 값은 다음과 같다.
0 Round-robin 정책: 첫 번째 가능한 슬레이브부터 마지막까지 순차적으로 전송한다. 이 모드는 부하분산과 장애 감내를 제공한다.
1 Active-backup 정책: bond에서 하나의 슬레이브만 활성화된다. 다른 슬레이브는 활성화된 슬레이브가 fail된 경우에만 활성화 된다.
2 XOR 정책: [(출발지 MAC 주소와 도착지 MAC 주소의 XOR) modula 슬레이브 개수] 에 기초하여 전송한다. 이것은 각 도착지 MAC 주소에 대해서 동일한 슬레이브를 선택하게 된다. 이 모드는 부하분산과 장애감내를 제공한다.
3 Broadcast 정책: 모든 슬레이브 인터페이스에 모든 것을 전송한다. 이것은 장애감내를 제공한다.
miimon
MII 링크 감시가 발생할 때 밀리(milli) 초 단위로 주파수를 기술한다. MII 링크 감시를 사용하지 않으려면 0 값을 준다. 100이 최초 시작할 때 적절한 값이 된다. 추가 정보를 위해서 고 가용성(High Availability) 부분을 참조하라. 기본값은 0 이다.
downdelay
링크가 죽은 것이 감지된 후에 링크를 사용하지 못하게 되는 지체 시간을 밀리(milli) 초 단위로 기술한다. 이것은 백만의 배수가 되어야 한다. 그렇지 않으면 값은 반올림될 것이다. 기본값은 0 이다.
updelay
링크가 되살아난 것을 감지한 후에 링크를 사용할 수 있게 되는 지체 시간을 밀리(milli) 초 단위로 기술한다. 이것은 백만의 배수가 되어야 한다. 그렇지 않으면 값은 반올림될 것이다. 기본값은 0 이다.
arp_interval
ARP 감시 주기를 밀리(milli) 초 단위로 기술한다. 만일 ARP 감시가 부하분산 모드(모드 0 또는 2)에서 사용된다면, 스위치(switch)는 round-robin처럼 모든 링크에 걸쳐 패킷을 동등하게 분배하는 모드에서 설정되어야 한다. 만일 스위치(switch)가 XOR 형식으로 패킷을 분산하도록 설정된다면, ARP 목표(target)로부터 오는 모든 답신(reply)은 동일한 링크로 받게 될 것이다. 이것은 다른 팀 멤버가 실패하도록 하는 원인이 될 수 있다. ARP 감시는 miimon과 함께 사용되면 안 된다. ARP 감시를 사용하지 않는 값은 0 이다. 기본값은 0 이다.
arp_ip_target
arp_interval > 0 일 때 사용하기 위한 ip 주소를 기술한다. 이것은 목표에게 링크의 상태를 검사하도록 보내어진 ARP 목표의 요청이다. 이 값은 ddd.ddd.ddd.ddd 형식으로 기술한다. 다중 ip 주소는 ‘,’로 구분되어야 한다. 적어도 하나의 ip 주소가 ARP 감시를 수행하기 위해 주어져야 한다. 설정할 수 있는 목표의 최대 개수는 16이다.
primary
문자열 (eth0, eth2, 등등)은 1차 디바이스와 동등하다. 만일 이 값이 입력되고, 디바이스가 on-line이라면 첫 번째 출력 미디어로 사용될 것이다. 디바이스가 off-line일 때는 다른 디바이스가 사용될 것이다. 그렇지 않으면 일단 failover가 감지되고, 새로운 기본 출력이 선택된다면, 또 fail될 때까지 출력 미디어로 남게 될 것이다. 이것은 하나의 슬레이브를 다른 것보다 더 우선 사용될 때 유용하다. 즉 하나의 슬레이브는 1000Mbps이고 다른 하나는 100Mbps일 때, 만일 1000Mbps 슬레이브가 fail되고 나중에 복구된다면, 일부러 100Mbps 슬레이브를 fail시키지 않고도, 더 빠른 슬레이브를 깔끔하게 활성화 시킬 수 있게 된다. ‘primary’를 설정하는 것은 active-backup 모드에서만 유효하다.
multicast
멀티캐스트 지원을 위한 모든 연산의 정수 값
가능한 값은:
0 사용불가 (멀티캐스트 지원안함)
1 활성 슬레이브에서만 가능, active-backup 모드에서 유용하다.
2 모든 슬레이브에서 가능, 기본값이다.
다중 Bonds 설정
==========================
만일 여러 가지 bonding 인터페이스가 필요하다면, 드라이버도 여러 개 올라와야 한다. 예를 들면, 매 100 ms 마다 링크 감시를 하는 두 개의 bonding 인터페이스를 설정하기 위해서 /etc/conf.modules은 다음과 같아야 한다.
alias bond0 bonding
alias bond1 bonding
options bond0 miimon=100
options bond1 -o bonding1 miimon=100
다중 ARP 목표 설정
================================
ARP 감시가 하나의 목표에서만 이루어질 수 있는 반면, 다중 ARP 목표는 감시할 여러 개의 목표를 가진 고 가용성 설정에서 유용하다. 하나의 목표인 경우에, 목표 그 자체가 다운되거나 ARP 요청에 응답하지 못하게 되는 문제를 가질 수 있다. 부가적인(또는 여러 개의) 목표를 가지는 것은 ARP 감시에 대한 신뢰도를 높일 수 있다.
다중 ARP 목표는 다음과 같이 콤마로 분리되어야 한다.
# example options for ARP monitoring with three targets
alias bond0 bonding
options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9
단일 목표에 대한 옵션은 아래와 같다.
# example options for ARP monitoring with one target
alias bond0 bonding
options bond0 arp_interval=60 arp_ip_target=192.168.0.100
스위치 설정
====================
스위치는 active-backup 정책이 사용될 때 설정할 필요가 없는 반면에, round-robin, XOR 그리고 broadcast 정책(모드 0, 2, 3)에 대해서 설정이 필요하다.
Bond 설정 검증
============================
1) Bonding 정보 파일
----------------------------
bonding 드라이버 정보 파일은 /proc/net/bond* 디렉토리에 있다.
드라이버가 모드 0와 miimon=1000이란 파라미터로 올라온 후에 /proc/net/bond0/info 의 내용은 아래와 같다.
Bonding Mode: load balancing (round-robin)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 1000
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth1
MII Status: up
Link Failure Count: 1
Slave Interface: eth0
MII Status: up
Link Failure Count: 1
2) 네트워크 검증
-----------------------
네트워크 설정은 ifconfig 명령을 사용하여 검증할 수 있다. 아래 예제에서 bond0 인터페이스는 마스터(MASTER)이고 eth0와 eth1은 슬레이브(SLAVE)이다. bond0의 모든 슬레이브는 bond0 와 동일한 MAC address를 갖는다는 것에 주의하라.
[root]# /sbin/ifconfig
bond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4
inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0
TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:0
eth0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4
inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0
TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0x1080
eth1 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4
inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0
TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:9 Base address:0x1400
자주 묻는 질문들
==========================
1. SMP에서도 정상적으로 동작하는가?
예. 예전 2.0.xx 채널 bonding 패치는 SMP에서 정상 작동하지 않는다. 새로운 드라이버는 처음부터 SMP를 고려하여 설계되었다.
2. bonding과 같이 동작하는 카드의 형태는 어떤 것인가?
어떤 종류의 이더넷(Ethernet) 카드(예를 들어 인텔 EtherExpress PRO/100과 3com 3c905b와 같이 여러 카드를 혼용할 수도 있다)와도 동작할 수 있다.
또한 기가빗 이더넷(gigabit ethernet) 카드와도 bond할 수 있다.
3. 얼마나 많은 bonding 장치를 가질 수 있는가?
올린 모듈당 하나이다. 이것을 어떻게 이것을 하는지에 대해서sms 모듈 파라미터(Module Parameter) 섹션을 참고하라
4. 얼마나 많은 슬레이브가 bonding 장치를 가질 수 있나?
네트워크 인터페이스의 개수로 제한된다. 리눅스는 시스템에서 장착할 수 있는 개수만큼의 네트워크 카드 개수를 지원한다.
5. 슬레이브의 링크가 다운이 되면 어떤 일이 일어나는가?
만일 당신의 이더넷 카드가 MII 또는 ETHTOOL 링크 상태 감시를 지원한다면, 그리고 MII 감시가 드라이버에서 가능하였다면(모듈 파라미터에서 기록된 것을 참고하라), adverse 결론은 없을 것이다. 이러한 bonding 드라이버는 어떻게 MII 정보를 얻고, 링크 상태에 따라서 어떻게 슬레이브를 사용 가능하게 하거나 사용 가능하지 않게 하는지를 알고 있다.
MII 상태를 지원하지 않는 이더넷 카드에 대해서, bonding이 정확하게 동작하게 하기 위해서 arp_interval과 arp_ip_target 파라미터가 기술되어야 한다. 만일 패킷이 정해진 arp_interval 동안 보내지거나 받아지지 않으면, ARP 요청이 주고 받는 패킷을 생성하기 위해 목표로 보내어 진다. 만일 이러한 시간 간격 후에, 성공적인 보내기/받기가 이루어지지 않는다면, 순서상 다음 슬레이브가 활성 슬레이브가 될 것이다.
만일 mii_monitor와 arp_interval 중 하나가 설정되지 않았다면, bonding 드라이버는 이러한 상황을 잘 처리하지 못할 것이다. 드라이버는 패킷을 계속 보낼 것이다. 하지만 어떤 패킷은 잃어버릴 것이다. 재전송은 심각한 성능의 저하를 가져온다(두 슬레이브중 하나가 fail되었을 때, 50% 패킷을 잃어버릴 것이다. 이것은 TCT와 UDP 모두 큰 문제이다).
6. bonding이 고 가용성을 위해서 사용될 수 있는가?
만일 MII 감시를 사용하고, 모든 카드가 MII 링크 상태 보고를 지원한다면, 가능하다. 더 자세한 정보는 고 가용성 부분을 참고하라.
7. 어떤 스위치/시스템과 함께 잘 작동하는가?
Round-robin과 XOR 모드에서, trunking을 지원하는 시스템과 잘 동작한다.
* Cisco 5500 시리즈 (EtherChannel 지원을 참조하라).
* SunTrunking 소프트웨어
* Alteon AceDirector 스위치 / WebOS (Trunks 사용).
* BayStack 스위치 (trunks 분명하게 설정되어야 한다). 스택 가능한 모델(450)은 다른 물리적 단위에서 포트 사이의 trunks를 정의할 수 있다.)
* Linux bonding
active-backup 모드에서, 어떤 L2 스위치와 잘 작동한다.
8. bonding 장치는 어디서 MAC 주소를 가져오는가?
만일 ifconfig를 사용하여 명백하게 설정하지 않는다면, bonding 디바이스의 MAC 주소는 첫 번째 슬레이브 디바이스로부터 가져온다. MAC 주소는 bonding 디바이스가 다운되거나 재설정될 때까지 다른 모든 슬레이브에 전달되고, 고정된다(첫 번째 슬레이브가 제거된다고 하더라도)
만일 MAC 주소를 변경하려면 ifconfig를 사용하여 설정할 수 있다.
# ifconfig bond0 hw ether
MAC 주소는 디바이스를 내리고 올리거나, 슬레이브(또는 슬레이브의 순서)를 변경하여 변경될 수 있다.
# ifconfig bond0 down ; modprobe -r bonding
# ifconfig bond0 .... up
# ifenslave bond0 eth...
이러한 방법은 추가될 다음 슬레이브로부터 주소를 자동으로 가져올 것이다.
슬레이브 MAC 주소를 되돌려놓으려면, bond로부터 슬레이브 디바이스를 떼어내고(‘ifenslaver –d bond0 eth0’), 정지시키고(‘ifconfig eth0 down’), 드라이버를 내리고(예를 들어 ‘rmmod 3c59x’), eeprom으로부터 MAC 주소를 다시 읽어와야 한다. 만일 드라이버가 여러 개의 디바이스에 의해서 공유되고 있다면, 그 모든 디바이스를 다운시켜야 한다. 또다른 해결책은 부팅시에 MAC 주소를 살펴보고(dmesg 또는 tail /var/log/messages), ifconfig를 사용하여 수동으로 설정한다
# ifconfig eth0 down
# ifconfig eth0 hw ether 00:20:40:60:80:A0
9. 어떤 전송정책이 사용될 수 있는가?
슬레이브의 순서에 기초한 round-robin, 출력 디바이스는 다음 사용 가능한 슬레이브에 따라서 선택된다. 패킷의 출발지와 목적지와는 상관없다.
주어진 시간에 하나 또는 꼭 하나만의 디바이스가 전송하는 것을 보장하는 Active-backup 정책. Active-backup 정책은 두 개의 허브를 사용하여 고 가용성 솔루션을 구축하는데 유용하다.(고 가용성 부분을 참고하라).
% 슬레이브 개수에 기초한(src hw addr XOR dst hw addr) XOR. 이 정책은 각 목적지 hw 주소에 대해서 동일한 슬레이브를 선택한다.
Broadcast 정책은 모든 슬레이브 인터페이스에서 모든 것을 전송한다.
고 가용성(High Availability)
====================
bonding 드라이버를 사용하여 고 가용성을 구현하기 위해서, 드라이버는 모듈로 컴파일 되어야 한다. 그것은 현재 드라이버에 파라미터를 전송하는 유일한 방법이기 때문이다. 이것은 이후에 변경될 것이다.
고 가용성은 MII 또는 ETHTOOL 상태 보고를 사용하여 구축된다. 당신은 당신의 모든 인터페이스가 MII 또는 ETHTOOL 링크 상태 보고를 지원하는지 검증해야 할 필요가 있다. 리눅스 커널 2.2.17에서, 모든 100Mbps 드라이버와 yellowfin 기가빗 드라이버는 MII을 지원한다. ETHTOOL 링크 보고가 eth0 인터페이스에 대해 가능한지를 결정하기 위해서 “ethtool eth0”를 입력하고 “Link detected:” 라인이 올바른 링크 상태를 나타내야 한다. 만일 당신의 시스템이 MII 또는 ETHTOOL 상태 보고를 지원하지 않는 인터페이스를 가지고 있다면, 링크의 failure는 감지되지 않을 것이다. 네트워크 드라이버가 MII와 ETHTOOL을 지원하지 않는다는 메시지는 bonding 드라이버가 miimon 값에 0이 아닌 값을 가지고 로드될 때 기록된다.
Bonding 드라이버는 ETHTOOL IOCTL(ETHTOOL_GLINK 명령어)을 사용하거나 또는 MII 상태 레지스터를 검사하여 모든 슬레이브의 링크를 정기적으로 검사할 수 있다. 검사 간격은 모듈 인수 “miimon”(MII 감시)를 사용하여 설정할 수 있다. 그것은 밀리초 단위로 검사하는 시간을 표현하는 정수값을 갖는다. 그 값은 1000/HZ에 가까우면 안 되는데 그것은 시스템 상호성을 감소시키기 때문이다. 100정도 값이 좋은 시작점으로 생각된다. 이것은 디바이스가 다운된 후 적어도 100 밀리초에 죽은 링크를 감지할 수 있다는 것을 의미한다.
예제:
# modprobe bonding miimon=100
또는 /etc/modules.conf에 다음 라인을 추가하라
alias bond0 bonding
options bond0 miimon=100
현재 고 가용성을 위해 2가지 정책이 있다. 그것은 아래조건에 의해 결정된다.
a) 호스트가 단일 호스트 또는 trunking을 지원하는 스위치에 연결되어 있는지
b) 호스트가 여러 개의 다른 스위치나 trunking을 지원하지 않는 단일 스위치에 연결되어 있는지
1) 단일 호스트 또는 단일 스위치에서의 고 가용성 – 부하 분산
----------------------------------------------------------------
이것은 가장 이해하기도 쉽고 설치하기도 쉽다. 단순히 여러 포트(Trunk, EtherChannel 등)의 트래픽을 모으기 위해서 외부 장치(호스트나 스위치)를 설정하라. 그리고 bonding 인터페이스를 설정하라. 만일 모듈이 적절한 MII 옵션을 사용하여 올라갔다면, 자동적으로 잘 동작할 것이다. 그리고 나서 다른 링크를 복구하거나 삭제하려 할 수 있다. 그리고 드라이버가 무엇을 감지하였는지 로그를 살펴보아라. 테스트할 때, trunk의 모든 포트가 다운된다면 오랫동안 trunk를 사용 불가능한 스위치에서 문제가 발생할 수 있다. 리눅스가 아니고, 스위치이다.
예제 1: 2배의 속도로 호스트에서 호스트
+----------+ +----------+
| |eth0 eth0| |
| Host A +---------------+ Host B |
| +---------------+ |
| |eth1 eth1| |
+----------+ +----------+
각 호스트에서:
# modprobe bonding miimon=100
# ifconfig bond0 addr
# ifenslave bond0 eth0 eth1
예제 2: 2배의 속도로 호스트에서 스위치
+----------+ +----------+
| |eth0 port1| |
| Host A +---------------+ switch |
| +---------------+ |
| |eth1 port2| |
+----------+ +----------+
호스트 A에서 : 스위치에서 :
# modprobe bonding miimon=100 # set up a trunk on port1
# ifconfig bond0 addr and port2
# ifenslave bond0 eth0 eth1
2) 2개 이상의 스위치(또는 trunking을 지원하지 않는 단일 스위치)에서 고 가용성
------------------------------------------------------------
이 모드는 문제가 더 많다. 왜냐하면 이것은 여러 개의 포트가 있고 호스트의 MAC 주소는 스위치가 혼동하지 않도록 하나의 포트만 볼 수 있어야 한다는 사실 때문이다.
만일 인터페이스가 활성화된 것과 어떤 것이 백업인지를 알아야 할 필요가 있다면, ifconfig 를 사용하라, 모든 백업 인터페이스는 NOARP 플래그를 갖는다.
이 모드를 사용하기 위해서는 로딩할 때 모듈에 “mode=1”을 보내라:
# modprobe bonding miimon=100 mode=1
또는 /etc/modules.conf 에 다음을 추가하라:
alias bond0 bonding
options bond0 miimon=100 mode=1
예제 1: “단일 실패 지점”을 없애기 위해서 여러 개의 호스트와 여러 개의 스위치를 사용하라.
| |
|port3 port3|
+-----+----+ +-----+----+
| |port7 ISL port7| |
| switch A +---------------+ witch B |
| +---------------+ |
| |port8 port8| |
+----++----+ +-----++---+
port2||port1 port1||port2
|| +------+ ||
|+---------+ host1 +---------+|
| eth0 +------+ eth1 |
| |
| +------+ |
+----------+ host2 +----------+
eth0 +------+ eth1
이런 설정에는 ISL이 있다. - Inter Switch Link(trunk가 될 수 있다), 양 스위치에 붙은 여러 개의 서버(host1, host2 …)와 외부와 연결하는 하나 이상의 포트(port3). 모든 링크는 계속 감시되지만, 각 호스트에 단지 하나의 슬레이브만 활성화된다.(시스템은 실패와 백업 링크를 감지한다)
호스트가 자신의 활성 인터페이스를 변경할 때마다, 인터페이스가 다운될 때까지 새로운 것을 고수할 것이다. 예를 들면, 호스트는 스위치의 전송 테이블의 만료시간에 의한 영향을 거의 받지 않는다.
만일 host1과 host2가 동일한 기능을 갖고 있고, 또 다른 외부 서버에 의해 부하분산에 사용되고 있다면, 호스트1의 활성 인터페이스가 하나의 스위치에 연결되고 호스트2의 활성 인터페이스는 다른 스위치에 연결되는 것이 좋다. 그러한 시스템은 단일 호스트, 케이블 또는 스위치의 failure에도 살아남을 것이다. 스위치 failure의 경우에 일어날 수 있는 가장 안 좋은 일은 다른 스위치가 자신의 테이블을 만료할 때까지 호스트중 1/2은 잠시 동안 연결이 불가능하다는 것이다.
예제 2: NIC failover를 설정하기 위해 스위치(trunking을 지원할 필요는 없다)에 여러 개의 이더넷 카드를 연결하는 것
+----------+ +----------+
| |eth0 port1| |
| Host A +---------------+ switch |
| +---------------+ |
| |eth1 port2| |
+----------+ +----------+
호스트 A에서 : 스위치에서:
# modprobe bonding miimon=100 mode=1 # (optional) minimize the time
# ifconfig bond0 addr # for table expiration
# ifenslave bond0 eth0 eth1
호스트가 자신의 활성 인터페이스를 변경할 때마다, 호스트는 자신이 다운될 때까지 새로운 것을 고수한다. 예제에서 호스트는 스위치 전송 테이블의 만료 시간에 많은 영향을 받는다.
3) Adapting to your switches' timing
------------------------------------
만일 스위치가 백업 모드로 전환하는데 오랜 시간이 걸린다면 링크가 다운된 후에 즉시 백업 인터페이스를 활성화시키는 것은 바람직하지 않을 것이다. 링크가 모듈 파라미터 “downdelay”(밀리초 단위이며 miimon의 배수이어야 한다)를 받아서 완전하게 사용 불가능하게 되는 순간만큼 시간을 지체하도록 하는 것은 가능하다.
스위치를 리부팅할 때, 스위치의 포트가 사용가능하기 전에 “link up” 상태를 보고하는 것이 가능하다. 이것은 아직 준비가 되지 않은 포트를 사용하도록 함으로써 bond 디바이스를 속일 수 있다. 활성 링크가 모듈 파라미터 “updelay”(밀리초 단위이며, miimon의 배수이어야 한다)를 받아서 재사용할 수 있는 순간을 지체하도록 할 수 있다.
유사한 사항이 호스트가 스위치와 끊어진 링크를 재 연결할 때(케이블 교체의 경우) 발생할 수 있다.
특별한 경우는 bonding 인터페이스가 모든 슬레이브 링크를 잃은 경우이다. 드라이버는 updelay 파라미터가 설정되어 있음에도, up되는 첫 번째 링크를 즉시 재사용할 것이다. (만일 “updelay” 상태의 슬레이브 인터페이스가 있다면, 첫 번째로 그 상태로 변경되는 인터페이스가 즉시 재사용될 것이다) 이것은 updelay 값이 과대평가되었다면, 다운타임(down-time)을 줄일 수 있다.
예제 :
# modprobe bonding miimon=100 mode=1 downdelay=2000 updelay=5000
# modprobe bonding miimon=100 mode=0 downdelay=0 updelay=5000
Promiscuous Sniffing notes
==========================
만일 네트워크 스니핑(network sniffing) 을 위해 bond 채널을 함께 사용하기를 원한다면 – tcpdump 또는 ethereal, 또는 bonding 드라이버를 사용하여 여러 개의 인터페이스로부터 수집한 입력을 사용한 snort 같은 IDS를 실행하기를 원한다면 – 수동으로 Promiscuous 인터페이스 설치를 처리해야 한다. 특히 “ifconfig bond0 up” 을 했을 때, 반드시 promisc 플래그를 추가해야 한다. 이것은 ifenslave 시간에 슬레이브 인터페이스에 전달(propagate down)할 것이다. 완전한 예제는 다음과 같다:
grep bond0 /etc/modules.conf || echo alias bond0 bonding >/etc/modules.conf
ifconfig bond0 promisc up
for if in eth1 eth2 ...;do
ifconfig $if up
ifenslave bond0 $if
done
snort ... -i bond0 ...
또한 Ifenslave 는 채널 용량 집합과 HA에서 설계 기능을 위하여 적절하게 인터페이스에서 인터페이스로 주소를 전달하기를 원한다. 하지만, 이것은 모든 경고를 무시하고 unnumbered 인터페이스에서도 잘 동작한다.
제약
===========
주된 제약 사항은:
- 단지 링크 상태가 감시된다. 만일 다른 편에 있는 스위치가 부분적으로 다운되었다면(즉, 전송을 더 이상하지 않지만, 링크는 정상인 경우), 링크는 사용가능하지 않다. 죽은 링크를 검사하는 또 다른 방법은 많은 부하가 걸린 호스트에서 들어오는 프레임의 개수를 세도록 하는 것이다. 이것은 작은 서버에서는 적절하지 않다. 하지만 전방 스위치가 링크(즉 VRRP) 또는 서버 health-check 에 멀티캐스트 정보를 보낼 때 유용할 것이다. 들어오고 나가는 프레임을 계산하기 위해서는 arp_interval/arp_ip_target 파라미터를 사용하라
- 전송 부한 분산 정책은 현재 가능하지 않다. 이 모드는 bond내 모든 슬레이브가 단지 하나만 받을 동안 전송할 수 있도록 한다. 만일 ‘받는’ 슬레이브가 fail된다면 다른 슬레이브가 fail된 받는 슬레이브의 MAC 주소를 받는다.
Resources and Links
===================
Current development on this driver is posted to:
- http://www.sourceforge.net/projects/bonding/
Donald Becker's Ethernet Drivers and diag programs may be found at :
- http://www.scyld.com/network/
You will also find a lot of information regarding Ethernet, NWay, MII, etc. at
www.scyld.com.
For new versions of the driver, patches for older kernels and the updated
userspace tools, take a look at Willy Tarreau's site :
- http://wtarreau.free.fr/pub/bonding/
- http://www-miaif.lip6.fr/willy/pub/bonding/
To get latest informations about Linux Kernel development, please consult
the Linux Kernel Mailing List Archives at :
http://boudicca.tux.org/hypermail/linux-kernel/latest/
-- END --
'OS > LINUX' 카테고리의 다른 글
| [LINUX] rpmbuild (0) | 2008.02.11 |
|---|---|
| yum (0) | 2008.02.11 |
| iptables 추가 (0) | 2007.11.21 |
| iptables (0) | 2007.11.21 |
| 리눅스 ＆ 유닉스에서 화일 갯수 세기 (0) | 2007.10.29 |
