We considered this option as well but the problem we saw with it is what 
happens when a user tries to use screen? Many of our users login, start screen, 
do some work and then disconnect. Whenever they reconnect they can pick up from 
where they left off. If you are allocated to a compute node based on loads, you 
likely won't be on the same node where your last session was. This is 
inconvenient for the users but then also leaves screen sessions open, at least 
until the time limit expires, on compute nodes.

The other issue is the time limit. Do you make it 1 hour, 4 hours, 8 hours? How 
long does a user get to be logged in? If the time limit expires, what happens 
to the open editor session? Can this be recovered on a different compute node?  

We are still looking for a good way to balance users on login nodes. Right now 
we are working on a method of redirecting ssh logins based on user IDs which 
feels extremely "hacky" as well.

Carl
--
Carl Schmidtmann
Center for Integrated Research Computing
University of Rochester

On Mar 24, 2014, at 5:44 AM, Olli-Pekka Lehto wrote:

> 
> Dear devs,
> 
> We are testing a concept where we are dynamically allocating a portion of our 
> compute nodes with oversubscribed interactive nodes for low-intensity use. To 
> make the use as simple as possible, we are testing redirecting user login 
> sessions directly to these nodes via SLURM. 
> 
> Basically the shell initialization on the actual login node contains a SLURM 
> srun command to spawn an interactive session and the user gets 
> "transparently" dropped into a shell session on a compute node.
> 
> This would offer more flexibility than physically setting up a set of login 
> nodes. Furthermore, SLURM should be able make better decisions on where to 
> assign each incoming session based on resource usage than a more naive 
> round-robin load balancer. This way also all interactive use can be tracked 
> with SLURM's accounting. 
> 
> Based on simple initial testing this seems to work but it's still a bit hacky.
> 
> My question is has anyone been doing similar things and what are your 
> experiences? Are there some caveats that we should be aware of?
> 
> Best regards,
> Olli-Pekka
> -- 
> Olli-Pekka Lehto
> Development Manager
> Computing Platforms
> CSC - IT Center for Science Ltd.
> E-Mail: olli-pekka.le...@csc.fi
> Tel: +358 50 381 8604
> skype: oplehto // twitter: ople

Reply via email to