You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Mohit Anchlia <mo...@gmail.com> on 2011/03/29 02:30:36 UTC
[users@httpd] Active Active Data center and stickyness
Apache 2:
We use apache 2 and we have 2 data centers. Problem is that both data
centers are active. So if User uploads a file for eg: in site A that
User can be directed to site B. Files are kept in sync asynchronously.
And it could take as long as 1 hr to bring them in sync on the other
data center. Now this presents unique problem as to how to provide
user stickyness accross data centers with 2 diff. cluster of nodes
each cluster running with nodes only in that data center.
I am sending this out in case people have solved it already or have
some suggestions on how this can be done.
Thanks
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Mohit Anchlia <mo...@gmail.com>.
Thanks! I will get more info and post what I find or route I go.
On Wed, Mar 30, 2011 at 7:22 AM, Ben Timby <bt...@gmail.com> wrote:
> On Wed, Mar 30, 2011 at 10:17 AM, Mohit Anchlia <mo...@gmail.com> wrote:
>> Appreciate all the input! Those things were already part of my list
>> that are mentioned in this email.
>>
>> What I was trying to point was that we are really in restrictive env
>> where server A can't be changed and 3rd party may not agree to change.
>> So I was wondering if there is something like caching on Apache
>> servers or something similar that can help. So if user A with id "A"
>> comes to site 1 and if that user is actually supposed to be in site 2
>> then redirect. Or may be some better solution on similar lines.
>
> Understood, without direct access to the system, and a wealth of
> information, we can't answer that question for you. There is probably
> some identifying information there, but you can't tell us what it is
> and we can't look for it, so our hands are tied.
>
> I have developed systems in the past where I glob the user agent and
> some other headers from clients and hash those to use as an
> identifier. The same browser will produce the same identifier, and can
> be used to identify the user in absence of anything else. But I don't
> know what headers or other details are in your HTTP requests. I don't
> know what there is to work with.
>
> Anyway, good luck!
>
> ---------------------------------------------------------------------
> 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@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Ben Timby <bt...@gmail.com>.
On Wed, Mar 30, 2011 at 10:17 AM, Mohit Anchlia <mo...@gmail.com> wrote:
> Appreciate all the input! Those things were already part of my list
> that are mentioned in this email.
>
> What I was trying to point was that we are really in restrictive env
> where server A can't be changed and 3rd party may not agree to change.
> So I was wondering if there is something like caching on Apache
> servers or something similar that can help. So if user A with id "A"
> comes to site 1 and if that user is actually supposed to be in site 2
> then redirect. Or may be some better solution on similar lines.
Understood, without direct access to the system, and a wealth of
information, we can't answer that question for you. There is probably
some identifying information there, but you can't tell us what it is
and we can't look for it, so our hands are tied.
I have developed systems in the past where I glob the user agent and
some other headers from clients and hash those to use as an
identifier. The same browser will produce the same identifier, and can
be used to identify the user in absence of anything else. But I don't
know what headers or other details are in your HTTP requests. I don't
know what there is to work with.
Anyway, good luck!
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Mohit Anchlia <mo...@gmail.com>.
Appreciate all the input! Those things were already part of my list
that are mentioned in this email.
What I was trying to point was that we are really in restrictive env
where server A can't be changed and 3rd party may not agree to change.
So I was wondering if there is something like caching on Apache
servers or something similar that can help. So if user A with id "A"
comes to site 1 and if that user is actually supposed to be in site 2
then redirect. Or may be some better solution on similar lines.
On Wed, Mar 30, 2011 at 7:11 AM, Ben Timby <bt...@gmail.com> wrote:
> On Wed, Mar 30, 2011 at 12:12 AM, Mohit Anchlia <mo...@gmail.com> wrote:
>> thanks! F5 supports the cookies and is recommended way but the problem
>> is server A is not managed by us and may be very difficult to
>> convience them to enter cookie (changing code). Is it possible to
>> embed cookies for non-browser clients in serverA?
>
> I don't understand the question. Server A is an HTTP client, so it
> would have a chance to inject cookies. They are after all just an HTTP
> header. Whether it is a browser or not is irrelevant.
>
>> Are there any other options if server A can't be changed.
>
> Not with the little information I have. If I was working on this
> solution, the major part of the project would be research. Traffic
> dumps between client and server A, traffic dumps between server A and
> my system. Code review of server A. How? Why? What? Who? When? Where?
> If there is a needle there, you need to find it, otherwise, you will
> need to find the smallest impact method for embedding a needle. Either
> way, information is key and research is the way of gathering
> information. The implementation is always simpler than the discovery,
> otherwise the project is boring.
>
> I think we have given about all the available solutions to you, but
> your job is to find the details needed to implement them. We can't do
> that for you.
>
> ---------------------------------------------------------------------
> 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@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Ben Timby <bt...@gmail.com>.
On Wed, Mar 30, 2011 at 12:12 AM, Mohit Anchlia <mo...@gmail.com> wrote:
> thanks! F5 supports the cookies and is recommended way but the problem
> is server A is not managed by us and may be very difficult to
> convience them to enter cookie (changing code). Is it possible to
> embed cookies for non-browser clients in serverA?
I don't understand the question. Server A is an HTTP client, so it
would have a chance to inject cookies. They are after all just an HTTP
header. Whether it is a browser or not is irrelevant.
> Are there any other options if server A can't be changed.
Not with the little information I have. If I was working on this
solution, the major part of the project would be research. Traffic
dumps between client and server A, traffic dumps between server A and
my system. Code review of server A. How? Why? What? Who? When? Where?
If there is a needle there, you need to find it, otherwise, you will
need to find the smallest impact method for embedding a needle. Either
way, information is key and research is the way of gathering
information. The implementation is always simpler than the discovery,
otherwise the project is boring.
I think we have given about all the available solutions to you, but
your job is to find the details needed to implement them. We can't do
that for you.
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Mohit Anchlia <mo...@gmail.com>.
thanks! F5 supports the cookies and is recommended way but the problem
is server A is not managed by us and may be very difficult to
convience them to enter cookie (changing code). Is it possible to
embed cookies for non-browser clients in serverA?
Are there any other options if server A can't be changed.
On Tue, Mar 29, 2011 at 8:07 PM, Ben Timby <bt...@gmail.com> wrote:
> On Tue, Mar 29, 2011 at 10:56 PM, Mohit Anchlia <mo...@gmail.com> wrote:
>> 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.
>
> If you control server A, then it is simple. At least for the load
> balancer I am used to using (HAProxy). You can stuff some client
> identifying information into a header, cookie, or querystring before
> generating the request to the load balancer.
>
> Then write some rule in the load balancer config to direct traffic
> based on that rule.
>
> http://haproxy.1wt.eu/download/1.3/doc/configuration.txt
>
> I would be really surprised if a product like F5 does not allow this
> level of sophistication. If not, then I would drop it and use
> something more flexible.
>
> Of course nothing bars you from running a proxy like HAProxy in front
> of the load balancer to do some intermediary processing that allows
> you to take advantage of some other F5 feature.
>
> Maybe figure out what format F5 uses for it's cookies, and forge one
> with the request from server A. Or forge it at an intermediary proxy.
>
> ---------------------------------------------------------------------
> 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@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Ben Timby <bt...@gmail.com>.
On Tue, Mar 29, 2011 at 10:56 PM, Mohit Anchlia <mo...@gmail.com> wrote:
> 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.
If you control server A, then it is simple. At least for the load
balancer I am used to using (HAProxy). You can stuff some client
identifying information into a header, cookie, or querystring before
generating the request to the load balancer.
Then write some rule in the load balancer config to direct traffic
based on that rule.
http://haproxy.1wt.eu/download/1.3/doc/configuration.txt
I would be really surprised if a product like F5 does not allow this
level of sophistication. If not, then I would drop it and use
something more flexible.
Of course nothing bars you from running a proxy like HAProxy in front
of the load balancer to do some intermediary processing that allows
you to take advantage of some other F5 feature.
Maybe figure out what format F5 uses for it's cookies, and forge one
with the request from server A. Or forge it at an intermediary proxy.
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Mohit Anchlia <mo...@gmail.com>.
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 <ic...@gmail.com> 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 <mo...@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 <ic...@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 <ic...@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
>> >> <mo...@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 <ic...@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
>> >>> > <mo...@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 <bt...@gmail.com>
>> >>> >> wrote:
>> >>> >> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia
>> >>> >> > <mo...@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-unsubscribe@httpd.apache.org
>> >>> >> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> >>> >> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
>> >>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> >>> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Igor Cicimov <ic...@gmail.com>.
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 <mo...@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 <ic...@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 <ic...@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 <mohitanchlia@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 <ic...@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 <
> mohitanchlia@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 <bt...@gmail.com>
> wrote:
> >>> >> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia
> >>> >> > <mo...@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-unsubscribe@httpd.apache.org
> >>> >> " from the digest: users-digest-unsubscribe@httpd.apache.org
> >>> >> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
> >>> " from the digest: users-digest-unsubscribe@httpd.apache.org
> >>> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Active Active Data center and stickyness
Posted by Mohit Anchlia <mo...@gmail.com>.
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 <ic...@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 <ic...@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 <mo...@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 <ic...@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 <mo...@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 <bt...@gmail.com> wrote:
>>> >> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia
>>> >> > <mo...@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-unsubscribe@httpd.apache.org
>>> >> " from the digest: users-digest-unsubscribe@httpd.apache.org
>>> >> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
>>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Igor Cicimov <ic...@gmail.com>.
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 <ic...@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 <mo...@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 <ic...@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 <mo...@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 <bt...@gmail.com> wrote:
>> >> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia <
>> mohitanchlia@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-unsubscribe@httpd.apache.org
>> >> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> >> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
Re: [users@httpd] Active Active Data center and stickyness
Posted by Igor Cicimov <ic...@gmail.com>.
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 <mo...@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 <ic...@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 <mo...@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 <bt...@gmail.com> wrote:
> >> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia <
> mohitanchlia@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-unsubscribe@httpd.apache.org
> >> " from the digest: users-digest-unsubscribe@httpd.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Active Active Data center and stickyness
Posted by Mohit Anchlia <mo...@gmail.com>.
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 <ic...@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 <mo...@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 <bt...@gmail.com> wrote:
>> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia <mo...@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-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Igor Cicimov <ic...@gmail.com>.
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 <mo...@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 <bt...@gmail.com> wrote:
> > On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia <mo...@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-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: [users@httpd] Active Active Data center and stickyness
Posted by Mohit Anchlia <mo...@gmail.com>.
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 <bt...@gmail.com> wrote:
> On Mon, Mar 28, 2011 at 10:42 PM, Mohit Anchlia <mo...@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-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Mohit Anchlia <mo...@gmail.com>.
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.
On Mon, Mar 28, 2011 at 5:50 PM, Ben Timby <bt...@gmail.com> wrote:
> On Mon, Mar 28, 2011 at 8:30 PM, Mohit Anchlia <mo...@gmail.com> wrote:
>> Apache 2:
>>
>> We use apache 2 and we have 2 data centers. Problem is that both data
>> centers are active. So if User uploads a file for eg: in site A that
>> User can be directed to site B. Files are kept in sync asynchronously.
>> And it could take as long as 1 hr to bring them in sync on the other
>> data center. Now this presents unique problem as to how to provide
>> user stickyness accross data centers with 2 diff. cluster of nodes
>> each cluster running with nodes only in that data center.
>>
>> I am sending this out in case people have solved it already or have
>> some suggestions on how this can be done.
>
> You don't provide enough information on how you have both data centers
> "active". My guess is that you are using DNS multiple A records, but
> who knows.
>
> If you are using DNS, then my suggestion would be to allow users to visit:
>
> www.myapp.com, which is distributed to both data centers, then after
> login, redirect them to:
>
> dc1.myapp.com
> - or -
> dc2.myapp.com
>
> The downside is there is no automatic fail over, the user would have
> to go back to www.myapp.com and log back in to be redirected to an
> accessible data center. For most cases, this would be acceptable.
>
> Another way to do it is to put an intelligent load balancer at each
> data center. This load balancer would then send connections to it's
> backend servers. You can then configure all the backend servers at
> both data centers into the load balancer. Use sticky connections in
> the load balancer to send the user to the correct backend (perhaps at
> the other data center).
>
> If you have good enough load balancing software, in the case of no
> stickiness, you could prefer the local backend servers over the remote
> ones, avoiding a long hop to the other data center. Also, you can use
> the presence of a cookie to determine stickiness. Then you can stick a
> user to a group of backend servers AFTER they upload something.
> Something like this.
>
> 1. User hits your site.
> 2. They are routed to a random data center.
> 3. They have no association, and thus are routed to a local backend.
> 4. User keeps browsing.
> 5. User performs a POST request to your upload script, it writes a
> cookie to their browser which expires in 1h.
> 6. Subsequent requests hit the load balancer and are routed to the
> preferred backend (where the upload occurred).
> 7. One hour later, the user is released and free to "float" again.
>
> This is probably the best solution as a user will always use the
> shortest path unless there is a reason not to (cookie). It also allows
> you to control the stickiness at the application level, so you can be
> selective. Failover occurs automatically, as the browser will connect
> to a live data center, however, their data may not live there. Such is
> life.
>
> This is not even close to all the options available to you, but these
> are the two simplest ones I could come up with without any specifics.
>
> ---------------------------------------------------------------------
> 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@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Active Active Data center and stickyness
Posted by Ben Timby <bt...@gmail.com>.
On Mon, Mar 28, 2011 at 8:30 PM, Mohit Anchlia <mo...@gmail.com> wrote:
> Apache 2:
>
> We use apache 2 and we have 2 data centers. Problem is that both data
> centers are active. So if User uploads a file for eg: in site A that
> User can be directed to site B. Files are kept in sync asynchronously.
> And it could take as long as 1 hr to bring them in sync on the other
> data center. Now this presents unique problem as to how to provide
> user stickyness accross data centers with 2 diff. cluster of nodes
> each cluster running with nodes only in that data center.
>
> I am sending this out in case people have solved it already or have
> some suggestions on how this can be done.
You don't provide enough information on how you have both data centers
"active". My guess is that you are using DNS multiple A records, but
who knows.
If you are using DNS, then my suggestion would be to allow users to visit:
www.myapp.com, which is distributed to both data centers, then after
login, redirect them to:
dc1.myapp.com
- or -
dc2.myapp.com
The downside is there is no automatic fail over, the user would have
to go back to www.myapp.com and log back in to be redirected to an
accessible data center. For most cases, this would be acceptable.
Another way to do it is to put an intelligent load balancer at each
data center. This load balancer would then send connections to it's
backend servers. You can then configure all the backend servers at
both data centers into the load balancer. Use sticky connections in
the load balancer to send the user to the correct backend (perhaps at
the other data center).
If you have good enough load balancing software, in the case of no
stickiness, you could prefer the local backend servers over the remote
ones, avoiding a long hop to the other data center. Also, you can use
the presence of a cookie to determine stickiness. Then you can stick a
user to a group of backend servers AFTER they upload something.
Something like this.
1. User hits your site.
2. They are routed to a random data center.
3. They have no association, and thus are routed to a local backend.
4. User keeps browsing.
5. User performs a POST request to your upload script, it writes a
cookie to their browser which expires in 1h.
6. Subsequent requests hit the load balancer and are routed to the
preferred backend (where the upload occurred).
7. One hour later, the user is released and free to "float" again.
This is probably the best solution as a user will always use the
shortest path unless there is a reason not to (cookie). It also allows
you to control the stickiness at the application level, so you can be
selective. Failover occurs automatically, as the browser will connect
to a live data center, however, their data may not live there. Such is
life.
This is not even close to all the options available to you, but these
are the two simplest ones I could come up with without any specifics.
---------------------------------------------------------------------
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@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org