Aren't the requests from one user coming from the same ip? This method will cause the requests coming from one source ip address always go to the same server ip address ... but as I said maybe I'm missing something :)
On Wed, Mar 30, 2011 at 12:18 PM, Mohit Anchlia <mohitanch...@gmail.com>wrote: > But this doesn't work for scenario that I described where user > connects to server and then server sends the requests to us. We really > want to load balance users not the servers. > > On Tue, Mar 29, 2011 at 5:07 PM, Igor Cicimov <icici...@gmail.com> wrote: > > Also the difference between GTM and LTM is that GTM enables fail-over > > between geographically different sites and for LTM that is possible only > for > > local sites. Nothing to do with the persistence feature. > > > > On Wed, Mar 30, 2011 at 10:59 AM, Igor Cicimov <icici...@gmail.com> > wrote: > >> > >> Strange because a quick search gives me this > >> > >> > >> > http://devcentral-sea.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/26947/showtab/groupforums/Default.aspx > >> > >> On Wed, Mar 30, 2011 at 10:17 AM, Mohit Anchlia <mohitanch...@gmail.com > > > >> wrote: > >>> > >>> Are you referrring to GTM or LTM. I have looked into it and even > >>> talked to F5 but currently they don't have this functionality for > >>> Prod. > >>> > >>> On Tue, Mar 29, 2011 at 4:16 PM, Igor Cicimov <icici...@gmail.com> > wrote: > >>> > Hi guys, > >>> > > >>> > Just scanned through the thread quickly so not sure if this makes any > >>> > sense > >>> > but what about F5 source IP stickiness? > >>> > > >>> > Cheers, > >>> > Igor > >>> > > >>> > On Wed, Mar 30, 2011 at 3:34 AM, Mohit Anchlia < > mohitanch...@gmail.com> > >>> > wrote: > >>> >> > >>> >> Currently, the load balancer don't provide the user > >>> >> stickyness/persistence for 'x' amount of time. At this point only > >>> >> option I see is that of creating a custom solution. It looks like > >>> >> there is no good solution. > >>> >> > >>> >> Problem here is User can be directed to any site by load balancer in > >>> >> active active scenario where load is being balanced as 1:1 ratio. > >>> >> > >>> >> Cookie was a good option but doesn;t work for non-browser client > where > >>> >> browser connection to server A and then server A then make Http > >>> >> request. So in essence it's the ip of server A that is making the > >>> >> request and there is no way to use cookies in such scenarios. > >>> >> > >>> >> On Tue, Mar 29, 2011 at 7:25 AM, Ben Timby <bti...@gmail.com> > wrote: > >>> >> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia > >>> >> > <mohitanch...@gmail.com> > >>> >> > wrote: > >>> >> >> Thanks! We are using F5 GTM as global load balancer with LTM. So > >>> >> >> global load balancing is not a problem. Problem is user > stickyness > >>> >> >> that need to persist beyond individual session. > >>> >> >> > >>> >> >> I forgot to mention that the problem is that these connections > come > >>> >> >> from the servers using http rather than browser and that's why > >>> >> >> cookies > >>> >> >> here will probably not work. > >>> >> > > >>> >> > Then you will have to review your load balancer docs and see what > >>> >> > options are available and go from there. A common load balancing > >>> >> > method is SOURCE, where the source of the request is hashed to > >>> >> > determine the backend server to direct the request to. This would > >>> >> > ensure the same source always hits the same backend (as long as it > >>> >> > is > >>> >> > available). The downside to this method is that upstream proxies > >>> >> > hide > >>> >> > the client's IP address and undermine the load balancing > >>> >> > effectiveness > >>> >> > of this method. However, you know the user (or group of users) > will > >>> >> > be > >>> >> > sticky. > >>> >> > > >>> >> > >>> >> > --------------------------------------------------------------------- > >>> >> The official User-To-User support forum of the Apache HTTP Server > >>> >> Project. > >>> >> See <URL:http://httpd.apache.org/userslist.html> for more info. > >>> >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > >>> >> " from the digest: users-digest-unsubscr...@httpd.apache.org > >>> >> For additional commands, e-mail: users-h...@httpd.apache.org > >>> >> > >>> > > >>> > > >>> > >>> --------------------------------------------------------------------- > >>> The official User-To-User support forum of the Apache HTTP Server > >>> Project. > >>> See <URL:http://httpd.apache.org/userslist.html> for more info. > >>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > >>> " from the digest: users-digest-unsubscr...@httpd.apache.org > >>> For additional commands, e-mail: users-h...@httpd.apache.org > >>> > >> > > > > > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > " from the digest: users-digest-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
