AMACE: agent based multi-criterions adaptation in cloud environment

Unlike traditional cloud computing, Wu et al. [2] treated a novel computing paradigm, self-organizing cloud. To automate the mechanism accomplishing resource allocation problem in cloud environment with dynamic price, authors proposed two novel economic strategies based on mechanism design: the Modified Vickrey Auction and the continuous double auction. The proposed strategies conduct to a transparent self-organizing cloud. Jieun et al. [3] presented an adaptive resource provisioning method based on two main concepts. First, it provides resource provisioning for applications via profiling of scientific applications in a heterogeneous computing infrastructure. Second, it offers an adaptive resource updated according to the availability of resource changes. In [4] Singh et al. suggested an adaptive resource management model which assist in making decisions according to execution time of the workflow. The model and depending on usage history, reschedule resources to improve performance. Ravandi et al. introduced in [5] a novel framework based on separation between the data layer and control. Authors used the black box and self-learning approach to design a self-organized and self-adaptive resource provisioning. In [6] Ghobaei-Arani et al. developed dynamic and adaptive resource provisioning approach, authors use a hybridization of the autonomic computing and the reinforcement learning. The proposed approach deals with the unexpected states like work overload, over provisioning and under-provisioning.

There have been many approaches and algorithms proposed for multi agent resource allocations and self-organization multi agent systems in cloud computing environment. Many of these approaches and algorithms are only based on a non-flexible environment model: Haresh et al. [1] suggested a broker based multi-agent system. Choosing the best provider in federated clouds is a very difficult task because users do not know the price of each resource in different clouds, which is determined dynamically, based on a demand–supply model. In [1] method, the user does not care about both the identity of the cloud provider belonging to a federated clouds and the location of the resources needed. To know which cloud service the provider will perform is not important, as the consumer has to get the resources with the minimum price. Some approaches bring new concepts as ‘borrowing’ and ‘leasing’ resources from and to other clouds. Xu et al. [7] Proposed an approach of self-organizing based on multi-agent systems. To achieve the required macroscopic properties of locally interacting agents in cloud market, they suggest a three-layered self-organizing multi-agents mechanism to support cloud commerce parallel negotiation activities. Their consumer model running mechanism uses an algorithm as a protocol of negotiation. Chaabouni et al. [8] Aimed to build a fully automatic system in which the client has simply to fulfill his requirements then loads his work using a centralized architecture of agents based on simple exchange of messages between the supervisor agent and data center agents. The agent who will be charged of the resources management must obey a list of rules. In paper [9] Kecskemeti et al. analyzed different approaches to integrate a reactive knowledge management system and suitable federation mechanisms for an on-demand generation and autonomous management of hybrid clouds. In this paper, the authors extended federated cloud management architectures with autonomous behavior. This work focused on adaptation actions and their possible effects on cloud federations. In order to prevent service level agreements (SLA) violations and resource usage optimization, the knowledge management (KM) system proposes reactive actions to minimize energy consumption. In the purpose of maintaining a balance between SLA violations and resource consumption, management of cloud infrastructures is done with an autonomous manner. In paper [10] Patel et al. presented methods for VM allocation in cloud providers federation, trying to maximize the cloud provider’s profit. The proposed model here is an extension of the clouds simulator for federated scenarios. Two algorithms are developed. The first one allocates the resources to VM while the second allocates VM in order to balance the load in federated cloud environment. Comi et al. [11] proposed an evolutionary approach in addressing the problem of resource management in federated cloud providers by means of an agent cloning mechanism. Intelligent and adaptive software agents’ features are made possible by the integration of learning techniques to multi agent systems. Learning software agents operate in order to enhance their performance. The learned knowledge and experience are used to help providers in taking decisions to manage their resources and some other agents with a better performance can reproduce the unsatisfactory agents. In paper [12] Manvi et al. suggested an agent-based resource allocation model (ARAM) for grid computing. Three types of agents are used: job agents (JAs), they are mobile and in charge of executing the jobs at suitable grid nodes. Brokering agents (BAs), they are static, incorporating an economic model and in charge of scheduling resources. Resource monitoring agents (RMAs), they are static, in charge of informing the local cluster servers about resource’s status. Comparing to traditional resource management techniques, ARAM aimed at flexible, intelligent, and adaptable services by using mobile agents.

