SIP セッションの複製

標準の Session Initiation Protocol (SIP) 処理時に発生するセッションの複製および ダイアログ状態の情報の複製が必要な場合に、SIP セッション用の複製ドメインをセットアップすることができます。 一般に、SIP コンテナーは、データ複製サービス (DRS) を使用して、すべての状態情報を複製します。DRS には、データの複製が完了した時期を確認する方法がないため、定量化できることは、複製用の状態情報の 1 つがキューに入れられた時期のみとなります。 このトピック内では、データの複製に対する参照では、複製用のデータがキューに入れられたことのみを意味します。

このタスクについて

SIP コンテナーは、さまざまなタイプの情報を複製します。 このデータは、次の 2 つの一般カテゴリーに入ります。
  • ダイアログに関連付けられた SIP コンテナーの内部状態情報。
  • さまざまなセッション・オブジェクトに関連付けられたアプリケーションの状態情報。

これらの各カテゴリーにはさまざまなデータ型が含まれており、これらについてはこのトピックで後述します。 各データ・オブジェクトは別個に扱います。そのため、複製を引き起こす、アプリケーション・セッション・オブジェクトの変更があっても、内部状態情報が複製されることはありません。

内部状態情報の複製

内部状態情報は、 コンテナーによって処理されているダイアログの状態に関連したものとして定義できます。 cseq、ダイアログ状態 (initial、early、confirmed、terminated)、セッションの有効期限、ローカル、リモート・パーティーなどが含まれています。 内部状態情報は、ダイアログの存在により複製のみ行われます。したがって、SIP 関連の内部データは、関連付けられているダイアログが確立するまでは複製されません。 ダイアログの作成の原因となる SIP 要求のタイプは、以下のとおりです。
  • INVITE
  • SUBSCRIBE
  • REFER
内部状態の複製は、コール・フローの明確であり、予測可能なポイントで行われます。 例えば、コンテナーでダイアログが確立されるのは、2xx 応答または「To」タグ付きの 1xx 応答が、上にリストされたメソッド・タイプの 1 つが原因で受信または送信されたときのみです。内部状態の複製を引き起こすイベントには、下記があります。
  • 新規 SIP ダイアログの作成
  • セッションのタイムアウトによるセッションの有効期限切れ
  • UAC への最終応答の送信
  • エンコード URI の作成
  • 内部ダイアログ状態の変更の原因となるメッセージの処理

トランザクション状態は、 WebSphere® Application Server 6.1 バージョンの SIP コンテナーでは複製されないことに注意してください。複製されるのは、ダイアログ状態のみです。トランザクション状態を複製しないことにより、 複製ドメインのすべてのサーバーで負荷が軽減されますが、 トランザクションの半ばに発生する障害問題の原因となる場合があります (例えば、ダイアログ関連の SIP メッセージの欠落など)。

B2BUA とプロキシー・アプリケーション間の重要な相違は、 作成され、複製されるセッション・オブジェクト数です。 どちらの場合も アプリケーション・セッションは 1 つしか作成されませんが、B2BUA の場合は、2 つのセッション・オブジェクトが作成されます。1 つはインバウンド・レグ用、もう 1 つはアウトバウンド・レグ用です。 プロキシー・アプリケーションの場合は、単一セッション・オブジェクトのみが作成されます。

アプリケーション状態情報の複製

アプリケーション状態情報は、内部のダイアログ状態情報とは異なる扱いをされます。 それは、複製するダイアログの存在に左右されるからです。 アプリケーションの状態は、 JSR 116 データ構成体の使用によりアプリケーションによって保守されているデータを参照します。 これには、以下のものがあります。
  • javax.servlet.sip.SipApplicationSession
  • javax.servlet.sip.SipSession
  • javax.servlet.sip.ServletTimer
  • SipSession または SipApplicationSession に設定されている属性
内部状態の複製はコール・フロー内で明確であり、予測可能なポイントで発生するが、 アプリケーション状態の複製は予測することが困難です。それは、一般に、アプリケーションが JSR 116 API を使用してセッション・データおよびタイマーを作成、無効化、および変更を行う時期に依存しているためです。 この場合は、インバウンド・メッセージの処理または SIP タイマーの期限切れに起因します。 以下のすべては、アプリケーションに関連したセッション・データの複製の原因となります。
  • アプリケーション・セッション・オブジェクトの作成
  • SIP セッション・オブジェクトの作成
  • SIP セッション・タイマーの作成
  • setAttribute または removeAttribute によるセッション・オブジェクトの変更
  • SIP セッション・オブジェクトの無効化
  • セッション・タイマーの期限切れ
  • アプリケーション・コードによる要求の送信 1 に対して、将来の呼び出しの整合性をとるためのものです。

