날아라 병아리

클라우드 인스턴스에서 devstack 구축하기

삐야악이 — Sun, 25 Jul 2021 12:49:25 +0900

devstack은 openstack 테스트 환경을 구축할 수 있는 가장 손 쉬운 방법이다. 보통은 자신의 컴퓨터에서 virtualbox vm을 생성해서 devstack을 설치하지만, 실수로 vm을 끄기라도 한다면 온전한 형태의 devstack을 다시 만들기는 어렵다. 이 경우 devstack 환경을 다시 만드는 것이 마음이 편하다.

그래서 요즘에 virtualbox를 이용하지 않고, 클라우드 인스턴스에 devstack을 구축해서 항상 구동중이면서 어디에서든지 접근할 수 있도록 하고 싶은 요구사항이 생겨났다. virtualbox에서 구현하는 것과 큰 차이는 없지만, 클라우드라는 환경에서 고려해야하는 점들이 있었고 어떻게 해결하였는지 이제부터 설명하겠다.

고민) provider network를 어떻게 제공할 것인가?

provider network는 OpenStack 입장에서 인터넷 통신이 가능한 (주로 공인 IP를 사용하는) 네트워크를 의미한다. 이 네트워크는 OpenStack에 floating ip를 제공하거나 가상 네트워크의 nat ip를 제공한다. virtualbox를 이용할 경우, 이 네트워크를 컴퓨터가 연결된 공유기의 네트워크와 인터페이스로 지정하고 공유기의 dhcp에서 일정 대역을 빼서 OpenStack에 할당해준다. 그런데 클라우드 인스턴스에서는 이런 네트워크를 어떻게 만들어야할까?

기본적으로 클라우드 인스턴스에는 인터넷이 가능한 네트워크에 연결된 nic 포트 하나가 제공된다. 제공되는 네트워크의 IP는 클라우드에 의해 자동으로 할당 및 관리되기 때문에 OpenStack에서 임의로 사용하기 어렵다. 따라서, 인스턴스 내부에서 가상의 provider network를 만들고 그것을 OpenStack이 사용하도록 해줘야한다.

방법) Linux Bridge로 가상의 provider network만들기

가상의 provider network를 만들기 위해 Linux Bridge를 이용할 것이다. Linux Bridge에 사설 네트워크를 할당한 뒤 iptables를 이용해 인터넷이 가능한 인터페이스와 nat를 시켜주면 bridge network에서도 인터넷이 가능하다.

그림으로 표현하면 다음과 같다.

apt install bridge-utils

brctl addbr mybr0
ifconfig mybr0 192.168.100.1 netmask 255.255.255.0 up
ip link set mybr0 up

iptables -I FORWARD -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.100.0/24 -j MASQUERADE

고민2) 외부에서 horizon 접근가능하도록 설정하기

devstack을 설치하면 기본적으로 OS에 설정된 ip로 horizon을 비롯한 api endpoint를 지정한다. 클라우드 인스턴스 OS에 설정된 ip는 사설 대역이므로, 인스턴스에 floating ip (aws는 elastic ip)를 붙인다고 해도, api endpoint와 horizon을 온전하게 외부에서 이용하기 어렵다. 따라서, devstack 설정파일에 인스턴스의 floating ip를 넣어주고, 그 아이피로 바인딩할 수 있게 loopback interface에 ip를 넣어줘야한다.

예를 들어 인스턴스에 연결된 floating ip 가 1.2.3.4 라면 다음과 같이 loopback interface에 ip를 추가한다.

ip addr add 1.2.3.4/32 dev lo

local.conf 설정

마지막으로 local.conf를 설정해주면 devstack을 구축할 준비가 완료되었다.

이 설정에서는 openvswitch를 이용해 네트워크를 구축하며, floating ip 대역으로 192.168.100.0/24 를 사용하고, 그 네트워크를 제공하는 인터페이스는 위에서 생성한 mybr0 Linux Bridge로 지정하였다.

[[local|localrc]]
HOST_IP=1.2.3.4
FORCE=yes
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

# Disable services
disable_service etcd3
disable_service ovn
disable_service ovn-controller
disable_service ovn-northd
disable_service q-ovn-metadata-agent

# Use openvswitch as the ml2 plugin driver
Q_AGENT=openvswitch

# Enable Neutron services neutron-server, neutron-openvswitch-agent,
# neutron-dhcp-agent, neutron-l3-agent and neutron-metadata-agent
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta

## Neutron options
# 인스턴스에 할당할 Floating ip 대역
FLOATING_RANGE="192.168.100.0/24"      
# 인스턴스 fixed ip 대역
IPV4_ADDRS_SAFE_TO_USE="10.0.0.0/22"    
Q_FLOATING_ALLOCATION_POOL=start=192.168.100.50,end=192.168.100.250
PUBLIC_NETWORK_GATEWAY="192.168.100.1"
PUBLIC_INTERFACE=mybr0

# Open vSwitch provider networking configuration
Q_USE_PROVIDERNET_FOR_PUBLIC=True
OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_BRIDGE=br-ex
OVS_BRIDGE_MAPPINGS=public:br-ex

[[post-config|/$Q_PLUGIN_CONF_FILE]]
[ml2]
type_drivers=flat,gre,vlan,vxlan
tenant_network_types=vxlan
mechanism_drivers=openvswitch,l2population

[agent]
tunnel_types=vxlan,gre

이렇게 설정하면 public interface로 mybr0를 이용하고, ovs가 public network를 이용하기 위한 ovs bridge `br-ex`를 만들어서 floating ip network와 연결하도록 설정한다.

아래는 "ovs-vsctl show" 를 통해 확인한 br-ex ovs bridge 설정 내용이다.

    Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        datapath_type: system
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port mybr0
            Interface mybr0
        Port br-ex
            Interface br-ex
                type: internal

그리고 `ip a`를 통해 인터페이스를 확인해보면 mybr0에 할당한 192.168.100.1 이, br-ex로 옮겨져간 것을 확인할 수 있다.

