OpenStack2019.06.07 23:09

Hello, My blog vistors


How about your days? In my case, I am working about openstack security for my customer site. so I am very busy nowadays. But I have learend a lot of things like OpenStack, Container, Linux, Network and Security through this project.


In this post, I'd like to share about OpenStack Container Architecture and how to install and manage openstack services with container. Actually, Nowadyas I am working about openstack security. so I have thinking about how to set security vulnerable items in openstack container environment. 


I had to anaylsis openstack container environment and architecture. Because I had only installing docker exprience. so I didn't know commands for operating container environment well. But I can do it now. 


Anyway, I discovered that docker and host's directory mount to each mapped directory like below architecture. We can modify configuration of openstack services through host's mapped directory. And we can monitor openstack service logs also through the host's mapped directory. However we can't modified somthing inside docker operating system. If something modify inside docker operating system, docker's configuration will back after docker restart. The mean is that docker environment can't modify.

I was curious why container environment of RHOSP13(Red Hat OpenStack Platform 13) can't modify. I wanted to know how to launch and manage container for openstack services. so I was looking openstack documents and finding various things on the internet. And I noticed that OpenStack containers launch and manage using paunch. If you visit following the site (, you can see below contents.



Utility to launch and manage containers using YAML based configuration data



  • Single host only, operations are performed via the podman client.
  • Zero external state, only labels on running containers are used when determining which containers an operation will perform on.
  • Single threaded and blocking, containers which are not configured to detach will halt further configuration until they exit.
  • Co-exists with other container configuration tools. Only containers created by paunch will be modified by paunch. Unique container names are assigned if the desired name is taken, and containers are renamed when the desired name becomes available.
  • Accessable via the paunch command line utility, or by importing python package paunch.
  • Builtin debug command lets you see how individual containers are run, get configuration information for them, and run them any way you need to.


Debugging with Paunch

The paunch debug command allows you to perform specific actions on a given container. This can be used to:

  • Run a container with a specific configuration.
  • Dump the configuration of a given container in either json or yaml.
  • Output the podman command line used to start the container.
  • Run a container with any configuration additions you wish such that you can run it with a shell as any user etc.

The configuration options you will likely be interested in here include:

--file <file>                  YAML or JSON file containing configuration data

--action <name>        Action can be one of: "dump-json", "dump-yaml", "print-cmd", or "run"

--container <name>   Name of the container you wish to manipulate

--interactive                Run container in interactive mode - modifies config and execution of container

--shell                         Similar to interactive but drops you into a shell

--user <name>           Start container as the specified user

--overrides <name>   JSON configuration information used to override default config values


In the first paunch's features, it is [Single host only, operations are performed via the podman client]. I was curious about podman. So I searched about podman on the internet. The description what I found is like below. If you visit following site (, you can see podman more detail.



Libpod provides a library for applications looking to use the Container Pod concept, popularized by Kubernetes. Libpod also contains the Pod Manager tool (Podman). Podman manages pods, containers, container images, and container volumes.

Overview and scope

At a high level, the scope of libpod and Podman is the following:

  • Support multiple image formats including the OCI and Docker image formats.
  • Support for multiple means to download images including trust & image verification.
  • Container image management (managing image layers, overlay filesystems, etc).
  • Full management of container lifecycle.
  • Support for pods to manage groups of containers together.
  • Resource isolation of containers and pods.
  • Support for a Docker-compatible CLI interface through Podman.
  • Integration with CRI-O to share containers and backend code.

This project tests all builds against each supported version of Fedora, the latest released version of Red Hat Enterprise Linux, and the latest Ubuntu Long Term Support release. The community has also reported success with other Linux flavors.


After I learned about things that I want, I started to analysis RHOSP13 provisining process. RHOSP13 have undercloud and overcloud. Undercloud is for openstack deployment, Overcloud is for openstack service. In the undercloud node, it have installed various openstack packages for deploying openstack like below process. Ansible has playbooks that deploy openstack container service to overcloud. Ansible will deploy openstack to overcloud node using the playbooks. And It is step 5.


