DevOps2015.04.23 07:58

ari_pingrange.py

IP_Info.py

브로케이드 , DevOps , NFV , SDN : Today Key

 

브로케이드 웨비나 < DevOps함께 NFV와 SDN을 실현합니다> 를 그저께 들었습니다.

업무시간이라서 처음부터 끝까지 경청할 수 있는 상황은 아니었지만,

진행된 세션 중의 기록해 둘만한 장표가 있어서 블로그에 올려봅니다.

 

 


미래 네트워크 결정 요소
 ▷ 자동화 - 적응성, 네트워크 민첩성
 ▷ 개방성 - 오픈소스 및 표준 데이터 모델 지원
 ▷ 표준 노스바운드 및 사우스바운드 인터페이스
 ▷ 프로그래밍 가능성 - 제어
 ▷ RESTful 인터페이스 및 YANG 데이터 모델
 ▷ 신속한 개발, 개발 방법에 대한 고객의 의견에 부합하도록 엔지니어링 프로세스(문화)정비

 

SDN/NFV를 위한 DevOps 구축 필요
  ▷네트워크 팀에는 프로그래머가 거의 없으며, 주로 프로그래머가 아닌 직원들로 구성
  ▷ 앱 개발자들은 네트워크 엔지니어가 아님
  ▷ 프로그래머의 bottleneck을 피해야함
  ▷ 정보의 체계화 필요
  ▷ 프로그래머가 아닌 직원들의 생산성을 높이십시오
  ▷ 빨리 시작하는 것도 중요하고 그것보다 더 중요한 것은 지속적인 투자/관심

 


  

Posted by 네떡지기
분류없음2014.12.14 04:16

 


이번에는 Cisco OnePK에 대한 아주 간단한 소개와 앞으로 포스팅 하게 될 OnePK에 대한 예제 내용들입니다.

이번 포스팅에서는 OnePK로 할 수 있는 예제 결과에 대해서만 간략하게 보여드리고,

이후 포스팅부터는 OnePK에 대한 좀 더 기술적인 내용과 함께

이번 포스팅에 보여드린 예제에 대해서 코드와 함께 좀 더 자세히 살펴보도록 하겠습니다.

 


 

Cisco OnePK (Platform Kit)

 

 ○ OnePK 란?

     - Cisco Open Network Environment SDN 전략 요소

     - 개발/자동화/빠른 서비스 생성 등의 작업을 손쉽게 하게 도와주는 툴킷

     - 다양한 언어(C, Java, Python)를 사용할 수 있도록 API를 제공

     - API를 사용하여 비즈니스 요구에 따른 확장, 변경 등의 다양한 작업 가능.

 

 

 ※ Cisco OnePK Site : https://developer.cisco.com/site/onepk/index.gsp

 

 

 ○ OnePK를 사용한  예제 1

     - Network Element(Device)에 접속하여 다양한 속성값을 가져올 수 있다.

 

 

 

 ○ OnePK를 사용한  예제 2

     - Network Element(Device)의 정보를 가져와서 확인할 수 있다. 

- Network Element의 실제 Interface 정보 -

 

- OnePK를 사용하여, Interface 번호와 Description을 가져온 결과 -

 

 

 ○ OnePK를 사용한  예제 3

     - Network Element의 설정을 OnePK에서 제공하는 API를 통해서 변경 ( Interface Descpriton 변경)

 

 

 

 

 

 ○ OnePK를 사용한  예제 4

     - Network Element에 직접 CLI 명령을 통해서 정보 확인 및 Config 설정

 

- CLI 명령을 통해서, 현재 정보를 출력하고, Loopback Interface를 생성 후, 동일한 정보를 출력하여 확인 -

 

 

● Cisco OnePK에 대한 소개 정보는 솔라구구님 블로그를 참조하셔도 좋습니다.

   : http://sola99.tistory.com/208

 

 

Posted by 네떡지기

 


