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
- 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
- INVITE
- SUBSCRIBE
- REFER
- 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
- javax.servlet.sip.SipApplicationSession
- javax.servlet.sip.SipSession
- javax.servlet.sip.ServletTimer
- alle Attribut, die in der SipSession oder in der SipApplicationSession gesetzt werden
- 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]](../images/ngzos.gif)
- 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]](../images/ngzos.gif)
- 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.
- 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
- Klicken Sie in der Administrationskonsole auf .
- Klicken Sie auf und wählen Sie anschließend aus.
- Klicken Sie im Abschnitt "Containereinstellungen" auf .
- Klicken Sie im Abschnitt "Weitere Eigenschaften" auf und anschließend auf .
- Setzen Sie auf .
- Speichern Sie Ihre Änderungen.
Ergebnisse
Sie haben die Replikation zwischen Speichern für SIP-Sitzungen aktiviert.