SIP-Sitzungen replizieren

Sie können eine Replikationsdomäne für SIP-Sitzungen konfigurieren, wenn während der typischen SIP-Verarbeitung (Session Initiation Protocol) Informationen zum Sitzungs- und Dialogstatus repliziert werden sollen. Im Allgemeinen verwendet der SIP-Container den Datenreplikationsservice (DRS), um alle Statusinformationen zu replizieren. Im DRS gibt es keine Möglichkeit, sicherzustellen, dass die Datenreplikation abgeschlossen ist. Die einzigen Informationen, die quantifiziert werden können, sind daher Statusinformationen, die für die Replikation in eine Warteschlange gestellt werden. In diesem Artikel bedeuten Referenzen auf die Replikation von Daten lediglich, dass die Daten für die Replikation in eine Warteschlange gestellt wurden.

Informationen zu diesem Vorgang

Der SIP-Container repliziert unterschiedliche Typen von Informationen. Diese Daten können in zwei allgemeine Kategorien eingeteilt werden:
  • Interne Statusinformationen des SIP-Container, die dem Dialog zugeordnet sind
  • Informationen zum Anwendungsstatus, die verschiedenen Sitzungsobjekten zugeordnet sind

Jede Kategorie enthält eine Anzahl unterschiedlicher Datentypen, die weiter unten in diesem Abschnitt beschrieben werden. Jedes jedes Datenobjekt gesondert behandelt. Eine Änderung an einem Anwendungssitzungsobjekt, die eine Replikation verursacht, führt deshalb nicht zur Replikation interner Statusinformationen.

Replikation interner Statusinformationen

Interne Statusinformationen sind alle Informationen, die sich auf den Status eines Dialogs beziehen, der vom Container bearbeitet wird. Dazu gehören Informationen wie cseq, Dialogstatus (initial, early, confirmed, terminated), Sitzungsverfall, lokaler oder ferner Teilnehmer usw. Interne Statusinformationen werden nur aufgrund der Existenz eines Dialogs repliziert. Deshalb werden interne Daten, die sich auf SIP beziehen, nur dann repliziert, wenn der Dialog, dem diese Daten zugeordnet sind, existiert. Im Folgenden sind die Typen von SIP-Anforderungen, die zum Erstellen eines Dialogs führen, aufgelistet:
  • INVITE
  • SUBSCRIBE
  • REFER
Die Replikation interner Status findet an klar definierten, vorhersehbaren Punkten im Anrufablauf statt. Ein Dialog wird beispielsweise nur dann im Container erstellt, wenn aufgrund einer der zuvor aufgelisteten Methodentypen eine 2xx-Antwort oder eine 1xx-Antwort mit einem "To"-Tag empfangen oder gesendet wird. Im Folgenden sind die Ereignisse aufgeführt, die eine interne Statusreplikation auslösen können:
  • Erstellung eines neuen SIP-Dialogs
  • Verfall einer Sitzung wegen Überschreitung des Sitzungszeitlimits
  • Senden einer endgültigen Antwort an einen UAC
  • Erstellung eines codierten URL
  • Bearbeitung von Nachrichten, die zur Änderung des internen Dialogstatus führt

Beachten Sie den folgenden Hinweis: Der Transaktionsstatus wird im SIP-Container der WebSphere Application Server Version 6.1 nicht repliziert, sondern nur der Dialogstatus. Die Nichtreplikation des Transaktionsstatus verringert zwar die Belastung aller Server in der Replikationsdomäne, kann aber zu Problemen während einer Transaktion führen (z. B. Verlust dialogbezogener SIP-Nachrichten).

Ein wichtiger Unterschied zwischen einer B2BUA und einer Proxy-Anwendung ist die Anzahl der Sitzungsobjekte, die erstellt und repliziert werden. In beiden Fällen wird nur eine einzige Anwendungssitzung erstellt. Für die B2BUA werden jedoch zwei Sitzungsobjekte erstellt: eines für die eingehende Schiene und eines für die abgehende Schiene. Für eine Proxy-Anwendung wird nur ein Sitzungsobjekt erstellt.

