Réplication des sessions SIP

Vous pouvez définir un domaine de réplication pour les sessions SIP si vous souhaitez une réplication de session et des informations d'état sur la boîte de dialogue pendant le traitement du protocole SIP (Session Initiation Protocol) standard. En règle générale, le conteneur SIP utilise le service DRS (Data Replication Service) pour répliquer toutes les informations d'état. DRS ne permettant pas de confirmer l'achèvement de la réplication des données, il est seulement possible de quantifier le moment où une information d'état est mise en file d'attente pour la réplication. Dans cette rubrique, les références à la réplication des données signifient uniquement que les données ont été mises en file d'attente pour la réplication.

Pourquoi et quand exécuter cette tâche

Le conteneur SIP réplique plusieurs types d'informations. Ces données font partie de deux catégories générales :
  • Informations d'état du conteneur SIP interne associées au dialogue.
  • Informations d'état de l'application associées aux objets de session variés.

Chacune de ces catégories inclut différents types de données, décrits dans cette rubrique. Chaque objet données est traité de façon indépendante. Par conséquent, une modification d'objet de session d'application, qui entraîne une réplication, ne déclenche aucune réplication d'informations d'état internes.

Réplication des informations d'état internes

Les informations d'état internes peuvent être considérées comme tout ce que est lié à l'état d'un dialogue géré par le conteneur. Ces informations incluent des éléments, tels que cseq, l'état du dialogue (initial, début, confirmé, clos), l'expiration de la session, local, distant partiel, etc. Les informations d'état internes sont uniquement répliquées à cause de l'existence d'un dialogue. Par conséquent, aucune donnée SIP interne ne sera répliquée tant que le dialogue avec laquelle est associée ne sera pas établie. Les types de demandes SIP susceptibles d'entraîner la création d'un dialogue sont les suivants :
  • INVITE
  • SUBSCRIBE
  • REFER
La réplication de l'état interne se produit à des moments bien définis et prévisibles du flux d'appels. Par exemple, un dialogue est établi uniquement au niveau du conteneur lorsqu'une réponse 2xx ou 1xx comportant une balise “To” est reçue ou envoyée à cause de l'un des types de méthode répertoriés précédemment. Les événements susceptibles de déclencher une réplication de l'état interne sont les suivants :
  • Création d'un nouveau dialogue SIP
  • Expiration d'une session après dépassement du délai d'attente
  • L'envoi d'une réponse finale à un client d'agent utilisateur
  • Création d'un URI encodé
  • Manipulation des messages qui entraîne la modification de l'état de dialogue interne

Il est important de noter que l'état de transaction n'est pas répliqué dans la version 6.1 du conteneur SIP de WebSphere Application Server, uniquement l'état de dialogue. Si vous ne répliquez pas l'état de transaction, la charge de tous les serveurs du domaine de réplication sera réduite, et des problèmes pourront survenir en plein milieu d'une transaction (par exemple, la perte des messages SIP liés au dialogue).

La grande différence entre un agent B2BUA et une application proxy est le nombre d'objets de session créés et répliqués. Dans les deux cas, une seule session d'application est créée, mais pour l'agent B2BUA, deux sessions d'objets sont créées : une pour la partie entrante et l'autre pour la sortante. Pour une application proxy, une seule session objet est créée.

Réplication des informations d'état d'une application

Les informations d'état d'une application sont traitées différemment des informations d'état du dialogue internes, car leur réplication ne dépend pas de l'existence d'un dialogue. L'état d'une application fait référence à toutes les données gérées par une application via l'utilisation des constructions de données JSR 116. Ceci inclut :
  • javax.servlet.sip.SipApplicationSession
  • javax.servlet.sip.SipSession
  • javax.servlet.sip.ServletTimer
  • Tout attribut défini sur SipSession ou SipApplicationSession
La réplication de l'état interne se produit à des moments bien définis et prévisibles du flux d'appels, tandis que la réplication d'un état d'application est moins prévisible car elle dépend généralement du moment de création, d'invalidation ou de modification des données de session et des temporisations par une application via des API JSR 116. Ceci est peut être dû au traitement d'un message entrant ou à l'expiration d'un temporisateur SIP. Tous les événements suivants peuvent entraîner la réplication des données de session liées à une application :
  • Création d'un objet de session d'une application
  • Création d'un objet de session SIP
  • Création d'un temporisateur de session SIP
  • Modification d'un objet de session via setAttribute ou removeAttribute
  • Invalidation d'un objet de session SIP
  • Expiration d'un temporisateur de session
  • Code d'application envoyant une demande 1

La réplication peut se produire pour des demandes qui n'établissent pas un dialogue si une application appelle request.getApplicationSession(true) et si addTimer() et/ou addAttribute() sont appelés sur l'objet de session d'application résultant. Cela permet à un module d'écoute d'être appelé quand le temporisateur expire.

