Browse Prior Art Database

Cooperative hierarchical placement Disclosure Number: IPCOM000195813D
Publication Date: 2010-May-18
Document File: 3 page(s) / 62K

Publishing Venue

The Prior Art Database


Disclosed in this article is a scheme for resolving collaborative hierarchical placement. The collaborative hierarchical placement problem is a variant of the general placement problem that deals with having multiple layers of entities, where entities of each layer are placed on top (or within) entities of another layer, and each layer having its own placement controller, and thus risk having conflicting decisions among the layers. This article proposes a general scheme for resolving collaborative hierarchical placement using a protocol for communicating between placement controllers of adjacent layers.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 39% of the total text.

Page 1 of 3

Automated resource provisioning to hosted user level services (such as virtual machines and web applications) is in the core of the cloud computing paradigm. To support elasticity those decisions are typically taken dynamically at runtime based on the current resource utilization and the client workload. The problem of determining the optimal target resource allocation is typically referred to as the placement problem, and is typically implemented through a dedicated software component, called the placement controller.

    In practice, the cloud management systems typically handle allocation of a nesting hierarchy of resources, such as e.g., assignment of virtual machines to physical nodes, application servers to the virtual machines, and applications to the application servers.

To achieve optimality, the placement controller should be able to simultaneously take into account the full collection of constraints imposed by all the resources throughout all levels of the hierarchy. However, this sort of a comprehensive placement optimization is often hard to achieve in practice as each level of the hierarchy is typically implemented by an independently developed technology, each having its own proprietary instance of the placement mechanism.

    In particular, the Infrastructure-as-a-Service (IaaS) systems, such as e.g., Amazon EC2 and Microsoft Azure, support virtual machines as the primary user abstraction, and therefore would typically include a placement controller whose primary responsibility is to handle allocation of virtual machines to physical nodes. The particular instance of the placement problem solved by the IaaS systems is given the current resource usage and user demand to determine the necessary number of VMs, their target hosting physical machines, and the amount of the physical resources on each of the physical node allocated to each of the hosted VMs.

    On the other hand, the Platform-as-a-Service (PaaS) systems, such as e.g., Google AppEngine, offer the entire application hosting platforms, such as various types of application containers, data base connectivity, data and messaging services, etc. For example, if the clustered J2EE application server environment is offered as a service, the associated placement mechanism should be able to determine the size of the application clusters and the assignment of the application instances to the servers in order to achieve the desired level of QoS given the current resource usage and availability constraints.

    In practice, the PaaS layer would typically be deployed on top of an IaaS layer, thus resulting in two layers of virtualized environment, each with its own proprietary placement mechanism. Allowing these two placement mechanisms to operate independently of each other would often result in sub-optimal and/or conflicting placement decisions. For example, if the objective of the PaaS application placement mechanism is to achieve maximum degree of the request load distribution, it w...