Oracle Tuxedo 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では、次のようにすることで大規模なアプリケーション開発をサポートします。

このトピックには次の項が含まれます:

システム・アーカイブではスループットとレスポンス時間の最適化が不可欠であるため、オブジェクト状態管理は大規模なクライアント/サーバー・システムの重要な課題です。オブジェクト状態管理の使用の詳細は、2-3ページの「ステートレス・オブジェクト・モデルの使用方法」およびテクニカル・アーティクル『Process-Entityデザイン・パターン』を参照してください。

Oracle Tuxedo CORBAでは、3つのオブジェクト状態管理モデルがサポートされています。

これらのモデルの詳細は、CORBAクライアント・アプリケーションの作成のサーバー・アプリケーションの概念に関する項を参照してください

メソッド・バウンド・オブジェクトは、クライアントによって呼び出されている間だけ、マシンのメモリーへ格納されます。呼出しが完了すると、オブジェクトは非アクティブ化され、そのオブジェクトの状態データはすべて、メモリーからフラッシュされます。このドキュメントでは、メソッド・バウンド・オブジェクトはステートレス・オブジェクトとして扱われます。

メソッド・バウンド・オブジェクトは、使用するアプリケーションにステートレス・サーバー・モデルを作成するために使用できます。ステートレス・サーバー・モデルを使用すると、アクティブなオブジェクトに送信済のリクエストを使用可能な任意のサーバーに移動できるため、何千、さらには何百万ものオブジェクトの同時実行が可能になります。クライアント・アプリケーション・ビューからは、すべてのオブジェクトがサービス・リクエストに対して使用可能です。ただし、サーバー・アプリケーションがオブジェクトをメモリーにマッピングするのはクライアントによってオブジェクトが呼び出されている間のみであるため、サーバー・アプリケーションによって管理されているオブジェクトのうち、任意の時点でメモリー内に存在するのは少数です。

プロセス・バウンド・オブジェクトは、最初に呼び出されたときから、実行されているサーバー・プロセスが停止されるまでメモリーにとどまります。プロセス・バウンド・オブジェクトは、クライアントの呼出し時、または任意のクライアント呼出し(preactivatedオブジェクト)前に明示的にアクティブ化できます。プロセス・バウンド・オブジェクトの非アクティブ化は、アプリケーションで制御できます。このドキュメントでは、プロセス・バウンド・オブジェクトはステートフル・オブジェクトとして扱われます。

適切な場合には、大量の状態データを含むプロセス・バウンド・オブジェクトはメモリーにとどまり、複数のクライアント呼出しを処理するため、クライアント呼出しのたびにオブジェクトの状態データの読取りおよび書込みを行わずにすみます。

トランザクション・バウンド・オブジェクトも、呼出しと呼出しの間、メモリーにとどまることができるため、トランザクションのスコープ内ではステートフルとして扱われます。オブジェクトがトランザクションのスコープ内でアクティブ化された場合、そのオブジェクトはトランザクションがコミットされるかロールバックされるまでアクティブな状態を保ちます。オブジェクトがトランザクションのスコープ外でアクティブ化された場合、その動作は、メソッド・バウンド・オブジェクトの動作と同じになります(クライアント呼出しの間ロードされます)。

一般にアプリケーション開発者は、ステートレス・オブジェクトを実装する際の負担と、ステートフル・オブジェクトを実装する際の負担を比較する必要があります。

ステートレス・オブジェクトやステートフル・オブジェクトの使用は、様々な要因に応じて決定します。オブジェクトをその永続状態で初期化する負担が大きい場合(これは、たとえば、そのオブジェクトのデータが大きな領域を占めている場合や、永続状態の場所が、それをアクティブ化するサーバントから大幅に離れたディスク上である場合)、たとえ通信の間オブジェクトがアイドル状態であるとしても、オブジェクトをステートフルにしておく方が合理的です。マシンのリソース使用率との関連で、オブジェクトをアクティブなままにしておく方が負担が大きい場合は、そのようなオブジェクトをステートレスにする方が合理的です。

