open stack neutron dataplane 구현

1. Implementing
OpenStack Neutron
Dataplane
박성우
NHN Entertainment

2. CONTENTS
1. background
2. concept
3. implementing
4. future works

3. 1.
background of
NEUTRON networking

4. 1.1 OpenStack
major component
1. NOVA - Compute
I) Computing 자원을 관리하는 컨트롤러
II) VM, Container, Baremetal
2. NEUTRON - Networking
I) Networking 자원을 관리하고 구성하는 컨트롤러
II) multi-tenancy

5. 1.2 Neutron
networking
1. Network Model
I) Centralized
II) Distributed
2. Tenancy
I) IP Overlapping
ex)192.168.0.0/24, 10.0.0.0/8 as fixed IP address
II) Overlay
ex) VLAN, VxLAN …
3. SNAT, DNAT, DHCP, Firewall, LB …

6. 1.2 Neutron
control plane
1. micro architecture
Controller - Agent
2. Compute Node
ML2 Agent, L3 Agent, Metering Agent, Nova Compute …
3. Network Node
ML2 Agent, L3 Agent, Metering Agent, FW Agent …
4. API + RPC
HTTP & Message Queue

7. 1.2 Neutron
data plane
1. OVS
I) openvswitch - open flow를 이용한 packet flow 조절
II) ovs-ofctl, ovs-vsctl 등의 명령을 사용
2. linux를 이용한 data plane 구성
I) linux network function을 이용한 router구성
II) veth, router, firewall(iptables), NAT(iptables) …

8. 1.3 Network Model
centralized virtual router
1. 단순하고 명확한 구조
2. Network Node
I) SNAT
II) DNAT - Floating IP
3. Network Node 장애에 취약

9. 1.3 Network Model
distributed virtual router
1. 장애에 강한 분산 구조
2. Router들이 분산된 형태
I) C-Router = SNAT
II) D-Router = DNAT (Floating IP)
3. Control 부하가 높음

10. 1.4 DVR
perfect solution?
1. DVR은 좀 더 안전하다.
I) 장애에 좀 더 강하다.
II) Network Node의 장애와 무관해진다.
2. 단점은 없나?
I) Control RPC가 증가한다.
II) Neutron Server를 계속 늘려서 대응하고 있다.
III) Router가 증가할 수록 Sync 속도는 현저히 저하된다.

12. 1.5 Performance
linux network function
1. 배포판 Linux의 Networking은 빠르지 않다.
I) Router, iptables 등의 linux networking 속도가 최적화 되지 않는다.
II) 이 설정을 위해서 ‘ip’, ‘iptables’ 등의 명령을 반복적으로 수행한다.
III) 라우터가 증가할 수록 속도가 저하된다.
2. OVS
I) multi core를 충분히 활용하지 못한다.
II) flow rule이 증가할 수록 속도 저하가 심해진다.
III) rule을 추가하기 위해 command를 반복적으로 수행한다.
IV)코드 오류의 문제가 발생할 경우 panic으로 이어질 수 있다.

13. 1.5 Performance
internet gateway
1. Network Node는 SNAT 덩어리
I) Failover에 시간이 오래 걸린다.
II) Data plane 뿐만 아니라 Control plane에 부하가 크다.
2. 대부분 Floating IP를 많이 사용하기 때문에 사용 빈도가 낮음.
I) 하지만 없으면 동작하지 않음.

14. 1.6 Scalability
limitation
1. Isolation
I) BUM packet에 의한 network 성능 저하 발생
II) VLAN으로 제한이 되어도 TOR/Agg Switch는 BUM을 줄일 수 없음
ex) 10000개의 VM이 있다고 하면 하나의 vm이 ARP를 전송하면 모든 VM에 전달됨
3) CVR & DVR 방법 모두 L2를 적절히 제한 할 수 없는 구조 - 확장 한계
2. Control
1) Neutron Controller는 Agent들과 RPC를 수행
2) Node가 증가하면 RPC도 동시에 증가
3) Message Queue에 의한 Control 부하 증가에 따라 확장성이 저하됨

15. 2.
concept

16. 3.1 Approach
How to improve?
1. 확장성이 있어야 한다.
I) L2 격리가 반드시 필요하다
II) L3를 적극 이용하자
2. CVR, DVR 장점을 모아보자
3. HW 도움을 가급적 많이 받아보자
4. 성능이 낮은 부분은 개발한다
1. Router
2. VxLAN
3. OVS
5. 하지만 개발은 최소로 하자
I) Neutron은 손대지 말자
II) 보편적인 장비는 그냥 쓰자

17. 3.2 Scope
Isolated Network
1. 무엇이 될지는 모르겠지만 우리는 격리할 단위를 Scope이라 불렀다.
I) Scope은 L2가 도달하는 영역이다.
II) Scope 밖은 L3이다.
Overlay를 위해 Scope을 넘어 EP로 전달하는 방법은 역시 Tunneling이다.
어떤 것으로 할지는 선택이다.
III) 증설은 Scope 단위로 한다.
IV)Scope 내부는 Scope Controller의 vSwtich가 담당한다.
2. Compute Node 는 VM 구동에만 집중한다.
3. Region이 커진다 == Scope 수가 늘어난다.

18. 3.2 Scope
Neutron-Agent

19. 3.2 Scope
Neutron-Scope Controller

20. 3.2 Scope
How it works?
1. Scope 마다 DVR 존재
I) endpoint database
2. VLAN to VxLAN mapping
I) 동일 segment의 vlan은 scope 마다 다를 수 있다.
3. Scope 밖으로 L2 frame은 전달되지 않는다.
I) BUM 억제
II) VxLAN multicast는 Unitcast로 변환하여 전달.
III) Floating IP는 host-routes로 ARP 억제

