There is only one FOG, which spans both datacenters. Neither datacenter is local to any location to where the DTUs are deployed, so there should be no affinity. Both datacenters are hot, as are the locations where the DTUs are deployed.
Our network is highly redundant and reliable - we are extremely intolerant of network delays, and outages are unheard of. I understand this is not typical, but I guess that's why we can tune, right? Thanks very much. I think I'll tweak and test... -Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bob Doolittle Sent: Tuesday, September 08, 2009 9:42 AM To: SunRay-Users mailing list Subject: Re: [SunRay-Users] auth.props timeout tuning (was RE: Detect Disconnected DTUs) Quayle, Bill wrote: > This brings up a good point. > > In my installation, our production FOG is split across two datacenters. If I > "lose" one datacenter, I want the clients to fall over to the servers at the > other datacenter as quickly as possible - in seconds would be ideal. > > As a matter of fact, if I have *any* problems with a server, I want the DTU > to re-bind to another server quickly so I can get my displays back online. > > Can I tune this using the timeout value in auth.props, and what is the > downside to this? > So are you implying that you have a single FOG which spans the two datacenters? Or are they two FOGs, and at bootup you are providing server addresses in each, in the preferred order? In the latter case, the downside would be that if you had a short, intermittent network outage DTUs would create sessions in the "other" datacenter. After network resumption, the first time somebody removed and reinserted their card they would connect to their local datacenter, and not be able to reach their stranded sessions in the remote datacenter without manually using utswitch or utselect. In the former case (one FOG) you can't create an affinity for the local datacenter. Generally neither behavior is desirable so very short timeouts are not recommended. 8 minutes is rather long, however. Even TCP only has a 3-minute timeout by default. -Bob > Thanks, and sorry for the hijacked thread. > > -Bill > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Joerg Barfurth > Sent: Tuesday, September 08, 2009 9:12 AM > To: SunRay-Users mailing list > Subject: Re: [SunRay-Users] Detect Disconnected DTUs > > Stuart schrieb: > > >> Basically I want to detect if somebody runs off with a sun ray. :-) >> >> > > You can't reliably detect that across an arbitrary TCP/IP network > connection. > > >> If I unplug a dtu, I can't find any events anywhere (like in the log >> files) until I plug it back in and reconnects. >> >> > > Generally it takes up to twice the 'timeout' time specified in the > auth.props(4) file (i.e. up to 2x240 sec = 8 min) until the > authentication daemon gives up on a non-responsive connection. When that > happens it will internally disconnect the DTU and any associated > utaction will fire. > > If the network connection is temporarily interrupted and restored, the > connection may be simply resumed where it left off. (AFAIK the DTU gives > up on the old connection sooner than the server does, so this may not be > possible for the full 8 min.) > > - Jörg > > _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
