Enterprise Network Weather Map 시스템의설계및구현 1 김명섭 O, 김성윤, 박준상, 김재성고려대학교컴퓨터정보학과 {tmskim, adayslife, runtoyou, noatile}@korea.ac.kr 요 약 현재의 Enterprise 네트워크는 multi-gbps 를지원하는이더넷스위치중심의트리토폴로지형태로구축되고있다. 이러한네트워크의트래픽현황을파악하기위한방법으로 Network Weather Map 과링크별로구축되는 bandwidth 시간추이그래프가많이사용되고있다. 이들은라우터 / 스위치장비내에동작하는 SNMP agent 에서제공하는 MIB 정보를주기적으로수집하여 DB 에저장하고, 사용자가언제 / 어디서나볼수있도록 Web 기반으로구축된다. 본논문은현재의 Enterprise 네트워크에적합한 SNMP 기반의 Network Weather Map 구축에있어고려되어야할사항을점검하고, 이를바탕으로 Enterprise Network Weather Map 시스템을설계하고구현한내용을기술한다. 특히 Enterprise 네트워크와 Core 네트워크의토폴로지상의차이를고려하여효율적인 Network Weather Map 디자인을제시하고, multi-gbps 고속링크를지원하는현재의라우터 / 스위치장비에 SNMP MIB-II 사용의문제점을확인하고이의해결방안을제시한다. 또한 SNMP 의사용에따른네트워크트래픽의발생량, 그리고네트워크장비의부하를조사함으로써 SNMP 의효율적사용방법을제시한다. 본논문에서구축한 Network Weather Map 시스템은학교 Campus 네트워크를대상으로구축되었다. Keywords: Network Weather Map, Enterprise Network, Passive Monitoring, SNMP, MIB 1. 서론 현재 Enterprise Network 은 multi-gbps 를지원하는이더넷스위치기반의트리토폴로지의형태로구축되고있고이러한추세는앞으로도계속되고있다.[1] 최상단에라우터가있어인터넷과의연결을담당하고, 각건물의 Building 스위치들과라우터를연결하는 Core 스위치가있고, 각건물에는 Building 스위치, Floor 스위치, Room 스위치, 그리고말단에컴퓨터의계층적트리구조를형성하고있다. 또한하나의링크들은 100 Mbps Fast 이더넷으로, 상단은 1 Gbps 이상의 Gbit 이더넷으로구성되고있다. 네트워크사업자 (NSP) 나인터넷사업자 (ISP) 의 Core 네트워크및회사, 학교및기관의 Enterprise 네트워크의트래픽현황및추이파악을위한방법으로 SNMP 를기반으로하는네트워크모니터링시스템 [2] 이많이구축되고있다. SNMP 기반의네트워크모니터링시스템은라우터나스위치에내재된 SNMP agent 가각링크의트래픽통계정보를표준화된혹은개별적으로정의된 MIB 구조에따라구축하고, 네트워크장비와는독립되게동작하는 SNMP manager 가그정보를주기적으로취합하여네트워크트래픽현황을보여주는구조로구축된다. 네트워크트래픽현황파악을위한모니터링시스템은크게현재의트래픽현황을네트워크토폴로지정보와함께보여주는 Network Weather Map[3, 4, 5, 6] 과각링크의시간추이에따른트래픽변화를그래프로보여주는시간추이그래프 [7] 의형태로구축된다. 또한사용자인터페이스또한독립된응용프로그램으로구축되기도하고, 사용자의이동성및편재성을고려하여 Web 기반의시스템으로구축되기도한다. 본논문은현재의 Enterprise 네트워크에적합한 SNMP 기반의 Network Weather Map 및시간추이그래프시스템구축에있어고려되어야할사항을점검하고, 이를바탕으로 Enterprise Network Weather Map 시스템을설계하고구현한내용을기술한다. 특히 Enterprise 네트워크와 Core 네트워크의토폴로지상의차이를고려하여효율적인 Network Weather Map 디자인을제시하고, multi-gbps 고속링크를지원하는현재의라우터 / 스위치장비에 SNMP MIB-II 사용의문제점을확인하고이의해결방안을제시한다. 또한 SNMP 의사용에따른네트워크트래픽의발생량, 그리고네트워크장비의부하를조사함으로써 SNMP 의효율적사용방법을제시한다. 본논문에서구축한 Network Weather Map 시스템은학교 Campus 네트워크를대상으로구축되었다. 본논문은다음과같은순서로기술한다. SNMP 1 본논문은고려대학교특별연구비에의하여수행되었음 172
기반의네트워크모니터링시스템에대한관련연구가 2 장에서, Network Weather Map 시스템구축고려사항이 3 장에기술한다. 4 장에서는고려사항을바탕으로한시스템설계에대하여 5 장은시스템구현및구현결과에대하여기술한다. 마지막으로 6 장에서는결론을맺고향후보완점과연구과제에대하여언급한다. 2. 관련연구 SNMP [2] 는네트워크 [8] 뿐만아니라시스템 [9] 및서비스 [10] 의성능을모니터링하기위한표준화된가장일반적인도구이다. 본장에서는 Network Weather Map ( 이하 NWM) 시스템구축에대한관련연구를기술한다. 네트워크의현황을나타내는 Network Weather Map 시스템은보여주는내용에따라특화된데이터수집체계를통하여구축된시스템 [11] 도있지만일반적으로많은시스템들은 SNMP 를이용하여네트워크장비로부터트래픽정보를수집하여보여준다 [12, 13]. SNMP 기반의 NWM 시스템의구축은대상네트워크에따라 Core 네트워크를위한 NWM 시스템, Enterprise 네트워크를대상으로한 NWM 시스템으로나누어볼수있고, 구축된형태에따라 Web 기반사용자인터페이스를제공하는 Web 기반 NWM 시스템, 독립된컴퓨터에서 Window 사용자인터페이스위주로구현된 Windows 기반시스템으로나누어볼수있다. 많은경우 NWM 시스템들은위의항목들을목적에따라서적절히혼용하여구축되고있다. NWM 시스템의관점에서본 Windows 사용자인터페이스의장점으로네트워크장비의연결정보자동검색 [12, 13] 을통한자동화된네트워크토폴로지구축및다양한토폴로지표현방법을제공하며, 목적에따라다양한기능을추가삭제할수있는시스템운영의유연성을제공하지만, 사용자의이동성및다수사용자의지원이어려운단점이있다. 그러나 Web 기반사용자인터페이스는반대로사용자의이동성과동시성에대한장점은있지만정해진범위내에서의분석및정보표현으로유연성이부족한단점이있다. 본논문에서개발한 NWM 시스템은 Enterprise 네트워크를대상으로구축하고 Web 기반의사용자인터페이스를제공하는구조로설계되고구현되었다. 본장에서는또한현재운영되고있는 NWM 시스템의구축사례를알아보고그들의 NWM 시스템구축에있어특징을짚어본다. 가장대표적인 NWM 시스템 [3] 으로미국 Indiana Univ. 의 Network Operation Center (NOC) 에서 Internet2 (Abilene Network) 을모니터링하는시스템이다. 이시스템은미국내 Internet2 를구성하는라우터 12 개사이의트래픽현황을실시간으로측정하여 Web 으로그결과를보여준다. 이 NWM 의특징은미국지도상에각라우터의위치를표시하고, 라우 터와라우터사이의양방향트래픽을화살표로분리하고, 각각의트래픽양을색깔을달리하여표현하고있다. 이러한방법은 Core 네트워크를대상으로한 NWM 시스템의가장대표적인구축사례이다. Internet Traffic Report[4] 은전세계트래픽의흐름현황을취합하여대륙별트래픽상황을숫자값 (traffic index: 0-100) 의값으로표현한다. 이시스템은각링크의현황보다는대륙단위의전반적인트래픽현황을 traffic index 의값으로표현하고있다. 5 분주기의실시간정보를 Web 을통하여확인할수있다. GRNET NWM 시스템 [5] 은그리스국내네트워크의트래픽현황을 NWM 과각링크의시간추이그래프를통하여표현하고 Web 을통하여정보를제공한다. 이역시 Core 네트워크를대상으로구축된시스템으로화살표와색깔로트래픽의방향과양을표현하며, 시간추이그래프를통하여시간흐름에따른각링크의트래픽양의변화를확인할수있게해준다. Enterprise 네트워크를대상으로한 NWM 시스템은네트워크의보안과관리의면에서공개된것을찾아보기쉽지않다. 국내의 POSTEC NWM 시스템 [6] 은대표적인 Enterprise 네트워크를대상으로한시스템으로전체적인구조는 Core 네트워크 NWM 시스템의구축내용과비슷하게화살표와색깔로링크와트래픽양을표현하고있다. 네트워크토폴로지에있어서지도보다는장치의연결정보를위주로구축하고있고장비간계층적구조는고려되지않아복잡하게표현되고있다. 각링크의시간추이그래프를제공하여트래픽양의변화를파하는데도움을주고있다. 3. 시스템구축고려사항 본장에서는현재 Enterprise 네트워크에서 NWM 시스템을구축함에있어고려되어야할사항들을점검하고, 각사항에대한본논문에서적용한해결책을제시한다. 3.1 Enterprise 네트워크토폴로지 Enterprise 네트워크토폴로지는 NSP 의 Core 네트워크토폴로지와다르다. 따라서 NWM 시스템의구축에있어 Enterprise 네트워크토폴로지특성을최대한고려하여구축하여야한다. Enterprise 네트워크토폴로지는그림 1 에나타난바와같이최상단에라우터가있어인터넷과의연결을담당하고, 라우터로부터들어온인터넷트래픽을각건물로분산하는 Core 스위치, 각건물에서트래픽을취합 / 분산하는 Building 스위치, 건물의각층에서트래픽을분산하는 Floor 스위치, 그리고하단에컴퓨터가직접연결되어있든지 Room 스위치 173
를거처각종컴퓨터장비로연결되는계층적트리구조를형성한다. 이는그림 1 에서나타난일반그래프구조의 Core 네트워크의구조와는다른형태를띠고있다. 그림 1 에서나타난계층적트리구조의 Enterprise 네트워크토폴로지정보가 NWM 의디자인에고려되어야한다. Enterprise INTERNET Router Core Core Switch Switch Building Switch Building Switch Building Switch Floor Switch Floor Switch Room Switch Room Switch (a) 전형적인 Enterprise Network Room Switch Room Switch ER ER Core Router ER Edge Router (b) 전형적인 Core Network 그림 1. Enterprise 네트워크 vs. Core 네트워크 3.2 Enterprise 네트워크모니터링범위계층적트리구조로이루어진 Enterprise 네트워크의네트워크장비들은네트워크관리자관리와사용자관리로나눌수있다. 이는 NWM 디자인에있어트리구조에서표현범위를결정하는중요한요소가된다. 일반적으로상위라우터에서하위 Floor 스위치까지는네트워크관리자의관리범위에속하고, Room 스위치이하는사용자가관리하고있다. NWM 의디자인에있어모니터링범위는관리자관리의네트워크장비들로정하는것이관리의일관성과시스템운용의효율성을위해타당하다. 또한관리자관리범위의네트워크장비는 IP 주소가할당되어야하고, SNMP agent 가동작되어야한다. 3.3 트래픽의방향성 Enterprise 네트워크는계층적트리구조의토폴로지를형성한다. 이구조에서인터넷과연결되는라우터는 leaf node 에해당되고말단의컴퓨터장비들은 leaf node 에해당된다. 트래픽의흐름또한 Core 네트워크와는달리상향 / 하향으로나누어질수있다. 상향트래픽은트리구조에서 child node 에서 parent node 로가는트래픽이고, 하향트래픽은 parent node 에서 child node 로가는트래픽이다. NWM 을디자인함에있어서트래픽을표시할때상향트래픽과하향트래픽의기본적인색깔을분리하여통일성을유지하고, 그양을색의농도로표시하는방법은전체적인트래픽의흐름을파악하는데도움된다. 3.4 모니터링지점의선택타겟링크의트래픽양정보를측정할때계층 ER ER 적트리구조에서링크의상위또는하위네트워크장비중하나를선택해야한다. 링크를통해지나간트래픽은링크양단네트워크장비의 SNMP agent 로부터모두수집할수있기때문이다. 이러한선택에있어서일관성의유지가 NWM 시스템의사후관리를위해중요하다. 본논문에서는 Enterprise 네트워크의계층적트리구조에서타겟링크의트래픽정보는상위네트워크장비에서수집하는것을제안한다. 이유는각링크의상단네트워크장비에서트래픽정보를수집하면본문 3.2 장에서제시한관리범위를한단계더확장할수있기때문이다. 즉 Room 스위치및각호스트별트래픽발생정보를 NWM 에표현가능하게된다. 단라우터에서인터넷으로오가는트래픽은라우터의상단네트워크장비는관리범위에서제외되기때문에라우터에서잡아야하는예외가생긴다. 3.5 트래픽정보표현주기트래픽정보표현주기는대부분의시스템에서 5 분을사용한다. 이는대표적인트래픽시간추이그래프를제공하는 MRTG[7] 에서트래픽수집주기를 5 분을최소값으로제공하고있고, CISCO Enterprise MIB[14] 에서도 5 분을최소단위로하여트래픽평균값정보를제공하고있기때문이다. 그러나 NWM 시스템을구축함에있어서수집주기를변경함으로써표현주기를변경가능하지만, 일반적으로사용되는 5 분단위의 NWM 정보갱신을사용하는것이타당하다고본다. 3.6 고속링크에서트래픽정보수집주기트래픽정보수집주기는 3.5 절에서의이유로대부분의시스템에서 5 분을사용한다. 이는고속네트워크트래픽수집에있어치명적인문제를가지고있다. 5 분간 bandwidth 평균값을계산하기위해많은경우 MIB-II[15] 의 interfaces 그룹에정의된 MIB-2.2.2.1.16 (ifoutoctets) MIB 정보를사용하는데, 이 MIB object 는 Counter (32 bit) type 으로정의되어있어그림 2 와같이 5 분동안약 110Mbps 이상의트래픽이발생하면 ifoutoctets 값의오버플로우가발생하여오류값을발생시킨다. (0xFFFFFFⅹ8) (5ⅹ1024ⅹ1024) = 109.227 Mbps 그림 2. 링크 In/Out bandwidth 시간추이그래프 그림 2 에서보는바와같이 15 시에서 24 시사이에파란색그래프가급격히떨어지는것을확인할수있다. 이는그시간에트래픽이적은것이아 174
니라 110 Mbps 이상발생했기때문이다. 이러한현상은현재많은 Enterprise 네트워크가 100 Mbps 이상의 bandwidth 로인터넷에연결되어있고, 라우터와 Floor 스위치사이 Gbps 고속네트워크로구축되어있어빈번히나타날것이다. 이에대한해결책으로두가지를생각해볼수있다. 먼저트래픽정보의수집주기를 5 분보다짧게하는방법이다. 단순계산으로 1 분단위수집은 550 Mbps 까지정확한값을얻을수있고, 30 초단위수집은 1.1 Gbps 까지정확한값을얻을수있다. 이방법은수집주기가짧아짐에따라많은트래픽을발생시켜네트워크에부담을줄여지가있다. 다음으로생각할수있는것이 MIB-II interface 그룹의 ifoutoctets 이아닌다른 MIB 으로부터정보를가져오는것이다. ifoutoctets 의경우는 RFC2863 [16] 에정의된 IF-MIB 의 ifcoutoctets MIB object 가 Counter (64 bit) 로정의되어있어대체가가능하다. 이와같은방법으로여러 RFC 1213[15] 의 MIB-II object 들은나중에정의된 MIB 들로대체될수있다. 그러나이방법의사용에있어고려해야할점은해당네트워크장비들이 IF-MIB 정보를제공하는지확인해야하고, SNMP V2c[2] 이상의프로토콜에서만동작한다는것이다. 따라서이두가지방법들을 NWM 시스템을구축하려는네트워크의상황에맞게적용되어야할것이다. 본장에서는고속링크로구성된 Enterprise 네트워크를위한 NWM 시스템을구축함에있어서고려되어야할사항들을기술하고, 각각에대한타당한해결방안들을제시하였다. 본장에서는기술한내용은시스템을설계하기전에고려해야할사항들을중점으로기술되었고, 시스템의설계에있어서고려사항과본논문에서선택한방법은 4 장에서기술한다. 4. 시스템설계 본장에서는 3 장에서제시한고려사항들을바탕으로 Enterprise 네트워크의 NWM 시스템구축을위한설계내용을기술한다. NWM 시스템은학교 Campus 네트워크를대상으로설계되었다. 4.1 NWM 시스템요구사항본절에서는 Campus NWM 시스템을개발에필요한요구사항들을기술한다. 첫째, NWM 시스템은 Campus 네트워크의관리자관리범위의모든네트워크장비및링크들을모니터링할수있어야한다. 둘째, NWM 표현에있어 Campus 네트워크의계층적트리구조가잘표현되어야하며, 각계층의링크에서발생하는트래픽양에대한비교를쉽게할수있어야한다. 셋째, NWM 시스템은현재 Campus 네트워크에서 발생하는트래픽의정보를실시간으로보여주어야하며, 각링크의트래픽발생량에대한시간추이그래프도볼수있어야한다. 넷째, 수집된트래픽정보는시간이지남에따라효과적으로저장관리되어야하고, 제한된저장공간을효율적으로사용할수있어야한다. 다섯째, 네트워크장비로부터트래픽정보의수집에있어네트워크및네트워크장비의부하를최소화하여야하고, 최단시간에필요한트래픽정보를수집할수있어야한다. 여섯째, 사용자의 NWM 요구는언제어디서나이루어질수있어야하고, 요구에의해 NWM 정보를즉시보여줄수있어야하며, 사용자의요구폭증을효율적으로처리할수있어야한다. 본논문에서개발한 Campus NWM 시스템은위의여섯가지요구사항을바탕으로개발되었다. 4.3 NWM 시스템전체구조그림 3 은 Campus NWM 시스템의전체적인구조를표현한것이다. Campus NWM 시스템은기본적으로 SNMP 를이용하여 Campus 네트워크의각네트워크장비로부터트래픽정보를수집하여 Traffic Info. DB 에저장하고, 사용자의요청에의해 DB 에저장된정보를바탕으로현재시점의 Network Weather Map 을생성한다. 사용자요청은웹을통해이루어지며사용자는언제어디서나네트워크를통해 Campus 네트워크트래픽현황을파악할수있다. Campus Network SNMP Request SNMP Response Network Weather Map System SNMP andler Rq Rp Timer trigger Traffic Information Collector trigger traffic info. DB Manager manipulate Traffic Info. DB Day Table Week Table Month Table Year Table Rq Rp map Network Weather Map Generator Map Cache map 그림 3. NWM 시스템전체구조 Rq Rp Web Server Request Response Rq Rp Request Response MWM 시스템은양단에사용자와 TTP 통신을담당하는웹서버, 네트워크장비와의 SNMP 통신을담당하는 SNMP andler 가존재하고, 그사이에 Timer, Traffic Info. Collector, DB Manager, Traffic Info. DB, NWM Generator, Map Cache 의 6 개의모듈이있다. 6 개의모듈은 DB 를중심으로 DB 에트래픽정보를수집하여저장하는 Traffic Info. Collector 와 DB 에저장된데이터를 Week, Month, Year 단위로압축저장하는 DB Manager 가있고, Timer 는주기적인시간간격으로 Traffic Info. Collector 와 DB Manager 를실행시킨다. 웹서버를통해사용자요청이들어오면 NWM Generator 는 DB 에저장된트래픽정보를읽어 NWM 을생성하고, 생성된 NWM 은 Map Cache 에저장한다. NWM Generator 는 DB 가새롭게 175
갱신되기전까지 Map Cache 에있는 map 을사용자에게제공한다. 다음은 NWM 시스템의각모듈에대한상세설명이다. 4.3 Traffic Information DB Traffic Information DB 는 MRTG 와 RRDTool 에서정보의시간추이그래프를표현하기위한데이터저장방법인 Round-Robin DB 의형태로테이블을구축하였다. 이는시간의흐름에관계없이저장공간의크기를일정하게유지하면서다양한시간추이그래프 ( 일간, 주간, 월간, 연간 ) 를보여줄수있는장점이있다. Traffic Info. DB 는그림 4 에서보는바와같이 5 분각링크의양방향 bandwidth 정보를저장하는 day_table, 30 분단위 bandwidth 평균을저장하는 week_table, 2 시간단위평균값을저장하는 month_table, 1 일단위평균값을저장하는 year_table 의 4 종류의 table 이각모니터링링크별로별도로구성된다. day_table Time (# of record = 7 day x 24 hour x 12 (5 min) = 2016, (2016x28 = 54.448 Kbytes) InOctets (8byte) 5min_avg_InBw OutOctets 8 byte 5min_avg_OutBw week_table (# of record = 14 day x 24 hour x 2 (30 min) = 672, (672x20 = 13.440 Kbytes) Time 30min_avg_InBw (4byte) 30min_max_InBw 30min_avg_OutBw month_table (# of record = 60 day x 12 (2 hour) = 720, (720x20 = 14.400 Kbytes) Time 2hr_avg_InBw (4byte) 2hr_max_InBw 2hr_avg_OutBw year_table (# of record = 400 day = 400, (400x20 = 8.000 Kbytes) Time 1day_avg_InBw (4byte) 1day_max_InBw 1day_avg_OutBw 30min_max_OutBw 2hr_max_OutBw 1day_max_OutBw 그림 4. Traffic Info. DB 의테이블스키마 각 DB 테이블에저장되는레코드의수는그림 5 와같이 day_table 은 7 일간 201, week_table 은 14 일간 672, month_table 은 60 일간 720, year_table 은 400 일간 400 개의레코드를갖게되고, 한링크를모니터링하기위해필요한저장공간은 DB 사용에따른시스템공간을제외하고순수한데이터저장공간은위의네테이블에필요한공간의합인 90.280 Kbytes 이다. 본논문에서모니터링하는 Link 의수는현재모두 50 개로필요한전체저장공간은 4.514 Mbytes (= 90.280 Kbytes ⅹ 50) 이다. 이사이즈는 Campus NWM 시스템을구축하는데필요한최소한의저장공간이다. 물론링크의수가늘어나게되면, 그리고수집해야할정보의종류가늘어나테이블의스키마가확장되게되면저장공간의크기는늘어나게되겠지만, 수백기가의저장공간이흔한현재의컴퓨터환경에서는충분하다고여겨진다. 4.3 Traffic Information Collector Traffic Info. Collector 는일정한시간주기로 Timer 로부터이벤트를받아지정된네트워크장비로부터 SNMP 프로토콜모듈을이용하여트래픽정보를수집하는기능을수행한다. 각링크별로수집된트래픽정보는 DB 의 day_table 에저장된다. 여기에서고려해야할사항은어떤 MIB object 로부터어떤시간주기로어떠한방식으로트래픽정보를수집할것인가이다. 본논문에서구현하는 Campus NWM 시스템은고속링크의 bandwidth 정보를수집해야하기때문에 IF-MIB[16] 에정의된 ifcoutoctets (mib-2. 31.1.1.1.10) 와 ifcinoctets (mib- 2. 31.1.1.1.16) 에서 SNMP V2c 프로토콜을이용하여 5 분단위로트래픽정보를수집한다. 또한수집해야할링크의수가다수일때트래픽정보수집을순차적으로할것인지동시에할것인지결정해야한다. 이는네트워크의부하와정보수집시간을최소화하는최적의방법을찾아야한다. 그림 5 는 SNMP GET 메시지에대한 roundtrip time 를그래프로나타낸것이다. Campus 내에위치한 NWM 시스템에서 Campus 내두개의다른네트워크장비 ( 스위치, 라우터 ) 로 SNMP GET 메시지를보내측정하였고, 이때각장비의평균 CPU 부하는 2%, 24% 였다. 그림 5 에서보는바와같이 SNMP 메시지의 RTT 는네트워크장비나 CPU 의부하에관계없이평균 2.8 msec 정도가나왔다. 이는 1 초동안한장비로 357 (=1000 / 2.8) 개의 MIB object 의순차적수집이가능함을뜻한다. Campus NWM 시스템의구축에있어모니터링되는링크는모두 50 개이고각링크당 2 개의 MIB 정보를추출하므로모두 100 개의 SNMP 메시지를발생시킨다. 순차적으로메시지를생성한다하더라도 1 초내에모든수행이가능하다는것을알수있다. Round-Trip Time msec 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 SNMP Round-Trip Time CISCO 스위치 CISCO 라우터 1 2 3 4 5 6 7 8 9 10 Number of Test 그림 5. SNMP RTT 평가 IF-MIB 에정의된 ifcoutoctets MIB 정보를가져오는데있어서소비되는트래픽은 SNMP request 1 패킷 (88 bytes), SNMP response 1 패킷 (94 bytes) 의총두개의패킷이고, 바이트수는총 182 bytes 이다. 50 개의링크에대하여트래픽정보수집에필요한트래픽의양은 200 패킷 (= 2 x 100), 18200 bytes (= 182 bytes x 100) 이고, 이양이 1 초동안순차적으로발생한다면필요한 bandwidth 는 145.6 Kbps (= 18200 bytes x 8) 이다. 이양은 1 Gbps 의고속링크로구성된현재의 Campus 네트워크에서는무시할수있을정도의적은양으로여겨진다. 따라서 Enterprise 네트워크에문제가발생하지않는다면 Traffic Info. Collector 는순차적인링크트래픽정보의수집을하여도네트워크부하나수집시간에있어충분히요구사항을만족시킬수있다. 물론여기에효율성을더하기위하여 SNMP 176
GETBULK 메시지나쓰레드 / 멀티프로그래밍을이용한트래픽정보의동시수집을고려할수있으나이는 Enterprise 네트워크의크기와수집해야할트래픽정보의양을고려하여적절히결정되어야할사항이다. 그러나 Enterprise 네트워크에문제가발생하는경우에대한대비는있어야할것이다. 트래픽정보수집시간은어떠한경우라도다음수집시간전에끝나야한다. SNMP 는 UDP 를사용하기때문에 SNMP 패킷의손실, SNMP agent 의장애, 네트워크장비의장애등의경우에 Traffic Info. Collector 는 SNMP GET 메시지를보내고난후에일정시간 (5 sec) 동안답변이없으면문제가생겼음을인식하고다시 SNMP GET 메시지를보낼지, 장애로여길지판단하게된다. 이경우 timeout 의값과 retrial 횟수가 Traffic Info. Collector 의안정적동작에큰영향을미친다. 본논문의 Campus NWM 시스템에서는 timeout 값을 2 sec, retrial 횟수를 2 회로정하였다. 이는 NWM 시스템및타겟장비들이모두 Campus 네트워크내에존재하고, 5 hop 이하의링크로연결되어있기때문이다. 이런경우극단적인경우 100 개의 MIB object 값을수집하는데걸리는시간은아래의계산과같이 5.66 min 이다. 5 분주기로 traffic Info. Collector 가동작하는 Campus NWM 시스템은문제를발생시킨다. 100 MIB objects x 2 sec x 2 = 400 sec = 5.66 min 이러한문제에대한해결책으로본논문에서는네트워크장비별로 Traffic Info Collector 를독립된프로세스로실행시킨다. 이렇게함으로써라우터에서부터 Building 스위치레벨까지 13 개의네트워크장비에대하여독립된프로세스가트래픽정보를수집한다. 한장비에최대 10 개의링크를모니터링하기때문에최악의경우 80 sec 의시간이소요된다. 물론이문제에대해타겟네트워크의상황에따라더효율적인방법이있을수있을것이다. 4.3 DB Manager DB Manager 의역할은각링크의 day_table 에저장된 5 min 평균트래픽정보를 4.3 절에서정의한내용에맞춰 week_table, month_table, year_table 을구성하는역할을수행한다. 그림 6 은 5 min 마다 Timer 에의해 event 를받은 DB Manager 의작업내용을순서도로그린것이다. 먼저각링크의 day_table 에저장된레코드들중에 7 일이전의데이터를지운다. 다음으로현재시각이 0분, 30 분일경우 day_table 에저장된지난 30 분간의트래픽정보를바탕으로평균 Out bandwidth, 최대 Out bandwidth, 평균 In bandwidth, 최대 In bandwidth 를계산하여 week_table 에저장하고 14 일이전의데이터는지운다. 다음으로매 2 시간마다지난 2 시간동안의트래픽양의평균값, 최대값을계산하여 month_table 에저장하고 60 일이전 의데이터는 month_table 에서지운다. 마지막으로매 24 시간마다지난 1 일동안의트래픽양을계산하여 year_table 에저장하고 400 일이전의데이터를지운다. START Delete all records in the day_table older than ( cur_time ( 7 x 24 x 60 x 60) ) (cur_time / 60) % 30 == 0 N (cur_time / (60x60) ) % 2 == 0 N (cur_time / (60x60) ) % 24 == 0 N END Y Y Y generate last 30 min avg. traffic info. and store them in the week_table delete all records in the week_table older than ( cur_time ( 14 x 24 x 60 x 60) ) generate last 2 hour avg. traffic info. and store them in the month_table delete all records in the month_table older than ( cur_time ( 60 x 24 x 60 x 60) ) generate last 1 day avg. traffic info. and store them in the year_table delete all records in the year_table older than ( cur_time ( 400 x 24 x 60 x 60) ) 그림 6. DB Manager 순서도 4.4 NWM Generator NWM Generator 의역할은사용자의요청에의해현재 map 정보를웹페이지형식으로생성하고 Web 서버를통하여사용자에게전달하는역할을수행한다. Campus NWM 시스템은 5분주기로트래픽정보를갱신하고 map data 를생성하고, Web UI 의특성상여러사용자로부터동시다발적인요청이이루어질수있기때문에 map cache 를두어시스템의부하를최소화하였다. START Is DB updated? END Yes generate NWM from the traffic data in the day_table generate time-series graphs from the traffic data in the tables store the maps and graphs in the Map Cache send them to the Web Server No read map data from the Map Cache send it to the Web Server 그림 7. NWM Generator 순서도 그림 7 은사용자요청에따른 NWM Generator 의동작을나타내는순서도이다. 우선사용자의요청이들어오면최근요청이후 DB 의트래픽정보가갱신되었는지검사한다. 갱신되지않았다면 Map Cache 에저장된 map 데이터를보내주고, 갱신되었다면새로운 map 데이터와시간추이그래프를생성하여 Map Cache 에저장하고 Web 서버에보내준다. 이러한방법으로 NWM Generator 의부하를최소화하고, 많은사용자의동시요청을처리할수있다. 177
5. 시스템구현 4 장의 NWM 시스템설계를바탕으로 Campus 네트워크의트래픽현황을한눈에파악할수있는 Campus NWM 시스템을개발하였다. 그림 8 은 NMW 시스템이보여주는 map 데이터의내용이다. Campus 네트워크는최상위의라우터가인터넷과다른 Campus 로연결되어있고, 라우터는하위에두대의 Core 스위치와연결되어있다. 두대의 Core 스위치는각빌딩의 Building 스위치와동시에연결되어있어장애발생을최소화한구조로되어있다. 그림 8 에는나타나지않았지만, 각 Building 스위치와연결된 Floor 스위치까지 Campus 네트워크의계층적트리구조를 map 으로표현하였다. 그림 8. Campus NWM 시스템 Web UI 각계층별링크를그룹화하고, 링크에서발생하는트래픽양을막대그래프로표현하여같은계층의링크에서발생하는트래픽의양을쉽게비교할수있도록하였다. Campus 내에서인터넷으로발생하는트래픽 (Outbound) 은상단막대그래프로, 인터넷에서 Campus 내로들어오는트래픽 (Inbound) 은하단막대그래프로표현하여두종류의트래픽양을쉽게비교할수있도록하였다. 또한 Inbound, Outbound 트래픽양의표시에있어그래프의색깔을통일함으로써쉽게구분할수있도록하였다. 또한각링크를선택하면타겟링크의트래픽시간추이그래프를보여줌으로써지난하루동안트래픽발생양의변화를확인할수있게하였다. 테이블 1. Campus NWM 시스템개발환경 OS Web Server Language DB Tool Linux Fedora 6 Apache 2.2.3 C, PP, Perl MySql 5.0.22 MRTG, RRDTool 본논문에서개발한 Campus NWM 시스템은테이블 1 과같은개발환경에서개발되었다. Linux 환경에서 Apache 웹서버를사용하였고, DB 는 MySql 을사용하였다. 그리고 NWM Generator 로 PP 를 사용하였으며, DB Manager 와 Traffic Info. Collector 는 C++ 를이용하여구현하였다. Timer 는 Linux 에서제공하는 Cron 데몬을이용하였다. 시간추이그래프를생성하기위하여 MRTG 를이용하였으나 MRTG 는그래프표현에제약이있어 RRDTool 을이용하거나, GD library 를이용하여직접그리는방안을모색중이다. 구축된시스템은현재 Campus 네트워크의트래픽현황을파악하는데운영되고있으며아래의 URL 을통하여 Web 으로확인할수있다. http://kumon.korea.ac.kr/ 5.1 Campus 네트워크트래픽의특징본절에서는 Campus NWM 시스템개발을통하여관찰된 Campus 네트워크의트래픽현황에대하여설명한다. 그림 9 는하루동안발생한인터넷트래픽의양을나타낸시간추이그래프이다. 첫째, Inbound 트래픽의양 (1day 평균 18.3 Mbits/sec) 이 Outbound 트래픽의양 (1 day 평균 54.2 Mbits/sec) 보다 3 배정도많은양을차지하고있다. 둘째, 하루동안트래픽양의변화는 Inbound 트래픽이 Outbound 트래픽에비해변화가심하고, Outbound 트래픽은완만한변화를보여주고있다. 그리고수업이진행되는낮시간에트래픽양이급격히증가하여최대치 (100 Mbps) 까지올라가며, 저녁과밤시간에는그정도가급격히떨어지는현상을보여주고있다. 이는학교학생들의활동에대한특성을잘나타내주는것이다. 그림 9. Campus 인터넷트래픽발생현황 셋째, Inbound 트래픽의최대치는 100 Mbps 인데하루중오전 10 시부터 5 시까지대부분의시간에최대치를보여주고있다. 이는 Inbound bandwidth 에대한 SLA 를재협상하여높일필요가있음을보여준다. 또한 Inbound 와 Outbound bandwidth 을달리정하는 Asynchronous bandwidth 협정의필요성도갖게한다. 또한 Inbound bandwidth 가최대치를나타낼때응용별 bandwidth 할당문제에대한연구의필요성도생각해볼수있다. 넷째, Campus 내의트래픽의흐름을분석해보면건물내에서발생한트래픽은대부분인터넷으로나가거나들어오는트래픽이고, 건물과건물사이에오가는트래픽은거의없는것으로나타났다. 그리고건물내의경우층별로설치되 Floor 스위치간의트래픽교환은빌딩간의트래픽교환보다는많아보이지만, 대부분인터넷으로오가는트래픽인것으로보여진다. 따라서 Campus 내에서발생하는대부분의트래픽은인터넷트래픽위주이고, Campus 178
내컴퓨터간통신은소수인것으로보여진다. 이러한현상이대부분의 Enterprise 네트워크에서의일반적인현상인지에대해서는좀더많은연구가필요할것이다. 이러한현상이일반적인경우라면네트워크관리자는이러한트래픽의특성을고려하여 Enterprise 네트워크를관리하여야할것이다. 6. 결론 본논문은 multi-gbps 를지원하는이더넷스위치중심의트리토폴로지형태로구축되고있는현재의 Enterprise 네트워크의트래픽현황을실시간으로파악하기위한 Network Weather Map 시스템의설계와구축에관한내용을기술하였다. 본연구에서는관리자가트래픽현황을효율적인파악을위하여 Enterprise 네트워크가가지는계층적트리구조의특징을 NWM 의구축에적용하였고, 각계층링크에서발생하는트래픽을쉽게비교할수있도록막대그래프표현방법을이용하였다. 또한 Gbps 이상의고속링크로구축되는 Enterprise 네트워크의모니터링에 SNMP 의사용에있어 MIB 정보선택의문제점과해결점을제시하였고, 시스템및네트워크의부하에대한분석을통하여 NWM 시스템이네트워크에미치는영향을연구하였다. 또한시스템의체계화효율성을위하여모니터링지점의선택, 트래픽정보의수집주기등 NWM 시스템의설계와구축에있어여러가지고려사항을제시하고, 각각에대한해결책을제시함으로써본논문은향후 NWM 시스템을구축하려는연구에도움을줄것으로기대한다. 본연구의결과물인 Campus NWM 시스템은상시운영함으로써네트워크관리자의네트워크관리에도움을주고있다. 향후연구로는현재의시스템성능개선과개발된시스템을바탕으로한 Enterprise 네트워크관리에관한다양한연구를추진중에있다. 먼저시스템성능및효율성개선을위해다양한정보의표현과 map 의다양한표현방법의두가지를고려하고있다. 그한예로트래픽양을표현하는막대그래프의시간추이에따른변화를효과적으로보여주기위해애니메이션기능을추가는것을들수있다. 둘째, 현재의트래픽모니터링연구를 SNMP 기반의보안연구로확대하여 Enterprise 네트워크의비정상트래픽의효율적분석을통한안정적네트워크운영에관한연구를계획하고있다. ISBN:201485346, 1999 [3] Internet2 Network Weather Map, http://www.abilene.iu.edu/abilene/mapsgraphs2/weather-map.html. [4] Internt Traffic Report, http://www.internettrafficreport.com. [5] GRNET Network Map, http://netmon.grnet.gr. [6] POSTEC Network Weather Map, http://ngmon.postech.ac.kr/ng-mon. [7] Tobi Oetiker, "Monitoring your IT gear: the MRTG story,", IT Professional, Vol. 3, No. 6, Nov-Dec, 2001, pp.44-48, http://oss.oetiker.ch/mrtg/. [8] You-Sun wang, Eung-Bae Kim, "The management of the broadband wireless access system with SNMP," Proc. of the 10th International Conference on Telecommunications(ICT 2003), Tahiti, Papeete, French Polynesia, Feb. 23 - Mar. 1, 2003, pp.225-228. [9] Myung-Sup Kim and James Won-Ki ong, "ighly Available and Efficient Load Cluster Management System using SNMP and Web," Proc. of the IEEE/IFIP Network Operations and Management Symposium (NOMS) 2002, Florence, Italy, Apri. 15-19, 2002, pp. 619-632. [10] Jae-Young Kim, Myung-Sup Kim, and James Won- Ki ong, "Management of Differentiated Services Using the SNMP Framework," Proc. of the International Conference on Advanced Communication Technology (ICACT) 2000, Muju, Korea, Feb. 16-18, 2000, pp. 624-629. [11] Rich Wolski, Neil Spring, and Jim ayes,"the Network Weather Service: A Distributed Resource Performance Forecasting Service for Metacomputing," Journal of Future Generation Computing Systems,Vol. 15, No. 5-6, October, 1999, pp. 757-768. [12] P Openview, http://www.openview.hp.com. [13] IMB Tivoli, http://www.tivolie.com. [14] CISCO, CISCO Enterprise MIB, http://www.cisco.com/univercd/cc/td/doc/product/wa nbu/8850px45/release3/snmp/axsm1.htm. [15] K. McCloghrie, M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II," FRC1213, IETF, Mar. 1991, http://www.ietf.org/rfc/rfc1213.txt. [16] K. McCloghrie, F. Kastenholz, "The Interfaces Group MIB," FRC2863, IETF, Jun. 2000, http://www.ietf.org/rfc/rfc2863.txt. 참고문헌 [1] N. Jovanovic, D. Sorgic, Tianying Ji, Shaowen Song, "An overview of metropolitan and enterprise networks - current and future," Canadian Conference on Electrical and Computer Engineering, May 1-4, 2005, pp. 160-163. [2] William Stallings, SNMP, SNMPv2, SNMPv3 and RMON 1 and 2, Third Edition, Addison-Wesley, 179