A função de afinidade da célula permite configurar topologias de várias células não vinculadas do On Demand Router (ODR) que preservam sessões mesmo no caso de interrupções do ODR. Este
diagrama de topologia mostra o pedido de afinidade de célula/fluxo de resposta quando um
pedido do servidor HTTP IBM deve ser enviado a um ODR que não está no caminho da sessão
original, porque o ODR original se tornou não-funcional
Um cenário que apresenta um fluxo de pedido/resposta é mostrado no seguinte diagrama. Neste
cenário, o navegador enviou um pedido in-session ao servidor HTTP IBM. O servidor HTTP
IBM determinou que ele não pode encaminhar o pedido ao ODR 1.1 original, então
alternativamente ele optou por encaminhar o pedido ao ODR 2.1 (normalmente, isto
interromperia a sessão).
As setas sólidas no diagrama representam os pedidos, enquanto que as setas quebradas representam as respostas. Os fluxos são explicados a seguir no seguinte sequência:
- O navegador envia um pedido ao servidor HTTP IBM. O ODR1.1 não está funcionando.
Em uma tentativa de failover, o Servidor HTTP IBM é roteado para ODR2.1.
- O ODR2.1 nota que o pedido foi destinado originalmente para o ODR1.1, portanto, o ODR2.1 localiza um cluster de servidor genérico que contém o ODR 1.1 e é roteado novamente para um ODR ativo dentro do cluster do servidor genérico, a saber. ODR 1.2.
- O ODR1.2 marca esta sessão para adoção durante o processamento da resposta e encaminha o pedido para o cluster de destino de backend original.
O servidor HTTP IBM pode rotear diretamente ao ODR 1.2 após detectar que o ODR 1.1
falhar. Nesse caso, o ODR 1.2 encaminhará o pedido para o cluster de destino de backend correto e adotará a sessão durante o processamento da resposta, conforme descrito anteriormente no nº 3 e no nº 4.
O diagrama a seguir ilustra um cenário de fluxo de pedido/resposta no qual um navegador envia um pedido em sessão para o Servidor HTTP IBM.
