Sitzungsaffinität und Failover in SIP

SIP in WebSphere stellt Sitzungsaffinität und Failover bereit.

SIP-Sitzungsaffinität

Ein einzelner SIP-Container in einem Cluster ist zuständig für die Abwicklung aller Nachrichten, die einem einzelnen Dialog zugeordnet sind. Wenn ein Container mitten in einem Dialog ausfällt, übernimmt ein einzelner Server im Cluster die Zuständigkeit für den Dialog. Es ist Aufgabe des SIP-Proxys, die Sitzungsaffinität auf der Basis der Sitzungs-ID (die den Namen des logischen Servers enthält) aufrechtzuerhalten. Die Informationen zum logischen Server werden vom SIP-Container veröffentlicht und vom SIP-Proxy über das Workload-Management-System gelesen.

SIP-Nachrichten basierend auf der Sitzungs-ID weiterleiten

Die ibmsid ist in verschiedenen SIP-Nachrichten enthalten und wird für die Weiterleitung an bestimmte Sitzungen auf dem SIP-Anwendungsserver verwendet. Allgemein ausgedrückt bedeutet dies, dass für die Weiterleitung von Antworten immer VIA-Header verwendet werden. Der Container wird immer eine ibmsid in den VIA-Header aufnehmen, der dem SIP-Anwendungsserver zugeordnet ist. Nachfolgend ist ein Beispiel eines solchen VIA-Headers aufgeführt:

Via: SIP/2.0/UDP 9.51.252.69:5063;ibmsid=sipcontainer1.1153242645968.4_2_2;branch=z9hG4bK920196437955379

Für Proxy-Anwendungen gilt, dass die ibmsid (oder Sitzungs-ID) in die erste Anforderung eingefügt wird, die vom UAC in der Record-Route empfangen wird. Der UAS gibt dieselbe Record-Route mit der Sitzungs-ID in der Antwort zurück. Der UAC gibt den Route-Header mit der Sitzungs-ID in nachfolgenden Anforderungen innerhalb des Dialogs zurück. Beispiel:

Record-Route: <sip:protocol2.databeam.com:5060;transport=udp;ibmsid=sipcontainer1a.1138119214953.4_2_2;lr>
In diesem Beispiel gibt der UAS dieselbe Record-Route mit der Sitzungs-ID in der Antwort zurück, und der UAC gibt den Route-Header mit der Sitzungs-ID in nachfolgenden Anforderungen innerhalb des Dialogs zurück.

Für UAC- und UAS-Anwendungen fügt der Container, der als UAC oder UAS fungiert, die Sitzungs-ID in das To-Tag (UAS) oder in das From-Tag (UAC) ein (z. B. To-Tag local.1132518053302_2_2). Dasselbe To- oder From-Tag wird in nachfolgende Anforderungen eingefügt.

Codierte URIs enthalten außerdem eine ibmappid (die einer ibmsid sehr ähnlich ist), die in nachfolgenden HTTP-Anforderungen gesendet werden kann. Ein wichtiger Punkt ist in diesem Zusammenhang, dass die IBM SIP-Infrastruktur kein Failover auf Transaktionsebene unterstützt, sondern nur das Dialog-Failover, um stabile Aufrufe sicherzustellen.

Nachfolgend sind die allgemeinen Regeln aufgeführt, anhand deren die IBM SIP-Infrastruktur festlegt, welche Adressen für Contact-Header verwendet werden sollen, die in abgehende SIP-Nachrichten eingefügt werden:
  • Ein eigenständiger SIP-Anwendungsserver verwendet seine eigene Adresse in den Contact-Headern, die in SIP-Nachrichten eingefügt werden müssen.
  • Ein SIP-Anwendungsserver, dem ein statusunabhängiger SIP-Proxy vorgeschaltet ist, verwendet die Adresse des SIP-Proxy in Contact-Headern, die in SIP-Nachrichten eingefügt werden müssen. Der SIP-Anwendungsserver ermittelt diese Adresse über WLM.
  • Ein SIP-Anwendungsserver, dessen vorgeschaltetem statusunabhängigem SIP-Proxy ein IP-Sprayer vorgeschaltet ist, verwendet die Adresse des SIP-Sprayers in Contact-Headern, die in SIP-Nachrichten eingefügt werden müssen. Die Adresse des IP-Sprayers muss über die Administrationskonsole auf dem SIP-Proxy konfiguriert worden sein, und sie wird über UFC auf dem SIP-Anwendungsserver veröffentlicht.
Failover in der Mitte eines Aufrufs

Wenn ein Server ausfällt, werden die Sitzungen, die dem ausgefallenen Server zugeordnet sind, auf den übrigen Containern in der Replikationsdomäne aktiviert. Sobald sie aktiv sind, veröffentlichen die Container, die die fehlgeschlagenen Sitzungen übernommen haben, die Position der Sitzungen über WLM auf den Proxy-Servern, die dem Cluster vorgeschaltet sind. Wenn auf dem Proxy eine Nachricht empfangen wird, die einem der fehlgeschlagenen Dialoge zugeordnet ist, ruft der Proxy die Sitzungs-ID aus der SIP-Nachricht ab und ermittelt mithilfe dieser Sitzungs-ID den neuen Container. Wenn der ausgefallene Server erneut gestartet wird, wird er dem Cluster wieder hinzugefügt. Anschließend ist er nur für neu erstellte Dialoge zuständig.

Abbildung 1. SIP-Container-Failover in einem Cluster (vorher)

SIP-Container-Failover in einem Cluster

Abbildung 2. SIP-Container-Failover in einem Cluster (nachher)

SIP-Container-Failover in einem Cluster
Konvergierte Anwendungen und Failover

Alle Nachrichten, die einer konvergenten HTTP/SIP-Sitzung zugeordnet sind, werden vom Proxy mittels codierter URIs und SIP-Sitzungsaffinität an denselben Back-End-Container weitergeleitet. HTTP und SIP verwenden dieselbe Replikationstopologie (dieselben Replikationseinstellungen). Bei einem Ausfall werden sowohl HTTP- als auch SIP-Anforderungen, die einem fehlgeschlagenen Dialog zugeordnet sind, an denselben neuen Back-End-Server weitergeleitet. Jsession-Cookies haben im Proxy Vorrang vor codierten Cookies, wenn die Affinitätsziele ermittelt werden.

Abbildung 3. Beispiel für eine konvergente Anwendung

SIP-Container-Failover in einem Cluster

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csip_sessionfail
Dateiname:csip_sessionfail.html