Cloud Foundry for Ops Teams
•Download as PPTX, PDF•
3 likes•2,095 views
Presented by: Cornelia Davis - Platform Engineer, Cloud Foundry, Pivotal If you believe everything you’ve read about Platform as a Service (PaaS) you probably think it’s all about the developer. If we told you that a Pivotal CF could auto scale your applications based on current load and provide consolidated logs and monitoring across all app instances, would your operators be happy? If they learned that four levels of high availability would cut down on the middle of the night pages, would they rejoice? We’ll show the wealth of operational benefits realized with use of Pivotal CF, powered by Cloud Foundry. Learn how Pivotal CF can free your IT Operations staff from fire fighting duties, allowing them to innovate instead.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Cloud Foundry for Ops Teams
Similar to Cloud Foundry for Ops Teams (20)
More from VMware Tanzu
More from VMware Tanzu (20)
Recently uploaded
Recently uploaded (20)
Cloud Foundry for Ops Teams
- 1. Not just for Developers: Cloud Foundry for Ops! VMWorld 2014 Cornelia Davis @cdavisafc cdavis@pivotal.io Director, Platform Engineering, Cloud Foundry Pivotal © Copyright 2013 Pivotal. All rights reserved. 1
- 2. Demo © Copyright 2013 Pivotal. All rights reserved. 2
- 3. Pivotal CF: Developer and Operator Productivity Built-in and Ecosystem Services • Applications • Rabbit MQ • MySQL HA • Cassandra • Elasticsearch • Jenkins (CI) • Memcached • MongoDB • Neo4j • Redis • Riak CS • Data/Analytics • Elastic Hadoop • HAWQ • GemFire XD • Mobile • Push Notification • Data Synch • API Gateway Easy to add and customize Simple, Developer Friendly Commands & API • Auto-detect frameworks • “Push and it works” • Simple service binding • Agile Microservices Easy to add and customize Operational Benefits for Every Application • Instant dynamic routing • Log stream aggregation • Access controls & policies • Built-in Containerization • APM & Operational metrics • 4 Layers of High Availability • App-Instance • Availability Zone • Process • Virtual Machine Deploy, Operate, Update & Scale with minimal downtime on IaaS ….and more • .WAR • Dockerfile • .NET © Copyright 2013 Pivotal. All rights reserved. 3
- 4. PIVOTAL CF Four Layers of HA © Copyright 2013 Pivotal. All rights reserved. 4
- 5. 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. 5
- 6. 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. 6
- 7. 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. 8
- 8. 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. 9
- 9. 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. 10
- 10. 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. 11
- 11. 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. 12
- 12. 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. 13
- 13. 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. 14
- 14. Thank You Pivotal Confidential––Internal Use Only 15
- 15. BUILT FOR THE SPEED OF BUSINESS
Editor's Notes
- Edgar
- Building the Pivotal CF story via animation Developer experience - where we started from and keep improving Operation benefits - When we started selling to enterprise customer beyond a cloud service, both at the Cloud Ops and Application Ops level 3 groups of build-in services (Pivotal and ecosystem) – Apps, Data/Analytics & Mobile. All Services are both deployed in a consistent / cloud in depended way by Cloud Ops and exposed to App Developer for easy binding to applications via the ERS marketplace All 3 pillars (Dev, Ops, Services) enjoy a common operational, continuous delivery and scale on any IaaS without app/service code of config changes
- Edgar
- 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.