SDN 관련 두 번째 포스팅입니다.

 조금 더 빨리하고 싶었으나, 이런 저런 일들과 무수한 삽질(?)을.. 하는 바람에 생각보다는 조금 늦어졌습니다.

 

 이번 포스팅은 지난 번에 설치한 Mininet 환경 구축을 실제로 아주 간단하게 테스트하는 내용입니다.

 별도의 OpenDayLight라는 OpenFlow Controller를 설치해서, Mininet으로 만든 구성을 OpenDayLight를 통해서 확인해봅니다.

 

아래 구성의 구성인

 

  OpenDayLight (Controller)/  mininet

 

은 각각 별도의 VM으로 구성하였으며, OpenDayLight의 경우에는 Ubuntu를 OS로 사용하였습니다.

  


 

먼저 OpenDayLight를 설치하겠습니다.

 

설치 파일은 http://www.opendaylight.org 에서 다운로드 받으실 수 있습니다.

 

 

 중앙에 보시면, DOWNLOAD NOW가 있습니다.  

 

 

 다운로드 페이지에서 보시면, Pre-Built Zip File이 있습니다.

 Pre-Built Zip File을 다운 받습니다. 이미 구성이 다 되어 있는 패키지 파일로, 다운 받아서 압축을 푸시고 실행만 하시면 됩니다.

 

 

약 45M정도의 파일을 모두 다운 받으시고, 압축을 풀어서, 해당 폴더로 이동하신 후에

 

 

run.sh 을 실행하면 됩니다.

그러면, 이런 저런 로그가 꽤 여러줄 올라오게 됩니다.

실제 로딩되는 데, 시간이 조금 걸립니다. 1~2분정도..

로딩이 완료되면, http://IP주소:8080 으로 접속하시면 아래와 같이 초기 화면이 뜨게 됩니다.

 

 

접속 계정은 ( admin / admin ) 입니다.

 

 

자, 이제 Controller의 준비가 끝났으니 Mininet으로 가상의 Lab을 구성해보겠습니다.

mn --controller==remote,ip=10.1.1.50,port=6633 --topo tree,2

라고 실행해봅니다.

 여기서, Controller 옵션은 Controller을 지정하고자 할 때 사용하는 옵션이며, 저는 Opendaylight를 10.1.1.50이라는 IP의 VM에서

구성하였기 때문에, IP는 10.1.1.50이 되며, Controller는 기본적으로 6633 포트를 사용합니다.

 그리고, Topo 옵션은 어떤 Topology를 구성할지에 대한 부분인데 우선 여기서는 간단하게 이미 정의된 Tree 형식의 Topology를

구성하였습니다. 뒤에 붙은 2는 Tree의 깊이를 나타내는 옵션입니다.

 어떤식으로 Topology가 만들어지는 말로 설명하는 것보다는 Controller에서 보여지는 그림을 보시는 것이 이해가 편하기 때문에

아래 그림을 보시면 됩니다.

 

자, 이제 mininet으로 구성한 첫 번째 Topology가 위와 같이 나타났습니다.

Tree 형식의 2단계가 어떤식으로 구성되었는지 아시겠죠?

하지만, 위에 보시면 분명 Host가 생성되었는 데, 보이지를 않습니다.

 

그럼 Mininet에서 pingall 이라는 명령을 하면, 모든 Host간의 Ping테스트를 하게 됩니다.

pingall의 결과를 보면, 전체 Host의 통신이 정상적으로 되고 있다는 것을 알 수 있습니다.

(첫 번째 pingall을 하면.. 일부 통신이 안되는 부분이 나올 수 있기는 하지만, 다시 해보면 정상적으로 통신 결과를 볼 수 있습니다.)

 

 

 

 Host의 통신 체크를 하면, 위와 같이 Host까지 모두 구성된 Topology를 볼 수 있습니다.

처음에 보여졌던, 스위치의 이름이 모두 OF1~3으로 바뀐 것은 자동으로 바뀌는 것은 아니고,

좌측의 Nodes Learned 화면에서 Node Name을 클릭해서 직접 바꾸시면 됩니다.

 

