Recommended
Recommended
More Related Content
What's hot
What's hot (11)
Viewers also liked
Viewers also liked (20)
Similar to Cloud Foundry: Inside the Machine
Similar to Cloud Foundry: Inside the Machine (20)
More from Derek Collison
Recently uploaded
Recently uploaded (20)
Cloud Foundry: Inside the Machine
- 1. Inside The Machine Derek Collison Thursday, October 27, 11
- 2. What is Cloud Foundry? 2 Thursday, October 27, 11
- 3. The Open Platform as a Service 3 Thursday, October 27, 11
- 4. What is PaaS? 4 Thursday, October 27, 11
- 5. Or more specifically, aPaaS? 5 Thursday, October 27, 11
- 6. aPaaS • Application Platform as a Service • Applications and Services 6 Thursday, October 27, 11
- 7. aPaaS • Application Platform as a Service • Applications and Services • Not • VMs • Memory • Storage • Networks • CPU 7 Thursday, October 27, 11
- 8. What is OpenPaaS? 8 Thursday, October 27, 11
- 9. OpenPaaS • Multi-Language • Multi-Framework • Multi-Services • Multi-Cloud, Multi-IaaS • Hybrid - Public or Private or Both • OpenSource 9 Thursday, October 27, 11
- 10. OpenPaaS • Multi-Language • Ruby, Java, Scala, Node.js, Erlang, Python, PHP.. • Multi-Framework • Rails, Sinatra, Spring, Grails, Express, Lift • Multi-Services • MySQL, Postgres, MongoDB, Redis, RabbitMQ • Multi-Cloud, Multi-IaaS • vSphere, MicroCloud, OpenStack, AWS 10 Thursday, October 27, 11
- 11. The Open PaaS Ap pli Private ca ce tio rfa Data Clouds n e Services Int Se Public rvi er vid ce Msg Services Clouds ro Int dP e Micro rfa ou Clouds ce Other Cl Services 11 Thursday, October 27, 11
- 12. The Open PaaS Ap pli vFabric Private ca ce Postgres tio rfa Data Clouds n e Services Int Se Public rvi er vFabric vid ce RabbitMQTM Msg Services Clouds ro Int dP e Micro rfa ou Clouds ce Other Cl Services 11 Thursday, October 27, 11
- 13. What is our Goal? 12 Thursday, October 27, 11
- 14. What was our Goal? Raise the unit of currency to be the application and its associated services, not the infrastructure 13 Thursday, October 27, 11
- 15. What was our Goal? Best of breed delivery platform for all modern applications and frameworks 14 Thursday, October 27, 11
- 16. What was our Goal? Favor Choice and Openness 15 Thursday, October 27, 11
- 17. How was it Built? 16 Thursday, October 27, 11
- 18. How was it Built? • Kernel (CloudFoundry OSS) • Core PaaS System • Kernel and Orchestrator Shells • Layered on top of IaaS • Orchestrator • IaaS creation, management and orchestration 17 Thursday, October 27, 11
- 19. High Level Clients (VMC, STS, Browser) CF Kernel Orchestrator IaaS Hardware - CPU/Memory/Disk/Network 18 Thursday, October 27, 11
- 20. Basic Premises • Fail Fast • Self Healing • Horizontally Scalable Components • Distributed State • No Single Point of Failure • Should be as simple as possible 19 Thursday, October 27, 11
- 21. Basic Patterns • Event-Driven • Asynchronous • Non-blocking • Independent, Idempotent • Message Passing • Eventually Consistent 20 Thursday, October 27, 11
- 22. Basic Design • All components loosely coupled • Few “Classes”, many “Instances” • Messaging as foundation • Addressing and Component Discovery • Command and Control • JSON payloads • HTTP or File/Blob for data transport 21 Thursday, October 27, 11
- 23. Kernel Components • All dynamically discoverable • Launch and scale in any order • Can come and go as needed • Monitor via HTTP and JSON • Location independent 22 Thursday, October 27, 11
- 24. Kernel Components • Router • CloudController • DEA • HealthManager • Service Provisioning Agent • Messaging System 23 Thursday, October 27, 11
- 25. Logical View Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging 24 Thursday, October 27, 11
- 26. Architecture 25 Thursday, October 27, 11
- 27. Messaging 26 Thursday, October 27, 11
- 28. Messaging “The Nervous System” 27 Thursday, October 27, 11
- 29. Messaging Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging 28 Thursday, October 27, 11
- 30. Messaging • Addressing and Discovery • No static IPs or DNS lookups req’d • Just Layer 4 • Command and Control • Central communication system • Dial tone, fire and forget • Protects *itself* at all costs • Idempotent semantics 29 Thursday, October 27, 11
- 31. Router 30 Thursday, October 27, 11
- 32. Router “Traffic Cop” 31 Thursday, October 27, 11
- 33. Router Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging 32 Thursday, October 27, 11
- 34. Router • Handles all HTTP traffic • Maintains distributed routing state • Routes URLs to applications • Distributes load among instances • Realtime distributed updates to routing tables from DEAs 33 Thursday, October 27, 11
- 35. CloudController 34 Thursday, October 27, 11
- 36. CloudController “The King” 35 Thursday, October 27, 11
- 37. CloudController Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging 36 Thursday, October 27, 11
- 38. CloudController • Handles all state transitions • Deals with users, apps, and services • Packages and Stages applications • Binds Services to Applications • Presents external REST API 37 Thursday, October 27, 11
- 39. HealthManager 38 Thursday, October 27, 11
- 40. HealthManager “Court Jester” 39 Thursday, October 27, 11
- 41. HealthManager Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging 40 Thursday, October 27, 11
- 42. HealthManager • Monitors the state of the world • Initial value with realtime delta updates to “intended” vs “real” • Determines drift • Complains to the CloudControllers when something is not correct • No power to change state itself 41 Thursday, October 27, 11
- 43. DEA 42 Thursday, October 27, 11
- 44. DEA “Droplet Execution Agent” 43 Thursday, October 27, 11
- 45. DEA Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging 44 Thursday, October 27, 11
- 46. DEA (Droplet Execution Agent) • Responsible for running all applications • Monitors all applications • CPU, Mem, IO, Threads, Disk, FDs, etc • All apps look same to DEA • start and stop • Express ability and desire to run an application • runtimes, options, cluster avoidance, memory/cpu • Alerts on any change in state of applications • Provides secure/constrained OS runtime • Hypervisor, Unix File and User, Linux Containers* • Single or Multi-Tenant 45 Thursday, October 27, 11
- 47. How does it all Work? 46 Thursday, October 27, 11
- 48. Pushing an App • Client (VMC/STS) pushes meta-data to CC • Client optionally pushes resource signatures (diff analysis, sys wide) • Client pushes app resources to CC • CC puts app together • CC stages app asynchronously • CC binds and stages services • Droplet ready 47 Thursday, October 27, 11
- 49. Architecture 48 Thursday, October 27, 11
- 50. Running an App • CC asks DEAs for “help” • First DEA back wins! Simple • CC sends start request to selected DEA • DEA pushes the “green” button • DEA waits and monitors pid and ephemeral port for app to bind • When app is healthy, sends “register” message • Register message is seen by HM and Routers • Routers bind URL to host:port 49 Thursday, October 27, 11
- 51. DEAs answer? • DEAs first determine YES or NO • correct runtime, options, memory, etc • Then calculate a Delay Taint • SHA hash of application • memory • cpu • Taint allows balancing and selection 50 Thursday, October 27, 11
- 52. Scale up & down? • Exact steps as running the app the first time • SHA1 taint helps avoid clustering • memory/cpu taint helps distribute as evenly as possible • Nothing pre-computed • Nothing assumed 51 Thursday, October 27, 11
- 53. Crashes? • If your app stops and we did not tell it to, that is a crash • Crashed apps are immediately detected by DEA and messaged • Routers disconnect route instantly • HM will signal CC • something is wrong • CC will issue run sequence again 52 Thursday, October 27, 11
- 54. Architecture 53 Thursday, October 27, 11
- 55. Access to my App? • All routers understand where all instances of your application are running • Will randomly pick backend, not semantically aware. • Will remove routes that are stale or unhealthy • Session stickiness and replication available, but best to avoid if possible 54 Thursday, October 27, 11
- 56. What about Services? 55 Thursday, October 27, 11
- 57. Services Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging 56 Thursday, October 27, 11
- 58. Services • Service Advertisement • Service Provisioning • Gateway fronts multi-backends • Service Nodes scale independent • App and service talk directly • API to register into system • Closure for additional value 57 Thursday, October 27, 11
- 59. Provisioning VMC/STS 1 Routers 2 CloudControllers Services Gateway 3 5 6 4 Service Node Service Node Service Node Application MySQL Redis Redis Messaging 58 Thursday, October 27, 11
- 60. Access (Direct) Browser (user app access) 1 Routers CloudControllers Services Gateway Service Node Service Node Service Node Application MySQL Redis Redis 2 Messaging 59 Thursday, October 27, 11
- 61. Services VMware Dev Tools Partner Dev Tools Cloud Foundry consume Enterprise Services apps consume bind Data Director provision/bind service service broker controller SQLFire core services Relational DB vSphere 60 Thursday, October 27, 11
- 62. Learn more: www.cloudfoundry.org blog.cloudfoundry.com support.cloudfoundry.com 61 Thursday, October 27, 11
- 63. Thank You 62 Thursday, October 27, 11
- 64. Questions? dcollison@vmware.com derek.collison@gmail.com twitter: derekcollison 63 Thursday, October 27, 11