OpenStack summit austin 2016 summary

1. OpenStack Summit Austin 2016
YongYoon. SHIN
http://uni2u.tistory.com

2. Let’s Talk
• Summary of OpenStack Summit
• OpenStack User Survey
• OpenStack Summit Keynote
• Networking SFC
• OpenStack and Container
• Container Network

3. SUMMARY OF OPENSTACK SUMMIT

4. OpenStack Summit Austin 2016
• OpenStack Mitaka (2016.1) 공식 발표 이후 개최된 총회이자, Newton Design Summit 과
병행
• 공식적으로 약 7,800 여명이 참석한 역대 가장 큰 규모의 행사
– OpenStack Design Summit 2010 (‘10.11) : 250 여명
– OpenStack Summit HongKong 2013 (’13.11) : 4,000 여명
– OpenStack Summit Atlanta 2014 (’14.05) : 4,500 여명
– OpenStack Summit Paris 2014 (‘14.11) : 4,600 여명
– OpenStack Summit Vancouver 2015 (‘15.05) : 6,000 여명
– OpenStack Summit Tokyo 2015 (‘15.10) : 5,000 여명

5. OpenStack Summit Austin 2016

6. OpenStack Summit 정리
• Big Tent 모델 도입 이후의 변화
– 다양한 새로운 프로젝트 활동들이 제안되고 소개됨 (개방과 혼돈)
– 그러나, 핵심 기능에 대한 개발 속도는 다소 저하된 듯함
– 전체적으로 Summit 프로그램의 구성에 있어서도 예전과 달리 체계적으로 정리되지 못한 느낌임
– Enterprise Cloud의 핵심 기능은 안정성이나 적용사례 등이 충분하나, 확장 기능 및 SDN/NFV 응용에 있어서는 다소 개발시간이
소요될 듯 함
• 우리 나름의 OpenStack Deployment Model 수립 필요
– OpenStack Core Project (6개) 이외의 프로젝트간 통합 및 검증 노력 요구
– 특히, Neutron의 SFC, DVR, L3 HA, LBaaS, VPNaaS, FWaaS 등 다양한 확장 기능에 대한 통합 및 검증 노력 요구
– Ceilometer 등과 같이 기술 성숙도 및 진척이 늦은 프로젝트에 대한 대안 고민 필요

7. The Next Summit
“O” Release Design Summit
October 25~28, Barcelona, Spain

8. OPENSTACK USER SURVEY

9. OpenStack user survey_user perspectives
• Which emerging technologies interest OpenStack user?
https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

10. OpenStack user survey deployments
• Which projects are OpenStack users most interested in?
https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

11. OpenStack user survey deployment decisions
• Which OpenStack Network (Neutron) drivers are in use?
https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

12. OpenStack user survey current issues
• Which Neutron features are actively used, interested in, or planned for use?
https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf

13. OPENSTACK SUMMIT KEYNOTE
What a big conference!!!

14. 약 7,500명!!!
체감 10,000명 이상!!!

15. Keynote
• OpenStack “Mitaka” Release
– 178 Countries / 345 Organizations / 2,336 Developers
– 3,500,000 lines of code
– Speaker: Jonathan Bryce (Executive Director, OpenStack Foundation)

16. Keynote
• OpenStack user interested
– Containers, NFV/SDN, Bare Metal
– OpenStack already prepared
– Speaker: Mark Collier (Chief Operating Officer, OpenStack Foundation)

17. AT&T Cloud Journey
• Mobile Data growth
– must transform building networks
• ACI (AT&T Integrated Cloud)
– Open-whitebox HW
• Virtualized & Controlled by AIC
– Lower cost & High speed/Agility
– Goal
• 75% of network using cloud infra and SDN by 2020

18. NETWORKING SFC

19. What is Service Function Chain ?
2016 OpenStack Summit Austin – Cathy Zhang – Realize SFC Using ONOS Controller

20. OpenStack Neutron Service Chain Architecture

21. OpenStack Service Chain API Overview

22. SFC in ONOS Architecture
OpenStack Networking-SFC
(ONOS SFC Driver)
ONOS NBI for SFC
Functions
ONOS SFC Manager
SB API for SFC Provisioning on
the Device

23. SFC (v1)의 문제점
• Neutron API 확장 (OpenStack/Networking-SFC)
 정해진 순서에 따른 VM간 Traffic Steering
 특정 트래픽 분류 조건
• 현재의 문제점
 SFC Encapsulation (NSH, MPLS, ..?)
 Reclassification and Branching
 Network Transport Protocol
 SFC Proxying
 Criteria for Elasticity and Load Balancing
 SFC Symmetry
• 새로운 SFC API 제안 (표준과 연동되는 형태)
 기존의 Port Chaining 기반 방식의 요구 존재
https://review.openstack.org/#/c/308453/2/specs/newton/ietf-compliant-sfc-api.rst

