ヘッダーをスキップ
Oracle Database Net Services管理者ガイド
11g リリース1(11.1)
E05725-04
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

5 Oracle Net Servicesのアーキテクチャ

この章では、Oracle Netのアーキテクチャ、リスナー共有サーバー専用サーバーOracle Connection Managerを説明します。

この章の内容は、次のとおりです。

5.1 Oracle Netスタック通信アーキテクチャ

Oracle Netの主要な機能は、クライアント・アプリケーションとOracleデータベース・サーバー間の接続を確立して維持することです。Oracle Netは複数の通信レイヤーで構成されており、クライアントとデータベース・サーバーはデータの共有、変更、操作が可能です。

この項で説明する項目は、次のとおりです。

5.1.1 クライアント/サーバー・アプリケーション接続のスタック通信アーキテクチャ

図5-1では、接続が確立された後のクライアントとデータベース・サーバーの様々なレイヤーを示します。

図5-1 クライアント/サーバー・アプリケーション接続で使用するレイヤー

図5-1の説明は次にあります。
画像の説明


注意:


SDPプロトコルはサポートされていますが、この図には含まれていません。

この通信アーキテクチャは、Open Systems Interconnection(OSI)モデルに基づいています。OSIモデルでは、いくつかのコード・レイヤーを通じてあるノードから別のノードに情報が渡される、スタックのような形式でコンピュータ間の通信が行われます。次のレイヤーがあります。

1. 物理層

2. データ・リンク層

3. ネットワーク層

4. トランスポート層 

5. セッション層

6. プレゼンテーション層

7. アプリケーション層

図5-2では、Oracle Netソフトウェア、つまりOracle Net FoundationレイヤーとOracle Protocol Supportが、OSIモデルのセッション層にどのように適合しているかを示します。

図5-2 OSI通信レイヤー

図5-2の説明は次にあります。
画像の説明


関連項目:


OSIスタックの詳細は、次のURLを参照してください。

http://www.ietf.org


図5-1で示すように、クライアント/サーバー・スタックには、次の内容が含まれます。

クライアント・アプリケーション

データベースとのセッション時、クライアントはOracle Call Interface(OCI)を使用して、データベース・サーバーとの対話型操作を実行します。OCIは、クライアント・アプリケーションとデータベース・サーバーが理解できるSQL言語とのインタフェースを提供するソフトウェア・コンポーネントです。


関連項目:


『Oracle Call Interfaceプログラマーズ・ガイド』

プレゼンテーション

キャラクタ・セットの相違は、クライアントとデータベース・サーバーを異なるオペレーティング・システム上で実行している場合に発生します。プレゼンテーション層によって、あらゆる相違を解決します。接続ごとに最適化を実行し、必要な場合のみ変換を実行します。

クライアント/サーバー・アプリケーションが使用するプレゼンテーション層は、Two-Task Common(TTC)です。TTCは、クライアントとデータベース・サーバー間のキャラクタ・セットの相違または形式の相違に対して、キャラクタ・セットとデータ型の変換を行います。

初期の接続時に、TTCは内部データとキャラクタ・セットの表現の違いを評価したり、2つのコンピュータが通信するために変換が必要かどうかを判断します。

Oracle Net Foundationレイヤー

Oracle Net Foundationレイヤーは、クライアント・アプリケーションとデータベース・サーバー間の接続の確立および維持、両者間のメッセージ交換の役割を担います。Oracle Net Foundationレイヤーは、これらのタスクをTransparent Network Substrate(TNS)と呼ばれるテクノロジのおかげで実行できます。TNSは、すべての業界標準プロトコルに対して単一の共通インタフェースを提供します。つまり、TNSは、peer-to-peerのアプリケーション接続を可能にします。ここでは、複数のコンピュータ(ネットワーキング環境で使用される場合はノードと呼ばれます)が相互に直接交信でき、中間のデバイスは必要ありません。