オブジェクトの状態を、アプリケーションに合せて効率的かつ適切な方法で管理することにより、アプリケーションの能力を最大限に高めて、大量のオブジェクトを使用する多数のクライアント・アプリケーションを同時にサポートできます。オブジェクトの状態管理方法は、アプリケーション固有の特性や要件によって異なります。CORBAアプリケーションの場合は、オブジェクトに対してmethodアクティブ化ポリシーを割り当てることでオブジェクトの状態を管理し、それによりアイドル状態のオブジェクト・インスタンスが非アクティブ化され、マシンのリソースを他のオブジェクト・インスタンスに割り当てられるようになります。

サーバー・リソースはオブジェクトがアイドル状態のときには使用されないため、ステートレス・オブジェクトは一般に、サーバー・リソースの性能を高め、最適な使用方法を実現します。サーバー・アプリケーションの実装にはステートレス・オブジェクトが適していますが、特に次のような場合に適しています。

•

クライアント・リクエストにサーバー・アプリケーションが必要とするデータがすべて含まれ、サーバーがそのデータのみを使用してクライアント・リクエストを処理できる場合。

オブジェクトをステートレスにすることで、サーバー・アプリケーションのリソースがクライアント・アプリケーションからの入力の待機中に不必要に拘束されないようにできます。

ステートレス・オブジェクト・モデルを使用するアプリケーションには、次のような特性があります。

•

着信クライアント・リクエストは、利用可能な最初のサーバー・プロセスに送信されます。リクエストが終了した後は、アプリケーションの状態が消滅して、サーバー・アプリケーションは別のクライアント・アプリケーション・リクエストに対して使用可能になります。

•

オブジェクトの永続状態の情報は、サーバー・プロセス外に存在します。このオブジェクトが呼び出されるたびに、永続状態がメモリーに読み込まれます。

•

特定のクライアント・アプリケーションから1つのオブジェクトへの連続したリクエストが別のサーバー・プロセスによって処理される場合があります。

ステートフル・オブジェクトは、一度アクティブ化されると、オブジェクトが存在しているプロセスが停止されたり、オブジェクトがアクティブ化されているトランザクションが完了したりといった、特定のイベントが発生するまで、メモリー内にとどまります。

次のような場合には、ステートフル・オブジェクトの使用をお薦めします。

•

1つのオブジェクトが、存続期間の長い既知のオブジェクトなど、多数のクライアント・アプリケーションによって頻繁に利用される場合。サーバー・アプリケーションによりこれらのオブジェクトがアクティブな状態に維持されていると、通常、クライアント・アプリケーションがそれらにアクセスする際のレスポンス時間が最短化されます。アクティブなオブジェクトは多くのクライアント・アプリケーションに共有されるので、このタイプのオブジェクトでメモリーにあるものは比較的少数です。

注意:

オブジェクトをトランザクションにどのように関係させるかについては、注意深く検討してください。オブジェクトは、一時的(トランザクション・バウンド)または永続的(プロセス・バウンド)に特定のプロセスにバインドできます。トランザクションに関係するオブジェクトは、他のクライアント・アプリケーションまたはオブジェクトからは呼び出せません(Oracle Tuxedoでは、オブジェクトがビジー状態であるというエラーが戻される可能性があります)。ステートフル・オブジェクトは多数のクライアント・アプリケーションによって使用されるため、頻繁にまたは長期間トランザクションに関係すると、ボトルネックの原因になる可能性があります。

•

トランザクションを完了するために1つのオブジェクト上でクライアント・アプリケーションが操作を連続して呼び出す必要がある場合や、こうした呼出しの間にユーザーからの入力を待機する際にクライアント・アプリケーションがアイドル状態でない場合。この場合、呼出しの間にオブジェクトが非アクティブ化されると、各呼出しの間に状態の書込みおよび読取りが行われるため、レスポンス時間が遅くなります。

ステートフル・オブジェクトは次のように動作します。

•

状態情報はサーバーの呼出しの間維持され、オブジェクトは通常、指定された期間、特定のクライアント・アプリケーション専用になります。クライアントとサーバー・アプリケーション間でデータの送受信が行われても、追加のコンテキスト情報またはアプリケーションの状態情報が、サーバー・プロセスによりメモリーに保持されます。

•