In the step 1, It will be common services tagging. Common services are like haproxy, Memcahed, RabbitMQ, MySql and Redis.

In the step 2, It will be Openstack services logging like below.

In the step 3, It will be OpenStack services DbSync. Ofcourse, these openstack services are all containers.

In the step 4, It will be OpenStack services configuration. 

In the last step 5, It will be Storage service configuration like cinder, cinder backup, conder volume and manila.


Today, I write about OpenStack container. Nowadays, Technical trend is moving to containers. However I think container is not perfect yet.  But It will improve continue. So I am interested about container technology. If I have any posting, I want to write about container architecture more deeply.


See you next time. Bye~~~

'OpenStack' 카테고리의 다른 글

OpenStack Container  (1) 2019.06.07
How to design OpenStack for Security  (0) 2019.05.28
Octavia Amphora Instance  (0) 2019.05.10
Load balancer as a service Octavia  (0) 2019.05.06
openstack heat template for create network and server  (3) 2018.03.13
Red Hat OpenStack Package Update Process  (3) 2017.09.29
Posted by 나리 짱!!! naleejang
OpenStack2019.05.28 22:44

Hello, My friends who visit to my blog.


How have you been these days? In my case, I have been working OpenStack project nowadays. so I am very busy and tired now. Actually, I wanted to post in English on my blog continue. but I have to had solving the virous problems everyday and everytime. so I didn't have any time for posting in English on my blog.


Today, I will share about how to design OpenStack for security before I forget that I get my OpenStack experiance. 

I visited site for checking OpenStack deployment methods. and I discoverd OpenStack architecture is changed. Now OpenStack is not using only virtual machines. We can use various resources like bare metal, virtual machines and containers.

What is OpenStack?

So how can we use our cloud resources more security? Openstack use REST API for using cloud resources. So it have http or https uri. Https is hypertext transfer protocol over secure. So https encrypted session data through ssl or tls protocol. ssl is secure socket layer. It needs certificate and secure key like below diagram.


Most OpenStack environment configured in data center. so it need many servers and there are many servers. Therefore we need to manage a lot of server's secure key and certification. How can we manage these keys and certifications?


Red Hat Openstack 13 can install ssl/tls using IDM server. IDM Server provides to manage users, domains, certificates and servers. For using ssl/tls with IDM Server, it needs domain of all Openstack  networks like below architecture.

Everywhere SSL/TLS with IDM Server

It has installed openstack packages in the director nodes. The packages are for installing openstack to other baremetal nodes. Let's see the process. 1. First, the director node registered domain to the IDM server. 2. And director will install controller and compute nodes with IDM server. 3. IDM server will check domain of overcloud's nodes and give the certificate to overcloud nodes.


If it finish to install openstack by director node, its system architecture is like below.

Nowadays OpenStack System Architecture

IDM server has apache httpd, ntp, dns, kerberos KDC, certmonger and SSSD(System Security Service Daemon)

Theses services provides features about manage overcloud nodes, domains, certificates and etc.

Director has openstack packages for overcloud(openstack for service) and docker. Because Openstack 13 version(queens) changed overcloud components. Previous openstack was installed only packages. Nowadays openstack main services are working in docker container.

If it install OpenStack with everywhere SSL/TLS, users can access by https based external network only. And each services can communicate with SSL/TLS only. The resources of OpenStack must certify by Keystone. If the certification is succesful, users can use OpenStack services. Also all networks of OpenStack isolated by network purpose. so If we design like below network, this OpenStack services will be secure. 

How to connect OpenStack Resources

How is this posting? If you have any opinion, please let me know it.

If I have free time, I will post about docker containers of openstack. 

'OpenStack' 카테고리의 다른 글

