MOSIX

Description

The MOSIX (http://www.mosix.org) market consists of three components respectively parties:

• resource requesters who would like to submit a job to MOSIX,
• resource providers who provide clusters and nodes to MOSIX, and
• market allocates jobs to resources and vice versa.

Both the resource requesters (the buyers) and the resource providers respectively clusters (the sellers) connect to a central component when using MOSIX. This central component consists of middleware extensions which connect MOSIX to the market component (MOSIX market). This component consists of stable interfaces which allow pluggable market mechanisms. The economic logic is encapsulated behind these stable interfaces and transparent for the MOSIX system. Consequently, the market mechanism can be exchanged and tested without needing to modify MOSIX as such.

Participants

Resource providers

The resource providers are offering clusters of nodes with processing power (CPU) and memory to MOSIX for the solution of computational problems (jobs), either their own jobs or jobs by third parties. Each cluster consists of either heterogeneous nodes that differ regarding CPU and memory (one node with 3 GHz and 5 GB, one node with 2 GHz and 4 GB, etc.) or homogenous nodes, that is all nodes within one cluster have the same configuration. Resource providers may require a minimum payment (reservation price) in order to be willing to provide their resources to third parties. For example, a resource provider may require a minimum payment of $10 for 2 GHz CPU and 4 GB memory. Based on offers by the resource providers and the resource requesters, the market mechanism determines an actual payment which may be higher than but at least equal to the specified reservation price. In a simple scenario, all clusters might require one common reservation price, which is for simplicity assumed to be 0. Consequently we have virtually one resource provider – MOSIX – and multiple (n) buyers  1:n-relationship. In more complex scenarios, each cluster might require a different reservation price. For example, cluster C1 might claim $20 for 2 GHz CPU and 4 GB memory, cluster C2 might claim $15 for 2 GHz CPU and 4 GB memory, and cluster C3 might claim $10 for 2 GHz CPU and 4 GB memory. In this case, we have multiple (m) sellers and multiple (n) buyers and a m:n-relationship. Resource providers might be able to specify time constraints if they only want to provide resources within a certain timeframe. For example, provider (cluster) C1 might decide to offer its resources during night time from 10 pm to 7 am the following day when its cluster is idle. Consequently, resource providers submit offers to the market respectively MOSIX – so called “bids” – by specifying

• The amount of CPU they are willing to provide;
• The amount of memory they are willing to provide;
• The reservation price (minimum payment) they demand in exchange for these resources;
• Possibly the time beginning from which they are able to provide these resources;
• Possibly the time until which they are able to provide these resources.

For example, the owner of cluster C1 might offer 2 GHz CPU and 4 GB memory for at least $20 from 10 pm to 7 am.

Resource requesters

The resource requesters have a job to be computed, generally computationally large-scale, by using MOSIX. Each job requires a certain amount of both CPU and memory , e.g. 2 GHz and 4 GB. In return for the execution of the job, the resource requesters are willing to pay a maximum amount of money corresponding to the value they associate with the results of the job. For example, the requester may be willing to pay up to $30 for the execution of a job which requires 2 GHz and 4 GB. Analogically to the resource providers, the market mechanism determines an actual payment which may be lower than but at most equal to the specified amount of money. In more complex settings, the resource requesters may specify time constraints for a job. Firstly, this may be a timeframe consisting of a starting time and a deadline until which the job has to be finished at the latest. Minimum starting time might relaxed by taking current time by default. Maximum end time might be relaxed by taking a predefined timeframe such as one day or one week by default. Additionally, as in the MACE service, users might specify the length of the actual timeslot which they want to obtain within this window. For example, a user might request 2 GHz and 4 GB for three hours between 10 pm and 7 am. However, except in specific domains and cases, users will not be able to exactly specify the runtime of their job. Consequently, resource requesters submit bids to the market respectively MOSIX specifying

• The amount of CPU they need for the computation of their job; The required amount of memory;
• The maximum price they are willing to pay for these resources;
• Possibly the time beginning from which the job may start;
• Possibly the time until which the job needs to be finished (deadline);
• Possibly the time runtime of the job, i.e. the width of the timeslot they want to obtain within the specified window.

For example, user B1 might request 2 GHz CPU and 4 GB memory for up to $20 and three hours between 10 pm to 7 am. Time constraints might furthermore imply compensation issues for jobs which have been accepted but which are not finished in time. This also depends on the nature of the job. If the requester needs to obtain the results of the job within the specified timeframe to get any value, the user might be compensated with the full payment and possibly an additional sanction. For example, if the requester and the provider of the resource agreed on $10 for the execution of the job, the requester may receive the $10 and an additional $10 as sanction. If the requester can still use the result of the current status of the job after the specified deadline, possibly with a lower associated value, the user might be compensated with a fraction of the full payment proportional to the status of the job. For instance, if the job is only executed to 50%, the requester might receive $5 of the $10 on which he and the provider agreed and the job is finished as soon as possible. The market mechanism determines the allocation of jobs to resources. This allocation might take place continuously – when a job is finished, new request is submitted to MOSIX, or new resources are added to MOSIX – or periodically, e.g. every x seconds or minutes. A job which is not allocated right now might either be rejected or remain in the market in case this does not violate possible time constraints, i.e. the job might be started later and still be able to finish within the specified timeframe. The allocation of jobs to resources might either be static or dynamic. In the static case, a job utilizes the resources it is assigned to at the beginning until it is finished or hibernated. In the dynamic case, the job might get reallocated to other resources according to the situation in the marketplace, for example if a cheaper cluster (node) is released. Additionally, resource requesters may have budget constraints, i.e. a maximum amount of money available for the execution of jobs and the payment of the associated costs/prices. Each MOSIX user might thus possess a “prepaid” account in the MOSIX system from which the execution of jobs is paid and which can be “recharged” in case new funding is available. If the execution of a job and the associated payment would exceed the limit set by the account, the job might be rejected if it is a new job, killed if already in process, or hibernated until the account is recharged.

Use cases

Basic scenario

This is a simple scenario with a set of different clusters, e.g. three as in figure 1, where each cluster consists of homogenous nodes. For example, cluster C1 consists of three nodes with 1 GHz and 1 GB each, cluster C2 consists of four nodes with 2 GHz and 2GB each, and cluster C3 consists of five nodes with 3 GHz and 3 GB each. The requests consist of three attributes A1 to A3 as indicated in figure 1, the required resources and a maximum amount of money the user is willing to pay for these resources. The offers of the resource providers consist of two attributes, the CPU and memory the owner is willing to provide. The resource providers such as academic departments within one university offer their resources for free and have no reservation price. Consequently we have a 1:n relationship between MOSIX as the virtual seller or resource provider and the n resource requesters or buyers. Neither resource requesters nor resource providers do have any time constraint, that is requesters submit jobs to MOSIX that can be executed at any time in the future and providers in turn offer their resources 24x7. Consequently, there are no compensation payments since no deadline can be violated. Resource requesters do not have any budgetary limitations. We assume they can pay the maximum price they indicated in their request for all submitted requests. The allocation of jobs to clusters takes place periodically, e.g. every two minutes. Requests which are not accepted by the market because the requester’s willingness to pay is too low are rejected and do not stay in the system. Other requesters are willing to pay more for the same resources. The allocation of jobs to resources (clusters) is static. Once a job is assigned to a certain cluster, it does not migrate to another cluster but stays there until it is finished. The resulting parameter values are:

• Heterogeneous clusters
• Homogenous nodes within each cluster
• Resource providers do not have reservation prices No time constraints, neither on the supply side nor on the demand side
• No budget constraints
• No compensation
• Periodic execution of the allocation Rejection of unallocated jobs Static allocation, i.e. no reallocation of assigned jobs

Complex scenario

A derived complex scenario is characterized by the following parameter values:

• Heterogeneous clusters
• Homogenous nodes within each cluster
• Resource providers do have reservation prices
• Timeframe (min starting time and max end time) on both the supply and the demand side, no computing time.
• Budget constraints with compensation
• Periodic execution of the allocation
• Rejection of unallocated jobs
• Dynamic allocation, i.e. reallocation of assigned jobs with respect to situation in the market

News