1つ以上のステートフル・オブジェクトが大量のマシン・リソースを使用している場合、ステートフル・オブジェクトと関連付けられていないタスクおよびプロセスに対するサーバー・パフォーマンスは、ステートレス・サーバー・モデルより劣ります。

たとえば、1つのオブジェクトがデータベースにロックを保持し、大量のデータをメモリーにキャッシュしている場合、そのステートフル・オブジェクトによって使用されているデータベースおよびメモリーは、トランザクションが完了するまで他のオブジェクトで使用できません。

定義では、パラレル・オブジェクトはステートレス・オブジェクトであるため、複数のサーバーに同時に存在することが可能です。リリース8.0のOracle Tuxedoでは、実装構成ファイル(ICF)を使用して、特定の実装に含まれるすべてのオブジェクトを強制的にパラレル・オブジェクトにできます。これにより、パフォーマンスが向上します。パラレル・オブジェクトの詳細は、1-14ページの「パラレル・オブジェクトの使用」を参照してください。

このトピックには次の項が含まれます:

サーバー・プロセスおよびサーバー・グループのレプリケートの詳細は、次のトピックを参照してください。

Oracle Tuxedo CORBA環境では、CORBAオブジェクトを複数のサーバーにデプロイしてフェイルオーバーの信頼性を強化し、ロード・バランシングによりクライアントのワークロードを分散できます。Oracle Tuxedo CORBAロード・バランシングは、デフォルトで有効化されています。ロード・バランシングの構成の詳細は、4-3ページの「システム制御のロード・バランシングの有効化」を参照してください。Oracle Tuxedo CORBAの機能を使用したアプリケーション・ワークロードの分散の詳細は、第3章「CORBAアプリケーションの分散」を参照してください。

Oracle Tuxedoアークテクチャのサーバー編成は次のとおりです。

•

グループ - 個々のサーバーを結合してグループを形成できます。サーバーのグループは、単一のマシンで稼働します。通常、グループ内のサーバーは共通のリソース(データベースなど)にアクセスします。

•

ドメイン - マシンを結合してドメインを形成できます。ドメインは中央管理されます。複数のドメインは個別に管理されます。ドメインは相互に接続することも可能で、あるドメインから別のドメインへリクエストを透過的にルーティングできます。ただし、各ドメインは個別に管理されます。

このアーキテクチャにより、新しいサーバーやグループ、マシンを動的に追加または削除して、負荷の高い期間または低い期間にアプリケーションを適合することや、アプリケーションに必要な内部の変更に対応することが可能です。Oracle Tuxedoランタイムは、リクエストを使用可能なサーバーにルーティングすることで、ロード・バランシングおよびフェイルオーバーを提供します。

システム管理者は、次のようにしてOracleアプリケーションをスケーリングできます。

•

サーバー・プロセスのレプリケートサーバー・プロセスの数を増やし、グループ内のより多くのアクティブなオブジェクト、およびサーバー間のロード・バランシングをサポートします。

•

サーバー・グループのレプリケート。サーバー・グループの数を増加することにより、複数のサーバー・マシンに処理リクエストを分散して負荷を調整できます。

サーバー・アプリケーションは次のように構成できます。

•

1つ以上のインタフェースが実装された1つ以上のサーバー・プロセスを含む1台のマシン。サーバーは、シングルスレッドにもマルチスレッドにもできます。

サーバー・プロセスをレプリケートすることにより、クライアント/サーバー・アプリケーションにパラレル処理機能をさらに追加することや、スレッドを追加することができます。さらにサーバー・グループを追加して、リソース・マネージャに処理を分割できます。CORBAアプリケーションの場合は、1-11ページの「ファクトリ・ベース・ルーティングの使用(CORBAサーバーのみ)」で説明されているように、ファクトリ・ベース・ルーティングを実装できます。

システム管理者は、サーバーをレプリケートしてアプリケーションをスケーリングし、サーバー・ノードで、より多くの同時アクティブ・オブジェクトをサポートすることや、より多くの同時リクエストを処理することが可能です。レプリケートされたサーバー・プロセスを構成するには、4-4ページの「レプリケートされたサーバー・プロセスおよびグループの構成」を参照してください。