Replikation von Anwendungsstatusinformationen

Die Anwendungsstatusinformationen werden anders als interne Dialogstatusinformationen behandelt, weil sie sich nicht auf die Existenz eines zu replizierenden Dialogs stützen. Der Anwendungsstatus bezieht sich auf alle Daten, die von der Anwendung über JSR-116-Datenkonstrukte verwaltet werden. Dazu gehören:
  • javax.servlet.sip.SipApplicationSession
  • javax.servlet.sip.SipSession
  • javax.servlet.sip.ServletTimer
  • alle Attribut, die in der SipSession oder in der SipApplicationSession gesetzt werden
Die Replikation des internen Status findet an klar definierten, vorhersehbaren Punkten im Aufrufablauf statt, während die Replikation des Anwendungsstatus weniger vorhersehbar ist, weil sich sich im Allgemeinen danach richtet, wann eine Anwendung die Sitzungsdaten und -zeitgeber über die JSR-116-APIs erstellt, invalidiert oder ändert, beispielsweise auf die Verarbeitung einer eingehenden Nachricht oder den Verfall eines SIP-Zeitgebers hin. Die folgenden Aktionen können die Replikation anwendungsbezogener Sitzungsdaten auslösen:
  • Erstellung eines Anwendungssitzungsobjekts
  • Erstellung eines SIP-Sitzungsobjekts
  • Erstellung eines SIP-Sitzungszeitgebers
  • Änderung eines Sitzungsobjekts mit setAttribute oder removeAttribute
  • Invalidierung eines SIP-Sitzungsobjekts
  • Verfall eines Sitzungszeitgebers
  • Anwendungscode sendet eine Anforderung. 1.

Die Replikation kann bei Anforderungen stattfinden, für die kein Dialog erstellt wird, wenn eine Anwendung request.getApplicationSession(true) aufruft und addTimer() und/oder addAttribute() im daraus resultierenden Anwendungssitzungsobjekt aufgerufen werden. Dies ist erforderlich, damit beim Ablauf des Zeitgebers ein Listener aufgerufen werden kann.

Hinweise zur Konfiguration von Failover und Replikation für SIP

Ein SIP-Cluster, der Replikation und Failover erfordert, kann zahlreiche Replikationsdomänen umfassen, die jeweils eine Reihe von SIP-Containern enthalten können. Die Anzahl der Container in einem Cluster ist nicht beschränkt. Im Hinblick auf die Leistung sollte jede Replikationsdomäne jedoch nur zwei Container enthalten.

Die Replikationsdomäne sollte auf "Gesamte Domäne" eingestellt sein, d. h., der Status wird in allen Containern der Replikationsdomäne repliziert. Für den Replikationsmodus sollte die Einstellung "Client und Server" ausgewählt werden.

Die verteilte Sitzung für einen Container muss auf "Replikation zwischen Speichern" eingestellt werden. Alle Anwendungen, die eine Sitzungsreplikation erfordern, müssen den Tag <distributable/> in den Dateien "web.xml" und "sip.xml" enthalten. SIP und HTTP verwenden dieselbe Replikationstopologie.

