[Bioclusters] PBSPro 5.3: Peer scheduling

[Ron Chen]

--- Danny Sternkopf <dsternkopf@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@remote_server"
> 
> Example:
> peer_queue: "workq     workq@rserv"
> peer_queue: "peer1     workq@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@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@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