このトピックでは、標準の SIP コール・フロー時に、セッションの複製が行われ、ダイアログ状態が起こる時期についての概要を示します。
WebSphere Application Server バージョン 6.1 では、 SIP の複製は「ベストエフォート」で行われます。 一般に、SIP コンテナーは、Data Replication Service (DRS) を使用して、 すべての状態情報を複製します。DRS は、データの複製が完了した時期を確認する方法を提供しません。 したがって、唯一定量化できることは、複製用の状態情報の 1 つがキューに入れられた時期です。 このトピック内では、データの複製に対する参照では、複製用のデータがキューに入れられたことのみを意味します。
カテゴリーにはさまざまなデータ型が含まれており、これらについては後述します。 複製の観点から、各データ・オブジェクトは別個に扱います。 言い換えると、アプリケーション・セッション・オブジェクトに対する変更 (複製の原因となる) は、 内部状態情報の複製をもたらすことはありません。
内部状態情報の複製
トランザクション状態は、 WebSphere Application Server 6.1 バージョンの SIP コンテナーでは複製されないことに注意してください。複製されるのは、ダイアログ状態のみです。 トランザクション状態を複製しないことにより、 複製ドメインのすべてのサーバーで負荷が軽減されますが、 トランザクションの半ばに発生する障害問題の原因となる場合があります (例えば、ダイアログ関連の SIP メッセージの欠落など)。
B2BUA とプロキシー・アプリケーション間の重要な相違は、 作成され、複製されるセッション・オブジェクト数です。 どちらの場合も アプリケーション・セッションは 1 つしか作成されませんが、B2BUA の場合は、2 つのセッション・オブジェクトが 作成されます。1 つはインバウンド・レグ用、もう 1 つはアウトバウンド・レグ用です。 プロキシー・アプリケーションの場合は、単一セッション・オブジェクトのみが作成されます。
アプリケーション状態情報の複製
* 「最終アクセスのタイム・スタンプ」をクラスターのピア・コンテナー (複数可) と同期させるために、SipSession および SipApplicationSession の複製の原因となります。 これは、SipSession.getLastAccessedTime() および SipApplicationSession.getLastAccessedTime() に対して、将来の呼び出しの整合性をとるためのものです。
アプリケーションが request.getApplicationSession(true) を呼び出す場合と、 addTimer() および/または addAttribute() が結果であるアプリケーション・セッション・オブジェクトで 呼び出される場合は、ダイアログを確立していない要求に対して複製が発生する可能性があります。 これは、タイマーが期限切れになるときにリスナーが呼び出されるようにするために必要です。
SIP フェイルオーバーおよび複製のセットアップの考慮事項
複製およびフェイルオーバーを必要とする SIP クラスターは、 数多くの複製ドメインから構成することができます。また、それぞれの複製ドメインは、SIP コンテナーのセットで構成されています。 クラスターのコンテナー数には制限がありません。 パフォーマンス上の理由で、各複製ドメインに含めるコンテナーは、2 つに制限します。
複製ドメインは、ドメイン全体に設定する必要があります。つまり、状態は、 複製ドメインのすべてのコンテナーに複製されます。 複製モードは、クライアントとサーバーの両方に設定する必要があります。
コンテナーの分散セッションは、メモリー間の複製に設定する必要があります。 セッションの複製を必要とするアプリケーションには、 web.xml ファイルおよび sip.xml ファイルに <distributable/> タグが 含まれていなければなりません。SIP と HTTP の両方は、同一の複製トポロジーを使用しています。