Brief description of architecture design for Cloudfoundry

VMware released the industry's first open source Paas--cloudfoundry. Today, the author has been concerned about its process, of course, from its architectural design to harvest a lot of things, now take out to share with you my feelings.

This article will be divided into two parts to describe: The first part of the main cloudfoundry architecture design, from the introduction of the modules it contains, to the various parts of the message flow, the coordination of various modules; The second part will be based on the first part, Combine the two parts with the goal of how to start deploying a private PAAs in your datacenter Cloudfoundry.

The first part of the story will cite Pat's speech on the Cloudfoundry architecture in Vmwarecloud Forum on October 12. Pat was in charge of Cloudfoundry core, and his speech was well worth listening to. If you are present and understand what he is saying, this part can choose to skip directly. I would not be able to speak better than that, except that I would be specific about what I said.

I. Architecture and Modules

Overall, the Cloudfoundry architecture is as follows:

This architecture diagram, as well as the module architecture diagrams used below, are from the Pat's PPT. From the above, we can see that cloudfoundry mainly consists of the following major components:

1, Router: As the name suggests, Router component in Cloudfoundry is to all incoming request route. There are two main types of request to enter the router: first, from Vmcclient or STS, by the Cloudfoundry user, the management directives.

For example: List all your apps Vmcapps, submit a apps, and so on. This type of request is routed to the Applife management component, called the Cloudcontroller component, and the second is the request for an outside visit to your deployed apps. This part of the requests is routed to appexecution, or components called Deas. All the requests entering the Cloudfoundry system will pass through the router component, seeing that there may be friends who worry that router becomes a single point, thus becoming the bottleneck of the entire cloud.

But Cloudfoundry as a cloud system, the core of its design is to go to a single point of dependency, component parallel expansion, and can be replaced to ensure extensibility, this is cloudfoundry, and even all cloud computing system design principles, the later article will discuss how cloudfoundry do this, At present, as long as you know, the system can deploy a number of routers together to deal with the requests, but router upper loadbalance is not cloudfoundry implementation scope, Cloudfoundry only ensure that all request is stateless , so that the upper balanced load selection surface is very very large, for example, can be done through DNS, can also deploy hardware loadbalancer, or simple point, to get a ngnix as a loading balancer, are feasible.