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