Cell affinity when an ODR fails
The cell affinity function allows configuration of unbridged, multi-cell, on demand router topologies that preserve sessions even in the event of ODR outages.
In the following request/response flow scenario the browser sends an in-session request to the IBM HTTP server. IHS determined that it cannot forward the request to the original ODR 1.1. Instead, IHS forwards the request to ODR 2.1 (typically, this action breaks the session). The solid arrows in the diagram represent requests, whereas the broken arrows represent responses. The flows are explained in the following sequence:
- The browser sends a request to IBM HTTP server.
ODR 1.1 is not functioning. In an attempt to failover, IBM HTTP Server routes to ODR 2.1.
- ODR 2.1 notes that the request was originally destined for ODR 1.1, so ODR 2.1 finds a generic server cluster containing ODR 1.1, and routes back to an active ODR within the generic server cluster, namely, ODR 1.2.
- ODR 1.2 marks this session for adoption during response processing and forwards the request to the original back-end target cluster.
- Because ODR 1.2 adopted the session, it sets a cookie which causes the next request (#4) to be sent directly to it rather than to ODR 2.1.
IHS can route directly to ODR 1.2 after detecting that ODR 1.1 failed. In this case, ODR 1.2 forwards the request to the correct back-end target cluster and adopts the session during response processing as described in #3 and #4 previously.
