Browse Prior Art Database

System and method to optimize cloud resources using variable tiering scheme Disclosure Number: IPCOM000239769D
Publication Date: 2014-Dec-01
Document File: 3 page(s) / 156K

Publishing Venue

The Prior Art Database


A system and method to optimize cloud resources using variable tiering scheme is disclosed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 01 of 3

System and method to optimize cloud resources using variable tiering scheme

Disclosed is a system and method to optimize cloud resources using variable tiering scheme.

The disclosed system balances dynamically changing hardware resources in a cloud environment based on tenants allocation of a funding. The allocation of funds are variable in that each additional unit of resource (e.g. 1 vCPU, 2 vCPU, etc) will have a different rate which can be either dictated by the service supplier or formed by the tenant. The system can then optimize resource balancing techniques in a way that matches each tenants ability to pay.

From a user perspective, a cloud system often appears to have unlimited capacity but in reality no cloud system has unlimited resources. Every cloud system must determine how to allocate its unused resources (or reallocation of used resources). For a given set of resources, the system allows the collective cloud community to protect resources they've already procured.

Today's public clouds provide spot instances which monetizes their excess capacity without compromising their flexibility. These solutions however do not prioritize which spot instances are reclaimed as the load on the system increases. What is needed is a mechanism for the spot instance creator to define an instance profile. This instance profile defines instance configurations and to what cost the creators are willing to pay to avoid having their instance reclaimed.

To solve this, the common approach is to levy a cost to the user in various ways.
In a pay as you go model, the user pays directly, so he is motivated to minimize the usage.

In a shared pool (e.g., paid by an organization), a user does not have to pay for the resources directly, so the cost may exist in some other forms:

Hall of shame: Cloud portal lists the users with the highest resource usage

Nagging by admin: Occasional review requiring user to reconfirm usage

Approval by admin: This requires work by the admin and may take away some of the self-service convenience
Spot Price: However, if another user overbids their Spot Price, they will lose their instance.

The disclosed model gives users a more flexible pricing scheme where users can associate a different pricing model, aligned more to their applications' requirements. e.g. place more weight (in terms of cost) at various levels of resources where they see fit.

The disclosed method addresses the fact that the resource usage is not being prioritized. Today, all self-service requests are treated with equal priority, or in some cases prioritized via business priority (e.g. gold/silver/bronze), but in reality, there exists different priorities for different requests that are driven by market based dynamics. Some users may need the resource for an important project with a firm deadline. Others may just want to try out something and may be willing to return the resource when needed. A relative market based priority is added on the self service...