OpenStack Collaboration Made in
Heaven
06.11.2017
Trinath Somanchi Bharath ThiruveedulaSridhar Ramaswamy,
Ex-PTL, Tacker CISCO NXP VERIZON INDIA
Dharmendra KushwahaNEC
with Tacker, Heat, Mistral and more…
OverviewCross project Collaboration
Need for Collaboration
Understanding the Do’s and Don’t
Case Study
Illustration using Tacker
Agenda
Features - Collaboration with
OpenStack Projects
Collaboration with Heat, Networking-sfc, Mistral and more
Collaboration beyond OpenStack
OPNFV, CNCF, Kubernetes and many more
Summary
Collaboration = Best in class features
Overview
Collaboration is crucial in the land of open source,
and with the rapid growth of projects and
communities, cross-project and cross-community
activities are more important than ever.
Libraries
Sub Projects
Projects
External Communities
Microservices Philosophy
Make each program do one
thing well. To do a new job, build a fresh rather than complicate old programs by adding new "features".
Expect the output of every program
to become the input to another, as yet unknown, program. Don't
clutter output with extraneous information
Design and build software, even
operating systems, to be tried early,
ideally within weeks. Don't
hesitate to throw away the clumsy parts and rebuild
them.
Use tools in preference to
unskilled help to lighten a
programming task, even if you have to detour to build the tools and expect to
throw some of them out after you've finished
using them.
Microservices follows UNIX philosophy which was proposed by Douglas McIlroy
Required for OpenStack
Doing the right feature under right project
umbrella
Embrace Micro Services design
patterns
Collaboration
Collaboration beyond Openstack – Always possible to replace OpenStack project with another project which can complete the feature
– Operators.
Require a Official OpenStack
Project status
Vendor specific feature implementation
Need for Collaboration
Design of New feature
Auto deployment of existing features.
Making something around and within
OpenStack.
Require existing features to your own project.
Going beyond OpenStack, embed external
projects.
Management
Server
Event Service
Authorization
Service
Key Mgmt
Service
Logging
Service
Monitoring
Service
Usage
Tracking
Service
Image
repository
service
Project A
Compute
Services
Storage ServicesNetwork
Services
Neutron
Kuryr
Dragon
Flow
Tacker
Nova
Glance
Magnum
Zun
Cinder
Swift
Manila
Freezer
Identity and
WorkflowKeystone Barbican Mistral
Monitoring
&
Management
Aodh
Ceilometer
Horizon
Monasca
Need for Collaboration
Features – Collaboration with other projects
Feature Collaboration with Projects
TOSCA template based Orchestration of VNFs HEAT, TOSCA-PARSER
Monitoring Framework, Alarm Monitoring Mistral, Ceilometer
VNF Forwarding Graph Networking – SFC
Secured VIM credentials Barbican
Virtual Infrastructure Management Nova, Neutron, Glance and Keystone
Configuration, Logging Oslo libs
TOSCA-Parser, HEAT-Translator and Tacker
TOSCA Parser
• Parser for TOSCA simple profile in YAML and NFV YAML based specification
• Sub-project of OpenStack - HEAT
HEAT Translator
• OpenStack project to map and translate non-HEAT templates to Heat Orchestration Templates (HOT).
• Sub-Project of OpenStack - HEAT
Tacker
• NFVO and VNFM – NFV block in OpenStack
• All Tacker VNFDs, VNFFGs and NS description files are TOSCA YAML files.
ETSI NFV TOSCA
YAML OpenStack
Tacker
(VNFM and
NFVO)
NSD
VNFD
VNFFGD
Data models
OpenStack Heat
TOSCA Parser
Heat
Translator
Compute Networking Storage Compute Networking Storage Compute Networking Storage
VIMVIM VIM
Multi Site VIM Support
Heat - OpenStack orchestration engine that automates launching
multiple composite cloud applications.
Heat-Translator - map and translate non-Heat (e.g. TOSCA)
templates to Heat Orchestration Template (HOT).
Tosca-Parser - for TOSCA Simple Profile in YAML
Heat ?
Mistral and Tacker
Network Service Descriptor (NSD)
• Mistral driver between NFVO and VNFM will translate TOSCA template into workflow which in turn instantiate a Network Service.
• Mistral Driver will call Mistral interfaces for Network Service requests.
• Wait in PENDING_CREATE state for NS until all VNFs goes to ACTIVE state.
• Decide to move forward/backward in case of partial failure.
Scalable VNF Monitoring
• Mistral is an integral part of tacker system, a long-live Mistral workflow action can be used to do this kind of task.
• Tacker server will generate a VNF monitoring workflow and execute it if there is a VNF configured with monitor policies.
• When the workflow is removed, the VNFM plugin will kill the mistral action via MSG queue
Scalable VIM Monitoring
Long-live mistral workflow.Tacker server will generate a VIM reachability test workflow and execute it if a new vim is registered.The workflow and execution will be removed once the vim is de-registered from tacker server.
Tacker Server Mistral Workflow Conductor Server
DB
Mistral is a workflow service. Most business processes consist of
multiple distinct interconnected steps that need to be executed in
a particular order in a distributed environment.
One can describe such process as a set of tasks and task
relations and upload such description to Mistral so that it takes
care of state management, correct execution order, parallelism,
synchronization and high availability.
Mistral also provides flexible task scheduling so that we can run a
process according to a specified schedule (i.e. every Sunday at
4.00pm) instead of running it immediately.
We call such set of tasks and relations between them a workflow.
Mistral ?
1 2
3
Ceilometer and Tacker
Tacker
(TOSCA)Alarm Framework Ceilometer
The Ceilometer project is a data collection service that provides the ability
to normalise and transform data across all current OpenStack core
components with work underway to support future OpenStack components.
Ceilometer is a component of the Telemetry project. Its data can be used to
provide customer billing, resource tracking, and alarming capabilities across
all OpenStack core components.
Ceilometer
Ceilometer?
1 2
Monasca
Custom
Driver
VNF
• ETSI MANO architecture describes to monitor the VNF to take appropriate action such as fault
management, performance management. Monitoring became an important aspect in MANO
architecture.
• Monitoring Policy in TOSCA template – for single and Multiple VDUs.
• Default backend actions : scaling, respawn, log, and log_and_kill.
Networking-SFC with Tacker - VNFFG
• Abstract VNFFG TOSCA definitions are rendered into
Service Function Chains (SFCs) and Classifiers.
• The SFC makes up an ordered list of VNFs for traffic to
traverse, while the classifier decides which traffic should go
through them.
• Similar to how VNFs are described by VNFDs, VNFFGs are
described by VNF Forwarding Graph Descriptors (VNFFGD).
• After creating a VNFFGD, a VNFFG is instantiated by a
separate Tacker command. This action will build the chain
and classifier necessary to realize the VNFFG.
Service Function Chaining Extension for OpenStack Networking
Fundamentally SFC is the ability to cause network packet flows to route
through a network via a path other than the one that would be chosen by
routing table lookups on the packet’s destination IP address.
It is most commonly used in conjunction with Network Function
Virtualization when recreating in a virtual environment a series of network
functions that would have traditionally been implemented as a collection of
physical network devices connected in series by cables.
Networking-sfc ?
NFVO / VNFM / VNFFG API
Tacker
HeatNeutron
(networking-sfc)
SDN Controller
OVSDB
OVSDB
VNF
vRouter VNF 1 VNF 2
Compute Node A
OVSDB
VNF
DPIVNF 1 VNF 2
Compute Node A
VNFDVNFD
VNFDVNFFGD
VNFDNSD
1
2
3
4
Tacker with Nova, Glance, Keystone, Neutron
Keystone, Glance, Nova and Neutron (Core Services)
– Provide the Virtual Infrastructure Management required for
VNF management in Direct and Indirect mode by VNFM or NFVO.
Neutron, networking-sfc supports VNF Forwarding Graph.
Nova
Neutron
Glance
Cinder Keystone
Tacker
Tacker – uses OpenStack CORE
services to manage the VNFs. OpenStack
with its CORE services forms the VIM.
Barbican with Tacker
Designed for the secure storage, provisioning and management of
secrets. It is aimed at being useful for all environments, including
large ephemeral Clouds.
* Secrets API. It provides access to the secret / keying material stored
in the system, including Private Key/Certificate/Password/SSH Keys
* Secret Metadata API. It allows a user to be able to associate various
key/value pairs with a Secret.
* Containers API. It creates a logical object that can be used to
hold secret references.
* ACL API. It supports access control for secrets and containers.
* Certificate Authorities API. It is used as an interface to interact
with Certificate Authorities.
* Quotas API. It limit on the number of resources that are allowed
to be created.
* Consumers API. It is a way to register as an interested party
for a container.
Barbican ?
Why to collaborate with a OpenStack project that deals with Security?
Tacker supports registering VIM with credentials, which are used by NFVO and VNFM to operate resources in
NFVI. The credentials include username, password, and project information.
When Tacker Server is behind a load balancer, then the operation will fail if the request is not
fulfilled by the server node which created and stored the fernet key. We need a possible solution for syncing
the keys across multiple server nodes. This adds operational complexity for tacker administrators as they add
tacker-server instances for scaling.
Tacker uses Barbican’s Secrets API to restore the password of VIM. And in
future, we can use Barbican to support TLS in Tacker API
Oslo Libraries
Oslo – brings deployment and development experiences consistent across OpenStack projects.
•OpenStack projects share many common design patterns and implementation details.
•Early in the history of OpenStack this resulted in a lot of code being copied out of one project into another.
•The Oslo project was created to address this situation, and to provide a home for common code used by multiple other OpenStack projects.
•Adopting oslo libraries makes a project more similar to the rest of OpenStack, and that consistency in turn improves the Operator/Deployer experience.
Well known Oslo Libraries (not limited to) –
oslo.config : Provides tools for managing configuration option definitions, validation, configuration file
parsing, and command line option processing.
oslo.messaging: Implements common inter-process communication patterns such as notifications and
RPC. It includes drivers for different backends such as RabbitMQ, AMQP 1.0, and ZMQ. This pluggable
backend pattern is common across OpenStack as a way to provide options for deployers familiar with
different tool stacks.
oslo.log: Wrapper around Python’s standard logging tools, coupling them with oslo.config and applying
OpenStack-specific requirements.
Tacker Architecture
Heat
OpenStack
Nova &
Neutron
Infra
Driver
Tacker
NFVO / VNFM / SFC API DB
Monitoring
Driver
Management
DriverSFC Driver
SDN Controller
OVS
Mgmt NetTenant Net
Trend
Micro
VNF
VNFVPN
VNF
6Wind
Turbo
RouterMngrMngr
Monitoring
feedbackService
ConfigurationVNF Forwarding
Graph
YAML
YAMLYAML
YAML
YAML
Monitoring ConfigurationVNF
LCM
NFVI - Compute Node
VNF On-Boarding,
Orchestration
&
Life Cycle Management
Network Service Orchestration
&
VNF Forwarding Graph
Trend Micro VNF
6WindVNF
Brocade VNF
VNF/NS/VNFFG
TOSCA Templates
Horizon GUI
(or) CLI1
2
3 4
5
6
7
Cross Community Collaboration: OPNFVOPNFV
- Provides blueprints on how to deploy and configure different open source communities together.
- Requirements, use-cases and validation.
- OpenStack for NFV.
OPNFV Project OpenStack Project(s)
NetReady – Investigate and evolve OpenStack Networking to
support NFV usecases.
Neutron – Gluon
Connect network service providers with VMs
Doctor – Create a fault management framework for HA. Ceilometer, Aodh – Notification/Alarm
Vitrage, Congress – Monitoring and Analysis
Multisite – Connected NFV deployments across multiple
geographical locations
OpenStack Core Services,
Kingbird, Tricircle – Centralized Service for multi-region
OpenStack deployments and Networking automation across
neutron servers.
SFC – Provides ordered list of network services stitched
together to create a Network Service Chain.
OpenStack Core Services,
Tacker - VNFM and NFVO, Neutron – Networking-SFC
OVN – Open Virtual Networking for Containerized VNFs and
Edge NFV devices.
Neutron – Networking-OVN
Tacker – Pike Release
Tacker Documentation
https://docs.openstack.org/tacker/latest/
Source Code
http://git.openstack.org/cgit/openstack/tacker
Weekly meeting
#openstack-meeting, Weekly Wednesday 04:30 UTC: 60 mins
IRC
#tacker
Top Related