In [13] Lee et al. a distributed resource allocation approach is proposed to solve resource competition in the federated cloud environment. This approach uses the pricing strategy to try to find the equilibrium implicitly. This approach decides which resource could be rented when the outsourcing occurs. The local provider will send an outsourcing request to another provider, which has, suitable resources with the minimal renting cost in case when the local cloud provider does not have available resources. If the outsourcing request is rejected, the local provider will try other providers with higher renting costs until the outsourcing request is accepted. In order to minimize communication overhead, the proposed approach groups tasks according to communication behavior, and tries to allocate grouped tasks to achieve equilibrium when resource competition occurs. Authors show that the cloud provider could obtain more profits by outsourcing resources in the federated cloud with enough resources. Federated-cloud-model in this paper [14] Ishikawa et al., means that two or more independent cloud service providers can be combined together to create one huge cloud environment. In the proposed approach, if a cloud service providers participating to the federated cloud does not have enough computing resources, it can satisfy its user’s demand by borrowing resources from other participated providers having enough capacity within the agreed price. In order to deal with dynamic changes of utility spaces during negotiation, authors presented an approach and a prototype system based on simultaneous negotiations among cloud providers and their users to form a federated cloud. The priority of negotiating opponents is decided by a simple method based on a difference of expected utility values obtained by each offer. Zulkar Nine et al. [15] propose as a multi-criteria decision making approach to select the best possible option to route the requests, it is a decentralized broker based approach that automatically decides about the incoming client requests and route to the most viable cloud member in the federation. The authors present a model that chooses the best destination for outsourcing demand without violating the service layer agreement. In [16] Petri et al. avoid migration to a single cloud environment thanks to the CometCloud system; authors facilitate the federation of several sites following the CometSpace concept thus creating a distributed cloud environment. Authors in this work provide hi level abstraction for supporting cloud federation and “cloud bridging”. Carlini et al. [17] present a contribution, optimizing inter-exchange of services among clouds. They proposed a self-adaptive approach based on the Markovchain model that allows a distributed exchange of services. Adaptation relies on global optimization through point-to-point exchanges between different pairs of clouds. In [18] Son et al. presented an autonomous multi-objectives SLA negotiation mechanism that includes an adaptive trade-off strategy by analyzing workload trends. This determines negotiation in accordance with cloud system’s status. Authors in [19] use abstractions and cloud-like capabilities to manage geographically distributed resources. Montes et al. presented a model to support the dynamic federation of resources and coordinate execution of application workflows on such federated environments.

As seen in [1–19] most of the works in clouds concern the study of fixed system models or architecture. There is no possibility to the federated clouds to acquire new providers with challenged price. In addition, services offered are fixed from the start and the federated clouds cannot provide a new kind of services while the open clouds federation is more faithful to business reality.

Few works like: Andronico et al. [20], Hou et al. [21] and De Meo et al. [22] take into account openness features in clouds federation. In [20] work authors include in the federation different cloud middleware, providing a concrete model that looks at heterogeneous cloud systems. In this work, the described model is able to consider all implications in accomplishing and managing dynamic cloud federations. The model targets small cloud operators allowing them to easily join and leave the federation. In [21] they present a self-management approach for the cloud services with an autonomous and context-aware management of the resources by employing a number of service agents in the cloud environment. Based on this approach, they present a cloud-oriented services self-management framework with suitable mechanisms for service aggregations and service provisions. Two supporting algorithms are designed to implement the proposed services self-organization process and the service provision process. Several types of agents are involved in the cloud services self-management such as a service manager agent, a manager center agent, and a service broker agent. Connection of computational nodes enlarges classical grid architecture. De Meo et al. [22] proposed a model supporting open grid federations based on a multi agent architecture, a distributed approach to improve the quality of service in dynamic grid federations where each grid composing the federation is able to accept or refuse node’s request for leaving or joining a virtual organization at any moment. Intelligent software agents reorganize the virtual organization according to two integrated parameters: (i) the nodes (past) behaviors, in terms of costs of the resources requested/offered and (ii) the trustworthiness of nodes, which is based on data automatically collected by software agents assisting grid nodes. In order to enhance the rate of requests satisfaction and reduce unallocated resources situations, the grid formation algorithm ensures a balance function between offer and demand of resources. Although approaches [21, 22] provided good results, they stay limited to a fixed number of criteria: in [21] the service manager considers an optimization and a balance method and in [22], reorganization depends on the result of the combination between trust and historical behaviors into a unified convenience measure. It stays insufficient for a large coverage of all the system’s sides such as: the quality of service “time response”, computing the load balance “workload parameter”, the geographical location or distance “network delay” between the costumer and provider…etc. However, the adaptive mechanism in AMACE takes into consideration optimization of no fixed number of various ranges and conflicting criteria and the list is not limited, it stays open and stretchable.

