Yes but when we receive request it is not from the end user but other host. For eg: User -> server A (prepares file) -> (http request that need load balancing) Our host So it's server A actually making the request not the user but we need to load balance user because this user can sign off and connect again to server B. And if server B connects to other data center before file is replicated then that will be a problem. On Tue, Mar 29, 2011 at 7:07 PM, Igor Cicimov <icicimov@xxxxxxxxx> wrote: > 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 <mohitanchlia@xxxxxxxxx> > 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 <icicimov@xxxxxxxxx> 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 <icicimov@xxxxxxxxx> >> > 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 >> >> <mohitanchlia@xxxxxxxxx> >> >> 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 <icicimov@xxxxxxxxx> >> >>> 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 >> >>> > <mohitanchlia@xxxxxxxxx> >> >>> > 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 <btimby@xxxxxxxxx> >> >>> >> wrote: >> >>> >> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia >> >>> >> > <mohitanchlia@xxxxxxxxx> >> >>> >> > 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-unsubscribe@xxxxxxxxxxxxxxxx >> >>> >> " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx >> >>> >> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx >> >>> >> >> >>> > >> >>> > >> >>> >> >>> --------------------------------------------------------------------- >> >>> 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-unsubscribe@xxxxxxxxxxxxxxxx >> >>> " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx >> >>> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx >> >>> >> >> >> > >> > >> >> --------------------------------------------------------------------- >> 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-unsubscribe@xxxxxxxxxxxxxxxx >> " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx >> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx >> > > --------------------------------------------------------------------- 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-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|