注意:

リリース8.0のOracleでは、アクティブ・オブジェクトに対してユーザー制御の同時実行性モデルがサポートされています。同時実行ポリシー機能の詳細は、1-6ページの「パラレル・オブジェクト」を参照してください。

レプリケートされたサーバー・プロセスを使用する利点には、次のようなものがあります。

•

グループ内の任意のサーバーでクライアント・リクエストが処理されます。サーバー・グループのOracleドメインにリクエストが到着すると、そのリクエストはグループ内で負荷が最も低いサーバー・プロセスへルーティングされます。

•

複数のサーバー・プロセスを使用することで、サーバー・アプリケーションのパフォーマンスが向上します。1つのサーバー・プロセスで一度に1つのクライアント・リクエストを処理するかわりに、複数のサーバー・プロセスで複数のクライアント・リクエストを同時に処理できます。

レプリケートされたサーバー・プロセスの利点を最大限に活用するには、使用するサーバー・アプリケーションによってインスタンス化されるCORBAオブジェクトのオブジェクトIDが一意になるようにしてください。そうすることにより、オブジェクト上でのクライアント呼出しでは、使用可能なサーバー・プロセス数の範囲内で必要に応じてオブジェクトがインスタンス化されるため、すでにアクティブなオブジェクトのためにキューに入ることがなくなります。

また、複数のプロセスを使用してアプリケーションのリカバリの質を高めることと、(一部のタイプのアプリケーション・パターンや処理環境で)スレッドを使用してパフォーマンスの効率を高めることのどちらを選択するかも考慮する必要があります。

フェイルオーバーは、スレッドではなくプロセスを追加することでよりスムーズに行われます。シングルスレッド・サーバーおよびマルチスレッド・サーバーの使用の詳細は、1-10ページの「マルチスレッドCORBAサーバーを使用する場合」を参照してください。

Oracleに対してサーバー・グループは一意であり、Oracleのスケーラビリティ機能の鍵です。グループでは、1つのノードに1つ以上のサーバーが含まれます。システム管理者は、サーバー・グループをレプリケートし、ドメイン内でロード・バランシングを構成することにより、Oracleアプリケーションをスケーリングできます。

サーバー・グループのレプリケートには、共有リソース(データベースなど)へのパラレル・アクセスが提供されるように、同じタイプのサーバーが含まれる別のサーバー・グループやリソース・マネージャを定義することが関係します。たとえば、CORBAアプリケーションはファクトリ・ベース・ルーティングを使用して、データベース・パーティション全体に処理を分割できます。

UBBCONFIGファイルは、サーバー・グループの構成方法や実行場所を指定します。複数のサーバー・グループを使用することで、Oracleは次の内容を実現できます。

•

CORBAアプリケーションの場合は、ファクトリ・ベース・ルーティングを使用して、任意のインタフェースへのリクエストの1つをあるグループに送信し、同じインタフェースへのリクエストの別のセットは別のグループへ送信できます。

レプリケートされたサーバー・グループを構成するには、4-4ページの「レプリケートされたサーバー・プロセスおよびグループの構成」を参照してください。

このトピックには次の項が含まれます:

マルチスレッド用にサーバーを構成する方法の手順は、4-5ページの「マルチスレッド・サーバーの構成」を参照してください。

システム管理者は、CORBAサーバーでマルチスレッド機能を有効化し、アプリケーションのUBBCONFIGファイルで構成パラメータ(作成可能なサーバー・スレッドの最大数)をチューニングすることでOracleアプリケーションをスケーリングできます。

Oracle CORBAでは、マルチスレッドCORBAアプリケーションを構成する機能がサポートされています。シングルスレッドCORBAサーバーで実行できるのは一度に1つのリクエストのみですが、マルチスレッドCORBAサーバーでは、複数のオブジェクト・リクエストを同時に処理できます。

サーバー・スレッドはアプリケーション・プログラムではなく、Oracle CORBAソフトウェアによって開始および管理されます。内部では、Oracle CORBAにより、使用可能なサーバー・スレッドのプールが管理されます。CORBAサーバーがマルチスレッドとして構成されている場合、クライアント・リクエストを受信すると、スレッド・プールの使用可能なサーバー・スレッドがリクエストを実行するようスケジュールされます。オブジェクトがアクティブな間、スレッドはビジー状態になります。リクエストが完了すると、スレッドは使用可能なスレッドのプールに戻ります。