Remarques relatives à la configuration de la réplication et du basculement SIP

Un cluster SIP qui nécessite une réplication et un basculement peut être composé de plusieurs domaines de réplication, qui contiennent chacun un ensemble de conteneurs SIP. Aucune limite n'est définie pour le nombre de conteneurs d'un cluster. Pour des raisons de performances, chaque domaine de réplication ne doit contenir que deux conteneurs.

Le domaine de réplication doit être définie sur la totalité du domaine, ce qui signifie que l'état est répliqué dans tous les conteneurs du domaine de réplication. Le mode de réplication doit être client et serveur.

La session distribuée d'un conteneur doit être définie sur la réplication de mémoire à mémoire. Toute application nécessitant une réplication de session doit inclure la balise <distributable /> dans les fichiers web.xml et sip.xml. SIP et HTTP utiliseront la même topologie de réplication

[z/OS]Vérifiez que le système est configuré de la façon suivante :
  • Votre système inclut au moins deux contrôleurs et chacun d'eux possède au moins deux serviteurs à des fins de reprise en ligne et de récupération.
  • La charge de travail totale, qui inclut les appels d'exploitation courante, les appels de reprise en ligne et les appels de récupération, ne doit jamais dépasser le taux d'appels maximum.
    Pour parvenir au nombre maximum d'appels par seconde, les paramètres de configuration suivants sont requis :
    • Vous utilisez un système z/OS version 1, édition 10 sur lequel High Performance FICON for System z (zHPF) est activé pour les entrées-sorties rapides. Une unité de stockage à accès direct DS8000 doit également être en cours d'exécution sur ce système.
    • Le flux de consignation et les définitions de tailles de fichiers de transfert utilisés lors de la création des flux de consignation doivent être égaux ou supérieurs à 256 mégaoctets (LS_SIZE(64000) STG_SIZE(64000)).

    Vous pouvez déterminer le débit d'appels maximum en augmentant progressivement les débits d'appels sur une durée donnée et en surveillant les performances jusqu'à atteindre des taux de délai d'expiration acceptables.

  • La quantité totale de données propagées sur tous les appels actifs n'excède pas 2 Go.
  • Tous les noeuds doivent être en version 7.0.0.7 ou à un niveau ultérieur pour que vous puissiez activer du travail SIP ou Communications Enabled Applications (CEA)sur z/OS.
  • D'autres services qui requièrent la persistance des données, tels que les transactions et les compensations sont configurés pour utiliser la consignation de fichiers HFS si vous envisagez d'utiliser votre système pour du travail associé à SIP ou CEA. Lorsque vous avez configuré votre système pour du travail associé à SIP ou CEA, d'autres services qui requièrent la persistance des données ne peuvent pas utiliser les flux de consignation.
[z/OS]Vous devez également supprimer et recréer le flux de consignation pour un serveur si l'une des situations suivantes se produit :
  • Tous les contrôleurs d'un cluster tombent en panne en même temps. Dans ce cas, une partie des données nécessaires à la reprise est perdue en raison des pannes simultanées multiples.
  • Une panne se produit pendant le processus de reprise. Dans ce cas, le flux de consignation associé aux sessions défaillantes contient des données incomplètes.
Topologie de la réplication des sessions SIP
  • Chaque membre réplique toutes les données d'état vers chaque homologue de son domaine de réplication.
  • Chaque domaine de réplication doit idéalement contenir deux serveurs.
  • En cas d'incident, le coordinateur du groupe central indique aux membres restants quelles sessions répliquées ils doivent activer. Ces sessions répliquées font alors partie de leurs sessions actives.

Procédez comme suit pour configurer un domaine de réplication pour les sessions SIP.

Procédure

  1. Dans la console d'administration, cliquez sur Environnement > Domaines de réplication > Nouveau
  2. Cliquez sur Nombre de répliques, puis sélectionnez Domaine entier.
  3. Dans la section Paramètres de conteneur, cliquez sur Gestion de session.
  4. Dans la section Propriétés supplémentaires, cliquez sur Paramètres de l'environnement distribué, puis sur Réplication mémoire à mémoire.
  5. Définissez le Mode de réplication sur Client et serveur.
  6. Enregistrez les modifications.

Résultats

La réplication mémoire-à-mémoire est activée pour les sessions SIP.

1 Entraîne la réplication de la session_SIP et de la session_application_SIP afin de synchroniser le "dernier horodatage de l'accès" avec le ou les conteneurs homologues du cluster. Cela s'effectue pour l'intégrité des futurs appels vers SipSession.getLastAccessedTime() et SipApplicationSession.getLastAccessedTime()

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsip_sessionrep
Nom du fichier : tsip_sessionrep.html