Migración tras error y afinidad de sesiones SIP
SIP en WebSphere proporciona la afinidad de sesiones y la migración tras error.
- Afinidad de sesiones SIP
Un contenedor SIP individual de un clúster puede manejar todos los mensajes asociados a un solo diálogo. Si un contenedor falla a mitad de un diálogo, un solo servidor del clúster tomará la responsabilidad del diálogo. Es responsabilidad del proxy SIP mantener la afinidad de sesiones en función del identificador de sesiones, (que incluye el nombre de servidor lógico). La información del servidor lógico la publica el contenedor SIP y la consume el proxy SIP mediante WLM (Workload Management System).
- Direccionamiento de mensajes SIP basado en el ID de sesión
Se incluya ibmsid en diferentes mensajes SIP y se utiliza para direccionar las sesiones específicas que se ejecutan en el servidor de aplicaciones SIP. En términos generales, las cabeceras VIA se utilizan siempre para direccionar respuestas. El contenedor siempre incorpora un ibmsid en la cabecera VIA que está asociado al servidor de aplicaciones SIP. El siguiente es un ejemplo de una cabecera VIA de este tipo:
Via: SIP/2.0/UDP 9.51.252.69:5063;ibmsid=sipcontainer1.1153242645968.4_2_2;branch=z9hG4bK920196437955379
En las aplicaciones proxy, el ibmsid (o ID de sesión) se inserta en la solicitud inicial que se recibe del UAC en Record-Route. UAS devuelve el mismo Record-Route con el ID de sesión en la respuesta. UAC devuelve la cabecera de direccionamiento con el ID de sesión en la solicitud siguiente del diálogo. Por ejemplo:
En este ejemplo, UAS devuelve el mismo Record-Route con el ID de sesión en la respuesta y UAC devuelve la cabecera de direccionamiento con el ID de sesión en la solicitud siguiente del diálogo.Record-Route: <sip:protocol2.databeam.com:5060;transport=udp;ibmsid=sipcontainer1a.1138119214953.4_2_2;lr>
En las aplicaciones UAC y UAS, el contenedor que actúa como UAC o UAS insertará el ID de sesión en el código To (UAS) o en el código From (UAC). Por ejemplo, el código To local.1132518053302_2_2. El mismo código To o From se incluye en la solicitud siguiente.
Los URI codificados contendrán también un ibmappid (muy similar a un ibmsid), que se pueden enviar a continuación en la solicitud HTTP siguiente. Un punto importante a tener en cuenta que la infraestructura SIP de IBM no da soporte a la migración tras error a nivel de transacción. Sólo da soporte a la migración tras error en las llamadas estables.
Las siguientes son las reglas generales para saber cómo decide la infraestructura SIP de IBM que dirección ha de utilizar para las cabeceras de contacto que incorpora en los mensajes SIP de salida:- Un servidor de aplicaciones SIP autónomo utilizará su propia dirección en las cabeceras de contacto que necesita insertar en los mensajes SIP.
- Un servidor de aplicaciones SIP que tenga frontalmente un proxy SIP sin estado utilizará la dirección del proxy SIP en las cabeceras de contacto que necesita insertar en los mensajes SIP. El servidor de aplicaciones SIP descubre esta dirección mediante WLM.
- Un servidor de aplicaciones SIP que tenga frontalmente un proxy IP sin estado, que a su vez tenga frontalmente un distribuidor de IP, utilizará la dirección del distribuidor de IP en las cabeceras de contacto que necesita insertar en los mensajes SIP. La dirección del distribuidor SIP se debe configurar en el proxy SIP a través de la consola administrativa y esta dirección se publica en el servidor de aplicaciones a través de UCF.
- Migración tras error a mitad de una llamada
Cuando falla un servidor, las sesiones asociadas al servidor anómalo se activan en el resto de los contenedores del dominio de réplica. Cuando están activos, los contenedores que manejan las sesiones anómalas publican la ubicación de la sesión en los servidores proxy de la parte frontal de clúster a través de WLM. Cuando llega al proxy un mensaje asociado con uno de los diálogos anómalos, el proxy extrae el ID de sesión del mensaje SIP y lo utiliza para buscar el nuevo contenedor. Cuando se reinicia el servidor anómalo, se vuelve a añadir al clúster. A continuación, manejará únicamente los diálogos recién creados.
Figura 1. Migración tras error del contenedor SIP en un clúster (Antes)Figura 2. Migración tras error del contenedor SIP en un clúster (Después)- Aplicaciones convergentes y migración tras error
Todos los mensajes asociados a una sesión HTTP/SIP convergentes se direccionan mediante el proxy al mismo contenedor de programa de fondo utilizando los URI codificados y la afinidad de sesiones SIP. HTTP y SIP utilizan la misma topología de réplica (comparten los mismos valores de réplica). Si se produce un error, tanto las solicitudes HTTP como las solicitudes SIP asociadas al diálogo anómalo se direccionan al nuevo servidor de programa de fondo nuevo. Los cookies Jsession tienen prioridad sobre los URI codificados dentro del proxy cuando se están determinando los destinos de afinidad.
Figura 3. Ejemplo de aplicación convergente