Load Balancing 설정에 관하여...
http://wiki.kldp.org/wiki.php/Adv-Routing-HOWTO 를 참고하여
부하분산이라는 것을 테스트해보려고 VMware상에서 eth0와 eth1을
NAT로 아래와 같이 구성하였습니다.
eth0, eth1, gw는 동일한 subnet이며,
eth0 192.168.0.2/24
eth1 192.168.0.3/24
gw 192.168.0.1/24 로 설정하였습니다.
ip route와 ip rule은 아래와 같이 설정하였구요..
[root@localhost root]# cat /etc/iproute2/rt_tables
#
# reserved values
#
#255 local
#254 main
#253 default
#0 unspec
#
# local
#
#1 inr.ruhep
200 T1
201 T2
[root@localhost root]#
[root@localhost root]# ip rule add from 192.168.0.2 table T1
[root@localhost root]# ip rule add from 192.168.0.3 table T2
[root@localhost root]# ip rule ls
0: from all lookup local
32764: from 192.168.0.3 lookup T2
32765: from 192.168.0.2 lookup T1
32766: from all lookup main
32767: from all lookup 253
[root@localhost root]#
[root@localhost root]# ip route add 192.168.0.0 dev eth0 src 192.168.0.2 table T1
[root@localhost root]# ip route add default via 192.168.0.1 table T1
[root@localhost root]# ip route add 192.168.0.0 dev eth1 src 192.168.0.3 table T2
[root@localhost root]# ip route add default via 192.168.0.1 table T2
[root@localhost root]#
[root@localhost root]# ip route add 192.168.0.0 dev eth0 src 192.168.0.2
[root@localhost root]# ip route add 192.168.0.0 dev eth1 src 192.168.0.3
RTNETLINK answers: File exists
[root@localhost root]#
[root@localhost root]# ip route add default scope global nexthop via 192.168.0.1 dev eth0 weight 1 nexthop via 192.168.0.1 dev eth1 weight 1
[root@localhost root]# ip route flush cache
[root@localhost root]# ip rule add from 192.168.0.2 table T1
[root@localhost root]# ip rule add from 192.168.0.3 table T2
[root@localhost root]#
[root@localhost root]# ip route ls
192.168.0.0 dev eth0 scope link src 192.168.0.2
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.3
127.0.0.0/8 dev lo scope link
default
nexthop via 192.168.0.1 dev eth0 weight 1
nexthop via 192.168.0.1 dev eth1 weight 1
[root@localhost root]#
이렇게 구성한후 외부 FTP로 put과 get을 해보니, eth0로는 TX, eth1으로는 RX 패킷의
카운트만 증가합니다. 이게 제대로 동작을 하는것인지에 대해 미리 설정해본 사람들의
얘기가 궁금하여 구글서 며칠째 찾아봐도 찾을수가 없더군요..
그래서 이게 맞는건지..아닌지가 궁금하여,
VMware의 NIC을 bridged모드로 하여 똑같이 setting하였더니
이제는 하나의 NIC의 packet 카운트만 증가하더군요..
그래서 또 하나의 뻘짓을 시도했습니다.
노트북에 PCMCIA랜카드를 추가하여 두개의 랜카드를 위와 같은 구성도에 맞추어
그리고 위 설정에 맞추어 세팅을 하고 같은 방법으로 테스트를 하였더니
한개의 NIC으로만 통신을 하더군요. 그 와중에 통신하던 랜선을 뽑았더니.
음..아예..다른 NIC의 ip로도 ping이 안가네요..분명 허브에 link불은 들어와있는데.
혹시 저와 같은 뻘짓을 미리 해보시고 어떤 소기의 목적을 달성하신 분이 있으시다면
살포시 댓글이라도 달아주시면 감사하겠습니다.
참고한 문서는 mulit ISP업체일 경우였는데, 모 별반 차이있겠냐는 짧은 생각으로
이렇게 작업해봤는데..제가 잘못 설정한건지..아 참 깝깝하네요..
그럼 수고하세요~
아 참고로 NAT는 RedHat 7.3, Bridged는 Fedora Core2, 노트북은 RedHat 9로
테스트했습니다..쩝..
이런저런
이런저런 잡담입니다.
1. FTP로 테스트를 했을 때 왜 한쪽 인터페이스로만 통신이 이뤄졌을까요?
기대하셨던 것이 각각 다른 주소를 가진 두 인터페이스에 반반씩 나눠서 FTP 데이터가 오가는 것이었다면 그건 불가능합니다. 한 FTP 세션의 FTP 데이터는 하나의 TCP 세션을 통해서 전송되며, 각 TCP 세션은 통신에 참여하는 양단의 IP 주소와 포트 번호로 구분되기 때문입니다. 즉 FTP 연결을 하나 맺으면 그건 192.168.0.2 주소를 이용하거나 192.168.0.3 주소를 이용하지 두 주소를 동시에 이용하지는 못합니다.
그렇다면 여러 개의 FTP 연결을 만들면 각각의 세션이 두 인터페이스를 교대로 이용하면서 생성되기 때문에 부하가 분산될까요? 그럴 수도 있고 아닐 수도 있습니다. 말씀하신 위키 문서의 4.2.2절에서 언급한 것처럼 라우팅 캐시 때문에 짧은 간격으로 만드는 세션은 동일한 인터페이스를 통해 생성될 수 있기 때문입니다. 즉 Adv-Routing HOWTO 문서에서 언급된 방법은 다음 조건이 만족되는 경우에만 유용합니다.
2. 왜 들어오는 트래픽이... 예상과 달리 동작했을까요?
eth0로 나간 세션의 트래픽이 eth1으로만 들어오는 현상과 eth0 링크를 뽑았더니 eth1으로도 ping이 안 가는 현상은 서로 관련이 있습니다.
자... eth0와 eth1은 동일한 서브넷에 속하며 같은 네트워크 세그먼트에 연결되어 있습니다. eth0을 통해서 어떤 패킷이 나갔고 그에 대한 응답이 지금 돌아오는 중입니다. 패킷은 장비의 바로 앞에 있는 라우터까지 도착했고, 라우터는 응답 패킷의 목적지 IP 주소를 가지고 어떤 장비(혹은 인터페이스)로 패킷을 보낼지 결정해야 합니다. 192.168.0.2 주소에 대한 ARP 요청을 날릴 것이고, 네트워크 구성이나 두 네트워크 인터페이스에서의 인터럽트 우선순위 등에 따라서 eth0과 eth1 중 하나의 인터페이스가 그 요청을 먼저 듣게 됩니다. eth0가 가진 IP 주소에 대한 ARP 요청을 eth1가 먼저 들은 경우 장비는 eth0이 아닌 eth1의 하드웨어 주소를 가지고 ARP 응답을 보내 줍니다. 그러면 앞단의 라우터는 ARP 캐시에 {192.168.0.2(eth0의 IP주소) => eth1의 하드웨어주소} 항목을 추가하고 그에 따라 eth1의 하드웨어 주소로 응답 패킷을 보내게 됩니다. 그래서 eth0으로 나간 패킷에 대한 응답이 eth1으로만 들어오는 경우가 생기게 됩니다. 물론 라우터가 보낸 ARP 요청에 eth0가 먼저 응답했다면 eth0로 응답 패킷이 들어왔을 것이고, 그러면 eth0로만 패킷이 오가게 됩니다.
eth0만으로 통신이 이뤄지고 있을 때 라우터에서 192.168.0.3(eth1의 IP주소)으로 ping을 날리면 어떻게 될까요? 마찬가지로 라우터는 192.168.0.3 주소에 대한 ARP 요청을 날릴 것이고, 아마 이번에도 eth0이 그 패킷을 먼저 보고서 자신의 하드웨어 주소로 응답을 해 줄 겁니다. 그러면 라우터의 ARP 캐시에서는 192.168.0.2와 192.168.0.3 주소 둘 모두가 eth0의 하드웨어 주소로 사상되어 있게 됩니다. 이 상황에서 eth0에 연결된 LAN 케이블을 뽑은 후 라우터에서 192.168.0.3으로 ping을 날리면 (좀 전의 ARP 캐시 항목이 아직 지워지지 않았다고 하면) eth0의 하드웨어 주소로 ping 패킷이 날아갑니다. 네트워크 상에 그런 하드웨어는 이제 연결되어 있지 않고, 따라서 아무도 그 ping 패킷을 받지 못합니다.
이 현상은 근본적으로 "인터페이스 자신이 아닌 동일 장비의 다른 인터페이스가 가진 IP 주소에 대한 ARP 요청에 대신 응답하는 동작 방식" 때문입니다. /proc/sys/net/ipv4/conf/DEV/arp_filter (이 항목에 대한 설명은 아쉽게도 13. 커널 네트워크 매개변수 절에는 포함되어 있지 않습니다.) 파일(sysctl식으로는 net.ipv4.conf.DEV.arp_filter 항목)의 값을 1로 바꿔주시면 인터페이스 자신의 IP 주소가 아닌 다른 주소에 대한 ARP 요청을 무시하게 됩니다.
3. Multi ISP인 경우와 아닌 경우의 차이가 있을까요?
2번 항목의 경우 각각의 인터페이스가 다른 네트워크에 물려있는 경우에는 발생하지 않습니다. 즉 골치아픈 내용 하나를 무시할 수 있습니다.
4. 더 나은 부하 분산 방법은?
말씀하신 방법은 1번 항목에서 설명한 것처럼 얼마간의 제한이 있는 방식입니다. 그 방법 말고도 네트워크 부하 분산을 위한 방법이 몇 가지 더 있으리라 생각합니다만... 그건 어느 멋진 분이 나타나서 자세히 설명해 주시리라 믿습니다...;;
----
$PWD `date`
$PWD `date`
댓글 달기