Cloud computing is a rising technology; it represents a business model in which enterprises can make enormous economies by reducing infrastructure investments. In cloud, users usually pay for the usage (i.e., CPU, storage, and network bandwidth, platforms, and application services) counted by the number of instance-hours incurred in a pay-as-you-go model. Cloud federation comprises services from different aggregated providers offering clients, in addition to sharing a wide range of resources, the opportunity to choose the best cloud services providers. Many basic features of cloud federation are identified: the best cost, service flexibility and availability to meet a particular business or technological need within their organization.

The dynamicity feature of the considered open federated clouds environment calls for adaptation strategies to allow for flexibility in our system. AMACE supports a flexible model, considering entrance of new cloud providers to the market, offering new services and departure of other cloud providers. The presented flexible model integrates interactions between BA’s organization. BA interactions permit migration requests among BA neighbors to delegate unsatisfied costumer requests. The implementation of the proposed flexible model is made possible by hybridization of two approaches.

Three types of agents are considered in Fig. 1: the consumer agent \( \left( {CA_{i} \;with \;i \in \left[ {1,n} \right]} \right) \), resource brokering agent \( \left( {BA_{k}\,with \;k \in \left[ {1,m} \right]} \right) \) and resource provider agent \( \left( {PA_{j}\,with\,j \in \left[ {1,h} \right]} \right) \). BA will assume the complicated resource allocation task between providers and users in clouds federation.

In AMACE, each broker has his own contact list of providers. This list can be more or less rich in comparison to other contacts list of neighbors belonging to the broker’s organization. The broker agent contains all information about cloud providers in his own contact’s list including the location, prices, lowest cost of the resources and the provider, which provides a high quality of service in his own contact’s list. The broker agent assigns a grade to the providers based on the feedback of the consumers to which it has done the allocations. All the time the broker agent will be checking the status of each of the cloud providers in his own list. The broker agent negotiates with provider agents and if a single provider does not fulfill the requirement of a consumer agent, it initiates a negotiation with another provider agent belonging to his contact’s list.

In case of BA cannot find the client request resource. And in spite of checking all his clouds provider contact’s list, BA is always unable to satisfy the client resource demand (i.e., resource still unavailable, price not suitable, a specific provider leaves the federation, entry of a new provider with a particular business or technological need which is not still well known by all brokers…). Such a situation in AMACE, leads BA organization to change the latter. The allocation resource method in AMACE minimizes user intervention and adapts itself. The adaptation mechanism is done by a delegating submitted customer request from one BA to another via multi criterion migration of a submitted customer request. This adaptive mechanism takes into account various parameters such as computing the load balance of mediator agents and the geographical distance “network delay” between the costumer and provider…). For this aim, we propose an algorithm to implement our self-organization mechanism. Migration in AMACE preserves continuously the organization’s coherence. Some preventive coherence constraints are verified before request’s migration and other corrective coherence constraints are verified after request’s migration.

BA self-organization

To achieve self-organization in BA organization, reorganization of the consumer’s requests allocation to BA is considered as an adaptive mechanism and to fulfill that, request’s migration between BA organizations is adopted as a technical means [16].

