On Wed, 2007-09-05 at 13:33 -0400, Lewick, Taylor wrote: > Brad, okay, that makes sense. A couple of more follow-up questions. > If we set it up as you describe below, since they aren't replicating, > that means when a user is initially setup, his information won't flow > across to the non-replicated server. We setup in the info field the > name of the user's Virtual Desktop Machine, and the UTWBTstart script > we have parses the other field to grab that VM name and set up the RDP > session to that host. > > So under your scenario, we would need to periodically replicate this > info manually. I know it can be done quite easily by dumping the > contents of utuser, utdesktop, utresadm, utresdef and utxconfig into > files, and importing them on the other server. That or direct our > desktop support team to register a card in both failover groups when > setting up new users.
Yes, registrations population across FOGs would have to be done manually. > > Also, you mentioned the inorder part of the parms file, which is fine > with 2 servers to reverse them, but we would have 3 servers in our > setup. Two in the primary FoG and one in another FoG in a different > location. So my understanding there is select=inorder would mean one > of the servers would never be used. Is that correct? No, They all are used, in order. Say you have three servers. two at one site in a FOG, and one at an alternate site called ServerA, ServerB, and ServerZ. Your parms file would look like this. servers=servera,serverb,serverz select=inorder This would mean that your DTUs would try to connect in that order. If they connected to ServerA, FOG load balancing would place their session between ServerA and ServerB. If both ServerA and ServerB are down, the STU will try ServerZ. Brad > > > > ______________________________________________________________________ > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Brad Lackey - > US-SW Desktop Product Lead > Sent: Wednesday, September 05, 2007 9:29 AM > To: SunRay-Users mailing list > Subject: RE: [SunRay-Users] Multicast problems > > > > > The issue is that if you set up a FOG across the WAN, you will be > subject to the load balancing mechanism deciding where your sessions > will live. > > For example... We have two sites Site A and Site B These sites have > 100MB local LAN's but are connected by a 4MB WAN link. There is one > Sun Ray server at each location, and 10 DTUs at each location. > > If you set up the servers at both sites in a FOG, DTUs from each site > may have sessions on the other site during normal operation. This > wouldn't be the best use of your WAN link bandwidth. > > What most customers want is their DTUS to connect to a local Sun Ray > server, and if in the case that server is down, connect across the WAN > to the alternate. > > There is no Need to put these in a FOG to do this. The two things that > a FOG does is Replication of policy/registrations and load balancing. > > Your best bet is to use your configuration mechanisms to give the DTUs > BOTH servers as connection targets in the preferred order. > > For example, put both your servers in the servers= line of your .parms > file and set select=inorder. The servers= lines will be opposite on > both of your servers. > > Brad > > On Wed, 2007-09-05 at 09:28 -0400, Lewick, Taylor wrote: > > > If I understand it correctly, SUN uses AMGH, and there is a good blog of > > an "AMGH How To Guide" here... > > http://blogs.sun.com/bobd/ > > > > My problem is I'd like to setup failover groups across the WAN. But > > according to our network guys, we don't route mutlicast across the WAN. > > And AMGH still says its not currently supported for CAM/Kiosk mode. It > > can be done, but requires a little customization. Myself, I have no > > problem trying to do the customization, but as the only onsite Unix > > Admin, and due to corporate requirements, I'd really rather not start > > down the path of running in an "unsupported" configuration. > > > > So I'm a bit stuck as to how I should go about implementing failover > > groups across the WAN. > > > > Any ideas? > > > > Thanks, > > Taylor > > > > _______________________________________________ > > SunRay-Users mailing list > > [email protected] > > http://www.filibeto.org/mailman/listinfo/sunray-users > > > Brad Lackey > Desktop Product Lead > US Software Practice > (720) 548-3339 > [EMAIL PROTECTED] > > > > > _______________________________________________ > SunRay-Users mailing list > [email protected] > http://www.filibeto.org/mailman/listinfo/sunray-users Brad Lackey Desktop Product Lead US Software Practice (720) 548-3339 [EMAIL PROTECTED]
<<attachment: sun_sig2.gif>>
<<attachment: sun_sig2.gif>>
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
