리눅스 Bonding 드라이버의성능분석 (Performance Analysis of Ethernet Bonding Driver in Linux) 김재열, 강동재, 김수영, 차규일한국전자통신연구원시스템소프트웨어연구팀 {gauri, djkang, sykim, gicha}@etri.re.kr 요 약 최근의컴퓨터시스템은네트워크를제외하고는생각할수조차없을정도로네트워크에대한의존성이매우크다. 저렴한비용으로서버시스템에장착된다수의물리적인이더넷인터페이스를하나의논리적인이더넷인터페이스로만들어서버시스템의네트워크대역폭을넓히는방법이 Ethernet Link Aggregation( 이하 ELA 라고칭함 ) 이다. 본논문은공개소프트웨어중가장널리사용되고있는리눅스의최신커널 2.6 에서최근의서버시스템에서일반적으로사용하는기가비트이더넷인터페이스장치를통해 ELA 기능을제공하는리눅스 ethernet bonding 드라이버의 TCP 와 UDP 성능을측정하여이를평가하고분석하였다. Keywords : Ethernet Link Aggregation, ethernet bonding, trunking, Linux 1. 서론 최근멀티미디어스트리밍서버에서의대용량데이터전송이나유비쿼터스환경의센서네트워크에서와같은예측할수없는다수데이터의전송요구가증가함에따라서네트워크의성능 (high performance)[1] 및가용성 (high availability)[2] 에관련한많은연구들이진행되어왔다. 일반적인 2-Way 또는 4-Way 서버처럼다수의프로세서를내장하고있는시스템의경우, 네트워크처리에사용할수있는 CPU 의컴퓨팅자원이여유있음에도불구하고서버의물리적네트워크인터페이스의대역폭제약으로인하여네트워크성능이제한되는경우가발생한다. 이와같은경우서버시스템의네트워크대역폭확보는빠른네트워크전송이중요시되는시스템에서매우필수적인기능이다. 서버의물리적네트워크인터페이스의대역폭을증가시키는가장쉬운방법은더넓은대역폭을지원하는네트워크인터페이스카드와이를지원할수있는네트워크스위치등의인프라를갖추는것이다. 예를들면현재서버에서일반적으로사용하는기가비트이더넷을 10- 기가비 트 이더넷환경으로전환하는것이다. 하지만, 이러한방법은네트워크인프라를바꾸어야하기때문에상당한비용을지불해야한다. ELA 는이러한추가적인비용의지출없이현재의네트워크인프라를그대로이용해시스템의네트워크대역폭을증가시킬수있는방법으로매우유용하다. 다양한데이터의서비스를수행하는서버들의경우, 네트워크디바이스나기타회선의문제로인하여발생가능한최소한의네트워크가용성을보장하는것이요구된다. 일반적으로 ELA 에서는다수의물리적인네트워크인터페이스중일부가고장이나거나네트워크연결이끊기는경우나머지네트워크인터페이스만으로논리적네트워크인터페이스를구성해사용할수있도록하는기능도제공해네트워크가용성을향상시킬수있다. ELA 는여러개의물리적네트워크인터페이스들을하나의논리적네트워크인터페이스로가상화하는기술로서논리적네트워크인터페이스에대한전송처리요구를하부의여러물리적네트워크인터페이스들을통하여부하분산을수행함으로서네트워크의대역폭를증 67
가시킨다. 따라서, 서버에대한클라이언트의요청에대한응답시간을개선할수있으며네트워크인터페이스에대한대기시간을감소시킴으로써단위전송의빠른처리를제공한다. 또한, 여러개의물리적네트워크인터페이스들중의일부에발생하는고장에대하여응용프로그램들에게투명성을제공함으로써네트워크서비스의가용성을향상시킨다. 본논문에서는 ELA 의개발배경과 ELA 가사용되는경우의모델에대하여알아보고, 리눅스의 ELA 드라이버인리눅스 bonding 드라이버 [3] 에대하여살펴본다. 또한 TCP 및 UDP 를사용하는응용프로그램환경에서벤치마크실험을통하여리눅스 bonding 드라이버의성능평가및분석을수행하고이에대한결론과향후과제를도출한다. 2. Ethernet Link Aggregation 본장에서는먼저 ELA 의개발배경과 ELA 가사용되는환경에대해서간략히기술하고, 리눅스의 bonding 드라이버에대한구조및지원모드에대하여설명한다. 은 3 가지모델로정리가된다. [ 그림 1] 의첫번째모델은 ELA 가처음으로사용될때의일반적인모델로스위치와스위치간을연결한다. 그림 1. 스위치와스위치간 ELA 연결 [ 그림 1] 에서와같이초창기에는스위치와같은통신장비들사이의연결에만 ELA 기능이적용되었다. 하지만, 서버의네트워크기능이점차증가함에따라 [ 그림 2] 에서와같이서버와스위치간에도 EAL 가사용되었다. 물론이때사용되는스위치는 ELA 기능을지원하는스위치여야한다. 2.1 Ethernet Link Aggregation 의배경 최초의 ELA 기능은 trunking 이라는이름으로각네트워크장비업체들이독자적으로가지는특화된기술로서, 10/100Mbps 이더넷과 FDDI 환경에적용되어왔다. 예를들면네트워크장비업체중에는 CISCO 의 ISL(Inter-Switch Link trunking)[4] 과 Adaptec 의 Duralink port aggregation[5] 이대표적이며서버업체로는 Sun 의 Sun Trunking[6] 기술이있다. 그러나각업체들마다서로다른프로토콜들은타제조사들의제품에호환성을제공하지못하는이유로많은네트워크장비관리자들이장비통합에어려움을겪게되었다. 이런 trunking 기술의타제조사장비간비호환성을개선하기위해나온것이 IEEE802.3ad[7,8] 표준으로 1999 년에제정되었다. ELA 기술은초기에스위치나라우터등의네트워크장비들간의기간망연결에주로사용되었으나수년전부터서버시스템의네트워크대역폭의중요성이커지면서현재는서버와의연결지원도매우중요하다. ELA 를적용함에있어서는크게아래와같 그림 2. 서버와스위치간 ELA 연결 이러한구성과더불어최근에는서버와서버의네트워크연결에도 ELA 를적용할수있다. [ 그림 3] 은이러한연결을보여준다. [ 그림 3] 과같은경우는여러대의서버가동일한서비스를하는경우와같이근접한거리에서버들이모여있을때적용할수있다. 이기종으로이루어진 Beowulf cluster 에도이러한 ELA 를적용한사례 [9] 가있다. 그림 3. 서버와서버간 ELA 연결 68
2.2 리눅스 bonding 드라이버의구조 ELA 는물리적인다수의네트워크인터페이스들을하나의논리적인네트워크인터페이스로가상화하고, 논리적인네트워크인터페이스에대한데이터전송및수신요청을 bonding 에참여하는실제네트워크인터페이스 ( 이하 slave 로기재 ) 들에게다양한로드분산알고리즘에의하여처리를분산한다. 이러한다양한알고리즘에따른분류를모드라고하며, 각모드에관한설명은다음절에서기술하도록하며본절에서는 ELA 를위한리눅스 bonding 모듈의구조에대하여설명한다. [ 그림 4] 는 ethernet bonding 모듈의커널내에서의위치및간략한구조를보여주는그림이다. bonding 모듈은실제물리적인디바이스를운용하기위한드라이버의가상화를위한부분이므로시스템에서사용하는네트워크디바이스드라이버의상위에존재한다. round robin 과같은부분들은 bonding 모듈을통한전송요청시에데이터를어떠한기준으로하부 slave 들에게분배할것인지를결정하기위한정책들을구현한부분이며자세한내용은다음절에서설명하도록한다. bonding 모듈이커널에서사용되면, bonding 에참여하는모든 slave 들과논리적인 bonding 네트워크인터페이스는외부에공개되는동일한 IP 와 MAC 주소및설정을공유하게되어서통신상대가되는원격의노드와응용프로그램에게 bonding 에대한투명성을제공한다. 2.3 리눅스 bonding 드라이버의지원모드 본절에서는리눅스의 bonding 드라이버에서사용가능한모드에대하여살펴본다. 지원하는모드들의목적은고성능을위한 loadbalancing 부분과고가용성의보장을위한 fault tolerance 로구분할수있으며모드에따라서일부또는동시지원을하고있다. Balance-Round Robin Mode. 현재 bonding 을위하여 slave 로등록된 NIC(Network Interface Card) 의처음부터마지막까지순차적으로데이터를전송하는방식으로본모드에서는네트워크에대한전송부하를여러개의 slave 로분할하여전송함으로써 load balancing 을통한네트워크대역폭증가효과를얻을수있다. 또한 slave 로등록된일부 NIC 의고장시, 나머지 NIC 으로전송을수행함으로써네트워크가용성또한보장한다. 그림 4. Bonding 드라이버의구조와커널의관계 [ 그림 4] 에서의 link monitoring 부분은 bonding 에참여하는각 slave 의가용성을주기적으로점검하는부분으로써일부 slave 에대한고장이인식되면현재의 bonding 설정을변경한다. 본기능은디바이스드라이버의인터페이스에서 MII(Media Independent Interface) 나환경설정도구인 ethtool[10] 이제공하는경우에사용가능하다. 예를들면, 현재사용중인 slave 가고장으로인식되면 bonding 에참여하는가용한다른 slave 를현재사용을위한 slave 로재지정하는동작을수행하게된다. [ 그림 4] 에서 Active-Backup Mode. Bonding 을위하여등록된 slave 중오직하나의 NIC 만이 active 상태이며나머지는 backup 을위하여 inactive 상태로존재한다. 현재 active 상태인 NIC 에고장이발생하는경우, backup 을위하여등록된나머지 NIC 중에서하나가 active 로상태전이를하게됨으로써끊임없는데이터전송처리를수행할수있도록하는모드이다. 고장이발생한 NIC 에대한 backup 시에는동일한서비스 port 에대하여동일한 MAC 어드레스가외부에공개됨으로써어플리케이션들에대한고장상태의투명성을제공한다. 이모드에서는대역폭의증가효과는없으며네트워크의고가용성만을보장한다. 69
Balance-XOR Mode. 데이터전송시에 [destination MAC address x source MAC address % slave count] 의연산에근거하여사용할 slave 를선택하는모드이다. 따라서, 동일한목적지에대한데이터전송인경우, 동일한 slave 를통하여수행된다. 본모드에서도, Balance-Round Robin 모드와동일하게 load balancing 과 fault tolerance 기능을동시에지원한다. Broadcast Mode. slave 로등록된모든 NIC 에대하여데이터전송을중복처리하는모드이다. 동일한데이터에대하여 slave 로등록된 NIC 에대하여중복전송을수행하므로처리부하가크다. 따라서, 단일 NIC 의사용시보다성능은감소하지만 slave 로등록된모든 NIC 에고장이발생하지않는한네트워크전송은수행되어우수한 fault tolerance 를보장한다. 802.3ad Mode. 본모드에서는 slave 들을동일한속도와양방향통신의설정을공유하는 aggregation group 으로통합하며 active aggregator 에소속된모든 slave 를통하여송수신을수행하는모드이다. Balance-TLB(Adaptive Transmit Load Balancing). 데이터의송신은현재 slave 로등록된각 NIC 에대한 load 상태의계산에의하여분산되며데이터의수신은현재사용중인 slave 에의하여처리되므로수신에대한 load balancing 은지원하지않는다. 수신을위한 slave 에고장이발생하는경우, 다른 slave 가고장이발생한 slave 의 MAC 주소를인계받아서처리를수행한다. Balance-ALB(Adaptive Load Balancing). 상기 Balance-TLB 모드의수행방식에수신을위한 load balancing 기능이추가된모드이며수신을위한 load balancing 은 ARP 협상에의하여수행된다. 서버에의하여발생된 ARP 응답메시지를 bonding 모듈이 hooking 하여 ARP 응답메시지에존재하는발신측의하드웨어주소를 bonding 에참여하는임의 slave 의유일한하드웨어주소로덮어쓰기연산을수행함으로써 bonding 에참여하는모든 slave 는각자다른하드웨어주소를사용하게된다. 따라서, 수신시에각자해당하는데이터패킷을수신함 으로써수신을위한 load balancing 기능을제공한다. 시스템관리자는시스템의환경에따라서상기모드들의 ELA 중적절한것을선택해야한다. 일반적으로간단한환경에서는처리방식이단순한 balance round-robin 의경우가좋은성능을나타낼수있다. 3. 성능분석및평가 3.1 실험환경 리눅스커널 2.6 에포함되어있는 ELA 의성능을테스트하기위해아래와같은환경에서실험을하였다. 실험에는리눅스 bonding 드라이버의여러모드중일반적으로가장성능이좋은 balance round-robin 모드를사용하였다. 실험에사용된장비는서버와스위치로이루어지며, 서버는모두동일한사양을가지고있다. 서버에는 Intel Xeon 3.0GHz 의 CPU 가 2 개씩장착되어있으며, 메모리는각각 1GB 가장착되어있다. 실험에사용된네트워크카드는서버보드에내장되어있는인텔의 e1000 기가비트이더넷포트 2 개를사용하였다. 서버에사용된커널은리눅스커널 2.6.10 이다. 스위치는 3com 의 3c17700 기가비트스위치를사용하였으며네트워크성능을측정하는 benchmark tool 로는널리알려진 SGI 의 netperf 2.1 을사용하였다. netperf 는테스트시간을지정할수있으며, 이를 30 초로지정해모든실험을진행하였다. TCP 실험에서는대부분 netperf 의 default 설정을이용하여실험하였으며몇몇옵션을지정해실험한경우도있었으나결과값이크게다른경우가없어본논문에서따로결과를보여주지는않는다. 아래는본실험에사용된 netperf 의 tcp 테스트옵션이다. netperf l 30 H 192.168.1.1 UDP 실험에서는소켓버퍼의크기와 message 의크기를 16060 byte 로지정하여테스트하였다. 아래는본실험에사용된 netperf 의 udp 테스트옵션이다. netperf l 30 t UDP_STREAM H 192.168.1.1 -- -s 16060 m 16060 70
3.2 실험 A (2G bonding - Switch 2G bonding) 실험 A 는 [ 그림 5] 와같은환경에서수행되었다. 이실험의목적은 ELA 의기능과성능을측정하는것을목적으로수행되었다. 그림 5. 실험 A [ 그림 5] 에서보듯이첫번째실험은두서버의양단을 mode-0(round-robin) 으로 bonding 시킨상태에서스위치에연결하여측정하였다. 리눅스의 bonding 이제공하는 mode-0 에서 mode-6 까지의 7 개의 mode 중 mode-0(roundrobin) 를선택하여실험한이유는 [ 그림 5] 와같은가장기본적인네트워크환경에서 link aggregation 기능을제공해최대의성능을낼수있는 mode 가 round-robin 이기때문이다. 실험은 TCP 와 UDP 모두에대하여수행하였으며프로세스의개수에따른성능상의차이점을알아보기위해테스트프로세스 (connection) 개수를 1, 5, 10, 20 로바꾸어가면서테스트하였으며 bonding 을하지않았을때의성능을비교해보기위해단일이더넷카드 (1-NIC) 의경우에도실험을수행하였다. [ 표 1] 실험 A 의결과 ( 단위 : Mbps) TCP UDP Stream 1-nic Bond(r-r) 1- nic Bond (r-r) 1 941.1 941.04 960 1918.59 5 942.22 970.45 - - 10 939.65 941.99 - - 20 935.17 982.12 - - [ 표 1] 의결과를살펴보면먼저, 1-NIC 의경우에는기가비트카드의최대성능인 1Gbps 에근접하게나왔으며 TCP 나 UDP 가큰차이가없음을알수있다. 약간의성능상의차이점은 TCP 가 UDP 보다 connection based 방식으로운 용되기때문에생기는부하때문이라고추정된다. Bonding 을한서버간의테스트결과를살펴보면 TCP 의경우에는 2 개의 link 를 aggregation 했음에도불구하고 1Gbps 를넘지못한결과를보여주고있으며, UDP 의경우에는 2Gbps 에가까운좋은성능을보여주었다. UDP 의경우에는 1-NIC 경우의결과를표시하고다수프로세스의결과는기록하지않았다. netperf 는자체적으로다수의 process 를수행해네트워크 bandwidth 를측정하는기능은제공해주지않기때문에본실험에서다수의프로세스가네트워크를이용한결과를측정할때는복수의 netperf 프로그램을수행시키는스크립트를작성하여사용하였다. 그러나이런방식을사용함으로써생기는문제는 process 를의도대로항상동시에수행시키지못할수있다는것이다. TCP 의경우에는대부분다수의프로세스가동시에수행되었으나 UDP 의경우에는각프로세스사이의간격이 TCP 에비해매우커서결과값을신뢰할수없었다. 또한하나이상의 UDP 대역폭실험이큰의미를갖지않는이유는결과에서볼수있듯이단일프로세스실험에서도 1900Mbps 이상의성능을보여주어물리적인한계인 2Gbps 에가깝게사용하고있음을알수있기때문이기도하다. 결과적으로 UDP 의경우는프로토콜의특성상단일연결에서도최대의네트워크성능을측정하기에충분함을알수있다. 위실험 A 에서 TCP 의경우성능이기대했던것과는달리 1Gbps 를넘지않았다. 이런성능상의문제가리눅스의 bonding 드라이버자체의문제인지, 주위의네트워크환경이나 bonding 을수행하는서버의처리능력이부족한것인지를확인하기위해실험 B 를수행하였다. 3.3 실험 B (200M bonding Switch 1G) 실험 A 에서 TCP 성능에 bonding 효과가전혀나타나지않은이유를찾기위하여실험 B 에서는 send 를하는서버의주위네트워크환경이충분히넓은대역폭을제공해줄수있도록송신서버에기가비트카드가아닌 100Mbps 이더넷카드 2 장을설치해이를 bonding 으로묶어테스트를진행하였다. [ 그림 6] 은실험 B 의실험환경을보여준다. 71
그림 6. 실험 B [ 표 2] 는실험 B 의실험결과를보여준다. 실험 B 의결과를살펴보면 UDP 의경우에는 192Mbps 로실험 A 의결과처럼 bonding 된네트워크대역폭을충분히활용하고있으며 TCP 의경우에도 188Mbps 라는좋은대역폭을보여주었다. [ 표 2] 실험 B 결과 ( 단위 : Mbps) TCP UDP Stream 1 NIC Bond (r-r) 1 NIC Bond (r-r) 1 94.13 145.12 96.13 192.12 5 94.22 188.34 - - 10 94.35 188.91 - - 20 94.27 188.45 - - 이러한결과에서추정해볼수있는것은 bonding 드라이버가하위의이더넷인터페이스카드의 scalability 를제대로지원해주지못하는것은아니라고추정할수있으며따라서실험 A 에서 TCP 의성능이잘나오지않은이유는송신호스트의 processing 능력이 2Gbps 의네트워크부하를제대로처리하지못하거나원격호스트의수신처리능력이떨어진다고볼수있다. 일반적으로 TCP/IP 네트워크처리에드는 CPU 부하는 1bps 처리에 1hz 정도가소요된다고알려져있으며실험에사용한서버의 CPU 는 Intel Xeon 3.0Ghz 두개를사용한 SMP 시스템으로 2Ghz 의네트워크부하를처리하는데는무리가없을것으로판단되므로실험 A 에서 TCP 의성능이제대로나오지않은것은수신측의 bandwidth 가충분하지않기때문일것으로추정할수있다. 이와같은추정을확인하기위해수신측의 bandwidth 를충분히확보한실험 C 를수행하였다. 3.4 실험 C (2G bonding Switch 1G x 2) 실험 C 는수신측의대역폭을충분히확보하기위해 netperf test 의수신측서버를한대의호스트가아닌두대의호스트에서처리하도록 [ 그림 7] 와같은환경하에서수행하였다. 실험 C 시험환경의특징은 netperf client 의데이터를받는 netserver 를두대의호스트에서수행함으로써 netserver 의수신대역폭을보장할수있는것이다. netperf client 는서로다른두개의 netserver 로각각데이터를보내 client 의최대대역폭을확인할수있다. 이전의실험에서 TCP 의최대대역폭을측정하는데 10 개이상의 process 이면충분하다는것을확인할수있었으므로실험 C 에서는 TCP 와 UDP 모두각 netserver 로 5 개의요청을보내, 총 10 개의 process 를수행하는것으로실험을하였다. 그림 7. 실험 C [ 표 3] 은실험 C 의결과를보여준다. 실험 C 의결과를보면실험 A 와는달리 TCP 의경우에도 1800Mbps 에가까운만족할만한성능을보이고있다. 이는실험 A 에서의 TCP 테스트의성능이제대로나오지않은이유가수신측의 bandwidth 가충분하지않았기때문이라고할수있다. UDP 테스트결과는실험 A 에서와마찬가지로충분한성능을보이고있다. 이의실험결과를바탕으로실험에사용된리눅스커널의 bonding 드라이버는 send 시에충분한 bandwidth 를제공하고있다고판단할수있다. [ 표 3] 실험 C 결과 ( 단위 : Mbps) TCP(5+5) UDP(5+5) # Bond(r-r) Bond(r-r) 1 1789.17 1924.77 2 1778.56 1935.21 3 1790.16 1922.15 4 1785.35 1900.37 72
그렇다면문제가되는것은실험 A 의 bonding 시스템에서 receive 대역폭이확보되지않았다는점이며이를테스트하기위하여실험 D 를수행하였다. 3.5 실험 D (2G bonding 2G bonding) 리눅스 bonding 드라이버의 send 시의성능은실험 C 에서검증되었으므로이제 bonding 드라이버가 receive 시에얼마만큼의대역폭을처리할수있는지를테스트하기위해 [ 그림 8] 과같이각각 bonding 한호스트를크로스케이블을사용해스위치를거치지않고직접연결하였다. 이렇게하면실험 C 에서검증된 bonding 드라이버의 TCP send 성능이 1.8Gbps 의속도를낼수있을것이므로이실험의결과치가 1.8Gbps 이하로나온다면이를 bonding 드라이버의 receive 성능이라고볼수있을것이다. 그림 8. 실험 D 이러한구성이가능한이유는 mode-0, roundrobin 으로 bonding 을구성한경우에 send 측에서는각패킷마다 round-robin 방식으로하위의다수의 slave 로번갈아가면서보내기때문에두대의호스트를직접연결한경우에는스위치의도움을받지않고 receive 측에서는차례대로 packet 을받을수있기때문이다. TCP 의경우각 connection 을갖는 process 를 5 개, 10 개씩을사용하여실험한결과를보여준다. 10 개이상이되었을때는프로세스개수가최대 bandwidth 측정에영향을주지않아 10 개까지만테스트하였으며, UDP 의경우에는실험 1 에서언급한것과같이하나의 process 에서최대 bandwidth 를낼수있으므로 process 개수는 1 개일경우만실험하였다. 앞의실험에서언급하지않은 netperf 의결과중하나는 UDP 성능측정의경우 netperf 는 send 시의성능과 receive 의성능을함께측정해준다. 예를들면 [ 그림 9] 은 netperf UDP 테스트의출력결과의한예를보여준다. 그림 9. netperf 의 UDP 시험결과예 [ 그림 9] 에서테스트의결과는 send 시와 receive 시의두개가출력된다. UDP 는 TCP 와는달리수신측에서송신한데이터를제대로받았는지, 그렇지않은지를알수도없으며상관하지않는다. 그래서 UDP 테스트의경우에는 send 측에서보낸 UDP 데이터를 receive 측에서에러없이잘받았는지를나타내는 receive 성능을함께보여준다. 실험 D 는 TCP 와 UDP 의수신성능을측정하기위한실험이므로 netperf 의 UDP 테스트수신성능또한유효한의미를가지고있다. [ 표 4] 실험 D 의결과 ( 단위 : Mbps) Stream TCP # Type UDP 5 1550.6 Send 1921.42 1 5 1518.07 Receive 1914.53 10 1449.45 Send 1920.94 2 10 1457.71 Receive 1920.87 [ 표 4] 는실험 D 의결과를보여준다. 먼저 TCP 성능결과를살펴보면 1450 Mbps 에서 1550 Mbps 정도의성능을보여주고있다. 이는실험 C 에서얻을수있었던 1.8 Gbps 의대역폭에비해떨어지는것이므로이값을 bonding 드라이버의 TCP receive 성능이라고볼수있을것이다. 따라서실험의결과에의하면리눅스의 bonding 드라이버는 TCP 의경우는 send 시가 receive 보다더좋은성능을보여준다는것을알수있다. UDP 의경우에는두번의실험을하였으며그결과 send 와 receive 모두 1920 Mbps 의성능을보여주고있어대부분이에러없이 send 와 receive 가되었으므로 bonding 드라이버의 UDP receive 성능은 send 시의성능과동일한 1920 Mbps 정도라고볼수있다. 즉리눅스의 bonding 드라이버는 UDP 의경우 send 와 receive 시둘다 1.9Gbps 이상의좋은성능을보이고있음을확인할수있다. 실험 A 에서 TCP 의성능이실험 D 에서의 73
성능에비해떨어지는것은스위치의 trunking 동작이정상적으로동작하지않았기때문이라고추정할수있다. 실험 C 와실험 D 는스위치를배제한호스트간의송수신능력을측정한결과로스위치의성능여부와상관없는 bonding 드라이버자체의성능을보여준다. 4. 결론및향후계획 본실험은리눅스커널 2.6 에포함되어 ELA 를지원하는리눅스 bonding 드라이버의기능과성능을테스트해보고문제가있다면문제의원인을밝히는것이목적이다. 실험에서는최대한스위치의기능과성능에따른영향을최소화하도록실험을진행하였다. 실험의결과를살펴보면 Ethernet link aggregation 기능을제공하는 mode-0 (roundrobin) 에서 TCP 와 UDP 모두충분한성능을발휘할수있다는것을확인할수있었다. 2 개의 gigabit port 를 bonding 했을경우 TCP 는 send 의경우 1.8Gbps, receive 의경우 1.5Gbps 의대역폭을보였으며 UDP 의경우 send 와 receive 모두 1.9Gbps 초반의대역폭을제공하였다. 이러한테스트결과를바탕으로리눅스커널 2.6 에서제공하는 bonding 드라이버의 link aggregation 은 UDP 의경우에는매우좋은선택일수있으며, TCP 의경우에도 send 를주로담당하는서버에서사용한다면효과적일수있을것이라는결론을내릴수있다. link aggregation 을사용할경우에는위의실험결과를참고하여환경을설정할때최상의효과를얻을수있을것이다. 향후과제로는본논문의실험에서다루지못한리눅스 bonding 드라이버의기타다른모드의성능측정이필요하며, 또한다수의네트워크인터페이스카드를사용함에따른성능의변화를측정하는 scalability 실험도필요하다. 정확한리눅스 bonding 드라이버의 scalability 를안다면실제로서버에이를적용하는경우에매우유용할것으로생각된다. 참고문헌 [1] Phillip Dykstra, High Performance Networking, on SuperComputinf 2002 in 18 November 2002 [2] Deepak Kakadia, Sam Halabi and Bill Cormier, Enterprise Network Design Patterns: High Availability, www.sun.com/blueprints/1203/817-4683.pdf [3] Thomas Davis, Willy Tarreau, Constantine Garvrilov, Chad N. Tindel, Janice Girouard, Jay Vosburgh, Linux Ethernet Bonding Driver minihowto, 2000. [4] ISL and 802.1Q Trunking Between Catalyst Layer 2 Fixed Configuration Switches and CatOS Switches Configuration Example, www.cisco.com/public/473/43.html [5] Duralink Port Aggregation Software, www.adaptec.com/pdfs/portaggregation.pdf [6] SUN TRUNKIN 1.2, White papers in Sun Microsystems, 1999. [7] Link Aggregation according to IEEE Standard 802.3ad, White papers in SysKonnect GmbH, 2002. [8] Amendment to carrier sense multiple access with collision detection(csma/cd)access method and physical layer specification aggregation of multiple link segments, IEEE Std 802.3ad-2000 [9] Daniel Andersen and Zhao Baosong, Heterogeneous Channel Bonding on a Beowulf Cluster, In Proceeding of the 2000 International Conference on Parallel and Distributed Processing Techniques and Applications, pp 2479-2484, June 2000. [10] ethtool, project site, http://sourceforge.net/projects/gkernel/ \ 김재열 1999 경북대학교전자공학과학사 2001 경북대학교전자공학과석사 2001 ~ 현재한국전자통신연구원, 선임연구원 < 관심분야 > 리눅스운영체제, 파일시스템, 시스템소프트웨어 강동재 1999 인하대학교전자계산학과학사 2001 인하대학교전자계산공학석사 2004 ~ 현재인하대학교컴퓨터정보공학박사과정 2001 ~ 현재한국전자통신연구원, 연구원 74
< 관심분야 > 데이터베이스, 네트워크연결형자료저장시스템, 원격시스템관리, 리눅스기반기술 김수영 2003 중앙대학교컴퓨터공학과학사 2005 한국과학기술원전산학과석사 2005 ~ 현재한국전자통신연구원, 연구원 < 관심분야 > 리눅스커널, 임베디드시스템소프트웨어 차규일 1998 고려대학교컴퓨터학과학사 2000 고려대학교컴퓨터학과석사 2000 ~ 현재한국전자통신연구원, 선임연구원 < 관심분야 > 운영체제성능개선, 시스템소프트웨어설계, 분산컴퓨팅 75