セル・アフィニティー機能を使用すると、オンデマンド・ルーター (ODR) の障害が起こった場合でも、セッションを保存できるように、ブリッジされていないオンデマンド・ルーター (ODR) トポロジーを構成できます。この機能を使用すると、ODR がセッション中トラフィックで、間違ってルーティングされたトラフィックを受信すると、元のセルで動作している ODR に戻るように再ルーティングするような、トポロジーを構成できます。このように、複数のセルの ODR にルーティングしても、なおセッション・アフィニティーを維持できるよう、IBM HTTP Server を構成することができます。
セル・アフィニティー機能を使用すると、複数のブリッジされていないセルに複数の ODR がある場合に、ロード・バランシングかフェイルオーバーのいずれかにより、セッション・トラフィックを複数の ODR に転送するよう IBM HTTP Server が構成されている場合は、セッションの消失を防止できます。例えば、ODR が IBM HTTP Server とバックエンド・アプリケーション・サーバーの間に配置されているようなネットワーク構成では、IBM HTTP Server は、その ODR を認識し、それにルーティングするように構成されているので、セッション中のトラフィックに含まれる JSESSIONID Cookie で識別されたサーバーを認識できません。 このように一般的に IBM HTTP Server は、異なる ODR を選択し、セッション要求を分散します。 IBM HTTP Server がホスティング・アプリケーション・サーバーと同じセル内のルーターを選択した場合、またはアプリケーション・サーバーがすべて共通データベースによってセッション・データを共有する場合、セッションが失われるリスクは考える必要がありません。ただし、セル・アフィニティーがないと、IBM HTTP Server が別のセル内の ODR を選択した場合、ODR はサーバー ID を認識せず、要求のルーティング方法がわからないので、セッションは失われます。
セル・アフィニティー機能には、2 つの特徴があります。最初の特徴とは、IBM HTTP Server は、セッション確立後、特定の ODR のアフィン変換を行うか、常にその ODR にルーティングできるということです。特定の ODR を通じたセッション・アフィニティーを維持するように IBM HTTP Server を構成するには、 セル・アフィニティーを使用可能にし、plugin-cfg.xml を作成して、その plugin-cfg.xml を IBM HTTP Server に移してから、そのサーバーを再始動します。作成された plugin-cfg.xml は、IBM HTTP Server プラグインに、そのセッション ID として ODRSESSIONID Cookie を使用するように指示します。これにより、ODR にセッション・アフィニティーが使用可能になります。
セル・アフィニティーのもう 1 つの特徴は、間違ってルーティングされたトラフィックを正しいセルに送るために、セル境界をまたいでセッション・トラフィックをルーティングできるということです。そのようにするためには、セル・アフィニティーを使用可能にするだけでなく、ODR がトラフィックを受信する各セルに対して汎用サーバー・クラスター (GSC) を構成する必要があります。こうした GSC のメンバーは、それらのリモート・セル内の ODR である必要があります。 ODR が間違ってルーティングされたセッション・トラフィックを受信し、セル・アフィニティーが使用可能になっている場合、ODR は、GSC のリストを参照して、ODR セッション ID で識別された ODR が見つかるかどうかを確認します。一致が見つかると、ODR は、一致が含まれる GSC にトラフィックを再ルーティングします。 再ルーティングが成功した場合、最後の ODR がセッションを選択し、ユーザーのセッションに対する適切なバックエンド・サーバーにトラフィックをルーティングします。