WebLogic Server SIP Container 管理者ガイド

11g リリース1(11.1.1)

B61429-02(原本部品番号:E15459-02)

目次へ

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティ

- 関連ドキュメント

- 表記規則

1 Oracle WebLogic SIP Containerの構成

- 1.1 Oracle WebLogic SIP Container

- 1.1.1 WebLogic Server 10.3プラットフォームのSIPと集中型アプリケーションのサポート

- 1.2 共有構成タスク

- 1.2.1 SIPコンテナとWebLogic Serverの共有構成タスク

- 1.2.2 Oracle WebLogic Server SIP Containerの構成の概要

- 1.2.2.1 Diameterの構成

- 1.2.3 構成タスクを実行するための方法とツール

- 1.2.3.1 管理コンソール

- 1.2.3.2 WebLogic Scripting Tool (WLST)

- 1.2.3.3 追加の構成方法

- 1.2.4 サーバーの起動と停止

- 1.2.5 管理サーバーのベスト・プラクティス

- 1.2.6 一般的な構成タスク

2 SIPサーブレット・コンテナ・プロパティの構成

- 2.1 SIPコンテナ構成の概要

- 2.2 コンテナ・プロパティを構成するための管理コンソールの使用

- 2.2.1 構成のロックおよび永続性

- 2.3 WLST (JMX)のによるコンテナ・プロパティの構成

- 2.3.1 構成ロックの管理

- 2.3.2 Oracle WebLogic Server SIP ContainerのMBeanの検出

- 2.4 WLSTの構成

- 2.4.1 WLSTの起動

- 2.4.2 MBeanの作成および削除

- 2.5 タイマー処理の構成

- 2.5.1 タイマー・アフィニティの構成(オプション)

- 2.5.2 正確なSIPタイマーのNTPの構成

3 ネットワーク・リソースの管理

- 3.1 ネットワーク構成の概要

- 3.1.1 IPv4とIPv6

- 3.2 ロード・バランサ・アドレスの構成

- 3.2.1 複数のロード・バランサおよびDNSロード・バランサ

- 3.3 ドメイン名サービス(DNS)サポートの有効化

- 3.4 SIPまたはSIPSのネットワーク・チャネルの構成

- 3.4.1 既存チャネルの再構成

- 3.4.2 新規SIPまたはSIPSチャネルの作成

- 3.4.3 カスタム・タイムアウト、MTU、および他のプロパティの構成

- 3.4.4 DNSマシンのSIPチャネルの構成

- 3.5 DiameterサポートのTCPおよびTLSチャネルの構成

- 3.6 任意のIPインタフェース上でリスニングするエンジン・サーバーの構成

- 3.7 SIPデータ層レプリカの一意のリスニング・アドレス属性の構成

- 3.8 本番ネットワーク・アーキテクチャおよび構成

- 3.8.1 TCPおよびUDPチャネルを使用した単一のNIC構成

- 3.8.1.1 アウトバウンドUDPパケットの静的なポート構成

- 3.8.2 DNSサーバー構成の概要

- 3.8.3 すべてのアドレス(IP_ANY)にリスニングするDNSサーバー

- 3.8.4 複数のサブネットにリスニングするDNSサーバー

- 3.8.4.1 ルート・リゾルバの理解

- 3.8.4.2 DNSハードウェアに関するIPの別名

- 3.8.5 ロード・バランサの構成

- 3.8.5.1 単一のロード・バランサの構成

- 3.8.5.2 複数のロード・バランサおよびDNSロード・バランサ

- 3.8.5.3 ネットワーク・アドレス変換オプション

- 3.9 例として使用するネットワーク構成

- 3.9.1 例として使用するネットワーク・トポロジ

- 3.9.2 Oracle WebLogic Server SIP Containerの構成

- 3.9.3 ロード・バランサの構成

- 3.9.3.1 NATベースの構成

- 3.9.3.2 maddrベースの構成

- 3.9.3.3 rportベースの構成

4 SIPデータ層パーティションおよびレプリカの構成

- 4.1 SIPデータ層構成の概要

- 4.1.1 datatier.xml構成ファイル

- 4.1.2 構成要件および制限

- 4.2 SIPデータ層サーバーの構成および管理のベスト・プラクティス

- 4.3 SIPデータ層構成および構成ファイルの例

- 4.3.1 パーティションを1つ持つSIPデータ層

- 4.3.2 パーティションを2つ持つSIPデータ層

- 4.3.3 パーティションを2つおよびレプリカを2つ持つSIPデータ層

- 4.4 存続期間が長い呼出し状態データのRDBMSへの保存

- 4.4.1 要件および制約

- 4.4.2 RDBMS呼出し状態ストレージを有効化する手順

- 4.4.3 構成ウィザードのRDBMSストア・テンプレートの使用

- 4.4.3.1 JDBCデータソース接続情報の変更

- 4.4.4 手動によるRDBMS呼出し状態ストレージの構成

- 4.4.4.1 JDBCリソースの構成

- 4.4.4.2 Oracle WebLogic Server SIP Containerの永続性オプションの構成

- 4.4.4.3 データベース・スキーマの作成

- 4.4.5 SIPアプリケーションにおける永続性ヒントの使用

- 4.5 地理的冗長性の概要

- 4.5.1 地理的冗長性の使用に最適な状況

- 4.5.2 地理的冗長性の使用に適していない状況

- 4.5.3 地理的冗長性の考慮: 開始前

- 4.6 地理的に冗長なSIPデータ層の使用

- 4.6.1 例として使用するドメイン構成

- 4.6.2 要件および制約

- 4.6.3 地理的永続性を構成するための手順

- 4.6.4 構成ウィザードの地理的永続性用テンプレートの使用

- 4.6.4.1 プライマリ・サイトのインストールおよび構成

- 4.6.4.2 セカンダリ・サイトのインストール

- 4.6.5 手動による地理的冗長性の構成

- 4.6.5.1 JDBCリソースの構成(プライマリおよびセカンダリ・サイト)

- 4.6.5.2 永続性オプションの構成(プライマリおよびセカンダリ・サイト)

- 4.6.5.3 JMSリソースの構成(セカンダリ・サイトのみ)

- 4.6.6 地理的に冗長なレプリケーション動作の理解

- 4.6.6.1 呼出し状態レプリケーション・プロセス

- 4.6.6.2 フェイルオーバー後の呼出し状態の処理

- 4.6.7 呼出し状態のバックアップの削除

- 4.6.8 地域サイト全体に渡るレプリケーションの監視

- 4.6.9 地理的レプリケーションのトラブルシューティング

- 4.7 エンジン層におけるSIPデータのキャッシュ

- 4.7.1 エンジン層キャッシュの構成

- 4.7.2 キャッシュ・パフォーマンスの監視およびチューニング

- 4.8 SIPデータ層サーバーの監視およびトラブルシューティング

5 監視およびトラブルシューティング

- 5.1 サーバー障害の回避およびリカバリ

- 5.1.1 障害の保護および自動リカバリ機能

- 5.1.1.1 過負荷保護

- 5.1.1.2 クラスタリングされたサービスの冗長性およびフェイルオーバー

- 5.1.1.3 障害が発生したサーバー・インスタンスの自動再起動

- 5.1.1.4 管理対象サーバーの独立モード

- 5.1.1.5 障害が発生した管理対象サーバーの自動移行

- 5.1.1.6 地域サイト障害時の地理的冗長性

- 5.1.2 障害リカバリ用のディレクトリおよびファイルのバックアップ

- 5.1.2.1 自動構成バックアップの有効化

- 5.1.2.2 ドメイン構成オフラインの保存

- 5.1.2.3 サーバー起動スクリプトのバックアップ

- 5.1.2.4 ロギング・サーブレット・アプリケーションのバックアップ

- 5.1.2.5 セキュリティ・データのバックアップ

- 5.1.2.6 追加のオペレーティング・システム構成ファイルのバックアップ

- 5.1.3 障害が発生した管理サーバーの再起動

- 5.1.3.1 同じマシンにおける管理サーバーの再起動

- 5.1.3.2 別のマシンにおける管理サーバーの再起動

- 5.1.4 障害が発生した管理対象サーバーの再起動

- 5.2 フェイルオーバー検出の概要

- 5.2.1 WlssEchoServerの障害検出

- 5.2.2 障害が発生したレプリカの強制シャットダウン

- 5.3 物理的なネットワーク障害のフェイルオーバー・パフォーマンスの向上

- 5.3.1 SIPデータ層サーバー・マシンにおけるWlssEchoServerの起動

- 5.3.2 サーバーにおけるハートビート・メカニズムの有効化および構成

- 5.4 SNMPの構成

- 5.4.1 MIBの参照

- 5.4.2 SNMPを構成するための手順

- 5.5 SNMPトラップの理解および応答

- 5.5.1 トラブルシューティング用ファイル

- 5.5.2 トラップの説明

- 5.5.2.1 connectionLostToPeer

- 5.5.2.2 connectionReestablishedToPeer

- 5.5.2.3 dataTierServerStopped

- 5.5.2.4 overloadControlActivated, overloadControlDeactivated

- 5.5.2.5 replicaAddedToPartition

- 5.5.2.6 replicaRemovedEnginesRegistration

- 5.5.2.7 replicaRemovedFromPartition

- 5.5.2.8 serverStopped

- 5.5.2.9 sipAppDeployed

- 5.5.2.10 sipAppUndeployed

- 5.5.2.11 sipAppFailedToDeploy

- 5.6 WebLogic診断フレームワーク(WLDF)の使用

- 5.6.1 データ収集およびロギング

- 5.6.2 監視と通知

- 5.6.3 イメージ・キャプチャ

- 5.6.4 インストゥルメンテーション

- 5.6.4.1 サーバー・スコープ・モニターの構成

- 5.6.4.2 アプリケーション・スコープ・モニターの構成

- 5.7 SIPリクエストおよびレスポンスのロギング

- 5.7.1 sip.xmlにおけるロギング・サーブレットの定義

- 5.7.2 ロギング・レベルおよび宛先の構成

- 5.7.3 ロギング・メッセージの基準の指定

- 5.7.3.1 ロギング基準を指定するためのXMLドキュメントの使用

- 5.7.3.2 ロギング基準を指定するためのサーブレット・パラメータの使用

- 5.7.4 暗号化されていないロギングのコンテンツ・タイプの指定

- 5.7.5 ログ・ローテーションの有効化およびログ・ファイルの表示

- 5.7.6 trace-pattern.dtdリファレンス

- 5.7.7 SIPサーブレット・コードへのトレース機能の追加

- 5.7.8 リスナーおよびロギング・サーブレットの起動順序

- 5.8 本番デプロイメントのJVMガベージ・コレクションのチューニング

- 5.8.1 サーバー起動スクリプトにおけるJVMパラメータの変更

- 5.8.2 JRockitを使用したガベージ・コレクションのチューニング

- 5.8.3 Oracle JRockitリアルタイム(確定的ガベージ・コレクション)の使用

- 5.8.4 確定的ガベージ・コレクションを使用しないOracle JRockitの使用

- 5.8.5 Sun JDKを使用したガベージ・コレクションのチューニング

- 5.9 乱数生成によって発生するJVM遅延の回避

6 Diameterクライアント・ノードとリレー・エージェントの構成

- 6.1 Diameterプロトコル構成の概要

- 6.2 Diameterクライアント・ノードとリレー・エージェントの構成の手順

- 6.3 Diameterドメインのインストール

- 6.4 Diameterコンソール拡張の有効化

- 6.5 DiameterプロトコルのTCP、TLS、SCTPネットワーク・チャネルの作成

- 6.5.1 Diameter TLSチャネル用の双方向SSLの構成

- 6.5.2 DiameterメッセージングのためのSCTPの構成と使用

- 6.6 Diameterノードの構成

- 6.6.1 新しいノード構成の作成(一般的なノード構成)

- 6.6.2 Diameterアプリケーションの構成

- 6.6.2.1 Shクライアント・アプリケーションの構成

- 6.6.2.2 Rfクライアント・アプリケーションの構成

- 6.6.2.3 Roクライアント・アプリケーションの構成

- 6.6.2.4 Diameterリレー・エージェントの構成

- 6.6.2.5 ShおよびRfシミュレータ・アプリケーションの構成

- 6.6.2.6 プロファイル・サービスの有効化(Shバックエンド使用)

- 6.6.3 ピア・ノードの構成

- 6.6.4 ルートの構成

- 6.7 ドメイン構成の例

- 6.8 Diameter構成のトラブルシューティング

7 Oracle WebLogic Server SIP Containerベース・プラットフォームのトポロジ

- 7.1 Oracle WebLogic Server SIP Containerベース・プラットフォームの目的

- 7.2 ロード・バランサ

- 7.3 エンジン層

- 7.4 SIPデータ層

- 7.4.1 呼出し状態データの書込みと取得の例

- 7.4.2 存続期間が長い呼出し状態データのRDBMSへの格納

- 7.5 地理的に冗長なインストール

- 7.6 ハードウェア構成の例

- 7.7 他の構成

8 デプロイ済SIPアプリケーションのアップグレード

- 8.1 SIPアプリケーションのアップグレードの概要

- 8.2 デプロイ済アプリケーションをアップグレードする場合の要件と制限

- 8.3 デプロイ済SIPアプリケーションをアップグレードする手順

- 8.4 バージョン識別子の割当

- 8.4.1 マニフェストでのバージョンの定義

- 8.5 更新バージョンのアプリケーションのデプロイ

- 8.6 以前のバージョンのアプリケーションのアンデプロイ

- 8.7 アップグレード処理のロールバック

- 8.8 アプリケーション名とバージョン識別子へのアクセス

- 8.9 管理モードの使用

A SIPサーブレット・コンテナ構成リファレンス

- A.1 sipserver.xmlの概要

- A.2 sipserver.xmlの編集

- A.2.1 sipserver.xmlの編集手順

- A.3 XMLスキーマ

- A.4 sipserver.xmlファイルの例

- A.5 XML要素の説明

- A.5.1 enable-timer-affinity

- A.5.2 overload

- A.5.2.1 適切なオーバーロード・ポリシーの選択

- A.5.2.2 セッション生成率に基づいた過負荷制御

- A.5.2.3 容量の制約に基づいた過負荷制御

- A.5.2.4 過負荷保護の2つのレベル

- A.5.3 message-debug

- A.5.4 プロキシ: アウトバウンド・プロキシ・サーバーの設定

- A.5.5 t1-timeout-interval

- A.5.6 t2-timeout-interval

- A.5.7 t4-timeout-interval

- A.5.8 timer-b-timeout-interval

- A.5.9 timer-f-timeout-interval

- A.5.10 max-application-session-lifetime

- A.5.11 enable-local-dispatch

- A.5.12 cluster-loadbalancer-map

- A.5.13 default-behavior

- A.5.14 default-servlet-name

- A.5.15 retry-after-value

- A.5.16 sip-security

- A.5.17 route-header

- A.5.18 engine-call-state-cache-enabled

- A.5.19 server-header

- A.5.20 server-header-value

- A.5.21 persistence

- A.5.22 use-header-form

- A.5.23 enable-dns-srv-lookup

- A.5.24 connection-reuse-pool

- A.5.25 globally-routable-uri

- A.5.26 domain-alias-name

- A.5.27 enable-rport

- A.5.28 image-dump-level

- A.5.29 stale-session-handling

- A.5.30 enable-contact-provisional-response

- A.5.31 app-router

- A.5.32 use-custom-app-router

- A.5.33 app-router-config-data

- A.5.34 custom-app-router-jar-file-name

- A.5.35 default-application-name

B SIPデータ層構成リファレンス

- B.1 datatier.xmlの概要

- B.2 datatier.xmlの編集

- B.3 XMLスキーマ

- B.4 datatier.xmlファイルの例

- B.5 XML要素の説明

C Diameter構成リファレンス

- C.1 diameter.xmlの概要

- C.2 グラフィカル表現

- C.3 diameter.xmlの編集

- C.3.1 diameter.xml編集の手順

- C.4 XMLスキーマ

- C.5 diameter.xmlファイルの例

- C.6 XML要素の説明

- C.6.1 構成

- C.6.2 ターゲット

- C.6.3 ホスト

- C.6.4 レルム

- C.6.5 アドレス

- C.6.6 ポート

- C.6.7 tls-enabled

- C.6.8 sctp-enabled

- C.6.9 debug-enabled

- C.6.10 message-debug-enabled

- C.6.11 アプリケーション

- C.6.11.1 class-name

- C.6.11.2 param*

- C.6.12 peer-retry-delay

- C.6.13 allow-dynamic-peers

- C.6.14 request-timeout

- C.6.15 watchdog-timeout

- C.6.16 supported-vendor-id+

- C.6.17 include-origin-state

- C.6.18 peer+

- C.6.18.1 ホスト

- C.6.18.2 アドレス

- C.6.18.3 ポート

- C.6.18.4 プロトコル

- C.6.19 ルート

- C.6.19.1 レルム

- C.6.19.2 application-id

- C.6.19.3 アクション

- C.6.19.4 server+

- C.6.20 default-route

- C.6.20.1 アクション

- C.6.20.2 server+

D 起動コマンド・オプション

E サポートされるプラットフォーム、プロトコル、RFCおよび標準

- E.1 サポートされる構成

- E.2 サポートされるSIPクライアント

- E.3 サポートされるロード・バランサ

- E.4 サポートされるデータベース

- E.5 Oracle WebLogic Server SIP Container標準アラインメントの概要

- E.6 Java Sun Recommendation (JSR)標準への準拠

- E.7 IETF RFCへの準拠

- E.8 3GPP R6仕様への適合

F Oracle WebLogic SIP Containerのエクスポート/インポートの使用

- F.1 エクスポート

- F.1.1 現在の環境からのデータベース・データのエクスポート

- F.2 インポート

索引

Oracle® WebLogic Server SIP Container

管理者ガイド

11g リリース1(11.1.1)

B61429-02(原本部品番号:E15459-02)

2011年1月

Oracle WebLogic Server SIP Container管理者ガイド, 11g リリース1 (11.1.1)

B61429-02

Copyright © 2006, 2011, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。 ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。 このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。 誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。 このソフトウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。 このソフトウェアを危険が伴うアプリケーションで使用する際、このソフトウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。 このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。 その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。 オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。 オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

この本では、Oracle WebLogic SIP Containerのトポロジ、構成および概念的なトピックについて説明します。この章は、次のトピックがあります。

- 対象読者

- ドキュメントのアクセシビリティ

- 関連ドキュメント

- 表記規則

対象読者

組織内でOracle WebLogic SIP Containerを設定および管理するシステム管理者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社は、障害のあるお客様を含めたすべてのお客様に、オラクル社の製品、サービスおよびサポート・ドキュメントをご利用いただけることを目標としています。 オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。 HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。 標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。 オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じカッコだけを行に記述する必要があります。しかしJAWSはカッコだけの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。 オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

聴覚に障害があるお客様のOracleサポート・サービスへのアクセス

Oracleサポート・サービスに連絡するには、テレコミュニケーション・リレー・サービス(TRS)を使用してOracleサポート(+1-800-223-1711)までお電話ください。Oracleサポート・サービスの技術者が、Oracleサービス・リクエストのプロセスに従って、技術的な問題を処理し、お客様へのサポートを提供します。TRSの詳細は、http://www.fcc.gov/cgb/consumerfacts/trs.htmlを参照してください。電話番号の一覧は、http://www.fcc.gov/cgb/dro/trsphonebk.htmlを参照してください。

関連ドキュメント

詳細は、ドキュメント・セットの次のドキュメントを参照してください。

- Oracle WebLogic SIP Containerインストレーション・ガイド

- Oracle WebLogic SIP Container開発者ガイド

- Oracle Fusion Middleware 11gリリース・ノート

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Oracle WebLogic SIP Containerの構成

次の項では、Oracle WebLogic SIP Container (OWLSC)の紹介、およびOracle WebLogic Server SIP Containerデプロイメントの構成と管理方法について説明しています。

- 1.1項「Oracle WebLogic SIP Container」

- 1.2項「共有構成タスク」

1.1 Oracle WebLogic SIP Container

Oracle WebLogic Server SIP Container 11g (OWLSC)は、通信サービスをエンタープライズ・サービスおよびアプリケーションと統合するために設計されている包括的なプラットフォームです。これには、キー通信チャネルとの相互作用をサポートするために使用する簡単なサービスが含まれます。

表1-1では、Oracle WebLogic Server SIP Containerの簡単な概要を示します。その詳細は、次の章で説明されています。

図1-1 OWLSCの概要

「図1-1 OWLSCの概要」の説明

1.1.1 WebLogic Server 10.3プラットフォームのSIPと集中型アプリケーションのサポート

OWLSCは、JSR 289準拠のSIPコンテナを持つコアWebLogic Serverプラットフォームを拡張します。これにより、拡張された通信アプリケーションのために、HTTPとともにSIPを処理するJ2EEアプリケーションの開発ができます。プラットフォームでは、SIPベースのIP-PBX、および標準SIPクライアントなど他のSIP要素と統合する補足的な通信サービスの開発ができます。

即時利用可能なOWLSCは、SIPベースのネットワークをビルドするキー・インフラストラクチャ・アプリケーションを提供します。

1.2 共有構成タスク

次の項では、Oracle WebLogic SIP ContainerとOracle WebLogic Serverで共通の構成タスクについて概要を説明します。次のトピックがあります。

- 1.2.1項「SIPコンテナとWebLogic Serverの共有構成タスク」

- 1.2.2項「Oracle WebLogic Server SIP Containerの構成の概要」

- 1.2.3項「構成タスクを実行するための方法とツール」

- 1.2.4項「サーバーの起動と停止」

- 1.2.5項「管理サーバーのベスト・プラクティス」

- 1.2.6項「一般的な構成タスク」

1.2.1 SIPコンテナとWebLogic Serverの共有構成タスク

Oracle WebLogic Server SIP Containerは、Oracle WebLogic Server 10g リリース3アプリケーション・サーバーに基づいており、システム・レベルの構成タスクの多くは両製品で共通しています。このガイドでは、Oracle WebLogic Server SIP Containerに一意のシステム・レベルの構成タスクのみを指定します。たとえば、ネットワークとセキュリティの構成や、エンジン層とSIPデータ層のクラスタ構成用のタスクなどです。

HTTPサーバーの構成や、その他の基本的な構成タスク(サーバー・ロギングなど)は、Oracle WebLogic Serverドキュメントを参照してください。開始方法は、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』を参照してください。

1.2.2 Oracle WebLogic Server SIP Containerの構成の概要

Oracle WebLogic Server SIP ContainerのSIPサーブレット・コンテナ、SIPデータ層のレプリケーション、およびDiameterプロトコル機能はカスタム・リソースとしてOracle WebLogic Server 10g リリース3製品に実装されています。カスタム・リソースのsipserverとdatatierのペアは、エンジン層のSIPサーブレット・コンテナ機能とSIPデータ層のレプリケーション機能を実装します。本番デプロイメントには通常、両方のリソースがインストールされています。特化デプロイメントでは、SIP対応ロード・バランサとともにsipserverリソースのみが使用できます。

別のカスタム・リソースdiameterは、Diameterベース・プロトコル機能を提供します。1つ以上のDiameterプロトコル・アプリケーションを利用するデプロイメントにのみ必要です。

Oracle WebLogic SIP Containerのカスタム・リソースの割当ては、ドメイン構成ファイルconfig.xmlで表示できますが、変更はできません。各リソースの定義を、例1-1に示します。sipserverとdatatierリソースは、それぞれ同じサーバーとクラスタに割り当てる必要があります。リソースはエンジン層とSIPデータ層の両方のクラスタにデプロイされます。

例1-1 Oracle WebLogic Server SIP Containerのカスタム・リソース

<custom-resource>
<name>sipserver</name>
<target>ORA_DATA_TIER_CLUST,ORA_ENGINE_TIER_CLUST</target>
<descriptor-file-name>custom/sipserver.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.SipServerResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.SipServerBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>datatier</name>
<target>ORA_DATA_TIER_CLUST,ORA_ENGINE_TIER_CLUST</target>
<descriptor-file-name>custom/datatier.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.DataTierResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.DataTierBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>diameter</name>
<target>ORA_ENGINE_TIER_CLUST</target>
<deployment-order>200</deployment-order>
<descriptor-file-name>custom/diameter.xml</descriptor-file-name>
<resource-class>com.bea.wcp.diameter.DiameterResource</resource-class>
<descriptor-bean-class>com.bea.wcp.diameter.management.descriptor.beans.ConfigurationBean</descriptor-bean-class>
</custom-resource>

Oracle WebLogic Server SIP Containerのカスタム・リソースは、config.xmlに定義されたネットワーク・チャネル、クラスタおよびサーバー構成、Java EEリソースのような基本的なドメイン・リソースを利用します。ただし、Oracle WebLogic Server SIP Containerの特定のリソースは、機能ベースの別々の構成ファイルで設定されます。

- sipserver.xmlは、SIPコンテナ・プロパティと一般的なOracle WebLogic Server SIP Containerエンジン層の機能を設定します。

- datatier.xmlは、SIPデータ層にレプリカとして属するサーバーを識別し、SIPデータ層パーティションの数とレイアウトも定義します。

- diameter.xmlは、Diameterノードおよびドメインで使用するDiameterプロトコル・アプリケーションを設定します。

- approuter.xmlは、デフォルト・アプリケーション・ルーターを構成します。DARの構成の詳細は、『Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

ドメイン構成ファイルconfig.xmlは、ドメインで使用可能なすべての管理対象サーバーを定義することに注意してください。sipserverアプリケーションに含まれるsipserver.xml、datatier.xml、およびdiameter.xml構成ファイルは、SIPデータ層レプリカ、エンジン層ノード、Diameterクライアント・ノードとして動作するかどうかなど、各サーバー・インスタンスのロールを決定します。

SIPサーブレット・コンテナ・プロパティの構成の変更は、管理コンソールまたはWLSTユーティリティのコマンドラインを使用して、実行中のサーバーに対して動的に適用できます(一部のSIPサーブレット・コンテナのプロパティでは、変更後の再起動が必要であることを示す「再起動が必要な場合があります」アイコンが表示されます)。SIPデータ層ノードの構成は動的に変更できないので、パーティションやレプリカの数を変更するには、SIPデータ層サーバーを再起動する必要があります。

1.2.2.1 Diameterの構成

Diameterプロトコルの実装は、SIPサーブレット・コンテナ機能とは別に、カスタム・リソースとして行われます。Diameter構成ファイルは、Diameterノード機能を提供するように1つ以上のDiameterプロトコル・アプリケーションを構成します。Oracle WebLogic Server SIP ContainerはDiameterプロトコル・アプリケーションを提供し、次のノード・タイプをサポートします。

- Diameter Shインタフェース・クライアント・ノード(ホーム・サブスクライバ・サービスの問合せ用)

- Diameter Rfインタフェース・クライアント・ノード(オフラインでのチャージ用)

- Diameter Roインタフェース・クライアント・ノード(オンラインでのチャージ用)

- Diameterリレー・ノード

- HSSシミュレータ・ノード(テストおよび開発にのみ適しており、本番デプロイメントには適しません)

Diameterカスタム・リソースは、Diameterクライアント・ノードまたはリレー・エージェントとして機能する必要があるサーバーを持つドメイン、またはHSSシミュレーション機能を提供するサーバーにのみデプロイされます。サーバー・インスタンスの実際の機能は、diameter.xmlファイルで定義される構成によって異なります。

Oracle WebLogic Server SIP ContainerドメインでDiameter Webアプリケーションを構成する手順は、第6章「Diameterクライアント・ノードとリレー・エージェントの構成」を参照してください。Diameterアプリケーションの開発の詳細は、『Oracle WebLogic Server SIP Container開発者ガイド』を参照してください。

1.2.3 構成タスクを実行するための方法とツール

Oracle WebLogic Server SIP Containerには、SIPサーブレット・コンテナの構成を変更するためのメカニズムが用意されています。

- 1.2.3.1項「管理コンソール」

- 1.2.3.2項「WebLogic Scripting Tool (WLST)」

- 1.2.3.3項「追加の構成方法」

1.2.3.1 管理コンソール

Oracle WebLogic Server SIP Containerには、変更可能な管理コンソールの拡張、SIPサーブレット・コンテナ、SIPサーブレット・ドメイン、グラフィカル・ユーザー・インタフェースを使用するDiameter構成プロパティが用意されています。Oracle WebLogic Server SIP Containerの管理コンソールの拡張は、Oracle WebLogic Server 10g リリース3で利用できるコア・コンソールと似ています。すべてのOracle WebLogic Server SIP Container構成と監視は、コンソールの左ペインにあるこれらのノードを介して提供されます。

- SipServer - SIPサーブレット・コンテナのプロパティとその他のエンジン層の機能を構成します。この拡張を使用して、新規のパーティションの作成、およびSIPデータ層のパーティションとレプリカの表示(変更は不可)もできます。管理コンソールを使用したSIPサーブレット・コンテナの構成の詳細は、第2章「SIPサーブレット・コンテナ・プロパティの構成」を参照してください。

- Diameter - Diameterノードとアプリケーションの構成を行います。

注意:
Oracle WebLogic Server管理コンソールの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソール・スタート・ガイドの項を参照してください。

1.2.3.2 WebLogic Scripting Tool (WLST)

WebLogic Scripting Tool (WLST)では、コマンドライン・インタフェースを使用して、対話型または自動化された(バッチ)構成操作を実行できます。WLSTは実行中のOracle WebLogic Server SIP Containerドメインで利用可能なMBeanの表示や操作ができるJMXツールです。詳細は、第2章「SIPサーブレット・コンテナ・プロパティの構成」では、WLSTを使用してSIPサーブレット・コンテナのプロパティを変更する手順を説明します。

注意:
WLSTの使用方法の詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

1.2.3.3 追加の構成方法

Oracle WebLogic Server SIP Container構成の多くは、管理コンソールまたはWLSTを使用して実行されます。構成タスクによっては、次の項に記述されている方法も使用できます。

1.2.3.3.1 構成ファイルの編集

sipserver.xml、datatier.xml、diameter.xml、およびapprouter.xmlを手動で編集することもできます。構成ファイルを手動で編集する場合は、構成の変更を適用するために、すべてのサーバーを再起動する必要があります。

1.2.3.3.2 カスタムJMXアプリケーション

Oracle WebLogic Server SIP Containerプロパティは、JMX準拠のMBeanで表されます。したがって、適切なOracle WebLogic Server SIP Container MBeanを使用して、SIPコンテナ・プロパティを構成するJMXアプリケーションをプログラムできます。

JMXを使用してOracle WebLogic Server SIP ContainerMBeanプロパティを変更する一般的な手順は、第2章「SIPサーブレット・コンテナ・プロパティの構成」で説明されています(WLST自体はJMXベースのアプリケーションです)。SIPコンテナ・プロパティの処理に使用する個々のMbeanの詳細は、Oracle Fusion Middleware Communication Services Java APIリファレンスを参照してください。

1.2.3.3.3 ログ・レベルの設定

ログ・レベルの設定は、logging.xmlファイルを手動で編集するか、setLoggerLevel(String loggerName, String logLevel) MBeanを設定するか、またはOracle Enterprise Managerを使用して行うことができます。詳細は、『Oracle Fusion Middleware 2日で管理者ガイド』を参照してください。

1.2.4 サーバーの起動と停止

Oracle WebLogic Server SIP Containerの開始スクリプトでは、パフォーマンスに影響する多くのJVMパラメータにデフォルト値が使用されています。たとえば、JVMのガベージ・コレクションやヒープ・サイズのパラメータが省略されていることや、評価や開発以外の目的には適切でない値を使用していることがあります。本番システムでは、十分なパフォーマンスを実現するために、様々なヒープ・サイズやガベージ・コレクションの設定でアプリケーションのプロファイリングを厳密に行う必要があります。

注意:
複数のエンジン層サーバーおよびSIPデータ層サーバーでドメインを構成するときには、SIPプロトコル・スタックを正しく機能させるために、すべてのシステムの時間を共通のタイム・ソースにあわせて、(1または2ミリ秒以下の精度で)正確に同期する必要があります。

通常のOracle WebLogic Server SIP Containerドメインには、多数のエンジン層サーバーおよびSIPデータ層サーバーがあり、異なるタイプのサーバー間に依存関係があるためです。したがって、ドメインを起動するときには、通常、次の手順に従う必要があります。

1. ドメインの管理サーバーを起動します。ドメインでエンジンおよびSIPデータ層サーバーに初期の構成を提供するには、管理サーバーを起動します。管理サーバーは、各管理対象サーバーの起動/停止のステータスを監視する目的にも使用します。通常、管理サーバーの起動には構成ウィザードでインストールされたstartWebLogic.cmdスクリプトを使用するか、またはカスタムの起動スクリプトを使用します。

2. 各パーティションのSIPデータ層サーバーを起動します。SIPデータ層のサーバーで呼出し状態データを処理できるようにならないと、エンジン層は機能しません。リクエストの処理を開始するためには、各パーティションのレプリカがすべて利用できる状態になっている必要はありませんが、同時呼出し状態を処理するためには、構成された各パーティションで少なくとも1つのレプリカを利用できる必要があります。本番ネットワーク・トラフィックに対してシステムを開く前に、すべてのレプリカが起動して利用可能な状態になっている必要があります。
通常、各SIPデータ層サーバーの起動には構成ウィザードでインストールされたstartManagedWebLogic.cmdスクリプトを使用するか、またはカスタムの起動スクリプトを使用します。startManagedWebLogic.cmdでは、起動するサーバーの名前と、ドメインの管理サーバーのURLを指定する必要があります。たとえば、次のように指定します。

startManagedWebLogic.cmd datanode0-0 t3://adminhost:7001

3. エンジン層サーバーを起動します。SIPデータ層サーバーを起動したら、エンジン層でサーバーを起動して、クライアント・リクエストの処理を開始できます。エンジン層サーバーも、SIPデータ層サーバーと同様に、通常はstartManagedWebLogic.cmdスクリプトまたはカスタムの起動スクリプトを使用して起動します。

以上の起動シーケンスに従うと、すべての管理対象サーバーで、最新のSIPサーブレット・コンテナとSIPデータ層の構成が確実に使用されます。また、この起動シーケンスなら、SIPデータ層のサーバーを利用できないときに生成されるエンジン層のエラー・メッセージも回避できます。

1.2.5 管理サーバーのベスト・プラクティス

サービスおよびアプリケーションの構成、デプロイ、および監視のために、Oracle WebLogic Server SIP Containerインストールで管理サーバーが必要です。

注意:
ハードウェア、ソフトウェア、またはネットワークの問題によって管理サーバーで障害が発生した場合に、その影響が及ぶのは、管理、デプロイメント、およびモニターの処理に対してのみです。管理対象サーバーが稼働を続けるうえでは、管理サーバーは必要ありません。つまり、管理サーバーで障害が発生した場合でも、管理対象サーバー・インスタンスで実行中のJava EEアプリケーションとSIP機能は引続き動作します。

Oracle WebLogic Server SIP Containerドメインの管理サーバーと管理対象サーバーのインスタンスを構成するには、次のベスト・プラクティスをお薦めします。

- 管理サーバーのインスタンスは、専用のマシンで稼働させます。管理サーバー・マシンには管理対象サーバー・マシンと同程度のメモリー容量が必要ですが、管理という目的のうえでは、通常は単一のCPUで問題ありません。

- 管理対象サーバーの独立性を使用するように管理対象サーバーのすべてのインスタンスを構成します。管理対象サーバーの独立性とは、ネットワーク、ハードウェア、またはソフトウェアの障害によって管理サーバーにアクセスできない場合でも管理対象サーバーを再起動できる機能です。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。

- Oracle WebLogic Server SIP Containerドメインのすべての管理対象サーバーを自動的に再起動するようにノード・マネージャ・ユーティリティを構成します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』を参照してください。

管理サーバーのインスタンスまたはマシンで障害が発生した場合でも、その影響が及ぶのは、構成、デプロイメント、およびモニターの各機能のみであり、管理対象サーバーは引続き動作して、クライアント・リクエストの処理を続けます。管理サーバーの障害によって次の喪失が生じる可能性があります:

- 進行中の管理およびデプロイメントの処理の喪失。

- 進行中のロギング機能の喪失。

- (Oracle WebLogic Server SIP Containerインスタンスのトラップ生成ではなく)WebLogic ServerインスタンスのSNMPトラップ生成の喪失。管理対象サーバーでは、Oracle WebLogic Server SIP Containerトラップは管理サーバーがなくても生成されます。

通常の運用を再開するために、障害が発生した管理サーバー・インスタンスはできるだけ早く再起動してください。

1.2.6 一般的な構成タスク

Oracle WebLogic Server SIP Containerの一般的な管理とメンテナンスでは、WebLogic Serverの構成プロパティとOracle WebLogic Server SIP Containerのコンテナ・プロパティの両方を管理することが必要です。これらの一般的な構成タスクを表1-1に要約します。

表1-1 Oracle WebLogic Server SIP Containerの一般的な構成タスク

タスク

説明

第2章

- 管理コンソールを使用してSIPコンテナ・プロパティを構成します。

- WLSTを使用してバッチ構成を実行します。

第4章「SIPデータ層のパーティションとレプリカの構成」

- Oracle WebLogic Server SIP ContainerインスタンスをSIPデータ層のパーティションに割り当てます。

- SIPデータ層の複数のインスタンスを使用して呼出し状態をレプリケートします。

第3章「ネットワーク・リソースの管理」

- SIPおよびHTTPのトラフィックを処理するようにWebLogic Serverネットワーク・チャネルを構成します。

- マルチ・ホーム・サーバーのハードウェアを設定します。

- Oracle WebLogic Server SIP Containerで使用するロード・バランサを構成します。

2 SIPサーブレット・コンテナ・プロパティの構成

次の項は、Oracle WebLogic Server SIP Containerデプロイメントのエンジン層でSIPコンテナの機能を構成する方法を説明します。

- 2.1項「SIPコンテナ構成の概要」

- 2.2項「コンテナ・プロパティを構成するための管理コンソールの使用」

- 2.3項「WLST (JMX)によるコンテナ・プロパティの構成」

- 2.4項「WLSTの構成」

- 2.5項「タイマー処理の構成」

2.1 SIPコンテナ構成の概要

管理コンソールやWebLogic Scripting Tool (WLST)などのJMXユーティリティを使用するか、またはカスタムJMXアプリケーションをログラミングするかのいずれかによって、SIPコンテナ・プロパティを構成できます。2.2項「コンテナ・プロパティを構成するための管理コンソールの使用」では、管理コンソールのグラフィカル・ユーザー・インタフェースを使用してコンテナ・プロパティを構成する方法を説明しています。

2.3項「WLST (JMX)によるコンテナ・プロパティの構成」では、コンテナ構成を変更するためにJMX MBeansに直接アクセスする方法を説明しています。すべての例では、構成MBeansへのJMXアクセスを示すためにWLSTを使用します。

2.2 コンテナ・プロパティを構成するための管理コンソールの使用

Oracle WebLogic SIP Containerに含まれる管理コンソールを使用すると、Oracle WebLogic SIP Containerで提供されているコアWebLogic Serverの機能およびSIPサーブレット・コンテナ機能を構成および監視できます。管理コンソールを使用してSIPサーブレット機能の構成または監視を行うには、『Oracle Fusion Middleware管理者ガイド』のOracle WebLogic Server管理コンソール・スタート・ガイドの項を参照してください。

表2-1 Oracle WebLogic Server SIP Container構成および監視に使用する各種ページ

ページ

サブページ

関数

「構成」

「全般」

「SIPタイマー値」、「セッション・タイムアウト期間」、「デフォルトのOracle WebLogic Server SIP Containerの動作(プロキシまたはユーザー・エージェント)」、「サーバー・ヘッダー形式」、「呼出し状態のキャッシュ処理」、「DNS名の解決」、「タイマー・アフィニティ」、「ドメイン別名」、「レポート・サポート」、および「診断イメージ形式」などを構成します。

「構成」

「アプリケーション・ルーター」

カスタム・アプリケーション・ルーター(AR)のクラス名、構成、またはデフォルト・アプリケーションを構成します。

「構成」

「プロキシ」

プロキシ・ルーティングURIおよびプロキシ・ポリシーを構成します。

「構成」

「過負荷保護」

自動オーバーロード制御の有効化と無効化の条件を構成します。

「構成」

「メッセージのデバッグ」

開発システムでのSIP「メッセージ・ロギング」の有効化または無効化。

「構成」

「SIPセキュリティ」

認証の実行対象としない「信頼性のあるホスト」の指定。

「構成」

「永続性」

「存続期間が長いデータのRDBMSへの格納」、または「地理的に冗長なリモート・サイトに存続期間が長いセッション・データのレプリケート」の永続性オプションを構成します。

「構成」

「データ層」

SIPデータ層サーバーの現在の構成を表示します。ここには、パーティションを追加、削除および構成することもできます。

「構成」

「ロードバランサ・マップ」

ソフトウェアのアップグレード中に、複数のクラスタの内部仮想IPアドレスへのマッピングを構成します。

「構成」

「ターゲット」

エンジン層の構成を受けるサーバーとクラスタのリストを構成します。ターゲット・サーバーのリストは、どのサーバーまたはクラスタがSIPサーブレット・コンテナの機能を提供するかを決定します。

「構成」

「接続プール」

「接続再利用プール」を、SBC (Session Border Control)機能またはS-CSCF (Serving Call Session Control Function)との通信オーバーヘッドを最小限に抑えるために構成します。

「監視」

「全般」

エンジン層サーバーで処理されたメッセージおよびセッションに関する実行時情報の表示。

「監視」

「SIPアプリケーション」

デプロイ済SIPアプリケーションの実行時セッション情報の表示。

「監視」

「データ層の情報」

現在のステータスおよびSIPデータ層のサーバーによって実行される機能に関するランタイム情報を表示します。

2.2.1 構成のロックおよび永続性

Oracle WebLogic Server SIP Containerの構成ページのいずれかに関する情報を変更するためには、構成がロックされる必要があります。構成をロックすると、他の管理者が同時にその構成を変更できなくなります。ロックは本番ドメインで自動的に有効化され、開発ドメインで有効化または無効化できます。

変更するには、次の手順を実行します。

1. 管理コンソールの左上にある「チェンジ・センター」を検出します。

2. 「ロックして編集」をクリックして、ドメインの編集可能な構成階層をロックします。これにより、管理コンソールを使用して変更できるようになります。

3. コンソールの関連ページ上で変更する項目を変更し、変更した各ページ上で「保存」をクリックします。

4. 変更する項目の変更を完了したら、「チェンジ・センター」で「変更のアクティブ化」をクリックします。

注意:
管理コンソールで行った変更の一部は、アクティブ化するとすぐに反映されます。それ以外の変更では、変更によって影響を受けるサーバーまたはモジュールを再起動する必要があります。後者の変更は、動的でない変更と呼ばれます。動的でない変更は、管理コンソールでは「警告」アイコンで示されます。
動的でない構成設定を編集した場合、編集した内容は、サーバーを再起動するまで反映されません。

Oracle WebLogic Server管理コンソールの使用方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

2.3 WLST (JMX)のによるコンテナ・プロパティの構成

WebLogic Scripting Tool (WLST)は、WebLogic ServerまたはOracle WebLogic Server SIP Containerインスタンス上で使用可能なJMX MBeanを監視または変更するために使用できるユーティリティです。WLSTの完全なドキュメントは、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』で参照できます。

Oracle WebLogic Server SIP Containerドメインを構成するためにWLSTを使用する前に、環境を設定して必要なOracle WebLogic Server SIP Containerクラスをクラスパスに追加します。MIDDLEWARE_HOME/server/binにあるsetWLSEnv.shスクリプトまたはドメイン環境スクリプトのいずれかを使用してください。ここで、MIDDLEWARE_HOMEは、Oracle WebLogic Server SIP Containerインストールのルートです。

2.3.1 構成ロックの管理

表2-1では、構成のロックおよび変更の適用に使用するWLSTメソッドを示します。

表2-2 MBeanメソッドのサマリー

メソッド

説明

activate

現在の構成のMBean属性(現在のSIPサーブレット・コンテナ構成)をsipserver.xml構成ファイルに書込み、変更を実行中のサーバーに適用します。

cancelEdit

編集ロックをリリースして編集セッションを削除し、保存していない変更をすべて破棄します。管理者権限を持つユーザーであれば、ユーザーが編集セッションを起動していなくてもこの操作を呼び出すことができます。

cd

構成Beanまたは実行時Beanの階層を移動します。

connect

WLSTをWebLogic Serverインスタンスに接続します。

edit

編集セッションを開始します。

save

現在の構成MBeanの属性(現在のSIPサーブレット・コンテナの構成)を一時構成ファイルに書き込みます。

set

現在の構成Beanの指定された属性値を設定します。

stopEdit

SIPコンテナのプロパティを変更するために取得したロックを解放し、一時ファイルをすべて破棄し、MBeanに対する未保存の変更をすべてロールバックします。

次は、T1タイマー間隔を変更するためのコマンドの使用例です。

例2-1 T1タイマー間隔の変更

connect()
edit()
cd('CustomResources/sipserver/Resource/sipserver')
set('T1TimeoutInterval',505)
activate()

2.3.2 Oracle WebLogic Server SIP ContainerのMBeanの検出

すべてのSIPサーブレット・コンテナ構成のMBeanは、WLSTでserverConfig()コマンドを使用してアクセスできる、「serverConfig」MBeanツリーにあります。このBeanツリー内では、各構成MBeanは次のパスを使用してアクセスできます。

CustomResources/sipserver/Resource/sipserver

たとえば、Oracle WebLogic Server SIP ContainerドメインのデフォルトのプロキシMBeanを参照するには、次のWLSTコマンドを入力します。

serverConfig()
cd('CustomResources/sipserver/Resource/sipserver/Proxy')
ls()

ランタイムMBeanは、WLSTのcustom()コマンドを実行してアクセスするカスタムMBeanツリーでアクセスします。ランタイムMBeanは次のパスを使用します。

mydomain:Location=myserver,Name=myserver,Type=mbeantype

プロキシおよび過負荷保護設定などの特定の構成設定は、sipserver.xmlにはデフォルトで定義されます。構成MBeanは、関連サーバーを起動時にこれらの設定用に生成されるため、プロキシおよびOverloadProtection MBeanをすぐに参照できます。その他の構成設定はデフォルトでは構成されないため、関連MBeanにアクセスする前にそれを作成する必要があります。詳細は、2.4.2項「MBeanの作成および削除」を参照してください。

2.4 WLSTの構成

次の項では、SIPサーブレット・コンテナ・プロパティを構成するためのWLSTスクリプトおよびコマンドを説明しています。

2.4.1 WLSTの起動

Oracle WebLogic Server SIP ContainerでWLSTを使用するためには、クラスパスにすべてのOracle WebLogic Server SIP ContainerのJARファイルを含める必要があります。次の手順を実行します。

1. Oracle WebLogic Server SIP Container環境を設定します。

cd MIDDLEWARE_HOME/user_projects/domains/mydomain/bin
./setDomainEnv.sh

2. WLSTを起動します。

java weblogic.WLST

3. Oracle WebLogic Server SIP Containerドメインの管理サーバーに接続します。

connect('system','weblogic','t3://myadminserver:<portnumber>')

2.4.2 MBeanの作成および削除

SipServer MBeanは、sipserver.xml構成ファイルのコンテンツ全体を示します。SIPタイマーおよびSIPアプリケーション・セッション・タイムアウトを構成するためのいくつかの属性の他に、SipServerは、プロキシ設定および過負荷保護制御を表すMBeanの作成または削除に役立つヘルパー・メソッドを提供します。SipServerにおける他のヘルパー・メソッドのリストは、表2-1「Oracle WebLogic Server SIP Container構成および監視に使用する各種ページ」を参照してください。Oracle Fusion Middleware Communication Services Java APIリファレンスも参照してください。

2.5 タイマー処理の構成

エンジン層サーバーが新しい呼出し状態データをSIPデータ層に追加すると、SIPデータ層はキューのインスタンスを作成し、各呼出しに関連したSIPプロトコル・タイマーおよびアプリケーション・タイマーの完全なリストを管理します。エンジン層サーバーは、現在の時間に従ってどのタイマーが期限切れになるかを決定するために、SIPデータ層で定期的にパーティションのポーリングを実行します。デフォルトでは、複数のエンジン層からSIPデータ層へのポーリングは、タイマー表上の競合を避けるために時間差を置いて行われます。次に、エンジン層サーバーは、sip.timer.Default実行キューで割り当てられたスレッドを使用して、すべての期限切れのタイマーを処理します。

2.5.1 タイマー・アフィニティの構成(オプション)

デフォルトのタイマー処理メカニズムを使用すると、指定されたエンジン層サーバーが、現在起動時間に達したすべてのタイマーを処理します。この処理は、エンジンがそのようなタイマーに関連した呼出しを処理するかどうかに関係なく行われます。ただし、一部のデプロイメント・シナリオでは、そのタイマーに関連する呼出しを最後に変更したサーバーと同一のエンジン・サーバー上でタイマーが処理される必要があります。このシナリオの一例として、別のエンジンが処理に失敗するまで呼出しデータを処理しないセカンダリ・エンジンを保持するホット・スタンドバイ・システムがあります。Oracle WebLogic Server SIP Containerを使用すると、このようなシナリオでタイマー・アフィニティを構成することができます。

タイマー・アフィニティを有効化すると、レプリカは、各エンジン層サーバーが定期的に処理されたタイマーのSIPデータ層にポーリングを実行するようにリクエストします。SIPデータ層をポーリングするとき、エンジンは、最後にそのエンジンによって変更された呼出しに関連したタイマーか、または所有者がいない呼出しのタイマーのみを処理します。

注意:
エンジン層サーバーが失敗する場合、最後にそのエンジンによって変更されたどんな呼出し状態にも、所有者は存在しません。所有者がいない期限切れのタイマーがSIPデータ層にポーリングを実行する次のエンジン・サーバーによって処理されます。

タイマー・アフィニティを有効化するには:

1. ドメインの管理コンソールにアクセスします。

2. (開発環境で有効化されている場合に)「ロックして編集」をクリックして、構成ロックを取得します。

3. 左ペインで「SipServer」ノードを選択します。コンソールの右ペインには、Oracle WebLogic Server SIP Containerの構成および監視に使用される2つのレベルのタブ・ページがあります。

4. 右ペインで「構成」>「全般」タブを選択します。

5. 「タイマー・アフィニティの有効化」を選択します。

6. 「保存」をクリックし、構成の変更を保存します。

なお、「タイマー・アフィニティの有効化」設定は、sipserver.xmlのenable-timer-affinity要素で保持されます。

2.5.2 正確なSIPタイマーのNTPの構成

SIPプロトコル・スタックを正常に機能させるには、エンジン層とSIPデータ層のすべてのサーバーのシステム時計を、共通の時間ソースに1または2ミリ秒以下の精度で正確に同期させる必要があります。システム時計の時刻に大きな差があると、次のような重大な問題が発生する原因となります。

- 時計の設定が進められたサーバー上で早期に起動するSIPタイマー。

- エンジン層におけるタイマー処理の不適切な分散。たとえば、1つのエンジン層サーバーがすべての期限切れタイマーを処理しますが、一方で他のエンジン層サーバーはタイマーを処理しません。

各Oracle WebLogic Server SIP Containerインスタンスでネットワーク・タイム・プロトコル(NTP)クライアントまたはデーモンを使用し、共通NTPサーバーに同期することをお薦めします。

注意:
SIPプロトコル・スタックを正常に機能させるには、サーバーのシステム時計を共通の時間ソースに正確に(1または2ミリ秒以下の精度で)同期させる必要があります。T1タイマーの初期値として設定される500ミリ秒の値は、INVITEリクエストおよびレスポンスの再送信間隔の制御や、その他のタイマーの初期値の設定に使用されるので、システム時計の設定に少しでもずれがあると、SIPプロトコルが適切に動作しなくなるおそれがあります。たとえば、エンジン層の1つのサーバーのシステム時計の時刻が他のサーバーの時計より250ミリ秒進んでいると、そのサーバーが処理する期限切れタイマーの割合が他のエンジン層サーバーに比べて高くなり、割り当てられている間隔の半分の時間が経過した時点で再送信が開始されるようになります。また、メッセージのタイムアウトが本来より早い時点で強制的に発生するおそれもあります。

3 ネットワーク・リソースの管理

次の項では、Oracle WebLogic Server SIP Containerとともに使用するためにネットワーク・リソースを構成する方法を説明します。

- 3.1項「ネットワーク構成の概要」

- 3.2項「ロード・バランサ・アドレスの構成」

- 3.3項「ドメイン名サービス(DNS)サポートの有効化」

- 3.4項「SIPまたはSIPSのネットワーク・チャネルの構成」

- 3.5項「DiameterサポートのTCPおよびTLSチャネルの構成」

- 3.6項「任意のIPインタフェース上でリスニングするエンジン・サーバーの構成」

- 3.7項「SIPデータ層レプリカの一意のリスニング・アドレス属性の構成」

3.1 ネットワーク構成の概要

それぞれのOracle WebLogic Server SIP ContainerインスタンスのデフォルトHTTPネットワーク構成は、各サーバーのリスニング・アドレスおよびリスニング・ポートの設定から決定されます。ただし、Oracle WebLogic Server SIP Containerは、HTTP経由でSIPプロトコルをサポートしていません。SIPプロトコルは、UDPおよびTCPトランスポート・プロトコル経由でサポートされます。また、SIPSは、TLSトランスポート・プロトコルを使用してサポートされます。

UDP、TCP、またはTLSトランスポートを有効化するには、Oracle WebLogic Server SIP Containerインスタンスの1つ以上のネットワーク・チャネルを構成します。ネットワーク・チャネルとは構成可能なWebLogic Serverリソースで、サーバー・インスタンスへの固有のネットワーク接続の属性を定義します。基本チャネル属性には次が含まれます。

- 接続でサポートされているプロトコル

- 接続のリスニング・アドレス(DNS名またはIPアドレス)

- 接続で使用されるポート番号

- 発信されるUDPパケットで使用されるポート番号(オプション)

- チャネルを発信接続に使用する場合にSIPヘッダーに埋め込まれるパブリック・リスニング・アドレス(ロード・バランサのアドレス)

複数のチャネルを単一のOracle WebLogic Server SIP Containerインスタンスに割り当てて、複数のプロトコルのサポートまたはDNSサーバー・ハードウェアで使用可能な複数のインタフェースを活用できます。同一のチャネルを複数のサーバー・インスタンスに割り当てできません。

SIPプロトコル用の新しいネットワーク・チャネルを構成すると、UDPおよびTCPトランスポート・プロトコルの両方が指定されたポートで有効です。UDPまたはTCPのどちらか一方のトランスポート・プロトコルのみを使用するSIPチャネルを作成することはできません。SIPSプロトコル用のネットワーク・チャネルを構成すると、そのチャネルの接続では、トランスポート・プロトコルとしてTLSが使用されます。

新しいSIP Serverドメインを構成する場合は、通常、システム内のエンジン層の各サーバーとの通信に使用する複数のSIPチャネルを作成する必要があります。エンジン層のサーバーは、レプリカ用に構成されたリスニング・アドレス属性を使用して、SIPデータ層のレプリカと通信できます。ただし、レプリカ間で相互に通信するには、レプリカで一意なリスニング・アドレスを使用する必要があります。

注意:
SIPデータ層クラスタで複数のレプリカを構成する場合、各サーバーの一意のリスニング・アドレス(一意のDNS名またはIPアドレス)を構成する必要があります。一意のリスニング・アドレスを指定しない場合、レプリカ・サービスはデフォルトのlocalhostアドレスにバインドし、複数のレプリカは相互に検索できません。

3.1.1 IPv4とIPv6

オペレーティング・システムおよびハードウェアがIPv6をサポートしている場合、ネットワーク通信にIPv6を使用するためにOracle WebLogic Server SIP Containerも構成できます。SIPトラフィックのIPv6は、IPv6アドレスを使用してネットワーク・チャネルを構成することによって有効化されます。IPv6トラフィックをサポートする各エンジン層サーバー上でIPv6 SIPチャネルを構成する必要があります。手順については、3.4.2項「新規SIPまたはSIPSチャネルの作成」を参照してください。

エンジン上で構成した各SIPネットワーク・チャネルは、IPv6またはIPv4トラフィックをサポートします。1つのチャネルでIPv4とIPv6トラフィックをいっしょに使用することはできません。1つのエンジンは、複数の個別のネットワークをサポートするために、IPv4とIPv6チャネルの両方で構成できます。

外部SIPトラフィックの他のプロトコル・バージョンをサポートする一方で、Oracle WebLogic Server SIP ContainerエンジンおよびSIPデータ層ノードがIPv4(またはIPv6)上で通信できます。IPv6ネットワークでエンジンおよびSIPデータ層ノードを構成するには、各サーバー・インスタンスに対してIPv6リスニング・アドレスを指定します。

IPv4とIPv6ネットワーク・チャネルの構成に関する詳細は、3.4.2項「新規SIPまたはSIPSチャネルの作成」を参照してください。

3.2 ロード・バランサ・アドレスの構成

システムが、エンジン層への接続を分散するために1つ以上のロード・バランサを使用する場合、外部リスニング・アドレスとしてロード・バランサ・アドレスを含めるようにSIPネットワーク・チャネルを構成する必要があります。SIPチャネルが、チャネルのプライマリ・リスニング・アドレスとは異なる外部リスニング・アドレスを持つとき、Oracle WebLogic Server SIP Containerは、ResponseなどのSIPヘッダーに外部アドレスのホストおよびポート番号を埋め込みます。このように、呼出しに対する後続の通信は、ローカル・エンジン層サーバー・アドレス(外部クライアントにアクセスできない)ではなく、パブリック・ロード・バランサ・アドレスに直接接続されます。

ネットワーク・チャネルにおいて外部リスニング・アドレスが構成されていない場合は、そのチャネルのプライマリ・リスニング・アドレスがSIPヘッダーに埋め込まれます。

3.2.1 複数のロード・バランサおよびDNSロード・バランサ

システムが2つのロード・バランサを使用する場合、各エンジン層サーバー(各ロード・バランサへの各ネットワーク接続)上で2つのチャネルを定義し、外部リスニング・アドレスを対応するロード・バランサに割り当てる必要があります。エンジン層サーバー上で特定のネットワーク・インタフェースがアウトバウンド・トラフィックに選択されるとき、そのネットワーク・インタフェース・カード(NIC)アドレスに関連するネットワーク・チャネルは、SIPヘッダーに埋め込むための外部リスニング・アドレスを決定するために確認されます。

2つのパブリック・アドレスを持つDNSロード・バランサを使用する場合、2つのチャネルを定義して、その両方のパブリック・アドレスを構成する必要もあります。エンジン層サーバーに搭載されているNICが1つのみのときは、2番目のパブリック・アドレス専用のチャネルを構成するために、そのNICの2番目のアドレスを論理アドレスとして定義します。さらに、IPルーティング・ポリシーを構成して、ロード・バランサのそれぞれのパブリック・アドレスにどの論理アドレスを関連付けるかを指定することも必要です。

3.3 ドメイン名サービス(DNS)サポートの有効化

Oracle WebLogic Server SIP Containerは、SIPメッセージを送信するために必要なプロキシのポート番号、トランスポートおよびIPアドレスを解決するDNSをサポートします。これは、RFC 3263(http://www.ietf.org/rfc/rfc3263.txt)で説明されている動作に一致します。また、DNSは、宛先のIPアドレスおよびポート番号を解決するために、レスポンスをルーティングするときに使用される場合もあります。

注意:
DNS解決はSIPメッセージ処理のコンテキスト内で実行されるため、どのようなDNSパフォーマンス問題でも待機時間増加の原因となります。潜在的なパフォーマンス問題を削減するために本番環境ではキャッシングDNSサーバーを使用することをお薦めします。

DNSサポートのコンフィグレーション手順

1. 構成対象のOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。

2. コンソールの左ペインで「SipServer」ノードを選択します。

3. 右ペインで「構成」>「全般」タブを選択します。

4. 「DNSサーバー・ルックアップの有効化」を選択してください。

5. 「保存」をクリックして変更を保存します。

DNSルック・アップを有効にすると、サーバーは以下の目的でDNSを使用できます。

- リクエストがSIP URIに送信されるとき、プロキシ・サーバーのトランスポート、IPアドレス、およびポート番号を検出します。

- Sent-byフィールドのコンテンツに応じて、レスポンスのルーティング中にIPアドレスまたはポート番号(あるいはその両方)を解決します。

プロキシの検出では、Oracle WebLogic Server SIP Containerは、トランスポート、IP、およびポート番号情報を判定するためにSIPトランザクションごとに1回のみDNS解決を使用します。すべての再送信、ACK、またはCANCELリクエストは、同一のトランスポートを使用して同一のアドレスおよびポートに送信されます。DNS解決発現の方法に関する詳細は、RFC 3263 (http://www.ietf.org/rfc/rfc3263.txt)を参照してください。

レスポンス・メッセージの送信にプロキシが必要なとき、Oracle WebLogic Server SIP Containerは、Sent-byフィールドおよびヘッダーによって提供される情報に応じて、宛先のIPアドレスまたはポート番号(あるいはその両方)を決定するためにDNS参照を使用します。

3.4 SIPまたはSIPSのネットワーク・チャネルの構成

構成ウィザードを使用して新しいドメインを作成するとき、Oracle WebLogic Server SIP Containerインスタンスは、UDPおよびTCP経由でSIPプロトコルをサポートするデフォルトのネットワーク・チャネルを使用して構成されます。このデフォルト・チャネルは、リスニング・ポート5060番を使用するように構成されますが、リスニング・アドレスは指定しません。デフォルト・チャネルのリスニング・アドレスおよびリスニング・ポートの設定を変更するためには、3.4.1項「既存チャネルの再構成」の手順に従ってください。追加プロトコルまたは追加ネットワーク・インタフェースをサポートするための新しいチャネル・リソースを作成するためには、3.4.2項「新規SIPまたはSIPSチャネルの作成」を参照してください。

3.4.1 既存チャネルの再構成

既存チャネルにサポートされているプロトコルは変更できません。異なるネットワーク・プロトコルを使用するための既存リスニング・アドレス/ポートの組合せを再構成するには、既存チャネルを削除し、3.4.2項「新規SIPまたはSIPSチャネルの作成」の手順を使用して新しいチャネルを作成します。

チャネルを構成するには、次の手順を実行します。

1. 構成対象のOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。

2. 左ペインで、「環境」>「サーバー」タブを選択します。

3. 右ペインで、構成するサーバーの名前を選択します。

4. 「プロトコル」>「チャネル」タブを選択し、構成済チャネルを表示します。

5. 既存チャネルを削除するには、表で選択して「削除」をクリックします。

6. 既存チャネルを再構成するには、次の手順を実行します。

1. チャネル・リストからチャネルの名前を選択します(デフォルトの「SIP」チャネルなど)。

2. 関連するエンジン層マシン上でNICのアドレスまたは論理アドレスに対応するように、「リスニング・アドレス」または「リスニング・ポート」フィールドを編集します。

注意:
リスニング・アドレスとリスニング・ポートを変更する前に、チャネルを無効にする必要があります。

3. 「外部リスニング・アドレス」フィールドまたは「外部リスニング・ポート」フィールドを編集して、システムのロード・バランサのパブリック・アドレスに一致するように変更します。

4. 必要に応じて上級チャネル属性を編集します(詳細は、3.4.2項「新規SIPまたはSIPSチャネルの作成」を参照)。

7. 「保存」をクリックします。

3.4.2 新規SIPまたはSIPSチャネルの作成

Oracle WebLogic Server SIP Containerインスタンスの構成への新規SIPまたはSIPSチャネルを作成するには、次の手順を実行します。

1. 構成対象のOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。

2. 左ペインで、「環境」>「サーバー」タブを選択します。

3. 右ペインで、構成するサーバーの名前を選択します。

4. 「プロトコル」>「チャネル」タブを選択し、構成済チャネルを表示します。

5. 「新規」をクリックし、新規チャネルを構成します。

6. 新規チャネルの各フィールドの値を以下のように指定します。

- 名前: SIPS-Channel-eth0などの、このチャネルの管理名を入力します。

- プロトコル: UDPおよびTCPトランスポートをサポートするために「SIP」を選択するか、またはTLSトランスポートをサポートするためにSIPSを選択します。SIPチャネルは、構成済ポート上でUDPトランスポートのみまたはTCPトランスポートのみはサポートできないので注意してください。

7. 「次へ」をクリックします。

8. 次のように、新規チャネルのアドレス・フィールドを記入します。

- 「リスニング・アドレス」: このチャネルのIPアドレスまたはDNS名を入力します。DNSマシンの場合は、構成対象のインタフェースの正確なIPアドレス、または正確なIPアドレスにマッピングされるDNS名を入力します。

- 「リスニング・ポート」: このチャネルを通して通信に使用されるポート番号を入力します。リスニング・アドレスおよびリスニング・ポートの組合せは、サーバーに構成されたすべてのチャネル全体に渡って一意である必要があります。SIPチャネルは、構成済ポート上でUDPおよびTCPトランスポートの両方をサポートしています。

- 「外部リスニング・アドレス」および「外部リスニング・ポート」:これらのフィールドを編集し、このチャネルに関連するロード・バランサのパブリック・アドレスと照合します。サーバーが、アウトバウンド・ネットワーク・トラフィックに使用するためにインタフェースまたは論理アドレスを選択するとき、Oracle WebLogic Server SIP Containerは、同一のプライマリ・リスニング・アドレスを使用して構成されたチャネルを確認します。このチャネルの「外部リスニング・アドレス」が異なる場合、外部アドレスは以降のコール・トラフィック用にSIPメッセージ・ヘッダーに埋め込まれます。詳細は、3.2項「ロード・バランサ・アドレスの構成」を参照してください。

9. 「次へ」をクリックします。

10. オプションで、「表示」をクリックし、「接続タイムアウト」値などの上級チャネル・プロパティを表示して編集します。上級チャネル・プロパティの次の制約および提案があることに注意してください。

- 「アウトバウンドの有効化」: この属性は、すべてのSIPおよびSIPSチャネルがネットワーク接続の起点となるため、チェックされません。

- 「このプロトコルでHTTPを有効化」: この属性は、Oracle WebLogic Server SIP ContainerがHTTPトランスポートSIPプロトコルをサポートしないため、SIPおよびSIPSチャネルに選択できません。

- 「最大メッセージ・サイズ」: この属性は、サーバーがこのチャネルからの接続で許可する最大TCPメッセージ・サイズを指定します。Oracle WebLogic Server SIP Containerは、メッセージ・サイズが構成済の値を超過する接続を切断します。デフォルト・サイズの10,000,000バイトは大容量です。サーバーに対するサービス拒否(DOS)攻撃を防ぐことを懸念するなら、デプロイされたサービスに体操する値までこの属性を削減します。

11. 「終了」をクリックします。

3.4.3 カスタム・タイムアウト、MTU、および他のプロパティの構成

SIPチャネルは、1つ以上のカスタム・チャネル・プロパティを使用して構成できます。カスタム・プロパティは、管理コンソールを使用して設定できません。そのかわり、テキスト・エディタを使用して、ドメインのconfig.xmlファイルのチャネル構成部分で単一のcustom-propertyスタンザにプロパティを追加する必要があります。

Oracle WebLogic Server SIP Containerによって、SIPチャネルのトランスポート・プロトコルに影響を与える次のカスタム・プロパティが提供されます。

- TcpConnectTimeoutMillis: Oracle WebLogic Server SIP Containerが、(アウトバウンドTCP接続の)宛先アドレスを受信不能と宣言するまでの待機時間を指定します。このプロパティはSIPチャネルにのみ適用できます。Oracle WebLogic Server SIP ContainerはSIPSチャネルのこの属性値を無視します。値を0に指定すると、タイムアウトを完全に無効化できます。デフォルト値の3000ミリ秒は、カスタム・プロパティを指定しない場合に使用されます。

- SctpConnectTimeoutMillis: Oracle WebLogic Server SIP Containerが、(アウトバウンドSCTP接続の)宛先アドレスを受信不能と宣言するまでの待機時間を指定します。このプロパティは、(Diameterトラフィックの)SCTPチャネルにのみ適用できます。値を0に指定すると、タイムアウトを完全に無効化できます。デフォルト値の3000ミリ秒は、カスタム・プロパティを指定しない場合に使用されます。DiameterのSCTPチャネルの作成に関する詳細は、3.8.1.1項「アウトバウンドUDPパケットの静的なポート構成」を参照してください。

- SourcePorts: UDPパケットの発信にサーバーが使用する1つ以上の静的なポート番号を構成します。

注意:
大半の構成において、SourcePortsカスタム・プロパティの使用は、パフォーマンスを低下させるためお薦めしません。このプロパティは、Oracle WebLogic Server SIP ContainerがUDPパケットの発信に使用する正確なポートを指定する必要がある場合にのみ構成します。

- Mtu: このチャネルの最大送信単位(MTU)を指定します。値を-1に指定すると、トランスポートのデフォルトのMTUを使用します。

- EnabledProtocolVersions: Oracle WebLogic Server SIP ContainerがSSLクライアントとして機能するときに、このチャネルで使用するSSLプロトコルのバージョンを指定します。SSLクライアントとして機能するとき、デフォルトでチャネルにはサポートされるプロトコルとしてTLS V1.0が必要です。サーバーは、SSL V3.0がSSLピア・サーバーによってサポートされる最上位バージョンである場合、SSL V3.0も使用するように構成できます。このプロパティの次の値のいずれかを設定できます:

- TLS1はデフォルトで、チャネルを構成してTLS V1.0メッセージのみ送信/受信するようにします。ピアはTLS V1.0メッセージで応答する必要があり、それ以外ではSSL接続が切断されます。

- SSL3はチャネルを構成してSSL V3.0メッセージのみ送信/受信するようにします。ピアはSSL V3.0メッセージで応答する必要があり、それ以外ではSSL接続が切断されます。

- ALLは、TLS V1.0またはSSL V3.0メッセージのいずれかをサポートします。ピアはTLS V1.0またはSSL V3.0メッセージで応答する必要があり、それ以外ではSSL接続が切断されます。

カスタム・プロパティを構成するには、テキスト・エディタを使用してconfig.xmlファイルを直接変更するか、またはWLSTなどのJMXクライアントを使用してカスタム・プロパティを追加します。config.xmlを直接編集するとき、custom-properties要素を1つのみチャネルの構成スタンザの最後に追加するようにしてください。例3-1に示されるように、セミコロン(;)を使用して同一要素内の複数のカスタム・プロパティを区切ります。

例3-1 カスタム・プロパティの設定

<network-access-point>
<name>sip</name>
<protocol>sip</protocol>
<listen-port>5060</listen-port>
<public-port>5060</public-port>
<http-enabled-for-this-protocol>false</http-enabled-for-this-protocol>
<tunneling-enabled>false</tunneling-enabled>
<outbound-enabled>true</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
<custom-properties>EnabledProtocolVersions=ALL;Mtu=1000;SourcePorts=5060</custom-properties>
</network-access-point>

3.4.4 DNSマシンのSIPチャネルの構成

複数のネットワーク・インタフェースを持つサーバー(DNSサーバー)を構成する場合、Oracle WebLogic Server SIP Containerによって使用される各IPアドレスの個別のネットワーク・チャネルを構成する必要があります。Oracle WebLogic Server SIP Containerは、ルーティング情報をSIPメッセージ・システム・ヘッダーに埋め込むときに、各チャネルのリスニング・アドレスおよびリスニング・ポートの値を使用します。

注意:
DNSマシン上で特定のIPアドレスのチャネルを構成しない場合、そのIPアドレスはVia、Contact、およびRecord-Routeヘッダーを移入するときに使用できません。

3.5 DiameterサポートのTCPおよびTLSチャネルの構成

Oracle WebLogic Server SIP Container Diameter実装は、TCPまたはTLSトランスポート・プロトコル経由でDiameterプロトコルをサポートします。サーバー上で受信Diameter接続を有効化するには、TCPトランスポートのプロトコル・タイプdiameterまたはTCPおよびTLSトランスポート両方のdiametersを使用して専用ネットワーク・チャネルを構成します。Diameter実装アプリケーションは、Diameter 仕様書(RFC 3558)に記載されているように、自動的にDiameter接続をアップグレードしてTLSを使用する場合があります。

Diameterプロトコル・サポートのネットワーク・チャネルの構成に関する詳細は、第6章「Diameterクライアント・ノードおよびリレー・エージェントの構成」を参照してください。

3.6 任意のIPインタフェース上でリスニングするエンジン・サーバーの構成

任意の使用可能なIPインタフェース上でUDPトラフィックをリスニングするようにOracle WebLogic Server SIP Containerを構成するには、新規SIPチャネルを作成し、リスニング・アドレスとして0.0.0.0(または、IPv6ネットワークの場合は::)を指定します。SIPメッセージの送信に使用する明示的なIPアドレスを使用して少なくとも1つの追加チャネルは構成する必要があります。(DNSマシンでは、メッセージ送信用の各インタフェースは必ず構成済チャネルを持つ必要があります。)

注意:
チャネル・リスニング・アドレスを指定せずにSIPチャネルを構成しても、サーバー自体にはリスニング・アドレスを構成する場合、SIPチャネルはサーバーのリスニング・アドレスを継承します。この場合、SIPチャネルはIP_ANY上でリスニングしません。

注意:
0.0.0.0構成を使用すると、Linuxプラットホーム上のUDPトラフィックにのみ影響があります。Oracle WebLogic Server SIP Containerは、サーバーの構成済ホスト名およびlocalhostに対応するTCP/HTTPリスニング・スレッドのみ作成します。複数のアドレスがホスト名にマップされている場合、Oracle WebLogic Server SIP Containerは起動時に警告メッセージを表示します。この問題を避け、すべてのアドレス上でリスニングするには、::アドレスを指定します。このアドレスは、HTTP/TCPトラフィックのIPv6およびIPv4の両方に使用可能なすべてのアドレスも含みます。

3.7 SIPデータ層レプリカの一意のリスニング・アドレス属性の構成

SIPデータ層のレプリカがピアとして相互に通信できるようにするには、一意なリスニング・アドレス属性(一意なDNS名またはIPアドレス)を各レプリカにバインドする必要があります。各レプリカに一意なリスン・アドレスを割り当てるには、次の手順を実行します。

1. Oracle WebLogic Server SIP Containerドメインの管理コンソールにアクセスします。

2. 左ペインから「環境」>「サーバー」を選択します。

3. 右ペインで、構成するサーバーの名前を選択します。

4. 「構成」>「全般」タブを選択します。

5. 「リスニング・アドレス」フィールドで一意のDNS名またはIPアドレスを入力します。

6. 「保存」をクリックします。

3.8 本番ネットワーク・アーキテクチャおよび構成

Oracle WebLogic Server SIP Containerの本番インストールの大半(エンタープライズ・デプロイメント)には、1つ以上の次の特性が含まれます。

- 複数のエンジン層サーバーによってクラスタが構成されています。

- エンジン層の各サーバー・インスタンスが複数のネットワーク・チャネルを持ち、複数のSIPトランスポート・プロトコル、またはDNSハードウェア上の複数のネットワーク・インタフェース・カード(NIC)がサポートされています。

- 1つ以上のロード・バランサ、またはDNSロード・バランサがあり、サーバーのフェイルオーバーや、必要に応じて、ソースまたはネットワーク・パケットのネットワーク・アドレス変換(NAT)を実行できます。

このような各種のネットワーク要素が組み合わされて使用されていると、各要素が互いにどのように作用し合い、ネットワーク要素や構成オプションの特定の組合わせがSIPメッセージまたはトランスポート・プロトコル・データ・グラムの内容にどのような影響を与えるのかが理解しにくくなる場合があります。

次の項では、共通Oracle WebLogic Server SIP Containerネットワーク・アーキテクチャを解説し、各アーキテクチャでサーバーが構成される仕組みを説明しています。また、SIPメッセージおよびトランスポート・データグラム内の情報が、各構成によってどのように影響を受けるかについても説明しています。図3-1は、異なるネットワーク構成によって影響を受ける可能性がある通常のOpen Systems Interconnect (OSI)モデル・レイヤーを示しています。

図3-1 Oracle WebLogic Server SIP Containerのネットワーク構成によって影響を受けるOSIレイヤー

「図3-1 Oracle WebLogic Server SIP Containerのネットワーク構成によって影響を受けるOSIレイヤー」の説明

レイヤー3 (ネットワーク層)およびレイヤー4 (トランスポート層)には、発信および受信されるトランスポート・データ・グラムの送信元または送信先IPアドレスとポート番号が格納されています。SIPプロトコルでは、SIPメッセージの送信元にアクセスするためのアドレス情報を特定のSIPヘッダー内に記述するように規定されているので、レイヤー7 (アプリケーション層)も影響を受ける可能性があります。

3.8.1 TCPおよびUDPチャネルを使用した単一のNIC構成

NICが1枚搭載されたサーバーを使用する単純なネットワーク構成では、1つ以上のネットワーク・チャネルを作成して、UDPおよびTCP経由のSIPメッセージ、またはTLS経由のSIPSメッセージをサポートできます。この単純な構成がOSIモデルの情報にどのように影響するかを把握しておくと、DNSハードウェアおよびロード・バランサを使用したさらに複雑な構成が、同じ情報にどのような影響を与えるかが理解できます。

図3-2 単一のNICネットワーク・チャネル構成

「図3-2 単一のNICネットワーク・チャネル構成」の説明

図3-2は、単一のNICを持つ単一のエンジン層サーバー・インスタンスを示します。このサーバーは、UDPおよびTCP経由でSIPをサポートする1つのネットワーク・チャネルを使用して構成されます。(SIPチャネルは、常にUDPおよびTCPトランスポートをサポートしますが、2つの内1つしかサポートできません)図3-2は、1つはUDP経由、もう1つはTCP経由でサーバーと通信する2つのクライアントも示しています。

TCPトランスポートでは、送信データグラム(Oracle WebLogic Server SIP ContainerからUAへ送信)に次の情報が含まれます。

- レイヤー3には、そのネットワーク・チャネルで指定されている送信元IPアドレス(上記例では10.1.1.10)が含まれています。

- レイヤー4には、基盤のオペレーティング・システムによって割り当てられた送信元ポート番号が含まれています。

受信TCPデータグラム(UAからOracle WebLogic Server SIP Containerへ送信)には、次の情報が含まれます。

- レイヤー3には、そのネットワーク・チャネルで指定されている送信先IPアドレス(10.1.1.10)が含まれています。

- レイヤー4には、そのネットワーク・チャネルで指定されている送信先ポート番号(5060)が含まれています。

送信UDPデータグラムでは、OSIレイヤー情報にTCPトランスポートと同一の情報が含まれます。受信UDPデータグラムでは、受信データグラム・レイヤー4情報の場合を除き、OSIレイヤー情報はTCPと同一になります。受信UDPデータグラムでは、レイヤー4には次のいずれかが含まれます。

- そのネットワーク・チャネルで指定されている送信先ポート番号(5060)

- 以前にOracle WebLogic Server SIP Containerによって割り当てられたエフェメラル・ポート番号。

デフォルトでは、Oracle WebLogic Server SIP Containerは、基礎となるオペレーティング・システムのエフェメラル・ポート番号の範囲からポートを送信UDPデータグラムに割り当てます。Oracle WebLogic Server SIP Containerによって、ネットワーク・チャネルに構成されたポート番号に加えて、外部接続が宛先ポート番号としてエフェメラル・ポイントを使用できるようになります。つまり、Oracle WebLogic Server SIP Containerは、サーバーが割り当てるすべてのエフェメラル・ポート上で自動的にリスニングします。オプションで、サーバー起動時に次のオプションを指定することによって、Oracle WebLogic Server SIP Containerによるエフェメラル・ポート番号の使用を無効化できます。

-Dwlss.udp.listen.on.ephemeral=false

サーバー・ログ・ファイルを確認することによって、Oracle WebLogic Server SIP Containerによる特定のエフェメラル・ポートの使用を決定できます。

<Nov 30, 2005 12:00:00 AM PDT> <Notice> <WebLogicServer> <BEA-000202> <Thread "SIP Message Processor (Transport UDP)" listening on port 35993.>

3.8.1.1 アウトバウンドUDPパケットの静的なポート構成

Oracle WebLogic Server SIP Containerネットワーク・チャネルによって、サーバーが発信UDPパケットに使用する1つ以上の静的なポートの構成に使用できるSourcePorts属性が提供されます。

注意:
大半の構成において、SourcePortsカスタム・プロパティの使用は、パフォーマンスを低下させるためお薦めしません。このプロパティは、Oracle WebLogic Server SIP ContainerがUDPパケットの発信に使用する正確なポートを指定する必要がある場合にのみ構成します。

SourcePortsプロパティを構成するには、WLSTなどのJMXクライアントを使用するか、またはカスタム・プロパティを含むようにconfig.xmlでネットワーク・チャネル構成を直接変更します。SourcePortsは、ポート番号の配列またはポート番号範囲を定義します。SourcePorts定義にスペースが含まれません。ポート番号のみを使用し、ポート範囲を指定するにはハイフン(-)、範囲または各ポートを区切るにはカンマ(,)を使用します。例として使用する構成については、例3-2を参照してください。

例3-2 送信UDPパケットの静的なポート構成

<network-access-point>
<name>sip</name>
<protocol>sip</protocol>
<listen-port>5060</listen-port>
<public-port>5060</public-port>
<http-enabled-for-this-protocol>false</http-enabled-for-this-protocol>
<tunneling-enabled>false</tunneling-enabled>
<outbound-enabled>true</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
<custom-properties>SourcePorts=5060</custom-properties>
</network-access-point>

3.8.2 DNSサーバー構成の概要

本番デプロイメントのエンジン層サーバーでは、多くの場合、複数のNICが搭載されDNSサーバー・ハードウェアが利用されます。DNSハードウェアは、一般に、次のいずれかの目的で使用されます。

- 同一のサブネット内での冗長なネットワーク接続の実現。複数のNICを使用すると、いずれか1つのNICに障害が発生した場合でも、それ以外の1つまたは複数のネットワーク接続を使用して、データ層サーバーまたは管理サーバーと通信することができます。

- 2つ以上の異なるサブネット全体でSIP通信のサポート。たとえば、Oracle WebLogic Server SIP Containerは、UAがサブネット全体に直接通信できないとき、1つのサブネット内のUAからセカンド・サブネット内のUAへのSIPリクエストを代理するように構成されることがあります。

構成要件およびOSIレイヤー情報は、システムにおけるDNSハードウェアの使用に応じて異なります。複数のNICがサブネット内の冗長接続を提供するために使用されるとき、サーバーは通常、3.8.3項「すべてのアドレス(IP_ANY)にリスニングするDNSサーバー」で説明されているように、すべての使用可能なアドレス(IP_ANY)にリスニングするように構成されます。

異なるサブネットをサポートするために複数のNICを使用するとき、3.8.4項「複数のサブネットにリスニングするDNSサーバー」で説明されているように、各NICのサーバー上で複数のネットワークを構成する必要があります。

3.8.3 すべてのアドレス(IP_ANY)にリスニングするDNSサーバー

最も単純なDNS構成によって、Oracle WebLogic Server SIP Containerインスタンスは、IP_ANYとして記載されることがある、すべての使用可能なNIC(物理NICおよび論理NIC)にリスニングできるようになります。これを達成するには、単一のネットワーク・チャネルを構成し、チャネル・リスニング・アドレスを0.0.0.0に指定します。

0.0.0.0アドレスは、サーバーのネットワーク・チャネル上で直接構成する必要があるので注意してください。チャネルにIPアドレスを指定しない場合、チャネルはサーバー・インスタンス自体に構成されたリスニング・アドレスを継承します。詳細は、3.6項「任意のIPインタフェース上でリスニングするエンジン・サーバーの構成」を参照してください。

3.8.4 複数のサブネットにリスニングするDNSサーバー

また、複数のNICは、複数のサブネット上でリスニングするようにエンジン層サーバーで使用できます。最も一般的な構成では、1つのサブネットからサブネット間の直接アクセスが許可されていない別のサブネットへのSIPトラフィックを代理するために、Oracle WebLogic Server SIP Containerを使用します。図3-3はこの構成を示しています。

図3-3 サブネット間のプロキシを実現させるDNS構成

「図3-3 サブネット間のプロキシを実現させるDNS構成」の説明

図3-3におけるOracle WebLogic Server SIP Containerインスタンスを構成するには、サーバー・マシン上で使用される各NICの個別のネットワーク・チャネルを定義する必要があります。例3-3では、サンプル構成のチャネルを定義するconfig.xmlエントリを示しています。

例3-3 複数のサブネット上のNICのサンプル・ネットワーク・チャネル構成

<NetworkAccessPoint ListenAddress="10.1.1.10" ListenPort="5060" Name="sipchannelA" Protocol="sip"/>
<NetworkAccessPoint ListenAddress="10.2.1.10" ListenPort="5060" Name="sipchannelB" Protocol="sip"/>

3.8.4.1 ルート・リゾルバの理解

Oracle WebLogic Server SIP Containerが複数のサブネット上でリスニングするように構成されているとき、ルート・リゾルバという機能が次のアクティビティを行います。

- OSIレイヤー7情報内に(Via、ContactなどのSIPシステム・ヘッダーに)、正しいアドレスが格納されます。

- OSIレイヤー3情報内に、正しい送信元IPアドレスが格納されます。

たとえば、図3-3で示される構成では、Oracle WebLogic Server SIP Containerは、各UAがSIPトランザクションの処理を続けるために、正しいサブネット・アドレスをSIPシステム・ヘッダーおよびトランスポート・データグラムに追加する必要があります。間違ったサブネットが使用される場合、どのUAも別のUAのサブネットに直接アクセスできないため、レプリカは送信されません。

ルート・リゾルバは、データグラムを所定の宛先に送信するためにどのNICをオペレーティング・システムが使用するかを決定してから、そのNICに関連するネットワーク・チャネルを確認することによって機能します。次に、選択されたネットワーク・チャネルで構成されたアドレスを使用し、SIPヘッダーおよびレイヤー3アドレス情報を移入します。

たとえば、図3-3で示される構成では、Oracle WebLogic Server SIP ContainerからUAC Bへ送信されるINVITEメッセージは、10.2.1.16という宛先アドレスを持ちます。オペレーティング・システムは、対応するサブネットに構成されるNIC Bを使用して、このメッセージを送信します。ルート・リゾルバは、NIC Bを構成されたsipchannelBに関連付け、チャネルのIPアドレス(10.2.1.10)をSIPメッセージのVIAヘッダーに埋め込みます。次に、正しいIPアドレスを使用して後続のメッセージをサーバーへ直接送信するために、UAC BはVIAヘッダーを使用します。メッセージが正しいサブネット上でのみ送信されるようにするため、同様のプロセスがUAC Aに使用されます。

3.8.4.2 DNSハードウェアに関するIPの別名

IPの別名は複数の論理IPを単一のNICに割り当て、基礎となるサーバーのオペレーティング・システムで構成されます。IP別名を構成し、すべての論理IPアドレスが同一のサブネット内にある場合、3.8.3項「すべてのアドレス(IP_ANY)にリスニングするDNSサーバー」で説明されているように、Oracle WebLogic Server SIP Containerがすべてのアドレスにリスニングするように構成できます。

異なるサブネット上で複数の論理IPアドレスを作成するためにIP別名を構成する場合、各論理IPアドレスに個別のネットワーク・チャネルを構成する必要があります。この構成では、Oracle WebLogic Server SIP Containerはすべての論理アドレスを個別の物理インタフェース(NIC)として処理し、ルート・リゾルバを使用して、構成済チャネルに基づいてOSIレイヤー4およびレイヤー7情報を移入します。

3.8.5 ロード・バランサの構成

フェイルオーバー機能の提供および複数のサーバーに渡るクライアント・ロードの分散に加え、ロード・バランサは、クライアントとサーバー間で送信されるネットワーク情報を構成するための重要なツールでもあります。次の項では、Oracle WebLogic Server SIP Containerで使用される共通ロード・バランサの構成を説明しています。

3.8.5.1 単一のロード・バランサの構成

最も一般的なロード・バランサの構成は、図3-4で示されるように、エンジン層サーバーのクラスタへのアクセスを開く単一のロード・バランサを活用します。

図3-4 単一のロード・バランサの構成

「図3-4 単一のロード・バランサの構成」の説明

図3-4で示されるように、単一のロード・バランサとともに使用するためにOracle WebLogic Server SIP Containerを構成するには、各サーバーに1つ以上のネットワーク・チャネルを構成し、ロード・バランサの仮想IPアドレスを使用して各チャネルのパブリック・アドレスを構成します。この構成では、クライアントが後続のレプリカのクラスタに到達できるようにするために、Oracle WebLogic Server SIP Containerはロード・バランサのIPアドレスをSIPメッセージ・ヘッダーに埋め込みます。第3章「ネットワーク・リソースの管理」では、ロード・バランサのアドレスを使用してネットワーク・チャネルを構成するための詳細な手順を提示しています。

注意:
ロード・バランス・スイッチの一部は、同一エンジン層サーバーへの所定の呼出しですべてのSIPメッセージを自動的に再ルーティングできますが、この機能はOracle WebLogic Server SIP Containerインストールには必要ありません。詳細は、7.7項「代替構成」を参照してください。

3.8.5.2 複数のロード・バランサおよびDNSロード・バランサ

複数のロード・バランサ(またはDNSロード・バランサ)は、単一のOracle WebLogic Server SIP Containerクラスタの仮想IPアドレスをいくつか提供するために構成できます。DNSロード・バランサとともに使用するためにOracle WebLogic Server SIP Containerを構成するには、各ロード・バランサまたはローカル・サーバーNICの専用ネットワーク・チャネルを作成し、チャネルのパブリック・アドレスを適切なロード・バランサの仮想IPアドレスに設定します。この構成では、ルート・リゾルバは構成済チャネルを発信SIPメッセージに使用されるNICに関連付けます。次に、選択したチャネルのパブリック・アドレスは、SIPシステム・メッセージの移入に使用されます。詳細は、3.8.4.1項「ルート・リゾルバの理解」を参照してください。

3.8.5.3 ネットワーク・アドレス変換オプション

最も一般的なケースでは、クライアントが1つ以上の内部(プライベート)Oracle WebLogic Server SIP Containerアドレスとの通信に使用するパブリックIPアドレスを提供するために、ロード・バランサは宛先NATを使用して構成されます。また、ロード・バランサは、ソースNATを使用して構成される場合もあります。このNATは、ロード・バランサ自体の仮想IPアドレスを照合するためにプライベート・アドレスから発信されるレイヤー3アドレス情報を変更します。

デフォルトのルート・リゾルバの動作を使用して、Oracle WebLogic Server SIP Containerエンジンは、ローカルNICのアドレス(プライベート・アドレス)に一致するソースIPアドレスを持つUDPパケットを発信します。これは、ローカル・サーバー・アドレスがパブリックではアクセスできないことがあるため、トランスポート・パケットに埋め込まれたレイヤー3アドレスに直接応答しようとするアプリケーションでは問題になる可能性があります。アプリケーションでこの問題が発生する場合、トランスポート・レイヤー3アドレスをパブリックでアクセス可能な仮想IPアドレスへ変更するためのソースNATを実行するようにロード・バランサを構成することをお薦めします。

3.8.5.3.1 ソースNATを代替するIPマスカレード

ロード・バランサ上でソースNATを有効化しないように選択する場合、Oracle WebLogic Server SIP Containerによって限定IPマスカレード機能が提供されます。この機能を使用するには、クラスタのロード・バランサのパブリックIPアドレスを使用して、各エンジン層サーバーで論理アドレスを構成します。(各エンジン層サーバー・マシン上で同一の論理IPを複製します)ローカル・サーバー・インタフェースが、構成されたロード・バランサ(ネットワーク・チャネルのパブリック・アドレスで定義される)のIPアドレスに一致するとき、Oracle WebLogic Server SIP Containerはこのインタフェースを使用してSIP UDPメッセージを発信し、レイヤー3アドレスにはパブリック・アドレスが含まれます。

注意:
Oracle WebLogic Server SIP ContainerのIPマスカレード機能を使用すると、複数のサーバー上で複製IPアドレスが必要になるので、ネットワークが不安定になる可能性があります。本番デプロイメントは、信頼性の高いネットワーク・インタフェースを保証するため、IPマスカレード機能ではなく、ソースNATに構成されたロード・バランサを使用する必要があります。

Oracle Communications Converged Application ServerのIPマスカレード機能を無効にするには、次の起動オプションを使用します。

-Dwlss.udp.lb.masquerade=false

3.9 例として使用するネットワーク構成

Oracle WebLogic Server SIP Containerは、SIPを認識できないロード・バランサに対応しているため、リクエストをサーバーにルーティングするとき、既存のSIPダイアログを考慮しません。このドキュメントによって、ロード・バランサおよびOracle WebLogic Server SIP Containerの構成とともに、各種構成におけるSIPとネットワーク・アドレス変換(NAT)との相互作用が実証されます。

次の項では、SIPを認識できないロード・バランサを使用するOracle WebLogic Server SIP Containerのサンプル・ネットワーク構成を説明します。

NATに関する実装依存問題の詳細は、IETFドキュメントのhttp://tools.ietf.org/wg/behave/draft-ietf-behave-nat-udp/にあるユニキャストUDPのNAT動作要件に関する項を参照してください。

3.9.1 例として使用するネットワーク・トポロジ

図3-5は、この項で説明されているサンプル・ネットワーク・トポロジを示します。Oracle WebLogic Server SIP Containerクラスタは、WLSS 1およびWLSS 2エンジンから成り、プライベートIPネットワーク10.1/16(内部16ビット・サブネット)上で構成されます。クラスタのパブリックIPアドレスは1.2.3.4で、ロード・バランサ上で構成される仮想IPアドレスです。

ユーザー・エージェントUAC Aは2.3.4.5のIPアドレスを持ち、Oracle WebLogic Server SIP Containerクラスタに構成された内部IPアドレスを参照しません。そのかわり、1.2.3.4へリクエストを送信し、そこからレスポンスを受信します。

次の項では、このサンプル・システムのOracle WebLogic Server SIP Containerクラスタおよびロード・バランサの構成を説明しています。

図3-5 例として使用するネットワーク・トポロジ

「図3-5 例として使用するネットワーク・トポロジ」の説明

3.9.2 Oracle WebLogic Server SIP Containerの構成

Oracle WebLogic Server SIP Containerクラスタ構成は、各エンジンのパブリック・アドレスを1.2.3.4、パブリック・ポートを5060番(3.2項「ロード・バランサ・アドレスの構成」を参照)に指定します。Oracle WebLogic Server SIP Containerの両エンジン上のデフォルト・ルートは、ロード・バランサの10.1/16ネットワーク・インタフェース(10.1.3.4)を指します。Oracle WebLogic Server SIP Container(WLSS 1およびWLSS 2サーバー)のルーティング表は、例3-4で示されます。

例3-4 Oracle WebLogic Server SIP Containerルーティング表

$ /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.0           *            255.255.0.0     U     0      0        0 eth0
default         10.1.3.4        0.0.0.0         UG    0      0

3.9.3 ロード・バランサの構成

ロード・バランサは、仮想IPアドレス「1.2.3.4」、アドレス「10.1.1.1」および「10.1.1.2」をそれぞれ持つ2つの実際のサーバーWLSS 1およびWLSS 2によって構成されます。また、ロード・バランサは、10.1/16ネットワーク上で構成された内部IPアドレス「10.1.3.4」を持ちます。UACアドレス「2.3.4.5」は、ロード・バランサ上の静的なルーティング構成によってロード・バランサから受信可能です。ロード・バランサのルーティング表は、例3-5で示されています。

例3-5 ロード・バランサのルーティング表

$ /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.0           *            255.255.0.0     U     0      0        0 eth1
1.2.0.0            *            255.255.0.0     U     0      0

SIPのユーザー・エージェントがリクエストまたはレスポンスを送信する際に使用すべき送信先IPアドレスとUDPポート番号はSIPプロトコル仕様(RFC 3261)で規定されているため、ロード・バランサのNAT構成はRFC 3261の要件に違反しない形で行う必要があります。そのような構成は、次の3とおりの設定方法で実現できます。

- 3.9.3.1項「NATベースの構成」

- 3.9.3.2項「maddrベースの構成」

- 3.9.3.3項「rportベースの構成」

以下の節で、それぞれのアプローチについて説明します。

3.9.3.1 NATベースの構成

ロード・バランサのデフォルトUDP NAT動作は、パブリック > プライベート・ネットワーク方向で宛先のIPアドレス変換を実行し、プライベート > パブリック・ネットワーク方向でソースIPアドレス変換を実行することです。つまり、ソース・アドレス変換なしのUAC > Oracle WebLogic Server SIP Container (2.3.4.5 > 1.2.3.4)方向の宛先アドレス変換、および宛先アドレス変換なしのOracle WebLogic Server SIP Container > UAC (10.1/16 > 2.3.4.5)方向のソース・アドレス変換を設定することになります。

図3-6は、SUBSCRIBE/200OKトランザクションのUDPパケット・フローを説明しています。

図3-6 SUBSCRIBEシーケンス

「図3-6 SUBSCRIBEシーケンス」の説明

UDPパケットのソース/宛先IPアドレスは青で示されるので注意してください。UAC > Oracle WebLogic Server SIP Container方向では、ロード・バランサは宛先IPアドレスを変換しますが、ソースIPアドレスは変換しません。Oracle WebLogic Server SIP Container > UAC方向では、ロード・バランサはソースIPアドレスを変換しますが、宛先IPアドレスは変換しません。

図3-6からのシーケンスの完全なメッセージ・トレース(IP/UDPヘッダーおよびSIPペイロードを含む)は、次の例3-6で示されます。

例3-6 完全なSUBSCRIBEメッセージ・トレース

No.     Time        Source                Destination           Protocol Info
1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
2 2.426250    2.3.4.5           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
3 3.430903    10.1.1.1               2.3.4.5           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 SUBSCRIBE
Call-ID: 1-25923@2.3.4.5

Oracle WebLogic Server SIP Containerが後でNOTIFYリクエストをUACへ送信する場合、図3-7で示されるシーケンスが発生します。

図3-7 NOTIFYシーケンス

「図3-7 NOTIFYシーケンス」の説明

前のシーケンスのように、IPアドレス変換はソースIPアドレスのOracle WebLogic Server SIP Container > UAC方向、および宛先IPアドレスのUAC > Oracle WebLogic Server SIP Container方向で起こります。

この設定は、セッション状態情報を保持したり、SIPを認識できるようになるためにロード・バランサを必要としないので注意してください。図3-7からの完全なメッセージ・トレースは、次の例3-7で示されます。

例3-7 完全なNOTIFYメッセージ・トレース

No.     Time        Source                Destination           Protocol Info
1 5.430952    10.1.1.1                2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
Message Header
To: sipp <sip:sipp@2.3.4.5>;tag=1
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 NOTIFY
Call-ID: 1-25923@2.3.4.5
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
2 6.430952    1.2.3.4          2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 1.2.3.4 (1.2.3.4), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 9999 (9999)
Session Initiation Protocol
Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
Message Header
To: sipp <sip:sipp@2.3.4.5>;tag=1
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 NOTIFY
Call-ID: 1-25923@2.3.4.5
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
3 7.431367    2.3.4.5           1.2.3.4          SIP      Status: 200 OK

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
To: sipp <sip:sipp@2.3.4.5>;tag=1;tag=1
Call-ID: 1-25923@2.3.4.5
CSeq: 1 NOTIFY
Contact: <sip:2.3.4.5:9999;transport=UDP>

注意:
NATがソース(SNAT)および宛先のIPアドレスの両方で実行される場合、ロード・バランサが通常はリクエストの応答として送信される固有の宛先ポート番号の値に依存するため、構成は機能しません。そのポート番号値はRFC 3261によって記述されており、ロード・バランサのNAT要件との競合を示すViaヘッダーに由来する必要があります。RFC 3261では、SIPリクエストへのレスポンスは、リクエストの送信に使用されるIPアドレスへ送信される必要があります(3.9.3.2項「maddrベースの構成」で示されるように、maddrがViaで提示されない場合)。その結果、次の図3-8の手順3では、Oracle WebLogic Server SIP Containerは200回のOKレスポンスをロード・バランサの内部IPアドレス(10.1.3.4)およびポート5060番に送信します。そのため、このレスポンスは削除されます。

図3-8 送信元NATと送信先NATを両方有効にした場合のシーケンス

「図3-8 ソース/宛先NAT」の説明

図3-8からの完全なメッセージ・トレースは、次の例3-8で示されます。

例3-8 完全なSUBSCRIBE失敗メッセージ・トレース

No.     Time        Source                Destination           Protocol Info
1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
3 3.430903    10.1.1.1               10.1.3.4           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 10.1.3.4 (10.1.3.4)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol

3.9.3.2 maddrベースの構成

Viaヘッダー内にmaddrパラメータの値が記述されている場合、レスポンスはリクエストの送信元のIPアドレスに対してではなく、maddrパラメータで指定されているIPアドレスに送信されます(このことはSNATが有効に設定されている場合でも同じです)。次の例では、UACからのリクエストのViaヘッダー内にmaddrパラメータが記述されていて、その値として2.3.4.5が設定されています。そのため、SIPサーバーからの応答は問題なくUACに着信します。

図3-9 maddrシーケンス

「図3-9 maddrシーケンス」の説明

図3-9からの完全なメッセージ・トレースは、次の例3-9で示されます。

例3-9 完全なmaddrメッセージ・トレース

No.     Time        Source                Destination           Protocol Info
1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;maddr=2.3.4.5;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;maddr=2.3.4.5;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
3 3.430903    10.1.1.1               2.3.4.5           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>

3.9.3.3 rportベースの構成

RFC 3581は、サーバーがViaではなくリクエストからレスポンスをUDPポート番号へ送信するようにクライアントがリクエストできるようにすることによって、SIPおよびNATの相互作用を向上します。SUBSCRIBEおよびNOTIFYの両方を正常に機能させるためには、UACとOracle WebLogic Server SIP Containerの両方がRFC 3581をサポートする必要があります。図3-10はSUBSCRIBEフローを示しています。

図3-10 rportを使用した場合のSUBSCRIBEシーケンス

「図3-10 rport SUBSCRIBEシーケンス」の説明

図3-10からの完全なメッセージ・トレースは、次の例3-10で示されます。

例3-10 rport SUBSCRIBEの完全なメッセージ・トレース

No.     Time        Source                Destination           Protocol Info
1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;rport;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;rport;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
3 3.430903    10.1.1.1               10.1.3.4           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 10.1.3.4 (10.1.3.4)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 2222 (2222)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 SUBSCRIBE
Call-ID: 1-25923@2.3.4.5

図3-11はNOTIFYフローを示しています。

ソース・アドレスNATが両方向(UAS > Oracle WebLogic Server SIP ContainerおよびOracle WebLogic Server SIP Container > UA)で有効化される一方で、ロード・バランサは、リクエストの送信に使用されるのと同一のポート番号におけるレスポンスの受信に依存することによって、手順3で正常に宛先アドレスを識別できるので、注意してください。つまり、ロード・バランサは状態を維持することを暗示しています。

図3-11 rportを使用した場合のNOTIFYシーケンス

「図3-11 rport NOTIFYシーケンス」の説明

図3-11からの完全なメッセージ・トレースは、次の例3-11で示されます。

例3-11 rport NOTIFYの完全なメッセージ・トレース

No.     Time        Source                Destination           Protocol Info
1 5.430952    10.1.1.1                2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
Message Header
To: sipp <sip:sipp@2.3.4.5>;tag=1
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 NOTIFY
Call-ID: 1-25923@2.3.4.5
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
2 6.430952    1.2.3.4          2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 1.2.3.4 (1.2.3.4), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 9999 (9999)
Session Initiation Protocol
Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
Message Header
To: sipp <sip:sipp@2.3.4.5>;tag=1
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 NOTIFY
Call-ID: 1-25923@2.3.4.5
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
3 7.431367    2.3.4.5           1.2.3.4          SIP      Status: 200 OK

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: (2222)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
To: sipp <sip:sipp@2.3.4.5>;tag=1;tag=1
Call-ID: 1-25923@2.3.4.5
CSeq: 1 NOTIFY
Contact: <sip:2.3.4.5:9999;transport=UDP

4 SIPデータ層パーティションおよびレプリカの構成

次の項では、デプロイメントのSIPデータ層クラスタを形成するOracle WebLogic Server SIP Containerインスタンスの構成方法を説明します。

- 4.1項「SIPデータ層構成の概要」

- 4.2項「SIPデータ層サーバーの構成および管理のベスト・プラクティス」

- 4.3項「SIPデータ層構成および構成ファイルの例」

- 4.4項「存続期間が長いコール状態データのRDBMSへの保存」

- 4.5項「地理的冗長性の概要」

- 4.6項「地理的に冗長なSIPデータ層の使用」

- 4.7項「SIPデータのエンジン層へのキャッシュ」

- 4.8項「SIPデータ層サーバーの監視およびトラブルシューティング」

4.1 SIPデータ層構成の概要

Oracle WebLogic Server SIP Container SIPデータ層は、同時SIP呼出しのアプリケーション呼出し状態を管理するサーバー・インスタンスのクラスタです。SIPデータ層は、サーバー・マシンに障害が発生した場合またはネットワーク接続が切断された場合、呼出し状態データが損失しないことを保証するために呼出し状態の単一のコピーまたは必要に応じて複数のコピーを管理できます。

SIPデータ層クラスタは、1つ以上のパーティションに配置されます。パーティションは、同時呼出し状態データの同一部分を管理する1つ以上のSIPデータ層サーバー・インスタンスから構成されます。単一サーバーのOracle WebLogic Server SIP Containerインストール、または2つのサーバー・インストール(1つはエンジン層、もう1つはSIPデータ層)では、すべての呼出し状態データは単一のパーティションに保持されます。複数のパーティションは、同時呼出し状態のサイズが単一のサーバー・インスタンスで管理可能な最大サイズを超えたときに必要です。1つ以上のパーティションが使用されるとき、同時呼出し状態はパーティション間で分割され、各パーティションは個別のデータ部分を管理します。たとえば、2つのパーティションを持つSIPデータ層では、1つのパーティションは同時呼出しの半分(A-Mの呼出しなど)の呼出し状態を管理し、2つ目のパーティションは残りの呼出し(N-Z)を管理します。

多くの場合、個々のサーバーで処理できる呼出し状態の最大サイズは、Java仮想マシンの制限に対応し、サーバー1つ当たり約1.6GBです。

呼出し状態データのコピーを管理するために同一のパーティション内にサーバーを追加できます。複数のサーバーが同一のパーティションのメンバーであるとき、各サーバーは、呼出し状態のレプリカと呼ばれる、呼出しデータの同一部分のコピーを管理します。パーティション内のサーバーで障害が発生した場合、またはネットワーク障害によって接続できない場合、パーティション内の別のレプリカが呼出し状態データをエンジン層に送信します。マシンやネットワークの障害から保護するために、本番インストールでは、各パーティションにおいて2つのサーバーを構成することをお薦めします。パーティションは、冗長性を強化させるために最大で3つのレプリカを持ちます。

4.1.1 datatier.xml構成ファイル

ドメイン・ディレクトリのconfig/customサブディレクトリにあるdatatier.xml構成ファイルは、SIPデータ層サーバーを識別し、呼出し状態の管理に使用されるパーティションおよびレプリカも定義します。サーバー名がdatatier.xmlに存在する場合、そのサーバーは、起動時にOracle WebLogic Server SIP Container SIPデータ層の機能をロードします。(datatier.xmlに存在しないサーバー名は、エンジン層ノードとして機能し、sipserver.xml構成ファイルで構成されたSIPサーブレット・コンテナ機能を提供します)。

次の項では、一般的なSIPデータ層構成のdatatier.xmlコンテンツの例を示します。

4.1.2 構成要件および制限

SIPデータ層に参加するすべてのサーバーは、同一のWebLogic Serverクラスタのメンバーである必要があります。クラスタ構成によって、各サーバーは他のサーバーのステータスを監視できます。また、クラスタを使用すると、sipserverおよびdatatierカスタム・リソースをデプロイメント用にすべてのサーバーに容易にターゲット指定できます。

信頼性を高めるために、1つのパーティション内に最大3つのレプリカを構成できます。

レプリカやエンジン層ノードの実行中にSIPデータ層構成を変更することはできません。SIPデータ層のメンバーシップの変更や、パーティションまたはレプリカの再構成を行うためには、ドメインのサーバーを再起動する必要があります。

図4-1に示されるように、管理コンソールの「構成」>「データ層」ページ(SipServerノード)を使用して、現在のSIPデータ層構成を表示(およびデータ層を構成)できます。

図4-1 管理コンソールでのSIPデータ層の構成の表示(読取り専用)

「図4-1 管理コンソールにおけるSIPデータ層構成(読取り専用)の表示」の説明

4.2 SIPデータ層サーバーの構成および管理のベスト・プラクティス

レプリカを追加すると、システム全体としての信頼性が向上しますが、パーティションにサーバーを追加するごとに、レプリケートされたデータを処理するためのネットワークの帯域幅が余分に必要となるという点には留意が必要です。レプリカが3つのパーティションでは、呼出し状態を変更する各トランザクションに対し、3つのサーバーそれぞれのデータが更新されることになります。

レプリカを使用するときには、高い信頼性を確実に実現するために、同じパーティションの各サーバー・インスタンスはそれぞれ別個のマシンに配置します。1つのマシンで2つ以上のレプリカをホストすると、マシンまたはネットワークで障害が発生した場合に、ホストされたそれらのレプリカすべてが影響を受けることになります。

SIPデータ層サーバーが取り得るステータスは、次の3つのいずれかです。

- ONLINE: サーバーが呼出し状態トランザクションの管理に使用可能であることを示します。

- OFFLINE: サーバーがシャットダウンしているか、使用不可能であることを示します。

- ONLINE_LOCK_AUTHORITY_ONLY: サーバーが再起動され、現在の呼出し状態データを使用して(他のレプリカから)現在更新中であることを示します。リカバリ中のサーバーは、パーティションによって管理される呼出し状態のフル・コピーを保持しないため、呼出し状態トランザクションをまだ処理できません。

定期保守のためにSIPデータ層サーバー・インスタンスをオフラインにする必要がある場合、同一パーティション内の少なくとも一台の別のサーバーがアクティブであることを確認します。アクティブ・サーバーをシャットダウンし、パーティション内の他のすべてのサーバーがオフラインまたはリカバリ中の場合、アクティブな呼出し状態の一部が損失する可能性があります。

Oracle WebLogic Server SIP Containerは、すべての構成されたパーティションにわたって、自動的に呼出し状態を均等分割します。

4.3 SIPデータ層構成および構成ファイルの例

次の項では、個別のSIPデータ層を活用する一般的なOracle WebLogic Server SIP Containerインストールのいくつかについて説明します。

4.3.1 パーティションを1つ持つSIPデータ層

単一パーティションを持つ単一サーバーのSIPデータ層は、最も単純なデータ層構成を表します。例4-1は、単一サーバー・デプロイメントのSIPデータ層構成を示します。

例4-1 小規模なデプロイメントのSIPデータ層構成

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>part-1</name>
<server-name>replica1</server-name>
</partition>
</data-tier>

同一パーティションでセカンドserver-nameエントリを定義するだけでレプリカを既存のパーティションに追加できます。たとえば、例4-2で示されているdatatier.xml構成ファイルは、2つのレプリカを持つ構成を再作成します。

例4-2 レプリケーションを使用した小規模なデプロイメントのSIPデータ層構成

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
<server-name>DataNode0-1</server-name>
</partition>
</data-tier>

4.3.2 パーティションを2つ持つSIPデータ層

複数のパーティションは、例4-3で示されているように、datatier.xmlで複数のパーティション・エントリを定義することによって、容易に作成できます。

例4-3 2つのパーティションを持つSIPデータ層構成

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
</partition>
<partition>
<name>Partition1</name>
<server-name>DataNode1-0</server-name>
</partition>
</data-tier>

4.3.3 パーティションを2つおよびレプリカを2つ持つSIPデータ層

呼出し状態のレプリカは、各パーティションで複数のSIPデータ層サーバーを定義することによって追加できます。例4-4は、各パーティションに2つのパーティションと2つのサーバー(レプリカ)を持つシステムを定義するために使用されるdatatier.xml構成ファイルを示します。

例4-4 小規模なデプロイメントのSIPデータ層構成

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
<server-name>DataNode0-1</server-name>
</partition>
<partition>
<name>Partition1</name>
<server-name>DataNode1-0</server-name>
<server-name>DataNode1-1</server-name>
</partition>
</data-tier>

4.4 存続期間が長い呼出し状態データのRDBMSへの保存

Oracle WebLogic Server SIP Containerでは、RAMを節約するためにOracleまたはMySQLのRDBMSに存続期間の長い呼出し状態データを保存できるようになります。RDBMSの永続性を有効にすると、デフォルトでは、後続のダイアログ境界で、SIPデータ層は呼出しダイアログの確立後に呼出し状態のデータをRDBMSへ保持し、必要に応じて呼出し状態を変更または削除するために保持した呼出し状態を取得または削除します。

オラクル社は、SIPデータ層が呼出し状態データを保持するタイミングに関する「ヒント」を与えるために、アプリケーション・デザイナにAPIも提供します。これらのヒントは、呼出し状態データをRDBMSへより頻繁に保持するか、または特定の呼出しの永続性を無効化するために使用できます。

Oracle WebLogic Server SIP Containerは、SIPデータ層のメモリー内レプリケーション機能を補填するためにRDBMSのみを使用します。RDBMS使用時の待機時間パフォーマンスを向上させるには、SIPデータ層は、アクティブに変更中の呼出し状態(たとえば、設定中の新しい呼出しへのレスポンス)に従ってSIPタイマーをメモリーに保持します。呼出し状態は、後続のダイアログ境界で、ダイアログの確立後に呼出しが実行中のとき、またはアプリケーション開発者によって追加された永続性ヒントのレスポンスときのみ自動的に保持されます。

RDBMSと組み合せて使用した場合、SIPデータ層はデータベースに書き込む(またはデータベースから削除する)呼出し状態を処理するために、レプリカ・サーバー・インスタンスを1つ選択します。使用可能なレプリカならどれでも、次の読込みのために必要に応じて永続的な保持から呼出し状態を検索するために使用できます。

RDBMS呼出し状態ストレージは、ドメインがエンジン層への接続管理にSIPを認識できるロード・バランサを使用する場合、エンジン層キャッシュと組み合せて使用できます。詳細は、4.7項「SIPデータのエンジン層へのキャッシュ」を参照してください。

4.4.1 要件および制約

以下のすべての基準に一致した場合のみ、RDBMSへの呼出し状態の格納が有効になります。

- システムで管理された呼出し状態は通常、長期間維持されます。

- 格納する呼出し状態はサイズが大きなものです。呼出し状態が非常に大きい場合は、呼出し状態の格納に大量のRAMが必要です。

- 待機時間パフォーマンスはデプロイされたアプリケーションにクリティカルではありません。

RDBMSへの呼出し状態データの格納を選択する前に、特に待機時間要件をよく理解しておく必要があります。RDBMSへの呼出し状態の格納のオプションは、SIPデータ層クラスタを使用する場合と比較すると、SIPメッセージ処理を行うためにレイテンシがある程度増加します。システムで短いレスポンス時間で多数の存続期間の短いSIPトランザクションを処理しなければならない場合、データ層に呼出し状態データを格納することをお薦めします。

注意:
RDBMSの永続性は、大規模な長期間維持する呼出し状態のSIPデータ層でRAM要件を抑えるように設計されています。永続性されたデータは、障害が発生したSIPデータ層パーティションやレプリカを復元する目的では使用できません。

4.4.2 RDBMS呼出し状態ストレージを有効化する手順

RDBMS呼出し状態ストレージ機能を使用するためには、Oracle WebLogic Server SIP Containerドメインには、必要なJDBC構成、SIPサーブレット・コンテナ構成、および呼出し状態の保存に必要なスキーマを持つデータベースが含まれる必要があります。RDBMS呼出し状態テンプレートを使用して新規ドメインを設定するために構成ウィザードを使用することによって、必要な構成の多くを自動化できます。詳細は、4.4.3項「構成ウィザードのRDBMSストア・テンプレートの使用」を参照してください。

既存のOracle WebLogic Server SIP Containerドメインを持っている場合、または独自のRDBMSストアを構成する場合、RDBMSストアを使用するためにJDBCおよびOracle WebLogic Server SIP Containerを構成するための手順は、4.4.4項「手動によるRDBMS呼出し状態ストレージの構成」を参照してください。

4.4.3 構成ウィザードのRDBMSストア・テンプレートの使用

構成ウィザードでは、RDBMSへの呼出し状態の格納の使用とテストを簡単に行うための単純なテンプレートを提供します。テンプレートから新しいドメインを作成するには、次の手順に従います。

1. 構成ウィザード・アプリケーション(config.sh)を起動します。

2. デフォルトの選択「新しいWebLogicドメインの作成」を受け入れ、「次へ」をクリックします。

3. 「既存のテンプレートを、このドメインのベースにする」を選択し、「参照」をクリックして「テンプレートの選択」ダイアログを表示します。

4. replicateddomain.jarという名前のテンプレートを選択し、「OK」をクリックします。

5. 「次へ」をクリックします。

6. 新しいドメインの管理者のユーザー名とパスワードを入力し、「次へ」をクリックします。

7. 使用するJDKを選択し、「次へ」をクリックします。

8. ソース・テンプレート・ファイルに定義されている設定をそのまま使用する場合は「いいえ」を選択し、「次へ」をクリックします。

9. 「作成」をクリックしてドメインを作成します。
テンプレートはクラスタに2つのエンジン層サーバーとSIPデータ層サーバー、および管理サーバー(AdminServer)を持つ新しいドメインを作成します。エンジン層クラスタには、次のリソースおよび構成が含まれます。

- 存続期間の長い呼出し状態データの保存に必要なwlss.callstate.datasourceというJDBCデータソース。独自のRDBMSサーバーにデータソースを構成するには、この構成を変更する必要があります。詳細は、4.4.3.1項「JDBCデータソース接続情報」を参照してください。

- RDBMSおよび地理的冗長性の両方の永続性ヒントのデフォルト処理を定義する永続性構成(SipServerノードの管理コンソールの「構成」>「永続性」タブで表示)。

10. 「完了」をクリックし、構成ウィザードを終了します。

11. RDBMSで必要な表を作成するには、4.4.3.1項「JDBCデータソース接続情報の変更」の手順に従います。

12. RDBMSで必要な表を作成するには、4.4.4.3項「データベース・スキーマの作成」の手順に従います。

4.4.3.1 JDBCデータソース接続情報の変更

新しいドメインのインストール後、RDBMSサーバーの接続情報を含めるようテンプレートJDBCデータ・ソースを変更します。

1. ブラウザを使用してURL (http://address:port/console)にアクセスします。ここで、addressは管理サーバーのリスニング・アドレス、portはリスニング・ポートです。

2. 「ドメイン構造」パネルの(ぺジーの左)スクロール・リストから「サービス」>「データ・ソース」を選択します。

3. 右ペインのwlss.callstate.datasourceというデータ・ソースを選択します。

4. 右ペインで、「構成」>「接続プール」タブを選択します。

5. 以下の接続プール・プロパティを変更します。

- URL: RDBMSサーバーのホスト名およびポート番号を指定するためのURLを変更します。

- プロパティ: RDBMSの接続情報に一致するようにユーザー、portNumber、SID、およびserverNameプロパティの値を変更します。

- パスワードおよびパスワードの確認:指定したRDBMSユーザーのパスワードを入力します。

6. 「保存」をクリックして変更を保存します。

7. 右ペインで「ターゲット」タブを選択します。

8. 「ターゲットの選択」ページで、SIPデータ層クラスタの名前(BEA_DATA_TIER_CLUSTなど)を選択してから、「保存」をクリックします。

9. 「保存」をクリックします。

10. RDBMSで必要な表を作成するには、4.4.4.3項「データベース・スキーマの作成」の手順に従います。

4.4.4 手動によるRDBMS呼出し状態ストレージの構成

既存のOracle WebLogic Server SIP Containerドメインが、OracleまたはMySQLのRDBMSに呼出し状態データを保存するように変更するには、必要なJDBCリソースを構成し、Oracle WebLogic Server SIP Container構成を編集し、必要なスキーマをデータベースに追加する必要があります。Oracleデータベースを構成するには、次の項の手順に従います。

4.4.4.1 JDBCリソースの構成

ドメインに必要なJDBCリソースを作成するには、以下の手順に従います:

1. ドメインの管理サーバーが実行中でなければ、起動します。

2. ドメインの管理コンソールにアクセスします。

3. 「ドメイン構造」パネルの(ぺジーの左)スクロール・リストから「サービス」>「データ・ソース」を選択します。

4. 「New」をクリックして、新しいデータ・ソースを作成します。

5. 「Create a New JDBC Data Source」ページの各フィールドに、次の情報を入力します。

- 名前: wlss.callstate.datasourceを入力します。

- JNDI名:wlss.callstate.datasourceを入力します。

- データベース・タイプ:「Oracle」を選択します。

- データベース・ドライバ:「データベース・ドライバ」リストから適切なJDBCドライバを選択します。このフィールドにリストされているドライバの一部は、デフォルトではシステムにインストールされない場合があります。RDBMSベンダーからの指示がある場合、必要に応じてサードパーティのドライバをインストールします。

6. 「次へ」をクリックします。

7. 使用するデータベースの接続情報を使用して、「接続プロパティ」タブのフィールドに入力します。「次へ」をクリックして続行します。

8. 「構成をテスト」をクリックしてRDBMSへの接続をテストするか、「次へ」をクリックして続行します。

9. 「Select Targets」ページで、SIPデータ層クラスタ名(例えば、BEA_DATA_TIER_CLUST)を選択します。

10. 「終了」をクリックして変更内容を保存します。

4.4.4.2 Oracle WebLogic Server SIP Containerの永続性オプションの構成

Oracle WebLogic Server SIP Containerの永続性オプションが、RDBMS呼出し状態ストアを使用するように構成するには、次の手順に従います。

1. ドメインの管理サーバーが実行中でなければ、起動します。

2. ドメインの管理コンソールにアクセスします。

3. 左ペインで「SipServer」ノードをクリックします。

4. 右ペインで、「構成」>「永続性」タブを選択します。

5. 「デフォルトの処理」ドロップダウン・メニューで、「db」または「all」のいずれかを選択します。「地域サイトID」および「地域リモートT3 URL」フィールドが構成済の場合、地理的に冗長なレプリケーションのみが実行されるため、「all」を選択しても構いません。

6. 「保存」をクリックして変更を保存します。

4.4.4.3 データベース・スキーマの作成

Oracle WebLogic Server SIP Containerには、呼出し状態情報の保存に必要な表を作成するために使用できるcallstate.sqlというSQLスクリプトが含まれます。このスクリプトは、構成ウィザードを使用してレプリケートされたドメインを構成するとき、ドメイン・ディレクトリのuser_staged_configサブディレクトリにインストールされます。また、このスクリプトは、WLSS_HOME/common/templates/scripts/db/oracleディレクトリでも使用できます。

callstate.sqlというSQLスクリプトのコンテンツは、例4-5で示されます。

例4-5 呼出し状態ストレージ・スキーマのcallstate.sqlスクリプト

drop table callstate;

create table callstate (
key1 int,
key2 int,
bytes blob default empty_blob(),
constraint pk_callstate primary key (key1, key2)
);

SQL*Plusを使用してスクリプト・コマンドを実行するには、以下の手順に従います。

1. SQLスクリプトの保存場所となるOracle WebLogic Server SIP Containerのutilsディレクトリに移動します。

cd ~/bea/wlcserver_10.3/common/templates/scripts/db/oracle

2. 必要な表の作成場所となるOracleデータベースに接続し、SQL*Plusアプリケーションを起動します。同一のユーザー名およびパスワードを使用し、4.4.4.1項「JDBCリソースの構成」でJDBCドライバを構成するときに指定したのと同一のデータベースに接続します。例:

sqlplus username/password@connect_identifier

ここで、connect_identifierは、JDBC接続プールで識別されたデータベースに接続します。

3. Oracle WebLogic Server SIP Containerのcallstate.sqlというSQLスクリプトを実行します。

START callstate.sql

4. SQL*Plusを終了します。

EXIT

4.4.5 SIPアプリケーションにおける永続性ヒントの使用

Oracle WebLogic Server SIP Containerは、SIPデータ層が呼出し状態データを保持する期間に関する「ヒント」を与えるための単純なAPIを提供します。このAPIを使用して固有の呼出しまたはSIPリクエストの永続性を無効化したり、(SIPダイアログ境界で)デフォルト設定よりも頻繁にデータを保持したりできます。

このAPIを使用するには、WlssSipApplicationSessionインスタンスを取得し、永続性を有効化/無効化するためのsetPersistメソッドを使用します。RDBMSストアまたは地理的に冗長なOracle WebLogic Server SIP Containerインストールのいずれかへの永続性を有効化/無効化できます(4.6項「地理的に冗長なSIPデータ層の使用」を参照してください)。

たとえば、一部のSIPを認識できるロード・バランシング製品は、SIPサーバーがアクティブかどうかの判定にSIP OPTIONSメッセージを使用します。RDBMSおよび地理的に冗長なサイトへのこれらのメッセージを保持しないようにするには、例4-6で示されるように、リクエストをエコーしてメッセージの永続性をオフにするために、サーブレットがdoOptionsメソッドを実装する場合があります。

例4-6 オプション・メソッドのRDBMS永続性の無効化

protected void doOptions(SipServletRequest req) throws IOException {
WlssSipApplicationSession session =
(WlssSipApplicationSession) req.getApplicationSession();
session.setPersist(WlssSipApplicationSession.PersistenceType.DATABASE,
false);
session.setPersist(WlssSipApplicationSession.PersistenceType.GEO_REDUNDANCY, false);
req.createResponse(200).send();
}

4.5 地理的冗長性の概要

地理的冗長性は、地理的に区別されたSIPサーバー・デプロイメントを使用して、トランザクションおよびプロバイダへの通信を中断しないことを保証します。

プライマリ・サイトは、各種SIPトランザクションおよび通信を処理し、トランザクション境界の決定時に、処理中のトランザクションに関連する状態データをセカンダリ・サイトにレプリケートできます。プライマリ・サイトの障害時には、処理のために呼出しは障害の発生したプライマリ・サイトからセカンダリ・サイトにルーティングされます。同様に、リカバリ時には、呼出しはプライマリ・サイトに再ルーティングされます。

図4-2 地理的冗長性

「図4-2 地理的冗長性」の説明

前の図では、地理的冗長性が表されています。プロセスは次の手順で進行します。

1. 呼出しはプライマリOCCASクラスタ・サイト上で発信され、呼出し設定および処理が通常どおり行われます。

2. 呼出しは通常通りにサイトのSIP状態層へレプリケートされ、セカンダリ・サイトへのレプリケーションの対象となります。

3. 次に、SIP状態層の単一レプリカは、構成済のJMSキューでレプリケートされるように呼出し状態データを配置します。

4. 呼出しは、WAN経由でJMSを使用して使用可能なエンジンのいずれかに送信されます。

5. セカンダリ・サイトのエンジンは、新規メッセージのローカル・キューを監視します。メッセージの受信時に、セカンダリ・サイトのOCCASクラスタのエンジンは呼出し状態データを保持し、プライマリ・サイトのサイトID値に割り当てます。

表4-1 地理的冗長性のフロー

通常操作

フェイルオーバー

セッションがプライマリOCCASサイト上で発信されるとき、通常は呼出し設定および処理が発生します。

プライマリ・サイトからセカンダリ・サイトへの呼出しのルーティングを開始するために更新されるグローバルLBポリシー

SIPトランザクション境界に到達すると、呼出しはサイトのデータ層にレプリケートされ(メモリー内)、セカンダリ・サイトへのレプリケーション対象になります。

完了すると、セカンダリ・サイトはバックアップされた呼出し状態データのリクエストの処理を開始します。

次に、データ層の単一レプリカは、レプリカ・サイトで構成されたJMSキューでレプリケートされるように呼出し状態データを配置します。

リクエストがセカンダリ・サイトに到達すると、エンジンはデータを取得して呼出し状態をアクティブ化し、呼出しの所有権を取得します。

データは、使用可能なエンジンのいずれかにラウンドロビン方式で送信されます。

呼出しに関連付けられたサイトIDを(ローカルとして表示されるように)ゼロに設定します。

セカンダリ・サイトのエンジンは、新規メッセージのローカル・キューを監視します。

呼出し状態にあるすべての休眠タイマーをアクティブ化します。

メッセージの受信時に、セカンダリ・サイトのエンジンは呼出し状態データを保持し、プライマリ・サイトのサイトID値に割り当てます。

デフォルトでは、呼出し状態は各呼出しに対してのみ、バックアップ・サイトでリクエストされる呼出しの後でのみアクティブ化されます。

サイトIDは、セカンダリ・サイト上でレプリケートされた呼出し状態データを、セカンダリ・サイトによってアクティブに管理される他の呼出し状態データと区別します。

サーブレットは、呼出しに関連付けられたサイトIDを確認するために、WlssSipApplicationSession.getGeoSiteId()メソッドを使用できます。

レプリケートされた呼出し状態データのタイマーは、タイマー処理がパフォーマンスに対してボトルネックにならないようにするため、セカンダリ・サイト上で休眠状態のままです。

サイトIDのゼロ以外の値は、サーブレットが別のサイトからレプリケートされた呼出し状態データを使用して機能することを示します。

4.5.1 地理的冗長性の使用に最適な状況

次の状況は、地理的冗長性の利用に最適です。

- アプリケーションは存続期間が長いSIPダイアログ状態(SUBSCRIBEダイアログや会議などの、通常は30秒以上続くダイアログ状態)を使用します。

- アプリケーションは、レプリケートされた状態からセッション(re-INVITE、再サブスクライブをトリガーするSUBSCRIBEダイアログの期限切れなど)を適切に再構築できるようになります。

- 2つのOCCASクラスタまたはサイト間のリンクは、帯域幅(各方向<1Gb/s)が低いか、または待機時間(>5ms 95%)が高く(または可変に)なります。

4.5.2 地理的冗長性の使用に適していない状況

地理的冗長性は、次の状況では使用しないでください。

- サイト間の高容量リンクが使用できる場合。

- アプリケーションは、SIPダイアログの安定した状態に到達しません。この状態は、致命的な障害の場合に、セカンダリ・サイトへのすべてのトラフィックを再ルーティングするためにかかる時間(15から30秒)よりも長くなる可能性があります。

- アプリケーションがセッションを再構築する前に、アプリケーション・セッションがユーザーによって終了される可能性がある場合(大半のユーザーは、セッションがセカンダリ・サイトから再確立する前に呼出しを切断します)。

- アプリケーションによって作成されるセッション状態オブジェクトの量が、サイトの相互接続がサポート可能な量より大きくなります。

4.5.3 地理的冗長性の考慮: 開始前

地理的冗長性を計画するとき次を考慮してください。

- サイト・リンクのシステムのディメンション

- 伝送路上の各ダイアログ状態は25 KBまで(25600ビット)

- 通常のB2BUAは2つのダイアログ

- リンク上で「ジッター」かつ持続された待機時間に対応するために使用率25% (固有の設備やサイトのトポロジによっては、25%以下)を目標にします。
たとえば、100 Mb/sのリンクは、呼出し状態を1秒間に約1000回処理でき、通常のB2BUA (デフォルト構成)は呼出し中に4つの状態を生成します(各ダイアログに2つ)。そのため、100 Mb/sのリンクは、ピーク時の受信率(コール率)が250 CPSのディメンションの単一のOWLSCクラスタをサポートします。

- 地理的冗長性は、アプリケーションに対して透過的ではありません。大半の場合、アプリケーションはSetPersist()を適切に使用するように設計される必要があり、開発者はアプリケーションがサイト間のレプリケーションのキューを実行する状態の量を考慮する必要があります。

- SetPersist()は、存続期間が長いダイアログ状態を選択的に識別するために、アプリケーション・コード内で使用される必要があります。

- セカンダリ・サイトへのトラフィックをルーティングするために通常かかる時間を想定すると、状態をレプリケートする頻度がより高いアプリケーションは、JMSキューおよびサイトの相互接続を不必要に飽和させることになります。

- JMSを固有のアプリケーション環境にチューニング擦る必要があります。シリアライズ・オプション、メッセージのバッチ処理、信頼できる送信オプションおよびキュー・サイズは、固有のアプリケーションおよびサイトの特性に応じてすべて変化します。

- 地理的冗長性のデフォルト動作は、地理的冗長性がコンテナに有効化されているときにすべてのダイアログ状態の変化をレプリケートすることです(これは本番デプロイメントではお薦めできません)。

- セカンダリ・サイトへのトラフィックをルーティングするために通常かかる時間を想定すると、状態をレプリケートする頻度がより高いアプリケーションはサイトの相互接続を不必要に飽和させることになります。

- SetPersist()は、存続期間が長いダイアログ状態を選択的に識別するために、アプリケーション・コード内で使用される必要があります(20から30秒より長くすると適切なしきい値になります)。

4.6 地理的に冗長なSIPデータ層の使用

Oracle WebLogic Server SIP ContainerのSIPデータ層で使用可能な基本的な呼出し状態のレプリケーション機能によって、単一のサイト・インストールに優れたフェイルオーバー機能が提供されます。ただし、SIPデータ層内で実行されるアクティブなレプリケーションでは、大半の本番ネットワークが求める待機時間パフォーマンスのニーズを満たすために、ネットワーク帯域幅を高くする必要があります。この帯域幅の要件によって、ある地域のデータ・センターから別の地域のデータ・センターまでといった、長距離に渡るデータのレプリケーションには、単一のSIPデータ層クラスタが適さないようになります。

Oracle WebLogic Server SIP Containerの地理的永続性機能によって、複数のOracle WebLogic Server SIP Containerインストール(複数の管理ドメインまたは「サイト」)全体に渡って呼出し状態トランザクションをレプリケートできるようになります。地理的に冗長な構成によって、広範囲の地域的な停電といったサイト全体の致命的な障害の場合に、呼出しの切断が最小化されます。

図4-3 Oracle WebLogic Server SIP Containerの地理的永続性

「図4-3 Oracle WebLogic Server SIP Containerの地理的永続性」の説明

4.6.1 例として使用するドメイン構成

別のドメインからデータを保持するセカンダリOracle WebLogic Server SIP Containerドメインは、それ自体でSIPトラフィックを処理したり、アクティブ・スタンバイ・ドメインとして単体で存在できます。最も一般的な構成では、お互いの呼出し状態データをレプリケートするために2つのサイトが構成され、各サイトは独自のローカルSIPトラフィックを処理します。そのため、いずれかのドメインで障害が発生しても、管理者はいずれかのドメインを「セカンダリ」サイトとして使用できます。

図4-4 一般的な地理的に冗長な構成

「図4-4 一般的な地理的冗長な構成」の説明

代替構成は複数の他のサイトからのデータを永続性する1つのドメインを使用して、それらのサイトのセカンダリ・サイトとして機能します。この構成のセカンダリ・サイトはそれ自体のローカルSIPトラフィックも処理できますが、他のいくつかのインストールからのアクティブなトラフィックを永続性する必要があるため、サイトのリソース要件が大きくなる可能性があります。

図4-5 地理的に冗長な代替構成

「図4-5 地理的に冗長な代替構成」の説明

地理的永続性を使用するとき、プライマリ・サイトの単一のレプリカは、変更された呼出し状態データを分散されたJMSキューに配置します。デフォルトでは、データはSIPダイアログ境界のキューにのみ配置されます。(カスタムAPIは、4.4.5項「SIPアプリケーションにおける永続性ヒントの使用」で説明されているように、粒度の高い細分度を使用してデータをレプリケートするアプリケーション開発者に提供されます。)セカンダリ・サイトでは、エンジン層サーバーはメッセージ・リスナーを使用して、メッセージを受信したり独自のSIPデータ層クラスタへデータを書き込んだりするために、分散されたキューを監視します。セカンダリ・サイトが、存続期間の長い呼出し状態を保存するためにRDBMSを使用する場合(お薦め)、分散されたキューからのすべてのデータ書込みは、SIPデータ層のメモリー内ストレージではなく、RDBMSへ直接送信されます。

4.6.2 要件および制約

Oracle WebLogic Server SIP Containerの地理的に冗長な永続性機能は、存続期間の長い呼出し状態データをRDBMSで管理するサイトに対して非常に役に立ちます。存続期間の短い呼出しは、サイト間のレプリケーションを行う前に、Oracle WebLogic Server SIP Containerが複数の呼出し状態のデータを収集することを選択する場合があるため、セカンダリ・サイトへの遷移の際に損失する可能性があります。

地理的な場所同士の呼出しを区分し、所定の地域のサイト状態を監視できる、信頼性が高くサイトを認識可能なロード・バランス・ソリューションを用意する必要があります。Oracle WebLogic Server SIP Containerには、ドメイン全体の障害検出や、セカンダリ・サイトへのフェイルオーバーの実行を自動的に行う機能はありません。所定のサイトで「障害が発生した」ときを判断し、サイトの呼出しを適切なセカンダリ・サイトへリダイレクトするのは、管理者の責任となります。また、サイトを認識可能なロード・バランサは、所定のcallIdに対するすべてのメッセージを単一のホーム・サイト(「アクティブな」サイト)へ直接送信する必要があります。フェイルオーバー後、障害の発生したサイトがリストアされる場合、ロード・バランサは2つのサイト間の呼出しを区分せずに、アクティブなサイトへの呼出しの直接送信を継続する必要があります。

セカンダリ・サイトへのフェイルオーバー中に、一部の呼出しが切断される場合があります。これは、Oracle WebLogic Server SIP Containerが通常、SIPダイアログ境界でのみ、サイト・レプリケーションの呼出し状態データのキューを実行するために発生します。データをキューへ書き込む前に発生する障害によって、キューに入れられたデータは損失してしまいます。

また、Oracle WebLogic Server SIP Containerは、SIPダイアログ境界が呼出し状態を変更するときのみサイト全体の呼出し状態データをレプリケートします。セカンダリ・サイトが起動される前にプライマリ・サイト上に実行時間の長い呼出しが存在する場合、呼出し状態は変更されず、その呼出しのデータはセカンダリ・サイトにレプリケートされません。実行時間の長い呼出し状態がレプリケートされる前に障害が発生してしまうと、呼出しはフェイルオーバー中に損失されます。

Oracle WebLogic Server SIP Containerインストールの容量を計画するとき、フェイルオーバー後には、障害の発生したサイトおよび独自の地理的位置からのすべての呼出しを所定のサイトがサポートする必要があります。本質的に、地理的に冗長な構成のすべてのサイトは、フェイルオーバーが起こるまでは最大限の容量以下で稼働することになります。

4.6.3 地理的永続性を構成するための手順

Oracle WebLogic Server SIP Containerの地理的永続性機能を使用するためには、プライマリ「ホーム」サイトおよびセカンダリ・レプリケーション・サイトの両方で、特定の構成タスクを実行する必要があります。

表4-2 地理的永続性の構成の手順

プライマリ「ホーム」サイトの手順

セカンダリ「レプリケーション」サイトの手順

1. Oracle WebLogic Server SIP Containerソフトウェアをインストールし、レプリケートされたドメインを作成します。

2. 長期間維持する呼出し状態のRDBMSへの格納を可能にします(推奨)。

3. 永続性オプションを構成し、一意の地域サイトIDの定義、セカンダリ・サイトのURLの識別、レプリケーション・ヒントの有効化を行います。

1. Oracle WebLogic Server SIP Containerソフトウェアをインストールし、レプリケートされたドメインを作成します。

2. 長期間維持する呼出し状態のRDBMSへの格納を可能にします(推奨)。

3. データをレプリケートするのに必要なJMSサーバーおよびモジュールを構成します。

4. 永続性オプションを構成し、一意の地域サイトIDを定義します。

注意:
ほとんどの本番デプロイメントでは、2つのサイトが相互に複製サービスを行うため、一般的にはインストールをそれぞれプライマリおよびセカンダリ・サイトとして構成します。

Oracle WebLogic Server SIP Containerは、表4-2で説明されているように、大半のリソースの構成を自動化するためのドメイン・テンプレートを提供します。テンプレートの使用に関する詳細は、4.6.4項「構成ウィザードの地理的永続性用テンプレートの使用」を参照してください。

既存のOracle WebLogic Server SIP Containerドメインを持ち、地理的永続性を使用する場合、リソースを作成するには、4.6.5項「手動による地理的冗長性の構成」の手順に従います。

4.6.4 地理的永続性用の構成ウィザード・テンプレートの使用

Oracle WebLogic Server SIP Containerは、地理的永続性機能に使用する2つの構成ウィザード・テンプレートを提供します。

- WLSS_HOME/common/templates/domains/geo1domain.jarは、サイトIDが1のプライマリ・サイトを構成します。このドメインは、geo2domain.jarで作成されたエンジン層サーバーへデータをレプリケートします。

- WLSS_HOME/common/templates/domains/geo2domain.jarは、geo1domain.jarを使用して作成されたドメインからの呼出し状態データをレプリケートするセカンダリ・サーバーを構成します。このインストールのサイトIDは2です。

どちらのドメイン・テンプレートのサーバー・ポート番号も固有の番号であるため、必要に応じて1台のマシンで地理的永続性の機能をテストすることができます。各ドメインのインストールと構成を行うには、次の節に示す手順に従います。

4.6.4.1 プライマリ・サイトのインストールおよび構成

テンプレートから新しいプライマリ・ドメインを作成するには、以下の手順に従います。

1. 構成ウィザード・アプリケーション(config.sh)を起動します。

2. デフォルトの選択「新しいWebLogicドメインの作成」を受け入れ、「次へ」をクリックします。

3. 「既存のテンプレートを、このドメインのベースにする」を選択し、「参照」をクリックして「テンプレートを選択」ダイアログを表示します。

4. geo1domain.jarという名前のテンプレートを選択し、「OK」をクリックします。

5. 「次へ」をクリックします。

6. 新しいドメインの管理者のユーザー名およびパスワードを入力し、「次へ」をクリックします。

7. 使用するJDKを選択し、「次へ」をクリックします。

8. ソース・テンプレート・ファイルで定義された設定を保持するなら「いいえ」を選択し、「次へ」をクリックします。

9. 「作成」をクリックし、ドメインを作成します。
テンプレートはクラスタに2つのエンジン層サーバーとSIPデータ層サーバー、および管理サーバー(AdminServer)を持つ新しいドメインを作成します。エンジン層クラスタには、次のリソースおよび構成が含まれます。

- 存続期間の長い呼出し状態データの保存に必要なwlss.callstate.datasourceというJDBCデータソース。この機能を使用する場合は、4.4.3.1項「JDBCデータソース接続情報の変更」で説明されているように、RDBMS接続情報を含めるようにデータソースを編集します。

- 永続性の構成(SipServerノードの管理コンソールの「構成」>「永続性」タブで表示)は次を定義します。

- RDBMSおよび地理的永続性の両方に対する永続性のヒントのデフォルト処理

- Geo Site IDは1です。

- 「geo2」ドメインのエンジン層サーバーを地理的冗長性のレプリケーション・サイトとして識別するt3://localhost:8011、localhost:8061の「地域リモートT3 URL」。

10. 「完了」をクリックして、構成ウィザードを終了します。

11. レプリケーションを実行するドメインを作成するには、4.6.4.2項「セカンダリ・サイトのインストール」の手順に従います。

4.6.4.2 セカンダリ・サイトのインストール

「geo1」ドメインからの呼出し状態データをレプリケートすることによってセカンダリ・サイトを作成するためにテンプレートを使用するには、次の手順に従います。

1. 構成ウィザード・アプリケーション(config.sh)を起動します。

2. デフォルトの選択「新しいWebLogicドメインの作成」を受け入れ、「次へ」をクリックします。

3. 「既存のテンプレートを、このドメインのベースにする」を選択し、「参照」をクリックして「テンプレートを選択」ダイアログを表示します。

4. geo2domain.jarという名前のテンプレートを選択し、「OK」をクリックします。

5. 「次へ」をクリックします。

6. 新しいドメインの管理者のユーザー名およびパスワードを入力し、「次へ」をクリックします。

7. 使用するJDKを選択し、「次へ」をクリックします。

8. ソース・テンプレート・ファイルで定義された設定を保持するなら「いいえ」を選択し、「次へ」をクリックします。

9. 「作成」をクリックし、ドメインを作成します。
テンプレートはクラスタに2つのエンジン層サーバーとSIPデータ層サーバー、および管理サーバー(AdminServer)を持つ新しいドメインを作成します。エンジン層クラスタには、次のリソースおよび構成が含まれます。

- 存続期間の長い呼出し状態データの保存に必要なwlss.callstate.datasourceというJDBCデータソース。この機能を使用する場合は、4.4.3.1項「JDBCデータソース接続情報の変更」で説明されているように、RDBMS接続情報を含めるようにデータソースを編集します。

- 永続性の構成(SipServerノードの管理コンソールの「構成」>「永続性」タブで表示)は次を定義します。

- RDBMSおよび地理的な永続性の両方に対する永続性ヒントのデフォルト処理

- Geo Site IDは2です。

- SystemModule-CallstateというJMSシステム・モジュールは次を含みます。

- プライマリ・サイトからの呼出し状態データのバックアップに必要なConnectionFactory-Callstateという接続ファクトリ。

- プライマリ・サイトからの呼出し状態データのバックアップに必要なDistributedQueue-Callstateという共通分散キュー。

JMSシステム・モジュールは、サイトのエンジン層クラスタをターゲットにしています。

- JMSServer-1およびJMSServer-2という2つのJMSサーバーは、それぞれengine1-site2およびengine2-site2へデプロイされます。

10. 「完了」をクリックし、構成ウィザードを終了します。

4.6.5 手動による地理的冗長性の構成

レプリケートされた既存のOracle WebLogic Server SIP Containerインストールまたはインストールのペアがある場合、地理的冗長性を有効化するために必要なJMSおよびJDBCリソースを手動で作成する必要があります。また、レプリケーションを実行する各サイトを構成する必要もあります。地理的冗長性を有効化するためのこれらの基本手順は次のとおりです。

1. JDBCリソースを構成します。存続期間の長い呼出し状態データをRDBMSに保存するために、プライマリおよびセカンダリ・サーバーの両方を構成することをお薦めします。

2. 永続性オプションを構成します。永続性オプションは、エンジン層のヒントがRDBMSへ書き込んだり地理的に冗長なインストールへデータをレプリケートしたりできるように、プライマリおよびセカンダリ・サイトの両方で構成される必要があります。

3. JMSリソースを構成します。セカンダリ・サイトは、別のサイトからの呼出し状態データをレプリケートするために、使用可能なJMSサーバーおよび固有のJMSモジュール・リソースを持つ必要があります。

以下の節では、各手順について詳しく説明します。

4.6.5.1 JDBCリソースの構成(プライマリおよびセカンダリ・サイト)

存続期間の長い呼出し状態をRDBMSに保存するために必要なJDBCリソースを構成するには、4.4項「存続期間が長い呼出し状態データのRDBMSへの保存」 の手順に従います。

4.6.5.2 永続性オプションの構成(プライマリおよびセカンダリ・サイト)

地理的な冗長なレプリケーションを有効化にするために、プライマリおよびセカンダリ・サイトに正しく永続性の設定を行う必要があります。永続性を構成するには、次の手順に従います。

1. ブラウザを使用してURL (http://address:port/console)にアクセスします。ここで、addressは管理サーバーのリスニング・アドレス、portはリスニング・ポートです。

2. 「ロックして編集」をクリックし、構成ロックを取得します。

3. 左ペインで「SipServer」ノードを選択します。コンソールの右ペインには、Oracle WebLogic Server SIP Containerの構成および監視に使用される2レベルのタブ・ページがあります。

4. 右ペインで「構成」>「永続性」タブを選択します。

5. 永続性の属性を次のように構成します。

- デフォルト処理: 「すべて」を選択し、存続期間の長い呼出し状態データをRDBMSへ保持し、地理的冗長性のために外部サイトへデータをレプリケートします(お薦め)。インストールが呼出し状態データをRDBMSに保存しない場合、「すべて」ではなく「geo」を選択します。

- 地域サイトID:1から9の一意の番号を入力し、このサイトを他のすべての構成済サイトと区別します。0のサイトIDは、対象のサイトに対してローカルな呼出し状態(別のサイトからレプリケートされていない呼出し状態)を示すために予約されます。

- 地域リモートT3 URL:プライマリ・サイト(または独自のデータを別のサイトへレプリケートするセカンダリ・サイト)では、T3 URLまたはサイトの呼出し状態データをレプリケートするエンジン層サーバーのURLを入力します。セカンダリ・エンジン層クラスタがクラスタ・アドレスを使用する場合、t3://mycluster:7001などの単一のT3 URLを入力できます。セカンダリ・エンジン層クラスタがクラスタ・アドレスを使用しない場合、t3://engine1-east-coast:7001,t3://engine2-east-coast:7002,t3://engine3-east-coast:7001,t4://engine4-east-coast:7002のように、カンマで区切られた個別のエンジン層サーバーのURLを入力します。

6. 「保存」をクリックし、構成の変更を保存します。

7. 「変更のアクティブ化」をクリックし、変更をエンジン層サーバーに適用します。

4.6.5.3 JMSリソースの構成(セカンダリ・サイトのみ)

もう一方のサイトから呼出し状態データをレプリケートするサイトはすべて、特定のJMSリソースを構成する必要があります。一方のサイトからデータをレプリケートしないサイトには、リソースは必要ありません。

JMSリソースを設定するには、以下の手順に従います。

1. ブラウザを使用してURL (http://address:port/console)にアクセスします。ここで、addressは管理サーバーのリスニング・アドレス、portはリスニング・ポートです。

2. 「ロックして編集」をクリックし、構成ロックを取得します。

3. 左ペインで「サービス」>「メッセージング」>「JMSサーバー」タブを選択します。

4. 右ペインで「新規」をクリックします。

5. JMSサーバーの一意の名前を入力するか、またはデフォルト名を受け入れます。「次へ」をクリックして続行します。

6. 「ターゲット」リストで、インストールにおける単一のエンジン層サーバー・ノードの名前を選択します。「終了」をクリックし、新規サーバーを作成します。

7. インストールで各エンジン層サーバー・ノードに専用のJMSサーバーを作成するには、手順3 - 6を繰り返します。

8. 左ペインで「サービス」>「メッセージング」>「JMSモジュール」ノードを選択します。

9. 右ペインで「新規」をクリックします。

10. 「JMSシステム・モジュール」ページのフィールドに、以下の情報を入力します。

- 名前:新規モジュールの名前を入力するか、またはデフォルト名を受け入れます。

- 記述子ファイル名:JMSモジュール構成を保存する場所の構成ファイル名の接頭辞を入力します(systemmodule-callstateなど)。

11. 「次へ」をクリックして、続行します。

12. エンジン層クラスタの名前を選択し、「クラスタのすべてのサーバー」オプションを選択します。

13. 「次へ」をクリックして続行します。

14. 「このJMSシステム・モジュールにリソースを追加しますか。」を選択し、「終了」をクリックしてモジュールを作成します。

15. モジュールに新しいリソースを追加するには、「New」をクリックします。

16. 「接続ファクトリ」オプションを選択し、「次へ」をクリックします。

17. 「Create a new JMS System Module Resource」の各フィールドに、以下の情報を入力します。

- 名前:ConnectionFactory-Callstateなどの、リソースの説明的な名前を入力します。

- JNDI名:wlss.callstate.backup.site.connection.factoryという名前を入力します。

18. 「次へ」をクリックして続行します。

19. 「終了」をクリックし、新規リソースを保存します。

20. 今作成した接続ファクトリ・リソース名を選択します。

21. 右ペインで「構成」>「ロード・バランシング」タブを選択します。

22. 「サーバー・アフィニティの有効化」オプションの選択を解除し、「保存」をクリックします。

23. 左ペインで「サービス」>「メッセージング」>「JMSモジュール」ノードを再選択します。

24. 右ペインに作成されたJMSモジュール名を選択します。

25. 「新規」をクリックし、別のJMSリソースを作成します。

26. 「分散キュー」オプションを選択し、「次へ」をクリックします。

27. DistributedQueue-Callstateなどの、リソースの説明的な名前を入力することによって、「新しいJMSシステム・モジュール・リソースの作成」の「名前」フィールドを記入します。

28. JNDI名:次に示すように「新しいJMSシステム・モジュール・リソースの作成」フィールドに「塗りつぶし」を入力します。

- 名前:ConnectionFactory-Callstateなどの、リソースの説明的な名前を入力します。

- JNDI名:wlss.callstate.backup.site.queueという名前を入力します。

29. 「次へ」をクリックして続行します。

30. 「終了」をクリックして、新しいリソースを作成します。

31. 「保存」をクリックし、構成の変更を保存します。

32. 「変更のアクティブ化」をクリックし、変更をエンジン層サーバーに適用します。

4.6.6 地理的に冗長なレプリケーション動作の理解

この項では、複数のサイトが呼出し状態データをレプリケートする仕組みの詳細を説明します。管理者は、この情報を使用して地理的に冗長なレプリケーションのメカニズムをより深く理解し、そのような構成で生じる問題に対してより適切にトラブルシューティングを実行できます。ただし、Oracle WebLogic Server SIP Containerインストール全体の内部レプリケーション機構は、今後の製品リリースによって変更される可能性があります。

4.6.6.1 呼出し状態レプリケーション・プロセス

プライマリOracle WebLogic Server SIP Containerサイトで呼出しが発信されると、通常は呼出し設定および処理が発生します。SIPダイアログ境界に到達すると、呼出しはサイトのSIPデータ層にレプリケートされ(メモリー内)、セカンダリ・サイトへのレプリケーション対象になります。Oracle WebLogic Server SIP Containerは、ネットワーク使用率を最適化するために、レプリケーションの複数の呼出し状態を集計することを選択する場合があります。

次に、SIPデータ層の単一レプリカは、レプリカ・サイトで構成されたJMSキューでレプリケートされるように呼出し状態データを配置します。データは、ラウンドロビン方式で使用可能なエンジン(sipserver.xmlのgeo-remote-t3-url要素で指定される)のいずれかへ送信されます。セカンダリ・サイトのエンジンは、新規メッセージのローカル・キューを監視します。

メッセージを取得すると、セカンダリ・サイトのエンジンは呼出し状態データを永続性し、それをプライマリ・サイトのサイトID値に割り当てます。サイトIDはセカンダリ・サイトでレプリケートされた呼出し状態データをセカンダリ・サイトで管理されるその他すべての呼出し状態データから区別します。レプリケートされた呼出し状態データのタイマーはセカンダリ・サイトで休止状態を続けるので、タイマー処理が動作の妨げになることはありません。

4.6.6.2 フェイルオーバー後の呼出し状態の処理

フェイルオーバーを実行するには、管理者はグローバルなロード・バランサ・ポリシーを変更して障害が発生したプライマリ・サイトからセカンダリ・サイトへの呼出しのルーティングを始める必要があります。この処理を終了したあとで、セカンダリ・サイトはバックアップされた呼出し状態データのリクエスト処理を始めます。障害が発生したサイトからレプリケートしたデータへのリクエストが行われると、エンジンはデータを取得し、呼出しのオーナーシップを取得して呼出し状態を起動します。起動処理には以下の動作が含まれます。

- 呼出しに関連するサイトIDをゼロに設定します(ローカルに指定します)。

- 呼出し状態に存在するすべての休止タイマーを起動します。

デフォルトでは、呼出し状態は各呼出しに対してのみ、バックアップ・サイトでリクエストされる呼出しの後でのみアクティブ化されます。SipServerRuntimeMBeanには、activateBackup(byte site)というメソッドが含まれ、サイトに対して別のサイトからレプリケートしたすべての呼出し状態データを強制的に引き継ぐようにするために使用できます。管理者は、WLST構成スクリプトを使用してこのメソッドを実行できます。あるいは、サーバー上にデプロイされたアプリケーションは、レプリケートされたサイト・データへのリクエストがいつ発生したかを検出し、メソッドを実行できます。例4-7は、サイト1からレプリケートされたすべての呼出し状態データの所有権を変更し、セカンダリ・サイトをアクティブ化するJSPからのサンプル・コードを示します。同様のコードは、デプロイされたサーブレット内で使用可能です。JSPまたはサーブレットのいずれかは、activateBackupメソッドを実行するために、権限ユーザーとして実行される必要があります。

特定の呼出し状態リクエストかどうかを判定するために、サーブレットはWlssSipApplicationSession.getGeoSiteId()メソッドを使用して呼出しに関連付けられたサイトIDを確認できます。サイトIDのゼロ以外の値は、サーブレットが別のサイトからレプリケートされた呼出し状態データを使用して機能することを示します。

例4-7 JMXを使用したセカンダリ・サイトのアクティブ化

<%
byte site = 1;

InitialContext ctx = new InitialContext();
MBeanServer server = (MBeanServer) ctx.lookup("java:comp/env/jmx/runtime");
Set set = server.queryMBeans(new ObjectName("*:*,Type=SipServerRuntime"), null);
if (set.size() == 0) {
throw new IllegalStateException("No MBeans Found!!!");
}

ObjectInstance oi = (ObjectInstance) set.iterator().next();
SipServerRuntimeMBean bean = (SipServerRuntimeMBean)
MBeanServerInvocationHandler.newProxyInstance(server,
oi.getObjectName());

bean.activateBackup(site);
%>

フェイルオーバーの後、ロード・バランサは、新しく起動されたサイトに同じcallIdを持つすべての呼出しをルートしなければならないことに注意してください。障害が発生した元のサイトをサービスに復元しても、ロード・バランサは2つの地理的なサイトの間で呼出しを分割しないことが必要です。

4.6.7 呼出し状態のバックアップの削除

リモート・サイト上でメンテナンスを実行したり、バックアップ・サイト全体を変更したりするために、呼出し状態をリモート・サイトへレプリケートすることを停止するように選択することもできます。レプリケーションは、4.6.5.2項「永続性オプションの構成(プライマリおよびセカンダリ・サイト)」で説明されているように、プライマリ・サイトでSite Handling属性を"none"に設定することによって停止できます。

プライマリ・サイトで地理的なレプリケーションを無効化した後、セカンダリ・サイトで呼出し状態のバックアップを削除することもできます。SipServerRuntimeMBeanには、deleteBackup(byte site)というメソッドが含まれ、サイトに対して別のサイトからレプリケートしたすべての呼出し状態データを強制的に削除するために使用できます。管理者は、WLST構成スクリプトを使用するか、またはセカンダリ・サイトでデプロイ済アプリケーションを経由して、このメソッドを実行できます。このメソッドを実行するための手順は、4.6.6.2項「フェイルオーバー後の呼出し状態の処理」で説明されているように、activateBackupメソッドの使用による手順と酷似しています。

4.6.8 地域サイト全体に渡るレプリケーションの監視

ReplicaRuntimeMBeanには、地理的に冗長なレプリケーションに関するデータを取得するための2つの新しいメソッドが含まれています。

- getBackupStoreOutboundStatistics()は、セカンダリ・サイトのJMSキューに格納される呼出しの数に関する情報を提供します。

- getBackupStoreInboundStatistics()は、セカンダリ・サイトが別のサイトからレプリケートする呼出し状態データに関する情報を提供します。

ReplicaRuntimeMBeanに関する詳細は、Oracle Fusion Middleware Communication Services Java APIリファレンスを参照してください。

4.6.9 地理的レプリケーションのトラブルシューティング

4.6.8項「地域サイト全体に渡るレプリケーションの監視」で説明されているReplicaRuntimeMBeanメソッドの使用に加え、管理者は、セカンダリ・サイト・インストール上でデータベースの書込みに失敗したことを示すSNMPトラップを監視する必要があります。

管理者は地理的に冗長な構成に属しているすべてのサイトが固有のサイトIDを使用しているか確認する必要があります。

4.7 エンジン層におけるSIPデータのキャッシュ

第7章「Oracle WebLogic Server SIP Containerベース・プラットホームのトポロジ」で説明されているように、デフォルトのOracle WebLogic Server SIP Container構成では、エンジン層クラスタはステートレスです。個別のSIPデータ層クラスタが1つ以上のパーティションで呼出し状態データを管理し、エンジン層サーバーが必要に応じてSIPデータ層のデータを取得して書き込みます。エンジンは、呼出し状態データを各パーティションの複数のレプリカに書き込み、SIPデータ層レプリカがオフライン状態に陥ったときに自動フェイルオーバーを実行できます。

また、Oracle WebLogic Server SIP Containerは、エンジン層サーバーが呼出し状態データの一部をローカルおよびSIPデータ層にキャッシュするためのオプションも提供します。ローカル・キャッシュが使用されるとき、エンジン層サーバーはまず既存の呼出し状態データのローカル・キャッシュをチェックします。キャッシュに必要なデータが含まれ、データのローカル・コピーが(SIPデータ層コピーに比べて)最新の場合、エンジンはSIPデータ層の呼出し状態をロックしますが、そのキャッシュから直接読み取ります。これによって、エンジンはSIPデータ層サーバーから呼出し状態データを取得する必要がないため、リクエストに対するレスポンス時間のパフォーマンスが向上します。

エンジン層キャッシュは、エンジン層サーバーによって最近使用された呼出し状態データのみ保存します。呼出し状態データは、クライアント・リクエストに応答したり、古いデータをリフレッシュしたりするために、必要に応じてエンジンのローカル・キャッシュに移動されます。新しい呼出し状態がキャッシュに書き込まれる必要があるときにキャッシュがいっぱいの場合は、最も長い期間アクセスされていない呼出し状態エントリが最初にキャッシュから削除されます。エンジン層キャッシュのサイズは構成できません。

SIP対応ロード・バランサがエンジン層クラスタにリクエストを管理する場合は、ローカル・キャッシュの使用が最も有利です。SIP対応ロード・バランサでは、確立された呼出しに対するリクエストはすべて同じエンジン層サーバーに転送され、キャッシュの有効性を改善します。同じ呼出しに次のリクエストが(様々なキャッシュ・コンテンツを持つ)別のエンジン層サーバーから分散されるため、SIP対応ロード・バランサを使用しないとキャッシュの有効性が限定されます。

4.7.1 エンジン層キャッシュの構成

エンジン層キャッシュはデフォルトで有効化されています。エンジン層で呼出し状態データの部分キャッシュを無効化するには、sipserver.xmlでengine-call-state-cache-enabled要素を指定します。

<engine-call-state-cache-enabled>false</engine-call-state-cache-enabled>

使用可能になると、キャッシュ・サイズは呼出し状態250回で固定されます。エンジン層キャッシュのサイズは構成不可です。

4.7.2 キャッシュ・パフォーマンスの監視およびチューニング

SipPerformanceRuntimeは、エンジン層キャッシュの動作を監視します。表4-3は、MBean属性を説明しています。

表4-3 SipPerformanceRuntime属性の概要

属性

説明

cacheRequests

セッション・データ項目のリクエスト数を追跡します。

cacheHits

サーバーは、セッション・データのリクエストが、エンジン層サーバーのローカル・キャッシュで検出されるデータのバージョンという結果になるたびに、この属性をインクリメントします。このカウンタは、キャッシュされたデータが古く、SIPデータ層からのデータを使用して更新される必要がある場合でもインクリメントされます。

cacheValidHits

この属性は、セッション・データのリクエストがデータのキャッシュ・バージョンで完全に満たされるごとにインクリメントされます。

有効化すると、キャッシュのサイズは250の呼出し状態に固定されます。キャッシュはメモリーを消費するため、パフォーマンスの目標を満たすためには、エンジン層サーバーの稼働に使用されるJVM設定を更新する必要がある場合があります。キャッシュされた呼出し状態は、ガベージ・コレクタの古い保存域に保持されます。キャッシュが有効化されているときは、「NewSize」の固定値を減らすようにします(-XX:MaxNewSize=32m -XX:NewSize=32mなど)。実際の値は、アプリケーションによって使用される呼出し状態のサイズおよびアプリケーション自体のサイズに依存します。

4.8 SIPデータ層サーバーの監視およびトラブルシューティング

ランタイムMBean (ReplicaRuntimeMBean)は、SIPデータ層の現在の状態および構成に関する貴重な情報を提供します。MBeanで提供される属性に関する説明は、Oracle Fusion Middleware Communication Services Java APIリファレンスを参照してください。

これらの属性の多くは、図4-6で示されるように、管理コンソールのSIPサーバーの監視>「データ層の情報」タブを使用して表示できます。

図4-6 管理コンソールでのSIPデータ層のモニター

「図4-6 管理コンソールにおけるSIPデータ層の監視」の説明

例4-8は、SIPデータ層パーティションにおける単一の管理対象サーバー・インスタンスの現在の属性を問い合せる単一のWLSTセッションを示します。表4-1は、MBeanサービスの詳細を説明しています。

例4-8 ReplicaRuntimeMBean属性の表示

connect('weblogic','weblogic','t3://datahost1:7001')
custom()
cd('com.bea')
cd('com.bea:ServerRuntime=replica1,Name=replica1,Type=ReplicaRuntime')
ls()
-rw-   BackupStoreInboundStatistics                 null
-rw-   BackupStoreOutboundStatistics                null
-rw-   BytesReceived                                0
-rw-   BytesSent                                    0
-rw-   CurrentViewId                                2
-rw-   DataItemCount                                0
-rw-   DataItemsToRecover                           0
-rw-   DatabaseStoreStatistics                      null
-rw-   HighKeyCount                                 0
-rw-   HighTotalBytes                               0
-rw-   KeyCount                                     0
-rw-   Name                                         replica1
-rw-   Parent                                       com.bea:Name=replica1,Type=S
erverRuntime
-rw-   PartitionId                                  0
-rw-   PartitionName                                part-1
-rw-   ReplicaId                                    0
-rw-   ReplicaName                                  replica1
-rw-   ReplicaServersInCurrentView                  java.lang.String[replica1, replica2]
-rw-   ReplicasInCurrentView                        [I@75378c
-rw-   State                                        ONLINE
-rw-   TimerQueueSize                               0
-rw-   TotalBytes                                   0
-rw-   Type                                         ReplicaRuntime

表4-4 ReplicaRuntimeMBeanメソッドおよび属性サマリー

メソッド/属性

説明

dumpState()

選択したSIPデータ層サーバー・インスタンスの全体の状態をOracle WebLogic Server SIP Containerのログ・ファイルに記録します。問題が発生した場合に追加の診断情報をテクニカル・サポート担当者に提供するためには、dumpState()メソッドを使用します。

BackupStoreInboundStatistics

遠隔地の地理的サイトからレプリケーションされた呼出し状態データに関する統計を提供します。

BackupStoreOutboundStatistics

遠隔地の地理的サイトにレプリケーションされた呼出し状態データに関する統計を提供します。

BytesReceived

このSIPデータ層サーバーが受信した総バイト数です。バイト・データを受信するのは、格納する呼出し状態データがエンジン層のサーバーから渡されたときです。

BytesSent

このSIPデータ層サーバーが送信した総バイト数です。バイト・データをエンジン層サーバーに送信するのは、格納された呼出し状態データを提供するようリクエストされたときです。

CurrentViewId

現在のビューID。SIPデータ層のレイアウトが変更になるたびに、ビューIDはインクリメントされます。たとえば、SIPデータ層クラスタの複数サーバーが最初に起動されるときには、各サーバーがSIPデータ層に加わった時点でビューIDがインクリメントされます。同様に、意図的または障害によってSIPデータ層からサーバーが抜けたときにも、ビューIDはインクリメントされます。

DataItemCount

保存された呼出し状態キーの合計数で、このサーバーはこのキーのデータを保持しています。この属性は、サーバーが現在データをリカバリ中の場合、KeyCount属性よりも小さくなる場合があります。

DataItemsToRecover

パーティション内の他のレプリカから回復する必要がある呼出し状態キーの総数です。SIPデータ層サーバーは、保守のためにオフラインにした後で、再起動してパーティションに参加したときに、必要に応じてキーを回復します。

HighKeyCount

このサーバーで起動以降に処理した呼出し状態キーの総数の最大値です。

HighTotalBytes

このサーバーで起動以降に処理した呼出し状態データの総バイト数の最大値です。

KeyCount

レプリカに格納されている呼出しデータ・キーの数です。

PartitionId

このサーバーのパーティションの数値的なパーティションID (0から7)。

PartitionName

このサーバーのパーティション名。

ReplicaId

このサーバーのレプリカの数値的なレプリカID (0から2)。

ReplicaName

このサーバーのレプリカ名。

ReplicaServersInCurrentView

パーティションに参加している他のOracle WebLogic Server SIP Containerインスタンス名。

State

レプリカの現在の状態です。SIPデータ層サーバーが取り得るステータスは、次の3つのいずれかです。

- ONLINE: サーバーが呼出し状態トランザクションの管理に使用可能であることを示します。

- OFFLINE: サーバーがシャットダウンしているか、使用不可能であることを示します。

- ONLINE_LOCK_AUTHORITY_ONLY: サーバーが再起動され、現在の呼出し状態データを使用して(他のレプリカから)現在更新中であることを示します。リカバリ中のサーバーは、パーティションによって管理される呼出し状態のフル・コピーを保持しないため、呼出し状態トランザクションをまだ処理できません。

TimerQueueSize

SIPデータ層サーバーにキューイングされたタイマーの現在の数です。通常はKeyCount値に一致しますが、追加された新しい呼出し状態に対応するタイマーがまだキューイングされていない場合には、この値の方が小さいこともあります。

注意: エンジン層サーバーは、呼出しに関連付けられたタイマーが期限切れになったかどうかを判定するために、SIPデータ層インスタンスを定期的にチェックします。SIPタイマーが正常に機能するためには、すべてのエンジン層サーバーがシステム・クロックを共通時間ソースにアクティブに同期化する必要があります。各エンジン層インスタンスでネットワーク・タイム・プロトコル(NTP)クライアントまたはデーモンを使用し、選択したNTPサーバーに同期することをお薦めします。詳細は、2.5項「タイマー処理の構成」を参照してください。

TotalBytes

このサーバーで扱った呼出し状態によって消費された総バイト数です。

5 監視およびトラブルシューティング

次の項では、サーバーがネットワークから物理的に切断されたときに、SIPデータ層のフェイルオーバー・パフォーマンスを向上するために、Oracle WebLogic Server SIP Containerの「エコー・サーバー」処理の使用を構成する方法を説明します。

- 5.1項「サーバー障害の回避およびリカバリ」

- 5.2項「フェイルオーバー検出の概要」

- 5.3項「物理的なネットワーク障害時のフェイルオーバー・パフォーマンスの向上」

- 5.4項「SNMPの構成」

- 5.5項「SNMPトラップの理解および応答」

- 5.6項「WebLogic診断フレームワーク(WLDF)の使用」

- 5.7項「SIPリクエストおよびレスポンスのロギング」

- 5.8項「本番デプロイメント時のJVMガベージ・コレクションのチューニング」

- 5.9項「乱数生成によって発生するJVM遅延の回避」

5.1 サーバー障害の回避およびリカバリ

サーバー・インスタンスの障害は、さまざまな出来事によって引き起こされます。1つの障害が別の障害のきっかけになることも少なくありません。停電、ハードウェアの故障、オペレーティング・システムのクラッシュ、ネットワーク・パーティション、アプリケーションの予期しない動作は、いずれもサーバー・インスタンスの障害の一因になり得ます。

Oracle WebLogic Server SIP Containerは、障害イベントの影響を最小化するための基礎として、高度にクラスタリングされたアーキテクチャを使用します。ただし、クラスタリングした環境でも、各サーバーまたはサーバー・マシンで障害が発生するイベントにおいて正常なリカバリ処理を準備することは重要となります。

次の項では、Oracle WebLogic Server SIP Containerの障害を保護する機能およびリカバリする機能についてまとめており、Oracle WebLogic Server SIP Containerドメインの各部をリストアするために必要な構成アーティファクトを説明しています。

5.1.1 障害の保護および自動リカバリ機能

Oracle WebLogic Server SIP Containerおよび基礎となるWebLogic Serverプラットホームによって、サーバー障害に対する多数の保護機能が提供されます。本番システムでは、無中断のサービスを保証するためにすべての使用可能な機能が使用されます。

5.1.1.1 過負荷保護

Oracle WebLogic Server SIP Containerは、デプロイ済SIPサーブレットのパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出し、あらかじめ定義された負荷のしきい値に達するとメッセージの処理を自動的に規制します。

過負荷保護を使用すると、予期しないレベルのアプリケーション・トラフィックやリソース使用率が原因で発生する障害を回避することができます。

Oracle WebLogic Server SIP Containerは、特定の条件が発生したとき、障害の回避を試みます:

- SIPセッションの作成レートが構成された値に到達するか、または

- SIPタイマーおよびSIPリクエスト処理実行キューのサイズが構成された値に到達した。

基盤となるWebLogic Serverプラットフォームは、デプロイ済アプリケーションのパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出します。WebLogic Serverではあらかじめ定義されたロードのしきい値で自動的に発生する障害回避アクションの構成を管理者に許可します。自動過負荷保護は、次によって示される、予期しないレベルのアプリケーション・トラフィックやリソース使用が原因で発生する障害を回避するのに役立ちます:

- 超過しつつあるワークロード・マネージャのキャパシティ

- 事前定義されたしきい値まで増大しているHTTPセッション数

- 差し迫ったメモリー不足状態

5.1.1.2 クラスタリングされたサービスの冗長性およびフェイルオーバー

専用SIPデータ層クラスタ内の複数のSIPデータ層サーバー(レプリカ)とともに、専用クラス内の複数のエンジン層サーバーを使用することによって、アプリケーションの信頼性と可用性を向上できます。エンジン層クラスタはSIPダイアログ(呼出し)に関するステートフルな情報を保持しないので、エンジン層サーバーの障害によってデータ損失や呼出しの喪失が生じることはありません。SIPデータ層パーティション内の複数のレプリカは、呼出し状態情報の冗長なコピーを保存し、レプリカが失敗した場合は自動的に相互にフェイルオーバーを行います。

5.1.1.3 障害が発生したサーバー・インスタンスの自動再起動

WebLogic Serverの自己ヘルス監視機能は、ドメイン内のサーバー・インスタンスの信頼性および可用性を向上させます。各サーバー・インスタンス内の選択されたサブシステムは、サブシステム固有の基準に基づいてヘルス状態を監視します。(たとえば、JMSサブシステムは、コア・サーバーのサブシステムがデフォルトおよびユーザー定義の実行キュー統計を監視する間に、JMSスレッド・プールの条件を監視します)各サブシステムは、一貫性のある信頼できる方法でもう稼働できないと判定される場合、ホスト・サーバーにヘルス・ステータスを「失敗」として登録します。

次に各WebLogic Serverインスタンスは、全体的に稼働が可能であるか判断するために、登録されたサブシステムの状態をチェックします。1つまたは複数のクリティカルのサブシステムがFAILED状態に達した場合、サーバー・インスタンスはアプリケーションを確実にホストできないことを示すためにそれ自体の状態をFAILEDにマークします。

ノード・マネージャと組み合せて使用されるとき、サーバーの自己ヘルス監視によって、自動的に障害が発生したサーバーを再起動することができるようになります。これによって、ドメインの全体の信頼性が向上し、管理者からの直接介入が必要なくなります。

5.1.1.4 管理対象サーバーの独立モード

管理対象サーバーは、ドメイン構成のローカル・コピーを保持します。管理対象サーバーは起動時に、管理対象サーバーが最後にシャットダウンされてから行われたドメイン構成に対する変更を取得するために、管理サーバーに接続します。管理対象サーバーが起動中に管理サーバーに接続できない場合、ローカルにキャッシュされた構成情報を使用できます。この情報は、管理対象サーバーが最後にシャットダウンされたときの構成です。構成の更新をチェックするために管理サーバーに接続せずに起動する管理対象サーバーは、管理対象サーバーの独立(MSI)モードで稼働しています。デフォルトでは、MSIモードは有効化されています。

5.1.1.5 障害が発生した管理対象サーバーの自動移行

LinuxまたはUNIXオペレーティング・システムを使用するとき、WebLogic Serverのサーバー移行機能を使用すると、ネットワーク層サーバーのマシンで障害が発生する場合またはネットワークからパーティション化されている場合に、候補(バックアップ)サーバーを自動的に起動できます。サーバー移行機能は、wlsifconfig.shスクリプトとともにノード・マネージャを使用し、フローティングIPアドレスを使用して候補サーバーを自動的に起動できます。候補サーバーは、ネットワーク層インスタンスをホストしているプライマリ・サーバーがアクセスできなくなる場合にのみ、起動されます。サーバー移行機能の使用の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のサーバー全体の移行に関する項を参照してください。

5.1.1.6 地域サイト障害時の地理的冗長性

サーバー・レベルの冗長性およびフェイルオーバー機能に加えて、Oracle WebLogic Server SIP Containerを使用すると、ドメイン全体に影響を与える可能性がある、停電などの致命的な障害に対して保護するためにピア・サイトを構成できます。これによって、完全なサービス停止を避け、1つの地理的サイトから別のサイトへフェイルオーバーを実行できるようになります。

5.1.2 障害リカバリ用のディレクトリおよびファイルのバックアップ

サーバー・インスタンスの障害からのリカバリでは、ドメインの構成データにアクセスする必要があります。デフォルトでは、管理サーバーはdomain_name/config/config.xmlと呼ばれるファイルにドメインのプライマリ構成データを保存します。ここで、domain_nameはドメインのルート・ディレクトリです。プライマリ構成ファイルは、JDBCやJMSなどの固有のWebLogic Serverサービスの追加構成ファイルや、SIPコンテナ・プロパティやSIPデータ層構成などのOracle WebLogic Server SIP Containerサービスの追加構成ファイルを参照できます。固有のサービスの構成は、Oracle WebLogic Server SIP Container構成ファイルのdomain_name/config/jms、domain_name/config/jdbc、およびdomain_name/config/customなどの、domain_name/configディレクトリのサブディレクトリ内にある追加XMLファイルに保存されます。

管理サーバーは、ドメイン構成(domain-name/configディレクトリ全体)の複数バージョンを自動的にアーカイブできます。構成アーカイブは、間違って変更した構成を元に戻す必要がある場合に、システムをリストアするために使用されます。たとえば、管理者が構成されたリソースを間違って削除した場合、最新の自動バックアップを使用して以前の構成をリストアできます。

管理サーバーは、有限の数の自動バックアップのみをローカルでdomain_name/configに保存します。このため、自動ドメイン・バックアップは、ハードディスク障害などのデータ破損に対する保護機能に限定されます。また、自動バックアップは、LDAPリポジトリ・データやサーバー起動スクリプトなどのフル・ドメイン・リストアに必要な特定の構成データも保存しません。ソース制御システムで、構成およびセキュリティ・オフラインの複数のバックアップ・コピーも保持することをお薦めします。

この項では、Oracle WebLogic Server SIP Containerが自動的に実行するファイル・バックアップ、および管理者が定期的に実行する必要がある手動バックアップ処理を説明しています。

5.1.2.1 自動構成バックアップの有効化

ドメインの管理サーバー上で、自動ドメイン構成バックアップを有効するには、次の手順に従います。

1. ドメインの管理コンソールにアクセスします。

2. 管理コンソールの左ペインで、ドメイン名を選択します。

3. 右ペインで、「構成」>「全般」タブをクリックします。

4. 「詳細設定」を選択し、詳細オプションを表示します。

5. 「構成アーカイブの有効化」を選択します。

6. 「アーカイブ構成数」ボックスに、保存する構成ファイル・リビジョンの最大数を入力します。

7. 「保存」をクリックします。

構成のアーカイブを有効化すると、管理サーバーは自動的に構成JARファイル・アーカイブを作成します。JARファイルには、以前の構成の完全なコピー(domain-name\configディレクトリの完全コンテンツ)が含まれます。JARファイルのアーカイブ・ファイルは、domain-name\configArchiveディレクトリに保存されます。これらのファイルは、config-number.jarというネーミング・ルールを使用します。ここで、numberはアーカイブの連続番号です。

ドメインの構成への変更を保存するとき、管理サーバーは以前の構成をdomain-name\configArchive\config.xml#nに保存します。管理サーバーは、configArchiveディレクトリにファイルを保存するたびに、#n接尾辞の値を構成可能なコピー数(デフォルトは5)まで増加させます。その後、ドメイン構成を変更するたびに、次のような処理が行われます。

- アーカイブ済のファイルが循環し、最新のファイルに最も大きい番号のサフィックスが付けられます。

- 以前にアーカイブされたファイルの名前に付いた番号は1つずつ小さくなります。

- 最も古いファイルが削除されます。

構成アーカイブはドメイン・ディレクトリ内にローカルで保存され、選択したリビジョンの最大数に従ってオーバーライドされる可能性があることを覚えておいてください。このため、5.1.2.2項「ドメイン構成オフラインの保存」で説明されているように、独自のドメイン構成のオフライン・アーカイブも作成する必要があります。

5.1.2.2 ドメイン構成オフラインの保存

自動バックアップにより偶発的な構成への変更は防止できますが、ドメイン構成を格納するハード・ディスクの障害によって発生するデータ損失やドメイン・ディレクトリの偶発的削除は防げません。これらの障害から保護するには、できればソース・コントロール・システムでドメイン構成オフライン全体のコピーを格納する必要があります。

定期的にドメイン構成のコピーを保存することをお薦めます。たとえば、次の場合には、構成の最新の改訂をバックアップします。

- 本番システムを最初にデプロイした場合

- デプロイされたアプリケーションを追加または除去した場合

- 構成をパフォーマンスを向上させるためにチューニングした場合

- その他の恒久的変更を行った場合

ドメイン構成バックアップには、domain_name/configディレクトリの完全なコンテンツが含まれる必要があります。例:

cd ~/user_projects/domains/mydomain
tar cvf domain-backup-06-17-2007.jar config

ソース・コントロール・システムで新しいアーカイブを格納する場合、過去のある時点のドメイン構成を回復するために必要な以前のバージョンを保存します。

5.1.2.3 サーバー起動スクリプトのバックアップ

Oracle WebLogic Server SIP Containerデプロイメントでは、エンジンおよびSIPデータ層サーバーの起動に使用される起動スクリプトは、通常、次のようなドメイン固有の構成情報を含むようにカスタマイズされます。

- JVMガベージ・コレクション・パラメータは、SIPメッセージ処理のスループット・ターゲットを達成するために必要になります(5.8項「本番デプロイメントときのJVMガベージ・コレクションのチューニング」を参照)。異なるパラメータ(および、そのために異なる起動スクリプト)は、通常、エンジンおよびSIPデータ層サーバーの起動に使用されます。

- Oracle WebLogic Server SIP Containerハートビート・メカニズムの構成パラメータおよび起動情報。ハートビート・メカニズムを使用する場合、エンジン層サーバーの起動スクリプトには、ハートビート・メカニズムを有効化して構成するための起動オプションが含まれる必要があります。SIPデータ層サーバーの起動スクリプトには、ハートビートを有効化してWlssEchoServerプロセスを開始するための起動オプションが含まれる必要があります。

ドメイン内のエンジン層サーバー、SIPデータ層サーバー、またはDiameterリレー・サーバーの起動に使われる個別の起動スクリプトをバックアップします。

5.1.2.4 ロギング・サーブレット・アプリケーションのバックアップ

SIPメッセージの定期的なロギングまたは監査を実行するためにOracle WebLogic Server SIP Containerロギング・サーブレット(5.7項「SIPリクエストおよびレスポンスのロギング」を参照)を使用する場合、ステージング・サーバーで障害が発生したり元のデプロイメント・ディレクトリが破損したりする場合でも容易にアプリケーションを再デプロイできるように、完全なアプリケーション・ソース・ファイルをバックアップしてください。

5.1.2.5 セキュリティ・データのバックアップ

WebLogicセキュリティ・サービスは、構成データのconfig.xmlファイルをLDAPリポジトリや他のファイルにも保存します。

5.1.2.5.1 SerializedSystemIni.datおよびセキュリティ証明書のバックアップ

すべてのサーバーは、SerializedSystemIni.datという名前のファイルを作成し、それをサーバーのルート・ディレクトリに配置します。このファイルには、サーバーを起動するために必要な暗号化されたセキュリティ・データが含まれます。このファイルをバックアップする必要があります。

サーバーでSSLを使用する場合は、セキュリティ証明書とキーもバックアップします。これらのファイルの場所はユーザーが構成できます。

5.1.2.5.2 WebLogic LDAPリポジトリのバックアップ

Oracle WebLogic Server SIP Containerにインストールされるデフォルトの認証、認可、ロール・マッパー、および資格証明マッパーは、それらのデータをLDAPサーバーに保存します。それぞれのOracle WebLogic Server SIP Containerには、組込みLDAPサーバーが含まれます。管理サーバーにはマスターLDAPサーバーが含まれ、すべての管理対象サーバー上でレプリケートされます。任意のセキュリティ・レルムがこれらのインストールされたプロバイダを使用する場合、次のディレクトリ・ツリーの最新バックアップを保持する必要があります。

domain_name\adminServer\ldap

ここで、domain_nameはドメインのルート・ディレクトリで、adminServerは管理サーバーがランタイム・データおよびセキュリティ・データを保存するディレクトリです。

それぞれのOracle WebLogic Server SIP ContainerにはLDAPディレクトリが含まれますが、管理サーバー上のLDAPデータのみバックアップする必要があります。ここで、マスターLDAPサーバーは、セキュリティ・データの更新時に各管理対象サーバーのLDAPデータをレプリケートします。WebLogicセキュリティ・プロバイダは、ドメインの管理サーバーが使用できない間は、セキュリティ・データを変更できません。各管理対象サーバーのLDAPリポジトリはレプリカなので変更できません。

ldap/ldapfilesサブディレクトリには、LDAPサーバーのデータ・ファイルが含まれます。このディレクトリのファイルには、ユーザー、グループ、グループ・メンバーシップ、ポリシー、およびロール情報が含まれます。ldapの他のサブディレクトリには、レプリケートされたLDAPサーバーに関するLDAPサーバー・メッセージ・ログおよびデータが含まれます。

LDAPデータのバックアップ中はセキュリティ・プロバイダの構成を更新しないでください。ldapディレクトリ・ツリーのバックアップ中に変更が行われた場合(たとえば、管理者がユーザーを追加する場合)、ldapfilesサブディレクトリ内のバックアップは一致しなくなる可能性があります。これが起こった場合、内容が一致しても古い可能性があるLDAPデータのバックアップを使用できます。

1日に1回、サーバーは書込み操作を一時停止してLDAPデータの独自バックアップを作成します。このバックアップをldap\backupディレクトリのZIPファイルにアーカイブ化した後、書込み操作を再開します。このバックアップは、内容が一致することが保証されていますが、最新のセキュリティ・データを含んでいない可能性があります。

5.1.2.6 追加のオペレーティング・システム構成ファイルのバックアップ

オペレーティング・システム・レベルで保持される特定のファイルも、システム障害からの回復において非常に重要な役割を果たします。システムの必要に応じて、以下の情報をバックアップすることを検討してください。

- ロード・バランサの構成スクリプト。たとえば、エンジン層クラスタのロード・バランサ・プールと仮想IPアドレス、およびNAT構成の設定を構成するために使われる自動化スクリプト。

- エンジン層サーバーとSIPデータ層サーバーのシステム時計を同期するために使用されるNTPクライアントの構成スクリプト。

- それぞれのOracle WebLogic Server SIP Containerマシンのホスト構成ファイル(ホスト名、マルチ・ホーム・マシンの仮想/実際のIPアドレス、IPルーティング表情報)。

5.1.3 障害が発生した管理サーバーの再起動

障害が発生した管理サーバーを再起動するときに、特別な手順に従う必要はありません。通常どおりの方法で管理サーバーを起動してください。

管理対象サーバーの実行中に管理サーバーが停止した場合、ドメインの管理を回復するために、実行されている管理対象サーバーを再起動する必要はありません。アクティブなドメインの管理を回復する手順は、ドメインの開始時に実行されていたのと同じマシンで管理サーバーを再起動できるかどうかによって異なります。

5.1.3.1 同じマシンにおける管理サーバーの再起動

管理対象サーバーの実行中にWebLogic管理サーバーを再起動した場合、デフォルトでは、管理サーバーは実行中の管理対象サーバーの存在を検出することができます。

注意:
起動コマンドまたは起動スクリプトに-Dweblogic.management.discover=falseが含まれていないことを確認してください。これが含まれていると、管理サーバーは稼働中の管理対象サーバーを検出できません。

ドメインのルート・ディレクトリには、running-managed-servers.xmlというファイルが含まれています。このファイルには、ドメイン内の管理対象サーバーのリストがあり、稼働中かどうかが記述されています。管理サーバーが再起動するとき、稼働を呈する前にどの管理対象サーバーが制御下にあるかを判定するためにこのファイルをチェックします。

管理対象サーバーが正常または強制的にシャットダウンされるとき、running-managed-servers.xmlにおけるそのステータスは「非稼働中」に更新されます。管理サーバーが再起動するとき、「非稼働中」ステータスの管理対象サーバーを検出しようとしません。システム・クラッシュのために稼働を停止する管理対象サーバーや、実行中のJVMまたはコマンド・プロンプト(シェル)を停止することによって停止される管理対象サーバーでは、running-managed-servers.xmlにおけるステータスは「稼働中」のままになります。管理サーバーはそれらを検出しようと試行し、管理対象サーバーがもう稼働していないと判定するとき例外を表示します。

管理サーバーを再起動すると、管理対象サーバーが静的な属性の構成を更新しません。静的な属性とは、起動プロセス中にのみサーバーが参照する属性です。サーバー・インスタンスは、静的な構成属性に対する変更を考慮して再起動される必要があります。管理対象サーバーの検出によって、管理サーバーは管理対象サーバーの監視またはサーバーの稼働中(動的な属性)に構成可能な属性におけるランタイム変更のみ可能になります。

5.1.3.2 別のマシンにおける管理サーバーの再起動

マシンのクラッシュにより、同じマシンで管理サーバーを再起動できない場合は、次のようにして実行中の管理対象サーバーの管理を回復できます。

1. Oracle WebLogic Server SIP Containerソフトウェアを新しい管理マシンにインストールしてください(未インストールの場合)。

2. アプリケーション・ファイルをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバーがこれらのファイルを使用できるようにします。新しいファイル・システム上でのアプリケーション・ファイルの相対位置は、元の管理サーバーのファイル・システムと同じにする必要があります。

3. バックアップからコピーするか、または共有ディスクを使用することによって、構成データおよびセキュリティ・データを新しい管理マシンで使用可能にします。詳細は、5.1.2.2項「ドメイン構成オフラインの保存」および5.1.2.5項「セキュリティ・データのバックアップ」を参照してください。

4. 新しいマシンで管理サーバーを再起動します。
起動コマンドまたは起動スクリプトに-Dweblogic.management.discover=falseが含まれていないことを確認してください。これが含まれていると、管理サーバーは稼働中の管理対象サーバーを検出できません。

管理サーバーは、起動時に管理対象サーバーと通信して、管理サーバーが異なるIPアドレスで動作していることを通知します。

5.1.4 障害が発生した管理対象サーバーの再起動

障害が発生した管理対象サーバーが稼働するマシンがドメインの管理サーバーにアクセスできる場合、ノード・マネージャを使用して管理対象サーバーを手動または自動で再起動します。自動再起動をサポートするように、ノード・マネージャおよび管理対象サーバーを構成する必要があるので注意してください。

管理対象サーバーが起動時に管理サーバーに接続できない場合、ローカルにキャッシュされた構成データを読み取ることによって、サーバーの構成データを取得できます。このようにして起動される管理対象サーバーは、管理対象サーバー(MSI)の独立モードで稼働しています。

MSIモードで管理対象サーバーを起動するには、次の手順に従います。

1. 次のファイルが管理対象サーバーのルート・ディレクトリで使用できることを確認してください。

- msi-config.xml

- SerializedSystemIni.dat

- boot.properties

これらのファイルが管理対象サーバーのルート・ディレクトリにない場合、

1. config.xmlおよびSerializedSystemIni.datファイルを管理サーバーのルート・ディレクトリ(またはバックアップ)から管理対象サーバーのルート・ディレクトリにコピーします。

2. 構成ファイルの名前を変更して、msi-config.xmlにします。サーバーを起動するとき、コピーした構成ファイルを使用します。

注意:
または、-Dweblogic.RootDirectory=path起動オプションを使用し、これらのファイルをすでに含むルート・ディレクトリを指定します。

2. コマンド・ラインまたはスクリプトで管理対象サーバーを起動します。
管理対象サーバーは、管理サーバーによって接続されるまでMSIモードで稼働します。このシナリオにおける管理サーバーの詳細は、5.1.3項「障害が発生した管理サーバーの再起動」を参照してください。

5.2 フェイルオーバー検出の概要

本番システムでは、呼出し状態データの取得して書き込むために、エンジン層サーバーが継続的にSIPデータ層のレプリカにアクセスします。Oracle WebLogic Server SIP Containerアーキテクチャは、SIPデータ層サーバーで障害が発生するか、または接続が切断されるときを検出するためにエンジン層ノードに依存します。レプリカが利用できないためエンジンが呼出し状態データにアクセスできないか、または書き込むことができないとき、エンジンは同一パーティション内の別レプリカに接続してオフライン・サーバーに報告します。レプリカは、オフライン・サーバーを考慮するためにSIPデータ層の現在のビューを更新した後、他のエンジンが呼出し状態データにアクセスして取得するときに更新されたビューがエンジンに通知されます。

デフォルトでは、エンジン層サーバーはレプリカへのRMI接続を使用し、レプリカで障害が発生したかどうか、または接続が切断されたどうかを判定します。RMI接続の障害を判定するために使用されるアルゴリズムは信頼できますが、結局は、接続を診断するためにTCPプロトコルの再送信タイマーに依存します(たとえば、レプリカへのネットワーク・ケーブルが切断される場合)。TCP再送信タイマーは通常、丸1分以上継続するため、Oracle WebLogic Server SIP Containerは、数秒で切断されたレプリカを診断できる代替障害検出メソッドを提供します。

5.2.1 WlssEchoServerの障害検出

WlssEchoServerは、同じサーバー・ハードウェア上でSIPデータ層のレプリカとして実行できる個別のプロセスです。WlssEchoServerの目的は、ネットワーク・ケーブルが切断されたときなどの、SIPデータ層サーバーがオフラインになるときを判定するために使用できるように、エンジン層ノードに単純なUDPエコー・サービスを提供することです。WlssEchoServerを使用した障害検出アルゴリズムは次のとおりです。

1. すべての標準トラフィックでは、エンジン層サーバーはTCPを使用してSIPデータ層のレプリカと通信します。TCPは、WlssEchoServerが使用されているかどうかに関係なく、エンジン層とSIPデータ層間の基本トランスポートとして使用されます。

2. エンジン層サーバーは、UDP経由で構成済の各WlssEchoServerに定期的なハートビート・メッセージを送信します。標準操作中、WlssEchoServerは、エンジン・ノードとレプリカ間の接続が検証されるようにハートビートに応答します。

3. SIPデータ層スタックの完全な障害が発生した場合、またはネットワーク・ケーブルが切断された場合、ハートビート・メッセージがエンジン・ノードに戻されます。この場合、エンジン・ノードは標準TCP接続タイムアウトを待機する必要がなく、レプリカをオフラインとしてマークできます。

4. オフライン状態にあるサーバーを特定した後、エンジン・ノードは利用可能なSIPデータ層のレプリカに障害を報告し、前の節で説明したようにSIPデータ層のビューが更新されます。

また、SIPデータ層サーバーがローカルのWlssEchoServerプロセスの停止を検出する場合、自動的にシャットダウンします。この動作によって、5.2項「フェイルオーバー検出の概要」で説明されているように、エンジン・ノードが障害を検出して報告するのにかかる時間を短縮するため、より素早いフェイルオーバーが保証されます。

必要に応じてフェイルオーバー検出のパフォーマンスを向上するために、エンジン層サーバー上のハートビート・メカニズムを構成できます。また、SIPデータ層サーバー上でWlssEchoServer が使用するリスニング・ポートおよびログ・ファイルも構成できます。

5.2.2 障害が発生したレプリカの強制シャットダウン

別のエンジン層サーバーが特定のレプリカで交信することができない場合、エンジンはSIPデータ層でオフライン・サーバーを報告するために、別の利用可能なレプリカにアクセスします。レプリカは、影響を受けるパーティションのビューを更新してオフライン・サーバーを削除します。次に更新されたビューはその後パーティションにアクセスするすべてのエンジン層サーバーに配布されます。このようにビューを伝播することで、エンジン・サーバーのオフライン・レプリカへのアクセスを防止することができます。

また、ビューを更新するレプリカは、シャットダウンを求める1回かぎりのリクエストをオフライン・レプリカに発行します。これは、ネットワーク障害によって1つ以上のエンジン・サーバーによってアクセスできない稼働中のレプリカ・サーバーをシャットダウンしようとするために実行されます。アクティブなレプリカが「オフライン」としてマークされたレプリカに到達できる場合、オフライン・レプリカはシャットダウンされます。

5.3 物理的なネットワーク障害のフェイルオーバー・パフォーマンスの向上

注意:
WlssEchoServerの使用は、すべてのOracle WebLogic Server SIP Containerインストールで必要ではありません。エコー・サーバーは、システムが構成済のTCPタイムアウト間隔よりも速くネットワーク障害またはレプリカの障害を検出する必要がある場合のみ有効化してください。

WlssEchoServerを使用してレプリカの障害を検出するとき、次の要件および制約を順守してください。

- 障害の検出にハートビート・メカニズムを使用する場合、WlssEchoServerプロセスが各レプリカ・サーバー・マシン上で常に稼働していることを確認する必要があります。WlssEchoServerプロセスに障害が発生するか、または停止される場合、サーバー・プロセスが影響を受けない場合でもレプリカは「オフライン」として処理されます。

- WlssEchoServerは、サーバー・マシン上で使用可能なすべてのIPアドレスでリスニングするので注意してください。

- WlssEchoServerには、ハートビート・メッセージのリスニング用に専用のポート番号が必要です。

5.3.1 SIPデータ層サーバー・マシンにおけるWlssEchoServerの起動

WlssEchoServerとは、シェルまたはコマンド・プロンプトから直接起動できるJavaプログラムです。WlssEchoServerを起動するための基本構文は次のようです。

java -classpath WLSS_HOME/server/lib/wlss/wlssechosvr.jar options com.bea.wcp.util.WlssEchoServer

ここで、WLSS_HOMEはOracle WebLogic Server SIP Containerインストールのパスで、optionsには表5-1で説明されるオプションのいずれかが含まれる場合があります。

表5-1 WlssEchoServerオプション

オプション

説明

-Dwlss.ha.echoserver.ipaddress

WlssEchoServerインスタンスがハートビート・メッセージをリスニングするIPアドレスを指定します。IPアドレスを指定しない場合、このインスタンスは任意の使用可能なIPアドレス(0.0.0.0)でリスニングします。

-Dwlss.ha.echoserver.port

ハートビート・メッセージをリスニングするために使用されるポート番号を指定します。指定するポート番号は、サーバー・マシン上の他のプロセスによって使用されていないことを確認してください。デフォルトでは、WlssEchoServerはポート6734番を使用します。

-Dwlss.ha.echoserver.logfile

ログ・ファイルの場所および名前を指定します。デフォルトでは、ログ・メッセージは./echo_servertime.logに書き込まれます。ここで、timeはミリ秒で表される時間です。

WlssEchoServerを起動するためのコマンドは、それぞれのOracle WebLogic Server SIP ContainerのSIPデータ層インスタンスを起動するために使用するのと同じスクリプトに組み込むことをお薦めします。startManagedWebLogic.shスクリプトをエンジンまたはSIPデータ層サーバー・インスタンスの起動に使用する場合、サーバーの起動に使用される最終コマンドの前にWlssEchoServerを起動するためのコマンドを追加してください。たとえば、次の行を変更します。

"$JAVA_HOME/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS}     \
-Dweblogic.Name=${SERVER_NAME}                                 \
-Dweblogic.management.username=${WLS_USER}                     \
-Dweblogic.management.password=${WLS_PW}                       \
-Dweblogic.management.server=${ADMIN_URL}                      \
-Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" \
weblogic.Server

読取り対象:

"$JAVA_HOME/bin/java" -classpath WLSS_HOME/server/lib/wlss/wlssechosvr.jar    \
-Dwlss.ha.echoserver.ipaddress=192.168.1.4                   \
-Dwlss.ha.echoserver.port=6734 com.bea.wcp.util.WlssEchoServer &
"$JAVA_HOME/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS}     \
-Dweblogic.Name=${SERVER_NAME}                                 \
-Dweblogic.management.username=${WLS_USER}                     \
-Dweblogic.management.password=${WLS_PW}                       \
-Dweblogic.management.server=${ADMIN_URL}                      \
-Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" \
weblogic.Server

5.3.2 サーバーにおけるハートビート・メカニズムの有効化および構成

WlssEchoServerハートビート・メカニズムを有効化するには、-Dreplica.host.monitor.enabledのJVM引数を、すべてのエンジンおよびSIPデータ層サーバーの起動に使用するコマンドに組み込む必要があります。システムにおける管理対象サーバーの起動に使用されるスクリプトに、このオプションを直接追加することをお薦めします。たとえば、startManagedWebLogic.shスクリプトで次の行を変更します。

# JAVA_OPTIONS="-Dweblogic.attribute=value -Djava.attribute=value"

読取り対象:

JAVA_OPTIONS="-Dreplica.host.monitor.enabled=true"

いくつかの追加JVMオプションによって、ハートビート・メカニズムの機能が構成されます。表5-1では、障害検出を構成するために使用されるオプションを説明しています。

表5-2 WlssEchoServerオプション

オプション

説明

-Dreplica.host.monitor.enabled

ハートビート・メカニズムを有効にするには、エンジン層サーバーとSIPデータ層サーバーの両方でこのシステム・プロパティを指定する必要があります。

-Dwlss.ha.heartbeat.interval

ハートビート・メッセージの間隔をミリ秒単位で指定します。デフォルトでは、ハートビート・メッセージは1,000ミリ秒ごとに送信されます。

-Dwlss.ha.heartbeat.count

レプリカがオフラインと判定される前に、ハートビートが連続して何回失敗できるかを指定します。デフォルトでは、サーバー上のWlssEchoServerプロセスがハートビート・メッセージへの応答に3回失敗すると、レプリカはオフラインとマークされます。

-Dwlss.ha.heartbeat.SoTimeout

UDPソケットのタイムアウト値を指定します。

5.4 SNMPの構成

Oracle WebLogic Server SIP Containerには、エンジン層およびSIPデータ層サーバー・インスタンス上のアクティビティを監視するための専用のSNMP MIBが含まれます。Oracle WebLogic Server SIP Container MIBは、ドメインの管理対象サーバーおよび管理サーバーの両方で使用できます。ただし、Oracle WebLogic Server SIP ContainerエンジンおよびSIPデータ層のトラップは、各層を構成する管理対象サーバー・インスタンスによってのみ生成されます。管理サーバーがsipserverカスタム・リソースのターゲットではない場合、WebLogic Server SNMPトラップのみ生成します(たとえば、クラスタ内のサーバーで障害が発生したとき)。管理者は、ドメイン全体の動作を評価するために、WebLogic ServerおよびOracle WebLogic Server SIP Containerのトラップの両方を監視する必要があります。

注意:
Oracle WebLogic Server SIP Container MIBオブジェクトは読取り専用です。SNMPを使用してOracle WebLogic Server SIP Container構成を変更することはできません。

5.4.1 MIBの参照

Oracle WebLogic Server SIP Container MIBファイルは、WLSS_HOME/server/lib/wlss/BEA-WLSS-MIB.asn1にインストールされます。使用可能なSNMP管理ツールまたはMIBブラウザを使用すると、このファイルのコンテンツを表示できます。共通SNMPトラップの詳細は、5.5.2項「トラップの説明」を参照してください。

5.4.2 SNMPを構成するための手順

Oracle WebLogic Server SIP Containerドメイン全体のSNMP監視を有効化するには、次の手順に従ってください。

1. Oracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。

2. 左ペインで、「診断」>「SNMP」ノードを選択します。

3. Server SNMPエージェントの表で「新規」ボタンをクリックし、新規エージェントを作成します。

注意:
Domain-Scopedエージェントではなく新しいServer SNMPエージェントを作成することを確認します。

4. 新規SNMPエージェントの一意の名前(たとえば「engine1snmp」)を入力し、「OK」をクリックします。

5. Server SNMPエージェント表から、作成した新しいSNMPエージェントを選択します。

6. 「構成」>「全般」タブで

1. 「有効化」チェック・ボックスを選択し、エージェントを有効にします。

2. SNMP UDPポート・フィールドで非使用のポート番号を入力します。

注意:
複数の管理対象サーバー・インスタンスを同じマシンで実行する場合、各サーバー・インスタンスは一意のSNMPポート番号で専用SNMPエージェントを使用する必要があります。

3. 「保存」をクリックします。

7. デプロイメント内の各サーバー(SIPデータ層サーバー、エンジン層サーバーおよび管理サーバー)に対して一意のSNMPエージェントを生成するには、上記の手順を繰り返します。

5.5 SNMPトラップの理解および応答

次の項では、Oracle WebLogic Server SIP Container SNMPトラップの詳細を説明します。各トラップへの応答に関するリカバリ手順も適宜含まれます。

5.5.1 トラブルシューティング用ファイル

次のOracle WebLogic Server SIP Containerログおよび構成ファイルは、問題のトラブルシューティングに役立つことが多く、技術サポートの連絡に必要になる場合があります。

- $DOMAIN_DIR/config/config.xml

- $DOMAIN_DIR/config/custom/sipserver.xml

- $DOMAIN_DIR/servername/*.log (server and message logs)

- sip.xml (アプリケーションの/WEB-INFサブディレクトリ内)

- web.xml (アプリケーションの/WEB-INFサブディレクトリ内)

テクニカル・サポート・チームが問題を解決する上で、次のような一般情報が役立つことがあります。

- 以下のソフトウェアの具体的なバージョン番号

- Oracle WebLogic Server SIP Container

- Java SDK

- オペレーティング・システム

- 停止Oracle WebLogic Server SIP Containerプロセスのスレッド・ダンプ

- ネットワーク・アナライザ・ログ

5.5.2 トラップの説明

表5-3は、Oracle WebLogic Server SIP Container SNMPトラップを一覧表示し、エンジン層またはSIPデータ層のサーバーによってトラップが生成されるかどうかを示します。各トラップは次の項で説明します。

表5-3 Oracle WebLogic Server SIP Container SNMPトラップ

トラップが生成されるサーバー・ノード

トラップ名

エンジン層サーバー

5.5.2.1項「connectionLostToPeer」

5.5.2.2項「connectionReestablishedToPeer」

5.5.2.4項「overloadControlActivated、overloadControlDeactivated」

5.5.2.9項「sipAppDeployed」

5.5.2.10項「sipAppUndeployed」

5.5.2.11項「sipAppFailedToDeploy」

エンジン層サーバーとSIPデータ層サーバー(サーバーがクラスタのメンバーである場合)

5.5.2.8項「serverStopped」

SIPデータ層サーバー

5.5.2.3項「dataTierServerStopped」

5.5.2.5項「replicaAddedToPartition」

5.5.2.6項「replicaRemovedEnginesRegistration」

5.5.2.7項「replicaRemovedFromPartition」

5.5.2.1 connectionLostToPeer

エンジン層のサーバー・インスタンスがSIPデータ層のレプリカに接続できなくなった場合は、そのエンジン層サーバーでこのトラップが生成されます。エンジン層とSIPデータ層の間でネットワーク接続の問題が起きている可能性があります。また、SIPデータ層のサーバーで障害が発生している場合は、このトラップとともに追加のトラップが生成されることがあります。

5.5.2.1.1 リカバリ手順

サーバーの障害を示す他のトラップとは無関係にこのトラップが発生している場合は、一般にネットワークで障害が起きています。ネットワーク・コネクションは、関わっているエンジン層のサーバーとSIPデータ層のサーバーの間に質しまたは直します。

トラップが、SIPデータ層サーバー障害(dataTierServerStoppedなど)を示す追加トラップを伴う場合、関連するトラップのリカバリ手順を実行します。

5.5.2.2 connectionReestablishedToPeer

このトラップは、前の障害の後(connectionLostToPeerトラップが生成された後)にSIPデータ層サーバーに正常に再接続される場合、エンジン層サーバー・インスタンスによって生成されます。このトラップの繰り返されたインスタンスは、エンジンおよびSIPデータ層の間の断続的ネットワーク障害を示す場合があります。

5.5.2.2.1 リカバリ手順

5.5.2.1項「connectionLostToPeer」を参照してください。

5.5.2.3 dataTierServerStopped

Oracle WebLogic Server SIP ContainerのSIPデータ層ノードは、SIPデータ層の一部であるWebLogic Serverインスタンスでリカバリ不能なエラーが発生したときに、このアラームを生成します。このトラップは、シャットダウン中のサーバー、同一パーティション内の別のレプリカ、または場合によっては両方のサーバーによって生成されることがあるので注意してください(ネットワーク停止によって両サーバーが同一のトラップを生成することがあります)。

5.5.2.3.1 リカバリ手順

5.5.2.8項「serverStopped」に関するリカバリ手順を参照してください。

5.5.2.4 overloadControlActivated、overloadControlDeactivated

Oracle WebLogic Server SIP Containerエンジン層ノードは、構成可能なスロットル・メカニズムを使用し、これは処理対象の新規SIPリクエストの数を管理するのに役立ちます。構成されたオーバーロード条件が監視された後、Oracle WebLogic Server SIP Containerは、「503 Service Unavailable」を呼出し元に応答することによって、新規SIPリクエストを破棄します。サーバーは、構成されたしきい値制御値に従ってオーバーロード条件が解決されるまで、新規リクエストを破棄し続けます。このアラームは、スロットル・メカニズムがアクティブ化されると生成されます。スロットル動作は最終的に、サーバーをオーバーロードではない状態に戻すので、それ以上の操作は必要ありません。

5.5.2.4.1 リカバリ手順

次のリカバリ手順を実行します。

1. 他のサーバーをチェックし、オーバーロード付近かどうか確認します。

2. ロード・バランサがアプリケーション・サーバー全体に渡って正常に負荷のバランスをとっているかどうか、または1つ以上のサーバーがオーバーロード状態になっているかどうかをチェックします。追加サーバーがオーバーロード状態に近い場合、Tier 4サポートに速やかに通知します。

3. この問題が1つのサーバーに限定される場合、1時間以内にTier 4サポートに通知します。

5.5.2.4.2 追加オーバーロード情報

キューの長さを受信コールのオーバーロード制御として設定する場合、管理コンソールを使用してキューの長さを監視できます。セッション率制御を指定する場合、管理コンソールを使用してセッション率を監視できません。(管理コンソールには、現在のSIPセッション数のみが表示され、新しく生成されたセッション率は表示されません。)

5.5.2.5 replicaAddedToPartition

Oracle WebLogic Server SIP ContainerのSIPデータ層ノードは、サーバー・インスタンスがSIPデータ層のパーティションに追加されるときに、このアラームを生成します。

5.5.2.5.1 リカバリ手順

このトラップは、SIPデータ層のサーバーを起動した場合の通常の起動処理時に生成されます。

5.5.2.6 replicaRemovedEnginesRegistration

SIPデータ層ノードは、登録されていなかった(または登録済エンジンのリストから削除された)エンジン・サーバー・クライアントがSIPデータ層と通信しようとすると、このアラームを生成します。このトラップの生成後、SIPデータ層の一貫性を保つためにエンジン層サーバーがシャットダウンされたことを示すserverStoppedトラップが生成されます。

5.5.2.6.1 リカバリ手順

エンジン層サーバーを再起動します。このトラップが繰返し発生する場合は、エンジン層と1つまたは複数のレプリカの間でネットワーク接続の問題が起きている可能性があります。

5.5.2.7 replicaRemovedFromPartition

Oracle WebLogic Server SIP ContainerのSIPデータ層ノードは、正常に停止された操作または障害によるシャットダウンのいずれかによって、サーバーがSIPデータ層から削除されるときに、このアラームを生成します。このトラップを生成するには、パーティション内に少なくとも1つのレプリカが残っている必要があります。パーティション内にレプリカが1つしかなく、そのレプリカに障害が発生した場合、このトラップは生成できません。また、エンジン層ノードはレプリカに障害が発生したときを判定するため、エンジン層ノードはこのトラップが生成されるために稼働している必要があります。

5.5.2.7.1 リカバリ手順

サーバー・インスタンスの障害の結果としてこのトラップが生成された場合、例外を示す追加のトラップが生成されます。replicaRemovedFromPartitionに加えて生成されるトラップのリカバリ手順を参照してください。

5.5.2.8 serverStopped

このトラップは、WebLogic Serverインスタンスが現在ダウンしていることを示します。このトラップはエンジン層とSIPデータ層の両方のサーバー・インスタンスに適用されますが、それは、サーバーが名前付きのWebLogic Serverクラスタのメンバーである場合に限られます。このトラップが、制御された停止によって発生したのではなく、自然に生成された場合は、次の手順に従います。

5.5.2.8.1 リカバリ手順

次のリカバリ手順を実行します。

1. 次のコマンドを使用して、ハングしているプロセスを特定します。

ps –ef | grep java

マシンで実行中のWebLogic Serverインスタンスごとに、対応するPIDが1つだけあるはずです。

2. 影響を受けているPIDを特定したら、次のコマンドを使ってプロセスを強制停止します。

kill -3 [pid]

3. このコマンドを実行すると、実際のスレッド・ダンプが生成されます。プロセスが直ちに停止しない場合は、潜在的なデッドロックの問題の診断に役立つように、プロセスが停止するまで5 - 10秒間隔でコマンドを何度か繰り返します。

4. Oracle WebLogic Server SIP Containerを速やかに再起動しようとします。

5. トラブルシューティングに役立つように、影響を受けたサーバーのすべてのSIPログのバックアップ・コピーを作成します。ログの場所は、サーバーの構成によって異なります。

6. Tier 4サポートが問題を解決する際に役立つように、各ログをコピーします。

注意:
Oracle WebLogic Server SIP Containerログは、システム構成に従って切り捨てられます。クリティカルなトラブルシューティング情報の損失を避けるには、速やかにバックアップ・ログを作成します。

7. Tier 4サポートに連絡し、トラブル・チケットにログ・ファイルを含めます。

8. その後24時間にわたり、サーバーを注意深くモニターします。ログ・ファイルで問題の原因を特定できない場合は、ハードウェアやネットワークに問題があり、それが時間をおいて再発することがあります。

5.5.2.8.2 追加シャットダウン情報

管理コンソールは、ServerShutDownメッセージが受信されるまでにかぎり、管理対象WebLogic ServerインスタンスのSNMPメッセージを生成します。その後、追加メッセージは生成されません。

5.5.2.9 sipAppDeployed

Oracle WebLogic Server SIP Containerのエンジン層ノードは、SIPサーブレットがコンテナにデプロイされるときに、このアラームを生成します。

5.5.2.9.1 リカバリ手順

このトラップは、通常のデプロイメント処理時に生成されます。例外を示しているわけではありません。

5.5.2.10 sipAppUndeployed

Oracle WebLogic Server SIP Containerのエンジン層ノードは、SIPアプリケーションがシャットダウンするときか、またはSIPアプリケーションがデプロイ解除される場合に、このアラームを生成します。これは通常、アクティブなリクエストが存在している間にOracle WebLogic Server SIP Containerがシャットダウンされるときに発生します。

5.5.2.10.1 リカバリ手順

通常の停止の手順では、このアラームは除去されるため、通知されないはずです。通常の運用の最中にこのアラームが発生した場合は、誰かがアプリケーションまたはサーバーを突然停止させたか、アプリケーションに問題があることを意味しています。直ちにTier 4サポートに連絡してください。

5.5.2.11 sipAppFailedToDeploy

Oracle WebLogic Server SIP Containerのエンジン層ノードは、アプリケーションがWebアプリケーションとして正常にデプロイされても、SIPアプリケーションとしてデプロイするのには失敗するときに、このトラップを生成します。

5.5.2.11.1 リカバリ手順

通常の障害は、無効なsip.xml構成ファイルによって発生して、ソフトウェアのインストールまたはアップグレード手順の間にのみ発生します。発生したら、アプリケーションをデプロイ解除し、sip.xmlファイルを検証してデプロイメントを再試行します。

注意:
通常の運用時にこのアラームが発生することは決してないはずです。もし発生した場合は、直ちにTier 4サポートに連絡してください。

5.6 WebLogic診断フレームワーク(WLDF)の使用

WebLogic診断フレームワーク(WLDF)は、WebLogic Serverインスタンスとそのアプリケーションに関する診断情報の収集、アーカイブ化、およびアクセスを行うために機能する多数のコンポーネントから構成されます。Oracle WebLogic Server SIP Containerバージョンは、エンジン層ノード/SIPデータ層ノードおよびデプロイ済SIPサーブレットの操作を監視および診断するためのWLDFコンポーネントのいくつかを統合しています。

- データ・コレクタ: Oracle WebLogic Server SIP Containerは、ランタイムMBeanから上表を収集するためにハーベスタ・サービスと統合しており、SIPリクエストおよびレスポンスをアーカイブ化するためにロガー・サービスと統合しています。

- 監視と通知: 管理者は、Oracle WebLogic Server SIP ContainerランタイムMBean属性に基づいて、複雑なルールを作成するために「監視と通知」コンポーネントを使用できます。このルールは、JMS、JMX、SNMP、SMTPなどを使用して自動通知のトリガーとなります。

- イメージのキャプチャ: Oracle WebLogic Server SIP Containerインスタンスは、特定の診断データを収集し、管理者によってリクエストされた場合そのデータをイメージ・ファイルに書き込むことができます。このデータはその後、稼働中のサーバーにおける問題の診断に使用されます。

- インストゥルメンテーション: Oracle WebLogic Server SIP Containerは、サーバーおよびアプリケーション・コードをモニターに備え付けます。これは、特定の基準に一致するSIPメッセージ(リクエストおよびレスポンス)上で実行される診断アクションを構成するのに役立ちます。

次の項では、Oracle WebLogic Server SIP Containerが、前述の各WLDFコンポーネントを統合する方法に関する詳細を説明します。

5.6.1 データ収集およびロギング

Oracle WebLogic Server SIP Containerは、WLDFハーベスタ・サービスを使用し、次のランタイムMBeanの属性からデータを収集します。

- ReplicaRuntimeMBean

- SipApplicationRuntimeMBean

- SipServerRuntimeMBean

WLDFコンソール拡張を使用して、このデータのチャートやグラフを独自のカスタム・ビューに追加できます。これを行うためには、JARファイルをドメイン・ディレクトリのconsole-extサブディレクトリにコピーすることにより、最初にWLDFコンソール拡張を有効化します。

cp ~/bea/wlserver_10.3/server/lib/console-ext/diagnostics-console-extension.jar ~/bea/user_projects/domains/mydomain/console-ext

WLDFコンソール拡張にアクセスするとき、Oracle WebLogic Server SIP ContainerのランタイムMBean属性は、拡張の「メトリック」タブで使用できます。

また、Oracle WebLogic Server SIP Containerは、WLDFロガー・サービスも使用し、SIPおよびDiameterメッセージを独立した専用ログ・ファイル(デフォルトでは、domain_home/logs/server_name/sipMessages.log)にアーカイブ化します。SIPサーバー管理コンソール拡張の「構成」>「メッセージのデバッグ」タブを使用して、ログ・ファイルの名前と場所、およびログ・ローテーション・ポリシーを構成できます。独立したロギングおよびログ・ローテーションを初期化するためには、サーバーを再起動する必要があります。

5.6.2 監視と通知

Oracle WebLogic Server SIP ContainerのランタイムMBeanから収集されたデータは、自動監視またはサーバーの診断状態を観察する「監視」を作成するために使用できます。その後、構成した監視条件およびルールが発生するときにSMTP、SNMP、JMX、またはJMSを使用してメッセージを生成するために、1つ以上の通知が監視によって使用されるように構成できます。

監視と通知を使用するためには、管理コンソールの左ペインで「診断」>「診断モジュール」ノードを選択し、監視ルールとサーバー監視に必要な通知を使用して新しいモジュールを作成します。監視ルールは、Oracle WebLogic Server SIP ContainerランタイムMBeanから収集されたメトリック、ログ・ファイルに書き込まれたメッセージ、または診断フレームワークによって生成されたイベントを使用できます。

5.6.3 イメージ・キャプチャ

Oracle WebLogic Server SIP Containerは、独自のイメージ・キャプチャ情報をWLDFによって生成された診断イメージに追加します。必要に応じて、または監視ルールを構成することによって自動的に診断イメージを作成できます。

診断イメージに含まれている情報については、Oracleのテクニカル・サポート担当者がサーバーの問題のトラブルシューティングに使用することを意図しています。これには以下の情報が含まれます。

- SIPデータ層のパーティションおよびレプリカの構成

- 呼出し状態およびタイマー統計

- ワーク・マネージャ統計

5.6.4 インストゥルメンテーション

WLDFインストゥルメンテーション・システムは、診断監視を作成し、それをOracle WebLogic Server SIP Containerまたはアプリケーション・コードの実行フローにおける特定のポイントに挿入します。Oracle WebLogic Server SIP Containerは、組込みのDyeInjection監視を提供するためにインストゥルメンテーション・サービスに統合します。有効にすると、特定のSIPメッセージがシステムに入力またはシステムから出力された場合、このモニターは仕分けフラグを診断コンテキストに注入します。仕分けフラグは、監視の構成プロパティおよび特定のリクエスト属性に基づいて組み込まれます。

Oracle WebLogic Server SIP Containerは、次の表5-4で説明されている仕分けフラグ、およびWebLogic Server仕分けフラグのUSER/ADDRを追加します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』を参照してください。

表5-4 Oracle WebLogic Server SIP Container DyeInjectionフラグ

仕分けフラグ

説明

PROTOCOL_SIP

すべてのSIPプロトコル・メッセージの診断コンテキストに設定されます。

SIP_REQ

プロパティSIP_REQの値に一致するすべてのSIPリクエストの診断コンテキストに設定されます。

SIP_RES

SIPレスポンスがプロパティSIP_RESの値に一致する場合に設定されます。

SIP_REQURI

SIPリクエストのreqURIがプロパティSIP_REQURIの値に一致する場合に設定されます。

SIP_ANY_HEADER

SIPリクエストが、プロパティSIP_ANY_HEADERの値に一致するヘッダーを含む場合に設定されます。

SIP_RES

このフラグは、プロパティSIP_RESの値に一致するすべてのSIPレスポンス用診断コンテキストに設定されます。

SIP_REQURI

このフラグは、SIPリクエストのリクエストURIがプロパティSIP_REQURIの値に一致する場合に設定されます。

SIP_ANY_HEADER

このフラグは、SIPリクエストがプロパティSIP_ANY_HEADERの値に一致するヘッダーを含む場合に設定されます。SIP_ANY_HEADERの値は、messageType.headerName=headerValueの形式を使用して指定されます。ここで、headerValueは値または正規表現のいずれかになります。たとえば、SIP_ANY_HEADER=request.Contact=sip:sipp@localhost:5061またはSIP_ANY_HEADER=response.Contact=sip:findme@172.17.30.50:5060としてプロパティを指定できます。

仕分けフラグは、受信および送信SIPメッセージの両方に適用できます。フラグは仕分けのフィルタ処理に役立ち、委任監視によって以降の診断アクションをトリガーするために使用できます。

Oracle WebLogic Server SIP Containerは、アプリケーションおよびサーバー・スコープに適用可能な委任監視をいくつか提供し、DyeInjection監視によって設定される仕分けフラグを確認できます。委任監視は表5-4で説明されています。

表5-5 Oracle WebLogic Server SIP Container診断監視

監視名

監視タイプ

スコープ

ポイントカット

occas/Sip_Servlet_Before_Service

前

アプリケーション

すべての実装サブクラスのSipServlet.do*またはSipServlet.serviceメソッドの入力時。

occas/Sip_Servlet_After_Service

後

アプリケーション

すべての実装サブクラスのSipServlet.do*またはSipServlet.serviceメソッドの終了時。

occas/Sip_Servlet_Around_Service

前後

アプリケーション

すべての実装サブクラスのSipServlet.do*またはSipServlet.serviceメソッドの入力時および終了時。

occas/Sip_Servlet_Before_Session

前

アプリケーション

SipSessionおよびSipApplicationSessionの両方用のgetAttribute、set、remove、およびinvalidateメソッドの入力時。

occas/Sip_Servlet_After_Session

後

アプリケーション

SipSessionおよびSipApplicationSessionの両方用のgetAttribute、set、remove、およびinvalidateメソッドの終了時。

occas/Sip_Servlet_Around_Session

前後

アプリケーション

SipSessionおよびSipApplicationSessionの両方用のgetAttribute、set、remove、およびinvalidateメソッドの入力時および終了時。

occas/SipSessionDebug

前後

アプリケーション

固定のポイントカットおよび固定のデバッグ・アクションを持つ、組込みのアプリケーション・スコープのモニターです。ポイントカットの前後で、監視はSipSessionDebug診断アクションを実行します。このアクションは、基礎となるオブジェクトのシリアライズ後にSIPセッションのサイズを計算します。

モニターのポイントカットは次のとおりです。

1. SipServletMessageクラス階層のgetSessionおよびgetApplicationSessionへの呼出しの前後。

2. SipSessionおよびSipApplicationSessionクラスのgetAttribute、setAttribute、およびremoveAttributeメソッドへの呼出しの前後。

注意: occas/SessionDebugAction-Beforeイベントは、req.getSession()またはreq.getApplicationSession()ジョインポイントのトリガーにはなりません。ジョイントポイントの実行後にセッションは検査目的でのみ使用可能となるため、occas/SessionDebugAction-Afterのみがトリガーされます。

注意: Apache Antを使用してアプリケーションをコンパイルする場合、必要なデバッグ情報を生成されたクラス・ファイルに組み込むためにdebug属性を有効化する必要があります。

occas/Sip_Servlet_Before_Message_Send_Internal

前

サーバー

メッセージをワイヤに書き込むOracle WebLogic Server SIP Containerコードの入力時。

occas/Sip_Servlet_After_Message_Send_Internal

後

サーバー

メッセージをワイヤに書き込むOracle WebLogic Server SIP Containerコードの終了時。

occas/Sip_Servlet_Around_Message_Send_Internal

前後

サーバー

メッセージをワイヤに書き込むOracle WebLogic Server SIP Containerコードの入力時および終了時。

5.6.4.1 サーバー・スコープ・モニターの構成

サーバー・スコープ・モニターを使用するためには、新しい診断モジュールを作成し、モジュール内に1つ以上の監視を構成する必要があります。組込みのDyeInjection監視では、固有の仕分けフラグを定義するために監視プロパティを追加します。occas/Sip_Servlet_Before_Message_Send_Internalなどの委任監視では、診断アクションを定義するために監視プロパティを追加します。

Oracle WebLogic Server SIP Container DyeInjection監視および委任監視を構成し、仕分けフィルタ処理を有効化するには、次の手順を実行します。

1. ドメインの管理コンソールにアクセスします。

2. コンソールの左ペインで「診断」>「診断モジュール」ノードを選択します。

3. 「新規」をクリックして新規診断モジュールを作成します。モジュールに「instrumentationModule」などの説明的な名前を付け、「OK」をクリックします。

4. 表のモジュール・リストから新規の「instrumentationModule」を選択します。

5. 「ターゲット」タブを選択します。

6. このモジュールをターゲットとするサーバーを選択して、「保存」をクリックします。

7. 「診断」>「診断モジュール」ノードに戻り、モジュールのリストからinstrumentationModuleを選択します。

8. 「構成」>「インストゥルメンテーション」タブを選択します。

9. 「有効化」を選択し、サーバー・レベルでのインストゥルメンテーションを有効にして、「保存」をクリックします。

10. モジュールにDyeInjectionモニターを追加するには、以下の手順に従います。

1. 「追加と削除」をクリックします。

2. 利用可能なリストからモニターの名(たとえば、DyeInjection)を選択し、矢印を使って選択したリストに移動します。

3. 「OK」をクリックします。

4. 利用可能なモニターのリストから新たに作成したモニターを選択します。

5. モニターが有効になっていることを確認し、「プロパティ」フィールドを編集して必要なプロパティを追加します。DyeInjectionモニターのサンプル・プロパティには、以下が含まれています。

SIP_RES=180
SIP_REQ=INVITE
SIP_ANY_HEADER=request.Contact=sip:sipp@localhost:5061

6. 「保存」をクリックします。

11. モジュールに1つまたは複数の委任モニターを追加するには、次の手順に従います。

1. 新規モジュールの「構成」>「インストゥルメンテーション」タブに戻ります。

2. 「追加と削除」をクリックします。

3. 「使用可能」リスト(occas/Sip_Servlet_Before_Message_Send_Internalなど)から委任監視の名前を選択し、矢印を使用して「選択済み」リストに移動します。

4. 「OK」をクリックします。

5. 利用可能なモニターのリストから新たに作成したモニターを選択します。

6. モニターが有効化されていることを確認し、使用可能なリストから1つ以上のアクションを選択してから、矢印を使用してアクションを「選択済み」リストに移動します。occas/Sip_Servlet_Before_Message_Send_Internalモニターでは、サンプル・アクションにはDisplayArgumentsAction、StackDumpAction、ThreadDumpAction、およびTraceActionが含まれます。

7. 「EnableDyeFiltering」の横にあるチェック・ボックスを選択します。

8. 利用可能なリストからSIP_REQのような1つまたは複数の仕分けマスクを選択し、矢印を使って選択したリストに移動します。

9. 「保存」をクリックします。

注意:
委任モニターを追加して作成するには、上記の手順を繰り返します。

5.6.4.2 アプリケーション・スコープ・モニターの構成

weblogic-diagnostics.xmlという名前のXML構成ファイルでアプリケーション・スコープ・モニターを構成します。SIPモジュールまたはエンタープライズ・アプリケーションのMETA-INFディレクトリにweblogic-diagnostics.xmlファイルを保存する必要があります。

XMLファイルはアプリケーション・レベルでインストゥルメンテーションを有効化し、ポイントカットを定義し、また、委任監視の仕分けマスクおよびアクションを定義します。例5-1は、occas/Sip_Servlet_Before_Serviceモニターを使用するサンプル構成ファイルを示します。

例5-1 サンプルweblogic-diagnostics.xmlファイル

<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics">
<instrumentation>
<enabled>true</enabled>
<include>demo.ProxyServlet</include>
<wldf-instrumentation-monitor>
<name>occas/Sip_Servlet_Before_Service</name>
<enabled>true</enabled>
<dye-mask>SIP_ANY_HEADER</dye-mask>
<dye-filtering-enabled>true</dye-filtering-enabled>
<action>DisplayArgumentsAction</action>
</wldf-instrumentation-monitor>
</instrumentation>
</wldf-resource>

この例では、受信リクエストの診断コンテキストがSIP_ANY_HEADER仕分けフラグを含む場合、occas/Sip_Servlet_Before_Serviceモニターがトリガーされ、DisplayArgumentsActionが実行されます。

5.7 SIPリクエストおよびレスポンスのロギング

Oracle WebLogic Server SIP Containerによって、処理対象のSIPリクエストおよびレスポンスのプロトコル・データ・ユニット(PDU)ロギングを実行することができます。ログ対象のSIPメッセージは、Oracle WebLogic Server SIP Containerのドメイン全体ログ・ファイル、または各管理対象サーバー・インスタンスのログ・ファイルのいずれかに配置されます。SIPメッセージはOracle WebLogic Server SIP Containerインスタンスと同一のログ・ファイルを共有するため、ログ対象SIPメッセージを管理するときに、ログ・ローテーション、ドメイン・ログ・フィルタ処理、最大ログ・サイズ構成などの高度なサーバー・ロギング機能を使用できます。

管理者は、com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImplクラスを使用して1つ以上のSIPサーブレットを定義することによって、SIP PDUロギングを構成します。ロギング基準は、定義されたサーブレットへのパラメータとしてか、またはアプリケーションでパッケージ化された個別のXMLファイルのいずれかで構成されます。

SIPリクエストが処理されるか、SIPレスポンスが生成される際に、ロギング・サーブレットはスタンドアロンのXML構成ファイルまたはサーブレットのパラメータで定義されたフィルタ処理のパターンをメッセージと照合します。指定されたパターンと一致するSIPリクエストとレスポンスは、ロギング・サーブレットの名前、構成されているロギング・レベル、その他の詳細とともにログ・ファイルに書き込まれます。無駄なパターン・マッチングを避けるために、サーブレットは最初のパターンが一致すると新しいSIPセッションにマークして、そのセッションのそれ以降のリクエストとレスポンスを自動的にログに記録します。

ロギング基準は、ロギング・サーブレットへのパラメータとしてsip.xmlまたは外部XML構成ファイルのいずれかのディレクトリで定義されます。詳細は、5.7.3項「ロギング・メッセージの基準の指定」を参照してください。

注意:
エンジニアは、サーブレットのinit()メソッドでTraceMessageListenerFactoryを使用して委任を作成するか、またはデプロイされたJavaアプリケーションでトレース・クラスを使用するかのいずれかによって、サーブレットでPDUロギング機能を実装できます。委任を使用すると、デフォルトのトレース・メッセージ・リスナー実装を使用してカスタム・ロギングまたは受信SIPメッセージの操作を実行できます。サーブレットのinit()メソッドでファクトリを使用する例については、5.7.7項「トレース機能のSIPサーブレット・コードへの追加」を参照してください。

5.7.1 sip.xmlにおけるロギング・サーブレットの定義

SIPメッセージのロギング・サーブレットは、実装クラスcom.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImplを持つサーブレットを定義することによって作成されます。サンプルmsgTraceLoggerの定義は、例5-2で示されます。

例5-2 サンプル・ロギング・サーブレット

<servlet>
<servlet-name>msgTraceLogger</servlet-name>
<servlet-class>com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl</servlet-class>
<init-param>
<param-name>domain</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>level</param-name>
<param-value>full</param-value>
</init-param>
<load-on-startup/>
</servlet>

5.7.2 ロギング・レベルおよび宛先の構成

ロギング詳細のレベルやSIPメッセージの宛先ログ・ファイルなどのロギング属性は、ロギング・サーブレットへの初期化パラメータとして渡されます。表5-5は、init-paramエントリとして指定できるパラメータおよびパラメータ値を一覧を表示します。例5-2は、SIPメッセージ情報をドメインログ・ファイルに記録するサーブレットのサンプルinit-paramエントリを示します。

5.7.3 ロギング・メッセージの基準の指定

SIPメッセージをロギングするための基準は、ロギング・サーブレットのアプリケーションにパッケージされるXMLファイル、またはサーブレットのsip.xmlデプロイメント記述子で初期化パラメータとして定義できます。次の項では、各メソッドを説明します。

5.7.3.1 ロギング基準を指定するためのXMLドキュメントの使用

ロギング基準をロギング・サーブレットへの初期化パラメータとして指定しない場合、サーブレットはロギング・アプリケーションの最上位にあるXML記述子ファイルのペアでロギング基準を検索します。これらの記述子ファイルは、request-pattern.xmlおよびresponse-pattern.xmlという名前で、Oracle WebLogic Server SIP Containerがログ・ファイルに配置するためのSIPリクエストおよびレスポンスを選択するために使用するパターンを定義します。

注意:
デフォルトでは、Oracle WebLogic Server SIP Containerはリクエストおよびレスポンスの両方をロギングします。レスポンスはロギングしない場合、response-pattern.xmlファイルを空の照合基準で定義する必要があります。

通常のパターン定義は、SIPメッセージ・ヘッダーにおける特定の値に一致する条件を定義します。たとえば、msgTraceLoggerサーブレットで使用されるサンプルresponse-pattern.xmlは、すべてのMESSAGEリクエストに一致します。この記述子のコンテンツは次で示されます。

例5-3 msgTraceLoggerサーブレットのサンプルresponse-pattern.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>response.method</var>
<value>MESSAGE</value>
</equal>
</pattern>

SIPメッセージ照合の追加演算子および条件は、5.7.6項「trace-pattern.dtdリファレンス」で説明されています。例5-3で説明されているequal条件などの大半の条件には、評価対象のSIPメッセージの部分を識別する変数(var要素)が必要です。表5-5では、共通変数およびサンプル値の一部を一覧を表示しています。追加の変数名および例については、SIPサーブレットAPI 1.1仕様書(http://jcp.org/en/jsr/detail?id=289)の16項「リクエストのサーブレットへのマッピング」を参照してください。Oracle WebLogic Server SIP Containerによって、リクエストおよびレスポンスの変数をロギング・サーブレットにマップできるようになります。

表5-6 パターン・マッチングの変数と値の例

変数

サンプル値

request.method、response.method

MESSAGE、INVITE、ACK、BYE、CANCEL

request.uri.user、response.uri.user

guest、admin、joe

request.to.host、response.to.host

server.mydomain.com

request-pattern.xmlおよびresponse-pattern.xmlの両方が同一のDocument Type Definition (DTD)を使用します。詳細は、5.7.6項「trace-pattern.dtdリファレンス」を参照してください。

5.7.3.2 ロギング基準を指定するためのサーブレット・パラメータの使用

パターン照合基準は、個別のXMLドキュメントとしてではなく、ロギング・サーブレットへの初期化パラメータとしても指定できます。照合基準の指定に使用されるパラメータ名は、request-pattern-stringおよびresponse-pattern-stringです。これらは、5.7.2項「ロギング・レベルおよび宛先の構成」で説明されているように、ロギング・レベルおよび宛先に従って定義されます。

各パターン照合パラメータの値は、スタンドアロン・パターン定義ドキュメントのDTDに準拠している有効なXMLドキュメントから構成される必要があります(5.7.3.1項「ロギング基準を指定するためのXMLドキュメントの使用」を参照)。パターンや値を定義するXMLドキュメントは、sip.xml記述子の部分として解析されてはならないので、CDATAタグ内にコンテンツを囲い込む必要があります。例5-4では、サンプル・ロギング・サーブレットであるinvTraceLoggerのフルsip.xmlエントリを示しています。最後の2つのinit-param要素は、サーブレットがINVITEリクエスト・メソッドおよびOPTIONSレスポンス・メソッドのみをロギングすることを指定します。

例5-4 init-param要素として指定されたロギング基準

<servlet>
<servlet-name>invTraceLogger</servlet-name>
<servlet-class>com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl</servlet-class>
<init-param>
<param-name>domain</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>level</param-name>
<param-value>full</param-value>
</init-param>
<init-param>
<param-name>request-pattern-string</param-name>
<param-value>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>request.method</var>
<value>INVITE</value>
</equal>
</pattern>
]]>
</param-value>
</init-param>
<init-param>
<param-name>response-pattern-string</param-name>
<param-value>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>response.method</var>
<value>OPTIONS</value>
</equal>
</pattern>
]]>
</param-value>
</init-param>
<load-on-startup/>
</servlet>

5.7.4 暗号化されていないロギングのコンテンツ・タイプの指定

デフォルトでは、Oracle WebLogic Server SIP Containerは文字列フォーマット(UTF-8エンコーディング)を使用して、テキストまたはapplication/sdp Content-Type値を持つSIPメッセージのコンテンツをロギングします。他のすべてのContent-Type値では、Oracle WebLogic Server SIP Containerは、指定されている場合にメッセージのcharsetパラメータで指定される文字セットを使用して、メッセージ・コンテンツをロギングする試行を行います。charsetパラメータが指定されていない場合、あるいはcharset値が無効またはサポートされていない場合、Oracle WebLogic Server SIP ContainerはBase-64エンコーディングを使用して、メッセージをロギングする前にメッセージ・コンテンツを暗号化します。

このような状況でメッセージのコンテンツを暗号化しない場合、sipserver.xmlでstring-rep要素を使用して、文字列が表示可能なContent-Type値のリストを指定してください。string-rep要素には、照合対象の1つ以上のcontent-type要素が含まれる可能性があります。ロギングされたメッセージが、構成されたcontent-type要素のいずれかに一致する場合、Oracle WebLogic Server SIP Containerは、charsetパラメータが含まれるかどうかに関係なく、UTF-8エンコーディングを使用して文字列フォーマットでコンテンツをロギングします。

注意:
text/*またはapplication/sdpのコンテンツ・タイプはデフォルトとして文字列フォーマットにログされているため、指定する必要はありません。

例5-5では、text/* and application/sdpコンテンツに加えて、3つの追加Content-Type値の文字列コンテンツをロギングするサンプルmessage-debug構成を示しています。

例5-5 追加コンテンツ・タイプの文字列コンテンツのロギング

<message-debug>
<level>full</level>
<string-rep>
<content-type>application/msml+xml</content-type>
<content-type>application/media_control+xml</content-type>
<content-type>application/media_control</content-type>
</string-rep>
</message-debug>

5.7.5 ログ・ローテーションの有効化およびログ・ファイルの表示

Oracle WebLogic Server SIP Containerのロギング・インフラストラクチャによって、既存のログ・ファイルが指定されたサイズに到達したときに、新しいログ・ファイルに自動的に書き込むことができるようになります。管理コンソールを使用してログ・コンテンツを表示するか、ログに書き込まれる追加サーバー・レベル・イベントを構成できます。

5.7.6 trace-pattern.dtdリファレンス

trace-pattern.dtdは、request-pattern.xmlおよびresponse-pattern.xmlの必須コンテンツ、ドキュメント、request-pattern-stringおよびresponse-pattern-stringサーブレットのinit-param変数の値を定義します。

例5-6 trace-pattern.dtd

<!--
The different types of conditions supported.
- >

<!ENTITY % condition "and | or | not |
equal | contains | exists | subdomain-of">

<!--
A pattern is a condition: a predicate over the set of SIP requests.
- >

<!ELEMENT pattern (%condition;)>

<!--
An "and" condition is true if and only if all its constituent conditions
are true.
- >

<!ELEMENT and (%condition;)+>

<!--
An "or" condition is true if at least one of its constituent conditions
is true.
- >

<!ELEMENT or (%condition;)+>

<!--
Negates the value of the contained condition.
- >

<!ELEMENT not (%condition;)>

<!--
True if the value of the variable equals the specified literal value.
- >

<!ELEMENT equal (var, value)>

<!--
True if the value of the variable contains the specified literal value.
- >

<!ELEMENT contains (var, value)>

<!--
True if the specified variable exists.
- >

<!ELEMENT exists (var)>

<!--
- >

<!ELEMENT subdomain-of (var, value)>

<!--
Specifies a variable. Example:
<var>request.uri.user</var>
- >

<!ELEMENT var (#PCDATA)>

<!--
Specifies a literal string value that is used to specify rules.
- >

<!ELEMENT value (#PCDATA)>

<!--
Specifies whether the "equal" test is case sensitive or not.
- >

<!ATTLIST equal ignore-case (true|false) "false">

<!--
Specifies whether the "contains" test is case sensitive or not.
- >

<!ATTLIST contains ignore-case (true|false) "false">

<!--
The ID mechanism is to allow tools to easily make tool-specific
references to the elements of the deployment descriptor. This allows
tools that produce additional deployment information (i.e information
beyond the standard deployment descriptor information) to store the
non-standard information in a separate file, and easily refer from
these tools-specific files to the information in the standard sip-app
deployment descriptor.
- >

<!ATTLIST pattern id ID #IMPLIED>
<!ATTLIST and id ID #IMPLIED>
<!ATTLIST or id ID #IMPLIED>
<!ATTLIST not id ID #IMPLIED>
<!ATTLIST equal id ID #IMPLIED>
<!ATTLIST contains id ID #IMPLIED>
<!ATTLIST exists id ID #IMPLIED>
<!ATTLIST subdomain-of id ID #IMPLIED>
<!ATTLIST var id ID #IMPLIED>
<!ATTLIST value id ID #IMPLIED>

5.7.7 SIPサーブレット・コードへのトレース機能の追加

トレース機能は、TraceMessageListenerFactoryを使用して、独自のサーブレットまたはJavaコードに追加できます。TraceMessageListenerFactoryは、インスタンスを作成してそれに委譲することによって、クライアントがデフォルトのトレース・メッセージ・リスナー実装の動作を再利用できるようにします。ファクトリ実装インスタンスは、TraceMessageListenerFactory.TRACE_MESSAGE_LISTENER_FACTORY属性の値を検出することによって、SIPサーブレットのサーブレット・コンテンツで検索できます。

注意:
ファクトリによって作成されたインスタンスは、SIPメッセージの受信および送信時にコールバックを受信するために、Oracle WebLogic Server SIP Containerに登録されません。

サーブレット内のトレースを実装するためには、ファクトリ・クラスを使用し、例5-7で示されているように、サーブレットのinit()メソッドで委任を作成します。

例5-7 TraceMessageListenerFactoryの使用

public final class TraceMessageListenerImpl extends SipServlet implements MessageListener {
private MessageListener delegate;

public void init() throws ServletException {
ServletContext sc = (ServletContext) getServletContext();
TraceMessageListenerFactory factory = (TraceMessageListenerFactory) sc.getAttribute(TraceMessageListenerFactory.TRACE_MESSAGE_LISTENER_FACTORY);
delegate = factory.createTraceMessageListener(getServletConfig());
}
public final void onRequest(SipServletRequest req, boolean incoming) {
delegate.onRequest(req,incoming);
}
public final void onResponse(SipServletResponse resp, boolean incoming) {
delegate.onResponse(resp,incoming);
}
}

5.7.8 リスナーおよびロギング・サーブレットの起動順序

リスナーとロギング・サーブレットが両方ともデプロイされている場合は、最初にリスナー・クラスがロードされ、その後でサーブレットがロードされます。各ロギング・サーブレットがデプロイされる順序は、Webアプリケーションのデプロイメント記述子で指定されているロード順序に従います。

5.8 本番デプロイメントのJVMガベージ・コレクションのチューニング

Oracle WebLogic Server SIP Containerの本番インストールは通常、サーバー・ロードのピークときでさえも、いつもクライアントに極端に短いレスポンス時間(50ミリ秒未満)を要求します。短いレスポンス時間を維持するキー・ファクタは、エンジン層におけるOracle WebLogic Server SIP ContainerインスタンスのJVMガベージ・コレクション(GC)アルゴリズムを適切に選択してチューニングすることです。

一部のチューニング方式はガベージ・コレクションの平均時間を最短にすることや完全なガベージ・コレクションの実行頻度を最小に抑えることを目的として設計されていますが、これらの方式では、長短のGC間隔を組み合せて総合的にGCの影響を軽減する方針が採用されているので、結果的に1回または数回、非常に時間のかかる(数秒間に及ぶことが多い)ガベージ・コレクションが発生することがあります。本番のSIP Serverでは、レスポンス時間の目標を維持するために、長いGC間隔が一切発生しないようにする必要があります。

次の項では、通常は結果として最高のレスポンス時間パフォーマンスになるJRockitおよびSunのJVMのGCチューニング手法を説明しています。

注意:
JRockitの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの紹介』を参照してください。

5.8.1 サーバー起動スクリプトにおけるJVMパラメータの変更

Oracle WebLogic Server SIP Containerエンジンおよびレプリカを起動するためにカスタム起動スクリプトを使用する場合、スクリプトを編集して、次の項で説明されているお薦めのJVMオプションを含めるようにします。

構成ウィザードは、新しいドメインを構成するときに、デフォルトの起動スクリプトもインストールします。このスクリプトは、デフォルトでMIDDLEWARE_HOME/user_projects/domains/domain_name/binディレクトリにインストールされ、次を含みます。

- startWebLogic.cmd、startWebLogic.sh: これらのスクリプトは、ドメインの管理サーバーを起動します。

- startManagedWebLogic.cmd、startManagedWebLogic.sh: これらのスクリプトは、ドメイン内の管理対象エンジンおよびレプリカを起動します。

エンジンおよびレプリカの起動にOracleのインストールしたスクリプトを使用する場合、コマンド・シェルで最初にUSER_MEM_ARGS環境変数を設定することによって、JVMメモリー引数をオーバーライドできます。

注意:
USER_MEM_ARGSの環境変数を設定することでOracleのインストールしたスクリプトで指定されたすべてのデフォルトのJVMメモリー引数をオーバーライドすることができます。常に使用する意向があるJVMメモリー引数の完全なリストにUSER_MEM_ARGSを設定します。たとえば、デフォルトのヒープ領域(-Xms、-Xmx)パラメータだけ変更する意向がある場合でも、Sun JVMを使用する場合、常に-XX:MaxPermSize=128mをUSER_MEM_ARGSの値に追加します。

5.8.2 JRockitを使用したガベージ・コレクションのチューニング

JRockitには、任意の時点のJVMヒープを分析するために役立つ次のようなモニタリング・ツールが用意されています。

- JRockitランタイム・アナライザ: ガベージ・コレクションのランタイム動作への表示および休止時間を提供します。

- JRockitスタック・ダンプ: トラブルシューティングまたはパフォーマンスの向上(あるいはその両方)に役立てるためのアプリケーションのスレッド・アクティビティを表示します。

制御された環境でこれらのツールや他のツールを使用すると、本番デプロイメントで設定を使用する前に、JVM設定の効果を判定できます。

次の項では、JRockitを使用したお薦めの起動JVMオプションを説明しています。JRockitを確定的ガベージ・コレクタ(お薦め)を使用する場合、5.8.3項「Oracle JRockitリアルタイム(確定的ガベージ・コレクション)の使用」に関する項で説明されているオプションを使用してください。

5.8.3 Oracle JRockitリアルタイム(確定的ガベージ・コレクション)の使用

確定的ガベージ・コレクタを実装するJRockitリアルタイムを使用することによって、極端に短いレスポンス時間はかなり容易に達成されます。

レプリケートされたクラスタ構成のエンジン層サーバーに次のJVM引数を使用することをお薦めします。

-Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc

注意:
先述の設定は、JRockit JVMを使用して新規ドメインを作成するために構成ウィザードを使用するとき、$WLSS_HOME/common/bin/wlssCommenv.shファイルにデフォルトで構成されます。
割当てインテンシブなアプリケーションに対して、-XpauseTarget値を高める必要がある可能性があります。この値は、より小さいアプリケーションに対して軽負荷の下で減らすことができます。

デプロイ済アプリケーションで使用される実データの量に応じて、ヒープ・サイズを調整します。開始点として、ヒープ・サイズをアプリケーションが必要とする合計の2から3倍まで設定します。必要な合計の3倍に近い値は、通常、最良のパフォーマンスをもたらします。

レプリカ・サーバーのため、利用可能なメモリーの容量を増大させます。

-Xms3072m -Xmx3072m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc

これらの設定は、ヒープ・サイズを修正し、確定的ガベージ・コレクションを使用して動的ガベージ・コレクタを有効化します。-XpauseTargetは最大休止時間を設定し、-XXtlasize=3kはスレッド・ローカル領域サイズを設定します。-XXnosystemgcによって、System.gc()アプリケーション・コールが強制的にガベージ・コレクションを実行しないようになります。

5.8.4 確定的ガベージ・コレクションを使用しないOracle JRockitの使用

確定的ガベージ・コレクションを使用せずにOracleのJRockit JVMを使用するとき(本番デプロイメントではお薦めしません)、ベスト・レスポンス時間のパフォーマンスは、世代別同時実行ガベージ・コレクタを使用することによって取得されます。

エンジン層サーバーの起動オプション例の一覧は以下のとおりです。

-Xms1024m -Xmx1024m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m

注意:
デプロイ済アプリケーションで使用される実データの量に応じて、ヒープ・サイズを微調整します。

レプリカ・サーバーの起動オプション例の一覧は以下のとおりです。

-Xms3072m -Xmx3072m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m

5.8.5 Sun JDKを使用したガベージ・コレクションのチューニング

SunのJDKを使用するとき、ガベージ・コレクションのパフォーマンスをチューニングする際の目標は、フル・ガベージ・コレクション・サイクルを実行するために必要な時間を削減することです。フル・ガベージ・コレクションの頻度を最小化するためにJVMをチューニングする試行は行わないでください。これを行うと、通常は完了までに数秒かかる場合がある強制ガベージ・コレクション・サイクルになってしまうからです。

本番サーバーの存続期間におけるガベージ・コレクション時間の短縮を実現する最も単純で信頼性の高い方法は、ヒープのサイズを固定してデフォルト・コレクタと若い世代用の並行コレクタを使用することにより、新しい世代のサイズを最大でもヒープ全体の1/3までに制限することです。

ほとんどのエンジン層サーバーには以下のJVM設定例をお勧めします。

-server -Xmx1024m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC

レプリカ・サーバーには、以下の設定例を使用します。

-server -Xmx3072m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC

上記のオプションには、それぞれ次のような効果があります。

- -XX:+UseTLAB: スレッド・ローカル・オブジェクトの割当てブロックを使用します。これは、共有ヒープ・ロックにおける競合を削減することによって、同時実行性を向上します。

- -XX:+UseParNewGC: 同時実行マーク・アンド・スイープ・コレクタに従って、若い世代のコピー・コレクタの並列バージョンを使用します。これは、すべての使用可能なCPUを並列に使用することによって、休止時間を最小化します。このコレクタは、デフォルトのコレクタおよび同時実行マーク・アンド・スイープ(CMS)コレクタと互換性があります。

- -Xms, -Xmx: ガベージ・コレクションの予測可能性を向上するために、ヒープ・サイズ上の境界を設定します。ヒープ・サイズは、フルGCでさえもSIP再送信をトリガーしないようにレプリカ・サーバーで限定されます。-Xmsは、ヒープの拡大によって生じる休止を防ぐために開始サイズを設定します。

- -XX:MaxTenuringThreshold=0: フルNewSizeを各NewGCサイクルに使用できるようにし、古いオブジェクトを評価しないことによって、休止時間を削減します。技術的には、この設定によってコピーするのではなく、すべてのライブ・オブジェクトが古い世代に昇格されます。

- -XX:SurvivorRatio=128: サバイバがない場合にほとんど領域が予約されないことを保証するためのゼロ保有しきい値を伴う、高いサバイバ率を指定します。

5.9 乱数生成によって発生するJVM遅延の回避

SunのJVMにおける乱数生成で使用されるライブラリは、UNIXプラットホームの場合、デフォルトで/dev/randomに依存します。一部のオペレーティング・システムでは、結果が戻される前に/dev/randomがホスト・マシン上で特定の量の「ノイズ」が生成されるまで待機するため、Oracle WebLogic Server SIP Containerプロセスをブロックする可能性があります。/dev/randomはセキュリティ性がより向上していますが、デフォルトのJVM構成がOracle WebLogic Server SIP Containerの起動を遅延する場合、/dev/urandomを使用することをお薦めします。

実際に使用しているオペレーティング・システムでこの遅延の問題が発生するかどうかを確認するには、このファイルの一部分を表示する次のコマンドをシェル・プロンプトから実行します。

head -n 1 /dev/random

1. テキスト・エディタで$JAVA_HOME/jre/lib/security/java.securityファイルを開きます。

2. 次の行を変更します。

securerandom.source=file:/dev/random

読取り対象:

securerandom.source=file:/dev/urandom

3. 変更を保存して、テキスト・エディタを終了します。

6 Diameterクライアント・ノードとリレー・エージェントの構成

次の項では、Oracle WebLogic Server SIP ContainerドメインでDiameterノード、あるいはリレーとしての役割を果たす個別のサーバーの構成方法を説明します。

- 6.1項「Diameterプロトコル構成の概要」

- 6.2項「Diameterクライアント・ノードとおよびリレー・エイジェントの構成の手順」

- 6.3項「Diameterドメインのインストール」

- 6.4項「Diameterコンソール拡張の有効化」

- 6.5項「DiameterプロトコルのTCP、TLS、SCTPネットワーク・チャネルの作成」

- 6.6項「Diameterノードの構成」

- 6.7項「ドメイン構成の例」

- 6.8項「Diameter構成のトラブルシューティング」

6.1 Diameterプロトコル構成の概要

通常なOracle WebLogic Server SIP Containerドメインは、Diameterベースのプロトコルおよび、Diameterクライアント・ノードとして動作するエンジン属サーバーにデプロイされる1つまたは複数のIMS Diameterインタフェース・アプリケーション(Sh、Ro、Rf)をサポートしています。エンジン上にデプロイされるSIPサーブレットでは、利用可能なDiameterアプリケーションを使用して、ユーザー・プロファイル・データ、アカウンティングおよびクレジット管理に対するリクエストを発信することや、プロファイル・データの変更通知のサブスクライブと受信することができます。

1つまたは複数のサーバー・インスタンスをDiameterリレー・エージェントとして構成することもできます。Diameterリレー・エージェントは、クライアント・ノードからのDiameterメッセージをルーティングして、ネットワーク内で構成されているHome Subscriber Server (HSS)や他のノードに転送しますが、メッセージを変更する処理は行いません。ドメイン内の1つまたは複数のサーバーをリレー・エージェントとして構成することをお薦めします。リレー・エージェントを使用するとDiameterクライアント・ノードの構成が容易になり、HSSへのネットワーク接続の数を削減できます。少なくとも2つのリレー・エージェントを使用すると、1つのリレー・エージェントに障害が発生した場合でも、HSSへのルートを必ず確立することができます。

注意:
3GPPでは、複数のHSSをサポートできるように、適切なHSSをルックアップするためのDhインタフェースが定義されています。Oracle WebLogic Server SIP ContainerにはDhインタフェース・アプリケーションは含まれていないため、Oracle WebLogic Server SIP Containerで可能なのは単一のHSSを使用する構成のみです。

リレー・エージェント・サーバーは、エンジン層またはSIPデータ層のインスタンスとしては機能しないことに注意してください - つまり、アプリケーションのホスト、呼出し状態データの格納、SIPタイマーの管理、SIPプロトコール・ネットワーク・リソース(sipまたはsipsネットワーク・チャネル)の使用は許されません。

Oracle WebLogic Server SIP ContainerはShおよびRoプロトコルのシミュレータ・アプリケーションも提供します。ShとRoクライアントを開発するとき、シミュレータ・アプリケーションをテストのために使用できます。シミュレータ・アプリケーションは本番システムのデプロイメント用のものではありません。

6.2 Diameterクライアント・ノードとリレー・エージェントの構成の手順

Oracle WebLogic Server SIP ContainerドメインにDiameterサポートを構成するには、次の手順を実行します。

1. Oracle WebLogic Server SIP Container Diameterドメインのインストール。Diameterドメインをインストールします。このドメインには、各種のDiameterノード・タイプ用に構成されたサンプル構成およびテンプレート・アプリケーションが含まれています。Diameterドメインは、ユーザー独自のドメインのテンプレートとして使用したり、様々なDiameterノード・タイプの構成方法を理解するために使用できます。

2. Diameterコンソール拡張を有効化してください。サンプルのDiameterドメインで作業している場合、Diameterコンソール拡張はすでに有効化しています。基本的なOracle WebLogic Server SIP Containerドメインを使用して起動する場合は、拡張を有効化するため、config.xmlファイルを編集します。

3. Diameterネットワーク・チャネルを作成します。エンジン層サーバーおよびリレー・エージェント上で、TCP、TLSまたはSCTPトランスポートのDiameterをサポートするために必要なネットワーク・チャネルを作成します。

4. Diameterノードを作成して、構成します。リレー・エイジェントやHSSのようなその他のネットワーク要素へのルート、ホスト名、ピアを使用して、エンジン層サーバーにDiameter・プロトコル・クライアント・アプリケーションを構成します。WebLogic SIP Serverインスタンスなしで、スタンドアロン・モードで動作するDiameterノードも構成することができます。

次の項では、各手順について詳しく説明します。詳細は、6.7項「ドメインの構成例」も参照してください。

6.3 Diameterドメインのインストール

構成ウィザードでは、次の4つのOracle WebLogic Server SIP Containerインタスンスを含むドメインが作成されるDiameterドメインのテンプレートが含まれています。

- 管理サーバー(AdminServer)

- Diameter Shクライアント・ノード(hssclient)

- Diameterリレー・ノード(リレー)

- HSSシミュレータ(hss)

すでにインストールしたDiameterドメインは、独自のドメインを作成するための基準として使用できます。また、カスタマイズしたDiameter Webアプリケーションをテンプレートとして使用して、既存のOracle WebLogic Server SIP ContainerインスタンスをHSSクライアントまたはリレー・エージェント・ノードとして機能するように構成することもできます。次の項で示す構成の手順は、Diameterドメインの構成にアクセスできることを前提としたものです。ドメインをインストールするには、次の手順に従います。

1. WLS_HOME\common\binディレクトリに移動します。WLS_HOMEはOracle WebLogic Server10g リリース 3のOracle WebLogic Server SIP Containerをインストールしたディレクトリです (たとえば、c:\bea\wlserver_10.3\common\bin)。

2. config.cmdまたはconfig.shスクリプトを実行して、構成ウィザードを起動します。

3. 「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

4. 既存のテンプレート上では、「既存のテンプレートを、このドメインのベースにする」を選択して、「参照」ボタンをクリックします。

5. diameterdomain.jarテンプレートを選択して、「OK」をクリックします。

6. 「次へ」をクリックします。

7. 新しいドメインの管理者のユーザー名とパスワードを入力し、「次へ」をクリックします。

8. 新しいドメインで使用する起動モードとJDKを選択し、「次へ」をクリックします。

9. デフォルト・テンプレート・オプションを取得するため「いいえ」を選択して「次へ」をクリックします。

10. デフォルトのドメイン名およびドメインの場所(/user_projects/domains/diameter)を使用して、新しいドメインを作成するには、「作成」をクリックします。

11. 「完了」をクリックします。

表6-2 では、Diameterドメインにインストールされたサーバー構成について説明します。

表6-1 Diameterドメインの主要な構成要素

サーバー名

ネットワーク・チャネルの構成

Diameterアプリケーション

ノート

AdminServer

なし

なし

Administration ServerはSIPまたはDiameterのプロトコル機能を提供しません。

hssclient

diameter (ポート3868上のTCP)

sip (ポート5060上のUDP/TCP)

WlssShApplication

hssclientエンジンは、Diameter Shクライアント・ノードとして機能します。このサーバーでは、SIPおよびDiameterトラフィックの両方をサポートするネットワーク・チャネルが含まれています。Diameterノードの構成は、WlssShApplication(com.bea.wcp.diameter.sh.WlssShApplication)をデプロイして、SIPサーブレットのIMS Shインタフェース機能を提供します。

relay

diameter (ポート3869上のTCP)

RelayApplication

relayエンジンは、Diameter Shリレー・ノードとして機能します。このサーバーでは、両方のDiameterトラフィックをサポートするネットワーク・チャネルが含まれています。リレーはSIPメッセージを処理しないため、このサーバーにはSIPトラフィックをサポートするチャネルは含まれていません。

Diameterノードの構成は、RelayApplication(com.bea.wcp.diameter.relay.RelayApplication)をデプロイして、リレー・サービスを提供します。ノード構成は、hssclientエンジンからメッセージをリレーするためのレルムに基づくルートも定義します。

hss

diameter (ポート3870上のTCP)

HssSimulator

hssエンジンのDiameterノード構成は、HssSimulatorアプリケーション(com.bea.wcp.diameter.sh.HssSimulator)のみをデプロイします。サーバーは、Diameterネットワーク・チャネルを使用して、構成されています。

6.4 Diameterコンソール拡張の有効化

Oracle WebLogic SIP Serverは、Diameterノードを作成して構成するためのコンソール拡張を提供します。拡張によって作成された実際の構成は、ドメイン・ディレクトリのconfig/customサブディレクトリにあるdiameter.xml構成ファイルに保存されています。

サンプルDiameterドメインでは、Diameterコンソール拡張はすでに有効化されています。拡張を有効化しないドメインを使用している場合は、ドメインのconfig.xmlファイルを編集して、拡張のカスタム・リソースを指定します。例6-1は、コンソール拡張を有効化するために必要なconfig.xmlエントリを強調表示しています。テキスト・エディタを使用して、config.xmlの正しい位置に強調表示されたラインを追加します。

例6-1 Diameterコンソール拡張を有効にするためのconfig.xmlエントリ

<custom-resource>
<name>sipserver</name>
<target>hssclient</target>
<descriptor-file-name>custom/sipserver.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.SipServerResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.SipServerBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>diameter</name>
<target>hssclient,relay,hss</target>
<deployment-order>200</deployment-order>
<descriptor-file-name>custom/diameter.xml</descriptor-file-name>
<resource-class>com.bea.wcp.diameter.DiameterResource</resource-class>
<descriptor-bean-class>com.bea.wcp.diameter.management.descriptor.beans.DiameterBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>ProfileService</name>
<target>hssclient</target>
<deployment-order>300</deployment-order>
<descriptor-file-name>custom/profile.xml</descriptor-file-name>
<resource-class>com.bea.wcp.profile.descriptor.resource.ProfileServiceResource</resource-class>
<descriptor-bean-class>com.bea.wcp.profile.descriptor.beans.ProfileServiceBean</descriptor-bean-class>
</custom-resource>
<admin-server-name>AdminServer</admin-server-name>
</domain>

6.5 DiameterプロトコルのTCP、TLS、SCTPネットワーク・チャネルの作成

Oracle WebLogic SIP Server ContainerのDiameter実装では、TCP、TLSまたはSCTPトランスポートプロトコル上のDiameterプロトコルがサポートされています。(SCTPトランスポートには、6.5.2項「DiameterメッセージングのためのSCTPの構成と使用」で説明されているような特定の制限があります。)

サーバーで着信Diameter接続が利用できるようにするには、適切なプロトコル・タイプの専用ネットワーク・チャネルを設定する必要があります。

- 「diameter」チャネルはTCPトランスポートを使用します。

- 「diameters」チャネルはTCP/TLSトランスポートを使用します。

- 「diameter-sctp」チャネルはTCP/SCTPトランスポートを使用します。

Diameter用のTCP/TLSチャネル(diametersチャネル)を使用するサーバーでは、双方向SSLも有効にする必要があります。Diameter仕様(RFC 3558)に記述されているように、Oracle WebLogic SIP Server Containerは、TLSを使用するためにDiameter TCP接続を自動的にアップグレードする場合があります。

Diameterプロバイダで使用するTCPチャネルまたはTCP/TLSチャネルを構成するには、次の手順に従います。

1. Oracle WebLogic SIP Containerドメインの管理コンソールにアクセスします。

2. 「ロックして編集」をクリックし、構成ロックを取得します。

3. 左ペインで、構成する対象のサーバーの名前を選択します。

4. 右ペインで、「プロトコル」>「チャネル」を選択して、構成済のチャネルを表示します。

5. 「新規」をクリックして、新しいチャネルを構成します。

6. 「IDプロパティ」ページの各フィールドに、次の情報を入力します。

- 名前: このチャネルに付ける管理用の名前(たとえば「Diameter TCP/TLS Channel」)を入力します。

- プロトコル: TCPトランスポートのサポートに「diameter」、TCPおよびTLSトランスポートのサポートに「diameters」、またはTCPトランスポートのサポートに「diameter-sctp」を選択します。

注意:
TLSチャネルが1つでも構成されているサーバーはTLSモードで動作し、TLSをサポートしていないノードからのピア接続を拒否します(相手がTLSをサポートしているかどうかは、機能情報の交換時に確認されます)。

7. 「次へ」をクリックして続行します。

8. 「ネットワーク・チャネル」>「アドレス」ページの各フィールドに、次の情報を入力します。

- リスニング・アドレス: このチャネルのIPアドレスまたはDNS名を入力します。マルチ・ホーム・マシンの場合は、構成対象のインタフェースの正確なIPアドレス、またはその正確なIPアドレスにマッピングされているDNS名を入力します。

- リスニング・ポート: このチャネルを介した通信に使用するポート番号を入力します。Diameterノードでは、通常は着信接続ポートとしてポート3868が使用されます。

- 外部リスニング・ポート: リスニング・ポートの値を再入力します。

9. 「次へ」をクリックして続行します。

10. 以下のように「ネットワーク・チャネル・プロパティ」ページの属性を選択します。

- 有効化: 新しいチャネルがネットワーク・トラフィックの受信を確定するためにこの属性を選択します。

- トンネリング有効化: Diameterチャネルに対してこの属性の選択を解除します。

- このプロトコルでHTTPを有効化: Diameterチャネルに対してこの属性の選択を解除します。

- 発信の有効化: チャネルを使用してノードがDiameterメッセージを開始できるようにこの属性を選択します。

11. 「次へ」をクリックして続行します。

12. 「diameters」チャネルに対して、次の2つの属性を選択します。

- Two Way SSL Enabled:TLSトランスポートには双方向SSLが必要です。

- Client Certificate Enforced:安全な通信のために利用できるクライアント証明書を受け取るためにこの属性を選択します。

13. 「終了」をクリックして、新しいチャネルを作成します

14. ネットワーク・チャネル表に新たに作成されたチャネルの名前を選択します。

15. 「詳細設定」リンクをクリックして、新たに作成したチャネルの詳細な構成項目を表示します。

16. アイドル接続タイムアウトのデフォルト値(65秒)をより大きな値に変更して、Diameter接続を一貫して利用し続けられるようにします。

注意:
デフォルト値を変更しないと、アイドル状態の継続時間が65秒に達するたびにDiameter接続の切断と再確立が行われます。

17. 「保存」をクリックします。

18. 「変更のアクティブ化」をクリックします。

Diameterドメイン・テンプレートを使用してインストールされたサーバーでは、TCPトランスポートを使用するDiameter用のネットワーク・チャネルが構成されています。リレー・サーバーではdiameterチャネルのみが構成され、sipチャネルやsipsチャネルは含まれていません。リレー・エージェントはSIPサーブレットやその他のアプリケーションのホストとしては使用できないので、リレー・サーバー・ノード上ではSIPトランスポートを構成しないでください。

6.5.1 Diameter TLSチャネル用の双方向SSLの構成

TLS上のDiameterチャネル(diametersチャネル)を使用するには双方向SSLを有効にする必要があります。双方向SSLがデフォルトでは無効されています。サーバーで双方向SSLを有効にするには、前述の手順に従います。

6.5.2 DiameterメッセージングのためのSCTPの構成と使用

SCTPは、テレフォニ・ネットワークで使用するために設計された、メッセージに基づく信頼性の高いトランスポート・プロトコルです。SCTPはTCPに比べていくつかの利点があります。

- データをエンドポイントに送信する場合、SCTPはメッセージの内部構造を保存します。一方、TCPは順番に受信する必要のある生のバイトを送信します。

- SCTPはマルチ・ホームをサポートし、各エンドポイントに複数のIPアドレスを割り当てることができます。SCTPプロトコルは接続に失敗すると、他のIPアドレスに透過的にフェイルオーバーできます。

- SCTPはマルチ・ストリーミング機能を提供します。接続された複数のストリームは、互いに関係なくデータを送信します。

Oracle WebLogic SIP Containerは、Diameterネットワーク・トラフィック用のSCTPをサポートしますが、いくつかの制限があります。

- 現在サポートされているのは、接続ごとに1つのストリームだけです。

- SCTPはDiameterネットワーク・トラフィックにのみ使用できます。SIPトラフィックは設定されたSCTPチャネルを使用できません。

- TLSはSCTPでサポートされません。

さらに、Oracle WebLogic Server SIPは、次のソフトウェア プラットホームのSCTPチャネルのみサポートします。

- 32または64ビット・ハードウェア上のRed Hat Enterprise Linux 4.0 AS、ES、WS (カーネル2.6.9、GCC 3.4以上)

- SPARC上のSun Solaris 10

SCTPチャネルはIPv4またはIPv6いずれかのネットワークで動作できます。6.5項では、新しいSCTPチャネルの作成方法について説明します。既存のSCTPチャネルに対してマルチホーム機能を使用するには、IPv4・アドレス0.0.0.0をチャネルのリスニング・アドレスとして指定します(IPv6・ネットワークは::アドレスを使用します)。

6.6 Diameterノードの構成

Oracle WebLogic Server SIP ContainerエンジンのDiameterノード構成は、diameter.xml構成ファイルに保存されます。(domain_home/config/custom/diameter.xml)エンジン層サーバーでdiameterサービス(クライアント、サーバーまたはリレー機能)を提供するには、新しいノード構成を作成して、既存のエンジン・サーバー・インスタンスに適用する必要があります。

Diameterノード構成にはいくつかのカテゴリがあります。

- 一般的な構成は、ノードのホストIDおよびレルム、基本的な接続情報、デフォルト・ルーティング・ビヘイビアを定義します。

- アプリケーション構成は、ノードで実行されるDiameterアプリケーションと、それらのアプリケーションに渡されるオプションの構成パラメータを定義します。

- ピア構成は、このノードで動作する他のDiameterノードを定義します。

- ルート構成は、ノードがメッセージを解決するために使用できるレルム・ベースのルートを定義します。

次の節ではDiameterノードの各特徴を設定する方法について説明します。

6.6.1 新しいノード構成の作成(一般的なノード構成)

次の手順に従って、新しいDiameterノード構成を作成し、既存のOracle WebLogic Server SIP Containerエンジン層インスタンスに適用します。

1. 作成するOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。

2. 構成ロックを取得するには「ロックして編集」をクリックします。

3. コンソールの左ペインの「Diameter」ノードを選択します。

4. 新しいDiameter構成を作成するため右ペインの「新規」をクリックします。

5. 新規構成の作成ページのフィールドに表6-2に記述されているように入力して「終了」をクリックします。

表6-2 Diameterノード一般構成プロパティ

プロパティ名

説明

名前

このDiameterノード構成の管理名を入力します。

ホスト

このDiameterノードのホストIDを入力します。または、ターゲットとなるエンジン層サーバーのホスト名をDiameterノードのホストIDとして自動的に割り当てるには、フィールドを空白のままにします。このホストIDはDNS名と同じであっても違っていてもかまいません。

複数のshクライアント・ノードを対象にdiameterサポートを構成する場合は、diameter.xmlファイルのhost要素を省略することをお薦めします。これにより、同じDiameter Webアプリケーションをエンジン層クラスタのすべてのサーバーにデプロイできます。その際、各サーバー・インスタンスのホスト名が動的に取得されます。

レルム

このノードに対して責任があるレルム名を入力します。または、ターゲットとなるエンジン層サーバーの完全修飾ホスト名(例: host@oracle.com)のドメイン名を使用するには、フィールドを空白のままにします。

異なるレルムとリスニング・ポート番号を使用すると、同一ホスト上で複数のDiameterノードを実行できます。

注意: HSS、アプリケーション・サーバー、リレー・エージェントは、レルム名がすべて決められている必要があります。HSSとアプリケーション・サーバーのレルム名は一致する必要はありません。

アドレス

DNS名またはIPアドレスを使用して、このDiameterノードのリスニング・アドレスを入力します。または、ホストIDをリスニング・アドレスとして使用する場合はフィールドを空白のままにします。

注意: ホスト ID は Diameter ノードの DNS 名と同じであっても違っていてもかまいません。 構成エラーを回避するため、アドレス プロパティを明示的な DNS 名または IP アドレスで構成することをお薦めします。

TLS

DiameterノードをTLS(diameterのネットワーク・チャネル)サポートとともに構成する場合は、このオプションを選択します。このフィールドは、ノードが他のDiameterノードから問い合せるときにTLS機能を公開するために使用されます。

デバッグ

デバッグ・メッセージを出力するには、このオプションを選択します。デフォルトでは、デバッグ・メッセージの出力は無効化されています。

メッセージ・デバッグ

このノードで処理されるDiameterメッセージに対してトレーシングを使用する場合は、このオプションを選択します。デフォルトではメッセージ・トレーシングは無効です。

動的ピア使用可能

Diameterピア・ノードの動的な検索を可能にするには、このオプションを選択します。デフォルトでは、動的なピアは無効化されています。動的なピアを有効にするのは、TLSトランスポートを使用する場合のみにします。ピアになるホストを制限するためのアクセス制御メカニズムがないからです。

ピア再試行遅延

このノードがリクエストをDiameterピアに再リクエストするまでの時間を秒で入力します。デフォルト値は30秒です。

リクエストのタイムアウト

このノードがタイムアウトまで回答メッセージを待つ時間をミリセカンドで入力します。

ウォッチドッグ・タイムアウト

このノードがDiameter Tw watchdogタイマー間隔のため使用する秒数を入力します。

ターゲット

1つまたは複数のターゲット・エンジン層サーバー名を入力します。Diameterノード構成は、このフィールドで指定されたサーバーにのみ適用されます。

デフォルト・ルート・アクション

デフォルト・ルートを使用するときのこのDiameterノードのロールを説明するアクションのタイプを指定します。この要素には次の値のいずれかを指定できます。

- none

- local

- relay

- proxy

- redirect

デフォルト・ルート・サーバー

デフォルト・ルートに対して、1つまたは複数のターゲット・サーバーを指定します。この要素に含めるどのサーバーも、このDiameterノードのピアとしても定義されている必要があります。また、動的ピアのサポートが有効化されている必要があります。

6. 「変更のアクティブ化」をクリックして、ターゲット・サーバーに構成を適用します。

一般ノード構成を作成すると、Diameterノードのリストに構成名が表示されます。次の節に説明したように、Diameterアプリケーション、ピアおよびルートを構成するためにノードが選択できます。

6.6.2 Diameterアプリケーションの構成

各Diameterノードは、1つ以上のアプリケーションをデプロイできます。選択したDiameterノードに対して「構成」>「アプリケーション」ページを使用して、管理コンソールでDiameterアプリケーションを構成します。次の手順に従います。

1. 構成するOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。

2. 「ロックして編集」をクリックして構成ロックを取得します。

3. コンソールの左ペインの「Diameter」ノードを選択します。

4. コンソールの右ペインでDiameterノード構成の名前を選択します。

5. 「構成」>「アプリケーション」タブを選択します。

6. 「新規」をクリックして新しいDiameterアプリケーションを構成します。あるいは、既存のアプリケーション構成を表から選択します。

7. 以下のようにアプリケーション・プロパティを記入します。

- アプリケーション名: アプリケーション構成の名前を入力します。

- クラス名: このノードにデプロイするアプリケーションのクラス名を入力します。

- パラメータ: 起動するとアプリケーションに渡されるオプションのパラメータを入力します。

8. 「終了」をクリックして、新しいアプリケーション構成を作成します。

9. 「変更のアクティブ化」をクリックして、Diameterノードに構成を適用します。

Oracle WebLogic Server SIP Containerには複数のDiameterアプリケーションが含まれおり、Sh、Rf、Roインタフェイス、DiameterリレーおよびSh、Roインタフェースのシミュレータを使用するクライアントをサポートします。次の項では、こうしたOracle WebLogic Server SIP Container Diameterアプリケーションの構成について詳しく説明されています。

Oracle WebLogic Server SIP Containerに含まれる基本的Diameter APIを使用して、ユーザー独自のDiameterアプリケーションを作成するか、デプロイもできます。

6.6.2.1 Shクライアント・アプリケーションの構成

Shクライアント・アプリケーションは、プロバイダとしてプロファイル・サービスAPIに実装されています。このアプリケーションは、Shアプリケーション仕様で定義されているDiameterコマンド・コードに対して透過的に生成と応答を行います。プロファイル・サービスAPIにより、SIPサーブレットは、XMLドキュメント・オブジェクト・モデル(DOM)を使用してユーザー・プロファイル・データをXMLドキュメントとして管理することが可能となります。変更されたプロファイル・データに関する配信と通知を管理するには、SIPサーブレット内でプロファイル・リスナ・インタフェースを実装します。

Shクライアント・アプリケーションをデプロイするDiameterノードは、以下のように設定する必要があります。

- ドメインに設定された任意のリレー・エージェントのホスト名は、Diameterピア・ノードとして定義します。リレー・エージェントを1つも使用しない場合は、すべてのエンジン層サーバーをピアのリストに追加するか、または動的ピアを有効にする必要があります。

- ドメイン内のリレー・エージェント・ノード(またはHSS)には、1つまたは複数のルートがアクセスします。

Shクライアント・アプリケーションを構成するには、com.bea.wcp.diameter.sh.WlssShApplicationクラスを指定します。WlssShApplicationは、次のパラメータを受け取ります。

- destination.host: 目的のホストへの静的ルートを構成します。サーバーがリレー・エージェントなしに直接HSS(静的ルーティング)に通信する場合は、destination.hostパラメータ定義を含めます。リレー・エージェントを通じてルーティングする場合は、destination.hostパラメータを完全に削除します。

- destination.realm: 目的のレルムへの静的ルートを構成します。ドメインがリレー・エージェントを使用するかどうかに基づいて、リレー・エージェント・サーバーのレルム名またはHSSを指定します。

例6-2はリレーを使用するShクライアント・ノードのサンプル・ノードの構成を表しています。

例6-2 Shクライアント・アプリケーションでのDiameterノード構成のサンプル

<?xml version='1.0' encoding='utf-8'?>
<diameter xmlns="http://www.bea.com/ns/wlcp/diameter/300" xmlns:sec="http://www.bea.com/ns/weblogic/90/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls">
<configuration>
<name>hssclient</name>
<target>hssclient</target>
<host>hssclient</host>
<realm>oracle.com</realm>
<!-- Omit the host and realm elements to dynamically assign the host name
and domain name of individual engine tier servers. - >
<message-debug-enabled>true</message-debug-enabled>
<application>
<name>WlssShApplication</name>
<class-name>com.bea.wcp.diameter.sh.WlssShApplication</class-name>
<param>
<!-- Include a destination.host param definition only if servers will
communicate directly to an HSS (static routing), without using
a relay agent. Omit the destination.host param completely when
routing through relay agents. - >
<!-- Specify the realm name of relay agent servers or the HSS,
depending on whether or not the domain uses relay agents. - >
<name>destination.realm</name>
<value>hss.com</value>
</param>
</application>
<peer>
<!-- Include peer entries for each relay agent server used in the domain.
If no relay agents are used, include a peer entry for the HSS
itself, as well as for all other Sh client nodes (all other engine
tier servers in the domain).
Alternately, use the allow-dynamic-peers functionality in
combination with TLS transport to allow peers to be recognized
automatically. - >
<host>relay</host>
<address>localhost</address>
<!-- The address element can specify either a DNS name or IP address,
whereas the host element must specify a diameter host identity.
The diameter host identity may or may not match the DNS name. - >
<port>3869</port>
</peer>
<!-- Enter a default route to a selected relay agent. If the domain does
not use a relay agent, specify a default route to relay messages
directly to the HSS. - >
<default-route>
<action>relay</action>
<server>relay</server>
</default-route>
</configuration>
</diameter>

6.6.2.2 Rfクライアント・アプリケーションの構成

Oracle WebLogic Server SIP ContainerのRfクライアント・アプリケーションによってSIPサーブレットは、IMS Rfインタフェースを使用してオフライン・チャージング・メッセージを発行できるようになります。Rfアプリケーションを構成するには、com.bea.wcp.diameter.charging.RfApplicationクラスを指定します。Rfアプリケーションは次のパラメータを受け取ります。

- cdf.hostはチャージング・データ関数(CDF)のホスト名を指定します。

- cdf.realmはCDFのレルムを指定します。

6.6.2.3 Roクライアント・アプリケーションの構成

Oracle WebLogic Server SIP ContainerのRoクライアント・アプリケーションによってSIPサーブレットは、IMS Roインタフェースを使用してオンライン・チャージング・メッセージを発行できるようになります。Rfアプリケーションを構成するには、com.bea.wcp.diameter.charging.RoApplication.クラスを指定します。Roアプリケーションは、次のパラメータが受け取ります。

- ocs.hostはオンライン・チャージング・データ関数(OCF)のホストIDを指定します。指定されたOCFホストは、RoアプリケーションがデプロイされるDiameterノードのピアとして構成されていることが必要です。

- 1つ以上のOCFホストを使用する場合、ocs.realmをレルムベース・ルーティング用のocs.hostのかわりに使用できます。関連するレルム定義は、Diameterノードの構成にも含まれている必要があります。

6.6.2.4 Diameterリレー・エージェントの構成

Diameterの構成ではリレー・エージェントの使用は必須ではありませんが、HSSへの直接接続の数を制限し、障害の発生に備えてHSSへの複数のルートを確保するためにも、少なくとも2つのリレー・エージェント・サーバーを使用することをお薦めします。

注意:
Oracle WebLogic Server SIP Containerエンジン層サーバーまたはSIPデータ層サーバーとしてリレー・サーバーが動作していないことを確認してください。つまり、サーバーは「sip」または「sips」ネットワーク・チャネルとともに構成されないことが必要です。

リレー・エージェント・ノードはクライアント・ノードとHSSの間のShメッセージのルーティングを行いますが、Diameter Sh仕様で定義されている処理以外の変更をメッセージに加えることはありません。リレー・エージェントはHSSからのレスポンスを必ずそのメッセージの発信元のクライアント・ノードに返信し、そのノードに接続できないときは、その応答を破棄します。

Diameterリレー・エージェントを構成するには、com.bea.wcp.diameter.relay.RelayApplicationクラスでアプリケーションをデプロイするノードを単純に構成します。

リレー・アプリケーションをデプロイするノードも設定します。

- リレー・ノードへのピアとして他のすべてノード

- リレー・アクションを指定するデフォルト・ルート

例6-3では、リレー・エージェント・ノードのサンプルdiameter.xml構成を示しています。

例6-3 Diameterリレー・ノードの構成

<?xml version='1.0' encoding='utf-8'?>
<diameter xmlns="http://www.bea.com/ns/wlcp/diameter/300" xmlns:sec="http://www.bea.com/ns/weblogic/90/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls">
<configuration>
<name>relay</name>
<target>relay</target>
<host>relay</host>
<realm>oracle.com</realm>
<message-debug-enabled>true</message-debug-enabled>
<application>
<name>RelayApplication</name>
<class-name>com.bea.wcp.diameter.relay.RelayApplication</class-name>
</application>
<!-- Define peer connection information for each Diameter node, or use
the allow-dynamic-peers functionality in combination with TLS
transport to allow peers to be recognized automatically. - >
<peer>
<host>hssclient</host>
<address>localhost</address>
<port>3868</port>
</peer>
<peer>
<host>hss</host>
<address>localhost</address>
<port>3870</port>
</peer>
<route>
<realm>oracle.com</realm>
<application-id>16777217</application-id>
<action>relay</action>
<server>hssclient</server>
</route>
<!-- Enter a default route for this agent to relay messages
to the HSS. - >
<default-route>
<action>relay</action>
<server>hss</server>
</default-route>
</configuration>
</diameter>

6.6.2.5 ShおよびRfシミュレータ・アプリケーションの構成

Oracle WebLogic Server SIP Containerには、Diameterクライアント・アプリケーションを評価する開発やテスト環境において使用できる2つのシミュレータ・アプリケーションが含まれています。シミュレータ・アプリケーションを構成するには、関連するクラスを構成されたDiameterノードにデプロイします。

- com.bea.wcp.diameter.sh.HssSimulatorは、Shクライアント・アプリケーションをテストするため、ユーザーのドメインでHSSをシミュレートします。

- com.bea.wcp.diameter.rf.RfSimulatorは、Rfクライアント・アプリケーションをテストするため、CDFホストをシミュレートします。

注意:
こうしたシミュレータは、テストまたは開発目的でのみ提供されており、本番のHSSやCDFの代用として使用されることを想定していません。

シミュレータ・アプリケーションをデプロイするDiameterノードは、起動しているエンジン層サーバーのターゲットにすることが可能です。または、スタンドアロンDiameterノードとしても起動できます。スタンドアロン・モードで起動すると、シミュレータ・アプリケーションは表6-2に説明されたコマンドライン・オプションを取得します。

表6-3 シミュレータ・アプリケーションのコマンド・ライン・オプション

オプション

説明

-r, -realm realm_name

Diameterノードのレルム名を指定します。

-h, -host host_name

ノードのホストIDを指定します。

-a, -address address

このノードに対してリスニング・アドレスを指定します。

-p, -port port_number

このノードに対してリスニング・ポート番号を指定します。

-d, -debug

デバッグ出力を有効にします。

-m, -mdebug

Diameterメッセージ・トレーシングを有効にします。

6.6.2.6 ピア・ノードの有効化(Shバックエンド使用)

前述したように、Sh、Ro、Rfアプリケーションは、構成して別々に使用できますが、Shは、プロファイル・サーバーAPIを利用することが可能です。その手順は次のとおりです。

1. diameter.xmlにShApplicationを構成します(詳細は、例6-5を参照してください)。

2. domain_home/config/custom/profile.xmlにprofile.xmlファイルを追加します。Diameterドメインをテンプレートとしてインストールしファイルを修正するか、手動で例6-4に示すようにprofile.xmlを作成できます。

例6-4 profile.xmlサンプル

<profile-service xmlns="http://www.bea.com/ns/wlcp/wlss/profile/300">
<mapping>
<map-by>prefix</map-by>
<map-by-prefix>
<provider-prefix-set>
<name>sh</name>
<prefix>sh</prefix>
</provider-prefix-set>
</map-by-prefix>
</mapping>
<provider>
<name>sh</name>
<provider-class>com.bea.wcp.profile.ShProviderCached</provider-class>
</provider>
</profile-service>

6.6.3 ピア・ノードの構成

Diameterノードは、レルムにある互いのDiameterノードに対してピア接続情報を定義します。または、TLSトランスポートと組み合せて動的なピアの使用を可能にして、ピアが自動認識されるようにします。選択したDiameterノードに対して「構成」>ピアページを使用して、管理コンソールにDiameterピア・ノードが構成します。次の手順を実行します。

1. 作成するOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。

2. 「ロックして編集」をクリックして構成ロックを取得します。

3. コンソールの左ペインの「Diameter」ノードを選択します。

4. コンソールの右ペインでDiameterノード構成の名前を選択します。

5. 「構成」>ピアタブを選択します。

6. 「新規」をクリックして、新しいピア・エントリを定義します。

7. 「Create a New Peer」ページの各フィールドに、次の情報を入力します。

- ホスト: ピア・ノードのホストIDを入力します。

- アドレス: ピア・ノードのアドレス(DNS名またはIPアドレス)を入力します。

- ポート番号: ピア・ノードのリスニング・ポート番号を入力します。

- プロトコル: ピア(TCPまたはSCTP)で通信するために使用するプロトコルを選択します。

注意:
Oracle WebLogic Server SIP Containerは、指定されたプロトコル(TCPまたはSCTP)のみを使用してピアに接続しようと試行します。指定されたプロトコルでの通信に失敗しても、他のプロトコルは使用されません。プロトコルが指定されていない場合は、TCPがデフォルトで使用されます。

- ウォッチドッグ: ピアがDiameter Twウォッチドッグ・タイマー・インターバルをサポートするかどうかを指定します。

8. 「終了」をクリックして、新しいピア・エントリを作成します。

9. 「変更のアクティブ化」をクリックして、構成を適用します。

6.6.4 ルートの構成

リレーなどの特定のDiameterノードでは、Diameterメッセージを処理するたびに使用するためのレルム・ベース・ルートを構成する必要があります。選択したDiameterノードに対して「構成」>ルートページを使用して、管理コンソールにDiameterルートを構成します。次の手順を実行します。

1. 作成するOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。

2. 構成ロックを取得するには「Lock & Edit」をクリックします。

3. コンソールの左ペインの「Diameter」ノードを選択します。

4. コンソールの右ペインでDiameterノード構成の名前を選択します。

5. 「構成」>ルートタブを選択します。

6. 「新規」をクリックして、新しいルートを構成します。

7. 「Create a New Route」ページの各フィールドに、次の情報を入力します。

- 名前: ルートの管理名を入力します。

- レルム: このルートのターゲット レルムを入力します。

- アプリケーション ID: このルートに対するターゲットDiameterアプリケーション IDを入力します。

- アクション: 構成したルートを使用するたびこのノードが実行するアクションを選択します。アクション・タイプは、none、local、relay、proxyまたはredirectです。

- サーバー名: ルートを使用するターゲット・サーバーの名前を入力します。

8. 「終了」をクリックして、新しいルート・エントリを作成します。

9. 「変更のアクティブ化」をクリックして、構成を適用します。

ルート・エントリを含むdiameter.xmlノード構成の例については、例6-3を参照してください。

6.7 ドメイン構成の例

この項では、基本的なDiameter Shプロトコルの機能を提供するOracle WebLogic Server SIP Containerの構成サンプルを示します。サンプル・ドメインのレイアウトには次のサーバーが含まれます。

- SIPアプリケーションのホストである3つのエンジン層サーバー。これらのサーバーには、ユーザー・プロファイルにアクセスするためのDiameter Shアプリケーションもデプロイされます。

- 4つのSIPデータ層サーバー。2つのパーティションにそれぞれ2つのレプリカが含まれています。

- Diameterリレー・エージェントとして動作する2つのサーバー。これらのサーバーは、DiameterリクエストをHSSに転送する役割を果たします。

図6-1は、構成サンプルの個別のサーバーを示します。

図6-1 Diameterドメインの例

「図6-1 Diameterドメインのサンプル」の説明

例6-5は、サンプル・ドメインでエンジン層サーバー(Shクライアント)を構成するために使用するdiameter.xmlファイルの内容を示しています。例6-6はリレー・エージェントを構成するため使用するdiameter.xmlファイルを示しています。

例6-5 サンプル・エンジン層クラスタ(Sh クライアント)のdiameter.xml構成

<?xml version='1.0' encoding='utf-8'?>
<diameter xmlns="http://www.bea.com/ns/wlcp/diameter/300" xmlns:sec="http://www.bea.com/ns/weblogic/90/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls">
<configuration>
<name>clientnodes</name>
<target>Engine1</target>
<target>Engine2</target>
<target>Engine3</target>
<realm>sh_wlss.com</realm>
<application>
<name>WlssShApplication</name>
<class-name>com.bea.wcp.diameter.sh.WlssShApplication</class-name>
<param>
<name>destination.realm</name>
<value>relay_wlss.com</value>
</param>
</application>
<peer>
<host>Relay1</host>
<address>10.0.1.20</address>
<port>3821</port>
</peer>
<peer>
<host>Relay2</host>
<address>10.0.1.21</address>
<port>3821</port>
</peer>
<default-route>
<action>relay</action>
<server>Relay1</server>
</default-route>
<route>
<action>relay</action>
<server>Relay2</server>
</route>
</configuration>
</diameter>

例6-6 サンプル・リレー・エージェントのdiameter.xml構成

<?xml version='1.0' encoding='utf-8'?>
<diameter xmlns="http://www.bea.com/ns/wlcp/diameter/300" xmlns:sec="http://www.bea.com/ns/weblogic/90/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls">
<configuration>
<name>relaynodes</name>
<target>Relay1</target>
<target>Relay2</target>
<realm>relay_wlss.com</realm>
<application>
<name>RelayApplication</name>
<class-name>com.bea.wcp.diameter.relay.RelayApplication</class-name>
</application>
<peer>
<host>Engine1</host>
<address>10.0.1.1</address>
<port>3821</port>
</peer>
<peer>
<host>Engine2</host>
<address>10.0.1.2</address>
<port>3821</port>
</peer>
<peer>
<host>Engine3</host>
<address>10.0.1.3</address>
<port>3821</port>
</peer>
<peer>
<host>Relay1</host>
<address>10.0.1.20</address>
<port>3821</port>
</peer>
<peer>
<host>Relay2</host>
<address>10.0.1.21</address>
<port>3821</port>
</peer>
<peer>
<host>hss</host>
<address>hssserver</address>
<port>3870</port>
</peer>
<default-route>
<action>relay</action>
<server>hss</server>
</default-route>
</configuration>
</diameter>

6.8 Diameter構成のトラブルシューティング

Oracle WebLogic Server SIP ContainerにデプロイされたSIPサーブレットは、利用可能なDiameterアプリケーションを使用して、ユーザー・プロファイル・データ、アカウント情報、信用管理の要求の開始、あるいはプロファイル・データ変更の通知の配信や受信をすることができます。これらのリクエストを対応しているSIPサーブレットが、次のようなエラーを生じた場合：

Failed to dispatch Sip message to servlet ServletName
java.lang.IllegalArgumentException: No registered provider for protocol: Protocol

プロトコルの関連する Diameter アプリケーションを正しく構成していないことを示すメッセージが表示されます。 詳細は、6.6.2項「Diameter アプリケーションの構成」を参照してください。

Diameterピアノードへの接続に関するエラーが出る場合は、6.6.3項「ピア ノードの構成」で、ピアとの通信用の正しいプロトコルを構成しているか確認してください。Oracle WebLogic Server SIP Containerは、ピア設定で指定したプロトコル(プロトコルを指定していない場合は、TCP)のみ試行することに注意してください。

7 Oracle WebLogic Server SIP Containerベース・プラットフォームのトポロジ

次の項では、Oracle WebLogic Server SIP Containerアーキテクチャとデプロイメント・トポロジの概要について説明します。

- 7.1項「Oracle WebLogic Server SIP Containerベース・プラットフォームの目的」

- 7.2項「ロード・バランサ」

- 7.3項「エンジン層」

- 7.4項「SIPデータ層」

- 7.5項「地理的に冗長なインストール」

- 7.6項「ハードウェア構成の例」

- 7.7項「他の構成」

7.1 Oracle WebLogic Server SIP Containerベース・プラットフォームの目的

Oracle WebLogic Server SIP Containerは、SIPアプリケーションのデプロイを目的とした、高スケーラビリティの可用性に優れた高パフォーマンスのサーバーとして設計されています。OWLSCがJSR 289準拠の任意のSIPアプリケーションのデプロイに使用されます。

Oracle WebLogic Server SIP Containerアーキテクチャは、管理が容易で、利用可能なハードウェアに簡単に対応できます。基本的なアーキテクチャの構成要素は次のとおりです。

- 7.2項「ロード・バランサ」

- 7.3項「エンジン層」

- 7.4項「SIPデータ層」

図7-1は、基本的なOracle WebLogic Server SIP Containerインストールの構成要素を示します。次の項で、アーキテクチャの各構成要素について詳しく説明します。

図7-1 Oracle WebLogic Server SIP Containerアーキテクチャ

「図7-1 Oracle WebLogic Server SIP Containerアーキテクチャ」の説明

7.2 ロード・バランサ

ロード・バランサは、Oracle WebLogic Server SIP Container製品の一部として用意されているものではありませんが、Oracle WebLogic Server SIP Container製品インストールにおいては、1つまたは複数のロード・バランサが構成要素として不可欠です。ロード・バランサの主な目的は、単一のパブリック・アドレスで受け取ったSIPリクエストを、Oracle WebLogic Server SIP Containerエンジン層の利用可能なサーバーに分散させることです。リクエストの分散によって、Oracle WebLogic Server SIP Containerエンジンが最大限に活用されます。

ロード・バランサの多くには、構成可能なポリシーがあり、各マシンのキャパシティと可用性に応じて、またはインストールで必要なその他のロード・ポリシーに応じて、クライアント・リクエストを分散できるようになっています。ロード・バランサの中には、SIPネットワーク・トラフィックを管理するための追加の機能を備えているものがあります。たとえば、SIPメッセージのヘッダーに含まれている送信元のIPアドレスやポート番号などのフィールドに基づく、ルーティング・ポリシーのサポートなどです。ロード・バランサ製品の多くは、テレフォニ・ネットワーク向けのフォルト・トレランス機能も備えており、特定の呼出しへのSIPリクエストを、その呼出しが開始された同じエンジン層サーバーに常に転送するように構成することができます。

Oracle WebLogic Server SIP Containerインストールでは、ロード・バランサは、個々のサーバー(Oracle WebLogic Server SIP Containerソフトウェアまたはハードウェア)をアップグレードしたり、既存のSIPクライアントで混乱を起こずにアプリケーションをアップグレードしたりといった保守作業を実行するうえでも不可欠です。管理者は、ロード・バランサ・ポリシーを変更して、1つまたは複数のサーバーへのクライアント・トラフィックを他へ移動したうえで、使用していないサーバー・インスタンスに対し、必要なアップグレードを実行します。その後、アップグレードが済んだサーバーでクライアント・トラフィックが元どおりに処理されるよう、ロード・バランサ・ポリシーを再度変更します。

Oracleでは、Oracle WebLogic Server SIP Containerエンジン層でロード・バランサを設定し、基本的なロード分散を行うための詳細な情報を提供しています。Oracle WebLogic Server SIP Containerとともに使用するロード・バランサの構成の詳細は、3.2項「ロード・バランサのアドレスの構成」を参照してください。

7.3 エンジン層

エンジン層は、SIPクライアントに対して機能を提供するSIPサーブレットおよびその他のアプリケーションをホストするOracle WebLogic Server SIP Containerインスタンスのクラスタです。エンジン層は、SIPダイアログの状態について、永続的情報や一時的情報を格納しないステートレス・サーバーのクラスタです。そのかわりに、SIPダイアログに関するすべてのステートフルな情報は、SIPデータ層(7.4項)に格納されてそこから取得され、SIPセッション・データのレプリケーションおよびフェイルオーバー・サービスも提供されます。

エンジン層サーバーはSIPデータ層で管理するセッション・データの一部をキャッシュすることができます。キャッシュはSIP対応ロード・バランサを使用する構成に非常に便利です。詳細は、4.7項「エンジン層でのSIPデータのキャッシュ」を参照してください。

エンジン層の主な役割は、SIPクライアントに対し、最大限のスループットを実現し、レスポンス時間を短縮することです。システムが処理する呼出しの数や平均時間が増したときには、エンジン層にサーバー・インスタンスを簡単に追加して、負荷の増加に対応できます。

エンジン層は、複数のOracle WebLogic Server SIP Containerインスタンスで構成されますが、単一の論理エンティティとして処理します。SIPサーブレットのデプロイは、クラスタ自体をターゲットとすることにより、すべてのサーバー・インスタンスに対して均一に行われ、ロード・バランサは、SIPクライアントとエンジン層のサーバーとの間のアフィニティを維持する必要はありません。

注意:
Oracle WebLogic Server SIP Containerの開始スクリプトでは、パフォーマンスに影響する多くのJVMパラメータにデフォルト値が使用されています。たとえば、JVMのガベージ・コレクションやヒープ・サイズのパラメータが省略されていることや、評価や開発以外の目的には適切でない値を使用していることがあります。本番システムでは、十分なパフォーマンスを実現するために、様々なヒープ・サイズやガベージ・コレクションの設定でアプリケーションのプロファイリングを厳密に行う必要があります。本番ドメインでJVMのパフォーマンスを最大限に引き出す方法は、5.8項「本番デプロイメントにおけるJVMガベージ・コレクションのチューニング」を参照してください。
エンジン層ではSIPデータ層サーバーを利用して呼出し状態データを取得するので、エンジン層とSIPデータ層のマシンで2枚のギガ・ビット・イーサネット・ネットワーク・インタフェース・カード(NIC)を使用してネットワーク接続を二重化することをお勧めします。

7.4 SIPデータ層

SIPデータ層は、SIPサーブレットのセッション状態データを格納および取得するための、高いパフォーマンスと可用性に優れたインメモリー・データベースを提供するOracle WebLogic Server SIP Containerインスタンスのクラスタです。IPデータ層の目的は次のとおりです。

- Oracle WebLogic Server SIP Containerエンジン層のSIPアプリケーションが必要とするセッション・データを格納する、信頼性のある高いパフォーマンスのストレージを提供します。

- 同時呼出しのセッション状態に対応できるよう、ハードウェア・リソースとソフトウェア・リソースの規模を管理者が必要に応じて簡単に変更できるようにします。

SIPデータ層の中では、セッション・データは1つ以上の「パーティション」で管理され、各パーティションは同時呼出し状態の特定の部分を処理します。たとえば、2つのパーティションを使用するシステムの場合、1つ目のパーティションでは、同時呼出し状態の半分(AからMまでのセッション)を処理し、2つ目のパーティションでは、同時呼出し状態の残りの半分(NからZまでのセッション)を処理します。パーティションが3つの場合には、各パーティションは呼出し状態全体の3分の1ずつを処理します。大量の同時呼出しを管理するときには、必要に応じてパーティションを追加できます。簡単なハッシュ・アルゴリズムは、各呼出し状態が1つのSIPデータ層パーティションのみに一意に割り当てられているか確認するために使用します。

各パーティションには複数のサーバーを追加でき、パーティション内の他のサーバーで障害が発生した場合の冗長性とフェイルオーバーを提供できます。同じパーティションに複数のサーバーが属する場合、それらのサーバーは、各サーバーがパーティションの呼出し状態の複製コピーを処理するため、「レプリカ」と呼ばれます。たとえば、2パーティション・システムの最初のパーティションに2つのサーバーがあると、各サーバーはAからMの呼出し状態のレプリカを管理します。パーティション内の1つまたは複数のサーバーが起動しない場合やネットワークから切断されている場合、任意の使用可能なレプリカが呼出し状態のデータを自動的にエンジン層に提供します。2つのレベルの冗長性を提供するため、SIPデータ層には最大3つのレプリカを含めることができます。

高可用性のためのSIPデータ層の構成の詳細は、第4章「SIPデータ層のパーティションとレプリカの構成」を参照してください。

注意:
エンジン層ではSIPデータ層サーバーを利用して呼出し状態データを取得するので、エンジン層とSIPデータ層のマシンで2枚のネットワーク・インタフェース・カード(NIC)を使用してネットワーク接続を二重化することをお勧めします。

7.4.1 呼出し状態データの書込みと取得の例

初期のSIPメッセージを受信した場合は、Oracle WebLogic Server SIP Containerは、メッセージをエンジン層にデプロイされた適当なSIPサーブレットに送信するためにサーブレット・マッピング・ルールを使用します。エンジン層は、SIPダイアログに関するステートフルな情報を保持しません。そのかわりに、SIPトランザクション境界でエンジン層に呼出し状態を保存します。ハッシュ・アルゴリズムは、呼出し状態データを格納する1つのSIPデータ層パーティションを選択するために呼出し状態に適用します。次に、エンジン層サーバーは、そのパーティション内にある各レプリカの呼出し状態を「書き込み」、呼出し状態をロックします。たとえば、各パーティション内の2つのサーバーを使用するようにSIPデータ層を構成した場合、エンジン層はパーティション内の両方のレプリカへの接続を開き、各レプリカに呼出し状態を書き込み、ロックします。

デフォルト構成では、レプリカはメモリーにのみ(利用可能なRAM)呼出し状態情報を保持します。呼出し状態データをRDBMSに長期的に格納するように構成することもでき、地理的冗長性を実現するため、オフサイトのOracle WebLogic Server SIP Containerインストールに対して永続化することもできます。

SIPダイアログに対応して以降のSIPメッセージが生成された場合は、エンジン層はSIPデータ層から呼出し状態データを取得する必要があります。ハッシング・アルゴリズムを再度適用して、呼出し状態データを格納するパーティションを決定します。次に、エンジン層は、パーティション内の各レプリカのロックを解除し、呼出し状態データを取得するように求めます。そうすると、エンジン層上のサーブレットは呼出し状態データを更新することができます。

7.4.2 存続期間が長い呼出し状態データのRDBMSへの格納

Oracle WebLogic Server SIP Containerでは、長期間維持する呼出し状態データをOracle RDBMSに格納してRAMを節約することができます。呼出しダイアログの確立後、SIPデータ層では呼出し状態のデータをRDBMSに永続化し、呼出し状態を変更または削除するために、必要に応じて永続化された呼出し状態データを取得または削除します。詳細は、4.4項「長期間維持する呼出し状態データのRDBMSへの格納」を参照してください。

7.5 地理的に冗長なインストール

複数の地域データ・センターを持ち、サイトに致命的な障害が発生した場合も継続的に稼働を行う必要がある顧客のために、Oracle WebLogic Server SIP Containerは地理的に冗長な構成でインストールできます。地理的に冗長な構成は、複数のOracle WebLogic Server SIP Containerインストール(エンジンおよびSIPデータ層クラスタ)を有効にし、インストール間の呼出し状態トランザクションをレプリケートします。特定のサイトへのインストールがクリティカル障害に陥った場合は、管理者は呼出しの損失を最少限に留めるため、すべてのネットワーク・トラフィックをレプリケートされたセカンダリ・サイトにリダイレクトすることができます。詳細は、4.6項「地理的に冗長なSIPデータ層の使用」を参照してください。

7.6 ハードウェア構成の例

Oracle WebLogic Server SIP Containerアーキテクチャは柔軟であるため、高スループットや高可用性を提供するように、エンジン層およびSIPデータ層を様々な方法で構成できます。

7.7 他の構成

Oracle WebLogic Server SIP Containerの要件によっては、エンジン層とSIPデータ層に複数サーバーを配置してパフォーマンスと信頼性を高めることが必ずしも必要でない場合もあります。たとえば、開発用マシンの場合は、通常は複数サーバーのクラスタにではなく単一のサーバーにアプリケーションをデプロイしてテストする方が好都合です。

Oracle WebLogic Server SIP Containerでは、呼出し状態のレプリケーションが不要な場合には、エンジン層およびSIPデータ層のサービスを単一のサーバー・インスタンスと組み合せることができます。こうした組合せ層構成では、SIPサーブレット・コンテナの機能と、サーバーがホストするアプリケーション向けの呼出し状態処理の機能を、1つのOracle WebLogic Server SIP Containerインスタンスが兼任します。組合せ層構成は、開発やテストの目的で使用するのが一般的ですが、呼出し状態データのレプリケーションが必要ない場合には、本番環境でも使用できます。図7-2に、本番環境における複数の組合せ層サーバーのデプロイメント例を示します。

図7-2 SIP対応ロード・バランサを使用した単一サーバー構成

「図7-2 SIP対応ロード・バランサを使用した単一サーバーの構成」の説明

組合せ層サーバー・デプロイメントでは、各サーバーは、自らがホストするアプリケーションの呼出し状態のみを処理します。そのため、ロード・バランサは完全に「SIP対応」であることが必要です。つまり、ロード・バランサは、同じ呼出しに対する複数のリクエストを、同一のOracle WebLogic Server SIP Containerインスタンスに対してアクティブにルーティングする必要があります。同じ呼出しのリクエストが同一のサーバーに対応付けられない場合は、呼出し状態を取得できません。また、図7-2に示す構成においてOracle WebLogic Server SIP Containerインスタンスで障害が発生した場合は、そのサーバーによって処理されたすべての呼出しが失われるという点にも注意してください。

8 デプロイ済SIPアプリケーションのアップグレード

次の項では、アクティブ・コールを失わずに、デプロイ済SIPサーブレットおよびコンバージドSIP/HTTPアプリケーションを同じアプリケーションの新しいバージョンにアップグレードする方法について説明します。

- 8.1項「SIPアプリケーションのアップグレードの概要」

- 8.2項「デプロイ済アプリケーションをアップグレードする場合の要件と制限」

- 8.3項「デプロイ済SIPアプリケーションをアップグレードする手順」

- 8.4項「バージョン識別子の割当」

- 8.5項「更新バージョンのアプリケーションのデプロイ」

- 8.6項「以前のバージョンのアプリケーションのアンデプロイ」

- 8.7項「アップグレード処理のロールバック」

- 8.8項「アプリケーション名とバージョン識別子へのアクセス」

- 8.9項「管理モードの使用」

8.1 SIPアプリケーションのアップグレードの概要

Oracle WebLogic Server SIP Containerでは、アプリケーションで処理中の既存のコールを失わずに、デプロイ済SIPアプリケーションを新しいバージョンにアップグレードすることができます。このような形でアプリケーションのアップグレードを行うには、新しいバージョンのアプリケーションを以前のバージョンと並行してデプロイします。Oracle WebLogic Server SIP Containerは、新しいリクエストが新しいバージョンに転送されるようにSIPサーブレットのマッピングを自動的に管理します。確立されている既存のダイアログへのメッセージは、それ以降もコールが完了するまで以前のバージョンのアプリケーションに転送されます。既存のダイアログがすべて完了し、以前のバージョンのアプリケーションが処理するコールが完了した後で、そのアプリケーションを安全にアンデプロイします。

Oracle WebLogic Server SIP Containerのアップグレード機能を利用すると、本番アプリケーションのアップグレード中にコーるが失われることがなくなります。また、アプリケーションのアップグレードの処理を元に戻す(ロールバックする)こともできます。たとえば、新しいバージョンのデプロイ済アプリケーションに問題があることが判明した場合は、新しいバージョンをそのままアンデプロイし、以前のバージョンをアクティブにすることができます。

注意:
アプリケーションのアクティブなバージョンをアンデプロイすると、以前のアプリケーションのバージョンは管理モードのままになります。アプリケーションに新しいリクエストを転送するには、以前のバージョンを明示的にアクティブ化しなければなりません。

SIP管理チャネルでアップグレード機能を使用すると、最終テストへのアクセスを制限して新しいアプリケーション・バージョンをデプロイすることもできます。管理チャネルを使用して最終テストを行った後、アプリケーションを一般的なSIPトラフィックに開くことができます。

Oracle WebLogic Server SIP Containerアプリケーションのアップグレードは、Oracle WebLogic Server 10g リリース3アプリケーションのアップグレードと同一の機能を提供しますが、次の例外があります。

- Oracle WebLogic Server SIP Containerでは、以前のバージョンのアプリケーションの「正常な」リタイアをサポートしていません。かわりに、-retiretimeoutオプションをweblogic.Deployerに対して使用することによる、タイムアウト・ベースのアンデプロイメントのみをサポートします。

- SIPサーブレットまたはコンバージド・アプリケーションで管理モードを使用する場合は、TLSトランスポートを使用するsips-adminチャネルの構成が必要です。

- Oracle WebLogic Server SIP Containerは、レプリケートされた環境、また、レプリケートされない環境では、異なる方法でアプリケーションのアップグレードを処理します。レプリケートされた環境では、サーバーはweblogic.xml構成ファイルでsave-sessions-enabled要素がtrueに設定された場合と同じように動作します。これにより、再デプロイメント処理間のセッションを保持します。
レプリケートされない環境では、セッションは再デプロイメント後直ちに破棄されます。

8.2 デプロイ済アプリケーションをアップグレードする場合の要件と制限

Oracle WebLogic Server SIP Containerのアプリケーション・アップグレード機能を使用する場合の要件と制限は次のとおりです。

- 以前のバージョンのアプリケーションと区別するために、更新したアプリケーションにバージョン情報を割り当てる必要があります。バージョン情報の割当てが必要なのは、新しいバージョンのデプロイされたアプリケーションのみです。現在デプロイされているアプリケーションにバージョンの指定がない場合、Oracle WebLogic Server SIP Containerはそのアプリケーションを自動的に「以前の」バージョンとして処理します。詳細は、8.4項「バージョン識別子の割当」を参照してください。

- 同時にデプロイできるバージョン違いの同じアプリケーションは2つまでです。

- アプリケーション名の使用をハードコード化しているアプリケーション(たとえば、1つのコールを複数のSIPサーブレットで処理するように構成されたアプリケーション)の場合は、そのアプリケーション名を、基本アプリケーション名を取得するヘルパー・メソッドのコールで置き換える必要があります。WebLogic Serverには、基本アプリケーション名とバージョン識別子を取得するとともに、現在のバージョンのアプリケーションがアクティブかリタイア中かを確認するApplicationRuntimeMBeanメソッドが提供されています。詳細は、8.8項「アプリケーション名とバージョン識別子へのアクセス」を参照してください。

- アプリケーションが(アプリケーション構成手法を使用して)構成されたアプリケーションに参加するときに、基本名しか指定されていない場合は、Oracle WebLogic Server SIP Containerは常にアプリケーションの最新バージョンを使用します。

- 管理モードでアプリケーションをデプロイする場合、TLSトランスポートを使用するsips-adminチャネルの構成が必要です。

8.3 デプロイ済SIPアプリケーションをアップグレードする手順

デプロイ済SIPアプリケーションを新しいバージョンにアップグレードするには、次の手順に従います。

1. 「バージョン識別子の割当」-バージョン識別子を使って更新バージョンのアプリケーションをパッケージ化します。

2. 「更新バージョンのアプリケーションのデプロイ」-更新バージョンのアプリケーションを以前のバージョンと並行してデプロイし、アップグレード処理を開始します。

3. 「以前のバージョンのアプリケーションのアンデプロイ」-以前のバージョンのアプリケーションが確立されたコールへのすべてのSIPメッセージの処理を終了すると、そのバージョンを安全にアンデプロイすることができます。これにより、それ以降のすべてのコールの処理は、新しくデプロイされたアプリケーションに任されます。

次の項で、それぞれの手順について説明します。新しくデプロイされたアプリケーションで問題が検出した場合は、アップグレード処理をロールバックもできます。複数のSIPサーブレットで構成されるアプリケーションでは、アプリケーション名とバージョン識別子にアクセスするためにApplicationRuntimeMBeanを使用する必要がある場合もあります。

8.4 バージョン識別子の割当

Oracle WebLogic Server SIP Containerでは、アプリケーション名に追加されるバージョン識別子(文字列値)を使用して、同じアプリケーションの複数のバージョンを区別します。バージョン文字列には最大で215文字まで指定できます。表8-1に示す有効な文字以外しか使用できません。

表8-1 有効な文字と無効な文字

有効なASCII文字

無効なバージョン構成コンストラクト

a-z

..

A-Z

.

0-9

他の文字と組み合せたピリオド(「.」)、アンダースコア(「_」)、ハイフン(「-」)

デプロイ可能なSIPサーブレットWARファイルの場合、アプリケーションのMANIFEST.MFファイルでバージョン識別子を定義するか、デプロイメント時にコマンドラインで指定する必要があります。

8.4.1 マニフェストでのバージョンの定義

WARおよびEARデプロイメントでは、MANIFEST.MFファイルでバージョン識別子を指定する必要があります。例8-1に、バージョン識別子「v2」を指定したアプリケーションを表示します。

例8-1 マニフェストのバージョン識別子

Manifest-Version: 1.0
Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.)
Weblogic-Application-Version: v2

バージョン識別子を割り当てずにアプリケーションをデプロイし、後からバージョン識別子を割り当ててデプロイした場合、Oracle WebLogic Server SIP Containerはそれらのデプロイメントを同じアプリケーションの異なるバージョンとして認識します。

8.5 更新バージョンのアプリケーションのデプロイ

アップグレード処理を開始するには、管理コンソール、または、weblogic.Deployerユーティリティを使用して、更新したアプリケーション・アーカイブをデプロイします。一定の時間後に以前のバージョンのアプリケーションを自動的にアンデプロイするには、weblogic.Deployerユーティリティに-retiretimeoutオプションを使用します。例:

java weblogic.Deployer -name MyApp -version v2 -deploy -retiretimeout 7

Oracle WebLogic Server SIP Containerは、マニフェスト・ファイルでバージョン識別子を調べ、現在アプリケーションの他のバージョンがデプロイされているか確認します。2つのバージョンがデプロイされている場合、サーバーは最後にデプロイされたアプリケーションに自動的に新しいリクエストをルーティングし始めます。他のアプリケーションには新しい呼出しを転送せず、現在処理中の呼出しを完了できるようにします。最終的に、以前のバージョンのアプリケーションはSIPメッセージを処理しなくなるため、この処理は、以前のバージョンのアプリケーションの「リタイア」と呼ばれます。

Oracle WebLogic Server SIP Containerは、デプロイされている2つのアプリケーションの実際のバージョン文字列を比較して、どちらが新しいバージョンなのかを見分けるわけではありません。新しいコールは、常に最後にデプロイされたアプリケーションにルーティングされます。

Oracle WebLogic Server SIP Containerは、バージョン識別子が指定されていない(マニフェストにバージョン文字列がない)デプロイメントと、バージョン識別子が指定されたそれ以降のバージョンのデプロイメントとを区別することもできます。このため、8.4項「バージョン識別子の割当」で説明した方法でバージョン情報を指定し始める前にパッケージ化されたアプリケーションも簡単にアップグレードすることができます。

8.6 以前のバージョンのアプリケーションのアンデプロイ

既存のアプリケーションの新しいバージョンをデプロイした後、元のデプロイメントは、現在処理中のコール(元のデプロイメントを使用して開始されたコール)へのメッセージのみを処理するようになります。処理中のコールが完了した後は、元のデプロイメントは新しいSIPメッセージを処理しません。ほとんどの本番環境では、アプリケーションをアンデプロイする前に、元のデプロイメントがメッセージを処理していないことを確認する必要があります。

デプロイ済アプリケーションがメッセージを処理しているかどうかを確認するには、アプリケーションのSipApplicationRuntimeMBeanインスタンスからアクティブ・セッション・カウントを取得します。例8-2に、デフォルトの単一サーバー・ドメインのfindmeサンプル・アプリケーションのアクティブ・セッション・カウントを表示するWLSTコマンドのサンプルを示します。

アクティブなセッション数の値に基づいて、アプリケーションを安全にアンデプロイするか(処理中の呼出しは失われない)、強制的にアンデプロイするか(アンデプロイメントの時点でアクティブなセッションが失われる)を判断します。

正しいデプロイメント名をアンデプロイするには、管理コンソール、または、weblogic.Deployerユーティリティのいずれかを使用します。

例8-2 セッション・カウントを調べるWLSTセッションのサンプル

connect()
custom()
cd ('examples:Location=myserver,Name=myserver_myserver_findme_findme,ServerRuntime=myserver,Type=SipApplicationRuntime')
ls()
-rw-   ActiveAppSessionCount                        0
-rw-   ActiveSipSessionCount                        0
-rw-   AppSessionCount                              0
-rw-   CachingDisabled                              true
-rw-   MBeanInfo                                    weblogic.management.tools.In
fo@5ae636
-rw-   Name                                         myserver_myserver_findme_fin
dme
-rw-   ObjectName                                   examples:Location=myserver,N
ame=myserver_myserver_findme_findme,ServerRuntime=myserver,Type=SipApplicationRu
ntime
-rw-   Parent                                       examples:Location=myserver,N
ame=myserver,Type=ServerRuntime
-rw-   Registered                                   false
-rw-   SipSessionCount                              0
-rw-   Type                                         SipApplicationRuntime

-rwx   preDeregister                                void :

8.7 アップグレード処理のロールバック

アプリケーションの新しいバージョンをデプロイする場合や問題が見つかった場合は、次の手順に従ってアップグレード処理をロールバックすることもできます。

1. アクティブなバージョンのアプリケーションをアンデプロイします。

2. 以前のバージョンのアプリケーションをアクティブ化します。例:

java weblogic.Deployer -name MyApp -appversion v1 -start

注意:
アプリケーションのアクティブなバージョンをアンデプロイすると、以前のアプリケーションのバージョンは管理モードのままになります。アプリケーションに新しいリクエストを転送するために以前のバージョンを明示的にアクティブ化しなければなりません。

かわりに、-startオプションを使用すると、以前のバージョンのアプリケーションが起動して新しいリクエストを処理し、新しいバージョンがリタイアします。

8.8 アプリケーション名とバージョン識別子へのアクセス

Oracle WebLogic Server SIP Containerの製品アップグレード機能を利用する予定がある場合は、複数のSIPサーブレットで構成されるアプリケーションでアプリケーション名をハードコード化しないでください。アプリケーション名をハードコード化するかわりに、ApplicationRuntimeMBeanのいくつかのヘルパー・メソッドを使用することにより、アプリケーションからデプロイメント名、またはバージョン識別子に動的にアクセスできます。

8.9 管理モードの使用

オプションで、-adminmodeオプションとweblogic.Deployerを使用して、管理モードでアプリケーションの新しいバージョンをデプロイされます。管理モードでは、TLSトランスポートを持つsips-adminという構成されたネットワーク・チャネル名を介してのみSIPトラフィックを受け付けます。sips-adminチャネルが構成されていない場合、または、別のチャネルを使用してリクエストを受けた場合は、サーバーは503メッセージを返してリクエストを拒否します。

管理モードから一般に利用可能なモードにアプリケーションを遷移するには、weblogic.Deployerで-startオプションを使用します。

注意:
お使いのアプリケーションでTLSを使用できない場合は、サーブレット・ロール・マッピング・ルールを変更して1ユーザーしかアプリケーションの新しいバージョンを使用できないように設定することもできます。これにより、新しいバージョンへのアクセスを制限しながら、以前のバージョンと並行して新しいバージョンをデプロイすることができます。

A SIPサーブレット・コンテナ構成リファレンス

次の項では、sipserver.xmlというエンジン層構成ファイルの完全なリファレンスを提供します。

- A.1項「sipserver.xmlの概要」

- A.2項「sipserver.xmlの編集」

- A.3項「XMLスキーマ」

- A.4項「sipserver.xmlファイルの例」

- A.5項「XML要素の説明」

A.1 sipserver.xmlの概要

sipserver.xmlファイルは、サーバー・インストールのエンジン層でOracle WebLogic Server SIP Containerインスタンスによって提供されるSIPコンテナ機能を構成するXMLドキュメントです。sipserver.xmlは、DOMAIN_DIR/config/customサブディレクトリに保存されています。ここで、DOMAIN_DIRは、Oracle WebLogic Server SIP Containerドメインのルート・ディレクトリです。

A.2 sipserver.xmlの編集

通常操作中はsipserver.xmlの移動、変更、および削除は絶対に行わないでください。

ファイルを手動で編集するのではなく、管理コンソールを使用してsipserver.xmlを間接的に変更することをお薦めします。管理コンソールを使用すると、sipserver.xmlドキュメントが常に有効なXMLを含むことが保証されます。構成ガイドのWLST (JMX)の使用によるコンテナ・プロパティの構成に関する項を参照してください。

Oracle WebLogic Server SIP Containerのインストール時またはアップグレード時に、問題のある構成のトラブルシューティングを実行したり、破損したファイルを修復したり、あるいはカスタム構成を多数のマシンにロール・アウトしたりするには、sipserver.xmlを手動で表示または編集する必要があります。手動でsipserver.xmlを編集するとき、変更を適用するにはOracle WebLogic Server SIP Containerインスタンスを再起動する必要があります。

注意:
実行中のOracle WebLogic Server SIP Containerデプロイメントを変更するには、管理コンソールまたはWLSTユーティリティでSipServerノードを常に使用します。

A.2.1 sipserver.xmlの編集手順

本番システムでsipserver.xmlを変更する必要がある場合、次の手順に従います。

1. テキスト・エディタを使用し、DOMAIN_DIR/config/custom/sipserver.xmlファイルを開きます。ここで、DOMAIN_DIRは、Oracle WebLogic Server SIP Containerドメインのルート・ディレクトリです。

2. 必要に応じてsipserver.xmlファイルを変更します。XML要素の完全な説明は、A.3項「XMLスキーマ」を参照してください。

3. 変更を保存し、テキスト・エディタを終了します。

4. サーバーを再起動して、変更内容を有効にします。

注意:
実行中のOracle WebLogic Server SIP Containerデプロイメントを変更するには、管理コンソールまたはWLSTユーティリティでSipServerノードを常に使用します。

5. 更新後のシステムをテストして、構成を検証します。

A.3 XMLスキーマ

sipserver.xmlのwcp-sipserver.xsdというスキーマ・ファイルは、wlss-descriptor-binding.jarライブラリ内にインストールされ、WLSS_HOME/server/lib/wlssディレクトリに配置されます。

A.4 sipserver.xmlファイルの例

次は、sipserver.xmlファイルの単純な例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<sip-server xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<overload>
<threshold-policy>queue-length</threshold-policy>
<threshold-value>200</threshold-value>
<release-value>150</release-value>
</overload>
</sip-server>

A.5 XML要素の説明

次の項では、sipserver.xml構成ファイルで使用される各要素を説明します。各項は、図A-0で示される主なsip-server要素内に含まれるXML要素を説明します。

A.5.1 enable-timer-affinity

enable-timer-affinity要素は、エンジン層サーバーが期限切れのタイマーを処理する方法を決定します。(enable-timer-affinityがsipserver.xmlから省略されるか、または「false」に設定されるとき)デフォルトでは、期限切れのタイマーのSIPデータ層をポーリングするエンジン層サーバーは、すべての使用可能な期限切れタイマーを処理します。enable-timer-affinityが「true」に設定されているとき、SIPデータ層をポーリングするエンジン層サーバーは、エンジンが最後に変更された呼出し状態に関連付けられる期限切れのタイマー(または所有者がいない呼出し状態の期限切れのタイマー)のみ処理します。

A.5.2 overload

overload要素を使用すると、構成された過負荷状態に従って受信SIPリクエストを制限できます。過負荷状態が発生するとき、Oracle WebLogic Server SIP Containerは、構成されたリリース値が観察されるか、またはサーバーの容量制約サイズが削減されるまで、「503 Service Unavailable」を表示して新規SIPリクエストを破棄します(A.5.2.3項「容量制限に基づいた過負荷制御」を参照)。

ユーザーの構成による過負荷制御が適用されるのは、初期SIPリクエストのみです。過負荷条件が発生したときにすでにアクティブになっていたSIPダイアログは、規制されないSIPリクエストをさらに生成することがあります。

過負荷制御を構成するには、表A-1で説明されている3つの要素を定義します。

表A-1 ネストされたoverload要素

要素

説明

threshold-policy

過負荷条件のモニターに使われる測定のタイプを指定する文字列値。

- session-rateは、新規SIPリクエストが生成される率を測定します。Oracle WebLogic Server SIP Containerは、直近の5秒間の操作で作成された新規SIPアプリケーション接続数を計算することによって、セッション率を決定します。詳細は、A.5.2.2項「セッション生成率に基づいた過負荷制御」を参照してください。

- queue-lengthは、SIPリクエストおよびSIPタイマーを処理する容量の制約があるワーク・マネージャ・コンポーネントの合計サイズを測定します。詳細は、A.5.2.3項「容量の制約に基づいた過負荷制御」を参照してください。

- 注意： 実行キューは非推奨なので、Oracle WebLogic Server SIP Containerでは使用できません。容量の制約は実行キューのかわりに使用されます。「queue-length」というポリシー名は、下位互換性のために維持されました。

過負荷制御を定義するには、前述のポリシーの内いずれか1つのみ使用する必要があります。詳細は、A.5.2.1項「適切なオーバーロード・ポリシーの選択」を参照してください。

threshold-value

Oracle WebLogic Server SIP Containerが過負荷状態を認識し、新規SIPリクエストの制限を開始する測定値を指定します。

- session-rateのしきい値ポリシーを使用するとき、threshold-valueは、過負荷状態をトリガーする1秒ごとの新規SIPリクエスト数を指定します。詳細は、A.5.2.2項「セッション生成率に基づいた過負荷制御」を参照してください。

- queue-lengthのしきい値ポリシーを使用するとき、threshold-valueは、SIPトランスポートおよび過負荷状態をトリガーするSIPタイマーの容量の制約があるコンポーネントにおけるリクエストの組合せ数のサイズを指定します。詳細は、A.5.2.3項「容量の制約に基づいた過負荷制御」を参照してください。

- threshold-valueが観察された後、Oracle WebLogic Server SIP Containerは、最短で512ミリ秒の過負荷状態を認識します。新規SIPリクエストはこの間に制限されます。複数のオーバーロードが短期間に発生する場合、512 msの最短オーバーロードは、オーバーロードの繰り返しを避けるために動的に増加されます。

- 最短オーバーロード認識期間が期限切れになった後、構成されたrelease-valueが観察されると過負荷状態は終了されます。

release-value

Oracle WebLogic Server SIP Containerにオーバーロード条件および新しいSIPリクエストの規制を停止させる測定値を指定します。

- session-rateのしきい値ポリシーを使用するとき、release-valueは、セッション制限を終了する1秒ごとの新規SIPリクエスト数を指定します。詳細は、A.5.2.2項「セッション生成率に基づいた過負荷制御」を参照してください。

- queue-lengthのしきい値ポリシーを使用するとき、release-valueは、セッション制限を終了する容量の制約におけるリクエストの組合せ数を指定します。詳細は、A.5.2.3項「容量の制約に基づいた過負荷制御」を参照してください。

A.5.2.1 適切なオーバーロード・ポリシーの選択

Oracle WebLogic Server SIP Containerは、SIPリクエストを制限するための2種類のポリシーを提供します。

- session-rateポリシーは、新しいSIPセッションの構成率(1秒当たりのセッション数)に達したときセッションを規制します。

- queue-lengthポリシーは、wlss.connectワーク・マネージャとwlss.timer.capacity容量制限コンポーネントの合計サイズが構成されたサイズに達した後、リクエストを規制します。

利用可能なオーバーロード・ポリシーは1つしか選択できません。同時に両方のポリシーを使用することはできません。

既知の最大スループット(RDBMSなど)を持つバックエンド・リソースがSIP呼出しの設定に使用されている場合は、session-rateポリシーが―般的に使用されます。この場合は、session-rateポリシーを使用すると、バックエンド・リソースの既知のスループット機能にOracle WebLogic Server SIP Containerオーバーロード・ポリシーを関連付けることができます。

queue-lengthポリシーでは、Oracle WebLogic Server SIP Containerはオーバーロード状態を診断するためCPUとI/Oボトル・ネックの両方をモニターします。queue-lengthポリシーは、一般的に呼出し率に関連付けられた予測可能な上限を持たないシステム内でCPU集中SIPアプリケーションとともに使用されます。

以下、これらのポリシーについて詳しく説明します。

A.5.2.2 セッション生成率に基づいた過負荷制御

Oracle WebLogic Server SIP Containerは、直前の5秒間に作成されたアプリケーション・セッションの数をモニターすることで、セッション生成率(1秒当たりのセッション数)を計算します。セッション生成率がthreshold-valueで指定された率を超えると、Oracle WebLogic Server SIP Containerは初期SIPリクエストを規制し、セッション生成率がrelease-valueで指定された値より小さくなるまでこの規制を続けます。

次の例では、50セッション/秒 を超える率で新しいセッションが作成されたときOracle WebLogic Server SIP ContainerがSIPリクエストの規制を開始するように設定しています。この規制はセッション生成率が40セッション/秒まで低下したときに終了します。

<overload>
<threshold-policy>session-rate</threshold-policy>
<threshold-value>50</threshold-value>
<release-value>40</release-value>
</overload>

A.5.2.3 容量の制約に基づいた過負荷制御

デフォルトでは、SIPメッセージはwlss.connectという名前のワーク・マネージャによって処理され、SIPタイマーはwlss.timerという名前のワーク・マネージャによって処理されます。各ワーク・マネージャは、SIPメッセージの処理およびタイマーの処理に割り当てられたリクエスト数を設定する関連付けられた容量の制約があるコンポーネントを含みます。ワーク・マネージャは、Oracle WebLogic Server SIP Containerのconfig.xmlファイルで構成されます。また、-Dweblogic.threadpool.MinPoolSize=number_of_threadsという起動オプションを使用して、起動時に追加スレッドをサーバーに追加できます。

Oracle WebLogic Server SIP Containerは、構成容量制限の合計長をモニターすることにより、queue-length過負荷制御を行います。この2つの制限の合計長がthreshold-value要素で指定された長さを超えると、Oracle WebLogic Server SIP Containerは初期SIPリクエストを規制し、合計長がrelease-valueで指定された値まで減少するまでこの規制を続けます。

例A-1は、sipserver.xmlからのサンプルoverload構成を示します。ここで、Oracle WebLogic Server SIP Containerは、制約の組合せサイズが200回のリクエスト数を超過するとき、SIPリクエストの制限を開始します。組み合された長さが200以下の同時リクエスト数に戻るとき、制限は中断されます。

例A-1 overload定義のサンプル

<overload>
<threshold-policy>queue-length</threshold-policy>
<threshold-value>200</threshold-value>
<release-value>150</release-value>
</overload>

A.5.2.4 過負荷保護の2つのレベル

ユーザーが構成したオーバーロード制御は(sipserver.xmlに定義されたように)Oracle WebLogic Server SIP Containerで供給された過負荷保護の最初の重大度レベルを示します。ユーザーが構成したオーバーロード制御は、オーバーロード条件の起動をマークし、ドロップされた呼出しを回避する単純な対策を開始します(新しいリクエストに対して503のレスポンスを生成)。

オーバーロードの原因となった条件が永続化したり悪化した場合は、SIPサーブレット・コンテナでワークの実行に使用するワーク・マネージャ・コンポーネント自体がオーバーロードとなる可能性があります。この時点でサーバーは503レスポンスの生成にスレッドの使用をやめ、そのかわりにドロップ・メッセージを開始します。このように、SIPコンテナのワーク・マネージャ・コンポーネントの構成サイズは、サーバーで使用する過負荷保護の2番目の最終レベルを示します。

sipserver.xmlにおいてはオーバーロード制御を慎重に構成し、適宜オーバーロードを引き起こした状況を解決します。

A.5.3 message-debug

message-debug要素は、Oracle WebLogic Server SIP Containerのログ・ローテーションを使用したアクセス・ロギングの有効化および構成に使用されます。この要素は、アクセス・ロギングがすべてのSIPリクエストおよびレスポンスをロギングするため、開発環境でのみ使用する必要があります。

A.5.4 プロキシ: アウトバウンド・プロキシ・サーバーの設定

RFC 3261では、アウトバウンド・プロキシを「リクエスト-URIによって解決されるサーバーではない場合でも、クライアントからリクエストを受信するプロキシ。通常、UAはアウトバウンド・プロキシを使用して手動で構成されるか、または自動構成プロトコルを通して認識できます」と定義しています。

Oracle WebLogic Server SIP Containerでは、アウトバウンド・プロキシ・サーバーは、sipserver.xmlでproxy要素を使用して指定されます。proxy要素は、1つ以上のプロキシ・サーバーのURIを定義します。proxy-policyタグを使用してプロキシ・ポリシーを設定することによって、プロキシ・プロセスの動作を変更できます。例A-0は、使用可能なproxy要素の値を説明しています。

デフォルト動作は、proxyポリシーが実施されているようなものです。proxyポリシーとは、リクエストが構成されたアウトバウンド・プロキシへ送信され、リクエストのルート・ヘッダーがOracle WebLogic Server SIP Containerによって実行されるルーティング判定を保存することを意味します。これによって、アウトバウンド・プロキシは、リクエスト上でアクションを実行した後に、リクエストを指定した受信者に送信できるようになります。proxyポリシーは、初期リクエストにのみ有効です。後続のリクエストに関しては、ルート設定がダイアログの任意のポリシー全体に優先します。(アウトバウンド・プロキシがルート設定になる場合、レコード・ルーティングをオンにできます。)

また、Oracle WebLogic Server SIP Containerで書き込まれたプロキシ・アプリケーションが、アウトバウンド・プロキシ・トラバースの構成された動作をオーバーライドきする場合、名前が「X-BEA-Proxy-Policy」で値が「domain」の特別なヘッダーを追加できます。このヘッダーは送信中にリクエストから削除されますが、その効果は構成されたアウトバウンド・プロキシを無視することです。X-BEA-Proxy-Policyというカスタム・ヘッダーは、リクエストごとの原則に基づいて構成されたポリシーをオーバーライドするために、アプリケーションによって使用されます。ヘッダーの値は「domain」または「proxy」にできます。ただし、ポリシーがオーバーライドされて「proxy」になる場合、アウトバウンド・プロキシへルーティングするために、構成はアウトバウンド・プロキシのURIを持つ必要があります。

表A-2 ネストされたproxy要素

要素

説明

routing-policy

プロキシの動作を構成する省略可能な要素。有効な値は次のとおりです。

- domain: RFC 3261によって定義されたルーティング・ルールを使用してメッセージをプロキシし、指定されるアウトバウンド・プロキシを無視します。

- proxy: メッセージをデフォルトのプロキシURIで指定されたダウンストリーム・プロキシへ送信します。複数のプロキシ指定がある場合、指定される順番で試行されます。ただし、トランスポートがUDPプロキシを試行する場合、後続のプロキシの設定は無視されます。

uri

プロキシ・サーバーのTCPまたはUDPのURI。proxy要素には1つ以上のURIを指定する必要があります。複数のURIをproxy要素内の複数のuri要素に配置します。

例A-2は、Oracle WebLogic Server SIP Containerドメインのデフォルト・プロキシ構成を示します。この場合のリクエストは、SIPルーティング・ルールに従って作成され、最終的にリクエストは「sipoutbound.oracle.com」というアウトバウンド・プロキシへ送信されます。

例A-2 サンプルのproxy定義

<proxy>
<routing-policy>proxy</routing-policy>
<uri>sip:sipoutbound.oracle.com:5060</uri>
<!-- Other proxy uri tags can be added. - >
</proxy>

A.5.5 t1-timeout-interval

この要素はSIPプロトコルT1タイマーの値(ミリ秒単位)を設定します。タイマーT1はタイマーA、E、およびGの初期値も指定します。これらのタイマーによってUDPによるINVITEリクエストとレスポンスの再送信の間隔が決定されます。

また、タイマーT1はタイマーF、H、およびJの値に影響を与え、これらの値はINVITEリクエスト/レスポンスの再送信間隔を制御します。タイマーの値は64*T1ミリ秒に設定されます。SIPタイマーの詳細は、「SIP: Session Initiation Protocol」を参照してください。

t1-timeout-intervalが構成されていない場合、Oracle WebLogic Server SIP Containerは、SIPプロトコルのデフォルト値である500ミリ秒を使用します。

A.5.6 t2-timeout-interval

この要素は、SIPプロトコルのT2タイマーの値をミリ秒単位で設定します。タイマーT2は、INVITEレスポンスおよびINVITE以外のリクエストの再送信間隔を定義します。SIPタイマーの詳細は、「SIP: Session Initiation Protocol」を参照してください。

t2-timeout-intervalが構成されていない場合、Oracle WebLogic Server SIP Containerは、SIPプロトコルのデフォルト値である4秒を使用します。

A.5.7 t4-timeout-interval

この要素は、SIPプロトコルのT4タイマーの値をミリ秒単位で設定します。タイマーT4は、メッセージがネットワーク内に留まる時間の最大長を指定します。また、タイマーT4はタイマーIおよびKの初期値も指定し、これらの値はUDP経由のACKおよびレスポンスの再送信を待機する時間を制御します。

t4-timeout-intervalが構成されていない場合、Oracle WebLogic Server SIP Containerは、SIPプロトコルのデフォルト値である5秒を使用します。

A.5.8 timer-b-timeout-interval

この要素は、SIPプロトコルのタイマーBの値をミリ秒単位で設定します。タイマーBは、クライアント・トランザクションがリクエストの送信を再試行する時間の長さを指定します。

timer-b-timeout-intervalが構成されていない場合、タイマーBの値はタイマーT1から取得されます(64*T1、またはデフォルトでは32000ミリ秒)。

A.5.9 timer-f-timeout-interval

この要素は、SIPプロトコルのタイマーFの値をミリ秒単位で設定します。タイマーFは、INVITE以外のリクエストを再送信するタイムアウト間隔を指定します。

timer-f-timeout-intervalが構成されていない場合、タイマーFの値はタイマーT1から取得されます(64*T1、またはデフォルトでは32000ミリ秒)。

A.5.10 max-application-session-lifetime

この要素は、Oracle WebLogic Server SIP Containerがセッションを無効にするまでに、SIPアプリケーション・セッションが存続時間の最大値を分単位で指定します。max-application-session-lifetimeは、sip.xmlファイルでsession-timeout要素を使用するか、またはsetExpires APIを使用することによって、任意のタイムアウト値の上限として機能します。

-1 (デフォルト)は、構成したタイムアウト値に対する上限が存在しないことを示します。

A.5.11 enable-local-dispatch

enable-local-dispatchはサーバーの最適化で、メッセージの送信時および転送時に不要なネットワーク・トラフィックを避けるのに役立ちます。この要素を「true」に設定すると最適化を有効にできます。enable-local-dispatchが有効化されるとき、サーバー・インスタンスがメッセージを送信または転送し、メッセージの宛先がエンジン層クラスタ・アドレスまたはローカル・サーバー・アドレスの場合に、メッセージはネットワーク経由で送信されず、ローカル・サーバーへ内部ルーティングされます。この最適化を使用すると、連鎖アプリケーションが同一リクエストを処理するとき、パフォーマンスを動的に向上できます。

内部メッセージのルーティングがエンジン層のサーバーの負荷を歪めるような気がして、構成されたロード・バランサを通じてすべてのリクエストをルーティングしたいと思うなら、この最適化を無効にするほうがよいでしょう。

デフォルトでは、enable-local-dispatchは「false」に設定されます。

A.5.12 cluster-loadbalancer-map

cluster-loadbalancer-map要素は、Oracle WebLogic Server SIP Containerソフトウェアをアップグレードするとき、または本番SIPサーブレットを新しいバージョンへアップグレードするときにのみ使用されます。通常のサーバー操作では不要または使用されません。

ソフトウェアのアップグレード時には、ソフトウェアの古いバージョンと新しいバージョンをホストするために複数のエンジン層クラスタを定義します。A cluster-loadbalancer-mapは、アップグレード用に構成したエンジン層クラスタに対応する仮想IPアドレスを定義します(ロード・バランサ上で定義)。Oracle WebLogic Server SIP Containerはこのマッピングを使用して、呼出し状態データとタイマーに対するエンジン層リクエストが間違いなくクラスタの正しい「バージョン」から受信されるようにします。リクエストがソフトウェアの間違ったバージョンから来た場合、cluster-loadbalancer-mapエントリが使用され、そのリクエストを正しいクラスタに転送します。

それぞれのcluster-loadbalancer-mapエントリには、表A-1で説明されている2つの要素が含まれます。

表A-3 ネストされたcluster-loadbalancer-map要素

要素

説明

cluster-name

エンジン層クラスタの構成された名前。

sip-uri

エンジン層クラスタにマップする内部SIP URI。これはロード・バランサで構成した仮想IPアドレスに対応します。内部URIはアップグレード時にリクエストを正しいクラスタ・バージョンに転送するために使用されます。

例A-3は、アップグレード時に使用されるサンプルのcluster-loadbalancer-mapエントリを示します。

例A-3 cluster-loadbalancer-mapサンプルのエントリ

<cluster-loadbalancer-map>
<cluster-name>EngineCluster</cluster-name>
<sip-uri>sip:172.17.0.1:5060</sip-uri>
</cluster-loadbalancer-map>
<cluster-loadbalancer-map>
<cluster-name>EngineCluster2</cluster-name>
<sip-uri>sip:172.17.0.2:5060</sip-uri>
</cluster-loadbalancer-map>

詳細については、 オペレーション・ガイド の 「 ソフトウェアのアップグレード」 を参照してください。

A.5.13 default-behavior

この要素は、サーバーが受信SIPリクエストをデプロイ済SIPサーブレットに照合できない場合(または照合アプリケーションが無効になっているかタイムアウトの場合)、Oracle WebLogic Server SIP Containerインスタンスのデフォルト動作を定義します。有効な値は次のようです。

- proxy: プロキシ・サーバーとして機能します。

- ua: ユーザー・エージェントとして機能します。

proxyは、値を指定しない場合にデフォルトとして使用されます。

ユーザー・エージェント(UA)として機能するとき、Oracle WebLogic Server SIP Containerは、SIPリクエストに応答して次のように動作します。

- ACKリクエストは通知なしに破棄されます。

- CANCELまたはBYEリクエストはレスポンス・コード481 (トランザクションが存在しない)を受け取ります。

- それ以外のすべてのリクエストはレスポンス・コード500 (内部サーバー・エラー)を受け取ります。

プロキシとして機能するとき、構成済の場合にリクエストはアウトバウンド・プロキシ(A.5.4項「proxy: アウトバウンド・プロキシ・サーバーの設定」を参照)へ自動的に転送されます。プロキシが定義されていない場合、Oracle WebLogic Server SIP Containerは、リクエストURIがSIPサーブレット・コンテナの既知のローカル・アドレスまたはサーバーに構成されたロード・バランサ・アドレスのIPおよびポート番号に一致しない場合のみ、指定されたリクエストURIへプロキシします。これによって、リクエストが同一のサーバーへ継続してループしないことが保証されます。リクエストURIがローカル・コンテナ・アドレスまたはロード・バランサ・アドレスに一致するとき、Oracle WebLogic Server SIP ContainerはかわりにUAとして機能します。

A.5.14 default-servlet-name

この要素は、受信初期リクエストがデプロイ済サーブレットに照合できない場合、呼び出すデフォルトのSIPサーブレットの名前を指定します(sip.xmlで標準のservlet-mapping定義を使用します)。default-servlet-name要素で指定された名前は、デプロイされたSIPサーブレットのservlet-nameの値に一致する必要があります。例:

<default-servlet-name>myServlet</default-servlet-name>

default-servlet-nameで定義される名前がデプロイ済サーブレットに一致しない場合、または値が指定されていない場合(デフォルト構成)、Oracle WebLogic Server SIP Containerはcom.bea.wcp.sip.engine.BlankServletという名前をデフォルト・サーブレットとして登録します。default-servlet-nameとして登録されたデプロイ済のサーブレットがコンテナからデプロイ解除される場合、BlankServletという名前も使用されます。

BlankServletの動作は、default-behavior要素を使用して構成されます。デフォルトでは、サーブレットはすべての一致しないリクエストをプロキシします。ただし、default-behavior要素が「ua」モードに設定されている場合、BlankServletは、CANCELおよびBYEリクエストに対して481レスポンスを戻し、その他のすべての場合には500/416レスポンスを戻します。BlankServletはACKに応答せず、常にアプリケーション・セッションを無効にします。

A.5.15 retry-after-value

5xxレスポンスのRetry-Afterヘッダーで使用される秒数を指定します。この値は、「Retry-After: 18000;duration=3600」または「Retry-After: 120 (I'm in a meeting)」などのパラメータまたは理由コードも含みます。

この値が構成されていない場合、Oracle WebLogic Server SIP Containerは、デフォルト値の180秒を使用します。

A.5.16 sip-security

Oracle WebLogic Server SIP Containerを使用すると、認証が実行される1つ以上の信頼できるホストを構成できるようになります。Oracle WebLogic Server SIP ContainerがSIPメッセージを受信するとき、SIPサーブレット・メッセージ上でgetRemoteAddress()を呼び出します。このアドレスがサーバーの信頼できるホスト・リストで定義されたアドレスと一致する場合、メッセージの認証は実行されません。

sip-security要素は、認証が実行されない1つ以上の信頼できるホストを定義します。sip-security要素には、1つ以上のtrusted-authentication-hostまたはtrusted-charging-host要素が含まれ、それぞれには信頼できるホスト定義が含まれます。信頼できるホスト定義は、IPアドレス(ワイルドカード・プレースホルダを含む/含まない)またはDNS名から構成されます。例A-4は、サンプルsip-security構成を示します。

例A-4 信頼できるホスト構成のサンプル

<sip-security>
<trusted-authentication-host>myhost1.mycompany.com</trusted-authentication-host>
<trusted-authentication-host>172.*</trusted-authentication-host>
</sip-security>

A.5.17 route-header

3GPP TS 24.229 Version 7.0.0 (http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-700.zip)は、新規リクエスト(B2BUAなど)を生成するIMSアプリケーション・サーバーが、S-CSCFルート・ヘッダーを含むことを要求します。Oracle WebLogic Server SIP Containerでは、S-CSCFルート・ヘッダーは、sipserver.xmlでroute-headerの値として静的に定義される必要があります。例:

<route-header>
<uri>Route: sip:wlss1.bea.com</uri>
</route-header>

A.5.18 engine-call-state-cache-enabled

Oracle WebLogic Server SIP Containerは、SIPを認識できるロード・バランサを使用してパフォーマンスを向上するために、エンジン層サーバーが呼出し状態データの一部をローカルおよびSIPデータ層にキャッシュするためのオプションも提供します。ローカル・キャッシュが使用されるとき、エンジン層サーバーはまず既存の呼出し状態データのローカル・キャッシュをチェックします。キャッシュに必要なデータが含まれ、データのローカル・コピーが(SIPデータ層コピーに比べて)最新の場合、エンジンはSIPデータ層の呼出し状態をロックしますが、そのキャッシュから直接読み取ります。

デフォルトでは、エンジン層キャッシュは有効化されています。キャッシュを無効化するには、engine-call-state-cache-enabledをfalseに設定します。

<engine-call-state-cache-enabled>false</engine-call-state-cache-enabled>

A.5.19 server-header

Oracle WebLogic Server SIP Containerを使用すると、サーバー・ヘッダーがSIPメッセージに挿入されるタイミングを制御できるようになります。この機能を使用して、ワイヤレス・ネットワークのメッセージ・サイズを削減したり、セキュリティを向上したりするために、サーバー・ヘッダーを制限または削除できます。

デフォルトでは、Oracle WebLogic Server SIP Containerはサーバー・ヘッダーをSIPメッセージに挿入しません。この動作を構成するには、server-headerを次の文字列値のいずれかに設定します。

- none (デフォルト)は、サーバー・ヘッダーを挿入しません。

- requestは、サーバーによって生成されたSIPリクエストに対してのみサーバー・ヘッダーを挿入します。

- responseは、サーバーによって生成されたSIPレスポンスに対してのみサーバー・ヘッダーを挿入します。

- allは、すべてのSIPリクエストおよびレスポンスに対してサーバー・ヘッダーを挿入します。

たとえば、次の要素は、すべての生成されたSIPメッセージに対してサーバー・ヘッダーを挿入するようにOracle WebLogic Server SIP Containerを構成します。

<server-header>all</server-header>

詳細は、A.5.20項「server-header-value」を参照してください。

A.5.20 server-header-value

Oracle WebLogic Server SIP Containerを使用すると、生成されたメッセージのサーバー・ヘッダーに挿入されるテキストを制御できるようになります。これによって、SIPメッセージのサイズ全体を追加で制御し、また、セキュリティ上の目的からサーバー・エンティティをマスクできるようになります。デフォルトでは、Oracle WebLogic Server SIP Containerは、サーバー・ヘッダーを生成されたSIPメッセージに挿入しません(A.5.19項「server-header」を参照)。サーバー・ヘッダーの挿入が有効化されていても、server-header-valueが指定されていない場合、Oracle WebLogic Server SIP Containerは「WebLogic SIP Server」という値を挿入します。ヘッダー・コンテンツを構成するには、文字列値を入力します。例:

<server-header-value>MyCompany Application Server</server-header-value>

A.5.21 persistence

persistence要素は、RDBMSまたは地理的に冗長なリモートのOracle WebLogic Server SIP Containerインストール(あるいはその両方)への呼出し状態データの書込みを、有効化/無効化することを定義します。地理的に冗長なレプリケーション機能を活用するサイトでは、persistence要素は、呼出し状態データを保持する対象のサイトIDおよびURLも定義します。

persistence要素には、表A-1で説明されているサブ要素が含まれます。

表A-4 ネストされたpersistence要素

要素

説明

default-handling

Oracle WebLogic Server SIP Containerが、RDBMS永続性または地理的冗長性(あるいはその両方)の永続性ヒントを保持するかどうかを決定します。この要素は、次の値のいずれかを持ちます。

- all: 呼出し状態データが、RDBMS保存域および地理的に冗長なOracle WebLogic Server SIP Containerインストールの両方に対して保持できることを指定します。これはデフォルトの動作です。また、いずれかの宛先の実際のレプリケーションでは、使用可能なリソース(JDBCデータソースおよびリモートJMSキュー)が使用できる必要があります。

- db: 必要なJDBCデータソースおよびスキーマが使用可能な場合、存続期間の長い呼出し状態データがRDBMSへレプリケートされることを指定します。

- geo: 構成されたサイトURLに必要なJMSリソースが含まれる場合、呼出し状態データが地理的に冗長なリモート・サイトへ保持されることを指定します。

- none: メモリー内のレプリケーションのみがSIPデータ層クラスタの他のレプリカへ実行されることを指定します。呼出し状態データは、RDBMSにも外部サイトにも保持されません。

geo-site-id

このインストールのサイトIDを指定します。地理的に冗長なレプリケーションに属するすべてのインストールは一意なサイトIDが必要です。

geo-remote-t3-url

このサイトが呼出し状態データをレプリケートする先のリモートOracle WebLogic Server SIP Containerインストールを指定します。リモート・インストールのエンジン層クラスタに対応する単一のURLを指定できます。また、各エンジン層サーバーに対応するアドレスのカンマ区切りリストも指定できます。URLはt3プロトコルを指定する必要があります。

例A-5は、存続期間の長い呼出し状態のRDBMSストレージおよび地理的に冗長なレプリケーションを使用するサンプル構成を示します。呼出し状態はリモート・ロケーションの2つのエンジン層サーバーへレプリケートされます。

例A-5 persistence構成のサンプル

<persistence>
<default-handling>all</default-handling>
<geo-site-id>1</geo-site-id>
<geo-remote-t3-url>t3://remoteEngine1:7050,t3://remoteEngine2:7051</geo-remote-t3-url>
</persistence>

A.5.22 use-header-form

この要素は、SIPメッセージにコンパクト・ヘッダーを使用または保持するためのサーバー全体のデフォルト動作を構成します。この要素は、次のいずれかの値に設定できます。

- compact: Oracle WebLogic Server SIP Containerは、システムが生成したヘッダーのすべてに圧縮形式を使用します。ただし、発信元のメッセージからコピーされるヘッダー(生成されたものではない)は、元の形式を使用します。

- force compact: Oracle WebLogic Server SIP Containerは、すべてのヘッダーに圧縮形式を使用し、既存メッセージのロング・ヘッダーを必要に応じて圧縮ヘッダーに変換します。

- long: Oracle WebLogic Server SIP Containerは、システムが生成したヘッダーのすべてに詳細形式を使用します。ただし、発信元のメッセージからコピーされるヘッダー(生成されたものではない)は、元の形式を使用します。

- force long: Oracle WebLogic Server SIP Containerは、すべてのヘッダーに詳細形式を使用し、既存メッセージの圧縮ヘッダーを必要に応じてロング・ヘッダーに変換します。

A.5.23 enable-dns-srv-lookup

この要素は、Oracle WebLogic Server SIP ContainerのDNS参照機能を有効化/無効化します。この要素を「true」に設定する場合、サーバーは次の目的でDNSを使用できます。

- リクエストがSIP URIに送信されるとき、プロキシ・サーバーのトランスポート、IPアドレス、およびポート番号を検出します。

- 「Sent-by」フィールドの内容に基づいて、レスポンスのルーティングの際にIPアドレスとポート番号を解決します。

プロキシの検出では、Oracle WebLogic Server SIP Containerは、トランスポート、IP、およびポート番号情報を判定するためにSIPトランザクションごとに1回のみDNS解決を使用します。すべての再送信、ACK、またはCANCELリクエストは、同一のトランスポートを使用して同一のアドレスおよびポートに送信されます。DNS解決発現の方法に関する詳細は、RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers (http://www.ietf.org/rfc/rfc3263.txt)を参照してください。

レスポンス・メッセージの送信にプロキシが必要なとき、Oracle WebLogic Server SIP Containerは、Sent-byフィールドおよびヘッダーによって提供される情報に応じて、宛先のIPアドレスまたはポート番号(あるいはその両方)を決定するためにDNS参照を使用します。

デフォルトでは、DNS解決は使用されません(「false」)。

注意:
DNS解決はSIPメッセージ処理のコンテキスト内で実行されるため、どのようなDNSパフォーマンス問題でも待機時間パフォーマンス増加の原因となります。潜在的なパフォーマンス問題を削減するために本番環境ではキャッシングDNSサーバーを使用することをお勧めします。

A.5.24 connection-reuse-pool

Oracle WebLogic Server SIP Containerには、接続プール・メカニズムが含まれます。このメカニズムは、SBC (Session Border Control)機能またはS-CSCF (Serving Call Session Control Function)を使用して通信オーバーヘッドを最小化するために使用できます。接続の複数の固定プールを異なるアドレスに構成できます。

Oracle WebLogic Server SIP Containerは、サーバーが構成されたアドレスにリクエストを送信する必要に応じて、接続プールから新規接続を開きます。次に、サーバーは、新規接続の終了と再作成を繰り返さずに、すでに開かれた接続を使用して新規SIPリクエストをアドレスへ多重送信します。開かれた接続はラウンドロビン方式で再使用されます。開かれた接続は、リモート・アドレスによって明示的に閉じられるまで開いたままになります。

接続再使用プールは、構成されたアドレスからの受信リクエストには使用されません。

接続再使用プールを構成するには、表A-1で説明されているネストされた4つの要素を定義します。

表A-5 ネストされたconnection-reuse-pool要素

要素

説明

pool-name

文字列の値はこのプールの名前を識別します。すべての構成されたpool-name要素は、ドメインに対して一意である必要があります。

destination

宛先SBCまたはS-CSCFのIPアドレスおよびホスト名を指定します。Oracle WebLogic Server SIP Containerは、リクエストを構成されたアドレスに送信するときのみ、このプールで接続を開くか、または再使用します。

destination-port

送信先SBCまたはS-CSCFのポート番号を指定します。

maximum-connections

このプールで保持する開いた接続の最大数を指定します。

例A-6は、2つのプールを持つconnection-reuse-pool構成のサンプルを示します。

例A-6 connection-reuse-pool構成のサンプル

<connection-reuse-pool>
<pool-name>SBCPool</pool-name>
<destination>MySBC</destination>
<destination-port>7070</destination-port>
<maximum-connections>10</maximum-connections>
</connection-reuse-pool>
<connection-reuse-pool>
<pool-name>SCSFPool</pool-name>
<destination>192.168.1.6</destination>
<destination-port>7071</destination-port>
<maximum-connections>10</maximum-connections>
</connection-reuse-pool>

A.5.25 globally-routable-uri

この要素を使用すると、ネットワーク要素との通信時にOracle WebLogic Server SIP Containerが自動的に連絡先およびルート設定ヘッダーに挿入するGRUU (Globally-Routable User Agent URI)を指定できます。この要素で指定されるURIは、Oracle WebLogic Server SIP Containerクラスタ全体のGRUUである必要があります。(単一サーバーのドメインでは、サーバー自体にGRUUを使用します)

Oracle WebLogic Server SIP Containerでデプロイ済ユーザー・エージェント(UA)は、通常、登録リクエスト経由でGRUUを取得します。この場合、アプリケーション・コードはGRUUのリクエストおよび後続の処理を実行します。GRUUをリクエストするには、UAが、GRUUがリクエストされる各Contactで「+sip.instance」という連絡先ヘッダー・フィールドのパラメータを含む必要があります。GRUUを受信すると、UAは新規リクエストを生成するときに連絡先ヘッダー・フィールドのURIとしてGRUUを使用します。

A.5.26 domain-alias-name

この要素は、Oracle WebLogic Server SIP Containerが実行する1つ以上のドメインを定義します。メッセージが、domain-alias-nameを使用して指定されたドメインに一致する宛先ドメインを持つ場合、Oracle WebLogic Server SIP Containerは、メッセージを転送せずにローカルで処理します。

sipserver.xml構成ファイルは、複数のmain-alias-name要素を持つ可能性があります。各要素は次のいずれかを指定できます。

- myserver.mycompany.comなどの個別の完全修飾ドメイン名、または

- *.mycompany.comなどの先頭がワイルドカード文字で始まるドメイン名。これはすべての照合ドメインを表すために使用されます。単一のワイルドカード文字のみサポートされているため、ドメイン名の最初の要素として使用する必要があります。

注意:
また、これらのドメイン名をSipServer管理コンソール拡張の「構成」>「全般」タブの「ドメイン別名」フィールドを使用して識別できます。

A.5.27 enable-rport

この要素は、Oracle WebLogic Server SIP Containerが、UACとして機能するときに自動的にrportパラメータをViaヘッダーに追加するかどうかを決定します。デフォルトでは、サーバーはrportパラメータを追加しません。この要素を「true」に設定すると、自動的にrportがサーバーによって生成されたリクエストに追加されます。

注意:
また、SipServer管理コンソール拡張の「構成」>「全般」タブの「対称レスポンス・ルーティング」オプションを選択することによって、このパラメータを「true」に設定できます。

rportパラメータは、RFC 3581 (http://www.ietf.org/rfc/rfc3581.txt)で説明されているように、対称レスポンス・ルーティングに使用されます。メッセージが、Oracle WebLogic Server SIP ContainerなどのRFC 3581に準拠したサーバーによって受信されるとき、サーバーは、Viaヘッダーで指定されたポート番号ではなく、メッセージが受信されたリモートUDPポート番号を使用して応答します。この動作は、ネットワーク・アドレス変換(NAT)を実行するゲートウェイ・デバイスの背後にサーバーが存在するときによく使用されます。NATデバイスは内部および外部のポート番号間のバインドを維持するため、すべての通信はゲートウェイ・ポート経由で発信される必要があります。

Oracle WebLogic Server SIP ContainerはRFC 3581に準拠しているため、enable-rport要素を「false」に設定する場合でも、rportパラメータを適用します。enable-rport要素は、サーバーが自動的にrportを、サーバーがUACとして機能するときに生成するリクエストへ追加するかどうかのみを指定します。rport処理を完全に無効化(RFC 3581対応を無効化)するには、-Dwlss.udp.uas.rport=falseというコマンドライン・オプションを使用してサーバーを起動する必要があります。

注意:
RFC3581で説明されるrportサポートは、元のSIPリクエストのソース・ポートを含むSIPレスポンスを必要とします。ソース・ポート情報は極秘データとして扱われることが多いので、TLSトランスポートを使用することをお薦めします。

A.5.28 image-dump-level

この要素は、Oracle WebLogic Server SIP Containerの診断イメージ・ファイルに記録する詳細レベルを指定します。この要素を次の2つの要素のいずれかに設定できます。

- basic: 呼出し状態データ以外のすべての診断データを記録します。

- full: 呼出し状態データを含むすべての診断データを記録します。

注意:
イメージ・ファイルへの呼出し状態データの記録には、時間がかかることがあります。デフォルトでは、イメージ・ダンプ・ファイルはbasicオプションを使用して記録されます。
また、SipServer管理コンソール拡張の「構成」>「全般」タブを使用してこのパラメータを設定できます。

A.5.29 stale-session-handling

Oracle WebLogic Server SIP Containerは、メッセージに関連付けられた呼出し状態およびアプリケーション・セッションを識別するために、エンコードされたURIを使用します。アプリケーションがデプロイ解除されるか、または新しいバージョンへアップグレードされるとき、受信リクエストは、呼出し/セッションIDが「無効」または存在しないことを指定するエンコードされたURIを持つ場合があります。stale-session-handling要素を指定すると、Oracle WebLogic Server SIP Containerがリクエスト内で無効なセッション・データを検出するときに、実行するアクションを構成できるようになります。次のアクションが可能です。

- drop: エラーをロギングせずにメッセージを削除します。この設定は、Oracle WebLogic Server SIP Containerのインプレース・アップグレード機能を使用してアプリケーションを頻繁にアップグレードするシステムに理想的です。dropアクションを使用すると、デプロイされたアプリケーションの古くて互換性がないバージョンを対象とするメッセージが削除されることが保証されます。

- error: UACが問題を修正するように、エラーを含めて応答します。これはデフォルトのアクションです。To:タグを含むメッセージは、481 Call/Transaction Does Not Existエラーを表示し、このタグを含まないメッセージは404 Not Foundエラーを表示します。

- continue: 古いセッション・データを無視し、リクエストの処理を継続します。

注意:
古いセッション・データを検出するとき、Oracle WebLogic Server SIP Containerは、default-behavior要素の値を考慮する前に、stale-session-handlingによって指定されたアクションを適用します。これは、default-behaviorが、continueアクションを実行するためにstale-session-handlingを構成したときにのみ実行されることを意味します。

A.5.30 enable-contact-provisional-response

デフォルトでは、Oracle WebLogic Server SIP Containerは、Toヘッダーを含む信頼性の低い暫定(1xx)レスポンスにContactヘッダーを配置しません。Contactヘッダーがそのような1xxレスポンスに存在することを期待するアプリケーションをデプロイする場合、この要素をtrueに設定します。

<enable-contact-provisional-response>true</enable-contact-provisional-response>

この要素をtrueに設定しても、100回試行のレスポンスには影響しません。

A.5.31 app-router

app-routerスタンザには、SIP Servlet v1.1アプリケーション・ルーター動作を構成するいくつかの要素が含まれます。詳細は、A.5.32項「use-custom-app-router」、A.5.33項「app-router-config-data」、A.5.34項「custom-app-router-jar-file-name」、およびA.5.35項「default-application-name」を参照してください。

A.5.32 use-custom-app-router

use-custom-app-router要素は、Oracle WebLogic Server SIP Containerが、custom-app-router-jar-file-name要素を使用して指定するデフォルト、組込みアプリケーションAR (AR)、またはカスタムARを使用するかどうかを決定します。デフォルト値の「false」を指定すると、サーバーはデフォルトARを使用するように構成します。

A.5.33 app-router-config-data

app-router-config-data要素は、initメソッドでデフォルトまたはカスタム・アプリケーション・ルーター(AR)へ渡すプロパティを定義します。すべての構成プロパティはJavaプロパティ形式に準拠する必要があり、各プロパティは改行やスペースなしに個別に1行で入力される必要があります。DARプロパティは、http://jcp.org/en/jsr/detail?id=289の付録Cで説明されている詳細プロパティ形式に準拠する必要があります。例A-7は、構成例を示します。

例A-7 app-router-config-data要素のサンプル

<?xml version='1.0' encoding='UTF-8'?>
<sip-server xmlns="http://www.bea.com/ns/wlcp/wlss/300" xmlns:sec="http://www.bea.com/ns/weblogic/90/security" xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<app-router>
<use-custom-app-router>false</use-custom-app-router>
<app-router-config-data>INVITE:("OriginatingCallWaiting","DAR:From","ORIGINATING","","NO_ROUTE","0"),("CallForwarding","DAR:To","TERMINATING","","NO_ROUTE","1")
SUBSCRIBE:("CallForwarding","DAR:To","TERMINATING","","NO_ROUTE","1")</app-router-config-data>
<custom-app-router-jar-file-name></custom-app-router-jar-file-name>
<default-application-name></default-application-name>
</app-router>
</sip-server>

-Djavax.servlet.sip.ar.dar.configurationというJavaオプションを含めることによって、Oracle WebLogic Server SIP Containerインスタンスの起動時に、任意でAR初期化プロパティを指定できます。(プロパティ・ファイルを指定するには、URIではなく、file:///という接頭辞を含めます)Java起動オプションを指定する場合、コンテナはapp-router-config-dataで指定された構成プロパティをすべて無視します。プロパティはいつでも変更できますが、-Djavax.servlet.sip.ar.dar.configurationオプションを省略してサーバーが再起動されるまで、プロパティはARへ渡されません。

A.5.34 custom-app-router-jar-file-name

custom-app-router-jar-file-name要素は、JARファイルとしてパッケージ化された使用するカスタム・アプリケーション・ルーター(AR)のファイル名を指定します。カスタムAR実装は、$DOMAIN_HOME/approuterサブディレクトリに配置される必要があります。

A.5.35 default-application-name

default-application-name要素は、カスタム・アプリケーション・ルーター(AR)が初期リクエストを処理するためのアプリケーションを検出できないとき、コンテナが呼び出すデフォルト・アプリケーション名を指定します。デフォルト・アプリケーションが指定されていない場合、ARがアプリケーションを選択できないとコンテナは500エラーを戻します。

注意:
アプリケーション名をデフォルト・アプリケーション名の値として指定する前に、アプリケーションをデプロイする必要があります。

B SIPデータ層構成リファレンス

次の項では、SIPデータ層構成ファイル(datatier.xml)の完全なリファレンスを提供します。

- B.1項「datatier.xmlの概要」

- B.2項「datatier.xmlの編集」

- B.3項「XMLスキーマ」

- B.4項「datatier.xmlファイルの例」

- B.5項「XML要素の説明」

B.1 datatier.xmlの概要

datatier.xml構成ファイルは、SIPアプリケーションの同時呼出し状態を管理するサーバーを識別し、これらのサーバーをSIPデータ層のパーティションに配置する方法を定義します。パーティションは、呼出し状態の同一部分を管理する1つ以上のSIPデータ層のサーバー・インスタンスを参照します。同一パーティション内の複数のサーバーは、呼出し状態の同一部分のコピーをすべて管理するため、レプリカとして参照されます。

datatier.xmlは、DOMAIN_DIR/config/customサブディレクトリに保存されます。ここで、DOMAIN_DIRは、Oracle WebLogic Server SIP Containerドメインのルート・ディレクトリです。

B.2 datatier.xmlの編集

管理コンソールまたはテキスト・エディタのいずれかを使用して、datatier.xmlを編集できます。SIPデータ層構成に対する変更は、サーバーに動的に適用できないので注意してください。SIPデータ層のメンバーシップの変更またはパーティションの再構成のためには、サーバーを再起動する必要があります。

B.3 XMLスキーマ

このスキーマ・ファイルは、wcp-sipserver.xsdライブラリ内にバンドルされ、WLSS_HOME/server/lib/wlssディレクトリにインストールされます。

B.4 datatier.xmlファイルの例

例B-1は、構成ウィザードを使用して作成されたテンプレートdatatier.xmlファイルを示します。

例B-1 デフォルトのdatatier.xmlファイル

<st:data-tier xmlns:st="http://www.bea.com/ns/wlcp/wlss/300">
<st:partition>
<st:name>partition-0</st:name>
<st:server-name>replica1</st:server-name>
<st:server-name>replica2</st:server-name>
</st:partition>
</st:data-tier>

B.5 XML要素の説明

datatier.xmlには、SIPデータ層のパーティションでサーバーのメンバーシップを定義する1つ以上のpartition要素が含まれます。すべてのSIP層のクラスタは、1つ以上のpartitionを持つ必要があります。各パーティションには、表B-0で説明されているXML要素が含まれます。

表B-1 ネストされたパーティション要素

要素

説明

name

文字列の値はパーティション名を識別します。管理するために(0から始まる)パーティション数を名前のテキストに含めることをお薦めします。たとえば、 「partition-0」。

server-name

このパーティションで呼出し状態を管理するOracle WebLogic Server SIP Containerのインスタンス名を指定します。partition要素ごとに3つまでサーバーを定義できます。同一のパーティション内の複数のサーバーは、同一の呼出し状態データを保持し、レプリカとして参照されます。

管理するために(0から始まる)サーバー数およびパーティション数をサーバー名に含めることをお薦めします。たとえば、「replica-0-0」。

C Diameter構成リファレンス

次の項では、Diameterの構成ファイルであるdiameter.xmlへの完全なリファレンスを提供します。

- C.1項「diameter.xmlの概要」

- C.2項「グラフィカル表現」

- C.3項「diameter.xmlの編集」

- C.4項「XMLスキーマ」

- C.5項「diameter.xmlファイルの例」

- C.6項「XML要素の説明」

C.1 diameter.xmlの概要

diameter.xmlファイルには、次のようなDiameterノードの属性が構成されています。

- Diameterノードのホスト・アイデンティティ

- ノードにデプロイされているDiameterアプリケーション

- Diameterピア・ノードの接続情報

- Diameterメッセージの処理に使用されるルーティング情報とデフォルト・ルート

Diameterプロトコルの実装は起動時に構成ファイルを読み込みます。diameter.xmlはDOMAIN_DIR/config/customサブディレクトリに格納されます。DOMAIN_DIRはOracle WebLogic Server SIP Containerドメインのルート・ディレクトリです。

C.2 グラフィカル表現

図C-1はdiameter.xmlファイルの要素の階層を示しています。

図C-1 diameter.xmlの要素階層

「図C-1 diameter.xmlの要素階層」の説明

C.3 diameter.xmlの編集

通常の操作中に、diameter.xmlファイルを移動、変更や削除しません。

手動ではなく管理コンソールの使用で間接的にdiameter.xmlファイルを変更することをお薦めします。管理コンソールを使用してdiameter.xmlドキュメントは常に有効なXMLが含まれていることを保証します。

Oracle WebLogic Server SIP Containerのインストールやアップグレードの場合に、diameter.xmlを手動で表示や編集して問題の構成をトラブルシューティングし、破損したファイルを修復して、または多数のマシンにカスタムDiameterノード構成をロールアウトする必要があります。diameter.xmlを手動で編集する場合に、Diameterノードを再起動して変更を適用する必要があります。

注意:
構成ガイドに説明したエンジン層コンテナのプロパティの構成によって、常に管理コンソールでのDiameterノードまたはWLSTユーティリティを使用して実行中のOracle WebLogic Server SIP Containerのデプロイメントを変更します。

C.3.1 diameter.xml編集の手順

本番システム上でdiameter.xmlを変更するには、次の手順を実行します。

1. テキスト・エディタを使用してDOMAIN_DIR/config/custom/diameter.xmlファイルを開きます。DOMAIN_DIRはOracle WebLogic Server SIP Containerドメインのルート・ディレクトリです。

2. 必要に応じてdiameter.xmlファイルを変更します。XML要素の詳細な説明は、C.6項「XML要素の説明」を参照してください。

3. 変更を保存してテキスト・エディタを終了します。

4. サーバーを再起動して、変更内容を有効にします。

注意:
構成ガイドに説明したエンジン層コンテナのプロパティの構成によって、常に管理コンソールでの直径ノードまたはWLSTユーティリティを使用して実行中のOracle WebLogic Server SIP Containerのデプロイメントを変更します。

5. 更新後のシステムをテストして、構成を検証します。

C.4 XMLスキーマ

XMLスキーマ・ファイル(wcp-diameter.xsd)がWLSS_HOME/server/lib/wlssディレクトリにインストールされているwlssdiameter.jarライブラリ内にバンドルされます。

C.5 diameter.xmlファイルの例

diameter.xml構成ファイル例の複数のリストは、ネットワーク・リソースの構成のDiameter Shクライアント・ノードとリレー・エージェントの構成を参照してください。

C.6 XML要素の説明

次の項では、diameter.xmlの各XML要素を説明します。

C.6.1 構成

最上位のconfiguration要素には、全体のDiameterノード構成が含まれています。

C.6.2 ターゲット

ノード構成が適用されている1つ以上のターゲットOracle WebLogic Server SIP Containerのインスタンスを指定します。ターゲット・サーバーがドメインのconfig.xmlファイルで定義される必要があります。

C.6.3 ホスト

このDiameterノードのホスト・アイデンティティを指定します。host要素が指定されていない場合に、アイデンティティがローカル・サーバーのホスト名から取得されます。ホスト・アイデンティティはDNS名と一致しない場合がありますので注意してください。

注意:
複数のshクライアント・ノードを対象にdiameterサポートを構成する場合は、diameter.xmlファイルのhost要素を省略することをお薦めします。これにより、同じDiameter Webアプリケーションをエンジン層クラスタのすべてのサーバーにデプロイすることができます。その際、各サーバー・インスタンスのホスト名が動的に取得されます。

C.6.4 レルム

Diameterノードに対応するレルム名を指定します。異なるレルムとリスニング・ポート番号を使用すると、同一ホスト上で複数のDiameterノードを運用することができます。HSS、アプリケーション・サーバー、リレー・エージェントはすべて、レルム名または名前が一致している必要があります。HSSとアプリケーション・サーバーのレルム名は一致していなくてもかまいません。

realm要素を省略した場合、レルム名は、ホスト名が完全修飾名(たとえば、host@oracle.com)である場合、ホスト名のドメイン名部分を使用して導出されます。

C.6.5 アドレス

DNS名またはIPアドレスを使用してこのDiameterノードのリスニング・アドレスを指定します。アドレスを指定していない場合、ノードはhostアイデンティティをリスニング・アドレスとして使用します。

注意:
host IDはDiameterノードのDNS名と同じであっても違っていても、どちらでもかまいません。構成エラーを回避するため、address要素と一緒にDNS名またはIPアドレスを明示的に指定することをお薦めします。

C.6.6 ポート

このDiameterノードのTCPまたはTLSリスニング・ポートを指定します。デフォルト・ポートは3868です。

C.6.7 tls-enabled

この要素は、TLS機能を公開するためにスタンドアロン・ノード操作のみに使用されます。

Oracle WebLogic Server SIP Containerでは、サーバー・インスタンス内で実行しているノードのtls-enabled要素が無視されます。そのかわりに、サーバー・インスタンスは、TLSサポートのあるネットワーク・チャネル(Diameterチャネル)を構成している場合、TLSトランスポートは有効と報告されます。ネットワーク・リソースの構成のDiameterプロトコルのネットワーク・チャネルの作成を参照してください。

C.6.8 sctp-enabled

この要素は、SCTP機能を公開するためのスタンドアロン・ノード操作にのみ使用されます。

Oracle WebLogic Server SIP Containerでは、サーバー・インスタンス内で実行しているノードのsctp-enabled要素が無視されます。そのかわりに、サーバー・インスタンスは、SCTPサポートのあるネットワーク・チャネル(diameter-sctpチャネル)を構成している場合、SCTPトランスポートは有効と報告されます。ネットワーク・リソースの構成のDiameterプロトコルのネットワーク・チャネルの作成を参照してください。

C.6.9 debug-enabled

デバッグ・メッセージの出力を有効/無効にするブール値を指定します。デフォルトでは、デバッグ・メッセージの出力は無効化されています。

C.6.10 message-debug-enabled

Diameterメッセージのトレースを有効/無効にするブール値を指定します。デフォルトでは、この要素は無効化されています。

C.6.11 アプリケーション

選択したノード上で実行するように特定の直径アプリケーションを構成します。Oracle WebLogic Server SIP Containerには、Diameter Sh、Ro、とRfクライアント、Diameterリレー・エージェントまたはホーム・サブスクライバ・サーバー(HSS)として機能するノードをサポートするアプリケーションが含まれます。HSSのアプリケーションは、開発またはテスト目的でのみ提供されるシミュレータであることに注意してください。

C.6.11.1 class-name

ロードするアプリケーション・クラス・ファイルを指定します。

C.6.11.2 param*

アプリケーション・クラスに渡す任意のパラメータを1つまたは複数指定します。

C.6.11.2.1 名前

アプリケーション・パラメータの名前を指定します。

C.6.11.2.2 値

パラメータ値を指定します。

C.6.12 peer-retry-delay

ノードがDiameterピアへのアクセスを再試行する間隔を秒単位で指定します。デフォルト値は30秒です。

C.6.13 allow-dynamic-peers

ピアの動的な構成有効または無効にするブール値を指定します。デフォルトでは、動的なピアは無効化されています。動的なピアを有効にするのは、TLSトランスポートを使用する場合のみにします。ピアになるホストを制限するためのアクセス制御メカニズムがないからです。

C.6.14 request-timeout

タイミング・アウトの前にピアからの応答を待機する間隔をミリ秒単位で指定します。

C.6.15 watchdog-timeout

Diameter Tw ウォッチドッグ・タイマーの秒単位を指定します。

C.6.16 supported-vendor-id+

能力交換にSupported-Version-Ids AVPに追加する1つ以上のベンダーIDを指定します。

C.6.17 include-origin-state

リクエストと応答で原点状態AVPをノードに含めるかどうか指定します。

C.6.18 peer+

個々のDiameterピアの接続情報を指定します。ピア・ノードごとに接続情報を設定するか、ノードをピアとして動的に追加することを許可するかの、どちらかを選択することができます。ただし、動的なピアを有効にするのは、TLSトランスポートを使用する場合のみにしてください。なぜなら、動的なピアを有効にすると、ピアになるホストをフィルタしたり制限したりできなくなるからです。

Shクライアント・ノードを構成する場合に、peers要素はシステムにデプロイされた各Diameterリレー・エージェントのピアの定義を含める必要があります。システムはリレー・エージェントを使用していない場合は、システム内のホーム・サブスクライバ・サーバー(HSS)とShクライアント・ノードとして機能する他のすべてのエンジン層ノードのピアのエントリを含める必要があります。

Diameterリレー・エージェント・ノードを構成する場合に、peers要素はピアおよびHSSにアクセスするすべてのDiameterクライアント・ノードのピア・エントリを含める必要があります。

C.6.18.1 ホスト

Diameterピアのホスト・アイデンティティを指定します。

C.6.18.2 アドレス

Diameterピアのリスニング・アドレスを指定します。アドレスを指定していない場合、ホスト・アイデンティティが使用されます。

C.6.18.3 ポート

このDiameterピアのTCPまたはTLSポート番号を指定します。デフォルト・ポートは3868です。

C.6.18.4 プロトコル

ピアで使用されるプロトコルを指定します。この要素はtcpやsctpのいずれかになります。

C.6.19 ルート

メッセージを解決するためにノードが使用するレルム・ベースのルートを指定します。

Shクライアント・ノードを設定する場合に、システム内にデプロイされた各Diameterリレー・エージェント・ノードへのルートと選択されたリレーへのdefault-routeを指定する必要があります。システムでは、リレー・エージェントを使用していない場合に、HSSへの単一のdefault-routeを設定します。

Diameterリレー・エージェント・ノードを構成する場合に、HSSへの単一のdefault-routeを設定します。

C.6.19.1 レルム

このルートで使用されるターゲット・レルムを指定します。

C.6.19.2 application-id

このルートのターゲット・アプリケーションIDを指定します。

C.6.19.3 アクション

このルートを使用するときのDiameterノードのロールを説明するアクションの種類です。この要素には次の値のいずれかを指定できます。

- なし

- ローカル

- リレー

- プロキシ

- リダイレクト

C.6.19.4 server+

このルートに対して1つ以上のターゲット・サーバーを指定します。server要素に指定したサーバーは、Diameterノードにpeerとして定義するか、または動的なピアのサポートを有効化する必要があることに注意してください。

C.6.20 default-route

リクエストを構成済みのルートにマッチングできない場合に使用するデフォルト・ルートを定義します。

C.6.20.1 アクション

Diameterノードのデフォルトのルーティング・アクションを指定します。詳細は、C.6.19.3項「アクション」を参照してください。

C.6.20.2 server+

デフォルト・ルートに対して1つ以上のターゲット・サーバーを指定します。この要素に含めるサーバーは、このDiameterノードにpeerとして定義するか、または動的なピアのサポートを有効化する必要があります。

D 起動コマンド・オプション

表D-1は、Oracle WebLogic Server SIP Containerおよび他のOracle WebLogic Server SIP Containerユーティリティで使用可能な起動構成オプションへの参照を提供します。

表D-1 起動コマンド・オプション

アプリケーション

起動オプションのリンク

SIPサーブレット・アプリケーション・ルーター

-Djavax.servlet.sip.dar.configuration

-Djavax.servlet.sip.ar.spi.SipApplicationRouterProvider

Oracle WebLogic Server SIP Container

-Dwlss.udp.listen.on.ephemeral

-Dwlss.udp.lb.masquerade

-Dweblogic.management.discover

-Dweblogic.RootDirectory

Oracle WebLogic SIP Server

-Dwlss.udp.listen.on.ephemeral

-Dwlss.udp.lb.masquerade

-Dweblogic.management.discover

-Dweblogic.RootDirectory

-DWLSS.SNMPAgentPort

インストーラ

-Djava.io.tmpdir

WlssEchoServer

-Dwlss.ha.echoserver.port

-Dwlss.ha.echoserver.logfile

-Dreplica.host.monitor.enabled

-Dwlss.ha.heartbeat.interval

-Dwlss.ha.heartbeat.count

-Dwlss.ha.heartbeat.SoTimeout

これらのオプションおよび他のオプションの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverコマンド・リファレンス』を参照してください。

E サポートされるプラットフォーム、プロトコル、RFCおよび標準

次の項では、Oracle WebLogic Server SIP Containerの様々な仕様とRFCへの準拠について説明します。

- E.1項「サポートされる構成」

- E.2項「サポートされるSIPクライアント」

- E.3項「サポートされるロード・バランサ」

- E.4項「サポートされるデータベース」

- E.5項「Oracle WebLogic Server SIP Container標準アラインメントの概要」

- E.6項「Java Sun Recommendation (JSR)標準への準拠」

- E.7項「IETF RFCへの準拠」

- E.8項「3GPP R6仕様への適合」

E.1 サポートされる構成

Oracle WebLogic Server SIP Containerは、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlに記載されているオペレーティング・システム、ハードウェアおよびJVM組合せの本番使用をサポートしています。

注意:
本番デプロイメントはLinuxおよびUNIXプラットフォームに対してのみサポートされています。Windowsプラットフォームは開発目的にのみサポートされています。

Oracle WebLogic Server SIP Containerの要件は、Oracle WebLogic Server 10g リリース3の要件と同様になります。基本的なWebLogic Server要件の他に次の項目が必要です。

- ほとんどの本番デプロイメントでは、エンジン層サーバーとSIPデータ層サーバーの間にギガ・ビット・イーサネットを接続する必要があります。

- 本番環境でフェイルオーバー機能を提供するには、Dual NICが必要です。

- 多くの本番インストールのスループット要件をサポートするには、追加RAMが必要です。

- 本番インストールのために互換性のあるロード・バランサが必要です。

E.2 サポートされるSIPクライアント

Oracle WebLogic Server SIP Containerおよび含まれるサンプル・アプリケーションは、次のSIPソフトフォンをサポートします。

- Oracle Communicator(デフォルトのクライアント)

E.3 サポートされるロード・バランサ

Oracle WebLogic Server SIP Containerは、F5 Networks, Inc. BIG-IPロード・バランサ、バージョン9.0.5 - 9.2.3ビルド34.3で動作確認されています。

その他のロード・バランサ・ソリューションのサポートは、Oracle Technology Network (http://www.oracle.com/global/index.html)を参照してください。

E.4 サポートされるデータベース

Oracle WebLogic Server SIP Containerは、存続期間の長いセッション・データの格納およびリージョン・サイト(地理的永続)にわたるコール状態情報のレプリケートに関して、次のデータベースでの動作が確認されています。

- Oracle Database 10g (10.2.0.3以上)Oracle Database 11g (11.1.0.6以上)

E.5 Oracle WebLogic Server SIP Container標準アラインメントの概要

Oracle WebLogic Server SIP Containerは、Internet Engineering Task Forceおよび3rd Generation Partnership Projectの仕様に特に注意して開発されています。機能の開発は、市場の全般的傾向の現状分析と予測に従って優先順位が付けられています。特定の仕様が廃止されている場合またはインターネット・ドラフトが「Request For Comments」標準に従って形式化されている場合、Oracle WebLogic Server SIP Containerはこれらの仕様に準拠することを優先します。仕様が3GPPのように大きなリリース計画の一部である場合、最新のリリース(この場合、リリース6)への準拠が優先されます。このドキュメントにはコンポーネント仕様の後続バージョンへの準拠について記述していない場合でも、製品はそれらの仕様に準拠しないわけではありません。

E.6 Java Sun Recommendation (JSR)標準への準拠

Oracle WebLogic Server SIP Containerは、Java EEバージョン5.0および対応するJava EEコンポーネント仕様に準拠します。

Oracle WebLogic Server SIP ContainerはJSR 289:「SIPサーブレットAPI」で定義されているSIPサーブレット・コンテナを追加することで拡張できます。

Oracle WebLogic Server SIP Containerは、関連するすべてのTest Compatibility Kits (TCK)を実行しており、Sun Microsystemが規定した、公式発表された準拠に必要な形式要件を満たしています。

E.7 IETF RFCへの準拠

次の表は、一般的なInternet Engineering Task Force (IETF)のRequests for Comment (RFC)およびインターネット・ドラフトに対するOracle WebLogic Server SIP Containerの準拠レベルを示しています。準拠レベルの定義は次のとおりです。

- はい: Oracle WebLogic Server SIP Containerがその機能または仕様を直接サポートしていることを示します。

- はい(プラットフォーム): Oracle WebLogic Server SIP ContainerがRFCを実装しているアプリケーションまたはコンポーネントをホストできることを示します。ただし、RFCまたは機能はプロトコルのトランザクション・レイヤーまたはSIPサーブレット・コンテナの動作には影響しません。

表E-2 Oracle WebLogic Server SIP ContainerのIETFへの準拠

RFC/仕様番号

タイトル

準拠?

関連情報

761

DoD Standard Transmission Control Protocol

はい

http://www.ietf.org/rfc/rfc761.txtを参照してください。

768

User Datagram Protocol

はい

http://www.ietf.org/rfc/rfc768.txtを参照してください。

1157

Simple Network Management Protocol (SNMP)

はい

Oracle WebLogic Server SIP Containerは、SNMP V2cトラップをサポートします。http://www.ietf.org/rfc/rfc1157.txtを参照してください。

1847

Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、署名付きまたは暗号化されたマルチパートMIMEオブジェクトを使用または生成するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc1847.txtを参照してください。

1901

Introduction to Community-based SNMPv2

はい

Oracle WebLogic Server SIP Containerは、SNMP V2cトラップをサポートします。http://www.ietf.org/rfc/rfc1901.txtを参照してください。

1905

Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)

はい

Oracle WebLogic Server SIP Containerは、SNMP V2cトラップをサポートします。http://www.ietf.org/rfc/rfc1905.txtを参照してください。

1906

Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)

はい

Oracle WebLogic Server SIP Containerは、TCPおよびUDPの両方よりSNMPをサポートします。http://www.ietf.org/rfc/rfc1906.txtを参照してください。

1907

Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)

はい(プラットフォーム)

http://www.ietf.org/rfc/rfc1907.txtを参照してください。

2183

Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠しているアプリケーションをサポートします。http://www.ietf.org/rfc/rfc2183.txtを参照してください。

2246

The TLS Protocol Version 1.0

はい

Oracle WebLogic Server SIP Containerは、TLSをサポートします。http://www.ietf.org/rfc/rfc2246.txtを参照してください。

2327

SDP: Session Description Protocol

はい

Oracle WebLogic Server SIP Containerは、SDPを使用または生成するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc2327.txtを参照してください。

2460

Internet Protocol, Version 6 (IPv6) Specification

はい

http://www.ietf.org/rfc/rfc2460.txtを参照してください。

2543

SIP: Session Initiation Protocol (v1)

はい

Oracle WebLogic Server SIP Containerは、この仕様に記載されている下位互換性をサポートします。http://www.ietf.org/rfc/rfc2543.txtを参照してください。

2616

Hypertext Transfer Protocol -- HTTP 1.1

はい

http://www.ietf.org/rfc/rfc2616.txtを参照してください。

2617

HTTP Authentication: Basic and Digest Access Authentication

はい

http://www.ietf.org/rfc/rfc2617.txtを参照してください。

2782

A DNS RR for specifying the location of services (DNS SRV)

はい

http://www.ietf.org/rfc/rfc2782.txtを参照してください。

2806

URLs for Telephone Calls

はい

http://www.ietf.org/rfc/rfc2806.txtを参照してください。

2848

The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services

はい(プラットフォーム)

PINTサービスを実装することは、IMS以前のアーキテクチャであることを意味します。Oracleでは3GPP/TISPANアーキテクチャおよびクラス4/5 Service Emulationのアプローチを推奨し、PINTは推奨しませんが、Oracle WebLogic Server SIP Containerを使用してPINTサービス要素を実装できます。http://www.ietf.org/rfc/rfc2848.txtを参照してください。

2916

E.164 number and DNS

はい

http://www.ietf.org/rfc/rfc2916.txtを参照してください。

2960

Stream Control Transmission Protocol

はい

SCTPはDiameterトラフィックのみをサポートします。http://www.ietf.org/rfc/rfc2960.txtを参照してください。

2976

The SIP INFO Method

はい

http://www.ietf.org/rfc/rfc2976.txtを参照してください。

3204

MIME media types for ISUP and QSIG Objects

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、それ自体がISUPオブジェクトやQSIGオブジェクトを使用または生成することはありませんが、これらのオブジェクトを使用または生成するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3204.txtを参照してください。

3261

SIP: Session Initiation Protocol

はい

http://www.ietf.org/rfc/rfc3261.txtを参照してください。

3262

Reliability of Provisional Responses in the Session Initiation Protocol (SIP)

はい

http://www.ietf.org/rfc/rfc3262.txtを参照してください。

3263

Session Initiation Protocol (SIP): Locating SIP Servers

はい

http://www.ietf.org/rfc/rfc3263.txtを参照してください。

3264

An Offer/Answer Model with Session Description Protocol (SDP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3264.txtを参照してください。

3265

Session Initiation Protocol (SIP)-Specific Event Notification

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3265.txtを参照してください。

3266

Support for IPv6 in Session Description Protocol (SDP)

はい

次を参照してください。

http://www.ietf.org/rfc/rfc3266.txt

3268

Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは暗号化サービスをサポートしますが、使用されている一部のアルゴリズムについては、地域によって使用できない場合や、輸出規制の対象となっている場合があります。http://www.ietf.org/rfc/rfc3268.txtを参照してください。

3311

The Session Initiation Protocol (SIP) UPDATE Method

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3311.txtを参照してください。

3312

Integration of Resource Management and Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3312.txtを参照してください。

3313

Private Session Initiation Protocol (SIP) Extensions for Media Authorization

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3313.txtを参照してください。

3323

A Privacy Mechanism for the Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3323.txtを参照してください。

3325

Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

はい

http://www.ietf.org/rfc/rfc3325.txtを参照してください。

3326

The Reason Header Field for the Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3326.txtを参照してください。

3327

Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts

はい(プラットフォーム)

http://www.ietf.org/rfc/rfc3327.txtを参照してください。

3351

User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3351.txtを参照してください。

3372

Session Initiation Protocol for Telephones (SIP-T): Context and Architectures

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3372.txtを参照してください。

3388

Grouping of Media Lines in the Session Description Protocol (SDP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3388.txtを参照してください。

3420

Internet Media Type message/sipfrag

次を参照してください。

http://www.ietf.org/rfc/rfc3420.txt

3428

Session Initiation Protocol (SIP) Extension for Instant Messaging

はい

http://www.ietf.org/rfc/rfc3428.txtを参照してください。

3455

Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3455.txtを参照してください。

3489

STUN-SimpleTraversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

はい

http://www.ietf.org/rfc/rfc3489.txtを参照してください。

3515

The Session Initiation Protocol (SIP) Refer Method

はい

http://www.ietf.org/rfc/rfc3515.txtを参照してください。

3524

Mapping of Media Streams to Resource Reservation Flows

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3524.txtを参照してください。

3556

Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3556.txtを参照してください。

3578

Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートしますが、ISUPインタフェースを提供しません。http://www.ietf.org/rfc/rfc3578.txtを参照してください。

3581

An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

はい

http://www.ietf.org/rfc/rfc3581.txtを参照してください。

3589

Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5

はい

http://www.ietf.org/rfc/rfc3589.txtを参照してください。

3588

Diameter Base Protocol

はい

http://www.ietf.org/rfc/rfc3588.txtを参照してください。

3605

Real Time Control Protocol (RTCP) attribute in Session Description Protocol ((SDP)

http://www.ietf.org/rfc/rfc3605.txtを参照してください。

3608

Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration.

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートしますが、登録中に確立されたServiceRouteを格納する機能はありません。この機能はアプリケーションの一部として実装できます。http://www.ietf.org/rfc/rfc3608.txtを参照してください。

3665

Session Initiation Protocol (SIP) Basic Call Flow Examples.

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3665.txtを参照してください。

3666

Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3666.txtを参照してください。

3680

A Session Initiation Protocol (SIP) Event Package for Registrations

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3680.txtを参照してください。

3689

General Requirements for Emergency Telecommunication Service (ETS)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3689.txtを参照してください。

3690

IP Telephony Requirements for Emergency Telecommunication Service (ETS)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3690.txtを参照してください。

3702

Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)

はい

Oracle WebLogic Server SIP Containerバージョンは、JDBCおよびLDAPをサポートします。http://www.ietf.org/rfc/rfc3702.txtを参照してください。

3725

Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3725.txtを参照してください。

3761

The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)

はい

http://www.ietf.org/rfc/rfc3761.txtを参照してください。

3764

Enumservice Registration for Session Initiation Protocol (SIP) Addresses-of-Record

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3764.txtを参照してください。

3824

Using E.164 numbers with the Session Initiation Protocol (SIP)

はい

http://www.ietf.org/rfc/rfc3824.txtを参照してください。

3840

Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3840.txtを参照してください。

3841

Caller Preferences for the Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3841.txtを参照してください。

3853

S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3853.txtを参照してください。

3856

Presence Event Package for the Session Initiation Protocol (SIP)

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3856.txtを参照してください。

3857

Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3857.txtを参照してください。

3858

Extensible Markup Language (XML) Based Format for Watcher Information

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3858.txtを参照してください。

3863

Presence Information Data Format (PIDF)

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3863.txtを参照してください。

3891

The Session Initiation Protocol (SIP) "Join" Header

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3891.txtを参照してください。

3892

The Session Initiation Protocol (SIP) Referred-By Mechanism

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3892.txtを参照してください。

3893

Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3893.txtを参照してください。

3903

Session Initiation Protocol (SIP) Extension for Event State Publication

はい

http://www.ietf.org/rfc/rfc3903.txtを参照してください。

3911

The Session Initiation Protocol (SIP) "Join" Header

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3911.txtを参照してください。

3959

The Early Session Disposition Type for the Session Initiation Protocol (SIP)

http://www.ietf.org/rfc/rfc3959.txtを参照してください。

3960

Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc3960.txtを参照してください。

3966

The tel URI for Telephone Numbers

はい

http://www.ietf.org/rfc/rfc3966.txtを参照してください。

4028

Session Timers in the Session Initiation Protocol (SIP)

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc4028.txtを参照してください。

4032

Update to the Session Initiation Protocol (SIP) Preconditions Framework

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc4032.txtを参照してください。

4244

An Extension to the Session Initiation Protocol (SIP) for Request History Information

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc4244.txtを参照してください。

4320

Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

http://www.ietf.org/rfc/rfc4320.txtを参照してください。

4321

Problems Identified Associated with the Session Initiation Protocol's (SIP) Non_INVITE Transaction

http://www.ietf.org/rfc/rfc4321.txtを参照してください。

4474

Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)

はい

http://www.ietf.org/rfc/rfc4474.txtを参照してください。

4479

Data Model for Presence

はい

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc4479.txtを参照してください。

4480

RPID: Rich Presence Extensions to the Presence Information Data Format

暗黙的にサポートされています

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc4480.txtを参照してください。

4481

Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals

暗黙的にサポートされています

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc4481.txtを参照してください。

4483

A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。http://www.ietf.org/rfc/rfc4483.txtを参照してください。

4825

The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)

部分的にサポートされています

一部のドキュメント操作(XPath)をサポートしていません。

4827

Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents

はい

draft-ietf-simple-xcap-pidf-manipulation-usage-02を置き換えます。

draft-levy-sip-diversion-08

Diversion Indication in SIP

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6002を参照してください。

draft-donovan-mmusic-183-00

SIP 183 Session Progress Message Draft

はい(プラットフォーム)

Oracle WebLogic Server SIP Containerは、この仕様に準拠するアプリケーションをサポートします。https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=4308を参照してください。

draft-ietf-sip-gruu-15

Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)

はい

http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-15.txtを参照してください。

Presence Authorization Rules

draft-ietf-simple-presence-rules-04

はい

http://tools.ietf.org/html/draft-ietf-simple-presence-rules-10

OMA extensions to the presence data model

OMA-TS-Presence_SIMPLE-V1_0-20051122-C

はい

OMA extensions to geopriv common policy

OMA-TS-XDM_Core-V1_0-20051122-C

はい

OMA extensions to presence rules

OMA-TS-Presence_SIMPLE_XDM-V1_0-20051122-C

はい

E.8 3GPP R6仕様への適合

表E-3は、各適用可能な3GPPリリース6仕様で識別されたイネーブラまたはアプリケーション機能の実装をサポートするOracle WebLogic Server SIP Containerの機能の要約です。

記載されている例外を除き、Oracle WebLogic Server SIP Containerは、仕様に記載されたアプリケーション・サーバー・エンティティに関連する項目に準拠するアプリケーションまたは機能の実装に対していかなる制限も課しません。場合によっては、アプリケーションはSIPメソッドまたはヘッダーをサポートする必要があります。Oracle WebLogic Server SIP Container Sipサーブレット・コンテナのデフォルトの動作では、通常のSIPサーブレットAPI手順を使用して、認識されていないヘッダー、リクエスト・メソッドおよびペイロードをSIPサーブレットに渡します。

表E-3 3GPP R6仕様への適合

仕様

コメント

3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2 (Release 6)"

- コメントなし

3GPP TS 24.229: "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 6)"

- Oracle WebLogic Server SIP Containerでは、サブセクション5.7.1.2で説明するように、SIPリクエストごとにp-charging-function-addressヘッダー1つのみという要件を適用しません。ただし、一意性は適用します。

- Oracle WebLogic Server SIP Containerでは、サブセクション5.7.3で説明しているプライバシ・サポートは行いません。

3GPP TS 23.141: "Presence Service; Architecture and Functional description (Release 6)"

- Oracle WebLogic Server SIP Containerでは、ネイティブでは、Ph (MAP)、Pl (LIF-MLP)、Px (DIAMETER Cx/Dx)、Pg (フェーズ4、3GPPリリース5)、Pc (CAMELフェーズ4、3GPPリリース5)またはPr、Pk、Pp (RADIUS)のリファレンス・ポイントをサポートしません。

- Oracle WebLogic Server SIP Containerは、サブセクション4.3.1で必要とされるPresence User Agent (Peu)リファレンス・ポイントに必要なIPv6をサポートしません。

3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2 (Release 6)"

- コメントなし

3GPP TS 24.247 "Messaging using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3 (Release 6)"

- MSRPリレーは一般的にIMSアーキテクチャにメディア・リソース機能として実装されると仮定されますが、Oracle WebLogic Server SIP ContainerはMessage Session Relay Protocol (MSRP)をサポートしません。

3GPP TS 24.841: "Presence service based on Session Initiation Protocol (SIP); Functional models, information flows and protocol details (Release 6)"

- Oracle WebLogic Server SIP Containerは、IETF RFC 3310: 「Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)」をサポートしません。

3GPP TS 24.109: "Bootstrapping interface (Ub) and Network application function interface (Ua); Protocol details (Release 6)"

- Oracle WebLogic Server SIP Containerは、IETF RFC 3310: 「Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)」をサポートしません。

- Oracle WebLogic Server SIP Containerは、統合セキュリティ・フレームワーク内でアクセス制御と認可制約の適用に使用する「X-3GPP-Asserted-Identity拡張ヘッダー」をサポートします。

3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message contents"

- コメントなし

3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details"

- コメントなし

3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging applications"

- コメントなし

3GPP TS 33.222: "Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS) (Release 6)"

- Oracle WebLogic Server SIP Containerは、GAAでのアプリケーション・サーバー・ロールをサポートします。

F Oracle WebLogic SIP Containerのエクスポート/インポートの使用

次の項では、Oracle WebLogic Server SIP Containerのエクスポートおよびインポート機能の使用方法について説明します。

- F.1項「エクスポート」

- F.2項「インポート」

注意:
このドキュメントのすべての例はLinuxコマンドを使用します。他のオペレーティング・システムに応じて適切なコマンドを使用します。

F.1 エクスポート

この項では、OWLSCデータをエクスポートするために必要な手順について説明します。

F.1.1 現在の環境からのデータベース・データのエクスポート

注意:
この手順における最初の4つのステップは、RDBMSマシン上で実行するものです。

Oracleデータベース・エクスポート・ユーティリティの1つを使用して、データをエクスポートします。エクスポート・コマンドを実行する前に、既存のデータベース・マシンで、エクスポートされたデータ・ダンプ・ファイルとログ・ファイルが格納されるファイル・システム上にディレクトリを作成します。

$ mkdir ~/owlcs_data_pump_dir

1. ディレクトリをデータベース・インストレーション・ディレクトリの$ORACLE_HOME/binに変更して、次のコマンドを実行します。これらのコマンドは、sysユーザーまたはsystemユーザーとして実行できます。

2. 次のコマンドを使用して、データベースにDATA_PUMP_DIRを作成します。

- $ ./sqlplus sys@<db_service> as sysdba

- プロンプトでsysユーザーのパスワードを入力します。

- SQLプロンプトでは、次のコマンドを実行します。

SQL> create or replace directory DATA_PUMP_DIR as '<full_path_to_the_data_pump_dir_created_above>';
SQL> commit;
SQL> quit

3. サブスクライバ・データ・サービス・スキーマにデータをエクスポートします。

- $ ./expdp "'sys@<db_service> as sysdba'" SCHEMAS=<current_prefix>_orasdpsds DIRECTORY=DATA_PUMP_DIR DUMPFILE=<current_prefix>_orasdpsds.dmp LOGFILE=<current_prefix>_orasdpsds.log

- プロンプトで、sysユーザーのパスワードを入力します。

注意:
前述のコマンド行のディレクトリ・パラメータの値は、ファイル・システム上の実際のディレクトリでなく、DATA_PUMP_DIRと指定します。コマンドを実行後、2つのファイル(1つはDUMPFILEに対応し、もう1つはLOGFILEに対応します)がデータ・ポンプ・ディレクトリに作成されていることを確認します。

4. XDMSスキーマにデータをエクスポートします。

- $ ./expdp "'sys@<db_service> as sysdba'" SCHEMAS=<current_prefix>_orasdpsds DIRECTORY=DATA_PUMP_DIR DUMPFILE=<current_prefix>_orasdpsds.dmp LOGFILE=<current_prefix>_orasdpsds.log

- プロンプトで、sysユーザーのパスワードを入力します。

注意:
前述のコマンド行のディレクトリ・パラメータの値は、ファイル・システム上の実際のディレクトリでなく、DATA_PUMP_DIRと指定します。コマンドを実行後、2つのファイル(1つはDUMPFILEに対応し、もう1つはLOGFILEに対応します)がデータ・ポンプ・ディレクトリに作成されていることを確認します。

クライアントがサーバーにサインインすると、ロケーション・データが再作成されるため、ロケーション・サービス・スキーマのエクスポートは必要ありません。

5. OWSMポリシー移行を完了します。次のコマンドを実行して、WLSTを開始します。

$ORACLE_HOME/common/bin/wlst.sh.

6. 次のコマンドを実行して、ローカルのWLSインスタンスに接続します。

wls:/offline> connect('weblogic','weblogic','127.0.0.1:7001')

この例では、「weblogic」/「weblogic」はWLS管理ユーザー名/パスワードのサンプルです。これらを使用する環境の実際値に置き換えます。WLSの別のインスタンスが実行されていると、ポート(WLS AdminServerポート)が変更されることがあります。

7. 次のWLSTコマンドを実行して、ポリシーとアサーション・テンプレートをエクスポートします。「wlcs_server1」をOWLSCインスタンス名に置き換えます。

wls:/base_domain/serverConfig> exportMetadata(application='wsm-pm',server='wlcs_server1',docs='/assertiontemplates/**',toLocation='/tmp/owsmexport/')
wls:/base_domain/serverConfig> exportMetadata(application='wsm-pm',server='wlcs_server1',docs='/policies/**',toLocation='/tmp/owsmexport/')

8. 次のコマンドを実行して、WLSTコマンド・ライン・ツールを終了します。

wls:/base_domain/serverConfig> exit()

9. (OWLSCインスタンスがインストールされているマシン「ミドルウェア・マシン」で実行されます)次は、資格証明ストアをエクスポートします。OWSMは、クライアント・ポリシー・ユーザー名とパスワードの資格証明とキーストア・パスワードを資格証明ストアに格納します。現在のマシンから<domain>/config/fmwconfig/cwallet.ssoを新しいマシンにコピーします。もしこれがOPSS移行の一部としてすでに実行されているときは、このステップは省略できます。

10. (UMSが環境にインストールされている場合)UMS関連の詳細情報を新規環境にエクスポートします。(UMSが環境にインストールされている場合)UMS関連の詳細情報を使用する新規環境にエクスポートします。現在および新規環境でユーザー・メッセージング・サービスを使用する場合、次のステップを実行します。

- 次のコマンドを実行して、WLSTを開始します。

$ORACLE_HOME/common/bin/wlst.sh

注意:
ミドルウェア・インスタンス上のORACLE_HOMEです。デフォルトで、<middleware_home>/as11gr1wlcs1 directoryです。<middleware_home>は、OWLSCをインストールするディレクトリです。

11. バックエンド・データベースから指定されたxmlファイルにユーザー・メッセージング・プリファレンスをダウンロードするには、次のWLSTコマンドを実行します。

wls:/offline> manageUserMessagingPrefs(operation='download', filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001', username='weblogic', password='weblogic')

注意:
前述のサンプルでは、「weblogic」/「weblogic」はWLS管理ユーザー名/パスワードの組合せのサンプルです。これらを使用する環境の実際値に置き換えます。8001は、UMSが実行されている管理対象サーバーのポートです。それを適切な値に置き換えます。

12. 以下のコマンドを実行して、WLSTコマンド・ライン・ツールを終了します。

wls:/offline> exit()

F.2 インポート

この項では、OWLSCデータをインポートするために必要な手順について説明します。

1. 本番環境にデータベース・データをインポートします。これは、Oracleデータベース・インポート・ユーティリティの1つを使用して実施できます。インポート・コマンドを実行する前に、新しいデータベース・マシンで、データ・ダンプ・ファイルがインポートされ、ログ・ファイルが格納されるファイル・システム上に、ディレクトリを作成します。

$ mkdir ~/owlcs_data_pump_dir

2. 旧データベース・マシンのデータ・ポンプ・ディレクトリから、前述のディレクトリへすべてのdmpファイルをコピー(ftpまたはリモート・コピー)します。

3. ディレクトリを本番データベース・インストールの$ORACLE_HOME/binに変更して、次のコマンドを実行します。これらのコマンドは、sysユーザーまたはsystemユーザーとして実行できます。

1. 次のコマンドで、本番データベースにDATA_PUMP_DIRを作成します。

$ ./sqlplus sys@<db_service> as sysdba

プロンプトで、sysユーザーのパスワードを入力します。

SQLプロンプトでは、次のコマンドを実行します。

SQL> create or replace directory DATA_PUMP_DIR as '<full_path_to_the_data_pump_dir_created_above>'
SQL> commit;
SQL> quit

2. 次のコマンドで、<production_prefix>_orasdpsdsスキーマのシーケンスをすべて削除します。

# $ ./sqlplus sys@<db_service> as sysdba

プロンプトで、sysユーザーのパスワードを入力します。

SQLプロンプトでは、以下のコマンドを実行してください。

SQL> alter session set current_schema=<production_prefix>_orasdpsds;
SQL> drop sequence ACCOUNT_SEQ;
SQL> drop sequence CREDENTIALS_SEQ;
SQL> drop sequence PRIVATE_IDENTITY_SEQ;
SQL> drop sequence PUBLIC_IDENTITY_SEQ;
SQL> drop sequence REALM_SEQ;
SQL> drop sequence ROLE_SEQ;
SQL> commit;
SQL> quit

3. サブスクライバ・データ・サービス・スキーマにデータをインポートします。

$ ./impdp "'sys@<db_service> as sysdba'" REMAP_SCHEMA=<test_prefix>_orasdpsds:<production_prefix>_orasdpsds TABLE_EXISTS_ACTION=REPLACE DIRECTORY=DATA_PUMP_DIR DUMPFILE=<test_prefix>_orasdpsds.dmp LOGFILE=<production_prefix>_orasdpsds.log

プロンプトで、sysユーザーのパスワードを入力します。

前述のコマンド行のディレクトリ・パラメータの値は、ファイル・システム上の実際のディレクトリでなくDATA_PUMP_DIRと指定します。「ユーザーがすでに存在する」のエラーを無視します。

4. データをXDMSスキーマにエクスポートします。

$ ./impdp "'sys@<db_service> as sysdba'" REMAP_SCHEMA=<test_prefix>_orasdpxdms:<production_prefix>_orasdpxdms TABLE_EXISTS_ACTION=REPLACE DIRECTORY=DATA_PUMP_DIR DUMPFILE=<test_prefix>_orasdpxdms.dmp LOGFILE=<production_prefix>_orasdpxdms.log

プロンプトで、sysユーザーのパスワードを入力します。

前述のコマンド行のディレクトリ・パラメータの値は、ファイル・システム上の実際のディレクトリでなくDATA_PUMP_DIRと指定します。「ユーザーがすでに存在する」のエラーを無視します。

クライアントがサーバーにサインインすると、ロケーション・データが再作成されますので、ロケーション・サービス・スキーマのインポートは必要ありません。

4. /tmp/owsmexportディレクトリを、新しいマシンにコピーします。

5. 以下のコマンドを実行して、WLSTを開始します。

$ORACLE_HOME/common/bin/wlst.sh

6. 以下のコマンドを実行して、ローカルWLSインスタンスに接続します。

wls:/offline> connect('weblogic','weblogic','127.0.0.1:7001')

注意:
前述のサンプルでは、「weblogic」/「weblogic」はWLS管理ユーザー名/パスワードのサンプルです。これらを使用する環境の実際値に置き換えます。WLSの別のインスタンスが実行されていると、ポート(WLS AdminServerポート)が変更されることがあります。

7. 次のWLSTコマンドを実行して、ポリシーとアサーション・テンプレートを置き換えます。wlcs_server1をOWLSCインスタンス名に置き換えます。

wls:/base_domain/serverConfig> deleteMetadata(application='wsm-pm',server='wlcs_server1',docs='/assertiontemplates/**')
wls:/base_domain/serverConfig> deleteMetadata(application='wsm-pm',server='wlcs_server1',docs='/policies/**')
wls:/base_domain/serverConfig> importMetadata(application='wsm-pm',server='wlcs_server1',docs='/assertiontemplates/**',fromLocation='/tmp/owsmexport/')
wls:/base_domain/serverConfig> importMetadata(application='wsm-pm',server='wlcs_server1',docs='/policies/**',fromLocation='/tmp/owsmexport/')

8. 以下のコマンドを実行して、WLSTコマンド・ライン・ツールを終了します。

wls:/base_domain/serverConfig> exit()

注意:
OWSMキーストアのインポートについて

- 秘密鍵は、現在の環境と新しい環境では異なるため、移行は必要ありません。

- 公開鍵、中間証明書およびルート証明書は、現在の環境から新規の環境に移行できます。これらを移動するためには、java keytoolのエクスポートとインポート・コマンドを使用します。そうした後に、新しい環境のサービスを起動するクライアントによって、これらの証明書が新規の環境に適用できるかを確認します。

- 新しい環境のサービスを起動するクライアントによって、クライアント証明書、中間CA証明書またはルートCA証明書の新規の公開鍵を新規のキーストアに追加する必要があるかどうかを確認します。

詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』を参照してください。

9. 新しいマシンに移動します。

10. 以下のコマンドを実行して、WLSTを開始します。

$ORACLE_HOME/common/bin/wlst.sh

11. ユーザー・メッセージング・プリファレンスをファイルからバックエンド・データベースへアップロードするために、次のWLSTコマンドを実行します。

wls:/offline> manageUserMessagingPrefs(operation='upload', filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001', username='weblogic', password='weblogic')

注意:
前述のサンプルでは、「weblogic」/「weblogic」はWLS管理ユーザー名/パスワードのサンプルです。これらを使用する環境の実際値に置き換えます。8001は、UMSが実行されている管理対象サーバーのポートです。それを適切な値に置き換えます。

12. アップロード成功のメッセージ表示を確認します。次のコマンドを実行して、WLSTコマンド・ライン・ツールを終了します。

wls:/offline> exit()

注意:
ダウンロードまたはアップロードの実行に関する様々なオプションについては、wls:/offline>プロンプトでヘルプ(manageUserMessagingPrefs)を実行します。LDAPストアで用意されているユーザー・デバイスは動的です。現在の環境と新しい環境の両方とも、同じLDAPストアを示すか、同じ情報のセットを使用するように再構成されることが、前提になっています。

素引

A  C  D  E  G  I  J  L  M  N  O  S  T  W

A

管理コンソール, 1.2.3.1

でコンテナのプロパティの構成, 2.2

管理コンソール

ベスト・プラクティス, 1.2.5

C

チャネル

SIPおよびSIPS, 3.4.2

TCPおよびTLS, 3.5

構成

ロックおよび永続性, 2.2.1

構成ロック, 管理, 2.3 構成

単一のNIC, 3.8.1

カスタム・チャネル

プロパティ, 3.4.3

D

datatier.xml, 4.1.1

デフォルト・アプリケーション・ルーター(DAR), 1.2.2

デプロイ済SIPサーブレット

アップグレード, 8

Diameter

構成, 1.2.2.1

直径

構成, C

ドメイン, 6.3

ノードとリレー, 6

diameterアプリケーション

構成, 6.6.2

コンソール, 6.4 diameterノード

構成, 6.6

Diameter, リソース, 1.2.2 DNS

サポート, 3.3

DNS名, 3.1

E

エンジン層, 7.3

エンタープライズ・デプロイメント, 3.8

エクスポート/インポート

Oracle WebLogic Server SIP Container, F

G

地理的冗長性, 4.5

I

IP_ANY, 3.6

IPv4, 3.1.1

IPv6, 3.1.1

J

JMX, 2.3

JMX準拠のMBean, 1.2.3.3.2

jrockit, 5.8.4

L

リスニング・アドレス, 3.1

リスニング・ポート, 3.1

ロード・バランサ, 7.2

SIPを認識できる, 1.2.2

ロード・バランサ

構成, 3.2, 3.8.5

マルチ・ホーム, 3.2.1

ログ・レベル, 設定, 1.2.3.3.3

M

MBean

通信サービス, 2.3.2

MBeans

作成および削除, 2.4.2

N

NAT (ネットワーク・アドレス変換オプション), 3.8.5.3

ネットワーク・リソース

管理, 3

NTP

構成, 2.5.2

O

Oracle WebLogic Server SIP Container

アーキテクチャ, 7

一般的な構成タスク, 1.2.6

構成, 3.8.5.3

カスタム・リソース, 1.2.2

エクスポートおよびインポート, F

紹介, 1, 1.1

SIPデータ層のパーティション, 4

S

SCTP, 6.5.2

サーバー

起動と停止, 1.2.4

SIP Container

構成, 2

SIPデータ層

構成リファレンス, B

SIPデータ層, 7.4 SIPサーブレット・コンテナ

構成リファレンス, A

SIPサーブレット・コンテナ, 1.2.2 SIPタイマー, 2.5.2 起動

コマンド・オプション, D

T

タイマー・アフィニティ, 2.5.1

タイマー, 2.5

トラブルシューティング, 5

W

WebLogic Scripting Tool (WLST), 1.2.3.2

WebLogic Serverプラットフォーム, 1.1.1

WLST

構成, 2.4

起動, 2.4.1

Copyright © 2006, 2011, Oracle and/or its affiliates. All rights reserved.