24. Networking-SFC Phase 2
• Container 및 Physical Device 형태의 SF를 위한 Chaining 지원
• Tacker 연동 지원
• Open Source SDN Controller Driver 지원
– ODL SFC Driver, OVN SFC Driver, Dragonflow SFC Driver
• IETF NSH Encapsulation 지원
• 대칭적인 SFC 경로 지원

25. Proposed Change
• Data Model
 Reclassification &
Branching
 Service Function Path
 Service Function Path
Hop

26. Proposed Change
• Example of high-level view
Instance Selection Policy
(same to Scheduling Algorithm (ODL))
->Elastic & Load Balancing
 Without SFC encapsulation ("legacy" mode) : 모든 노드를 기준으로 패킷 분류 기능 수행
 With SFC Encapsulation 방식 : Next hop SF가 불분명할 경우에만, 트래픽 분류 기능이 수행

27. Proposed Change
• Architecture

28. Tacker+SFC 연동 구조
• Tacker에서 ODL SFC로 연결
– Neutron의 Network 정보 활용
• Tacker에서 VNFFGD 추가
• Tacker에서 Networking-SFC 활용
• ODL의 Neutron NB 이용

29. Service Chaining & Injection (1)
2016 OpenStack Summit Austin - Gal Sagie – Container Based Dynamic Service Chaining

30. Service Chaining & Injection (2)
Attack Flow & Normal Flow
• Attack Flow
– Service 추가 (IPS)
– Manager에 IPS 수행 결과 통보
– Drop
• Normal Traffic
– Manager에 정상 트래픽 전달
– IPS를 거치지 않고, 바로 전달

31. ODL SFC와 vADC의 결합
2016 OpenStack Summit Austin - Michael OMalley – A better wheel using OPNFV for superior service

32. 6 Top Challenges for Using OpenStack for D-NFV
• Binding Virtual Network Interface Card to the Virtual Network
Function
• Service Chain Modification
• Securing OpenStack over the Internet
• Scalability of the Controller(s)
• Start-up Storms (Or Stampedes)
• Backward Compatibility between Release
2016 OpenStack Summit Austin – T. Khan – Distributed NFV & OpenStack Challenges and Potential Solutions

33. OpenStack Networking-SFC V1/V2
• “Port Group” 기반 메커니즘
– API 사용 용이
• SFC 기능 수정 요구
– “A standards-compliant SFC API”
• SFC v2의 목표
– Resource 및 Service 관리 분리
– IETF 호환 (Meta-data, NSH 등)
– Instance 선택 정책 부재
– 현재의 모델은 SFF Proxy 모델과 유사
– 트래픽 분류 기능의 제한

34. SFC MPLS/BGP VPN Approach

35. WHAT’S NEW IN MITAKA
Neutron Address Scopes?

36. Neutron Address Scopes
• Motivation
– NAT : External 및 Private 네트워크 분리
• 사용자 자체 주소 할당
• IPv6에서는 NAT 사용 없음
– Mitaka에서 BGP를 이용한 announcing private networks
– L2VPN/L3VPN에서 BGP 동작 라우팅 개선 필요
– 라우팅 도메인 분리 필요
– 라우팅 도메인 내에서 IP 주소 오버랩 방지 필요
• Subnet Pools
– Subnet 할당을 위한 주소 영역
• Tenant에 전용 할당 및 Tenant간 공유
– 참고
• https://blueprints.launchpad.net/neutron/+spec/subnet-allocation
2016 OpenStack Summit Austin – Carl Baldwin – Neutron Address Scope

37. Neutron Subnet Pools
• Subnet에 할당할 수 있는 주소 영역
• Subnet 객체가 subnetpool_id attribute를 갖고 있음
– Subnet Pool의 UUID
– 역방향 호환성을 위해 기본은 Null
– Subnet Pool이 지정되면, CIDR은 필요 없음
– CIDR이 지정되면, Subnet Pool에 포함된 영역 중에서 할당.
– Subnet pool은 subnet의 overlap 불허
• Subnet Pool Quotas
– IPv4의 경우 주소기반으로 Quota 할당 : x/24 -> 256
http://docs.openstack.org/developer/neutron/devref/address_scopes.html

