YJWANG

OVS 환경에서의 Openstack Network Deep Dive (Provider) 본문

60.Cloud/60.OpenStack

OVS 환경에서의 Openstack Network Deep Dive (Provider)

왕영주 2021. 3. 11. 16:08

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)

  1. 먼저 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
  1. 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는 무엇이고 저기와 연결된 곳은 또 어디인가 알아야한다.

  1. 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-a9tapc3d70d5c-a9 가 연결된 bridge 임을 알 수 있다. tap은 위에서 살펴본 것과 같이 VM에 eth0과 맞물려있으므로 qvb는 어디서 오는 것인지 알아야한다.

Interface 명을 보아하니 Open V Switch에서 만든 Virtual Interface임을 짐작할 수 있다.

  1. qvbc3d70d5c-a9 의 연결 정보 및 출처 확인

OVS 내에서 찾아보도록 하자. openvswitch_db Container 내에서 찾아보자

OVS 에서 qvbqvo는 모두 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-a9qvoc3d70d5c-a9 가 연결돼있다.

  1. 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-exphy-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 |
+--------------------------------------+----------+--------------------------------------+
반응형