Difference between revisions of "Jacket"

Revision as of 07:36, 18 March 2016

Overview

Now there are many people and enterprises using private clouds based on OpenStack or VMware vCloud Director and so on, and the public clouds such as AWS, Azure and so on. Because clouds' API models are different from each other, users will 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.
Large workload to deploy the business in a new cloud: When users want to deploy their business in a new cloud, there are a large workload to redevelop the business deployment tool or deploy the business manually using the API provided by the new cloud.
Difficult to scale out the workload across the different clouds: There is no a unified resource management of the different clouds, users need develop a scaling across clouds tool which is not friendly because the tool need user to know the differences of the business configuration in different clouds.

The target of jacket project is to offer the standard OpenStack API model as the unified API model to manage the different clouds, such as AWS, Azure, the private clouds based on VMware vCloud Director and so on. And users can manage the different clouds just like one cloud.

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 unify the compute and block storage management?

There are two ways to unify the compute and block storage management.

One way is that jacket project offers the standard nova-compute hypervisor drivers and cinder-volume drivers for AWS, Azure, VMware vCloud Director and so on. AWS, Azure and so on will be managed as the different hypervisors just like KVM, Xen and so on.

But this solution has the following weaknesses:

Only one account in the provider cloud can be used as the static configuration in nova-compute and cinder-volume driver because the standard nova-compute and cinder-volume can’t offer the restful API. When users want to modify the manage account, they must modify the static configuration and restart nova-compute and cinder-volume, and they can’t use the provider cloud through OpenStack.
The number of the available resources in the provider cloud managed by OpenStack just is equal to the quota of one account of the provider clouds. And all projects in OpenStack share the resources, each project’s quota must be less than the one in provider cloud. Maybe it can’t be acceptable for users.
The associations of the flavors between OpenStack and the provider cloud just can be as the static configuration in nova-compute because of the same reason with the access account management. So, when the provider clouds add or update the flavors, users must update the configuration and restart nova-compute.
When users have the legacy compute and block storage resources in the provider clouds, we just can offer a tool to inject the legacy resources’ data into the database of nova and cinder. Obviously it is not a good solution.

In the other way, jacket will run as an independent service to manage the different clouds, and it offers the compute, block storage restful API and multiply clouds configuation restful API. The compute and block storage API is used to managed the resources in provider clouds for OpenStack driver. The multiply API is used to manage the associations of project, image, flavor and so on. This solution just like that OpenStack manages the bare metal servers using Ironic service.

This solution has the following advantages rather than the first solution:

Jacket will offer API to configure the associations between projects created in OpenStack and the accounts in provider clouds. Users can add or update the associations without restarting any services.
One project or more than one projects can be associated with an account in provider clouds. So that one project can have the quota of one account in provider clouds, and also can share it with other projects.
Jacket offers API to configure the associations between the flavors created in OpenStack and the flavors in provider clouds. The similar flavors in different provider clouds can associate with the same or different flavor in OpenStack according to users’ use case. When provider clouds add new flavors, users can create the new flavors then associate them with the new one in provider clouds dynamically.
Jacket offers the legacy resources adoption feature with restful API. In the feature Jacket will call the resources allocation API of nova and cinder to create the records in their database, when nova and cinder call jacket, jacket will just look up the corresponding legacy resources instead of creating a new resource.

Clouds are very different from hypervisors, for example hypervisors has no tenant management, image management, flavor management and so on. So the second solution, jacket runs as an independent service and offers the restful API, will be better.

How to unify the network management?

There is a solution to use OpenStack Neutron to offer the unified network function through the overlay virtual network based on the provider clouds’ virtual network. It will be another project, jacket project will not in include this part, and just focus on the unified compute and block storage management.

How to unify image management?

The provider clouds have the different demands for the images, and one image can’t run in all provider clouds. How to unify the image management? There is a solution that users upload the images to provider clouds, and jacket offers the restful API to allow users associate the images created in OpenStack without image file with the images in provider clouds.

Architecture

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.

FAQ