OpenStack Container  (1) 2019.06.07
How to design OpenStack for Security  (0) 2019.05.28
Octavia Amphora Instance  (0) 2019.05.10
Load balancer as a service Octavia  (0) 2019.05.06
openstack heat template for create network and server  (3) 2018.03.13
Red Hat OpenStack Package Update Process  (3) 2017.09.29
Posted by 나리 짱!!! naleejang
OpenStack2019.05.10 17:59

오늘은 지난 포스팅에 이어 이번에는 Amphora 인스턴스를 한번 파헤쳐볼까 합니다. 지난 포스팅에서 보았던 Amphora 인스턴스에 대한 아키텍처를 혹시 기억하시나요? 지난 포스팅에서 저는 Octavia가 뭔지? 그리고, Octavia를 이용하여 로드밸런서 생성까지 해보았습니다. 그때 테스트로 미리 생성해 둔 대역의 인스턴스들을 기억하시나요? 해당 설정을 적용하여 다시 그려본 아키텍처가 아래 그림입니다.



## How to connect octavia amphora instance

시스템을 운영하다보면 가끔 때로는 인스턴스에 직접 들어가 시스템 상태를 체크해야 할 경우가 종종 있습니다. 그때를 대비해서 시스템에 어떻게 접근을 하는지 알고 있다면 참 많은 도움이 되겠죠!!


Amphora 인스턴스에 접속을 하기 위해서는 우선 인스턴스에 접속하기 위한 고정 IP주소와 액세스를 하기 위한 ssh key가 필요합니다. IP주소는 대쉬보드의 인스턴스 목록에서 대역의 IP를 확인 할 수 있습니다. 앞에서 만든 인스턴스의 고정 IP 주소는이였습니다. 그리고, 필요한것은 ssh key입니다. 레드햇 오픈스택은 TripleO라는 배포 노드를 통해 오픈스택을 설치하는데 이때 설치과정에서 Octavia가 사용할 network, flavor, amphora image, security group, ssh key를 만들어 줍니다. 이때 사용되는 ssh key는 배포 노드의 stack 계정에 생성되어진 ssh public key와 private key를 사용합니다. 그러니 ssh key는 배포 노드의 stack 게정에 생성된 ssh private key를 컨트롤러 노드에 복사하면 되겠죠!!


1. 그럼, 복사한 ssh key를 이용하여 아래와 같이 amphora 인스턴스에 접속할 수 있습니다.

[heat-admin@con1 ~]$ ssh -i octavia_key cloud-user@

The authenticity of host ' (<no hostip for proxy command>)' can't be established.

ECDSA key fingerprint is SHA256:+R8/b/0Kc9LXoezkoCWDV7niPPjy/RLsNeJk5dPeBsg.

ECDSA key fingerprint is MD5:97:f5:87:b6:6c:aa:1c:82:7f:72:0e:2f:4a:5f:21:fa.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '' (ECDSA) to the list of known hosts.

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$ 


2. Amphora 인스턴스에 접속을 했습니다. 우선, 먼저 IP를 확인해 보겠습니다. 네트워크 디바이스는 eth0 하나이고, 고정IP 주소를 통해 들어온이 설정되어 있는것을 확인할 수 있습니다. 

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether fa:16:3e:01:c3:59 brd ff:ff:ff:ff:ff:ff

    inet brd scope global noprefixroute dynamic eth0

       valid_lft 65661sec preferred_lft 65661sec

    inet6 fe80::f816:3eff:fe01:c359/64 scope link

       valid_lft forever preferred_lft forever

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$


3. 이번에는 프로세스 목록을 확인해 보겠습니다. 프로세스 목록에서 우리는 amphora-agent가 실행이 되고 있고, haproxy 가 실행되고 있는것을 확인할 수 있습니다.

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$ ps -ef



root      3180     1  0 Apr22 tty1     00:00:00 /sbin/agetty --noclear tty1 linux

root      3181     1  0 Apr22 ttyS0    00:00:00 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt220

