일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- kolla
- k8s
- Docker
- awx
- ubuntu
- kolla-ansible
- nfs-provisioner
- HTML
- pacman
- port open
- Arch
- Linux
- ceph
- Octavia
- libvirt
- archlinux
- OpenStack
- golang
- KVM
- Kubeflow
- cloud-init
- terraform
- Ansible
- repository
- yum
- ceph-ansible
- i3
- grafana-loki
- Kubernetes
- cephadm
- Today
- Total
YJWANG
OVS 환경에서의 Openstack Network Deep Dive (Provider) 본문
OVS 환경에서의 Openstack Network Deep Dive
provider network instance
참고 :https://docs.openstack.org/liberty/networking-guide/scenario-classic-ovs.html
Down to Up으로 Interface들의 상관관계를 찾아나갈 것이다. 즉 VM 내의 Interface부터 시작해서 Provider Interface까지 어떻게 도달하는지가 물리적으로 확인하는 것이 목표이다.
현재 편의를 위해 Compute / Network / Storage / Controller는 모두 같은 Node에 구성돼있다. (All-In-One)
- 먼저 KVM 내의 VM과 Openstack Server 매핑 관계를 확인한다.
List를 먼저 확인해본다. virsh (KVM / Libvirt) 에서와 Openstack Server는 이름이 다르기 때문에 직관적으로 매핑 관계가 보이지 않는다.
Openstack에서 서버 이름은 중복이 가능하기에 ID값으로 관리되는 것으로 추측할 수 있다.
- Openstack
root@yjwang0-stack-11:~# openstack server list
+--------------------------------------+---------------+--------+-----------------------+-----------------+-------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+---------------+--------+-----------------------+-----------------+-------------+
| 9c45fce8-83d9-4518-9055-4df2899e23af | yjwang-test-1 | ACTIVE | provider=10.99.99.111 | centos-83.qcow2 | test-flavor |
| ec806aaf-4452-4300-918c-cea81915ad41 | yjwang-test-5 | ACTIVE | provider=10.99.99.115 | centos-83.qcow2 | test-flavor |
| fc5c58e3-5a6a-48d1-b701-65bf229d7d72 | yjwang-test-3 | ACTIVE | provider=10.99.99.113 | centos-83.qcow2 | test-flavor |
| 42aa68e8-982b-4f44-8545-01ecf19d6946 | yjwang-test-2 | ACTIVE | provider=10.99.99.112 | centos-83.qcow2 | test-flavor |
| 6f0eca6c-fec5-4eb6-9a3d-9c4e0fb38c4c | yjwang-test-4 | ACTIVE | provider=10.99.99.114 | centos-83.qcow2 | test-flavor |
+--------------------------------------+---------------+--------+-----------------------+-----------------+-------------+
- KVM
root@yjwang0-stack-11:~# virsh list
Id Name State
-----------------------------------
33 instance-00000022 running
34 instance-00000023 running
35 instance-00000025 running
36 instance-00000024 running
37 instance-00000026 running
yjwang-test-1
서버가 Libvirt에서는 어떤 서버인지 확인해보자. Libvirt 서버 내에서도 각 서버마다 UUID를 부여하므로 Openstack에서의 ID와 KVM UUID를 매핑시켜보자.
아래 명령을 통해 instance-00000025
= yjwang-test-1
임을 알 수 있다.
- Openstack
root@yjwang0-stack-11:~# openstack server list --name yjwang-test-1
+--------------------------------------+---------------+--------+-----------------------+-----------------+-------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+---------------+--------+-----------------------+-----------------+-------------+
| 9c45fce8-83d9-4518-9055-4df2899e23af | yjwang-test-1 | ACTIVE | provider=10.99.99.111 | centos-83.qcow2 | test-flavor |
+--------------------------------------+---------------+--------+-----------------------+-----------------+-------------+
- KVM
root@yjwang0-stack-11:~# virsh dominfo instance-00000025
Id: 35
Name: instance-00000025
UUID: 9c45fce8-83d9-4518-9055-4df2899e23af
OS Type: hvm
State: running
CPU(s): 2
CPU time: 5290.8s
Max memory: 8290304 KiB
Used memory: 8290304 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: none
Security DOI: 0
- yjwang-test-1 (instance-00000025) 서버의 interface와 물리 interface 관계 확인
서버는 eth0
(fa:16:3e:21:1b:4b) interface를 갖고있다.
[root@yjwang-test-1 ~]# ip l
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether fa:16:3e:21:1b:4b brd ff:ff:ff:ff:ff:ff
위 Interface는 Host의 어떠한 (virtual or physical) Interface와 Libvirt에 의해 Mapping 돼있을 것이므로 VM 정보를 통해 확인해본다.
root@yjwang0-stack-11:~# virsh dumpxml instance-00000025 |grep -i "<interface" -A 7
<interface type='bridge'>
<mac address='fa:16:3e:21:1b:4b'/>
<source bridge='qbrc3d70d5c-a9'/>
<target dev='tapc3d70d5c-a9'/>
<model type='virtio'/>
<mtu size='1500'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
위 명령을 통해 VM 내의 eth0
Interface는 qbrc3d70d5c-a9
bridge에 연결된 tapc3d70d5c-a9
Interface라는 것을 알 수 있다. 그림으로 하면 아래와 같이 된다.
이제 VM내의 Interface가 무엇인지는 찾아냈다. tap
Interface로 Packet을 주고 받는구나 라고 이해하면된다.
그럼 이제 저 tap
Device가 속한 qbr bridge는 무엇이고 저기와 연결된 곳은 또 어디인가 알아야한다.
- qbrc3d70d5c-a9 bridge의 연결 정보 확인
root@yjwang0-stack-11:~# brctl show qbrc3d70d5c-a9
bridge name bridge id STP enabled interfaces
qbrc3d70d5c-a9 8000.1229ce98c8ae no qvbc3d70d5c-a9
tapc3d70d5c-a9
위 명령어를 통해 qbrc3d70d5c-a9
bridge는 qvbc3d70d5c-a9
와 tapc3d70d5c-a9
가 연결된 bridge 임을 알 수 있다. tap
은 위에서 살펴본 것과 같이 VM에 eth0
과 맞물려있으므로 qvb
는 어디서 오는 것인지 알아야한다.
Interface 명을 보아하니 Open V Switch에서 만든 Virtual Interface임을 짐작할 수 있다.
- qvbc3d70d5c-a9 의 연결 정보 및 출처 확인
OVS 내에서 찾아보도록 하자. openvswitch_db
Container 내에서 찾아보자
OVS 에서 qvb
와 qvo
는 모두 virtual interface이나 veth로 peer됨을 볼 수 있다. 즉 qvb로 온 요청은 qvo로 가고 qvo로 온 요청은 qvb로 전달된다. (두 포트를 가상의 케이블로 연결했다고 보면 이해하기 편하다.)
root@yjwang0-stack-11:~# docker exec openvswitch_db ip link show type veth dev qvbc3d70d5c-a9
149: qvbc3d70d5c-a9@qvoc3d70d5c-a9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master qbrc3d70d5c-a9 state UP mode DEFAULT group default qlen 1000
link/ether 12:29:ce:98:c8:ae brd ff:ff:ff:ff:ff:ff
즉 qvbc3d70d5c-a9
와 qvoc3d70d5c-a9
가 연결돼있다.
- qvoc3d70d5c-a9 의 연결 정보 및 출처 확인
이제 qvoc3d70d5c-a9
는 어디와 연결돼있는지 확인해볼 필요가 있다.
이전과 마찬가지로 이도 bridge로 연결돼있을 확률이 높으므로 bridge들을 확인해보자.
우선 ovs-vsctl
명령어로 bridge list를 보면 아래와 같이 세개의 bridge가 있음을 볼 수 있다.
root@yjwang0-stack-11:~# docker exec openvswitch_db ovs-vsctl list-br
br-ex
br-int
br-tun
이름에서 유추할 수 있듯이 아래와 같이 생각하면 된다.
- br-ex : external bridge
- br-int : internal bridge
- br-tun : tunneling bridge
먼저 우리가 보고있는 서버는 provider
Network에 연결된 Instance이기 때문에 br-ex를 살펴보자
root@yjwang0-stack-11:~# docker exec openvswitch_db ovs-vsctl list-ports br-ex
ens3
phy-br-ex
br-ex
에는 qvoc3d70d5c-a9
가 없다. 위 내용은 나중에 살표보기로 하고 br-int
를 살펴보자
root@yjwang0-stack-11:~# docker exec openvswitch_db ovs-vsctl list-ports br-int
int-br-ex
patch-tun
qvo3f4287ae-89
qvo896252b2-9f
qvo89632c97-fd
qvo97cfa661-af
qvoc3d70d5c-a9
tapc91e441d-8c
br-int
bridge에 qvoc3d70d5c-a9
가 물려있음을 알 수 있다. 또한 br-int
에 다른qvo는 또다른 qbr에 연결돼있는 것으로 예측해볼 수 있고 지금은 int-br-ex
에 주목해보자.
root@yjwang0-stack-11:~# docker exec openvswitch_db ovs-vsctl show
1bda1c42-9cad-4bf5-87fa-39125a7ed2f9
Manager "ptcp:6640:127.0.0.1"
is_connected: true
Bridge br-int
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
datapath_type: system
...
Port int-br-ex
Interface int-br-ex
type: patch
options: {peer=phy-br-ex}
int-br-ex
는 phy-br-ex
와 peer돼있는 것을 볼 수 있다.
그리고 phy-br-ex
는 위에서 한 번 보고 지나갔던 br-ex
bridge에 물려있으며 해당 bridge는 ens3
Interface로 요청을 내보낸다.
root@yjwang0-stack-11:~# docker exec openvswitch_db ovs-vsctl list-ports br-ex
ens3
phy-br-ex
참고로 ens3
는 Openstack 구축 시 Provider Network로 지정한 Interface이다.
root@yjwang0-stack-11:~# cat /etc/kolla/globals.yml |grep -i neutron_external_interface
neutron_external_interface: "ens3
즉 여기까지 그림으로 살펴보면 아래와 같다.
Provider Network Interface는 위와 같은 과정으로 traffic이 In / Out 함을 이해할 수 있다.
[번외]
br-int에 있던 patch-tun 은 Self-Service Network Instance에대한 분석 때 알아보도록하고
br-int에 있던 tap interface는 qdhcp 서버에서 사용중이다.
root@yjwang0-stack-11:~# ip netns exec qdhcp-3c0896bd-16ef-4ca7-8cea-133862ffc400 ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
10: tapc91e441d-8c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fa:16:3e:1d:be:10 brd ff:ff:ff:ff:ff:ff
Provider network의 dhcp interface가 아래와 같이 지정돼있다.
root@yjwang0-stack-11:~# docker exec neutron_dhcp_agent cat /var/lib/neutron/dhcp/3c0896bd-16ef-4ca7-8cea-133862ffc400/interface
tapc91e441d-8c
3c0896bd-16ef-4ca7-8cea-133862ffc400
가 provider network 임은 아래에서 볼 수 있다.
root@yjwang0-stack-11:~# openstack network list
+--------------------------------------+----------+--------------------------------------+
| ID | Name | Subnets |
+--------------------------------------+----------+--------------------------------------+
| 3c0896bd-16ef-4ca7-8cea-133862ffc400 | provider | e2c60752-af94-4add-9198-28b13fb5317d |
+--------------------------------------+----------+--------------------------------------+