Continuing where I left off last time, here is some thoughts on massively distributed cloud platforms as I see it from the cloudband perspective.
We are building a distributed cloud with many sites (cloudNodes) connected through WAN (service provider’s network). In that scenario, it’s reasonable to assume that
- … the PaaS layer in a distributed cloud orchestrates the IaaS actions on to different cloudNodes: making decisions on geographical placement zones and actions in granularity of cloudNodes when IaaS actions are required. For example: install application Tier #1 in Frankfurt and application Tier #2 in Berlin.
- … IaaS actions on the cloudNode granularity are initiated by the OpenStack management layer.
- … further extensions and plugins around placements on a single OpenStack cloudNode will be developed. One single extension I find interesting is the VM Ensembles concept designed by Gilad Zlotkin and Gary Kotton. I stumbled upon this concept while researching composite Nova scheduling concepts such as affinity rules when deploying IaaS.
The process handling an action must
- … analyze the action and break it down into IaaS and Application level operations.
- … check if a decision is required or policy has been compiled already to define what needs to be done and where (meaning: in which cloudNode and what in this specific cloudNode).
- … compile policy and decide (in another post, I’ll discuss this policy engine in more detail).
- … perform this operation while defining IaaS policies for this specific cloudNode (such as ensemble batch operations or compute affinity and anti-affinity rules or operate on other Nova or other scheduler based operations).
- … return the result to the PaaS orchestrator for further application components installation or networking updates, according to the relevant elasticity rules.
To sum up: Leveraging current and future functionalists such as ensembles, the distributed cloud management system should off-load IaaS batch operations and cloud node level decisions to the OpenStack management layer. Thus, it would be able to decide how to handle a request for infrastructure, or the placement of this infrastructure. These tools should be developed (eventually) as OpenStack scheduler plugins and be used by the cloud platform PaaS layer on top.
I just wanted to provide initial taste on this very broad topic. would be happy to hear your view.
Feel free to ping me or just drop a note,