root      3184  2844  0 Apr22 ?        00:00:29 /usr/bin/python2 /usr/bin/amphora-agent --config-file /etc/octavia/amphora-agent.conf

root      3188     1  0 Apr22 ?        00:00:00 rhnsd

root      3191  2844  0 Apr22 ?        00:00:00 gunicorn: worker [gunicorn]

root      3234     1  0 Apr22 ?        00:00:00 /usr/sbin/sshd -D

root      3667     1  0 Apr22 ?        00:00:00 /usr/sbin/haproxy-systemd-wrapper -f /var/lib/octavia/aabe2b08-ebcb-4243-b411-33c24ecca342/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/oct

nobody    3795  3667  0 Apr22 ?        00:00:00 /usr/sbin/haproxy -f /var/lib/octavia/aabe2b08-ebcb-4243-b411-33c24ecca342/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/octavia/aabe2b08-eb

nobody    3796  3795  0 Apr22 ?        00:00:16 /usr/sbin/haproxy -f /var/lib/octavia/aabe2b08-ebcb-4243-b411-33c24ecca342/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/octavia/aabe2b08-eb


cloud-u+ 16522 16503  0 01:17 pts/0    00:00:00 ps -ef

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$


4. 그럼, VIP는 어디에 설정이 되어 있는걸까요? 우선, sudo 명령어를 이용하여 root 계정으로 전환한 후 ip netns 명령어를 이용하여 가상 네트워크를 확인해 보겠습니다. 가상 네트워크 목록에는 amphora-haproxy라는 가상 네트워크가 생성되어 있는걸을 확인할 수 있습니다.

[cloud-user@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]$ sudo -i

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]# ip netns show

amphora-haproxy (id: 0)

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]#


5. 가상 네트워크의 환경설정 정보를 확인해보면 아래와 같이 eth1이라는 가상 네트워크 디바이스와 인스턴스 목록에서 확인되었던 IP, 그리고 로드밸런서의 VIP를 함께 확인할 수 있습니다. VIP는 바로 여기 숨어 있었습니다. 

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]# ip netns exec amphora-haproxy ip a

1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether fa:16:3e:6d:d2:69 brd ff:ff:ff:ff:ff:ff

    inet brd scope global eth1

       valid_lft forever preferred_lft forever

    inet brd scope global secondary eth1:0

       valid_lft forever preferred_lft forever

    inet6 fe80::f816:3eff:fe6d:d269/64 scope link

       valid_lft forever preferred_lft forever

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]#


6. 그럼, 이번에는 haproxy 모듈의 환경설정 파일을 살펴보도록 하겠습니다. 앞에서 이미 프로세스 목록을 확인했습니다. 그리고, 프로세스 목록을 통해 haporxy 환경설정 파일이 어느 디렉토리에 위치하는지를 확인했습니다. 확인된 디렉토리에 들어가 ls 명령어를 이용하여 파일 목록을 확인해 보면 아래와 같이 UUID와 같은 디렉토리명과 conf 파일 하나를 확인할 수 있습니다. conf 파일을 내용을 확인해 보니 특별한 내용은 없는듯 합니다.

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf ~]# cd /var/lib/octavia/

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# ls

3c22219d-7c34-48f3-acf6-6e15f76ec9a1        haproxy-default-user-group.conf  plugged_interfaces

3c22219d-7c34-48f3-acf6-6e15f76ec9a1.sock                  plugged_interfaces.sorted

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# cat haproxy-default-user-group.conf


    group haproxy

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# 


7. UUID와 같이 보이는 디렉토리로 들어가서 파일 목록을 확인해 보면 haproxy.cfg라는 환경설정 파일을 확인할 수 있습니다.

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# ll

total 24

drwxr-xr-x. 2 root root 4096 Apr 22 21:28 3c22219d-7c34-48f3-acf6-6e15f76ec9a1

srw-rw-rw-. 1 root root    0 Apr 22 21:28 3c22219d-7c34-48f3-acf6-6e15f76ec9a1.sock

