Réplica de sesiones de SIP
Puede configurar un dominio de réplica para sesiones SIP si desea que la réplica de sesiones y la información de estado de diálogo que se producen durante el proceso típico de SIP (Session Initiation Protocol). El contenedor SIP normalmente utiliza el servicio de réplica de datos (DRS) para duplicar toda la información de estado. DRS no proporciona ninguna forma de confirmar cuando finaliza el duplicado de datos, por lo que la única forma que puede cuantificarse es que una parte de la información de estado está en la cola para la réplica. En este tema, las referencias a la réplica de datos sólo significa que los datos se han colocado en la cola para su réplica.
Acerca de esta tarea
- La información de estado de contenedor SIP interna asociada al diálogo.
- La información de estado de aplicación asociada a los diversos objetos de sesión.
Cada categoría incluye varios tipos de datos que se describen más adelante en este tema. Cada objeto de datos se trata de forma independiente. Por lo que un cambio en un objeto de sesión de aplicación que cause una réplica, no da como resultado la réplica de información de estado interna.
Réplica de información de estado interna
- INVITE
- SUBSCRIBE
- REFER
- Creación de un nuevo diálogo SIP
- Caducidad de una sesión debido a que se ha excedido el tiempo de espera de sesión
- El envío de una respuesta final a un UAC
- Creación de un URI codificado
- Manejo de cualquier mensaje que provoque un cambio del estado de diálogo interno
Es importante tener en cuenta que el estado de transacción no se duplica en la versión del contenedor SIP de WebSphere Application Server 6.1, sólo el estado de diálogo. Al no duplicar el estado de transacción se reduce la carga en todos los servidores del dominio de réplica, pero puede causar problemas en las anomalías que ocurren en medio de una transacción (por ejemplo, la pérdida de algunos mensajes SIP relacionados con el diálogo).
Una diferencia importante entre un B2BUA y una aplicación de proxy es el número de objetos de sesión creados y duplicados. En los dos casos sólo se crea una sola sesión de aplicación, pero para el B2BUA, se crean dos objetos de sesión, uno para el tramo de entrada y uno para el tramo de salida. Para una aplicación de proxy, sólo se crea un objeto de sesión.
Duplicación de información de estado de aplicación
- javax.servlet.sip.SipApplicationSession
- javax.servlet.sip.SipSession
- javax.servlet.sip.ServletTimer
- Cualquier atributo establecido en SipSession o SipApplicationSession
- Creación de un objeto de sesión de aplicación
- Creación de un objeto de sesión SIP
- Creación de un temporizador de sesión SIP
- Modificación de un objeto de sesión a través de setAttribute o removeAttribute
- Anulación de un objeto de sesión SIP
- Caducidad de un temporizador de sesión
- El código de la aplicación que envía una solicitud 1.
La réplica puede producirse para solicitudes que no establecen un diálogo si una aplicación llama a request.getApplicationSession(true) y si se llama a addTimer() y/o a addAttribute() en el objeto de sesión de aplicación que resulta. Esto es necesario para que poder llamar al escucha cuando caduque el temporizador.
Consideraciones sobre la configuración de la réplica y migración tras error SIP
Un clúster SIP que requiere réplica y migración tras error puede estar formado por muchos dominios de réplica y cada uno contiene un conjunto de contenedores SIP. No hay ningún límite establecido en el número de contenedores en un clúster. Por razones de rendimiento, cada dominio de réplica sólo debe contener dos contenedores.
Se debe establecer el dominio de réplica en Todo el dominio, lo que significa que el estado se duplica a todos los contenedores en el dominio de réplica. La modalidad de réplica debe ser ambos, cliente y servidor.
La sesión distribuida para un contenedor necesita establecerse en réplica de memoria a memoria. Todas las aplicaciones que requieren réplica de sesión deben incluir el código <distributable/> en los archivos web.xml y sip.xml. Tanto SIP como HTTP utilizarán la misma topología de réplica
![[z/OS]](../images/ngzos.gif)
- El sistema incluye al menos 2 controladores y cada controlador tiene al menos 2 servants para fines de migración tras error y recuperación.
- La carga de trabajo total, que incluye las llamadas de operación normal, llamadas a la migración tras error y llamadas de recuperación, nunca debe superar la velocidad de llamada máxima.Para lograr el número máximo de llamadas por segundo, se necesitan los valores de configuración siguientes:
- Se ejecuta en un sistema z/OS Versión 1 Release 10 con FICON de alta disponibilidad para System z (zHPF) habilitado para E/S rápido. Un DASD DS8000 también debe estar ejecutándose en este sistema.
- Las definiciones de corriente de registro y de tamaño de conjunto de datos intermedio utilizadas cuando se crean las secuencias de registro debe ser igual o superior a 256 Megabytes (LS_SIZE(64000) STG_SIZE(64000)).
Puede determinar la tasa máxima de llamada aumentando progresivamente las tasas de llamada a lo largo de un período de tiempo y el rendimiento de supervisión hasta que se consigan tasas de tiempo de espera tolerables.
- La cantidad total de datos propagados sobre todas las llamadas activas no exceden los 2 GB.
- Todos los nodos están en la Versión 7.0.0.7 o un nivel posterior antes de habilitar el trabajo de SIP o CEA (Communications Enabled Applications) en z/OS.
- Otros servicios que requieren persistencia de datos como, por ejemplo, transacciones y compensaciones, se configuran para utilizar el registro de archivos HFS si tiene previsto utilizar el sistema para trabajo relacionado con SIP o CEA. Después de configurar el sistema para trabajo relacionado con SIP o CEA, otros servicios que requieren persistencia de datos no pueden utilizar corrientes de registro.
![[z/OS]](../images/ngzos.gif)
- Todos los controladores que están dentro de un clúster fallan al mismo tiempo. En esta situación, algunos de los datos que son necesarios para realizar la recuperación se pierden debido a los diversos errores simultáneos.
- Se produce una anomalía durante el proceso de recuperación. En esta situación, la corriente de registro asociada con las sesiones de error contiene datos incompletos.
- Cada miembro duplica todos los datos de estado para cada igual en su dominio de réplica.
- Lo ideal es que cada dominio de réplica contuviera dos servidores.
- Cuando se produce una anomalía, el coordinador de grupo principal indica a los miembros que quedan del grupo principal qué sesión duplicada activar. Estas sesiones duplicada pasan así a formar parte de las sesiones activas.
Siga los siguientes pasos para configurar un dominio de réplica para sesiones SIP.
Procedimiento
- En la consola de administración, pulse .
- Pulse y, a continuación, seleccione .
- En la sección Valores del contenedor, pulse .
- En la sección Propiedades adicionales, pulse y pulse .
- Establezca en .
- Guarde los cambios.
Resultados
La réplica de memoria a memoria queda duplicada para sesiones de SIP.