Replicando Sessões do SIP

É possível configurar um domínio de replicação para sessões do SIP se você deseja que as informações de replicação de sessão e de estado do diálogo ocorram durante o processamento típico do Session Initiation Protocol (SIP). O contêiner SIP geralmente utiliza o DRS (Data Replication Service) para replicar todas as informações de estado. Como o DRS não fornece uma maneira de confirmar quando a replicação de dados foi concluída, a única coisa que pode ser quantificada é quando uma parte das informações de estado é enfileirada para replicação. Dentro deste tópico, referências à replicação de dados significa apenas que os dados foram enfileirados para replicação.

Sobre Esta Tarefa

O contêiner SIP replica vários tipos diferentes de informações. Esses dados cabem em duas categorias gerais:
  • Informações de estado de contêiner SIP interno associadas ao diálogo.
  • Informações de estado de aplicativos associadas a diversos objetos de sessão.

Cada uma dessas categorias inclui vários tipos de dados diferentes, que são descritos posteriormente neste tópico. Cada objeto de dados é tratado de forma independente. Portanto, uma alteração em um objeto de sessão do aplicativo, que causa uma replicação, não resulta na replicação de nenhuma informação de estado interno.

Replicação das informações de estado interno

As informações de estado interno podem ser definidas como qualquer coisa relacionada ao estado de um diálogo que está sendo manipulado pelo contêiner. Isso inclui algo como cseq, estado do diálogo (inicial, antecipado, confirmado, terminado), expiração de sessão, parte local, remota etc. As informações de estado interno só são replicadas devido à existência de um diálogo. Portanto, nenhum dado relacionado ao SIP interno será replicado até que o diálogo ao qual está associado seja estabelecido. Os tipos de pedidos SIP que podem provocar a criação de um diálogo incluem:
  • INVITE
  • SUBSCRIBE
  • REFER
A replicação do estado interno acontece em pontos previsíveis bem-definidos no fluxo de chamada. Por exemplo, um diálogo é estabelecido no contêiner somente quando uma resposta 2xx ou uma resposta 1xx com uma tag “To” é recebida ou enviada devido a um dos tipos de método listados anteriormente. Os eventos que podem acionar uma replicação de estado interno incluem:
  • Criação de um novo diálogo SIP
  • Expiração de uma sessão devido a um tempo limite de sessão
  • Envio de uma resposta final a um UAC
  • Criação de uma URI codificada
  • Manipulação de qualquer mensagem que resulte em uma alteração do estado de diálogo interno

E importante observar que o estado da transação não é replicado na versão 6.1 do WebSphere Application Server 6.1 do contêiner SIP, somente o estado de diálogo. Não replicar estado de transação reduz a carga em todos os servidores do domínio de replicação, mas pode provocar problemas nas falhas que acontecem no meio de uma transação (por exemplo, perda de algumas mensagens SIP relacionadas ao diálogo).

Uma importante diferença entre um B2BUA e um aplicativo proxy é o número de objetos de sessão criados e replicados. Em ambos os casos apenas uma única sessão de replicação é criada, mas para B2BUA, dois objetos de sessão são criados: um para a fase de entrada e um para a fase de saída. Para obter um aplicativo proxy, apenas um único objeto de sessão é criado.

Replicação de Informações de Estado do Aplicativo

As informações do estado do aplicativo são tratadas de forma diferente das informações do estado de diálogo interno porque não dependem da existência de um diálogo para ser replicado. O estado do aplicativo se refere a qualquer dado que estiver sendo mantido pelo aplicativo por meio do uso das construções de dados JSR 116. Isso inclui:
  • javax.servlet.sip.SipApplicationSession
  • javax.servlet.sip.SipSession
  • javax.servlet.sip.ServletTimer
  • Qualquer atributo configurado em SipSession ou em SipApplicationSession
A replicação do estado interno acontece em pontos previsíveis bem definidos no fluxo de chamada, enquanto a replicação do estado do aplicativo é menos previsível porque geralmente depende de quando um aplicativo cria, invalida ou modifica os dados de sessão e cronômetros por meio de APIs JSR 116. Isso poderia ser atribuído ao processamento de uma mensagem de entrada ou à expiração de um cronômetro SIP. Todos os eventos a seguir podem provocar a replicação dos dados da sessão relacionados ao aplicativo:
  • Criação de um objeto de sessão de aplicativos
  • Criação de um objeto de sessão SIP
  • Criação de um cronômetro de sessão SIP
  • Modificação de um objeto de sessão por meio do setAttribute ou do removeAttribute
  • Invalidação de um objeto de sessão SIP
  • Expiração de um cronômetro de sessão
  • Código do aplicativo enviando uma solicitação 1