-rw-r--r--. 1 root root   25 Jan 10 10:32 haproxy-default-user-group.conf

-rwxr-xr-x. 1 root root  209 Jan 10 10:32

-rw-r--r--. 1 root root   23 Apr 22 21:26 plugged_interfaces

-rw-r--r--. 1 root root   23 Apr 22 21:26 plugged_interfaces.sorted

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf octavia]# cd 3c22219d-7c34-48f3-acf6-6e15f76ec9a1

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf 3c22219d-7c34-48f3-acf6-6e15f76ec9a1]# ls  haproxy.cfg

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf 3c22219d-7c34-48f3-acf6-6e15f76ec9a1]#


8. haproxy.cfg 파일 내용을 확인해 보니 로드밸런서를 생성할때 지정해 주었던 인스턴스들의 IP가 보이고, 로드밸런서 VIP도 확인할 수 있습니다.

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf 3c22219d-7c34-48f3-acf6-6e15f76ec9a1]# cat haproxy.cfg

# Configuration for cmp-was-lb



    user nobody

    log /dev/log local0

    log /dev/log local1 notice

    stats socket /var/lib/octavia/3c22219d-7c34-48f3-acf6-6e15f76ec9a1.sock mode 0666 level user

    maxconn 1000000



    log global

    retries 3

    option redispatch

    timeout connect 5000

    timeout client 50000

    timeout server 50000


frontend 3c22219d-7c34-48f3-acf6-6e15f76ec9a1

    option tcplog

    maxconn 1000000


    mode tcp

    default_backend 42e1058e-a298-42b3-83ce-1123c2d94547


backend 42e1058e-a298-42b3-83ce-1123c2d94547

    mode tcp

    balance roundrobin

    stick-table type ip size 10k

    stick on src

    timeout check 5s

    fullconn 1000000

    server 8d712f3b-1ee1-47ef-8c0a-4779fd044365 weight 1 check inter 5s fall 10 rise 10

    server a523158c-cddb-4528-b5bd-660971ff08a1 weight 1 check inter 5s fall 10 rise 10

[root@amphora-93b939b0-c1ff-48a0-a2f0-31378aaf5abf 3c22219d-7c34-48f3-acf6-6e15f76ec9a1]# exit

[heat-admin@con1 ~]$ 


이제 아래 그림이 이해가 가시나요? 왜 이런 그림이 나왔는지, 어떻게 동작하는지도 조금은 이해를 하셨으리라 생각이 듭니다.



이렇게해서, 2019년도 두번째 포스팅을 마무리해 봅니다. 모두들!!! 즐거운 주말되세요~~~

'OpenStack' 카테고리의 다른 글

OpenStack Container  (1) 2019.06.07
How to design OpenStack for Security  (0) 2019.05.28
Octavia Amphora Instance  (0) 2019.05.10
Load balancer as a service Octavia  (0) 2019.05.06
openstack heat template for create network and server  (3) 2018.03.13
Red Hat OpenStack Package Update Process  (3) 2017.09.29
Posted by 나리 짱!!! naleejang
OpenStack2019.05.06 20:19



그동안 어떻게 지내셨나요? 저는 그동안 여러 프로젝트를 하느라 정말 바쁜 나날을 보내고 있었습니다. 그래서, 블로그에 글을 올릴 시간조차 없었네요! 오늘도 사실은 영어로 포스팅을 하려고 하다가 시간도 너무 오래 걸리고, 영어로 바로 쓰려니 무슨말을 어떻게 써야할지 생각조차 나질 않더라구요! 그래서, 그냥 2019년에 처음으로 쓰는 블로그 글이니까 그냥 한글로 오랜만에 써보기로 했어요. 그리고나서, 다시 영어로 바꿔 쓰면 되니까요!!