Since links between BA are known, a dominance relation based on multi criteria is used to resolve the conflict of choosing BA destination or direction between neighbors. The adaptive mechanism will be engaged in failure situation case, so the BA source delegates to the BA direction the task of satisfying his initial consumer. From this moment, the BA direction will communicate directly with CA concerned and try to satisfy his demand. If even the new BA direction cannot satisfy the delegated request, the adaptive mechanism will be engaged again and so on until time limit of the request execution. The customer cannot know that his request migrates from the initial broker to another; the adaptive mechanism is done in a transparency manner. The major advantage is the possibility to take into account no fixed number of various conflicting criteria in choosing the BA destination. Where a multi criteria functions evaluations \( \varvec{f}\left( \varvec{k} \right)\varvec{ } = \varvec{ }\left\{ {\varvec{f}1\left( \varvec{k} \right),\varvec{f}2\left( \varvec{k} \right)\varvec{ } \ldots \varvec{ fn}\left( \varvec{k} \right)} \right\} \) require optimization of no limited number of parameters (which can be incompatible) in solving the conflict of choosing the BA direction (i.e., \( \varvec{f}1\left( \varvec{k} \right) \): the BA workload parameter between the BA source and his neighbor \( \varvec{k} \), \( \varvec{f}2\left( \varvec{k} \right) \): the BA rate transfer time between the BA source and his neighbor \( \varvec{k} \)…etc.).

Case of failure situation

Figure 1 shows a case of a failure situation where the adaptive mechanism must be engaged. To start executing his task, User 4 needs to acquire a specific resource provided by a specific provider (for example: a spare part provider of a specific motors company, a specific software provider…etc.). This provider exists in our cloud federation but User 4 makes his request to Broker “C”. The problem is that Broker “C” cannot provide this specific resource to User 4 because he has no contact with the specific provider who can allocate the needed resource. In such case, the Broker organization must be capable of self-reorganizing and adapting its behavior to solve the failure situation. Therefore, the self-organization mechanism is automatically started by Broker “C” and starts the multi criterion process of choosing the neighbor destination. After that, the specific resource request migrates from Broker “C” to Broker “A” who is in a position to satisfy directly the specific resource request of User 4.

Figure 2 illustrates the general case of the failure situation where many broker agents interact among them. It shows the migration of a resource request from a broker source to a non-dominate broker “F”.

After the choice of BA, the direction is done and before the authorization for migration of non-satisfied customer requests, some preventive constraints are checked to preserve a coherent BA organization. After the migration, other corrective constraints for a coherent reestablishment must be checked which ensures to have, at any moment, a coherent system evolution. Examples of preventive constraints are the avoidance of the migration of a non-satisfied costumer request to an BA direction with an empty provider contact’s list and if it is known from the beginning that this BA has no cloud provider in his liable list to satisfy the migrated user’s request. As a corrective constraint, after the migration of a non-satisfied customer’s request, the workload parameter must be updated for both the BA source and direction. Algorithm 2: BA communication takes in charge self-adaptation in AMACE, which is an online adaptive mechanism.

Negotiation protocol

In Fig. 1 three protocols are used for negotiation

• Between CA: consumer agents, BA: brokering agents and PA: provider agents,

• In addition, between brokering agents organization members.

Algorithms 1, 2 and 3 are proposed to deal with a dynamic open federated clouds environment. Algorithm 2 permits provider’s movement (departure and entrance), permitting inter BA organization communications and integrating an adaptive behavior in case of failure situation, where the BA is incapable to satisfy a user’s request. Notice that there is another Algorithm 4 for resource allocations.

• Algorithm 1 is the protocol used for negotiation of

  • CA _iє[1,…]: Consumer agents with: BA _jє[1,…] brokering agents,

  • CA _iє[1,…]: Consumer agents with: PA _kє[1,…] provider agents.

Algorithm 1 description

Line 1–4: Consumer agent initializes the consumer request message including his identification then Sends its message to BA with CA_identification. CA waits to receive a cost proposition from BA.

Line 5–11: If the cost proposition is acceptable, CA sends Acceptance answer to BA then waits to receive proposition confirmation from BA. If the cost is higher than expected cost, CA sends reject answer due to cost limit then checks if it is not time limit (TL) of the request execution and if \( \varvec{Rreq} \) is not empty, so CA waits to receive new cost proposition from BA.

