You have made some rather significant investment in your cluster. It is also evident that it depreciates at a rather frightening rate. Given these two facts it should be obvious you want your cluster busy 100% of the time if possible.
However, timely results of output are also important. If the memory requirements of programs running on the cluster exceed the available physical memory, swap memory (hard disk) will be used severely reducing performance. Even if the memory requirements of many processes still fit within the physical memory, results of any one of the programs may take significantly longer to achieve if many jobs are running on the same nodes simultaneously.
Thus we come to concept of the “load balancing”, which maintain a delicate balance between overburdened and idle. Load balancing is when multiple servers can perform the same task, and which server performs the task is based on which server is currently doing the least amount of work. This helps to spread a heavy work load across several machines, and does it intelligently; if one machine is more heavily loaded than the others, new requests will not be sent to it. By doing this, a job is always run on a machine that has the most resources to devote to it, and therefore gets finished sooner.
Generally, it is believed that a constant load of one 100% CPU bound process per CPU is ideal. However, not all processes are CPU bound; many are I/O bound on either the harddrive or the network. The act of load balancing is often described as “scheduling”.
Optimal load balancing is almost never achieved; hence, it is a subject of study for many researchers. The optimal algorithm for scheduling the programs running on your cluster is probably not the same as it might be for others, so you may want to spend time on your own load balancing scheme.
Load Balancing in a Scyld Cluster¶
Scyld ClusterWare supplies a general load balancing and job scheduling scheme via the
beomap subsystem in conjunction with job queuing utilities. Mapping
is the assignment of processes to nodes based on current CPU load.
Queuing is the holding of jobs until the cluster is idle enough to let
the jobs run. Both of these are covered in detail in other sections of
this guide and in the User’s Guide. In this section, we’ll just discuss
the scheduling policy that is used.
The current default mapping policy consists of the following steps:
Run on nodes that are idle
Run on CPUs that are idle
Minimize the load per CPU
Each proceeding step is only performed if the number of desired
processes (NP) is not yet satisfied. The information required to perform
these steps comes from the
BeoStat sub-system of daemons and
The current default queuing policy is to attempt to determine the
desired number of processes (NP) and other mapping parameters from the
job script. Next, the
beomap command is run to determine which nodes
would be used if it ran immediately. If every node in the returned map
is below 0.8 CPU usage the job is released for execution.
Implementing a Scheduling Policy¶
The queuing portion of the schedule policy depends on which scheduling and resource management tool you are using. The mapping portions, however, are already modularized. There are a number of ways to override the default, including
Substitute a different program for the
beomapcommand and use
mpirunto start jobs (which uses beomap).
Create a shared library that defines the function get_beowulf_job_map() and use the environment variable LD_PRELOAD to force the pre-loading of this shared library.
Create the shared library and replace the default
These methods are in order of complexity. We can’t actually highly recommend the first method as your mileage may vary. The second method is the most recommended followed by the third method of replacing the Scyld source code when you’re happy that your scheduler is better.
It is highly recommended that you get the source code for the
package. It will give you a head start on writing your own mappers. For
more information on developing your own mapper, see the Programmer’s Guide.