38. Neutron Address Scopes
• 주소 오버랩이 허용되지 않은 영역 (“The thing within which address overlap is not allowed”)
• Mitaka 이전
– 암시적인 하나의 공유 주소 영역. 주소 오버랩 가능
– 서로 다른 Tenant간 라우팅 불가 . 외부 네트워크와 내부 네트워크 간 NAT 이용 -> Tenant가 각자의 Address Scope를 갖는 것과 비슷
• NAT가 없는 경우나, Tenant간 연결을 지원할 필요가 있음
• Routing
– Address Scope 내: 자유롭게 라우팅
– Address Scope 간 : 라우팅 방지 (NAT에 의한 전달만 가능), Floating IP 이용 가능
• RPC
– L3 Agent : 라우터의 각 포트에 대한 Address Scope를 알 필요가 있음
– Subnet은 동일한 subnet pool 이용 (동일한 Address Scope)
• L3 Agent
– 트래픽이 Ingress에서 Marking (트래픽을 보낸 Network 정보 표시) -> 다른 Address Scope의 인터페이스로 전달될 경우 Block
– Floating IP 트래픽의 경우 예외 동작 : Floating IP로 전달되면 DNAT 적용. Floating IP에서 외부로 전달 가능
– 내부에서 외부로 전달될 경우에 SNAT 적용하면 예외 동작 : 외부 네트워크가 명시적인 Address Scope를 갖고, 내부 네트워크와 Address Scope와 동일하면 NAT 불필요

39. Neutron Address Scopes
• Subnet Pools support Address Scopes
– Address overlap 방지
– Subnet pools은 subnet 할당 관리
– Address scopes는 라우팅 도메인을 분리
– Subnet pools은 Address scopes를 지원하기 위한 Accounting Mechanism
– Address scopes 내 다중 pool
• 호환성 유지
– Aggregation instead of Composition
• Subnet pool 없는 subnet 가능
• Address scope 없는 subnet pool 가능
– The “no scope” scope
• Subnet pool 없는 모든 subnet 포함
• Address scope 없는 모든 subnet 포함
• Constraints are relaxed
– 임의적인 주소 overlap 허용
– 원하는 주소 모두 사용 가능
– Private IPv4 주소와 외부 주소와의 암묵적인 NAT
– and the external network

42. L2GW를 이용한 Inter-Cloud 연결
2016 OpenStack Summit Austin – E. Gampel – Spanning your overlay network across clouds

43. OpenStack간의 L2 네트워크 확장
• More use case
• L2 Border Gateway
• 다른 OpenStack간의 Overlay L2
네트워크 연결의 확장을 위해 필요
• Multi Region OpenStack
• Region 간의 L2 연결 지원
• Hybrid Cloud
• Public Cloud에서 동작하는 VPC 간
의 연결 지원

45. l2-gateway-create
l2-gateway-connection-create
l2-remote-gateway-create
l2-remote-gateway-connection-create
l2-remote-mac-create

46. OPENSTACK AND CONTAINER
LXD… Docker… Mesos… etc
So many container services… But networks?

47. OpenStack project for container
Nova Heat Magnum
A Docker hypervisor driver for
Nova Compute to treat containers
and images as the same type of
resource as virtual machines.
A plugin template for
orchestrating Docker resources on
top of OpenStack resources.
Allows access to full Docker API.
Provides an API to manage multi-
tenant Containers-as-a-Service
leveraging Heat, Nova, and
Neutron.
Kolla Murano Kuryr
Containerizes the OpenStack
control services themselves as
microservices to simplify the
operational experience.
Provides an application catalog
of containerized applications
that can be deployed to an
OpenStack cloud.
Brings the Neutron networking
model to containers. Providing
consistency between bare metal,
virtual machines, and containers.

48. OpenStack with Container_User Story
• Stackanetes (CoreOS)
– OpenStack over Kubernetes
– Clustering Node = Seamless OpenStack service

49. Containers.. more faster, more light
• LXD (canonical)
– LXD provides machine containers
• Application container
– Linux container(LXC) hypervisor
• more container, more faster, more light
– Dozens of LXD instances launch in seconds
– Service migrate in real time
– OpenStack mitaka plugin
– REST API for managing system containers

50. Mesos and OpenStack

51. CONTAINER NETWORK
Current container network have a problem…
Network is always problem…
How can we solved in OpenStack

52. Problems with current Nested Containers Network
• Two Separate Networking infrastructures
• Hard to enforce network policy
• Security and isolation
• Performance and unneeded overhead of management

56. Nested Container Networking in OpenStack
• Nested/baremetal container to nested/baremetal container
same/different hosts
• Nested/baremetal container to virtual machine communication
• Nested/baremetal container to baremetal communication
• Container networking as a first class entity in Neutron
• Consistent policy enforcement across containers, VMs, bare metal
• Enable advanced networking services like FWaas, LBaas, VPNaas etc

60. Container Networking in OpenStack Next Step
• Follow up on the Neutron Trunk port implementation
• Finish COE(Container Orchestration Engine) baremetal integration
– Policy translation
– Make Neutron resources available through native APIs
• Magnum deployment prototype of worker VM with Kuryr agent
• Magnum administrator VM that communicates with Neutron

61. Containerizing Network Services
• Scalability
– Container scale-out with the number of available compute nodes
• High Availability
– Seamless failover on container or compute failure
• Container Health
– Report the running status of the network service software
• Container Migration
– Cloud operator tools to manage network service containers
• Scheduling Policies
– Container affinity, host selection and fate-sharing