(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]

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]

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

최신 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

    # ip netns add netns1

    # 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

    # ip netns exec netns1 ping 127.0.0.1
    connect: Network is unreachable

    # 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
    ...

    # ip link add veth0 type veth peer name veth1
    # ip link set veth1 netns netns1

    # ip netns exec netns1 ifconfig veth1 10.1.1.1/24 up
    # ifconfig veth0 10.1.1.2/24 up

    # 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
    ...

    # ip netns exec netns1 route
    # ip netns exec netns1 iptables -L

    # ip link set vethX netns 1

(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에서 관리가 가능해졌다.