using openstack to accelerate new product development: rik harris, telstra

OpenStack Australia Day 2016

Rik Harris – Telstra

Use Case: Telstra using OpenStack to

accelerate new product development

©2016 Telstra Corporation Limited ABN 33 051 775 556

This presentation is intended to provide personal observations about using OpenStack to develop a service provider product.

Examples and diagrams are illustrative only.

It is not intended to provide guidance on Telstra’s products and services.

The content is not to be used without the author’s permission.

Dynamic Network – Customer Benefits

Empowering business with unified on demand ICT services

Unified ProductExperience

Help increase customers

speed to market

Increaseservice velocity

Fasteractivation

Platform forinnovation

Goal


The Dynamic Network

Orchestration

Virtualisation (NFV)

Software defined networking

InfrastructureCustomer Premises Core Cloud

CustomerDC

ManagedRouter

NTUServiceEdge

CloudEdge

SaaS

Bandwidth

On DemandPath Selection

High

Availability

Dynamic

DDOS

Self

Healing

11000101 1010

0100

11000101 1010

0100

11000101 1010

0100

11000101 1010

0100

11000101 1010

0100

11000101 1010

0100

11000101 1010

0100

11000101 1010

0100

vFirewall vAnalyticsvRouter


Network Overview

Cisco Intercloud Services (OpenStack)

Next IP®

Gateway

customer Next IP®

(MPLS) VPN

customer

sites

other

customer

projects/

tenancies

Dynamic

Networks

Application

project/

tenant

Dynamic

Networks

VNF

project/

tenantcustomer traffic

portal traffic

Telstra core systems

mgmttraffic Internet


Tenancy Architecture – ApplicationVMSaaS Application OpenStack project

Man

agem

ent

VP

NM

anag

emen

t V

PN

VNF ManagementVRF

VNF ManagementVRF

VN

F M

anag

emen

tV

NF

Man

agem

ent

Telstra core systems

Pu

blic

Inte

rnet

Pu

blic

Inte

rnet

Loca

l In

tern

et (

NA

T)Lo

cal I

nte

rnet

(N

AT)

Internetneutron router

Internetneutron router

NSONSO

ESCESC

Clo

ud

Fo

un

dry

Clu

ste

r

Internet

Tran

siti

on

Tran

siti

on

Tran

siti

on

Tran

siti

on

VNF Managementneutron router


Symphony VPNneutron router

Symphony VPNneutron router

©2016 Telstra Corporation Limited

ABN 33 051 775 556

ESC, NSO and

VMS are Cisco

products.

Tenancy Architecture – VNFVNF OpenStack project

VN

F M

anag

emen

tV

NF

Man

agem

ent

VNF ManagementVRF

VNF ManagementVRF

Internet

Inte

rnet

Dir

ect

(no

NA

T)In

tern

et D

irec

t (n

o N

AT)

Cu

sto

mer

2C

ust

om

er 2 ASAvASAv

Customer 2 VPN

Cu

sto

mer

1C

ust

om

er 1

Customer 1 VPN

WSAvWSAv

ASAvASAv

Tran

siti

on

Tran

siti

on

Cu

sto

mer

3C

ust

om

er 3

CSRCSR

ASAvASAv

WSAvWSAvVNF Management

neutron router


Next IP® Gateway

Next IP® Gateway


CSR, ASAv and

WSAv are Cisco

products.

Orchestration Architecture

VN

FA

pp

lica

tio

nVMSApplication Control Plane

Data Plane

Cisco ESC

Next IP® Gateway

Internet

OpenStack API

Customer Site

Next IP®(MPLS)

VPN

Customer Site

Customer Site

Network Orchestrator

VNF 2

VNF 1 VNF 3

Portal/UI

Cisco NSO

Portal User


ESC, NSO and

VMS are Cisco

products.

Benefits of using OpenStack

SpeedInitial development

environments

New application

environments for testing



FlexibilityExperiment with

environment structure