이제 간단한 테스트를 해보려고 합니다.

그 전에, node라는 명령과 dump라는 명령을 mininet에서 해보면 위와 같은 결과를 볼 수가 있습니다.

node라고 치게 되면, 각 Host와 Switch가 어떻게 연결이 되어 있는지 볼 수 있습니다.

Topology에서만 보면, 어떤 Interface로 각 Host와 Switch가 연결되어 있는지 확인이 안되기 때문에 이처럼 node라는 명령으로

확인할 수 있습니다.

 

dump 명령으로도 전체적인 구성 정보를 볼 수 있습니다. 여기서는 각 Host의 IP정보, Switch의 Interface 정보, Controller 정보를

한 번에 모두 볼 수 있습니다.

 

위의 내용에서 Interface 정보를 가지고, Controller에서 Flow를 생성해서 내려보는 테스트를 하려고 합니다.

먼저 위에서 H1와 H2간의 통신이 되는 것을 위와 같이 볼 수 있습니다.  (h1 ping h2)

 

OpenDayLight의 Flows 메뉴를 선택하시면,

Flow Entries를 볼 수 있습니다.

우선 여기서 Add Flow Entry를 클릭하면 아래와 같이 Flow 정책을 만들 수 있는 팝업창이 뜨게 됩니다.

 

 

 

Flow Entry 이름을 지정하고, 어떤 Node(Switch)에 내릴 것인지 지정합니다.

여기서는 Host 1, 2가 연결된 OF2 Switch를 선택했습니다.

그리고, 해당 Flow가 동작할 Input Port는 Host 1과 연결된 eth1을 선택합니다.

(이 Interface정보는 위의 Node나 Dump로 확인할 수 있습니다.)

 

스크롤바를 내리면 다양한 인자값을 선택해서 Flow를 만들 수 있는 것을 볼 수 있습니다.

위의 화면은 Layer 2에 대한 내용이네요. 저는 Layer 2에 대해서는 default 상태로 두겠습니다.

 

 

Layer 3 옵션에서는 Destination IP Address를 Host 2의 IP인 10.0.0.2로 지정합니다.

 

 

마지막으로 어떤 Action을 취할지에 대해서 선택하는 것이 있는 데, 다양한 Action이 있지만

저는 여기서 Drop으로 해보겠습니다.

모두 다 만들어지면, Install Flow로 바로 Switch 2에 Install 할 수도 있고 혹은 Save Flow로 우선 Flow를 저장만 할 수도 있습니다.

저는 Save Flow를 클릭하였습니다.

 

 

 Flow를 만들고 나면, 좌측에는 Flow의 이름과 어떤 Node에 적용되는 Flow인지 나오고 해당 Flow를 클릭하면,

 우측에는 해당 Flow의 세부 정보를 볼 수 있습니다.

 Flow Detail에서는 Flow를 Remove / Edit / Install 할 수 있습니다.

 이제 실제 적용하기 위해서 Install을 클릭합니다.

 Install을 하게 되면, Controller에서 생성된 Flow가 OF2 Node로 보내지게 됩니다.

 

해당 Flow를 적용하니, h1에서 h2로는 통신이 끊긴 것을 볼 수 있습니다.

그리고, h3로의 통신을 확인하면 h3과는 통신이 정상 상태입니다.

Flow가 h2로 가는 경우에만 막혀있기 때문입니다.

물론 OF2 Node에만 적용하였기 때문에 h3,h4 에서는 h2로 통신이 가능합니다. 

혹은 OF2의 또 다른 Interface가 존재하고 해당 Interface에 h5가 존재할 경우에도 통신이 가능합니다.

(h1과 연결된 interface에 대해서 flow를 적용하였기 때문에..)

 

위의 Troubleshoot를 보시면, 실제 각 Node의 Flow Table과 적용된 내용을 볼 수 있습니다.

실제 위에서 만든 h1과 h2간의 Drop하는 정책이 정상적으로 동작했는지 보려고 합니다.

