Skip to main content

SDN(OpenFlow) 개요

OpenFlow는 SDN(Software Defined Network)의 하나의 콤포넌트이다.


아래는 2013/3/13 오픈프로우 코리아 주최로 열린 한국 SDN Interest Group 4번째 정기세미나의 내용이다. 다음에는 꼭 모임에 참석하고 싶다.



SDN Architecture including OpenFlow

위 그림에서와 같이, Control Layer부분과 Application Layer부분이 최근 활발히 연구개발되고 있다. 그 중 Control Layer부분은 Controller가 많은 비중을 차지 하는데, 다음 절에서와 같이 이미 많은 벤더들이 많은 OpenFlow 기반의 Controller를 제공하고 있다. 그외 소규모 벤더들은 Controller가 아닌 Application Layer에서 보안, 로드벨런싱, 홈네트워크 등의 서비스가 지원되는 제품 개발에 힘쓰고 있다.

SDN에서는 Router라는 명칭 대신, Switch라는 명칭을 사용하는데, 이는 Router보다 더 단순한 기능을 수행하고, 기존 레거시와 차별화를 위해 명명된 것으로 보인다.
또한, Switch를 반드시 벤더로부터 구매할 필요가 없다. 상황에 따라 리눅스 등의 운영체제를 기반으로 자체 개발이 가능하다.


Controllers의 종류

SDN의 Controller 가운데 Open Source로 운영되는 것은 다음과 같다. 대부분 Java언어로 구현되어 있다. 따라서 플랫폼 또는 인프라 개발자라면 Java에 능숙해야 한다.
  • NOX
    • C++/Python
  • Beacon
    • Java
  • Floodlight
    • Java
  • Maestro
    • Java
  • RouteFlow
    • NOX, Quagga

보안을 위한 Open Source

  • FortNOX
    • Java 기반의 SE-FloodLight
      •  공격 감지
      •  인증
      •  스위치의 Flow 처리 성능 고려
  • FRESCO
    • OpenFlow Controller와 OpenFlow application 사이에서 빠른 보안 이슈 감지 모듈
    •  그리고 보안 서비스의 효과적으로 적용하기 위한 Open Flow application framework
  • Resonance
    • NOX와 OpenFlow를 사용하는 NAC(Network Access Control) application
  • Security Requirements in the SDN Model
    • IETF에서 제안중인 프로토콜로, Open Flow와 같이 SDN controller 혹은 application 사이에 추가 기능을 전제로 함
  • Cloud Management Platform(CMP)
    • OpenStack의 Quantum
    • Stateful Firewall등의 보안 기능
    •  LBaaS(Load Balancing as a Service)

Open Networking User Group에 의한 SDN의 5가지 권장사항


  • Open Network는 상호 호환이 가능해야 한다.
  • Open Network는 벤더에 종속되지 않고, 독립적이어야 한다
  • Open Network는 Northbound형식으로 자유롭게 프로그래밍이 가능해야 한다
  • 네트워크의 가시화와 모니터링이 가능해야 한다
  • Open Network는 비지니스 모델이 필요하다







SDN의 과제


http://www.ddaily.co.kr/news/news_view.php?uid=105141
위 사이트에서와 같이, SDN는 현재 개발과 테스트베드 하에 있다.

문제점들은 다음과 같다.

  1. 현재 기술 수준의 SDN으로는 기존 레거시 네트워크를 대처할 만한 비용 절감 효과를 보기 어렵다. 따라서, 충분한 기술 확보와 평가 등이 완료되어야 하고, 그 시점에서는 현재 비용보다 약 50%정도 절감 효과를 볼 수 있다. 아직 갈 길이 멀다는 얘기이다.
  2. 현재 개발이 완료된 controller와 appllication의 가격 단가가 고가이다보니, 초기투자비용이 많이 든다. 뿐만 아니라 운영비용 또한 많이 드는데, 이는 관리 자동화와 설정 또는 트러블 발생률을 기존 레거시 수준까지 올려야 비용 절감 효과를 볼 수 있다.


요약

SDN의 최대 장점은, 유연성이다. 각 환경에 맞게 controller와 application 개발 및 설정이 레거시보다 현저히 유연성을 가진다는 점이다.
하지만, 오픈플로우 스위치에서의 플로우 테이블 폭증 또는 다중 컨트롤러 간의 메시징 처리 성능 문제해야 하며, 스위치 벤더 간의 호환성 문제 또한 차후 과제로 본다.



이 페이지에서는 OpenFlow와 SDN에 관한 전반적인 개념을 소개했다.
다음 페이지에서는 OpenFlow의 Tutorial를 통해 개념을 더욱 확고히 쌓아가보자.