23. 3.2 Scope
isolation
1. 동일 tenant에서
I) VNI는 Neutron이 지정
II) Scope 에 따라 VLAN이 다름.
III) 외부 연결은 각 Scope에서 결정.
2. 장애 발생시
I) 범위는 Scope에 한정

24. 3.3 Controller
back to back
1. controller
I) ML2 Agent, L3 Agent, Metering Agent
하나의 Compute Node 처럼보임
II) 각 Node 들에게는 Contoller로 보임
2. Database에 필요한 정보를 저장하여 RPC를 줄임

25. 3.3 Controller
OpenStack

26. 3.3 Controller
Scope API flow

27. 3.
implementing

28. 3.1 Components
goblin project
1. scope side
I) ML2 Agent, L3 Agent, Metering Agent, Firewall Agent
II) TOR vSwitch
2. neutron side
I) ML2 plugin - goblin driver
3. nova compute
I) network driver
II) goblin VIF driver

29. 3.1 Components
Scope Controller
1. VMs on TOP of Rack
I) Controller
II) vSwitch
III) DHCP

30. 3.1 Components
vSwitch
1. TOR switch
I) VM으로 동작
II) SRIOV
2. DHCP
I) Neutron DHCP Agent
II) Metadata Proxy
3. Ironic Conductor

31. 3.1 Components
internet gateway
1. TOR switch
I) VM으로 동작
II) SRIOV
2. SNAT
3. Load Balancer
4. Legacy Device

32. 3.2 Controller
goblin controller
1. Neutron 의 부하를 덜고 Scope이라는 개념을 추가 하기 위한 process
1. Neutron을 수정하기에는 범위가 크다.
2. 단순하게 보인다.
I) goblin이 대체하기 때문에 RPC가 적어진다.
II) Agent 가 단순해진다.
III) Recovery가 매우 빠르다.
2. Neutron에게 Compute Node 처럼 보인다.
1. 제약 사항은 있지만 OVS와 같이 동작할 수 있다.

33. 3.3 Compute
bridge & SRIOV
1. OVS & DVR 제거
I) 보통의 경우에는 linux bridge를 사용한다.
II) 고성능이 필요한 경우에는 SRIOV를 사용한다.

34. 3.3 Compute
bridge & SRIOV
2. Linux bridge
I) OVS를 제거하고 linux bridge + vlan 만으로 성능이 향상됨
II) multi core를 충분히 활용할 수 있음
3. PCI pass through
I) PCI device를 VM에 direct attach 하는 방식.
II) 최근 NIC 대부분이 이 기능을 지원.
III) bridge 방식보다 성능은 뛰어나고 CPU는 적게 소모

35. 3.3 Compute
implementing
1. network driver
I) NOVA network interface 구현
II) neutron에 직접 질의 하던 것을 controller를 통해서 수행
2. create linux bridge
I) overriding libvirtd VIF driver
II) implements goblin port

36. 3.4 Agent
SNAT, LB
1. LBaaS
I) Linux Network Interface 구현 내용을 변경
II) neutron에 직접 질의 하던 것을 controller를 통해서 수행
2. SNAT Agent
I) Network Node가 수행하던 SNAT 기능을 수행
II) 현재와 유사한 방법으로 구동
III) Interface 수정

37. 3.5 vSwitch
network segment for tenant
1. Segment
1. Endpoint Database
2. Firewall & NAT
3. Tunneling
4. Local Router
1. tenant의 subnet routers

38. 3.5 vSwitch
TOR vSwitch
1. Controller가 Segment를 생성/삭제
I) API로 구성 속도가 빠름
2. Scope Router
I) Floating IP, VTEP을 위한 router

39. 3.5 vSwitch
open source
1. Data Plane Development Kit
I) Intel 에서 주도하는 Open Source Project
II) Polling Mode Driver등의 기술을 사용하여 Packet을 빠르게 수신/발신 할 수 있다.

40. 3.6 Result
performance
1. vSwitch - SRIOV
1) Intel E5-2680v3 @ 2.5GHz x2
2) Intel X710 10G x2 - 64 vf / port
3) KVM 2 vCPU
4) Baremetal의 80% 정도
2. CPU Scheduling Issue
1) Scheduling에 따라 성능 차이가 나타난다.
MPPS Bridge L3NAT VxLAN
OVS 2.56 0.44 0.30
vSwitch 26.3

41. 4.
future works

42. 4.1 Migration
OVS & goblin
1. OVS와 goblin은 동시에 적용이 가능한 구조
I) 몇 가지 제약 조건을 해결한다면 운영중에 Migration이 가능하다.
II) 동작 중인 VM 및 서비스를 Live Migration으로 넘기거나
III) 새로 생성하는 경우에 goblin을 지정하는 경우
2. 이미 동작하고 있는 Node에서 Network 중단 없이는 어려움
1. 수 초 내외로 끊어지는 정도로 migration이 가능할 것

43. 4.2 Baremetal
ironic
1. baremetal on overlay
I) Ironic - baremetal provisioning
II) L2 Switch 제어를 통해 각 baremetal server들을 overlay에 연결
III) Agent plugin 구현

44. 4.3 Legacy Connectivity
legacy device
1. Overlay를 지원하지 않는 장비들을 연결
I) Load Balancers — L2 DSR, L3 DSR
II) Firewalls
III) VPN
2. Co-location service

45. Q & A

46. Thank you