오늘은 Octavia에 대해서 한번 써보려고 해요. 오픈스택이 뭘하는건지는 다들 아실테고, 오픈스택이 어떤 서비스로 이루어져 있는지도 다들 아실꺼라 생각이 듭니다. 아래 그림이 레드햇에서 제공하는 오픈스택 아키텍처입니다. 요즘 오픈스택에는 너무나도 많은 서비스들이 있기 때문에, 그 중에서도 가장 많이 사용하는 서비스들을 아래와 같이 레드햇에서 제공을 하고 있습니다. 


그럼, 오늘 이야기할 Octavia가 뭐냐구요? 뭐냐하면, 바로 Load Balancer 서비스입니다. 로드밸런서가 뭐냐구요? 로드밸런서는 한마디로 말해서 많은 사용자가 웹사이트를 사용할때 웹사이트의 부하를 분산해주는 부하 분산 처리기라고 할 수 있습니다. 종류도 L3(IP기반), L4(IP+Port 기반), L7(사용자 어플리케이션 기반) 으로 여러가지입니다.


아래 그림은 오픈스택의 Octavia라는 로드밸런서의 아키텍처입니다.

쉽게 이야기하면 사용자는 웹사이트를 접속하기 위해 Amphora라는 인스턴스에서 실행되는 https 또는 http 리스너를 통해 웹사이트에 접속을 합니다. 이때 접속할 웹사이트들의 집합을 Pool이라고 하고 웹사이트들을 Pool의 Member라고 합니다. 그리고, Member들이 잘 살아있는지, 정상적으로 동작을 하는지를 체크하는 모니터링 도구를 Pool Health Monitor라고 합니다.   


이렇게 Octavia에서 제공하는 로드밸런서는 아래와 같은 서비스들로 구성되어 있습니다.

- 로드밸런서

- Amphora 인스턴스

- 리스너(Listener)

- 풀(Pool)

- 멤버(Member)

- 헬스체크 모니터(Health-check Monitor)


여기서 가장 중요한 역할을 하는건 바로 amphora 라고 불리는 인스턴스입니다. amphora 인스턴스는 Red Hat Enterprise Linux 7.6 기반에 Haproxy 데몬이 설치되어 있습니다. 그리고, Octavia-agent가 Octavia-server로부터 명령을 받아 Listener를 생성하고 Haproxy에 환경설정을 하고 VIP를 Virtual Network로 생성을 하는 역할을 합니다. 그러면, 클라이언트는 Octavia-agent에 의해 생성된 VIP를 통해 Haproxy가 연결해주는 VM으로 접근을 하게 되는 것입니다. 



그럼, 이제 데쉬보드를 통해 로드밸런서를 한번 만들어 볼까요? 

레드햇 오픈스택 13 버전의 데쉬보드에서는 Project > Network > Load Balancers 메뉴를 통해 로드밸런서를 만들수 있습니다. 아래와 같이 메뉴를 찾아 들어가면 로드밸런서 목록을 확인할 수 있습니다. 그러나 생성된 로드밸런서가 없으니 아무것도 없겠죠! 


상단의 [+Create Load Balancer] 버튼을 클릭하면 아래와 같이 Load Balancer 화면이 뜹니다. 그러면, 아래와 같이 Name을 입력합니다. 이때 고정IP를 사용하고 싶다면 IP address에 사용하고자 하는 IP를 입력합니다. 그리고, 해당 IP가 포함된 서브넷을 선택합니다. 입력하지 않는다면 DHCP에 의한 IP가 할당됩니다.

- Name : 로드밸런서 이름

- Description : 로드밸런서 설명

- IP address : 로드밸런서로 사용할 VIP 주소

- Subnet: VIP가 포함된 네트워크 서브넷


이번에는 리스너를 만들어보겠습니다. 아래와 같이 리스너 Name, Protocol, Port를 입력합니다.

- Name: 리스너 이름

- Description: 리스너 설명

- Protocol: 프로토콜로 HTTP, TCP, UDP를 선택할 수 있음.

- Port: 리스닝을 할 포트