A replicação pode ocorrer para pedidos que não estabelecem um diálogo, se um aplicativo chamar request.getApplicationSession(true) e se addTimer() e/ou addAttribute() forem chamados no objeto de sessão de aplicativos resultantes. Isso é necessário para que um listener possa ser chamado quando o cronômetro expirar.

Considerações sobre Configuração de Replicação e Failover SIP

Um cluster SIP que requer a replicação e o failover pode consistir em vários domínios de replicação, sendo que cada um contém um conjunto de contêineres SIP. Não há um conjunto de limites no número de contêineres em um cluster. Por motivos de desempenho, cada domínio de replicação deve conter apenas dois contêineres.

O domínio de replicação deve ser configurado para o Domínio Inteiro, o que indica que o estado é replicado para todos os contêineres no domínio de replicação. O modo de replicação deve ser Tanto de cliente como de servidor.

A sessão distribuída para um contêiner precisa ser configurada para a replicação Memória-a-Memória. Todos os aplicativos que precisam de replicação de sessão devem incluir a tag <distributable /> nos arquivos web.xml e sip.xml. Tanto SIP como HTTP utilizarão a mesma topologia da replicação

[z/OS]Certifique-se de que o seu sistema esteja configurado de tal modo que:
  • O seu sistema inclua pelo menos 2 controladores e cada controlador tenha pelo menos 2 servidores para propósitos de failover e de recuperação.
  • A carga de trabalho total, que inclui chamadas de operação normais, chamadas de failover e chamadas de recuperação nunca deve exceder a taxa de chamada máxima.
    Para atingir o número máximo de chamadas por segundo, as seguintes definições de configuração são necessárias:
    • Você está executando em um sistema z/OS Versão 1 Release 10 com High Performance FICON para System z (zHPF) ativado para E/S rápida. Um DS8000 DASD também deve estar sendo executado nesse sistema.
    • As definições de tamanho do conjunto de dados temporários e do fluxo de logs utilizadas ao criar os fluxos de logs devem ser iguais ou maiores que 256 Megabytes (LS_SIZE(64000) STG_SIZE(64000)).

    É possível determinar a taxa máxima de chamada aumentando progressivamente as taxas de chamada durante certo tempo e monitorando o desempenho até que taxas toleráveis de tempo limite sejam atingidas.

  • A quantidade total de dados propagados em todas as chamadas ativas não excede 2 GB.
  • Todos os nós estão no nível de Versão 7.0.0.7 ou posterior antes de ativar o trabalho de SIP ou de Communications Enabled Applications (CEA) no z/OS.
  • Outros serviços que requerem persistência de dados, como transações e compensações são configurados para usar criação de log de arquivo de HFS se você planeja usar seu sistema para trabalho relacionado a SIP ou CEA. Após configurar seu sistema para trabalho relacionado a SIP ou CEA, outros serviços que requerem persistência de dados não podem usar fluxos de logs.
[z/OS]Você também deve excluir e recriar o fluxo de logs para um servidor se ocorrer alguma das seguintes situações:
  • Todos os controladores dentro de um cluster falham ao mesmo tempo. Nessa situação, alguns dos dados necessários para executar a recuperação são perdidos devido às diversas falhas simultâneas.
  • Ocorre uma falha durante o processo de recuperação. Nessa situação, o fluxo de logs associado com as sessões com falha contém dados incompletos.
Topologia de Replicação da Sessão SIP
  • Cada membro replica todos os dados de estado a cada nível igual em seu domínio de replicação.
  • O ideal é que cada domínio contenha dois servidores.
  • Quando ocorrer uma falha, o coordenador do grupo principal informa aos membros restantes do grupo principal quais sessões replicadas ativar. Essas sessões replicadas tornam-se então parte de suas sessões ativas.

Conclua as seguintes etapas para configurar um domínio de replicação para sessões do SIP.

Procedimento

  1. No console administrativo, clique em Ambiente > Domínios de replicação > Novo
  2. Clique em Número de Réplicas e, em seguida, selecione Domínio Inteiro.
  3. Na seção Configurações do Contêiner, clique em Gerenciamento de Sessões.
  4. Na seção Propriedades Adicionais, clique em Configurações do Ambiente Distribuído e, em seguida, clique em Replicação Memória-a-Memória.
  5. Defina Modo de Replicação como Cliente e Servidor.
  6. Salve suas alterações.

Resultados

A replicação memória-a-memória está ativada para as sessões do SIP.

1 Causa a replicação da SipSession e da SipApplicationSession para sincronizar o "registro de data e hora do último acesso" com os contêineres no mesmo nível no cluster. Isso destina-se à integridade de futuras chamadas para SipSession.getLastAccessedTime() e SipApplicationSession.getLastAccessedTime()

Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsip_sessionrep
Nome do arquivo: tsip_sessionrep.html