Deployment Automation on OpenStack with TOSCA and Cloudify

14,589 views

Published on

TOSCA (Topology and Orchestration Specification for Cloud Applications) is an emerging standard for modeling complete application stacks and automating their deployment and management. It’s been discussed in the context of OpenStack for quite some time, mostly around Heat. In this session we’ll discuss what TOSCA is all about, why it makes sense in the context of OpenStack, and how we can take it farther up the stack to handle complete applications, both during and after deployment, on top of OpenStack.

Published in: Technology
0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
14,589
On SlideShare
0
From Embeds
0
Number of Embeds
856
Actions
Shares
0
Downloads
522
Comments
0
Likes
16
Embeds 0
No embeds

No notes for slide
  • Goals:Why Workflows are critical part of automation of applications on the cloudClarify the need for something like OpsWorksWhy do we think this OpsWorks is needed in addition to other projects
  • A recent Gartner study projected that through 2015, “80 percent of outages impacting mission-critical services will be caused by people and process issues, and more than 50 percent of those outages will be caused by change, configuration, release integration, and handoff issues.[2].”(Ronni J. Colville and George Spafford, “Configuration Management for Virtual and Cloud Infrastructures”)
  • According to the AppsDynamics blog “How much does downtime cost,” the downtime expenses increased by an average of 65 percent from 2010-2012, even though the number of downtime hours per organization decreased (Figure 1) [1]. One possible explanation for this trend is that larger portions of business are being done online, making the overall impact of downtime bigger on an organization’s bottom line. With the move to cloud and Software-as-a-Servcice-based (SaaS-based) delivery models where not only customer-facing applications are exposed to online service but entire IT infrastructures, the impact of downtime could easily shut down an entire organization.
  • http://www.cloudcomputing-news.net/blog-hub/2013/sep/10/the-challenge-of-predicting-enterprise-cloud-computing-growth/83% of enterprises face significant roadblocks that hold them back from moving beyond cost reduction to faster time-to-market and better orchestration of their businesses. Respondents mentioned that politics, budget, time and staff are the main sources of roadblocks to getting more value out of their cloud computing investments. The majority of these roadblocks are not related to IT.  They include lack of clarity regarding organization and budget (37%), resistance to change (16%) and lack of trust (visibility and reliability) (15%).  The following graphic illustrates the enterprise cloud journey as defined in TheInfoPro Wave 5 Cloud Computing Study.
  • Deployment Automation on OpenStack with TOSCA and Cloudify

    1. 1. Deployment Automation on OpenStack with TOSCA and Cloudify Nati Shalom @natishalom Uri Cohen @uri1803
    2. 2. Provision What It Really Takes to Deploy and Manage Apps Scale Install Monitor Configure Deploy
    3. 3. Large Parts Are Mostly Manual Measure performance against expected SLA’s Set and tune Alerts thresholds Match Policy to Incident Real Time Analytics Send Metrics Correlate with Historical Events Collect and Analyze Logs Troubleshoot Execute Policy Feedback Setup Monitoring and Alerts Deploy and Configure Applications Setup Machine, Network, Sto rage Push updates
    4. 4. The Impact of Human Errors 80% of outages impacting mission-critical services will be caused by people and process issues 50% of those outages will be caused by change/configuration/release integration and hand-off issues
    5. 5. The Cost of Downtime Up by 60%
    6. 6. EFFECTIVENESS The Current Reality.. 83%BE HERE WANT TO 61% ARE HERE TIME
    7. 7. The Solution Challenges Solution: Automation & Orchestration • 80% • Remove Manual Intervention out of of outages impacting mission-critical services will be caused by people and process •83% are facing significant roadblock keeping them from moving to the next phase (Politics, Budget, Time, Stuff) the application deployment process • Reduce Complexity and Dynamically align to the business needs
    8. 8. Automating The Application Deployment Real Time Analytics Real Time Analytics Cloud Infrastructure Send Metrics Correlate with Historical Events Execute Policy Scale Feedback Failover Deploy Historical data Intelligent Orchestration
    9. 9. TOSCA – The Glue for Putting all This Together TOSCA
    10. 10. What is TOSCA? • Topology & Orchestration Specification of Cloud Application • By OASIS – Sponsored by IBM, CA, Rackspace, RedHat, Huawei and others
    11. 11. What is TOSCA? • Goal: cross cloud, cross tools orchestration of applications on the Cloud • Status: – Version 1 approved (XML ) – Version 2 (YAML!) in design
    12. 12. • Standard • Can Describe Why TOSCA? – Any Topology – Any Automation Process • Portable between Clouds and Tools
    13. 13. The TOSCA Building Blocks Application Topologies Workflows Policies
    14. 14. What do we see here?
    15. 15. Host App module What do we see here? Middleware connection
    16. 16. • An application topology • 3 layers What We’ve Seen – Infrastructure (Cloud or DC objects) – Platform or Middleware (App containers) – Application modules, schemas and configurations • Relationships between components: – What’s hosted on what or installed on what – What’s connected to what
    17. 17. What’s in a TOSCA Topology? • component in the topology are called Nodes • Each Node has a Type (e.g. Host, BD, Web server). – The Type is abstract and hence portable – The Type defines Properties and Interfaces • An Interface is a set of hooks (named Operations) • Nodes are connected to one another using Relationships
    18. 18. Topology Infrastructure Middleware Application Host Network Router Apache Tomcat MySQL Mod_proxy WAR Schema
    19. 19. Types and Nodes Portable Blueprint Concrete Types Node in Topology Node Implementation Instance of Instance of Implements Abstract Type Concrete Type Uses defines Lifecycle Interface Lifecycle: create: start: stop: delete: Implements Concrete Plugin
    20. 20. Types and Nodes Portable Blueprint Concrete Types Frontend_host My_OpenStack_Host Instance of Instance of Implementing OpenStack Host Host Uses defines Lifecycle Interface Lifecycle: create: start: stop: delete: Implementing Nova Plugin Lifecycle: create: nova_provisioner.create start: nova_provisioner.start stop: nova_provisioner.stop delete: nova_provisioner.delete
    21. 21. Relationships Node in Topology Connnected_to Node in Topology defines Hosted_on Relationship Interface Node in Topology source_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink target_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink
    22. 22. Relationships Host Connnected_to Network defines Hosted_on Relationship Interface Tomcat source_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink target_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink
    23. 23. Node Translated to TOSCA Node Hosted_on relationship Node Connected_to relationship
    24. 24. Properties Portable Blueprint Concrete Types Frontend_host My_OpenStack_Host Instance of Instance of Implementing OpenStack Host Host Memory size = 2GB Image_Id=1235 Memory Size Properties schema Property values Image Id Generic Properties Schema
    25. 25. Policies • TOSCA 1.0 didn’t elaborate much on policies • TOSCA 2.0 (draft) discusses specific DSL for specific policies such as SLA of a Node • Out take: – Policies are imperative – Policies are NOT in YAML and are tool dependent (we’re using Riemann.io)
    26. 26. • TOSCA 1.0 – Workflows (Plans) are in any WF language. – Strong preference for BPMN 2.0 Workflows • TOSCA 2.0 – No change • Cloudify 3.0 take – Workflows are also tool specific, currently we use Radial (Ruby based DSL) but seeking an alternative for future versions
    27. 27. • TOSCA Template (Blueprint in Cloudify) contains: Putting It All Together – Application Topology • Nodes – Interfaces – Properties – Artifacts (Plugins in Cloudify) • Relationships – Interfaces – Workflows – Policies
    28. 28. Portable Blueprint
    29. 29. Openstack_host type
    30. 30. Type implementation
    31. 31. Invokes Reports Creates Architecture Cloudify Manager REST + File Server Proxy GUI Metrics VM Blueprint + Runtime Data Workflow Engine Policy Engine Task Manager Monitoring Data Agent Logs + Events App VM Remote Agents Application Stack Agent Agent Agent Agent Monitoring Agent
    32. 32. HOW IT FITS INTO THE OPENSTACK UNIVERSE
    33. 33. The AWS Stack
    34. 34. The OpenStack Equivalents OpenShift/ CloudFoundry **Solum** ? Heat Nova, Cinder, Neutron etc..
    35. 35. References • OASIS TOSCA https://www.oasis-open.org/committees/tosca/ • TOSCA Session from the HK Summit https://wiki.openstack.org/w/images/a/a1/TOSCA_in_Heat_-_20130415.pdf • Cloudify 3.0 (AKA Cosmo) on github https://github.com/cloudifysource/cosmo-manager https://github.com/cloudifysource/cosmo-cli

    ×