Difference between revisions of "Jacket"

Revision as of 01:10, 1 March 2016

Overview

Now there are many people and enterprises using private clouds which are set up by OpenStack or VMware vCloud Director and so on, and the public clouds such as AWS, Azure and so on. Because the API models of each different cloud are different, users meet the following problems:

High cost of learning: users have to cost long time to learn how to use the new API of a new cloud which they will use.

Use case

Cross cloud deployment

A typical web application is composed with 3 different tiers, the load balancer tier, the web front tier, and the app backend tier. Users have a private cloud based on OpenStack or VMware and so on, which just has less resources but more secure than public clouds. So they can use the standard OpenStack API to launch the web service's backend virtual machines in private cloud, launch the load balancer and web front virtual machines in the public clouds.

Cloud burst

In some cases, user would not like to put anything in public cloud if not necessary. User would like to put all parts of the application in private cloud usually, and they would like to scale the web front end in case of there is a 'Cloud Burst' comes. For example, I have a online shopping mall in my private cloud, the system resource and internet bandwidth is enough in normal case. But there will have a bottleneck in big festival period, so I would like to scale out my application to public cloud in that period, and I would like to scale in my application back to private cloud after the big festival.

Challenges

How to shield the functional differences between clouds

There are huge differences between the API models of the different provider clouds. For example, VMware vCloud Director can't support to create the bootable volume through the image, and it can't support the snapshot/backup of the volumes. But OpenStack and AWS can support these festures. So it is the first challenge to offer the unified standard OpenStack API model to manage the different provider clouds.

How to unify images and flavors' management

The provider clouds have the seprate image storehouses, each provider cloud has the different demands for the images. In the markets of the provider clouds, there are a lot of particular images which just can be used in the specified provider cloud, and there are some images which are the same OS version.

The provider clouds have defined a lot of virtual machine flavors for users, most of them are different.

How to unify images and flavors' management just like one cloud?

How to import the existing resources in the provider clouds

Users maybe have a lot of resources in the provider clouds before they use this solution. How to import the existing resources will be a challenge.

We will solve these challenges through 'Jacket' project.

Architecture

Architecture layer 0

Jacket will offer the unified API models to manage the provider clouds. Jacket has the following functions:

Account management: manage the accounts of the provider clouds, and the asociation between the projects in OpenStack and the accounts in the provider clouds.
Flavor/image unified management: manage the associations between the flavors/images in OpenStack and the virtual machines flavors/images in the provider clouds.
Fake volume management: offer the fake volume management to sheild the missing volume function in some provider clouds.
Consistency check: check the consistency between the resources in OpenStack and the real resources in provider clouds.

Jacket can be deployed as a cluster. The Jacket cluster can manage multiply provider clouds at the same time, and we can also deploy multiply Jacket clusters in that each Jacket cluster just manage one provider cloud at the case of managing large scale virtual machines.

OpenStack will call Jacket through nova-compute/cinder-volume driver, just like calling Ironic to manage baremetal servers. There will be one nova-compute and cinder-volume to manage the resources in each availability zone of each provider cloud. Each nova-compute/cinder-volume has the different configuation of the name of the managed availability zone in the provider cloud.

Architecture layer1

Jacket will have three modules, they are Jacket-api, Jacket-worker and Jacket-resmng.

Jacket-api: offer the unified API models, its HA model is "active-active" just like nova-api and cinder-api.
Jacket-worker: only this module contact with the provider clouds. It will receive the messages from Jacket-api and Jacket-resmng which will do something in the provider clouds, then it will contact with the provider clouds and handle the response from the provder clouds. It has a cloud adaptor framework, each provider cloud will offer a plugin to manage the provider cloud.
Jacket-resmng: it will collect the resouces' status period and offer importting the existing resources in the provider clouds.

To do list

Phase1: Unified compute API(AWS/vCloud)

Phase2: Unified block storage API(AWS/vCloud)

Phase3: Scaling across clouds(AWS/vCloud)

Phase4: Importing the existing reources(AWS/vCloud)

@@ Line 1: / Line 1: @@
 == Overview ==
-More and more enterprise are thinking about how to leverage the usage of private cloud and public cloud. Public cloud have very good scalability and have cost advantage in many cases, while Private cloud have more security assurance and have more feasibility for IT administrator. It is a hard decision to choose just one of them.
+Now there are many people and enterprises using private clouds which are set up by OpenStack or VMware vCloud Director and so on, and the public clouds such as AWS, Azure and so on. Because the API models of each different cloud are different, users meet the following problems:
-A traditional Cloud Broker can provider a basic multi-cloud management function, but it is not a good experience for the administrator, since they still feels like they are using multiple separated clouds with a unified UI style. What's worse is that they need to learn one more type of operational mode and API besides the existing clouds APIs.
-A hybrid cloud solution is required, which will provide smooth inter-cloud management which makes you feels just like managing one cloud, and it should provide the existing standard API and operational mode which makes you shorten learning curve and easy to integrate with industry existing services.
+* High cost of learning: users have to cost long time to learn how to use the new API of a new cloud which they will use.
-The target of Jacket project will solve the problem with OpenStack. It will be an adaptor for the different clouds, and it will be called by the services in OpenStack, for example nova, cinder and so on. In this way, OpenStack will manage the different clouds and offer the standard OpenStack API just like one cloud. At the same time, users can enjoy a series of the 3rd part tools which are based on OpenStack.
 == Use case ==