SIP セッションの複製
標準の Session Initiation Protocol (SIP) 処理時に発生するセッションの複製および ダイアログ状態の情報の複製が必要な場合に、SIP セッション用の複製ドメインをセットアップすることができます。 一般に、SIP コンテナーは、データ複製サービス (DRS) を使用して、すべての状態情報を複製します。DRS には、データの複製が完了した時期を確認する方法がないため、定量化できることは、複製用の状態情報の 1 つがキューに入れられた時期のみとなります。 このトピック内では、データの複製に対する参照では、複製用のデータがキューに入れられたことのみを意味します。
このタスクについて
- ダイアログに関連付けられた SIP コンテナーの内部状態情報。
- さまざまなセッション・オブジェクトに関連付けられたアプリケーションの状態情報。
これらの各カテゴリーにはさまざまなデータ型が含まれており、これらについてはこのトピックで後述します。 各データ・オブジェクトは別個に扱います。そのため、複製を引き起こす、アプリケーション・セッション・オブジェクトの変更があっても、内部状態情報が複製されることはありません。
内部状態情報の複製
- INVITE
- SUBSCRIBE
- REFER
- 新規 SIP ダイアログの作成
- セッションのタイムアウトによるセッションの有効期限切れ
- UAC への最終応答の送信
- エンコード URI の作成
- 内部ダイアログ状態の変更の原因となるメッセージの処理
トランザクション状態は、 WebSphere® Application Server 6.1 バージョンの SIP コンテナーでは複製されないことに注意してください。複製されるのは、ダイアログ状態のみです。トランザクション状態を複製しないことにより、 複製ドメインのすべてのサーバーで負荷が軽減されますが、 トランザクションの半ばに発生する障害問題の原因となる場合があります (例えば、ダイアログ関連の SIP メッセージの欠落など)。
B2BUA とプロキシー・アプリケーション間の重要な相違は、 作成され、複製されるセッション・オブジェクト数です。 どちらの場合も アプリケーション・セッションは 1 つしか作成されませんが、B2BUA の場合は、2 つのセッション・オブジェクトが作成されます。1 つはインバウンド・レグ用、もう 1 つはアウトバウンド・レグ用です。 プロキシー・アプリケーションの場合は、単一セッション・オブジェクトのみが作成されます。
アプリケーション状態情報の複製
- javax.servlet.sip.SipApplicationSession
- javax.servlet.sip.SipSession
- javax.servlet.sip.ServletTimer
- SipSession または SipApplicationSession に設定されている属性
- アプリケーション・セッション・オブジェクトの作成
- SIP セッション・オブジェクトの作成
- SIP セッション・タイマーの作成
- setAttribute または removeAttribute によるセッション・オブジェクトの変更
- SIP セッション・オブジェクトの無効化
- セッション・タイマーの期限切れ
- アプリケーション・コードによる要求の送信 1 に対して、将来の呼び出しの整合性をとるためのものです。
アプリケーションが request.getApplicationSession(true) を呼び出す場合と、 addTimer() および/または addAttribute() が結果であるアプリケーション・セッション・オブジェクトで 呼び出される場合は、ダイアログを確立していない要求に対して複製が発生する可能性があります。 これは、タイマーが期限切れになるときにリスナーが呼び出されるようにするために必要です。
SIP フェイルオーバーおよび複製のセットアップの考慮事項
複製およびフェイルオーバーを必要とする SIP クラスターは、 数多くの複製ドメインから構成することができます。また、それぞれの複製ドメインは、SIP コンテナーのセットで構成されています。 クラスターのコンテナー数には制限がありません。 パフォーマンス上の理由で、各複製ドメインに含めるコンテナーは、2 つに制限します。
複製ドメインは、ドメイン全体に設定する必要があります。つまり、状態は、 複製ドメインのすべてのコンテナーに複製されます。 複製モードは、クライアントとサーバーの両方に設定する必要があります。
コンテナーの分散セッションは、メモリー間の複製に設定する必要があります。 セッションの複製を必要とするすべてのアプリケーションは、web.xml ファイルおよび sip.xml ファイルに <distributable/> タグを含んでいなければなりません。SIP と HTTP の両方は、同一の複製トポロジーを使用しています。
![[z/OS]](../images/ngzos.gif)
- システムに少なくとも 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]](../images/ngzos.gif)
- クラスター内のすべてのコントローラーに同時に障害が発生した場合。 この状態では、複数の障害が同時に発生したため、 リカバリーを行う必要がある一部のデータが喪失した可能性があります。
- リカバリー処理中に障害が発生した場合。この状態では、 障害が発生したセッションに関連したログ・ストリームに不完全なデータが含まれています。
- 各メンバーは、すべての状態データを、その複製ドメインのあらゆるピアに複製します。
- 各複製ドメインには、理想的には、2 つのサーバーが含まれている必要があります。
- 障害が発生すると、コア・グループのコーディネーターが、コア・グループの残りのメンバーに、どの複製セッションをアクティブにするかを通知します。これらの複製セッションは、アクティブ・セッションの一部になります。
SIP セッションの複製ドメインをセットアップするには、以下のステップを完了してください。
手順
- 管理コンソールで、 の順にクリックします。
- をクリックしてから、 を選択します。
- 「コンテナー設定」セクションで、 をクリックします。
- 「追加プロパティー」セクションで、 をクリックしてから、 をクリックします。
- を に設定します。
- 変更を保存します。
タスクの結果
メモリー間の複製が、SIP セッションに対して使用可能になっています。