11:03 a.m.
Hi all,
One of JBoss Cloud users asked me about possible clustering of our
front-end appliances. This in real is the question: can we have
multiple mod_cluster instances that share state between them?
If this is possible how I can configure it? If this is not possible
now, is it maybe in roadmap?
This could greatly enhance HA of web clusters. How? For example we
have an Elastic Load Balancer in Amazon. It doesn't support sticky
sessions and it just forwards requests to selected instances. If we
could for example forward it to two our clustered front-end appliances
we could achieve great failover.
Thoughts?
--Marek
11:39 a.m.
This doesn't work currently, as the apache mod-cluster instances don't
exchange information about their states, e.g. which sticky session is
routed to which worker.
No wait, I guess I'm wrong: they don't need to !
Say we have Apaches A1 and A2, and workers W1, W2 and W3.
If a client request hits A2 and A2 creates a new session on W3, then the
session id is going to be SESSION.W3. When the same client now hits A1,
A1 should actually also route the request to W3 ! This of course assumes
that all workers have registered with all Apache daemons.
So IMO we don't even need to exchange routing information between the
Apache daemons... can someone confirm this ?
This is with sticky session. If you turn this off, you can pick any
Apache to route your request, and the route will be different every
time. In this case, you'd have to use synchronous replication to prevent
potentially stale data between 2 requests for the same session going to
different workers.
With Infinispan and DIST, stale data shouldn't be an issue as the
routing is always based on the content (keys to be accesssed) rather
than a client's identity (session-id), and L1 caches should make things
fast, so data doesn't have to be fetched by one worker from another one.
Marek Goldmann wrote:
Hi all,
One of JBoss Cloud users asked me about possible clustering of our
front-end appliances. This in real is the question: can we have
multiple mod_cluster instances that share state between them?
If this is possible how I can configure it? If this is not possible
now, is it maybe in roadmap?
This could greatly enhance HA of web clusters. How? For example we
have an Elastic Load Balancer in Amazon. It doesn't support sticky
sessions and it just forwards requests to selected instances. If we
could for example forward it to two our clustered front-end appliances
we could achieve great failover.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
11:48 a.m.
On Oct 21, 2009, at 11:39 AM, Bela Ban wrote:
This doesn't work currently, as the apache mod-cluster instances
don't exchange information about their states, e.g. which sticky
session is routed to which worker.
No wait, I guess I'm wrong: they don't need to !
Say we have Apaches A1 and A2, and workers W1, W2 and W3.
If a client request hits A2 and A2 creates a new session on W3, then
the session id is going to be SESSION.W3. When the same client now
hits A1, A1 should actually also route the request to W3 ! This of
course assumes that all workers have registered with all Apache
daemons.
Yes, I'm assuming that.
So IMO we don't even need to exchange routing information between
the Apache daemons... can someone confirm this ?
Good catch, I'll try this today and will let you know!
This is with sticky session. If you turn this off, you can pick any
Apache to route your request, and the route will be different every
time. In this case, you'd have to use synchronous replication to
prevent potentially stale data between 2 requests for the same
session going to different workers.
Yes, we're talking about sticky sessions only, because those who don't
want to have sticky sessions, don't want sessions at all, I think. In
other words if I care about sessions, I want to have sticky sessions
too, otherwise I'm not interested in sticky sessions. Am I wrong?
--Marek
With Infinispan and DIST, stale data shouldn't be an issue as the
routing is always based on the content (keys to be accesssed) rather
than a client's identity (session-id), and L1 caches should make
things fast, so data doesn't have to be fetched by one worker from
another one.
Marek Goldmann wrote:
> Hi all,
>
> One of JBoss Cloud users asked me about possible clustering of our
> front-end appliances. This in real is the question: can we have
> multiple mod_cluster instances that share state between them?
>
> If this is possible how I can configure it? If this is not possible
> now, is it maybe in roadmap?
>
> This could greatly enhance HA of web clusters. How? For example we
> have an Elastic Load Balancer in Amazon. It doesn't support sticky
> sessions and it just forwards requests to selected instances. If we
> could for example forward it to two our clustered front-end
> appliances
> we could achieve great failover.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
11:52 a.m.
On 10/21/2009 11:39 AM, Bela Ban wrote:
This doesn't work currently, as the apache mod-cluster instances
don't
exchange information about their states, e.g. which sticky session is
routed to which worker.
No wait, I guess I'm wrong: they don't need to !
Say we have Apaches A1 and A2, and workers W1, W2 and W3.
If a client request hits A2 and A2 creates a new session on W3, then the
session id is going to be SESSION.W3. When the same client now hits A1,
A1 should actually also route the request to W3 ! This of course assumes
that all workers have registered with all Apache daemons.
So IMO we don't even need to exchange routing information between the
Apache daemons... can someone confirm this ?
Yep. It will work that way.
Cheers
Jean-Frederic
12:02 p.m.
On 10/21/2009 11:48 AM, Marek Goldmann wrote:
Yes, we're talking about sticky sessions only, because those who
don't
want to have sticky sessions, don't want sessions at all, I think. In
other words if I care about sessions, I want to have sticky sessions
too, otherwise I'm not interested in sticky sessions. Am I wrong?
If you don't have sessions you can't have sticky logic with mod_cluster.
Cheers
Jean-Frederic
4:56 p.m.
On 10/21/2009 04:48 AM, Marek Goldmann wrote:
On Oct 21, 2009, at 11:39 AM, Bela Ban wrote:
> This doesn't work currently, as the apache mod-cluster instances
> don't exchange information about their states, e.g. which sticky
> session is routed to which worker.
>
> No wait, I guess I'm wrong: they don't need to !
>
> Say we have Apaches A1 and A2, and workers W1, W2 and W3.
>
> If a client request hits A2 and A2 creates a new session on W3, then
> the session id is going to be SESSION.W3. When the same client now
> hits A1, A1 should actually also route the request to W3 ! This of
> course assumes that all workers have registered with all Apache
> daemons.
Yes, I'm assuming that.
> So IMO we don't even need to exchange routing information between
> the Apache daemons... can someone confirm this ?
Yes, the routing information is encapsulated in the session id.
Otherwise mod_jk/cluster could never have been HA since the load
balancer would always be a single point of failure.
Good catch, I'll try this today and will let you know!
> This is with sticky session. If you turn this off, you can pick any
> Apache to route your request, and the route will be different every
> time. In this case, you'd have to use synchronous replication to
> prevent potentially stale data between 2 requests for the same
> session going to different workers.
Yes, we're talking about sticky sessions only, because those who don't
want to have sticky sessions, don't want sessions at all, I think. In
other words if I care about sessions, I want to have sticky sessions
too, otherwise I'm not interested in sticky sessions. Am I wrong?
Whenever asked I always say you have to use sticky sessions. Even with
synchronous replication. See
http://www.jboss.org/community/wiki/WebClusteringBestPractices for
further discussion of why that's necessary.
--Marek
> With Infinispan and DIST, stale data shouldn't be an issue as the
> routing is always based on the content (keys to be accesssed) rather
> than a client's identity (session-id), and L1 caches should make
> things fast, so data doesn't have to be fetched by one worker from
> another one.
>
>
>
> Marek Goldmann wrote:
>> Hi all,
>>
>> One of JBoss Cloud users asked me about possible clustering of our
>> front-end appliances. This in real is the question: can we have
>> multiple mod_cluster instances that share state between them?
>>
>> If this is possible how I can configure it? If this is not possible
>> now, is it maybe in roadmap?
>>
>> This could greatly enhance HA of web clusters. How? For example we
>> have an Elastic Load Balancer in Amazon. It doesn't support sticky
>> sessions and it just forwards requests to selected instances. If we
>> could for example forward it to two our clustered front-end
>> appliances
>> we could achieve great failover.
>
> --
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss
_______________________________________________
mod_cluster-dev mailing list
mod_cluster-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/mod_cluster-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
5293
days inactive
5293
days old
mod_cluster-dev@lists.jboss.org
5 comments
4 participants
participants (4)
-
Bela Ban -
Brian Stansberry -
jean-frederic clere -
Marek Goldmann