複数の独立したスレッドを使用するようにアプリケーションを設計すると、アプリケーション内に並行性がもたらされ、総合的なスループットを改善できます。複数のスレッドを使用すると、各スレッドが複数の独立したタスクを並列に処理する効率的なアプリケーションを構築できます。マルチスレッドは、次の場合に特に役立ちます。

コンピュータ操作の中には、完了するのに長い時間を要するものがあります。マルチスレッド設計では、操作のリクエストと完了の間の待機時間を飛躍的に短縮できます。これは、データベースにアクセスするとき、リモート・オブジェクトの操作を呼び出すとき、マルチ・プロセッサ・マシン上のCPUバウンドなど、操作が大量のI/O操作を実行する環境に当てはまります。サーバー・プロセスでマルチスレッド機能を実装すると、サーバーが一定時間に処理できるリクエストの数が増加します。

マルチスレッド・サーバー・アプリケーションの主要な要件は、複数のクライアント・リクエストを同時に処理することです。マルチスレッド・サーバーの使用の要件と利点の詳細は、「Oracle」を参照してください。

クライアントまたはサーバー・アプリケーションがユーザー・ログ(ULOG)にメッセージを送信する場合、マルチスレッド・サーバーのパフォーマンスを分析できるようにするには、各メッセージに次の識別子のいずれかを含めます。

マルチスレッドCORBAサーバーを構成するには、アプリケーションのUBBCONFIGファイルの設定を変更します。マルチスレッド・サーバーを実装するようにUBBCONFIGパラメータを定義する方法の詳細は、4-5ページの「マルチスレッド・サーバーの構成」を参照してください。

このトピックには次の項が含まれます:

このトピックでは、Oracle CORBAアプリケーションでのファクトリ・ベース・ルーティングについて説明します。ファクトリ・ベース・ルーティングの使用方法の詳細は、2-11ページの「UBBCONFIGファイルでのファクトリ・ベース・ルーティングの構成」を参照してください。

ファクトリ・ベース・ルーティングを使用すると、どのサーバー・グループをオブジェクト参照に関連付けるかを指定できます。これにより、特定のオブジェクトがインスタンス化されるグループとマシンを定義して、複数のマシン間で特定のアプリケーションの処理負荷を分散できます。

ファクトリ・ベース・ルーティングでは、ファクトリによりオブジェクト参照が作成される際にルーティングが実行されます。ファクトリは、オブジェクト参照を作成するために、Oracle CORBA TPフレームワークへの呼出しにフィールド情報を指定します。TPフレームワークは、アプリケーションのUBBCONFIGファイルのROUTINGセクションに定義されているルーティング基準に基づいて、ルーティング・アルゴリズムを実行します。結果のオブジェクト参照には、オブジェクト参照でのメソッド呼出しを処理するための適切なサーバー・グループがターゲットとして含まれます。サーバー・グループにインタフェースを実装しているサーバーは、オブジェクト参照のサーバントをアクティブ化できます。

このため、CORBAオブジェクトのアクティブ化は、定義された基準に基づいてサーバー・グループにより分散され、CORBAインタフェースの異なる実装が個々のグループに提供されます。これにより、定義されたグループ固有の差異に基づき、複数のサーバー・グループ間で同じCORBAインタフェースをレプリケートできます。

ファクトリ・ベース・ルーティングの第一の利点は、デプロイメント環境の拡大に対応して、アプリケーション、特にインタフェースの呼出し機能をスケーリングするための簡単な方法が提供されることです。アプリケーションのデプロイメントを追加マシンにも分散することは、厳密には管理用の機能であり、アプリケーションの再コーディングや再ビルドは不要です。

ファクトリ・ベース・ルーティングの特性は次のとおりです。

•

ファクトリ・オブジェクト実装は、アプリケーション固有のルーティング情報を提供することで、作成されるCORBAオブジェクトの場所を間接的に制御します。

•

