[GE users] Need help in SGE configuration and resource allocation

shaila shaila.parashar at colostate.edu
Thu May 20 17:09:52 BST 2010


Thanks a lot Reuti and Gerald

I have configured it using user_list and slot preemption. I have asked the users to test it. Will update the mailing list with the final configuration once everything works.

Once again thanks to all who responded.

> Hi,
> 
> Am 13.05.2010 um 20:42 schrieb gragghia:
> 
> > There are two easy ways to restrict host access as you describe.
> > 
> > 1. You can create two cluster queues (each containing one of the host 
> > groups), and then put the users into the "user_lists" for each queue of 
> > hosts they should have access to.  I recommend creating two user sets 
> > and then putting the user set name into the "user_lists" field.
> 
> it also possible to specify different user lists for different hostgroups inside one and the same queue, and so a second queue can be avoided:
> 
> user_lists NONE,[@hosts1=userlist1],[@hosts2=userlist2 userlist3]
> 
> 
> > 2. You can use a resource quota set similar to the following:
> > 
> > {
> >         name         host_access
> >         description  "restrict host access"
> >         enabled      true
> >         limit        users {a,b} hosts @dandyhosts to slots=1000
> >         limit        users {c,d,e} hosts @enshosts to slots=1000
> >         limit        to slots=0
> >      }
> 
> Or using a negated syntax:
> 
> limit users c,d,e hosts @dandyhosts to slots=0
> limit users a,b hosts @enshosts to slots=0
> 
> or using !:
> 
> limit users !@userlist1 hosts @dandyhosts to slots=0
> limit users !@userlist2 hosts @enshosts to slots=0
> 
> -- Reuti
> 
> 
> > 
> > 
> > 
> > On 5/13/2010 10:37 AM, shaila wrote:
> >> Hi I just had a question regarding restricting access to specific queues on certain hostgroups.
> >> As suggested, I have defined a queue called primary that includes all the hosts. I need to setup the queues such that only specific users have access to specific hosts in the queue. I tried user_lists, but I was unable to figure out the syntax.
> >> For example, I have a queue called primary that includes the hostgroups @dandyhosts and @enshosts.  I want it so that on the hosts included in dandyhosts, only 2 users (A and B) have access to the primary queue. And on the hosts included in enshosts, only 3 users (c, d and e) have access to the primary group. This is as John has suggested. I have been unable to figure out how to implement this.
> >> Thanks a lot for all your help.
> >> 
> >> Shaila
> >> 
> >> 
> >>> Hi John
> >>> 
> >>> Thank you so much for responding to my email.
> >>> Your setup is very similar to ours. Also, looks like your solution will suit our needs.
> >>> It definitely sounds like something that I would like to pursue. Could you please send me the details at my email - shaila.parashar at colostate.edu .
> >>> 
> >>> Once again thanks a lot.
> >>> 
> >>> Shaila
> >>> 
> >>> 
> >>>> Shaila -
> >>>> 
> >>>> here's how we handle a similar situation - using your example,
> >>>> we would have 3 hostgroups, as you described them. Also, we
> >>>> have 2 cluster queues - called "primary" and "secondary". Those
> >>>> in Mr A's group have access to the primary queue on hostgroup 2,
> >>>> and those in Mr B's group have access to the primary queue
> >>>> on hostgroup 3. If hostgroup 1 is truly shared, and has no
> >>>> users that have "priority", then in our model we would not give
> >>>> anyone access to the primary queue on hostgroup 1. All users
> >>>> have access to the secondary queue on all hostgroups.
> >>>> 
> >>>> Now, the thing that makes this work is that the secondary queue
> >>>> is a subordinant of the primary queue. Therefore, for example,
> >>>> if a user who's not in either hostgroup 2 or hostgroup 3 starts
> >>>> a job, it might get assigned to the secondary queue on hostgroup 2.
> >>>> That's OK as long as no one in Mr A's group needs it. But if
> >>>> someone in Mr A's group does submit a job, and there's nowhere
> >>>> else to run it, then the secondary job on hostgroup 2 will get
> >>>> suspended, and Mr A's guy's job will run there.
> >>>> 
> >>>> That's how we handle resources that are "paid for" by a certain
> >>>> group of users, and expect to have access to them, while sharing
> >>>> them with all users when they aren't busy. If that sounds like
> >>>> something you'd want to pursue, I can send more details, but that's
> >>>> enough for this post....
> >>>> 
> >>>>      John
> >>>> 
> >>>> 
> >>>> shaila wrote:
> >>>> 
> >>>>> Hi
> >>>>> 
> >>>>> I am a newbie to the resource allocation and ticket allocation on SGE.
> >>>>> I have the following scenario :-
> >>>>> 
> >>>>> We have 3 sets of machines :-
> >>>>> 
> >>>>> HostGroup 1 - 7 machines with 8 cores each and 16GB of RAM
> >>>>> HostGroup 2 - 4 machines with 16 cores  and 24G of RAM
> >>>>> HostGroup 3 - 10 machines with 8 cores and 24GB of RAM
> >>>>> 
> >>>>> Hostgroup 1 has been purchased by the college, Hostgroup 2 has been purchased by Mr. A and Hostgroup 3 has been purchased by Mr. B. They have included them in the big cluster with the condition that when they submit a job, they will get a minimum of what they purchased and additional resources from the other hostgroups based on availability.
> >>>>> So, when members from Mr. A's group  submit a job, they should get at least 64 cores and 24x4 GB of RAM and if there is more available , then they should get that too.
> >>>>> But when someone from Mr. B's group  comes along and submits a job, he should be guaranteed the 80 cores and 24x10 GB of RAM. So, if there is another job running on the other nodes, then they should be suspended and his jobs should start.
> >>>>> We also need to have a maximum wait period of 4 hours for the jobs.
> >>>>> 
> >>>>> I feel that there are a lot of things to be considered here and am not sure how to go about it.
> >>>>> 
> >>>>> I know I will need to have a load_scaling factor. But I am not able to figure out how to calculate it.
> >>>>> Also , I since we do not need to have a share tree policy, I have configured a functional policy for the groups.
> >>>>> 
> >>>>> Any suggestions on how to start on this sort of resource allocation and scheduling would be extremely helpful.
> >>>>> 
> >>>>> Thanks a lot in advance.
> >>>>> 
> >>>>> Shaila
> >>>>> 
> >>>>> ------------------------------------------------------
> >>>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=255609
> >>>>> 
> >>>>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
> >>>>> 
> >>>> 
> >>>> 
> >>>> -- 
> >>>> ###########################################################################
> >>>> # John Foley                          # Location:  IL93-E1-21S            #
> >>>> # IT&  Systems Administration         # Maildrop:  IL93-E1-35O            #
> >>>> # Antenna&  Mechanical Simulation Grp #    Email: john.foley at motorola.com #
> >>>> # Motorola, Inc. -  Mobile Devices    #    Phone: (847) 523-8719          #
> >>>> # 600 North US Highway 45             #      Fax: (847) 523-5767          #
> >>>> # Libertyville, IL. 60048  (USA)      #     Cell: (847) 460-8719          #
> >>>> ###########################################################################
> >>>>                (this email sent using SeaMonkey on Windows)
> >>>> 
> >> ------------------------------------------------------
> >> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=257187
> >> 
> >> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
> >> 
> > 
> > -- 
> > Gerald Ragghianti
> > 
> > Newton HPC Program http://newton.utk.edu/
> > Office of Information Technology
> >   Research Computing Support
> >   Professional Technical Services
> > 
> > The University of Tennessee
> > 2309 Kingston Pike
> > Knoxville, TN 37996
> > Phone: 865-974-2448
> > 
> > /-------------------------------------\
> > | One Contact       OIT: 865-974-9900 |
> > | Many Solutions         help.utk.edu |
> > \-------------------------------------/
> > 
> > ------------------------------------------------------
> > http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=257200
> > 
> > To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=257990

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list