Architecture & Operations
•Download as PPTX, PDF•
2 likes•1,627 views
The primary goals of this presentation are to: - Show how to easily deploy Pivotal Cloud Foundry to CenturyLink Cloud with CenturyLink’s Blueprint technology - Do a deep dive into the CF architecture via animated slides illustrating push, stage, deploy, scale and health management. - Discuss in depth how Pivotal Cloud Foundry simplifies many traditional operator concerns such as managing application updates, availability, user/quota management and monitoring. - Provide a brief introduction to BOSH, including why BOSH, what it is and animations of how it works. - Discuss the value adds to CF BOSH OSS that Pivotal brings through the Pivotal Ops Manager product and our associated ecosystem of data and mobile services.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Architecture & Operations
Similar to Architecture & Operations (20)
More from VMware Tanzu
More from VMware Tanzu (20)
Recently uploaded
Recently uploaded (20)
Architecture & Operations
- 1. © Copyright 2014 Pivotal. All rights reserved. Pivotal Cloud Platform Deep Dive Part 2: Architecture and The Operator Experience Sani Chabi Yo syo@pivotal.io 1 Keith Resar keith.resar@ctl.com @keithresar
- 2. © Copyright 2015 Pivotal. All rights reserved. Architecture and the Operator Experience • Pivotal Cloud Foundry Architecture • Structured Platform for Cloud Native Apps • One Click CenturyLink Ops Manager and CenturyLink Dashboard • The Operator Experience
- 3. © Copyright 2014 Pivotal. All rights reserved. Moore’s Law Of Applications The Good Old Days – 3 applications – Physical Servers + Scripts Present Day – 300+ applications – IAAS + CAPS The Future – 30,000 applications – ? PROBLEM SPACE
- 4. © Copyright 2014 Pivotal. All rights reserved. Plus… And many more….
- 5. © Copyright 2014 Pivotal. All rights reserved. Operation agility as the secret sauce
- 6. © Copyright 2014 Pivotal. All rights reserved. 6 A STRUCTURE PLATFORM • Self-service provisioning with RBA • Many Touch points to ONE Platform • Configuration changes • Updates/upgrades • Remediation • Scale out/Scale in • Immutable environment Amend (Re)deploy (Re)configure (Re)connect Monitor Current State Desired State
- 7. © Copyright 2014 Pivotal. All rights reserved. 7 2 Key Components to Pivotal Cloud Foundry Ops Manager/ Operations Manager: A web application that you use to deploy and manage a Pivotal Cloud Foundry PaaS Elastic Runtime: The set of core Cloud Foundry services that are installed, upgraded and scaled via Ops Manager
- 8. © Copyright 2014 Pivotal. All rights reserved. 8 Loggregator DEA Pool Router Cloud Controller BOSH Director BOSH Agent UAA/Login Servers Health Manager Service Broker Node(s) Messaging (NATS) IaaS Cloud Foundry Architecture Stack
- 9. © Copyright 2014 Pivotal. All rights reserved. 9 Pivotal CF deployment on CenturyLink Cloud
- 10. © Copyright 2014 Pivotal. All rights reserved. 10
- 11. © Copyright 2014 Pivotal. All rights reserved. 11
- 12. © Copyright 2014 Pivotal. All rights reserved. 12
- 13. © Copyright 2014 Pivotal. All rights reserved. 13
- 14. © Copyright 2014 Pivotal. All rights reserved. 14
- 15. © Copyright 2014 Pivotal. All rights reserved. 15
- 16. © Copyright 2014 Pivotal. All rights reserved. 16
- 17. © Copyright 2014 Pivotal. All rights reserved. 17
- 18. © Copyright 2014 Pivotal. All rights reserved. 18
- 19. © Copyright 2014 Pivotal. All rights reserved. 19
- 20. © Copyright 2014 Pivotal. All rights reserved. 20
- 21. © Copyright 2014 Pivotal. All rights reserved. 21
- 22. © Copyright 2014 Pivotal. All rights reserved. 22
- 23. © Copyright 2014 Pivotal. All rights reserved.
- 24. © Copyright 2014 Pivotal. All rights reserved.© Copyright 2014 Pivotal. All rights reserved. What’s on Pivotal Cloud Foundry for an operator? 24
- 25. © Copyright 2014 Pivotal. All rights reserved. 25 Pivotal Cloud Foundry operations Developer Operator
- 26. © Copyright 2014 Pivotal. All rights reserved. 26 Install runtime and container Deploy to dev
- 27. © Copyright 2014 Pivotal. All rights reserved. 27 Install runtime and container Install services (db, messaging, hadoop, …) Deploy to dev
- 28. © Copyright 2014 Pivotal. All rights reserved. 28 Install runtime and container Install services (db, messaging, hadoop, …) Setup load-balancing, SSL termination and dynamic routing Deploy to dev
- 29. © Copyright 2014 Pivotal. All rights reserved. 29 Install runtime and container Setup load-balancing, SSL termination and dynamic routing Setup / config High Availability Deploy to dev Install services (db, messaging, hadoop, …)
- 30. © Copyright 2014 Pivotal. All rights reserved. 30 Install runtime and container Setup load-balancing, SSL termination and dynamic routing Setup / config High Availability Setup APM Deploy to dev Install services (db, messaging, hadoop, …)
- 31. © Copyright 2014 Pivotal. All rights reserved. 31 Install runtime and container Setup load-balancing, SSL termination and dynamic routing Setup / config High Availability Setup APM Setup log streaming Deploy to dev Install services (db, messaging, hadoop, …)
- 32. © Copyright 2014 Pivotal. All rights reserved. 32 Install runtime and container Setup load-balancing, SSL termination and dynamic routing Setup / config High Availability Setup APM Setup log streaming Deploy to dev App Deployed Install services (db, messaging, hadoop, …)
- 33. © Copyright 2014 Pivotal. All rights reserved. 33 Install runtime and container Install services (db, messaging, hadoop, …) Setup load-balancing and dynamic routing Setup / config High Availability Setup APM Setup log streaming Deploy to dev
- 34. © Copyright 2014 Pivotal. All rights reserved. 34 Install runtime and container Install services (db, messaging, hadoop, …) Setup load-balancing and dynamic routing Setup / config High Availability Setup APM Setup log streaming Deploy to dev
- 35. © Copyright 2014 Pivotal. All rights reserved. Deploy to dev The Pivotal CF way
- 36. © Copyright 2014 Pivotal. All rights reserved. Deploy to dev >cf push Cloud Controller Health Manager NATS (message bus) Router App Deployed The Pivotal CF way
- 37. © Copyright 2014 Pivotal. All rights reserved. 37 Operator Concerns Monitor the platformHandle upgrades and updates Plan capacity Manage users Quotas and services Setup High Availability
- 38. © Copyright 2014 Pivotal. All rights reserved. 38 Orgs, Spaces, Users and Quotas
- 39. © Copyright 2014 Pivotal. All rights reserved. Self-service with RBAC SOLUTION SPACE PIVOTAL CLOUD FOUNDRY IMMUTABLE SELF-SERVICE PROVISIONING PLATFORM RBAC • Organization, User role, Space • New environment in seconds • SSO with your existing IP (AD, LDAP, SAML2) ADMIN CONTROLS • Set limits on Key resources • Set Quotas per Orgs. • Fine grained control to restrict inbound/outbound traffic. MARKETPLACE • Self-provisioning on services (Data Services, mobiles services, etc.) • PCF Managed and 3rd party provided services
- 40. © Copyright 2014 Pivotal. All rights reserved. What about my legacy services?
- 41. © Copyright 2014 Pivotal. All rights reserved. SOLUTION SPACE
- 42. © Copyright 2014 Pivotal. All rights reserved. Service Broker options Service Broker Service Broker Service Broker IBM DB2ORACLE DB Mongo Lab Send Grid AppDirect ClearDB INTERNET Synchronous ORACLE DB SOLUTION SPACE
- 43. © Copyright 2014 Pivotal. All rights reserved. 43
- 44. © Copyright 2014 Pivotal. All rights reserved. 44 Operator Concerns Monitor the platform Handle upgrades and updates Plan capacity Manage users Quotas and services Setup High Availability
- 45. © Copyright 2014 Pivotal. All rights reserved. 45 Provision services, not machines Enables continuous delivery Cloud-agnostic view of Platform Ops Holistic Toolchain for “rule them all" Eliminate bespoke automation on top of config management Why BOSH
- 46. © Copyright 2014 Pivotal. All rights reserved. 46 The BOSH Architecture Very similar to CF architecture itself Director as analogy to Cloud Controller Different CPIs exist per IaaS implementation Workers responsible for executing tasks as dictated by Director
- 47. © Copyright 2014 Pivotal. All rights reserved. How about and CF? 47
- 48. © Copyright 2014 Pivotal. All rights reserved. 48 IaaS BOSH Director BOSH Agent Mobile Services for Pivotal CF ElasticSearch for Pivotal CF CloudBees Jenkins Enterprise Cassandra for Pivotal CF
- 49. © Copyright 2014 Pivotal. All rights reserved. 49 IaaS BOSH Director BOSH Agent Mobile Services for Pivotal CF ElasticSearch for Pivotal CF CloudBees Jenkins Enterprise Cassandra for Pivotal CF Click to install No downtime updates Explore install logs Click to scale the platform Built-in High Availability Built-in Platform Monitoring Integrated services
- 50. © Copyright 2014 Pivotal. All rights reserved. 50 IaaS BOSH Director BOSH Agent Mobile Services for Pivotal CF ElasticSearch for Pivotal CF CloudBees Jenkins Enterprise Cassandra for Pivotal CF BOSH releases CF
- 51. © Copyright 2014 Pivotal. All rights reserved. PCF – Each Layer Upgradable with Zero Downtime runtime layer OS image application layer PCF Buildpack Apps linux host & kernel App container PCF Supported Dev Supported Ops Supported • Platform Provided • CVEs addressed by Pivotal • Canary-style, zero- downtime upgrades • Platform or Developer Provided • CVEs addressed by Pivotal (for Platform Provided) • Blue/Green deployments • Developer/App team provided • Blue/Green deployments
- 52. © Copyright 2014 Pivotal. All rights reserved. Demo: How long does it take you to deploy a patch in production?
- 53. © Copyright 2014 Pivotal. All rights reserved. 53 Operator Concerns Monitor the platform Handle upgrades and updates Plan capacity Manage users quotas and services Setup High Availability
- 54. © Copyright 2014 Pivotal. All rights reserved. 54 Platform Monitoring How do I know when to scale DEAs? How many requests each Router is servicing? What is the current load of my Cloud Controllers?
- 55. © Copyright 2014 Pivotal. All rights reserved. 55 Platform Monitoring Collector JMX Provider JMX Monitoring Tool
- 56. © Copyright 2014 Pivotal. All rights reserved. 56 Platform Monitoring Collector JMX Provider JMX Monitoring Tool
- 57. © Copyright 2014 Pivotal. All rights reserved. Monitoring in Pivotal Cloud Foundry APPLICATIONS • CLI: cf logs <appname> • Apps Manager • ELK tile • RBAC PLATFORM • SYSLOG Endpoint • Configuration via Ops Manager • Logs Search & Persistence such as ELK • Only accessible by Admins • Collector Component with plugins for JMX and Datadog • Ops Metrics tile • Firehose METRICS • Agentless APM • APM Integrations through buildpacks LOGS
- 58. © Copyright 2014 Pivotal. All rights reserved. 58 Operator Concerns Monitor the platform Handle upgrades and updates Plan capacity Manage users Quotas and services Setup High Availability
- 59. © Copyright 2014 Pivotal. All rights reserved. 59 4 Layers of built-in High Availability Application Instance Platform Processes Platform VMs Availability Zones
- 60. © Copyright 2014 Pivotal. All rights reserved. 60 4 Layers of built-in High Availability Application Instance Platform Processes Platform VMs Availability Zones
- 61. © Copyright 2014 Pivotal. All rights reserved. 61 App Instance HA Blobstore Router Cloud Controller DEA Messaging (NATS) DEA DEA Runtime Health Manager Actual State Cloud Foundry
- 62. © Copyright 2014 Pivotal. All rights reserved. 62 4 Layers of built-in High Availability Application Instance Platform Processes Platform VMs Availability Zones
- 63. © Copyright 2014 Pivotal. All rights reserved. 63 Platform Processes HA Blobstore BOSH Health Monitor DB Messaging Health Manager Target VM Cloud Controller BOSH Director NATS Agent Agent Agent Process Process Process Pivotal CF DEA Agent Process
- 64. © Copyright 2014 Pivotal. All rights reserved. 64 Platform Processes HA Target VMCloud Controller Agent ProcessRestart
- 65. © Copyright 2014 Pivotal. All rights reserved. 65 4 Layers of built-in High Availability Application Instance Platform Processes Platform VMs Availability Zones
- 66. © Copyright 2014 Pivotal. All rights reserved. 66 Platform VMs HA Blobstore BOSH Health Monitor DB Messaging Health Manager BOSH Director NATS Agent Agent Cloud Controller Agent Process Process Process Pivotal CF Cloud Controller Agent Process Ressurector Re-create VM VM is missing…
- 67. © Copyright 2014 Pivotal. All rights reserved. 67 4 Layers of built-in High Availability Application Instance Platform Processes Platform VMs Availability Zones
- 68. © Copyright 2014 Pivotal. All rights reserved. Availability Zone #2 68 Availability Zones DEA DEA DEA Router Blobstore Cloud Controller Health Manager Messaging (NATS) Push app Availability Zone #1 DEA DEA
- 69. © Copyright 2014 Pivotal. All rights reserved. 69 Operator Concerns Monitor the platform Handle upgrades and updates Plan capacity Manage users Quotas and services Setup High Availability
- 70. © Copyright 2014 Pivotal. All rights reserved.© Copyright 2014 Pivotal. All rights reserved. And on top of all that… … something else we’ve found in enterprises
- 71. © Copyright 2014 Pivotal. All rights reserved. Virtualized Infrastructure Infrastructure-centric Operations model Your Application Code Database Web Server Messaging IaaS+ (+automation) IT Ops Team App Team (Dev and Ops) SOLUTION SPACE
- 72. © Copyright 2014 Pivotal. All rights reserved. Application-centric Operation model Virtualized Infrastructure Your Application Code Database Web Server Messaging IaaS+ (+automation) IT Ops Team App Team Your Application Code PAAS Virtualized Infrastructure PaaS Ops Team App Team (Dev and Ops) Emits application “dial tone” • Configuration • Runtime • Logs • Metrics • Health Management • Security SOLUTION SPACE
- 73. © Copyright 2014 Pivotal. All rights reserved. 74
- 74. © Copyright 2014 Pivotal. All rights reserved. THANK YOU! See you after the break! 82
Editor's Notes
- 1. “Cowboy devs” - “It’s hard when ppl don't follow protocol” - “when devs do something that impacts us w/out telling us” 2. “ideally devs would be on pager duty”: “Devs turn to ops when things break - a lot of time bc ops guys fix everything all the time, they know what every service did, know common problems you might have” 3. Interruption-driven lives: “difficult to manage work. we're constantly blowing deadlines. unexpected things come up” We are entering into a fundamentally new era of business, where people have to build new experiences and new capabilities that are driven by software in order to compete in the market. Competing in this service oriented world means moving fast with consistency and reliability. How will your enterprise Manage all the Test, Dev and QA environments Patch and Update Production Manage failures and usage spikes How do you support changes not only at the application level but on the middleware, os, platform? Those are the questions PCF is mainly intended to solve. By balancing Speed and operational excellence.
- Take away: Left Silo: Silos & Right side: Dev + Operation work together. Livrer continuellement, non seulement le jour 1 mais egalement jour 2 et au dela.` 80% is resources is spend on day 2 and beyond.
- 2. 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 IT Operation. You shouldn’t need to work with different vendors to support your applications. You shouldn’t need a separate vendor for your middleware, load balancer, system provisioning and policy management. That’s the value proposition of PCF 3. No more Script/Templates 4. 5. Remediation: What happened if a application failed? What about a VM? PCF manages transformations between existing and desired system states, using immutable infrastructure. LOB care about Ops costing less, developer delivering faster. PCF is best positioned to respond to that requirement. The systems need to be able to change. Software needs to be updated. That’s what delivery means. Software also fails. The system needs to detect and recover from failure, while minimizing any impact. Capacity needs to be balanced against demand. Adding and removing capacity must become routine and trivial. Similar to other configuration tools you might be familiar with, BOSH is based on declarative idempotent resource abstractions. What do all those words mean? They mean that BOSH isn’t told what to do, BOSH is told what should be, and then does the right thing to make that be true. In BOSH these declarations abstract a service deployed as a distributed system, where servers are a lower level primitive in the service abstraction, and BOSH handles the orchestration with rolling no downtime upgrades and canary deployments out of the box.
- Let talk a bit about the overall architecture of PCF
- This is open source cloud foundry. Briefly describe each function Service broker provisions the logical instance and makes it available to a CF space.
- Ops Manager at https://206.128.159.234. Credentials admin / Savvis11
- Not doing this for one app. Doing this across the platform for all apps.
- There is a hierarchy to isolate the tenants on a CF environment.
- Take away: You can expose legacy middleware and as an Operator, you decide what service your developers consume.
- admin / fd60669ba943bd852c55
- Key take away: The self service concept is very powerful. Not only do you have access to the public offering from AppDirect (a Cloud Market place provider) but you can also define your own. For example you can decide to expose your own system to developer to consume, It can be an internal Oracle or DB2 database, a DB preloaded with data for testing purpose and so own. admin / fd60669ba943bd852c55
- Key take away: The self service concept is very powerful. Not only do you have access to the public offering from AppDirect (a Cloud Market place provider) but you can also define your own. For example you can decide to expose your own system to developer to consume, It can be an internal Oracle or DB2 database, a DB preloaded with data for testing purpose and so own. admin / fd60669ba943bd852c55
- Pre-requisite: Service broker already created: Connect as a cloud-developer and show the empty market place. Connect as a mobile-developer and show the empty market place Connect as an operator and create the Oracle service broker: cf create-service-broker myoracle user password <URL> Enable one plan for Cloud Team org Enable another plan for Mobile Team org. Connect back in the “Cloud Team space” and show the Cloud Plan is there and not the Mobile Plan: cf enable-service-access myoracle -p Cloud -o "Cloud Team" Connect back in the “Mobile Team” space and show the Mobile Plan is there and not the Cloud Plan: cf enable-service-access myoracle -p Mobile -o ”Mobile Team" Take away: You can expose legacy middleware and as an Operator, you decide what service your developers consume.
- Needed a consistent way to interact with different IaaS providers. The outer layer is what operators work with, typically through Ops Manager or a command line.
- Those are some benefits we get with BOSH
- Traditional ways: Morgan for ((i=1;;i++)); do curl "http://cdeveloper. pcf.centurylinkcloud.com/ping"; echo ; sleep 1; done bundle exec rake package VERSION=2.6
- Demo: cf nozzle
- 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. Also at Pivotal we understand that you have made lot of investment in log/monitoring visualization tools. Those can be leverage as well. Our solution Make every component transparent and monitorable. Built-in separation concern between Infrastructure, Middleware and App. Benefits Operator friendly. Quicker to isolate in which layer the problem occurred. Centralized end-to-end transparency for root cause analysis Elimination of environment drifts Quicker resolution time/shorter MTTR (Mean time to resolution)
- Conclusion: This is why we see people who are operating the Pivotal Cloud Foundry platform spending a lot more time thinking strategically about which services they’d like to offer, how they’d like to scale the platform, where they want to deploy the platform, where certain applications should be run, rather than having to think about patching, compilation, integration, and other nuances etc
- In both ‘service instance creation’ and ‘service binding creation’, org/space/plan identifiers are provided to the ‘service broker’ This allows the broker flexibility what to do
- Fine grained, policy-based network access whitelists to restrict network traffic System defaults with additional policy mapped to groups of applications Network traffic auditing
- Emphasize on the WHY/HOW/WHAT here.