(Recovered from my old article - originally posted on 2014.12.12 08:05 KST)

 

지난 12월 9일 오전 9시 (한국 시각: 12/10 2:00AM)에 Midokura에서 있었던 "Midonet - How to Get Started"에 참석했을 때 들었던 내용들을 정리하고, Midostack을 사용해 본 경험을 정리하였습니다.

 

Midokura 회사에서 개발하는 MidoNet은 OpenStack 등의 클라우드 관리 플랫폼 계층과 KVM 등의 Hypervisor 계층 사이에서 일종의 네트워크 가상화 계층을 두어 다음과 같은 네트워크 기능을 제공하도록 설계되었다.

 - Logical Switching: 물리 네트워크의 2계층과 3계층을 논리적으로 분리 (decoupling)

 - Logical Routing: 가상 네트워크에서의 라우팅 지원

 - Logical Firewall: 커널과 통합된 빠른 속도의 분산 방화벽 지원

 - Logical Layer 4 Load Balancer: 소프트웨어 내에서의 응용프로그램 로드 밸런싱

 - API: RESTful API를 통한 클라우드 관리 플랫폼과의 통합 지원

Midonet은 production network을 염두하고 벤더 및 사용자 중립성을 목표로 하는 Apache 2 라이선스를 따르는 오픈 소스라고 한다.

 

Midokura에 따르면 커널 레벨에서 구현되고, Agent를 기반으로 통신을 하는 식으로 구조가 되었기에, 오버레이 네트워크와 같은 논리적인 토폴로지 구성이 쉽다고 한다. 

또한, 장애가 발생했을 때의 처리 (예: failover), 확장성 (scalability), 네트워크 효율성 등을 해결하기 위해 Midonet은 분산형의 모델을 선택하였다고 한다.

 

 