Existing Nodes에서 OF2의 Flows 를 클릭하면

우측 하단에 Flow Table이 보이고, 스크롤을 제일 아래로 내리니 위에서 만든 Flow Table이 보입니다.

현재 81 이라고 써진 부분이 실제 적용된 count입니다.

 

 

 

 

 Test를 위해서 다시 한 번, h1과 h2간의 ping 체크를 합니다.

 제일 마지막에 체크한 부분만 보시면 됩니다. 제일 마지막에 18번의 전송이 이뤄졌고, 100% Loss입니다.

 

 

다시 OpenDayLight에서 보시면, 81이었던 count가 99로 바뀌었음을 볼 수 있습니다. ( 81 + 18 = 99)

정상적으로 만들어진 Flow가 동작했음을 확인할 수 있습니다.

 

 

 


이번에는 지난 포스팅에서 잠시 실행만 해보았던 miniedit를 이용해서

Topology를 만들고 이를 Controller에서 확인하겠습니다.

 

 

위와 이 miniedit.py를 실행합니다.

 

 

 

좌측의 아이콘을 이용하여 위와 같이 구성하였습니다.

 

제일 상단이 Controller이고, 아래에는 OpenFlow를 지원하는 Switch1~3이 있고, 각각의 Switch에는 h1 ~ h3까지 Host가 있습니다.

  

 

 

Controller에서 우측 버튼을 누르고, 속성을 지정하여

1. Controller IP를 지정하고,

2. Type을 Remote Controller로 설정합니다.

 

 

 

설정을 마치면, Run 버튼을 눌러서 해당 Topology를 실행합니다. 

 

 

 실행한 이후에, h1에서 마우스 우클릭을 하여 Console창을 열어서 h2와 h3과의 통신 상태를 확인해 볼 수 있습니다..

 

 

 

 

다시 OpenDayLight에서 보면, miniedit로 구성한 Topology가 정상적으로 보이는 것을 확인할 수 있습니다. 

 

마찬가지로 여기서 Flow 적용하는 Test를 해볼 수도 있습니다.

 

그리고 꼭 miniedit를 이용하지 않더라도 Node를 코드를 수정하여 원하는대로 만들 수도 있습니다.

이 부분은 나중에 다루게 될런지... 어떨런지.. 모르겠네요. ^^;

 

그럼 다음 포스팅에서 다시 뵙겠습니다.

 

Posted by 네떡지기

새로운 주제의 포스팅이 시작됩니다.

이번 주제는 SDN과 관련된 내용의 포스팅으로 진행될 예정입니다.

얼마나 많은 내용이 담길지 모르겠지만... ^^; 우선 시작해봅니다!

우선 첫 번째 포스팅으로는 SDN 환경을 시뮬레이션을 할 수 있는 Mininet 이라는 환경을 구축해보는 포스팅입니다.

 

Mininet에 관련된 사항은

 

    http://mininet.org/

 

로 가시면 볼 수 있습니다.

 

Mininet을 구성하는 방법에는 3가지가 있습니다.

 

1. Mininet VM Installation

2. Native Installation from Source

3. Installation from Packages

 

포스팅에서 다룰 내용은  mininet.org에서 추천하는 1번입니다.

추천하는 이유는 제일 쉽기 때문이지요

 (VM installation is the easiest and most foolproof way of installing Mininet, so it’s what we recommend to start with.)

 

설치를 위해서 우선 이미지 파일을 받으러 가야합니다.

 

https://github.com/mininet/mininet/wiki/Mininet-VM-Images

 

위의 링크로 가시면, 2014년 8월 8일 현재 기준 Ubuntu 14.04 / Mininet 2.1.0 으로 된, VM Image를 다운 받을 수 있습니다.

 

파일을 다운받은 이후부터 실행하는 방법까지 이번 포스팅에서 다뤄집니다.

 

전 과정을 모두 캡춰를 떴으니~ ^^ 한 장씩 따라오시면 금방 구축할 수 있습니다!

 

