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 を持つ経路ヘッダーを戻します。 以下に例を示します。
この例の場合、UAS は、応答において、セッション ID を持つ 同じレコード経路を戻します。UAC は、 ダイアログ内の後続の要求において、 セッション ID を持つ経路ヘッダーを戻します。Record-Route: <sip:protocol2.databeam.com:5060;transport=udp;ibmsid=sipcontainer1a.1138119214953.4_2_2;lr>
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 コンテナーのフェイルオーバー (事前)図 2. クラスター内での SIP コンテナーのフェイルオーバー (事後)- 集中アプリケーションおよびフェイルオーバー
HTTP/SIP 集中セッションに関連したすべてのメッセージは、 エンコード済み URI と SIP セッション・ アフィニティーをプロキシーが使用することで、 同一のバックエンド・コンテナーに経路指定されます。 HTTP および SIP は、同一の複製トポロジー (これらは同じ複製設定を共有します) を利用します。 障害が発生した場合は、 失敗したダイアログに関連した HTTP と SIP の両方の要求が、 同一の新規バックエンド・サーバーに経路指定されます。 アフィニティー・ターゲットが判別されている場合、プロキシー内では Jsession Cookie が Encoded URI に優先します。
図 3. 集中アプリケーションの例