Cloud Foundry Introduction (w Demo) at Silicon Valley Code Camp
•Als PPTX, PDF herunterladen•
7 gefällt mir•2,051 views
Silicon Valley Code Camp, The Self-healing Elastic Runtime that is Cloud Foundry. While we did mostly demo in this session, these slides set a bit of context first. Also includes the four levels of HA in Cloud Foundry.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Cloud Foundry Introduction (w Demo) at Silicon Valley Code Camp
Ähnlich wie Cloud Foundry Introduction (w Demo) at Silicon Valley Code Camp (20)
Mehr von cornelia davis
Mehr von cornelia davis (11)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Cloud Foundry Introduction (w Demo) at Silicon Valley Code Camp
- 1. Cloud Foundry The Self-healing, Elastic Runtime Cornelia Davis Director, Platform Engineering, Cloud Foundry, Pivotal cdavis@pivotal.io | @cdavisafc | October 2014 © Copyright 2013 Pivotal. All rights reserved. 1
- 2. The Power of PaaS (On Premise & Off Premise) Traditional IT Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking You Manage IaaS Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking You Manage IaaS Business Value, Agility & PaaS Applications Data Runtime Middleware O/S Virtualization Servers Storage Networking Cost Savings Pivotal CF + Choice of Virtualized Infrastructure You Manage © Copyright 2013 Pivotal. All rights reserved. 2
- 3. “Software is Eating the World” © Copyright 2013 Pivotal. All rights reserved. 3
- 4. Software is Eating the World $5B valuation Financial Services $10B valuation Travel & Hospitality $18B valuation Transportation $3.2B Acquisition by Google Home Automation $20B valuation Entertainment $26B valuation Automotive © Copyright 2013 Pivotal. All rights reserved. 4
- 5. You are either building a software business… Or losing to someone who is. © Copyright 2013 Pivotal. All rights reserved. 5
- 6. Amazon, a book store in Seattle, deploys code every 11 seconds © Copyright 2013 Pivotal. All rights reserved. 6
- 7. Continuously Delivered Microservices Faster & Safer © Copyright 2013 Pivotal. All rights reserved. 7
- 8. Rapid Innovation Requires a Combined Approach DEVELOPERS OPERATORS Dramatically improve developer experience Agile teams, rapid iteration Microservices, incubate open source advancements (data and apps) Continuous delivery, no planned downtime Instant scaling of apps and data services Automation and deployment consistency at every step © Copyright 2013 Pivotal. All rights reserved. 8
- 9. Agile Methodologies Meets Agile Platforms DEVELOPMENT AWS Dev Space 1 DEVELOPMENT AWS/vSphere Dev Space 2 Agile Development QA/Scale AWS QA Space QA PRODUCTION AWS/vSphere Prod 1 Prod 2 Production No code or configuration changes! © Copyright 2013 Pivotal. All rights reserved. 9
- 10. The Reality in Enterprises…Months and Weeks … and do it all over again from Dev Test Prod on any infrastructure © Copyright 2013 Pivotal. All rights reserved. 10
- 11. The Pivotal CF Way…Hours and Minutes USERS OPERATORS target <my cloud> push <my app> bind <my services> scale <my app> +1000 App Deployment: 30-90 seconds provision cloud <Public/Private> provision service <PaaS,Hadoop...> upgrade/update <my cloud> scale <my cloud> Cloud Deployment: 2-4 hours © Copyright 2013 Pivotal. All rights reserved. 11
- 12. OPEN SOURCE IS THE NEW OPEN STANDARD © Copyright 2013 Pivotal. All rights reserved. 12
- 13. Industry Transformation In the beginning… Open vs Proprietary Open Source is the new Open Standard Open Source as a strategic asset Purpose Motive as competitive differentiator © Copyright 2013 Pivotal. All rights reserved. 13
- 14. Cloud Foundry: The Largest Open PaaS Ecosystem Platinum Gold Silver © Copyright 2013 Pivotal. All rights reserved. 14
- 15. © Copyright 2013 Pivotal. All rights reserved. 15
- 16. …And One More Thing: Cloud Independent Application Containerization & Cluster Scheduling Automatic AppServer & OS Configuration with Buildpacks (“just push your app”) Application to Services Binding and Access Native & Extended Data, Mobile and Platform Services Application Network Security Groups Policy, Identity and Roles Management App Health Mng, Load Balancing, Rapid Scaling, Availability Zones IaaS Provisioning, Scaling & Configuration Logging as a service, Application metrics & performance, Metric based scaling Deploy, Operate, Update & Scale with minimal downtime on choice of IaaS ….and more © Copyright 2013 Pivotal. All rights reserved. 16
- 17. A Multi-Cloud 3rd Platform: Cloud Foundry Elastic Runtime Agile Microservices Elastic Hadoop Jenkins Service (CI) Google Redis KV Store Cloud Foundry BOSH VMware Openstack EC2 Elastic managed runtime service integrated into leading data services; all scaled and managed by CF BOSH Multi-Cloud Declarative Service Deployment, Operations Rabbit MQ © Copyright 2014 Pivotal. All rights reserved. 17
- 18. Demo! © Copyright 2014 Pivotal. All rights reserved. 18
- 19. Application Instances and Availability Zones Router App Ops Zone 1 Zone 2 Application instances DEA DEA DEA are evenly distributed over two availability zones. Loosing an AZ keeps instances running and available. Pivotal CF Elastic Runtime DEA DEA DEA © Copyright 2013 Pivotal. All rights reserved. 19
- 20. Failed Application Instances Replaced Router Blobstore Cloud Controller Desired State Actual State Health Manager Messaging (NATS) DEA DEA DEA App Ops Pivotal CF Elastic Runtime © Copyright 2013 Pivotal. All rights reserved. 20
- 21. ERS Processes are Monitored PaaS Ops Health Manager AGENT DEA AGENT Cloud Controller AGENT Message Bus Pivotal CF Operations Manager IaaS Health Monitor Responses: pager email monitoring … © Copyright 2013 Pivotal. All rights reserved. 22
- 22. ERS Processes are Monitored PaaS Ops Health Manager AGENT DEA AGENT Cloud Controller AGENT Message Bus Pivotal CF Operations Manager IaaS Health Monitor Responses: pager email monitoring … © Copyright 2013 Pivotal. All rights reserved. 23
- 23. ERS Processes are Monitored PaaS Ops Health Manager AGENT DEA AGENT Cloud Controller AGENT Message Bus Pivotal CF Operations Manager IaaS Health Monitor Responses: pager email monitoring … © Copyright 2013 Pivotal. All rights reserved. 24
- 24. VMs are Monitored PaaS Ops Health Manager AGENT DEA AGENT Cloud Controller AGENT BOSH Director Message Bus Pivotal CF Operations Manager IaaS Desired State Actual State Health Monitor Responses: pager email monitoring ressurector … © Copyright 2013 Pivotal. All rights reserved. 25
- 25. VMs are Monitored PaaS Ops Health Manager AGENT DEA AGENT Cloud Controller AGENT BOSH Director Message Bus Pivotal CF Operations Manager IaaS Desired State Actual State Health Monitor Responses: pager email monitoring ressurector … © Copyright 2013 Pivotal. All rights reserved. 26
- 26. VMs are Monitored PaaS Ops Health Manager AGENT DEA AGENT Cloud Controller AGENT BOSH Director Message Bus CPI Pivotal CF Operations Manager IaaS Desired State Actual State Health Monitor Responses: pager email monitoring ressurector … © Copyright 2013 Pivotal. All rights reserved. 27
- 27. Four levels of HA in PCF Elastic Runtime (ERS): Distribution across availability zones Application health management and recovery Operations Manager (cluster management): Process monitoring, recovery and alerting Virtual machine health monitoring, recovery and alerting http://blog.gopivotal.com/cloud-foundry-pivotal/products/the-four-levels-of-ha-in-pivotal-cf © Copyright 2013 Pivotal. All rights reserved. 28
- 28. Slides can be found at: http://www.slideshare.net/cdavisafc © Copyright 2013 Pivotal. All rights reserved. 29
- 29. BUILT FOR THE SPEED OF BUSINESS
Hinweis der Redaktion
- The rate and pace of change in our industry only continues to rise. We’re undergoing a transition to a whole new set of platforms and a whole new set of concerns. Cloud platforms, big data, real-time analytics, mobile delivery, systems of engagement and more are all bringing in waves of change and innovation. The old model of committee-based collaboration to create a standard specification that can then be implemented by multiple vendors is just too slow for this world. Not only is it too slow, but it also does not produce solutions that are as good as those created by refining open source projects in the fire of real user feedback. So the industry has mostly replaced a standards-first approach with an open-source first approach. In many cases, with an open-source *only* approach, but there are also examples of open standards being created behind the bow-wave of open source, ratifying what have become defacto standards. [This recently happened with the Spring Batch project for example, where the lag between the first open source version being used in production, and the JEE standard being complete was about 5 years! That’s an eternity in today’s world of IT].
- In the beginning people used to say that open source couldn’t innovate. That it was only good for commoditizing existing capabilities. That it was a race to the bottom which would destroy industry value. Bullshit. We never believed that. Still don’t. Open source is the best way to innovate because of the short feedback cycles it can create that we talked about previously. In the last few weeks, we’ve seen a subset of the vendors in the Hadoop space, which is itself just a part of the over 140 projects at the Apache Software Foundation, achieve a combined market valuation of $3Bn (Cloudera = $2Bn, HW = $1Bn). That’s a whole lot of industry value being created through open source. What happened? First open source became a means of overcoming proprietary lock-in,. Then it replaced standards at the leading edge of industry adoption, fueled by a rate of innovation that standards could never keep up with. Then it became a strategic asset and an integral part of corporate strategy.
- Largest Open source PaaS Ecosystem. Billions committed to the technology Global SPs are “all in”: AT&T, Verizon, NTT, Swisscom, CenturyLink, Telus, etc.
- WHY Remember the good old days when you had a separate chunk of plastic to take live video, make phone calls, listen to music, snap a picture with friends, get instant messages from co-workers, check the time and use that new fangled world wide web? Can you imagine swapping your smart phone for 8 pieces of gear that barely fit into a duffle bag? We are on the cusp of a similar transition in the datacenter. You shouldn’t need to work with different vendors when running applications. You shouldn’t need a separate vendor for your operating system, middleware, load balancer, system provisioning and policy management. Why would you use these devices in a world where a single platform displaces a myriad of unnecessary and expensive products.
- WHAT Pivotal CF is next generation middleware that delivers 9 things that are typically delivered via point software products. We provision operating systems and middleware. We deliver workload density without compromising application performance. We ensure that applications have appropriate network security safe guards to prevent security threats. We support application connections to external sources including databases and legacy middleware. We provide 4 levels of HA, with built in load balancing for scale in/out We support multi-tenant environments so that each line of business can operate with a discrete quota and isolated system access. We provision next generation data services including NOSQL databases, traditional databases and hadoop clusters. We provide horizontal and vertical scaling for the underlying IaaS so that you can scale your infrastructure in lock step with your Business. We provide a built-in log aggregation service, built-in APM metrics and utilization based auto-scaling so that you can monitor the health of your applications and scale out without human or 3rd party tool intervention. I am going to cover each of these 9 capabilities in more detail, but it’s important to note the impact of this collection of capabilities. The following slides will include information on CAPEX and OPEX reduction. We will also discuss how you can deliver faster time to value while holding the line on infrastructure cost.
- Zone could = rack, for example
- The elastic runtime will keep the number of instances you’ve requested running by: DEAs constantly reporting their state Health manager constantly updating actual state model across all DEAs HM periodically requests desired state from the cloud controller When a difference is found, HM advises CC CC initiates deployment of a new instance
- A static version of the previous slide.
- The processes running on the virtual machines (i.e. the health manager) are started with monit, a nice little utility that keeps an eye on processes and will respond when one dies. If a process dies then, monit will do two things: first, it will try to restart the process and second, whether the restart is successful or not, it will tell the BOSH agent about the failure. Recall that the Bosh agent is there to communicate with Operations Manager and in this case it will relay this failure information to the Operations Manager Health Monitor (not to be confused with the Health Manager of the elastic runtime that was discussed above) – we’ll abbreviate it OMHM. The OMHM will take this alert and pass it through a list of responders that can be configured to do things like send emails, page administrators and display alerts in operations dashboards. There’s a good chance that monit will already have recovered the process, but we also want there to be an opportunity for a human to respond.
- The processes running on the virtual machines (i.e. the health manager) are started with monit, a nice little utility that keeps an eye on processes and will respond when one dies. If a process dies then, monit will do two things: first, it will try to restart the process and second, whether the restart is successful or not, it will tell the BOSH agent about the failure. Recall that the Bosh agent is there to communicate with Operations Manager and in this case it will relay this failure information to the Operations Manager Health Monitor (not to be confused with the Health Manager of the elastic runtime that was discussed above) – we’ll abbreviate it OMHM. The OMHM will take this alert and pass it through a list of responders that can be configured to do things like send emails, page administrators and display alerts in operations dashboards. There’s a good chance that monit will already have recovered the process, but we also want there to be an opportunity for a human to respond.
- The processes running on the virtual machines (i.e. the health manager) are started with monit, a nice little utility that keeps an eye on processes and will respond when one dies. If a process dies then, monit will do two things: first, it will try to restart the process and second, whether the restart is successful or not, it will tell the BOSH agent about the failure. Recall that the Bosh agent is there to communicate with Operations Manager and in this case it will relay this failure information to the Operations Manager Health Monitor (not to be confused with the Health Manager of the elastic runtime that was discussed above) – we’ll abbreviate it OMHM. The OMHM will take this alert and pass it through a list of responders that can be configured to do things like send emails, page administrators and display alerts in operations dashboards. There’s a good chance that monit will already have recovered the process, but we also want there to be an opportunity for a human to respond.
- Of course, the BOSH agent on a VM can only communicate back to the Operations Manager if the VM is there, so let’s talk about what happens when a VM disappears. First thing to understand is that by “disappear” I mean that the BOSH agent is not functional; the VM could be there, but Ops Manager no longer knows what it is up to so for all intents and purposes it’s “gone”. How does Ops Manager know? One of the things that a BOSH agent is responsible for is sending out heartbeat messages and by default it does so every 60 seconds. The OMHM is constantly listening for those heartbeats and when it finds that one is missing it will itself produce and alert and pass that through the list of responders. Just as described above, this could result in emails, pages and operations dashboard alerts, but in this case there is one more responder that kicks in – the “resurector”. The resurector will communicate with the IaaS over which PCF is running and will ask that the failed VM be replaced. Of course it will be replaced with a VM running the appropriate part of the elastic runtime – i.e. a health manager or DEA, etc. That’s right, Operations Manager will restart failed cluster components.
- Of course, the BOSH agent on a VM can only communicate back to the Operations Manager if the VM is there, so let’s talk about what happens when a VM disappears. First thing to understand is that by “disappear” I mean that the BOSH agent is not functional; the VM could be there, but Ops Manager no longer knows what it is up to so for all intents and purposes it’s “gone”. How does Ops Manager know? One of the things that a BOSH agent is responsible for is sending out heartbeat messages and by default it does so every 60 seconds. The OMHM is constantly listening for those heartbeats and when it finds that one is missing it will itself produce and alert and pass that through the list of responders. Just as described above, this could result in emails, pages and operations dashboard alerts, but in this case there is one more responder that kicks in – the “resurector”. The resurector will communicate with the IaaS over which PCF is running and will ask that the failed VM be replaced. Of course it will be replaced with a VM running the appropriate part of the elastic runtime – i.e. a health manager or DEA, etc. That’s right, Operations Manager will restart failed cluster components.
- Of course, the BOSH agent on a VM can only communicate back to the Operations Manager if the VM is there, so let’s talk about what happens when a VM disappears. First thing to understand is that by “disappear” I mean that the BOSH agent is not functional; the VM could be there, but Ops Manager no longer knows what it is up to so for all intents and purposes it’s “gone”. How does Ops Manager know? One of the things that a BOSH agent is responsible for is sending out heartbeat messages and by default it does so every 60 seconds. The OMHM is constantly listening for those heartbeats and when it finds that one is missing it will itself produce and alert and pass that through the list of responders. Just as described above, this could result in emails, pages and operations dashboard alerts, but in this case there is one more responder that kicks in – the “resurector”. The resurector will communicate with the IaaS over which PCF is running and will ask that the failed VM be replaced. Of course it will be replaced with a VM running the appropriate part of the elastic runtime – i.e. a health manager or DEA, etc. That’s right, Operations Manager will restart failed cluster components.