OpenStack summit austin 2016

OpenStack Summit Austin 2016

YongYoon. SHINhttp://uni2u.tistory.com

Let’s Talk

• Summary of OpenStack Summit

• OpenStack User Survey

• OpenStack Summit Keynote

• Networking SFC

• OpenStack and Container

• Container Network

SUMMARY OF OPENSTACK SUMMIT


• 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 여명


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 등과 같이 기술 성숙도 및 진척이 늦은 프로젝트에 대한 대안 고민 필요

The Next Summit

“O” Release Design SummitOctober 25~28, Barcelona, Spain

OPENSTACK USER SURVEY

OpenStack user survey_user perspectives

• Which emerging technologies interest OpenStack user?

https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf


OpenStack user survey deployments

• Which projects are OpenStack users most interested in?



OpenStack user survey deployment decisions

• Which OpenStack Network (Neutron) drivers are in use?



OpenStack user survey current issues

• Which Neutron features are actively used, interested in, or planned for use?



OPENSTACK SUMMIT KEYNOTE

What a big conference!!!

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

Keynote

• OpenStack “Mitaka” Release

– 178 Countries / 345 Organizations / 2,336 Developers

– 3,500,000 lines of code

– Speaker: Jonathan Bryce (Executive Director, OpenStack Foundation)

Keynote

• OpenStack user interested

– Containers, NFV/SDN, Bare Metal

– OpenStack already prepared

– Speaker: Mark Collier (Chief Operating Officer, OpenStack Foundation)

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

NETWORKING SFC

What is Service Function Chain ?

2016 OpenStack Summit Austin – Cathy Zhang – Realize SFC Using ONOS Controller

OpenStack Neutron Service Chain Architecture

OpenStack Service Chain API Overview

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

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

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 경로 지원

Proposed Change

• Data Model

Reclassification & Branching

Service Function Path

Service Function PathHop

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가 불분명할 경우에만, 트래픽 분류 기능이 수행

Proposed Change

• Architecture

Tacker+SFC 연동 구조

• Tacker에서 ODL SFC로 연결

– Neutron의 Network 정보 활용

• Tacker에서 VNFFGD 추가

• Tacker에서 Networking-SFC 활용

• ODL의 Neutron NB 이용

Service Chaining & Injection (1)

2016 OpenStack Summit Austin - Gal Sagie – Container Based Dynamic Service Chaining

Service Chaining & Injection (2)Attack Flow & Normal Flow

• Attack Flow

– Service 추가 (IPS)

– Manager에 IPS 수행 결과 통보

– Drop

• Normal Traffic

– Manager에 정상 트래픽 전달

– IPS를 거치지 않고, 바로 전달

ODL SFC와 vADC의 결합

2016 OpenStack Summit Austin - Michael OMalley – A better wheel using OPNFV for superior service

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

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 모델과 유사

– 트래픽 분류 기능의 제한

SFC MPLS/BGP VPN Approach

WHAT’S NEW IN MITAKA

Neutron Address Scopes?

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

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


• 주소 오버랩이 허용되지 않은 영역 (“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 불필요


• 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

L2GW를 이용한 Inter-Cloud 연결

2016 OpenStack Summit Austin – E. Gampel – Spanning your overlay network across clouds

OpenStack간의 L2 네트워크 확장

• More use case• L2 Border Gateway

• 다른 OpenStack간의 Overlay L2 네트워크 연결의 확장을 위해 필요

• Multi Region OpenStack

• Region 간의 L2 연결 지원

• Hybrid Cloud

• Public Cloud에서 동작하는 VPC 간의 연결 지원

l2-gateway-createl2-gateway-connection-createl2-remote-gateway-createl2-remote-gateway-connection-createl2-remote-mac-create

OPENSTACK AND CONTAINER

LXD… Docker… Mesos… etc

So many container services… But networks?

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-Serviceleveraging Heat, Nova, andNeutron.

Kolla Murano Kuryr

Containerizes the OpenStackcontrol services themselves asmicroservices to simplify theoperational experience.

Provides an application catalogof containerized applicationsthat can be deployed to anOpenStack cloud.

Brings the Neutron networkingmodel to containers. Providingconsistency between bare metal,virtual machines, and containers.

OpenStack with Container_User Story

• Stackanetes (CoreOS)

– OpenStack over Kubernetes

– Clustering Node = Seamless OpenStack service

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

Mesos and OpenStack

CONTAINER NETWORK

Current container network have a problem…

Network is always problem…

How can we solved in OpenStack

Problems with current Nested Containers Network

• Two Separate Networking infrastructures

• Hard to enforce network policy

• Security and isolation

• Performance and unneeded overhead of management

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

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

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

OpenStack summit austin 2016

Technology