アプリケーションが request.getApplicationSession(true) を呼び出す場合と、 addTimer() および/または addAttribute() が結果であるアプリケーション・セッション・オブジェクトで 呼び出される場合は、ダイアログを確立していない要求に対して複製が発生する可能性があります。 これは、タイマーが期限切れになるときにリスナーが呼び出されるようにするために必要です。

SIP フェイルオーバーおよび複製のセットアップの考慮事項

複製およびフェイルオーバーを必要とする SIP クラスターは、 数多くの複製ドメインから構成することができます。また、それぞれの複製ドメインは、SIP コンテナーのセットで構成されています。 クラスターのコンテナー数には制限がありません。 パフォーマンス上の理由で、各複製ドメインに含めるコンテナーは、2 つに制限します。

複製ドメインは、ドメイン全体に設定する必要があります。つまり、状態は、 複製ドメインのすべてのコンテナーに複製されます。 複製モードは、クライアントとサーバーの両方に設定する必要があります。

コンテナーの分散セッションは、メモリー間の複製に設定する必要があります。 セッションの複製を必要とするすべてのアプリケーションは、web.xml ファイルおよび sip.xml ファイルに <distributable/> タグを含んでいなければなりません。SIP と HTTP の両方は、同一の複製トポロジーを使用しています。

[z/OS]システムが次のように構成されていることを確認します。
  • システムに少なくとも 2 つのコントローラーがあり、各コントローラーには、 フェイルオーバー用とリカバリー用の少なくとも 2 つのサーバントがなければなりません。
  • 通常の操作呼び出し、フェイルオーバー呼び出し、およびリカバリー呼び出しを含む合計ワークロードが、 最大呼び出し率を超えてはなりません。
    1 秒あたりの最大呼び出し数が達成されるようにするには、 以下の構成設定が必要です。
    • 高速 I/O のための High Performance FICON for System z (zHPF) 対応の z/OS バージョン 1 リリース 10 システムで実行しており、DS8000 DASD もこのシステムで実行している必要があります。
    • ログ・ストリーム、およびログ・ストリームの作成時に使用するステージング・データ・セット・サイズ定義 は、256 メガバイト以上でなければなりません (LS_SIZE(64000) STG_SIZE(64000))。

    許容可能なタイムアウト率に達するまで、一定時間あたりの呼び出し率を徐々に増やし、 パフォーマンスをモニターすることにより、最大呼び出し率を決定することができます。

  • すべてのアクティブ呼び出しで伝搬されるデータの合計量が 2 GB を 超えないようにします。
  • z/OS で SIP または Communications Enabled Applications (CEA) を作動可能にする前に、 すべてのノードがバージョン 7.0.0.7 以降のレベルであるようにします。
  • システムを SIP または CEA 関連作業に使用することを計画している場合は、 データ・パーシスタンスを必要とする他のサービス (トランザクションなど) および補正が HFS ファイル・ロギング を使用するように構成します。システムを SIP または CEA 関連作業用に構成すると、 データ・パーシスタンスを必要とする他のサービスは、ログ・ストリームを使用できません。
[z/OS]また、以下のいずれかの状態が発生したら、サーバーのログ・ストリームを削除して再作成する必要があります。
  • クラスター内のすべてのコントローラーに同時に障害が発生した場合。 この状態では、複数の障害が同時に発生したため、 リカバリーを行う必要がある一部のデータが喪失した可能性があります。
  • リカバリー処理中に障害が発生した場合。この状態では、 障害が発生したセッションに関連したログ・ストリームに不完全なデータが含まれています。
SIP セッション複製トポロジー
  • 各メンバーは、すべての状態データを、その複製ドメインのあらゆるピアに複製します。
  • 各複製ドメインには、理想的には、2 つのサーバーが含まれている必要があります。
  • 障害が発生すると、コア・グループのコーディネーターが、コア・グループの残りのメンバーに、どの複製セッションをアクティブにするかを通知します。これらの複製セッションは、アクティブ・セッションの一部になります。

SIP セッションの複製ドメインをセットアップするには、以下のステップを完了してください。

手順

  1. 管理コンソールで、「環境」>「複製ドメイン」>「新規」の順にクリックします。
  2. 「レプリカの数」をクリックしてから、 「ドメイン全体」を選択します。
  3. 「コンテナー設定」セクションで、「セッション管理」をクリックします。
  4. 「追加プロパティー」セクションで、「分散環境設定」をクリックしてから、「メモリー間の複製」をクリックします。
  5. 「複製モード」「クライアントとサーバーの両方」に設定します。
  6. 変更を保存します。

タスクの結果

メモリー間の複製が、SIP セッションに対して使用可能になっています。

1 「最終アクセスのタイム・スタンプ」をクラスターのピア・コンテナーと同期化するために、SipSession および SipApplicationSession の複製を発生します。これは、SipSession.getLastAccessedTime() および SipApplicationSession.getLastAccessedTime()

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsip_sessionrep
ファイル名:tsip_sessionrep.html