참고문헌

http://OpenFlow Korea 제4 정기세미나#1

Labels:

Comments

Post a Comment

Popular posts from this blog

맥OS 사전에 사전 파일 추가하기

1. http://code.google.com/p/mac-dictionary-kit/에서 sdconv를 다운로드 받는다. 2. e4u 등과 같은 사전 파일(stardict 형식)을 다운받는다. 3. 사전 파일의 압축을 풀면, e4u.ifo, e4u.dict.dz, e4u.idx와 같은 파일이 보인다. 4. sdconv 디렉터리 내의 convert 실행 파일로 convert e4u.ifo를 실행한다. 5. 위 과정이 완료되면 아래와 같이 사전에 e4u가 추가된 점을 확인할 수 있다. 6. 순서를 조절하여 사용하면 된다.
Post a Comment
Read more

Sqlite database is locked

sqlite는 embedded system에서 널리 사용되는 무료 dbms?(dbms라고 말하긴 좀 그렇지만, dbms라 불러주자 ㅎ) 이다. 특히 memory db 기능이 아주 유용하다. 그 밖의 dbms에서도 이 기능이 있으나, 이 기능이 지원되는 버전은 대부분 고가이다. 따라서, 무료인 sqlite를 많이들 애용하는 것 같다. 멀티쓰레드를 sqlite DB를 구현하고 롱런테스트를 하다보면, pthread_mutex_lock으로 쓰레드 간의 교착상태를 막아줘도, sqlite lock 에러가 간헐적으로 발생할 것이다. 이에 대해 본인은 다음과 같은 에러 처리 구문을 준비하여 사용하고 있다. sqlite Error가 발생하면, sqlite3_exception함수를 호출한다. 이 함수에서 sqlite error code를 구분하여, 만약, busy 또는 locked이면 최대 2초간 sleep 상태로 만드는 sqlite3_busy_timeout, busy handler를 호출한다. 그 다음, goto 구문으로 재차 sqlite3_exec를 실행한다. 단, sqlite3_exec는 transaction의 begin과 commit 또는 rollback 구문 사이에서 실행한다. 대부분 lock 에러가 발생하더라도 1~2번 실패 후에, 처리된다는 것이 본인의 테스트 결과이다. 단, journal를 WAL로 변경하였음. 기존 journal은 멀티쓰레드 지향적이지 않다는 점을 잊지마시길.... Error Code SQLITE_LOCKED (6): Database Is Locked This error code occurs when you try to do two incompatible things with a database at the same time from the same database connection. For example, if you are in the middle of a SELECT statement and you t
Post a Comment
Read more

SAStruts란

SAStruts 개요 Struts는 Spring Framework 다음으로 많이 사용되고 있는 FrameWork이다. Struts는 프레임워크로 강력한 기능을 제공한다. 하지만, 개발 과정에서 부수적인 설정 작업이 개발자들을 힘들게 했다. 이 문제를 해결하기 위해, 일본 개발자 커뮤니티 Seasar(일본 오키나와의 전설 동물, 우리나라의 해태와 비슷^^) 에서 개발한 프레임워크가 SAStruts(Super Agile Struts)이다. 아래 아키텍처 그림과 같이, SAStruts의 모태는 Struts이다. 다만, 상기한 복잡하고 까다로운 설정 작업을 그림2와 같이 SAStruts가 개발자 대신 내부적으로 처리해 준다. 예를 들어, Struts는 항상 struts-config.xml을 읽고 Action 클래스를 호출한다. 이 때문에, 개발자는 소스 코드를 수정한 후, 늘 struts-c onfig.xml 파일을 검토 또는 수정해야 한다. 또한, 대형 프로젝트일 경우는, 이 struts-config.xml 파일이 경합을 자주 일으킨다. 이는 실로 개발자의 스트레스 치수를 높이는 원인이다. 반면, SAStruts는 이 번거로운 작업을 알아서 처리해 준다. 아리가또~~~ 입니다. 그림1 Struts 아키텍처 그림2 SAStruts 아키텍처 그럼, 이 번거로운 작업을 SAStruts는 어떻게 처리하는 것인지 궁금할 것이다. 그것은 Java의 annotation기술을 이용한 점이다. 예를 들어, @Execute, @ActionForm, @Resource 등 Seasar 커뮤니티에서 제공하는 Dolteng 플러그인을 사용하면, SAStruts 개발이 더욱 효율적이다. SAStruts 프로젝트는 다음과 같은 패키지 구조로 형성된다. [root package].action Action 클래스 [root package].condition 데이터베이스에 엑세스하는 조건 설정 [root packa
Post a Comment
Read more