SIP 세션 유사성 및 장애 복구
WebSphere의 SIP는 세션 유사성 및 장애 복구를 제공합니다.
- SIP 세션 유사성
클러스터의 단일 SIP 컨테이너가 단일 대화 상자와 연관된 모든 메시지를 처리합니다. 대화 상자에서 컨테이너가 실패한 경우에는 클러스터의 단일 서버에 해당 대화 상자의 책임이 인계됩니다. 세션 ID(논리 서버 이름 포함)에 기반하여 세션 유사성을 유지하는 것은 SIP 프록시의 책임입니다. 논리 서버 정보는 SIP 컨테이너가 공개하고 WLM(Workload Management System)을 통해 SIP 프록시가 사용합니다.
- 세션 ID를 기반으로하는 SIP 메시지 라우팅
ibmsid가 다양한 SIP 메시지에 임베디드되어 있어 SIP 애플리케이션 서버에서 실행 중인 특정 세션에 라우트하는 데 사용됩니다. 일반적으로, 응답을 라우트할 때는 항상 VIA 헤더가 사용됩니다. 컨테이너는 항상 SIP 애플리케이션 서버와 연관된 VIA에 ibmsid를 임베디드합니다. 다음은 VIA 헤더와 같은 예입니다.
Via: SIP/2.0/UDP 9.51.252.69:5063;ibmsid=sipcontainer1.1153242645968.4_2_2;branch=z9hG4bK920196437955379
프록시 애플리케이션의 경우, Record-Route의 UAC에서 수신한 초기 응답에 ibmsid(또는 세션 ID)가 삽입됩니다. UAS는 응답에 세션 ID가 있는 동일한 Record-Route를 리턴합니다. UAC는 대화 상자에서 후속 응답에 세션 ID가 있는 Route 헤더를 리턴합니다. 예제:
이 예제에서 UAS는 응답에 세션 ID가 있는 동일한 Record-Route를 리턴하고, UAC는 대화 상자에서 후속 응답에 세션 ID가 있는 Route 헤더를 리턴합니다.Record-Route: <sip:protocol2.databeam.com:5060;transport=udp;ibmsid=sipcontainer1a.1138119214953.4_2_2;lr>
UAC 및 UAS 애플리케이션의 경우, UAC 또는 UAS 역할을 하는 컨테이너가 세션 ID를 To tag(UAS) 또는 From tag(UAC)에 삽입합니다(예: To tag local.1132518053302_2_2). 동일한 To tag 또는 From tag가 후속 요청에 포함됩니다.
또한 인코딩된 URI은 후속 HTTP 요청에 보낼 수 있는 ibmappid(ibmsid와 유사함), 를 포함합니다. 여기서 중요한 점은, IBM SIP 인프라가 트랜잭션 레벨 장애 복구를 지원하지 않는다는 사실입니다. 이것은 안정적인 호출에 대한 대화 상자 장애 복구만 지원합니다.
IBM SIP 인프라가 아웃바운드 SIP 메시지에 임베디드하는 contact 헤더에 사용할 주소를 어떻게 결정하는지에 대한 일반 규칙은 다음과 같습니다.- 독립형 SIP 애플리케이션 서버는 SIP 메시지에 삽입해야 하는 contact 헤더에 고유 주소를 사용합니다.
- Stateless SIP 프록시가 앞에 있는 SIP 애플리케이션 서버는 SIP 메시지에 삽입해야 하는 contact 헤더에 SIP 프록시의 주소를 사용합니다. SIP 애플리케이션 서버는 WLM을 통해 이 주소를 찾습니다.
- 그런 다음 IP 스프레이가 앞에 있는 Stateless SIP 프록시가 앞에 오는 SIP 애플리케이션 서버가 SIP 메시지에 삽입해야 하는 contact 헤더에 IP 스프레이의 주소를 사용합니다. IP 스프레이의 주소는 관리 콘솔을 통해 SIP 프록시에 구성되어야 하고, 이 주소는 UCF를 통해 SIP 애플리케이션 서버에 "공개"됩니다.
- 호출 중에 장애 복구
서버가 실패하면, 해당 실패한 서버와 관련된 세션이 복제 도메인에 있는 남은 컨테이너에서 활성화됩니다. 활성화되고 나면, 실패한 세션을 처리하는 컨테이너가 WLM을 통해 클러스터를 직면하는 프록시 서버에 세션 위치를 공개합니다. 실패한 대화 상자 중 하나와 연관된 메시지가 프록시에 도착하면, 프록시가 SIP 메시지에서 세션 ID를 가져와 새 컨테이너를 조회하는 데 사용합니다. 실패한 서버를 다시 시작할 때 클러스터에 다시 추가됩니다. 그런 다음 새로 작성된 대화 상자만 처리합니다.
그림 1. 클러스터에서 SIP 컨테이너 장애 복구(이전)그림 2. 클러스터에서 SIP 컨테이너 장애 복구(이후)- 통합된 애플리케이션 및 장애 복구
통합된 HTTP/SIP 세션과 연관된 모든 메시지는 프록시에 의해 인코딩된 URI 및 SIP 세션 유사성을 사용하여 동일한 백엔드 컨테이너로 라우트됩니다. HTTP 및 SIP는 동일한 복제 토폴로지를 이용합니다(동일한 복제 설정 공유). 장애가 발생하면 실패한 대화 상자와 연관된 HTTP 및 SIP 요청이 동일한 새 백엔드 서버로 라우트됩니다. 유사성 대상이 결정될 때는 Jsession 쿠키가 프록시의 인코딩된 URI보다 우선 적용됩니다.
그림 3. Converged 애플리케이션 예제