PBSPro 5.3: Peer scheduling
Ron Chen
ron_chen_123 at yahoo.com
Tue Mar 18 19:19:17 PST 2003
--- Danny Sternkopf <dsternkopf at ess.nec.de> wrote:
> PBSPro 5.3.0 introduces the ability to have
> different pbs installations
> run jobs from each other. This is done by having
> PBS move jobs from one to
> another when they can run.
>
> Peer scheduling is useful when installation A is
> impacted with work and B is
> not. Installation B can look at all the jobs which
> are waiting run on A. If
> B has enough resources to run any of them, it will
> move the job to B and run
> it. Another usefulness of peering is when
> installations (and computing
> resources) are distant. If you have one on the east
> coast and one on the
> west, PBS can move jobs between the two when
> resources become idle.
>
> The peer scheduling model which PBS implemented is a
> pull model. This means
> that B will move jobs from A to B, but never the
> push jobs to A. There is
> nothing stopping you from having A pull jobs from B
> and B pull jobs from A.
>
> PBS implements this by "mapping" a queue from A onto
> B. This means that the
> scheduler on B will see all the jobs in that queue
> on A as if they were in a
> queue on B. If B's scheduler chooses a job in A to
> run, t first moves it
> from A to B and then runs it.
>
> The peer scheduler works over a flat namespace.
> This means that joe on host A
> better be joe on host B.
>
> A couple of terms should be defined first.
> local server - the server which will pull jobs
> remote server - the server where jobs are coming
> from
> peer a job - to pull a job from a remote server to a
> local one
>
> scheduler configuration change:
>
> peer_queue - This instructs the scheduler to "map"
> jobs from a remote server
> to the local one.
>
> Format:
>
> peer_queue: "local_queue remote_queue at remote_server"
>
> Example:
> peer_queue: "workq workq at rserv"
> peer_queue: "peer1 workq at rserv2"
>
> To set up the peer scheduler you need to do a couple
> of things
> 1. qmgr> set server flatuid = true
> 2. add one more more peer_queue entires to the
> scheduling config file
>
> On the remote side:
> 1. qmgr> set server flatuid = true
> 2. qmgr set server managers += root at local_server
>
> This second one authorizes the local server to be
> able to query and move jobs.
> The peer server will not work properly without it.
>
>
>
> Since the scheduler maps the remote jobs to a local
> queue, the scheduler will
> view them as local jobs in it's policy. If remote
> jobs are to be treated
> differently then local jobs, this can be done on the
> queue level. A queue can
> be created exclusively for remote jobs and this will
> allow queue level policy
> to be set for remote jobs (i.e. max_running or
> max_user_run or resources_max
> etc).
>
__________________________________________________________________________
> To unsubscribe: email majordomo at OpenPBS.org with
> body "unsubscribe pbs-users"
> For message archives:
> http://www.OpenPBS.org/UserArea/pbs-users.html
> - - - - - - - - - -
> - - - -
> OpenPBS and the pbs-users mailing list are sponsored
> by Altair.
>
__________________________________________________________________________
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
More information about the Beowulf
mailing list