Virtual BOX를 추천하지만~ 저는 VMWare에서 해보도록 하겠습니다.

 

 

VMWare에서 시작해봅니다.
전 Advanced로 시작합니다!

 

Next!

 

우선 설치는 나중으로 미룹니다.

 

Ubuntu 이미지이므로, Linux Ubuntu로 설정합니다.

 

적절하게 VM이 구성될 이름과, 위치를 잡아줍니다.

 

여기도 Default로 Next!

 

전 메모리를 2048로 잡았습니다.

 

요것도 뭐 우선 사실 크게 중요하지 않습니다~ ^^

Host-only로 잡아주셔도 무방합니다.

 

이것도 Default로 Next.. 

 

 

이것도 Default로 Next.. 

 

 

Disk는 이미 받아놓은 이미지가 있으니, 이미 존재하는 Virtual Disk로 선택합니다. 

VM 9.0 버전에서는 이 부분이 초기에는 안보이는 듯 한데.. 그럴 때는 기본 설정으로 만들어진 다음에..

모든 설정이 끝난 이후에 edit해서.. 기존 하드를 삭제하고 새롭게 추가하면.. 지금 메뉴처럼 기존 Virtual Disk를 선택할 수 있습니다.


 

 

Mininet.org를 통해서 다운받은 이미지 파일을 선택합니다. 

 

걍 Convert Go!. 

 

드디어 완료되었습니다.

 

자 이제. VM을 실행해보도록 하겠습니다.. 

 

 

 

실행하고 나면, 위와 같이 나오게 됩니다.

계정은 ( mininet / mininet ) 입니다. 모두 소문자! 

 

 

Mininet을 실행하는 건... 위와 같이 

mn 명령으로 실행할 수 있습니다.

실행 시에

Host 2개, Switch 1개, Controller 1개로 구성됩니다.

위에 보시면, Available Node로 해당 내용을 볼 수 있습니다.

해당 구성은 변경이 가능하며, 그 부분은 다음 포스팅에서 다룰 예정입니다.

 

 

 

다음은 Topology를 구성하는 방법 중에 miniedit를 실행하는 방법입니다.

뭔지는 다음에 알아보도록 하고. 우선 실행만 해보는걸 알아봅니다.

 

mininet/examples에 가면, miniedit.py 를 실행해서 GUI환경으로 Topology를 구성할 수 있습니다.

본 포스팅에 의도에 맞춰서 우선 환경만 구축해봅니다.

 

자! 그럼 우선 해당 위치로 가서, 실행해보도록 하겠습니다.

 

 

음 그런데 실행을 하려고 보니... 실행이 되지 않네요...

어떻게 해야하나요?

 

아래와 같이 추가적으로 패키지를 설치해줍니다.

 

 

 

# apt-get update

 

 

 

# apg-get install xinit flwm

 

이 때, xinit의 경우에는 3가지 옵션이 있지만... 저는 flwm으로 합니다.

그냥 따라하는 포스팅이므로~ 똑같이 하시면 됩니다!  ^^;

 

 

 

패키지를 주루륵 설치하게 됩니다.
Y를 눌러서~ 설치를 하시면 됩니다.

 

 

 

자, 이제 설치가 끝나면 xwindow를 띄웁니다.

# startx

 

 

아까 설치할 때, 3가지 옵션 중에 2번째 옵션은... 보셨다시피 용량이 크지 않은 컴팩트한 버전으로 구성된 것입니다.

그래서 화려한 GUI를 구현해 주지는 않습니다. 그렇다고 Full로 설치하는 3번째 옵션을 쓰게 되면...

엄청난 용량의 파일을 다운 받아야하고... 한숨 자고 와야 할지도 모르는... 현상을 보실지도... (쪽잠.. )

 

자자 암튼.. 위와 같이 Bash Shell을 띄웁니다.

 