クライアント側で、Oracle Net Foundationレイヤーは、クライアント・アプリケーション要求を受け取り、すべての一般的なコンピュータ・レベルの接続性の問題を解決します。次のような問題があります。

  • データベース・サーバーや接続先の場所

  • 接続に含まれるプロトコルの数

  • それぞれの機能に基づいた、クライアントとデータベース・サーバー間の中断の処理方法

サーバー側で、Oracle Net Foundationレイヤーは、クライアント上と同じタスクを実行します。また、リスナーと一緒に機能して着信接続要求を受け取ります。

接続の確立と維持に加えて、Oracle Net Foundationレイヤーは、ネーミング・メソッドを使用して通信し名前を解決します。また、セキュリティ・サービスを使用して安全な接続を実現します。

Oracle protocol support

Oracle protocol supportレイヤーは、Oracle Net Foundationレイヤーとネットワーク・プロトコル・レイヤーとの間に位置し、TNS機能をクライアント/サーバー接続で使用する業界標準のプロトコルにマッピングする役割を担います。このレイヤーは次のネットワーク・プロトコルをサポートします。

  • TCP/IP

  • SSL付きTCP/IP

  • Named Pipes

  • SDP

ネットワーク・プロトコル

すべてのOracleソフトウェアは、クライアント/サーバー接続処理の際、2台のコンピュータのトランスポート層間でコンピュータ・レベルの接続を確立するために、既存のネットワーク・プロトコル・スタックを必要とします。ネットワーク・プロトコルは、クライアント・コンピュータからデータベース・サーバー・コンピュータまで、データを送ることに責任があります。この時点で、データはサーバー側のOracle protocol supportレイヤーに渡されます。

TCP/IPプロトコル Transmission Control Protocol/Internet Protocol(TCP/IP)は、ネットワークを介したクライアント/サーバー間の対話に使用される標準の通信プロトコルです。

SSLプロトコル付きTCP/IP Secure Sockets Layer(SSL)プロトコルのTCP/IPでは、クライアント上のOracleアプリケーションとリモートのOracleデータベースが、TCP/IPとSSLを介して通信できます。SSL付きTCP/IPを使用するためには、Oracle Advanced Securityが必要です。

SSLは、証明書や秘密鍵などの認証データをOracle Walletに格納します。クライアントがデータベース・サーバーと接続を開始すると、SSLは証明書を使用して両者間のハンドシェイクを実行します。ハンドシェイクの実行中、次の処理が行われます。

  • クライアントとデータベース・サーバーは、認証データ、暗号化方法およびデータ整合性タイプのセットであるCipher Suiteについてネゴシエーションを行い、交換するメッセージに適用します。

  • 使用する構成によっては、データベース・サーバーはクライアントの公開鍵で暗号化したメッセージにサーバー自身の証明書を入れてクライアントに送信します。データベース・サーバーは、この同じメッセージを使用して、クライアントの証明書を送るように要求する場合もあります。クライアントは、それ自身の秘密鍵を使用してこのメッセージの暗号化を解除し、データベース・サーバーの証明書に認証局のシグネチャがあることを確認します。

  • 必要に応じてクライアントは、このユーザーの証明書をデータベース・サーバーに送信します。証明書によって、ユーザーの情報が正しいことと、公開鍵が実際にそのユーザーのものであることが保証されます。

データベース・サーバーはこのユーザーの証明書を調べて、認証局のシグネチャがあることを確認します。


関連項目:


『Oracle Database Advanced Security管理者ガイド』

Named Pipesプロトコル Named Pipesプロトコルは、分散アプリケーションを使用したクライアントとデータベース・サーバー間で、プロセス間通信を提供する高水準のインタフェースです。 サーバー側のプロセスがパイプを生成し、クライアント側のプロセスが名前によってそれをオープンします。これによって互いに、一方が書き込む情報を他方が読み取ることができます。Named Pipesは、特にPC LAN環境で使用することを念頭に設計されています。