Midostack은 이러한 Midonet을 오픈 소스 클라우드 관리 플랫폼에서 체험 가능하고자 만들어졌으며, DevStack이 실행될 때 Midonet을 같이 구성하여 Midonet 오픈 소스에 기여하고자 하는 사람, Midonet을 배우고자 하는 사람 등을 대상으로 만들었다고 한다. Midostack은 현재 Ubuntu 14.04에서만 설치를 지원한다고 한다. 실제 Midonet을 설치할 때는 Midostack이 아닌 CentOS 7 또는 RHEL 7에서 동작하는 Packstack RDO를 권장한다고 한다 (참고: https://openstack.redhat.com/MidoNet_integration). Packstack RDO는 Icehouse 기반에서 동작한다고 한다.

 

또한, 보다 자세한 사항 및 Midonet에 contribute하는 방법 등 상세한 설명이 webinar에서 있었다. (슬라이드는 곧 공개될 것으로 보입니다.)

 

OpenStack, 특히 DevStack 위에서 구동되는 것이 신기해 보여 Midostack을 설치해 보고, Midonet에서 지원하는 간단한 cli 명령들을 실행해 보았다.

 

- 준비: VirtualBox 4.3

- OS: Ubuntu 14.04 LTS (64 bit)

- 기본 설정 사항: 램 8GB, HDD는 넉넉하게 50GB 정도로 동적 디스크로 할당, 기본 네트워크 NAT 사용

(Midostack은 다른 설정없이 실행했을 때, public network가 200.200.200.0/24라고 가정한다. 혹, 네트워크 functionality까지 테스트를 원하시는 분은 Midostack 실행 전 설정을 변경하거나, VirtualBox 설정 등을 통해 네트워크 영역을 지정해 줄 필요가 있다.)

 

정말 손쉽게, 다음과 같은 명령을 실행하여 설치 가능한데, 몇 가지는 미리 해 주어야 한다.

- 리눅스가 최신 업데이트된 상태여야 한다. ('sudo apt-get update', 'sudo apt-get upgrade', 'sudo apt-get dist-upgrade', 'sudo reboot' 차례 차례 실행 필요)

- 'git' 설치 필요 ('sudo apt-get install git')

 

 $ git clone 

 $ cd 

 $ ./midonet_stack.sh

 

실행하면 Midonet 및 DevStack 최신 소스를 다운로드하여 자동으로 설치가 이루어지고, Midonet에서 사용하는 logical router 등의 생성까지 이루어진다.

그런데, 나의 경우 알 수 없는 이유로 DevStack 설치 이후 Midonet에서 logical router 생성이 실패했는데, IRC community에 질문하니 unstack 실행 후 다시 stack을 실행해 보라는 제안을 주었고, 실제 그렇게 하니 성공적으로 설치가 된 메시지를 확인할 수 있었다.

(약 2주 전까지는 protobuf 최신 버전을 별도로 설치했어야 했는데, 이 부분은 최근에 해결된 것으로 보인다.)

 

 

 

설치 완료 화면: Devstack과 비슷하게 설치 완료된 후, Midonet과 관련된 추가 작업이 이루어진 것을 확인할 수 있다.

 

 

Horizon: 디폴트로 200.200.200.0/24 public network가 생성된다. VM 인스턴스를 하나 생성한 후, 캡처한 화면

 

 

midonet-cli 명령을 통해 OpenStack에서 사용하는 tenant 목록을 확인할 수 있으며, Midonet에서 관리하는 라우터에 대한 포트 목록, multi-node OpenStack 환경을 위한 host 목록 및 PRE_ROUTING, POST_ROUTING 처리를 위한 chain 목록 등을 확인 가능하였다.

 

 

Midonet의 더 많은 기능을 테스트하기 위해서는 Multi-node로 환경을 구성해야 할 것으로 보인다. IRC에서 이와 관련해 논의하였는데, 이 때는 Midostack보다는 Packstack RDO를 활용하는 것이 좋을 것 같다는 제안을 들었다. (아무래도 Midostack으로 multi-node를 구성하려면.. 이것저것 삽질이 많이 필요할 수 있다는 이야기겠죠? 참고하셨으면 합니다.)

 

[참고]

http://www.midonet.org/#quickstart

- Online MidoNet Network Virtualization Meetup (http://www.meetup.com/Online-MidoNet-Meetup/) 자료 인용

http://komeiy.hatenablog.com/entry/2014/11/13/012401

- Midonet IRC!

 

이전 블로그 내용을 찾을 수 없어 영어 백업본(http://sdndev.net/5)을 아래에 붙입니다.


(Recovered from my old article - originally posted on 2014.09.13 16:49 KST)

 

Previously, many developers and engineers needed to add OpenFlow dissector to WireShark to analyze OpenFlow protocol packets in WireShark. It was so difficult stuff, because we needed to match the version of OpenFlow dissector and the version of Wireshark.

 

According to Wireshark wiki page (http://wiki.wireshark.org/OpenFlow), OpenFlow dissector will be available on Wireshark 1.12.0, and this version was released as 'Stable Release' on 31 July, 2014.

 

I have downloaded this stable release version and checked that this version well supports both OpenFlow 1.0 & 1.3!

 

Just download from Wireshark homepage (https://www.wireshark.org/download.html)and install the latest stable release of Wireshark.

After installation, you can see that your Wireshark supports OpenFlow 1.0, 1.3 and 1.4.

 

I have downloaded & installed Wireshark 1.12.0 on my Windows computer and it worked very well!

 

[Menu: Supported Protocols]

 

[Parts from supported protocols]

 

Here are some screenshots which show that OpenFlow 1.0 & 1.3 filters work very well:

 

[OpenFlow 1.0: openflow_v1]

 

[OpenFlow 1.3: openflow_v4]

'OpenFlow&SDN' 카테고리의 다른 글

Ryu-book: 한국어 번역 과정 소개  (0) 2024.03.10
RYU SDN Framework: 한글 번역  (0) 2024.03.10

이전 블로그 내용을 찾을 수 없어 영어 백업본을 아래에 붙입니다.

최신 Ryu 관련 내용은 https://ryu-sdn.org/resources.html 링크를 통해서도 확인 가능합니다.


(Recovered from my old article - originally posted on 2014.07.26 22:20 KST)

 

I have finished the draft translation of "RYU SDN Framework", written in Japanese & English.

 

HTML: http://ianychoi.github.io/ryu-book/ko/html/

PDF: http://ianychoi.github.io/ryu-book/ko/Ryubook.pdf

 

This book was published in Japanese first, on the early of this year

(http://osrg.github.io/ryu-book/ja/html/)

and after several months, the English edition of this book was also published

(http://osrg.github.io/ryu-book/en/html/).

 

I'm not good at Japanese, but I mainly used Google translator (http://translate.google.com).

So please give me feedback through github (https://github.com/ianychoi/ryu-book/).

 

Currently, the PDF edition has line-feed problems.

I think it is because of the conflict between ko.tex & listings packages used in Latex,

but it is a little bit difficult for me to solve this problem..

 

I hope that more Korean developers will read this book and contribute to SDN worlds!

 

Note: Ryu is a SDN controller written by Python, and supports various OpenFlow versions: 1.0, 1.2, 1.3 and 1.4.

(Recovered from my old article - originally posted on 2014.03.27 23:45 KST)

 

네트워크 네임스페이스는 리눅스 커널 2.6.24 이후부터 지원하기 시작하였는데, 사실 몇 년 전부터 이미 지원하고 있던 기능임에도 불구하고 의외로 많이 대중화되어 알려지지 못했습니다.

OpenStack에서 Neutron을 사용해 네트워크를 구성하다 보면, 'ip netns'라는 명령어를 자주 볼 수 있는데, 해당 명령어가 왜 필요한지를 이해하기 위해서는 네트워크 네임스페이스에 대한 지식이 필요합니다.

 

외국에서는 이미 영어로 많이 안내가 되고 있는 것 같지만, 국내에는 아직 마땅히 번역된 자료가 없는지라, lwn.net 에서 올해 초 설명한 내용을 번역해 보았습니다. 리눅스 시스템 콜과 같은 디테일한 설명이 있어 읽기 부담되실 수도 있으나, 읽어보시면 네트워크 네임스페이스에 대해 보다 잘 이해하실 수 있으리라 생각합니다 : )

 

 


 

네임스페이스 (Namespaces) 운영, part 7: Network namespaces

By Jake Edge
January 22, 2014
번역 by Ian Y. Choi,
March 27, 2014 Namespaces in operation
기사 원문을 보시려면 클릭하세요. (Please click this URL if you want to read the original article.)

lwn.net에서 Linux namespace를 다룬지 꽤 되었다. 본 시리즈에서 빠졌던 '네트워크 네임스페이스' 부분을 이제야 채우고자 한다. 이름에서 알 수 있듯이, 네트워크 네임스페이스는 네트워크 장치, 주소, 포트, 라우트, 방화벽 규칙 등의 사용을 각각 분할하여, 별도의 상자(박스)처럼 분리한다. 이를 통해 단일 커널 인스턴스가 실행 중인 환경에서 네트워크를 가상화하는 것이 가능해진다. 네트워크 네임스페이스는 이미 5년 가까이 지난 커널 버전 2.6.24에 추가되었다. (현재와 같이) 자주 쓰일 정도로 준비된 상황까지 발전하기까지는 1년 정도 소요되었는데, 이 때 이후, 네트워크 네임스페이스는 많은 개발자로부터 많이 간과된 측면이 있다.

네트워크 네임스페이스 관리 기본

다른 네임스페이스들과 비슷하게, 네트워크 네임스페이스 역시 CLONE_NEWNET 플래그값을 clone() 시스템 콜에 전달하는 과정을 통해 생성된다. 그러나, 명령 라인 방식으로 실행 가능한 ip 라는 네트워크 구성 도구를 사용하여 네트워크 네임스페이스를 셋업하고 작업하는 것 또한 가능하다. 예를 들면,

    # ip netns add netns1

위 명령어는 netns1라는 새로운 네트워크 네임스페이스 1개를 생성한다. ip 도구가 네트워크 네임스페이스를 하나 생성할 때, /var/run/netns 아래에 해당 네임스페이스를 위한 연결 마운트 지점이 생성될 것이다. 이를 통해, 프로세스들이 해당 네임스페이스 안에 없더라도 네임스페이스가 지속될 수 있도록 하고, 네임스페이스 자체를 변경하는 것을 가능하게 한다. 네트워크 네임스페이스의 경우 사용 전 어느 정도 분량이 되는 구성을 일반적으로 필요로 하기에, 이 특징은 시스템 관리자들에게 많은 도움을 줄 것이다.

"ip netns exec" 명령은 네임스페이스 내에서 네트워크 관리 명령어들을 실행하는데 사용된다.

    # ip netns exec netns1 ip link list
    1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT 
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

이 명령어는 네임스페이스 내에서 보이는 인터페이스들을 열거한다. 네임스페이스는 다음을 통해 제거 가능하다.

    # ip netns delete netns1

이 명령어는 주어진 네트워크 네임스페이스와 연관된 연결 바운트 지점을 제거한다. 그러나, 네임스페이스 자체는 해당 네임스페이스 내 실행되는 프로세스가 실행될 때까지 계속 지속될 것이다.

네트워크 네임스페이스 구성

새 네트워크 네임스페이스에는 다른 네트워크 장치들은 존재하지 않고 루프백 장치 (loopback device) 1개만 있을 것이다. 루프백 장치를 제외하고, 각 네트워크 장치 (물리 또는 가상 인터페이스, 브릿지 등)는 오직 1개의 단일 네트워크 네임스페이스에만 소속된다. 게다가, (실제 하드웨어에 연결된) 물리 장치들은 root 네임스페이스가 아닌 어떤 네임스페이스에도 할당되어질 수 없다. 대신, 가상 네트워크 장치들은 (예: 가상 ethernet, 즉 veth) 생성되어 네임스페이스에 소속될 수 있다. 이 가상 장치들은 프로세스들이 네임스페이스 내에서만 네트워크 통신을 수행하도록 지원한다. 이를 통해 누구와 통신을 할 수 있는지에 대한 대상을 결정하는 구성, 라우팅 등이 이루어진다고 볼 수 있다.

처음 생성되었을 때, 새 네임스페이스 상에 있는 lo 루프백 장치는 down 상태이므로, 루프백 장치에 ping을 수행하면 실패할 것이다.

    # ip netns exec netns1 ping 127.0.0.1
    connect: Network is unreachable
해당 인터페이스를 up을 시키는 과정을 통해 루프백 주소에 ping하는 것이 가능해진다.
    # ip netns exec netns1 ip link set dev lo up
    # ip netns exec netns1 ping 127.0.0.1
    PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
    64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.051 ms
    ...
그러나 여전히 netns1과 root 네임스페이스와는 통신이 불가능하다. 이를 지원하기 위해서는, 가상 ethernet 장치를 생성 및 구성할 필요가 있다.
    # ip link add veth0 type veth peer name veth1
    # ip link set veth1 netns netns1
처음 명령어는 가상 ethernet 장치 한 쌍을 연결된 상태로 만든다. veth0로 보내지는 패킷은 veth1에서 받을 것이고, 그 반대 또한 동작할 것이다. 두 번째 명령어는 veth1을 netns1 네임스페이스에 할당한다.
    # ip netns exec netns1 ifconfig veth1 10.1.1.1/24 up
    # ifconfig veth0 10.1.1.2/24 up
그리고 나서, 이 두 명령어를 통해 IP 주소를 두 장치에 할당한다.
    # ping 10.1.1.1
    PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
    64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=0.087 ms
    ...
    
    # ip netns exec netns1 ping 10.1.1.2
    PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
    64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.054 ms
    ...
위에서 보여준 ping 명령어에서 보듯이, 양방향 통신이 이제 가능해진다.

언급하였듯이, 그러나, 네임스페이스들은 라우팅 테이블 또는 방화벽 규칙을 서로 공유하지 못한다. netns1에서 route와 iptables -L 명령을 실행함으로써 증명될 것이다.

    # ip netns exec netns1 route
    # ip netns exec netns1 iptables -L
첫 번째 명령은 단순히 (veth1이 사용하는) 10.1.1 서브넷을 위한 패킷들의 경로를 보여줄 것이고, 반명 두 번째 명령은 iptables 구성이 되어 있지 않음을 보여줄 것이다. 두 결과 모두 의미하는 바는, netns1으로부터 인터넷으로 보내지는 다량의 패킷들은 "Network is unreachable"라는 두려운 메시지를 수신할 것이다. 필요한 경우, 네임스페이스를 인터넷에 연결하는 몇 가지 방법이 있다. bridge를 root 네임스페이스와 netns1에 있는 veth 장치에 생성할 수 있을 것이다. 다른 방법으로는, 네트워크 주소 변환 (NAT) 과 결합된 IP 포워딩을 root 네임스페이스에 구성할 수 있다. 이들 중 어떤 방식이든 (그리고 다른 구성할 수 있는 여러 방법들이 있을 것이다.) 패킷들이 netns1으로부터 인터넷에 도달하도록 하고 해당 패킷들에 대한 응답이 netns1에 도달하도록 하는 것이 가능할 것이다.

네임스페이스에 할당된 (clone(), unshare(), 또는 setns()를 통해) root 권한으로 실행되지 않는 프로세스들은 이미 셋업된 네트워크 장치 및 구성에 대해서만 접근 가능하다-물론, root 사용자는 새로운 장치들을 추가하고 구성할 수 있다. ip netns 서브 명령을 사용하여, 네트워크 네임스페이스를 지칭(address)하는 두 가지 방법이 존재한다. 그 중 하나는 netns1과 같은 이름을 사용하는 것이고, 다른 하나는 해당 네임스페이스 내에 있는 프로세스의 프로세스 ID (PID)을 통한 방법이다. init이 일반적으로 root 네임스페이스 내에 존재하므로, 다음과 같은 명령어를 사용할 수 있다.

    # ip link set vethX netns 1
저 명령어를 통해 (짐작컨데, 새로 생성된) veth 장치를 root 네임스페이스에 위치시키고, 다른 네임스페이스 상에서 root 사용자가 동작시킬 수 있을 것이다. root 사용자가 네트워크 네임스페이스 내에서 이와 같은 운영을 수행 가능하게하는 것이 적절하지 않은 상황일 수도 있겠지만, PID와 네임스페이스 마운트 기능은 다른 네트워크 네임스페이스들에 도달하지 못하도록 사용될 수도 있을 것이다.

네트워크 네임스페이스 사용

이제까지 살펴보았듯이, 네임스페이스의 네트워크 동작은 아무것도 동작하지 않는 상태 (즉, 단순히 루프백만 존재하는 경우)부터 시스템 네트워크 동작에 대한 모든 접근까지 가능하도록 할 수 있다. 이를 통해 수많은 다양한 네트워크 네임스페이스를 사용한 유스케이스가 있을 것이다.

본질적으로 네임스페이스 내에서 네트워크를 끔으로써, 관리자들은 해당 네임스페이스 내에서 실행되는 프로세스들이 네임스페이스 밖으로 접속을 생성하지 못하도록 보장할 수 있다. 해당 프로세스가 보안 취약점과 같은 과정을 통해 감염되더라도, 네임스페이스는 botnet에 참여하거나 스팸을 보내는 것과 같은 행동들을 못하도록 해줄 것이다.

심지어 네트워크 트래픽을 다루는 프로세스들 (예: 웹 서버 worker 프로세스 또는 웹 브라우저 렌더링 프로세스) 또한 제한된 네임스페이스로 위치시킬 수 있다. 외부 지점에 의해, 또는 외부 지점으로 향하는 접속 하나가 생성되면, 해당 접속을 위한 파일 디스크립터 (file descriptor)는 clone() 시스템 콜에 의해 생성된 새로운 네트워크 네임스페이스의 자식 프로세스에 의해 관리 가능하다. 자식은 부모의 파일 디스크립터들을 모두 상속받을 것이기에, 해당 자식 프로세스는 접속된 디스크립터에 대한 접근 권한이 있다. 또 다른 가능성으로는 부모가 파일 디스크립터들을 제한된 네트워크 네임스페이스 내에 있는 프로세스에 Unix 소켓을 통해 보낼 수도 있다. 어떤 경우라도, 적절한 네트워크 장치가 해당 네임스페이스에 존재하지 않으면 자식 또는 worker 프로세스가 부가적인 네트워크 접속을 생성하는 것이 불가능할 것이다.

네임스페이스는 모든 것들이 단일 박스에서 동작하는 다소 복잡한 네트워킹 구성을 필요로 하는 환경에서 테스트하는 데 사용할 수도 있다. 보다 락-다운인 상황에서 실행되어야 하는 민감한 서비스들, 그리고 방화벽이 제한된 네임스페이스 또한 해당될 수 있다. 분명한 것은, 컨테이너 방식의 구현 또한 네트워크 네임스페이스를 사용하여 각 컨테이너에 각 네트워크만의 뷰를 제공하고, 해당 컨테이너 바깥과는 자유로운 공간을 만든다는 것이다. 이와 같이 한다면, 다양한 유스케이스들이 탄생할 수 있을 것이다.

일반적으로 네임스페이스는 시스템 자원을 분할하고, 프로세스를 그룹별로 묶어 다른 자원들로부터 격리시키는 방법을 제공한다고 할 수 있다. 네트워크 네임스페이스 역시 다른 많은 부분의 네임스페이스와 동일하지만, 네트워킹이 보안적으로 민감한 부분에 해당하기에, 여러 방법을 사용한 네트워크 격리를 제공하는 것은 굉장히 가치가 있을 것이다. 물론, 여러 네임스페이스 유형을 함께 사용한다면 보안 및 다른 필요성을 위한 보다 나은 격리를 제공할 것이다.

 

(Recovered from my old article - originally posted on 2014.03.17 02:06 KST)

 

OpenStack을 설정하다 보면, Nova-Network, Neutron (Quantum), 그리고 최근 Havana에 포함된 ML2와 같이 새롭고 복잡한(?) 용어들이 많습니다.

본 글을 통해 OpenStack에서 네트워크 관련 부분들을 정리해 보고자 합니다.

NAIM Networks에서 개최하는 PM 교육에서 사용 중인 OpenStack 부교재 내용을 참고하였습니다.

(자료 퍼가실 때, 출처 명시 부탁드립니다 ^^)

 


OpenStack에서 네트워크 지원 부분은 다음과 같이 변화되었다.

- Nova-Network: Nova는 가상 머신들을 관리하는 OpenStack 프로젝트명으로, 초기에는 가상 머신들을 관리하는 부분에서 네트워크 또한 관리하였다.

- Quantum: OpenStack 버전이 Essex에서 Folsom으로 바뀌면서 포함된 프로젝트명으로, 복잡한 네트워크 부분을 별도의 프로젝트로 분리하고자 기존에 Nova 프로젝트에 속해있던 Nova Network 부분을 Quantum 프로젝트로 분리하였다.

- Neutron: Quantum 이름을 상표권 문제로 더 이상 사용하지 못하면서, Neutron으로 이름을 변경하였다.

- ML2: Havana에 포함되었으며, Neutron에 연결 가능한 플러그인 형태로 개발되었다.

 

 

OpenStack에서 IP 주소를 이야기할 때, Fixed IP와 Floating IP라는 용어를 사용한다. 이 두 용어들을 직역하면 '고정IP'와 '유동IP'가 되는데, 네트워크 IP 주소 설정 때 고정 IP, 유동 IP를 의미하는 것이 아님을 유의해야 한다.

Fixed IP

- OpenStack에서 가상 머신 템플릿을 기반으로 인스턴스가 생성되었을 때 할당된 IP 주소

- 해당 인스턴스가 종료될 때까지 계속 가지고 있음

Floating IP

- 필요에 따라 IP 주소를 잠시 연결하거나 해제 가능한 IP 주소

- 예를 들어, 공인 IP 주소를 특정 인스턴스에 잠시 연결했다가 해제하고자 할 때 이용 가능한 IP 주소를 의미함

 

OpenStack Essex까지는 Nova-Network를 통해 Flat Mode, Flat DHCP Mode, VLAN DHCP Mode 3가지를 지원하였다. Flat Mode는 사용자가 100% 수동으로 Fixed IP 주소를 부여하는 방식을 의미하고, Flat DHCP Mode는 dnsmasq 라는 Linux에서 사용하는 DHCP 서버 프로그램을 활용하여 Fixed IP 주소를 자동으로 부여하는 방식을 의미한다. 그리고, VLAN DHCP mode는 VLAN을 통해 가상 머신 인스턴스들을 그룹화하여, 각 그룹에 할당된 vtag 번호가 달라져 각 그룹 네트워크 격리가 가능해진 상태에서 DHCP 서버를 각 그룹마다 사용하는 방식을 의미한다.

 

 

Quantum은 네트워크 가상화를 지원하기 위해 Nova 프로젝트 내 Nova-Network가 수행하던 역할을 별도 프로젝트로 분리하였다고 볼 수 있다. 플러그인을 지원하는 형태로 제작되었는데, 이를 통해 Linux Bridge와 OpenvSwitch를 Quantum에서 플러그인 교체 및 설정 수정을 통해 교체하는 것이 가능해졌다. 뿐만 아니라, 하드웨어 스위치와의 연동을 플러그인 교체 및 설정을 통해 지원 가능해졌으며, SDN 컨트롤러와의 연동 또한 플러그인을 통해 가능해졌다.

 

 

(출처: http://pt.slideshare.net/kamesh001/whats-new-in-neutron-for-open-stack-havana)

ML2는 Module Layer 2의 약어로, 이름을 통해 네트워크 2계층 부분에 대한 모듈화를 지원하기 위한 플러그인에 해당된다. Havana에서 포함되기 시작한 플러그인인데, 위 그림과 같은 형태를 지원하기 위해 개발되었다고 볼 수 있다. 기존 Quantum/Neutron에서는 OpenvSwitch 플러그인 사용시, 모든 물리 호스트에 OpenvSwitch를 사용해야만 했었다. 그러나, ML2에서는 각 호스트에서 서로 다른 방식을 쓰더라도 네트워크 2계층이 모듈화되어 OpenStack에서 관리가 가능해졌다.

+ Recent posts