10: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 46:6f:e7:cc:b4:4b brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 2001:db8::2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::446f:e7ff:fecc:b44b/64 scope link
       valid_lft forever preferred_lft forever

[ Linux ] iptables 를 이용하여 간단히 port forwarding 하기

삐야악이 — Thu, 3 Oct 2019 23:33:07 +0900

서버가 특정 아이피에 대해서만 접속이 허용될 때, 그 아이피를 가진 proxy 서버를 만들어 접속을 하는 방법이 있다.

이 때, proxy 서버를 좀 더 간편하게 만들 방법을 찾아보던 중, iptables 를 이용하여 port forwarding 하는 방법을 찾았다.

이 방법을 쓰니, OpenVPN으로 VPN 서버를 구축하고 클라이언트 설정하는 번거로움을 해결할 수 있었다.

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport [source port] -j DNAT --to [dest IP]:[dest PORT]

위 내용은 eth0 인터페이스를 대상으로 dport 에 적은 포트로 오는 요청을 –to 로 보내버리는 설정이다.

iptables -t nat -D PREROUTING [rule num]

[ maven ] 운영환경 별, 설정 파일 분리하기

삐야악이 — Thu, 3 Oct 2019 23:31:03 +0900

maven profile 을 이용한 설정 파일

어플리케이션을 개발하다보면 다양한 설정파일들을 관리하게 된다. 데이터베이스 접근 정보, 레디스 접근 정보 등..

이런 설정들은 개발, 테스트, 운영 단계별 서로 다른 설정을 가질 수 밖에 없다. 만약 이런 내용들이 코드에 정적으로 들어가 있다면 단계별로 코드의 내용을 수정해서 다시 컴파일을 해야하는 매우 번거로운 상황이 일어날 것이다.

만약 별 다른 기능을 사용하지 않는다면 아마 코드에는 다음과 같은 내용이 들어갈 것이다.

if(env.equals("local")) {
    ......
}
else if (env.equals("dev")) {
    .....
}

maven 을 이용해서 개발하는 java 프로젝트일 경우, maven profile 을 이용하여 빌드 시, 외부에서 넣어주는 파라미터를 기준으로 서로 다른 설정파일을 참조하게 하여 환경 별로 다른 설정파일을 선택하도록 해줄 수 있다.

설정 파일

설정파일은 다양한 포멧을 가질 수 있다. 가장 많이 쓰이는 것이 yaml 와 properties 이다. maven 에서는 properties 파일을 이용해서 설정 파일을 관리하고 있다.

properties 설정 파일의 형태는 다음과 같이 key = value 형태를 가진다.

url = http://printf.kr

그리고 설정 파일은 대부분 src/main/resources 폴더 아래에 위치한다.

환경 별 리소스 폴더 구분

위에서 설정 파일은 대부분은 src/main/resources 에 저장된다고 하였다. 그럼 환경별로 리소스 폴더를 다르게 두고 그것을 classpath 에 넣으면 환경 별로 설정파일을 다르게 가져갈 수 있다.

개발자 환경
- src/main/resources-local
개발 서버 환경
- src/main/resources-dev
운영 서버 환경
- src/main/resources-real

와 같이 리소스 폴더를 구분해 줄 수 있다.

maven profile 설정

이제 maven profile 설정을 통해, 빌드 단계에서 원하는 리소스 폴더를 classpath 에 추가하는 작업을 진행할 것이다.

우선, pom.xml 에 아래와 같이 profile 을 추가한다.

<profiles>
    <profile>
      <id>dev</id>
      <properties>
        <env>dev</env>
      </properties>
    </profile>
    <profile>
      <id>local</id>
      <properties>
        <env>local</env>
      </properties>
    </profile>
    <profile>
      <id>real</id>
      <properties>
        <env>real</env>
      </properties>
    </profile>
</profiles>

이렇게 설정된 profile 을 maven 명령어에서 P옵션으로 같이 선택할 수 있다.

maven clean package -P dev

다음은 선택된 profile 에 맞는 리소스 폴더를 classpath 에 넣는 작업이다. 기본즉으로 src/main/resources 는 들어가고 부가적으로 환경 별 리소스 폴더를 넣으면 된다. 아래 내용을 pom.xml 의 build 부분에 추가한다.

<resources>
  <resource>
    <directory>src/main/resources</directory>
  </resource>
  <resource>
    <directory>src/main/resources-${env}</directory>
  </resource>
</resources>

자 여기까지 하면 빌드 시, 환경에 맞는 설정파일이 classpath 로 들어가게 된다.

코드에서 properties 값 가져오기

이제 코드에서 properties 에 설정된 값을 가져와야 한다.

Properties prop = new Properties();
prop.load(OAuthPayco.class.getClassLoader().getResourceAsStream("payco.properties"));
clientId = prop.getProperty("clientId");
clientSecret = prop.getProperty("clientSecret");

위 코드와 같이 아주 간단하게 코드에서 properties 에 있는 값을 가져올 수 있다.

참고 자료

https://www.lesstif.com/pages/viewpage.action?pageId=14090588

[2017년 회고] 주니어 시스템 엔지니어로써의 1년

삐야악이 — Thu, 3 Oct 2019 23:28:52 +0900

나에게도 생소했던 시스템 엔지니어로써의 1년을 정리한다

2017년 1월 2일 나는 IT인프라 직군으로 입사를 하였고, 현재는 시스템 엔지니어라는 역할을 가지고 일을 하고 있다.
지난 1년동안 나에게도 생소했던 시스템 엔지니어로써의 1년을 정리해보려고 한다.

입사하면서..

그동안 학교에서 배운 것 그리고 활동한 것은 개발에 대한 것이었다. 개발자들과 생활하였고 개발에 대한 문화를 배우고 경험해왔다.
하지만 내가 앞으로 지낼 곳은 인프라를 다루는 곳이다. 평소에 IT인프라에 대해 많은 호기심이 있었다. 쉽게 접할 수 없는 분야이기도 하고 시설과 장비 또한 쉽게 접할 수 없어서 나에겐 우주와 같이 선망의 대상이었다.