- Connection Limit: 접속 제한, -1은 제한을 하지 않겠다는 의미임


리스너 정보 입력이 끝나면 풀에 대한 정보를 입력합니다.

- Name: 풀 이름

- Description: 풀 설명

- Session Persistence: 세션 지속 방법

- Algorithm: 로드밸런서 방법


풀에 대한 정보 입력후 이번에는 멤버를 선택합니다. 앞에서 이미 서브넷을 선택했습니다. 따라서 해당 서브넷에 이미 생성된 인스턴스 목록을 Available Instances 에서 확인할 수 있습니다. 그럼, 로드밸런싱을 할 인스턴스를 2개 이상 선택합니다. 여기서는 앞에서 HTTP를 선택했기 때문에 자동으로 80 port가 설정되지만, 만일 TCP나 UDP를 선택했다면 해당 Port를 입력해야 합니다.


마지막으로 모니터링에 대한 정보를 입력합니다. 여기서는 모니터링 타입을 Ping으로 선택했습니다. 그리고, 하단의 [Create Load Balancer] 버튼을 클릭합니다.


그러면 로드밸런서 목록에서 아래와 같이 로드밸런서가 생성되고 있는것을 확인할 수 있습니다.


로드밸런서 생성이 완료되면 아래와같이 Provisioning Status가 Pending Create 에서 Active로 변경됩니다.


생성이 완료된 로드밸런서에 외부에서 접속이 가능할 수 있도록 Floating IP를 설정해 보도록 하겠습니다. Floating IP를 할당할 로드밸런서 우측 버튼을 클릭하여 [Associate Floating IP] 버튼을 클릭하고 아래와 같이 External IP나 서브넷을 선택하고 하단의 [Associate] 버튼을 클릭합니다.


할당된 IP는 로드밸런서 상세정보에서 아래와 같이 확인할 수 있습니다.


상세정보에서 Listeners 탭을 클릭하면 아래와 같이 리스너 목록을 확인할 수 있습니다.


리스너 목록에서 리스너를 클릭하면 아래와 같이 리스너 정보와 풀 목록을 확인할 수 있습니다.


풀 목록에서 풀을 클릭하면 해당 풀의 상세정보와 함께 Health Monitors와 Members 목록을 확인 할 수 있습니다.


생성된 로드밸런서용 amphora 인스턴스는 관리자 계정으로 들어가서 Admin > Compute > Instances 메뉴에서 아래와 같이 확인할 수 있습니다.



이제 로드밸런싱이 제대로 되는지 테스트를 해보도록 하겠습니다. 컨트롤러 노드에서 ip netns를 명령어를 이용하며 가상 네트워크 및 라우터 정보를 확인할 수 있습니다. 테넌트 네트워크가 포함된 라우터 정보를 ip netns exec 명령어를 이용하여 해당 테넌트의 VIP에 curl를 실행하면 아래와 같이 로드밸런싱이 되는 것을 확인할 수 있습니다. 또한 연결해 준 Floating IP로 curl를 실행하면 역시 로드밸런싱이 되는것을 확인 할 수 있습니다.

[root@overcloud-controller-0 ~]# ip netns exec qrouter-355b554a-a5a2-4ff5-878f-1fb3f0de6509 curl 

Welcome to

[root@overcloud-controller-0 ~]# ip netns exec qrouter-355b554a-a5a2-4ff5-878f-1fb3f0de6509 curl

Welcome to

[root@overcloud-controller-0 ~]# curl

Welcome to

[root@overcloud-controller-0 ~]# curl

Welcome to

[root@overcloud-controller-0 ~]#



이렇게 해서 오픈스택의 로드밸런서 서비스인 Octavia에 대해서 알아보았습니다. 다음에는 Octavia 인스턴스에 접속을 해서 Octavia가 어떻게 구성이 되었는지 확인해 보도록 하겠습니다. 

Posted by 나리 짱!!! naleejang