[z/OS]Vergewissern Sie sich, dass Ihr System wie folgt konfiguriert ist:
  • Ihr System umfasst mindestens 2 Controller, und jeder Controller hat mindestens 2 Servants für Failover und Wiederherstellung.
  • Die gesamte Workload, die normale Operationsaufrufe, Failoveraufrufe und Wiederherstellungsaufrufe umfasst, darf nie den Maximalwert für die Anzahl der Aufrufe überschreiten.
    Um den maximale Anzahl der Aufrufe pro Sekunde zu erzielen, sind die folgenden Konfigurationseinstellungen erforderlich:
    • Sie arbeiten mit einem für schnelle Ein-/Ausgabe aktivierten z/OS-System der Version 1 Release 10 mit High Performance FICON for System z (zHPF). Außerdem muss auf diesem System auch eine DASD-Einheit vom Typ DS8000 aktiv sein.
    • Die Werte für die Größedefinitionen des Protokolldatenstroms und der Staging-Datei, die bei der Erstellung der Protokolldatenströme verwendet werden, müssen größer-gleich 256 Megabyte sein: LS_SIZE(64000) bzw. STG_SIZE(64000).

    Sie können die maximale Aufrufrate bestimmen, indem Sie die Aufrufraten über einen bestimmten Zeitraum immer weiter erhöhen und dabei die Leistung überwachen, bis tolerierbare Zeitlimitraten erzielt werden.

  • Der Gesamtumfang der Daten, die über alle aktiven Aufrufe weitergegeben werden, überschreitet nicht den Grenzwert von 2 GB.
  • Alle Knoten haben die Version 7.0.0.7 oder höher, bevor Sie SIP oder Communications Enabled Applications (CEA) unter z/OS aktivieren.
  • Andere Services, die Datenpersistenz voraussetzen, wie z. B. Transaktionen und Kompensationen, werden konfiguriert, um die Protokollierung von HFS-Dateien zu verwenden, wenn Sie Ihr System für Arbeitsvorgänge mit SIP oder CEA verwenden möchten. Wenn Sie Ihr System für Arbeitsvorgänge mit SIP oder CEA konfiguriert haben, können andere Services, die Datenpersistenz voraussetzen, keine Protokolldatenströme verwenden.
[z/OS]Sie müssen den Protokolldatenstrom für einen Server auch löschen und erneut erstellen, wenn eine der folgenden Situationen eintritt:
  • Alle Controller in einem Cluster fallen gleichzeitig aus. In dieser Situation gehen einige der Daten, die für die Wiederherstellung erforderlich sind, verloren, da mehrere Störungen gleichzeitig auftreten.
  • Während des Wiederherstellungsprozesses tritt ein Fehler auf. In dieser Situation enthält der Protokolldatenstrom, der den fehlgeschlagenen Sitzungen zugeordnet ist, unvollständige Daten.
Replikationstopologie für SIP-Sitzungen
  • Jedes Member repliziert alle Daten auf jedem Peer in seiner Replikationsdomäne.
  • Jede Replikationsdomäne sollte idealerweise zwei Server enthalten.
  • Wenn ein Fehler auftritt, teilt der Koordinator der Stammgruppe den verbleibenden Stammgruppenmembern mit, welche replizierten Sitzungen aktiviert werden müssen. Diese replizierten Sitzungen werden dann in die aktiven Sitzungen übernommen.

Führen Sie die folgenden Schritte aus, um eine Replikationsdomäne für SIP-Sitzungen einzurichten.

Vorgehensweise

  1. Klicken Sie in der Administrationskonsole auf Umgebung > Replikationsdomänen > Neu.
  2. Klicken Sie auf Anzahl der Replikate und wählen Sie anschließend Gesamte Domäne aus.
  3. Klicken Sie im Abschnitt "Containereinstellungen" auf Sitzungsverwaltung.
  4. Klicken Sie im Abschnitt "Weitere Eigenschaften" auf Einstellungen für eine verteilte Umgebung und anschließend auf Replikation zwischen Speichern.
  5. Setzen Sie Replikationsmodus auf Client und Server.
  6. Speichern Sie Ihre Änderungen.

Ergebnisse

Sie haben die Replikation zwischen Speichern für SIP-Sitzungen aktiviert.

1 Bewirkt die Replikation der SipSession und der SipApplicationSession, damit die "Zeitmarke des letzten Zugriffs" mit den Peer-Containern im Cluster synchronisiert wird. Dies geschieht im Hinblick auf die Integrität künftiger Aufrufe von SipSession.getLastAccessedTime() und SipApplicationSession.getLastAccessedTime()

Symbol, das den Typ des Artikels anzeigt. Taskartikel



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