Distributed Design and Architecture of Cloud Foundry

15,942 views
15,710 views

Published on

In this session we will dig deep into Cloud Foundry's core architecture and design principles. We will discuss the challenges around scaling and operating a large scale service as we combined the PaaS and traditional IaaS layers, and how we achieve multiple updates per week to the system with no perceived downtime. Allowing user to download a single virtual machine that is a complete replica of the service presented some challenges as well, and we will discuss our approach to offering up the downloadable private cloud.

Published in: Technology, Education
1 Comment
65 Likes
Statistics
Notes
No Downloads
Views
Total views
15,942
On SlideShare
0
From Embeds
0
Number of Embeds
2,621
Actions
Shares
0
Downloads
1,156
Comments
1
Likes
65
Embeds 0
No embeds

No notes for slide

Distributed Design and Architecture of Cloud Foundry

  1. 1. Design and Architecture Derek Collison
  2. 2. What is Cloud Foundry?2
  3. 3. The OpenPlatform as a Service3
  4. 4. What is PaaS?4
  5. 5. Or more specifically, aPaaS?5
  6. 6. aPaaS • Application Platform as a Service • Applications and Services6
  7. 7. aPaaS • Application Platform as a Service • Applications and Services • Not • VMs • Memory • Storage • Networks • CPU7
  8. 8. What is OpenPaaS?8
  9. 9. OpenPaaS • Multi-Language • Multi-Framework • Multi-Services • Multi-Cloud, Multi-IaaS • Hybrid - Public or Private or Both • OpenSource9
  10. 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, AWS10
  11. 11. 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 Services11
  12. 12. What is our Goal?12
  13. 13. What was our Goal? Raise the unit of currency to be the application and its associated services, not the infrastructure13
  14. 14. What was our Goal? Best of breed delivery platform for all modern applications and frameworks14
  15. 15. What was our Goal? Favor Choice and Openness15
  16. 16. How was it Built?16
  17. 17. How was it Built? • Kernel (CloudFoundry OSS) • Core PaaS System • Kernel and Orchestrator Shells • Layered on top of IaaS • Orchestrator • IaaS creation, management and orchestration17
  18. 18. High Level Clients (VMC, STS, Browser) CF Kernel Orchestrator IaaS Hardware - CPU/Memory/Disk/Network18
  19. 19. Basic Premises • Fail Fast • Self Healing • Horizontally Scalable Components • Distributed State • No Single Point of Failure • Should be as simple as possible19
  20. 20. Basic Patterns • Event-Driven • Asynchronous • Non-blocking • Independent, Idempotent • Message Passing • Eventually Consistent20
  21. 21. 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 transport21
  22. 22. Kernel Components • All dynamically discoverable • Launch and scale in any order • Can come and go as needed • Monitor via HTTP and JSON • Location independent22
  23. 23. Kernel Components • Router • CloudController • DEA • HealthManager • Service Provisioning Agent • Messaging System23
  24. 24. Logical View Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging24
  25. 25. 25 Architecture
  26. 26. Messaging26
  27. 27. Messaging “The Nervous System”27
  28. 28. Messaging Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging28
  29. 29. 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 semantics29
  30. 30. Router30
  31. 31. Router “Traffic Cop”31
  32. 32. Router Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging32
  33. 33. Router • Handles all HTTP traffic • Maintains distributed routing state • Routes URLs to applications • Distributes load among instances • Realtime distributed updates to routing tables from DEAs33
  34. 34. CloudController34
  35. 35. CloudController “The King”35
  36. 36. CloudController Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging36
  37. 37. CloudController • Handles all state transitions • Deals with users, apps, and services • Packages and Stages applications • Binds Services to Applications • Presents external REST API37
  38. 38. HealthManager38
  39. 39. HealthManager “Court Jester”39
  40. 40. HealthManager Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging40
  41. 41. 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 itself41
  42. 42. DEA42
  43. 43. DEA “Droplet Execution Agent”43
  44. 44. DEA Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging44
  45. 45. 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-Tenant45
  46. 46. How does it all Work?46
  47. 47. 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 ready47
  48. 48. 48 Architecture
  49. 49. 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:port49
  50. 50. 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 selection50
  51. 51. 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 assumed51
  52. 52. 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 again52
  53. 53. 53 Architecture
  54. 54. 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 possible54
  55. 55. What about Services?55
  56. 56. Services Browser VMC client STS plugin (user app access) Routers CloudControllers App App HealthManager Services DEA Pool Messaging56
  57. 57. 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 value57
  58. 58. Provisioning VMC/STS 1 Routers 2 CloudControllers Services Gateway 3 5 6 4 Service Node Service Node Service Node Application MySQL Redis Redis Messaging58
  59. 59. Access (Direct) Browser (user app access) 1 Routers CloudControllers Services Gateway Service Node Service Node Service Node Application MySQL Redis Redis 2 Messaging59
  60. 60. 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 vSphere60
  61. 61. Learn more: www.cloudfoundry.org blog.cloudfoundry.com support.cloudfoundry.com61
  62. 62. Thank You62
  63. 63. Questions? dcollison@vmware.com derek.collison@gmail.com twitter: derekcollison63

×