Zero-Sum Cluster BarteringThe Zero-Sum method is a credit based trading scheme. Users trade barter units for computation time on remote clusters. Every user is a member of a cluster group. The cluster group is associated with one or more clusters. However, clusters are only associated with one cluster group. These associations are built in the Central Server's database and are important for regulating cluster bartering. Similar to the allocation method, each user and cluster group has an account running balance and balance. However, a lower-limit and percentage-of-shared value are additional fields that regulate the distribution and use of Barter Units in a trade scheme. The lower limit value is the lowest number of Barter Units that a user or cluster can equal. Lower limit is usually set to a negative number to facilitate trade. This value represents the margin that facilitates trade or credit that the user must pay back at some time. Without negative lower limits, no user would be able to run on cluster outside the user's cluster group. The percentage-of-shared value is used to redistribute barter units to a remote cluster that successfully completed a job.   Job SubmissionAvailable Barter Units = (User_Balance - User_Lower_Limit) + (Cluster_Balance - Cluster_Lower_Limit)Zero-Sum Cluster Bartering supports a hierarchical structure of users that belong to groups. Users and groups can be assigned Barter Units. Users that belong to the same group can share Barter Units. When consuming barter units after a job is accepted, the Central Server first consumes the user’s barter units, and then the shared barter units. This provides three methods of consuming barter units for users in a cluster group for job submission.
When a user submits a job, the cluster manager that accepts the job connects to the central server to ensure that the user has enough available Barter Units to run the job. If the available Barter Units is not higher then or equal to the job price, the user does not have sufficient barter units, and the job will not be submitted; otherwise, the cluster will request an update of the users available running-balance. The central server will first deduct Barter Units from the user’s running balance. If the user does not have enough Barter Units to cover the bid price, the remaining Barter Units are consumed from the user’s associated cluster group. In this case, Barter Units are deducted from the cluster group's running balance. Once the job completes, a similar process to the one described above occurs with the user's balance value. Barter Units are deducted from the user's account and then from the user's cluster group. The central server then updates the account of the cluster group that ran the job. If a job did not run successfully, the Central Server does not deduct the bid price from the user's balance. Instead it adds the bid price back to the user's running-balance. Earning Barter UnitsThe percentage-of-shared value is used to redistribute Barter Units to the cluster group that successfully ran a submitted job. First, the cluster group's running-balance and balance are increased by the cluster account percentage multiplied by the job price. The remaining Barter Units are distributed to the cluster group's users by the user's percentage values. It is important to ensure that the user's percentage-of-shared values total 100 percent. This provides three methods of allocating barter units to users in a cluster group.
The cluster group's percentage-of-shared value should be sent to 100%. The cluster group's percentage-of-shared should be sent to 0%. Users must be given percentage values that total to 100%. The cluster group's percentage-of-shared value should be set between 0 and 100 percent. Users must be given percentage values that total to 100%. Benefits of Zero-Sum Cluster BarteringZero-Sum bartering holds many advantages over allocation based schemes. Zero-Sum bartering provides for different allocation methods, redistribution of purchasing power, lower administration overhead, a credit based economy, and control over delinquent members.
The different allocation and redistribution methods are very useful and natural for Faucets target users - laboratory groups in academia. Often groups want the flexibility to share computation time, but ensure that they have a minimum amount of personal time. Zero-Sum provides this, along with completely shared and completely independent methods. Lowering administration overhead is an important factor in Faucets. All users and groups will be given zero barter units when given an account in Faucets. System administration only has to set the amount of credit (lower-limit) and the redistribution amount (percentage-of-shared) for new users and cluster groups. They don't have to make long term guesses at the number of Barter Units any group will need or guess at the computational power a Barter Unit might purchase. Furthermore, accounting is simple with Zero-Sum bartering. At any time, summing the balances of all users and groups should add to zero Barter Units. This provides a simple check on the accuracy of the system. A credit based economy encourages trade much more then an allocation method. In allocation methods, users can often submit many jobs regardless of how willing they are to accept external jobs on their system. With Zero-Sum, a user can only submit jobs to the limit of their credit. Unless their cluster has competitive prices, the user will quickly run out of Barter Units and be unable to run jobs externally. This encourages clusters to set their prices fairly to attract more Barter Units. Using credit also helps system administration regulate delinquent clusters. Suppose a cluster repeatedly fails completing jobs by their Q.O.S. contract but reports that the job met its requirements and the user is charged. Through careful arbitration, system administration can readjust the balances appropriately. However, because this may be difficult to verify and readjust, credit based schemes provide another recourse - reducing credit. At zero credit, a cluster must run a successful job before they can submit jobs of their own to the Faucets system. This will motivate delinquent clusters to rethink their scheduling strategies and obey the Q.O.S. contracts. |