Simple Cloud Federation using Availability Zones

Registered by ashwin naresh

Motivation and Need:
OpenStack has no built-in feature for federation between different Cloud Service Providers. We propose an architecture for OpenStack-Amazon or OpenStack-OpenStack federation using the concept of Availability Zone.
A common use case of this solution will be to help in efficient management of resources in enterprises when there are sudden spikes in demand for computational resources. This solution helps in balancing the load efficiently between a private cloud like OpenStack (set up in local data centres) and a public cloud like Amazon from where extra resources can be acquisitioned as and when needed.
Design Benefits:
• This infrastructure is capable of managing the entire lifecycle of the VMs running on that cloud. The private cloud looks at the public cloud element as one single availability zone. Hence, using this architecture, we can scale the OpenStack cloud across geographic regions and also, enable leveraging resources from the public cloud. Hence, making the cloud more elastic.
• Using availability zones in the overall architecture will make the mapping of actual attributes and zones across different Cloud providers more coherent. Ideally it would provide a logical one-one mapping between the two resource providers.
• A monitoring daemon running on the public cloud updates the instance information on the local cloud such that the instance running on the public cloud can be managed from the local dashboard itself.
Design Prerequisites:
• The data-centre has a local OpenStack cloud set up. In our architecture, we have at least 2 availability zones defined in our local OpenStack cloud – one local availability zone where the local VMs are running and another public cloud availability zone which is mapped to the public cloud provider.
• We define an architecture where a cloud administrator can apply load balancing policies based on the memory usage and the number of VMs currently running on the local cloud. The load balancing policies themselves can be defined in a policy.json file.
Workflow:
• With every incoming request, the nova-scheduler checks the scheduling policy. If the load in the local availability zone is higher than the set threshold in the policy, VMs are scheduled onto the public cloud availability zone.
• The virtualization driver of the host in the public cloud availability zone is modified so that the instance scheduled onto it is spawned on an Amazon Virtual Private Cloud using the Boto APIs or on a public OpenStack cloud using the nova-client API.
• The quota of instances available to this host in the public cloud availability zone is increased so as to accommodate large number of federated instances.
• The resource usage by the federated instance is monitored and the details are returned to Nova using a monitoring daemon.
• If the load in the local availability zone is well within the threshold value specified, the Nova-scheduler schedules the instance onto the local availability zone. The instance scheduled in the local availability zone is spawned using the native virtualization driver present.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
ashwin naresh
Direction:
Needs approval
Assignee:
None
Definition:
Drafting
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.