Named Pipesでは、Named Pipesを使用するネットワーク上でクライアント/サーバーの接続が可能です。クライアント上のOracleアプリケーションはNamed Pipesを介してリモートのOracleデータベースと通信できるようになります(Oracleデータベースが、Named Pipesを使用したネットワーク通信をサポートするホスト・システム上で実行されている場合)。

SDP Sockets Directory Protocol(SDP)は、Infinibandネットワーク・ピア間の業界標準のワイア・プロトコルです。InfinibandネットワークでSDPを使用すると、データの中間的なレプリケーションが除去され、メッセージ交換の負荷がCPUからネットワーク・ハードウェアへ移動することにより、TCP/IPのオーバーヘッドが削減されます。

RDBMS

ネットワーク・プロトコルを通じてクライアント・アプリケーションから渡された情報は、データベース・サーバー側にある同様の通信スタックで受信されます。データベース・サーバー側でのプロセス・フローは、クライアント側でのプロセス・フローの逆になり、情報は通信レイヤーを通ってさかのぼります。

OCIのかわりに、データベース・サーバーはOracleプログラム・インタフェース(OPI)を使用します。OCIから送信される各文に対して、OPIは応答します。たとえば、OCIが25行のデータのフェッチを要求すると、OPIはフェッチした25行のデータをOCIに戻します。

5.1.2 Javaアプリケーション接続のスタック通信アーキテクチャ

Oracle Java Database Connectivity(JDBC)ドライバにより、JavaアプリケーションはOracleデータベースにアクセスします。Oracleには、2つのJDBCドライバが用意されています。

  • JDBC OCIドライバは、クライアント/サーバーのJavaアプリケーションで使用されるレベル2のJDBCドライバです。JDBC OCIドライバは、JDBCの呼出しをOCIの呼出しに変換します。変換された呼出しは、Oracle Netを通してOracleデータベース・サーバーに送信されます。

  • JDBCシン・ドライバは、Javaアプレットが使用するレベル4のドライバです。JDBCシン・ドライバは、Javaソケットを通してOracleデータベース・サーバーに直接接続を確立します。データベースへのアクセスは、TTCとOracle Netの軽量実装に支援されます。

図5-3では、JDBCドライバが使用するスタック通信レイヤーを示します。

図5-3 Javaクライアント・アプリケーションで使用するレイヤー

図5-3の説明は次にあります。
画像の説明


注意:


SDPプロトコルはサポートされていますが、この図には含まれていません。

JDBC OCIドライバは、標準のクライアント/サーバー通信スタックと同様の通信スタックを使用します。JDBCシン・ドライバは、JavaNetと呼ばれるOracle Net FoundationレイヤーのJava実装と、JavaTTCと呼ばれるTTCのJava実装を使用します。


関連項目:


『Oracle Database JDBC開発者ガイドおよびリファレンス』

5.1.3 Webクライアント接続のスタック通信アーキテクチャ

TTCによるプレゼンテーションに加えて、Oracleデータベース・サーバーは、Webクライアントがデータベース内にアクセスする機能に使用できる、その他の多数のプレゼンテーションをサポートしています。リスナーは、これを容易にするため、データベースで要求されるあらゆるプレゼンテーションをサポートします。

たとえば、図5-4は、Oracleデータベース・インスタンスのOracle XML DBへのHTTP接続またはFTP接続で使用するスタック通信レイヤーを示しています。WebDAV接続では、HTTPおよびFTPと同じスタック通信レイヤーが使用されます。

図5-4 Webクライアント接続に使用するレイヤー

図5-4の説明は次にあります。
画像の説明


関連項目:


『Oracle XML DB開発者ガイド』

5.2 リスナーのアーキテクチャ

データベース・サーバーは、クライアント・アプリケーションからの初期接続を、リスナーを通じて受け取ります。リスナーはOracle Net Foundationレイヤーの最上位に位置するアプリケーションです。図5-5では、初期接続時のクライアントとデータベース・サーバー上にある様々なレイヤーを示します。