인프라에 대해 잘 몰랐던 나는 입사하면서 시스템 아키텍처를 설계하고(예를 들면 MQ는 무엇을 쓰고 어떻게 구성할 것이며.. 디비들은 어떻게 구성할 것인가 등..) 테스트하고 서비스의 인프라를 구축/운영하는 업무를 하게 되지 않을까? 라는 생각을 가졌다.

하지만, 실무에서의 인프라는 내가 처음에 생각했던 것과는 약간 다른 세상이었고, 더 큰 매력을 가지고 있었다.

신입 사원 교육

회사에서 자체적으로 진행하는 신입 사원 교육은 건너뛰고, 팀에 배정받은 다음에 진행한 교육이다. 처음 신입 사원 교육에 진행할 때 이용한 도서는 “인프라 엔지니어의 교과서” 이다.

책은 매우 얇았지만 IT인프라에 대한 모든 내용의 엑기스를 정말 잘 담아냈다. 이 책을 읽고 구두 시험을 보고, 책에서 설명하는 내용이 실제 회사 인프라에 어떻게 적용되어 있는지를 배웠다. IT인프라에 대해 맛을 보고 싶은 분에게 추천한다.

이 책을 시작으로 “서버/인프라를 지탱하는 기술” 과 “서버 부하분산 입문” 을 읽고 세미나를 하면서 시스템 엔지니어로서 기본 역량을 다져나갔다.

동시에 회사 인프라에 대한 교육도 진행되었다. 대충 아래와 같은 내용으로 교육을 받았다.

IDC 에 대한 이해
- 공조, 전력, 화재예방, 입/출고 처리, 라벨링, 하드웨어 파트 관리
- 케이블링, IDC 모니터링 등..
IDC 네트워크 장비에 대한 이해
네트워크 ACL 및 보안 정책
서비스 별 IP 대역 및 IP 할당/관리 정책
다양한 인프라 운영도구
- CMDB 포함
표준 서버 스펙 및 OS 설정
장애 대응 방법
등…

적어놓으니 엄청 많다. 저것들이 시스템 엔지니어로써 업무를 하기 위한 기본 지식이고 서비스별로 특화된 지식들도 더 필요하게 된다.

DNS
CDN
GSLB
Storage
Backup
VMWare ESXi
Windows Hyper-V
등등…

배워야할 것들이 매우 많기에 지금도 나는 업무를 받으면서 계속해서 공부하고 배워나가고 있다.

IDC에 대한 이야기

나에게 IDC는 환상의 나라 에버랜드와 같은 곳이었다. 고등학생 때 친구들과 서버를 구매하여 가지고 놀았기에 몇 번 IDC에 가본적은 있지만, 갈 때 마다 IDC는 신비로운 공간이었고 그 내부를 더 알고 싶었다. 심심할 때면 Youtube 에서 데이터센터, IDC로 검색해서 나오는 데이터센터 소개 영상을 보면서 꿈을 꾸곤 했었다.

이제 나에게 IDC는 더 이상 환상의 나라 에버랜드와 같은 곳이 아니다. IDC에서 직접 일 하는 것은 아니지만 IDC에 있는 서버들과 인프라 요소 하나하나가 나의 삶의 터전이 되었다. 하지만 난 아직도 IDC에 가면 눈이 휘둥그래져서 구경하곤한다.

내가 다니는 회사는 국내에 몇 안되는 자사가 직접 설립한 IDC를 보유한 회사이다. 이것은 주니어 시스템/인프라 엔지니에게 엄청난 복지(?)이다. IDC이용자가 아닌 제공자이기에 IDC에 대한 정말 모든 것들을 생생하게 경험하고 보고 들을 수 있기 때문이다. 상세한 네트워크 구조와 그에 쓰이는 장비들..처음에 IDC에 갔을 때, 통신사와 연결되어있는 코어 라우터를 정말 한동안 바라보곤 했었다.. IDC의 다양한 시설(공조, 전력 등)을 관리하는 방법, 모니터링 대시보드.. 네트워크 현황 등..정말 신기한 것들로 가득차있는 곳이다.

요즘은 클라우드를 많이 쓰기에 많은 주니어 개발자들이 IDC를 경험하진 못할 것 같다. 클라우드라고 부르는 것도 결국 물리적인 장비들로 이루어져있고 IDC가 없으면 안된다는 것을 알고나면 IDC가 궁금해질 것이다. 살면서 꼭! 한번쯤은 IDC에 가보는 것을 추천한다.

무엇을 공부하였나?

지금까지 내가 경험한(직접/간접) 시스템 엔지니어의 주요 업무는 아래와 같다.

인프라 용량 산정을 통해 선정된 스펙에 맞는 서버 공급
- 디스크, CPU, 메모리 등등.. 상황에 맞게 재조립해서 쓴다
- 그리고 운영체제를 설치한다.
서비스에 맞는 시스템 설계 및 구축
- 네트워크에 대한 내용은 네트워크팀에서 해준다.
- 서비스에 맞는 시스템 설정 및 관리
DNS/CDN 설정 및 모니터링
장애 시 1차적 대응 및 원인 분석

이 외에도 시스템 엔지니어의 업무영역은 매우 넓다. (아직 1년차라서 모르는게 많을 뿐이다)

1년동안 지내면서 내가 느낀 시스템 엔지니어에게 가장 필요한 스킬은 ‘리눅스‘ 이다. 회사의 대부분 시스템은 리눅스로 구축이 되어있다. 리눅스에 대한 깊은 이해가 없이는 업무를 절대로 진행할 수 없다. 사소한 설정 하나하나가 어떤 것을 의미하는지, 여러 시스템 로그들은 어떻게 분석하는지, 시스템 설정은 어떻게 해야하는지(예: bonding), 파티션 잡는 방법 등등 리눅스라는 운영체제에 대해 아주 깊은 지식이 필요로 한다. 이 지식을 기반으로 더 고급진(Docker라던지 Openstack 이라던지, HAProxy 라던지..) 기술들을 익히고 연마해 나가는 것이다.