Line 12–24: If the cost proposition is acceptable, CA sends agreement acceptance to BA and waits to receive agreement confirmation from PA. If the agreement is not acceptable, CA sends agreement reject to BA and checks if it is not time limit (TL) of the request execution and if \( \varvec{Rreq} \) is not empty, so CA waits to receive new cost proposition from BA.

When CA finishes sending agreement confirmation to PA, CA checks if it is not time limit (TL) of the request execution and if \( \varvec{Rreq} \) is not empty, so CA waits to receive new cost proposition from BA.

Line 25–29: When reaching the final agreement, the consumer agent begins the execution. After completion of the task, CA calculates the utility of the resources and sends it as feedback information to BA.

• Algorithm 2 is the protocol used for the negotiation of

  • BA _jє[1,…] brokering agents with: CA _iє[1,…] consumer agents,

  • BA _jє[1,…] brokering agents with: PA _kє[1,…] provider agents,

  • BA _jє[1,…] brokering agents with: other BA _jє[1,…] brokering agents neighbors of BA organization.

Algorithm 2 description

Line 2–5: BA waits to receive a consumer request message. BA extracts the resources from the consumer request then updates his current provider list of contacts (to take in account a probably new entrance or departure of providers). BA initializes a temporary provider contact’s list with his current provider contact’s list.

Line 6–8: BA checks if it is not time limit (TL) of the request execution and if both the temporary contact’s list and \( \varvec{Rreq} \) are not empty.

Line 8–10: BA searches each resource in his own temporary provider contact’s list based on, maximum QoS and minimum unit cost to select the best provider.

After BA gets the resource list, it calculates the total cost of resource set \( \varvec{Rreq} \) then sends to consumer agent cost proposition and waits to receive an answer from CA.

Line 11–12: If BA receives the acceptance answer from CA, BA initializes a consumer request message and sends it to provider agent.

Line 13–16: If BA receives a reject answer from CA, BA removes the best-selected provider from his temporary provider contact’s list and go back to line 6–8.

Line 17–37: In case where it is not time limit (TL) of the request execution and if \( \varvec{Rreq} \) is not empty but BA temporary provider contact’s list is empty the adaptation mechanism is engaged automatically by executing BA self organization segment part and a feedback about the failure situation is generated to update BA provider contact’s list.

Line 38: BA waits to receive response from PA.

Line 39–40: If BA receives acceptance answer from PA then sends proposition confirmation to CA then waits to receive agreement answer from CA.

Line 41–46: If BA receives reject answer from PA, BA sends proposition not confirmed to CA, updates both temporary and current provider contact’s list with this demand price, remove best provider from temporary provider contact’s list and go back to line 6–8.

In case where is not time limit (TL) of the request execution and if \( \varvec{Rreq} \) is not empty but BA temporary provider contact’s list is empty the adaptation mechanism is engaged automatically by executing BA self organization segment part and a feedback about the failure situation is generated to update BA provider contact’s list.

Line 47–50: BA waits to receive agreement answer from CA. If it is agreement acceptance, BA sends the agreement confirmation to PA, update \( \varvec{Rreq} \) (set of resources requested).

BA check if it is not time limit (TL) of the request execution and if both the temporary contact’s list and \( \varvec{Rreq} \) are not empty BA try to select another best provider from the temporary contact’s list. In case where it is not time limit (TL) of the request execution and \( \varvec{Rreq} \) is not empty but BA temporary provider contact’s list is empty go back to line 17–37.

Line 51–55: If agreement reject, BA sends agreement reject to PA, remove the best selected provider from his temporary provider contact’s list, checks both if is not time limit (TL) of the request execution and if the temporary contact’s list is not empty, so BA repeats the protocol from the start to select another best provider from the temporary contact’s list. In case where it is not time limit (TL) of the request execution but BA temporary provider contact’s list is empty go back to line 17–37.

Line 56–58: BA updates his own provider contact’s list based on the received CA feedback information.

• Algorithm 3 is the protocol used for the negotiation of

  • PA _kє[1,…] provider agents with: BA _jє[1,…] brokering agents,

  • PA _kє[1,…] provider agents with: CA _iє[1,…] consumer agents.

