osm in practice...microservice architecture to enable extensibility osm stack lxd nbi elk stack...

© ETSI 2018

OSM IN PRACTICEGerardo García (Telefónica), Technical Steering Committee

Gianpietro Lavado (Whitestack), MON Module Development Lead

© ETSI 2018

OSM Release THREE Overall Architecture (OLD)

2

Highly functional, but with some opportunities for enhancement:

● NBI tightly coupled to SO

● Difficult to add new modules to extend functionality

© ETSI 2018

Architectural decisions1) Keep layered communication to VIMs and VNFs

NFVI

NS#1VNF 1

VNF 2

VNF 3

VCA ROCharm

VIM controller

VIM controller

VIM controllers

Charm

CharmOVIMplugin

OSTplugin

VMWplugin

AWSplugin

© ETSI 2018

Architectural decisions2) Decouple NBI from NS and VNF LCM

SO

NBI

LCM

© ETSI 2018

Architectural decisions3) Message bus, common DB and object storage

Object Storage

CommonDatabase(NoSQL)

Kafka busNBI

Any other module

© ETSI 2018

OSM Release FOUR Architecture

6

Kafka bus

Object Storage

Common Services

ROVCA

OSM IM

OSM IM


OSM IM

NBIOSM IM

osmclient

New OSM’s NBI

MON

LCM

light-ui

N2VC

POL

Integrated components for policy, fault and performance management

Lightweight Life Cycle Manager (LCM)

Unified Northbound Interface (SOL005-based), decoupled from LCM

Complete control through CLI and stand-alone new UI

Common DB and object storage

5

3

2

1

OSM IM Message bus for asynccommunications

4

6

© ETSI 2018

Extending the plugin model to other modules

ROOVIMplugin

OSTplugin

VMWplugin

AWSplugin

MONOST

pluginVMWplugin

AWSplugin

Common DBMONGO

pluginFS

plugin

NBI RBACKeystone

plugin

Message busKafkaplugin

FSplugin

Object StorageCephplugin

FSplugin

VNF metricsplugin

ODLplugin

ONOSplugin

Floodl.plugin

ODL WIMplugin

TAPIplugin

© ETSI 2018

Microservice architecture to enable extensibility

OSM stack

LXD

NBI

ELK stack

Perf. Mon. stack

VCA(juju controller)

MONGO

Kafka

Zookeeper

LCM RO RO-DB

POL

MON

Light-UI

Elasticsearch Logstash Kibana

Prometheus Grafana

Add here your stack

docker X docker ynetOSMdocker network

© ETSI 2018

From design to operation

9

Design Onboarding Instantiation NS LCMService

Operation

© ETSI 2018

DesignDescriptors and packages, result of the design phase

10

VNF package

VNFD

VNFartifacts

Additional metadata?

Resource description aspects

VNF resource orchestration info(EPA resources and internal

connectivity)

Management procedures

VNF primitives- Day-1- Day-2

Charms

Icon, README, etc.

Additional info

© ETSI 2018

DesignDescriptors and packages, result of the design phase

11

NS package

NSD

NSartifacts

Additional metadata?

Resource description aspects

NS topology

Management procedures

NS primitives- Day-1- Day-2

Charms

Icon, README, etc.

Additional info

© ETSI 2018

DesignWhat is a charm?

• A charm is a set of actions and hooks• Actions are programs• Hooks are events/signals

• For commodity and reusability, those actions and hooks are grouped in layers

• A charm will always have one layer:• That layer has some actions and hooks• In addition, that layer can import other layers

• The resulting charm has all the actions and hooks from all the layers joined together, plus additional default actions and hooks (e.g. ‘config’ action)

12

© ETSI 2018

DesignCharm design

NEW LAYER

red greenlayers

‘config’ action

actions

hooks

© ETSI 2018

DesignImplementing actions

@when('actions.touch')

def touch():

err = ''

try:

filename = action_get('filename')

cmd = ['touch {}'.format(filename)]

result, err = charms.sshproxy._run(cmd)

except:

action_fail('command failed:' + err)

else:

action_set({'outout': result})

finally:

clear_flag('actions.touch')

© ETSI 2018

DesignCharm build

© ETSI 2018

Primitives are mapped to charm actions in the descriptor

16

vnfd:

...

vnf-configuration:

juju:

charm: aaa

initial-config-primitive:

- seq: '1'

name: getConfigurationFromEMS

parameter:

- name: ems-ip-address

value: '/home/ubuntu/first-touch'

config-primitive:

- name: touch

parameter:

- name: filename

data-type: STRING

- name: addUser

parameter:

- name: userName

data-type: STRING

© ETSI 2018

Onboarding

17

Kafka bus

Object Storage

Common Services

ROVCA

OSM IM

OSM IM


OSM IM

NBIOSM IM

osmclient

New OSM’s NBI

MON

LCM

light-ui

N2VC

POL

OSM IM

CRUD operations overVNF and NS packages godirectly to the CommonDB and Object storage, without travelling through the Kafka bus

© ETSI 2018

NS instantiationDeployment + Day 0 + Day 1

18

Kafka bus

Object Storage

Common Services

ROVCA

OSM IM

OSM IM


OSM IM

NBIOSM IM

osmclient

New OSM’s NBI

MON

LCM

light-ui

N2VC

POL

OSM IM

1. NBI creates record in common DB

2. NBI publishesmessage in Kafka:instantiate NS_id

3. LCM consumes themessage and deploysthe NS

4. Deployment andday-0 configuration

5. Day-1 configuration(parametrized)

© ETSI 2018

Service Operation

19

Kafka bus

Object Storage

Common Services

ROVCA

OSM IM

OSM IM


OSM IM

NBIOSM IM

osmclient

New OSM’s NBI

MON

LCM

light-ui

N2VC

POL

OSM IM

1. NBI publishesmessage in Kafka

2. Consumer module depends on thespecific primitive(day-2 operationprimitives are consumed by LCM, on-demand metricexport and alarmconfiguration are consumed by MON.

© ETSI 2018

Instantiation process summary

21

ROmodule

LCMmodule

NBI

OSM CLI OSM Light UIUnified NBI lets users manage

the NS lifecycle

MONmodule

POLmodule

starts monitoring VNF according to descriptor!

creates alarms through MON based on thresholds

takes care of VIM resources

takes descriptors and sends instructions to the bus

OSM KAFKA BUS

© ETSI 2018

Demo 1: Metrics collection and visualization

22

MONmodule

(1) MON collects VIM/VNF metrics and

stores in TSDB

(2) Prometheus reads and stores selected VNF metrics

(3) Grafana presents

selected VNF metrics

Optional tools

OSM TSDB

VNFmetrics

through N2VC-VCAmodules

© ETSI 2018

Demo 2: Auto-scaling action!

23

MONmodule

(1) MON notifies POL about an alarm being triggered

OSM KAFKA BUS

POLmodule

(2) POL submits an action to the bus based on descriptor logic (i.e. SCALE)

LCMmodule

(3) LCM instructs the system to generate the scaled instances

OPTIONAL toolsAn optional ELK

(or similar) logging analytics stack can inform about anything going on through the bus or logs

© ETSI 2018

Conclusions

25

• Regarding monitoring, OSM Release FIVE will:

• Monitor VNF metrics

• Support auto-scaling actions

• Include its own TSDB

• Enhance integration with external logging analysis stacks like ELK

osm in practice...microservice architecture to enable extensibility osm stack lxd nbi elk stack...

Documents