그리고! 또 제일 중요한 것이 하나 있었다. HP, DELL, IBM 등 다양한 벤더에서 나오는 제품에 대한 이해. 어차피 엔지니어들은 물리적인 장비를 직접적으로 다루고 그에 대한 이해가 반드시 필요하다는 것을 알게 되었다. 모델별로 어떤 특징을 가지고 있는지, 설정은 어떻게 바뀌는지.. 하나하나가 업무를 하는데 정말 필요한 지식들이었다.

앞으로도 나는 공부할게 너무 많아서 하하 행복하다…..

앞으로 나는 어떻게 할 것인가?

아직 못 배운 기술들이 너무 많다.

우선은 장비에 대한 이해를 먼저 하고 싶다. 선배 엔지니어들을 보면 다양한 벤더사들의 모델별로 어떤 특징이 있고 무슨 문제점이 있는지 정말 콕 찌르면 술술술술 나온다. 물론 경험적인 면이 많이 차지하겠지만 회사에 예비로 되어있는 장비들을 가지고 메뉴얼과 함께 공부를 해야할 듯 하다.

리눅스… 리눅스를 쓴지는 어느덧 8년이 지나가고 있지만, 시스템 엔지니어로써 일하면서 정말 나는 아무것도 모르고 있었구나를 다시 한번 느끼고 있다. 서점에 가면 볼 수 있는 리눅스 관리하기 같은 책들을 사서 달달 외워야겠다. 업무하는데 리눅스를 몰라서 해맸던 적이 한둘이 아니다…

최신 기술. 요즘 Ansible이니 DevOps 니 여러 최신 기술들이 나오고 적용하는 사례가 나오고 있다. 지난 1년을 돌이켜보면 난 기존 인프라를 익히는데 모든 리소스를 사용하였고 최신 기술은 쳐다볼 엄두도 나지 않았다. 2018년에는 최신 기술이라 불리는 것들을 조금 들여다볼 수 있지 않을까?

마무리하며

간단하게 만 정리한다는 것이 엄청 많이 써버렸다. 두서 없이 써서 빠뜨린 내용도 있겠지만 지금의 나의 생각을 정리하기엔 충분했다. (만족?)
대다수의 또래 전공자들이 선택하지 않은 IT인프라, 시스템 엔지니어로서의 길을 선택했다.
아직은 모르겠다. 1년쯤 더 해보면 이 분야가 어떤지 조금은 알 수 있지 않을까? 아직은 모든게 새롭고 신기하고 흥미진진하다.

많은 사람들이 개발에 관심을 가지고 있다. 인프라에 관심을 가지고 있는 사람도 많아졌으면 좋겠다. 혼자서 놀기엔 심심하다.
2018년에도 열심히 일하는 주니어 일개미가 되어야겠다.
끝!

Virtualbox 네트워크 종류와 설정 방법

삐야악이 — Thu, 3 Oct 2019 23:23:51 +0900

Virtualbox 에서는 가상머신(이하 VM)에 할당할 수 있는 네트워크 종류를 총 6가지를 지원하고 있습니다. 각 네트워크 종류가 어떤 것을 의미하는지 살펴보고, 어떻게 설정을 할 수 있는지 알아보도록하겠습니다.

이 문서에서의 Virtualbox 실행 환경은 OS X 이며, 윈도우와 리눅스/OSX는 기본 설정에서 약간의 차이가 있습니다.

다음은 Virtualbox 에서 지원하는 네트워크 종류입니다.

NAT
NAT network
Bridge Adapter
Internal Network
Host-only Network
Generic Driver

여기에서는 맨 마지막 Generic Driver 를 제외한 나머지 5개에 대해서 설명하도록 하겠습니다.

