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
- 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
- INVITE
- SUBSCRIBE
- REFER
- 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
- javax.servlet.sip.SipApplicationSession
- javax.servlet.sip.SipSession
- javax.servlet.sip.ServletTimer
- Tout attribut défini sur SipSession ou SipApplicationSession
- 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]](../images/ngzos.gif)
- 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]](../images/ngzos.gif)
- 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.
- 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
- Dans la console d'administration, cliquez sur
- Cliquez sur , puis sélectionnez .
- Dans la section Paramètres de conteneur, cliquez sur .
- Dans la section Propriétés supplémentaires, cliquez sur , puis sur .
- Définissez le sur .
- Enregistrez les modifications.
Résultats
La réplication mémoire-à-mémoire est activée pour les sessions SIP.