| Oracle® WebLogic Communication Services 管理ガイド 11g リリース 1 （11.1.1) B55505-01 |
|
 戻る |
 次へ |
この章の以下の節では、OWLCS のデプロイメント トポロジについて説明します。
この章では、以下の用語を使用します。
管理サーバ -- ドメインのすべてのリソースをコンフィグレーションおよび管理するドメイン内の特殊なサーバ インスタンス。ドメインには管理サーバが 1 つのみ含まれます。
ドメイン -- 論理的に関連付けられたサーバ リソースのグループ。
高可用性 (HA) -- 妥当とされる長期間に渡って、運用状態が連続的に維持されるシステムまたはコンポーネントを指します。
JVM -- Java 仮想マシン。
管理対象サーバ -- リソースがデプロイされているドメイン内のサーバ インスタンス。ドメイン内には 1 つまたは複数の管理対象サーバが存在できます。
ノード -- 物理マシン。
OWLCS クライアント -- OWLCS サーバに接続し、プレゼンス、インスタント メッセージング (IM)、VoIP、Presence Web Services、Messaging Web Service などの機能を使用できるクライアント アプリケーション。たとえば、Oracle Communicator などです。
OWLCS では、単一ノードおよび複数ノードのデプロイメント トポロジがサポートされています。
オールインワン管理対象サーバ -- 物理マシン上のドメイン内の管理対象サーバに、すべての OWLCS コンポーネントがデプロイされます。OWLCS コンポーネントは、同じドメインにインストールされた管理サーバを使用してコンフィグレーションおよび管理されます。
詳細については、節 16.2.1「単一ノード トポロジ」を参照してください。
オールインワン管理サーバ -- 物理マシン上のドメイン内の管理サーバに、すべての OWLCS コンポーネントがデプロイされます。管理対象サーバはありません。OWLCS コンポーネントは、同じ管理サーバを使用してコンフィグレーションおよび管理されます。
詳細については、節 16.2.1「単一ノード トポロジ」を参照してください。
エンタープライズ デプロイメント -- OWLCS のエンタープライズ デプロイメントで推奨される最小の HA トポロジです。OWLCS コンポーネントは、SIP インフラストラクチャ、サービスおよびプレゼンス コンポーネントに分離されます。各コンポーネント グループは、2 つの異なるマシン上の固有のドメイン内にデプロイされます。
節 16.3.1「OWLCS エンタープライズ デプロイメント トポロジの概要」を参照してください。
オールインワン管理サーバおよびオールインワン管理対象サーバの 2 つのトポロジは、すぐに使用可能な操作性を提供することを目的としています。プレゼンス、インスタント メッセージング、Voice-Over-IP、Third Party Calling、Presence Web Service、および Messaging Web Service を OWLCS クライアントで使用できます。これらのトポロジはテストおよび評価環境での使用が推奨され、プロダクション環境での使用は推奨されません。高可用性のサポートは含まれていません。
オールインワン管理サーバ トポロジでは、唯一のサーバ (管理サーバ) が単一の JVM で実行されます。オールインワン管理対象サーバ トポロジでは、管理対象サーバがある JVM で実行され、管理サーバが別の JVM で実行されます。
この節では、Oracle WebLogic Communication Services (OWLCS) の高可用性トポロジであるエンタープライズ デプロイメントについて説明します。以下の節が含まれています。
OWLCS では複数ノードのデプロイメント トポロジがサポートされています。「SIP コンテナ クラスタ」は、アプリケーションに関連する状態を共有する一連の SIP コンテナ インスタンスとして定義されます。クラスタは、それぞれが 1 つの OWLCS インスタンスを実行する複数のノードで構成されます。
高可用性の OWLCS クラスタでは、以下の機能が提供されます。
SIP アプリケーション セッションに含まれるオブジェクトと値のレプリケーション
データベースによってバックアップされるロケーション サービス データ
OWLCS SIP ノード間での着信リクエストのロード バランシング
オーバーロード発生時にサーバを誤動作から保護し、適切に処理できないトラフィックを拒否するオーバーロード保護
クラスタ内のアプリケーション間の透過的なフェイルオーバ。アプリケーションのあるインスタンスに障害が発生した場合、インスタンスは応答しなくなり、セッションはクラスタ内の別のノード上の別のアプリケーション インスタンスにフェイルオーバできます。
|
注意 : OWLCS エンタープライズ デプロイメント トポロジのインストールおよびコンフィグレーションについては、『Oracle WebLogic Communication Services インストール ガイド』を参照してください。 |
Oracle WebLogic Communication Services の起動スクリプトでは、パフォーマンスを左右する多数の JVM パラメータにデフォルト値が使用されています。たとえば、JVM のガベージ コレクションやヒープ サイズのパラメータが省略されていることや、評価や開発以外の目的には適切でない値を使用していることがあります。プロダクション システムでは、十分なパフォーマンスを実現するために、さまざまなヒープ サイズやガベージ コレクションの設定でアプリケーションのプロファイリングを厳密に行う必要があります。プロダクション ドメインで JVM パフォーマンスを最大化するための推奨事項については、『Oracle WebLogic Communication Services 管理ガイド』を参照してください。
通常、Oracle WebLogic Communication Services ドメインは多数のエンジンおよびサーバで構成されており、異なる種類のサーバ間に依存関係があります。ドメインを起動するときは、一般に次の手順に従う必要があります。
ドメインの管理サーバを起動します。初期コンフィグレーションを提供するため、管理サーバを起動します。管理サーバは、各管理対象サーバの起動/停止のステータスをモニタする目的にも使用します。通常、管理サーバの起動には Configuration Wizard でインストールされた startWebLogic.sh/cmd スクリプトを使用するか、またはカスタムの起動スクリプトを使用します。
管理対象サーバを起動します。次に、startManagedWebLogic.sh/cmd スクリプトを使用するか、カスタムの起動スクリプトを使用して、管理対象サーバを起動できます。
リクエスト フローは JSR 289 に規定されています。 この仕様は SIPServlet 仕様に対する拡張です。
JSR 289 の詳細については、http://www.oracle.com/technology/tech/java/standards/jsr289/index.html を参照してください。
Oracle WebLogic Communication Services の各インスタンスのデフォルトの HTTP ネットワーク コンフィグレーションは、各サーバの「リスン アドレス」および「リスン ポート」の設定に基づいて決定されます。 ただし、Oracle WebLogic Communication Services では HTTP 上の SIP プロトコルはサポートされていません。SIP プロトコルは、UDP および TCP 転送プロトコル上でサポートされています。また、転送プロトコルとして TLS を使用する SIPS もサポートされています。
UDP、TCP、または TLS による転送を有効にするには、Oracle WebLogic Communication Services の各インスタンスに対して 1 つまたは複数の「ネットワーク チャネル」をコンフィグレーションします。ネットワーク チャネルは、そのサーバ インスタンスに対する特定のネットワーク接続の属性を定義するコンフィグレーション可能な WebLogic Server リソースです。基本的なチャネルの属性は次のとおりです。
接続でサポートされているプロトコル
接続のリスン アドレス (DNS 名または IP アドレス)
接続で使用されるポート番号
発信 UDP パケットで使用されるポート番号 (省略可能)
チャネルを発信接続に使用する場合に SIP ヘッダに埋め込まれるパブリック リスン アドレス (ロード バランサのアドレス)
Oracle WebLogic Communication Services の 1 つのインスタンスに複数のチャネルを割り当てて、複数のプロトコルをサポートすることや、マルチホームのサーバ ハードウェアに搭載されている複数のインタフェースを利用することができます。同一のチャネルを複数のサーバ インスタンスに割り当てることはできません。
SIP プロトコル用の新しいネットワーク チャネルをコンフィグレーションすると、UDP および TCP 転送プロトコルの両方が指定されたポートで有効です。UDP または TCP のどちらか一方の転送プロトコルのみを使用する SIP チャネルを作成することはできません。SIPS プロトコル用のネットワーク チャネルをコンフィグレーションすると、そのチャネルの接続では、転送プロトコルとして TLS が使用されます。
新しい SIP Server ドメインをコンフィグレーションする場合は、通常、システム内のエンジン層の各サーバとの通信に使用する複数の SIP チャネルを作成する必要があります。エンジン層のサーバは、レプリカ用にコンフィグレーションされたリスン アドレス属性を使用して、SIP 状態層のレプリカと通信できます。ただし、レプリカ間で相互に通信するには、レプリカで一意なリスン アドレスを使用する必要があります。
インストール、コンフィグレーション、およびデプロイメントでは、OWLCS の以下のアーティファクトが作成されます。
アプリケーションをデプロイするための .ear ファイルはミドルウェア ホーム ディレクトリにあります (例) : $MW_HOME/as11gr1wlcs1/communications/applications。通常、これらはファイル名で簡単に識別されます (たとえば、SMPP ドライバをデプロイする sdpmessagingdriver-smpp.ear など)。
以下に、高可用性の OWLCS トポロジ内のコンポーネントの詳細を示します。 図 16-4 に、トポロジをサポートする OWLCS ホストの詳細を示します。
|
注意 : これらのコンポーネントのコンフィグレーションの詳細については、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter』を参照してください。 |
OWLCS では、JSR 289 準拠の SIP コンテナによって WebLogic Server プラットフォームが拡張されています。 これにより、進化した通信アプリケーションに対応した、HTTP および SIP を処理する J2EE アプリケーションを開発できます。 このプラットフォームでは、SIP ベースの IP-PBX、および標準 SIP クライアントなどの他の SIP 要素と統合される、補完的な通信サービスの開発が可能になります。SIP コンテナの詳細については、『Oracle WebLogic Communication Services 管理ガイド』を参照してください。
複数の SIP コンテナは、OWLCS SIP 状態のレプリケーションを通じて相互にリンクしています。ある SIP コンテナ ノードに障害が発生した場合にノードのレプリケートされた状態を使用して別のコンテナ ノードが処理を引き継げるように、各コンピュータ上の OWLCS SIP 状態は SIP 状態層にある他のノードにレプリケートされます。
サードパーティ製ロード バランサは、着信トラフィックの負荷を分配します。また、障害が発生したノードから稼働中のノードにトラフィックをリダイレクトします。使用するロード バランサは、HTTP および SIP の両方のトラフィックをルーティングする機能を持ち、この機能がコンフィグレーションされている必要があります。ロード バランサの詳細については、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter』を参照してください。
OWLCS Proxy Registrar は、SIP プロキシ サーバとレジストラの機能を結合します。 主なタスクとしては、サブスクライバの登録、サブスクライバのロケーションの検索、前方へのリクエストのプロキシなどがあります。Proxy Registrar は、ユーザのロケーション データと登録データを Oracle データベースに格納します。これはオプションのコンポーネントです。Proxy Registrar の詳細については、節 14.1「Proxy Registrar」を参照してください。
OWLCS には、プレゼンス情報の集約機能として動作し、アプリケーションおよびエンドユーザがプレゼンス情報を使用するためのサブスクライブ/通知機能を提供する、プレゼンス サービスが含まれています。Web サービスを使用するか、または準拠する SIP ベースのエンドユーザ クライアントを使用して、アプリケーションを統合できます。
OWLCS を使用すると、Web サービス クライアントは、「Open Service Access, Parlay X Web Services, Part 14, Presence ETSI ES 202 391-14」で定義されている Parlay X Presence Web Service のサポートを通じて、プレゼンス サービスにアクセスできます。Parlay X Web Service では、HTTP Web サービス クライアントが、プレゼンス情報をパブリッシュおよびサブスクライブするプレゼンス サービスにアクセスできます。Parlay X Presence Web Service では、このような Web ベースのクライアントを開発するのに SIP プロトコルに精通している必要はありません。Web 開発者は、Web サービスの知識を利用してこのようなクライアントを作成できます。
Third Party Call Parlay X 2.1 通信サービスは Parlay X 2.1 Third Party Call インタフェースを実装します (標準参照 : ETSI ES 202 391-2 V1.2.1 (2006-12), Open Service Access (OSA); Parlay X Web Services; Part 2: Third Party Call (Parlay X 2))。Third-Party Call Control Web サービスの詳細については、『Oracle WebLogic Communication Services 開発者ガイド』を参照してください。
Aggregation Proxy は、Web サービス呼び出しを承認し、XCAP トラフィックを認証します。その後、Aggregation Proxy は、このトラフィックを Parlay X Web Service および XDMS にプロキシします。これはオプションのコンポーネントです。
Authentication Proxy は、認証の成功時に P-Asserted-Identity ヘッダをリクエストに挿入する SIP アプリケーションです。 Authentication Proxy アプリケーションでは認証自体は実行されません。すべての SIP アプリケーションに対し、SIP ダイジェスト ベースの認証が通常の方法でコンフィグレーションされています。P-Asserted-Identity ヘッダの値は、外部に格納された (たとえば、Oracle Identity Management または Database 内など) 認証済みユーザの優先的な SIP- または TEL-URL、あるいはその両方になります。
OWLCS には、ユーザが相互にファイルを転送できる Oracle 固有のファイル転送サービスが含まれています。
メッセージング サービスでは、「ETSI ES 202 391-5 V1.2.1 (2006-12), Open Service Access (OSA), Parlay X Web Services Part 5: Multimedia Messaging (Parlay X 2)」で定義されているように、SendMessage、ReceiveMessage、および MessageNotificationManager の各インタフェースの操作のサブセットのサポートが実装されています。
OWLCS STUN サービスは、STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) を実装します。 STUN サービスの詳細については、節 14.2「STUN サービス」を参照してください。
DAR コンフィグレーションです。アプリケーション ルータは、着信 SIP リクエストを適切なアプリケーションにルーティングする SIP アプリケーションです。アプリケーション ルータでは、処理される各 SIP リクエストにルート ヘッダを配置することにより、リクエストをルーティングします。リクエストには、それぞれ異なる宛先 URI を表すいくつかのルート ヘッダを配置できます。SIP リクエストは宛先 URI のチェーンを通じて送信されるか、または最初の宛先への到着時に新しい URI にプロキシされます。
Oracle Communicator は、組織内のユーザが相互に連絡を取り合うことのできるクライアント通信アプリケーションです。連絡先のプレゼンス (連絡先の状態) を表示し、インスタント メッセージの送信やファイルの共有を通じて相互に通信できます。
Oracle WebLogic Communication Services の SIP 状態層ノードでは、同時 SIP 呼に対するアプリケーション呼状態を管理します。SIP 状態層では、呼状態の単一のコピーを管理することも、サーバ マシンで障害が発生したりネットワーク接続が中断された場合でも呼状態データが失われないように、必要に応じてクラスタ間で複数のコピーを管理することもできます。
User Dispatcher を使用すると、Presence アプリケーションと XDMS アプリケーションのスケール変更を行えます。User Dispatcher は、SIP および XCAP の各リクエストを (HTTP 上で) 適切な宛先に一貫した基準でディスパッチするプロキシです。
Presence アプリケーションではデプロイメント内のすべてのユーザの状態が維持されるため、User Dispatcher を使用して Presence アプリケーションのスケール変更 (分散) を行えます。User Dispatcher では、(HTTP 上で) SIP および XCAP プロトコルを使用する、Presence サーバおよび XDMS サブアプリケーションへのリクエストのディスパッチをサポートします。
Oracle RAC 環境では、Oracle RDBMS がインストールされ、運用可能な状態である必要があります。 サポートされているバージョンは、10.2.0.4 および 11.1.0.7 です。『Oracle Clusterware Installation Guide 11g Release 1 (11.1.)』、『Oracle Real Application Clusters: For 11g Release 1 (11.1)』、および 『Oracle Real Application Clusters Installation Guide 11g Release 1』を参照してください。
Oracle WebLogic Communication Services の SIP 状態層は、同時 SIP 呼のアプリケーション呼状態を管理するサーバ インスタンスのクラスタです。SIP 状態層では、呼状態の単一のコピーを管理することも、サーバ マシンで障害が発生したりネットワーク接続が中断された場合でも呼状態データが失われないように、必要に応じて複数のコピーを管理することもできます。
SIP 状態層クラスタは、1 つまたは複数の「パーティション」として構成します。 1 つのパーティションは、同時呼状態データの同じ部分を管理する、1 つまたは複数の SIP 状態層サーバ インスタンスで構成されます。単一サーバの Oracle WebLogic Communication Services インストールや、エンジン層と SIP 状態層にそれぞれ 1 つずつサーバがある 2 つのサーバのインストールでは、すべての呼状態データが単一のパーティションで管理されます。同時呼状態のサイズが、単一のサーバ インスタンスで処理できる最大サイズを超える場合には、複数のパーティションが必要です。複数のパーティションを使用する場合、同時呼状態はそれらのパーティション間で分割され、各パーティションはそれぞれデータの別々の部分を処理します。たとえば、2 つのパーティションで構成される SIP 状態層の場合、1 つ目のパーティションでは、同時呼状態の半分を管理し (たとえば、セッション A ～ M)、2 つ目のパーティションでは、残りの呼 (セッション N ～ Z) を管理します。
多くの場合、個々のサーバで管理できる呼状態の最大サイズは、Java 仮想マシンのヒープ サイズによって制限されます。
同じパーティション内でサーバを追加して、呼状態データのコピーを処理できます。同じパーティションに複数のサーバが属する場合には、各サーバは、呼データの同じ部分のコピー (呼状態の「レプリカ」) を処理します。パーティション内のサーバで障害が発生したり、ネットワーク障害のためにアクセスできない場合には、エンジン層に対する呼状態データの提供は、パーティション内の別のレプリカによって行われます。Oracle では機器やネットワークの障害に備え、プロダクション インストール用の各パーティションに 2 つのサーバをコンフィグレーションすることを推薦します。冗長性を強化するため、1 つのパーティションには最大 3 つのレプリカを含めることができます。
以下の節では、別個の SIP 状態層を使用する Oracle WebLogic Communication Services インストールの典型的な例を説明します。
単一のパーティションに 2 つのサーバがある SIP 状態層は、最も単純な状態層のコンフィグレーションです。
たとえば、例 16-1 に示す datatier.xml コンフィグレーション ファイルは、2 つのレプリカのコンフィグレーションを作成します。
例 16-2 に示すように、datatier.xml で複数の partition エントリを作成することで、複数のパーティションを作成できます。
各パーティションに複数の SIP 状態層サーバを定義すると、呼状態のレプリカを追加できます。例 16-3 は、それぞれ 2 つのサーバ (レプリカ) を含む 2 つのパーティションを持つシステムの定義に使用される datatier.xml コンフィグレーション ファイルを示します。
例 16-3 小規模デプロイメントでの SIP 状態層のコンフィグレーション
<?xml version="1.0" encoding="UTF-8"?> <data-tier xmlns="http:...."> <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>
Oracle WebLogic Communication Services では、長期間維持する呼状態データを Oracle RDBMS に格納して RAM を節約することができます。RDBMS の永続性を有効にすると、SIP 状態層は、呼のダイアログが確立された後、呼状態データをデフォルトで RDBMS に保存します。それ以降のダイアログ境界で、呼状態を変更したり、削除する必要がある場合は、保存された呼状態データを抽出したり、削除します。
Oracle では、アプリケーション設計者用の API を用意し、どのようなときに呼状態データを SIP 状態層に保持すべきかについての「ヒント」を提供しています。呼状態データを頻繁に RDBMS で保存したり、特定の呼の永続性を無効にするためにこれらのヒントを使用できます。
Oracle WebLogic Communication Services では、RDBMS を使用して、SIP 状態層のインメモリ レプリケーション機能を補うことができます。RDBMS 使用時にレイテンシ パフォーマンスを改善するため、SIP 状態層はアクティブに変更されている呼状態 (たとえば、設定中の新しい呼に対応している状態) と共に、SIP タイマーをメモリ内で管理します。呼状態はダイアログが確立された後に自動的に保持され、それ以降のダイアログ境界で呼は進行中か、アプリケーション開発者が加えた保持に関するヒントに対応しているかのどちらかです。
RDBMS と共に使用する場合、SIP 状態層は (このドキュメントでは、「状態層」という用語を「データ層」に代わるものとして使用しています)、すべての呼状態のデータベースへの書き込み (または削除) を処理する 1 つのレプリカ サーバ インスタンスを選択します。使用可能なレプリカならどれでも、次の読み込みのために必要に応じて永続的な保持から呼状態を検索するために使用できます。
ドメインがエンジン層への接続を管理するため SIP-aware ロード バランサを使用している場合、RDBMS への呼状態の格納をエンジン層キャッシャと組み合わせて使用することができます。
地理的な冗長性では、地理的に分割された SIP サーバのデプロイメントを使用することで、プロバイダの途切れることのないトランザクションと通信が保証されます。
プライマリ サイトでは、各種の SIP トランザクションおよび通信を処理し、トランザクションの境界が確定した時点で、処理中のトランザクションに関連付けられている状態データをセカンダリ サイトにレプリケートできます。プライマリ サイトに障害が発生すると、呼は処理のために障害の発生したプライマリ サイトからセカンダリ サイトにルーティングされます。同様に、障害からの回復時、呼はプライマリ サイトに再び戻されます。詳細については、『Oracle WebLogic Communication Services 管理ガイド』を参照してください。
上の図は、地理的な冗長性を示しています。処理は次のように進行します。
プライマリ クラスタ サイトで呼が開始され、呼の設定と処理が正常に行われます。
呼は通常どおりサイトの SIP 状態層にレプリケートされ、セカンダリ サイトへのレプリケーションが可能になります。
SIP 状態層にある単一のレプリカによって、レプリケート対象の呼状態データが、レプリカ サイトにコンフィグレーションされた JMS キューに配置されます。
WAN 上の JMS を使用して、使用可能ないずれかのエンジンに呼が送信されます。
セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。メッセージを受信すると、セカンダリ サイトのエンジンが呼状態データを保存し、プライマリ サイトのサイト ID 値を割り当てます。
Oracle の高可用性ソリューションには、あらゆるレベルのシステムに対するフェイルオーバのサポートが含まれています。フェイルオーバでは、正しく機能していない、または稼動していないコンポーネントの機能が、スタンバイ コンポーネントまたは代替コンポーネントによって処理されます。これは手動による介入なしに行われ、多くの場合、システムがフェイルオーバ アクションを実行していることをエンドユーザ側では検出できません。フェイルオーバには、「セッション フェイルオーバ」と「サービス フェイルオーバ」という 2 つの主な種類があります。
「セッション フェイルオーバ」は、セッション、接続、または電源が中断した場合に発生します。セッション フェイルオーバ時は、進行中の呼またはリクエストがバックアップ ノードによって処理され、この状態が発生したことをユーザ側では検出しません。SIP コンテナは、セッションの障害からの回復に役立つサービスを上位レベルに対して提供します。SIP プロトコルは、事前定義された特定の時間 (毎時など) に状態を再構築します。これは、信頼性のないネットワークを保護するために設計されています。
「サービス フェイルオーバ」が発生すると (クラスタ内のあるノードが停止した場合など)、クラスタ内の他のノードによって負荷が処理されます。その時点で処理中の個別のリクエストは失敗しますが、後続のリクエストは稼働中のノードによって処理されます。
高可用性のコンフィグレーションでは、Proxy Registrar、Third-Party Call Control および他の分散可能アプリケーションなどの、wlcs-services ドメインで実行中のサービスで、セッション フェイルオーバがサポートされています。また、プレゼンスおよび他の非分散型アプリケーションなどの、wlcs_presence ドメインで実行中のサービスでは、サービス フェイルオーバがサポートされています。
高可用性のデプロイメントで複数のノードを使用している場合、OWLCS プレゼンスはノード (サーバ) 間でサービスを分散します。エンティティ (E1) のプレゼンス情報に対するリクエストが作成されると、リクエストはノード 1 (N1) に渡されます。リクエスト中に N1 が停止すると、障害の発生がユーザに通知されます。リクエストを再送信すると、リクエストはノード 2 (N2) で処理されます。再送信されたリクエスト、または最初の障害後に作成されたその他のリクエストでは、障害は発生しません。
フェイルオーバは、Presence サーバのより高度な可用性を実現するために User Dispatcher が使用できる手法です。Presence サーバでは (確立されたサブスクリプションなどの) 状態がレプリケートされないため、クライアントは新しいサブスクリプションを設定することで新しいサーバ ノード上に状態を再作成する必要があります。また、サブスクリプションは SIP ダイアログであり、User Dispatcher はレコード ルーティングではないため、あるノードから別のノードへのサブスクリプションをフェイルオーバすることはできません。すべての後続のリクエストはルート セットに続き、「古い」ノードで終了します。
これは、「障害が発生している」サーバからフェイルオーバするときの問題ではありません。該当するノードはトラフィックを処理しておらず、ダイアログ内のリクエストは最終的にエラー応答やタイムアウトを取得してダイアログが終了するためです。ただし、バックアップ ノードから (修復された) 元のノードにユーザを再び戻して、障害後の分散を均等に保つ必要がありますが、これによってプレゼンス機能の不具合が起きる可能性があります。実行中のあるサーバから別のサーバにサブスクリプションを移行するには、クライアントまたはサーバのいずれかを再起動するしかありません。
ただし、サブスクリプションを保持しているサーバでは、終了の NOTIFY を送信し、サブスクリプション状態を破棄することで、これをアクティブに終了させることができます。これにより、クライアントでは新しい最初の SUBSCRIBE が発行され、新しいダイアログが確立されます。ある稼働中のノードから別のノードにサブスクリプションを移行する場合、User Dispatcher は (最初のリクエストにのみ影響する) トラフィックをフェイルオーバし、サブスクリプションを終了するよう現在のサーバに指示する必要があります。
ノード セットが変更された場合は、プレゼンティティを移行する必要があります。移行するには、Presence アプリケーションで一部または全部のサブスクリプションを終了する必要があります。
最も基本的な方法では、すべてのノード上の Presence アプリケーションに通知し、すべてのサブスクリプションを終了させます。この場合の問題は、一定期間にわたるとはいえ、大量のトラフィックが突発的に生成されることです。終了期間が長いほど、すべてのユーザが正しいプレゼンス状態を取得するまでに時間がかかるため、この期間に不適切なプレゼンス状態が生じます。
この問題を最適化するため、実際に終了する必要のあるサブスクリプション (移行されたサブスクリプション) のみを終了できます。問題は、どのユーザがこれらに該当するのかを User Dispatcher が認識しておらず (アルゴリズムに基づいてステートレスな分散を行うため)、Presence アプリケーションでも認識していない点です (どのユーザがサブスクリプションを保持しているかのみ認識しているため)。ただし、Presence アプリケーションがすべてのサブスクリプションを反復処理し、各サブスクリプションについて、このユーザがこの Presence ノードに移動するかどうかを User Dispatcher に尋ねることができれば、Presence サーバでは戻らないサブスクリプションのみを終了できます。これは負荷の大きい操作かもしれませんが、各 Presence サーバが User Dispatcher と共に配置されるという制約の下で、これらの各コールバックは同じ JVM 内で行われます。
もう 1 つの解決策は、ある時点ではユーザが 1 つの Presence ノードにのみ存在することを Presence サーバで保証することです。これを実行するには、Presence アプリケーションが新しいプレゼンティティ (まだ状態がないプレゼンティティ) の PUBLISH または SUBSCRIBE を受信したときに、近隣のすべてのノードにメッセージをブロードキャストするようにします。このブロードキャスト メッセージを受信した他の Presence ノードが、このプレゼンティティのアクティブなサブスクリプションをすでに保持している場合、クライアントが新しいサーバで新しいサブスクリプションを確立できるように、そのサーバは該当するサブスクリプションを終了する必要があります。
Presence アプリケーションでこの機能を使用する場合、User Dispatcher では、ある稼働中のノードから別のノードにユーザを移行するために追加の手順を実行する必要はありません。
別の方法として、障害の発生したノードからトラフィックを引き継ぐ準備が整っている、アイドル状態のサーバのスタンバイ プールを用意することもできます。アクティブ ノードに障害が発生すると、User Dispatcher はそのすべてのトラフィックをスタンバイ プールの 1 つのサーバに再分散します。これで、このノードがアクティブになります。障害の発生したノードが最終的に修復されると、そのノードはスタンバイ プールに追加されます。そのため、障害の発生したノードが再開しても、稼働中のノードからユーザを「再び」移行する必要はありません。
この方法ではハードウェアを追加する必要があり、ハードウェア リソースの使用が最適化されません。
Presence サーバでは、いくつかの種類の障害が発生する可能性があります。User Dispatcher では、障害の種類に応じて異なるアクションを実行する必要があります。
致命的な障害の場合、すべての状態情報は失われ、確立されたセッションは失敗します。ただし、エラー応答に応じて、新しい SIP ダイアログを使用することで、サブスクリプション (プレゼンス サブスクライブ セッション) は存続することができます。応答コードが 481 の場合、プレゼンス クライアントは RFC 3265 に従って新しい SUBSCRIBE ダイアログを確立する必要があります。これはプレゼンス側からは障害と見なされません。その他のエラー応答はすべて、(クライアントの実装に応じて) クライアントでエラーとして処理され、障害と見なされます。
致命的な障害の後、サーバには障害発生前の時点からのダイアログ状態はなく、このため、この時点で到着したすべての後続のリクエストに対して 481 応答が返されます。障害時は、(最初および後続の) すべてのトランザクションは 481 以外のエラー コードで終了します。最も可能性があるのは 500、または内部 503 または 408 です (ルート パスにプロキシが含まれているかどうか、および障害の性質に応じて異なります)。
通常は、致命的な障害の結果、サーバ プロセスまたはマシン全体が再起動されます。
Presence サーバ ノードで障害が検出された場合、User Dispatcher はいくつかのアクションを実行できます。このアクションの目的は、失敗したサブスクリプションとパブリケーションの数、および回復にかかる時間の点から、障害の影響を最小限に抑えることです。User Dispatcher ではこの他にも、アクティブなサーバ間で分散を可能な限り均等に保つ必要があります。
このバージョンの User Dispatcher で使用されるフェイルオーバ アクションは、プール内のノードを無効にする方法です。ResizableBucketServerPool を使用する場合は、追加操作と削除操作が確定的でないため、これはノードを削除するよりも適切な方法です。つまり、ノードを追加した結果が以前の追加操作と削除操作のシーケンスに依存するのに対し、無効化の操作では、アクティブなノードと無効なノードのセットがある場合に、分散内で常に同じ変更が行われます。
アクティブにされたオーバーロード ポリシーでは、複数の種類の障害を示すことがありますが、この主な目的は、システムが処理するトラフィックの負荷が大きくなりすぎないように保護することにあります。このような状況が障害として検出されると、トラフィックが適度に均等に分散されている場合にすべてのノードがオーバーロード状態、またはそれに近い状態になるため、フェイルオーバ アクションによってクラスタ全体が停止する可能性があります。ディスパッチャがクラスタのあるノードを削除し、そのノードのトラフィックを残りのノードに再分散した場合、それらのノードは確実にオーバーロード状態に陥り、連鎖反応が起こります。
このオーバーロード状態は、システムに負荷がかかっていなくてもオーバーロード ポリシーのアクティブ化を引き起こすソフトウェア障害と区別することが困難ですが、オーバーロード ポリシーが無効でない限り、フェイルオーバ アクションを実行することが適切な場合があります。システムが実際にオーバーロード状態にある場合、システムの機能は制限される可能性があり、フェイルオーバは無効になります。
User Dispatcher は、(オーバーロード ポリシーがアクティブであることを示す) 503 応答が検出された場合、フェイルオーバを行いません。ただし、サーバが 503 応答を返す代わりにメッセージが削除される最大のオーバーロード ポリシー状態にある場合、User Dispatcher モニタは内部 408 を受信します。これは応答のないサーバと区別されずに、フェイルオーバが発生します。
障害検出メカニズムに応じて、異なるディスパッチャ インスタンス間で、フェイルオーバ イベント (または結果として生じる状態) を同期する必要があります。これは、エラー応答など、クラスタ全体での検出メカニズムの整合性が保証されていない場合に必要です。たとえば、あるサーバ ノードがあるリクエストに対して 503 応答を送信した後、すぐに正常に動作するとします (これは、オーバーロード ポリシーの一時的な障害により起こる場合があります)。1 つの 503 のみが送信された場合、これは 1 つのディスパッチャ インスタンスでのみ受信されます。このイベントがフェイルオーバを発生させると、このディスパッチャ インスタンスはクラスタの残りのインスタンスと同期しなくなります。さらに、一定期間にいくつかの 503 応答を受け取ってフェイルオーバを発生させるように猶予期間が実装されている場合でも、障害期間が猶予期間と同じである場合は、依然として競合状態のリスクが生じます。
以下の方法を使用すると、ディスパッチャ インスタンスのクラスタ全体で、フェイルオーバ後の状態が確実に同期されます。
Presence アプリケーションでは、各ユーザが複数の (増え続ける可能性のある) 他のユーザをサブスクライブするため、急激に増大する負荷が生成される可能性があります。このため、多くの混乱を伴わずにクラスタを動的に拡張するための方法が必要です。たとえば、従来の電気通信アプリケーションではクラスタのアップグレードのためトラフィックが少ない時間帯にすべてのサーバを停止することが容認されますが、これと比較すると、プレゼンス システムではより高度な可用性の要件が求められます。
クラスタの拡張では、Presence ノードと User Dispatcher ノードの両方を追加する必要がある場合があります。
新しい Presence サーバをクラスタに追加した場合、分散を適度に均等化するために、一部のプレゼンティティを古いノードから新しいノードに移行する必要があります。クラスタ変更時にシステム上のトラフィックが膨大にならないように、移行は最小限に抑える必要があります。
新しい User Dispatcher をクラスタに追加した場合、その User Dispatcher ノードは、他のディスパッチャ ノードと同じディスパッチ状態を達成する必要があります。プールの実装に応じて、他のディスパッチャ ノードと状態を同期する必要があります (たとえば、永続性のあるバケット プール実装を使用している場合など)。
|
注意 : プレゼンス クラスタ内の各 User Dispatcher では、ディスパッチ先となる Presence サーバのリストに、クラスタ内のすべての Presence サーバ インスタンスが含まれるようにコンフィグレーションする必要があります。 |
指定のプレゼンティティのサーバ ノードを検出するために使用されるアルゴリズムに応じて、新しいノードを追加または削除する際に別のノードに「移行される」プレゼンティティの数は異なります。プールの実装を最適化することで、この数は最小限に抑えられます。
ノード セットが更新された場合、分散を均等にするために、一部のプレゼンティティを移行する必要があります。各種の移行方法については、「プレゼンティティの移行」で説明しています。
これらの使用例では、1 つまたは複数の Presence サーバ ノードでのさまざまな障害状況に対して、User Dispatcher がどのように対処するかを示しています。
クラスタは 4 つの Presence サーバで構成され、各ノードは User Dispatcher と Presence アプリケーションがデプロイされた 1 つの OWLCS インスタンスで構成されています。100.000 ユーザが 4 つのサーバに均等に分散されます (各ノードに 25.000)。この中の 1 つのサーバで異常に長い GC による中断が原因で、メッセージの処理がガベージ コレクタによってブロックされるため、取得中の SIP キューがいっぱいになり、オーバーロード ポリシーがアクティブになります。60 秒後、処理が再開され、サーバは引き続きメッセージを処理します。
User Dispatcher はフェイルオーバを行いませんが、障害が発生したノードへのトラフィックの送信を続けます。この場合、すべての PUBLISH リクエストと最初の SUBSCRIBE リクエストは、障害が発生したノードに送信されるため、別のノードに移行されるセッションはありません。障害時に到着する最初の SUBSCRIBE は失敗し、481 以外のエラー (503 など) が発生します。障害が発生したノードの期限が切れるか、障害が報告される場合、新しいサブスクリプションを試して設定するかどうかはクライアント次第です。すべての PUBLISH リクエストと最初の SUBSCRIBE リクエストでは、失敗が生成されます。
障害が発生したノードが通常操作に戻る場合、すべてのトラフィックは再度処理され、失敗するリクエストはありません。セッションがフェイルオーバされないため、すべてのプレゼンス状態が再び「正常」になるまでにかかる時間は最小限で済みます。
このような場合のノードを「停止」として検出する方法でモニタ機能が実装される場合、一部のユーザは別のノードに移行され、このノードが復旧すると、ユーザは再び戻されます。このため、一定期間にある程度の負荷が増加します。トラフィックの負荷がきわめて高いためにオーバーロード ポリシーがアクティブになった場合、この移行は適切ではありません。この状態は再度発生する可能性が高く、その他のサーバもオーバーロードに近い状態になるためです。これにより、連鎖反応が生じるため、クラスタ全体が停止したり、サービスが完全に失われたりします。
この使用例では、短期間 (たとえば 5 秒間) でオーバーロード状態とそうでない状態を行き来する Presence サーバについて説明します。これは、システムの機能が制限され、かろうじてトラフィックの負荷を処理できる場合によく発生します。ただし、特定のノード上の他の障害のみが原因で発生することもあります。User Dispatcher は、「1 つの Presence サーバが 60 秒間オーバーロードする」の場合とまったく同様に動作します。障害の期間がより短いために、失敗したセッション数とフェイルオーバ セッション数が少ないことを除けば、同じ結果になります。
OWLCS ソフトウェアまたはその上位にデプロイされたアプリケーションに障害が発生すると、すべてのスレッドがロックされます (デッドロック)。これにより、最終的にキュー内がいっぱいになるため、実際にシステムがオーバーロード状態ではなくても、オーバーロード ポリシーがアクティブになります。これは永続的なエラーのため、解決するにはサーバを再起動するしかありません。
モニタ機能が実装されているかどうか、およびモニタ機能の実装方法に応じて、影響を受けるユーザ数を最小限に抑えることができます。ただし、この状態を「実際の」オーバーロード状態と区別することはできません。この場合、フェイルオーバの実行は最適な方法ではありません。
クラスタは 4 つの Presence サーバで構成され、各ノードは User Dispatcher と Presence アプリケーションがデプロイされた 1 つの OWLCS インスタンスで構成されています。100.000 ユーザが 4 つのサーバに均等に分散されます (各ノードに 25.000)。これらの Presence サーバのうちの 1 台がハードウェア障害が原因で停止します。故障したサーバを新しいサーバと交換するには手動による操作が必要です。2 時間が経過した後、サーバは再び起動し、実行します。障害の種類に応じて、障害が発生したノードにプロキシされるトランザクションに対して戻される応答コードは、408 または 503 になります。
この場合、障害の期間がサブスクリプションの有効期間よりも (ほとんどの場合) 長いため、このノード上のすべてのセッションは失敗します。モニタ サーバがフェイルオーバで実装される場合、障害時間は検出時間 (秒) に対して最小限で済みます。ユーザは移行機能によって移行されます。これにより、期間中の負荷が増加します。
User Dispatcher も障害が発生したノードで実行していたため、サーバを新しいマシンに交換する際に、User Dispatcher に関して維持されていたデータはすべて失われます。
クラスタは 3 つの Presence サーバで構成され、各ノードは User Dispatcher と Presence アプリケーションがデプロイされた 1 つの OWLCS インスタンスで構成されています。100.000 ユーザが 3 つのサーバに均等に分散されます (各ノードに 33.000)。新しいノードがインストールされ、クラスタに追加されます。新しいノードを追加するには、次の一連の操作を実行します。
新しいノード上の User Dispatcher と Presence アプリケーションは、クラスタの残りのノードと同じ設定でコンフィグレーションされます。この設定では、永続性のあるプール実装の場合、新しい User Dispatcher に分散状態を同期する必要があります。
addServer JMX 操作は、クラスタの User Dispatcher MBean に対して新しいノードで起動されます。これにより、すべての User Dispatcher ノード (新しいノードを含む) に対して addServer 操作が起動されます。
ロード バランサは、最初のリクエストが新しい User Dispatcher ノードに送信されるように、新しいノードで再びコンフィグレーションされます。
移行方法に応じて、Presence アプリケーションに対して (クラスタ MBean サーバを使用して) さらに JMX 操作を起動できます。
この結果、8.000 ユーザが移行され、ユーザの新しい分散は各ノードで 25.000 になります。移行方法に応じて、一定期間でシステムにかかるトラフィックの負荷が増加します。
クラスタは 4 つの Presence サーバで構成され、各ノードは User Dispatcher と Presence アプリケーションがデプロイされた 1 つの OWLCS インスタンスで構成されています。100.000 ユーザが 4 つのサーバに均等に分散されます (各ノードに 25.000)。1 つの Presence ノードがクラスタから削除されます。ノードを削除するには、次の一連の操作を実行します。
削除するノードを含めないように、ロード バランサを再びコンフィグレーションします。
クラスタのすべての User Dispatcher からノードを削除するために、removeNode JMX 操作が起動されます。クラスタ MBean を使用して、操作を委任します。
移行方法に応じて、削除するノードに対してさらに JMX 操作を起動できます。
削除するノードからすべてのユーザが移行されると (この期間は移行方法によって異なります)、ノードは最終的に停止され、クラスタから削除されます。
この結果、8.000 ユーザが移行され、ユーザの新しい分散は各ノードで 33.000 になります。
