다중컨트롤러환경에서의제어평면모니터링및스위치배치방법에대한연구 (A study of control plane monitoring and switch placement scheme in SDN multi-controller environment) 정세연 *, 이도영 *, 리건 **, 유재형 *, 홍원기 * 포항공과대학교 * 컴퓨터공학과, ** 정보전자융합공학부 {jsy0906, dylee90, gunine, styoo, jwkhong}@postech.ac.kr 요 약 1. 서론 소프트웨어정의네트워킹 (Software Defined Networking, SDN) 은등장이후많은관심을받아온연구분야로써중앙집중적이고단일화된컨트롤러를통해모든네트워크상태를감시제어할수있다는특징을갖고있다. 이와같이네트워크상태를알기위해단일컨트롤러는네트워크를구성하는스위치들과끊임없이컨트롤메시지를송수신하는데, 이는네트워크규모가커지면확장성및단일장애지점문제 (Single point of failure) 를발생시키는원인이된다. 이를해결하기위해최근에주목받고있는 ON lab 의오픈소스 SDN 컨트롤러인 ONOS [1] 는여러대의서버또는클러스터에다중컨트롤러환경을제공하여각컨트롤러가가지는컴퓨팅부하를분산시킨다. 하지만 ONOS 는각컨트롤러에배치될스위치의개수만고려하기때문에각컨트롤러가처리하는컨트롤트래픽량을균형있게분배하는데한계가존재한다. 또한, 네트워크관리자가네트워크설정을변경했을때, 각컨트롤러가처리하는컨트롤트래픽량의변화를직관적으로알수있는방법이존재하지않는다. 따라서본논문에서는 ONOS 를개량하여컨트롤러에부하를주는컨트롤메시지들을모니터링하고그결과를그래프로보여줌으로써컨트롤트래픽량을보다직관적으로파악할수있는환경을제공하고자한다. 뿐만아니라모니터링결과를이용해전체컨트롤트래픽량을여러컨트롤러에균등하게분배하는스위치배치방법을제안한다. Keywords: Control Plane Monitoring, Switch Placement, Multi-Controller, Software Defined Network 오늘날, 소프트웨어정의네트워킹 (Software Defined Networking, SDN) 은컴퓨터네트워크분야에서주목을끌고있는연구분야중하나로다음과같은특징들을가지고있다. (1) 프로그래머블 (Programmable) 한환경을제공하여동적으로네트워크를구성하거나관리할수있다. (2) 데이터평면으로부터제어평면을완전히분리하고이를중앙집중화된컨트롤러로구성한다. (3) 컨트롤러는데이터평면에서이루어지는포워딩 (Forwarding) 규칙들을생성하여각스위치에설치하는역할을한다. 이러한중앙집중화된컨트롤러는자신이관리하는네트워크의모든정보를알기위해 OpenFlow 프로토콜 [2] 을사용하여네트워크에존재하는스위치들과지속적으로컨트롤메시지를주고받는다. OpenFlow 는오늘날사용되는사실상의 SDN 표준프로토콜로, 컨트롤러 - 11
스위치간통신을위한컨트롤메시지의규격및형태를정의한다. 만약네트워크를구성하는스위치개수가늘어나면이로인해발생하는컨트롤메시지수가증가하게되고결국컨트롤러가처리해야하는컨트롤트래픽량이증가하게된다. 이는컨트롤러를과부하 (Overloaded) 상태에빠지게만들고컨트롤메시지전달시지연을발생시켜전체네트워크성능저하를가져온다. 따라서이러한컨트롤러의과부하문제를해결하기위해정확한컨트롤러부하측정방법이우선적으로요구된다. 하지만이러한요구에도불구하고아직까지컨트롤메시지들로인해야기되는컨트롤러의부하상태를측정하기위한방안은많지않은실정이다. 반면 SDN 에서데이터평면을모니터링하기위한방법들은많은연구가진행되어왔다. 특히 FlowCover [3], FlowSense [4] 및 PayLess [5] 는데이터평면모니터링을위한대표적인연구들로, 데이터평면의사용량 (Utilization) 을정확하고낮은비용으로모니터링하는것을목적으로한다. 컨트롤트래픽으로인해야기되는과부하문제를해결하기위해서컨트롤메시지부하를정확하고효율적으로측정하는모니터링방법과부하분산을위한다중컨트롤러배치환경을갖추는방안이있다. 하지만대부분의오픈소스컨트롤러들은컨트롤트래픽을모니터링하기위한메커니즘과다중컨트롤러배치환경을제공하고있지않다. 반면 ONOS 는다중컨트롤러환경을지원하며자신이관리하는네트워크를정교한토폴로지뷰 (Topology view) 로제공하는완성도높은컨트롤러이다. ON lab 의주도하에개발중인 ONOS 는캐리어네트워크급의 SDN 컨트롤러를목표로개발되고있으며현재공식적으로 1.2.1 버전이공개되어있다. ONOS 가제공하는토폴로지뷰를이용하면관리중인네트워크의토폴로지형태뿐만아니라각스위치들이어떻게컨트롤러에할당되어있는지쉽게파악할수있다. 이러한이유로본논문에서는 ONOS 를이용하여제어평면모니터링및스위치배치알고리즘연구결과를제시하기로한다. 우리의연구목표는크게다음의두가지로구분된다. 1) 제어평면 ( 컨트롤러 ) 에전달되는컨트롤메시지를일정주기로모니터링하고, 그결과를실시간그래프형태로표현하는모니터링도구의개발 2) 특정컨트롤러에집중되는부하를다른컨트롤러로분산시키기위해각컨트롤러의컨트롤트래픽량을고려한스위치배치방법의설계및구현. 제안한방법의타당성을확인하기위해우리는두개의어플리케이션을개발하고 ONOS 컨트롤러에배치하여어느정도의성능향상이있는지실험을통해검증하였다. 첫번째어플리케이션은컨트롤러와스위치간에송수신되는 OpenFlow 컨트롤메시지들을모니터링하고그결과를메시지종류별로저장하고가공해서그래프로도식화한다. 이를통해제어평면에서송수신하는모든컨트롤메시지를실시간으로확인할수있는환경을제공한다. 두번째어플리케이션은첫번째어플리케이션의모니터링결과를바탕으로과부하가발생한컨트롤러를신속히파악하고해당컨트롤러에할당된스위치를다른컨트롤러에재배치하여제어평면의부하를분산시키고병목현상을완화시킨다. 이논문의나머지부분은다음과같은다섯개의순서로이루어져있다. 제 2 장에서는연구의배경설명으로 ONOS 와관련연구에대해소개하고제 3 장에서는 ONOS 구조와본논문에서개발한어플리케이션의상관관계및구현방법에대해구체적으로설명한다. 제 4 장에서는제안한방법의검증을위한실험환경과결과를보인다. 마지막으로제 5 장에서는우리의연구에대한결론을내리고향후과제에대해논의한다. 2. 연구배경및관련연구 2.1. Open Network Operating System (ONOS) ONOS 는성능, 확장성및가용성요구를충족시키기위한목적으로개발된분산 SDN 컨트롤플랫폼이다 [1]. ONOS 는서비스사업자들 (Service provider) 을위한캐리어급오픈소스네트워크운영체제를개발하는것을목표로한다. 현재시스코, 인텔, 스탠포드대학, 버클리 (UC Berkeley) 와같은글로벌벤더및대학들이 ONOS 프로젝트에참여하고있다. ONOS 의대표적인특징은다음과같다. 12
1) Distributed Core: 확장성및높은가용성과성능을제공함으로써캐리어급의기능들을 SDN 제어평면으로갖고온것이다. 즉, ONOS 가클러스터로동작할수있다는사실은안정적인 SDN 환경을구축할수있는요인중의하나이다. ONOS 인스턴스 (Instance) 들은서로통신을하면서마치하나의컨트롤러처럼동작하며, 어느 ONOS 인스턴스가장애를일으키더라도다른인스턴스가그역할을대신할수있다. 2) Northbound abstraction/apis: 제어, 관리및구성서비스의개발을용이하게하는네트워크그래프와어플리케이션을포함한다. 이는네트워크및어플리케이션개발자가시스템에대한정확한지식이없더라도원하는요구사항을네트워크상에쉽게구현할수있도록돕는다. 3) Southbound abstraction/apis: OpenFlow 또는그외의레거시 (Legacy) 장치를제어하기위한플러그인 (Plug-in) 가능한 Southbound 프로토콜을지원한다. 이 Southbound 추상화는 ONOS 의중심부 (Core) 와하위계층의장치들을분리한다. 이는 OpenFlow 기반화이트박스 (White-box) 에레거시장치들을연동시키기위한중요한기능이기도하다. 4) Software Modularity: 개발자또는어떤서비스요구를원하는서비스공급자들이직접 ONOS 를소프트웨어시스템으로써쉽게개발, 디버깅, 유지보수및업그레이드할수있다. 본연구에서 OpenFlow 를지원하는 ONOS 컨트롤러로구성된제어평면의스위치배치알고리즘을구현하므로 OpenFlow 에서컨트롤러와스위치간에논리적연관관계를표현하는방법에대한이해가필요하다. OpenFlow 명세서에따르면, 컨트롤러는스위치에대하여다음중하나의역할을수행한다. 1) Slave Role: 컨트롤러는해당스위치에대하여읽기권한만을가지며스위치로부터의 Port- Status 를제외한비동기메시지를수신하지않는다 ( 기본값 ). 또한해당스위치의상태를수정하기위한메시지를송신할수없다. 2) Master Role: 스위치에대한모든접근권한을가진다. 해당스위치에 Master Role 을가진컨트롤러는반드시하나만존재해야한다. 이와같이 OpenFlow 에서는 Role 개념을통해컨트롤러와스위치간에물리적채널과는별도의논리적연관관계를표현하는데, 이는다중컨트롤러환경에서컨트롤러의장애복구나부하분산에활용될수있다. 이번연구에이용되는 ONOS 는이러한 OpenFlow Role 메커니즘을위한모듈및인터페이스를제공한다. 본연구에서는과부하상태의 Master 컨트롤러에수용된스위치들중일부를다른컨트롤러에배치하기위하여, 해당스위치들에대해 Slave Role 으로동작하는컨트롤러중에서부하가가장낮은컨트롤러를선택해 Master Role 을부여한다. 오직하나의 Master Role 컨트롤러만존재한다는제약조건에따라기존의과부하컨트롤러는해당스위치들에대한 Master Role 을잃고 Slave Role 로동작하게된다. 2.2. 관련연구 기존의연구에서는컨트롤러가전체네트워크의상태를알수있다는장점을이용한데이터평면모니터링연구가주류를이루어왔다. 네트워크데이터평면의상태를모니터링하기위해컨트롤러와스위치들은컨트롤메시지들을주고받는데, 정확한모니터링을위해서는잦은주기로컨트롤메시지들을주고받아야했다. 하지만이는컨트롤러의컴퓨팅부하뿐만아니라네트워크의부하를증가시키는원인이되었다. 그런이유로데이터평면모니터링의경우에도간접적이나마컨트롤트래픽량을줄이려는시도가있어왔다. 특히, FlowSense [4] 에서는모니터링을위해컨트롤메시지를따로생성하지않고스위치에 Flow Rule 이생성되거나삭제될때발생되는 Packet-in, Flow-removed 메시지만을활용해최소한의비용으로데이터평면모니터링을시도하였 13
다. 그밖에 FlowCover [3] 에서는 State-Request/Response 메시지의양을최소화하기위하여일부중요한스위치들만을선택하여 State-Request 메시지를전달하고, 해당메시지를수신한스위치는자신이갖고있는플로우정보를단일 State-Response 메시지에집계하여컨트롤러로송신하는방법을제안했다. 이를통해컨트롤러는모든스위치로 State-Request 메시지를전송하지않고도전체네트워크상태를알수있었고, 스위치마다하나의 State-Response 메시지만을생성하므로트래픽량을기존의방법보다감소시킬수있었다. 한편, [6] 에서는최초로 SDN 에서컨트롤트래픽분석을시도하였다. 즉, 컨트롤트래픽을모니터링하여 D3 라이브러리, Django 그리고파이썬을통해그결과를몇가지종류의그래프로표현하였으며, Flow Rule 들의유휴타임아웃 (Idle timeout) 값과모니터링시간간격 (Interval time) 설정을통해컨트롤메시지들의양을줄이기위한방법을제시하였다. 그결과이두개의값설정을통해컨트롤트래픽량을줄일수있었지만, 자동화된시스템이아니어서네트워크관리자가직접모니터링결과를지켜보고부하를줄이기위해값들을설정해주어야한다는단점이존재한다. [7] 에서는 Kandoo 라는프레임워크 (Framework) 를제안하고있다. 여기에서는잦은네트워크이벤트들로인해제어평면이겪는부하를줄이기위한방법을소개하고있다. 이는두계층으로이루어진제어평면구조를가지는데상위계층에존재하는루트컨트롤러와하위계층에존재하는다수의로컬컨트롤러들로구성되어있다. 루트컨트롤러는각로컬컨트롤러들로부터네트워크정보를전달받아전체네트워크상태를알수있는반면로컬컨트롤러들은오로지자신들이관리하고있는지역네트워크상태만알수있다. 따라서로컬컨트롤러들은데이터평면에서발생하는잦은이벤트들을처리하고, 간혹전체네트워크상태를요구하는이벤트가발생될경우에만루트컨트롤러에게관련워크로드를요청하여처리한다. 결과적으로다중로컬컨트롤러를이용하여자주발생하는이벤트들을처리함으로써제어평면부하분산의효과를가져올수있다. 이외에도제어평면의부하를분산시키기위한연구들로 HyperFlow [8] 와 Onix [9] 가있었다. HyperFlow 는 NOX [10] 컨트롤러상에서어플리케이션형태로동작하며, 논리적으로는중앙집중화된컨트롤러이지만실제로는다수의분산컨트롤러들로구성되어있다. HyperFlow 는 publish/subscribe 시스템을이용해네트워크에서발생하는이벤트들을다룬다. Onix 는대규모네트워크를위한분산형제어플랫폼으로 Onix API 를통해네트워크제어를가능케한다. 한편, [11] 의연구는제어평면의신뢰성 (Reliability) 을보장하기위한컨트롤러배치문제에집중하고있다. 이연구에서는제어경로손실비율 (Percentage of control path loss) 이라고불리는메트릭 (metric) 을통해 SDN 컨트롤네트워크에서의신뢰성을측정하는방법을제시하였고, 몇가지컨트롤러배치알고리즘을제안하여제어평면의신뢰성을높이는방법을제시하고있다. 이외에는여러개의컨트롤러를이용해서단일컨트롤러의부하를줄이고자하는연구들도진행되어왔다. 그중 [12] 에서는컨트롤러의부하를분산시키고전체적인네트워크성능향상을위해컨트롤러배치문제에관심을두었다. 특히, 새로운컨트롤러가설치될적절한위치를정하는것이저자들이관심을둔부분이었다. 그들은해당연구에서다음의두가지질문을던지고이를해결하고자하였다. (1) 얼마나많은컨트롤러들이필요한가? (2) 그컨트롤러들은각각어디에위치되어야하는가? 이에대한답을얻기위해해당연구에서는스위치들과컨트롤러들사이의응답시간 (Reaction time) 을측정하여적절한위치를선택하는방법을택했다. 하지만이연구는오직정적 (Static) 인트래픽만고려하여컨트롤러배치를시도했다는한계를지니고있다. 이연구의한계를극복하기위해 [13] 에서는동적 (Dynamic) 인트래픽을고려한연구를진행하였다. 특히, 이연구에서는컨트롤러가 Flow Rule 들을설치할때걸리는시간 (Flow setup time) 과다중컨트롤러들간에동기화를맞추기위해각컨트롤러간에이루어지는통신부하 (Communication overhead) 를동시에고려했다. 즉, 단일컨트롤러가너무많은스위치들의 Flow Rule 설정에관여하여성능이떨어지는것을지양함과동시에다중컨트롤러들간발생하는통신부하를최소화하기위해노력하였다. 저자들은앞서제기한문제를 DCPP (Dynamic Controller Provisioning Problem) 이라고정의하고, 휴리스틱 (Heuristic) 알고리즘을통해해결방안을제시하고있다. 14
3. 시스템디자인 3.1. 개념적구조 그림 1. 개념적구조도 그림 1 은본연구의시스템구조를보인다. 그림에서최하위계층은실제패킷을전달하는스위치들로구성된데이터평면이다. 그상위계층은데이터평면과다중컨트롤러 (ONOS) 사이에통신프로토콜을정의한 Southbound API 계층으로써본연구에서는 OpenFlow 1.0 버전을사용한다. 이시스템에서는각컨트롤러에가해지는부하를일정주기로측정하고이를각컨트롤러의 Capacity 로가정하는임계치 (Threshold) 미만으로유지하기위해서부하를분산시킨다. 그결과컨트롤러간에일부스위치가재배치되는데, 이때각컨트롤러에배치되는스위치의개수는네트워크상황에따라달라진다. 그림의최상위계층에는본연구를통해구현된 Monitoring Manager 와 Switch Placer 라고명명된어플리케이션들이위치한다. Monitoring Manager 는여섯가지종류의컨트롤메시지 (Packet-In/Out, State-Request/Response, Flow-Modify/Removed) 들을모니터링하고가시화 (Visualization) 하는어플리케이션이다. 이여섯종류의컨트롤메시지들은컨트롤러 - 스위치간전달되는총메시지개수의 97.78% 을차지하며, 전체컨트롤트래픽의 99.70% 를차지하기때문에컨트롤러가처리하는컨트롤트래픽의대부분이라고볼수있다 [6]. 각메시지들의역할은다음과같다. 1) Packet-In: 스위치에도달한패킷에매칭되는 Flow Rule 이없거나매칭되는 Flow Rule 의 Action 이 Send to the controller 인경우발생하는컨트롤메시지. 패킷버퍼링을지원하는경우패킷헤더의일부만포함하고지원하지않는경우패킷전체가포함되어컨트롤러로전송된다. 2) Packet-Out: 컨트롤러가패킷을스위치의특정포트로전송하는데쓰이거나 Packet-In 메시지에의해전달된패킷을실제로포워딩하려는경우에발생하는컨트롤메시지. 3) State-Request/Response: 컨트롤러가스위치의플로우테이블, 포트, 큐에대한정보및설치된 Flow Rule 의통계값을요청하거나그에대한응답으로스위치가관련정보를컨트롤러로전달할때발생하는컨트롤메시지. 4) Flow-Modify: 컨트롤러가스위치플로우테이블내의 Flow Rule 을추가, 삭제, 수정요청하는경우에발생하는컨트롤메시지. 5) Flow-Removed: 스위치가컨트롤러의 Flow Rule 삭제요청이나기간만료 (Timeout) 에따라 Flow Rule 이삭제된사실을컨트롤러에게알릴때발생하는컨트롤메시지. 15
Algorithm 1 Overload detection Input: Topology, Controller capacity Output: Control traffic load balanced topology for all switch s in Topology do load s captured control traffic load on the switch s master s a master-role controller of the switch s backups s slave-role controllers of the switch s If master s equals controller c in Topology then controllerload c = controllerload c + load s end if end for for all controller c in Topology do if controllerload c >= capacity of controller c then Make a new switch placement for load balancing end if Reset controller c`s current load for next interval measurement end for 알고리즘 1. 과부하탐지알고리즘 Switch Placer 는컨트롤러의부하상태를측정하여과부하상태의컨트롤러를탐지하고해당컨트롤러의스위치일부를다른컨트롤러로재배치하는역할을수행한다. 알고리즘 1 은네트워크의모든컨트롤러중에서컨트롤트래픽으로인한과부하상태의컨트롤러를식별하는알고리즘으로써매 5 초마다수행된다. 현재수행주기에서모든스위치의컨트롤트래픽정보를저장하여컨트롤러단위의부하정보를계산한뒤, 미리정의된임계치를초과하는부하를가진컨트롤러만을식별해서알고리즘 2( 스위치배치알고리즘 ) 을수행한다. 이알고리즘은과부하컨트롤러에할당된각스위치들을해당컨트롤러에대한부하기여도 ( 점유율 ) 순으로정렬한다. 이후순차적으로스위치의점유율을누적해가면서 50% 에가장가까운스위치들의집합 (ⅰ) 과나머지집합 (ⅱ) 으로구분한다. 앞선 2 장연구배경에서설명했듯이, ONOS 에서는스위치와컨트롤러의관계를마스터쉽 (Mastership) 이라는개념으로관리하는데이역할정보를수정함으로써컨트롤러가관리하는스위치를재배치할수있다. 집합 (ⅰ) 에속하는스위치는현재컨트롤러와의마스터쉽을그대로유지하고, 집합 (ⅱ) 에속하는스위치에대해서는현시점에서부하가가장적은컨트롤러와의새로운마스터쉽을요청한다. 스위치배치를하는데있어서알고리즘 1 과같은임계치기반알고리즘을사용하는이유는다음과같다. [14] 와같이컨트롤러의 Capacity 는처리량 (Throughput) 과반응시간 (Response time) 관점에서객관적으로측정될수있다. 마찬가지로 ONOS 에대해서도이와같은연구가진행된다면, 측정된 ONOS 의 Capacity 를본논문의임계치로사용했을때컨트롤러의부하를 Capacity 이하로유지하면서빈번한스위치재배치에따른부담 ( 예 : 마스터쉽이벤트핸들링, 컨트롤러간정보동기화등 ) 을최소화할수있다. 또한스위치를두그룹으로나누는기준으로현재컨트롤러부하의 50% 라는수치를사용하는데, 이는과부화컨트롤러의일부스위치가부하가가장적은컨트롤러하나에재배치시켜컨트롤러간에부하의절반씩을나눠갖는것이이상적임을가정하고있다. Algorithm 2 Switch placement Input : Overloaded-controller, Topology Output : Switch reassignment to other controllers for all switch s in Overloaded-controller c do loadproportion s = load s / controllerload c end for Sort all switches by descending order of the load proportion for all switch s in Sorted switch list do s s 1 if i=0 load i 0.5 > i=0 load i 0.5 then reassignment this switch and remains 16
end if end for for all switch s in reassignment do for all controller c in backups s do Find a controller with lowest load and make it as a master of the switch s controllerload c = controllerload c + load s end for end for 알고리즘 2. 스위치배치알고리즘 그림 2. ONOS 어플리케이션동작원리 ( 점선박스는본연구의추가개발사항 ) 3.2. 프로토타입 (Prototype) 구현 앞서제안한두가지알고리즘의타당성및성능을검증하기위하여 Monitoring Manager 와 Switch Placer 프로토타입을구현하고, ONOS 에배치하여동작여부를확인하였다. 이어플리케이션들은 ONOS web UI [15] 또는 ONOS command line 인터페이스 [16] 를통해 ONOS 에서개별적으로실행되거나종료될수있다. 또한이어플리케이션들은클러스터를이루고있는여러 ONOS 컨트롤러에설치되어각컨트롤러가송수신하는모든컨트롤메시지들을모니터링하고도식화할수있다. ONOS 다중컨트롤러환경을클러스터형태로구축하기위하여 Ubuntu-Server 14.04 버전이설치된호스트에여러개의가상머신을생성하고 ONOS 컨트롤러를배치하였다. 본연구에서는 Virtual Box 를이용해가상머신을생성했지만리눅스컨테이너 [17] 또는 Docker [18] 를사용하여 ONOS 클러스터를구성할수도있다. 컨트롤러에서컨트롤메시지들을모니터링하기위해패킷수집모듈을기존 ONOS 구조의하위계층에추가하였다. OpenFlow Message Monitor 로명명된이모듈은이벤트핸들러로서컨트롤메시지를송수신할때마다트리거 (Trigger) 된다. 이모듈은컨트롤메시지들의종류와개수, byte 크기를스위치별로구분해서다음에소개될패킷정보수집객체에저장한다. Monitoring Manager 어플리케이션의구현과동작원리는다음과같다. 먼저 5 초마다앞서소개된여섯종류의 OpenFlow 컨트롤메시지의 byte 비율 (5 초간누적된 byte 크기 /5) 과 packet 비율 (5 초간누적된패킷개수 /5) 을계산하고그결과값을 Message Entry 라고명명된객체에저장한다. Message Counter 는여섯종류의컨트롤메시지에대응하는 6 개의 Message Entry 를포함하고, 17
Message Entry 에저장된비율값을외부모듈에제공하기위한인터페이스를갖추고있다. 이객체정보들은해쉬맵 (HashMap) 형태의 Message Map 을통해개별스위치단위로관리가가능하다. 이와같이계층화된자료구조를통해스위치또는컨트롤러단위로각컨트롤메시지정보들을적절하게관리할수있다. Monitoring Manager 는이러한정보를활용해 GUI 환경에서컨트롤메시지에대한모니터링환경을제공할수있는데, 이는 ONOS 가제공하는 ONOS web resource API 와연동되어 AngularJS 프레임워크 [19] 위에서동작한다. Message Counter 가제공하는 REST API 를이용해그래프생성에필요한정보들을받아와다음과같은 4 개의그래프를생성한다. (1) 컨트롤러가송수신하는컨트롤메시지들의 packet 비율, (2) 컨트롤러가송수신하는컨트롤메시지들의 byte 비율, (3) 특정스위치가송수신하는컨트롤메시지들의 packet 비율, (4) 특정스위치가송수신하는컨트롤메시지들의 byte 비율. 이때 (3), (4) 의경우에서사용자가보고싶은스위치의식별값 (dpid) 을 ONOS web GUI 를통해선택하면, 즉시해당스위치가송수신하는컨트롤트래픽정보가그래프로보여진다. AngularJS 프레임워크상에서그래프를그리기위해 Ng-Epoch 라이브러리 [20] 를사용했는데이라이브러리는웹환경에서입력되는데이터들을이용하여동적으로그래프를생성하는데도움을준다. 이렇게생성된그래프들은웹브라우저를이용하여 ONOS web GUI 가제공하는화면을통해확인할수있다. 그림 3. 컨트롤러 A 의컨트롤트래픽량 Switch placer 는 Message Counter 의 REST API 를이용해모니터링주기마다갱신되는컨트롤트래픽정보를받아와알고리즘 1 을통해컨트롤러단위의부하정보를구성한다. 이를통해컨트롤러의과부하상태를식별하고, 해당컨트롤러와연결된스위치정보를알고리즘 2 로전달한다. 이과정에서과부하된컨트롤러의스위치일부를부하가가장적은컨트롤러에배치시킨다. 이때, 해당스위치가실제적으로배치가능한컨트롤러의목록을확인하고 Master Role 변경요청을위해서 ONOS Core 의 Mastership 서비스를활용한다. 전체적인어플리케이션의동작원리는그림 2 와같다. 18
4. 결과및검증 4.1. 실험환경 본연구에서제안한제어평면모니터링및스위치배치방법을검증하기위하여우리는 Mininet [21] 을이용하여 OpenFlow 네트워크를구성하였고, 비교대상 (Baseline) 으로 ONOS 에서기본적으로제공하는스위치배치알고리즘 [22] 을선정하였다. ONOS 스위치배치알고리즘은오로지스위치개수만을고려하여각컨트롤러에스위치를할당한다. 예를들어, 15 개의스위치와 3 개의컨트롤러로구성된네트워크에서해당알고리즘을사용하여스위치를배치하면, 각컨트롤러가처리중인컨트롤트래픽량에대한고려없이하나의컨트롤러당 5 개의스위치가할당된다. 실험환경은 Mininet 을사용하여 4 개계위로구성된트리형토폴리지로구성되고, 이는 3 개의컨트롤러, 15 개의스위치와 16 개의호스트를포함한다. 또한호스트사이에데이터트래픽을생성하기위해모든호스트에 Iperf [23] 를설치하였다. 실험초기에는각스위치의플로우테이블이비어있는상태이기때문에스위치는 Iperf 에의하여생성된 TCP 트래픽을수신하면곧바로 Packet-In 메시지를발생시켜 ONOS 에전달한다. 그후에 ONOS 는경로계산을수행하여관련컨트롤메시지를각스위치들로전달한다. 이과정은 Reactive Flow Insertion 으로알려져있으며본실험에서는 ONOS 의 onos.app.fwd 어플리케이션을활성화시켜 Reactive Flow Insertion 을실현하였다. 위 Reactive Flow Insertion 과정을거쳐설치된 Flow Rule 은일정시간동안각스위치에서유지되며인입되는패킷들은설치된 Flow Rule 에근거하여목적지까지전달된다. 본연구의스위치배치방법을검증하기위하여일부스위치들에서더많은양의컨트롤메시지를발생시켜야하는데이를실현하기위하여해당스위치에설치된 Flow Rule 의유지시간을최대로낮추어거의모든인입패킷에대하여컨트롤메시지가발생되게끔설정하였다. 위과정을통하여특정스위치와컨트롤러사이에많은양의 Packet-In/Out, Flow-Mod 등의컨트롤메시지를발생시켰다. 그림 4. ONOS 기본스위치배치알고리즘결과 19
4.2. 실험결과 그림 4 는실험에이용한트리토폴로지를보이고있다. Iperf 를이용하여호스트 10.0.0.5 에서부터호스트 10.0.0.8 로데이터트래픽을발생시켰고, 해당트래픽이경유하는경로에위치한 3 개의스위치는다른스위치에비해많은양의컨트롤트래픽을발생시켰다. ONOS 의기본스위치배치알고리즘을사용하였을경우컨트롤트래픽량을고려하지않은상태에서스위치를배치하기때문에최악의경우위 3 개의스위치가모두컨트롤러 A(192.168.56.101) 에할당되며이는집중적인컨트롤트래픽발생으로인한컨트롤러의과부하를유도했다. 본연구에서제안된스위치배치방법을평가하기위하여위에서소개한실험환경과동일한실험환경에서 Switch Placer 어플리케이션을실행하였다. 그결과컨트롤러 A 에대한부하가임계치를넘어서과부하상태라는것을탐지하고컨트롤러 A 에할당된스위치일부 ( 부하기여도하위 50%) 를상대적으로낮은부하를보이는컨트롤러 B (192.168.56.102) 와컨트롤러 C (192.168.56.103) 로재배치하였다. 그결과그림 5 와같이호스트 10.0.0.5 와호스트 10.0.0.8 의경로상에있는 3 개의스위치가서로다른컨트롤러에할당되어컨트롤러 A 에집중되었던부하가다른컨트롤러로분산되었음을확인할수있었다. 그림 5. 제안된스위치배치알고리즘결과 그림 6 은 ONOS 가기본적으로제공하는스위치배치알고리즘을사용했을때각컨트롤러에할당된컨트롤트래픽부하를 (y 축 ) 보여준다. 그림의 x 축은알고리즘 1 의모니터링알고리즘을실행한시간을나타내며, 25 초마다 Iperf 를통해데이터트래픽을발생시켜서컨트롤트래픽의집중적인증가를유도하고있다. 그림 6 에서는대부분의컨트롤트래픽이컨트롤러 A 로집중되면서컨트롤러간에부하분산이고르게되지않고있음을보인다. 트래픽이집중적으로발생하는시점에서컨트롤러 A 는평균적으로전체네트워크컨트롤트래픽의 85~90% 에달하는부하를받는것으로확인되었다. 이와같이컨트롤러 A 에대한집중적인부하가지속되어과부하상태가되면컨트롤러 A 의패킷처리성능이저하된다. 반면컨트롤러 B 와 C 는충분히활용되지못하기때문에전체네트워크자원활용측면에서비효율적이다. 반면, 그림 7 에서는본논문에서제안한알고리즘을사용했을때, 각컨트롤러별로부하가분배되는과정을보이고있다. 25 초구간에서컨트롤러 A 에가해지는집중적인부하를탐지하고제안된스위치배치알고리즘을실행한다. 이를통해컨트롤러 A 의일부스위치가해당시점 20
에서가장적은부하를받는컨트롤러 C 로배치되고, 그결과 50 초구간에서컨트롤러 C 의부하가증가했음을알수있다. 50 초구간에서컨트롤러 A 와컨트롤러 C 의부하가상대적으로높게유지됨을탐지하고스위치재배치를통해컨트롤러 B 로부하를분배한다. 최종적으로는 100 초와 125 초구간에서 3 개의컨트롤러사이에부하가균등하게분배되었음을알수있다. 그림 7 의실험에서부하가고르게분산된 100 초이후에매 25 초마다전체컨트롤트래픽량을측정했을때, 컨트롤러 A, B, C 는평균적으로각각 34%, 29%, 37% 의컨트롤트래픽부하를나누어가짐을확인하였다. 이는매실험마다알고리즘 2 를통해재배치되는스위치의개수가달라질수있으므로어느정도의비율차이는존재하지만, 비교적균등하게부하가분산되고있음을보여준다. 2000 Controller A Controller B Controller C Control Traffic Rate (byte/s) 1600 1200 800 400 0 20 40 60 80 100 120 Time (s) 그림 6. ONOS 기본스위치배치알고리즘사용시컨트롤러별부하 2000 Controller A Controller B Controller C Control Traffic Rate (byte/s) 1600 1200 800 400 0 20 40 60 80 100 120 Time (s) 그림 7. 제안된스위치배치알고리즘사용시컨트롤러별부하 21
5. 결론 본연구에서는다중컨트롤러로구성된 SDN 환경에서제어평면의성능향상을위한모니터링및스위치배치방법을제안하였다. 제어평면모니터링은컨트롤러와스위치사이에서발생되는모든제어메시지들을컨트롤러별로수집하여분석하는방식으로실현되었고, 과부화상태로탐지되는컨트롤러의일부스위치를다른컨트롤러에재배치함으로써제어평면의부하분산을도모하였다. 이를통해네트워크관리자는 GUI 환경에서컨트롤러의부하상태를보다쉽게파악할수있고, 제어평면에서발생하는부하를여러컨트롤러들에평형시킬수있어전체제어평면의성능을향상시킬수있다. 제안한방법의가용성 (Availability) 을보이기위해앞서소개한방법을구현한 Monitoring Manager 와 Switch Placer 어플리케이션을 ONOS 컨트롤러에설치하였다. 또한스위치배치방법의성능을검증하기위하여 ONOS 의기본스위치배치방법을사용하였을경우와본연구에서제안한새로운스위치배치방법을사용하였을경우, 전체제어평면의부하평형도 (Balance ratio) 가어떻게변화하는지비교하였다. 마지막으로는본논문을확장시키기위한향후연구방향은다음과같다. 먼저제어평면모니터링환경에서그래프의종류를보다다양화하고직관적으로이해할수있는형태로발전시켜네트워크관리자에게보다유용한모니터링환경을제공하고자한다. 다음으로부하분산을위한스위치배치알고리즘을개선하고자한다. 네트워크상황에따라부하분산을위한빈번한스위치재배치과정이오히려컨트롤러에부담을주어서성능을저하시키는부작용을초래할수도있다. 따라서부하분산의이점과스위치재배치에따른비용을고려하는, 보다동적이고효과적인스위치배치알고리즘으로개선될여지가남아있다. 6. 감사의글 본연구는미래창조과학부및정보통신기술진흥센터의정보통신 방송연구개발사업의일환으로수행하였음. [R0126-15-1009, ICBMS 플랫폼간정보모델연동및서비스매쉬업을위한스마트중재기술개발 ] 7. 참고문헌 [1] Pankaj Berde, Matteo Gerola, Jonathan Hart, Yuta Higuchi, Masayoshi Kobayashi, Toshio Koide, Bob Lantz, Brian O Connor, Pavlin Radoslavov, William Snow, Guru Parulkar, ONOS: Towards an Open, Distributed SDN OS, in HotSDN, 2014 [2] Open Networking Foundation, OpenFlow Switch Sepcification Version 1.0.0 (Wire Protocol Ox01), 2009, available at: https://www.opennetworking.org/sdn-resources/technical-library. [3] Zhiyans Su, Ting Wang, Yu Xia and Hamdi, M., FlowCover: Low-cost flow monitoring scheme in software defined networks, in GLOBECOM, 2014 [4] C. Yu, C. Lumezanu, Y. Zhang, V. Singh, G. Jiang, and H. V. Madhyastha, "FlowSense: monitoring network utilization with zero measurement cost", in PAM, 2013 [5] S. R. Chowdhury, M. F. Bari, R. Ahmed, and R. Boutaba, "PayLess: A Low Cost Network Monitoring Framework for Software Defined Networks", in NOMS, 2014 [6] PH Isolani, JA Wickboldt, CB Both, J Rochol, Interactive Monitoring, Visualization, and Configuration of OpenFlow- Based SDN, in IM, 2015 [7] Soheil Hassas Yeganeh, Yashar Ganjali, Kandoo: a framework for efficient and scalable offloading of control applications, in HotSDN, 2012 [8] Tootoonchiaan, Amin, Yashar Ganjali, HyperFlow: A distributed control plane for OpenFlow, in NM/WREN, 2010 [9] T. Koronen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, and S. Shenker., Onix: a distributed control platform for large-scale production networks, in OSDI, 2010 [10] Natasha Gude, Teemu Koponen, Justin Pettit, Ben Pfaff, Martin Casado, Nick McKeown, and Scott Shenker, NOX: towards an operating system for networks, in SIGCOMM, 2008 [11] Yannan Hu, Wendong Wang, Xiangyang Gong, Xirong Que, On Reliability-optimized Controller Placement for Software-Defined Networks, in Communications China, 2014 [12] Brandon Heller, Rob Sherwood, Nick McKeown, The Controller Placement Problem, in HotSDN, 2012 [13] Md. Faizul Bari, Arup Raton Roy, Shihabur Rahman Chowdhury, Qi Zhang, Mohamed Faten Zhani, Reaz Ahmed, 22
Raouf Boutaba, Dynamic Controller Provisioning in Software Defined Netwroks, in CNSM, 2013 [14] A. Tootoonchian, S. Gorbunov, Y. Ganjali, M. Casado, and R. Sherwood. On controller performance in softwaredefined networks, In Hot-ICE, 2012 [15] ONOS wiki page, The ONOS Web GUI, https://wiki.onosproject.org/display/onos/the+onos+web+gui/ [16] ONOS wiki page, The ONOS CLI, https://wiki.onosproject.org/display/onos/the+onos+cli [17] Linux Containers, https://linuxcontainers.org/lxc/introduction/ [18] ONOS wiki page, Running the published Docker ONOS image, https://wiki.onosproject.org/display/onos/running+the+published+docker+onos+images/ [19] AngularJS, HTML enhanced for web apps, https://angularjs.org/. [20] NG-Epoch, Simple charting for AngularJS, http://dainbrump.github.io/ng-epoch/ [21] Mininet, An Instant Virtual Network on Your Laptop, http://mininet.org/ [22] ONOS GitHub, MastershipManager.java, https://github.com/opennetworkinglab/onos/blob/de77ee513d5077c00edd798a9900979356cc1cb8/core/net/src/main/jav a/org/onosproject/cluster/impl/mastershipmanager.java/ [23] Iperf, The TCP/UDP Bandwidth Management Tool, https://iperf.fr/ 정세연 2015 경북대학교, 컴퓨터학부학사 2015 ~ 현재포항공과대학교, 컴퓨터공학과통합과정 < 관심분야 > SDN, OpenFlow, 네트워크관리 이도영 2015 건국대학교, 컴퓨터공학부학사 2015 ~ 현재포항공과대학교, 컴퓨터공학과통합과정 < 관심분야 > SDN, OpenFlow, 네트워크트래픽모니터링 리건 2007 연변과학기술대학교, 전자통신공학과학사 2012 포항공과대학교, 컴퓨터공학과석사 2012 ~ 현재포항공과대학교, 정보전자융합공학부박사과정 < 관심분야 > SDN, OpenFlow, 클라우드컴퓨팅, 모바일장치관리, 스마트그리드 23
유재형 1983 연세대학교전자공학과학사 1985 연세대학교전자공학과석사 1999 연세대학교컴퓨터공학과박사 1986 ~ 2012: KT 네트워크연구소 2012 ~ 2013: KAIST 전기및전자공학과연구부교수 2013 ~ 현재 : 포항공과대학교컴퓨터공학과연구부교수 < 관심분야 > 네트워크관리및보안, SDN, OpenFlow 홍원기 1983 Univ. of Western Ontario, BSc in Computer Science 1985 Univ. of Western Ontario, MS in Computer Science 1985 ~ 1986 Univ. of Western Ontario, Lecturer 1986 ~ 1991 Univ. of Waterloo, PhD in Computer Science 1991 ~ 1992 Univ. of Waterloo, Post-Doc Fellow 1992 ~ 1995 Univ. of Western Ontario, 연구교수 1995 ~ 현재포항공과대학교, 컴퓨터공학과교수 2007 ~ 2011 포항공과대학교, 정보통신대학원장 2007 ~ 2010 포항공과대학교, 정보통신연구소연구소장 2008 ~ 2010 포항공과대학교, 컴퓨터공학과주임교수 2008 ~ 2012 포항공과대학교, 정보전자융합공학부장 2012 ~ 2014 KT 종합기술원, 원장 < 관심분야 > 네트워크트래픽모니터링, 네트워크및시스템관리 24