Bash Shell에서.. 아까 실행하지 못한 miniedit.py를 실행하면, 화면 하단의 그림판 처럼 생긴 GUI형식의 Edit 프로그램이 뜨게 됩니다.

왼쪽의 아이콘 중에 모니터처럼 생긴게 "HOST", 굵은 가로줄이 "SWITCH", 파란색 대각선이 "LINK"를 의미합니다.

각 구성요소로 다양한 Topology를 만들어 볼 수 있게 됩니다.

만든 이후에는 아래의 Run 버튼을 눌러서 해당 Topology를 활성화 할 수 있습니다.

 

 

자~ 여기까지 SDN/OpenFlow를 테스트 할 수 있는 Mininet 환경을 구성해 보았습니다.

 

다음에는 이 Mininet을 활용한 Topology를 원하는데로 구성해보기...

Controller와 연동하기 등을.... 진행하도록 하겠습니다.

 

이것 저것... 포스팅 시리즈를 벌여놓기만 하고.. 중간에 끊기고 있기는 하지만. ^^;

그래도 지속적으로 노력하겠습니다.

 

Posted by 네떡지기
분류없음2013.12.31 01:17

 연말 부서 세미나용으로 급히 만든 자료입니다.

 기존 부서세미나에 했었던, SDN/Openflow 자료에 업데이트 + 몇가지 내용을 추가했습니다.

 

 맘에 드는 정도는 아니지만..(만들다가... 귀차니즘 폭발..) 도움이 되실분이 한 분이라도 계실까봐. ^^;

 블로그에 올려놓습니다... (네전따에 올리기엔 부끄러워서... )


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted by 네떡지기

NFV에 대해서 간략하게나마 정리를 시작합니다.

잘못된 부분이나, 추가/보완할 내용이 있으시면 덧글 부탁드리겠습니다.

추가/보완되는 내용이 있으면 업데이트 하도록 하겠습니다.

 

 - 초기작성 : 2013. 09.21

 - Last Update : 2013. 09.21

 


 

NFV (Network Function Virtualization)

   - 기존 Hardware Appliances들로 구현된 Route, NAT, Firewall, IDS, IPS, DNS, Caching등의 다양한 기능을 Software 형태의

     Virtual Applicances로 구현하여 운용하는 가상화 기술.

   - 2012년 10월 독일 SDN & OpenFlow World Congress 에서 BT와 도이치텔레콤이 NFV 단체 설립 발표.

   - ETSI(European Telecommunications Standards Institue)의 ISG(Industry Specification Group)에서 NFV 표준화 시작

   - 서비스 사업자 주도로 NFV 표준화 진행 중.

 

 

NFV의 목적

   - 표준 IT 가상화 기술을 활용하여 기존의 단일 Appliance로 동작하던 장비들을 Software형식으로 Virtual Appliance로 구현.

   - Virtual Appliance로 구현된 S/W는 표준 대용량 서버/스위치/스토리지를 활용하여 하나의 서비스 자원으로 운용 

   - 기능적인 구현을 Virtual Appliance에서 구현함으로써, 표준화된 대용량 장비 개발 장려.

   - 서비스 기능 구현을 위해 보다 민첩한 소프트웨어 기반 프레임워크를 사용하여 서비스 유연성을 향상.

 

 

NFV 특징

   - 기존의 고정된 인프라와 모바일 인프라 모두에서 어떠한 Data Plane 처리 / Control Plane 기능 적용 가능.

   - 기존의 독립된 Hardware Applicane의 경우에 단독형 장비이므로 물리적인 확장만 가능하지만,

      Virtual Appliance로 구현된 경우, CPU/Memory와 같은 추가적인 자원 할당만으로 유연한 확장이 가능하다.

      [On-Demand 시에 Scale-Out을 쉽게 할 수 있음]

   - 필요에 따라, 새로운 장비에 별도의 설치가 필요없이 기존의 Virtual Appliance의 이동 및 인스턴스화가 가능하다.

 

 

