SIP のセッション・アフィニティーとフェイルオーバー

WebSphere の SIP によって、 セッション・アフィニティーとフェイルオーバーが提供されます。

SIP セッション・アフィニティー

クラスター内の単一の SIP コンテナーによって、 単一のダイアログに関連したすべてのメッセージを処理します。 ダイアログ中にコンテナーに障害が発生すると、 クラスター内の単一のサーバーがダイアログの実行を引き継ぎます。 セッション ID (この中に論理サーバー名が含まれます) に基づいて、セッション・アフィニティーを維持することが、 SIP プロキシーの役割です。 論理サーバー情報は、SIP コンテナーによって公開され、 ワークロード管理システム (WLM) を介して SIP プロキシーで使用されます。

セッション ID に基づく SIP メッセージのルーティング

ibmsid は、さまざまな SIP メッセージに組み込まれ、 SIP アプリケーション・サーバー上で実行される特定のセッションの、 経路指定を行うために使用されます。 一般に、応答を経路指定するためには、VIA ヘッダーが常に使用されます。 SIP アプリケーション・サーバーに 関連した VIA に ibmsid を組み込むのは、常にコンテナーが行います。 このような VIA ヘッダーの例は、以下のようになります。

Via: SIP/2.0/UDP 9.51.252.69:5063;ibmsid=sipcontainer1.1153242645968.4_2_2;branch=z9hG4bK920196437955379

プロキシー・アプリケーションの場合、ibmsid (またはセッション ID) は、 レコード経路の UAC から受信した初期要求に挿入されます。 UAS は、応答において、セッション ID を持つ同じレコード経路を戻します。 UAC は、ダイアログ内の後続の要求において、 セッション ID を持つ経路ヘッダーを戻します。 以下に例を示します。

Record-Route: <sip:protocol2.databeam.com:5060;transport=udp;ibmsid=sipcontainer1a.1138119214953.4_2_2;lr>
この例の場合、UAS は、応答において、セッション ID を持つ 同じレコード経路を戻します。UAC は、 ダイアログ内の後続の要求において、 セッション ID を持つ経路ヘッダーを戻します。

UAC および UAS アプリケーションの 場合、UAC または UAS として機能するコンテナーは、 送信先タグ (UAS) または発信元タグ (UAC) (すなわち、 送信先タグ local.1132518053302_2_2) に、セッション ID を挿入します。 後続の要求には、同じ送信先または発信元のタグが組み込まれます。

エンコード済み URI にも、ibmappid (ibmsid に 極めてよく似ています) が含まれます。 これは、後続の HTTP 要求で送信することができます。 ここで重要な点は、IBM SIP インフラストラクチャーは、 トランザクション・レベルのフェイルオーバーを サポートしていないということです。 サポートされるのは、継続的呼び出しのためのダイアログ・フェイルオーバーのみです。

アウトバウンド SIP メッセージに組み込まれて、 連絡ヘッダーに使用されるアドレスを、IBM SIP インフラストラクチャーが決定する方法に関する、 一般的なルールを紹介します。
  • スタンドアロン SIP アプリケーション・ サーバーは、SIP メッセージに挿入する必要がある連絡ヘッダーに、 独自のアドレスを使用します。
  • ステートレス SIP プロキシーが代表となる SIP アプリケーション・サーバーは、SIP メッセージに挿入する必要がある連絡ヘッダーに、SIP プロキシーのアドレスを使用します。 SIP アプリケーション・サーバーは、このアドレスを WLM 経由で見つけます。
  • ステートレス SIP プロキシーが代表となり、次いで IP スプレイヤーが代表となる SIP アプリケーション・サーバーは、SIP メッセージに挿入する必要がある連絡ヘッダーに、IP スプレイヤーのアドレスを使用します。 IP スプレイヤーのアドレスは、 管理コンソールを介して、SIP プロキシーで構成する必要があります。 また、このアドレスは、UCF を介して、SIP アプリケーションに 公開されます。
呼び出し中のフェイルオーバー

サーバーに障害が発生すると、 障害が起こったサーバーに関連したセッションは、 複製ドメイン内の残りのコンテナーでアクティブになります。 アクティブになった後、 失敗したセッションを処理するコンテナーは、WLM を 介して、クラスターの代表となるプロキシー・サーバーに、 セッションのロケーションを公開します。 失敗したダイアログのいずれかに関連したメッセージが プロキシーに到着すると、 そのプロキシーは SIP メッセージからセッション ID をプルし、 そのセッション ID を使用して、新規コンテナーを検索します。 障害が発生したサーバーが再始動されると、そのセッション ID は再びクラスターに追加されます。 再始動したサーバーでは、新規に作成したダイアログのみが処理されます。

図 1. クラスター内での SIP コンテナーのフェイルオーバー (事前)

クラスター内での SIP コンテナーのフェイルオーバー

図 2. クラスター内での SIP コンテナーのフェイルオーバー (事後)

クラスター内での SIP コンテナーのフェイルオーバー
集中アプリケーションおよびフェイルオーバー

HTTP/SIP 集中セッションに関連したすべてのメッセージは、 エンコード済み URI と SIP セッション・ アフィニティーをプロキシーが使用することで、 同一のバックエンド・コンテナーに経路指定されます。 HTTP および SIP は、同一の複製トポロジー (これらは同じ複製設定を共有します) を利用します。 障害が発生した場合は、 失敗したダイアログに関連した HTTP と SIP の両方の要求が、 同一の新規バックエンド・サーバーに経路指定されます。 アフィニティー・ターゲットが判別されている場合、プロキシー内では Jsession Cookie が Encoded URI に優先します。

図 3. 集中アプリケーションの例

クラスター内での SIP コンテナーのフェイルオーバー

トピックのタイプを示すアイコン 概念トピック



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