The cell affinity function enables you to configure unbridged,
multi-cell, on demand router (ODR) topologies that preserve sessions
even in the event of ODR outages. This topology diagram shows the
cell affinity request/response flow when an IBM HTTP server request
must be sent to an ODR which is not on the original session path,
because the original ODR has become non-functional
A scenario featuring a request/response flow is shown in the following
diagram. In this scenario, the browser has sent an in-session request
to the IBM HTTP server. The IBM HTTP server has determined it cannot
forward the request to the original ODR 1.1, so it has chosen to forward
the request to ODR 2.1 instead (normally, this would break the session).
The solid arrows in the diagram represent requests, whereas the broken
arrows represent responses. The flows are explained below in the following
sequence:
- The browser sends a request to IBM HTTP server. ODR1.1 is not
functioning. In an attempt to failover, IBM® HTTP
Server routes to ODR2.1.
- ODR2.1 notes that the request was originally destined for ODR1.1,
so ODR2.1 finds a generic server cluster generic server cluster containing
ODR 1.1, and routes back to an active ODR within the generic server
cluster, namely. ODR 1.2.
- ODR1.2 marks this session for adoption during response processing
and forwards the request to the original back-end target cluster.
The IBM HTTP server could route directly to ODR 1.2 after detecting
that ODR 1.1 failed. In this case, ODR 1.2 would forward the request
to the correct back-end target cluster and adopts the session during
response processing as described in #3 and #4 previously.
The following diagram illustrates a request/response flow scenario
in which a browser sends an in-session request to the IBM HTTP Server.