Q: Is Jacket one kind of API gateway for different clouds?

There are some differences between clouds, the major task of Jacket is how to shield the differences. So that Jacket will not be an API gateway, it has the complex objects management and function processing, for example :

Unified resource uuid allocation: When users call Jacket resource create API, Jacket will allocate the uuid for the resource according to its own uuid format, then associates it with the unique identification in provider cloud, because of the different unique identification and the different behaviour in clouds. e.g. 1) AWS can't support to create a volume from an AMI image and boot a VM from a boot volume. So that when users create a VM from a volume in AWS using Jacket, Jacket will just create a volume record in database and return its uuid, after the VM is created in AWS, Jacket will get the boot volume's uuid in AWS and write it into the mapping table in database. 2) Creating a volume's snapshot, AWS will just return a job id, and users will get the snapshot's id after the job starts. Jacket will return the snapshot's uuid allocated by Jacket, then it will query the snapshot's id in AWS periodically and write it into the mapping table in database.
Fake volume management: Some clouds have not the complete volume management, for example, VMware vCloud Director have no the boot volume object, and it can't support volume's backup and snapshot, so that Jacket will implement these functions for this kind of clouds.

There will be more differences of clouds' behaviour and function. Jacket will shield the differences like the above mentioned to let users feel that they are using just one cloud.

Q: What is the difference between Tricircle and Jacket?

Tricircle mainly focuses on the API gateway and networking automation across multiple OpenStack instances, but Jacket focuses on how to manage the different clouds just like one cloud. There are some differences:

Account management and API model: Tricircle faces multiply OpenStack instances which can share one Keystone and have the same API model, but Jacket will face the different clouds which have the respective service and different API model. For example, VMware vCloud Director has no volume management like OpenStack and AWS, Jacket will offer a fake volume management for this kind of cloud.
Image management: One image just can run in one cloud, Jacket need consider how to solve this problem.
Flavor management: Different clouds have different flavors which can not be operated by users. Jacket will face this problem but there will be no this problem in Tricircle.
Legacy resources adoption: Because of the different API modles, it will be a huge challenge for Jacket.

Their design principle is different, too. Tricircle will be stateless and has no uuid mapping, but Jacket will cache the status and store the uuid mapping to shield the differences between clouds. For example, in case of creating snapshot in AWS, Jacket returns users a uuid in Jacket, then it will query the job's status periodically before getting the real snapshot id in AWS. In this period if users query the snapshot's status, Jacket will return 'Pending' defined by Jacket.

I think it is maybe a good solution that Jacket works to unify the API model for different clouds, and then using Tricircle over Jacket to offer the management of a large scale VMs.

Revision as of 07:15, 18 March 2016 (view source) Okay22many (talk \| contribs) (→‎FAQ) ← Older edit		Revision as of 07:36, 18 March 2016 (view source) Okay22many (talk \| contribs) (→‎FAQ) Newer edit →
Line 101:		Line 101:


−	~~Thier~~ design principle is different, too. Tricircle will be stateless and has no uuid mapping, but Jacket will cache the status and store the uuid mapping to shield the differences between clouds. For example, in case of creating snapshot in AWS, Jacket returns users a uuid in Jacket, then it will query the job's status periodically before getting the real snapshot id in AWS. In this period if users query the snapshot's status, Jacket will return 'Pending' defined by Jacket.	+	Their design principle is different, too. Tricircle will be stateless and has no uuid mapping, but Jacket will cache the status and store the uuid mapping to shield the differences between clouds. For example, in case of creating snapshot in AWS, Jacket returns users a uuid in Jacket, then it will query the job's status periodically before getting the real snapshot id in AWS. In this period if users query the snapshot's status, Jacket will return 'Pending' defined by Jacket.

	I think it is maybe a good solution that Jacket works to unify the API model for different clouds, and then using Tricircle over Jacket to offer the management of a large scale VMs.		I think it is maybe a good solution that Jacket works to unify the API model for different clouds, and then using Tricircle over Jacket to offer the management of a large scale VMs.