Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OpenStack Collaboration made in heaven with Heat, Mistral, Neutron and more..


Published on

Cross-project collaboration is something OpenStack community has embraced for a long time. Common libraries like Oslo reduces the time and effort to build a new service. Another way this manifests is in new OpenStack services getting built using existing services to solve an higher level use-case.

In this talk we are present how the band of projects comprising of Mistral, Tacker, Neutron, Heat, TOSCA-parser and Barbican came together to build an industry leading ETSI NFV Orchestrator that leveraged the best of these projects. Each of these projects brought in critical functionalities needed towards the final product. You will learn how, when strung together, this solution follows the classic Microservices design pattern that the industry is rapidly adopting.

Published in: Software
  • Be the first to comment

OpenStack Collaboration made in heaven with Heat, Mistral, Neutron and more..

  1. 1. OpenStack Collaboration Made in Heaven 06.11.2017 Trinath Somanchi Bharath ThiruveedulaSridhar Ramaswamy, Ex-PTL, Tacker CISCO NXP VERIZON INDIA Dharmendra Kushwaha NEC with Tacker, Heat, Mistral and more…
  2. 2. Overview Cross 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
  3. 3. 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
  4. 4. Need for Collaboration
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Compute Services Storage ServicesNetwork Services Neutron Kuryr Dragon Flow Tacker Nova Glance Magnum Zun Cinder Swift Manila Freezer Identity and Workflow Keystone Barbican Mistral Monitoring & Management Aodh Ceilometer Horizon Monasca Need for Collaboration
  9. 9. Success Story - Tacker
  10. 10. 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
  11. 11. 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 ?
  12. 12. 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
  13. 13. 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.
  14. 14. 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 Heat Neutron (networking-sfc) SDN Controller OVSDB OVSDB VNF vRouter VNF 1 VNF 2 Compute Node A OVSDB VNF DPI VNF 1 VNF 2 Compute Node A VNFD VNFD VNFD VNFFGD VNFD NSD 1 2 3 4
  15. 15. 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.
  16. 16. 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
  17. 17. 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.
  18. 18. Tacker Architecture Heat OpenStack Nova & Neutron Infra Driver Tacker NFVO / VNFM / SFC API DB Monitoring Driver Management Driver SFC Driver SDN Controller OVS Mgmt NetTenant Net Trend Micro VNF VNFVPN VNF 6Wind Turbo Router MngrMngr Monitoring feedback Service Configuration VNF Forwarding Graph YAML YAML YAML YAML YAML Monitoring Configuration VNF 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) CLI 1 2 3 4 5 6 7
  19. 19. Demo
  20. 20. Cross Community Collaboration: OPNFV OPNFV - 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
  21. 21. Summary Tacker Oslo Nova Heat KeystoneGlance Mistral Barbican Net-SFC
  22. 22. Tacker – Pike Release Tacker Documentation Source Code Weekly meeting #openstack-meeting, Weekly Wednesday 04:30 UTC: 60 mins IRC #tacker
  23. 23. What’s next ? Join us @ Tacker – 102 – Hands-on lab today.
  24. 24. @OpenStac k That’s all folks. Questions? openstack openstack OpenStackFoundation