NFV vs SDN

   - NFV은 SDN과의 보완을 통해서 상호 이익을 가져갈 수 있지만, 서로의 종속되어 구현되지는 않을 것이다.

   - SDN는 네트워크를 보다 쉽게 설정/관리할 수 있게 해주며,
     NFV 네트워크를 보다 쉽게 Deploy하고, 확장할 수 있게 해준다.

     SDN과 NFV에서 이를 가능하게 해주는 주요 Key테마는 바로 "Software"이다.

 

 

 

  

SDN

NFV

탄 생 배 경

 • Control Plane과 Data Plane을 분리
 • 중앙 집중식 제어와 Network의 프로그램화

 • 네트워크 기능 이동(독립 Appliance → 일반 서버

적 용 위 치 

 • Campus / Datacenter / Cloud  • Service Provider Network

적 용 장 비

 • 범용 서버와 스위치  • 범용 서버와 스위치

초기

어플리케이션

 • Cloud orchestration and networking

 • Routers, firewalls, gateways, CDN,

   WAN accelerators, SLA assurance

프로토콜

 • OpenFlow  • 현재 없음

표준화 기구

 • Open Networking Forum (ONF)

 • ETSI NFV Working

 

NFV 구현 시

  - CAPEX(설비투자비) / OPEX(운용비) / 상면 / 에너지 소비량 의 절감 효과

  - 네트워크 사업자의 성숙주기 감소


CloudNFV 

  - 다수의 벤더로 구성된 NFV에 대한 Prototype을 만드는 컨소시엄 단체

  - OpenDaylight과 같은 OpenSource Protect는 아니며, 각 벤더들은 자신들의 지적 재산권을 유지하여 생산한다.

    하지만, 서로 다른 NFV Components간의 Open Interface를 통해서 Multi 벤더 NFV를 구성할 수 있다.

 

   • Dell : NFV 기능이 있는 데이터센터 인프라

   • 6WIND :  Cloud 환경에서의 성능 가속화 기능

   • EnterpriseWeb : 가상 네트워크 기능을 구성하는 리소스들을 통합하고 최적화를 위한 데이터모델에 대한 소프트웨어

   • Overture Network : Orchestration 소프트웨어 / SDN 컨트롤러

                              클라우드에 배포된 가상 네트워크와 연결되는 Metro Edge Switch

   • Qosmos : 네트워크 모니터링 소프트웨어 (NFV가 어떻게 네트워크를 운영을 하는지에 대한 모니터링)

 

 

 

Posted by 네떡지기

약간 PT를 두어장 수정했습니다. 동일한 내용이 써 있는 것도 발견하고 오타도 발견을 해서요. ^^;

그리고 파워포인트 쇼도 함께 추가로 첨부합니다.


 

 부서 세미나를 위해서 어떤 주제로 할까? 고민을 하다가 예전에 네전따 카페 세미나에서 들었었던 OpenFlow에 대해서 다시 한 번 알아보고 정리를 해보았습니다.

 그 때에는 조금 더 능동적이지 못한 채, 세미나를 준비하는 데 힘들어서 그냥 들었다면 이번에 세미나 자료를 만들면서 보다 OpenFlow와 SDN(Software-Defined Networking)에 대해서 조금이나마 알게 되었습니다.

아직은 초기 단계에 불과하기는 하지만 향후 5년간 성장함에 따라서 지금의 Cloud가 대두되는 것처럼 SDN과 OpenFlow가 대두되게 된다면, 정말 오랫동안 정체되어 있던 전통적인 네트워크 구조자체가 새롭게 변모하게 될 것 같다는 생각을 해 봅니다.
(물론 정체된 네트워크도 따라가기가 여전히 버겁다..)

세미나는 아직 진행하지 않았지만, 자료를 방금 막 만들어서 우선 블로그에 올려봅니다.

 

 

2012세미나(SDN_OpenFlow)_by_네떡지기(수정).pdf

2012세미나(OpenFlow_SDN)-by네떡지기.ppsx

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted by 네떡지기

티스토리 툴바