図5-5 初期接続で使用するレイヤー

図5-5の説明は次にあります。
画像の説明


注意:


SDPプロトコルはサポートされていますが、図5-5には含まれていません。

リスナーは、クライアント要求を受け取ってOracleデータベース・サーバーに渡します。クライアントがデータベース・サーバーとのネットワーク・セッションを要求するたびに、リスナーは初期要求を受信します。

各リスナーは、リスニング・エンドポイントを指定する1つ以上のプロトコル・アドレスで構成されます。 これらのプロトコル・アドレスのいずれか1つで構成されたクライアントが、そのリスナーに接続要求を送ります。

リスナーはクライアント要求を受信すると、そのクライアント要求を処理する適切なサービス・ハンドラを選択してクライアント要求を転送します。リスナーはデータベース・サービスとそのサービス・ハンドラが利用可能かどうかを、サービス登録から判断します。サービス登録時、インスタンスのバックグラウンド・プロセスであるPMONプロセスは、次に関する情報をリスナーに提供します。

この情報によって、リスナーはクライアントの要求を適切に渡すことができます。図5-6では、インスタンスがリスナーに情報を登録する様子を示します。登録できるすべての情報を示しているわけではありません。

図5-6 サービス登録

図5-6の説明は次にあります。
画像の説明

オプションで、リスニング・エンドポイント、つまりポート番号を、リスナーに動的に登録できます。たとえば、Oracle XML DB、HTTP、FTPおよびWebDAVのリスニング・エンドポイントがリスナーに登録されます。

インスタンスの起動時にリスナーが実行していない場合、PMONはサービス情報を登録できません。PMONは、定期的にリスナーに接続を試みますが、リスナーが起動されてからPMONがリスナーに登録するまで、最大で60秒間遅延することがあります。リスナーの起動後即座にサービス登録を開始するには、SQL文ALTER SYSTEM REGISTERを使用します。これは特に高可用性が求められる構成で有益です。

リスナーが受信した要求を受け取るのが、対応するインスタンスが登録されるより前の場合は、リスナーは要求を拒否します。

インスタンスが制限されたモードの場合、PMONはリスナーにこのインスタンスへの全接続をブロックするよう指示します。クライアントが接続しようとすると、次のいずれかのエラーが発生します。

図5-7は、HTTP接続を行うブラウザとデータベース接続を行うクライアントを使用して、接続を確立するときのリスナーのロールを示しています。

  1. データベースは、サービス、インスタンスおよびサービス・ハンドラに関する情報をリスナーに登録します。

  2. クライアントはリスナーに初期接続を確立します。

  3. リスナーはクライアント要求を解析し、要求されたデータベース・サービスのサービス・ハンドラに転送します。


    関連項目:

    • ALTER SYSTEM REGISTER文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

    • HTTP、FTPおよびWebDAVのリスニング・エンドポイントの動的な登録の詳細は、『Oracle XML DB開発者ガイド』を参照してください。


図5-7 リスナーのアーキテクチャ

図5-7の説明は次にあります。
画像の説明

5.3 データベース・サーバー・プロセス・アーキテクチャ

リスナーに登録されているサービス・ハンドラのタイプに基づいて、リスナーは要求を共有サーバー・プロセスまたは専用サーバー・プロセスのいずれかに転送します。

この項で説明する項目は、次のとおりです。

5.3.1 共有サーバー・プロセス

図5-8で示すように、共有サーバー・プロセスは、共有サーバー・アーキテクチャで使用されます。共有サーバー・アーキテクチャでは、クライアントは最終的にディスパッチャへの接続を行います。PMONプロセスは、ディスパッチャの場所とロード情報をリスナーに登録するため、リスナーは要求を最もロード量の少ないディスパッチャに転送できます。