2-11ページの「UBBCONFIGファイルでのファクトリ・ベース・ルーティングの構成」に示されているように、特定のCORBAインタフェースの実装は複数のサーバー・プロセスに存在可能です。

•

指定されたインタフェースを提供するグループ内のすべてのオブジェクト・インスタンスで、同じバージョンの実装がサポートされている必要があります。

ファクトリ・ベース・ルーティングを実装するには、ファクトリがオブジェクト参照を作成する方法を変更する必要があります。まず、システム設計者と協力して、ルーティングの基準として使用するフィールドや値を決定する必要があります。次に、各インタフェースに対して、グループIDの決定に使用されるルーティング基準を表すパラメータを指定するファクトリのインタフェース定義など、ファクトリ・ベース・ルーティングを構成する必要があります。

ファクトリ・ベース・ルーティングを構成するには、UBBCONFIGファイルに次の情報を定義する必要があります。

注意:

ファクトリ・ベース・ルーティングを実装している場合、2つのグループのどちらにも同じオブジェクト実装が含まれていると、特定のインタフェースおよびOIDを持つ1つのオブジェクトを異なる2つのグループで同時にアクティブ化できることに注意してください。ファクトリで一意のOIDが生成される場合には、これを回避できます。特定のインタフェース名およびOIDのオブジェクト・インスタンスが、ドメイン内で一度に1つのみ使用可能になるようにするには、次のいずれかを行う必要があります。

特定のインタフェース名およびOIDを含むオブジェクト参照が複数のクライアントにある場合、参照は常に同じオブジェクト・インスタンスにルーティングされます。

したがって、オブジェクト参照には、ターゲット・サーバーが存在する場所を示すために使用される追加情報が含まれます。ファクトリ・ベース・ルーティングは、オブジェクト参照の作成時に、CORBAオブジェクトごとに1回実行されます。

ルーティング基準は、リクエストを特定のサーバー・グループにルーティングするために使用されるデータ値を指定します。ファクトリ・ベース・ルーティングを構成するには、(リクエストがルーティングされるインスタンスごとに)UBBCONFIGファイルのROUTINGセクションにルーティング基準を定義します。ファクトリ・ベース・ルーティングの構成方法の詳細は、2-11ページの「UBBCONFIGファイルでのファクトリ・ベース・ルーティングの構成」を参照してください。

複数ドメインにわたってファクトリ・ベース・ルーティングを構成するには、現在の(ローカル)ドメインで使用されているが、別の(リモート)ドメインに存在するファクトリ・オブジェクトを識別するために、factory_finder.iniファイルも構成する必要があります。詳細は、『Oracle Tuxedo Domainsコンポーネントの使用』のCORBAアプリケーションへの複数ドメインの構成に関する項を参照してください。

このトピックには次の項が含まれます:

リリース8.0のOracle Tuxedoには、パフォーマンス拡張としてパラレル・オブジェクトのサポートが追加されています。パラレル・オブジェクト機能を利用すると、特定アプリケーションのすべてのビジネス・オブジェクトをステートレス・オブジェクトとして指定できます。1つのドメインの1つのサーバーでしか実行できないステートフル・ビジネス・オブジェクトと異なり、ステートレス・ビジネス・オブジェクトは1つのドメインのすべてのサーバーで実行できます。パラレル・オブジェクトの利点は次のとおりです。

注意:

パラレル・オブジェクト機能は、ICFファイルで同時実行ポリシー・オプションをuser_controlledに設定して有効化します。詳細は、1-17ページの「パラレル・オブジェクトの構成」を参照してください。

•

ステートレスであるパラレル・オブジェクトは、同じドメインの複数のサーバーで同時に実行できます。すべてのサーバーを使用して同時リクエストを複数処理できるためパフォーマンスが向上します。

•

Oracle Tuxedoでパラレル・ビジネス・オブジェクトへのリクエストが処理されるときには、常に、ローカル・マシン上の使用可能なサーバーが最初に確認されます。ローカル・マシン上のすべてのサーバーがリクエストされたビジネス・オブジェクトの処理に使用されている場合、Oracle Tuxedoではローカル・ドメイン内の他のマシンで使用可能なサーバーを探します。したがって、ローカル・マシンに複数のサーバーがある場合は、ネットワーク・トラフィックが削減され、パフォーマンスが向上します。

