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 IHS 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 IHS. The IHS 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 IHS. 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 response of the back-end target cluster returns to the IHS
via ODR1.2, ODR1.2 adopts the session by placing its own server ID
on the ODRSESSIONID, and ODR2.1. The next request for the session
described in the previous flow will be forwarded to ODR 1.2.
The IHS 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.
