Cell affinity when an ODR fails
The cell affinity function allows us to configure unbridged, multi-cell, on demand router (ODR) topologies that preserve sessions even in the event of ODR outages.
The following diagram displays a request/response flow scenario. In this scenario, the browser sends an in-session request to the IBM HTTP server. The IBM HTTP server determined that it cannot forward the request to the original ODR 1.1. Instead, the IBM HTTP server 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.
The IBM HTTP server 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.
The following diagram illustrates a request/response flow scenario in which a browser sends an in-session request to the IBM HTTP Server.
Related tasks