Thanks very much for your response. I will definitely follow your advices, they even are requirements for our organization so I have no choice anyway :-)
My original mail was motivated more like due to the concept of "session" here - In the SRS administration guide the session is defined as a set of assigned resources to an user. It's also defined (from the user's point of view) as a desktop session. As Bjoern said, once a server loses its connectivity, those sessions are lost. However, I've seen in a bunch of places that stated that even these sessions are lost, once the users reconnect, they'll recover the state of their desktop session (meaning the same desktop environment, the same windows, applications, etc.). So that's what still doesn't fit to me - Most of this data is stored in the user's home directory (under .gconf, .local... directories). So if by default homes are not replicated, how can the SRSS failover group know each user's desktop state? Well, all that assuming they actually recover that desktop session and the places where stated the desktop environment will be recovered are right. If not, I still don't see a big advantage between using a failover group and simply reconnecting to a new server chosen by DNS beyond the balancing algorithm. 2014-06-16 21:31 GMT+01:00 Jim Klimov <jimkli...@cos.ru>: > On 2014-06-15 19:48, Edwin Marqe wrote: > >> Thanks Bjoern. Does your last point mean that after the client >> reconnects it would recover the last known state it had on the failed >> server, meaning i.e. the same windows opened, same desktop configuration >> etc? In this case, would that mean that there's also a 'home' >> sincronization between the failover group servers? >> > > Agreeing with Bjoern, I want to address the last sentence: > do you mean a home directory here, and their synchronization > among Sun Ray servers? > > With any sufficiently large installation (and having several > terminal servers alone qualifies for that, IMHO) you should > really look towards a centralized networking infrastructure, > which includes home directories residing on an NFS server and > user accounts (especially non-kiosk ones) defined in the LDAP > catalogs (Sun DSEE, Oracle DSEE, ForgeRock OpenDJ, maybe even > OpenLDAP or MS Active Directory with Unix extensions). For > more resilience, you might replicate the LDAP catalogs, maybe > keeping a copy on each server and preferring it to the other > copies (search order, which can be defined in LDAP client > profiles stored in the catalog, and you assign each server > to its own profile). > > While it is discouraged by documentation, there are tricks to > allow a server hosting the LDAP service to be its own client. > > As one of the attributes in LDAP accounts you can specify the > home directories (though it is usually /home/username for all) > and also you can define automounter maps for autofs (so that > if you have several NFS servers hosting different sets of > users - these relations can be defined here). > > For failover of the homedir storage you use any number of > solutions, but should really prefer those based on OpenZFS > with illumos or BSD kernels (commercial or free, though the > reliable/HA ones tend to be more expensive in gear and paying > a price to one of the many developer companies for software > license and support is reasonable to keep the setup running). > In particular, for NFS and ZFS you should look towards systems > with dedicated ZIL (write-logging) devices preferably with DDR > RAM for active storage rather than SSDs or HDDs, since all NFS > write I/O is synchronous by design and lags greatly on ordinary > HDDs (must be really committed to storage before ACKing, and > servers that don't do this and seem fast - they lie and are an > accident waiting to happen in an emergency poweroff, kernel > crash, etc. which would not let them flush the caches for the > delayed writes). > > HTH, > Jim Klimov > > > _______________________________________________ > SunRay-Users mailing list > SunRay-Users@filibeto.org > http://www.filibeto.org/mailman/listinfo/sunray-users >
_______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users
