The optimization component offers a service to the Grid users aiming at optimizing the scheduling of the jobs in the environment. In particular, the Optim provides a service that can be used by the Scheduler to improve quality of resource allocation. The component receives from the scheduler one or more jobs to be scheduled and it returns, for each job, an ordered list of available computing resources of the grid on which the job can be carried out respecting SLA’s constraints.

The Optimisation pattern is composed of two main components: the Optim and the GridOptimizer Components. On the basis of the Publish/Subscribe patterns, the Optim component receives from the scheduler the job to carry out (each job is related both with a RES -resource file- and the SLA that contain information about the inherent constraints like resources and time slots).

The Optim component receives both from the GRID and the Monitoring components information about the status of the system.

In particular, by using the Adapt Pattern the Optim Component obtains information about the whole grid resources from the the Grid Component; while the Monitoring Component gives information about the already existing schedule and therefore about the effective availability of each resource in the grid.

All this information is processed to evaluate which optimizing algorithm is more suitable and efficient to solve the scheduling problem. Once the problem is solved by the GridOptimizer component, the output is notified to the scheduler.

Read More

The SLA Accounting component is responsible for computing the charges to be made to each consumer’s account according to a record of their usage for a specific service provider’s resources or services. The usage information should be provided by the Runtime Monitoring component. Moreover, the SLA Accounting Component may impose additional charges or discount to a user account as a penalty when notified by the Runtime Monitoring component of a violation from the customer’s or the Service Provider’s side respectively.

The SLA Accounting component must be able to receive and treat the notifications sent by the SLA Evaluation component. To this end, it should present a Web Service capable of receiving WS-Notifications. Such a Design Pattern is presented in Design Pattern for a GT4 Service receiving WS-notifications whitepaper.

Within a grid framework, once an SLA contract is agreed and contains monetary information describing usage (and possibly penalty) fees, there arises a need to justify the bill produced by the provider. On the basis of the SLA Accounting design pattern, the Accounting component receives usage information from the SLA Monitoring component. The usage information consists of aggregated measurements of the usage of the various resources created by combining monitoring data provided by the resources or the services. The SLA Accounting also receives a notification each time an SLA violation occurs and imposes penalties or discounts to the customer’s account based on the nature of the SLA-Violation and the agreed-upon penalty terms. The SLA Accounting Pattern enhances grid functionality by enabling the resource and service provider to charge consumers for usage of his services based on a predefined agreement between the two (SLA). It is a step towards making a grid application more commercial and business oriented.

Read More

The Negotiation Common Capability relates to the procedure of parties (consumer and providers) agreeing on the terms of an SLA governing the exchange of resources. The parties try to reach a deal based on a consensus after exchanging (possibly several) non-binding probes called quotes hereafter.

One important part is that in any such type of trade agreement, the provider never publishes offers. Instead, the provider waits for the client to send a pre-signed agreement. The provider expects the client’s agreement to be based on a previous template. The client can reasonably know what the provider is ready to offer based on quotes that the provider has issued previously on demand. The steps are the following:

  1. The provider publishes a template describing the service and its possible terms, including the QoS and possible compensations in case of violation. This template leaves several fields blank or modifiable, which are meant to hold the user specific needs.
  2. The client fetches the template, and fills it in with values which describe the planned resource usage. Some terms of the template may be removed or added or changed, but may lead to a rejection in step 5. This new document, which engages neither party, called a quote request, is sent to the provider.
  3. Sending the quote request is equivalent to asking the provider to give a provisional answer, saying whether the deal could be accepted. Receiving this, the provider, based on the current resource availability and customer policies, sends back to the client a quote. This quote corresponds to values on which the provider would probably agree (but this is by no means binding), based on the client’s needs expressed in the quote request.
  4. The client, if satisfied with the quote, applies his/her signature to the document, and sends it back to the provider as a proposal. This proposal corresponds to an agreement that the user is ready to comply with. Effectively, the client is already proposing an SLA to the provider, but the provider’s signature is missing.
  5. The provider, receiving the proposal, is free to reject or accept it. In the latter case, the proposal becomes an SLA officially signed by both parties, and starts to be a valid legal document.

Requesting the template is only done once for every type of service the provider offers. The quotes exchange (steps 2 and 3) can be repeated any number of times. The user can tune the terms in the quote request until the provider’s quote is in line with what the client is ready to accept. The last step for the client, step 4, requesting the real SLA, has a Boolean answer: the SLA is either accepted or rejected by the provider. In the latter case, the user can go back to asking for a quote, as the provider might have changed his conditions. This procedure allows the provider to have the final decision in accepting or not the contract (this is crucial to avoid pre-reserving resources which may not be attributed if the client disengages).

The steps 2-3 are the core part of the negotiation, as each party can pull the deal in any direction. The parties may freely modify the different terms: lower fees, lower QoS, longer time slots, fewer resource needs, lower compensations, etc.

Once a contract has been signed and agreed, the necessity of changing it could be envisaged (see re-negotiation). In that case, the same quote framework could be used. The main difference comes from the already allocated resources, and the existence of a first contract to modify. Technical difficulties appear on the provider side in this case, but the framework presented to the parties to sign a new contract stays basically the same. The getTemplate() first call would contain as parameter the previous contract, to signify that it should be renegotiated. The procedure then stays the same as presented above.

On the technical side, there are existing protocols and pre-standards existing. For example, the format of the SLA templates, quotes, and proposals described in this framework could be based on the WS-Agreement XML schemas.

Read More