prior to go-live

VNF Environments

expand based on

demand


environments

New application




InnovationEasy to try

(and abandon)

new product ideas

Sandboxes for ongoing

experimentation

FlexibilityExperiment with

environment structure

prior to go-live

VNF Environments

expand based on

demand


environments

New application




ConnectivityDirect connectivity available to

Telstra’s Next IP® (MPLS) network

Granular control over traffic flows

(ACLs) – orchestrated as part of VNF

deployment



Automation(Close to) full automation of

application deployment using

Cloud Foundry

Opportunity for full test automation,

including network elements

ConnectivityDirect connectivity available to

Telstra’s Next IP® (MPLS) network

Granular control over traffic flows

(ACLs) – orchestrated as part of VNF

deployment


Observations & Challenges

• Geographical locations for VNFs currently limited to CIS points of

presence.

• Using public cloud platform means we (mostly) can’t change the

underlying platform capabilities.

• Mix of neutron and VNF-based networking fitted our needs.



• Generally run 6-8 environments

concurrently, plus development.

• Automation tools capabilities

with OpenStack remains

nascent – Puppet, Chef,

Ansible, Salt.


Puppet, Chef, Ansible and

Salt are trademarked by

their respective owners







Ansible, Salt.

• Ansible 2.0 (beta, at the time)

provided best support, but…











Ansible, Salt.



---- name: create environment testing serveros_server:state: presentcloud: "{{ Symphony_Project }}"name: env-test-{{ Symphony_Project }}image: testimagekey_name: symphony-testingtimeout: 200flavor: Micro-Smallfloating-ips:- 200.199.198.197

security_groups:- testservers

nics:- net-name: "{{ Symphony_Internet_Name }}"- net-name: "{{ Symphony_Network_Name }}"











Ansible, Salt.



---- name: create environment testing serveros_server:state: presentcloud: "{{ Symphony_Project }}"name: env-test-{{ Symphony_Project }}image: testimagekey_name: symphony-testingtimeout: 200flavor: Micro-Smallfloating-ips:- 200.199.198.197

security_groups:- testservers

nics:- net-name: "{{ Symphony_Internet_Name }}"- net-name: "{{ Symphony_Network_Name }}"

Non-deterministic






• Lots of virtual networks!




• But they’re mostly managed

by orchestration so we never

have to use the topology

view.




• But they’re mostly managed

by orchestration so we never

have to use the topology

view.

• Too many routes and ACLs

to handle manually, even in

the application projects.



• Needed to provide access

to OpenStack CLI and

Ansible tools to various

people

• However the dependencies

are still messy

• Docker to the rescue!



• Needed to provide access

to OpenStack CLI and

Ansible tools to various

people

• However the dependencies

are still messy

• Docker to the rescue!

$ cat DockerfileFROM ubuntu:15.10ARG DEBIAN_FRONTEND=noninteractiveARG TERM=linuxRUN apt-get -y updateRUN apt-get install -y sudo make git pythonRUN apt-get install –y python-setuptools python-pip fping jqRUN apt-get install –y vim python-dev ssh-clientRUN pip install shade

RUN git clone git://github.com/ansible/ansible.git --recursiveRUN cd ./ansible && \

make install && \mkdir -p /etc/ansible && \echo '[local]\nlocalhost ansible_connection=local\n' \

> /etc/ansible/hosts

RUN useradd -d /home/symphony -M -G sudo symphonyUSER symphonyADD 90-symphony /etc/sudoers.d/90-symphony

# default command: display Ansible versionWORKDIR /home/symphony/SymphonyCMD [ "ansible-playbook", "--version" ]


Future Direction and Ideas

• More VNF types, greater variety of product offerings, integration with

more networks, etc.

• Extend automated testing from unit and system to full integration.

• Use additional (still OpenStack) VNF environments to improve

geographic options.

• Enhance Ansible OpenStack modules.


using openstack to accelerate new product development: rik harris, telstra

Technology