VirtualClusterAPI

Work in Progress

1. Rationals
   1. There are many use cases of IaaS that require the provisioning of a group of compute/storage/network instances in order to satisfy the requirements of work loads from the tenants. These requirements include failure resilience, IO performance, redundancy, and security to name a few. Such requirements possess properties that go beyond the individual instance specification and thus should be expressed using constructs beyond individual instance such as "Server" and "Volume". For example, some users might want to have a web service cluster that contains a pair of redundant soft load balancers, a pair of redundant data base servers, and several web servers. To mitigate single device failure, the redundant servers should be placed in different hosts (or even racks and physical clusters). On the other hand, to achieve good throughput between the servers with different "roles", affinity rule should apply to the placement of any particular load balancer, data base server and web server. Such complicated requirements are difficult to express using the current construct.
   2. It is the responsibility of the platform rather than the users/tenants to find a good placement for these groups of instances. Users should worry about their high level requirements (capability requirements, QoS, SLA etc.), but not worry about details such as which host to avoid placing his/her VMs on.
   3. Current available provisioning unit is individual servers or volumes and requirements across multiple instances are enforced by scheduling hints (which are often not visible to users/tenants).
2. API specs

Virtual Cluster is a new resource that tenants can perform CRUD operations on. The format of the API follows the same format as server (VM) and volume.

• Create a virtual cluster

POST v2/{tenant_id}/vclusters/

• Describes a specific virtual cluster

GET v2/{tenant_id}/vclusters/{vcluster_id}

• Update a virtual cluster

PUT v2/{tenant_id}/vclusters/{vcluster_id}

• Delete a virtual cluster

DELETE v2/{tenant_id}/vclusters/{vcluster_id}

The same authentication mechanism applies. When creating a virtual cluster, the tenant needs to provide parameter data to customize the instances and groupings for the virtual data. :The object model is given as below:

VCluster (UUID)

name:

instances: []

groupings:[groups]

Instance (UUID)

name:

type: [server|volume|network]

spec: {}

Group(UUID)

name:

spec: {policy: anti affinity/proximity}

members: [instance id's/names]

1. Difference from HEAT

HEAT also performs orchestration across OpenStack Nova/Cinder/Glance/Quantum and other services. However, it more focuses on the application deployment, image packaging, software configuration, package upgrade and so on. We can treat it as a vertical orchestration that is driven from application top down to infrastructure. Here, the focus is solely on infrastructure layer for the purpose of providing a higher level of bundled compute/storage/networking services to upper layers (e.g., platform layer, application layer). Heat can utilize this service to facilitate the application deployment.