You could just use AMGH to take either the info field, MAC or IP of the Sun Ray to send it to a specific server. That way failover is guaranteed (if the server AMGH returns can't be reached, the Sun Ray will just stick around on the one that sent it there), and although I don't know loadbalancing specifics, it's still better then no loadbalancing at all.
-- "When the accumulation of wealth is no longer of high social importance, there will be great changes in the code of morals. We shall be able to rid ourselves of many of the pseudo-moral principles which have hag-ridden us for two hundred years, by which we have exalted some of the most distasteful of human qualities into the position of the highest virtues. We shall be able to afford to dare to assess the money-motive at its true value. The love of money as a possession - as distinguished from the love of money as a means to the enjoyments and realities of life - will be recognised for what it is, a somewhat disgusting morbidity, one of those semi-criminal, semi-pathological propensities which one hands over with a shudder to the specialists in mental disease..." - J.M. Keynes, Economic Possibilities for our Grandchildren (1930) On 4 July 2010 09:27, <[email protected]> wrote: > i do it by turning loadballancing off. And then on the dtus on one site u > put their sunray server first and the other second in the params file or > over the guii. The other site vice versa. This way i can control which dtu > connects to which server and if ine server fails the dtu automaticaly > connect to the other server. > Easy > > ------- Original message ------- > >> From: James Kissler <[email protected]> >> To: [email protected] >> Sent: 2.7.'10, 20:31 >> >> It should work, if your server is not setup with load balancing or in >> a failover group. >> >> However, I have a suggestion for you (it is what I am doing for >> similar reasons): >> >> Setup your failover group with load balancing. In the sunray >> database, accessible from the GUI, add a description with building and >> room number, in a set format. This will allow you to search by >> building with the room numbers in order, such as: >> >> BLDG 4321 RM 123 >> >> This will make things cut and dry. >> >> On Fri, Jul 2, 2010 at 11:23 AM, Jörg Barfurth <[email protected]> >> wrote: >> >>> Robert Jaudon schrieb: >>> >>>> >>>> I have a customer that has a 3 server FOG setup. Per the customers >>>> request they want to move a certain number of Sunray's onto each >>>> secondary >>>> server and have them remain there no matter what. The only way I know >>>> how >>>> to make a DTU stick on a particular server is to take the opposing >>>> server >>>> offline. I know that is not proper and did some researching and found >>>> via >>>> the auth.props file you can set enableLoadBalancing to false which kills >>>> the >>>> load balancing effect. What are the cons for doing this? >>>> >>> >>> Mainly that you have no load balancing. Depending on how you assign DTUs >>> to >>> servers, you may also lose failover, when one server goes down. >>> >>> If you do that, why do you still want the servers to form a failover >>> group? >>> You could simply set the servers up to be standalone. >>> >>> Note that even with load balancing off, you don't bind a DTU to a fixed >>> server. You only prevent load balancing when sessions start. If you use >>> smartcards, then you can move a 'server A' DTU away from its server by >>> inserting a smartcard, which has a session on server B. >>> >>> Will replication be affected? >>>> >>>> >>> No. >>> >>> Are there any other ways I can accomplish having the DTU's stick on a >>>> specific server and not load balance? >>>> >>>> >>> Use standalone servers. >>> >>> There might be a way to achieve a similar effect by removing the -g >>> option >>> from your policy string using utpolicy. But I don't know if the resulting >>> setup is still supported, if the servers are configured as a FOG. The web >>> admin GUI does not even offer that as an option. >>> >>> - Jörg >>> >>> -- >>> Oracle (http://www.oracle.com) >>> >>> Jörg Barfurth | Software Engineer Desktop Technology >>> Oracle Desktop Virtualization >>> >>> ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg >>> >>> ORACLE Deutschland B.V. & Co. KG >>> Hauptverwaltung: Riesstr. 25, D-80992 München >>> Registergericht: Amtsgericht München, HRA 95603 >>> >>> Komplementärin: ORACLE Deutschland Verwaltung B.V. >>> Rijnzathe 6, 3454PV De Meern, Niederlande >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>> Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven >>> >>> Oracle is committed to developing practices and products that help >>> protect >>> the environment >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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
