[
https://issues.jboss.org/browse/WFLY-6944?page=com.atlassian.jira.plugin....
]
Paul Ferraro updated WFLY-6944:
-------------------------------
Description:
Currently, session affinity is specified as a single route, usually the primary owner of a
session. However, if this node is not active (from the load balancer's perspective),
then the load balancer will select another node of its choosing. This is less than ideal,
since some nodes are more optimal than others. Better is to expression session affinity
as an ordered list of nodes. The load balancer can then choose the 1st node in the list
that is active, and cascade on failures accordingly. From the server's perspective,
the affinity list should have the following order:
1. The primary owner
2. Any backup owners
3. The local node (if the local node is not an owner)
There are a couple of ways a load balancer can indicate that it supports multiple routes.
1. Static configuration, e.g. routing="OWNER|LOCAL|RANKED"
2. Adding an HTTP header to a proxied request, which can be detected by the server
handling the request
#1 has the advantage of simplicity - but requires that users manually apply this
configuration to gain optimal performance. This would also let us allow users (for even
the single node affinity case) to toggle between local affinity or primary owner affinity,
or even no routing.
#2 has the advantage of applying this optimization automatically, but incurs the cost of
an additional header to every request
was:
Currently, session affinity is specified as a single route, usually the primary owner of a
session. However, if this node is not active (from the load balancer's perspective),
then the load balancer will select another node of its choosing. This is less than ideal,
since some nodes are more optimal than others. Better is to expression session affinity
as an ordered list of nodes. The load balancer can then choose the 1st node in the list
that is active, and cascade on failures accordingly. From the server's perspective,
the affinity list should have the following order:
1. The primary owner
2. Any backup owners
3. The local node (if the local node is not an owner)
There are a couple of ways a load balancer can indicate that it supports multiple routes.
1. Static configuration
2. Adding an HTTP header to a proxied request, which can be detected by the server
handling the request
#1 has the advantage of simplicity - but requires that users manually apply this
configuration to gain optimal performance. This would also let us allow users (for even
the single node affinity case) to toggle between local affinity or primary owner affinity,
or even no routing.
#2 has the advantage of applying this optimization automatically, but incurs the cost of
an additional header to every request
Encode session affinity using multiple routes, if supported by the
load balancer
--------------------------------------------------------------------------------
Key: WFLY-6944
URL:
https://issues.jboss.org/browse/WFLY-6944
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Currently, session affinity is specified as a single route, usually the primary owner of
a session. However, if this node is not active (from the load balancer's
perspective), then the load balancer will select another node of its choosing. This is
less than ideal, since some nodes are more optimal than others. Better is to expression
session affinity as an ordered list of nodes. The load balancer can then choose the 1st
node in the list that is active, and cascade on failures accordingly. From the
server's perspective, the affinity list should have the following order:
1. The primary owner
2. Any backup owners
3. The local node (if the local node is not an owner)
There are a couple of ways a load balancer can indicate that it supports multiple
routes.
1. Static configuration, e.g. routing="OWNER|LOCAL|RANKED"
2. Adding an HTTP header to a proxied request, which can be detected by the server
handling the request
#1 has the advantage of simplicity - but requires that users manually apply this
configuration to gain optimal performance. This would also let us allow users (for even
the single node affinity case) to toggle between local affinity or primary owner affinity,
or even no routing.
#2 has the advantage of applying this optimization automatically, but incurs the cost of
an additional header to every request
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)