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