ディスパッチャは、複数のクライアント接続を同時にサポートできます。各クライアント接続は、バーチャル・サーキットにバインドされます。バーチャル・サーキットは、ディスパッチャが使用する共有メモリーの1つで、クライアント・データベースの接続要求および応答を目的としています。ディスパッチャは、要求が到着するとバーチャル・サーキットを共通キューに配置します。アイドル状態の共有サーバーは、共通キューからバーチャル・サーキットを取り出して要求を処理し、共通キューから次のバーチャル・サーキットを取り出す前に、取り出したバーチャル・サーキットを放棄します。この方法によって、サーバー・プロセスの小規模プールが大量のクライアントを処理できるようになります。

図5-8 共有サーバー・アーキテクチャ

図5-8の説明は次にあります。
画像の説明

5.3.2 専用サーバー・プロセス

図5-9は、専用サーバー・アーキテクチャを示しています。専用サーバー・アーキテクチャでは、各クライアントは専用サーバー・プロセスへの接続を行います。サーバー・プロセスは、他のいずれのクライアントとも共有されません。

PMONは専用サーバー・プロセスに関する情報をリスナーに登録します。これによってリスナーは、クライアント要求を受け取って転送する際に、専用サーバー・プロセスを開始できます。


注意:


専用サーバー・アーキテクチャは、HTTP、FTPまたはWebDAVクライアントをサポートしていません。データベース・クライアントのみサポートします。

図5-9 専用サーバー・アーキテクチャ

図5-9の説明は次にあります。
画像の説明

5.4 Oracle Connection Managerのアーキテクチャ

Oracle Connection Managerはルーターの一種です。これにより、クライアントの接続要求は次のホップに送信されたり、データベース・サーバーに直接送信されます。Oracle Connection Managerを通して接続要求をルート指定するクライアントは、そのOracle Connection Managerに構成されているセッション多重化およびアクセス制御機能を利用できます。

Oracle Connection Managerは3つのコンポーネントで構成されています。

リスナーは、クライアント接続を受け取り、一連の規則と照合して、アクセスの可否を判断します。アクセスが許可されると、リスナーは最小接続回数の接続を選択してゲートウェイ・プロセスに要求を転送します。CMGWプロセスでは、データをリレーするために接続が終了するまで、この要求を別のOracle Connection Managerに転送するか、またはデータベース・サーバーに直接、転送します。すでに既存のサーバーへの接続がある場合、ゲートウェイは既存の接続を介してこの接続を多重化、または集中化させます。CMADMINは、ゲートウェイ・プロセスとリスナーの状態を監視して、必要に応じてプロセスを停止または開始します。さらに、このリスナーで使用されるゲートウェイ・プロセスの場所とロードを登録し、Oracle Connection Manager Controlユーティリティの要求に応答します。

図5-10では、リスナーは接続要求を選別します。ゲートウェイ・プロセスでは、CMADMINプロセスを登録します。CMADMINプロセスでは、リスナーを登録します。最後にリスナーは、接続要求をゲートウェイ・プロセスに転送します。リスナーが、4番目のクライアントへのアクセスを拒否していることに注意してください。ゲートウェイ・プロセスは3つの有効なクライアント接続を受け取り、データベースへの単一のネットワーク・プロトコル接続を介してそれらを多重化します。

図5-10 Oracle Connection Managerのアーキテクチャ

図5-10の説明は次にあります。
画像の説明

5.5 完全なアーキテクチャ

Oracle Netはアーキテクチャ上のソリューションを提供しているため、インターネットやイントラネット環境における拡張性をさらに高めることができます。

図5-11では、Oracleデータベース・サーバーへの複数の接続が、Oracle Connection Managerと共有サーバー・アーキテクチャによって、さらにスケーラブルになっている様子を示します。Oracle Connection Managerを使用すると、Webアプリケーション・サーバーのネットワークI/Oの負荷を一部オフロードすることができます。また、共有サーバーによって、複数の同時ユーザーを処理できます。

図5-11 スケーラブルなアーキテクチャ上のソリューション

図5-11の説明は次にあります。
画像の説明