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.
Open federated cloud
It is noticed in the flexible system model (Fig. 1) interactions among BA organization members (inter organization communications). The request’s migration mechanism and BA organization interactions features used together in AMACE permit to implement open federated clouds.
Entrance of a new cloud provider
We assume that the integration of a new provider freshly arrived at the federation, implies the creation of contacts with at least one BA from the BA organization. This link with only one BA will be enough for the new coming provider to be reached by all the BA organization. Thanks to BA interactions and request’s migration, all consumers will take benefits from this new provider services. For example, in Fig. 1 User 1 demands a request from Broker “A”, this request needs a compute resource (as seen in the cloud federation it is provided exclusively by a new coming compute cloud provider) but Broker “A” have no contact with the new coming compute cloud provider. Interactions between the BA organizations will permit Broker “A” to delegate User’s 1 compute resource request to neighbors of Broker “A” and so on until the delegated request will reach the suitable Broker in contact with the new coming compute cloud provider to allocate this compute resource to User 1. In this case, it is Broker “C” who is in position to satisfy User’s 1 compute resource request.
Departure of a cloud provider
In case when a provider will leave the federation before running the task, the PA will send back to BA the resources request that PA planned to provide to consumers. Two situations are possible:
-
a.
If other providers belonging to the BA provider contact’s list could provide resources requests sent back, the BA would review again all his providers’ contacts list to fulfill resources requests sent back.
-
b.
But if the cloud provider who leaves the federation was a specific and exclusive one in the BA providers’ contacts list, the adaptive mechanism would delegate this requested resources to BA neighbors to be fulfilled and so on (the case in Fig. 1 when the compute cloud leaves the federation).
Problem modeling
The consumer agent has the following attributes:
-
\( \varvec{CA}\_\varvec{id} \): Consumer agent identification.
-
\( \varvec{Rreq} \): Set of resources requested by the consumer. For each \(r \in Rreq \), \( q\left( r \right) \) is the quantity of resource r.
-
\( \varvec{Td} \): Time duration of resource usage.
-
\( \varvec{Tl} \): Time limit of the request execution, it indicated the latest time by which the request must be started. The request execution must finish before \( \left( {Tl + Td} \right) \), or must be started before \( Tl \).
The brokering agent has a Provider_list that contains the information about each resource, its cost and its quality of service. The brokering agent periodically updates the Provider_list. Cost of a resource \( r \in Rreq \) is \( Cost\left( r \right). \) The total cost of \( Rreq \) at PA is:
$$ C\left( {Rreq} \right) = Td \times \sum\nolimits_{r \in Rreq} {Cost\left( r \right)} $$
(1)
The utility of a consumer agent depends on the resource quality and its payment. It is calculated by dividing the quantity of resources by the cost of resources.
$$ U\left( {Rreq} \right) = \frac{{q\left( {Rreq} \right)}}{{c\left( {Rreq} \right)}},\quad {\text{while}}\;{\text{q}}\left( {\text{Rreq}} \right) = \sum\nolimits_{r \in Rreq} {q\left( r \right)} $$
(2)
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 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 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 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.