| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング > BEA Tuxedo CORBA アプリケーションのスケーリング |
|
Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング
|
BEA Tuxedo CORBA アプリケーションのスケーリング
ここでは、BEA Tuxedo CORBA アプリケーションのスケーリングの基本概念とそれを行うためのタスクの概要を説明します。ここでは、以下の内容について説明します。
BEA Tuxedo CORBA アプリケーションの詳細と例については、CORBA サーバ・アプリケーションのスケーリングを参照してください。
BEA Tuxedo CORBA アプリケーションのスケーリングについて
ここでは、以下の内容について説明します。
アプリケーションのスケーラビリティ要件
多くのアプリケーションは、1 〜 10 のサーバ・プロセスと 10 〜 100 のクライアント・アプリケーションが動作している環境で適切に機能します。しかし、ビジネス環境のアプリケーションでは、数百の実行コンテキスト (コンテキストはこの場合はスレッドまたはプロセス)、数万のクライアント・アプリケーション、および数百万のオブジェクトを十分な性能水準でサポートしなければならない場合があります。
急激に増加する要求に晒されると、アプリケーションでは資源の不足や性能のボトルネックがすぐに明らかになります。したがって、スケーラビリティは BEA Tuxedo アプリケーションの極めて重要な特性です。
高度にスケーラブルな BEA Tuxedo アプリケーションは、次のようにしてビルドできます。
BEA Tuxedo スケーラビリティの特徴
BEA Tuxedo では、以下の手段で大規模なアプリケーションのデプロイメントをサポートします。
オブジェクト状態管理の使用
ここでは、以下の内容について説明します。
大規模なクライアント/サーバ・システムでは、スループットと応答時間を最適化することが重要であるため、オブジェクト状態管理は基本的な考慮事項となっています。オブジェクト状態管理の使用の詳細については、状態を持たないオブジェクト・モデルの使用方法および『CORBA 技術情報』の「Process-Entity デザイン・パターン」を参照してください。
CORBA オブジェクト状態モデル
BEA Tuxedo CORBA では、3 種類のオブジェクト状態管理モデルをサポートしています。
これらのモデルの詳細については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』
の「CORBA サーバ・アプリケーションの概念」を参照してください。メソッド・バウンド・オブジェクト
メソッド・バウンド・オブジェクトは、クライアント呼び出しの有効期間中のみ、マシンのメモリにロードされています。呼び出しが完了すると、オブジェクトは非活性化され、そのオブジェクトの状態データはすべて、メモリからフラッシュされます。ここでは、メソッド・バウンド・オブジェクトは状態を持たないオブジェクトと見なされます。
メソッド・バウンド・オブジェクトを使用すると、アプリケーション内に状態を持たないサーバ・モデルを作成できます。状態を持たないサーバ・モデルを使用することで、活性化されたオブジェクトに送信済みの要求を、利用可能な任意のサーバへ移動できます。これにより、何千ものオブジェクト、さらには何百万ものオブジェクトの同時実行が可能になります。クライアント・アプリケーションのビューからは、すべてのオブジェクトがサービス要求に利用可能です。ただし、サーバ・アプリケーションがオブジェクトをメモリにマッピングするのが、クライアント呼び出しの有効期間中のみであるため、任意の時点でメモリ内にあるオブジェクトのうち、サーバ・アプリケーションによって管理されているものはほとんどありません。
プロセス・バウンド・オブジェクト
プロセス・バウンド・オブジェクトは、最初に呼び出されたときから、そのオブジェクトが実行されているプロセスがシャットダウンされるまで、メモリ内にとどまります。プロセス・バウンド・オブジェクトは、クライアント呼び出し時に活性化することも、クライアントが呼び出される前に、事前活性化オブジェクトとして明示的に活性化することもできます。アプリケーション側で、プロセス・バウンド・オブジェクトの非活性化を制御できます。ここでは、プロセス・バウンド・オブジェクトは状態を持つオブジェクトと見なされます。
しかるべき場合には、大量の状態データを備えたプロセス・バウンド・オブジェクトをメモリ内に残して、複数のクライアント呼び出しの処理を行うことができます。それにより、クライアント呼び出しのたびにオブジェクトの状態データを読み書きせずに済みます。
トランザクション・バウンド・オブジェクト
トランザクション・バウンド・オブジェクトも、状態を持つオブジェクトであると見なされます。なぜなら、トランザクションの範囲内においては、これらのオブジェクトは呼び出しと呼び出しの合間でもメモリ内に残存できるからです。オブジェクトがトランザクション範囲内で活性化された場合、そのオブジェクトはトランザクションがコミットまたはロールバックされるまでは、活性化されたままです。オブジェクトがトランザクション範囲外で活性化された場合、その振る舞いはメソッド・バウンド・オブジェクトと同様です。つまり、オブジェクトはクライアント呼び出しの有効期間中だけロードされています。
状態を持たないオブジェクトおよび状態を持つオブジェクトのインプリメント
一般に、アプリケーション開発者は状態を持たないオブジェクトのインプリメントと状態を持つオブジェクトのインプリメントのコストを均衡化する必要があります。
状態を持たないオブジェクトと状態を持つオブジェクトについて
状態を持たないオブジェクトを使うか、状態を持つオブジェクトを使うかの判断は、さまざまな要因に左右されます。永続状態を持つオブジェクトの初期化コストが高額の場合は、オブジェクトが会話中にアイドル状態であっても、状態を持ったままにしておくほうが合理的です。初期化コストが嵩む理由としてはたとえば、オブジェクトのデータが多くの領域を占めている、または永続状態が活性化を行うサーバントから非常に遠隔のディスクにあることなどが考えられます。オブジェクトを活性化されたままにしておくコストが、マシンのリソース使用率との関連で高額になる場合は、そのようなオブジェクトは状態を持たないようにするほうが合理的です。
オブジェクトの状態を、アプリケーションに合わせて効率的かつ適切な方法で管理することにより、アプリケーションの能力を最大限に高めて、多数のオブジェクトを使用する多数のクライアント・アプリケーションを同時にサポートできます。オブジェクト状態の管理方法は、アプリケーション固有の特性や要件に応じて変わります。CORBA アプリケーションの場合、オブジェクト状態の管理は、これらのオブジェクトに method 活性化方針を割り当てることによって行います。この方針を割り当てると、アイドル状態のオブジェクトのインスタンスを非活性化して、マシン・リソースをほかのオブジェクト・インスタンスに割り当てられるようにする効果があります。
状態を持たないオブジェクトを使用すべき場合
サーバ・リソースはオブジェクトがアイドル状態のときには絶対に使用されないため、状態を持たないオブジェクトは一般に、サーバ・リソースの性能を高め、最適な使い方を実現します。状態を持たないオブジェクトの使用は、サーバ・アプリケーションのインプリメンテーションを行うのには良い手法です。特に、次の場合には適しています。
状態を持たないオブジェクトにすることで、一般に、クライアント・アプリケーションからの入力待機中にサーバ・アプリケーションのリソースが無駄に予約されることは確実になくなります。
状態を持たないオブジェクト・モデルを採用したアプリケーションの特長は次のとおりです。
状態を持つオブジェクトを使用すべき場合
状態を持つオブジェクトは、いったん活性化されると、オブジェクトが存在しているプロセスがシャットダウンされたり、オブジェクトが活性化されているトランザクションが完了したりといった、特定のイベントが発生するまで、メモリ内にとどまります。
状態を持つオブジェクトの使用が推奨されるのは、以下のような場合です。
注記 オブジェクトがどのようにトランザクションに関与する可能性があるかは、慎重に考慮する必要があります。オブジェクトは、一時的または永続的に、特定プロセスにバインドできます。一時的にバインドされたものがトランザクション・バウンド・オブジェクト、永続的にバインドされたものがプロセス・バウンド・オブジェクトです。トランザクションに関与するオブジェクトを、別のクライアント・アプリケーションまたはオブジェクトから呼び出すことはできません。呼び出そうとした場合、BEA Tuxedo はおそらく、そのオブジェクトが使用中であることを示すエラーを返します。多数のクライアント・アプリケーションでの使用が意図されている、状態を持つオブジェクトが、頻繁にまたは長期にわたってトランザクションに関与している場合、それがボトルネックにつながる可能性があります。
状態を持つオブジェクトは、以下のような振る舞いをします。
たとえば、オブジェクトがデータベースをロックしており、メモリ内に大量のデータをキャッシュしている場合、その状態を持つオブジェクトが使用している、そのデータベースとメモリは、トランザクション継続中、一貫してほかのオブジェクトに対しては使用不可となる可能性があります。
パラレル・オブジェクト
パラレル・オブジェクトは、定義上は状態を持たないオブジェクトなので、複数のサーバに同時に存在できます。BEA Tuxedo のリリース 8.0 では、インプリメンテーション・コンフィギュレーション・ファイル (ICF) を使用して、特定のインプリメンテーションのすべてのオブジェクトを強制的にパラレル・オブジェクトにすることができます。それにより、性能を向上させる効果が得られます。パラレル・オブジェクトの詳細については、パラレル・オブジェクトの使用を参照してください。
サーバ・プロセスおよびサーバ・グループの複製
ここでは、以下の内容について説明します。
サーバ・プロセスとサーバ・グループの複製の詳細については、次のトピックを参照してください。
サーバ・プロセスおよびサーバ・グループの複製について
BEA Tuxedo CORBA 環境では、CORBA オブジェクトを複数のサーバにわたるようにデプロイし、フェイルオーバーの信頼性を高めるとともに、クライアントの作業負荷をロード・バランシングによって分担できます。BEA Tuxedo CORBA ロード・バランシングは、デフォルトで有効になっています。ロード・バランシングのコンフィギュレーションの詳細については、システム制御のロード・バランシングの有効化を参照してください。BEA Tuxedo CORBA の機能を使用してのアプリケーション作業負荷の分散の詳細については、CORBA アプリケーションの分散を参照してください。
BEA Tuxedo アーキテクチャにより、次のようなサーバ編成が提供されます。
このアーキテクチャにより、アプリケーションを需要の多い期間または少ない期間に適合させたり、アプリケーションに対して要求される内部変更に対処したりするために、新規のサーバ、グループ、またはマシンを動的に追加または削除できます。BEA Tuxedo の実行時に、使用可能な各サーバ間で要求をルーティングすることにより、ロード・バランシングとフェイルオーバーがもたらされます。
システム管理者は、次の処理を行うことによって、BEA Tuxedo アプリケーションをスケーリングできます。
コンフィギュレーションのオプション
サーバ・アプリケーションは、以下のようにコンフィギュレーションできます。
サーバ・プロセスを複製するか、スレッドを追加することにより、クライアント/サーバ・アプリケーションの並列処理機能を強化できます。サーバ・グループを追加して、リソース・マネージャ間で処理を分担することができます。CORBA アプリケーションでは、ファクトリ・ベース・ルーティングの使用 (CORBA サーバのみ)で説明したファクトリ・ベース・ルーティングをインプリメントできます。
サーバ・プロセスの複製
システム管理者は、サーバ・ノード上でより多くの活性化されたオブジェクトを同時にサポートしたり、より多くの要求を同時に処理したりするために、サーバを複製することによって、アプリケーションをスケーリングできます。複製サーバ・プロセスのコンフィギュレーションについては、複製されたサーバ・プロセスおよびグループのコンフィギュレーションを参照してください。
注記 BEA Tuxedo のリリース 8.0 では、活性化されたオブジェクトについて、ユーザが制御する同時実行モデルをサポートしています。同時実行方針機能の説明については、パラレル・オブジェクトを参照してください。
利点
複製サーバ・プロセスを使用する利点には、以下のようなものがあります。
ガイドライン
複製サーバ・プロセスを使用する利点を最大限に高めるには、サーバ・アプリケーションによってインスタンス化された CORBA オブジェクトに、必ず一意のオブジェクト ID を付けます。これにより、オブジェクトに対するクライアント呼び出しで、オブジェクトを活性化済みオブジェクトのキューに入れるのではなく、必要に応じて利用可能なサーバ・プロセス数の制限内においてインスタンス化できます。
また、アプリケーション・パターンおよび処理環境の種類によっては、複数のプロセスを使用してアプリケーションの回復機能を改善するか、スレッドを使用して性能を高めるかの、兼ね合いを考える必要があります。
フェイルオーバーが改善されるのは、スレッドではなくプロセスを追加した場合のみです。シングル・スレッド・サーバおよびマルチスレッド・サーバの使用については、マルチスレッド CORBA サーバを使用すべき場合を参照してください。
サーバ・グループの複製
サーバ・グループは、BEA Tuxedo に固有のもので、BEA Tuxedo のスケーラビリティ機能の基幹部分です。グループは、単一ノード上の 1 つまたは複数のサーバで構成されます。システム管理者は、サーバ・グループを複製し、ドメイン内のロード・バランシングをコンフィギュレーションすることにより、BEA Tuxedo アプリケーションをスケーリングできます。
サーバ・グループを複製するには、同じタイプのサーバとリソース・マネージャを備えた別のサーバ・グループを定義して、共有リソース (データベースなど) への並行アクセスを実現することが必要です。たとえば CORBA アプリケーションでは、ファクトリ・ベース・ルーティングを使用して、データベースのパーティション間で処理を分担できます。
UBBCONFIG ファイルにより、どのようにサーバ・グループをコンフィグレーションするか、およびそれらのグループが稼動する場所が指定されます。複数のサーバ・グループを使用すると、BEA Tuxedo は次のことを行えます。
複製サーバ・グループのコンフィギュレーションについては、複製されたサーバ・プロセスおよびグループのコンフィギュレーションを参照してください。
マルチスレッド・サーバの使用
ここでは、以下の内容について説明します。
マルチスレッド処理を行うためのサーバのコンフィギュレーション方法については、マルチスレッド・サーバのコンフィギュレーションを参照してください。
マルチスレッド CORBA サーバについて
システム管理者は、CORBA サーバ内でマルチスレッド処理を有効にし、アプリケーションの UBBCONFIG ファイルのコンフィギュレーション・パラメータ (作成可能なサーバ・スレッドの最大数) をチューニングすることによって、BEA Tuxedo アプリケーションのスケーリングを行えます。
BEA Tuxedo CORBA では、マルチスレッド CORBA アプリケーションのコンフィギュレーション機能をサポートしています。シングル・スレッド CORBA サーバでは一度に 1 つの要求しか実行できませんが、マルチスレッド CORBA サーバでは複数のオブジェクト要求の同時処理を行えます。
サーバ・スレッドは、アプリケーション・プログラムではなく、BEA Tuxedo CORBA ソフトウェアによって開始および管理されます。内部では、BEA Tuxedo CORBA が、利用可能なサーバ・スレッドのプールを管理しています。CORBA サーバがマルチスレッド処理用にコンフィグレーションされている場合は、クライアント要求が受信されると、スレッド・プールからの利用可能なサーバ・スレッドがその要求を実行するように、スケジューリングが行われます。オブジェクトが活性化されている間、スレッドは使用中です。要求が完了すると、スレッドは利用可能なスレッドのプールに返されます。
マルチスレッド CORBA サーバを使用すべき場合
複数の独立したスレッドを使用するようにアプリケーションを設計すると、アプリケーション内に並行性がもたらされ、総合的なスループットを改善できます。複数のスレッドを使用すると、各スレッドが複数の独立したタスクを並列に処理する効率的なアプリケーションを構築できます。マルチスレッドは、以下の場合に特に役立ちます。
コンピュータ・オペレーションの中には、完了するのに長い時間を要するものがあります。マルチスレッド・アプリケーションの設計では、要求とオペレーション完了の間の待ち時間を、大幅に短縮できます。これは、オペレーションが数多くの I/O オペレーションを実行する環境に当てはまります。たとえば、データベースにアクセスするとき、リモート・オブジェクトのオペレーションを呼び出すとき、マルチ・プロセッサ・マシン上の CPU バウンドなどです。サーバ・プロセスでマルチスレッドをインプリメントすると、サーバが一定時間に処理できる要求の数が増加します。
マルチスレッド・サーバ・アプリケーションの主要な要件は、複数のクライアント要求を同時に処理することです。マルチスレッド・サーバの使用の要件と利点の詳細については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。
コーディングの推奨事項
クライアント・アプリケーションまたはサーバ・アプリケーションが、メッセージをユーザ・ログ (ULOG) に送る場合、マルチスレッド・サーバの性能を分析できるようにするには、各メッセージに次の識別子のうち 1 つを含めます。
マルチスレッド CORBA サーバのコンフィギュレーション
マルチスレッド CORBA サーバをコンフィギュレーションするには、アプリケーションの UBBCONFIG ファイルの設定を変更します。マルチスレッド・サーバをインプリメントするための UBBCONFIG パラメータの定義については、マルチスレッド・サーバのコンフィギュレーションを参照してください。
ファクトリ・ベース・ルーティングの使用 (CORBA サーバのみ)
ここでは、以下の内容について説明します。
このトピックでは、BEA Tuxedo CORBA アプリケーションにおけるファクトリ・ベース・ルーティングについて概説します。ファクトリ・ベース・ルーティングの使用の詳細については、UBBCONFIG ファイルでのファクトリ・ベース・ルーティングのコンフィギュレーションを参照してください。
ファクトリ・ベース・ルーティングについて
ファクトリ・ベース・ルーティングを使用すると、オブジェクト・リファレンスと関連付けられたサーバ・グループを指定できます。その結果、所定のオブジェクトがインスタンス化されているグループとマシンを定義し、その後、所定のアプリケーションの処理負荷を、複数のマシン間に分散できます。
ファクトリ・ベース・ルーティングでは、ファクトリがオブジェクト・リファレンスを作成したときにルーティングが行われます。ファクトリは、オブジェクト・リファレンスを作成するための BEA Tuxedo CORBA TP フレームワークへの呼び出しにおいて、フィールド情報を指定します。TP フレームワークは、アプリケーションの UBBCONFIG ファイルの ROUTING セクションで定義されたルーティング基準に基づき、ルーティング・アルゴリズムを実行します。その結果得られるオブジェクト・リファレンスは、オブジェクト・リファレンスに対するメソッド呼び出し処理に適したサーバ・グループをターゲットとしています。このサーバ・グループにおけるインターフェイスをインプリメントするサーバはすべて、オブジェクト・リファレンスのためのサーバントを活性化するものとして適しています。
したがって、CORBA オブジェクトの活性化は、定義された基準に基づいてサーバ・グループにより分散可能であり、CORBA インターフェイスのさまざまなインプリメンテーションを、さまざまなグループに提供することができます。つまり、定義済みのグループ固有の差異に基づき、複数のサーバ・グループにわたって、同一の CORBA インターフェイスを複製することができます。
ファクトリ・ベース・ルーティングの主な利点は、アプリケーションのスケーリングを行うための単純な手段と、拡大しつつあるデプロイメント環境全体にわたる、特定のインターフェイスに対する呼び出しが得られることです。アプリケーションのデプロイメントを、追加のマシン間に分散することは、あくまでも管理上の機能であり、アプリケーションのコーディングやビルドをやり直す必要はありません。
ファクトリ・ベース・ルーティングの特性
ファクトリ・ベース・ルーティングには、次の特性があります。
ファクトリ・ベースのインプリメンテーションのしくみ
ファクトリ・ベース・ルーティングをインプリメントするには、ファクトリによるオブジェクト・リファレンスの作成方法を変更する必要があります。まず、システム設計者との間で調整を行い、ルーティングの基準として使用するフィールドと値を決定します。次に、各インターフェイスについて、グループ ID の決定に使用されるルーティング基準を表すパラメータが、ファクトリのインターフェイス定義で指定されるように、ファクトリ・ベース・ルーティングをコンフィギュレーションする必要があります。
ファクトリ・ベース・ルーティングをコンフィギュレーションするには、UBBCONFIG ファイルで以下の情報を定義します。
注記 ファクトリ・ベース・ルーティングをインプリメントする際には、所定のインターフェイスと OID を備えたオブジェクトは、2 つの異なるグループの双方に同じオブジェクトのインプリメンテーションが含まれている場合、2 つのグループ内で同時に活性化されることに留意してください。これは、ファクトリが一意の OID を生成している場合は回避できます。所定のインターフェイス名および OID のオブジェクト・インスタンスが、ドメイン内では必ず一度に 1 つしか使用されないようにするには、次の処理のいずれかを行います。
複数のクライアントが、所定のインターフェイス名と OID を含むオブジェクト・リファレンスを持っている場合、そのリファレンスは常に同じオブジェクト・インスタンスにルーティングされます。
その後のオブジェクト・リファレンスには、ターゲット・サーバが存在する場所を示すための追加情報が含まれます。ファクトリ・ベース・ルーティングは、各 CORBA オブジェクトについて 1 回ずつ、オブジェクト・リファレンスの作成時に行われます。
UBBCONFIG ファイルでのファクトリ・ベース・ルーティングのコンフィギュレーション
ルーティング基準により、特定のサーバ・グループに要求をルーティングするためのデータ値が指定されます。ファクトリ・ベース・ルーティングをコンフィギュレーションするには、UBBCONFIG ファイルの ROUTING セクションで、要求がルーティングされる各インターフェイスについて、ルーティング基準を定義します。ファクトリ・ベース・ルーティングのコンフィギュレーションの詳細については、UBBCONFIG ファイルでのファクトリ・ベース・ルーティングのコンフィギュレーションを参照してください。
複数ドメインにわたってファクトリ・ベース・ルーティングをコンフィギュレーションするには、現在の (ローカル) ドメインで使用されているが、別の (リモート) ドメインに存在するオブジェクトを識別するために、factory_finder.ini ファイルのコンフィギュレーションも行う必要があります。詳細については、『BEA Tuxedo Domains コンポーネント』の「複数の CORBA ドメインを設定する」を参照してください。
パラレル・オブジェクトの使用
ここでは、以下の内容について説明します。
パラレル・オブジェクトについて
パラレル・オブジェクトのサポートは、BEA Tuxedo のリリース 8.0 で性能強化の一環として追加されています。パラレル・オブジェクト機能を利用すると、特定アプリケーションのすべてのビジネス・オブジェクトを状態を持たないオブジェクトとして指定できます。1 つのドメインの 1 つのサーバでしか実行できない、状態を持つビジネス・オブジェクトと異なり、状態を持たないビジネス・オブジェクトは 1 つのドメインのすべてのサーバで実行できます。パラレル・オブジェクトの利点は以下のとおりです。
注記 パラレル・オブジェクト機能を有効にするには、ICF ファイルで同時実行方針のオプションを user_controlled に設定します。詳細については、パラレル・オブジェクトのコンフィギュレーション
を参照してください。図1-1 で示されるように、状態を持つビジネス・オブジェクトがマシン 2 のサーバ上で活性化されている場合、その後、そのビジネス・オブジェクトへの要求はすべてマシン 2 のグループ 2 に送信されます。マシン 2 上の活性化されたオブジェクトが、別の要求の処理に使用中であった場合、その要求はキューに入れられます。ビジネス・オブジェクトがマシン 2 上の要求の処理を停止した後でも、その状態を持つビジネス・オブジェクトに対するその後の要求はやはり、すべてグループ 2 に送信されます。オブジェクトがマシン 2 上で非活性化されると、その後の要求はマシン 2 上のグループ 2 に送られ、グループ 2 のほかのサーバによって処理可能です。
図 1-1 状態を持つビジネス・オブジェクトの使用
図1-2 で示されるように、パラレル・オブジェクトがマシン 1 上のグループ 1 に含まれるすべてのサーバ上で実行されている場合、そのビジネス・オブジェクトに対するその後の要求はマシン 2 に送信され、グループ 1 でサーバが使用可能になるまで、グループ 2 のサーバに分散されます。状態を持たない、ユーザに制御されるビジネス・オブジェクトの複数のインスタンスは、複数のサーバ上で同時に実行可能です。ローカル・マシンで利用可能なサーバがある限りは、要求はマシン 1 上のサーバに分散されます。ただし、BEA Tuxedo のロード・バランシング機能が、サーバに対する負荷を理由に、要求をグループ 2 のサーバで処理すべきであると判断した場合には、その限りではありません。この判断を行うために、ロード・バランシング機能では LOAD パラメータを使用します。これは、UBBCONFIG ファイルの INTERFACES セクションで設定されます。 図 1-2 状態を持たないビジネス・オブジェクトの使用
UBBCONFIG ファイルLOAD パラメータについては、INTERFACES セクションの変更を参照してください。 パラレル・オブジェクトのコンフィギュレーション パラレル・オブジェクトのサポートは、BEA Tuxedo のリリース 8.0 から追加されました。特定の CORBA アプリケーションのパラレル・オブジェクトをインプリメントするには、ICF ファイルを使用します。ICF には、その ICF ファイルが適用されるアプリケーションでインプリメントされているすべてのビジネス・オブジェクトを状態を持たないオブジェクトに設定する、ユーザ制御の同時実行方針のオプションが含まれます。 同時実行方針は、あるオブジェクトが一度に 1 つのサーバでのみ活性化されることを保証するために、アクティブ・オブジェクト・マップ (AOM) を使用するかどうかを決定します。旧リリースでは、AOM の使用はオプションではなく必須でした。AOM の使用は、システム制御の同時実行と呼ばれます。システム制御の同時実行モデルと異なり、AOM を使用しないユーザ制御のモデルでは、一度に複数のサーバで、同じオブジェクトを活性化することができます。したがって、ユーザ制御の同時実行を使用すると、性能とロード・バランシングを改善できます。パラレル・オブジェクトのためのユーザ制御の同時実行のコンフィギュレーションの詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「パラレルオブジェクト」を参照してください。
受信するクライアント接続の多重化
ここでは、以下の内容について説明します。
システム管理者は、UBBCONFIG ファイルで、アプリケーション・サイトによってサポートされている受信するクライアント接続数を増やすことによって、BEA Tuxedo アプリケーションをスケーリングできます。BEA Tuxedo は、リスナ/ハンドラのマルチコンテキスト化された、複数の状態を持つゲートウェイを提供して、クライアントによって発行されたすべての要求の多重化処理を行います。
IIOP リスナ/ハンドラ
IIOP リスナ (ISL) を使うと、IIOP を使用するリモート BEA Tuxedo CORBA クライアントによる BEA Tuxedo CORBA オブジェクトへのアクセスが可能になります。ISL とは、IIOP 接続を要求する リモート CORBA クライアントをリッスンするプロセスです。IIOP ハンドラ (ISH) は、リモート CORBA クライアントの代理プロセスとして作用するマルチプレクサ・プロセスです。ISL と ISH はどちらも、アプリケーション・サイト上で実行されます。アプリケーション・サイトは、1 つまたは複数の ISL プロセスと、複数の関連する ISH プロセスを持つことができます。各 ISH は、単一の ISL と関連付けられます。
クライアントは、既知のネットワーク・アドレスを使用して ISL プロセスに接続します。ISL は、利用可能な中から最適な ISH を選択して、接続を直接それに渡すことにより、ISH プロセス間でロード・バランシングを行います。ISL/ISH は、アプリケーション・クライアントの代わりに、コンテキストを管理します。ISL と ISH の詳細については、『BEA Tuxedo のファイル形式とデータ記述方法』
の ISL の説明を参照してください。ISH プロセス数の増加
システム管理者は、アプリケーション・サイト上の ISH プロセスの数を増加することによって、BEA Tuxedo CORBA アプリケーションをスケーリングできます。それにより、ISL でのロード・バランシングを、より多くの ISH プロセス間で行えるようになります。デフォルトでは、ISH は最高で 10 個のクライアント接続を処理できます。この数を増やすには、オプションの CLOPT -x mpx-factor パラメータを ISL コマンドに渡します。その際、mpx-factor で、各 ISH が処理できる ISH クライアント接続数 (最大 4096)、つまり ISH の多重化のレベルを指定します。ISH プロセス数を増やすと、アプリケーション・サイトで同時に処理するプロセスの数が増えるので、アプリケーションの性能に影響が出る可能性があります。
システム管理者は、そのほかの ISH オプションもチューニングして、BEA Tuxedo アプリケーションをスケーリングできます。詳細については、『BEA Tuxedo のファイル形式とデータ記述方法』
の ISL の説明を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