図1-1に示されているように、マシン2のサーバーでステートフル・ビジネス・オブジェクトがアクティブである場合、そのビジネス・オブジェクトに対する後続のすべてのリクエストは、マシン2のグループの2に送信されます。マシン2のアクティブ・オブジェクトが別のリクエストを処理している場合、そのリクエストはキューに入ります。ビジネス・オブジェクトがマシン2のリクエストの処理を停止した後も、そのステートフル・ビジネス・オブジェクトに対する後続のすべてのリクエストは、グループ2に送信されます。マシン2でオブジェクトが非アクティブ化されると、後続のリクエストがマシン2のグループ2に送信され、グループ2の別のサーバーで処理されます。

図1-2に示されているように、パラレル・オブジェクトがマシン1のグループ1にあるすべてのサーバーで実行されている場合(ステートレスでユーザー制御のビジネス・オブジェクトの複数のインスタンスを複数のサーバーで同時に実行可能)、そのビジネス・オブジェクトに対する後続のリクエストはマシン2に送信され、グループ1でサーバーが使用可能になるまでグループ2のサーバーに分散されます。Oracle Tuxedoのロード・バランシング機能により、サーバーの負荷が原因で、リクエストをグループ2のサーバーで処理することが決められている場合以外、ローカル・マシンに使用可能なサーバーがあるかぎり、リクエストはマシン1のサーバーに分散されます。この決定を行うため、ロード・バランシング機能では、INTERFACESセクションに設定されているLOADパラメータが使用されます。

UBBCONFIGファイル。LOADパラメータについては、3-10ページの「INTERFACESセクションの変更」を参照してください。

パラレル・オブジェクトのサポートは、リリース8.0のOracle Tuxedoに追加されました。特定のCORBAアプリケーションにパラレル・オブジェクトを実装するには、ICFファイルを使用します。ICFには、ICFファイルが適用されるアプリケーションに実装されているすべてのビジネス・オブジェクトをステートレス・オブジェクトに設定する、ユーザー制御の同時実行ポリシー・オプションが含まれます。

同時実行ポリシーは、1つのサーバーで一度にアクティブになるオブジェクトが1つのみになるようにするために、アクティブ・オブジェクト・マップ(AOM)を使用するかどうかを決定します。旧リリースではAOMの使用は必須で、オプションではありませんでした。AOMを使用することを、システム制御の同時実行性と呼びます。システム制御の同時実行性モデルとは異なり、ユーザー制御モデルではAOMが使用されず、同じオブジェクトを一度に複数のサーバーでアクティブ化できます。このため、ユーザー制御の同時実行性は、パフォーマンスやロード・バランシングの向上に使用できます。パラレル・オブジェクトに対してユーザー制御の同時実行性を構成する方法の詳細は、『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は、1つのISLと関連付けられます。

クライアントは、既知のネットワーク・アドレスを使用してISLプロセスに接続します。ISLは、使用できる最適なISHを選択して接続を直接渡すことにより、ISHプロセス間の負荷を調整します。ISL/ISHは、アプリケーション・クライアントのかわりにコンテキストを管理します。ISLおよびISHの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のISLの説明を参照してください。

システム管理者は、アプリケーション・サイトのISHプロセスの数を増やして、ISLがより多くのISHプロセス間でロード・バランシングできるようにすることで、Oracle Tuxedo CORBAアプリケーションをスケーリングできます。デフォルトでは、ISHは最大10のクライアント接続を処理できます。この数値を増やすには、オプションのCLOPT -x mpx-factorパラメータで、mpx-factorに各ISHが処理できるISHクライアント接続の数(つまり多重化の度合いで、最大4096)を指定してISLコマンドに渡します。ISHプロセスの数を増やすと、アプリケーション・サイトでより多くの同時実行プロセスが処理されるため、アプリケーション・パフォーマンスに影響する可能性があります。

システム管理者は、Oracle Tuxedoアプリケーションをスケーリングできるだけでなく、その他のISHオプションもチューニングできます。詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のISLの説明を参照してください。