O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Why NFV Needs TOSCA

1.234 visualizações

Publicada em

TOSCA specifications are rapidly advancing in 2017 to become the premier framework for deploying and orchestrating NFV workloads (VNFs and Network Services). At the same time, adoption requires more than standard specifications - and open source projects such as ARIA are stepping up to this challenge. Gaps in the specifications, many identified by implementations in open source projects, are being actively analyzed and addressed by an energized cross-section community of individuals/companies engaged in both standards activities and open-source projects. This cross-pollination gives industry confidence that TOSCA-as-a-living-standard has a real chance to accelerate the realization of many of the promises of NFV.

Publicada em: Tecnologia

Why NFV Needs TOSCA

  1. 1. May 3, 2017 Why NFV Needs TOSCA Michael Brenner, Chief Architect NFV, GigaSpaces michael@gigaspaces.com
  2. 2. NFV paradigm (un)settling questions Are NFV-impacting standards settled? Have open source communities produced a complete NFV solution? Does any vendor have a market-dominant complete NFV solution? Does any Operator have a major NFV deployment in production ?
  3. 3. A “right”-sized standards approach With NFV still settling … we need: - direction-setting specifications - under-specification - flexible/extensible frameworks - iterative implementation - feedback to standards With NFV still settling … we should not: - mandate compliance to yet-to-be- proven/un-tested standards
  4. 4. TOSCA – right-sized for NFV, and growing with it Designed broadly for deployment and orchestration of Cloud Workloads (and beyond) Lightweight/under-specified as a philosophy Extensible … “on a clear day one can see forever” Ideal for iterative implementations Driven by a receptive and energetic standards community … and it does not mandate much 
  5. 5. What is TOSCA and what does it address? TOSCA is a data modeling framework that supports defining interoperable description of applications; including their components, relationships, dependencies, requirements, and capabilities…. …thereby enabling portability and automated management across cloud providers regardless of underlying platform or infrastructure thus expanding customer choice, improving reliability, and reducing cost and time-to-value. TOSCA addresses critical Cloud Challenges: - Speed and accuracy moving apps to Cloud - Agility adapting to change - Consumer choice of Cloud vendor and technology
  6. 6. TOSCA philosophy These concepts lead to application-centric, holistic, unified model • Reusable models extend investments by making it easy to compose more valuable and complex apps from existing apps • Models can be validated by automation to ensure app-aware, policy-aligned configuration, deployment and operational semantics TOSCA Application Model Web Server Tier Web Server Web App PHP Script Module Database Server Tier DB Server Database Containment Connectivity Containment and Connectivity concepts support Composition and Reuse.
  7. 7. So why is TOSCA good for NFV? 1. What’s good for Cloud Workloads is also good for NFV … because VNFs and Network Services composed with VNFs are in fact specialized cloud workloads/applications. 2. TOSCA specific extensions for NFV are taking shape in 2017, and will support ETSI NFV information model while avoiding being locked into it. 4. TOSCA is a living and growing framework, and it will find its way in Operators’ NFV++ (i.e. crossing the current NFV boundaries defined in ETSI NFV) 3. TOSCA is supported by living Open Source implementations in demand in Open Source projects, and between adoption and its conduciveness to iteration, will converge faster than any other standard into the right-sized specification. TOSCA is used first and foremost to describe the topology of the deployment view for cloud applications and services.
  8. 8. (NFV) Topology and Composition (1) Tier source_resource Node_Type_A target_resource Node_Type_B Requirement connect_relationship ConnectsTo Capability Node templates to describe components in the topology structure Relationship templates to describe connections, dependencies, deployment ordering Requirement - Capability Relationships can be customized to match specific source requirements to target capabilities TOSCA is used first and foremost to describe the topology of the deployment view for cloud applications and services.
  9. 9. (NFV) Topology and Composition (2) Orchestrators can “substitute” for abstract nodes… … as long as all declared “requirements” are met: • Monitoring Service can be substituted in Cloud Application • Analytics Service can be substituted in Monitoring Service Any node in a TOSCA topology can be an abstraction of another layer or sub-topology.
  10. 10. (NFV) Policy my_app_1 Compute Capabilities Container .. . Lifecycle create configure .. . Policy • Type • Event, Condition • Action my_scaling_group backend_ app Compute Policy • Type • Event, Condition • Action my database Compute web-app Compute Policy • Type • Event, Condition • Action 1 2 3 Scaling Policies can be declared independently and attached to various points in your models 1. That can be attached to Interfaces or specific Operations, 2. Nodes and 3. Groups of Nodes Policies are non- functional requirements independent of nodes, e.g. wrt placement/affinity, scaling and performance Orchestrators can evaluate Conditions based on Events that trigger Automatic or Imperative Actions
  11. 11. (NFV) Workflows A CB D E F ‒ Declarative workflows: automatically generated based on the INTENT derived from the description of nodes, relationships, and groups defined in the topology ‒ Imperative workflows: manually specified TASKS by the author of the topology TOSCA defines two different kinds of workflows that can be used to deploy a TOSCA topology. Defining sequence of operations in an imperative workflow • Using on_success to define steps ordering • Every step that doesn’t define any successor is considered as final. When all the final nodes executions are completed then the workflow is considered as completed.
  12. 12. Matching (NFV) infrastructure requirements Cloud Provider C Cloud Provider B Portable Choice Best Fit TOSCA App Cloud Provider A • TOSCA Apps can be designed to be portable to any cloud (including hybrid) that meets the application’s requirements Each cloud provider competes by offering their “best fit” of unique capabilities, features and services that match the application’s requirements – and avoid the “lowest common denominator” approach TOSCA supports automated matching of application requirements to provider capabilities and choice of provide that “best fits” your application.
  13. 13. Architects Model services, policies & requirements Development Teams Develop, unit test scripts, plans & artifacts for planned releases, patches, fixes QA Teams Build & Test releases, updates & configurations Operations Deploy, manage & monitor application lifecycle Cloud Provider A Cloud Provider C Cloud Provider B TOSCATemplate Cloud Application Lifecycle with TOSCA TOSCATemplate TOSCATemplate TOSCATemplate TOSCATemplate Infrastructure Changes Hot Packs Strategic Requests Operational Requests Business Conditions TOSCA Templates Agnostic to Cloud Infrastructure Changes Cloud Application (VNF/NS) lifecycle management TOSCA templates communicate and drive app-centric Dev-Ops/CICD
  14. 14. NFV specific extensions – work-in-progress: VDU TOSCA NFV/SDN ad-hoc group is working on a TOSCA profile for NFV. Extensions that help mapping to ETSI NFV VNF model are specified. The NFV Virtualization Deployment Unit (VDU) compute node type represents a VDU entity which describes the deployment and operational behavior of a VNF component (VNFC), as defined by ETSI NFV IFA011.
  15. 15. NFV specific extensions – work-in-progress: VNFD example TOSCA NFV/SDN ad-hoc group is working on a TOSCA profile for NFV. This spec will support the definition of an (ETSI NFV) VNF Descriptor This defines a VNFD example which contains three different types of VDUs, interconnected by two virtual link descriptors. The type of VDU C is not defined within the same VNFD service template file, but rather in a separate service template file.
  16. 16. TOSCA Open Source implementations for NFV TOSCA spec alone is insufficient to fulfill portability & inter- operability for NFV. Open Source implementations are rising to the challenge. Service Orchestration & Management http://getcloudify.org/ https://wiki.openstack.org/ Heat-Translator (IaaS, App Orchestration) Tacker (Network Function Orchestration) Senlin (Clustering & Policy (on roadmap)) App Catalogs (Community & Murano) Parser (standalone) http://ariatosca.org// Multi-Cloud Orchestration (Amazon, Azure, VMware, OpenStack) Open Sourced from Cloudify Deployment Template Translation Parser https://wiki.opnfv.org/display/parser/Parser UBICITY Cloud-based template validator http://ubicity.com/validator.html
  17. 17. ARIA: a TOSCA implementation like no other ARIA: a one-stop shop for all your TOSCA needs: - TOSCA Parser - Library for NFV TOSCA- based orchestration products - TOSCA SDK for specifying VNFs - CLI Tool for orchestrating TOSCA templates Uses ARIA for TOSCA orchestration TOSCA Spec Implementation TOSCA Spec Definition Uses ARIA for TOSCA orchestration Others Spec Definition Use Cases & Models Open Source Apache 2.0 License Open Governance Apache Software Foundation
  18. 18. TOSCA for NFV++ TOSCA for Cloud Native applications TOSCA for Micro-Services TOSCA for General Orchestrators TOSCA for Serverless Architectures TOSCA for zero-touch/zero-outage interactions (OSS/BSS) Unleash TOSCA: - It’s flexible - It’s dynamic - It’s adopted - It’s both lightweight and right-sized for automation
  19. 19. Thank You

×