The framework consists of a number of entities that use tender model. The entities are classified into resources, brokers and users. A resource sends bids and receives jobs, a broker sends jobs and bids and receives jobs and bids and a user sends jobs and receives bids. Figure 3.1 shows the negotiations that take place between the entities, while Table 3.1 shows the parameters which are sent through the nego-tiations that occur between them. For each negotiation, the job parameters such as job characteristics and requirements are sent from the user to brokers. Then,
each of these brokers can either negotiate with the user or negotiate a group of resources. After the broker sends offers to resources, the interested resources send their bids to this broker. Next, the brokers keep negotiating with the resources or with the user who in turn accepts one of the sent bids from brokers or keeps negotiating.
The job parameters are:
• User number: The job owner’s number.
• Job ID: The job’s number.
• Sender number: The number of the entity that submitted the job parameters for the job whose number is Job ID.
• Receiver number: The number of the entity that receives the job parameters.
• Negotiation number: This shows the negotiation’s number for the submitted job. A negotiation is a direct communication between two entities (e.g.
communication between a user and a broker).
• Price, job length, deadline and job class that are described in section 3.2.2.
On the other hand, the bid parameters are:
• User number: The job owner’s number.
• Job ID: The job’s number.
• Sender number is the number of the entity that submitted the parameters.
• Receiver number is the number of the entity that receives the bid parameters for the job whose number is Job ID.
• Negotiation number: It shows for what negotiation’s number this reply (bid) is for.
• Price: The revenue that is asked for executing the job.
• Expected completion time: The date by which the job is expected to com-plete.
• Expiry date: The date when the bid will expire.
Grid accounting is not in the scope of this project. Grid accounting is considered in [10, 30].
Figure 3.1: Interaction between users, brokers and resources.
Table 3.1: Negotiation parameters.
The resources represent the working power of the grid, and they are where the jobs are executed. Each resource comprises a number of processors that have speeds
measured in MIPS (Million Instructions Per Second). MIPS is used because no better metric was found. In the future, a more appropriate metric to measure the speed of processors is going to be used. In this work, all the resources (processors) use space shared scheduling policy, i.e. a processor can execute only one job at a time.
In the proposed framework, the resource is shown as an entity that sends bids and receives jobs as appears in figure 3.2. The resource receives jobs (requests) from brokers. After processing the requests, it sends bids based on the cost of taking on the jobs and the availability of its processors.
This framework supports the situation where resource prices fluctuate based on the demand and supply. Thus, when the demand becomes higher, the resource becomes more expensive and the chance of the broker request to be accepted be-comes smaller. Otherwise, the resource bebe-comes cheaper and the chance bebe-comes greater. On the other hand, when the supply (free processors) is higher, the re-source price decreases and the possibility of the rere-source to accept a job request becomes higher. Contrarily, the price increases and the possibility becomes lower, if the supply is lower. Different models can be implemented to determine how the resource price is varied and how the demand is measured.
Two kinds of costs are paid by resources: Cost per million instructions (MI) and cost per time unit. Cost per MI is only paid when a resource is executing a job, because this results in consuming more power in addition to other expenses relate to the job executing. On the other hand, cost per time unit is paid all the time whether the resource is idle or busy and results from the expenses arisen from maintaining the resource (e.g. security, software).
Entity Jobs
Bids
Figure 3.2: Resource.
3.2.2 Users
The users have jobs that need to be executed on the resources reside on the Grid.
Each job has a price (currency), length (MI), deadline (date) and a class. Price is the amount of money that will be paid for executing the job. The price that is submitted to the brokers might be increased during the negotiations with the brokers until the job owner and a broker agree on a price for executing the job.
The length indicates the number of instructions the job is expected to take. The model of a job in use is such that the job is progressed through a fixed number of instructions and then saved. So, if the job took more instructions than is determined in the request, the resource executes the number of instructions the user (job owner) paid for and returns the results to the user. Then, the user can ask for executing the rest of instructions in a new job request. The deadline is the date by which the job must be completed. The class is a descriptive category of a job that is based on the computer resources it requires when running.
For every job, there is the submission time which is the time when the negoti-ation starts for the job (the job is submitted to a group of brokers). If a resource accepts to execute the job, the job is allocated (submitted) to the resource at time called the allocation time. Then, the job is assigned to one of the available processors belong to the resource at time called the start time. Finally, the job finishes its execution and the results are returned to the job owner at time called finish time.
The user in this framework is an entity that sends job parameters and receives bid parameters as appears in figure 3.3. The user sends jobs to brokers, so they can find suitable resources for executing the user’s jobs. On the other hand, the brokers send their bids to the user after contacting the resources, so the user can select one the bids or keeps negotiating with brokers.
Every user maintains historical performance for brokers which is used in se-lecting the brokers the user wants to contact. So in the next negotiations, the users just send requests to brokers with good historical performance to reduce the number of negotiations that happen between them and brokers. The historical
performance is updated based on the responses from various brokers. Further-more, every user sends requests to the brokers with poor historical performance after a while to see if their performances (e.g. their responses to its requests) improve.
Entity
Bids Jobs
Figure 3.3: User.
3.2.3 Brokers
The broker aims to find suitable resources for executing the jobs owned by users that the broker acts on behalf of them. The existence of brokers is important for users because they have knowledge about resources reside in the Grid. The brokers employ various strategies and aim to maximise their own profit. Different to users and resources, brokers interact with two classes of entities that are users and resources, while users only interact with brokers and resources only interact with brokers.
In this framework, the broker is represented as an entity that sends job and bid parameters and receives job and bid parameters as shown in figure 3.4. It sends bid and job parameters to users and resources, respectively, and receives bid and job parameters from resources and users, respectively. Each broker just sends one bid to user at a time.
Similar to users, brokers sustain historical performance, but for resources. The brokers employ historical performance to reduce the number of communications that occur between them and resources. As a result, the brokers only contact a group of resources.
As resources, brokers pay two kinds of costs: cost per MI and cost per time unit. However, the costs paid by brokers are usually less than the costs paid by resources. This is due to the fact that resources have processors that need to be
maintained.
Entity
Jobs Jobs
Bids Bids
Figure 3.4: Broker.