보다 자세한 내용은 virtualbox 홈페이지의 문서를 참고해주시기 바랍니다.
( https://www.virtualbox.org/manual/ch06.html )

NAT

NAT(Network Address Translation) 는 VM이 외부 네트워크(인터넷)에 접근할 수 있는 가장 간단한 방법입니다. Host / Guest 에 어떠한 설정을 할 필요가 없기 때문에, Virtualbox 에서 VM을 생성하면 기본적으로 attach 되는 네트워크이기도 합니다.

VM에 NAT 인터페이스를 처음으로 붙이게 되면 10.0.2.0/24 대역이, 그 다음에는 10.0.3.0/24 대역이 할당되게 됩니다.

10.0.2.0/24 대역으로 할당되면, VM에는 10.0.2.15 가 부여되고, 기본 게이트웨이는 10.0.2.2 가 됩니다.

여러개의 VM을 만들고, NAT 를 붙이더라도 모두 동일하게 10.0.2.15 를 가지게 됩니다.

NAT Network

NAT Network는 공유기와 같은 환경을 만드는 것으로 이해하면 매우 쉽습니다.

여러 VM을 같은 네트워크에 속하게 하고 싶은데, 모두 인터넷이 가능하게 하고 싶을 때 사용하면 매우 유용합니다.

(보통 VM을 같은 네트워크로 묶고, 인터넷이 가능하게 하려면 VM 에 Host-only, NAT 두 개의 네트워크 인터페이스를 붙입니다)

위와 같이 Virtualbox 의 환경설정에서 GUI로 간단하게 NAT Network 를 구성할 수 있지만, 명령어를 통해서도 NAT Network 를 구성할 수 있습니다.

# 현재 생성되어있는 NAT Network 목록 조회
$ VBoxManage list natnetworks

# 192.168.0.0/24 대역의 DHCP 기능이 있는 NAT Network 생성
$ VBoxManage natnetwork add --netname natnet1 --network "192.168.0.0/24" --enable --dhcp on

# 위에서 생성한 'natnet1' NAT Network 시작하기
$ VBoxManage natnetwork start --netname natnet1

# 'natnet1' NAT Network 삭제하기
$ VBoxManage natnetwork remove --netname natnet1

natnetwork 관련 명령어에 대한 자세한 내용은 여기를 참고해주시기 바랍니다.

Bridge Network

Bridge Network 는 Virtualbox 가 호스트에 있는 네트워크 디바이스를 직접적으로 사용하는 네트워크입니다. 호스트가 사용하는 네트워크 환경을 그대로 이용할 수 있으며, VM이 호스트와 같은 물리적인 네트워크에 존재하게 할 수 있습니다.

사용하는 방법은 VM 설정의 네트워크탭에서 네트워크 어뎁터를 Bridge Network 로 선택하고, 연결할 호스트 네트워크 디바이스를 선택하면 됩니다.

단, OS X와 Linux에서는 무선 네트워크에 대해서는 Bridge Network 사용이 제한됩니다.

Internal Networking

Internal Networking 은 NAT Networking 과 같이 Virtualbox 내에서 완벽한 사설망을 구축할 수 있다는 점에서 동일하지만, 인터넷 연결이 되지 않는 점에서 다르다.

또한, Internal Networking 으로 할당된 IP로는 호스트에서 접근이 불가능하다. 오직 같은 Internal Networking 으로 연결된 VM들간에만 통신이 가능하다.

Internal Networking 을 생성하는 방법은 터미널에서만 가능합니다. 아래 명령어를 통해 생성 및 삭제를 할 수 있습니다.

# testinet 이라는 이름의 Internal Network 생성
vboxmanage dhcpserver add --netname testinet --ip 10.10.10.1 --netmask 255.255.255.0 --lowerip 10.10.10.2 --upperip 10.10.10.240 --enable

# testinet 이름의 Internal Network 제거
vboxmanage dhcpserver remove --netname testinet

생성 후, VM 네트워크 설정 부분에서 Attach to 를 ‘Internal Network’로 선택하고, Name 에 위에서 설정한 이름인 testinet을 입력하면 됩니다.

Host-only Networking

Host-only Networking 은 Internal Networking 과 기능면에서는 동일하다. 하지만 다른점은 Host-only Networking 은 호스트와도 통신이 가능하다는 것이다.

그렇게 때문에 Virtualbox 를 사용하는 사용자들이 호스트에서 VM에 접속하고 싶을 경우, (예를 들면 VM에 웹 서버를 실행하고 호스트에서 접속) Host-only Networking 을 VM에 추가하여 사용한다. (이 경우 VM이 인터넷도 사용해야할 경우 NAT 까지 붙이기도 한다.)

Host-only Networking 은 OS X 의 경우 기본적으로 6개가 생성되어 있다. 이를 이용할 수 도 있고, NAT Networking 에서 확인한 환경설정 화면에서 Host-only Networks 로 들어가서 추가로 생성할 수도 있다.

Openstack Network 구축 과정 이해 – LinuxBridge

삐야악이 — Thu, 3 Oct 2019 23:22:27 +0900

그림1. Openstack Mitaka 설치가이드의 네트워크 구성도

Ubuntu 14.04 Openstack Mitaka Install Guide 에서는 위의 네트워크 구성도를 기반으로 설정을 진행합니다.. 이 그림만 봐서는 Provider Network 의 역할이 무엇인지, 그리고 대부분의 오픈스택의 네트워크 구성도와는 다른 모습이여서 이해하는데 많은 어려움이 있었습니다.

이 포스트에서는 Install Guide 에서 제시하는 네트워크 구성도에 대한 이해와, 그것이 내부적으로 어떻게 구성되는지 명령어단위로 하나하나 분석하면서 알아보도록 하겠습니다.

Openstack Network 종류

많이 공개된 오픈스택 네트워크 구성도를 보면 크게 아래와 같이 3가지 네트워크로 구성됩니다.

Management Network : 관리용 네트워크. 각 컴포넌트(Nova, Neutron 등)이 서로 API 를 호출하는데 사용됩니다.
Tunnel Network : vm instance 간 네트워크를 구축하는데 사용되는 네트워크입니다. GRE, VXLAN 등의 기술이 사용됩니다. Overlay Network 라고도 부릅니다.
External Network : vm instance 가 인터넷과 통신하기 위한 네트워크.

Host 머신에 오픈스택을 설치하기 위한 인터넷 연결으로는 별도의 네트워크를 연결하거나, Management Network 를 인터넷에 연결되도록 구성합니다.

그림1을 보면 오픈스택 설치 가이드에서는 Management Network 와 Provider Network 이렇게 두 가지의 네트워크로만 구성하고 있습니다. Provider Network 는 무엇이고 Tunnel / External Network 는 어디로 간 것일까요? 이것은 설치 가이드에 나오는 Provider / Self-Service Network 에 대해 먼저 이해하고, 가이드에서는 각각의 네트워크를 어떤 용도로 사용하는지 파악하면 알 수 있습니다.

Provider / Self-Service Network 란?

설치 가이드 문서의 Neutron 설정부분에서 네트워킹 서비스를 설정하기 위해서 2가지 옵션 중 한가지를 선택해야합니다.

Provider Network : 오픈스택을 서비스하는 사람이 구축한 네트워크가 vm instance 에 할당되는 네트워크입니다. 서비스하는 사람이 ‘제공’ 하는 네트워크라는 의미에서 Provider Network 라고 합니다. 이 네트워크는 인터넷에 연결이 되어있는 네트워크입니다. (그렇다고 public ip 를 반드시 가진다는 것은 아닙니다.)
Self-Service Network : 오픈스택을 사용하는 사용자(Tenant)가 직접 자신만의 vm instance 를 위한 네트워크를 구축할 수 있는 네트워크입니다. 이 네트워크는 provider network 를 기반으로 GRE, VXLAN 등의 터널링을 통해 구축됩니다.

이 두 가지 옵션과 위에서 설명한 3가지 네트워크 종류와의 연관성을 정리하면 다음과 같습니다.

Provider Network = External Network
Self-Service Network = Tunnel Network + External Network

Virtualbox 로 네트워크 구성하기

이제 오픈스택을 설치하기 위해, virtualbox 로 네트워크를 구성해보도록 하겠습니다.

Internet
- virtualbox의 NAT 인터페이스
- 오픈스택 설치용 네트워크
- IP : Controller / Compute 가 동일하게 10.0.2.15
Provider Network
- virtualbox 의 bridge 인터페이스
- 공유기와 연결된 인터넷을 사용할 수 있는 네트워크
- Controller IP : 할당하지 않음
- Compute IP : 할당하지 않음
- IP 대역 : 172.32.0.0/24
Management Network
- virtualbox 의 host-only network
- host에서 virtualbox 의 vm 에 접속할 수 있는 네트워크
- Controller IP : 192.168.56.101/24
- Compute IP : 192.168.56.102/24

Neutron 주요 설정

Neutron 설정은 Mitaka 설치 가이드의 Self-Service Network 부분대로 진행하였지만, 기록을 위해 주요 설정 부분을 보여드립니다.

Controller

/etc/neutron/plugins/ml2/linuxbridge_agent.ini

[linux_bridge] physical_interface_mappings = provider:eth1 [vxlan] enable_vxlan = True local_ip = 192.168.56.101 l2_population = True

[linux_bridge]
physical_interface_mappings = provider:eth1

[vxlan]
enable_vxlan = True
local_ip = 192.168.56.101
l2_population = True

Compute

/etc/neutron/plugins/ml2/linuxbridge_agent.ini

[linux_bridge]
physical_interface_mappings = provider:eth1

[vxlan]
enable_vxlan = True
local_ip = 192.168.56.102
l2_population = True

Self-Service 네트워크가 구축되는 과정

그림 2. Self-Service networks 개요도

그림 3. Self-Service networks 연결도

설치 가이드 문서의 Launch Instance 의 인스턴스를 위한 네트워크 구축 – Self-Service 파트 에서 위와 같은 구성도를 보여주고 있습니다.

이제 neutron 에서 네트워크, 서브넷, 라우터를 생성하면서 그림 3의 연결도가 어떤 명령어로 어떻게 생성되는지 하나하나 살펴보도록 하겠습니다.

Self-Service Network 는 provider network 를 통해 인터넷과 통신하기에, neutron에 provider network를 사용할 수 있도록 설정해주어야 합니다.

Create the provider network

# 모든 오픈스택 사용자가 사용할 수 있도록 shared 네트워크를 생성.
neutron net-create --shared --provider:physical_network provider \
  --provider:network_type flat provider

# 위에서 생성한 네트워크에 서브넷을 생성.
neutron subnet-create --name provider --allocation-pool start=172.32.0.100,end=172.32.0.200 --dns-nameserver 8.8.8.8 --gateway 172.32.0.1 provider 172.32.0.0/24

위 작업을 하고 나면 Controller 노드에 아래와 같이 구성됩니다.

Controller 노드에서 bridge 와 네임스페이스는 아래와 같이 구성되어있다.

# 리눅스 bridge 확인
$ brctl show 
bridge name bridge id       STP enabled interfaces
brqc1997735-77      8000.08002772b679   no      eth1
                            tape9fb1eac-9b

# 리눅스 네트워크 네임스페이스 확인
$ ip netns
qdhcp-c1997735-771e-463c-b64f-7724800bbb1a

$ sudo ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

2: ns-e9fb1eac-9b@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:07:a8:82 brd ff:ff:ff:ff:ff:ff
    inet 172.32.0.100/24 brd 172.32.0.255 scope global ns-e9fb1eac-9b
       valid_lft forever preferred_lft forever
    inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-e9fb1eac-9b
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe07:a882/64 scope link
       valid_lft forever preferred_lft forever

어떤 명령어들이 저런 구성을 완성했는지, neutron 서비스들의 디버그 메세지를 통해 확인해보겠습니다.

아래 내용은 구성을 위한 필수 명령어들만 정리한 내용입니다.

# 먼저 어디에선가 tape9fb1eac-9b 인터페이스가 만들어집니다 (어디서 만들어지는지 찾지 못했습니다. 명령어도..)

# DHCP Agent 에서 DHCP Namespace 생성하는 작업을 진행합니다.
ip netns add qdhcp-c1997735-771e-463c-b64f-7724800bbb1a
ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip link set lo up

# 이때 ns-e9 인터페이스가 생성되고, tape9fb 랑 연결됩니다.
ip link add tape9fb1eac-9b type veth peer name ns-e9fb1eac-9b netns qdhcp-c1997735-771e-463c-b64f-7724800bbb1a

ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip link set ns-e9fb1eac-9b address fa:16:3e:07:a8:82
ip link set tape9fb1eac-9b up
ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip link set ns-e9fb1eac-9b up

# dhcp 서버에 172.32.0.100 을 할당합니다.
ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip -4 addr add 172.32.0.100/24 scope global dev ns-e9fb1eac-9b brd 172.32.0.255

ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip -4 route replace default via 172.32.0.1 dev ns-e9fb1eac-9b

# dhcp 를 구성합니다.
ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/host --addn-hosts=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/opts --dhcp-leasefile=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/leases --dhcp-match=set:ipxe175 --bind-interfaces --interface=ns-e9fb1eac-9b --dhcp-range=set:tag0172.32.0.0static86400s --dhcp-option-force=option:mtu1500 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal

[Linux-Bridge-Agent] Bridge 생성

# 새로운 bridge 생성
brctl addbr brqc1997735-77
ip link set brqc1997735-77 up

# 인터페이스 추가
brctl addif brqc1997735-77 eth1
brctl addif brqc1997735-77 tape9fb1eac-9b

여기까지가 provider 네트워크를 생성했을 때 일어나는 일입니다. 여기서 compute 노드에 vm instance 를 생성하면, compute 쪽에서 provider bridge 가 생성되고 instance 와 연결되는 작업이 이루어집니다

이 부분은 self-service 네트워크를 생성 후, vm instance 를 만드는 것과 비슷한 작업이기에 아래에서 알아보도록 하겠습니다.

Create the Self Service Network

$ neutron net-create selfservice

$ neutron subnet-create --name selfservice --dns-nameserver 8.8.4.4 --gateway 172.16.1.1 selfservice 172.16.1.0/24

위와 같이 self-service network 와 서브넷을 생성하면 아래와 같이 구성됩니다.

그림을 보면 vxlan-70 이 eth0에 연결되어있는 것을 볼 수 있습니다. eth0 은 Management Network 로 할당된 인터페이스입니다.

이걸 통해서 Openstack Mitaka 설치 가이드에서는 Management Network 를 Tunnel Network와 같이 사용한다는 것을 알 수 있습니다.

사실 이것을 설명드리고 싶어서 이 문서를 작성한 것이 가장 큽니다. Management Network 를 통해서 Tunnel Network 를 사용하고 있었습니다.

[DHCP Agent] self-service dhcp namespace 생성

# 마찬가지로 tapb5ab7d31-e1 가 생성됩니다. 어디에선가..

ip netns add qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip link set lo up

# ns-b5ab7d31-e1를 생성하고 tabb5ab7d31-e1 와 연결합니다.
ip link add tapb5ab7d31-e1 type veth peer name ns-b5ab7d31-e1 netns qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899

ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip link set ns-b5ab7d31-e1 address fa:16:3e:76:6d:74
ip link set tapb5ab7d31-e1 up
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip link set ns-b5ab7d31-e1 up

# dhcp 서버 ip를 172.16.1.2 로 설정합니다.
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip -4 addr add 172.16.1.2/24 scope global dev ns-b5ab7d31-e1 brd 172.16.1.255

ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip -4 addr add 169.254.169.254/16 scope global dev ns-b5ab7d31-e1 brd 169.254.255.255
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip -4 route replace default via 172.16.1.1 dev ns-b5ab7d31-e1

# dhcp 기능을 활성화합니다.
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/host --addn-hosts=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/opts --dhcp-leasefile=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/leases --dhcp-match=set:ipxe175 --bind-interfaces --interface=ns-b5ab7d31-e1 --dhcp-range=set:tag0172.16.1.0static86400s --dhcp-option-force=option:mtu1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal

[neutron-linuxbridge-agent] bridge 생성

# vxlan-70 인터페이스를 생성하고, vxlan id 는 70로 설정하고 eth0 과 연결되도록 합니다.
ip link add vxlan-70 type vxlan id 70 dev eth0

ip link set vxlan-70 up

# 새로운 bridge 를 생성합니다.
brctl addbr brq34078f0c-3e
brctl stp brq34078f0c-3e off
ip link set brq34078f0c-3e up

# 인터페이스들을 추가합니다.
brctl addif brq34078f0c-3e vxlan-70
brctl addif brq34078f0c-3e tapb5ab7d31-e1
ip link set tapb5ab7d31-e1 up

Create a router

self-service network 와 provider network 를 연결해주는 라우터를 생성합니다.

$ neutron net-update provider --router:external

$ neutron router-create router

$ neutron router-interface-add router selfservice

위 작업을 하고 나면 아래와 같은 구성이 만들어집니다.

[l3-agent] router namespace 생성

# tap19d1547d-a0 가 어디에선가 생성됩니다.

# 새로운 namespace 를 만듭니다.
ip netns add qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set lo up
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 sysctl -w net.ipv4.ip_forward=1

# qr-19d1547d-a0 인터페이스를 만들고 tap19d1547d-a0 와 연결합니다
ip link add tap19d1547d-a0  type veth peer name qr-19d1547d-a0 netns qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set qr-19d1547d-a0 address fa:16:3e:02:b0:b9
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set qr-19d1547d-a0 up

# qr-19d1547d-a0 인터페이스에 self-service 네트워크의 게이트웨이로 설정하기 위해 172.16.1.1 를 할당합니다.
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip -4 addr add 172.16.1.1/24 scope global dev qr-19d1547d-a0 brd 172.16.1.255

[neutron-linuxbridge-agent] brq34078f0c-3e bridge 에 새로운 인터페이스 추가

# 이전에 만들어져있는 bridge에 router 와 연결되는 인터페이스를 추가합니다.
brctl addif brq34078f0c-3e tap19d1547d-a0

ip link set tap19d1547d-a0  up

‘router’ 이름의 라우터를 provide 네트워크의 gateway 로 설정

neutron router-gateway-set router provider

이 작업을 하고 나면 본격적으로 self-service 네트워크와 provider 네트워크가 연결되어, self-service 네트워크에서 인터넷으로 트래픽이 나갈 수 있게 됩니다.

구성은 아래와 같이 됩니다.

네트워크 인터페이스 구성

여기까지 왔을 때, controller 노드의 네트워크 인터페이스 구성은 아래와 같이 됩니다.

$ brctl show 

bridge name bridge id       STP enabled interfaces
brq34078f0c-3e      8000.7aa146e736c5   no      tap19d1547d-a0
                            tapb5ab7d31-e1
                            vxlan-70
brqc1997735-77      8000.08002772b679   no      eth1
                            tape01914d2-a0
                            tape9fb1eac-9b


$ sudo ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: qr-19d1547d-a0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:02:b0:b9 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.1/24 brd 172.16.1.255 scope global qr-19d1547d-a0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe02:b0b9/64 scope link
       valid_lft forever preferred_lft forever
// 새로 생성
3: qg-e01914d2-a0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:04:32:27 brd ff:ff:ff:ff:ff:ff
    inet 172.32.0.101/24 brd 172.32.0.255 scope global qg-e01914d2-a0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe04:3227/64 scope link
       valid_lft forever preferred_lft forever

[l3-agent] router namespace 에 인터페이스 추가

# tape01914d2-a0 가 어디에선가 생성

# qg-e01914d2-a0 를 생성하고, tape01914d2-a 와 연결합니다.
ip link add tape01914d2-a0 type veth peer name qg-e01914d2-a0 netns qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8

ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set qg-e01914d2-a0 address fa:16:3e:04:32:27
ip link set tape01914d2-a0 up
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set qg-e01914d2-a0 up

# qg-e01914d2-a0에 provide 라우터 인터페이스 ip로 172.32.0.101 을 할당합니다.
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip -4 addr add 172.32.0.101/24 scope global dev qg-e01914d2-a0 brd 172.32.0.255
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip -4 route replace default via 172.32.0.1 dev qg-e01914d2-a0

[neutron-linuxbridge-agent] brqc1997735-77에 인터페이스 추가

ip link set brqc1997735-77 up
brctl addif brqc1997735-77 tape01914d2-a0
ip link set tape01914d2-a0 up

여기까지 neutron 에서 provider / self-service 네트워크를 생성 및 설정할 경우 controller 노드에서 물리적(?)으로 어떤 작업을 통해 네트워크들이 구성되는지 확인해보았습니다.

이제 self-service 네트워크에 vm instance 를 생성해보고, 어떤 일이 일어나는지 확인해보겠습니다.

Self-service 네트워크에 vm instance 생성

vm instance 를 생성하면, controller 와 compute 에 작은 변화가 생깁니다. 우선 vm instance 를 생성하면 어떻게 구성되는지 아래 그림으로 확인해보겠습니다.

여기서 중요한 것은, compute 노드에서 vxlan70 인터페이스가 생성되고 그것을 통해 controller 노드와 연결이 되고 있는 것입니다.

이제부터 bridge 구성을 포함해서 어떻게 리눅스에서 vxlan 설정이 들어가는지 알아보도록 하겠습니다.

[compute node 의 neutron-linuxbridge-agent] etables 설정 / 새로운 bridge 생성 / vxlan 설정

# tap66aa1ee8-9b 이 생성된다.

# etables 설정 (이더넷 프레임에 대한 테이블)
ebtables -N neutronMAC-tap66aa1ee8-9b -P DROP
ebtables -A FORWARD -i tap66aa1ee8-9b -j neutronMAC-tap66aa1ee8-9b
ebtables -A neutronMAC-tap66aa1ee8-9b -i tap66aa1ee8-9b --among-src fa:16:3e:3f:4b:28 -j RETURN
ebtables -N neutronARP-tap66aa1ee8-9b -P DROP
ebtables -F neutronARP-tap66aa1ee8-9b
ebtables -A neutronARP-tap66aa1ee8-9b -p ARP --arp-ip-src 172.16.1.3 -j ACCEPT
ebtables -A FORWARD -i tap66aa1ee8-9b -j neutronARP-tap66aa1ee8-9b -p ARP

# vxlan-70 인터페이스를 생성하고 vxlan id 를 70으로 할당 후 eth0 에 연결되도록 설정
ip link add vxlan-70 type vxlan id 70 dev eth0
ip link set vxlan-70 up

# bridge 생성 및 인터페이스 추가
brctl addbr brq34078f0c-3e
brctl addif brq34078f0c-3e vxlan-70
brctl addif brq34078f0c-3e tap66aa1ee8-9b

# 여기에서 vxlan 터널링을 설정합니다.
# vxlan-70 의 모든 l2 트래픽의 목적지를 192.168.56.101 으로 설정
bridge fdb add 00:00:00:00:00:00 dev vxlan-70 dst 192.168.56.101

# 172.16.1.1 에 대한 목적지 ip 는 192.168.56.101, mac address 는  fa:16:3e:02:b0:b9 로 설정
# fa:16:3e:02:b0:b9 는 qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 의 qr-19d1547d-a0@if13 인터페이스 mac address
ip -4 neigh replace 172.16.1.1 lladdr fa:16:3e:02:b0:b9 nud permanent dev vxlan-70
bridge fdb replace fa:16:3e:02:b0:b9 dev vxlan-70 dst 192.168.56.101

# 172.16.1.2 에 대한 목적지 ip 는 192.168.56.101, mac address 는  fa:16:3e:76:6d:74 로 설정
# fa:16:3e:76:6d:74 는 qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 의 ns-b5ab7d31-e1@if10
# 172.16.1.2 는 self-service dhcp 서버 주소
ip -4 neigh replace 172.16.1.2 lladdr fa:16:3e:76:6d:74 nud permanent dev vxlan-70
bridge fdb replace fa:16:3e:76:6d:74 dev vxlan-70 dst 192.168.56.101

[controller node 의 neutron-linuxbridge-agent]

# vxlan-70 의 모든 l2 트래픽의 목적지를 192.168.56.102로 설정
bridge fdb add 00:00:00:00:00:00 dev vxlan-70 dst 192.168.56.102

# 172.16.1.3 은 instance ip
# 172.16.1.3 으로 가는 트래픽을 fa:16:3e:3f:4b:28 로 가도록 설정
# fa:16:3e:3f:4b:28 는 compute 노드의 tap66aa1ee8-9b 인터페이스 mac address
ip -4 neigh replace 172.16.1.3 lladdr fa:16:3e:3f:4b:28 nud permanent dev vxlan-70

// fa:16:3e:3f:4b:28 로 가는 트래픽의 목적지 ip 를 192.168.56.102 로 설정
bridge fdb replace fa:16:3e:3f:4b:28 dev vxlan-70 dst 192.168.56.102

여기까지 아주 긴 과정을 거쳐 provider network / self-service network 를 생성 및 설정이 이루어지는 방법을 알아보았습니다.

내용은 많지만 중요한 것만 정리하면 다음과 같습니다.

linuxbridge 를 이용하여 네트워크를 구축할 경우, linux bridge, namespace 를 이용해서 가상 네트워크를 구축한다.
linuxbridge 는 vxlan 만 지원하는데 이는, bridge 라는 명령어를 통해 vxlan 을 설정한다.
self-service 네트워크는 provider 네트워크를 통해 외부와 통신한다.

두서없이 정리하느냐 틀린 내용이나 누락된 내용이 있을 수 있습니다. 혹 발견하시면 댓글로 남겨주시면 감사하겠습니다.

특정 이름의 프로세스 죽이기

삐야악이 — Thu, 3 Oct 2019 23:05:54 +0900

kill -9 $(ps ax | grep '이름' | awk '{print $1}')