Algorithm 3 description

Line 2: PA waits to receive consumer request message from BA.

Line 3–5: If all resources are available for assignment, PA sends acceptance answer to BA.

Line 6–8: If one of resources is not available, PA sends reject answer BA. PA goes back to line 2 and repeats the protocol from the start waiting to receive new consumer request from BA.

Line 9: PA waits to receive agreement answer from BA.

Line 10–14: When PA get the agreement acceptance from BA, it sends the agreement confirmation to CA, waits to receive agreement confirmation from CA then PA goes back to line 2 and repeats the protocol from the start waiting receive a consumer request message from BA.

Figure 3 illustrates algorithm’s interaction and communication protocol between algorithms: CA, BA and PA, the flowchart is helpfull for a clearer reading and best analysis.

Data flow diagram

Figure 4 illustrates the communication protocol between algorithms: CA, BA and PA. Before beginning every search, we first make an updating action to the provider’s contacts list. CA request migration action to a new BA direction is done in case of a failure situation (provider_list is empty). This situation leads to execute BA self-organization mechanism and a feedback report about failure reasons is sent to providers. The migration process will be repeated again until satisfaction. The self-organization mechanism in AMACE is executed discreetly. Customers do not feel that their requests are migrating from one broker to another and there is no need to know who performed their request.

The most critical difficulties faced during development process of adaptive multi agent system, is definition of the triggering event or the moment when the adaptive mechanism must be engaged. There are two kind of adaptive system: reactive system, guided by the events on the system or its environment such as new arrival agent or outgoing one. Proactive system, aware about the state of the system, and if it is necessary make decision to adapt it.

The adaptation process responds to a logic following which it decides, if a system requires adaptation. This logic can be predefined when designing the adaptation mechanism or an adaptable logic that can change. This logic may be maximizing a utility function, maximize the utility function while minimizing the cost of the reorganization process.

Two types of adaptation implementation are defined; the implementation is called centralized if an agent is able to decide on its own whether an adaptation is necessary, on the other hand, it is said distributed if it is the whole of the agents who must decide if an adaptation is yes or not necessary. Emergent behavior is behavior of a system that does not depend on its individual parts, but on their relationships to one another.

There are features that are not related to the adaptation mechanism, but rather link to the system that can be an open system: where an agent can leave the system or a new agent can also join the system. Open clouds federation is more faithful to reality; some limits results from the non-flexibility of the clouds federation. In closed federated cloud, there is no possibility to offer new services in the future, if the service is unavailable from the start so it will stay unavailable. There is no evolution of the federation; no new providers can be acquired to satisfy new client’s requests. In addition of the risk to be in a vendor lock-in situation, in case where unfortunately in our cloud federation there is a unique provider offering a specific service. Not only there is no possibility of price challenge but also the worst thing is in case if this provider decides to stop definitely providing services or decide to leave federation, the whole federation will be enabling to satisfy this specific service.

To maintain the consistency or coherence of a system, preventative constraints must be verified before the adaptation mechanism. In addition, other corrective re-establishment constraints should be checked after adaptation.

Actually, business is a very dynamic environment. It is considered in this paper an open clouds federation environment that is in constant evolution. AMACE supports a flexible model integrating interactions between BA organization, new cloud providers can enter the market and offer their new services while other cloud providers can leave it. BA’s interaction permits request’s migration between BA neighbors to delegate unsatisfied costumer requests. An adaptive approach is proposed to support the presented flexible model.

AMACE makes adaptation and hybridization of two approaches to deal with dynamic federated cloud computing. The adaptive mechanism is inspired from an organization’s optimization approach for self-organization in broker agent organization [16] and negotiation protocol communication from Multi agent resource allocation approach on federated clouds [1]. AMACE is auto adaptive and multi criterion, which can take in account various parameters (i.e. computing the load balance of mediator agents and the geographical distance “network delay” between the costumer and provider…).

Looking in the future to implement the whole system with the negotiation protocol communication to get empirical results and demonstrate AMACE effectiveness in addition to trying to provide new features in open federated clouds accomplishment.