Paul Greidanus wrote:
Bob Doolittle wrote:
Matthias Ernst wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I have upgraded now to Solaris 10/SParc and SRSS 3.1 and the
backup server solution using utadm -f seems to work well.
There is one additional question I have: When I reboot my
dedicated Sunray server, all the DTUs will go to the backup
server. Is there a way to migrate them all to the dedicated
server after it is back up short of rebooting the backup
server afterwards? I guess I could do a utrestart on the
backup server but it would be nicer to have a method that
just sends the idle sessions to the main server.
If you did a utrestart after hours, when everyone's
card was removed, this is exactly what would happen.
Idle sessions should only connect to the dedicated
server. When people insert their cards, if they have
a session on the backup server they will connect to it.
This would loose any session state that the user had?
No, not if you avoid the "-c" option to utrestart. Restarting
utauthd is safe and will result only in a temporary disconnection
of the DTUs - they'll immediately bind to the other server.
If you use NSCM, this isn't a problem, because session
location and load balancing happens after you enter
your user name, at which time both servers will be
up.
The only problem is people who leave their cards in
over night. In that case, if they don't remove and
then reinsert their cards (or power-cycle the Sun Ray)
in the morning, they'll log in and get a new session on
the dedicated server, which is not what you want.
Shouldn't there be policy against this sort of thing? It's a huge
security risk IMHO
Explain the security issue here please.
I could see a resource issue in that you might have
people using two sessions worth of resources, and I
could see a usability issue because people 'lost' what
they were doing (it's easily recoverable but people
might not realize that), but I don't see a security
issue - nobody but the user can access the user's
session.
It can't be addressed by policy, really. It's a
fundamental issue. Say a user has a session on
Server X, and there is another server Y in the
FOG. Say a network fault occurs between the DTU
the user is using and X. The Sun Ray will connect
to server Y, which is what FOG is for, but
there's still a session on Server X, and if Y
can't talk to X either there's really no way to tell.
Should we prevent the user from logging
into Y, when we can't tell if the user has a
session on X or not? How does SRSS distinguish
between X being down and a network fault which
makes X unreachable? In the first case, there's
no possibility of a duplicate session, but in the second
there is. What if SRSS on X is just restarting, and is
down temporarily but the sessions will survive? How
is this case determined and handled?
These are tricky situations which can't be treated
lightly. Some are impossible to solve.
Maybe you could write a script that issues "utsession -k"
to all the idle sessions?
We're discussing how we might add a feature to
disconnect DTUs and cause them to rebalance in
the next release.
Would this save session state, and move processes between servers?
No, that's impossible. Things like TCP connection
and hardware I/O state (think of hardware buffered
data in the process of being flushed to a device,
possibly flow-controlled) can't be moved from one
server to another. What we're envisioning would
simply solve the problem you requested. Without
NSCM, or if cards are inserted, after a disconnect
DTUs will reconnect and immediately be redirected
to servers which are online. With NSCM, the
initial "username" greeter session might connect to
an offline server, but once people insert their
username if they have no session on offline
servers they'll be redirected to an online server
for their new session.
I'm imagining something like a "disconnect all"
capability that would redistribute all idle sessions
across the servers which are currently up and
online.
This would be very very cool.. but a huge challenge. It would be very
neat if you could use infiniband, or something and have HA SunRay
Sessions, not service, but sessions..
If you can show me a graduate thesis from
*anybody* showing how to move a general-purpose
process between two servers (barring redundant
Fault Tolerant hardware), I'll be very surprised.
We actually had a Stanford intern in our group
working on this for limited types of processes for
a while, but it didn't pan out in any way that was
useful.
-Bob
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
