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

reuti reuti at staff.uni-marburg.de
Fri May 21 16:25:00 BST 2010


Hi,

Am 21.05.2010 um 17:21 schrieb shaila:

> Hi
>
> Thank you for all your help.
> I tried configuring the queue high.q using userlists and user sets, but I get an error that I do not have permission to access the queue.
> My configuration is as follows:
>
> I have a usergroup called dandygroup
>
> shippo % qconf -su dandygroup
> name    dandygroup
> type    DEPT
> fshare  45000
> oticket 0
> entries dandy,nslynn,joeblow
>
> I have hostgroup called dandyhosts. It is configured as below:
> shippo % qconf -shgrp @dandyhosts
> group_name @dandyhosts
> hostlist bacara.engr.colostate.edu cody.engr.colostate.edu \
>         neyo.engr.colostate.edu fox.engr.colostate.edu
>
>
> I have a queue called high.q with the user_list defined as given below:
> slots                 1,[eng-blade0.engr.colostate.edu=8], \
>                      [eng-blade1.engr.colostate.edu=8], \
>                      [eng-blade2.engr.colostate.edu=8], \
>                      [eng-blade3.engr.colostate.edu=8], \
>                      [eng-blade4.engr.colostate.edu=8], \
>                      [eng-blade5.engr.colostate.edu=8], \
>                      [eng-blade6.engr.colostate.edu=8], \
>                      [fox.engr.colostate.edu=16], \
>                      [cody.engr.colostate.edu=16], \
>                      [neyo.engr.colostate.edu=16], \
>                      [bacara.engr.colostate.edu=16]
>
> user_lists            NONE,[@dandyhosts=dandygroup],[@enghosts=baugroup ensdept]
>
>
> I logged in as joeblow , who is a member of dandygroup .
> When I submit a job to high.q as follows
>
> qsub -q high.q simple.sh
>
> I get the following error
>
> has no permission for queue "high.q at eng-blade0.engr.colostate.edu"

is this the primary group? If not, you have to change to this group by `newgrp dandygroup` or use `sg dandygroup -c qsub...`.

-- Reuti


> ...
>
> It gives this error message for all the hosts listed in high.q
>
> I could not figure out what I am doing wrong.
> Could you please give some suggestions.
>
> Once again thanks for all the help.
>
> Shaila
>
>
>
>
>> 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=258105
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

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

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



More information about the gridengine-users mailing list