Afinidade de Sessão e Failover SIP
O SIP no WebSphere fornece a afinidade de sessão e failover.
- Afinidade de Sessão SIP
Um único contêiner SIP em um cluster manipulará todas as mensagens associadas a um único diálogo. Se um contêiner falhar no meio de um diálogo, um único servidor no cluster assumirá a responsabilidade pelo diálogo. É responsabilidade do proxy do SIP manter a afinidade de sessão com base no identificador de sessão (que inclui o nome do servidor lógico). As informações do servidor lógico são publicadas pelo contêiner SIP e consumidas pelo proxy SIP por meio do WLM (Workload Management System).
- Roteando Mensagens SIP com base no ID de Sessão
O ibmsid é incorporado em várias mensagens SIP e é utilizado para rotear para sessões específicas em execução no servidor de aplicativos SIP. De forma geral, os cabeçalhos VIA sempre são utilizados para rotear respostas. O contêiner sempre irá incorporar um ibmsid no VIA associado ao servidor de aplicativos SIP. A seguir, um exemplo desse cabeçalho VIA:
Via: SIP/2.0/UDP 9.51.252.69:5063;ibmsid=sipcontainer1.1153242645968.4_2_2;branch=z9hG4bK920196437955379
Para aplicativos proxy, o ibmsid (ou ID de sessão) é inserido no pedido inicial recebido do UAC no Record-Route. O UAS retorna o mesmo Record-Route com o ID de sessão na resposta. O UAC retorna o cabeçalho Route com o ID de sessão no pedido subsequente no diálogo. Por Exemplo:
Neste exemplo, o UAS retorna o mesmo Record-Route com o ID de sessão na resposta e o UAC retorna o cabeçalho do Route com o ID de sessão no pedido subsequente no diálogo.Record-Route: <sip:protocol2.databeam.com:5060;transport=udp;ibmsid=sipcontainer1a.1138119214953.4_2_2;lr>
Para aplicativos UAC e UAS, o contêiner que estiver agindo como UAC ou UAS inserirá o ID de Sessão na tag To (UAS) ou na tag From (UAC) (por exemplo, tag To local.1132518053302_2_2). A mesma tag To ou From é incluída no pedido subsequente.
As URIs codificadas também conterão um ibmappid (muito semelhante a um ibmsid), que poderá, então, ser enviado no pedido de HTTP subsequente. Um ponto importante aqui é que a infraestrutura IBM SIP não suporta o failover de nível de transação. Ela suporta apenas o failover de diálogo para chamadas estáveis.
A seguir são apresentadas as regras gerais de como a infraestrutura IBM SIP decide qual endereço utilizar para cabeçalhos de contato que incorpora nas mensagens SIP de saída:- Um servidor de aplicativos SIP independente usará seu próprio endereço em cabeçalhos de contato que precisa inserir nas mensagens SIP.
- Um servidor de aplicativos SIP que defronta um proxy SIP sem preservação de estado utilizará o endereço do proxy SIP nos cabeçalhos de contato que precisa inserir nas mensagens SIP. O servidor de aplicativos SIP descobre esse endereço por meio do WLM.
- Um servidor de aplicativos SIP que defronta um proxy SIP sem preservação de estado, que defronta, em seguida, um sprayer IP utilizará o endereço do sprayer IP nos cabeçalhos de contato que precisa inserir nas mensagens SIP. O endereço do sprayer IP deve ser configurado no proxy SIP por meio do console administrativo e esse endereço será publicado no servidor de aplicativos SIP por meio do UCF.
- Failover no Meio de uma Chamada
Quando um servidor falha, as sessões associadas ao servidor que falhou são ativadas nos contêineres restantes no domínio de replicação. Uma vez ativos, os contêineres que manipulam as sessões que falharam publicam o local da sessão nos servidores proxy que estão enfrentando o cluster através do WLM. Quando uma mensagem associada a um dos diálogos que falharam chega no proxy, o proxy pega o ID de sessão da mensagem SIP e o utiliza para consultar o novo contêiner. Quando o servidor que falhou é reiniciado, ele é incluído novamente no cluster. Ele irá, então, manipular apenas os diálogos criados recentemente.
Figura 1. Failover do Contêiner SIP em um Cluster (Antes)Figura 2. Failover do Contêiner SIP em um Cluster (Após)- Aplicativos e Failover Convergidos
Todas as mensagens associadas a uma Sessão HTTP/SIP convergida são roteadas pelo proxy para o mesmo contêiner de backend utilizando a afinidade de sessão de URIs e SIP codificada. O HTTP e o SIP utilizam a mesma topologia de replicação (eles compartilham as mesmas configurações de replicação). Se ocorrer uma falha, os pedidos HTTP e SIP associados a um diálogo que falhou serão roteados para o mesmo servidor de backend novo. Cookies Jsession têm precedência sobre URIs Codificados no proxy quando os destinos de afinidade estão sendo determinados.
Figura 3. Exemplo de Aplicativo Convergido